Here is a simple, straightforward guide to improving VPS security.
Change the SSH portOne of the most common points of attack is port 22. Changing this discourages many of them as well as scripts set to check for that port. In order to change the port do the following:
nano /etc/ssh/sshd_config
You should locate a line that looks like:
#Port 22
Un-comment this line and change the port number. A port number above 1024 is recommended.
This section of your sshd_conf should now look like:
Port 2222
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
You can now save and exit nano (Ctrl x) and restart the SSHD service by issuing the following command:
service sshd restart
IMPORTANT: Make sure you can connect to SSH using the new port. Leave your current SSH session open and open a new session using the new port you set above. If you can connect to the new SSH session on the new port than everything is good. If you cannot, then you need to figure out why. This is why you left the original SSH session open, otherwise, you would be locked out of your server.
You may need to add the new port in your IPTables.
First, open your IPtables rules:
nano /etc/sysconfig/iptables
Next, locate the COMMIT line and add the following above it making sure to change #### to the port you set for SSH:
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport #### -j ACCEPT
You can now save and exit nano (Ctrl x) and restart the IPtables service:
service iptables restart
You should now try to connect to SSH again. If you still cannot connect to it, it would be best to set your SSH port back to 22 and contact your service provider for help.
Use strong passwords for everythingOne of the most common causes of system breach is weak passwords. For a strong password, follow a few simple guidelines:
• Minimum password length should be 10 characters
• Always use a mix of numbers, letters, uppercase, lowercase, and symbols (when allowed)
• Strong Password Example- T=ep@Uy*ST
If you need to change your root password, issue the following command and follow the prompts:
passwd
Disable Root UserIt is a security risk to keep the root user enabled. Most operations and installs should not be done using root. Instead, create a regular user and if you need root privileges, use the su command.
To add a user, do the following replacing “namehere” with your desired username:
useradd namehere
passwd namehere
Now, disable root login to SSH by editing your sshd_config file:
nano /etc/ssh/sshd_config PermitRootLogin no (make sure you remove the #)
Now save and exit Nano (Ctrl x) and restart SSHd:
service sshd restart
For your next connection, use the previously created “namehere” user and if needed to perform root commands, simply use the “su” command followed with the root password.
Restrict SSH access by IP using IPtablesThis adds a great amount of security but make sure you have a static IP.
First, open your IPtables rules:
nano /etc/sysconfig/iptables
Locate the line containing rule with "--dport 22" fragment and add the following above it making sure to change #### to the port you set for SSH and 192.168.0.1 to your IP address:
-A INPUT -p tcp -s 192.168.0.1 --dport #### -j ACCEPT
You can now save and exit nano (Ctrl x) and restart the iptables service:
service iptables restart
Install RkHunterEvery server needs something checking for rootkits, backdoors, md5 hashes (file changes), hidden files, etc.. etc.. and RKHunter is great at this.
To install RKHunter, issue the following commands:
yum install rkhunter -y
You need to set up a daily cron so that rkhunter will check its version and update it if needed as well as run a scan. We will also be setting it so it will e-mail you the daily report.
Create and open in nano a new cron task/shell script by issuing the command below:
nano -w /etc/cron.daily/rkhunter.sh
Now add the following making sure to replace “PutYourServerNameHere” with your server's hostname and “your@email.here” with your email address:
#!/bin/sh(/usr/local/bin/rkhunter --versioncheck/usr/local/bin/rkhunter --update/usr/local/bin/rkhunter --cronjob --report-warnings-only)
/bin/mail -s 'rkhunter Daily Run (PutYourServerNameHere)' your@email.here
If you don’t know your server’s hostname, you can find it by typing hostname in your ssh window. You will need to exit (Ctrl x) nano first or open another session.
You also need to secure the script making it usable only by root. To do this, issue the following command:
chmod 700 /etc/cron.daily/rkhunter.sh
Now test it and make sure it runs ok. To run rkhunter manually, issue the following command:
rkhunter -c -sk
That’s it. You're done and your server just became much safer!
Install CSF (Config Server Firewall)CSF includes many different types of protection and is much more user-friendly than using IPTables directly.
If you are not sure whether you have Perl installed issue the following command:
perl -v
If perl is installed, it will return which version. If it is not installed, issue the following command to install it:
yum install perl-libwww-perl.noarch perl-LWP-Protocol-https.noarch perl-GDGraphyum install perl perl-libwww-perl perl-Time-HiRes -y
Now you can install CSF with the command below:
cd /usr/src
rm -fv csf.tgz
wget https://download.configserver.com/csf.tgz
tar -xzf csf.tgz
cd csf
sh install.sh
Make sure that you have the required iptable modules by issuing the following command:
perl /etc/csf/csftest.pl
It is possible that you will be missing some modules, but as long as the test does not return a fatal error, you should be fine. You may lose some functionality of CSF with missing modules but it will work.
When you install CSF, it automatically whitelists your IP. It also starts in test mode which means it clears the rules every 5 minutes. Make sure you leave it in test mode until you are sure your configuration is working properly. If you do lock yourself out, just wait for 5 minutes and you will be able to log in again. The stock configuration is fine for most servers though some changes should be made.
If you changed your SSH port above, you need to make sure to add it to your CSF config. To edit the csf configuration, issue the following command:
nano /etc/csf/csf.conf
The first thing to edit is the TCP ports. You can delete port 22 on inbound and outbound since SSH uses your new port which should already have been added to the end of the inbound line, if not then add it. You will also need to add it to the outbound TCP:
# Allow incoming TCP portsTCP_IN = "20,21,25,53,80,110,143,443,465,587,993,995,####"
# Allow outgoing TCP portsTCP_OUT = "20,21,22,25,53,80,110,113,443,####"
Next, locate CONNLIMIT = “”
You should limit the number of concurrent connections per IP on the most commonly attacked ports which are 21 (FTP), 80 (HTTP), and your new SSH port. This setting is only for TCP.
CONNLIMIT = "21;5,####;5,80;20"
Next, configure port flood protection located directly under CONNLIMIT. Again, you should add the most commonly attacked ports. This setting limits the number of connections allowed at one time on a specified port.
PORTFLOOD = "21;tcp;5;300,80;tcp;20;5,####;tcp;5;300"
To set the e-mail that CSF will send reports to, find X_ARF_TO = “” and add your email address:
X_ARF_TO = "your@email.here"
That’s all the configuration changes we are going to cover in this guide.
Save and exit your editor (Ctrl x) and start CSF by issuing the following command:
csf -h (shows a list of csf commands) or csf -s (starts csf)
You need to open another SSH session and try to connect to your server. If you can connect without error your configuration is good!
Now we can disable testing mode so the lfd (login failure daemon) will be able to start.
To do this, go back into your csf.conf /etc/csf/csf.conf and find TESTING = “1″ and change it to “0″ then save and exit (Ctrl x). Restart CSF with the following command:
csf -r
Now you should remove the install archive by issuing the following command:
cd ../rm -fv csf.tgz
That's it! Now your server is more secure.
Comments
Install tinc or OpenVPN and use a VPN with a private IP subnet as a lazy man's way to secure services that only you use (especially stuff like web-based administration panels.
There's no good reason to have stuff like that accessible to the public web these days
That's actually a good idea, I basically do this on my private LAN by using different VLAN's but doing this on your public services is a really awesome idea. I'll try setting up a p2p OpenVPN tunnel with my cloud server using pfSense.
Cheers!