Mailing List Archive

On the wisdom of using conserver in a multi-tenant environment
Hi, I'm about to launch a standardized co-location package that
includes serial console access. My current plan is to use conserver
fronting cyclades TS-3000 boxes to provide access to the serial ports.
The thing of it is, I'll have mutually untrusted users accessing
different ports on the same conserver box (which will access different
ports on the same ts-3000)

Is anyone else doing this? Are there any obvious gotchas?
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
Re: On the wisdom of using conserver in a multi-tenant environment [ In reply to ]
> Is anyone else doing this? Are there any obvious gotchas?

I have some mutually untrusted users:) One advice: don't put passwords
in conserver.cf, users can display that via 'console'.

Andras
--
Andras HORVATH
Systems engineer, CERN CF FPP
Tel: +41 22 767 4290 // Fax: +41 22 766 9154
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
Re: On the wisdom of using conserver in a multi-tenant environment [ In reply to ]
There's also a "limited" access type for restricting what users can do, which might help. It was added for a setup where a user logs into the conserver host and their shell is a script that invokes console with the appropriate console name. That could be a program that lets them chose their console too, if there are multiple.

If they have a full shell on the host, then this probably doesn't matter as much. Just figured I'd highlight the option.

(and sorry for the blank email luke - goofed up)

Bryan

On Dec 8, 2010, at 11:06 PM, Luke S Crawford <lsc@prgmr.com> wrote:

>
> Hi, I'm about to launch a standardized co-location package that
> includes serial console access. My current plan is to use conserver
> fronting cyclades TS-3000 boxes to provide access to the serial ports.
> The thing of it is, I'll have mutually untrusted users accessing
> different ports on the same conserver box (which will access different
> ports on the same ts-3000)
>
> Is anyone else doing this? Are there any obvious gotchas?
> _______________________________________________
> users mailing list
> users@conserver.com
> https://www.conserver.com/mailman/listinfo/users

_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
Re: On the wisdom of using conserver in a multi-tenant environment [ In reply to ]
Bryan Stansell <bryan@conserver.com> writes:

> There's also a "limited" access type for restricting what users can do, which might help. It was added for a setup where a user logs into the conserver host and their shell is a script that invokes console with the appropriate console name. That could be a program that lets them chose their console too, if there are multiple.

That sounds like part of what I need. In the past I just used a
FreeBSD box with the proper 'cu' command line in the 'forced command'
field of the authorized_keys file. My xen hosts do something similar
only it goes to a script that allows you to reboot your xen server or
see the console. The problem is that this requires (very limited)
ssh access to the dom0 from the public 'net, which is something I'd rather
avoid.

As xen provides me with a pty for each guest, I could probably
make conserver also handle my xen guests, with a central conserver connecting
to slave conservers on each dom0 (or alternately having a guest running
conserver on each dom0 that connects to the dom0 conserver over a private
network)

My worry, of course, with centralizing my console server is that I'll
be creating a single server that, if compromised, will give an attacker
a toehold on all my customer's boxes.

One thought I had was to separate out the systems used for the
serial console and for the rebooter on to different systems
(authenticated with public key, of course, so the user can use
the same token to authenticate both places, but also so that
if the attacker compromises one system s/he can't use that as a
toehold to compromise the other.)

My thought is that if magicsysrq is disabled, even if someone
compromises my console system, they can only break into the systems
with weak passwords (or people who log in) - the idea being that
if I notice the compromise quickly, I may only have a few customers
compromised. If the rebooter system is compromised and not the
console system, the attacker can reboot stuff or even turn
everyone off, but without also having access to the console system,
this wouldn't allow them to compromise data.


_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
Re: On the wisdom of using conserver in a multi-tenant environment [ In reply to ]
bryan@conserver.com wrote:
> There's also a "limited" access type for restricting what users can do, which might help. It was added for a setup where a user logs into the conserver host and their shell is a script that invokes console with the appropriate console name. That could be a program that lets them chose their console too, if there are multiple.

Luke, thank you for starting this thread. I apologize for the hijack.
Bryan, thank you for mentioning the "limited" switch. Somehow I
hadn't noticed it before.

I'm headed down a similar road where I'd like to deploy a solution in
which users telnet to the conserver host and find themselves connected
to a serial console on a terminal server somewhere. Basically, the
conserver host will be nothing more than a mux for several terminal
server appliances. Each physical serial port appears on a different
TCP port on the conserver box. Telnet because I can give the users a
telnet URL that can be reasonably expected to work, and because I'm
not concerned about securing the user's session.

The users won't have shell access, and I don't want to require them to
have anything beyond a standard telnet client.

I'd been thinking about using inetd to start 'console'. ...Probably
in a chroot jail, and probably with each bunch of consoles running
under different user ids. iptables will make sure that customers can
only connect to tcp ports associated with their devices.

Is this sane? How can I improve on the plan?

Thank you!

/chris

_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users