Does this scenario sound familiar? You're in between meetings or running around taking care of any number of problems when the dreaded message or phone call arrives: Your firewall just sent you an alert that the computer at IP address 10.15.97.12 is sending packets like crazy to the NetBIOS ports of hundreds of other computers. You think the problem might be a worm, and you need to ask the PC's owner to disconnect it from the network ASAP. Sounds like a quick process, but even something so simple can be error prone—especially when minutes count. Let's take a look at how naming conventions and IP standards can help you quickly identify systems, then we'll compare the approaches that two everyday Windows tools take to resolve IP addresses to names.
Know Your Subnets
Network engineers think in octets, and so should you. As companies grow in size, they will likely mature from a single, flat subnet into multiple subnets that represent security zones or offices. A consistent and predictable IP subnet address scheme will streamline your incident response. For example, if your company is large and uses a private IP space, you probably use 10.0.0.0/8 or 172.16.0.0/12 private subnets, per Request for Comments (RFC) 1918. Consider designating the second octet as an office location: for example, use 10 for New York, 15 for Chicago, and 20 for Seattle. Then, if you receive an alert from the computer at 10.15.97.12, you immediately know that it's in the Chicago office, and you can notify administrators in that office right away.
Let's take this one step further. Use the third octet for intraoffice subnets such as perimeter networks, server subnets, and user subnets. For example, if you allocate the numbers from 96 to 111 to workstations in a user subnet, then you know that 10.15.97.12 is a computer in the user subnet in the Chicago office.
Renumbering your office's IP space isn't necessarily feasible for every organization, but if you're creating an architecture for a new office or are thinking about an IP network addressing change, consider adopting a standard that will speed security event response.
The examples I've given reflect another security best practice: that of separating computers by security risk into different subnets. An example is to keep user workstations in a different subnet than servers. But even if you run a flat network consisting of a single subnet, you can still assign servers to one IP range and workstations to another so that you can discern the general location of a computer by its IP address. For example, in the subnet 192.168.0.0/24, you could assign numbers in the third octet from 0-10 to network equipment, from 11-100 to servers, and from 101-200 to user workstations.
A thoughtful computer and user naming convention that helps you locate computers physically by their name alone can dramatically lower your incident response time. If your organization has many offices, an effective naming standard could be to concatenate the office location in which the computer resides with the primary user of the computer. For example, if my username is "jeff" and I work out of the Seattle office, then my computer name would be "sea-jeff". IT staff from across the organization might not know me by name, but when they receive an alert pointing to my computer, they can immediately escalate to local IT staff in the Seattle office or call me directly by looking up my username in Active Directory (AD).
A bonus to using a naming standard such as this is that you can sort reports alphabetically by computer name and group them by office without any effort. Unfortunately, many systems still rely on the 15-character NetBIOS computer name limit, so you still have to be creative in your name truncation.
Getting the Name
Following an IP subnet standard and computer-naming convention helps you quickly pinpoint the location of a suspect computer; however, not every organization is able to implement new conventions. Fortunately, two tools that come loaded on every Windows computer—ping and nbtstat—can resolve the names of suspect computers. The catch is that these tools don't always return accurate information. The key to success is using them together.
The ping command sends a packet to a computer and records a successful reply. It also supports a parameter to request a name lookup. Use the command
ping -a <ipaddress>
to resolve an IP address by using DNS. Ping relies on the DNS configuration of the client computer running the command and has no direct knowledge of the target computer. Therefore, if the client running the ping command is configured with an erroneous hosts file or corrupted DNS cache, or if the DNS server the client references contains old data, ping will return the wrong name. For example, some RAS servers issue client IP addresses from their own pools and don't update the DNS server when IP addresses change. This becomes problematic when one client connects to RAS, registers its name with DNS, and disconnects, then a second client connects and is assigned the same IP address as the previously disconnected client. If the second computer fails to register its name with DNS, ping resolves the IP address to the name of first computer but actually pings the second computer.
Figure 1 shows how a bad DNS entry can fool ping into returning an incorrect name. Ping reports that a computer named badhost is at the address 192.168.0.6, when in actuality the computer with that IP address is named midway. How do we know that? By using our second tool: nbtstat.
To directly ask a target computer its NetBIOS name, use the command
nbtstat -A <ipaddress>
Nbtstat is a command-line tool that displays protocol statistics and current TCP/IP connections by using Net-BIOS over TCP/IP. The -A parameter lists the target computer's name table, given its IP address. Unlike ping, nbtstat directly queries the target computer and works only if the target computer is turned on and responding to NetBIOS queries. Using nbtstat successfully also requires that the target computer support NetBIOS, which isn't a problem with Windows computers but might be with other OSs. Regardless, in a predominantly Windows environment where NetBIOS is enabled by default, nbtstat will give you the correct name of any computer very quickly. If you've configured a host-based firewall to block NetBIOS traffic, then you need to create a rule to permit NetBIOS traffic from the client performing the name lookups, which would probably be a computer that your administrators use.
Put It All Together
Using ping and nbtstat together will tell you which IP address is associated with a computer name. When you combine the use of these tools with naming conventions and subnet standards, you'll quickly be able to identify and pinpoint the location of security breaches within your network.