mailing list archives
Re: RE: IDS (was: FW appliance comparison)
From: "Marcus J. Ranum" <mjr () tenablesecurity com>
Date: Mon, 30 Jan 2006 19:21:44 -0500
[This is going to be my last posting in this thread. The sound that
I am hearing in the background sounds suspiciously like the
sound of my head beating against a wall...]
First off, a couple of meta-comments: I've been on this list
since it's inception (I was, after all, subscriber #1) and there
is a paradigmatic exchange of postings that we've all seen
time and again which follows the approximate pattern of:
Original Poster: We'd X but it can't be done.
Follow-up Poster: Actually, it's not that hard, you just Y and Z
Original Poster: Oh, yeah, but what I didn't mention is that
our X is 15 times bigger than normal and, well, it's
political, and our budget just got caught, and an army
of ninja squirrels is holed up in our computer room and
won't let anyone in.
Follow-up Poster: Why do I get the feeling you don't actually
WANT to do this??
Of course this is just an Internet mailing list. Nobody on the list is
another poster's mommy or daddy. If your organization's security
sucks, or your management is clueless, or - whatever - your
problems are probably entirely your own. So, unless I'm unfortunate
enough to live downwind from your reactor, or I have my tiny stock
portfolio in your care, or you're putting my personal information at
risk - I really don't care if your managers are stupid, or whatever.
Don't feel you need to make excuses to me, or Paul, or Arkanoid -
OK? We know your managers are morons; everyone's are. We know
your budgets are tight; everyone's are. We know you're not a
programmer; nobody is. Whatever. It's not our problem.
Brian Loe wrote:
I suppose, but where I was coming from was that this requires a great
deal of resources - not only in space - and that requires money.
I guess that's where I was coming from, too. You seem to think
this requires a great deal of resources and I doubt it does. You
seem to think this requires a great deal of money and I doubt
that, too. But I'm not the guy on the ground, so I'm absolutely
sure there are "details" that complicate or change the situation
a great deal.
Naturally its slightly political, but
only because I would have to put the fact that we have our pants down
right now pretty delicately.
That's your real problem, I bet, isn't it?
99% of the "technical" problems I run into in security are
usually political - which is really a manifestation of poor
management or egotistical employees. Or both.
spend money" - wait a minute: didn't you already say you had
some hardware? Presumably a computer with a hard disk, right?
Maybe you don't have a terabyte in the darned thing but if you
managed to do something useful and demonstrate some value
to it, you'd probably find that they could afford a hard disk
upgrade. But what do I know?
But wait, isn't that what I'm asking - how to go about doing just
I answered that question in my previous post but here it is
- There is no "silver bullet" that "handles logging"
and requires no comprehension of what you
want to do with your data
- Look at your data
- Decide what you want to do with it
- Then do some scaling estimates and back from
there into your performance envelope
- Then implement it
There's no "laundry list" for what you should be able to pull
out of your logs and what you should do with the results. That's
because logs are highly site-specific and data-specific.
There was a good discussion on the log analysis mailing
list of "reports that would be good starting points" but it's
always data-dependent. I.e.:
Loganalysis mailing lists top picks:
Top N machines sending/receiving traffic through the firewall
Top N machines sending/receiving traffic on the network segment
Same as above but inward-looking
Top N machines being accessed behind the firewall
Breakdown of traffic through firewall by service (%-age)
This is popular as a pie chart
Breakdown of traffic on the network segment by service (%-age)
Same as above but inward-looking
Top N email address(es) sending Email messages
Top N email address(es) receiving Email messages
Top N machines accessing web
Top N targets identified in IDS alerts
Top N IDS attacks identified
%age of Email that is identified as spam
%age of Email that contains blocked attachments
%age of web traffic aimed at sites on porn blacklist
%age of traffic aimed at sites on spy/adware blacklist
Top N porn-surfers
Top N most-ad/spyware infected systems
New machines that have served WWW/FTP/SMTP today
That's from my old USENIX class materials and loganalysis.org.
They've tried, I've tried, to do the logging - and always with
something running on the data to help make it useful. You say it can
be done and that it is useful - I'm just wanting to hear how. I think
generally the mindset has been to log for troubleshooting purposes,
not security (and this should probably include my last effort).
Look for things you've never seen before
Look for things that fall outside a range of what you see every day
Look for things that usually happen that don't
That's a pretty good start.
If you couple that with throwing away the stuff you ARE SURE
you don't care about (but count the number of things you throw
away and compare them day-over-day) you're in pretty good
You're still not guaranteed to find something valuable. But you're
much much much less likely to be standing around going
"Duh, we don't know WTF happened but yeah our customer
database is out there and the New York Times is calling. Let's
have a press conference and tell them we don't know anything
about how our systems work, then get jobs flipping burgers."
seems to get exacerbated, I might add, if you're saving all the data
(no drilling) and reviewing it all manually, looking for something
you've never seen before and can find no reference for.
How do you identify things you've never seen before?
The answer is easy: identify things you've seen before, acknowledge
them and count them, and if ANYTHING isn't something you've
already seen before it must be new, right?
I (again) suggest you take a look at the NBS powerpoints that
I mentioned in my last posting. Also, look at the posting I referred
to on "artificial ignorance." Those are two approaches (structural
analysis for never-before-seen structures and pattern analysis for
never-before-seen patterns) that work at extremely high speeds if
you are careful how you implement them. Trivial artificial ignorance
is a 5 line shell script. You can get fancier than that if you like.
But you're the guy who said:
"But, on the bright side, our 2k IDS system did
eventually begin blocking it from all but one customer site."
comparing your "$250k" log analysis system to your $2k IDS -
which certainly doesn't make it sound like you think your
IDS is useless. Make up your mind, would you?
Did I say that?
Yeah, you did. Not only do I log all the URLs entering and leaving
my network, all session start/stops, DHCP leases, MAC addresses,
and IP/MAC pairings, I log all the Emails, too. :)
I am currently tracking things like processor
and memory loads, in hopes that a jump in activity - especially at odd
times - would be an alert of something bad happening.
It might, yes. But then what?
"Processor loads spiked off the chart at 3:00am!"
"I don't know. Our logs from 3:00am are already gone."
"Oh, well, let's hope it was nothing really bad!"
Something that seems to be lost here though is that when I was saying
a Gig an hour, that was in compressed format.
It didn't get lost; you never said it. You didn't mention the
ninjas in your computer room either. :) But what's an
order of magnitude between friends?
Seriously, though, 1 gig of compressed data per hour
means a bunch of different stuff; namely that you were
compressing it (which is fairly CPU and memory intensive)
on the fly -- so you could just as easily be doing something
else with it like running it through a stoplist or something
to prune out the stuff you know is garbage. Yes, that is
site-specific stuff and to do it right we're talking a little
bit of programming -- not rocket science type programming;
more like an awk script.
The logserver was
rolling the logs at a gig.
Did it only have a gig of disk space?? Most logservers roll the log
when the disk is full.
Not only is that a lot of data to store but
that's a lot of data through the NIC. Multiplying that by two is going
to be interesting, let alone 4 or more.
...and this is why I am going to stop posting on this thread.
When I read observations like the one above, I can tell that
you have decided in advance that this problem is going to
defeat you. You're just looking for excuses. Hey, it's OK,
you don't have to do that. It's not our problem, we don't care,
and we don't need to know why you're not going to do it.
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
RE: RE: IDS (was: FW appliance comparison) Jon Czerwinski (Feb 02)