RE: fragroute vs. snort: the tempest in a teacup

[Ron DuFresne <dufresne () winternet com>]

On Thu, 25 Apr 2002, Craig, Scott wrote:

> I've heard this argument before regarding the placement of network IDS,
> where it is believed that the hot zone is not worth it for any more that
> research or scary statistics.
>
> I think Steven Bellovin gave a great objective statement on answering the
> question of the purpose of your IDS.
>
> I would like to add something to it.
>
> Another few questions to ask are:
>
>  "How many systems are being protected behind the firewall?".
>  "How many firewalls do you have?" (noting you may have private network
> connections to business partners)
>  "Are you dilligent in secure configurations, awareness, and software
> patches?"
>
>
> Prioritizing Fixes:
>
>       For instance, if you have a network of 30,000 computers,
>       consisting of 1,000 servers, you probably don't have the
>       resources to apply security patches on a daily, even weekly
>       basis. Even if you have the ultimate SW distribution system,
>       some patches could require reboots and you can't afford to
>       schedule downtime for a 24x7 operation.
>
>       You may use the data from a Hot Zone NIDS to determine what
>       urgently needs to be addressed. We see bulletins of vulnerabilities
>       daily, many of which apply to our environment. I may or may not
>       need to do a vulnerability scan to determine how vulnerable we
>       are to the new threat. Next, I balance out the severity of the
>       threat's impact & ease of exploitation, along with other items
>       that could impact the loss of data, service, or compromise. I may
>       then determine what the community has to say as to what they're
>       seeing in the wild, or how things are leaning towards whether it
>       will be exploited in mass (how sexy is this vulnerability to some
> people).
>       I'll also look to see what the hot zone network IDS is seeing.
> Hopefully
>       I have a relavent signature for the type of attack to be used
> against
>       the vulnerability. If I have a honeypot server in the hot zone that
>       reflects our generic web servers, first I'd consider myself lucky to
>       have someone to take on the responsibility of properly  keeping an
>       eye on the honeypot, second I would verify if any probes were taken
> to
>       the next step of an attack. If the data from the hot zone shows that
>       we are under a constant probe for this vulnerability, I then have
>       plenty of material that is personal to upper management to approve
>       resources to take immediate action to ward off the attacks (patches,
> configs, etc).
>       This is an important step because everyone already has a job to do,
> and
>       this could impact other deadlines or responsibilities.


Unless you NIDS has all the current signatures to identify the probes and
react to them, you might well see nothing of particular interest.
Additionally, you have to take further steps to identify, even if the
outside place IDS systems does detect the probes, that they are really
something to be concerned with.  But, until IDS systems can start to
recongise something new, not in their *known* database of bad things<TM>
it' possible, like the issues that started this thread, that you will see
nothing to be concerned with.  Afterall, it took until today for snort
signatures to be updated to deal with the all<?> issues Dug Song
identified.


> Detection Scope:
>
>       Having the IDS only internal, could miss network-wide signatures.
>       To simplify this, an example would be a port scan. To
>       really simplify this, I will say a port 80 scan. Let's say
>       your DMZ has 10 web servers with IP addresses visible to the
>       word on port 80, and 45 other types of servers (FTP, SMTP,
>       clustered servers, etc). Your IDS monitoring DMZ traffic may
>       not catch a port 80 scan. But if you were in the hot zone it
>       would. Again, this is just a simplified example. There would
>       be other signatures more gratifying than port scans for the Hot
> Zone.


DMZ machines are very different beasts, and should be hardened to the max,
as well as having some protection, at the least a packet filter to limit
exposure as much as possible.  A specific IDS system to monitor them might
be deemed important and useful, if properly tamed and tuned and cared and
fed.  Yet, I still think that getting an idea of normal traffic flows to
these systems and having something of comparative value is just as if not
more enlightening at this time, in this state of the IDS game, until they
can actually detect new unknown attack 'signatures'.  Otherwise you are
prolly better off with the honeypot scenario and dedicating staff to it's
constant monitoring and interpretation.


>       To take the logic of cutting down false positives by placing it
>       only inside the firewall, would be the same as saying to have only
> host based IDS.
>
> Maybe what I'm coming to conclude is that many large organizations should
> consider
> their "computer security guy" a researcher. It may take research to impose
> change.
>
> I would also strongly suggest that anyone subscribing to a Bugtraq mailing
> list is beyond the
> average consumer. Many subscribers are researchers, (or) just responsible
> for a software product,
> have a responsibility for security, or are just curious.

And for another take, on the IT ealm and understaffing and under-payment
it has always faced:

There are two methods common for IDS, one setup places the IDS in front of
the firewall so folks can get those 3AM wakeup calls and notifications and
thus not fall too deeply into rem sleep for long periods, call this method
the self depridation method if you will.  That IDS system will be sucking
up packets and seeing all sorts of nasty bits hitting the external
interface and clanging out warnings upon warnings on end, most of the
information passing this IDS setup will be of dubious use, though some
will argue that such an IDS placement is good for telling them what kind
of nasty traffic is out there and banging at their doorstep, yet, the good
firewall/security admin already has a good clue in this area and knows
better.

The second admin knows that what has passed the firewall checks and
balances is of more import and use in determining if the firewall setup is
sufficent for the job it was designed to do, and they will be clued into
the fact that at least 70% of the nasty traffic they are dealing with
originates internally.  These folks place the IDS system behind the
firewall, so it tries to catch what might well pass that system and
attempt to cause havock internally, at the same time, this IDS system can
see what the userbase behind the firewall might be trying to pass outside
to raise hell on the internet public at large.  These are admins more keen
on getting some of that rem sleep, and not into false positives
interupting their days as well as night and weekends.  The companies they
work for have an internal respose team that is adept at dealing with the
internal noise that such a IDS system will be alerting too, and have a
good policy established to define the firewall rules in place and will
seldom hear a peep, if at all, from the IDS about something nasty passing
from the external past the firewall to the soft chewy center of their
networks.

If rem sleep is not important to you, then by all means use the first


IDS is just not yet *smart* enough to do what many wish for it and try to
task it to do.

Thanks,

Ron DuFresne
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
        ***testing, only testing, and damn good at it too!***

OK, so you're a Ph.D.  Just don't touch anything.


_______________________________________________
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