Archive for the ‘Security’ Category
Having set up my SBS server some time ago, I couldn’t remember where I had set the incoming port number (falsely called 65535 here.) I find the button that pops open the dialog box for this quite forgettable, so I’ll document this here hoping to help someone — me included — in the future.
Running TCPView from SysInternals shows that inetinfo.exe is listening on port 65535.
This was set in Exchange System Manager, drilling down seven levels to the SMTP-Default, right-clicking Properties, Advanced and editing the incoming port number. By default, this is port 25 for SMTP.
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 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 »
Never having “lost” my password in Linux, I’ve always bypassed articles about how to reset passwords (though I’ve noticed that Linux software available to reset XP administrator passwords are not gratis). Not sure why I set the Ubuntu server password to something I’ve forgotten, but I thought, “Oh, well. I guess I’ll reinstall.” But then, I figured it might be worth a shot to see about resetting it. Within minutes I had it reset! There seem to be many sites that give various guidance, but specifically for Ubuntu (6.10 Edgy Eft in my case) here’s all it took:
- At system boot, when Grub menu appears, select Recovery. Eventually, a root (#) command line appears.
- Use “cd /etc” and “tail passwd” to see the last part of the password file. You’ll see your login name.
- Use “passwd login name” and it will prompt you for a new password.
- Press Ctrl-D and the X window will begin and you’ll be able to login.
Sure glad I took the 2 minute route instead of the 2 hour route!