[c-nsp] IP Options Drop
Robert Williams
Robert at CustodianDC.com
Fri Apr 18 12:40:18 EDT 2014
Hi All,
I’ve got a 6500/720 which needs to have IP Options enabled; I need to secure it as best as possible as it will be globally reachable on some of its interfaces. It has a very comprehensive CoPP on it which protects it just fine at the moment, but IP Options opens up a new attack vector.
My initial feeling was simply to drop all IP Options on all interfaces except the ones which are secure and need the options enabled. However, using the following test ACL results in _all_ traffic being dropped:
10 deny ip any any option any-options
20 permit ip any any
Not a single packet gets past this ACL, regardless of having options or no options at all. Yet I’ve seen this exact ACL being referenced many times in various places. Interestingly when I check the TCAM for the vlan in question, it only ever gets programmed up until the point of the line which matches ‘options’. The mask is then set to match everything 0.0.0.0/0.0.0.0 and test to L3_deny_result.
For example, if I use this ACL on vlan 101 inbound:
Extended IP access list TEST
10 permit ip host 1.2.3.4 any
20 deny ip any any option timestamp
30 permit ip host 4.5.6.7 any
Then issue: #remote command switch show tcam interface vlan 101 acl in ip det
* Global Defaults shared
-------------------------------------------------------------------------------------------------------------------
DPort - Destination Port SPort - Source Port TCP-F - U -URG Pro - Protocol
I - Inverted LOU TOS - TOS Value - A -ACK rtr - Router
MRFM - M -MPLS Packet TN - T -Tcp Control - P -PSH COD - C -Bank Care Flag
- R -Recirc. Flag - N -Non-cachable - R -RST - I -OrdIndep. Flag
- F -Fragment Flag CAP - Capture Flag - S -SYN - D -Dynamic Flag
- M -More Fragments F-P - FlowMask-Prior. - F -FIN T - V(Value)/M(Mask)/R(Result)
X - XTAG (*) - Bank Priority
-------------------------------------------------------------------------------------------------------------------
Interface: 101 label: 2 lookup_type: 0
protocol: IP packet-type: 0
+-+-----+---------------+---------------+---------------+---------------+-------+---+----+-+---+--+---+---+
|T|Index| Dest Ip Addr | Source Ip Addr| DPort | SPort | TCP-F |Pro|MRFM|X|TOS|TN|COD|F-P|
+-+-----+---------------+---------------+---------------+---------------+-------+---+----+-+---+--+---+---+
Entries from Bank 0
V 18396 0.0.0.0 0.0.0.0 P=0 P=0 ------ 0 ---- 0 0 -- --- 0-0
M 18404 0.0.0.0 0.0.0.0 0 0 ------ 0 ---- 0 0
R rslt: L3_DENY_RESULT rtr_rslt: L3_DENY_RESULT hit_cnt=0
Entries from Bank 1
V 36250 0.0.0.0 1.2.3.4 P=0 P=0 ------ 0 ---- 0 0 -- C-- 0-0
M 36251 0.0.0.0 255.255.255.255 0 0 ------ 0 ---- 0 0
R rslt: PERMIT_RESULT (*) rtr_rslt: PERMIT_RESULT (*) hit_cnt=0
V 36828 0.0.0.0 0.0.0.0 P=0 P=0 ------ 0 ---- 0 0 -- --- 0-0 <-
M 36836 0.0.0.0 0.0.0.0 0 0 ------ 0 ---- 0 0 <-
R rslt: L3_DENY_RESULT (*) rtr_rslt: L3_DENY_RESULT (*) hit_cnt=1187 <-
There is no sign of the permit for 4.5.6.7 which comes after the line with the options on it.
So my questions are:
1) Why is this ACL not getting past the IP Options entry at 20?
2) What is the recommended method of securing a chassis against IP Options from rogue sources when you only want to accept them on a couple of interfaces?
The lab kit is running 15.1(2)SY1 in the tests shown above.
Any pointers welcome, cheers!
Robert Williams
Custodian Data Centre
Email: Robert at CustodianDC.com
http://www.CustodianDC.com
More information about the cisco-nsp
mailing list