nanog mailing list archives

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


From: "Nick Suan" <nsuan () nonexiste net>
Date: Thu, 15 Jul 2021 09:45:39 -0500

I've noticed something similar on two networks, however it appears to be trying to scan port 80:

13:30:26.387183 IP6 2620:96:a000::5.9999 > 2620:135:5005:71::b0c.80: Flags [S], seq 2063829402, win 65535, length 0
13:30:26.393445 IP6 2620:96:a000::5.9999 > 2620:135:5006:7::703.80: Flags [S], seq 2158423190, win 65535, length 0
13:30:26.430259 IP6 2620:96:a000::5.9999 > 2620:135:500e:3d::804.80: Flags [S], seq 3284825109, win 65535, length 0
13:30:26.432115 IP6 2620:96:a000::5.9999 > 2620:135:5007:2d7::a.80: Flags [S], seq 109350720, win 65535, length 0
13:30:26.460045 IP6 2620:96:a000::5.9999 > 2620:135:5009:998::a.80: Flags [S], seq 3938745191, win 65535, length 0
13:30:26.515579 IP6 2620:96:a000::5.9999 > 2620:135:500b:c92::6.80: Flags [S], seq 430848867, win 65535, length 0
13:30:26.516136 IP6 2620:96:a000::5.9999 > 2620:135:5006:14::b0c.80: Flags [S], seq 515087951, win 65535, length 0
13:30:26.542392 IP6 2620:96:a000::5.9999 > 2620:135:500a:67::30a.80: Flags [S], seq 2626838356, win 65535, length 0
13:30:26.547341 IP6 2620:96:a000::5.9999 > 2620:135:500f:b30::f.80: Flags [S], seq 939521116, win 65535, length 0
13:30:26.549701 IP6 2620:96:a000::5.9999 > 2620:135:500c:b::95.80: Flags [S], seq 1015131109, win 65535, length 0
13:30:26.557200 IP6 2620:96:a000::5.9999 > 2620:135:5009:50::f5.80: Flags [S], seq 217447395, win 65535, length 0
 

On Tue, Jul 6, 2021, at 4:53 AM, Tore Anderson wrote:
A couple of hours after midnight UTC, the control plane policers for
unresolved traffic on a couple of our CE routers started being clogged with
ping-scanning activity from 2620:96:a000::/48, which belongs to «Internet
Measurement Research (SIXMA)» according to ARIN.

Excerpt of this traffic (anonymised on our end):

11:21:05.016914 IP6 2620:96:a000::10 > 2001:db8:1234::f5:7a69: ICMP6, 
echo request, seq 0, length 16
11:21:05.016929 IP6 2620:96:a000::10 > 2001:db8:1234::12:ba74: ICMP6, 
echo request, seq 0, length 16
11:21:05.060045 IP6 2001:db8:1234::3 > 2620:96:a000::10: ICMP6, 
destination unreachable, unreachable address 2001:db8:1234::e7:f473, 
length 64
11:21:05.060060 IP6 2001:db8:1234::3 > 2620:96:a000::7: ICMP6, 
destination unreachable, unreachable address 2001:db8:1234::d4:c4a3, 
length 64
11:21:05.060419 IP6 2001:db8:1234::3 > 2620:96:a000::7: ICMP6, 
destination unreachable, unreachable address 2001:db8:1234::42:198a, 
length 64
11:21:05.064464 IP6 2620:96:a000::10 > 2001:db8:1234::4a:d4cd: ICMP6, 
echo request, seq 0, length 16
11:21:05.079645 IP6 2620:96:a000::10 > 2001:db8:1234::63:b58d: ICMP6, 
echo request, seq 0, length 16
11:21:05.097337 IP6 2620:96:a000::10 > 2001:db8:1234::24:1038: ICMP6, 
echo request, seq 0, length 16
11:21:05.111091 IP6 2620:96:a000::7 > 2001:db8:1234::8f:a126: ICMP6, 
echo request, seq 0, length 16
11:21:05.124112 IP6 2001:db8:1234::3 > 2620:96:a000::7: ICMP6, 
destination unreachable, unreachable address 2001:db8:1234::e6:70fc, 
length 64
11:21:05.124417 IP6 2001:db8:1234::3 > 2620:96:a000::10: ICMP6, 
destination unreachable, unreachable address 2001:db8:1234::bf:ca18, 
length 64
11:21:05.137509 IP6 2620:96:a000::10 > 2001:db8:1234::12:f0df: ICMP6, 
echo request, seq 0, length 16
11:21:05.142614 IP6 2620:96:a000::7 > 2001:db8:1234::8f:9ec6: ICMP6, 
echo request, seq 0, length 16

While the CP policer did its job and prevented any significant operational
impact, the traffic did possibly prevent/delay legitimate address resolution
attempts as well as trigger loads of pointless address resolution attempts
(ICMPv6 Neighbour Solicitations) towards the customer LAN.

We just blocked the prefix at our AS border to get rid of that noise. Those
ACLs are currently dropping packets at a rate of around 600 pps.

I was just curious to hear if anyone else is seeing the same thing, and also
whether or not people feel that this is an okay thing for this «Internet
Measurement Research (SIXMA)» to do (assuming they are white-hats)?

Tore






Current thread: