David Taylor wrote:
>
> Before going on the offense, you may want to rethink your defense.
>
> If the alleged policy-violator is being issued a DHCP license, then you
> have their MAC. With that, and depending upon the size of your network, you
> can either create include or exclude entries within your DHCP config.
Agreed. Attacking an internal host simply because you do not know who
owns it is a dangerous game to play. I would suggest the following:
1) Perform a port scan against the machine and look for obvious port
clues. For example if finger, Telnet, etc. are open. You can be pretty
sure its a Unix box. If all you see is ports 135 & 139, its probably
Windows.
2) Check banner screens
If you find open services, Telnet the port to see if you get a banner
which yields any clues. For example if you connect to port 25 and see a
Sendmail banner, this is another clue its a Unix OS.
3) If finger is open, try checking some obvious addresses (like root).
This may yield an some helpful info like the last remote IP connection
for the account. This may help you hunt down the person who setup the
machine.
4) Evaluate the MAC address to determine who makes the card. You can
use:
ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers
as a reference. Knowing the card vendor may help you determine what kind
of system the NIC is attached to.
5) If you have determined its a Windows machine, try the following:
nbtstat -A ip_address_of_host
This will yield the machine name, domain/workgroup as well as the logon
name of the person currently using the system.
6) If its an NT box, try running hunt.exe against it. The tool is
available at:
http://www.ntobjectives.com/
(its part of JD Glaser's Forensic ToolKit) and you can read exactly how
to use it at:
http://www.geek-speak.net/products/ntaudit1.html
Unless the machine has the correct registry hacks in place, hunt will
give you a complete dump of all logon names and shares.
So instead of trying to kick the machine off the wire (and take the
chance of wasting other hosts in the process) you may want to try and
identify who's running the offending system first.
Happy hunting,
Chris
--
**************************************
[EMAIL PROTECTED]
* Multiprotocol Network Design & Troubleshooting
http://www.amazon.com/exec/obidos/ASIN/0782120822/geekspeaknet
* Mastering Network Security
http://www.amazon.com/exec/obidos/ASIN/0782123430/geekspeaknet
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
