 |
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Бессонная ночь админа, или Возможно ли повышение точности IDS
Бессонная ночь админа, Первые упоминания о системах обнаружения атак (IDS) относятся к 1980 году, и начались с публикации Джона Андерсона (John Anderson) «Computer Security Threat Monitoring and Surveillance». Сегодня же их применяют как в сетях, так и устанавливают на отдельные компьютеры, как правило, в качестве второй дополнительной линии защиты (после firewall) для сигнализации о действиях, которые являются злонамеренными по своему содержанию, и остановки вторжения. Открытость инструментов для атаки и доступность соответствующей информации помогает не только администраторам в изучении уязвимости систем, но и приводит к тому, что у некоторых злоумышленников, как говорят, руки чешутся. Постоянные сканирования, проверки в действии эксплоитов, попытки подбора паролей, сетевые черви – далеко не полный список того, с чем сегодня приходится иметь дело администратору. И к сожалению, в этой ситуации IDS не всегда являются помощниками, а даже наоборот, подчас только мешают нормальной работе. В последнее время их работа все больше и больше вызывает критику за то, что они генерируют большое количество данных, в которых истинные предупреждения смешаны с большим количеством ложных сообщений. Учитывая, что какая-нибудь сотня предупреждений в день на сегодня – далеко не фантастическая цифра (а реально она гораздо больше, и растет постоянно), перебрать и проанализировать поступающий поток информации не в силе ни один админ, на анализ информации тратится большое количество времени, а автоматическое принятие решений может повлечь за собой любые последствия вплоть до отключения всей сети от Интернета. Кроме того, такие системы не различают атаки по степени угрозы и реагируют на малоопасные (а то вообще безопасные для данного узла) атаки или аномалии и выдают сообщения без разбора, независимо от наличия связи между некоторыми действиями. Как пример после сканирования портов далеко не всегда происходит атака. Дошло дело до того, что некоторые просто отказываются от использования сетевых IDS или ограничивают количество датчиков, чтобы не потонуть в этом море информации. Естественно, такое положение дел не могло не остаться незамеченным, и были предприняты попытки найти решения, помогающие уменьшить объем выводимой информации и увеличить точность систем обнаружения атак. Компьютеры и IDS (настоящее время) Существует несколько классификаций IDS, некоторые из них были затронуты в статье Павла Заклякова [13], подробно останавливаться не буду, но для понимания общего вопроса, возможно, кое-где придется повториться. Системы обнаружения атак можно грубо поделить на системы, реагирующие на аномалии (например, HostSentry, использующий технологию Login Anomaly Detection), и системы, использующие технологии anomaly detection и misuse detection, например Snort. Первые, собирая некоторую статистику (продолжительность сеансов telnet, IP-адреса и пр.), отслеживают все измения и в случае существенного отклонения от некоторой нормы бьют тревогу. Хотя, если быть точнее, сейчас различают два типа подобных систем: statistical analysis system и adaptive system. Пример выше описывает статистические системы, адаптивные же, применяя сложные математические модели, строят некие правила для среды и обучаются, изучая поведение пользователей и системы. Детекторы систем misuse detection реагируют на известные атаки и уязвимости, предварительно занесеные в базу данных системы в виде сигнатур. Проблемы есть у обеих систем. Первые требуют серьезных статистических исследований и обучения, и не всегда могут отличить нормальные действия от злонамеренных, хотя надо отметить, это довольно перспективное направление развития систем IDS, и за ними, очевидно, будущее. Вторые не могут обнаруживать новые, не занесенные в базу атаки, при этом при обнаружении новых разновидностей атак существует некоторая латентность, пока ее изучат и занесут в базу, а учитывая, что за полчаса сетевой вирус способен заразить около 100 тысяч компьютеров, эта задержка делает бесполезной такие системы в самом начале эпидемии. Далее IDS делятся на Network-based IDS и Host-based IDS. NIDS просматривают сетевой трафик и реагируют на сетевые атаки, в то время как HIDS защищают отдельный узел. Причем такое разделение обязанностей привело к тому, что NIDS не понимают, что происходит непосредственно на компьютере и оказываются бесполезны при шифровании трафика и наоборот, системе, защищающей хост, абсолютно все равно, что там творится в сети. Выходом из этой ситуации послужило создание гибридных IDS, сочетающих в себе достоинства тех и других. В последнее время все чаще IDS разделяют на собственно IDS, отвечающие за сбор статистики, и IPS (Intrusion Prevention Systems, система предотвращения атак) – системы, позволяющие реагировать на атаки. Если в первом случае админ будет просто завален большим количеством (в том числе ложных, отвлекающих предупреждений), то во втором случае ошибка в определении может иметь более неприятные последствия вроде отказа в доступе вполне лояльным пользователям. И не секрет, что сегодня именно IDS благодаря своим «достоинствам» подчас подвергаются атаке, атакующий таким образом старается сбить администратора с толку, ввести дезинформацию, отвлечь внимание. Некоторые модели повышения точности систем Можно выделить три класса корреляции результатов. Например, возможно отобрать все предупреждения, основываясь на подобии неких атрибутов атаки. Как пример один и тот же IP-адрес, такой метод позволяет обнаружить скрытое сканирование сетей, но, скорее всего, такой подход не сможет полностью обнаружить все зависимости между предупреждениями, хотя бы по причине того, что некоторые параметры очень легко изменить во время атаки, но все равно все угрозы, исходящие из одного адреса, будут рассматриваться как одна, а не несколько угроз, от ложных тревог такая схема не спасет. Но средства вывода информации IDS-систем позволяют рассмотреть собранные данные под любым углом, каким только ни пожелает ее просмотреть и проанализировать админ (IP-адресам, сервисам и пр.), так что проблемы этого класса, можно сказать, уже решены. Также, кроме IP-адреса, сюда можно включить и подобие пакетов, так, например, некоторые реализации программ для DoS-атак подменяют только IP-адрес отправителя, поэтому, захватив такие пакеты, можно обнаружить их почти полную идентичность (установленые флаги, ttl, размер окна приема/передачи), отсюда можно сделать вполне логичное заключение о том, что это одна угроза, а не несколько, и не засорять вывод. Хотя подобные атаки довольно хорошо описываются отдельными методами следующих далее классов. При отборе результатов возможно следование хорошо изученным методикам атак, это так называемые механизмы последствия, но при отклонении в сценарии атаки такая система может и не отреагировать. К тому же механизмы последствия используют методы, которые распознают предупреждения, уровень серьезности атаки и временной интервал между двумя связанными предупреждениями, что не дает достаточно информации, позволяющей собрать воедино всевозможно связанные предупреждения. Кроме того, непросто предсказать, как нападающий может производить атаку или ее части, т.е. разработать достаточно точный набор последствий довольно тяжело. Хотя в общем такие системы позволяют уменьшить объем выводимой информации, собирая в один вывод все возможные предупреждения, соответствующие некоему возможному последствию. Поэтому в данном классе наиболее перспективным мне кажется вариант модели самообучающихся систем. Такой подход позволит автоматически формировать модели для корреляции данных, однако это потребует обучения в каждом отдельном случае. И последний класс применяет более комплексный подход, используя как предпосылки, так и последствия атак. При этом предпосылка атаки определяет то, что должно быть удовлетворено для успешной атаки, а последствие атаки описывает то, что должно произойти в том случае, когда атака действительно удается. При таком подходе этот класс позволяет раскрыть зависимости между предупреждениями и, главное, не ограничен только известными сценариями атаки, хотя некоторые методики не отличают несколько реализаций одной и той же атаки. Все используемые методы третьего класса основаны на предположении, что атака узла связана в несколько часто изолируемых стадий с подготовкой в начале и переходит к более активным действиям в конце. Так, например, сканирование и сбор бан-неров (т.е. предпосылка атаки) должны указать злоумышленнику на используемые (и возможно, уязвимые) сервисы, действия же вслепую могут привести к успеху только в довольно небольшом количестве случаев (для конкретной системы). Существование уязвимых сервисов является хорошей предпосылкой для начала атаки и получения доступа к системе. Эту ситуацию в самой простой форме можно представить как 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 собирает информацию от нескольких источников и поэтому содержащаяся в нем информация может отличаться в зависимости от настроек конкретной системы.
Надо отметить, что тестовые системы, на которых обкатывались методики, описанные в этом пункте, были способны автоматически выявить начало вирусной эпидемии и многие другие аномалии. Несмотря на то, что работа по уменьшению ошибок систем обнаружения атак ведется уже давно, мне пока не удалось найти законченных приложений, которые можно было рекомендовать для применения, особенно это касается свободных проектов. Некоторые ссылки ведут в пустоту, некоторые проекты уже стали коммерческими, и технологии скрыты за семью печатями, получить доступ даже для тестирования не удается, на сайтах организаций, ранее занимавшихся этим вопросом, можно найти лишь некоторые обрывки (некоторые доступны только для нужд образования), позволяющие оценить прогресс, но не собрать систему. Наиболее близко из OpenSource-систем к решению стоят разработчики гибридной IDS Prelude (http://www.prelude-ids.org), о которой речь шла в июньском номере журнала за этот год. По крайней мере сам принцип построения этой системы, доступные датчики, анализирующие аномалии как в сети, так и на отдельном хосте, включая анализ логов и уже имеющиеся скрипты (http://www.rstack.org/oudot/prelude/correlation) позволяют надеяться, что эта работа будет все-таки доведена до конца. Ближайшим, если можно так выразиться, конкурентом, вероятно, является довольно интересный проект STAT (State Transition Analysis Technique, http://www.cs.ucsb.edu/~kemm/netstat.html/projects.html), в котором имеется все, что необходимо для нормальной работы системы и коррелляции поступающих данных: сетевые и хост scenario-based-датчики, и в том числе уже разработан один датчик уровня приложений (application-based) для веб-сервера Apache, анализаторы логов, менеджер и специальный модуль для анализа, предназначенный для идентификации атак, в том числе и многоступенчатых. Подробнее о работе STAT – в следующем номере журнала. Из других разработок стоит отметить работу Колумбийского университета MADAM ID – Mining Audit Data for Automated Models for Intrusion Detection(Columbia IDS), являющуюся частью большого пректа JAM – (Java Agents for Meta-Learning) (http://www.cs.columbia.edu/jam), уже, кстати, тоже успевшего лицензировать свою технологию для коммерческой разработки компанией System Detection, INC. http://www.sysd.com, которая, в свою очередь, обещает в скором выпустить готовые продукты, умеющие распознавать аномальные явления в сети, устранять ложные срабатывания и пр. Основная идея проекта JAM состоит в том, чтобы, используя данные, полученные от нескольких разнородных датчиков, используя свои модели, коррелировать их в некий набор правил, способных произвести общее описание среды, в которую они включены. Судя по описанию, система способна к самообучению, работе в режиме реального времени, возможно обнаружение в том числе и комплексных атак, растянутых во времени, двумя способами anomaly и misuse detection, построение затем сценария атаки. Сам проект разделен на подпроекты, в которых разрабатывается один из компонентов (привожу здесь для того, чтобы вы смогли оценить размах и сравнить с имеющимися системами):
Компания Promia, Incorporated (http://www.promia.com), которая на сайте http://seclab.cs.ucdavis.edu выступает спонсором проекта «Intrusion Detection Analysis Project», в результате создала инструмент Intelligent Agent Security Manager (IASM). IASM собирает информацию от многочисленных источников IDS, firewall, роутеров, VPN и пр., собирает все в кучу и анализирует. В результате своей работы отсеивает ложные тревоги систем IDS, отфильтровывая несущественные для охраняемой сети события, позволяет быстро оценить сложившуюся ситуацию, способен выявить новые атаки. Следующий инструмент TIAA – A Toolkit for Intrusion Alert Analysis (http://discovery.csc.ncsu.edu/software/correlator), который разработан для того, чтобы облегчить интерактивный анализ, используя предупреждения, сделанные системой обнаружения атак. Пока это еще прототип, демонстрирующий возможности корреляции, основанный на предпосылках и последствиях известных атак (рис. 1). Написан на Java и протестирован с Windows 2000/XP c MS SQL Server, используя JDBC, но, очевидно, его можно подружить и с парочкой GNU/Linux с MySQL.
Рисунок 1 Open Source-проект QuIDScor (http://quidscor.source forge.net) демонстрирует соответствие информации, полученной от IDS SNORT и утилитой оценки уязвимости QualysGuard, триал-версию которой можно взять с http://www.qualys.com/?page=services/qg. При обнаружении IDS события QuIDScor отыскивает в сообщении QualysGuard релевантное событие и пытается дать ему оценку в виде одной из трех основных категорий: Validated, Unknown и Invalidated и подкатегорий.
Рисунок 2 Если нужно визуально оценить характер трафика в сети и выявить перекосы, свидетельствующие о возможных проблемах, то в этом случае могут помочь утилиты Security Incident Fusion Tools, к которым относятся NvisionIP (http://distribution.ncsa.uiuc.edu/nvision/NVisionIPv0_2Install.tar.gz) и VisFlowConnect (http://distribution.ncsa.uiuc.edu/visflow/index.html). Утилиты Security Incident Fusion Tools, анализируя журналы, полученные при помощи других утилит, на выходе выдают графическое представление всех проходящих пакетов, некий снимок сети, при этом различие линий по толщине, цвету и направлению позволяют визуально оценить количественные параметры и таким образом получить «снимки» нормальной сети, в случае же существенных отклонений можно сделать вывод о том, что в сети происходит что-то необычное. Для установки NvisionIP вам понадобится D2K – Data to Knowledge (http://alg.ncsa.uiuc.edu/do/downloads/d2k), представляющая собой гибкую обучающуюся систему, в которой интегрированы эффективные аналитические данные, методы для прогнозирования и детектирования изменений. Распространяется D2K под Academic Use License и для возможности ее бесплатной закачки вам потребуется адрес электронной почты в домене edu или очень убедительные аргументы при отсутствии такового. Итак, современные IDS первого поколения не лишены недостатков и требуют существенного пересмотра самого процесса обнаружения угроз, математики уже более-менее разобрались с этой проблемой, дело стало за программистами, которые смогут реализовать требуемые алгоритмы на практике. Остается надеяться, что осталось ждать недолго. Успехов. Литература:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
СЕРГЕЙ ЯРЕМЧУК, фрилансер. Автор более 800 статей и шести книг. С «СА» с первого номера. Интересы: сетевые технологии, защита информации, свободные ОС
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
