FRESCO: Modular Composable Security Services for Software-Defined Networks

Size: px
Start display at page:

Download "FRESCO: Modular Composable Security Services for Software-Defined Networks"

Transcription

1 To appear in the ISOC Network and Distributed System Security Symposium, February FRESCO: Modular Composable Security Services for Software-Defined Networks Seugwon Shin 1, Phillip Porras 2, Vinod Yegneswaran 2, Martin Fong 2, Guofei Gu 1, Mabry Tyson 2 (1) Texas A&M University (2) SRI International College Station, TX Menlo Park, CA Abstract OpenFlow is an open standard that has gained tremendous interest in the last few years within the network community. It is an embodiment of the software-defined networking paradigm, in which higher-level flow routing decisions are derived from a control layer that, unlike classic network switch implementations, is separated from the data handling layer. The central attraction to this paradigm is that by decoupling the control logic from the closed and proprietary implementations of traditional network switch infrastructure, researchers can more easily design and distribute innovative flow handling and network control algorithms. Indeed, we also believe that OpenFlow can, in time, prove to be one of the more impactful technologies to drive a variety of innovations in network security. Open- Flow could offer a dramatic simplification to the way we design and integrate complex network security applications into large networks. However, to date there remains a stark paucity of compelling OpenFlow security applications. In this paper, we introduce FRESCO, an OpenFlow security application development framework designed to facilitate the rapid design, and modular composition of OF-enabled detection and mitigation modules. FRESCO, which is itself an OpenFlow application, offers a Click-inspired [19] programming framework that enables security researchers to implement, share, and compose together, many different security detection and mitigation modules. We demonstrate the utility of FRESCO through the implementation of several well-known security defenses as OpenFlow security services, and use them to examine various performance and efficiency aspects of our proposed framework. 1 Introduction OpenFlow (OF) networks distinguish themselves from legacy network infrastructures by dramatically rethinking the relationship between the data and control planes of the network device. OpenFlow embraces the paradigm of highly programmable switch infrastructures [23], enabling software to compute an optimal flow routing decision on demand. For modern networks, which must increasingly deal with host virtualization and dynamic application migration, OpenFlow may offer the agility needed to handle dynamic network orchestration beyond that which traditional networks can achieve. For an OpenFlow switch, the data plane is made programmable, where flows are dynamically specified within a flow table. The flow table contains a set of flow rules, which specify how the data plane should process all active network flows. In short, OpenFlow s flow rules provide the basic instructions that govern how to forward, modify, or drop each packet that traverses the OF-enabled switch. The switch s control plane is simplified to support the OpenFlow protocol, which allows the switch to communicate statistics and new flow requests to an external OpenFlow network controller. In return, it receives flow rules that extend its flow table ruleset. An OF controller is situated above a set of OF-enabled switches, often on lower-cost commodity hardware. It is the coordination point for the network s flow rule production logic, providing necessary flow rule updates to the switch, either in response to new flow requests or to reprogram the switch when conditions change. As a controller may communicate with multiple OF switches simultaneously, it can distribute a set of coordinated flow rules across the switches to direct routing or optimize tunneling in a way that may dramatically improve the efficiency of traffic flows. The controller also provides an API to enable one to develop 1

2 OpenFlow applications, which implement the logic needed to formulate new flow rules. It is this application layer that is our central focus. From a network security perspective, OpenFlow offers researchers with an unprecedented singular point of control over the network flow routing decisions across the data planes of all OF-enabled network components. Using OpenFlow, an OF security app can implement much more complex logic than simplifying halting or forwarding a flow. Such applications can incorporate stateful flow rule production logic to implement complex quarantine procedures, or malicious connection migration functions that can redirect malicious network flows in ways not easily perceived by the flow participants. Flow-based security detection algorithms can also be redesigned as OF security apps, but implemented much more concisely and deployed more efficiently, as we illustrate in examples within this paper. We introduce a new security application development framework called FRESCO. FRESCO is intended to address several key issues that can accelerate the composition of new OF-enabled security services. FRESCO exports a scripting API that enables security practitioners to code security monitoring and threat detection logic as modular libraries. These modular libraries represent the elementary processing units in FRESCO, and may be shared and linked together to provide complex network defense applications. FRESCO currently includes a library of 16 commonly reusable modules, which we intend to expand over time. Ideally, more sophisticated security modules can be built by connecting basic FRESCO modules. Each FRESCO module includes five interfaces: (i) input, (ii) output, (iii) event, (iv) parameter, and (v) action. By simply assigning values to each interface and connecting necessary modules, a FRESCO developer can replicate a range of essential security functions, such as firewalls, scan detectors, attack deflectors, or IDS detection logic. FRESCO modules can also produce flow rules, and thus provide an efficient means to implement security directives to counter threats that may be reported by other FRESCO detection modules. Our FRESCO modules incorporate several security functions ranging from simple address blocking to complex flow redirection procedures (dynamic quarantine, or reflecting remote scanners into a honeynet, and so on). FRESCO also incorporates an API that allows existing DPI-based legacy security tools (e.g., BotHunter [12]) to invoke FRESCO s countermeasure modules. Through this API, we can construct an efficient countermeasure application, which monitors security alerts from a range of legacy IDS and anti-malware applications and triggers the appropriate FRESCO response module to reprogram the data planes of all switches in the OpenFlow network. Contributions. In summary, our primary contribution is the introduction of FRESCO, which simplifies the development and deployment of complex security services for OpenFlow networks. To this end, we describe FRESCO: a new application development framework to assist researchers in prototyping new composable security services in OF-enabled networks. FRESCO scripts can be defined in a manner agnostic to OF controller implementation or switch hardware (an important feature given the rapid evolution of the protocol standard). A collection of OpenFlow security mitigation directives (FRESCO modules) and APIs to enable legacy applications to trigger these modules. Using FRESCO, security projects could integrate alarms from legacy network security DPI-based applications as inputs to FRESCO detection scripts or as triggers that invoke FRESCO response scripts that generate new flow rules. Several exemplar security applications demonstrate both threat detection and mitigation in an OpenFlow network, including scan detectors [16, 35, 15] and BotMiner [11]. We further show that existing security applications can be easily created with the use of FRESCO. For example, our FRESCO implementations demonstrate over 90% reduction in lines of code when compared to standard implementations and recently published OpenFlow implementations [24]. A performance evaluation of FRESCO, which shows promise in developing OpenFlow security services that introduce minimal overhead for use in live network environments. 2 Background and Motivation Our intent is to design an application framework that enables the modular design of complex OF-enabled network security services, which can be built from smaller sharable libraries of security functions. Before presenting FRESCO s design, we first review some of the challenges that motivate the features of our framework. 2.1 The Information Deficiency Challenge OpenFlow controllers do not uniformly capture and store TCP session information, among other key state tracking data, which is often required to develop security functionality (e.g., TCP connection status, IP reputation). We call this an information deficiency challenge. The FRESCO architecture incorporates a database module (FRESCO-DB) that simplifies storage and management of session state shared across applications. FRESCO also exports a high-level API in the FRESCO language that abstracts away complexities relating to switch management and specific controller implementations. This abstraction is a critical feature to enable module sharing across OpenFlow network instances that may vary in controller and OpenFlow protocol version. 2.2 The Security Service Composition Challenge The FRESCO framework incorporates a modular and composable design architecture, inspired by the Click router 2

3 Figure 1. High-level overview of the FRESCO architecture. architecture [19], which fosters rapid and collaborative development of applications through module composition. For example, a security module design to recognize certain traffic patterns that may represent a threat should be easily linkable to a variety of potential threat mitigation modules that, when triggered by the detection module, produce appropriate flow rule responses. FRESCO incorporates a scripting language that enables the linking of modules through data sharing and event triggering. Another important challenge is the need to provide an API that can facilitate flow rule production decisions using information produced from legacy DPI-based security applications (such as IDS or anti-malware applications). 2.3 The Threat Response Translation Challenge The OpenFlow protocol enables the controlling software layer to communicate flow handling instructions to the data plane. However, while network security technologies do indeed produce threat alerts applicable to responses for individual flows, these technologies also have a need to express more complex (even stateful) security response directives that may span many flow rules, or even address networkwide attack scenarios. We call this the threat response translation challenge. For example, one may wish to define a notion of host quarantine, in which all flows from an infected internal machine are blocked, with the exception that the machine s web traffic should be redirected to a web server that returns quarantine notification pages to the machine s user. One might also wish to define redirection directives that will silently redirect flows from a detected hostile external entity away from an internal production network and into a honeynet for analysis. One might even want to produce a network-wide response to shun malicious traffic, or alternatively, incorporate high-priority flow rules to ensure that emergency administrative flows succeed during a DOS attack. Such security directives may require a complex set of flow rule production logic, which is also ideally sharable as a countermeasure library that could be coupled with many different detection algorithms. 3 FRESCO DESIGN The FRESCO framework consists of an application layer (which provides an interpreter and APIs to support composable application development) and a security enforcement kernel (SEK, which enforces the policy actions from developed security applications), as illustrated in Figure 1. Both components are integrated into NOX, an open-source openflow controller. FRESCO s application layer is implemented using NOX python modules, which are extended through FRESCO s APIs to provide two key developer functions: (i) a FRESCO Development Environment [DE], and (ii) a Resource Controller [RC], which provides FRESCO application developers with OF switch- and controller-agnostic access to network flow events and statistics. Developers use the FRESCO script language to instantiate and define the interactions between the NOX python security modules (we present FRESCO s scripting language in Section 4.3). These scripts invoke FRESCO-internal modules, which are instantiated to form a security application that is driven by the input specified via the FRESCO scripts (e.g., TCP session and network state information) and accessed via FRESCO s DE database API. These instantiated modules are triggered (executed) by FRESCO DE as the triggering input events are received. FRESCO modules may also produce new flow rules, such as in response to 3

4 a perceived security threat, which are then processed by the controller s security enforcement kernel [SEK] (Section 5). 4 FRESCO Application Layer The basic operating unit in the FRESCO framework is called a module. A module is the most important element of FRESCO. All security functions running on FRESCO are realized through an assemblage of modules. Modules are defined as Python objects that include five interface types: (i) input, (ii) output, (iii) parameter, (iv) action, and (v) event. As their names imply, input and output represent the interfaces that receive and transmit values for the module. A parameter is used to define the module s configuration or initialization values. A module can also define an action to implement a specific operation on network packets or flows. An event is used to notify a module when it is time to perform an action. A module is implemented as an event-driven processing function. A security function can be realized by a single module or may be composed into a directed graph of processing to implement more complex security services. For example, if a user desires to build a naive port comparator application whose function is to drop all HTTP packets, this function can be realized by combining two modules. The first module has input, output, parameter, and event. The input of the first module is the destination port value of a packet, its parameter is the integer value 80, an event is triggered whenever a new flow arrives, and output is the result of comparing the input destination port value and parameter value 80. We pass the output results of the first module as input of the second module and we assign drop and forward actions to the second module. In addition, the second module performs its function whenever it is pushed as an input. Hence, the event of this module is set to be push. A module diagram and modules representing this example scenario are shown in Figure 2. Figure 2. Illustration of FRESCO module design (left: model diagram; right: naive port comparator application) An action is an operation to handle network packets (or flows). The actions provided by FRESCO derive from the actions supported by the NOX OpenFlow controller. The OpenFlow standard specifies three required actions, which should be supported by all OpenFlow network switches, and four optional actions, which might be supported by Open- Flow network switches [29]. OpenFlow requires support for three basic actions: (i) drop, which drops a packet, (ii) output, which forwards a packet to a defined port (in this paper, we sometimes use the term forward to denote the output action), and (iii) group, which processes a packet through the specified group. As these actions must be supported by all OpenFlow network switches, FRESCO also exports them to higher-level applications. One optional action of interest is the set action, which enables the switch to rewrite a matching packet s header fields (e.g., the source IP, destination port) to enable such features as flow path redirection. Because one of the primary goals of FRESCO is to simplify development of security functions, FRESCO handles possible issues related to the set action by breaking the set action into three more specific actions: redirect, mirror, and quarantine. Through the redirect action, an application can redirect network packets to a host without explicitly maintaining state and dealing with address translation. FRESCO offloads session management tasks from applications and automatically changes the source and destination IP address to handle redirects. The mirror action copies an incoming packet and forwards it to a mirror port for further analysis. The functionality may be used to send a packet to a feature or other packet analysis systems. The quarantine action isolates a flow from the network. Quarantine does not mean dropping a particular flow, but rather, FRESCO attaches a tag to each packet to denote a suspicious (or malicious) packet. If a packet has the tag, then this packet can traverse only to allowed hosts (viz., a FRESCO script can fishbowl an infected host into an isolated network using packet tags). 4.1 FRESCO Development Environment The FRESCO development environment (DE) provides security researchers with useful information and tools to synthesize security controls. To realize this goal, we design the FRESCO DE with two considerations. First, this environment must export an API that allows the developer to detect threats and assert flow constraints while abstracting the NOX implementation and OF protocol complexities. Second, the component must relieve applications from the need to perform redundant data collection and management tasks that are common across network security applications. The FRESCO development environment provides four main functions: (i) script-to-module translation, (ii) database management, (iii) event management, and (iv) instance execution. Script-to-module translation: This function automatically translates FRESCO scripts to modules, and creates instances from modules, thus abstracting the implementation complexities of producing OF controller extensions. It is also responsible for validating the registration of modules. Registration is performed via a registration API, which enables an authorized administrator to generate a FRESCO application ID and an encryption key pair. The developer embeds the registered application ID into the FRESCO script, and then encrypts the script with the supplied private key. The naming convention of FRESCO applications incorporates the application ID, which is then used by FRESCO to 4

5 associate the appropriate public key with the application. In addition to registering modules, the module manager coordinates how modules are connected to each other and delivers input and event values to each module. Database management: The DB manager collects various kinds of network and switch state information, and provides an interface for an instance to use the information. It provides its own storage mechanism that we call the FRESCO-DataBase (F-DB), which enables one to share state information across modules. For example, if an instance wants to monitor the number of transferred packets by an OpenFlow enabled switch, it can simply request the F-DB for this information. In addition, this database can be used to temporarily store an instance. Event management: The event manager notifies an instance about the occurrence of predefined events. It checks whether the registered events are triggered, and if so delivers these events to an instance. FRESCO supports many different kinds of events, including flow arrivals, denied connections, and session resets. In addition, the event manager exposes an API that enables event reporting from legacy DPI-based security applications, such as Snort [38] or BotHunter [12]. The security community has developed a rich set of network-based threat monitoring services, and the event manager s API enables one to tigger instances that incorporate flow rule response logic. 1 Instance execution: This function loads the created instances into memory to be run over the FRESCO framework. During load time, FRESCO decrypts the application using the associated public key, and confirms that the ID embedded in the script corresponds to the appropriate public key. The application then operates with the authority granted to this application ID at registration time. 4.2 FRESCO Resource Controller The FRESCO resource controller monitors OpenFlow network switches and keeps track of their status. A flow rule that is distributed from a FRESCO application is inserted into a flow table in an OpenFlow switch. Because the flow table has a limit on the number of entries it can hold, it is possible that a flow rule from a FRESCO application cannot be inserted into the flow table. However, because flow rules from a FRESCO application deal with security policy enforcement, such flow rules require immediate installation into the flow table of an OpenFlow network switch. Thus, FRESCO may forcibly evict some old or stale flow rules, both FRESCO and non-fresco, from the switch flow table to make space for new flow rules. This operation is done by the resource controller. Garbage collecting inactive FRESCO rules does not compromise the network security policy: if a prohibited flow is re-attempted later, the FRESCO SEK will prevent other OF applications from performing the flow setup. The resource controller performs two main functions. 1 The example case for this scenario is shown in section 6. The first function, which we call the switch monitor, periodically collects switch status information, such as the number of empty flow entries, and stores the collected information in the switch status table. The second component, i.e., the garbage collection, checks the switch status table to monitor whether the flow table in an OpenFlow switch is nearing capacity. If the availability of a flow table becomes lower than a threshold value (θ), the garbage collector identifies and evicts the least active flow, using least frequently used (LFU) as FRESCO s default policy. 4.3 FRESCO Script Language To simplify development of security applications, FRESCO provides its own script language to assist developers in composing security functions from elementary modules. The textual language, modeled after the Click language [19], requires the definition of six different variables per instance of modular element: (i) type, (ii) input, (iii) output, (iv) parameter, (v) action, and (vi) event. To configure modules through a FRESCO script, developers must first create an instance of a module, and this instance information is defined in type variable. For example, to use a function that performs a specific action, a developer can create an instance of the ActionHandler module (denoted as type:actionhandler within a FRESCO script). Developers can specify a script s input and output, and register events for it to process by defining the script s input, output, parameter, and event variables. Multiple value sets for these variables (e.g., specifying two data inputs to input) may be defined by using a comma as the field separator. Defining an instance is very similar to defining a function in C or C++. A module starts with the module name, two variables for representing the number of inputs and outputs, and left braces (i.e., { ). The numbers of inputs and outputs are used to sanity check the script during module translation. Like C or C++ functions, a module definition ends with a right brace (i.e., } ). The action variable represents actions that a module will perform based on some conditions, where the conditions are determined by one of the input items. There may be multiple conditions in the action, which are separated by semicolons. We summarize these variables in Table 1, and Figure 3 shows example scripts of the port comparator application shown in Figure 2 (right) with two connecting modules. FRESCO Script Execution: We use a simple running example, shown in Figures 3 and 4, to illustrate the execution of a FRESCO script. First, an administrator composes a FRESCO script (shown in Figure 3) (1), and loads it into FRESCO (2). Next, when Host A sends a packet to port 80 of Host B through an OpenFlow switch, as illustrated in Figure 4 (3), this packet delivery event is reported to the FRESCO DE (4). The FRESCO DE creates instances from modules defined in the FRESCO script (i.e., port comparator instance from comparator module and 5

6 Variable Explanation Possible Values instance name (#input)(#output) denotes an instance name (should be unique) (#input) and (#output) denote the number of inputs and outputs type: [module] denotes a module for this instance [module] names an existing module input: a 1,a 2,... denotes input items for a module a n may be set of flows, packets or integer values output: b 1, b 2,... denotes output items for a module b n may be set of flows, packets or integer values parameter: c 1,c 2,... denotes configuration values of a module c n may be real numbers or strings event: d 1,d 2,... denotes events delivered to a module d n may be any predefined string action : condition? action,... denotes set of conditions and actions performed in the module { } denotes the module start ({) and end (}) - condition follows the same syntax of if condition of python language; action may be one of the following strings (DROP, FOR- WARD, REDIRECT, MIRROR, QUARANTINE) Table 1. Key variables in the FRESCO scripting language port_comparator (1)(1) { type:comparator event:incoming_flow input:destination_port output:comparison_result parameter:80 /* no actions are defined */ action: - } do_action (1)(0) { type:actionhandler event:push input:comparison_result output: - /* no outputs are defined */ parameter: - /* no parameters are defined */ /* if input equals to 1, drop, otherwise, forward */ action:comparator_result == 1? DROP : FORWARD } Figure 3. FRESCO script with two connecting modules used to build the naive port comparator Figure 4. Operational illustration of running FRESCO script (case of the FRESCO script shown in Figure 3) do action instance from ActionHandler module) and dynamically loads them. The FRESCO DE runs each instance (5, 6), and when it receives an action from the do action module (i.e., drop) (7), it translates this action into flow rules, which can be understood by an OpenFlow switch. Finally, these flow rules are installed into the switch through the FRESCO SEK (8). 5 FRESCO Security Enforcement Kernel Security applications developed in FRESCO scripts can enforce diverse security policies, such as DROP, REDI- RECT, QUARANTINE, to react to network threats by simply setting an action variable, as listed in Table 1. These high-level security policies can help developers focus on implementing security applications, and these policies will be automatically translated into flow rules for OpenFlow enabled switches by FRESCO DE (e.g., the REDIRECT action will be translated into three flow rules). Thus, developers do not need to care about network-level flow rules. However, when FRESCO DE enforces translated flow rules to switches, it will face a new challenge, which stems from the fact that OpenFlow provides no inherent mechanisms to reconcile rule conflicts as competing OpenFlow applications assert new rules into a switch. For example, a set of rules designed to quarantine an internal computing server (i.e., the QUARANTINE action in a FRESCO script) might subsequently be overridden by a load-balancing application that may determine that the quarantined host is now the least-loaded server. One needs a mechanism to ensure that flow rules produced by a security application will take precedence over those produced from non-securityaware applications. OpenFlow also incorporates a packet alteration functions (i.e., the set action), specifiable within its flow rule format. This feature enables virtual tunnels between hosts, such that a virtual tunnel can be used to circumvent a flow rule that was inserted to prevent two hosts from establishing a connection. To address this issue, FRESCO incorporates a security enforcement kernel (SEK), which is integrated directly into the OpenFlow controller upon which FRESCO operates. A more complete discussion of FRESCO SEK is provided in a published workshop paper [31]. FRESCO SEK offers several important features upon which FRESCO relies to ensure that flow rules derived from security services are prioritized and enforced over competing flow rules produced by non-security-critical applications: Rule source identification: The SEK introduces a trust model that allows FRESCO applications to digitally 6

7 sign each candidate flow rule, thus enabling the SEK to determine if a candidate flow rule was produced by a FRESCO security module, by an OpenFlow application, or by a network administrator. Rule conflict detection: To detect conflicts between a candidate rule set and the set of rules currently active in the switch, the SEK incorporates an inline rule conflict analysis algorithm called alias set rule reduction, which detects flow rule conflicts, including those that arise through set actions that are used to produce virtual tunnels. Since this is not the main focus of this paper, we include a relatively more detailed description of our rule conflict detection algorithm in Appendix A.1 for interested readers. Conflict resolution: When a conflict arises, the SEK applies a hierarchical authority model that enables a candidate rule to override (replace) an existing flow rule when the digital signature of the rule source is deemed to possess more authority than the source whose rule is in conflict. 6 Working Examples We show two case studies by creating real working security applications written in FRESCO script. 6.1 Implementing Reflector Net FRESCO s power stems from its ability to use OpenFlow to effectively reprogram the underlying network infrastructure to defend the network against an emerging threat. To illustrate this notion, consider a FRESCO application that allows OF network operators to redirect malicious scanners to a third-party remote honeypot. Using FRESCO script, we compose two modules that first detect an active malicious scanner, and then reprogram the switch data plane to redirect all the scanner s flow into a remote honeynet. We refer to our composed security service as a threat reflector net, which effectively turns the address space of any OpenFlow network that deploys this service into a contact surface for a remote high-interaction honeypot. The incentive for an operator to use such a service is that the forensic evidence collected by the honeypot can be shared back for the purpose of refining the operator s local FRESCO-based firewall. First, we create and configure a simple thresholdbased scan detector instance. Since FRESCO already provides a ScanDetector module, we can instantiate an instance from this module for selecting malicious external targets. For this example, let us assume that our scan analysis is triggered by an external entity producing large numbers of failed TCP connections. Thus, we establish TCP CONNECTION FAIL, which is captured in FRESCO s native DB service, as an input trigger event for our scan detection, which outputs a scan detection event when a threshold number of failed connections is observed. Our FRESCO script instantiates the scan detection module using four key script variables: (i) input, (ii) output, (iii) parameter, and (iv) action. The input for this instance is a source IP address for a flow that causes TCP CONNECTION FAIL event. The parameter will determine a threshold value for a scan detection algorithm, and here, we set this value as 5 (i.e., if a source IP generates five failed TCP connections, we regard it as a scan attacker). The output is a source IP address and a scan detection result (noted as scan result), which are delivered to the second instance as input variables. The action variable is not defined here, as the logic required to formulate and insert flow rules to incorporate duplex redirection is modularized into a second flow redirection instance. The FRESCO script for our flow redirection instance is shown in Figure 5 (left). We configure a redirector instance to redirect flows from the malicious scanner to a honeynet (or forward benign flows). This function is an instance of FRESCO s Action- Handler module. This instance uses a PUSH event, which triggers the instance each time find scan is outputted from the scan detection instance Finally, we need to define an action to redirect flows produced by scan attackers. Thus, we set the action variable of this instance as scan result == 1? REDIRECT : FORWARD, which indicates that if the input variable of scan result equals 1 (denoting the scanner) this instance redirects all flows related to the source IP address. The FRESCO script for this instance is shown in Figure 5 (right). We test this script in an OpenFlow simulation environment with Mininet [25], which is commonly used to emulate OpenFlow networks, to show its real operation. In this test, we created three hosts (scanner, target host, and honeynet) and an OpenFlow enabled switch. All three hosts are connected to the switch and able to initiate flows to each another. As illustrated in Figure 6, the malicious scanner ( ) tries to scan the host ( ) using Nmap tool [28]. The scan packets are delivered through an OpenFlow switch (1), where the switch then forwards the flow statistics to a FRESCO application (i.e., find scan instance) through a controller. The find scan instance determines that these packets are scan-related, and it sends the detection result to the do redirect instance to instantiate flow rules to redirect these packets to our honeynet ( ) (2). At this time, the network configuration of the honeypot is different from the original scanned machine ( ), which opens network port 445 while the honeypot opens network port 444. Then, the honeypot returns packets to the scanner as if it is the original target (3). Finally, the scanner receives packet responses from the honeypot (4), unaware that all of its flows are now redirected to and from the honeynet. 6.2 Cooperating with a Legacy Security Application FRESCO provides an interface, which receives messages from legacy security applications, such as Snort [38] and BotHunter [12]. Usually, we use these network security ap- 7

8 find_scan (1)(2){ type:scandetector event:tcp_connection_fail input:source_ip output:source_ip, scan_result parameter:5 /* no actions are defined */ action: - } do_redirect (2)(0){ type:actionhandler event:push input:source_ip, scan_result output: - parameter: - /* if scan_result equals 1, redirect, otherwise, forward */ action: scan_result == 1? REDIRECT : FORWARD } Figure 5. FRESCO script with two connecting modules used to build a reflector net Figure 6. Operational illustration of a FRESCO reflector net application such as the intrusion detection message exchange format (IDMEF) [33]. If we use FRESCO type, it is notified in the event as a keyword of FRESCO, and it can be represented as MESSAGE LEGACY:FRESCO. If we use IDMEF, it can be shown as MESSAGE LEGACY:IDMEF. In the scenario, shown in Figure 7, an attacker sends a bot binary (1) to the host C, and BotHunter responds by producing an infection profile (2). Then, BotHunter reports this information (i.e., the Victim IP and forensic confidence score for the infection) to a security application written in FRESCO script (3). If the profile s forensic score achieves a threshold value, the application imposes a quarantine action on the victim IP. The quarantine module uses the FRESCO SEK to enforce a series of flow rules that implement the quarantine action SEK (4, 5). Finally, if an infected host (the host C) sends another malicious data to other hosts, such as host A or host B (6), it is automatically blocked by the switch. plications to monitor our networks, often using DPI-based techniques to identify malicious traffic content or by simply monitoring flow patterns. Using FRESCO, alerts produced from such network security monitors can be integrated into the flow rule production logic of OF-enabled networks. To do this, we employ FRESCO actions (e.g., drop and redirect) as responses against network attacks. One might consider reimplementing classic network security applications directly as OpenFlow applications. However, such efforts are both costly in engineering time and subject to limitations in the availability of data provided by the OF controller. Also, OpenFlow does not export full packet content over its APIs, so DPI-based security services must be implemented as external applications. To reduce the integration burden, FRESCO provides a function of receiving messages from third-party security applications, and we can simply design response strategies based on the messages through FRESCO script. A message from a third-party security application will be delivered to a module as a type of event - MES- SAGE LEGACY, and the format of a message is of two kinds: (i) FRESCO type and (ii) other standardized formats Figure 7. Operational illustration of a FRESCO actuator cooperating with BotHunter To implement this function, we simply reconfigure the do quarantine instance (or create another instance) used in the above example scenario for this case. This time, we instantiate the instance with four alternate variables: (i) event, (ii) input, (iii) parameter, and (iv) condition part of action. When BotHunter forwards its infection alarm using the FRESCO API, we set the event variable as MESSAGE LEGACY:FRESCO. The input variables passed to this module include the victim ip (reported as infected by BotHunter), and the infection confidence score, which represents the degree of forensic evi- 8

9 dence recorded within the infection profile. We also specify a parameter for the confidence threshold, and trigger the QUARANTINE action when the confidence score exceeds the confidence threshold. The FRESCO script for this instance is shown in Figure 8. do_quarantine (2)(0){ type:actionhandler event:message_legacy:fresco input:victim_ip,confidence_score output: - parameter:confidence_score /* redirect all flows from source IP */ action:confidence_score > confidence_threshold? QUARANTINE(victim_ip) } Figure 8. FRESCO script for invoking host quarantine for BotHunter 7 Implementation We have developed a prototype implementation of the FRESCO architecture. The FRESCO Application Layer prototype is implemented in Python and runs as an Open- Flow application on NOX. The prototype operates on NOX version using the OpenFlow protocol, and is implemented in approximately 3,000 lines of Python. FRESCO modules are implemented as independent Python objects, and inputs and parameters of a module are input variables to the Python object. The return values of a Python object are considered as output values of a module. A sample implementation of the FRESCO Comparator module, used in Figure 2 (right), is presented in Figure 9. All modules in FRESCO start with the function of module start, and this function has two arguments: (i) input dic, which is a dictionary data structure containing F-DB, event, and input values, and (ii) param list, which is a list structure storing user-defined parameter values. All variables starting with FR are FRESCO native variables. The developer fills in additional specialized logic at the bottom of the module (lines 13-18). The FRESCO SEK is implemented as a native C++ extension of the NOX source code in approximately 1160 lines of C++ code. We modified the send openflow command function, whose main operation is to send OpenFlow commands to network switches, to capture flow rules from all OpenFlow applications. FRESCO SEK intercepts flow rules in the function and stores them into the security constraints table if the rules are from FRESCO applications (i.e., flow rules produced through the FRESCO path are considered trusted flow rules and are preserved as active network security constraints). If a flow rule is from a non-fresco application, FRESCO SEK evaluates the rule to determine if a conflict exists within its security constraints table. The match algorithm is specifically optimized to perform the least-expensive com- 1 def module_start(input_dic, param_list): 2 # initialize FRESCO native inputs 3 FR_FDB = input_dic[ FR_FDB ] 4 FR_event = in_dic[ FR_event ] 5 FR_input = input_dic[ FR_input ] 6 7 # initialize FRESCO variables 8 FR_ret_dic = {} 9 FR_ret_dic[ output ] = [] 10 FR_ret_dic[ action ] = None # start - user defined logic 13 if param_list[0] == FR_input[0]: 14 output = 1 15 else: 16 output = FR_ret_dic[ output ].append(output) 19 # end - user defined logic return FR_ret_dic Figure 9. FRESCO Comparator module parisons first. If there are conflicts, an error message is returned to the OF application. Otherwise, the rule is forwarded to the network switches. We implement and evaluate the security constraint table using the in-memory database opportunistic best-fit comparison algorithm, which reports an ability to execute queries in near-constant lookup time. 8 System Evaluation We now evaluate the FRESCO framework with respect to its ease of use, flexibility, and security constraints preservation. To evaluate components in FRESCO, we employ mininet [25], which provides a rapid prototyping environment for the emulation of OpenFlow network switches. Using mininet, we have emulated one OpenFlow network switch, three hosts connected to the switch, and one host to operate our NOX controller. We perform flow generation by selecting one or two hosts to initiate TCP or UDP connections. The remaining host is employed as a medium interaction server, which responds to client application setup requests. We hosted our evaluation environment on an Intel i3 CPU with 4 GB of memory. In addition, we conduct live performance evaluations of the FRESCO SEK using an HP ProCurve 6600 OF-enabled switch in a test network laboratory. 8.1 Evaluating Modularity and Composability For the evaluation, we begin with the basic problem of identifying entities performing flow patterns indicative of malicious network scanning, and compare schemes of implementing network scanning attacks with and without the use of FRESCO. While network scanning is a well-studied problem in the network security realm, it offers an opportunity to examine the efficiency of entity tracking using FRESCO. Many well- 9

10 established algorithms for scan detection exist [16, 15, 35]. However, under OpenFlow, the potential for FRESCO to dynamically manipulate the switch s data path in reaction to malicious scans is a natural objective. This scenario also lets us examine how simple modules can be composed to perform data collection, evaluation, and response. 1. FRESCO Scan Deflector Service. Figure 10 illustrates how FRESCO modules and their connections can be linked together to implement a malicious scan deflector for Open- Flow environments. This scan detection function consists of the three modules described above. First, we have a module for looking up a blacklist. This module checks a blacklist table to learn whether or not an input source IP is listed. If the table contains the source IP, the module notifies its presence to the second module. Based on the input value, the second module performs threshold-based scan detection or it drops a packet. If it does not drop the packet, it notifies the detection result to the third module. In addition, this second module receives a parameter value that will be used to determine the threshold. Finally, the third module performs two actions based on input. If the input is 1, the module redirects a packet. If the input is 0, it forwards a packet. Implementing the three modules required 205 lines of Python code and 24 lines of FRESCO script (this script is shown in Figure 11). Figure 10. FRESCO composition of a Scan Deflector 2. FRESCO BotMiner Service. To illustrate a more complex flow analysis module using FRESCO, we have implemented a FRESCO version of the BotMiner [11] application. Note that our goal here is not faithful, bugcompatible adherence to the full BotMiner protocol described in [11], but rather to demonstrate feasibility and to capture the essence of its implementation through FRESCO, in a manner that is slightly simplified for readability. BotMiner detects bots through network-level flow analysis. We have implemented the essentials of its detection functionality using five modules as shown in Figure 12. BotMiner assumes that hosts infected with the same botnet exhibit similar patterns at the network level, and these patterns are different from benign hosts. To find similar patterns between bots, BotMiner clusters botnet activity in two dimensions (C-plane and A-plane). The C-plane clustering Figure 12. FRESCO composition of the Bot- Miner service approach is used to detect hosts that resemble each other in terms of (packets per second) and bps (bytes per second). The A-plane clustering identifies hosts that produce similar network anomalies. In this implementation, we use the scan detector module to find network anomalies. Finally, if we find two clusters, we perform co-clustering to find common hosts that exist in both dimensions and label them as bots. BotMiner was implemented in 312 lines of python code and 40 lines of FRESCO script (the script for BotMiner is presented in Figure 13). 3. FRESCO P2P Plotter Service. We have implemented a FRESCO-based P2P malware detection service, similarly implemented to capture the concept of the algorithm, but simplified for the purpose of readability. Motivated by Yen s work [43], we have implemented the P2P malware detection algorithm, referred to as P2P Plotter, using FRESCO. The P2P Plotter asserts that P2P malware has two interesting characteristics, which are quite different from normal P2P client programs. First, P2P malware usually operates at lower volumes of network flow interactions than what is typically observed in benign P2P protocols. Second, P2P malware typically interacts with a peer population that has a lower churn rate (i.e., the connection duration time of P2P plotters is longer than that of normal P2P clients). The algorithm operates by performing co-clustering, to find common hosts that exhibit both characteristics (i.e., low volume and low churn rate). We have implemented this essential functionality of the P2P Plotter algorithm as a 4-module FRESCO script, which is shown in Figure 14. This involved 227 lines of Python code and 32 lines of FRESCO script. The script for the P2P Plotter is illustrated in Figure 15. The reuse of modules (i.e., CrossCluster and ActionHandler, from the BotMiner service implementation is noteworthy, high- 10

11 1 blacklist_check (1)(1){ 2 type:tablelookup 3 event:tcp_connection_fail, TCP_CONNECTION_SUCCESS 4 input:source_ip 5 output:blacklist_out 7 action:- 1 find_scan (1)(1){ 2 type:scandetector 3 event:push 4 input:blacklist_out 5 output:scan_out 7 action:blacklist_out == 1?DROP 1 do_action (1)(0){ 2 type:actionhandler 3 event:push 4 input:scan_out 5 output:- 7 action:scan_out == 1?REDIRECT:FORWARD Figure 11. FRESCO script for Scan Detector 1 table_check (1)(2){ 2 type:tablelookup 3 event:tcp_connection_fail, TCP_CONNECTION_SUCCESS 4 input:source_ip 5 output:table_out,source_ip 7 action:- 1 a_cluster (2)(1){ 2 type:a-planecluster 3 event:push 4 input:table_out,source_ip 5 output:a_cls_out 7 action:- - 1 c_cluster (0)(1){ 2 type:c-planecluster 3 event:tcp_connection_fail, TCP_CONNECTION_SUCCESS 4 input:- 5 output:c_cls_out 7 action:- 1 cr_cluster (2)(2){ 2 type:crosscluster 3 event:push 4 input:a_cls_out,c_cls_out 5 output:cross_out,ip_list 7 action:- - 1 do_action (2)(0){ 2 type:actionhandler 3 event:push 4 input:cross_out,ip_list 5 output:- 7 action:cross_out == 1?DROP(ip_list):FORWARD Figure 13. FRESCO scripts illustrating composition of the BotMiner service Figure 14. FRESCO composition of the P2P Plotter lighting the reuse potential of FRESCO modules. 8.2 Comparing FRESCO Applications with Non- FRESCO Detectors Network anomaly detection approaches, e.g., TRW [16], have been well-studied and are commonly used as a complement to signature-based detection systems in traditional networks. While these approaches may be instantiated as software programs or in hardware devices, the common practice is to implement them as stand-alone software programs. (We envision that the FRESCO development environment may be similarly used for rapid prototyping and evaluation of certain anomaly detection algorithms in Open- Flow networks.) To highlight the advantages of FRESCO, we first choose an open-source network anomaly detection system and then replicate identical functionality using FRESCO. Specifically, we compare FRESCO with a recently published work [24], where the authors implemented popular network anomaly detection algorithms such as TRW-CB [34] and Rate Limit [39] as applications running on an OpenFlow network controller. We re-implement the same algorithms (i.e., TRW-CB and Rate Limit) using existing FRESCO modules and the FRESCO scripting language. We provide a comparison in Table 2, in terms of the number of lines of source code, to demonstrate the utility of the FRESCO development environment. As summarized in Table 2, prior work [24] makes the case that its OpenFlow application implementation is slightly simpler than the standard implementation (i.e., the source code for the OpenFlow implementation is roughly 70% to 80% the length of the standard implementation). Using FRESCO, we are able to realize similar functionality with an order of magnitude fewer lines of code. That is, we have implemented the identical TRW-CB function with 11

12 1 low_volume_peer (0)(1){ 2 type:volumedetector 3 event:incoming_flow 4 input:- 5 output:volume_out 7 action:- 1 low_churn_peer (0)(1){ 2 type:churndetector 3 event:incoming_flow 4 input:- 5 output:churn_out 7 action:- 1 cr_cluster (2)(2){ 2 type:crosscluster 3 event:push 4 input:volume_out,churn_out 5 output:cross_out,ip_list 7 action:- 1 do_action (2)(0){ 2 type:actionhandler 3 event:push 4 input:cross_out,ip_list 5 output:- 7 action:cross_out == 1? DROP(ip_list):FORWARD Figure 15. FRESCO scripts illustrating composition of the P2P Plotter 66 lines of code (58 lines of Python and 8 lines of FRESCO script) and the rate limiting function with 69 lines of code (61 lines of Python and 8 lines of FRESCO script). These two examples represent 6% to 7% of the length of their standard implementations, and less than 9% of the recently published OpenFlow implementation. Implementation Algorithms Standard OpenFlow application FRESCO TRW-CB 1, (58 + 8) Rate Limit (61 + 8) Table 2. Source code length for standard, OpenFlow and FRESCO implementations of the TRW-CB and Rate Limit anomaly detection algorithms component monitors switch status frequently and removes old flow rules to reclaim space for new flow rules, which will be enforced by FRESCO applications. This job is performed by FRESCO s garbage collector, a subcomponent of the resource controller, which we test under the following scenario. First, we let non-fresco applications enforce 4,000 flow rules to an OpenFlow network switch. In this case, we assume that the maximum size of the flow table in the switch is 4,000, and we set the threshold value(θ) for garbage collection as 0.75 (i.e., if the capacity of a flow table in a switch is 75%, we run the garbage collector). Our test results, shown in Figure 16, demonstrate that the garbage collector correctly implements its flow eviction policy. 8.3 Measuring and Evaluating FRESCO Overhead FRESCO Application Layer Overhead. We compare the flow setup time of NOX flow generation with five other FRESCO applications and summarize the results in Table 3. To measure this, we capture packets between NOX and the OpenFlow switch, and measure the round trip required to submit the flow and receive a corresponding flow constraint. We observe that FRESCO applications require additional setup time in the range of 0.5 milliseconds to 10.9 milliseconds. 2 Time (ms) NOX Simple Flow Tracker Simple Scan Detector Threshold Scan Detector BotMiner Detector P2P Plotter Table 3. Flow setup time comparison of NOX with five FRESCO applications Resource Controller Overhead. The resource controller 2 These setup times were measured on mininet, which is an emulated environment running on a virtual machine. If we use a more powerful host for the controller, which is the common case in an OpenFlow network, this setup time will be reduced significantly. Figure 16. Operation of FRESCO garbage collector 9 Related Work The OpenFlow standard has as its roots on a rich body of work on control-flow separation and clean-slate design of the Internet (e.g., [6], [10]). SANE [7] and Ethane [6] propose new architectures for securing enterprise networks. The SANE [7] protection layer proposes a fork-lift (cleanslate) approach for upgrading enterprise network security that introduces a centralized server, i.e., domain controller, to authenticate all elements in the network and grant access to services in the form of capabilities that are enforced at each switch. Ethane [6] is a more practical and backwards- 12

13 compatible instantiation of SANE that requires no modification to end hosts. Both studies may be considered as catalysts for the emergence of OpenFlow and software-defined networking. FRESCO is built over the foundations laid by these studies and shares a common objective with these systems in that it seeks to improve enterprise security using programmable network elements. However, FRESCO emphasizes composable security, and applications that it enables are much more sophisticated than simple access control policies. In addition, the FRESCO SEK focuses on providing continued enforcement of potentially conflicting flow constraints imposed by FRESCO and other OF applications. Thus, we consider our work as greatly complementary to existing studies such as SANE and Ethane. FRESCO s focus is on the development of a holistic platform for specifying and developing OF security applications and enforcement of security constraints generated by these applications. Prior work has addressed a part of this problem, i.e., development of new languages for specifying security policies. Nettle [40] is a new language for managing OF switches that is based on functional reactive programming. Frenetic [9] and Procera [41] provide declarative query language frameworks for managing distributed OF switches, describing high-level packet-forwarding and specifying network policies. The OpenSAFE system provides a language framework for enabling redirection of traffic to network monitoring devices [3]. In contrast to these languages, the FRESCO development environment is specialized to serve the needs of security applications. Specifically, FRESCO applications issue high-level security directives (e.g., REDIRECT, QUARANTINE, MIRROR), which are then translated into OF-specific commands by the script-tomodule translator. In addition, FRESCO applications require aggregate session and flow state information as well as directives for asynchronous delivery of switch state information that is unavailable in standard OF environments. Applications such as Random Host Mutation [14] are additional motivating examples of candidate OF security applications whose development may be accelerated using FRESCO. The FRESCO security enforcement kernel is informed by prior research focused on testing or verifying firewall and network device configuration [36, 8, 21, 22, 2, 42, 1], e.g., using Firewall Decision Diagrams (FDDs) [21] or test case generators [36, 8]. These studies do not deal with dynamic networks. More recently, header space analysis was proposed, which is a generic framework to express various network misconfigurations and policy violations [17]. While HSA can in theory deal with dynamic networks, the FRESCO SEK differs in that it is specialized to deal with specific policy violations by OF applications, rule conflict detection, and dynamic flow tunneling. Veriflow proposes to slice the OF network into equivalence classes to efficiently check for invariant property violations [18]. The alias set rule reduction algorithm used by FRESCO SEK is complementary to this approach. We build our system on NOX, which is an open-source OF controller [13]. However, our methodology could be extended to other architectures like Beacon [30], Maestro [4], and DevoFlow [26]. FlowVisor is a platform-independent OF controller that uses network slicing to separate logical network planes, allowing multiple researchers to run experiments safely and independently in the same production OpenFlow network [37]. Our work differs from FlowVisor in several ways. First, FlowVisor cares primarily about non-interference across different logical planes (slices) but does not instantiate network security constraints within a slice. It is possible that an OF application uses packet modification functions resulting in flow rules that are applied across multiple network switches within the same slice. In such cases, we need a security enforcement kernel to resolve conflicts as described in Section 5. Second, although FlowVisor improves security by separating the OF network into logical planes, it does not provide analogous capabilities to FRESCO for building additional security applications. The need for better policy validation and enforcement mechanisms has been touched on by prior and concurrent research efforts. NICE provides a model-checking framework that uses symbolic execution for automating the testing of OpenFlow applications [5]. The Resonance architecture enables dynamic access control and monitoring in SDN environments [27]. The FlowChecker system encodes OpenFlow flow tables into Binary Decision Diagrams (BDD) and uses model checking [1] to verify security properties. However, the evaluation of FlowChecker does not consider handling of set action commands, which we consider to be a significant distinguisher for OpenFlow networks. More recently, researchers have proposed developing language abstractions to guarantee consistency of flow updates in software-defined networks [32]. In contrast, our complementary work on the FRESCO security enforcement kernel is focused on detection of rule update conflicts and security policy violations. The Onix platform [20] provides a generalized API for managing a distributed control plane in Software Defined Networks. The techniques and the strategies developed in Onix for managing a distributed network information base are complementary and can be integrated into FRESCO. 10 Conclusion Despite the success of OpenFlow, developing and deploying complex OF security services remains a significant challenge. We present FRESCO, a new application development framework specifically designed to address this problem. We introduce the FRESCO architecture and its integration with the NOX OpenFlow controller, and present several illustrative security applications written in the FRESCO scripting language. To empower FRESCO applications with the ability to produce enforceable flow constraints that can defend the network as threats are detected, we present 13

14 the FRESCO security enforcement kernel. Our evaluations demonstrate that FRESCO introduces minimal overhead and that it enables rapid creation of popular security functions with significantly (over 90%) fewer lines of code. We believe that FRESCO offers a powerful new framework for prototyping and delivering innovative security applications into the rapidly evolving world of software-defined networks. We plan to release all developed code as open source software to the SDN community. 11 Acknowledements This material is based in part upon work supported by the Defense Advanced Research Projects Agency (DARPA) and the United States Air Force under Contract No. FA C-0249, the Army Research Office under Cyber-TA Grant no. W911NF , and the National Science Foundation under Grant no. CNS All opinions, findings and conclusions or recommendations expressed herein are those of the author(s) and do not necessarily reflect the views of the U.S. Air Force, DARPA, U.S. Army Research Office, or the National Science Foundation. It is approved for Public Release, Distribution Unlimited. References [1] E. Al-Shaer and S. Al-Haj. FlowChecker: Configuration Analysis and Verification of Federated Openflow Infrastructures. In Proceedings of the 3rd ACM Workshop on Assurable and Usable Security Configuration, SafeConfig, pages 37 44, New York, NY, USA, ACM. [2] E. Al-shaer, W. Marrero, A. El-atawy, and K. Elbadawi. Network Configuration in A Box: Towards End-to-End Verification of Network Reachability and Security. In The 17th IEEE International Conference on Network Protocols (ICNP), [3] J. R. Ballard, I. Rae, and A. Akella. Extensible and Scalable Network Monitoring Using OpenSAFE. In INM/WREN, [4] Z. Cai, A. L. Cox, and T. E. Ng. Maestro: A System for Scalable OpenFlow Control. In Rice University Technical Report, [5] M. Canini, D. Venzano, P. Peresini, D. Kostic, and J. Rexford. A NICE Way to Test OpenFlow Applications. In Proceedings of NSDI, [6] M. Casado, M. J. Freedman, J. Pettit, J. Luo, N. McKeown, and S. Shenker. Ethane: Taking Control of the Enterprise. In Proceedings of ACM SIGCOMM, [7] M. Casado, T. Garfinkel, M. Freedman, A. Akella, D. Boneh, N. McKeowon, and S. Shenker. SANE: A Protection Architecture for Enterprise Networks. In Proceedings Usenix Security Symposium, August [8] A. El-atawy, T. Samak, Z. Wali, E. Al-shaer, F. Lin, C. Pham, and S. Li. An Automated Framework for Validating Firewall Policy Enforcement. Technical report, De-Paul University, [9] N. Foster, R. Harrison, M. Freedman, C. Monsanto, J. Rexford, A. Story, and D. Walker. Frenetic: A Network Programming Language. In ACM SIGPLAN Inernational Conference on Functional Programming, [10] A. Greenberg, G. Hjalmtysson, D. A. Maltz, A. Myers, J. Rexford, G. Xie, H. Yan, J. Zhan, and H. Zhang. A Clean Slate 4D Approach to Network Control and Management. In Proceedings of ACM Computer Communications Review, [11] G. Gu, R. Perdisci, J. Zhang, and W. Lee. BotMiner: Clustering Analysis of Network Traffic for Protocol- and Structure- Independent Botnet Detection. In Proceedings of USENIX Security Symposium (Security 08), [12] G. Gu, P. Porras, V. Yegneswaran, M. Fong, and W. Lee. BotHunter: Detecting malware infection through ids-driven dialog correlation. In Proceedings of the 16th USENIX Security Symposium (Security 07), August [13] N. Gude, T. Koponen, J. Pettit, B. Pfaff, M. Casado, N. McKeown, and S. Shenker. NOX: Towards an Operating System for Networks. In Proceedings of ACM SIGCOMM Computer Communication Review, July [14] J. H. Jafarian, E. Al-Shaer, and Q. Duan. OpenFlow Random Host Mutation: Transparent Moving Target Defense using Software-Defined Networking. In Proceedings of ACM Sigcomm HotSDN Workshop, [15] J. Jung, R. Milito, and V. Paxson. On the Adaptive Real-time Detection of Fast Propagating Network Worms. In Proceedings of Conference on Detection of Intrusions and Malware and Vulnerability Assessment (DIMVA), [16] J. Jung, V. Paxson, A. Berger, and H. Balakrishnan. Fast Portscan Detection Using Sequential Hypothesis Testing. In Proceedings of IEEE Symposium on Security and Privacy, [17] P. Kazemian, G. Varghese, and N. McKeown. Header Space Analysis: Static Checking for Networks. In Proceedings of NSDI, [18] A. Khurshid, W. Zhou, M. Caesar, and P. B. Godfrey. Veri- Flow: Verifying Network-Wide Invariants in Real Time. In Proceedings of ACM Sigcomm HotSDN Workshop, [19] E. Kohler, R. Morris, B. Chen, J. Jannotti, and F. Kaashoek. The Click Modular Router. ACM Transactions on Computer Systems, August [20] T. Koponen, M. Casado, N. Gude, J. Stribling, L. Poutievski, M. Zhu, R. Ramanathan, Y. Iwata, H. Inoue, T. Hama, and S. Shenker. Onix: A Distributed Control Platform for Largescale Production Networks. In The Symposium on Operating Systems Design and Implementation (NSDI), [21] A. Liu. Formal Verification of Firewall Policies. In Proceedings of the 2008 IEEE International Conference on Communications (ICC), Beijing,China, May [22] A. Liu and M. Gouda. Diverse Firewall Design. IEEE Transactions on Parallel and Distributed Systems (TPDS), 19(8), [23] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner. Open- Flow: Enabling Innovation in Campus Networks. In Proceedings of ACM SIGCOMM Computer Communication Review, April [24] S. A. Mehdi, J. Khalid, and S. A. Khayam. Revisiting Traffic Anomaly Detection Using Software Defined Networking. In Proceedings of Recent Advances in Intrusion Detection, [25] Mininet. Rapid Prototyping for Software Defined Networks. bin/view/openflow/mininet/. [26] J. C. Mogul, J. Tourrilhes, P. Yalagandula, P. Sharma, A. R. 14

15 Curtis, and S. Banerjee. DevoFlow: Cost-effective Flow Management for High Performance Enterprise Networks. In Proceedings of the Ninth ACM SIGCOMM Workshop on Hot Topics in Networks, [27] A. Nayak, A. Reimers, N. Feamster, and R. Clark. Resonance: Dynamic Access Control for Enterprise Networks. In Proceedings of WREN, [28] NMAP.ORG. Nmap: Open Source Network Discovery and Auditing Tool. [29] OpenFlow. OpenFlow Specification. openflow.org/documents/openflow-spec-v pdf. [30] OpenFlowHub. BEACON. openflowhub.org/display/beacon. [31] P. Porras, S. Shin, V. Yegneswaran, M. Fong, M. Tyson, and G. Gu. A Security Enforcement Kernel for OpenFlow Networks. In Proceedings ACM SIGCOMM Workshops on Hot Topics in Software Defined Networking (HotSDN), August [32] M. Reitblatt, N. Foster, J. Rexford, and D. Walker. Consistent Update for Software-Defined Networks: Change You Can Believe In! In Under Submission, [33] RFC4765. The intrusion detection message exchange format (idmef). txt. [34] S. Schechter, J. Jung, and A. Berger. Accuracy Improving Guidelines for Network Anomaly Detection Systems. In Proceedings of International Symposium on Recent Advances Intrusion Detection. [35] V. Sekar, Y. Xie, M. Reiter, and H. Zhang. A Multi- Resolution Approach for Worm Detection and Containment. In Proceedings of International Conference on Dependable Systems and Networks (DSN), June [36] D. Senn, D. Basin, and G. Caronni. Firewall Conformance Testing. In The 17th IFIP International Conference on Testing of Communicating Systems (TestCom), pages , [37] R. Sherwood, G. Gibb, K.-K. Yap, G. Appenzeller, M. Casado, N. McKeown, and G. Parulkar. Can the Production Network Be the Testbed. In Proceedings of Operating System Design and Implementation, [38] Snort. [39] J. Twycross and M. M. Williamson. Implementing and testing a virus throttle. In Proceedings of the USENIX Security Symposium, [40] A. Voellmy and P. Hudak. Nettle: Functional Reactive Programming of OpenFlow Networks. In Yale University Technical Report, [41] A. Voellmy, J. Kim, and N. Feamster. Procera: A Language for High-Level Reactive Network Control. In Proceedings of ACM Sigcomm HotSDN Workshop, [42] G. Xie, J. Zhan, D. Maltz, H. Zhang, A. Greenberg, G. Hjalmtysson, and J. Rexford. On Static Reachability Analysis of IP Networks. In The 24th IEEE International Conference on Computer Communications (INFO- COM), pages , [43] T.-F. Yen and M. K. Reiter. Are Your Hosts Trading or Plotting? Telling P2P File-sharing and Bots Apart. In Proceedings of IEEE ICDCS, A Appendix A.1 FRESCO Security Enforcement Kernel It is possible that the flow rules created by non-securityrelated OF applications conflict with the flow constraints distributed by FRESCO applications. A conflict arises when one or more flow rules would allow a flow from one end point to another that is specifically prohibited by a flow constraint rule produced by a FRESCO application. To manage FRESCO flow constraints and perform conflict evaluation, we introduce the FRESCO SEK as an embedded NOX extension. Two main components of OpenFlow rules are match conditions and actions. The former specifies packet header fields that must match for the rule s associated actions to trigger. The FRESCO SEK maintains the set of active constraint rules produced by registered FRESCO modules. Constraint rules inserted into the FRESCO SEK security constraints table are considered active, and must be explicitly deactivated by a registered FRESCO module. Because non-fresco applications can publish flow rules that potentially violate FRESCO s network security policy, The FRESCO SEK employs two protection mechanisms to prevent such violations. The first mechanism is rule prioritization, in which flow rules produced by FRESCO applications are published to the switch using the highest rule priority. This immediately overrides any active flow rules in the switch s flow table that may contradict FRESCO s security policy. Second, the FRESCO SEK applies a conflict detection algorithm between each new flow rule and the security constraints table, rejecting the new flow rule if a conflict is detected. Conflict detection is performed in two passes: alias set rule reduction, and then rule set conflict evaluation. A conflict can also happen between security constraints enforced by different FRESCO applications. In this case, the FRESCO SEK can still detect conflicts but it needs to determine which constraint should be enforced. By default, FRESCO SEK keeps the first enforced constraint (i.e., ignore following conflicted constraint), but it is easy to be configured by the administrators to apply other approaches (e.g., keep the last enforced constraint, or based on some priority settings). A.1.1 Alias Set Rule Reduction To detect conflicts between a candidate rule set and FRESCO s constraint rule sets, the source and destination IP addresses, their ports, and wild card members 3 for each rule in a rule set are used to derive rules with alias sets representing IP addresses and ports. The initial alias sets contain the first rule s IP addresses, network masks, and ports (where 0 [zero] represents any port). If the rule s action causes a field substitution via a set action, the resultant value is added to the appropriate alias set. These sets are 3 For OpenFlow 1.1, the examined members include the source and destination network mask fields (for OpenFlow 1.0 these are implicitly defined by the wildcard field). 15

16 then compared to the next rule s alias sets. If there is an intersection between both the source and address sets, the union of the respective sets is used as the subsequent rule s alias sets. For example, given the FRESCO rule, a b drop packet (1) its source alias set is (a), while its destination alias set is (b). The derived rule is (a) (b) drop packet (2) For the candidate (evasion) rule set, 1 a c set (a a ) 2 a c set (c b) 3 a b forward packet the intermediate alias sets are (3) 1 a c set (a a ) (a, a ) (c) 2 a c set (c b) (a, a ) (c, b) 3 a b forward packet (a, a ) (c, b) forward packet (4) and the derived rule is A.1.2 (a, a ) (c, b) forward packet (5) Rule Set Conflict Evaluation The FRESCO SEK first performs alias set rule reduction on the candidate rule set. These validity checks are then performed between each derived FRESCO constraint rule crule and each derived flow rule frule, as follows: For a formalization of the above, we first define some terms: (i) S i is the i th entry of security constraints, (ii) F i is the i th entry of flow rules, (iii) SC i,j is the j th item of the i th entry of the condition part of the security constraint, (iv) SA i is the i th entry of the action part of the security constraint, (v) F C i,j is the j th item of the i th condition part of a flow rule from non-fresco applications, and (vi) F A i is the i th action part of the flow rule. At this time, both SC i,j and F C i,j are sets whose elements are one of the specific value or some ranges and j {1, 2,..., 14}. Rule contradiction is then formalized using the following notation: if there is any S i, satisfying SC i,j F C i,j and SA i F A i, for all j, thenf i is conflicted with S i (6) Finally, upon an update to the security constraints table, rule set conflict resolution is performed against all flow rules currently active within the switch. If a conflict is detected in which the switch rule is found to be wider than the FRESCO rule, SEK initiates a request to the switch to flush the resident rule. 1. Skip any crule/frule pair with mismatched prototypes. 2. Skip any crule/frule pair whose actions are both either forward or drop packet. 3. If crule s alias sets intersect those of frule s, declare a conflict. Thus, given the example security constraint table in Equation 2 and the candidate rule set in Equation 5, assuming that both rules are TCP protocol, the first candidate rule passes the first two checks. However, for the third check, because the intersection of the source and destination alias sets results in (a) and (b), respectively, the candidate rule is declared to be in conflict. As a practical consideration, because OpenFlow rules permit both wildcard field matches and IP address network masks, determining alias set intersection involves more than simple membership equality checks. To accommodate this, we define comparison operators that determine if a field specification is (i) more encompassing ( wider ), (ii) more specific ( narrower ), (iii) equal, or (iv) unequal. Thus, an intersection occurs when the pairwise comparisons between all fields of a candidate rule are wider than, equal to, or narrower than that of the corresponding fields of the constraint table rule. 16

FRESCO: Modular Composable Security Services for Software-Defined Networks

FRESCO: Modular Composable Security Services for Software-Defined Networks FRESCO: Modular Composable Security Services for Software-Defined Networks Seugwon Shin 1, Phillip Porras 2, Vinod Yegneswaran 2, Martin Fong 2, Guofei Gu 1, Mabry Tyson 2 (1) Texas A&M University (2)

More information

FRESCO: Modular Composable Security Services for So;ware- Defined Networks

FRESCO: Modular Composable Security Services for So;ware- Defined Networks FRESCO: Modular Composable Security Services for So;ware- Defined Networks Seungwon Shin, Phil Porras, Vinod Yegneswaran, MarIn Fong, Guofei Gu, and Mabry Tyson SUCCESS LAB, Texas A&M and SRI Interna7onal

More information

Stephan Neuhaus, HS 2013 Institut für Technische Informatik und Kommunikationsnetze (TIK), ETH Zürich

Stephan Neuhaus, HS 2013 Institut für Technische Informatik und Kommunikationsnetze (TIK), ETH Zürich ETH Zurich - Startpage SDN Security Stephan Neuhaus, HS 2013 Institut für Technische Informatik und Kommunikationsnetze (TIK), ETH Zürich October 21, 2013 Prof. B. Plattner ETH Zürich Institute TIK Communication

More information

A Fuzzy Logic-Based Information Security Management for Software-Defined Networks

A Fuzzy Logic-Based Information Security Management for Software-Defined Networks A Fuzzy Logic-Based Information Security Management for Software-Defined Networks Sergei Dotcenko *, Andrei Vladyko *, Ivan Letenko * * The Bonch-Bruevich Saint-Petersburg State University of Telecommunications,

More information

How OpenFlow-based SDN can increase network security

How OpenFlow-based SDN can increase network security How OpenFlow-based SDN can increase network security Charles Ferland, IBM System Networking Representing the ONF ferland@de.ibm.com +49 151 1265 0830 Important elements The objective is to build SDN networks

More information

Security as an App and Security as a Service: New Killer Applica6ons for So9ware Defined Networking? Guofei Gu SUCCESS Lab, Texas A&M

Security as an App and Security as a Service: New Killer Applica6ons for So9ware Defined Networking? Guofei Gu SUCCESS Lab, Texas A&M Security as an App and Security as a Service: New Killer Applica6ons for So9ware Defined Networking? Guofei Gu SUCCESS Lab, Texas A&M Credits Seungwon Shin (TAMU) Phil Porras, Vinod Yegneswaran (SRI Interna?onal)

More information

International Journal of Enterprise Computing and Business Systems ISSN (Online) : 2230-8849

International Journal of Enterprise Computing and Business Systems ISSN (Online) : 2230-8849 WINDOWS-BASED APPLICATION AWARE NETWORK INTERCEPTOR Ms. Shalvi Dave [1], Mr. Jimit Mahadevia [2], Prof. Bhushan Trivedi [3] [1] Asst.Prof., MCA Department, IITE, Ahmedabad, INDIA [2] Chief Architect, Elitecore

More information

Implementation of Botcatch for Identifying Bot Infected Hosts

Implementation of Botcatch for Identifying Bot Infected Hosts Implementation of Botcatch for Identifying Bot Infected Hosts GRADUATE PROJECT REPORT Submitted to the Faculty of The School of Engineering & Computing Sciences Texas A&M University-Corpus Christi Corpus

More information

AlienVault. Unified Security Management (USM) 5.x Policy Management Fundamentals

AlienVault. Unified Security Management (USM) 5.x Policy Management Fundamentals AlienVault Unified Security Management (USM) 5.x Policy Management Fundamentals USM 5.x Policy Management Fundamentals Copyright 2015 AlienVault, Inc. All rights reserved. The AlienVault Logo, AlienVault,

More information

The Lagopus SDN Software Switch. 3.1 SDN and OpenFlow. 3. Cloud Computing Technology

The Lagopus SDN Software Switch. 3.1 SDN and OpenFlow. 3. Cloud Computing Technology 3. The Lagopus SDN Software Switch Here we explain the capabilities of the new Lagopus software switch in detail, starting with the basics of SDN and OpenFlow. 3.1 SDN and OpenFlow Those engaged in network-related

More information

Securing Local Area Network with OpenFlow

Securing Local Area Network with OpenFlow Securing Local Area Network with OpenFlow Master s Thesis Presentation Fahad B. H. Chowdhury Supervisor: Professor Jukka Manner Advisor: Timo Kiravuo Department of Communications and Networking Aalto University

More information

Symantec Endpoint Protection 11.0 Network Threat Protection (Firewall) Overview and Best Practices White Paper

Symantec Endpoint Protection 11.0 Network Threat Protection (Firewall) Overview and Best Practices White Paper Symantec Endpoint Protection 11.0 Network Threat Protection (Firewall) Overview and Best Practices White Paper Details: Introduction When computers in a private network connect to the Internet, they physically

More information

OpenFlow Based Load Balancing

OpenFlow Based Load Balancing OpenFlow Based Load Balancing Hardeep Uppal and Dane Brandon University of Washington CSE561: Networking Project Report Abstract: In today s high-traffic internet, it is often desirable to have multiple

More information

Chapter 9 Firewalls and Intrusion Prevention Systems

Chapter 9 Firewalls and Intrusion Prevention Systems Chapter 9 Firewalls and Intrusion Prevention Systems connectivity is essential However it creates a threat Effective means of protecting LANs Inserted between the premises network and the to establish

More information

Complete Protection against Evolving DDoS Threats

Complete Protection against Evolving DDoS Threats Complete Protection against Evolving DDoS Threats AhnLab, Inc. Table of Contents Introduction... 2 The Evolution of DDoS Attacks... 2 Typical Protection against DDoS Attacks... 3 Firewalls... 3 Intrusion

More information

A Look at the New Converged Data Center

A Look at the New Converged Data Center Organizations around the world are choosing to move from traditional physical data centers to virtual infrastructure, affecting every layer in the data center stack. This change will not only yield a scalable

More information

Security Challenges & Opportunities in Software Defined Networks (SDN)

Security Challenges & Opportunities in Software Defined Networks (SDN) Security Challenges & Opportunities in Software Defined Networks (SDN) June 30 th, 2015 SEC2 2015 Premier atelier sur la sécurité dans les Clouds Nizar KHEIR Cyber Security Researcher Orange Labs Products

More information

Introduction of Intrusion Detection Systems

Introduction of Intrusion Detection Systems Introduction of Intrusion Detection Systems Why IDS? Inspects all inbound and outbound network activity and identifies a network or system attack from someone attempting to compromise a system. Detection:

More information

White Paper. Time for Integrated vs. Bolted-on IT Security. Cyphort Platform Architecture: Modular, Open and Flexible

White Paper. Time for Integrated vs. Bolted-on IT Security. Cyphort Platform Architecture: Modular, Open and Flexible White Paper Time for Integrated vs. Bolted-on IT Security Cyphort Platform Architecture: Modular, Open and Flexible Overview This paper discusses prevalent market approaches to designing and architecting

More information

CS 356 Lecture 17 and 18 Intrusion Detection. Spring 2013

CS 356 Lecture 17 and 18 Intrusion Detection. Spring 2013 CS 356 Lecture 17 and 18 Intrusion Detection Spring 2013 Review Chapter 1: Basic Concepts and Terminology Chapter 2: Basic Cryptographic Tools Chapter 3 User Authentication Chapter 4 Access Control Lists

More information

Cisco IPS Tuning Overview

Cisco IPS Tuning Overview Cisco IPS Tuning Overview Overview Increasingly sophisticated attacks on business networks can impede business productivity, obstruct access to applications and resources, and significantly disrupt communications.

More information

Second-generation (GenII) honeypots

Second-generation (GenII) honeypots Second-generation (GenII) honeypots Bojan Zdrnja CompSci 725, University of Auckland, Oct 2004. b.zdrnja@auckland.ac.nz Abstract Honeypots are security resources which trap malicious activities, so they

More information

Data Analysis Load Balancer

Data Analysis Load Balancer Data Analysis Load Balancer Design Document: Version: 1.0 Last saved by Chris Small April 12, 2010 Abstract: The project is to design a mechanism to load balance network traffic over multiple different

More information

Breach Found. Did It Hurt?

Breach Found. Did It Hurt? ANALYST BRIEF Breach Found. Did It Hurt? INCIDENT RESPONSE PART 2: A PROCESS FOR ASSESSING LOSS Authors Christopher Morales, Jason Pappalexis Overview Malware infections impact every organization. Many

More information

Banking Security using Honeypot

Banking Security using Honeypot Banking Security using Honeypot Sandeep Chaware D.J.Sanghvi College of Engineering, Mumbai smchaware@gmail.com Abstract New threats are constantly emerging to the security of organization s information

More information

Semantic based Web Application Firewall (SWAF V 1.6) Operations and User Manual. Document Version 1.0

Semantic based Web Application Firewall (SWAF V 1.6) Operations and User Manual. Document Version 1.0 Semantic based Web Application Firewall (SWAF V 1.6) Operations and User Manual Document Version 1.0 Table of Contents 1 SWAF... 4 1.1 SWAF Features... 4 2 Operations and User Manual... 7 2.1 SWAF Administrator

More information

Architecture Overview

Architecture Overview Architecture Overview Design Fundamentals The networks discussed in this paper have some common design fundamentals, including segmentation into modules, which enables network traffic to be isolated and

More information

PLUMgrid Toolbox: Tools to Install, Operate and Monitor Your Virtual Network Infrastructure

PLUMgrid Toolbox: Tools to Install, Operate and Monitor Your Virtual Network Infrastructure Toolbox: Tools to Install, Operate and Monitor Your Virtual Network Infrastructure Introduction The concept of Virtual Networking Infrastructure (VNI) is disrupting the networking space and is enabling

More information

SHIN, WANG AND GU: A FIRST STEP TOWARDS NETWORK SECURITY VIRTUALIZATION: FROM CONCEPT TO PROTOTYPE 1

SHIN, WANG AND GU: A FIRST STEP TOWARDS NETWORK SECURITY VIRTUALIZATION: FROM CONCEPT TO PROTOTYPE 1 SHIN, WANG AND GU: A FIRST STEP TOWARDS NETWORK SECURITY VIRTUALIZATION: FROM CONCEPT TO PROTOTYPE 1 A First Step Towards Network Security Virtualization: From Concept To Prototype Seungwon Shin, Haopei

More information

LPM: Layered Policy Management for Software-Defined Networks

LPM: Layered Policy Management for Software-Defined Networks LPM: Layered Policy Management for Software-Defined Networks Wonkyu Han 1, Hongxin Hu 2 and Gail-Joon Ahn 1 1 Arizona State University, Tempe, AZ 85287, USA {whan7,gahn}@asu.edu 2 Clemson University, Clemson,

More information

From Network Security To Content Filtering

From Network Security To Content Filtering Computer Fraud & Security, May 2007 page 1/10 From Network Security To Content Filtering Network security has evolved dramatically in the last few years not only for what concerns the tools at our disposals

More information

BlackBerry Enterprise Service 10. Secure Work Space for ios and Android Version: 10.1.1. Security Note

BlackBerry Enterprise Service 10. Secure Work Space for ios and Android Version: 10.1.1. Security Note BlackBerry Enterprise Service 10 Secure Work Space for ios and Android Version: 10.1.1 Security Note Published: 2013-06-21 SWD-20130621110651069 Contents 1 About this guide...4 2 What is BlackBerry Enterprise

More information

BotHunter: Detecting Malware Infection Through IDS-Driven Dialog Correlation

BotHunter: Detecting Malware Infection Through IDS-Driven Dialog Correlation BotHunter: Detecting Malware Infection Through IDS-Driven Dialog Correlation Guofei Gu, Phillip Porras, Vinod Yegneswaran, Martin Fong, Wenke Lee USENIX Security Symposium (Security 07) Presented by Nawanol

More information

DoS: Attack and Defense

DoS: Attack and Defense DoS: Attack and Defense Vincent Tai Sayantan Sengupta COEN 233 Term Project Prof. M. Wang 1 Table of Contents 1. Introduction 4 1.1. Objective 1.2. Problem 1.3. Relation to the class 1.4. Other approaches

More information

Trusting SDN. Brett Sovereign Trusted Systems Research National Security Agency 28 October, 2015

Trusting SDN. Brett Sovereign Trusted Systems Research National Security Agency 28 October, 2015 Trusting SDN Brett Sovereign Trusted Systems Research National Security Agency 28 October, 2015 Who I am 18 years experience in Cryptography, Computer and Network Security Currently work at Trust Mechanisms,

More information

Ethernet-based Software Defined Network (SDN) Cloud Computing Research Center for Mobile Applications (CCMA), ITRI 雲 端 運 算 行 動 應 用 研 究 中 心

Ethernet-based Software Defined Network (SDN) Cloud Computing Research Center for Mobile Applications (CCMA), ITRI 雲 端 運 算 行 動 應 用 研 究 中 心 Ethernet-based Software Defined Network (SDN) Cloud Computing Research Center for Mobile Applications (CCMA), ITRI 雲 端 運 算 行 動 應 用 研 究 中 心 1 SDN Introduction Decoupling of control plane from data plane

More information

SOFTWARE DEFINED NETWORKS REALITY CHECK. DENOG5, Darmstadt, 14/11/2013 Carsten Michel

SOFTWARE DEFINED NETWORKS REALITY CHECK. DENOG5, Darmstadt, 14/11/2013 Carsten Michel SOFTWARE DEFINED NETWORKS REALITY CHECK DENOG5, Darmstadt, 14/11/2013 Carsten Michel Software Defined Networks (SDN)! Why Software Defined Networking? There s a hype in the industry!! Dispelling some myths

More information

Taxonomy of Intrusion Detection System

Taxonomy of Intrusion Detection System Taxonomy of Intrusion Detection System Monika Sharma, Sumit Sharma Abstract During the past years, security of computer networks has become main stream in most of everyone's lives. Nowadays as the use

More information

Secure Networks for Process Control

Secure Networks for Process Control Secure Networks for Process Control Leveraging a Simple Yet Effective Policy Framework to Secure the Modern Process Control Network An Enterasys Networks White Paper There is nothing more important than

More information

ADVANCED SECURITY MECHANISMS TO PROTECT ASSETS AND NETWORKS: SOFTWARE-DEFINED SECURITY

ADVANCED SECURITY MECHANISMS TO PROTECT ASSETS AND NETWORKS: SOFTWARE-DEFINED SECURITY ADVANCED SECURITY MECHANISMS TO PROTECT ASSETS AND NETWORKS: SOFTWARE-DEFINED SECURITY One of the largest concerns of organisations is how to implement and introduce advanced security mechanisms to protect

More information

Firewalls and VPNs. Principles of Information Security, 5th Edition 1

Firewalls and VPNs. Principles of Information Security, 5th Edition 1 Firewalls and VPNs Principles of Information Security, 5th Edition 1 Learning Objectives Upon completion of this material, you should be able to: Understand firewall technology and the various approaches

More information

ON THE IMPLEMENTATION OF ADAPTIVE FLOW MEASUREMENT IN THE SDN-ENABLED NETWORK: A PROTOTYPE

ON THE IMPLEMENTATION OF ADAPTIVE FLOW MEASUREMENT IN THE SDN-ENABLED NETWORK: A PROTOTYPE ON THE IMPLEMENTATION OF ADAPTIVE FLOW MEASUREMENT IN THE SDN-ENABLED NETWORK: A PROTOTYPE PANG-WEI TSAI, CHUN-YU HSU, MON-YEN LUO AND CHU-SING YANG NATIONAL CHENG KUNG UNIVERSITY, INSTITUTE OF COMPUTER

More information

Security+ Guide to Network Security Fundamentals, Fourth Edition. Chapter 6 Network Security

Security+ Guide to Network Security Fundamentals, Fourth Edition. Chapter 6 Network Security Security+ Guide to Network Security Fundamentals, Fourth Edition Chapter 6 Network Security Objectives List the different types of network security devices and explain how they can be used Define network

More information

Analyzing HTTP/HTTPS Traffic Logs

Analyzing HTTP/HTTPS Traffic Logs Advanced Threat Protection Automatic Traffic Log Analysis APTs, advanced malware and zero-day attacks are designed to evade conventional perimeter security defenses. Today, there is wide agreement that

More information

White paper. TrusGuard DPX: Complete Protection against Evolving DDoS Threats. AhnLab, Inc.

White paper. TrusGuard DPX: Complete Protection against Evolving DDoS Threats. AhnLab, Inc. TrusGuard DPX: Complete Protection against Evolving DDoS Threats AhnLab, Inc. Table of Contents Introduction... 2 The Evolution of DDoS Attacks... 2 Typical Protection against DDoS Attacks... 3 Firewalls...

More information

Fail-Safe IPS Integration with Bypass Technology

Fail-Safe IPS Integration with Bypass Technology Summary Threats that require the installation, redeployment or upgrade of in-line IPS appliances often affect uptime on business critical links. Organizations are demanding solutions that prevent disruptive

More information

Concierge SIEM Reporting Overview

Concierge SIEM Reporting Overview Concierge SIEM Reporting Overview Table of Contents Introduction... 2 Inventory View... 3 Internal Traffic View (IP Flow Data)... 4 External Traffic View (HTTP, SSL and DNS)... 5 Risk View (IPS Alerts

More information

Network- vs. Host-based Intrusion Detection

Network- vs. Host-based Intrusion Detection Network- vs. Host-based Intrusion Detection A Guide to Intrusion Detection Technology 6600 Peachtree-Dunwoody Road 300 Embassy Row Atlanta, GA 30348 Tel: 678.443.6000 Toll-free: 800.776.2362 Fax: 678.443.6477

More information

Flow-based detection of RDP brute-force attacks

Flow-based detection of RDP brute-force attacks Flow-based detection of RDP brute-force attacks Martin Vizváry vizvary@ics.muni.cz Institute of Computer Science Masaryk University Brno, Czech Republic Jan Vykopal vykopal@ics.muni.cz Institute of Computer

More information

A Coordinated. Enterprise Networks Software Defined. and Application Fluent Programmable Networks

A Coordinated. Enterprise Networks Software Defined. and Application Fluent Programmable Networks A Coordinated Virtual Infrastructure for SDN in Enterprise Networks Software Defined Networking (SDN), OpenFlow and Application Fluent Programmable Networks Strategic White Paper Increasing agility and

More information

Gaining Operational Efficiencies with the Enterasys S-Series

Gaining Operational Efficiencies with the Enterasys S-Series Gaining Operational Efficiencies with the Enterasys S-Series Hi-Fidelity NetFlow There is nothing more important than our customers. Gaining Operational Efficiencies with the Enterasys S-Series Introduction

More information

Managing Latency in IPS Networks

Managing Latency in IPS Networks Application Note Revision B McAfee Network Security Platform Managing Latency in IPS Networks Managing Latency in IPS Networks McAfee Network Security Platform provides you with a set of pre-defined recommended

More information

IBM. Vulnerability scanning and best practices

IBM. Vulnerability scanning and best practices IBM Vulnerability scanning and best practices ii Vulnerability scanning and best practices Contents Vulnerability scanning strategy and best practices.............. 1 Scan types............... 2 Scan duration

More information

McAfee Network Security Platform Administration Course

McAfee Network Security Platform Administration Course McAfee Network Security Platform Administration Course Intel Security Education Services Administration Course The McAfee Network Security Platform Administration course from McAfee Education Services

More information

Chapter 2 TOPOLOGY SELECTION. SYS-ED/ Computer Education Techniques, Inc.

Chapter 2 TOPOLOGY SELECTION. SYS-ED/ Computer Education Techniques, Inc. Chapter 2 TOPOLOGY SELECTION SYS-ED/ Computer Education Techniques, Inc. Objectives You will learn: Topology selection criteria. Perform a comparison of topology selection criteria. WebSphere component

More information

Guidance Regarding Skype and Other P2P VoIP Solutions

Guidance Regarding Skype and Other P2P VoIP Solutions Guidance Regarding Skype and Other P2P VoIP Solutions Ver. 1.1 June 2012 Guidance Regarding Skype and Other P2P VoIP Solutions Scope This paper relates to the use of peer-to-peer (P2P) VoIP protocols,

More information

SDN Security Considerations in the Data Center. ONF Solution Brief October 8, 2013

SDN Security Considerations in the Data Center. ONF Solution Brief October 8, 2013 SDN Security Considerations in the Data Center ONF Solution Brief October 8, 2013 Table of Contents 2 Executive Summary 3 SDN Overview 4 Network Security Challenges 6 The Implications of SDN on Network

More information

Network Services in the SDN Data Center

Network Services in the SDN Data Center Network Services in the SDN Center SDN as a Network Service Enablement Platform Whitepaper SHARE THIS WHITEPAPER Executive Summary While interest about OpenFlow and SDN has increased throughout the tech

More information

Software Defined Networking What is it, how does it work, and what is it good for?

Software Defined Networking What is it, how does it work, and what is it good for? Software Defined Networking What is it, how does it work, and what is it good for? slides stolen from Jennifer Rexford, Nick McKeown, Michael Schapira, Scott Shenker, Teemu Koponen, Yotam Harchol and David

More information

Extending Network Visibility by Leveraging NetFlow and sflow Technologies

Extending Network Visibility by Leveraging NetFlow and sflow Technologies Extending Network Visibility by Leveraging and sflow Technologies This paper shows how a network analyzer that can leverage and sflow technologies can provide extended visibility into enterprise networks

More information

Extending the Internet of Things to IPv6 with Software Defined Networking

Extending the Internet of Things to IPv6 with Software Defined Networking Extending the Internet of Things to IPv6 with Software Defined Networking Abstract [WHITE PAPER] Pedro Martinez-Julia, Antonio F. Skarmeta {pedromj,skarmeta}@um.es The flexibility and general programmability

More information

Intelligent. Data Sheet

Intelligent. Data Sheet Cisco IPS Software Product Overview Cisco IPS Software is the industry s leading network-based intrusion prevention software. It provides intelligent, precise, and flexible protection for your business

More information

UNMASKCONTENT: THE CASE STUDY

UNMASKCONTENT: THE CASE STUDY DIGITONTO LLC. UNMASKCONTENT: THE CASE STUDY The mystery UnmaskContent.com v1.0 Contents I. CASE 1: Malware Alert... 2 a. Scenario... 2 b. Data Collection... 2 c. Data Aggregation... 3 d. Data Enumeration...

More information

CS 356 Lecture 16 Denial of Service. Spring 2013

CS 356 Lecture 16 Denial of Service. Spring 2013 CS 356 Lecture 16 Denial of Service Spring 2013 Review Chapter 1: Basic Concepts and Terminology Chapter 2: Basic Cryptographic Tools Chapter 3 User Authentication Chapter 4 Access Control Lists Chapter

More information

SDN AND SECURITY: Why Take Over the Hosts When You Can Take Over the Network

SDN AND SECURITY: Why Take Over the Hosts When You Can Take Over the Network SDN AND SECURITY: Why Take Over the s When You Can Take Over the Network SESSION ID: TECH0R03 Robert M. Hinden Check Point Fellow Check Point Software What are the SDN Security Challenges? Vulnerability

More information

DATA COMMUNICATOIN NETWORKING

DATA COMMUNICATOIN NETWORKING DATA COMMUNICATOIN NETWORKING Instructor: Ouldooz Baghban Karimi Course Book: Computer Networking, A Top-Down Approach, Kurose, Ross Slides: - Course book Slides - Slides from Princeton University COS461

More information

WHITE PAPER. FortiWeb and the OWASP Top 10 Mitigating the most dangerous application security threats

WHITE PAPER. FortiWeb and the OWASP Top 10 Mitigating the most dangerous application security threats WHITE PAPER FortiWeb and the OWASP Top 10 PAGE 2 Introduction The Open Web Application Security project (OWASP) Top Ten provides a powerful awareness document for web application security. The OWASP Top

More information

Hillstone T-Series Intelligent Next-Generation Firewall Whitepaper: Abnormal Behavior Analysis

Hillstone T-Series Intelligent Next-Generation Firewall Whitepaper: Abnormal Behavior Analysis Hillstone T-Series Intelligent Next-Generation Firewall Whitepaper: Abnormal Behavior Analysis Keywords: Intelligent Next-Generation Firewall (ingfw), Unknown Threat, Abnormal Parameter, Abnormal Behavior,

More information

CheckPoint FireWall-1 Version 3.0 Highlights Contents

CheckPoint FireWall-1 Version 3.0 Highlights Contents CheckPoint FireWall-1 Version 3.0 Highlights Contents Abstract...2 Active Network Management...3 Accounting... 3 Live Connections Report... 3 Load balancing... 3 Exporting log records to Informix database...

More information

IDS / IPS. James E. Thiel S.W.A.T.

IDS / IPS. James E. Thiel S.W.A.T. IDS / IPS An introduction to intrusion detection and intrusion prevention systems James E. Thiel January 14, 2005 S.W.A.T. Drexel University Overview Intrusion Detection Purpose Types Detection Methods

More information

Firewall Firewall August, 2003

Firewall Firewall August, 2003 Firewall August, 2003 1 Firewall and Access Control This product also serves as an Internet firewall, not only does it provide a natural firewall function (Network Address Translation, NAT), but it also

More information

VXLAN: Scaling Data Center Capacity. White Paper

VXLAN: Scaling Data Center Capacity. White Paper VXLAN: Scaling Data Center Capacity White Paper Virtual Extensible LAN (VXLAN) Overview This document provides an overview of how VXLAN works. It also provides criteria to help determine when and where

More information

Countermeasure for Detection of Honeypot Deployment

Countermeasure for Detection of Honeypot Deployment Proceedings of the International Conference on Computer and Communication Engineering 2008 May 13-15, 2008 Kuala Lumpur, Malaysia Countermeasure for Detection of Honeypot Deployment Lai-Ming Shiue 1, Shang-Juh

More information

PROTECTING INFORMATION SYSTEMS WITH FIREWALLS: REVISED GUIDELINES ON FIREWALL TECHNOLOGIES AND POLICIES

PROTECTING INFORMATION SYSTEMS WITH FIREWALLS: REVISED GUIDELINES ON FIREWALL TECHNOLOGIES AND POLICIES PROTECTING INFORMATION SYSTEMS WITH FIREWALLS: REVISED GUIDELINES ON FIREWALL TECHNOLOGIES AND POLICIES Shirley Radack, Editor Computer Security Division Information Technology Laboratory National Institute

More information

SDN and NFV in the WAN

SDN and NFV in the WAN WHITE PAPER Hybrid Networking SDN and NFV in the WAN HOW THESE POWERFUL TECHNOLOGIES ARE DRIVING ENTERPRISE INNOVATION rev. 110615 Table of Contents Introduction 3 Software Defined Networking 3 Network

More information

11.1. Performance Monitoring

11.1. Performance Monitoring 11.1. Performance Monitoring Windows Reliability and Performance Monitor combines the functionality of the following tools that were previously only available as stand alone: Performance Logs and Alerts

More information

Comprehensive Malware Detection with SecurityCenter Continuous View and Nessus. February 3, 2015 (Revision 4)

Comprehensive Malware Detection with SecurityCenter Continuous View and Nessus. February 3, 2015 (Revision 4) Comprehensive Malware Detection with SecurityCenter Continuous View and Nessus February 3, 2015 (Revision 4) Table of Contents Overview... 3 Malware, Botnet Detection, and Anti-Virus Auditing... 3 Malware

More information

Networking and High Availability

Networking and High Availability TECHNICAL BRIEF Networking and High Availability Deployment Note Imperva appliances support a broad array of deployment options, enabling seamless integration into any data center environment. can be configured

More information

Cisco Application Networking for BEA WebLogic

Cisco Application Networking for BEA WebLogic Cisco Application Networking for BEA WebLogic Faster Downloads and Site Navigation, Less Bandwidth and Server Processing, and Greater Availability for Global Deployments What You Will Learn To address

More information

The basic groups of components are described below. Fig X- 1 shows the relationship between components on a network.

The basic groups of components are described below. Fig X- 1 shows the relationship between components on a network. Elements of Email Email Components There are a number of software components used to produce, send and transfer email. These components can be broken down as clients or servers, although some components

More information

INCREASE NETWORK VISIBILITY AND REDUCE SECURITY THREATS WITH IMC FLOW ANALYSIS TOOLS

INCREASE NETWORK VISIBILITY AND REDUCE SECURITY THREATS WITH IMC FLOW ANALYSIS TOOLS WHITE PAPER INCREASE NETWORK VISIBILITY AND REDUCE SECURITY THREATS WITH IMC FLOW ANALYSIS TOOLS Network administrators and security teams can gain valuable insight into network health in real-time by

More information

Why an Intelligent WAN Solution is Essential for Mission Critical Networks

Why an Intelligent WAN Solution is Essential for Mission Critical Networks Why an Intelligent WAN Solution is Essential for Mission Critical Networks White Paper Series WP100135 Charles Tucker Director of Marketing June 1, 2006 Abstract: Reliable Internet connectivity is now

More information

LASTLINE WHITEPAPER. Using Passive DNS Analysis to Automatically Detect Malicious Domains

LASTLINE WHITEPAPER. Using Passive DNS Analysis to Automatically Detect Malicious Domains LASTLINE WHITEPAPER Using Passive DNS Analysis to Automatically Detect Malicious Domains Abstract The domain name service (DNS) plays an important role in the operation of the Internet, providing a two-way

More information

Introduction to Software Defined Networking (SDN) and how it will change the inside of your DataCentre

Introduction to Software Defined Networking (SDN) and how it will change the inside of your DataCentre Introduction to Software Defined Networking (SDN) and how it will change the inside of your DataCentre Wilfried van Haeren CTO Edgeworx Solutions Inc. www.edgeworx.solutions Topics Intro Edgeworx Past-Present-Future

More information

CS 356 Lecture 19 and 20 Firewalls and Intrusion Prevention. Spring 2013

CS 356 Lecture 19 and 20 Firewalls and Intrusion Prevention. Spring 2013 CS 356 Lecture 19 and 20 Firewalls and Intrusion Prevention Spring 2013 Review Chapter 1: Basic Concepts and Terminology Chapter 2: Basic Cryptographic Tools Chapter 3 User Authentication Chapter 4 Access

More information

CS 356 Lecture 25 and 26 Operating System Security. Spring 2013

CS 356 Lecture 25 and 26 Operating System Security. Spring 2013 CS 356 Lecture 25 and 26 Operating System Security Spring 2013 Review Chapter 1: Basic Concepts and Terminology Chapter 2: Basic Cryptographic Tools Chapter 3 User Authentication Chapter 4 Access Control

More information

Extending Network Visibility by Leveraging NetFlow and sflow Technologies

Extending Network Visibility by Leveraging NetFlow and sflow Technologies Extending Network Visibility by Leveraging and sflow Technologies This paper shows how a network analyzer that can leverage and sflow technologies can provide extended visibility into enterprise networks

More information

Network Instruments white paper

Network Instruments white paper Network Instruments white paper EXTENDING NETWORK VISIBILITY BY LEVERAGING NETFLOW AND SFLOW TECHNOLOGIES This paper shows how a network analyzer that can leverage and sflow technologies can provide extended

More information

Security Toolsets for ISP Defense

Security Toolsets for ISP Defense Security Toolsets for ISP Defense Backbone Practices Authored by Timothy A Battles (AT&T IP Network Security) What s our goal? To provide protection against anomalous traffic for our network and it s customers.

More information

The flow back tracing and DDoS defense mechanism of the TWAREN defender cloud

The flow back tracing and DDoS defense mechanism of the TWAREN defender cloud Proceedings of the APAN Network Research Workshop 2013 The flow back tracing and DDoS defense mechanism of the TWAREN defender cloud Ming-Chang Liang 1, *, Meng-Jang Lin 2, Li-Chi Ku 3, Tsung-Han Lu 4,

More information

Firewalls and IDS. Sumitha Bhandarkar James Esslinger

Firewalls and IDS. Sumitha Bhandarkar James Esslinger Firewalls and IDS Sumitha Bhandarkar James Esslinger Outline Background What are firewalls and IDS? How are they different from each other? Firewalls Problems associated with conventional Firewalls Distributed

More information

A NOVEL APPROACH FOR PROTECTING EXPOSED INTRANET FROM INTRUSIONS

A NOVEL APPROACH FOR PROTECTING EXPOSED INTRANET FROM INTRUSIONS A NOVEL APPROACH FOR PROTECTING EXPOSED INTRANET FROM INTRUSIONS K.B.Chandradeep Department of Centre for Educational Technology, IIT Kharagpur, Kharagpur, India kbchandradeep@gmail.com ABSTRACT This paper

More information

McAfee Web Gateway Administration Intel Security Education Services Administration Course Training

McAfee Web Gateway Administration Intel Security Education Services Administration Course Training McAfee Web Gateway Administration Intel Security Education Services Administration Course Training The McAfee Web Gateway Administration course from Education Services provides an in-depth introduction

More information

Radware s Smart IDS Management. FireProof and Intrusion Detection Systems. Deployment and ROI. North America. International. www.radware.

Radware s Smart IDS Management. FireProof and Intrusion Detection Systems. Deployment and ROI. North America. International. www.radware. Radware s Smart IDS Management FireProof and Intrusion Detection Systems Deployment and ROI North America Radware Inc. 575 Corporate Dr. Suite 205 Mahwah, NJ 07430 Tel 888 234 5763 International Radware

More information

Security principles Firewalls and NAT

Security principles Firewalls and NAT Security principles Firewalls and NAT These materials are licensed under the Creative Commons Attribution-Noncommercial 3.0 Unported license (http://creativecommons.org/licenses/by-nc/3.0/) Host vs Network

More information

Deploying Advanced Firewalls in Dynamic Virtual Networks

Deploying Advanced Firewalls in Dynamic Virtual Networks SOLUTION GUIDE Deploying Advanced Firewalls in Dynamic Virtual Networks Enterprise-Ready Security for Network Virtualization 1 This solution guide describes how to simplify deploying virtualization security

More information

Understanding TCP/IP. Introduction. What is an Architectural Model? APPENDIX

Understanding TCP/IP. Introduction. What is an Architectural Model? APPENDIX APPENDIX A Introduction Understanding TCP/IP To fully understand the architecture of Cisco Centri Firewall, you need to understand the TCP/IP architecture on which the Internet is based. This appendix

More information