No entanto, as técnicas tradicionais de monitoramento não estão preparadas para atender a essas necessidades. Esta tese centra-se na inclusão da segurança na construção de novas ferramentas de monitorização de redes.
Introduction
From the Power Grid to a Smart Grid
The current architecture of the electricity grid presents problems by not allowing a significant part of our energy needs to be generated through renewable sources. The introduction of a large number of distributed sources, such as solar cells on residential roofs, is not easily manageable and increases the stability obligations in the operation of the grid.
From a conventional network to a Software Defined NetworkNetwork
These approaches map the abstract configurations that the applications express based on a simplified, abstract model of the network to a physical configuration for the global network view presented by the SDN controller. The coupling of the control and data planes (and its physical embedding in the network elements) makes the development and implementation of new network functions (e.g. routing algorithms) very difficult, as it would involve changing the control plane of all network devices – through the installation of new firmware and in some cases hardware upgrades. With SDN, management becomes simpler and middlebox services can be delivered as SDN controller applications.
All applications can benefit from the same network information (global network view), leading (possibly) to more consistent and effective policy decisions by reusing control plane software modules. Therefore there is no need to design a precise strategy for the location of the new functionality.
Motivation
Forwarding Devices Open Southbound API Network Opera,ng System (SDN Controllers) Network Abstrac,ons (eg topology abstrac,on). These intermediate boxes must be strategically placed in the network, making it even more difficult to later change the network topology, configuration and functionality. In contrast, SDN decouples the control plane from the network entities and becomes an external entity: the network.
Programming these applications becomes easier because the abstractions provided by the control platform and/or network programming languages can be shared. With SDN, management becomes simpler and middle-box services can be provided as applications for SDN controllers [21].
Contributions
Planning
The work we present in this thesis is part of a European project - SEGRID: security for smart grids - and a redefinition of the FCUL tasks in this project led to a significant change. That is why we decided to focus our attention on the fundamental component that is part of the resilient communication infrastructure that FCUL will develop over the course of this project: a secure monitoring system. We devised software plugins to carry out the attacks, implemented them and demonstrated the attacks experimentally.
Finally, after evaluating the existing solutions, we designed some more secure and accurate techniques to overcome the observed vulnerabilities.
Document structure
Finally, we demonstrate the attacks that cause the monitoring platform to report invalid measurement data. We concentrate on the two metrics most used in practice today: path delay and link throughput. We address SDN, Open-Flow and network monitoring with an emphasis on SDN-based monitoring frameworks.
Finally, we describe some useful network tools - Mininet, Ettercap and Scapy - that were used in this work.
Software Defined Networking
- OpenFlow
- SDN controllers
The OpenFlow protocol provides an open and standard way for a controller to communicate with switches and allows externally defined flow table entries. The SSL protocol can be used to securely send commands and packets from the controller to the switches using the Open-Flow protocol. In response, the controller installs appropriate flow rules to prevent packets with the same header from being forwarded to the controller.
In this way, the controller installs flows proactively, limiting network traffic to the desired configurations. The NOX model is event-based allowing a programmer to write an application by programming event handlers for the controller.
![Figure 2.1: Simplified view of an SDN architecture [21].](https://thumb-eu.123doks.com/thumbv2/123dok_br/17618359.4194337/32.892.247.619.218.479/figure-simplified-view-sdn-architecture.webp)
Network Monitoring
An alternative push-based approach is for the controller to request a switch to send a flow-expire message (flow-remove) when a flow expires. At the control level, the controller can periodically perform measurements of the network status. One example is through the transmission of probe packets sent back to the controller by switches.
SDN-based monitoring frameworks
DREAM [28] is a dynamic resource allocation measurement framework that balances a user-specified level of accuracy and resource utilization for measurement tasks. The sample rate produced by sFlow is not constant, it is equal to the packet rate on the port divided by the sampling rate. So if two distinct packets are sampled from a given TCP flow, they can calculate an accurate measure of the average flow rate during the sampling window by subtracting the two sequence numbers and dividing by the time between samples.
Multiple ports are mirrored into mirror ports, which are then connected to a aggregator to aggregate information and send the required statistics to the SDN controller. HONE [35] extends the scope of traffic management to the network stack of the end host, enabling joint traffic management between the host and the network.
SDN-based monitors
- A more detailed view on OpenNetMon
OpenNetMon1 is an SDN application that runs on top of the Pox [2] controller and performs adaptive monitoring of network path delay, flow throughput, and packet loss. When a data packet2 arrives at one of the switches and there is no match with the installed flow rules, it is passed to the controller (as a Packet-In) where it is processed. OpenNetMon learns the packet source MAC (Media Access Control) address and maps it to the switch ingress port.
A special probe packet 2.4 is transmitted to the input switch, which is then forwarded along the flow path until it reaches the output switch, where it is returned back to the controller using the input packet message (using pre-installed control). rules). The measurement frequency (in terms of probe transmission and query rate) varies according to the total throughput of all switches.
Networking tools
- Mininet
- Ettercap
- Scapy
For network monitoring purposes, OpenNet-Mon adds additional monitoring rules on the switches along the path when installing a new data flow. Running a platform in a single system is convenient, but on the downside, it can introduce resource constraints. Being an emulator, Mininet runs real programs on the hosts, just like on a hardware platform, making it easy to port from the virtual environment to a physical implementation.
At first we ran all the attacks in Ettercap, but we noticed that it introduced a lot of latency into the modified packets, which is a problem since the attacks need to be accurate. The main idea is to communicate incorrect monitoring values to the controller, which affects possible reconfigurations of routing parameters on the data plane.
Threat model
Another strong attack could directly interfere with the communication of the control plane, but if we assume that the communication links between the controller and the switches are secure, and more importantly, if they guarantee at least data integrity, then a weak adversary will not be able to use it way to attack. We limit the resistance actions to the data plane, which means that the connections between the controller and the switches are considered secure (eg using SSL). In addition, we assume that switches involved in the measurements (e.g. sw1andswn) work according to their specification, that is, they are not compromised by the adversary.
A1: an adversary can inject any traffic into the target network along the path we want to monitor;. Attack vectors are the links between each pair of connected switches and the links between the switches and the connected hosts.
Implementation
- A1 plugins
This means that opponents with further abilities may be able to amplify the impact of our attacks. A3: this opponent is used in conjunction with A2, and she has the additional ability to drop packets after shedding. In summary, we assume that the attack surface is only the data plane of an SDN network.
The A1 adversary represented in Figure 3.2 has the sole ability to inject arbitrary traffic into the network.
Attacking latency measuring
A2 and A3 plugins
The A2 adversary represented in Figure 3.4 has higher capabilities which allow him to inject, intercept, modify or drop packets. As seen in Figure 3.3, in Scapy the packets arriving at the attacker's interfaces are sniffed, modified as needed by the plugin and dropped by IPTABLER (they are injected by Scapy into the correct interface, avoiding duplicates).
Attacking throughput measuring
Attacking the monitor
- Testing environment
This section presents a series of attacks that expose vulnerabilities of SDN-based monitoring platforms. We focus our attention in attacks that affect the measurement of path delay and throughput. We chose the recently proposed SDN-based monitoring application OpenNetMon [37], which is open source available, to demonstrate the feasibility of the attacks.
As shown in Figure 3.5, the main modification was to use only two switches, swentry and swexit.
SDN controller
A1sender
Attacking delay measurements
Probing for latency measurements
Controller
Attacking throughput measurements
Within the network, it is therefore possible to identify a flow based on a 5-tuple consisting of source and destination IP address, source and destination port, and transport protocol. Whenever a match occurs in a rule, its counter is incremented by the number of bytes in the packet. The adversary's goal is to hide from the monitor the traffic passing through the switch, causing it to report throughput that is lower than its actual value.
In this case, OpenNetMon, as usual, adds a flow rule to each switch on the path of the packet (from inbound to outbound). So this packet does not go through the usual path and the counters of the switches are not incremented, i.e. they remain at zero.
Attacking throughput measuring
- Strategies to secure the network monitor
- Traditional security techniques
- Path delay probing techniques
- DoS attacks
- Using SDN holistic view
- Correlating switch counters
- Correlating sampled packets
- Enhancing switch design
- Conclusion
The controller places monitoring traffic in the data plane directed back to itself, and keeps track of the departure and arrival times of this traffic to calculate the path delay. Suggested Solution #1: One possible solution, but not ideal, is to install a meter in the probe packet flow line of each switch. If the received throughput from switch 2 is higher than the transmitted throughput from switch 1, this is evidence of a malicious packet injection into the link.
If the probe can be hidden in the normal forwarded traffic, we not only solve latency measurements, but also provide an attack detector for statistical measurements. To select which packets to use as samples, a sampling algorithm must be implemented in the switches. P4 [9] allows the functionality of programmable switches not only to be specified by the controller, but also to be changed in the switches.
To increase the security of monitoring platforms, authentication and integrity could be integrated into the switches using P4, by adding identifiers or by signing specific packets.
