DDoS that feeds on silence....or why you don't have to pay a ransom in Żabka bonds

You receive a threatening email: We've detected an issue with your network. If you pay xxxx PLN in bills from Żabka, we will add your network for immediate anti-DDoS defense. This is how the history of problems of many ISPs begins. A small extortion, but more and more operators are struggling with this type of situation. This type of attack already has a name Carpet attack and is directed in subsequent Polish ISPs. 

EPIX as a traffic exchange node should, in its assumptions, focus on a reliable and fast exchange of traffic in the L2 layer – ensure the transmission of packets between participants and provide routing information in OpenPeering. However, we cannot remain passive towards what is happening, which is why we systematically approach the problem solving of our participants. In addition to building a scrubbing center, we try to educate the community – and this article is part of it: it is a compilation of knowledge about what an attack is, an incentive to take action and sample solutions. Actually: proposals for actions that will make life difficult for attackers.

Description of the attack

We are dealing with a family attack reflection/amplification, based entirely on the very behavior of the TCP protocol – without using any vulnerability or error in the software. The attacker does not direct traffic directly at the victim; instead, he uses hundreds or thousands of legally operating web servers as unaware fenders (headlights), which also act as traffic multipliers.

The starting point is the source address spoofing. The attacker sends TCP/SYN packets, in which he substitutes the victim's IP address as the sender's address, and the addresses of servers supporting HTTP and HTTPS (ports 80 and 443) as the destination address. From the point of view of such a server, this looks like the most ordinary attempt to establish a connection: according to the specification, it sends the SYN/ACK packet back, starting tripartite reconciliation (Handshake),

And this is where the crux of the problem comes in. The victim never initiated this connection, so even if the SYN/ACK reaches a working host, their TCP stack will not find a matching entry in the array. It is worth noting, however, that naked tCP stack (Linux, Windows) in this situation by default conforms the RST package and it is this RST that would interrupt the entire mechanism. So why does the attack work?

The answer lies in the reality of carrier networks, to which this attack is tailored. First, a single host is rarely the victim; the target is usually entire, large address classes, including ranges not used or allocated, but not occupied by any active device. SYN/ACK packages then go to Black Holes: there is no one to reject them, there is no one to respond with RST. From the perspective of the reflector-server, it looks identical to a packet lost on the network, so, exactly as the protocol dictates, it resumes transmission. And again. And again.

Secondly, even where real hosts are hidden at the victim's address, NAT and edge devices are common in carrier networks, which unexpected, unsuitable for any session simply quietly drop traffic instead of sending RST. The effect is the same as with a black hole: no response that the reflector could interpret as the end of the connection, and therefore retransmission after retransmission.

Each such retransmission is another packet landing in the victim's network. Depending on the configuration of the TCP stack on the multiplier server side, the cycle is usually repeated 6 to 12 times before the connection is finally abandoned. A single contrived package sent by the attacker turns into a dozen or so packages hitting the victim, sent not by the attacker himself, but by reliable WEBSITES scattered throughout Poland. The result is millions of packets flooding the victim's link, coming from addresses that are perfectly legal in themselves.

This is the perfidy of this attack: there is no simple method of defense against it. Traffic cannot be simply filtered by the source address, because it flows from real HTTP(S) servers – by blocking it, the victim would cut off their own legitimate web traffic. The blockade after the port will not help either, because it is the same port where normal communication with the parties takes place.

A real solution remains a stateful firewall (stateful firewall) set on the edge of the victim's network. It tracks the status of connections and knows which ones were actually initiated from the inside. When a SON/ACK arrives that does not match any entry in the call table, instead of silently rejecting it, he sends back the TCP/RST packet. This RST is a clear signal to the reflector server that there is no connection and will not be – which immediately interrupts the retransmission chain and eliminates the multiplication effect at the source.

How can we defend ourselves?

In fact, the only real defense is the hygiene of your own network. And yes, just because your network is not under attack at the moment does not mean that the zombie computers in your scope, which are part of the botnet, are not attacking other operators right now. This type of attack can only be cut at the source: by blocking the sending of spoofed packets. And it is you, the operators, who have both the tools and the knowledge of what should come out of your networks and what should not.

The fact that you are not under attack at the moment – and attacking others does not bother you – does not mean that tomorrow your network will not become a target and you will have a problem. The saddest thing is that the relevant document has existed for a quarter of a century. In May 2000 – 26 years ago – RFC 2827 (also known as BCP 38) was created, which directly describes how to configure carrier networks to prevent impersonation of source addresses. In practice, it comes down to filtering outgoing traffic (ingress filtering on the customer's edge) – often implemented by the uRPF mechanism – so that only packages with source addresses actually belonging to it can come out of a given range. This is a bit of an analogy to vaccination, by implementing solutions from BCP 38 at home, we strengthen the resilience of the entire Polish cyberspace. 

With small networks, having several or several dozen prefixes, the whole operation takes several minutes and does not noticeably affect the load on modern routers. And this is our common, social defense method – working before anyone is attacked. The more networks implement it, the fewer places spoofing can come from. 

Attack in progress?

It's not so rosy here anymore. As I mentioned earlier, a properly configured firewall or TCP stack – one that sends RST to an out-of-state SYN/ACK instead of silently dropping it – should cope with the attack. However, I know from experience that theory goes hand in hand with practice. Most consumer ONTs and routers do NATs to a user's network and are usually vulnerable to this attack: silently dropping packets unrelated to any session they know, rather than responding with a reset. This is a real problem on which the operator has limited influence.

So what remains during the attack? First, if you have a lot of unused prefixes, just don't advertise them; what's not in the routing tables won't get reflected traffic. Second, direct the addressing ranges you don't use to the TCP/RST referral firewall rules, exactly as described in the sections below. However, be careful here: a mass-generating RST device can itself become a spotlight for another attack, so such a rule must be limited to its own, unoccupied ranges and not respond to traffic from outside them.

And finally, NAT on your devices – you are not completely defenseless here either.

Protection of inactive ranges in the BNG (brass) /PPPoE network

Since the attack feeds on silence – the lack of RST where the packet goes to an unoccupied address – the most effective defense is to turn any such black hole in a device that consciously responds with a reset to an unexpected SYN/ACK. In the PPPoE terminated BNG/BRAS operator network, this can be done extremely elegantly, because the infrastructure itself provides the ready signal address is active: presence of a host route/32.

The mechanism is based on the longest-prefix match rule. When the client's PPPoE session gets up, BNG installs a route /32 for his address indicating the subscriber's interface (framed route). When the session rains – this route /32 disappears. For the entire address pool of subscribers (e.g. /20), we maintain the route covering – less detailed – directing traffic to the firewall or a dedicated RST referral server. The distribution of traffic then happens automatically, without any additional logic:

• active address – a more detailed route /32 with BNG wins, the traffic goes to the customer;
• address inactive – none /32, so the covering route wins and the traffic lands on the reset sending device.

So instead of directing the unused address space in null-route (a classic black hole that is silent and thus drives the retransmissions of the reflector), we direct it to where every out-of-state SON/ACK will meet with RST. And because attacks of this type target large, rarely planted ranges, we hit exactly the middle of the vector.

Dedicated server-responder

Role RST-Responder it can perform the edge firewall itself, but you can also put a machine dedicated to this task next to it – a kind of controlled victims to attack, which takes over all the traffic to dead addresses. In both variants, the key mask, not a metric: it is the less detailed prefix (e.g. /20 versus /32 of the active customer) that makes the responder by definition only get traffic to unoccupied addresses. The metric determines something else – competition between routes of the same length – so it is useful only for redundancy (firewall as the basic route, server as a backup announcing the same prefix with a worse metric), and not for the selection itself active versus inactive.

However, there is a trap here that can destroy the whole idea. Bare system stack responds with RST to unexpected SYN/ACK only if the packet is addressed to its own local IP address. In this scenario, the SYN/ACK flies to the client's address from the pool /20 – an address that the server does not have. If the route simply indicates the server as next-hop, the machine will see the foreign destination address and either try to forward the packet further or reject it as martian – under no circumstances will it generate a reset. In other words: placed barefoot the server will just be another black hole.

In order for the responder to actually reset, it must embrace the entire pool as your own. In practice, this means configuring the entire range as local on this machine and a default-deny policy with an explicit reset – on Linux REJECT -reject-with tcp-reset (iptables/nftables) – or using a dedicated responder or tarpit listening on the entire prefix and generating RST. This is a conscious configuration, not Adverse effect bare stack, and it is this distinction that determines whether the solution works or just gives the impression.

Dimensioning and scope of protection

Two things are worth having in the back of your head before such a construction goes into production. First, the responder becomes the outlet of the attack: all reflected traffic to inactive addresses is focused on one node. RSTs themselves are tiny and stateless, so generating them is cheap – but receiving millions of packets per second is already a matter of PPS performance, interrupt handling, and network adapter, not bandwidth. An ordinary server has its ceiling here; in a serious attack, you either have to reach for generating RST in the kernel (XDP/eBPF, in front of the entire network stack), or take into account that the responder will also fail under load – and then silence will occur again instead of a reset. Therefore, this victim to attack must be dimensioned under real volume, not staked as a spare.

Second, this technique specifically closes the gap blackhole on unoccupied rangesand not the whole problem. A subscriber with an active session has its route /32, so the reflected SYN/ACK will normally be delivered to it by BNG – and the multiplication has to be handled by its CPE, which, as we have established before, usually silently drops traffic behind NAT. The protection of inactive ranges and the defense of active customers are therefore two complementary elements, not substitutes.

Configuration examples

We return here to the announced defense NAT on your devices. The following examples relate precisely to nAT performing operator equipment (edge BNG, CGNAT, router/firewall translating subscriber traffic) – not an abstract firewall on the side. This is important, because NAT is based on the conntrack / session table anyway; so since the device is already tracking sessions for translation, it can be induced to respond to a packet outside this table with a reset instead of a silent drop. The NAT RST itself does not send – it is done by the state module on the same device.

So the whole defensive thesis comes down to one thing: the NAT device has an out-of-state SYN/ACK reply with RST, and not quietly sprinkle it. Below are specific projects on three popular platforms plus a variant with a dedicated server-responder. It is worth noting right away that platforms differ fundamentally here – from a mechanism directly created for this task (Juniper) to one that targets something else and requires a workaround (Cisco).

Juniper SRX

The cleanest case – Junos has a dedicated option that sends an RST in response to a TCP segment with any flag other than a pure SON if it does not match any existing session. Exactly the reflector scenario:

set security flow tcp-session tcp-rst

The decision is made on the path first path flow support: the incoming SYN/ACK does not create a session (because it is not a SYN package), so instead of a silent drop, the device sends the RST to the sender – i.e. to the reflector server. By default, the function is disabled, it must be enabled explicitly.

MikroTik (RouterOS)

Here, the implementation is based on a filter rule rejecting motion in an invalid state with an explicit reset. The hook concerns the classification of the state: with default loose-tcp-tracking =yes the wandering SON/ACK can be marked as new instead of invalid and bypass the rule. That's why we're tightening call tracking first:

/ip firewall connection tracking set loose-tcp-tracking=no
/ip firewall filter add chain=forward protocol=tcp connection-state=invalid \
    action=reject reject-with=tcp-reset

After this change, the TCP packet not matching any entry in the conntrack enters the invalid state, and the rule sends back the tcp-reset, giving the reflector an unambiguous signal of the end of the connection.

Cisco ASR (IOS-XE / ZBFW)

This is a case where you need to be careful. Feature TCP Reset Segment Control w parameter-map type inspect nie is used to reset packets outside the session – sends RST only at the time of deleting (expiration) sessions half-open, half-close or idle, after the appropriate timer has expired:

parameter-map type inspect pmap-name
 tcp synwait-time 10
 tcp half-open reset on
 tcp idle reset on

The default behavior of ZBFW for a packet that does not fit any session is silent policy drop (class-default), without RST. In other words: on ASR, the above configuration will speed up the cleaning of half-open sessions and send them a reset after the timer, but will not respond with a reset charged immediately to the wandering SON/ACK from the spotlight – and that's what this attack is all about. On this platform, a more reliable solution is to direct the unoccupied ranges to a dedicated server-responder (below), and the ZBFW configuration itself for stray SYN/ACK should be verified in the lab on a specific version of IOS-XE.

Dedicated server-responder (Linux)

The most predictable variant, independent of the specificity of the vendor. The machine must first embrace the entire pool as a local one – otherwise, as discussed above, it will itself become a black hole. On Linux, the local route (AnyIP) is used for this, which makes the kernel treat the entire range as its own addresses:

ip route add local 198.51.100.0/24 dev lo

Then the default-deny policy with an explicit reset for traffic outside the existing (initiated from the inside) sessions. Since this host never initiates calls to these addresses by itself, each incoming SYN/ACK is by definition unexpected and gets reset:

# nftables
table inet responder {
    chain input {
        type filter hook input priority 0; policy drop;
        ct state established,related accept
        ct state invalid tcp reset
        tcp flags & (syn|ack) == syn|ack ct state new reject with tcp reset
    }
}

With a very large volume, even this has a stack performance ceiling – then RST generation moves to the kernel before the proper network stack (XDP/eBPF), allowing you to respond with a much higher PPS.

Firewall from Żabka – is it worth paying the ransom?

Let's go back to the threatening email we started with for a moment. Its authors are counting on you to pay – because you think that you have no choice and that the defense is out of your reach. Meanwhile, this whole attack feeds on one thing: silence. The silence of the server-reflector, which does not get RST and retransmits. The silence of a black hole on an unoccupied range. The silence of CPE, which quietly drops behind NAT. And – at the very source – the silence of networks that allow spoofed packets to leave, because no one has configured filtering.

Each of these silences can be broken, and tools have been in existence for years: a stateful firewall referencing TCP/RST, conscious management of unused prefixes, a responder on blind spots, and above all – outbound traffic filtering according to RFC 2827. None of these solutions require paying a ransom in bonds. It requires something that the criminal will not sell you: a dozen or so minutes of work and a little community responsibility.

And that's the point. Defending against this attack is not a solo game. Your properly configured network protects not only you – it protects everyone else, because one less source of spoofing means less ammunition for attackers throughout Poland. It also works the other way around: you use the hygiene of other operators. The more of us, the tighter the attacker.

What can you do today?

• Implement outbound filtering (RFC 2827 / BCP 38). On the edge of your own network, make sure that only packages with source addresses that actually belong to you can leave each range – simply by using the uRPF mechanism. This is the most important item on this list.
• Don't post prefixes you don't use. What is not in the routing tables, it will not attract reflected traffic. A more nasty solution is to prepare a quick path to disable broadcasting of unused prefixes in the event of detecting an attack – this action will burn some of the attacker's resources. 
• Configure the state firewall/NAT to send back TCP/RST on packets outside the session board, instead of silently dropping them – following the examples for your platform above.
• Refer unoccupied ranges to RST referral responder, remembering to limit it only to your own addresses and not become a spotlight for someone else.
• Close ports 80 and 443 on externally available ONTs/CPE subscribers – Your network will not be an attack multiplier. 
• See if you're part of the problem yourself. Verify that there is no traffic coming from your network with spoofed source addresses – even if no one is attacking you today.

Don't wait for your network to become a target. The best time to implement these changes was 26 years ago, when RFC 2827 was created. The second best is now. 

Have questions, need setup support, or want to talk about protecting your network? Talk to us! – as an EPIX community, we are here to make life difficult for attackers.

Related posts

Thinking about cybersecurity, don't forget about tSEC