The Session Token Protocol for Forensics and Traceback
Carrier, B., & Shields, C. (2004). The Session Token Protocol for Forensics and Traceback. ACM Transactions on Information Security and System Security, 7, 333-362. Retrieved on September 13, 2006, from the ACM Digital Library database.
In this article, Carrier and Shields describe the Session Token Protocol (STOP), a protocol designed to be used by forensic investigators and others to track the identity of an attacker. It is based and expands on the Identification Protocol (IDENT).
By “stone stepping,” an attacker logs on through many host computers before trying an attack to complicate any attempt to learn his identity. To seek a remedy for this problem, the authors started by reviewing two alternative but limited types of network traceback: IP traceback which attempts to locate the source of spoofed Internet Protocol packets, and network-based connection-chain which tracks attacks that were performed using a connection chain. These two types of traceback are not effective if the attacker spoofs the IP address of the victim in a system that responds with a protocol like DNS, also known as a reflector attack. The authors then described IDENT, the protocol on which STOP is based. IDENT is a two-way protocol used by a server to identify the client-side of a network connection. First, it establishes a TCP connection from the client port to the server port on the host computer. Then, the host computer connects to the TCP port on the previous host computer and sends the message, . The previous host computer then uses the source IP address to determine which process had a connection from the client port to the server port. If it is able to locate a process, it returns a message. IDENT’s limitations include that it may provide insecure sources with information concerning the service a user is using, can be used to collect email addresses, and the IDENT daemon does not automatically protect a user’s privacy.
The authors then introduced the STOP protocol which provides additional functionality to what is offered by IDENT, and data that is usually missing in forensics investigations. It gives a log of socket activity, can request that a daemon using this protocol save additional user-level and application-level data, and provides a mechanism that the protocol can use to trace a hacker using many hosts. In fact, STOP works most effectively when it is run on many hosts. While IDENT did not maintain privacy, STOP does so by returning a random token rather than a user’s name. Because IDENT is widely used, STOP has been built to be backward compatible with it. The protocol used by STOP incorporates recursive traceback in an attempt to gain access to information on the whole pathway of a connection. This lets investigators trace an attacker to their home system or computer. STOP may not always show the entire chain of connection. But it can lower the expensive costs of a forensics investigation required to catch an attacker.
Two of the three case studies that were shown by the authors were the simple and complex process structures. Their examples were of process trees that could be analyzed by a daemon that used the STOP protocol. The protocol was tested on three operating systems: Solaris, OpenBSD and Linux. Solaris used the KVM library to read kernel memory, but it used a stream design for it in-memory network structures. Solaris’ design made it harder for it to get information than in the OpenBSD design. OpenBSD, on the other hand, used the KVM library to read the process table and tables from the kernel’s memory. Linux used the pseudofile process system to get information about the process. In the tests it was found that Linux had a 973% increase in lookup time. Linux also spent 136% more time on a SV lookup than the OpenBSD operating system did. This was because OpenBSD could do more in kernel space and Linux had to utilize file IO and use scanf() to determine process data.
Some limitations of STOP are partial deployment, covert channels, its effects on network channels, integrity of saved data and the compromising of STOP daemons. While it is certain that the STOP protocol will not solve all traceback situations, it is a step closer to a solution.
In this article, Carrier and Shields describe the Session Token Protocol (STOP), a protocol designed to be used by forensic investigators and others to track the identity of an attacker. It is based and expands on the Identification Protocol (IDENT).
By “stone stepping,” an attacker logs on through many host computers before trying an attack to complicate any attempt to learn his identity. To seek a remedy for this problem, the authors started by reviewing two alternative but limited types of network traceback: IP traceback which attempts to locate the source of spoofed Internet Protocol packets, and network-based connection-chain which tracks attacks that were performed using a connection chain. These two types of traceback are not effective if the attacker spoofs the IP address of the victim in a system that responds with a protocol like DNS, also known as a reflector attack. The authors then described IDENT, the protocol on which STOP is based. IDENT is a two-way protocol used by a server to identify the client-side of a network connection. First, it establishes a TCP connection from the client port to the server port on the host computer. Then, the host computer connects to the TCP port on the previous host computer and sends the message
The authors then introduced the STOP protocol which provides additional functionality to what is offered by IDENT, and data that is usually missing in forensics investigations. It gives a log of socket activity, can request that a daemon using this protocol save additional user-level and application-level data, and provides a mechanism that the protocol can use to trace a hacker using many hosts. In fact, STOP works most effectively when it is run on many hosts. While IDENT did not maintain privacy, STOP does so by returning a random token rather than a user’s name. Because IDENT is widely used, STOP has been built to be backward compatible with it. The protocol used by STOP incorporates recursive traceback in an attempt to gain access to information on the whole pathway of a connection. This lets investigators trace an attacker to their home system or computer. STOP may not always show the entire chain of connection. But it can lower the expensive costs of a forensics investigation required to catch an attacker.
Two of the three case studies that were shown by the authors were the simple and complex process structures. Their examples were of process trees that could be analyzed by a daemon that used the STOP protocol. The protocol was tested on three operating systems: Solaris, OpenBSD and Linux. Solaris used the KVM library to read kernel memory, but it used a stream design for it in-memory network structures. Solaris’ design made it harder for it to get information than in the OpenBSD design. OpenBSD, on the other hand, used the KVM library to read the process table and tables from the kernel’s memory. Linux used the pseudofile process system to get information about the process. In the tests it was found that Linux had a 973% increase in lookup time. Linux also spent 136% more time on a SV lookup than the OpenBSD operating system did. This was because OpenBSD could do more in kernel space and Linux had to utilize file IO and use scanf() to determine process data.
Some limitations of STOP are partial deployment, covert channels, its effects on network channels, integrity of saved data and the compromising of STOP daemons. While it is certain that the STOP protocol will not solve all traceback situations, it is a step closer to a solution.
posted by Dr. Adam Norten at 5:05 PM
0 Comments:
Post a Comment
<< Home