GIT – If you have a VPS or dedicated server you need to spend some time in your   before using it in any type of production/live environment. If you do not you are asking for trouble at some point down the road. Most likely you are going to lose a lot of hard work and maybe even money. This article will cover the basics of securing your based server (most of what’s covered in this howto will work on other linux distros as well). 

Change The SSH Port

One of the most common points of attack is port 22. Everybody and their dog knows that port 22 is the default for SSH it will be constantly tested and attacked by script kiddies. 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 ####
#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 :

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 than you need to figure out why. This is why you left the original SSH session openotherwise you would be locked out of your server.

You may need to add the new port in your .

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:

-A RH-Firewall-1-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 can not it would be best to set your SSH port back to 22 and contact your service provider for help. There are many other possible reasons why you can not connect to SSH on an alternate port but that is beyond the scope of this howto article.

Use Strong Passwords For Everything!

One of the most common causes of system breach is weak passwords. Jill45 is just not going to cut it! For a strong 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 password issue the following command and follow the prompts:

passwd

Root User

It 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 privledges 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

In order to have root privileges when logged in as the normal user you created above simply type su and enter your root password. Alternatively you can just use the sucommand preceding a command that requires root privileges.

Restrict SSH Access By IP Using IPtables

This adds a great amount of security but make sure you have a static IP. If you don’t know what the difference between static and dynamic is please don’t do this or you will find yourself locked out of your server. If you have a dynamic IP and have some knowledge you can setup to connect through a VPN and allow only the VPN address through the tables for SSH (great way to do things). You can view an article on how to setup a VPN here >> Coming Soon!

First open your IPTables Rules:

nano /etc/sysconfig/iptables

locate the COMMIT line 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 RH-Firewall-1-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

RkHunter

Every server needs something checking for rootkits, backdoors, md5 hashes (file changes), hidden files etc.. etc.. and RKHunter is great at this.
Though it will throw some false positives and you may need to tune the settings we will cover this in a future article.

To install RKHunter issue the following commands:

cd /usr/local/src
wget http://dfn.dl.sourceforge.net/sourceforge/rkhunter/rkhunter-1.4.0.tar.gz
tar -zxvf rkhunter-1.4.0.tar.gz
cd rkhunter-1.4.0
./installer.sh –layout default –install
/usr/local/bin/rkhunter –update
/usr/local/bin/rkhunter –propupd
rm -Rf /usr/local/src/rkhunter*
cd

You need to setup a daily cron so that rkhunter will check its version and update 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 below command:

nano -w /etc/cron.daily/rkhunter.sh

Now add the following making sure to replace “PutYourServerNameHere” with your servers 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 your 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. CSF should work fine by default on most servers but sometimes on an OpenVZ VPS you will need to ask your provider to add missing IPTable modules that CSF needs. We use KVM for full Kernel and driver Virtualization so you won’t have this issue with us.

Note: In the minimal versions of CentOS 6 Perl does not come pre-installed so you will need to install it.

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 perl is not installed issue the following command to install it:

yum install perl perl-libwww-perl perl-Time-HiRes -y

Now you can install CSF with the below commands:

rm -fv csf.tgz
wget http://www.configserver.com/free/csf.tgz
tar -xzf csf.tgz
cd csf
sh install.sh

If you have or ever have had APF installed you must remove it completely as CSF and APF conflict.

To remove APF issue the following command:

sh /etc/csf/remove_apf_bfd.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 every 5 minutes it clears the rules. 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 5 minutes and you will be able to login 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 than add it. You will need to also add it to the outbound TCP:

# Allow incoming TCP ports
TCP_IN = “20,21,25,53,80,110,143,443,465,587,993,995,####”
# Allow outgoing TCP ports
TCP_OUT = “20,21,22,25,53,80,110,113,443,####”

Next locate CONNLIMIT = “”
You should limit the amount 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 amount 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 sends 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 for this guide. It is a good base and makes a huge difference in the security and stability (under attack) of your server.

Save and exit your editor (Ctrl x) and start CSF by issuing the following commands:

csf -h (shows a list of csf commands)
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) and restart CSF with the following command:

csf -r

Now you should remove the install archive by issuing the following commands:

cd ../
rm -fv csf.tgz

Congratulations! Your server is no longer an open door saying “hack me kids”. Your server now looks like an impenetrable wall discouraging any that view its mighty girth! It’s exciting when you get a new server and tempting to rush into getting it ready for the public, but your Linux Server Security should never be overlooked. We hope this guide will make it easier for you to secure your server and ultimately save a whole lot of stress and grief.

 

Print Friendly

Comments

comments

Bài viết liên quan