[Oisf-users] [Emerging-Sigs] New Classification System Finalization

[Edward Fjellskål]

On 02/01/2011 05:21 PM, Kevin Ross wrote:
> Actually speaking of Suricata feature reaquests can I suggest the
> following 2 things for some ideas I had:
> 
> 1) The option to have the session as an alert as a rule option. Or being
> able to configure it somewhere for rules, so for instance rather then
> just seeing the single packet you can see everything sent to the client
> in that session, both client/server communication in that session or
> something in the alert. I know you can do it with tags in a messy kind
> of way but something easier that is in between full packet capture and
> the single packet alerts would be useful to have in single alerts if
> desired. Even a config option so people can enable it if that have the
> spare memory with sids such as session:all,to_client,to_server and then
> have another thread deal with this.
> 
> 2) The option to specifiy a path to save these files too and then have
> rule options or config options which say extract_pdf, extract_exe etc so
> if an alert fires, say for the newplayer exploit and extract_pdf was in
> the rule (or a config option like extract_pdf then sids) that the PDF
> file would be carved out of the session and saved before the reasembled
> session was cleared or whatever. Same could be done with exe files and
> other files.
> This means say the javascript in PDF sig fired, you could have the PDF
> on disk so that you can decompress streams, analyse, scan with AVs or
> whatever else. This would obviously need to be an additional feature as
> I imagine it would need more resources to hold the sessions and if an
> alert is fired on them for .exe files, .pdf files etc then it would have
> to carve the file out. Using tools like tcpxtract or nfex
> http://blogs.cisco.com/security/network-based-file-carving/ which is
> more reliable at it file carving is very useful in providing context.
> 
> Again another thread within suricata or even something else could be
> used to go back over the session and carve out the file to disk. It
> could even save short term PCAPs to disk and then go over them with
> session filters and extract the files from the session that the alert
> was generated on so the capture is on disk for a short time rather than
> in memory. For exes for some people they may want to carve out certain
> suspicious small executables with the policy sigs or even all
> executables and then have a script run clamav or something, move
> infected files into another folder and then delete the others.
> 
> What do people think? No idea of feasibility or practicality, just some
> jumbled ideas.

I did something like this in a Proof of Concept...

I use openfpc, which can parse nftracker syntax. So when I see a .pdf or
.exe, I send the command to openfpc-client so it can extrackt the
pcap from daemonlogger. My test system handles too little traffic to
have any problem with performance, but if you have spare memory, you
could make a filesystem in memmory (ramfs/tmpfs).

When you have the pcap of the session, you can carve the file, md5/sha
sum it and check it agains virustotal/shadowserver/wepawet and if no
hits, ClamAV it or send it through you mail-infrastructure that might
have commercial antivirus software :)


---
nftracker: https://github.com/gamelinux/nftracker/blob/master/README
(you could write rules for suricata/snort - but I wrote an app instead:)

openfpc: http://www.openfpc.org/

daemonlogger:
http://www.snort.org/users/roesch/Site/Daemonlogger/Daemonlogger.html

ramfs/tmpfs:
http://www.thegeekstuff.com/2008/11/overview-of-ramfs-and-tmpfs-on-linux/