Unexplainable router log entries mentioning IPSEC from Yahoo IPs
mpetach at netflight.com
Sat Dec 19 14:03:32 UTC 2020
In this case, however, what's being seen is simply valid traffic
which was most likely erroneously redirected through an
internal encryption device.
I would hazard a guess the folks involved have already jumped
on checking the redirector rules to fix the leakage which allowed
external IPs to be passed through the internal encryption pathway.
I helped build the system that's causing those messages, so I have
a bit of a guess as to what the issue is. I'm no longer an employee,
however, so I can't fix the issue. But in this case, those boxes really
aren't trying to attack you--they just aren't supposed to be sending
traffic externally like that.
So, it actually is good to speak up about this traffic--because it's a
issue, and one that should be addressed at the source.
On Fri, Dec 18, 2020 at 9:05 PM Dobbins, Roland <Roland.Dobbins at netscout.com>
> On Dec 19, 2020, at 01:19, Frank Bulk <frnkblk at iname.com> wrote:
> Curious if someone can point me in the right direction. In the last three
> days our core router (Cisco 7609) has logged the following events:
> Dec 16 19:04:59.027 CST: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC
> packet has invalid spi for destaddr=<redacted>, prot=50,
> spi=0xEF7ED795(4018067349), srcaddr=184.108.40.206, input interface=Vlan20
> It should be noted that attackers will sometimes generate
> non-TCP/-UDP/-ICMP DDoS attack traffic which is intended to bypass ACLs,
> firewall rules, etc. which only take the more common protocols into
> account. They'll often pick ESP (protocol 50, AH (protocol 51), or GRE
> (protocol 47) in order to try & masquerade the attack traffic as legitimate
> VPN or tunneled traffic.
> And the source IPs of this attack traffic are frequently spoofed, as well.
> Roland Dobbins <roland.dobbins at netscout.com>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NANOG