We protect and optimize RDP. Disable redirection of unused devices

RDP Remote Desktop Protocol (Remote Desktop)

First of all, here we'll talk about StandAlone Server. That is, about a separate server. And not about domain controllers and corporate networks. (highly qualified specialists are required there)

A situation when an idea came to your mind and you decided to bring it to life. And to implement it, you need to have a Server, which you rent in a certain data center.

You chose the appropriate tariff, paid the money, and now you already have a Server on which the software you need is installed. In most cases, Windows 2003 Server is sufficient for such pilot projects. Quite inexpensive and effective.

Technical support will give you an IP address, Login and Password for RDP access, and you begin your journey, full of... well, in general - it won’t seem like much.

By default, we can say that this service in Windows is configured to cause the user a lot of trouble and problems.

Although, of course, it works on its own and performs its function perfectly. But over time, (sometimes it may be too late) the careless owner of a remote server will be horrified to realize what is really going on with his system and what a crowd of bloodthirsty people is standing around the walls of his fortress.
It's like turning off the infrared filter on the DVR and suddenly starting to see video sources - traffic police cameras with photo recording, and signals from TV remote controls.

You begin to see and then, perhaps, understand.

On the one hand, software developers pretend that they make their systems for ordinary person, and you start to believe it.

But on the other hand, these same developers assume that only a certified specialist can pick up the keyboard. And so that the certificate is from this year.

Such is the paradox.

Let me tell you what it really looks like.

But in fact, hordes of hackers, after reading a dozen lines on forums, download ready-made lists of servers with an open RDP port. And they start breaking into your car. Some do it manually (but this is rare), but mostly with different programs, running brute-force dictionaries: login - password. And no one limits them in anything. They are even cramped there at times.

Moreover, I look at the logs and see that for the most part, these are the same dictionaries.

And your server is forced to fight back. And you don’t know. And you don’t understand why your performance is low, why requests take so long to complete.

You're thinking about great things. Strategically, about functionality. And here - some kind of brakes are incomprehensible.

Therefore, you will start optimizing memory, deleting temporary variables, defragmenting disks, etc.

And maybe even take a closer look at the Events tab in the management snap-in.

But I assure you that you will not see the reason there! Because attempts to enter incorrect login and password are not displayed there. Perhaps you will even argue with other people that they don’t break you because they are afraid or respected.
No. I assure you, the developers are just such funny guys. And initially they tip the scales slightly towards darkness. They say that if these events were displayed, the load on the server would be higher.
But, just note that the first thing everyone should do is turn on this display. Although, of course, there are some completely closed from the outside world technological systems, where no one ever hacks anything. But there it is just such systems that serve entire teams of professionals.

So, let’s start by correcting this situation and bringing the system into normal working order.

What we will do:

1. We will limit the number of simultaneously open sessions allowed.
   (If you administer your remote server yourself, why do you need someone other than you to manage the server at the same time as you?
   Although, one more may be needed - for example, for technical support. And why more?)
2. And turn on the light. That is, we will allow the system to display unsuccessful login attempts in the “Events” snap-in.
   And here you will be surprised.
3. We will prohibit access to the server from more than 3000 IP addresses, which, strictly speaking, do nothing else but cause problems for people. Importing the Black List.

If, out of nothing to do, you make requests on the network about setting up RDP, you will come across a lot of advice (and for a long time I myself was sure that they were very effective, until I decided to conduct an experiment)

1. Limit the number of failed login attempts allowed.
   (If you are not drunk, then 3 times is enough for you to understand that the keyboard is in the wrong language and in the wrong register.)
2. Limit the time for these 3 attempts.
   (You can do it 3 times a week, or you can do it 3 times a second, and multi-threaded too. And therefore, since none of the cool hackers poke at the keyboard with one finger for a long time selecting a letter, there is decent traffic there, which in 10 minutes, that the developers have determined will have time to sort out several hundred, a couple of thousand combinations.)
3. Set a blocking time for entry if you are drunk, or if you are not you.
   (The default is 3 minutes, which won’t upset anyone. Let’s set it to half an hour. Let them get tired of waiting.)

I admit, I was very happy when I found such articles, and immediately did everything right. I was sure that now I could focus on the project itself and not worry too much about safety.

How there were tens of thousands of attempts during the day. (and I don’t sit with my head glued to the monitor all day, but I go in once a day to check the functionality of my applications) That’s how it remains.

And I still couldn’t understand how this could happen, so I see that I have 3 attempts configured and then blocked for 30 minutes. And this bot has been busy for six hours now, tirelessly sorting through logins from “Administrator” to “ferapont”.
But everything was not leisure. And then - I set everything up, so it should work!

Once, I had to transfer one of my projects from one server to another due to failure RAID array. And the old server was available to me for some time, but on it I could without fear try to conduct dangerous and not so dangerous experiments. Therefore, I decided to check it out.

To do this, for several minutes I tried to log in with wrong password, expecting that now the authentication system will block me. Figurines. Nothing happened.

I spent a couple of days studying this problem in more detail. I immersed myself in manuals and scant comments. Everyone assures us on the forums that this method is super effective.

And this is what I will tell you now:

• firstly, this method only works under a domain controller (you don’t know what it is? Spit, you don’t need it) and for a standalone server you need to immerse yourself in special knowledge and learn spells.
• secondly, it turns out, and apparently many mistakenly and naively assume otherwise (like myself), that when such a mechanism is implemented, the one who tries to enter will be blocked.
  No - just not him. And you will be blocked!
  Yes - it is your account that will be blocked for the time that you registered there. And you yourself will never be able to log into your own server!

When I leave the house and lock the door, I break the lock. I’ll frostbite my ears to spite Grandma.

But I think that parting with such illusions was worth a couple of days of torment.

We're done with the preamble. Let's get down to business.

1. We will limit the number of simultaneously open sessions allowed.

Find and open the “Terminal Services Configuration” snap-in:

In this snap-in, select and open the RDP-Tcp “properties” tab, where we limit “Msximum Connections” to 2x, for all network adapters.

Click OK. Now, only one more person can enter with you at the same time. And without you, everyone who wants to will have to stand in lines of two.
Get in line - sons of bitches!

2. Enable the display of unsuccessful login attempts in the “Events” snap-in.

Find and open the “Local Security Settings” snap-in and in it – the section: “Audit Policy”:

And change the property values ​​of all “Audit” entries - as shown in the screenshot. You will then need to reboot for the changes to take effect.

You can wait and after a few hours look at the now real picture in order to understand what kind of world we live in and who really surrounds us.

3. We deny access to the server from 100% malicious IP addresses. Importing the Black List.

Here you have 2 options:

• Fast and everything at once.
• Manual, with an understanding of what exactly you are doing.

Fast way.

After which, you should get something like this:

Manual method, with understanding.

1. First, you need to create an additional policy. Open the “Local Security Settings” snap-in.
2. Select the “IP Security Policies on Local Computer” section and right-click: “Create IP Security Policy...” and launch the Configuration Wizard.
3. You come up with a name for the new Rule. For example: "Block IP".
   
4. Next, click on all the questions and in the end you will have a form for editing the properties of the Policy.
   
5. Add a new Rule. Click. and if the Wizard checkbox is checked, then another Wizard will launch, whose questions need to be answered.
   
6. Tunnel Endpoint. press
   
7. Network Type. “All network connections” is already there. press
   
8. IP Filter List.
   Add a new Filter. Click and come up with a meaningful Name.
   
   For example: Block brute forcing IP.
   His list is still empty. We save it as is.

Regularly install important Windows Server OS and software updates

Keeping the operating system and installed software up to date, in addition to troubleshooting program malfunctions, helps protect your server from some of the vulnerabilities that the developers became aware of before the update was released. You can configure Windows to automatically download (install) important and recommended updates through the utility "Windows Update".

Despite the prevalence of high-quality open-source software products available “with one click,” we urge you to study the known vulnerabilities of such software before installing it and use only official sources to download distributions. Exactly self installation the administrator or user of software that is vulnerable or already “packed” with virus code often causes problems with infrastructure security.

Pay due attention to setting up Firewall

For servers Windows Server accessible via the Internet and not located behind a dedicated firewall device, Windows Firewall is the only protection tool external connections to the server. Disabling unused allow rules and adding deny rules will mean that fewer ports on the server are listening to external incoming traffic, reducing the likelihood of attacks on those ports. For example, for a standard web server to work, it is enough to open the following ports:
80 - HTTP
443 - HTTPS

For ports to which access must remain open, you should limit the range of connection sources by creating a “white list” of IP addresses from which calls will be accepted. This can be done in Windows Firewall rules. This will ensure that everyone who needs access to the server has it, while denying those who are not “invited”.

Below is a list of ports, access to which is best limited only to the circle of clients included in whitelist IP:

• 3389 - Standard RDP port
• 990 - FTPS
• 5000-5050 - ports for FTP in passive mode
• 1433-1434 - standard SQL ports
• 53 - DNS

Rename the default administrator account

Because standard notation local administrator "Administrator" is enabled by default in all current versions of Windows OS and has unlimited powers; it is for this account that people most often try to find a password to gain access to server management, because it's easier than figuring out usernames.

Create multiple administrative accounts

If multiple people are involved in administering your infrastructure, create a separate account with administrative rights for each of them. This will help track who exactly authorized this or that action in the system.

If possible, use an account with limited rights to work

To perform tasks that do not require administrator rights, it is advisable to use the account regular user. In case of penetration into the system, incl. As a result of the user's actions, the server's vulnerability level will remain at the level of authority of this user. If unauthorized access to the account is obtained, the administrator will also receive unlimited access to system management.

Do not provide shared access to directories without entering a password, differentiate sharing rights

Never allow connection to shared folders servers without entering a password and anonymous access. This will eliminate the possibility easy receipt unauthorized access to your files. Even if these files themselves have no value to an attacker, they can provide a “window” for further intrusion, since users of your infrastructure are likely to trust these files and are unlikely to check them for security reasons. malicious code every time you start.

Besides mandatory use password, it is advisable to differentiate access rights to shared directories for their users. It is much easier to set limited rights for users who do not need full access (write/read/modify) than to ensure that no client accounts are subsequently compromised, which could have adverse consequences for other clients accessing the shared network resources.

Enable prompting for a password to log in when exiting standby mode and auto-disconnecting sessions when inactive.

If you are using a physical Windows server, we strongly recommend that you enable the user password prompt when resuming from standby mode. You can do this in the tab "Power supply" Control panels (page task area "Choose a power plan").

In addition, it is worth enabling the user password prompt when connecting to a session after a specified period of inactivity. This will eliminate the possibility easy login on behalf of the user in the case when the latter, for example, forgot to close the RDP client on a personal computer, on which the security settings are rarely strong enough. To configure this option, you can use the Local Policy Configuration Utility secpol.msc called up through the menu “Run” (Win+R->secpol.msc).

Use the Security Configuration Wizard

The Security Configuration Wizard (SCW) allows you to create XML security policy files, which can then be transferred to various servers in your infrastructure. These policies include rules for using services, configuration of general system settings, and Firewall rules.

Correctly configure group security policies

In addition to pre-configuring Active Directory group policies (if you use them), audit and reconfigure them from time to time. This tool is one of the main ways to ensure the security of the Windows infrastructure.

For the convenience of managing group policies, you can use not only the utility built into Windows Server distributions "gpmc.msc", but also the proposed Microsoft utility“Simplified security settings” (SCM-Security Compliance Manager), the name of which fully describes the purpose.

Use local security policies

In addition to using Active Directory security group policies, you should also use local policies, since they affect not only the rights of users logging in through a domain account, but also local accounts. To manage local policies, you can use the corresponding snap-in, called by the command secpol.msc (“Run” (WIN+R)).

Remote Desktop Services (RDP) Security

- Block RDP connections for accounts with empty password

This measure is very obvious, but it should not be ignored. To block connections to remote desktops for a user whose password is not specified, open the utility "Computer Configuration" -> " Windows Settings" -> "Security Settings" -> "Local Security Policies -> "Security Settings" and enable ( Enable) parameter " Accounts: Accounts: Limit local account use of blank passwords to console logon only.

- Change the standard Remote Desktop Protocol port

- Configuring the Terminal Services Gateway

Service "TS (Remote Desktop Services) Gateway" allows remote users make remote connections to terminal servers and other machines private network with RDP enabled. It ensures secure connections by using the protocol HTTPS (SSL), removing the need for the administrator VPN settings. This tool allows you to comprehensively control access to machines, set authorization rules and requirements for remote users, namely:

• users (user groups) who can connect to internal network resources;
• network resources (groups of computers) to which users can connect;
• whether client computers must be members of Active Directory groups;
• whether clients need to use smart card or password based authentication or they can use either of the above two authentication methods.

Of course, the logic of the Remote Desktop Gateway implies the use of a separate machine for it. However, this does not mean that you cannot use virtual machine, deployed to any of the hosts on your private network.

Installing the TS Gateway service

To install Terminal Services Gateway on an eligible machine running Windows Server 2008/2012, follow these steps:

Create a certificate for Remote Desktop Services Gateway

To initiate SSL connections from RDP clients, an appropriate certificate must be created for the gateway:

The details of the created certificate are now displayed in the Server Certificates window. By double-clicking on this certificate, you can see information about the destination object and the presence of a private key for this certificate (without which the certificate is not used).

Configuring the TS Gateway to Use a Certificate

After creating the certificate, you need to configure the terminal gateway to use it:

- RDP session protection using SSL/TLS

To ensure the security of RDP connections when the connection to the server is not made through a VPN, it is recommended to use SSL/TLS connection tunneling.

The RDP over TLS option can be enabled via Remote Desktop Server security group policy (gpedit.msc command or menu “Administration” -> “Windows Components” -> Remote Desktop Session -> “Security”), where you need to activate the option to request a specific security level for remote connections (Require use of specific security layer for remote connections). The recommended value for this option is SSL (TLS 1.0) only.

You can also enable the above option through the remote desktop server management menu (Remote Desktop Session Host Configuration) by selecting from the list Connections required connection and going to its properties, where to select the security level "Security Level". TLS session encryption requires at least a server certificate. As a rule, it is already in the system (generated automatically).

To configure TLS tunneling of RDP connections, open the tools “Managing a Remote Desktop Server (Remote Desktop Session Host Configuration)” via menu "Administration" -> Remote Desktop Connections".

Select from the list of connections the one for which you want to configure SSL/TLS protection and open its Properties. In the tab "General" select the required Encryption Level. We recommend using RDP FIPS140-1 Encryption.

Isolate server roles and disable unused services

One of the main tasks of pre-planning the security of a server infrastructure is to diversify the risks of damage to critical infrastructure segments during successful attacks on individual nodes. The more roles each node takes on, the more attractive a target it becomes for attacks, and the more serious the consequences of defeating that node can be. To minimize such risks, it is necessary, firstly, to delineate the critical roles of servers at the stage of infrastructure deployment (if possible), and secondly, to disable services and roles on servers that are not really necessary to use.

Ideally, one server should perform one specific function (Domain Controller, File Server, Terminal Server, etc.). But in practice, such diversification of roles is rarely fully possible. However, you can separate the functions of the machines as much as possible.

To isolate roles, it is not necessary to use dedicated servers for each specific task. You can easily use virtual machines for some roles by configuring their security settings as required. Today, virtualization technologies make it possible not to experience any noticeable limitations in functionality. virtual hosts and can offer high levels of performance and stability. A properly configured virtual infrastructure may well be a full-fledged alternative to expensive hardware for those who want to diversify the risks of serious damage.

We are the team cloud service, for our part, we do not limit the client’s independent creation of virtual machines on virtual servers rented from us. If you wish to install a Windows virtual machine on your server, simply request the appropriate option.

Windows Server Core Overview

Windows Server Core is a Windows Server 2008/2012 distribution without a pre-installed graphical environment (UI). This distribution does not use many system services necessary for the operation of GUI and, accordingly, is free from a number of vulnerabilities associated with the operation of these services. One more thing Windows advantage Server Core - minimal load on server hardware resources. This makes her excellent choice for installation on virtual machines.

Unfortunately, only a few are currently supported for Server Core. Windows features Server, which is why this system cannot yet be called complete. Perhaps the situation will change in the near future.

I received some good advice to cover the work and configuration of the RDP protocol. A sensible idea, more details to follow.

Introduction

The RDP protocol is a convenient, efficient and practical means for remote access both for administration purposes and for everyday work.
Considering that its implementations are available almost everywhere (various platforms and OS), and there are many of them, you need to have a good understanding of its capabilities.
At the very least, this will be necessary for a number of reasons:

• Often, instead of RDP, another solution is used (VNC, Citrix ICA) for a simple reason - it is assumed that “the built-in RDP is minimal and does not do anything.”
• In many decisions related to what is fashionable now cloud technologies(transferring offices to “thin clients”, and simply organizing terminal servers), there is an opinion that “RDP is bad because it’s built-in.”
• There is a standard myth that “RDP cannot be exposed outside without a VPN, they are fooling” (the myth has a basis, but is no longer relevant for a long time).
• Well, since we’re talking about myths, there is an opinion that “When you switch from RDP to Citrix, traffic drops a couple of times.” After all, Citrix is ​​expensive, therefore at least 157% cooler.

All these myths are nonsense and a mixture of outdated “practical advice” that was relevant in the times of NT 4.0, as well as outright fabrications that have no reason to exist. Since IT is an exact science, we need to figure it out. A well-configured RDP protocol of new versions, taking into account all the new functionality, is a fairly good and reliable tool for organizing remote access.

So we'll do:

• Brief mention about RDP versions
• Setting the RDP session protection mode
• Setting up encryption for RDP
• Binding to a specific adapter and port
  • Change the standard port to the desired one
  • Making separate RDP settings for several network adapters
• Enabling NLA
  • NLA and Windows XP
  • How to enable CredSSP in XP
• Choosing the right certificate for RDP
• Blocking RDP connections accounts with empty password
• RDP speed optimization
• RDP compression optimization
  • Setting up general RDP compression
  • Configuring RDP audio stream compression
• Optimizing the ratio of RDP data streams
• Enabling Require secure RPC communication for RDP

Let's get started.

RDP protocol versions

The protocol has a fairly long history, starting with NT 4.0. We will leave historical details aside for a simple reason - to at the moment It makes sense to talk only about version RDP 7.0, which is available in Windows Vista SP1 / Windows Server 2008 and is added free of charge to Windows XP by installing SP3 and an updated RDP client (located at the link to KB 969084). I assume that you have at least Windows XP, and that you have installed/can install the latest Service Pack, and I will not waste your time discussing the advantages of RDP in Windows 2000 SP2 over NT 4.0 SP5.

Setting the RDP session protection mode

Basically, this is the most simple part tasks. The point is this. IN different versions RDP uses two main session protection mechanisms - built-in RDP and “wrapping” the session in TLS. The built-in one is not secure enough, and the recommendation “RDP can only be accessed via VPN” is about it. Therefore, always enable TLS support. This is the minimum you should start with. The only limitations will be a server version no lower than Windows Server 2003 SP1 and an RDP client 5.2 and higher, but I think this can be completely resolved at the end of 2011.

How to enable RDP over TLS

As always, there are several options. The first is enabling via Group Policy. To do this you need to go to target object group policy (or run gpedit.msc locally on your home workstation) and there sequentially select “Computer Configuration” -> “Administrative Templates” -> “Windows Components” -> “Remote Desktop Session Host” -> “Security” and There, enable the Require use of specific security layer for remote connections parameter, selecting SSL (TLS 1.0) only. You can choose a softer Negotiate, but I would not recommend it, because... at the moment this is simply below the acceptable level of security. As a person who created private clouds with enough high level security, I can say that there is zero point in moving particularly valuable data to a data center near London and going there using the default RDP and is a search for trouble.

It can be simpler - open the Remote Desktop Session Host Configuration snap-in (you can find it in mmc or ready-made in the Administrative Tools -> Remote Desktop Connections menu), select the desired connection from the Connections list (usually there is one and is called RDP-Tcp), and open Properties, after – General tab and select the desired Security Layer there.

For TLS to work, a digital certificate is required (at least on the server side). Usually it already exists (it is generated automatically), make sure it is there, and we’ll talk about how to make it good later. For now, you just need it to be there, otherwise you won’t be able to connect.

Setting up encryption for RDP

There will be 4 encryption options available for configuration. Let's look at each of them.

RDP Low Encryption Mode

The most “no” mode. A legacy of terrible times and versions of RDP 5.x. It can negotiate encryption based on 56-bit DES or 40-bit RC2, which is currently not serious. Unnecessary and dangerous. For example, if you enable it, TLS will not be enabled, because TLS will already refuse to negotiate ciphers as weak as this option offers.

RDP Client Compatible Encryption Mode

The second “no” mode. A legacy of terrible times and versions of RDP 5.x. Will try up to 128 bit RC4, but will immediately settle for DES/RC2. Unnecessary and dangerous. Also not compatible with TLS.

RDP High Encryption Mode

Minimum acceptable mode. Requires at least 128-bit RC4. Works with all servers starting from Windows 2000 Server w/HEP.

RDP Mode FIPS140-1 Encryption

Just what you need. It will support modern symmetric algorithms and will not explicitly support RC2, RC4, single DES, and will also force the use of the SHA-1 algorithm rather than MD5 to calculate the integrity (Message Authentication Code - MAC). Always enable this option; finding a server that does not know 3DES, AES or SHA-1 is almost impossible.

Where is this setting done? Open the Remote Desktop Session Host Configuration snap-in (you can find it in mmc or ready-made in the Administrative Tools -> Remote Desktop Connections menu), select the desired connection from the Connections list (usually there is one and is called RDP-Tcp), and open Properties, then the General tab and there select the desired Encryption Level.

We bind RDP to a specific adapter and port

In order for the server to work securely and predictably (for example, not to start accepting connections from a new, newly added network adapter), you must explicitly specify on which interfaces the RDP server service should accept connections. Plus, quite often it is useful to switch the port on which the server listens for connections. Of course, you can do this by publishing a server with RDP through some kind of gateway, but you can do it without it. Such, it would seem, basic actions in reality, they will significantly reduce the percentage of fools-scriptkids who check well-known ports with another “powerful tool”.

How to bind the RDP service to a specific network adapter or make multiple RDPs with different settings for different adapters

Open the Remote Desktop Session Host Configuration snap-in (you can find it in mmc or ready-made in the Administrative Tools -> Remote Desktop Connections menu), select the desired connection from the Connections list (usually there is one and is called RDP-Tcp), and open Properties, then the Network Interfaces tab . In it you can select one specific interface on which to wait for a connection, plus limit the number of parallel sessions.

If you have many interfaces, and you need, say, to be able to connect through 2 of the 5 available, then you will need to bind the existing default RDP-Tcp to one adapter, then go to the Action menu and select Create New Connection there. A connection can listen either on all interfaces or on one, and in the case where it needs to listen on N interfaces, N connections will have to be created.

Accordingly, if you have the task “So that on one RDP interface listened on one port, and on another - on another”, it can be solved in the same way - unbind the default RDP-Tcp from all adapters and bind it to a specific one, then create a new RDP connection and also bind it to the desired network interface.

How to bind an RDP service to a non-default port

The default port is 3389 TCP. By the way, don't forget to allow it in the packet filter. Well, if you want something else, you need to go to the registry key

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

and correct the PortNumber value in it. Keep in mind that monitoring conflicts in terms of port occupancy is on your conscience; he himself, having discovered that the port you have assigned is busy, will not be able to “jump” anywhere.

Enable NLA – Network Level Authentication

The NLA function appears in NT 6.0, and later the ability to partially use it is added in previous version OS by installing SP3 for XP.
The essence of this function is quite simple. In RDP versions up to 6.0, when connecting via RDP, the client must show the login window before authentication - i.e. first show it, and then he will try to log into the system. This creates a simple vulnerability - the server can be overloaded with a bunch of requests “let me try to start a new session,” and it will be forced to respond to all requests by creating a session and waiting for the user to log in. In fact, this is a DoS capability. How can you fight this? It is logical that we need to come up with a scheme the purpose of which is to request credentials from the client as early as possible. Optimally, there should be something like kerberos in the domain. This was done. NLA solves two problems:

• The client is authenticated before initiating a terminal session.
• It becomes possible to transfer local client SSP data to the server, i.e. Single Sign-On starts working.

This is implemented through a new security provider – CredSSP. You can read its technical specifications, but to put it simply, you should always turn on this function. Of course, given that for it to work you need:

• The client OS (the one with which the connection is made) was Windows XP SP3 and higher.
• The server OS (the one to which the connection will be made) was Windows Server 2008 and higher.

Note: Although Windows kernel Server 2003 is newer than XP (5.2 vs 5.1), Windows XP has an update that adds NLA support, but Windows Server 2003 does not. That is, even if you connect with the most available version– Windows Server 2003 R2 SP2 with all patches, you will not be able to connect to a server that requires NLA and be an NLA-enabled server. Alas.

How to enable NLA from the RDP server side

It is best to enable NLA on all servers through Group Policy. To do this, go to the target group policy object and there sequentially select “Computer Configuration” -> “Administrative Templates” -> “Windows Components” -> “Remote Desktop Session Host” -> “Security” and there enable the Require user authentication for parameter remote connections by using Network Layer Authentication.

You can also enable it locally. This is done by calling the Properties submenu (the standard submenu for Computer) and selecting the Remote tab there, in which there will be a choice of three options– prohibit RDP connections to this host, allow connections via any RDP, allow only NLA connections. Always enable the option with NLA, this primarily protects the server.

NLA and Windows XP

If you have Windows XP, you can also use this function. The common statement “NLA requires at least Vista, Microsoft did this to upgrade” is false. Service Pack 3 adds a CredSSP implementation that allows you to delegate client credentials held by a local SSP to the server. That is, to put it simply, this was specially done so that Windows XP can be connected to systems with NT 6.0+. It will not be possible to connect to Windows XP SP3 itself with this function; NLA support will be partial (therefore, make an RDP server that supports connecting clients using NLA from Windows XP in standard ways will not work, Windows XP will only be an NLA-compatible client).

Note: NLA appears with NT 6.0, and is part of a suite of technologies called RDP 6.0. The 3rd service pack for XP brings not just RDP 6.0, but the ability to install RDP 7.0, which is quite positive (for example, RDP 7.0, unlike 6.0, has EasyPrint, bidirectional audio and some other things that turn an RDP client on Windows XP with all the twists into a fairly practical system). This is about bad Microsoft, which so terribly forced everyone to upgrade from Windows XP to the bad, very bad Vista that they even included a newer RDP subsystem in the free service pack for the 2001 product than the one that came with Vista, released in 2006.

This functionality must be enabled explicitly, since despite the fact that Service Pack 3 adds new dll crypto provider, he does not include it.

How to enable CredSSP in XP

Once again - this operation is carried out strictly after Service installations Pack 3 on Windows XP and in the context of our conversation is needed in order to be able to connect to other servers via RDP 6.1 using NLA.

Step one - expand the list of Security Packages.
To do this we will open the registry key

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

and find the value Security Packages in it. Let's click right button and select “Modify” (not Modify Binary Data, but simply Modify). There will be a list like “package name on each line”. We need to add tspkg there. The rest should be left. The location of the addition is not critical.

The second step is to hook up the library.
The key will be different:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders

In it you will need to find the SecurityProviders value (note, as in the previous case, this is not a subkey, but a value), and modify it in the same way, only adding credssp.dll. The rest of the list, again, does not need to be touched.

You can now close the Registry Editor. After these operations, the system will need to be rebooted, because Crypto providers are a thing that definitely won’t get picked up on the go, and that’s more good than bad.

Choosing the right certificate for RDP

If you have the opportunity to use a non-default certificate for RDP, then it is better to use it. This will not affect the security of the session as such, but will affect the security and ease of connection. The certificate that is optimally used should contain the following points:

• A name (in subject or SAN) that matches character by character the name entered by the client connecting to the server.
• A normal CDP extension pointing to a working CRL (preferably at least two - OCSP and static).
• The desired key size is 2048 bits. More is possible, but remember the limitations of CAPI2 in XP/2003.
• Don't experiment with signature/hashing algorithms if you need connections from the XP/2003 side. There is a little more information about this in the article about setting up TLS, but in short - choose SHA-1, this is quite enough.

I’ll dwell in a little more detail on the issue of a special certificate for the RDP server.

We do everything beautifully - a special certificate template for RDP servers

It would be ideal if the certificate for RDP is made not based on a regular template (such as Web Server) and has in the Application Policy field (which in the certificate will be more commonly called Enchanced Key Usage - EKU) standard values ​​Client Authentication and Server Authentication, but add your own template , in which there will be a single, special application value that is not added by standard methods - Remote Desktop Authentication. This Application Policy value will have to be created manually, its OID will be 1.3.6.1.4.1.311.54.1.2, and then you can do it new template certificate, on the basis of which to issue a certificate specifically tailored for RDP Server.

To fully automate this operation, give the new template a predictable name - for example, “RDPServerCert” - and go to the GPO, and there open Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security. Select the Server Authentication Certificate Template option and enable it, and in the value field enter the name - we made RDPServerCert. Now all domain hosts that fall under this policy will, if RDP is enabled on them, go to the Certification Authority, request a certificate based on the specified template if they do not have it, and automatically make it default to protect RDP connections. Simple, convenient, effective.

Blocking connections via RDP accounts with an empty password

It’s a small thing, but you don’t need to forget about it.
To block the connection of accounts without passwords to RDP, you need to go to the GPO settings: Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options and set “Accounts: Limit local account use of blank passwords to console logon only ” in Enabled. Take the time to check that this is true.

Setting up an ACL for connecting via RDP

By default, you must have explicit User Access or Guest Access permission to connect to an RDP server.
This permission is available to local groups Administrators and Remote Desktop Users. It is best to use the Remote Desktop Users group to control access to the RDP server, adding the necessary domain groups to it, rather than individual users. Modify the contents of the Security tab in the Properties settings of RDP-Tcp only in extreme cases, best of all by adding the group “ hostname RDP Blocked”, which is explicitly denied RDP access to the specified node.

Optimizing RDP speed

Optimizing RDP speed is a fairly broad topic, so I'll break it down into parts. This will include methods that will reduce the load on the protocol before compression and before optimizing the network level.

Chroma (bit depth)

In RDP 7.0 and higher, 32, 16 and 8 bit options are available. If we are talking about work, then 16 bits will be enough for it. This will significantly reduce the load on the channel, sometimes more than 2 times, which is surprising, but true. 8 bit, of course, is also possible, but it will look too scary. 16 bits are quite acceptable.

Note: In Windows Server 2008 R2, 8-bit connections are no longer available.

Enable the Limit Maximum Color Depth parameter on the server, or do similar action in the RDP client settings.

Disable ClearType

When ClearType is turned off, the RDP protocol does not transmit a picture, but commands for drawing characters. When enabled, it renders an image from the server side, compresses it and sends it to the client. This is guaranteed to be much less efficient, so disabling ClearType will significantly speed up the work process and reduce response time. You'll be surprised how much.

This can be done both at the client settings level and on the server side (the Do not allow font smoothing parameter in the Remote Session Environment section in Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host).

Remove wallpaper

The Enforce removal of RD Wallpaper option in the Remote Session Environment section in Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host will dramatically improve the situation with redrawing the terminal session screen. Users without cats survive normally on the desktop, verified.

Enable and configure image caching

If the client has enough RAM, then it makes sense to enable and configure bitmap caching. This will allow you to win up to 20-50% of bandwidth. To install you will need to enter the key

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server Client\

and create the BitmapPersistCacheSize and BitmapCacheSize parameters there, both DWORD 32 types.
The BitmapPersistCacheSize parameter indicates the size in kilobytes disk cache. The default value is 10. It makes sense to increase this parameter to at least 1000.
The BitmapCacheSize parameter indicates the size in kilobytes of the cache in RAM. The default value is 1500. It makes sense to increase this parameter to at least 5000. This will be only 5 megabytes per client session, with modern scales of RAM this is insignificant, and even if it leads to a gain of 10% in performance, it will already pay for itself. By the way, the same parameter can be corrected in the .rdp file; If you save your RDP connection and then open the file with Notepad, then among the parameters you can add something like bitmapcachesize:i:5000, where 5000 is 5MB of cache.

Disable Desktop Composition

Desktop Composition brings all sorts of “beauties” like Aero and its friends and significantly eats up bandwidth. This is not necessary for work and is harmful. The Allow desktop composition for RDP Sessions parameter in the Remote Session Environment section in Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host must be set to Disabled.

Optimizing Desktop Window Manager parameters

The settings found in the Remote Session Environment section in Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Desktop Window Manager will control the “beautiful” display of sliding menus and the like. There are three of them - Do not allow window animations, Do not allow desktop compositions and Do not allow Flip3D invocation. All of them must be switched to Enabled mode, i.e. in essence, disable all these functions.

Disable redirection of unused devices

If you do not plan to connect certain classes of devices (for example, COM and LPT ports), or audio, it makes sense to disable the ability to redirect them from the server side. So that clients with default RDP Client settings do not waste connection time negotiating unused functionality. This is done in the same place as the rest of the server settings, in Properties for RDP-Tcp, Client Settings tab (in the same place where we made the color depth settings), Redirection section.

Setting up the general logic for optimizing RDP visual data

A setting called Optimize visual experience for RDP sessions, found under Remote Session Environment in Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Remote Session Environment, will control how , how RDP will perceive visual data - as multimedia or as text. This, roughly speaking, is a “hint” to the compression algorithm on how to behave more competently. Accordingly, to work you will need to set this parameter to Text , and if you want a lot of beautiful flash banners, HTML5 and view video clips - better option Rich Multimedia.

RDP compression optimization

Compression in RDP has passed long haul development. According to RDP 5.2, inclusive, there was a compression subsystem (“compressor”), internally called “Version 1” - the simplest and easiest option in terms of client processor load, but the worst in terms of network traffic load. In RDP 6.0 they made “Version 2”, which was slightly improved in terms of compression efficiency. We are interested in “Version 3”, which only works when connected to Windows servers Server 2008 and older. It compresses better than anyone, and the cost of CPU time is insignificant considering the power of modern computers.

The gain when turning on V3 can, judging by tests, reach 60% and, in general, is noticeable to the eye even without tests.

How to enable optimal compression in RDP

This is a client setting. Open Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Remote Session Environment in the desired GPO, select there Set parameter compression algorithm for RDP data, enable it and select Optimize to use less network bandwidth.

Note: Many people wonder why there is a “disable compression” option in the list. This is necessary in case your RDP sessions are compressed external device, optimizing WAN connections, something like Cisco WAAS. In other cases, of course, there is no point in disabling compression.

Setting audio compression

RDP 7.0 brings an excellent opportunity to regulate the quality of compression of the incoming audio stream (i.e., the sound that goes from the server to the client). This is quite useful - for example, if you are working on a terminal server, then apart from all sorts of service sounds like “a message has arrived in ICQ,” others are not particularly planned. There is no point in transmitting uncompressed CD-quality audio from the server if it is not necessary for work. Accordingly, you need to adjust the compression level of the audio stream.
This parameter will be called Limit audio playback quality and will be located in the Device and Resource Redirection section in Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host. There will be three options:

• High – the sound will come without compression. At all. That is, it will fall under the general compression of the RDP protocol, but specific audio compression (with loss of quality) will not be performed.
• Medium – compression will adapt to the channel so as not to increase the delay during data transmission.
• Dynamic – compression will dynamically adapt to the channel so that the delay does not exceed 150ms.

Choose the one that suits you. As is clear, for office work It's better to choose Dynamic.

Optimizing the ratio of data streams in RDP

RDP session traffic is not something monolithic. On the contrary, it is quite clearly divided into data streams of redirected devices (for example, copying a file from localhost to the terminal server), audio stream, rendering primitive command stream (RDP tries to transmit rendering primitive commands, and transmits bitmaps as a last resort), as well as input device streams (mouse and keyboard).

The mutual relationship of these flows and the logic of its (ratio) calculation (a kind of local QoS) can be influenced. To do this, you need to go to the registry key from the server side

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TermDD

and create there first (if they are not there) four keys:

• FlowControlDisable
• FlowControlDisplayBandwidth
• FlowControlChannelBandwidth
• FlowControlChargePostCompression

The type for all is DWORD 32. The functionality of the keys will be as follows.
The FlowControlDisable key will determine whether prioritization is used at all. If you set one, then priority will be turned off, if zero, then priority will be turned on. Turn it on.
The FlowControlDisplayBandwidth and FlowControlChannelBandwidth keys will determine the relative relationship of the two data streams:

• User interaction flow (image+input devices)
• Other data (block devices, clipboard and everything else)

The values ​​of these keys themselves are not critical; what is critical is how they relate. That is, if you make FlowControlDisplayBandwidth equal to one, and FlowControlChannelBandwidth is set to four, then the ratio will be 1:4, and 20% of the bandwidth will be allocated to the user interaction flow and 80% to the rest. If you do 15 and 60, the result will be identical, since the ratio is the same.
The FlowControlChargePostCompression key will determine when this ratio is calculated - before or after compression. Zero is before compression, one is after.

I recommend that to use the form “our remote server is far away and everyone connects to it via RDP and works in the office and 1C”, set the ratio to 1:1 and calculate it after compression. From experience, this can really help in the situation of “printing a large document from a terminal server to local printer" But this is not a dogma - try it, you already have the main tool - knowledge of how it is calculated and works.

Enable Require secure RPC communication for RDP

This setting operates similarly to the settings for Secure RPC, which are in the Security section of Group Policy and apply to the entire system, only it is easier to configure. By enabling this parameter, you will make it mandatory for all client RPC requests to encrypt (depending on the system settings, the “lower bar” of encryption will be different - RC4/DES or, if FIPS-140 is enabled - 3DES/AES) and use at least NTLMv2 for authentication remote procedure call. Always enable this option. There is a myth that it does not work in a non-domain environment. This is not true, and strengthening RPC security will not hurt anyone.

This is a server setting. Open Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security in the desired GPO, select the Require secure RPC communication option there and enable it.

Conclusion

Since everyone has long moved servers to external sites over the hill, this material is I hope that this material will be useful to you for optimizing and protecting RDP. If I missed something, please comment.