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

["Craig, Scott" <SCraig () kmart com>]

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.


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.

        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.

Just another viewpoint...
Scott

> -----Original Message-----
> From: Ron DuFresne [mailto:dufresne () winternet com]
> Sent: Friday, April 19, 2002 8:33 AM
> To: Darren Reed
> Cc: Dug Song; Dragos Ruiu; bugtraq () securityfocus com;
> snort-users () lists sourceforge net; pen-test () securityfocus com;
> roesch () sourcefire com; 0xcafebabe () hushmail com
> Subject: Re: fragroute vs. snort: the tempest in a teacup
>
>
> On Fri, 19 Apr 2002, Darren Reed wrote:
>
> > In some mail from Dug Song, sie said:
> > > > Most firewalls these days (especially Linux and OpenBSD ones)
> > > > actually do reassembly inbound.
> > >
> > > this isn't quite true. most stateful inspection firewalls 
> do "virtual
> > > reassembly" for IP fragments, and a few do basic window 
> tracking for
> > > TCP connections, but will still allow most fragroute-style attacks
> > > through (e.g. duplicate overwriting TCP segments with older TCP
> > > timestamp options for PAWS elimination, short TTLs, etc.).
> >
> > Well then IDS software needs to be smarter.  IMHO it makes 
> little sense
> > for an IDS to be *behind* a firewall as it's going to miss 
> out on lots
> > of useful data points.  Maybe this means telling your IDS 
> software how
> > big your network is so it can make intelligent decisions 
> about how far
> > a packet will go based on its TTL.
>
> But, was not this what IDS' were originally designed for;  behind the
> firewall placement to detect what the firewall policies might not be
> catching?  And as thus a warning/alert being sounded for action?
>
> I see the additional placement of looking inwards as having merit.  to
> detect machines that are trojaned and or viri infected and 
> trying to scan
> other networks or phone home.
>
> Being that the IDS' in present use are lke a abti-viri product and
> requiring lots of special care and feeding, and thus very 
> reactionary to
> signatures and the known common attack vectors, I see they 
> are only useful
> at present as policy verifiers, behind the firewal as a last catchall.
> Especially in light of comments by others about the 'scrubbing'
> charateristics of some firewalls.


_______________________________________________
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