amuck-landowner

Stallion 2 - pictures and daily updates :)

Zen

New Member
Encrypting the source is completely against the ideals we had for stallion and if we were to ever market it.


I just don't know how I'd do it if we ever did.


Francisco
Confusing scenario really. Though you've probably already thought of it, a licence checker type thing would easily name and shame the hosts using illegal copies and allow you to keep it unencrypted.

Furthermore, you could license it out without any guarantee of updates/fixes/etc. That way it doesn't become a full time job, and if licensed correctly the unencrypted nature of it would allow hosts that know what they are doing to change what needs to be changed and advance it even further.
 
Last edited by a moderator:

Francisco

Company Lube
Verified Provider
Confusing scenario really. Though you've probably already thought of it, a licence checker type thing would easily name and shame the hosts using illegal copies and allow you to keep it unencrypted.
No one would care alas.

If LET proved anything it's about what companies have some form of dignity.

Francisco
 

Francisco

Company Lube
Verified Provider
I need some feedback from users & providers alike on KVM security:

[06:34] <~Delta> so vnc is insecure and i know some kvm users disable it once they're all done

[06:35] <~Delta> since the new remote console i'm adding is entirely HTML5/ajax, it means we could add an option

[06:35] <~Delta> 'only allow VNC from the control panel' or something like that

[06:35] <~Delta> since i could just have the node firewall the port to only allow manage's ip

[06:35] <~Delta> that'd give users some protection as well as access if they need it

[06:36] <~Delta> user<>manage is all https with websockets ssl too

[06:36] <~Delta> and the end user doesn't provide the password

[06:36] <~Delta> it's entirely token based

Honestly, the 'disable vnc entirely' option seems pointless on the basis that if someone can get into your user to toggle said control, you have much bigger problems anyways.

Encrypted FS doesn't make a difference either since users need to be able to type their details at POST time to get the FS to unlock.

All feedback is welcome and appreciated.

Francisco
 

acd

New Member
Dearest Pony Lord;

As a paranoid KVM user and moderately long-term customer of yours, I'm one of those folks advocating turning off VNC after you're done with it and only turning it on as needed. As security conscious as your team seems to be, I'm sure you've got some monitoring in place to prevent brute force attempts on VNC ports, but still, they are vulnerable. It wouldn't be so bad if VNC didn't silently truncate your passwords to 8 characters, or send them with one of the weakest crypto schemes ever, as well as plaintext key events and absolute mouse posi.... you get the idea, it's an insecure pile of horse manure if you can get the right logging window in tcpdump.

That being said, my answer to your question is "It really depends". If you have a fantastic VNC/console implementation in HTML5/ajax, then for sure, this will help a lot. I will pretty much use the manage page exclusively and I'll set up the IP lock you'd implement. If it's crap, nobody is going to use it anyway, so it's not going to help a lick. I have a couple of concerns that this centralizes the point of failure to your Stallion2 server in both a security sense--comp'd stallion2 would mean free reign to everyone's goodies, a situation not much different than it is now; and a reliability sense--a failure of your LV or CN networks would make all KVMs unreachable via VNC console, as opposed to just LV on fail there, or nobody, if just CN dropped out. That being said, for most users the feature you propose would be be a fair step up in security in a way that is nearly transparent to users which is pretty much win/win.

If you're going to implement firewall IP locks for VNC however, I would really appreciate it if you implemented a full IP ACL solution, which is not too much further away, though I will be the first to admit the increase in complexity is not trivial. If I could lock to specific IPs, I'd be much more willing to leave VNC running, just in case. The way I handle security now is two faceted. First, at both of your locations I have a single VPN server on a 128 (used to be just ssh port forward, that works equally well) that I use to manage my machines at each site, still using external IPs since I don't know the VLAN IPs for the host nodes. Not that it matters, at that point the traffic is as secure as your LAN is, which is about the same as running VNC from Stallion2. Second, on any KVM which has data I think should be moderately secure, I'm running key-only ssh-unlocked FDE (not console unlockable). Debian 6 & 7 have made that setup extremely simple so there's no longer any reason not to and it's a lot easier to type my boot-server alias and type in the ssh key's passphrase than it is to vnc, etc. Foolproof, it is not, but it's the best I can do with the tools I've got. Having an encrypted FS is about making yourself a less easy target than your VM neighbor, hopefully giving me enough time to notice something is up.

tl;dr: You should do it, and it should default to "Locked to Stallion2". Please add VNC IP ACLs to your someday-TODO list as well.

best regards,
-tw
 
Last edited by a moderator:

Francisco

Company Lube
Verified Provider
Dearest Pony Lord;


As a paranoid KVM user and moderately long-term customer of yours, I'm one of those folks advocating turning off VNC after you're done with it and only turning it on as needed. As security conscious as your team seems to be, I'm sure you've got some monitoring in place to prevent brute force attempts on VNC ports, but still, they are vulnerable. It wouldn't be so bad if VNC didn't silently truncate your passwords to 8 characters, or send them with one of the weakest crypto schemes ever, as well as plaintext key events and absolute mouse posi.... you get the idea, it's an insecure pile of horse manure if you can get the right logging window in tcpdump.


That being said, my answer to your question is "It really depends". If you have a fantastic VNC/console implementation in HTML5/ajax, then for sure, this will help a lot. I will pretty much use the manage page exclusively and I'll set up the IP lock you'd implement. If it's crap, nobody is going to use it anyway, so it's not going to help a lick. I have a couple of concerns that this centralizes the point of failure to your Stallion2 server in both a security sense--comp'd stallion2 would mean free reign to everyone's goodies, a situation not much different than it is now; and a reliability sense--a failure of your LV or CN networks would make all KVMs unreachable via VNC console, as opposed to just LV on fail there, or nobody, if just CN dropped out. That being said, for most users the feature you propose would be be a fair step up in security in a way that is nearly transparent to users which is pretty much win/win.


If you're going to implement firewall IP locks for VNC however, I would really appreciate it if you implemented a full IP ACL solution, which is not too much further away, though I will be the first to admit the increase in complexity is not trivial. If I could lock to specific IPs, I'd be much more willing to leave VNC running, just in case. The way I handle security now is two faceted. First, at both of your locations I have a single VPN server on a 128 (used to be just ssh port forward, that works equally well) that I use to manage my machines at each site, still using external IPs since I don't know the VLAN IPs for the host nodes. Not that it matters, at that point the traffic is as secure as your LAN is, which is about the same as running VNC from Stallion2. Second, on any KVM which has data I think should be moderately secure, I'm running key-only ssh-unlocked FDE (not console unlockable). Debian 6 & 7 have made that setup extremely simple so there's no longer any reason not to and it's a lot easier to type my boot-server alias and type in the ssh key's passphrase than it is to vnc, etc. Foolproof, it is not, but it's the best I can do with the tools I've got. Having an encrypted FS is about making yourself a less easy target than your VM neighbor, hopefully giving me enough time to notice something is up.


tl;dr: You should do it, and it should default to "Locked to Stallion2". Please add VNC IP ACLs to your someday-TODO list as well.


best regards,


-tw
Hm.

Adding ACL support wouldn't be very hard if I'm already doing the other controls. I could simply just give each VPS its own INPUT table in IPTABLES, default policy DENY then just add allowed ip's/networks.

 How does 10 ACL entries sound? It would support ip's as well as networks (ex. allow anything from 1.2.3.4/24).

Francisco
 
Last edited by a moderator:

Kyle

New Member
Wow it's amazing, it's one of the nicest panels I've seen! How long has it been in development? (Not sure if you said that in here already if you did sorry I must have read over it)
 

Francisco

Company Lube
Verified Provider
Wow it's amazing, it's one of the nicest panels I've seen! How long has it been in development? (Not sure if you said that in here already if you did sorry I must have read over it)
11/2 months.


Francisco
 

bzImage

New Member
[18:39:09] <bzImage> Allow vnc to be disabled entirely, but actually tell the user that it's disabled when they try to go and use it. It's rare but a few clients ticket aboot it and go 'vnc isn't working.'
[18:39:18] <bzImage> on top of your idear.
 
Last edited by a moderator:

Francisco

Company Lube
Verified Provider
[18:39:09] <bzImage> Allow vnc to be disabled entirely, but actually tell the user that it's disabled when they try to go and use it. It's rare but a few clients ticket aboot it and go 'vnc isn't working.'


[18:39:18] <bzImage> on top of your idear.
Will do :)


So far the 'whats left' list is shrinking quickly.

  • RDNS needs to push entries into powerdns
  • Re-Write powerdns interface into a codeigniter controller instead of a procedural page like it currently is
  • OpenVZ virtual server creation
  • - This is just for provisioning. We don't really need the option to manually create virtual servers in an initial release
  • Write a new WHMCS module that does basic controls. We don't need panel controls in WHMCS short of admin ones
  • Client side API controls. I'll need to introduce 'versions'.
  • - /v1/ will support all solusvm controls allowing users to continue using their current setup
  • - /v2/ will add support for pretty much everything the frontend can do for users.
  • Virtual server statistics. I'm still not sure how I want to store these.
  • remote console access for KVM & OpenVZ users. We could launch with java based clients but ehhhhhh
 

Francisco

Company Lube
Verified Provider
Please no java. Clients shouldn't have to click "Yes" to 20 different prompts because java has a zero day exploit 3 times a week.
I'll be using novnc which is entirely javascript based (and if that doesn't work, it'll use flash).


I can actually reuse a lot of Nikki's code for it so I'll likely do that.

Francisco
 

Francisco

Company Lube
Verified Provider
10 ACL entries is more than sufficient for my needs, more than twice sufficient actually. Thanks, boss.
sounds good sir :) Thanks for the feedback.

Console accounts for a fairly large part of what's left.

Francisco
 
Top
amuck-landowner