NNM Real-Time Plugin Syntax

Real-Time Plugin Model

NNM real-time plugins are exactly the same as NNM vulnerability plugins with two exceptions:

  • They can occur multiple times.
  • Their occurrence may not be recorded as a vulnerability.

For example, an attacker may attempt to retrieve the source code for a Perl script from an Apache web server. If NNM observes this event, it would be logical to send a real-time alert. It would also be logical to mark that the Apache server is potentially vulnerable to some sort of Perl script source code download. In other cases, it may be more logical to just log the attempt as an event, but not a vulnerability. For example, a login failure over FTP is an event that may be worth logging, but does not indicate a vulnerability.

As the real-time plugins are written, there are two keywords that indicate to NNM that these are not regular vulnerability plugins. These are the real-time and realtimeonly keywords.

In the previous example, the FTP user login failure would be marked as a realtimeonly event because we would like real-time alerting, but not a new entry into the vulnerability database.

Real-Time Plugin Keywords




If a plugin has this keyword, then NNM will generate a SYSLOG message or real-time log file entry the first time this plugin matches. This prevents vulnerabilities that are worm related from causing millions of events. For example, the plugins for the Sasser worm generate only one event. Output from plugins with this keyword will show up in the vulnerability report.


If a plugin has this keyword, then NNM will generate a SYSLOG message or real-time log file entry each time the plugin evaluates successfully. These plugins never show up in the report file.


This keyword will cause the contents of a session to be reported (via SYSLOG or the real-time log file) a specified number of times after the plugin containing this keyword was matched. This is an excellent way to discover what a hacker “did next” or possibly what the contents of a retrieved file were real-time.


Normally if a plugin has multiple dependencies, then all of those dependencies must be successful for the current plugin to evaluate. However, the trigger-dependency keyword allows a plugin to be evaluated as long as at least one of its dependencies is successful.