International Journal of Computer Networks & Communications (IJCNC)

AIRCC PUBLISHING CORPORATION

Victim Based Statistical Filtering: A New Deterrent Against Spoofed Dos Traffic

Suhail Qadir Mir1 and S.M.K. Quadri2

1Post Graduate Department of computer sciences, University of Kashmir, India

2Department of Computer Science, Jamia Millia Islamia, India

Abstract


The extensive use of Internet and network based information resources on a global scale has led to the rise in a wide range of security incidents. One such attack is a TCP-SYN DoS attack, which makes use of IP-Spoofing for its effectiveness. This paper presents a robust scheme for filtering spoofed DoS IP Packets in the Internet. We have proposed a robust filtering algorithm namely, Victim Based Statistical Filtering in this paper. The algorithm is inspired from the Hop-Count Filtering (HCF) method, which uses a co-relation between IP addresses and their respective hop-counts to the destination server, to filter out the spoofed IP packets from the legitimate ones. The variation that we have proposed is adding the monitoring information of the usage levels of port numbers of the destination machine (victim), in the HCF Algorithm. The proposed VBSF algorithm was empirically evaluated and it was found to exhibit better performance than its predecessor. 

Keywords


Hop Count, Flooding, TCP-SYN, DoS Attack, IP Spoofing, IP Filtering.

1. Introduction


The TCP-SYN flooding is the most frequently used DoS attack [1]. The basis of the attack lies in the design of the TCP handshake. In a normal scenario between a client and a server a TCP session starts with an agreement of session parameters between the two communicating parties. The client initiates the process by sending a TCP SYN packet, requesting the server for some service. Upon arrival of the SYN packet, the server resources are allocated i.e. a record for connection buffer, client-info etc. with the SYN packet header, an initial sequence number is provided by the client, a unique number for every connection (used to keep track of data exchanged with the server, so that any missing data can be recognized and handled or to keep track of any repeated data received). The server then replies with a SYN-ACK packet, notifying the client about the grant of connection with itself. The server basically acknowledges the client’s sequence number and returns information about its own initial sequence number.

Figure 1: TCP connection three-way handshake [34].

Now the client machine upon the receipt of the SYN-ACK packet creates a connection buffer record. The client then send back the ACK to the server, thus completing the initial set-up of the connection with the server. This process is called a three-way handshake and is depicted in figure 1.

Figure 2: TCP connection: half-open state.

The promising situation for the exploit lies in the allocation of the server’s resources (during initial connection setup). When the server obliges to the clients request by allocating connection buffer space and send back a SYN-ACK, the connection at this point is said to be half open. The allocated resources by the server are kept occupied for the client-request until an ACK is received from the client, the

Figure 3: TCP SYN flooding during the half-open state and the connection request by the legitimate client [14].

connection timeout expires or the connection is re-set (by sending an RST packet) and the connection is terminated by the server after which the occupied resources are released. Now during the half-open connection phase, in the TCP-SYN flooding the attacker generates a huge number of connection requests and uses client IP spoofing (in order to eliminate the risk of being discarded by the server for a multiple connection requests from the same client). The throng of requests in a short span of time exhausts the TCP connection buffer space and sending the server in a state where no new connections can be established. In practice if the attack is launched from a single source, then using IP spoofing is mandatory. While as if a number of compromised hosts (attack from distributed sources) are used to launch a TCP SYN attack, then the attacker does not need IP spoofing. A number of compromised hosts under the control of the attacker (botnet) launches a deadly TCP SYN attack, where the traffic comes continuously at variable rates. As long as the rate of requesting new TCP-SYNs is greater than at which the TCBs are produced we are assured of a successful attack.

An important thing here to note is the TCP-SYN attack does not basically target a host directly or the network. But rather the attack is aimed at a particular open port or random open ports in the victims system. The initial phase always in a TCP-SYN attack is scanning for open ports on the victim machine. A tool like Nmap [3] gives us the list of open ports on a target machine. After the open port discovery the attacker may launch an attack on a specific port or randomly on a number of ports.

2. Common Defense Mechanisms


 Does an information system or a network exist today that is completely secure, unbreakable and can never be attacked by hackers or any other thing? Yes such a system does exist, it is the system not connected to any network, wrapped up in concrete and lying deep down at the bottom of the deepest ocean on earth [4]. Now clearly such a system is of no use in today’s world given the dependence today users have on internet and network based information processing systems. Now if we can’t have a complete secure system, what can we have then? Security professionals and practitioners have been trying to figure this out for the past three decades, since the inception of the first computer virus [2] and have come to the conclusion that the security of a system can’t be 100% but a system can try and achieve if not 100% but nearer to that.

Similarly the attacks discussed in the preceding section are unavoidable and can’t be prevented 100% but certainly can be mitigated to a certain level where a legitimate user can be assured of the services as promised to be delivered by the information system. Before going into the solution, this section will discusses the existing solutions that exist in practice for the prevention of TCP-SYN Denial of Server attacks happening in Internet or any other network based resource. Some of the very well-known defence mechanisms [5] that prevent DoS attacks from happening are as follows;

2.1 Filtering

Since majority of the TCP-SYN attacks (direct attacks) employ IP spoofing, therefore filtering mechanisms are widely deployed in the networks to check for traffic containing spoofed packets. The filtering techniques Ingress filtering and Egress filtering (6, 7 and 8) represent the most common practices for IP address based filtering. Ingress filtering is a restrictive mechanism to drop traffic with IP address that does not match a domain prefix connected to the ingress router [1]. Egress filtering is an outbound filter, which ensures that only assigned or allocated IP address space leaves the network. History based IP Filtering [9] is based on checking a pre-constructed IP address database for the legitimacy of the packets arriving at the router. If a barrage of packets is entering the router, the connection history is checked and if the barrage is not seen anywhere in the history then the arriving packets are labelled as suspicious and appropriate steps are taken to avoid any catastrophe in the network. Route-based packet filtering [10] is another filtering mechanism used in IP networks. Route-based filtering uses the route information of the IP packets to filter out spoofed IP packets. The main disadvantage of this filtering mechanism is that it requires universal knowledge of the network topology and which may lead to scalability issues. To overcome the issues with route-based filtering Li et al. proposed Source Address Validity En-forcement (SAVE) protocol [11]. SAVE constantly propagates messages containing valid source address information from the source location to all destinations. Thus, each router along the way builds an incoming table that associates each link of the router with a set of valid source address blocks [12]. An attacker can duplicate any field in the header of the IP packet but cannot forge the number of Hops an IP packet makes during its journey from source to destination [12]. In other words the TTL (time to live) value in the header of the IP packet cannot be falsified. Hop Count filtering (HCF) [13] is based on the value contained in the TTL part of the header. In the Hop Count Filtering method a mapping table is constructed, containing hop-count to IP address mapping. Upon the arrival of the new packet new mapping calculations are carried out at the victim site.  The newly calculated values are then compared to the already stored values in the mapping table and the packets whose address is spoofed are identified and discarded in the process.

2.2 Shortening Syn Received Timer

It’s a victim oriented defence technique in which the timer is scaled down when a TCB enters the SYN-RECEIVED state [5, 14 and 15]. The time period is shown in figure 2 (red bar on the server side). With this the curtailed-timer will keep the illegitimate SYN attempts from persisting for as long in the backlog and therefore freeing up the resources for legitimate SYN’s. Decreasing the timer for TCB’s can also prove flawed in some cases, some legitimate connections may be prevented from getting established with the server. Another vulnerability in the defense method is it just needs the attacker to increase the attack rate and make huge number of TCP’s flock the server in lesser time periods. For the above reasons this method of dealing with the TCP-SYN attacks is least preferred.

2.3 Increasing TCP Backlog

TCP Backlog is considered to be the limit of the queue for the incoming TCP connections to the server. If the limit is overflowed with a barrage of illegitimate requests, the result is a TCP SYN attack. Now the mitigation strategy in this case is to increase the number of TCP backlog connection sockets so that the server tolerates the TCP SYN attack and still is able to provide services to the legitimate users. This step by itself should not be seriously considered as a means to defend against SYN flooding attacks—even in operating systems that can efficiently support large backlogs—because an attacker who can generate attack segments will most likely be able to scale to larger orders than the backlog supportable by a host [14].

2.4 Syn Cache

In the SYN-cache approach full TCB is not allocated immediately for the incoming TCP connections [16]. But when the opening request is received a minimal state is allocated to the requesting host. The full state allocation is done only when the full connection is established. During the TCP handshake process secret bits are selected from the incoming SYN segments. Hashing is done on these secret bits along with the socket (IP address + TCP port) of the segment. The calculated hash determines a location in the global hash table where the incomplete TCB is stored. There is a bucket limit for each hash value, and when this limit is reached, the oldest entry is dropped [5].

2.5 Syn Cookies

SYN-cookie [16, 17 and 19] also follows the similar approach of SYN-cache by not allocating the full TCB immediately for the incoming TCP connections. Unlike SYN-Cache no state is allocated at all for all the incoming SYN’s, but instead, the sequence number used in the SYN-ACK is filled with compressed information created from the basic data of the connection state. The data is encrypted into the sequence number and transmitted in the SYN/ACK packet. The ACK packet that completes the handshake can be used to reconstruct the state to be put into the backlog queue. One problem with SYN cookies is not able to encode all the TCP options, and the other is that TCP protocol with SYN cookies would never retransmit the unacknowledged SYN/ACK packet [18].

3. Attack Mitigation


The main objective is to differentiate between legitimate packets and the illegitimate packets. In order to separate the attack packets from the normal ones we make use of co-relational patterns. The phenomenon of existence of a co-relational pattern among the various parts of an IP packet header [27] is used in the mitigation technique to thwart TCP-SYN DoS attacks. The mitigation technique separates spoofed IP packets from the normal ones, based on the co-relation between TTL and IP address of the incoming packet and the destination port number reserved on the victim machine is also included in the mitigation technique.  .The mitigation technique is inspired from Hop Count Filtering [13], as explained in section 5.2.1. Before going into the proposed Victim Based Statistical Filtering we first discuss the existing Hop Count Filtering techniques used in the prevention of TCP-SYN DoS attacks in the next section.

3.1 Related Work

Wang et al proposed and proved the TTL based HCF algorithm [13 and 20] that separates spoofed IP packets from the normal ones with capturing rate of 90% of spoofed packets. Their HCF algorithm creates IP to HC mapping table and stores the mapping in an IP2HC table. Upon arrival the packets HC is compared to the HC stored for this IP. If the HC values match, then the packet is legitimate. Otherwise the packet is dropped. Wang et al also analysed the strengths and weaknesses of his filtering method in his work.

Xia Wang et al. [21] proposed a modification in the HC Filtering method. Instead of applying the HCF at the victim site, their technique emphasised on applying the HCF at in-between routers. With this technique they emphasised on not only protecting the victim but the entire network. Their results outperformed the Wang’s HCF technique.

StackPi detects the spoofed packets using a routing mechanism known as “path markers”. The StackPi marking scheme consists of two new marking methods that substantially improve Pi’s incremental deployment performance: Stack-based marking and Write-ahead marking [22]. The scheme performs 2–4 times better than the original Pi scheme in a sparse deployment of Pi-enabled routers.

An implementation of HCF inside the Linux kernel [23] presents a flexible solution against DoS attacks. A hash table is used to construct the IP2HC table in order to hide the IP to HC mapping of every single IP address from the machine

Work in [24] presents a simplistic 3-layer defense mechanism based on web servers against DoS attacks. And at the application layer a traffic limit is used for DoS attacks using legitimate IP.  All the transport layer malicious traffic is filtered by the algorithm of SYN Proxy Firewall. A majority of malicious traffic is filtered on network layer using HCF.

Work in [25] proposes a modification in the HCF technique and increases the accuracy of filtering by further 9%. This technique includes all valid HC’s seen in the learning phase. This variation enhances the overall accuracy compared to the original HCF and its variations.

The technique presented in [26] works by checking the packets until ‘n’ malicious packets have been received. Then, ‘m’ packets are allowed to go unchecked. Their analysis is based on probability of packet arrival ‘p’, number of malicious packets ‘n’, and number of legitimate packets ‘m’.

3.2 Mitigation Framework: Victim Based Statistical Filtering

The mitigation framework Victim Based Statistical Filtering (VBSF) presented here is basically a variation in the HOP count filtering (HCF) technique presented in [20]. The logic behind the hop count filtering is the fact that the packets upon arrival at the victim site do not contain consistent hop count values matching with the spoofed IP addresses. The technique works by analysing the incoming packet’s IP address and hop count and if any inconsistency is found, such a packet is deemed as spoofed and discarded accordingly. Hop Count Filtering works by building an accurate IP-to-hop-count (IP2HC) mapping table. The table is built during the alert phase, during which every IP packets header is analysed for any abnormality in the TTL field. During this phase certain legitimate packets may also get incorrectly identified as spoofed ones. Upon DoS attack detection the HCF changes its phases to action phase and every incoming IP packet is analysed for any mismatch using the IP2HC table and the mismatching ones are dropped accordingly.

The variation that we are proposing is adding the monitoring information of the usage levels of port numbers on the destination machine, in the HCF Algorithm. Before launching the TCP-SYN attack (set-up process of the DoS attack) the victim machine is scanned for open TCP ports. The attacker either targets a particular port in this list or random port numbers in the list. The point we are making here is that the DoS attack is going to be based on these open ports that resulted from the port scan.  The attacker would keep on hitting these port numbers with SYN’s and at the same time keep on changing (spoofing) the IP address as well. Now the defense framework VBSF presented here keeps an eye on the usage of these port numbers. Other than the well-known ports numbers all the hosts IP address requesting to SYN with the server on these port numbers will be suspected as spoofed ones and then a check would be made for the respective port numbers from the server constructed port-frequency-monitoring table and all originating requests from IP addresses trying to SYN with these ports numbers will be dropped accordingly.  The server here would analyse the port scan detection [29] [30] and maintain a list of open ports that it returned to such requesting hosts of the open port numbers.

In order to separate legitimate packets from the illegitimate ones, Victim Based Statistical Filtering (VBSF) employs correlation pattern. The concept of correlation here points out to the situation, when a legitimate packet travels from source to destination, certain number of interior characteristics take place at the same time. Given the IP Address distribution on the Internet [32], such a pattern can be seen between the requesting hosts IP address and the hop count. For example majority of the users (students) of Kashmir University website “www.uok.edu.in” are from the Kashmir region. During normal days a large number of users visit the website for the service required. During certain days a flash crowd can also be seen. But almost every time the majority (more than 90%) of the traffic is going to come from within Kashmir only. Therefore the Website of Kashmir University will have more IP packets containing correlations between visits of webpage and the IP addresses from Kashmir. A barrage of traffic originating outside of Kashmir will always be suspicious and the one originating is easy to filter out using the VBSF framework.

3.2.1 VBSF Algorithm

The Filtering algorithm extracts hop count, IP address from the IP header and destination port number from the TCP header of every incoming packet. Hop count is the number of router traversals made by the IP packet when it moves from source to destination. Hop count can be calculated using the Time to Live (TTL) field of the IP header. TTL is an 8-bit field in the IP header. The value of TTL is decremented by 1 every time the packet

Figure 4: TTL and hosts IP address extracted from IPV4 Header [34].

Figure 5: Destination port number extracted from the TCP Header [34].

traverses through a router; if the value reaches 0, the packet is dropped by the router. Hop count is calculated by subtracting the currently received TTL value of the IP packet, from the initial TTL of the IP packet, which is set by the Operating System. These initial TTL values are OS dependent and vary from OS to OS. Potential initial values of TTL across various operating systems (variants of Linux and Microsoft Windows) are 30, 32, 60, 64, 128, and 255 [20]. Given the relatively limited hop counts of 1-30 [28] between any two hosts on the internet it’s not that hard to guess the initial TTL value. After inferring the initial TTL value, hop-count is calculated by subtracting the final TTL value from the initial TTL value. After this the IP address of the packet is searched in the IP2HC table for the stored hop count of the packet. If there is a mismatch, the packet is deemed as spoofed, otherwise the packet is put forward for further processing.  The destination port number is extracted from the packet now and is searched and compared to the port numbers in the port-frequency-monitoring table. If there is a match, the packet is dropped. If there is no match the packet is a legitimate one and is granted entry. The algorithm is as follows:

Algorithm: Victim Based Statistical Filtering (VBSF)

4. Empirical Evaluation And Analysis


For the illustration of the victim based statistical filtering, a small scale experiment was conducted using a simple network topology as shown in Figure 6.6. The experiment focussed more on the evaluation and analysis of the proposed modification in the hop count filtering method [20] as the HCF part of the algorithm already stands as a well-established filtering present in the research and industry today.

Figure 6: setup for experiment

4.1 The Setup

The experiment was carried out under controlled conditions on a Local Area Network consisting of a server, 3 client computers and an attacker. The configuration of the machines are presented in Table 1. The server is the victim machine which is at the receiving end of the traffic generated by the attacker machine. There are 3 legitimate clients as well who want to access the services of the server machine. The server is running on VMware Player V7 [33], hosted on a Windows 8.1 machine (6.3 build 9600) with Intel® Core™ i5 2.8 GHz, 4 GB RAM.

Table no.1: System Configurations used in the Experiment.

The attacker launches the DoS attack from his machine which is running Kali Linux using a socket-stress testing framework Sockstress. The following configuration is used to bring havoc on the target machine:

Sockstress floods the victim with TCP-SYN requests by randomly picking up the port numbers mentioned in the above configuration. All these port numbers (reserved and others) are initially discovered on the victim machine using the port scanner nmap [3]. For the VBS filtering to work the victim system also has to maintain the list of open ports returned to the calling port scanner software. We achieved this by using the port scan firewall logs on the Windows server and populated the scanned port numbers from the files into a table, called the port-frequency-monitoring table. This table monitors the activity levels of the server ports. By using the logs and network port scan analyser software like wire-shark [31] the ports with maximum occurrence were filtered out and the frequency of occurrence was recorded in the port-frequency-monitoring table. There are better ways to analyse and extract the port scan logs on the victim machines [29] [30]. Coming back to the system configurations used in the experiment as Table 6.1 and the experimental as shown in Figure 6.6, we make the following assumptions:

  • As we have used different variants of Windows and Linux operating systems, we assume that the initial TTL is same in all the variants i.e. 255.
  • All the machines (server, legitimate clients and the attacker) are kept in the same subnet on purpose, to observe how the filtering is done if the hop-count and IP address values match with the legitimate clients.

Figure 7: Outline of VBS Filtering Framework.

Now during the alert phase of the HCF method, in absence of the attack the IP2HC table changes as follows:

Table 2: IP2HC table during the alert phase .

During the action phase of the HCF method, in presence of the attack the IP2HC table changes as follows:

Table 3: IP2HC table during the action phase.

It is worth to notice the spoofed IP address of the attacker, changing from 192.168.0.120 to 192.168.0.159 (as configured in the Sockstress, the IP is spoofed randomly between 192.168.0.150- and 192.168.0.175). In spite of the changed IP address of the attacker the spoofed address still falls in the same subnet as others. Therefore the simple HCF algorithm would treat the traffic from the attacker as legitimate just like other traffic. The VBS filtering is a step ahead of HCF, now after initial policing of the packet, the algorithm looks into the port-frequency-monitoring table for any matching destination port numbers. Upon arrival of the packet at the server premises the destination port numbers.Upon arrival of the packet at the server premises the destination port number Px is hooked off and then searched for any matching port number (Ps) in the port-frequency-monitoring table. Table 4 contains the values;

Table 4: port-frequency-monitoring table .

Clearly there is a match and all the entries in Table 4 would point the finger of suspicion in the direction of the IP packet of the attacker, because it is from the attackers IP and TCP header that the information matched to that in the port-frequency table. Such matching packets will be discarded immediately by the Victim Based Statistical Filtering Framework. In other cases had the attacker been from a different area the HCF would have shown a different profile in the table and would have discarded the packet much before reaching for a comparison in the port-monitoring-table.

6. Conclusion


With the modification of using destination ports with the HCF method, the Victim Based Statistical Filtering framework shows promising scope to thwart TCP-SYN exploits. But firstly, the framework needs to be implemented, tested and analysed in a live scenario to observe its actual performance over the already effective HCF filtering and other filtering techniques. The VBS filtering mechanism relies heavily on two things:

  1. Monitoring the activity levels of destination port numbers of the victim.
  2. The time quantum under which the activity levels of the port numbers can be analysed.

In order for the VBS filtering technique to show better results than the HCF technique, it is mandatory to extract the port scan logs efficiently from the victim machine and make the data available for storage and further analysis. Generally, victims are very reluctant to show and distribute the information in logs to third parties due to their sensitive nature or potential for violation of any privacy laws, but given the dependence of the VBS Filtering technique on the information in logs, it is necessary to come up with schemes and methods that would ensure the security of log information as well as assist in making filtering of malicious traffic more efficient.

The time quantum of analysing a port number for activity levels is still an un-answered question in this work. The observation is based assumingly on recording the activities for  -60 seconds only, while the optimum time scale needs to be developed keeping in view certain factors like, capturing for longer durations  resulting in the legitimate port use falling in as false positives and much smaller time quantum resulting in false negatives. Therefore an appropriate time quantum needs to be developed for the functional success of the technique.

References


[1]     Douligeris, C., & Mitrokotsa, A. (2004). DDoS attacks and Defense mechanisms: classification and state-of-the-art. Computer Networks, 44(5), 643-666.

[2]     Highland, H. J. (1988). The BRAIN virus: fact and fantasy. Computers & Security, 7(4), 367-370.

[3]     Lyon, G. F. (2009). Nmap network scanning: The official Nmap project guide to network discovery and security scanning. Insecure

[4]     Connolly, P. J. (2001). Security protects bottom line. InfoWorld, Vol. 23, No. 15, p. 47.

[5]     Eddy, W. M. (2007). TCP SYN flooding attacks and common mitigations.

[6]     Killalea, T., “Recommended Internet Service Provider Security Services and Procedures”, BCP 46, RFC 3013, November 2000.

[7]     Ferguson, P. and D. Senie, “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing”, BCP 38, RFC 2827, May 2000.

[8]     Baker, F. and P. Savola, “Ingress Filtering for Multihomed Networks”, BCP 84, RFC 3704, March 2004.

[9]     Peng, T., Leckie, C., & Ramamohanarao, K. (2003, May). Protection from distributed denial of service attacks using history-based IP filtering. In Communications, 2003. ICC’03. IEEE International Conference on (Vol. 1, pp. 482-486). IEEE.

[10]   Park, K., & Lee, H. (2001, August). On the effectiveness of route-based packet filtering for distributed DoS attack prevention in power-law internets. In ACM SIGCOMM computer communication review (Vol. 31, No. 4, pp. 15-26). ACM.

[11]   Li, J., Mirkovic, J., Wang, M., Reiher, P., & Zhang, L. (2002, June). SAVE: Source address validity enforcement protocol. In INFOCOM 2002. Twenty-First Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE (Vol. 3, pp. 1557-1566). IEEE.

[12]   Abliz, M. (2011). Internet denial of service attacks and defense mechanisms. University of Pittsburgh, Department of Computer Science, Technical Report, 1-50.

[13]   Wang, H., Jin, C., & Shin, K. G. (2007). Defense against spoofed IP traffic using hop-count filtering. IEEE/ACM Transactions on Networking (ToN), 15(1), 40-53.

[14]   Eddy, W. M. (2006). Defenses against TCP SYN flooding attacks. The Internet Protocol Journal, 9(4), 2-16.

[15]   Gont, F. (2011). Reducing the TIME-WAIT state using TCP timestamps.

[16]   Lemon, J. (2002, February). Resisting SYN Flood DoS Attacks with a SYN Cache. In BSDCon (Vol. 2002, pp. 89-97).

[17]   “SYN cookies.” [Online]. Available: http://cr.yp.to/syncookies.html

[18]   Sun, C., Fan, J., & Liu, B. (2007, August). A robust scheme to detect SYN flooding attacks. In Communications and Networking in China, 2007. CHINACOM’07. Second International Conference on (pp. 397-401). IEEE.

[19]   Al-Duwairi, B., & Manimaran, G. (2005, March). Intentional dropping: a novel scheme for SYN flooding mitigation. In INFOCOM 2005. 24th Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings IEEE (Vol. 4, pp. 2820-2824). IEEE.

[20]   Jin, C., Wang, H., & Shin, K. G. (2003, October). Hop-count filtering: an effective defense against spoofed DDoS traffic. In Proceedings of the 10th ACM conference on Computer and communications security (pp. 30-41). ACM.

[21]   Wang, X., Li, M., & Li, M. (2009, December). A scheme of distributed hop-count filtering of traffic. In Wireless Mobile and Computing (CCWMC 2009), IET International Communication Conference on (pp. 516-521). IET.

[22]   Yaar, A., Perrig, A., & Song, D. (2006). StackPi: New packet marking and filtering mechanisms for DDoS and IP spoofing defense. IEEE Journal on Selected Areas in Communications, 24(10), 1853-1863.

[23]   Mopari, I. B., Pukale, S. G., & Dhore, M. L. (2008, December). Detection and defense against DDoS attack with IP spoofing. In Computing, Communication and Networking, 2008. ICCCn 2008. International Conference on (pp. 1-5). IEEE.

[24]   Wu, Z., & Chen, Z. (2006, October). A three-layer defense mechanism based on web servers against distributed denial of service attacks. In Communications and Networking in China, 2006. ChinaCom’06. First International Conference on (pp. 1-5). IEEE.

[25]   Mukaddam, A., Elhajj, I., Kayssi, A., & Chehab, A. (2014, May). IP spoofing detection using modified hop count. In Advanced Information Networking and Applications (AINA), 2014 IEEE 28th International Conference on (pp. 512-516). IEEE.

[26]   Swain, B. R., & Sahoo, B. (2009, March). Mitigating DDoS attack and Saving Computational Time using a Probabilistic approach and HCF method. In Advance Computing Conference, 2009. IACC 2009. IEEE International (pp. 1170-1172). IEEE.

[27]   Chen, Q., Lin, W., Dou, W., & Yu, S. (2011, December). CBF: a packet filtering method for DDoS attack defense in cloud environment. In Dependable, Autonomic and Secure Computing (DASC), 2011 IEEE Ninth International Conference on (pp. 427-434). IEEE.

[28]   Cheswick, B., Burch, H., & Branigan, S. (2000, June). Mapping and visualizing the Internet. In USENIX Annual Technical Conference, General Track (pp. 1-12).

[29]   Muelder, C., Ma, K. L., & Bartoletti, T. (2005, September). Interactive visualization for network and port scan detection. In International Workshop on Recent Advances in Intrusion Detection (pp. 265-283). Springer Berlin Heidelberg.

[30]   Jung, J., Paxson, V., Berger, A. W., & Balakrishnan, H. (2004, May). Fast portscan detection using sequential hypothesis testing. In Security and Privacy, 2004. Proceedings. 2004 IEEE Symposium on (pp. 211-225). IEEE.

[31]   Wireshark. (2017, January 5). In Wikipedia, the Free Encyclopedia. Retrieved 18:36, January 21, 2017, from https://en.wikipedia.org/w/index.php?title=Wireshark&oldid=768792980

[32]   Rekhter, Y., & Li, T. (1993). An architecture for IP address allocation with CIDR.

[33]   Bugnion, E., Devine, S., Rosenblum, M., Sugerman, J., & Wang, E. Y. (2012). Bringing virtualization to the x86 architecture with the original vmware workstation. ACM Transactions on Computer Systems (TOCS), 30(4), 12.

[34]   Postel, J. (1981). Transmission control protocol.

[35]   Forouzan, B. A. (2010). TCP/IP protocol suite, E4. McGraw-Hill, Inc.

 

 

%d bloggers like this: