s2ipt: A Lightweight Network Intrusion Detection/Prevention System

based on IPtables

Gerardo Canfora

, Antonio Pirozzi

1,2

and Aaron Visaggio

Department of Engineering, University of Sannio, Via Traiano, 3, 82100 Benevento BN, Italy

KOINE srl, Via Porta Ruﬁna 13, Benvento 82100, Italy

Keywords:

Intrusion Detection System, Intrusion Prevention System, IPtables, Snort, NIDS, NIPS, Application-level

Control Flow, Netﬁlter.

Abstract:

Since each organization has its own security culture and background, there is not an out-of-the-box solution

that ﬁts all the possible security requirements. There may be some contexts in which it is necessary to monitor

and prevent certain application-level attacks with less impact on pre-existent conﬁguration. For example, there

may be some constraints on processing resources of some embedded devices. Starting from this consideration,

we developed s2ipt, a python-powered tool which aims to implement a lightweight Netﬁlter-based network

intrusion detection and prevention system (IDS/IPS) by translating Snort community rules into iptables rules-

set. s2ipt utilizes the netﬁlter string matching module to detect application-level attacks. Netﬁlter reduces

the impact on a system, has less memory and CPU footprint, which makes it suitable to run even on low-cost

devices than a solution like Snort. s2ipt allows iptables to detect application layer attacks in a transparent way,

in fact it only adds new application layer ruleset leaving the existing ones unchanged.

1 INTRODUCTION

One of the most powerful and widespread ﬁrewall,

already integrated within Linux machine, is iptables

(ipt, ). Iptables is a stateful packet ﬁlter ﬁrewall em-

bedded in the most UNIX installations, and is based

on Netﬁlter module; however it lacks the functional-

ity of inspecting the Application layer data. Another

network defence technology is Snort (sno, ), a widely

deployed network intrusion detection and prevention

system (IDS/IPS). The two technologies are comple-

mentary since iptables can be adopted to a lower level

than Snort, while Snort can perform ﬁltering at appli-

cation level. For this reason the two technologies can

be integrated, obtaining the following beneﬁts: ipta-

bles could inherit the rich set of rules from Snort, and,

differently from Snort, can be adopted as a ﬁrewall on

thin devices like wearable devices and Arduino con-

trollers. Moreover, as authors in (Zhong, 2016) claim,

to elicit attack path patterns by modeling and mining

the traces of analysts’ data triage operations is feasi-

ble and necessary, thus technologies that capture such

information must be developed and adopted by or-

ganizations. This paper presents a tool called s2itp

which aims to adapt Snort ruleset to iptables, which

is made possible by the string matching support of

Netﬁlter which adds content inspection capabilities to

iptables.

s2ipt allows iptables to detect application layer at-

tacks in a transparent way, in fact it only adds a new

application layer ruleset leaving the existing ones un-

changed. Since this tool produces a low system foot-

print, it is suitable also for low-powered devices. s2ipt

combines logging, network based intrusion detection

and prevention system within a packet ﬁlter ﬁrewall.

The usage of Snort rules in scenarios with poor

computational resources is scarcely discussed in liter-

ature: at the best knowledge of the authors only Ar-

ney and Wang (Arney and Wang, 2016) investigate

the relationship between the number of enabled rules

maintained by Snort and the amount of computing re-

sources necessary in low-powered systems as the IoT

devices. The paper proceeds as follows: section 2 il-

lustrates the solution in detail; section 3 shows a val-

idation of the tool; and, ﬁnally, section 4 draws the

conclusions.

2 SOLUTION

Establishing a correspondence between a Snort rule

and an Iptables’ one is not always possible. For this

462

Canfora, G., Pirozzi, A. and Visaggio, A.

s2ipt: A Lightweight Network Intrusion Detection/Prevention System based on IPtables.

DOI: 10.5220/0006431904620467

In Proceedings of the 14th International Joint Conference on e-Business and Telecommunications (ICETE 2017) - Volume 4: SECRYPT, pages 462-467

ISBN: 978-989-758-259-2

reason s2ipt performs a ”best-effort” translation, i.e.

at the best of the possibilities offered by the Iptables’

syntax. Unfortunately Snort provides for functions of

a higher level than Iptables, as well as a regular ex-

pressions engine, which are not available in Iptables.

A Snort rule is formed by a two elements-

structure: header(options), where the ﬁrst part is

ﬁxed, while the second one is variable and depends

on the options of the rule. The header includes the

following ﬁelds:

• action: indicates the action to take when the

packet speciﬁed by the rule is intercepted;

• protocol: indicates the protocol the packet is as-

sociated to (Snort supports TCP, UDP, IMCP, and

IP);

• Source IP: indicates the source IP;

• Source port: indicates the number of the source

port;

• Operator: indicates the direction of the packets

and three modes are considered: from source to

destination, and in both the directions between the

source and the destination;

• Destination IP: indicates the destination IP;

• Destination Port: indicates the number of the des-

tination port;

All the options within a Snort rule are expressed in

the form: keyword:value where keyword: represents

the type of option, and value the corresponding value.

These options can be classiﬁed into four categories:

• General: provides information about the rule

without effects on the rule’s execution;

• Payload: allows to ﬁnd data within a packet’s pay-

load, and different rules of this kind can be corre-

lated to form a one only rule;

• Non-Payload: allows to look for information out-

side the payload;

• Post-detection: lets to deﬁne mechanisms to be

triggered after the rule matching;

Iptables rules can be deﬁned by command line

within a Linux operating system with this structure:

iptables[-thtable-namei]hcommandi hchain-

namei\hparameter-lihoptiono-li\hparamter-

nihoprtion-ni where:

• htable-namei indicates which table the rules must

be applied to;

• hcommandi indicates the action to perform;

• hchain-namei indicates the chain to modify, create

or remove;

• the pairs hparametersi-hoptionsi represents the

parameters and the corresponding values of the

options associated, which deﬁne how a packet

which triggers a rule must be handled.

The high ﬂexibility allowed by the Iptables syntax

makes a rule’s length and complexity to signiﬁcantly

vary with regards to its goal. Finally, in order to cre-

ate a valid Iptables rule, three key further parameters

must be deﬁned:

• Packet type, which is the type of packet to be mon-

itored;

• Packet source/destination, which is the packet’s

source or destination that must be ﬁltered;

• Target, which deﬁnes the type of action to perform

when the rule is matched.

2.1 Translating Algorithm

The approach used for the translation is based on a

”best effort” philosophy, due to the lack of a perfect

correspondence between the Snort syntax and the Ipt-

ables syntax. When the correspondence between a

Snort rule and an Iptables rule is complete, the algo-

rithm translates the rule from a syntax to the other

one. When there is not a complete correspondence,

the algorithm rephrases the semantics into the syntax

allowed by Iptables. If this attempt fails, the trans-

lation of the entire rule fails. As ﬁrst step, the al-

gorithm translates the header of the Snort rule, and

than it copes with the single options. The translation

strategies adopted are the following:

• Action: although the Snort sintax supports eight

different types of action, s2ipt takes into account

only the rules with the alert.

• Protocol: in this case there is a 1:1 mapping with

the Iptables option Iptables -p protocolname

where all the protocols supported by Snort can be

made explicit;

• Source/destination IP: for specifying the IP ad-

dresses, sources and destinations, the commands

-s IPaddress and -d IPaddress are respec-

tively used. Nevertheless, the Snort syntax pro-

vides for static variables tagged as $HOME NET

and $EXTERNAL NET (representing the local

network and the the external network), which are

not supported by Iptables, and are not translated

by the algorithm. Snort lets specify the multiple

IP addresses, classes of IP addresses (in CIDR no-

tation) and the negation of a certain IP address.

All these options are supported by Iptables (and

thus translated by s2ipt) except for the negation

of multiple IP addresses;

s2ipt: A Lightweight Network Intrusion Detection/Prevention System based on IPtables

463

• Source/destination port: Snort supports three dif-

ferent ﬁelds for the number of source/destination

ports. Iptables makes use of --sport value and

--dport value options. In this case there is not

a direct correspondence, but we adopted a trick.

Iptables allows the deﬁnition of the port num-

bers, like Snort. Additionally, Iptables lets to de-

ﬁne an interval, separating the extremes with a

colon. For deﬁning any port (corresponding to

any in Snort), the user must omit the port num-

ber in Iptables. Iptables allows to exclude a spe-

ciﬁc port number, as well as Snort, but for indicat-

ing a set of port numbers, Iptables requires the -m

multiport module before the commands for the

speciﬁcation of the port numbers;

• Operator: there is not a correspondence for

the Snort’s direction tag in Iptables, where the

same information is represented by the concept of

chain. In the case of s2ipt, a custom chain is cre-

ated, which is referred to by the Iptables engine,

as discussed later in the paper.

Once the header is translated into a Snort rule,

the algorithm examines the options, analyzing them

singularly, trying to accomplish the translation. Even

if not all the Snort options can be translated in Ipta-

bles rules as they are not supported, the most common

ones can be mapped.

All the Snort options that s2ipt can translate into

the Iptables format are listed along with the adopted

assumptions and strategies:

• Content: allows to ﬁnd a speciﬁc byte sequence

within a payload, applying the Boyer-Moore algo-

rithm. The Iptables extension that performing the

”string-matching” can be selected with the com-

mand -m string -string "string" -- algo

bm, where string is the string to search within the

payload. Snort allows the search of hexadecimal

value that can be accomplished with Iptables op-

tion -m string --hex-string;

• Uricontent: allows to handle data codiﬁed in

URLs, transferred on HTTP. S2ipt manages this

option as well as the previous one;

• Offset: searches for a content within the payload

starting from an offset location. Iptables allows

the same option with the command --from;

• Depth: forces that the packet matching does not

overcome a certain number of bytes after the pay-

load. In Iptables this option is speciﬁed through

the command --to followed by the number of de-

sired bytes. This and the following option can be

present in more than an instance within a Snort

rule. This is not allowed by Iptables, with the

additional constraint tha the number of bytes in-

dicated by --from be smaller than that indicated

by --to. In such case, 2s2ipt sums the values of

the depth (--to) ﬁelds, considering the minimum

value of the offset (--from) ﬁeld;

• TTL: allows to match a packet relying on the TTL

value within the IP header. Both Snort and Ipt-

ables allow to specify a value of TTL smaller or

greater than, and equals to a certain number;

• Tos: indicates the bit within the Type of Service

ﬁeld in the IP header. This option is supported

by Iptables with the command -m tos --tos

value;

• Flow: this Snort option allows to deﬁne a spe-

ciﬁc state of a connection: for instance the combi-

nation of from

client and established lets to an-

alyze only the packets on the client side of a

TCP connection after the three-way handshake

was completed. Iptables lets to ﬁlter the state

of a TCP connection with -m state --stat

CONNECTION STATE command. Differently from

Snort, Iptables allows to check only ﬁve states

(INVALID, ESTABLISHED, NEW, RELATED

and UNTRACKED). For this reason we made the

decision to consider in s2ipt only the Snort rules

referring to the ESTABLISHED;

• Ip proto: resctricts the scope of rule on the basis

of the protocol ﬁeld of the IP header.Iptables lets

to specify the same option with the command -p

followed by the type of the desired protocol;

• Pcre: stands for Perl Compatible Regular Expres-

sion and lets Snort to apply regular expressions

of high complexity. Since Iptables does not sup-

port any kind of regular expression, for this option

the algorithm must use mainly the best-effort ap-

proach. s2ipt is able to translate only a little subset

of all the possibile variants of Snort’s pcre. The al-

gorithm can translate only those rules whose pcre

option contains constant values, as it begins the

aforementioned content. Another case that allows

the transaltion in Iptables rule is represented by

static patterns deﬁned by numeric values.

The complete algorithm of translation includes

four main phases:

• Pre-processing: the tool carries out a preliminary

evaluation of the rules for excluding those that can

not be translated because of a missing correspon-

dence between the Snort and the Iptables sintax.

The remaining rules are gathered in two sets: one

contains the part concerning the header and the

other contains the part concerning the option;

SECRYPT 2017 - 14th International Conference on Security and Cryptography

464

Figure 1: s2ipt. Translation process.

• Header translation: all the ﬁelds of the Snort

rule’s header are properly translated in the corre-

sponding Iptables rule(s);

• Options translation: all the options of the Snort

rule’s are properly translated in the corresponding

Iptables rule(s);

• Synthesis: the result of the translation is trans-

formed into a string used as Iptables command.

The translation process is depicted in Fig. 1

2.2 Best-effort Policy

The lack of a complete correspondance between the

Snort and Iptables sintax lead us to deﬁne a ”best-

effort” policy which consists into the generation of

an Iptables rule which is similar to the corresponding

Snort rule, but that is not an exact translation. The

policy is deﬁned in this way:

• if the Snort rule contains an action different from

alert, the rule is not translated;

• if the number of Snort options within an input rule

is greater than the number of options that s2ipt is

able to translate, the rule is considered translated

in ”best-effort”;

• if the rule contains the pcre option, and there are

patterns that can not be translated, the rule is dis-

carded, otherwise the rule is considered translated

in ”best-effort”;

• if the rule contains the negation of a range of IP

addresses as source or destination, the rule is not

translated;

• if the the rule contains a content option, it is not

translated as it is considered too generic.

Each rule is assessed against this list of controls in

order to decide if the translation is in ”best-effort”, or

not.

2.3 Coverage of Translation

In order to obtain a ﬁrst assessment of the level of the

translation coverage, s2ipt was launched getting as in-

put data the complete rules-set of the Snort commu-

nity(at 06/16/2016). In particular, compared to 3419

rules taken into account, the tool is able to correctly

translate 2860 rules, ie approximately the 84%. The

best-effort approach was applied to 2268 rules (about

80%), while the remaining 592 have been translated

1:1 by the tool. Such a high percentage in the best-

effort is essentially justiﬁed by two reasons. First,

many options are not taken as part of the algorithm

translation because they did not have corresponding

options in Iptables. Furthermore, since the Iptables

syntax does not provide for the use of regular ex-

pression patterns, whenever the algorithm meets the

pcre option in a Snort rule and manages to translate

it, s2ipt makes the conservative assumption for which

the translation is done in best-effort.

Let’s see how s2ipt translates a Snort rule;

let’s consider the following rule: alert

tcp $HOME NET any -> $EXTERNAL NET any

(msg:"MALWARE-BACKDOOR Infector.1.x";

flow:established,to client; content:

"WHATISIT"; metadata:ruleset community;

reference:nessus,11157; classtype:

misc-activity; sid:117; rev:16;)

This rule tracks all the packets that refer to an

established TCP connection headed to the client ap-

plication, whose content includes the ”WHATISIT”

string at application layer. a packet having these char-

acteristics will be written in the log with the tag:

”MALWARE-BACKDOOR Infector.1.x””. Such a

rule does not contain any option that is not supported

by Iptables, thus it will be straight translated by s2ipt.

In particular, the translation process will analyze the

header content as ﬁrst, then it will scan all the options

of the rule. The result of the translation will be:

s2ipt: A Lightweight Network Intrusion Detection/Prevention System based on IPtables

465

iptables -I CUSTOM CHAIN 1 i IFACE p

tcp m state --state ESTABLISHED m string

--string "WHATISIT" --algo bm -m comment

--comment "MALWARE-BACKDOOR Infector.1.x"

-j LOG --log-prefix [IDS-117]

where, as it is easy to observe, the options regard-

ing metadata have been ignored (metadata, refer-

ence, classtype, sid and rev), whereas the remain-

ing have been taken as they are. In particular, CUS-

TOM CHAIN indicates a chain where the rule (IDS

or IPS) must be added and IFACE represents the in-

terested interface (eth0, wlan0, and others).

3 VALIDATION

The goal of the validation phase is to evaluate the ef-

fectiveness of s2ipt and the accuracy of the produced

iptables rules. Since these rules are generated from

semantically equivalent Snort rules, the validation has

been focused on the analysis of the observed behavior

of the iptables ﬁrewall (conﬁgured with s2ipt) com-

pared to the corresponding Snort ﬁrewall while tra-

versed by the same trafﬁc pattern. Three classes of

test cases were deﬁned: port scanning, attacks against

Apache Web Server, and Web Application Fuzzing.

The results of the two systems were then observed and

compared. All the tests were carried out starting from

2860 Snort rules published by the same community

on 06.16.2016, which s2ipt was able to translate.

3.0.1 Port Scanning Test Case

This test case consisted of 12 different port scanning

techniques deﬁned as follows:

• Syn Scan : Sending a SYN (synchronization)

packet to initiate a three-way handshake.

• Fin Scan : Sending a packet with just the TCP FIN

bit set.

• Null Scan : Sending a packet without setting TCP

ﬂags.

• Maimon Scan : This probe is exactly the same

as NULL, FIN, and Xmas scans, except that the

probe is FIN/ACK.

• Xmas Scan : Sending a packet with all TCP ﬂags

set. Sets the FIN, PSH, and URG ﬂags.

• Connect Scan : Full TCP scan, trying to establish

a 3-way handshaking.

• Ack Scan: Sending a packet with only the ACK

ﬂag set.

• IP Protocol Scan : IP protocol scan allows to de-

termine which IP protocols (TCP, ICMP, IGMP,

etc.) are supported by target machines.

• Intensive Scan : Scan the most common TCP

ports. It will try to determine the OS type and

which services (and versions) are running.

• Intensive Scan plus UDP : Same as the regular

Intense scan, but UDP ports are also scanned.

• Intensive Scan plus TCP : Same as the regular In-

tense scan, but TCP ports are also scanned.

The results given in Table 1 show the results of the

I test case (port scanning):

Table 1: Test Case I : Port Scanning.

Type of Scan. Snort Alerts Ipt Alerts

Syn Scan 0 0

Fin Scan 0 0

Null Scan 0 0

Maimon Scan 0 0

Xmas Scan 0 0

Connect Scan 0 0

Ack Scan 0 0

IP Protocol Scan 0 0

Intensive Scan 5 11

Intensive Scan plus UDP 8 15

Intensive Scan plus TCP 8 11

Figure 2: Test Case I : Port Scanning.

As we can notice from the histograms in ﬁgure 2,

both Snort and iptables generated alerts for the fol-

lowing types of port scanning: ip protocol scan, in-

tensive scan, intensive scan plus UDP, intensive scan

plus TCP. We notice that iptables generates some

more alerts, because the best effort approach tends to

relax iptables rules that becomes more greedy.

3.0.2 Attacks against Apache Web Server

This test case consisted of attacking Apache web

server using Metasploit and then see if Snort and

iptables would be able to detect the attacks. The

ﬁrst attack, also known as Apache Killer, is called

Apache Range Dos Attack CVE-2011-3192 (CVE, ).

It submits a single short request to trigger these ap-

plications into replying with a large amount of arbi-

trary data, causing the service to become temporar-

ily unresponsive. The Apache Killer attack was car-

SECRYPT 2017 - 14th International Conference on Security and Cryptography

466

ried out with the Auxiliary Metasploit module auxil-

iary/dos/http/apache range dos). The second attack

is against mod isapi extension in Apache and it was

carried out with the Auxiliary Metasploit module aux-

iliary/dos/http/apache mod isapi.

The results given in Table 2 show the results of the II

test case (Attacks against Apache Web Server) :

Table 2: Test Case II : Attacks against Apache Web Server.

Type of Attack. Snort Alerts/pkt Iptables Alerts/pkt

Apache Range DoS Attack 1/1 3/1

Apache mod isapi 2/20 3/20

Figure 3: Test Case II : Attacks against Apache Web Server.

As we can see from the histograms in Figure 3,

iptables tend to generate more alerts due to the ”best

effort approach” in the translation process but the im-

portant thing is that the attack had been detected by

iptables as well as snort.

3.0.3 Web Application Fuzzing

This test case consisted of sending Random Data

against both Snort and iptables and verifying if they

would be able to detect the attack. To carrying out

this test case, ZAP Proxy was used (OWASP, ). The

results given in Table 3 are related to the III test case:

Table 3: Test Case III : Web Application Fuzzing

Type of Attack. Snort Alerts/pkts Iptables Alerts/pkts

Web application Fuzzing 1/53 5/53

Figure 4: Test Case III : Web Application Fuzzing.

4 CONCLUSION

s2ipt is a tool that lets to conﬁgure the iptables ﬁre-

wall as an NIDS/NIPS based on the Snort community

rules, in a simple and transparent way, without ob-

serving substantial changes to the environment. The

power of s2ipt lies in the combination of the posi-

tive aspects of two different types of technologies: on

one hand the power of Snort syntax and the support

contributed by his community, on the other hand the

efﬁciency resulting from the use of the Linux kernel

and the simplicity of iptables commands, which have

a minimal impact on system resources.

ACKNOWLEDGEMENTS

This Research was supported thanks to the contribu-

tion of Luigi Pino, Alessandro Esposito and Luciano

Ocone of the Department of Engineering of Univer-

sity of Sannio.

REFERENCES

Cve-2011-3192. http://cve.mitre.org/cgi-bin/cvename.cgi?

name=cve-2011-31922. Accessed: 2017-02-09.

iptables. https://www.netﬁlter.org/. Accessed: 2017-02-09.

Snort ids. https://www.snort.org. Accessed: 2017-02-09.

Arney, C. A. and Wang, X. (2016). Active snort rules and

the needs for computing resources: Computing re-

sources needed to activate different numbers of snort

rules. In Proceedings of the 5th Annual Conference

on Research in Information Technology, pages 54–54.

ACM.

OWASP. Zap proxy. https://github.com/zaproxy/zaproxy.

Accessed: 2017-02-09.

Zhong, C., Y. J. L. P. . E. R. F. (2016). Automate cyberse-

curity data triage by leveraging human analysts’ cog-

nitive process. In IEEE International Conference on

Intelligent Data and Security (IDS), pages 357–363.

IEEE.

s2ipt: A Lightweight Network Intrusion Detection/Prevention System based on IPtables

467