Extended Access Lists

TCP Access Lists

TCP access lists support both source and destination TCP ports, which can be specified using either the port number or mnemonic. Port numbers or name must be preceded with relational operators, such as those shown in the following code output:

 Rtr1(config)#access-list 101 deny tcp host 10.0.0.97 ?
 ?eq ??????Match only packets on a given port number
 ?gt ??????Match only packets with a greater port number
 ?lt ??????Match only packets with a lower port number
 ?neq ?????Match only packets not on a given port number
 ?range ???Match only packets in the range of port numbers

After choosing an operator, specify a mnemonic or port number like those shown in the following code output for the TCP port names. The port number appears in parentheses. Because the mnemonics make the access list easier to understand for anyone who might need to support the device later, it’s a good idea to use them when they’re available.

 Rtr1(config)#access-list 101 deny tcp host 10.0.0.97 eq ?
 ?<0-65535> ???Port number
 ?bgp ?????????Border Gateway Protocol (179)
 ?chargen ?????Character generator (19)
 ?cmd ?????????Remote commands (rcmd, 514)
 ?daytime ?????Daytime (13)
 ?discard ?????Discard (9)
 ?domain ??????Domain Name Service (53)
 ?echo ????????Echo (7)
 ?exec ????????Exec (rsh, 512)
 ?finger ??????Finger (79)
 ?ftp ?????????File Transfer Protocol (21)
 ?ftp-data ????FTP data connections (used infrequently, 20)
 ?gopher ??????Gopher (70)
 ?hostname ????NIC hostname server (101)
 ?ident ???????Ident Protocol (113)
 ?irc ?????????Internet Relay Chat (194)
 ?klogin ??????Kerberos login (543)
 ?kshell ??????Kerberos shell (544)
 ?login ???????Login (rlogin, 513)
 ?lpd ?????????Printer service (515)
 ?nntp ????????Network News Transport Protocol (119)
 ?pim-auto-rp ?PIM Auto-RP (496)
 ?pop2 ????????Post Office Protocol v2 (109)
 ?pop3 ????????Post Office Protocol v3 (110)
 ?smtp ????????Simple Mail Transport Protocol (25)
 ?sunrpc ??????Sun Remote Procedure Call (111)
 ?syslog ??????Syslog (514)
 ?tacacs ??????TAC Access Control System (49)
 ?talk ????????Talk (517)
 ?telnet ??????Telnet (23)
 ?time ????????Time (37)
 ?uucp ????????Unix-to-Unix Copy Program (540)
 ?whois ???????Nicname (43)
 ?www ?????????World Wide Web (HTTP, 80)

In the following extended ACL example, the first statement blocks network hosts in 192.168.3.0 from accessing the web servers in 192.168.1.0. The second statement blocks the same hosts from accessing any FTP servers. The third statement blocks an address from using the Telnet feature to reach the 192.168.1.0 network:

 access-list 101 deny tcp 192.168.3.0 0.0.0.255 192.168.1.0 0.0.0.255 eq www
access-list 101 deny tcp 192.168.3.0 0.0.0.255 any eq ftp
access-list 101 deny tcp any 192.168.1.0 0.0.0.255 any eq telnet
access-list 101 permit ip any any

The last statement demonstrates an important concept. Recall that any access list changes the default operation from a Permit Anything mode to a Deny Anything mode, except what is explicitly allowed. Implicit in the previous lines is that all protocols are denied, not only TCP. If the final statement were access-list 101 permit tcp any any, all remaining TCP ports would, in fact, be permitted, but all UDP and ICMP packets would remain blocked. While this might be the objective, this is a common mistake with people new to ACLs or those in a hurry.

TCP’s Established Option

The Established option is a TCP-only feature that can use the connection-oriented attributes of the TCP to limit traffic coming into a network or network segment to those sessions that originated from within that network. The established condition is only true if the ACK (acknowledge) or RST (Reset) bits are set to one in the TCP header, indicating an already established connection. A packet with no ACK or RST bit set, but a SYN (synchronize) bit set to one is used to establish a new connection and can then be denied. Figure A-4 demonstrates the three-step “handshake” TCP uses to establish a connection.

Figure A-4: TCP three-way handshake to establish a session

The following output demonstrates allowing any host to respond to FTP and Telnet requests that originated within the 192.168.1.0 network, but blocks all other TCP packets.

 access-list 101 permit tcp any eq www 192.168.1.0 0.0.0.255 eq ftp established
access-list 101 permit tcp any 192.168.1.0 0.0.0.255 any eq telnet established
access-list 101 deny ??tcp any any
access-list 101 permit ip ?any any

The Established option can help reduce the risk of a common type of hacker attack that buries a host in SYN requests, preventing it from handling normal business. Because a sophisticated hacker can manipulate the TCP header bits, this tool needs support from other tools to protect against that threat.

Look over the following ACL statement using the established option. This is a common first effort when trying to limit Web activity to those sessions originating within the network. So what’s wrong with the statement?

 access-list 101 permit tcp any 192.168.1.0 0.0.0.255 eq www established

Remember, www is an alias for port 80. A web session originating inside would use port 80 as the destination, but would designate a port above 1024, such as 1065, as the source port. This means the returning packet would have port 80 as the source and port 1065 as the destination. The ACL is looking for port 80 as the destination. The following output might work better:

 access-list 101 permit tcp any eq www 192.168.1.0 0.0.0.255 established

When you work with the established feature, it’s important to make sure you understand what the mnemonic stands for and, if you use the port numbers, what any port numbers stand for. Another approach, which allows any established sessions, but blocks all other TCP traffic, is represented in the following code lines:

 access-list 101 permit tcp any 192.168.1.0 0.0.0.255 established
access-list 101 deny ??tcp any any

Note?

Source-port filtering, the process of filtering data on the source port of a packet, isn’t secure because a skilled hacker could easily change a source port on a packet, which could then pass through the filter.

UDP Access Lists

The UDP access list, like TCP, supports both source and destination ports, and, like TCP, uses the same relational operators to define the mnemonic or port numbers. The following code output shows some of the most common UDP port names:

 Rtr1(config)#access-list 101 permit udp any eq ?
 ?<0-65535> ???Port number
 ?biff ????????Biff (mail notification, comsat, 512)
 ?bootpc ??????Bootstrap Protocol (BOOTP) client (68)
 ?bootps ??????Bootstrap Protocol (BOOTP) server (67)
 ?discard ?????Discard (9)
 ?dnsix ???????DNSIX security protocol auditing (195)
 ?domain ??????Domain Name Service (DNS, 53)
 ?echo ????????Echo (7)
 ?  isakmp ??????Internet Security Association and Key Management Protocol (500)
 ?mobile-ip ???Mobile IP registration (434)
 ?nameserver ??IEN116 name service (obsolete, 42)
 ?netbios-dgm ?NetBios datagram service (138)
 ?netbios-ns ??NetBios name service (137)
 ?netbios-ss ??NetBios session service (139)
 ?ntp ?????????Network Time Protocol (123)
 ?pim-auto-rp ?PIM Auto-RP (496)
 ?rip ?????????Routing Information Protocol (router, in.routed, 520)
 ?snmp ????????Simple Network Management Protocol (161)
 ?snmptrap ????SNMP Traps (162)
 ?sunrpc ??????Sun Remote Procedure Call (111)
 ?syslog ??????System Logger (514)
 ?tacacs ??????TAC Access Control System (49)
 ?talk ????????Talk (517)
 ?tftp ????????Trivial File Transfer Protocol (69)
 ?time ????????Time (37)
 ?who ?????????Who service (rwho, 513)
 ?xdmcp ???????X Display Manager Control Protocol (177)

In the following extended ACL example, the first statement blocks network hosts in 192.168.3.0 from sending SNMP packets into the 192.168.1.0 network. The second statement blocks the same hosts from accessing any TFTP servers. The third statement blocks any RIP routing updates from going to the 192.168.1.0 network.

 access-list 101 deny udp 192.168.3.0 0.0.0.255 192.168.1.0 0.0.0.255 eq snmp
access-list 101 deny udp 192.168.3.0 0.0.0.255 any eq tftp
access-list 101 deny udp any 192.168.1.0 0.0.0.255 any eq rip
access-list 101 permit ip any any

The final statement permits the remaining UDP packets, plus all TCP and ICMP packets.

ICMP Access Lists

ICMP (Internet Control Message Protocol—RFC 792) access list syntax doesn’t use port numbers, but adds options to allow filtering on ICMP messages. The actual syntax for filtering UDP is as follows:

access-list acl# {permit | deny} icmp {source wildcard | any} {destination wildcard |
any} [icmp-type | [[icmp-type icmp-code] | [icmp-message]] [precedence precedence]
[tos tos] [log | log-input] [options]

The following code includes the symbolic names (since IOS v 10.3) that can be used to filter ICMP traffic:

 Rtr1(config)#access-list 101 permit icmp any any ?
 ?<0-255> ?????????????????????ICMP message type
 ?administratively-prohibited ?Administratively prohibited
 ?alternate-address ???????????Alternate address
 ?conversion-error ????????????Datagram conversion
 ?dod-host-prohibited ?????????Host prohibited
 ?dod-net-prohibited ??????????Net prohibited
 ?echo ????????????????????????Echo (ping)
 ?echo-reply ??????????????????Echo reply
 ?general-parameter-problem ???Parameter problem
 ?host-isolated ???????????????Host isolated
 ?host-precedence-unreachable ?Host unreachable for precedence
 ?host-redirect ???????????????Host redirect
 ?host-tos-redirect ???????????Host redirect for TOS
 ?host-tos-unreachable ????????Host unreachable for TOS
 ?host-unknown ????????????????Host unknown
 ?host-unreachable ????????????Host unreachable
 ?information-reply ???????????Information replies
 ?information-request ?????????Information requests
 ?log ?????????????????????????Log matches against this entry
 ?log-input ???????????????????Log matches against this entry, 
 ??????????????????????????????including input interface
 ?mask-reply ??????????????????Mask replies
 ?mask-request ????????????????Mask requests
 ?mobile-redirect ?????????????Mobile host redirect
 ?net-redirect ????????????????Network redirect
 ?net-tos-redirect ????????????Net redirect for TOS
 ?net-tos-unreachable ?????????Network unreachable for TOS
 ?net-unreachable ?????????????Net unreachable
 ?network-unknown ?????????????Network unknown
 ?no-room-for-option ??????????Parameter required but no room
 ?option-missing ??????????????Parameter required but not present
 ?packet-too-big ??????????????Fragmentation needed and DF set
 ?parameter-problem ???????????All parameter problems
 ?port-unreachable ????????????Port unreachable
 ?precedence ??????????????????Match packets with given precedence value
 ?precedence-unreachable ??????Precedence cutoff
 ?protocol-unreachable ????????Protocol unreachable
 ?reassembly-timeout ??????????Reassembly timeout
 ?redirect ????????????????????All redirects
 ?router-advertisement ????????Router discovery advertisements
 ?router-solicitation ?????????Router discovery solicitations
 ?source-quench ???????????????Source quenches
 ?source-route-failed ?????????Source route failed
 ?time-exceeded ???????????????All time exceededs
 ?timestamp-reply ?????????????Timestamp replies
 ?timestamp-request ???????????Timestamp requests
 ?tos ?????????????????????????Match packets with given TOS value
 ?traceroute ??????????????????Traceroute
 ?ttl-exceeded ????????????????TTL exceeded
 ?unreachable ?????????????????All unreachables

RFC 1812 dictates that traffic denied by filtering (ACL) will cause an ICMP Administratively Prohibited message to be sent to the sender, using the sender’s address as destination and the filtering router interface address as source. While this might be informative to the sender, it might not be a good security practice for the network protected by the router. Not sending this message back to external users might be better because of the implication that something is worth protecting or hacking—depending on your point of view. One solution would be to deny ICMP Administratively Prohibited messages outbound at the external interface.

In the following extended ACL example, if the ACL is applied to the outbound traffic on a border router, the first statement blocks any echo replies out of the network. The statement literally prevents ping responses, denying the sender connectivity information about the address. If you ping www.Microsoft.com, you can see this policy in effect. The second statement blocks ICMP Administratively Prohibited messages from notifying the sender that an ACL discarded their packets.

 access-list 101 deny icmp any any echo-reply
access-list 101 deny icmp any any administratively-prohibited
access-list 101 permit ip any any

The final statement permits the remaining ICMP packets, plus all TCP and UDP packets.