3 === Defense4All Design
\r
5 Defense4All is a security SDN application for detecting and driving mitigation of DoS and DDoS attacks in different SDN topologies. It realizes anti-DoS in OOP mode for the ProgrammableFlow SDN environment. Administrators can configure Defense4All to protect certain networks
\r
6 and servers, known as protected networks or Protected Objects (POs). Defense4All exploits SDN capabilities to count specified traffic, and installs traffic counting flows for each protocol of
\r
7 each configured PO in every network location (VTN Vexternals) through which traffic of the subject PO flows. Defense4All then monitors traffic of all configured POs, summarizing readings, rates,
\r
8 and averages from all relevant network locations. If it detects a deviation from normal learned traffic behavior in a protocol (such as TCP, UDP, ICMP, or the rest of the traffic) of a particular
\r
9 PO, Defense4All declares an attack against that protocol in the subject PO. The Defense4All learning period has a minimum of one week from the installation of the counting flows in
\r
10 which Defense4All does not detect attacks. +
\r
12 To mitigate a detected attack, Defense4All performs the following procedure: +
\r
14 . Validates that the DefensePro device is alive and selects a live connection to it (if DefensePro is not alive or does not have a live connection from a PFS, then no traffic diversion is performed. For more information, refer to the Continuity section.
\r
15 . Configures DefensePro with a security policy and normal rates of the attacked traffic. The latter speeds up DefensePro’s efficient mitigation of the attack.
\r
16 . Starts monitoring and logging syslogs arriving from DefensePro for the subject traffic. As long as it continues receiving syslog attack notifications from DefensePro regarding this attack, Defense4All continues attack mitigation through traffic diversion even if the Vexternal FlowFilter counters do not indicate any more attacks.
\r
17 . Maps the selected physical DefensePro connection to the relevant VTN by creating a pair of Vexternals and mapping them to the selected pair of physical PFS ports connected to DefensePro. Automatically learns and preserves VLAN tagging if it exists. If Defense4All has already created and mapped a pair of Vexternals with the same VLAN in the VTN, then the same pair is also reused for diversion of the new traffic (rather than creating new Vexternals for the same VTN and VLAN).
\r
18 . Installs higher priority flow filter entries in every north Vexternal through which the attacked traffic flows in order to redirect traffic to the “north DP-In Vexternal”. It also selects one of the live north interfaces of the Vbr connected to all those Vexternals (there can be exactly one Vbr with the same VLAN). Defense4All re-injects traffic from the “DP-Out Vexternal” to the selected interface of the Vbr. When Defense4All decides that the attack is over (no indication from either PFC FlowFilter counters or from DefensePro) it reverts the previous actions: it stops monitoring for DefensePro syslogs about the subject traffic, it removes the traffic diversion FlowFilters, removes the “DP-In and DP-Out Vexternals” (if this is the last attack in this VTN and VLAN), and removes the security configuration from DefensePro. Defense4All then returns to peacetime monitoring.
\r
20 In this version, Defense4All runs as a single instance (non-clustered), but integrates the following main fault tolerance features:
\r
22 * Runs as a Linux service that is automatically restarted should it fail.
\r
23 * State entirely persisted in stable storage, and upon restart Defense4All obtains the latest state.
\r
24 * Carries a health tracker with restart and reset capabilities to overcome certain logical and aging bugs.
\r
26 Defense4All monitors the status of DefensePro, switch connections to DefensePro, relevant Vbrs in various VTNs, northbound interfaces of those Vbrs, and north Vexternals and adjusts, cancels, and (re)initiates attack traffic diversion accordingly.
\r
28 The following figure illustrates the possible state of any given PO. Radware’s DefensePro (DP) is an example of an incorporated AMS.
\r
29 image::Pn_possible_states.jpg[Workflow of Defense4All Attack Mitigation]
\r
31 === Defense4All in an ODL Environment
\r
32 Defense4All comprises of an SDN application framework and the Defense4All application itself, packaged as a single entity.
\r
33 Application integration into the framework is pluggable, so any other SDN application can benefit from the common framework services.
\r
35 The main advantages of this architecture are:
\r
37 * Faster application development and changes - The Framework contains common code for multiple applications, complex elements (such as clustering and repository services) are implemented once for the benefit of any application.
\r
38 * Faster, flexible deployment in different environments, form-factors, satisfying different NFRs – The Framework masks from SDN application factors such as required data survivability, scale and elasticity, availability, security.
\r
39 * Enhanced robustness - Complex framework code is implemented and tested once, cleaner separation of concerns leads to more stable code, and the framework can increase robustness proactively with no additional code in the application logic (such as periodic application recycle).
\r
40 * Unified management of common aspects – Common look and feel.
\r
44 The following figure illustrates the framework view.
\r
45 image::800px-Framework_view.jpg[Framework View]
\r
47 The framework contains the following elements:
\r
49 *FrameworkMain* – The Framework root point contains references to all Framework modules and global repositories, as well as the roots of deployed SDN applications (in the current version, the framework can accommodate only one application). This is also the point to start, stop, or reset the framework (along with its hosted application) Web server, Jetty Web server running the Jersey RESTful Web services framework, with Jackson parser for JSON encoded parameters. The REST Web server runs a servlet for the framework and another servlet for each deployed application (currently only one). All REST and CLI APIs are supported through this REST Web server.
\r
51 *FrameworkRestService* – A set of classes constituting the framework servlet that responds to framework REST requests ( get latest Flight Recorder records, perform factory reset, and so on). The FrameworkRestService invokes control and configuration methods against the FrameworkMgmtPoint, and for reporting it retrieves information directly from the relevant repositories. For flight recordings, it invokes methods against the FlightRecorder.
\r
53 *FrameworkMgmtPoint* – The point to drive control and configuration commands (start, stop, reset, set address of the hosting machine, and so on). FrameworkMgmtPoint in turn invokes methods against other relevant modules in the correct order. It forwards lifecycle requests (start, stop, reset) directly to FrameworkMain to drive them in the correct order.
\r
55 *Defense4All Application* – The AppRoot object that should be implemented/extended by any SDN application (in this case, Defense4All). SDN applications do not have “main,” and their lifecycle (start, stop, reset) is managed by the framework operating against the application root object, which then drives all lifecycle operations in the application. This module also contains references back to the framework, allowing the application to use framework services (such as create a Repo and log a flight record) and common utilities.
\r
57 *Common classes and Utilities* – A library of convenient classes and utilities from which any framework or SDN application module can benefit. Examples include wrapped threading services (for asynchronous, periodic, or background execution), short hash of a string, and confirmation by user.
\r
59 *Repository services* – One of the key elements in the framework philosophy is decoupling the compute state from the compute logic. All durable states should be stored in a set of repositories that can be then replicated, cached, distributed under the covers, with no awareness of the compute logic (framework or application). Repository services comprise the RepoFactory and Repo or its annotations-friendly equivalent – the EntityManager. The RepoFactory is responsible for establishing connectivity with the underlying repository plugged-in service, instantiate new requested repositories, and return references to existing ones. The chosen underlying repository service is Hector Client over Cassandra NoSQL DB. Repo presents an abstraction of a single DB table. It enables reading the whole table, only table keys (tables are indexed by only the single primary key), records or single cells, as well as writing records or single cells with controlled eagerness. A sub-record (with only a portion of cells) may be written. In this case, the displayed cells override existing ones in the repository. Other cells in the repository remain unchanged. In contrast to a relational DB, in which all columns must be specified up-front (in a schema design), Repo leverages the underlying Cassandra support to contain rows (records) in the same table with different sets of columns, some of which may not being even defined up-front. Furthermore, cells with new columns can be added or removed on the fly. RepoFactory and Repo (as well as its Entity Manager annotation-friendly equivalent) constitute a convenient library targeted to framework and SDN applications goals on top of the Hector client library communicating with Cassandra Repository cluster. Scaling the Cassandra cluster, distributing data shards across Cassandra cluster members, and configuring read/write eagerness and consistency are for the most part encapsulated in this layer.
\r
61 *Logging and Flight Recorder services* – The logging service uses Log4J library to log error, warning, trace, or informational messages. These logs are mainly for Defense4All developers. Administrators can obtain additional details about failures from the error log. FlightRecorder records all flight records recorded by any Defense4All module, including information received from external network elements such as ODC and AMSs. It then allows a user or administrator to obtain that information through the REST API or the CLI. Flight records can be filtered by categories (zero or more can be specified) and by time ranges. FlightRecorder stores all flight records in its own Repo (with another repo holding time ranges for efficient time ranges retrieval from the records repo). Because all flight records are stored in Cassandra, the number of flight records Defense4All can keep is limited only by the size of the underlying persistent storage capacity of all Cassandra servers, and so even on a single Cassandra instance, months of historical information can be kept.
\r
63 *HealthTracker* – The point to hold the aggregated runtime health of Defense4All and to act in response to severe deteriorations. Any module, upon sensing unexpected and/or faulty behavior in it or in any other module can record a “health issue” in the HealthTracker, providing health issue significance. This is instead of directly triggering a Defense4All termination. This means that numerous health issues in a short period with high aggregated significance are likely to indicate a significant wide-spread Defense4All problem, but sporadic and/or intermittent operational “hiccups” can be neglected, even if Defense4All remains less than 100% operational (the administrator can always reset it to fully recover). As a result, every non-permanent health issue has a gradually diminished effect over time. If Defense4Al health deteriorates below a predefined threshold, HealthTracker triggers responsive actions depending on the nature of the health issues. A restart can heal transient problems, and so the HealthTracker triggers Defense4All termination (running as a Linux service, Defense4All is automatically restarted). To recover from more permanent problems, HealthTracker may additionally trigger a Defense4All reset. If this does not help, the next time the HealthTracker attempts a more severe reset. As a last resort, the administrator can be advised to perform a factory reset.
\r
65 *ClusterMgr* – Currently not implemented. This module is responsible for managing a Defense4All cluster (separate from Cassandra or ODC clusters, modeled as separate tier clusters). A clustered Defense4All carries improved high availability and scalability. Any module in the Defense4All framework or application can register with ClusterMgr for a clustered operation, specifying whether its functionality should be carried out by a single or by multiple/all active instances (running on different Defense4All cluster members). When cluster membership changes, ClusterMgr notifies each instance in each module about its role in the clustered operation of that module. If there is a single active instance, that instance is notified of its role in the cluster, while all other instances are notified that they are in standby mode. If there are multiple active instances, each active instance is notified about the number of active instances and its logical enumeration in that range. All states are stored in a globally accessible and shared repository, so any instance of a module is stateless, and can perform any role after every membership change. For example, following membership change N, an instance can be enumerated as 2 out of 7, as a result performing the relevant portion of the work. At membership change N+1, the same instance can be enumerated 5 out of 6, and perform the work portion allocated for 5 and not for 2. Peer messaging services are skipped which the ClusterMgr can provide for a more coordinated cross-instance operation.
\r
67 The Defense4All application is highly pluggable. It can accommodate different attack detection mechanisms, different attack mitigation drivers, and drivers (called reps [representative]) to different versions of the ODC and different AMSs. The Defense4All application comprises “core” modules and “pluggable” modules implementing well-defined Defense4All application APIs.
\r
69 === Application View
\r
71 The following figure illustrates the application view.
\r
72 image::800px-D4a_application_view.jpg[Application View]
\r
74 The following is a description of the Defense4All application modules: +
\r
76 *DFAppRoot* – The root module of the Defense4All application. The Defense4All application does not have “main,” and its lifecycle (start, stop, reset) is managed by the Framework operating against this module, which in turn drives all lifecycle operations in the Defense4All application. DFAppRoot also contains references to all Defense4All application modules (core and pluggable), global repositories, and references back to the framework, allowing the Defense4All application modules to use framework services (such as create a Repo and log a flight record) and common utilities.
\r
79 *DFRestService* – A set of classes constituting the Defense4All application servlet that responds to Defense4All application REST requests. The DFRestService invokes control and configuration methods against the DFMgmtPoint, and for reporting it retrieves information directly from the relevant repositories. For flight recordings, it invokes methods against the FlightRecorder.
\r
82 *DFMgmtPoint* – The point to drive control and configuration commands (such as addams and addpn). DFMgmtPoint in turn invokes methods against other relevant modules in the right order.
\r
85 *ODL Reps* – A pluggable module-set for different versions of the ODC. Comprises two functions in two sub-modules: stats collection for, and traffic diversion of, relevant traffic. These two sub-modules adhere to StatsCollectionRep DvsnRep APIs. ODL Reps is detailed in Figure 6 and the description that follows it.
\r
88 *SDNStatsCollector* – Responsible for setting “counters” for every PN at specified network locations (physical or logical). A counter is a set of OpenFlow flow entries in ODC-enabled network switches and routers. The SDNStatsCollector periodically collects statistics from those counters and feeds them to the SDNBasedDetectionMgr (see the description below). The module uses the SDNStatsCollectionRep to both set the counters and read latest statistics from those counters. A stat report consists of read time, counter specification, PN label, and a list of trafficData information, where each trafficData element contains the latest bytes and packet values for flow entries configured for <protocol,port,direction> in the counter location. The protocol can be {tcp,udp,icmp,other ip}, the port is any Layer 4 port, and the direction can be {inbound, outbound}.
\r
91 *SDNBasedDetectionMgr* – A container for pluggable SDN-based detectors. It feeds stat reports received from the SDNStatsCollector to plugged-in SDN based detectors. It also feeds all SDN based detectors notifications from the AttackDecisionPoint (see the description below) about ended attacks (so as to allow reset of detection mechanisms).
\r
94 *RateBasedDetector sub-module* – This detector learns for each PN its normal traffic behavior over time, and notifies AttackDecisionPoint (see the description below) when it detects traffic anomalies. For each protocol {TCP, UDP, ICMP, other IPs} of each PN, the RateBasedDetector maintains latest rates and exponential moving averages (baselines) of bytes and packets, as well as last reading time. The detector maintains those values both for each counter as well as the aggregation of all counters for each PN. The organization at two levels of calculations (counter and PN aggregate) allows for better scalability (such as working with clustered ODCs, where each instance is responsible for obtaining statistics from a portion of network switches, and bypassing the ODC single instance image API). Such organizations also enable a more precise stats collection (avoiding the difficulty of collecting all stats during a very small time interval). Stats are processed at the counter level, and periodically aggregated at the PN level. Continuous detections of traffic anomalies cause the RateBasedDetector to notify AttackDecisionPoint about attack detection. Then, absence of anomalies for some period of time causes the detector to stop notifying the AttackDecisionPoint about attack detection. The detector specifies a detection duration within which the detection is valid. After that time, the detection expires but can be “prolonged” with another notification about the same attack.
\r
97 *AttackDecisionPoint* – This module is responsible for maintaining attack lifecycles. It can receive attack detections from multiple detectors. Defense4All supports the RateBasedDetector, external detectors (scheduled for future versions), and AMS-based detector reference implementation (over Radware’s DefensePro). In the current version, AttackDecisionPoint fully honors each detection (max detector confidence and max detection confidence). It declares a new attack for every detection of a newly attacked traffic (PN, protocol, and port), and adds more detections for existing (already declared) attacks. The module periodically checks the statuses of all attacks. As long as there is at least one unexpired detection (each detection has an expiration time), the attack is kept declared. If all detections are expired for a given attack the AttackDecisionPoint declares the attack has ended. The module notifies the MitigationMgr (see description below) to start mitigating any new declared attack. It notifies the MitigationMgr to stop mitigating ended attacks, and also notifies the detectionMgr to reset stats calculations for traffic on which an attack has just ended.
\r
100 *MitigationMgr* - A container for pluggable mitigation drivers. The MitigationMgr maintains the lifecycle of all mitigations as a result of mitigation notifications from AttackDecisionPoint. It holds a pre-ordered list of the MitigationDriver sub-modules, and attempts to satisfy each mitigation in that order. If MitigationDriveri indicates to MitigationMgr that it does not mitigate a mitigation (because of per PN preferences, unavailability of AMS resources, network problems, and so on) MitigationMgr will attempt mitigation by MitigationDriveri+1. If none of the plugged-in MitigationDrivers handle mitigation, it remains at the status ‘not-mitigated.’
\r
103 *MitigationDriverLocal* – This mitigation driver is responsible for driving attack mitigations using AMSs in their sphere of management.
\r
104 When requested to mitigate an attack, this mitigator performs the following sequence of steps: +
\r
106 . Consults with the plugged in DvsnRep (see description below) about topologically feasible options of diversion for each of the managed AMSs from each of the relevant network locations. In this version, the diversion is always performed from the location where the stats counters are installed.
\r
107 . The MitigationDriverLocal selects an AMS out of all feasible options (in the first release, the selection is trivial—it is the first in list).
\r
108 . Optionally configures all the AMSs (each diversion source may have a different AMS associated with it) prior to instructing to divert traffic to each. This is done through the plugged in AMSRep.
\r
109 . MitigationDriverLocal instructs the DvsnRep to divert traffic from each source NetNode (in this version, NetNode is modeled over an SDN switch) to the AMS associated with that NetNode. Diversion can be either for inbound traffic only or both for inbound and outbound traffic.
\r
110 . Mitigation driver notifies the AMSBasedDetector to optionally start monitoring the attack status in all the AMSs, and feed attack detections to the AttackDecisionPoint.
\r
111 . In future versions, the MitigationDriverLocal is scheduled to monitor health of all AMSs and relevant portions of network topologies, re-selecting AMSs should some fail, or should network topologies changes require that.
\r
112 When mitigation should be ended, the MitigationDriverLocal notifies AMSBasedDetector to stop monitoring the attack status for the ended attack, notifies DvsnRep to stop traffic diversions to all AMSs for this mitigation, and finally notifies the AMSRep to optionally clean all mitigation-related configuration sets in each relevant AMS.
\r
114 *AMSBasedDetector* – This optional module (which can be packaged as part of the AMSRep) is responsible for monitoring/querying attack mitigation by AMSs. Registering as a detector, this module can then notify AttackDecisionPoint about attack continuations and endings. It monitors only specified AMSs and only for specified (attacked) traffic.
\r
117 *AMSRep* - A pluggable module for different AMSs. The module adheres to AMSRep APIs. It can support configuration of all introduced AMSs (permanently or before/after attack mitigations). It can also receive/query security information (attack statuses), as well as operational information (health, load). AMSRep module is entirely optional – AMSs can be configured and monitored externally. In many cases, attacks can continue be monitored solely via SDN counters. Defense4All contains a reference implementation AMSRep that communicates with Radware’s DefensePro AMSs.
\r
121 The following figure illustrates the Defense4All application ODL Reps module-set structure.
\r
122 image::D4a_odl_reps_view.jpg[ODL Reps View]
\r
124 Different versions of OFC may be represented by different versions of the ODL Reps module-set. ODLReps comprises two functions: stats collection for, and traffic diversion of, relevant traffic. Both or either of the functions may be utilized in a given deployment.
\r
125 As such, they have a common point to communicate with the ODC and hold all general information for the ODC.
\r
127 ODL Reps supports two types of SDN switches: sdn-hybrid, which supports both SDN and legacy routing, and sdn-native, which supports SDN only routing. Counting traffic on the sdn-hybrid switch is done by programming a flow entry with the desired traffic selection criteria and the action “send to normal”, that is, to continue with legacy routing. Counting traffic on sdn-native switch requires an explicit routing action (which output port to send the traffic to). Defense4All avoids learning all routing tables by requiring an sdn-native switch which is more or less a bump-in the wire with respect to traffic routing (that is, traffic entering port 1 normally exits port 2 and traffic entering port 3 normally exits port 4 and vice versa). Such a switch allows for easy programming of flow entries just to count traffic or to divert traffic to/from the attached AMS. When Defense4All programs a traffic counting flow entry with selection criteria that includes port 1, its action is output to port 2, and similarly with 3 to 4. In future versions, this restriction is scheduled to be lifted.
\r
129 The following is a description of the sub-modules: +
\r
131 StatsCollectionRep - The module adheres to StatsCollectionRep APIs. Its main tasks are:
\r
133 * Offer counter placement NetNodes in the network. The NetNodes offered are all NetNodes defined for a PN. This essentially maps which of SDN switches the traffic of the given PN flows.
\r
134 * Add a peacetime counter in selected NetNodes to collect statistics for a given PN. StatsCollectionRep creates a single counter for a PN in each NetNode. (Overall, a NetNode can have multiple counters for different PNs; and a PN can have multiple counters in NetNodes as specified for the given PN). StatsCollectionRep translates the installation of a counter in a NetNode to programming four flow entries (for TCP, UDP, ICMP, and the rest of the IPs) for each “north traffic port” in that NetNode port from which traffic from a client to a protected PN enters the SDN switch. For example, StatsCollectionRep adds for a given PN 12 flow entries in an SDN switch with three ports through that PN’s inbound traffic enters the OFS. And, if another NetNode (SDN switch) was specified to have that PN’s inbound traffic entering it through two ports, then StatsCollectionRep programs for this PN eight flow entries in that second NetNode.
\r
135 * Remove a peacetime counter.
\r
136 * Read latest counter values for a specified counter. StatsCollectionRep returns a vector of latest bytes and packets counted for each protocol-port in each direction (currently only “north to south” is supported), along with the time it received the reading from the ODC.
\r
138 *DvsnRep* - The module adheres to DvsnRep APIs. Its main tasks are:
\r
140 * Return diversion properties from a given NetNode to a given AMS. In this version, an empty property is returned if such a diversion is topologically feasible (AMS is directly attached to the SDN switch over which the specified NetNode is modeled. Otherwise no properties are returned. This leaves room for remote diversions in future versions, and topological costs to each distant AMS, such as latency, bandwidth reservation, and cost).
\r
141 * Divert (attacked) traffic from a specified NetNode through an AMS. As such, the new flow entries take precedence over the peacetime ones. DvsnRep programs flow entries to divert inbound attacked traffic (or all traffic, if so specified for the PN) from every “north traffic port” into the AMS “north” port. If “symmetric diversion” (for both inbound and returning, outbound traffic) has been specified for that PN, DvsnRep programs another set of flow entries to divert attacked (or all) traffic from every “south traffic port” into the AMS “south” port. In an sdn-hybrid switch deployment, DvsnRep adds a flow entry for inbound traffic that returns from the AMS south port, with the action sent to normal, and similarly it adds a flow entry for outbound returning traffic from the AMS north port, with action of also sent to normal. In an SDN-native switch, the action is to send to the correct output port, however if this scenario the process is more complex for determining the correct port. North port MAC learning is used to determine from the source/destination MAC in the packet the correct output port. This scheme of flow entries works well for TCP, UDP and ICMP attacks. For “other IP” attacks, the flow entries programming is more complex, and is suppressed here for clarity. The set of flow entries programmed to divert (but still count) traffic comprises the “attack traffic floor”. There may be many attack traffic floors, all of which take precedence over the peacetime stats collection floor (by programming higher priority flow entries). Additional attacks (except “other IP” attacks, which is a special case, and is suppressed here) are created with higher priority traffic floors over previously set attack traffic floors. Attacks may fully or partially “eclipse” earlier attacks (for example, TCP port 80 over TCP, or vice versa), or be disjointed (such as TCP and UDP). Stats collection is taken from all traffic floors, both peacetime and attacks. An SDN-based detector aggregates all statistics into overall rates, thus determining if the attack is still in progress. (Note that eclipsed peacetime counted traffic may show zero rates, and that counting is complemented by the higher priority floor counters.)
\r
142 * End diversion. DvsnRep removes the relevant attack traffic floor (removing all of its flow entries from the NetNode). Note that this affects neither traffic floors “above” the removed floor nor the traffic floors “below.” In addition, the SDN-based detector receives the same aggregated rates from counters of remaining floors, so its operation also is not affected.
\r
144 *ODLCommon* – This module contains all common elements needed to program flow entries in the ODC. This allows for coherent programming of configured ODCs (in this version, at most one) by StatsCollectionRep and DvsnRep. For instance ODLCommon instantiates connectivity with the ODCs, maintains a list of programmed flow entries and cookies assigned to each. It also maintains references to DFAppRoot and FrameworkMain. When an sdn-native NetNode is added ODLCommon programs 2 flow entries per each protected link (pair of input-to-output ports) to transfer traffic between the two ports (traffic entering north port is routed to south port and vice versa). ODLCommon adds two more flow entries for each port connecting to an AMS to block returning ARP traffic (so as to avoid ARP floods if the AMSs are not configured to block them). This “common traffic floor” flow entries are set with the lowest priority. Their counters are accounted for neither stats collections nor traffic diversion. When a NetNode is removed, ODLCommon removes this common traffic floor flow entries.
\r
147 *FlowEntryMgr* – This module provides an API to perform actions on flow entries in an SDN switch managed by an ODC, and retrieves information about all nodes managed by an ODC. Flow entries actions include adding a specified flow entry in a specified NetNode (SDN switch/router), removing a flow entry, toggling a flow entry, getting details of a flow entry, and reading statistics gathered by the flow entry. FlowEntryMgr uses the connector modules to communicate with the ODC.
\r
150 *Connector* – This module provides the basic API calls to communicate with the ODC, wrapping REST communications. After initializing connection details with a specified ODC, the connector allows getting or deleting data from the ODC, as well as posting or putting data to the ODC.
\r
153 *ODL REST Pojos* – This set of Java classes are part of the ODC REST API, specifying the Java classes of the parameters and the results of interaction with the ODC.
\r
155 === Basic Control Flow
\r
157 Control flows are logically ordered according to module runtime dependencies, so if module A depends on module B then module B should be initialized before module A, and terminate after it. Defense4All application modules depend on most Framework modules, except WebServer.
\r
159 *Startup* — Defense4All initializes all its modules and re-applies previously configured infrastructure and security set-ups, obtaining them from persistent repositories. At the end of the Startup process, Defense4All resumes its prior operation. +
\r
160 *Termination* - restart — Defense4All persists any relevant data into stable storage repositories, and terminates itself. If the termination is for restart, the automatic restart mechanism restarts Defense4All. Otherwise (such as upgrading) Defense4All does not automatically restart. +
\r
161 *Reset* — In this flow, all modules are reset to factory level. This means that all dynamically obtained data as well as user configurations are deleted +
\r
163 === Configurations and Setup Flow
\r
165 *OFC (OpenFlowController = ODC)* – When DFMgmtPoint receives from DFRestService a request to add an OFC, it first records the added OFC in the OFC’s Repo, and then notifies ODLStatsCollectionRep and ODLDvsnRep, which in turn notify the ODL to initiate a connection to the added OFC (ODC). ODL instantiates a REST client for communication with the ODC.
\r
168 *NetNode* - Multiple NetNodes can be added. Each NetNode models a switch or similar network device, along with its traffic ports, protected links, and connections to AMSs. When DFMgmtPoint receives from DFRestService a request to add a NetNode, it first records the added NetNode in NetNodes Repo, and then notifies ODLStatsCollectionRep and ODLDvsnRep, followed by MitigationMgr. ODLStatsCollectionRep and ODLDvsnRep then notify the ODL, and the ODL installs low priority flow entries to pass traffic between the protected links’ port pairs. MitigationMgr notifies MitigationDriverLocal, which updates its NetNode-AMS connectivity groups for consistent assignment of AMSs to diversion from given NetNodes.
\r
171 *AMS* – Multiple AMSs can be added. When DFMgmtPoint receives from DFRestService a request to add an AMS, it first records the added AMS in the AMS’s Repo, and then notifies AMSRep. AMSRep can optionally pre-configure protection capabilities in the added AMS, and start monitoring its health.
\r
174 *PN* - Multiple PNs can be added. When DFMgmtPoint receives from DFRestService a request to add a PN, it first records the added PN in the PN’s Repo, notifies MitigationMgr, and then finally notifies the DetectionMgr. MitigationMgr notifies MitigationDriverLocal, which then notifies AMSRep. AMSRep can preconfigure the AMS for this PN, as well its EventMgr to accept events related to this PN’s traffic. DetectionMgr notifies RateBasedDetector, which then notifies StatsCollector. StatsCollector queries ODLStatsCollectionRep about possible placement of stats collection counters for this PN. ODLStatsCollectionRep returns all NetNodes configured for this PN (and if none are configured, it returns all NetNodes currently known to Defense4All). StatsCollector “chooses” the counter locations option (the only available option in this version). For each of the NetNodes, it then asks ODLStatsCollectionRep to create a counter for the subject PN. The counter is essentially a set of flow entries set for the protocols of interest (TCP, UDP, ICMP, and the rest of the IPs) on each north traffic port. The counter is given a priority and this constitutes the peacetime traffic floor (to monitor traffic by periodically reading all counter flow entry traffic count values). Because the PN may be re-introduced at restart or a change in network topology may require re-calculation of counter locations, it is possible that some/all counters may already be in place. Only new counters are added. Counters that are no longer are removed. ODLStatsCollectionRep configures the flow entries according to the NetNode type. For hybrid NetNodes, the flow entry action is “send to normal” (proceed to legacy routing), while for native NetNodes, the action is to match the output port (in each protected link). OdlStatsCollectionRep invokes the ODL to create each specified flow entry. The latter invokes FlowEntryMgr and Connector to send the request to the ODC.
\r
176 === Attack Detection Flow
\r
177 Periodically, the StatsCollector requests the ODL StatsCollectionRep to query the ODC for the latest statistics for each set counter for each configured PN. ODLStatsCollectionRep invokes FlowEntryMgr to obtain statistics for each flow entry in a counter. The latter invokes the connector to obtain the desired statistics from the ODC.
\r
179 ODLStatsCollectionRep aggregates the obtained results in a vector of stats (latest bytes and packets readings per each protocol) and returns that vector. StatsCollector feeds each counter stats vector to DetectionMgr, which then forwards the stats vector to the RateBasedDetector. The RateBasedDetector maintains stats information for every counter as well as aggregated counter stats for every PN. Stats information includes the time of previous reading, and for every protocol the latest rates and exponential averages.
\r
181 The RateBasedDetector checks for significant and prolonged latest rate deviations from the average, and if such deviations are found in the PN aggregated level, it notifies the AttackDecisionPoint about attack detection. As long as deviations continue, the RateBasedDetector continues notifying the AttackDecisionPoint about the detections. It sets an expiration time for every detection notification, and repeatable notifications essentially prolong the detection expiration.
\r
183 AttackDecisionPoint honors all detections. If it has already declared an attack on that protocol-port, then the AttackDecisionPoint associates the additional detection with that existing attack. Otherwise, it creates a new attack and notifies the MitigationMgr to mitigate that attack (as described below). Periodically, AttackDecisionPoint checks the status of all detections of each live attack. If all detections have expired, AttackDecisionPoint declares the end of the attack and notifies MitigationMgr to stop mitigating the attack.
\r
185 === Attack Mitigation Flow
\r
187 MitigationMgr, upon receiving mitigate notification from yhe AttackDecisionPoint, attempts to find a plugged-in MitigationDriver to handle the mitigation. Currently, it requests only its plugged-in MitigationDriverLocal.
\r
189 MitigationDriverLocal checks if there are known, live, and available AMSs to which attacked (or all) traffic can be diverted from NetNodes through which attacked traffic flows. It selects one of the suitable AMSs and configures it prior to diverting attack traffic to the selected AMS. For example, MitigationDriverLocal retrieves from Repo the relevant protocol averages, and configures them in AMS through the AMSRep.
\r
191 MitigationDriverLocal then requests ODLDvsnRep to divert the attacked PN protocol-port (or all PN) traffic from each of the NetNodes through which the PN traffic flows to the selected AMS.
\r
193 ODLDvsnRep creates a new highest priority traffic-floor (that contains flow entries with a priority higher than any flow entry in the previously set traffic floors). The traffic floor contains all flow entries to divert and count traffic from every ingress/northbound traffic port into the AMS, and back from the AMS to the relevant output (southbound) ports. Optionally, diversion can be “symmetric” (in both directions), in which case flow entries are added to divert traffic from southbound ports into the AMS, and back from the AMS to northbound ports. Note that the StatsCollector treats this added traffic floor as any other, and passes obtained statistics from this floor to the DetectionMgr/RateBasedDetector. Because traffic floors are aggregated (in the same NetNode as well as across NetNodes) for a given PN the combined rates remain the same as prior to diversion. Just like ODLStatsCollectionRep, ODLDvsnRep also utilizes lower level modules to install the flow entries in desired NetNodes.
\r
195 Finally, MitigationDriverLocal notifies AMSRep to optionally start monitoring this attack and notify the AttackDecisionPoint if the attack continues or new attacks develop. AMSRep can do that through the AMSBasedDetector module.
\r
197 If MitigationDriverLocal finds no suitable AMSs, or fails to configure any of its mitigation steps, it aborts the mitigation attempt, asynchronously notifying MitigationMgr. The mitigation then remains in status “no-resources.”
\r
199 When MitigationMgr receives a notification to stop mitigating an attack, it forwards this notification to the relevant (and currently the only) MitigationDriver, MitigationDriverLocal. MitigationDriverLocal reverses the actions in at the start of the mitigation. It notifies AMSRep to stop monitoring for this attack, it cancels diversion for the attacked traffic, and finally notifies AMSRep to optionally remove pre-mitigation configurations.
\r
203 Service Continuity, as opposed to High Availability, is defined here as the ability to deliver a required level of service, at tolerable cost,
\r
204 in the presence of disrupting events, where:
\r
206 * Disrupting events can be load, changes, logical errors, failures and disasters, administrative actions (such as an upgrade), external attacks, and so on.
\r
207 * The level of service can include response time, throughput, survivability of data/operations, security/privacy, and so on. The required level of service may differ for every service function, for every type of event, at different event handling phases.
\r
208 * The cost can include people (number, expertise), equipment (hardware, software), facilities (space, power). +
\r
210 *Clustering and Fault-tolerance* - Clusters help to address both Scalability and High Availability. If one of the cluster members fails, another cluster member can quickly assume its responsibilities. This overcomes member failures, member hosting machine failures, and member network connectivity failures. Defense4All clustering is scheduled for future releases. In version 1.0, Defense4All runs as a Linux restartable service, so if it fails, the hosting Linux OS revives Defense4All. This enables overcoming intermittent/sporadic Defense4All failures. Failure of the Defense4All hosting machine means longer time and modest additional human effort to revive the machine and its hosted Defense4All. If the machine cannot be brought up, Defense4All can be started on another machine in the network. To ensure that Defense4All resumes its operation (rather that restart from scratch) you must pre-load the Defense4All (latest or earlier) state snapshot on that machine. A non-clustered environment affects the time and the human effort to recover from machine failures. The time factor is less critical, as Defense4All runs out-of-path, so its longer non-availability period means a longer time to detect and mitigate new attacks.
\r
212 *State Persistence* - Defense4All persists the state in the Cassandra DB running on the same machine. In version 1.0, only one Cassandra instance cluster is configured. As long as local stable storage does not crash, a Linux restart of the Defense4All service enables Defense4All to quickly retrieve its latest state from Cassandra and resume its latest operation. The same happens at failure and restart of the machine hosting Defense4All. Taking the Defense4All state backup, and restoring on another machine allows for resuming the Defense4All operation on that machine. Multi-node Cassandra clusters (scheduled for future versions) will increase state persistence while reducing recovery time and effort.
\r
214 *Restart Process* - When Defense4All (re)starts, it first checks for saved configuration data, and re-plays the configuration steps against all its relevant modules, driving any relevant external programming and/ or configuration actions (such as against the PFC or AMS devices), for example, re-adding a PO. The only difference between this configuration replay and original configuration is that any dynamically obtained data is preserved, for example, all PO statistics. This allows for easily reaching internal consistency, especially in cases where Defense4All or its hosting machine has crashed. When configuration action derivatives are replayed against external entities, for example adding missing PO stats counters, and removing no longer necessary ones, consistency with external entities is also reached. Defense4All becomes operational (launching its Web server), lets you or some other component to complete Defense4All missing configurations according to possible changes while Defense4All was down. This results in reaching end-to-end consistency.
\r
216 *Reset* - Defense4All lets you reset its dynamically obtained data and configuration information (factory reset). This enables you to overcome many logical errors and mis-configurations. Note that a Defense4All restart or failover would not overcome such problems. This mechanism is therefore complementary to the restart-failover mechanism, and should typically be applied as a last resort.
\r
218 *Failure Isolation and Health Tracker* - In Defense4All, failure isolation takes place in the form of a failure of immediate recovery or compensation (as much as possible), and a failure recording in a special module called Health Tracker. Except for a handful of substantial failures (such as a failure to start the Framework), no failure in any module immediately causes Defense4All to stop. Instead, each module records each failure in its scope, providing severity specifications and an indication of failure permanence. If the combined severity (permanent or temporary) of all failures exceeds a globally set threshold, the HealthTracker triggers Defense4All shutdown (and revival by Linux). Later on, permanent or repeating temporary faults will cause HealthTracker to trigger Defense4All soft and dynamic reset (of dynamically obtained data) or suggest to the administrator to perform a factory reset (that also includes configuration information).
\r
220 *State Backup and Restore* - The administrator can snapshot the Defense4All state, save the backup in a different location, and restore to the original or new Defense4All location. This allows overcoming certain logical bugs and mis-configurations, as well as the permanent failure of the machine hosting Defense4All. To snapshot the Defense4All state, do the following:
\r
222 . Quiesce (shutdown) Defense4All, causing the current state to flush to stable storage). Avoid performing any configurations changes when it is brought back up, avoiding new state changes.
\r
223 . Take the Cassandra snapshot for Defense4All DB - "DF": For backup-restore guidelines, refer to http://www.datastax.com/docs/1.0/operations/backup_restore.
\r
224 . Copy the snapshot files to the desired storage archive.
\r
226 To restore a Defense4All backup to a target machine, do the following:
\r
228 . Restore the desired saved snapshot in the target machine (same as backup or different). For Cassandra backup-restore guidelines, refer to http://www.datastax.com/docs/1.0/operations/ backup_restore.
\r
229 . Bring up Cassandra on that machine.
\r
230 . Bring up Defense4All on that machine.
\r
Code Review / docs.git / blob