Juniper MX + IX + SynFlood

In this article, I would like to talk about one fairly simple method of protection against Syn Flood attacks on Juniper MX series routers. This method can help with several conditions, which are described below. Of course, there are hardware and software solutions, technologies Syn Cookies , Syn Proxy and others. But, sometimes, it turns out that most of the traffic is blocked on the router without the use of additional mechanisms or expensive devices. Since we used to configure some articles of our colleagues for the router, we decided to share our experience, it is quite specific, but we hope it will be useful. An example of such an attack is shown in the chart below.

Some theory

Syn Flood is one of the types of network attacks such as denial of service, which consists in sending a large number of SYN requests in a relatively short time. The SYN packet itself is small in size (with data link headers of 54+ bytes), even with a 1G band, you can generate a large number of packets per second. Some providers do not prohibit sending packets with a substitute source address from their network, and even one server with a 1G band hosted by such a provider can generate an attack that creates many problems. Most Internet providers for end users do not release packages from their network with a fake source address and, as a result, most of the attacks are coming from DC’s clients, while the number of attacking machines is small.

What can be done on the Router?

Initially, we need to proceed from the fact that we have good connectivity and many traffic exchange points are connected. Of course, if you have a single UPLINK and, suppose, Syn Flood comes from the same machine, you can try to analyze the traffic, and if the person who organizes the DDOS is completely lazy and has not taken care of different ttl , you can block traffic by ttl + dst ip. In this case, all traffic with the current ttl will be cut off - this is certainly better than if the server was lying completely, but not optimally.

Currently, in my work, in addition to backbone providers and providers providing incomplete connectivity, such traffic exchange points are connected, such as:
')

• DataIX
• Cloud IX
• Pirix
• WIX
• Spbix
• Mskyx
• Codix
• Globalix
• Ihome

Quite a large number of providers, data centers and service providers are connected to data IX . Most of them provide L2 connectivity between participants. Using these facts, you can simply locate the source of the attack if traffic goes through IX.

How to do it

Initially, you need to connect IX to a separate virtual-switch - to be able to filter by MAC addresses. That is, even if the src address is changed, the packets will come with the src MAC address of the border router. For example, we can assume that we only connected DataIX and the anomalous traffic goes through it.


Then you can see the MAC addresses that came from this IX:

  root @ rt01> show bridge mac-table
 MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
            SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)

 Routing instance: switch_dataix
  Bridging domain: switch_dataix_bridge, VLAN: 20
    MAC MAC Logical NH RTR
    address flags interface Index ID
    00: 01: e8: a3: ed: 20 D, SE xe-0/3 / 0.0      
    00: 03: fe: 0a: ac: 00 D, SE xe-0/3 / 0.0      
    00: 04: 80: f4: bc: 00 D, SE xe-0/3 / 0.0      
    00: 04: 96: 51: ba: 84 D, SE xe-0/3 / 0.0      
    00: 04: 96: 52: 05: a4 D, SE xe-0/3 / 0.0      
    00: 04: 96: 52: 05: ea D, SE xe-0/3 / 0.0      
    00: 04: 96: 52: 06: 14 D, SE xe-0/3 / 0.0      
    00: 04: 96: 6d: 13: a9 D, SE xe-0/3 / 0.0      
    00: 04: 96: 6d: 14: 79 D, SE xe-0/3 / 0.0      
    00: 04: 96: 6d: 17: 79 D, SE xe-0/3 / 0.0      
    00: 04: 96: 6d: 52: 3e D, SE xe-0/3 / 0.0      
    00: 04: 96: 6d: 5b: 26 D, SE xe-0/3 / 0.0      
    00: 04: 96: 6d: 6f: f0 D, SE xe-0/3 / 0.0      
    00: 04: 96: 7d: bf: 68 D, SE xe-0/3 / 0.0      
    00: 04: 96: 7d: f8: 99 D, SE xe-0/3 / 0.0      
 ... 

And based on this data, you can create a filter that will count the number of packets that came from the MAC address to the server being attacked:

  filter ix_mac_filter {
     term 00: 01: e8: a3: ed: 20 {
         from {
             source-mac-address {
                 00: 01: e8: a3: ed: 20/48;
             }
             ip-destination-address {
                 # address of the attacked server
             }
         }
         then {
             count 00: 01: e8: a3: ed: 20;
             accept;
         }
     }
     term 00: 03: fe: 0a: ac: 00 {
         from {
             source-mac-address {
                 00: 03: fe: 0a: ac: 00/48;
             }
             ip-destination-address {
                 # address of the attacked server
             }
         }
         then {
             count 00: 03: fe: 0a: ac: 00;
             accept;
         }
     }
     term other {
         then {
             count other;
             accept;
         }
     } 

Judging by the documentation in the Juniper MX series routers, there is a limit of 1024 rules with the counter action, but we did not rest on this limit. We reset the state of the counters in this filter and after some time (1-2 minutes) we look at the result:

  root @ rt01> clear firewall filter ix_mac_filter  
 root @ rt01> show firewall filter ix_mac_filter                               

 Filter: ix_mac_filter                                          
 Counters:
 Name Bytes Packets
 00: 01: e8: a3: ed: 20 142632382856 288079929
 00: 02: 4a: 2f: a0: 1a 5159885 75880
 00: 03: fe: 0a: ac: 00 14915791420 72085522
 00: 04: 96: 6d: 6f: f0 2508125168 35985837
 00: 04: 96: 7d: f8: 99 362692758 5352205
 00: 04: 96: 82: 4d: 57 216046092 2851369
 ... 

And, if there is an anomaly, we look at what IP address is associated with this MAC address, then we see who owns it, and, if it is not a gateway, set the reject policy. Thereby minimizing the effects of the attack.

Of course, this is not a panacea, part of the Internet is blocked, but, in most cases, it is data center boarders - they are not our traffic consumers. The blocking is quite simple and, for example, if there are no other means, this protection is fully justified. When the process is fully automated, it allows you to understand where the attack is coming from and whether several teams can handle it, which greatly simplifies life.

ps After installation in one DPCe and MPC chassis, this scheme began to work not quite correctly, some of the packets in the filter just do not appear. If someone tells you why, I will be grateful.