A COMBINATION OF THE INTRUSION DETECTION SYSTEM AND THE OPEN-SOURCE FIREWALL USING PYTHON LANGUAGE
Tuan Nguyen Kim1, Tam Nguyen Tri2, Lam Tran Nguyen2 and Duy Thai Truong2
1School of Computer Science, Duy Tan University, Danang, Vietnam
2Danang ICT Infrastructure Development Center, Danang, Vietnam
ABSTRACT
There are many security models for computer networks using a combination of Intrusion Detection System and Firewall proposed and deployed in practice. In this paper, we propose and implement a new model of the association between Intrusion Detection System and Firewall operations, which allows Intrusion Detection System to automatically update the firewall filtering rule table whenever it detects a weirdo intrusion. This helps protect the network from attacks from the Internet.
KEYWORDS
Firewall, Rule table, Intrusion detection system, Sniff, Packet capture.
1 INTRODUCTION
The enterprise network security model is responsible for monitoring every flow of traffic and every packet in/out of the network, to detect unauthorized intrusions and packets that may come from legitimate sources but are at risk of carrying malicious code into the network [1]. When an unusual activity is detected in some traffic, Intrustion Detection System (IDS) takes immediate action, such as disseminating information about irregularities or sending irregularity notifications to other systems, including the network’s security administrator. It’s worth noting that IDS is simply in charge of detecting and issuing warnings; other elements are in charge of dealing with problems. Firewalls commonly do this under the direction of the security administrator’s law table. Obviously, this stage seems to be inactive; however, because upgrading the rule table takes time, it should be considered for improvement to increase the efficiency of network protection for organizations and companies [2].
Package Filters and Package Filtering Rules are two of the three key components of package filter firewalls, according to this definition. The cyber security management team will create a package filtering rule table for firewalls based on the network access control policy. This Rule table is used by package filters to manage network access policies. This means that the ability to identify the situation of network access to bring new laws and the speed with which the cyber security administrator updates the rule board for the firewall is important to the timely level of avoiding undesired traffic flows [3]. As a result, if we develop a firewall support system that can detect traffic flows, packets with suspicious actions, and automatically updating the package filtering rule board for the firewall, the firewall will perform better and prevent harmful traffic. This is something that the host-based IDS [8] self-made software can deal with.
Firewalls and IDS can both be hardware devices or software programs. The firewall is selected as the open-source IP Tables technology in our suggested model. IDS is a Python-based Sniffer program that we created. This is considered the article’s main contribution.
As a result, IP Tables [6] conduct network access control activities while also being prepared to receive instructions from Sniffer to change the packet filtering rule table. After passing through IP Tables firewall, traffic lines and packets are delivered to Sniffer, who collects and recovers the necessary information, analyzing, statistics, and forecasting to discover the origin of the traffic, of the suspicious packet. Then, automatically, and instantly, the IP Tables rule board is updated. Under this new rule table, the IP Tables firewall will make an access control decision. The system we propose has this as its target.
The benefit of open-source firewalls [10], such as IP Tables, is that we can easily change their rule table (packet filtering rule file, to be precise), which is made simple by the Python program. This is one of the reasons why we consider auto-updating packet filtering rules for open-source firewalls.
2 RELATED KNOWLEDGE
In this section, we’ll summarize the most basic information regarding two cyber security technologies that are necessary in today’s high-security enterprise networks: Firewalls and IDSs. This is required so that the meaning of the combination in their functioning in the network model that we present in this article may be simply understood (in section 3).
2.1. The packet filtering firewall’s functioning principle
A firewall is a network access control device that also functions as an in/out network port (commonly referred to as a network gateway). As a result, all traffic flows in and out between external networks, most commonly the Internet, and the enterprise’s internal network are subject to the Firewall’s supervision and control. To determine whether a traffic/packet flow is allowed to pass through a firewall, it uses a network access policy, which is designed as a Policy Rule Table, and the appropriate information contained in the traffic/packet flow – usually IP Address, Protocols, and Port number.
Figure 1. The network diagram with the existence of the firewall
Firewalls are divided into two types based on their operation principles. They are the filtering firewall (Packet filtering firewall) functioning at the Network layer of the OSI or TCP/IP network model and the Application layer firewall (also known as Proxy) working at the ‘Application’ layer of the network model. Nowadays, enterprise networks often use a firewall that combines the operation priciples of these two types of firewalls.
The unit that manages the in/out of the news; package survey filters, also known as Packet Filters; and package filtering rules are the three primary components of the firewall filter package. The Packet Filter uses the package filtering rule table, which was put by the cyber security administrator into the firewall, to decide whether to allow the packet to get through to its destination or not.
Figure 1 represents an enterprise network with a package filter firewall acting as a network gate. Every packet from the Internet to the corporate network, as well as from the internal network to the Internet, must pass through the firewall.
The network access policy of this enterprise network can be seen in the network diagram: Only packets from the Internet are allowed to enter network zone 192.168.2.0/24, the enterprise network’s DMZ (DeMilitarized Zone) zone; packets from the Internet are not allowed to enter network zone 192.168.1.0/24, the user network area inside. Any traffic flow from the user network zone and the DMZ network zone, on the other hand, can reach the Internet. The cyber security administrator standardizes this policy into packet filtering laws, which are then constructed into the Package Filtering Rule Table (shown in the diagram) and deployed on the firewall. Before the new network access control policy takes effect, the cyber security administrator must update the Package Filtering Rule Table for the firewall.
The network access policy of this enterprise network can be seen in the network diagram: Only packets from the Internet are allowed to enter network zone 192.168.2.0/24, the enterprise network’s DMZ zone; packets from the Internet are not allowed to enter network zone 192.168.1.0/24, the user network area inside. Any traffic flow from the user network zone and the DMZ network zone, on the other hand, can reach the Internet. The cyber security administrator standardizes this policy into packet filtering laws, which are then created into the Package Filtering Rule Table (shown in the diagram) and installed on the firewall.
2.2. Principle of Operation of Intrusion Detection System
According to [4], IDS is a network access monitoring system that can be a hardware device or a software application. It can be a hardware device or a software program. It’s responsible for monitoring traffic flows into and out of the network, or to a specific computer on the network, to discover and notify relevant departments about unusual access, unlawful access to the network system, or to specific machines on the network.
Figure 2. A network diagram with Network-based IDS and Host-based IDS in the background
In fact, IDS can detect and analyzing all user and system actions, as well as reviewing system files, configuration files, and operating systems. It can also check the integrity of system and data files, discover problems in the system’s setup, and detect and issue warnings if the system is at risk. IDS, in particular, may analyze trends based on known attacks.
IDS provides a variety of advantages, including ease of deployment in an existing company network without disrupting the current network, and the ability to provide rapid and varied warnings regarding problems. The potential of an IDS to detect unexpected traffic flows and suspicious actions can aid systems and administrators in detecting and preventing multiple network attacks. System administrators can simply modify IDS’s “what needs monitoring” by modifying its “signature set” (with signature-based IDS type). IDS can also log, identify, and report on changes to important files on computers connected to the inland network. However, IDS has several limitations, such as the ability to deliver false positive or false negative warnings to the system regarding irregularities and suspicions, which can negatively affect the system’s normal operation. The ability of an IDS to examine encrypted packets is likewise restricted, and therefore does not assist in discovering the source of a network attack. Like other cyber security systems/network services, IDS can be hacked via DoS (Deny of Service) and “misleading” attacks.
The differences between IDS and IPS (Intrusion Prevention System) cybersecurity systems should be clear. They read and analyze network packets before comparing them to known attacks known as “signature set” (also known as signature episodes, or threads). While IDS merely detects unusual packets and issues warnings, IPS is an access control system that can accept or reject a packet depending on a set of rules. IDS requires people and/or another system to view the results and take action, whereas IPS just requires regular updates to known threats and the addition of new threats.
When IDS is needed to monitor traffic both going in and out across the network, it can be placed between the firewall and the router (Internet connection); it can be placed in the DMZ zone: when only ids monitor traffic entering the DMZ zone; or it can be placed behind the firewall (right in front of the inner network): when IDS is needed to monitor traffic between the internal and external networks. HIDS is often installed on each server in the DMZ zone to monitor and warn of unusual access or suspicious activity.
Host-based IDS (HIDS), Network-based IDS (NIDS), Protocol-based IDS (PIDS), Application Protocol-based IDS (APIDS), and Hyber IDS are the five most popular types of IDS (HyIDS). In terms of where IDS is located in the network or scope, whether it’s on the entire network or just one computer, and how it monitors traffic flow, there are two main types: HIDS and NIDS.
The main difference between these two types of IDS can be noticed in the fact that signature based IDS uses a known signature set to detect irregularities. Anomaly-based IDS, on the other hand, detects irregularities based on “normal” traffic.
Figure 2. shows a business network diagram that combines both NIDS and HIDS. HIDS is installed on servers in the DMZ zone (Web, File, Mail) in this network to detect any illegal or unexpected access to these servers. NIDS is installed behind the firewall to monitor all traffic entering and exiting the network.
When a network traffic flow passes through it, the signature-based IDS type operates as follows: it copies the traffic and then separates the necessary information in headers and/or payloads from it. The IDS then proceeded to “match” this information against a database of known threats. If a “match” is identified, IDS notifies the appropriate systems. When the IDS detects a new irregularity or a new threat from traffic flowing through it, the database is updated to prepare for future “matching”. The Anomaly-based IDS type observes all traffic flows passing through first, acquiring important data to determine “normalcy.” Then rely on “this normality” to find the “irregularities” hiding inside it. This sort of IDS is extremely good at detecting new threats, “new attacks,” but it need “intelligence” to do so [7].
3 THE PROPOSED MODEL
3.1. Network model
Figure 3 depicts our proposed model, which is based on an operational combination of firewall and Host-based IDS:
Figure 3. A network diagram with a firewall and Host-based IDS in use
In this model:
The proposed model has a new feature in that we have established a connection in the operation and completed the task assigned between the Sniffer program and the open-source firewall IPTables: Once the origin of the traffic or packet line is determined to be abnormal or suspected of acting suspiciously, Sniffer immediately sends a command to IPTables to update the rule table filters its packets. This new package filtering rule table will use firewall IPTables to prevent unwanted traffic flows and packets from accessing the network.
The benefits of the proposed model are obvious: in addition to the usual functions of a specialized IDS, Sniffer is totally proactive in automatically modifying the package filtering rule table on the IPTables firewall. This not only helps to prevent the organization’s plan to sabotage the network from the Internet from happening, but it also helps the cybersecurity administrator save time [9].
3.2. Related work
First, we do the necessary work to put the proposed model’s network into operation, as designed. We then proceed to establish the IPTables Firewall Package Filtering Rule Table in accordance with the network access policy, in which we direct all traffic lines through IDS, the sniffer program runner, after passing through the IPTables firewall.
Our main contribution is not only to propose a novel model combining IDS and Firewall, but also to provide a Python-based Sniffer software. The major functions of the Sniffer program are as follows:
– Function process_packet(): Sniffer’s process packet() function is responsible for copying all packets going through the specified ports (specified in the files: Listports and Blacklist). Then, from the header of this packet, obtain the necessary details, such as the packet type (TCP or UDP), source IP address, source port, and so on. The function test for active will take this data as an argument.
– Function test_for_active(): This function compares the contents of packets received from the proceeded packet with the contents of Listports and Blacklist. If a match is identified from a specific traffic or packet, Sniffer counts how many times it appears; if the number of times exceeds the defined threshold, test for active updates the IPTables rules to prevent the traffic from going online. This function is also in charge of detecting and notifying suspicious traffic flows, which are often traffic flows provided in large from a single IP address or many IP addresses to Sniffer.
– Function setup_logfile(): Set the logfile parameters that Sniffer uses to save information about the traffic, packets that it is specified to pay attention to during observation with the setup logfile() function.
– Class limitedPool: This class contains the functions init_ and _setup queues. In multithreaded processing cases, the function init_ performs the initial construction of queues for ThreadPools. We’ve set a maximum queue size of 10,000 people (containing 10000 threads). The setup queues function is used to configure queue parameters.
– Sniffer was able to handle all the packets supplied to it thanks to Python’s support [5], even when up to 10,000 packets were sent at the same time.
– update rule iptables.py program: This firewall, which is based on the SSH protocol, which is used by Sniffer to deliver commands to IPTables, must update the rule table to block packets containing strings that Sniffer considers are a threat to the internal network system. Sniffer uses these two functions to transmit commands to change IPTables, ensuring that traffic flows and undesirable packets are prevented from accessing the network.
– And report2email.py program, which is based on the SMTP protocol and is used by Sniffer to send emails to cybersecurity administrators with the content of unusual notifications.
3.3. Testing and evaluation of the proposed model
We set the proposed model to the test in three different scenarios: Scenario 1: String filtering test This scenario is designed to see how well Sniffer and IPTables work together in alerting and stopping packet lines that contain a string that has been flagged for attention and is on the blacklist.
The result is as expected: if many packets come into the Sniffer, and their payload contains the same string recorded in the blacklist, these packets will be blocked by IPTables immediately for a set length of time.
As a result, if there is a large amount of traffic, go into a sniffer, which has the same source IP address, within a certain period, IPTables will quickly stop this traffic stream.
Not surprisingly, if a significant number of packets TCP SYN, go into sniffer, within a given length of time, the traffic line with this initial initialing packet is immediately blocked by IPTables.
We also performed an operational coordination performance assessment between Sniffer and IPTables during the testing procedure. To check the filtering and packet blocking results of the proposed model, we use the Tcpdump and Wireshark tools:
Table 1. The packets received on the IPTables firewall
Table 2. The packets received on the Sniffer server
As a result of Tcpdump, packets containing the strings “ls – ls” were blocked in IPTable during sniffer and IPTables.
Table 3. Packets TCP_SYN and RST, ACK
During the TCP “3-step shake-up”, usually, every time the destination party receives a packet [TCP_SYN] it must immediately send a response packet [TCP_RST, ACK]. But here, due to suspicion of a SYN_Flood DoS attack, Sniffer asked IPTables to restrict response to connection initiation packets [TCP_SYN]. This has been proven by Tcpdump.p.
Table 4. IPTables firewall packets received
Table 5. The packets received on the Sniffer server
As a result of Sniffer and IPTables’ views and actions, packets from IP: 10.7.7.100 (in large quantities) were blocked in IPTables, according to Tcpdump.
Because most open-source firewall systems allow command-line interaction, our usage of IPTables in our test and evaluation scenarios does not compromise the general validity of the proposed model.
From the results of the assessment, we are confident that the proposed system can completely play a role in detecting and illegally entering the enterprise in-house network such as IDS systems and other individual firewalls in the information security product market.
4 CONCLUSION
In this paper, we propose a new model for merging the operations of IDS and open-source firewall IPTables, which we have successfully implemented. We’ve also created a Sniffer software that acts as the network system’s IDS. This rule table change is completely automated; therefore, it happens extremely quickly.
The accuracy of making a statement about the suspicious actions of an IDS depends on the collection and analysis of information, from the flow of traffic into/out of the network and depends on its statistical and forecasting capabilities. It can be said that the “intelligence” of this department determines so greatly the accuracy in determining which traffic flows are suspicious actions among the many traffic flows passing through IDS. Also, with the increasing ability to “fake” and “deceive” hackers in cyberspace, without high “intelligence”, IDS is difficult to determine exactly whether a packet is carrying malicious code or not. Our Sniffer’s limitation is that it has a low “intellect.” Sniffer’s “intelligence” will be improved in the future by moving it toward a Machine Learning approach.
CONFLICT OF INTEREST
The authors declare no conflict of interest.
REFERENCES
[1] Kanika & Urmila, (2013) “Security of Network Using IDS and Firewall”, International Journal of Scientific and Research Publications, Vol. 3, Iss. 6, pp.1-4.
[2] Waleed Bul’ajoul, Anne James & Mandeep Pannu, (2015) “Improving network intrusion detection system performance through quality of service configuration and parallel technology”, Journal of Computer and System Sciences, Vol. 81, Iss. 6, pp. 981-999.
[3] Sulaman & Sadar Muhammad, (2012) “An Analysis and Comparison of The Security Features of Firewalls and IDSs”, Linköpings universitet, Institutionen för systemteknik, pp. 87-2011.
[4] D. Ashok Kumar & S.R Venugopala, (2017) “Intrusion Detection Systems: A review”, International Journal of Advanced Research in Computer Science, Vol. 8, No. 8, pp.356-370.
[5] Mrinal Wahal, Tanupriya Choudhury & Manik Arora, (2018) “Intrusion Detection System in Python”, 8th International Conference on Cloud Computing, Data Science & Engineering, pp. 348- 353.
[6] Michael & Rash, (2007) “Linux Firewalls: Attack Detection and Response with iptables, psad, and fwsnort”, No Starch Press, pp. 81-173.
[7] SH Kok, Azween Abdullah, NZ Jhanjhi, Mahadevan Supramaniam, (2019) “A Review of Intrusion Detection System using Machine Learning Approach”, International Journal of Engineering Research and Technology, Vol. 12, No. 1, pp. 8-15.
[8] Thomas M. Chen, Patrick J. Walsh, (2014) “Guarding Against Network Intrusions”, In: Network and System Security (Second Edition), Chapter. 3, pp. 57-82.
[9] Takeda K., Takefuji Y., (2001) “Pakemon – A Rule Based Network Intrusion Detection System”, International Journal of Knowledge Based Intelligent Engineering Systems, Vol. 5, No. 4, pp. 240- 246.
[10] Dmitrij Melkov & Šarūnas Paulikas, (2021) “Analysis of Linux Os Security Tools For Packet Filtering and Processing”, Vilnius Gediminas Technical University, pp. 1
AUTHORS
Tuan Nguyen Kim was born in 1969, received B.E, and M.E from Hue University of Sciences in 1994, and from Hanoi University of Technology in 1998. He has been a lecturer at Hue University since 1996. From 2011 to present (2021) he is a lecturer at School of Computer Science, Duy Tan University, Da Nang, Vietnam. His main research interests include Computer Network Technology and Information Security.
Duy Thai Truong was born in 1997, He graduated from Duy Tan University in 2019. He is a Security Engineer at Danang Department of Information and Communications, Vietnam. He is working at here from November 2019 to present. His main is research on information security and penetration testing.
Tam Nguyen Tri was born in 1998, He graduated from Duy Tan University in 2020. From November 2020 to present (2021), he is a Security Researcher at Danang ICT Infrastructure Development Center.
Lam Tran Nguyen was born in 1998, He graduated from Duy Tan University in 2020. From November 2020 to present (2021), he is a Security Researcher at Danang ICT Infrastructure Development Center.