44net

44net@mailman.ampr.org

3 participants
3191 discussions

by Rob Janssen

> especially before Shodan was > blocked on AMPR... Has Shodan been blocked on amprgw or have they been convinced to stop scanning AMPRnet? There are still various agressive scanners active from internet, and I have some scripts to automatically add them to a blocklist but it still is an ever increasing load on the network. For example, "stretchoid.com" is an agressive scanner that changes addresses all the time (but does keep reverse-DNS records on their virtual servers so easy to identify). They do have an opt-out form but it is a NOP. (I have completed it 3 times at 1-month intervals but no reply and no effect on the scanning... maybe Brian should try it as he is listed in the whois as the owner of NET44) Of course there are others, like security.ipip.net and binaryedge.ninja. Plus the many many other scanners, "researchers", etc. Rob

7 years, 9 months

Re: [44net] VPNFilter Router Malware

by Rob Janssen

> I'm not at all sure that Shodan is blocked on amprgw. There are > more than 2,000 IP addresses that are blocked, with more being added > from time to time, plus there are a number of tcp and udp destination > ports that are blocked from all IP addresses, but there's no way > to be sure that these lists include all Shodan and other scanners. I have blocked some known Shodan addresses and subnets, and indeed even a hoster that is known to be a cesspool and accomodates Shodan and the likes: 66.240.192.138 # census8.shodan.io 66.240.205.34 # malware-hunter.census.shodan.io 66.240.219.146 # burger.census.shodan.io 66.240.236.119 # census6.shodan.io 71.6.128.0/17 # cesspool! (including shodan.io, project sonar) 80.82.64.0/20 # ECATEL/QUASI (including shodan.io 80.82.77.139) 82.221.105.6 # census10.shodan.io 82.221.105.7 # census11.shodan.io 89.248.160.0/20 # ECATEL/QUASI (incl shodan.io 89.248.167.131 89.248.172.16) 93.174.88.0/21 # ECATEL/QUASI (incl shodan.io 93.174.95.106) 94.102.48.0/20 # ECATEL/QUASI (incl shodan.io 94.102.49.190 94.102.49.193) 107.6.151.192 # security.census.shodan.io 107.6.151.193 # security.census.shodan.io 107.6.151.194 # security.census.shodan.io 107.6.151.195 # security.census.shodan.io 185.163.109.66 # goldfish.census.shodan.io 185.181.102.18 # turtle.census.shodan.io 198.20.69.72/29 # shodan.io 198.20.69.96/29 # shodan.io 198.20.70.112/29 # shodan.io 198.20.87.96/29 # shodan.io 198.20.99.128/29 # shodan.io (of course many others, these are just the shodan.io entries) I also have some iptables rules that capture TCP SYN to addresses that are not registered in DNS and forwards them to an nflog socket to be picked up by some scripts that finds those that are repeat offenders. Those are logged as candidates for blocking. But I don't bother to block everything, I run reverse-DNS on them to see if it has some signature patterns like "research", "scan" etc or one of the known names like shodan.io stretchoid.com etc. And irregularly I just sort the entire list and glance over it to see if there are clusters of addresses and do a whois to see if they belong to some common network. Names like DigitalOcean pop up quite regularly but of course they are just cloud hosters that could also host bonafide services. Rob

7 years, 9 months

VPNFilter Router Malware

by LLEACHII＠aol.com

https://www.us-cert.gov/ncas/current-activity/2018/05/23/VPNFilter-Destruct… https://blog.talosintelligence.com/2018/05/VPNFilter.html https://www.thedailybeast.com/exclusive-fbi-seizes-control-of-russian-botnet All, I need to ask you now...do any of you keep Netflow records? If so, can you scan your records from 01JAN2016-31OCT2016 for: > proto TCP and dst net 44.xxx.xxx.xxx/xx and dst port 2000 As you go back in time, I think you'll find the origins of the IPs tell a story different than the links above...especially before Shodan was blocked on AMPR... 73, - Lynwood KB3VWG

7 years, 9 months

Gateway 75.101.96.109 not receiving full traffic for 44.4.39.8/29

by Jeremy Cooper

I run the gateway at 75.101.96.109 and have assigned my network, 44.4.39.8/29 to it in the portal a long time ago (more than a year ago). I receive packets destined for the first allocated address (44.4.39.8) but I'm not receiving traffic for any of the other hosts in my range. Did I miss a crucial update about network allocations? -- Longer version below: I've made sure to log into the portal every now and then to keep my assignment fresh, but just today I decided to actually try to start connecting hosts inside my allocation. To do some tests, I tried pinging the first assignment in my net, 44.4.39.8, from an outside host. That worked fine. I successfully received the tunneled IPIP packet from amprgw.ucsd.edu, de-encapsulated it, found that the inner destionation was 44.4.39.8, and sent it on its way to my inside network. When I attempt to hit other hosts in my allocation, however, I never even receive the IPIP packet for them. Traceroute from my test host seems to indicate that the packet never even makes it to UCSD; it stops one hop short, at sdsc-7710-7--mcore-vl2995-p2p.ucsd.edu (132.239.255.50). WORKING HOST Traceroute to 44.4.39.8: traceroute to 44.4.39.8 (44.4.39.8), 64 hops max, 40 byte packets 1 50-0-193-1.dsl.static.fusionbroadband.com (50.0.193.1) 23.641 ms 19.205 ms 18.704 ms 2 xe-0-0-20.cr2.colaca01.sonic.net (70.36.228.117) 39.927 ms 72.901 ms 30.780 ms 3 0.ae0.cr3.colaca01.sonic.net (198.27.244.130) 37.454 ms 35.465 ms 33.255 ms 4 * * * 5 50.ae4.gw.pao1.sonic.net (50.0.2.5) 19.397 ms 19.728 ms 20.012 ms 6 palo-b22-link.telia.net (213.248.81.254) 19.673 ms 19.190 ms 19.935 ms 7 sjo-b21-link.telia.net (62.115.125.1) 21.363 ms 20.989 ms 20.647 ms 8 las-b21-link.telia.net (62.115.116.41) 26.836 ms las-b21-link.telia.net (62.115.136.46) 37.521 ms 33.204 ms 9 limelight-ic-320599-las-b21.c.telia.net (213.248.96.65) 68.480 ms 28.275 ms 28.070 ms 10 198.32.251.189 (198.32.251.189) 31.314 ms 32.787 ms 28.098 ms 11 137.164.11.25 (137.164.11.25) 33.761 ms 36.236 ms 137.164.11.23 (137.164.11.23) 33.997 ms 12 dc-sdg-agg4--tus-agg3-100ge.cenic.net (137.164.11.9) 40.166 ms 137.164.11.11 (137.164.11.11) 34.933 ms 31.510 ms 13 dc-ucsd-1--sdg-agg4.cenic.net (137.164.23.54) 36.912 ms 36.172 ms 32.772 ms 14 mcore-flow-bypass-mx0-p2p.ucsd.edu (132.239.254.61) 39.436 ms 38.211 ms 42.078 ms 15 sdsc-7710-7--mcore-vl2995-p2p.ucsd.edu (132.239.255.50) 37.436 ms 37.872 ms 36.955 ms 16 amprgw.ucsd.edu (169.228.34.84) 32.790 ms * 33.361 ms 17 ke6jjj-8.ampr.org (44.4.39.8) 35.951 ms 36.368 ms 32.583 ms NON-WORKING HOST Traceroute to 44.4.39.9: traceroute to 44.4.39.9 (44.4.39.9), 64 hops max, 40 byte packets 1 50-0-193-1.dsl.static.fusionbroadband.com (50.0.193.1) 69.583 ms 19.148 ms 19.244 ms 2 xe-0-0-20.cr2.colaca01.sonic.net (70.36.228.117) 120.800 ms 68.925 ms 88.207 ms 3 0.ae0.cr3.colaca01.sonic.net (198.27.244.130) 91.626 ms 34.418 ms 76.632 ms 4 * * * 5 50.ae4.gw.pao1.sonic.net (50.0.2.5) 23.116 ms 19.177 ms 19.248 ms 6 palo-b22-link.telia.net (213.248.81.254) 19.647 ms 19.396 ms 19.452 ms 7 sjo-b21-link.telia.net (62.115.125.1) 20.457 ms las-b24-link.telia.net (62.115.119.91) 36.542 ms sjo-b21-link.telia.net (62.115.125.1) 20.644 ms 8 las-b21-link.telia.net (62.115.136.46) 33.996 ms las-b21-link.telia.net (62.115.116.41) 26.532 ms las-b21-link.telia.net (62.115.136.46) 33.467 ms 9 limelight-ic-320599-las-b21.c.telia.net (213.248.96.65) 36.186 ms 28.669 ms 28.199 ms 10 198.32.251.189 (198.32.251.189) 30.786 ms 33.225 ms 31.040 ms 11 137.164.11.25 (137.164.11.25) 32.792 ms 33.481 ms 32.755 ms 12 dc-sdg-agg4--tus-agg3-100ge.cenic.net (137.164.11.9) 38.265 ms 137.164.11.11 (137.164.11.11) 31.252 ms 32.276 ms 13 dc-ucsd-1--sdg-agg4.cenic.net (137.164.23.54) 37.461 ms 37.917 ms 36.964 ms 14 mcore-flow-bypass-mx0-p2p.ucsd.edu (132.239.254.61) 36.682 ms 33.464 ms 36.222 ms 15 sdsc-7710-7--mcore-vl2995-p2p.ucsd.edu (132.239.255.50) 33.497 ms 37.393 ms 36.970 ms 16 * * * 17 * * * 18 * * *

7 years, 9 months

44.190.8.0/24 is online!

by Tony Langdon

Got my allocation online and have reconfigured elproxy to provide 150 public proxies, in addition to the existing 4 private proxies. Got a geolocation issue causing incorrect allocation of proxies, but have submitted change requests with 3 of the major geolocation providers. :) -- 73 de Tony VK3JED/VK3IRL http://vkradio.com

7 years, 9 months

Re: [44net] Network 44.190.5.x work!

by Rob Janssen

> Sorry, I can't agree on that. Without manual interaction Echolink > Repeaters behind traditional IPIP-Mesh gateways are not reachable > through the NLD Echolink Relays/Proxies. That is NOT CORRECT! It will work just fine when the repeater is behind a traditional IPIP mesh gateway which sends traffic to internet via amprgw (the setup described in the Wiki). It will only fail when shortcuts are made and traffic to internet is sent via some local NAT router instead of via the IPIP mesh. As the Echolink protocol cannot handle this situation (as described above) one needs to make sure that Echolink traffic is not sent via this NAT shortcut. The Echolink system is perfectly happy with clients, proxies and relays on NET44, it is only the bad configuration of gateway systems that will break it. Rob

7 years, 9 months

Network 44.190.0.0/16 - Further information

by Jann Traschewski

Description: The network 44.190.0.0/16 is available to host amateur radio internet services using direct BGP. Allocations will be made usually in /24 chunks. The focus of this network is to transfer data as direct as possible (no radio, no tunnels) to keep reliability high. AMPRNet systems with no dynamic routing protocol support are able to route 44.190.0.0/16 via their ISP. Background: AMPRNet allocations are not partitioned by connectivity type. Each individual network can either be of type "radio", "tunnel" or "direct". AMPRNet systems may be "dual homed" and have a line based and a radio connection, thus there needs to be a decision whether a packet should be forwarded by line or by radio. This _could_ be achieved by AMPRNet systems *with* dynamic routing protocols by learning the routes and treating each route by its type (or any other available "flag"). However this will _never_ be the case for AMPRNet systems *without* support for dynamic routing protocols. Endusers running a *radio* connection to AMPRNet infrastructure such as HAMNET User Acess Points, IPIP-Mesh Gateways or even direct-BGP Gateways might ask how to integrate the radio connection into their home-LAN to have permanent access using any device on their LAN. Unfortunately standard home routers do not provide dynamic routing protocols, but there is often the functionality to add additional static routes like "44.0.0.0/8 via radio" and "44.190.0.0/16 via ISP". Sometimes customers are *forced* to use the router provided by the ISP to access the Internet (such a requirement is prohibited by law in Germany). Those might have no functionality to set static routes at all and you might end up attaching another router to the router to gain more functionality... As of today the standard setup for "dual homed" AMPRNet systems *without* support for dynamic routing protocols is to add 44.0.0.0 netmask 255.0.0.0 via <radio device within the home-LAN>. Outbound connections to 44.x.x.x will be made by their radio with the source-44 address and outbound connections to the Internet will be made with the source address obtained from the ISP. This worked without any issues as long as there were no direct BGP allocations within the network44. Nowadays we have several amateur radio internet services provided on the Network44 by direct BGP and the accessibility for the above mentioned AMPRNet systems highly depends on a proper radio connection and the backbone infrastructure to transfer the packet to its destination. The idea of 44.190.0.0/16 is to give willing stakeholders the opportunity to improve the situation. Amateur radio internet services can be hosted in that range while AMPRNet systems can make use of the additional route 44.190.0.0/16 via their ISP. The following issue has much more impact: Once direct BGP allocations started within the Network44 we encountered situations of full incompatibility. It is the case for amateur radio internet services (e.g. Echolink) working with a directory to map callsigns to IP addresses. Echolink does learn the IP address of an Echolink station (respectively of the used Echolink Proxy or Relay) from the inbound connection to the directory service. This leads to the problem, that AMPRNet systems forwarding 44.0.0.0/8 to the radio device on the roof will not have a slow or weak connection to a Echolink station using direct BGP but even *no* connection at all. Since they are registered on the Echolink network with their IP address obtained from the ISP but appearing with their Network44 address used over radio at the Echolink station using direct BGP, the connection is dropped due to a mismatch between "IP address <-> callsign". This will not happen if Echolink Relay/Proxy Servers or Echolink Stations will make use of address space from 44.190.0.0/16 while AMPRNet systems route 44.190.0.0/16 via their ISP. There will be no IP mismatch anymore. I made a diagram explaining the situation: http://db0fhn.efi.fh-nuernberg.de/~dg8ngn/echolink-amprnet.pdf 73, Jann -- Jann Traschewski, Faber-Castell-Str. 9, D-90522 Oberasbach, Germany Tel.: +49-911-99946898, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de Ham: DG8NGN / DB0VOX / DB0FOX / DB0ZM / DB0DBA / DB0HZS

7 years, 9 months

DNS Web tool

by Brian

For those who use my Amprnet DNS management web tool, just a note to let you know it's been completely rewritten. Your login credentials will still work, and it still forces SSL/TLS, but now reCaptcha has been added. I tried to keep the look and feel of it somewhat similar to the old one. Don't be shocked when you see a captcha box on the screen now. -- Did you know that dolphins are so smart that within a few weeks of captivity they can train people to stand on the very edge of the pool and throw them fish? ----- 73 de Brian N1URO IPv6 Certified SMTP: n1uro-at-n1uro.ampr.org IPv4: 44.88.0/28 IPv6:2001:470:8a1e::/48 https://uronode.n1uro.com (dual stacked) https://n1uro.ampr.org (dual stacked)

7 years, 9 months

Re: [44net] Network 44.190.0.0/16 - Further information

by Rob Janssen

> Each 44.190.x.0/24 subnet arranges its own BGP advertising, > so there isn't just one point. They are spread all over the > world. > - Brian Note that due to this, the approximate location in IP geolocation databases has to be set for each of the /24 subnets. The default location for 44.0.0.0/8 is San Diego, California, USA. I have set the location for 44.137.0.0/16 to Amsterdam, Netherlands and other country ip coordinators have done similar for their countries. And of course an individual amateur can set a more accurate location for their smaller subnet. It comes into play for some services that use IP location aware DNS to direct users to a geographically closest (and hopefully this translates to closest in network topology) service. With all the 44.190.0.0/16 networks located in San Diego this of course isn't going to work. Echolink is such a service that users IP geolocation. You can enter an address from your subnet in lookup services like this: https://www.iplocation.net/ It shows what some of the more important services return for your location. And when clicking on the link for each service it is usually easy to submit location data for a subnet to that service provider. Rob

7 years, 9 months

Re: [44net] OT: Recommendations for a small to medium size router for a multi-purpose repeater site

by Rob Janssen

> One thing I'm unclear on with Mikrotik is their different generations of > hardware. I DO want to make sure I get the newer generation so, in > theory, I get the longer supported OS support. Does anyone know if the > CCR1009-7G-1C-1Splus is a new generation of hardware or is it older? > Regarding buying a box that can run "The Dude" on an internal SSD, do > Wifi, or other stuff on the side. That was something I was planning on > running on a separate machine with say TICK, Zabbix, etc. Not sure but > I seriously worry if something goes south in that system, can it harm > the router. That's NOT acceptable in my book. The CCR1009-7G-1C-1Splus is the latest model in the CCR series, but the RB1100AHx4 is a newer router that could well be the root of more new models in the future. Of course one never knows such things for sure, but the Tilera TILE processors in the CCR series appear to have less current development than the processor used in the 1100. I would expect MikroTik to support the CCR in software updates at least for some years. Remember that all MikroTik routers include software support for the support lifetime of the device, no need for a separate support contract for that. The selection also depends on the network architecture. The RB1100AHx4 has two hardware switch chips each driving 5 ports so you can have hardware switching between those ports, while the CCR series ports are all independent router ports, they are expected to be connected to an external switch when you want hardware switching. So the CCR is a true router while the RB1100AHx4 is a router-switch combination. And the CCR has an SFP and SFP+ slot for fiber etc. The CCR does not have internal M.2 SSD like the RB1100AHx4 Dude edition, but it has a slot for an SDHC card and a USB port that both can be used for external storage. Rob

7 years, 9 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net