44net September 2018

44net@mailman.ampr.org

20 participants
12 discussions

AX.25 with digital signatures and binary compression
by Quan Zhou 24 Sep '18

24 Sep '18

Hi all, I just saw this project on the Github, and it looks related and might be very interesting to you. Check it out! https://github.com/brannondorsey/chattervox An AX.25 packet radio chat protocol with support for digital signatures and binary compression. Like IRC over radio waves. Chattervox implements a minimal packet radio protocol on top of AX.25 that can be used with a terminal node controller (TNC) like Direwolf to transmit and receive digitally signed messages using audio frequency shift keying modulation (AFSK). In the United States, it's illegal to broadcast encrypted messages on amateur radio frequencies. Chattervox respects this law, while using elliptic curve cryptography and digital signatures to protect against message spoofing. -- Regards, Quan Zhou

2 1

Old newbe question.
by Jean Létourneau 24 Sep '18

24 Sep '18

Hello Group, I'd like to start experimenting building my own gateway (For learning purpose). I am reading different way to do it. Now I am in limbo bettwing : amprd 2.1 or Mikrotik RIPv2 AMPR Gateway Can you tell me your experience if you are using any of those options. Thank you 73 de Jean, VA2OM / VE2PKT -- Sysop de: VE2PKT (BBS), VE2PKT-13 (URONode) : VE2RCN-1, VE2RGM-1, VE2RGC-1, VE2RVA-1, (The-Net) : VE2PKT-9 (DXCluster), VE2PKT-10 (Winlink Gateway) RF: 147.435 Mhz (1200 Bps), Internet: Telnet://nodes-ve2pkt.dyndns.org <http://xrouter-ve2pkt.dyndns.org/> port 23 (Network Node) Telnet://fbb-ve2pkt.dyndns.org port 6300 (FBB BBS) Telnet://ve2pkt.dyndns.org port 9000 (DXCluster) E-Mail: packet: ve2pkt(a)ve2pkt.#qbc.qc.can.noam ampr net: ve2pkt(a)ve2pkt.ampr.org Inet: ve2pkt(a)gmail.com

1 0

Re: [44net] beware of IPIP scanner...
by Rob Janssen 22 Sep '18

22 Sep '18

> I'll read this carefully and figure it out...I was a BASIC and C++ > man...shouldn't be too hard. There is always a lot to learn... But in shell scripting, the following two do the same thing: if command then and: command if [ $? -eq 0 ] then Similarly: if ! command then is the same as: command if [ $? -ne 0 ] then It reads easier (once you know) and it avoids the situation where someone inadvertently puts something between the command and the 'if' that resets the $? e.g. some attempt at debugging like 'echo $?'. Rob

1 0

Re: [44net] beware of IPIP scanner...
by Rob Janssen 22 Sep '18

22 Sep '18

> Also, don't put a space between these two lines: > > ipset -N ipipfilter hash:ip 2>/dev/null > > if [ $? -eq 0 ] It would not be a problem to have a space between those, but of course there should not be other things, and having a space there maybe invites that. You would better write this as: if ipset -N ipipfilter hash:ip 2>/dev/null then ... else ... fi so it is clear what is going on and that the result $? of the ipset is to be processed by the if. Rob

2 1

Re: [44net] beware of IPIP scanner...
by Rob Janssen 22 Sep '18

22 Sep '18

> I believe a significant number of people who have AMPRNet addresses > and are BGP-connected really don't care much about communicating > with other IPIP mesh-connected hosts; their interest is the rest > of the Internet. Of course traffic mostly tends to be local and we see some IPIP mesh traffic to stations in the area that are IPIP mesh connected, including country networks like Germany. Most traffic is between AMPRnet addresses connected on radio or VPN, and between those and internet. It is understandable, because many IPIP mesh stations are small islands at the other side of the world and there is little chance that someone here would want to send a lot of data to them. On the other hand, connections internal to our network are used to interconnect repeaters (both voice and ATV) and for things like echolink and they transport a lot of data, mostly local. > Since there's no way to capture flow data for these folks, we'll > never know where their traffic is going. All we can do is guess > from anecdotal data. Maybe we can setup some ip flow export... Rob

2 1

Re: [44net] beware of IPIP scanner...
by lleachii＠aol.com 21 Sep '18

21 Sep '18

You can also use ipset in Linux and OpenWrt to filter from the RIP44 announcements. I only allow Protocol No. 4 from you all. I have the script; it's a slight modification of the one found on the Firewall Wiki. It can be set to run with the -x argument after each RIP44 announcement on ampr-ripd. Let me know and I'll send a TXT file of it. - Lynwood KB3VWG

4 5

Re: [44net] beware of IPIP scanner...
by Rob Janssen 21 Sep '18

21 Sep '18

> 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

9 10

Re: [44net] beware of IPIP scanner...
by Rob Janssen 20 Sep '18

20 Sep '18

> 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

2 1

beware of IPIP scanner...
by Rob Janssen 20 Sep '18

20 Sep '18

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

3 2

ARRL/TAPR Digital Communications Conference this weekend
by Brian Kantor 11 Sep '18

11 Sep '18

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

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net September 2018