Re: Tracking back internal incidents to users, not IPs

["List Spam" <listspam () gmail com>]

On 2/20/06, Charles Kaplan <ckaplan () mazunetworks com> wrote:
> Say for example you detect port scanning originating from an
> un-authorized internal system, how do you go about getting a user name?

If this is an unauthorized system, it is highly likely that they won't
be logged in with an valid username.  If they had a valid username,
they would probably just hop onto some resource remotely instead of
lugging in a new system.  That being said, it sounds like you're
primarily an MS shop.  Given this, you can get the name of the
currently logged in user, in many cases, by executing "nbtstat -A
<IPADDRESS>".  Please don't rely on that, however, as if the system is
unauthorized, it is already outside of your expected norm.

> Note that I am assuming that the source is a DHCP system here (otherwise
> it is much easier problem).

I would think that a statically assigned IP would be more problematic
in that there is no guarantee that they've communicated to your
audited infrastructure as is the case with one that obtains a DHCP
lease...

> I realize there is a lot of industry talk around DHCP, DDNS, user auth
> (say Active Directory), NAC and such, but looking at real situations
> today I am very interested in how people are solving this problem.

You've gotten a few good answers on this already and, if you want what
is generally the best industry recommendation, you'll likely end up
going down the road of obtaining some sort of NAC solution.

> I am often given an internal IP# on my own network and asked to call the
> user and ask them why they are doing something strange.  I would ideally
> like to use some kind of extended NSlookup to tell me who to call.  And
> while I won't be a spokes person for Microsoft any time soon, I think it
> safe to assume that I would like to somehow find this info stored within
> AD.

What you may want to do is populate one of the optional user
attributes with the jack number their workstation is supposedly tied
to and their current IP address.  Obviously, in a wireless, multi-user
device, or VPN setting, this won't apply, but it would be better than
having nothing.  You could manually enter this if your physical
environment is fairly static and management doesn't like to play the
"hot potato" game with employees, but it would quickly become
cumbersome to maintain.  A better bet, should you go this route, would
be to script something that pulls info from a database/spreadsheet for
static IP assignments, then queries your DHCP server(s) for active
leases with MAC adresses, compares the MAC address to the switch's MAC
table, then queries your database/spreadsheet for jack number to
switch port assignments and updates the user object via an LDAP modify
command.  This again, should not be relied upon as 100% accurate as
devices and IPs can easily travel and be spoofed, but this might be
enough to get your noggin cranking on something that may be
appropriate for your environment.

> And yes, I realize that for the info to get to AD, it must be a
> credentialed user, and maybe this is an area to debate, but I am simply
> looking for ideas based on how others have solved this, not a 100%
> perfect solution.

Nothing is 100% perfect or we'd all be running it.  My best advice, in
this and most cases, is to take all of the input you receive and
figure out what components make sense for you and your company.  You
have at least two problems in this question that need to be addressed,
regardless of if all you want is to be able to know what user to call.
 First, you have to be able to determine who is using your resources. 
Secondly, you have to be able to detect/prevent unauthorized usage of
those resources.  If you focus on the second item, the first will most
likely work itself out and, by proxy, give you your answer on who is
at what IP address.

> Thoughts?
>
> Note that I would take an open source or a commercial product as a
> viable answer.

Perhaps what is needed first, is a rethinking of how you want to skin
this cat and what you're truly trying to accomplish and use that as a
framework.  Once you've done that, the specifics of a given process
(being able to call a user if you're just given an IP) will be
trivially worked out.

Sorry for the drawn out advice.  I've not yet had my coffee.

My two cents.

RE

------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it
with real-world attacks from CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708
to learn more.
------------------------------------------------------------------------