Bob's Blogs

Dirty laundry

Let's discuss how to make yourself unpopular with your co-workers. This is not the sort of advice you read about in Miss Manners or Live For Success. Today's subject is internal auditing.

Putting up a well-configured firewall is a great idea. It is also good to track authentication for the VPN and (if you still have it) dial-up pool. But the firewall and other things work even better when there are fewer things inside to compromise. Think of it as layers of defense in reverse - removing potential targets. It also works better when nobody has circumvented your protections by some other mechanism. So we'll cover a lot of these things. Let's start with the firewall. I'm performing a two-step process for one of my current customers and have done this in the past for others as well. Intrusion and extrusion testing. My laptop is sitting inside the firewall, with no special permissions of any sort -- just a normal workstation from the firewall's point of view. Using another system, I make an SSH connection to my Linux box at home and proceed to perform a full 64K TCP Nmap port scan of my laptop -- with a sniffer running on the laptop. That's the intrusion test. A simple scan of one system with no special permissions -- just to see what (if anything) does get past the firewall. Now, I reverse that. Using a port scanner on my laptop, I scan my home IP address, knowing that my Snort system will pick up anything and log it for later analysis. So right off the bat, I've got a picture of what the effective permissions "mask" looks like for inbound and outbound access. We'll assume that this will be dealt with later. If you've got an organization with multiple geographic sites, you need to check for rogue Internet connections. There are several ways of doing this. Here are a few:

Call up the remote site and ask for whoever is most technical at that location (the Alpha Geek) and ask him or her how they get to the Internet. Nothing like the simple approach.

Log into a remote router or other manageable device to which you have access and do a traceroute to a public site.

Log into a remote router or other manageable device, ping your external firewall, and look at the logs to see where it came from.

Set up a permit-only ACL (Access Control List) on their router that permits, in turn: Internal Organization traffic IP range(s), then wide ranges belonging to popular Internet sites (MSN, Yahoo, Google, ESPN, Ebay, AOL), then an "everything else" entry. Wait for anywhere from a few days to weeks and see what hits you get against the access list. If all of the popular and "everything else" entries are zero, you've probably got a rogue Internet connection -- assuming that it's not documented and official. You did look first, didn't you?

Check for illicit modems. There are still plenty of them out there. You'll need what is called a topology report (in the U.S., anyway) from the phone company(ies) lists all of the incoming phone numbers/lines that you are paying for. If you talk to whoever handles your organization's phone bills, they may already have a copy. There are some very fancy dialing checkers out there, but I still use ToneLoc (by MuchoMaas and MinorThreat), which is fairly ancient, but works just fine for me. It's got checks in there for various PBX signals/tones, but you don't need to look for them in this effort. It will dial in sequential or pseudo-random order any block of phone numbers you give it. It's purely a DOS (No, not Denial Of Service, Disk Operating System) application -- so you'll have to run it in a command line window. Interesting sidebar though: I once tried to disassemble the code for ToneLoc, only to discover that the authors have it wrapped up in its own encryption scheme. Very clever and discouraging enough to make me not bother. I'm sure someone reading this will think "lamer" to him or herself.

Check for rogue wireless access points. Get a laptop equipped with NetStumbler, make sure NetStumbler works with whatever wireless card you have in it against a known wireless access point -- even if you've got to make a trip to Starbucks or similar public place to test it. Point of clarity here: NetStumbler is not a wireless security tool; it's more of a wireless survey tool. There are ways to configure a WAP to evade detection, but if the owner has done a good job of it, then it's not that great a threat to your security -- relatively speaking anyway.

Check for cellular modems? Good idea, but I have no way that I'm aware of to do that. If someone in the reading audience does know, please email me here. Just because I don't know how to deal with such a thing doesn't mean that I don't regard it as a potential threat.

Check for outbound-oriented remote desktop apps. GoToMyPc and Mionet (mentioned in a previous blog) make an outbound connection to a remote site, which effectively allows inbound control to a system inside. GoToMyPc directs all traffic to "" I'm still investigating Mionet, so I don't have all the data yet.

Check your firewall for inbound remote control connections as well --mentioned in the same blog as just above.

Do a port scan internally for the following ports (there are more, but you've got to start somewhere):

SSH (22/tcp)
Telnet (23/tcp)
RDP (3389/tcp) (Microsoft Remote Desktop Protocol or Terminal Services)
pcAnywhere (5631/5632/tcp/udp)
Dameware (6129)
Citrix (1494)
Laplink (1547)
CarbonCopy (1680)
BackOrifice (31337, 8787, 31338, 54320, 54321, )
SubSeven (1234, 1243, 1999, 2773, 2774, 5873, 6667 (IRC), 6711-6713, etc.) (You can get free scanners for the bad guy ones)
VNC (5800/5900/tcp)
If you want to look up more, go, which uses the Neohapsis port listings. If you've got the client side apps, check to see if any of them let you in with no credentials or generic domain credentials.

Check for open file/folder shares. I still use the Legion tool, but it's not complete, so I've supplemented it with some Perl scripts and Batch files. The last few years, I've bought (and use) NetScanTools and NetScanToolsPro -- both from, which also scans for file shares and the like. One Midwestern company I audited a few years back had over 6 million writeable files discovered -- mostly from people sharing the root directory. But of those 6 million, between 400-500 of the files had names suggestive of confidential information. The criteria for these were as follows: 1st pass *.doc, *.xls, *.ppt, *.wpd (Word Perfect), *.vsd (Visio document). This reduced the list considerably down to the 10s of thousands instead of millions. The second pass was to check the file name list for words like "budget," "evaluation," "project," "review," "termination," "schedule," "offer" and others. This was what netted us the 400-500 filename list. I recall someone asking me at the time what those documents contained. My response was "Are you kidding?" Confidentiality aside, there simply isn't time to look at that sort of thing, unless you're actually looking for evidence of criminal wrongdoing -- in which case that's the wrong approach anyway.

Perform a port 80 (and its variants 81, 82, 83, 85, 88, 8000, 8001, 8080, etc.) scan to look for rogue Web servers. Many of them will be printers, print servers and authentication-required devices of various sorts. If you get prompted for a username and password, and simple efforts don't get you in, that's good.

However -- just to trash the previous paragraph -- there is a Web site that provided the manufacturer's default account settings for many, many different types of equipment. is the place to learn how many people in your organization have not bothered changing the manufacturer's default username/password. Pretty scary overall.

There are lots more things you can do to audit the inside of your network. But if you go through the list above, and add the other things that occur to you as you learn what is really going on in your network, you'll have made a really good start! And if you follow through, I applaud you. 

Meeting Network Security & Control Requirements: (408) 395-3921