Another major disadvantage that I see is that I believe doing this
requires enabled 'unsupported' mode in ESX.  How do you weigh the
security benefit of account lockouts against the issue of potentially
voiding your support contract with vmware?  I see issues like this
more and more with the newer (i series) ESX releases.  They are only
going to become more common as well.  Another example is running
Nessus scans (or any compliance scans) with credentials against
vmware.  I don't think that the new releases come with SSH enabled by
default, and enabling SSH requires jumping into that unsupported mode.
 Without SSH, you can do a credentialed compliance scan (for patches,
configuration, etc).  Maybe someone know's a different way to enable
SSH that I'm not aware of as well.

I'd be very interested to know people's thoughts about this.

On Fri, Sep 18, 2009 at 12:22 PM, Tim Mugherini <[email protected]> wrote:
> After chatting with Carlos and Mick about VMWare & ESX account lockout
> policies (or lack thereof) during the pre show last night, I thought I would
> start an email string here. Carlos had mentioned something last night about
> integration with AD policies. A while back someone had popped this into the
> IRC channel (Carlos I think it was you actually).
>
> http://blog.securitywhole.com/2009/09/01/brute-force-esx-usernamepassword.aspx
>
> So some sysadmins here came up with the following for the ESX console
> (warning have not tested yet).
>
> ------------------
>
> To configure the ESX service console to disable the account after three
> unsuccessful login attempts, add the
> following lines to /etc/pam.d/system-auth:
>
> auth required /lib/security/pam_tally.so no_magic_root
> account required /lib/security/pam_tally.so deny=3
> no_magic_root
>
> To create the file for logging failed login attempts, execute the following
> commands:
>
> touch /var/log/faillog
> chown root:root /var/log/faillog
> chmod 600 /var/log/faillog
>
> -------------------
>
> Of course a major disadvantage here would be DDOS by locking our any built
> in accounts so a more robust solution would be desired.
>
> Thoughts? Might make an interesting blog post ;)
>
> Thanks
>
> Tim
>
>
>
> _______________________________________________
> Pauldotcom mailing list
> [email protected]
> http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
> Main Web Site: http://pauldotcom.com
>
_______________________________________________
Pauldotcom mailing list
[email protected]
http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
Main Web Site: http://pauldotcom.com

Reply via email to