Attacker Identification

When analyzing most attacks, identifying the attacker is not an immediate primary concern—ensuring that the attack is stopped and recovering systems and data is the focus. If an attack is ongoing, such as an extended denial of service attack, organizations may want to identify the IP address used by the attacker so that the attack can be stopped. Unfortunately, this is often not as simple as it sounds. The following items explain potential issues involving the IP addresses apparently used to conduct an attack:

+ Spoofed IP Addresses. Many attacks use spoofed IP addresses. Spoofing is far more difficult to perform successfully for attacks that require connections to be established, so it is most

commonly used in cases where connections are not needed.⁹¹ When packets are spoofed, usually the attacker has no interest in seeing the response. This is not always true—attackers could spoof an address from a subnet that they monitor, so that when the response goes to that system, they can sniff it from the network. Sometimes spoofing occurs by accident, such as an attacker

misconfiguring a tool and accidentally using internal NAT addresses. Sometimes an attacker spoofs a particular address on purpose—for example, the spoofed address may be the actual intended target of the attack, and the organization seeing the activity is simply a middleman.

+ Many Source IP Addresses. Some attacks appear to use hundreds or thousands of different source IP addresses. Sometimes this is accurate—for example, distributed denial of service attacks typically rely on large numbers of compromised machines performing a coordinated attack. Sometimes this is bogus—an attack may not require the use of real source IP addresses, so the attacker generates many different fake IP addresses to add confusion. Sometimes attackers will use one real IP address and many fake ones; in that case, it may be possible to identify the real IP address by looking for other network activity occurring before or after the attack that uses any of the same IP addresses. Finding a match does not confirm that it was the attacker’s address; the attacker could have inadvertently or purposely spoofed a legitimate IP address that happened to be interacting with the organization.

+ Validity of the IP Address. Because IP addresses are often assigned dynamically, the system currently at a particular IP address may not be the same system that was there when the attack occurred. Also, many IP addresses do not belong to end-user systems, but instead to network infrastructure components that substitute their IP address for the actual source address, such as a firewall performing NAT. Some attackers use anonymizers, which are intermediate servers that perform activity on a user’s behalf to preserve the user’s privacy.

The following describes several possible ways of attempting to validate the identity of a suspicious host:

+ Contact the IP Address Owner. The Regional Internet Registries, such as the American Registry for Internet Numbers (ARIN),⁹² provide WHOIS query mechanisms on their Web sites for identifying the organization or person that owns—is responsible for—a particular IP address.

This information may be helpful in analyzing some attacks, such as seeing that three different IP addresses generating suspicious activity are all registered to the same owner. However, in most cases, analysts should not contact the owner directly; instead, the analyst should provide information on the owner to the management and legal advisors for the analyst’s organization, who can initiate contact with the organization or give the analyst approval to do so if needed.

This is due primarily to concerns involving sharing information with external organizations; also, the owner of an IP address could be the person attacking the organization.

+ Send Network Traffic to the IP Address. Organizations should not send network traffic to an apparent attacking IP address to validate its identity. Any response that is generated cannot conclusively confirm the identity of the attacking host. If the IP address is for the attacker’s system, the attacker may see the traffic and react by destroying evidence or attacking the host sending the traffic. If the IP address is spoofed, sending unsolicited network traffic to the system could be interpreted as unauthorized use or an attack. Under no circumstances should individuals attempt to gain access to others’ systems without permission.

+ Seek ISP Assistance. As mentioned in Section 6.3.1, ISPs generally require a court order before providing any information to an organization on suspicious network activity. Accordingly, ISP assistance is generally only an option during the most serious network-based attacks, particularly those that involve IP address spoofing. ISPs have the ability to trace ongoing attacks back to their source, whether the IP addresses are spoofed or not.

92 ARIN’s web site is at http://www.arin.net/. The other registries are the Asia Pacific Network Information Centre (APNIC), located at http://www.apnic.net/; Latin American and Caribbean IP Address Regional Registry (LACNIC), located at http://lacnic.net/; and Réseaux IP Européens Network Coordination Centre (RIPE NCC), located at http://www.ripe.net/.

+ Research the History of the IP Address. Analysts can look for previous suspicious activity associated with the same IP address or IP address block. The organization’s own network traffic data archives and incident tracking databases may show previous activity. Possible external sources include Internet search engines and online incident databases that allow searches by IP address.⁹³

+ Look for Clues in Application Content. Application data packets related to an attack may contain clues to the attacker’s identity. Besides IP addresses, other valuable information could include an e-mail address or an Internet relay chat (IRC) nickname.

In most cases, organizations do not need to positively identify the IP address used for an attack.

6.5 Recommendations

The key recommendations presented in this section for using data from network traffic are as follows:

+ Organizations should have policies regarding privacy and sensitive information. The use of data analysis tools and techniques might inadvertently disclose sensitive information to analysts and others involved in data analysis activities. Also, long-term storage of sensitive information inadvertently captured by data analysis tools might violate data retention policies. Policies should also address the monitoring of networks, as well as requiring warning banners on systems that indicate activity may be monitored.

+ Organizations should provide adequate storage for network activity-related logs.

Organizations should estimate typical and peak log usage, determine how many hours or days’

worth of data should be retained, and ensure that systems and applications have sufficient storage available. Logs related to computer security incidents might need to be kept for a substantially longer period of time.

+ Organizations should configure data sources to improve the collection of information. Over time, operational experience should be used to improve the capabilities for data analysis.

Organizations should periodically review and adjust the configuration settings of data sources to optimize the capture of relevant information.

+ Analysts should have solid technical knowledge. Because current tools have rather limited analysis abilities, analysts need to be well-trained, experienced, and knowledgeable in networking principles, common network and application protocols, network and application security

products, and network-based threats and attack methods.

+ Analysts should consider the fidelity and value of each data source. Analysts should have more confidence in original data sources than data sources that receive normalized data from other sources. Analysts should validate any unusual or unexpected data that is based on analyzing or interpreting data, such as IDS and SEM alerts.

+ Analysts should generally focus on the characteristics and impact of the event. Determining the identity of an attacker and other similar actions are typically time-intensive and difficult to accomplish, and do not aid the organization in correcting operational issues or security

weaknesses. Establishing the identity and intent of an attacker may be important, but it should be weighed against other important goals.

93 One publicly available incident database is DShield, located at http://www.dshield.org/.