44net May 2018

44net@mailman.ampr.org

33 participants
33 discussions

by Eric Busch

Hello All, I've just got my first allocation and tunneling setup, and now would like to have public traffic routed to my allocation, which I have read requires DNS records to be made for the IPs to be routed. I'm not seeing any obvious way to contact my coordinator in the portal. How is this usually accomplished? Thanks! Eric, W8ETB

6 years, 6 months

Test msg, Ignore Please

by kd4iz＠frawg.org

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

6 years, 6 months

Encap Database/AMPR Portal Problems?

by Charles J. Hargrove

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 years, 6 months

Fwd: Re: VPNFilter Router Malware

by info＠pb0fh.nl

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

6 years, 6 months

Re: [44net] VPNFilter Router Malware

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

6 years, 6 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

6 years, 6 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

6 years, 6 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 * * *

6 years, 6 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

6 years, 6 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

6 years, 6 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net May 2018