44net January 2019

44net@mailman.ampr.org

27 participants
23 discussions

Re: [44net] DNS Flag Day, Feb 1st, 2019
by Rob Janssen 27 Jan '19

27 Jan '19

>Contacting Debian will always yield the same results as they've stated >for decades now. They fix end-user affecting bugs, but they don't >introduce new versions, features, etc. At one time there was the >Debian Volatile project that hosted "fast moving" versions of software >(spamassassin, clamav, etc), But that project was disbanded years ago. It is what most distributions do. And frankly I am not that unhappy with it. Sometimes it is nice to have a recent version of something but when a system is continuously updating everything it requires constant attention because things are breaking all the time. Unfortunately most open source developers do not consider backward compatibility very important, they just declare some feature you are using as "deprecated" and you will have to find a workaround or abandon some functionality. I prefer to do that at my own convenience, not at the time the distribution maintainer forces it upon me. >As of today, the authoritative voice is ISC for whether or not bind >v9.5.x should be used.. and they say don't. Are you using v9.5.5 as >an authoritative server, if so as a master? We are not using version 9.5.5 and I never wrote that. It is version 9.9.5. Rob

2 1

Re: [44net] DNS Flag Day, Feb 1st, 2019
by Rob Janssen 27 Jan '19

27 Jan '19

> The problem lies outside of Linux distributions, the problem lies with > over aggressive firewalls (or poorly designed firewalls) that don't > allow or understand DNS Extensions. And with old DNS server versions that do not allow them either, I think. And that seems to be the case for the abovementioned domains. (or there is such an overly agressive firewall in front of them) > This email was sent to you from a Debian Stretch (earlier in the food > chain than Jessie) server using DNS servers running various versions of > Linux DNS software behind simple iptables firewalls that don't strip > off DNS Extension bits. I am running Debian Buster on my own machine at home, even newer, and I have no problems either. But on our AMPRnet gateway (which has Debian Jessie) there is a DNS server/resolver (bind 9.9.5) which logs EDNS warning about the abovementioned domains, and it was my impression that after this flag day those warnings would be turned into errors for those domains. But of course that would only happen when Debian decide to replace the bind package on Jessie with a new version that has been amended according to the message that Brian sent (9.14.0). I am not so convinced that this is going to happen, but I have not researched that fully. When I understand correctly, major resolvers like 1.1.1.1, 8.8.8.8 and 9.9.9.9 would make that change on Feb 1st, so those that use these resolvers will be affected immediately on Feb 1st. Well, we will see. The number of EDNS warnings (and warnings about DNSSEC issues) has gone down quite a bit in the last months, so apparently work has been done in a lot of places already. Rob

3 2

Re: [44net] DNS Flag Day, Feb 1st, 2019
by Rob Janssen 26 Jan '19

26 Jan '19

>>/But on our AMPRnet gateway (which has Debian Jessie) />>/there is a DNS server/resolver (bind 9.9.5) / >Ouch. Bind v9.9.5 is ~10 years old... sure Debian applies patches, but >man that's way too old, even ISC would heavily advise against it. Why >can't that gateway be upgraded to Stretch or Buster? I'm willing to >help if help is needed. Debian Jessie is only some 3.5 years old and it is fully supported. We keep it uptodate. When you think the package is too old you better contact Debian instead. I know how to update the system, but it involves work, downtime, and risk. And when I do this on sunday afternoons (a convenient time for me to do it) I get nagged about interruptions in the AMPRnet/HAMnet service during times others are using it. So it has to be planned at some time when it is not used so much and I still have time to do it. Other less critical systems will likely be done first, also to gain experience with this particular version upgrade. >I can assure you that that your thoughts are correct on this. Debian >will patch patch patch bind v9.5.5, right up to the end of LTS support, >but never move to a newer major version. It's not in their mindset to >do such. ;-) It is how most distributions work. What we will have to see is whether they will patch this change into their version of bind or will just ignore it because it is not a security issue. Same for the "stretch" version. The "Buster" version will maybe get an update. But even that is not so certain as it is currently at version 9.11.5 so not the leading version either. Rob

2 1

Re: [44net] DNS Flag Day, Feb 1st, 2019
by Rob Janssen 26 Jan '19

26 Jan '19

> Rob, > Both domains you speak of do not rely on AMPRnet DNS infrastructure > So Brandmeister and Dstar.su are not effected by any DNS issues within AMPRnet > 73s, > Rudy (PD0ZRY) That is exactly what I wrote: it is not related to 44Net. There is nothing we can do about it. But it is related to amateur radio and it could affect people reading the list because they are involved in amateur radio networking. So it is good to know it so we know where we could look when problems appear. See the topic of this thread: DNS Flag Day, Feb 1st, 2019. that is when problems could occur. Although I don't expect that all the Linux distribution maintainers will suddenly rush out resolver updates on Feb 1st, especially not on stable versions. So it could take longer until it becomes visible in our network. It will likely hit those that use 8.8.8.8 sooner than e.g. the resolver on our gateway (44.137.0.1) which will only get updated once Debian Jessie receives an update. Rob

2 1

Re: [44net] DNS Flag Day, Feb 1st, 2019
by Rob Janssen 25 Jan '19

25 Jan '19

While not really related to 44Net, note that there are serious issues with the DNS servers used by amateur radio related services like brandmeister.network dstargateway.org dstar.su etc. Not much we can do about it, but at least it is known... Rob

4 4

Wiki - Firewall ipset Bogons
by LLEACHII＠aol.com 24 Jan '19

24 Jan '19

All, The ipset firewall script I posted included my subnet. The error was fixed from an unedited copy/paste operation. 73, - Lynwood KB3VWG

2 3

DNS Flag Day, Feb 1st, 2019
by Brian Kantor 23 Jan '19

23 Jan '19

Quoting from the web site at https://dnsflagday.net/ What is happening? The current DNS is unnecessarily slow and suffers from inability to deploy new features. To remediate these problems, vendors of DNS software and also big public DNS providers are going to remove certain workarounds on February 1st, 2019. This change affects only sites which operate software which is not following published standards. Are you affected? On that web page, there is a Domain Owner's test. I have already tested AMPR.ORG, and it passes except for one test on one of our secondary servers times out. I am working with the person who so kindly runs that secondary server [in Thailand] to get this fixed. Please don't run any more tests on the AMPR.ORG domain. But if *you* operate servers for a subdomain of ampr.org, such as 'se.ampr.org', you may wish to test your subdomain and see if there are things you need to fix. In fact, the "se.ampr.org" subdomain does indeed have a few problems that probably should be addressed. (In particular, it looks like the DNS server software for that domain may not be listening on the IPv6 addresses for those servers.) - Brian

2 1

AMPRNet OVPN portal still working?
by Mark Phillips 11 Jan '19

11 Jan '19

Hi Folks, I've had need to try the Open VPN portal located at aprs.fi today but I failed to connect. Is it still functioning? Thanks Mark NI2O/G7LTT

2 1

Re: [44net] security reminder : Sharing best practices and tools ?
by lleachii＠aol.com 11 Jan '19

11 Jan '19

1. As you all observed yesterday, I still run OpenWrt - currently on a Cisco Meraki MX60W device. I also use OpenWrt to create a separate VLAN for AMPRLAN traffic (those configs are in the Wiki). I can use routing, masquerade and NAT in another VLAN - if I need to temporally assign a device a 44 Public IP for testing and use. 2.I am running the firewall on my tunnel, which is iptables and zone-based in OpenWrt. Only relevant inbound ports for known services are allowed (e.g. 80/tcp for HTTP from 0.0.0.0/0 and 53/udp for DNS from 44.0.0.0/8). For additional security, I use a script ran with ampr-ripd updates - to only allow Pings and IPENCAP traffic from the IPs located in the Portal (script available on the Firewall Wiki page - someone offered an update to the script, but it has not yet been tested or implemented in the one found at the Wiki). I currently only use Apache, HTML and some PHP on the visible web server. The "largest" concern here is the PHP-based APRS Code recovery tool (someone in this forum previously helped me better sanitize the input, as to prevent command injections). 3.I do monitor traffic with softflowd package in OpenWrt. I collect and record the data with NfSen (http://nfsen.sourceforge.net). I also run snmpd for bandwidth statistics. * Would you be willing to share the SANS IP script you have?* What threats does this list block? 4.PFsense also implements Snort, perhaps you can route traffic through a Virtual Machine to test? 5.When needed, I previously used a firewall rule that only allows x SYNs from given IP in x minutes. If greater than x attempts - REJECT. 6.Regarding DNS, I do not open my server to the outside world. Only those at 44.0.0.0/8 are able to reach and use it.

2 4

security reminder
by Brian Kantor 11 Jan '19

11 Jan '19

Folks, Please remember that when you set up a host, computer, or device on the AMPRNet, it is exposed to the big bad evil environment of the Internet without any form of protection such as a firewall or traffic filter, UNLESS YOU PROVIDE IT. In recent days we've had a some more complaints about systems being used as DNS amplification attack vectors, others as having been compromised and turned into a spam bot, and so on. I wish these were unusual events, but they're not rare enough. Yes, you're being thrown into the network security swamp, and having to learn to swim while trying to keep your head above water. Please be careful. Practice safe networking! - Brian

3 4

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net January 2019