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. |

| 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> |
|---|---|---|
| ||
| Previous by Date: | Bad options?, Daniel . Ramaswami |
|---|---|
| Next by Date: | Re: compromised machines, soccer4net@netzero.com |
| Previous by Thread: | Bad options?, Daniel . Ramaswami |
| Next by Thread: | Uptick in telnetd scanners - possible worm activity., Jay D. Dyson |
| Indexes: | [Date] [Thread] [Top] [All Lists] |