Blocking terminal services to non admin users

  • Thread starter Thread starter Chris Pratt
  • Start date Start date
C

Chris Pratt

Hi all,

we use terminal services for managing our servers but was wondering if you
can restrict who can access it. I know it runs on port 3389 or something,
so can you set-up a firewall to stop access to port 3389 to every IP but the
administrators machine? we are worried that if an admin password got out
that a user (in our case a student) would use a client to access the server
via terminal services.

Or is there a better / easier way to do it?

All help appreciated

Chris
 
I have no idea which features your firewall has. The only native
way to restrict access to TS is by user account.

If you can't trust that your administrator password is kept a
secret for the users, then you have a problem that is far more
serious than access through TS only. I presume that the servers
that you manage are networked with the clients that are used by
the students. If the administrator password is known, they won't
bother with TS, I can promise you :-(
 
I don't think our admin password is at risk but our network manager would
like this type of security in place (just in case - if you like!). Any ideas
would be appreciated.

Thanks

Chris
 
You are correct that you could use a firewall to prevent certain computers
from reaching a specific port on a particular computer or subnet or group of
computers based upon other characteristics. The assumption I have is that
you are trying to allow users to have access to these servers for their apps
server purposes, but prevent them from taking administrative control via TS
access.

As Vera suggested, you are giving away a lot of ground by assuming that the
password of the Admin group has been lost, basically because you are asking
"if I assume that users in the network have already gained full
administrative rights to a computer, is there a way I can block one port
from access?" That's not a very deep thought. You are now discounting all
of the workarounds available to the user with administrative rights to
defeat whatever security you now have introduced specific to the TS logon,
but not specific to the one port! With Admin rights, a connection via WMI,
the user potentially can make hash of any plan you have to keep them out of
that machine, including resetting the TS port. It depends upon the
determination that user has.

If you were to put a firewall on the TS or in front of it, port filtering
would work to do what you want, provided that the firewall properly takes an
authentication that you can verify in order to open/close that port. You
might have more luck by locking down the outbound ports at the local station
that connect to TS rather than blocking the TS servers themselves because if
the assumption is that "no one on this subnet should have TS control
access", you could firewall out the TS control from the location that is
unilaterally not to use TS sessions, rather than firewalling a conditional
basis at the TS. You might even be able to use the TCP/IP port filters
native to the OS to do this at each workstation, assuming that you have
blocked the user from having access to the Administrator control at their
workstation.

I think the question you ask is a fair question, it's a reasonable idea, but
it's not operating at a level with which a generic answer is easily
provided. By that I mean, if you have an office with 1 or 2 servers, and
that's where this question is coming, you will have a different scale of
answer than if you have 20-30 servers to protect. If you have VLAN switches,
multiple sites, routed subnets and multilevel browsing and security zones,
this means a completely different level of attack required as well as a
level of defense.
 
Thank you very much Jeff, for taking the time to structure a very well
thoughtout answer. You have given me a few ideas if you don't mind
indulging.

The idea of locking the ports on the workstation is an excellent idea. Can
this be done in group policy?

Thanks again

Chris
 
Hello Chris,
If I can chime in here, you're asking for not that unusual
a solution, and partly because it is recognized that
Username/password security by itself has limited efficacy
and the way hacking technology is going, already at this
time it takes a very short period of time to crack typical
passwords, even "strong" passwords with freeware
sophisticated crackers.

So, the key to your situation is usually "security in
depth." Better security requires not only a "thing you
know" (password) but also a "thing you have" which can be
a number of different things... but Microsoft is promoting
certificate technology in general and smartcards in
particular. There are many alternatives to using a
smartcard (carried on the person like a credit card)...
you can also use USB tokens, embed certificates in
workstations, applications, etc.

The process would be that logging on to the network would
require the User (administrator) to logon with both a
username/password <and> submit her personal token, whether
it's stored on her machine, plugged into a USB port or
scanned through a reader.

Speaking of scanners... Biometrics avoids the use of
password issues altogether and is becoming very cheap. You
can now purchase fingerprint scanners for less than $100
and you can require a fingerprint instead to logon to your
most critical machines. The smartcard scanner would cost
about the same, cards will cost from pennies to under a
dollar depending on quantity. USB tokens will usually cost
less than $5 each.

Good luck on your solution!

Tony Su
Su Network Consulting


-----Original Message-----
Thank you very much Jeff, for taking the time to structure a very well
thoughtout answer. You have given me a few ideas if you don't mind
indulging.

The idea of locking the ports on the workstation is an excellent idea. Can
this be done in group policy?

Thanks again

Chris

You are correct that you could use a firewall to prevent certain computers
from reaching a specific port on a particular computer
or subnet or group
of
computers based upon other characteristics. The assumption I have is that
you are trying to allow users to have access to these
servers for their
apps
server purposes, but prevent them from taking
administrative control via
TS
access.

As Vera suggested, you are giving away a lot of ground
by assuming that
the
password of the Admin group has been lost, basically
because you are
asking
"if I assume that users in the network have already gained full
administrative rights to a computer, is there a way I can block one port
from access?" That's not a very deep thought. You are now discounting all
of the workarounds available to the user with administrative rights to
defeat whatever security you now have introduced specific to the TS logon,
but not specific to the one port! With Admin rights, a
connection via
WMI,
the user potentially can make hash of any plan you have
to keep them out
of
that machine, including resetting the TS port. It depends upon the
determination that user has.

If you were to put a firewall on the TS or in front of it, port filtering
would work to do what you want, provided that the
firewall properly takes
an
authentication that you can verify in order to open/close that port. You
might have more luck by locking down the outbound ports
at the local
station
that connect to TS rather than blocking the TS servers
themselves because
if
the assumption is that "no one on this subnet should have TS control
access", you could firewall out the TS control from the location that is
unilaterally not to use TS sessions, rather than firewalling a conditional
basis at the TS. You might even be able to use the TCP/IP port filters
native to the OS to do this at each workstation, assuming that you have
blocked the user from having access to the Administrator control at their
workstation.

I think the question you ask is a fair question, it's a
reasonable idea,
but
it's not operating at a level with which a generic answer is easily
provided. By that I mean, if you have an office with 1 or 2 servers, and
that's where this question is coming, you will have a different scale of
answer than if you have 20-30 servers to protect. If
you have VLAN
switches,
multiple sites, routed subnets and multilevel browsing and security zones,
this means a completely different level of attack required as well as a
level of defense.
network manager
would
like this type of security in place (just in case -
if you like!). Any
ideas
 
I'm inclined to agree with Tony Su's thinking in the next post below, but to
answer your question...

I've not implemented a policy like this myself...yet...that will be coming
in the next few weeks I suspect because I have unrelated application
concerns to look into for this Group Policy trick.

In Group Policies, assuming you have all W2K/XP/W2K3 stations, you can use
the Computer Configuration | Windows Settings | Security Settings | IP
Security Policies.

The tools you probably want are listed there.

In addition, another slightly less complicated technique might be to
actually block access to the registry keys required to run the RDP using the
section of Security Settings | Registry. This is an area, together with File
System where I have been working with success in handling Administrative
control on workstations with a great deal of success.

If you are about to ask me for documentation on these sections, I'm going to
tell you that I've had very poor luck finding much on this. The best
technical information I've found is in fact in a recent set of information
created in Oct 2002, located in Technet | Security | Standards, Regulations
Government Issues...and then look into the three related documents that are
titled "Windows 2000 Common Criteria....Guide".

You may find some applicable info there.
 
Thanks very much Jeff. I'm currently looking into this in more detail. if i
come accross anything i will either e-mail you or post it here. Thanks to
everyone for their help.

Chris Pratt - MCP
 
Anything you find of interest, post it here. :)

BTW, the thing I was most curious about in that was that when I walked
through the wizard steps, it wasn't entirely clear to me if this process
requires you to use IPSEC if you only want to filter ports and subnet, not
implement IPSEC settings in general. I did see an RDP protocol in the list
to use. I'll get around to testing that, but it's not on the top of my todo
list this week.

Thanks.
 
Back
Top