Snort mailing list archives
Re: Intel X520 and Multi-Queue Snort
From: beenph <beenph () gmail com>
Date: Fri, 13 May 2011 17:16:36 -0400
Actually, I take that back--TCP analysis would tell you if you're dropping packets, but that would be expensive to compute (comparatively) and frequently wrong. In any case, I think we have different ideas about the "core" of the problem. You seem to be saying that the "core" to you is getting packets from the wire to Snort. To me, the most important issue is whether I'm actually inspecting the traffic I think I am, which includes the entire supply and output chain for Snort. It's a first indicator, and does require more fine-grained stats from things like DAQ to fully investigate.
If a span drop traffic its a span issue. And if you know that some of the ports your monitoring are overloading your span , mabey you could rething how your monitoring goes. What you call the entire output chain of snort also includes the time it takes from detection to logging and this type of backlog can't be detected by a simple singature heartbeat (unless you also encode some information that is parsed while processing the specific signature by a compiled rule or others means that requires code).
I will say, however, that I've learned not to trust a single counter on the Snort box, kernel or otherwise. I've even been burned on Cisco counters before. That's when I decided enough was enough, I didn't care about the exact tenths of a percent being dropped, I just wanted the actual truth for a change: if a URL is requested matching a given pattern, will I know about it?
Counter is a counter, computers are computers, human interpreting information is something else. Everyone can be fooled by a computer if they do not take the time to check if they lie.
My main question would be if your sniffing outside at the edge of your network, do to sniff inside also?No, gateway only. Intra-datacenter IDS has an incredibly small payoff for a huge amount of time and money. Monitoring internal client-server traffic is most easily done with comprehensive audit logging and network flows.
Ah ... i guess it all boils down to perception and conception. I allways had the impression that its easyer to monitor 50 little streams than a huge convergent stream.
Once you get all of that implemented, then you can worry about putting IDS between your clients and servers. Getting events forwarded from your Windows boxes to a central location is a far more worthwhile investment--especially when you see the granularity that Server 2k8 gives you (per-packet connection stats, better process auditing, etc.).
Perf monitor has been there since NT... (and it was to generate events back then also).
If you have all of that and are still bored, have fun digging through the mountain of FP's that your legit business traffic generates. I'm not saying it's impossible to do, just do it last because it's the most work with the least amount of payoff. At the end of the day, don't you really want to know what an attacker was doing anyway? Process accounting logs can give you incredible insight into that. Database logs can tell you when tables were altered, etc., etc.
Im sure you have enough FP with ~7kish signature enabled on the internet i understand your concern. Anyways im stepping out of this since i guess its quite turned as an offtopic issue Which i wouldn't mind to speak of off-list. Sorry s-usr readers. -elz ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Snort-users mailing list Snort-users () 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
Current thread:
- Re: Intel X520 and Multi-Queue Snort, (continued)
- Re: Intel X520 and Multi-Queue Snort Will Metcalf (May 12)
- Re: Intel X520 and Multi-Queue Snort Mike Lococo (May 12)
- Re: Intel X520 and Multi-Queue Snort Martin Holste (May 13)
- Re: Intel X520 and Multi-Queue Snort Mike Lococo (May 13)
- Re: Intel X520 and Multi-Queue Snort Martin Holste (May 13)
- Re: Intel X520 and Multi-Queue Snort Mike Lococo (May 13)
- Re: Intel X520 and Multi-Queue Snort beenph (May 13)
- Re: Intel X520 and Multi-Queue Snort Mike Lococo (May 13)
- Re: Intel X520 and Multi-Queue Snort beenph (May 13)
- Re: Intel X520 and Multi-Queue Snort Martin Holste (May 13)
- Re: Intel X520 and Multi-Queue Snort beenph (May 13)
- Re: Intel X520 and Multi-Queue Snort Mike Lococo (May 13)