Three elements are needed to effectively counter DDoS attacks:
- specialized/dedicated hardware platforms/network mechanisms
- skilled engineers responsible for configuring tools and monitoring network events
- established incident handling processes and procedures.
The “further” from the end user a DDoS attack mitigation is initiated, the less impact the attackers will have on the infrastructure in question. Of course, providing the right level of protection should be structured in layers. This article will present selected mechanisms used by telecommunications operators providing Internet access services. By the time an attack reaches a bottleneck such as an access link, it may have undergone a mitigation process already within the service provider’s network.
Identifying network events and attack vectors
Before taking steps to thwart attackers, it is important to first identify these network events and determine the vector of attack being conducted. IP traffic analysis can be conducted on a copy of the traffic (so called mirroring), collecting data from network devices’ counters (e.g. SNMP) or using dedicated protocols transferring information about processed traffic (e.g. Netflow, sFlow, IPFIX). As methods based on traffic copying are not very scalable and detection based on general information provided by SNMP is limited, services using Flow/NetFlow protocols have gained the most popularity. We will focus on the protocol that started the family of such solutions, developed by Cisco – Netflow, later in this article. This protocol samples the actual traffic flowing through PE (Provider Edge) routers. The header of the sampled traffic is placed in a flow record, which is then exported to the components of the system responsible for monitoring network health. An older version (v5) of the Netflow protocol does not support IPv6. It also does not allow for statistics and analysis of network traffic in an MPLS-based infrastructure either. Therefore, in a carrier network, it is best to focus on using Netflow v9.
The wide applicability and great potential of Netflow v9 is due to the dynamic nature of this protocol. Earlier versions were static, meaning that data was exported in a strict format. Each field in the exported stream had a specific meaning, and trying to add new information involved developing a new version of the protocol. In Netflow v9, so-called templates were introduced to describe the type of data in the structure. A detailed description of the frame format is available in the material “NetFlow Version 9 Flow-Record Format”. The challenge that comes with such flexibility is the proper configuration of the flow data collector. There is a real risk that the collector will not be able to correctly interpret the information received in records generated from new templates and will therefore reject or incorrectly process such records.
However, a properly configured Netflow v9 will allow you to effectively monitor events in your transmission network. It is successfully used by both domestic and international operators – mainly due to its low implementation costs, high flexibility and scalability.
Know your enemy – traffic analysis
Due to the nature of DDoS attacks, it is more important to analyse traffic directed to protected resources (IP address(es)). This traffic should be counted using a minimum of 2 values:
- the number of megabits per second sent to a given object (Mbps)
- the number of packets per second sent to a given object (pps).
Determination of the expected values of traffic parameters should be based on the analysis performed during the period of normal network operation. The characteristics of valid traffic are a direct result of the services/activities performed on specific protected resources. By considering these and additional parameters in the collected data, detection rules/mechanisms are created to track any deviation from previously identified values or defined static thresholds. As a very simple example, we can assume that for a web server the natural state would be data transmission using the TCP protocol. Thus, the occurrence of network traffic in the UDP protocol can be considered as an anomaly and/or should be further analysed for a suspicious situation. Another example would be monitoring the average number of TCP sessions established/closed (3-way-handshake) per time unit. A sudden, significant increase in one of these parameters should trigger an alarm. The better the knowledge of the protected network, including the knowledge of services running on specific IP addresses, the more effective detection policies can be developed.
Parameters to monitor:
- source and destination IP addresses,
- source and destination ports,
- transport layer protocols (TCP, UDP),
- date and time,
- source and destination ASN,
- packet size,
- header flags,
Examples of data collected by the system that can be used to analyse a network event:
Fig. 1. Figures of pps and Mbps
Fig. 2. Source (registered ports) and targets (communication protocols)
Fig. 3a. Packet Size Statistics
Fig. 3b. Packet Size Statistics – Graph
Conclusion
The combination of the presented exemplary information makes it possible to determine the type and nature of events occurring in the network. Based on this, further steps can be taken to deal with incidents that occur. Any information gathered at the detection stage, in addition to triggering a dedicated alarm and determining its level in the monitoring system, can indicate a specific method for handling the incident/mitigating the traffic. Operators use different methods of handling/filtering the attack resulting both from the level of purchased service and from the real possibility of handling an attack with a specific signature. The mechanisms of mitigation will be described in more detail in part two, soon to follow.
