All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Dedicatserver.ro aka Astimp IT Solution SRL silently logging into the customer server
Creating a new thread because offer thread was set to sink
Dedicatserver.ro (@dedicatserver_ro) aka Astimp IT Solution SRL silently logging into the customer server without permission.
I don't have exact data on what commands were run on the server since it was cleared, however, they've forgotten to clean up the secure log file.
Even @cociu didn't do that.
What I should call this provider @FAT32 after doing this?
You always asked to be nice but come on this real utter shit and the provider
(@dedicatserver_ro) should be banned for doing such things.
**** systemd[***]: pam_unix(systemd-user:session): session opened for user root by (uid=0) **** login[***]: pam_unix(login:session): session opened for user root by LOGIN(uid=0) **** login[***]: ROOT LOGIN ON tty1
At first, I thought WTF why no IP with the last login, went checking secure log file, and surprise somebody logged in via root.
After that I realized this is only possible via OpenNebula console which I don't have access to because no console access is available in the client area:
I have kindly asked the provider to check OpenNebula logs (here) because you don't have a console in the panel to login in like that.
However, @dedicatserver_ro didn't deny it all and asked for IP later edited to ticket creation, there is no point to create a ticket because it's the provider's job to check who of the employees doing shady things.
Don't ever trust this provider even though it's cheap.
Actually, amazing thing that this @dedicatserver_ro was talking trash about @cociu but in reality, they are the bottom of it.
Enjoy!
Comments
Frankly this provider was banned earlier but he got a second chance. Would love to understand more from both sides because who knows it might be a vulnerability in OpenNebula?
Such tasks should be logged for auditing purposes but if the provider has to ask for the customer's IP to cross-check details just tells me that this happens way too often to be able to back track or zero in on this incident
Uh, dodgy.
Website seems to be down?
Yes that's definitely console access as such you see with VNC or others.
What a shit show.
I wanted to see whether their Contractual agreements subtly permits staff to access the root account at any time, but I found the website inaccessible.
The nameserver of their domain is
ns3.ddoshosting.ro
, so I don't think it's caused by OP DDoS-ing the website.Either the provider is taking the systems offline to look for intruders that affected OP's server, or they are in preparation of deadpooling.
Could it be that their node got hacked though aswell?
I mean, that providers logging into costumers containers, happens.
Also did happen to hosts still selling stuff here.
Nothing new to see, you can setup alerts for this and punish the provider publicly for doing so.
Ah, the good'ol Sunday LET drama.
Let me grab my popcorn...
is this even ethical, please name them
@alexvolk
we ask you to PM / tell us your IP or services or client, but no answer....we have a multitude of customers although in our offer we explicitly state that we do not accept the TOS violation they do it believing that there are no consequences, have you tried, you have been caught and are you crying now ?
@LET
I also specified "clean host only."
One of them in (we don't know who ) currently executing a DDOS attack , that is why the site is not online. ( we have null routed our IP )
To be clear, we monitoring what traffic / type of traffic is done on each IP/Port. If something suspicious appears, we take packet captures and ask the clients what they do and if they respect TOS. Depending on their answer, we act accordingly. If he respects TOS
we are partners and friends.
On an unmanaged server/VPS, any unauthorised console access by the provider is grounds for immediate cessation of the provider's service, IMHO. I have done this a few times in the past. There are no excuses - except one: the server/VPS user is doing shady shit (DDOS, continuous & repeated port scanning etc.). Even with that single excuse, there are alternatives eg. null route that IP, then get in touch with the customer.
@AlwaysSkint
Once upon a time a wise man said " you better look into your garden " let's how this one pan out
why would you need to login to a server to determine they're conducting a ddos attack?
to see something like that:
and to store the evidence.
To be a dick, I don't think cociu cared in the first place.
Anyhow, the end is nigh.
So did you receive signs or reports of abuse coming from OP's node that warrants the access?
Or do you go around accessing/snooping customers' nodes at random?
He was probably snooping around for free porn.
Happens all the time (not) with kiddie hosts.
I am surprised by the amount of drama every week on LET...
initiating @jsg
Really? Used to be 5x more in older days. Several drama threads every single day.
Well, if Mr. Biloh brings back banned members to create a hostile environment, is it that surprising?
Although, in this case, both the provider and the OP are in the wrong, the provider should implement BCP38 and the OP should be banned as they are not only responsible for running DDOS attacks but also having their psycho episodes on provider threads.
I focused mainly on deals and I never care about drama when I am lurking around
There was more drama but less PMSing.
Now, in 2021, far less drama but far more PMSIng.
Can you just write a statement confirming or denying that you had the proper evidence or justification (abuse reports, netflow graphs) that lead you to access the customer's server?
Also, why don't you implement BCP38? That would take care of all these issues.
MXroute is known to be collecting dick pics sent through their servers.
Thus, even top providers are snooping around.
https://talk.lowendspirit.com/discussion/3124/vps-is-compromised
WisHosting inserted an SSH public key to a customer VM.
I'm not asking how.
I mean if an abuse was detected from OP's node and he's at fault, then maybe just say so? That would explain a lot.
Oh I'm not worried. I'm not a customer.
But your "clean hosting" is somewhat questionable especially when seeing that your domain is pointed to
*.ddoshosting.ro
nameservers.OVH does the same plus a bunch of hosts.
But this case I was speaking about, is years ago, on LES.
I don't remember the details anymore.
Just buy KVM and make sure you have no host keys + any service running that may used to enter the VM.