Уровень безопасности сервера терминалов обнаружил ошибку в потоке протокола и отключил этот клиент windows 7
Обновлено: 07.07.2024
Авторизуясь в LiveJournal с помощью стороннего сервиса вы принимаете условия Пользовательского соглашения LiveJournal
Всем стабильности и капельку термопасты в этот неоднозначный, мать его, вторник!
Извините, но я снова про Шиндоус спросить..
Поднял на W2008R2 SP1 сервер удаленных рабочих столов. В целом полет нормальный. Подключаются клиенты под доменными учетками с недоменных ОС WinXP и Win7. Но один клиент на Win7 сервер периодически выкидывает (не часто), ругаясь в системном журнале ошибками:
- TermDD 56 "Уровень безопасности сервера терминалов обнаружил ошибку в потоке протокола и отключил этот клиент. IP-адрес клиента: 172.16.122.10."
- TermDD 50 "Компонент X.224 RDP-протокола обнаружил ошибку в потоке протокола и отключил этого клиента"
После чего клиента не пускает даже после ввода правильного пароля учетки в RDP-клиенте. Помогает создание учетки в диспетчере учетных данных заново. Безопасность на RDP-сервере выставлена по минимуму. Эти же ошибки есть и по другим подключающимся клиентам, большинство из которых WinXP, но в XP эта проблема встречается реже (хотя и клиентов на XP 95%) и решается проще - ввел пароль в RDP-клиенте заново и всё.
Копать в сторону антивируса (точнее его отсутствия) на локальных ПК
антивирус стирает сохраненную учетку? это что-то новенькое..
>>Но один клиент на Win7 сервер периодически выкидывает (не часто), ругаясь в системном журнале ошибками:
-
>>Помогает создание учетки в диспетчере учетных данных заново
-
сдается мне, стирает УЗ не антивирус.
а что тогда? там TS RemoteApp запиливает свой RDP-файл, который на WinXP хранит пароль как-то иначе чем на Win7. Я пока только это понял.
у меня такие сессии как-то пытался перехватить троян. что вызывало отлуп подключения. обновил базы, убил трояна - все прошло.
некоторые антивирусы имеют функционал срубать коннекшны от не нравящихся им клиентов с разными забавными эффектами.
так что первый вопрос - наличие на сервере антивируса с функцией файрвола
на сервере стоит серверный ESET File Security, но там вроде как только защита доступа в интернет, и та выключена
За 2020 год из пары десятков тысяч посетителей, набралось всего пару десятков перечислений от 50 до 300 рублей.
Пустяк в денежном выражении, но большая ценность для автора. Посмотрим что год грядущий нам готовит ))
Сумма абсолютно не важна - главное участие.
На терминальных серверах постоянно стали появляться необъяснимые события. Ошибка 50, источник TermDD, компонент X.224 RDP-протокола обнаружил ошибку в потоке протокола и отключил этого клиента (The RDP protocol component X.224 detected an error in the protocol stream and has disconnected the client.).
Никаких данных, позволяющих идентифицировать клиента в событии нет. И, что интересно, никто из пользователей не жалуется на проблемы с подключением или прерывания сеансов.
Форумы:
Поиск решений в Интернет
Дополнительно задумался, отсортировал по времени - оказывается события возникают круглосуточно. Опросил пользователей - работают максимум до 22:00. Кроме того события возникают также на HyperV сервере куда кроме меня никто подключаться не должен и тоже случайным образом в течении суток.
Выслеживаем с MS Network Monitor
Решил попробовать выследить 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 Сервер его естественно отрубает и генерит событие.
Что делать
Нужно ли что-то делать в данной ситуации? Вроде бы нет, сервер сам отрубает неправильные попытки подключений. На всякий случай на firewall заблокировал входящий трафик с вычисленных IP. Пока помогло - события по ошибке не появляются.
Что это было? Тоже не совсем понятно. Похоже на попытку вычисления RDP серверов с низким уровнем безопасности.
Небольшая деталь: после получения отказа от сервера известные мне RDP клиенты завершают TCP сессию посылая серверу пакет с флагом FIN. В отловленном примере, клиент после сброса соединения сервером никаких пакетов больше не шлет:
Этот момент говорит, что скорее всего используется самописанное ПО.
NCRACK
Наловил еще кучу 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
Если они будут создавать
Если они будут создавать некторую ощутимую нагрузку? Как их отсечь правильно?
на сетевом оборудовании
То что из внешней сети приходят нежелательные пакеты - сетевая проблема и правильно решать ее на уровне сетевого оборудования
Как правильно? Зависит от возможностей оборудования.
УдаленнымРабочимСтолом,
УдаленнымРабочимСтолом, хотелось бы пользоваться. Мне видилось решение что, как -то этакие запросы, отлавливать и добавлять в правило фаервола. Типо банить по айпи на 15 минут. Потом убирать. Или это не выход?
сложно и неэффективно
Я еще раз отмечу, что данную проблему надо решать на уровне сетевого оборудования.
Например, сервер наружу не публиковать, а реализовать доступ во внутреннюю сеть с помощью VPN.
Можно конечно сделать и "пятиминутное решение" - задать нестандартный порт для RDP и периодически его менять. Стандартные сканеры не сканируют весь диапазон портов на предмет наличия на них RDP.
Имя журнала: System
Источник: TermDD
Дата: 10.02.2010 17:25:48
Код события: 50
Категория задачи:Отсутствует
Уровень: Ошибка
Ключевые слова:Классический
Пользователь: Н/Д
Компьютер: tr0yPC
Описание:
Компонент X.224 RDP-протокола обнаружил ошибку в потоке протокола и отключил этого клиента
Имя журнала: System
Источник: TermDD
Дата: 10.02.2010 17:25:48
Код события: 56
Категория задачи:Отсутствует
Уровень: Ошибка
Ключевые слова:Классический
Пользователь: Н/Д
Компьютер: tr0yPC
Описание:
Уровень безопасности сервера терминалов обнаружил ошибку в потоке протокола и отключил этот клиент. IP-адрес клиента: 192.168.0.124.
всё что удалось найти касается других ОС и не применимо к windows7
Я сделал проще - согласно моей безопасности я просто добавил локалку в сеть Домашняя и переключил на 56 бит.
Подключился по РДП с ХР и вин2003.
А если попробовать добавить в список криптопровайдеров OpenSSL - сегодня это уже версия 1.00 в сорцах и использовать его возможности для защиты подключения? Тут дело по моему более серьёзное - экспортные ограничение на криптостойкость шифров по Законам США. Но, согласно ФЗ "Федеральный закон Российской Федерации от 27 июля 2006 г. N 149-ФЗ Об информации, информационных технологиях и о защите информации" владелец информации самостоятельно определяет адекватные меры по её защите от несанкционированного доступа (НСД). И Экспортные ограничения установленные законодательством третьих стран на территории РФ после пересечения таможенной границы и начала применения изделия по прямому назначению потребителем не распространяются на принимаемые им решения. Этот официальный ответ мне дали в ФСБ когда по роду работы мы строили систему защиты своей конторы от НСД к информации содержащей коммерческую тайну. Есть только одно ограничение - каналы передачи данных выходящие на сети общего пользования должны защищаться с помощью сертифицированных для применения на территории РФ средств предотвращения НСД и защиты информации и при необходимости проходить специальную криптографическую экспертизу соответствия требованиям ФЗ РФ в органах ФСБ.
Вопрос по названию ветки: "невозможно подключиться по RDP к Windows 7 x64".
Ситуация такая:
- W7 SP1 Корпоративная русская,
- рабочая группа настроена, расшаренные ресурсы работают,
- стоят 2 протокола IP4 и IP6 - IP6 не стал сносить, но он не нужен.
- как клиент для вызова удаленных рабочих столов с др. компьютеров и операционок MS этот комп работает,
- локальная учётная запись с непустым паролем есть,
- брандмауэр отключен.
Причины ошибки "Повторите попытку подключения"
В прошлый раз мы с вами победили ошибку с синим экраном dpc watchdog violation, победим и эту, но для начала нужно понять причину всего этого действия. Вот как выглядит данная проблема:
Как я и писал выше, появляется она после ввода корректного логина и пароля.
- Вся эта канитель началась еще с 2014 года, после обновлений KB2992611 и последующих. В момент установки данных обновлений ужесточился уровень безопасности и шифрования.
- Вторая возможная причина, это наличие программ КриптоПро или VipNet, у меня был именно второй вариант
- Другие сторонние программные обеспечения по шифрованию.
Если вы посмотрите логи Windows, то сможете обнаружить вот такие системные предупреждения:
- возникло следующее неустранимое предупреждение: 36888. Внутренне состояние ошибки: 1250
- Компонент X.224 RDP-протокола обнаружил ошибку в потоке протокола и отключил этого клиента.
Как решить ошибку с RDP подключением
Существует несколько методов решения ошибки "Не удается подключиться к удаленному компьютеру. Повторите попытку подключения. Если проблема повторится, обратитесь к владельцу удаленного компьютера." что вы должны сделать:
- Удалить необходимые обновления Windows
- Удаление или обновление "Крипто ПРО" и VipNet
- Понижение требования к уровню шифрования
- Установка дополнительных обновлений
Удаление или обновление ПО
Начинаю я с этого метода, так как он самый правильный и с точки удобства и с точки безопасности. Если вам данное ПО не нужно, то советую его удалить его и провести очистку системы от мусора, если же программы нужны, то рассмотрите вариант их обновления на свежие версии в которых уже таких проблем нет. В моем случае это не получилось сделать, так как мне была необходима старая версия VipNet.
Удаления обновления KB2992611
Следующим методом я вам посоветую установка новых обновлений, которые это решают, могу посоветовать KB3018238 (оно идет теперь вместе с KB2992611) и KB3011780, с ходом времени, данные обновления могут перекрываться уже более новыми, так, что следите за ними на официальном сайте Microsoft. Если KB2992611 установлено, то попробуйте его удалить, проверить возможность подключения и снова поставить.
Скачиваете и производите обновление, это похоже на шаги описанные в проблеме, где windows 7 не находит обновления, мы так же устанавливали автономные версии.
Понижение требования к уровню шифрования
Не самое правильное решение, так как уменьшает уровень защиты и шифрования трафика, но может быть палочкой-выручалочкой в некоторых ситуациях. В настройках сервера терминалов снизить уровень "безопасности/уровень шифрования". Для этого заходите в "Пуск > Администрирование > Удаленный рабочий стол > Конфигурация узла сеансов удаленного рабочего стола", выбираете "Настройка для сервер", далее вкладка "Общие" и два пункта:
- Уровень безопасности > Уровень безопасности RDP
- Уровень шифрования > Низкий
Все теперь повторите подключение и повторите попытку зайти по RDP, ошибка должна исчезнуть, но поищите возможность все же обновиться.
Читайте также: