thomas lakofski <[EMAIL PROTECTED]> writes: > > I've considered it, to some extent, but in my case I figured it's best > > just to look at snort's logs in a bit more detail before blocking > > things left right & center. > > yes, familiarity with the traffic patterns you get over a few weeks is > useful for picking out the aberrations.
Well right now I'm having a phase of re-investigating snort in greater depth; I can't believe there really is *no* (working) CGI front-end in which to process stats on postgresql databases storing snort info... so FWIW, after last night, there now is: ObPlug: <http://spodzone.org.uk/packages/network/snort.pl.txt>. Probably untidy, but it produces a really "surf-able" output... > > Whatever automated solution you find, it *must* > > a) allow me to specify some "must-not-block" networks/IP#s, eg upstream > > nameservers, etc > > b) allow me back in after a given amount of time > > c) never block a valid user after a false alarm - just because my snort db > > is filling up with `retransmission attempt's, it doesn't mean that every > > IP# generating an alert wants blocking. (Yes, I've got some tweaking to > > be doing :) > > i think it does all of the above (not used it -- so just going by docs) > -- i would assume that you would be able to choose which alerts to block > -- otherwise eventually you would block a large proportion of the hosts > that you communicate with legitimately. Quite so. The ECN rules (`Queso fingerprint detected'), web/CGI rules (`finger CGI attempt!' - when I had a finger.php3 on my site ;) and so on, all used to combine to send far too many false alarms. > i've got 'preprocessor stream4: noalerts' and 'preprocessor > stream4_reassemble: noalerts' in my snort 1.8 config; i'm not interested > in messages from my stream reassembler... Indeedie. Aye well, we're getting there :) ~Tim -- 14:05:21 up 7 days, 16:04, 14 users, load average: 0.32, 0.23, 0.23 [EMAIL PROTECTED] |Roobarb and Custard let fly http://piglet.is.dreaming.org |with their secret weapon.
