Snort mailing list archives
Re: Intel X520 and Multi-Queue Snort
From: Martin Holste <mcholste () gmail com>
Date: Fri, 13 May 2011 15:18:51 -0500
When i wrote not a real solution, i was refering to signature heartbeat obviously. And the problem i was refering to was "signature heartbeat being a possible solution to packet drops" <- NOT A SOLUTION.
There are plenty of caveats to the heartbeat method. Obviously, if drops occur between heartbeats, they will go unnoticed. I have one minute intervals for my heartbeats, and that has proven to be very helpful. In fact, let's replace the word "solution" which implies being canonical with "helpful." Heartbeats are a helpful ;)
Especially if your "splitting" your traffic.
This is a valid caveat when doing srcip/dstip hashing for load balancing, as if you use the same IP for your heartbeat, you're not getting a look at how other IP pairs are doing. To be more thorough, you would want a lot of heartbeats that would test each destination of the hashing function. Theoretically, sixteen consecutive IP's would hash to sixteen separate PF_RING cluster processes (someone please correct me if I'm wrong on that).
Heartbeats can be implemented different ways, signature heartbeats is an easy implemented solution but it does not really tackle the core of the problem. IMHO.
If a span session is overloaded (which happens frequently when traffic goes > 1 gig), then your DAQ will never know the difference, but a heartbeat has a chance of being dropped. 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. 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?
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. 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.). 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.
If so what type of sensor deployment do you have on the inside vs what your trying to acheive at your network edge.
Put the absolute beefiest security guard you can afford at the door to the wild-wild-west. Audit the hell out of everything else.
Do you also enable everything you can inside? Do you and how do you correlate internal and external alerts?
We correlate external IDS events with internal syslog in a SIEM. ------------------------------------------------------------------------------ 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 Mike Lococo (May 12)
- 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)
- Re: Intel X520 and Multi-Queue Snort Mike Lococo (May 12)