You may have heard in the news recently the Syracuse city police department, was among a list of agencies to have their website hacked. In fact, we had some of the iSchool’s finest weigh in on the situation already. As someone who has a lot of experience administering servers and building web applications (although I have no inside knowledge of what happened in those police department cases), I thought I’d contribute with some general tips and best practices for keeping your website secure.
For a lot of organizations, websites are these things we’re compelled to build for our customers, constituents, or fans. They need one because “everyone has one” especially their competitors. In my experience, organizations with this mentality treat their website like cheesy infomercial appliances, and once the site “goes live” little to no resources are spent maintaining it.
Websites are like pets. They’re a long-term commitment. They need constant care and attention. And just like your pet, if you neglect your website bad things will happen. Organizations who to not dedicate resources to website maintenance are punching their one-way train ticket to Hackedville.
Dedicating boat-loads of resources to your website is no guarantee either, and I argue that no system can be made completely hacker-proof. Even the security experts get hacked. In 2011, a well-known security company which sells hacker-proof technology was hacked, forcing all the major web browsers to release updates to fix the gaffe. So, you ask “What’s a website owner to do?” My answer is two things: minimize the risk and be prepared for the worst.
#1 Minimize the risk
Do everything you can to reduce your chances of being hacked in the first place. When I was a kid, my mom got her car stolen from the neighborhood grocery store parking lot. (That sort of thing happens when you leave the car running out front.) My takeaway? Don’t make it easy for an attacker to break your website. Make your site less tempting to hackers, and chances are they’ll go elsewhere. This seems like common sense, but many people don’t do this because it takes time and expertise. Here’s some of low-hanging fruit for you to pick:
- Stay up to date: Even the simplest websites rely on software which was not authored by you. Since software is created by people it is inherently flawed and contains errors or bugs. You should know the components your website relies on to operate, and keep tabs on the known issues, and releases of updates and patches. You can search known vulnerabilities in software here http://web.nvd.nist.gov/view/vuln/search or here http://www.securityfocus.com/bid. Your best bet is to follow the security lists and announcements for the software you’re using to run your website, and always stay up to date on the latest stable versions.
- Limit access to resources: Has this happened to you? In the morning, you place your lunch in the company refrigerator and when you come back for it at noon… *poof* it’s gone! Many people are shocked by this, but not me. The fundamental problem is a community refrigerator has no means to granulize access so only you take your own lunch. Fortunately, software doesn’t have this problem, and its common practice to harden, or lock down the access to only the resources that need access. The Web is chock-full of hardening guides, like this one if you’re running a Word Press site. You should try to harden your site all three levels: the operating system, the web server, and the web application itself.
- Use strong passwords: You need a username and password to place files on your web server or to update content. Make sure you’re using not using the default password and chose a password which is difficult to guess. If you’re logging in over an insecure protocol like HTTP or FTP then your password is sent “in the clear” making it easy to intercept, especially over public Wi-Fi networks. Yes, you look cool updating your blog from the coffee shop, but it’s become far too easy to get your passwords compromised in such places so avoid it where possible.
#2 Be prepared for the worst
Now that we’ve covered what you can do to reduce the chances of being backed, let’s talk about what your options are when it happens. First, take a bite of the reality sandwich, and come to grips with the fact that your site will eventually get hacked. In my 15+ years of administering and building websites, I’ve had a few of them hacked myself. Your plan here is simple – be the first to know there’s a problem, and have a plan in place to get things back. If you knew ahead of time your laptop will get stolen someday, you’d be a fool to not install laptop tracking software like this guy did, right? Why not have a similar insurance policy for your website?
- Monitor your site: You don’t want to find out that your site was defaced from a news outlet, your supervisor or worse yet your high school arch-nemesis (whom for some odd reason you’ve “friended” on Facebook.) You want to be the first to know about it. There are a lot of good tools for monitoring your site including some free ones like http://www.uptimerobot.com. Be smart and use one. To help with those really difficult cases where your site was hacked but does not appear hacked, use Google Safe browsing to detect the hidden malware on your page. (Use the following Url but replace the site you want to check after the ?site= parameter) http://www.google.com/safebrowsing/diagnostic?site=https://ischool.syr.edu
- Backup your site: It goes without saying you should have routine backups of your site. The rule of thumb is everything required to get the site running exactly as it was at the time of the backup should be included. That usually means the files, content and the database. Backups should be stored off site or at least not on the same computer as your web server. Finally, a backup is only useful if you can restore your website. You should test your website restore process at least once a year and write up instructions in case someone else needs to do it.
- When the hack comes: Get your site back on line quickly with your restore procedure. Examine the log files and attempt to find the source of the hack, and then patch or rebuild your system to prevent it from happening again in the future. Be open with your users about what transpired, what you found, what you did about it and what if any data may have been compromised.
If you’d like me to dive deeper into a specific subject, please share your thoughts in the comments below.
