dhcp.lease showing strange entries

lease 172.16.0.174 {
  starts 2 2011/11/22 10:23:11;
  ends 3 2011/11/23 10:23:11;
  binding state active;
  next binding state free;
  hardware ethernet 6c:50:4d:0e:c8:c0;
  uid "\000cisco-6c50.4d0e.c8c0-Vl1";
  client-hostname "Switch";
}
 cat /var/lib/dhcpd/dhcpd.leases | grep cisco -A 3 -B 6 | grep lease | wc
   1190    3570   24990

Found some very strange entries in our dhcpd.leses file. All form the same mac address. It queries for all available ips. It's will get a new lease every second. It has now done the same thing 4 times on the network. As you can see from the cat entry that is 1190 entries all linked to the same mac address, all since 9:30am this morning.

I expect our network is being scanned. For available ips.

What can I do to find out where this device is and what it is doing.
Does any body know of some venerability scanners that would do this.
Does any body know of a way to track this device.
To see traffic coming to or from that device.
A way to block that mac address on our network.

I cleaned out the lease file and restated the dhcpd server, with in 20 minutes we had another 120 entries.

nelaaro

Posted 2011-11-22T10:58:14.253

Reputation: 9 321

Block/blacklist the MAC and see who complains? BOFH! ;) – HaydnWVN – 2011-11-22T12:04:37.220

@haydnwvn I am more worried that this is some malicious activity. I would like to do more then just close the door after it has opened. I want to stop the door from being opened. http://superuser.com/q/360238/67952

– nelaaro – 2011-11-22T12:11:29.080

That is a Cisco vendor id, maybe a rogue switch? – charlesbridge – 2011-11-22T12:24:44.033

@nelaar wouldn't 'blacklisting' the MAC address accomplish that? – HaydnWVN – 2011-11-22T12:35:34.420

1@HaydnWVN, if someone is maliciously probing the network, they can just switch to another MAC address if that one is blacklisted. – a CVn – 2011-11-22T13:15:59.380

True, but you won't know for sure until you try it, if it's just a device causing it then you'll have 'fixed' the problem (although not actually 'solved' it) ;) – HaydnWVN – 2011-11-22T14:09:49.207

Answers

To track this down, check your switches. Start with the switch the dhcp server is attached to. If you are using Cisco switches, then do

show mac-address-table | inc 6c:50:4d:0e:c8:c0

This will display the ports that the mac address has been seen on. If it is a straight switch port, then find out what is plugged into it.

If it is a trunk port, or otherwise connected to another switch, then go to that switch and repeat the process. Eventually you will find the device issuing the dhcp requests.

The rogue switch idea is a possibility. If you are using ip helper (dhcp relay) on a vlan, and the switch is incorrectly substituting its own mac address in the dhcp payload (not the ethernet header) then it would look exactly like this. However, given that you have blocked the mac in iptables, if this was the case, you would have a whole segment of your network unable to get ip addresses. You'd probably know about it by now.

Paul

Posted 2011-11-22T10:58:14.253

Reputation: 52 173

No body has complained so far. Will investigate the routers / switches near the server to find the source. Our network is simple, and we are not assign ip across vlans. – nelaaro – 2011-11-22T13:28:28.707

Excellent, it should be easy to track down then. – Paul – 2011-11-22T13:33:17.177

http://www.cyberciti.biz/tips/iptables-mac-address-filtering.html

/sbin/iptables -A INPUT -m mac --mac-source 6c:50:4d:0e:c8:c0 -j DROP

iptables -L -n -v
Chain INPUT (policy ACCEPT 1029M packets, 460G bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 654M packets, 1067G bytes)
 pkts bytes target     prot opt in     out     source               destination 

/sbin/iptables -A INPUT -m mac --mac-source 6c:50:4d:0e:c8:c0 -j DROP

 iptables -L -n -v
Chain INPUT (policy ACCEPT 1029M packets, 460G bytes)
 pkts bytes target     prot opt in     out     source               destination         
   26  8468 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MAC 6C:50:4D:0E:C8:C0

From there you can see it has now blocking 26 packets.

nelaaro

Posted 2011-11-22T10:58:14.253

Reputation: 9 321