Hmm, I doubt this is the output of TCP amplification since Jim reported it as SYN spoofing, i.e., SYN packets, not SYN-ACK packets (as for typical TCP amplification). Unless the given _hosts_ respond with multiple SYN-ACKs in which case these may be experiments by an attacker to measure if these IP:ports could be abused as TCP amplifiers.
Clarifying for those unfamiliar with this attack:
- Attacker is sending SYN packets spoofed "from" NL to Jim (and others)
- Jim (and others) have applications listening on those ports and respond with SYN-ACK packets to the victim in NL
- When the victim (NL) fails to complete the handshake (which they didn't initiate!) Jim (and others) sends another SYN-ACK
So they're not probing to see if Jim (and others) are abusable as TCP amplifiers... they've already determined they can be abused and are using those machines to conduct an actual attack against victims in NL.
Damian
On Sat, Aug 17, 2019 at 6:18 PM Damian Menscher via NANOG <
nanog@nanog.org> wrote:
I'm seeing slow-motion (a few per second, per IP/port pair) syn flood
attacks ostensibly originating from 3 NL-based IP blocks: 88.208.0.0/18
, 5.11.80.0/21, and 78.140.128.0/18 ("ostensibly" because ... syn flood,
and BCP 38 not yet fully adopted).
Is anybody else seeing the same thing? Any thoughts on what's going on?
Or should I just be ignoring this and getting on with the weekend?
This appears to be a TCP amplification attack. Similar to UDP amplification (DNS, NTP, etc) you can get some amplification by sending a SYN packet with a spoofed source, and watching your victims receive multiple SYN-ACK retries. It's a fairly weak form of attack (as the amplification factor is small), but if the victim's gear is vulnerable to high packet rates it may be effective.
The victim (or law enforcement) could identify the true source of the attack by asking transit providers to check their netflow to see where it enters their networks.
Damian