New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
With Globalping at least it will just timeout:
(Onidel blocks outgoing 22 by default)
I don't think there are many ways for Globalping to know if the port is blocked internally by the VM or by some country firewall, which defeats one of the main purposes of a probe network
That's why I'd rather cancel all my servers with justhost before dropping port 22 or stopping my probes.
@jimaek Are there any tests Globalping does to determine if a probe should be considered eligible for use to connect to a specific port? Could you perhaps add a feature that would allow probes to send back a list of ports it can or cannot connect to, similarly to the way a Tor exit policy works?
Oh nevermind, they use AbuseIPDB right now, auto suspend for any bogus report, very cool!
what a shitshow 😂
That's bad. There are some services that incorrectly auto-flag Tor middle relays, e.g. xmission.
That account should be banned from AbuseIPDB, gotta say.
I'm actually in correspondence with their support. They said a few weeks ago (after a short back-and-forth where they kept assuring me that they do not own the abuseipdb.com domain before realizing what I was talking about and confirming that they owned the xmission account there) that they would escalate the matter to see what could be done. I just sent a follow-up now requesting an update.
At the very least, I hope for them to whitelist relays' address:ORPort tuple and not report them. I have some hope because they are a very pro-privacy ISP in Utah, and they aren't so massive that support is
/dev/null.Belgrade Location?
We have no special logic related to ports. We pass the port directly to the utility to run the test and return the results as is.
So if a probe has to disable, say, port 22, that's bad for the network due to the skewed results?
Technically yes but I don't like the alternative of port scanning. Our quality control focuses more on packet loss rather than port availability
Not scanning, but allowing probes to voluntarily provide a whitelist or blacklist of their abilities via the API. So for example, zGato's probes could return that they don't support TCP/22, and then any requests to connect to TCP/22 simply wouldn't be routed to any of his probes.
It might even be feasible client-side by having the probe return a refusal over the API rather than return false results (like a connection timeout). Essentially telling the API "I'm alive and I received the request, but I can't satisfy it".
I understand, yes that sounds doable, I'll add it to the backlog
@antonpa I'm receiving more false abuse complaints. This time three duplicates for a single incorrect AbuseIPDB entry (somehow your system is triple-reporting the same report). Looking at it again, it's another false positive to port 9001 (Tor).
Please be aware that anyone can create an AbuseIPDB entry. It is not authoritative.
@antonpa I have received another false abuse report for the same reason. Please look into this.
Your system is also sending three duplicate reports for each report. I'm not sure what I should do with them.
The same you do with spam, feed the emails through ai to create a response and blast it back to the sender.
And now one of my services is suspended, again due to two factors:
@antonpa You said you would help fix this issue, but it has only gotten worse for me and others. I've been a fan of your services for a long time and I need this resolved.
With that said, I believe I have found the core issue. XMission runs a Tor exit and has for 14 years, but they have put an AbuseIPDB auto-reporting script on their exit. Whenever it blocks a connection, it automatically reports it to AbuseIPDB. I'm in contact with them and trying to get the issue escalated to the right person.
@zGato @Killix ^ might be useful information for you. It explains why the xmission account on AbuseIPDB is causing so many issues. It's ironic because they're a pro-privacy ISP.
Also: https://lists.torproject.org/mailman3/hyperkitty/list/[email protected]/thread/IFI2HSD3KDZYHYPRDH6K6LUTUEDADAWS/
Edit: I just got out from a live chat with their support. They are (finally!) escalating it to their networking team which manages the relay. Hopefully, within a week, this particular issue will be resolved. It won't stop JustHost from suspending on every false abuse complaint, but it'll stop the most common false-complainant.
It's not the best practice for sure, but a stop-gap measure for nftables would be:
The iptables equivalent would probably be:
Wow, that is... stupid.
Using AbuseIPDB as a source for abuse reports is also stupid... @antonpa what is up with that? AbuseIPDB is unverified crowdsourced data.
Can someone just report entire /24s to AbuseIPDB and get the customers suspended?
I used your services in the past and they were decent, seeing this makes me sad.
In theory, AbuseIPDB won't increase the abuse score unless a lot of verified, trusted reporters report the IP. But JustHost flags it when even a single report is registered, even though that's not supposed to be done.
@zGato @Killix XMission has said they've disabled reporting of Tor-related ports. Hopefully this means any connections to or from 166.70.207.2:9001 and [2607:fa18:3:beef:f001:c0de:feed:ba5e]:9001 will not be eligible for automatic reporting.
I've requested that they remove existing AbuseIPDB reports against Tor relays that merely connected to their exit and offered to provide a complete list for them. Hopefully they accept and we can get their false-positives removed.
If anyone sees new xmission reports against one of their (non-exit) relays from now, please tell me. Reports look like:
welp, this is a new one, they're not even removing restrictions now
Apparently, RIPE Atlas and Globalping probes are against their ToS now.
@antonpa should I go ahead and cancel my 30+ servers already? are you going to do anything about this? It's only getting worse.
It seems to be a template, and I suspect "restriction" means the filter mechanism? Since I was told the same thing but the "restriction" eventually got removed.
JustHost must be fighting a surge of abuse and is desperately trying to figure out some type of filter that works, but clearly relying on a single user-submitted report to AbuseIPDB is the wrong way to go about it.
@antonpa At the very least, could you explicitly whitelist us? We aren't abusers. We both have dozens (in my case) to hundreds (in zGato's) of servers with various providers and have never abused the services.
Nope, servers remain suspended (four of them, to be exact).
@antonpa seems to be ignoring us in this thread, once again.
Something also very dumb to add up: if you ordered your server when that location didn't have IPv6 available but is now available, you're forced to buy the IPv6 addon which costs a few cents a month. Not much, but ends up adding up if you have many servers. This is despite their "Free IPv6 address for VPS server" claim in their website:
