> Ah ah ah, it's very complex to common mortals as me :)
> Perhaps it is mature the time to adopt, after many
> years, the *SIMPLE* implementation created by Maiko
> VE4KLM for JNOS2, applying it to our systems:
> ------------
> 3) Configuration
> -------------
> When adding a 44 route, typically one uses something like this :
> route add 44.0/8 encap a.b.c.d
But does that automatically add the two levels of firewalling that we are
discussing here? If not, it does not seem very relevant. It is quite easy
to make a configuration that basically works (especially when using RIP which
makes route statements like the above unnecessary), but the point is that it
is not secure against abuse by malicious people. That is why additional
work is needed.
Rob
> It is also a good idea to block forwarding from/to AMPR interfaces other
> than your own internal 44 network.
That is right! At first you filter IPIP packets in the input chain to allow only
packets from the list of gateways (public addresses). In Linux this can be done
with ipset and on the MikroTik using an "address list" (which is just their UI around
ipset), or you can dynamically maintain a list of rules.
(which allows to maintain counters per rule, also possible with recent kernels and ipset)
Then, there should be a forward chain rule on the tunnel interface that only accepts
incoming packets to the net-44 subnets you have published in the portal. You don't
want to accept traffic destined for other addresses and then forward that.
It would also be good to filter traffic forwarded TO the tunnel interface to only
accept valid source addresses (your own networks), mostly to cover one's own mistakes
in handling NAT.
Both of those rulesets would have blocked the described scan.
Probably it would be a good idea to include some working firewall example on the
Wiki (for the different environments desrcibed) so everyone can have a secure firewall
without in-depth knowledge about this matter.
Unfortunately I have little knowledge about the particular methods used to load iptables
on the different Linux distributions: the first thing I always do when installing a
machine that does advanced routing is to remove their firewall maintenance packages
and replace them by a init.d script that just uses iptables statements to build it at
boot (or reload) time. That allows me to use variables, comments, shell constructs,
etc which is much more maintainable than those "iptables-save" or automatic firewall
maintenance solutions (when you install some package, corresponding ports are opened).
Rob
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
