Inline:
----- Original Message -----
From: "Logan Greenlee" <[EMAIL PROTECTED]>
To: "maralisa" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[email protected]>
Sent: Monday, November 14, 2005 9:33 PM
Subject: RE: RE: break in? - terminal services on alternate port
Moving the TS port is for the most part unnecessary, silly and not
"smart". In fact, moving your TS port around might even make you machine
less accessible from some networks depending on the vigilance of network
administrators there by reducing the utility of the service.
Let's break this down a bit... "Unnecessary?" Maybe- that is a matter of
perspective based on what security measures one defines as "necessary." But
I completely disagree when you say it is "silly and not 'smart'."
Defining an action as foolish or "dumb" explicitly infers some escalated
level of consequence in the action's execution. But there is none in this
case. Not changing the default RDP port immediately identifies a potential
attack vector to an attacker. Changing it makes them do more work to find
it. More work == more time == more noise. I would make a strong argument
that forcing what would normally be a silent attack by default to one where
both the time frame of penetration is extended, and the propensity of attack
discovery is increased, not to be silly or foolish.
"Network vigilance" would be based on defining what services are needed,
which means that the admins would support the port change. But even if they
didn't, the logic of having the utility reduced by being blocked would stand
on both sides-- some admins do not open 3389 because they know the ports are
changed. Thus, that point is moot.
By moving the port you gain some degree of security through obscurity.
Though, no real tangible gains have been made on the safety of the
system. This is in my opinion no security at all - moving the port does
not mitigate a human threat, and it does not mitigate threats from
somewhat intelligent worms. Only in the case of a self propagating
"dumb" worm or program that specifically targets 3389 (and no others)
will one find themselves in trouble. Terminal services has an excellent
(as far as MS is concerned) track record in regards to security and
while this is no degree of insurance it does lead me to believe that it
can be trusted.
What intelligent worms? I know of no worm that did a port scan for the
vulnerable service when the pop wasn't found on the default port. Why would
a worm do so, anyway? The point of a worm is to propagate and to do so as
quickly as possible before it is detected. Why increase the acquisition of
the entry vector by 65,534 (it already has 3389) just on the off chance that
it hit the "one in x" people who have changed the port? Worm's don't and
they won't.
I've done a little bit of work with detecting terminal services on a box,
and even when grabbing service handles or querying master browser
registrations the listening port is not revealed. You don't get an RDP
banner on connecting to a terminal service/remote desktop box-- you've got
to go the Full Monty and request an RDP connection to really know that
you've got the RDP port.
Regardless, let's just look at it logically-- There is a question regarding
any additional security in changing the listening port-- doing so may, it
may not. Given that, one must agree that there is *absolutely* no
additional security benefit in *not* changing it, right? Therefore, the
question is not "why change it," but "why not?"
The "smart" solution here would involved isolating access to Terminal
Services to authorized users of your network. Access to the terminal
serviced machine should be provided via a VPN connection. If you want to
be really paranoid about it - the VPN connection should not be provided
by your DC (tempting on smaller networks) but instead by another network
device or server. You should also make sure that the device
authenticates with a higher level of credentials than a preshared key
(IPSec comes to mind).
Terminal Services are already isolated to authorized users... Requiring VPN
access is not the "smart" solution- it's just a "different" solution. Some
people might access via TSWeb on some remote system without having to be
able to build a VPN connection on the box. TSWeb allows for alt port
configurations. Not all remote systems allow you to config a vpn client.
Additionally, not everyone is running ISA 2004 and restricting VPN clients
to 3389. Many implementations of VPN still allow full stack access to the
network. That's not necessarily a "smart" way to extend TS to a client.
The knee jerk reaction to that is "well, VPN provides dual authentication
mechanisms." Not when deployed like this-- the same uname/pwd is used for
both VPN and RDP logon in the typical deployment model. If "game over"
lives in the RDP default connection, it certainly lives in the VPN model as
well.
In my experience TS can stand on it's own. It's a hardy service that has
managed to prove itself through so many catastrophes with other windows
services. Moving the port only has the capacity to restrict your ability
to use the service as intended and does not truly provide any sort of
security. It also adds to the complexity of the network.
We all thought IIS5 could stand on it's own before CodeRed came along.
(Well, I didn't. Neither did Laura. Or Marc. Or Carv. Or BitchHolz. Or
Litch. Or the rest of us that changed our default configs)
Changing the administrative login is a good idea though - as it is
nearly impossible to guess in a reasonable amount of time both a user
and a pass for the machine in question.
I agree.
Make sure that your lockout policy is defined such that there is a long
pause between incorrect logins and a lockout for an extended period of
time after no more than 5 failed authentication attempts. Also, if you
do use terminal services you should enable both successful and failed
authentication events. Periodically reviewing the logs is always a good
idea and not just when you think you've been compromised ;-)
Great advise... And look, I'm not trying to be an ass about all this-- but
just because something is obscure, doesn't mean it doesn't have some
intrinsic value. Security through obscurity, by its very definition, works
perfectly as long as the securing element is obscured. Forcing someone to
discover something before attacking it has value, particularly when other,
obvious, targets are so evident.
thx
t
---------------------------------------------------------------------------
---------------------------------------------------------------------------
