[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 511
  • Last Modified:

Confused about IPSEC in windows 2k, help!?

Hi All, I enabled a w2k server with IPEC Terminal Services using the microsoft article below.  My question is, that I have read that IPSEC automatically works when configured this way.  

Why then do I hear about root creating certificates in order secure IPSEC??  This is confusing.  I didn't create any certificates so why would anyone go to the trouble to do so if they didn't have to??  Article below:




"To Use IPSec Policy to Secure Terminal Services Communications in Windows 2000
View products that this article applies to.
Article ID : 315055
Last Review : July 15, 2004
Revision : 2.1
This article was previously published under Q315055
IN THIS TASK
• SUMMARY
  • How to Create the IPSec Filter List for Terminal Services Communications
• How to Create and Enable the IPSec Policy to Secure Terminal Services Communications
• How to Ensure That Clients Respond to the Terminal Server's Requests for Security
• Troubleshooting
 

SUMMARY
You can use Windows 2000 Terminal Services to gain access to programs in a multiple-user Terminal server environment. Communications between the Terminal Services client computer and the server that has Terminal Services enabled can contain sensitive information; therefore, you may want to optimize security between the Terminal Services client and the Terminal server. This step-by-step article describes how to configure the Terminal server to require varying degrees of encryption by using the RC4 algorithm to secure Terminal Services communications.

Many organizations use standardized Internet Protocol security (IPSec) for network security. You can configure IPSec policies on Terminal servers to force all Terminal Services communications to be protected by IPSec.

This article assumes that you are configuring computers that are a part of a domain structure. If the computer is not part of a domain structure, you may also have to configure encryption and authentication services.

For additional information about troubleshooting IPSec, click the article number below to view the article in the Microsoft Knowledge Base:
257225 Basic IPSec Troubleshooting in Windows 2000
To enable IPSec protection for Terminal Services: 1. Create an IPSec filter list to match Terminal Services packets.
2. Create an IPSec policy to enforce IPSec protection, and then enable the policy.
3. Enable the Client (respond-only) policy on the Terminal Services clients.
back to the top
How to Create the IPSec Filter List for Terminal Services Communications
1. Click Start, point to Programs, point to Administrative Tools, and then click Local Security Policy.
2. Click to expand Security Settings, right-click IP Security Policies, and then click Manage IP filter lists and filter actions.
3. Click the Manage IP Filter Lists tab, and then click Add.
4. Type terminal services in the Name box, and then type for terminal services connections in the Description box.
5. Click to clear the Use Add Wizard check box, and then click Add .
6. Click the Addressing tab, click My IP Address in the Source address box, and then click Any IP Address in the Destination address box.

After you complete this step, the filter is applied to outbound packets.
7. Verify that the Mirrored check box is selected.

If this check box is selected, a packet filter is created to match inbound packets. All IPSec-secured communications must be protected in both directions; you cannot have unidirectional IPSec security.
8. Click the Protocol tab, click TCP in the Select a protocol type box, and then click From this port
9. Type 3389 in the From this port box, click To any port, and then click OK.  
10. Click Close, and then click Close.  
back to the top
How to Create and Enable IPSec Policy to Secure Terminal Services Communications
1. Start the Local Security Settings Microsoft Management Console (MMC), right-click IP Security Policies in the left pane, and then click Create IP Security Policy.  
2. After the IP Security Policy Wizard starts, click Next.
3. On the IP Security Policy Name page, type secure terminal services connection in the Name box, and then click Next.
4. Click to clear the Activate the default response rule check box, and then click Next.
5. On the Completing the IP Security Policy Wizard page, verify that the Edit properties check box is selected, and then click Finish.
6. Click the Rules tab, click to clear the Use Add Wizard check box, and then click Add.
7. Click the IP Filter List tab, and then click Terminal Services IP Filter List.
8. Click the Filter Action tab, and then click Require Security.
9. Click Apply, and then click OK.
10. Verify that the Terminal Services Filter List check box is selected, and then click Close.
11. Right-click the new policy, and then click Assign.
back to the top
How to Ensure That Clients Respond to the Terminal Server's Requests for Security
1. Click Start, point to Programs, point to the Administrative Tools, and then click Local Security Policy.
2. Click to expand Security Settings in the left pane, right-click the Client (respond only) policy, and then click Assign.
0
Sp0cky
Asked:
Sp0cky
  • 7
  • 6
  • 2
2 Solutions
 
Sp0ckyAuthor Commented:
In further reading I have found that in private networks, certificates or keys are used to PROVE 2 computers can trust each other to begin with.  This is done using kerberos and IKE.  After a trust relationship is established THEN nad ONLY THEN are the two computers able to establish the IPSEC communication.  Is this correct?  Anyone want to verify or elaborate?  Thanks.
0
 
Rich RumbleSecurity SamuraiCommented:
No, this is not correct, you can establish connections with a shared key(aka certificate) or a preshared key...
If you open the "default response rule" go to the authentication methods tab, and click Add you'll be able to specify the use of a pre-shared key or string.
http://support.microsoft.com/kb/240262
http://support.microsoft.com/?kbid=252735
http://www.jacco2.dds.nl/networking/win2000xp-freeswan.html (step 4)
-rich
0
 
Sp0ckyAuthor Commented:
My objective with Terminal Services was to require authentication and enable encryption.  Using the procedures above, I enabled IPSEC for terminal services without certs and the session is encrypted.  So this leads me back to my question though, "why create certs for IPSEC?"  Thx.  
0
Put Machine Learning to Work--Protect Your Clients

Machine learning means Smarter Cybersecurity™ Solutions.
As technology continues to advance, managing and analyzing massive data sets just can’t be accomplished by humans alone. It requires huge amounts of memory and storage, as well as the high-speed power of the cloud.

 
bboy77Commented:
They are a form of authentication that replaces the need for using the original IP source header as your authentication identifier during IKE key exchange negotiations.    How do you know or Authenticate the entity that is trying to establish an IPSec connection to you?  For example, I could send packets impersonating one of your clients or injecting packets in a man in the middle attack, without authentication you don't know where these packets are originating from.  Like richrumble mentioned, IKE CAN use a pre-shared keys as well public encryption key pairs or public key signatures.  But when using a pre-shared key, IKE uses the IPaddresses of the two parties as part of it's authentication mechanism.  

IPSec requires the use of certificates or FQDN or some other authentication form in a NAT environment during IKE negotiations.  The general implementation of IPSec uses the IP source address to authenticate and create a security association during IKE pre-shared key authentication.  As you probably know, during NAT, your NAT device will read the header of the IP address and "translate\convert" it by adding a pseudo-header with a new IP address.  Since the IP header is now changed your IPSec security gateway will reject the request because it doesn't recognize this new IP header address NAT has attached. So basically the IPSec can not perform authentication.  (there are also a few other problems created by NAT when using IPSec. Packet filtering firewall's also create problems on occaision since they are attempting to read the contents in the encrypted payload.  Personally I find it easier to just use a FQDN instead  of implementing certificates.

The whole field is a pretty interesting area . Microsoft and the UPnP forum are pushing hard for their form of NAT traversal. You might want to look up IPSec and NAT.  Of course you don't have any of these concerns if you are not behind a NAT device or some type of device that must inspect or alter the IPSec packet.  This is another reason people are pushing hard for IPv6.  With IPv6 you wouldn't need NAT or any of it's "workarounds" since the original packet isn't altered. RFC 3715 has some good info.
0
 
Rich RumbleSecurity SamuraiCommented:
All good info from bboy77, very well put. TerminalServices/RemoteDesktop by default is encrypted over the RDP protocol, the only disernable information from a TS/RD session is the username that is sent plain-text upon first signing into the server your TS'ing to. As far as I have ever seen, the username is all that you can obtain from an RD/TS session, and only right at the begining.

As eluded to by bboy77, certificates are generally purchased from a 3rd party such as verisign or thwate (there are many)
These cert makers are trusted CA's (certificate authorities) http://en.wikipedia.org/wiki/Certificate_authority
You must prove to the CA's your identity before they will issue a cert to/for you.Once your issued your cert, you can have others accept it to do httpS (ssl http) or to sign/encrypt traffic between hosts.

Now with a company VPN you can save yourself some money, and create certs yourself. If you tried to run an SSL site using these certs that are not from one of, or endorsed by one of the big CA's- the browser would (should)prompt you telling you that this cert did not come from a trusted CA... http://en.wikipedia.org/wiki/IPSEC

Also with reguard to IPSEC port filters, some people rely on them as a firewall, they are poor firewalls if you get more than a script kiddie knocking on them, or a script kiddie that knows if he binds his src port to port 88 or port 500 he will by-pass the ipsec filters.
http://support.microsoft.com/default.aspx?scid=kb;en-us;811832
http://support.microsoft.com/default.aspx?scid=kb;en-us;810207 (a step in the right direction)
-rich
0
 
Sp0ckyAuthor Commented:
"As far as I have ever seen, the username is all that you can obtain from an RD/TS session, and only right at the begining."

Meaning, this is pretty good encryption..or security for the Terminal Services session?

"They are a form of authentication that replaces the need for using the original IP source header as your authentication identifier during IKE key exchange negotiations.  "

Meaning without the certs or keys, I am open to a man in middle attack correct?  Also, is it that IPSEC will not work with not or just not be secure through nat?


0
 
Rich RumbleSecurity SamuraiCommented:
yes and yes and it works through nat, with no difference as far as i know/have seen.
-rich
0
 
bboy77Commented:
 I'm not quite sure what you mean by not using certificates or keys.  The IKE phases use keys for authentication to establish a security association in the first place, then it uses esp encryption and occaisionally AH if there is no NAT.

Sorry, I'm not as familiar with Microsoft's implementation of IPSec with terminal services. I was speaking more towards the need for certificates in IPSec communication. I do know that most of my collegues use CISCO or Netscreen devices to establish IPSec vpn tunnels. Only then do they use terminal services.  OpenSSH would be cheap way to SSH encrypt your terminal services session.  Might be slightly over the head of the average user, but I've set it up for clients who are loving it and learned it quick.
0
 
Rich RumbleSecurity SamuraiCommented:
M$'s IPSEC is pretty standard, it works well with openswan, and various others, again it follows the standards. It also allows tunnels to be created from pre-shared phrases or key's alone, no certificate is imported or selected, this isn't a devation from the standard RFC 3193, just not a common setup to have-
RFC 3129 is what windows tries to rely on mostly with it's IPSEC, BUT you can still do ipsec tunnels without kerberose on M$ ipsec
http://www.faqs.org/rfcs/rfc3129.html
In addition,
   the lack of a trusted third party (the lack of a trusted CA) requires the use of Diffie Hellman
   (DH) to establish a shared secret.  DH, unfortunately, is computationally quite expensive and prone to denial of service
   attacks.  IKE also relies on X.509 certificates to realize scalable authentication of peers.  Digital signatures are also
   computationally expensive and certificate based trust models are difficult to deployin practice.  While IKE does allow for
   pre-shared symmetric keys, key distribution is required between all peers -- an O(n^2) problem --
   which is problematic for large deployments.

Terminal service sessions are encrypted by default, but can be set to not encrypt sessions, this is set on the server.
-rich
0
 
Sp0ckyAuthor Commented:
Thank you for your expert responses.  I was tired last night when I responded.  I am going to study your responses more closely.  It's a little over my head so I have to go slower.

"Terminal service sessions are encrypted by default, but can be set to not encrypt sessions, this is set on the server."

Encrypted with what method?  Then why did I have to set it to require IPSEC on the server in my above instructions?  Thx.
0
 
Sp0ckyAuthor Commented:
I did not know what openswan is but apparently it is IPSEC for Linux.  Let's try to wrap this up with some final q/a and so I can give you guys your hard earned points.

"IPSec requires the use of certificates or FQDN or some other authentication form in a NAT environment during IKE negotiations."

Makes sense.  So why use anything OTHER than the M$ default implementation of IPSEC?  That's what I must have missed.  I think the answer is to (securely) establish an initial security association rather than just a clear text pword.  Am I getting yet, lol?:

"The IKE phases use keys for authentication to establish a security association in the first place, then it uses esp encryption and occaisionally AH if there is no NAT."


NEXT QUES:
"It also allows tunnels to be created from pre-shared phrases or key's alone, no certificate is imported or selected, this isn't a devation from the standard RFC 3193, just not a common setup to have-"

I thought the default IPSEC is essentially a tunnel?  Also what exactly is a "pre-shared key?"  Is it part of the default implementation I am using above?

I think we went a little beyond my initial question.  For the most part, it was a basic question:

"In further reading I have found that in private networks, certificates or keys are used to PROVE 2 computers can trust each other to begin with.  This is done using kerberos and IKE.  After a trust relationship is established THEN nad ONLY THEN are the two computers able to establish the IPSEC communication.  Is this correct?"

Rich answered:

" No, this is not correct, you can establish connections with a shared key(aka certificate) or a preshared key...
If you open the "default response rule" go to the authentication methods tab, and click Add you'll be able to specify the use of a pre-shared key or string."

But based on your answers to my question (focusing more on the CONCEPT rather than specific detail)  - you use kerberos or IKE as an added measure over and above the regular IPSEC to secure the initial communication this IS correct, right?




0
 
Rich RumbleSecurity SamuraiCommented:
TS is encrypted with M$ propriatary 56-bit encryption (in NT4.0 it's a 40bit) of the RDP protocol, the encryption can go up to 128, set that on the server.
This site has good doc's and links for more info
http://rdesktop.sourceforge.net/
http://www.windowsecurity.com/articles/Windows_Terminal_Services.html
TS/RD encryption is very good, I've not found a cracker for it, nor have I been able to crack a "sniffed" session... but it's better safe than sorry.

This is complicated... kerberos is used to authenticate ipsec communiucations, yet kerberos cannot be secured via ipsec- the two are mutually exclusive in this instance.
So kerb data is not encrypted over ipsec, but just about everything else is.

Also, you do not <i>have</i> to use kerb, as I indicated, you can "go to the authentication methods tab, and click Add you'll be able to specify the use of a pre-shared key or string."
and that string will serve as the "cert" if you will. Both point's must know of that string before comunication can be secured. So that phrase has to be entered in both locations before the tunnel is even turned on, that is "proof" to the client and server that these two are supposed to communicate, as they both knew the same secret phrase,
-rich
0
 
Sp0ckyAuthor Commented:
"TS is encrypted with M$ propriatary 56-bit encryption (in NT4.0 it's a 40bit) of the RDP protocol, the encryption can go up to 128, set that on the server."

OK.  The extra step I was doing must be needed to REQUIRE encryption.  It's not enabled to require it from the client by default.   ..but I will have to back track and re-read my article.

Ok, kerberos is used by default as part of the authentication process in TS IPSEC sessions.  Got it.

Ok, pre-shared key is extra measure of security for authentication and so is certs..based on your answer, I think I've got it.  Thanks much.  A tough concept that branches off widely.  
0
 
Rich RumbleSecurity SamuraiCommented:
TS and RD have nothing to do with ipsec.... ipsec is a tunneling protocol. TS/RD use a M$ algorythim to compress, and encrypt the RemoteDesktopProtocol
M$ RDP is based on previous ITU T.120 family of protocols. By default they (terminal service and remote desktop) are "self" encrypted. The amount of encryption is dictated by the server your TS'ing to, and the client must comply with that setting to even communicate properly.

http://www.windowsecurity.com/articles/Windows_Terminal_Services.html (there is a good doc on this page top left)
This article (below), just like the one in your question does seem to lead one to think that TS/RD is not protected in any way, when in fact they are- these are extra security measures to secure communications.
http://support.microsoft.com/kb/816521
-rich
0
 
Rich RumbleSecurity SamuraiCommented:
DOh! not that article this one
http://www.microsoft.com/windows2000/techinfo/howitworks/terminal/rdpfandp.asp
page 5 under the encryption heading:

Every version of RDP uses RSA Security’s RC4 cipher, a stream cipher designed to efficiently encrypt small amounts of varying size data. RC4 is designed for secure communications over networks, and is also used in protocols such as SSL, which encrypts traffic to and from secure Web sites.
In Windows 2000, administrators can choose to encrypt the data using a 56- or 128-bit key. Encryption is bi-directional except when using the ‘low’ security setting that only encrypts data from the client to the server (which protects sensitive information such as passwords). The default setting is “medium” which uses a 56-bit key to bi-directionally encrypt the data. 128-bit encryption can be enabled after installing the Windows 2000 High Encryption Pack.

So it's using RC4, it's not propriatary, may fault.
-rich
0

Featured Post

2017 Webroot Threat Report

MSPs: Get the facts you need to protect your clients.
The 2017 Webroot Threat Report provides a uniquely insightful global view into the analysis and discoveries made by the Webroot® Threat Intelligence Platform to provide insights on key trends and risks as seen by our users.

  • 7
  • 6
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now