> Has anyone else noted problems with the ethernet alias functionality in
> recent Linux kernels ? I've just done an update on my tunnel server
> (pogoplug E02 running Debian 8 with kernel 4.4.0-kirkwood) and within a
> day or so the 44net alias disappears. Nothing I can see in any of the
> logs. Replacing the alias via 'ip addr add 44.135.190.17/32 dev eth0:1'
> is enough to fix it, might have to hack into a cron job :-/R
Why are you still using ethernet aliases? This was originally a hack to
be able to have multiple IP addresses on a single interface (using ifconfig)
but since the introduction of the iproute2 package (which you apparently use,
as it provides the "ip" command) this is really not required anymore.
You can add addresses to eth0 without making an eth0:1 alias first.
Rob
> In any case, your subnet will be connected to the Internet by at most
> ONE method: Radio, Tunnel, or Direct, and might not be connected at all,
> so select at most ONE of the connection method boxes in the allocation
> request. (I have asked that these selections be changed to a pulldown
> list or radio buttons so that it is impossible to select more than one;
> until that happens, requests having more than one box checked are likely
> to be rejected.)
> - Brian
Why is that??
We have been happily connected on both BGP and Tunnel for some time.
The gateways that are part of the tunnel mesh route to us by Tunnel and
the remainder of internet routes directly. What is wrong with that?
Some gateways do not want to route directly ("only AMPRnet") so it is
preferred when they can use the Tunnel to the same network.
Rob
> The idea here is to support IPIP and BGP concurrently while preferring IPIP. Additionally we also
> run BGP over other tunnel protocols ( GRE, SSTP, etc) with more specific preferences depending on the
> agreement between the Ops. AFAICT this setup is the only way wich allows both the IPIP-only and the BGP-only
> sites to reach our networks.
> vy 73 de Marc, LX1DUC
I agree, that is the way it works best. We do that here as well, however now we just have a single routing
table where routes of different origin are stored at a different metric, so there is no fixed priority between
protocols anymore. The first decision is always made on subnet size (smaller subnet has preference), the
metric only comes into play when for some reason there are routes over two different protocols for the same
subnet, and then the metric decides what path to take (e.g. there is both an IPIP tunnel and a a route announced
with internal BGP on HAMNET). Normally these are error conditions.
The difference between those methods becomes important when e.g. a /20 subnet is IPIP tunneled and out of
that a /28 subnet is routed another way, e.g. over a GRE tunnel. This works without problem for us now.
(on systems that are both on the normal internet and on the IPIP mesh reachable from the entire internet,
with source address filtering at the provider, I normally have at least two different routing tables and
policy routing, but on a directly routed system this is not required)
Rob
> On Wed, Jun 15, 2016 at 11:46:30PM +0200, Rob Janssen wrote:
> >/A quick check returns the following subnets being both BGP and Tunnel routed: /
> I stand corrected.
> - Brian
Well, before I made that list I hoped that it would be much longer...
Maybe I made a mistake, it was quick cut-and-paste followed by edit and comm of the
list of bgp routed subnets and the routes in my personal gateway.
Anyone with a BGP subnet who has a full-featured system as a router should consider
to announce the same subnet on the IPIP mesh, I think.
(with a tunnel endpoint address outside net-44, certainly outside the subnet)
Rob
> I'm not saying you can't be connected in more than one way, I'm saying
> that it's a special case that is unusual enough that it ought not to be
> easy to mistakenly claim you're going to do. As far as I know, Rob, at
> the current moment you're the only one doing this.
Hmm... disappointing. I would hope everyone who is BGP routing would be
doing that. I am not the only one, your gateway is doing the same thing :-)
A quick check returns the following subnets being both BGP and Tunnel routed:
44.135.193.0/24
44.136.227.0/24
44.137.0.0/16
44.161.230.0/24
44.161.252.0/22
44.188.128.0/20
44.208.0.0/16
44.48.16.0/24
> Two or three times a week I get applications which have simplemindedly
> checked all three boxes. Most of these people have no idea what they're
> asking for
Most applications of portal registrations I get are wrong or strange.
It appears that the thing is confusing to newcomers.
> I'm open to any suggestion that will keep me from having to go through
> this process over and over again. Perhaps making 'Direct' a link which
> brings up an intermediate page which presents a blurb about what checking
> Direct actually means and demands that they confirm that they're really
> going to get a BGP announcement from their ISP? Other ideas?
It could be done with a simple Javascript on the page that presents a pop-up
or reveals some explanation on the page when the checkmark is set ON.
Hi there,
I actually have a /32 IP.
I plan to connect a few new machines to the network. So, I would need 3
or 4 new adresses.
I went to the web page, the the network tab, and click on 44.0.0.0 / 8
<https://portal.ampr.org/networks.php?a=request&id=1> Global link.
the smallest block that I can request through this link is a /24. but I
don't need a /24, only a /29
how can I send my request directly from the web site ?
thank you
--
73,
Pierre-Philippe
F4MZI
> Subject:
> Re: [44net] block allocation
> From:
> "Bill Buhler - AF7SJ" <af7sj(a)buhlerfamily.org>
> Date:
> 06/15/2016 06:47 PM
>
> To:
> "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu>
>
>
>
> Sorry if I'm unclear, so what I'm envisioning is setting up tunnels to the
> other participants of the 44 net who aren't directly internet routed and
> using RIP advertisement for them. Then traffic between me and them can
> bypass the main AMPR 44 net router, reducing latency and reducing bandwidth
> requirements at the root node.
>
> In other words, if anyone on my subnets access the internet it would route
> through our BGP connected uplink. If they were communicating with another
> subnet on the AMPRNet it would tunnel directly to them.
>
> What do you think?
>
> Bill Buhler
> AF7SJ
>
Indeed that is how we route here as well.
Please don't remove that from the Portal!
Rob
Pedro,
I use the following iptables rules on my router (this will work for any
console-based connection using TCP):
# DROPS MULTIPLE SSH CONNECTIONS FROM SAME IP
iptables -t filter -I FORWARD -p tcp --syn --dport 22 -i tunl0 -m
connlimit --connlimit-above 5 -j DROP
# DROPS MULTIPLE SSH ATTEMPTS FROM SAME IP WITHIN FIVE MINUTES
iptables -t filter -I FORWARD -p tcp --dport 22 -i tunl0 -m state
--state NEW -m recent --name sshconnect --update --seconds 300
--hitcount 5 -j DROP
iptables -t filter -I FORWARD -p tcp --dport 22 -i tunl0 -m state
--state NEW -m recent --name sshconnect --set
The first rule drops any connections greater then five. The last two
rules mark and drop more than five attempts from the same IP, for a
period of five minutes. You may wish to increase the time frame. I've
also added rules to block IPs that attempt to connect (or portscan) on
certain TCP and UDP ports (3389/tcp, 123/udp and 161/udp are common, for
example) for which I not post services as available to the AMPR
Community or the Public Internet connection.
In essence, even if an unauthorized person discovered the the port
without being firewalled by the portscan rule, they only get 5 chances,
with up to 5 concurrent connections at any given 5 minute interval (the
amount of attempts vary by implementation of server and client; but once
portscanned or disconnected from a given series of attempts, it counts
at one connection). Each reattempt after 5, restarts the 5 minute clock.
I also block Bogon IP addresses from entering tunl0:
# DROPS BOGONS ENTERING AMPRNet
# SEE http://www.team-cymru.org/Services/Bogons/bogon-bn-nonagg.txt
iptables -t raw -I PREROUTING -s 0.0.0.0/8 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 10.0.0.0/8 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 100.64.0.0/10 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 127.0.0.0/8 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 169.254.0.0/16 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 172.16.0.0/12 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 192.0.0.0/24 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 192.0.2.0/24 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 192.168.0.0/16 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 198.18.0.0/15 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 198.51.100.0/24 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 203.0.113.0/24 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 224.0.0.0/4 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 240.0.0.0/4 -i tunl0 -j DROP
I should note that in addition to this, console-based connections that I
use for administration only are moved to non-standard ports. So I added
another layer of protection with Security Through Obscurity (hence a
portscan rule).
73,
Lynwood
KB3VWG
Pedro:
I use Fail2Ban as well, and created my own Jail to help with this.
First, you will need to created jail. In the Fail2Ban directory "filter.d"
create a new text file called "jnos.conf"
In the file called "jnos.conf" place the following text.
_____________________________________
# Fail2Ban configuration file
#
# Author: Wm Lewis - KG6BAJ
#
# $Revision$
#
[Definition]
# Option: failregex
# Notes.: regex to match the password failures messages in the logfile. The
# host must be matched by a group named "host". The tag "<HOST>" can
# be used for standard IP/hostname matching and is only an alias for
# (?:::f{4,6}:)?(?P<host>[\w\-.^_]+)
# Values: TEXT
#
#
#
#
#
failregex = ^.* <HOST>:.*bad login.*$
# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
#
#
ignoreregex =
___________________________________
Next, after creating this file, in the main Fail2Ban directory, add the
following to your "jail.local" file.
______________________________
#
# Custom Made Bans
#
[jnos]
enabled = true
port = anyport
filter = jnos
logpath = /jnos/logs/nos.log
banaction = shorewall
action = %(action_mwl)s
maxretry = 2
______________________________
***
Note #1 : Your BANACTION may be different, depending on what your box is
using as a default ban method. Look at some of the other jail entries, (
like [postfix] ). You may need to change the BANACTION to match the others.
If your other jails are working with Fail2Bans default settings, you could
comment out the "banaction = shorewall" with a hash so it reads "#banaction
= shorewall" Obviously I use shorewall for my firewall. Your system may be
using something else.
Note #2 : Your path to your jnos log file may have to be tweaked to
something like "/jnos/logs/filename.extension"
I am using a version of jnos where I can specify that jnos logs are called
"nos.log" and rotated every 24 hours. Your jnos may be custom built to call
the logs something else.
After you've install the "jnos.conf" jail file, and added the jnos jail
settings, then restart Fail2Ban. Assuming you've made any appropriate
directory tweaks needed to what I supplied, and assuming you've also
adjusted your "jail.local" files email address to be your own, you should
start getting emails telling you when Fail2Ban bans an IP address from the
jnos logs for a bad login attempt.
Note, I put MAXRETRY = 2. This tells the jail to allow 2 bad login tries,
and then ban on the third bad attempt.
Hope this helps. I currently show over 1300 banned IP addresses from jnos
using this method.
73
Bill Lewis / KG6BAJ
At 11:39 AM 6/12/2016, you wrote:
>(Please trim inclusions from previous messages)
>_______________________________________________
>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
>_________________________________________
>44Net mailing list
>44Net(a)hamradio.ucsd.edu
>http://hamradio.ucsd.edu/mailman/listinfo/44net
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
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
