44net

44net@mailman.ampr.org

3194 discussions

Start a nNew thread

Re: [44net] OpenWRT 15.05 upgrade to LEDE 17.01.1
by Rob Janssen 21 Apr '17

21 Apr '17

> - HTTP: 44.60.44.10 Now I can access your service for the first time. Rob

1 0

Re: [44net] misconfigured encap routers?
by Rob Janssen 21 Apr '17

21 Apr '17

> - 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 have done that for a while and I do not see a lot of traffic, but there is some. Part of it is from gateways with dynamic address. When their address changes it takes a while for the update to bubble through DNS, the portal and AMPR-RIP, and during that time the traffic from their new address is dropped. But that does not matter, as return traffic would not arrive there either. A gateway with a daily changing external address is really not workable. Lately there has been a lot more bad GRE traffic. We run GRE tunnels as well, with a similar protection, and the default drop rule has logged quite some traffic the past months. Research indicates that it is related to a hacked video recording system, although it is unclear to me what the purpose or cause of the GRE traffic is. When browsing to the source address of these packets, one gets a logon screen of some Chinese video recording (for surveillance) system. Rob

1 0

Re: [44net] OpenWRT 15.05 upgrade to LEDE 17.01.1
by Rob Janssen 21 Apr '17

21 Apr '17

> Tom and Ruben, > traceroute to 44.165.2.4 (44.165.2.4), 30 hops max, 60 byte packets > 1 kb3vwg-001.ampr.org (44.60.44.1) 1.385 ms 1.392 ms 1.593 ms > 2 mail.sp2l.ampr.org (44.165.2.2) 154.783 ms 171.077 ms 171.653 ms > 3 home.sp2l.ampr.org (44.165.2.4) 171.674 ms 171.668 ms 171.650 ms I cannot ping, connect or traceroute you either. When it works from your side and not from ours, are you sure you have a *working* incoming IPIP protocol forward or DMZ host? It is all too common for stations behind ISP NAT modem/routers to have IPIP tunnels that work only outbound (and replies), not for unsolicited inbound traffic, because they only admit IPIP traffic as replies to their own outging traffic, even when they have set a DMZ host in their router. (which often only works for protocols like ICMP, TCP and UDP) Rob

4 15

Re: [44net] encapsulated ipencap packets
by Rob Janssen 20 Apr '17

20 Apr '17

> Regarding the other thread about which firewall rules to use, the > gateway is a little more complicated but for my home router I > (normally, not last night in case you saw differently) have the > equivalent to: > iptables -t filter -A FORWARD -i tunl0 ! -d 44.131.14.128/26 -j REJECT > iptables -t filter -A FORWARD -o tunl0 ! -s 44.131.14.128/26 -j REJECT > I think this pretty much covers the requirements for a basic end network? For the outgoing side, yes. It would be very helpful when everyone had a filter like that. For the incoming side it is a bit too simple. It covers the case where hackers send packets that you would then forward, but that can also be covered with a iptables -A FORWARD -i tunl0 -o tunl0 -j DROP However, it would still be advisable to: - only accept tunnel traffic from registered gateways (I have shown on the list how to do that a couple of times) - attempt to screen the source address of the tunneled traffic a little (e.g. accept non-44 traffic only from the gateway, as shown earlier today, and even better: to reverse path checking for tunnel traffic, i.e. only accept traffic from each tunnel whose source address matches the subnets registered for that tunnel) > If the main gateway receives an invalid encapsulated packet from a > known gateway or a 44net address, would it be helpful to return an > error instead of dropping it? An ICMP Administratively Denied packet > is more likely to generate an obvious error message than packets going > missing. The gateway would probably need to rate-limit the number of > errors it will send out to prevent abuse, though. This does not bring much, it would only help when someone is actually watching the traffic, and it appears not many people do. When a decapsulating gateway sends an ICMP unreachable packet to the encapsulating gateway, that gateway will not normally attempt to translate it into an ICMP packet related to the inner packet and send that back to the originating system. So the user behind the keyboard will never know. Rob

1 0

encapsulated ipencap packets
by Brian Kantor 20 Apr '17

20 Apr '17

In our tunnels, all traffic from a gateway should be encapsulated and should NOT contain an encapsulated ipencap packet. The ipip router at UCSD logs and discards these; I'm seeing such packets from gateways 77.138.34.39 85.234.252.133 86.161.255.194 185.58.225.84 which suggests that they have a routing misconfiguration. The operators of those gateways should examine their routing and encapsulation rules to see why this is happening. - Brian

2 1

DNS for Belgium (44.144.0.0/16)
by Ruben ON3RVH 20 Apr '17

20 Apr '17

Hey Guys, Does anyone have any contact info for ON4SAX? He should be the maintainer for the Belgium subnets. But I'm not able to mail him through the contact info on qrz.com (on4sax(a)on4sax.be<mailto:on4sax@on4sax.be>) to make DNS changes for my hosts. The domain seems parked and has no MX record as far as I can see. I also saw that the range for Belgium is routed through Wireless Belgium and as such not through ucsd so I am also wondering how I can get incoming traffic from the world (non 44net) to my 44net hosts and outbound from my 44net hosts towards the world. Thanks in advance. 73, Ruben - ON3RVH

2 3

Re: [44net] misconfigured encap routers?
by Rob Janssen 20 Apr '17

20 Apr '17

> 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." The problem with that is that it will also drop the legitimate internet traffic that is coming in via the gateway. So, when you want connectivity to/from internet, it has to be more complicated than that. You will need to put a rule in the mangle table for protocol 4 traffic arriving from the gateway, and add some packet mark to the packet, then in the above rule you exclude the packets with that mark. Like this: iptables -t mangle -A PREROUTING -p 4 -s 169.228.66.251 -j MARK --set-mark 1 and in the above rules add before the -j: -m mark ! --mark 1 When you are inside a BGP routed subnet that also is on the tunnel mesh (like 44.137.0.0/16) you will have to change the 169.228.66.251 to the address of your local gateway. And of course, now you make yourself vulnerable again for dedicated attacks that spoof the address of the gateway to send tunneled packets. So it remains mandatory to treat the traffic received via the tunnels as hostile from-internet traffic! Rob

1 0

Re: [44net] misconfigured encap routers?
by Rob Janssen 20 Apr '17

20 Apr '17

> 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. When I see odd addresses on encap links they often are ICMP packets (e.g. TTL exceeded, a result of traceroute) that are sent by encap systems themselves and have the wrong source address. Also, there appears to be some traffic in the noise of Internet that is completely ridiculous. Things like this: Apr 20 10:43:30 Packet DROP: IN=eth0 OUT=gre14 SRC=44.137.49.139 DST=44.137.49.139 LEN=56 TOS=0x00 PREC=0x00 TTL=245 ID=35377 DF PROTO=ICMP TYPE=11 CODE=0 [SRC=44.137.49.139 DST=80.92.136.89 LEN=69 TOS=0x00 PREC=0x00 TTL=1 ID=35377 DF PROTO=UDP SPT=34973 DPT=53 LEN=49 ] Note that 44.137.49.139 is not a registered AMPRnet address so it can never have sent this query, but there is a ICMP TTL exceeded with source and destination being that address about a query it has allegedly sent to 80.92.136.89, an address at some broadband provider that often re-occurs in this (amongst others). It is completely unclear to me whether this is part of some attack on 80.92.136.89, on us, or is due to some bug in a router (that sends ICMP with the wrong source address). W.r.t. tunnel traffic, it sure is a good idea to drop anything not-AMPRnet. I also see a lot of RFC1918 addresses in those packets, and even when I mail the gateway operator about them I usually get a mail back that they are going to do something about it, but that rarely happens (i.e. it just continues). E.g. this repeat offender: Apr 20 07:52:05 Packet DROP: IN=tunl0 OUT=gre3 TUNL=90.63.239.151 SRC=192.168.1.3 DST=44.137.41.178 LEN=52 TOS=0x18 PREC=0xA0 TTL=59 ID=16343 DF PROTO=UDP SPT=50001 DPT=50000 LEN=32 It is unfortunate that setups of a gateway system can vary so widely that it is impossible to give a good firewall example that will work for everyone. My feeling is that many of the gateway operators lack the network knowledge to get the firewall setup correctly, and it would be nice if we could educate them. However, I am not going to be the sysop for even more systems. Some generic help would be a good thing, but it is hard to do. Rob

1 0

Re: [44net] Make Error
by lleachii＠aol.com 20 Apr '17

20 Apr '17

OK, it's my understanding the source and destination ports are undefined. I'll just leave the mesh DOWN at this time, as the cross compiler is configured exactly as before, and I am able to compile other software. Thanks, -Lynwood KB3VWG

6 19

UCSD ipip gateway firewall updated
by Brian Kantor 19 Apr '17

19 Apr '17

I've made a few small changes to the ipip encap firewall in the UCSD encapsulating router. If something has stopped working today because of that, please let me know. - Brian

3 7

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net