Testing the Locks: Validating Security in a Linux Environment

The last lock to test is, in many cases, the first entrance into your network, the perimeter. Let's test it by placing our VM outside the network and then performing a network map against our publicly facing IP address(es) to verify that only allowed services are allowed in or out of the network. We use the time-tested Nmap application for this role.

Although Nmap is on the BackTrack VM, you need to update to the latest version to use the handy new topology tab of the zenmap front-end GUI. Download Nmap from the project's site, and install on the VM with the usual ./configure, make, make install sequence. Type the command zenmap from a terminal to bring up the GUI. Enter a host, host range or network as the target, select Regular Scan from the Profile drop-down list and click on Scan. This performs a cursory scan of the host/networks and identifies open ports and other available information about the host, such as OS and app versions (Figures 8 and 9). Be patient; this process may take a while. Use Nmap's results to verify that only allowed hosts and services are accessible from the outside.

Figure 8. Nmap Results from a Regular Scan

Figure 9. The Topology Tab of zenmap Visualizes a Map

After running Nmap, we can start to envision how an attack against our network might take place. Assume we can glean our network's external IPs from public DNS or whois records. With this information, we run a network map against those IP addresses and identify host OS and application versions. With map results in hand, we scan said hosts for vulnerabilities as discussed in section 3 of this article. If we are lucky, we find one and run an exploit against it to take control of the box. If all we wanted was to own the box, mission accomplished. But, if we wanted to own other hosts or the network, we might begin a new map from the inside or sniff with a tool like Wireshark from the owned box. If we passively sniff traffic instead of map, we are less likely to set off any IDS alarms. At that point, we notice SSH traffic to a particular machine, so we attempt to gain a remote shell against it. Hopefully, there aren't any glaring openings in our local configuration, as we checked for in section 1, or we might lose another box or boxes.

Although this is not a standard blueprint for attack by any means, it is a possible avenue for attack. There are too many methods, techniques, hacks, cracks and attacks to document at length here. By performing regular assessments like the one shown in this article, we can lower the risk of attack, but not eliminate it. Unfortunately, it is a lot harder to play defense than offense. The bad guys do not focus on one aspect of security (or insecurity), and all they need is a single opening in the network, the OS or the application to be successful. Hopefully, after sampling the tools here, you can test your own locks and get the peace of mind that your network, your systems and your security measures work.