Essay About Root Cause Of The Flaws And Purpose Of This Article

Defeating Sniffers and Intrusion Detection Systems
Essay Preview: Defeating Sniffers and Intrusion Detection Systems
Report this essay
(Taken from phrack.com, the best Hacker zine ever)
—-[ Overview
The purpose of this article is to demonstrate some techniques that can be used
to defeat sniffers and intrusion detection systems. This article focuses
mainly on confusing your average “hacker” sniffer, with some rough coverage of
Intrusion Detection Systems (IDS). However, the methods and code present in
this article should be a good starting point for getting your packets past ID
systems. For an intense examination of attack techniques against IDS, check
out:
There are a large number of effective techniques other than those that are
implemented in this article. I have chosen a few generic techniques that
hopefully can be easily expanded into more targeted and complex attacks. After
implementing these attacks, I have gone through and attempted to correlate
them to the attacks described in the NAI paper, where appropriate.
The root cause of the flaws discussed in this article is that most sniffers
and intrusion detection systems do not have as robust of a TCP/IP
implementation as the machines that are actually communicating on the network.
Many sniffers and IDS use a form of datalink level access, such as BPF, DLPI,
or SOCK_PACKET. The sniffer receives the entire datalink level frame, and
gets no contextual clues from the kernel as to how that frame will be
interpreted. Thus, the sniffer has the job of interpreting the entire packet
and guessing how the kernel of the receiving machine is going to process it.
Luckily, 95% of the time, the packet is going to be sane, and the kernel
TCP/IP stack is going to behave rather predictably. It is the other 5% of the
time that we will be focusing on.
This article is divided into three sections: an overview of the techniques
employed, a description of the implementation and usage, and the code. Where
possible, the code has been implemented in a somewhat portable format: a
shared library that wraps around connect(), which you can use LD_PRELOAD to
“install” into your normal client programs. This shared library uses raw
sockets to create TCP packets, which should work on most unixes. However, some
of the attacks described are too complex to implement with raw sockets, so
simple OpenBSD kernel patches are supplied. I am working on complementary
kernel patches for Linux, which will be placed on the rhino9 web site when
they are complete. The rhino9 web site is at:
—-[ Section 1. The Tricks
The first set of tricks are solely designed to fool most sniffers, and will
most likely have no effect on a decent ID system. The second set of tricks
should be advanced enough to start to have an impact on the effectiveness of
an intrusion detection system.
Sniffer Specific Attacks
1. Sniffer Design – One Host Design
The first technique is extremely simple, and takes advantage of the design of
many sniffers. Several hacker sniffers are designed to follow one connection,
and ignore everything else until that connection is closed or reaches some
internal time out. Sniffers designed in this fashion have a very low profile,
as far as memory usage and CPU time. However, they obviously miss a great deal
of the data that can be obtained. This gives us an easy way of preventing our
packets from being captured: before our connection, we send a spoofed SYN
packet from a non-existent host to the same port that we are attempting to
connect to. Thus, the sniffer sees the SYN packet, and if it is listening, it
will set up its internal state to monitor all packets related to that
connection. Then, when we make our connection, the sniffer ignores our SYN
because it is watching the fake host. When the host later times out, our
connection will not be logged because our initial SYN packet has long been
sent.
2. Sniffer Design – IP options
The next technique depends on uninformed coding practices within sniffers.
If you look at the code for some of the hacker sniffers, namely ones based-off
of the original linsniffer, you will see that they have a structure that looks
like this:
struct etherpacket
etherheader eh;
ipheader ip;
tcpheader tcp;