|
xen-users
RE: [Xen-users] Web Console Access
Thanks Felix.
What you think of the Apache htaccess method?
Thanks
From: Felix Kuperjans
[mailto:felix@xxxxxxxxxxxxxxxxxx]
Sent: Fri 18/06/2010
15:54
To: Jonathan Tripathy
Cc:
xen-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-users] Web Console
Access
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, 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