{'fraction_non_alphanumeric': 0.022116408746319153, 'fraction_numerical': 0.004009773823695257, 'mean_word_length': 4.602667602667602, 'pattern_counts': {'":': 0, '<': 1, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
An Indigenous Solution for SYN Flooding

SYN flooding is one of the most challenging problems that many networks applications face, particularly those that are security-related. Disrupting a server's daily function and assigning it to other tasks leaves it a constantly busy server that processes little usable data. In this research, a comprehensive INDIGSOL approach is demonstrated that not only detects SYN flooding but also prevents the attacker(s) from making such attempts in the future. The designed approach has four modules such as node registration and validation, packet capturing, dynamic check system, and hook activation. The approach is further checked and compared with some state-of-the-art baselines on various parameters like detection time, response/processing time, and number of malicious packets detection. It is observed that INDIGSOL performed better than other baselines with an average accuracy of 99% malicious packet detection in six scenarios along with 13.4% faster detection time and 11.2% faster response/processing time. Overall, the provided solution is scalable, robust, and highly accurate that prevents SYN flooding in a timely manner.


Introduction
TCP is a stable, connection-oriented transport protocol. The TCP's job is to keep the network's intricacies hidden from the upper layers. Until data can be shared, the two hosts involved in a conversation must first create a link, according to the connection-based protocol. The three-way way, so mail-bombing DoS attacks succeed. The ICMP ECHO command takes advantage of the fact that most kernels can actually respond to ICMP ECHO request packets one by one. Because of the current implementation of TCP's link establishment protocol, the flooding TCP SYN DoS attack's function prevails [9]. A flooding attack is initiated by sending a huge number of packets to the victim in order to overwhelm one or more of the victim's resources and reduce network capacity, often to the extent that the networks can no longer be used [10]. The so-called attacks are usually DDoS attacks that employ amplifiers to boost their strength. Flooding attacks come in a variety of forms, each based on a particular protocol: • TCP/IP protocols: ICMP, UDP, TCP, IP • Application protocols: HTTP, FTP, DNS However, these attacks can be carried out using a variety of protocols; the most common are those that use ICMP and UDP packets, which do not require the setting up of a connection between the communicating entities. The primary aim of these attacks is to consume the victim's bandwidth before causing any of the victim's systems to go down. The victim may be a single host or a whole IP network, which is critical. To detect this type of attack, metrics parameters such as throughput, number of packets, and number of bytes are used [11]. The proposed solution named as INDIGSOL (Indigenous Solution) is designed and implemented to prevent the SYN flooding in real environment. This solution has four modules namely: 1. Node registration and validation 2. Packet capturing 3. Dynamic checksum 4. Hook activator INDIGSOL has the capability to both detect and prevent SYN flooding in a dynamic environment as the system has been thoroughly tested with number of scenarios. In this solution, every node needs to get register in the database. The provided defense system keeps a check on the network nodes dynamically and looks for live clients after fix intervals of time. Now once the network is on its routine work it will keep a check on all the incoming traffic towards that specific Server and thus will always be alert for any sort of anomaly. The packet is initially monitored to see whether it is arriving from the legitimate node or not, in case of legitimate it is forwarded whereas illegitimate packet is discarded and informed to the user. Secondly, it also checks for number of SYN from every user and if goes beyond limit, it will start discarding the packets. Overall, INDIGSOL provides very comprehensive and efficient solution in preventing the SYN attack as compared to number of state of art baselines.  [13]. Each and every device that is linked to the Internet has the possible vulnerability of the SYN attack based on TCP-based network services. In comparison to the threats on the specific servers, these attacks may also be directed at individual hosts. If these hosts are on the routers or other network server, other TCP services should be enabled. The attack significance may be overstated. Depending on the method, the attack can differ; however, the attack itself is the same. The TCP protocol is being used by all applications is fundamental [14]. Following are the main contributions of this research: • To identify the potential vulnerable host/hosts facing SYN flooding.
• To implement a strong monitoring system that would prevent host/hosts/devices in getting attacked by the SYN attack.
• To keep track of the illegitimate traffic so that prevention mechanism be assured in future communication.
The rest of the research is organized as section two provides literature review, methodology is in section three, section four details about results and discussions and lastly conclusions are in section five.

Literature Review
This section is providing brief overview of different TCP header components, properties and state of the art techniques used to prevent SYN flooding. Tab. 1 shows various acronyms used in this research as below: ports so that they can be seen on any device with a common port. TCP port 23 is used for the telnet daemon.

TCP Memory Structures and the Backlog
It's important to look at the memory structures that TCP produces when a client SYN arrives and the link is pending ( 4. Sock Structure (sock()): It includes protocol specific information because most of the data structures are using TCP.
5. SK Structure (sk_buff()): It contains protocol specific information comprising of packet header information and a sock().

Backlog Queue
There are a lot of memory structures here. They must be allocated any time a client SYN arrives on a legitimate port (a port where a TCP server is listening ()). A busy host could quickly and it refers to the length of the queue where incoming (but unfinished) connections are stored. This queue cap extends to both the number of missing connections (the 3-way handshake hasn't been completed) and the number of completed connections that the application hasn't taken from the queue through the approve () call. If this backlog cap is exceeded, TCP will quietly reject all incoming link requests before the pending connections are resolved [20]. The backlog is not a significant amount of work. TCP is normally very quick when it comes to establishing connections. If a link arrives before the queue is complete, the receiving TCP would more likely have space in its queue when the client retransmits the connection request section. The queue sizes of various TCP implementations vary.
There is also a 3/2 'grace' margin in BSD style networking code. TCP can support up to backlog3/2+1 connection and if it calls listen with a backlog of 0, this will cause a socket to make one link [21].
There are few common backlog values as mentioned in the following Tab.2: It's necessary to watch as the receiving TCP processes an incoming section to see just how the attack operates. For BSD-style networking, the following is valid, and only processes applicable to this paper are discussed [22]. When a packet arrives, it is demultiplexed and sent up the protocol stack to TCP, which is in the LISTEN state. To go along with the ever-present network security threat of SYN flood, the Microsoft has devised its own approach, such as avoiding RAW sockets, it is not believed that this is the best solution [27]. Anyone from everywhere, regardless of privileges or access rights, will make YAHOO Out of Bounds to all of us in the vast dark world of the Internet. Imagine that the PING command is regarded by all of us as a fast search of operation, but no one is aware of the havoc it causes on the receipting end. TCP SYN Flood is the same concept; it was and continues to be a source of concern for most network tycoons.
An attacker first attempts to create a link with the server, after which he attempts to send any bogus TCP packets to the server in such a manner that all of these packets request the creation of a connection with that server. However, any clever server will never allow a client to request more than a certain number of connections, necessitating the attacker's implementation of the spoofing principle, and therefore someone spoofs itself any time he requests a connection, thus filling up the server's

Problem Description
The TCP SYN Flood always remains a matter of great concern in the Internet world.
Generally speaking, there has never been provided a full-fledged and multidimensional solution to this problem. Most of the solutions available deal specific issues or aspects of the flooding process. transmission to begin. The intended TCP, however, cannot complete the 3-way handshake when the client IP address is spoofed to be that of an unreachable host and will continue trying until it clocks out. That is the attack's foundation. The attacking host sends a few SYN requests to the target TCP port (we found that as few as six are sufficient) (for example, the telnet daemon). The attacking host must also spoof the source IP address to that of another, currently unreachable host (the target TCP would send its response to this address). TCP will be notified that the host is unreachable by IP (via ICMP), but TCP finds these errors to be temporary and leaves the resolution to IP (reroute the packets, etc.) essentially ignoring them [48]. Since the intruder would not allow *any* host to receive the SYN/ACKs that would be coming from the target TCP, which will evoke a RST from that host, the IP-address must be unreachable. The threat will be thwarted. The steps are as follows: The invading host sends a slew of SYN requests at (1). to the aim of filling the target's backlog queue with pending requests interconnections (2)   In fact, we can found out whether a client is alive or dead by sending an ICMP echo request.
Below are details provided by an ICMP echo request:  Figure 6 depicts the situation more clearly.

The Solution
The provided defense system keeps a check on the network nodes dynamically and looks for live clients after fix intervals of time. Now once the network is on its routine work it will keep a check on all the incoming traffic towards that specific Server and thus will always be alert for any sort of anomaly. Basically, the sole purpose of this system will be to look for the SYN packets. Once a SYN packet arrives at the server so before it ids handed over to the destined application it is analyzed whether is coming from the valid node or not. If it is from a valid node so it is forwarded to the desired application without any delay, otherwise it is immediately discarded and the user is informed that it has discarded an illegal packet which was most probably destined to look for a valid server and then impose an attack [56]. The second way or policy which it implements is that if suppose the packet is coming from a legal client so it is let to go but it then checks for number of SYN packets coming from that specific application per time and thus if the ratio goes above a fixed limit so it is considered as a suspicious act and the system gets more tight. Now if even a single SYN packet above the specific number is received so the client is immediately paralyzed by its extreme defense system and he is unable to send even a single SYN packet [57]. At the same time the user is informed that it has stopped that specific client from doing so and has made him an illegal or suspicious user. The basic purpose of this defense system is only to provide an effective and in time solution to TCP SYN Flood attack. Thus, we worked out on different modules independently in order to make it one of the most efficient and up-to-date solution. Different modules are organized and arranged independently, and this is the key to its being and efficient and responsive. it was our utmost wish that we should come up with a module and efficient response system and it was only possible when we worked out thoroughly on its design process by identifying its major modules and their interrelationship.
Implementation Modules: The whole defense system consists of the following major modules which are inter related in such a way that the provide the maximum functionality: System would dynamically search for the live nodes and would make their entry in the database then on the basis of this entry it will decide the fate of all the incoming packets.

Node Registration and Validation Module
This is the 1st and foremost operation performed by the system whenever executed by administrator. As discussed earlier the system goes through the available database and also let the user if he wants to introduce a new node into the database. Now whenever the user makes an entry of a node IP address so it tries to validate its authenticity by executing a ping and ARP request on that specific IP address. Further, the user gives an IP address which generate Message "Node Not Found" which means that an error has been occurred in the validation process.
Error: Node Not Found If all the above cases do not exist, then it means that user has entered a valid IP address. So, the next steps this module will perform is to trace out the MAC address of this IP address. When MAC address is traced out, its entry is entered in the back end database.

Packet Capturing Module
After

Dynamic Check System Module
The dynamic check system module gets activated once the packet is captured. This is the main area where the SYN flood Detection policy has been implemented and also the required defense system is defined. This makes it core area which goes through many inner modules including activating other modules on the server as well as synchronizing with that specific client which is either flooder or acting as a flooder (hijacked by an attacker).

Hook Activator
Once a packet has been identified for being a member of flood, then before the next packet may reach the destination, the active hooks are activated. They are responsible for discarding all the incoming traffic from that specific client. One of the main features implemented by our security system is that it not only stops all the traffic coming from that node but also totally paralyzes that client and would no more be able to generate any flood.

Results and Discussion
The System is tested with respect to various factors like Detection time, Processing time, and Diagnosis. Some of the factors were responding slowly in start but with some changes they get better and were efficient enough to tackle the situation [58]. There are various factors which help to determine the performance in the real scenario. These are SYN attack detection time, response/processing time for the packet and detecting attacking packets. The comparative performance of the three factors is reflected in Figures 14, 15   It is visible that the p-values in all three cases are less than the significance level of <0.05, which states that their exist a significant difference between IDIGSOL and baselines. The null hypothesis H0 is rejected and alternate hypothesis H1 is there accepted.

Conclusion
The availability of computing resources is important to perform useful operations. SYN flooding over the years is one of the major securities problems that opens large number of half open TCP connections and making the server all time busy. This will result in unavailability of computing resources to the legitimate users. In this research, INDIGSOL approach is proposed as a defense system that monitors and stop SYN flood packets at the origin. The adopted approach is an efficient