Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Shells Virtual Desktop
BMail.ag - Secure Email Service
Server.net
CPLicense.net
VPS Server
Buy VPN
Vultr
VMs for AI
HostDare
ReliableSite White-Label Dedicated Hosting for Resellers
InterServer VPS
BMail.ag - Secure Email Service
Best VPN
High-Performance Bare Metal Server Solutions
Karvl.com
Server Mania Cloud Hosting
DataWagon Hosting
AlphaVPS Hosting
Evoxt.com
Clouvider
VPS Hosting with NVMe
Residential IPs in the US & 4G Mobile Proxies in EU & US with Unlimited Bandwidth
ReliableSite White-Label Dedicated Hosting for Resellers
Rabisu - Hosting Solutions
Shells Virtual Desktop
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.

[BitsFlowCloud] Our First Offer! Starting at £8.4/Yr ! | US/DE/HK VPS & China Optimized VPS

12346»

Comments

  • rpqurpqu Member

    @BitsFlowCloud said:

    @rpqu said:

    @BitsFlowCloud said:

    @rpqu said:

    @BitsFlowCloud said:

    @ralf said:

    @BitsFlowCloud said:
    Just like in the community, many people don't understand why outbound traffic on port 22 is blocked and fail to grasp the potential risks it could pose to them.

    Could you explain these potential risks please? Why would outgoing SSH be a potential risk?

    If you're saying people are scanning other people's SSH, then that's already covered by your no scanning rule. But what do you have against SSH?

    When I'm using a machine, I use outgoing SSH for: backups to my borg servers, access to my git repo, fetching web certificates from a centralised certbot, etc.

    I've never encountered another provider that thinks outgoing SSH is dangerous, so please, if it's a potential risk, please explain why you think so...

    Regarding outbound traffic on port 22, although I've addressed this before, I'm happy to reiterate:

    The greatest risk isn't what you actively do, but what unknown “entities” are doing behind your back.

    Previously, numerous malicious users purchased VPS servers and used port 22 for outbound scanning, triggering abuse reports against me.

    So, it's because MJJ are doing something they're specifically told not to. Then they overreact and start attacking you when you canceled and banned them from your system, right?

    I don't think this has anything to do with MJJ; you're making a sweeping generalization.

    This kind of thing doesn't just happen to malicious users—legitimate users sometimes encounter it too. For instance, the proxy panel they use might have been tampered with, or sometimes Cloudflare even flags their VPS as “preferred,” exhausting all their traffic within a single day.

    Generalization doesn't happen without patterns. Bad apple spoils the batch.

    Anyway, CF also generalized your IP range because of the past behaviors. Burning 500-1000GB is quite crazy.
    Let's do the math.

    • 86400 seconds in a day
    • 5.92~11.84MB of traffic per seconds
    • CF challenge in total 0.75~0.8MB uncompressed, 0.22 and 0.14MB with gzip and brotli
    • 7.4 requests per second. 26.09 and 42.286 rps with compression.
    • 660K-3.65M failed requests (per 500GB).

    It's not surprising your IP blocks got bad rep. It's puzzling how the customer could use the server, write some program, yet execute it without doing testing, let alone putting exponential back off or scheduled sleep.

    @BitsFlowCloud said:

    Additionally, an explanation:

    I never believed that “they did something they shouldn't have, causing me to overreact.” On the contrary, the reality is that “my former partners and I (I attribute this to myself because I don't wish to deny any actions that occurred, even if they were decisions made by previous team members) did something we shouldn't have, causing them to overreact.” It sounds a bit convoluted, but I hope you understand what I'm trying to convey.

    You can find the answer to this point by looking for the “Wall of Shame” in the footer of my official website. If I truly believed “I was right and others were wrong,” I wouldn't have built “this wall” and made it public at all :)

    Sorry, I assumed it's something like this.
    1. Customer do something bad
    2. You (or your previous team) stopped the instance or cancel it without refund (severe violation of ToS with consequences to business)
    3. The customer start badmouthing you

    But, you're honest it was caused by problems on your side which customer react negatively.

    You are absolutely right. While these incidents occurred in the past, now that I have personally taken charge, I can assure you they will not happen again.

    As a service provider, mistakes are inevitable. However, I have rarely seen a business openly summarize all their past faults for customers to review. Please understand that this isn’t a PR stunt; it is a genuine reminder to myself of how I need to operate from now on. :) I take full responsibility for all past errors—that is beyond question.

    While you take extraordinary measure to reassure future customers, it doesn't seems your past customers are convinced by the transparency.
    Even myself would wait for few months and see whether the current business practice/policy is suitable.

    Regarding the blocking of outbound traffic on port 22: You might feel this restriction implies we view users as 'bad actors.' However, you may not be aware of a specific incident where dozens of users—all running the same proxy panel software—unknowingly had their servers hijacked by malicious code to scan others via outbound port 22. This resulted in me receiving over 20 abuse reports in a single day, which forced me to implement this default blocking rule.

    However, I would like to clarify a few things:

    The block can be lifted. However, once lifted, you bear full responsibility if the port is used maliciously.
    Blocking outbound port 22 does not break SSH access. Your incoming SSH connection works perfectly fine. This primarily affects actions like using git or using this VPS as a jump host to SSH into other servers. A simple workaround is to change your SSH port to a non-standard port and run systemctl restart ssh, which bypasses the rule. Alternatively, you can simply open a ticket to request unblocking. It’s not a hassle—I approve all requests and remove the rule for verified users. :)
    If anything remains unclear, please feel free to ask, and I will be happy to explain further.

    Can you name the malicious panel?
    I occasionally run small HK vps instance because many cheap roaming esim has breakout in there

  • BitsFlowCloudBitsFlowCloud Member, Patron Provider

    @xmexman said:
    Is Windows available??

    很不幸,基于潜在的版权风险,不提供windows安装镜像,也不允许客户自行安装windows :(

  • angstromangstrom Moderator

    @BitsFlowCloud said:

    @xmexman said:
    Is Windows available??

    很不幸,基于潜在的版权风险,不提供windows安装镜像,也不允许客户自行安装windows :(

    Which translates as:

    Unfortunately, due to potential copyright risks, Windows installation images are not provided, and customers are not allowed to install Windows themselves

    @BitsFlowCloud

    Please post in English, which is the common language of this forum. (Or minimally, provide a translation in English)

This discussion has been closed.