Archive for the ‘Wireshark’ Category
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 188.8.131.52 (Rogue) and 184.108.40.206 (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 220.127.116.11-250/24
- Setup PC07 (HD # 01) as DHCP server (rogue) to dispense IPs 18.104.22.168-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 22.214.171.124 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 »
I’ve wanted to be able to use Wireshark to sniff on my LAN using the Cisco 2900XL Switch instead of an old hub I keep around for LAN sniffing purposes, but I’ve never taken the time to use the port monitoring features of Cisco’s SPAN, until now.
It’s pretty straight forward. Just configure one port to monitor any traffic on another. The IOS:
port monitor FastEthernet0/17
port monitor FastEthernet0/18
port monitor FastEthernet0/19
port monitor FastEthernet0/20
port monitor FastEthernet0/22
port monitor FastEthernet0/23
I was even able to hook up this PC to the 0/1 monitoring port and use it normally — I’m typing this on that PC that’s on the internet now. Wireshark was able to see all that was happening on those other ports. As an aside, the most persistent traffic were STP BPDUs issued from each of the 6 active switch ports every 2 seconds. FWIW, the packets look like this:
I was reading a manual for the 2950 (not 2900XL) earlier today. Clearly, there is MUCH more in this area of SPAN that can be accomplished on the 2950. Still, this is doing everything I need it to.
BTW, as I was browsing the 2900XL manual, I was distracted for a minute by the section on using CMS, a web browser GUI for switch management. I thought, why not give it a try? I’ve seen Cisco GUI interfaces for PIX and Wireless Access Points and they’re a good way to see the wealth of features at a glance. But, alas, this seems to require having the software loaded on the switch. All I got when I plugged in the patch cable and entered http:192.168.1.192 was a basic screen:
When you click on the first line about CMS or such, I get a 404 error, presumably because I don’t have that GUI software installed on the switch.
There was some merit in the available choices. For example, I received a nicely formatted gob of “shows” when I clicked on the Show tech support option. The 1st, show ver, looks like this:
—————— show version ——————
Cisco Internetwork Operating System Software
IOS ™ C2900XL Software (C2900XL-C3H2S-M), Version 12.0(5.4)WC(1), MAINTENANCE INTERIM SOFTWARE
Copyright (c) 1986-2001 by cisco Systems, Inc.
Compiled Tue 10-Jul-01 11:52 by devgoyal
Image text-base: 0x00003000, data-base: 0x00333CD8
ROM: Bootstrap program is C2900XL boot loader
Switch uptime is 32 minutes
System returned to ROM by power-on
System image file is “flash:c2900XL-c3h2s-mz.120-5.4.WC.1.bin”
cisco WS-C2924-XL (PowerPC403GA) processor (revision 0x11) with 8192K/1024K bytes of memory.
Processor board ID FAB0406T00W, with hardware revision 0x01
Last reset from power-on
Processor is running Enterprise Edition Software
Cluster command switch capable
Cluster member switch capable
17 FastEthernet/IEEE 802.3 interface(s)
32K bytes of flash-simulated non-volatile configuration memory.
Base ethernet MAC Address: 00:B0:64:ED:12:C0
Motherboard assembly number: 73-3382-07
Power supply part number: 34-0834-01
Motherboard serial number: FAB040370MM
Power supply serial number: PHI0341009W
Model revision number: A0
Model number: WS-C2924-XL-EN
System serial number: FAB0406T00W
Configuration register is 0xF
Over breakfast coffee, I analyzed the Ethereal output from the DHCP discovery process that took place last night on the non-domain kitchen PC. It was textbook but for one thing: The PC sent out three DISCOVER packets at 0 seconds, 3 seconds and 11 seconds, each followed by an OFFER from the server within .0007 seconds! Why didn’t the PC respond to the first. I did notice at the pc some delay after I typed IPCONFIG /RENEW. I was even thinking that it may have failed since I’d guess it was about 15 seconds before the DOS prompt came back.
It was very interesting to see the format of the OFFER packet:
Note the hard coded renewal and rebinding times, i.e, 50% (1.5 days on a 3 day lease) and the 87.5%, which I had assumed was computed by the client. Instead it appears that the server does the computation and dictates the time frame.
The REQUEST and ACK seem to have all this information included, too. I guess this is to provide unique values since all packets are 255.255.255.255 broadcast packets. I’ll look to see if the MAC address is within… Yes, it’s embedded in the packet.
Thanks, Ethereal for clarifying all this cryptic stuff that’s all in binary within the packets!