On 9/23/16 2:59 AM, G1FEF wrote:
> I get very fed up with folk like yourself making assumptions.
There is a simple way to shut me up.
> The reasons
> why the code is not yet open has nothing to do with me or my ego, there are
> other factors which you are not aware of that keep it like it is for now at
> least.
State them.
> I am an advocate of open source, I have, and do, contribute to open
> source. So please stop being so rude and obnoxious to me when a) you don’t
> know me and b) you do not know the full circumstance.
I see the evidence as presented. What is presented is you have some
"mystical" reason you refuse to be open with your code. This is
unacceptable. Can you logically argue it is not?
> Just take the time to
> look at life from someone else’s perspective for a change, how would you
> feel if people like yourselves were being so rude to you for trying to help
> out without being paid?
Having 44net over a barrel with code which we cannot audit or extend is not
helping; It's holding us back.
--
Bryan Fields
727-409-1194 - Voice
http://bryanfields.net
>>/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. />This is not true. By registering a gateway, you can use your assigned
>subnet through your registered gateway. But if that subnet is already
>assigned to a gateway, you can not assign it to your own gateway without
>deassigning it from the old gateway first.So this is a non-issue unless
>there are unassigned subnets floating around in the portal for people to
>grab. But these are mostly the result of misconfiguration and lack of
>knowledge, not the work of an attacker. And it will disrupt only that
>specific subnet.
Well, this issue is really there!
Recently I found that two users from the Netherlands had setup completely
bogus gateway entries, both stealing subnets belonging to others and routing
them to the 44.137.x.x address I have them as "the gateway external address".
Those were probably not malicious, they just did not understand the portal
and fiddled around a bit, and left it as it is once they did not understand
anymore what is happening.
I think the portal should not allow to route other people's subnets through
your own gateway without some consent from the subnet's owner, I think for some
time it was impossible to setup such entries, and people complained that they
needed this to route for others, and the check was removed again.
>So here we may need some improvement tot to allow e.g. assignements of
>national or regional subnets assigned to administrators to regular
>users, which are the most likely to float since they are not bound to
>any gateway.
Administering national and regional subnets is a real pain, as it is impossible
to manipulate the subnet structure without deleting it first, and ownership
of an entry cannot be transferred.
We all know how hard it is to get anything improved in the portal.
For now, I advise users to not register their subnets unless they want to
do IPIP tunneling.
W.r.t. the processing of RIP and IPIP traffic, you can do a lot with a
properly designed firewall. On my systems I accept only IPIP traffic from
gateways that I received before via RIP, and I accept RIP only from 44.0.0.1
on the IPIP interface. Maybe it would be possible to also check if the
traffic came from UCSD, I'll have to see how to check that in iptables.
(probably can be done with marking packets when they come in from UCSD,
then check the mark when they arrive on tunl0)
Rob
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.
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?
> 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
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
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
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
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
