44net

44net@mailman.ampr.org

3198 discussions

Re: [44net] block allocation
by Rob Janssen 16 Jun '16

16 Jun '16

> 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

8 9

Re: [44net] block allocation
by Rob Janssen 16 Jun '16

16 Jun '16

> 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

1 0

Re: [44net] block allocation
by Rob Janssen 16 Jun '16

16 Jun '16

> 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

1 0

Re: [44net] block allocation
by Rob Janssen 15 Jun '16

15 Jun '16

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

3 2

block allocation
by Pierre-Philippe F4MZI 15 Jun '16

15 Jun '16

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

3 11

Re: [44net] block allocation
by Rob Janssen 15 Jun '16

15 Jun '16

> 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

1 0

Re: [44net] Help MBOX flood
by lleachii＠aol.com 15 Jun '16

15 Jun '16

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

3 4

Re: [44net] Help MBOX flood
by William Lewis 13 Jun '16

13 Jun '16

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

1 0

Help MBOX flood
by Pedro Converso 13 Jun '16

13 Jun '16

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

4 3

Raspberry Pi 3 image
by Brian 12 Jun '16

12 Jun '16

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.net http://axmail.sourceforge.net AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net