A new approach to deploy a self-adaptive distributed firewall

A new approach to deploy a self-adaptive distributed firewall Distributed firewall systems emerged with the proposal of protecting individual hosts against attacks originating from inside the network. In these systems, firewall rules are centrally created, then distributed and enforced on all servers that compose the firewall, restricting which services will be available. However, this approach lacks protection against software vulnerabilities that can make network services vulnerable to attacks, since firewalls usually do not scan application protocols. In this sense, from the discovery of any vulnerability until the publication and application of patches there is an exposure window that should be reduced. In this context, this article presents Self-Adaptive Distributed Firewall (SADF). Our approach is based on monitoring hosts and using a vulnerability assessment system to detect vulnerable services, integrated with components capable of deciding and applying firewall rules on affected hosts. In this way, SADF can respond to vulnerabilities discovered in these hosts, helping to mitigate the risk of exploiting the vulnerability. Our system was evaluated in the context of a simulated network environment, where the results achieved demonstrate its viability. Keywords: Distributed firewall, Self-adaptive software, Network security, Software vulnerability assessment 1 Introduction of the network is no longer effective, as centralized bor- Several institutions all over the world deal with com- der firewalls are not able to deal with attacks originated plex network infrastructure, involving an increasing num- from inside the security perimeter [1]. Today’s technol- ber of equipment (e.g., switches, routers) and servers, ogy movements, such as Bring Your Own Device (BYOD) usually providing different services. These environments and the availability of 3G/4G connections, mean that a may contain several types of vulnerabilities that could malicious user has already penetrated the border defense. be exploited by an attacker. In this way, it is extremely This is exacerbated when we consider university environ- important to maintain software systems up to date with ments, which are usually open to the public in general, and versions that fix known vulnerabilities. Considering the contains some servers maintained by researchers, with diversity of activities and variety of research topics con- outdated and potentially vulnerable services. ducted throughout an university, it is common to find Distributed firewall systems [2] have emerged as a solu- situations where several services, and servers, need to be tion for dealing with incidents originated from inside the provided for different groups of people, and more often secure perimeter, by including firewalls in different points than not, maintained by these groups. This leads to an of the network and servers. In such systems, a centralized inconsistency in management and security procedures, control mechanism is responsible for distributing firewall where servers poorly configured, with outdated services, rules to each point of the network, and hence it is possi- or both may become potential targets for attacks. ble to control what services running on those servers are In this context, the traditional approach for network exposed on the network, and only for specific client hosts. security, in which firewalls are deployed on the border However, the application of distributed firewall also brings some challenges, such as the management of these *Correspondence: kaduardo@imd.ufrn.br firewalls and their rules, and the response time in case of Digital Metropolis Institute, Federal University of Rio Grande do Norte (UFRN), an incident. Traditional solutions for intrusion detection Natal, RN, Brazil Full list of author information is available at the end of the article © The Author(s). 2018 Open Access This article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made. da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 2 of 21 or vulnerability assessment usually notify an administra- adaptation, and an evaluation of the whole implementa- tor, who then assesses and decides how to respond to deal tion in a controlled environment. with the situation [3]. However, this approach is usually The remaining of this paper is organized as follows: not fast enough for avoiding information theft, the infec- Section 2 contextualizes our work defining its scope and tion of new systems/servers, or even service unavailability, presenting some background on self-protection. Section 3 mainly for attacks conducted during strategic times, such presents a conceptual view of the proposed SADF archi- as the middle of the night or weekends, when the IT team tecture. Section 4 describes a prototype that has been is usually out of service. implemented to demonstrate our approach feasibility. Moreover, it is possible to identify a gap on the inte- Results from the experiments conducted in a controlled gration between the several tools involved in securing environment to evaluate the proposed approach are pre- a network environment. For example, a Vulnerability sented and discussed in section 5.Section 6 discusses AssessmentSystem(VAS) maydetectavulnerabilityon some related work. Section 7 concludes the paper. a particular server, but the firewall of such system may not react to such detection, as both systems are not inte- 2 Contextualization grated. Such problem becomes more evident when we In a university network infrastructure, such as the Federal consider the dynamic nature of a complex network envi- University of Rio Grande do Norte (UFRN) in Brazil, ronment, in which new devices and services are constantly it is common to find several groups of servers hosting added/removed, and new vulnerabilities are discovered from basic services, like e-mail, Web, and DNS (Domain and patched. Finally, it is worth mentioning that, although Name System), to specific applications. These institutions there are firewall solutions that inspect application pro- usually maintain a network team responsible for manag- tocols, in 2016 more than half of the corporate networks ing these services. However, it is also common to find were still using conventional firewalls [4]. other servers and equipment providing a set of local ser- In this context, the main contribution of this paper vices used and maintained by researchers in their respec- is an architecture for network security based on self- tive laboratories. Such a diverse environment is prone to protection, named Self-Adaptive Distributed Firewall inconsistency in management and security procedures, (SADF). SADF integrates different components that are causing it to be likely susceptible to vulnerable servers due part of a network for supporting the autonomic manage- to misconfiguration or outdated software. Moreover, an ment of its infrastructure in response to security-related university network contains some workstations and wire- incidents. SADF has been deployed on a prototype inte- less access points, which together with the trend of BYOD grating a configuration management system with a VAS and the availability of 3G/4G connectivity, constitute a for managing a distributed firewall, in which possible plethora of equipment outside the control of the central threats can be detected (i.e., servers with vulnerabilities) management team. and appropriate decisions be made for mitigating their The firewall is usually treated as the first line of defense impacts with minimal human intervention. of computer networks [10]. A firewall is a trusted host The motivation for using self-adaptation is the proven that acts as a choking point of one or more networks, effectiveness and efficiency of self-adaptation in dealing usually at the border between a public and a private net- with uncertainty in a wide range of applications, includ- work. The traffic between the networks passes through ing those related to security [5–7]. Our current prototype the firewall, which decides based on a set of rules, which of SADF monitors the hosts of a network, which are then network packet should be allowed to continue or blocked. scanned by a VAS in the search for known vulnerabili- However, as previously mentioned, the limitations of a ties. Once a vulnerability is discovered, firewall rules for centralized firewall, which is not able to protect against reacting to it are defined based on high-level policies. internal attacks, has motivated the definition of a dis- These rules are then applied to individual hosts, effectively tributed firewall model [2]. In a distributed firewall, secu- mitigating the exposure window for the vulnerable server. rity policies are defined in a centralized fashion using SADF was first proposed in [8], in which the main specific language, and then distributed, by secure means, issues related to the theme were presented, together with a to be applied to different enforcement points. These proposal of architecture and a prototype implementation enforcers can either be located on different segregation that demonstrated its viability. Compared to our previous points inside the network, such as routers and switches, work, this article further details the proposed architec- or on each host of the network [1]. Figure 1 presents a ture, which now fully implements a Monitor-Analyse- general view of a network infrastructure where we can Plan-Execute-Knowledge (MAPE-K) feedback control identify a Rules Management Server, which is responsible loop [9] for managing the self-adaptation process. This for dealing with and distributing the firewall rules into the article also presents details about high-level policies different enforcement points, such as switches, servers, and the decision-making process used for controlling or both. da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 3 of 21 Fig. 1 General view of the distributed firewall scope considered in this paper Operating and maintaining this infrastructure requires a One way for achieving self-adaptation is through the continuous effort as, even though there are different tools Monitor-Analyse-Plan-Execute-Knowledge (MAPE-K) for facilitating management and maintenance actions, it feedback control loop over a target system [11]. In this is common to find out that most of these operations way, a self-protection mechanism allows the protected are still manually conducted. For example, the majority system to monitor and analyze its resources to detect of institutions use, apart from firewalls, some tool for possible problems, being able to react accordingly to configuration management, resource and service moni- deal with the detected problem. This reaction depends toring, intrusion detection and vulnerability assessment on the type of monitoring and analysis technique being systems, which scans the network pointing out vulner- employed, type of incident and the type of system being able services. These are important tools for maintain- protected, and can range from emergency system shut- ing the network infrastructure, but there is a lack of down, deactivation of damaged module and replacement integration among them, requiring human intervention for a new instance, user or connection blocking, etc. [7]. for conducting some tasks, and wasting valuable time Figure 2 presents a reference architecture for a sys- between the moment an incident is detected, and an tem that implements self-protection. At a meta-level, we administrator performs some corrective action to mitigate have a protecting sub-system, responsible for implement- its impact. ing the MAPE-K feedback control loop that protects the In this context, software self-adaptation can be used protected sub-system at the base level. The protected sub- for integrating such tools, contributing for automating system contains the system functionality associated with the security management of the network, with minimal the main application logic and may incorporate different human intervention. security mechanisms, such as access control and cryp- A self-adaptive software system is able to modify its tography, and different execution environment such as own structure or behaviour during run-time in order to Software Defined Networks with or without support for deal with changes in its requirements, the environment Network Functions Virtualization. The meta-level subsys- in which it is deployed, or the system itself [9]. Among tem is responsible for detecting security-related incidents the different properties of a self-adaptive system, self- and for the decision-making associated with the use of the protection has been identified as a key concept for build- mechanisms available at the base-level [7]. The base-level ing autonomous self-managed systems. While systems’ sub-system runs over and interacts with, a domain, which architectures are becoming more dynamic and adaptive, can also be monitored for helping in the decision making the majority of the protection mechanisms have kept sim- of the MAPE-K at the meta-level. ple, with security policies usually manually defined, in a Thinking along these lines, a SADF solution can be slow and costly way. employed as a preventive mechanism for dealing with da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 4 of 21 Fig. 2 Self-protection reference architecture [7] well-known vulnerabilities. For example, whenever a par- automation. Figure 3 presents a conceptual view of SADF ticular server contains a vulnerability with a score greater architecture. than a pre-defined value, the firewall could be configured Each phase of the MAPE-K feedback control loop is to only allow access to the server from clients in the same implemented by an engine, which encapsulates the con- network. crete components that allow for each engine functionality. To perform self-adaptation, the Monitor, Analyze, Plan 3 Architecture for self-adaptive distributed and Execute engine components use different models that firewall provide an abstraction of relevant aspects of the managed Our solution for a Self-Adaptive Distributed Firewall system, its environment, and the self-adaptation goals (SADF) is built on top of the MAPE-K reference model [12]. These models are maintained by a knowledge base as the means for logically structuring the different tasks represented in Fig. 3. involved in the management of the security aspects for The Monitoring engine is responsible for collecting network infrastructure, and for integrating the different information about the different servers of the network tools usually involved in those tasks, allowing for their infrastructure. This collection happens through Sensor Fig. 3 Conceptual architecture of the proposed solution da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 5 of 21 interfaces in each server. This data is represented by new firewall rules on the servers. This component must a Server description model, which is a format that can take in consideration mechanisms for guaranteeing secure be manipulated and reasoned upon by the components communication with each server, and configuration man- of SADF. A service description model contains, among agement techniques. other information, details about the operating system, IP The MAPE-K reference architecture allows for the use Address, services’ names, versions and network port. Fur- of different mechanisms for each of its phases, which can thermore, it captures the firewall rules currently in effect be integrated in a number of different interaction pat- on the server. The Monitoring engine is also responsible terns [13, 14]. Thinking along these lines, an SADF-based for obtaining Vulnerabilities descriptions from an exter- solution can be deployed with different components. In nal Vulnerability base. Vulnerabilities are represented our particular architecture, we employed a configuration through CVE , which defines a dictionary and stan- management system and a VAS with the roles of monitor- dard representation format for vulnerabilities descrip- ing and analyzing the network infrastructure. These can tions. These descriptions are published through the CVE be easily replaced by a metrics monitoring system, such as List and maintained by different vulnerabilities databases Zabbix, with threshold-based policies for identifying the (e.g., the NVD ). Vulnerabilities have an associated sever- necessity of adaptation, an IDS or any other analysis prod- ity score calculated based on the CVSS , which defines uctthatcandetect abnormal situationonthe network metrics and formulas for deriving a vulnerability score, infrastructure. The decision-making process of our solu- and a standard format representation. tion is based on high-level policies defined by an adminis- The Analyzer engine relies on a Vulnerability Assess- trator, which must consider the execution environment to ment System (VAS) to search for known vulnerabilities be controlled. One advantage of such approach is the sep- on the services currently running on the network. A VAS aration of concerns between the functions of the MAPE-K works by scanning the network and conducting different loop. SADF controls a distributed firewall, but our archi- tests to find vulnerabilities in systems and servers, pro- tecture allows the management of more sophisticated ducing a vulnerability report for each server. Based on the environments such as Software Defined Networks with server descriptions, the VAS can be employed with higher Network Function Virtualization capabilities when those priority to scan known services running on each server, are available. Since we have taken as a basis a real scenario, usually, when there are changes in the server descrip- in which there is no support to SDN/NFV, we chose to tions or new vulnerabilities have been published. In the focus on the control of a distributed firewall, acting as a meantime, full vulnerability analysis of servers can still be proof-of-concept for deployment in such environment. performed. A High-level policy captures the requirements of the administrator, and together with the VAS report 4 Instantiating the SADF and the server description, is used for detection of policy The proposed SADF architecture has been instantiated violations. For example, servers with a vulnerability score into a prototype implementation using a combination greater than a particular threshold should only be acces- of existing open source and in-house developed compo- siblefrommachines in thesamenetwork,but thecurrent nents. This instantiation has been used to build a case firewall rules allow access from anywhere. All this data study to demonstrate the feasibility of our approach. As is used by the Analyzer engine component for producing a scenario for presenting its instantiation, in this paper Analysis report, which indicates, for example, servers with we consider the protection of a Web server running known vulnerabilities. the Apache HTTPD software and the JBoss Application The Decision engine component is responsible for the Server. plan phase of the MAPE-K loop. This component is In this section we present details about the different responsible for making decisions on how to respond to representation models employed in our instantiation, fol- the encountered situation based on the analysis report, lowed by a description of the developed prototype. the server descriptions, the high-level policies, and a set of Firewall rules templates. These templates provide a sort 4.1 Model representation of parametrized firewall rules for different services, which One aspect that must be considered for a self-protection can then be employed by the Decision engine for defining solution is the representation of the protected environ- specific firewall rules to be applied. The creation of fire- ment, such as servers, services, and firewall rules. wall rules must employ mechanisms for avoiding conflicts For representing servers and their deployed services between rules. Besides creating firewall rules to be applied we chose the representation language defined by the to the servers of the network, the Decision engine also Puppet configuration management tool. The Puppet lan- produces a report intended for a human administrator. guage allows the description of servers, services, and At the execute phase we have a Firewall rule application configurations using a parametrized approach and well- engine component, which is responsible for effecting the defined semantics. Puppet configures systems in two da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 6 of 21 main stages: compiling and applying a catalog. A cat- decided to employ the FLIP language [15, 16]for defin- alog is a document that describes the desired system ing the firewall rules templates that SADF receives as state. It lists all resources that need to be managed, input. In FLIP, firewall rules are defined using a high- as well as any dependencies between those resources. level language that can be automatically translated into Thecoreofthe Puppet language is declaring resources. device-specific format. FLIP provides a well defined lan- Groups of resources can be organized into classes, which guage with formal semantics, together with proven sound are larger units of configuration. While a resource may and complete algorithms for conflict resolution and trans- describe a single file or package, a class may describe lation into device specific firewall rules. Its formalism was everything needed to configure an entire service or one of the main reasons for choosing FLIP. application. An example of representation for a server and its services is shown in Listing 1. The node named sadf- Listing 2 Example of firewall rules using the FLIP language target.info.ufrn.br was previously added to the Puppet ecosystem, which allows to describe and apply new con- 1 domain sadf −target . info . ufrn . br = [10.3.128.12] , figurations to this server. As shown in Listing 1, the node 2 local −network = [ 1 0 .3.128.0/24] , has two monitored services: the Apache HTTPD - a well- known open source HTTP server -, and the JBoss - an 4 service apache = tcp . [ port =80] , 5 jboss = tcp . [ port =8080 , port =8009 , port application server to the Java Platform, Enterprise Edition =9090] , (Java EE). 7 policy_group vulnerable_jboss { 8 incoming : Listing 1 Example of a node description using the Puppet 9 apache { allow ∗} language 10 jboss { deny ∗ except local −network } 11 } 1 node ’ sadf −target . info . ufrn . br ’ { 12 2 13 apply vulnerable_jboss on sadf −target . 3 include apache : : mod : : php info . ufrn . br ; 4 apache : : vhost { ’ apache ’ : 5 port => ’80 ’ , 6 docroot => ’ / var /www/ html ’ , 7 } Listing 2 presents an example of a rule in FLIP. The 9 include jboss first block (lines 1-2) defines the domains, which can 10 jboss : : default { ’ jboss ’ : be networks or hosts. We define a target server (sadf- 11 http_port => 8080 , target.info.ufrn.br)and anetwork (local-network)that 12 ajp_port => 8009 , 13 jmx_porp => 9090 , represents the network in which the target is running. The 14 xms => 1024 , second block (lines 4-5) of FLIP defines services, which 15 xmx => 1024 , may have one or more ports. In this example, Apache and 16 } 17 JBoss were specified. In the sequence, we define a policy 18 include fw_sadf_target group (lines 7-11), which specifies the behavior that will 19 } be taken about services in a given scenario. One group was created that allows access to Apache HTTPD (line 9) and blocks access to JBoss (line 10) except when the con- Briefly, the settings on Listing 1 define that the Apache nection comes from sadf-engine.info.ufrn.br. Finally, it is HTTPD server must run the PHP module (line 3), and cre- ate a VirtualHost listening to port 80 from DocumentRoot necessary to make a connection between the group and /var/www/html (lines 4 to 7). Regarding JBoss service, the protected domain (line 13). three ports must be configured: 8080 which is bound to Figure 4 presents a class diagram with the meta-model the HTTP connector, 8009 to the AJP connector, and 9090 created for manipulating FLIP firewall rules as objects. that works as a managing interface to the JMX (lines 11 The Model class represents the language model that con- to 13). Moreover, the parameters xms and xmx are used sists of declarations. A Declaration is a generic block to determine the min and max memory size, respectively, that represents each of the terms supported by FLIP. The to be allocated on the HEAP (lines 14 and 15). The class Domain class describes a network or host, which has the fw_sadf_target (line 18), which will be detailed later on, is attributes name and address to represent the name of applied to this node, defining a specific firewall rules for the domain and the IP address. The Service class repre- the sadf-target.info.ufrn.br node. sents a service with names and ports. The Policy_group Similarly, it is necessary to represent firewall rules in a class defines the policy that has a name, traffic direc- format that can be reasoned upon. For this purpose, we tions, which can be incoming or outgoing, policy-related da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 7 of 21 Fig. 4 Class diagram of FLIP implementation in Xtext services and domains that can be inserted into the pol- Listing 3 Firewall rule created by using Puppet icy as the target domain of the action or exception to 1 c l a s s fw_sadf_target { 2 include firewall_module the target group. Finally, the Apply class assigns policies 3 firewall { ’001 accept connections from to domains, causing their traffic to meet the conditions puppet master ’ : described in the FLIP policy. 4 proto => ’ a l l ’ , 5 source => ’10.3.225.163 ’ , In order to apply firewall rules, FLIP models need to be 6 action => ’ accept ’ , translated into Concrete firewall rules . Since we employ 7 } the Puppet language for describing and managing servers 8 firewall { ’002 accept connections from sadf −scanner ’ : and services, we employed Puppet’s firewall module for 9 proto => ’ a l l ’ , representing concrete firewall rules, and hence the fire- 10 source => ’10.3.227.77 ’ , wall rules can be applied by Puppet agents. To achieve 11 action => ’ accept ’ , 12 } that, FLIP rules expressed in text files are instantiated into 13 firewall { ’100 deny access to port Java objects, which are then used to create Puppet classes. 8009 ’: During the translation process, some fields are extracted 14 dport => ’8009 ’ , from the FLIP rules’ fields and then written as a Puppet 15 proto => tcp , 16 action => drop , class describing each host and its services. This transla- 17 source => ! 1 0 .3.128.0/24 , tion has been implemented as a Java class that handles the 18 } FLIP Model and makes it possible to obtain its respec- 19 firewall { ’101 deny access to port 8080 ’: tive rule declarations as domains, services, policy_groups 20 dport => ’8080 ’ , and actions to perform the assembly of Puppet’s classes. 21 proto => tcp , Listing 3 presents an example of the class that speci- 22 action => drop , 23 source => ! 1 0 .3.128.0/24 , fies thefirewallrulestothe sadf-target.info.ufrn.br node, 24 } which have been generated from the example pre- 25 firewall { ’102 deny access to port sented in Listing 2. The first two rules (lines 3-12) are 9090 ’: 26 dport => ’9090 ’ , included by SADF to guarantee access from its com- 27 proto => tcp , ponents to the targeted host. The following rules (lines 28 action => drop , 13-30) blocks access to JBoss ports (8009, 8080, 9090) 29 source => ! 1 0 .3.128.0/24 , 30 } except when the connection comes from the network 31 } 10.3.128.0/24. da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 8 of 21 We employ high-level policies to define how to respond 4.2 Prototype implementation to found vulnerabilities in the monitored environment. In this section, we describe our prototype implementa- These policies are based on Event-Condition-Action tion, whose concrete architecture is illustrated in Fig. 5. (ECA) rules. The basics of an ECA rule imply that when- Implementation and functioning details for each devel- ever an event occurs, a predefined condition is evalu- oped module are also presented. Moreover, the iterations ated, which trigger a specific action when the condition between the modules and the tools/models employed in is true. The event may be represented by a complex the solution are discussed. structure involving a number of sub-events. Similarly As previously mentioned, we employ the Puppet con- to the event, the condition may be formed by several figuration management language for describing servers’ sub-conditions that must be evaluated under a spe- configurations. Puppet provides tools for applying config- cific logic. Finally, an action may be a composition urations, and for obtaining the current status of a host. A of actions according to the condition and event that Puppet agent component runs on each host, and reports activated it [17]. to (and receive commands from) the puppet-master com- In our approach, an event is a discovered vulnerability, ponent, which stores servers description into the Puppet while the condition captures the context of this vulnera- catalog. Hence, Puppet agents fulfill the roles of sen- bility in terms of its severity and other information that sor and effector of servers, while the Puppet master is can be used for decision making on how to respond, i.e., responsible for the monitor and execute phases of the the action. MAPE-K. The syntax used to define a policy is given by the set of fields {server, service, port, CVSS, CVE, action} 4.2.1 Monitor engine that can be mapped to four scopes: target, score, vul- The function of this module is to collect information nerability, and execution, as described in Table 1.The regarding all hosts members and so creating the Server target scope defines the policy application range and is description whichisusedbySADFtorepresent theservers formed by the fields server, service,and port.The score and its services. All hosts managed by the Puppet are taken scope - given by the CVSS field - specifies the CVSS as members of our scheme. The Puppet collects informa- threshold value, hence addressing vulnerabilities with tion regarding the servers by pooling agents (see Fig. 5) CVSS equal or higher than this value. In contrast, the -thatplays theroleofa sensor on SADF architecture - and store it in its Catalog. Thus, the monitoring module vulnerability scope - given by the CVE field - directly can gather information about all servers by communi- addresses the CVE, allowing to act only for specific vul- nerabilities. The score and vulnerability scopes may be cating to the PuppetDB -a Data Warehouse that stores optional, i.e., as long as one is provided, the other may be information and allows the access to it through a specific omitted. API . The target, score and vulnerability scopes comprise the The UML sequence diagram in Fig. 6 illustrates condition of our policy, while the action scope defines the interaction between the Monitor engine and the how to respond when the specified condition is eval- PuppetDB.The Monitor engine first creates an empty list uated to true. Action in our policy refers to a fire- of descriptions (call 1), then it contacts the PuppetDB to wall rule template, which must be provided together collect the list of managed nodes (call 2), and finally, it with the policy. In this way, the proposed system can starts a loop to recover the list of services to each node dynamically select the appropriate parametric rule tem- (call 3). The Monitor engine maintains a list of servers pre- plate for the detected situation, which is then popu- viously collected to detect when there is a change in one of lated based on the information about the affected host the servers. Thus, once all servers’ descriptions have been description. obtained, the Monitor engine performs internal processing Table 1 High-level policy’s fields description Field Description Mandatory Input syntax Server Target server for the policy Yes Hostname, network range or just ’any’ to represent any server. Service Target service for the policy Yes Server name or ’any’ to represent any service. Port Target port for the policy Yes List of integer numbers or ’any’ to represent any port. CVSS Score’s threshold value No A decimal value between 0.0 and 10.0 CVE Vulnerability ID. No List of CVEs. Action Action to be executed for the policy. Yes List of supported action names. da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 9 of 21 Fig. 5 Architectural view of the prototype implementation (call 4) in order to identify servers that need to be scanned again due to changes in their configuration. It is important to mention that the description files defi- nition for servers in Puppet is out of the scope of this work. So there is an assumption that this task was previously performed by the network administrator team. Thereby the focus of this work is to define and apply the firewall rules according to the specified configuration, as well as targeting well-known vulnerabilities on servers. 4.2.2 Analyzer engine Considering that a list of all services running on each server is known, a vulnerability evaluation may be used as the trigger to an adaptation. The OpenVAS is used to scan the servers. It provides an open source solu- tion to identify, quantify and prioritize the vulnerabilities. These properties were explored by the Analyzer engine. In our solution, the OpenVAS Scanner conducts Net- Fig. 6 UML sequence diagram for the Monitor engine work Vulnerability Tests (NVT) for all hosts. An NVT da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 10 of 21 is formed by a script for vulnerability detection, and a A task is a scan configuration that defines how the target specification of the CVE and CVSS for each vulnerability will be tested. detected. OpenVAS Manager gets NVTs through the The Analyzer engine starts each scan (call 4 of the OpenVAS NVT Feed, which is developed based on the UML sequence diagram) and stores its ID. A scan may CVEs from the NVD. take several minutes to complete, as the current Open- The OpenVAS Manager is responsible for control- VAS database includes more than 50,000 entries. Besides, ling the OpenVAS Scanner actions, by providing its the scan duration may vary according to the number of inputs and processing its outputs. All the interactions services on the target and the processing load on the Scan- between the Manager and the Scanner are performed ner and the Server being scanned. Currently, the VAS through the OpenVAS Transfer Protocol (OTP). OTP is queried every five seconds to check whether the scan supplies all the resources to control the scan’s execu- has finished, at which point the Analyzer engine uses the tions. The Manager also includes the OpenVAS Man- stored ID as a key to recover its report (call 5). Each report agement Protocol (OMP), an XML-based stateless API, from the OpenVAS includes, among other data: the CVE, which may be used to interact with and control the the CVSS, the host, the port bound to the affected ser- OpenVAS Manager. vice, the protocol, the suggested solution type, and the The Analyzer engine configures and runs the OpenVAS affected software name. The Analyzer engine process the scans by using the server description. This interaction received report (call 6) to check whether a vulnerability is allowed by the OMP, which receives an XML entry has been detected, or a vulnerability previously detected describing the target host and the scan tasks. A detailed is no longer present. When a vulnerability is detected the view of the interaction between the Analyzer engine and Decision engine is activated to handle it (call 7). the OpenVAS is presented in Fig. 7.The Analyzer engine obtains the Server descriptions of those hosts that need to 4.2.3 Decision engine be scanned (call 1) and builds scan tasks for each server Once activated, the Decision engine must decide how to (see calls 2 and 3 in the figure). Each target defines a host, properly respond to the detected vulnerability. Its behav- listing the ports for all detected services, and thereby all ior is presented in Fig. 8. Initially, it loads the high-level services managed by Puppet in each host can be scanned. policies, the Analysis report,and the Server descriptions Fig. 7 UML sequence diagram for the Analyzer Engine da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 11 of 21 Fig. 8 UML sequence diagram for the Decision engine (calls 1, 2, and 3). Then the policies are evaluated to detect any violation (call 4). This verification involves a set of iterations and conditional operations used to assert the conditions according to the data collected from the Analysis report. When a violation is detected, an adaptation loop is started. In the current prototype implementation, the exe- cution module allows two actions: (1) the configuration of the firewall rules on the affected servers, and (2) to send an alert to the system administrator. The action to be taken is defined by the high-level policy. If the selected action requires blocking a port, then the Decision engine creates the firewall rules using FLIP syntax and then request its translation (calls 6 and 7). Following, the FLIP translates the rules and creates the Concrete firewall rules model, which is written using the Puppet notation (call 8). The corresponding action is then requested to the Executor engine, either to apply new firewall rules to a server (call 9) or to notify the system administrator (call 10). Figure 9 presents a simplified algorithm describ- ing the policy evaluation mechanism. Essentially, the evaluation consists in looping through each server in which a vulnerability has been detected, and checking whether the conditions of the high-level policies hold Fig. 9 Algorithm for policy evaluation and apply. da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 12 of 21 4.2.4 Executor engine 5 Evaluation Once the planning phase is finished, the Executor engine This section presents an evaluation of SADF that has been is invoked to apply all the necessary actions. conducted in a controlled environment. To block ports, it would apply the Concrete firewall First, we present the complete operational flow of rules by sending the generated classes to the directory SADF to demonstrate its feasibility (section 5.1). In the /etc/puppetlabs/code/environments/production/manifests sequence, we present a set of experiments to evaluate to be read by the puppet-master. Following this step, SADF resource consumption (section 5.2). Finally, we each agent can contact the master to apply the sched- discuss the achieved results (section 5.3). uled firewall rules. The puppet-master together with the firewall module manages and configures the generated 5.1 Demonstration iptables and ip6tables rules to be applied directly to A set of servers and services in a controlled environ- each host. ment were deployed in order to demonstrate the func- The Zabbix monitoring system is employed in order tionalities of the proposed SADF. All servers run the to support alerting system administrators. Zabbix is a CentOS 7. Such services are similar to what can be network monitoring system with support to triggered found in a typical network infrastructure of a univer- notifications. SADF creates a list of alerts, which is used sity. Figure 11 presents a general view of the deployed as the basis for populating a monitoring template con- environment, in which we can find two groups of figured into Zabbix. This template includes information servers. The first group corresponds to SADF compo- about the affected host, its service, and the discovered nents and is composed by three servers: (i) puppet- vulnerability, with its respective CVSS. Through the tem- master agent that acts as a configuration management plate, Zabbix can detect the alerts sent by SADF, creat- server; (ii) sadf-engine, which contains all components ing triggers for each alert into Zabbix monitoring screen of SADF; and (iii) sadf-scanner corresponding to the that should be permanently exhibited on the Network OpenVAS vulnerability assessment system. The second Operation Center. We have employed Zabbix on SADF group of servers represents the target environment, which because this is the monitoring solution used by the is controlled by SADF, and corresponds to the dif- network administration team of where SADF is being ferent servers that will have their firewall rules man- deployed. aged by our solution. For this first demonstration, we The behavior of the Executor engine is presented in have instantiated a total of 10 servers (sadf-target01 Fig. 10. As previously mentioned, our current proto- to sadf-target10), in which we have services managed type supports two actions, the notification of admin- by Puppet. istrators (call 1), or the application of firewall rules Several services that are commonly found on complex through puppet-master (call 2). In case of applying fire- network infrastructure were selected in order to demon- wall rules, once the new rules have been saved, each strate SADF functionality. The selection of services was puppet-agent obtain them through the Puppet catalog based on past experiences with incidents that occurred in (call 3), and then applies the rules on their corresponding the UFRN network infrastructure. Therefore, we have hosts (call 4). some services with vulnerabilities of different severity Fig. 10 UML sequence diagram of Executor engine da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 13 of 21 P5: Only allow connections from a particular network on any server that belongs to this network in case any vulnerability is found. “Server = 10.2.59.0/24”, “Service = any”, “Port = any”, “CVSS = any”, “Action = isolate” Once the high-level policies are in place, SADF is ready to start monitoring and controlling the target servers, according to the MAPE-K feedback control loop. It starts by obtaining the server descriptions of the target servers and interacting with OpenVAS for creating the respective scan routines. Based on OpenVAS results, which identi- Fig. 11 Environment deployed for testing SADF fied the existing vulnerabilities in the testing environment, SADF employed the high-level policies to decide how to respond. Following our case study, the OpenVAS found a vulnerability with CVSS score 7.8 in HTTP service that levels. Table 2 presents details about versions, ports, and allows remote attackers to cause a denial of service (mem- vulnerabilities of the services considered in this demon- ory and CPU consumption). An extract of the XML report stration. is presented in Listing 4. These services have been distributed in 10 servers sadf- Listing 4 Extraction of OpenVAS report to a vulnerable HTTP target according to Table 3. The column Vulnerability server Severity represents the server status based on the vulner- 1 . . . <port >80/ tcp abilities found on its deployed services. The classification 2 <host >10.3.128.20 </ host > of vulnerabilities is based on the CVSS V2 specification , 3 < severity >7.8 </ severity > which defines the intervals 0.0 − 3.9 as LOW,4.0 − 6.9 as 4 <threat >High </ threat > 5 </ port > <nvt oid MEDIUM,and 7.0 − 10.0 as HIGH. ="1.3.6.1.4.1.25623.1.0.901203" > Once all target servers are configured and managed 6 <name> by puppet-master, SADF is capable of extracting their 7 Apache httpd Web Server Range Header Denial of Service V ulnerability Server descriptions to monitor and control them. The 8 </name> next step is to configure the high-level policies that define 9 <family >Denial of Service </ family > the behaviour of SADF. For this demonstration, we have 10 <cvss_base >7.8 </ cvss_base > 11 <cve >CVE−2011 −3192</ cve > defined four policies that either block vulnerable services 12 <bid >49303 </ bid > or alert network administrators in different contexts. The 13 ... policies defined are listed below with an informal textual description, and then using the policy definition rules of Based on policy P1, which defines the trigger of alerts SADF. for vulnerabilities with CVSS above 5.0, we have the list of alerts presented in Fig. 12, extracted from Zabbix. P1: Alert administrator if any vulnerability with CVSS SADF creates several objects and triggers in Zabbix with higher than 5.0 is found in any server: information about the vulnerable services, using a color “Server = any”, “Service = any”, “Port = any”, “CVSS = classification according to the severity of the vulnerabil- 5.0”, “Action = alert” ity found. We can notice that some servers appeared more P2: Block any port on any server assigned to any service than once in the list (such as sadf-target10), which indi- in which with vulnerability “CVE-2013-4810” cates that either the server contains more than one vul- (regarding to JBoss 5.1.0) has been detected: nerability, or that the same vulnerability has been found in “Server = any”, “Service = any”, “Port = any”, “CVE = different ports. CVE-2013-4810”, “Action = block” Based on the other policies, SADF activated the Execu- P3: Block any port assigned to any service with CVSS tor engine for blocking several ports. Policy P2 blocked equal or higher than 7.0 running on the server port 8080 on server sadf-target09, while policy P3 blocked sadf-target06.info.ufrn.br: port 80 on server sadf-target06. policies P2 and P4 caused “Server = sadf-target06.info.ufrn.br”, “Service = any”, the blocking of ports 21 and 8080 on server sadf-target01, “Port = any”, “CVSS = 7.0”, “Action = block” and policy P4 blocked port 21 on server sadf-target03. P4: Block any server or port assigned to the service ftp Policy P5, in particular, is an example of a policy which with CVSS equal or higher than 9.0: could be applied for isolating servers of a particular net- “Server = any”, “Service = Ftp”, “Port = any”, “CVSS = work by only accepting connections from their network 9.0”, “Action = block” da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 14 of 21 Table 2 Services and vulnerabilities used to test the prototype Service Port CVE CVSS Vulnerability Apache 2.4.6 443 CVE-2016-2183, CVE-2016-6329 5.0 Confidential information leak. Apache 2.4.6 80 CVE-2004-2320, CVE-2003-1567 5.8 Cross site Apache 2.2.15 80 CVE-2004-2320, CVE-2003-1567 5.8 Cross site Apache 2.2.15 80 CVE-2011-3192 7.8 Denial-of-service (DoS) MySQL 5.5.52 3306 - - - ProFTPD 1.3.4a 21 CVE-2015-3306 10.0 Arbitrary remote code execution. JBoss 5.1.0 8080 CVE-2013-4810 10.0 Arbitrary remote code execution. JBoss 5.1.0 8009 - - - JBoss 5.1.0 9090 - - - Tomcat 8.5.16 8080 - - - Tomcat 8.5.16 8009 - - - Tomcat 8.5.16 9090 - - - (10.2.59.0/24) when any vulnerability is found. Such pol- detected a vulnerability and reacted according to its poli- icy triggers the application of firewall rules on all servers cies. We can notice rules allowing connections from SADF managed by SADF that belong to the identified network. components (puppet-master and sadf-scanner), similar to The blocking of ports is achieved by manipulating Fig. 13, and rules for blocking (DROP) incoming packets objects based on the FLIP meta-model defined by us. (INPUT chain) on ports 21/tcp and 8080/tcp. Theseobjects arethentranslatedintoPuppetclasses con- This procedure was repeated to all servers where we taining concrete firewall rules. Each server has its own confirmed the application of firewall rules according to Puppet class with its respective firewall rules. Listing 5 the high-level policies defined. We have repeated these presents an example of class for server sadf_target01. experiments, varying the services versions and known vulnerabilities, services, and high-level policies. In all Listing 5 New class created by the SADF to block ports 21 and occasions SADF worked as expected, demonstrating its 8080 on the server sadf-target01 effectiveness in blocking vulnerable services and trigger- 1 class fw_sadf_target01 { ing alarms for alerting administrators when the blocking 2 include firewall_module is deemed a too harsh response. 3 firewall { ’100 ’: 4 dport => ’8080 ’ , 5 proto => tcp , 5.2 Resource consumption experiments 6 action => drop , After demonstrating the operational viability of SADF, 7 } we have conducted a set of experiments for evaluating 8 firewall { ’101 ’: its resource consumption. These experiments have been 9 dport => ’21 ’ , 10 proto => tcp , conducted with the objective of providing subsides for 11 action => drop , 12 } 13 } Table 3 Servers and services tested Server Vulnerability severity Running services The iptables tool was used on the affected servers in order to confirm if the firewall rules have been correctly sadf-target01 HIGH JBoss 5.1.0; ProFTPD 1.3.4a applied. sadf-target02 MEDIUM Apache 2.4.6; Tomcat 8.5.16 Figure 13 presents the output for server sadf-target01 sadf-target03 HIGH Apache 2.4.6; ProFTPD 1.3.4a before SADF has run. We can notice explicit rules allow- sadf-target04 MEDIUM Apache 2.4.6; MySQL 5.5.52 ing (ACCEPT) packets from the servers that play the sadf-target05 NONE Tomcat 8.5.16 role of puppet-master (IP address 10.3.225.163) and sadf- sadf-target06 MEDIUM Apache 2.2.15 scanner (IP address 10.3.227.77), and no closed ports (indicated by the absence of rules, which means that all sadf-target07 NONE MySQL 5.5.52 connection are accepted). These rules are maintained by sadf-target08 MEDIUM Apache 2.4.6 the firewall module of Puppet, defining the servers that sadf-target09 HIGH JBoss 5.1.0; Apache 2.2.15 are part of SADF as trusted. Figure 14 presents the ipta- sadf-target10 MEDIUM Apache 2.2.15; MySQL 5.5.52 bles output for the same server (sadf-target01)after SADF da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 15 of 21 Fig. 12 Vulnerability alerts triggered on Zabbix system the allocation of resources for SADF deployment. A first based on the resource allocation to similar services in our observation allowed us to notice that the biggest overhead real network infrastructure. of SADF is related to the vulnerability analysis. Based on To run the first group of experiments, we replicated the this, the experiments conducted have been divided into 10 servers used in the demonstration of SADF, consider- two groups. The first group considered whether there is ing a growing number of servers, respectively, 1, 10, 20, an improvement in the use of OpenVAS when the ports 30, 40 and 50 servers, while employing the same distribu- to be scanned are explicitly indicated (based on the ser- tion of services showed on Table 3. For these experiments, vices’ ports configured via Puppet). The second group OpenVAS has been used in its default configuration, up considered the impact of increasing the number of servers to 10 NVTs running in parallel for each host, and a max- monitored and controlled. imum of 30 hosts that can be verified simultaneously. In These experiments have been conducted on the same this context, in case there are more than 30 servers to be environment used for demonstrating SADF (which has verified, the exceeding ones will be queued until the end been presented in Fig. 11). The configurations of each of the scans in execution. OpenVAS has been restarted server used in these experiments are presented in Table 4. between each test, and the tests have been repeated The resources allocated to puppet-master server are based three times for obtaining the average execution time for on the official documentation of puppet , which recom- each run. mends a server with four cores and at least 4GB of RAM When considering the consumption of hardware for attending a number of 1000 servers. The resources resources, we did not identify any significant difference allocated for sadf-engine correspond to the server used with and without the definition of ports. However, Open- for its development. The server responsible for OpenVAS, VAS took around 2 hours and 43 minutes to scan 50 sadf-scanner, demands more computational power as it servers in its default configuration. When comparing the will potentially conduct more than 50,000 NVTs in each time necessary to run the tests with (Scan on defined monitored host. The resources allocated to this server are ports)and without(Scan without ports definition)port Fig. 13 Iptables output of firewall rules that are managed by Puppet on the server sadf-target01 before running SADF da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 16 of 21 Fig. 14 Iptables output of firewall rules that are managed by Puppet on the server sadf-target01 after running SADF indication, we have a difference up to 20.53% for 50 The results obtained with these experiments have been servers (2 h and 25 min with ports defined). We con- considered satisfactory. The time of 2 hours and 25 min sidered these results as a substantial indication of the to scan 50 hosts is within the expected time given the benefits of directing OpenVAS scansasdonebySADF, complexity of the vulnerability analysis process, and the which encouraged the execution of the second group of experience of the network administration team. experiments. A more detailed discussion about the results obtained is After that, we started to experiment with the full SADF presented in the sequence. solution. As previously mentioned, the biggest overhead of SADF is related to the vulnerability analysis. Thus, our 5.3 Discussion focus was on evaluating the analysis phase of SADF, which The experiments conducted have shown that SADF can includes OpenVAS to scan hosts on specific ports. dynamically update firewall rules in response to dis- During these experiments, we have observed the covered vulnerabilities, following the high-level policies resource consumption of sadf-scanner to understand defined by an administrator. Based on this, we conclude its behavior and profile its hardware requirements. We that SADF indeed provides a significant improvement in present the measurements for the experiments involving the administrative procedures of the network administra- 50 hosts. Figure 15 presents CPU load, Fig. 16 presents the tion team of UFRN in detecting and protecting vulner- RAM utilization, and Fig. 17 presents the network usage. able services. This is evidenced when we consider that The higher CPU-load is expected, due to the number such procedure used to be conducted manually by net- of NVT executing simultaneously. Regarding memory and work administrators, usually by different teams, and the network load, we notice a low usage, with some peaks response to a detected vulnerability took hours (some- caused by the inner workings of NVTs, which involves times days) to be implemented. discovery and test of ports and service, followed by load- In its current implementation stage, SADF is only able ing and running of tests. These peaks represent when the to deal with hosts. Although SADF supports the speci- number of servers tested in parallel dropped below 30, fication of more complex firewall rules using FLIP and and the tests for the next servers in the queue have been our high-level policies, we do not consider the deploy- started. Regarding network consumption, a maximum ment of firewall rules in other points of the network of 6.78 Mbits/s is viewed as a good result, considering infrastructure, such as routers and switches. This is due that the datacenter infrastructure is connected to at least to a simple decision-making implementation, which only 1Gbits/s, with 10 Gbits/s in several segments, and the targets hosts. Through the use of adaptation rules, the duration of the peak when compared to the whole testing response can be anything supported by the controlled time. environment. Thus, although the proposed SADF can, for example, isolate a network employing firewall rules, such isolationisachievedbyapplying firewall rulesateachhost Table 4 SADF servers resource configuration of the affected network. Server Memory Processor The resource consumption experiments have confirmed the overhead caused by the vulnerability scanner, and the puppet-master 4GB 4Cores improvement of its use when the ports to be scanned are sadf-engine 16 GB 8 Cores identified. Although the time to scan 50 hosts is above sadf-scanner 16 GB 16 Cores two hours, it is still substantially faster than the traditional da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 17 of 21 Fig. 15 Load average on the SADF server for 50 servers manual approach. One aspect that has not been explored as a satisfactory time, since the blocking action occurs in is to deploy OpenVAS as a cluster using a master-slave a preventive way, upon discovery of a vulnerable server. architecture, which has the potential to provide horizon- Regarding the secure communication between the tal scalability to our solution without any changes to its SADF and protected servers, we employ the certificate implementation. based security provided by the Puppet tool, which takes Another aspect worth mentioning concerns the Puppet care of authentication and secure transit between the configuration management tool. Puppet presents a pull- puppet-master and its agents through SSL certificates. based model, in which agents query the master at pre- Thenumberof50hosts have been used forthe tests determined intervals in search of new commands (usu- due to limitation of the infrastructure available for this ally, 30 minutes). It might be considered an issue when project at the time of the experiments. Nevertheless, this responding on-the-fly to detected situations, which is not number has been considered relevant for the evaluation the case in this paper. We focused on preventing the of the proposal when taking into account feedback from exploitation of known vulnerabilities before they hap- the network management team, simulating an infrastruc- pen, opposed to traditional IDPS systems, which focus on ture capable of providing many applications and services. responding to incidents in real-time. Hence, we consider Also, this is the current number of servers that will be ini- that 30 minutes is a reasonable time for applying fire- tially monitored when deployed in the UFRN data center. wall rules blocking vulnerable services, although this time Besides that, the results obtained provide us guidelines on could be reduced. We have changed this configuration to how to allocate resources to SADF components to repro- 10 minutes in our experiments, which is still considered duce theexperiments with alargernumberofservers. Fig. 16 RAM memory utilization on the SADF server for 50 servers da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 18 of 21 Fig. 17 Network traffic on the SADF server for 50 servers 6 Related work for analyzing download events for detecting malware The discussion on centralized and distributed firewalls is download. These works are concentrated on improving well established in the literature [2, 18]. One of its first an IDS, and present interesting discussions that could implementation proposals has been presented by Ioanni- complement SADF in a possible future work integrat- dis [1], in which kernel extensions have been developed for ing IDS into its architecture. Iannucci and Abdelwahed the OpenBSD distribution, together with a policy defini- [24] employ a Markov Decision Process together with an tion language (named KeyNote)and useofIPsec forsecure Intrusion Response System for deciding which action to traffic amongst the hosts of the network. More recently perform in response to a detected intruder. Compared [19] introduces a distributed firewall system for Linux to our work, their approach presents a formalism that platform that works upon Iptables/Netfilter for IPv6 net- can be used for deciding which action to perform, con- works with IPsec support. A distributed firewall archi- sidering cost and impact, from a list of possible actions. tecture was proposed in order to improve performance, Of-IDPS [25] is a system that considers network usage his- handling the additional costs of encryption of packages tory and IDS alerts for extracting security rules that are with IPsec. applied through a Software Defined Network (SDN) based Autonomic computing and self-protection have been on OpenFlow controllers. gaining traction as the means for dealing with new secu- As stated by Shin et al. [26], SDN environment can be rity challenges and systems, in which static and rigid combined with traditional security mechanisms to rein- security practices are not enough to deal with security force the detection of attacks and to quickly react to them. threats that need to be detected and mitigated at run- In the context of our work, the major impact of SDN on time [7]. In this context,Yuanetal. [7]havedonean a SADF solution would be twofold: at first, the decision extensive systematic survey of the state of the art on making now needs to deal with flows fate besides firewall self-protecting software, identifying trends, patterns, and rules, and second, SADF can act upon switches through gaps. Some works focus on adapting authorization poli- Access Control Lists (ACL) which allows creating rules cies, such as the Self-Adaptive Authorisation Framework connected to the network traffic [27]. In fact, our archi- (SAAF) [5] that focus on adapting access control poli- tecture would fit perfectly with an SDN environment, and cies on the PERMIS system [20], and SecuriTAS [6], a with the range of possibilities pointed out in the literature tool that enables dynamic decisions in awarding physical [26, 27], being able to provide the link between a detec- access, based on a perceived state of the system and its tion tool, the decision making process for deciding how environment. to react to the detected situation, and the commands that Several researchers focus on Intrusion Detection and will change the SDN environment. Similarly, an environ- Response Systems. For example, Uribe and Cheung [21] ment with NFV capabilities can provide more response have looked into the integration between IDSs and fire- options for our architecture. walls, proposing an approach for optimizing IDS config- There are also works that aim to facilitate the configu- uration by only analyzing traffic that is not considered by ration of security mechanisms as part of the instantiation the firewalls’ rules. Zhang and Shen [22]employastatis- process of virtual machines in cloud computing environ- tical learning based approach to reduce false positives on ment [28, 29]. This approach provides IDS/IPS, firewall, IDSs. Rahbarinia et al. [23] use graph mining techniques and anti-malware in a solution Security-as-a-Service. da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 19 of 21 Few works consider the analysis of vulnerabilities is still considered work-in-progress, and may be subject to for making a decision at the network level (i.e., fire- changes. wall rules). Debar et al. [30] present formalisms for The research in the area of self-protection, when con- the definition of security policies that can be dynam- sidering the network level, tend to focus on IDS/IRS. To ically modified in response to detected threats. The the best of our knowledge, we have not found any work formalism presented in their paper is at an abstract that employs vulnerability detection as the trigger for self- level and may consider vulnerability analysis in the adaptation, or that consider the addition of self-adaptive threat detection process. Compared to our work, their capabilities to a distributed firewall. approach can be considered as complementary, pro- viding formalisms that could improve the robustness 7 Conclusions & future work of our approach regarding the definition of high-level This article presented an approach for Self-Adaptive Dis- policies. tributed Firewall (SADF) based on the synergies between To the best of our knowledge, the closest work to ours the MAPE-K feedback control loop of self-adaptive sys- has been presented by Sheridan et al. [31]and involves the tems with the increased network security provided by automatic security of virtual machines in cloud comput- distributed firewalls. The MAPE-K reference model is ing environments. Their approach is based on three flows: used as the means for logically structuring the different First, a VAS analyses a host during its instantiation, noti- tasks involved in the management of network security, fying an administrator by e-mail in case a vulnerability is employing a vulnerability analysis system to detect vul- found. Second, the firewall provided by the cloud platform nerable hosts on the network infrastructure. Along these is activated for allowing access to services known dur- lines, our approach can cope with the complexity on ing instantiation. Third, the Chef configuration manage- the management of distributed firewalls, while reducing ment system is employed for automatically installing and the exposure windows of vulnerable hosts by automati- upgrading software packages for hardening and updat- cally applying firewall rules during run-time, according ing the operating system. Although their approach also to specified high-level policies, in response to detected employs a VAS and activate firewall rules, the VAS out- vulnerabilities. put is not used for decision making on which firewall We have developed a prototype of SADF using a com- rules to apply, as we propose. Moreover, their approach bination of existing open source and in-house developed only considers a virtual machine during its creation, not components, which has been used to conduct a series presenting any means for constant monitoring, and the of experiments, involving different services with a var- automatic update of software packages without any super- ied degree of vulnerabilities. These experiments have vision (or an intelligence level) might be dangerous in a demonstrated the feasibility of SADF, which is able to critical environment. dynamically modify the firewalls on protected servers, An aspect that must be considered for a self-protection and presented a satisfactory performance of the environ- solution is the representation of the protected environ- ment in which it is being deployed. For example, SADF ment, such as servers, services, and firewall rules. We managed to achieve a 20% reduction on the scanning present here some of the options found in the litera- time for a group of 50 servers using the default configu- ture during our searches. The Network Markup Language rations of the OpenVAS vulnerability scanning system, a (NML) [32] is a generic model defined by the OpenGrid significant performance gain which reduces the exposure Forum (OGF) as a standard for modeling networks, such window of a detected vulnerability. These experiments as switches and links, which is out of the scope consid- provided interesting feedback about its configuration and ered in this paper. Regarding the representation of firewall operation that has been incorporated into our solution. rules, apart from the FLIP language (already presented), Although we obtained very encouraging results, SADF there is also the AFPL2 [33] (Abstract Firewall Policy presents some limitations. We employ the Puppet con- Language 2), a domain-specific language that provides an figuration management tool for describing servers and XML Schema for the definition of firewall rules indepen- services, and for applying firewall rules on the affected dent of firewall product. Although its support of NAT hosts. Accordingly, we assume the infrastructure has been rules, AFPL2 has not evolved as FLIP and does not pro- previously configured using this tool, as we employ Puppet vide conflict resolution of firewall rules. The Distributed descriptions as part of our monitoring and execution Management Task Force (DMTF) proposed the Com- engine. mon Information Model (CIM), a specification aimed Another limitation is related to the use of NVTs. Each at allowing the interoperation of management informa- NVTisupdated basedonthe NVTFeed,maintained tion. The CIM also provides an extensible XML model by Greenbone Community .SADFisonlyabletoreact and, although it has been employed by different ven- to known vulnerabilities that have been published to dors, its extension for Network Policy Management [34] NVT Feed. Moreover, recently Greenbone has adopted da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 20 of 21 measures to increase paid subscription to its service, PuppetDB 5.0: API overview https://docs.puppet.com/ which might delay the availability of new NVTs. puppetdb/latest/api/index.html In its current stage, SADF only deal with hosts. 8 OpenVAS http://www.openvas.org/ Although SADF supports the specification of more com- http://www.openvas.org/nvt-dev.html plex firewall rules using FLIP and our high-level poli- Zabbix is an enterprise-class open source monitoring cies, we do not consider the deployment of firewall rules solution for network monitoring and application monitor- in other points of the network infrastructure, such as routers and switches. This is caused by a simple decision- ingofmillionsofmetrics - https://www.zabbix.com/ making process, which only targets hosts. Although it Federal University of Rio Grande do Norte, Brazil is possible to isolate a network through firewall rules, NVD CVSS Support https://nvd.nist.gov/vuln- such isolation is achieved at each host of the affected metrics/cvss network. Puppet system requirements https://docs.puppet. Other improvements on the decision making might com/puppet/5.0/system_requirements.html allow more complex responses. For example, a host firewall might redirect all incoming connection to https://www.ogf.org/ an application level firewall or IDS when a particular Greenbone Community https://www.greenbone.net/ vulnerability has been detected, adding an extra layer en/community-edition/ of security while the vulnerability has not been fixed. Availability of data and materials Another future work involves the integration of our The datasets generated during the current work are not publicly available due solution with traditional IDPSs on the monitoring and to its private nature, as it is related to a real University, but are available from analyses phases, allowing it to react to attacks exploiting the corresponding author on reasonable request. zero-day vulnerabilities. This would allow the use of less Authors’ contributions disruptive firewall rules, such as blocking of vulnerable EPCJ was responsible for the majority of the technical work, implementing the services only from suspect sources. SADF can also be prototype, conducting experiments and collecting the obtained results, drafting the initial version of the article. CEDS made contributions to the easily scaled up by deploying OpenVAS into a cluster con- conception and design of the proposed solution, validating the prototype figuration to deal with an elevated number of monitored implementation, and contributing for critically reviewing the manuscript. servers. MP made contributions to the conception and design of the proposed solution, to designing the experiments conducted, and writing the manuscript. Another possible future work is related to Software- SCS participated in the drafting and critically reviewing the article for important Defined Networks (SDN) and virtualization. In our setup, intellectual content, and made substantial contributions to the analysis of the we have not considered the impact of such technologies. experimental data. All authors read and approved the final manuscript. An SDN-enabled infrastructure, combined with support Competing interests for virtualized network functions, would allow for more The author(s) declare(s) that they have no competing interests. sophisticated responses without direct host intervention. Publisher’s Note New challenges arise from the dynamicity of the Virtual Springer Nature remains neutral with regard to jurisdictional claims in Machines (VMs), which imposes frequent changes on the published maps and institutional affiliations. virtual network topology, where VMs might be migrated Author details for resource management and optimization. We intent on Digital Metropolis Institute, Federal University of Rio Grande do Norte (UFRN), Natal, RN, Brazil. Department of Informatics and Applied Mathematics, conducting further research in this direction in order to Federal University of Rio Grande do Norte (UFRN), Natal, RN, Brazil. support new responses, such as the dynamic redirection of traffic to an application proxy that could perform a Received: 24 August 2017 Accepted: 10 April 2018 second authentication. References Endnotes 1. Ioannidis S, Keromytis AD, Bellovin SM, Smith JM. Implementing a Common Vulnerabilities and Exposures sponsored by Distributed Firewall. In: Proceedings of the 7th ACM Conference on Computer and Communications Security. New York: ACM; 2000. US-CERT - https://cve.mitre.org p. 190–9. CCS ’00. https://doi.org/10.1145/352600.353052. National Vulnerability Database maintained by NIST - 2. Bellovin SM. Distributed Firewalls. J Login. 1999;24(5):39–47. https://www. cs.columbia.edu/~smb/papers/distfw.pdf. https://nvd.nist.gov/ 3. Meng G, Liu Y, Zhang J, Pokluda A, Boutaba R. Collaborative Security: A Survey and Taxonomy. ACM Comput Surv. 2015;48(1):1:1–1:42. Common Vulnerability Scoring System sponsored by https://doi.org/10.1145/2785733. FIRST - https://www.first.org/cvss 4. Young G, Pescatore J. Magic quadrant for enterprise network firewalls. Tech. Rep. 141050, Gartner RAS Core G. 2008. http://www.eircomictdirect. https://puppet.com/ ie/docs/juniper/gartner_magic_quadrant_2008.pdf. 5. Bailey C, Chadwick DW, de Lemos R. Self-adaptive federated https://forge.puppet.com/puppetlabs/firewall authorization infrastructures. J Comput Syst Sci. 2014;80(5):935–52. PuppetDB-Overview https://docs.puppet.com/puppetdb/ https://doi.org/10.1016/j.jcss.2014.02.003. da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 21 of 21 6. Pasquale L, Menghi C, Salehie M, Cavallaro L, Omoronyia I, Nuseibeh B. 25. dos Santos LAF, Campiolo R, Monteverde WA, Batista DM. Abordagem SecuriTAS: A Tool for Engineering Adaptive Security. In: Proceedings of autonômica para mitigar ciberataques em LANs. In: Simpósio Brasileiro de the ACM SIGSOFT 20th International Symposium on the Foundations of Redes de Computadores e Sistemas Distribuídos (SBRC); 2016. p. 600–13. Software Engineering. New York: ACM; 2012. p. 19:1–19:4. FSE ’12. http://www.sbrc2016.ufba.br/downloads/SessoesTecnicas/152417.pdf. https://doi.org/10.1145/2393596.2393618. 26. Shin S, Xu L, Hong S, Gu G. Enhancing Network Security through 7. Yuan E, Malek S, Schmerl B, Garlan D, Gennari J. Architecture-based Software Defined Networking (SDN). In: Proceedings of the 25th Self-protecting Software Systems. In: Proceedings of the 9th International International Conference on Computer Communication and Networks ACM Sigsoft Conference on Quality of Software Architectures. New York: ICCCN ’16, vol. 1; 2016. p. 1–9. https://doi.org/10.1109/ICCCN.2016. ACM; 2013. p 33–42. QoSA ’13. https://doi.org/10.1145/2465478.2465479. 7568520. 8. da Costa Jr. EP, da Silva CE, Madruga M, Medeiros ST. XVI Simpósio 27. Alsmadi I, Xu D. Security of Software Defined Networks: A survey. Comput Brasileiro de Segurança da Informação e de Sistemas Computacionais Secur. 2015;53:79–108. https://doi.org/10.1016/j.cose.2015.05.006. (SBSeg2016). 2016. http://sbseg2016.ic.uff.br/pt/files/anais/completos/ 28. Daniel J, Dimitrakos T, El-Moussa F, Ducatel G, Pawar P, Sajjad A. ST7-1.pdf. Accessed 15 Mar 2018. Seamless Enablement of Intelligent Protection for Enterprise Cloud 9. Cheng BH, et al. Software Engineering for Self-Adaptive Systems: A Applications through Service Store. In: 2014 IEEE 6th International Research Roadmap. In: Cheng BH, de Lemos R, Giese H, Inverardi P, Conference on Cloud Computing Technology and Science; 2014. Magee J, editors. Software Engineering for Self-Adaptive Systems. Berlin: p. 1021–6. https://doi.org/10.1109/CloudCom.2014.92. Springer-Verlag; 2009. p. 1–26. https://doi.org/10.1007/978-3-642- 29. Pawar PS, Sajjad A, Dimitrakos T, Chadwick DW. Security-as-a-Service in 02161-9_1. Multi-cloud and Federated Cloud Environments. In: Damsgaard Jensen C, 10. Kurose JF, Ross KW. Computer Networking: A Top-Down Approach. Marsh S, Dimitrakos T, Murayama Y, editors. Trust Management IX. Cham: 6th ed. New York: Pearson; 2012. Springer International Publishing; 2015. p. 251–61. https://doi.org/10. 11. Kephart JO, Chess DM. The Vision of Autonomic Computing. IEEE 1007/978-3-319-18491-3_21. Comput. 2003;36(1):41–50. https://doi.org/10.1109/MC.2003.1160055. 30. Debar H, Thomas Y, Cuppens F, Cuppens-Boulahia N. Enabling 12. Iglesia DGDL, Weyns D. MAPE-K Formal Templates to Rigorously Design automated threat response through the use of a dynamic security policy. Behaviors for Self-Adaptive Systems. ACM Trans Auton Adapt Syst. J Comput Virol. 2007;3(3):195–210. https://doi.org/10.1007/s11416-007- 2015;10(3):15:1–15:31. https://doi.org/10.1145/2724719. 0039-z. 13. Sweitzer JW, Draper C. Architecture Overview for Autonomic Computing. 31. Sheridan C, Massonet P, Phee A. Deployment-Time Multi-Cloud In: Parashar M, Hariri S, editors. Autonomic Computing: Concepts, Application Security. In: 2017 IEEE International Conference on Smart Infrastructure, and Applications. CRC Press; 2006. p. 71–98. Computing (SMARTCOMP); 2017. p. 1–5. https://doi.org/10.1109/ 14. Vromant P, Weyns D, Malek S, Andersson J. On Interacting Control SMARTCOMP.2017.7947000. Loops in Self-Adaptative Systems. In: Proceedings of the 6th International 32. van der Ham J, Dijkstra F, Apacz R, Zurawski J. Network markup Symposium on Software Engineering for Adaptive and Self-Managing language base schema version 1. 2013. Grid Final Draft (GFD), Proposed Systems; 2011. p. 202–7. https://doi.org/10.1145/1988008.1988037. Recommendation (R-P) GFD-R-P.206, Open Grid Forum. https://www.ogf. 15. Zhang B, Al-Shaer E, Jagadeesan R, Riely J, Pitcher C. Specifications of a org/documents/GFD.206.pdf. Accessed 15 Mar 2018. High-level Conflict-free Firewall Policy Language for Multi-domain 33. Pozo S, Varela-Vaca AJ, Gasca RM. AFPL2, an Abstract Language for Networks. In: Proceedings of the 12th ACM Symposium on Access Firewall ACLs with NAT Support. In: Second International Conference on Control Models and Technologies. New York: ACM; 2007. p. 185–94. Dependability (DEPEND 2009); 2009. p. 52–9. https://doi.org/10.1109/ SACMAT ’07. https://doi.org/10.1145/1266840.1266871. DEPEND.2009.14. 16. Al-Shaer E. In: Automated Firewall Analytics: Design, Configuration and 34. DMTF. Network policy management profile. 2016. https://www.dmtf.org/ Optimization. Springer International Publishing; 2014. p. 49–74. chap. sites/default/files/standards/documents/DSP1048_1.0.0c_0.pdf. Specification and Refinement of a Conflict-Free Distributed Firewall Accessed 15 Mar 2018. Configuration Language. https://doi.org/10.1007/978-3-319-10371-6_3. 17. Alferes JJ, Banti F, Brogi A. An Event-Condition-Action Logic Programming Language. Berlin, Heidelberg: Springer Berlin Heidelberg; 2006, pp. 29–42. https://doi.org/10.1007/11853886_5. 18. Stallings W. Network Security Essentials: Applications and Standards, 4th edn. Englewood Cliffs: Prentice Hall; 2010. 19. Lai Y, Jiang G, Li J, Yang Z. Design and Implementation of Distributed Firewall System for IPv6. In: Communication Software and Networks, 2009. ICCSN ’09. International Conference on; 2009. p. 428–32. https://doi.org/10.1109/ICCSN.2009.121. 20. Chadwick DW, Zhao G, Otenko S, Laborde R, Su L, Nguyen TA. PERMIS: a modular authorization infrastructure, Concurrency and Computation: Practice & Experience. 2008;20(11):1341–57. https://doi.org/10.1002/cpe. v20:11. 21. Uribe TE, Cheung S. Automatic Analysis of Firewall and Network Intrusion Detection System Configurations. In: Proceedings of the 2004 ACM Workshop on Formal Methods in Security Engineering (FMSE 2004); 2004. p. 66–74. https://doi.org/10.1145/1029133.1029143. 22. Zhang Z, Shen H. M-AID: An Adaptive Middleware Built Upon Anomaly Detectors for Intrusion Detection and Rational Response. ACM Trans Auton Adapt Syst. 2009;4(4):24:1–24:35. https://doi.org/10.1145/1636665. 23. Rahbarinia B, Balduzzi M, Perdisci R. Real-Time Detection of Malware Downloads via Large-Scale URL −→ File −→ Machine Graph Mining. In: Proceedings of the 11th ACM on Asia Conference on Computer and Communications Security. New York: ACM; 2016. p. 783–94. ASIA CCS ’16. https://doi.org/10.1145/2897845.2897918. 24. Iannucci S, Abdelwahed S. A Probabilistic Approach to Autonomic Security Management. In: 2016 IEEE International Conference on Autonomic Computing (ICAC); 2016. p. 157–66. https://doi.org/10.1109/ ICAC.2016.12. http://www.deepdyve.com/assets/images/DeepDyve-Logo-lg.png Journal of Internet Services and Applications Springer Journals
Free
21 pages

Loading next page...
 
/lp/springer_journal/a-new-approach-to-deploy-a-self-adaptive-distributed-firewall-b8HukBbd1o
Publisher
Springer Journals
Copyright
Copyright © 2018 by The Author(s)
Subject
Computer Science; Computer Systems Organization and Communication Networks; Computer Communication Networks; Information Systems and Communication Service; IT in Business; Computer Applications; Processor Architectures
ISSN
1867-4828
eISSN
1869-0238
D.O.I.
10.1186/s13174-018-0083-6
Publisher site
See Article on Publisher Site

Abstract

Distributed firewall systems emerged with the proposal of protecting individual hosts against attacks originating from inside the network. In these systems, firewall rules are centrally created, then distributed and enforced on all servers that compose the firewall, restricting which services will be available. However, this approach lacks protection against software vulnerabilities that can make network services vulnerable to attacks, since firewalls usually do not scan application protocols. In this sense, from the discovery of any vulnerability until the publication and application of patches there is an exposure window that should be reduced. In this context, this article presents Self-Adaptive Distributed Firewall (SADF). Our approach is based on monitoring hosts and using a vulnerability assessment system to detect vulnerable services, integrated with components capable of deciding and applying firewall rules on affected hosts. In this way, SADF can respond to vulnerabilities discovered in these hosts, helping to mitigate the risk of exploiting the vulnerability. Our system was evaluated in the context of a simulated network environment, where the results achieved demonstrate its viability. Keywords: Distributed firewall, Self-adaptive software, Network security, Software vulnerability assessment 1 Introduction of the network is no longer effective, as centralized bor- Several institutions all over the world deal with com- der firewalls are not able to deal with attacks originated plex network infrastructure, involving an increasing num- from inside the security perimeter [1]. Today’s technol- ber of equipment (e.g., switches, routers) and servers, ogy movements, such as Bring Your Own Device (BYOD) usually providing different services. These environments and the availability of 3G/4G connections, mean that a may contain several types of vulnerabilities that could malicious user has already penetrated the border defense. be exploited by an attacker. In this way, it is extremely This is exacerbated when we consider university environ- important to maintain software systems up to date with ments, which are usually open to the public in general, and versions that fix known vulnerabilities. Considering the contains some servers maintained by researchers, with diversity of activities and variety of research topics con- outdated and potentially vulnerable services. ducted throughout an university, it is common to find Distributed firewall systems [2] have emerged as a solu- situations where several services, and servers, need to be tion for dealing with incidents originated from inside the provided for different groups of people, and more often secure perimeter, by including firewalls in different points than not, maintained by these groups. This leads to an of the network and servers. In such systems, a centralized inconsistency in management and security procedures, control mechanism is responsible for distributing firewall where servers poorly configured, with outdated services, rules to each point of the network, and hence it is possi- or both may become potential targets for attacks. ble to control what services running on those servers are In this context, the traditional approach for network exposed on the network, and only for specific client hosts. security, in which firewalls are deployed on the border However, the application of distributed firewall also brings some challenges, such as the management of these *Correspondence: kaduardo@imd.ufrn.br firewalls and their rules, and the response time in case of Digital Metropolis Institute, Federal University of Rio Grande do Norte (UFRN), an incident. Traditional solutions for intrusion detection Natal, RN, Brazil Full list of author information is available at the end of the article © The Author(s). 2018 Open Access This article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made. da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 2 of 21 or vulnerability assessment usually notify an administra- adaptation, and an evaluation of the whole implementa- tor, who then assesses and decides how to respond to deal tion in a controlled environment. with the situation [3]. However, this approach is usually The remaining of this paper is organized as follows: not fast enough for avoiding information theft, the infec- Section 2 contextualizes our work defining its scope and tion of new systems/servers, or even service unavailability, presenting some background on self-protection. Section 3 mainly for attacks conducted during strategic times, such presents a conceptual view of the proposed SADF archi- as the middle of the night or weekends, when the IT team tecture. Section 4 describes a prototype that has been is usually out of service. implemented to demonstrate our approach feasibility. Moreover, it is possible to identify a gap on the inte- Results from the experiments conducted in a controlled gration between the several tools involved in securing environment to evaluate the proposed approach are pre- a network environment. For example, a Vulnerability sented and discussed in section 5.Section 6 discusses AssessmentSystem(VAS) maydetectavulnerabilityon some related work. Section 7 concludes the paper. a particular server, but the firewall of such system may not react to such detection, as both systems are not inte- 2 Contextualization grated. Such problem becomes more evident when we In a university network infrastructure, such as the Federal consider the dynamic nature of a complex network envi- University of Rio Grande do Norte (UFRN) in Brazil, ronment, in which new devices and services are constantly it is common to find several groups of servers hosting added/removed, and new vulnerabilities are discovered from basic services, like e-mail, Web, and DNS (Domain and patched. Finally, it is worth mentioning that, although Name System), to specific applications. These institutions there are firewall solutions that inspect application pro- usually maintain a network team responsible for manag- tocols, in 2016 more than half of the corporate networks ing these services. However, it is also common to find were still using conventional firewalls [4]. other servers and equipment providing a set of local ser- In this context, the main contribution of this paper vices used and maintained by researchers in their respec- is an architecture for network security based on self- tive laboratories. Such a diverse environment is prone to protection, named Self-Adaptive Distributed Firewall inconsistency in management and security procedures, (SADF). SADF integrates different components that are causing it to be likely susceptible to vulnerable servers due part of a network for supporting the autonomic manage- to misconfiguration or outdated software. Moreover, an ment of its infrastructure in response to security-related university network contains some workstations and wire- incidents. SADF has been deployed on a prototype inte- less access points, which together with the trend of BYOD grating a configuration management system with a VAS and the availability of 3G/4G connectivity, constitute a for managing a distributed firewall, in which possible plethora of equipment outside the control of the central threats can be detected (i.e., servers with vulnerabilities) management team. and appropriate decisions be made for mitigating their The firewall is usually treated as the first line of defense impacts with minimal human intervention. of computer networks [10]. A firewall is a trusted host The motivation for using self-adaptation is the proven that acts as a choking point of one or more networks, effectiveness and efficiency of self-adaptation in dealing usually at the border between a public and a private net- with uncertainty in a wide range of applications, includ- work. The traffic between the networks passes through ing those related to security [5–7]. Our current prototype the firewall, which decides based on a set of rules, which of SADF monitors the hosts of a network, which are then network packet should be allowed to continue or blocked. scanned by a VAS in the search for known vulnerabili- However, as previously mentioned, the limitations of a ties. Once a vulnerability is discovered, firewall rules for centralized firewall, which is not able to protect against reacting to it are defined based on high-level policies. internal attacks, has motivated the definition of a dis- These rules are then applied to individual hosts, effectively tributed firewall model [2]. In a distributed firewall, secu- mitigating the exposure window for the vulnerable server. rity policies are defined in a centralized fashion using SADF was first proposed in [8], in which the main specific language, and then distributed, by secure means, issues related to the theme were presented, together with a to be applied to different enforcement points. These proposal of architecture and a prototype implementation enforcers can either be located on different segregation that demonstrated its viability. Compared to our previous points inside the network, such as routers and switches, work, this article further details the proposed architec- or on each host of the network [1]. Figure 1 presents a ture, which now fully implements a Monitor-Analyse- general view of a network infrastructure where we can Plan-Execute-Knowledge (MAPE-K) feedback control identify a Rules Management Server, which is responsible loop [9] for managing the self-adaptation process. This for dealing with and distributing the firewall rules into the article also presents details about high-level policies different enforcement points, such as switches, servers, and the decision-making process used for controlling or both. da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 3 of 21 Fig. 1 General view of the distributed firewall scope considered in this paper Operating and maintaining this infrastructure requires a One way for achieving self-adaptation is through the continuous effort as, even though there are different tools Monitor-Analyse-Plan-Execute-Knowledge (MAPE-K) for facilitating management and maintenance actions, it feedback control loop over a target system [11]. In this is common to find out that most of these operations way, a self-protection mechanism allows the protected are still manually conducted. For example, the majority system to monitor and analyze its resources to detect of institutions use, apart from firewalls, some tool for possible problems, being able to react accordingly to configuration management, resource and service moni- deal with the detected problem. This reaction depends toring, intrusion detection and vulnerability assessment on the type of monitoring and analysis technique being systems, which scans the network pointing out vulner- employed, type of incident and the type of system being able services. These are important tools for maintain- protected, and can range from emergency system shut- ing the network infrastructure, but there is a lack of down, deactivation of damaged module and replacement integration among them, requiring human intervention for a new instance, user or connection blocking, etc. [7]. for conducting some tasks, and wasting valuable time Figure 2 presents a reference architecture for a sys- between the moment an incident is detected, and an tem that implements self-protection. At a meta-level, we administrator performs some corrective action to mitigate have a protecting sub-system, responsible for implement- its impact. ing the MAPE-K feedback control loop that protects the In this context, software self-adaptation can be used protected sub-system at the base level. The protected sub- for integrating such tools, contributing for automating system contains the system functionality associated with the security management of the network, with minimal the main application logic and may incorporate different human intervention. security mechanisms, such as access control and cryp- A self-adaptive software system is able to modify its tography, and different execution environment such as own structure or behaviour during run-time in order to Software Defined Networks with or without support for deal with changes in its requirements, the environment Network Functions Virtualization. The meta-level subsys- in which it is deployed, or the system itself [9]. Among tem is responsible for detecting security-related incidents the different properties of a self-adaptive system, self- and for the decision-making associated with the use of the protection has been identified as a key concept for build- mechanisms available at the base-level [7]. The base-level ing autonomous self-managed systems. While systems’ sub-system runs over and interacts with, a domain, which architectures are becoming more dynamic and adaptive, can also be monitored for helping in the decision making the majority of the protection mechanisms have kept sim- of the MAPE-K at the meta-level. ple, with security policies usually manually defined, in a Thinking along these lines, a SADF solution can be slow and costly way. employed as a preventive mechanism for dealing with da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 4 of 21 Fig. 2 Self-protection reference architecture [7] well-known vulnerabilities. For example, whenever a par- automation. Figure 3 presents a conceptual view of SADF ticular server contains a vulnerability with a score greater architecture. than a pre-defined value, the firewall could be configured Each phase of the MAPE-K feedback control loop is to only allow access to the server from clients in the same implemented by an engine, which encapsulates the con- network. crete components that allow for each engine functionality. To perform self-adaptation, the Monitor, Analyze, Plan 3 Architecture for self-adaptive distributed and Execute engine components use different models that firewall provide an abstraction of relevant aspects of the managed Our solution for a Self-Adaptive Distributed Firewall system, its environment, and the self-adaptation goals (SADF) is built on top of the MAPE-K reference model [12]. These models are maintained by a knowledge base as the means for logically structuring the different tasks represented in Fig. 3. involved in the management of the security aspects for The Monitoring engine is responsible for collecting network infrastructure, and for integrating the different information about the different servers of the network tools usually involved in those tasks, allowing for their infrastructure. This collection happens through Sensor Fig. 3 Conceptual architecture of the proposed solution da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 5 of 21 interfaces in each server. This data is represented by new firewall rules on the servers. This component must a Server description model, which is a format that can take in consideration mechanisms for guaranteeing secure be manipulated and reasoned upon by the components communication with each server, and configuration man- of SADF. A service description model contains, among agement techniques. other information, details about the operating system, IP The MAPE-K reference architecture allows for the use Address, services’ names, versions and network port. Fur- of different mechanisms for each of its phases, which can thermore, it captures the firewall rules currently in effect be integrated in a number of different interaction pat- on the server. The Monitoring engine is also responsible terns [13, 14]. Thinking along these lines, an SADF-based for obtaining Vulnerabilities descriptions from an exter- solution can be deployed with different components. In nal Vulnerability base. Vulnerabilities are represented our particular architecture, we employed a configuration through CVE , which defines a dictionary and stan- management system and a VAS with the roles of monitor- dard representation format for vulnerabilities descrip- ing and analyzing the network infrastructure. These can tions. These descriptions are published through the CVE be easily replaced by a metrics monitoring system, such as List and maintained by different vulnerabilities databases Zabbix, with threshold-based policies for identifying the (e.g., the NVD ). Vulnerabilities have an associated sever- necessity of adaptation, an IDS or any other analysis prod- ity score calculated based on the CVSS , which defines uctthatcandetect abnormal situationonthe network metrics and formulas for deriving a vulnerability score, infrastructure. The decision-making process of our solu- and a standard format representation. tion is based on high-level policies defined by an adminis- The Analyzer engine relies on a Vulnerability Assess- trator, which must consider the execution environment to ment System (VAS) to search for known vulnerabilities be controlled. One advantage of such approach is the sep- on the services currently running on the network. A VAS aration of concerns between the functions of the MAPE-K works by scanning the network and conducting different loop. SADF controls a distributed firewall, but our archi- tests to find vulnerabilities in systems and servers, pro- tecture allows the management of more sophisticated ducing a vulnerability report for each server. Based on the environments such as Software Defined Networks with server descriptions, the VAS can be employed with higher Network Function Virtualization capabilities when those priority to scan known services running on each server, are available. Since we have taken as a basis a real scenario, usually, when there are changes in the server descrip- in which there is no support to SDN/NFV, we chose to tions or new vulnerabilities have been published. In the focus on the control of a distributed firewall, acting as a meantime, full vulnerability analysis of servers can still be proof-of-concept for deployment in such environment. performed. A High-level policy captures the requirements of the administrator, and together with the VAS report 4 Instantiating the SADF and the server description, is used for detection of policy The proposed SADF architecture has been instantiated violations. For example, servers with a vulnerability score into a prototype implementation using a combination greater than a particular threshold should only be acces- of existing open source and in-house developed compo- siblefrommachines in thesamenetwork,but thecurrent nents. This instantiation has been used to build a case firewall rules allow access from anywhere. All this data study to demonstrate the feasibility of our approach. As is used by the Analyzer engine component for producing a scenario for presenting its instantiation, in this paper Analysis report, which indicates, for example, servers with we consider the protection of a Web server running known vulnerabilities. the Apache HTTPD software and the JBoss Application The Decision engine component is responsible for the Server. plan phase of the MAPE-K loop. This component is In this section we present details about the different responsible for making decisions on how to respond to representation models employed in our instantiation, fol- the encountered situation based on the analysis report, lowed by a description of the developed prototype. the server descriptions, the high-level policies, and a set of Firewall rules templates. These templates provide a sort 4.1 Model representation of parametrized firewall rules for different services, which One aspect that must be considered for a self-protection can then be employed by the Decision engine for defining solution is the representation of the protected environ- specific firewall rules to be applied. The creation of fire- ment, such as servers, services, and firewall rules. wall rules must employ mechanisms for avoiding conflicts For representing servers and their deployed services between rules. Besides creating firewall rules to be applied we chose the representation language defined by the to the servers of the network, the Decision engine also Puppet configuration management tool. The Puppet lan- produces a report intended for a human administrator. guage allows the description of servers, services, and At the execute phase we have a Firewall rule application configurations using a parametrized approach and well- engine component, which is responsible for effecting the defined semantics. Puppet configures systems in two da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 6 of 21 main stages: compiling and applying a catalog. A cat- decided to employ the FLIP language [15, 16]for defin- alog is a document that describes the desired system ing the firewall rules templates that SADF receives as state. It lists all resources that need to be managed, input. In FLIP, firewall rules are defined using a high- as well as any dependencies between those resources. level language that can be automatically translated into Thecoreofthe Puppet language is declaring resources. device-specific format. FLIP provides a well defined lan- Groups of resources can be organized into classes, which guage with formal semantics, together with proven sound are larger units of configuration. While a resource may and complete algorithms for conflict resolution and trans- describe a single file or package, a class may describe lation into device specific firewall rules. Its formalism was everything needed to configure an entire service or one of the main reasons for choosing FLIP. application. An example of representation for a server and its services is shown in Listing 1. The node named sadf- Listing 2 Example of firewall rules using the FLIP language target.info.ufrn.br was previously added to the Puppet ecosystem, which allows to describe and apply new con- 1 domain sadf −target . info . ufrn . br = [10.3.128.12] , figurations to this server. As shown in Listing 1, the node 2 local −network = [ 1 0 .3.128.0/24] , has two monitored services: the Apache HTTPD - a well- known open source HTTP server -, and the JBoss - an 4 service apache = tcp . [ port =80] , 5 jboss = tcp . [ port =8080 , port =8009 , port application server to the Java Platform, Enterprise Edition =9090] , (Java EE). 7 policy_group vulnerable_jboss { 8 incoming : Listing 1 Example of a node description using the Puppet 9 apache { allow ∗} language 10 jboss { deny ∗ except local −network } 11 } 1 node ’ sadf −target . info . ufrn . br ’ { 12 2 13 apply vulnerable_jboss on sadf −target . 3 include apache : : mod : : php info . ufrn . br ; 4 apache : : vhost { ’ apache ’ : 5 port => ’80 ’ , 6 docroot => ’ / var /www/ html ’ , 7 } Listing 2 presents an example of a rule in FLIP. The 9 include jboss first block (lines 1-2) defines the domains, which can 10 jboss : : default { ’ jboss ’ : be networks or hosts. We define a target server (sadf- 11 http_port => 8080 , target.info.ufrn.br)and anetwork (local-network)that 12 ajp_port => 8009 , 13 jmx_porp => 9090 , represents the network in which the target is running. The 14 xms => 1024 , second block (lines 4-5) of FLIP defines services, which 15 xmx => 1024 , may have one or more ports. In this example, Apache and 16 } 17 JBoss were specified. In the sequence, we define a policy 18 include fw_sadf_target group (lines 7-11), which specifies the behavior that will 19 } be taken about services in a given scenario. One group was created that allows access to Apache HTTPD (line 9) and blocks access to JBoss (line 10) except when the con- Briefly, the settings on Listing 1 define that the Apache nection comes from sadf-engine.info.ufrn.br. Finally, it is HTTPD server must run the PHP module (line 3), and cre- ate a VirtualHost listening to port 80 from DocumentRoot necessary to make a connection between the group and /var/www/html (lines 4 to 7). Regarding JBoss service, the protected domain (line 13). three ports must be configured: 8080 which is bound to Figure 4 presents a class diagram with the meta-model the HTTP connector, 8009 to the AJP connector, and 9090 created for manipulating FLIP firewall rules as objects. that works as a managing interface to the JMX (lines 11 The Model class represents the language model that con- to 13). Moreover, the parameters xms and xmx are used sists of declarations. A Declaration is a generic block to determine the min and max memory size, respectively, that represents each of the terms supported by FLIP. The to be allocated on the HEAP (lines 14 and 15). The class Domain class describes a network or host, which has the fw_sadf_target (line 18), which will be detailed later on, is attributes name and address to represent the name of applied to this node, defining a specific firewall rules for the domain and the IP address. The Service class repre- the sadf-target.info.ufrn.br node. sents a service with names and ports. The Policy_group Similarly, it is necessary to represent firewall rules in a class defines the policy that has a name, traffic direc- format that can be reasoned upon. For this purpose, we tions, which can be incoming or outgoing, policy-related da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 7 of 21 Fig. 4 Class diagram of FLIP implementation in Xtext services and domains that can be inserted into the pol- Listing 3 Firewall rule created by using Puppet icy as the target domain of the action or exception to 1 c l a s s fw_sadf_target { 2 include firewall_module the target group. Finally, the Apply class assigns policies 3 firewall { ’001 accept connections from to domains, causing their traffic to meet the conditions puppet master ’ : described in the FLIP policy. 4 proto => ’ a l l ’ , 5 source => ’10.3.225.163 ’ , In order to apply firewall rules, FLIP models need to be 6 action => ’ accept ’ , translated into Concrete firewall rules . Since we employ 7 } the Puppet language for describing and managing servers 8 firewall { ’002 accept connections from sadf −scanner ’ : and services, we employed Puppet’s firewall module for 9 proto => ’ a l l ’ , representing concrete firewall rules, and hence the fire- 10 source => ’10.3.227.77 ’ , wall rules can be applied by Puppet agents. To achieve 11 action => ’ accept ’ , 12 } that, FLIP rules expressed in text files are instantiated into 13 firewall { ’100 deny access to port Java objects, which are then used to create Puppet classes. 8009 ’: During the translation process, some fields are extracted 14 dport => ’8009 ’ , from the FLIP rules’ fields and then written as a Puppet 15 proto => tcp , 16 action => drop , class describing each host and its services. This transla- 17 source => ! 1 0 .3.128.0/24 , tion has been implemented as a Java class that handles the 18 } FLIP Model and makes it possible to obtain its respec- 19 firewall { ’101 deny access to port 8080 ’: tive rule declarations as domains, services, policy_groups 20 dport => ’8080 ’ , and actions to perform the assembly of Puppet’s classes. 21 proto => tcp , Listing 3 presents an example of the class that speci- 22 action => drop , 23 source => ! 1 0 .3.128.0/24 , fies thefirewallrulestothe sadf-target.info.ufrn.br node, 24 } which have been generated from the example pre- 25 firewall { ’102 deny access to port sented in Listing 2. The first two rules (lines 3-12) are 9090 ’: 26 dport => ’9090 ’ , included by SADF to guarantee access from its com- 27 proto => tcp , ponents to the targeted host. The following rules (lines 28 action => drop , 13-30) blocks access to JBoss ports (8009, 8080, 9090) 29 source => ! 1 0 .3.128.0/24 , 30 } except when the connection comes from the network 31 } 10.3.128.0/24. da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 8 of 21 We employ high-level policies to define how to respond 4.2 Prototype implementation to found vulnerabilities in the monitored environment. In this section, we describe our prototype implementa- These policies are based on Event-Condition-Action tion, whose concrete architecture is illustrated in Fig. 5. (ECA) rules. The basics of an ECA rule imply that when- Implementation and functioning details for each devel- ever an event occurs, a predefined condition is evalu- oped module are also presented. Moreover, the iterations ated, which trigger a specific action when the condition between the modules and the tools/models employed in is true. The event may be represented by a complex the solution are discussed. structure involving a number of sub-events. Similarly As previously mentioned, we employ the Puppet con- to the event, the condition may be formed by several figuration management language for describing servers’ sub-conditions that must be evaluated under a spe- configurations. Puppet provides tools for applying config- cific logic. Finally, an action may be a composition urations, and for obtaining the current status of a host. A of actions according to the condition and event that Puppet agent component runs on each host, and reports activated it [17]. to (and receive commands from) the puppet-master com- In our approach, an event is a discovered vulnerability, ponent, which stores servers description into the Puppet while the condition captures the context of this vulnera- catalog. Hence, Puppet agents fulfill the roles of sen- bility in terms of its severity and other information that sor and effector of servers, while the Puppet master is can be used for decision making on how to respond, i.e., responsible for the monitor and execute phases of the the action. MAPE-K. The syntax used to define a policy is given by the set of fields {server, service, port, CVSS, CVE, action} 4.2.1 Monitor engine that can be mapped to four scopes: target, score, vul- The function of this module is to collect information nerability, and execution, as described in Table 1.The regarding all hosts members and so creating the Server target scope defines the policy application range and is description whichisusedbySADFtorepresent theservers formed by the fields server, service,and port.The score and its services. All hosts managed by the Puppet are taken scope - given by the CVSS field - specifies the CVSS as members of our scheme. The Puppet collects informa- threshold value, hence addressing vulnerabilities with tion regarding the servers by pooling agents (see Fig. 5) CVSS equal or higher than this value. In contrast, the -thatplays theroleofa sensor on SADF architecture - and store it in its Catalog. Thus, the monitoring module vulnerability scope - given by the CVE field - directly can gather information about all servers by communi- addresses the CVE, allowing to act only for specific vul- nerabilities. The score and vulnerability scopes may be cating to the PuppetDB -a Data Warehouse that stores optional, i.e., as long as one is provided, the other may be information and allows the access to it through a specific omitted. API . The target, score and vulnerability scopes comprise the The UML sequence diagram in Fig. 6 illustrates condition of our policy, while the action scope defines the interaction between the Monitor engine and the how to respond when the specified condition is eval- PuppetDB.The Monitor engine first creates an empty list uated to true. Action in our policy refers to a fire- of descriptions (call 1), then it contacts the PuppetDB to wall rule template, which must be provided together collect the list of managed nodes (call 2), and finally, it with the policy. In this way, the proposed system can starts a loop to recover the list of services to each node dynamically select the appropriate parametric rule tem- (call 3). The Monitor engine maintains a list of servers pre- plate for the detected situation, which is then popu- viously collected to detect when there is a change in one of lated based on the information about the affected host the servers. Thus, once all servers’ descriptions have been description. obtained, the Monitor engine performs internal processing Table 1 High-level policy’s fields description Field Description Mandatory Input syntax Server Target server for the policy Yes Hostname, network range or just ’any’ to represent any server. Service Target service for the policy Yes Server name or ’any’ to represent any service. Port Target port for the policy Yes List of integer numbers or ’any’ to represent any port. CVSS Score’s threshold value No A decimal value between 0.0 and 10.0 CVE Vulnerability ID. No List of CVEs. Action Action to be executed for the policy. Yes List of supported action names. da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 9 of 21 Fig. 5 Architectural view of the prototype implementation (call 4) in order to identify servers that need to be scanned again due to changes in their configuration. It is important to mention that the description files defi- nition for servers in Puppet is out of the scope of this work. So there is an assumption that this task was previously performed by the network administrator team. Thereby the focus of this work is to define and apply the firewall rules according to the specified configuration, as well as targeting well-known vulnerabilities on servers. 4.2.2 Analyzer engine Considering that a list of all services running on each server is known, a vulnerability evaluation may be used as the trigger to an adaptation. The OpenVAS is used to scan the servers. It provides an open source solu- tion to identify, quantify and prioritize the vulnerabilities. These properties were explored by the Analyzer engine. In our solution, the OpenVAS Scanner conducts Net- Fig. 6 UML sequence diagram for the Monitor engine work Vulnerability Tests (NVT) for all hosts. An NVT da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 10 of 21 is formed by a script for vulnerability detection, and a A task is a scan configuration that defines how the target specification of the CVE and CVSS for each vulnerability will be tested. detected. OpenVAS Manager gets NVTs through the The Analyzer engine starts each scan (call 4 of the OpenVAS NVT Feed, which is developed based on the UML sequence diagram) and stores its ID. A scan may CVEs from the NVD. take several minutes to complete, as the current Open- The OpenVAS Manager is responsible for control- VAS database includes more than 50,000 entries. Besides, ling the OpenVAS Scanner actions, by providing its the scan duration may vary according to the number of inputs and processing its outputs. All the interactions services on the target and the processing load on the Scan- between the Manager and the Scanner are performed ner and the Server being scanned. Currently, the VAS through the OpenVAS Transfer Protocol (OTP). OTP is queried every five seconds to check whether the scan supplies all the resources to control the scan’s execu- has finished, at which point the Analyzer engine uses the tions. The Manager also includes the OpenVAS Man- stored ID as a key to recover its report (call 5). Each report agement Protocol (OMP), an XML-based stateless API, from the OpenVAS includes, among other data: the CVE, which may be used to interact with and control the the CVSS, the host, the port bound to the affected ser- OpenVAS Manager. vice, the protocol, the suggested solution type, and the The Analyzer engine configures and runs the OpenVAS affected software name. The Analyzer engine process the scans by using the server description. This interaction received report (call 6) to check whether a vulnerability is allowed by the OMP, which receives an XML entry has been detected, or a vulnerability previously detected describing the target host and the scan tasks. A detailed is no longer present. When a vulnerability is detected the view of the interaction between the Analyzer engine and Decision engine is activated to handle it (call 7). the OpenVAS is presented in Fig. 7.The Analyzer engine obtains the Server descriptions of those hosts that need to 4.2.3 Decision engine be scanned (call 1) and builds scan tasks for each server Once activated, the Decision engine must decide how to (see calls 2 and 3 in the figure). Each target defines a host, properly respond to the detected vulnerability. Its behav- listing the ports for all detected services, and thereby all ior is presented in Fig. 8. Initially, it loads the high-level services managed by Puppet in each host can be scanned. policies, the Analysis report,and the Server descriptions Fig. 7 UML sequence diagram for the Analyzer Engine da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 11 of 21 Fig. 8 UML sequence diagram for the Decision engine (calls 1, 2, and 3). Then the policies are evaluated to detect any violation (call 4). This verification involves a set of iterations and conditional operations used to assert the conditions according to the data collected from the Analysis report. When a violation is detected, an adaptation loop is started. In the current prototype implementation, the exe- cution module allows two actions: (1) the configuration of the firewall rules on the affected servers, and (2) to send an alert to the system administrator. The action to be taken is defined by the high-level policy. If the selected action requires blocking a port, then the Decision engine creates the firewall rules using FLIP syntax and then request its translation (calls 6 and 7). Following, the FLIP translates the rules and creates the Concrete firewall rules model, which is written using the Puppet notation (call 8). The corresponding action is then requested to the Executor engine, either to apply new firewall rules to a server (call 9) or to notify the system administrator (call 10). Figure 9 presents a simplified algorithm describ- ing the policy evaluation mechanism. Essentially, the evaluation consists in looping through each server in which a vulnerability has been detected, and checking whether the conditions of the high-level policies hold Fig. 9 Algorithm for policy evaluation and apply. da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 12 of 21 4.2.4 Executor engine 5 Evaluation Once the planning phase is finished, the Executor engine This section presents an evaluation of SADF that has been is invoked to apply all the necessary actions. conducted in a controlled environment. To block ports, it would apply the Concrete firewall First, we present the complete operational flow of rules by sending the generated classes to the directory SADF to demonstrate its feasibility (section 5.1). In the /etc/puppetlabs/code/environments/production/manifests sequence, we present a set of experiments to evaluate to be read by the puppet-master. Following this step, SADF resource consumption (section 5.2). Finally, we each agent can contact the master to apply the sched- discuss the achieved results (section 5.3). uled firewall rules. The puppet-master together with the firewall module manages and configures the generated 5.1 Demonstration iptables and ip6tables rules to be applied directly to A set of servers and services in a controlled environ- each host. ment were deployed in order to demonstrate the func- The Zabbix monitoring system is employed in order tionalities of the proposed SADF. All servers run the to support alerting system administrators. Zabbix is a CentOS 7. Such services are similar to what can be network monitoring system with support to triggered found in a typical network infrastructure of a univer- notifications. SADF creates a list of alerts, which is used sity. Figure 11 presents a general view of the deployed as the basis for populating a monitoring template con- environment, in which we can find two groups of figured into Zabbix. This template includes information servers. The first group corresponds to SADF compo- about the affected host, its service, and the discovered nents and is composed by three servers: (i) puppet- vulnerability, with its respective CVSS. Through the tem- master agent that acts as a configuration management plate, Zabbix can detect the alerts sent by SADF, creat- server; (ii) sadf-engine, which contains all components ing triggers for each alert into Zabbix monitoring screen of SADF; and (iii) sadf-scanner corresponding to the that should be permanently exhibited on the Network OpenVAS vulnerability assessment system. The second Operation Center. We have employed Zabbix on SADF group of servers represents the target environment, which because this is the monitoring solution used by the is controlled by SADF, and corresponds to the dif- network administration team of where SADF is being ferent servers that will have their firewall rules man- deployed. aged by our solution. For this first demonstration, we The behavior of the Executor engine is presented in have instantiated a total of 10 servers (sadf-target01 Fig. 10. As previously mentioned, our current proto- to sadf-target10), in which we have services managed type supports two actions, the notification of admin- by Puppet. istrators (call 1), or the application of firewall rules Several services that are commonly found on complex through puppet-master (call 2). In case of applying fire- network infrastructure were selected in order to demon- wall rules, once the new rules have been saved, each strate SADF functionality. The selection of services was puppet-agent obtain them through the Puppet catalog based on past experiences with incidents that occurred in (call 3), and then applies the rules on their corresponding the UFRN network infrastructure. Therefore, we have hosts (call 4). some services with vulnerabilities of different severity Fig. 10 UML sequence diagram of Executor engine da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 13 of 21 P5: Only allow connections from a particular network on any server that belongs to this network in case any vulnerability is found. “Server = 10.2.59.0/24”, “Service = any”, “Port = any”, “CVSS = any”, “Action = isolate” Once the high-level policies are in place, SADF is ready to start monitoring and controlling the target servers, according to the MAPE-K feedback control loop. It starts by obtaining the server descriptions of the target servers and interacting with OpenVAS for creating the respective scan routines. Based on OpenVAS results, which identi- Fig. 11 Environment deployed for testing SADF fied the existing vulnerabilities in the testing environment, SADF employed the high-level policies to decide how to respond. Following our case study, the OpenVAS found a vulnerability with CVSS score 7.8 in HTTP service that levels. Table 2 presents details about versions, ports, and allows remote attackers to cause a denial of service (mem- vulnerabilities of the services considered in this demon- ory and CPU consumption). An extract of the XML report stration. is presented in Listing 4. These services have been distributed in 10 servers sadf- Listing 4 Extraction of OpenVAS report to a vulnerable HTTP target according to Table 3. The column Vulnerability server Severity represents the server status based on the vulner- 1 . . . <port >80/ tcp abilities found on its deployed services. The classification 2 <host >10.3.128.20 </ host > of vulnerabilities is based on the CVSS V2 specification , 3 < severity >7.8 </ severity > which defines the intervals 0.0 − 3.9 as LOW,4.0 − 6.9 as 4 <threat >High </ threat > 5 </ port > <nvt oid MEDIUM,and 7.0 − 10.0 as HIGH. ="1.3.6.1.4.1.25623.1.0.901203" > Once all target servers are configured and managed 6 <name> by puppet-master, SADF is capable of extracting their 7 Apache httpd Web Server Range Header Denial of Service V ulnerability Server descriptions to monitor and control them. The 8 </name> next step is to configure the high-level policies that define 9 <family >Denial of Service </ family > the behaviour of SADF. For this demonstration, we have 10 <cvss_base >7.8 </ cvss_base > 11 <cve >CVE−2011 −3192</ cve > defined four policies that either block vulnerable services 12 <bid >49303 </ bid > or alert network administrators in different contexts. The 13 ... policies defined are listed below with an informal textual description, and then using the policy definition rules of Based on policy P1, which defines the trigger of alerts SADF. for vulnerabilities with CVSS above 5.0, we have the list of alerts presented in Fig. 12, extracted from Zabbix. P1: Alert administrator if any vulnerability with CVSS SADF creates several objects and triggers in Zabbix with higher than 5.0 is found in any server: information about the vulnerable services, using a color “Server = any”, “Service = any”, “Port = any”, “CVSS = classification according to the severity of the vulnerabil- 5.0”, “Action = alert” ity found. We can notice that some servers appeared more P2: Block any port on any server assigned to any service than once in the list (such as sadf-target10), which indi- in which with vulnerability “CVE-2013-4810” cates that either the server contains more than one vul- (regarding to JBoss 5.1.0) has been detected: nerability, or that the same vulnerability has been found in “Server = any”, “Service = any”, “Port = any”, “CVE = different ports. CVE-2013-4810”, “Action = block” Based on the other policies, SADF activated the Execu- P3: Block any port assigned to any service with CVSS tor engine for blocking several ports. Policy P2 blocked equal or higher than 7.0 running on the server port 8080 on server sadf-target09, while policy P3 blocked sadf-target06.info.ufrn.br: port 80 on server sadf-target06. policies P2 and P4 caused “Server = sadf-target06.info.ufrn.br”, “Service = any”, the blocking of ports 21 and 8080 on server sadf-target01, “Port = any”, “CVSS = 7.0”, “Action = block” and policy P4 blocked port 21 on server sadf-target03. P4: Block any server or port assigned to the service ftp Policy P5, in particular, is an example of a policy which with CVSS equal or higher than 9.0: could be applied for isolating servers of a particular net- “Server = any”, “Service = Ftp”, “Port = any”, “CVSS = work by only accepting connections from their network 9.0”, “Action = block” da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 14 of 21 Table 2 Services and vulnerabilities used to test the prototype Service Port CVE CVSS Vulnerability Apache 2.4.6 443 CVE-2016-2183, CVE-2016-6329 5.0 Confidential information leak. Apache 2.4.6 80 CVE-2004-2320, CVE-2003-1567 5.8 Cross site Apache 2.2.15 80 CVE-2004-2320, CVE-2003-1567 5.8 Cross site Apache 2.2.15 80 CVE-2011-3192 7.8 Denial-of-service (DoS) MySQL 5.5.52 3306 - - - ProFTPD 1.3.4a 21 CVE-2015-3306 10.0 Arbitrary remote code execution. JBoss 5.1.0 8080 CVE-2013-4810 10.0 Arbitrary remote code execution. JBoss 5.1.0 8009 - - - JBoss 5.1.0 9090 - - - Tomcat 8.5.16 8080 - - - Tomcat 8.5.16 8009 - - - Tomcat 8.5.16 9090 - - - (10.2.59.0/24) when any vulnerability is found. Such pol- detected a vulnerability and reacted according to its poli- icy triggers the application of firewall rules on all servers cies. We can notice rules allowing connections from SADF managed by SADF that belong to the identified network. components (puppet-master and sadf-scanner), similar to The blocking of ports is achieved by manipulating Fig. 13, and rules for blocking (DROP) incoming packets objects based on the FLIP meta-model defined by us. (INPUT chain) on ports 21/tcp and 8080/tcp. Theseobjects arethentranslatedintoPuppetclasses con- This procedure was repeated to all servers where we taining concrete firewall rules. Each server has its own confirmed the application of firewall rules according to Puppet class with its respective firewall rules. Listing 5 the high-level policies defined. We have repeated these presents an example of class for server sadf_target01. experiments, varying the services versions and known vulnerabilities, services, and high-level policies. In all Listing 5 New class created by the SADF to block ports 21 and occasions SADF worked as expected, demonstrating its 8080 on the server sadf-target01 effectiveness in blocking vulnerable services and trigger- 1 class fw_sadf_target01 { ing alarms for alerting administrators when the blocking 2 include firewall_module is deemed a too harsh response. 3 firewall { ’100 ’: 4 dport => ’8080 ’ , 5 proto => tcp , 5.2 Resource consumption experiments 6 action => drop , After demonstrating the operational viability of SADF, 7 } we have conducted a set of experiments for evaluating 8 firewall { ’101 ’: its resource consumption. These experiments have been 9 dport => ’21 ’ , 10 proto => tcp , conducted with the objective of providing subsides for 11 action => drop , 12 } 13 } Table 3 Servers and services tested Server Vulnerability severity Running services The iptables tool was used on the affected servers in order to confirm if the firewall rules have been correctly sadf-target01 HIGH JBoss 5.1.0; ProFTPD 1.3.4a applied. sadf-target02 MEDIUM Apache 2.4.6; Tomcat 8.5.16 Figure 13 presents the output for server sadf-target01 sadf-target03 HIGH Apache 2.4.6; ProFTPD 1.3.4a before SADF has run. We can notice explicit rules allow- sadf-target04 MEDIUM Apache 2.4.6; MySQL 5.5.52 ing (ACCEPT) packets from the servers that play the sadf-target05 NONE Tomcat 8.5.16 role of puppet-master (IP address 10.3.225.163) and sadf- sadf-target06 MEDIUM Apache 2.2.15 scanner (IP address 10.3.227.77), and no closed ports (indicated by the absence of rules, which means that all sadf-target07 NONE MySQL 5.5.52 connection are accepted). These rules are maintained by sadf-target08 MEDIUM Apache 2.4.6 the firewall module of Puppet, defining the servers that sadf-target09 HIGH JBoss 5.1.0; Apache 2.2.15 are part of SADF as trusted. Figure 14 presents the ipta- sadf-target10 MEDIUM Apache 2.2.15; MySQL 5.5.52 bles output for the same server (sadf-target01)after SADF da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 15 of 21 Fig. 12 Vulnerability alerts triggered on Zabbix system the allocation of resources for SADF deployment. A first based on the resource allocation to similar services in our observation allowed us to notice that the biggest overhead real network infrastructure. of SADF is related to the vulnerability analysis. Based on To run the first group of experiments, we replicated the this, the experiments conducted have been divided into 10 servers used in the demonstration of SADF, consider- two groups. The first group considered whether there is ing a growing number of servers, respectively, 1, 10, 20, an improvement in the use of OpenVAS when the ports 30, 40 and 50 servers, while employing the same distribu- to be scanned are explicitly indicated (based on the ser- tion of services showed on Table 3. For these experiments, vices’ ports configured via Puppet). The second group OpenVAS has been used in its default configuration, up considered the impact of increasing the number of servers to 10 NVTs running in parallel for each host, and a max- monitored and controlled. imum of 30 hosts that can be verified simultaneously. In These experiments have been conducted on the same this context, in case there are more than 30 servers to be environment used for demonstrating SADF (which has verified, the exceeding ones will be queued until the end been presented in Fig. 11). The configurations of each of the scans in execution. OpenVAS has been restarted server used in these experiments are presented in Table 4. between each test, and the tests have been repeated The resources allocated to puppet-master server are based three times for obtaining the average execution time for on the official documentation of puppet , which recom- each run. mends a server with four cores and at least 4GB of RAM When considering the consumption of hardware for attending a number of 1000 servers. The resources resources, we did not identify any significant difference allocated for sadf-engine correspond to the server used with and without the definition of ports. However, Open- for its development. The server responsible for OpenVAS, VAS took around 2 hours and 43 minutes to scan 50 sadf-scanner, demands more computational power as it servers in its default configuration. When comparing the will potentially conduct more than 50,000 NVTs in each time necessary to run the tests with (Scan on defined monitored host. The resources allocated to this server are ports)and without(Scan without ports definition)port Fig. 13 Iptables output of firewall rules that are managed by Puppet on the server sadf-target01 before running SADF da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 16 of 21 Fig. 14 Iptables output of firewall rules that are managed by Puppet on the server sadf-target01 after running SADF indication, we have a difference up to 20.53% for 50 The results obtained with these experiments have been servers (2 h and 25 min with ports defined). We con- considered satisfactory. The time of 2 hours and 25 min sidered these results as a substantial indication of the to scan 50 hosts is within the expected time given the benefits of directing OpenVAS scansasdonebySADF, complexity of the vulnerability analysis process, and the which encouraged the execution of the second group of experience of the network administration team. experiments. A more detailed discussion about the results obtained is After that, we started to experiment with the full SADF presented in the sequence. solution. As previously mentioned, the biggest overhead of SADF is related to the vulnerability analysis. Thus, our 5.3 Discussion focus was on evaluating the analysis phase of SADF, which The experiments conducted have shown that SADF can includes OpenVAS to scan hosts on specific ports. dynamically update firewall rules in response to dis- During these experiments, we have observed the covered vulnerabilities, following the high-level policies resource consumption of sadf-scanner to understand defined by an administrator. Based on this, we conclude its behavior and profile its hardware requirements. We that SADF indeed provides a significant improvement in present the measurements for the experiments involving the administrative procedures of the network administra- 50 hosts. Figure 15 presents CPU load, Fig. 16 presents the tion team of UFRN in detecting and protecting vulner- RAM utilization, and Fig. 17 presents the network usage. able services. This is evidenced when we consider that The higher CPU-load is expected, due to the number such procedure used to be conducted manually by net- of NVT executing simultaneously. Regarding memory and work administrators, usually by different teams, and the network load, we notice a low usage, with some peaks response to a detected vulnerability took hours (some- caused by the inner workings of NVTs, which involves times days) to be implemented. discovery and test of ports and service, followed by load- In its current implementation stage, SADF is only able ing and running of tests. These peaks represent when the to deal with hosts. Although SADF supports the speci- number of servers tested in parallel dropped below 30, fication of more complex firewall rules using FLIP and and the tests for the next servers in the queue have been our high-level policies, we do not consider the deploy- started. Regarding network consumption, a maximum ment of firewall rules in other points of the network of 6.78 Mbits/s is viewed as a good result, considering infrastructure, such as routers and switches. This is due that the datacenter infrastructure is connected to at least to a simple decision-making implementation, which only 1Gbits/s, with 10 Gbits/s in several segments, and the targets hosts. Through the use of adaptation rules, the duration of the peak when compared to the whole testing response can be anything supported by the controlled time. environment. Thus, although the proposed SADF can, for example, isolate a network employing firewall rules, such isolationisachievedbyapplying firewall rulesateachhost Table 4 SADF servers resource configuration of the affected network. Server Memory Processor The resource consumption experiments have confirmed the overhead caused by the vulnerability scanner, and the puppet-master 4GB 4Cores improvement of its use when the ports to be scanned are sadf-engine 16 GB 8 Cores identified. Although the time to scan 50 hosts is above sadf-scanner 16 GB 16 Cores two hours, it is still substantially faster than the traditional da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 17 of 21 Fig. 15 Load average on the SADF server for 50 servers manual approach. One aspect that has not been explored as a satisfactory time, since the blocking action occurs in is to deploy OpenVAS as a cluster using a master-slave a preventive way, upon discovery of a vulnerable server. architecture, which has the potential to provide horizon- Regarding the secure communication between the tal scalability to our solution without any changes to its SADF and protected servers, we employ the certificate implementation. based security provided by the Puppet tool, which takes Another aspect worth mentioning concerns the Puppet care of authentication and secure transit between the configuration management tool. Puppet presents a pull- puppet-master and its agents through SSL certificates. based model, in which agents query the master at pre- Thenumberof50hosts have been used forthe tests determined intervals in search of new commands (usu- due to limitation of the infrastructure available for this ally, 30 minutes). It might be considered an issue when project at the time of the experiments. Nevertheless, this responding on-the-fly to detected situations, which is not number has been considered relevant for the evaluation the case in this paper. We focused on preventing the of the proposal when taking into account feedback from exploitation of known vulnerabilities before they hap- the network management team, simulating an infrastruc- pen, opposed to traditional IDPS systems, which focus on ture capable of providing many applications and services. responding to incidents in real-time. Hence, we consider Also, this is the current number of servers that will be ini- that 30 minutes is a reasonable time for applying fire- tially monitored when deployed in the UFRN data center. wall rules blocking vulnerable services, although this time Besides that, the results obtained provide us guidelines on could be reduced. We have changed this configuration to how to allocate resources to SADF components to repro- 10 minutes in our experiments, which is still considered duce theexperiments with alargernumberofservers. Fig. 16 RAM memory utilization on the SADF server for 50 servers da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 18 of 21 Fig. 17 Network traffic on the SADF server for 50 servers 6 Related work for analyzing download events for detecting malware The discussion on centralized and distributed firewalls is download. These works are concentrated on improving well established in the literature [2, 18]. One of its first an IDS, and present interesting discussions that could implementation proposals has been presented by Ioanni- complement SADF in a possible future work integrat- dis [1], in which kernel extensions have been developed for ing IDS into its architecture. Iannucci and Abdelwahed the OpenBSD distribution, together with a policy defini- [24] employ a Markov Decision Process together with an tion language (named KeyNote)and useofIPsec forsecure Intrusion Response System for deciding which action to traffic amongst the hosts of the network. More recently perform in response to a detected intruder. Compared [19] introduces a distributed firewall system for Linux to our work, their approach presents a formalism that platform that works upon Iptables/Netfilter for IPv6 net- can be used for deciding which action to perform, con- works with IPsec support. A distributed firewall archi- sidering cost and impact, from a list of possible actions. tecture was proposed in order to improve performance, Of-IDPS [25] is a system that considers network usage his- handling the additional costs of encryption of packages tory and IDS alerts for extracting security rules that are with IPsec. applied through a Software Defined Network (SDN) based Autonomic computing and self-protection have been on OpenFlow controllers. gaining traction as the means for dealing with new secu- As stated by Shin et al. [26], SDN environment can be rity challenges and systems, in which static and rigid combined with traditional security mechanisms to rein- security practices are not enough to deal with security force the detection of attacks and to quickly react to them. threats that need to be detected and mitigated at run- In the context of our work, the major impact of SDN on time [7]. In this context,Yuanetal. [7]havedonean a SADF solution would be twofold: at first, the decision extensive systematic survey of the state of the art on making now needs to deal with flows fate besides firewall self-protecting software, identifying trends, patterns, and rules, and second, SADF can act upon switches through gaps. Some works focus on adapting authorization poli- Access Control Lists (ACL) which allows creating rules cies, such as the Self-Adaptive Authorisation Framework connected to the network traffic [27]. In fact, our archi- (SAAF) [5] that focus on adapting access control poli- tecture would fit perfectly with an SDN environment, and cies on the PERMIS system [20], and SecuriTAS [6], a with the range of possibilities pointed out in the literature tool that enables dynamic decisions in awarding physical [26, 27], being able to provide the link between a detec- access, based on a perceived state of the system and its tion tool, the decision making process for deciding how environment. to react to the detected situation, and the commands that Several researchers focus on Intrusion Detection and will change the SDN environment. Similarly, an environ- Response Systems. For example, Uribe and Cheung [21] ment with NFV capabilities can provide more response have looked into the integration between IDSs and fire- options for our architecture. walls, proposing an approach for optimizing IDS config- There are also works that aim to facilitate the configu- uration by only analyzing traffic that is not considered by ration of security mechanisms as part of the instantiation the firewalls’ rules. Zhang and Shen [22]employastatis- process of virtual machines in cloud computing environ- tical learning based approach to reduce false positives on ment [28, 29]. This approach provides IDS/IPS, firewall, IDSs. Rahbarinia et al. [23] use graph mining techniques and anti-malware in a solution Security-as-a-Service. da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 19 of 21 Few works consider the analysis of vulnerabilities is still considered work-in-progress, and may be subject to for making a decision at the network level (i.e., fire- changes. wall rules). Debar et al. [30] present formalisms for The research in the area of self-protection, when con- the definition of security policies that can be dynam- sidering the network level, tend to focus on IDS/IRS. To ically modified in response to detected threats. The the best of our knowledge, we have not found any work formalism presented in their paper is at an abstract that employs vulnerability detection as the trigger for self- level and may consider vulnerability analysis in the adaptation, or that consider the addition of self-adaptive threat detection process. Compared to our work, their capabilities to a distributed firewall. approach can be considered as complementary, pro- viding formalisms that could improve the robustness 7 Conclusions & future work of our approach regarding the definition of high-level This article presented an approach for Self-Adaptive Dis- policies. tributed Firewall (SADF) based on the synergies between To the best of our knowledge, the closest work to ours the MAPE-K feedback control loop of self-adaptive sys- has been presented by Sheridan et al. [31]and involves the tems with the increased network security provided by automatic security of virtual machines in cloud comput- distributed firewalls. The MAPE-K reference model is ing environments. Their approach is based on three flows: used as the means for logically structuring the different First, a VAS analyses a host during its instantiation, noti- tasks involved in the management of network security, fying an administrator by e-mail in case a vulnerability is employing a vulnerability analysis system to detect vul- found. Second, the firewall provided by the cloud platform nerable hosts on the network infrastructure. Along these is activated for allowing access to services known dur- lines, our approach can cope with the complexity on ing instantiation. Third, the Chef configuration manage- the management of distributed firewalls, while reducing ment system is employed for automatically installing and the exposure windows of vulnerable hosts by automati- upgrading software packages for hardening and updat- cally applying firewall rules during run-time, according ing the operating system. Although their approach also to specified high-level policies, in response to detected employs a VAS and activate firewall rules, the VAS out- vulnerabilities. put is not used for decision making on which firewall We have developed a prototype of SADF using a com- rules to apply, as we propose. Moreover, their approach bination of existing open source and in-house developed only considers a virtual machine during its creation, not components, which has been used to conduct a series presenting any means for constant monitoring, and the of experiments, involving different services with a var- automatic update of software packages without any super- ied degree of vulnerabilities. These experiments have vision (or an intelligence level) might be dangerous in a demonstrated the feasibility of SADF, which is able to critical environment. dynamically modify the firewalls on protected servers, An aspect that must be considered for a self-protection and presented a satisfactory performance of the environ- solution is the representation of the protected environ- ment in which it is being deployed. For example, SADF ment, such as servers, services, and firewall rules. We managed to achieve a 20% reduction on the scanning present here some of the options found in the litera- time for a group of 50 servers using the default configu- ture during our searches. The Network Markup Language rations of the OpenVAS vulnerability scanning system, a (NML) [32] is a generic model defined by the OpenGrid significant performance gain which reduces the exposure Forum (OGF) as a standard for modeling networks, such window of a detected vulnerability. These experiments as switches and links, which is out of the scope consid- provided interesting feedback about its configuration and ered in this paper. Regarding the representation of firewall operation that has been incorporated into our solution. rules, apart from the FLIP language (already presented), Although we obtained very encouraging results, SADF there is also the AFPL2 [33] (Abstract Firewall Policy presents some limitations. We employ the Puppet con- Language 2), a domain-specific language that provides an figuration management tool for describing servers and XML Schema for the definition of firewall rules indepen- services, and for applying firewall rules on the affected dent of firewall product. Although its support of NAT hosts. Accordingly, we assume the infrastructure has been rules, AFPL2 has not evolved as FLIP and does not pro- previously configured using this tool, as we employ Puppet vide conflict resolution of firewall rules. The Distributed descriptions as part of our monitoring and execution Management Task Force (DMTF) proposed the Com- engine. mon Information Model (CIM), a specification aimed Another limitation is related to the use of NVTs. Each at allowing the interoperation of management informa- NVTisupdated basedonthe NVTFeed,maintained tion. The CIM also provides an extensible XML model by Greenbone Community .SADFisonlyabletoreact and, although it has been employed by different ven- to known vulnerabilities that have been published to dors, its extension for Network Policy Management [34] NVT Feed. Moreover, recently Greenbone has adopted da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 20 of 21 measures to increase paid subscription to its service, PuppetDB 5.0: API overview https://docs.puppet.com/ which might delay the availability of new NVTs. puppetdb/latest/api/index.html In its current stage, SADF only deal with hosts. 8 OpenVAS http://www.openvas.org/ Although SADF supports the specification of more com- http://www.openvas.org/nvt-dev.html plex firewall rules using FLIP and our high-level poli- Zabbix is an enterprise-class open source monitoring cies, we do not consider the deployment of firewall rules solution for network monitoring and application monitor- in other points of the network infrastructure, such as routers and switches. This is caused by a simple decision- ingofmillionsofmetrics - https://www.zabbix.com/ making process, which only targets hosts. Although it Federal University of Rio Grande do Norte, Brazil is possible to isolate a network through firewall rules, NVD CVSS Support https://nvd.nist.gov/vuln- such isolation is achieved at each host of the affected metrics/cvss network. Puppet system requirements https://docs.puppet. Other improvements on the decision making might com/puppet/5.0/system_requirements.html allow more complex responses. For example, a host firewall might redirect all incoming connection to https://www.ogf.org/ an application level firewall or IDS when a particular Greenbone Community https://www.greenbone.net/ vulnerability has been detected, adding an extra layer en/community-edition/ of security while the vulnerability has not been fixed. Availability of data and materials Another future work involves the integration of our The datasets generated during the current work are not publicly available due solution with traditional IDPSs on the monitoring and to its private nature, as it is related to a real University, but are available from analyses phases, allowing it to react to attacks exploiting the corresponding author on reasonable request. zero-day vulnerabilities. This would allow the use of less Authors’ contributions disruptive firewall rules, such as blocking of vulnerable EPCJ was responsible for the majority of the technical work, implementing the services only from suspect sources. SADF can also be prototype, conducting experiments and collecting the obtained results, drafting the initial version of the article. CEDS made contributions to the easily scaled up by deploying OpenVAS into a cluster con- conception and design of the proposed solution, validating the prototype figuration to deal with an elevated number of monitored implementation, and contributing for critically reviewing the manuscript. servers. MP made contributions to the conception and design of the proposed solution, to designing the experiments conducted, and writing the manuscript. Another possible future work is related to Software- SCS participated in the drafting and critically reviewing the article for important Defined Networks (SDN) and virtualization. In our setup, intellectual content, and made substantial contributions to the analysis of the we have not considered the impact of such technologies. experimental data. All authors read and approved the final manuscript. An SDN-enabled infrastructure, combined with support Competing interests for virtualized network functions, would allow for more The author(s) declare(s) that they have no competing interests. sophisticated responses without direct host intervention. Publisher’s Note New challenges arise from the dynamicity of the Virtual Springer Nature remains neutral with regard to jurisdictional claims in Machines (VMs), which imposes frequent changes on the published maps and institutional affiliations. virtual network topology, where VMs might be migrated Author details for resource management and optimization. We intent on Digital Metropolis Institute, Federal University of Rio Grande do Norte (UFRN), Natal, RN, Brazil. Department of Informatics and Applied Mathematics, conducting further research in this direction in order to Federal University of Rio Grande do Norte (UFRN), Natal, RN, Brazil. support new responses, such as the dynamic redirection of traffic to an application proxy that could perform a Received: 24 August 2017 Accepted: 10 April 2018 second authentication. References Endnotes 1. Ioannidis S, Keromytis AD, Bellovin SM, Smith JM. Implementing a Common Vulnerabilities and Exposures sponsored by Distributed Firewall. In: Proceedings of the 7th ACM Conference on Computer and Communications Security. New York: ACM; 2000. US-CERT - https://cve.mitre.org p. 190–9. CCS ’00. https://doi.org/10.1145/352600.353052. National Vulnerability Database maintained by NIST - 2. Bellovin SM. Distributed Firewalls. J Login. 1999;24(5):39–47. https://www. cs.columbia.edu/~smb/papers/distfw.pdf. https://nvd.nist.gov/ 3. Meng G, Liu Y, Zhang J, Pokluda A, Boutaba R. Collaborative Security: A Survey and Taxonomy. ACM Comput Surv. 2015;48(1):1:1–1:42. Common Vulnerability Scoring System sponsored by https://doi.org/10.1145/2785733. FIRST - https://www.first.org/cvss 4. Young G, Pescatore J. Magic quadrant for enterprise network firewalls. Tech. Rep. 141050, Gartner RAS Core G. 2008. http://www.eircomictdirect. https://puppet.com/ ie/docs/juniper/gartner_magic_quadrant_2008.pdf. 5. Bailey C, Chadwick DW, de Lemos R. Self-adaptive federated https://forge.puppet.com/puppetlabs/firewall authorization infrastructures. J Comput Syst Sci. 2014;80(5):935–52. PuppetDB-Overview https://docs.puppet.com/puppetdb/ https://doi.org/10.1016/j.jcss.2014.02.003. da Costa Júnior et al. Journal of Internet Services and Applications (2018) 9:12 Page 21 of 21 6. Pasquale L, Menghi C, Salehie M, Cavallaro L, Omoronyia I, Nuseibeh B. 25. dos Santos LAF, Campiolo R, Monteverde WA, Batista DM. Abordagem SecuriTAS: A Tool for Engineering Adaptive Security. In: Proceedings of autonômica para mitigar ciberataques em LANs. In: Simpósio Brasileiro de the ACM SIGSOFT 20th International Symposium on the Foundations of Redes de Computadores e Sistemas Distribuídos (SBRC); 2016. p. 600–13. Software Engineering. New York: ACM; 2012. p. 19:1–19:4. FSE ’12. http://www.sbrc2016.ufba.br/downloads/SessoesTecnicas/152417.pdf. https://doi.org/10.1145/2393596.2393618. 26. Shin S, Xu L, Hong S, Gu G. Enhancing Network Security through 7. Yuan E, Malek S, Schmerl B, Garlan D, Gennari J. Architecture-based Software Defined Networking (SDN). In: Proceedings of the 25th Self-protecting Software Systems. In: Proceedings of the 9th International International Conference on Computer Communication and Networks ACM Sigsoft Conference on Quality of Software Architectures. New York: ICCCN ’16, vol. 1; 2016. p. 1–9. https://doi.org/10.1109/ICCCN.2016. ACM; 2013. p 33–42. QoSA ’13. https://doi.org/10.1145/2465478.2465479. 7568520. 8. da Costa Jr. EP, da Silva CE, Madruga M, Medeiros ST. XVI Simpósio 27. Alsmadi I, Xu D. Security of Software Defined Networks: A survey. Comput Brasileiro de Segurança da Informação e de Sistemas Computacionais Secur. 2015;53:79–108. https://doi.org/10.1016/j.cose.2015.05.006. (SBSeg2016). 2016. http://sbseg2016.ic.uff.br/pt/files/anais/completos/ 28. Daniel J, Dimitrakos T, El-Moussa F, Ducatel G, Pawar P, Sajjad A. ST7-1.pdf. Accessed 15 Mar 2018. Seamless Enablement of Intelligent Protection for Enterprise Cloud 9. Cheng BH, et al. Software Engineering for Self-Adaptive Systems: A Applications through Service Store. In: 2014 IEEE 6th International Research Roadmap. In: Cheng BH, de Lemos R, Giese H, Inverardi P, Conference on Cloud Computing Technology and Science; 2014. Magee J, editors. Software Engineering for Self-Adaptive Systems. Berlin: p. 1021–6. https://doi.org/10.1109/CloudCom.2014.92. Springer-Verlag; 2009. p. 1–26. https://doi.org/10.1007/978-3-642- 29. Pawar PS, Sajjad A, Dimitrakos T, Chadwick DW. Security-as-a-Service in 02161-9_1. Multi-cloud and Federated Cloud Environments. In: Damsgaard Jensen C, 10. Kurose JF, Ross KW. Computer Networking: A Top-Down Approach. Marsh S, Dimitrakos T, Murayama Y, editors. Trust Management IX. Cham: 6th ed. New York: Pearson; 2012. Springer International Publishing; 2015. p. 251–61. https://doi.org/10. 11. Kephart JO, Chess DM. The Vision of Autonomic Computing. IEEE 1007/978-3-319-18491-3_21. Comput. 2003;36(1):41–50. https://doi.org/10.1109/MC.2003.1160055. 30. Debar H, Thomas Y, Cuppens F, Cuppens-Boulahia N. Enabling 12. Iglesia DGDL, Weyns D. MAPE-K Formal Templates to Rigorously Design automated threat response through the use of a dynamic security policy. Behaviors for Self-Adaptive Systems. ACM Trans Auton Adapt Syst. J Comput Virol. 2007;3(3):195–210. https://doi.org/10.1007/s11416-007- 2015;10(3):15:1–15:31. https://doi.org/10.1145/2724719. 0039-z. 13. Sweitzer JW, Draper C. Architecture Overview for Autonomic Computing. 31. Sheridan C, Massonet P, Phee A. Deployment-Time Multi-Cloud In: Parashar M, Hariri S, editors. Autonomic Computing: Concepts, Application Security. In: 2017 IEEE International Conference on Smart Infrastructure, and Applications. CRC Press; 2006. p. 71–98. Computing (SMARTCOMP); 2017. p. 1–5. https://doi.org/10.1109/ 14. Vromant P, Weyns D, Malek S, Andersson J. On Interacting Control SMARTCOMP.2017.7947000. Loops in Self-Adaptative Systems. In: Proceedings of the 6th International 32. van der Ham J, Dijkstra F, Apacz R, Zurawski J. Network markup Symposium on Software Engineering for Adaptive and Self-Managing language base schema version 1. 2013. Grid Final Draft (GFD), Proposed Systems; 2011. p. 202–7. https://doi.org/10.1145/1988008.1988037. Recommendation (R-P) GFD-R-P.206, Open Grid Forum. https://www.ogf. 15. Zhang B, Al-Shaer E, Jagadeesan R, Riely J, Pitcher C. Specifications of a org/documents/GFD.206.pdf. Accessed 15 Mar 2018. High-level Conflict-free Firewall Policy Language for Multi-domain 33. Pozo S, Varela-Vaca AJ, Gasca RM. AFPL2, an Abstract Language for Networks. In: Proceedings of the 12th ACM Symposium on Access Firewall ACLs with NAT Support. In: Second International Conference on Control Models and Technologies. New York: ACM; 2007. p. 185–94. Dependability (DEPEND 2009); 2009. p. 52–9. https://doi.org/10.1109/ SACMAT ’07. https://doi.org/10.1145/1266840.1266871. DEPEND.2009.14. 16. Al-Shaer E. In: Automated Firewall Analytics: Design, Configuration and 34. DMTF. Network policy management profile. 2016. https://www.dmtf.org/ Optimization. Springer International Publishing; 2014. p. 49–74. chap. sites/default/files/standards/documents/DSP1048_1.0.0c_0.pdf. Specification and Refinement of a Conflict-Free Distributed Firewall Accessed 15 Mar 2018. Configuration Language. https://doi.org/10.1007/978-3-319-10371-6_3. 17. Alferes JJ, Banti F, Brogi A. An Event-Condition-Action Logic Programming Language. Berlin, Heidelberg: Springer Berlin Heidelberg; 2006, pp. 29–42. https://doi.org/10.1007/11853886_5. 18. Stallings W. Network Security Essentials: Applications and Standards, 4th edn. Englewood Cliffs: Prentice Hall; 2010. 19. Lai Y, Jiang G, Li J, Yang Z. Design and Implementation of Distributed Firewall System for IPv6. In: Communication Software and Networks, 2009. ICCSN ’09. International Conference on; 2009. p. 428–32. https://doi.org/10.1109/ICCSN.2009.121. 20. Chadwick DW, Zhao G, Otenko S, Laborde R, Su L, Nguyen TA. PERMIS: a modular authorization infrastructure, Concurrency and Computation: Practice & Experience. 2008;20(11):1341–57. https://doi.org/10.1002/cpe. v20:11. 21. Uribe TE, Cheung S. Automatic Analysis of Firewall and Network Intrusion Detection System Configurations. In: Proceedings of the 2004 ACM Workshop on Formal Methods in Security Engineering (FMSE 2004); 2004. p. 66–74. https://doi.org/10.1145/1029133.1029143. 22. Zhang Z, Shen H. M-AID: An Adaptive Middleware Built Upon Anomaly Detectors for Intrusion Detection and Rational Response. ACM Trans Auton Adapt Syst. 2009;4(4):24:1–24:35. https://doi.org/10.1145/1636665. 23. Rahbarinia B, Balduzzi M, Perdisci R. Real-Time Detection of Malware Downloads via Large-Scale URL −→ File −→ Machine Graph Mining. In: Proceedings of the 11th ACM on Asia Conference on Computer and Communications Security. New York: ACM; 2016. p. 783–94. ASIA CCS ’16. https://doi.org/10.1145/2897845.2897918. 24. Iannucci S, Abdelwahed S. A Probabilistic Approach to Autonomic Security Management. In: 2016 IEEE International Conference on Autonomic Computing (ICAC); 2016. p. 157–66. https://doi.org/10.1109/ ICAC.2016.12.

Journal

Journal of Internet Services and ApplicationsSpringer Journals

Published: Jun 4, 2018

References

You’re reading a free preview. Subscribe to read the entire article.


DeepDyve is your
personal research library

It’s your single place to instantly
discover and read the research
that matters to you.

Enjoy affordable access to
over 18 million articles from more than
15,000 peer-reviewed journals.

All for just $49/month

Explore the DeepDyve Library

Search

Query the DeepDyve database, plus search all of PubMed and Google Scholar seamlessly

Organize

Save any article or search result from DeepDyve, PubMed, and Google Scholar... all in one place.

Access

Get unlimited, online access to over 18 million full-text articles from more than 15,000 scientific journals.

Your journals are on DeepDyve

Read from thousands of the leading scholarly journals from SpringerNature, Elsevier, Wiley-Blackwell, Oxford University Press and more.

All the latest content is available, no embargo periods.

See the journals in your area

DeepDyve

Freelancer

DeepDyve

Pro

Price

FREE

$49/month
$360/year

Save searches from
Google Scholar,
PubMed

Create lists to
organize your research

Export lists, citations

Read DeepDyve articles

Abstract access only

Unlimited access to over
18 million full-text articles

Print

20 pages / month

PDF Discount

20% off