> My speicific issue here is that my local AMPR coordinator recently told me that unless all my IP addresses had a DNS entry, I risked loosing my allocations. I think this is a policy that *he* is setting himself (not a global AMPR policy) and
> though I don't agree with his view, I obliged to give him ~1024 hostnames to fill things out. If other AMPR coordinators have similar approaches, then DNS entries mean everything to the IP allocation be it a subnet or a /32.
>
> --David
> KI6ZHD
This is not how I handle allocations... in the area I manage one can allocate individual addresses or subnets, and when
they are subnets the address range of the subnet is reserved but not each address in the subnet needs to have a name attached.
However, all traffic for addresses without associated name in .ampr.org is filtered at our internet gateway. So when you want
to actually *use* an address outside the local radio network, it has to have a name.
(this is the same policy as in the gateway at UCSD)
Rob
> Subject:
> Re: [44net] DNS cleanup
> From:
> Brian Kantor <Brian(a)UCSD.Edu>
> Date:
> 02/07/2016 08:52 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> On Sun, Feb 07, 2016 at 08:37:23PM +0100, Rob Janssen wrote:
>> >I wonder what the database structure is and if you could maybe just delete the
>> >record from the database without affecting the children.
> I can't; I don't really have access to the underlying database.
> - Brian
That is why I initally sent the request via the contact page on the portal. However, it was not
processed. This makes me pessimistic about the maintenance resources at the portal, and
reluctant to spend a lot of time filling it with information that apparently can never be modified.
Rob
> Rob, if you'll tell me which subnet that has "children" should be removed
> and which of those "children" should be kept, I'll make a note of the
> "children", delete them, delete the erroneous subnet, and add the
> "children" back in. Annoying, but it should take only a few minutes,
> less time and more productive than arguing about it on the mailing list.
It is the 44.137.24.0/22 subnet as I mentioned before.
But be careful: those children are IPIP gateways and have that subnet registered
in their gateway system. I'm sure when you delete them through the UI, the subnet
will be deleted from their gateway as well. That is not good.
I wonder what the database structure is and if you could maybe just delete the
record from the database without affecting the children.
When there are all kinds of pointers back and forth between parent and child records,
that would be something that needs to be fixed. It should be easy to add and delete
subnet levels between existing ones, e.g. a new regional subnet between a country
subnet and users. We are re-arranging things all the time as the network develops.
Probably the subnets should just be stored neutrally, and the parent/child relationship
should only be established at the time the records are retrieved for display.
And deleting a subnet should not infer deleting everything that is in it, the contents
should just be promoted to the next higher level.
Rob
> Were there multiple entries for 44.137.24.0/22 ?
> I still have it in my allocation list. the whole subnet was in use for
> the regional local access point I was co-sysop for. That access point is
> not operational at the moment, but I would like to keep that allocation
> for when it comes back in the future.
It is precisely this flexibility that is missing in the portal. There is no way to insert or delete
regional subnets when there already are user subnets registered below that level. And there is no
way to resize a subnet or transfer ownership either.
I would like to register all regional subnets for clarity of the allocation tree, and transfer them to
the proper user when that is appropriate. This can be done in HamnetDB and there I have registered
those subnets to make the structure of the network visible to anyone, but the portal cannot do that.
This particular subnet has been planned to be used by the soon to be deployed access point at the
Eindhoven UHF repeater site which will route it using BGP via radio link to PE1RDP.
So I prefer to delete this entry for now, to clean the allocation list.
Rob
All,
I have an NTP Server online at kb3vwg-001.ampr.org. Let me know if it's
reachable from your hosts. This is currently in testing (the domain may
move perhaps to tick.ampr.org.).
73,
KB3VWG
All,
I've noticed that if someone performs a traceroute to a 44net address
routed via an IPIP tunnel on OpenWRT versions 14 or 15 (tested) results
in the router giving the Public, Commercial IP address of the device
instead of a 44net IP on tunl0, or any assigned forwarded interface.
Without intricate detail, this is by design of the Operating System, as
the kernel re-packets an ICMP TTL Exceeded, and seems not to connect
that new pack as RELATED to the Received Packet in which the TTL had
Exceeded. This is fine when all local IPs are Private IPs, or should be
forwarded via the Kernel's Gateway; but as they are not, and the only
gateway the kernel knows is the physical WAN. The ICMP TTL Exceeded
Packet is given the Kernel's source address (with Gateway), and sent
hence - a leaked TTL Exceeded packet.
Reason: the least computationally difficult method to protect our
gateways from rogue packets is to not publicize/announce our Public
WAN-facing IP address.
In order to prevent this, a RAW Packet Filter rule for all packets
received via tunl0 < 2 can be created, preventing processing of TTL
exceeded packets for non-44net IPs:
iptables -t raw -I PREROUTING -i tunl0 -m ttl --ttl-lt 2 -j DROP
iptables -t raw -I PREROUTING -s 44.0.0.0/8 -d 44.xxx.xxx.xxx/xx -i
tunl0 -m ttl --ttl-lt 2 -j ACCEPT
Those using OpenWRT, please test and confirm issue and its fix.
73,
-Lynwood
KB3VWG
The main problem with spoofing of course is not that it "attacks" our systems, but
that our systems are being hit by backscatter from others that are being attacked,
or that we attack others when we are used as reflectors.
So be careful to have the right filters so you don't send too much traffic "back" to
senders with spoofed addresses.
It is correct that you need to allow protocol 4 only on the external network card and
NOT on the tunl0 interface. If you do, you allow tunnel-within-tunnel packets, and
they could be malicious, but in any case they are incorrect. In the past we have
sometimes seen encap loops where some incorrectly configured system kept putting
packets into another encap layer and forward them, and this kind of looping can
easily be stopped by not allowing protocol 4 over protocol 4.
There is an additonal filter that you can make, and which I explained earlier on the
list. With Marius' ampr-ripd you can call an external script when the encap route table is
changed, and in this script you can maintain an address list of valid IPIP peers, and
use that in the firewall to accept IPIP packets only from peers that are announced
by the RIP daemon. This will guard you against funny IPIP packets sent by random
hackers. Of course it is not sufficient against the determined people, because they
can spoof the IPIP packet to come from one of the gateways in the list, and it will
be accepted anyway.
Blocking "non-44 source addresses on tunnel interface" of course is only possible
when you do not want to communicate between net-44 and the rest of internet.
However, you can always use the regular firewalling techniques like blocking all
incoming traffic with a source address that is local to your network (and of course
all RFC1918 traffic like 192.168.0.0/16), and use connection tracking
(-m state --state ESTABLISHED, RELATED) to block most incoming traffic
that is not a reply to outgoing connections, and then carefully allow what you like
to come in. This has to be done separately for the external interface and the tunnel
interface, as the things you want to allow on those two interfaces are completely
different.
Lots of firewall howto's only show you how to put lots of rules in the INPUT or FORWARD
table, which quickly make things inefficient and difficult to maintain.
It is usually better to setup a number of tables with iptables -N tablename, each with
the rules for a specific interface or even for a protocol, and put rules in the INPUT and
FORWARD tables that match on some input/output interface and branch to the table
for that case.
iptables -N eth0ipip
....
iptables -N eth0input
iptables -A eth0input -p 4 -j eth0ipip
...
iptables -N tunl0input
iptables -A INPUT -i eth0 -j eth0input
iptables -A INPUT -i tunl0 -j tunl0input
...
Rob
> Subject:
> [44net] OpenWRT Security Notice
> From:
> lleachii(a)aol.com
> Date:
> 02/02/2016 04:11 AM
>
> To:
> 44net(a)hamradio.ucsd.edu
>
>
>
> the least computationally difficult method to protect our gateways from rogue packets is to not publicize/announce our Public WAN-facing IP address.
Of course that does not work very well.
All other gateway stations know your public IP and those who really want to know it can probably obtain it.
The only way to protect your system is by using appropriate filters. And yes, these can be difficult to design,
especially in the world of lousy internet service providers that do not bother filtering clients that spoof addresses....
Rob
All,
- Time - NTP UDP/123
- This is odd, I'm able to reach the server and 44.60.44.1 from AMPR and the Public Internet
(what exactly are you trying to 'reach' at 44.60.44.1 to determine its status, as I've only announced NTP as being available there)
- using 'ntpdate -q 44.60.44.1' or 'ntpdate -q kb3vwg-001.ampr.org' works for me anywhere on the Internet
kb3vwg@kb3vwg:~$ ntpdate -q 44.60.44.1
server 44.60.44.1, stratum 2, offset 0.001173, delay 0.02589
30 Jan 18:00:19 ntpdate[1058]: adjust time server 44.60.44.1 offset 0.001173 sec
- I have now permitted access from the Public Internet (previously, it was only available to 44 hosts), let me know
- Lynwood
KB3VWG
Stephen and Ed,
I have setup the tunneling routers on devices using OpenWRT and Ubuntu
Linux. Since OpenWRT is actually designed to be a router OS, I highly
suggest it. There are instructions for setting up a gateway using both
OSes at http://wiki.ampr.org/
In order to route using Ubiquiti or VyOs, you must be able to compile
and run ampr-ripd in order to provide RIP44 (which is not the name as
RIPv2) on the tunnel interface.
Since VyOs is a distribution of Linux, there may be instructions on the
Internet on how to compile and/or execute ampr-ripd or rip44d.
73,
Lynwood
KB3VWG
