Spoofed DDoS Attacks and BCP 38

The majority of recent DDoS attacks utilize source address spoofing techniques. These spoofed DDos attacks complicate mitigation efforts and hide the IP address of the originating system. It happens with TCP SYN floods as well as UDP amplification and reflection attacks. This post was created to raise awareness on the existence of best practices to prevent address spoofing. Administrators of networks connected to the Internet are urged to implement ingress filtering according to BCP 38 and RFC 3704 to prohibit the abuse of internal devices to generate spoofed packets.

DDoS attacks, as the name suggests, originate from multiple devices distributed around the Internet. Packets traversing IP networks contain a header with source and destination addresses. In spoofed DDoS attacks, source addresses are modified on purpose to point to something other than the originating device. The receiving party is fooled to believe that replies must be sent to the spoofed address. Therefore, the real address of the attacker can’t be discovered.

Network administrators must enforce policies to only allow packets with legitimate source addresses to enter the Internet. This rule applies to ingress (input) traffic to border routers. Restrictions should enforce that only traffic originating from addresses assigned to the network or networks directly connected to border router interfaces is forwarded.

For example, suppose ISP A (Internet Service Provider) runs router R1 connected to the Internet on its interface f0/0 and customer X is connected to interface f1/0 with an assigned IP address range x.y.z.0/24. Traffic originating from customer X is ingress to router R1 and only packets arriving at interface f1/0 with source addresses in the range x.y.z.0/24 should be forwarded. Packets containing any other source address should be dropped on that interface, not forwarded.

It is important to drop packets, instead of blocking them, to avoid producing additional traffic by the router back to the originating network segment.

RFCs and BCPs are formal documents published by the IETF (Internet Engineering Task Force). The acronym RFC means Request For Comments. These documents describe specifications, protocols, procedures and events and are the result of committee drafting and subsequent reviews by interested parties. A designation is assigned to each RFC from the following options: informational experimental, best current practice, historic or unknown. Some informational RFCs become Internet standards and further modifications are only allowed as a new document that obsoletes the previous one. RFCs with status best current practice are referred to as BCPs.

The first RFC was published in April, 7 1969 by Steve Crocker to archive notes related to the development of ARPANET.

RFC 1 – Host Software http://tools.ietf.org/html/rfc1.html

BCP documents receive two numbers, one as a RFC and another one as a Best Current Practice. For example, BCP 38 is also RFC 2827. BCPs describe guidelines, processes, methods and other subjects not suitable for a standard. As of this writing, the last BCP is 205 from July 2016.

BCP 38 has become a critical tool to help mitigate DDoS attacks. Implementing it means your devices won’t participate on attacks that employ source address spoofing. Notice that BCP 38 doesn’t protect against floods originating from valid source IP addresses.

All providers of Internet connectivity, operating or not an AS (Autonomous Systems), are highly urged to implement ingress filtering mechanisms according to BCP 38 and RFC 3704 to prohibit attackers from using forged source addresses.

Unfortunately, this is not implemented in many networks yet. Best practices are known for a long time, the first published RFC on this subject was 2267 in 1998, followed by 2827 (BCP 38) in 2000 and 3704 (BCP 84) in 2004.

RFC 2267 – Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing http://tools.ietf.org/html/rfc2267.html

RFC 2827 / BCP 38 – Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing http://tools.ietf.org/html/rfc2827.html

RFC 3704 / BCP 84 – Ingress Filtering for Multihomed Networkshttp://tools.ietf.org/html/rfc3704.html

There are distinct methods to implement ingress filtering in a network. The choice must be based on the topology and the advantages and disadvantages of each deployment option.

• • Ingress access lists: most common method that compares addresses of every packet against a list of acceptable prefixes. Its main disadvantages include the manual maintenance and size that may become large depending on the environment.

• • Strict Reverse Path Forwarding: is conceptually similar to access lists but Strict RPFs are dynamic. It is a simple and fast option for edge routers that advertise BGP prefixes. Implementation brings some challenges on networks that employ asymmetric routing or are multi-homed, requiring the usage of BGP communities to force longer internal (not advertised) AS paths.

• • An extension of Strict RPF used to solve some of the problems experienced on asymmetric routing or multi-homed networks. In simple terms, if the advertisement of a prefix is filtered, packets will be filtered as well.

• • For the presence of a route, including the default, to decide if packets should be forwarded or dropped. It doesn’t take into account where the route points to. It is in fact a route existence check. Problems with drop packets may occur on asymmetric routing environments.

• Loose Reverse Path Forwarding Ignoring Default Routes: is an explicit route check method that excludes default routes. Is useful when routes are created to cover all legitimate traffic and default routes only exist to catch bogus traffic.

The following additional scenarios must be taken into account when implementing BCP 38 or mitigating DDoS attacks:

• • Spoofed source addresses don’t have to belong to unassigned or reserved networks, like 10.0.0.0/8 or 192.168.0.0/16. In fact, attackers most frequently randomize source addresses, utilizing prefixes assigned to geographically distributed networks and even the few ranges still not assigned to any company.

    During a SYN flood attack, the targeted system sends SYN-ACK replies to what it believes to be the originating systems, looking to complete the 3-way TCP handshake. Because source addresses are spoofed, innocent systems receive unwanted traffic. Under certain circumstances, this may result in a secondary denial of service.

• • A situation that is not commonly taken into account during the mitigation of DDoS attacks is an attacker spoofing a certain network or networks, creating for example a SYN flood. The network administrator of the targeted infrastructure calls its network provider, ISP X, and decide to filter all traffic coming from the impersonated networks. The consequence of this action is users from non-hostile spoofed networks are denied access to all networks connected to ISP X, resulting in an unintentional denial of service. This unveils how sensitive is the task of blocking traffic originating from the Internet, without an appropriate assessment.

• • Network operators should log information on dropped packets to monitor suspicious activities.

  • If IPSec and AH (Authentication Header) are not enabled, spoofing IPv6 source addresses is as simple as in IPv4 [3]. Unfortunately, the IPv6 specification makes the usage of IPSec optional. Source routing would be another option for attackers, but versions 4 and 6 of the Internet Protocol have the routing header type 0 disabled by default.

References:

[1] BCP38 – http://www.bcp38.info/[2] DoS SYN flood attack – http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/100830-asa-pix-netattacks.html[3] IPv6 security brief – http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-678658.html[4] Ingress Filtering For Multihome Networks – http://tools.ietf.org/pdf/rfc3704.pdf
 
 

Protect Your Business

Malware Patrol offers a wide variety of threat intelligence feeds for use within organizations of all sizes and industries, including a real-time feed of amplification and reflection DDoS attacks that have happened in the last 24 hours. We verify our feeds constantly – every hour in most cases – to ensure they contain only actionable indicators that protect our customers against malware infections and data breaches.

For ease of use, we format the feeds for compatibility with the most popular security tools and platforms. To learn more or to request a free evaluation, you can contact us and our cybersecurity experts will get in touch with you.