44net April 2017

44net@mailman.ampr.org

41 participants
78 discussions

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

Internet founder dies
by Brian Kantor 18 Apr '17

18 Apr '17

http://www.bbc.com/news/technology-39621198

1 0

Router advice
by Marc Williams 18 Apr '17

18 Apr '17

Hi all, As part of my gateway setup I am looking to get rid of my BT Home hub (which I am having to use with DMZ turned on) and put in an inexpensive but more capable router. So I was looking for peoples thoughts on either Microtik or Ubiquiti Edge routers. Is either particularly better suited? Kind Regards Marc (2W0PNT)

5 5

Re: [44net] Make Error
by Rob Janssen 17 Apr '17

17 Apr '17

> An update - I had success using compiling using 'cpp' instead of 'gcc' cpp is not a compiler. it will only resolve your #include #define etc but the output is still C. > I now receive less error output, but there's still an error: Your crosscompiler setup is seriously broken! It apparently misses critical include file contents, the first error about IPPORT_ROUTESERVER was also caused by that. Maybe you missed some step in setting it up, I remember from the past where I tried this for my Dreambox that it is quite an involved procedure. Rob

1 0

Make Error
by lleachii＠aol.com 17 Apr '17

17 Apr '17

All, I've been able to successfully compile ampr-ripd for the native OS (Ubuntu Linux x64); but I receive errors when trying to compile for MIPS: -------------------------------------------------------------------------- user@ubuntu-comp:~/ampr-ripd-1.16.2$ make CC=mips-openwrt-linux-musl-gcc LD=mips-openwrt-linux-musl-ld mips-openwrt-linux-musl-gcc -Wall -O2 -o ampr-ripd ampr-ripd.c ampr-ripd.c: In function 'create_fwsd': ampr-ripd.c:1536:23: error: 'IPPORT_ROUTESERVER' undeclared (first use in this function) sin.sin_port = htons(IPPORT_ROUTESERVER); ^ ampr-ripd.c:1536:23: note: each undeclared identifier is reported only once for each function it appears in ampr-ripd.c: In function 'on_alarm': ampr-ripd.c:1629:27: error: 'IPPORT_ROUTESERVER' undeclared (first use in this function) sin.sin_port = htons(IPPORT_ROUTESERVER); ^ ampr-ripd.c: In function 'main': ampr-ripd.c:1864:13: error: 'struct udphdr' has no member named 'dest' (udh->dest == htons(IPPORT_ROUTESERVER)) && ^ ampr-ripd.c:1864:29: error: 'IPPORT_ROUTESERVER' undeclared (first use in this function) (udh->dest == htons(IPPORT_ROUTESERVER)) && ^ ampr-ripd.c:1865:13: error: 'struct udphdr' has no member named 'source' (udh->source == htons(IPPORT_ROUTESERVER))) ^ Makefile:30: recipe for target 'ampr-ripd' failed make: *** [ampr-ripd] Error 1 -------------------------------------------------------------------------- Any assistance is appreciated 73, KB3VWG

2 4

Re: [44net] Make Error
by Rob Janssen 17 Apr '17

17 Apr '17

> I've been able to successfully compile ampr-ripd for the native OS (Ubuntu Linux x64); but I receive errors when trying to compile for MIPS: IPPORT_ROUTESERVER should be defined in <netinet/in.h> When it isn't, you can work around that by inserting this line near the top of the ampr-ripd.c file near the other #define lines: #define IPPORT_ROUTESERVER 520 Rob

1 0

fbi.gov at i0ojj.ampr.org
by Gustavo Ponza 16 Apr '17

16 Apr '17

Hi all, Just to inform all of you about the special visit at i0ojj.ampr.org/ir0rm-7.ampr.org by using the following references: fbi.gov. 0 IN TXT Dgoogle-site-verification=L8cauHJF4MANoTCkMbrLkAVfHBta28ctva9n1IDekToQ fbi.gov. 0 IN TXT Dgoogle-site-verification=6UEk-jfg1xPNjz_rQGcRFJOBGxMy1aARDZUTXgSNAqw fbi.gov. 0 IN TXT XublrZj1CzpSEiwtiRFKDAyiek8hRqkqaTTApxvhwai14i8JqVBOauW4cA06i39H5Lhl3HnALCM/xfTxIPEXEpA== fbi.gov. 0 IN TXT 625558384-8740534 -- 73 and ciao, gus i0ojj A proud member of linux team Non multa, sed multum

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net April 2017