RE: Secure / Encrypt Terminal Services

• Previous message: Eric Devine: "RE: Secure / Encrypt Terminal Services"
• In reply to: Zack Berkovitz: "RE: Secure / Encrypt Terminal Services"
• Next in thread: David Vincent: "RE: Secure / Encrypt Terminal Services"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

From: "M. Burnett" <mb@xato.net>
To: <focus-ms@securityfocus.com>
Date: Tue, 26 Nov 2002 19:23:11 -0700

I have received a tremendous amount of feedback from that
SecurityFocus article, mostly from people telling me of different
variations that would work much better. In the article, I had meant
to demonstrate the concepts rather than specific solutions. There are
many other very good solutions that I did not mention such as STunnel
or IPSec. I think Zebedee is cool, but its not always the perfect
solution.

Terminal Services does have decent encryption, but it does not
provide any port access control nor does it provide sufficient
logging. For access control, IPSec is a great solution. Of course,
any packet filtering mechanism will also work great. One problem with
IPSec is that the the port will sometimes still show as being open
(although you may not be able to connect to it), depending on how
IPSec is configured.

As for logging, while some things are buried in the EventLog, the IP
address can be misleading (see
http://www.xato.net/Reference/xato-112001-01.txt) and sometimes the
logs are not consistent. For example, it will only log a successful
login, not someone just connecting to the server. I don't remember
all the problems off hand, but as we researched the xato advisory we
found many inconsistencies in the EventLog. I therefore concluded
that it could not be fully trusted. A separate Terminal Service log
file would be quite useful.

As for the encryption, I do feel somewhat safe using the built-in
encryption but I am not totally convinced that it has been
sufficiently proven secure. In high-security scenarios, such as
government or millitary use, or say, protecting the recipe for Coke,
I would certainly consider additional security. Flaws have been
found in the encryption and we do not know what other flaws may
exist.

My preferred solution is to use Terminal Services over IPSec, with
additional packet filtering and logging done at a firewall or router
to limit which IP addresses can even see the port. Here's a good
article on TS over IPSec:
http://www.ntsecurity.net/Articles/Index.cfm?ArticleID=20288

Mark Burnett
www.iissecurity.net

On Tue, 26 Nov 2002 14:06:58 -0500, Zack Berkovitz wrote:
>In the securityfocus article, it states:
>
>Terminal Services is a built-in service in Windows 2000 that
>provides admins with a remote desktop for managing a server.
>Terminal Services is the most obvious way to remotely manage a
>server because it is built-
>in, easy to get running, uses built-in Windows accounts for
>authentication, and allows for strong encryption. But there are some
>limitations: there is no mechanism to limit access by IP address, it
>is not obvious how to change the default listening port, and it has
>no logging facility.
>Based on the list of requirements at the beginning of this article,
>Terminal Services alone does not score well on security.
>
>
>There are several easy-to-follow steps to use the included tools to
>achieve similar results with less overhead (latency and packet
>overhead-- i.e. no second wrapper):
>
>Access can be limited by IP filter or IPSec policy native to the OS,
>the listening port can be changed in the registry:
>
>http://support.microsoft.com/default.aspx?scid=kb;en-us;187623
>
>
>Logging occurs in the security log. You can change the local audit
>policy to include what you want logged.
>
>Some packets (licensing info and print job acknowledgments aren't
>encrypted (who knows why), so this may be a concern:
>
>http://support.microsoft.com/default.aspx?scid=kb;en-us;275727
>
>
>
>The RDPClip and Drmapsrv utilities from the resource kit will allow
>you to map local client drives into the session and copy files over
>the encrypted session:
>
>http://support.microsoft.com/default.aspx?scid=kb;en-us;309825
>
>
>It doesn't work with the Advanced client (the XP version, which you
>can run on 2K), however:
>
>http://support.microsoft.com/default.aspx?scid=kb;EN-US;278139
>
>
>
>And, of course, you can install the high encryption pack and specify
>that all RDP sessions must be 128-bit encrypted in the Terminal
>Services Configuration snap-in.
>
>
>So, really, the main limitations are the type of encryption or its
>strength (you feel more comfortable with 3DES, for example), and
>potentially the few packets which are sent in the clear (you don't
>want someone knowing your printer names... Actually, I recommend
>disabling all port, printer, and drive mapping by policy-- clipoard
>mapping is generally the only mapping necessary for remote
>management, unless you need to transfer files and don't have some
>other method.) Also, does anyone know if you can replay encrypted
>RDP?
>
>The easiest thing to do for a non-sensitive server (i.e. end-user
>terminal server box) is to use a network VPN first. I've used a
>hardware VPN with IPSec 3DES and client software in the past. This
>way you don't have to set up IPSec on the box.
>
>For the original question, IPSec sounds like a good solution,
>although if the WAN is somewhat controlled, then the default 128-bit
>encryption may be sufficient.
>
>- Zack
>
>
>
>
>
>-----Original Message-----
>From: jason d. montgomery [mailto:jason@atgi.com] Sent: Monday,
>November 25, 2002 8:05 PM To: focus-ms@securityfocus.com Subject:
>RE: Secure / Encrypt Terminal Services
>
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>One solution we implemented involved setting up IPSec between a
>Cisco PIX at the enterprise to SafeNet Soft-Pk software
>(http://www.safenet-inc.com/) on the client side - then run terminal
>services through the tunnel.
>
>If you want to set something up a bit simpler than setting up IPSec,
>I just read an article on this very topic:
>
>Remote Management of Win2K Servers: Three Secure Solutions
>http://online.securityfocus.com/infocus/1629
>
>later, jason
>
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>
>>Does the community have an opinion on which is the best way to do
>>this? Can it be done via IP-Sec? Basically we have a machine
>>(tripwire manager) that will have access to all our networks. Due
>>to politics (gotta love security made insecure by politics) it must
>>be
>>
>>remotely managed. The CIO (god bless CIO's) has decided that we
>>will use terminal services. Is there a way to encrypt the traffic
>>so it is
>
>>not flying around the network in clear text? Would IP-Sec be the
>>recomended solution?
>>
>>Suggestions or links (or gentle shoves) to the information would be
>> great.
>>
>>Thanks
>>
>>
>>-----BEGIN PGP SIGNATURE-----
>>Version: Hush 2.2 (Java) Note: This signature can be verified at
>>https://www.hushtools.com/verify
>>
>>
>>wl0EARECAB0FAj3c67gWHG9obm9ub25vQGh1c2htYWlsLmNvbQAKCRAuXN+1lPsfqYk9
>> AJ4ndm/CgplNAjJHfTV5oSgPLfoYYwCfYUHT6Cta9Or1jTiu4KGfYokrjYg= =2bx1
>>-----END PGP SIGNATURE-----
>>
>>
>>
>>
>>Get your free encrypted email at https://www.hushmail.com
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.0.6 (MingW32) Comment: For info see
>http://www.gnupg.org
>
>iD8DBQE94vLQv6RvkvBVJ4sRAkHBAKDQ9Yxr2JG+SXdpnoN2fWZ8XN6RpwCgr/xT
>FMWwbZoWcmnbqUN/HoBnIkE= =aCn9 -----END PGP SIGNATURE-----

• Next message: auto473105@hushmail.com: "Embedded NT/XP security"
• Previous message: Eric Devine: "RE: Secure / Encrypt Terminal Services"
• In reply to: Zack Berkovitz: "RE: Secure / Encrypt Terminal Services"
• Next in thread: David Vincent: "RE: Secure / Encrypt Terminal Services"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]