44net April 2014

44net@mailman.ampr.org

62 participants
77 discussions

Re: [44net] 44Net Digest, Vol 3, Issue 71
by Rob Janssen 12 Apr '14

12 Apr '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] ampr-ripd for openwrt > From: > marius(a)yo2loj.ro > Date: > 04/12/2014 12:56 PM > > To: > "AMPRNet working group" <44net(a)hamradio.ucsd.edu> > > > For the Mikrotik mipsbe metarouter architecture, I have a repository > online, where you can find ampr-ripd included: > http://yo2loj.ro/openwrt/mr-mips/packages/ > > I asked the question for someone else, a newcomer in gateway land. I forgot to ask which hardware architecture he uses, as I first assumed that openwrt always means those modified Linksys routers. The above list has an ampr-ripd with version 1.6 but a recent date. Is it really 1.6 or is it the latest version? Rob

2 1

Re: [44net] 44Net Digest, Vol 3, Issue 71
by Rob Janssen 12 Apr '14

12 Apr '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] syn and such attacks on 44 net lately ? > From: > Gustavo Ponza <g.ponza(a)tin.it> > Date: > 04/12/2014 07:31 PM > > To: > 44net(a)hamradio.ucsd.edu > > > Hi Maiko and all, > >> Anyone else noticing the SYN and FIN WAIT 1 status on their >> 44 systems lately ? Telnet, Smtp, HTTP, and such. Seems to >> be a 'bit' heavy this past few weeks. >> >> Maiko / VE4KLM > > just reported several times publicly and privately with no reply ... :) > Just look at someone of that below. > > gus i0ojj There are at least two different kinds of attack: 1. the ones that try to connect to your system to scan for vulnerabilities (including Heartbleed) 2. the ones that try to use your system for reflection to another victim. I have seen many of the second kind lately. Note that it is no use to complain to the owner of the "sending address" in this case, because it is spoofed and not the real sender. it is the intended victim of the attack! The symptom is many incoming connections in SYN_RECV state in the netstat -t output. What happens is you receive a SYN with a spoofed sender address, and you are supposed to send a number of SYN ACK packets to the "sender". As this is done repeatedly and to many different destinations, the "sender" (the victim) is hammered with traffic. The real cause of this problem is the lack of uptake of BCP38 (SAF, source address filtering). While "we" are sometimes suffering because of source address filtering when we want to dump traffic sourced in net 44 directly on the internet (instead of tunneling it back via amprgw), SAF in fact is a very good thing, and providers not doing it should be convinced to implement it to end those spoofed address attacks. Back to the SYN problem. I see two different schemes of this attack: 1. the SYN packets are sent with a source port that is a well-known service, like 80, 443, 119, 110 2. the SYN packets are sent with the usual random high-numbered port. The first ones are easily filtered with an iptables rule: iptables -A (chainname) -p tcp --syn -m multiport --source-ports 0:1023 -j DROP This blocks all connects from a privileged port, and should not hurt any normal operation. In fact it would be good if this rule was applied externally at amprgw, so that all this crap does not enter our tunnels. I have added it to several of my systems and the systems at work already. The second ones are a bit more tricky. You cannot simply block those as they look similar to normal traffic. However, if you have the typical low-traffic amateur radio system, you can use the "recent" module to limit unanswered traffic from the same IP address. iptables -A (chainname) -p tcp ! --syn -m recent --name tcp --remove iptables -A (chainname) -p tcp --syn -m recent --name tcp --set iptables -A (chainname) -p tcp --syn -m recent --name tcp --update --seconds 30 --hitcount 5 -j DROP What we do here is limit the number of "open" SYN packets from the same IP address to 5 in 30 seconds. When a SYN comes in, the second and third rules setup a bucket for the sending address in which those events are counted. When another packet comes in, the first rule resets that bucket and traffic from that system is allowed. So for normal incoming connections there is no impact, as the SYN/SYN ACK/ACK 3-way handshake quickly removes the special treatment of the client. However, for those spoofed SYN packets for which there is never any followup traffic, after 5 of those from the same system the "sender" is blocked from further access until they stop doing that for another 30 seconds. Works fine, this rule blocks tens of thousands of packets a day here and ends the issue of many incoming connections in SYN_RECV state. Note that these rules (or at least the first one) should be inserted BEFORE the typical "-m state -state ESTABLISHED,RELATED -j ACCEPT" rule that is often near the beginning of the list, because that rule will match on the followup packets of the connection so the --remove rule will never be reached, and the result would be that a client cannot make more than 5 connects in 30 seconds. Not a problem for telnet, but will be a problem when you run a website. Unfortunately this kind of "recent traffic" rule does not lend itself well for application at amprgw, because it has to maintain a lot of state and will probably be overloaded by the traffic being handled there. Rob

2 1

44.133.48.66 !!!
by Maiko Langelaar 12 Apr '14

12 Apr '14

Good afternoon, It would see that 44.133.48.66 is popping, snmpding, and other amounts of traffic from time to time to various ampr.org systems and doing so *without warning* type of thing. I just got hit with a bunch of SNMP requests, others have been hit with POP requests. Can anyone find out who the owner of that particular system or network is, so that I can contact the entity or person. Or perhaps a bit more draconian, can someone deal with it. Thanks in advance. Maiko Langelaar VE4KLM

4 5

ampr-ripd for openwrt
by Rob Janssen 12 Apr '14

12 Apr '14

Does someone have a binary of ampr-ripd for openwrt available on the net? It would save the effort of gearing up a development environment only to compile this little program... Rob

2 1

Re: [44net] Portal doesn't allow IPIP anycast via 44net
by kb9mwr＠gmail.com 12 Apr '14

12 Apr '14

I was guessing most folks who run NOS these days do it on top of Linux. I don't have a problem with anyone who still wants to run it. So if you still doing the routing (encap stuff) on the NOS side, maybe its time to re think that. Just point the NOS default routes to the Linux and let it do what it does best. Doing the routing on the NOS side of things seems a bit backwards these days (cough encap.txt) Of course you cannot do that if you are still running NOS on an old DOS box. So is that why we still export the route addprivate nos format stuff on the portal? >> Alright how many people are still running some sort of NOS on DOS? >> >> Time to move forward folks and use the excellent routing capabilities of Linux. >> And let those who still need it the old way learn the pain of >> conversion. Give them a reason to upgrade/ move forward. >> >> </Off my soap box> >Or we can go the other way... Turn off all these fancy routers and >protocols and turn the radios back on... We never had better RF >technology available for cheap and I don't see much use being made of >it.. > >A CONVERS session on JNOS on a DOS box at 1200 baud can be more >'special' then thousands of words on these commercial infrastructure >systems with canned tools... > >Bill, WA7NWP > >PS. New toys arrived this week and with a bit of luck they'll be on >the air. 9k6 (and maybe much much more) in the 440 band for $80 a >side - just plug the USB into a RPI or whatever... ________________________________

1 0

Wiki issues
by Neil Johnson 11 Apr '14

11 Apr '14

I can see the main page, but if I click on a link the following page displays no text. -Neil -- Neil Johnson http://erudicon.com

2 2

Re: [44net] Portal doesn't allow IPIP anycast via 44net
by Bryan Fields 11 Apr '14

11 Apr '14

On 4/11/14, 12:26 PM, lleachii(a)aol.com wrote: > TOS section 7c requires him to provide an AMPRNet connection for AMPR > devices local to him; but not necessarily via rip44. Since its not valid at > this time to tunnel to a 44subnet via a 44 address, I don't see how he's in > compliance (save via RF, which is their local AMPRNet anyway). Where would hamradio be with out armchair lawyers? I love this hobby. If he's using 44net space and announcing it to the internet via BGP he is providing access to the users behind his BGP router that have AMPRnet addresses. Sure they may not have access to the rest of AMPRnet via the IPIP routes, but that's optional. I'd even venture to guess most hams on his system won't care/know that it's missing the IPIP tunnels. People using AMPRnet space in BGP are most likely concerned with providing access to the internet via ham radio, not accessing slow 9600 baud links from the internet. > Bart also mentioned: > >>>>> It allows our microwave network to remain connected to the rest of >>>>> AMPRnet as long as we have at least 1 ISP that isn't dead. > **The problem would also solved if he announces 209.189.196.68/32 on both > ISP connections.** A /32 is going to be route filtered, and it's not his IP space, it's a /30 or /31 from his upstream BGP peer. So no, this is not possible. The entire *IDEA* of BGP is to allow you to control your own redundancy and peering to the routing table. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

3 2

Re: [44net] Portal doesn't allow IPIP anycast via 44net
by kb9mwr＠gmail.com 11 Apr '14

11 Apr '14

Alright how many people are still running some sort of NOS on DOS? Time to move forward folks and use the excellent routing capabilities of Linux. Every time I look at the encap.txt and see stuff like: route addprivate 44.129/16 encap 118.22.1.194 I ask myself why do we still export is this way. I say export it as: ip route add 44.129.0.0/16 via 118.22.1.194 dev tunl0 onlink And let those who still need it the old way learn the pain of conversion. Give them a reason to upgrade/ move forward. </Off my soap box> ---- Quote--- Bart, Don brought up some good points. In addition: - non Linux-kernel routers (e.g. JNOS and TNOS) would not be able to route to you as they would need to be reprogrammed and recompiled (FYI, JNOS and TNOS is the most commonly used AMPR Network OS)

2 1

NANOG 61 June 2-4
by Bryan Fields 11 Apr '14

11 Apr '14

https://www.nanog.org/meetings/nanog61/home I'll be here, and Tim Osbourn W7RSZ as well. Is there anyone else going? I'd enjoy having a dinner or lunch breakout to meet with some of the AMPRnet users at NANOG. Post if you're going and we'll arrange something if we have some interest. 73's -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

4 3

Re: [44net] Portal doesn't allow IPIP anycast via 44net
by Bryan Fields 11 Apr '14

11 Apr '14

On 4/11/14, 11:37 AM, lleachii(a)aol.com wrote: > It's much easier, and doesn't require a total reconfiguration of AMPR to > simply have Bart run a 44GW speaking rip 44 using his Public IP address as > the GWip - be advised that he is required to do so under the Terms of > Service: That's a heck of a jump in logic. I see nothing in there requiring anyone to run rip44d. All it means is you need have the ability of supplying connectivity to other hams in your area out of your subnet. I'm doing this via GRE and VPN dialers. I have little interest in connecting to the rest of AMPRnet hosts who are not rotatable in the global table. My interest is supplying access over RF using the AMPR space and setting up routed redundant multi-megabit links. What AMPRnet has running now is akin to the GRX network IMO. It's private with one interconnection to the internet. 73's -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net April 2014