Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Focus-Microsoft
[Top] [All Lists]

RE: Re: Remote connections

Subject: RE: Re: Remote connections
Date: Tue, 19 Oct 2004 10:34:36 -0700
Actually, the TSWeb client is a simple and ActiveX based terminal server
client.  It allow simply deployment (web based) of a relatively limited
client.

Check out:
http://blogs.msdn.com/tristank/archive/2004/03/18/91806.aspx 

BTW, the last issue of (now) Windows IT Pro had an article about using
RDP securely too (instant doc 43877).  Basically, it is a best practices
approach.  The main tips being:

-Require maximum encryption
-Require password (disable pass-thru for TS login)
-Disable most redirection to local resources

My two cents on the subject of various remote control programs:

RDP works fairly well, even over slow links.  With XP/2000 the lack of
actual console access is annoying for certain tasks.  At least this is
corrected with 2003.

VNC is its various forms is quick and can actually be setup easily
remotely if necessary (provided with access to administrative shares of
course).  Very nice that most VNC clients can connect to most VNC
servers regardless of actual version.  Lack of build-in security beyond
simple password limits its security.  Yes, you can use VNC over SSH, and
there is even a distro that supports stream encryption modules...but
this is not default and you can not guarantee that EVERY server you
which to connect to supports the encryption unless you set it up
yourself.

I have not actually used Radmin but I have used most of the desktop
management remote control programs (LanDesk, Novell ZEN, Trackit Remote)
which all appear to be based on one originally developed by Intel.  Good
performance, ability to use other modules (file transfer, command
execution, etc) but security is usually proprietary.

All these systems suffer from connection stability issues at depending
on how the terminal server is configured (in the case of RDP) you can
loose your session once disconnected and have to start over instead of
simply reconnecting.

Anyway, that's my opinion.  I think in the end this subject is more like
"what's the best shell" "what's the best editor" or "what's the best
scripting language" we all have our preferences that we swear are the
only real solution.

Jordan


-----Original Message-----
From: John Fleming [mailto:jfleming@creativeventuresofboca.com] 
Sent: Monday, October 18, 2004 8:04 PM
To: 'Laura Robinson'; 'GuidoZ'; focus-ms@securityfocus.com
Cc: bugtraq@planetcobalt.net; paviles@adjoined.com
Subject: RE: Re: Remote connections

Aside from creating a VPN tunnel and then performing a Remote Desktop
session, the only other secure way that I was taught, but never tested
was through SSL.

Aparently there is a Remote Desktop Web Connection feature that can be
installed with IIS 6.0. This can act as a gateway to 2000 and 2003
Server Terminal Services and XP and 2003 server Remote Desktop machines.
You communicate through HTTP port 80 or SSL 443. Terminal Services Web
Connection is installed on the web server to a Virtual Directory called
TSWEB. It is supposed to act as a gateway between the client and
terminal server. Like I said, I have never tried it, but would love to
hear some input on it if anyone has.

Regards,

John

-----Original Message-----
From: Laura Robinson [mailto:larobins@verizon.net]
Sent: Saturday, October 16, 2004 5:34 PM
To: GuidoZ; focus-ms@securityfocus.com
Cc: bugtraq@planetcobalt.net; paviles@adjoined.com
Subject: Re: Re: Remote connections



Why not? I don't know of any current exploit for RDP set to high 
encryption, and even if there were any, connections may very well be

shielded by encrypted tunnels.

I'm not aware of any currently either, but as their track record 
proves, that's meaningless.


RDP has been around and used for *years*. Just because Microsoft makes
something doesn't inherently mean that it is broken and requiring of a
knee-jerk bigoted approach to it.

RDP can be tunneled thru SSH as well and has much better performance

than VNC (don't know about Radmin).

This may very well be true. I'm not up to par as much as I'd like on 
RDP, although I'm quite well learned on VNC and such. TightVNC has 
some of the best compression I've ever seen on a remote control app,  
I've used TightVNC through Dial-up many a times without delay or a 
problem. I'd love to see RDP perform the same feat.

Um, it does. I've done it many, many times. And RAdmin is garbage as far
as what it does to the machine on which it's running unless you remember
to crank down its refresh rate to a near-nonexistent level.

But I digress. Again, I very well could be wrong about RDP. I've 
always leaned towards other remote control programs due to problems 
that usually arises with proprietary programs. (I've been using a form

of WinVNC since before RDP was even thought of.)

Don't be too sure- do you know where RDP came from? With that said, I
think it's time for you to take a look at it before making what you
admit are biased statements about it. Never comment on something you've
not used is usually a good approach, I find.

 


------------------------------------------------------------------------
---
------------------------------------------------------------------------
---




------------------------------------------------------------------------
---
------------------------------------------------------------------------
---




DISCLAIMER: 
This message is confidential, intended only for the named recipient(s)
and may contain information that is privileged or exempt from disclosure
under applicable law.  If you are not the intended recipient(s), you are
notified that the dissemination, distribution or copying of this
information is strictly prohibited.  If you received this message in
error, please notify the sender then delete this message.

---------------------------------------------------------------------------
---------------------------------------------------------------------------


<Prev in Thread] Current Thread [Next in Thread>