10 ms·
Things I set on new servers
- purephase 13y agoFor Rails folks, you can accomplish a lot of this with the excellent Twitter gem "secureheaders". https://github.com/twitter/secureheaders https://github.com/twitter/secureheaders
- daemon13 13y agoIs there smth similar for Python?
- TallboyOne 13y agoCan anyone explain how to do this with nginx? I'm not using rails but I would really like to have all those. I'm not sure what's best though.
- nisa 13y agoAlso 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) https://nealpoole.com/blog/2011/04/setting-up-php-fastcgi-and-nginx-dont-trust-the-tutorials-check-your-configuration/ https://nealpoole.com/blog/2011/04/setting-up-php-fastcgi-an...
- columbo 13y agoMy #1 install on any server is fail2ban, then it's server specific stuff.
- octo_t 13y agofail2ban should be the first thing to install, first thing to manage via puppet/chef, first thing to have centralized logged etc :p
- stevekemp 13y agoUnless you restrict SSH access to a small set of known-good IP addresses, of course.
- hackerboos 13y agoI've always wanted to do this, but then I thought "What if I suddenly lose my IP address?"
- laumars 13y agoUse ssh keys instead then :-)
- drdaeman 13y agoKeys are additional credentials, so they don't add any security by themselves. You have remove a password from an account (set unusable password). However, there are rare cases where you need to access the server from some remote location, when you don't have your SSH private key at hand, and the only credentials you can use, are the those you keep in your head. Obviously, the most important requirement is a strong password, but protecting against brute-force won't hurt.
- laumars 13y ago> Keys are additional credentials, so they don't add any security by themselves. You have remove a password from an account (set unusable password). Keys add security if you turn off password based logins (this is done in sshd_config - you don't need to mess about with the users passwd) > However, there are rare cases where you need to access the server from some remote location, when you don't have your SSH private key at hand, and the only credentials you can use, are the those you keep in your head. > Obviously, the most important requirement is a strong password, but protecting against brute-force won't hurt. You're point about not having private keys to hand is a very valid one; and why I opt for fail2ban ssh rules against password logins on my own personal servers. But the strength of keys compared to passwords does make key based authentication a good measure against brute force attacks (purely in terms of the time line to to crack a key)
- euroclydon 13y agoIf you're using SSH keys exclusively, what does fail2ban really buy you? The HTTP monitoring sounds like it might be useful, but also might be an easy way to reject the Googlebot and de-list your site.
- jallmann 13y agoFail2ban can be used to rate-limit nearly all services that have the potential for abuse. I have it set up to track connection and message frequency, bans on message content (not following protocol, overly large, malformed, etc) and so forth. Having a system like F2B is nice because it compartmentalizes abuse handling and you can set up rules in one place for all your services, both user-facing and not. Since the rules/actions are user defined, anything is possible -- I've had actions that send alerts to Twitter, a system that distributes bans to hundreds of servers, and centralized logging that gives very good insight into how users are poking around.
- buro9 13y agoYup. Fail2Ban ModSecurity (for whatever web server, including Nginx) And the OWASP rules for ModSecurity.
- treve 13y agoWhat about a great default content security policy? :)
- cabirum 13y agoPHP also uses cookie named PHPSESSID to store session ids. Use session.name to specify a different one.
- laumars 13y agoThat has no impact on security. If an attacker can read your cookies then it didn't matter if you're sessions are called PHPSESSID or WETTROUT, they're still readable.
- tachion 13y agoThe 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.
- Treffynnon 13y agoI think I do a reasonable job of making that clear with the introductory paragraph, but yes it is something that cannot be understated. They are just three little things that do not constitute a complete security policy.
- hackmiester 13y agoWhen silencing Nginx's version number, what is the value in continuing to supply the "Nginx" header to indicate which product it is?
- apendleton 13y agoTwo reasons, I think: one (as a sysadmin once explained it to me) is that there's a certain degree of public good/advertising that comes from publicly supporting an open-source project by advertising that you use it in your headers. Services that aggregate web server market share (Netcraft, etc.) use the Server header to build stats. It's also not that hard to fingerprint webservers (though not necessarily their specific versions) without making use of the Server line by testing for other subtle differences in behavior (see, for example, http://82.157.70.109/mirrorbooks/apachesecurity/0596007248/apachesc-CHP-2-SECT-3.html http://82.157.70.109/mirrorbooks/apachesecurity/0596007248/a... ). So on balance, hiding the version makes it hard to single you out for vulnerabilities in specific versions, but hiding the server name altogether doesn't really add much.
- brokentone 13y agoThis article is all http daemon related which is a very small subset of server config... 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). I disallow OPTIONS, HEAD, TRACE... everything, with this sort of an Apache config: <LimitExcept POST GET> Require valid-user </LimitExcept> The biggest place this can cause issues is with load balancers using a HEAD command to check the existence of a server.
- apendleton 13y agoThis is probably over-broad. HEAD is also used by browsers to determine whether or not to re-request cached content; disabling it will still allow pages to load properly, but will waste bandwidth and slow down page loads as browsers re-request unchanged content. OPTIONS is necessary if you want to offer APIs that support CORS: http://en.wikipedia.org/wiki/Cross-origin_resource_sharing http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
- ntoshev 13y agoWhy would a browser use HEAD instead of conditional GET to re-request cached content? It would require one more round-trip if a refresh is actually required.
- vsync 13y agoThe best is to use GET with an If-Modified-Since header: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.25 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14... This acts like HEAD if the resource has not been modified and like GET if it has. In practice this seems to be the go-to technique for browsers as well.
- apendleton 13y agoI've definitely observed both behaviors in Firefox, and to be honest, I'm not entirely sure why. I'll see what I can dig up...
- lifeguard 13y ago1. install rkhunter 2. update it: #rkhunter --update 3. generate checksums of important files: #rkhunter --propupd *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.
- hostyle 13y agoWhat stops an attacker running rkhunter --proupd after he/she has installed backdoors in a few of your binaries ? I realise what rkhunter does (searches for common backdoors), but I can't see what advantage the proupd argument adds.
- lifeguard 13y agoIt is useful if accounts other than root have been compromised, like the web server's.
- ook 13y agoNothing 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. Done correctly someone logging into a non development server should be an alertable "red flag". Even for a development server you should use veewee, vagrant, box grinder etc etc to produce something consistent and repeatable. "Editing a file in /etc directly 'by hand' should be an obscure art done to teach internals or to scare children on halloween." -@yesthattom
- lifeguard 13y agoIdeal world, meet actual world.
- ook 13y agoAutomating infrastructure and treating it like code is a similar shift in mindset to embracing test driven development for the first time. It appears daunting, but once you get over the hump you can't imagine how you ever survived without it. If you have a mythical quiet Friday afternoon install Vagrant and try and replicate your manual setup steps for a new server and share it with your development team. Even just having the steps required to set up a development environment represented in re-usable versioned code is worthwhile. Next time a new hire starts that afternoon repays itself when they have a fully working dev environment ready in less then an hour. Going from that, to doing this stuff in production is a lot of work, but you get similar pay offs at every step as long as you're willing to invest a little time.
- lifeguard 13y agoYou don't have to convince me it is good. In my entire career I have never seen a company that manages even 50% of their servers this way. It has always been a situation of engineering 'being too busy cutting wood to make better saws'.
- twic 13y agoThe company where i work manages >90% of its servers that way. This company is blessed with some extraordinarily bloody-minded sysadmins who made the time to sharpen the saw in the face of mounting piles of wood to cut.
- zalew 13y ago> Hide your versions > 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". newsflash: exploits will hit the vulnerability anyway, without asking about your name and version. could somebody explain to me why these security by obscurity measures are still popular? especially in an age when running bots hitting every public facing piece of equipment is so cheap?
- lifeguard 13y agoSure, PCI DSS.
- laumars 13y agoWhile you're true, it's only takes 5 seconds to change the config. Plus some security certifications (eg PCI) check those signatures during their automated scans. My problem is when people think hiding their signatures makes their systems more secure rather than equally secure but with less garbage broadcast
- nisa 13y ago
- olalonde 13y agoDoes anyone have a link to an article explaining TRACE attacks? I had never heard of it (after 8 years of web development!). Edit: Oops, should have Googled before commenting: https://www.owasp.org/index.php/Cross_Site_Tracing https://www.owasp.org/index.php/Cross_Site_Tracing
- Rickasaurus 13y agoGotta wonder why these aren't defaults.
- monokrome 13y agoHow 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? What?
- shanbady 13y agoIn the examples you provided, I believe you meant to say `top != this` instead of `top != self` as you had it. minor edit