How to identify potentially vulnerable network daemons on your Linux systems

[ Editor's note: This article presents one tool you may wish to consider in your security toolkit. However, no single tool or approach is sufficient to ensure security. For more on security topics, we encourage readers to visit the Product Security Center on the Red Hat Customer Portal. ]

Nmap is a frequently used tool for folks in the sysadmin space as well as those pesky "hackers." It's great for testing network connectivity and server availability, but it can also help to identify vulnerable network daemons to both good and bad people. I'll show you how you can use it as a force for good and how others might use it as a force for evil.

Test environment

I'll run some tests against a virtual machine I previously built. The how-to on setting up the testing machine is outside the scope of this article, but please do look up metasploitable in your preferred search engine if you want to test against a system with loads of known vulnerable daemons for learning and testing. Of course, don't expose such a system to any public network; it will likely be compromised in no time. But that's the point, right? To determine how to help defend against such attacks.

The pros of using Nmap to find vulnerable daemons:

• Speed
• Easily scriptable and automated
• Good first pass on auditing systems

The cons:

• Limited ability to verify findings
• Limited ability to manage vulnerabilities
• Lack of distributed scanning support (important for enterprises and large networks)

The first scan

First, scan your vulnerable system using the -sV option to determine the version of network daemons.

# nmap -sV 192.168.27.139

Image

Wow, that's a lot of information. Fortunately, that is to be expected in this test environment. What's happening here is that Nmap is sending queries to the various ports and eliciting a response from the daemon on each port. The daemon's responses are compared to the nmap-services database (which is just a text file) to find matches.

You see that OpenSSH 4.7p1  is running on port 22, which is the usual SSH port. That's probably accurate. A quick check here is the prudent thing to do. Follow up using the command line:

Image

Ok, that confirms it. The next question is, "Does this version of OpenSSH server have any known vulnerabilities?" You'll need to check for published vulnerability notifications. Head over to the NIST National Vulnerability Database to find out:

Image

There is at least one potential vulnerability here. But wouldn't it be great if you didn't have to type or copy/paste into a web browser manually? Nmap can help out here, too. Nmap supports scripts and many are available out of the box on install. One such script is vulners. With all those other services running, specify that vulners only runs against port 22:

# nmap -p 22 -sV --script=vulners 192.168.27.139

Image

As an added bonus, vulners does a better job finding potential issues. The vulners script is more intelligent about matching the version number and found notices that include version ranges, including 4.7p1. A search in the NVD database turns up a note that only specifically mentions 4.7p1. That's a big plus.

Now that you know you can find vulnerable daemons based on the version number, is there a way to protect your systems? You could certainly configure firewall rules to help out, but maybe you can also fool Nmap.

[ You might also like: Finding rogue devices in your network using Nmap ]

Hide information

If you suspect that malicious actors will scan your systems using the same tools that you do (And, they likely will), maybe you can use that to your advantage. Perhaps you can hide or alter the version number of applications such that these types of scans won't return useful results to the attacker. It's possible to do so in some cases. Some applications allow you to change the banner. Using vsftpd as an example, scan for FTP servers on metasploitable, and you'll find:

Image

You can change the /etc/vsftpd.conf configuration file to present a custom banner:

# You may fully customize the login banner string:
ftpd_banner=Welcome to the blah FTP service.

Make the change and scan again to see:

Image

The full customized banner is not visible and the version number is also not visible.

Is changing a daemon's banner something that you should actually do? It might confuse other system administrators or anyone else working in your environment, so at a minimum, it should be made clear to the entire team you've disabled version banners.

The right tool?

When is Nmap a good choice for discovering vulnerable network daemons? As is often the case, the real answer is, "It depends." Here are some questions to ask yourself:

• In large environments, do you have visibility across the entire network? Maybe you need something that includes distributing scanning?
• How are you going to manage the results of scans?
• Will you address and resolve the results manually, or do you want to automate it "at scale?"
• Do you need to keep track of exceptions?
• Do you need to coordinate patch rollouts?

For some of these questions, a dedicated vulnerability scanner might be a better answer. There are a few of them out there, both free and not-free. Their added benefits include more accurate tests and recommendations on how to remediate vulnerabilities. Using Nmap in an ad hoc manner, as discussed, is still valid when combined with a dedicated vulnerability scanner. As a matter of fact, many dedicated vulnerability scanners integrate Nmap directly into their products. Nmap is still great for an initial survey and view of any new systems.

[ Thinking about security? Check out this free guide to boosting hybrid cloud security and protecting your business. ] 

Wrap up

Securing a network involves knowing which versions of network daemons and services are running. Nmap can play an important role in gaining that visibility and evaluating the urgency so that you can protect your assets.

Reference URLs:

• NIST National Vulnerability Database
• Nmap home page
• Nmap and Service Detection