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: [email protected]
http://www.CustodianDC.com
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
