Как избежать популярных ошибок сетевой безопасности

В середине сентября стало известно об утечке почти 2Тб данных, в которых содержалась информация о работе системы оперативно-розыскных мероприятий (СОРМ) в сети одного российского оператора связи. Утечка произошла из-за неправильно настроенной утилиты резервного копирования rsync. Подобные ошибки – частая причина проблем крупных компаний. В этой статье мы разберем семь самых популярных ошибок сетевой безопасности: расскажем, как их можно обнаружить и устранить.

Распространенная причина успеха развития атак внутри сети — ошибки конфигурирования каналов связи или систем обработки и хранения данных, а также нарушения регламентов ИБ. Все это снижает эффективность используемых средств защиты и увеличивает шансы злоумышленников на взлом и развитие атаки. Во время проектов по расследованию инцидентов и анализа трафика наша команда PT Expert Security Center регулярно находит типичные ошибки в конфигурациях информационных систем и нарушения корпоративных регламентов ИБ. Давайте посмотрим, что это за ошибки.

7 типовых ошибок сетевой безопасности

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

1. Передача учетных данных по сети в открытом виде.
2. Нешифрованные почтовые сообщения.
3. Использование утилит для удаленного доступа.
4. Использование широковещательных протоколов LLMNR и NetBios.
5. Ошибки конфигурирования сетей.
6. TOR, VPN-туннели и прочие инструменты сокрытия активности в сети.
7. Нецелевое использование систем (майнеры криптовалют, торренты).

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

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

Передача учетных данных по сети в открытом виде

Все еще встречается использование сетевых протоколов, в которых в открытом виде передаются учетные данные пользователей, — это HTTP, почтовые протоколы с отсутствием шифрования, LDAP и Telnet. По данным нашего исследования, хранение важной информации в открытом виде на сетевых ресурсах встречается в 44% организаций, в которых мы проводили анализ защищенности. В случае компрометации сети злоумышленник может в пассивном режиме перехватить учетные данные, закрепить свое присутствие в инфраструктуре и повысить свои привилегии.

Пример «летающих» учетных данных, выявленных с помощью PT NAD

На видео мы показали, как с помощью системы анализа трафика PT Network Attack Discovery можно проверить, передаются ли по сети учетные данные в открытом виде. Для этого мы отфильтровали в PT NAD сетевые сессии по признаку передачи пароля. Это позволило найти факты передачи учетных данных для веб-приложения, в нашем случае — системы мониторинга Zabbix. Имея привилегированную учетную запись на сервере Zabbix, злоумышленник чаще всего получает возможность удаленного выполнения команд на всех системах, подключенных к мониторингу. Также в демонстрации мы рассмотрели пример анализа трафика на использование отрытых сетевых протоколов (LDAP, FTP, HTTP, POP3, SMTP, Telnet) и извлечение из него учетных записей пользователей.

Подробнее на видео:

Устранить передачу учетных данных в открытом виде можно несколькими способами.

1. WEB-серверы: перейти с протокола HTTP на HTTPS. Для перехода на защищенный протокол HTTPS требуется настроить SSL-сертификат и переадресацию с HTTP-адресов на HTTPS. На внутренних ресурсах организации допустимо настроить самоподписанные сертификаты, предварительно настроив внутренний центр сертификации. Для общедоступных ресурсов лучше использовать доверенные сертификаты, выпущенные доверенным удостоверяющим центром.
2. Протокол LDAP: настроить клиенты на использование аутентификации через Kerberos или использование защищенной версии протокола. Для настройки аутентификации через Kerberos, необходимо настроить клиентов на использование SASL механизмов аутентификации GSSAPI или GSS-SPNEGO.
3. Для настройки аутентификации защищенной TLS, необходимо активировать LDAPS на сервере согласно инструкции. Далее настроить клиентов на использование TLS (LDAPS) при подключении к LDAP серверу.
4. Почтовые протоколы: настроить клиенты и серверы на использование TLS. Вместо стандартных POP3, IMAP и SMTP рекомендуем настроить клиенты и серверы организации на использование их защищенных аналогов POP3S, IMAPS и SMTPS согласно инструкции вашего почтового сервера. Стоит отметить, что при принудительном включении TLS письма могут не быть доставлены на серверы, не поддерживающие шифрование.
5. Протокол Telnet: перейти на SSH. Следует полностью отказаться от использования протокола Telnet и заменить его на защищенный протокол SSH.
6. FTP: перейти на SFTP или FTPS. FTPS — версия FTP с применением протокола SSL, требующая для своей работы SSL-сертификат. SFTP — протокол передачи файлов, чаще всего использующий SSH. Как следствие, требует меньше настроек на серверах, где уже применяется SSH.

Нешифрованные почтовые сообщения

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

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

Подробнее на видео:

Возможные варианты устранения ошибки:

1. Настроить сервер на принудительное использование TLS при отправке почты (но в этом случае письма могут быть не доставлены на серверы, не поддерживающие шифрование).
2. Настроить использование S/MIME — стандарта для отправки зашифрованных сообщений и сообщений с цифровой подписью. Требует настройки почтового клиента и S/MIME сертификата. Подробнее по ссылке.
3. Применять PGP. Принудительное использование PGP также исключит передачу писем в открытом виде, однако это требует дополнительной настройки на клиентах и передачи открытого ключа получателям. Данный вариант больше подходит для использования в частных случаях.

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

Сотрудники часто применяют утилиты для удаленного доступа (remote access tools, RAT), например, TeamViewer, Ammyy Admin, RMS и другие. Если это разрешено внутренними политиками ИБ, то в случае когда злоумышленник воспользуется этими же инструментами, отличить нелегитимное их использование от легитимного будет сложно.

Обнаружить подключения через TeamViewer можно с помощью системы анализа трафика. В нашем случае, мы обнаружили две такие сетевые сессии. Если в организации запрещено использование утилит удаленного управления, то специалисту по ИБ стоит провести расследование, чтобы установить источник активности.

Еще один механизм выявления случаев использования RAT – предустановленные правила. На видео с их помощью мы обнаружили факт использования утилиты Remote Admin.

Подробнее на видео:

Рекомендации по устранению нарушения:

1. Контролировать использование утилит удаленного управления. Необходимо разработать регламенты ИБ, запрещающие несанкционированное использование утилит для удаленного управления, а также контролировать их соблюдение. Подключение RAT можно также запретить на уровне некоторых сетевых средств безопасности, например, NGFW.
2. Разграничить права локальных пользователей на рабочих станциях. Если пользователям не будут выданы избыточные административные права, разрешающие в том числе установку программ на рабочие компьютеры, использование утилит будет невозможно.
3. Ввести политику белых списков для ПО. Самый надежный, но трудоемкий метод решения. Ввести в организации список «белого» ПО и следить, что на всех узлах используется ПО только из этого списка, а также следить за актуальностью списка. Для настройки можно воспользоваться утилитой AppLocker, которая входит в состав Windows. Подробнее по ссылке.

Использование широковещательных протоколов LLMNR и NetBios

Еще одна проблема настроек сетей организаций — использование подверженных спуфингу протоколов LLMNR и NetBios. Данные протоколы позволяют за счет широковещательных запросов в локальном сегменте сети L2 разрешать имена соседних компьютеров без использования DNS сервера. Эти протоколы также автоматически используются при недоступности DNS. В случае проникновения злоумышленника во внутреннюю сеть компании, он сможет провести атаку «человек посередине» (англ. Man in the middle, MITM). Злоумышленник может ответить на широковещательный запрос и тем самым перенаправить запросы жертвы на подконтрольный злоумышленнику сервер. Проведение данной атаки позволит перехватить аутентификационные данные.

Мы попробовали выявить использование данных протоколов, воспользовавшись виджетом «Прикладные протоколы» в PT NAD. Мы обнаружили, что, кроме привычных протоколов, используются протоколы LLMNR и NBNS. Добавив их к фильтру, также обнаружили всех клиентов, которые отправляли запросы, используя данный протокол.

Видео:

Чтобы устранить эту ошибку, нужно:

1. Отключить LLMNR. Для этого необходимо предварительно на клиентах произвести настройку DNS. Произвести отключение LLMNR можно с помощью групповой политики «Turn Off Multicast Name Resolution» в разделе «Computer Configuration -> Administrative Templates -> Network -> DNS Client». Для отключения значение политики должно быть выставлено в «Enabled».

По клику картинка откроется в полном размере

2. Отключить NetBios. Для этого необходимо воспользоваться оснасткой dhcpmgmt.msc. Server Options: Вкладка Advanced -> Microsoft Windows 2000 Options -> Microsoft Disable Netbios Option. Выставить значение 0x2.

3. Также поддержку NetBios можно отключить через запуск PowerShell скрипта на узлах с помощью групповой политики «Scripts» в разделе «Computer Configuration -> Policies-> Windows Settings». Требуется добавить startup PowerShell script с следующим содержимым:

$regkey = "HKLM:SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces" Get-ChildItem $regkey |foreach { Set-ItemProperty -Path "$regkey\$($_.pschildname)" -Name NetbiosOptions -Value 2 -Verbose}

Данный скрипт для всех сетевых адаптеров в ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces установит значение параметра NetbiosOptions на 2.

Если в инфраструктуре имеются узлы под управлением Windows XP или Windows 2000, то отключение NetBios может сказаться на их работоспособности.

Ошибки конфигурирования сетей

Наиболее частые ошибки, связанные с неверным конфигурированием работы сети:

1. Излишне «доверительные» отношения между подсетями. Сюда относятся проблемы разграничения доступа между подсетями, при которых становится возможен несанкционированный сетевой доступ между внутренними подсетями организации. В результате злоумышленник при компрометации небольшой части сети может беспрепятственно взять под контроль ключевые узлы всей сети.
2. Доступ узлов инфраструктуры ко внешним DNS-серверам. При использовании внутренней системы доменных имен DNS-запросы должны обрабатываться только на собственных DNS-серверах организации. Если DNS на клиентах сконфигурирован неверно, в случае запроса к публичному DNS-серверу существует риск утечки внутренних доменных имен, а также обход фильтрации известных адресов командных серверов вредоносного ПО.
3. Открытые для внешней сети «наружу» сетевые порты и сервисы порты без необходимости в этом (например, базы данных). Вследствие у злоумышленника появляются большие возможности для проведения атаки. Например, из-за хранения сведений в незащищенной базе данных, в сеть утекли данные пациентов скорой помощи из Подмосковья.

Чтобы выявить такие ошибки, мы воспользовались вкладкой PT NAD «Сетевые связи». Все связи представлены в виде графа. Мы попробовали найти соединения из подсети DMZ в пользовательскую подсеть. Для этого настроили фильтр по подсетям. В результате мы обнаружили нежелательную сетевую связь, а также сработавшее событие — сканирование утилитой nmap, что служит индикатором проводившейся сетевой разведки.

Также мы попробовали найти связи из внешней сети к подсети DMZ. Проанализировали прикладные протоколы — увидели активное использование служебных протоколов, а также событие — попытку эксплуатации уязвимости EthernalBlue, ставшей причиной нашумевшей эпидемии WannaCry.

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

Видео:

Устранить ошибки можно следующим образом:

1. Настроить Access Control List (ACL) на сетевом оборудовании для корректного разграничения прав доступа между подсетями. ACL — это набор разрешающих или запрещающих правил для сетевого трафика (в контексте сетевого оборудования). В большинстве случаев списки доступа применяют для пакетной фильтрации на границе интернета и частной сети, однако фильтрация может также потребоваться на границе DMZ и других подсетей.
2. Настроить межсетевой экран. Межсетевые экраны также должны быть настроены не только на границе с внешней сетью, но и между внутренними подсетями организации.
3. Запретить изменения сетевых настроек пользователей. Для этого настройте параметр в групповых политиках Windows: «User Configuration -> Administrative Templates -> Network -> Network Connections».

Сокрытие трафика

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

Для выявления использования этих средств подойдут такие фильтры: по репутационному списку tor-relays, который содержит актуальные адреса узлов сети Tor, а также фильтр по протоколу TLS, так как Tor маскируется под него. Использованный в «подозрительной» сессии TLS-сертификат является автоматически сгенерированным, что является индикатором соединения сети Tor.

Для обнаружения VPN и других туннелей можно воспользоваться фильтром по ключевому слову PPTP (Point-to-Point Protocol), а для обнаружения SOCKS5-трафика — уже знакомым нам фильтром по протоколу. Так мы нашли VPN-сессию с внешним хостом и множество подключений по SOCKS5.

Видео:

Методы решения данной проблемы мы уже рассматривали ранее, справиться поможет:

1. Разграничение прав локальных пользователей.
2. Политика белых списков для ПО.
3. Настройка сетевого экрана.
4. Закрытие сетевых портов.

Нецелевое использование систем

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

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

С Bittorent и онлайн-играми все еще проще — для поиска торрент-трафика воспользуемся фильтром по протоколу Bittorent, а для онлайн-игр — по серверам популярных онлайн-игр. Это помогает вычислить сотрудников, использующих свое рабочее время не так, как хотелось бы работодателю.

Видео:

Средства противодействия почти те же, что и в пунктах выше:

1. Разграничить права локальных пользователей.
2. Политика белых списков для ПО.
3. Обновить антивирус и его базы.

Подведем итоги

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

1. Минимизировать использование открытых протоколов.
2. Контролировать разграничение сетевого доступа.
3. Разграничивать права пользователей.

При этом на рынке уже есть инструменты, способные отслеживать сетевую активность внутри организации, своевременно обнаруживать как ошибки настроек, так и активность злоумышленников. Одна из таких систем – это PT Network Attack Discovery.

Автор: Алексей Леднев, Старший специалист. PT Expert Security Center