ra output intrepretation

[Carter Bullard]

Hey Russell,
   The detail and the non-detail argi are consistent
in their reporting, a ping volley and then a TCP
packet with a reset.  It should be impossible for the
probe to react packets that it promiscuously reads,
as these packets don't go to the communication stacks,
so lets eliminate that up front.

   I believe that you are seeing connectivity between
these two machines, on both ICMP and TCP protocols.
Since the "hidden" machine's responses are what would
be predicted by protocol, there isn't any evidence
to suggest that you shouldn't trust the argi() data.
And since you see evidence on two independent protocols,
the best conclusion is that the filter scheme is
inappropriate for the policy.

   If this really beings to bug you and you want to
dig further, I would recommend two additional things
that I would look at to additionally validate this
conclusion.  Use the -g option on the ra() to see
what the delay is for the Pings and the TCP packets.
They should be order of magnitude the same.  This may
suggest that the same target machine is being hit.
Also look at the TTL's for the packets.  Both the
source and destination TTL's should be the same for
both flows.  If they aren't the same then you might
be able to say that more than one host is involved.
Use fullra() to get the TTL values.


   The TCP flags for this connection are completely
predictable. This is  ecause so many access control filter 
schemes only filter TCP SYN packets (the notion being
that if you can't establish a TCP connection then TCP
is useless.  This is of course not true, as covert
channels can readily be established through these types
of filter firewalls).  In order to exploit this filter
characteristic, some scanning elements send TCP data packets
as a probe packet (no SYN bit set) since they will have
a better chance of getting to the target.  Actually this
is the preferred scanning technique, since there is no host
support for indicating that a "stray" packet was received
on a non-exisiting TCP, and so its pretty much undetectable
from the host's perspective.  Had it been a SYN packet,
there would have been an entry in the host TCP table for
a period of time that could have been reported on.

   This scenario is readily seen from the detail argus
records. In detail mode you get specific indications of
the state of the TCP with each output record.  In the first
TCP record seen in the detail mode output, the first state
is "EST".  So there was no connection establishment
handshake.  If this had been a normal TCP request, you
would have seen either a "REQ" or "ACC" indication for
the first TCP output record indicating the "SYN" or
"SYN_ACK" states respectively.

   I believe that you have bumped into the number one
use of Argus for site security; access policy enforcement
validation.  I'll bet you've got a tiny problem
with your filters.

Hope this was helpful,

Carter



-----Original Message-----
From: Russell Fulton [mailto:r.fulton at auckland.ac.nz]
Sent: Wednesday, June 23, 1999 7:10 PM
To: argus at lists.andrew.cmu.edu
Subject: ra output intrepretation


Greetings All,
	     I run two argus servers, one in detail mode and one not.
(To be complete the one in detail mode is 1.7be and the other one
is 1.8 code).

The data here comes from the port scan of a machine (130.216.85.131)
that should be invisible (except for pings) from the outside.  I will
present data for one connection from both logs and would like an
explaination of what it actually means.  I am confused (if that isn't
already appearent ;-)

First data from server in detail mode:

argus at k-meter argus]$ grep '\.80 ' june/139.80.75.71 
Wed 06/23 16:03:09     icmp    xxx.yy.75.71        ->  130.216.85.131       1      0                          ECO
Wed 06/23 16:03:09     icmp    xxx.yy.75.71       <->  130.216.85.131       1      1                          ECO
Wed 06/23 16:03:24      tcp    xxx.yy.75.71.41325 <?>  130.216.85.131.80    1      0       0         0        EST
Wed 06/23 16:03:24      tcp    xxx.yy.75.71.41325 <|   130.216.85.131.80    0      1       0         0        RST

the same session reported by the other server was:

Wed 06/23 16:03:09     icmp    xxx.yy.75.71       <->  130.216.85.131       1      1                          ECO
Wed 06/23 16:03:24      tcp    xxx.yy.75.71.41325 <|   130.216.85.131.80    1      1       0         0        RST

This caught my eye because traffic to that address should be blocked
at our packet filter (the argus machines are outside the packet
filter).

These are the first packets of the scan i.e. a ping followed by a tcp
packet to port 80.  These were followed by a normal port scan with
ports probed in random order.

My guess is that the inital probe to port 80 had some illegal combination of flags which has confused ra and caused something (our packet filter ?) to send a reset.

Is there anyway to glean more information from these records using
existing tools?

Any other ideas?

Cheers, Russell.