To understand how to protect your services nowadays, we have to know how attackers work and what common methods they use to damage your infrastructure.

In 2026 there is a huge number of different botnets, mostly originating from India, Brazil, Russia, China and North Korea. The devices vary greatly and can include poorly protected cloud servers, users’ machines, and private office networks. However, the vast majority of devices come from the IoT segment. Most of them are IP cameras with default credentials, outdated firmware, or no security whatsoever. That said, IoT devices can be extremely diverse — smart teapots, refrigerators, and any other device that can connect to the Internet and has security vulnerabilities. The largest botnets can contain millions of devices and generate terabits of traffic per second. At the time of this article’s publication, the largest recorded attack came from the Aisuru botnet — 31.4 Tb/s.

Attacks are not limited to infected devices alone. Reflection and amplification techniques are also widely used. A reflection attack is named so because infected devices do not send traffic directly to the target. Instead, they send packets with a spoofed destination IP address to third-party services. These services then send their replies directly to the victim. This approach hides the real source of the attack and allows significant traffic amplification, since one compromised device can query many third-party servers. The main problem is that such traffic appears legitimate because it originates from real, trusted services.

Attackers can also exploit specific weaknesses in the target’s software. Some server-side applications may suffer from buffer overflows, race conditions, or inefficient resource usage, such as extreme memory consumption, CPU overload, or excessive disk I/O. Any of these issues can cause the service to stop responding. Attackers often scan the target beforehand to discover such vulnerabilities and then exploit them — either before or during the main volumetric attack. For example, during an attack you may notice sudden huge traffic that constantly changes protocols, destination ports, or the pattern of incoming data.

At first glance, protecting against all these threats seems very difficult. It is. But it is not impossible.

XFW includes various protection mechanisms, some of which are activated automatically when protection is enabled. For instance, malformed IPv4/IPv6 packets and fragmented packets are filtered out by default. Bad packets may have a missing source IP, incorrect headers, or even unknown L2 protocols.

XFW also filters UDP anomalies by default — missing source or destination ports, bad headers such as incorrect packet size, and so on. To enable basic protection it is enough to run:

xfw {}

You can check which problems were detected using the following metrics: xfw_udp_badhdr_ingress_bytes, xfw_udp_badhdr_ingress_packets, xfw_ip4_fragmented_ingress_bytes, xfw_ip4_fragmented_ingress_packets, xfw_l2_unknown_ingress_packets, xfw_l2_unknown_ingress_bytes

TCP attacks come in many variations, but most share recognizable patterns — broken packets with invalid headers, SEQ=0 during connection establishment, missing TCP options, and others. XFW provides the tcp_anomaly_filter to catch them. For more details see the article: Filtration rules — TCP Anomaly Filter

xfw {
   tcp_anomaly_filter;
}

Useful metrics for this filter include xfw_tcp_anom_syn_no_options_bytes, xfw_tcp_anom_syn_no_options_packets and other.

Another important protection concerns TCP reflection attacks. Due to the three-way handshake, during a TCP reflection attack a third-party server sends a SYN-ACK to the target even though no connection was initiated. Similar behavior occurs with RST packets arriving from sources the server was never connected to. The tcp_auth_filter drops such illegitimate TCP packets:

xfw {
   tcp_auth_filter;
}

Keep in mind that enabling this filter may drop already established connections, requiring users to reconnect. You can monitor this via the metrics xfw_tcp_auth_failed_bytes and xfw_tcp_auth_failed_packets.

XFW offers a very useful mechanism — tcp_syncookies. It leverages the Linux kernel to detect SYN floods and handle them efficiently using SYN cookies. For more details about filter modes and timers, see the article: Filtration rules — TCP SYN cookies

xfw {
   tcp_syncookies passive_timer=1 flood_timer=1;
}

The tcp_flags filter gives you finer control over SYN and RST flags. You can set rate limits on these packets. Attackers often open many connections quickly or abruptly close them to increase memory consumption. If you know your normal traffic patterns, you can configure SYN/RST limits proportional to your typical active connections:

xfw {     
    ratelimit=syn_rl pps=1000 bps=1000000;
    tcp_flags syn: ratelimit=syn_rl;

    ratelimit=rst_rl pps=1000 bps=1000000;
    tcp_flags rst: ratelimit=rst_rl;
}

Related metrics: xfw_syn_rate_limited_bytes, xfw_syn_rate_limited_packets, xfw_rst_rate_limited_bytes, xfw_rst_rate_limited_packets.

ICMP traffic is frequently used in reflection attacks because it is easy to exploit. It is recommended to block all incoming ICMPv4 traffic and apply strict limits to ICMPv6:

xfw {
    defaults { icmp ip4: block; icmp ip6: block;}
}

If your services use IPv6 or rely on ping for health checks, you should allow specific ICMPv6 message types using rate limiting:

xfw {
    ratelimit=icmp_rl pps=10 bps=1000;
    icmp ip4 : ratelimit=icmp_rl { 0, 3, 8, 11, 12 }
    icmp ip6 : ratelimit=icmp_rl { 1, 2, 3, 4, 128, 129, 133, 134, 135, 136, 137, 143 }
}

Associated metrics: xfw_icmp_default_blocked_bytes, xfw_icmp_default_blocked_packets

The final layer of protection is general rate limiting. Some attack traffic may look completely legitimate — packets are valid and contain normal data. The only suspicious thing is that identical or very similar traffic arrives simultaneously from millions of different devices. If your network and NIC can handle the volume, XFW can still protect your applications by blocking unexpected traffic and applying strict rate limits to your services:

xfw {
    # Block by default all Incoming traffic
    defaults { 
        src_port ip4: block;
        src_port ip6: block;
    }

    # Ratelimit the APP
    ratelimit=whitelisted_rl pps=<YOUR_PPS> bps=<YOUR_BPS>;
    dst=MY_UDP_APP ip4.udp : ratelimit=whitelisted_rl {
         MY_HOST:MY_PORT
    }

    # Restricted whitelist sources

    # Block all system and user ports, allow only dynamic + services that host uses
    ratelimit=regular_clients_rl pps=<YOUR_PPS> bps=<YOUR_BPS>;
    src=apps_tcp ip4.tcp : ratelimit=regular_clients_rl {
        :32768-65535,
        :22,
        :80,
        :443,
        ...
    }
    src=apps_udp ip4.udp : ratelimit=regular_clients_rl {
        :32768-65535,
        :53,
        ...
    }
}

Each environment has its own infrastructure, applications, and requirements. XFW provides a wide range of instruments to configure protection that fits exactly your setup.

Based on the situations described above, here are some common recommendations for your protection

xfw {

    # Anti DNS-Reflection
    dns_filter;

    # Anti TCP Broken Packets
    tcp_anomaly_filter;

    # Anti SYN-ACK, RST Flood
    tcp_auth_filter;
    
    # Anti SYN Flood
    tcp_syncookies passive_timer=1 flood_timer=1;

    # Ratelimit the APP
    ratelimit=whitelisted_rl pps=<YOUR_PPS> bps=<YOUR_BPS>;
    dst=MY_TCP_APP ip4.tcp : ratelimit=whitelisted_rl {
         MY_HOST:MY_PORT
    }
    
    # Anti SYN Flood
    ratelimit=syn_rl pps=<YOUR_PPS> bps=<YOUR_BPS>
    tcp_flags syn : ratelimit=syn_rl;

    # Anti RST Flood
    ratelimit=rst_rl pps=<YOUR_PPS> bps=<YOUR_BPS>
    tcp_flags rst : ratelimit=rst_rl;
}

xfw {
    defaults {
        dst: allow;
        icmp ip4: block;
        icmp ip6: block;
        src_port ip4: block;
    }

    # Anti DNS-Reflection
    dns_filter;

    # Anti TCP Broken Packets
    tcp_anomaly_filter;

    # Anti SYN-ACK, RST Flood
    tcp_auth_filter;
    
    # Anti SYN Flood
    tcp_syncookies passive_timer=1 flood_timer=1;

    # Ratelimit the APP
    ratelimit=whitelisted_rl pps=<YOUR_PPS> bps=<YOUR_BPS>;
    dst=MY_TCP_APP ip4.tcp : ratelimit=whitelisted_rl {
         MY_HOST:MY_PORT
    }
    
    # Anti SYN Flood
    ratelimit=syn_rl pps=<YOUR_PPS> bps=<YOUR_BPS>
    tcp_flags syn : ratelimit=syn_rl;

    # Anti RST Flood
    ratelimit=rst_rl pps=<YOUR_PPS> bps=<YOUR_BPS>
    tcp_flags rst : ratelimit=rst_rl;

    ratelimit=whitelisted_4gb_rl pps=2863311 bps=4294967295;
    ratelimit=icmp_rl pps=10 bps=1000;

    # Ratelimited ICMP
    icmp ip4 : ratelimit=icmp_rl { 0, 3, 8, 11, 12 }
    icmp ip6 : ratelimit=icmp_rl { 1, 2, 3, 4, 128, 129, 133, 134, 135, 136, 137, 143 }

    # Restricted whitelist sources

    # Block all system and user ports, allow only dynamic
    ratelimit=regular_clients_rl pps=<YOUR_PPS> bps=<YOUR_BPS>;
    src=apps_tcp ip4.tcp : ratelimit=regular_clients_rl {
        :32768-65535,
        :22,
        :80,
        :443,
        ...
    }
    src=apps_udp ip4.udp : ratelimit=regular_clients_rl {
        :32768-65535,
        :53,
        ...
    }
}

xfw {
    # Anti DNS-Reflection
    dns_filter;
    
    # Ratelimit the APP
    ratelimit=whitelisted_rl pps=<YOUR_PPS> bps=<YOUR_BPS>;
    dst=MY_UDP_APP ip4.udp : ratelimit=whitelisted_rl {
         MY_HOST:MY_PORT
    }
}

xfw {
    defaults {
        dst: allow;
        icmp ip4: block;
        icmp ip6: block;
        src_port ip4: block;
    }

   # Block by default all Incoming traffic
   defaults { 
        src_port ip4: block;
    }

    # Anti DNS-Reflection
    dns_filter;
    
    # Ratelimit the APP
    ratelimit=whitelisted_rl pps=<YOUR_PPS> bps=<YOUR_BPS>;
    dst=MY_UDP_APP ip4.udp : ratelimit=whitelisted_rl {
         MY_HOST:MY_PORT
    }

    # Ratelimited ICMP
    icmp ip4 : ratelimit=icmp_rl { 0, 3, 8, 11, 12 }
    icmp ip6 : ratelimit=icmp_rl { 1, 2, 3, 4, 128, 129, 133, 134, 135, 136, 137, 143 }

    # Restricted whitelist sources

    # Block all system and user ports, allow only dynamic + services that host uses
    ratelimit=regular_clients_rl pps=<YOUR_PPS> bps=<YOUR_BPS>;
    src=apps_tcp ip4.tcp : ratelimit=regular_clients_rl {
        :32768-65535,
        :22,
        :80,
        :443,
        ...
    }
    src=apps_udp ip4.udp : ratelimit=regular_clients_rl {
        :32768-65535,
        :53,
        ...
    }
}