As you probably noticed IP header has variable length placeholder for the IP Options field. It has been there since the beginning , once a good idea for debug now turned into trouble. RFC 791 states that hosts/routers supporting IP protocol must implement Ip Options filed . It is up to the vendor to decide what to do with this optional field, but it must understand it. Still, wouldn’t be a problem if not modern architecture of the routing equipment that was designed to do most efficiently Routing , i.e. pass from interface to interface gigabytes of traffic. Therefore routing functions are highly optimized and most of the time are implemented in hardware . All other types of traffic unfortunately are not, and in most of the cases processing , lets call it Control traffic, is being left to poor router CPU and done in software. That brought the troubles into the IP world – relatively small amounts of control traffic (including Ip Options packets) may bring down otherwise
powerful router in just minutes.
To prevent this attack vendors implemented protection measures to drop entirely or selectively IP packets that has Ip Options filed set. Below is quick cheat sheet how to do it in some gear :
Checkpoint firewall NG/NGX – packets with Ip Options are dropped by default except for the “Router Alert” option (0x94) for the IGMPv2 and PIM protocols [or so CP claim, will have to verify later] and not even logged. To start logging dropped packets go to Policy -> Global Properties -> Log and Alerts -> check Ip dropped packets : Log
There is a value related to it that is on by default : Global Properties -> SmartDashboard customization -> Advanced Configuration -> Configure -> Firewall 1 -> Stateful inspection -> enable_ip_options (check/uncheck) but unchecking it removes from firewall VM chain module that inspects these Options at all and all Ip Options packets are dropped . So all packets bearing Ip Options are happily dropped even before security rules , here:
in chain (9):
0: -7f800000 (9095dd60) (ffffffff) IP Options Strip (ipopt_strip)
1: – 1fffff6 (9095ee80) (00000001) Stateless verifications (asm)
Also Checkpoint say you can decide which Ip Options will be allowed later BUT only when installing the firewall: “The set of permitted options must be configured during installation … the enable_ip_options setting in SmartDashboard is then used to enable or disable this functionality. Contact Check Point support for instructions on configuring the set of allowed IP options.”
– If Enable Packet Filtering is not checked then do it in IP Packet Filters -> Properties – > General tab. On the Packet Filters tab check Enable Filtering IP Options .
Microsoft ISA 2004 Server:
– IP options filtering is enabled by default
– Go to Configuration node of the server in question in Management console -> General -> Additional Security Policy
Define IP Preferences . Here you will have 3 options to deal with Ip Options packets:
a) Deny packets with any IP options;
b) Deny packets with selected IP options;
c) Deny packets with all except selected IP options
The same options are available in ISA 2006 , click on Configure IP Protection link – > IP Preference settings
You just add ip-options term to the filter and apply it to the interface of interest. In the example below I block only Route Record type of Ip Options, if you use any then it will block any type:
firewall {
family inet {
filter NOICMP {
term 1 {
from {
address {
192.168.2.100/32;
}
}
then {
reject;
}
}
term 2 {
from {
ip-options route-record;
}
then {
reject;
}
}
term 3 {
from {
address {
192.168.2.0/24;
}
}
then accept;
}
}
}
}
Apply to the interface:
interfaces {
em0 {
unit 0 {
enable;
family inet {
filter {
input NOICMP;
}
address 192.168.2.133/24;
}
}
}
Other possible arguments to ip-options clause:
Possible completions:
<range> Range of values [ Open a set of values any Any IP option loose-source-route Loose source route route-record Route record router-alert Router alert security Security stream-id Stream ID strict-source-route Strict source route timestamp Timestamp
By default it doesnt allow/forward packets with Source Routing set, and that’s good. For completeness
here is how to enable (or check whether it is enabled) source-routed forwarding:
BillG> netsh interface ipv4 set global sourceroutingbehavior=drop| forward| dontforward
– or-
Registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameter
Key: DisableIPSourceRouting
DWORD value: 0
In Security any measure/protection/method is as good as the proof you can present that it actually works.
Windows:
– Ping with Record Route field set:
BillG> ping –r 9 192.2.2.1
– Ping with Strict Routing field set:
BillG> ping –k <1st_hop_router_IP> <2nd_hop_router_IP…> <target>
– Ping with Loose Routing field set:
BillG> ping -j <1st_hop_router_IP> <2nd_hop_router_IP…> <target>
– Ping with Timestamp option set:
BillG> ping –s 3 8.8.8.8
Linux:
– Ping with Record Route field set:
root@darktstar:~/nmap# ping -R 8.8.8.8
– Ping with Timestamp option set:
root@darkstar:~/nmap# ping -T tsonly 8.8.8.8
Linux,BSD,Unix :
This handy utility sends bunch of packets to the target to test what Ip Options the target supports:
freebsd# fragtest ip-opt 192.168.2.133
ip-opt: sec lsrr ts esec cipso satid ssrr
I run fragroute above against Juniper (8.3) that was configured in the example earlier to block only Record Route option, as you can see it is indeed missing in the output list that enumerates what Ip Options the target supports [ see Reference for fragroute details]
References for further details:
Juniper: JUNOS Enterprise Routing, 1st Edition, By Doug Marschke; Harry Reynolds, 2008
Microsoft ISA : Microsoft® ISA Server 2006 Unleashed ,By Michael Noel, 2007
Fragroute http://monkey.org/~dugsong/fragroute/
Windows 2008: Windows® Server 2008 TCP/IP Protocols and Services,By Joseph Davies, 2008
