Next Steps

Next Steps

Finding the source address of one or more attacking hosts might require considerable effort. Remember, too, that the majority of people who engage in unauthorized network activities exercise great care in covering their tracks. Assuming that you have discovered one or more source addresses, however, what are some logical next steps? This portion of the chapter explains possible subsequent courses of action.

Sending Email to abuse@

One course of action is to send email to abuse@<domainname> or possibly root@<domainname> . For example, if you discover that a particular IP address is within the aol.com domain, you can try to send mail to [e-mail] . Your message is likely to be received by someone who administers security in the domain in which the apparent offending host resides. You will, in most cases, receive some kind of autoreply (see Figure 6.3). The reply you get, however, is not nearly as important as the fact that you have now helped someone investigate whether the apparent offending host has been compromised or misused.

Figure 6.3. A sample autoreply message.

Sending email to an "abuse address" is, unfortunately , a less-than -perfect strategy. First, the source address you obtained might simply not be the correct one. Second, you might not be able to get any information back, or if you do, it might be the kind of information shown in Figure 6.3 instead of more meaningful information. Finally, the attackers might have control of the abuse@ or root@ accounts. At a minimum, you might now have tipped them off that you have discovered their activities. They might now attempt to remove all traces of their presence on your systems before you can start forensics procedures. They also might now attempt to have a little bit of fun with you (as unethical as this might be) by doing something such as sending you bogus information that sends you on a wild goose chase.

All things considered , the benefits of sending email to abuse@ or root@ often out-weigh the disadvantages. Many if not most attacks simply go unnoticed, giving a huge advantage to those who perpetrate them. Attempting to send email to those who are responsible for security in systems from which attacks have apparently originated at least allows a chance for those who need to intervene to do so.

Tracking Down a Suspected Source IP Address

At some point in the process of responding to an incident or set of incidents, the true identity of the attacking host(s) might become evident. This often is because multiple attempts to pinpoint the source address keep resulting in the discovery of a single address or possibly a small group of addresses. A number of commands can now be of great value. These include dig/nslookup , whois , ping , traceroute , and possibly others.

dig/nslookup

A sound next step is to reverse map the identified source IP address into a domain name . The "dig -x ip" *NIX command accomplishes this goal by doing a reverse lookup on an IP address of interest using its domain name server. Entering the -x flag with the dig command is a wise move because it guarantees that all DNS table records (for example, which name servers and email servers are used, the host-resolved name, and so forth) regarding the host of interest will be sent.

Another good strategy is to enter the nslookup command for all the addresses in the network to which the offender's machine is connected. The nslookup command maps the relationship between a hostname and IP address. Simply enter the following:

 nslookup <hostname or IP address> 

If the offender appears to have originated an attack from 12.34.56.78, you can do an nslookup for 12.34.56.1 through 12.34.56.254. You can often find information that an nslookup on a single address might not yield. Note that this strategy is feasible with a class C network (which has 254 addresses) but not with class A or class B networks (which have a larger address space).

whois

Using the whois command to find out to whom the offending IP is registered is another good next step. This involves using the resolved name to attempt to identify the country of the particular IP address in question. Different whois gateways are available for this purpose. The main gateway in the United States is ARIN (for "American Registry") at whois.arin.net . RIPE ( whois.ripe.net ) is the main European gateway, and APNIC ( whois.apnic.net ) is the primary Asian Pacific gateway. Enter telnet whois.arin.net (or another address as previously shown) to connect to the appropriate gateway. Then enter whois . After the special prompt appears enter one of the following:

‚ »host attacker.corp.com (to attempt to find the name and phone number of the system administrator as well as the IP address of the connecting machine)

or

‚ »net 128.115 (to attempt to find the name and phone number of the network coordinator )

or

‚ »finger@<address> (to attempt to find out who is logged in to the suspected source machine)

Attempts to use whois might or might not work. Sometimes the whois data does not correspond to the resolved name. Furthermore, whois databases tend to be updated too slowly, resulting in out-of-date information. If initial whois attempts with the gateways introduced earlier fail, another possible course of action is to reach country-specific whois databases to attempt to identify the registered owner. You can find these country-specific databases at www.allwhois.com.

ping

The ping command can sometimes be useful in that it can tell you whether a host you suspect has been used to launch an attack is alive and on the network. Enter the following:

 ping <address> 

One drawback of using ping , however, is that because it uses the ICMP protocol, it might not reach the target address. Firewalls and screening routers often (wisely) filter out all incoming ICMP traffic, so if a ping attempt fails, the meaning of the outcome might be unclear. The host you suspect of launching an attack might not be alive and on the network, or a firewall or screening router might have blocked your ping attempt.Yet another limitation is that even if you successfully ping the suspected host, this does not show that the host attacked you.

traceroute

You can also enter the following:

 traceroute <address> 

The traceroute command (or its equivalent in Windows systems, tracert ) shows intermediate hops between the host on which this command is entered and a target host. If you enter traceroute soon after you find suspicious activity from a particular host, you are likely to discover the route through which traffic between your host and the suspected host traveled at the time the activity occurred. ^[7] This is potentially very helpful because if the IP address you obtain for the suspected host does not resolve, you can possibly get some clues about that host. You might, for example, be able to determine the ISP for the suspected host. Similarly, you might be able to determine the particular part of the world from which the activity originated by examining the path over which the packets traveled.

^[7] Note that because IP finds its own best route, routing might change from time to time. This will affect the output of the traceroute command.

Should You Scan a Host that May Have Attacked You?

A number of net postings and conference papers advocate scanning a host that has apparently attacked one of your hosts. Scanning can enable you to determine which ports are open. It can also help you determine whether a host is being used as a relay host. Relay hosts typically run services such as Internet relay chat (IRC), Remote Procedure Calls (RPC), and Virtual Network Controller (VNC). With tools such as NMAP and Nessus in the public domain, virtually anyone who wants to can engage in such activity.

There also is a danger, however. What if the host you are scanning has not been involved in an attack? How will the system administrator respond? Might the system administrator retaliate? Furthermore, conducting such scans without explicit management approval is against many organizations' policies. Finally, there is an important ethical question: Is it acceptable to do what attackers do when you have been attacked? The resolution of this issue thus depends on many issues. In general, we, the authors of this book, would like to discourage anyone from scanning other machines in response to an attack, primarily for ethical reasons. Being attacked does not constitute license for attacking others.

You can also use the traceroute command in another way. If you can successfully run the traceroute command shortly after a host is attacked, you can count the number of hops over which packets travel. If you have also captured packets on the network segment to which the victim host is connected, you can now count the TTL (time to live) value ^[8] of the packet (see Figure 6.4 to find out more about the TTL field within an IP header). If you see that an IP packet header has a TTL value of, say, 99, but a traceroute indicates that the suspected IP address is only three hops away over the network, something is wrong. TTL values are typically either 64 or 128.You might accordingly conclude that the source address has been spoofed.

^[8] TTL values are important because a packet with a TTL value of 0 will be dropped by the device that receives it.

Figure 6.4. A hypothetical attack path.

The limitations of traceroute are the same as with ping . traceroute is based on the ICMP protocol and thus might be blocked by one or more firewalls or screening routers. Additionally, a successful execution of the traceroute command does not prove that the target host attacked you.