At work we frequently have to alter our Access Control List (ACL), to block any computers with security violations until we can patch the problem. Currently we use a computer that is consoled into our primary network switch. We delete the old list (command "no access-list 101) and copy and paste the new modified ACL into the switch's command line. We do this part 40 or so permit/allow ip commands at a time. Is there an alternate way that we could just tell the switch to permit/allow specific IPs, instead deleting the original and pasting in the new one? EDIT: The switch we use is cisco by brand, not sure of the model
6 Answers
I'm assuming by your syntax that you're talking Cisco IOS. If you have a moderately recent code-level, then instead of
access-list 101 deny ip 10.1.1.1 any
access-list 101 permit ip any any
you can do:
ip access-list extended Name-of-ACL
deny ip 10.1.1.1 any
permit ip any any
and when you "show" it, there will be an access-list with line numbers:
show ip access-lists
Extended IP access list Name-of-ACL
10 deny ip 10.1.1.1 any
20 permit ip any any
Next when you want to insert another IP, you go back into editing the ACL, but this time add a sequence number:
ip access-list extended Name-of-ACL
15 deny ip 192.168.1.1 any
And it will insert it at that place in the ACL. You can even use the word "remark" in place of "permit" or "deny" to place a comment in the list.
show ip access-lists
Extended IP access list Name-of-ACL
10 deny ip 10.1.1.1 any
15 deny ip 192.168.1.1 any
20 permit ip any any

- 238
- 2
- 4
-
I'll try this tonight when I'm at work, yeah I forgot to include details about the system I'm using. – killamjr May 29 '09 at 22:26
-
Because the OS on this switch was pretty old this didn't work – killamjr Jul 18 '09 at 20:37
One alternative model you could do is to use one VLAN for non-infected machines and one for infected machines. This would probably require using DHCP, so minimal reconfiguration has to be done on the infected machine. At that point, you could then use an ACL from the VLAN sub-interface to the net to block access to the Internet, while (ideally) leaving enough holes to download patches or virus updates.
If all you're interested in is to make sure no TCP session can be established externally, you could always just use a blackhole route (a route into Null0) and coupled with reverse-path verification on the inbound router interface, this should be able to stop ALL outbound traffic from the hosts you want to isolate. It may even cause less of a load on the router, as it uses the forwarding engine instead of ACLs (though that depends on the specifics of the router hardware, some of the larger Cisco kit can ACL-filter at wirespeed by compiling the ACL and run it on an ASIC).

- 5,440
- 25
- 24
Unfortunatley, to remove entries, I think you have to "no" the ACL to clear it out.
I've written a lot of PHP to send commands to Cisco equipment using Telnet and SNMP, it would be really easy to automate this task.
I can dig up an example if you're interested.
One way to do this that I really like is instead of trying to edit the list in place to replace it with a new list which includes a timestamp of when it was created.
ip access-list extended acl_name-date_time
It becomes easy to automate this process with some simple scripts to push the new acl to the device and then flip over the interface to using the new list.
Extra features that such a system could include using a DB to store all the acl rules and a web interface for updating them. You can then do things like track who owns that rule, maybe link it to the ticket in your ticket tracking system so you know why it was added. You can also set an expiration time so that temporary rules get removed when they are no longer needed.
I Finally figured out a semi-solution to this, that at least makes editing our ACL less painful. We changed the ASCII settings so it puts the address for our ACL more slowly and makes it to where we can just copy and paste the list in and walk away for awhile.

- 191
- 1
- 2
- 8
I like to keep the ACLs on a central server under revision control. Each ACL is in a separate file named “router-interface-ingress” or “router-interface-egress”. (Ingress/egress refer to our environment, not the router interface direction). The router name is usually munged because two routers named similarly get each ACL.
The ACLs themselves look like this:
no IP access-list extended router-interface-ingress
IP access-list extended router-interface-ingress
permit.....
permit....
deny IP any any
Then to push them to the router, we “copy scp: run” on the router. The acl is deleted and recreated from the RCS master each time.
One trick is to build a culture that engineers know to edit ACLs on the server, not the router. Any acl changes on the router will get blown away by the next push from the server.

- 101
- 2