<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Dear Ivan,<br>
<br>
Thank you for your reply,<br>
<br>
I was looking for something simple, something to enable me to
construct a full tcp session buffer (like follow tcp stream of
wireshark).<br>
<br>
Thanks.<br>
<br>
Ivan Arce wrote:
<blockquote cite="mid44E13A96.9080903@coresecurity.com" type="cite">
<pre wrap="">Hello,
There are mode that just "small differences" depending on what and why
you're looking at this problem. Almost 8 years ago I worked developing
one of the first commercial honeypot software packages for a big security
vendor, the software had to mimic the behavior of a handful of TCP/IP
stacks (Windows NT4, Cisco IOS, solaris 2.x , FreeBSD, SunOS 4.x, etc).
There were more that 200 documented behavioral differences among the
TCP/IP stacks of those systems (unfortunately the paper detailing them had
never seen the public light).
To clarify: Not ~200 "problem packets" but differences in how those TCP/IP
stacks operated on exactly the same traffic
Tools such as nmap (<a class="moz-txt-link-freetext" href="http://insecure.org/nmap/">http://insecure.org/nmap/</a>) and p0f
(<a class="moz-txt-link-freetext" href="http://lcamtuf.coredump.cx/p0f.shtml">http://lcamtuf.coredump.cx/p0f.shtml</a>) take advantage of some of these
behavioral differences to infer the operating system running on a remote host.
A good paper that explains how and why these differences are a problem in
the security world is the classic Tim&Tom on defeating Intrusion Detection
Systems:
"Insertion, Evasion and Denial of Service; eluding Network Intrusion
Detection", Tim Newsham & Thomas Ptacek, Jan 1998.
<a class="moz-txt-link-freetext" href="http://insecure.org/stf/secnet_ids/secnet_ids.pdf">http://insecure.org/stf/secnet_ids/secnet_ids.pdf</a>
A good tool to some testing and possibly extend to include more features
is fragrouter with was originally at <a class="moz-txt-link-freetext" href="http://monkey.org/~dugsong/fragroute/">http://monkey.org/~dugsong/fragroute/</a>
but possibly there are more recent versions
To craft and send packets quickly you can use the excellent Python package
Scapy from Philippe Biondi:
<a class="moz-txt-link-freetext" href="http://www.secdev.org/projects/scapy/">http://www.secdev.org/projects/scapy/</a>
Or our own Pcapy/Impacket combo (although most likely you'd need a bit of
Python coding of your own):
<a class="moz-txt-link-freetext" href="http://oss.coresecurity.com/projects/impacket.html">http://oss.coresecurity.com/projects/impacket.html</a>
-ivan
David Chang wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Ralph,
I'm sure that different implementations of TCP/IP have small differences
in the way they handle packets. However, for the vast majority of real
world situations, TCP/IP is well documented in RFC 791 & 793. In
addition, books like TCP/IP Illustrated by W. Richard Stevens cover the
protocol in great detail. Using these resources, one can write a TCP/IP
re-assembly engine. I don't think there is a "standard" implementation
(or algorithm) for re-assembly but rather a list of possible problem
packets to handle. Looking at the libnids website
(libnids.sourceforge.net), they mention a test suite that their
re-assembly engine passed (libnids.sourceforge.net/TESTS). Maybe you
can contact them to find out how they conducted their tests. Or, maybe
you can just use their engine.
DC
----- Original Message ----- From: "Thomas O'Hare" <a class="moz-txt-link-rfc2396E" href="mailto:Tom@RedTile.Com"><Tom@RedTile.Com></a>
To: <a class="moz-txt-link-rfc2396E" href="mailto:winpcap-users@winpcap.org"><winpcap-users@winpcap.org></a>
Sent: Monday, August 14, 2006 3:50 PM
Subject: Re: [Winpcap-users] TCP/IP stack reassembly
</pre>
<blockquote type="cite">
<pre wrap="">Ralph
I will go out on a limb here and anyone else is free to jump in...
The nature of TCP/IP is a "connection oriented" protocol. Which mean a
real connection exists between 2 hosts. If the protocol stack is
anywhere near what it should be, then if there are problems with packets
the sending host is supposed to resend the problem data.
So trying to recover and re-assemble packets seems to me to be
defeating, or at least making a lot more work for something that is
supposed to be done for you anyway by the stack.
If I totally missed the boat, then please explain a little further.
But it is late here, I am tired and so I am at a loss as to why you want
to work so hard...
Thanks,
~ Thomas O'Hare ~
President, RedTile, Inc. - DBA: RedTile Software
Web, Wireless, Network, Database & Systems Software
+1.407.295.9148 ; +49.8651.717950 ; <a class="moz-txt-link-freetext" href="http://www.RedTile.Com/">http://www.RedTile.Com/</a>
Operations Manager; Virtual FoxPro User Group
<a class="moz-txt-link-abbreviated" href="mailto:Tom@VFUG.Org">Tom@VFUG.Org</a> ; <a class="moz-txt-link-freetext" href="http://www.VFUG.Org/">http://www.VFUG.Org/</a>
Accounts wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi All,
I believe this question was asked before without a clear answer. Is
there a definite or a standard way/library of reassembling the tcp/ip
stack from the sniffed packets?
I wanted to write one myself but the biggest problem that I have
faced is debugging, is there a software out there that can simulate
sending packets on demand (like fragmented and oob...) so that it could
aid in the development and debugging of a code that does the reassembly?
Thank you all.
Ralph.
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->---
"Buy the ticket, take the ride" -HST
Ivan Arce
CTO
CORE SECURITY TECHNOLOGIES
<a class="moz-txt-link-freetext" href="http://www.coresecurity.com">http://www.coresecurity.com</a>
PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836 B25D 207B E78E 2AD1 F65A
</pre>
</blockquote>
<br>
</body>
</html>