Matching TCP Packets for Stepping-Stone Intrusion Detection Resistant to Intruders’ Chaff Perturbation

Abstract

Hackers usually launch cyberattacks through several stepping-stone hosts to reduce the chance of being detected. With stepping-stone intrusion (SSI), the attacker’s identity is hidden behind a long interactive connection chain of stepping stones and thus is very difficult to reveal. Many algorithms for detecting SSI have been proposed since 1995. Most of these known detection algorithms for SSI only work for network traffic without intruders’ session manipulation. These known SSID algorithms are either weak to resisting intruders’ chaff-perturbation manipulation or have a very limited capability in resisting attacker’s session manipulation. This paper proposes an innovative SSID algorithm resistant to intruders’ chaff perturbation through matching TCP packets by using the crossover of packets. Our proposed SSID algorithm is verified by well-designed network experiments. Our experimental results show that the proposed SSID algorithm works effectively in detecting network intrusion as well as resisting intruders’ chaff perturbation.

1. Introduction

With SSI, a hacker creates a chain of compromised hosts (stepping-stone hosts), employs the tool ssh to login to each of the stepping-stone hosts in the chain, and then sends the attacking commands to the victim host [1,2,3,4,5,6,7]. Figure 1 shows a sample of a connection chain with five connections. In this figure, host A is the attack host, whereas host V serves as the victim host. In turn, the attacker remotely logins to the stepping-stone hosts S1, S2, S3, and S4, and eventually to the victim. To perform SSID, any stepping-stone host between the attacker A and the victim host V can be used as the sensor host to capture network packets using certain tools such as tcpdump or Wireshark. Assume that host S2 is selected as the sensor host. The connections from the intruder A to host S1, and then to the sensor S2, form the upstream sub-chain, whereas the connections from S2 to host S3 to host S4 and finally to the victim V form the downstream sub-chain.

The goal for detecting SSI is to decide whether a stepping-stone host is used by an attacker for a network intrusion [1,2,3]. The session is a network intrusion detected at the sensor host if an ingress connection to the sensor matches one of its outbound connections from the sensor. With stepping-stone intrusion, it is extremely tough to detect the intruder as it is hidden behind a long communication session [1,2,3]. The difficulty for the final victim host V to obtain information about the origin of the attack has been well documented in the literature of this area.

Nowadays, attackers often send hacking commands using techniques such as chaff perturbation to manipulate the communication session, that is, injecting some meaningless packets into a TCP data stream. The purpose for performing this is to decrease the probability of being caught. SSI with chaff perturbation is also referred to as a chaff attack. Through a chaff attack, intruders can not only revise the packets’ round-trip times (RTTs) but can also change the packet count for those sent from the attacker host to the victim. With chaff attacks, most of the existing detection approaches for SSI may be defeated by hackers. Today, chaff-attacking techniques have been widely used in various cyberattacks.

A widely used type of detection method for SSI is to find if an outbound connection departing from the sensor matches with an ingress connection into the sensor [1,2]. If so, it is highly suspicious that the sensor host is used as a stepping-stone host. With this type of SSID approach, all the network packets are captured and analyzed only at the selected sensor host; thus, it is called host-based SSID [8]. Figure 2 below shows a scenario for deciding if the host H1 is used as a stepping-stone one. The basic idea here is that if host H1 is used as a stepping-stone host, some other host must be under attack presumably via host H1, although this detection method may bring false positive errors.

In Figure 2, H1 is the sensor host. This figure shows a scenario where C_in is an incoming connection from its upstream hosts (up to the attacker machine) and C_out is an outgoing connection that goes to its downstream hosts until it reaches the victim machine. If C_in and C_out are proved to be a relayed pair of connections, then host H1 is used as a stepping stone. In the incoming connection C_in, there are two streams, S_i and E_j, where S_i represents the request packets stream, which is also called ‘Send packets from the attacker to the victim’, whereas E_j represents the response packets stream, which is also called ‘Echo packets from the victim back to the attacker host’. Similarly, the two streams $S_i^{\prime }$ and $E_j^{\prime }$ are obtained from the outgoing connection C_out.

Many such methods for SSI have been proposed in the literature. The work [1] is the first paper in this area for unencrypted network traffic. The conclusion of [1] states that, if there is such a relayed pair of connections, the sensor host is used as a stepping stone. The detection algorithm proposed in [1] is easy to implement and also quite efficient. The primary issue for the content thumbprint is that it is hard to obtain packets’ contents if the connection is established using encrypted tools, such as SSH or OpenSSH. Thus, this method for detecting SSI based on packet contents can be easily defeated by establishing an encrypted session.

A time thumbprint is an approach proposed by Y. Zhang and V. Paxson [2] in 2000 to detect SSI when the network traffic is encrypted. The time thumbprint approach can overcome the difficulty existing in a content thumbprint. The main reason is that, instead of using the packet content, this approach uses the timestamp of each captured packet to define the time thumbprint. Since the timestamp of each packet is not encrypted, and also only relies on the local host system time clock, this approach is not only stable and reliable but also cannot be affected by the clock skew issue. However, the time thumbprint approach can be easily defeated by chaff attacks as intruders’ session manipulation can change the timestamps of network packets.

The use of encrypted sessions by intruders makes SSID much more complicated, and the intruder’s active timing perturbation and injection of chaff packets by attackers make the SSI detection process even more difficult. The use of packet count was proposed in [4] and [5] by T. He et al. to handle such SSID challenges. The paper [5] is the extended version of the paper [4]. These two papers proposed strategies for identifying stepping-stone connections when the network traffic is encrypted, and the timestamps of packets are perturbed or chaff packets are injected into an attacking stream. Two activity-based algorithms are proposed to detect stepping-stone connections with either bounded memory or bounded delay perturbation, respectively. More details of these host-based detection methods will be reviewed and discussed in the next section.

Most of these known host-based detection algorithms for SSI only worked effectively for network traffic without intruders’ session manipulation. When session manipulation such as chaff perturbation or time jittering by intruders is present, however, these known hosted-based SSID algorithms are either weak to resisting intruders’ manipulation or have a very limited capability in resisting attacker’s manipulation.

This paper develops an innovative host-based algorithm for SSID that is effective for detecting SSI and resistant to intruders’ chaff perturbation through matching TCP packets by using packet crossover. Our proposed detection algorithm can be simply implemented as the ratios of packet crossover used in this paper can be quickly computed. Well-designed network experiments are conducted to verify the correctness of the proposed method for SSI. The experimental results that we obtained exhibit that the proposed approach for SSI in this paper works in resisting intruders’ chaff attacks effectively.

The rest of this paper is organized as follows: related work of this paper is presented in Section 2. Preliminary knowledge of basic concepts is given in Section 3. In Section 4, we give an effective SSID algorithm to determine whether a host is used as a stepping stone for network traffic with chaffed meaningless packets via using the occurrences of packet crossover. In Section 5, we design and conduct network experiments to verify the correctness of Proposition 1, which is a theoretical basis of the proposed SSID algorithm. Section 6 concludes this paper and gives some discussion of future research directions in the SSID area.

2. Related Work

This section discusses the related work of SSID approaches. The review focuses on the known host-based SSID approaches that determine whether the sensor host is used as a stepping-stone one for malicious intrusion. The easiest way to verify whether the two connections C_in and C_out of host H1 shown in Figure 1 are relayed is to compare the actual content of the network packets from the two connections. The idea of examining packet contents in a connection to determine whether a host is used as a stepping stone was proposed by S. Staniford-Chen and L. T. Heberlein [1] in 1995. The primary issue for the content thumbprint is that it is hard to obtain packets’ contents if the connection is established using encrypted tools, such as SSH or OpenSSH. Thus, this method for detecting SSI based on packet contents can be easily defeated by establishing an encrypted session.

The time thumbprint approach [2] can overcome the difficulty existing in a content thumbprint. The main reason is that, instead of using the packet content, this approach uses the timestamp of each captured packet to define the time thumbprint. Since the timestamp of each packet is not encrypted, and also only relies on the local host system time clock, this approach is not only stable and reliable but also cannot be affected by the clock skew issue.

K. Yoda et al. proposed another detection method for SSI in [9] using the idea of investigating the deviation for two consecutive connections of the same connection chain. The content of network packets was not used for the design and analysis of this approach, and thus the approach proposed in [9] works for encrypted network traffic.

The use of packet count was proposed in [4,5] by T. He et al. to handle such SSID challenges. The paper [5] is the extended version of the paper [4]. A. Blum et al. proposed another detection method for network intrusion via using the idea to count the number of network packets in the ingress connection as well as the outbound connection, respectively [6], making the conclusion that the difference between these two numbers is less than a constant number if such a pair of connections is a relayed one.

The research findings [3] obtained by D. L. Donoho et al. show that intruders’ capabilities of manipulating communication sessions are limited and they will not be able to evade detection by camouflaging the communication sessions.

In [8], we proposed an effective approach for stepping-stone intrusion detection (SSID) via estimating the length of a connection chain using packet crossover ratios. In another of our recent research publications [10], we developed an effective host-based detection method for SSI by using packet crossover for network traffic without chaffed meaningless packets.

X. Wang et al. developed SSID approaches using the idea of a watermark from 2001 to 2011 [11,12,13,14]. The key idea of this type of SSID method is to inject a watermark into the incoming connection to the sensor host and then observe the outgoing connections from this host to check whether the injected watermark can be found on the outgoing links. If so, the sensor host is highly likely being used as a stepping-stone one.

3. Preliminaries

This section discusses some basic concepts that will be used in the design of our proposed SSID algorithm in this paper.

3.1. A Matched Pair of a Send Packet and Its Corresponding Echo

Send packets and their corresponding echoes are clearly described in [8,10]. Let us use an example to review these basic concepts. Assume that the Linux command “ps” is typed on a terminal in the attacker machine (refer to Figure 1). The command “ps” could be sent to the victim host in one or two packets. For simplicity, it is assumed that the command with two separate TCP packets is sent to the victim host: one packet with the letter “p” and the other with the letter “s”. Both are Send packets because they are sent from the attacker host to the victim. After “p” is typed on the attacker host, the packet with “p” is sent to the remote victim machine. Once it arrives at the victim host, a corresponding Echo packet is then delivered back to the attacker host. As a result, its screen displays the letter “p”. In this example, the Send packet with “p” and the corresponding Echo one are a matched pair of packets. Similarly, a Send packet with “s” and its corresponding Echo one holding “s” are also a matched pair.

3.2. Crossover of Packets

TCP allows a client host to send pipelined request (Send) packets to a remote server. Packet crossover occurs when a new Send packet meets the corresponding Echo packet of a previous Send one before the Echo arrives at host 1 (see Figure 3) [7]. In Figure 3, four hosts, the client (host 1), host 2, host 3, and the server (host 4), are involved in a connection chain, where both hosts 2 and 3 are stepping-stone hosts in this chain. The packets S1, S2, and S3 (marked red) are the Send packets, and the packets E1, E2, and E3 (marked green) are their corresponding Echo packets. Assume that host 2 serves as the sensor host for capturing all the packets; then, the Send packets and their corresponding Echo packets from the connection between host 2 and host 3 are captured and analyzed. The sequence of these six packets monitored at the sensor is S1, E1, S2, S3, E2, and E3, respectively. Thus, one occurrence of packet crossover is observed in this case, which is the one occurring between host 2 and host 3, caused by the two packets S3 and E2.

3.3. An Algorithm for Calculating Packet Crossover Ratios

In this paper, we adopt the algorithm that we developed in our prior work [8] to compute packet crossover ratios. This Algorithm 1 is essential for the design of our proposed detection algorithm for SSI using packet crossover that will be presented in the next section.

Algorithm 1. Compute Packet Crossover Ratio

Input: a TXT file containing packet timestamp, packet type (Send or Echo), and index of Send or Echo

Output: Packet Crossover Ratio

sendIndex, echoIndex, crossoverCount = 0

while more packets in data capture file:

if currentPacket is Acknowledgement:

discard packet

break

else if currentPacket is Echo:

if echoIndex less than sendIndex:

crossoverCount += (sendIndex − echoIndex)

echoIndex += 1

else if (currentPacket is Send):

sendIndex += 1

PacketCrossoverRatio = crossoverCount/(2 × echoIndex)

Print PacketCrossoverRatio

3.4. Chaff Attack Definition and Chaff Rates

Today, chaff attacks are widely utilized by intruders in order to evade detection. Many known SSID approaches can be defeated by chaff attacks. Chaffing is a process of injecting meaningless packets into an interactive data stream. It uses packet forging or spoofing techniques. It interferes with an ongoing TCP stream. The steps involved in chaffing include making a raw socket; creating an Ethernet, IP, and TCP header; assembling the header and data to generate a chaff packet; and sending the chaff packet through the raw socket. Chaff packets can be easily created by using existing tools such as hping, Pakcit, and Ettercap.

In this paper, we perform offline chaffing by randomly injecting meaningless packets into each of the captured dataset files. More specifically, we select different chaff rates of λ = 0%, 10%, and 50%, respectively. For example, when the chaff rate λ = 10%, each captured dataset is randomly injected 100 meaningless packets in every 1000 packets.

4. Matching Packets Using Packet Crossover for Network Traffic with Chaff

In this section, we give a proposition that is a theoretical basis for our detection algorithm design. Then, we present an effective SSID algorithm to determine whether a host is used as a stepping stone for network traffic with chaffed meaningless packets using the ratios of packet crossover.

Proposition 1.

Assume that both an incoming connection and an outgoing connection of the sensor host contain chaffed meaningless packets. We claim that these two connections of the sensor are a relayed pair if the ratio of packet crossover for the incoming connection is almost equal to that of the outgoing connection. In such a case, it is highly suspicious that the sensor host is used as a stepping-stone one.

This proposition will be verified through several well-designed network experiments conducted in the environment of the Internet in Section 6.

Next, we adopt the host-based SSID algorithm using packet crossover proposed in [10]:

(1)

Pick a host of a network as the sensor host.

(2)

Adopt Algorithm 1 (Compute Packet Crossover Ratio) described in Section 3.3 to calculate the packet crossover ratio for every incoming connection to the above sensor host.

(3)

Adopt Algorithm 1 (Compute Packet Crossover Ratio) described in Section 3.3 to calculate the packet crossover ratio for every outgoing connection from the above sensor host.

(4)

If any of the packet crossover ratios calculated for an incoming connection at Step (2) is almost the same as one of the packet crossover ratios calculated for an outgoing connection at Step (3), then it is highly suspicious that these two connections are a relayed pair, and thus the sensor host is used as a stepping-stone one.

(5)

If none of the packet crossover ratios calculated at Step (2) for incoming connections is close to any of the packet crossover ratios calculated for outgoing connections at Step (3), then it is almost sure that the sensor is not used as a stepping-stone host.

Theoretically, the correctness of our detection algorithm for SSI listed above is clearly asserted based on Proposition 1. Our experimental results presented in Section 5 exhibit that the proposed detection approach against SSI in this paper works effectively in resisting chaff attacks manipulated by hackers.

Proposition 1 holds in any wired local area networks with an arbitrary number of hosts in the network, and, thus, so does our proposed algorithm for SSID in this paper.

5. Network Experimental Results and Analysis

In this section, we design and implement network experiments to verify the correctness of Proposition 1 described in Section 4 by comparing the packet crossover ratios of incoming and outgoing connections. Relayed pairs typically result in almost equal packet crossover ratios. On the other hand, non-relayed pairs of connections typically result in dissimilar packet crossover ratios.

To set up our experimental environment, we created a connection from a local computer (localhost-1) in our computer lab at Columbus State University (Columbus, GA, USA) to four remote Amazon AWS servers, aws-servers 1 through 4, which were then connected back to another local host (localhost-2) in the same computer lab in our university. A chain of five connections was created from the attacker host localhost-1 to the victim host localhost-2 through the four stepping stones: aws-servers 1 through 4. Linux was running in each of these six hosts, which had both the SSH client and server installed in each host. AWS2 served as the sensor host. We used the tool tcpdump to capture all the network packets at the sensor host.

The corresponding actual geographic locations and their corresponding public IP addresses of the four AWS servers (aws-servers 1 through 4) are listed in

Table 1. Public IP addresses and geographic locations of the four AWS servers.

Servers	Systems	Public IP	Location
aws-server 1	Linux	34.239.127.118	Ashburn, USA
aws-server 2	Linux	52.59.96.142	Frankfurt, GER
aws-server 3	Linux	18.133.230.26	London, UK
aws-server 4	Linux	52.60.79.102	Vancouver, CA

. Both the incoming packets to the sensor host AWS2 and the outgoing packets from AWS2 were monitored and captured at the sensor host.

For this experiment, we used four virtual servers on the Amazon AWS cloud, except for the two local hosts that we used in our computer labs. It is well known that a virtual machine server runs on the top of another physical computer server. If the virtual servers are replaced by physical computer servers located in each of the specific cities that we selected, the RTTs of captured network packets will be reduced slightly. However, the number of packet crossovers will remain the same, and so will the packet crossover ratios. Therefore, the replacement of four virtual servers with physical computer servers does not affect the results of this experiment.

After the connection chain was established, both the incoming and outgoing connections of the sensor host AWS2 were monitored, and the packets were captured using the tcpdump tool running at the sensor host AWS2.

In the first experiment that we conducted, network traffic without chaffed meaningless packets was captured and analyzed. With this experiment, we first entered the following Attacker 1 script of standard Linux commands for about 3 min into a terminal on the attacker localhost-1 and captured all packets from the indicated connections at the sensor AWS2:

//Attacker 1 script

pwd

whoami

sudo su

ls

cd/etc

ls −a

scp −p shadow attacker username@attacker IP:/home/seed/Documents

exit

By running the Attacker 1 script for about 3 min, we captured 10 datasets in total at the sensor host AWS2, with each dataset comprising two files: one for the incoming connection to the sensor host and the other one for the outgoing connection from the sensor host. On average, over the 10 datasets, we captured 514 packets from the incoming connection to AWS2 and 514 packets from the outgoing connection from AWS2.

After capturing all the data, we ran our packet crossover ratio algorithm to calculate the packet crossover ratio observed at the sensor AWS2 from the incoming connection represented by i1 for the above script (refer to Figure 4). In

Table 2. CRs of relayed pairs (i1, o1) and (i2, o2) close to 1. This table verifies Proposition 1 for network traffic without chaff.

DataSet #	i1 CR	o1 CR	i1/o1	i2 CR	o2 CR	i2/o2
1	0.7850	0.7851	1	3.3130	3.3130	1
2	0.8158	0.8158	1	0.6149	0.6149	1
3	0.8290	0.7345	1.13	0.6278	0.6278	1
4	1.2820	1.0871	1.18	0.6212	0.6515	0.95
5	0.8319	0.8319	1	0.6742	0.6742	1
6	0.8532	0.8455	1.01	0.7593	0.7593	1
7	0.8000	0.8000	1	0.8310	0.8310	1
8	0.9250	0.9250	1	0.6667	0.6667	1
9	0.8651	0.8651	1	0.6761	0.6761	1
10	3.1972	3.1257	1.02	0.6104	0.6184	0.99

, CR stands for crossover ratio. Column 1 of Table 2 lists the number of each dataset. Column 2 of Table 2 lists the crossover ratio (CR) of the incoming connection i1 for each dataset. Then, we ran the packet crossover ratio algorithm to calculate the packet crossover ratio observed at the sensor AWS2 from the corresponding outgoing connection represented by o1 (refer to Figure 4). Column 3 of Table 2 lists the crossover ratio (CR) of the outgoing connection o1 for each dataset.

Next, we entered the following Attacker 2 script of standard Linux commands different from Attacker 1 for about 3 min into a terminal at the attacker localhost-1 and captured all packets from the indicated connections at the sensor host AWS2:

//Attacker 2 script

whoami

pwd

cd/home/seed/Documents

ls

nano text_file.txt

//paste a large text and save it

ls

cat hello.txt

exit

By running the Attacker 2 script for about 3 min, we captured 10 datasets in total at the sensor host AWS2, with each dataset comprising two files: one for the incoming connection to the sensor host and the other one for the outgoing connection from the sensor host. On average, over the 10 datasets, we captured 338 packets from the incoming connection to AWS2 and 338 packets from the outgoing connection from AWS2.

After capturing all the data, we ran our packet crossover ratio algorithm to calculate the packet crossover ratio observed at the sensor AWS2 from the incoming connection represented by i2 for the above script (refer to Figure 5). Column 5 of Table 2 lists the crossover ratio (CR) of the incoming connection i2 for each dataset. Then, we ran the packet crossover ratio algorithm to calculate the packet crossover ratio observed at the sensor AWS2 from the corresponding outgoing connection represented by o2 (refer to Figure 5). Column 6 of Table 2 lists the crossover ratio (CR) of the outgoing connection o2 for each dataset.

We then used the packet crossover ratios that we obtained to match the incoming and outgoing connections. Based on Proposition 1 above, the packet crossover ratios captured at a given sensor for the incoming and outgoing connections of a relayed pair should be close to 1. Therefore, we expected to see a matching of close to 1 for ratio i1/o1 in Column 4 of Table 2, as well as a matching for ratio i2/o2 close to 1 in Column 7 of Table 2. Moreover, we expected to see from this table a matching not close to 1 for non-relayed connection pairs, such as i1 and o2 (or i2 and o1). This table compares the CR of i1 to its respective outgoing connection o1. The CRs of relayed pairs should be very similar. Therefore, the incoming connection’s CR divided by the outgoing connection’s CR should and does equal approx. 1 in Columns 4 and 7 of Table 2.

Now, let us calculate standard deviations to back our claim, Proposition 1 described in Section 4. In column 4 of Table 2, the mean of the ratio i1/o1 over the 10 datasets is µ(i1/o1) = 1.034. Its standard deviation is 0.065, which is very low. In column 7 of Table 2, the mean of the ratio i2/o2 over the 10 datasets is µ(i2/o2) = 0.994. Its standard deviation is 0.016, which is also very low. These low values of standard deviations further verify the correctness of Proposition 1 when there are no chaffed meaningless packets in the network traffic.

In the second experiment that we conducted, network traffic with meaningless packets chaffed at a rate of 10% was captured and analyzed. We performed all the same steps as carried out for the first experiment above for network traffic without chaffed packets. We entered the scripts of Attacker 1 and Attacker 2, respectively, for about 3 min for each script into a terminal on the attacker localhost-1 and captured all packets from the indicated connections at the sensor AWS2. Similarly, the same packet crossover ratio algorithm was employed to compute the packet crossover ratio using the captured packets with a 10% chaff rate at the sensor host. Our results for the second experiment are listed in

Table 3. CRs of relayed pairs (i1, o1) and (i2, o2) close to 1. This table verifies Proposition 1 for 10% chaff rate.

DataSet #	i1 CR	o1 CR	i1/o1	i2 CR	o2 CR	i2/o2
1	3.36	3.36	1.00	6.33	6.34	1.00
2	3.54	3.62	0.98	2.40	2.39	1.00
3	3.58	3.35	1.07	2.83	2.85	0.99
4	4.49	4.25	1.06	2.17	2.12	1.02
5	3.64	3.65	1.00	2.22	2.24	0.99
6	3.40	3.51	0.97	2.01	1.98	1.02
7	3.52	3.46	1.02	2.51	2.54	0.99
8	3.84	3.75	1.02	2.60	2.56	1.02
9	3.90	3.91	1.00	2.32	2.38	0.97
10	7.60	7.49	1.01	2.45	2.43	1.01

below, and are very similar to our results for the first experiment without chaffed meaningless packets (refer to Table 2).

Now, let us calculate standard deviations to back Proposition 1 for this experiment. In column 4 of Table 3, the mean of the ratio i1/o1 over the 10 datasets is µ(i1/o1) = 1.013. Its standard deviation is 0.032, which is very low. In column 7 of Table 3, the mean of the ratio i2/o2 over the 10 datasets is µ(i2/o2) = 1.001. Its standard deviation is 0.017, which is also very low. These low values of standard deviations further verify the correctness of Proposition 1 when the chaff rate is 10%.

In the third experiment that we conducted, network traffic with meaningless packets chaffed at a rate of 50% was captured and analyzed. We performed all the same steps as carried out for the first experiment above for network traffic without chaffed packets. We entered the scripts of Attacker 1 and Attacker 2, respectively, for about 3 min for each script into a terminal on the attacker localhost-1 and captured all packets from the indicated connections at the sensor AWS2. Similarly, the same packet crossover ratio algorithm was employed to compute the packet crossover ratio using the captured packets with a 50% chaff rate at the sensor host. Our results for this experiment are listed in

Table 4. CRs of relayed pairs (i1, o1) and (i2, o2) close to 1. This table verifies Proposition 1 for 50% chaff rate.

DataSet #	i1 CR	o1 CR	i1/o1	i2 CR	o2 CR	i2/o2
1	11.58	11.62	1.00	16.09	16.23	0.99
2	12.49	12.54	1.00	8.16	8.22	0.99
3	12.40	12.30	1.01	9.69	9.67	1.00
4	14.65	14.42	1.02	7.30	7.01	1.04
5	12.77	12.66	1.01	7.48	7.36	1.02
6	11.92	11.92	1.00	6.07	6.14	0.99
7	12.29	12.40	0.99	8.12	8.06	1.01
8	13.07	12.97	1.01	8.78	8.71	1.01
9	13.67	13.74	0.99	7.90	7.85	1.01
10	21.56	21.67	0.99	8.36	8.21	1.02

below, and are also very similar to our results for the first experiment without chaffed meaningless packets (refer to Table 2).

Now, let us calculate standard deviations to back Proposition 1 for this experiment. In column 4 of Table 4, the mean of the ratio i1/o1 over the 10 datasets is µ(i1/o1) = 1.002. Its standard deviation is 0.01, which is very low. In column 7 of Table 4, the mean of the ratio i2/o2 over the 10 datasets is µ(i2/o2) = 1.008. Its standard deviation is 0.016, which is also very low. These low values of standard deviations further verify the correctness of Proposition 1 when the chaff rate is 50%.

Next, let us use the same datasets that we captured by running the above Attacker 1 script to compare the performance of the SSID algorithm that we proposed in this paper with the SSID method developed in [6] by A. Blum et al. We compare the detection accuracies of these two SSID algorithms in the following three different scenarios of network traffic:

(1)

Captured network traffic with no chaffed meaningless packets;

(2)

Captured network traffic with 10% chaff rate;

(3)

Captured network traffic with 50% chaff rate.

For the first scenario of network traffic with no chaff, according to the experimental data in Table 2 and the analysis that we performed on column 4 (the ratio i1/o1) and column 7 (the ratio i2/o2) of Table 2, with their standard deviations of 0.065 and 0.016, respectively, our proposed SSID algorithm detected the relayed connection pair for each of the 10 datasets. Therefore, the detection accuracy of our proposed SSID algorithm is 100%, as shown in

Table 5. Detection accuracies of the two SSID algorithms in three different scenarios.

SSID Algorithms	Network Traffic with no Chaff	Network Traffic with 10% Chaff Rate	Network Traffic with 50% Chaff Rate
SSID algorithm proposed in this paper	100%	100%	100%
SSID algorithm developed in [6]	100%	100%	70%

below. Now, we analyze the detection accuracy of the SSID method developed in [6] for this scenario. Let us assume that the maximum tolerable delay bound Δ = 1000 ms. For the first dataset that we captured by running the Attacker 1 script, the maximum number of packets that may be sent in the time interval Δ is p_Δ = 4. The difference in the number of packets of the two streams never exceeds the packet bound 4. The SSID algorithm in [6] detected the attacking pair for the first dataset, and the same is true for the remaining nine datasets. Thus, the detection accuracy of the SSID algorithm in [6] is 100%, as shown in Table 5 below.

For the second scenario of network traffic with a 10% chaff rate, according to the experimental data in Table 3 and the analysis that we performed on column 4 (the ratio i1/o1) and column 7 (the ratio i2/o2) of Table 3, with their standard deviations of 0.032 and 0.017, respectively, our proposed SSID algorithm detected the relayed connection pair for each of the 10 datasets. Therefore, the detection accuracy of our proposed SSID algorithm is 100%, as shown in Table 5 below. Now, we analyze the detection accuracy of the algorithm for detection with chaff described in Section 5.1 of [6] for this scenario. Let us assume that the maximum tolerable delay bound Δ = 1000 ms. For the first dataset that we captured by running the Attacker 1 script, the maximum number of packets that may be sent in the time interval Δ is p_Δ = 4. The difference in the number of packets of the two streams never exceeds 2 p_Δ = 8. The SSID algorithm in Section 5.1 of [6] detected the attacking pair for the first dataset, and the same is true for the remaining nine datasets. Thus, its detection accuracy over the 10 datasets is 100%, as shown in Table 5 below.

For the third scenario of network traffic with a 50% chaff rate, according to the experimental data in Table 4 and the analysis that we performed on column 4 (the ratio i1/o1) and column 7 (the ratio i2/o2) of Table 4, with their standard deviations of 0.01 and 0.016, respectively, our proposed SSID algorithm detected the relayed connection pair for each of the 10 datasets. Therefore, the detection accuracy of our proposed SSID algorithm is 100%, as shown in Table 5 below. Now, we analyze the detection accuracy of the algorithm for detection with chaff described in Section 5.1 of [6] for this scenario. Let us assume that the maximum tolerable delay bound Δ = 1000 ms. For the first dataset that we captured by running the Attacker 1 script, the maximum number of packets that may be sent in the time interval Δ is p_Δ = 6. The difference in the number of packets of the two streams never exceeds 2 p_Δ = 12. The SSID algorithm in Section 5.1 of [6] detected the attacking pair for the first dataset, and another 6 out of the 10 datasets, but it failed to detect the attacking pair for the remaining 3 datasets. Thus, its detection accuracy over the 10 datasets is 70%, as shown in Table 5 below.

We summarize the detection accuracy comparison between these two SSID algorithms in Table 5 below. The data shown in Table 5 are the detection accuracies over the 10 captured datasets for each of these two SSID algorithms. From the data in this table, we conclude that our SSID algorithm proposed in this paper outperforms the detection method developed in [6] when the chaff rate is large.

6. Conclusions and Future Work

In this paper, we developed a host-based approach to detect SSI using packet crossover. Our proposed method for detecting SSI is resistant to chaff attackers manipulated by hackers and works effectively to detect network intrusion. Most existing algorithms for detecting SSI are either weak to resisting chaff attacks manipulated by hackers or have a very limited capability in resisting attacker’s session manipulation. The detection approach for SSI proposed in this paper can be simply and quickly implemented as computing the ratios of the packet crossovers is straightforward. Our results from the well-designed network experiments exhibit that our proposed algorithm for detecting SSI performs perfectly in resisting chaff attacks manipulated by hackers up to a 50% chaff rate. Our proposed SSID method works in any wired local area network with an arbitrary number of hosts on it.

The key weakness of the SSID algorithm proposed in this paper is that it belongs to a host-based method of SSID, with which only the network packets captured at a single host were used for the analysis and detection of malicious intrusion. Depending only on if a host is used as a stepping stone to decide whether an SSI exists may generate a false positive error. In fact, due to the use of web services and/or cloud computing, many legitimate applications may use two stepping-stone machines to access a remote server. For example, the architecture “client browser -> application server -> Web services -> remote database server” is a commonly used scenario in the IT industry today.

So far, in all the known works that address intruders’ chaff manipulation, it is assumed that the incoming and outgoing connections of only one host (the sensor) can be chaffed with meaningless packets. For future research directions related to SSID, detection algorithms for SSI that are resistant to chaff attacks if meaningless packets are chaffed by intruders into the egress and ingress connections of two or more machines in a connection chain could be investigated.

Using machine learning algorithms or deep learning approaches may be a promising way to design new detection algorithms for stepping-stone intrusion detection.