 |
Структура системы обнаружения нарушителя.
|
|
|
|
Обобщение опыта построения СОН было сделано в документе “Единая структура систем обнаружения нарушителя”. В данном документе определено множество компонентов, образующих СОН:
· генератор событий (E-box);
· модуль анализа (A-box);
· модуль хранения (D-box);
· модуль контрмер (C-box).
На рисунке 2 показана взаимосвязь компонентов СОН.
Генератор событий предназначен для регистрации событий в системе и передаче их остальным модулям СОН. Событие может быть как “сложным”, так и низкоуровневым событием в сети. Генератор событий является модулем, связывающим СОН с внешним миром (без него СОН не имеет информации о событиях в системе, относящихся к безопасности).
Модуль анализа обрабатывает информацию от генератора событий. Большая часть исследований в области обнаружения нарушителя посвящена различным методам построения модуля анализа.
Генератор событий и модуль анализа обеспечивают систему большим количеством информации об активности системы. Данная информация может быть востребована и использована пользователями системы по истечении некоторого периода времени. Хранением информации, сгенерированной во время работы СОН занимается модуль хранения.
Многие СОН построены так, что в ответ на атаку, они выдают только сигнал тревоги. Однако, коммерческие системы часто имеют в своем составе модуль контрмер. Данный модуль может по желанию пользователя СОН автоматически запускать некоторый процесс, закрывать соединение TCP или модифицировать конфигурацию МЭ с целью предотвращения дальнейших атак.
Говоря об архитектуре СОН невозможно обойти вниманием вопрос о периодичности работы СОН.
Рассмотренные ранее сканеры уязвимостей, обычно ищущие уязвимости хоста или сети, выполняются периодически. Недостатком данного подхода является то, что нарушение безопасности системы может произойти в период между сканированиями. СОН также могут быть построены на основе периодического выполнения в пакетном режиме. Но современная практика показывает, что предпочтение отдается анализу нарушений в реальном режиме.
|
|
|
Функционирование в режиме реального времени, естественно, налагает дополнительные требования на производительность системы и использование программой ресурсов. Выходом из создавшейся ситуации мог бы быть адаптивный режим функционирования (анализ при получении определенного числа событий), но в настоящее время в коммерческих системах он не реализован (проблемой является определение минимального количества событий, при получении которых целесообразно проводить анализ).
Таким образом, целесообразно использовать оба типа анализа нарушений безопасности системы. При низкой вероятности атаки целесообразно использовать периодический подход к анализу нарушений безопасности, а при высокой вероятности атаки желательно использовать анализ в реальном времени.
В следующих параграфах рассмотрим модули СОН подробнее.
Модуль сбора и фильтрации данных.
СОН различаются между собой по источнику данных. Данные для СОН могут поступать от хоста или от сети.
СОН хоста могут быть использованы для обнаружения атак, связанных с некорректным использованием системы авторизованными пользователями. Хотя для сбора данных в СОН хоста могут использоваться стандартные средства аудита ОС (не предназначенные для анализа безопасности систем), желательна разработка специализированных подсистем аудита. Это связано с тем, что обычные системы часто собирают информацию бесполезную для определения нарушения безопасности системы, тогда как важная информация зачастую не фиксируется. Особенности данных, которые должны быть зафиксированы, зависят от типа приложений функционирующих в системе и от метода, используемого при обнаружении нарушителя.
|
|
|
Кроме записей аудита система обнаружения использует следующие данные:
- внешние факты, такие как изменение статуса пользователя, информация о новых пользователях и прекращении их полномочий и т.д.
- информация об используемых файлах, устройствах и т.д.
- профили ожидаемого от пользователя поведения.
Уровень функционирования системы аудита целесообразно выбирать в зависимости от атак, которые предполагается обнаруживать, а так же в зависимости от сложности и быстродействия системы обнаружения нарушителя. Естественно, чем более высокий уровень выбран для функционирования системы аудита, тем проще обработка данных. Но при этом возрастает вероятность обхода подсистемы аудита нарушителем.
Можно привести следующие схемы аудита:
- системных вызовов и их аргументов;
- приложений и их аргументов;
- всех вводимых пользователем данных и откликов системы.
В зависимости от типов предполагаемых атак можно предложить следующие методы аудита для СОН хоста.
1. Аудит входа в систему; собирает данные о том, кто, когда и как вошел в систему. При этом целесообразно фиксировать:
· имя пользователя, вошедшего в систему;
· наименование терминала или удаленного хоста, с которого был осуществлен вход в систему;
· время входа и выхода пользователя.
2. Аудит процессов; собирает данные о том, какие сервисы системы были использованы. При этом целесообразно фиксировать:
· условия исполнения (используются ли права суперпользователя) процесса;
· значение, возвращаемое процессом при завершении;
· имя пользователя и группы;
· терминал, с которого запущен процесс;
· время вызова процесса;
· время, проведенное в режиме пользователя;
· время, проведенное в режиме ядра;
· общее время выполнения;
· средняя использованная память;
· количество обработанных символов;
· количество считанных – записанных блоков информации;
· имя команды для запуска процесса.
3. Аудит ошибок и административных данных.
Сетевой СОН работают с сетевым трафиком и обнаруживают атаки, связанные с низкоуровневым влиянием на сетевые протоколы, и могут обнаружить атаки на несколько хостов сети. Сетевой СОН строится на основе интеллектуального анализатора трафика, обрабатывающего каждый проходящий через него фрейм данных на предмет поиска в нем запрещенных сигнатур, обозначающих атаки. Сетевые данные, сетевой трафик получают от сетевого адаптера функционирующего в promiscuous моде (т.е. принимая все пакеты в сети).
|
|
|
Пример топологии сети, использующей СОН сети приведен на рисунке 3.
Библиотека Libcap является свободно-распространяемой библиотекой сбора сетевых пакетов. Данная библиотека обеспечивает ПО независимостью от технологии построения сети (Ethernet, FDDI, SLIP и т.д.), что способствует переносимости данной библиотеки на различные программно-аппаратные платформы и, как следствие, популярность данной библиотеки. Libcap обладает возможностью фильтрации данных на основе установки фильтра, такого как BPF, который позволяет отбрасывать многие сетевые пакеты, не передавая их ядру.
Одной из основных проблем сетевых СОН является быстродействие, т.к. лучшие из них в состоянии функционировать при пропускной способности сети около 100Мбт, но не могут обеспечить нормальное функционирование в гигабитных сетях.
В данном параграфе объединим перечисление данных аудита, которые нам необходимо снимать для обнаружения удаленных атак, с характеристиками семейства протоколов TCP/IP.
ARP запрос
· IP адресом источника;
· аппаратный адрес источника;
· сетевой интерфейс ограничивающий ARP запрос.
IP-фрагмент.
· адрес источника;
· адрес приемника;
· поле протокола;
· поле смещения;
· длина;
· длина заголовка;
· MF бит;
· идентификация.
IP датаграмма
· сообщение о перекрытии фрагмента;
· содержимое фрагмента при перекрытии.
ICMP сообщение
· IP адрес источника;
· IP адрес приемника;
· ICMP поле типа;
· ICMP идентификатор;
· ICMP номер последовательности.
TCP пакет
· IP адрес источника;
· IP адрес приемника;
· TCP порт источника;
· TCP порт приемника;
· бит кода TCP.
TCP модуль
|
|
|
· переходы из состояния LISTEN в состояние SYN_RECVD;
· переходы из состояния SYN_RECVD в состояние LISTEN;
· переходы из состояния SYN_RECVD в состояние CONNECTED;
· сравнение полуоткрытых соединений с числом возможных соединений.
Одним из достоинств использования сетевого СОН является отсутствие его влияния на функциональность и производительность сети, а также невозможность передачи в сети пакета, копию которого не получил бы сетевой СОН.
Фильтрация данных – анализ данных с целью выявления наиболее значимых компонентов данных для уменьшения времени обработки и места для хранения. Фильтрация данных необходима для:
· повышения эффективности анализа;
· уменьшения загрузки сети при передаче данных между модулями СОН;
· уменьшением места необходимого для хранения данных.
Фильтрация данных повышает эффективность работы систем обнаружения нарушителя. В качестве примера уменьшения данных аудита можно привести “оригинальную” идею, выдвинутую в начале развития дисциплины обнаружения нарушителя “о выборочном контроле приложений по примеру транспортных контролеров”.
Фильтрация данных может состоять как в отбрасывании несущественных для процесса обнаружения нарушителя данных, так и в кластеризации данных с целью выявления скрытых шаблонов с дальнейшим хранением характеристик кластера. Различают статистическую кластеризацию, кластеризацию на основе примеров (для каждого кластера строится экземпляр-пример), кластеризацию на основе измерения расстояний и концептуальную кластеризацию (удовлетворение определенным условиям для членства в кластере).
Фильтрация данных должна проводиться осторожно, т.к. могут быть отброшены важные для анализа данные. В таких системах как DIDS, MIDAS, TIM, NSM данные фильтруются на основе эвристик (экспертных правил), которые могут быть просмотрены и отредактированы.
СОН хоста в состоянии анализировать только высокоуровневые события и не могут работать с низкоуровневыми событиями сети. Наряду с очевидными преимуществами сетевых СОН можно выделить следующий их недостаток: сетевые СОН не могут определить, что в точности происходит в системе, на это способны только СОН хоста, основываясь на информации, получаемой от операционной системы.
Преимуществом сетевых СОН является:
· высокая эффективность – сетевые СОН можно поместить только в критических точках сети, защищая с помощью одной СОН большое количество хостов; кроме того, функционирование сетевых СОН не влияет на производительность хостов;
· анализ пакетов - сетевые СОН анализируют все пакеты, проходящие через них на предмет наличия подозрительных действий; только на основании данного анализа могут быть обнаружены современные атаки, связанные с отказом в обслуживании (СОН хоста не в состоянии обнаружить атаки данного типа);
|
|
|
· устранение доказательств - сетевые СОН используют для анализа и сохраняют в режиме реального времени сетевой трафик, проходящий через них. Нарушителю часто бывает затруднительно удалить эти данные (хранение данных аудита в СОН хоста часто стандартизовано; место их хранения известно нарушителю; данная ситуация может привести к устранению доказательств).
· обнаружение и отклик в реальном времени - сетевые СОН распознают атаки и реагируют на них в режиме реального времени (для СОН хоста отклик на нарушение часто приходит уже тогда, когда нарушение состоялось);
· обнаружение намерения вторжения - сетевые СОН могут использоваться для обнаружения намерения вторжения. Это достигается, например, помещением СОН вне области, защищаемой МЭ (при этом атаки на хосты внутренней сети фиксируются на СОН, но не проходят через МЭ). СОН хоста не обладают такой возможностью. На основании обнаружения намерения вторжения можно получить такую интересную статистику, как частоту и типы атак на систему.
· дополнение и верификация существующих механизмов защиты – сетевые СОН могут дополнять существующие механизмы защиты; использование в сети механизмов шифрации не позволяет СОН обнаруживать атаки в зашифрованном трафике; однако, СОН могут обнаруживать трафик, остающийся незашифрованным; при применении МЭ СОН позволяет верифицировать его функционирование;
· независимость от типа ОС - сетевые СОН в первом приближении не зависят от типа ОС, функционирующих на хостах сети.
Преимуществами СОН хоста является:
· верификация атак – базируясь на данных аудита, СОН хоста анализируют события, которые действительно произошли в системе, что дает преимущество при анализе, т.к. имеется информация об успехе или неудаче атаки. Это приводит к большей точности определения атак, и, соответственно, к меньшему числу ложных срабатываний (сетевые СОН характеризует большой процент ложных срабатываний, т.к. нормальный трафик очень часто похож на трафик, содержащий атаку; кроме того сетевое СОН не имеет информации об успехе атаки);
· активность на хосте - СОН хоста может легко отслеживать активность на хосте, т.е. действия пользователей, доступ к файлам, вход и выход из системы и т.д. (сетевое СОН не имеет возможности отследить данную активность); сетевые СОН так же неспособны определить изменения в политике безопасности системы.
· использование шифрации – применение шифрации при передаче данных по сети может создавать трудности для работы сетевых СОН; СОН хоста не имеют данной проблемы, т.к. базируются на данных аудита, содержащих незашифрованные данные;
· мониторинг ключевых компонентов - СОН хоста могут осуществлять мониторинг ключевых объектов, таких как ключи реестра, исполняемые файлы, динамические библиотеки и т.д., с помощью компрометации которых может быть осуществлено вторжение в систему; при изменении данных компонентов сетевое СОН может генерировать отклик; сетевое СОН неспособно на это.
· отсутствие необходимости использования дополнительного аппаратного обеспечения – СОН не требует дополнительного аппаратного обеспечения для обнаружения нарушителя, т.к. обычно выполняется на защищаемых объектах сети, что делает их в некоторых случаях более эффективными, чем СОН сети;
Примеры, иллюстрирующие необходимость применения каждого подхода приведены на рисунках ниже.
Вопрос более эффективного построения IDS на базе хоста или на базе сети в настоящее время разрешен с применением комбинированной технологии, сочетающей в себе оба подхода в связи с тем, что оба подхода имеют собственные преимущества и удачно дополняют друг друга.
Организация ловушек в сети состоит в установке в вычислительной системе хоста-приманки, который легко уязвим для нарушителя. Эта уязвимость может быть вызвана использованием незащищенной операционной системы или внесением в защищенную систему одной или нескольких известных уязвимостей. Хост-приманка должен содержать информацию схожую с реальной информацией, обрабатываемой в вычислительной системе. Естественно, данная информация должна быть ложной или малозначащей.
Нарушитель, “взломав защиту” на хосте-приманке, будет считать, что он получил доступ к секретной информации. В то время как он будет собирать информацию на хосте-приманке, можно будет собирать информацию о самом нарушителе. По собранным данным часто можно оценить квалификацию нарушителя, средства используемые им, а иногда и идентифицировать самого нарушителя. Собранные сведения часто помогают подготовиться к отражению реальной атаки на внутреннюю сеть организации.
Обычно хост-приманка помещается в “демилитаризованной зоне” (фрагмент сети, располагающийся между защищенной сетью и общедоступной областью), что защищает внутреннюю сеть организации от нападения при компрометации хоста-приманки. Весь трафик, направляемый на хост-приманку, считается подозрительным.
Модуль реакции
При обнаружении атаки СОН может выполнить следующие действия:
· переконфигурировать МЭ, заблокировав IP адрес, с которого была осуществлена атака;
· выдать звуковой сигнал;
· записать соответствующее событие в системный журнал;
· послать SNMP Trap на консоль администратора;
· послать e-mail сообщение администратору;
· послать сообщение на пэйджер администратору;
· записать информацию об атаке (время, IP адрес нарушителя, IP адрес / порт цели атаки, информацию о протоколе);
· записать данные атаки (поток пакетов) для дальнейшего анализа;
· запустить определенную программу;
· оборвать TCP соединение посылкой FIN пакета.
|
|
|
