Here's the error you see in the event logs:

Only one usage of each sock address (protocol/network address/port) is normally permitted.

The whole event log looks like this:

Event Type: Error
Event Source: Service Control Manager
Event Category: None
Event ID: 7023
Date: 24/03/2009
Time: 7:13:42 AM
User: N/A
Computer: THISCOMPUTER
Description:
The Internet Authentication Service service terminated with the following error:
Only one usage of each sock address (protocol/network address/port) is normally permitted.

The issue is that your DNS server has allocated some of the ports used by the Internet Authentication Service which means that you can't log into your routers, or vpn users can't connect anymore, or whatever you were using IAS for does not work. It actually causes the IAS service to stop completely. You may have seen this when you opened the admin MMC:

There was an error getting connection to the datastore. The handle is invalid

The Fix

Straight to the workaround:

• Open up the IAS admin console (administrative tools)
• Right click on "Internet Authentication Services" and go to "Properties"
• Click on ports and write down the ports that it's using
• Open up regedit -- insert warning of death here --
• Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
• Double-click the ReservedPorts value, type the range of ports used by IAS (1645-1646)
• Save it and restart the DNS Server service (you may need to reboot the whole server but not in my case)

Now when DNS restarts it'll make sure not to use those ports that you have already allocated for IAS and you're back working.

The Background

This is all caused by Dan Kaminsky so you should email him and tell him how many problems he's caused. (Just kidding but he still might enjoy that).

The real issue was the hotfix that Microsoft released MS08-037 which fixed a flaw in DNS servers and clients and was originally discovered by Dan Kaminsky. The MS08-037 security update randomizes the DNS transaction ID's of DNS servers, changes the logic when handling DNS caching, and most importantly to this error - randomizes the socket that the DNS server uses each time. That means that when DNS is running, it could be using that socket you have reserved for another application like IAS.

External Links

http://www.capslockassassin.com/2009/01/28/ms08-037-causes-port-conflicts-with-dns-and-ias-services/ - nice write up about the issue with screen shots

http://support.microsoft.com/kb/956188/ - MS support KB about the issue

http://www.microsoft.com/technet/security/bulletin/ms08-037.mspx - MS08-037 security bulletin

Today is the end of my three month contract with one of my clients' Chicago area sites. It's been a blast while I've been here and I want to thank everyone for their hospitality. Hopefully everything is in a better place than when I got there. :)

This also marks the end of me working with this client in general as they're making an effort to trim back outside consultants for echonomical reasons which is understandable. I've been lucky enough to work for with this company for more than six years during which time they've let me work at their Vancouver, Chicago, Virginia, Pennsylvania, Florida, and Rochester sites. I've learned a ton through the years working with the IT staff and management as they grown the IT dept in all kinds of directions.

I'll be heading back home to Rochester, NY and continue to work for my employer, Hurricane Technologies, Inc. and they already have new projects lined up for me that look pretty interesting.

I had a late night discussion on the L this weekend about detecting someone sniffing on your network. I think his question meant to be "how do you detect if someone is performing a man-in-the-middle attack" which is just too much of an open question to go into right now. But, if the question was how do you detect if someone is sniffing traffic on your network, that could be answered in a simpler more blogable way.

Promiscuous Mode

When most(all?) systems attempt to sniff network traffic, their network cards run in promiscuous mode. But what does this mean exactly? Wikipedia has a succinct explanation:

Promiscuous mode is a configuration of a network card that makes the card pass all traffic it receives to the central processing unit rather than just packets addressed to it — a feature normally used for packet sniffing.

Detecting Promiscuous Mode Network Cards

So if know that promiscuous mode is used for sniffing and if you're attempting to control your local network, you're going to want to know which systems are sniffing on the network so lets find out who's running in promiscuous mode. There are a ton of tools out there to just detect promiscuous mode (see External Links below) but once again it's Nmap ftw.

Development versions of NMap include a script called "sniffer-detect.nse" and in current/old versions this script is called "promiscuous.nse." You can run it like this:

nmap --script=promiscuous 10.10.10.0/24

If a system has been detected to be running in promiscuous mode, you'll see this:

Interesting ports on BADHOST (10.10.10.76): Not shown: 997 closed ports PORT STATE SERVICE 23/tcp open telnet 53/tcp open domain 80/tcp open http MAC Address: 00:21:29:71:22:68 (Cisco-Linksys) Host script results: |_ Promiscuous detection: PROMISCUOUS (tests: "11111111")

We can see that the system has been detected to be running in promiscuous mode and the result is "11111111." Different operating systems report different combinations of 1's. Linux reports "11111111", Windows 2k, XP, Vista, and Windows 7 reports "111___1_", and Windows 98 reports "1111__1_". By default, the script will only report NICs in promiscuous mode so if you don't see get any results, that's because the scan returned false.

When This Doesn't Work

So that's neat, we can detect when systems are sniffing the network using wireshark or other sniffing tools but what about if someone installs a hub or network tap? These are devices that are designed to forward copies of packets to another interface without making any noise thereby sniffing traffic that goes through the device.

The short answer is you can't.

The longer answer is that it depends on the hub and how you've setup your network. As far as I know Cisco and other higher end network equipment give you some control but it's not perfect.

Detection vs Prevention

Of course I have to say that detecting a sniffer is not a good way of maintaining control of the network. Even if you automate this process, it most likely will be too late to protect from anything being stolen.

These are the preventative measures that I've compiled and if someone has other suggestions, please let me know.

• Host to host encryption (IPSEC)
• Force other encrypted protocols (SSL,FTPS,SSH)
• Have a switch only policy for your network
• Implement a NAC/NAP system
• Keep physical access to network closets/rooms restricted and controlled
• Perform regular physical inspection of all your network interfaces in the facility (offices, conference rooms, hidden in drop down ceilings - no seriously)
• Implement a secure proxy server for web traffic (Squid)

External Links

http://www.mnin.org/?page=promisc&left=off - good break down and detection script using perl and nemesis
http://www.securityfriday.com/promiscuous_detection_01.pdf - the original paper describing how to detect NICs in promiscuous mode using ARP packets
http://nmap.org/nsedoc/scripts/sniffer-detect.html - quick description of what sniffer-detect.nse does
http://www.microsoft.com/downloads/details.aspx?familyid=1a10d27a-4aa5-4e96-9645-aa121053e083&displaylang=en - Microsoft GUI tool that can scan for promiscuous mode NICs
http://www.securityfocus.com/tools/3333 - tool to run locally on a *NIX system to detect promiscuous mode enabled NICs
http://www.oxid.it/ca_um/topics/promiscuous-mode_scanner.htm - Cain and Abel have the ability to scan for promiscuous mode MAC's too. (wasn't able to get it to work though)