Thank you. The possible dictionary attack is probably the single point of failure. I will setup Remote Destop thru
VPN and hope its performance wont be slow.
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.
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.
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.
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.
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.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.