|
|
Snort Forums Archive
Archive Home » Snort Development » Snort, viruses, and encrypted connections
Please note that the categories listed below represent an archived version of our forums pages. To view the current version and be able to post and reply to threads, please register and login here to go to the full forums pages.
[ Notice: Full Version of This Topic ]
Snort, viruses, and encrypted connections
Posted by bluefoxicy on April 10, 2005 22:54:45
virus.rules sucks.
virus.rules is an idiotic idea.
Snort should not have a rules file for viruses.
HOWEVER, it would be nice if snort could scan for viruses.
Given the above four points, it stands to reason that we need a way to scan for viruses. With the 2.3 release having IPS capabilities, snort could even drop viruses on various types of traffic (email, http, etc), or simply corrupt the virus code (replace all or part of it with XXXXXXX).
Having the snort team maintain rules for viruses is totally retarded. It's not VRT's job to hunt viruses and write such rules. However, a more permenant solution may be viable and acceptable for snort.
Enter libclamav. Clam Antivirus brings an antivirus library. With the proper tuning and some development, snort could use ClamAV to scan for and drop or destroy viruses. This would satisfy any user complaints about wanting virus checking in snort, and hand off all maintenance to the ClamAV project. As ClamAV has its own database maintained by the project itself anyway, this is simply preventing duplicate work.
Virus rules should be configurable per connection type (http? IMAP? port 440? what?) to a point. They should be fairly simple, allowing rules to destroy, drop, reject, or log "if a virus is found." The ambiguous "virus" is determined by offloading that exact determination to libclamav.
Note that this makes another interesting idea: Snort web/e-mail plug-ins. AV plug-ins are somewhat common in the Windows world; but imagine instead of scanning for a "virus," content is downloaded to a buffer (HTML, png, gif, flash), then run through a plug-in which uses a snort library to scan for violations and alert the user before the data (web, flash, etc) is even processed.
Not only old, but new, non-heuristics matching attacks with new (self-decrypting?) shellcode that an AV would miss would be found. Having Snort at the browser or email client level would catch encrypted content by scanning and sanitizing after it's been decrypted, meaning the user's own processes do it without logging to the system (privacy). Combined with integration with ClamAV, this would make a snort plug-in a very powerful privacy protection tool for web and e-mail clients above and beyond a generic snort IDS/IPS. |
|
Posted by lubo on April 11, 2005 01:09:58
get a proxy for that..
imagine snort tracking all the tcp sessions buffering all the files going through.. I just can't imagine the memory requirements for that..
not to speak of network response.. a file check in fastest AVs take a moment and if you have a few hundred users browsing web with 10-20 files per session you would have quite a queue for AV checks..
anyway.. virus rules may serve at least as display of snort capabilities and if you don't want it.. disable it.. i would do that if there are performance problems.. |
|
Posted by bluefoxicy on April 11, 2005 08:41:48
Virus rules in snort are "E-mail attachments are evil" :)
I didn't think buffering the whole thing would be necessary. Wouldn't there be a more conservative approach? Parse each packet, if one ends in a partial virus signature buffer it and wait for the next. If they match, trash them. Isn't that how snort matches anyway? (If a rule looks for data that cuts out halfway at the end of the packet, it has to hold that and look at the next packet for the snort_inline module to actually drop it).
In the case of a browser or email plug-in, a full buffer would of course be done; but that's not something that'd actually be a priority anyway (are we going to make AV and IPS plug-ins for everything in the life of computers? Maybe Majonng needs one too to check for corrupt high scores!).
I'm more interested in streams-- i.e. streaming mp3 or ogg vorbis-- that virus scanning files. |
|
Posted by lubo on April 12, 2005 03:48:39
no..
at least the last time i've read the sources processing is done per packet.. stream reassembly and matching is not very feasible when thinking of memory issues (you have to keep the streams in memory).
and again.. if you need to scan the content for viruses use a proxy..
it does reassemble and it can drop the stream when it contains a virus..
dont' try to handle whole security with snort.. :) |
|
Posted by bluefoxicy on April 12, 2005 11:51:24
So what if a program (attacking) forcibly fragments a packet in the middle of the byte sequence that snort matches in the rule? Can the rule be evaded?
alert tcp $EXTERNAL_NET 27374 -> $HOME_NET any (msg:"BACKDOOR subseven 22"; flow:to_server,established; content:"|0D 0A|[RPL]002|0D 0A|"; reference:arachnids,485; reference:url,www.hackfix.org/subseven/; classtype:misc-activity; sid:103; rev:7;)
So two packets
content:"|0D 0A|[RPL]002|" and "0D 0A|"
or whatever. Can crafty fragmentation evade this rule? |
|
Posted by wmetcalf on April 22, 2005 16:21:29
bluefox,
We have already written a ClamAV preproc for snort, we actually just completed it for 2.3.2 but lubo is correct, it is not meant for scanning e-mail. I'm not even sure how you would implement such a beast. If you want it let me know, as I was having problems posting the patch to the snort-inline sf page. In regards to your question about fragments, as long as you are doing state tracking via the NEW,RELATED,ESTABLISHED keywords your are already doing fragment reassembly or at least iptables is doing it for you. |
|
Posted by bluefoxicy on May 09, 2005 06:22:22
It's for another forum, but I do need to find out how the hell stateful filtering works in iptables and some tips on that. Got a linku to a nice explaination? |
|
Posted by roesch on June 28, 2005 12:18:22
Just for the record, Snort is stateful and includes both IP defragmentation and TCP stream reassembly.
I'd be interested in seeing what kind of performance Snort can maintain running the ClamAV preprocessor on a beefy piece of equipment.
-Marty
|
|
|
|