20 Apr
2017
20 Apr
'17
5:02 a.m.
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