Re: [44net] Security - Nested IPIP

All, I ran the following against my netflow (which is tcpdump syntax) tunl0 logs: not dst net 44.60.44.0/24 and not src net 44.60.44.0/24 and not dst host 224.0.0.9 I forwarded 0 traffic from the said loop in the last 14 days, all dropped. Please start checking! - KB3VWG -----Original Message----- From: lleachii <lleachii(a)aol.com> To: 44net <44net(a)mailman.ampr.org> Sent: Mon, Mar 16, 2020 12:32 am Subject: Re: Security - Nested IPIP 509.93 K 26.31 MB zone_amprwan_dest_DROP all * * 0.0.0.0/0 0.0.0.0/0 - AMPR_DropLoop All, To be clear: These are packets that seem to have come from one of you...that wanted me to route it to a destination - that was not my subnet. - KB3VWG -----Original Message----- From: lleachii <lleachii(a)aol.com> To: 44net <44net(a)mailman.ampr.org> Sent: Mon, Mar 16, 2020 12:27 am Subject: Re: Security - Nested IPIP All, At this point, I think I've got enough SMTP 500 errors from my coordinator: * Some are seeing rogue packets across their GWs (I only found, blocked and identified 32 such attempted packets on 10MAR at approx 2100 UTC via an existing raw rule that drops IPENCAP packets received into tunl0, nested in a rule that only allows IPENCAP on WAN from you)...an operator sent that rogue 10MAR traffic to me and is still online; and has not yet responded to my request to identify ** I believe this COULD be nested IPENCAP packets entering your tunnels (such as the 32 packets I blocked), if not firewalled, the current origin of such traffic would be inconsequential. This is more dangerous if your routing policies use the same table for your AMPR IPs and interfaces...I don't want to get into what information was gleaned to determine this...if an operator does not expect a nested IPENCAP - I advise a rule to all in such condition - to drop IPENCAP on the tunnel itself, this prevents a malicious person from addressing your router as the destination in Header 1 and hence using your router to forward the payload contained under Header 2 A rule to check for such is: `tcpdump -vvv -n -i tunl0 proto 4` Except in cases an operator knowingly uses IPENCAP to send and receive to downstream operators, you should see 0 traffic; and if you see traffic with your router as the destination in its outer header (i.e. Header 1) - that's the issue. The traffic under Header 2 is rogue and being routed without your knowledge and consent. I hope nobody sees such traffic. Our BGP operators who also run IPENCAP on the same Routing Plane definitely need to take caution. ############################################################# DROPS IP TRAFFIC THAT'S INVALID ENTERING OR EXITING AMPR# THIS PREVENTS A GENERAL LOOP# iptables -I FORWARD -i tunl0 -o tunl0 -j DROP # THIS PREVENTS NESTED IPENCAPiptables -t raw -I PREROUTING -p 4 -i tunl0 -j DROP ...THIS REMINDED ME TO CHECK THAT (commented) FIREWALL LOOP RULE [I now have in OpenWrt UCI syntax]! 509.93 K 26.31 MB zone_amprwan_dest_DROP all * * 0.0.0.0/0 0.0.0.0/0 - AMPR_DropLoop * If this is occurring - without proper firewalling, those who forward their IPENCAP downstream from their border to an internal device could even experience activity that appears as if a rogue device existed on LAN/AMPRLAN - interacting Locally * Abnormal/uncommon traffic to my AMPR-only services, sent from some registered gateways that are still online (I am actively experiencing this, a majority of this traffic is from the same operator) * MikroTik discoveries from nodes (normal) * Normal bad traffic from the Internet via AMPRGW (I hope everyone blocks this anyway - normal)...I did see some very sophisticated SIP/VoIP strings * Some of you query the NTP with your Public IP thru AMPRGW instead of directly to me thru the mesh (just a note to make your SRC IP an AMPR address, not your Public IP - I may disable your access thru AMPGW in the future, as it's announced as "AMPR-only") 73, - Lynwood KB3VWG