Taking Argus Source from Files Doesn't Ignore ~/.rarc options

[Carter Bullard]

Hey Eric,
Yes I'm afraid that your ra* programs are doing the correct thing.
You have this line in your .rarc:

> RA_ARGUS_SERVER=radium:562


Which means that after its done with everything on the command-line,
it will connect to radium:562.  This is only cleared, if you were to
have a "-S host" option line (you want to modify the entry in the .rarc)

This configuration entry is primarily for radium(), so you can have
10-100's of remote RA_ARGUS_SERVER's being managed and collected.
But it is not recommended that this entry be in your general ~/.rarc  
file.

OK, so why is this behavior in there to begin with?  The idea of
reading a file, before you start reading data from a real-time remote
server, is to provide a "priming" of the pump, if you will.   I have
many clients that do this, where they read a file of 'expected' flows
which are matched against the flows coming in from the real-time
source.  In the client source code, these records are the "STICKY"
records, they are cached, but never timed out, so we have a set of
flows as reference.

OK, that is the rationale.  I don't think having a "-r file" option  
should
clear out the "-S host" option learned from a resource file.
I usually have many ra.conf files around for my specific needs, and
have the ~/.rarc for formating.

Could you consider removing the entry?

Carter


On Apr 10, 2008, at 3:09 AM, Eric Pancer wrote:

> Well, I'm seeing some really problematic behavior of ra* clients that
> are continuing to take data from remote network sources even when
> processing files with "-r". If I remove my ~/.rarc configurations and
> process through flow records, everything works just fine. It's only
> when I add that file back that things go a bit haywire.
>
> Please observe the following (sorry for the lengthy description)...
>
> First, I remove ~/.rarc
>
> gurgle$ rm ~/.rarc
> gurgle$ ls -ld ~/.rarc
> ls: /home/staff/eric/.rarc: No such file or directory
>
> Next, I take some flows from a router, only with 10.0.0.0/8 and
> 163.0.0.0/8 as a dst net.
>
> gurgle$ ra -S radiumserver:562 -w homenet.cap - dst net \( 10.0.0.0/8
> or 163.0.0.0/8 \)
>
> Validate I have clean dst net data.
>
> gurgle$ racluster -m daddr/8 -r homenet.cap
>  01:00:00.000000  e          ip            0.0.0.0           ->
> 10.0.0.0           14174   11116971   INT
>  01:00:00.000000  e          ip            0.0.0.0           ->
> 163.0.0.0          301271  166580675   INT
>
> So far so good. Next, let me run a couple summaries again this data.
>
> gurgle$ racluster -L0 -m proto -r homenet.cap -s proto trans pkts  
> rate bytes
> Proto  Trans  TotPkts         Rate   TotBytes
>  esp      2    44262   457.185944    8587472
>  udp   2710     5147    17.156666     603992
>  tcp   6787   265976   886.586670  168497375
> icmp     22       60     0.218279       8807
>
> Next, try to look at top bytes on the network; do this thrice just to
> make sure we get the same result.
>
> gurgle$ racluster -M rmon -m saddr -r homenet.cap  -w - - ip | rasort
> -m bytes -s saddr bytes | head -3
>   163.y.240.99  111563830
>   163.y.214.47   16937476
>  163.x.104.230   16937476
> gurgle$ racluster -M rmon -m saddr -r homenet.cap  -w - - ip | rasort
> -m bytes -s saddr bytes | head -3
>   163.y.240.99  111563830
>   163.y.214.47   16937476
>  163.x.104.230   16937476
> gurgle$ racluster -M rmon -m saddr -r homenet.cap  -w - - ip | rasort
> -m bytes -s saddr bytes | head -3
>   163.y.240.99  111563830
>   163.y.214.47   16937476
>  163.x.104.230   16937476
>
> Ok, so that all looks good. I'm getting the same results when looking
> at data WITHOUT ~/.rarc. Next, put my .rarc back in place
>
> gurgle$ ln -s ~/.rarcs/default.rarc ~/.rarc
> gurgle$ cat ~/.rarc
> RA_ARGUS_SERVER=radium:562
> RA_RUN_TIME=0
> RA_PRINT_LABELS=0
> RA_FIELD_DELIMITER=' '
> RA_PRINT_NAMES=port
> RA_PRINT_RESPONSE_DATA=no
> RA_PRINT_UNIX_TIME=no
> RA_USEC_PRECISION=6
> RA_USERDATA_ENCODE=Ascii
> RA_DEBUG_LEVEL=0
> RA_TIME_FORMAT="%m-%d-%y %T.%f"
> RA_FIELD_SPECIFIER="stime:19 flgs proto saddr sport dir daddr dport
> pkts bytes state srcid"
>
> Check homenet.cap, which was taken from radium in previous steps..
>
> gurgle$ racluster -m daddr/8 -r homenet.cap
>               StartTime    Flgs  Proto            SrcAddr  Sport Dir
>          DstAddr  Dport  TotPkts   TotBytes State SrcId
> 04-07-08 01:00:00.000000  e          ip            0.0.0.0 ->
>  10.0.0.0           14174   11116971   INT 10.10.246.46
> 04-07-08 01:00:00.000000  e          ip            0.0.0.0 ->
> 163.0.0.0          301271  166580675   INT 10.10.246.46
>
> Looking good; next step...try look at the bytes report again
>
> gurgle$ racluster -M rmon -m saddr -r homenet.cap  -w - - ip | rasort
> -m bytes -s saddr bytes | head -3
>          SrcAddr   TotBytes
>    172.x.40.198   11812056
>   163.y.240.99    1227080
> gurgle$ racluster -M rmon -m saddr -r homenet.cap  -w - - ip | rasort
> -m bytes -s saddr bytes | head -3
>          SrcAddr   TotBytes
>    68.a.132.29    2887341
>   163.w.205.71    1103544
> gurgle$ racluster -M rmon -m saddr -r homenet.cap  -w - - ip | rasort
> -m bytes -s saddr bytes | head -3
>          SrcAddr   TotBytes
>    172.x.18.152     219359
>   163.x.53.170     191467
>
> So basically, I believe racluster is taking data from my
> RA_ARGUS_SERVER; this happens with other ra* tools, as well.
>
> Is something screwed up with my end of things? If not, is there a bug
> in "-r" and/or "-R" that is causing it to take remote streams?
>
> Thanks,
>
> - Eric
>