Re: Mod FWD

[Jackie Chan <blue0ne () igloo org>]

Archive: http://msgs.securepoint.com/ids
FAQ: http://www.ticm.com/kb/faq/idsfaq.html
IDS: http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
HELP: Having problems... email questions to ids-owner () uow edu au
NOTE: Remove this section from reply msgs otherwise the msg will bounce.
SPAM: DO NOT send unsolicted mail to this list.
UNSUBSCRIBE: email "unsubscribe ids" to majordomo () uow edu au
-----------------------------------------------------------------------------
It appears I have let my idealism get in the way of the "business
need".  My collegues have duefully beat me amongst the head and shoulders
for my annoying academic tirade.

Suffice it to say that Packet Re-assembly is the better type of IDS due to
the fact that it adds a greater definition of data required to
appropriately respond to a network based attack.  Without packet
-reassembly chances are that the attack will go "unseen"(copyright
nfr) due to any number of factors.

-blue

On Thu, 7 Sep 2000, Jackie Chan wrote:

> Archive: http://msgs.securepoint.com/ids
> FAQ: http://www.ticm.com/kb/faq/idsfaq.html
> IDS: http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
> HELP: Having problems... email questions to ids-owner () uow edu au
> NOTE: Remove this section from reply msgs otherwise the msg will bounce.
> SPAM: DO NOT send unsolicted mail to this list.
> UNSUBSCRIBE: email "unsubscribe ids" to majordomo () uow edu au
> -----------------------------------------------------------------------------
> Folks,
>       I don't disagree with the premise that packet reassembly adds
> value and is the better of the two solutions, however even though the
> actual attack is not revealed without packet re-assembly, the security
> admin still gets an alert containing Source IP, Dest IP, Source Port, and
> Dest Port.
>
> > From a watch standers perspective, there is a _huge_ difference between no
> alarm, and an alarm that has enough elements that I can at least infer
> what type of attack has occured, or better yet where it was coming from
> (so I can stop it) and where it was headed (so I can perform damage
> control).
>
> My opinion is that if we ever plan on turning computer security from a
> black art into a science, we need to treat it as such.  And as I realized
> what Marcus was originally saying, there are quite a few people on this
> list who may be new and did not understand that there would be alerts, and
> information generated when a IP Fragment event occured.
>
> In closing, its semantics.
>
> -blue
>
> On Wed, 6 Sep 2000, Dragos Ruiu wrote:
>
> > On Wed, 06 Sep 2000, Jackie Chan wrote:
> > > Not to argue with Marcus, but his quote of the fragmented attack going
> > > "unseen" is not totally correct.  It is true that without packet
> > > reassembly one cannot correctly identify the type of attack that is taking
> > > place, however most IDS's that do not execute packet re-assembly DO
> > > alert on the fact that it saw fragmented packets, and from which source IP
> > > they originated from.
> > >
> > > So to clarify, packet re-assembly is required to categorize the attack
> > > taking place.  It is not needed to merely detect the anomolous pattern of
> > > the fragmented packet stream.
> >
> > Damn, and I usually like disagreeing with Mr. Ranum, but I have to side 
> > with him on this. I've just been updating my defragger code for snort and
> > thinking a lot about this issue, and upon consideration....
> >
> > There are whole classes of attack and obfuscation that are possible to sneak 
> > by if you don't reassemble or maintain enough cross-fragment state to do 
> > some consistency checks.  Speaking from snort terms (but I'm sure it's
> > applicable to other IDS system capabilities), the minfrag plugin, which
> > predated my defrag plug-in and was a primary line of defense against 
> > frag attacks up until a little while ago, will only alert when fragments exceed
> > certain thresholds, size, number.... and based on only these criteria, it is
> > still possible to use fragmentation to sneak by some very nasty stuff 
> > and have the fragment detectors stay quiet as a rock... because to
> > wire them any tighter would set off a string of falses on ordinary 
> > naturally occurring fragmented traffic....
> >
> > Yeah, simple fragment detectors will catch the script kiddies using
> > stock nmap -f, hping -f, and fragrouter, but don't kid yourself... without
> > full fragment checking, there are still massive holes in your detection
> > system and people can drive through a small tractor trailer full of 
> > shellcode or nasty cgi queries right past your very silent intrusion 
> > alarm that won't see a thing. And the old, "Well, we look at and filter
> > the head fragment isn't that good enough?", you get from some IDS
> > and firewall vendors makes me laugh...  What's your IP address 
> > again? I know a few IRC channels that may be interested in building
> > up their bot fleets...
> >
> > BTW the same statements could apply to web character notation
> > and TCP reassembly, when looking for things like CGI probes. 
> > IDS is a tough job that requires hefty processing power and 
> > thoroughly optimized, full, implementations to do right, imho....
> >
> > cheers,
> > --dr
> >
> > -- 
> > Dragos Ruiu <dr () dursec com>    dursec.com ltd. / kyx.net - we're from the future
> > pgp fingerprint: 18C7 E37C 2F94 E251 F18E  B7DC 2B71 A73E D2E8 A56D 
> > pgp key: http://www.dursec.com/drkey.asc