Posts tagged acls
Using MAC Access-lists
Oct 27th
We ran into this today, and, though I knew it existed, I never actually saw it in the wild. I’m talking about MAC access-lists.
In the example setup, we have a DMZ off of a firewall that contains a whole mess of servers — email, web, ftp, etc. These should all be in the DMZ for sure, but they shouldn’t talk to each other. If a bad guy was able to own my FTP server, he would have a nice platform to use to attack my email server. That’s not cool, so we’ve put in MAC access-lists to help out.
MAC access-lists do just what you think they do; they put access controls on what MAC addresses can talk to what on a particular port. You build a list of permit and deny lines that you want to use to control access and apply them to a port. Sound familiar? Yeah…it does sound a lot like IP ACLs, doesn’t it? Here’s some technical detail for those that care.
- MAC ACLs can be numbered or named. The range for numbered ACLs is 700-799. The naming conventions follow the same rules as an IP list.
- A port must be a in access mode before you can apply a MAC ACL. You can’t apply them to trunks.
- You can use the any and host directives instead of using MAC/mask combos.
- If you’re feeling froggy, you can actually do a MAC/mask combo, but, since the MACs on your hosts probably aren’t sequential, I don’t see the point.
Let’s build one. Suppose we have a host with the MAC 1111.2222.3333 plugged into a switch on port F0/1. It is a web server and needs access to the mail server on the same network (4444.5555.6666) and the firewall (9999.8888.7777) as a gateway. How do we set it up so that the web server can only speak to those guys?
mac access-list extended WEBSERVER
permit host 1111.2222.3333 host 4444.5555.6666
permit host 1111.2222.3333 host 9999.8888.7777int f0/1
mac access-group WEBSERVER in
Now that host can only speak to those two MACs on layer 2. Pretty simple yet again. There are some things to note, though.
First of all, this just keeps this host from talking to other MACs on the same network and does nothing to keep packets from other host from reaching our webserver. Though the webeserver won’t be able to respond, one could argue that it’s best practice to apply an outbound MAC ACL that mirrors the inbound.
There’s also an issue of broadcast. Say that the webserver is now trying to send a packet to the mail server to send an alert. One of the first things that it will do is to send a broadcast (ffff.ffff.ffff) asking for an ARP reply. Guess what? That MAC isn’t in the ACL. You could put static ARP entries on the boxes, but it may be easier just to allow the host to talk to the broadcast.
Don’t get layer-2 security mixed up with layer-3 security. This restricts access on (usually) a single IP network where you don’t have routers or firewalls between hosts. Use the old-fashioned IP ACL for between networks and MAC ACLs for between hosts on a network.
Questions? Comments? Bribes? Free money? Send them all my way.
ACLs and HSRP, BGP, OSPF, VRRP, GLBP…
Jun 12th
Here’s a handy list of ACL entries to allow your devices to speak routing protocols, availability protocols, and some other stuff. We’ll assume you have ACL 101 applied to your Ethernet inbound; your Ethernet has an IP of 192.168.0.1.
- BGP : Runs on TCP/179 between the neighbors
access-list 101 permit tcp any host 192.168.0.1 eq 179
- EIGRP : Runs on its own protocol number from the source interface IP to the multicast address of 224.0.0.10
access-list 101 permit eigrp any host 224.0.0.10
- OSPF : Runs on its own protocol number from the source interface IP to the multicast address of 224.0.0.5; also talks to 224.0.0.6 for DR/BDR routers
access-list 101 permit ospf any host 224.0.0.5
access-list 101 permit ospf any host 224.0.0.6
- HSRP : Runs on UDP/1985 from the source interface IP to the multicast address of 224.0.0.2. I’ve seen in the past that it runs on UDP/1985, but I didn’t find any evidence of that in a quick Google for it. Can someone verify?
access-list 101 permit udp any host 224.0.0.2 eq 1985
- HSRP version 2 : Runs on UDP/1985 from the source interface IP to the multicast address of 224.0.0.102.
access-list 101 permit udp any host 224.0.0.2 eq 1985
- RIP : Runs on UDP/520 from the source interface IP to the multicast address of 224.0.0.9
access-list 101 permit udp any host 224.0.0.9 eq 520
- VRRP : Runs on its own protocol number from the source interface IP to the multicast address of 224.0.0.18
access-list 101 permit 112 any host 224.0.0.18
- VRRP-E : This is a Foundary thing according to readers, and runs on UDP/8888 from the source interface IP to the multicast address of 224.0.0.2
access-list 101 permit 112 any host 224.0.0.2 eq 8888
- GLBP : Runs on UDP from the source interface IP to the multicast address of 224.0.0.102
access-list 101 permit udp any host 224.0.0.102
- DHCPD (or bootps) : Runs on UDP/67 from 0.0.0.0 (since the client doesn’t have an address yet) to 255.255.255.255 (the broadcast).
access-list 101 permit udp any host 255.255.255.255 eq 67
If anyone else has one to add, do so in the comments.
Commenting Access-lists
Mar 12th
There’s a very-overlooked feature of access-lists — the remark. Yes, this is very basic, but it’s worth mentioning, as it has saved me anguish time and time again.
I use remarks to document each line of an ACL (on IOS, PIX, FWSM, ASA, etc.) so that when I go back later, I actually know what I did. They’re simple to use, and, I promise you, you’ll thank yourself for using it when the CTO asks why access to TCP/80 is open from the Internet to the development server.
Easy to use.
access-list 101 remark This line allows access from the Internet to the development server. See ticket 1234
access-list 101 permit tcp any host 1.2.3.4 eq 80
Now, when you get asked the inevitable question, you can look at the line and know to check ticket 1234 for more information. The remark is just a string, so you can put what you want. I like to put source and destination hostnames, protocol/port, ticket number, and date/time the line was entered for reference like this.
access-list 2001 remark *** I’net — HTTP -> dev.example.com, Ticket 1234, 12Mar2008-0853 ***
It works with the ip access-list command as well.
ip access-list extended INBOUND
remark *** I’net — HTTP -> dev.example.com, Ticket 1234, 12Mar2008-0853 ***
It might be a good idea to use a remark to document what the ACL itself does. For example, on a firewall with 28974 interfaces, you might want to do something like this.
access-list DMZ1_OUT remark This ACL allows traffic out of the DMZ interface
access-list DMZ1_OUT remark *** ….
access-list DMZ1_OUT permit …
