Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Focus-IDS
[Top] [All Lists]

Re: Tracking back internal incidents to users, not IPs

Subject: Re: Tracking back internal incidents to users, not IPs
Date: Thu, 23 Feb 2006 23:49:45 -0800

802.1x is intended to provide an identity framework. However, there are some things one can do short of an 802.1x deployment in order to provide this kind of capability.


There's a *NIX nbtscan command which provides the equivalent of nbtstat -a, and is scriptable, which can help when dealing with Windows systems.

Host registration as a foundation for a quarantine system is also a good idea (yes, MAC addresses can be spoofed and so forth, but it's all about raising the bar):


http://www.nanog.org/mtg-0402/gauthier.html

http://www.roxanne.org/~eric/blaster.html


On Feb 23, 2006, at 7:24 AM, List Spam wrote:

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

---------------------------------------------------------------------- Roland Dobbins <rdobbins@cisco.com> // 408.527.6376 voice

     Everything has been said.  But nobody listens.

                   -- Roger Shattuck


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


<Prev in Thread] Current Thread [Next in Thread>