Вопрос или проблема
Вот мой не совсем теоретический сценарий: атака с троянским конем в день первого запуска, когда злоумышленник устанавливает безопасное соединение обратно к себе, используя известный доверенный порт, например 80, 21, 443. Или, например, если злонамеренный пользователь использует инструмент с открытым исходным кодом, такой как openvpn, чтобы обеспечить и направить соединение через доверенный порт изнутри компании, эффективно делая все меры безопасности бесполезными.
Есть ли способ, чтобы snort мог обнаружить начальное безопасное соединение, будь то SSL/TLS или IPSEC? Я понимаю, что как только соединение установлено, его становится очень трудно обнаружить, это и есть моя проблема.
Мой главный вопрос: есть ли способ обнаружить обмен открытыми ключами и зарегистрировать, кто это делает?
Спасибо заранее!
В случае TLS ответ – да. (IPSEC?) Скриншот ниже показывает обмен TLS, пойманный Wireshark. Я не знаю, может ли Snort делать это напрямую.
ДИСКУССИЯ
Я предполагаю, что вы находитесь в той же зоне безопасности, что и сервер. Если бы вы не были, то просто туннелирование одного протокола (например, TLSxx по TCP) внутри другого (например, OpenVPN по UDP) будет достаточно, чтобы замаскировать любое установление соединения, так что вам придется полагаться на статистический анализ, чтобы попытаться определить, какая конкретная сетевое активность имеет место.
В общем, однако, это действительно зависит от эксплойта.
Если злоумышленник скомпрометирует публично доступный хост и сможет открыть привилегированный порт на этом хосте, то вы сможете зафиксировать эту активность либо на хосте, либо в сети хоста, предпочтительно – и там, и там!
Но что если противник изменил (или, что еще хуже: установил!) какой-то маршрутизатор на границе службы, чтобы перенаправить пакеты на другой внутренний хост, и затем, вместо того чтобы этот новый хост прослушивал ожидаемые протоколы (например, HTTPS), условный хост теперь прослушивал какой-то другой протокол (например, SSH)? Я мог бы настроить HAProxy с реверс-прокси уровня 4, который выбирает между TLS или SSH на другом внутреннем хосте только когда IP клиента именно w.x.y.z или порт 0FF0 и т.д.
Вот еще один интересный пример, который показывает дискреционные бэкенды в зависимости от содержимого имени хоста TLS-SNI Gornstein ’17
Документация HAProxy по директивам acl
(Да, этот пример показывает выбор бэкенда SSH в зависимости от первых 7 байтов, которые ваши мониторинги также заметят, но протокол может так же просто быть сделан самодельным или защищен с предшествующим общим ключом, например, WireGuard или ZeroTier. В этих случаях протокол предназначен для маскировки обмена ключами; IMHO, это направление, в котором движутся новейшие протоколы, ориентированные на конфиденциальность.)
Теперь вы можете видеть, что данные движутся по сокету (зашифрованы, конечно!) и никогда не регистрировать никакой протокол. Любое мониторинг, выполненное на хосте X, даже не увидит пакеты, связанные с злонамеренной активностью. Мониторинг в сети увидит активность от хоста Y, но это может быть ошибочно принято за какой-то другой протокол.
Ответ или решение
Обнаружение несанкционированного VPN или шифрованного трафика с использованием правила SNORT
Современные киберугрозы представляют собой серьезную проблему для организаций, и использование шифрованных соединений для скрытия действий злоумышленников является одной из наиболее распространенных тактик. В этом контексте необходимо разработать эффективные правила для системы обнаружения вторжений (IDS) SNORT, чтобы выявить и предотвратить несанкционированный доступ через VPN или другие зашифрованные соединения.
1. Определение угрозы
Атака может начинаться с установки троянского вируса, который создает устойчивое соединение к злоумышленнику через известные и доверенные порты (например, 80, 21, 443). Используя такие инструменты, как OpenVPN, злоумышленник может скрыто эксфильтровать данные, используя разрешенные протоколы, нарушая при этом основные механизмы безопасности компании.
2. Задача SNORT
Основная цель SNORT – это обнаружение подозрительных соединений и аномальной активности в сети. Для этого следует настроить сигнатуры, которые будут анализировать исходящие запросы на элементы, характерные для инициализации VPN или других шифрованных соединений.
3. Обнаружение инициализации VPN или шифрования
Правила SNORT для обнаружения TLS
Чтобы отследить начало TLS-соединения и обмен публичными ключами, рекомендуется использовать следующие правила SNORT:
alert tcp any any -> any 443 (msg:"TLS handshake detected";
content:"|16 01 01|";
offset:0;
depth:3;
metadata:service https;
sid:1000001;
rev:1;)Объяснение:
alert tcp any any -> any 443: Указывает на предупреждение для любого TCP-трафика, направленного на порт 443 (HTTPS).content:"|16 01 01|": Паттерн, указывающий на начало TLS-рукопожатия, что является ключевым этапом для обмена публичными ключами.offset:0; depth:3;: Указывает SNORT, что проверится начало пакета.metadata:service https;: Указывает на сервис, который мы мониторим.sid:1000001;: Уникальный идентификатор для правила.rev:1;: Версия правила.
4. Обнаружение IPsec
Обнаружение ISAKMP (Internet Security Association and Key Management Protocol) для IPsec соединений можно сделать через следующие правила:
alert udp any any -> any 500 (msg:"ISAKMP packet detected";
content:"|0a|";
depth:1;
metadata:service ipsec;
sid:1000002;
rev:1;)Объяснение:
alert udp any any -> any 500: Указывает на предупреждение для любого UDP-трафика на порту 500.content:"|0a|";: Ищет данные, которые идентифицируют ISAKMP.metadata:service ipsec;: Сообщает о мониторинге IPsec.
5. Логирование и реагирование
Для эффективного реагирования на такие угрозы, важно не просто обнаруживать, но и логировать события. Настройте SNORT на создание отчетов и отправку уведомлений для дальнейшего анализа:
output unified2: filename snort.log, log, limit 128Настройка системы для последующего анализа и реагирования в случае обнаружения любых аномалий является важным аспектом безопасности сети.
Заключение
Использование SNORT для обнаружения и предотвращения несанкционированного VPN или шифрованного трафика может значительно повысить уровень безопасности организаций. Однако одно лишь правило не может полностью защитить вашу сеть. Комплексный подход к безопасности, включающий мониторинг, анализ и реагирование на угрозы, является ключом к успешной защите информации. Важно также оставаться в курсе новых угроз и обновлять правила SNORT для адекватного реагирования на изменяющиеся условия в мире киберугроз.