This article is all http daemon related which is a very small subset of server config...<p>I don't want to devolve into all my own tips and then have arguments about fail2ban, but I have one tweak to the TRACE/TRACK note, really there are some silly things people can do with any requests other than POST/GET (also silly things people can do with those, but that's primarily App security).<p>I disallow OPTIONS, HEAD, TRACE... everything, with this sort of an Apache config:<p><LimitExcept POST GET>
Require valid-user
</LimitExcept><p>The biggest place this can cause issues is with load balancers using a HEAD command to check the existence of a server.
<i>> Hide your versions</i><p><i>> Another super simple, but often overlooked adjustment to make is to prevent the server from broadcasting too much information about itself. Whilst attackers maybe able to source the information in other ways the harder we make it the more likely potential attackers are to give up and move onto a softer target. It is similar to introducing yourself to someone and giving them specific details about yourself such as "I rarely lock the back window when I pop into town".</i><p>newsflash: exploits will hit the vulnerability anyway, without asking about your name and version.<p>could somebody explain to me why these <i>security by obscurity</i> measures are still popular? especially in an age when running bots hitting every public facing piece of equipment is so cheap?
The title is a bit misleading, as it mostly applies to web daemons configuration, rather than to the servers themselves, and, while being a nice addition to default configuration, is extremely narrow and not really enough when it comes to securing (web or any other) server, while novice reader can get under impression, that it's it.
Nothing<p>Automated network installer (eg cobbler) installs OS, which installs a configuration management system (eg puppet or chef or ansible) which sets up the server appropriately.<p>Done correctly someone logging into a non development server should be an alertable "red flag".<p>Even for a development server you should use veewee, vagrant, box grinder etc etc to produce something consistent and repeatable.<p>"Editing a file in /etc directly 'by hand' should be an obscure art done to teach internals or to scare children on halloween." -@yesthattom
1. install rkhunter<p>2. update it:
#rkhunter --update<p>3. generate checksums of important files:
#rkhunter --propupd<p>*NOTE: when normal system s/w updates are installed, some of the files watched by rkhunter may change and thus generate false warnings. It also needs to be run again to update checksums after updates.
How does an article like this actually get points on HN? It's called "Things I set on new servers", but it should really be called "Things That I Configure in Apache", and the suggestions aren't even anything all that interesting or useful. Do people really even use Apache any more?<p>What?
Also check for this dangerous configuration bug if you are using FastCGI and PHP (I'm not sure if this also applies to other FastCGI applications)<p><a href="https://nealpoole.com/blog/2011/04/setting-up-php-fastcgi-and-nginx-dont-trust-the-tutorials-check-your-configuration/" rel="nofollow">https://nealpoole.com/blog/2011/04/setting-up-php-fastcgi-an...</a>
Does anyone have a link to an article explaining TRACE attacks? I had never heard of it (after 8 years of web development!).<p>Edit: Oops, should have Googled before commenting: <a href="https://www.owasp.org/index.php/Cross_Site_Tracing" rel="nofollow">https://www.owasp.org/index.php/Cross_Site_Tracing</a>
For Rails folks, you can accomplish a lot of this with the excellent Twitter gem "secureheaders".<p><a href="https://github.com/twitter/secureheaders" rel="nofollow">https://github.com/twitter/secureheaders</a>