Русский
Русский
English
Статистика
Реклама

Rdp

Как убрать назойливое предупреждение о сертификате для RDP

02.07.2020 12:23:15 | Автор: admin

Привет Хабр, это супер короткое и простое руководство для новичков о том, как подключаться по RDP по доменному имени, чтобы не вылезало назойливое предупреждение о сертификате, подписанным самим сервером. Нам понадобится WinAcme и домен.

Все, кто хоть раз пользовался RDP, видели эту надпись.


В руководстве приведены готовые команды для пущего удобства. Скопировал, вставил и заработало.

Так вот, это окно можно в принципе пропустить, если выдать сертификат подписанный сторонним, трастовым центром сертификации. В данном случае, Lets Encrypt.

1. Добавляем А запись




Просто добавляем A запись и вписываем в неё IP адрес сервера. На этом работа с доменом окончена.

2. Качаем WinAcme


Качаем WinAcme с их сайта. Архив лучше всего распаковать туда, куда вы не доберетесь, исполняемые файлы и скрипты вам еще пригодятся в будущем для автоматического обновления сертификата. Лучше всего вытряхнуть архив в C:\WinAcme\.

3. Открываем 80 порт




Авторизация вашего сервера осуществляется по http, поэтому нам нужно открыть 80 порт. Для этого введите в Powershell команду:

New-NetFirewallRule -DisplayName 80-TCP-IN -Direction Inbound -Protocol TCP -Enabled True -LocalPort 80

4. Разрешаем выполнение скриптов


Чтобы WinAcme смог без проблем импортировать новый сертификат, нужно разрешить выполнение скриптов. Для этого переходив в папку /Scripts/



Перед запуском WinAcme нам нужно разрешить выполнение двух скриптов. Для этого двойным кликом запустите PSRDSCerts.bat из папки со скриптами.

5. Устанавливаем сертификат




Дальше скопируйте строку ниже и введите имя домена, по которому хотите подключатсяь к серверу и выполните команду.

C:\Winacme\wacs.exe --target manual --host VASHDOMAIN.RU --certificatestore My --installation script --installationsiteid 1 --script "Scripts\ImportRDListener.ps1" --scriptparameters "{CertThumbprint}"

После этого сертификат подписывающий домен встанет на место старого. Обновлять вручную ничего не нужно, через 60 дней программа продлит сертификат сама.

Готово! Вы великолепны и избавились от надоедливой ошибки.

А какие системные ошибки раздражают вас?

Подробнее..

VPS на Linux с графическим интерфейсом запускаем сервер RDP на Ubuntu 18.04

29.07.2020 12:21:28 | Автор: admin

В предыдущей статье мы разобрали запуск сервера VNC на виртуальной машине любого типа. У этого варианта масса недостатков, основным из которых являются высокие требования к пропускной способности каналов передачи данных. Сегодня мы попробуем подключиться к графическому рабочему столу на Linux по RDP (Remote Desktop Protocol). Система VNC основана на передаче массивов пикселей по протоколу RFB (Remote Framebuffer), а RDP позволяет отправлять более сложные графические примитивы и высокоуровневые команды. Обычно он используется для организации служб удаленных рабочих столов в Windows, но серверы для Linux также доступны.

Оглавление:


Установка графического окружения
Русификация сервера и установка ПО
Установка и настройка сервера RDP
Настройка межсетевого экрана
Подключение к серверу RDP
Менеджер сессий и сеансы пользователей
Переключение раскладок клавиатуры

Установка графического окружения


Мы возьмем виртуальную машину с Ubuntu Server 18.04 LTS с двумя вычислительными ядрами, четырьмя гигабайтами оперативной памяти и жестким диском (HDD) на двадцать гигабайт. Более слабая конфигурация плохо подходит для графического десктопа, хотя это зависит от решаемых задач. Не забывайте использовать промокод Habrahabr10 для получения скидки в 10% при заказе.



Установка окружения рабочего стола со всеми зависимостями выполняется следующей командой:

sudo apt-get install xfce4 xfce4-goodies xorg dbus-x11 x11-xserver-utils

Как и в предыдущем случае, мы выбрали XFCE из-за относительно невысоких требований к вычислительным ресурсам.

Русификация сервера и установка ПО


Часто виртуальные машины разворачиваются только с английской локализацией. На десктопе может потребоваться русская, настроить которую несложно. Сначала установим переводы для системных программ:

sudo apt-get install language-pack-ru

Настроим локализацию:

sudo update-locale LANG=ru_RU.UTF-8

Того же эффекта можно достичь, отредактировав вручную файл /etc/default/locale.

Для локализации GNOME и KDE в репозитории есть пакеты language-pack-gnome-ru и language-pack-kde-ru они понадобятся, если вы будете использовать программы из этих сред рабочего стола. В XFCE переводы устанавливаются вместе с приложениями. Дальше можно инсталлировать словари:

# Словари для проверки орфографииsudo apt-get install hunspell hunspell-ru# Тезаурус для LibreOfficesudo apt-get install mythes-ru# Англо-русский словарь в формате DICTsudo apt-get install mueller7-dict

Кроме того, инсталляция переводов может потребоваться для некоторых прикладных программ:

# Браузер Firefoxsudo apt-get install firefox firefox-locale-ru# Почтовый клиент Thunderbirdsudo apt-get install thunderbird thunderbird-locale-ru# Офисный пакет LibreOfficesudo apt-get install libreoffice libreoffice-l10n-ru libreoffice-help-ru

На этом подготовка окружения рабочего стола завершена, осталось настроить сервер RDP.

Установка и настройка сервера RDP


В репозиториях Ubuntu есть распространяемый свободно сервер Xrdp, которым мы и воспользуемся:

sudo apt-get install xrdp

Если все прошло нормально, сервер должен запуститься автоматически:

sudo systemctl status xrdp



Сервер Xrdp запускается с правами пользователя xrdp и по умолчанию берет ертификат /etc/ssl/private/ssl-cert-snakeoil.key, который можно заменить собственным. Для доступа на чтение файла нужно добавить пользователя в группу ssl-cert:

sudo adduser xrdp ssl-cert

Настройки по умолчанию можно найти в файле /etc/default/xrdp, а все прочие конфигурационные файлы сервера лежат в каталоге /etc/xrdp. Основные параметры находятся в файле xrdp.ini, который можно не менять. Конфиг хорошо документирован, к тому же в комплекте имеется соответствующие manpages:

man xrdp.ini
man xrdp

Осталось только отредактировать скрипт /etc/xrdp/startwm.sh, который исполняется при инициализации пользовательской сессии. Предварительно сделаем резервную копию скрипта из дистрибутива:

sudo mv /etc/xrdp/startwm.sh /etc/xrdp/startwm.bsudo nano /etc/xrdp/startwm.sh

Чтобы запустить окружение рабочего стола XFCE, потребуется сценарий примерно такого содержания:

#!/bin/shif [ -r /etc/default/locale ]; then. /etc/default/localeexport LANG LANGUAGEfiexec /usr/bin/startxfce4

Обратите внимание: в скриптах лучше прописывать полный путь к исполняемым файлам это хорошая привычка. Сделаем скрипт исполняемым и на этом настройку сервера Xrdp можно считать законченной:

sudo chmod 755 /etc/xrdp/startwm.sh

Перезапускаем сервер:

sudo systemctl restart xrdp

Настройка межсетевого экрана


По умолчанию Xrdp слушает TCP-порт 3389 на всех интерфейсах. В зависимости от конфигурации виртуального сервера может потребоваться настройка межсетевого экрана Netfilter. В Linux это обычно делается с помощью утилиты iptables, но в Ubuntu лучше использовать ufw. Если IP-адрес клиента известен, настройка осуществляется следующей командой:

sudo ufw allow from IP_Address to any port 3389

Разрешить соединения с любого IP можно так:

sudo ufw allow 3389

Протокол RDP поддерживает шифрование, но открывать доступ к серверу Xrdp из сетей общего пользования плохая идея. Если у клиента нет фиксированного IP, для повышения уровня безопасности сервер должен слушать только localhost. Доступ к нему лучше настроить через туннель SSH, который безопасно перенаправит трафик с клиентского компьютера. Аналогичный подход мы использовали в предыдущей статье для сервера VNC.

Подключение к серверу RDP


Для работы с окружением рабочего стола лучше создать отдельного непривилегированного пользователя:

sudo adduser rdpuser



Добавим пользователя в группу sudo, чтобы он мог решать связанные с администрированием задачи. Если такой потребности нет, этот шаг можно пропустить:

sudo gpasswd -a rdpuser sudo

Подключиться к серверу можно с помощью любого клиента RDP, включая встроенный клиент службы удаленных рабочих столов Windows. Если Xrdp слушает внешний интерфейс, никаких дополнительных телодвижений не понадобится. Достаточно указать в настройках соединения IP-адрес VPS, имя пользователя и пароль. После подключения мы увидим примерно такую картину:



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



Если сервер Xrdp слушает только localhost, на клиентском компьютере трафик придется упаковать в туннель SSH (на VPS должен быть запущен sshd). Под Windows можно использовать графический клиент SSH (например, PuTTY), а в UNIX-системах нужна утилита ssh:

ssh -L 3389:127.0.0.1:3389 -C -N -l rdpuser RDP_server_ip

После инициализации туннеля клиент RDP будет подключаться уже не к удаленному серверу, а к локальному хосту.

После инициализации туннеля клиент RDP будет подключаться уже не к удаленному серверу, а к локальному хосту.

С мобильными устройствами сложнее: способные поднять туннель клиенты SSH придется покупать, к тому же в iOS и iPadOS фоновая работа сторонних приложений затруднена из-за слишком хорошей оптимизации энергопотребления. На iPhone и iPad поднять туннель в отдельном приложении не получится потребуется приложение-комбайн, которое само умеет устанавливать соединение RDP через SSH. Такое, например, как Remoter Pro.

Менеджер сессий и сеансы пользователей


Возможность многопользовательской работы реализована непосредственно в сервере Xrdp и не требует дополнительной настройки. После запуска сервиса через systemd один процесс работает в режиме демона, слушает порт 3389 и взаимодействует через localhost с менеджером сессий.

ps aux |grep xrdp



sudo netstat -ap |grep xrdp



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



Автоматический запуск менеджера сессий прописан в файле /etc/default/xrdp, а конфигурация хранится в /etc/xrdp/sesman.ini. По умолчанию выглядит она примерно так:

Globals]ListenAddress=127.0.0.1ListenPort=3350EnableUserWindowManager=trueUserWindowManager=startwm.shDefaultWindowManager=startwm.sh[Security]AllowRootLogin=trueMaxLoginRetry=4TerminalServerUsers=tsusersTerminalServerAdmins=tsadmins; When AlwaysGroupCheck=false access will be permitted; if the group TerminalServerUsers is not defined.AlwaysGroupCheck=false[Sessions]

Здесь можно ничего не менять, стоит только запретить вход с правами root (AllowRootLogin=false). Для каждого авторизовавшегося в системе пользователя запускается отдельный процесс xrdp: если отсоединиться не завершив сеанс, пользовательские процессы по умолчанию продолжат работать. Настройки можно изменить в файле /etc/xrdp/sesman.ini (секция [Sessions]).

Переключение раскладок клавиатуры


С двухсторонним буфером обмена проблем обычно не возникает, а вот с русской раскладкой клавиатуры придется немного пошаманить (русская локаль должна быть уже установлена). Отредактируем клавиатурные настройки сервера Xrdp:

sudo nano /etc/xrdp/xrdp_keyboard.ini

В конец конфигурационного файла нужно добавить следующие строки:

rdp_keyboard_ru]keyboard_type=4keyboard_type=7keyboard_subtype=1model=pc105options=grp:alt_shift_togglerdp_layouts=default_rdp_layoutslayouts_map=layouts_map_ru[layouts_map_ru]rdp_layout_us=us,rurdp_layout_ru=us,ru

Остается сохранить файл и перезапустить Xrdp:

sudo systemctl restart xrdp

Как видите, поднять сервер RDP на линуксовом VPS несложно, а в предыдущей статье мы уже разобрали настройку VNC. Помимо этих технологий, есть еще один интересный вариант: использующая модифицированный протокол NX 3 система X2Go. С ней мы разберемся в следующей публикации.

Подробнее..

Защита RDP-подключения к VDSVPS в эпоху заслуженного киберпанка

31.08.2020 12:09:59 | Автор: admin


Пандемия вируса COVID-19 радикально изменила модель работы персонала множества организаций в добровольно-принудительном порядке, наградив большую его часть статусом дистанционный, а кое-кого, даже удалённый работник.

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

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

RDP наоборот


В 2018 году, в процессе исследований безопасности протокола удалённого рабочего стола, специалисты Check Point Research обнаружили множественные уязвимости в трёх популярных клиентах, предназначенных для работы с ним:

  • RDP-клиент от Microsoft / Mstsc.exe
  • rdesktop
  • FreeRDP

Всего было обнаружено 25 уязвимостей, среди которых были и критические, в том числе и те, что позволяют злоумышленнику изменить обычное направление связи и атаковать клиентский компьютер, то есть осуществить атаку с помощью обратного RDP-соединения (reverse RDP-attack).

В RDP-клиенте от Microsoft эта уязвимость таилась в общем буфере обмена между клиентом и сервером. Которая, при использовании буфера в процессе соединения, позволяла серверу с эксплойтом включать собственные файлы в инициированный пользователем процесс обмена. А функционалу атаки обхода пути (path traversal attack) определять конечным пунктом назначения для файла любое место в клиентском компьютере. Например, без лишних уведомлений отправить исполняемый файл (программу-майнер, шифровальщик) в папку автозагрузки компьютера пользователя, для его запуска при следующей перезагрузке системы.


Демонстрация уязвимости от Check Point Research

О факте чего и было сообщено компании Microsoft (MSRC) 16 октября 2018 года. В ответ на что,17 декабря 2018 года адресат ответил:

Thank you for your submission. We determined your finding is valid but does not meet our bar for servicing. For more information, please see the Microsoft Security Servicing Criteria for Windows (http://personeltest.ru/aways/aka.ms/windowscriteria).

Спасибо за подачу заявки. Мы определили, что ваша находка действительна, но не соответствует нашему уровню обслуживания. Дополнительные сведения см. в разделе Критерии обслуживания Microsoft для Windows (http://personeltest.ru/aways/aka.ms/windowscriteria).

В результате чего данная уязвимость не получила своего ID и патча для её исправления. источник

ГипеРДП


После публикации информации об этой уязвимости, сотрудники Check Point Research стали получать множество комментариев и вопросов, один из которых вызвал неподдельный интерес и побудил вернуться к дальнейшему исследованию и посмотреть на уязвимость под другим углом, а именно: может ли уязвимость RDP-клиента Microsoft быть использована в Microsoft Hyper-V?

В результате дальнейшего изучения выяснилось, что в основе GUI для управления ВМ Hyper-V manager, негласно используется технологии RDP, в расширенных сеансах которого, так же как и в свойствах удалённого рабочего стола есть возможность включения общего буфера обмена. И как следствие присутствует та же самая уязвимость!


Демонстрация уязвимости в Hyper-V от Check Point Research

Об этом сотрудники Check Point Research рассказали в своем блоге, а также на конференции Black Hat USA 2019.


Презентация уязвимости на Black Hat USA 2019

Ну и, конечно же, сообщили в MSRC. На этот раз Microsoft завела тикет и в октябре 2019 года выпустила патч для исправления этой уязвимости, получившей ID: CVE-2019-0887. источник

Неисповедимы пути


После анализа эффективности патча, когда эксперты Check Point Research собрались уже было присвоить уязвимости статус закрыта, к ним обратился пользователь Mac OS RDP Client, с информацией об особенностях поведения клиента после установки исправления от MS.

В процессе прототипирования модели RDP-соединения c использованием этого клиента, стало понятно, что в самом патче есть дыры в безопасности, которые позволяют обойти защиту и воссоздать первоначальный эксплойт. О чем и было сообщено MSRC.

В феврале 2020 года Microsoft собралась с силами и выпустила патч для исправления и этой уязвимости CVE-2020-0655, который, по словам экспертов Check Point Research, в полной мере так не решил проблему атаки обхода пути (path traversal attack), в частности, для Windows API. Оповещённая об этом косячке компания Microsoft пока эту ситуацию никак не прокомментировала. источник

И, что


Как может заметить проницательный читатель, для удачного проведения атаки такого типа необходим скомпрометированный RDP-сервер. А достать его можно тремя путями:

  • Создать свой и выдать его за легитимный
  • Получить доступ к существующему и скомпрометировать его
  • Гибридный

Относительно безопасным, оптимальным по затратам и скорости провижининга вариантом в сегодняшних реалиях будет завладеть арендуемым у сервис-провайдера облачным или VPS/VDS сервером. И тому есть три основные причины:

  • Каждый арендуемый виртуальный сервер под управлением Windows это уже RDP-сервер по-умолчанию
  • Каждый арендуемый виртуальный сервер под управлением Windows, как правило, уже имеет RDP-аккаунт с админскими правами и единым логином для всех пользователей.
  • Как правило, RDP-доступ к виртуальному серверу осуществляется через доступный на публичном IP-адресе TCP-порт: 3389.

Собственно этот торчащий наружу порт, наверно, та, самая красная тряпка для кибер-злоумышленника, желающего завладеть каким-нибудь виртуальным сервером, подобрав пароль к нему методом простого автоматизированного перебора. Или как его ещё называют брутфорс-атакой.

Для справки: Пример роста количества атак семейства Bruteforce.Generic.RDP, февраль апрель 2020 г. от Лаборатории Касперского.


источник

дальше


Для того чтобы не стать жертвой вышеописанных ситуаций, можно, конечно, менять параметры учётных записей и стандартные RDP-порты, блокировать неавторизованные попытки подключения с помощью брандмауэра Windows или сторонних программ типа IPBAN, использовать шифрование и сертификаты, и многое-многое другое. Но для меня самый простым и быстрым способом защиты RDP-подключения к вновь создаваемому серверу является разрешения RDP-доступа к нему только с узлов из доверенной сети.

В RUVDS для этого требуется три простых шага:

  • Объединить виртуальный сервер с компьютерами, которым необходим доступ к нему по RDP, виртуальной частной сетью. Я использую ZeroTier
  • Настроить нативный файрвол виртуального сервера:
    В настройках сервера во вкладке Сети кликаем настроить файрвол для публичных адресов.

    image

    И начинаем создавать правила:
    Первое запрещаем все внешние соединения
    Второе разрешаем соединения виртуальной сети. В данном случае ZeroTier.
    Третье разрешаем RDP-соединение только по адресу виртуального сервера в виртуальной сети. Принимаем изменения.
  • Установить успешное RDP-соединение по IP-адресу сервера внутри виртуальной сети согласно инструкции.

На этом хочу откланяться и советую следить за здоровьем RDP-подключения вашего виртуального сервера. Ибо, с момента CVE-2020-0655, появилось ещё с функционалом reverse RDP-attack.

Подробнее..

Как я искал нормальный RDP-клиент и нашел целых три

27.01.2021 16:20:11 | Автор: admin


Remote Desktop Protocol один из самых распространенных протоколов для удаленного управления, потому что он используется для работы с операционными системами Windows, которые часто незаменимы в корпоративной среде. Естественно, самый распространенный способ подключения к удаленной системе использование средств встроенных в саму систему, но он не единственный и, более того, совершенно неприменимый, если используется другая ОС или сильно устаревшая Windows.

В этой статье я расскажу о нескольких альтернативных решениях, отличных от встроенных в дистрибутивы операционных систем: программу MobaXterm и два сервиса не требующих от пользователя установки приложений и работающих в обычном браузере.


MobaXterm


Эта программа для Windows. Немного неправильно называть MobaXterm RDP-клиентом, потому что это целый комбайн. Список поддерживаемых протоколов впечатляет: SSH, Telnet, Rlogin, RDP, VNC, XDMCP, FTP, SFTP и Serial.

Почему я рекомендую этот клиент? Меня уже давно не радует Putty. Громоздкий и запутанный интерфейс из времен W95, не вызывающий ностальгию, если приходится часто с ним работать, плохая поддержка экранов высокого разрешения, собственный формат ключей, отсутствие поддержки вкладок и прочее. MobaXterm лишен всех этих недостатков, это удобная и современная программа. Портативная версия состоит из одного единственного exeшника и файла настроек, интерфейс интуитивный, а если нужна помощь, то, в отличии от Putty, в самой программе есть исчерпывающая документация.

Кроме соединения через перечисленные протоколы можно локально поднимать некоторые сервисы для удаленного доступа, такие как: FTP, SSH/SFTP, HTTP и другие. Если вы не любите консольные nano и vi, то в программе есть текстовый редактор с удобным графическим интерфейсом. В терминале есть настраиваемая подсветка синтаксиса и автодополнение.
Сразу после запуска программа нашла ранее используемые мной подключения, импортировала настройки из Putty и обнаружила установленную в системе WSL-Ubuntu:



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

Apache Guacamole




Современные тенденции DevOps предполагают перенос окружения для разработки с локальной машины на сервер компании или к облачному провайдеру. Один из простых примеров ранее описывался в статье: Установка Visual Studio Code в облаке, приложения для удаленного подключения этого тоже не избежали.

Apache Guacamole, это клиентский шлюз для удаленного подключения, работающий на HTML5, позволяет пользоваться протоколами: VNC, Telnet, RDP, Kubernetes и SSH / SFTP через web-интерфейс. Не требуется установки никаких программ, подписок на сторонние сервисы, все работает прямо в браузере, независимо от того, какой операционной системой пользуется разработчик. Все что требуется: установить и настроить службы на сервере. По сути, это web-интерфейс для FreeRDP бесплатной реализации протокола RDP, с открытым исходным кодом.

Сценарий работы с этим сервисом типичен для последних тенденций удаленной работы и оптимизации рабочего места. Разработчики подключаются к своему окружению из любой точки земного шара. Им не требуется держать дома мощный десктоп или носить с собой высокопроизводительный ноутбук, забота об этом перекладывается на серверы компании, а работнику достаточно подключения к интернету и любого ноутбука, на котором не будет лагать браузер.

Настройка сервиса подробнейшим образом документирована, мануал впечатляет своими размерами. Установка возможна несколькими способами: из репозиториев, компиляция исходников и разворачивание образа Docker. К счастью, как это часто бывает, один прошаренный DevOps-инженер решил автоматизировать процесс установки с наиболее типичными настройками и выложил готовый скрипт на github: guac-install. Из его кода легко понять, что он пошел по пути установки образа Docker, и все действия сводятся к вводу всего нескольких команд.

Начнем с того, что настроим виртуальный сервер для установки AG. Его характеристики будут зависеть от количества пользователей, но разработчики рекомендуют не меньше 2 гигабайт оперативной памяти. Размещение сервера выберем в Москве, для минимального пинга, что критично для работы с удаленными компьютерами.



В качестве тестовой машины я выбрал такие параметры :



После того, как будет создана виртуальная машина, подключимся к ней (используя MobaXterm, конечно же). Теперь можно приступать к работе.

Сначала надо скачать скрипт установки:

wget https://git.io/fxZq5 -O guac-install.sh

Выдать ему разрешение на исполнение:

chmod +x guac-install.sh

И запустить:

./guac-install.sh

В процессе работы будут установлены нужные образы и задано несколько вопросов о настройке паролей для MySQL. В конце скрипт выдаст сообщение о том, что установка завершена, напишет адрес для подключения к сервису и сообщит пароль/логин, который настоятельно порекомендует потом поменять:

Installation Complete- Visit: http://localhost:8080/guacamole/- Default login (username/password): guacadmin/guacadmin***Be sure to change the password***.


Все готово, надо только заменить localhost на внешний айпи-адрес нашего сервера и ввести пару логин/пароль в форму логина на сайте:



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

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

В качестве примера подключимся к серверу под управлением Windows по протоколу RDP. Для этого надо зайти в Настройки и выбрать опцию Подключения. Интерфейс переведен на несколько языков, и сложностей при работе с ним ни у кого не возникнет.



Дальше надо заполнить следующие поля (я перечислю минимально необходимые):
В разделе РЕДАКТИРОВАНИЕ ПОДКЛЮЧЕНИЯ заполнить поле Название и в поле Протокол выбрать RDP
В разделе СОВМЕСТНОЕ ИСПОЛЬЗОВАНИЕ поставить требуемые числа в поля Максимальное число соединений и Максимальное число соединений на пользователя. Любое необходимое, но не меньше 1.
В разделе НАСТРОЙКИ и подразделе Сеть ввести айпи-адрес удаленного сервера под управлением Windows и Порт: 3389.
Далее заполнить поля Имя пользователя и Пароль. В моем случае еще потребовалось отметить опцию Игнорировать сертификат сервера.
Остальное настройки заполняются по необходимости, в зависимости от специфики серверов, к которым требуется подключаться.
В итоге выглядит это примерно так:



В самом низу страницы нажимаем кнопку СОХРАНИТЬ и можно подключаться с главной страницы панели управления:



Все работает, мы видим рабочий стол нашего виртуального сервера:



Myrtille


На основе FreeRDP разрабатывается еще один проект: , аналогичный Apache Guacamole, но работающий на системе Windows. Его установка традиционный Windows-way, надо всего лишь скачать файл инсталлятора с и запустить его. Приложение поддерживает двухфакторную авторизацию и позволяет настроить ее в процессе установки:


В следующем диалоговом окне можно настроить работу с Active Directory:



А затем порты для подключения:



Далее следует диалог с выбором опций для установки сертификата, драйвера для PDF-принтера и разрешения множественных подключений:



Потом выбирается директория, куда будет устанавливаться программа и запускается процесс установки. На этом все, сервисом можно пользоваться, перейдя по ссылке: , где вместо ip-address надо подставить адрес сервера и web-клиент готов к подключению:



Надо заметить, что он не позволяет управлять группами пользователей и подключениями как AG и довольно аскетичен в настройках. Меню сервиса хоть и не блещет красотой, но вполне функционально:



Вот таким образом, можно отказаться от еще одного локального инструмента для работы и пользоваться обычным браузером, который есть на любом компьютере.

Подробнее..

Из хлама в NAS и немного темы майнинга

18.06.2021 12:04:53 | Автор: admin

Начну с того, что очень часто, рядом со мной аккумулируется разного рода железо (в простонародье хлам), а так как я по своей природе Плюшкин, в том плане, что я очень редко выкидываю технику, а если и случается предварительно вытаскиваю оттуда всё, что может хоть как-то пригодиться. И что бы ничего не выкидывать, периодически приходится находить применение всему этому железу, об этом сегодня и будет идти речь.

Итак мы имеем: ПК 11 летней давности в состоянии трэш.
Если подробнее: у блока питания вздуты все конденсаторы на выходе, у жёсткого диска взорванный полимерный конденсатор на входе питания, видеокарта тоже не стартует. По моим догадкам, по 12в линии явно пошло сильно больше 12в. При этом материнка с процессором остались живы. Чудо!

Порывшись в закоулках нахожу 4 плашки ddr2 пару на 1гб и пару на 2гб.

По характеристикам


Процессор: Celeron E3400
Материнская плата: P5K PRO
Оперативная память: 6 Gb ddr2
Жёсткий диск: 400 Gb IDE
Видеокарта: GeForce 8400 GS
Блок питания: FSP 350W



Ну вот всё что нужно есть, приступаем к оживлению трупа!


Начал с БП. Конденсаторов на большую ёмкость у меня нет (2000-3000мкФ) и пришлось городить этажами, получился вот такой лес:

image

На плате жёсткого диска, припаял конденсатор (старый просто испарился, одни следы только были), так же заодно покрыл припоем контактные площадки, чтобы не коррозировали, и даже не надеялся что он заработает, однако ожил:

image

С видеокартой немного сложнее, питание gpu звонится с малым сопротивлением в обе стороны, явно что то не то. При прозвоне нашёл два подозрительных силовых транзистора, перепаял на те, что были в закромах, заработало это только с помощью черной магии, других объяснений нет!Хотя сильно в нагрузке не тестировал:

image

Обновляю bios, накатываю win 10 и подключаю подготовленные под это дело диски (восстановленные). Я осознал насколько он тормоз в плане быстродействия, так что все планы по установке чего либо в него, я убрал (по крайне мере до того момента как найду, хотя бы четырёхъядерный процессор).

image

Тут больше ничего не оставалась как сделать из него NAS (сетевое хранилище) с возможностью подключения по RDP, к тому же в материнке была рабочая родная гигабитная сетевая карта (кто много возился со старым железом, знает что рабочая сетевуха в материнке это джекпот).
Далее я в прямую сделал доступ к локальным дискам по SMB включая C и разрешил подключение по RDP:

image

Майнинг


Сразу понятно что речь идёт о новой одноимённой монете.
Так как я не дата центр, будем экспериментировать с пулом.
Еще к этому NAS я подключил заплоченные диски, по-другому никак, характеристики вы сами видели.

На главном компьютере запускаю программу добычи, и тут столкнулся с тем, что сетевые диски она не видит, пришлось прописать полный путь до каждого диска:

image

После 24ч теста всё хорошо, ничего не взорвалось. Синхронизация кошелька ест 90% процессора и идёт со скоростью ленивца, который должен преодолеть 50 км ХД.

По итогу, у нас 6 портовый NAS, ещё и с 400Гб памяти на борту. Ради интереса глянул сколько стоит подобные готовые решения и удивился 700$ и это минимум.

Что можно сделать дальше?


Можно отрыть 4 ядерный процессор, подоткнуть usb 3.0 контроллер, настроить мультимедийный DLNA сервер и это только то, что мне пришло на ум.

На момент написания текста статьи, 1Тб приносит 10 рупий рублей в день.

Ни одна деталь не была куплена, всё собиралось из того, что есть.

Финал


Мне нравится спасать компьютерное железо, это экологично и экономично, к тому же, никогда не знаешь, когда может пригодиться тот или иной компьютер. И вышел реально неплохой NAS, если отойдёт в мир иной напишу в комментариях.


Подробнее..

DDoS на удаленке RDP-атаки

08.09.2020 16:22:26 | Автор: admin

Несмотря на то, что решения для удаленного доступа уже много лет успешно работают на рынке и имеют многомиллионную аудиторию, они всегда вызывали у пользователей некоторые опасения в плане безопасности. Некоторые люди и компании принципиально отказывались ими пользоваться. Что ж, в чем-то их страхи оправдались: количество атак через протокол удаленного доступа не просто растет - во время пандемии оно вообще удвоилось. В этой статье расскажем о том, как обнаружить RDP-атаку, как защититься от нее на постоянной основе, а какие методы не настолько эффективны.

До недавнего времени корпоративный поток данных в подавляющем большинстве случаев циркулировал в контролируемой инфраструктуре. Но пандемия вынудила людей в спешке организовывать весь доступ к корпоративной среде в домашних условиях и незащищенных сетях Wi-Fi. Ну а уж любовь пользователей к простым паролям и нелюбовь к двухфакторной авторизации всегда были головной болью безопасников.

Этим немедленно воспользовались киберпреступники. И без того популярные атаки через протоколы удаленного доступа с начала строгого карантина пошли лавиной: ежедневно стало регистрироваться почти миллион таких попыток. Самый популярный из протоколов удаленного доступа - проприетарный протокол Microsoft RDP, поэтому такие атаки называют RDP-атаками. Хотя в той или иной степени уязвимо любое решение удаленного доступа.

Статистика

По данным Лаборатории Касперского, с начала марта 2020 года количество атак на RDP скачкообразно увеличилось. ESET в своем отчете говорит о более чем 100 тысячах новых RDP-атак в день - рост более чем в два раза по сравнению с первым кварталом.

Причина, в том числе, не только в переходе на удаленку, но и в спешке - для компаний при переезде в карантин главным было добиться работоспособности инфраструктуры, а ее безопасность стояла только второй задачей. Например, опрос специалистов по информационной безопасности, который провели в Positive Technologies, показал, что в связи с пандемией удаленный доступ им пришлось либо экстренно организовывать с нуля (11%), либо срочно масштабировать (41%).

Что такое RDP-атаки

Протокол RDP (Remote Desktop Protocol) - это один из наиболее популярных протоколов для подключения к удаленным рабочим столам, доступный во всех версиях Windows, начиная с XP. Помимо взаимодействия с удаленным компьютером он позволяет подключить к удаленной машине локальные диски, порты и другие устройства. Используется большинством админов Windows-сред для администрирования рабочих мест пользователей и серверов, экономя им много времени.

В протоколе постоянно находили уязвимости, причем так часто, что в 2018 году даже ФБР выпустило специальное предупреждение. В мае 2019 года в старых версиях протокола была обнаружена критическая уязвимость под названием BlueKeep. Всего через месяц после ее появления началась активная волна атак, использующих BlueKeep. Затем в августе того же года в протоколе нашли еще четыре новые уязвимости. Они были связаны не с протоколом RDP, а с сервисом удаленных рабочих столов RDS и позволяли с помощью специального запроса, отправленного через RDP, получить доступ к уязвимой системе, не проходя при этом процедуру проверки подлинности.

RDP-атака - это, по сути, атака brute force, в ходе которой подбирается логин и пароль или ключ шифрования для доступа к RDP путем систематического перебора всех возможных комбинаций символов, пока не будет найден верный вариант. Для длинных паролей может использоваться перебор по словарю, где вместо генерирования комбинации букв и цифр используется длинный список популярных или скомпрометированных паролей.

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

А затем начинается собственно атака изнутри системы. Решения безопасности отключаются или удаляются, а затем либо начинается DDoS-атака, либо запускается программа-вымогатель, которая устанавливает пароль на доступ к базам данных с важной для компании информацией. Либо уводятся реальные персональные данные для credential stuffing и фишинга. Также можно использовать плохо защищенный RDP для установки программ для майнинга криптовалют или создания бэкдора (на случай, если несанкционированный доступ к RDP будет обнаружен и закрыт), для установки рекламного или шпионского ПО, SMS-троянов, и так далее. Этим можно полностью заразить все доступные в сети машины.

Существуют скрипты, которые способны по-максимуму использовать права пользователя, который подключается по RDP и всех последующих пользователей в цепочке RDP-подключений. Этот метод получил название RDPInception. Если атакованная машина подключается по цепочке через несколько серверов и везде монтируются локальные диски, то скрипт самокопируется в нужные директории и становится возможным атаковать все машины, поскольку при входе в систему выполняются скрипты, расположенные в Startup директории. Все, что подключается в этой цепочке, также может быть заражено.

Почему они опасны?

Плохо защищенное RDP-соединение может обеспечить преступникам доступ ко всей корпоративной системе. Например, зашифровка серверов компании программами-вымогателями, которые потом требуют выкуп, может быть крайне разрушительной для бизнеса. Тут показательна недавняя история очень крупного GPS-вендора Garmin, который был вынужден заплатить вымогателям $10 миллионов - по-другому их специалистам по безопасности решить проблему не удалось.

Технически такие атаки тоже становятся все более опасными. Во-первых, злоумышленники больше не работают точечно, а охватывают большие сегменты сетей.

Во-вторых, время простых атак уже прошло. Преступники используют сложные схемы и комбинируют методы. Так, в трояне TrickBot появился новый модуль rdpScanDll, который используется для проведения атак brute force на RDP-соединения. Этот модуль уже отметился в ряде атак на крупные компании, в том числе связанными с образованием и финансами.

В-третьих, персональные данные и инструменты для взлома, к сожалению, становятся все более доступными. Например, недавно исходный код Dharma, ransomware-as-a-service ПО, также нацеленного на RDP, выложили для продажи онлайн (извините, ссылку давать не будем). Растет количество утечек баз с паролями и словарей для перебора паролей, упоминавшиеся выше скрипты для взлома можно найти в открытом доступе, и там же есть готовые списки серверов, у которых открыт RDP порт. На рынке есть огромное количество ботов, которые постоянно сканируют все доступные точки подключения и пытаются подобрать пароль.

Наконец, средств для защиты либо недостаточно для переборщиков паролей, либо они не применяются. Часто компании даже не видят, что такая атака уже идет. Они могут заметить низкую производительность и долгое выполнение запросов, но лечат это оптимизацией памяти и другими нерелевантными методами.

Как понять, что RDP-атака началась

  • Снижается общая производительность, ответы на запросы становятся дольше (причем иногда вы не видите это в трафике - в нем нет ни очевидных всплесков, ни провалов, и нет аномалий в статистике нагрузки на вычислительные ресурсы).

  • Серверы не принимают соединения со службой удалённого доступа, пользователи не могут зайти на свои рабочие столы. При этом ситуация может то временно улучшаться, то ухудшаться. В целом серверы могут быть доступны и даже отвечать на ping.

  • В журналах регистрации событий вы видите множество сообщений о попытке подобрать пароль (к сожалению, далеко не всегда - там часто не отображаются попытки неверного ввода логина и пароля, потому что отслеживание этих событий дает большую нагрузку на сервер).

Способы от них избавиться

Способов, на самом деле, множество, но в данной статье мы решили разделить их на полностью надежные и те, у которых или есть определенные недостатки, или их сложно реализовать, или они могут служить только временной мерой. Начнем с надежных.

Правильная система паролей

Недавнее исследование Verizon показало, что более 80% взломов связано не с уязвимостями протокола RDP, а именно с ненадежными паролями. Поэтому в компаниях должна быть принята и закреплена в инфраструктуре политика использования сложных для подбора паролей и обязательной двухфакторной аутентификации. Пароли пользователям желательно хранить в специальных защищенных менеджерах паролей. Решения по безопасности также должны быть дополнительно защищены паролем, чтобы нельзя было их отключить изнутри при успешной атаке.

Система мониторинга всех запросов

Эффективный способ - мониторить весь входящий трафик и отслеживать все несанкционированные подключения и запросы. К системам мониторинга удаленных подключений можно добавить какие-то дополнительные системы отслеживания, которые помогут увидеть более полную картину происходящего. Например, можно включить решение Variti - Active Bot Protection, которое не только позволяет размечать все входящие запросы на предмет бот - не бот, начиная с самого первого, в режиме реального времени, но и вычислять и блокировать источники атаки. Подобное отслеживание может вестись на всех системных уровнях, включая транспортный уровень и уровень приложений. Это позволит, например, увидеть подозрительную ботовую активность, которая может быть признаком начала атаки.

Другой вариант: если нет централизованной системы контроля доступа, то можно создать скрипт на powershell, который сообщает о всех фактах и попытках авторизации. Наконец, можно настроить События на отображение всей доступной информации.

Network Level Authentication

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

Ряд других полезных практик:

  • Используйте нестандартные ключи, например, PKI (Public Key Infrastructure), а соединения RDP стройте с помощью TLS (Transport Layer Security).

  • Если RDP не используется, то выключите его и отключите на брандмауэре сети внешние соединения с локальными машинами на порту 3389 (TCP/UDP) или любом другом порту RDP.

  • Постоянно обновляйте все ПО на устройствах сотрудников до актуальных версий. Помните, что 80-90% эксплойтов создано после выхода патча на уязвимость. Узнав, что была уязвимость, атакующие ищут ее именно в старых версиях софта. Конечно, это непростая задача в условиях удаленки, но это должно быть частью корпоративной ИТ-политики. Кроме того, любые незащищенные или устаревшие компьютеры нужно изолировать.

  • По возможности используйте шифрование на устройствах, которые используются для решения рабочих задач (например, шифрование диска).

  • Сделайте резервные копии ключевых данных. Резервные копии должны быть доступны только администратору или пользователю резервного копирования. Права на папки к файлам резервного копирования также должны быть максимально ограничены.

  • Установите на все устройства сотрудников защитные решения и решения, позволяющие отследить технику в случае ее утери.

А теперь перейдем к вариантам, которые сложно назвать однозначными, потому что у них есть и плюсы, и минусы.

Организовать доступ через VPN

Помимо очевидных преимуществ, у этого варианта есть несколько сложностей.

  • Даже у тех, кто использует Virtual Private Network, иногда разрешена авторизация пользователя без пароля.

  • Практически во всех популярных VPN-решениях также есть уязвимости для несанкционированного доступа.

  • Если вы раньше не пользовались VPN, что поднимать в спешке IPSec-соединения - не самая простая задача.

  • В условиях полного домашнего зоопарка устройств и подключений к сети (как насчет выхода в интернет через сотовый модем?) на удаленке довольно тяжело объяснять и настраивать каждому из нескольких сотен пользователей, чтобы у пользователя все стабильно работало и не пропадало подключение к сети.

  • VPN-серверы тоже могут падать, причем в отличие от временного падения какого-то из сервисов, это может грозить серьезными последствиями. Получается, что VPN серверы становятся единой точкой отказа со всеми вытекающими последствиями.

  • VPN это двойное шифрование (помимо стандартного RDP шифрования дополнительно выполняется ещё и VPN шифрование), что означает дополнительную нагрузку и более медленное подключение, что не очень хорошо в условиях нестабильного или не особо быстрого канала связи.

  • При взломе VPN (а это может быть при взломе роутера), если он настроен по умолчанию (или недостаточно компетентно), хакер получает сразу доступ ко всей внутренней сети, в отличии от доступа к одиночному ПК в случае взлома RDP (хотя и через него тоже потом можно получить доступ ко внутренней сети).

Использовать другие средства удаленного доступа

К сожалению, в них также есть уязвимости. Например, в конце прошлого года найдено 37 уязвимостей в разных клиентах, работающих с протоколом VNC.

Изменить настройки всех пользователей на другой порт

Наверное, наименее надежный способ из всех, хотя наверняка найдутся люди, у которых это прекрасно работает. Почему же он не очень?

  • Требует много времени на то, чтобы изменить настройки, если у вас много конечных пользователей, среди которых могут оказаться и клиенты. А ведь счет часто идет на минуты во время активной фазы атак. В этой ситуации нужно как можно быстрее устранить проблему с минимальным отрывом пользователей от дел.

  • Кроме того, это временное решение, потому что современные боты с интеллектуальной программой сканирования портов быстро найдут новый нестандартный порт. Из нашей анти-бот практики: боты ловят нестандартный порт от пары часов до пары дней. В общем, к вам все равно придут, хоть и позже. Возможно, переименование учетных записей типа Администратор, admin, user, user1 на более несловарные будет здесь даже более эффективно.

Ввести различные ограничения на подключения

Например, можно ограничить количество разрешенных одновременно открытых сеансов, минимизировать количество пользователей, которые могут подключаться к серверам организации через интернет, запретить доступ к серверу с более чем N IP адресов, ограничить количество разрешенных ошибочных попыток входа и время для этих попыток, установить время блокировки для входа в случае неправильного ввода пароля и так далее. Да, это помогает, но это нельзя назвать полноценным решением. К сожалению, как показывает практика, эти меры могут не дать заметного снижения количества атак, ведь боты работают круглосуточно и без остановки, а ограничения - это куча тонких настроек, где одно зависит от другого, а у самого администратора часто есть определенные ограничения на настройки.

Блокировка IP

Эффективный для поколения кулхацкеров метод - блокирование IP - в случае серьезных противников может быть бесполезным, а то и опасным. Во всяком случае, адреса, с которых идут атаки, меняются в очень широком диапазоне (атака на перебор часто идет с группы адресов и даже с разных подсетей), так что сама идея блокировки по адресам это лечение последствий, а не болезни. IP адрес слишком легко подделать, атакующие могут применять сотни и с легкостью менять их. И есть большая вероятность, что они подставят его так, что будет заблокирован ваш собственный адрес или IP ваших клиентов.

К тому же блокировка отдельных IP на сервере Windows - не такая уж простая задача. Во-первых, в логах безопасности часто не видно IP того, кто пытается подключится - в некоторых случаях его можно увидеть только при успешной авторизации. В противном случае видно только логин, под которым пытались залогиниться, хотя события в журнале отмечаются. И тем более это сложно, если IP специально скрывается.

Кстати, если вы делаете это с помощью Windows Firewall, то через какое-то времяWindows начинает сильно тормозить из-за переполненного правила Windows Firewall.

Давать доступ к данным только белому списку IP-адресов - тоже достаточно сложная вещь в условиях удаленки и домашних офисов - IP может плавать, так как пользователь задействует очень разные гаджеты, которые есть в хозяйстве, и все норовит поработать из кафе или парка с публичным вайфаем.

О дивный новый мир

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

Основная головная боль в том, чтобы защититься от RDP-атак в такой ситуации - это зоопарк устройств, на которых удаленно работают сотрудники, и сроки, так как проблему нужно решать быстро. И не нужно объяснять, что в каждой конкретной организации у администратора могут быть отдельные ограничения - кому-то выделяют только один порт под сервис, у кого-то нет подходящего железа и достаточного бюджета.

Единого ответа в том, как полностью обезопасить себя от таких нападений за счет одного-единственного инструмента, наверное, пока не существует (но, думаем, рынок усиленно над этим работает). К тому же и боты стали намного хитрее и сложнее, и хакеры стали более умными, и атаки более многоплановыми. Понадобится комплекс мер, ведь существует еще достаточно много вариантов защиты, кроме тех, о которых мы написали, в том числе аппаратных - межсетевые экраны, маршрутизаторы, виртуализация, разделение основной базы данных и многое другое.

Но, мы уверены, что самый важный и первый шаг - это четко увидеть, существует ли у вас такая проблема и насколько она серьезна. Так что включайте свои мониторинги. Второй шаг - это сделать все возможное, чтобы максимально усложнить жизнь хакеру. Есть огромная вероятность того, что столкнувшись хотя бы с несколькими приемами, хакер не будет тратить время на вас, а найдет жертву попроще.

Подробнее..

Перевод История программ для удалённого доступа

04.03.2021 12:16:30 | Автор: admin


Не каждый день мне доводится рассказывать историю о технологии, попавшей в новости по весьма зловещим причинам, но и нечасто бывает так, что система водоснабжения оказывается взломанной при помощи технологии удалённой демонстрации экрана. А именно это и произошло недавно во Флориде. В центре обсуждений оказался чрезвычайно важный сегодня инструмент, в то же время обладающий естественными проблемами безопасности: это приложение удалённого отображения экрана, которое в современных условиях невероятно удобно и полезно. Однако, как показали последние события, оно может и вызывать проблемы. Сегодня мы расскажем историю программ для удалённого управления компьютерами, и она длиннее, чем мы могли бы предположить.

Можно прийти к заключению о том, что подключение к сети может заставить нас использовать более стандартизированный способ управления терминалами и потоками символов, передаваемых в наши мониторы и оборудование для контроля за терминалами. Цитата из документа Request for Comments 1971 года, в котором предложено создание официального протокола для Telnet важнейшей сетевой технологии для удалённого доступа к машинам через интерфейс командной строки. Хотя он и отличается от современных программ удалённого доступа с графическими интерфейсами, многие из описанных в документе стратегий применимы и сегодня. Основное отличие заключается в том, что современные приложения стремятся быть более платформонезависимыми, что позволяет пользователям подключаться к разным типам операционных систем при помощи одного инструмента.


Набрав номер и подключившись к твоему компьютеру, я смогу сделать всё, что захочу! Может, попробовать команду format c:?

Нет Windows, нет проблем: история ПО для удалённого доступа уходит корнями в эпоху DOS


Удалённый доступ был одной из тем для разработки компьютерного ПО в течение десятков лет ещё на заре компьютеров люди получали доступ к сетям мейнфреймов через терминалы. Однако мысль о том, что можно подключиться к компьютеру, как будто он находится в той же комнате, и получить к нему полный доступ, некоторым пользователям по-прежнему кажется какой-то магией, несмотря на то, что мы занимались подобным десятки лет.

Важнейшим инструментом в истории ПО удалённого доступа стал Carbon Copy программа, позволявшая пользователям получать доступ к удалённым компьютерам на расстоянии и управлять ими так, как будто они находятся рядом. Это ПО компании Meridian Technologies, впервые появившееся в середине 1980-х, оставалось резидентной программой в памяти DOS, позволяя удалённым пользователям созваниваться с компьютером и управлять им по телефонной линии.

Для своего времени это был впечатляющий трюк, и к тому же довольно непонятный в статье PC Magazine за 1986 год эта категория продуктов называется достаточно новой, чтобы оставаться неизвестной для большинства пользователей PC.


Реклама Carbon Copy Plus, сообщающая, что можно работать с двумя компьютерами, купив всего одну копию ПО. Готовьтесь получить по почте несколько гибких дисков. (Взято из Google Books.)

Carbon Copy, на следующий год получившая замечательный и глубокий отзыв в InfoWorld, стала считаться одним из первых лидеров рынка. Примерно в тот же период начали появляться и другие подобные инструменты, например, Norton pcANYWHERE. В то время, когда Интернет не был распространён повсеместно, такие платформы работали через стандартные модемы и требовали созваниваться с удалённой машиной по телефонной линии.

Забавно, что у продукта с названием Carbon Copy (копия, сделанная через копирку или ксерокопия) возникли проблемы с пиратством. На одном из этапов своей истории Meridian Technologies учредила программу вознаграждений, призвав пользователей ПО стучать на своих коллег, использующих нелегальные копии Carbon Copy, хотя название программы прямо-таки провоцировало её клонировать.

Мы делаем всё возможное для поддержки продукта, и в ответ призываем людей играть с нами честно, сообщил представитель компании Чарльз Джонс журналу PC Magazine. К сожалению, мир неидеален, поэтому вполне может получиться, что мы заплатим множеству людей по 2500 долларов.


Timbuktu Pro. (Взято из Macintosh Garden.)

Чрезвычайно привлекательной стала перспектива получения удалённого доступа к более мощным компьютерам, особенно после появления GUI. В статье в InfoWorld за 1988 год пользователям продавался инструмент удалённого доступа Timbuktu для компьютеров Mac, работавший по локальным сетям и через модемы. Он позиционировался как способ использования мощных компьютеров на более скромном оборудовании. (Но, увы, без цвета.)

По цене SE вы сможете использовать компьютер Mac II, рассказывал Рис Джонс из компании Farallon, купившей в то время производителя Timbuktu WOS Data Systems.


Пример работы DOS-версии pcANYWHERE.

Разумеется, эта технология со временем эволюционировала и не стояла на месте: вскоре инструменты наподобие pcANYWHERE совершили переход с DOS на Windows, и ПО для удалённого доступа начало становиться всё более платформонезависимым, упрощая задачу управления машинами за пределами офиса.

В результате этого удалённый доступ стал важным элементом инструментария отделов ИТ по всему миру. Но он ни в коем случае не является идеальным инструментом.

Screens

Приложение для macOS под названием Screens.

Пять распространённых типов ПО удалённого доступа, с которым вы можете столкнутся сегодня


  1. Chrome Remote Desktop. Реклама этого инструмента сводится к принципу в стиле Google: если у вас есть веб-браузер, то вы можете получить доступ к компьютеру. И это действительно хорошо реализовано в Chrome Remote Desktop, который присутствует на рынке уже около десятка лет и стал, вероятно, простейшим способом для удалённого доступа к компьютерам.
  2. GoToMyPC. Этот инструмент, появившийся примерно в 1998 году, получил огромный успех примерно на рубеже двух веков благодаря вниманию к простоте использования и применялся удалёнными сотрудниками ещё за десяток лет до того, как это стало популярным.
  3. Apple Screen Sharing. Хотя у Apple уже давно есть надёжное приложение Remote Desktop, для большинства пользователей оно слишком мощное; многим из нас вполне достаточно встроенного в MacOS инструмента Screen Sharing. Достойной сторонней альтернативой ему является Screens сервиса SetApp. (Лично я пользуюсь Screens.)
  4. Remote Desktop Services. У Microsoft тоже есть встроенный инструмент демонстрации удалённого экрана, называющийся Remote Desktop Services. Корнями он уходит аж в Windows NT Server 4.0, выпущенную четверть века назад.
  5. TeamViewer. Именно с этим приложением возникли проблемы у ребят из Флориды. Это широко используемый инструмент для демонстрации экрана, обычно используемый отделами ИТ для технической поддержки и удалённого управления. Он получил популярность в последние годы благодаря своей гибкости и простоте использования.


1998


В этом году произошёл первый публичный релиз протокола RFB (remote framebuffer). Эта технология, разработанная английской Olivetti Research Laboratory в 90-х, родилась благодаря своим любопытным корням впервые её использовали в качестве интерфейса, позволяющего периферийным устройствам подключаться к операционной системе банкоматов. Эта необычайно узкая сфера применения постепенно эволюционировала в нечто столь же необычайно широкое: она стала основой VNC (virtual network computing) вероятно, наиболее распространённого открытого стандарта, применяемого в ПО удалённого доступа и по сей день. Исследовательская лаборатория, приобретённая AT&T, в 2002 году стала фундаментом отдельной компании RealVNC.


Печально известный инструмент для хакинга Back Orifice имеет те же истоки, что и современное ПО для управления удалёнными рабочими столами.

Проблема удалённого доступа в том, что его слишком легко использовать злонамеренно


Вероятно, вы не ждали, что эта история об основах технологии Remote Desktop сделает неожиданный поворот и коснётся юношеских лет известного политика, но уж в такое время мы живём.

Пару лет назад бывший кандидат в президенты США Бето О'Рурк сделал заявление, что когда-то был хакером. Ну, или типа того.

Раньше он был участником Cult of the Dead Cow (cDc) существующей уже десятки лет группы, известной своей работой на хакерской сцене, однако в ней О'Рурк больше занимался писательством, чем самим хакингом. (И я говорю это без пренебрежения: cDc это не только коллектив хакеров, но в равной степени и самиздатная медиагруппа.)

Стоит также заметить, что многие участники cDc, наряду с Бето О'Рурком, постоили респектабельную карьеру. Например, один из её руководителей Mudge, урождённый Пейтер Затко, когда-то работал в DARPA, а теперь является главой отдела безопасности Twitter.

Эта группа получила наибольшую известность в связи с созданием одного из самых запомнившихся за последние тридцать лет хакерских инструментов Back Orifice, ПО для удалённого доступа, представлявшего собой бэкдор для получения полного доступа к компьютеру пользователя Windows. (Это название, как можно догадаться, является похабной игрой слов с отсылкой к Microsoft.) Программа Back Orifice, о создании которой сообщили на мероприятии DEFCON 1998 года, возникла как способ мотивировать Microsoft серьёзнее относиться к безопасности.

Но когда Microsoft всё-таки отказалась воспринимать её с достаточной серьёзностью, группа выпустила обновлённую версию, которая была ещё более изощрённой. Опасность этих инструментов заключалась не только в том, что они позволяли использовать компьютеры, основная угроза была в том, что они снижали порог входа в хакерство для тех, кто не знает, что делает.

Любопытно то, что при анализе Back Orifice очевидна его схожесть с более современными инструментами удалённого доступа, обеспечивающими доступ к машинам конечных пользователей на глубоком уровне.

Разница заключается в контексте, а также в подходе к безопасности. Современный удалённый доступ (если забыть о водоочистных сооружениях) обладает высокой защитой и позволяет администраторам удалённо управлять очень сложными системами. Многими нашими машинами можно управлять точно так же, как взломанными при помощью троянов машинами прошлого под Windows 98. Отличие в том, что вместо стратегии плаща и кинжала они реализуют это с помощью безопасных средств.


TeamViewer совершенно замечательный инструмент, если использовать его правильно.

В результате этого инструменты наподобие TeamViewer стали невероятно популярными в сфере информационных технологий. Однако они имеют и свои проблемы, особенно в случае взлома защиты.

Хорошим примером этого является Symantec pcAnywhere: примерно девять лет назад его защита превратилась в решето исходный код ПО был украден и опубликован на The Pirate Bay после того, как хакеру не удалось получить выкуп у компании. ПО pcAnywhere, появившееся ещё в середине 1980-х, вскоре полностью пропало с рынка.

Злоумышленники легко могут использовать удалённый доступ в преступных целях, особенно при слабых протоколах защиты.

Многие компании используют удалённый рабочий стол для упрощения сетевого доступа сотрудников через Интернет. Однако предоставляя такой доступ, компании упрощают возможность своего взлома, рассказывает глава отдела безопасности киберстраховой фирмы Coalition Мэтт Эхренс в посте DarkReading 2018 года.

Разумеется, учитывая этот риск, многие приложения удалённого доступа работают над усилением защиты, чтобы обеспечить ограниченность доступа. Именно поэтому инцидент с водоочистными сооружениями во Флориде стал, по сути, идеальным примером того, что не надо делать с удалённым доступом к рабочему столу.

TeamViewer со стандартным паролем? Завершение работы с инструментом высокого доступа без его удаления? Это совершенно отвратительный пример использования ПО удалённого доступа, управляющего столь важным объектом, как общественная водопроводная сеть. Разумеется, именно так оно и использовалось.

768%


На такую величину, по информации компании ESET, возросло количество атак через RDP-клиенты в прошлом году. По словам компании, проблема в том, что поскольку люди больше работают удалённо, чем год назад, киберпреступники этим пользуются. Поэтому если вы используете VNC, то, возможно, стоит его выключить.

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

К сожалению, очень многие люди узнали о его потенциале очень тёмным и странным образом, хотя в современных условиях мы должны стимулировать использование инструментов, позволяющих управлять критичными системами, находясь в безопасности дома.

(Проблема в том, что при управлении такими критичными системами нужны индивидуальные логины и надёжные меры безопасности.)

В будущем о произошедшем во Флориде почти наверняка напишут книги и запишут интервью, ведь в этой ситуации удалённый доступ оставался открытым с таким низким вниманием к защите. Однако в этом нужно упрекать не саму технологию, которая была сверхсовременной в середине 80-х и до сих пор остаётся удивительной для многих, дополнившись GUI и сетевым доступом.

На самом деле это упрёк нам, потому что несмотря на пройденный путь, мы всё равно безалаберно относимся к безопасности. А ведь cDc нас предупреждала.



На правах рекламы


Windows VDS с уже включённой в стоимость лицензией и посуточной тарификацией для самых разных задач, требующих операционку от Microsoft. Удалённый сервер мощнее домашнего компьютера это реально, закажи и убедись)

Подробнее..

Защищаем RDP Windows Server без VPN

15.04.2021 14:13:15 | Автор: admin

Часто у наших клиентов (обычно это небольшие организации без собственной IT службы) возникает необходимость предоставить доступ к своему серверу терминалов (о настройке и обеспечении отказоустойчивости будет отдельная статья) через глобальную сеть Интернет. Мы конечно же советуем так не делать, а использовать для подключения VPN (рекомендуем любимый нами SoftEther VPN Server), но если уж клиент настаивает, то стараемся максимально его обезопасить. И вот как раз про средства, которыми мы этого достигаем и пойдет речь в этой статье...

Первая программа, о которой мы расскажем называется Cyberarms Intrusion Detection and Defense Software (IDDS).

количество неудачных попыток авторизации за последние 30 днейколичество неудачных попыток авторизации за последние 30 дней

К сожалению, судя по всему, разработка была прекращена в 2017-м году, но тем не менее программа (с некоторыми нюансами - о них далее) работает даже на ОС Windows Server 2019.

Принцип действия довольно таки простой, но в тоже время эффективный: после нескольких неудачных попыток ввода пароля(количество для блокировки определено в параметрах) срабатывает Soft lock(подозрение в брутфорсе), в журнале создается инцидент и IP помечается как подозрительный. Если новых попыток не последовало, то спустя 20 минут адрес убирается из списка наблюдаемых. Если же перебор паролей продолжается, то IP адрес "злоумышленника" добавляется в запрещающее подключения правило брандмауэра Windows (должен быть в активированном состоянии) и тем самым подбор пароля с этого адреса временно прекращается, так как подключения полностью блокируются. Блокировка Hard lock продлится 24 часа - такой параметр выставлен по умолчанию. Вечную блокировку,"Hard lock forever", включать не рекомендуем, иначе количество IP в правиле брандмауэра быстро "распухнет" и программа будет тормозить.

Soft and Hard lock threshold - counts and durationSoft and Hard lock threshold - counts and duration

Устанавливается программа просто - скачиваем архив с установщиком, распаковываем во временную папку. Cкачиваем и устанавливаем Microsoft Visual C++ 2010 x64 (vcredist_x64.exe) и только после этого запускаем пакет установщика Windows -Cyberarms.IntrusionDetection.Setup.x64.msi, потому как у setup.exe скачать и установить автоматически Visual C++ не получается.

Далее производим настройку - активируем агент для защиты RDP сессий "TLS/SSL Security Agent", во вкладке "AGENTS":

Enable TLS/SSL Security AgentEnable TLS/SSL Security Agent

Вторая программа - Duo Authentication for Windows Logon and RDP

это инструмент для мультифакторной аутентификации от Duo Security (Cisco), коммерческий многофункциональный продукт, который безупречно работает и позволяет использовать смартфоны, токены и коды для 2FA.

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

  1. Зарегистрируйте себе административный аккаунт, для доступа к панели управления (Личный кабинет). Рекомендуем сразу добавить еще одного администратора, потому как восстановить доступ с помощью разработчика довольно таки проблематично, а прецеденты с неожиданной утратой смартфона администратора возникают часто.

  2. Войдите в панель администратора Duo и перейдите в Приложения (Applications).

  3. Нажмите "Защитить приложение" и найдите в списке приложений запись для Microsoft RDP. Щелкните Защитить в крайнем правом углу, чтобы настроить приложение и получить ключ интеграции, секретный ключ и имя хоста API. Эта информация понадобится вам для завершения настройки (в процессе установки Duo Authentication for Windows Logon).

    Мы рекомендуем установить политики по умолчанию для новых пользователей приложения Microsoft RDP значение "Запрет доступа", поскольку ни один незарегистрированный в Duo пользователь не должен успешно проходить авторизацию. Но для этого вам будет необходимо добавить всех пользователей в Duo через панель управления вручную или, что намного удобнее, через импорт из Active Directory (об этом расскажем позже) и выслать им ссылку для активации приложения Duo Security, предварительно установленному на их смартфонах.

4. Загрузите и установите пакет установщика Duo Authentication for Windows Logon. Во время установки введите данные, полученные на предыдущем шаге.

Если вы хотите включить автономный доступ с помощью Duo MFA, вы можете сделать это сейчас в разделе Настройки автономного доступа на странице приложения Duo или вернуться в панель администратора позже, чтобы настроить автономный доступ после первой проверки успешного входа в систему с помощью двух-факторной аутентификации.

Также во время установки рекомендуем установить все 3 галки в чекбоксах - эти настройки позволят вам получать доступ в ОС без 2FA, например при использовании консоли гипервизора или при отсутствии подключения к серверам Duo (частый случай - большое расхождение по времени):

не лишним будет напоминание о безопасном хранении всех ключей:
Treat your secret key like a password

The security of your Duo application is tied to the security of your secret key (skey). Secure it as you would any sensitive credential. Don't share it with unauthorized individuals or email it to anyone under any circumstances!

После установки Duo Authentication for Windows Logon можно добавить пользователя (своего, без привилегий администратора) и активировать приложение на смартфоне. Для этого переходим в раздел Users, жмем Add User - заполняем необходимые поля. Далее добавляем пользователю телефон (раздел Phones - Add Phone) и активируем Duo Moibile (ссылку для активации пользователю можно отправить SMS, если есть деньги на балансе или вручную через Email или другим удобным способом).

Теперь при подключении и успешной авторизации (по логину и паролю) пользователю будет отправлено Push уведомление на смартфон с активированным приложением Duo Mobile:

Если на смартфоне нет доступа в Интернет (и соответственно Push приходить не будут), то можно подтвердить авторизацию сгенерированным кодом (Passcode ) из приложения:

Настройка синхронизации пользователей с глобальным каталогом (Azure AD - Active Directory - LDAP) хорошо описана в документации разработчика, хочу лишь уточнить что это платный функционал. Основной компонент для синхронизации пользователей, это Duo Authentication Proxy - ПО, которое обеспечивает подключение к каталогу.

Если вы используете RDWEb (клиентский доступ или шлюз), то вам пригодится еще один компонент - Duo Authentication for Microsoft Remote Desktop Web. Настройка его аналогична Duo Authentication for Windows Logon и не должна вызвать затруднений.

Подводя итоги заметим, что рассмотренное ПО не является панацеей от всех бед для публичных сервисов (доступных из сети Интернет), потому как бывают уязвимости, эксплуатация которых позволяет злоумшленникам обходить даже такие меры по обеспечению безопасности ОС\инфраструктуры в целом. Поэтому требуется всегда комплесно подходить к этому вопросу - мониторинг, аудит и регламентные процедуры по обновлению позволят вам почувствовать себя защищенными в этом неспокойном мире. Берегите свои данные!

Подробнее..

Производительность RemoteFX, часть 1

14.04.2021 14:22:42 | Автор: admin

О технологии RemoteFX от Майкрософт, которая повышает качество работы в режиме удалённого рабочего стола, известно давно. В интернете хватает материалов, демонстрирующих её эффективность. Но большинство оценок носят качественный характер: "вот играем в %game_name%, fps в норме", "вот запустили 3D софт, как будто локально работает! Скриншот здесь, видео там".

В данном исследовании мы разберёмся, как перейти от "попугаев" к конкретным метрикам, чтобы количественно оценить эффективность технологии и объективно сравнить её использование с обычным режимом RDP.

Содержание
  • Кратко о RemoteFX

  • Конфигурация тестовой среды

    • Сервер

    • Клиент

  • Выбор показателей для измерений

  • Методика тестирования

    • Тест #1: ввод текста

    • Тест #2: ввод текста + 3D BenchMark

    • Тест #3: ввод текста + просмотр локальных видеофайлов

    • Тест #4: ввод текста + просмотр youtube-ролика

  • Обработка данных и построение графиков

  • Анализ результатов и наиболее интересные графики

    • Задержки при обработке ввода от пользователя

    • Частота кадров

    • Общие сетевые метрики

    • Загрузка центрального процессора

    • Загрузка видеокарты

  • Выводы

  • Что дальше

  • Список источников

  • Приложения

    • Переопределение групп сбора данных: _1_task_define.cmd

    • Принудительная остановка записи данных: _1_task_breake.cmd

    • Конвертация двоичных данных в CSV: blg2csv.cmd

    • Нормализация заголовков CSV: blg2csv.ps1

    • Jupiter Notebook: импорт данных

    • Jupiter Notebook: отрисовка одной метрики на диаграмму

    • Jupiter Notebook: отрисовка всех метрик на одной диаграмме

    • Диаграмма со всеми графиками

Кратко о RemoteFX

Традиционный RDP работает так, чтобы как можно больше работы по отрисовке окна удалённого рабочего стола переложить на клиента: по сети передаются графические примитивы и инструкции, которые должна выполнить клиентская видеокарта. Такой подход, в случае показа видео или использования интерфейса Windows Aero, требует поддержки со стороны клиента. Иначе вместо Aero будет использована упрощённая схема, а обработанный CPU сервера видеопоток передан клиенту в виде растровой графики, производительность отрисовки при этом может оказаться просто неприемлемой. Поэтому приходилось выбирать: либо использовать традиционный RDP только в связке с достаточно производительным клиентским железом, либо отказываться от сложной графики.

При включении RemoteFX клиенту по сети по прежнему передаются растровые кадры. Но есть два существенных отличия от традиционного RDP. Во-первых, вся подготовка и обработка графики перекладывается на GPU сервера, это происходит намного быстрее и разгружает CPU. А во-вторых, используется сжатие кадра, которое выполняет кодек RemoteFX. Это существенно снижает объём передаваемых по сети данных, тем самым разгружая канал связи. Это существенно снижает требования к клиентскому железу, но сохраняет достаточный уровень отрисовки и отзывчивости удалённого рабочего стола.

Конфигурация тестовой среды

Сервер

  • 2 vCPU Intel(R) Xeon(R) CPU E5-2696 v4 @ 2.20GHz

  • 8 GB RAM

  • GPU NVIDIA GRID M60-1Qб, Dedicated Memory 929 MB, Shared Memory 4095 MB

  • гостевая ОС Windows Server 2019 Standart x64 1809 (Version 10.0.17763.1577), DirectX 12

  • network in/out rate limit 50 Mbps

Клиент

  • Intel(R) Core(TM) i5-7600K CPU @ 3.80GHz, 3801 МГц, ядер: 4, логических процессоров: 4

  • 16 GB RAM

  • network in/out rate limit 100 Mbps

  • OS Windows 10 Pro 2004 (Version 10.0.19041.685), DirectX 12

  • настройки RDP-сеанса

    • 1920 x 1080 (32 bit) (32Hz)

    • на вкладке "Взаимодействие" выбрано "Локальная сеть (10 Мбит/с и выше)"

Выбор показателей для измерений

Качество и производительность удалённого рабочего стола нужно оценить с точки зрения как пользователя, так и потребления облачных ресурсов. Будем собирать данные о частоте кадров отрисовки, задержках отклика на ввод данных, сетевом трафике и загрузке CPU/GPU/RAM. Метрики выбраны с учётом официальныхрекомендаций по диагностике.

Замеры выполним с помощью стандартного средстваСистемный монитор. Для этого на каждый тест определим свой сборщик данных, который в течении двух минут будет каждую секунду фиксировать в двоичном blg-файле журнала показания счётчиков:

Показания
  • \Графика RemoteFX(*)\Качество кадра

  • \Графика RemoteFX(*)\Исходящих кадров в секунду

  • \Графика RemoteFX(*)\Входящих кадров в секунду

  • \Графика RemoteFX(*)\Среднее время кодирования

  • \Графика RemoteFX(*)\Коэффициент сжатия графических данных

  • \Графика RemoteFX(*)\Пропущено кадров в секунду у сервера недостаточно ресурсов

  • \Графика RemoteFX(*)\Пропущено кадров в секунду недостаточно сетевых ресурсов

  • \Графика RemoteFX(*)\Пропущено кадров в секунду у клиента недостаточно ресурсов

  • \Задержка ввода данных пользователем на сеанс(Max)\Максимальная задержка ввода

  • \Сведения о процессоре(_Total)\% загруженности процессора

  • \NVIDIA GPU(*)\% Video Decoder Usage

  • \NVIDIA GPU(*)\% Video Encoder Usage

  • \NVIDIA GPU(*)\% GPU Memory Usage

  • \NVIDIA GPU(*)\% GPU Usage

  • \NVIDIA GPU(*)\% FB Usage

  • \Сеть RemoteFX(*)\Потери

  • \Сеть RemoteFX(*)\Общая скорость отправки

  • \Сеть RemoteFX(*)\Общая скорость приема

  • \Сеть RemoteFX(*)\Скорость отправки TCP-данных

  • \Сеть RemoteFX(*)\Скорость отправки UDP-данных

  • \Сеть RemoteFX(*)\Общая скорость приема

  • \Сеть RemoteFX(*)\Скорость получения TCP-данных

  • \Сеть RemoteFX(*)\Скорость получения UDP-данных

  • \Сеть RemoteFX(*)\Пропускная способность текущего TCP-подключения

  • \Сеть RemoteFX(*)\Пропускная способность текущего UDP-подключения

  • \Память\% использования выделенной памяти

  • \Память\Доступно байт

PS. По непонятной причине данные по оперативной памяти не сохранялись в журнал при выполнении задания группы сбора, хотя "вживую"Системный мониторнормально строил графики по обоим показателям.Сброс кэша счётчиковне помог.

Методика тестирования

Чтобы оценить эффективность использования выделенной видеокарты на облачным сервере, нужно провести две серии одинаковых тестов: до и после включения отрисовки удалённого рабочего стола на GPU.

В каждой серии выполним следующие тесты:

  1. ввод текста

  2. ввод текста + 3D BenchMark

  3. ввод текста + просмотр локальных видеофайлов

  4. ввод текста + просмотр youtube-ролика

Для оценки влияния теста на задержку обработки ввода от пользователя поверх основной программы открывается стандартныйБлокноти зажимается произвольная клавиша. Окно редактора на протяжении теста будет постоянной частью всех кадров, поэтому исказит результат в лучшую сторону. Чтобы снизить эффект, размер окна уменьшим до 122*156% 99% кадра будут меняться и визуально будет видно, что имитация активности пользователя работает.

Тест #1: ввод текста

В качестве тестоврекомендуется"использовать любые приложения, которые плотно работают с графикой (например, потоковое видео), приложения, использующие DirectX". Результаты первого теста, с точки зрения пользователя (частота кадров и задержка ввода), практически одинаковые. Поэтому строить графики и анализировать их нет особого смысла. Такой тест больше пригодится для диагностики RemoteFX.

Тест #2: ввод текста + 3D BenchMark

Выполнялся при помощи FurMark в полноэкранном режиме.

Тест #3: ввод текста + просмотр локальных видеофайлов

Локальные видеофайлы воспроизводились в Windows Media Player, равёрнутом на весь экран, без установки каких-либо дополнительных кодеков, по кругу в следущем порядке:

  1. "Ants carrying dead spider": 1920 x 1080, 10667 кбит/с, 19 секунд, 29.97 fps

  2. "Flying Through Forest 1": 1920 x 1088, 48072 кбит/с, 9 секунд, 25 fps

  3. "Low Angle Of Pedestrians Walking In Busy Street, Daytime": 4096 x 2160, 31721 кбит/с, 13 секунд, 25 fps

Единственным критерием отбора была динамичность ролика: видеоряд должен был как можно сильнее нагрузить кодек RemoteFX. Но ролик "Flying Through Forest 1" оказался в этом плане интересной находкой: выходной FPS заметно проседал, а входной от запуска к запуску был сильно выше или ниже среднего! Его влияние на различные метрики будет заметно на графиках, которые будут ниже.

Тест #4: ввод текста + просмотр youtube-ролика

В качестве youtube-теста был выбран чудесный ролик "Коста-Рика", который проигрывался в качестве1080p60в браузере Firefox, режим "киоск".

Обработка данных и построение графиков

Файлы журналов -blg- имеют двоичный формат: легко открываются в родной программе, графики всех счётчиков на одной шкале, можно выключать/включать/масштабировать/etc. Но чтобы работать с данными из нескольких файлов, нужно другое решение.

Сначалаконвертируем двоичные файлы в csv (см. Приложение)с помощью стандартной утилитыreglogиочистим их заголовки (см. Приложение).

Затем вJupiter-блокноте при помощи библиотекpandasиmatplotlibпрочитаемcsv (см. Приложение, Jupiter Notebook: импорт) ипостроимграфики (см. Приложение, Jupiter Notebook: одна метрика одна диаграмма).

Анализ результатов и наиболее интересные графики

Задержки при обработке ввода от пользователя

До включения групповых политик сильнее всего на обработке ввода сказалось проигрывание локальных видеофайлов: в среднем 45 мс при рекомендованных 33 мс.

Включение отрисовки через GPU в групповых политиках стабилизировало этот показатель во всех сценариях.

Частота кадров

После включения GPU ускорения ситуация явно становится лучше, особенно в 3D тесте. Результаты двух других тестов хоть и демонстрируют улучшение, но недостаточно: провалы на графиках соответствуют визуальным "рывкам" при просмотре.

Воспроизведение"Flying Through Forest 1"(1920 x 1088, 48072 кбит/с, 9 секунд, 25 fps): от запуска к запуску на вход кодека RеmoteFX поступало либо повышенное либо пониженное количество кадров. Возможно, причина в перекодировке из формата QuickTime, "лишних" 8 пикселях ширины кадра или битрейте.

"Коста-Рика"также вызвал "проседание" FPS у RemoteFX: его проигрывание в браузере в1080p60ложилось на центральный процессор. Возможно, он просто не успевал перекодировать из 60fps и подготовить нужный кадр для RemoteFX.

Общие сетевые метрики

При включении GPU ускорения происходит рост сетевого трафика, который зависит от сценария теста.

Видно, что самым тяжёлым для кодека RemoteFX опять оказался тот же самый видеофайл,"Flying Through Forest 1". Первый запуск этого теста, когда наблюдается провал входящих кадров, также видим скачки трафика до 60 Мбит/с и потери до 30% - 40%.

Загрузка центрального процессора

Включение GPU ускорения практически вдвое разгружает центральный процессор, за исключением youtube-теста. И даже здесь удалось уйти от периодической 100% загрузки.

Загрузка видеокарты

Возможно, разгадка странного поведения второго ролика кроется в графике 17: входящих для RemoteFX кадров было больше, когда видеокарта была больше загружена кодированием.

Выводы

В RDP протоколе частота кадров ограничена 30-ю кадрами в секунду. Со стороны сервера увеличить лимит FPSможно, но бессмысленно: на практике терминальная сессия перестала отрисовывать окно и реагировать на действия как раз при проигрывании"того самого"видеофайла :).

Итоги в цифрах:

  1. Частота кадров стабилизируется почти на максимально возможном для протокола уровне: 29-30 FPS в среднем вместо 25 или даже 15 FPS

  2. Отзывчивость удалённого рабочего стола также стабилизируется, при этом возрастая в несколько раз

  3. Заметно, на 20-50 %, разгружается центральный процессор

  4. Немного возрастает утилизация канала связи, на 3-6 Мбит/сек

  5. Утилизация GPU составила до 20%

Результат действительно очень хороший: RemoteFX значительно увеличивает качество работы в терминальной сессии плавность отрисовки окна и отклик на действия пользователя сравнимы с локальным режимом. Даже "тяжёлые" сценарии показывают в этом плане заметный прирост.

Тесты, конечно, носят искусственный характер: выбором способа нагрузки на кодек RemoteFX можно как "завалить" так и "подтянуть" его результаты. Возможно, более релевантным было бы проведение чего-то вроде "конфетти-теста",например, такого.

Что дальше

Так как на этом этапе тесты проводились для одной сессии и при включении лишь рекомендованных настроек, то далее имеет смысл протестировать производительность:

  • при одновременной работе нескольких пользователей

  • при включении в групповых политиках различных дополнительных настроек кодека

Список источников

Приложения

Переопределение групп сбора данных: _1_task_define.cmd
@echo offsetlocal EnableDelayedExpansion@REM для сбора используются счётчики, перечисленные в _1_counters.cfg@REM счётчики называются только на английском, на русском это просто описание@REM @REM запуск сбора данных:@REM    при каждом входе на удалённый рабочий стол исправить _1_counters.cfg:@REM    1)  посмотреть номер своей терминальной сессии консольной командой@REM        query session@REM    @REM    2)  вписать этот номер в _1_counters.cfg, например, RDP-Tcp 9@REM    @REM    3)  перерегистрировать сброщик запуском данного файла@REM @REM    4)  замер производительности производится запуском _2_task_run_X.cmd и длится 2 минуты@REM @REM удаление старого сборщика данныхlogman delete -n RemoteFX_1logman delete -n RemoteFX_2logman delete -n RemoteFX_3logman delete -n RemoteFX_4logman delete -n RemoteFX_5for /F "usebackq delims= " %%a IN (`query session ^| find "Administrator"`) DO (    set "x=%%a"    set "x=!x:~9,10!"    echo !x!    type NUL>_1_counters.cfg    echo ^\NVIDIA GPU^(^*^)^\%% Video Decoder Usage>>_1_counters.cfg    echo ^\NVIDIA GPU^(^*^)^\%% Video Encoder Usage>>_1_counters.cfg    echo ^\NVIDIA GPU^(^*^)^\%% GPU Memory Usage>>_1_counters.cfg    echo ^\NVIDIA GPU^(^*^)^\%% GPU Usage>>_1_counters.cfg    echo.>>_1_counters.cfg    echo ^\Processor Information^(_Total^)^\%% Processor Time>>_1_counters.cfg    echo.>>_1_counters.cfg    echo ^\RemoteFX Network^(RDP-Tcp !x!^)^\Loss Rate>>_1_counters.cfg    echo ^\RemoteFX Network^(RDP-Tcp !x!^)^\Current TCP Bandwidth>>_1_counters.cfg    echo ^\RemoteFX Network^(RDP-Tcp !x!^)^\Current UDP Bandwidth>>_1_counters.cfg    echo.>>_1_counters.cfg    echo ^\RemoteFX Network^(RDP-Tcp !x!^)^\Total Sent Rate>>_1_counters.cfg    echo ^\RemoteFX Network^(RDP-Tcp !x!^)^\TCP Sent Rate>>_1_counters.cfg    echo ^\RemoteFX Network^(RDP-Tcp !x!^)^\UDP Sent Rate>>_1_counters.cfg    echo.>>_1_counters.cfg    echo ^\RemoteFX Network^(RDP-Tcp !x!^)^\Total Received Rate>>_1_counters.cfg    echo ^\RemoteFX Network^(RDP-Tcp !x!^)^\TCP Received Rate>>_1_counters.cfg    echo ^\RemoteFX Network^(RDP-Tcp !x!^)^\UDP Received Rate>>_1_counters.cfg    echo.>>_1_counters.cfg    echo ^\RemoteFX Graphics^(^*^)^\Output Frames/Second>>_1_counters.cfg    echo ^\RemoteFX Graphics^(^*^)^\Input Frames/Second>>_1_counters.cfg    echo.>>_1_counters.cfg    echo ^\RemoteFX Graphics^(^*^)^\Frames Skipped/Second - Insufficient Server Resources>>_1_counters.cfg    echo ^\RemoteFX Graphics^(^*^)^\Frames Skipped/Second - Insufficient Network Resources>>_1_counters.cfg    echo ^\RemoteFX Graphics^(^*^)^\Frames Skipped/Second - Insufficient Client Resources>>_1_counters.cfg    echo ^\RemoteFX Graphics^(^*^)^\Frame Quality>>_1_counters.cfg    echo ^\RemoteFX Graphics^(^*^)^\Average Encoding Time>>_1_counters.cfg    echo ^\User Input Delay per Session^(Max^)^\Max Input Delay>>_1_counters.cfg    echo.>>_1_counters.cfg    echo ^\RemoteFX Graphics^(^*^)^\Graphics Compression ratio>>_1_counters.cfg    echo ^\NVIDIA GPU^(^*^)^\%% FB Usage>>_1_counters.cfg    @REM счётчик памяти не работает, сброс кэша счётчиков также не помог    @REM    https://docs.microsoft.com/ru-ru/troubleshoot/windows-server/performance/manually-rebuild-performance-counters    echo ^\Memory^\%% Committed Bytes In Use>>_1_counters.cfg    echo ^\Memory^\Available Bytes>>_1_counters.cfg)@REM и регистрация нового сборщикаlogman create counter -n RemoteFX_1 -f bin -max 10 -si 00:00:01 -rf 00:02:00 --v -o "%~dp0logs\test #1 void GPO X" -cf "%~dp0_1_counters.cfg"logman create counter -n RemoteFX_2 -f bin -max 10 -si 00:00:01 -rf 00:02:00 --v -o "%~dp0logs\test #2 3D GPO X" -cf "%~dp0_1_counters.cfg"logman create counter -n RemoteFX_3 -f bin -max 10 -si 00:00:01 -rf 00:02:00 --v -o "%~dp0logs\test #3 wmp GPO X" -cf "%~dp0_1_counters.cfg"logman create counter -n RemoteFX_4 -f bin -max 10 -si 00:00:01 -rf 00:02:00 --v -o "%~dp0logs\test #4 youtube GPO X" -cf "%~dp0_1_counters.cfg"logman create counter -n RemoteFX_5 -f bin -max 10 -si 00:00:01 -rf 00:02:00 --v -o "%~dp0logs\test #5 webGL GPO X" -cf "%~dp0_1_counters.cfg"@REM pause@REM exit
Принудительная остановка записи данных: _1_task_breake.cmd
@REM запускаем сбор данныхlogman stop RemoteFX_1logman stop RemoteFX_2logman stop RemoteFX_3logman stop RemoteFX_4logman stop RemoteFX_5
Конвертация двоичных данных в CSV: blg2csv.cmd
@echo off@REM смена кодировки нужна для powershell-скрипта "%~dpn0.ps1"chcp 65001@REM работаем в текущей папке скриптаcd "%~dp0logs"@REM включаем расширения для переопределения переменных в циклеsetlocal EnableDelayedExpansion@REM цикл по двоичным файлам мониторингаFOR /F "usebackq delims=." %%a IN (`dir *.blg /b`) DO (    set "blg=%%a.blg"    set "csv=%%a.csv"    @REM convert binary to csv    relog "!blg!" -f csv -o "!csv!" -y)@REM имена cmd и powershell скриптов должны совпадатьstart "%~dpn0.ps1" /WAIT /B pwsh.exe -Command "& {%~dpn0.ps1 -en:$False}"@REM справка reglog - утилиты работы с журналами производительности@REM https://docs.microsoft.com/ru-ru/windows-server/administration/windows-commands/relog
Нормализация заголовков CSV: blg2csv.ps1

Заголовки столбцов содержат различные уникальные данные (id терминальной сессии или оборудования), которые будут несовпадать из-за применения групповых политик и выхода-входа на терминальный сервер. Приводим к единому виду с помощью PowerShell-скрипта:

[CmdletBinding()]param (    [switch] $en       = $False  # substitute ru alias of counters by real en name)$WorkDir = $MyInvocation.MyCommand.Definition | Split-Path -Parent$LogsDir = Join-Path -Path $WorkDir -ChildPath 'logs'$EncodeFrom = [System.Text.Encoding]::GetEncoding(1251)$EncodeTo = New-Object System.Text.UTF8Encoding $False$names = @(    New-Object psobject -Property @{ 'ru' = 'Задержка ввода данных пользователем на сеанс(Max)\Максимальная задержка ввода' ; 'en' = 'User Input Delay per Session\Max Input Delay'}    New-Object psobject -Property @{ 'ru' = 'Графика RemoteFX\Входящих кадров в секунду' ; 'en' = 'RemoteFX Graphics\Input Frames/Second'}    New-Object psobject -Property @{ 'ru' = 'Графика RemoteFX\Исходящих кадров в секунду' ; 'en' = 'RemoteFX Graphics\Output Frames/Second'}    New-Object psobject -Property @{ 'ru' = 'Графика RemoteFX\Среднее время кодирования' ; 'en' = 'RemoteFX Graphics\Average Encoding Time'}    New-Object psobject -Property @{ 'ru' = 'Графика RemoteFX\Качество кадра' ; 'en' = 'RemoteFX Graphics\Frame Quality'}    New-Object psobject -Property @{ 'ru' = 'Графика RemoteFX\Коэффициент сжатия графических данных' ; 'en' = 'RemoteFX Graphics\Graphics Compression ratio'}    New-Object psobject -Property @{ 'ru' = 'Сеть RemoteFX\Общая скорость отправки' ; 'en' = 'RemoteFX Network\Total Sent Rate'}    New-Object psobject -Property @{ 'ru' = 'Сеть RemoteFX\Общая скорость приема' ; 'en' = 'RemoteFX Network\Total Received Rate'}    New-Object psobject -Property @{ 'ru' = 'Сеть RemoteFX\Потери' ; 'en' = 'RemoteFX Network\Loss Rate'}    New-Object psobject -Property @{ 'ru' = 'Графика RemoteFX\Пропущено кадров в секунду  недостаточно сетевых ресурсов' ; 'en' = 'RemoteFX Graphics\Frames Skipped/Second - Insufficient Network Resources'}    New-Object psobject -Property @{ 'ru' = 'Графика RemoteFX\Пропущено кадров в секунду  у сервера недостаточно ресурсов' ; 'en' = 'RemoteFX Graphics\Frames Skipped/Second - Insufficient Server Resources'}    New-Object psobject -Property @{ 'ru' = 'Графика RemoteFX\Пропущено кадров в секунду  у клиента недостаточно ресурсов' ; 'en' = 'RemoteFX Graphics\Frames Skipped/Second - Insufficient Client Resources'}    New-Object psobject -Property @{ 'ru' = 'Сведения о процессоре(_Total)\% загруженности процессора' ; 'en' = 'Processor Information(_Total)\% Processor Time'}    New-Object psobject -Property @{ 'ru' = 'NVIDIA GPU\% GPU Usage' ; 'en' = 'NVIDIA GPU\% GPU Usage'}    New-Object psobject -Property @{ 'ru' = 'NVIDIA GPU\% GPU Memory Usage' ; 'en' = 'NVIDIA GPU\% GPU Memory Usage'}    New-Object psobject -Property @{ 'ru' = 'NVIDIA GPU\% Video Decoder Usage' ; 'en' = 'NVIDIA GPU\% Video Decoder Usage'}    New-Object psobject -Property @{ 'ru' = 'NVIDIA GPU\% Video Encoder Usage' ; 'en' = 'NVIDIA GPU\% Video Encoder Usage'}    New-Object psobject -Property @{ 'ru' = 'NVIDIA GPU\% FB Usage' ; 'en' = 'NVIDIA GPU\% FB Usage'}    New-Object psobject -Property @{ 'ru' = 'Сеть RemoteFX\Пропускная способность текущего UDP-подключения' ; 'en' = 'RemoteFX Network\Current UDP Bandwidth'}    New-Object psobject -Property @{ 'ru' = 'Сеть RemoteFX\Пропускная способность текущего TCP-подключения' ; 'en' = 'RemoteFX Network\Current TCP Bandwidth'}    New-Object psobject -Property @{ 'ru' = 'Сеть RemoteFX\Скорость отправки UDP-данных' ; 'en' = 'RemoteFX Network\UDP Sent Rate'}    New-Object psobject -Property @{ 'ru' = 'Сеть RemoteFX\Скорость получения UDP-данных' ; 'en' = 'RemoteFX Network\UDP Received Rate'}    New-Object psobject -Property @{ 'ru' = 'Сеть RemoteFX\Скорость отправки TCP-данных' ; 'en' = 'RemoteFX Network\TCP Sent Rate'}    New-Object psobject -Property @{ 'ru' = 'Сеть RemoteFX\Скорость получения TCP-данных' ; 'en' = 'RemoteFX Network\TCP Received Rate'})$Heads = @()foreach ($f in Get-ChildItem -Path $LogsDir -File -Filter '*.csv'){    $FileContent = $f | Get-Content -Encoding $EncodeFrom    $HeadOrig = $FileContent[0]    # приводим заголовки к единому виду, убираем ненужное    # "\\TESTGPU\NVIDIA GPU(#0 GRID M60-1Q (id=1, NVAPI ID=513))\% GPU Memory Usage"    if ($HeadOrig -match '.*(?<hostname>\\\\[a-zA-Z0-9]*\\).*')    {        $HeadOrig = $HeadOrig.Replace($Matches['hostname'], '')    }    if ($HeadOrig -match '.*NVIDIA GPU(?<gpu>\(#[A-Z0-9 ]*-[A-Z0-9]* \(id=[0-9,]* NVAPI ID=[0-9]*\)\))')    {        $HeadOrig = $HeadOrig.Replace($Matches['gpu'], '')    }    # "\\TESTGPU\Графика RemoteFX(RDP-Tcp 55)\Входящих кадров в секунду"    if ($HeadOrig -match '.*(?<session>\(RDP-Tcp[ 0-9]*\)).*')    {        $HeadOrig = $HeadOrig.Replace($Matches['session'], '')    }    # "(PDH-CSV 4.0) (Russia TZ 2 Standard Time)(-180)"    if ($HeadOrig -match '.*(?<time>\(.*\) \(.*Time\)\([0-9 +-]*\))')    {        $HeadOrig = $HeadOrig.Replace($Matches['time'], 'Time')    }    if ($en)    {        $HeadOrig = ($HeadOrig -split '","') -replace '"', ''        foreach ($h in $HeadOrig)        {            if ($h -notin $names.ru) { continue }            $n = $names | Where-Object {$_.ru -eq $h}            $HeadOrig[($HeadOrig.IndexOf($h))] = $n.en  # $h = $n.en не работает        }        $HeadOrig = '"{0}"' -f ($HeadOrig -join '","')    }    $FileContent[0] = $HeadOrig  # перезапись заголовка    $FileContent | Out-File -Encoding $EncodeTo -FilePath $f.FullName    $Heads += $f.Name + $HeadOrig  # сохранение заголовка}# вывод заголовков столбцов в отдельный файл для доп. контроля порядка, названий и т.д.$Heads | Out-File -Encoding $EncodeTo -FilePath (Join-Path -Path $LogsDir -ChildPath 'heads.txt')
Jupiter Notebook: импорт данных
import pandas as pdimport matplotlib.pyplot as pltfrom matplotlib.ticker import EngFormatter  # для вывода форматированных единиц измеренияplt.rcParams['figure.max_open_warning'] = 30  # порог предупреждения при одновременном построении нескольких рисунков%matplotlib inline# импорт данных csv-файловt21 = pd.read_csv('./logs/test #2 3D GPO 1.csv', na_values=' ')t20 = pd.read_csv('./logs/test #2 3D GPO 0.csv', na_values=' ')  # , encoding='cp1251')t31 = pd.read_csv('./logs/test #3 wmp GPO 1.csv', na_values=' ')t30 = pd.read_csv('./logs/test #3 wmp GPO 0.csv', na_values=' ')t31_prev = pd.read_csv('./logs/test #3 wmp GPO 1 anomaly.csv', na_values=' ')t41 = pd.read_csv('./logs/test #4 youtube GPO 1.csv', na_values=' ')t40 = pd.read_csv('./logs/test #4 youtube GPO 0.csv', na_values=' ')# слияние результатов каждого теста: сначала рекомендованные GPO, потом default GPOt2 = pd.concat([t21, t20],           join='inner', axis=1)t3 = pd.concat([t31, t30, t31_prev], join='inner', axis=1)t4 = pd.concat([t41, t40],           join='inner', axis=1)# разные наборы для итерации и рисования в циклеdataframes = [t2, t3, t4]ax_titles = ['test #2: 3D benchmark', 'test #3: play 1080p video', 'test #4: play 1080p youtube video']legend = ['GPU acceleration', 'default', 'GPU, anomaly']img_sx, img_sy = 15, 5  # размеры одного ряда графиковfgs = [  # макет графиков  # yunit ед. изм., ylabel метка Y-оси, ydata колонка из датафрейма    {'yunit': 'ms',     'ylabel': 'Input Delay',            'ydata': 'Задержка ввода данных пользователем на сеанс(Max)\Максимальная задержка ввода'},    {'yunit': 'fps',    'ylabel': 'RemoteFX input FPS',     'ydata': 'Графика RemoteFX\Входящих кадров в секунду'},    {'yunit': 'fps',    'ylabel': 'RemoteFX output FPS',    'ydata': 'Графика RemoteFX\Исходящих кадров в секунду'},    {'yunit': 'bps',    'ylabel': 'Tx Speed',               'ydata': 'Сеть RemoteFX\Общая скорость отправки'},    {'yunit': 'bps',    'ylabel': 'Rx Speed',               'ydata': 'Сеть RemoteFX\Общая скорость приема'},    {'yunit': '%',      'ylabel': 'Tx / Rx Loss',           'ydata': 'Сеть RemoteFX\Потери'},    {'yunit': '%',      'ylabel': 'CPU Usage',              'ydata': 'Сведения о процессоре(_Total)\% загруженности процессора'},    {'yunit': '%',      'ylabel': 'GPU Usage',              'ydata': 'NVIDIA GPU\% GPU Usage'},    {'yunit': '%',      'ylabel': 'GPU Memory Usage',       'ydata': 'NVIDIA GPU\% GPU Memory Usage'},    {'yunit': '%',      'ylabel': 'GPU Decoder Usage',      'ydata': 'NVIDIA GPU\% Video Decoder Usage'},    {'yunit': '%',      'ylabel': 'GPU Encoder Usage',      'ydata': 'NVIDIA GPU\% Video Encoder Usage'},    {'yunit': 'ms',     'ylabel': 'Encoding Time',          'ydata': 'Графика RemoteFX\Среднее время кодирования'},    {'yunit': '%',      'ylabel': 'Frame Quality',          'ydata': 'Графика RemoteFX\Качество кадра'},    {'yunit': '%',      'ylabel': 'Compression: enc byte / in byte', 'ydata': 'Графика RemoteFX\Коэффициент сжатия графических данных'},    {'yunit': 'fps',    'ylabel': 'FPS Loss by network',    'ydata': 'Графика RemoteFX\Пропущено кадров в секунду  недостаточно сетевых ресурсов'},    {'yunit': 'fps',    'ylabel': 'FPS Loss by server',     'ydata': 'Графика RemoteFX\Пропущено кадров в секунду  у сервера недостаточно ресурсов'},    {'yunit': 'fps',    'ylabel': 'FPS Loss by client',     'ydata': 'Графика RemoteFX\Пропущено кадров в секунду  у клиента недостаточно ресурсов'},    {'yunit': '%',      'ylabel': 'GPU Framebufer Usage',   'ydata': 'NVIDIA GPU\% FB Usage'},    {'yunit': 'bps',    'ylabel': 'Tx Speed UDP',           'ydata': 'Сеть RemoteFX\Скорость отправки UDP-данных'},    {'yunit': 'bps',    'ylabel': 'Rx Speed UDP',           'ydata': 'Сеть RemoteFX\Скорость получения UDP-данных'},    {'yscale': 1000,    'yunit': 'bps', 'ylabel': 'Bandwidth UDP', 'ydata': 'Сеть RemoteFX\Пропускная способность текущего UDP-подключения'},    {'yunit': 'bps',    'ylabel': 'Tx Speed TCP',           'ydata': 'Сеть RemoteFX\Скорость отправки TCP-данных'},    {'yunit': 'bps',    'ylabel': 'Rx Speed TCP',           'ydata': 'Сеть RemoteFX\Скорость получения TCP-данных'},    {'yscale': 1000,    'yunit': 'bps', 'ylabel': 'Bandwidth TCP', 'ydata': 'Сеть RemoteFX\Пропускная способность текущего TCP-подключения'},]
Jupiter Notebook: отрисовка одной метрики на диаграмму
for i in range(len(fgs)):  # сколько метрик, столько рисунков (рядов диаграмм)    fig, axs = plt.subplots(1, 3, figsize=(img_sx, img_sy), sharex='col', sharey='row', gridspec_kw=dict(hspace=0, wspace=0, ))  # width_ratios=[1, 1, 1]    fig_name = fgs[i]['ydata'].split('\\')[1]    fig.suptitle(f'Рис. {i + 1:>2}. {fig_name}', fontsize=14)  #, color='grey')  # имя рисунка    fig.patch.set_facecolor('white')  # фон рисунка белый вместо прозрачного    axs[0].set(ylabel=fgs[i]['ylabel'])  # подпись Y-оси только на первых (левых) графиках из трёх    axs[2].yaxis.set_tick_params(labelleft=False, labelright=True, which='major')  # дублируем значения справа    for ax, d, title in zip(axs, dataframes, ax_titles):  # на каждый тест своя диаграмма        ax.plot(d.index.values, d[fgs[i]['ydata']] * (fgs[i].get('yscale', 1)))  # строим график        ax.set_title(title)  #, color='grey')  # заголовок диаграммы                ax.xaxis.set_tick_params(which='major', labelcolor='grey')  # подписи к X-шкале        ax.xaxis.set_major_formatter(EngFormatter(unit='s'))  # по X секунды        ax.yaxis.set_tick_params(which='major', labelcolor='grey')  # подписи Y-шкале        ax.yaxis.set_major_formatter(EngFormatter(unit=fgs[i]['yunit']))  # по Y у каждого графика своя ед. изм.        # расчёт средних и вывод в легенду диаграммы "на лету"        avg = [EngFormatter(places=0).format_eng(avg * (fgs[i].get('yscale', 1))) for avg in d[fgs[i]['ydata']].mean()]        lgn = [f'avg {m}{fgs[i]["yunit"]}, {l}' for l, m in zip(legend, avg)]        ax.legend(lgn, fontsize=8)  # отображение легенды графика        ax.grid(axis='y')  # горизонтальная сетка        ax.set_xlim(0,119)  # метка "120" засоряла график        if ax == axs[1]:  # выделяем аномалии на средней диаграмме            ax.axvline(x=15, linestyle=":", color='C0')            ax.axvline(x=58, linestyle=":", color='C0')            ax.axvline(x=101, linestyle=":", color='C0')        fig.tight_layout()  # (pad=0.4, w_pad=1.5, h_pad=30.0)
Jupiter Notebook: отрисовка всех метрик на одной диаграмме

Общая ось X на все графики: метрики тестов располагаются строго друг под другом - удобно сопоставлять разные метрики между собой.

# один рисунок  # plt.style.available  # plt.style.use('seaborn-whitegrid')fig, axs = plt.subplots(len(fgs), 3, figsize=(img_sx, img_sy * len(fgs)), sharex='col', sharey='row', gridspec_kw=dict(hspace=0.2, wspace=0))fig.patch.set_facecolor('white')  # фон рисунка белый вместо прозрачного# заголовки только вверху[ax.set_title(title) for ax, title in zip(axs[0], ax_titles)]  # ax.set_title(title, color='grey')for i in range(len(fgs)):    axs[i,0].set(ylabel=fgs[i]['ylabel'])    fig_name = fgs[i]['ydata'].split('\\')[1]    axs[i,1].set(xlabel=f'Рис. {i + 1:>02}. {fig_name}')    # axs[i,1].xaxis.label.set_color('grey')    axs[i,2].yaxis.set_tick_params(labelleft=False, labelright=True, which='major')    for ax, d, title in zip(axs[i], dataframes, ax_titles):        ax.plot(d.index.values, d[fgs[i]['ydata']] * (fgs[i].get('yscale', 1)))        ax.xaxis.set_tick_params(which='major', labelcolor='grey')  # подписи к X-шкале        ax.xaxis.set_major_formatter(EngFormatter(unit='s'))  # по X секунды        ax.yaxis.set_tick_params(which='major', labelcolor='grey')  # подписи Y-шкале        ax.yaxis.set_major_formatter(EngFormatter(unit=fgs[i]['yunit']))  # по Y у каждого графика своя ед. изм.        # расчёт средних и изменение легенды диаграммы "на лету"        avg = [EngFormatter(places=0).format_eng(avg * (fgs[i].get('yscale', 1))) for avg in d[fgs[i]['ydata']].mean()]        lgn = [f'avg {m}{fgs[i]["yunit"]}, {l}' for l, m in zip(legend, avg)]        ax.legend(lgn, fontsize=8)  # отображение легенды графика        ax.grid(axis='y')  # горизонтальная сетка        ax.set_xlim(0,119)  # метка "120" засоряла график        if ax == axs[i,1]:  # выделяем аномалии на средней диаграмме            ax.axvline(x=15, linestyle="--", color='C0')            ax.axvline(x=58, linestyle="--", color='C0')            ax.axvline(x=101, linestyle="--", color='C0')
Диаграмма со всеми графиками

Продолжение истории будет на следующей неделе. Спасибо за внимание!


Что ещё интересного есть в блогеCloud4Y

Частые ошибки в настройках Nginx, из-за которых веб-сервер становится уязвимым

Пароль как крестраж: ещё один способ защитить свои учётные данные

Тим Бернерс-Ли предлагает хранить персональные данные в подах

Подготовка шаблона vApp тестовой среды VMware vCenter + ESXi

Создание группы доступности AlwaysON на основе кластера Failover

Подписывайтесь на нашTelegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.

Подробнее..

Recovery mode Собираем сервер для графических и CADCAM приложений для удаленной работы по RDP на базе бу CISCO UCS-C220 M3 v2

04.07.2020 20:20:46 | Автор: admin
imageПочти у каждой компании сейчас обязательно есть отдел или группа работающая в CAD/CAM
или тяжелых дизайнерских программах. Эту группу пользователей объединяет серьёзные требования к железу: много памяти 64ГБ и больше, профессиональная видеокарта, быстрый ssd, и чтобы было надежное. Зачастую компании покупают некоторым пользователям таких отделов несколько мощных ПК (или графических станций) и остальным менее мощные в зависимости от потребностей, а также финансовых возможностей компании. Зачастую это стандартный подход для решения таких задач, и он нормально работает. Но во время пандемии и удаленной работы, да и в общем такой подход неоптимален, очень избыточен и крайне неудобен в администрировании, управлении и прочих аспектах. Почему это так, и какое решение идеально удовлетворит потребности в графических станциях многих компаний? Прошу пожаловать под кат, где описано как собрать рабочее и недорогое решение, чтобы убить накормить сразу нескольких зайцев, и какие мелкие нюансы нужно учесть, чтобы успешно внедрить это решение.
В декабре прошлого года одна компания открывала новый офис для небольшого КБ и была поставлена задача организовать им всю компьютерную инфраструктуру учитывая, что ноутбуки для пользователей и пару серверов у компании уже есть. Ноутам уже было пару лет и это были в основном игровые конфигурации с 8-16ГБ ОЗУ, и в основном не справлялись с нагрузкой от CAD/CAM приложений. Пользователи должны быть мобильными, так как часто необходимо работать не из офиса. В офисе к каждому ноуту дополнительно покупается еще по монитору (так работают с графикой). При таких входных данных единственно оптимальное, но рискованное для меня решение внедрить мощный терминальный сервер с мощной профессиональной видеокартой и nvme ssd диском.

Преимущества графического терминального сервера и работы по RDP


  • На отдельных мощных ПК или графических станциях большую часть времени аппаратные ресурсы не используются даже на треть и простаивают без дела и только короткий период времени используются в 35-100% своей мощности. В основном КПД составляет 5-20 процентов.
  • Но часто аппаратная часть далеко не самая затратная составляющая, ведь базовые графические или САД/CAM лицензии на ПО часто стоят от 5000$, а если еще с расширенными опциями то и от 10 000$. Обыкновенно в сеансе RDP эти программы запускаются без проблем, но иногда необходимо дозаказывать RDP опцию, либо поискать по форумам что прописать в конфигах или реестре и как запустить в сеансе RDP такое ПО. Но проверить, что нужное нам ПО работает по RDP нужно в самом начале и сделать это просто: пробуем зайти по RDP если программа запустилась и работают все базовые программные функции, то и проблем с лицензиями скорее всего не будет. А если выдает ошибку, то перед реализацией проекта с графическим терминальным сервером, ищем удовлетворительное для нас решение проблемы.
  • Также большим плюсом есть поддержка одинаковой конфигурации и специфических настроек, компонентов и шаблонов, что часто труднореализуемо для всех ПК пользователей. Управление, администрирование и обновление ПО тоже без сучка и задоринки

В общем плюсов много посмотрим как на деле покажет наше почти идеальное решение.

Собираем сервер на базе бу CISCO UCS-C220 M3 v2


Изначально планировалось купить поновее и мощный сервер с 256ГБ DDR3 ecc памятью и 10GB ethernet, но сказали что нужно немного сэкономить и вписаться в бюджет на терминальный сервер 1600$. Ну ладно клиент всегда жадный прав и подбираем под эту сумму:
бу CISCO UCS-C220 M3 v2 (2 X SIX CORE 2.10GHZ E5-2620 v2) \128ГБ DDR3 ecc 625$
3.5" 3TB sas 7200 з США д 2x65$=130$
SSD M.2 2280 970 PRO, PCI-E 3.0 (x4) 512GB Samsung 200$
Видеокарта QUADRO P2200 5120MB 470$
Адаптер Ewell PCI-E 3.0 to M.2 SSD (EW239) -10$
Итого за сервер = 1435$
Планировалось брать ssd 1TB и 10GB ethernet adapter 40$, но выяснилось, что UPS к их 2 серверам не было, и пришлось немного ужаться и купить UPS PowerWalker VI 2200 RLE -350$.

Почему сервер, а не мощный ПК? Обоснование выбранной конфигурации.


Многие недальновидные админы (много раз уже сталкивался) почему то покупают мощный (зачастую игровой ПК), ставят там 2-4 диска, создают RAID 1, гордо называют это сервером и ставят его в углу офиса. Естественна вся комлектуха сборная солянка сомнительного качества. Поэтому распишу подробно почему подобрана под такой бюджет именно такая конфигурация.
  1. Надежность!!! все серверные комплектующие спроектированы и протестированы для работы более 5-10 лет. А игровые мамки от силы работают 3-5 лет и даже процент поломки во время гарантийного срока у некоторых превышает 5%. А наш сервер от супернадежного бренда CISCO, так что особых проблем не предвидится и их вероятность на порядок ниже стационарного ПК
  2. Важные компоненты типа блока питания дублируются и в идеале можно подать питание с двух разных линий и при выходе из строя одного блока сервер продолжает работать
  3. Память ECC сейчас мало кто помнит, что изначально память ECC была введена для коррекции одного бита от ошибки, возникающей в основном от воздействия космических лучей, а на объёме памяти 128ГБ ошибка может возникать несколько раз в году. На стационарном ПК мы можем наблюдать вылет программы, зависание и прочее, что некритично, но на сервере цена ошибки иногда очень высока (например неправильная запись в БД), в нашем случае при серьезном глюке надо перегрузится и иногда это стоит дневной работы нескольких человек
  4. Масштабируемость часто потребность компании в ресурсах вырастает в несколько раз за пару лет и в сервер легко добавить памяти дисков, поменять процессоры (в нашем случае шестиядерные E5-2620 на десятиядерные Xeon E5 2690 v2) на обычном ПК почти никакой масштабируемости
  5. Серверный формат U1 серверы должны стоять в серверных! и в компактных стойках, а не кочегарить(до 1КВт тепла) и шуметь в углу офиса! Как раз в новом офисе компании отдельно предоставлялось немного (3-6 юнитов) место в серверной и один юнит на наш сервер как раз был нам впритык.
  6. Удаленные: управление и консоль без этого нормальное обслуживание сервера для удаленной! работы крайне затруднительно!
  7. 128Гб ОЗУ в ТЗ было сказано 8-10 пользователей, но в реальности будет 5-6 одновременных сессий поэтому учитывая типичный в той компании максимальный расход объёма памяти 2 пользователя по 30-40ГБ=70ГБ и 4 юзера по 3-15ГБ=36ГБ, + до 10ГБ на операционку в сумме 116ГБ и 10% у нас в запасе(это все в редких случаях максимального использования. Но если будет не хватать то в любой момент можно добавить до 256ГБ
  8. Видеокарта QUADRO P2200 5120MB в среднем на пользователя в той компании в
    удаленном сеансе расход видеопамяти был от 0,3ГБ до 1,5ГБ, так что 5ГБ будет достаточно. Исходные данные были взяти с аналогичного, но менее мощного решения, на базе i5/64ГБ/Quadro P620 2ГБ, которого хватало на 3-4 пользователя
  9. SSD M.2 2280 970 PRO, PCI-E 3.0 (x4) 512GB Samsung для одновременной работы
    8-10 пользователей, необходимо именно скорости NVMe и надежность ssd Samsung. По функционалу этот диск будет использоваться для ОС и приложений
  10. 2х3TB sas объединяем в райд 1 используем для объёмных или редкоиспользуемых локальных данных пользователей, а также для бекапа системы и критическо важных локальных данных с диска nvme

Конфигурация одобрена и куплена, и вот скоро настанет момент истины!

Сборка, настройка, установка и решение проблем.


С самого начала у меня не было уверенности, что это 100% рабочее решение, так как на любом этапе, начиная со сборки заканчивая установкой, запуском и корректной работой приложений можно было застрять без возможности продолжить, поэтому про сервер я договорился, что его в течении пару дней можно будет вернуть, а другие компоненты можно использовать в альтернативном решении.
1 надуманная проблема видеокарта профессиональная, полноформатная! +пару мм, а что если не влезит? 75вт а что если pci разьем не потянет? И как нормальный теплоотвод этих 75вт сделать? Но влезла, запустилась, теплоотвод нормальный(особенно если кулеры сервера включить на обороты выше среднего. Правда когда ставил, для уверенности что бы ничего не замыкало что-то в сервере на 1мм отогнул (уже не помню что), а для лучшего теплоотвода с крышки сервера потом после окончательной настройки отодрал пленку инструкции, которая была на всю крышку и которая могла ухудшать теплоотвод через крышку.
2-е ипытание NVMe диск через переходник мог не увидится либо система туда не поставится, а если поставится, то не загрузится. Как ни странно Windows поставилась на NVMe диск, но загрузится с него не смогла, что логично так как биос(даже обновленный) ни в какую распознавать для загрузки NVMe не хотел. Не хотел костылить, но пришлось тут пришел на помощь наш любимый хабр и пост про загрузку с nvme диска на legacy системах скачал утилитку Boot Disk Utility (BDUtility.exe), создал флешку с CloverBootManager по инструкции из поста, установил флешку в биосе первой на загрузку и вот мы уже грузим загрузчик с флешки, Clover успешно увидел наш NVMe диск и через пару секунд автоматично с него загрузился! Можно было поиграться с установкой clover на наш raid 3TB диск, но было уже субота вечер, а работы оставалось еще на день, ведь до понедельника нужно было или отдавать сервер или оставлять. Загрузочную флешку оставил внутри сервера, там как раз был лишний usb.
3-я почти угроза провала. Поставил Windows 2019 standart +RD сервисы, установил главное приложение, ради которого всё затевалось, и всё чудесно работает и буквально летает. Замечательно! Еду домой и подключаюсь по RDP, приложение запускается, но ощущается серьёзный лаг, смотрю а в проге сообщение включен soft режим. Чего?! Ищу более свежие и суперпрофессиональные дрова на видеокарту, ставлю -результата ноль, более древние дрова под p1000 тоже ничего. А в это время внутренний голос всё издевается а я тебе говорил не экспериментируй со свежачком возьми p1000. А время уже давно ночь во дворе, с тяжелым сердцем ложусь спать. Воскресенье, еду в офис ставлю в сервер quadro P620 и тоже по RDP не работает MS в чем дело? Ищу по форумам 2019 server и RDP ответ нашел почти сразу. Оказывается, что так как у большинства сейчас мониторы с большим разрешением, а в большинстве серверов встроенный графический адаптер эти разрешения не поддерживает то аппаратное ускорение по умолчанию отключено через групповые политики. Цитирую инструкцию по включению:
  • Open the Edit Group Policy tool from Control Panel or use the Windows Search dialog (Windows Key + R, then type in gpedit.msc)
  • Browse to: Local Computer Policy\Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Remote Session Environment
  • Then enable Use the hardware default graphics adapter for all Remote Desktop Services sessions

Перезагружаемся все прекрасно по RDP работает. Меняем видеокарту на P2200 опять работает! Теперь когда мы уверены, что решение полностью рабочее приводим все настройки сервера к идеалу, вводим в домен, настраиваем доступ пользователей и прочее, ставим сервер в серверную. Тестируем всей командой пару дней всё идеально работает, на все задачи ресурсов сервера хватает с избытком, минимальный лаг возникающий в результате работы по RDP всем пользователям незаметен. Замечательно задача выполнена на 100%.

Пару моментов, от которых зависит успешность внедрения графического сервера.


Так как на любом этапе внедрения графического сервера в организацию могут возникнуть подводные камни, которые могут создать ситуацию аналогичную как на картинке со сбежавшими рыбкамиimage
то на этапе планирования необходимо сделать несколько простых шагов:
  1. Целевая аудитория и задачи пользователи которые интенсивно работают с графикой и им нужно аппаратное ускорение видеокарты. Успех нашего решения основан на том, что потребности в мощности пользователей графических и CAD/CAM программ был удовлетворен с избытком более 10 лет назад, а на данный момент мы имеем запас мощности превышающий потребности в 10 и более раз. Например мощности GPU Quadro P2200 хватает с избытком на 10 пользователей, и даже при недостатке памяти видеопамяти видеокарта добирает с ОЗУ, и для обычного 3d разработчика такое небольшое падение в скорости памяти проходит незаметно. Но если в задачах пользователей есть интенсивные вычислительные задачи (рендеринг, расчеты и прочее), которые часто задействуют 100% ресурсов то наше решение не подходит, так как другие пользователи в эти периоды не смогут нормально работать. Поэтому тщательно анализируем задачи пользователей и текущую загрузку ресурсов (хотя бы приблизительно).
  2. Исходя из количества пользователей подбираем подходящий по ресурсам сервер, видеокарту и диски:
    процессоры по формуле 1 ядро на пользователя + 2,3 на ОС, все равно каждый в один момент времени не использует одного или максимум двух(при редкой загрузке модели) ядер;
    видеокарта -смотрим средний объём потребления видеопамяти и GPU на пользователя в сеансе RDP и подбираем профессиональную! видеокарту;
    аналогично поступаем с ОЗУ и дисковой подсистемой(сейчас можно даже RAID nvme недорого подобрать).
  3. Тщательно смотрим по документации к серверу (благо все брендовые сервера имеет полную документацию) соответствие по разъёмам, скоростям, питанию и поддерживаемым технологиям, а также физическим размерам, и нормам теплоотвода устанавливаемых дополнительных компонентов.
  4. Проверяем нормальную работу нашего ПО по RDP на отсутствие лицензионных ограничений и наличие необходимых лицензий. Решаем этот вопрос до первых шагов по реализации внедрения.
  5. Продумываем где будет установлен графический сервер, не забываем про UPS и наличие там высокоскоростных ethernet портов и интернет (если нужно), а также соответствие климатических требованиям сервера.
  6. Термин внедрения увеличиваем минимум до 2,5-3 недель, ведь многие даже мелкие необходимые компоненты могут ехать до двух недель, а ведь сборка и настройка проходит несколько дней только обычная загрузка сервера до ОС может быть более 5 минут.
  7. Обговариваем с руководством и поставщиками, что если вдруг на каком либо этапе проект не пойдет или пойдет не так, то можно сделать возврат или замену.
  8. Операционную систему (желательно Windows server 2019 там качественный RDP) устанавливаем вначале в Trial режиме, но ни в коем случае не evaluate (нужно потом переустанавливать с нуля). И только после успешного запуска решаем вопросы с лицензиями и активируем ОС.
  9. Также до внедрения подбираем инициативную группу для проверки работы и объясняем будущим пользователям преимущества работы с графическим сервером. Если это делать после, то увеличиваем риск рекламаций, саботажа и неаргументированных негативных отзывов.

По ощущениям работа по RDP не отличается от работы в локальном сеансе. Часто даже забываешь, что работаешь где-то по RDP ведь даже видео и иногда видеосвязь в сеансе RDP работают без ощутимых задержек, ведь сейчас у большинства подключен высокоскоростной интернет. По скорости и функционалу RDP компания Microsoft сейчас продолжает приятно удивлять и аппаратное ускорение 3D и мультимониторы все что необходимо для удаленной работы пользователям графических, 3D и CAD/CAM программ!
Так что во многих случаях установка графического сервера согласно проведенного внедрения является предпочтительней и мобильней 10 графических станций или ПК.
P.S. Как просто и безопасно подключиться через интернет по RDP, а также оптимальные настройки для RDP клиентов вы можете подсмотреть в статье "Удаленная работа в офисе. RDP, Port Knocking, Mikrotik: просто и безопасно"
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru