Server Colocation and Managed Hosting Solutions

CLIENT LOGIN  |  CAREERS  |  FORUMS  |  BLOG  |  COMMUNITY  |  CONTACT    
nav_top
nav_bottom


"We have no physical product that comes in a box, so the IT infrastructure has to be rock-solid for us. PEER 1 gets that it's critical to my business, and they make sure that I stay in business."

Darrell Snow, VP of Technology
Blast Radius

digg this rss feed print this page send to a friend
Linux/Unix Security 101


By Payam Tarverdyan Chychi

Remote Security
Network security is a growing concern among server administrators of all kinds. Whether you are a small one-person, one-server operation, or part of an enterprise corporation with hundreds of servers all over North America, you need to ensure that your servers are protected from vulnerabilities.  There are a growing list of ways that unscrupulous individuals can take advantage of your servers, so by being vigilant and taking appropriate measures, you can begin to defend yourself against the dark side. The following addresses just one aspect of good network security practices. Stay tuned for more in upcoming PEER 1 newsletters.
           
Open ports, Active daemons
The only way to improve security is to understand what hackers know about your server. This can be done with the use of a port scanner. Nmap (www.nmap.org) is a very fast and versatile network scanner. Use nmap to find out what ports you have open to the world.

Getting a good sense of what software you need running, what ports they use, and what protocols those ports listen for is a good way to minimize security threats and at the same time analyze your network for any security breaches. If you notice any unexpected ports showing up in your nmap results, investigate it further by running "netstat -a". This will show you a list of known services (that are cross-refrenced to /etc/services) and the ports they are listening on or have established a connection to.

BE THOROUGH: Don’t forget that just because your nmap/netstat results show port 21 / ftp is open/listening, doesn’t mean that there really is an ftp server running on that port. Use "ps aux" to discover what user is running that process and take necessary actions based on your findings. Remember, if your server has been hacked, you will require a new set of binary files for testing as the original binary files may have been trojaned in order to provide the administrator with false results.

By default, every OS has a list of system daemons that get run on startup. In most cases you will only need a few of these running, if any at all. The file containing this list can be found at /etc/inetd.conf and /etc/xinetd.conf.

It is very important to go through this file and comment "#" any of the services that you do not need running at startup. You may notice that not all services are listed in /etc/inetd.conf, for example apache, ftp and sshd. You can find a more complete list of services in /etc/init.d/ and also in /etc/xinetd.d/

Software Vulnerability Assessment (ftp / sshd / smtp / httpd)
Now that you know what ports are open on your server, it’s time to analyze each port to better understand the need and the security threat it may hold. Below is an example of what you might see as the result of your nmap.

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-05-10 04:34 PDT
Interesting ports on host.domain.com (1.1.1.1):
(The 1653 ports scanned but not shown below are in state: closed)
PORT   STATE SERVICE
22/tcp  open    ssh
25/tcp   open    smtp
80/tcp   open    http
           
For a better understanding of what each SERVICE represents please use your googling skills at www.google.com.

In most cases, you can locally connect to the open port via telnet and obtain some information about the active software.
           
telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
220 mail.domain.com ESMTP Sendmail 8.12.9/8.12.9
^]
telnet> quit
Connection closed.

By telneting to port 25 on the local host I was able to obtain valuable information about the software that is accepting the connection. We know that there is a mail daemon running by the name of Sendmail and that it’s using the version 8.12.9/8.12.9. This simple knowledge is enough for script kiddies (people that use tools and codes provided by others who possess much higher skills than they do, otherwise known as crackers, or as portrayed by the media, hackers) to use on special search engines designed to parse through an “exploit” database and look for any exploits that were designed for "Sendmail 8.12.9/8.12.9".

So how can you protect yourself? The first and most important task is to always be informed of security threats. Inform yourself of the latest   security threats by visiting CERT (http://www.cert.org), NVD (https://nvd.nist.gov), Secunia (http://securia.com) and Zone-H (http://www.zone-h.org). By staying on top of the latest security threats, you will quickly realize that Sendmail, one of the oldest SMTP softwares out there, is also one of the most vulnerable.

Use the same telnet method to find information about the software you run on each of your open ports and investigate the security history of each one.
           
*Important*
Try to enforce policies in your network infrastructure so as not to use default ports or banners. There are tools (auto rooter) out there that are specially coded to scan the Internet looking for certain open ports or strings inside banners, and then they cross-reference the open port and banner information with an exploit that meets the qualifications of a Vulnerable Host. By changing your default ports and the banner information, you increase the chances of being bypassed by such coincidental hack attempts. This is refered to as “Security by Obscurity”. For more information, check out a well-written article by Jay Beale, Lead Developer of Bastille Linux Project that explains how real security measures plus obscurity equals a well-secured network. (http://bastille-linux.org/jay/obscurity-revisited.html)