Companies spend thousands of dollars to protect the information on their networks, but most give little thought to the information they make publicly available through services running on their servers or through other outlets such as the company Web site or external listings. Obviously, you must share some information on the Internet. However, you might inadvertently be permitting unnecessary and excessive access to information about your network through null sessions, SNMP, WHOIS listings, company Web sites, device naming conventions, and DNS zone-file transfers. Intruders can piece together that data to build a map of your network that is as accurate as it would be if you had prepared a network diagram for them.
Null Sessions
Windows null sessions are some of the worst offenders at leaking information. Null sessions are established connections that use a blank (i.e., null) password and username. These connections automatically receive guest privileges on a system. Although intruders can't use a null session to access crucial data or services, they can use such sessions to get listings of all the users, shares, and services on the machine and to learn which users have administrator rights or haven't logged on in a while. This type of data is a wealth of information to someone trying to get into your network. Windows versions earlier than Windows XP permitted null sessions by default because applications used null sessions to get information from the system. Microsoft finally wised up, and XP limits null access by default. But unless you have an all-XP network, you might be running machines that permit these sessions.
To limit null sessions on XP or Windows 2000 systems, open the Control Panel Administrative Tools applet and select Local Security Policy. Open the Local Policies\Security Options object, then double-click Additional restrictions for anonymous connections in the right-hand pane. In the Local policy setting drop-down box, select No access without explicit anonymous permissions or, for a higher level of security, Do not allow enumeration of SAM accounts and shares. (Be aware that the more restrictive setting might affect some file-sharing capabilities when your network contains pre-Win2K clients.) On Windows NT or Windows 98 Second Edition (Win98SE) systems, open a registry editor and go to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa registry subkey. Edit or add the RestrictAnonymous value (of type REG_DWORD), and set the value to 1.
SNMP
Services such as SNMP can also reveal information about your network. SNMP was originally developed to provide a standard for gathering data on network devices. Although many companies use the service to run network-management packages such as Hewlett-Packard's HP OpenView or Nortel Network's Optivity Network Management System, many more organizations don't use SNMP and don't even realize that it's running on their servers and other network devices.
The problem with SNMP is that almost every device that runs SNMP contains built-in, default manufacturer community strings—passwords that let you query and in some cases reconfigure the device. Even folks who actively use SNMP often leave these default community strings unchanged. Intruders then can use freely available tools such as Snmpwalk or Snmpset to learn all about that device and even shut it down. And recently, several serious SNMP exploits have come to light. These exploits don't require the community strings in many cases and therefore can be used against even secure SNMP implementations.
If you use SNMP on a network device, be sure to change all the default community strings. Also, determine whether the device vendor has issued any patches that address SNMP vulnerabilities. If you don't use SNMP—and if you aren't sure whether you do, you probably don't—be sure to turn off SNMP on any machines that might be running it.
WHOIS Listings
The first place to go when you want to know more about who runs a company's Web site is VeriSign's WHOIS search engine at http://www.netsol.com/cgi-bin/whois/whois (formerly maintained by Network Solutions). Something as simple as your WHOIS listing can give intruders valuable information about your network.
Web Figure 1 (http://www.windowswebsolutions.com, InstantDoc ID 25579) shows an example of a typical WHOIS record. One piece of information that this record reveals is a technical contact—someone who is usually fairly high up in the IT hierarchy. An intruder can use the technical contact's email address to launch social-engineering or email-spoofing attacks, in which the intruder tries to trick legitimate users out of sensitive information such as usernames and passwords. For example, few people would hesitate to download an attachment that came with an email message that appeared to be from the company's network manager, instructing the recipient to "Please load this software patch immediately." However, that message could be an email spoof from an intruder, tricking users into loading a Trojan horse that will let the intruder into the network or a keystroke logger that will capture and email user passwords back to the intruder.
Sometimes, the technical contact is an outside organization such as a consultant or ISP. Such cases usually are easy to identify because the domain for the contact's email address differs from the company's domain; a quick Web site visit to the domain name in the technical contact email usually can verify the contact's role. This situation makes social-engineering attacks even easier to pull off and opens up physical-access concerns. Imagine a technician showing up on site, claiming to be with your company's ISP and needing to look at your Internet connection. Is your receptionist likely to ask for identification before giving that person access to the wiring closet?
The WHOIS listing also can give intruders your company's email-address format. From the sample WHOIS record that Web Figure 1 shows, an intruder can determine that Example Systems uses the firstname.lastname@example.com format. If the intruder knows that the company president's name is John Smith, he or she has a good idea that [email protected] might be a good email account to hit with a brute-force attack: The account is likely to contain sensitive information, and executives are often the worst about using easy-to-guess passwords and are sometimes exempted from the stricter password policies that other employees must observe.
To limit your WHOIS exposure, use only generic titles and email addresses in your WHOIS record. An address such as [email protected] or [email protected] provides enough information to legitimate users—and protects you when a primary technical contact leaves the company. WHOIS record changes can take several weeks, during which a terminated technical contact could have access to domain information. Also, domain providers typically email the primary contact to verify any requested changes. If your primary contact's email address is specific to one person and that person then leaves the company, the domain provider's email messages will bounce and you'll need to jump through additional hoops to make your changes. And be sure to keep your WHOIS listing current. If phone numbers or email addresses are outdated or incorrect, you might encounter hassles when you need to make a quick change.
Web Site Information
Periodically review the information on your Web site from a security standpoint. Having a voluminous listing of specific email addresses on your Web site is a bad idea, contrary to what the marketing department might say. In addition to the reasons I explained in relation to using specific addresses in your WHOIS listing, publishing such email addresses on your Web site provides fodder for recruiters and spam robots. Use generic email addresses (e.g., sales@, accounting@, info@) that forward email messages to the correct parties. Better yet, funnel all requests through a Web-based form, which will let you collect more information about a request and more easily categorize and route it.
You should also use a major search engine to search for your Web site and see what comes up. In addition to confirming that your primary listing is correct, go farther down the results page to look for listings that shouldn't be public. You might find old Web pages that are no longer connected to your Web site but that search-engine robots (and consequently, intruders) can still access. A person with a lot of patience can sometimes find old project data or even an internal site. To use the Google search engine to determine whether any sensitive files or data have made it onto the Web, use the search parameters filetype:ext and site:yoursite.com, where ext is the file extension you want to search for and yoursite.com is your Web site. These parameters will search for any public files with the specified extension, from your site only. Good extensions to check for are .mdb, .xls, or .dwg (for technical drawings). You can also use a Web-mirroring program, such as SoftByte Laboratories' BlackWidow, to scan your Web site, listing all the pages and whether they actively link to other pages.
Device Naming Conventions
As far as network tools go, nothing shows an intruder how your network is physically laid out like the Trace Route—aka Tracert (tracert.exe)—command-line utility. The command
tracert <IP address>
shows an intruder the names of all visible hosts between the intruder and the target IP and the relationships between those hosts. And if you've been nice enough to use descriptive names for your network devices, malicious users can label each point as a router, firewall, mail server, and so on. Sometimes the tool reveals the types and models of routers (e.g., cr for a Cisco Systems router) and the speed of the company's Internet link (e.g., ds1 for a T1 line, POS for a packet over a Synchronous Optical Network—SONET). In some cases, I've seen this tool traverse an internal network, revealing the company's private network schemes. (IP spoofing, anyone?) Servers with descriptive names also help intruders decide where to focus their efforts. Host names such as accounting1.example.com or oracleserver2.example.com look juicy to potential intruders—the latter name even tells them the application to work on.
Web Figure 2 shows the sample results of a typical Tracert run into a corporate network. (I've changed the IP addresses to nonpublic addresses.) An intruder can use the IP host names to start building a network map. The results show that the company uses a Cisco 7500 router, connects to the Internet through a T1 line, and employs Sprint as the ISP. The Tracert results even provide a customer reference number that might come in handy for social engineering. Intruders can determine which cities the network comes from and flows to, therefore finding central aggregation points. (Abbreviations such as DAL and HOU won't fool a savvy Tracert user.)
Instead of using descriptive names for your devices and servers, try using a genre naming convention. Pick a common group of things, such as Snow White's seven dwarves (assuming you have no more than seven servers), country names, or whatever strikes your fancy. (I once named a whole network after Irish beers.) Such names are still easy to remember for people in the know, but an intruder wont be able to determine that sneezy.example.com is your e-commerce server or that dopey.example.com is your email server—at least not without doing a lot more work.
For internal naming conventions, resist the temptation to use host names such as johnscomputer or frontdesk. Although such conventions make life easier in the short term, they can also raise the temptation for users to go snooping through Network Neighborhood for the boss's computer or the Human Resources (HR) system that holds salary lists. And such location-specific conventions can be a nightmare when you need to move machines around.
DNS Information
If you run your own DNS, don't permit zone-file transfers between your DNS servers and other DNS servers unless those servers are secondary servers for your domains. To secure zone-file transfers, open the Microsoft Management Console (MMC) DNS snap-in. Open the zone's Properties dialog box and go to the Zone Transfers tab. If you don't run a secondary server, clear the Allow zone transfer check box; if you do run a secondary server, select the Only to the following servers option, then add your backup DNS servers to the IP address box. Also, make sure that the only hosts you let make queries against your DNS server are hosts on your internal LAN or WAN. You have no reason to offer use of your DNS server to the outside world.
Time Well Spent
It doesn't matter how high your castle walls are if you hang the keys to the castle in the town square. Review your WHOIS listing, your naming conventions, and your server configurations to keep from giving the bad guys a blueprint to your network. The time you spend will be worth your while.
