Thanks for following up, and for publishing two bits of key data:
  - This was part of a larger attack campaign that included CLDAP
amplification
  - The SYN/ACK amplification resulted in 208Mpps (or more)

Some additional questions, if you're able to answer them (off-list is fine
if there are things that can't be shared broadly):
  - How large was the CLDAP amplification attack?  What was the packet rate
of the initial fragments?
  - The post suggested that the 208Mpps saturated some links.  Did it cause
other problems as well?
  - Was the attack referred to law enforcement?
  - Were any transit providers asked to trace the source of the spoofing to
either stop the attack or facilitate the law enforcement investigation?

Damian

On Wed, Aug 21, 2019 at 12:44 PM Töma Gavrichenkov <xima...@gmail.com>
wrote:

> Peace,
>
> Here's to confirm that the pattern reported before in NANOG was indeed a
> reflection DDoS attack. On Sunday, it also hit our customer, here's the
> report:
>
>
> https://www.prnewswire.com/news-releases/root-cause-analysis-and-incident-report-on-the-august-ddos-attack-300905405.html
>
> tl;dr: basically that was a rather massive reflected SYN/ACK carpet
> bombing against several datacenter prefixes (no particular target was
> identified).
>
> --
> Töma
>
> On Sat, Aug 17, 2019, 1:06 AM Jim Shankland <na...@shankland.org> wrote:
>
>> Greetings,
>>
>> 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).
>>
>> Why is this syn flood different from all other syn floods? Well ...
>>
>> 1. Rate seems too slow to do any actual damage (is anybody really
>> bothered by a few bad SYN packets per second per service, at this
>> point?); but
>>
>> 2. IPs/port combinations with actual open services are being targeted
>> (I'm seeing ports 22, 443, and 53, just at a glance, to specific IPs
>> with those services running), implying somebody checked for open
>> services first;
>>
>> 3. I'm seeing this in at least 2 locations, to addresses in different,
>> completely unrelated ASes, implying it may be pretty widespread.
>>
>> 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?
>>
>> Jim
>>
>

Reply via email to