Actually speaking of Suricata feature reaquests can I suggest the following 2 things for some ideas I had:<br><br>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.<br>
<br>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. <br>
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 <a href="http://blogs.cisco.com/security/network-based-file-carving/">http://blogs.cisco.com/security/network-based-file-carving/</a> which is more reliable at it file carving is very useful in providing context. <br>
<br>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.<br>
<br>What do people think? No idea of feasibility or practicality, just some jumbled ideas.<br><br><br><br><br><br><div class="gmail_quote">On 31 January 2011 19:28, Matthew Jonkman <span dir="ltr"><<a href="mailto:jonkman@emergingthreatspro.com">jonkman@emergingthreatspro.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">As you may recall, Alienvault (<a href="http://www.alienvault.com" target="_blank">http://www.alienvault.com</a>), the home of OSSIM, has very generously offered to the snort and suricata communities the classification system they've developed to better categorize and react to IDS events. We're excited about this, especially in suricata, and we have already begun the changes required to allow us at Emerging Threats Pro and Emerging Threats Open to distribute the rulesets in both forms.<br>

<br>
We had called an end to comments by Jan 12, but discussion has continued mostly privately. A few points to iron out yet:<br>
<br>
1. Sourcefire has proposed to change all underscores to dashes.<br>
I feel the underscores are an important differentiator. But older snort's may not handle that well. Suricata will handle them fine. But having differing systems is going to be a challenge of course.<br>
<br>
2. Sourcefire also proposes to lower-case everything.<br>
Shouldn't be a big deal if no one objects.<br>
<br>
3. We also need to assign priorities to the events. Sourcefire in the link below has proposed how they might look. We need feedback there.<br>
Perhaps we put up a simple web app to let folks go through and prioritize and we can take the average over a few weeks of input?<br>
<br>
-----------<br>
<br>
Initial posts are here:<br>
<a href="http://blog.emergingthreatspro.com/2010/12/new-classification-system-proposal.html" target="_blank">http://blog.emergingthreatspro.com/2010/12/new-classification-system-proposal.html</a><br>
<br>
and here:<br>
<a href="http://blog.snort.org/2011/01/classification-comments.html" target="_blank">http://blog.snort.org/2011/01/classification-comments.html</a><br>
<br>
The actual system is here as proposed by Alienvault:<br>
<br>
<a href="http://www.emergingthreats.net/new_classifications_v1.txt" target="_blank">http://www.emergingthreats.net/new_classifications_v1.txt</a><br>
<br>
And a version proposed by Sourcefire.<br>
<a href="http://www.snort.org/assets/157/classifications.txt" target="_blank">http://www.snort.org/assets/157/classifications.txt</a><br>
<br>
-----------<br>
<br>
I propose these steps as a way forward:<br>
<br>
1. Lets get more feedback on the lists (the snort lists, the oisf lists, and the emerging lists).<br>
<br>
2. We have an OISF brainstorming session at RSA in a week and a half (<a href="http://www.openinfosecfoundation.org/index.php/component/content/article/34-general-content/109-the-next-oisf-brainstorming-meeting" target="_blank">http://www.openinfosecfoundation.org/index.php/component/content/article/34-general-content/109-the-next-oisf-brainstorming-meeting</a>)<br>

This is on the agenda there, lets get some more discussion and we will summarize this on the lists<br>
<br>
Lets call the End of February the final date, adopt an official classification.conf and move forward!<br>
<br>
Matt<br>
<br>
<br>
<br>
----------------------------------------------------<br>
Matthew Jonkman<br>
Emergingthreats.net<br>
Emerging Threats Pro<br>
Open Information Security Foundation (OISF)<br>
Phone 765-807-8630<br>
Fax 312-264-0205<br>
<a href="http://www.emergingthreatspro.com" target="_blank">http://www.emergingthreatspro.com</a><br>
<a href="http://www.openinfosecfoundation.org" target="_blank">http://www.openinfosecfoundation.org</a><br>
----------------------------------------------------<br>
<br>
PGP: <a href="http://www.jonkmans.com/mattjonkman.asc" target="_blank">http://www.jonkmans.com/mattjonkman.asc</a><br>
<br>
<br>
<br>
_______________________________________________<br>
Emerging-sigs mailing list<br>
<a href="mailto:Emerging-sigs@emergingthreats.net">Emerging-sigs@emergingthreats.net</a><br>
<a href="http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs" target="_blank">http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs</a><br>
<br>
Support Emerging Threats! Subscribe to Emerging Threats Pro <a href="http://www.emergingthreatspro.com" target="_blank">http://www.emergingthreatspro.com</a><br>
The ONLY place to get complete premium rulesets for Snort 2.4.0 through Current!<br>
</blockquote></div><br>