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
On 7/6/21 11:53, Tore Anderson wrote:
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)?
One would think that they if they want to target your network, that they'd reach out to discuss, first. Mark.
On 6 Jul 2021, at 16:53, Tore Anderson <tore@fud.no> wrote:
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)?
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?). 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. -------------------------------------------- Roland Dobbins <roland.dobbins@netscout.com>
* 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
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@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
Protected or not, 600 pps is abusive. If they practice this behavior routinely they could find themselves filtered off the Internet. If Tore can’t reach them, I recommend an abuse report to their upstream, assuming they’re not directly peering at an IXP (I haven’t checked). -mel via cell On Jul 6, 2021, at 3:53 AM, Tom Beecher <beecher@beecher.cc> wrote: 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@fud.no<mailto:tore@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
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
participants (6)
-
Dobbins, Roland -
Mark Tinka -
Mel Beckman -
Nick Suan -
Tom Beecher -
Tore Anderson