ddh76
asked on
Secure remote access solution
We are a 65 user company running Windows XP, 2003 Servers and fairly standard network setup. We have been offering users a VPN solution thus far that is a little flaky to say the least. Some users use RDP once they have connected but OTHER users require that their Outlook on fat client is up to date and offline whenever they need it to be.
We are looking to standardise on the way in which we can provide remote access to our users. Citrix Secure Gateway is one way of securely providing this but doesn't combat the offline issue. An RDP solution won't combat the offline issue either.
What is the most secure way of providing 'public' access to an RDP Server if we have DMZ capabilities on our server? Can RDP traffic be encrypted? can we put the RDP Server on the DMZ and then route through NAT?
Any advice on this very welcome!
We are looking to standardise on the way in which we can provide remote access to our users. Citrix Secure Gateway is one way of securely providing this but doesn't combat the offline issue. An RDP solution won't combat the offline issue either.
What is the most secure way of providing 'public' access to an RDP Server if we have DMZ capabilities on our server? Can RDP traffic be encrypted? can we put the RDP Server on the DMZ and then route through NAT?
Any advice on this very welcome!
I always prefer VPN over opening up RDP to the world. RDP has had a few bugs, though I think they've been patched by now. You should be able to run the outlook client across the VPN as well. You said your current VPN has been flaky. What VPN is it? Cisco and watchgaurd make some stable VPN clients and end points.
ASKER
Interestingly enough, it is a Watchguard firebox 750e and the MUVPN client seems to disconnect a lot. Yes, I have the latest version etc and yes I have spoken to Watchguard about it.
Is RDP traffic encrypted? Or can it be?
Is RDP traffic encrypted? Or can it be?
RDP is encrypted
And quite good I may add - if you use the latest implementations. The only two vulnerabilities discovered are a possible DOS (denial of service) attack (resolved) and a very hypothetical MITM (man in the middle) attack.
If you want to be very safe then you can add a VPN.
Using your DMZ is useless as there is not something like an RDP forwarder or proxy. So you would put your production machine in the DMZ and then have to open your domain to the DMZ. Not a recommended configuration.
Also, you are talking about a closed set of user. Not something public.
So, for you requirements RDP + Outlook, VPN is the best option. See my answer to your other question regarding PPTP. Watchguard also has it's own PPTP implementation on the box.
J.
And quite good I may add - if you use the latest implementations. The only two vulnerabilities discovered are a possible DOS (denial of service) attack (resolved) and a very hypothetical MITM (man in the middle) attack.
If you want to be very safe then you can add a VPN.
Using your DMZ is useless as there is not something like an RDP forwarder or proxy. So you would put your production machine in the DMZ and then have to open your domain to the DMZ. Not a recommended configuration.
Also, you are talking about a closed set of user. Not something public.
So, for you requirements RDP + Outlook, VPN is the best option. See my answer to your other question regarding PPTP. Watchguard also has it's own PPTP implementation on the box.
J.
ASKER
Interesting. So RDP is encrypted and it will just sit on the Internet essentially? So potential hacker has to 'discover' the DNS entry for it (if there is one) and then know username/password of Windows user? Is there no other way of making it more secure? (Without RSA tokens or EAP?)
Wow, I think you are assuming some things. Bare with me:
A DNS entry is not necessary to find your machine. Just a port scan. To get in: a known username/password.
So you'll need a strong password policy + set up terminal services as secure as possible. Yes it can be set up in an insecure way with e.g. to low encryption, open to brute force attacks, ...
Also, you have to open port 3389 to the world AND keep your system patched. I can not predict when eventually someone will find an exploitable vulnerability on RDP. Because none are known now does not mean this will not change. You have to wheigh the risks.
To make it more secure, like I said: add VPN to the flavouring. Or have a look at the Citrix access control products.
Or wait for Longhorn: Microsoft is adding a Terminal Service Gateway (a head-end gateway server that can provide SSL encryption for back-end Terminal Servers).
J.
A DNS entry is not necessary to find your machine. Just a port scan. To get in: a known username/password.
So you'll need a strong password policy + set up terminal services as secure as possible. Yes it can be set up in an insecure way with e.g. to low encryption, open to brute force attacks, ...
Also, you have to open port 3389 to the world AND keep your system patched. I can not predict when eventually someone will find an exploitable vulnerability on RDP. Because none are known now does not mean this will not change. You have to wheigh the risks.
To make it more secure, like I said: add VPN to the flavouring. Or have a look at the Citrix access control products.
Or wait for Longhorn: Microsoft is adding a Terminal Service Gateway (a head-end gateway server that can provide SSL encryption for back-end Terminal Servers).
J.
ASKER
No, that's fine. I am trying to get my head round this. As you describe it, this seems a little bit dodgy. I was only saying that potential nasty person might find the DNS Entry easier than an IP address, that's all. i.e. RDPSERVER.DOMAIN.COM!! Don't worry about that. As for the port scan results, this seems still too easy to hack. Even though complex passwords are good, they are generally words with numbers replaces where letters should be aren't they? It just doesn't seem that secure at all.
Do you have any experience with the Citrix secure gateway product?
Do you have any experience with the Citrix secure gateway product?
The safety on a password largely depends on the protocal used.
For the moment a safe password (not crackable in a reasonable amount of time, e.g. > 1000 years) for RDP I would considering something like:
- min 8 chars
- caps and lower chars used
- min 1 numerical and a special character (dot, hash, at, ...)
- does not contain large part of the login name
Nope, no recent experience with Citrix.
J.
For the moment a safe password (not crackable in a reasonable amount of time, e.g. > 1000 years) for RDP I would considering something like:
- min 8 chars
- caps and lower chars used
- min 1 numerical and a special character (dot, hash, at, ...)
- does not contain large part of the login name
Nope, no recent experience with Citrix.
J.
ASKER
Do you know how the encryption actually works on RDP?
Yes I do. There are 3 levels (from least to most secure)
1: Low = RC4 56bit.
2: High = RC4 128bit.
3: Fips Compliant = 3DES 128 bit in CBC mode (needs min RDP client version 5.2), FIPS 140-1 compliant
There is also something called 'Compatible with client' but this just uses the highest available from the above.
Since 2003 server SP1 you can also use SSL (TLS 1.0) with level high & FIPS to be used for server authentication and encryption. The server and client needs to be correctly configured for this (not out of the box).
J.
1: Low = RC4 56bit.
2: High = RC4 128bit.
3: Fips Compliant = 3DES 128 bit in CBC mode (needs min RDP client version 5.2), FIPS 140-1 compliant
There is also something called 'Compatible with client' but this just uses the highest available from the above.
Since 2003 server SP1 you can also use SSL (TLS 1.0) with level high & FIPS to be used for server authentication and encryption. The server and client needs to be correctly configured for this (not out of the box).
J.
ASKER
So how do I find out which encryption I am using? The Term Svcs is running Windows 2003 SP1. Client RDP version is normal Windows XP.
Fire up the Terminal Services Manager, double click the server, click on a connected user. In the right pane click the information tab. The encryption levels is there among a lot of other info.
J.
J.
If your current VPN hardware is flaky, keep in mind Windows 2003 Server provides secure PPTP and L2TP (more secure, but requires a server cert) VPN connections. If you have Active Directory running then the microsoft VPN server can go there for authentication. Then you can tunnel the 3389 in your VPN.
ASKER
How would you set that up securely on a DMZ? What would you have Internet facing? Would it be the VPN Server sat in the DMZ?
ASKER
Also, my encryption level on TS says "Client compatible". What does that mean?
The endpoint of the VPN server has to be in your private network. What else would be the point if having the endpoint in the DMZ? Nowhere to go from there.
Your firewall needs to be setup to forward the VPN ports to ONLY the VPN server. So the firewall is Internet facing.
-> Internet -> Firewall -> VPN server.
Or, like I already mentioned, the firewall or UTM can also be the VPN server.
The encryption level says "Client Compatible" because that is what is configured in the Terminal Services Manager in the RDP settings.
J.
Your firewall needs to be setup to forward the VPN ports to ONLY the VPN server. So the firewall is Internet facing.
-> Internet -> Firewall -> VPN server.
Or, like I already mentioned, the firewall or UTM can also be the VPN server.
The encryption level says "Client Compatible" because that is what is configured in the Terminal Services Manager in the RDP settings.
J.
ASKER
Ok so if I wanted to provide secure (L2TP and PPTP) Windows 2003 VPN and utilise the DMZ on my firewall, what would I have to do?
You have now lost me...
Why would you want to use the DMZ?
J.
Why would you want to use the DMZ?
J.
ASKER
I thought that the DMZ would add an extra layer of security though? Can you not have VPN Server in the DMZ and that then allows connections in to the LAN only once you have authenticated?
No, a DMZ is used to host servers & services separated from your internal network.
With a VPN you want to tunnel into your internal network.
The thunnel - and access to your LAN - is only set up after the VPN system authenticated the session.
So a DMZ adds nothing to a VPN.
J.
With a VPN you want to tunnel into your internal network.
The thunnel - and access to your LAN - is only set up after the VPN system authenticated the session.
So a DMZ adds nothing to a VPN.
J.
ASKER
I see - that makes sense I suppose. Sorry about this!
So, in order to implement Windows 2003 Server VPN with L2TP and PPTP, you simply open up the right port on your firewall and have the VPN Server sit on your internal network then?
So, in order to implement Windows 2003 Server VPN with L2TP and PPTP, you simply open up the right port on your firewall and have the VPN Server sit on your internal network then?
ASKER
Also, are you saying that you should "never" connect services/servers that reside in a DMZ to the Corporate LAN?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Do you know how IAS and RADIUS fits in to this?
IAS? That's the Oracle web server in their 3-tier application. Don't see how this fits in RDP & VPN.
Radius is an authentication, authorization & accounting service. Some VPN's can use it. RDP can not. RDP uses kerberos.
BTW, it common courtesy on EE to start a new topic for a new question.
J.
Radius is an authentication, authorization & accounting service. Some VPN's can use it. RDP can not. RDP uses kerberos.
BTW, it common courtesy on EE to start a new topic for a new question.
J.
ASKER
ok, thanks for the etiquette tip. I will start a new question.