Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Windows Remote Desktop - is it secure?
- Thread starter vostok1
- Start date
Triplejolt
IS-IT--Management
Use VPN to establish an encrypted connection. Then allow Remote Desktop through to your Windows 2003 server
A firm beleiver of "Keep it Simple" philosophy
Cheers
/T
A firm beleiver of "Keep it Simple" philosophy
Cheers
/T
- Thread starter
- #4
Triplejolt
IS-IT--Management
I use it all the time, and it's fairly good. Depending on your bandwidth ofcourse, it shouldn't have too much overhead.
A firm beleiver of "Keep it Simple" philosophy
Cheers
/T
A firm beleiver of "Keep it Simple" philosophy
Cheers
/T
- Thread starter
- #6
Thanks again.
Lets say several business partners use PCAnywhere to access servers inside a company to perform maintenance of their databases.
Again, this required certain configuration in PIX. Create group of IP addresses and rules,
apply ACL, and set static maps.
PCAnywhere is slow and, I assume, vulnerable to a dictionary attack.
I was thinking about the best next step here.
Lets say several business partners use PCAnywhere to access servers inside a company to perform maintenance of their databases.
Again, this required certain configuration in PIX. Create group of IP addresses and rules,
apply ACL, and set static maps.
PCAnywhere is slow and, I assume, vulnerable to a dictionary attack.
I was thinking about the best next step here.
bwilliam13
IS-IT--Management
The better option would be to use Terminal Services on the server side with W2K3 SP1 installed, then force the user to provide either smart card and/or a FIPS-compliant login (digital certificate of some kind). Quite frankly, I think this approach is MORE secure than a VPN, since most VPN's still rely on a username/password combo to connect. It's easier to find out a username/password combo than it is to physically possess a smart card and know the PIN. Nowadays, you can set up smart card access to your infrastructure for about $35 per user. It probably costs the same or more to maintain a separate VPN infrastructure.
With Terminal Services in W2K3 SP1, you can completely turn off logging into a terminal server with username/password. So, the dictionary attack thing gets negated. What you run into then are issues based on PKI, which most *hackers* won't bother messing with because 99% of the rest of the world is more vulnerable than you are.
With Terminal Services in W2K3 SP1, you can completely turn off logging into a terminal server with username/password. So, the dictionary attack thing gets negated. What you run into then are issues based on PKI, which most *hackers* won't bother messing with because 99% of the rest of the world is more vulnerable than you are.
VPNs also use smart cards, if desired. Pix, specifically, supports several authentication methods. Also, the hacker would have to know the vpngroup in addition to the username & password.
As long as there's a username/password combination used, it'll be subject to dictionary attacks. Using a VPN has the benefit (and hassle) of forcing two username/passwords rather than one, and requires platform-specific software which I imagine most hackers also won't bother with. Especially if you use an IP address and don't have a DNS name set up like "cisco-pix-vpn.company.com"...
Finally, if you cut of a customer's VPN access, they can't even touch your network or servers. I'd tend to agree with the VPN solution.
As long as there's a username/password combination used, it'll be subject to dictionary attacks. Using a VPN has the benefit (and hassle) of forcing two username/passwords rather than one, and requires platform-specific software which I imagine most hackers also won't bother with. Especially if you use an IP address and don't have a DNS name set up like "cisco-pix-vpn.company.com"...
Finally, if you cut of a customer's VPN access, they can't even touch your network or servers. I'd tend to agree with the VPN solution.
bwilliam13
IS-IT--Management
Yup. I guess what I'm getting at, is if your VPN (which is only a tunnel) is using the same auth mechanism as the server(s) you're connecting to, what's the difference?
PIX with Aladdin smartcard is what I use. However, I don't see the point in going to all that trouble in a lot of cases when the PIX is just authenticating against the same backend as the servers behind it. So why not access the same auth mechanism straight to the server? It's not a security or risk issue at that point...it's how many IP addresses you have vs how many servers you want to access.
PIX with Aladdin smartcard is what I use. However, I don't see the point in going to all that trouble in a lot of cases when the PIX is just authenticating against the same backend as the servers behind it. So why not access the same auth mechanism straight to the server? It's not a security or risk issue at that point...it's how many IP addresses you have vs how many servers you want to access.
- Thread starter
- #10
- Thread starter
- #11
I like this solution:
I'm surprised at the talk of dictionary attacks.
Dictionary attacks will be ineffective, assuming you have a network policy that locks out user accounts after a certain number of incorrect logins (which is the default). You're offering a dictionary hacker, what, three attempts before the domain account is logged out? Do you not notice multiple domain accounts being locked out all of a sudden?
Secondly, if you authenticate using a vpn on the pix, you can at least log where attempted attacks come from, and then block those ip addresses at your firewall (assuming you've set up logging on your PIX, which you have done, haven't you?). If you simply nat RDP traffic through the firewall to auth against the server, you'll see auth failures in the event logs, but will you see what ip address they come from? Don't believe you will ... so how do you stop external users trying to hack the terminal server?
Thirdly, if you just nat the traffic through, you're relying upon Microsoft's implementation of RDP being secure, and no exploits ever being discovered for it. There previously have been RDP exploits. If more come to light, a hacker owns your server. If not, they first need to hack their way onto an IpSec vpn on your pix before they can try the RDP exploit. Which is more secure? Bear in mind you can create an ipsec vpn that only allows RDP traffic to that particular server.
Fourthly, if you have a perimiter firewall with an available security feature, USE IT. Don't open holes through your firewall, and rely on the security of other boxes behind it. Where's the logic in that?
Personally i'd rather rely on Cisco's implementation of security than Microsoft's, but that's a judgement call. Your mileage may vary.
CCNA, CCSA, MCSE, Cisco Firewall specialist, VPN specialist, wannabe CCSP
Dictionary attacks will be ineffective, assuming you have a network policy that locks out user accounts after a certain number of incorrect logins (which is the default). You're offering a dictionary hacker, what, three attempts before the domain account is logged out? Do you not notice multiple domain accounts being locked out all of a sudden?
Secondly, if you authenticate using a vpn on the pix, you can at least log where attempted attacks come from, and then block those ip addresses at your firewall (assuming you've set up logging on your PIX, which you have done, haven't you?). If you simply nat RDP traffic through the firewall to auth against the server, you'll see auth failures in the event logs, but will you see what ip address they come from? Don't believe you will ... so how do you stop external users trying to hack the terminal server?
Thirdly, if you just nat the traffic through, you're relying upon Microsoft's implementation of RDP being secure, and no exploits ever being discovered for it. There previously have been RDP exploits. If more come to light, a hacker owns your server. If not, they first need to hack their way onto an IpSec vpn on your pix before they can try the RDP exploit. Which is more secure? Bear in mind you can create an ipsec vpn that only allows RDP traffic to that particular server.
Fourthly, if you have a perimiter firewall with an available security feature, USE IT. Don't open holes through your firewall, and rely on the security of other boxes behind it. Where's the logic in that?
Personally i'd rather rely on Cisco's implementation of security than Microsoft's, but that's a judgement call. Your mileage may vary.
CCNA, CCSA, MCSE, Cisco Firewall specialist, VPN specialist, wannabe CCSP
- Thread starter
- #13
Thanks.
I have a policy that locks windows accounts after seven logins.
The problem is that our current remote access scheme uses PCAnywhere (I didn’t implement it, just configured it in PIX upon my manager's request when replacing firewalls ). To give an example, a database company support goes thru the firewall thru static maps and authenticates by PCA at the machine (some of the programmers do not have static IPs, so I can’t lock the allowed IP addresses and, by this means, can’t have the PIX to verify the outside IP address).
There is about 15 PCA translations in the firewall
(access-list ACLIN permit tcp any object-group PCAHOSTS object-group PCAPORTS ), and I’m about to change the scheme and have been thinking about the most appropriate way to do so.
I have a policy that locks windows accounts after seven logins.
The problem is that our current remote access scheme uses PCAnywhere (I didn’t implement it, just configured it in PIX upon my manager's request when replacing firewalls ). To give an example, a database company support goes thru the firewall thru static maps and authenticates by PCA at the machine (some of the programmers do not have static IPs, so I can’t lock the allowed IP addresses and, by this means, can’t have the PIX to verify the outside IP address).
There is about 15 PCA translations in the firewall
(access-list ACLIN permit tcp any object-group PCAHOSTS object-group PCAPORTS ), and I’m about to change the scheme and have been thinking about the most appropriate way to do so.
- Thread starter
- #14
- Status
