4 ms·

If you want a safe and secure Web server, use what your distribution gives you. Don't add third party sources if you can avoid it, ie. don't need features < 1 y

by rlpb 14y ago

If you want a safe and secure Web server, use what your distribution gives you. Don't add third party sources if you can avoid it, ie. don't need features < 1 year old. It's hardly safe and secure if it's not had long enough for people to find problems with it anyway. Instead, go with what your distribution gives you. The people who put your favourite distribution together work on making the system safe and secure as a whole. People who don't think it is safe and secure file bugs and they get fixed. And you have one place to get all your updates in case fixes are needed. If you start adding third party sources, you're on your own as to managing any implications of the way you've put it together. Just because each individual component is safe and secure doesn't mean that it is as a whole. For example, Ubuntu add hardening (AppArmor) for various server daemons which you won't get if you just download apache from the project website. If you need a guide on putting a system together yourself, then you aren't someone who can manage these implications yourself, and you're trusting the guide author in not having made any mistakes. Are you really in a position to judge his competence? Just use your distribution's standard web server and you'll get your safe and secure Web server in one command.

laumars 14y ago
I disagree with that. Apache's defaults on most distros isn't secure. Even 'enterprise' level distributions often fall into the following traps when packaging Apache: 1-> auto indexing enabled (should be disabled) 2-> user directories enabled (should be disabled) 3-> server signatures 'on' (should be 'off') 4-> server tokens set to 'full' (should be 'prod') 5-> hidden (dot prefixed) files not always blacklisted as unauthorised files in Apache config 6-> same as above for editor specific back up files (eg file~). But this is only an issue for people who bulk upload or edit files on the live server (very naughty). 7-> having less optimal SSL configurations (Apache's default SSL set up isn't PCI compliant). (IIRC there's a couple of other Apache tweaks, but that's just off the top of my head) Then you have issues with PHP (eg logging to STDOUT so web users can view PHP errors). And that's just covering the webserver configuration. There's still holes that need plugging if you actually want to run a secure web server; one of my favourite tools for that is using fail2ban which will auto-blacklist IPs in iptables (Linux firewall) based on if certain attacks are detected. For example it can prevent brute force attacks on SSH brute force attacks (which negates the need to run denyhosts as recommended in the article), HTTP auth, FTP, mail servers, etc. And touching on SSH, many data centres will enable root log ins on their OS pre-installs by default. Your first job on any such box will be creating a user account and then disabling root log ins (PermitRootLogin no -> /etc/ssh/sshd_config). Then there's a whole stack of optimisations you can run on iptables to adaptively prevent port scanning, forged TCP/IP packets and such like. Also many distributions ship FTP, which is insecure by default. Anyone sys admin requiring FTP hosting would be better off using a chrooted SFTP environment (so the security benefits of SSH plus the sandboxed (chroot) environment that FTP often benefits). Let's also not forget the plethora of internal services (databases, MTAs (mail servers), etc). If you're reading this article then you're probably not a trained systems administrator or not working for a large enough company where each server is running in it's own environment. Thus your MySQL / Postgre / whatever databases are running on your webservers. So you need to ensure that your database is only listening on localhost (127.0.0.1). Same applied for your MTA, unless you are intentionally providing a mail services (it is advisable to have an MTA installed even if you're not providing mail services because you can then set up daemons like fail2ban to automatically e-mail you when attempted break ins happen; which will in turn allow you to spot any determined hackers and permanently ban their IP from your box). And lastly, if you're really paranoid, run your webserver inside a Linux/UNIX container (FreeBSD Jail, Solaris Zone, Linux OpenVZ) instead of inside a virtual machine as there have been hacks where attackers can break out of the VM and gain access to the host system (as of yet, I've not heard such attacks from containers, but if anyone has any evidence of that then I'd love to know). Running inside a container will give your webserver the sandboxed environment to work with plus an easy route for backups / snapshotting meaning minimal downtime and data loss should the worst happen and your server does become compromised. (source: http://www.youtube.com/watch?v=hCPFlwSCmvU http://www.youtube.com/watch?v=hCPFlwSCmvU - it's a plugged vulnerability, but it will give you an idea about the kind of issues VMs face when compared to containers) In short; distribution's don't ship secure defaults. They ship a happy medium between usability and security. However if you have an internet facing box (particularly one not hidden behind a hardware firewall, as many budget set ups are not), then the happy medium isn't secure enough.
- rlpb 14y ago
  I'd say that most of your points are debatable. They can be divided into two groups: 1) Changes that give you relatively little gain from a security point of view at the cost of massive usability. I'd be happy to run production servers without these changes, and so I claim that these are debatable. 2) Changes that stop inexperienced admins accidentally compromising their servers, at the cost of usability/complexity. Debatable because they're less about security and more about not shooting yourself in the foot. Eg. fail2ban. I use ssh keys only. Brute forcing my ssh won't work, and I'd prefer to not allow outsiders to cause firewall rule changes on my servers based on a script that parses log strings with regular expressions. I trust ssh's security more than I trust fail2ban in not having a vulnerability. > And lastly, if you're really paranoid, run your webserver inside a Linux/UNIX container This is pretty much what AppArmor hardening does. LXC (Linux containers) are implmented via AppArmor. A compromised httpd daemon restricted in this way won't be able to much anyway (eg. open outbound ports or go to other areas of the filesystem). And this is what Ubuntu ships by default for many daemons. > Also many distributions ship FTP, which is insecure by default. Nowadays this stuff is only installed if you requested it, which is different from "ship"ing it. If you use distribution defaults, you won't have an FTP server installed. If you choose to install one, you'll get the weakness whether you use the distribution, tune it yourself or install from a third party source. > In short; distribution's don't ship secure defaults. They ship a happy medium between usability and security. However if you have an internet facing box (particularly one not hidden behind a hardware firewall, as many budget set ups are not), then the happy medium isn't secure enough. Secure enough for production. I have plenty of servers on distribution defaults that haven't been compromised (and I have experience in dealing with others' servers when they have been compromised, so I don't think I'm oblivious). You may prefer adding additional hardening, but it is unnecessary and relies on you knowing what you are doing. Finally, you've missed my biggest point. For someone new to running servers on the Internet, who can he trust for guidance? You, me, a random guide on the Internet or a distribution vendor?
  - laumars 14y ago
    I don't think you've really read through the points I was raising as the vast majority of them were relating to hiding server based information from unauthorised users and preventing brute force attacks. Neither of those two have any impact on usability what-so-ever (that is, unless your 'user' is an attacker lol). If you don't mind, I will address your points individually: "Changes that give you relatively little gain from a security point of view at the cost of massive usability. I'd be happy to run production servers without these changes, and so I claim that these are debatable." Which items specifically prevents usability? None of them do aside the FTP (but SFTP is supported by nearly every FTP client already) and turning off PHP error logging to STDOUT (really not recommended for production servers!). Everything else doesn't reduce usability for authorised users. And I resent the claim that there's little gain as even on my servers which have a low public profile, I get reports of multiple brute force attacks a week (on average, about separate 5 attacks a week, all of which I manually add to a permanent firewall blacklist when it becomes obvious that they're just retrying attacks everytime fail2ban's autoban expires). "Changes that stop inexperienced admins accidentally compromising their servers, at the cost of usability/complexity. Debatable because they're less about security and more about not shooting yourself in the foot. Eg. fail2ban. I use ssh keys only. Brute forcing my ssh won't work, and I'd prefer to not allow outsiders to cause firewall rule changes on my servers based on a script that parses log strings with regular expressions. I trust ssh's security more than I trust fail2ban in not having a vulnerability." You don't understand how fail2ban works if that's your primary concern. Fail2ban isn't public facing, it just monitors logs and then adds an iptables (or any firewall you chose) rules based on the results of the log files. It's iptables that is public facing and thus needs to be protected against vunrabilities; and iptables is proven technology already. What's more, preventing brute force attacks doesn't reduce usability nor prevent you from shooting yourself in the foot; preventing brute force attacks is the !!bare minimum!! you need to do if you have an internet facing server. This is security 101! I do agree with you that SSH keys are preferable to password log ins, but that also adds complexity and can reduce usability if users need access from multiple locations and platforms (there are workarounds, eg memory stick with the key on), and then you still have the issue of brute force attacks on every other log in service. "This is pretty much what AppArmor hardening does. LXC (Linux containers) are implmented via AppArmor. A compromised httpd daemon restricted in this way won't be able to much anyway (eg. open outbound ports or go to other areas of the filesystem). And this is what Ubuntu ships by default for many daemons." You missed the point about easy snapshotting though, which is why I raised the point about containers in the 1st place. I will grant you that you can have back up solutions on bare metal systems, but snapshotting is way more usable (which is ironic given that's been your key argument). Plus I did say that advice was for the paranoid (ie not really all that necessary unless you fancy tinkering). "Nowadays this stuff is only installed if you requested it, which is different from "ship"ing it. If you use distribution defaults, you won't have an FTP server installed. If you choose to install one, you'll get the weakness whether you use the distribution, tune it yourself or install from a third party source." You're just reiterating what I said though as I didn't say distributions install it by default. However you missed my point there as well, as I was describing how FTP isn't ideal for production systems (FTP sends clear text passwords and doesn't behave itself behind firewalls and/or NATing without adaptive routing (which means that FTPS often doesn't work behind some firewalls).). Thus chrooted SFTP is a much saner solution for production systems. "Secure enough for production. I have plenty of servers on distribution defaults that haven't been compromised (and I have experience in dealing with others' servers when they have been compromised, so I don't think I'm oblivious). You may prefer adding additional hardening, but it is unnecessary and relies on you knowing what you are doing." You've been lucky. But what your advocating is little more than 'security by obscurity' rather than pro-actively hardening your box. Having worked on a number of high profile web infrastructures (including farms that take web payments), I wouldn't be doing my job if I ignored my steps; in fact our business wouldn't exist as we would break UK laws. The Apache configuration I described is ridiculously easy to set up, as is fail2ban. They are the bare minimum any web server should implement. Which is why I placed emphasis on them by placing those suggestions at the top of my post. However if we're going to advocate complacency in order to make our lives easy, then lets also not bother keeping our software up to date, because that's a real pain in the arse at times :p
jackalope 14y ago
By all means, buy the car with the best safety record. But you still need to fasten your seatbelt, buy and properly install car seats for your kids, and, above all, learn how to drive safely. My point is that there is more to security than installing an OS and running regular updates.

by rlpb 14y ago

laumars 14y ago

I disagree with that. Apache's defaults on most distros isn't secure. Even 'enterprise' level distributions often fall into the following traps when packaging Apache: 1-> auto indexing enabled (should be disabled) 2-> user directories enabled (should be disabled) 3-> server signatures 'on' (should be 'off') 4-> server tokens set to 'full' (should be 'prod') 5-> hidden (dot prefixed) files not always blacklisted as unauthorised files in Apache config 6-> same as above for editor specific back up files (eg file~). But this is only an issue for people who bulk upload or edit files on the live server (very naughty). 7-> having less optimal SSL configurations (Apache's default SSL set up isn't PCI compliant). (IIRC there's a couple of other Apache tweaks, but that's just off the top of my head) Then you have issues with PHP (eg logging to STDOUT so web users can view PHP errors). And that's just covering the webserver configuration. There's still holes that need plugging if you actually want to run a secure web server; one of my favourite tools for that is using fail2ban which will auto-blacklist IPs in iptables (Linux firewall) based on if certain attacks are detected. For example it can prevent brute force attacks on SSH brute force attacks (which negates the need to run denyhosts as recommended in the article), HTTP auth, FTP, mail servers, etc. And touching on SSH, many data centres will enable root log ins on their OS pre-installs by default. Your first job on any such box will be creating a user account and then disabling root log ins (PermitRootLogin no -> /etc/ssh/sshd_config). Then there's a whole stack of optimisations you can run on iptables to adaptively prevent port scanning, forged TCP/IP packets and such like. Also many distributions ship FTP, which is insecure by default. Anyone sys admin requiring FTP hosting would be better off using a chrooted SFTP environment (so the security benefits of SSH plus the sandboxed (chroot) environment that FTP often benefits). Let's also not forget the plethora of internal services (databases, MTAs (mail servers), etc). If you're reading this article then you're probably not a trained systems administrator or not working for a large enough company where each server is running in it's own environment. Thus your MySQL / Postgre / whatever databases are running on your webservers. So you need to ensure that your database is only listening on localhost (127.0.0.1). Same applied for your MTA, unless you are intentionally providing a mail services (it is advisable to have an MTA installed even if you're not providing mail services because you can then set up daemons like fail2ban to automatically e-mail you when attempted break ins happen; which will in turn allow you to spot any determined hackers and permanently ban their IP from your box). And lastly, if you're really paranoid, run your webserver inside a Linux/UNIX container (FreeBSD Jail, Solaris Zone, Linux OpenVZ) instead of inside a virtual machine as there have been hacks where attackers can break out of the VM and gain access to the host system (as of yet, I've not heard such attacks from containers, but if anyone has any evidence of that then I'd love to know). Running inside a container will give your webserver the sandboxed environment to work with plus an easy route for backups / snapshotting meaning minimal downtime and data loss should the worst happen and your server does become compromised. (source: http://www.youtube.com/watch?v=hCPFlwSCmvU http://www.youtube.com/watch?v=hCPFlwSCmvU - it's a plugged vulnerability, but it will give you an idea about the kind of issues VMs face when compared to containers) In short; distribution's don't ship secure defaults. They ship a happy medium between usability and security. However if you have an internet facing box (particularly one not hidden behind a hardware firewall, as many budget set ups are not), then the happy medium isn't secure enough.

rlpb 14y ago
I'd say that most of your points are debatable. They can be divided into two groups: 1) Changes that give you relatively little gain from a security point of view at the cost of massive usability. I'd be happy to run production servers without these changes, and so I claim that these are debatable. 2) Changes that stop inexperienced admins accidentally compromising their servers, at the cost of usability/complexity. Debatable because they're less about security and more about not shooting yourself in the foot. Eg. fail2ban. I use ssh keys only. Brute forcing my ssh won't work, and I'd prefer to not allow outsiders to cause firewall rule changes on my servers based on a script that parses log strings with regular expressions. I trust ssh's security more than I trust fail2ban in not having a vulnerability. > And lastly, if you're really paranoid, run your webserver inside a Linux/UNIX container This is pretty much what AppArmor hardening does. LXC (Linux containers) are implmented via AppArmor. A compromised httpd daemon restricted in this way won't be able to much anyway (eg. open outbound ports or go to other areas of the filesystem). And this is what Ubuntu ships by default for many daemons. > Also many distributions ship FTP, which is insecure by default. Nowadays this stuff is only installed if you requested it, which is different from "ship"ing it. If you use distribution defaults, you won't have an FTP server installed. If you choose to install one, you'll get the weakness whether you use the distribution, tune it yourself or install from a third party source. > In short; distribution's don't ship secure defaults. They ship a happy medium between usability and security. However if you have an internet facing box (particularly one not hidden behind a hardware firewall, as many budget set ups are not), then the happy medium isn't secure enough. Secure enough for production. I have plenty of servers on distribution defaults that haven't been compromised (and I have experience in dealing with others' servers when they have been compromised, so I don't think I'm oblivious). You may prefer adding additional hardening, but it is unnecessary and relies on you knowing what you are doing. Finally, you've missed my biggest point. For someone new to running servers on the Internet, who can he trust for guidance? You, me, a random guide on the Internet or a distribution vendor?
- laumars 14y ago
  I don't think you've really read through the points I was raising as the vast majority of them were relating to hiding server based information from unauthorised users and preventing brute force attacks. Neither of those two have any impact on usability what-so-ever (that is, unless your 'user' is an attacker lol). If you don't mind, I will address your points individually: "Changes that give you relatively little gain from a security point of view at the cost of massive usability. I'd be happy to run production servers without these changes, and so I claim that these are debatable." Which items specifically prevents usability? None of them do aside the FTP (but SFTP is supported by nearly every FTP client already) and turning off PHP error logging to STDOUT (really not recommended for production servers!). Everything else doesn't reduce usability for authorised users. And I resent the claim that there's little gain as even on my servers which have a low public profile, I get reports of multiple brute force attacks a week (on average, about separate 5 attacks a week, all of which I manually add to a permanent firewall blacklist when it becomes obvious that they're just retrying attacks everytime fail2ban's autoban expires). "Changes that stop inexperienced admins accidentally compromising their servers, at the cost of usability/complexity. Debatable because they're less about security and more about not shooting yourself in the foot. Eg. fail2ban. I use ssh keys only. Brute forcing my ssh won't work, and I'd prefer to not allow outsiders to cause firewall rule changes on my servers based on a script that parses log strings with regular expressions. I trust ssh's security more than I trust fail2ban in not having a vulnerability." You don't understand how fail2ban works if that's your primary concern. Fail2ban isn't public facing, it just monitors logs and then adds an iptables (or any firewall you chose) rules based on the results of the log files. It's iptables that is public facing and thus needs to be protected against vunrabilities; and iptables is proven technology already. What's more, preventing brute force attacks doesn't reduce usability nor prevent you from shooting yourself in the foot; preventing brute force attacks is the !!bare minimum!! you need to do if you have an internet facing server. This is security 101! I do agree with you that SSH keys are preferable to password log ins, but that also adds complexity and can reduce usability if users need access from multiple locations and platforms (there are workarounds, eg memory stick with the key on), and then you still have the issue of brute force attacks on every other log in service. "This is pretty much what AppArmor hardening does. LXC (Linux containers) are implmented via AppArmor. A compromised httpd daemon restricted in this way won't be able to much anyway (eg. open outbound ports or go to other areas of the filesystem). And this is what Ubuntu ships by default for many daemons." You missed the point about easy snapshotting though, which is why I raised the point about containers in the 1st place. I will grant you that you can have back up solutions on bare metal systems, but snapshotting is way more usable (which is ironic given that's been your key argument). Plus I did say that advice was for the paranoid (ie not really all that necessary unless you fancy tinkering). "Nowadays this stuff is only installed if you requested it, which is different from "ship"ing it. If you use distribution defaults, you won't have an FTP server installed. If you choose to install one, you'll get the weakness whether you use the distribution, tune it yourself or install from a third party source." You're just reiterating what I said though as I didn't say distributions install it by default. However you missed my point there as well, as I was describing how FTP isn't ideal for production systems (FTP sends clear text passwords and doesn't behave itself behind firewalls and/or NATing without adaptive routing (which means that FTPS often doesn't work behind some firewalls).). Thus chrooted SFTP is a much saner solution for production systems. "Secure enough for production. I have plenty of servers on distribution defaults that haven't been compromised (and I have experience in dealing with others' servers when they have been compromised, so I don't think I'm oblivious). You may prefer adding additional hardening, but it is unnecessary and relies on you knowing what you are doing." You've been lucky. But what your advocating is little more than 'security by obscurity' rather than pro-actively hardening your box. Having worked on a number of high profile web infrastructures (including farms that take web payments), I wouldn't be doing my job if I ignored my steps; in fact our business wouldn't exist as we would break UK laws. The Apache configuration I described is ridiculously easy to set up, as is fail2ban. They are the bare minimum any web server should implement. Which is why I placed emphasis on them by placing those suggestions at the top of my post. However if we're going to advocate complacency in order to make our lives easy, then lets also not bother keeping our software up to date, because that's a real pain in the arse at times :p

jackalope 14y ago

By all means, buy the car with the best safety record. But you still need to fasten your seatbelt, buy and properly install car seats for your kids, and, above all, learn how to drive safely. My point is that there is more to security than installing an OS and running regular updates.