Spurious web server traffic

[Carter Bullard]

Hey Russ,
You were defining the two inputs as "independent" packet sources,
so argus would keep the two pools of packets separate.

You want to pool the packet sources together, so either "dup"lex 
or "bond"ed would be the right strategy.

Carter



On Jun 3, 2013, at 4:55 PM, Russ Harvey <russ-harvey at ucr.edu> wrote:

> Hi Carter,
> Thanks for the quick reply. I changed the conf file to what I thought was
> correct, but there was no difference, so thanks for this information, I'll give
> the "dup" option a try and let you know.
> 
> --russ
> 
> On Mon, Jun 03, 2013 at 09:59:48AM -0400, Carter Bullard wrote:
>> Hey Russ,
>> Yes, that would be a problem.  A comma is very important if you gang them
>> all up on the same line (we use ' , ' as the field separator).
>> 
>> If you want one interface to be one direction, and the other to be the other
>> direction of the same link, then you need to "dup" them.  Try this instead:
>> 
>>   ARGUS_INTERFACE=dup:dna0,dna1
>> 
>> That should get a better result.
>> 
>> We were having problems with performance when argus was configured
>> with the "bond" directives.   That thread died down, so not sure if it is still
>> a real problem or if its a transient issue.  So if it works, but not at any level
>> of performance, then holler, as we need to fix that…..
>> 
>> Carter
>> 
>> On Jun 2, 2013, at 1:19 AM, Russ Harvey <russ-harvey at ucr.edu> wrote:
>> 
>>> Hey Carter,
>>> Is it possible that my problems are related to a misconfigured argus server?
>>> The box I mentioned that is collecting network traffic has two fiber interfaces
>>> (linux calls them dna0 and dna1), presumably one for inbound packets, one for
>>> outbound. The argus.conf file on that system has:
>>> 
>>>   ARGUS_INTERFACE=dna0 dna1
>>> 
>>> Whereas the man page for the conf file says it should be:
>>> 
>>>   ARGUS_INTERFACE=dna0
>>>   ARGUS_INTERFACE=dna1
>>> 
>>> Everything I've been seeing when analyzing the output files could be accounted
>>> for, I think, if only one side of the conversations was being collected.
>>> 
>>> Just to make sure I just changed the conf file to be correct, and restarted the
>>> daemon, I'll give it a few hours worth of files (i.e. tomorrow morning my time)
>>> and rerun ra.
>>> 
>>> Hope this fixes things.
>>> 
>>> Thanks,
>>> --russ
>>> 
>>> On Thu, May 30, 2013 at 06:28:54PM -0400, Carter Bullard wrote:
>>>> Hey Russ,
>>>> Hmmm, well it should work the exact same…..but things have changed
>>>> quite a bit.
>>>> 
>>>> Not sure what your are reporting, regarding the ra() command not showing
>>>> flows?  So if you can provide a few lines of output, that would be a great
>>>> help….
>>>> 
>>>> So, single argus, collecting from a port mirror, or are you running argus
>>>> in the webserver itself ?  What are you doing to get your files into your
>>>> archive?  Are you running rasplit() or are you moving an argus output file?
>>>> Are you running racluster() on the files, or are these " primitive " argus
>>>> data files.
>>>> 
>>>> I'm not sure that I know what you expect as an outcome….so lets go through
>>>> a few steps.   With the "src host" filter, for TCP traffic, you are asking to see
>>>> flows where the host is the source of the tcp connections, i.e. it originates
>>>> the flows.   If you aren't seeing flows that you expect from this filter, if you take
>>>> out the " src ", do you see the flows you're interested in, but the direction
>>>> is incorrect ?  Is there a " <?> " in the direction field ?  
>>>> 
>>>> If you've got your flow data looking good, then simple filters generally find
>>>> the specific flows that are interested in.  To find flows initiated by your
>>>> webserver, that are leaving your /24 address space, which we will call
>>>> x.y.z.0/24, that are not going to machine X:
>>>> 
>>>>  ra -r argus.file - tcp and src host webserver and not dst net x.y.z.0/24 and not host X
>>>> 
>>>> If you don't get anything, and you suspect that you should, then decompose
>>>> the filter, and see which part is not doing what you expect.
>>>> 
>>>>  ra -r argus.file -w /tmp/test.out - tcp and host webserver
>>>> 
>>>> Look at this and see if you have enough traffic, without the " ? " in the direction
>>>> field to capture what you suspect, then run the next part of the filter against
>>>> the /tmp/test.out file.
>>>> 
>>>>  ra -r /tmp/test.out - src host webserver and not dst net x.y.z.0/24 
>>>> 
>>>> This should give you tcp connections originated by webserver, going
>>>> out of your network, and then add the specific " not host X " filter to
>>>> pick out the " others "……….
>>>> 
>>>> Hopefully this will get us in the right direction?
>>>> 
>>>> Carter
>>>> 
>>>> 
>>>> 
>>>> On May 30, 2013, at 6:04 PM, Russ Harvey <russ-harvey at ucr.edu> wrote:
>>>> 
>>>>> Hi,
>>>>> I am having trouble going from older argus clients to newer versions as I update
>>>>> my scripts that do various searches of our network border traffic. One script
>>>>> looked for outbound connections initiated by a campus web server -- only
>>>>> connections to a particular off-campus machine are expected, anything else
>>>>> indicates something suspicious. My circa 2.0.6 script relied on flow information
>>>>> to see the outbound connections that were legitimate vs. all the usual noise
>>>>> and knob rattling seen in today's internet traffic. It relied on argus's state
>>>>> and direction flags, plus source and destination packets, to know that there was
>>>>> a two way exchange of packets, tcp protocol was followed, etc. It made the
>>>>> perhaps unfortunate assumption that all normal web traffic will be initiated by
>>>>> other hosts, so, as an example, captured flow files would be filtered with
>>>>> 
>>>>>             ra -nr <argus-archive-file> - src host <mywebserver>
>>>>> 
>>>>> It seemed to work acceptably well, the web server outbound traffic would be
>>>>> displayed, and using state, direction, etc. the valid tcp protocol flows
>>>>> could be examined.
>>>>> 
>>>>> I don't seem to be able to do the same thing with 3.0.6 clients. The output I
>>>>> get using the above ra command, for example, doesn't seem to show flows, or
>>>>> shows flows on separate lines. I thus don't seem to be able to discriminate
>>>>> legitimate flows from the suspicious ones. Even the expected traffic doesn't seem
>>>>> to appear as a single flow line in the ra/racluster output.
>>>>> 
>>>>> So apart from all that, how do I find legitimate traffic initiated by my webserver
>>>>> that is not going to the expected off-campus machine?
>>>>> 
>>>>> Apologies for the long winded question, especially if the answer is that I am
>>>>> doing something stupid, which is entirely possible.
>>>>> 
>>>>> Thanks,
>>>>> --russ
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
> 
> 
> 

-------------- 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/20130603/d8666363/attachment.bin>