rafilteraddr issue

[Phillip Deneault]

On 2/5/2010 2:03 PM, Carter Bullard wrote:
> What do you think?

I think it might be a better solution than using rafilteraddr for what I
ultimately am trying to do. :-)

I guess I picked rafilteraddr because I was pondering the differences in
speed that would come from a large set of facts to try to match against,
per your comment here:
http://thread.gmane.org/gmane.network.argus/5341/focus=5344

but since I could label flows as they came in, then the processing load
for the label marking would be distributed and the processing load for
the data querying would be limited to just a few columns in the ra
files.  Do you agree?

Thanks!
Phil

On 2/5/2010 2:03 PM, Carter Bullard wrote:
> Hey Phillip,
> Sorry I haven't responded!!!  So here is where I am on this:
> 
> Its not a bug, by default rafilteraddr() matches only exact matches,
> and CIDR matches are, of course, not exact matches.
> 
> But this, of course, is not what we want.  I believe that I have a solution,
> but I need to test it out a bit.
> 
> As a work around, I might suggest that you use ralabel() to do what you
> want.  As an example, using the sample ralabel.conf and iana-address-file
> from the ./support/Config directory in the client distribution, you can take your
> address list, and have it insert the label "match" into the flow stream, and
> then use ra() to find flows that have the label "match" in them:
> 
>    ralabel -f ralabel.conf -r /data/argusinput -w - | ra -M label=match
> 
> The ralabel.conf file contains:
>    RALABEL_IANA_ADDRESS=yes
>    RALABEL_IANA_ADDRESS_FILE="filtertest.txt"
> 
> and your filtertest.txt file contains:
> 
>    192.168.1.0/24   match
> 
> You can make this much more complicated, and so much more than just
> filtering with these schemes.   Hopefully it will provide you with a workaround
> until I get the fix in. I should have a solution for rafilteraddr() by the weekend?
> 
> What do you think?
> 
> Carter
>