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
Believe me, I have experience with it. Given our positioning, a lot of people initially think Servury is bulletproof hosting, so I'm already constantly dealing with abuse reports.
Here's our defaults at the moment :
-nodefaults
-cpu 'EPYC-v4,enforce,+kvm_pv_eoi,+kvm_pv_unhalt,vendor=AuthenticAMD'
-object 'rng-random,filename=/dev/urandom,id=rng0'
-device 'virtio-rng-pci,rng=rng0,max-bytes=1024,period=1000'
-device 'i6300esb,bus=pci.0,addr=0x4'
-watchdog-action reset
-global 'ICH9-LPC.disable_s3=1'
-global 'ICH9-LPC.disable_s4=1'
-sandbox 'on,obsolete=deny'
I'll tinker around with yours, but I think some of them might break Proxmox, not sure though, have to test.
https://servury.com/guest.txt
Not sure, I'd have to implement it first, and we would have to test drive it thoroughly. It'd be a nightmare to manage abuse that way.
OK. I will 100% be giving that a read, but part of me really likes the nuclear-no-guest-agent-at-all option. It completely kills any possibility of fuckery happening because of the guest agent.
Yeah this is kinda fucked to be honest, there's not much we can do to guarantee we're not doing that I reckon.
It's kind of my job to deal with that, we'll see how it goes though.
Yeah, those are not Blackbox nodes. Those are nodes for our regular VPS/VDS. We do not own that hardware.
I don't really believe they're real at all. 200+ nodes in 6 months of doing business?
And I wasn't able to find anything pointing to you having that many nodes or those other locations. I can only find that 1 LG for Montreal, all your infra hosted in Montreal. DNS, Censys data, etc... also only pointing to Montreal.
Trustpilot doesn't really point to you having customers either, there's 3 reviews. You had more than 20 until Trustpilot removed all your fake 5-star reviews. https://www.trustpilot.com/review/servury.com https://web.archive.org/web/20260115143659/https://www.trustpilot.com/review/servury.com
Everything combined, it just starts smelling like shit.
The jig is up buddy
No
-run-with user=qemu? Or is it being started as non-root?Nice for the non-KYC and SEV-SNP part, but your other 2 marketing "addons" are possible
with any provider. You can install your own image with disk encryption, and having the guest agent installed or alternatively blacklist it's dangerous features is entirely up to you.
9.99$/mo price is very hard to justify for only 512 MB ram, let's be honest, it's barely
enough to run just the basic OS services with this low amount.
39.99$ is a price for a reasonably ok'ish dedi, you only offer 4GB ram VPS for that.
GLWS.
Here's the results of my tests so far
Flag Result
resourcecontrol=deny works
elevateprivileges=deny blocks setsid(), -daemonize needs it
spawn=deny could not launch network script pve-bridge: Operation not permitted
-run-with user= starts, then leaks tap devices on shutdown
I guess the only way to get around to using your - might I say, really nice hardening flags - would be to make our own QEMU API/wrapper and ditch proxmox entirely. That's now on the roadmap.
So all your QEMU processes are running as root? If so, what is the purpose of even having the sandbox?
`> @forest said:
It can't be done on Proxmox. I'll make a POC of a custom QEMU wrapper so it can be done.
Wait... so Proxmox still runs VMs as root by default?
https://pve.proxmox.com/wiki/Qemu/KVM_Virtual_Machines
QEMU inside Proxmox VE runs as a root process, since this is required to access block and PCI devices.
Totally possible to harden it properly. Don't pass raw disks to guest VMs, and only pass virtio-net as network device since it acts as a buffer. The problem will be with PCI devices like GPUs, but that's rare to have GPUs in shared VM environments anyway so can be ignored.
Even with that, you can drop privileges after it uses the raw disks with e.g. VFIO.
Yeah but Proxmox entire development logic is tied around running as root. The architectural design blocks priv-dropping workarounds. ZFS, Ceph, LVM, NFS, HA, I can probably think of more. This is a too much complex over-engineered product that I think was never designed for isolated, untrusted guests sharing the same host. While it's ok in corporate setups where you don't expect guest VMs tampering with each other or the host, it has so many attack surfaces that are only waiting to be discovered.
Hello NSA
Are xmr / Tor nodes allowed?
Or Public vpns?
Yes, all of those are allowed on the Blackbox Pro plan
@servury Note that this means that the sandboxing options you provided are useless. Nothing is stopping a compromised QEMU process from obtaining kernelmode (which is the whole purpose of a seccomp sandbox).
I'm fully aware. Like I said, I'm working on a custom QEMU wrapper to ditch Proxmox entirely, which will subsequently allow us to use hardcore turbo schizo hardening methods. Should be done by the end of next week
Indeed I am glad to see someone is making this effort :-)
They also have a Tor and I2P domain!
@servury
If I go to place an order through the onion domain I get redirected to the clearnet domain during payment.
UI bug occurs if one were to press the "Blog" and "Compare" buttons on the payment page, they overlay each other.
There exists a captcha bypass on account creation if you navigate to the order form without being logged in.
"ISP Proxies" button on order page leads to 404. Who is your supplier of residential proxies and how do you make sure they are legitimately and ethically sourced?
"Burn" button in support chat does not work, perhaps because of a JavaScript requirement?
@servury I don't want to necro my old threads, so perhaps its best fitting for you respond here. what is your stance on these two request threads?
Seeking provider that takes client communication security seriously.
Seeking provider that is understanding towards service fingerprinting and scanning of the internet.
Fixed
Fixed, I think.
Yeah I know, but it's not that big of a deal, the only real issue spam-created accounts could cause is spamming support chats, and that's behind a captcha. Matter of fact, I'll remove the captchas from signup/login pages.
Fixed. We use a blend of a bunch of different bandwidth providers, which we have all made extensive research in.
Fixed.
Thanks for the list. Let me know if you find anything else. As a thank you, I'll give you one month of Blackbox Core if you signup and PM me your user ID.
@forest the QEMU wrapper is done, here's our defaults now :
qemu-system-x86_64 -nodefaults -no-user-config \
-cpu EPYC-v4,enforce,-svm,pmu=off,+kvm_pv_eoi,+kvm_pv_unhalt,vendor=AuthenticAMD \
-machine pc-q35-9.2,vmport=off,hpet=off,smm=off,mem-merge=off,\
dump-guest-core=off,sata=off,smbus=off,usb=off[,confidential-guest-support=sev0] \
-accel kvm,kernel-irqchip=split \
-device bochs-display (VGA only for Windows guests) \
-object rng-builtin,id=rng0 -device virtio-rng-pci,rng=rng0,max-bytes=1024,period=1000 \
-device virtio-scsi-pci,disable-legacy=on \
-drive file=/dev/zvol/...,cache=none,aio=native,discard=unmap,detect-zeroes=unmap \
-netdev tap,...,vhost=on -device virtio-net-pci,disable-legacy=on \
-device i6300esb -action watchdog=reset \
-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny
Going back to the flag we discussed :
-run-with chroot=/var/empty,user=qemu - this is where we diverge hardest. That needs CAP_SYS_CHROOT, so QEMU still starts as root to enter it. We hand the whole job to systemd instead:
User=servury-vm # unprivileged, CapabilityBoundingSet= (empty), NoNewPrivileges
DevicePolicy=closed # + per-VM DeviceAllow for only THIS vm's disk node
TemporaryFileSystem=/run/servury:ro + BindPaths=/run/servury/%i # per-VM mount view
PrivatePIDs=yes # siblings invisible + unsignalable
RestrictAddressFamilies=AF_UNIX + IPAddressDeny=any + SocketBindDeny=any
SystemCallFilter=~@debug ... process_vm_readv process_vm_writev kcmp
MemorySwapMax=0, LimitCORE=0
As for "providers that takes client communication security seriously" - You're more than welcome to message us via e-mail or the support chat and use PGP.
As for mass port scanning, it's not allowed, it's the type of activity that gets our IP ranges burned with garbage rep.
But why?
Using
-run-withdoes require root to start out with, but it's safe because QEMU will drop its privileges immediately after. But if you're using systemd to create a read-only mount namespace, it should be fine.it's dead weight, it goes in the same bucket as sata=off,smbus=off,usb=off.
Also, systemd gives us more than a chroot. Each QEMU gets a mount namespace where the shared trees (/run/servury, /var/lib/servury/vm, /etc/servury/vms) contain only its own sockets, disk and spec; a device cgroup allowlist so a neighbour's zvol is EPERM at open; private PIDs; AF_UNIX only with IPAddressDeny=any; and a second seccomp filter on top of -sandbox that closes ptrace/process_vm_readv, which QEMU's own filter leaves open. A chroot into /var/empty gives you the filesystem part of that and none of the rest.
With User= in the unit, QEMU is never root at any instant, and the empty capability set is true from execve onward, which is what makes it checkable from outside (CapEff 0000000000000000 in /proc/PID/status for the life of the process). It also takes QEMU's own privilege-drop code out of the trust path.