44net

44net@mailman.ampr.org

3198 discussions

Re: [44net] Co-located point of presence for 44net
by Rob Janssen 25 Sep '16

25 Sep '16

> So my question is this: Is what I want to do feasable as a way to get a > static address and act as an AMPR gateway? Yes, this works quite well. I have the same setup here. I have a colocated Raspberry Pi that is on the IPIP mesh using ampr-ripd in the standard setup that is described on the WiKi, and it serves my subnet and a couple of /32 addresses. My subnet is tunneled to my home using IPsec in AH/Tunnel mode. Using AH instead of ESP (as is usually used) reduces CPU usage, and encryption is not required for this purpose anyway. At home I have a MikroTik router. I do have a fixed IP at home so IPsec is easy, when you don't have that it may be easier to use a VPN that does not care about addresses, e.g. OpenVPN. I also run a couple of applications locally on the Pi, hence the /32 addresses. Today, thanks to Marius' work, it is also possible to use a MikroTik router instead of the Raspberry Pi. It may be easier to configure and is available in rackmount formfactor. Rob

1 0

Co-located point of presence for 44net
by Tom C 24 Sep '16

24 Sep '16

Greetings. I'm somewhat new to the list and would like to join the network. I am not able to get a static address from my ISP, well I could, but I'd have to get a business account and my speeds would be a lot slower than they are now. I'm considering getting a VPS or a colocated raspberry pi to act as a vpn server and my point of presence to connect to my network via a tunnel. A rough ASCII diagram follows: (^^^^^^^^^^^^^^^^^^^^^^^^^^^^) ( IPIP/Tun0/VPN Svr <<--- ) ( Ieth0 RasPi in DATA CENTER) (vvIvvvvvvvvvvvvvvvvvvvvvvvvv) I (^^I^^^^^^^^^^) (^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^) ( Internet )====(>LinuxRouter/VPN/Tun0/eth2-->>44.98.63.0/29) (vvIvvvvvvvvvv) (vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv) I (^^I^^^^^^^^) (IPIP @ SDSU) ( 44/8 ) (vvvvvvvvvvv) My intent is to initilly have connectivity for a small LAN and then build it out over AX25 for my local area. I've run linux as my router/firewall (iptables and ipset) since 2012, but have not done much with "ip route" or "route", tunneling or anything with bridging but I did play a little with GRE and OpenSwan a couple of years ago. My thinking is building tun0/eth0 bridge and feeding that through the VPN to the distant RasPi which would vbidge the other end of the connection to the IPIP tunnel. So my question is this: Is what I want to do feasable as a way to get a static address and act as an AMPR gateway? Any suggestions, hints or approaches to prod me in the right direction to get me going would be appreciated. -- tom 73 de N2XU/Tom Cardinal/MSgt USAF (Ret)/BSCS/Security+/IPv6 Certified

1 0

New 44.0.0.0 /24 request
by John Ricketts 24 Sep '16

24 Sep '16

All, KD5ZZH here. I currently run an ISP (AS 62744) and I would like to provide an exit bridge to the public internet and link the Tom Green<x-apple-data-detectors://0> County, TX area as well. How does one go about getting a /24 out of the block? John Ricketts, PhD Quintex Alliance Consulting (325) 263-3488<tel:(325)%20263-3488>

3 3

ampr-ripd update 1.14
by Marius Petrescu 23 Sep '16

23 Sep '16

Hello all, It seems that the ampr-ripd daemon will be included into Debian by the DebianHams group. To be able to fit into an easy setup for all fellow hams, after discussions with Brian Kantor and Ana C. Custura taking care of packackaging it, we reached the following conclusions: - The RIP password was never actually meant as a security feature, more a validation mechanism - Everyone having access to the RIP data can actually extract the password by sniffing the stream - Since access to the network implies a gateway registration, and the RIP sources are well defined and restricted, the password could be ignored. Now, as a result of these discussions, I made some changes to the ampr-ripd daemon: - the RIP password is now included into the source file. The RIP data will continue to be validated against this password. - the password option can be omitted, but is still there for compatibility reasons and if it would be necessary to change the password at a later time - password discovery via debug mode still works - a man page for ampr-ripd was added (Tnx. Ana) You can get the updated ampr-ripd from: Internet: http://www.yo2loj.ro/hamprojects/ampr-ripd-1.14.tgz 44Net: http://yo2tm.ampr.org/hamprojects/ampr-ripd-1.14.tgz or from GitHub: git clone https://github.com/yo2loj/ampr-ripd.git Have fun, Marius, YO2LOJ

5 5

Re: [44net] RIPv4 security
by Brian Kantor 23 Sep '16

23 Sep '16

Gentlemen, if we cannot discuss a matter calmly and rationally, we should not discuss it at all. What we are after here is light, not heat. Incendiary comments are not welcome on this mailing list. Control yourselves. - Brian

4 3

Portal (was: RIPv4 security)
by Rob Janssen 23 Sep '16

23 Sep '16

It would still be an option to merge the portal and hamnetdb... Hamnetdb is much more capable when managing subnets, and it is open. There is an issue with scalability (it always shows you all the data it has when first opening a page, before you have applied a search filter, which really loads older computers), so there may be surprises when all of the world's data is loaded into it. The "gateways" functionality is not yet there, so it would have to be implemented. But issues like the one that started this discussion are easier to resolve in hamnetdb because every object has a list of maintainers, which the owner or a sufficiently privileged person can modify. So you can easily hand over control over your subnet (e.g. to include it in a gateway) to someone else without sysop involvement. Rob

2 1

RIPv4 security
by Rob Janssen 23 Sep '16

23 Sep '16

> That's fine for YOUR users because you keep a separate database of what > is allocated and what is not in your country's subnet, but I and many of > the other coordinators use the subnet allocations in the portal as the > authority for what is allocated and what is available. It is essential > that all subnets be registered in the portal in order for me to do my job. For me, the portal is not usable as the only registry of information, because it does not do DNS and DNS is essential for the functioning of the network. (not only because you want to name your system, but also because being in DNS is used as a filter to allow traffic through the gateway) So I need to keep two different registries anyway, and it does not matter how much of the information is in the portal and how much is in my own database. Furthermore, for allocating subnets and addresses I need an easily browsable view on the existing allocations including comments like regional names, to be able to decide where to put the new entry. To me, a simple "hosts" file edited in vi gives more overview than most point and click interfaces, including even that of the hamnetdb (which is way better than the portal in this regard). This solution also reduces the effort when making bulk changes like moving an entire subnet, doing cleanups like I did some time ago, or even transfer of the existing allocations into the portal. Sure they would be possible with a tool like this but it would either need a lot more features (and thus coding) or it would have to offer direct access to the database for queries. Rob

2 1

Re: [44net] RIPv4 security
by Bryan Fields 23 Sep '16

23 Sep '16

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

1 0

Re: [44net] RIPv4 security
by Rob Janssen 23 Sep '16

23 Sep '16

>>/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

5 5

RIPv4 security
by Jakub Kramarz 22 Sep '16

22 Sep '16

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.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net