Child pages
  • 5 Immediate Security Suggestions from 100TB
Skip to end of metadata
Go to start of metadata

One of the worst things that a server administrator can experience is the feeling and reality of having a compromised server. “I could have secured my server better,” muses one administrator. “This will kill our business!” screams management. At the end of the day, owning up to a server and its data being compromised is hard to cope with. Each time a server or computer is compromised there is a greater potential for nefarious actors to spread their botnets, spam hosts and especially for additional backdoors to be deployed on the server.
 

In reality, a small bit of planning can go a long way towards preventing these worst-case scenarios. The steps and advice in this article can guide server administrators to perform security-hardening tasks which go a long way towards helping prevent server compromises. These steps can be deployed by hand, or if you are managing a larger deployment they can be implemented into your automated deployments using stacks such as Puppet, Chef or Salt.


1) Change your passwords!
While we may scoff at someone using a password like “Purpl3Bunnie$”, users often leave passwords with default values provided by a vendor or software developer. At 100TB we issue all servers with random passwords, but cannot stress enough that these should be changed and kept in a secure environment. This can be accomplished in Linux via the passwd command:

 

root@purplebunnies:~# passwd

Enter new UNIX password:

Retype new UNIX password:

passwd: password updated successfully

root@purplebunnies:~#


2) Change your public ports! Sometimes security means playing your cards as close to your chest as possible. Many botnets and brute force applications forego scanning and attacking all ports on a handful of servers in lieu of attacking common ports on many servers. By changing your public ports you employ what is called ‘security by obscurity’, a term at the heart of many debates in infosec. Security by obscurity does not protect you any more than before as services will still listen on a public IP and port; however it does allow an administrator to eliminate a good majority of hit-and-run attacks where botnets scan large ranges of IPs for services running on common ports.

As an example, Secure Shell (SSH) runs on port 22/tcp by default, and is commonly targeted. By changing this to some other random port number you decrease the likelihood of being targeted for brute force attacks. In Linux you can accomplish this change by modifying your SSH configuration file and restarting your SSH daemon (sshd).

To easily update your SSH configuration file and restart sshd, perform the following commands as root, or another administrative user. This will do an inline replacement of the default SSH port and restart the SSH daemon service. Replace 1111 with any available port number (typically between 1025 and 65535).


root@purplebunnies:~# sed -i '/Port/c\Port 1111' /etc/ssh/sshd_config

root@purplebunnies:~# /etc/init.d/sshd restart


3) Deploy and configure your firewall! Linux comes with a powerful firewall called ‘iptables’ which can perform stateful packet/connection inspection. Keeping this information in mind, iptables can be configured to accept, drop or otherwise modify packets and connection attempts. Many front-ends to iptables exist, including ufw, or csf/lfd. For performing basic iptables configuration we recommend checking out our Linux Firewall Introduction


4) Secure public services!
This step is too expansive to summarize, however a good rule of thumb is to ensure that any services that are running on the public network, and can be accessed by anyone over the public network, are secured according to best practices for the application. Some examples of securing public services are:

    1. disable root logins over SSH
    2. use key-based authentication for SSH
    3. deploy and configure ModSecurity for Apache
    4. configure Nginx blocks to prevent unauthorized IPs to an application
    5. set up SSL certificates for your web server
    6. or require authentication for Wowza streaming.

This process will take the most time for you to deploy, however a well-secured public service will greatly reduce the risk of your server being compromised.

5) Ensure you have off-site, static backups! In some cases, even the best planning is not enough. 100TB strongly recommends that any critical data hosted on or required by your server is backed up off-site, with protection in place such as encryption or read-only data archives. While a backup of your data will not prevent existing or future compromises, the effort needed to deploy critical backups will save you further doubts and concerns as to your backup data’s authenticity or integrity in event of a server compromise.

 

The realm of server security is vast, and this guide cannot hope to explain every facet of it. The above five steps are a good starting point, and will help you on your journey to a well-protected infrastructure. We welcome any feedback that you might have about this article!