Re: Remote terminal service - Comments

Thanks for your answer Jeff. I'm still having a little difficulty
understanding just what you might recommend. "Poking a hole" ,as you call
it, is not what I call it when you do port forwarding from your firewall to
a single box behind your firewall, that is NAT'd.

Anyhow, near as I can tell, you're thinking VPN or DMZ, pretty much period.
Is that right?

Incidentally, about DMZ. I believe in DMZs wholeheartedly, if your network
warrants the expense. But if you "poke holes" from your DMZ to allow
connectivity to your internal network, what's the point in having that other
router for your DMZ anyway? Many folks do DMZs this way, for better or
worse.

I view "publicly accessible" servers different from "directly on the
Internet". All the web browsing everyone does is to "public accessible"
servers. But not all are "directly on the Internet".

-Frank

"Jeff Pitsch" <jeff@xxxxxxxxxxxxxxxxx> wrote in message
news:ubiW6JaBGHA.2668@xxxxxxxxxxxxxxxxxxxxxxx
> Obviously this is completely my opinion so take it for what it's worth.
>
> An internal server should never be exposed directly to the internet. This
> is regardless of a NAT because it still allows direct access to the
> server. The preferable solution is something like a VPN (a traditional VPN
> does typically slow things down but it shouldn't be that bad) or a man in
> the middle (citrix Secure Gateway). It comes down to making it that much
> harder for someone to get into your internal network. for example, a DOS
> attack. If you do strictly the NAT, your still exposed your internal
> network and if an attack isn't shut down, you've now compromised your
> internal network. if you do a man in the middle (2x loadbalancer or
> Citrix Secure Gateway), the attack is directed at that one box in the DMZ.
> You've effectively cut off the initial attack.
>
> Now on top of that, if you are going to poke a hole to your internal
> network, why have a firewall at all? What good does it do if you're
> exposing your internal network? Yes someone could hack the DMZ server and
> then hack into your internal network but, again, your putting another
> layer of defense in. This lends itself to you may be able to detect an
> intruder in your DMZ before they get inside.
>
> to me this is just the #1 tenant of security, you never, ever directly
> expose your internal network.
>
> as well, not everyone is going to hacked and not everyone is even going to
> have an attempt. That's great and that's the way it should be. On the
> same token (to take away from mothers everywhere), if everyone jumped off
> a bridge would you? to paraphrase Jurassic Park, you were so busy
> figuring out if you could, you never thought about if you should.
>
> does any of that make sense?
>
> Jeff Pitsch
> http://www.sbcgatekeeper.com
> Your Terminal Services Security Website
>
> "Frankster" <Frank@xxxxxxxxxxxxxx> wrote in message
> news:q-KdnZ6l1r9tsjXeRVn-qQ@xxxxxxxxxxxxxxx
>>> the site has only been up for a few months. It takes time for content.
>>
>> Yeah, I know :-)
>>
>> One thing I was looking for was your recommended method of not placing a
>> TS (or any server) "directly" on the Internet.
>>
>> I've been running a TS "directly" on the Internet for years without
>> issue. First NT, then 2000, now 2003. But, my definition of "directly" is
>> probably different than yours. Mine is behind a network firewall, using a
>> private IP after being NAT'd. Still, no VPN or other security measures
>> (except NATing) have been taken. Yes, a complex password requirement for
>> all users on the box is a given. Perhaps this qualifies in your
>> definition of "not directly". I dunno...
>>
>> OTOH, I have also often ran a TS within a VPN, NAT'd and with RSA
>> SecureID. Works too. But slower. Perhaps this is your definition of "not
>> directly".
>>
>> I would take OS hardening to be a given in all public access situations.
>>
>> Can you comment?
>>
>> -Frank
>>
>
>


.

Relevant Pages

  • Re: Unable to join AD domain from DMZ network
    ... > the captured traffic between the server in DMZ to the DC from internal ... >> unless you lock it down to a specific port. ... >>> authentication from DMZ to 2003 AD internal network. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Gurus: server on perimeter vs. corporate advice
    ... But if you put the Sharepoint in the "DMZ", you would need to open various ... ports to allow communication from the DMZ to the Internal network (I think ... When you "open" such ports for a server that resides in the DMZ, ...
    (microsoft.public.security)
  • Re: Unable to join AD domain from DMZ network
    ... To me that points to something outside the machine (Firewall most likely culprit) ... > the captured traffic between the server in DMZ to the DC from internal ... >>> authentication from DMZ to 2003 AD internal network. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Windows 2K RRAS VPN on DMZ cant authenticate users
    ... >>>How can it be part of the domain when it is out in the DMZ?" ... >> I should have said all the ports are open between the VPN Server and the ... >> to connect to our internal network, it can't be spoofed cause it's got ... >> It's a Remote Access VPN with clients connecting to it using PPTP ...
    (microsoft.public.win2000.networking)
  • Re: Windows 2003 VPN wont respond to packets forwarded by Linux router
    ... Win2K3 server? ... Do you have correctly marked external and internal network ... problem is in certificates, use MS CHAP v2 for test, till it works with MS ... > forwarded VPN traffic to a Windows 2000 Pro workstation. ...
    (microsoft.public.windows.server.networking)