Is anyone else seeing a lot of 'strange' IPSEC traffic? We started seeing logs of IPSEC with invalid spi on Friday. We're seeing it on pretty much all of our PE routers, none of which are setup to do anything VPN related. Most are just routing local customer traffic. decaps: rec'd IPSEC packet has invalid spi for destaddr=X.X.X.X, prot=50, spi=0x9D2D0000(2636972032), srcaddr=211.112.195.167, input interface=TenGigabitEthernet0/0/11 decaps: rec'd IPSEC packet has invalid spi for destaddr=Y.Y.Y.Y, prot=50, spi=0x14690000(342425600), srcaddr=74.116.56.244, input interface=TenGigabitEthernet0/0/5 The destination address is always one of our customer's ip addresses. The source seems to be all over the place, mostly Russia, Korea, China or south east asia. It's not really impacting anything at the moment, just rather annoying. Thanks Shawn
On 11/13/23 19:10, Shawn L via NANOG wrote:
Is anyone else seeing a lot of 'strange' IPSEC traffic? We started seeing logs of IPSEC with invalid spi on Friday. We're seeing it on pretty much all of our PE routers, none of which are setup to do anything VPN related. Most are just routing local customer traffic.
decaps: rec'd IPSEC packet has invalid spi for destaddr=X.X.X.X, prot=50, spi=0x9D2D0000(2636972032), srcaddr=211.112.195.167, input interface=TenGigabitEthernet0/0/11
decaps: rec'd IPSEC packet has invalid spi for destaddr=Y.Y.Y.Y, prot=50, spi=0x14690000(342425600), srcaddr=74.116.56.244, input interface=TenGigabitEthernet0/0/5
The destination address is always one of our customer's ip addresses. The source seems to be all over the place, mostly Russia, Korea, China or south east asia. It's not really impacting anything at the moment, just rather annoying.
Thanks
Shawn
Hi Shawn, we saw a lot of syslog messages like these and the targets are cisco devices, some of witch, according to the data sheets, are not even capable of ipsec. Cisco is punting some ESP traffic to control plane on ios and ios-xe devices, regardless of the configuration. Last week somebody on the internet started a campaign to scan and perhaps to exploit some zero day ipsec vulnerabilities. This is the list of ip addresses we saw: https://pastebin.com/vrLRai9Q -- Best regards, Adrian Minta
A new attack was published against SSH and the paper authors are theorizing that the attack is possible against IPSEC due to flaws in the CPU that are exploitable via brute force. On Mon, Nov 13, 2023 at 9:42 AM Adrian Minta <adrian.minta@gmail.com> wrote:
On 11/13/23 19:10, Shawn L via NANOG wrote:
Is anyone else seeing a lot of 'strange' IPSEC traffic? We started seeing logs of IPSEC with invalid spi on Friday. We're seeing it on pretty much all of our PE routers, none of which are setup to do anything VPN related. Most are just routing local customer traffic.
decaps: rec'd IPSEC packet has invalid spi for destaddr=X.X.X.X, prot=50, spi=0x9D2D0000(2636972032), srcaddr=211.112.195.167, input interface=TenGigabitEthernet0/0/11
decaps: rec'd IPSEC packet has invalid spi for destaddr=Y.Y.Y.Y, prot=50, spi=0x14690000(342425600), srcaddr=74.116.56.244, input interface=TenGigabitEthernet0/0/5
The destination address is always one of our customer's ip addresses. The source seems to be all over the place, mostly Russia, Korea, China or south east asia. It's not really impacting anything at the moment, just rather annoying.
Thanks
Shawn
Hi Shawn,
we saw a lot of syslog messages like these and the targets are cisco devices, some of witch, according to the data sheets, are not even capable of ipsec.
Cisco is punting some ESP traffic to control plane on ios and ios-xe devices, regardless of the configuration.
Last week somebody on the internet started a campaign to scan and perhaps to exploit some zero day ipsec vulnerabilities.
This is the list of ip addresses we saw: https://pastebin.com/vrLRai9Q
-- Best regards, Adrian Minta
----- On Nov 13, 2023, at 9:43 AM, Maurice Brown maurice@pwnship.com wrote: Hi,
A new attack was published against SSH and the paper authors are theorizing that the attack is possible against IPSEC due to flaws in the CPU that are exploitable via brute force.
For those interested, here is the paper: https://eprint.iacr.org/2023/1711.pdf It's written for SSH, but the authors theorize it will work for IPSec as well. Thanks, Sabri
Last week somebody on the internet started a campaign to scan and perhaps to exploit some zero day ipsec vulnerabilities.
I've seen traffic like this for the better part of at least the last 7 years, fairly consistently. It's definitely not something new. On Mon, Nov 13, 2023 at 12:42 PM Adrian Minta <adrian.minta@gmail.com> wrote:
On 11/13/23 19:10, Shawn L via NANOG wrote:
Is anyone else seeing a lot of 'strange' IPSEC traffic? We started seeing logs of IPSEC with invalid spi on Friday. We're seeing it on pretty much all of our PE routers, none of which are setup to do anything VPN related. Most are just routing local customer traffic.
decaps: rec'd IPSEC packet has invalid spi for destaddr=X.X.X.X, prot=50, spi=0x9D2D0000(2636972032), srcaddr=211.112.195.167, input interface=TenGigabitEthernet0/0/11
decaps: rec'd IPSEC packet has invalid spi for destaddr=Y.Y.Y.Y, prot=50, spi=0x14690000(342425600), srcaddr=74.116.56.244, input interface=TenGigabitEthernet0/0/5
The destination address is always one of our customer's ip addresses. The source seems to be all over the place, mostly Russia, Korea, China or south east asia. It's not really impacting anything at the moment, just rather annoying.
Thanks
Shawn
Hi Shawn,
we saw a lot of syslog messages like these and the targets are cisco devices, some of witch, according to the data sheets, are not even capable of ipsec.
Cisco is punting some ESP traffic to control plane on ios and ios-xe devices, regardless of the configuration.
Last week somebody on the internet started a campaign to scan and perhaps to exploit some zero day ipsec vulnerabilities.
This is the list of ip addresses we saw: https://pastebin.com/vrLRai9Q
-- Best regards, Adrian Minta
I can confirm we started seeing this on Nov 9th at 19:10 UTC across all markets from a variety of sources. If you want to filter it with ingress ACLs they need to include subnet base and broadcast addresses in addition to interface address, so a router at 192.168.1.1/30 with a customer potentially running IPSEC at 192.168.1.2 would require all this to silence the log messages: access-list 100 deny esp any host 192.168.1.0 access-list 100 deny esp any host 192.168.1.1 access-list 100 deny esp any host 192.168.1.3 access-list 100 permit ip any any I started with an ACL only on the interface address and then noticed I was still getting logs on base/broadcast addresses. Could be recon for the IKEv2 vulnerability in this: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisor... https://blogs.cisco.com/security/akira-ransomware-targeting-vpns-without-mul... Or zero day. Even though the devices they are hitting are not configured for IPSEC we are filtering it anyway (and for good measure " no crypto isakmp enable"). Mike
On Nov 14, 2023, at 00:12, Shawn L via NANOG <nanog@nanog.org> wrote: The destination address is always one of our customer's ip addresses. Attackers will sometimes use synthetic ESP, AH, GRE, or other protocols in DDoS attacks, because organizations often only think about TCP/UDP/ICMP in terms of ACLs, DDoS defense mechanisms, etc. -------------------------------------------- Roland Dobbins <roland.dobbins@netscout.com>
* Shawn L [Mon 13 Nov 2023, 18:12 CET]:
Is anyone else seeing a lot of 'strange' IPSEC traffic?
This mail server running FreeBSD did: (timestamps in CET, UTC+1) Nov 10 00:58:55 mailserver kernel: ipsec_common_input: no key association found for SA 77.174.253.13/77b40000/50 Nov 10 01:26:09 mailserver kernel: ipsec_common_input: no key association found for SA 77.174.253.13/03e80000/50 Nov 11 10:15:22 mailserver kernel: ipsec_common_input: no key association found for SA 77.174.253.13/62861b0e/50 Nov 11 14:35:34 mailserver kernel: ipsec_common_input: no key association found for SA 77.174.253.13/048b828c/50 Nov 13 20:00:53 mailserver kernel: ipsec_common_input: no key association found for SA 77.174.253.13/a5ff0000/50 I don't remember ever seeing these log messages before. -- Niels.
participants (8)
-
Adrian Minta -
Dobbins, Roland -
Maurice Brown -
Mike Lewinski -
Niels Bakker -
Sabri Berisha -
Shawn L -
Tom Beecher