On 7/8/2011 11:58 AM, Jeff Cartier wrote:
Hi All,
This might be a little off-topic to Cisco, but what the heck.
I'm just curious as to how 'you' would go about tracking down a user that *may*
possibly be downloading large amounts of data causing congestion on a link.
For instance, I had a case this morning with an internal IP address of 10.x.x.x
that showed a 900MB conversation over TCP 80 (HTTP) to an ip address of
174.120.5.220.
Great - so its not that hard to track down the internal user. Yell at him to
stop, talking to him about what he's doing to the network. No biggie.
I'm more curious about options/tools available to find out what he was doing.
I know that he was downloading something, I know that it was over HTTP and I
know the outside IP address he was accessing. So I start off by looking at
174.120.5.220. I can check the A record which tells me nothing....
Name: dc.5.78ae.static.theplanet.com....
I've encountered organizations that use commercial grade applications to
proactively track this data, such as
lancope(Stealthwatch)/riverbed(ManageEngine)/sourcefire(RNA). They enjoy
some success when dealing with situations similar to those you describe,
since these tools track netflow data over time, allowing profiles to be
constructed (which may well contain the information you seek). Some of
them integrate with user directories, which would certainly improve your
chances. For customers without budget money, I've also deployed ntop
rather effectively.
I can't browse to that IP address. I can see who owns that IP address (XO
Communications) though, but in this case its all useless.
The question, more or less, is do I have any options to keep moving forward in
finding out what this user was actually doing?
It depends how long your organization stores log entries. Without a
proactive monitoring tool in place, you'll almost certainly need to
interface with individuals managing other parts of the infrastructure
such as dhcp servers and/or snmp collectors and/or firewalls. The list
of options often depends upon the higher-level details. As other posters
have noted, it's difficult to outdo packet capture data when you're
seeking actual insight.
Thanks in advance!
__________________________________________________________________
DISCLAIMER: This e-mail contains proprietary information some or all of which
may be legally privileged. It is for the intended recipient only. If an
addressing or transmission error has misdirected this e-mail, please notify the
author by replying to this e-mail. If you are not the intended recipient you
must not use, disclose, distribute, copy, print, or rely on this e-mail.
This message has been scanned for the presence of computer viruses, Spam, and
Explicit Content.
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
