Hi Jonathan,
I think this would increase the risk if ajaxterm would not be secure
enough and you will need SSH anyway... I'll have a look at ajaxterm now:
(Note that I only read their website, did not test it locally)
- Ajaxterm seems to contain an own little webserver, which is usually
proxied through apache2 (or other Webservers) for SSL encryption and
port access. I think you won't be able to use PHP sessions here!
Httpauth would be possible, indeed.
- Many applications nowadays require UTF-8 locales (e.g. python3 AFAIK)
to have their full functionality, but ajaxterm only handles latin1. As
long as the language is English, most letters will have the same UTF-8
and latin1-codes, but it would not support some special characters in
the terminal (even © would be a problem).
- I'd say that the dom0 should only use SSH, but I'd really reconsider
if you need a web console. SSH can be easily accessed with Windows,
Linux and Mac and offers really secure encryption and authentication
mechanisms.
I don't think that the ability to restrict the access to Dom0's
services (SSH / ajaxterm) with a firewall is a big pro:
If the users get access via apache2 to Dom0's ajaxterm or via ajaxterm
on the webserver to Dom0's SSH, exploits will be usable as well via
that proxy (for example, worst case: xm console would have a bug that
would allow command execution with xm's rights (root!) within Domain-0
on a special key combination - it would work either way, but such
severe bugs have never existed in the history of XEN).
Try out some SSH-based setups, I personally prefer them to any
web-based solution (restart / shutdown etc. can still be handled with a
web-interface). If you like, I could help you with SSH configuration /
hardening.
Regards,
Felix
Am 19.06.2010 11:22, schrieb Jonathan Tripathy:
Hi Felix,
I have another idea to maybe make it easier to implement:
Instead of running Ajaxterm locally on the web server, I could run it
on the xen host itself. Inside the vif script, everytime the VM starts
up, I could put in a line that starts ajaxterm and binds it to a port
which is specific to that user. Then, I could use iptables to make sure
that the only machine which has access to this port is the web server.
Then on the web server, php could handle all the authentication, and
then "proxy" the ajaxterm output from the xen host to the user. No ssh
keys required!
Pros:
Easy to start/stop ajaxterm by using the vif scripts
Easy to firewall (just use iptables)
Cons:
Lots of ajaxterms will be launched (1 per vm), so the xen host may not
handle this very well
The web server will need to use ssh anyway for startup/shutdown/restart
of VMs
What you think?
Thanks
On 18/06/10 16:11, Felix Kuperjans wrote:
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.html
A 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
|
