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

"kiln" <kiln@brick-like.com> wrote in message
news:MPG.1e1472eaa5ca38f498999c@msnews.microsoft.c om...
> 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???
>
> In article <cgxqf.219831$tD4.37575@tornado.ohiordc.rr.com>,
> void@nowhere.lan says...
>> In article <MPG.1e13c30bad53402198999a@msnews.microsoft.com>,
>> kiln@brick-like.com says...
>> > 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?
>>
>>

In article <MPG.1e1472eaa5ca38f498999c@msnews.microsoft.com>,
kiln@brick-like.com says...
> 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?


--

spam999free@rrohio.com
remove 999 in order to email me

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.

In article <eSpf5IyBGHA.2644@TK2MSFTNGP09.phx.gbl>,
jeff@sbcgatekeeper.com says...
> 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
>
> "kiln" <kiln@brick-like.com> wrote in message
> news:MPG.1e1472eaa5ca38f498999c@msnews.microsoft.c om...
> > 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???
> >
> > In article <cgxqf.219831$tD4.37575@tornado.ohiordc.rr.com>,
> > void@nowhere.lan says...
> >> In article <MPG.1e13c30bad53402198999a@msnews.microsoft.com>,
> >> kiln@brick-like.com says...
> >> > 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.

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)

In article <%_Cqf.219896$tD4.77407@tornado.ohiordc.rr.com>,
void@nowhere.lan says...
> In article <MPG.1e1472eaa5ca38f498999c@msnews.microsoft.com>,
> kiln@brick-like.com says...
> > 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?
>

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

"kiln" <kiln@brick-like.com> wrote in message
news:MPG.1e14a50be8c71faf98999e@msnews.microsoft.c om...
>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.
>
> In article <eSpf5IyBGHA.2644@TK2MSFTNGP09.phx.gbl>,
> jeff@sbcgatekeeper.com says...
>> 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
>>
>> "kiln" <kiln@brick-like.com> wrote in message
>> news:MPG.1e1472eaa5ca38f498999c@msnews.microsoft.c om...
>> > 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???
>> >
>> > In article <cgxqf.219831$tD4.37575@tornado.ohiordc.rr.com>,
>> > void@nowhere.lan says...
>> >> In article <MPG.1e13c30bad53402198999a@msnews.microsoft.com>,
>> >> kiln@brick-like.com says...
>> >> > 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.

In article <MPG.1e14a78519389f3098999f@msnews.microsoft.com>,
kiln@brick-like.com says...
> 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.

--

spam999free@rrohio.com
remove 999 in order to email me

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?

In article <edgiGZzBGHA.4016@TK2MSFTNGP11.phx.gbl>,
jeff@sbcgatekeeper.com says...
> 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
>
> "kiln" <kiln@brick-like.com> wrote in message
> news:MPG.1e14a50be8c71faf98999e@msnews.microsoft.c om...
> >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.
> >
> > In article <eSpf5IyBGHA.2644@TK2MSFTNGP09.phx.gbl>,
> > jeff@sbcgatekeeper.com says...
> >> 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
> >>
> >> "kiln" <kiln@brick-like.com> wrote in message
> >> news:MPG.1e1472eaa5ca38f498999c@msnews.microsoft.c om...
> >> > Your comments confuse me, and they are in the vein of other comments

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

"kiln" <kiln@brick-like.com> wrote in message
news:MPG.1e14a78519389f3098999f@msnews.microsoft.c om...
> 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)
>
> In article <%_Cqf.219896$tD4.77407@tornado.ohiordc.rr.com>,
> void@nowhere.lan says...
>> In article <MPG.1e1472eaa5ca38f498999c@msnews.microsoft.com>,
>> kiln@brick-like.com says...
>> > 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?
>>

> 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?

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.

"Leythos" <void@nowhere.lan> wrote in message
news:KpGqf.219923$tD4.24549@tornado.ohiordc.rr.com ...
> In article <MPG.1e14a78519389f3098999f@msnews.microsoft.com>,
> kiln@brick-like.com says...
>> 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.
>
> --
>
> spam999free@rrohio.com
> remove 999 in order to email me