Security Basics mailing list archives

RE: A different question RE: Windows Remote Desktop


From: "Shawn Jackson" <sjackson () horizonusa com>
Date: Fri, 16 Jan 2004 09:43:00 -0800


        From my terminal server experience I encountered that 'type' of
problem in the following situations.

        1.) The program can't operate in a shared environment with
multiple instances open. Some programs just can work under TS properly
due to their use of static files, (INI's, config files, flat file db's,
etc). Could you have another instance running on the box that is
'locking' a file needed to be written to by the new instance?

        2.) Service packs/updates/hotfixes are more 'pronounced' in a TS
environment and need to be looked at a lot more carefully. Even though
you install them days ago some file operations are saved for when the
system reboots, check your logs to see what updates were installed
recently.

        3.) Communication errors, excessive latency or dropped packets
can mess up communication between the client and server and cause
'weird' TS error messages, usually (The server is too busy....).

        4.) If it *is* a Terminal Services server and not a XP RDP box
make sure you are licensed properly, TS-CALS are demoed for 90 days or
so then become invalid, at which point you need to setup a licensing
server and install some TS-CALS.

        5.) Make sure you don't have any 'phantom' sessions still open.
Set a timeout for disconnected sessions to ensure that they disappear.
For my servers I set this high for admin purposes but if it's an
end-user TS server I set this very low.

        6.) Update your afflicted program or reinstall it, make *SURE*
you are running the install/update using the Add/Remove Programs
installation utility, no program on a TS server should be installed
without using Add/Remove programs utility.

        7.) Reinstall your NIC drivers and use a multi-homed server.
Which seaming you're sniffing anyways you should be connected to a
'management' NIC and sniffing through another NIC.

        8.) Double check permissions, TS for installed programs created
'shadow' copies of static files that the program writes, like
configuration files or databases. These might be damaged/missing or have
had their permissions removed/changed.

        9.) When in Rome.... Remove TS->Reboot->Reinstall
TS->Reboot->Reinstall Program (From Add/Remove pgms util)->Reboot.

Shawn Jackson
Systems Administrator
Horizon USA
1190 Trademark Dr #107
Reno NV 89521

www.horizonusa.com
Email: sjackson () horizonusa com
Phone: (775) 858-2338
             (800) 325-1199 x338


-----Original Message-----
From: David Gillett [mailto:gillettdavid () fhda edu] 
Sent: Thursday, January 15, 2004 4:37 PM
To: security-basics () securityfocus com
Subject: A different question RE: Windows Remote Desktop

  We don't allow RDP to/from off-site locations, but we've
been using it to allow a couple of folks to, from their
office desktops, connect to strategically placed servers
to sniff specific network segments.
  This worked fine from sometime in September until the
Christmas/New Year's break, during which we had a scheduled
power shutdown.  Everything came back on after the shutdown,
and most boxes involved have been rebooted individually
since.
  But although sniffing still works fine from the server
console, RDP clients get a general-purpose error message 
that seems to indicate that they don't have the necessary
permissions, or there's some other kind of problem, with
the adapter that connects to the sniffed segment.

  Since sniffing from the console works, we know it's not an
adapter or port configuration issue, or a switch port issue.
Since several privileged accounts, including Administrator,
*can* sniff from the console but not from an RDP session,
we're convinced it's not an account privileges issue.
  And since it worked before the power shut-down, we know
it can be made to work.

  Has anyone who works more extensively with RDP seen anything
similar?  Or have you a useful theory that might help explain
what we're seeing?

Dave Gillett



------------------------------------------------------------------------
---
Ethical Hacking at InfoSec Institute. Mention this ad and get $720 off
any 
course! All of our class sizes are guaranteed to be 10 students or less.

We provide Ethical Hacking, Advanced Ethical Hacking, Intrusion
Prevention, 
and many other technical hands on courses. 
Visit us at http://www.infosecinstitute.com/securityfocus to get $720
off 
any course!  
------------------------------------------------------------------------
----


---------------------------------------------------------------------------
Ethical Hacking at InfoSec Institute. Mention this ad and get $720 off any
course! All of our class sizes are guaranteed to be 10 students or less.
We provide Ethical Hacking, Advanced Ethical Hacking, Intrusion Prevention,
and many other technical hands on courses.
Visit us at http://www.infosecinstitute.com/securityfocus to get $720 off
any course!
----------------------------------------------------------------------------


Current thread: