[Snort-users] RE: fragroute vs. snort: the tempest in a teacup

Craig, Scott SCraig at ...5719...
Thu Apr 25 15:23:24 EDT 2002


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 at ...943...]
> Sent: Friday, April 19, 2002 8:33 AM
> To: Darren Reed
> Cc: Dug Song; Dragos Ruiu; bugtraq at ...35...;
> snort-users at lists.sourceforge.net; pen-test at ...35...;
> roesch at ...1935...; 0xcafebabe at ...1284...
> 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.
> 





More information about the Snort-users mailing list