Security Incidents mailing list archives

RE: Traffic from private or unroutable addresses


From: "Obert, Jack E." <JObert () sprg smhs com>
Date: Tue, 26 Jun 2001 14:58:23 -0500

Probing ports with Acks is a good way to determine if you've got a Cisco
Router using an Access list with the 'Established' variable enabled...  I
can't answer the 10.x.x.x address question satisfactorily though...

 
Jack E. Obert, GSEC 
Technical Information Security Officer 
St. John's Health System 
 


-----Original Message-----
From: Russell Fulton [mailto:r.fulton () auckland ac nz]
Sent: Monday, June 25, 2001 7:09 PM
To: Incidents list
Subject: Traffic from private or unroutable addresses


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 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


Current thread: