|
xen-users
RE: [Xen-users] Web Console Access
Thanks Felix,
I know that Ubuntu Server installs php with Suhosin by default, so
I should be good to go with that
Thanks
Jonny
From: Felix Kuperjans
[mailto:felix@xxxxxxxxxxxxxxxxxx]
Sent: Fri 18/06/2010
16:11
To: Jonathan Tripathy
Cc:
xen-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-users] Web Console
Access
Hm I don't know of an actual hack when the session is SSL encrypted, but
it's not a good practise to send the login credentials every time although they
are encrypted. Safe session ids, are better because there is one login with
the password and the 'password' for further requests is the session id (which
must be at least as safe then, preferably even safer), combined with a three
tries for the password mechanism or something similar. Best method are
HMAC's, but as far as I know, this is not available on PHP, but the default for
SSH or OpenVPN connections. suhosin adds many security improvements to
PHP (even to the default session mechanism) and I think it should be preferred
over htaccess. Regards, Felix Am 18.06.2010 17:01, schrieb
Jonathan Tripathy:
Thanks Felix.
What you think of the Apache htaccess method?
Thanks
My main security concern would be rather: If I were your customer, I
would want that my VM's console is completely secured. But just relying on PHP
sessions or HTTP-auth is not really secure, e.g.: http://www.h-online.com/open/news/item/PHP-blunders-with-random-numbers-967525.htmlA
hacker could abuse such insecure mechanisms of PHP to enter the session with a
well-guessed session-id. PHP Auth resends all login credentials every time a
request is made, and so there is no real session, which makes attacks
sometimes easier. Of course, the security of those applications can be
improved (especially with suhosin), but webservers and web-frontends are the
primary hacking target (and very often subject to vulnerabilities). I
wouldn't doubt that it will *work* with that method, but having it in a secure
way will be harder (but still possible). Probably you should consider
using an own session mechanism, but this will require an advanced and
security-aware PHP programmer. /dev/random (or if necessary /dev/urandom)
should definitely be used for gaining the entropy for the session id and it
should be long enough and further secured by ip address. And remember to do
that all on a SSL-only connection, using that without SSL would allow anyone
to do MITM attacks to capture the password / session
id. Regards, Felix Am 18.06.2010 16:30, schrieb Jonathan
Tripathy:
Thanks Felix,
Glad you like my idea. Since ajaxterm runs its own web server
(and you can specify the port is listens on, which would be one per
customer), I think it's just a matter of using php to control access to this
resource.
Another, easier way, would be to just use Apache's .htaccess
stuff (No sessions required). Just protect one directory per user, and in
each directory simply have an index.php that runs the correct ajaxterm
command for the user. Then Apache could use it's reverse proxy mechanism to
give the user access to ajax term. The "logical" address of the ajax term
would be a child of the inital htaccess protected directory. This isn't as
nice and doesn't scale well, but I'm pretty sure it would work..
Hi Jonathan, I think this is a great idea: The Domain-0 has full
SSH-security (can be limited to your webserver's internal ip address for
further security) and the webserver is not running on Dom0. You could
combine this approaches: SSH on Dom0, with RSA authentification and (for
example) sudo-wrapped xm console, accessed by your ajaxterm software. It
would be even possible to provide both methods to your customers, if the SSH
daemon is secured enough, or just allow that web console. When the web
console is secure enough, this will not expose any security threats to your
customers, and it would never be a threat to your Dom0s. You'll need to ask
the ajaxterm developers, I only know that many PHP session ids are *not*
safely generated and ajax can even extend that problem (on the other hand,
suhosin fixes that problem). SSH's HMAC-method is more safe, but many
applications rely on PHP's safety (some of them without being hacked), so it
would offer enough security if the application has no big security
issues. Regards, Felix Am 18.06.2010 16:09, schrieb
Jonathan Tripathy:
Hi Felix,
What I was thinking of doing (And i'll need to consult with
my php/java folk here to get this working in a secure way), is to run
Ajaxterm on the web server itself. When launch Ajaxterm, there is a -c
option that allows you to specify a command. With an ssh key stored in the
web server's filesystem (Which only is allowed to preform global xm
functions), I could do something like (The command would run locally on
the web server):
Where $vm_id could be storaed in a database and would be the
name of the DomU running
What you think?
Hi Jonathan, if you can do that, it's good. But you'll always
need some kind of access to the Dom0 to get the console data and to reboot
/ reset / rescue the VMs (whatever you want to offer to your
customers). Regards, Felix Am 18.06.2010 15:17, schrieb
Jonathan Tripathy:
Hi Felix,
Probably the main reason why I want to use a web console is
so that I can run the web server on a different machine (Or maybe in a
VM connected to an isolated network).
Thanks for the tip on the Grub password for the Dom0.
That's scary about the KVM!
Thanks
Jonathan
Hi Jonathan, the Dom0 cannot be compromised as long as your
SSH or web-based console does not have any security leaks. PHP
sessions are not as secure as SSH, but with SSL and suhosin patched PHP
considerably OK. As I said, I don't use web-based consoles so I
can't help you there, but I'd *really* consider whether it is a good
thing to setup a webserver on a Dom0 and it may be probably hard to do
web-based consoles without that. Regards, Felix P.S.
Anyway, considering the method I posted, you should always setup GRUB
and BIOS passwords for all of your Dom0s. I once requested KVM access at
my provider and ended up at the wrong server... Am 18.06.2010
15:03, schrieb Jonathan Tripathy:
Hi Felix,
I actually have that guy's book who wrote that article -
The book of Xen - very good book indeed!
What I really wish to do, is provide a similar sort of
thing to that SSH setup, except allow it to be accessed via a web
browser. I have an idea where I can use ajaxterm and some PHP
scripting. Once a user logs on with a username and password, I could
tell php to start ajaxterm and piple xm console through it. This is
what Slicehost does I think. The console would be protected with php
sessions.
But my main worry was whether or not the Dom0 could be
compramised via the above method, but I don't think that's the
case.
Thanks
Jonathan
Hi Jonathan, this is a common way to reset lost /
forgotton root passwords: You need: - Physical access to a
machine (if you want to reset the password of the Dom0 or a native
linux) or console access to a DomU - Access to the kernel command
line, via lilo, grub or pygrub/pvgrub in XEN Then you do: -
Modify the kernel command line, add the init=/bin/bash option, for
example: kernel /linux-2.6.32.15-xen root=/dev/xvda2
init=/bin/bash - You'll directly end up in a root console without
password or any services started after the kernel booted - enter
those commands: mount -o remount,rw / passwd root <enter
new password> exec /sbin/init The root password will then
be the newly set one. DomUs generally are not vulnerable to
this method, as long as the kernel command line is set in the domain
configuration. But pygrub/pvgrub is a nice thing for hosting
customers, because they can compile their own kernels, containing
their preferred settings, modules and builtin functionality. Generally
this problem is avoided by adding a password to grub, but some
customers may forget that step. So physical access can always be a
strong weapon, but it is necessary for repairing a machine or for some
advanced setups (especially when setting up a firewall, one easily
gets locked out of the server...). I think the best way is securing
this access, by restricting virtual console access to highly encrypted
and authenticated sessions (IMHO the best way is SSH here). I'd
also think about customers forgetting to log out, because leaving xm
console does *not* logout root inside the console. The tutorial
I posted to your I/O question contains a SSH-based setup for xm
console access with sudo, which may be nice to start with. I
personally use an own wrapper inside a chroot jail, to provide the
ability of entering commands like create / rescue / setup (rescue
starts another domain configuration with NFS root + rescue-Kernel,
setup starts a virtual Debian setup). It's quite handy for VPS
customers. Regards, Felix Am 18.06.2010 14:26,
schrieb Jonathan Tripathy:
Hi Felix,
Thanks for the email.
>a simple init=/bin/bash added to the kernel command
line allows resetting the root password...
ok this worries me.
Can you please explain this a little further? Do you need to have
access to the Dom0 to begin with?
Thanks
Hi Jonathan, do you definitely need a web console (so
really browser-based) or would you consider a SSH-based
console? I personally prefer SSH because it is more secure,
easier to set up and it is somehow the default way of accessing
remote consoles. You can do a modified SSH setup that only allows
access to the console, or optionally, access to xm console, xm list,
xm shutdown, xm create but restricted to the own VM of your
customer. With chroot-jails etc., other commands cannot be
executed. SSH also has the advantage of good copy & paste of
larger commands, and the possibility to work with multiple client
certificates and / or passwords. Probably your administrative
interface allows uploading of multiple public keys, so that your
customers can have multiple adminsitrative accounts for the server
(but only one can access the console at a time). I've got no
experiences with ajaxterm, but you should really control its
security: Console access is quite useful for hackers, e.g. some
customer may forget to log out root or if you use pvgrub / pygrub, a
simple init=/bin/bash added to the kernel command line allows
resetting the root password... So it must be a really secure
application, not vulnerable to XSS, SQL Injections, Connection
hijacking, ... and SSL encrypted. Regards, Felix
Kuperjans Am 18.06.2010 13:02, schrieb Jonathan Tripathy:
Hi Everyone,
Does anyone have any idea on how to give my customers
a "web console" for their VMs?
Using http://antony.lesuisse.org/software/ajaxterm/ I
can manually set up a remote session for them, by doing ajaxterm.py -c xm console <DOMNAME> However is there any way to make this automatic? Maybe I could put it in the vif script? Thanks
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users |
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
| <Prev in Thread] |
Current Thread |
[Next in Thread>
|
- RE: [Xen-users] Web Console Access, (continued)
- RE: [Xen-users] Web Console Access, Jonathan Tripathy
- Re: [Xen-users] Web Console Access, Felix Kuperjans
- RE: [Xen-users] Web Console Access, Jonathan Tripathy
- Re: [Xen-users] Web Console Access, Felix Kuperjans
- RE: [Xen-users] Web Console Access, Jonathan Tripathy
- Re: [Xen-users] Web Console Access, Felix Kuperjans
- RE: [Xen-users] Web Console Access, Jonathan Tripathy
- Re: [Xen-users] Web Console Access, Felix Kuperjans
- RE: [Xen-users] Web Console Access, Jonathan Tripathy
- Re: [Xen-users] Web Console Access, Felix Kuperjans
- RE: [Xen-users] Web Console Access,
Jonathan Tripathy <=
- Re: [Xen-users] Web Console Access, Jonathan Tripathy
- Re: [Xen-users] Web Console Access, Felix Kuperjans
- Re: [Xen-users] Web Console Access, Jonathan Tripathy
- Re: [Xen-users] Web Console Access, Felix Kuperjans
- Re: [Xen-users] Web Console Access, Tapas Mishra
|
|
|
Home