On 05/10/2014, at 13.45, Madog <madogdevelopment@gmail.com> wrote:
> Hi All:
>
> I am interested in this thread particularly from the perspective of some more general (newbie) security questions, and was hoping for some input:
>
> - How easy is it for viruses or attackers to compromise a vserver guest? I know that's a broad question, but how would it occur:
>
> * if there is no root access in a guest, and guest users have no access to a command prompt (because it's been disabled).....but ssh is running on the guest…
possibly BASH shell shock exploit if bash is installed on the system and the user has bash as shell. I think that setting the users shell to /bin/false will prevent intrusion.
> * or same scenario, but there's a desktop: users can't double click on code to execute it, but there is a browser (say no java for the sake of this example)
>
> - Would the compromise occur primarily because of inherent exploits in OS, code which is employed both in the host and guests?
It depends. Usually I think that a flaw in some userland software allows the attacker to run programs as a normal user and then they use some other exploits to escalate their privilegies to become root. That could be sudo, setuid and flaws like that. But if the flaw is in the kernel, then assume that they will get the vserver host as well.
> - would an attack most likely come from between guests, or from the host getting compromised? Again, in an overly broad sense, are attacks statistically most likely to come from a browser (either in the guest or the host)?
a vserver-host should run as few services as possible, I would say basically only SSH.
> - is running an AV on the host against guests effective, or is it "best practice" to run an AV in each guest?
>
> I am working under the assumption that guests are very hard to compromise, even from phishing and common user mistakes. Is that a correct assumption? Any feedback appreciated.
I would assume that a linux vserver guest is just as easy/hard to infect as a normal linux server and then take actions to prevent that.
JonB
Received on Mon Oct 6 12:11:13 2014