On 4/11/14, 12:04 PM, Bart Kus wrote:
> Well, IPIP itself is not the problem. It avoids the costs of Internet
> BGP peering. What is a problem is the lack of dead-peer-detection
> between IPIP gateways. If intra-AMPR BGP peering was actually deployed
> as part of the general recommendations then we wouldn't need to anycast
> to achieve redundancy. But as it stands, the deployed technologies are
> very light, and anycasting our IPIP endpoint is the easiest way to
> …
[View More]achieve the desired redundancy. We do plan to make special BGP+IPSec
> arrangements with select AMPRnet peers to further improve our
> availability and security, but there's no need to do any of that work on
> the mailing list.
I'd say we should keep it on the mailing list. I'm very interested in what
others are doing with BGP announced AMPRnet space!
I'd be interested in interconnecting if you need a gateway or something. I've
got a good relationship with my upstream in Tampa. Granted the latency to WA
is a bit much :)
FWIW I'll be in Belview for NANOG 61 in June.
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
[View Less]
Does such exist.... Has anyone created..... can said code be easily
separated / compiled separately.....
What I'm looking for is a "version" of nos that is devoid of any of it's
networking functionality or well at least the bottom 3 layers of the OSI
stack. The issue being that NOS has long been a standard and familiar
interface for networked amateur radio BBS systems. I'm good with that.
over the last 20+ years though we have moved to computers and operating
systems that are much more …
[View More]capable, especially when it comes to processing
speed, memory, and a decent built in network stack. I now no longer need
my application (BBS) to handle the network layer stuff but simply need what
amounts to a good BBS interface. can/has this functionality be/been
gutted/separated out from the NOS code base such that I can end up with an
application that simply is setup to listen on the proper port via init.d
and present *ONLY* the familiar bbs interface while the OS handles all the
networking stuff and the application not even being capable of such.
Eric
[View Less]
Good day to all,
Unfortunately my subscription options were set to nomail, so I have
not been following posts very reliably this past few months. Anyways,
just thought I would dig through the digest and comment on stuff.
> Doing the routing on the NOS side of things seems a bit backwards
> these days (cough encap.txt)
You don't have to use encap.txt anymore, depending on your
configuration. Brian introduced AMPRnet RIP broadcasts a few
years ago. Some of us use those now to update our …
[View More]NOS routes.
> Of course you cannot do that if you are still running NOS
> on an old DOS box.
Technically speaking you could always do encap.txt on a NOS
system running in DOS - I did it that way over 12 years ago.
> Does such exist.... Has anyone created..... can said code
> be easily separated / compiled separately.....
The irony is (and there was a lot of criticism towards the authors
at the time, this was before I took it over in 2004), the original
NOS was actually 'hacked' to give it BBS functionality, as well as
a few other features. Anythings possible, but removing the NOS from
NOS (think about it, that's what it would come down to) would be a
big waste of time and all you would have left is a BBS 'hack'.
Sound to me perhaps FBB is more what you're looking for. It's a BBS
first and foremost. Actually, how about BCM (Baybox) or OpenBCM out
of Europe. It's pretty slick stuff actually, check it out.
> don't say whether you're interested in a Windows or a Linux based
Believe it or not I have a text (console) based Windows (yeah, true
native windows not a DOS compile) version of JNOS, experimental like
all of the NOS stuff is, even got WINMOR running B2F forwarding with
RMS stations in both my windows and linux versions. Again, I'm an
experimenter so the software (like usual NOS style) is not always
the most user friendly. I'm just going to say, I'm encouraged for
my own ham radio needs. Multipsk as a packet modem works too :)
> This appears to be the only "maintained" version of JNOS
I took over from James Dugal in 2004, and rebranded it as JNOS 2.0, you
can see it in the credits on my official site for JNOS 2.0. James passed
away years ago, passing the tourch so to speak, as others did to him as
well when they got tired of working on it, or just had to give it up.
My primary development platform for years was LINUX, it still is, just
that I feel I need to get moving into the Windows (very untapped user
base) domain. Just wish I had more time to devote to it, I'm a busy
family and working man too like a lot of the people on this group.
> haven't looked at the code to see how deep into the stack he's
> getting but his dependence on winp cap indicates it still has some
> degree of coupling to layer 3.
The windows version I started with WinPcap cause I wanted a quick way
to tie into the WIN32 tcp stack. I've tried to do raw sockets and it's
just plain ugly and I got frustrated. The WinPcap has turned out to be
pretty decent for what I need.
I use the original NOS ip stack code, no windows IP or TCP functions,
it's all NOS (yeah obsolete, exciting eh) code for ip routing, and
such.
Anyways, just thought I would try and clarify a few things. Feel free
to ask me if you have more questions about all of this.
With kind regards,
Maiko Langelaar / VE4KLM
* http://www.langelaar.net/projects/jnos2
[View Less]
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 …
[View More]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
[View Less]
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 / …
[View More]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
[View Less]
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
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
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 …
[View More]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...
________________________________
[View Less]
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
…
[View More]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
[View Less]
