44net

44net@mailman.ampr.org

3194 discussions

Start a nNew thread

Test msg, Ignore Please
by kd4iz＠frawg.org 31 May '18

31 May '18

Apologies. Need a test message to set message sorting rules here. KD4IZ

1 0

Encap Database/AMPR Portal Problems?
by Charles J. Hargrove 26 May '18

26 May '18

Is anyone else having problems connecting to other stations? I have about a dozen forwarding partners and until a few minutes ago none were connecting. I still only have 3 connecting now and the rest are all unreachable. I have rebooted my JNOS and it is still occurring. -- Charles J. Hargrove - N2NOV NYC-ARECS/RACES Citywide Radio Officer/Skywarn Coord. NYC-ARECS/RACES Nets 449.025/123.0 PL ARnewsline Broadcast Mon. @ 8:00PM NYC-ARECS Weekly Net Mon. @ 8:30PM http://www.nyc-arecs.org NY-NBEMS Net Saturdays @ 10AM & USeast-NBEMS Net Wednesdays @ 7PM on 7.036 Mhz USB (alt 3.536)/1500 hz waterfall spot; MFSK-16 or 32 "Information is the oxygen of the modern age. It seeps through the walls topped by barbed wire, it wafts across the electrified borders." - Ronald Reagan "The more corrupt the state, the more it legislates." - Tacitus "Molann an obair an fear" - Irish Saying (The work praises the man.) "No matter how big and powerful government gets, and the many services it provides, it can never take the place of volunteers." - Ronald Reagan

6 6

Fwd: Re: VPNFilter Router Malware
by info＠pb0fh.nl 25 May '18

25 May '18

You did what? This is not very nice! I Really dont like this! Making everyone blind for a pressing security issue is not the fix! Please undo this, censorship is not right. Adding to that, i use shodan and its alternatives more than frequently, and i would like to be ablo to doublecheck my own infra via those web services. M.v.g. Pb0fh Roy van Dongen On 25 May 2018, at 11:07, Rob Janssen <pe1chl(a)amsat.org> wrote: >> 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 > > _________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net

2 1

Re: [44net] VPNFilter Router Malware
by Rob Janssen 25 May '18

25 May '18

> 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

4 7

Re: [44net] VPNFilter Router Malware
by Rob Janssen 25 May '18

25 May '18

> 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

2 1

VPNFilter Router Malware
by LLEACHII＠aol.com 24 May '18

24 May '18

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

1 0

Gateway 75.101.96.109 not receiving full traffic for 44.4.39.8/29
by Jeremy Cooper 22 May '18

22 May '18

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

2 2

44.190.8.0/24 is online!
by Tony Langdon 18 May '18

18 May '18

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

2 1

Re: [44net] Network 44.190.5.x work!
by Rob Janssen 15 May '18

15 May '18

> 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

3 2

Network 44.190.0.0/16 - Further information
by Jann Traschewski 15 May '18

15 May '18

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

11 19

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net