pcap for Snort

8b2b86ac

There are some pcap files in /var/log/snort/snort_igb* that seem related to some of the alerts but most alerts do not seem to generate pcap data. Is there a setting so that all alerts store the packets that generate the alert. I would like to view them in Wireshark to help identify what service is triggering the alter so I can make the necessary changes to reduce false positives.

bmeeks

I just checked into the PHP code for the Snort GUI, and unfortunately the command line options for turning on full packet logging are incomplete. I will need to make some adjustments to the GUI code. Formerly, folks used Barnyard2 for alert logging and that would place some alert data into the binary unified2 logging format. However, Barnyard2 is effectively no longer maintained in the FreeBSD ports tree and will need to be removed as an option in the Snort package .

So long story shortened, give me a litte time to look into adding the option of full packet logging to the GUI configuration screen for an interface. Just be aware there will be a performance impact from this, and the logged data will be in tcpdump binary format and not standard pcap form.

8b2b86ac

@bmeeks thanks for looking into this! I'd be ok with the performance hit. I'm just using it while I identify false positives on my network. I'm not sure what the turnaround time is for updating the GUI but I imagine not instance. Any chance you could point me to the relevant snort config settings in the meantime? That way I can make the adjustments via the shell until the GUI fully supports it.

Once again, thanks!

bmeeks

@8b2b86ac said in pcap for Snort:

@bmeeks thanks for looking into this! I'd be ok with the performance hit. I'm just using it while I identify false positives on my network. I'm not sure what the turnaround time is for updating the GUI but I imagine not instance. Any chance you could point me to the relevant snort config settings in the meantime? That way I can make the adjustments via the shell until the GUI fully supports it.

Once again, thanks!

You can try pasting this output configuration info into the Advanced Configuration Pass-Through text box at the bottom of the INTERFACE SETTINGS tab for the interface where you want packet captures.

# pcap logging
output log_tcpdump: tcpdump.log 128M

After pasting in the configuration, click Save and then restart Snort on that interface. The example configuration I provided should write the packet caps to the file tcpdump.log.xxxxx where xxxxx will be a Unix timestamp. The file(s) should be created in the logging directory under /var/log/snort/ for the interface. When the packet capture exceeds 128 MB in size, Snort will rotate it and start a new file. You can set whatever file size you want by varying the 128M value ("M" means megabytes. Use "K" for kilobytes). This feature will chew up disk space quickly, so make sure you configure the LOG MGMT tab features to enable logs management and set a reasonable limit on the event pcaps parameter on that tab.

NogBadTheBad

@8b2b86ac said in pcap for Snort:

There are some pcap files in /var/log/snort/snort_igb* that seem related to some of the alerts but most alerts do not seem to generate pcap data. Is there a setting so that all alerts store the packets that generate the alert. I would like to view them in Wireshark to help identify what service is triggering the alter so I can make the necessary changes to reduce false positives.

FWIW I had the following configured when I was trying to debug odd dns lookups, it might help as it would only do a pcap when the custom rule was hit:-

Advanced Configuration Pass-Through

ruletype pcap
{
type alert
output alert_syslog: LOG_AUTH LOG_ALERT
output log_tcpdump: pcap.cap
}

custom.rules

pcap udp any any -> any 53 ( msg:"ns.hetsptt.net.cn"; flow:to_server; byte_test:1,!&,0xF8,2; content: "|02|ns|07|hetsptt|03|net|02|cn|00|"; nocase; sid:20000010; rev:001;classtype:string-detect;)

http://manual-snort-org.s3-website-us-east-1.amazonaws.com/node1.html

bmeeks

@NogBadTheBad's suggestion will use much less disk space by capturing only targeted packets. His method uses targeted rules via a custom "ruletype" defininition. You create your own custom rules and reference your custom ruletype in their headers.

Details are here in the Snort docs: http://manual-snort-org.s3-website-us-east-1.amazonaws.com/node29.html.

The method I gave you will capture packets for all alerts. So which method you choose to use is determined by your purpose of capturing. If there are only a few rules you are considering evaluating indepth to test for false positives, then I would create a custom ruletype as @NogBadTheBad suggested and then copy the entire text of the rules you want to evaluate into the Custom Rules dialog on the RULES tab. Just make sure you change the SIDs of each rule to a high number so as not to have duplicate SIDs. You cannot duplicate SIDs in Snort rules. When copying the rules into the Custom Rules dialog, change the rule action from ALERT to PCAP or whatever custom ruletype you choose and define in the Pass-Through configuration.

NogBadTheBad

@bmeeks

That's exactly what I was thinking Bill.

Do custom rules take precedence over existing enabled rules if the only difference is the SID?

bmeeks

@NogBadTheBad said in pcap for Snort:

@bmeeks

That's exactly what I was thinking Bill.

Do custom rules take precedence over existing enabled rules if the only difference is the SID?

No, I would not think the custom rules have any precedence over other rules. The only precedence configuration I am aware of is the "pass alert, etc.," setting in snort.conf. There is a config section in that file where you can specify if Snort should process PASS rules first or DROP rules first, for example. But Snort is not like the firewall where first rule to match wins and then evaluation stops. Packets are evaluated against all Snort rules no matter. The only "verdict" that has any precedence is PASS, DROP or REJECT.

NogBadTheBad

@bmeeks

So two alerts then, one with a packet capture.

bmeeks

@NogBadTheBad said in pcap for Snort:

@bmeeks

So two alerts then, one with a packet capture.

As configured per your example, yes. But I would not be surprised if you could eliminate the second alert in the logs by changing the ruletype definition for "pcap" to this:

ruletype pcap
{
type alert
output log_tcpdump: pcap.cap
}

Snort would still process it like a normal alert, but would only packet capture when that rule was triggered instead of logging and packet capturing. I have never tested this, but it seems plausible.

bmeeks

This feature is coming in the next Snort package update. The packet captures will be in tcpdump format as that results in more efficient logging from Snort. The files will be written as "snort.log" in the interface logging subdirectory under the /var/log/snort/ main Snort logging directory.

The pull request for this update for pfSense-2.4.5 is posted here: https://github.com/pfsense/FreeBSD-ports/pull/871. A similar update for the Snort-4.x package available for pfSense-2.5 DEVEL is posted here: https://github.com/pfsense/FreeBSD-ports/pull/872.

8b2b86ac

@bmeeks What a fast turnaround! Thanks so much for the work.