cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1006
Views
0
Helpful
6
Replies

security concerns with telnet through VPN tunnel

bberry
Level 1
Level 1

I have a group that is requesting thrid party access through a VPN tunnel to a couple servers. I have requested they use somethig more than simple telnet as it is not secure. The group is saying that since the tunnel is secure why should they use anything else. Anyone have any references to documentation to help me explaine my case.

6 Replies 6

acomiskey
Level 10
Level 10

I would just explain that it would be encrypted up to the vpn endpoint, but not encrypted after that (between your firewall and the servers for example).

mhellman
Level 7
Level 7

In many cases there is very little involved in moving to SSH. Most unix servers already have SSH and there are free clients available. For Windows there is RDP, or if you prefer a CLI...Cygwin.

The question should be, why use telnet when there are easy to implement alternatives?

Jon Marshall
Hall of Fame
Hall of Fame

Hi

Agree with what Adam says about it only being encrypted within the tunnnel so it once it comes out of the tunnel it is readable with clear text passwords etc.

However depending on your security setup this may be what you want.

SSH is a good solution but generally not great if you have IDS/IPS systems as the traffic is encrypted so all sort of nasty things could be sent down this channel and your IDS/IPS is oblivious.

It depends on what you think telnet opens you up to. If you are concerned with someone at the third party getting access to the cleartext to read the passwords etc then in reality this makes very little difference as there is nothing stopping them sharing the password with SSH. The point is you just don't know and if you are prepared to give them access to your servers you must have a certain level of trust in them.

If you are concerned about internal users getting access to these details then you should be firewalling off these servers to only allow the people you want to get access.

Cases where i can think of where you could argue against telnet

1) The third party network is hacked and traffic is intercepted. If they use ssh the usernames/passwords will still be encrypted whereas with telnet they won't.

2) IPSEC tunnels generally terminate at firewalls at either end. Depending on your security topology you may have cleartext telnet traffic in the DMZ which could be vulnerable. You can alleviate this to some extent by segregatiing your vpn tunnel traffic onto it's own DMZ.

Generally speaking i would use ssh over telnet internally and in many instances it is preferable but you do need to take into account the rest of your security infrastructure.

HTH

Jon

The tunnel termination is part of the concern. I have been told there will be about 10 programmers outside the U..S. that will be working on the project. IF they are running the client, the tunnel would be between their PCs and our contentrator here. The concentrator in turn is connected to the core with the next hop being the server switch. Terminating on say a firewall is a different matter. It is these types of questions I posed to the programming group yesterday.

I have always been told that telnet is ok within the LAN but from a best practice SSH or the like should be used. For traffic traversing the internet something like telnet should never be used. It is clear text and one does not have any control once it has left the firewall.

I am trying to improve on the security and practices they have started here. There is starting to be more and more vendor access allowed for monitoring and maintaining outside systems. My concern is that the mind set of "we use VPN we are protected" is a little lax. Giving vendors the VPN client and saying have at it is just seems too easy. I know there has to be a certail level of trust with the vendors but there still needs to be controls in place. What about someone using this as a jumping off point for nosing around the rest of the network?

A question someone brought up was what control do we have once they are connected to the server? Can they not go from there to anywhere else they want? Is there more that I could do from a network standoint other than simply give them a tunnel limited to a few IP addresses?

Am I just being paranoid? Should I a more comfortable feeling in a simple VPN tunnel limited to only specific IP addresses?

Brent

"I have always been told that telnet is ok within the LAN but from a best practice SSH or the like should be used"

there is not one-size-fits-all best practice. This should be driven by policy, but in general I would agree that SSH is now best practice. It's not always practical however;-)

"My concern is that the mind set of "we use VPN we are protected" is a little lax"

In some situations, a VPN doesn't protect you from anything other than eavesdropping...and even then not always end-to-end, as is the case with a site-to-site.

IMHO, one of the biggest risk with a user VPN solution is a compromised machine (outside of direct malicious behavior by the vendor of course). In this attack vector, ssh may not help.

Are you using 2-factor authentication for the VPN? Is split-tunneling enabled? Does the VPN enforce minimum client requirements (personal firewall, antivirus, patch-level, etc)?

Even a top-of-the-line user VPN with 2-factor auth and split-tunneling disabled (only access to local subnet allowed) does not provide complete protection.

Hi Brent

No, i don't think you are being paranoid. In fact i think you've hit the nail on the head when you talk about what control's you have once the remote user is connected.

Securely bringing them across the Internet is not the issue. Use ssh, use IPSEC, they will both secure the traffic. I agree that just because it is a VPN does not mean it is completely safe, far from it. A virus on a VPN client that is allowed access to windows file sharing for example could create no end of problems.

And yes, once they have access what is to stop them nosing around the rest of your network. We have similiar issues and one way we deal with this is to firewall internally any servers 3rd party companies access so if the server is compromised they are restricted in what they can do.

The problem with all of this is that if you are going to allow 3rd parties into your network there will always be a risk. The best you can do is secure the servers as much as possible, monitor the network and monitor server logs.

I'm not advocating complete trust in vendors but realistically once you let these parties in you are, no matter how vigiliant, relying to some extent on the intergrity of your 3rd party.

Jon

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: