Hello,
Since last months my JNOS MBOX is being attacked:
15:24:59 94.53.236.39:55248 - MBOX (supervisor) bad login
15:25:07 113.162.86.77:35247 - MBOX (support) bad login
15:25:09 190.140.17.22:53348 - MBOX (root) bad login
15:25:14 92.27.102.224:38887 - MBOX (support) bad login
15:25:14 114.109.125.48:42069 - MBOX (administrator) bad login
15:25:35 190.140.17.22:54146 - MBOX (root) bad login
15:25:50 92.27.102.224:40191 - MBOX (support) bad login
15:26:33 182.184.71.162:41259 - MBOX (root) bad login
15:26:49 182.184.71.162:41259 - MBOX (sh) bad login
15:26:50 89.22.213.165:33979 - MBOX (root) bad login
15:27:52 89.22.213.165:34979 - MBOX (root) bad login
None of the users tried have granted permit.
Installed fail2ban but not avail.
Attacking IPs change continuosly, routing to loopback no help
Due heavy load jnos eventually hangs.
Is it there any way/suggestion to stop this ?
Appreciate any help.
73, lu7abf, Pedro Converso
44.153.0.1 or conversoft.com.ar
pconver(a)gmail.com
I'm in the process of uploading an image of jessie for the RPI 3 to
https://sourceforge.net/projects/uronode/files/?source=navbar
If you wish to give it a go, that's where it'll be in approximately an
hour from this post. It's made from the kit sold near the TAPR booth at
this year's Hamvention at Dayton. You'll need to edit files
in /etc/ax25, /etc/postfix, and the file /usr/local/bin/ax25
other than that it should be ready to go. I did notice the main
repositories that came with it failed but an apt-get update fixed those
issues.
It was made using the uronode-pi.tgz script available in the tools
section of the same sf.net site.
--
<rhetorical> Why is it linux users can install and operate *any* version of M$
Windoze but the same can't be said in reverse?</rhetorical>
73 de Brian - N1URO
email: (see above)
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
http://uronode.sourceforge.nethttp://axmail.sourceforge.net
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
Greetings;
Is it me or does the Jessie version of the Banana Pi OS fail to include
kernel modules for the ax25 stack?.. and if so would a custom compile of
the kernel work?
Curious as if anyone else has gone through this one before. I know it's
fine with the Raspberry Pi but I'm not that familiar with a Banana Pi.
--
<rhetorical> Why is it linux users can install and operate *any* version of M$
Windoze but the same can't be said in reverse?</rhetorical>
73 de Brian - N1URO
email: (see above)
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
http://uronode.sourceforge.nethttp://axmail.sourceforge.net
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
Repeat (sorry about the formatting in my previous reposting)
-------- Forwarded Message --------
Subject: [Uronode] FCC serves Comcast
Date: Tue, 07 Jun 2016 13:19:12 -0400
From: Brian <n1uro(a)n1uro.ampr.org>
Reply-To: n1uro(a)n1uro.ampr.org
Organization: Amateur Radio Services
To: uronode(a)tapr.org, eastnet(a)n1uro.ampr.org
With regards to my dealings with Comcast and the faulty firmware
installed in their CPE devices, the FCC has informed me that they've
officially served Comcast with a direct order to resolve this problem or
respond to the complaint within 30 days of receipt of the complaint.
Since Comcast has admitted to me about their firmware bugs it'll be
interesting to see how this is accomplished and if it's within their 30
day window. A copy of their communication is included below.
"
Your Ticket No. 950514 was served on Comcast Cable Communications on Jun
7 for its review and response.
Comcast Cable Communications will likely contact you in an effort to
resolve your issue.
A response is due to the FCC no later than 30 days from today. Comcast
Cable Communications will respond to you directly by postal mail.
You can view a list of frequently asked questions at:
https://consumercomplaints.fcc.gov/hc/en-us/articles/205082880.
We appreciate your submission and help in furthering the FCC’s mission
on behalf of consumers.
This email is a service from FCC Complaints. Delivered by Zendesk
[NKGKWV-K6P1] "
This is somewhat positive news for us on the amprnet.
--
<rhetorical> Why is it linux users can install and operate *any* version of M$
Windoze but the same can't be said in reverse?</rhetorical>
73 de Brian - N1URO
email: (see above)
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
http://uronode.sourceforge.nethttp://axmail.sourceforge.net
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
I repost this from the UroNode list with permission from the author.
-------- Forwarded Message --------
Subject: [Uronode] FCC serves Comcast
Date: Tue, 07 Jun 2016 13:19:12 -0400
From: Brian <n1uro(a)n1uro.ampr.org>
n1uro(a)n1uro.ampr.org
With regards to my dealings with Comcast and the faulty firmware
installed in their CPE devices, the FCC has informed me that they've
officially served Comcast with a direct order to resolve this problem or
respond to the complaint within 30 days of receipt of the complaint.
Since Comcast has admitted to me about their firmware bugs it'll be
interesting to see how this is accomplished and if it's within their 30
day window. A copy of their communication is included below. " Your
Ticket No. 950514 was served on Comcast Cable Communications on Jun 7
for its review and response. Comcast Cable Communications will likely
contact you in an effort to resolve your issue. A response is due to the
FCC no later than 30 days from today. Comcast Cable Communications will
respond to you directly by postal mail. You can view a list of
frequently asked questions at:
https://consumercomplaints.fcc.gov/hc/en-us/articles/205082880. We
appreciate your submission and help in furthering the FCC’s mission on
behalf of consumers. This email is a service from FCC Complaints.
Delivered by Zendesk [NKGKWV-K6P1] " This is somewhat positive news for
us on the amprnet. -- <rhetorical> Why is it linux users can install and
operate *any* version of M$ Windoze but the same can't be said in
reverse?</rhetorical> 73 de Brian - N1URO email: (see above) Web:
http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2:
http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax &
URONode http://uronode.sourceforge.nethttp://axmail.sourceforge.net
AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland,
Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.
> On Tue, 2016-06-07 at 13:25 -0400, James Sharp wrote:
> >/I haven't run in to 443 "filtering", but I have run into instances where /> >/the ISP will drop TCP connections that are active for more than a few /> >/minutes, forcing openvpn to restart the connection. /
> Chances are your issue is the same as mine was. The CPE (router) has a
> built in watchdog timer that cuts all sockets after a few minutes. Using
> port 443 wouldn't make any difference. To the average web user this
> isn't an issue because each time a page is opened/refreshed a new socket
> is created, thus a new timer engages. The same may be said for services
> such as pop3/smtp/etc. where you're engaging a new socket each time you
> pop or send email. As long as the attachments aren't that big where you
> may exceed the watchdog's timer you'll never notice this.
So you can never download a file that takes more than a few minutes to complete?
Terrible! Now I understand why some companies try to enforce a "download manager"
to download a file of a measly 30 MB. So I can continue where I left off, yeah sure.
Well it is clear that everyone should devise their own solution for tunneling
and we should not change the global system to cater for limits that certain
users encounter. There will always be a more severe limitation found by someone.
It is better to solve these issues locally, where you have fellow users (victims)
that can understand what is and what isn't possible.
Colocated (virtual) servers with small storage capacity are very cheap today.
Usually they are the entry level of server location, the hoster advertises
their $3.99/mo server and knows that "everyone" will upgrade to more storage
and pay a lot extra. But for a gateway these are perfectly usable, you can
perfectly run it with 512MB RAM and 8GB disk. Put it in the IPIP mesh with
the usual tunl0 and ampr-ripd, and then everyone in the area can make their
VPN connection to there. Without NAT problems, and working round nasty ISPs.
(you can make a VPN over almost anything if you wish)
Rob
> Ok... all important points to understand and we absolutely rely and
> appreciate all your help on running the current AMPRGW solution. Before
> even jumping to conclusion, we'd need to know if GRE really would be
> more successful than IPIP. In Brian, N1URO's situation, I'm curious if
> a Comcast "Business" class service would remove some of these
> intentional filtering issues.
I don't think it will be an appreciable improvement.
I have experimented with GRE as the tunneling protocol (chosen exactly for this reason)
to connect local stations to our Dutch gateway, and at first the results looked promising,
but it did not take long before I got to the first case where plain GRE would not work
over a consumer NAT router. I think it is (at least here) never caused by intentional
ISP filtering, it is just caused by limitations of NAT routers that were only designed
for typical outgoing TCP and UDP connections only. In the mentioned case the router was
not even provided by the ISP, making malice even less likely.
I then changed setup to GRE over IPsec which works fine until now when in NAT-T mode,
but of course this is only suitable for use in a star configuration with connections
initiated from the users to some gateway. Not a replacement for the tunnel mesh.
I heard in Germany L2TP is used, I'm not sure if it is over IPsec or not.
Anyway, I use L2TP over IPsec (sometimes over NAT-T) at work, it works over any connection
but here as well it is a star topology.
We also offer OpenVPN connectivity at our gateway, in UDP mode only, and this too is
problem-free w.r.t. ISP routers. I don't believe a provider would (or even can?) filter
OpenVPN, certainly not when it would be run in TCP mode on port 443.
However, what is common in all these solutions is the star topology where the user behind
the crippled router connects outward to a well-connected system.
Of course we don't want to make the entire network into a star, but it could be an
idea to deploy more regional gateways like our national gateway, that are interconnected
by IPIP tunnels and optionally are BGP-routed on internet, and that offer services like
mentioned above and discussed before in this thread to regional users who for some reason
cannot run IPIP.
It works well here.
It is possible to deploy these on virtual servers that are quite inexpensive these
days, certainly when not doing BGP (not all those hosters will offer BGP of a /16 or
similar network via their routers, at an affordable price)
In my experience it is possible (although not for "I am not a programmer" types) to get
this working well on a Linux box. Setting up the VPN services and routing is quite well
described. Setting up a firewall requires some thought and monitoring, see the recent
incident with portmap. But this list is available for exchange of such information.
Rob
Thanks Brian, for your update.
Yes, the Portugese hamnet site is still under construcction. I notice you when this is up and running for update the link.
73’s
EB5JEQ
Message: 5
Date: Mon, 6 Jun 2016 09:22:08 -0700
From: Brian Kantor <Brian(a)UCSD.Edu>
To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
Subject: Re: [44net] Suggestions for the portal and the wiki
Message-ID: <20160606162208.GA28893(a)UCSD.Edu>
Content-Type: text/plain; charset=us-ascii
On Mon, Jun 06, 2016 at 02:31:39PM +0200, Miguel Bahi wrote:
> Please , I suggest add in this paragraf
> http://www.ampr.org/publications/
> add : Spanish hamnet www.hamnet.es
I have added the Spanish HAMNET to the list of links on the
publications page of www.ampr.org.
There is a link on the Spanish hamnet page to the Portuguese
hamnet page, but that site is still under construction so I
did not add that link to the link list on www.ampr.org.
- Brian
> A possible option could be SSTP, which works over regular TCP connections
> on port 443. But this is not well supported by the Linux world.
> Marius, YO2LOJ
SSTP is a star as well. In the open world there is OpenVPN over TCP port 443
when you want to run a VPN over TCP (I would not want that, but that is another topic).
However what it seems to come down to is that these issues can be solved locally.
A local Linux server or (e.g. MikroTik) router can be configured to be part of the
IPIP mesh and possibly be BGP routed, and then it can serve as a VPN server for
local users using whatever protocol(s) is or are locally preferred due to local
situation w.r.t. internet routers and/or filtering.
Rob
I concur with Bob. I've had Comcast before (though, I always used my own
device - connecting to a DOCSIS-to-Ethernet bridge/Cable Modem). I've
never had success using a consumer-grade router, unless it had DD-WRT or
OpenWRT installed, or I used a Linux server. Some D-Link devices permit
forwarding of protocols other than TCP/UDP, select the 'Other' option,
and place the number 4 in the box for IPENCAP.
Otherwise, most DMZ settings on consumer routers only forward TCP and
UDP traffic. Since 44net (including RIP44) packets are encapsulated
within IPENCAP (IP Protocol No. 4), you must forward that protocol. The
Iptables Firewall is the same as on other *nix devices. If you are
NATing to a device inside your LAN, the commands are similar to:
# iptables -t filter -I INPUT -p 4 -i eth0 -j ACCEPT
# iptables -t nat -I PREROUTING -p 4 -j DNAT --to-destination 192.0.2.8
Ensure that you are in fact seeing IPENCAP traffic entering your Local
Network at your device (e.g. the to-destination address specified).
Within the IPENCAP packets, you should see the password.
I should also note, that I currently use Verizon FiOS; and I noticed
when using their router as my border gateway, that the IPENCAP entry I
make is administratively removed (Verizon has a back-door into their
routers on tcp/4567) from upstream at intermittent times (I've been told
this is because it's 'hard' for the carrier to track and/or rate-limit
non TCP/UDP traffic). So be certain that your carrier it not removing
firewall entires, especially if you were successful in the past.
73,
- Lynwood
KB3VWG
