If you can't find an answer to your question here why then get in touch via the mailing list and we'll get cracking on it. You can also send as a private message if you would like. See the contacts page for details.
NSM is not a new term and it's not one credited to the Knoppix-NSM developers. Our first introduction to NSM was through the Intrusion Analsyis Tool "Sguil" and "The Tao Of Network Security Monitoring: Beyond Intrusion Detection". If you want to find out more information about NSM I suggest you check out Richard Bejtlich's TAO Security website or book "The Tao Of Network Security Monitoring". More information about sguil can be found on our tools page or the sguil website.
Q.
Why can't I extract transcripts or wireshark logs?
A.
This is due to an time inconsistency between the server and sensor components, where the server is attempting to retrieve information from the capture files during a period that is inconsistent. Since Snort can log in either UTC or the localtime, it is very important to ensure that when components are stored on separate machines that all machines are synchronised together in terms of UTC and timezone (if set).
This can be done by either setting the timezone on all machines to UTC or alternatively to set the timezone on all machines to the same and remove the \$UTC variable from the OPTIONS variable in the following init scripts:
/etc/init.d/snortu
/etc/init.d/snortl
Q.
It says it's compiling but it's taking an awfully long time. Has it hung?
A.
To keep the display relatively clutter free majority of the output is piped to the log file. This ensures that everything is captured when troubleshooting. This also may appear that nothing is happening. However, you are able to get a full picture of what is going on by tailing the log file.
We do this extensively during testing to get the full picture of what is happening.
$ tail -f ./NSMnow.log
Q.
Where is the sancp data? It keeps saying 0 rows returned.
A.
If your system/distribution has AppArmor installed and is running you will need to ensure MySQL has read access to the files on the local filesystem. This can typically be achieved by adding the appropriate line to the mysql profile
For example on a Ubuntu system, add the following line to the mysql apparmor profile in:
File: /etc/apparmor.d/usr.sbin.mysqld
/nsm/server_data/server1/load/* r,
Q.
How do I update the Snort rules?
A.
NSMnow is designed to set up the initial framework for a NSM system based around Sguil.
Whilst it does not configure any Snort signature handling tools, we do recommend two excellent tools; oinkmaster and pulledpork. The latter addresses some issues of the former particularly with compiled rule sets and so is our preferred choice.
The process for updating the rules for snort has two distinct parts, updating the rules for the sensor and updating the rules for the server. The reason rules exist on the server are so that Sguil can correlate rule messages to the sensor from which a real-time alert arrives from. If the rules do not correlate clients will be presented with incorrect, or no, information.
So where are these rules stored?
For the sensor(s) they will be stored under: /etc/nsm/sensorname/rules, where "sensorname" is the name of the sensor you're updating the rules for. This is the location that the snort process will use in its processing.
For the server(s), all rule information pertaining to an associated sensor will be stored at: /nsm/server_data/servername/rules/sensorname, where "servername" is the server of interest and "sensorname" is the associated sensor to the server of interest.
Example: If I have a sensor "thor" connected to a server "athena" and wish to update the rules. I will first update the rules on the sensor under that will exist at "/etc/nsm/thor/rules" and ensure the corresponding *.map files are also updated at "/etc/nsm/thor". Secondly I'll ensure the same rules are updated on the server under the "/nsm/server_data/athena/rules/thor".
