syn flood attacks from NL-based netblocks

Sat Aug 17 22:35:55 UTC 2019

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.

But, at least if these IP:ports do not amplify, I suspect it's more likely
that, as Töma wrote, this is simply result of some learning-experiment by
students (or by wanna-be hackers).

Yes, such (unethical, unprofessional) experimentation happens, and can be
easily confused with some clever new attack... which is a pity since we
always like to learn of new attacks!

Of course one (i.e., Jim) could try to trace back and find the source
(likely spoofer) but it seems quite likely to be some students or script
kiddies, which may be underwhelming...
-- 
Amir

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/6de07332/attachment.html>