44net

44net@mailman.ampr.org

3192 discussions

Re: [44net] DNS Flag Day, Feb 1st, 2019

by Rob Janssen

> 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

7 years, 3 months

Re: [44net] DNS Flag Day, Feb 1st, 2019

by Rob Janssen

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

7 years, 3 months

Wiki - Firewall ipset Bogons

by LLEACHII＠aol.com

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

7 years, 3 months

DNS Flag Day, Feb 1st, 2019

by Brian Kantor

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

7 years, 3 months

AMPRNet OVPN portal still working?

by Mark Phillips

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

7 years, 3 months

Re: [44net] security reminder : Sharing best practices and tools ?

by lleachii＠aol.com

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.

7 years, 3 months

security reminder

by Brian Kantor

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

7 years, 3 months

Re: [44net] security reminder : Sharing best practices and tools ?

by Rob Janssen

I think that script is OK, except of course this line: AMPRGW="<AMPRGW>" Should be edited to the actual address of AMPRGW instead of that <AMPRGW>. I think it is better to just put the literal address in the example code as this kind of substitutions confuses people. When it changes, the Wiki can be updated. It is of course also possible to look it up using DNS but that will require another dependant package e.g. "dig" and again may confuse people. >I tested it and it seems to work. Also believe diffutils doesn't need to > be installed, either. I'll update the OpenWrt Wiki. Correct, the diffutils was only required for the iptables version which uses the diff command to generate changes once the table is initially loaded instead of replacing it from zero every time as the ipset version does. > I only noted it in this particular best practices/tools thread due to > messages in SEP2018: Yes that was a case where I actually received some "malicious" IPIP traffic, but ir happens quite seldomly. Of course it never hurts to lock down as well as possible, but I wanted to indicate that installing this filter is not the full response to the security reminder that Brian posted. I hope people do not think "Oh, Brian posted a security advisory and now there is this script that I do not yet have so let's install it so my system is secured", as this is only a very small and probably insignificant part of that whole security solution. When someone wants quick-and-dirty solutions to the security problem, it is much better to install some firewall rules according to this pattern: - accept ESTABLISHED/RELATED - accept new outgoing traffic - accept new incoming traffic matching some specific addresses/ports/protocols - drop everything else It is usually easiest to have two of those rulesets, one that applies to traffic incoming on the internet interface (where you want to accept protocol 4 using your ipset and not much else) and one that applies to traffic incoming on the tunnel interface (where you are basically handling AMPRnet traffic and may allow a bit more, but often you allow more from 44.0.0.0/8 than from other addresses). How complicated that ends up to be is of course dependent on what services your system(s) should expose, but at least it drops everything that you usually do not want to serve to the outside, like SNMP and DNS. Rob

7 years, 3 months

Re: [44net] security reminder : Sharing best practices and tools ?

by Rob Janssen

> All, > I implemented the code update. It's been added to Firewall Wiki under the ipset-based script. > http://wiki.ampr.org/wiki/Firewalls#ipset <http://wiki.ampr.org/wiki/Firewalls#ipset> > Thanks Rob! Those scripts were adapted from mails that I sent to the list, but there are some funny things in the versions on the Wiki. The first version (with iptables) has comments that really aren't correct. You must have had other problems while debugging this, as neither "the if iptables ... construct does not work" nor "there must be no spaces or empty lines here" are true. Maybe you had files with CRLF line endings (Windows editor) and/or other issues that were resolved by other changes and this comment was left in there. if command then is the same as: command if [ $? eq 0 ] then there may be empty lines between the command and if, this is no problem, but of course there should be NO thing like "echo $?" between those lines! maybe you did that during testing. that will make it fail because the echo command will not only display the value of $? but also the new value of $? will then be set to the result of the echo command! -> always 0 In the second example, using "ipset", there is an "if ipset" command (see, here it is OK!) but the "then" and the "else" branch contain exactly the same code. I don't know how that came about, but of course in that case you can just remove the if, then and else and put 1 instance of the code left-shifted under that. Of course in this case you don't need the tempfile and can do everything in one go like this: ipset -N ipipfilter hash:ip 2>/dev/null ipset flush ipipfilter ipset -A ipipfilter $AMPRGW grep addprivate encap.txt | sed -e 's/.*encap //' | sort -u | while read ip do ipset -A ipipfilter $ip done In my own systems I use a temporary ipset and swap them after completing the above, to avoid the small time interval where the ipset is being filled and packets could be dropped. For an ordinary user gw it probably isn't worth the trouble as this interval is quite short. Of course, those filters are very useful against abuse of the gateway by people who send ipip packets but are not part of AMPRnet (they could use it to hide their IP or to work their way around parts of the firewall) but in practice I have found that most cases where this actually happens are in fact hams who have misconfigured their gateway. (e.g. the IPIP output goes out on another IP than they have configured as incoming for their gateway) Don't think that adding this will solve any problems you have been faced with unless you are certain that it was via IPIP abuse. There probably is another error in the firewall. Rob

7 years, 3 months

Is there any way to update ampr.org dns

by Cathryn Mataga

Right now ke6i.ampr.org points to another ip address, not the one I'm using, which is at vhf.ke6i.ampr.org

7 years, 3 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net