TS over the internet - directly attach, or require a VPN?

[William Fields]

Hello.

I have a customer who is having all kinds of problems w/ their current VPN
connection. They're wondering if it would be acceptable to drop using the
VPN altogether and just open the necessary port(s) on their firewall to
allow Terminal Server connections. They do not need LAN access over the
internet, just terminal server connections.

My initial reaction was "you always use a VPN, that's the secure way of
doing things", but since the TS client uses an encrypted connection, doesn't
that generally give enough protection against sniffing?

Comments? Obviously, I'm not a security expert...

Thanks.

--
William Fields
MCSD - Microsoft Visual FoxPro
US Bankruptcy Court
Phoenix, AZ

".dll hell - .rpm hell - whatever.
The grass is always greener"

 

[Leythos]

Hello.

I have a customer who is having all kinds of problems w/ their current VPN
connection. They're wondering if it would be acceptable to drop using the
VPN altogether and just open the necessary port(s) on their firewall to
allow Terminal Server connections. They do not need LAN access over the
internet, just terminal server connections.

My initial reaction was "you always use a VPN, that's the secure way of
doing things", but since the TS client uses an encrypted connection, doesn't
that generally give enough protection against sniffing?

Comments? Obviously, I'm not a security expert...

If you TRUST MICROSOFT to not have ANY holes in Remote Desktop, if you
trust Microsoft to not have any unknown exploits, if you don't mind
everyone and their brother being able to attempt a RD connection to your
server, then it's fine to expose it.

As a matter of security, we install a Firewall that also acts as a VPN
endpoint and then only create accounts for Users that require VPN
access, and don't integrate the Firewall with the AD structure - they
get one user/password for the firewall and it's not the same as their
domain users/password. Once they VPN into the network, the firewall rule
for their firewall user, is permitted only TCP3389 to a single IP
(either the Terminal Server or their desktop in the office). We never
expose the LAN directly.

 

[Jeff Pitsch]

I agree. they've opened a hole directly into their internal network. could
they make a hackers job any easier? Most times they have to go through a
firewall first but not with this company.

Jeff Pitsch
http://www.sbcgatekeeper.com
Your Terminal Services Security Website

 

[Steven L Umbach]

While some do use direct connection I prefer through a VPN particularly if
you can use l2tp which can require computer certificates so that computers
must authenticate before user credentials are even tried with certificates
from trusted Certificate Authorities. VPN also allows you to use Remote
Access Policies to further secure the VPN connection and decide what traffic
is allowed into the network with input/output filters. If direct connection
is used you can greatly reduce the risk by configuring the firewall to allow
connections to the port used for RDP [3389 TCP is default] from only
specific IP addresses which may not be possible if users roam or do not have
a static IP address. Either way make sure that users are forced to use
strong passwords. --- Steve

 

[Sooner Al [MVP]]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

In addition, for home users I both use and recommend RDP through a Secure
Shell (SSH) tunnel for added security. Plus you can access multiple RDP
hosts quite easily through the tunnel. Here is one way to do all of that...

http://theillustratednetwork.mvps.org/Ssh/RemoteDesktopSSH.html

- --

Al Jarvi (MS-MVP Windows Networking)

Please post *ALL* questions and replies to the news group for the mutual
benefit of all of us...
The MS-MVP Program - http://mvp.support.microsoft.com
This posting is provided "AS IS" with no warranties, and confers no
rights...

-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.3 (Build 2932) - not licensed for commercial use:
www.pgp.com

iQEVAwUBQ6iQaRU2gKNumcJAAQii9wf/cMKjhprR5iswrS7gshhdKbHCbI/DJO2c
d/q4A6gbQyNt10Ko1AYBooAmLxHuMR1KKLi0h+bRK2PMmSt0xONpDX0utP4V5M+5
1hHF3uuh6oiHcvwCSX2dphzO3tUaANal5yJabWd1p0SP4Z6NIZeJ0f9QduCJE+D9
H1g+sKDtiYYXHm5eewSOVBNxw/M1VDD3nonPax8bhoX6qD6Rlo06ar7Al1WJ9EhD
qxJJsDw165DDdJDn2nDAKLK9SlyAXbY+VI5E6DvYPNbxauck/+N4n5iTP7qomKMM
vG4ZbuX5un4h7YBzvZjS9huV+1emn8400i9GQnEftw6w5wCwOijX5Q==
=jFxc
-----END PGP SIGNATURE-----

 

[kiln]

I'm totally new to this and so am liable to get confused about the
issues, but the OP did state that they were *considering* dropping the
VPN part of their setup, which includes a firewall. So they haven't
opened up anything (because they haven't changed their current
firewall/vpn config) and even if they did, they'd still have the
firewall in place.

As I said I'm a newbie to the topic at hand, so I'm even not sure that
what you said doesn't match the OP's question. I've read many posts by
you (Jeff) where the primary message seems to be "don't ever expose your
TS/LAN directly on the internet". I often can't tell exactly what you
mean by that; and this response of yours makes it even more confusing.
What exactly do you consider a safe TS config for use on the internet? I
really want to know. They only direct exposure I have is via TS behind a
cisco firewall that is also a vpn endpoint, with all clinet IP addresses
known. I am hoping that there is a safe way to deploy TS on the internet
that is less rigorous than that, but maybe there isn't.

I agree. they've opened a hole directly into their internal network. could
they make a hackers job any easier? Most times they have to go through a
firewall first but not with this company.

Jeff Pitsch
http://www.sbcgatekeeper.com
Your Terminal Services Security Website

 

[Leythos]

As I said I'm a newbie to the topic at hand, so I'm even not sure that
what you said doesn't match the OP's question. I've read many posts by
you (Jeff) where the primary message seems to be "don't ever expose your
TS/LAN directly on the internet". I often can't tell exactly what you
mean by that; and this response of yours makes it even more confusing.
What exactly do you consider a safe TS config for use on the internet?

Any user outside of the OFFICE should FIRST connect via VPN and then
access the company resources - simple answer.

What this means is that no matter where you are, you need to VPN into
the office and then through the VPN tunnel you would open a Remote
Desktop session to the Terminal Server (still inside the company
network). This means that the ONLY exposure is through the VPN ports to
the VPN device in the office.

I personally never terminate the VPN's at the Server, I terminate them
at the Firewall Appliance and then have RULES that limit VPN users to
specific ports/IP in the company.

 

[kiln]

Thanks for that response. What if the TS box is a dedicated unit at a
web host? IE, it's not really on a LAN, but is behind the web host's
firewall. I suppose that the unit could be considered to be on the web
hosts LAN, but it's not a regular corporate office LAN.

I think essentially you're saying that unless I am willing to have some
idiot rooting around on the TS box at will, and any lan it's connected
to, the formula should include TS properly configured, a firewall, and
vpn access. Is that right?

I'm not a network person so I don't have a lot of exposure. What's
interesting about this is that at the end of the day, a ts setup as
you've outlined would seem to be more secure than most websites that
deal with important matters (etrade, online banking etc), even if they
use https etc. No public websites use vpn/ip addresses. So it makes me
wonder, in my case, since there is no corporate lan at risk, is the vpn
needed? The server would contain data that is less sensitive than an
online bank.

 

[Leythos]

I'm not a network person so I don't have a lot of exposure. What's
interesting about this is that at the end of the day, a ts setup as
you've outlined would seem to be more secure than most websites that
deal with important matters (etrade, online banking etc), even if they
use https etc. No public websites use vpn/ip addresses. So it makes me
wonder, in my case, since there is no corporate lan at risk, is the vpn
needed? The server would contain data that is less sensitive than an
online bank.

Ask yourself this - does your connection, firewall/vpn or not, have any
undisclosed or unknown holes that might allow the public to access some
part of the solution that you don't want them to access?

If you can not answer the question with a NO and feel 100% sure that
it's true, then you need to look at your exposure risk - what if someone
gets into the system and has complete access?

Why would you host a TS box at another location and not provide any
services?

 

[kiln]

Your comments confuse me, and they are in the vein of other comments
here that don't make sense to me. I don't think any "connection,
firewall/vpn or not", is completley safe from penetration. Maybe there
are some websites etc that are completely and utterly invulnerable to
attack but I doubt it, as new exploits are always coming to light. Yet
the risk/benefit ratio must be acceptable, else half of the internet
would go away.

I don't understand why, as far as I can tell, you and others think TS on
the internet would only be acceptible if it was invulnerable to
penetration? What makes it different from any web server? That's why I
brought up etrade and online banks etc. There must be something behind
what you're saying but I can't figure it out. It sounds like you only
recommend using TS on internal LANS, unless it presents only anonymous
and uninteresting data?

You also said "Why would you host a TS box at another location and not
provide any services?" I don't understand that either. I think you are
referring to my statement than the ts box I'm talking about would not be
connected to an internal lan, it's be at an external web host's site.
That doesn't mean it does not provide any services? Right???

 

[Jeff Pitsch]

Most companies do not host their webservers from their internal network.
This is not a hard concept to grasp. Your wanting to provide a direct line
to your internal network. Companies do not do that (typically). It is a
very bad security measure. Do you seriously not see the implications in
that? Do you not understand that their are things called DMZ's where
webservers reside? Nothing is invulnerable but your going out of your way
to make it easier for someone to get to your internal network. Why woul
dyou do that? A solution even as simple as 2xLoadbalancer is still better
than what your suggesting.

Jeff Pitsch
http://www.sbcgatekeeper.com
Your Terminal Services Security Website

 

[Leythos]

Your comments confuse me, and they are in the vein of other comments
here that don't make sense to me.

I don't think any "connection,
firewall/vpn or not", is completley safe from penetration.

Let's start here: You are correct, no exposed connection is 100% safe
from penetration - that's whey we use MULTIPLE forms of authentication
and rules to LIMIT exposure.

Maybe there
are some websites etc that are completely and utterly invulnerable to
attack but I doubt it, as new exploits are always coming to light. Yet
the risk/benefit ratio must be acceptable, else half of the internet
would go away.

In many cases, if you have a proper security method, some/many exploits
are meaningless - as an example, we had Fortune 500 companies with
public sites running on IIS 4 and 5 for years, unpatched, without a
single compromise, due to the methods we implemented. During that same
time, there were uncountable sites compromised because the site
admins/network admins didn't understand protection/security methods and
exposure.

I don't understand why, as far as I can tell, you and others think TS on
the internet would only be acceptible if it was invulnerable to
penetration?

It's not just TS, it's ANY server that runs on a Windows Platform (and
many Linux platforms, and HPUX)....

When it comes to exposed Microsoft boxes, in 20+ years of working with
computers/networks, I've never had a compromised system under my
management. I know the limitations of Windows, and I learned long ago,
and this is important, ONLY EXPOSE WHAT MUST BE EXPOSED.

In this case, your Terminal Server, you have proven methods that don't
mean you expose TS to the public - it's just plain lazy to do it.

What makes it different from any web server?

It's a different service, something that is based on a new (new, meaning
in the last few years) method that Microsoft has implemented - and it's
not proven as far as I'm concerned. Ask yourself what happens if someone
with Admin access permits user X to have RD access to the server? What
if the web site is cracked and they add users with RD permission?

Website exploits are common, but they are easy to protect against as
most firewalls and IDS tools already look for them - I don't see any RD
Proxy services being implemented in Firewalls....

That's why I
brought up etrade and online banks etc. There must be something behind
what you're saying but I can't figure it out. It sounds like you only
recommend using TS on internal LANS, unless it presents only anonymous
and uninteresting data?

ETrade does not expose their servers like you want - they don't allow
users to TS into them.

Windows TS should only be exposed on the LAN or through a VPN of some
type. That's what I'm saying.

You also said "Why would you host a TS box at another location and not
provide any services?" I don't understand that either. I think you are
referring to my statement than the ts box I'm talking about would not be
connected to an internal lan, it's be at an external web host's site.
That doesn't mean it does not provide any services? Right???

If you have a box, and allow TS connections, what other connections do
you allow to it from the public?

Are you using this box as a cheap Application Server and hosting apps
for customers?

 

[kiln]

I want to provide a direct line into my LAN? How do you derive that? Or
the OP? He specifically said they don't need LAN access.

My original comments to you were an expression of puzzlement that you
basically trashed the OP for asking he was right in thinking that the
vpn part of a client's current setup should be maintained. I'm not
really sure if you're reading the posts carefully; the OP was resisting
a client's suggestion, checking it out. You responded like the OP had
already flung a LAN wide open to the internet. There is a major
disconnect between what the OP said and what you responded to. You may
know a lot about TS etc, but it doesn't mean that anyone asking
questions here deserves to have sand kicked in their face.

 

[kiln]

Hi thanks for taking the time to write all of that, it's very
educational.

So your point is that TS is special in that it's a newer technology, and
thus has less or no mindshare with firewall vendors etc. If exposed to
the public via the internet, your take is that VPN and IP address level
auth is the only way to operate with confidence. Is that a fair summary?

"Are you using this box as a cheap Application Server and hosting apps
for customers?"

Yes, it's more of a potential, there is no such box at this time, just
exploring. If you have a suggestion re the sensible route for a newbie
like me to look into, I'd like to hear about it. (I do have one ts app
exposed via firewall/vpn endpoint, but I'm only the app provider, not
very involved in the network part of that)

 

[Jeff Pitsch]

I'm not kicking sand but when something is explained over and over it gets
very frustrating saying the same thing to the same people. You keep posting
the same questions over and over as if you will finally get the answer you
want to hear. Yet you keep getting the same answers, not just from me, but
others as well. so I guess you can take it as you will. By the way, I'm
responding your comments not the OP. I'm not trying to be a jerk but
obviously it came across that way. I just don't know how to explain it any
more clearly. Don't expose your internal network to the internet.

Jeff Pitsch
http://www.sbcgatekeeper.com
Your Terminal Services Security

 

[Leythos]

Hi thanks for taking the time to write all of that, it's very
educational.

That's what we're here for - I've learned a lot in my 20+ years on
Usenet, always like to give back when I can.

So your point is that TS is special in that it's a newer technology, and
thus has less or no mindshare with firewall vendors etc. If exposed to
the public via the internet, your take is that VPN and IP address level
auth is the only way to operate with confidence. Is that a fair summary?

Sort of - my position is that TS should never, new or not, be exposed
where there are proven means to access the server without exposing the
TS services.

Sort of like the old HTTP/RPC email access for Outlook that was used for
years until a worm trashed that method - then all the ASP's that were
providing Exchange over HTTP were screwed as they scrambled to implement
VPN solutions (and then later HTTPS methods).

There is just no valid reason to expose the TS service.

"Are you using this box as a cheap Application Server and hosting apps
for customers?"

Yes, it's more of a potential, there is no such box at this time, just
exploring. If you have a suggestion re the sensible route for a newbie
like me to look into, I'd like to hear about it. (I do have one ts app
exposed via firewall/vpn endpoint, but I'm only the app provider, not
very involved in the network part of that)

What you need to do is make Security a clear part of your business plan,
so that you account for it's needs and methods, before you build a
business and then have to re-do things because of problems you didn't
expect - hence, why we don't expose TS outside of the LAN.

 

[kiln]

The only think that I said about my potential TS server was that it
would not connected to a LAN. I think you must be confusing me with some
other posters: "You keep posting the same questions over and over as if
you will finally get the answer you want to hear. Yet you keep getting
the same answers, not just from me, but others as well." I've been
posting in this ng for a day or two, but asking for the same answer over
and over? No. The only interchange I've had with you is in this thread,
where you've not communicated much of anything to me that was related to
my or the OPs questions. On the other hand, today in this thread Laythos
articulated his stance on how to sec a site like I've asked for; at
least I think I understood him.

It's obvious that you know your stuff and contribute a lot here. But I
don't think this particular thread is going to go into your Best Threads
of 2005 scrapbook?

 

[Jeff Pitsch]

TS has been around for over 10 years. It's not new technology. If being an
older technology meant bad security then nobody would be using Unix, BSD,
Linux, windows, etc.

Jeff Pitsch
http://www.sbcgatekeeper.com
Your Terminal Services Security Website

 

[Guest]

Sort of - my position is that TS should never, new or not, be exposed

where there are proven means to access the server without exposing the
TS services.

Sort of like the old HTTP/RPC email access for Outlook that was used for
years until a worm trashed that method - then all the ASP's that were
providing Exchange over HTTP were screwed as they scrambled to implement
VPN solutions (and then later HTTPS methods).

There is just no valid reason to expose the TS service.

I am curious how you would view RDP using HTTP as introduced in Windows
Server SP1? Do you believe that the HTTPS solution is comparable to VPN?

 

[Baldsimon]

A good topic for discussion!

We used to use VPN (before we implemented Terminal Server) and now we don't.
Instead we open a (non-standard) port on the firewall and use
port-forwarding to point incoming traffic from specific, permitted client
computers and users (both must be correctly identified) to port 3389 on the
TS.

The reason that we ended up dropping VPN was that we had no control over the
remote computers. When they become compromised and VPN to the network then
we had endless problems with the compromised machines being part of the LAN.

So far, since we switched to using native RDP/port-forwarding and no VPN we
have had no problems. It's also much, much easier for the end user to
manage for themselves! This approach has also enabled us to add an extra
layer of redundancy in that we now have two separate internet connections
from different providers and the client can access the TS via either
connection.

Regards,
Simon.