Re: Mod FWD

[mark.teicher () networkice com]

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
-----------------------------------------------------------------------------
I am just quoting from their manual, and I found it to be quite a bit 
misleading, and very confusing.  I have already logged this to ISS tech 
support as enhancement to their manual.  Hopefully in the next rev it will 
be corrected.

/mark

At 04:14 PM 9/7/00 -0700, Dragos Ruiu 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
> -----------------------------------------------------------------------------
> And besides the dubious functionality, that manual page
> is just plain misleading.  The reason you could be
> seeing the fragments is because something is being done
> to avoid the IDS and it does not happen at the same time as
> another event!  Hope they reword that before someone
> new picks it up and starts quoting it as authoritative.... ;-)
>
> --dr
>
> On Thu, 07 Sep 2000, mark.teicher () networkice com wrote:
> > I would recommend trying this attack again and seeing what ISS RealSecure
> > actually records to both the Display and the database.  It is not exactly
> > what is stated below.
> >
> > /mark
> >
> > /begin excerpt from their manual.
> > IP Fragmentation
> > RealSecure has detected a fragmented IP packet.
> > Type Unauthorized Access Attempt
> > Console Name IPFrag
> > Technical
> > Description
> > An IP packet is sometimes split into several fragments when it is
> > transmitted over the network. These fragments are then reassembled at the
> > destination to form a full IP packet. Some routers that filter out packets
> > based on information in the TCP header rely on the information in the 
> first
> > fragment, then blindly pass the remaining fragments. It is possible to
> > construct individual fragments of an IP packet so that subse-quent packets
> > overlap. As a result, they can overwrite parts of the TCP header when they
> > are reassembled at the destination. In this case, an intermediate 
> filtering
> > router is
> > tricked into believing that a packet is destined for an allowed 
> service. In
> > reality, the packet is destined for a service that would normally be 
> filtered.
> >
> > False positives Since the IPFrag signature detects only part of a packet,
> > RealSecure may have detected the fragment plus the reassembled packet
> > (composed of the entire packet). If this is the case, then RealSecure
> > detects both events, although the two (or more) packets are actually only
> > one packet.
> > If you are using RealSecure, the IPFrag alert will most likely happen at
> > the same time as an alert that represents the true event. To make sure the
> > alerts are about the same event, see if the following information in the
> > events matches:
> >  Time
> >  Date
> >  Source Address
> >  Destination Address
> > If these events match, an attacker is probably trying to evade an 
> Intrusion
> > Detection System (IDS) and is possibly using advanced tools to create the
> > fragmented packets. If the IPFrag alert does not happen at the same 
> time as
> > another alert, then it could indicate that an attacker is exploiting a
> > vulnerability that RealSecure does not currently detect or the fragment
> > could simply be an IP packet that simply became frag-mented
> > during transit.
> >
> > /end excerpt from manual
> >
> > At 10:06 AM 9/7/00 +0900, Keiji Takeda 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
> > >----------------------------------------------------------------------- 
> ------
> > >Hi,
> > >
> > >I  recently tested several IDSs in the market for an article on
> > >Japanese magazine and think this is good chance to talk about my 
> recogntion.
> > >
> > >The packet reassembly has been one of hot issues on Networkbased IDS for
> > >long time.
> > >Today, in my feeling, it became on of requirements of NIDS product.
> > >
> > >When I did the test, all IDSs I could get handled fragmented IP 
> packets and
> > >  TCP segments.
> > >The notrious Realsecure nicely does reassemble packets in its version5.0.
> > >It seems that the product has no weakness anymore as well as other 
> products
> > >that have good names.
> > >
> > >I'd like to be fair, so please give me your feedback.
> > >
> > >P.S. Even my tiny free IDS, Packet Monster (pakemon), does it now! ;)
> > >
> > >Marcus J. Ranum san wrote on Wed, 06 Sep 2000 10:22:35 -0400
> > >By the way, are there still IDS out there that don't do TCP
> > > >reassembly and defragmentation? It's the 21st century, now,
> > > >surely we've gotten past the basics! ;)
> > >
> > >
> > >
> > >Keiji Takeda ( http://www.sfc.keio.ac.jp/~keiji/ )
> --
> 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