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@adelaide.edu.au South Australia