[rt-devel] IP tracking in RTIR

Tremaine Lea tremaine.lea at sjrb.ca
Wed Dec 3 13:57:39 EST 2003


> -----Original Message-----
> From: Damian Gerow [mailto:freebsd at coal.sentex.ca] 
> Sent: Wednesday, December 03, 2003 11:39 AM
> To: Security
> Cc: rt-devel at lists.fsck.com
> Subject: Re: [rt-devel] IP tracking in RTIR

<snip of my previous email>

> I think you mean:
> 
>     If a matching ticket is found, the current inbound 
> complaint will be
>     grafted as a child of the open incident.  No match, new ticket.
> 
> if we're going to follow the RTIR way of doing things.

My bad.  Yes, that's what I'd intended.


> > Anyone out there have something like this in place or in 
> the works?  
> > I'd rather not have to try and re-invent where it's not 
> necessary and 
> > as I mentioned above... I'm not much of a coder.
> 
> I'd actually started on this some time ago, but quickly came 
> to the realization that the approach is broken: dynamic IP 
> assignments.
> 
> Since setting up RTIR, I have gotten two complaints that 
> referenced IP addresses for current Investigations.  However, 
> each of those two did *not* actually map to that 
> investigation, as a different userid was signed on to that IP 
> address at the time of the complaint.
> 
> Instead, what I'd like to do, is generate links within the 
> ticket body for IP addresses found, that can take me to my 
> RADIUS log lookup page.  And include the date range around 
> the time of the complaint only (so I'm not looking at a 
> months worth of RADIUS logs).
> 
> That approach might actually be a little bit easier, I just 
> haven't done it yet.


Perhaps an addendum to the above?  Our system uses DHCP as well, however the
assignments change rarely.  Short of an IP block move or the customer
changing NIC's the IP remains the same.  In our case, I suppose the scrip/t
or module would look for unresolved tickets containing the IP.  We then
manage to avoid investigating previously investigated IP's that have moved
for one reason or another.

Thoughts?  Additionally, we also have the ability to drop the MAC address
associated with the IP at the time of offense which can also be checked
against.  

The other challenge perhaps is having the IP/MAC address placed in the
ticket via POST or some other method.  Obviously I'm looking for a high
level of automation here.  My team deals with a very high volume of inbound
mail and it's simply not realistic to handle it by hand.  We handle abuse@
complaints for a cable network of close to a million internet subscribers,
so we have some significant challenges in ticketing.

Do you happen to have a 'working' version of the project you started on
above?  I do have a perl coder I can go to internally to perhaps tweak it
for our own needs or finish it off.  I'd be happy to then submit that back
to the community.

Cheers,

Tremaine




More information about the Rt-devel mailing list