Sp0cky
asked on
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.
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.
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
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
ASKER
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.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
All good info from bboy77, very well put. TerminalServices/RemoteDes
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
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
ASKER
"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?
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?
yes and yes and it works through nat, with no difference as far as i know/have seen.
-rich
-rich
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.
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.
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
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
ASKER
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.
"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.
ASKER
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?
"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?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
"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.
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.
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
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
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
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
ASKER