IP tracking in RTIR

Hello folks,

I'm not a coder myself, but I can see some strong possibilities in RT3

for grouping tickets based on “offending” IP address. As I’m sure most
are aware, determining the IP to be investigated by parsing inbound
abuse mail is at best a daunting task.

However courtesy of some fine tools at places like mynetwatchman,

dshield, spamcop and numerous others… the volume of standardized
reporting is definitely on the increase.

What I’m wondering is if anyone out there has already put together any
kind of pre-filtering system/scrip/module that parses inbound email
(either before it hits RT or as it’s queued) for the reported IP.

What I envision is a module of some kind that parses ‘tagged’ types of
email such as mynetwatchman and then checks RT/IR to see if there is an
existing ticket referencing the IP (custom field). If the ticket exists
it will then be merged into that ticket. No match, new ticket.

Obviously there are a number of ways the new email report could be
handled. The inbound email could have it’s subject rewritten with the
RT#, it could be added as an attachment to the ticket via POST or some
similar method.

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.

Cheers,

Tremaine

Thus spake Security (security@ddiction.com) [02/12/03 22:19]:

What I’m wondering is if anyone out there has already put together any
kind of pre-filtering system/scrip/module that parses inbound email
(either before it hits RT or as it’s queued) for the reported IP.

What I envision is a module of some kind that parses ‘tagged’ types of
email such as mynetwatchman and then checks RT/IR to see if there is an
existing ticket referencing the IP (custom field). If the ticket exists
it will then be merged into that ticket. No match, new ticket.

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.

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.

  • Damian

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

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

Thus spake Damian Gerow (freebsd@coal.sentex.ca) [03/12/03 13:38]:

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).

Actually, what I’d like to do is have a menu pop up when you click on
certain links – so we can do nslookup, RADIUS lookup, whois lookup,
traceroute, etc. right from the ticket body, instead of needing to
copy/paste into the ‘Tools’ page.

But last I checked, HTML doesn’t let you do this. Javascript probably will.

  • Damian

Thus spake Tremaine Lea (tremaine.lea@sjrb.ca) [03/12/03 13:57]:

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.

For DHCP, it would work relatively smoothly. You’d still have the odd
report that would be grafted into the wrong Incident, but the occurrence
would be relatively low.

However, we don’t use DHCP – we use PPPoE. So our IP assignment can change
as frequently as every ten seconds, depending on how often our users
connect, disconnect, and reconnect.

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.

Well, RTIR was written to do automation, so it /should/ be possible. And my
condolences to you – I man the abuse desk for, oh, a couple thousand
customers, and I find it overwhelming enough.

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.

Unfortunately, no. I stopped working on it relatively early.

However, it shouldn’t be hard to put in place the thought of linking to a
RADIUS lookup page (or whatever you use to look through your assignment
logs). Just find a regex for an IP address
(/(\d{1,3}.\d{1,3}.\d{1,3}.\d{1,3})/ perhaps?), and wrap it in an A HREF,
and you /should/ be okay.

Double-check that regex, though. It might not work, and there’s probably
much better regular expressions for finding IP addresses out there.

  • Damian

However, it shouldn’t be hard to put in place the thought of linking to a
RADIUS lookup page (or whatever you use to look through your assignment
logs). Just find a regex for an IP address
(/(\d{1,3}.\d{1,3}.\d{1,3}.\d{1,3})/ perhaps?), and wrap it in an A HREF,
and you /should/ be okay.

Double-check that regex, though. It might not work, and there’s probably
much better regular expressions for finding IP addresses out there.

Like the one in RTIR’s “MakeClicky” component, which gives you a way to
configure what happens when people click on IP addresses.

-j
  • Damian

rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

Thus spake Jesse Vincent (jesse@bestpractical.com) [03/12/03 16:01]:

However, it shouldn’t be hard to put in place the thought of linking to a
RADIUS lookup page (or whatever you use to look through your assignment
logs). Just find a regex for an IP address
(/(\d{1,3}.\d{1,3}.\d{1,3}.\d{1,3})/ perhaps?), and wrap it in an A HREF,
and you /should/ be okay.

Double-check that regex, though. It might not work, and there’s probably
much better regular expressions for finding IP addresses out there.

Like the one in RTIR’s “MakeClicky” component, which gives you a way to
configure what happens when people click on IP addresses.

Yep, that would be pretty much what I wanted. I figured RTIR would have
something like that in there, since the docs say it does, I just haven’t
bothered trying to track it down. Now I just need to read up on how to use
it.

Once again, Jesse, you rock.

  • Damian

At 03:55 PM 12/3/2003, Damian Gerow wrote:

Double-check that regex, though. It might not work, and there’s probably
much better regular expressions for finding IP addresses out there.

Have a look at Regexp::Common::net
(Regexp::Common::net - provide regexes for IPv4 addresses. - metacpan.org).
Regexp::Common is part of the RT dependencies.

Michael

Michael S. Liebman m-liebman@northwestern.edu
http://msl521.freeshell.org/
“I have vision and the rest of the world wears bifocals.”
-Paul Newman in “Butch Cassidy & the Sundance Kid”

  • Damian Gerow [2003/12/03 15:47]:

Thus spake Damian Gerow (freebsd@coal.sentex.ca) [03/12/03 13:38]:

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).

Actually, what I’d like to do is have a menu pop up when you click on
certain links – so we can do nslookup, RADIUS lookup, whois lookup,
traceroute, etc. right from the ticket body, instead of needing to
copy/paste into the ‘Tools’ page.

FWIW, Net::Nslookup (http://search.cpan.org/dist/Net-Nslookup/) will
get you nslookup(1)-style lookups without having to shell out to another
program.

(darren)

Millions long for immortality who do not know what to do with
themselves on a rainy Sunday afternoon.
– Susan Ertz