Обнаружение вредоносных сигнатур

Введение

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

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

В этой лабораторной работе вы примерите на себя роль аналитика по безопасности. Вы напишете правила Snort для сопоставления содержимого, способные обнаруживать атаки на уровне приложений. В частности, вы проанализируете полезную нагрузку имитированной SQL-инъекции, захваченную в файле PCAP (Packet Capture), и создадите точные правила Snort, используя как базовое сопоставление содержимого, так и расширенные регулярные выражения (PCRE) для проверки HTTP-трафика и оповещения при обнаружении вредоносной строки.

Анализ полезной нагрузки атаки (PCAP)

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

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

Ваша среда предварительно настроена: в каталоге ~/project находится файл sqli_attack.pcap. Этот файл содержит имитированный сетевой пакет, в котором злоумышленник пытается провести SQL-инъекцию против веб-сервера.

Для проверки содержимого этого PCAP-файла можно использовать инструмент tcpdump. Команда tcpdump — это мощный анализатор пакетов командной строки. Используя флаг -A, вы можете вывести содержимое пакета в формате ASCII (обычный текст), что идеально подходит для чтения HTTP-запросов. Флаг -r указывает tcpdump читать данные из файла, а не с активного сетевого интерфейса.

Выполните следующую команду в терминале, чтобы проанализировать полезную нагрузку:

tcpdump -A -r sqli_attack.pcap

Вы должны увидеть вывод, похожий на следующий:

reading from file sqli_attack.pcap, link-type EN10MB (Ethernet), snapshot length 262144
10:23:45.123456 IP 192.168.1.100.12345 > 192.168.1.10.http: Flags [P.], seq 1:78, ack 1, win 8192, length 77: HTTP: GET /login.php?user=admin'%20UNION%20SELECT%201,2,3-- HTTP/1.1
E..u..@.@............9.P..P.P.......+......GET /login.php?user=admin'%20UNION%20SELECT%201,2,3-- HTTP/1.1
Host: example.com

Внимательно посмотрите на текстовую часть вывода. Вы видите HTTP-запрос GET, отправленный к /login.php. Обратите внимание на параметр user: admin'%20UNION%20SELECT%201,2,3--.

Символы %20 — это URL-кодированное представление пробела. Фраза UNION SELECT является классической сигнатурой SQL-инъекции, при которой злоумышленник пытается объединить результаты своего вредоносного запроса к базе данных с исходным запросом. Это именно та сигнатура, которую мы хотим обнаружить.

Написание правил сопоставления содержимого

На этом этапе вы напишете свое первое пользовательское правило Snort для обнаружения сигнатуры SQL-инъекции, которую вы обнаружили на предыдущем шаге.

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

Правила Snort пишутся с использованием определенного синтаксиса. Базовое правило состоит из заголовка правила и опций правила.

• Заголовок определяет действие, протокол, IP-адреса источника/назначения и порты.
• Опции определяют конкретное содержимое для поиска и сообщение, которое нужно отобразить при срабатывании оповещения.

Мы создадим правило, которое ищет точную строку UNION%20SELECT в любом TCP-трафике, направленном на порт 80 (стандартный HTTP-порт).

Откройте файл пользовательских правил с помощью текстового редактора nano:

nano ~/project/rules/local.rules

Добавьте в файл следующую строку:

alert tcp any any -> any 80 (msg:"Basic SQL Injection Detected"; content:"UNION%20SELECT"; sid:1000001; rev:1;)

Разберем, что означает это правило:

• alert: Действие, которое нужно выполнить при совпадении правила (генерировать оповещение).
• tcp: Протокол для проверки.
• any any -> any 80: IP-адрес и порт источника (любой) направляются к IP-адресу назначения (любой) на порт 80.
• msg:"...": Сообщение оповещения, которое будет показано аналитику.
• content:"UNION%20SELECT": Точная строка, которую Snort будет искать в полезной нагрузке пакета.
• sid:1000001: Идентификатор Snort. Пользовательские правила должны иметь ID 1 000 000 или выше.
• rev:1: Номер редакции правила.

После добавления строки сохраните файл и выйдите из nano, нажав Ctrl+O, Enter, а затем Ctrl+X.

Вы можете проверить содержимое файла правил с помощью команды cat:

cat ~/project/rules/local.rules

Настройка PCRE (регулярных выражений)

На этом этапе вы расширите свои возможности обнаружения, используя PCRE (Perl Compatible Regular Expressions — регулярные выражения, совместимые с Perl).

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

Хотя ключевое слово content быстрое и эффективное, оно очень жесткое. Злоумышленники часто пытаются обойти обнаружение, слегка изменяя свои полезные нагрузки. Например, вместо %20 (URL-кодированный пробел) злоумышленник может использовать обычный пробел (``), несколько пробелов или знак плюса (+). Простое сопоставление content пропустит эти вариации.

PCRE позволяет писать гибкие шаблоны. Мы напишем второе правило, которое использует регулярное выражение для перехвата вариаций атаки UNION SELECT.

Снова откройте файл правил:

nano ~/project/rules/local.rules

Добавьте следующее новое правило на новой строке под первым правилом:

alert tcp any any -> any 80 (msg:"Advanced SQL Injection Detected"; pcre:"/UNION(%20|\s|\+)SELECT/i"; sid:1000002; rev:1;)

Разберем опцию pcre:

• pcre:"/ ... /i": Слэши обозначают начало и конец регулярного выражения. Буква i в конце делает поиск нечувствительным к регистру (будет соответствовать union, UNION, UnIoN и т.д.).
• UNION: Соответствует слову UNION.
• (%20|\s|\+): Это группа захвата с логикой ИЛИ (|). Она соответствует либо %20, ЛИБО символу пробела (\s), ЛИБО знаку плюса (\+).
• SELECT: Соответствует слову SELECT.

Сохраните файл и выйдите из nano (Ctrl+O, Enter, Ctrl+X).

Теперь ваш файл local.rules должен содержать два различных правила, предназначенных для перехвата попыток SQL-инъекций.

Проверка обнаружения правил

На этом заключительном этапе вы протестируете свои пользовательские правила. Вы запустите Snort в автономном режиме, указав ему прочитать файл sqli_attack.pcap и применить правила, которые вы только что написали в local.rules.

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

Snort можно запускать с различными флагами. Вот что мы будем использовать:

• -q: Тихий режим (Quiet mode). Подавляет вывод большого баннера и текста инициализации, делая вывод более читабельным.
• -c: Указывает файл конфигурации или правил для использования.
• -r: Указывает PCAP-файл для чтения.
• -A console: Указывает Snort выводить оповещения непосредственно в консоль терминала.

Выполните следующую команду, чтобы протестировать свои правила на вредоносной полезной нагрузке:

sudo snort -q -c rules/local.rules -r sqli_attack.pcap -A console

Если ваши правила были написаны правильно, вы должны увидеть вывод, похожий на этот:

10/23-10:23:45.123456  [**] [1:1000001:1] Basic SQL Injection Detected [**] [Priority: 0] {TCP} 192.168.1.100:12345 -> 192.168.1.10:80
10/23-10:23:45.123456  [**] [1:1000002:1] Advanced SQL Injection Detected [**] [Priority: 0] {TCP} 192.168.1.100:12345 -> 192.168.1.10:80

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

Резюме

В этой лабораторной работе вы получили практический опыт обнаружения сетевых вторжений, написав пользовательские правила Snort. Вы начали с анализа необработанного захвата пакетов, чтобы идентифицировать конкретную сигнатуру атаки SQL-инъекции. Затем вы узнали, как перевести эту сигнатуру в базовое правило Snort для сопоставления содержимого. Наконец, вы расширили свои возможности обнаружения, внедрив регулярные выражения, совместимые с Perl (PCRE), для перехвата вариаций атаки, и успешно проверили свои правила, запустив Snort против вредоносного трафика. Эти навыки являются фундаментальными для любого специалиста по кибербезопасности, которому поручено защищать сетевую инфраструктуру.