Skip to main content

How to identify potentially vulnerable network daemons on your Linux systems

Identifying vulnerable network daemons for remediation and how attackers find vulnerable resources.
Broken chain link fence

Image by jplenio from Pixabay

[ 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
Nmap scan results displaying many open ports

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:

nc result displaying OpenSSH version information

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:

NIST vulnerability search results for OpenSSH

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
CVE results from vulners script

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:

port, state, and version information

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:

port, state, and no version information

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:

Check out these related articles on Enable Sysadmin

Enumerating a new network with nmap
Here are some basic Nmap flags that you can use to generate a quick and useful network map for effective troubleshooting and managing network traffic.
Topics:   Linux   Linux administration   Security  
Author’s photo

Geoff Galitz

Geoff Galitz is a Cybersecurity/Systems Engineer and writer by day.  By night, Geoff is a family man and tinkerer.  Making the world a better, safer place, bit by bit, is his mission.  More about me

Red Hat Summit 2022: On Demand

Get the latest on Ansible, Red Hat Enterprise Linux, OpenShift, and more from our virtual event on demand.

Related Content