Spurious web server traffic

[Russ Harvey]

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