Even more unusual traffic

Tue Oct 20 02:37:46 UTC 1998

Jesse Whyte wrote:
> I apologize for sending three messages, but in the review
> of our access-list violations, I have discovered even more
> odd and unusual traffic...
> 
> %SEC-6-IPACCESSLOGP: list 102 denied udp 10.10.10.10(0) ->
> 20.20.20.20(0), 2 packets
> 
> IANA lists port 0 as reserved (failing to note what it is
> reserved for), so why am I seeing this traffic in the
> wild?  What is its function, both as a source port and a
> destination port?  And more importantly, why is someone
> trying to access it on my primary DNS server?

You should be aware that Cisco access lists report port 0
unless a port is explicity mentioned in an access list.

That is, coding:

  access-list 100 deny ip 10.0.0.0 0.255.255.255 any log

will report 0 as the port, but coding

  access-list 100 deny tcp 10.0.0.0 0.255.255.255 any range 0 65535 log
  access-list 100 deny udp 10.0.0.0 0.255.255.255 any range 0 65535 log
  access-list 100 deny ip 10.0.0.0 0.255.255.255 any log

will give correct port numbers for TCP and UDP.

This is a side-effect of the access list evaluation
optimiser.

We also have an interest in denied packets, so we policy
route the packets to an dedicated interface.  We then have a
packet sniffer permanently located on that interface that
decodes and records the entire packet contents.  This has
proven to be extremely useful.

Finally, one last hint.  If you permit but log outgoing
traffic sent to class C, B and A boundaries then you will
get at least one log entry generated by people within your
network launching SMURF attacks.  If you locate the access
list on the last-hop routers, then "log-input" will give the
ethernet address of the offender's machine.  This is very
handy for routers attached to public-access computing labs.

! Anything to a null or broadcast address on the Internet is
! suss.
!
!    We don't know the network masks of other networks.
!
!    But we do known at least one broadcast address in
!    other networks -- the one at the class boundary.
!    By logging this packet, we can take administrative
!    action against the user.
!
!    Unfortunately, CIDR supernetting means that a class ABC
!    broadcast *might* be a valid host address (the odds of
!    the are exceedingly small), but to be compliant we have
!    to allow the packet through.
!
!    These statements also log traffic to the deprecated
!    0.0.0.0 `broadcast' address.  Not a problem in our
!    network, as we want to contact those people about
!    configuring their IP stack correctly.  Other networks
!    may need an initial statement
!      access-list 101 permit ip any host 0.0.0.0
!
!    You may also need to permit and not log your own network's
!    broadcast address.  However, for a class B subnetted
!    network like ours, it is better never to allocate
!    this address (and by extension, the highest-numbered
!    subnet), but log all traffic to it.  This identifies
!    all machines that incorrectly use the default class B
!    subnetwork mask 255.255.0.0 rather than the correct
!    subnet mask.
!
! Class A
!   Null: 0xxxxxxxx 00000000 00000000 00000000
access-list 101 permit ip any 0.0.0.0 127.0.0.0 log-input
!   Broadcast: 0xxxxxxxx 11111111 11111111 11111111
access-list 101 permit ip any 0.255.255.255 127.0.0.0 log-input
! Class B
!   Null: 10xxxxxx xxxxxxxx 00000000 00000000
access-list 101 permit ip any 128.0.0.0 63.255.0.0 log-input
!   Broadcast: 10xxxxxx xxxxxxxx 11111111 11111111
access-list 101 permit ip any 128.0.255.255 63.255.0.0 log-input
! Class C
!   Null: 110xxxxx xxxxxxxx xxxxxxxx 00000000
access-list 101 permit ip any 192.0.0.0 31.255.255.0 log-input
!   Broadcast: 110xxxxx xxxxxxxx xxxxxxxx 11111111
access-list 101 permit ip any 192.0.0.255 31.255.255.0 log-input

Cheers,
glen

-- 
 Glen Turner                               Network Specialist
 Tel: (08) 8303 3936          Information Technology Services
 Fax: (08) 8303 4400         The University of Adelaide  5005
 Email: glen.turner at adelaide.edu.au           South Australia