Bro NIDS and Unix Firewall: towards an Intrusion Prevention System.

(1)

Abstract

The huge number of successfully attacks that nowadays we are experiencing suggests that we have to find new methods to protect our systems from ma-licious actors. In recent years several new technologies and new distributed system architectures were introduced, and the attacks that those systems are exposed to are very complex and sometimes not so easy to detect. Both anomaly-based and signature-based Intrusion Detection Systems (IDS) can be used to mitigate this problem, but each network administrator has to be aware of common used attack techniques in order to enable the selected IDS discover them. The aim of this thesis is to build a collaboration between the Bro Network Intrusion Detection System (NIDS) and the ubiquitous Linux Kernel firewall in order to construct a system with a custom active response to block a set of known attacks and evasion techniques. Moreover in order to decrease the percentage of false positives, which is a known limitation of anomaly-based IDS, a separated inspection technique is implemented for fur-ther analysis of weird behaviors detected by Bro NIDS. The power of this approach is demonstrated by implementing a selected set of attacks and eva-sion techniques, conducted against a little protected network. It is composed by a machine in which an instance of Bro and one of custom “packet inspector” are deployed, together with a running Linux server that is actually the victim of each attack. The outcomes of these test cases prove the strength of this system in the selected attack scenarios.

(2)

1 Introduction

1.1 Context

Nowadays we are surrounded by an huge number of devices with Internet ac-cess. In the last decade, we have been experiencing an explosive growth in Internet traffic, driven largely by faster mobile internet speeds and the prolif-eration of online devices [31]. Internet-of-Things (IoT) and its ubiquitous sen-sors, intelligent transportation systems, smart-home environments, and even the more familiar smartphones are an example of devices and systems that have enabled such growth [16].

From an infrastructure point of view, even computer systems have evolved offering new architectures. Cloud computing has reached every part of the Internet, offerings a lot of services that people use every day (e.g. mailing systems, storage systems, mobile services). More in general, distributed archi-tectures have been largely used in the last few years to better dominate the growth in the number of end-users and online devices/services. By making applications reachable from each part of the Internet and from each online device, the whole attack surface grew accordingly.

Moreover, the huge amount of data that we create, use, and exchange within computer systems has become the gold of the 21st century [32]. This has captured the attention of malicious actors. They work nonstop to evolve their threats, move with even more speed, and find ways to widen their operational space. Nowadays each terminal with Internet access can be a victim, and this leads to an increment on the number of possible threats.

A report by Symantec [33] reveals that in the last 8 years more than 7.1 billion of identities have been exposed in data breaches, with 1209 total re-vealed cases in 2016. The most used techniques are email threats (one in 131 emails sent is malicious), living-off-the-land attack [26], ransomware and mal-ware in general. The average number of web attacks blocked per day are 229K

(5)

in 2016, and this reveals how older techniques continue to be extensively used. Generally speaking, even if all of these attacks exploit mostly straightforward approaches and use very simple and available tools, they can be very powerful and may cause damage to the victims, e.g. economic losses.

According to the Cisco 2017 Annual Cybersecurity Report, a quarter of the organizations that have suffered an attack lost business opportunities. One in five organizations lost customers due to an attack, and nearly 30 percent lost revenue [31]. However, there still remain a lot of organizations that may believe their networks are safe only because they have not yet suffered a security breach. Consequently, such organizations start reasoning about security after the first experienced attack. The key to avoid loosing money and/or customers is to be ready whenever an attack arrives.

On the defense side, the situation is even worst. An attacker can exploit one out of the whole available attacks to breach the victim. A defender has to pro-tect the system from each possible threat. This suggests that defenders must be aware of vulnerabilities that their system can be exposed to, and patch all of them (or at least the most critical ones) as soon as possible. System admin-istrators should know about the most used attacks and evasion techniques that malicious actors exploit, in order to reduce the attackers operational space.

The deployment of Intrusion Detection and Prevention Systems (IDPS), to-gether with regularly updated firewalls (e.g. Web Application Firewall (WAF)) as well as gateway antivirus, can help the defenders to protect their systems [16]. This protection systems offers various automated techniques to stop common and known attacks. However, there still exist very powerful evasion techniques that can be used from attackers to avoid detection. An attack must remain undetected and stealthy to perform its malicious actions [32]: this is the reason why attackers continuously searching for new techniques and tactics to avoid detection.

(6)

1.2 The problem

The scenario described in Section 1.1 suggests that the available attacks and evasion techniques continue to grow and to evolve according to the current technologies. This reveals that even the security components must evolve as well and exploit new techniques to protect computer systems.

Cisco defines the Time to Detect (TDD) as “the window of time between a compromise and the detection of a threat” [31]. It also defines the Time to Evolve (TTE) as the time it takes adversaries to change the way specific malware/exploit is delivered. This last measure tells a lot of information about how malicious actors work: they continuously and constantly change tactics to avoid detection and also to increase their Time to Operate (TTO). This last measure models the time that an attack remains active in the system. The longer the TDD, the longer the TTO. Consequently, the amount of money that the victim can loose is proportional to those two measures.

The problem is to develop and create security technologies that can help defenders to do their work. The best solution should be providing a protec-tion system which has a TDD as shorter as possible in order to reduce the average TTO of each attack. Moreover, this solution should be managed by security specialists aware of common attacks and evasion techniques. They must continuously improve their countermeasures making them to evolve with the attacks, in order to tune their security technologies and protect their com-puter systems. This can only be done with totally configurable and tunable security components.

Defenders are not alone. They can exploit existent automatic defensive systems in order to be as reactive as possible. Just deploying a security tech-nology and hoping it can solve all the problems is far from an effective solution. A best practice is to emphasize multiple, overlapping, and mutually supportive defensive systems to guard against different threats. Anyway, security special-ists must take care of their protected networks and continuously estimate the exposure of critical applications to common attacks and evasion techniques.

(7)

As introduced in the Section 1.1, the key is to reduce their operational space by patching (at least) all critical discovered threats.

The statistics reported in [31] [32] and [33] reveals that even if there are a lot of commercial security technologies that are used in production environments, the number of attacks is continuously growing. This suggests that security companies have to evolve and produce better protection systems that can be as complete as possible and even offers a tunable structure to security specialists.

1.3 Proposed solution

In this work we consider a production like environment, with a local network hosting different applications to be protected. We have assessed the set of threats that the protected applications are exposed to, and we have selected the most critical ones. Then, by extending an available and open-source Network Intrusion Detection System (NIDS) named Bro [34], we add a set of defense policies that are applied in the selected attack scenarios. Those kind of policies will be automatically deployed when the corresponding attack is detected by the protection system.

Bro is a network-based detection system. Consequently, we choose to de-ploy our proposed defense policies as firewall filtering/blocking rules, using the ubiquitous Linux Kernel Firewall and specifically the iptables command-line program [23]. For a particular evasion technique, the collected packets are sent to an application in user-space to perform a packet inspection technique. The implemented packet inspector finds malicious overlapping in TCP flows, a known evasion technique. The details of attacks will be given in Section 2.

The collaboration between Bro NIDS and the Linux Firewall results in the construction of a real IDPS that enable the protection against the selected attacks and evasion techniques.

The final aim of this work is not to propose a complete system which can protect a site against each possible attack. Rather we want to describe a usable and powerful security component, composed by state-of-the-art technologies

(8)

that can be used as a starting point for protection purposes. In a nutshell, using a completely configurable and tunable detection system, we have defined a methodology that enables security specialists to deploy the best countermea-sures against the attacks that a specific site can be exposed to.

1.4 Methods, Tools and Results

In this section we describe our methodology and the tools that support it. Finally, we briefly present the obtained results in test cases. In this phase we act as we are attackers. The first step is the vulnerability assessment about the deployed applications and their threats. Then, we select a subset of them considering the most critical ones. A threat is considered critical if it enables an attacker to steal sensitive data or credentials that can be used to gain unauthorized access [6].

Then we search for available tools and exploits that an attacker can use to target the applications deployed in our protected network. This phase reveals how simple is retrieving powerful exploits or available tools that implement them. Consequently, each malicious actor who wants to implement a spe-cific attack, can avoid wasting time implementing it. Mostly of the times, he can find an available tool that implements exactly the selected attack. We use THC-Hydra for SSH brute-force attack [35]; sqlmap for automated SQL-Injections [36]; and Fragrouter for the selected evasion techniques (Malicious Segment/Fragment Overlap) [24]. Those tools are already installed in the Kali Linux 2017.1 release [37], that we use in our test cases. The details about those tools and the attacks that they implement are given in Section 2.

Finally we conduct a set of test runs for each attack scenario. The per-formed test cases prove that using the proposed protection system can effec-tively decrease the number of successful attacks. However, in the considered attack scenarios there are particular cases in which Bro NIDS misses to detect the implemented attack. This reveals as either a configurable and tunable protection system like the one proposed, has its limitations. In the considered

(9)

Bro version, some detection modules appear to use an older signature that for sure lead to a defense policy that lack of completeness. In this work we overcome some of these limitations, and in Section 5 we indicate some future works useful to deal also with the other ones.

Our results also reveal that this approach can be extended in a simple way by a security specialists or network administrators. They can make their vulnerability assessment against the protected site, writing down a specific extension that can improve the detection capabilities of the proposed defense system.

1.5 Overview

The remainder of this thesis is organized as follows. Section 2 provides an overview of the basic concepts and a complete description of the technologies used in this work, with some links to relevant related work. Section 3 provides the description of the proposed defense system and the presentation of the different defense policies applied in selected attack scenarios. Section 4 has all the test cases together with the obtained results. Finally, the thesis concludes with Section 5 discussing some future work.

(10)

2 Background

In this section we present the considered technologies and software in order to enable the reader to understand all remainder contents of this thesis.

We will also describe all the different attacks and evasion techniques that we have considered in our test environment. This survey will provide the reader with the basic background on the various topics mentioned in this thesis.

2.1 Intrusion Detection System (IDS)

As described in Section 1, the Internet encompasses nearly every aspect of our lives today. In this scenario, partial or temporal failures could have severe con-sequences. End-users experiencing those failures can loose money or sensitive informations that could lead them to leave the service/application. This can cause damage in the company that hosted the breached service/application.

In order to protect their computer systems and applications, companies must implement software and design hardware to be as secure as possible. But this is not enough: they must continuously monitor their systems to ensure their correct functioning, for any kind of anomalies, or for signs of intrusions and attacks. This task is usually taken by Intrusion Detection Systems (IDSs). Its main goal is the detection of any attempt to compromise confidentiality, integrity, availability, or simply bypass the security mechanisms of a computer or a network [27].

An IDS can be classified in terms of various characteristics. The first one is the position at which it is deployed. An IDS can be host-based, whenever it is deployed to monitor a single host, or network-based when it is deployed at the edge of a protected network to monitor all traffic that enters it. The second characteristic is related to the way it tries to detect attacks. An IDS can be signature-based whenever it uses a set of known attacks (signatures) to perform the detection task. Anomaly-based IDS instead, constructs a model

(11)

of normal behavior of the protected systems and marks as malicious all unex-pected behavior.

An IDS can be further categorized according to their architecture. The early IDSs have been mostly isolated single instances for monitoring a single system/network. If more than one instance of that IDSs is deployed in the same network, no communication and interaction takes place between instances. In order to be able to protect large networks and large IT ecosystems, Collabora-tive IDSs (CIDSs) are emerged [27]. This type of IDS can have several analysis and monitor units which communicate each other to detect intrusions. CIDSs can be further divided according to their communication architecture:

• Centralized CIDSs consist of several monitors hosted on their respective host or network that share their data with a central analysis unit; • Decentralized CIDSs usually employ a hierarchical structure of

moni-toring points that apply preprocessing and correlation of the monitored data, until the data converge to a central analysis unit on top;

• Distributed CIDSs share the tasks of central analysis unit equally among all monitors, so that each monitor is also an analysis unit.

In [27] there is a comprehensive analysis of the state of the art in CIDSs. On the one hand, this survey reveals that Centralized CIDSs and Decentralized CIDSs provide higher accuracy detection than Distributed CIDSs. On the other hand, Distributed CIDSs appear to be more scalable and resilient than the other two types (e.g. no Single Point of Failure (SPoF)). An interesting Centralized CIDS is named DIDMA that stands for Distributed Intrusion De-tection system using Mobile Agents [4]. This CIDS has two types of agents that act as monitors: static and mobile agents. The first type acts as host monitor and generates alerts whenever malicious activity is detected. The second type is responsible for alert dissemination as well as correlation and ag-gregation of data. DIDMA utilizes a central entity that uses signature-based detection algorithm and maintains a global view of the protected network overlay. Event Monitoring Enabling Responses to Anomalous Disturbances

(12)

(EMERALD) is a Decentralized CIDS that uses both signature-based and anomaly-based detection engines [1]. It distinguishes between three different layers: service analysis, domain-wide analysis, and enterprise-wide analysis. These layers model the hierarchical detection structure of this CIDS. Finally the Neighborhood-Watching is a P2P-based Distributed CIDS that uses mobile agents with anomaly-based detection engine. The detection phase is done in a P2P fashion: if an anomaly is detected by a neighbor of an attacked peer, a voting process among all its neighbors takes place. When the majority agrees that intrusive behavior has been observed, all neighbors will try to protect themselves and at the same time disseminating the alert within other peers in the network.

2.2 Intrusion Prevention System (IPS)

As IDS deals with only detection, it is considered as a passive mechanism only. In order to prevent breaches, we need systems that are able to detect attacks online and prevent malicious data to enter the protected network or host.

Those systems are named Intrusion Prevention Systems (IPS) and their task consists on applying a given response mechanism to block detected at-tacks. This goal is obtained by making an existent IDS collaborate with other software framework (e.g. firewalls) in order to have an engine for active re-sponse. IPS solutions are considered an active mechanism to fight against intruders.

The same differences defined in IDS case apply also for IPS. According to [8] they can be classified in Host-based Intrusion Prevention Systems (HIPSs), Network-based Intrusion Prevention Systems (NIPSs), and Wireless Intrusion Prevention System (WIPSs), depending on the deployment position. Their de-tection methodology can be signature-based, anomaly-based or both. Finally IPSs can be isolated or collaborative, based on their communication architec-ture.

(13)

article reveals that the most recent research has concentrated on collabora-tive systems to provide solutions for distributed real-time environment using hybrid detection techniques and wireless technologies. It also provides a list of newer approaches to deploy IPS in the cloud environment. In [17] a mo-bile agent based IPS for wireless network is defined. It uses signature-based detection algorithm and it is considered a Distributed Collaborative IPS. In [12] Jaiswal & Jain with their Database Intrusion Prevention System pro-pose an architecture for detection, prevention and appropriate response in a database system. The proposed IPS is isolated and host-based and it uses signature-based detection algorithm (e.g. SQL-Injections signatures) together with genetic algorithms for the anomaly-based detection. It is worth notic-ing that there are some commercial implementation of IPS. The most famous Snort IPS [38] provides only signature-based detection algorithms. Cisco Next-Generation IPS (NGIPS) provides an hardware solution to detect and prevent threats in an automated way [39]. It is also capable of discovering information about network environment, including data about operating systems, mobile devices, files, applications and users. It then uses this information to build network maps and host profiles, in order to have contextual information to make better decisions about intrusion events.

2.3 Detection vs Prevention

The detection component present in an IDS is the same as in IPS. There are monitor units in the detection module, used to collect information about entering traffic (NIPS) or host behavior (HIPS). Then, analysis units are used to searching for signature matching or malicious behavior.

The key difference between IDSs and IPSs stands in their response mecha-nism. According to NIST [8], an IPS is a software that has all the capabilities of an IDS and can also attempt to stop possible incidents. The methods that an IPS apply to stop detected attacks are various, and depends on the software framework of the response module. An IPS can collaborate with a firewall and

(14)

terminate the network connection or user session used for the attack. Chang-ing the content of malicious packet is another way to block a given attack: an IPS could replace some portions of an attack to make it benign [8]. IDS does not do this: it only alerts the system administrator whenever a signature is matched or a malicious behavior is detected.

It is also worth mentioning the Intrusion Response Systems (IRSs). These systems perform similar function to IDS and IPS but they use multiple type of responses and select the right one in each different situation [13]. The response mechanism can be proactive or reactive. The first one is an approach that controls a potential incident activity before it happens. The second one takes immediately or in real-time a response action to protect the system against the detected attack. IRSs are able to initiate a collaboration between other security appliances, such as working with firewalls to block suspicious traffic, working with honeypots to collect attackers information and trace attackers sources, and also redirect connections for other precautions.

In our work we make Bro NIDS collaborate with a firewall and also with an external packet inspector. All the proposed defense policies contains a set of firewall rules. The majority of these rules uses to block network connection used for detected attack. In a specific attack that we describe in Section 2.9, the defense policy consists on redirect the traffic through the custom packet inspector that we describe in Section 3.3.3.

Several different approaches are studied in research to overcome the prob-lems considered in this work. In [9] Uribe and Cheung propose an integrated, constraint-based approach for modeling Firewall and NIDS joint configura-tions. They take into account the possibility of multiple firewalls and NIDSs deployed in a protected corporate network and they develop a tool for the specification and verification of that network. This tools is also able to auto-matically generates NIDS configurations that are optimal relative to a given cost function based on false positive rate. In his PhD thesis J. Lane Thames de-signs a modular, adaptive, and integrable framework that models a distributed firewall and active response architecture [16]. The dissertation also provides an

(15)

implementation of an hardware semantic path merger packet classification sys-tem, used by the proposed security system architecture. Yuan et al. propose in [20] the Architecture-Based Self-Protecting Software System (ABSP). The proposed ABSP is able of detecting and mitigating security threats construct-ing an architectural representations of the applications hosted in the protected system. Their main goal is to provide a disciplined and repeatable process for engineering self-protecting software systems. To this end they propose several architecture-level self-protection patterns that provide reusable detection and adaptation strategies for solving well-known security threats. They finally re-alize some of these patterns on top of an existing architecture-based adaptation framework named Rainbow [3]. Another interesting related work is given in [29]. In this work Sendi et al. propose a framework for selecting and deploying optimal countermeasures in an IRS. In this framework the IRS selects the best countermeasure to apply by taking into consideration the attacked resources, the resources being used by the user, the load of the system, the severity of de-pendency between services (Service Dede-pendency Graph), and even the history of previous deployments (countermeasures effectiveness). Countermeasures are selected dynamically based on the solution of a multi-objective optimization problem. The considered objectives are: maximizing the security performance, minimizing the security impact on service quality (QoS), and minimizing the security deployment cost.

2.4 The Bro Network Security Monitor

Bro is a passive, open-source network traffic analyzer [34]. Vern Paxson in-troduced it in 1998 in the original Bro paper published by USENIX Security Symposium [2]. Its main task consists on inspecting all traffic on a link and searching for signs of suspicious activities.

Bro NIDS actually implements all the tasks of a normal IDS. It has an extensive set of log files, that record network activity in high-level terms. Bro comes with built-in functionality for a range of analysis and detection tasks,

(16)

e.g. files extraction from HTTP sessions, malware detecting by querying exter-nal registries, reporting for vulnerable application versions seen on the network, detecting SSH brute-force, and so on.

The key difference that makes Bro better than other IDSs is that it repre-sents a platform for traffic analyses that is fully customizable and extensible [34]. To this end, Bro provides users with a domain-specific, Turing-complete scripting language for expressing arbitrary analysis task [40]. This leads Bro to be more than a classic signature-based IDS. Besides the fact that it sup-ports this standard feature, Bro scripting language enables system admin-istrators and security specialists to implement very different approaches for finding malicious activity (e.g. semantic misuse detection, anomaly detection and behavioral analysis) [34]. Moreover, Bro targets high-speed, high-volume network monitoring by supporting scalable load-balancing with Bro Cluster architecture [41]: it consists on a set of systems jointly analyzing the traffic of a network link in a coordinated fashion. The details about this type of deployment and its component are given in the next section.

In the remainder of this section we describe the most important components of this powerful IDS and we briefly presents its architecture. We do not mention two other components of Bro that are not considered in this work: those are the Intelligence Framework and the NetControl Framework. The details of the specific features that those components implements can be found in [42] and [43].

2.4.1 Architecture

Figure 1 describe the Bro internal architecture (standalone deployment). It is divided in two main components: the event engine and the policy script interpreter.

The event engine reduces the incoming packet stream into a series of high-level events. These events are abstraction of what has been seen on the wire. Each event does not perform any interpretation on the stream packets that it

(17)

Figure 1: Bro internal architecture [34]

represents: it only reflects network activity in policy-neutral terms [34]. The policy script interpreter has the role to perform interpretation of events produced by event engine. The script interpreter executes a set of event han-dlers that express security policies to be applied on the generated events.

These scripts are written in Bro scripting language and they can be cus-tomized and extended as needed. They can derive properties and statistics from the input traffic using the Summary Statistics Framework described in Section 2.4.5. They can generate alerts with Notice Framework described later in in Section 2.4.3. Moreover, they can execute arbitrary external programs on demand. All this features enable network administrators and security spe-cialists to implement their own defense policy without much effort.

If we consider Bro Cluster deployment, the structure is a bit more complex as can be seen in Figure 2. The structure described in Figure 1 represents only one component of a Bro Cluster: the worker. The full component set of such cluster configuration is composed by: frontend, logger, manager, proxy and worker. The frontend can be a discrete hardware device or on-host technique: its task consists on splits traffic into many streams or flows that will be then analyzed by the workers. The logger is able to receives log messages from the

(18)

rest of the nodes in the cluster exploiting Bro communications protocol. When logger is not defined, the manager will receives log messages and notices from the rest of the nodes. The manager also takes the “final action” whenever it receives a notice for a signature matching or malicious behavior. The proxy automatically manages synchronized state across connected Bro Processes. Fi-nally the worker is the Bro process that is able to sniff network traffic and do protocol analysis on the reassembled traffic streams.

Figure 2: Bro Cluster architecture [41]

In this work we use the standalone deployment of Bro for simplicity rea-sons. However, it is also worth pointing out that distributed deployment exists in order to protect high-speed and high-volume traffic networks which are very used nowadays. Our approach is fully compatible with a distributed deploy-ment.

(19)

2.4.2 Event handlers and Hooks

As described in the previous section, events model what has been seen in the network traffic. Bro defines a set of built-in protocol analyzers that define a set of events. Those events effectively model the various states of a specific protocol. Event handlers are actually functions that can be attached to an event in order to collect information, statistics or properties about the specific detected situation. Event Engine will execute each event handler that is asso-ciated to any detected event. Unlike normal functions, event handlers never return value. It is also possible to define delays of invocation of a specific event handler, or define multiple implementation with different priority [44].

A Hook is another flavor of function. It can be thought of as multi-bodied functions and using them looks very similar to handling events. The difference is that they do not go through the event queue like events. For each defined hook type, more than one implementation can be defined. As in the event handlers, different priorities of execution can be given to various implemen-tations. Finally the returned value is an implicit boolean: true means that all handlers for the hook have been executed; false means that only a subset of the handlers were actually executed. This last case is possible because one peculiar feature of Hooks is that it is possible to short-circuit the execution of remaining hook handlers by executing a break statement inside the body.

2.4.3 Notice Framework

Bro comes with a lot of policy scripts already included in the base version which perform a wide variety of analyses. As introduced in Section 2.4, those scripts do not determine whether or not the detected behavior are important: their task consists on flag those situations as potentially interesting. It is then in charge of network administrators or of security specialists to tune local configuration defining which of the situations marked as “interesting” are in fact actionable. This reveals an important peculiarity of Bro: decoupling detection and reporting allows Bro to address the different needs that sites

(20)

may have [45].

The role of reporting potentially interesting events is the main task of the Notice Framework. Whenever a signature is matched or a malicious behavior is detected, the analysis script flags these situations by calling the NOTICE function. Any Notice has a Notice::Type, which reflects the kind of activity that has been seen.

The function NOTICE takes a single argument of the Notice::Info record type. The fields of Notice::Info mainly used when raising notices are the fol-lowing [45]:

• $note is an enum value which represents the notice type;

• $msg contains the human readable message to be displayed in log/email; • $conn contains information about the connection record associated to

this notice, if it is available when the notice is being raised;

• $id contains the conn_id record associated to this notice, if it is available when the notice is being raised (it contains address/port of originator and responder of the given connection);

• $src contains the IP address of the attacker;

• $identifier is the unique identifier of this notice (useful for notice sup-pression);

• $suppress_for indicate the suppression interval for this notice.

Once a notice is raised, network administrators or security specialists can apply a set of actions by writing custom Notice::policy hooks. A Notice::policy hook provides the mechanism for applying actions and generally modifying the notice before it is sent onward to the action plugins [45]. The set of available actions in the considered version (Bro 2.5.0) are:

• Notice::ACTION_LOG writes the notice to the Notice::LOG logging stream [46];

(21)

• Notice::ACTION_ALARM logs into the Notice::ALARM_LOG [46] stream and email the contents to the email address defined in the Notice::mail_-dest variable [45];

• Notice::ACTION_EMAIL sends the notice in an email to the address or addresses given in the Notice::mail_dest variable;

• Notice::ACTION_PAGE sends an email to the pager email address given in the Notice::mail_page_dest variable.

External programs can be also executed in this phase by call the Exec::Command function. This enables system administrators to have a wider range of actions to be taken in the various situations.

2.4.4 Signature Framework

Bro scripting language is the primarily method used for defining detection policies. However, since Bro supports also signature-based detection meth-ods, it provides an independent signature language for doing low-level pattern matching. Sometimes signatures are closer to what many people are familiar with from using other NIDS (e.g. Snort [38]).

Signature Framework offers to users the possibility to defines signatures for the analysis of network traffic. They can be defined for analyze packet headers in order to check if there are unexpected values in header fields. It is also possible to define regular expressions that match the content of a packet (e.g. payloads). Another important feature of this framework is that it can be used to identify MIME types of files independently of the network protocol/-connection over which the file is transferred.

Those are only a subset of the features that this powerful framework actu-ally offers. We describe later in Section 3.3.2 the considered signature in the SQL-Injection attack case. For a full disclosure about those other features of this framework, the reader can go to [47].

(22)

2.4.5 Summary Statistics Framework

The Summary Statistics Framework (SumStats) provides data structures which enable users to collect measure aspects of network traffic (e.g. properties and statistics about a specific situation). This framework aims to define a mech-anism for consuming unbounded data sets and making them measurable in practice on large clustered and non-clustered Bro deployments [48].

The SumStats processing flow is divided into three pieces. Observations (SumStats::Observation), where properties and aspects of an event are ob-served and given to the associated SumStats instance. This is a single point of data. It contains a key (SumStats::Key), which uniquely identifies the ob-servation itself. These obob-servations are then collected in the same obob-servation stream by Reducers that also take some sort of summary statistic measure-ments above the considered stream (e.g. average, summing, random sampling, variance). This phase is used to reduce the full unbounded set of observations down to a smaller representation, namely the results of the selected calcula-tions. More than one reducer can be defined, but results are collected within each of them per-SumStats::Key. Finally in the SumStats instance, created with SumStats::create function, one or more reducers are collected over an interval, also known as an epoch. Is also possible to define callbacks for moni-tor thresholds or viewing collected and measured data. The SumStats::create function takes a single argument of the SumStats::SumStat record type, which is composed of the following information:

• name is an arbitrary name for the SumStat instance;

• epoch is the interval in which observation are collected. Each thresh-old based detection instance needs to be set to a value that should be expected to happen within this epoch;

• reducers contains the set of Reducers to be used in this SumStat instance; • threshold_val is the function that will be called once for each observation in order to calculate a value used for thresholding (optional parameter);

(23)

• threshold is the threshold value for calling the threshold_crossed callback (optional parameter);

• threshold_series contains a series of threshold for calling the threshold_-crossed callback. It is used in case more than one threshold value is needed (optional parameter);

• threshold_crossed is the callback that is called when a threshold is crossed (optional parameter);

• epoch_result is the callback that receives each of the results at the end of the analysis epoch. This function is called once for each SumStats::Key (optional parameter);

• epoch_finished is the callback that will be called when a single collection interval is completed (optional parameter).

This framework is very useful to collect and correlate different events that belong to the same malicious behavior that may arise in the network. We discuss later in Section 3 some Bro policy scripts which use this framework.

2.5 Linux Kernel Firewall: iptables software framework

A firewall is a combination of hardware and software that isolates an orga-nization internal network from the Internet at large, allowing some packets to pass and blocking others [21]. Iptables is a user-space application program that enable system administrators to configure the tables of the Linux firewall embedded in the kernel with Netfilter Xtables modules. This program is used to setup, maintain, and inspect the tables with specific rules that apply to incoming IP packets. Netfilter defines four built-in tables which have different purposes [23]:

• mangle is used for apply mangle targets like TOS for Type of Service fields modification, TTL to change Time to Live field value, and MARK to set a special mark value to the packet;

(24)

• nat is used for Network Address Translation (NAT) purposes;

• filter is used for any filtering purposes and is mainly the place where packets are accepted or dropped on the floor;

• raw is used to make decision on the packet before connection tracking is applied (e.g. before connection-state checking or packet de-fragmentation). Custom user-defined tables can be added for special behavior not accounted in default configuration. Each table contains a set of built-in chains which are traversed in different situations. The way different tables and chains are traversed is shown in Figure 3. Not all the tables contain the same chains. It is also possible to add custom user-defined chains but the default ones are: “PRE-ROUTING”, “INPUT”, “OUTPUT”, “FORWARD”, and “POSTROUTING”.

Figure 3: Netfilter Firewall tables and chains traversal [11].

Incoming packets traverse different tables and their chains depending on the specific routing decisions that take place three times in the Linux Fire-wall. According to Figure 3, the first one is applied right after traversing the “PREROUTING” chain of raw. The result of this routing decision tells if the packet has to be delivered to the local machine or if it has to be forwarded. The second routing decision take place after the local process: this phase is

(25)

executed only if the considered packet is delivered to the local machine. The final routing decision is taken right before “POSTROUTING” chain of mangle tables.

Each chain contains a set of firewall rules that specify criteria to match packets, and also a target which models the action to be taken on the matched packet. We call them chain because each incoming packet traverses them in order from the first rule to the last one. If none match is found, the default target of the considered chain is applied to the packet. The set of default target value are: “ACCEPT”, “DROP”, “QUEUE”/“NFQUEUE”, or “RE-TURN”. “ACCEPT” means to let packet through. “DROP” means to drop the packet on the floor. “QUEUE” means to pass the packet to user-space and “NFQUEUE” is an extension of this target that allows to divide packets in different queues for load balancing (only with Kernel versions 2.6.14 or later). “RETURN” has the same meaning of reaching the end of the chain without a match: the default target policy of the chain is applied.

2.6 SSH Service and Brute-Force Attack

According to [RFC 4251] the Secure Shell (SSH) is a protocol for secure remote login over an insecure network. The SSH protocol consists of three major com-ponents. The Transport Layer Protocol defined in [RFC 4253] provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol defined in [RFC 4252] enables the authentication between the client and the server. Finally the Connection Protocol defined in [RFC 4254] provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections, multiplexing all of them into a single encrypted tunnel.

Since in SSH sessions the authentication is done by user ID and password combination, this is one of the possible target of a brute-force attack. This type of attack is nothing more than guessing the userID/password combination on a service that attempts to authenticate users before access is granted [18].

(26)

Even if it exploits a straightforward approach, this attack is one of the most effective way to gain access on a Unix system.

Attackers uses other services active in the system (e.g. finger, rusers, send-mail) to identify potential system user IDs. Once an attacker has a list of user accounts, he can begin trying to gain shell access to the target system by guessing the password associated to one of the discovered IDs. The vulner-ability stands on the user side: mostly of the time many user accounts have either a weak password or not password at all. In this situations attackers can succeed in their brute-force attack.

Although it is possible to guess passwords by hand, there exist automated brute-force tools that can speed this type of attacks. Two of the most popular are THC Hydra [35] and Medusa [58]. They accept a list of user accounts and passwords and try to authenticate to a target machine with each possible ID/password combination. We describe later in Section 4.2 our test case that implements SSH brute-force attack using THC Hydra.

2.7 Web Applications and SQL-Injection Attack

The HyperText Transfer Protocol (HTTP) is the heart of the Web. It is the underlying protocol of Web application and it is implemented in two programs: a client (e.g. Web browser like Firefox) and a server (e.g. Apache, Microsoft Internet Information Server). Those two components talk to each other by exchanging HTTP messages. HTTP is defined in [RFC 1945] and [RFC 2616] were the structure of these messages is described together with the way client and server exchange the messages [21]. HTTP uses TCP as its underlying transport protocol.

Any Web site is composed by Web pages (also called document) that con-tain objects. An object is simply a file addressables by a single Uniform Re-source Locator (URL). Whenever an HTTP connection is established, the client will requests for one or more Web pages. It is in charge of the Web server to retrieve all the objects that belong to the requested document and

(27)

send them back to the client.

With the arrival of Web 2.0, Web sites and Web applications start to rely on dynamic content to achieve the appeal of traditional desktop windowing programs. Dynamic means that most of the objects that compose Web pages are computed dynamically on the fly whenever the Web page is requested by clients. Web 2.0 is not an update to any technical specification: it consists on a new methodology to design and use Web pages. This new methodology has enabled the possibility to implement Web application like social media (e.g. Facebook, Twitter), blogs, wikis, video sharing sites (e.g. YouTube), and more appealing Web applications in general.

On the one hand, this Web 2.0 technologies have improved Web in usability, bridging the gap between client and server, and enabling Web applications to perform a wide range of new powerful functions. On the other hand, with this new advanced peculiarities the Web popularity is become enormous and this has driven it to the status of prime target for attackers [18].

One of the most insidious attacks on a Web application involves hijacking the queries used in the front-end scripts. This technique is used to gain control of the application or data [18]. The most powerful mechanism to achieve this is using SQL-Injection attacks. Those type of attacks target WEB application which uses as back-end datastore a Relational Database Management System (RDBMS). These injection flaws can be devastating because the service often trusts the web application fully and lacks of sanitizing techniques in the back-end source code [18].

SQL injection are mostly implemented by injecting malicious SQL state-ments inside a dynamically constructed query. If the application does not sanitize the received input, an attacker has “direct” access to the back-end database. He can use this flaws to construct malicious queries to be executed in the RDBMS and so gain access to data (e.g. user credentials, user informa-tions).

(28)

boolean-based approach that uses boolean expressions to create tautologies. These boolean expressions are injected to make a “WHERE” condition always true. These technique can be used to bypass authentication or data extraction. The use of Subqueries to be injected using GET/POST/COOKIE parameters is an-other technique to retrieve information ranging from boolean indicators (e.g. “is ’A’ the first character of the foo user passwd? true/false”) to data ex-traction (e.g. extract complete record). Another technique is to inject illegal queries to force DBMS report some error messages. Even if a prerequisite of this technique is that the Web Server must be configured to report DBMS errors, they can be used for database fingerprinting or data extraction as well. Another technique is to use Union queries. In this case the attacker wants to add values to the result set of the attacked query. In this way he can change the application behavior and also bypass authentication, extract schema and extract data. Finally the Inference technique is mostly used when the Web App does print neither result sets nor error messages. The attacker deduces in-formation performing polar(true/false) question to the DBMS. This technique actually enables the implementation of the so called Blind SQL-Injection. The attacker injects a SQL code that contains a polar question (Inference). Then the injection causes the Web App to change its behavior depending on the answer to the polar question. Consequently the attacker can extracts schema information or data (e.g. username/password combination). In the test cases that we conduct and describe in Section 4 we take into account Blind SQL-Injections with other techniques like Union query and Subqueries. Further information and examples about SQL-Injections techniques can be found in [14].

Most of the times SQL-Injection can be effectively and successfully imple-mented only because of back-end developers coding style: using unbounded string concatenation without any sanitizing technique, lead the application to be vulnerable to SQL-Injections [14].

SQL-Injections are typically performed manually. However, automated SQL Injection tools exist like SQLNinja [49] or sqlmap [36]. We talk about

(29)

our SQL-Injection attack scenario and related test cases in Section 3.3.2 and Section 4.3.

2.8 IP protocol and Fragment Overlap Attack

The network layer provides forwarding and routing capabilities. Internet net-work layer provides a single service, known as best-effort-service. With this kind of network service model, timing between packets is not guaranteed to be preserved, packets are not guaranteed to be received in the order in which they were sent, nor is the eventual delivery of transmitted packets guaranteed [21].

Internet Protocol (IP) is the first major component of Internet. It actually defines the structure of datagrams that are sent on Internet. There are two versions of this protocol: IP version 4 (IPv4) defined in [RFC 791] and IP ver-sion 6 (IPv6) defined in [RFC 2460; RFC 4291]. In this work we consider only the IPv4 version. The other two major components are the routing component and the Internet Control Message Protocol (ICMP). The reader can find a complete description about those last two components in [21].

IP datagrams have a defined syntax and semantic. Its defined fields are represented in Figure 4: for a complete description of each fields the reader can read [21].

As it is widely used in the Internet network, IP protocol can be also used for implementing attacks. In our work we have considered the Fragment Overlap Attack which is an IDS evasion technique that can be used either for Denial of Service (DoS) or as a vehicle for other attacks (e.g. SQL-Injection).

According to [7], the Fragment Overlap Attack is based on manipulating the 13-bit fragment-offset field of the IP header. This field is used by the destination system to know how to reassemble the whole original packet that has been fragmented on the path. A simple example is given in Figure 5.

(30)

Figure 4: IP Datagram format [21].

Figure 5: IP Fragment Overlap Attack [7].

In the scenario shown in Figure 5 the attacker creates two (or more) frag-ments for each IP packet. One fragment has the TCP header, and a piece of innocuous-looking data that does not trigger the signature, like “cat /etc/fred”. The second fragment has an offset value that is a lie. The offset is too small, so that when the fragments are reassembled, they overlap. The second fragment is designed to overwrite part of the first fragment with the text “shadow”, making it evil when the two parts are brought together. The IDS does not detect any malicious content in the first fragment and it also does not perform

(31)

any other analysis on the second fragment that is supposed to be benign as well. When the two fragments arrive at the targeted protected server, the re-assembly overwrites part of fragment 1 (“fred”) with the data from fragment 2 (“shadow”). Finally the TCP/IP stack passes the packet to the application, which receives the malicious payload “cat /etc/shadow”. The attacker has evaded the IDS.

Since fragmentation is used to send packet that exceed Maximum Trans-mission Unit (MTU) of the underlying link layer (Layer 2 in the OSI Model [21]), it is not an always evil feature. What enables attackers to perform those type of attacks is the lack of reassembling specification in the RFC. There is not a defined way to reassemble a fragmented flow. It is up to the operating sys-tem to implement a convenient way to perform this operation. Consequently, some operating systems do not properly handle fragments that completely or partially overlap. Consequently, it is possible that the IDS machine reassemble the flow in a different way with respect to the victim side [5]. This enables an attacker to exploit this method to evade and IDS or IPS.

The Fragment Overlap Attack is actually one of the attacks that can be implemented using IP fragmentation. Other attacks like Ping O’ Death, Tiny Fragment Attack, Teardrop Attack, The Rose Attack and The Unnamed At-tack are all implemented by exploiting IP fragmentation. However, most of them have been fixed several years ago and they may still exist only in relic systems[22].

There exist a tool named FragRouter [24] that can be used to create frag-ment attacks for evasion. This tool was created by Dug Song, and implefrag-ments a variety of fragmentation attacks. It supports more than 35 different ways of slicing and dicing packets to manipulate the flow of data between a source and a destination [7]. It really is a router, implemented in software. Attackers install it on one of their own systems and then use any attack tool to send packets through the machine with FragRouter installed.

(32)

a particular attack tool to launches against a target. This tool generates at-tack packets that are funneled through FragRouter machine, which slices and dices the packets according to any one of its 35 fragmentation and scrambling options. Then, FragRouter forwards these packets across the network to the target machine. The separation of the fragmentation function from the par-ticular attack tool allows an attacker to choose any tool and any attacks he want to implement.

We discuss about the selected defense policy in our Fragment Overlap At-tack scenario providing a description of the fragmentation options used in test cases in Section 3.3.3 and in Section 4.4.

2.9 TCP protocol and Segment Overlap Attack

A transport-layer protocol provides for logical communication between appli-cation processes running on different hosts. The term “logical” means that from the application point of view, it is as if the hosts running the processes were directly connected. In reality, the two hosts can be on opposite side of the planet, connected via numerous routers and different link types [21]. This kind of protocols can be used by application processes to send messages to each other, without take care of the physical infrastructure used to carry these messages.

More than one transport-layer protocol may be available to network appli-cations. For example, the Internet has two protocols: Transmission Control Protocol (TCP) defined in [RFC 793, RFC 1122, RFC 1323, RFC 2018, RFC 2581], and User Data Protocol (UDP) defined in [RFC 768]. Each of these protocols provides a different set of transport-layer services to the invoking application. We consider in our attack scenarios only the TCP protocol as the transport-layer that can be used for implementing evasion techniques. For a complete description of UDP protocol, the reader can read in [21].

TCP protocol offers reliable data transfer service at transport-layer. It is said to be connection-oriented because before one application process can begin

(33)

to send data to another, the two processes must first complete the so called “3-way handshake”. In this initial phase, both sides have to initialize many TCP state variables associated with the TCP connection. These variables are used to prepare all the resources needed on both sides to guarantee reliable data transfer. A TCP connection is also always point-to-point between a single sender and a single receiver. TCP uses segments as transmission unit. They are similar to packets, but they are not because they are always carried by a network-layer datagram. A TCP segment has its own structure, syntax and semantics that is represented in Figure 6. During the initialization phase, the Maximum Segment Size (MSS) is defined typically according to MTU at link-layer. MSS ensure that a TCP segment (when encapsulated in an IP datagram) plus the TCP/IP header length (typically 40 bytes) will fit into a single link-layer frame.

Figure 6: TCP Segment format [21].

The Segment Overlap Attack is very similar to the Fragment Overlap Attack described in the previous section. As described above, TCP protocol does not have the notion of packets. It is a streaming protocol that is made up of multiple segments. As shown in Figure 6, there is not any field in the TCP

(34)

header that is used for segmentation purposes. Each segment has a defined position within the stream which is identified by its sequence number and the length of the carried payload. Whenever a stream of segments arrives to the destination host, it is the TCP/IP stack that will align them properly according to the received sequence numbers. This permits the receiver host to reconstruct the original TCP payload [21].

If we consider the example given in Figure 5, the same kind of attack can be done using segmentation at the TCP level. Suppose that our IDS has the same signature that is looking for “cat /etc/shadow”. The attacker can craft two different segments that overlap to implement this evasion technique. The first segment will have “cat /etc/fred” as payload and a sequence number equal to 11_{. Then the attacker create the second segment which contains payload}

“shadow” and it set sequence number to 10. We know that the payload length of the first segment is 13: its position into the stream is from byte 1 (sequence number of the first segment) to byte 13. The second fragment position into the stream is from byte 10 (sequence number of the second segment) to byte 16. So it is clear that when those two fragments are reassembled, they overlap. Also in this case, if the IDS does not reassemble the stream with the same policy as the target machine, the attacker can evade detection.

As in the Fragment Overlap Attack, this type of evasion technique is pos-sible due to lack of reassembling policy specification in RFC definition. If the reassembly policy of the IDS machine is different with respect to the target machine one, the attacker can reach the target with malicious payload evading the IDS or IPS deployed [10].

The FragRouter tool described in the previous section can be used to im-plement this evasion technique as well. There exist a lot of fragmentation and scrambling options in this tool that exploit TCP protocol. We describe all fragmentation options that this work consider in Section 4.4. The details about the selected defense policy in the considered Segment Overlap Attack

1_{In a real situation, the initial sequence number is selected randomly. We use 1 in this}

(35)

scenario are described in Section 3.3.3.

2.10 Scapy: Interactive Packet Manipulator Program

Scapy is a Python program that enables the user to send, sniff and dissect and forge network packets. This capability is mostly used to construct tools that can probe, scan or attack networks [50].

Scapy does two thing: sending packets and receiving answers. It offers the possibility to define a set of packets specifying all layers (e.g. link-layer frame, network-layer packets and transport-layer segments) that can be sent to a given destination host. Whenever the answers come back, it matches requests with answers and return a list of packet couple (request,answer) that can be inspected and analyzed. If something goes wrong, it also returns the list of unmatched packets that arrives. The big advantage with respect to other similar tools is that the answer is not reduced or interpreted: the whole packet is offered to the script writer.

We use this program in our packet inspector that we describe in Section 3.3.

(36)

3 Proposed Defense System

In this section we describe the proposed system, and the selected type of attacks that are considered in this work. The idea behind this solution is to enable a collaboration between Bro NIDS [51] and the ubiquitous Linux Kernel Firewall [23] described in Section 2. This collaboration enables to construct a system which is configured to respond as soon as attacks are detected.

On the one hand, the resulting system is able to recognize specific patterns of different attacks using Bro peculiarities. On the other hand, the Linux Kernel Firewall is the core of the response engine of this Intrusion Prevention System.

3.1 Architecture

The goal of this work is to construct an IPS starting from an existent open-source NIDS called Bro, introduced in Section 2.

As described in Section 2, an IDS is used to monitor the network traffic for detecting specific situations that match a signature or are classified as malicious. In order to evolve into a Prevention System, an IDS has to be extended with some security policies to be automatically applied whenever some unexpected and possibly malicious behavior is detected.

From this point of view, Bro comes with a very extensible and tunable structure. Bro implements a lot of built-in functionalities for a range of analysis and detection tasks. It also offers to an expert user the possibility to completely customize and extend the base version to better fit the various situation on each site. Moreover it has the powerful Notice and Summary Statistics frameworks that enable security specialists to have a flexible detection engine, with tunable alerts and a wide range of actions to be selected and executed. We have already discussed those peculiarities in Section 2.

(37)

Sys-tem. Using the Bro scripting language we extend the built-in policy scripts with custom actions to be taken in case of detected attacks. Moreover we propose also some new policy scripts to enable detection of evasion techniques not considered in Bro base version.

Bro reasons in terms of packets and groups them into the same flow or connection depending on the underlying protocol. For this reason one of the possible response engine core component is a firewall. With this component on board, Bro can actively defense a protected network by deploying a set of rules that effectively stop the detected attack. In our considered scenario we deploy Bro in a Linux machine. Consequently, as introduced in Section 2, we use the Linux Kernel Firewall as the core response engine.

We define each security defense policy as a set of firewall rules that are automatically deployed on the protected network whenever the corresponding attack is detected. We describe each considered detection module together with its defense policy in Section 3.3.

3.2 How Bro collaborate with Linux Kernel Firewall

The base version of Bro NIDS contains a set of Protocol Analyzers for the majority of known protocols. Some examples can be those for HTTP, SSH and TCP protocols that we consider in this work. As described in Section 2, those analyzers define a set of events that model the various step of a connection of the managed protocol. An example can be the http_request event, defined in HTTP Analyzer. This event is triggered for each new HTTP request transiting on the wire.

Each event instance carries a set of information about the triggered event. For example, an instance of http_request contains information about the un-derlying TCP connection, the URI being requested and the HTTP version in use. Each event is generated by the Event Engine during its network traffic analysis task.

(38)

the triggered events. Its unique task is to reduce the incoming packet stream into a series of higher-level events reflecting network activity in policy-neutral terms [34].

In order to make Bro collaborate with the Linux Firewall, we define cus-tom Notice::policy hooks using Bro scripting language. These hooks bodies are attached to specific Notice::Type that are raised whenever the associated sig-nature or malicious behavior is detected. In these bodies we execute external scripts that actually deploy a set of rules in the firewall. Depending on the type of attack, these rules can have blocking or redirecting purposes. The first is used to effectively stop a detected attack. The second is used for redirecting packets to user-space program for further analysis.

In the next section, we describe all the attack scenarios that we consider in this work. For each of them, we describe the detection module and the proposed defense policy to be applied.

3.3 Considered Attack Scenarios

Figure 7: Test Environment

Once we set up the test environment shown in Figure 7, we take a vul-nerability assessment on the considered protected network. As described in

(39)

Section 1.4, in this phase we act as we are attackers. Starting from the vulner-ability assessment, we select four different attacks that a malicious actor could exploit against the considered environment. Then we move in the defense side and we select a defense policy to block each considered attack. Finally, we write extensions of Bro using its scripting language to enable detection and prevention in those attack scenarios.

The protected network is composed by two machines. The first one is a Linux server hosting SSH service. The second one is a LAMP instance (Linux, Apache, MySQL, PHP) with a running Wordpress Content Management Sys-tem (CMS) (version 3.1.3). Then there is an instance of Bro deployed at the edge of the protected network. Bro machine acts also as firewall for the in-ternal network. The description of attacker side and the details about the implemented attacks will be given in Section 4.

The selected attack scenarios are: SSH brute-force attack against 10.0.10.27 host machine; SQL-Injection attack against 10.0.10.26 host machine (exploit-ing an old Wordpress vulnerability [15]); and finally a Fragment Overlap Attack and a Segment Overlap Attack against 10.0.10.26 host machine to enable SQL-Injection attack as in the previous case. These two last attacks are actually evasion techniques used to evade Bro SQL-Injection detection module.

The first two type of attacks are already managed in the considered Bro version. Bro comes with a detection module for SSH brute-force attack that relies on tracking the number of failed logins arrived from a host. The detec-tion module of SQL-Injecdetec-tion attacks is based on a set of regular expressions that are used to match each requested URI. The other two evasion techniques have no built-in detection module inside Bro. In order to protect the system even from these kind of attacks, we write two different detection modules that correlate various set of generated events that identify the considered attacks.

All the selected attacks are implemented against the test environment shown in Figure 7 in order to prove the effectiveness of the proposed defense policies.

(40)

In the reminder of this section we describe the various Bro detection mod-ules for the considered attack scenarios and we also present the implementation of the selected defense policy scripts.

3.3.1 SSH Password brute-force

As described in Section 2, brute-force attacks exploit straightforward approach to guess password, based on a set of previously retrieved list of user IDs. Most of the times, malicious actors succeed to implement this type of attack because of end-user password weaknesses.

In this section we focus our discussion on the brute-force attack targeting SSH service, describing the Bro SSH brute-force detection module. We also present our selected defense policy and we discuss a set of countermeasures that can be applied in a Linux system to prevent this kind of attack.

Bro has a specific Analyzer for SSH service that defines a set of events, one for each state of a SSH connection. One of these events is ssh_auth_failed modeling a failed SSH authentication from a given host. The SSH brute-force detection module uses this event to monitor the number of failed logins. A threshold is defined in the SumStats instance (Code 2) in order to define the maximum number of accepted failed logins. Whenever this threshold is crossed by a single host, a Password_Guessing notice type is raised. We now describe the code of this detection module (code listings 1, 2, 3) and we explain how it works [52].

First of all, the detection module defines a set of variables as listed in Code 1. Bro scripting language syntax allows to define variables by using an export block (line 3). The new Password_Guessing notice type is defined in line 5 to model this attack in the Notice Framework. Then the threshold for the number of admitted failed SSH logins is defined in line 13 with the

SSH::password_guesses_limit variable. By lowering this value (default value is set to 30), you can increase your security level but also the number of false positives. Then the epoch interval is defined in the SSH::guessing_timeout

(41)

variable at line 14. This value is used later in the SumStats initialization phase to define the detection interval. Finally in this detection module the set of addresses to ignore is defined with the SSH::ignore_guessers variable at line 15. The redef keyword at the end of each definition means that the value can be modified later as needed.

1 module SSH;

2

3 export {

4 redef enum Notice::Type += {

5 Password_Guessing,

6 Login_By_Password_Guesser,

7 };

8

9 redef enum Intel::Where += {

10 SSH::SUCCESSFUL_LOGIN,

11 };

12

13 const password_guesses_limit: double = 30 &redef;

14 const guessing_timeout = 30 mins &redef;

15 const ignore_guessers: table[subnet] of subnet &redef;

16 }

Code 1: SSH brute-force detection module: variable/notices definitions. As shown in Code 1, there is another Notice Type defined: the

Login_By_Password_Guesser. It is raised whenever a successful login at-tempt is made by an host previously marked as password guesser. A script writer uses the Intelligence Framework in order to implement this feature. To this end, the new SSH::SUCCESSFUL_LOGIN Intel::Where type is defined. We does not consider this feature because it is not implemented in the consid-ered Bro version. For a complete disclosure about Intelligence Framework and its features the reader can read [42].

As described above, the defined variables are used in the SumStats instance initialization. To do this, a custom implementation of the bro_init() event handler is given. The event engine generates this event just before normal input processing begins. The bro_init() event is used mainly for initialization purposes, and in this case contains the SumStats instance initialization of the SSH brute-force detection module.