44net

44net@mailman.ampr.org

1 participants
3179 discussions

by Jakub Kramarz

I hope that I'm not breaking thread continuity, but I've subscribed requesting daily batches and don't know how to change it. > > As it is UDP based and relies on source of UDP packets, which is easy to > > spoof, current routing infrastructure is vulnerable to unrestricted > > injecting of 44/8 routes to it's gateways - anybody can send forged RIP > > updates to them. > Here I don't think the situation is that critical. The RIP updates are > sent via tunnel, and should be accepted only from the ampr-gw tunnel > interface. The attacker needs actually to block out original IPIP > traffic and spoof the IPIP tunnel to get fake RIP data into the network. > This is a little harder than just sending a bunch of UDP packets to a host. It's just as hard as decapsulating these packages in ampr-ripd. There's no need to disturb communication, as IPIP tunnel is not being established - it's just another IP header one can easily spoof, there's no authenticity control. This kind of DoS attack on AMPRnet won't be very interesting, but may be quite annoying to gateway operators. On the other side, it may result in sending unsolicited IPIP traffic to random hosts. Firewalling (by restricting pool of destination hosts for protocol 4) would do the job of limiting such activity, but on the other hand would be one step back, as list of gateways would need maintenance by hand. > I really don't see the point of doing that. Crackers want benefits from > their work: e-mail collecting, snmp access, spamming, not the glory of > sending data to a compromised system to which they are the only ones > having access. And creating a DOS attack like this on an APMPR host is > nothing interesting. So I do. Can't find any other use than a bit creepy SMURF-like DDoS. > So this is a non-issue unless > there are unassigned subnets floating around in the portal for people to > grab. There's a lot of such subnets. I just got banned for routing one of them through 192.168.0.1.

8 years, 6 months

RIPv4 security

by Jakub Kramarz

Password authentication mechanism in RIPv2 is meant to protect against accidental misconfigurations and is the only way of configuring ampr-ripd routing. As it is UDP based and relies on source of UDP packets, which is easy to spoof, current routing infrastructure is vulnerable to unrestricted injecting of 44/8 routes to it's gateways - anybody can send forged RIP updates to them. Furthermore, portal.ampr.org allows anybody with valid email address to route any 44/8 subnet through any IP address, not only subnets assigned to account in use. There're no restrictions to do so and it will stay there and get broadcasted until somebody notice. So, there're at last two ways of disrupting whole AMPRnet network topology and both will make nodes send traffic to any hosts. Is it really the way it should be? If changing RIP to some more secure protocol is not an option, maybe at last implementing RFC4822 would do the job?

8 years, 6 months

Re: [44net] ampr-ripd update 1.14

by Rob Janssen

> Subject: > Re: [44net] ampr-ripd update 1.14 > From: > Marius Petrescu <marius(a)yo2loj.ro> > Date: > 09/21/2016 06:59 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu>, "Ana C. Custura" <ana(a)netstat.org.uk> > > > On my server running Debian 8 with kernel 3.16.0-4-amd64 it works > without the '-r' flag. > > I actually wanted to remove that flag, but then it will break the > scripts using it. > > I will make a new release that ignores that flag but still accepts it as > parameter, but runs always in raw mode. > > I think this would be the proper approach. Ok, the multicast mode of course is a good thing, but it has caused some strange behaviour in the past. You could of course keep the old code in there using some #ifdef option for those that want to try it. Or introduce a new flag that switches from raw to multicast mode. Raw mode always works, but in some cases may have some more CPU overhead. Not sure if it is a noticable difference... Rob

8 years, 6 months

ampr-ripd 1.15

by Marius Petrescu

Hello, Another update... To keep everything as simple as possible and since this seem to work on all systems, only raw socket mode is used (parameter -r is ignored, so you don't have to change anything in your startup scripts). Please note that no functionality has actually changed compared to 1.13, so if you are happy with your current setup, no change is needed. These changes are basically aimed to newcomers and will bring nothing new to existing users. Internet: http://www.yo2loj.ro/hamprojects/ampr-ripd-1.15.tgz 44Net: http://yo2tm.ampr.org/hamprojects/ampr-ripd-1.15.tgz or from GitHub: git clone https://github.com/yo2loj/ampr-ripd.git Have fun, Marius, YO2LOJ

8 years, 7 months

Re: [44net] ampr-ripd update 1.14

by Rob Janssen

I think it is a good idea! The password has often confused newcomers and made it harder to debug an intial setup. How about the -r flag? Some time ago it became necessary for me to use it, apparently due to changes in the kernel around multicasting. Is this still the current situation on the latest Debian release? Or can ampr-ripd again work without -r? Depending on this, it may be good to make some change in that default too. Rob

8 years, 7 months

Greetings from Poland!

by Jakub Kramarz

Dear 44net group subscribers, My name is Jakub Kramarz (SP0NGE) and I'm writting on behalf of Hackerspace Kraków foundation (callsign SP9HACK) in Poland and I'd like to say hello to this community :-) We're a group of Linux and networking professionals, web and embedded developers, security researchers and finally radioamatours who has recently started our small, personal war to bring HAM radio back to young people in our country. In recent time, we've successfully: - in cooperation with SP9KGP club, we held 3 comprehensive HAM radio courses in Kraków, converting 40 enthusiasts to fully-fledged radio operators (~ the number of Polish Amateur Radio Union's new members in whole country), - held an important role in securing radio communication during World Youth Day 2016, - operated multiple occasional stations (supporting Great Orchestra of Christmas Charity, promoting Woodstock Festival Poland, ...), - supported Radioreaktywacja (Radio Reactivation) initiative, who "infects" the youngest with our hobby, by sharing hardware and knowledge, - and, finally, contributed to numerous open source and open hardware radio-related projects, eg. mcHF QRP firmware I hope we'll be able also take a part in AMPRNet project and contribute to digital communications over radio. Serdecznie pozdrawiam / Best regards, Jakub Kramarz http://about.me/jkramarz Sent from Makita TD090DWE impact driver

8 years, 7 months

Posting from HamWAN Tampa @ DCC

by Bryan Fields

I'm on the 15th floor, 17 Miles from Tampa in St Petersburg, getting 20mbit/s with some refraction through glass in the club here. 73's -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net

8 years, 7 months

rip down ?

by Maiko Langelaar

Did we loose the rip broadcast ? Maiko

8 years, 7 months

Re: [44net] getting rip data fron the non ampr address of ucsd gw?

by Rob Janssen

> Please be aware the protocol is RIP44, **NOT** RIPv2. You must install > and run a daemon that processes RIP44 (e.g. ampr-ripd and rip44d). He uses a solution devised by Marius to work around that problem on a MikroTik router. Rob

8 years, 7 months

Re: [44net] getting rip data fron the non ampr address of ucsd gw?

by lleachii＠aol.com

Ronen, Please be aware the protocol is RIP44, **NOT** RIPv2. You must install and run a daemon that processes RIP44 (e.g. ampr-ripd and rip44d). See: http://wiki.ampr.org/wiki/RIP 73, -Lynwood KB3VWG

8 years, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net