[Snort-users] Homebrew Snort Reactive/Unified2 output
Korodev
I'm trying to implement a proof-of-concept system that will "react"
based on snort alerts. In short, once Snort detects an alert, I have a
C lines that I would like executed as *quickly* as possible. There
seem to be several points of insertion for this. First, would be
modifying the unified2 output plugin to do some custom work as well as
maintain normal unified2 output. Second, would be to modify a BY2
output plugin (this seems to be what the Snort team suggests), but
given that speed is a factor, picking it up right out of Snort is
ideal. Does homebrew take a time-based polling approach to unified2
files? I quickly browsed through the source and saw no indication
otherwise.
I suppose the last option would be to write my own unified2 parser,
but I really don't have that much time on my hands. As I understand
it, the best/only documentation of the unified2 output format is the
snort source code..is that correct?
Suggestions?
\\korodev
------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
_______________________________________________
Snort-users mailing list
Snort...@lists.sourceforge.net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users
Jefferson, Shawn
Jefferson, Shawn
Korodev
Hadn't seen that...I'll check it out.
Thanks,
Martin Holste
http://code.google.com/p/snort-unified-perl/ . At the very least,
most of the constants and byte conversions are well documented there.
Why is speed a factor? Are you trying to issue RST packets or issue
firewall blocks/ACL rules? If you want to kill an active connection,
I don't think anything reading Snort's output will be reliably fast
enough unless the connection is a rather large file download. If
you're not trying to kill the connection, then a few milliseconds
difference between having a script do the reading and having something
more built-in do the reading won't matter, and you should go with the
ease-of-use of the script.
waldo kitty
> Why is speed a factor? Are you trying to issue RST packets or issue
> firewall blocks/ACL rules? If you want to kill an active connection,
> I don't think anything reading Snort's output will be reliably fast
> enough unless the connection is a rather large file download. If
> you're not trying to kill the connection, then a few milliseconds
> difference between having a script do the reading and having something
> more built-in do the reading won't matter, and you should go with the
> ease-of-use of the script.
you expressed the above quite well for my side of the fence ;) the old guardian
script does quite well in my environment with the current improvements and
updates made to it in the last few years and it is little more than a perl
script running as a daemon ;)
beenph
something that will parse unified2?
-elz
On Wed, Mar 30, 2011 at 6:56 PM, Korodev <kor...@gmail.com> wrote:
>> Why is speed a factor? Are you trying to issue RST packets or issue
>> firewall blocks/ACL rules? If you want to kill an active connection,
>> I don't think anything reading Snort's output will be reliably fast
>> enough unless the connection is a rather large file download. If
>> you're not trying to kill the connection, then a few milliseconds
>> difference between having a script do the reading and having something
>> more built-in do the reading won't matter, and you should go with the
>> ease-of-use of the script.
>
> Thanks for the link Martin. Speed is a factor because I would like to
> be able to issue a firewall rule that could be a pipe divert, delay
> queue, block, or something similar. With my current piping/delay
> setup, I can afford ~15ms of time.
>
> \\korodev
Martin Holste
could have it log to a (local) network destination, which would
eliminate the 4-8 ms of disk access time for a unified write/read.
That's probably preferable, because most of the unified readers have a
polling mechanism to check for new entries; they are not async and so
you may be getting the new entries up to a second or two late.
Could a custom plugin be faster than the syslog plugin? It's so
simple that I'm not sure there's much to strip out.
Martin Roesch
> Hey guys,
>
> I'm trying to implement a proof-of-concept system that will "react"
> based on snort alerts. In short, once Snort detects an alert, I have a
> C lines that I would like executed as *quickly* as possible. There
> seem to be several points of insertion for this. First, would be
> modifying the unified2 output plugin to do some custom work as well as
> maintain normal unified2 output. Second, would be to modify a BY2
> output plugin (this seems to be what the Snort team suggests), but
> given that speed is a factor, picking it up right out of Snort is
> ideal. Does homebrew take a time-based polling approach to unified2
> files? I quickly browsed through the source and saw no indication
> otherwise.
>
> I suppose the last option would be to write my own unified2 parser,
> but I really don't have that much time on my hands. As I understand
> it, the best/only documentation of the unified2 output format is the
> snort source code..is that correct?
>
> Suggestions?
At the risk of getting into a pilosophical discussion...
The absolute fastest place to fire a response post-detection would be
an output plugin. There's no need to hook the U2 output plugin or
write an output module for BY2, depending on a number of factors
you're not going to get the absolute fastest activation time for your
code from the point of detection.
If I was going to do it (and I thought that triggering responses
automatically based on raw IPS output was a good idea, it generally
isn't) I'd be writing an output plugin for Snort. As Martin
mentioned, starting off by looking at the syslog output plugin would
be a good place to get started.
Marty
--
Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
Sourcefire - Security for the Real World - http://www.sourcefire.com
Snort: Open Source IDP - http://www.snort.org
Martin Roesch
>> At the risk of getting into a pilosophical discussion...
>>
>> The absolute fastest place to fire a response post-detection would be
>> an output plugin. There's no need to hook the U2 output plugin or
>> write an output module for BY2, depending on a number of factors
>> you're not going to get the absolute fastest activation time for your
>> code from the point of detection.
>
> discussion, I'm not only interested in IPS style responses, but simply
> interested in getting a 'heartbeat' signal as soon as an alert has
> tripped. My only reason for implying hooking the U2 output plugin, was
> my desire to preserve U2 output for later processing. I feel like I'm
> being directed away from that, but not sure why (?) I haven't played
> with Snort's output plugins in the past, so this will be a beneficial
> exercise.
That's cool. You can have multiple output plugins active at the same
time so it's not necessary to do anything to the U2 plugin, you can
just run it alongside whatever plugin you write (via the snort.conf
file) and they'll be called sequentially.
beenph
on output plugging
(this is why its recommended not to use db output pluggin straight
from snort because in some cases a database write could block for xyz
reason)
Then you will halt packet processing and this could lead to packet drops.
The faster you process the faster snort can go back and do its job.
On Thu, Apr 7, 2011 at 9:59 AM, Korodev <kor...@gmail.com> wrote:
>>>> The absolute fastest place to fire a response post-detection would be
>>>> an output plugin. There's no need to hook the U2 output plugin or
>>>> write an output module for BY2, depending on a number of factors
>>>> you're not going to get the absolute fastest activation time for your
>>>> code from the point of detection.
>
> In follow up to this discussion, I've started working on my output
> plugin and had a few questions in regards to what happens to alert
> data between inspection about output processing. In short, I plan on
> running dual output plugins (custom and unified2) and am interested to
> know what kind of effects to watch for if my custom output plugin is
> to slow. What happens if an event is sent to the output plugin, but
> the output plugin hasn't finished processing the previous event. Is
> there a queueing mechanism implemented here that will lead to a memory
> usage spike? Just trying to figure out what sort of things to watch
> for in my testing.
>
> \\korodev
>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> Snort-users mailing list
> Snort...@lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> https://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
Korodev
> what you describe, you would not be reacting in real-time anyway and packets
> have already made it through, regardless of reacting using an output plugin
> or spooling off of U2 files. The obvious benefit of spooling off of U2
> files is that it's snort version independent and does not require you to
> patch / maintain changes to the snort source every time a new version comes
> out.
>
> Just my .02
> JJC
Thanks for your input. I'm thinking spooling off U2 files in the end
will probably be the best solution, but I would like to experiment
with the output plugin. However, the common polling approach when
dealing with the U2 files won't work very well to achieve the desired
goals, so I'll have to implement some sort of async solution using
kqueue or something similar in FreeBSD.