Unexplainable router log entries mentioning IPSEC from Yahoo IPs

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
fixable
issue, and one that should be addressed at the source.

Thanks!

Matt
#notspeakingofficiallyforanyoneoranything

On Fri, Dec 18, 2020 at 9:05 PM Dobbins, Roland <Roland.Dobbins at netscout.com>
wrote:

>
>
> 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=68.180.160.18, 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...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20201219/7fb4902a/attachment.html>