BackTrack and its tools can protect your environment from remote intrusions

  

 Email Article  

Tweet  

  

Attackers commonly look for remote vulnerabilities in order to compromise the resources on your network. BackTrack Linux, a security-testing distribution, can help you inspect your network and servers for remote security weaknesses and potential vulnerabilities.

BackTrack, which is based on Ubuntu, bundles all the tools necessary for penetration testing and security audits. You don't really have to run BackTrack to use the tools it provides, but booting up a BackTrack live CD lets you get started in no time.

A word of caution before you start: Scanning your network may take system and network resources. Make sure to fully coordinate your actions inside your company and inform your management.

Exploring Your Environment With Nmap

One of the first tools you'll want to try is Nmap, a powerful, smart, command-line network scanner. In essence, Nmap shows open ports and some information about the services listening on these ports.

Nmap comes with a lot of useful options enabled by default. For instance, port randomization, which randomizes the order of the ports being scanned, prevents simple intrusion detection and protection systems from detecting and blocking you while you're probing. Some other useful options include:

• --script – performs the scan with the aid of a set of scripts. Nmap comes bundles with a few sets of scripts categorized according to their use, such as for DOS, brute force, and other weakness detection. You can find the full list on the home page of the Nmap Scripting Engine. If you are not sure what scripts to use, choose the default, which is more informative and less intrusive than some other options.
• -p – specifies which ports you are interested it. Most legitimate services run within the port range of 1:10000 for UDP and TCP protocols. Scanning a larger range requires more time and resources.
• -sV – shows service and version information for the open ports. This is useful to show whether a service is listening on a non-default port, such as Apache listening on TCP port 8080, and the version information may indicate outdated software and potential vulnerabilities. If you detect such outdated applications with Nmap, make sure to patch them as soon as possible.

   

• target – defines the target host or network as the final argument of your Nmap command.

Put the above options together and you get a command like:

nmap --script=default -p U:1-10000,T:1-10000 -sV 192.168.1.0/24

In this case the target is an internal, private network (192.168.1.0/24). If you are looking for truly remote vulnerabilities you should perform the scan from outside your local network. Still, internal scans are also useful and can show unnecessary exposure of services, which is always a security risk.

The output of this example is similar to:

...
Nmap scan report for example.org (192.168.1.102)
Host is up (0.0017s latency).
Not shown: 9997 closed ports
PORT     STATE SERVICE     VERSION
22/tcp   open  ssh     OpenSSH 6.0p1 Debian 3 (protocol 2.0)
...
80/tcp   open  http    Apache httpd 2.2.22 ((Debian))
|_http-methods: No Allow or Public header in OPTIONS response (status code 200)

...
3306/tcp open  mysql   MySQL 5.5.28-1
...

The above excerpt from the Nmap output shows information for SSH, HTTP, and MySQL services running on 192.168.1.102. It clearly shows the name and the version of each software – OpenSSH 6.0p1, Apache httpd 2.2.22, and MySQL 5.5.28-1.

Limiting the network exposure

For each exposed service, you should decide whether it's really necessary for it to be exposed. If not, one option is to make sure the service listens only on the local loopback interface (127.0.0.1). This is a good option for the MySQL service when it serves only local requests. To do that for MySQL, edit the my.cnf file. When MySQL listens on all interfaces, the bind-address directive looks like this: bind-address = 0.0.0.0. To make it listen only on the local interface, change it to bind-address = 127.0.0.1.

Furthermore, MySQL lets you explicitly limit the remote hosts from which a user is allowed to connect as part of MySQL's connection verification process. Such an additional security restriction helps guard against brute-force attacks but usually does not help against remote software vulnerability exploits.

You can also use a firewall to restrict access to a service. When properly configured, a firewall can allow only certain hosts to connect to a given service. An example iptables command for MySQL looks like this: iptables -I INPUT -s 192.168.1.1 -p TCP --dport 3306 -j ACCEPT; iptables -I INPUT -p TCP --dport 3306 -j DROP. This sample command allows MySQL connections only from the IP address 192.168.1.1.

As a last resort, you may decide to change the default port for a service. This is usually feasible for sensitive services that have to remain relatively hidden but still fully accessible from outside. This is often the case with SSH when system administrators want to have access from everywhere. You can change the SSH port to a port above the commonly scanned range (1-10000). For example, if you set the SSH daemon to listen on port 19999, it's less likely to be detected, but you will be still able to access the service from anywhere as long as you know this port. To change the SSH port, edit the directive Port in the file /etc/ssh/sshd_config and restart the service. Don't forget to specify this port when connecting later with your SSH client (ssh -p in Linux shell).

These are the simplest ways to limit the remote connectivity and protect from external attacks. If you are interested in more advanced techniques, consider port knocking as one interesting idea and option.

Limiting the exposed information

After dealing with the SSH and MySQL services from our example, only the web service remains. It is supposed to be fully accessible for the outside world on the standard HTTP TCP port 80, and we cannot hide it under a different port nor restrict the access to it. Our only choice is to disclose as little information about it as possible.

According to the above example, the Apache version is Apache httpd 2.2.22 ((Debian)). This gives an attacker plenty of information – web server name, version, and even operating system. You can limit this information by changing the Apache configuration and setting the server token setting as ServerTokens ProductOnly. After this, when you run the scan again, you'll see for version only Apache httpd.

Even with our basic Nmap example we got more information than just the version. For Apache, Nmap also showed that the OPTIONS header is allowed and there is no restriction on the http methods – |_http-methods: No Allow or Public header in OPTIONS response (status code 200). From a security point of view it's important to restrict the allowed HTTP methods to only the ones your site really needs and thus give attackers fewer options.

For example, the TRACE HTTP method echos back user input. Clearly, this is a feature useful for debugging but not needed in a production web server. The TRACE method is used in certain attacks by allowing access to sensitive information, so it should almost always be disabled. In fact, most average web servers should support only two HTTP methods: GET and POST. To forbid the rest, use the Apache directive limitexcept like this:

    Order deny,allow
    Deny from all

Hiding the server token and forbidding unneeded communication methods is a good start, but it's far from enough. You also need an application firewall, which offers more thorough protection. Almost all publicly accessible services have such a firewall solution available. In the case of Apache, check the article How to protect your web server with ModSecurity.

Examine your Nmap output and proceed similarly for any publicly exposed services. You should be able to foil the usual generic untargeted attacks that randomly scan the Internet for outdated or misconfigured software.

Delving deeper into penetration testing with Nessus

Nmap is powerful and lets you do some serious penetration testing of your environment, but it's not as easy to use and complete as some more advanced vulnerability scanners. Nessus, for instance, is a commercial vulnerability scanner that allows limited free use for home users. To start using it in BackTrack you have to register for a license key first and follow a few preliminary steps as described in the official Nessus on BackTrack guide.

Once you have Nessus up and running in BackTrack, you control it from an intuitive web interface accessible at https://localhost:8834. The web interface allows you to easily configure your penetration test and generate a professional-looking report upon completion.

Nessus detects more than 50,000 vulnerabilities on all exposed levels, from misconfigured services to outdated software. Once it detects a vulnerability, it reports all the related information and, most importantly, suggests a solution. This saves you time, ensures that you follow the best practices for resolving a problem, and that you comply with the highest security standards.

Nessus is the most preferred penetration testing solution for enterprise users. Still, Nmap remains the Swiss Army Knife for network scanning, as it provides the fastest and simplest path to exploring your environment without binding to licenses and spending significant amounts of money.

No matter what application you choose, the most important thing is to understand the concept of remote security. Don't unnecessarily expose services, nor any information that is not explicitly required. That should ensure you don't attract publicly circulating threats that may exploit zero-day vulnerabilities.