Re: Strange IPSEC traffic
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=0x9D2D(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=0x1469(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
Re: massive facebook outage presently
https://www.youtube.com/watch?v=gmk673M5BoA On 10/4/21 7:03 PM, Eric Kuhnke wrote: https://downdetector.com/status/facebook/ <https://downdetector.com/status/facebook/> Normally not worth mentioning random $service having an outage here, but this will undoubtedly generate a large volume of customer service calls. Appears to be failure in DNS resolution. -- Best regards, Adrian Minta
Re: Unexplainable router log entries mentioning IPSEC from Yahoo IPs
=203.84.212.20 Dec 18 02:49:16: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=203.84.212.51 Dec 18 02:45:59: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=66.196.91.232 Dec 18 02:42:21: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=203.84.212.23 Dec 18 02:33:05: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=203.84.212.37 Dec 18 02:30:46: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=203.84.212.50 Dec 18 02:23:02: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=203.84.212.20 Dec 18 00:57:45: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=203.84.212.50 Dec 17 17:06:12: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=68.180.160.18 Dec 17 14:45:06.899: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=68.180.160.34 Dec 17 16:38:03: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=203.84.212.37 Dec 17 16:28:13: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=203.84.212.40 Dec 17 16:24:06: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=68.180.160.99 Dec 17 15:14:03: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=68.180.160.40 Dec 17 15:06:40: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=68.180.160.100 Dec 17 08:57:00: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0xEF7ED795(4018067349) srcaddr=68.180.160.23 Dec 17 08:25:36: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0xEF7ED795(4018067349) srcaddr=68.180.160.104 Dec 17 08:11:54: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0xEF7ED795(4018067349) srcaddr=68.180.160.19 Dec 17 07:22:22: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0xEF7ED795(4018067349) srcaddr=203.84.212.55 Dec 17 06:18:55: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0xEF7ED795(4018067349) srcaddr=68.180.160.20 Dec 17 06:14:35: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0xEF7ED795(4018067349) srcaddr=203.84.212.36 Dec 17 06:13:05: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0xEF7ED795(4018067349) srcaddr=203.84.212.17 Dec 17 05:36:24: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0xEF7ED795(4018067349) srcaddr=203.84.212.53 Dec 17 01:56:17: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0xEF7ED795(4018067349) srcaddr=68.180.160.17 Dec 17 03:27:47: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0xEF7ED795(4018067349) srcaddr=203.84.212.34 -- Best regards, Adrian Minta
Re: Product for heat containment per rack unit?
https://objects.eanixter.com/PD317813.PDF On 8/13/20 9:26 PM, David Hubbard wrote: Curious if anyone has knowledge of a vendor / product designed to make it possible to use back-to-front cooled equipment in racks that need to be ‘sealed’ for heat containment reasons? I’d envision this looking like some kind of adjustable depth sleeve, to get the cold air to the equipment, and perhaps a brush strip opening to allow power cables in? Thanks! -- Best regards, Adrian Minta
Re: Widespread Firefox issues
My temporary solution was to set "xpinstall.signatures.required" to "false". On 5/4/19 4:55 AM, Brielle Bruns wrote: Just an FYI since this is bound to impact users: https://bugzilla.mozilla.org/show_bug.cgi?id=1548973 Basically, Mozilla forgot to renew an intermediate cert, and people's Firefox browsers have mass-disabled addons. Whoops. -- Best regards, Adrian Minta
whois.radb.net down ?
Anyone else seeing the radb.net whois server as being down? $ date Sat Jan 23 00:04:29 EET 2016 $ ping whois.radb.net PING whois.radb.net (207.75.117.18) 56(84) bytes of data. ^C --- whois.radb.net ping statistics --- 7 packets transmitted, 0 received, 100% packet loss, time 6047ms $ telnet whois.radb.net 43 Trying 207.75.117.18... ^C -- Best regards, Adrian Minta
Re: Linux router traffic monitoring, how? netflow?
Softflowd is also nice, supports Netflow versions 1, 5 and 9 and is fully IPv6-capable. The package is included on ubuntu debian. On 14.11.2014 20:38, srn.na...@prgmr.com wrote: fprobe is a linux-based netflow probe that uses libpcap (as does tcpdump) and is already in the ubuntu universe repository. There is an ipv4-only iptables based version too called fprobe-ulog. For collectors, it looks like the ones already available in ubuntu are nfcapd from nfdump and flow-capture from flow-tools. For analysis/alerts, cacti with the thold and flowview plugins might do the job. -- Best regards, Adrian Minta
Re: BGPMON Alert Questions
Already too late :( *Delivery has failed to these recipients or groups:* indriana.triyunianingt...@indosat.com mailto:indriana.triyunianingt...@indosat.com The recipient's mailbox is full and can't accept messages now. Please try resending this message later, or contact the recipient directly. On 02.04.2014 23:40, Aris Lambrianidis wrote: Contacted ip@indosat.com about this, I urge others to do the same. --Aris On Wed, Apr 2, 2014 at 9:33 PM, Andrew (Andy) Ashley andre...@aware.co.thwrote: Hi All, I am a network admin for Aware Corporation AS18356 (Thailand), as mentioned in the alert. We operate a BGPMon PeerMon node on our network, which peers with the BGPMon service as a collector. It is likely that AS4761 (INDOSAT) has somehow managed to hijack these prefixes and CAT (Communications Authority of Thailand AS4651) is not filtering them, hence they are announced to us and are triggering these BGPMon alerts. I have had several mails to our NOC about this already and have responded directly to those. I suggest contacting Indosat directly to get this resolved. AS18356 is a stub AS, so we are not actually advertising these learned hijacked prefixes to anyone but BGPMon for data collection purposes. -- Best regards, Adrian Minta
Re: 10gbps peering subscriber switch recommendation
Good morning, We're in the market to move our IX peering off of our core (too much BGP/CPU :-/ ) and onto a dedicated switch. Brocade ICX 7750 Switch seems to satisfy all the requirements. -- Best regards, Adrian Minta
Re: anybody seeing mail problems sending to yahoo.com? (and a yahoo email contact?)
I'm seeing the same thing: Jan 4 19:13:20 mail2 postfix/error[21241]: 8C9BD1F20045: relay=none, delay=30958, delays=30835/121/0/2.1, dsn=4.4.2, status=deferred (delivery temporarily suspended: lost connection with mta5.am0.yahoodns.net[98.136.217.202] while sending end of data -- message may be sent more than once) Jan 4 19:19:44 mail2 postfix/smtp[21813]: 3993E1F20045: relay=mta7.am0.yahoodns.net[66.196.118.33]:25, delay=98, delays=0.58/0.03/46/51, dsn=4.4.2, status=deferred (lost connection with mta7.am0.yahoodns.net[66.196.118.33] while sending end of data -- message may be sent more than once) Jan 4 19:19:44 mail2 postfix/smtp[21813]: 3993E1F20045: relay=mta7.am0.yahoodns.net[66.196.118.33]:25, delay=98, delays=0.58/0.03/46/51, dsn=4.4.2, status=deferred (lost connection with mta7.am0.yahoodns.net[66.196.118.33] while sending end of data -- message may be sent more than once) -- Best regards, Adrian Minta
Re: Attack on the DNS ?
We already have this type of attack in Bucharest/Romania since last Friday. The targets where IP's of some local webhosters, but at one moment we event saw IP's from Go Daddy. Tcpdump will show something like: 11:10:41.447079 IP target open_resolver_ip.53: 80+ [1au] ANY? isc.org. (37) 11:10:41.447082 IP target open_resolver_ip.53: 59147+ [1au] ANY? isc.org. (37) 11:10:41.447084 IP target open_resolver_ip.53: 13885+ [1au] ANY? isc.org. (37) After one week the attack has been mostly mitigated, and the remaining open resolvers are probably windows servers. Apparently in bill'g world is impossible to restrict the recursion.
Re: 10G switchrecommendaton
Cisco has finally release a new 10G switch, Catalyst 4500-X: http://www.cisco.com/en/US/products/ps12332/index.html Does anyone know the price range, or the FCS date for this ?
Re: Business Ethernet Services
On 06/17/11 21:55, Elliot Finley wrote: Anyone using a CPE that is reliable and costs= $300 ? features needed: SFP for uplink, QnQ, basic layer 2 functionality. If you're using something with the above parameters and you like it, please share. :) Thanks, Elliot Something like Zyxel MES-2110 ?
Re: multicast nightmare #42
Philip Lavine wrote: Please explain how this would be possible: 1 sender 1 mcast group 1 receiver = no data loss 1 sender 1 mcast group 2+ receivers on same VLAN and physical segment = data loss Probably a crappy switch. -- Best regards, Adrian Minta
Re: multicast nightmare #42 - REDUX
Philip Lavine wrote: More info if this helps: Switch Platform: 4500 SUPII+ with gig line cards Data rate is 100Mbps Server OS: Windows 2003 R2 (please withhold snickering). Multicast traffic is routed ? -- Best regards, Adrian Minta
Re: Hijacked Blocks
In Europe RIPE has a nice database. Hijacking is not possible since most ISP's use filters based on RIPE Database. Why ARIN don't use a similar tool ?
Re: Subnet Size for BGP peers.
Shared link for BGP connectivity is a bad idea. Imagine that one of your customer leave proxy-arp on his interface, or imagine that he makes a Layer2 loop. Then all other customers will be affected. Usually a customer with BGP is on another level, so a gain of some IP's doesn't worth the trouble IMHO. -- Best regards, Adrian Minta
RE: What else shall we test?
I will sugest to test the throughput when a BGP peer is flapping. -Original Message- From: Michael J McCafferty m...@m5computersecurity.com Sent: 23 iulie 2009 03:05 To: nanog nanog@nanog.org Subject: What else shall we test? All, We are putting together a test plan to test a pair of Cisco 7206 VXR's, each with with NPE-G2. The purpose of the test is just to make sure we know where their realistic limits are with a real configuration, full route tables from two providers, etc. We have one JDSU T-Berd 8000 test system with interfaces and software to test a single stream through multi-mode fiber interfaces. We plan to test through the interfaces on the NPE and through PA-GE cards with a variety of packet sizes (especially 64 Byte). I'd be interested in any thoughts on additional testing or testing methodologies we might want to do, to help us set our expectations for this setup and to plan when we need to go bigger as we grow traffic, hosts, etc. We plan to get 1 to 3 additional full tables and peer with Any2 Easy on this network within the next year. We want to determine how this platform will behave under moderate DoS attacks, BGP updates, etc. Is there anything else we need to be mindful of? Can we get a realistic test of the routers with the T-Berd? What else should we test while we have the maintenance window and the test system on hand? Your thoughts and experience are appreciated! Thanks ! Mike -- Michael J. McCafferty Principal, Security Engineer M5 Hosting http://www.m5hosting.com You can have your own custom Dedicated Server up and running today ! RedHat Enterprise, CentOS, Ubuntu, Debian, OpenBSD, FreeBSD, and more
