Since two days ago someone is scanning the internet for IPIP decapsulation gateways, hitting our gateway system.
The packets look like this (shortened tshark output):
Internet Protocol Version 4, Src: 35.231.13.238 (35.231.13.238), Dst: 44.137.164.26 (44.137.164.26)
Version: 4
Total Length: 69
Time to live: 236
Protocol: IPIP (4)
Source: 35.231.13.238 (35.231.13.238)
Destination: 44.137.164.26 (44.137.164.26)
Internet Protocol Version 4, Src: 44.137.164.26 (44.137.164.26), Dst: 35.231.13.238 (35.231.13.238)
Version: 4
Time to live: 255
Protocol: UDP (17)
Source: 44.137.164.26 (44.137.164.26)
Destination: 35.231.13.238 (35.231.13.238)
User Datagram Protocol, Src Port: 35261 (35261), Dst Port: 5974 (5974)
Source Port: 35261 (35261)
Destination Port: 5974 (5974)
Length: 29
Data (21 bytes)
0000 74 68 69 73 20 69 73 20 6e 6f 74 20 61 6e 20 61 this is not an a
0010 74 74 61 63 6b ttack
Data: 74686973206973206e6f7420616e2061747461636b
[Length: 21]
The sender is always 35.231.13.238 (a Google cloud customer), the destination is some random address
(in this case within AMPRnet because the trace was made on a BGP-routed system) and the payload is an
IPIP packet which contains a UDP packet back towards the sender.
Despite the text in the packet, the sender is obviously looking for traffic coming back at that UDP port, and
then knows at which addresses on internet they may find systems that decapsulate IPIP traffic and route it
back to internet. This can then be used to forge source addresses in attacks.
I advise those that run IPIP gateways to configure a firewall that only allows IPIP traffic from peers that are
listed in the route info distributed in the RIP packets. This can be done with some scripting, possibly with
the help of "ipset" to keep a set of valid gateway addresses.
Of course as a first fix you can block all traffic from 35.231.13.238, but that address could change any time.
Rob
Friday, Sept 14 through Sunday, Sept 16 is the annual
ARRL/TAPR Digital Communications Conference, held this
year in Albuquerque, New Mexico, USA.
https://www.tapr.org/dcc.html
I only saw one talk directly relevant to AMPRNet, titled
"Bringing Net-44 and IPv6 to your Station via VPN"
by John Hays, K7VE, scheduled for 9:45 am Saturday.
I'll be attending; if you are also going to be there, look
for the guy wearing the large "44" t-shirt, and we can chat.
If there's interest, perhaps we can have breakfast on Saturday
or Sunday morning.
- Brian
It has been a long time since I have done any serious networking so am
still struggling with getting my head around the instructions for the
Edgerouter even after reading Marius's Microtik wiki.
Does anyone have a Dummies Guide version of building a new gateway on the
Edgerouter X?
I have a HamServerPi and HamNet node (Ubiquiti Bullet M2) ready to go and a
large group of hams waiting for my setup before they start active
involvement in the development of our local HamNet - something we really
need in the middle of tornado alley.
My thanks in advance.
Andy KA5BBC
> We were wondering if it would be possible to tunnel in the AMPRNet from
> UCSD into the exchange over BGP for the weekend of the event. If so what is
> the best way to go about this? I'm more than happen to land it on a VM
> elsewhere (Likely in London) then deal with getting it to the field myself
> if need be.
The standard way to have traffic tunneled to you, in the absence of a regional
gateway that is BGP-routed, would be to register a subnet at the portal and
setup an IPIP gateway for it, if desired using a VM somewhere to do the tunneling
and a further tunnel (VPN) to the site to forward the traffic.
Of course it would be possible to setup BGP routing to your VM, but would it be
worth it for a 3-day event only? Maybe you could setup something more permanent
that can be used by local amateurs after the event has ended.
Rob
Hi,
There is an upcoming event here in the UK, EMF Camp (
https://www.emfcamp.org/). There are a bunch of villages doing various
things, included is an amateur radio village (
https://wiki.emfcamp.org/wiki/Village:Amateur_Radio) as well as an internet
exchange (https://wiki.emfcamp.org/wiki/Village:EMF-IX).
We were wondering if it would be possible to tunnel in the AMPRNet from
UCSD into the exchange over BGP for the weekend of the event. If so what is
the best way to go about this? I'm more than happen to land it on a VM
elsewhere (Likely in London) then deal with getting it to the field myself
if need be.
Thanks,
Alistair
Hello All,
Have you noticed if you do a "C port Call" connect via a com port from Linux
JNOS window with your own (JNOS) call sign to BPQ, BPQ32 or XROUTER that the
connection is established but there is no further response in the connection
and seems to not respond any more.
However if you use another call sign via say Telnet or TNC via JNOS com
port, all works fine and the connection across the com port is established
and proceeds normally.
It makes it hard to test the configuration and have not gotten to the bottom
of it yet.
This has happened thru several versions of JNOS, but I am using similar
autoexec, etc files.
Any Ideas please?
Secondly, why does McAfee keep quarantining my WIN10 BPQ32.EXE file and also
the contents of downloaded BPQ32 EXE ZIP file from the official web site?
Thanks
Rob
Vk1kw
If -- for example -- one has a /24 delegated, are the .0 and .255
blocked at gw.ampr.org?
I haven't tried this, just figured I'd ask.
--
Kris Kirby, KE4AHR
Disinformation Architect, Systems Mangler, & Network Mismanager
> Before, or as soon as you attach a piece of equipment to our network
> (or anywhere else, for that matter) IMMEDIATELY CHANGE THE PASSWORD.
> Oh, and be careful when upgrading firmware: in far too many devices
> when you flash new firmware into it, the password gets reset to the
> factory default. Be sure to check it afterwards!
But, do not see this as a reason to not upgrade firmware!
It is really important to keep firmware uptodate, as e.g. was seen in the recent
case of MikroTik routers being compromised because they were running firmware
before version 6.42.1 which has a vulnerability that allows a remote user to
retrieve the correct password from the router! This was fixed some time ago
(current version is 6.42.6) but people didn't upgrade, and their router became
infected with a botnet that essentially allows it do do anything.
In this case, it is also important to change the password after the upgrade,
not because it would be reset, but because it could be known to an attacker who
retrieved it before the upgrade. In that case they can still login after upgrade!
(more details on how to avoid such things can be found on the MikroTik forum, but
even the "cannot do! too difficult for me!" type of operator still can upgrade the
software as this is only a matter of two clicks in the user interface)
Rob
