На терминальных серверах постоянно стали появляться необъяснимые события. Ошибка 50, источник TermDD, компонент X.224 RDP-протокола обнаружил ошибку в потоке протокола и отключил этого клиента (The RDP protocol component X.224 detected an error in the protocol stream and has disconnected the client.).
Никаких данных, позволяющих идентифицировать клиента в событии нет. И, что интересно, никто из пользователей не жалуется на проблемы с подключением или прерывания сеансов.
Поиск решений в Интернет
Опубликовано пользователем manager
Как оказалось событие может быть вызвано очень широким кругом причин (например см. http://www.eventid.net/display.asp?eventid=50&eventno=606&source=TermDD&...). Перебирая их поочереди пришел к выводу, что это все не мой случай.
Дополнительно задумался, отсортировал по времени - оказывается события возникают круглосуточно. Опросил пользователей - работают максимум до 22:00. Кроме того события возникают также на HyperV сервере куда кроме меня никто подключаться не должен и тоже случайным образом в течении суток.
Выслеживаем с MS Network Monitor
Опубликовано пользователем manager
Решил попробовать выследить IP с которых производятся попытки подключений. Установил Network Monitor от Microsoft - замечательная вещь уже не раз выручавшая меня в тупиковых ситуациях. Поставил фильтр на захватываемые пакеты TCP.DstPort == 3389 и оставил на ночь.
Поутру просмотрел улов. C 11 IP адресов создавались TCP сессии на 3389 и сразу сбрасывались без передачи каких-либо данных.
А с двумя IP (109.228.6.126 и 46.163.106.199) было интереснее. Создается TCP сессия и посылается пакет X244 Connection request с именем пользователя из одной буквы a или g. Время посылки этих пакетов совпадает с временем генерации событий на сервере.
Пакет выглядит вот так:
Здесь видно, что клиент сразу переходит к аутентификации с именем пользователя g. Не пытается использовать Network Level Authentication и не договаривается с сервером об используемом протоколе безопасности.
Собственно проблема ясна, кто-то зачем-то пытается подсоединиться к серверу, без учета что он настроен на использование NLA и TLS 1.0 Сервер его естественно отрубает и генерит событие.
Что делать
Опубликовано пользователем manager
Нужно ли что-то делать в данной ситуации? Вроде бы нет, сервер сам отрубает неправильные попытки подключений. На всякий случай на firewall заблокировал входящий трафик с вычисленных IP. Пока помогло - события по ошибке не появляются.
Что это было? Тоже не совсем понятно. Похоже на попытку вычисления RDP серверов с низким уровнем безопасности.
Небольшая деталь: после получения отказа от сервера известные мне RDP клиенты завершают TCP сессию посылая серверу пакет с флагом FIN. В отловленном примере, клиент после сброса соединения сервером никаких пакетов больше не шлет:
Этот момент говорит, что скорее всего используется самописанное ПО.
NCRACK
Опубликовано пользователем Anonymous (не проверено)
Наловил еще кучу IP с которых производится сканирование:
87.251.172.232
176.53.17.228
112.123.170.3
188.130.251.14
188.212.152.102
79.175.153.90
96.241.201.15
85.10.52.102
218.62.10.215
173.9.114.153
80.93.220.79
210.74.159.213
122.226.56.145
187.66.189.50
212.105.73.250
187.141.53.102
94.56.143.169
Использовались имена пользователей: admin, Administrator, micros, NCRACK_USER
Последнее подсказывает, что сканирование производится с помощью сканера сетевой безопасности NCRACK
Если они будут создавать
Опубликовано пользователем Антон (не проверено)
Если они будут создавать некторую ощутимую нагрузку? Как их отсечь правильно?
на сетевом оборудовании
Опубликовано пользователем manager
То что из внешней сети приходят нежелательные пакеты - сетевая проблема и правильно решать ее на уровне сетевого оборудования
Как правильно? Зависит от возможностей оборудования...
УдаленнымРабочимСтолом,
Опубликовано пользователем Антон (не проверено)
УдаленнымРабочимСтолом, хотелось бы пользоваться. Мне видилось решение что, как -то этакие запросы, отлавливать и добавлять в правило фаервола. Типо банить по айпи на 15 минут. Потом убирать. Или это не выход?
сложно и неэффективно
Опубликовано пользователем manager
Я еще раз отмечу, что данную проблему надо решать на уровне сетевого оборудования.
Например, сервер наружу не публиковать, а реализовать доступ во внутреннюю сеть с помощью VPN.
Можно конечно сделать и "пятиминутное решение" - задать нестандартный порт для RDP и периодически его менять. Стандартные сканеры не сканируют весь диапазон портов на предмет наличия на них RDP.