OS Fingerprinting

The ability to identify an operating system based on the network traffic that it sends is known as operating system fingerprinting, and it can provide useful information when performing reconnaissance. This is typically done using TCP/IP stack fingerprinting techniques that focus on comparing responses to TCP and UDP packets sent to remote hosts. Differences in how operating systems and even operating system versions respond, what TCP options they support, what order they send packets in, and a host of other details can provide a good guess at what OS the remote system is running.

Service and Version Identification

The ability to identify a service can provide useful information about potential vulnerabilities, as well as verify that the service that is responding on a given port matches the service that typically uses that port. Service identification is usually done in one of two ways: either by connecting and grabbing the banner or connection information provided by the service or by comparing its responses to the signatures of known services.

Figure 3.3 shows the same system scanned in Figure 3.1 with the nmap -sV flag used. The -sV flag grabs banners and performs other service version validation steps to capture additional information, which it checks against a database of services.

The basic nmap output remains the same as Figure 3.1, but we have added information in the Version column, including the service name as well as the version and sometimes additional detail about the service protocol version or other details. This information can be used to check for patch levels or vulnerabilities and can also help to identify services that are running on nonstandard ports.

Common Tools

Nmap is the most commonly used command-line port scanner, and it is a free, open source tool. It provides a broad range of capabilities, including multiple scan modes intended to bypass firewalls and other network protection devices. In addition, it provides support for operating system fingerprinting, service identification, and many other capabilities.

Using nmap's basic functionality is quite simple. Port scanning a system merely requires that nmap be installed and that you provide the target system's hostname or IP address. Figure 3.4 shows an nmap scan of a Windows 10 system with its firewall turned off. The nmap scan provides quite a bit of information about the system—first, we see a series of common Microsoft ports, including 135, 139, and 445, running Microsoft Remote Procedure Call (MSRPC), NetBIOS, and Microsoft's domain services, which are useful indicators that a remote system is a Windows host. The additional ports that are shown also reinforce that assessment, since ICSLAP (the local port opened by Internet Connection Sharing) is used for Microsoft internal proxying, Web Services on Devices API (WSDAPI) is a Microsoft devices API, and each of the other ports can be similarly easily identified by using a quick search for the port and service name nmap provides. This means that you can often correctly guess details about a system even without an OS identification scan.

A more typical nmap scan is likely to include a number of nmap's command-line flags:

• A scan technique, like TCP SYN, which is the most popular scan method because it uses a TCP SYN packet to verify a service response, and is quick and unobtrusive. Other connection methods are Connect, which completes a full connection; UDP scans for non-TCP services; ACK scans, which are used to map firewall rules; and a variety of other methods for specific uses.
• A port range, either specifying ports or including the full 1–65535 range. Scanning the full range of ports can be very slow, but it can be useful to identify hidden or unexpected services. Fortunately, nmap's default ports are likely to help find and identify most systems.
• Service version detection using the –sV flag, which as shown earlier can provide additional detail but may not be necessary if you intend to use a vulnerability scanner to follow up on your scans.
• OS detection using the –O flag, which can help provide additional information about systems on your network.

Nmap also has an official graphical user interface, Zenmap, which provides additional visualization capabilities, including a topology view mode that provides information about how hosts fit into a network.

Angry IP Scanner is a multiplatform (Windows, Linux, and macOS) port scanner with a graphical user interface. In Figure 3.5, you can see a sample scan run with Angry IP Scanner with the details for a single scanned host displayed. Unlike nmap, Angry IP Scanner does not provide detailed identification for services and operating systems, but you can turn on different modules called “fetchers,” including ports, TTL, filtered ports, and others. When running Angry IP Scanner, it is important to configure the ports scanned under the Preferences menu; otherwise, no port information will be returned! Unfortunately, Angry IP Scanner requires Java, which means that it may not run on systems where Java is not installed for security reasons.

Angry IP Scanner is not as feature rich as nmap, but the same basic techniques can be used to gather information about hosts based on the port scan results. Figure 3.5 shows the information from a scan of a home router. Note that unlike nmap, Angry IP Scanner does not provide service names or service identification information.

In addition to these two popular scanners, security tools often build in a port scanning capability to support their primary functionality. Metasploit, the Qualys vulnerability management platform, OpenVAS, and Tenable's Nessus vulnerability scanner are all examples of security tools that have built-in port scanning capabilities as part of their suite of tools.

Network Devices

Network devices log their own activities, status, and events including traffic patterns and usage. Network device information includes network device logs, network device configuration files, and network flows.

Network Device Logs

By default, many network devices log messages to their console ports, which means that only a user logged in at the console will see them. Fortunately, most managed networks also send network logs to a central log server using the syslog utility. Many networks also leverage the Simple Network Management Protocol (SNMP) to send device information to a central control system.

Network device log files often have a log level associated with them. Although log level definitions vary, many are similar to Cisco's log levels, which are shown in Table 3.1.

Level	Level name	Example
0	Emergencies	Device shutdown due to failure
1	Alerts	Temperature limit exceeded
2	Critical	Software failure
3	Errors	Interface down message
4	Warning	Configuration change
5	Notifications	Line protocol up/down
6	Information	ACL violation
7	Debugging	Debugging messages

Network device logs are often not as useful as the device configuration data when you are focused on intelligence gathering, although they can provide some assistance with topology discovery based on the devices they communicate with. During penetration tests or when you are conducting security operations, network device logs can provide useful warning of attacks or reveal configuration or system issues.

The Cisco router log shown in Figure 3.6 is accessed using the command show logging and can be filtered using an IP address, a list number, or a number of other variables. Here, we see a series of entries with a single packet denied from a remote host 10.0.2.50. The remote host is attempting to connect to its target system on a steadily increasing TCP port, likely indicating a port scan is in progress and being blocked by a rule in access list 210.

Network Device Configuration

Configuration files from network devices can be invaluable when mapping network topology. Configuration files often include details of the network, routes, systems that the devices interact with, and other network details. In addition, they can provide details about syslog and SNMP servers, administrative and user account information, and other configuration items useful as part of information gathering.

Figure 3.7 shows a portion of the SNMP configuration from a typical Cisco router. Reading the entire file shows routing information, interface information, and details that will help you place the router in a network topology. The section shown provides in-depth detail of the SNMP community strings, the contact for the device, as well as what traps are enabled and where they are sent. In addition, you can see that the organization uses Terminal Access Controller Access Control System (TACACS) to control their servers and what the IP addresses of those servers are. As a security analyst, this is useful information—for an attacker, this could be the start of an effective social engineering attack!

DHCP Logs and DHCP Server Configuration Files

The Dynamic Host Configuration Protocol (DHCP) is a client/server protocol that provides an IP address as well as information such as the default gateway and subnet mask for the network segment that the host will reside on. When you are conducting passive reconnaissance, DHCP logs from the DHCP server for a network can provide a quick way to identify many of the hosts on the network. If you combine DHCP logs with other logs, such as firewall logs, you can determine which hosts are provided with dynamic IP addresses and which hosts are using static IP addresses. As you can see in Figure 3.12, a Linux dhcpd.conf file provides information about hosts and the network they are accessing.

In this example, the DHCP server provides IP addresses between 192.168.1.20 and 192.168.1.240; the router for the network is 192.168.1.1, and the DNS servers are 192.168.1.1 and 192.168.1.2. We also see a single system named “Demo” with a fixed DHCP address. Systems with fixed DHCP addresses are often servers or systems that need to have a known IP address for a specific function and are thus more interesting when gathering information.

DHCP logs for Linux are typically found in /var/log/dhcpd.log or by using the journalctl command to view logs, depending on the distribution you are using. DHCP logs can provide information about systems, their MAC addresses, and their IP addresses, as seen in this sample log entry:

Oct 5 02:28:11 demo dhcpd[3957]: reuse_lease: lease age 80 (secs) under 25%
threshold, reply with unaltered, existing lease
Oct 5 02:28:11 demo dhcpd[3957]: DHCPREQUEST for 10.0.2.40 (10.0.2.32) from
08:00:27:fa:25:8e via enp0s3
Oct 5 02:28:11 demo dhcpd[3957]: DHCPACK on 10.0.2.40 to 08:00:27:fa:25:8e v
ia enp0s3
Oct 5 02:29:17 demo dhcpd[3957]: reuse_lease: lease age 146 (secs) under 25%
threshold, reply with unaltered, existing lease
Oct 5 02:29:17 demo dhcpd[3957]: DHCPREQUEST for 10.0.2.40 from 08:00:27:fa:
25:8e via enp0s3
Oct 5 02:29:17 demo dhcpd[3957]: DHCPACK on 10.0.2.40 to 08:00:27:fa:25:8e v
ia enp0s3
Oct 5 02:29:38 demo dhcpd[3957]: DHCPREQUEST for 10.0.2.40 from 08:00:27:fa:
25:8e via enp0s3
Oct 5 02:29:38 demo dhcpd[3957]: DHCPACK on 10.0.2.40 to 08:00:27:fa:25:8e
(demo) via enp0s3

This log shows a system with IP address 10.0.2.40 renewing its existing lease. The system has a hardware address of 08:00:27:fa:25:8e, and the server runs its DHCP server on the local interface enp0s3.

Firewall Logs and Configuration Files

Router and firewall configurations files and logs often contain information about both successful and blocked connections. This means that analyzing router and firewall access control lists (ACLs) and logs can provide useful information about what traffic is allowed and can help with topological mapping by identifying where systems are based on traffic allowed through or blocked. Configuration files make this even easier, since they can be directly read to understand how systems interact with the firewall.

Firewall logs can also allow penetration testers to reverse-engineer firewall rules based on the contents of the logs. Even without the actual configuration files, log files can provide a good view of how traffic flows. Like many other network devices, firewalls often use log levels to separate informational and debugging messages from more important messages. In addition, they typically have a vendor-specific firewall event log format that provides information based on the vendor's logging standards.

Organizations use a wide variety of firewalls, including those from Cisco, Palo Alto, and Check Point, which means that you may encounter logs in multiple formats. Fortunately, all three have common features. Each provides a date/timestamp and details of the event in a format intended to be understandable. For example, Cisco ASA firewall logs can be accessed from the console using the show logging command (often typed as show log). Entries are reasonably readable, listing the date and time, the system, and the action taken. For example, a log might read

Sep 13 10:05:11 10.0.0.1 %ASA-5-111008: User 'ASAadmin' executed the 'enable' command

This command indicates that the user ASAadmin ran the Cisco enable command, which is typically used to enter privileged mode on the device. If ASAadmin was not supposed to use administrative privileges, this would be an immediate red flag in your investigation.

A review of router/firewall ACLs can also be conducted manually. A portion of a sample Cisco router ACL is shown here:

ip access-list extended inb-lan
 permit tcp 10.0.0.0 0.255.255.255 any eq 22
 permit tcp 172.16.0.0 0.15.255.255 any eq 22
 permit tcp host 192.168.2.1 any eq 22
 deny tcp 8.16.0.0 0.15.255.255 any eq 22

This ACL segment names the access list and then sets a series of permitted actions along with the networks that are allowed to perform the actions. This set of rules specifically allows all addresses in the 10.0.0.0 network to use TCP port 22 to send traffic, thus allowing SSH. The 172.16.0.0 network is allowed the same access, as is a host with IP address 192.168.2.1. The final deny rule will prevent the named network range from sending SSH traffic.

If you encounter firewall or router configuration files, log files, or rules on the exam, it may help to rewrite them into language you can read more easily. To do that, start with the action or command; then find the targets, users, or other things that are affected. Finally, find any modifiers that specify what will occur or what did occur. In the previous router configuration, you could write permit tcp 10.0.0.0 0.255.255.255 any eq 22 as “Allow TCP traffic from the 10.0.0.0 network on any source port to destination port 22.” Even if you're not familiar with the specific configuration or commands, this can help you understand many of the entries you will encounter.

System Log Files

System logs are collected by most systems to provide troubleshooting and other system information. Log information can vary greatly depending on the operating system, how it is configured, and what service and applications the system is running.

Log files can provide information about how systems are configured, what applications are running on them, which user accounts exist on the system, and other details, but they are not typically at the top of the list for reconnaissance. They are gathered if they are accessible, but most log files are kept in a secure location and are not accessible without administrative system access.

DNS and Traceroute Information

DNS converts domain names like google.com to IP addresses (as shown in Figure 3.13) or from IP addresses to human-understandable domain names. The command for this on Windows, Linux, and macOS systems is nslookup.

Once you know the IP address that a system is using, you can look up information about the IP range it resides in. That can provide information about the company or about the hosting services that they use. Nslookup provides a number of additional flags and capabilities, including choosing the DNS server that you use by specifying it as the second parameter, as shown here with a sample query looking up Microsoft.com via Google's public DNS server 8.8.8.8:

nslookup microsoft.com 8.8.8.8

Other types of DNS records can be looked up using the -query flag, including MX, NS, SOA, and ANY as possible entries:

nslookup -query=mx microsoft.com

This results in a response like that shown in Figure 3.14.

The IP address or hostname also can be used to gather information about the network topology for the system or device that has a given IP address. Using traceroute in Linux or macOS (or tracert on Windows systems), you can see the path packets take to the host. Since the Internet is designed to allow traffic to take the best path, you may see several different paths on the way to the system, but you will typically find that the last few responses stay the same. These are often the local routers and other network devices in an organization's network, and knowing how traffic gets to a system can give you insight into the company's internal network topology. Some systems don't respond with hostname data. Traceroute can be helpful, but it often provides only part of the story, as you can see in Figure 3.15, which provides traceroute information to the BBC's website as shown by the asterisks and request timed out entries in Figure 3.15, and that the last two systems return only IP addresses.

This traceroute starts by passing through the author's home router, then follows a path through Comcast's network with stops in the South Bend area, and then Chicago. The 4.68.63.125 address without a hostname resolution can be matched to Level 3 communications using a Whois website. The requests that timed out may be due to blocked ICMP responses or other network issues, but the rest of the path remains clear: another Level 3 communications host, then a BBC IP address, and two addresses that are under the control of RIPE, the European NCC. Here we can see details of upstream network providers and backbone networks and even start to get an idea of what might be some of the BBC's production network IP ranges.

Domains and IP Ranges

Domain names are managed by domain name registrars. Domain registrars are accredited by generic top-level domain (gTLD) registries and/or country code top-level domain (ccTLD) registries. This means that registrars work with the domain name registries to provide registration services: the ability to acquire and use domain names. Registrars provide the interface between customers and the domain registries and handle purchase, billing, and day-to-day domain maintenance, including renewals for domain registrations.

Registrars also handle transfers of domains, either due to a sale or when a domain is transferred to another registrar. This requires authorization by the current domain owner, as well as a release of the domain to the new registrar.

The global IP address space is managed by IANA. In addition, IANA manages the DNS Root Zone, which handles the assignments of both gTLDs and ccTLDs. Regional authority over these resources are handled by five regional Internet registries (RIRs):

• African Network Information Center (AFRINIC) for Africa
• American Registry for Internet Numbers (ARIN) for the United States, Canada, parts of the Caribbean region, and Antarctica
• Asia-Pacific Network Information Centre (APNIC) for Asia, Australia, New Zealand, and other countries in the region
• Latin America and Caribbean Network Information Centre (LACNIC) for Latin America and parts of the Caribbean not covered by ARIN
• Réseaux IP Européens Network Coordination Centre (RIPE NCC) for Central Asia, Europe, the Middle East, and Russia

Each of the RIRs provides Whois services to identify the assigned users of the IP space they are responsible for, as well as other services that help to ensure that the underlying IP and DNS foundations of the Internet function for their region.

DNS Entries

In addition to the information provided using nslookup, DNS entries can provide useful information about systems simply through the hostname. A system named “AD4” is a more likely target for Active Directory–based exploits and Windows Server–specific scans, whereas hostnames that reflect a specific application or service can provide both target information and a clue for social engineering and human intelligence activities.

DNS Discovery

External DNS information for an organization is provided as part of its Whois information, providing a good starting place for DNS-based information gathering. Additional DNS servers may be identified either as part of active scanning or passive information gathering based on network traffic or logs, or even by reviewing an organization's documentation. This can be done using a port scan and searching for systems that provide DNS services on UDP or TCP port 53. Once you have found a DNS server, you can query it using dig or other DNS lookup commands, or you can test it to see if it supports zone transfers, which can make acquiring organizational DNS data easy.

Zone Transfers

One way to gather information about an organization is to perform a zone transfer. Zone transfers are intended to be used to replicate DNS databases between DNS servers, which makes them a powerful information-gathering tool if a target's DNS servers allow a zone transfer. This means that most DNS servers are set to prohibit zone transfers to servers that aren't their trusted DNS peers, but security analysts, penetration testers, and attackers are still likely to check to see if a zone transfer is possible.

To check if your DNS server allows zone transfers from the command line, you can use either host or dig:

host –t axfr domain.name dns-server
dig axfr @dns-server domain.name

Running this against a DNS server that allows zone transfers will result in a large file with data like the following dump from digi.ninja, a site that allows practice zone transfers for security practitioners:

; <<>> DiG 9.9.5-12.1-Debian <<>> axfr @nsztm1.digi.ninja zonetransfer.me
; (1 server found)
;; global options: +cmd
zonetransfer.me.     7200     IN     SOA     nsztm1.digi.ninja.
robin.digi.ninja. 2014101603 172800 900 1209600 3600
zonetransfer.me.     7200     IN     RRSIG     SOA 8 2 7200 20160330133700
20160229123700 44244 zonetransfer.me. GzQojkYAP8zuTOB9UAx66mTDiEGJ26hVIIP2
ifk2DpbQLrEAPg4M77i4 M0yFWHpNfMJIuuJ8nMxQgFVCU3yTOeT/EMbN98FYC8lVYwEZeWHtb
MmS 88jVlF+cOz2WarjCdyV0+UJCTdGtBJriIczC52EXKkw2RCkv3gtdKKVa fBE=
zonetransfer.me.     7200     IN     NS     nsztm1.digi.ninja.
zonetransfer.me.     7200     IN     NS     nsztm2.digi.ninja.
zonetransfer.me.     7200     IN     RRSIG     NS 8 2 7200 20160330133700
20160229123700 44244 zonetransfer.me. TyFngBk2PMWxgJc6RtgCE/RhE0kqeWfwhYS
BxFxezupFLeiDjHeVXo+S WZxP54Xvwfk7jlFClNZ9lRNkL5qHyxRElhlH1JJI1hjvod0fycq
LqCnx XIqkOzUCkm2Mxr8OcGf2jVNDUcLPDO5XjHgOXCK9tRbVVKIpB92f4Qal ulw=
zonetransfer.me.     7200     IN     A     217.147.177.157

This transfer starts with a start of authority (SOA) record, which lists the primary name server; the contact for it, robin.digi.ninja (which should be read as [email protected]); and the current serial number for the domain, 2014101603. It also provides the time secondary name servers should wait between changes: 172,800 seconds, the time a primary name server should wait if it fails to refresh; 900 seconds, the time in seconds that a secondary name server can claim to have authoritative information; 1,209,600 seconds, the expiration of the record (two weeks); and 3,600 seconds, the minimum TTL for the domain. Both of the primary name servers for the domain are also listed—nsztm1 and nsztm2—and MX records and other details are contained in the file. These details, plus the full list of DNS entries for the domain, can be very useful when gathering information about an organization, and they are a major reason that zone transfers are turned off for most DNS servers.

DNS Brute Forcing

If a zone transfer isn't possible, DNS information can still be gathered from public DNS by brute force. Simply sending a manual or scripted DNS query for each IP address that the organization uses can provide a useful list of systems. This can be partially prevented by using an IDS or IPS with a rule that will prevent DNS brute-force attacks. Sending queries at a slow rate or from a number of systems can bypass most prevention methods.

Whois

Whois, as mentioned earlier, allows you to search databases of registered users of domains and IP address blocks, and it can provide useful information about an organization or individual based on their registration information. In the sample Whois query for Google shown in Figure 3.16, you can see that information about Google, such as the company's headquarters location, contact information, and its primary name servers, is returned by the Whois query. This information can provide you with additional hints about the organization by looking for other domains registered with similar information, email addresses to contact, and details you can use during the information-gathering process.

Other information can be gathered by using the host command in Linux. This command will provide information about a system's IPv4 and IPv6 addresses as well as its email servers, as shown in Figure 3.17.

Websites

It might seem obvious to include an organization's website when gathering electronic documents, but simply gathering the current website's information doesn't provide a full view of the data that might be available. The Internet Archive (archive.org) and the Time Travel Service (timetravel.mementoweb.org) both provide a way to search historic versions of websites. You can also directly search Google and other caches using a site like cachedview.com.

Historical and cached information can provide valuable data, including details that the organization believes are no longer accessible. Finding every instance of a cached copy and ensuring that they are removed can be quite challenging!

Social Media Analysis

Gathering information about an organization often includes gathering information about the organization's employees. Social media can provide a lot of information, from professional details about what employees do and what technologies and projects they work on to personal data that can be used for social engineering or password guessing. A social media and Internet presence profiling exercise may look at what social networks and profiles an individual has, who they are connected to, how much metadata their profiles contain, and what their tone and posting behaviors are.

In addition to their use as part of organizational information gathering, social media sites are often used as part of a social engineering attack. Knowing an individual's interests or details of their life can provide a much more effective way to ensure that they are caught by a social engineering attack.

Social Engineering

Social engineering, or exploiting the human element of security, targets individuals to gather information. This may be via phone, email, social media, or in person. Typically, social engineering targets specific access or accounts, but it may be more general in nature.

A number of toolkits are available to help with social engineering activities:

• The Social Engineering Toolkit (SET), which provides technical tools to enable social engineering attacks
• Creepy, a geolocation tool that uses social media and file metadata about individuals to provide better information about them
• Metasploit, which includes phishing and other tools to help with social engineering

Phishing, which targets account information or other sensitive information by pretending to be a reputable entity or organization via email or other channels, is commonly used as part of a social engineering process. Targeting an organization with a well-designed phishing attack is one of the most common ways to get credentials for an organization.

Data Sources

Typical data sources for analysis include the following:

• Network traffic analysis using intrusion detection systems (IDSs), intrusion prevention systems (IPSs), host intrusion detection systems (HIDSs), network intrusion detection systems (NIDSs), firewalls, or other network security devices. These devices often provide one or more of the following types of analysis capabilities:
  • Packet analysis, with inspection occurring at the individual packet level to detect issues with the content of the packets, behaviors related to the content of the packet, or signatures of attacks contained in them.
  • Protocol analysis, which examines traffic to ensure that protocol-level attacks and exploits are not being conducted.
  • Traffic and flow analysis intended to monitor behavior based on historic traffic patterns and behavior-based models.

• Device and system logs that can help identify reconnaissance and attacks when analyzed manually or using a tool.
• Port and vulnerability scans conducted internally to identify potential issues. These can help match known vulnerabilities to attempted exploits, alerting administrators to attacks that are likely to have succeeded.
• Security device logs that are designed to identify problems and that often have specific detection and/or response capabilities that can help limit the impact of reconnaissance.
• Security information and event management (SIEM) systems that centralize and analyze data, allowing reporting, notification, and response to security events based on correlation and analysis capabilities.

Data Analysis Methods

Collecting data isn't useful unless you can correlate and analyze it. Understanding the techniques available to analyze data can help you decide how to handle data and what tools you want to apply.

• Anomaly analysis looks for differences from established patterns or expected behaviors. Anomaly detection requires knowledge of what “normal” is to identify differences to build a base model. IDSs and IPSs often use anomaly detection as part of their detection methods.
• Trend analysis focuses on predicting behaviors based on existing data. Trend analysis can help to identify future outcomes such as network congestion based on usage patterns and observed growth. It is not used as frequently as a security analysis method but can be useful to help guarantee availability of services by ensuring that they are capable of handling an organization's growth or increasing needs.
• Signature analysis uses a fingerprint or signature to detect threats or other events. This means that a signature has to exist before it can be detected, but if the signature is well designed, it can reliably detect the specific threat or event.
• Heuristic, or behavioral analysis, is used to detect threats based on their behavior. Unlike signature detection, heuristic detection can detect unknown threats since it focuses on what the threat does rather than attempting to match it to a known fingerprint.
• Manual analysis is also frequently performed. Human expertise and instinct can be useful when analyzing data and may detect something that would otherwise not be seen.

Your choice of analysis methods will be shaped by the tools you have available and the threats your organization faces. In many cases, you may deploy multiple detection and analysis methods in differing locations throughout your network and systems. Defense-in-depth remains a key concept when building a comprehensive security infrastructure.

Preventing Active Reconnaissance

Active reconnaissance can be limited by employing network defenses, but it cannot be completely stopped if you provide any services to the outside world. Active reconnaissance prevention typically relies on a few common defenses:

• Limiting external exposure of services and ensuring that you know your external footprint
• Using an IPS or similar defensive technology that can limit or stop probes to prevent scanning
• Using monitoring and alerting systems to notify you about events that continue despite these preventive measures

Detecting active reconnaissance on your internal network should be a priority, and policy related to the use of scanning tools should be a priority to ensure that attackers cannot probe your internal systems without being detected.

Preventing Passive Information Gathering

Preventing passive information gathering relies on controlling the information that you release. Reviewing passive information gathering techniques, then making sure that your organization has intentionally decided what information should be available, is critical to ensuring that passive information gathering is not a significant risk.

Each passive information gathering technique has its own set of controls that can be applied. For example, DNS antiharvesting techniques used by domain registrars can help prevent misuse. These include the following:

• Blacklisting systems or networks that abuse the service
• Using CAPTCHAs to prevent bots
• Providing privacy services that use third-party registration information instead of the actual person or organization registering the domain
• Implementing rate limiting to ensure that lookups are not done at high speeds
• Not publishing zone files if possible, but gTLDs are required to publish their zone files, meaning this works for only some ccTLDs

Other types of passive information gathering each require a thorough review of exposed data and organization decisions about what should (or must) be exposed and what can be limited either by technical or administrative means.