Thanks for the reply Jon...am digesting. Am using Vserver guests under
assumption they are hard to compromise, so am interested in steps others
are taking to "harden" them, especially as in my case my guests have
"desktops" with limited apps but potential problems ones including
Firefox and LibreOffice.
Guest bash in my set up is not accessible (e.g., /bin/false, my .bashrc
is "chattr'ed") and users cannot change shortcuts or get to a command
prompt....unless the whole deal gets hacked.
Q: What are other common steps Vserver admins use to harden guests and
hosts, assuming one's use case for guests include limited desktops? I
assume that's is why this thread started, to audit guest services and
run anti viruses in guests.
On 10/06/2014 07:11 AM, Bendtsen, Jon wrote:
> 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 Wed Oct 8 14:26:24 2014