Managing Hyper-V
-
@stacksofplates said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
@brianlittlejohn said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
@Tim_G said in Managing Hyper-V:
If it's off domain, you have to perform a couple quick extra steps that can be put into a script.
I've never tried to use RSAT over a WAN, seems like a bad idea
I use it over a vpn to our office in OKC... it works a little slow, but it works.
VPN is just another term for the LAN, just a slow portion of it. That's still LAN security as a model, which we don't do here.
So how do you do it with SCALE? You leave the web interface public facing?
Yes, that's the idea. Properly secured web is the same as a VPN, but limited to a single task. So equal or more secure. Scaling, now that requires some kind of automation to handle it, but can be done.
-
@scottalanmiller said in Managing Hyper-V:
@stacksofplates said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
@brianlittlejohn said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
@Tim_G said in Managing Hyper-V:
If it's off domain, you have to perform a couple quick extra steps that can be put into a script.
I've never tried to use RSAT over a WAN, seems like a bad idea
I use it over a vpn to our office in OKC... it works a little slow, but it works.
VPN is just another term for the LAN, just a slow portion of it. That's still LAN security as a model, which we don't do here.
So how do you do it with SCALE? You leave the web interface public facing?
Yes, that's the idea. Properly secured web is the same as a VPN, but limited to a single task. So equal or more secure. Scaling, now that requires some kind of automation to handle it, but can be done.
True but now your only barrier is the login page. So any vulnerabilities in whatever language it's in (e.g. PHP) is the only barrier.
-
@stacksofplates said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
@stacksofplates said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
@brianlittlejohn said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
@Tim_G said in Managing Hyper-V:
If it's off domain, you have to perform a couple quick extra steps that can be put into a script.
I've never tried to use RSAT over a WAN, seems like a bad idea
I use it over a vpn to our office in OKC... it works a little slow, but it works.
VPN is just another term for the LAN, just a slow portion of it. That's still LAN security as a model, which we don't do here.
So how do you do it with SCALE? You leave the web interface public facing?
Yes, that's the idea. Properly secured web is the same as a VPN, but limited to a single task. So equal or more secure. Scaling, now that requires some kind of automation to handle it, but can be done.
True but now your only barrier is the login page. So any vulnerabilities in whatever language it's in (e.g. PHP) is the only barrier.
That can be done at the server level, too. But not ideal. Or can be done with keys and not a login. All the same limitations as any VPN.
-
But all VPN solutions have that limitation. The difference here is that the limitation only exists for this one thing, rather than the entire network.
-
@scottalanmiller said in Managing Hyper-V:
But all VPN solutions have that limitation. The difference here is that the limitation only exists for this one thing, rather than the entire network.
My point is I don't understand why you go with salt because of the concern of security with SSH but you leave a web page open directly to the internet.
I trust SSH on a bastion host which gets daily updates and bug fixes more than I trust a web page that gets development but not daily updates.
-
@stacksofplates said in Managing Hyper-V:
My point is I don't understand why you go with salt because of the concern of security with SSH but you leave a web page open directly to the internet.
Because I can turn access on and off with Salt.
-
@stacksofplates said in Managing Hyper-V:
I trust SSH on a bastion host which gets daily updates and bug fixes more than I trust a web page that gets development but not daily updates.
As the web page uses the same daily updates for the encryption as SSH, I don't think that this is an issue. Both rely on the same OpenSSL library equally.
-
Or if you can lock it down to a local tunnel through SSH that would be better. Ours isn't set up yet so I'm not sure if you can do that.
-
@scottalanmiller said in Managing Hyper-V:
@stacksofplates said in Managing Hyper-V:
I trust SSH on a bastion host which gets daily updates and bug fixes more than I trust a web page that gets development but not daily updates.
As the web page uses the same daily updates for the encryption as SSH, I don't think that this is an issue. Both rely on the same OpenSSL library equally.
The hosts get daily updates from SCALE? And SSL updates don't fix bugs in PHP or JS or whatever they use.
-
@stacksofplates said in Managing Hyper-V:
Or if you can lock it down to a local tunnel through SSH that would be better. Ours isn't set up yet so I'm not sure if you can do that.
I figure anything you can do through a web or SSL tunnel, you can do through SSH, too. And I've been trying to figure out how to automate that well with a "reach out" system and if that is logically a good approach.
-
@stacksofplates said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
@stacksofplates said in Managing Hyper-V:
I trust SSH on a bastion host which gets daily updates and bug fixes more than I trust a web page that gets development but not daily updates.
As the web page uses the same daily updates for the encryption as SSH, I don't think that this is an issue. Both rely on the same OpenSSL library equally.
The hosts get daily updates from SCALE? And SSL updates don't fix bugs in PHP or JS or whatever they use.
Oh, on the Scale specifically? No, not daily. But regularly. It alerts you whenever there is an update to apply. I don't get SSH regularly either. I update systems daily and go weeks or months between OpenSSH or OpenSSL library updates at times. But they are released on any given day as needed, and the same with the Scale.
Language bugs exist for everything, including for SSH.
-
But with web, you have good choices like adding reverse proxies and such. It's easy to lock down SSL based channels in standard but still accessible ways.
-
@scottalanmiller said in Managing Hyper-V:
@stacksofplates said in Managing Hyper-V:
Or if you can lock it down to a local tunnel through SSH that would be better. Ours isn't set up yet so I'm not sure if you can do that.
I figure anything you can do through a web or SSL tunnel, you can do through SSH, too. And I've been trying to figure out how to automate that well with a "reach out" system and if that is logically a good approach.
But web isn't key based. A 4096 bit key is better than a login page no matter how long the password is. And mitigates brute forcing (whether that's even still a concern anymore).
-
@scottalanmiller said in Managing Hyper-V:
@stacksofplates said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
@stacksofplates said in Managing Hyper-V:
I trust SSH on a bastion host which gets daily updates and bug fixes more than I trust a web page that gets development but not daily updates.
As the web page uses the same daily updates for the encryption as SSH, I don't think that this is an issue. Both rely on the same OpenSSL library equally.
The hosts get daily updates from SCALE? And SSL updates don't fix bugs in PHP or JS or whatever they use.
Oh, on the Scale specifically? No, not daily. But regularly. It alerts you whenever there is an update to apply. I don't get SSH regularly either. I update systems daily and go weeks or months between OpenSSH or OpenSSL library updates at times. But they are released on any given day as needed, and the same with the Scale.
Language bugs exist for everything, including for SSH.
That's my point tho. You get them immediately when they are available.
-
@scottalanmiller said in Managing Hyper-V:
But with web, you have good choices like adding reverse proxies and such. It's easy to lock down SSL based channels in standard but still accessible ways.
You can do that with local tunnels too which is why I mentioned that. To me that would be the preferable way. Tunnel to 127.0.0.1
-
@stacksofplates said in Managing Hyper-V:
But web isn't key based.
Actually it is. That's an option with every web server and browser that I know. Just no one uses it. But it is the same mechanism that OpenVPN uses for its key based VPN authentication. Literally the same one, same keys, same libraries used. Long ago we had to learn that for web management certs. Today, it's been like forgotten. But it is there and a totally viable mechanism if you are considering the same approach with a VPN or SSH.
-
@stacksofplates said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
@stacksofplates said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
@stacksofplates said in Managing Hyper-V:
I trust SSH on a bastion host which gets daily updates and bug fixes more than I trust a web page that gets development but not daily updates.
As the web page uses the same daily updates for the encryption as SSH, I don't think that this is an issue. Both rely on the same OpenSSL library equally.
The hosts get daily updates from SCALE? And SSL updates don't fix bugs in PHP or JS or whatever they use.
Oh, on the Scale specifically? No, not daily. But regularly. It alerts you whenever there is an update to apply. I don't get SSH regularly either. I update systems daily and go weeks or months between OpenSSH or OpenSSL library updates at times. But they are released on any given day as needed, and the same with the Scale.
Language bugs exist for everything, including for SSH.
That's my point tho. You get them immediately when they are available.
Right, and you do with Scale, too. That was what I was saying. When a critical bug is released, you get the update. It's not a scheduled thing like "once a month" or something like that. If you used SSH in the same places as web, you'd have the same update pattern regardless.
-
@stacksofplates said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
But with web, you have good choices like adding reverse proxies and such. It's easy to lock down SSL based channels in standard but still accessible ways.
You can do that with local tunnels too which is why I mentioned that. To me that would be the preferable way. Tunnel to 127.0.0.1
Six of one, half a dozen of the other. Same tunnel mechanism, same security.
-
@scottalanmiller said in Managing Hyper-V:
@stacksofplates said in Managing Hyper-V:
But web isn't key based.
Actually it is. That's an option with every web server and browser that I know. Just no one uses it. But it is the same mechanism that OpenVPN uses for its key based VPN authentication. Literally the same one, same keys, same libraries used. Long ago we had to learn that for web management certs. Today, it's been like forgotten. But it is there and a totally viable mechanism if you are considering the same approach with a VPN or SSH.
But hat either needs server side support for SOCKS or some kind of challenge file, or some way for your local browser extension for the keys.
-
@scottalanmiller said in Managing Hyper-V:
@stacksofplates said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
But with web, you have good choices like adding reverse proxies and such. It's easy to lock down SSL based channels in standard but still accessible ways.
You can do that with local tunnels too which is why I mentioned that. To me that would be the preferable way. Tunnel to 127.0.0.1
Six of one, half a dozen of the other. Same tunnel mechanism, same security.
Not really because the form is still open. I. Can eliminate passwords with SSH completely or use Kerberos tickets.
