RE: Secure / Encrypt Terminal Services

From: M. Burnett (mb@xato.net)
Date: 11/27/02

  • Next message: auto473105@hushmail.com: "Embedded NT/XP security"
    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-----



    Relevant Pages

    • Re: "Linux Shminux - IPsec is Snake Oil!" VMS Mgmnt
      ... In addition to the Apple, IBM, SUN, Microsoft, and HP-UX support for IPsec I ... This was a public company which needed to meet Sarbanes-Oxley regulations and auditing, most of which covered security. ... I couldn't say whether IPSEC or some other form of encryption was really needed or not but I'm reasonably certain that none of my jobs since being discharged from the Army in 1969 used any form of encryption for internal network traffic. ...
      (comp.os.vms)
    • Re: Compression TCP/IP
      ... >>I'm currently examining IPsec. ... >>If encryption is used, then compression is not possible. ... (Security is also increased by compressing then encrypting) ...
      (comp.security.firewalls)
    • CryptoSurvey -- Results ..
      ... Many same or similar behavioral barriers for the ... effective utilization of many security solutions still exist limiting ... applications of encryption technologies currently in commercial ... Many people do not care about cryptography and/or security products ...
      (sci.crypt)
    • CryptoSurvey -- Results ..
      ... Many same or similar behavioral barriers for the ... effective utilization of many security solutions still exist limiting ... applications of encryption technologies currently in commercial ... Many people do not care about cryptography and/or security products ...
      (sci.crypt)
    • Re: OT - Kuwait
      ... > One place where I agree with you is that the scope of government intrusion ... > into the private matters of Americans is much greater than most Americans ... >>> strict security procedures to prevent unauthorized release of the keys. ... >> Feds Want to Control Encryption ...
      (alt.sports.football.pro.ne-patriots)