Re: Option for one-line "raw" packet dump (ascii and hex) in alert_fast output module

["Ed Borgoyn (eborgoyn)" <eborgoyn () cisco com>]

Hello Roberto,

  Thank you for the Snort imporvement recommendation and patch.  I cannot say for certain that it will be incorporated 
into the snort codebase.  But we will add your request and patch to the snort feature request log.

    Best Regards,
    Ed Borgoyn
    Cisco Snort Development Team


From: Roberto Moreda <moreda () allenta com<mailto:moreda () allenta com>>
Date: Wednesday, October 7, 2015 at 7:29 PM
To: "snort-devel () lists sourceforge net<mailto:snort-devel () lists sourceforge net>" <snort-devel () lists 
sourceforge net<mailto:snort-devel () lists sourceforge net>>
Subject: [Snort-devel] Option for one-line "raw" packet dump (ascii and hex) in alert_fast output module

Hi, all.

I hope I'm not bringing up an old or closed subject. I made some searches and I couldn't find anything clear about my 
problem :-)

For some time I have been using Snort as a source of "security events" for several log consolidation or SIEM systems. 
Most of those systems assume one-line alerts as input, with the minimal info (i.e. name/id of the signature, severity, 
category, source and destination). The problem is that analysts usually would like to have the payload of the package 
to assess false positives at once.

In order to not interfere with the usual "field recognition patterns" of such systems, I opted to extend the alert_fast 
output module this way:

...
output alert_fast: [<filename> ["packet"|"packetraw"] [<limit>]]

* packetraw: this option will cause brief single-line entries
                 to be logged with the content of the packet in raw format (ascii and hexadecimal
                 dumps) appended.
...

This is absolutely backwards compatible, not affecting current Snort configurations.

The result with the "packetraw" option in the alert_fast output module configuration, should be one line per alert as:

10/08/15-01:03:16.909442  [**] [3:21355:4]  <eth1> PROTOCOL-DNS potential dns ca
che poisoning attempt - mismatched txid [**] [Classification: Attempted Informat
ion Leak] [Priority: 2] {UDP} XX.XX.XX.XX:53 -> YY.YY.YY.YY:12563 ...z[...]  0001D77A[...]

Note that the ...z[...]  0001D77A[...] is shortened on purpose, but the idea is basically what's shown. Once again, 
this should be backwards compatible with sane parsers in most of log consolidation or SIEM systems *and* appends the 
ascii and hexadecimal dump of the raw packet to each event, offering a great way to assess false positives and make 
accurate general searches.

I wrote a patch against 2.9.7.6 to enable this behaviour, that you can see 
here<https://github.com/moreda/snort/compare/2.9.7.6...2.9.7.6-packetraw> in a fancy format or download 
here<https://github.com/moreda/snort/compare/2.9.7.6...2.9.7.6-packetraw.diff> ready to apply.

I know that the general idea is to avoid extra logic in the output modules, letting other processes to cope with 
unified2 to convert data to whatever format... but I'm pretty sure that this tiny addition could lower complexity in 
many deployments allowing to have payload info in a very simple way.

Please, feel free to criticise, correct or comment about my proposal.
Thank you very much!

  Roberto

------------------------------------------------------------------------------

_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel
Archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel

Please visit http://blog.snort.org for the latest news about Snort!