Hi all,

One of our firewalls has recently rejected the following packets for having
unusual IP options. The apparent origins were as follows:

<IP1> was a server in Switzerland (with which no traffic has been recorded) 
<IP2> was a Windows box belonging to the address space of a very large
American ISP

11:06:39 Deny IP from <IP1> to <...>, IP options 0x80323fa4
11:06:47 Deny IP from <IP1> to <...>, IP options 0x8034e784
11:06:58 Deny IP from <IP1> to <...>, IP options 0x801e38bc

11:27:13 Deny IP from <IP2> to <...>, IP options 0x8021d36c
11:27:18 Deny IP from <IP2> to <...>, IP options 0x802125fc
11:27:25 Deny IP from <IP2> to <...>, IP options 0x802b181c
11:28:47 Deny IP from <IP2> to <...>, IP options 0x8029b644
11:29:04 Deny IP from <IP2> to <...>, IP options 0x8022f6cc

For your convenience, I've broken down the options into binary form. 

0x80323fa4      10000000 00110010 00111111 10100100
0x8034e784      10000000 00110100 11100111 10000100
0x801e38bc      10000000 00011110 00111000 10111100
0x8021d36c      10000000 00100001 11010011 01101100
0x802125fc      10000000 00100001 00100101 11111100
0x802b181c      10000000 00101011 00011000 00011100
0x8029b644      10000000 00101001 10110110 01000100
0x8022f6cc      10000000 00100010 11110110 11001100


I looked in Stevens' book (see p. 37) for the meaning of the unusual options
but couldn't find a match:

- it's not DoD Security (RFC 1108), the first byte would have been 0x82 or
0x85
- it's not Record Route, the first byte would have been 0x07
- it's not router timestamp, the first byte would have been 0x44
- it's not source routing, the first byte would have been 0x83 for loose
source routing or 0x89 for strict source routing 

My questions:

1. Are these options meaningful or can they be the result of a bug?
2. What would the purpose be ?
3. Although the 2 sets of packets did not have identical options, their
occurrence within a short time frame is rather remarkable in many months of
logging that have not produce similar entries.
I take into account the possibility of spoofed source IPs.

Thank you,

Razvan


-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]

Reply via email to