5

I'm looking to make a "bare minimum" checklist for securing a public facing Unix web server. Assume it's a LAMP stack (or similar). This list should be what minimums you would implement. Obviously requirements would go up for high traffic sites (DDoS protection, high availability, etc), but I'm not concerned with that. Just looking for a list of bare minimums for hosting a single web server that is running Apache or NGINX and has a basic on-server MySQL or MariaDB database and a simple PHP application. Assume it's running on AWS, DigitalOcean, etc. Some ideas include:

  • Blacklisting/whitelisting IP ranges by country
  • Disable remote login by root
  • Enable fail2ban (disables IPs after so many failed login attempts)
  • Configure firewall to only allow relevant ports inbound (e.g. ssh, sftp, https)
  • Only allow HTTPS and then test validity of certificate and server configuration using Qualys SSL Labs testing tool (https://www.ssllabs.com/ssltest/)
  • Enable multi-factor authentication everywhere that is public facing such as your Amazon/Digital Ocean/etc. account, your credentials to the server, etc.
  • Change the root password to minimum 16 characters, alphanumeric with special characters.
  • What else?
wubs
  • 153
  • 1
  • 5

2 Answers2

3

I would definitely add that SSH should not allow password authentication alone, but public-key (and/or some second token).

I would personally add enabling seLinux (or appArmor) to the list, and would also enable and configure auditd, and mandating the use of sudo.

There is a lot more you could do if wanted to go above minimal, but I would consider those three things to be part of the base you would want.

If you wanted something a bit more formal, you could look at the CIS benchmarks (https://benchmarks.cisecurity.org/downloads/benchmarks/). They possibly aren't minimal, but have some recognition (whatever your opinion of the CIS might be).

CentOS (and I suspect RedHat likes) also has some tools for SCAP (https://scap.nist.gov/) you could check out if they apply.

iwaseatenbyagrue
  • 3,631
  • 1
  • 12
  • 24
2

Marcus Müller has a point, this is a very broad question.

The best security policies have a focus. Some famous general (Frederick the Great?) once said "to protect everything is to protect nothing." Start by establishing a "threat profile" so you know what you're guarding against, then identify best practices to guard against those threats. Obviously, revise your threat profile whenever you experience specific attacks.

To what's already been said, I would add the following:

  • Move your sshd to a non-standard port. The script kiddies attack port 22, if your sshd is not there, only smarter attackers will even find it.

  • Consider putting all non-public listening ports (sshd, SNMP, rsyslogd etc.) behind a VPN. Access (human or inter-server) to those services will be a bit more tedious to set up, but this offers strong protection. VPN-only access particularly recommended for servers that require no direct public access (such as database or message-queue servers).

  • Define egress rules for your firewall, not just incoming rules. Particularly for services blackhats like to exploit once they've zombied your server (such as SMTP). If somehow your server gets compromised, but your hijacker can't ping or SMTP or SFTP outward... that's one additional line of defense that buys you time to smite them.

  • (Labor-intensive but worth it) Consider upgrading your entire server farm to IPv6 (which everyone will have to do soon enough anyway). Bear in mind fail2ban will become less valuable as it only works on IPv4. IPSec is baked into IPv6.

Daniel de Segovia Gross
  • 36
  • 4