May you provide a list of all these gateways you see ? so that their maintainers will be aware and fix the problem ? I hope one of them is not myn .... ________________________________ From: 44Net <44net-bounces+ronenp=hotmail.com(a)hamradio.ucsd.edu> on behalf of Brian Kantor <Brian(a)UCSD.Edu> Sent: Wednesday, April 19, 2017 9:36 PM To: AMPRNet working group Subject: Re: [44net] misconfigured encap routers? (Please trim inclusions from previous messages) _______________________________________________ What's peculiar about a lot of these non-44 is that they have the encapsulated (inner) source and destination apparently interchanged: _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

My relatively new GW is at 86.146.55.101I am keen to know what rules to apply when its agreed on.As it is I have blocked all china IP's as i was getting A LOT of connection attempts. Marc On Thursday, 20 April 2017, 15:48, Brian Kantor <Brian(a)UCSD.Edu> wrote: (Please trim inclusions from previous messages) _______________________________________________ In analyzing the log, it's pretty clear that before I started filtering these packets out, amprgw was being used to attack hosts all over the Internet from a huge list of spoofed packet outer source addresses. New firewall rules require that incoming proto-4 packets have to have an outer source address of one of the registered gateways, and forwarding rules require the inner source address to be on network 44 and on the list of registered hosts.  This should help some. Given those rules, the following gateways have been attempting to send encap packets with non-44 inner source addresses: 23.30.150.141 24.55.194.111 24.147.182.8 24.215.95.200 24.229.88.253 59.167.198.158 67.164.64.8  77.138.34.39 85.186.143.52 85.234.252.133 87.105.249.51 87.251.250.110 91.121.90.186 * 104.49.12.130 104.238.183.161 * this one has been doing it a lot If people who operate these gateways could look into why they're doing this it would be appreciated.     - Brian On Thu, Apr 20, 2017 at 05:50:41AM +0000, R P wrote: _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

An HTML attachment was scrubbed... URL: <http://hamradio.ucsd.edu/mailman/private/44net/attachments/20170420/30d6baf6/attachment.html>

Well, the ipip router at UCSD will drop encap'd packets whose inner source is not on network 44, and those with BOTH inner source and destination addresses on network 44. - Brian On Thu, Apr 20, 2017 at 06:51:49PM +0200, Marco Di Martino wrote:

Brian, Marius et al. Brian, is my gateway still been misbehaving? Brian's post dated Apr 20th 15:48UTC comprised my public IP address 87.251.250.110 This alerted me enough to search for possible culprit. Checked thorughly present routing table on my server. To my astonishment I spotted following entries: 44.130.121.2 via 192.168.0.1 dev eth0 proto 44 onlink. 44.130.122.2 via 192.168.0.1 dev eth0 proto 44 onlink. 44.130.124.2 via 192.168.0.1 dev eth0 proto 44 onlink. 44.131.14.255 via 192.168.0.1 dev eth0 proto 44 onlink. Yesterday, after I spotted above totally wrong entries I returned to ampr-ripd-1.15 Please note: neither before nor after I swapped ampr-ripd, encap.txt file generated by ampr-ripd _DID NOT_ contained such wrong entries! Server operating system is: systemd Debian-8.7 32bit - updated to date. Best regards. Tom - SP2L

Brian. Thank you very much for prompt response. It's really at least weird... Particularly because 44.165.129.254 IP address _IS NOT MINE_ ! It belongs to another Polish gateway maintained by SQ8GKT... Will search further to remove this issue. Best regards. Tom - SP2L

Brian. How it is right now, please? Should be O.K. Best regards. Tom - SP2L

Hi Tom, Those routes are correct and are BGP routed endpoint host routes. They are generated by ampr-ripd starting with version 1.16 to allow you to reach those subnets via tunnel. Marius, YO2LOJ On 2017-04-21 17:05, SP2L wrote:

May you give me more datails ? (from your log ) this seems to be my gateway but i have a 44 Net connectivity OK Thanks Forward Ronen - 4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com ________________________________ 77.138.34.39

As of about 1600 Pacific time, this is a summary of problems logged in today's ipipd router log. The following gateways are sending packets to amprgw (169.228.66.251) which either have non-44net inner source addresses or which are attempting to reach a 44-net inner destination address from a 44-net inner source address. Either of these will cause the packet to be dropped, and is an indication of misconfigured routing. It would be greatly appreciated if the operators of these gateways would take appropriate measures. - Brian #packets gateway address -------- --------------- 34477 90.63.239.151 23472 81.242.50.150 19413 92.149.14.241 14409 59.167.198.158 9698 24.215.95.200 6660 24.229.88.253 6308 208.110.114.235 5973 24.147.182.8 5412 85.234.252.133 3798 77.138.34.39 2320 67.164.64.8 2233 87.105.249.51 2005 87.251.250.110 1367 24.55.194.111 717 66.85.85.82 177 173.230.244.130 168 192.147.172.252 130 107.179.251.142

No, they're logged and dropped. - Brian On Thu, Apr 20, 2017 at 04:12:00AM +0000, R P wrote:

Going thru the archives, you may find posts from me long ago that mentions this behavior. To refresh, I discovered double-encapsulated packets being received all the way at my AMPR LAN (I added the 'general loop' iptables rule below to prevent that). Alot of my original firewall setups in Linux thru OpenWRT 15 was due to discovering the nature of running the tunnel on the same router as your home/business. I also wrote how a malicious person could send packets to your Home LAN and perhaps use it to forward packets back out your Public Interface...I was told thats impossible...BECAUSE ONLY WE HAD ACCESS TO THE IPs IN THE PORTAL! (now you see why I read Chris' emails intently...) I first observed this and realized one logical reason was to use AMPRNet as a secondary channel to forward packets across the Internet. I surmised at some point, that one day, someone could resort to active means to make the network more efficient for them - either thru tuning their methods, or compromising machines to better control the movement. Many years ago, it was Team - APT1 sending RDP disconnect signals to tcp/3389 to locate Windows machines; now - its more complex. Below are some firewall rules. # DROPS IP TRAFFIC THAT'S INVALID ENTERING OR EXITING AMPR # THIS PREVENTS A GENERAL LOOP iptables -I FORWARD -i tunl0 -o tunl0 -j DROP # PREVENTS PACKETS WITHOUT SOURCE IP IN ASSIGNED SUBNET FROM EXITING AMPRLAN iptables -t raw -I PREROUTING ! -s 44.60.44.0/24 -i br-amprnet -j DROP # PREVENTS IP SOURCE ADDRESS SPOOFING FROM YOUR INTERFACE # SEE: https://tools.ietf.org/html/bcp38 # DROPS OUTBOUND UNASSIGNED IPs FROM LOOPING THROUGH tunl0 VIA IPENCAP # YOU MUST ADD ACCEPT RULES UNDER THIS LINE TO MAKE EXCEPTIONS iptables -I FORWARD ! -s 44.60.44.0/24 -o tunl0 -j DROP ############################################################ # THIS PREVENTS NESTED IPENCAP iptables -t raw -I PREROUTING -p 4 -i tunl0 -j DROP On 04/19/2017 06:04 PM, lleachii(a)aol.com wrote: And some bogons lists as well: # BOGON LIST # SEE http://www.team-cymru.org/Services/Bogons/bogon-bn-nonagg.txt ipset -A bogons 0.0.0.0/8 ipset -A bogons 10.0.0.0/8 ipset -A bogons 100.64.0.0/10 ipset -A bogons 127.0.0.0/8 ipset -A bogons 169.254.0.0/16 ipset -A bogons 172.16.0.0/12 ipset -A bogons 192.0.0.0/24 ipset -A bogons 192.0.2.0/24 ipset -A bogons 192.168.0.0/16 ipset -A bogons 198.18.0.0/15 ipset -A bogons 198.51.100.0/24 ipset -A bogons 203.0.113.0/24 ipset -A bogons 224.0.0.0/4 ipset -A bogons 240.0.0.0/4 ipset -A bogons 44.60.44.0/24 ipset -A bogons 44.128.0.0/16 iptables -t raw -I PREROUTING -i eth0.2 -m set --match-set bogons src -j DROP iptables -t raw -I PREROUTING -i tunl0 -m set --match-set bogons src -j DROP - Lynwood KB3VWG

Jerome iptables -I FORWARD ! -s 44.0.0.0/8 -i tunl0 -j DROP iptables -I INPUT ! -s 44.0.0.0/8 -i tunl0 -j DROP "If the source address of packets entering tunl0 doesn't equal AMPRNet, DROP them." - Lynwood

Wouldn't it be easier to make a rule to drop all output from tunl0 without your subnet addresses as src...and not accept tcp...udp or packets for your endpoints? I understand the concept of blocs you don't expect traffic from; but the list I posted includes ALL IPv4 addresses KNOWN everywhere on the global Internet not be valid ANYWHERE as a source, unless you expect it, for ANY REASON, WHATSOEVER. I know everyone is now understanding the security implications. Just as I emailed Jerome in a separate email, it was also as simple form him to remove AMPRGW as a source of IPENCAP traffic (but then he can't use the Internet on his AMPRLAN then). Just my $0.02... - Lynwood KB3VWG On 04/20/2017:

First let me thank all that responded to my quest for some iptables ideas for getting rid of encaped non-ampr source packets. Most of it I understood and some I did not. In any event, I learned quite a bit along the way. For me, most all of the bad stuff is coming in via the spoofed ampr gateway address of 169.228.66.251 . The only thing I use the gateway for is the rip broadcasts. Linwood is right — the obvious solution is to simply use the emailed routing tables from the portal and not use rip at all. Then simply block everything coming from 169.228.66.251 - easy peasy. Several of my jnos forwarding partners have been doing this for years. Not as convenient, but it will do the job - they get a daily updated table via email and automatically install it and then source it. I think this is the route I will take for now while keeping on playing with iptables. jerome ve7ass Vancouver