Locking down the root acount, using SSH keys, installing fail2ban, and setting up a basic firewall are all things we should be doing in the first five minutes on a new server. After these basics, what other steps do you take to harden your servers? Are there security utilities that you consider essential? Have you implemented any intrusion detection?
Let’s share what’s on our server security check lists.
Those are the basics I always run.
to add to these:
Just for posterity’s sake (since I came across this post in a Google search), changing the SSH port does not remove the need for fail2ban. A good port scanning tool (e.g., nmap) can discover what services are running, even if they’re running on a non-standard port. So while changing the SSH port might provide some protection against brute force scans for open port 22, it won’t mean nobody can see that you’re running SSH.
Related to security in an after-the-fact sort of way: Backups..lots of backups. Regular backups of your web-folders and databases in different folders for different times.
Have those backups initiated from a different server that ssh’s into the droplet and backs up things then disconnects.
Also: a snapshot of your droplet in a working state.
If your server is compromised, or crashes ..you can spin-up a droplet from that image and then restore your web-folder and databases from the most recent backup.
I’ve spun up servers with these specs, but I’ve always wondered why there isn’t an image that essentially starts with these standards, too.
While they might not be the first things that come to mind when thinking about security, monitoring and logging can play an important in role. Often no one notices when a system is initially compromised. The Linux Auditing System is one powerful tool that provides an audit trail for actions that occur on a server allowing you to notice when something out of the ordinary happens. Other useful software for monitoring your servers include Nagios and Prometheus. Both can alert you when resource usage like bandwidth is abnormal. As your infrastructure becomes more complex, setting up centralized logging allows you to search and visualize your logs all in one place. The ELK Stack (Elasticsearch, Logstash, and Kibana) is a popular solution for this.
@asb
hi bro,
i was just thinking, this tutorials could be used with ubuntu 16.04 without any issue or not?
https://www.digitalocean.com/community/tutorials/how-to-protect-ssh-with-fail2ban-on-ubuntu-14-04
Ubuntu 14.04 shipped version 0.8.11 while 16.04 is shipping 0.9.3, but fail2ban is pretty stable. There shouldn’t be any issues following that tutorial on 16.04 as all the basic functionality is the same. Though there have been a number of improvements around more advanced usage and additional filters shipped. So looking over the release notes might be a good idea.
One minor change in the Debian/Ubuntu package to be aware of is that the distro defaults are now done in /etc/fail2ban/jail.d/defaults-debian.conf rather than in /etc/fail2ban/jail.conf directly.