Linux security is often overlooked in the mistaken assumption that security is built in. While this may be true to a certain extent, not taking any security measures makes you a target. No security often indicates to an attacker that the server administrator is possibly inexperienced and an easy target. At Host Africa, we care about security as a secure environment makes for happier customers.
Adding security should be your first step after starting your server as any new ip address is targeted on average less than 45 seconds after it goes live !
Secure your access
Ensure that only YOU have a valid password. It may be nice to have your hosting provider know your password when you forget it. The downside is that the same helpful help-desk agent may leave your hosting provider and use that password against you. Keep a special access account which is allowed to gain root privileges via sudo for your hosting provider or anyone else. Change this password after every use and NEVER give anyone your root password. There are a few exceptions to this, but always change a password once the 3rd party has finished using it. Once again, your linux security is only as strong as the administrator makes it.
Choose a GOOD password – see our blog on passwords
A good password, in essence, is long and easy to remember.
Follow the link above for a quick look at just how easy it is to create a strong password.
Use ONLY ssh to access remotely
The days of TELNET are long gone. Anything as important as your access details MUST be transmitted via an encrypted link. This is exactly what SSH does. It give your remote access via a securely encrypted tunnel. Install SSH if it is not already installed in Centos/Redhat with: “yum install openssh” and in Ubuntu/Debian with: “apt-get install ssh”
Create an ssh key-set – security is THE KEY
Log in to your linux server and type “ssh-keygen”
This will create a public-private key-pair which you can optionally add a password to. If you want to create without a password, simply press enter when asked for a password. The files created will be in the user home directory ie the ~ directory. For root this is /root/.ssh . All other users are under /home/~/.ssh.
The files will typically be called id_rsa.pub and id_rsa. The .pub file is the public key. This can be copied into ~/.ssh/authorized_keys to allow any holder of both keys to access WITHOUT a password. The advantage of this is that removing the key also removes access.
No passwords need to be given out. You can generate key-pairs for each user, root or not. Multiple users can log in as root with different keys.
Ensure that some form of firewall is installed
On most flavours of Linux, IPTABLES is the default firewall back-end and many of the “new” firewalls are often just a command shell to manipulate iptables. IPTables is a key component in linux security.
Having said that, work with whatever you are comfortable with. The more familiar you are with the firewall, the less chance of making a mistake. Too keep it simple, most firewalls are divided into “POLICIES”, “RULES” and “CHAINS”. A POLICY is what happens to the data when there are no RULES i.e a POLICY of REJECT or DROP will deny all access to the data directed to the CHAIN the POLICY is applied to.
The default CHAINS are INPUT (data FOR your server), OUTPUT (data FROM your server) and FORWARD (data travelling THROUGH your server). For a start, it is best to keep all POLICIES at ACCEPT and always end with a REJECT or DROP rules. This will have the same effect as a policy, but has the advantage that if you wipe all rules, you won’t be kicked off your own server ( it happens ! ). CentOS/Redhat now has FIREWALLD and Ubuntu/Debian as UFW. These firewall shells both manipulate IPTABLES.
Install fail2ban and make sure it is active for SSH
Fail2Ban SSH Module checks your log files for failed login attempts (for SSH) and after a preset number of failed login attempts, it blocks the IP address of the person trying to log in. Only install this if you do NOT have cPanel installed. cPanel uses CSF/LFD (Login Failure Daemon) to essentially do the same as fail2ban. In Ubuntu, fail2ban is usually activated by default for SSH. On CentOS, you usually have to activate it.
Ensure only the needed ports are open
Once you have all your software installed and running, make sure you have researched (Googled) which ports each application runs on. Run the command “netstat -punta” to see which ports and applications are running. Ensure that each open port is needed by the system or your application.
Ignore any ports running on IP address 127.0.0.1 as this is an internal IP. Certain applications such as MySQL in safe mode run on this port. Focus on ports running on IP 0.0.0.0 (Any IP) or the PUBLIC ip of your server. Learn how to shut down any application you or your system do not need and keep it shut down even after a reboot.
Be careful of dependencies. SAMBA needs NMBD and SMBD to be running and NFS needs RPCBIND and RCP.MOUNTD to run.
Ensure that any public directories have the minimum permissions needed to function
Permissions are often misunderstood and sometimes overrated as a security measure. Setting the correct permissions can keep a rogue application in check or minimise the damaged caused by a compromised account. Set User and Group permissions on files AND directories where possible with no Global permissions, or read only if really needed. Once again, Google is your friend as well as the hundreds of Linux forums dedicated to just these issues.