Direction and IP/TCP timeout settings

[Carter Bullard]

Hey Russ,
> I obviously need to adjust my thinking, but I still have a question about
> distinguishing legitimate traffic from standard port scans and other types of
> noise. With http, for example, I have a server that should not initiate
> connections on it own, but merely act as an http server and respond to requests
> only on ports 80 and 443. There is a potential security problem if the http
> server initiates connections. However, if I look at archived argus 3 records
> using something like `src host X.X.X.X' I see lots of activity with my server as
> source host, '->' in the direction field, and both source and destination packets
> recorded in those fields. I am pretty sure this server is not initiating
> traffic but merely responding to http and https requests, so I don't understand
> what argus is reporting. Do I have a misconception about how http works?

If the TCP flow's direction doesn't have a " ? " then we saw a SYN or a SYNACK
while tracking the flow, which indicates who initiated the TCP connection.
Most machines do things you aren't aware of, and in bad situations, do things
you definitely don't expect.

The whole point of doing the network audit thing, is to discover network
behaviors that you weren't aware of, first so you can be aware of them,
second so you can check to make sure they are OK, and third to make
them better if they need help.

If you're curious about a set of TCP connections, look a bit more at what
the flow records can tell you, so that you can get a grip on what is going on.
What is the service being used.  Look at the content to see if its at all
reasonable.  All servers have backend dependancies, like DNS, ARP, NTP
etc...  Is this what is happening?  

If not, maybe your server has been hosed, and you need to fix it?

What do these rogue connections look like ?

> 
> Also, as mentioned before, I see a lot of 'd' and a few 's' flags set, though I
> suppose those could be retransmissions instead of dropped destination and source
> packets?

"d" and "s" in the 4th column indicate that there was loss/retransmissions.
For TCP, they really are in a round about way, the same thing.  If there is
loss, there must be a retransmission, don't have one without the other.

> 
> Thanks again Carter,
> --russ
> 

Carter

> 
> On Mon, Jul 15, 2013 at 08:43:39AM -0400, Carter Bullard wrote:
>> Hey Russ,
>> If you are seeing " -> " for TCP traffic, everything is working correctly.
>> You should NOT see " <-> " for TCP traffic  unless there is a tracking problem.  If you see " ? " in the dir field, means we didn't see the SYN or SYNACK.   If you think you are missing traffic, in TCP, you'll see a " g " in the flags field.
>> 
>> Holler if this generates more questions, or doesn't help !!!!
>> Carter
>> 
>> 
>> 
>> 
>> On Jul 13, 2013, at 1:08 PM, Russ Harvey <russ-harvey at ucr.edu> wrote:
>> 
>>> Just to chime in, we are seeing similar direction issues where tcp flows are
>>> showing as '->' rather than the expected '<->' This makes it difficult to
>>> distinguish between legitimate (http, for example) traffic and scanning. We are
>>> also seeing a lot of 'd' and 's' flags when using ra tools to look at the
>>> capture files, so we would like to understand if there is something wrong with
>>> our implementation, something wrong with our argus configuration, or just what.
>>> We are capturing traffic via fiber taps on our network edges also using
>>> pf_ring+dna.
>>> 
>>> Thanks,
>>> --russ
>>> 
>>> On Fri, Jul 12, 2013 at 09:36:56AM -0400, Carter Bullard wrote:
>>>>  Hmmmm, do the new timeouts change the direction problem?
>>>>  That will be the real test, if the memory issues aren't showing
>>>>  themselves,
>>>>  the cool, as long as your traffic looks better.
>>>>  If not, I'll take a look.  Never know where things break down.
>>>>  In some cases, we'll try to make the direction indicator match the
>>>>  traffic,
>>>>  with the central character indicating the confidence.  So, when there is
>>>>  a " ? ", the < or > should change to indicate direction of traffic, since
>>>>  the assignment of flow direction isn't " on ".
>>>>  Carter
>>>>  On Jul 11, 2013, at 7:28 PM, Craig Merchant <cmerchant at responsys.com>
>>>>  wrote:
>>>> 
>>>>    Hey, Carter*
>>>> 
>>>>    We*re finding that for about 70% of our flows, Argus can*t figure out
>>>>    the direction.  From previous posts, it would seem that the 60 second
>>>>    TCP session timeout is too short.  If I understand correctly, a flow
>>>>    longer than 60 seconds will have its session timeout in the cache and
>>>>    then argus can*t really determine what the direction is.
>>>> 
>>>>    The argus.conf file warns of the hit on memory if those settings are
>>>>    adjusted from the defaults.  I*ve been steadily increasing the TCP and
>>>>    IP timeout values and watching to see if memory consumption jumps up
>>>>    dramatically or if we*re seeing less events where the direction is
>>>>    uncertain.
>>>> 
>>>>    I*ve gone as high up as two hour session timeout.  We do something like
>>>>    2.5-8 Gbps 24 hours a day, so I would expect to see a huge increase in
>>>>    Argus memory consumption when increase the timeout value.  The machine
>>>>    has like 64 GB of memory and top says argus is only using .2%. 
>>>> 
>>>>    The settings look like:
>>>> 
>>>>    ARGUS_IP_TIMEOUT=3600
>>>>    ARGUS_TCP_TIMEOUT=7200
>>>>    #ARGUS_ICMP_TIMEOUT=5
>>>>    #ARGUS_IGMP_TIMEOUT=30
>>>>    #ARGUS_FRAG_TIMEOUT=5
>>>>    #ARGUS_ARP_TIMEOUT=5
>>>>    #ARGUS_OTHER_TIMEOUT=30
>>>> 
>>>>    Am I doing something wrong here?  Is there some other setting I need to
>>>>    enable to increase that timeout value?
>>>> 
>>>>    Also, what*s the difference between a direction value of ?> vs <?>?
>>>> 
>>>>    Thanks!
>>>> 
>>>>    Craig
>>> 
>>> 
>>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6837 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130720/ef11984a/attachment.bin>