I have two IDS sensors on the edges of my network (one is the Internet, the other is a Frame network attached to a number of larger university hospitals), and I'm in the process of upgrading to v2.5. The configuration notes talk some about fragment reassembly... and I'm wondering if any of y'all have any experience with this. Any comments or experiences would really be helpful. TIA
What exactly are you interested in knowing? I strongly suggest that you enable this feature to provide you with the best coverage possible. Initially the default values that we have established for managing the reassembly buffers should be fine. In rare occasions in environments that are extremely fragmented you may need to tweak them.
I would also suggest that when you transition to 2.5 you apply the latest service pack and signature update to bring your system up to the latest rev possible. The current latest rev is 2.5(1)S2.
Fragment re-assembly means putting a packet back together after it has been fragmented after passing through a network hopp with a smaller MTU than the packet started with. The IP header has a flag that when set has value 1=more fragments, 0=last fragment and a field called fragment offset to indicate where in the full packet this fragment goes.
The problem is that a cracker can fragment a packet so that parts of the IP or TCP/UDP/CIMP etc. headers are in separate fragments but with the offsets so that a later fragment overlays the information in an earlier fragment.
Depending on the receiving client TCP/IP stack, the resulting fragment could be very different from the one the network IDS sees.
So for example a fragment could have destination TCP port of 80 (http) as seen by the IDS but an actual destination port of 25 (SMTP mail) as seen by the destination host. it is a way of evading intrusion detection and can be easily added to any attack by passing the fragments by a fragmentation tool before they hit your network. Dug Song's fragrouter 1.6 will do this readily.
You are correct. Our Fragment reassembly methodology takes these and a few other problems such as resource starvation into account. By default the sensor will reassemble packets as if it were a Solaris or NT server. This is probably the most common method of reassembly. As a fail safe the sensor also checks for illegal overwrites of data in overlapping fragments. If this evasion technique is attempted one of two things will occur.
1. The sensor will note the over write and alert that someone has performaed an illegal data manipulation. This is NOT seen in normal traffic and is a high probability indicator of an attempted attack.
2. You will get the above alert as well as specific alerts as to what was attempted. This is only possible when the target was a Solaris or NT machine since this is the sensors default reassembly mode.
Look for significant advancements in this are in the months to come as we release new features to handle this.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...