Re: Intel X520 and Multi-Queue Snort

[Martin Holste <mcholste () gmail com>]

> 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