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