I’m a web developer, that’s what I do, and I love it. But, the unfortunate side of offering web development services, is that you usually need to offer a place for your clients web offerings to live – a web server. Many years ago when I had just a couple clients, a small shared hosting space did the trick. But as my client base grew, I found that shared hosting become not only cumbersome to manage, but insecure and limiting. Fast forward 10 years and I now manage 4 dedicated servers. I was forced to become a server admin, something I had cringed about for as long as I can remember.
Some may ask, “why not spend a few extra bucks and go the managed server route?” It seems like the obvious choice, but it unfortunately would force my web hosting fees beyond the competitive rates that they’ve always been. I want my clients to be on my servers, so I can provide all the TLC that their website needs, and to ensure that, my prices need to be competitive.
The biggest challenge has been keeping up with web server security standards. Over the years, I’ve picked up on many best practices, and I think you’d be surprised at how many of them are simple “one-liners”, quick one-off commands at the prompt or in a config file that really do wonders to enhance your web security. From one web developer who wears too many hats to another, I hope this list helps (oh, Linux only, by the way :):
- Disable Trace / Track
To this day, I’ve never needed to take advantage of the Trace or Track HTTP request methods. They are used for lower lever debugging, at the connection level. But, they can also be used maliciously via holes in web browser security. If you have no need, or don’t know what these are, turn them off.Apache: httpd.conf
Add configuration directive anywhere:TraceEnable off - Shut down your FTP server
It’s a shame, but you really can’t be safe unless you disable your FTP service. Although it can be encrypted via TLS in many FTP clients, you can’t depend on your users using that option. It’s just too easy to sniff out an FTP password, and believe me, it happens more often than you think.
Typically, it’s a one-line config change, and line at the command prompt, but it differs based on your FTP server and Linux distro. Start here:http://www.phy.bnl.gov/cybersecurity/old/ftp.html - Put your database on a different server
Okay, technically not a one-liner, although, changing your database connection server parameter from localhost to a remote server really involves only one line :)This is typically done for performance reasons, but if you are storing sensitive data, encrypted with a private key, it is a useful technique. You can keep the encryption key in your code, on the web server. Then, of course, the encrypted data will be stored in the database on the database server. If someone gets access to your database server, they won’t be able to get your encryption key.Keep in mind though, that in doing this, you need to make sure that your connections to the remote server are secure, if you are trading sensitive information. If you’re using MySQL, the REQUIRE SSL parameter to the GRANT statement is worth taking a look at.Better yet, have your data center run a CAT 5 cable between your web & database servers. This will allow for direct access to your database server, making queries both faster and more secure. Be prepared for the additional monthly cost of adding a network card to both servers though.
- Disable the PHP eval function
disable_functions = evalWILL NOT WORK!I guess I tricked you into thinking this is a one-liner. I’ve seen a few posts that suggest such a method, but eval isn’t a PHP function. One way to get around this is to load this “patch”:http://www.hardened-php.net/suhosin/index.htmlI know, eval has its uses, and it really isn’t eval or PHPs fault that it is so widely abused by hackers. But, the fact remains that it is abused, and if you don’t need it or aren’t using it, you should try to disable it.
- Turn off mail serverWhile I haven’t personally been victim of a mail server port related attack, it’s one more thing you can do to make yourself feel warm and fuzzy at night. If you don’t need a port open, why have it open?If you do need to send mail, try using Gmail’s SMTP server. Most languages now support the use of TLS encryption, so using Gmail’s server should be fairly simple. Just a word of caution, avoid sending from my@email.com to my@email.com. This is typically either not allowed by Google, or is flagged as SPAM.
Pretty close to a one-liner: http://www.serverschool.com/dedicated-servers/how-to-close-and-open-ports-with-iptables/
- SSL V3I’m not going to pretend to know the difference between SSLv2 and SSLv3. But, what I do know is that a couple PCI compliance tools that I’ve used prefer to see that you are using the latter. This is generally a quick change in your apache config file:
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP
I am seriously struggling to find one-liners here! I’m considering changing the title of this post. - Don’t support .htaccess filesThe .htaccess file is most useful on shared hosting, where the individual customer is not granted access to the primary apache config file. Hackers love this file, which is typically available to any FTP user, as it allows them a very quick method of redirecting users to malicious websites. Anything you can put in an .htaccess file, you can also put within a
<Directory>block within your VirtualHost stanza. Yes, this also goes for the famous WordPress .htaccess directives (for creating SEO friendly URLs).The magical one-liner here is:AllowOverride NoneDrop this into a
<DIrectory />block within your httpd.conf. - Turn off directory index listingsThe less a hacker knows about your server, the better. By default, Apache setups display a directory listing when an index file is unavailable. Best to turn this off:
Options -Indexes - Use SQL injection-safe functionsAlways use your languages SQL injection-safe functions when executing ANY SQL query. An SQL injection can take place on just about any type of query (select, insert, update, delete, etc.).In PHP, use
mysql_real_escape_string()In ColdFusion, use
<cfqueryparam> - ServerTokens directive
For the last one, I present possibly the easiest “fix” of all. By default, Apache configurations reveal way more than they should in HTTP response headers. Going back to that point about not revealing any more information than you have to, I’d recommend replacing your ServerTokens directive in httpd.conf to:ServerTokens Prod - Quick RestoreObviously, the ability to quickly restore from backup is not a security measure, but many backup policies don’t translate to quick restorations. Storing complete backups off-site or on another server is a terrific idea, but having a local backup to restore from with a single unzip or gunzip command is a nice additional.I like to do this for WordPress sites, as they allow the user a good deal of control and hence the capability to introduce security holes into their own sites! Create a cron job to tar and gzip the site and store a copy of it in a non-web-accessible location on the server, nightly or weekly.
- Disable SNMP
There are a number of exploits within the SNMP specification itself. Unless you’re using it and know how to configure it properly, it’s best just to turn it off.
service snmpd stop
Oh, probably also want to prevent it from ever loading again:
chkconfig snmpd off