Comments

• rpqu Member

  August 3

  First
• zGato Member

  August 3

  can you stop ignoring the questions in your other threads?

  Thanked by 10Killix oloke tzuli Nekopara KeyGenMe forest buggedout Xrmaddness Porlam mandala
• JohnFilch123 Member

  August 3

  I guess can be used for CH location @forest not ideal but well
• forest Member

  August 4 edited August 4

  @JohnFilch123 said:
  I guess can be used for CH location @forest not ideal but well

  For CH I'm actually going with @PacketraOliver. They aren't cheap but they have a good network.

  @zGato said:
  can you stop ignoring the questions in your other threads?

  Have you been receiving any more false positive warnings? So far I haven't but I can't tell if that's because he disabled them for everyone, disabled them for just me, or adjusted the thresholds. Or maybe I'm just getting lucky.

  @antonpa The only thing that's been holding me back from buying more of your VPSes is the uncertainty surrounding whether I can keep running Tor middle nodes and Globalping probes. I hope you can talk with us.

  Thanked by 4oloke JohnFilch123 PacketraOliver mandala
• zGato Member

  August 4 edited August 4

  @forest said:

  @zGato said:
  can you stop ignoring the questions in your other threads?

  Have you been receiving any more false positive warnings? So far I haven't but I can't tell if that's because he disabled them for everyone, disabled them for just me, or adjusted the thresholds. Or maybe I'm just getting lucky.

  @antonpa The only thing that's been holding me back from buying more of your VPSes is the uncertainty surrounding whether I can keep running Tor middle nodes and Globalping probes. I hope you can talk with us.

  For now nope, but I'd rather get a proper statement by @antonpa himself of what they're doing next.

  Last abuse report is from July 26th

  Thanked by 1forest
• antonpa Member, Patron Provider

  August 10

  @zGato Thanks for bringing this up. We’re currently working on improving and fine-tuning our systems, and we’d like to take a closer look at your case with our engineers to understand what happened.

  Could you please send us your service ID(s) and client ID? We’ll check everything on our side.

  Also, while we’re working on this, we plan to extend the abuse notice dispute window from 24 to 72 hours, so customers have more time to respond

  Thanked by 1tzuli
• antonpa Member, Patron Provider

  August 10

  @forest said: Have you been receiving any more false positive warnings? So far I haven't but I can't tell if that's because he disabled them for everyone, disabled them for just me, or adjusted the thresholds. Or maybe I'm just getting lucky.

  >

  @forest Thanks for explaining your concerns so clearly and for your patience.
  We have the information about what was running on your VPS and your service details. Our engineers will review the cases and check what exactly triggered the warnings.
  We are working on improving and tuning our systems, and we’ll make sure to investigate the root cause rather than just the symptoms.
  In the meantime, we plan to extend the abuse notice dispute window from 24 to 72 hours, so customers have enough time to respond before any action is taken on a service.

  Thanked by 1tzuli
• zGato Member

  August 10 edited August 10

  @antonpa said:
  @zGato Thanks for bringing this up. We’re currently working on improving and fine-tuning our systems, and we’d like to take a closer look at your case with our engineers to understand what happened.

  Could you please send us your service ID(s) and client ID? We’ll check everything on our side.

  Also, while we’re working on this, we plan to extend the abuse notice dispute window from 24 to 72 hours, so customers have more time to respond

  For example one from yesterday: service #919473. (ID U208708). I host RIPE Atlas & Globalping probes on all my servers and I have no plans on stopping, as this system makes no sense. I'd rather cancel all my servers and move on. This is the first provider I've ever encountered such behavior of mass customer scanning, besides Hetzner.

  This abuse report was for "Outbound Brute-Force" for SSH port to 144.31.234.73. You know the fun part? This server is blocked in Russia because someone was running a VPN server on it, and I can't even SSH it.
  
  

  Thanked by 1tzuli
• zed Veteran

  August 10

  i don't have anything constructive to add but i wanted to share how amused i am by this nonsense, lol.

  Thanked by 4zGato Nekopara Killix oloke
• zGato Member

  August 10 edited August 10

  @forest they do actually suspend servers btw, I have 2 servers down for getting two "abuse" reports in a row. (or they're in the same hostnode and they're both down lol)
• forest Member

  August 10 edited August 10

  @zGato said: This is the first provider I've ever encountered such behavior of mass customer scanning, besides Hetzner.

  Many providers actually do this kind of scanning, but they aren't configured nearly as strictly and so have few if any false positives. It's usually nothing more than watching out for sinkhole IPs and IPs from known botnets.

  @zGato said:
  @forest they do actually suspend servers btw, I have 2 servers down for getting two "abuse" reports in a row. (or they're in the same hostnode and they're both down lol)

  Did 24 hours pass since the initial report before they were suspended? Because I've gotten as many as 4 (I think) reports stacked up on the same service in a row before I got to replying to them, but I did reply to them before 24 hours elapsed.
• forest Member

  August 10

  @antonpa said: @zGato Thanks for bringing this up. We’re currently working on improving and fine-tuning our systems, and we’d like to take a closer look at your case with our engineers to understand what happened.

  I would be happy to give a detailed technical explanation that will be understood by you and your engineers if you would like (I know the exact problem and solution), but I want to be sure it is listened to and not dismissed.

  I have not had any warnings recently, but I do not know if that is because you changed some settings on your filter. I did not make any changes on my side.

  Could you please send us your service ID(s) and client ID? We’ll check everything on our side.

  Client ID is U290929. Service IDs are 1215053-290929, 1075861-290929, 1082985-290929, and 1093795-290929.

  @zGato said:
  @forest they do actually suspend servers btw, I have 2 servers down for getting two "abuse" reports in a row. (or they're in the same hostnode and they're both down lol)

  @antonpa Could you please look into this as well? @zGato is not an abuser.

  Thanked by 1zGato
• Killix Member

  August 10 edited August 10

  @antonpa said:
  @zGato Thanks for bringing this up. We’re currently working on improving and fine-tuning our systems, and we’d like to take a closer look at your case with our engineers to understand what happened.

  Could you please send us your service ID(s) and client ID? We’ll check everything on our side.

  Also, while we’re working on this, we plan to extend the abuse notice dispute window from 24 to 72 hours, so customers have more time to respond

  1130886-313636 (currently 3 open abuse reports)

  Currently, no abuse reports, but recently:
  1120312-300200
  1113007-300200
  1098328-300200

  On the VPS runs I2P, Syncthing Relay and Snowflake.

  Thanked by 1zGato
• antonpa Member, Patron Provider

  August 11

  I would be happy to give a detailed technical explanation that will be understood by you and your engineers if you would like (I know the exact problem and solution), but I want to be sure it is listened to and not dismissed.

  @forest It will definitely be reviewed. We will analyze your explanation together with our engineers and get back to you within this week.
  Thank you for providing the details — we appreciate your help in understanding the issue and finding the right solution.
• forest Member

  August 14 edited August 14

  @antonpa said: @forest It will definitely be reviewed. We will analyze your explanation together with our engineers and get back to you within this week.

  Thank you. Here are the details:

  Your security system currently flags outgoing connections to IPs in the Spamhaus DROP list. This is not appropriate for a general-purpose host because there are many benign reasons to connect to such IPs. For example:

  • Globalping and ATLAS probes: These allow people to measure latency and connectivity to various IPs, including ones with poor IP reputation. They are not malicious and are helpful to many people.
  • Tor (non-exit) relays: The Tor network is composed of a mix of relays. Non-exit relays connect to exit relays, and exit relays often have a poor IP reputation. Unlike exits, Tor non-exit relays pose no risk to your network.

  By automatically flagging and sending an abuse report for connections to a poor-reputation IP, nothing is done to protect your network and innocent activities, like mine, zGato's, Killix's, and many others, get penalized. There are no other providers that do this because connecting to a poor-reputation IP is not an indicator of malicious activity and does not harm your network's security or IP reputation. If you want to block malicious outgoing activity, I would recommend instead flagging sinkhole IPs.

  Please confirm for us that we are allowed to run Tor middle (non-exit) relays, Globalping probes, and ATLAS probes, because connecting to IPs with poor reputation, including those on Spamhaus DROP, is necessary and expected for them.

  Thanked by 4Killix zGato tototo mandala
• malikshi Member

  August 16

  @antonpa why your support always recommend me to reinstall even the error are from yourside the system triggering something and network VM become unavailable it's like being null network. i am already reinstalled the vps and the issues still happening even no load within the VM(idle)

  "we recommend reinstalling the server on your VPS"
• zGato Member

  August 16

  @forest said:

  @zGato said: This is the first provider I've ever encountered such behavior of mass customer scanning, besides Hetzner.

  Many providers actually do this kind of scanning, but they aren't configured nearly as strictly and so have few if any false positives. It's usually nothing more than watching out for sinkhole IPs and IPs from known botnets.

  @zGato said:
  @forest they do actually suspend servers btw, I have 2 servers down for getting two "abuse" reports in a row. (or they're in the same hostnode and they're both down lol)

  Did 24 hours pass since the initial report before they were suspended? Because I've gotten as many as 4 (I think) reports stacked up on the same service in a row before I got to replying to them, but I did reply to them before 24 hours elapsed.

  Sorry! I totally forgot to answer you

  I got my VM instantly blocked, although now my reports are for alleged SSH brute force...
• forest Member

  August 16

  @zGato said: now my reports are for alleged SSH brute force...

  I'm interested in what the report says, if you can share it. Does it give destination IPs or any other information? I wonder if some Tor relays decided to put their ORPort on 22 or something.
• star111 Member

  August 16

  @malikshi said:
  @antonpa why your support always recommend me to reinstall even the error are from yourside the system triggering something and network VM become unavailable it's like being null network. i am already reinstalled the vps and the issues still happening even no load within the VM(idle)

  "we recommend reinstalling the server on your VPS"

  I have the same problem; the virtual machine is inaccessible from the public internet. The customer service representative will only suggest reinstalling and changing the region. They won't give you a specific answer to your question.
• malikshi Member

  August 17

  @star111 said:

  @malikshi said:
  @antonpa why your support always recommend me to reinstall even the error are from yourside the system triggering something and network VM become unavailable it's like being null network. i am already reinstalled the vps and the issues still happening even no load within the VM(idle)

  "we recommend reinstalling the server on your VPS"

  I have the same problem; the virtual machine is inaccessible from the public internet. The customer service representative will only suggest reinstalling and changing the region. They won't give you a specific answer to your question.

  Are you in SIN1? SO THE problem was same as me. Network become inaccessible from internet.
• antonpa Member, Patron Provider

  August 17

  @forest @zGato @Killix

  We were testing a new threat-mitigation system designed to prevent malicious actors from using our services. Their activity affects legitimate customers sharing the same networks, as entire network ranges may consequently be classified as malicious.

  Under the standard enforcement policy, only VPS instances whose IP addresses have already been identified in malicious-IP lists are restricted. During testing, several legitimate customers were incorrectly affected because spammers use increasingly sophisticated methods to evade detection. We have reviewed these cases, corrected the false positives, and lifted all erroneous restrictions.

  We apologize to the affected customers. The purpose of this system is to protect legitimate users and maintain the reputation and accessibility of our networks.

  For security reasons, we cannot disclose the system’s algorithms, detection methods, data sources, or the lists it uses, as doing so would help malicious actors adapt their behavior and bypass protection.
• malikshi Member

  August 17

  @antonpa said:
  @forest @zGato @Killix

  We were testing a new threat-mitigation system designed to prevent malicious actors from using our services. Their activity affects legitimate customers sharing the same networks, as entire network ranges may consequently be classified as malicious.

  Under the standard enforcement policy, only VPS instances whose IP addresses have already been identified in malicious-IP lists are restricted. During testing, several legitimate customers were incorrectly affected because spammers use increasingly sophisticated methods to evade detection. We have reviewed these cases, corrected the false positives, and lifted all erroneous restrictions.

  We apologize to the affected customers. The purpose of this system is to protect legitimate users and maintain the reputation and accessibility of our networks.

  For security reasons, we cannot disclose the system’s algorithms, detection methods, data sources, or the lists it uses, as doing so would help malicious actors adapt their behavior and bypass protection.

  Hi, the VM randomly get null network even the vps are idle. Why your current solution only reinstall VM?
• forest Member

  August 17

  @malikshi said: Hi, the VM randomly get null network even the vps are idle. Why your current solution only reinstall VM?

  Have you tried doing any diagnostics? Traceroute to 8.8.8.8 or anything like that? Ping the gateway?
• malikshi Member

  August 17 edited August 17

  @forest said:

  @malikshi said: Hi, the VM randomly get null network even the vps are idle. Why your current solution only reinstall VM?

  Have you tried doing any diagnostics? Traceroute to 8.8.8.8 or anything like that? Ping the gateway?

  Ofc I did that. It's nulled network random time I got this issue since early August. Been reinstalled the os works for moment then got same issues the vps are idling around. I won't reinstall again until they fix it
• zGato Member

  August 17 edited August 17

  @antonpa said:
  @forest @zGato @Killix

  We were testing a new threat-mitigation system designed to prevent malicious actors from using our services. Their activity affects legitimate customers sharing the same networks, as entire network ranges may consequently be classified as malicious.

  Under the standard enforcement policy, only VPS instances whose IP addresses have already been identified in malicious-IP lists are restricted. During testing, several legitimate customers were incorrectly affected because spammers use increasingly sophisticated methods to evade detection. We have reviewed these cases, corrected the false positives, and lifted all erroneous restrictions.

  We apologize to the affected customers. The purpose of this system is to protect legitimate users and maintain the reputation and accessibility of our networks.

  For security reasons, we cannot disclose the system’s algorithms, detection methods, data sources, or the lists it uses, as doing so would help malicious actors adapt their behavior and bypass protection.

  I'm still getting a huge chunk of VMs flagged for "SSH port scanning". My VMs are not comprimised, but running Globalping & RIPE Atlas. Users may use their tokens to do checks on all probes hosted on those two platforms, which include TCP checks, which is what I assume you're flagging. These platforms, as far as I know, already have some protections in place.

  Instead of checking if I did, I don't know, 10 SSH connections to X IP, wouldn't it be more useful to actually track SSH scanners, which, by nature, scan the whole internet and try SSHing several IPs at the same time?

  At least this is a more decent suspension reason, although still being false positives. I wouldn't really want to block outgoing to port 22. What about weighting a flag before suspension with other DBs (e.g. AbuseIPDB, even if I completely dislike it) ?

  Thanked by 2mandala forest
• ca1 Member

  August 17

  Very disappointing experience — would not recommend

  I had around 20 VPSs with this provider last year, and unfortunately the experience ended very badly.

  Suddenly, all of my VPSs were suspended/removed due to what I believe were false-positive abuse reports. I tried contacting support to resolve the situation, but getting a meaningful response was extremely difficult. In some cases, I had to wait around a week for a response, and the replies often felt automated rather than like someone was actually investigating the issue.

  For a provider hosting important infrastructure, this level of support is simply not acceptable. If a false positive can result in all your VPSs being removed and you cannot get timely human support, there is a serious risk to your services and business.

  Based on my experience, I would not recommend this provider, especially for anyone running multiple VPSs or production infrastructure. There are providers with much better communication and support.
• forest Member

  August 17

  @zGato said: At least this is a more decent suspension reason, although still being false positives. I wouldn't really want to block outgoing to port 22. What about weighting a flag before suspension with other DBs (e.g. AbuseIPDB, even if I completely dislike it) ?

  As far as I know, Globalping never connects to port 22. It can only do traceroute/mtr, connect to HTTP(S), do DNS lookups, and ICMP echo request. I don't know about the RIPE Atlas probe, but you can probably safely block port 22. It's very possible that you'll keep getting false positives, though.

  @ca1 said: Suddenly, all of my VPSs were suspended/removed due to what I believe were false-positive abuse reports. I tried contacting support to resolve the situation, but getting a meaningful response was extremely difficult. In some cases, I had to wait around a week for a response, and the replies often felt automated rather than like someone was actually investigating the issue.

  Can you provide more detailed information about what the false positives were?
• Obelous Member

  August 17

  @forest said: It can only do traceroute/mtr, connect to HTTP(S), do DNS lookups, and ICMP echo request

  It does TCP ping too.
• zGato Member

  August 17 edited August 17

  @forest said:

  @zGato said: At least this is a more decent suspension reason, although still being false positives. I wouldn't really want to block outgoing to port 22. What about weighting a flag before suspension with other DBs (e.g. AbuseIPDB, even if I completely dislike it) ?

  As far as I know, Globalping never connects to port 22. It can only do traceroute/mtr, connect to HTTP(S), do DNS lookups, and ICMP echo request. I don't know about the RIPE Atlas probe, but you can probably safely block port 22. It's very possible that you'll keep getting false positives, though.

  You can with Globalping:
  
  

  You can't do it directly with RIPE Atlas, but you can do a TCP traceroute to port 22.
  

  Thanked by 1tentor
• forest Member

  August 17

  @zGato said:

  @forest said:

  @zGato said: At least this is a more decent suspension reason, although still being false positives. I wouldn't really want to block outgoing to port 22. What about weighting a flag before suspension with other DBs (e.g. AbuseIPDB, even if I completely dislike it) ?

  As far as I know, Globalping never connects to port 22. It can only do traceroute/mtr, connect to HTTP(S), do DNS lookups, and ICMP echo request. I don't know about the RIPE Atlas probe, but you can probably safely block port 22. It's very possible that you'll keep getting false positives, though.

  You can with Globalping:
  
  

  You can't do it directly with RIPE Atlas, but you can do a TCP traceroute to port 22.
  

  Oh, that's interesting. I assume if you block 22, the system will just mark your probe as unable to connect to 22. If not, then that would be a serious limitation.