И последний класс применяет более комплексный подход, используя как предпосылки, так и последствия атак. При этом предпосылка атаки определяет то, что должно быть удовлетворено для успешной атаки, а последствие атаки описывает то, что должно произойти в том случае, когда атака действительно удается. При таком подходе этот класс позволяет раскрыть зависимости между предупреждениями и, главное, не ограничен только известными сценариями атаки, хотя некоторые методики не отличают несколько реализаций одной и той же атаки. Все используемые методы третьего класса основаны на предположении, что атака узла связана в несколько часто изолируемых стадий с подготовкой в начале и переходит к более активным действиям в конце. Так, например, сканирование и сбор бан-неров (т.е. предпосылка атаки) должны указать злоумышленнику на используемые (и возможно, уязвимые) сервисы, действия же вслепую могут привести к успеху только в довольно небольшом количестве случаев (для конкретной системы). Существование уязвимых сервисов является хорошей предпосылкой для начала атаки и получения доступа к системе. Эту ситуацию в самой простой форме можно представить как Host(IP, Port). Но для успешной атаки требуется, чтобы компьютер с такими параметрами был доступен для нападающего, т.е. не был прикрыт firewall. Отсюда условие, необходимое для успешной атаки, приобретает такой вид: Host(IP, Port) && AccessibleFirewall(IP, Port), и чтобы атака удалась, как вариант необходимо наличие VulnerableWeb Server(IP). Учитывая, что IDS, прослушивая трафик и анализируя результат, «не знает» о настройках firewall и запущенных сервисах, поэтому сигнализирует обо всем, что обнаруживает, поэтому если отфильтровать ненужную информацию, можно убрать часть ложных тревог. При описании последствий атаки (действительно возможного исхода) используется набор предикатов вроде RootAccess(IP), DOSAttask(IP), SystemCompromised(IP) и т. д. Но атака не обязательно может генерировать заявленное последствие. Например, сервис выполняется в изолированной chroot-среде или на сервере установлен один из пакетов, защищающих от возможных последствий переполнения буфера libsafe, LIDS и пр. Но все равно в моделях используется понятие возможных последствий, а не фактических, по причине того, что IDS не может иметь достаточно информации, чтобы принять решение об эффективности атаки. Для того чтобы отслеживать повторяющиеся с течением времени атаки и не засорять вывод, к отслеживаемым параметрам возможно добавление временного интервала. Также в некоторых моделях позволяется частичное удовлетворение предпосылок и последствий, что повышает точность, позволяя определить и соединить в одно предупреждение, в том числе и случайные атаки, когда нападающий вначале пробует сеть на уязвимость, просто указав диапазон адресов в надежде на успех. При этом стоит заметить, что в моделях рассматриваются в первую очередь параметры объекта атаки, т.е. сам уязвимый узел. Параметры нападающей системы менее интересны и имеют меньшее значение для корреляции результатов, что, согласитесь, вполне логично, т.к. тот же IP-адрес можно поменять, используя любой анонимный прокси-сервер, да и большинству админов абсолютно нет никакого дела, кто его сейчас атакует, главными остаются сам факт атаки, служба, подвергшаяся нападению, желание остановить вторжение и уменьшить потери. Но естественно, данные атакующей системы в окончательном результате фигурируют. «Факт», «предпосылка», «последствие» – главные слова в моделях третьей группы.

Что для этого нужно?

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

Если с сетевыми IDS ситуация более-менее ясна, кроме традиционного поиска в пакетах сигнатур атак, основные усилия сосредоточены на создании самообучающихся систем, реагирующих на аномалии (я думаю, это тема отдельного разговора и поэтому сейчас затрагивать ее не буду). Кроме того, основное усилие сейчас сосредоточено на создании распределенных систем, позволяющих определять скоординированные атаки в больших сетях. Такие системы, как правило, состоят из нескольких мониторов, способных общаться друг с другом при определении распределенных атак, решающего устройства для анализа собранных данных, и базы данных, предназначенной для хранения информации. Но все равно для успешного 100% точного детектирования одной информации мало, поэтому сейчас заметны усилия по объединению систем IDS в комплексы. Интересны и перспективны исследования зависимостей некоторых параметров при возникновении тех или иных внештатных обстоятельств.

Например, резкое увеличение количества процессов, загрузка CPU, объем занимаемой памяти отдельным процессом, открытие новых сетевых соединений, подозрительные, т.е. не характерные для данного сервиса последовательность системных вызовов и объемы передаваемой/принимаемой информации и сопоставление полученных результатов. Работа такая ведется, и уже имеются некие алгоритмы, но для UNIX-систем не характерна унификация приложений, и отследить статистику всех вариантов сложнее. Особое внимание исследователей обращено на системные журналы, в которых имеется вся информация о том, что происходит на компьютере. Сопоставляя данные, полученные из различных журналов (в том числе и систем IDS, контроля целостности, honeypot, firewall и пр.), можно сделать вывод о попытке и эффективности атак, кроме того, некоторые неочевидные атаки могут не проявиться в одном журнале, но при сопоставлении нескольких уже можно связать все воедино и увеличить КПД систем IDS. При изучении этого вопроса используется два способа. Первый – берут известную атаку и анализируют записи, оставленные в системных журналах, это позволяет найти общее и выявить классы атак, получить статистику и составить список журналов, в которых обнаруживаются следы тех или иных атак. Во втором способе исследователи сами пробуют опознавать образы атак в многочисленных журналах, выявить аномалии и вывести некие законы. Как пример таблица «Log correlation table», найденная мной в документе «Log Correlation for Intrusion Detection: A Proof of Concept» (http://www.ncassr.org/projects/sift/papers/ACSAC03.PDF), правда, стоит отметить, что syslog собирает информацию от нескольких источников и поэтому содержащаяся в нем информация может отличаться в зависимости от настроек конкретной системы.