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
I like Pale Moon, the Belgian Ale. Will stay away from the browser.
always beaver gotta be furless
Pale.moon hits dawgy dawg
Good thing I haven't bothered with anything other than mainline firefox for years.
Re: FDE on KVM : I do it to prevent any personal data recovery, by the next (possibly malicious) tenant of the same sectors/flash-cells, after I've hit cancel.
How much overhead does FDE incur on modern systems or those systems with the AES switch or whatever it is that speeds up encryption?
Relevant.
It's certainly no strange thing as a provider to be blamed for a compromised environment. I propose that it generally stems from two points:
If you succeed in blaming your provider, you can create negative press for them that they can only solve by investigating the compromise for you. This saves you money, and you can just apologize later.
You are actually incompetent and even more dangerously you think so highly of yourself that you think incompetence is an impossibility.
I've been the provider blamed for this hundreds of times. I've learned a trick, as a provider, to reducing the time it takes to deal with it. It is simply this:
"I've found no evidence of an intrusion at my level. With that said, I'm happy to consider such a possibility. What do you want me to investigate next?"
The key is to put the ball in their court. You know as reasonably as you can whether or not you've been compromised, and frankly there is plenty of default logic that can lead you to a reasonable conclusion in a short period of time (ex. If you compromised root on a shared box, why in the hell would you have uploaded one PHP shell to one privileged Wordpress user and chown'd it to their account, then faked the logs showing an old, unchanged vulnerable script being compromised to upload it?). It's simply not reasonable (financially or morally) for you to be expected to conduct a full scale investigation every time a customer running vulnerable software is compromised.
It's the most friendly way out of it: Yes I'm willing to consider your idea, now prove you're intelligent enough to even suggest such a thing by telling me where to look for signs of it. If you prove to be the least intelligent party at the table, you no longer get to make these accusations, you can come back when you've learned more.
Hi, what do you need?
A dose of reality and salt.
Many of the users of this would be XP, which would have a problem downloading from https.
But yeah, https and digital signature for the builds after they stopped XP support makes sense.
What is windows xp?
It's for those who has refused to move on with time.
Xtra Profit
Fran prefers vinyl.
I suggest "Stallion" be renamed "Stud".
Francisco is being responsible. He's looking to avoid spreading the viruses to others.
Basically their reasoning is "since we are unable to find what happened it must be providers fault"?
....2017 nuff said
Someone running a server but not knowing how to properly secure it is just asking for trouble. RDP should never be publicly exposed - either use a VPN or a bastion host on the same private network.
XP supports Authenticode signing as long as you use an SHA1 signature. You can dual sign with both SHA1 and SHA256 to get the stronger signing on modern Windows versions while still supporting XP (eg. http://www.elstensoftware.com/blog/2016/02/10/dual-signing-osslsigncode/)
that about sums it up
like some half-baked Sherlock Holmes
Hey! You talking ‘bout me?!?
Actually, in the first half of the Holmes canon (Arthur Conan Doyle’s 19th century stories), up until Holmes returned from supposedly dying at the Reichenbach falls, he was a regular cocaine user, to Watson’s frequent scolding.
Let's be honest and realistic. Yes, many, probably even most providers have not exactly solid setups (but "good enough") ones. The vast majority of engineers and technicians are not gurus, especially in the low end segment. Simple reason: high end professionals strongly tend to be considerably more expensive. Another reason is that most providers run a money earning operation and not a contest for the perfect setup.
Plus there is a big fat monster lurking: the OSs as well as most software have many problematic spots or even vulnerabilities, so no matter how good a providers techies are, it's next to impossible to create and run really solid (incl. safe & secure) hosting.
And there is yet another problem, us, the clients. Very very few clients are really capable to keep a (assumed) safe and secure VPS safe and secure; most will weaken or even ruin it. One major reason is in the fact that most, unfortunately even incl. some security professionals do not really understand their field but rather repeat cool sounding nonsense.
That said, this case here is ridiculous because (a) from what I know @Francisco is a very experienced and highly respected provider, while (b) that palemoon guy seems to be a total loser.
Is it really as easy as
cd /vz/private/ctid?Oh wait: https://askubuntu.com/questions/856569/how-to-view-live-file-system-of-qemu-kvm-vm-externally
You cannot /thread yourself
It is easy, no special magic required, just live snapshot a running VM and then guest-mount (or convert to raw + mount as loop) the snapshot.
Also, I see someone mentioned disk encryption. I never understood why people encrypt their VMs' storage - the host can simply live snapshot the whole running VM including memory, which means they can possibly get access to the unencrypted storage with some effort anyway...
^
Also there may be some existential heuristics at play when applying layers of security - it's a posture one may adopt so as not to always be low-hanging fruit.
As the saying goes: “You don’t have to run faster than the bear to get away. You just have to run faster than the guy next to you.”
This logic doesn't always make perfect sense of course, but it's something to consider - especially when it's easy enough to make it more difficult to get into your bits compared to someone else's.
Better not to coast on any delusion of absolute security online, but still good to do what one can, and to be mindful of the costs and benefits of doing some work to harden a system vs taking shortcuts for convenience.
EDIT2:
The main concept wrt to FDE is "encryption at rest" ... one less thing to be concerned about once I've powered off the VPS.
its not even that complicated.
virt-ls
virt-copy-in
virt-copy-out
virt-cat
etc etc
Given the content of this thread, I presume that he is doing penetration testing.
Still obviously RO access.
...
Disk encryption, IMO, has 2 uses - protection from provider carelessness like sold servers, sold disks etc (basically "at rest" protection). And second - kind of a way to state "i do not want you to look inside my VM". Somehow i think in 99.9% cases seeing encrypted FS will be enough for support/whoever for whatever reason wanted to look inside VM to stop (obviously excluding any law enforcement related cases). Or otherwise if i notice some traces of breaking encryption i will 100% know that this provider can not be trusted and i need to move.
Or libguestfs in another words? It still requires guest to run daemon to be able to work on live vm, right? Which sure will be present in templates, but in manually installed OS it will have to be installed manually inside VM.
I will leave this thread with this thought, forget anything you think you know if you are not literally dealing with this sort of stuff every single day, trust your host or don't host.
Your files are just files on my hard drives, if you think your host cannot read/write/manipulate, you are just wrong.
I work 12 - 14 hour days almost 365 days p/year without much exception, I promise you part of that day is not me snooping about looking to ruin my reputation.