I've been analyzing some of the encap traffic and finding unexpected things.
Several sources of ipencap'd packets being received by amprgw have non-44 inner source addresses.
Would you all agree that a protocol-4 (ipencap) packet reaching the UCSD gateway should always have an inner (encap'd) source address on the 44-net? And that those that don't should be considered bogus and be discarded? - Brian
Absolutely. I can't think of a reason why someone would be using the gateway otherwise.
Neill K6NRT
Sent from my iPad
On Apr 19, 2017, at 8:34 PM, Brian Kantor Brian@UCSD.Edu wrote:
(Please trim inclusions from previous messages) _______________________________________________ I've been analyzing some of the encap traffic and finding unexpected things.
Several sources of ipencap'd packets being received by amprgw have non-44 inner source addresses.
Would you all agree that a protocol-4 (ipencap) packet reaching the UCSD gateway should always have an inner (encap'd) source address on the 44-net? And that those that don't should be considered bogus and be discarded?
- Brian
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
What's peculiar about a lot of these non-44 is that they have the encapsulated (inner) source and destination apparently interchanged:
Apr 19 21:28:27 <local0.debug> amprgw ipipd[66472]: NON44: len 40, os 91.121.90.186, od 169.228.66.251, is 91.223.133.13, id 44.134.209.15, ttl 237, proto 6
Either that or they're encapping in the wrong direction.
I can't offhand think of what would cause THAT. - Brian
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@hamradio.ucsd.edu on behalf of Brian Kantor Brian@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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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:
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 ....
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@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:
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 ....
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
China, Vietnam and others in same region are the nr1 source of hack attempts... Been seeing A LOT of hack attempts coming from those sources the last 5 years or so on all networks I manage for customers
Ruben - ON3RVH
On 20 Apr 2017, at 16:54, Marc Williams monsieurmarc@btinternet.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ 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@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: 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 ....
44Net mailing list 44Net@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
Hi Brian and all,
It seems that my gateway is the bad one. I have one rule that redirects the traffic from INET addresses to 44.134.x.x addresses back again into the tunnel to the amprgw router. It's an old configuration and I did that to make reachable from Internet a 44net host. It should work only when a hostname in the Ampr.org DNS is associated to those 44net IP address. For sure there's something that I did wrong. Is this a supported routing configuration? Or am I abusing some policies? Later this night I will look into that. My idea is to implement some iptables rules (thanks for sharing) in order to block unwanted traffic.
Sorry for causing this mess! Regards, Marco iw2ohx
On 20/04/2017 16:47, Brian Kantor 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:
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 ....
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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:
It seems that my gateway is the bad one. I have one rule that redirects the traffic from INET addresses to 44.134.x.x addresses back again into the tunnel to the amprgw router. It's an old configuration and I did that to make reachable from Internet a 44net host. It should work only when a hostname in the Ampr.org DNS is associated to those 44net IP address. For sure there's something that I did wrong. Is this a supported routing configuration? Or am I abusing some policies? Later this night I will look into that. My idea is to implement some iptables rules (thanks for sharing) in order to block unwanted traffic.
Sorry for causing this mess! Regards, Marco iw2ohx
Hi all,
I'm implementing this IPTABLES script:
https://www.cyberciti.biz/faq/block-entier-country-using-iptables/
It should avoid traffic coming from these attackers towards 44-net hosts belonging to my subnets.
Just some examples:
Apr 20 21:42:52 ks28006 kernel: cn Country DropIN=tunl0 OUT=tun1 MAC= SRC=180.97.106.162 DST=44.134.224.50 LEN=40 TOS=0x00 PREC=0x00 TTL=231 ID=54321 PROTO=TCP SPT=36243 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0 Apr 20 21:42:53 ks28006 kernel: cn Country DropIN=tunl0 OUT= MAC= SRC=119.28.68.144 DST=44.134.0.1 LEN=92 TOS=0x00 PREC=0x00 TTL=51 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=18388 SEQ=1 Apr 20 21:42:53 ks28006 kernel: cn Country DropIN=tunl0 OUT=tun1 MAC= SRC=182.254.6.23 DST=44.134.160.1 LEN=84 TOS=0x00 PREC=0x00 TTL=43 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=21669 SEQ=4 Apr 20 21:42:53 ks28006 kernel: cn Country DropIN=tunl0 OUT=tun1 MAC= SRC=119.145.248.226 DST=44.134.192.31 LEN=40 TOS=0x00 PREC=0x00 TTL=238 ID=30562 PROTO=TCP SPT=1235 DPT=1433 WINDOW=1024 RES=0x00 SYN URGP=0 Apr 20 21:42:53 ks28006 kernel: cn Country DropIN=tunl0 OUT=tun1 MAC= SRC=119.145.248.226 DST=44.134.192.31 LEN=40 TOS=0x00 PREC=0x00 TTL=237 ID=30562 PROTO=TCP SPT=1235 DPT=1433 WINDOW=1024 RES=0x00 SYN URGP=0 Apr 20 21:42:53 ks28006 kernel: cn Country DropIN=tunl0 OUT= MAC= SRC=101.226.77.16 DST=44.134.0.1 LEN=84 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=2294 SEQ=4
I'm blocking entire blocks from countries like China, Afghanistan, US, Brazil, Romania, Russia, Italy (why not?).
I will add at the end the bogon list that Lynwood shared. Of course, a cleanup of the Ampr.org DNS would help a lot. Definitely this something I have to do for Italy... This issue gave me the opportunity to play again with IPTABLES after many years :)
Regards, Marco iw2ohx
On 20/04/2017 19:01, Brian Kantor wrote:
(Please trim inclusions from previous messages) _______________________________________________ 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:
It seems that my gateway is the bad one. I have one rule that redirects the traffic from INET addresses to 44.134.x.x addresses back again into the tunnel to the amprgw router. It's an old configuration and I did that to make reachable from Internet a 44net host. It should work only when a hostname in the Ampr.org DNS is associated to those 44net IP address. For sure there's something that I did wrong. Is this a supported routing configuration? Or am I abusing some policies? Later this night I will look into that. My idea is to implement some iptables rules (thanks for sharing) in order to block unwanted traffic.
Sorry for causing this mess! Regards, Marco iw2ohx
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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.
From April 5th I started using ampr-ripd-1.16
Yesterday, after I spotted above totally wrong entries I returned to ampr-ripd-1.15
From this very moment I do not see such routes anymore.
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
Yes, it's still trying to use amprgw to get to a host on network 44 from network 44:
Apr 21 08:08:11 <local0.debug> amprgw ipipd[71490]: DEST44: len 37, os 87.251.250.110, od 169.228.66.251, is 44.165.2.2, id 44.165.129.254, ttl 63, proto 93
I don't think it should be doing this. - Brian
On Fri, Apr 21, 2017 at 05:05:51PM +0300, SP2L 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.
From April 5th I started using ampr-ripd-1.16
Yesterday, after I spotted above totally wrong entries I returned to ampr-ripd-1.15
From this very moment I do not see such routes anymore.
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.
Wait a moment...
Partly it _IS CORRECT_ as I have link to 44.165.129.254 but this gateway is __OFF LINE__ for quite long time.
Will remove this link and then issue should disappear, I believe.
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:
(Please trim inclusions from previous messages) _______________________________________________ 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.
From April 5th I started using ampr-ripd-1.16 Yesterday, after I spotted above totally wrong entries I returned to ampr-ripd-1.15 From this very moment I do not see such routes anymore.
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
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Hello Marius.
But... my tunnel is configured as follows:
ifconfig tunl0 44.165.2.2 netmask 255.255.255.255 mtu 1472 multicast arp up
/usr/local/bin/ampr-ripd -t 1 -a 87.251.250.110 -i tunl0 -v -s
There is _NO_ 192.168.0.1 IP plainly visible, which is my private router LAN IP.
So, how come that I see such routes, please? Am I misssing something?
Best regards. Tom - SP2L
-----Oryginalna wiadomość----- From: Marius Petrescu Sent: Friday, April 21, 2017 8:07 PM To: AMPRNet working group Subject: Re: [44net] misconfigured encap routers?
(Please trim inclusions from previous messages) _______________________________________________ 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
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) WebSitehttp://www.ronen.org/ www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com
________________________________
77.138.34.39
On 22/04/2017 7:21 PM, R P wrote:
(Please trim inclusions from previous messages) _______________________________________________
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
I'm also looking for a better explanation.
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
Is this Packet currently transfered ?
________________________________ From: 44Net 44net-bounces+ronenp=hotmail.com@hamradio.ucsd.edu on behalf of Brian Kantor Brian@UCSD.Edu Sent: Wednesday, April 19, 2017 8:33 PM To: 44net@hamradio.ucsd.edu Subject: [44net] misconfigured encap routers?
(Please trim inclusions from previous messages) _______________________________________________
Several sources of ipencap'd packets being received by amprgw have non-44 inner source addresses.
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
YES I agree!! These encap public source addreses are all probing for standard open ports - Which get dropped by my firewalls 73 Paul G4APL
On 20 April 2017 at 04:33 Brian Kantor Brian@UCSD.Edu wrote:
(Please trim inclusions from previous messages) _______________________________________________ I've been analyzing some of the encap traffic and finding unexpected things.
Several sources of ipencap'd packets being received by amprgw have non-44 inner source addresses.
Would you all agree that a protocol-4 (ipencap) packet reaching the UCSD gateway should always have an inner (encap'd) source address on the 44-net? And that those that don't should be considered bogus and be discarded?
- Brian
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
This email has been scanned by Netintelligence http://www.netintelligence.com/email
Can someone send me a few lines for iptables that would allow me to drop ipip packets whose inner source addresses are non-44’s”? Much appreciated… jerome - ve7ass
On Apr 19, 2017, at 23:41, paul Lewis paul@theskywaves.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ YES I agree!! These encap public source addreses are all probing for standard open ports - Which get dropped by my firewalls 73 Paul G4APL
On 20 April 2017 at 04:33 Brian Kantor Brian@UCSD.Edu wrote:
(Please trim inclusions from previous messages)
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@aol.com wrote:
Can someone send me a few lines for iptables that would allow me to drop ipip packets whose inner source addresses are non-44’s”? Much appreciated… jerome - ve7ass
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
EDIT MY SUBNET of 44.60.44.0/24 to YOUR SUBNET(S). Your own subnets are invalid as an inbound source address to your node.
On 04/20/2017 07:13 AM, lleachii@aol.com wrote:
***iptables -I FORWARD ! -s 44.60.44.0/24 -o tunl0 -j DROP
# 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
All,
Can someone with an iptables router, running the dynamic filtering scripts (using IPSET OR IPTABLES) do the following.
- make an IP tables rule AFTER (-A [APPEND]) your ALLOW IPENCAP from AMPRGWS - to DROP IPENCAP - let us know if you get any firewall hits by checking your running ipencap list
I accepted IPENCAP without connection tracking for a long time, so i have no netfilter information, unless it was a Nested IPENCAP packet that was received at tunl0.
73,
- Lynwood KB3VWG
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:
I'm blocking entire blocks from countries like China, Afghanistan, US, Brazil, Romania, Russia, Italy (why not?).
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
On Apr 20, 2017, at 18:11, lleachii--- via 44Net 44net@hamradio.ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________ Correction...he can't get routes from AMPRGW...without someone else bootstrapping him.
- Lynwood
On 04/20/2017 09:05 PM, lleachii@aol.com wrote:
(but then he can't use the Internet on his AMPRLAN then). Just my $0.02...
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On Wed, 19 Apr 2017, Brian Kantor wrote:
(Please trim inclusions from previous messages) Several sources of ipencap'd packets being received by amprgw have non-44 inner source addresses.
Would you all agree that a protocol-4 (ipencap) packet reaching the UCSD gateway should always have an inner (encap'd) source address on the 44-net? And that those that don't should be considered bogus and be discarded?
Quite clearly they can be discarded.
They *should* be discarded; they can be attempts to use the router as a bouncer point for network attacks.
For an IPIP packet, if the inner src is in 44/8 and the destination is not in 44/8, the packet can be accepted; the amprnet host is communicating with the outside Internet. But I would believe all other cases to be mostly config issues.
* src in 44/8, dst not in 44/8: OK, amprnet host talking to the Internet
* src in 44/8, dst in 44/8: the sender gateway has a silly default route towards USCD and has not loaded the full mesh encap route table, could probably drop unless you wish to support this use case (star network topology instead of mesh)
* src not in 44/8: totally bogus, ipip packets should be originated by amprnet gateways only
- Hessu, OH7LZB
-
Brian Kantor -
Heikki Hannikainen -
jerome schatten -
lleachii＠aol.com -
Marc Williams -
Marco Di Martino -
Marco Di Martino (IW2OHX)
-
Marius Petrescu -
Michael Fox - N6MEF -
Neill Thornton -
paul Lewis -
R P -
Ruben ON3RVH -
SP2L -
Tony Langdon