syn flood attacks from NL-based netblocks

Sat Aug 17 22:56:19 UTC 2019

On Sat, Aug 17, 2019 at 3:36 PM Amir Herzberg <amir.lists at gmail.com> wrote:

> 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 at nanog.org>
> wrote:
>
>> On Fri, Aug 16, 2019 at 3:05 PM Jim Shankland <nanog at shankland.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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190817/5b3c3a22/attachment.html>