Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Incidents
[Top] [All Lists]

Re: Bad options?

Subject: Re: Bad options?
Date: Thu, 26 Aug 2004 22:36:26 -0700
On Thu, 26 Aug 2004 15:00:28 -0400, daniel.ramaswami@celera.com
<daniel.ramaswami@celera.com> wrote:
Hello,

Has anyone had any detects similar to below? Is this a form of fingerprint
(this being a fingerprint response? Any insight into what the last TCP
option
fields may be? I have seen interesting traffic like this before, but have
not found any text that could explain it.

Any help appreciated.

09:27:21.621476 xxx.xxx.xxx.xxx.http > xxx.xxx.xxx.xxx.46045: . ack
3207692596 win 8688 <nop,nop,sackOK,[bad opt]> (DF)
                         4500 0034 e1a2 4000 3e06 b453 xxxx xxxx
                         xxxx xxxx 0050 b3dd d43c c6f2 bf31 8134
                         8010 21f0 980d 0000 0101 0402 4c66 7844
                         0278 c313

Thanks,
Dan


IP Header:
4500 0034 e1a2 4000 3e06 b453 xxxx xxxx
xxxx xxxx

First 5 32-bit words of TCP Header:
0050 b3dd d43c c6f2 bf31 8134
8010 21f0 980d 0000

TCP header length is 8.

TCP Options:
0101 0402 4c66 7844 0278 c313

http://www.iana.org/assignments/tcp-parameters

01 = nop 
01 = nop 
0402 = sackOK

4c66 7844 0278 c313

Taking flipped bits into consideration doesn't explain this. 
Tunnelling perhaps?  There's not enough here to determine if ASCII
interpretations of the hex mean anything.

Something else that is interesting, from RFC 2018:
  "The selective acknowledgment extension uses two TCP options. The
   first is an enabling option, "SACK-permitted", which may be sent in a
   SYN segment to indicate that the SACK option can be used once the
   connection is established.  The other is the SACK option itself,
   which may be sent over an established connection once permission has
   been given by SACK-permitted."

"2.  Sack-Permitted Option

   This two-byte option may be sent in a SYN by a TCP that has been
   extended to receive (and presumably process) the SACK option once the
   connection has opened.  It MUST NOT be sent on non-SYN segments.
"

But take the sackOK option in a non-SYN packet as meaning anything
with a grain of salt.

Do you have more of these packets that you could share?  Are you on
the sending or receving end of this packet?  We need more info to
really say anything other than, you're right, it is odd.

<Prev in Thread] Current Thread [Next in Thread>
  • Bad options?, Daniel . Ramaswami
    • Re: Bad options?, Jeffrey Denton <=