dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
484

SimplePanda
BSD
Premium Member
join:2003-09-22
Montreal, QC

SimplePanda

Premium Member

Control plane lockdown

Does anyone have an opinion on the best way to lock down the control plane on IOS 15+?

I've made an inverted access-list (deny traffic I want, permit traffic I want to block), then made a class-map and a policy, then assigned this as an inbound policy on control-plane.

It -seems- to work, but it's not consistent. For example, there is a random port 21 (FTP) server running on my router (doesn't send output - just connects) that I can't filter out this way. It doesn't seem to be in the control-plane as a result.

Additionally, IPV6 filtering of the control plane is effectively broken as far as I can tell. "show access-list" never shows my match terms increasing in count.

I could scrap control-plane filtering completely and just use access lists to filter all of my incoming interfaces. This means I'd have to do so using the specific destination IP's of my router at each interface and this means making 2x access-lists (IPv4 and IPv6) x N interfaces (one for each interface) to keep from interfering with traffic just forwarding through the router.

On Junos this is really straightforward - just put an inbound filter on the loopback interface. All control level ports are filterable at lo0 no matter how many interfaces are coming into the router and no matter how many interfaces have IP addresses that the underlying router responds to.

On IOS, it feels like control-plane policies are a little half baked as far as IPv6 support goes.

Any thoughts?
HELLFIRE
MVM
join:2009-11-25

HELLFIRE

MVM

Got your config we can look at SimplePanda See Profile ?

Cisco's White Paper on CPP, and a Best Practices Guide from Cisco for your reference.
said by SimplePanda:

I've made an inverted access-list (deny traffic I want, permit traffic I want to block), then made a class-map and a policy, then assigned this as an inbound policy on control-plane.

Not quite clear on that... again, can you supply the config, and what platform is this? To KISS, permit what (management)
traffic is hitting the control plane with the ACL (so the router can match and police it), and forget putting in any other entries.

My 00000010bits

Regards

SimplePanda
BSD
Premium Member
join:2003-09-22
Montreal, QC

SimplePanda

Premium Member

said by HELLFIRE:

Got your config we can look at SimplePanda See Profile ?

Cisco's White Paper on CPP, and a Best Practices Guide from Cisco for your reference.

said by SimplePanda:

I've made an inverted access-list (deny traffic I want, permit traffic I want to block), then made a class-map and a policy, then assigned this as an inbound policy on control-plane.

Not quite clear on that... again, can you supply the config, and what platform is this? To KISS, permit what (management)
traffic is hitting the control plane with the ACL (so the router can match and police it), and forget putting in any other entries.

My 00000010bits

Regards

Believe me, I've read both of those guides. And about half a dozen more. I'm getting what I want (more or less) if only IPv4 is a factor. It's when IPv6 filtering is added to the control-plane policy that it all falls apart. IPv4 filters; IPv6 does not.

Sigh.

I'll have to sanitize a config to post it. Will do tomorrow.

Thanks!
HELLFIRE
MVM
join:2009-11-25

HELLFIRE to SimplePanda

MVM

to SimplePanda
...admittedly I've been avoiding IPv6 myself, so I haven't messed with IPv6 anything IOS-wise.
Don't know if anyone has anything else to offer on this...

Regards

SimplePanda
BSD
Premium Member
join:2003-09-22
Montreal, QC

SimplePanda

Premium Member

Ok, so the general way to block/suppress traffic to control-plane is as follows. Assume that 10.0.0.1 is a management machine.

This is a simple example that allows only SSH into the control-plane. My actual example has a few other input allowances.

access-list 101 deny tcp host 10.0.0.1 eq 22
access-list 101 deny icmp any any 
access-list 101 permit ip any any
 

I know this looks backwards in that I'm doing is creating an access-list that allows traffic I want to block through so that the policy-map can block it. All other traffic that doesn't match (the allowed traffic) is not matched and therefore goes through.

Next, build a class map:

class-map match-all filter-control-plane
  match access-group 101
 

Next, create a policy map:

policy-map policy-control-plane
  class filter-control-plane
    drop
 

Then finally, apply it to the control-plane:

control-plane
  service-policy input policy-control-plane
 

So, this works fine and as expected. The issues are:

- Something in IOS is answering port 21. It's no in the control-plane so this policy-map on the control plane doesn't filter for it.

- I can create multiple access lists. I can use these lists to create either multiple class-maps or I can do a match-any and match multiple access lists inside the same class-map. Of course if you do multiple class-maps you have to add multiple class X drop statements in the policy-map. All of this works fine... UNLESS one of the access lists is an IPv6 list. The configuration "works" but in production it doesn't work. IPv6 packets aren't being matched properly.

I'm thinking at this point that IPv6 control plane policing just doesn't work properly in IOS 15.1 (4-M2) and I've resorted to just putting ingress filters (with multiple statements accounting for the various IP's associated with the router interfaces).
HELLFIRE
MVM
join:2009-11-25

HELLFIRE to SimplePanda

MVM

to SimplePanda
said by SimplePanda:

access-list 101 deny tcp host 10.0.0.1 eq 22
access-list 101 deny icmp any any
access-list 101 permit ip any any

...you sure about that? That doesn't match any TCP/22 traffic from host 10.0.0.1 and any ICMP traffic but matches
everything else for COPP policy policy-control-plane.

Just for gits and shiggles, did you explicitly tell COPP to not match on TCP/21? That'd be my last thought....

My 00000010bits

Regards
HELLFIRE

HELLFIRE

MVM

said by SimplePanda:

- Something in IOS is answering port 21.

Just as a crazy thought, check if you have the FTP service / server running on the device...

Regards

SimplePanda
BSD
Premium Member
join:2003-09-22
Montreal, QC

SimplePanda to HELLFIRE

Premium Member

to HELLFIRE
said by HELLFIRE:

said by SimplePanda:

access-list 101 deny tcp host 10.0.0.1 eq 22
access-list 101 deny icmp any any
access-list 101 permit ip any any

...you sure about that? That doesn't match any TCP/22 traffic from host 10.0.0.1 and any ICMP traffic but matches
everything else for COPP policy policy-control-plane.

Just for gits and shiggles, did you explicitly tell COPP to not match on TCP/21? That'd be my last thought....

My 00000010bits

Regards

Yeah; I'm not trying to throttle or shape the traffic that gets matched in the ACL, I'm trying to block it. The policy-map "drop" statement then blocks the traffic for the policy filter.

Is there another way to do this directly?
HELLFIRE
MVM
join:2009-11-25

HELLFIRE to SimplePanda

MVM

to SimplePanda
said by SimplePanda:

Yeah; I'm not trying to throttle or shape the traffic that gets matched in the ACL, I'm trying to block it.

May be better to use interface ACLs then, as COPP is more to throttle the traffic going
to the CPU. If you're trying to lock down your VTY lines, a VTY ACL may be better as well.

My 00000010bits

Regards

SimplePanda
BSD
Premium Member
join:2003-09-22
Montreal, QC

SimplePanda

Premium Member

said by HELLFIRE:

said by SimplePanda:

Yeah; I'm not trying to throttle or shape the traffic that gets matched in the ACL, I'm trying to block it.

May be better to use interface ACLs then, as COPP is more to throttle the traffic going
to the CPU. If you're trying to lock down your VTY lines, a VTY ACL may be better as well.

My 00000010bits

Regards

Basically this is what I've done... interface ACL's on my WAN link. It's a bit more work and more lines of config but it gets the job done.

Wish IOS would adopt a JUNOS-ish approach of allowing all control-plane services to be filtered via a single access-group (or collection of them). Separates the control-plane / management-plane security from the interfaces and removes ACL processing from the vast majority of traffic in my case (ACL's aren't needed until destination traffic is actually hitting control/management).

Thanks for your input.

-d

TomS_
Git-r-done
MVM
join:2002-07-19
London, UK

TomS_ to SimplePanda

MVM

to SimplePanda
I believe HELLFIRE is correct.

COPP is as the name suggests, Control Plane Policing. Policing is normally in regards to throughput management, not filtering.

Dont apply local router policy via your Interfaces - its just the wrong idea. Policy applied to interfaces should be for enforcement between network segment boundaries. Apply local router policy on the router itself, so for VTYs that would be access groups on your VTYs.

I do like the Juniper method of actually applying your control plane ACL on the Loopback interface. Seems a lot cleaner and results in a single ACL that can cover the entire router, instead of a handfull of small ACLs to cover different services.

SimplePanda
BSD
Premium Member
join:2003-09-22
Montreal, QC

SimplePanda

Premium Member

Thanks TomS_!

tubbynet
reminds me of the danse russe
MVM
join:2008-01-16
Gilbert, AZ

tubbynet to TomS_

MVM

to TomS_
exactly.
copp isnt meant as a box-lockdown. it is meant to ensure continuity of control-plane services during times of high cpu-load.

if you grep [c-nsp] or so, experts from arbor networks will talk about a comprehensive network management and protection policy.

q.