Archive for the ‘DHCP’ Category
Wanting to make changes to the wifi and DNS settings of the new routers that Cincinnati Bell (CB) is routinely installing now, I went about researching and using trial and error. The goal was to implement WPA2 wifi security and OpenDNS at a router level, so as to help clients be a bit more secure.
Overview of high speed modem/router
Near as I can tell, Cincinnati Bell is using its installed fiber in urban locations to offer a high speed internet, combined with television channels via internet, so-called IPTV. Westell has long been a provider of equipment to our local phone company and this device is meant to offer “Advanced, dual-core processing power with Ethernet, MoCA, or VDSL2 WAN interface for fiber-to-the-home and fiber-to-the-curb networks.” (link) These are hunka-chunka, white bricks and I’ll leave it to others to show us what’s actually inside them and perhaps explain their hugeness.
Getting access to advanced settings
As made clear on Westell’s web site their stuff is marketed to ISP’s, not thru retail / wholesale channels. As such, finding a manual is like pulling teeth. I must give credit to others’ posts on for helping me just figure out the interface and that you need to click on menus up top AND on the left.) Read the rest of this entry »
Cisco allows you to monitor any switchport to limit the rate of DHCP client activity. Presumably, someone flooding a network with spurious DISCOVER packets could give a DHCP server headaches.
I figured extra packets would just be dropped, but was in for somewhat of a shock when the port was placed into a permanent ERR-DISABLE status. That means a SysAdmin would need to reset the port manually, unless other provisions were made.
So what’s reasonable number of packets per minute? Maybe 3? I set it to 2 to see what the result. Pretty drastic!
The IOS: Read the rest of this entry »
Don’t look here if you’re hoping to actually see a “how-to.” Here’s a link to Cisco page on Switch Auto-Configuration. (I haven’t gone through it, but from what I read I wouldn’t assume it’s going to be easy. Looks like it’s easy on the switch; but you have to configure a ton of stuff!)
So the point of this posting is just to show what displays on your console if you reload or start the switch after erasing the startup-config and a DHCP server happens to be attached. What’s not apparent from the listing is that there will be endless console messages showing attempts to reach a config server.
— System Configuration Dialog — Read the rest of this entry »
OVERVIEW – Where Cisco’s DHCP Snooping is used to prevent a rogue DCHP server from offering up bad IPs or worse a bad gateway
My daughter’s school gives every student two different ID numbers to use. It’s so confusing for her as to which one to use when. In the same manner, allowing a second DHCP on a subnet segment is apt to confuse many host PCs and the users too. Any home router or a Windows Shared Internet or a distro of Linux can easily be setup as a DHCP server, plugged into your network and begin the confusion.
Worse, if a malicious hacker wants to intercept all packets on a network, browse them and send them on their way, setting up a rogue DHCP server, which can define the gateway IP as itself, is one way to do it (i.e., a man in the middle attack.)
Fortunately, Cisco switches allow you to mitigate either the accidental or intentional danger by defining one or more ports on a switch that can be trusted to dole out IP using DHCP. All ports in a VLAN are initially flagged as untrusted for any DHCP offers, then you may indicate which are to be trusted. We will use the global config command ip dhcp snooping to turn it on. Then we’ll use interface commands to set it up for various ports.
I learned a bit more about the somewhat mysterious background workings of DHCP. And frankly, some mysteries continue. Watching WireSharksniff packets provides a clearer idea as to what’s going on. When a client attempts to renew an IP lease (at half way thru its duration) I believe it uses a direct unicast with the original server. If never answered, it will resort to a discover broadcast, trying to locate any DHCP server to offer it an IP. What seems strange though is after a host interface is forced to close down (in Linux with an ifdown command) then brought back with an ifup, the host seems to request the same IP address it had before even if it’s requesting the IP from a different DHCP server. What’s more, if there should be two DHCP servers present (an abnormal and incorrect setup) the host seems to accept (i.e., request) the IP from the original server. This would seem to indicate the need for a hacker to disable the original DHCP server or intercept any of its offers.
Now I overcame this by temporarily disconnecting the Good DHCP server and resetting the host NIC (using ifdown + ifup). The host PC then became responsive to the Rogue server. Note in the Wireshark sniff display below that both 22.214.171.124 (Rogue) and 126.96.36.199 (Good) DHCP servers offered IPs, but in the window below showing the details of the REQUEST packet that it’s accepting the Rogue offer.
Eric Capal says it’s because the first one doesn’t have to do an ARP request since the original server is still in the host’s ARP cache.
SETUP – Where two DHCP servers are established and the fun begins
- Setup PC 11 (HD # 07) as DHCP server to dispense IPs 188.8.131.52-250/24
- Setup PC07 (HD # 01) as DHCP server (rogue) to dispense IPs 184.108.40.206-210/24
- (Oops, forgot to activate the server in Windows!)
- Activated MST instead of PVST (see previous post) in an effort to lower the BPDUs. That didn’t work as there’s only 1 VLAN in use.
- I messed around with Wireshark trying to get some capture filters to work. Need some training here. Want only source (not transmitted or destination) on one PCs MAC.
- Put both DHCP servers on one net and did some ifdown/ifup commands. Seems a host will go back to its original DHCP server and use it to get its IP. Then if that one is unavailable, it goes to the other and then becomes “loyal” to that one. Capal says that’s because the first one doesn’t have to do an ARP request since that’s still in its ARP cache.
- I was surprised to see that PC10 was leasing the 220.127.116.11 address after it was not suppose to be able to access DHCP advertisements from the rogue DHCP server. In fact it was NOT in contact with that server, it was merely re-obtaining the 252 IP from the “good” DHCP server. It was its previous IP and it was a valid IP in the “good” server’s scope of IPs. Apparently it requested the “good” server to lease that same IP even though it was originally dealt from the rogue server.
Now for the Show Run and Show IP DHCP Snooping commands: Read the rest of this entry »
Let’s see what the Conflict Detection setting does for us. It’s supposed to ping the prospective IP before assigning it. Let’s see how that goes by setting up a scope that includes some static IPs, namely the first 10. Hang on!
I setup 192.168.1.4-192.168.1.63, knowing that .4 is available. I’ll now setup a machine or two to use DHCP. I setup .68, which was static to Obtain automatic (funny, this is the first time I’ve configured the IP settings where it then did NOT gray out the DNS IP address and set that to automatic, too. Perhaps it’s because this is on a domain now.) I’ll sniff this.
DHCP service database files
|Dhcp.mdb||The DHCP server database file.|
|Dhcp.tmp||A temporary file used by the DHCP database as a swap file during database index maintenance operations. This file sometimes remains in the Systemroot\System32\Dhcp directory after a system failure.|
|J50.log and J50#####.log||A log of all database transactions. This file is used by the DHCP database to recover data when necessary.|
|J50.chk||A checkpoint file.|
Well, I left Ethereal and we all went on the hours-long Christmas tree hunt. When I came back, there were almost a hundred ICMP messages and fewer, though many, DHCP messages, but after I clicked the Stop button, Ethereal must have abended. I started it again, but seems like nothing.
I was surprised that my laptop, when coming out of hibernation, does NOT keep the same IP settings and switches to the top-of-the-list wireless network, in the case “thelab.” I am now going to experiment to see if the same thing occurs when I put it into Standby after choosing the second choice “wescott” wireless network.
It does! After it comes up, the wireless System Tray icon indicates it’s on “thelab” flashes to indicate that it’s negotiating a network connection.
Hold on. It seems that it may have been due to my moving the folders (see below) I’ll try again after I get the thing up and going.
Looking through the snap-in, I see that you can move most of the DHCP folders, so I moved them to E:. It prompts you to ask if you’re ready to stop, then start the service. I say go for it.
Works well, but HOLD ON! It’s wiped out my scopes. Thanks a lot guy, that might have been a good thing to point out BEFORE I wiped ’em out. Let me put back the scopes. Wait, can I do a restore? Let’s try stopping service manually. Done, but when I try to restore it tells me the service isn’t running. So, I start it again and try the restore. It tells me it needs to stop/start the service. The original scope is NOT restored! So here goes with a manual restore.
Seems to be okay, but now what will happen with the already assigned .32 IP that the kitchen got? Will it be assigned again? Should be fun let’s see what happens when I try to do this?
It gave out .35, somehow “knowing” that .32, .33 and .34 were already leased. Hmmm. Let’s see what Ethereal shows. $%@! It shows NO packets. Tried again with NO filter, still no good. Ethereal’s broke?! Started it again and worked okay. Captured with filter and it abended. Guess I have to restart this machine. Good reason not to do sniff, etc. ON a server.
Well, I tried it on an XP machine and clearly Ethereal does not want to do the “OR” operation with port 67 or 67 or ICMP packets. Seems to capture fine, but after Stop is pressed and it needs to read from the capture file and format the packets on the screen it dies. I uninstalled it on the server. I was able to use Ethereal to capture all packets, then used the Display filter with the expression:
(udp.port == 67) (udp.port == 68) or icmp
and it shows what happens. Pretty interesting. It shows the DHCP RELEASE when I click on the other network to free up the IP on the original network. Later when I access the network again, it goes through the discovery process. Immediately, the client pings the DHCP server 4 times, then pings the DNS domain server twice. Twenty seconds later the DNS server pings the client back. The client pinged again three times over the next few minutes. Keep in mind that I had NOT turned on DHCP server Conflict Detection advanced option.
Just to see what was happening when a computer reboots and has been assigned an IP by DHCP, I reset the PC described earlier (i.e., 192.168.1.34). I expected no activity so was surprised to sniff 4 packets, 3 from the PC. It was a REQUEST packet from the PC, followed within 5/1000th of a second by an ACK. Over a minute later, the PC issued and INFORM packet and another 3 seconds later.
I’m going to put the sniffer on for DHCP packets and, if I can figure out how, for PING packets, too.
Update: Use Ethereal’s capture filter using the expression:
port 67 or port 68 or icmp