44net

44net@mailman.ampr.org

3 participants
3195 discussions

Re: [44net] OpenWRT Security Notice
by Rob Janssen 03 Feb '16

03 Feb '16

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

1 0

Re: [44net] OpenWRT Security Notice
by Rob Janssen 02 Feb '16

02 Feb '16

> 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

2 1

Re: [44net] NTP Server Test
by lleachii＠aol.com 01 Feb '16

01 Feb '16

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

7 11

Re: [44net] Just received allocation... next steps?
by lleachii＠aol.com 01 Feb '16

01 Feb '16

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

2 2

Just received allocation... next steps?
by Stephen - K1LNX 01 Feb '16

01 Feb '16

Hi guys, I just received an allocation for 44.34.96.0/24 to begin experimenting with. I plan on doing mesh networking as well as offering services as time permits. I have two questions regarding connectivity to the network: - I understand most folks are doing IPIP tunneling, has anyone ever done this on a Ubiquiti Edgerouter Lite or VyOS? Anyone in or near Tennessee that can accomodate a tunnel for me? - BGP... thinking entirely out loud here, but are there any VPS providers anyone is aware of that will accept announcements from 44 net that I could handle with say BIRD or another BGP daemon under linux? This would be my ideal setup and I could tunnel my own connectivity, but not sure this is possible.. looking for ideas here. 73, and glad to be a part of AMPR, I love networking :) Stephen K1LNX

4 4

NTP - Reference
by lleachii＠aol.com 01 Feb '16

01 Feb '16

An inquiry was made into the Stratum of the NTP server: - Servers referenced are Stratum 1 or Stratum 2 Servers which reference a Stratum 0 Atomic Clock maintained by a University or Government Institution in Canada, the US or Mexico time-d.nist.gov nist1-pa.ustiming.org time.nist.gov time.nrc.ca time.chu.nrc.ca gnomon.cc.columbia.edu tick.gatech.edu cronos.cenam.mx

3 3

Re: [44net] Just received allocation... next steps?
by Steve L 01 Feb '16

01 Feb '16

Your next step is to build a gateway. "google: build amprnet gateway" Your are correct most folks are doing the IPIP (aka IPencap) method, as BGP is typically for /24's or bigger and isn't something attainable for most. The most common method is to do this on some sort of Linux computer.

1 0

Questions from Rob and Marius
by lleachii＠aol.com 01 Feb '16

01 Feb '16

- all 44/8 hosts should be able to traceroute and ping my hosts - the Internet and AMPR should be able to reach: 44.60.44.1 (Gateway, DNS and NTP), xxx.3 (DNS) and xxx.10 (HTTP) - I am running Verizon FiOS directly into the WAN interface of the OpenWRT device, I have explicitly opened IPENCAP on it, and tunl0 and rip44 are running on it - In order to provide MoCA (Coax) Ethernet device Internet, connect the carrier-provided router to the LAN interface, and provide IGMP Proxy for multicast - a Trunk port interface carries all VLANs (including AMPR LAN to my Virtual Server interface, HSMM devices, etc.) - 44/8 hosts should not be firewalled - I have a raw filtering of TTL > 2 on the WAN interface (preventing TTL Expiry DDoS Attacks); but AMPR hosts with a source of 44/8 can traceroute on AMPRNet to 44.60.44.0/24 and see 44.60.44.1 and hosts - Lynwood KB3VWG

1 0

Re: [44net] NTP Server Test
by Rob Janssen 31 Jan '16

31 Jan '16

> - 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 Maybe you are suffering the problem with some types of cable router that I noticed when trying to reach another US amprnet station. Those routers claim to support a DMZ mode and you set the IPIP tunnel server as the DMZ host, but in reality they do not forward new incoming IPIP packets to the DMZ host, they only forward "replies" to outgoing IPIP tunnel packets just like they do for normal NAT traffic. So, you configure your IPIP tunnel host, you test connectivity with other systems by pinging or telnet or whatever, and all appears to be fine. However, when anyone else attempts to connect to you from the outside, your system is just unreachable. When you do a ping to one of them and they try to reach you, it works OK. But when there is no traffic for a few minutes, the gate closes again and you are unreachable. The DMZ feature probably only works for TCP and UDP. For IPIP, you are just relying on the standard NAT feature which of course is causing the problem described above. Rob

1 0

Re: [44net] NTP Server Test
by Rob Janssen 30 Jan '16

30 Jan '16

> Subject: > [44net] NTP Server Test > From: > lleachii(a)aol.com > Date: > 01/30/2016 09:13 AM > > To: > 44net(a)hamradio.ucsd.edu > > > 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 > Like the others, I cannot reach your server. However, when people want to have an NTP server from AMPRnet, we are running one on our gateway in Amsterdam at 44.137.0.1 It is referenced off 8 stratum-1 GPS-locked servers that are part of our co-channel diversity FM repeater network. remote refid st t when poll reach delay offset jitter ============================================================================== *44.137.8.140 .PPS. 1 u 414 1024 377 4.918 -0.052 0.079 -44.137.41.97 .PPS. 1 u 689 1024 377 13.387 -1.770 0.104 +44.137.72.10 44.137.72.16 2 u 490 1024 377 8.022 0.037 0.045 -44.137.72.16 .PPS. 1 u 842 1024 377 7.952 0.036 0.077 -44.137.72.130 .PPS. 1 u 123 1024 377 8.604 -0.122 0.036 +44.137.72.131 .PPS. 1 u 489 1024 377 8.756 -0.135 0.055 -44.137.73.3 .PPS. 1 u 993 1024 377 13.443 0.128 0.022 -44.137.73.4 .PPS. 1 u 674 1024 377 13.358 0.158 0.064 -44.137.73.50 .PPS. 1 u 158 1024 377 18.075 0.249 0.173 Only (S)NTP. So no Time/TCP, Time/UDP or other time protocols. Rob

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net