Every few months we see posts to this list about traffic from various private or unroutable addresses, e.g. 10.0.0.0/8 and 192.168.0.0/16. Here is an example of non malicious traffic from such a source. I'll use argus output to tell this story... Today I picked up what appeared to be a host scan from 10.0.0.107: bin/ra -AIncr data/2001.06.25/argus-2001.06.25.14.00.gz -Zb host 10.0.0.107 25 Jun 01 14:14:28 tcp 10.0.0.107.80 ?> 130.216.191.46.1632 5 0 7300 0 A_ 25 Jun 01 14:14:30 tcp 10.0.0.107.80 ?> 130.216.191.46.1653 5 0 7300 0 A_ 25 Jun 01 14:14:31 tcp 10.0.0.107.80 ?> 130.216.191.46.1690 5 0 7300 0 A_ 25 Jun 01 14:14:33 tcp 10.0.0.107.80 ?> 130.216.191.46.1748 5 0 7300 0 A_ 25 Jun 01 14:14:34 tcp 10.0.0.107.80 ?> 130.216.191.46.1772 5 0 7300 0 A_ 25 Jun 01 14:14:36 tcp 10.0.0.107.80 ?> 130.216.191.46.1807 5 0 7300 0 A_ 25 Jun 01 14:14:38 tcp 10.0.0.107.80 ?> 130.216.191.46.1862 5 0 7300 0 A_ 25 Jun 01 14:14:40 tcp 10.0.0.107.80 ?> 130.216.191.46.1927 5 0 7300 0 A_ 25 Jun 01 14:14:42 tcp 10.0.0.107.80 ?> 130.216.191.46.1957 5 0 7300 0 A_ 25 Jun 01 14:14:45 tcp 10.0.0.107.80 ?> 130.216.191.46.2016 5 0 7300 0 A_ 25 Jun 01 14:14:49 tcp 10.0.0.107.80 ?> 130.216.191.46.2087 5 0 7300 0 A_ 25 Jun 01 14:14:50 tcp 10.0.0.107.80 ?> 130.216.191.46.2111 5 0 7300 0 A_ 25 Jun 01 14:14:55 tcp 10.0.0.107.80 ?> 130.216.191.46.2186 5 0 7300 0 A_ 25 Jun 01 14:14:56 tcp 10.0.0.107.80 ?> 130.216.191.46.2213 5 0 7300 0 A_ 25 Jun 01 14:14:57 tcp 10.0.0.107.80 ?> 130.216.191.46.2237 5 0 7300 0 A_ 25 Jun 01 14:15:06 tcp 10.0.0.107.80 ?> 130.216.191.46.2448 5 0 7300 0 A_ 25 Jun 01 14:15:07 tcp 10.0.0.107.80 ?> 130.216.191.46.2468 5 0 7300 0 A_ But why would some probe ports with ACKs (A_ means that source sent a packet that had ACK set and no other flags, in this case there were 5 packets with a total of 7300 bytes of tcp data -- no replies). lets look at all traffic to or from 130.216.191.46 (a large web proxy) on a couple of these ports: bin/ra -AIncr data/2001.06.25/argus-2001.06.25.14.00.gz -Zb host 130.216.191.46 and port 2016 25 Jun 01 14:14:41 tcp 130.216.191.46.2016 -> 64.47.39.100.80 9 11 307 9187 FSRPA_FSRPA 25 Jun 01 14:14:45 tcp 10.0.0.107.80 ?> 130.216.191.46.2016 5 0 7300 0 A_ bin/ra -AIncr data/2001.06.25/argus-2001.06.25.14.00.gz -Zb host 130.216.191.46 and port 2087 25 Jun 01 14:14:45 tcp 130.216.191.46.2087 -> 64.47.39.100.80 9 10 307 7300 FSRPA_FSRPA 25 Jun 01 14:14:49 tcp 10.0.0.107.80 ?> 130.216.191.46.2087 5 0 7300 0 A_ Hmm.... in both case we see an outgoing tcp session to port 80 on 64.47.39.100 which terminated normally (F in the status field indicates that FINs were exchanged). Followed 4 seconds later by a stream of incoming ACKs to the original source port from the an address in 10.0.0.0/8. I have seen many variations on this theme where sessions to a web server appear to terminate normally and then (up to 5 minutes later) we see either RSTs or ACK coming in from some other address to the original source port on the host that originated the session. My guess is that there are a whole lot of different causes for these problems and many different products involved. What they all have in common is that they result from imperfect systems that break the original end-to-end connectivity IP model. Such devices include NAT enabled firewalls and load balancers. Russell Fulton, Computer and Network Security Officer The University of Auckland, New Zealand This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Tue Jun 26 2001 - 10:50:24 PDT