24 Mar
2020
24 Mar
'20
4:03 a.m.
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