There are ways to make a server less susceptible to attacks. You can harden a web server and its supporting programs, but it may not be enough. Reading an article on the bad things about security through obscurity can make you wonder if it’s worth it. It is, trust me.
There are so many ways to get hacked if you don’t know what you’re doing. It isn’t as much an issue if you’re using shared hosting because you control very little. When you have total control, it’s a huge issue. One mistake can open up your server to the worst of the worst.
Iptables is the default firewall for most Linux systems. Unless you’re a command-line commando, you need an interface to work with it effectively. Doing things from the command line when you’re prone to making mistakes can get you locked out of your server.
Despite the name, ConfigServer Security & Firewall (CSF) is merely an interface to iptables. It’s really good if you know what you’re doing and not so good if you don’t.
CSF can be installed as a module in the cPanel, DirectAdmin and Webmin control panels (I use Webmin). It can also be used without a control panel but it takes extra work to get it going.
With CSF, you can close all the service ports on the server except the ones you need open. I don’t use a mail server and I don’t use a name server. The number of incoming ports open on my Digital Ocean droplet (a VPS) is limited to six TCP ports (other than FTP passive ports) and one UDP port. That takes care of the services I use: SSH server, FTP server, web server and control panel.
You can also limit abusive port scanning with CSF. If I view my syslog, I can see port scans happening nearly every minute of every day. Even if they find my open ports, they can’t do much because the applications are already hardened.
This is really easy to do on Ubuntu (or Ubuntu derivatives). Add the IP addresses you connect from to /etc/hosts.allow and then the ones you don’t to /etc/hosts.deny, in that order (or you may lock yourself out):
sshd:123.123. 123.123.123. 18.104.22.168
The trailing period is the way to specify a range. The IP address and ranges above are just for formatting, use your own.
The next step is to use public key authentication instead of a password and never log in as root. Log in as a super user and use “su” or “sudo” to do things requiring root user access.
Finally, move your SSH port (if you’re the only user). That way, attackers have to use a port scanner to find it. Even if they find it, they won’t be able to get into it if you have everything set up the way I have it set up even if they’re on the same network you’re on. If CSF is set up correctly, failed logins will end up blocked in iptables.
First things first, never use plain FTP. FTPES (explicit over TLS) is secure. Second, move the port (if you’re the only user). Third, make sure TCP wrappers are turned on for the FTP server. With VSFTPD, just add “tcp_wrappers=YES” to the end of the configuration file. Fourth, add these to the hosts.allow and hosts.deny files (it will be different if you use something other than VSFTPD):
vsftpd:123.123. 123.123.123. 22.214.171.124
Again, the trailing period is the way to specify a range. The IP address and ranges above are just for formatting, use your own.
Finally, make sure your superuser can do everything you need to do by FTP and disable root access. You can do this with VSFTPD by adding to the configuration file (/etc/vsftpd.conf) and creating a new file.
Add to the configuration:
userlist_enable=YES userlist_deny=YES userlist_file=/etc/vsftpd.user_list
Create the file on the last line above and enter “root” as the sole item in it:
You can restart the daemon with:
service vsftpd restart
I use a home-brewed application firewall for Nginx. It won’t work for Apache or any other web server. I’ll publish a separate article about it.
In the meantime, you should switch to SSL (HTTPS) if possible, unless you’ve already switched. You can get a free SSL certificate and automate its renewal, if a domain validation certificate is good enough for you. I’ll publish another separate article about it.
Previous and Next Articles (if any):
Your comment will appear below the form when it's approved. When the page redisplays after hitting the send button (it takes a few seconds), your comment has been sent.
When replying to someone else's comment, please start the comment with "@" and the name so I can put it in the right place.
Please read some of my more important pages if you have the time: