Security Incidents mailing list archives
Re: Bad options?
From: Jeffrey Denton <dentonj () gmail com>
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.
Current thread:
- Bad options? Daniel . Ramaswami (Aug 26)
- Re: Bad options? Jeffrey Denton (Aug 27)