ra time range option

[Scott A. McIntyre]

> Hey Scott,
> Europeans, why can't you guys just conform ;o)  OK,

Heh -- I guess I opened up a bit of a can of worms with my time
questions.

> Time range matching is a really good problem to think
> about, because time correlation of records is very
> cool, and doing a good job can provide a lot of utility.
> 
> A security example would be:

[ s n i p ]

In a way, what you described made me think of "threading" in the context
of things like email/news -- in an ideal world, it would be nice if when
a time range is specified to ra() that it can see the contextual
relationship between similar flows on connected nodes.

In other words, to use your example, if someone telnets from host1 to
host2, if we wanted to find out if they did that directly from the
console, or if they merely "leapfrogged" then the "total flow" that
would be of interest would be the one instantiated on host1 within a
given 'fuzzy' matched time period, then the host1 to host2
communication, and either the termination of host1/host2
commonunication, or a similar fuzzy match to the hostX to host1.

I am not nearly as skilled as Carter at ASCII art, so words will have to
suffice to better explain what I'm thinking.

ra -f 1h -t 20010128-20010129.06 - tcp and port 23 and (host1 and host2)

Would report telnet flows between midnight January 28th, 2001 and 0600
January 29th, but apply a "fuzzy" filter of 1 hour to include flows
outside of the specified time range, within an hour, but matched other
criteria of the filter with some statistical significance; such as
reporting ftp flows involving host1 and host2, or udp traffic, or tcp
and port 23, but to host1 only.

This is probably not making as much sense typed out as it does in my
mind -- I'm thinking about the problem in terms of the way I used argus
1.5 and convoluted perl to track "events" in the past.  Typically, a
single packet to a port that didn't belong would trigger a series of
other ra() searches for the offending node's traffic, the port's
traffic, and look for other patterns that I'd further instructy my
scripts to investigate.

Anyway...

> OK, so the kind of issues that I've restled with.
> 
> Do we do -tI, where both start and end times fit in the range?
> The 'I' standing for Inclusive.  This allows you to find
> flows that were covered by another flow.
> 
> AR1 |  +-----+
> AR2 |      +---|----+
> AR3 |    +-----|------------|-----+
> AR4 |          |    +=====+ |
> AR5 |          |        +---|--+
> AR6 |          |            | +-------+
>     +----------|------------|--------------
>          Time  |            |
>                |            |
> Filter Range   |------------|
> 
> +---+  Not Matching
> +===+  Matching

Personally, I find this attractive -- if you have a very specific time
range that you're working with and need to have concise reporting for
that time period, perhaps for usage statistics in working with NetFlow
data, for example.

> Do we do -tX, where both start and end times are outside the
> range?  This allows you to find flow that cover other flows.
> This also has a lot of security impliations.
> 

This is something that I've tried to build myself over the years of
using earlier argus versions by playing stupid perl tricks.


> And then last but not least, should we support things like:
> 
>    ra -t `date --date="2 days ago"` - `date --date="today"`

The reason I found this attractive was largely because I was too lazy to
count backwards X number of hours, or days, when I wasn't sure of the
time/date at the moment I was working on tracking security events -- a
few late nights/early mornings and sometimes it's blurry.

However, this sort of translation is perhaps better handled externally
to ra and by postprocessing scripts.  Maybe.

> 
> If so what kind of standard format would we support?  RFC-822
> or ISO-8601? or what?

ISO-8601

Just my thoughts.

Scott