3389 tcp microsoft rdp уязвимость как исправить

Хотя уязвимость BlueKeep (CVE-2019-0708) до настоящего времени не вызвала широкомасштабного хаоса, и мы рассмотрим причины этого в данном посте, она все еще находится на очень ранней стадии жизненного цикла ее использования. Факт остается фактом, что многие системы все еще не исправлены, и все еще можно найти версию эксплойта, обладающую всем потенциалом червя. С учетом этих факторов компания ESET создала бесплатную утилиту для проверки уязвимости системы.

Инструмент обнаружения ESET BlueKeep (CVE-2019-0708)

Скачать инструмент

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

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

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

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

Что такое RDP?

RDP (аббревиатура английского термина «Протокол удаленного рабочего стола») позволяет одному компьютеру подключаться к другому компьютеру по сети и использовать последний удаленно. В домене компьютеры с операционной системой Windows Client, такой как Windows XP или Windows 10, поставляются с предустановленным клиентским программным обеспечением RDP как частью операционной системы, что позволяет им подключаться к другим компьютерам в сети, включая сервер(-ы) организации. Соединение с сервером в этом случае означает, что он может быть напрямую подключен к операционной системе сервера или к операционной системе, работающей внутри виртуальной машины на этом сервере. Благодаря этому соединению человек может открывать каталоги, загружать и выгружать файлы, а также запускать программы, как если бы они использовали клавиатуру и монитор, подключенные к этому серверу.

RDP был изобретен компанией Citrix в 1995 году и продавался как часть расширенной версии Windows NT 3.51 под названием WinFrame. В 1998 году компания Microsoft добавила RDP в Windows NT 4.0 Terminal Server Edition. С тех пор этот протокол входит в состав всех версий линейки операционных систем Microsoft Windows компании Microsoft и после выпуска Windows XP в 2001 году включается во все версии операционных систем Windows Client, кроме версий для пользователей домашних компьютеров. Сегодня обычными пользователями RDP являются системные администраторы, выполняющие удаленное администрирование серверов из своих кабинетов без необходимости заходить в серверную комнату, а также удаленные работники, которые могут подключаться к виртуализированным настольным компьютерам внутри домена своей организации.

Что злоумышленники делают с RDP?

В течение последних нескольких лет ESET фиксирует рост числа случаев, когда злоумышленники через Интернет, используя RDP, удаленно подключаются к Windows Server и входят в систему как администратор компьютера. После того как злоумышленники входят на сервер как администратор, они, как правило, проводят разведку, чтобы определить, для чего сервер используется, кем и когда.

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

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

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

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

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

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

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

Рисунок 1: Сообщение электронной почты аферы «сексуального вымогательства», упоминающей RDP

Для получения дополнительной информации об этих видах мошенничества с электронной почтой я рекомендую серию статей моего коллеги Брюса П. Баррелла: Часть I, Часть II и Часть III.

Массовые атаки с использованием RDP

Количество атак, совершаемых с помощью RDP, медленно, но неуклонно увеличивается, и эта проблема стала темой ряда информационных сообщений, выпущенных государственными учреждениями, например: ФБР, Национальным центром кибербезопасности (NCSC) (Великобритания), Канадским центром кибербезопасности (CCCS) и Австралийским центром кибербезопасности (ACSC).

Шлюзы открылись в мае 2019 года с появлением CVE-2019-0708, или «BlueKeep» – уязвимости безопасности в RDP, затрагивающей Windows 2000, Windows XP, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008 и Windows Server 2008 R2. Windows 8 и более поздние версии для настольных компьютеров, Windows Server 2012 и более поздние версии для серверов не затрагиваются.

Уязвимость BlueKeep позволяет злоумышленникам запускать произвольный программный код на компьютерах своих жертв. И хотя масштабную угрозу могут представлять даже одиночные злоумышленники, поскольку они могут использовать для атак автоматизированные инструменты, эта уязвимость имеет потенциал червя, что означает, что атака может распространяться автоматически по сетям без какого-либо вмешательства со стороны пользователей, так же как это в прошлом происходило с червями Win32/Diskcoder.C (или NotPetya) и Conficker. 

Эксплуатация уязвимостей с потенциалом червя считается весьма серьезной проблемой. В своем опубликованном руководстве для клиентов компания Microsoft присвоила этой уязвимости самый высокий, «критический», уровень серьезности, а в Национальной базе данных уязвимостей США описание CVE-2019-0708 имеет оценку 9,8 из 10.  В своем блоге Microsoft опубликовала пост, настоятельно рекомендовав пользователям устанавливать ее исправления, в том числе для уже не поддерживаемых операционных систем, таких как Windows XP и Windows Server 2003. Опасения по поводу эксплойта с потенциалом червя были настолько сильны, что в начале июня Агентство национальной безопасности США выпустило редкое информационное сообщение, рекомендовав для исправления этой ошибки устанавливать исправления Microsoft.

В начале сентября Rapid7, разработчик инструмента пентестинга Metasploit, объявил о выпуске эксплойта BlueKeep. Несмотря на то, что в течение следующих нескольких месяцев не было зарегистрировано значительных всплесков активности BlueKeep, в последнее время ситуация изменилась. В начале ноября, ZDNet и WIRED в числе других новостных СМИ, обратили внимание на массовые сообщения об активности BlueKeep. По сообщениям, атаки оказались не очень успешными: когда злоумышленники пытались использовать уязвимость BlueKeep, около 91% уязвимых компьютеров вышли из строя со STOP-ошибкой (т. н. проверкой ошибок или ошибкой «синий экран»). Однако на оставшихся 9% уязвимых компьютеров злоумышленникам удалось успешно установить программное обеспечение для криптомайнинга Monero. И хотя это нельзя назвать грозной атакой с потенциалом червя, преступной группе, похоже, таки удалось автоматизировать использование уязвимости, пусть пока и без большого успеха.

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

Защита от злоумышленников, использующих RDP

Итак, учитывая все вышесказанное, что вы можете сделать? Ну, первый шаг очевиден – это прекратить подключаться напрямую к своим серверам через Интернет, используя RDP. Для некоторых компаний это может оказаться проблематичным, поскольку для использования этой функции у них могут быть свои, и вероятно, обоснованные причины. Однако, поскольку в январе 2020 года Windows прекращает поддерживать Server 2008 и Windows 7, наличие компьютеров под управлением этих операционных систем и прямой доступ к ним через Интернет с использованием RDP, представляет риск для вашей компании, снижение которого вам уже давно следовало бы запланировать.

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

Рекомендации по обеспечению безопасности RDP	Основание
1. Запретите внешние подключения к локальным компьютерам через порт 3389 (TCP/UDP) на межсетевом экране периметра. *	Блокирует доступ к RDP из Интернета.
2. Протестируйте и как можно скорее разверните исправления для уязвимости CVE-2019-0708 (BlueKeep) и включите Network Level Authentication .	Установка исправления компании Microsoft и следование ее предписывающим рекомендациям помогает обеспечить защиту устройств от уязвимости BlueKeep.
3. ля всех учетных записей, в которые можно войти через RDP, требуются сложные пароли (обязательна длинная парольная фраза, содержащая более 15 символов без использования фраз, связанных с компанией, названиями продуктов или именами пользователей).	Защищает от атак с помощью подбора паролей и подстановки учетных данных. Это невероятно легко автоматизировать, а экспоненциальный рост длины пароля делает их более устойчивыми к таким атакам.
4. Установите двухфакторную аутентификацию (2FA) и, как минимум, требуйте ее для всех учетных записей, в которые можно войти через RDP.	Требуется второй уровень аутентификации, доступный только сотрудникам через мобильный телефон, токен или другой механизм для входа в компьютеры.
5. Установите шлюз виртуальной частной сети (VPN) для посредничества по всем соединениям RDP за пределами вашей локальной сети.	Предотвращает RDP-соединения между Интернетом и вашей локальной сетью. Позволяет применять более строгие требования к идентификации и аутентификации для удаленного доступа к компьютерам.
6. Программное обеспечение для защиты рабочих станций, защищенное надежным паролем, не связанным с учетными записями администратора и службы.	Обеспечивает дополнительный уровень защиты, если злоумышленник получит доступ администратора к вашей сети..
7. Включите блокировку использования уязвимости в программном обеспечении безопасности рабочих станций.	Многие программы безопасности рабочих станций также способны блокировать методы использования уязвимости. Убедитесь, что эта функция включена.
8. Изолируйте любой небезопасный компьютер, к которому необходимо получить доступ из Интернета с использованием RDP.	Внедрите изоляцию сети, чтобы заблокировать уязвимые компьютеры от остальной части сети.
9. Замените небезопасные компьютеры.	Если компьютер невозможно исправить от уязвимости BlueKeep, запланируйте его своевременную замену.
10. ассмотрите возможность внедрения блокировки geoIP на шлюзе VPN.	Если сотрудники и поставщики находятся в одной и той же стране или в небольшой группе стран, рассмотрите возможность блокировки доступа из других стран, чтобы предотвратить соединения со стороны зарубежных злоумышленников.

* По умолчанию RDP работает на порте 3389. Если вы изменили этот порт на другое значение, то этот порт следует заблокировать.

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

Вы должны убедиться, что ваше программное обеспечение безопасности рабочих станций обнаруживает уязвимость BlueKeep. BlueKeep определяется как RDP/Exploit.CVE-2019-0708 модулем Network Attack Protection компании ESET, которая является расширением технологии брандмауэра ESET, представленной в ESET Internet Security и ESET Smart Security Premium для потребителей, и программ ESET для защиты рабочих станций для компаний.

Рисунок 2: Объяснение технологии защиты от вредоносных программ ESET: защита от сетевых атак

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

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

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

Использование средства проверки уязвимости ESET BlueKeep (CVE-2019-0708)

Компания ESET выпустила бесплатный инструмент BlueKeep (CVE-2019-0708) для проверки уязвимости компьютера под управлением Windows. На момент публикации инструмент можно загрузить здесь:

(Обязательно посетите страницу «Инструменты и утилиты ESET» для новых версий)

Эта программа была протестирована на 32- и 64-разрядных версиях Windows XP, Windows Vista, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008 и Windows Server 2008 R2 до и после применения обновлений Microsoft для BlueKeep. Чтобы использовать программу, запустите исполняемый файл. Для использования с исходной версией нет никаких аргументов командной строки.

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

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

Рисунок 3: Пример запуска инструмента в неисправленной системе Windows 7

Рисунок 4: Пример запуска инструмента в исправленной системе Windows 7

Рисунок 5: Пример запуска инструмента в неуязвимой системе Windows 10

Заключительные соображения и дополнительное чтение

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

Однако сделать это не всегда возможно из-за того, что уязвимое устройство играет в компании важную роль, из-за высокой стоимости или по другим причинам. Мы давно выступаем за использование многоуровневого подхода к безопасности, и защита от BlueKeep не является исключением. Фактически, некоторые из описанных выше шагов, например, установка приложения 2FA, такого как ESET Secure Authentication, могут помочь защитить ваши сети от вторжений, а также от других угроз.

Дополнительную информацию об RDP и BlueKeep можно найти на следующих ресурсах:

• CSO Online.  Microsoft призывает клиентов Windows исправить уязвимость RDP с потенциалом червя. (15
  мая 2019 г.)
• Microsoft.  Описание
  обновления безопасности для уязвимости удаленного выполнения кода в Windows XP SP3, Windows Server 2003 SP2, Windows Server 2003 SP2 R2, Windows XP Professional x64 Edition SP2, Windows XP Embedded SP3, Windows Embedded POSReady 2009 и Windows Embedded Standard 2009. (17 июня 2019 г.)
• Microsoft. Руководство клиента для CVE-2019-0708 | Уязвимость удаленного выполнения кода службы удаленного
  рабочего стола: 14 мая 2019 года. (14 мая 2019 г.)
• Microsoft. CVE-2019-0708
  | Уязвимость удаленного выполнения кода службы удаленного рабочего стола. (14 мая 2019 г.)
• Microsoft. Настройка проверки подлинности на уровне сети для подключений служб удаленного
  рабочего стола. (13 июня 2013 г.)
• MITRE.  CVE-2019-0708. (без даты)
• АНБ. 
  Информационное сообщение по кибербезопасности АНБ: исправление служб
  удаленного рабочего стола в старых версиях Windows. 
  (4 июня 2019 г.)
• SANS. 
  Обновление уязвимости RDP «BlueKeep» (CVE-2019-0708) на Microsoft Windows [теперь
  с pcap].  (22 мая 2019 г.)
• US-CERT, Техническое
  предупреждение AA19-168A: Уязвимость BlueKeep в операционных системах Microsoft. (17
  июня 2019 г.)
• WeLiveSecurity. 
  Первые атаки BlueKeep вызывают новые предостережения. (11 ноября 2019 г.)
• WeLiveSecurity. 
  Microsoft предупреждает о новых уязвимостях, подобных BlueKeep. (15 августа 2019 г.)
• WeLiveSecurity.  Исправление для BlueKeep развивается недостаточно быстро. (17 июля 2019 г.)
• WeLiveSecurity.  АНБ присоединилось к хору, призывая
  пользователей Windows исправить «BlueKeep».  (6 июня 2019 г.)
• WeLiveSecurity.  Исправьте прямо сейчас! Почему уязвимость BlueKeep имеет большое значение.  (22
  мая 2019 г.)
• ZDNet.  Обнаружена интенсивная активность
  сканирования уязвимости BlueKeep RDP. (26 мая 2019 г.)

Особая благодарность за помощь при написании этой статьи моим коллегам Алексису Дорайс-Йонкасу, Брюсу П. Барреллу, Нику Фитцджеральду, Матушу П., Питеру Р., Петру Станчику, Штефану С. и другим коллегам из ESET.

Методология MITRE ATT&CK

Тактика	Идентификатор	Название	Описание
Начальный доступ	T1076	Протокол удаленного рабочего стола	BlueKeep использует уязвимость в протоколе удаленного рабочего стола.
	T1133	Внешние удаленные сервисы	BlueKeep использует общедоступные RDP-серверы в Интернете.
Управление и контроль	T1071	Стандартный протокол прикладного уровня	Для управления и контроля BlueKeep по умолчанию использует порт 3389
	T1043	Обычно используемый порт	Для атаки BlueKeep по умолчанию использует порт 3389.
Боковое смещение	T1210	Использование уязвимостей удаленных сервисов	BlueKeep использует общедоступные RDP-серверы в Интернете.
Смягчение	M1035	Ограниченный доступ к ресурсам через сеть	Предупреждайте проникновение BlueKeep за счет использования VPN-шлюза.
	M1050	Защита от эксплойтов	Предупреждайте проникновение BlueKeep за счет использования защиты от эксплойтов в безопасности рабочих станций.
	M1032	Многофакторная аутентификация	Используйте многофакторную аутентификацию для всех входов в систему, выполняемых через RDP.
	M1031	Предотвращение вторжений в сеть	Предупреждайте проникновение BlueKeep за счет использования сетевой защиты в безопасности рабочих станций.
	M1051	Обновление программного обеспечения	Предупреждайте использование уязвимости BlueKeep за счет установки исправления CVE-2019-0708 или обновления до неуязвимой версии операционной системы.
	M1049	Антивирусы/Защита от вредоносных программ	Предупреждайте запуск вредоносного кода BlueKeep за счет использования системы безопасности рабочих станций.

ESET Blog
2019 Дек 18 – 12:02:50

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

В 2020 году увеличилось использование сторонних сервисов для обмена данными, работа сотрудников на домашних компьютерах в потенциально незащищенных сетях Wi-Fi. Увеличилось количество людей, использующих инструменты удаленного доступа. Это стало одной из главных проблем для сотрудников ИБ.

Одним из наиболее популярных протоколов прикладного уровня, позволяющим получать удаленный доступ к рабочей станции или серверу под управлением ОС Windows, является проприетарный протокол Microsoft — RDP (англ. Remote Desktop Protocol – Протокол удаленного рабочего стола). Во время карантина в сети Интернет появилось большое количество компьютеров и серверов, к которым можно подключиться удаленно. Наблюдался рост активности злоумышленников, которые хотели воспользоваться текущим положением вещей и атаковать корпоративные ресурсы, доступные для сотрудников, отправленных на удаленную работу. На рисунке 1 представлена статистика атак на RDP. По графику видно, что количество атак на RDP значительно увеличилось с начала пандемии.

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

1. Предварительный сбор информации о RDP

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

По умолчанию RDP сервер прослушивает TCP-порт 3389 и UDP-порт 3389, поэтому компьютеры с включённым удалённым рабочим столом можно искать с помощью утилиты Nmap командой вида:

sudo nmap – p 3398 -sU -sS СЕТЬ

Например, на рисунке 2 продемонстрирован результат работы команды nmap:

sudo nmap –p 3389 -sU -sS –open 192.168.0.0/24

Для сбора баннеров достаточно добавить опции -sV --script=banner

sudo nmap -p 3389 -sU -sS -sV --script=banner 192.168.0.0/24

1.1 Сбор дополнительной информации о RDP

У Nmap также имеется перечень скриптов для сбора дополнительной информации о RDP:

sudo nmap -p 3389 -sU -sS --script rdp-enum-encryption, rdp-ntlm-info, rdp-vuln-ms12-020 192.168.0.1

Ниже описан каждый из них отдельно:

1.1.1 rdp-enum-encryption

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

Этот скрипт перечисляет информацию от удалённых служб RDP с включённой аутентификацией CredSSP (NLA).

1.1.3 rdp-vuln-ms12-020

Проверяет, является ли машина уязвимой для уязвимости MS12-020 RDP.

Также доступность RDP проверяется модулем Metasploitauxiliary(scanner/rdp/rdp_scanner), пример использования Metasploit для проверки доступности RDP приведен на рисунке 4

1.1.4 rdp-sec-check

Утилита rdp-sec-check используется для получения характеристик настроек безопасности службы RDP

Пример запуска: rdp-sec-check

Вывод команды продемонстрирован на рисунке 5

Результат после строки [+] Summary of security issues (перечень проблем безопасности) говорит о том, что не используется NLA (англ. Network Level Authentication – Аутентификация на уровне сети), следовательно, возможна атака DoS (англ. Denial [ЗДС1] [ЛОВ2] of Service – отказ в обслуживании). Далее сказано, что SSL поддерживается, но не является обязательным, потенциально это может привести к атаке MiTM (англ. Man in the Middle – атака «человек по середине»).

Помимо приведенных выше способов доступность службы RDP проверяется обычными утилитами:

в Windows: mstsc

в Linux: freerdp:

xfreerdp /f /u:ИМЯ-ПОЛЬЗОВАТЕЛЯ /p:ПАРОЛЬ /v:ХОСТ[:ПОРТ]

Далее перейдем с основным видам атак на RDP и уязвимостям.

2 Виды атак на RDP

2.1 BruteForce RDP

По статистике основным способом получения доступа по RDP является слабая парольная политика, поэтому, давайте рассмотрим основные способы перебора данных учетных записей RDP. Удобными являются утилиты ncrack, hydra, patator:

пример использования утилиты hydra:

ncrack -vv --user -P pwds.txt rdp://

пример использования hydra:

hydra -V -f -L -P rdp://

пример использования patator :

patator rdp_login host=192.168.0.101 user=FILE0 password=FILE1 0=user.txt 1=passwords.txt -x ignore:fgrep='ERRCONNECT_LOGON_FAILURE'

Также утилита crowbar может использоваться для осуществления перебора данных учетных записей RDP. Пример использования данной утилиты продемонстрирован на рисунке 6.

./crowbar.py –server -b rdp -u -C

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

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

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

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

В случае, если же выставлено значение «0», как показано на рисунке 10, то злоумышленник может неограниченно пытаться получать доступ к RDP.

На рисунке 11 продемонстрировано получение данных учетных записей RDP.

Зная данные учетных записей можно осуществить подключение через утилиту xfreerdp, доступную в Kali Linux. Пример на рисунке 12.

После чего получил доступ к удаленной машине.

2.2 MitM атака на RDP с помощью утилиты Seth

С помощью seth выполняется атака MitM, в результате которой извлекаются учётные данные из RDP подключений.

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

Установка зависимостей:

git clone https://github.com/SySS-Research/Seth.git

cd Seth

pip install -r requirements.txt

apt install dsniff

Для проведения атаки злоумышленнику требуется локальный IP-адрес, целевой IP-адрес и сетевой интерфейс, который будет использоваться. В данном случае это eth0. На рисунке 14 продемонстрирован пример запуска утилиты с необходимыми параметрами.

Использование:

/usr/share/seth/seth.sh

Далее после запуска утилиты злоумышленником цель открыла диалоговое окно «Подключение к удаленному рабочему столу» и пыталась подключиться к машине и пользователю по своему выбору. Пользователь запрашивает учетные данные для подключения в качестве исходного запроса проверки подлинности безопасности.

Далее всплывает окно диспетчера сертификатов. На рисунке 16 видно, что существует конфликт между именем сервера и доверенным центром сертификации. Это похоже на окно с запросом на сохранение сертификата. Допускаем, что наша цель нажала «Да» в окне, представленном на рисунке 16.

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

2.3 BlueKeep (CVE-2019-0708)

С 2019 года было обнаружено несколько серьезных RCE (англ. Remote Code Execution – Удаленное Выполнение Кода), связанных с RDP. Их эксплуатация приводит к отказу в обслуживании, а также к удаленному исполнению кода на целевой системе. Уязвимость CVE-2019-0708, получившую название BlueKeep, обнаружили не в самом протоколе RDP, а в реализации службы удаленных рабочих столов. В результате эксплуатации уязвимости неаутентифицированный пользователь может удаленно исполнить произвольный код на целевой системе. Уязвимости подвержены старые версии Windows: начиная с Windows XP (Windows Server 2003) и заканчивая Windows 7 (Windows Server 2008 R2). Для ее успешной эксплуатации необходимы лишь сетевой доступ к компьютеру с уязвимой версией Windows и запущенная служба RDP. Для этого злоумышленник отправляет специально сформированный запрос к службе по RDP для удаленного выполнения произвольного кода на целевой системе. Информация о BlueKeep опубликована в мае 2019 года, но уязвимыми до сих пор остаются достаточное количество RDP-серверов. Уязвимости CVE-2019-1181/1182/1222/1226 практически аналогичны BlueKeep. Однако если предыдущей уязвимости были подвержены лишь старые версии Windows, то теперь под угрозой оказались и все новые версии ОС. Для эксплуатации уязвимостей злоумышленнику также достаточно отправить специально сформированный запрос к службе удаленных рабочих столов целевых систем, используя протокол RDP, что позволит выполнить произвольный код. Эти уязвимости опубликованы в августе 2019 года.

Пример эксплуатации и проверки с помощью модуля metasploit:

auxiliary(scanner/rdp/cve_2019_0708_bluekeep)

CVE-2019-0708 – это уязвимость типа use-after-free драйвера termdd.sys, который используется в Microsoft RDP. Для лучшего понимания, рассмотрим схему образования связи RDP:

Протокол удаленного рабочего стола (RDP) обеспечивает соединение между клиентом и конечной точкой (endpoint прим.), определяя данные, передаваемые между ними в виртуальных каналах. Виртуальные каналы — это двунаправленные каналы данных, расширяющие RDP. Windows Server 2000 определил 32 статических виртуальных канала (SVCs) с RDP 5.1, но из-за ограничений на количество каналов дополнительно определил динамические виртуальные каналы (DVCs), которые содержатся в рамках выделенного SVC. SVC создаются в начале сеанса и остаются до завершения сеанса, в отличие от DVC, которые создаются и удаляются по запросу.

Эту привязку 32 SVC исправляет патч CVE-2019-0708 в функциях _IcaBindVirtualChannels и _IcaRebindVirtualChannels в драйвере RDP termdd.sys. Как видно на рисунке 19, соединения RDP Connection Sequence инициируются, а каналы настраиваются до начала действия безопасности. Блок «RDP security commencement», как видно на схеме, выполняется после инициализации и базовых настройки канала, что позволяет CVE-2019-0708 выполнять функцию червей, поскольку данная уязвимость может самостоятельно распространяться по сети после обнаружения открытого порта 3389.

Уязвимость связана с тем, что имя SVC «MS_T120» привязывается в качестве канала по умолчанию к номеру 31 во время последовательности инициализации конференции GCC протокола RDP. Это имя канала используется корпорацией Microsoft для внутренних целей, и нет очевидных законных вариантов использования клиентом запроса на подключение через SVC с именем «MS_T120».

На рисунке 20 показаны легитимные запросы канала во время последовательности инициализации конференции GCC без канала MS_T120.

Пока конференция GCC инициализируется клиент предоставляет имя канала, которое не занесено сервером в белый список, что означает, что злоумышленник может настроить другой SVC с именем «MS_T120» на канале, отличном от 31. Использование MS_T120 на другом канале приводит к повреждению памяти кучи (англ. Heap Memory Corruption) и RCE.

На рисунке 21 показан аномальный запрос канала во время последовательности инициализации конференции GCC с каналом «MS_T120» на канале номер 4.

Компоненты, участвующие в управлении каналом MS_T120, выделены на рисунке 22. Эталонный канал MS_T120 создается в rdpwsx.dll, а пул кучи выделяется в rdpwp.sys. Повреждение кучи происходит в termdd.sys, когда эталонный канал MS_T120 обрабатывается в контексте индекса канала, отличного от 31.

Исправление Microsoft, показанное на рисунке 23, теперь добавляет проверку запроса на подключение клиента с использованием имени канала «MS_T120» и обеспечивает его привязку только к каналу 31 (1Fh) в функциях _IcaBindVirtualChannels и _IcaRebindVirtualChannels в termdd.sys.

Данная часть материала взята с сайта https://cve-2019-0708.info/understanding-the-wormable-rdp-vulnerability-cve-2019-0708.php

2.3.1 BlueGate

Еще одна уязвимость — BlueGate (CVE-2020-0609/0610) — была найдена в компоненте Windows Remote Desktop Gateway в Windows Server (2012, 2012 R2, 2016 и 2019). Она также позволяет злоумышленникам посредством RDP и специально созданных запросов осуществлять удаленное выполнение кода на целевой системе. BlueGate опубликована в начале 2020 года.

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

В обновлении безопасности от января 2020 года Microsoft устранила две уязвимости в RDG. Обе ошибки, CVE-2020-0609 и CVE-2020-0610, позволяют выполнять удаленное выполнение кода до аутентификации.

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

Была изменена только одна функция. RDG поддерживает три различных протокола: HTTP, HTTPS и UDP. Обновленная функция отвечает за обработку последнего. Для удобства на рисунке 24 рассмотрена функция в виде псевдокода, в котором ненужный код был удален.

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

fragment_id: позиция пакета в последовательности

num_fragments: общее количество пакетов в последовательности

fragment_length: длина данных пакета

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

CVE-2020-0609

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

1-й фрагмент (fragment_id=0) имеет длину 1. this->bytes_written равен 0, поэтому проверка границ проходит.

1 байт записывается в буфер по смещению 0, а bytes_written увеличивается на 1. Второй фрагмент (fragment_id=1) имеет длину 998. проверка границ проходит.

998 байт записываются в буфер по смещению 1000 (fragment_id*1000), что приводит к записи 998 байт после конца буфера.

Следует отметить, что пакеты не обязательно отправлять по порядку (помните, это UDP). Таким образом, если первый пакет, который мы отправляем, имеет fragment_id=65535 (максимум), он будет записан со смещением 65535*1000, т.е. полные 65534000 байт после конца буфера. Управляя fragment_id, можно записать до 999 байт в диапазоне от 1 до 65534000 после окончания буфера. Эта уязвимость гораздо более гибкая, чем типичное линейное переполнение кучи. Это позволяет нам контролировать не только размер записываемых данных, но и смещение до места их записи. Благодаря дополнительному контролю легче выполнять более точную запись, избегая ненужного повреждения данных.

CVE-2020-0610

Объект класса поддерживает массив 32-битных целых чисел без знака (по одному для каждого фрагмента). Как только фрагмент получен, соответствующий элемент массива устанавливается с 0 на 1. Как только каждый элемент устанавливается на 1, повторная сборка сообщения завершена, и сообщение может быть обработано. В массиве есть место только для 64 записей, но идентификатор фрагмента может находиться в диапазоне от 0 до 65535. Единственная проверка заключается в том, что fragment_id меньше, чем num_fragments (которое также можно установить равным 65535). Следовательно, установка для fragment_id любого значения от 65 до 65535 позволит нам записать 1 (TRUE) за пределами массива. Хотя возможность установить единственное значение в 1 может показаться неправдоподобным для превращения в RCE, даже самые незначительные изменения могут оказать огромное влияние на поведение программы.

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

2.4 Session Hijacking

Перехват сеанса — это тип атаки, при котором злоумышленник может получить доступ к активному сеансу, который не доступен злоумышленнику напрямую. Чтобы продемонстрировать атаку такого типа, нужно создать сценарий. На рисунке 28 представлен демонстрационный стенд на Windows с включенной службой удаленного рабочего стола и работающей с двумя активными пользователями: raj и aarti. Одним из наиболее важных факторов для выполнения атаки перехвата сеанса является то, что другой сеанс, который мы пытаемся перехватить, должен быть активным.

Пусть мы вошли под пользователем raj, используя учетные данные, которые удалось извлечь на предыдущих этапах проникновения, описанных в разделе 3.2.

Теперь нам нужно снова запустить Mimikatz после входа в систему как пользователь raj. Необходимо перечислить все активные сеансы. Мы используем команду сеансов из модуля ts. На рисунке 30 видим, что существует сеанс 3 для пользователя aarti, который активен.

Использовали команду elevate для повышения уровня из модуля токена, чтобы выдавать текущий токен за NT AuthoritySYSTEM и предоставить возможность подключения к другим сеансам. Вернувшись к выходным данным сеанса, мы увидели, что у пользователя aarti есть сеанс 3. Нам нужно подключиться к этому конкретному сеансу с помощью удаленной команды модуля ts. Пример подключения продемонстрирован на рисунке 31.

Как видно на рисунке 32, удалось получить сеанс удаленного рабочего стола для пользователя aarti, имея изначально доступ к пользователю raj. Таким образом session hijacking успешно реализована в службе удаленного доступа RDP.

3 Рекомендации по повышению уровня защищенности RDP

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

3.1 Журналы событий в Windows

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

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

EventID 4624: процесс аутентификации прошел успешно

EventID 4625: процесс аутентификации завершился сбоем

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

Applications and Services Logs > Microsoft > Windows > TerminalServices-LocalSessionManager > Operational.

Event ID 21: Remote Desktop Logon

Event ID 23: Remote Desktop Logoff

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

Applications and Services Logs > Microsoft > Windows > TerminalServices-LocalSessionManager > Operational.

EventID 24: сеанс удаленного рабочего стола отключен

EventID 25: сеанс удаленного рабочего стола переподключен

3.2 Установка ограничения времени активного сеанса

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

Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Session Time Limits.

3.3 Network Level Authentication

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

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

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

• Использовать VPN (англ. Virtual Private Network – виртуальная частная сеть).

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

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

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

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

• Блокировать учетные записи с пустым паролем.

• Использовать двухфакторную аутентификацию.

• Настроить политику блокировки при неудачных попытках ввода пароля. Рекомендуется установить значение блокировки равное 3.

• Ограничить кол-во пользователей, которые могут войти в систему с помощью RDP.

Спасибо за прочтение и уделенное время!

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

14 мая 2019 года Microsoft сообщила о наличии критической уязвимости в реализации службы удаленных столов (ранее служба терминалов) в Windows, которая позволяет атакующему, не прошедшему проверку подлинности, через протокол RDP удаленно выполнить произвольный код на целевой системе. RCE (Remote Code Execution) уязвимость описана в CVE-2019-0708 и ей присвоено неофициальное название BlueKeep. Уязвимости подвержены только старые версии Windows – начиная с Windows XP (Windows Server 2003) и заканчивая Windows 7 (Windows Server 2008 R2). Более новые версии (Windows 10, 8.1 и Windows Server 2012R2/2016/2019) данной уязвимости в RDS не подвержены.

RCE уязвимость CVE-2019-0708 в Remote Desktop Services

Уязвимость присутствует не в самом протоколе RDP, а в реализации службы удаленных рабочих столов (Remote Desktop Service) в старых версиях Windows. Для эксплуатации уязвимости необходим только сетевой доступ к компьютеру с подверженной версией Windows и наличие на нем включенной службы RDP (доступ к которой не должен блокироваться межсетевыми экранами). Т.е. если ваш Windows хост доступен из интернета через RDP, это означает, что уязвимость может быть эксплуатирована кем угодно. Уязвимость реализуется за счет отправки специального запроса к службе удаленного рабочего стола через RDP, преаутентфикация удаленного пользователя при этом не требуется. После реализации уязвимости BlueKeep атакующий может удаленно выполнить произвольный код на целевой системе с правами SYSTEM.

Microsoft отмечает, что есть весьма высокая вероятность появления автоматических червей, которые будут используют уязвимость в RDS для распространения в локальных сетях. Таким образом масштаб атак может достигнуть результатов червя WannaCry (использовал уязвимость в протоколе SMB CVE-2017-0144 — EternalBlue).

Защита от уязвимости BlueKeep CVE-2019-0708

Для защиты от уязвимости CVE-2019-0708 (BlueKeep) Microsoft рекомендует оперативно установить обновления безопасности (перечислены в следующем разделе). Для уменьшения рисков реализации уязвимости на системах до момента установки обновления во внешнем периметре рекомендуются следующие действия:

• Временно отключить RDP доступ к компьютерам и отключить службу Remote Desktop Services или заблокировать внешний доступ на RDP на межсетевых экранах периметра сети и отключить проброс RDP портов в локальную сеть;
• Включить поддержку Network Level Authentication (NLA — Проверку подлинности на уровне сети) в настройках RDP на компьютере ) – возможно настроить как в Windows 7 /2008 R2, так и в Windows XP SP3. При включенной NLA для реализации уязвимости атакующему сначала нужно аутентифицироваться в службе Remote Desktop Services с помощью действительного аккаунта (реализовать атаку можно только под легитимным пользователем).

Обновления Windows для защиты от RDP уязвимости BlueKeep

Microsoft выпустила обновления для всех ОС Windows, подверженных уязвимости CVE-2019-0708 (BlueKeep). Патчи доступны для загрузки в каталоге обновлений Microsoft.

Несмотря на то, что Microsoft прекратила поддержку Windows XP и Windows Server 2003, для защиты от BlueKeep были выпушены обновления и для этих устаревших систем. Что лишний раз подчеркивает серьезность найденной уязвимости и высокий риск ее массовой эксплуатации.

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


KB4500331:

Windows XP SP3 x86, x64 Windows XP Embedded, Windows Server 2003 SP2 x86, x64 — https://www.catalog.update.microsoft.com/Search.aspx?q=KB4500331

KB4499175:

• Windows Server 2008 R2 SP1 и Windows 7 SP1 x64 — windows6.1-kb4499175-x64_3704acfff45ddf163d8049683d5a3b75e49b58cb.msu
• Windows 7 x86 SP1 — windows6.1-kb4499175-x86_6f1319c32d5bc4caf2058ae8ff40789ab10bf41b.msu

В Windows XP и 2003 обновления kb4500331 придется устанавливать вручную.

Для Windows 7 и Windows Server 2008 R2 обновление KB4499175 уже доступно для установки через WSUS (в зависимости от настроек одобрения обновлений) и Microsoft Update. Но вы можете установить его и вручную из msu файла с помощью wusa.exe:

wusa.exe "C:Installwindows6.1-kb4499175-x64_3704acfff45ddf163d8049683d5a3b75e49b58cb.msu" /quiet /warnrestart

Ну, самое простое: взломать серверные аккаунты и сделать через него релей спама. Как раз по SMTP.

Но с этим всё должно быть просто.

1. Если почтовый сервер оконечный, то релей должен быть запрещен. Если нет, то должна быть включена аутентификация по SMTP.
2. Дополнительная проверка по обратному резольвингу PTR-записей в MX-записи отметает почти 100% подключений ботнета. Но не все.
3. Если есть возможность — включить SPF-контроль.
4. Ну и включить всякие эвристики по полям «To:», «Cc:», «Bcc:». Например, ограничить допустимое число получателей, рубить письма с большим числом чередований кириллицы и латиницы.

Когда у нас был свой SMTP я еще экспериментировал с динамическим выявлением массовых рассылок:

www.courierms.ru/forum/viewtopic.php?t=1840

Результат был неплох (после всех фильтров улавливало еще свыше 30% спама), но от эмуляции к боевой эксплуатации так и не перешли, а потом отказались от своего почтового сервера в пользу PDD на Яндексе. А жаль — спама сейчас гораздо больше.

Так что, защитить SMTP от спама и релея несколько проще, чем RDP от подбора паролей. Да и ущерб от взлома SMTP не критичны. Разве что начнут экстремистскую литературу и приглашения на митинги рассылать. Тогда: да… чревато.

Jun 21, 2022 (Last updated on June 22, 2022)