Клиенты rdp в ос windows xp

Использование network-level authentication

До появления Windows 2008/2008 R2, для аутентификации в службе терминалов пользователи должны были использовать Remote Desktop Client для установки связи с терминальным сервером. После чего у пользователя появлялась возможность ввода учетных данных  в окно входа. Такой подход к аутентификации пользователя выглядит довольно простым, в то же время с точки зрения безопасности является существенным риском.

Простота, с которой устанавливается терминальная сессия, позволяет получить определенную информацию о сети, например имя внутреннего домена, название конечного сервера. Полученная информация может помочь злоумышленнику осуществить DDOS атаку на терминальный сервер даже если атакующий не имеет в своем распоряжении данных для аутентификации.

Начиная с Windows 2008, Microsoft вводит дополнительный уровень защиты — network-level authentication. Этот уровень предполагает, что пользователь представляет определенный набор данных до установки сеанса подключения, что делает процесс аутентификации более безопасным.

Для использования network-level authentication необходимо выполнение ряда условий. Терминальный сервер должен работать под управлением операционной системы Windows 2008/2008 R2, а клиентские компьютеры должны  работать на ОС Windows XP Service Pack 3 или выше, Windows Vista или Windows 7. Для Windows XP может потребоваться редактирование реестра:

1. Кликните «Пуск», «Выполнить», введите в строку «regedit» (без кавычек) и нажмите «Ok»

2. В левой навигационной панеле откройте ключ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

3. В правой панеле найдите параметр «Security Packages», нажмите на нём правой кнопкой мыши и выберите «изменить»

4. В поле «значение» допишите внизу строчку «tspkg» (без кавычек). Не удаляйте имеющиеся значения. Нажмите «Ok»

5. В левой навигационной панеле откройте ключ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders

6. В правой панеле найдите параметр «SecurityProviders», нажмите на нём правой кнопкой мыши и выберите «изменить»

7. В поле «значение» допишите через запятую строчку «credssp.dll» (без кавычек). Не удаляйте имеющиеся значения. Нажмите «Ok» 8. Перезагрузите компьютер

Еще одним условием является использование Remote Desktop клиента версии 6 или выше.

Существует несколько способов конфигурации терминального сервера на требование использовать network-level authentication. Вы можете включить Network Level Authentication в процессе установки роли Terminal Services, или после ее завершения, используя консоль Terminal Services Configuration. Щелкнув правой кнопкой мыши на подключении, используемом вашими клиентами. В меню выбрать  Properties и опцию «Allow connections only from computers running Remote Desktop with Network Level Authentication».

Однако, наилучший способ включить network-level authentication, это использовать групповую политику. Запустите редактор групповой политики, выберите нужную политику. Откройте раздел Computer Configuration | Administrative Templates | Windows Components | Terminal Services | Terminal Server | Security и включите параметр Require user authentication for remote connections by using Network Level Authentication.

Solution #4: Turn off NLA using PowerShell

To turn off or disable Network Level Authentication with the help of Windows PowerShell, you need the remote computer name. Otherwise, this is not possible to get started with this method. If you have collected that, go ahead and follow these steps.

  • Open Windows 11 PowerShell with administrator privilege. For that, search for ‘powershell’ in the Cortana search box > right-click on the corresponding result > select Run as administrator.
  • Enter the following commands one after one-
    $TargetMachine = “remote-computer-name”
    
    (Get-WmiObject -class “Win32_TSGeneralSetting” -Namespace root\cimv2\terminalservices -ComputerName $TargetMachine -Filter “TerminalName=’RDP-tcp'”).SetUserAuthenticationRequired(0)

    Do not forget to replace the remote-computer-name with the actual name.

  • Restart computer.

Here is a list of powershell commands to uninstall and reinstall built-in Windows system core apps of your choice.

Solution #2: Disable NLA using Group Policy Editor

You can disable the Network Level Authentication with the help of Group Policy Editor. This is much more user-friendly, and you do not need any expert knowledge to get it done. The only drawback is you cannot get Local Group Policy Editor on Windows 10/11 Home version. Even if you sideload Group Policy Editor, you might not get the similar option in that third-party app. Therefore, this method is applicable to Windows 10/11 Pro and Enterprise users only.

  • Open Local Group Policy Editor. You can search for it in the Taskbar search box. Or you can enter gpedit.msc in the Run prompt.
  • After opening it, navigate to this path-
    Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security
  • On your right-hand side, you should find a setting named Require user authentication for remote connections by using Network Level Authentication. Double-click on this setting to open the Properties.
  • Make sure the Disabled is selected. If not, do choose that option and click the OK button to save your change.

Изменение номера порта RDP

По умолчанию терминальный сервер использует порт 3389 для RDP подключения. Изменение номера порта RDP служит одним из самых эффективных способов защиты от хакеров.

Смена номера порта требует внесения изменений в реестр. Настоятельно рекомендуется сделать резервную копию до внесения изменений.

Выберите новое желаемое значение номера порта. Затем получите его значение в шестнадцатеричном коде, для этого можно использовать калькулятор Windows.

Запустите редактор реестра перейдите к ветке HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Terminal Server\WinStations\RDP-TCP.

Внесите свое шестнадцатеричное значение в раздел Port Number.

После того как вы внесли изменение в номер порта RDP на сервере, вам необходимо создать новое подключение на клиентском компьютере, используя новое значение порта RDP.  Для этого при настройке подключения необходимо указать порт, например 111.222.333.444:123456, где 111.222.333.444 – IP адрес сервера, 123456 – номер порта RDP.

В заключении отметим, считается, что использование Windows Terminal Services относительно безопасно, есть возможность значительно повысить безопасность, используя описанные выше шаги.

Solution #1: Tweak Remote Desktop security settings

By default, your Windows 11 machine allows connections only from computers that have Network Level Authentication. This inbuilt security function lets you block all the unwanted connections when you have a large local area network, and your computer is open for share. You can change the network location from public to private and vice versa as per your requirement. However, the same settings can cause the issue as mentioned earlier. Therefore, you can try to disable this option and check if the problem remains or not. Following the following steps to allow connections without NLA.

  • Open This PC on your computer.
  • Right-click on empty space and select Properties.
  • On your right-hand side, you should find an option called Advanced system settings. You need to click on this option.
  • Switch from Advanced tab to Remote
  • Alternatively, you can press Win + R, type sysdm.cpl and hit the Enter button.
  • Make sure Allow remote connections to this computer option is selected. If not do choose this option and remove the tick from the checkbox called Allow connections only from computers running Remote Desktop with Network Level Authentication.
  • Click the Apply and OK buttons to save your change.

After that, try to connect to the remote computer.

Самый правильный метод, это установка обновлений

Когда вам удалось везде подключиться и подошло время обслуживания ваших серверов, быстренько производим установку обновлений закрывающих брешь (CVE-2018-0886 | CredSSP Remote Code Execution Vulnerability).

  • Windows Server 2012 R2 / Windows 8: KB4103715
  • Windows Server 2008 R2 / Windows 7: KB4103712
  • Windows Server 2016 / Windows 10 1607 — KB4103723
  • Windows Server 2016 / Windows 10 1703 — KB4103731
  • Windows Server 2016 / Windows 10 1709 — KB4103727
  • Windows Server 2016 / Windows 10 1803 — KB4103721

13 марта Microsoft опубликовал описание уязвимости CVE-2018-0886 в протоколе проверки подлинности CredSSP, который в частности используется при подключении по RDP к терминальным серверам. Позже Microsoft опубликовал, что будет блокировать подключения к необновлённым серверам, где присутствует данная уязвимость. В связи с чем многие заказчики столкнулись с проблемами подключения по RDP.

В частности, в Windows 7 можно увидеть ошибку: «Произошла ошибка проверки подлинности. Указанная функция не поддерживается«

В Windows 10 ошибка расписана более подробно, в частности сказано «Причиной ошибки может быть исправление шифрования CredSSP»:

Для обхода ошибки со стороны клиента многие советуют отключить групповую политику, путём установки значения Encryption Oracle Remediation в Vulnerable: с помощью gpedit.msc в Конфигурация компьютера / Административные шаблоны / Система / Передача учётных данных, слева выбрать «Исправление уязвимости шифрующего оракула» (забавный конечно перевод), в настройках поставить «Включено» и выбрать «Оставить уязвимость».

или через реестр (т.к., например, в Windows Home нет команды gpedit.msc):

REG ADD HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2

НО! Так делать не нужно! Т.к. таким образом вы оставляете уязвимость и риски перехвата вашего трафика и пр. конфиденциальные данные, включая пароли. Единственный случай, когда это может быть необходимо, это когда у вас вообще нет другой возможности подключиться к удалённому серверу, кроме как по RDP, чтобы установить обновления (хотя у любого облачного провайдера должна быть возможность подключения к консоли сервера). Сразу после установки обновлений, политики нужно вернуть в исходное состояние.

Если доступ к удалённому серверу есть, то ещё, как временная мера, можно отключить требование NLA (Network Level Authentication), и сервер перестанет использовать CredSSP. Для этого достаточно в Свойствах системы, на вкладке удалённые подключения снять соответствующую галку «Разрешить подключения только с компьютеров, на которых работает удалённый рабочий стол с проверкой подлинности на уровне сети«:

Но, это тоже неправильный подход.

Правильный подход — это всего-лишь установить нужные обновления на операционную систему, закрывающие уязвимость CVE-2018-0886 в CredSSP, причём, как серверную, куда вы подключаетесь, так и клиентскую, с которой вы подключаетесь.

Solution #3: Disable Network Level Authentication using Registry Editor

Network Level Authentication can be blocked via Registry Editor as well. However, you need to do that on the remote computer. This is quite easy when your host computer is connected to the remote computer via Local Area Network. In any case, if your Windows registry editor is disabled accidentally or by the syatem administartor, first enable the Windows registry editor. The advantage of this method is you can get Registry Editor on any version of Windows 11/10/8/7.

  • Open Registry Editor. You can either search for it in the Taskbar search box, or you can enter regedit in the Run prompt.
  • Go to File > Connect Network Registry.
  • Enter the name of the remote computer and click the Check Names You should find the remote computer’s Registry Editor on your host computer.
  • After opening Registry Editor of the remote computer, navigate to this path-
    HKEY_LOCAL_MACHINE  >SYSTEM > CurrentControlSet > Control  >Terminal Server > WinStations > RDP-Tcp
  • Here you can find two keys i.e. SecurityLayer and UserAuthentication. Open one after one and set the value to zero(0).
  • After that, open PowerShell and enter this command-
restart-computer

After that, if you can connect to the remote computer via Remote Desktop.

Причины ошибки шифрования CredSSP

В марте 2018 года, компания Microsoft выпустила обновление безопасности для устранения уязвимостей для протокола поставщика поддержки безопасности учетных данных (CredSSP) под именем CVE-2018–0886 (https://support.microsoft.com/en-us/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018), используемого подключениями по протоколу удаленного рабочего стола (RDP) для клиентов Windows и Windows Server. Как только пользователи и системные администраторы произвели установку апдейтов, то по всему миру начались массовые жалобы, что люди не могут подключаться по протоколу RDP к серверам, компьютерам, получая ошибку, что причиной ошибки может быть шифрование CredSSP.

К сожалению 99% людей и администраторов совершают одну и туже ошибку, они сразу ставят обновления, не дождавшись пары дней после их выхода. Обычно этого времени хватает, чтобы вендор определил проблемы и отозвал глючное обновление.

Под раздачу попали буквально все, клиентские ОС Windows 7, Windows 8.1, Windows 10 с которых были попытки подключиться к RDS ферме или RemoteApp приложениям работающим на Windows Server 2008 R2 и выше. Если бы вы читали ветки обсуждений в эти дни, то вы бы поняли все негодование людей, особенно с запада.

Назначение CredSSP

Что такое CredSSP — это Win32 API, используемый системами Microsoft Windows для выполнения различных операций, связанных с безопасностью, таких как аутентификация. SSPI функционирует, как общий интерфейс для нескольких поставщиков поддержки безопасности (SSP). Поставщик поддержки безопасности — это библиотека динамической компоновки (DLL), которая делает один или несколько пакетов безопасности доступными для приложений.

C redSSP позволяет приложению делегировать учетные данные пользователя от клиента целевому серверу для удаленной аутентификации. CredSSP предоставляет зашифрованный канал протокола безопасности транспортного уровня . Клиент проходит проверку подлинности по зашифрованному каналу с использованием протокола SPNEGO (Simple and Protected Negotiate) с Microsoft Kerberos или Microsoft NTLM.

После проверки подлинности клиента и сервера клиент передает учетные данные пользователя на сервер. Учетные данные дважды шифруются с использованием ключей сеанса SPNEGO и TLS. CredSSP поддерживает вход в систему на основе пароля, а также вход в систему с использованием смарт-карт на основе X.509 и PKINIT.

Windows SSP

Следующие поставщики общих служб устанавливаются вместе с Windows:

  • NTLM (Представлено в Windows NT 3.51 ) (msv1_0.dll) — обеспечивает проверку подлинности NTLM с запросом/ответом для клиент-серверных доменов до Windows 2000 и для не доменной аутентификации (SMB /CIFS).
  • Kerberos (Представлен в Windows 2000 и обновлен в Windows Vista для поддержки AES ) (kerberos.dll). Предпочтителен для взаимной аутентификации клиент-серверного домена в Windows 2000 и более поздних версиях.
  • Согласование (введено в Windows 2000) (secur32.dll) — выбирает Kerberos и, если не доступно, протокол NTLM. SSP обеспечивает возможность единого входа , иногда называемую встроенной аутентификацией Windows (особенно в контексте IIS). В Windows 7 и более поздних версиях представлен NEGOExts, в котором согласовывается использование установленных пользовательских SSP, которые поддерживаются на клиенте и сервере для аутентификации.
  • Безопасный канал (он же SChannel) — Представлен в Windows 2000 и обновлен в Windows Vista и выше для поддержки более надежного шифрования AES и ECC. Этот поставщик использует записи SSL/TLS для шифрования полезных данных. (Schannel.dll)
  • PCT (устарел) реализация Microsoft TLS/SSL — криптография SSP с открытым ключом, которая обеспечивает шифрование и безопасную связь для аутентификации клиентов и серверов через Интернет. Обновлено в Windows 7 для поддержки TLS 1.2.
  • Digest SSP (Представлено в Windows XP ) (wdigest.dll) — Обеспечивает проверку подлинности HTTP и SASL на основе запросов/ответов между системами Windows и не-Windows, где Kerberos недоступен.
  • Учетные данные (CredSSP) (Представлено в Windows Vista и доступно в Windows XP с пакетом обновления 3 (SP3)) (credssp.dll) — обеспечивает SSO и проверку подлинности на уровне сети для служб удаленных рабочих столов.
  • Аутентификация с распределенным паролем (DPA) — (Представлено в Windows 2000) (msapsspc.dll) — Обеспечивает аутентификацию через Интернет с использованием цифровых сертификатов.
  • Криптография с открытым ключом «пользователь-пользователь» (PKU2U) (представлена ​​в Windows 7 ) (pku2u.dll) — обеспечивает одноранговую аутентификацию с использованием цифровых сертификатов между системами, которые не являются частью домена.
Рейтинг
( Пока оценок нет )
Понравилась статья? Поделиться с друзьями:
Ваша ОС
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: