Remote Management of Win2K Servers: Three Secure Solutions

[Phantasm66]

Its another great article, this time on how to make a secure connection over the net to your windows 2000 box for means of remote administration. As this is a very current interest of mine, I've posted a link to the article here for your enjoyment....

Remote Management of Win2K Servers: Three Secure Solutions

by Mark Burnett
last updated September 25, 2002

--------------------------------------------------------------------------------

It's a common scenario: your company has an IIS Web server sitting 300 miles away at a high-bandwith, air-conditioned and power-regulated co-location center. The network is stable and the price is right, but you must completely manage the server remotely; you can't just go sit down at the console whenever you want. Remote management presents several problems, the most obvious being that the traffic between you and the server is travelling across the public Internet, available for others to sniff. Another problem is that remote administration normally involves installing software and opening ports, both of which increase the attack surface of your server. The goal when selecting a remote administration solution is to make sure that you (and only you) can do your job without exposing the server to additional risk.

In particular, the concerns when administering a remote server are:

Access Control
Integrity
Confidentiality
Auditing
Access Control

Access control is making sure that only you can remotely administer the server. This means that the remote administration software should only accept connections from a small range of IP addresses and should prompt for a username and password. Access control can be further strengthened through the use of smart cards and client certificates. There are also obscurity techniques that may provide additional layers of protection such as using non-standard TCP ports or suppressing service banners.

Integrity

Integrity ensures that the data received by the server is the same data that you sent. You also want to be sure that a packet is authentic and cannot be replayed at a later time.

Confidentiality

Perhaps the greatest concern with remote administration is that sensitive data is travelling across a public network. Confidentiality ensures that this traffic cannot be intercepted and viewed by others. Confidentiality means using strong, accepted encryption algorithms with a sufficiently large encryption key.

Auditing

Auditing is the ability to log all access to a server for later analysis. It is important to remember that a server could very well become a crime scene and it is essential that your remote access solution keep sufficient information about every connection to the server. Furthermore, the logs should be moved off the server itself to ensure their integrity.

Remote Management Methods

Although there are a variety of ways to remotely manage a Win2K server, not all products provide the security requirements listed above. But that doesn't mean we cannot use them. By combining different products we can come up with some very secure solutions that provide features we need to administer remotely.

Below are some examples of what can be done using built-in or third-party open source solutions. While there is no one best way to remotely administer a server, these are good examples of what can be done when combining solutions.

Read more at: http://online.securityfocus.com/infocus/1629

http://www.winton.org.uk/zebedee/

http://www.networksimplicity.com/openssh/

 

[Elcarion]

SSH2 is a great solution for UNIX administration whether it's remote or not. I disable telnet, ftp, and similar on all of my systems. SSH2 with X-11 tunnelling works great with either Cygwin, Exceed, or similar!
On the other hand, I haven't had good results tunnelling VNC over SSH2. I've tried it between my RH 7.3 workstation and my Win2K laptop using a D-Link 10/100 Switch. The problem that I had was that the client would lock up and/or miss screen updates from the server. Direct VNC between the two worked great. I tried both the regular VNC and TightVNC with the same results. TightVNC did work a bit better (it lasted a minute before locking rather than 30 seconds).

If you're using OpenSSH I recommend the following: 1) Disable root logins, 2) Use shared key authentication over userid/password, and 3) Disable SSH1 protocol. You might also consider the added support/security of a non-open source SSH2 distro like F-Secure if you're in a corporate environment.

I'm not really sure about the advantages of using Zebedee over SSH2, if there are any. I don't see any known expoits for Zebedee while there have been several found for OpenSSH. You could look at this as either good or bad.