Nessus is a popular vulnerability scanner, but there are some misconceptions about what it does and how it works. So how does Nessus detect vulnerabilities, and why is that important? Let’s explain.
Nessus detects vulnerabilities in two major ways, either by scanning ports or scanning files. Scanning files requires it to log in to the system, but it is considerably more accurate.
Nessus Plugins
For me, the concept of Nessus Plugins was the hardest thing to wrap my head around. A plugin is just a collection of code and/or signatures that Nessus uses to evaluate and/or report on a system. They’re the equivalent of a vulnerability check in Nexpose or a QID in Qualys.
It seemed like something called a plugin ought to do more than just that. But you’re not really disrespecting them much if you think of them the same way you’d think of antivirus signatures. They’re just checking for something other than viruses.
Nessus will sometimes feed the results of one plugin into others. This saves code and saves scanning time, and allows Nessus to generate useful reports. Plugin 66334, for example, is money. That plugin reports a consolidated, minimalist patch list that you need to remediate everything on the system in question. Apply every update that plugin tells you, and if every update works, your next scan on that system will be 100% informational findings.
Port scans with Nessus
The simplest evaluation to set up is the port scan, because it doesn’t require a user account. Just feed Nessus an IP address, and it goes to town. Port scanning works by checking to see what ports on a system are answering. Then Nessus queries each port to see what’s running on them. Many services just flat out announce themselves by name and version number. Those are easy to evaluate. If a web server announces itself as running Apache 2.4.14, all Nessus has to do is report any vulnerabilities it knows about that are associated with Apache 2.4.14, and eliminate anything from Apache 2.4.13 or earlier.
Some services don’t announce themselves. In those cases, Nessus has to prod a little, usually by sending common traffic to those ports and looking for a response. If you get cute and put SSH on port 25, it won’t fool Nessus, because it’ll try all the other common types when it sees port 25 isn’t responding correctly to SMTP.
These checks are tricky, because Nessus has to look for nuances in how various versions of software respond. Sometimes there aren’t any tell-tale signs, in which case Nessus may miss something.
Finally, in some cases Nessus will fuzz the ports. This could mean sending garbage, or it can mean sending something very closely resembling an exploit to the port. Then it evaluates the behavior. The response can sometimes reveal a vulnerable service.
Problems with port scanning
The biggest problem with port scanning is software that doesn’t listen on ports. You can’t evaluate Microsoft Word, for example, through port scanning.
The other problem is false positives and false negatives. Oracle Weblogic, for example, doesn’t report the minor version numbers. For example, there are known vulnerabilities in Weblogic 12.1.3.0.0. But when you scan Weblogic, it just reports 12.1.3, leaving off the last two numbers. So if you patched Weblogic, a port scan doesn’t tell you it’s fixed.
It’s also entirely possible to configure some Unix services to report something other than what they are. So you can make Apache report that it’s running version 2.4.1 when it’s actually running 2.4.13. There was a time when this was considered a good practice. That was 20 years ago, but some people still do it. This won’t fool a file scan, but it fools a port scan every time.
How Nessus detects vulnerabilities in files
File scanning requires an account for Nessus to log in, and the account really needs privileged access, such as administrator or sudo access, to work. This makes people uncomfortable sometimes, but Nessus isn’t a penetration test. It’s a scan, intended to verify whether your patching system worked.
By logging in and looking at configuration files and evaluating the binaries, Nessus can do a much more thorough job. If a vulnerability is mitigated due to the system’s configuration, Nessus can evaluate and report that. If the operating system thinks the patch applied but some other process reverted the vulnerable file after the fact, Nessus will find that. It also doesn’t matter whether the application listens to the outside world, since Nessus has the inside view at this point. This dramatically reduces false positives and false negatives. More importantly, the results column in the output tells you exactly what Nessus found so you can pinpoint the file that’s causing the problem.
This is why authenticated scanning is much, much more preferred. It’s more thorough, it’s usually easier on the system, it may take less time, and the results give far more useful detail.
David Farquhar is a computer security professional, entrepreneur, and author. He started his career as a part-time computer technician in 1994, worked his way up to system administrator by 1997, and has specialized in vulnerability management since 2013. He invests in real estate on the side and his hobbies include O gauge trains, baseball cards, and retro computers and video games. A University of Missouri graduate, he holds CISSP and Security+ certifications. He lives in St. Louis with his family.