Tracking down an unknown machine

16 views
Skip to first unread message

Kit Peters

unread,
Apr 10, 2013, 10:55:26 AM4/10/13
to kul...@googlegroups.com
At my job, we maintain a list of IP addresses and the machines to which they are assigned.  As you might expect, this list periodically gets out of sync with reality, and it's my job to fix that.  

Lately, I've discovered a couple of machines on the network that aren't in my list, and aren't in the block we've assigned to DHCP.  I'd like to track these machines down and add them to the list.  

Any suggestions for tracking these machines down?  
--
Kit Peters, W0KEH
GPG public key fingerpint: 1A12 04B6 0C80 306A B292  14FD 2C7A 1037 F666 46A7

David Hageman

unread,
Apr 10, 2013, 11:00:55 AM4/10/13
to kul...@googlegroups.com
The easiest method would be one in which you had access to the switches.  Log into the switches and track down the exact port that a machine is plugged into by looking at the mac address tables.  You just follow the cable from that point ...

This is making several assumptions about how your place of business operates and what type of network they run ...



--
You received this message because you are subscribed to the Google Groups "kulua-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kulua-l+u...@googlegroups.com.
To post to this group, send email to kul...@googlegroups.com.
Visit this group at http://groups.google.com/group/kulua-l?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
================================================
David Hageman                                   <dhag...@gmail.com>
================================================

Kyle Hutson

unread,
Apr 10, 2013, 11:01:53 AM4/10/13
to kul...@googlegroups.com
1) If you don't already know the mac address, look it up by pinging the IP in question and then using 'arp -a' to find it.
2) It's often useful to know what vendor the card is. I use http://www.coffer.com/mac_find/ to look up the ethernet vendor. Sometimes it's not very useful (e.g. 'Realtek'), sometimes it is (e.g. 'Cisco').
3) If you have a decent switch, you can trivially find what port it's plugged into by looking at the mac tables.

That should at least get you a good start.


On Wed, Apr 10, 2013 at 9:55 AM, Kit Peters <pope...@gmail.com> wrote:

--

Andrew Beals

unread,
Apr 10, 2013, 11:03:29 AM4/10/13
to kul...@googlegroups.com

And the easiest way to do that is with switches you can snmpwalk.

Andy Beals / kc6sss

Matthew Welch

unread,
Apr 10, 2013, 11:08:13 AM4/10/13
to kul...@googlegroups.com
To quote the others,

Switch / Router side. These commands will help track down the IP's in use at the router side then all the way down to the switch side:

- show lldp neighbors

or the older way

- show cdp neighbors

- show mac address-table

- show ip arp

On the server side:

- arp -a

- nmap

Janky idea:

I've seen in one instance someone setup access so that they could ping the broadcast address. When doing this, they were able to simulate some network traffic on active ports and use SNMP to track down hosts that way. 

imo, cdp has its faults, but lldp has addressed some of those issues. If your switch supports lldp, I would look into turning that on. 


Kit Peters

unread,
Apr 10, 2013, 11:08:45 AM4/10/13
to kul...@googlegroups.com
I've got the MAC addresses; they're both Dell machines. That helps a little.  

I have one switch I can log in to; unfortunately that will only rule out a few machines.  All of our other switches are dumb.  This is what you get in public broadcasting when there's no dedicated IT staff.  :\

KP

Nick Anderson

unread,
Apr 10, 2013, 11:12:21 AM4/10/13
to kul...@googlegroups.com
On 04/10/2013 10:08 AM, Kit Peters wrote:
> I've got the MAC addresses; they're both Dell machines. That helps a
> little.
>
> I have one switch I can log in to; unfortunately that will only rule out
> a few machines. All of our other switches are dumb. This is what you
> get in public broadcasting when there's no dedicated IT staff. :\

Or you could do something to make the user come to you.

http://www.ex-parrot.com/pete/upside-down-ternet.html

Kyle Hutson

unread,
Apr 10, 2013, 11:06:00 AM4/10/13
to kul...@googlegroups.com
...or if you're in BOFH mode, you could just unplug that port and see who complains. :-)



On Wed, Apr 10, 2013 at 10:01 AM, Kyle Hutson <kyleh...@k-state.edu> wrote:

Kendric Beachey

unread,
Apr 10, 2013, 11:34:51 AM4/10/13
to kulua-l
(depending on whether I understood the original question, this might be tangential)

At one point I had several machines just on my desk that I would ssh into, among, between, etc., and sometimes I lost track of which one I was on.  I wrote this little script and put it on all of the machines, and ran it when I wanted to know which machine I was on.  The effect is to make the machine pop out its CD tray and pull it back in.

beachey@halstead:~$ cat bin/raiseyourhand 
#!/bin/bash
/usr/bin/eject
/usr/bin/eject -t
beachey@halstead:~$ 

Maybe in a server room with a whole bunch of machines, doing this in a loop for 60 seconds or so would be enough to let you walk through the room and find the machine?  For a situation with multiple server rooms it might not be so great.

Of course maybe we're rapidly approaching the time when optical drives are something you show the grandkids in a museum...  :-)


Kendric Beachey

Andrew Beals

unread,
Apr 10, 2013, 11:36:04 AM4/10/13
to kul...@googlegroups.com

More BOFH: Flood ping their IP during off-hours and see which switch port lights up.

Kit Peters

unread,
Apr 10, 2013, 11:58:17 AM4/10/13
to kul...@googlegroups.com
Kendric -

That's a nice idea, but it won't work in my case.  SSH is not open on either machine.   In fact, there are no open TCP ports on either machine, according to (Ze)nmap. 

KP

Kyle Hutson

unread,
Apr 10, 2013, 12:10:18 PM4/10/13
to kul...@googlegroups.com
A third BOFH - use 'arp -s the.ip.you.want 00:00:00:00:00:00' on anything it may be wanting to talk to (including the gateway). Wait to see who complains.

Kit Peters

unread,
Apr 10, 2013, 12:57:31 PM4/10/13
to kul...@googlegroups.com
At least one of these hosts has 49080/tcp open.  Any ideas what that might be?  Telnet times out, and nc doesn't produce any output.

Richard Allen

unread,
Apr 10, 2013, 1:21:27 PM4/10/13
to kul...@googlegroups.com

Use two dhcp pools.

If the dhcp server doesnt know a mac, they get routed to a registration page that records the Mac address and updates the dhcp server.

Once registered, they get an IP with full routing.

Jonathan Otsuka

unread,
Apr 10, 2013, 1:34:06 PM4/10/13
to kul...@googlegroups.com
Nlockmgr from googling. 

Jonathan Otsuka

Billy Crook

unread,
Apr 10, 2013, 3:19:01 PM4/10/13
to kul...@googlegroups.com
On Wed, Apr 10, 2013 at 9:55 AM, Kit Peters <pope...@gmail.com> wrote:
At my job, we maintain a list of IP addresses and the machines to which they are assigned.  As you might expect, this list periodically gets out of sync with reality, and it's my job to fix that.  

Lately, I've discovered a couple of machines on the network that aren't in my list, and aren't in the block we've assigned to DHCP.  I'd like to track these machines down and add them to the list.  

Any suggestions for tracking these machines down?  

0) probe the weird machines with nmap for identifiable traits
1) Log all their traffic at the router; from a spanport; or by arp spoofing the router to them, and look for identifiable dns and other cleartext traffic
2) Continuously log all show-mac-addresses and show 802.11 associations (might be different spelling) on switches and APs, to refer to later.
3) After one successful ping (to make sure that your arp entry for them is fresh)  UDP flood them, and follow the solid activity LEDs and/or complaint calls.  (useful if you don't have switches that maintain mac address lists)

Don't forget VMs share mac addresses of wifi hosts, but can have their own IP addresses; and can have their own mac addresses on wired hosts; and either way they can pull a separate DHCP IP from the actual host.

But the only actual, REAL solution is for an organizational policy to go in to place that no device may use the network in any way without first registering with the network administrator; and then enforcing that policy (aggressively) by denying all network services to unregistered hosts, and disciplining violators.  Anything less than that, and you will waste countless hours herding cats. 

If your leadership wants confidence that there are no rogue machines on the network, they must realize this can only be accomplished by administrative policy.

Karl Schmidt

unread,
Apr 10, 2013, 10:00:58 PM4/10/13
to kul...@googlegroups.com
Please tell us how this story turns out.


--------------------------------------------------------------------------------
Karl Schmidt EMail Ka...@xtronics.com
Transtronics, Inc. WEB http://secure.transtronics.com
3209 West 9th Street Ph (785) 841-3089
Lawrence, KS 66049 FAX (785) 841-0434

Truth is mighty and will prevail.
There is nothing wrong with this,
except that it ain't so.
--Mark Twain

--------------------------------------------------------------------------------

Kit Peters

unread,
Apr 11, 2013, 11:46:09 AM4/11/13
to kul...@googlegroups.com
It's going to come down to looking at every machine in the office and checking it off on the list, most likely.  I've got the guy who controls our router to do a tcpdump (filtered to those hosts) for me; maybe that will give me some insight.  


--
You received this message because you are subscribed to the Google Groups "kulua-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kulua-l+unsubscribe@googlegroups.com.

To post to this group, send email to kul...@googlegroups.com.
Visit this group at http://groups.google.com/group/kulua-l?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Billy Crook

unread,
Apr 11, 2013, 11:52:17 AM4/11/13
to kul...@googlegroups.com

What leads you to believe you can visually identify 'every machine in the office'?

I find that wireless and virtual machines complicate that approach to insanity.

To unsubscribe from this group and stop receiving emails from it, send an email to kulua-l+u...@googlegroups.com.

Kit Peters

unread,
Apr 11, 2013, 12:06:34 PM4/11/13
to kul...@googlegroups.com
Because there is no wireless on that network, nor do I expect there to be any virtual machines running.  Of the people in my department, I'm the only one who would be running any VM's.  This network is a /24 restricted to one part of floor of one building.  I have a key to every office in that building.   There are only so many places these machines could be.

Chattha, Ishwinder S.

unread,
Apr 12, 2013, 12:45:02 PM4/12/13
to kul...@googlegroups.com
That is so priceless I am so doing that for my wifi at home. :)

Tom Currie

unread,
Apr 14, 2013, 6:19:25 PM4/14/13
to kul...@googlegroups.com
BOFH answer:  set up a dhcp lease for that MAC addr that gives out everything except a default gateway.  Notify the help desk to expect a call.

this of course presumes that you never did like this job anyway.

;)


--
the mind commands the body and it obeys. the mind orders itself and meets resistance  -- St Augustine of Hippo

Billy Crook

unread,
Apr 14, 2013, 7:07:25 PM4/14/13
to kul...@googlegroups.com

Default net boot to dban?

Kit Peters

unread,
Apr 14, 2013, 9:36:56 PM4/14/13
to kul...@googlegroups.com
BOFH answers aren't going to fly; I *am* the help desk.  :)
Reply all
Reply to author
Forward
0 new messages