Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

["Jean | ddostest.me via NANOG" <nanog () nanog org>]

Maybe we're looking at the wrong place when dealing with TCP amp. I 
believe there is a much easier way to solve this.

@OP: can you post the tcp flags of the SYN/CK you are receiving from Sony?

Thanks

Jean

On 2020-01-27 20:49, Damian Menscher via NANOG wrote:
> On Mon, Jan 27, 2020 at 5:43 PM Töma Gavrichenkov <ximaera () gmail com 
> <mailto:ximaera () gmail com>> wrote:
>
>     On Tue, Jan 28, 2020, 4:32 AM Damian Menscher <damian () google com
>     <mailto:damian () google com>> wrote:
>
>         On Mon, Jan 27, 2020 at 5:10 PM Töma Gavrichenkov
>         <ximaera () gmail com <mailto:ximaera () gmail com>> wrote:
>
>             If this endpoint doesn't connect to anything outside of
>             their network, then yes.
>             If it does though, the design of the filter might become
>             more complicated.
>
>
>         Not really... just requires sorting by volume.  Turns out most
>         legitimate hosts don't send high-volume syn packets. ;)
>
>
>     This is a good *detection* technique, but you cannot filter by
>     volume in transit if the set of destinations is large (and random)
>     enough, and you don't have a time machine.  Not sure if this is
>     the case but might as well be.
>
>
> They don't need to filter by destination.  Once a problem customer has 
> been identified, they can apply an ACL restricting them to only 
> originate IPs they own.  This was all covered in my talk at NANOG last 
> year: 
> https://pc.nanog.org/static/published/meetings//NANOG76/daily/day_2.html#talk_1976
>
>     As for the detection of the real source, everything is technically
>     possible but you need certain bargaining power which a
>     medium-sized (at best) VPN service probably doesn't have.
>
>
> True, but there are ways around that, including public shaming (here), 
> or involving law enforcement.
>
> Damian