24 Mar
2020
24 Mar
'20
10:58 a.m.
Hello Lynwood,
Thank you for working on this and all of this is amazingly complex and I
would have never expected something like this would be possible. A few
questions and comments if I may:
1. Do you know if this multiple encapsulation and resultant issue
(rogue routing) only apply to Linux hosts or does it automatically
happen on other IPIP stacks like OpenWRT, JNOS, Mikrotik, Cisco, etc?
2. In the Linux world, the routing function is generally very
controllable and OFF by default. Since it's off... I don't know how
malicious users could be abusing Linux based systems. Maybe I'm not
100% clear on the problem here. Are these users trying to break into
our AMPR hosts due to gaps in our firewalls or are they exploiting
incomplete firewalls to use them as relay hosts to SOURCE attacks out on
the Internet?
3. For Linux setups, do you have a tcpdump filter that can show this
issue? I have a machine on the Internet that I can test with (as you
requested)
4. Do you have any example IPTABLES rules to block these 2nd and 3rd
headers scenarios?
5. Do you know if there a way to still have DNS records for our AMPR
IPs yet disable traffic coming from the AMPRGW gateway?
--David
KI6ZHD
On 03/24/2020 02:03 AM, lleachii--- via 44Net wrote:
All,
I wanted to make 2 notes regarding: dynamic IP addresses and AMPR TCP-based services.
* An operator mentioned that it may perhaps be malicious dynamic IPs (no longer used by
the operators in question) that are sending this traffic...I also think the [malicious]
experience "via RIP[44]" had not occurred was noted...
Since my gateway is in fact dynamic and still seeing issues...wouldn't it be prudent
for those operators that are monitoring AND FIREWALLING their gateways to identify the
rogue gateways for removal and dropping?
Because, if they're rogue operators...**we now understand how our routes are being
leaked**...as they are successfully relocating my new Public IPs (even though I'm
dropping routing traffic and IPs out of tunl0 that != my allocation).
* All operators running TCP services should ensure they are not reflecting SYN-ACK
packets and/or experiencing half-open connections on the router and server as a result.
Firewalling new TCP connections CONNECTION_STATE not SYN (unless you expect such traffic)
and burst rules help. In OpenWrt, such activity can be easily seen on the Overview Page
upon login at "Active Connections" graphic.
** I suggest as an extreme measure for those who have not blocked IPENCAP on tunl0 only
to operators in the past - to do so; and/or renumber their router interface(s) possessing
AMPR IPs (the IP does not need a DNS record if it doesn't need access from
AMPRGW/Public Internet). This mitigates the malicious actors' ability to perform
nested routing on your device.
** It is now apparent that 2nd and 3rd headers need to be properly firewalled on all
gateways running IPENCAP. Be vigilant.
** Please make sure no internal LAN devices were compromised (thru asymmetric traffic
that may have allowed a malicious person access to LAN machines).
** Nested IPIP can be firewalled (i.e. Header 2 - the third header); but there is no
known solution to receiving a packet with a malicious Header 1 (i.e the second header -
which could be expected to reach any device on Earth with a Public IP). Properly
firewalling and monitoring traffic that you allow into your 44network (with 44net IPs) is
important.
** If anyone running a Linux-based router can WireShark/tcpdump and observe MAC addresses
directly on their tunl0, please let me know. This is believed a hash of the 4 SRC/DST IPs
of Headers 0 and 1 - which could be used to authenticate traffic from gateways that !=
AMPRGW.
19:39 UTC 23MAR2020:
269 11.96 KB zone_amprwan_dest_DROP all * * 0.0.0.0/0 0.0.0.0/0 - AMPR_DropLoop
844 76.12 KB zone_amprwan_dest_DROP all * * !44.60.44.0/24 0.0.0.0/0 -
Drop-AMPR_OUT_InvalidSRC
This is ~30 seconds of traffic of drops from my router to forwarding of invalid Header 1
receipts. The first rule is all traffic from you in which KB3VWG != DST IP; and hence you
asked me to route it for you. (I only allow this by coordination). It should be 0. I
should note the second rule includes drops from my AMPRLAN that != bogons - but should
otherwise be 0 too (e.g. unfirewalled, the packets could forward to BGP 44 IPs that exist
on an operator's routing table as "properly NATed traffic" from an allowed
gateway).
73,
- Lynwood
KB3VWG
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net