🚀 go-pugleaf

Barry Margolin pointed out that I'd made a really stupid error in my
posting answering Jason Haar's question about access lists for NNTP. I
put a term that should have been on access list 101 on list 102, and
vice-versa. The result would have been that no connections could ever have
been initiated.

A corrected copy of the entire message is below. My apologies to anybody
who was confused.

					-- John B.

To: Jason Haar <j.haar@csc.canterbury.ac.nz>
Cc: cisco@spot.colorado.edu
Subject: Re: ACLs 
In-reply-to: Your message of "Mon, 25 Jan 93 23:09:03 GMT."
             <C1FMz4.I4n@cantua.canterbury.ac.nz> 
Date: Mon, 25 Jan 93 21:39:45 -0800
From: John Bashinski <jbash@cisco.com>

> Currently I have configured our cisco (which is the gateway) to let anyone
> talk to this host on the nntp port, and on any port over 1000 - and visa
> versa for connections from the other direction. This works fine, but means
> that the node is still open for connections over 1000 - which I don't want.
> 
> (just enabling port 119 isn't enough as there are two ports to every
> connection)
> 
> Is there any other ACL set I could use to ensure that _only_ connections
> to .OR. from port nntp were allowed? 

Let me restate the requirement to make sure I understand it. You want to
allow incoming connections only to port 119 on this machine (from any port
on a remote machine), and outgoing connections from this machine only to
port 119 on remote machines. Presumably the incoming restriction is to
protect yourself from ne'er-do-wells on the Internet, and the outgoing
restriction is to protect the Internet from similar ne'er-do-wells inside
your site.

You can do this with the "established" keyword. What "established" does on
an extended access list entry is to let that entry match any packet that's
part of an already-created TCP connection, but not any packet that could
serve to create a new connection. It does this by examining the SYN and RST
bits in the TCP header.

Suppose your internal net is on Ethernet 0, and the outside world is on
Serial 0. Your NNTP host has address 1.2.3.4. You're using access list 101
on Ethernet 0, and access 102 on serial 0. A partial view of your
configuration file might look like this (untested) example:

! Access list 101 is applied to traffic coming in from the outside world
! to the internal network.
!
! The first entry lets machines in the outside world connect to the NNTP
! port on our machine. Anything destined from anywhere to port 119 on
! that machine is allowed.
!
access-list 101 permit tcp 0.0.0.0 255.255.255.255 1.2.3.4 0.0.0.0 eq 119
!
! The second entry lets machines that already have connections to the
! local machine continue to talk to it. Presumably they wouldn't have
! gotten those connections unless the local machine had initiated them.
!
access-list 101 permit tcp 0.0.0.0 255.255.255.255 1.2.3.4 0.0.0.0 established
!
! In the real world, you'd probably want to permit more than the NNTP port,
! and/or allow connections to other machines. In particular, you'd probably
! want to allow ICMP from anywhere to anywhere, and you'd probably need to
! give the outside world TCP and UDP access to your DNS services. You might
! also have some mail hosts that needed to talk to outside hosts.
!
! The second access list is very much like the first...
access-list 102 permit tcp 1.2.3.4 0.0.0.0 0.0.0.0 255.255.255.255 eq 119
access-list 102 permit tcp 1.2.3.4 0.0.0.0 0.0.0.0 255.255.255.255 established
!
interface ethernet 0
ip access-group 101
!
interface serial 0
ip access-group 102

Another common configuration would be to leave out access list 102
entirely, so that the outside world could only connect to port 119 on your
NNTP server, but your own (presumably trusted) host could connect to
anything in the outside world that would accept the connection.

The "established" keyword was introduced in Release 8.2, but there's a
problem with it in some versions. It's unlikely that anybody could actually
exploit the bug to get unauthorized access to anything-- perhaps not
impossible, but certainly very difficult, especially without knowing
proprietary details of how Cisco routers work. The bug *will* sometimes
make legitimate accesses fail.

The bug in question is CSCdi07901. It's fixed in all shipping software,
including 8.3(6-and-above), 9.0(3), and 9.1(2). It was present in 8.2,
8.3(1-5), 9.0(1-2), and 9.1(1). Even if your software has the bug, you can
avoid any incorrect behavior by disabling IP fast switching on the involved
interfaces using the command "no ip route-cache". This will increase the
load on your CPU, but isn't usually a problem, especially for the
relatively slow WAN links where access lists are most often used. If you're
concerned about system load without fast-switching, you can use "show
process" and "show interface" to check for CPU overloading and/or packet
drops. If disabling fast switching causes a load problem for you, you can
order a ROM upgrade from Cisco, or download new net-bootable software via
anonymous FTP from ftp.cisco.com.

The official release-note text for the bug follows--

   If extended access lists are used on an MCI, SCI or cBus interface,
   the IP route cache is enabled, and also the 'established' keyword
   is used, it can be improperly evaluated. This can permit packets
   which should be filtered and exclude packets which should be
   permitted. This behavior was first introduced in 8.2.

If you have any further problems or questions, you should probably send
mail to "tac@cisco.com".

                                   -- J. Bashinski
                                      Cisco Systems