Scanning activity from 2620:96:a000::/48

Tue Jul 6 10:51:51 UTC 2021

As mentioned, rando traffic is part and parcel of being internet connected.
There isn't much 'ok' or 'not ok' to it. At this point of the internet's
lifecycle, it is incumbent on all operators to protect themselves as much
as possible from potential malfeasance or unintended technical oopsies.

That being said, the public records for the originator look pretty sketch.
Contact address is a USPS Post Office in Maryland, ARIN entries only a few
months old, website is 'Look at these studies about internet research'!
Probably not missing anything to nuke them at your edge, or honeypot them
if you're nerd curious.

On Tue, Jul 6, 2021 at 6:46 AM Tore Anderson <tore at fud.no> wrote:

> * Dobbins, Roland
>
> > Scanning is part of the ‘background radiation’ of the Internet, and it’s
> performed by various parties with varying motivations.  Of necessity, IPv6
> scanning is likely to be more targeted (were your able to discern any rhyme
> or reason behind the observed scanning patterns?).
>
> The pattern appears to be sending a bunch of ICMPv6 pings to a random
> adresses
> within the same /104. The last 24 bits of each destination address appears
> randomised in each ping request, that is.
>
> I don't know if they move on to another /104 after they were done with the
> first one and so forth.
>
> > iACLs, tACLs, CoPP, selective QoS for various ICMPv6 types/codes, et.
> al. should be configured in such a manner that 600pps of anything can’t
> cause an adverse impact to any network functions.  Because actual bad
> actors are unlikely to voluntarily stop, even when requested to do so.
>
> Clearly, and in this particular case my CP protections did their job
> successfully, fortunately, but that is kind of besides the point.
>
> What I am wondering, though, is if it is really should be considered okay
> for
> a good actor to launch what essentially amounts to an neighbour cache
> exhaustion DoS attack towards unrelated network operators (without asking
> first), just because bad actors might do the same.
>
> Tore
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210706/6b3dd958/attachment.html>