ra time range option

[Carter Bullard]

Hey Scott,
Europeans, why can't you guys just conform ;o)  OK,
this is much bigger than you had probably wanted, but
its time to do a final review of ra* options, so
lets dive into a good one.

Yes, I changed all the date reporting to be more
internationally oriented, and we should do the same
with the "-t" option.  But there are some issues that
we should probably review and possibly fix.

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:

    someone telnets from host 1 to host 2.
    was this person at the console or did someone telnet
    to host 1 from another host and then telnet to host 2?

    You can test this by looking for a telnet transaction
    that accesses host 1 and exists for the duration of
    the host 1 to host 2 telnet; one that covers the time
    range of the telnet session from host 1 to host 2.
    If such a telnet exists, then you've got a potential
    candidate.  If they have the same packet size and burst
    behavior, then you've got a likely candidate, etc.....

This is also very interesting because of just the technical
issue.  Each record has 2 timestamps, the start and end time.
By matching a range against a range, which timestamp should
be compared?  One of them?  Which one?  Both of them?
Inclusive or exclusive?  All of this is interesting stuff.

Currently we support this type of syntax.
   -t <timerange>
   timerange format:  timeSpecification[-timeSpecification]
   timeSpecification: [mm/dd[/yy].]hh[:mm[:ss]]
                       mm/dd[/yy]

I just made this up, so we can change it to something that is
more standard, if such a thing exists.  We are considering
swaping the mm/dd/yy to yyyy/mm/dd, that's a no brainer, but
is there more to do here?

Let me go over what the option is suppose to do today.

Times are literal, in that if you specify just an hh, its hh:00:00,
an mm/dd gives you mm/dd.00:00:00.

If you specify only one time (t1), we build a time range out of
it as (t1 - t1).  This is probably not the right thing to do,
because:

   ra -r * -t 01/24

doesn't return any records on my archive, and this is not what
I wanted.  I'll change this behavior to be (t1 - (t1 + 1))
with the correct scaling.

So the command line specification generates a time range.
We match if either 2 timestamps in an Argus record fall in this
range or they span the range.  So you get something like this:

AR1 |  +-----+
AR2 |      +===|====+
AR3 |    +=====|============|=====+
AR4 |          |    +=====+ |
AR5 |          |        +===|==+
AR6 |          |            | +-------+
    +----------|------------|--------------
         Time  |            |
               |            |
Filter Range   |------------|

+---+  Not Matching
+===+  Matching


A time range such as:

   ra -t 14 - 15:11:10

should match every record that has a startime or an endtime between
or spanning 2PM and 3:11:10 PM, regardless of the day, month or year.

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

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.

AR1 |  +-----+
AR2 |      +---|----+
AR3 |    +=====|============|=====+
AR4 |          |    +-----+ |
AR5 |          |        +---|--+
AR6 |          |            | +-------+
    +----------|------------|--------------
         Time  |            |
               |            |
Filter Range   |------------|

+---+  Not Matching
+===+  Matching



And then last but not least, should we support things like:

   ra -t `date --date="2 days ago"` - `date --date="today"`

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

I know this is a lot to swallow, but this is what makes
it interesting for me.  Opinions??????

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

carter at qosient.com
Phone +1 212 813-9426
Fax   +1 212 813-9426



> -----Original Message-----
> From: Scott A. McIntyre [mailto:scott at xs4all.nl]
> Sent: Monday, January 29, 2001 8:44 AM
> To: Carter Bullard
> Subject: Re: Big files.
> 
> 
> Hi Carter,
> 
> 
> > > I'm more than happy enough to leave things as they are at 
> the moment
> > > with respect to the date and time then -- I can always 
> just reformat my
> > > own output of date commands into the input format for argus.  
> 
> 
> I changed my mind.
> 
> I just can't handle Month/Day/Year.
> 
> It's pretty much just the USA who uses that format, so, how about a
> toggle or a configuration file format tweak that will assume World
> standard?  As in Day/Month/Year, or even better, YYYY/MM/DD?
> 
> :-)
> 
> Scott
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3699 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20010129/bae5335c/attachment.bin>