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

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

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

image

Автор: Алексей Леднев, старший специалист экспертного центра безопасности, Positive Technologies (PT Expert Security Center)

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

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

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

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

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

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

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

  4. использование широковещательных протоколов LLMNR и NetBIOS,

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

  6. TOR, VPN-туннели и прочие инструменты сокрытия активности в сети,

  7. нецелевое использование систем (майнеры криптовалют, торренты).

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

Далее мы поговорим о каждой ошибке: к каким последствиям они могут привести, на примере системы анализа трафика PT Network Attack Discovery (PT NAD) покажем, как их можно выявить и дадим рекомендации по их устранению. PT NAD — система класса NTA (Network Traffic Analysis), которая разбирает трафик на уровнях L2 — L7 и выявляет атаки на периметре и в инфраструктуре. Для проверки на наличие ошибок в сети мы будем применять фильтрацию трафика по протоколу и несколько дополнительных инструментов.

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

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

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

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

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

Перечислим методы устранения передачи учетных данных в открытом виде на разных участках инфраструктуры:

  1. Веб-серверы: перейти с протокола HTTP на HTTPS. Для перехода на защищенный протокол HTTPS требуется настроить SSL-сертификат и переадресацию с HTTP-адресов на HTTPS. На внутренних ресурсах организации допустимо настроить самоподписанные сертификаты, предварительно настроив внутренний центр сертификации. Для общедоступных ресурсов лучше использовать доверенные сертификаты, выпущенные доверенным удостоверяющим центром.

  2. 2. Протокол LDAP: настроить клиенты на использование аутентификации через Kerberos или использование защищенной версии протокола. Для настройки аутентификации через Kerberos, необходимо настроить клиентов на использование SASL-механизмов аутентификации GSSAPI или GSS-SPNEGO. TLS, необходимо активировать LDAPS на сервере согласно инструкции. Далее настроить клиентов на использование TLS (LDAPS) при подключении к LDAP-серверу.

  3. Почтовые протоколы: настроить клиенты и серверы на использование TLS. Вместо стандартных POP3, IMAP и SMTP рекомендуем настроить клиенты и серверы организации на использование их защищенных аналогов POP3S, IMAPS и SMTPS согласно инструкции вашего почтового сервера. Стоит отметить, что при принудительном включении TLS письма могут быть не доставлены на серверы, не поддерживающие шифрование.

  4. Протокол Telnet: перейти на SSH. Следует полностью отказаться от использования протокола Telnet и заменить его на защищенный протокол SSH.

  5. FTP: перейти на SFTP или FTPS. FTPS — версия FTP с применением протокола SSL, требующая для своей работы SSL-сертификат. SFTP — протокол передачи файлов, чаще всего использующий SSH. Как следствие, требует меньше настроек на серверах, где уже применяется SSH.

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

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

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

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

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

  2. Настроить использование S/MIME — стандарта для отправки зашифрованных сообщений и сообщений с цифровой подписью. Требует настройки почтового клиента и S/MIME сертификата. Подробнее — на сайте Microsoft.

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

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

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

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

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

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

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

  1. Контролировать использование утилит удаленного управления. Необходимо разработать регламенты ИБ, запрещающие несанкционированное использование утилит для удаленного управления, а также контролировать их соблюдение. Подключение RAT можно также запретить на уровне некоторых сетевых средств безопасности, например, NGFW.

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

  3. Ввести политику белых списков для ПО. Самый надежный, но трудоемкий метод решения. Ввести в организации белый список ПО и следить, что на всех узлах используется ПО только из этого списка, а также следить за актуальностью списка. Для настройки можно воспользоваться утилитой AppLocker, которая входит в состав Windows. Подробнее на сайте Microsoft.

Использование широковещательных протоколов 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. Проанализировали прикладные протоколы — увидели активное использование служебных протоколов, а также событие — попытку эксплуатации уязвимости EternalBlue, ставшей причиной нашумевшей эпидемии 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. закрытие сетевых портов.

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

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

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

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

Видео.

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

  1. разграничение прав локальных пользователей,

  2. политика белых списков для ПО,

  3. обновление антивируса и его базы.

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

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

  1. минимизировать использование открытых протоколов,

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

  3. разграничивать права пользователей.

При этом на рынке уже есть инструменты, способные отслеживать сетевую активность внутри организации,
своевременно обнаруживать как ошибки настроек, так и активность
злоумышленников.


Подписывайтесь на каналы "SecurityLab" в TelegramTelegram и Яндекс.ДзенЯндекс.Дзен, чтобы первыми узнавать о новостях и эксклюзивных материалах по информационной безопасности.

Какие зарубежные новостные сайты по информационной безопасности вы читаете?