Tracing Methods

‚  < ‚  Free Open Study ‚  > ‚  

Tracing Methods

Several tracing methods can be used to attempt to pinpoint (or at least guess) the source of an attack. This section describes some of the most useful of these methods.

Search Engines

The first tracing method covered here, using search engines, is a bit "shaky" from a technical perspective. It is nevertheless potentially very useful. The basic notion is that people who do bad things to computing systems and networks often have big mouths. You might remember the old military slogan ,"Loose lips sink ships." The same applies to security- related attacks that occur. Perpetrators often brag about their exploits. In so doing, they often reveal information both about the source of any attacks they have launched and even about their identity.

If one or more of your organization's web pages has been defaced or some other type of web-related breach has occurred, good places to initially check include alldas.org and www.antionline.org. Both of these sites report alleged web defacements. Although perpetrators do not reveal their identities when they report web-related breaches of web-site security, visiting these sites can help incident handlers obtain additional information about an incident, enabling them to be able to conduct a more extensive subsequent search for the source IP address. A posting on either of these two sites can, for example, enable you to determine the possible attack technique as well as other information such as the time and date that the attack occurred.

The next level of using a search engine is performing a search on a particular word. Suppose the victim machine is in a particular domain, such as domain.com. You can use a search engine such as Google (www.google.com) to determine whether there are any postings related to attacks on domain.com. Additionally, entering +link:domain name shows every web page with a cross-link to the victim domain listed on every web page that contains information about the attack(s) that occurred.

Searching not only for the domain but also the specific hostname and IP address of the victim(s) can be useful. If you search for an IP address, be sure to put quotes around the address.You can also include Boolean operators such as "and denial of service." If the perpetrator uses a handle (such as Darkest Doom Godzilla), as so many crackers do, and you discover this handle, you can also search by entering the handle. Again, using a Boolean operator such as "<domain name> and <cracker handle>" can produce extremely useful results. Also try typing the search term +host:domain <source domain> and hack* . to determine the web links of potential perpetrators who have launched attacks from the domain name you have specified.You can substitute words such as "warez" or "mp3" to find information relevant to warez or mp3 dealers. If you click on "View original posting," you might be able to discover the identity of the original server on which each message was posted. Use sites such as www.anonymizer.com or www.the- cloak .com if it is important to remain anonymous while you are doing web searches. [3]

[3] These sites shield your IP address from other sites to which you connect.At the same time, however, it is important to realize that any privacy site you use will have your IP address; you thus must trust the privacy site to not misuse this address or other information about you.

You can often use the aforementioned methods at a minimum to learn of other compromised hosts /IP addresses, enabling you to possibly contact the system administrator of these systems. The system administrator might be able to provide data (such as an apparent source address) that you might otherwise be unable to obtain directly. Additionally, although perpetrators typically spoof source addresses when they make public postings, they occasionally get careless. You might, therefore, be able to find a possible source address by examining postings by suspected perpetrators.

The reason we have labeled using search engines as "shaky" is that no guarantee of the integrity or source of network postings exist. A malicious user could even implicate a completely innocent user or an arbitrary host in a posting. Using a search engine nevertheless can sometimes be very useful, especially if the search engine is used in connection with other methods described next.

The netstat Command

You can obtain apparent source addresses by entering netstat ‚ (flag or switch) from the command line of many types of operating systems. In Windows 9X, Windows NT, Windows 2000, and most UNIX systems, for example, you can enter the following:

 netstat a n 

The ‚ a switch displays all connections and listening ports. The ‚ n switch displays addresses and port numbers in numerical format. Table 6.1 displays the type of output that results from running the netstat command on a Windows 9X system.

Table 6.1. Output of the netstat Command in Windows Systems

Active

Connections

‚  

Proto

Local Address

Foreign Address

State

TCP

198.128.4.231:2178

128.3.41.19:143

ESTABLISHED

TCP

198.128.4.231:2180

128.3.41.19:143

ESTABLISHED

UDP

198.128.4.231:137

*:*

‚  

UDP

198.128.4.231:138

*:*

‚  

One of the limitations of the netstat command is that it produces data only for the time during which this command is run. In other words, netstat records current connections and nothing more. If you enter the netstat command once every day, you will miss possible connections at all other times. One possible remedy is to set up a scheduled job using cron in UNIX and Linux systems or the Scheduler in Windows NT and Windows 2000 systems. You can schedule this command to run every few minutes (or perhaps every hour ), dumping the output into a file using the following format:

 netstat >> textfile 

Log Data

Log data from systems can provide informative data concerning potential source addresses. Log data includes system audit data, firewall log data, and data from monitoring and/or intrusion-detection tools. System audit data can, for example, reveal information such as the following:

  • The start and end time of access

  • The port number used to access system

  • The name of the task executed or command entered

  • Attempts to change permissions

  • Files accessed

  • The baud rate of the connection

Next you'll look at logging in some of the major operating systems used today.

UNIX and Linux Logging

Table 6.2 lists commands that can be used to display log data in the UNIX and Linux operating systems and the information that each provides. Please note that the lastcom and sa commands are available only in certain flavors of UNIX and Linux (these commands originated in Berkeley Standard Distribution [BSD] UNIX).

Table 6.2. UNIX and Linux Commands to Display Log Data

Command

Data Displayed

who

Usernames, ports used, login times

last

Last logins by users, terminals

ps

Current processes

acctcom

Commands executed, start/end, CPU usage

lastcomm

Commands executed (displayed in reverse order)

sa

Login accounting information

Commands such as who (which shows each login ID's login and logout times), last (which displays the time of each login ID's last login) and pacct (process accounting, which displays commands entered and the time of each command entry) generally provide a ttyname (terminal name) or source IP address for each entry. Remember, however, that the apparent source might not be the actual source.

Most perpetrators utilize methods that remove the intruder's activity from UNIX and Linux logs. Furthermore, UDP and X-Windows-based activity often does not show up in these logs. Running a wrapper tool that logs incoming service requests and taking measures that record all activity such as NFS-related activity (for example, using NFS Watch) is thus extremely useful if you want to obtain information about the source of an attack.

Windows NT and Windows 2000 Logging

In Windows NT and Windows 2000 systems, entering eventvwr in the Run menu (or going to Start, Programs, Administrative Tools, Event Viewer) brings up a display of one of the event logs (System Log, Security Log, or Application Log). Going to the Log menu bar and pulling down to the selection that corresponds to the particular log you want to view enables you to access any of these three logs. Of the three types of logs, only the Security Log contains security-related data such as the account name and time of failed logons , changes in accounts and groups, access to files and directories, and so forth. The data available depend on how the Security Log is configured.

Unfortunately, however, the Security Log in Windows NT and Windows 2000 does not contain the source of recorded events; the event logger does not record the source IP address. One solution is obtaining and installing a packet filter such as the Nuke Nabber tool (www.dynamsol.com) that records attempted connections on specified ports. Another is buying a third-party tool that yields more complete audit data.

NetWare Logging

NetWare auditing is done by the AUDITCON.EXE utility located in the SYS:PUBLIC directory of each file server. The administrator can configure auditing, but anyone (regardless of assigned privilege level) can access the audit logs and control various auditing functions by entering the appropriate password. Events related to the NetWare directory services (NDS) and file system events are audited independently of each other.

To read audit reports for directory services, select Audit directory services from the AUDITCON main menu. The Audit directory services menu is displayed. Select Change session context in the Audit directory services menu to go directly to a container. Otherwise, you can select Audit directory tree to go through the NDS tree structure to locate a container of interest. The currently selected container is shown at the top. Choose the container you want from the Audit directory tree screen and then press F10. The Available audit options menu is displayed. Select Auditor container login, type in the password, and then press Enter. The Available audit options menu will now be displayed. Finally, select Auditing reports .The particular audit data displayed will depend on how you have configured directory services auditing.

To view NetWare audit reports for volume auditing, enter AUDITCON and then select Change current server to choose the appropriate service. From the AUDITCON main menu, select Change current volume to specify the volume of interest. Next, select Auditor volume login from the AUDITCON main menu. The Enter volume password input box will be displayed. Type in the auditing password for the volume you have chosen , press Enter, and then select Auditing reports, a selection within the Available audit options menu that will be displayed.As in the case of directory services auditing, the particular audit data displayed will depend on the configuration of volume auditing.

VMS Logging

VMS commands to access log data are shown in Table 6.3. VMS not only allows incident handlers to quickly discover the apparent source addresses of attacks, it also yields other extremely useful information such as logon times and privilege level.

Table 6.3. VMS Commands to Display Audit Data

Command

Information Displayed

SHOW USERS

Names of users who are currently logged in

SHOW SYSTEM

Current processes and process IDs (PIDs)

SHOW PROCESS

A specific process (of your choice)

SHOW

Current users' logon times, privilege level, and so on

ANALYZE /AUDIT/EVENT=name

Failed logins, modification of system authorization function, and so on

ACCOUNTING/FULL

All activity on system

Data from firewalls are often the most useful when incident handlers are trying to determine the source of an attack. This topic will be explored next.

Firewall Logs

Most commercial firewall products include logging capabilities that capture information such as the type of service requested , the source and destination IP address, and so on. Some firewall logging capabilities are much better than others, however. Some simply capture a greater amount of information; some display data in a more human-usable format.

When all is said and done, firewall logs generally provide the best source of information about apparent source IP addresses of attacks. Although firewalls, like hosts that reside in internal networks, are vulnerable to attacks, they are usually more difficult to tamper with than other hosts. In their " bastion host" role, they need to be more secure. As such, the information they capture is likely to be complete and unaltered, at least as compared to information gleaned from individual systems. Additionally, external firewalls gather data from a central point ‚ the external gateway. Investigators can conveniently access the firewall to obtain information about source addresses and other parameters related to a variety of attacks that might have occurred within their internal network.

Unfortunately, we live in an imperfect world. Firewall logs can be altered or deleted by attackers. (For this reason, running a Tripwire tool that checks the integrity of firewall logs [as well as system logs] is a good thing to do.) Attackers can also flood firewalls with so much traffic that examining logs can become unmanageable. Finally, attackers can launch DoS attacks on firewalls, causing them to crash or at least slow down so much that they become functionally "brain dead."

Intrusion Detection System Alarms and Data

Intrusion detection systems (IDSs) also produce alarms and data that contain apparent IP addresses. This book does not cover IDSs, however. More information on this subject is available in books such as Stephen Northcutt's Network Intrusion Detection: An Analyst's Handbook . [4]

[4] Northcutt, Stephen. Network Intrusion Detection:An Analyst's Handbook . Indianapolis: New Riders, 1999.

Raw Packet Data

Another method that can be used to determine the source of an attack is implementing a tool such as TCP Dump or Snort that records the apparent source IP address. Typically, this means putting some kind of device that captures packets as part of a configuration designed to gather raw packet data. Raw packet dumps contain, among other things, the source IP address.

Examining Raw Packet Dumps

The IP header in packets contains information that is potentially useful in tracing the origin of an attack. [5] Table 6.4 below shows a data dump from an IP header.

[5] For additional information, see RFC-791 at www.ietf.org.

Table 6.4. A Data Dump from an IP Header

0x0000

45c0

005c

c562

0000

1d06

4f81

8003

09f0

0x0010

d2dd

054a

0203

4b44

0000

0000

4500

002c

0x0020

79a4

0000

1c06

4a88

5804

004a

d09b

d9bf

0x0030

7443

0011

6a55

c3d1

0000

0000

6002

00a4

0x0040

44c3

0000

0106

005a

3220

6907

0000

0000

0x0050

0000

0000

0000

0000

0000

0000

‚  

The hexadecimal values in this header dump have been converted from binary values by a packet analysis tool. You can convert each value to decimal by multiplying the right-most number by 16**0 (or 1), then multiplying the next number to the left by 16**1 (or 16), then multiplying the next number to the left by 16**2 (or 256), and so on.

The first column of numbers (starting with 0x0000 at the top left side) corresponds to the row. Table 6.5 shows the format.

Table 6.5. Fields and Field Lengths in the IP Packet Header

Field [6]

Length (Bits)

Version

4

Header length

4

Type of service

8

Total length

16

Identification

16

Flags

3

Fragment offset

13

TTL (time to live)

8

Protocol

8

Header checksum

16

Source address

32

Destination address

32

Options

24

Padding

8

[6] Starting at bit position (offset) zero.

In Table 6.4, you'll see that the values in the first line start with 45c0. The 4 means that the version is 4; in other words, this is an IPv4 packet. The header length is 5. The type of service is c0 or 192. Skipping ahead a little bit, note also that the value 8003 09f0 appears at the end of the first line. In this example, this is the source IP address. 0x80 is decimal 128, 0x03 is decimal 3, 0x09 is decimal 9, and 0xf0 is decimal 240, so the source IP address is 128.3.9.240.

How to Capture Packet Data

Myth, not fact, predominates when it comes to methods of capturing packet data. Legend has it, for example, that it is impossible to capture packets in a switched network environment, but this is simply not true. It is true, however, that it is more difficult to capture packets in a switched environment, but this is because of fundamental differences between hubs and switches. Hubs do not support connections, and as such, they echo every packet to every port on the hub except for the source port. Switches, on the other hand, support connections. Switches thus form a temporary connection when a packet arrives; packets are forwarded to the destination port.

These properties of hubs and switches make a big difference when it comes to capturing packet data. The fact that hubs do not support connections enables someone to install a packet capture device that captures virtually all traffic that passes through. Switches, on the other hand, are not so versatile when it comes to capturing packets. To put it bluntly, they can miss packets if specific solutions are not put in place to ensure that a packet capture device picks up traffic that goes through the switch.

The major solution for capturing packets in a switched environment is a port called a "spanning port." A spanning port can be configured in a manner that causes a switch to behave like a hub for a particular port. Figure 6.1 illustrates how this can be done. The connection between the switch and a particular host can be monitored using a spanning port that dumps packet contents to a machine used specifically for capturing packet data. This does not, of course, guarantee that all packet data will be recorded. Additionally, one of the limitations of switches is that only one port can be spanned at any point in time. This greatly complicates simultaneously capturing packets from more than one host. Finally, the sheer throughput of a switch makes collection and processing of packets quite challenging. Of course, any form of packet encryption ‚ such a packets transmitted via a VPN ‚ defeats successful analysis of collected packets.

Figure 6.1. A typical configuration for using a spanning port.

Another alternative is to put a hub or a network tap device (hereafter called a "tap") between the switches, between a router and a switch, or between a monitored host and a switch. Figure 6.2 illustrates the last of these three possibilities. A hub between the resource machine and the switch is, in this case, copying packet data that pass between the switch and the monitored host. The hub then shunts the copies of the network traffic off to a host that stores the data.

Figure 6.2. A hub sending data passing between a monitored host and switch.

The use of a hub or other device in the manner shown in Figure 6.2 is also less than optimal; it can be used only for monitoring single hosts. Placing more than one host on the hub also causes a number of networking complications that are beyond the scope of this chapter. Still another complication is that for all practical purposes, a fault-tolerant hub must be purchased. Fault tolerant hubs, however, are generally expensive to buy.

Still another deployment option is to deploy a tap, a device that connects directly to network media, instead of a hub in the configuration shown in Figure 6.2. Most taps have built-in fault-tolerance capabilities yet have a more reasonable purchase price. In this deployment, it is important to ensure that traffic flow to the data storage host is one-way to avoid the possibility of obtaining a considerable amount of data from hosts for which you already know the source IP address. It can also, in some cases, reduce the probability of a denial-of-service attack from excessive traffic. Commercial products that support one-way traffic flow are available.

A final caveat is appropriate before moving on. By now, it should be apparent that there is a lot more to capturing packets than meets the eye. Careful planning, particularly in the preparation stage, is thus a prerequisite.You will also need to ensure that the host you use to store the captured data has sufficient storage capacity. It is not difficult to fill a 20GB or 30GB hard drive with packet data in a relatively short period of time, assuming high network throughput rate at the point where data are being captured. Because of this, some organizations use optical media (such as worm drives ) with many terabytes of storage capacity for recording packet data.

We will next consider what to do if you should happen to obtain one or more source addresses.

‚  < ‚  Free Open Study ‚  > ‚  


Incident Response. A Strategic Guide to Handling System and Network Security Breaches
Incident Response: A Strategic Guide to Handling System and Network Security Breaches
ISBN: 1578702569
EAN: 2147483647
Year: 2002
Pages: 103

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net