Персональные фаирволлы и выявление вторжений Кандид Вюст [Candid W\"uest] Швейцарский Федеральный Институт Технологий, Лаборатория компьютерной инженерии и сетей Сокр. пер. с англ. Oleg Morozov, Marїnais. 03.11.2005 Дипломная работа DA─2003.22 Зимний семестр 2002/2003 Преподаватели: Дьего Дзамбони [Diego Zamboni] (IBM R\"uschlikon Res. Lab), Марк Реннхард [Marc Rennhard] Руководитель: Проф. Д-р Бернхард Платтнер [Bernhard Plattner] 28.02.2002─08.02.2002 Аннотация Использование персональных фаирволлов в наши дни получает всё большее распространение. Цель этой работы ─ детальный анализ использования персональ- ных фаирволлов для лучшего понимания их возможностей, сильных и слабых мест. Поскольку инсталлируются они на машины конечных пользователей совместно с дру- гими приложениями, возникает вопрос, способствуют ли они усилению безопасности или же открывают в безопасности охраняемой машины новые бреши. Интересна идея проанализировать совместную работу нескольких образцов персональных фаирволлов с системами выявления вторжений [intrusion detection system, IDS]. Для этого были сформулированы правила выявления атак по собранным логам и введён унифи- цированный формат лога персонального фаирволла, позволяющий соотносить соот- ветствующие события из различных логов. Глава 1 Введение 1.1 Обоснование Соединение с Интернетом из различных мест стало обыденностью. Часто оно функционирует днём и ночью. Даже дома многие люди имеют ПК, соединённый с Ин- тернетом 24 часа в сутки. В течение всего этого длительного времени машины оказываются подверженными опасностям Интернета. Чем дольше подключена машина, тем более вероятно, что она подвергнется злонамеренному воздействию. Новые технологии типа беспроводных сетей ещё больше увеличивают риск подвергнуться атакам, поскольку открывают новые возможности для их осуществления. Под влия- нием недавних историй с компьютерными вирусами и червями, распространяющимися по Интернету и наносящими ущерб, пользователи медленно, но верно осознают на- личие в Интернете опасности и свою потребность в защите от неё [7]. В малых организациях уровень обеспечения безопасности часто не на высоте и даже в организациях больших, с хорошей политикой безопасности, в порядке ве- щей то, что служащие берут свои портативные компьютеры из офисов домой и там с них подключаются к Интернету. В этот момент все данные в них, прежде находив- шиеся под защитой системы безопасности организации, оказываются подверженными возможной атаке. После же успешного вторжения в такую машину, она, будучи воз- вращённой обратно в корпоративную сеть, может затем заражать другие машины в интранете. По этой причине люди начали использовать для защиты от атак персо- нальные фаирволлы. Но в отличие от антивирусной программы, наличие которой стало в наше время делом привычным, персональный фаирволл столь же обычным по- ка ещё не стал. В противоположность традиционному подходу, при котором фаирволлы рекомен- дуется инсталлировать на специально выделенную и хорошо охраняемую машину, персональные фаирволлы инсталлируются на машинах конечных пользователей сов- местно с широким кругом утилит и приложений. Это порождает вопрос, действи- тельно ли они обеспечивают дополнительную безопасность, или, будучи также уяз- вимы к новым атакам, снижают её в итоге. При контроле системы на предмет атак для достижения большей безопасности следует проанализировать и рассмотреть ло- ги персональных фаирволлов. Попыток в направлении сравнения зарегистрированных фаирволлами событий ещё не предпринималось, хорошо детализированные тесты воз- можностей персональных фаирволлов также редки [1]. Доступные же результаты тестов обычно являются ориентированными на простого потребителя и в детали глубоко не вникают [4]. Данная работа не претендует на роль ещё одного сравнительного исследова- ния персональных фаирволлов на предмет простоты их эксплуатации или привлека- тельности их внешнего вида. Вместо этого, на первом этапе она ставит целью со- ставить общую концепцию использования персональных фаирволлов и вопрос о том, насколько их применение для защиты машины имеет смысл с точки зрения безопас- ности. На втором этапе предлагаются механизмы коррелирования порождаемых собы- тий с целью интеграции персональных фаирволлов в единую систему безопасности. Логи в повседневной практике обычно никак не используются и в дальнейшем выб- расываются. Их анализируют только при возникновении проблемы, требующей изуче- ния. Размышления над всей потенциально полезной зарегистрированной информаци- ей, остающейся неиспользованной, являются ещё одним поводом внимательнее прис- мотреться к возможным применениям этой информации. 1.2 Другие источники по теме Во время написания этой работы автор не был осведомлён о каких-либо ис- точниках, непосредственно относящихся к данной теме. Большинство работ по кор- релированию логов затрагивает только фаирволлы сетевые, а не персональные [12]. Можно отыскать лишь несколько анализаторов логов, способных обрабатывать логи фаирволлов персональных. Примером может служить утилита "Symantec's Deep Sight", также используемая в "Security Focus", способная просматривать логи некоторых персональных фаирволлов, напр., "Zonelabs Zonealarm" [2]. Другим средством является "DShield", позволяющий пользователям подвергнуть их логи совместному исследованию [6]. Обычно они ограничены в возможностях несколькими широко используемыми персональными фаирволлами и не поддерживают многие их версии. Другим недостатком этих утилит является то, что пользователи часто не получают детальный анализ атак на свои домашние сети. Информация только добав- ляется в общую базу, и анализу подвергаются все события вместе. Тот, кто уже имеет инфраструктуру безопасности, вероятно, хочет иметь да- лее возможность обрабатывать всю связанную с происходящими событиями информа- цию самостоятельно. Передача данных вовне может также противоречить политике безопасности. Утилиты типа "DShield" в большей или меньшей степени работают по принципу передачи логов третьей стороне, которая затем генерирует статистику, такую как порты, сканировавшиеся наиболее часто, но они не создают детальный отчёт об атаках, которые предпринимались на машину. Вдобавок, нет возможности легко интегрировать результаты в коррелирующий движок для принятия решений. По теме данной работы известно несколько коротких статей, поднимающих вопрос об использовании персональных фаирволлов в качестве дешёвых средств вы- явления вторжений в сеть. Одна из них принадлежит Маркусу Рануму [Marcus J. Ranum [1]], но она не вникает в детали того, как эту идею реализовать и что именно такое применение персональных фаирволлов может дать. Она только указы- вает, что это, вероятно, имеет смысл. С другой стороны, исследований персональных фаирволлов проводилось уже множество, и обзор таких исследований успел опубликовать чуть ли ни каждый компьютерный журнал. Беда же подобных статей в том, что они в основном предна- значены лишь помочь конечному пользователю в выборе продукта, с которым было бы легко работать. Это означает, что их внимание чаще сосредоточено не на внутренних механизмах и действительных возможностях персональных фаирволлов, а на том, насколько хорошо выглядит графический интерфейс (GUI) или насколько оперативно реагирует служба поддержки. Такой тип обзоров может представлять интерес для пользователей, но тестов, которые анализировали бы происходящее "за кулисами", всё ещё недостаточно. Пример более технического исследования персональных фаирволлов можно найти на сайте "Boran" [3]. Некоторые сайты про- вели общие исследования персональных фаирволлов с помощью т.н. "средств тести- рования утечек", чтобы опробовать возможность похищения информации из охраняе- мой системы. Многие из них оказались очень успешными и утверждают, что персо- нальные фаирволлы небезопасны и бесполезны. К несчастью, в некоторых из них использовались такие атаки, от которых фаирволл защищать не предназначен, и потому естественно был посрамлён. Поэтому, в исследовательской части данной работы был рассмотрен ряд применяющихся на практике приёмов. Причины неудач в защите от определённых видов атак исследованы ниже в гл. 5. Упомянутые сайты могут быть найдены на "PC flank" [5] или в статье [4]. 1.3 Персональные фаирволлы 1.3.1 Принципы работы персональных фаирволлов Для защиты сетей специалистами в области защиты информации давно применя- ются фаирволлы сетевые. Таковым может быть как аппаратное устройство, так и программа, исполняемая на специально выделенной машине. В обоих случаях должно иметься, по меньшей мере, два сетевых интерфейса: один для сети защищаемой и один для сети внешней. Сетевой фаирволл расположен в точке соединения или гей- те между двумя сетями ─ обычно частной сетью и общей, такой как Интернет. Ран- ние компьютерные фаирволлы были простыми маршрутизаторами. Весь траффик, про- ходящий через сетевой фаирволл, анализировался и, в зависимости от того, под какие критерии он попадал, пропускался или, наоборот, блокировался [17]. Но для простого домашнего компьютерного пользователя сетевой фаирволл обычно слишком сложен и дорог. Это часто является причиной, по которой простые домаш- ние пользователи не используют сетевые фаирволлы даже для собственной защиты. Так возникает идея фаирволла персонального. Персональные фаирволлы, иногда также называемые "персональными брандмауэ- рами" и "межсетевыми экранами" (МСЭ) [англ.: "desktop firewalls", "personal firewall", "distributed firewalls"] предназначены для конечных пользователей и не пытаются подменить собой фаирволлы сетевые. Их задача ─ быть простыми в на- стройке и обслуживании. Большинство персональных фаирволлов сконфигурировано заранее так, чтобы не обременять пользователя сложным программированием пра- вил, и так, чтобы при возникновении в процессе дальнейшей эксплуатации непред- виденной ситуации в формировании необходимого правила помог бы автонастройщик. Как следует из названия, персональные фаирволлы ─ это приложения уровня хоста, исполняемые на пользовательской машине. Вследствие этого они способны анализировать только траффик, направленный к охраняемой машине. Персональный фаирволл ─ это обычно пакетный фильтр без сохранения состоя- ния. Последнее означает, что фильтр не отслеживает состояние соединения ─ ре- шение о пропуске или блокировании каждого пакета он принимает на индивидуаль- ной основе [17]. В противоположность этому, фильтры с сохранением состояния принимают пакеты только тогда, когда текущее состояние соединения делает это возможным. Поэтому, пакетный фильтр без сохранения состояния ─ это приложение, которое принимает пакеты, самостоятельно анализирует их заголовки и затем, в зависимости от правил, установленных пользователем, принимает по ним решение. Работа происходит на уровне IP-пакетов. Недостаток анализа без сохранения сос- тояния в том, что пакеты, недоступные в определённом состоянии связи, тем не менее, персональным фаирволлом могут быть получены. Персональные фаирволлы обычно не осуществляют фильтрацию содержимого па- кетов. Это означает, что они не анализируют внутренность пакетов на предмет опасного содержимого. Персональный фаирволл анализирует только заголовки паке- тов. 1.3.2 Основания для использования персонального фаирволла Основной задачей персонального фаирволла является мониторинг и возможное блокирование входящего и исходящего сетевого траффика машины согласно желаниям пользователя. Обычно это осуществляется через правила фильтрации пакетов. Т. о., механизм мало отличается от обычного сетевого фаирволла, за исключением того, что последние фильтруют траффик, предназначенный для множества машин, тогда как фаирволлы персональные проверяют только пакеты, предназначающиеся одной локальной машине. Дополнительно персональные фаирволлы могут проверять название приложения, устанавливающего соединение, что позволяет им фильтровать по правилам приложе- ния. Это означает, что правила фильтрования могут включать не только IP-адре- са, но и названия доверяемых или недоверяемых приложений, предоставляя большую гибкость в настройке. Задачи персонального фаирволла могут быть разделены на две категории. Во- первых, он должен защищать от атак на охраняемую машину извне. Это включает такие их виды как сканирование портов, злоупотребление открытыми демонами типа сетевых ресурсов совместного доступа и DoS-атаки. Вторая категория ─ это атаки или угрозы, происходящие изнутри системы, такие как троянский сервер, пытаю- щийся установить соединение с базой или адварная утилита, пытающаяся раскрыть продавцу какую-либо личную информацию о клиенте. Задачей персонального фаир- волла является пресечение или, по крайней мере, обнаружение и оповещение о по- добных действиях. Существует много причин использовать персональный фаирволл, даже на маши- не, расположенной за полноценным фаирволлом сетевым. Первая причина ─ это создание второй линии обороны от атак и повышение общей безопасности. Всилу того, что конфигурация и характер уязвимостей персо- нальных фаирволлов отличны от таковых у фаирволлов сетевых, системы защиты атакующему придётся пробивать уже две. Поиск двух различных эксплойтов, кото- рые могли бы работать совместно, снижает шансы атаки на успех. Далее, те внеш- ние фаирволлы, которые обычно размещаются на границах сети, не помогут, когда атака предпринимается изнутри сети. Согласно некоторым исследованиям, большин- ство атак происходит из сетей локальных [13]. Даже если вы полностью доверяете своим коллегам, вы не можете быть уверены в том, что их машины не взломаны и не используются им вопреки. Другое достоинство персональных фаирволлов в том, что они учитывают ло- кальную обстановку. Более того, у них есть доступ к таким сведениям как назва- ние приложения, устанавливающего соединение, а не только IP-адрес машины. Рас- смотрение этой дополнительной информации, делает возможным принятие решений по тонким признакам. Напр., предположим, что некоторая адварь проинсталлировала себя в машину и пытается отослать личные данные в маркетинговую компанию через HTTP. Большинство внешних фаирволлов сконфигурировано так, чтобы не препятст- вовать подобному траффику, поскольку он выглядит как вполне нормальная работа по HTTP. Правильно же сконфигурированный фаирволл персональный, по меньшей ме- ре, прежде, чем отослать пакеты, проинформирует пользователя и сообщит назва- ние опасного приложения. Однако, персональные фаирволлы полезны не только про- тив таких малозначительных угроз как адварь, но и на практике эффективны про- тив червей. Как показывают недавние события, компьютерные черви распространя- ются так быстро, что пользователи не успевают обновлять свои антивирусные ба- зы, чтобы их отлавливать. Напр., компьютерный червь "SQL.Slammer" (известный также как "Hellkern" или "Sapphire") в первые минуты своего появления удваивал количество заражённых машин каждые 9 с [8]. Через 11 мин он охватил весь Ин- тернет. Персональные фаирволлы отлично справляются с задачей пресечения тех компьютерных червей, которые распространяются по сети, поскольку блокируют ис- ходящие соединения неизвестным приложениям. Поэтому, если червь пытается отос- лать себя с заражённой машины, он окажется заблокирован персональным фаирвол- лом, и заражение им других машин будет предотвращено. И хотя в этом сценарии заражение первой машины предотвращено не было, общая ситуация, тем не менее, сохранилась под контролем. Многие домашние пользователи считают, что они в безопасности. Они рассуж- дают так: "Ну кому могут понадобиться мои данные, у меня нет ничего ценного, и даже если я потеряю данные, мне наплевать". Даже если согласиться с таким под- ходом, использование персональных фаирволлов всё равно сохраняет смысл. Осо- бенно это касается домашних пользователей постоянного подключения к Интернету типа DSL, которые всё больше и больше становятся объектом атак. Причина не в секретных данных, а в том, что их системы могут быть затем использованы в ка- честве подставных звеньев для сокрытия истинного источника атаки на другую систему. Напр., их системы могут быть использованы для DoS-атак. Большинство из упомянутых выше сценариев может быть также выявлено ис- пользованием системы обнаружения атак [intrusion detection system (IDS)]. Её отличие в том, что она обычно используется для обнаружения атак, но не для предотвращения или защиты от них. IDS может сообщить о том, что троянская программа пытается выкрасть данные с машины, но не может блокировать траффик, не будучи для этого предназначенной. Это означает, что IDS не являются заменой персональным фаирволлам. Большинство разработчиков персональных фаирволлов стали включать в них функции генерации отчётов об обнаруженных атаках, анало- гично системам обнаружения атак. Так пользователь снабжается дополнительной информацией о зарегистрированных событиях. Другими дополнительными функциями является фильтрация содержимого, позволяющая пользователю на индивидуальной основе контролировать фаирволлом информацию, сохраняемую в куках, блокировать всплытие рекламных окон или исполнение активного содержимого типа ActiveX в веб-страницах. Наконец, как будет показано в данной работе, другой причиной использова- ния персонального фаирволла может быть применение его в качестве дополнитель- ного источника информации, которая может помочь в получении лучшего представ- ления о состоянии безопасности системы вцелом. Логи обеспечивают информацию, которая может быть использована в процессе коррелирования сигналов тревоги и реакции на атаки. 1.4 Методология Методология данной работы в первую очередь заключается в осмыслении сце- нариев возможных атак, на различных уровнях нацеленных на персональные фаир- воллы. Для этого была построена небольшая сеть, в которой все тестируемые пер- сональные фаирволлы исполнялись параллельно на идентично сконфигурированных машинах. Проведение последовательности атак, обеспечивая обзор их возможнос- тей, позволяло видеть, от каких из них конкретно способен защищать конкретный персональный фаирволл. Логи, сгенерированные в результате, собирались для дальнейшего изучения. В процессе анализа зарегистрированных событий был выведен унифицированный общий для персональных фаирволлов формат лога. Для трансляции отдельных логов в этот унифицированный формат было написано три скрипта на Perl. Сгенерирован- ные логи анализировались для нахождения правил коррелирования этих сигналов тревоги. С целью проверки сделанных выводов был проведён эксперимент в услови- ях работы нескольких персональных фаирволлов в реальной сети. Глава 2 Характеристики персональных фаирволлов В этой главе рассмотрены технические возможности программных продуктов, отобранных для исследования. 2.1 Выбранные программные продукты Большинство систем класса Unix или разновидностей Linux изначально вклю- чает полноценные фаирволлы, имеющие мало общего с персональными фаирволлами для систем класса Windows. По этой причине для тестов были выбраны только пер- сональные фаирволлы для Windows. Персональный фаирволл для не-Windows системы, вероятно, испортил бы общую картину результатов, поскольку устроен как обычный сетевой фаирволл и не имеет некоторых специальных черт, типичных для персо- нальных. Поскольку целью данного исследования было моделирование условий ре- ального пользователя, продукты были выбраны из всего диапазона данного сегмен- та рынка. Отобранные персональные фаирволлы следующие:  Название: Zonealarm Версия: 3.1.395 Разработчик: Zonelabs Сайт: http://www.zonelabs.com Тип: бесплатный Целевые ОС: Win98/ME/NT/2K/XP  Название: Symantec Desktop Firewall Версия: 2.01 Разработчик: Symantec Сайт: http://www.symantec.com Тип: платный Целевые ОС: Win95/98/ME/NT/2K/XP  Название: Sygate Personal Firewall Версия: 5.0.1150 Разработчик: Sygate Сайт: http://soho.sygate.com Тип: бесплатный для личного пользования Целевые ОС: Win95/98/ME/NT/2K/XP Эти продукты были выбраны потому, что представляют собой хороший обзор имеющегося на рынке, ориентированном на небольшие офисы и домашних пользовате- лей. В тех случаях, когда в данной работе какое-либо из названий употреблено без указания версии, подразумевается версия, указанная выше. 2.2 Характеристики персональных фаирволлов В этой части рассмотрены некоторые представляющие интерес характеристики выбранных персональных фаирволлов. Хотя внимание сосредоточено, прежде всего, на функциях регистрирования и формирования правил, играющих основную роль в данной работе, упомянуты также и другие полезные черты. Перечень не претендует на полноту, и такие функции как "горячее обновление" ["live update"] в нём не рассматриваются. 2.2.1 "Zonealarm" Персональный фаирволл "Zonelabs" создаёт две отдельные зоны: "зону Интер- нета" и "зону доверия". Для каждой зоны пользователь может добавить IP-адреса или сети. Обе зоны могут иметь разные настройки безопасности. Степень обеспе- чения безопасности может быть одного из трёх уровней: высокого, среднего и низкого. В настройках управления программами для каждого приложения можно оп- ределить права в зоне Интернета и в зоне доверия. Далее можно определить, дол- жно ли приложение работать как сервер, разрешая ему ждать входящие соединения. Возможные опции: разрешить, блокировать и спрашивать. Функцией, не относящейся к фаирволлам, но представляющей интерес, являет- ся "mailsafe". Это основная защита от вирусов на языке Visual Basic в e-mail. Её суть заключается в перемещении скрипта в безопасное место и предотвращении его автоматического запуска. Достигается это посредством мониторинга траффика e-mail. В качестве дополнительной функции имеется аварийная кнопка, при нажатии переводящая фаирволл в режим "блокировать всё". Она может быть полезной, когда пользователь замечает какое-либо ненормальное поведение системы. Возможность добавления сложных пользовательских правил, которые использо- вали бы опции фильтрации, основанные на номерах портов, отсутствует. Это озна- чает, что каждое приложение, которому разрешено работать с сетью, имеет права на использование всех портов. 2.2.2 "Symantec Desktop Firewall" "Symantec Desktop Firewall" отслеживает два основных направления: безо- пасность и приватность. В "безопасности" пользователь имеет выбор из трёх предопределённых уров- ней: высокий, средний и низкий. Эти три уровня являются значениями внутренних опций. Они делятся на три тематические группы: персональный фаирволл, Java-ап- плеты и ActiveX. Для каждой из этих групп в свою очередь можно выбрать один из трёх уровней защиты. В случае персонального фаирволла это означает следующее: высокий ─ блокировать всё кроме явно разрешённого пользователем; средний ─ блокировать известные агрессивные приложения; нулевой ─ разрешить любой траф- фик. Для двух остальных групп можно выбрать блокировать всё, спрашивать каждый раз и разрешить всё. Дополнительно имеются ещё две опции. Первая включает сигнализацию тревоги иконкой на панели задач, а вторая молча блокирует неиспользуемые порты. Пос- леднее означает, что траффик, направленный в неиспользуемый порт и не удовлет- воряющий какому-либо правилу фильтрации, будет блокирован, как если бы такое правило имелось. Вторая категория ─ "приватность". Ползунок позволяет пользователю задать один из трёх предусмотренных уровней безопасности; высокий, средний и мини- мальный. Таковые касаются внутренних значений блокирования кук (блокировать, спрашивать или разрешать) и блокирования конфиденциальной информации (блокиро- вать, спрашивать или разрешать). "Конфиденциальной" информацией может быть лю- бая, введённая в пользовательское поле, напр., последние 4 цифры номера кре- дитной карты. Если разрешено, персональный фаирволл пытается убедиться, что эта информация не покидает машину. Далее, "Symantec Desktop Firewall" способен блокировать IGMP-траффик и фрагментированные IP-пакеты. Оба варианта часто применяются для атак DoS или Nuke, которые пытаются обрушить систему специально сформированными пакетами. "Symantec Desktop Firewall" предоставляет возможность разрешить автомати- ческое формирование своих правил автонастройщиком. Этот автонастройщик имеет внутреннюю базу данных известных приложений и соответствующих правил по умол- чанию. Если персональный фаирволл замечает новое приложение, которое пытается получить доступ к сети, автонастройщик ищет название в базе данных и проверя- ет, известно ли это приложение. Если это приложение известно, для него автома- тически, без уведомления, создаётся соответствующее правило. Это может вызы- вать проблемы при желании иметь нестандартные правила для стандартных приложе- ний, типа веб-браузеров. В разделе дополнительных опций есть возможность установить дополнительные правила приватности на основе доменного имени. Это позволяет блокировать стро- ки user-agent, куки, referrer и адреса e-mail от передачи сайтам. Соединения могут фильтроваться после установки правил в редакторе правил. Эти правила могут сопоставляться входящим и исходящим пакетам и фильтровать их согласно критериям типа: протокол, название приложения, номера портов или ис- пользуемые IP-адреса. Действиями над фильтруемыми пакетами могут быть: разрешение, блокирова- ние или игнорирование. Последнее означает, что пакет будет зарегистрирован, но не блокирован. В особых случаях может быть выставлен флаг тревоги, отображаемый в иконке системного лотка. 2.2.3 "Sygate Personal Firewall" "Sygate Personal Firewall" предлагает три различных режима работы: "бло- кировать всё", "разрешать всё" и обычный. Блокировать всё означает, что всякая передача входящих и исходящих данных будет прекращена. Разрешить всё означает, что весь траффик к и от охраняемой машины будет разрешён. При этом будет вестись регистрация событий, для которых имеются соответствующие прави- ла. "Обычный" означает, что будут использоваться правила фильтра- ции, установленные пользователем. Имеется таблица приложений, хранящая все данные им права и упорядоченная по названиям приложений. Она имеет следующие поля: FileName: название приложения; Version: номер версии (сборки) приложения; Access: статус доступа, назначенный данному приложению (блокиро- вать, спрашивать, либо разрешать); Path: расположение приложения. Для всех приложений существует возможность создать сложное правило. Эти правила могут фильтровать траффик приложений по дополнительным полям типа IP- адреса или номеров портов. Каждому приложению может быть дано право отправлять или принимать траффик во время режима скринсейвера или заданных отрезков вре- мени. Далее, существует возможность создавать сложные правила для соединений. Каждое правило может задавать фильтрацию пакетов в соответствии с используемым протоколом, IP-адресами, MAC-адресами и номерами портов. Все правила могут быть привязаны ко множеству приложений. Реакцией на фильтруемый пакет может быть его разрешение или блокирование. Правило может действовать только в за- данный отрезок времени или во время режима скринсейвера. Вместо регистрирования в файл фаирволл способен информировать о необычных событиях, отправляя сообщение по e-mail. Это может осуществляться немедленно при поступлении тревоги или через регулярные интервалы времени. "Sygate Personal Firewall" обеспечивает защиту на уровне драйверов. Эта функция блокирует стеки протоколов от доступа к сети, пока пользователь не разрешит его. Если какое-либо приложение вопреки фаирволлу устанавливает собс- твенный стек протокола, оно будет обнаружено. Функция, называемая "аутентификация DLL", отслеживает связь DLL с прило- жениями и отмечает её в собственной таблице. Доступ к сети каких-либо DLL, в ней отсутствующих, блокируется. 2.3 Возможности регистрирования 2.3.1 "Zonealarm" "Zonealarm" обеспечивает возможность регистрирования в файл в plain text в простом формате. Таковое происходит не в реальном времени, поскольку прохо- дит через внутренний буфер, прежде чем он будет сброшен, однако, задержка сос- тавляет менее секунды и ею можно пренебречь. Каждое событие сохраняется в от- дельной строке, содержащей поля, разделённые запятыми. Ниже показан формат и пример фрагмента лога "Zonealarm". ┌─────────────┬─────────────────┬───────────────────────────────────────────┐ │название поля│ пример │ формат содержимого │ ├─────────────┼─────────────────┼───────────────────────────────────────────┤ │Type │FWIN │FWIN|FWOUT|FWLOOP|LOCK|PE|ACCESS|FWROUTE|MS│ │Date │2002/11/26 │YYYY/MM/DD │ │Time │11:38:02 +1 GMT │HH:MM:SS +n GMT │ │Source │192.168.0.66:3244│IP-адрес:порт │ │Destination │192.168.0.10:80 │IP-адрес:порт │ │Transport │TCP(flags:s) │TCP(flags:x)|UDP|ICMP|IGMP|N/A │ └─────────────┴─────────────────┴───────────────────────────────────────────┘ FWIN,2002/11/26,13:21:22 +1:00 GMT,10.10.50.42:63348,10.10.50.2:17978,TCP (fl· ags:S) FWIN,2002/11/26,14:07:22 +1:00 GMT,192.168.0.9:0,10.10.50.2:0,ICMP (type:8/su· btype:0) FWIN,2002/11/26,14:22:00 +1:00 GMT,10.10.50.4:0,10.10.50.2:0,IGMP FWIN,2002/11/25,13:41:36 +1:00 GMT,192.168.0.9:0,10.10.50.2:0,IGMP (type:2/su· btype:31) FWIN,2002/11/26,15:31:46 +1:00 GMT,192.168.0.9:7617,10.10.50.2:42,UDP ACCESS,2002/11/28,14:05:58 +1:00 GMT,,N/A,N/A ACCESS,2002/11/28,14:05:58 +1:00 GMT,flood.exe was temporarily blocked from c· onnecting to the Internet (10.10.50.3).,N/A,N/A PE,2002/11/28,14:09:06 +1:00 GMT,flood.exe,10.10.50.3:0,N/A PE,2002/11/28,10:10:46 +1:00 GMT,Internet Explorer,192.168.0.9:80,N/A FWOUT,2002/11/28,14:09:08 +1:00 GMT,10.10.50.2:96,10.10.50.3:66,TCP (flags:S) FWOUT,2002/11/28,14:09:36 +1:00 GMT,10.10.50.2:0,10.10.50.3:0,IGMP FWOUT,2002/11/25,14:37:40 +1:00 GMT,10.10.50.2:53,10.10.50.2:53,UDP FWROUTE,2002/11/28,14:09:58 +1:00 GMT,0.0.0.0:96,10.10.50.3:66,UDP FWROUTE,2002/11/28,14:11:28 +1:00 GMT,0.0.0.0:0,10.10.50.3:0,ICMP (type:8/sub· type:0) 2.3.2 "Symantec Desktop Firewall" "Symantec Desktop Firewall" регистрирует шесть различных типов событий в отдельные логи, рассмотренные ниже. Внутри данные представлены в 16-ричном ви- де и проприетарном формате. К сожалению, "Symantec" какого-либо описания фор- мата этих файлов не предоставляет. Существует функция экспорта логов в plain text, но часть информации оригинального лога, вчастности, подтип протокола, при этом выбрасывается. Все нижеследующие образцы взяты из логов, экспортиро- ванных в plain text. Шесть различных логов рассмотрены по отдельности в следу- ющих подглавах. Лог блокирования содержимого Хранится в файле iamtdi.log. Этот файл регистрирует информацию о блокиро- ванных апплетах ActiveX или Java. Пользователь имеет возможность задать данную фильтрацию на трёх различных уровнях: низком, среднем и высоком. Эта функция не имеет непосредственного отношения к данной работе, поскольку регистрация событий не содержит информации о попытках вторжения. Поэтому данный лог в дальнейшем не рассматривается. Лог соединений Хранится в файле iamtcp.log. Этот файл регистрирует все входящие и исхо- дящие соединения, включая порты, отметки времени и количество прошедших байт. Особый интерес может представлять последнее, напр., для проверки успешности атаки. Правила фильтрации на это регистрирование не влияют. Ниже показан при- мер лога соединений "Symantec Desktop Firewall". 1/28/2003 18:00:48 Connection: 192.168.0.33: http from 192.168.0.2: 1802, 537· bytes sent, 1380 bytes received, 3:35.268 elapsed time 1/28/2003 18:00:12 Connection: 192.168.0.66: http from 192.168.0.2: radius, 3· 162 bytes sent, 8352 bytes received, 21.451 elapsed time 1/28/2003 17:59:54 Connection: 192.168.0.66: http from 192.168.0.63: radacct,· 503 bytes sent, 221 bytes received, 0.650 elapsed time Лог фаирволла Хранится в файле iamfw.log. Это основной лог. Он регистрирует входящие и исходящие соединения, согласно указаниям в правилах фильтрации. Каждое событие регистрируется на нескольких строках. Как показывают наблюдения, количество строк может варьироваться от трёх до шести. Как видно из таблицы ниже, записи событий не следуют каким-либо строгим правилам форматирования. Это несколько затрудняет его перевод в унифицированный формат логов, описанный в гл. 6. 11/25/2002 14:39:05 Rule "Default Outbound ICMP" permitted (10.10.50.4,systat· ). Details: Outbound ICMP request Local address is (10.10.50.1) Remote address is (10.10.50.4) Message type is "Time Exceeded for a Datagram" Process name is "N/A" 11/26/2002 14:14:30 Blocked inbound IGMP packet. Details: Remote address (10.10.50.4) Local address (10.10.50.1) 11/27/2002 16:39:53 Rule "block all" blocked (10.10.50.1,441). Details: Inbound TCP connection Local address,service is (10.10.50.1,441) Remote address,service is (10.10.50.4,44614) Process name is "N/A" 1/27/2003 14:08:45 Rule "Eudora HTTP" blocked (192.168.0.7,http). Details: Outbound TCP connection Local address,service is (0.0.0.0,2683) Remote address,service is (192.168.0.7,http) Process name is "C:\Program Files\Qualcomm\Eudora\Eudora.exe" 11/26/2002 15:24:28 Rule "block all" blocked (10.10.50.1,nameserver). Details: Inbound UDP packet Local address,service is (10.10.50.1,nameserver) Remote address,service is (192.168.0.2,15897) Process name is "N/A" Лог приватности Хранится в файле iampriv.log. Этот файл регистрирует события, касающиеся приватности, напр., отправки кук или идентификатора user-agent браузера. Пос- кольку эти сведения не относятся непосредственно к вторжениям, этот лог в дальнейшем не рассматривается. Системный лог Хранится в файле iamsys.log. Этот файл регистрирует рабочие сообщения, такие как начало и окончание работы какой-либо службы. В рамках экспериментов данной работы эти сигналы тревоги не рассматриваются, поскольку прямых следст- вий они не имеют. В дальнейшем для полноты исследования может иметь смысл включение и этого лога, т.к. в некоторых сценариях его информация может предс- тавлять интерес. Напр., когда атака деактивировала персональный фаирволл, хотя у атакующего возможности сделать это не ожидалось. Лог веб-истории Хранится в файле iamwebh.log. Подобно файлу истории веб-браузера этот лог регистрирует все посещённые URL-ы со временем и датой. Если только не ставится цель отслеживать людей, посещающих заблокированные веб-страницы, этот лог не представляет интереса для дальнейших экспериментов и потому не рассматривает- ся. 2.3.3 "Sygate Personal Firewall" "Sygate Personal Firewall" регистрирует события в четыре отдельных файла: системный лог, лог безопасности, лог траффика и пакетный лог. Собственно логи хранятся в 16-ричном коде, но имеется функция экспорта в сообщения в plain text из консоли просмотра лога. Кроме них в том же каталоге имеется ещё и отладочный лог под названием debug.log, содержащий информацию такого типа как время запуска фаирволлом GUI или который драйвер и куда был им загружен. Как следует из названия, он служит только отладочным целям и в экспериментах данной работы не используется. Все эти логи могут отображаться в двух различных режимах: "локальный вид" ["local view"] и "исходный вид" ["source view"]. Единственное различие между ними в том, что они выводят два поля "удалённый хост" и "локальный IP" ["remo- te host" & "local IP"] в первом режиме и "хост назначения" и "исходный IP" ["destination host" & "source IP"] в другом. С какой целью была реализована эта функция, понять трудно, т.к. информация остаётся одна и та же. Два поля просто меняются местами. Обычного же конечного пользователя данная опция может скорее лишь смущать и раздражать. Для простоты, во всех проведённых тестах ис- пользовался только режим "исходный вид". Системный лог Хранится в файле syslog.log. Этот файл регистрирует все рабочие измене- ния, такие как начало и окончание работы служб, обнаружение сетевых приложе- ний, изменение конфигурации программ и ошибки исполнения программ. Системный лог важен для поиска неисправностей, но для целей коррелирования бесполезен, и поэтому в рамках данной работы он не рассматривается. Включение этого лога в рассмотрение для полноты исследования может иметь смысл в будущем. В некоторых сценариях эта информация ─ напр., о том, когда была запущена и остановлена ка- кая-либо служба ─ может представлять интерес. Ниже показан пример системного лога "Sygate Personal Firewall". *************** Windows Version info *************** Operating System: Windows 2000 (5.0.2195 Service Pack 2) *************** Network info *************** No.0 "Local Area Connection" 00-04-ac-44-ab-ba "Intel 8255x-based PCI Ethernet Adapter (10/100)" 10.10.50.3 96 01/22/2003 16:00:38 Information 12070202 Start Sygate Personal Firewall... 97 01/22/2003 16:00:38 Information 12070202 Sygate Personal Firewall has been· started. 98 01/22/2003 16:00:38 Information 12070305 Security level has been changed t· o Normal 99 01/22/2003 16:00:54 Information 12070305 New Option Settings is applied 100 01/22/2003 16:01:14 Information 12070305 New Advance rule has been applied 101 01/22/2003 16:01:20 Information 12070204 Stopping Sygate Personal Firewal· l.... 102 01/22/2003 16:01:24 Information 12070204 Sygate Personal Firewall is stop· ped 103 01/22/2003 17:02:08 Information 12070201 Sygate Personal Firewall 5.0.1150 Лог безопасности Хранится в файле seclog.log. Этот файл регистрирует потенциально угрожаю- щие виды активности, направленные к машине, напр., сканирование портов или DoS-атаки. Лог безопасности аналогичен простой консоли IDS, перечисляющей со- бытия, сгенерированные в логе траффика. Ниже показан формат и пример фрагмента лога безопасности "Sygate Personal Firewall". ┌────────────────────────┬───────────────────────────────────────────────────┐ │ название поля │ описание │ ├────────────────────────┼───────────────────────────────────────────────────┤ │Event number │события последовательно пронумерованы │ │Time │дата и время регистрации события │ │Information │сообщение об опасности │ │Severity │степень серьёзности тревоги (Critical, Major, Minor│ │ │или Information) │ │Direction │направление относительно пользователя │ │Protocol │тип протокола (TCP, UDP или ICMP) │ │Destination │IP-адрес атакуемой машины │ │Source │IP-адрес машины, из которой исходит траффик │ │Destination port or ICMP│номер порта получателя или тип пришедшего ICMP-│ │ │траффика │ │Source port or ICMP │номер порта источника или тип отправленного ICMP-│ │ │траффика │ │Count │количество зарегистрированных событий данного типа │ │Application │название затронутого приложения │ │Begin time │время начала попытки атаки │ │End time │время окончания попытки атаки │ └────────────────────────┴───────────────────────────────────────────────────┘ 113 11/28/2002 10:04:56 Executable File Change Denied Major Outgoing TCP 10.1· 0.50.4 0.0.0.0 C:\Program Files\Internet Explorer\IEXPLORE.EXE 1 11/28/2002· 10:04:52 11/28/2002 10:04:52 114 11/28/2002 10:05:19 Executable File Change Accepted Information Outgoing · TCP 10.10.50.4 0.0.0.0 C:\Program Files\Internet Explorer\IEXPLORE.EXE 1 11· /28/2002 10:05:15 11/28/2002 10:05:15 56 11/26/2002 14:02:59 Denial of Service Major Incoming ICMP 192.168.0.8 10.1· 0.50.3 1 11/26/2002 14:02:52 11/26/2002 14:02:52 58 11/26/2002 14:45:34 Denial of Service Major Incoming Unknown 10.10.50.4 10· .10.50.3 7 11/26/2002 14:45:32 11/26/2002 14:45:34 105 11/27/2002 15:55:24 Port Scan Minor Incoming TCP 10.10.50.4 10.10.50.3 6 · 11/27/2002 15:55:18 11/27/2002 15:55:19 Лог траффика Хранится в файле tralog.log. Этот файл регистрирует информацию о всех па- кетах траффика, который входит или покидает порты охраняемой машины. Ниже по- казан формат и пример фрагмента лога траффика "Sygate Personal Firewall". Пер- вое поле времени (время) содержит время появления сигнала тревоги, второе поле времени (время начала) указывает, когда началась зарегистрированная атака, и третье поле времени (время окончания) ─ когда атака закончилась. Это означает, что отметки времени всегда подчиняются закону: время начала =< время окончания =< время. ┌─────────────┬─────────────────────────────────────────────────────────────┐ │название поля│ описание │ ├─────────────┼─────────────────────────────────────────────────────────────┤ │Event number │события последовательно пронумерованы │ │Time │дата и время регистрации события │ │Action │действие, предпринятое фаирволлом (Blocked or Allowed) │ │Protocol │тип протокола, применённого при попытке (TCP, UDP, ICMP или│ │ │неизвестный) │ │Direction │направление относительно пользователя (Incoming or Outgoing) │ │Source │IP-адрес машины, из которой исходит траффик │ │Destination │IP-адрес атакуемой машины │ │Application │название затронутого приложения │ │Count │количество зарегистрированных событий такого типа │ │Begin time │время начала попытки атаки │ │End time │время окончания попытки атаки │ └─────────────┴─────────────────────────────────────────────────────────────┘ 56 11/25/2002 14:22:54 Blocked UDP Incoming 127.0.0.1 53 10.10.50.3 53 2 11/2· 5/2002 14:22:32 11/25/2002 14:22:50 Block_all 57 11/25/2002 14:22:54 Allowed UDP Incoming 10.10.50.4 138 10.10.50.255 138 C· :\WINNT\System32\ntoskrnl.exe 1 11/25/2002 14:22:52 11/25/2002 14:22:52 GUI· %GUICONFIG#SRULE@NBENABLEYOU#ALLOW-UDP 30545 11/26/2002 14:01:10 Blocked ICMP Incoming 192.168.0.9 0 10.10.50.3 8 1 · 11/26/2002 14:00:51 11/26/2002 14:00:51 Block_all 1460410 11/28/2002 14:08:22 0.0.0.0 0 0.0.0.0 0 Outgoing Blocked C:\sygate_DF· W\exploits\flood\flood.exe Пакетный лог Хранится в файле rawlog.log. Этот файл перехватывает каждый пакет данных, входящих или покидающих компьютер. Его можно рассматривать как сетевой сниф- фер, работающий не в неразборчивом [promiscuous] режиме. По умолчанию опция данного регистрирования выключена, поскольку оно может потреблять очень много дискового пространства. К сожалению, будучи экспортированным, пакетный лог содержит не исходные пакеты, а только информацию, которую уже обеспечивает лог траффика, напр., IP- адреса источника и получателя. Для того же, чтобы извлечь содержимое пакетов, придётся написать собственный интерпретатор этого формата, который открыто не документирован. Но даже при обладании информацией пакетов из исходного лога, нам ещё потребуется разработка соответствующих правил для всех возможных слу- чаев атак, поскольку эта информация ─ всего лишь "сырые" данные из пакетов, не прошедшие отсева ни по каким критериям. Для того, чтобы обнаружить среди этих пакетов опасные, потребуется применение к их содержимому различных правил фильтрации. Это вточности та работа, которую уже выполняет IDS. Изобретение колеса не имеет смысла и выходит за рамки настоящей работы. По этой причине и потому, что в экспортированном виде данный лог обеспечивает ту же самую инфор- мацию, что и лог траффика, он, хотя и является одним из лучших источников ин- формации, в данной работе более не рассматривается. Ниже показан формат и пример фрагмента пакетного лога "Sygate Personal Firewall". Как уже было сказано, эти сообщения не содержат собственно пакетов, поскольку полный пакет сохраняется только во внутреннем представлении файла rawlog.log. ┌────────────────┬─────────────────────────────────────────────────────────┐ │ название поля │ описание │ ├────────────────┼─────────────────────────────────────────────────────────┤ │Event number │события последовательно пронумерованы │ │Time │дата и время регистрации события │ │Source │IP-адрес машины, из которой исходит траффик │ │Source port │номер исходящего порта │ │Destination │IP-адрес атакуемой машины │ │Destination port│номер входящего порта │ │Direction │направление относительно пользователя (Incoming or Outgo-│ │ │ing) │ │Action │действие, предпринятое фаирволлом (Blocked or Allowed) │ │Application │название затронутого приложения │ └────────────────┴─────────────────────────────────────────────────────────┘ 1019023 01/22/2003 15:41:01 10.10.50.4 80 10.10.50.3 1038 Outgoing Allowed C:· \WINNT\system32\telnet.exe 1019034 01/22/2003 15:44:00 10.10.50.4 80 10.10.50.3 1040 Incoming Allowed C:· \Program Files\Internet Explorer\IEXPLORE.EXE 1019035 01/22/2003 15:44:07 10.10.50.2 138 10.10.50.255 138 Incoming Blocked · C:\WINNT\System32\ntoskrnl.exe Глава 3 Условия тестирования Эта глава описывает устройство испытательного стенда, использованного для моделирования атак на персональные фаирволлы, выбранные для тестирования, и вводит принятые в эксперименте допущения. 3.1 Цели тестирования В Интернете можно найти некоторое количество сайтов, осуществляющих тес- тирование фаирволлов с ориентацией на персональные [3]. Все встречающиеся тес- ты просто проводят сканирование портов IP-адреса и сообщают об открытых. Таким способом всего лишь выявляются недостатки конфигурирования, но поскольку в данном тестировании принимается предположение, что персональные фаирволлы сконфигурированы правильно и по максимуму их возможностей, этот аспект нас не интересует. Покуда предполагается доступность службы из Интернета, наличие открытых портов само по себе опасности не представляет. В конфигурации по умолчанию все персональные фаирволлы блокируют входящий траффик и по каждому приложению спрашивают пользователя, разрешить его или нет. Поэтому полезность таких тес- тирующих сайтов в проверке надёжности персональных фаирволлов сомнительна. При этом они лишь создают у конечного пользователя впечатление безопасности, воз- можно оставляя другие бреши в ней необнаруженными. Поэтому внимание данной работы сосредоточено на недостатках разработки и брешах в концепциях персональных фаирволлов, которые не могут быть устранены лишь изменением конфигурации. Часть недостатков может быть исправлена разра- ботчиком в последующих версиях, часть же не может быть исправлена вообще, по- тому что связана с задачами, для решения которых персональные фаирволлы не предназначены. Но выявленные и проанализированные, эти лазейки можно избежать или обезопасить другими механизмами. Т.о., внимание сосредоточено на нахожде- нии атак, которые покрывают весь класс возможных сценариев, рассмотренных в гл. 4. Второй задачей процесса тестирования, разумеется, является генерация ло- гов, которые впоследствии могут быть использованы для создания схемы коррели- рования. Для этой цели персональные фаирволлы были сконфигурированы на регист- рирование всей значимой информации. Для облегчения дальнейшего анализа сгене- рированные логи с помощью небольшого пакетного скрипта перемещались в отдель- ный для каждой атаки каталог. 3.2 Допущения Внимание данной работы сосредоточено на концепции персональных фаирвол- лов, поэтому вопросы, связанные со слабостями операционных систем или атаками, возможными исключительно благодаря недостаткам в конфигурации фаирволлов, не рассматриваются. Поэтому принимается допущение, что нижележащая операционная система пол- ностью пропатчена всеми необходимыми обновлениям и работает стабильно. Прини- мается, что персональные фаирволлы работают с разумным набором правил, обеспе- чивающим максимально достижимую безопасность. С этой целью конфигурация по умолчанию каждого фаирволла была адаптирована согласно его возможностям. Бло- кировался весь исходящий траффик, кроме относящегося к "Internet Explorer", которому был разрешён доступ к TCP-портам 80, 8080 и 443, представляющим собой стандартный порт веб-сервера, дополнительный порт веб-сервера и порт SSL-сое- динения. Входящие соединения принимались только для сервера Telnet на TCP-пор- ту 21. Данная конфигурация была выбрана для моделирования условий реальной эк- сплуатации без блокирования всего траффика по умолчанию, поскольку простое блокирование всего траффика практического смысла не имеет. Процесс ведения ло- гов был настроен с максимально возможной детализацией, так чтобы никакой ин- формации на этом этапе не терялось. 3.3 Испытательный стенд Для тестирования была составлена небольшая сеть из четырёх машин. Все яв- ляются десктопами "IBM PL300" с процессорами "Pentium II" 350 МГц и 128 Мб ОЗУ. Три машины имеют идентично проинсталлированную "Windows 2000" и "Service Pack 2". На каждой системе проинсталлирован соответствующий тестируемый персо- нальный фаирволл. Четвёртая машина использовалась как атакующая и имеет двой- ную систему загрузки "Windows 2000" с "Service Pack 2" и "RedHat Linux 8.0". Все машины соединены изолированной 100-Мбитной сетью через "Netgear Hub". На всех системах Windows были созданы логины администратора и ограниченного поль- зователя. Глава 4 Атаки В этой главе подробно рассмотрены сценарии используемых атак и ущерб, ко- торый они могут вызвать. 4.1 Описание использованных атак Поскольку идея этой работы заключается в проверке сильных и слабых мест персональных фаирволлов, а не операционных систем, атаки были направлены на собственно фаирволлы. Набор атак включает много приёмов, подразумевающих для своей работы изме- нения на локальной машине. Оправдать такое допущение можно, представив его ре- ализацию в виде вируса или трояна, которые были запущены на машине-жертве и теперь готовы произвести желаемые изменения. Поскольку типичные антивирусные средства ведут поиск, основываясь на сигнатурах, очевидно, что новое малварное приложение ими обнаружено не будет. Из этого следует, что мысль о наличии ка- кой-либо малвари, функционирующей в машине незаметно, ─ отнюдь не надуманная. Поэтому, предположение о том, что в локальной системе имели место изменения в целях какой-либо атаки, отнюдь не абсурдно. Средства осуществления всех опробованных атак, за исключением программи- ровавшихся автором самостоятельно, могут быть свободно найдены в Интернете. В данную работу они не включены, поскольку публикация исходного кода или подроб- ного описания работающих эксплойтов противоречит швейцарским государственным законам. Было решено не включать и описания этих средств, поскольку данная ра- бота не об инструментах проведения атак как таковых, а преимущественно призва- на проиллюстрировать проблему, показав их возможность. Компетентный же техни- чески читатель может повторить тесты самостоятельно, взяв аналогичные средства или написав их сам. Рисунок ниже показывает граф проделанных атак, из которого были выведены различные сценарии. ┌АТАКА╥─┬>┌Локальная╥─┬>┌Атака на доверяемое──╥─┬─>┌Злоупотребление────────╖ │ ║░│ │ ║░│ │приложение ║░│ │доверяемым приложением ║░ ╘═════╝░│ ╘═════════╝░│ ╘═════════════════════╝░│ ╘═══════════════════════╝░ ░░░░░░░│ ░░░░░░░░░░░│ ░░░░░░░░░░░░░░░░░░░░░░░│ ░░░░░░░░░░░░░░░░░░░░░░░░░ │ │ ├─>┌Внедрение памяти───────╖ │ │ │ │ ║░ │ │ │┌>╘═══════════════════════╝░ │ │ ││ ░░░░░░░░░░░░░░░░░░░░░░░░░ │ │ ├─>┌Изменение набора правил╖ │ │ ││ │ ║░ │ │ │├>╘═══════════════════════╝░ │ │ ││ ░░░░░░░░░░░░░░░░░░░░░░░░░ │ └>┌Атака на персональный╥─│┼>┌Нажатие кнопки "да"────╖ │ │фаирволл ║░││ │ ║░ │ ╘═════════════════════╝░││ ╘═══════════════════════╝░ │ ░░░░░░░░░░░░░░░░░░░░░░░││ ░░░░░░░░░░░░░░░░░░░░░░░░░ │ └─>┌Туннелирование─────────╖ │ │ │ ║░ │ │ ╘═══════════════════════╝░ │ │ ░░░░░░░░░░░░░░░░░░░░░░░░░ └>┌Удалённая╥─┬>┌Атака на персональный╥─┬─>┌Фиктивный траффик──────╖ │ ║░│ │фаирволл ║░││ │ ║░ ╘═════════╝░│ ╘═════════════════════╝░││ ╘═══════════════════════╝░ ░░░░░░░░░░░│ ░░░░░░░░░░░░░░░░░░░░░░░││ ░░░░░░░░░░░░░░░░░░░░░░░░░ │ │├>┌Перехват───────────────╖ │ ││ │ ║░ │ ││ ╘═══════════════════════╝░ │ ││ ░░░░░░░░░░░░░░░░░░░░░░░░░ │ │├>┌Невидимость────────────╖ │ ││ │ ║░ │ ││ ╘═══════════════════════╝░ │ ││ ░░░░░░░░░░░░░░░░░░░░░░░░░ │ │├>┌Исчерпание ресурсов────╖ │ ││ │ ║░ │ ││ ╘═══════════════════════╝░ │ ││ ░░░░░░░░░░░░░░░░░░░░░░░░░ │ │├>┌Терминация процесса────╖ │ ││ │ ║░ │ ││ ╘═══════════════════════╝░ │ ││ ░░░░░░░░░░░░░░░░░░░░░░░░░ │ │├>┌Блокирование мьютекса──╖ │ ││ │ ║░ │ ││ ╘═══════════════════════╝░ │ ││ ░░░░░░░░░░░░░░░░░░░░░░░░░ │ ├─>┌Затопление─────────────╖ │ ││ │ ║░ │ │├>╘═══════════════════════╝░ │ ││ ░░░░░░░░░░░░░░░░░░░░░░░░░ │ │└>┌Изменение лога─────────╖ │ │ │ ║░ │ │ ╘═══════════════════════╝░ │ │ ░░░░░░░░░░░░░░░░░░░░░░░░░ │ └─>┌Затопление сигналами───╖ │ │тревоги ║░ │ ╘═══════════════════════╝░ │ ░░░░░░░░░░░░░░░░░░░░░░░░░ └>┌Сбор информации──────╥───>┌Сканирование портов────╖ │ ║░ │ ║░ ╘═════════════════════╝░ ╘═══════════════════════╝░ ░░░░░░░░░░░░░░░░░░░░░░░ ░░░░░░░░░░░░░░░░░░░░░░░░░ ┌Злоупотребление────────╥─┬>┌Кража прав приложения╥─┬>┌Прохождение некоторых╖ │доверяемым приложением ║░│ │ ║░│ │фильтров ║░ ╘═══════════════════════╝░│ ╘═════════════════════╝░│ ╘═════════════════════╝░ ░░░░░░░░░░░░░░░░░░░░░░░░░│ ░░░░░░░░░░░░░░░░░░░░░░░│ ░░░░░░░░░░░░░░░░░░░░░░░ ┌Внедрение памяти───────╥─┘ │ │ ║░ │ ╘═══════════════════════╝░ │ ░░░░░░░░░░░░░░░░░░░░░░░░░ │ ┌Изменение набора правил╥─┬>┌Добавление пользова-─╥─┤ │ ║░│ │тельского правила ║░│ ╘═══════════════════════╝░│ ╘═════════════════════╝░│ ░░░░░░░░░░░░░░░░░░░░░░░░░│ ░░░░░░░░░░░░░░░░░░░░░░░│ ┌Нажатие кнопки "да"────╥─┘ │ │ ║░ │ ╘═══════════════════════╝░ │ ░░░░░░░░░░░░░░░░░░░░░░░░░ │ ┌Туннелирование─────────╥─┐ │ │ ║░│ │ ╘═══════════════════════╝░│ │ ░░░░░░░░░░░░░░░░░░░░░░░░░│ │ ┌Фиктивный траффик──────╥──>┌Права доверяемого────╥─┘ │ ║░│ │источника ║░ ╘═══════════════════════╝░│ ╘═════════════════════╝░ ░░░░░░░░░░░░░░░░░░░░░░░░░│ ░░░░░░░░░░░░░░░░░░░░░░░ ┌Перехват───────────────╥─┤ │ ║░│ ╘═══════════════════════╝░│ ░░░░░░░░░░░░░░░░░░░░░░░░░│ ┌Невидимость────────────╥─┴>┌Обход фильтрующего───╥─┬>┌Избежание фильтрации─╖ │ ║░ │движка ║░│ │ ║░ ╘═══════════════════════╝░ ╘═════════════════════╝░│ ╘═════════════════════╝░ ░░░░░░░░░░░░░░░░░░░░░░░░░ ░░░░░░░░░░░░░░░░░░░░░░░│ ░░░░░░░░░░░░░░░░░░░░░░░ ┌Исчерпание ресурсов────╥─┐ │ │ ║░│ │ ╘═══════════════════════╝░│ │ ░░░░░░░░░░░░░░░░░░░░░░░░░│ │ ┌Терминация процесса────╥─┼>┌Выключение персональ-╥─┘ │ ║░│ │ного фаирволла ║░ ╘═══════════════════════╝░│ ╘═════════════════════╝░ ░░░░░░░░░░░░░░░░░░░░░░░░░│ ░░░░░░░░░░░░░░░░░░░░░░░ ┌Блокирование мьютекса──╥─┤ │ ║░│ ╘═══════════════════════╝░│ ░░░░░░░░░░░░░░░░░░░░░░░░░│ ┌Затопление─────────────╥─┘ ┌Потеря информации────╥──>┌Утечка информации────╖ │ ║░ │ ║░ │ ║░ ╘═══════════════════════╝─┬>╘═════════════════════╝░ ╘═════════════════════╝░ ░░░░░░░░░░░░░░░░░░░░░░░░░│ ░░░░░░░░░░░░░░░░░░░░░░░ ░░░░░░░░░░░░░░░░░░░░░░░ ┌Изменение лога─────────╥─┤ │ ║░│ ╘═══════════════════════╝░│ ░░░░░░░░░░░░░░░░░░░░░░░░░│ ┌Затопление сигналами───╥─┤ │тревоги ║░│ ╘═══════════════════════╝░│ ░░░░░░░░░░░░░░░░░░░░░░░░░│ ┌Сканирование портов────╥─┘ │ ║░ ╘═══════════════════════╝░ ░░░░░░░░░░░░░░░░░░░░░░░░░ Далее рассмотрены различные категории атак, использованных при тестирова- нии персональных фаирволлов. Здесь объясняются лежащие в основе атак идеи, а также ущерб, который они могут вызывать. 4.1.1 Терминация процесса Описание: Попытка остановить работу персонального фаирволла локально. Требуемый доступ: Локальный. Суть: Остановка исполнения персонального фаирволла. Ущерб: Прекращение работы персонального фаирволла. Цель: Преодоление входящей и исходящей фильтрации. Варианты: Отправка терминирующего сообщения от администратора или обычного пользователя. 4.1.2 Внедрение в память 1 Описание: Внедрение процесса в пространство памяти персонального фаир- волла. Требуемый доступ: Локальный. Суть: Попытка стать частью процесса фаирволла. Ущерб: Использование прав доступа фаирволла. Цель: Преодоление входящей и исходящей фильтрации. Варианты: Загрузка DLL в это пространство памяти, затем выделение этой памяти под функцию, вызываемую из рабочей памяти фаирволла. 4.1.3 Сбор информации Описание: Сканирование портов с целью сбора информации об охраняемой системе. Требуемый доступ: Удалённый. Суть: Сбор как можно большей информации о системе для последующих атак. Ущерб: Утечка информации. Цель: Возможная последующая специфическая атака. Варианты: Использование специальных приёмов скрытого сканирования, ти- па сканирования XMAS. 4.1.4 Внедрение в память 2 Описание: Внедрение процесса в пространство памяти доверяемого прило- жения. Требуемый доступ: Локальный. Суть: Попытка стать частью доверяемого приложения. Ущерб: К траффику будет применена фильтрация доверяемого приложе- ния. Цель: Преодоление входящей и исходящей фильтрации. Варианты: Загрузка DLL в это пространство памяти, затем выделение этой памяти под функцию, вызываемую из рабочей памяти приложения. 4.1.5 Кнопка "дополнительно" Описание: Попытка перехватить отсылаемую информацию в момент, когда пользователь нажимает кнопку "дополнительно" ["more info"] и перенаправляется на страницу производителя. Требуемый доступ: Удалённый. Суть: Некоторые персональные фаирволлы отсылают номер версии и IP- адреса сайту для получения дополнительной информации. Ущерб: Утечка информации. Цель: Возможная последующая специфическая атака. 4.1.6 Входящее затопление Описание: Отсылка персональному фаирволлу огромного объёма траффика. Требуемый доступ: Удалённый. Суть: Загрузка всех ресурсов для временного или полного выключения фаирволла. Ущерб: Прекращение работы персонального фаирволла. Цель: Преодоление входящей и исходящей фильтрации. Варианты: Применение для затопления различных протоколов типа TCP, UDP, ICMP или IGMP. Применение специально изготовленных па- кетов типа SYN или FYN. Варьирование загрузки траффика. При- менение фиктивных случайных исходящих адресов. Применение в пакетах одинаковых адресов источника и получателя. 4.1.7 Исходящее затопление Описание: Отсылка огромного объёма траффика с машины, на которой рабо- тает персональный фаирволл. Требуемый доступ: Локальный. Суть: Загрузка всех ресурсов для временного или полного выключения фаирволла. Ущерб: Прекращение работы персонального фаирволла. Цель: Преодоление входящей и исходящей фильтрации. Варианты: Применение для затопления различных протоколов типа TCP, UDP, ICMP или IGMP. Применение специально изготовленных па- кетов типа SYN или FYN. Варьирование загрузки траффика. При- менение случайных исходящих IP-адресов и фиктивных случай- ных исходящих IP-адресов. Применение в пакетах одинаковых адресов источника и получателя. 4.1.8 Фиктивные пакеты Описание: Отсылка специальных пакетов с 127.0.0.1 в качестве исходяще- го IP-адреса. Требуемый доступ: Удалённый. Суть: Претензия на траффик, исходящий из доверяемого устройства обратной петли. Ущерб: К траффику будет применена фильтрация доверяемого источника. Цель: Преодоление входящей фильтрации. Варианты: Применение различных протоколов типа TCP, UDP, ICMP или IGMP. Применение специально изготовленных пакетов типа SYN или FYN. 4.1.9 Подмена двоичного кода Описание: Подмена доверяемого приложения инструментом агрессии с таким же именем и путём. Требуемый доступ: Локальный. Суть: Имитация доверяемого приложения. Ущерб: К траффику будет применена фильтрация доверяемого приложе- ния. Цель: Преодоление входящей и исходящей фильтрации. Варианты: Замена значения хеша доверяемого приложения, хранимого пер- сональным фаирволлом для обнаружения подмены. 4.1.10 Перехват Описание: Использование пакетного сниффера для перехвата траффика пе- ред тем, как он будет отсеян персональным фаирволлом. Требуемый доступ: Локальный. Суть: Получение траффика до того, как он будет заблокирован. Ущерб: К траффику фильтрация применена не будет. Цель: Преодоление входящей фильтрации. Варианты: Использование различных видов сетевых снифферов. 4.1.11 Блокирование мьютекса Описание: Блокирование мьютекса персонального фаирволла. Требуемый доступ: Локальный. Суть: Предотвращение загрузки персонального фаирволла. Ущерб: Прекращение работы персонального фаирволла. Цель: Преодоление входящей и исходящей фильтрации. 4.1.12 Туннелирование Описание: Применение разрешённых протоколов передачи для скрытия ре- ального траффика в новых пакетах. Требуемый доступ: Локальный. Суть: Перепаковка траффика в другой протокол и использование соот- ветствующих портов для его отправки и получения. Ущерб: К траффику будет применена фильтрация доверяемого приложе- ния. Цель: Преодоление входящей и исходящей фильтрации. Варианты: Применение для скрытия пакетов различных протоколов, напр., HTTP, SMTP или ICMP. 4.1.13 Подмена стека IP Описание: Использование другого стека IP для отправки и получения па- кетов. Требуемый доступ: Локальный. Суть: Персональный фаирволл не видит траффик. Ущерб: К траффику фильтрация применена не будет. Цель: Преодоление входящей и исходящей фильтрации. Варианты: Инсталляция нового сетевого драйвера. Инсталляция поставщика многоуровневых служб для отсылки траффика. 4.1.14 Невидимость Описание: Обеспечение невидимости процесса для персонального фаирвол- ла. Требуемый доступ: Локальный. Суть: Применение патча ядра для скрытия приложения от вызовов API. Ущерб: К траффику фильтрация применена не будет. Цель: Преодоление исходящей фильтрации. Варианты: Использование различных руткитов для систем Windows. 4.1.15 Исчерпание ресурсов Описание: Потребление всех доступных ресурсов охраняемой машины. Требуемый доступ: Локальный. Суть: Потребление всех доступных ресурсов с целью вероятного краха персонального фаирволла или, по крайней мере, прекращения его работы. Ущерб: Прекращение работы персонального фаирволла. Цель: Преодоление входящей и исходящей фильтрации. Варианты: Обращение к различных ресурсам типа процессорного времени или памяти. 4.1.16 Изменение лога Описание: Изменение лога персонального фаирволла. Требуемый доступ: Локальный. Суть: Удаление следов после успешной атаки. Ущерб: Поддельные логи событий. Цель: Дезинформация. Варианты: Добавление сигналов тревоги об атаке, не имевшей места. Уда- ление всего лога. 4.1.17 Изменение набора правил Описание: Изменение набора правил персонального фаирволла. Требуемый доступ: Локальный. Суть: Редактирование набора правил для разрешения любого траффика. Ущерб: Добавление пользовательского правила. Цель: Преодоление входящей и исходящей фильтрации. Варианты: Добавление новых специальных правил или редактирование су- ществующих. 4.1.18 Нажатие кнопки "да" Описание: Внедрение приложения, автоматически нажимающего в автонаст- ройщике правил кнопку "да" при создании нового правила. Требуемый доступ: Локальный. Суть: Автоматическое создание правила для инструмента агрессии. Ущерб: Добавление пользовательского правила. Цель: Преодоление входящей и исходящей фильтрации. Варианты: Использование автонастройщика для создания всеразрешающего правила. 4.1.19 Затопление сигналами тревоги Описание: Попытка затопить персональный фаирволл сигналами тревоги. Требуемый доступ: Удалённый. Суть: Чрезмерное количество сигналов тревоги может вызвать переза- пись старых сигналов тревоги в логе. Ущерб: Потеря информации. Цель: Незамеченная атака. Варианты: Применение различных размеров логов. 4.1.20 Манипуляция доверяемым приложением Описание: Удалённое управление доверяемым приложением, имеющим связь с сетью. Применение COM-объектов для открытия скрытого окна браузера. Доступ с него на специальную веб-страницу для об- мена информацией. Требуемый доступ: Локальный. Суть: Претензия на доверяемое приложение. Ущерб: К траффику будет применена фильтрация доверяемого приложе- ния. Цель: Преодоление входящей и исходящей фильтрации. Глава 5 Результаты В этой главе представлены результаты, полученные в процессе тестирования персональных фаирволлов, и рассматриваются выявленные проблемы их разработки. 5.1 Результаты атак 5.1.1 Терминация процесса Описание атаки: В качестве ограниченного пользователя, попытаться терминировать процесс исполнения персонального фаирволла. В случае успеха, работа фаирволла и его функций будет прекращена, что обеспечит неограниченный доступ в Интернет. В случае неуспеха, попытаться проделать то же самое с правами администратора. Использованное средство: "Process Xplorer" от "Sysinternals" [11]. "Zonealarm": Выбор процесса Zonealarm.exe и отправка терминирующего сообщения заверша- ет процессы фаирволла, включая службу "TrueVector" VSmon.exe, осуществляющую фильтрацию. При этом во время эксперимента "TrueVector" завершалась не всегда корректно. Поэтому лучшим подходом представляется отдельно терминировать сна- чала VSmon.exe и затем Zonealarm.exe. "Zonealarm" заметит, что служба "True- Vector" больше не исполняется, и спросит пользователя, следует ли её переза- пустить, но если "Zonealarm" также терминирован, этого уже не произойдёт. Когда фаирволл находится в режиме "блокировать всё", называемом также "аварийным", после терминации процесса дальнейшая связь по сети остаётся не- возможной. По-видимому, в этом случае некий драйвер нижнего уровня внедряется в сетевой стек, прекращая все соединения. Терминация процесса драйвер не уда- ляет, поскольку собственно процессом, блокирующим траффик, он не является. Же- лательно выяснить, что именно инсталлируется процессом, чтобы определить, мо- жет ли атакующий удалить и его. "Symantec Desktop Firewall": Ограниченный пользователь имеет возможность терминировать процесс IAMAPP. EXE. К сожалению, это лишь убирает иконку в системном лотке. Исследование про- цесса загрузки обнаруживает, что первичный процесс запускает другую утилиту NISSERV.EXE. Этот процесс собственно и ответствен за фильтрацию траффика. Поэ- тому терминация его и есть то, что нужно. В результате эксперимента выясни- лось, что ограниченный пользователь терминировать его возможности не имеет, однако, в результате попытки этого он переходит в состояние, при котором не отвечает и никакой дальнейшей фильтрации не осуществляет. С правами админист- ратора терминация процесса фаирволла не составляет никакой проблемы. Если этот вариант не рассматривается, возникает идея удалить запись реес- тра: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run : IAMAPP запретив тем самым автозагрузку фаирволла. При следующей перезагрузке системы фаирволл запущен не будет. "Sygate Personal Firewall": Даже у администратора не существует возможности терминировать процесс фаирволла SCM.EXE непосредственно. Он включает несколько потоков, которые пос- тоянно проверяют терминирующие сообщения и пытаются блокировать их или переза- пустить службу. Это хорошая идея. Однако, хотя терминировать процесс непосредственно невозможно, это можно сделать косвенно. В списке открытых хендлов процесса фаирволла, можно видеть т.н. "\Default" типа "Desktop". Если этот хендл закрыть, вскоре появится сооб- щение "Dr. Watson" о том, что процесс SMC.EXE сгенерировал ошибку и будет ос- тановлен. Даже если не нажимать кнопку "OK" этого сообщения, через 15 с (при холостой работе), процесс будет завершён и система останется незащищённой. Су- ществует возможность установить пароль на запуск и остановку службы фаирволла, но это не помешает описанной выше атаке, поскольку запрос пароля при этом не выводится. Общие выводы В случаях всех трёх протестированных продуктов возможность терминации процесса фаирволла существует. Она может быть произведена компьютерным виру- сом или троянской программой, открывая после завершения фаирволла полный дос- туп к Интернету. Разумеется, разработать процесс, который было бы невозможно терминировать инструментом диверсии, запущенным пользователем, непросто, пос- кольку одно из требований, предъявляемых к персональному фаирволлу, ─ это воз- можность его отключения пользователем при необходимости. Следствием этого ста- новится то, что теоретически атакующий может использовать конфигурирующую ути- литу персонального фаирволла и удалить все нежелательные функции, окончив при- ложением, завершающим процесс фаирволла. Поэтому надёжный способ обеспечить невозможность остановки процесса фаирволла неизвестен, если только не отказать в праве включать и выключать фаирволл нормальному пользователю. Противодействие "Sygate Personal Firewall" стоит на правильном пути, но нуждается в даль- нейшем улучшении с тем, чтобы сделать завершение исполнения фаирволла невоз- можным, по крайней мере, для обычного ограниченного пользователя. 5.1.2 Внедрение в память Описание атаки: Загрузить инструмент агрессии в пространство памяти доверяемого приложе- ния через выделение памяти для некоей функции в его рабочей области и запус- тить в ней поток. Использованное средство: "BackStealth" К сожалению, имеющаяся версия "BackStealth" несовместима с фаирволлами, участвовавшими в данном тестировании, т.к. была разработана для версий более ранних. Поскольку время, выделенное на данную работу, было ограничено, запрог- раммировать собственное внедрение памяти для трёх фаирволлов не представлялось возможным. Как следствие, тестирование с данным средством не проводилось. Согласно доступной информации, внедрение кода в доверяемое приложение предположительно осуществимо. В Интернете имеются обобщённые примеры кода для данной цели на различных языках программирования. Напр., исходный код для внедрения собственных функций в приложение можно найти на сайте "MADshi" [15]. Исследования показали, что подобные приёмы уже используются для обхода персо- нальных фаирволлов в некоторых троянах типа "Assasin". 5.1.3 Затопление SYN 1, всё случайное Описание атаки: Затопить целевую машину TCP-пакетами, имеющими выставленный флаг SYN. Па- кеты изготовлены со случайным IP-адресом источника, случайными портами источ- ника и случайными портами получателя. Использованное средство: "HGOD_flood.exe" "Zonealarm": Сообщает о каждом пакете как об отдельном событии. Специального сообщения не генерируется. DoS-эффекта не возникает. "Symantec Desktop Firewall": Сообщает о каждом пакете как об отдельном событии. Специального сообщения не генерируется. DoS-эффекта не возникает. "Sygate Personal Firewall": Сообщает о каждом пакете как об отдельном событии. Специального сообщения не генерируется. В течение атаки загрузка CPU возрастает до 100%. Общие выводы Атаки данного типа не могут быть сведены к одному сообщению о событии, поскольку события различаются. Каждый пакет имеет различный IP-адрес источника и не может быть выделен из общего траффика. Тем не менее, DoS-эффекта не воз- никает. Противодействие Удостовериться в отсутствии DoS-эффекта наблюдением за загрузкой памяти и CPU. Возможно также блокирование пакетов на нижележащем уровне. SYN-затопления должны распознаваться и сообщаться как тревожное событие. 5.1.4 Затопление SYN 2, случайные порты Описание атаки: Затопить целевую машину TCP-пакетами, имеющими выставленный флаг SYN. Па- кеты изготовлены с постоянным IP-адресом источника, случайными портами источ- ника и случайными портами получателя. Использованное средство: "HGOD_flood.exe" "Zonealarm": Сообщает о каждом пакете как об отдельном событии. Специального сообщения не генерируется. DoS-эффекта не возникает. "Symantec Desktop Firewall": Сообщает о каждом пакете как об отдельном событии. Специального сообщения не генерируется. DoS-эффекта не возникает. "Sygate Personal Firewall": Сообщает о каждом пакете как об отдельном событии. В системном логе нес- колько раз регистрируется сканирование портов с одного IP-адреса. DoS-эффекта не возникает. Общие выводы Данная атака должна выявляться как сканирование портов или DoS-атака. Каждый из вариантов близок к истине, равно как и оба вместе. Поэтому сообщение о ней как о сканировании портов ошибкой не является, поскольку для персональ- ного фаирволла она выглядит как таковое. Противодействие Предпринимать что-либо против данного вида атак нет необходимости, пос- кольку траффик успешно блокируется фаирволлом. Атакующий никакой реакции не наблюдает. 5.1.5 Затопление SYN 3, статическое Описание атаки: Затопить целевую машину TCP-пакетами, имеющими выставленный флаг SYN. Па- кеты изготовлены с постоянным IP-адресом источника, постоянным портом источни- ка и постоянным портом получателя. Использованное средство: "HGOD_flood.exe" "Zonealarm": Сообщает обо всех пакетах в сообщении об одном событии с увеличивающимся счётчиком. Итоговый счёт очень маленький, т.е. некоторое количество пакетов теряется. Специального сообщения о событии не генерируется. DoS-эффекта не возникает. "Symantec Desktop Firewall": Сообщает о каждом пакете как об отдельном событии. Итоговый счёт очень маленький, т.е. некоторое количество пакетов теряется. Специального сообщения о событии не генерируется. DoS-эффекта не возникает. "Sygate Personal Firewall": Сообщает обо всех пакетах в сообщении об одном событии с увеличивающимся счётчиком. По мере продолжения атаки, через неопределённый промежуток времени выводится сообщение о новом событии. Специального сообщения о событии не гене- рируется. DoS-эффекта не возникает. По-видимому, в процессе атаки некоторые пакеты были потеряны. Общие выводы Данная атака должна выявляться как DoS-атака. Разумеется, как указано в разделе 5.1.4, она также может быть сканированием портов, но после обнаружения нескольких идентичных пакетов, постоянно идущих с одного порта источника в один порт получателя, сканирование портов может быть исключено. Подобное пове- дение не имеет смысла для сканирования портов, но обычно для DoS-атак. Противодействие Предпринимать что-либо против данного вида атак нет необходимости, пос- кольку траффик успешно блокируется фаирволлом. Атакующий никакой реакции не наблюдает. Однако, желательно, чтобы об атаке сообщалось специальным сообщени- ем о DoS-атаке. 5.1.6 Затопление SYN 4, тяжёлое Описание атаки: Затопить целевую машину TCP-пакетами, имеющими выставленный флаг SYN. Па- кеты изготовлены со случайными IP-адресами источника, случайными портами ис- точника и случайными портами получателя. Полученная загрузка сети составила ок. 300 Кб/с, что для тестовой сети очень много. Использованное средство: "HGOD_flood.exe" "Zonealarm": Через короткое время загрузка CPU достигла 100% и оставалась таковой до окончания атаки. Нажатие кнопки "блокировать всё" от такого вида DoS-атак не спасает. "Symantec Desktop Firewall": Через короткое время загрузка CPU достигла 100% и оставалась таковой до окончания атаки. "Sygate Personal Firewall": Через короткое время загрузка CPU достигла 100% и оставалась таковой до окончания атаки. Нажатие кнопки "блокировать всё" от такого вида DoS-атак не спасает. После атаки фаирволлу потребовалось более 60 с для возвращения в ис- ходное состояние. При проведении теста после атаки длительностью 15 с фаирволл в течение 80 с всё ещё потреблял 100% времени CPU. После атаки длительностью 30 с, фаирволлу для восстановления потребовалось 100 с. Общие выводы Против всех трёх фаирволлов удалённая DoS-атака оказалась действенной. Это делает возможным временное блокирование охраняемой целевой машины. Противодействие Возможности для DoS-атак быть не должно. Пакеты должны отбрасываться со стека как можно раньше. Справиться с этой задачей непросто, поскольку по дос- тижении загрузкой сети некоторой точки способность корректно отрабатывать все пакеты потеряет принимающая сетевая плата. Подобный эффект может возникать и без фаирволла. Тем не менее, фаирволл должен защищать от таких атак. 5.1.7 Затопление ICMP Описание атаки: Затопить целевую машину ICMP-пакетами, тип echo request, с фиктивными IP-адресами. Использованное средство: "HGOD_flood.exe" "Zonealarm": Сообщает о каждом пакете как об отдельном событии. Специального сообщения не генерируется. "Symantec Desktop Firewall": Сообщает о каждом пакете как об отдельном событии. Специального сообщения не генерируется. "Sygate Personal Firewall": Сообщает о каждом пакете как об отдельном событии. В системном логе ре- гистрируется DoS-атака по протоколу ICMP. Несмотря на фиктивные адреса источ- ника, фаирволл сообщает только несколько исходящих IP-адресов. Общие выводы Атаки данного типа не могут быть сведены к одному сообщению о событии, поскольку события различаются. Каждый пакет имеет различный IP-адрес источника и не может быть выделен из общего траффика. Противодействие Не требуется. 5.1.8 Затопление IGMP 1 Описание атаки: Затопить целевую машину IGMP-пакетами. Размер пакета установлен в 1480 байт, т.е. без фрагментации. Фиктивные исходящие IP-адреса не применялись. Использованное средство: "HGOD_flood.exe" "Zonealarm": Сообщает обо всех пакетах в сообщении об одном событии с увеличивающимся счётчиком. DoS-эффекта не возникает. "Symantec Desktop Firewall": Сообщает о каждом пакете как об отдельном событии. DoS-эффекта не возни- кает. Фаирволл имеет опцию блокирования траффика IGMP, но какой-либо разницы при включении данной опции не наблюдалось. Возможно, данная функция блокирует не весь траффик IGMP, а только некорректно выполненные пакеты, используемые в атаке "kiss of death" [20]. "Sygate Personal Firewall": Фаирволл не поддерживает протокол IGMP. Поэтому он не видит никаких паке- тов и не сообщает ни о каких событиях. Во время атаки загрузка времени CPU составляла 100%. После окончания атаки она вернулась к нормальной. Если вклю- чен лог "сырых" пакетов, то пакеты в нём сохраняются, но никаких сообщений о них в логе траффика не остаётся. Общие выводы Все персональные фаирволлы должны уметь видеть и регистрировать траффик IGMP. DoS-эффекта возникать не должно. Противодействие Реализовать в персональном фаирволле фильтр IGMP. 5.1.9 Затопление IGMP 2 Описание атаки: Затопить целевую машину IGMP-пакетами. Размер пакета был сначала установ- лен в 1481 байт, а затем в 65 000 байт для получения множественных фрагменти- рованных пакетов. Фиктивные исходящие IP-адреса не применялись. Использованное средство: "HGOD_flood.exe" "Zonealarm": Сообщает обо всех пакетах в сообщении об одном событии с увеличивающимся счётчиком. DoS-эффекта не возникает. "Symantec Desktop Firewall": Сообщает о каждом пакете как об отдельном событии. DoS-эффекта не возни- кает. "Sygate Personal Firewall": За короткое время загрузка CPU достигает 100%. В системном логе регистри- руется DoS-атака по неизвестному протоколу. Если посмотреть лог "сырых" паке- тов, можно увидеть, что половина пакетов блокирована, а половина разрешена. Причина в том, что загрузка в 1481 байт порождает два фрагментированных паке- та. Когда размер пакета равен 65 000 байтам, что порождает 44 фрагментирован- ных пакета, 43 из 44 пакетов остаются незаблокированными, поскольку их бит смещения не равен 0, а бит дополнительных фрагментов равен 0. Системный лог регистрирует DoS-атаку. По-видимому, движком обнаружения DoS-атак регистриру- ются пакеты только фрагментированные. При нажатии кнопки "блокировать всё" во время атаки, загрузка CPU редко снижается ниже 80%, чаще всего она остаётся на 100%. Нажатие этой кнопки до начала атаки ограничивает загрузку CPU фаирволлом 50% и сохраняет её на этом уровне в течение атаки. Это, разумеется, не то, что должно происходить в нор- ме, поскольку предугадать, когда начнётся атака, невозможно. Общие выводы Те же, что и для атаки затоплением IGMP первого типа в разделе 5.1.8. 5.1.10 Затопление UDP Описание атаки: Затопить целевую машину UDP-пакетами со случайными исходящими IP-адресами и случайными исходящими портами, с длиной используемых пакетов в 1000 байт. Использованное средство: "HGOD_flood.exe" "Zonealarm": Сообщает о каждом пакете как об отдельном событии. DoS-эффекта не возни- кает. "Symantec Desktop Firewall": Сообщает о каждом пакете как об отдельном событии. DoS-эффекта не возни- кает. "Sygate Personal Firewall": Сообщает обо всех пакетах в сообщении об одном событии с увеличивающимся счётчиком. Сигнал тревоги о DoS-атаке не генерируется, хотя во время атаки загрузка CPU достигает 100%. Общие выводы DoS-эффекта возникать не должно. Противодействие Изменить реализацию фильтрующего движка, так чтобы DoS-эффект не возни- кал. 5.1.11 Изменение набора правил Описание атаки: Определить, где персональный фаирволл хранит набор правил. Изменить его так, чтобы добавить пользовательские правила, которые не вызывали бы подозре- ний и давали бы инструменту агрессии привилегии, необходимые для доступа в Интернет. "Zonealarm": Сохраняет набор правил для приложений в файле IAMDB.RDB, который в систе- ме "Windows 2000" находится в C:\WINNT\internetlogs\. Файл машинно-независим. Это означает возможность подмены его и его копии ─ файла BACKUP.RDB ─ изменён- ной версией с другой машины. Пока фаирволл работает, он держит этот файл отк- рытым в безраздельном доступе. Как рассмотрено в разделе 5.1.1, существует возможность терминировать процесс фаирволла и тем самым прекратить блокировку файла правил, что даёт возможность подменить его даже ограниченному пользова- телю. "Symantec Desktop Firewall": Хранит все правила в plain text в реестре. Соответствующий ключ: \HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\IAM\FirewallObjects\IPFilterRules\Rule1 Здесь находятся все детали правил, такие как направление или протокол. Атакую- щему не составляет труда вставить в начало последовательности правило, разре- шающее через фаирволл любой траффик. "Sygate Personal Firewall": Хранит набор правил в файле STDDEF.DAT в своём инсталляционном каталоге по умолчанию. Файл машинно-независим. Это означает возможность подмены его из- менённой версией с другой машины. Пока фаирволл работает, он держит этот файл открытым в безраздельном доступе. Как рассмотрено в разделе 5.1.1, существует возможность терминировать процесс фаирволла и тем самым прекратить блокировку файла правил, что даёт возможность подменить его даже ограниченному пользова- телю. Общие выводы Набор правил является мозгом персонального фаирволла. Если существует возможность изменять его записи, весь фаирволл оказывается беззащитным. Экспе- римент показал возможность добавления пользовательских правил для всех трёх протестированных фаирволлов. Этот приём может быть реализован в виде трояна, добавляющего всеразрешающее правило, делая возможной связь с Интернетом без ограничений. Противодействие Набор правил можно зашифровать и защитить кодом аутентификации сообщения [message authentication code (MAC)], но все данные, в особенности ключ, необ- ходимый для его расшифровки, придётся хранить локально в этой же машине. В противном случае, фаирволл не будет иметь возможность читать правила после пе- резагрузки машины. Однако, хранение секретного ключа локально оставляет воз- можность и другому приложению читать его и далее использовать для расшифровки правил. Если фаирволл открывает файл в безраздельном режиме, блокируя другим про- цессам возможность доступа к нему, возникает вопрос, не хранится ли он где-ли- бо в памяти, где им можно было бы манипулировать? Даже если последнее не рассматривается, как было показано в разделе 5.1. 1, остаётся возможность терминировать текущий процесс фаирволла и тем самым отменить исключительный режим доступа к файлу правил, оставив его незащищён- ным. Другой выход заключается в том, что в первый раз, когда пользователь инс- таллирует персональный фаирволл, у него запрашивается пароль. С этим паролем набор правил заверяется с использованием асимметричного алгоритма шифрования. Каждый раз при запуске фаирволл может использовать открытый ключ для проверки сигнатуры набора правил, дабы убедиться в том, что он не был подменён. Если пользователь хочет изменить некоторое правило, он предъявляет свой закрытый ключ и набор правил обновляется. Это могло бы сработать, если бы не одна проб- лема, заключающаяся в том, что злоумышленник может просто подменить набор пра- вил и снабдить его соответствующим открытым ключом, так что процедуру проверки он успешно пройдёт. Истоки проблемы в том, что мы не может полагаться ни на какие данные, поскольку они хранятся локально, а значит, могут быть подменены атакующим. Открытый ключ теряет аутентичность, будучи подменённым. Перемещение же процедуры аутентификации на другую машину неудобно с практической точки зрения. Файлы правил можно было бы инсталлировать только при правах администрато- ра и иметь небольшую службу, принимающую запросы на изменения только с пользо- вательского интерфейса. Это позволило бы защитить файл правил от изменений на- прямую, поскольку нормальный пользователь изменять этот файл прав иметь не бу- дет. Но проблема в том, что нормальный пользователь возможность изменять свою конфигурацию правил хочет иметь. Возможность для нормального пользователя из- менять правила всегда порождает возможность для инструмента агрессии действо- вать тем же методом. Напр., это может быть модифицированная версия пользова- тельского интерфейса, которая при запуске автоматически инсталлирует всеразре- шающее правило. Для скептиков можно предложить следующий сценарий. Инструмент агрессии делает скриншот реального пользовательского десктопа. Затем это изоб- ражение демонстрируется поверх всего, а клавиатура отключается. Для обычного пользователя это будет выглядеть так, будто машина "задумалась". За этим изоб- ражением, инструмент эмулирует клики мыши и нажатия клавиш для персонального фаирволла. Таким способом он может создать правило, разрешающее всё, как будто это сделал нормальный пользователь. В конце скриншот будет удалён, а пользова- тель появление нового правила не заметит. "Sygate Personal Firewall" использует другой подход. При закрытии он за- писывает правила из памяти обратно в файл. Это устраняет проблему манипуляции файлом во время нормального использования. К сожалению, этот метод надёжен только при отсутствии возможности манипулировать правилами в памяти и закры- вать фаирволл обходными путями. Возможность последнего была доказана в разделе 5.1.1. Увы, предложить надёжно работающее решение данной проблемы не представля- ется возможным. По моему мнению, она должна решаться с использованием админис- трирующего процесса, который контролирует файл правил. 5.1.12 Подмена двоичного кода Описание атаки: Подменить доверяемое приложение инструментом агрессии, замаскированным под него. Для эксперимента "C:\Program Files\Internet Explorer\IEXPLORE.EXE" был заменён приложением telnet.exe, посредством переименования и перезаписи. После этого начато исходящее соединение по TCP порту 80. "Zonealarm": Замечает подмену и спрашивает разрешение на обновление базы правил. "Zo- nealarm" сохраняет набор правил для приложений в файле IAMDB.RDB, который в системе "Windows 2000" находится в C:\WINNT\internetlogs\. Файл машинно-неза- висим. Это означает возможность подмены его и его копии ─ файла BACKUP.RDB ─ изменённой версией с другой машины. Пока фаирволл работает, он держит этот файл открытым в безраздельном доступе. Как рассмотрено в разделе 5.1.1, сущес- твует возможность терминировать процесс фаирволла и тем самым прекратить бло- кировку файла правил, что даёт возможность подменить его даже ограниченному пользователю. "Symantec Desktop Firewall": Замечает подмену и сообщает о том, что для "telnet" также существуют пра- вила, но с последнего раза путь к файлу изменился, и требуется создать новое правило. Программа рекомендует создающий правила автонастройщик, который смот- рит имя файла и затем даёт изменённому "telnet" даже большие полномочия, чем требовалось. Напр., разрешаются порты FTP, Gopher и SSL. Рекомендующий автона- стройщик должен быть выключен, поскольку способен привести неопытного пользо- вателя к неверному выбору. Это обычная функция для нормального конфигурирова- ния, но она может быть легко использована в злонамеренных целях. Все сигнатуры приложения сохраняются в реестре в plain text и без каких- либо дальнейших проверок целостности. Поэтому можно легко подменить хеш сигна- туры "Internet Explorer" новым хешем инструмента агрессии. Хеш хранится в клю- че реестра, расположенном в: HKLM\Software\symantec\IAM\FirewallObjects\Applications\Internet Explorer\App· licationSignature1 Reg_Binary Этот хеш машинно-независим. Знать, как он генерируется, необязательно, пос- кольку можно легко сгенерировать его на другой машине и подменить им ориги- нальный на первой. "Sygate Personal Firewall": Факт подмены файла регистрируется фаирволлом как событие, и выводится со- общение, спрашивающее у пользователя, являются ли изменения ожидаемыми. В списке приложений название "Internet Explorer" сменяется на "telnet", но сете- вые соединения для "telnet" всё равно остаются блокированными. Возникает вопрос, где "Sygate Personal Firewall" хранит хеши приложений. В реестре ничего найти не удалось. Поэтому можно предположить, что они хранят- ся в файле. С помощью средств наблюдения за доступом к файлам можно выследить команды записи в файл stdState.dat, расположенный в инсталляционном каталоге фаирволла. В этом файле программа хранит правила для каждого приложения. Файл зашифрован, так что изменить его невозможно. Однако, во время эксперимента оказалось возможным заменить данный файл на stdState.dat с другой машины. Если подмена произведена в процессе работы фаирволла, ничего не происходит, т.к. по закрытии программа восстанавливает в нём данные, сохраняя их из памяти. Но ес- ли фаирволл не работает, при следующем запуске, файл, созданный на другой ма- шине, и все правила в нём он принимает. Это делает подмену файла правил прило- жений возможной. Общие выводы Файл правил и значения хешей являются мозгом персонального фаирволла. Ес- ли существует возможность изменять его записи, весь фаирволл оказывается без- защитным. Эксперимент показал возможность подмены отпечатков приложений для всех трёх протестированных фаирволлов. Этот приём может быть реализован в виде трояна, добавляющего себя к доверяемым приложениям, и получающего связь с Ин- тернетом без ограничений. Противодействие О мерах противодействия см. об атаке с изменением набора правил в разделе 5.1.11. 5.1.13 Сканирование портов 1 Описание атаки: С помощью программы "Nmap" произвести сканирование портов целевой машины в поисках открытых. Это часто первое, что делает атакующий, чтобы узнать о це- ли больше. "Nmap" был использован с опциями -sT -p 440-450 -v -P0 -T Aggressi· ve. Данный метод сканирования TCP-соединения является основным вариантом ска- нирования портов с помощью полных TCP-хендшейков. Он не очень скрытен, но всё ещё широко используется. Тестировались все TCP-порты от 440 до 450 без пауз между сканированиями. Диапазон портов выбран без каких-либо отдельных сообра- жений. Использованное средство: "Nmap" "Zonealarm": Сообщает о каждом пакете как об отдельном событии. "Nmap" сообщает обо всех портах, как отфильтрованных. "Symantec Desktop Firewall": Сообщает о каждом пакете как об отдельном событии. "Nmap" сообщает обо всех портах, как отфильтрованных. "Sygate Personal Firewall": Каждый пакет регистрируется. Системный лог регистрирует 3 события скани- рования портов с номерами 6, 4 и 10. "Nmap" сообщает обо всех портах, как от- фильтрованных. Общие выводы Все три фаирволла не вполне соблюдают скрытность, но реагируют полностью одинаково. Ни один порт не был выявлен как открытый или блокированный. Противодействие Необходимости в мерах противодействия нет, поскольку утечки информации не происходит. 5.1.14 Сканирование портов 2 Описание атаки: С помощью программы "Nmap" произвести сканирование портов целевой машины в поисках открытых. "Nmap" был использован с опциями -sT -p 440-444 -v -P0 -T sneaky. Это тот же метод сканирования TCP-соединения, что использовался при сканировании портов 1, но с длительными задержками по 15 с между отдельными сканированиями. Замедление сканирования может позволить обойти некоторые де- тектирующие движки, поскольку они следят за специфическим количеством соедине- ний в фиксированном интервале времени. Использованное средство: "Nmap" "Zonealarm": Сообщает о каждом пакете как об отдельном событии. "Nmap" сообщает обо всех портах, как отфильтрованных. "Symantec Desktop Firewall": Сообщает о каждом пакете как об отдельном событии. "Nmap" сообщает обо всех портах, как отфильтрованных. "Sygate Personal Firewall": Сообщает о каждом пакете как об отдельном событии. "Nmap" сообщает обо всех портах, как отфильтрованных. Системный лог регистрирует 2 события скани- рования портов, каждое с номером 1. Общие выводы Обо всех портах сообщается, как об отфильтрованных. Атакующий в процессе атаки информацию не получает. Противодействие Необходимости в мерах противодействия нет, поскольку утечки информации не происходит. 5.1.15 Сканирование портов 3 Описание атаки: С помощью программы "Nmap" произвести сканирование портов целевой машины в поисках открытых. "Nmap" был использован с опциями -sS -p 440-444 -v -P0 -T sneaky. На этот раз отсылаются только SYN-пакеты. Этот приём часто называется "полуоткрытым" сканированием, поскольку полный трёхактный TCP-хендшейк до за- вершения не доводится. После получения ответа от целевой системы, немедленно отсылается RST-пакет, закрывающий запрос на соединение. Использованное средство: "Nmap" "Zonealarm": Сообщает о каждом пакете как об отдельном событии. "Nmap" сообщает обо всех портах, как отфильтрованных. "Symantec Desktop Firewall": Сообщает о каждом пакете как об отдельном событии. "Nmap" сообщает обо всех портах, как отфильтрованных. "Sygate Personal Firewall": Сообщает о каждом пакете как об отдельном событии. "Nmap" сообщает обо всех портах, как отфильтрованных. Системный лог регистрирует 4 события скани- рования портов. Общие выводы Обо всех портах сообщается, как об отфильтрованных. Атакующий в процессе атаки информацию не получает. Противодействие Необходимости в мерах противодействия нет, поскольку утечки информации не происходит. 5.1.16 Сканирование портов 4 Описание атаки: С помощью программы "Nmap" произвести сканирование портов целевой машины в поисках открытых. "Nmap" был использован с опциями -sX -p 440- 444 -v -P0 -T normal. В этом случае используется сканирование XMAS. Оно означает отправку специального пакета с выставленными флагами FIN, URG и PUSH. Поскольку флаг SYN не выставлен, такой пакет пройдёт фильтры без сохранения состояния. В за- висимости от результата можно догадаться, открыт порт или нет. Данный метод срабатывает не всегда, т.к. зависит от ОС. Использованное средство: "Nmap" "Zonealarm": Никакого сообщения о событии не генерируется. "Nmap" сообщает, что все порты открыты, что неверно. "Symantec Desktop Firewall": Никакого сообщения о событии не генерируется. "Nmap" сообщает, что все порты закрыты. "Sygate Personal Firewall": В логе траффика или системном никакого сообщения о событии не регистриру- ется. Лог "сырых" данных пакетов регистрирует. "Nmap" сообщает, что все порты открыты, что неверно. Общие выводы Такое поведение делает возможным предположить, какой именно персональный фаирволл используется в целевой машине. Данная информация может быть затем ис- пользована при запуске эксплойта, нацеленного на конкретную версию персональ- ного фаирволла. Противодействие Данная проблема может быть решена только через реализацию фаирволла, про- веряющего пакеты с сохранением состояния. 5.1.17 Блокирование мьютекса Описание атаки: Некоторые персональные фаирволлы используют мьютекс для проверки наличия своей уже загруженной копии. Мьютекс ─ это программный объект, позволяющий нескольким программным потокам совместно пользоваться одним ресурсом ─ таким как доступ к файлу, ─ но не одновременно. При запуске программы создаётся мью- текс с уникальным идентификатором. С этого момента любой поток, нуждающийся в ресурсе, на время его использования должен заблокировать мьютекс для других потоков. Мьютекс разблокируется, когда данные более не нужны или процедура за- вершена. Остановка работы персонального фаирволла и блокирование его мьютекса инс- трументом агрессии делает возможным воспрепятствовать загрузке фаирволла и, как следствие, защите сети. Использованное средство: "ZoneMutex" от "Diamond Computer Systems Labs" "Zonealarm": Средство терминирует процесс исполнения фаирволла. Затем создаётся мью- текс с именем "Zone Alarm Mutex", препятствующий перезагрузке настоящего "Zo- nealarm". Вследствие блокировки мьютекса машина становится незащищённой. Инст- румент агрессии может даже сохранять иконку в системном лотке, симулируя нор- мальную работу настоящего фаирволла. "Symantec Desktop Firewall" и "Sygate Personal Firewall": К сожалению, готовых средств для проведения такой атаки на эти фаирволлы в распоряжении не было. Поскольку время, выделенное на данную работу, было ог- раничено, запрограммировать собственное блокирование мьютекса для данных фаир- воллов не представлялось возможным. Поэтому данное тестирование для "Symantec Desktop Firewall" и "Sygate Personal Firewall" не проводилось. Общие выводы Данная проблема имеет связь с темой терминации процесса. Т.к., если фаир- волл уже исполняется, перед блокированием мьютекса процесс требуется термини- ровать. То, что единственный вызов API мьютекса способен воспрепятствовать загрузке фаирволла, является очень серьёзным. Противодействие Предотвратить возможность имитации мьютекса фаирволла другим процессом. Вероятно, этого можно достичь использованием для защиты мьютекса криптографи- ческих алгоритмов. Что весьма нетривиально. Но, следует иметь в виду, что зло- умышленник может взять исходное приложение фаирволла и извлечь из него часть, отвечающую за создание мьютекса. Тогда блокирование мьютекса будет возможным, независимо от средств, использованных для его защиты. 5.1.18 Внедрение DLL Описание атаки: Сделать DLL, которая будет автоматически загружена как доверяемое прило- жение. Далее она сможет использовать права доверяемого приложения для установ- ления сетевых соединений. В настоящем эксперименте было использовано средство, создающее DLL, загружаемую вместе с "Internet Explorer". Использованное средство: "FireHole" "Zonealarm": Не сообщает ни о чём необычном. Пакеты получают те же права, что и роди- тельское доверяемое приложение. "Symantec Desktop Firewall": Не сообщает ни о чём необычном. Пакеты получают те же права, что и роди- тельское доверяемое приложение. "Sygate Personal Firewall": Сообщает об изменённой DLL и спрашивает, следует ли её разрешить или заб- локировать. Это происходит в результате сравнения DLL со внутренним списком названий и отпечатков. Как рассматривается в разделе 5.1.12, существует воз- можность подменить этот внутренний список так, чтобы новая DLL загружалась, не вызывая сигналов тревоги. Общие выводы Данная идея аналогична внедрению потока в память процесса доверяемого приложения. Противодействие Персональный фаирволл должен проверять также все загружаемые приложением DLL и следить за ними. "Sygate Personal Firewall" это уже делает. Разумеется, это возвращает нас к проблеме, где и как хранить сигнатуры проверяемых DLL, о чём уже говорилось в разделе 5.1.12. 5.1.19 Кодирование URL Описание атаки: Используя имеющийся веб-браузер, отправить скрытую строку, закодированную в URL. Напр., открыть URL: http://www.attackerssite.com\input.php?passwd=secret&IP=192.168.0.7 Окно браузера, применяемое для отправки этой информации, может быть сделано невидимым или за пределами пользовательского экрана, чтобы не вызывать подоз- рений. Данный приём используют средства типа "TooLeaky". Общие выводы Этот приём будет работать всегда, покуда разрешён веб-траффик. Если нор- мальному веб-траффику разрешено проходить через фаирволл, этот приём заблоки- рован быть не может. Не существует возможности различать веб-траффик злонаме- ренный и безобидный. При этом все простые почтовые формы используют точно та- кие же приёмы отправки информации по HTTP. Здесь мы встречаемся с трудной проблемой, поскольку пользователь не согласится отказаться от возможности хо- дить по Интернету, лишь ради безопасности. Противодействие Блокирование веб-браузера нецелесообразно и поэтому не рассматривается. Даже если фаирволл осуществляет проверку пакетов с сохранением состояния, дан- ный приём всё равно обнаружен не будет, т.к. траффик всё равно будет легальным HTTP-траффиком. Единственная вещь, которая может помочь ─ это блокирование запросов дру- гих приложений на открытие URL в браузере по умолчанию. Но это может быть од- ной из функций, от которых пользователь отказываться не захочет. Использование веб-прокси проблему не устранит. Окончательный вывод ─ практически пригодного метода противодействия дан- ной атаке не существует. 5.1.20 LSP Описание атаки: Проинсталлировать поставщик многоуровневых служб ["layered service provi- der" (LSP)] [16], просматривающий весь входящий траффик. Если LSP окажется ин- сталлированным в протокольной цепи под фаирволлом, может появиться возможность видеть пакеты до того, как они будут отброшены фаирволлом в этой цепи. При этом реализация в нём самостоятельной фильтрации пакетов атакующего позволит добиться того, что они уже не будут увидены фаирволлом. Это сделает возможной двустороннюю связь, минуя фаирволл, даже когда он функционирует. Использованное средство: "AWP LSP" "Zonealarm": LSP инсталлируется без проблем. Заблокированные им пакеты в LSP не появ- ляются. "Symantec Desktop Firewall": LSP инсталлируется без проблем. Заблокированные им пакеты в LSP не появ- ляются. "Sygate Personal Firewall": LSP инсталлируется без проблем. Заблокированные им пакеты в LSP не появ- ляются. Общие выводы LSP был проинсталлирован в цепи недостаточно глубоко, вчастности, не под драйвером фаирволла, или использовались другие пути доступа к событиям сетевой платы. Фаирволл работал нормально и видел отбрасываемые пакеты раньше LSP. Т. о., атака не состоялась. Противодействие Не требуется, однако, необходимо убедиться в невозможности проинсталлиро- вать LSP ниже драйвера персонального фаирволла. 5.1.21 Исходящее затопление Описание атаки: Попытаться изобразить инструмент агрессии, атакующий из охраняемой машины некоторую цель. Т.е., было использовано средство затопления для атаки на дру- гую машину. В протоколе варьировались TCP-пакеты с выставленным флагом SYN, IGMP-траффик и UDP-пакеты. Использованное средство: "HGOD_flood.exe" "Zonealarm": Обнаруживает средство и спрашивает, разрешить его траффик или заблокиро- вать. "Symantec Desktop Firewall": Никаких событий не отмечается, никакие пакеты не видны. "Sygate Personal Firewall": Обнаруживает средство и спрашивает, разрешить его траффик или заблокиро- вать. Все пакеты находятся в логе "сырых" пакетов. Общие выводы Подобный сценарий обычен для DoS-атаки, производимой из машины. Напр., при размножении червя [8]. Противодействие Исходящее затопление должно обнаруживаться и блокироваться в том случае, если оно нежелательно или несанкционировано. Поэтому необходим фильтр, прове- ряющий пакеты с сохранением состояния, поскольку средство затопления может от- правлять специфические пакеты. 5.1.22 Загрузка 100% процессора и памяти Описание атаки: С помощью кода на JavaScript легко создать 100%-ю загрузку CPU и памяти. Смысл данного мероприятия заключается в том, что из-за нехватки ресурсов неко- торые события могут фаирволлом не зарегистрироваться. Если же фаирволл разра- ботан недостаточно качественно, существует также вероятность его краха. "Zonealarm": Краха фаирволла не произошло, и регистрация шла нормально. Никаких собы- тий в процессе тестирования пропущено не было. "Symantec Desktop Firewall": Краха фаирволла не произошло, и регистрация шла нормально. Никаких собы- тий в процессе тестирования пропущено не было. "Sygate Personal Firewall": Краха фаирволла не произошло, и регистрация шла нормально. Никаких собы- тий в процессе тестирования пропущено не было. Общие выводы Похоже, что интенсивное потребление ресурсов целевой системы на персо- нальный фаирволл не влияет. Хотя, разумеется, вызывает неработоспособность системы вцелом. Противодействие Не требуется. 5.1.23 Проверка специальных пакетов Описание атаки: Отправить целевой системе специально изготовленный пакет, чтобы опреде- лить, какие виды пакетов ею обнаруживаются. Основное внимание сосредоточено на всех вариациях флагов, которые может иметь TCP-пакет. Если существует возмож- ность отправить пакеты, которые не регистрируются, это делает возможным уста- новление трояном канала связи, использующего такие пакеты. Использованное средство: "PacketCrafter" "Zonealarm": тип пакета выставленные флаги обнаружен IP ─ нет TCP ─ да TCP URG да TCP ACK да TCP PSH да TCP RST да TCP SYN да TCP FIN да TCP все кроме PSH да UDP ─ да Таблица показывает результаты проверки специальных пакетов для "Zone- alarm". Когда исходящий и входящий IP-адреса установлены в локальный адрес (127.0.0.1), пакет обрабатывается как исходящий. "Symantec Desktop Firewall": тип пакета выставленные флаги обнаружен IP ─ нет TCP ─ нет TCP URG нет TCP ACK нет TCP PSH нет TCP RST нет TCP SYN да TCP FIN нет TCP все кроме PSH да UDP ─ да Таблица показывает результаты проверки специальных пакетов для "Symantec Desktop Firewall". Обнаруживаются только пакеты, имеющие флаг SYN. Когда исхо- дящий и входящий IP-адреса установлены в локальный адрес (127.0.0.1), пакет обрабатывается как входящий. "Sygate Personal Firewall": тип пакета выставленные флаги обнаружен IP ─ нет TCP ─ да TCP URG да TCP ACK да TCP PSH да TCP RST да TCP SYN да TCP FIN да TCP SYN & ACK нет UDP ─ да Таблица показывает результаты проверки специальных пакетов для "Sygate Personal Firewall". Все пакеты регистрируются в лог "сырых" пакетов. Когда ис- ходящий и входящий IP-адреса установлены в локальный адрес (127.0.0.1), пакет обрабатывается как входящий. Общие выводы Инструмент агрессии типа трояна может использовать специальные пакеты, чтобы связываться, минуя персональный фаирволл, т.к. для каждого из них сущес- твуют виды пакетов, которые он не обнаруживает. Противодействие Персональные фаирволлы должны иметь фильтр, проверяющий пакеты с сохране- нием состояния, способный обнаруживать все виды пакетов, и проверять их при- надлежность к санкционированному соединению. 5.1.24 Изменение лога Описание атаки: Попытаться изменить лог персонального фаирволла. Это позволит атакующему удалить все возможные следы успешного взлома. Также появляется возможность по- мещения ложной информации для оклеветания других людей. Принятие данных лога на веру может иметь далеко идущие последствия. "Zonealarm": Хранит лог в plain text. Файл может быть легко изменён или даже удалён во время исполнения процесса. Консоль приложения имеет собственный буфер, который остаётся заполненным, даже когда программа перезапущена. Это означает, что из- менение лога на консоли никак не отразится. Тем не менее, все вставленные со- бытия будут размножаться до централизованной консоли безопасности, если она используется. "Symantec Desktop Firewall": Во время работы фаирволла, лог удалён быть не может. Но в реестре есть флаг: HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\IAM\Logs\Firewall при выключении которого, процесс регистрации в лог останавливается. Разумеется, если фаирволл не работает, логи могут быть изменены. При сле- дующей перезагрузке, все новые события также появятся в просмотре консоли. "Sygate Personal Firewall": Во время работы фаирволла, лог удалён быть не может. Разумеется, если фаирволл не работает, логи могут быть изменены. При следующей перезагрузке, все новые события также появятся в просмотре консоли. Общие выводы После завершения процесса персонального фаирволла содержимое его лога можно изменить или удалить весь лог. Противодействие Защитить лог от изменения во время работы процесса. Не существует практически пригодного способа защитить лог от изменения, когда процесс не исполняется. Шифрование файла выходом не является, поскольку должна существовать возможность извлечения данных сторонними средствами, так чтобы они могли передавать события централизованному коррелирующему движку. Ещё важнее то, что ключ для расшифровки будет также храниться локально и может быть извлечён из фаирволла. Если фаирволл не работает, также не существует способов защитить его ключ от инструментов агрессии. 5.1.25 Нажатие кнопки "да" Описание атаки: Сделать небольшое приложение, которое остаётся в памяти и следит за наз- ваниями выводимых окон, ожидая появления окна автонастройщика персонального фаирволла, который спросит пользователя, разрешить или блокировать некий траф- фик. В этот момент приложение сэмулирует нажатие кнопки "да", напр., отсылая последовательность клавиш быстрого ввода. Если это произойдёт достаточно быст- ро, пользователь ничего не заметит. Данный метод позволяет создать для новых приложений правила, разрешающие им соединения с Интернетом. Общие выводы Это простая локальная атака, не направленная на персональный фаирволл как таковой. Скорее, она использует функцию, имеющуюся во всех персональных фаир- воллах и включенную по умолчанию. Поэтому данная атака срабатывает со всеми версиями персональных фаирволлов. Противодействие Новое правило будет видно в списке, но обычный список правил содержит бо- лее сотни записей, из-за чего в нём трудно отыскать новое. Обычный пользова- тель заглядывает в список правил редко, по крайней мере, пока все его приложе- ния работают нормально. Выключение автонастройщика выходом не является, пос- кольку он чрезвычайно удобен для начинающего пользователя. С ним пользователь избавлен от необходимости догадываться, какие виды соединений требуются для конкретного приложения. Поэтому защиты от данного вида атак не существует. 5.1.26 Невидимость Описание атаки: Существует несколько руткитов для Windows. С помощью этих утилит можно скрыть исполняемое приложение от системы. Осуществляется это патчением функций ядра или перехватом вызовов API в системе. Общие выводы Использованные руткиты способны успешно скрыть процесс от менеджера задач и "Explorer". Но они не могут помешать персональному фаирволлу видеть и блоки- ровать траффик. Вероятно, будет непросто манипулировать сетевым драйвером так, чтобы отфильтровать конкретный траффик, прежде чем фаирволл его увидит. С другой стороны обеспечение нового сетевого стека данную проблему может решить. Это будет практически тем же, что уже описано в разделе 5.1.20. Противодействие Не требуется. 5.1.27 Туннелирование Описание атаки: "Туннелированием" называется перепаковка пакетов в другие протоколы. Её суть заключается в использовании разрешённого протокола, такого как HTTP, и наполнении его пакетов исходным траффиком. Для этой цели часто используются протоколы типа HTTP, SMTP или ICMP. Общие выводы Данный приём хорошо срабатывает против сетевых фаирволлов, поскольку они не могут различать пакеты туннелированные и исходные. Данный приём не будет работать с фаирволлами персональными, поскольку они будут видеть отличия в названиях приложений и блокировать их. Для персонально- го фаирволла существует разница между приложениями, которые отсылают траффик. Противодействие Не требуется. 5.1.28 Порт трояна Описание атаки: Сэмулировать программу троянского сервера, пытающуюся прослушивать входя- щие соединения. Общие выводы Входящие соединения с троянскими серверами фильтруются наравне с осталь- ным входящим траффиком и вместе с названием правила сопоставляются с названием трояна, обычно использующего данный порт. Трояны могут быть переконфигурирова- ны на использование любого другого порта, поэтому сопоставление этих портов с названиями троянов не имеет смысла. С точки зрения безопасности, данный сцена- рий не является проблемой для персональных фаирволлов, поскольку они обнаружи- вают троянский сервер, когда он пытается получить доступ в Интернет. Затем фаирволл предлагает заблокировать приложение, препятствуя установлению трояном соединения. Противодействие Не требуется. 5.2 Выводы Персональные фаирволлы хорошо справляются с защитой от входящих атак. Они не могут предотвратить значительную DoS-атаку, но это нормально. Тем не менее, эксперименты показали, что они могут поднимать способность противостоять DoS- атакам на более высокий уровень. Единственная вещь, которую следует иметь в виду, ─ это опасность, влеко- мая встраиванием в персональные фаирволлы систем автоматического реагирования. Реакция на сигналы тревоги, сгенерированные фаирволлом, остаётся адекватной, пока мы не доверяем информации об источнике атаки. Большинство атак, использо- ванных в процессе эксперимента, может быть проделано с поддельными исходящими адресами, что делает их блокирование невозможным, и вероятно, принципиально. Перевод системы в скрытный режим ─ когда она не отвечает на любые незап- рошенные пакеты, ─ свойство хорошее, но не обязательное. Открытые порты ло- кальной системы при сканировании портов будут всегда опознаваться как откры- тые, и это единственное, что интересует атакующего. Разумеется, функции, кото- рые не должны быть доступны из сети, подлежат блокированию, но это вопрос кон- фигурирования. С другой стороны, персональные фаирволлы уязвимы к различным атакам, ис- ходящим из системы, в которой они инсталлированы. Эта проблема неразрешима. Невозможно воспрепятствовать действиям, которые может производить и нормальный пользователь. Напр., в той мере, в какой пользователь может запускать и прек- ращать какую-либо службу фаирволла, эти возможности имеет и запущенный пользо- вателем инструмент агрессии. То же самое относится и к набору правил. В той мере, в какой пользователь может изменять набор правил, изменять его может и инструмент агрессии. Решением проблемы мог бы стать запуск персонального фаир- волла с администраторскими правами, как уже делает большинство антивирусных сканнеров. Однако, это лишит пользователя удобства добавления новых правил "на лету". По существу, это основная проблема персональных фаирволлов ─ они рабо- тают в системе, в которой могут подвергнуться атаке изнутри. Поэтому невозмож- но сделать что-либо, что злоумышленник с правами администратора не мог бы из- менить. Персональные фаирволлы должны содержать проверяющий пакеты фильтр с сох- ранением состояния, иначе появляется возможность для скрытого канала связи с использованием специальных пакетов. Это также сможет устранить опасность неко- торых входящих DoS-атак, которые из-за данного недостатка пока не обнаружива- ются. Разумеется, персональные фаирволлы должны отслеживать все используемые протоколы, особенно IGMP. Глава 6 Коррелирование и кооперация В этой главе вводится унифицированный формат лога событий и даны некото- рые примеры взаимодействия между персональными фаирволлами. Затем рассматрива- ется и экспериментально иллюстрируется коррелирование событий лога. 6.1 Общий формат лога Чтобы иметь возможность сравнивать и коррелировать события одних персо- нальных фаирволлов с событиями других персональных фаирволлов или других средств безопасности, неизбежно требуется приведение различных форматов логов к унифицированному. Этот формат должен содержать всю необходимую информацию. Наличие адекватного формата облегчит составление правил, адекватных сигналам тревоги. К сожалению, ничего, похожего на унифицированный формат лога, который был бы принят и использовался всеми разработчиками, не существует. Поэтому, возникает необходимость в разработке средств, конвертирующих оригинальные фор- маты событий в новый унифицированный формат. В рамках данной работы было напи- сано три скрипта на Perl, пригодных для перевода логов трёх персональных фаир- воллов в такой унифицированный формат. 6.1.1 Определения В унифицированный лог событий должна быть включена информация, которую обычно сообщают все персональные фаирволлы. Кроме того, интерпретирующим скриптом должны быть добавлены поля, которые не присутствуют в логах, но, тем не менее, нужны, напр., поле доверия. После анализа логов и сравнения их с ло- гами IDS и сетевых фаирволлов, был выведен формат унифицированного лога собы- тий, содержащий поля, которые приведены в таблице ниже и описываются далее. описание название поля значение IP-адрес датчика SensorIP IP-адрес [4 октета] тип датчика Type [ZOA3|SDF2|SPF5] время события Time отметка времени Unix исходящий IP-адрес SrcIP IP-адрес [4 октета] исходящее имя хоста SrcName <строка> исходящий номер порта SrcPort <целое> входящий IP-адрес DestIP IP-адрес [4 октета] входящее имя хоста DestName <строка> входящий номер порта DestPort <целое> произведённое действие Action [blocked|allowed|ignored|info|N/A] направление Direction [incoming|outgoing|N/A] использованный протокол Protocol [TCP|UDP|ICMP|IGMP|N/A] флаги или тип пакета Flag [SYN|FIN|ECHO_REPLY|...] затронутое приложение Application <строка> степень доверия событию Trust [0─9] название сигнатуры Signature <строка> полное исходное сообщение Msg <строка> o SensorIP: (обязательное) Адрес машины, в которой работает персональной фаирволл. Эта информация может быть также вычислена на основе исходящего адреса, входящего адреса и на- правления, но в некоторых случаях этот способ может не сработать. Напр., когда пакет был отправлен на широковещательный адрес. Кроме того, эта информация часто востребованная, и потому есть смысл хранить её в отдельном поле. Поле заполняется интерпретирующим скриптом. o Type: (обязательное) Тип и версия использованного персонального фаирволла. Оно может приме- няться при отфильтровывании событий, специфичных для разработчика. Напр., если известно, что определённые сигнатуры соответствуют некоторой атаке не вполне точно. Или же эта информация может быть использована для написания правила коррелирования, основанного на специфических особенностях конкретного фаирвол- ла. Продукты, задействованные в данной работе, были промаркированы как "ZOA3" для "Zonealarm 3", "SDF2" для "Symantec Desktop Firewall 2" и "SPF5 для "Syga- te Personal Firewall 5". Поле заполняется интерпретирующим скриптом. o Time: (обязательное) Обычная отметка времени в формате Unix. Важно убедиться, что все охраняе- мые машины находятся в одном часовом поясе. o SrcIP: (факультативное) Адрес, с которого поступил траффик. Может быть пустым, если вместо тако- вого было дано имя хоста. o SrcName: (факультативное) Имя хоста, с которого поступил траффик. Конвертировать это имя в адрес имеет смысл не всегда, т.к. за то время, пока произойдёт конверсия, адрес или локальное разрешение DNS может измениться. o SrcPort: (факультативное) Номер порта, с которого поступил траффик. o DestIP: (факультативное) Адрес, к которому был направлен траффик. o DestName: (факультативное) Имя хоста, к которому был направлен траффик. Конвертировать это имя в ад- рес имеет смысл не всегда, т.к. за то время, пока произойдёт конверсия, адрес или локальное разрешение DNS может измениться. o DestPort: (факультативное) Номер порта, к которому был направлен траффик. o Action: (обязательное) Может содержать пять вариантов строки: "blocked" ─ означает, что траффик персональным фаирволлом был блоки- рован и выброшен. Эта информация может быть полезна для проверки успешности атаки. "allowed" ─ означает, что траффик не был блокирован и через персо- нальный фаирволл прошёл. Эта информация может быть по- лезна для проверки успешности атаки. "ignored" ─ означает, что траффик был зарегистрирован, но блокирован не был. "info" ─ означает, что данное событие является только информаци- онным, типа "для telnet.exe добавлено новое правило". При данном значении поля сама информация о событии нахо- дится в поле "Msg". "N/A" ─ означает, что ни один из вышеперечисленных вариантов не подходит или в процессе интерпретации строки этого собы- тия в исходном логе произошла ошибка. o Direction: (факультативное) Направление: входящее или исходящее. Эта информация может быть также вы- числена на основе входящего и исходящего адресов, однако, эти адреса могут быть и фиктивными. Некоторые персональные фаирволлы, напр., "Zonealarm", похо- же, действуют именно таким образом и попадают впросак, когда отсылается пакет, имеющий входящий и исходящий адреса, равные адресу самого фаирволла. И, пос- кольку исходящий адрес равен локальному, пакет воспринимается как исходящий. Кроме того, эта информация часто востребованная, и поэтому есть смысл хранить её в отдельном поле. o Protocol: (факультативное) Наблюдаемый протокол, напр., TCP или UDP. Поле факультативное, поскольку его предполагают не все события. Напр., протокола не имеют сообщения информа- ционные. o Flag: (факультативное) Дополнительная информация об использованном протоколе, если таковая име- ется. Напр., это может быть "SYN", если в пакете был выставлен флаг "SYN". o Application: (факультативное) Название приложения, отправлявшего или принимавшего пакеты в наблюдаемой системе. o Trust: (обязательное) Собственно в логах персональных фаирволлов отсутствует и было введено до- полнительно. Его значением является число от 0 до 9, выражающее степень дове- рия данному сигналу тревоги. Число 0 означает, что мы не доверяем сигналу и считаем его ложным, а число 9 означает, что мы доверяем сигналу и считаем его верным. Данный параметр призван помочь в устранении ложных срабатываний пос- редством оценки событий и, возможно, игнорирования в процессе коррелирования сигналов тревоги, имеющих низкую степень доверия. По умолчанию всем интерпре- тируемым сообщениям присваивается уровень доверия 5. В данной работе единст- венное правило, изменяющее его ─ это оценка сигналов тревоги. Согласно ей, сигналы тревоги соединений, исходящих с охраняемой машины, по умолчанию полу- чают +1 балл, а входящих ─ ─1 балл. Причина этого в наличии над локальными со- бытиями большего контроля и большей информации о них. Удалённые события могут быть легко подделаны, чтобы заставить нас думать так, как нужно атакующему. Напр., сканирование портов может происходить с поддельных исходящих IP-адре- сов, так чтобы казалось, будто оно исходит откуда-то ещё. Манипулировать же локальными событиями значительно труднее. o Signature: (факультативное) Название сигнатуры, соответствующей данному сигналу тревоги. Нужно иметь в виду, что пользователь может иметь права на изменение правила и, следова- тельно, также на переименование его в нечто, реальному событию не соответству- ющее. Но если контролируема, эта информация в дальнейшем при фильтровании со- бытий может быть полезна. o Msg: (обязательное) Полное сообщение о событии в том виде, как оно появилось в исходном логе. Это поле добавлено специально для информационных сообщений. Если событие носит информационный характер, здесь находится собственно строка сообщения. Посколь- ку различных информационных сообщений очень много, не имеет смысла вводить но- вые поля для каждого в отдельности. Также оно может использоваться в качестве резерва на случай, если информация утерялась в процессе интерпретации скрип- том. Некоторые поля после интерпретации различных событий логов могут оста- ваться пустыми, поскольку в исходном сообщении о событии информация может при- сутствовать не вся. Номера событий удаляются, поскольку они могут быть несог- ласованными и не представляют интереса. Коррелирующий центр или центральная консоль могут и, вероятнее всего, добавят собственную нумерацию событий. 6.1.2 Экспорт Ниже приведены использованные отображения экспортов конкретных персональ- ных фаирволлов на описанный унифицированный формат. Как было сказано в начале этой главы, в процессе данной работы были созданы средства трансляции событий. Отображение лога "Zonealarm" Типичное событие лога "Zonealarm" выглядит следующим образом: FWIN,2002/11/25,14:35:52 +1:00 GMT,10.10.10.7:53,10.10.50.2:53,TCP (flags:S) Таблица трансляции лога "Zonealarm" FWIN, -> Direction 2002/11/25, 14:35:52 +1:00 GMT, -> Time 10.10.10.7:53, -> SrcIPaddr + SrcPort 10.10.50.2:53, -> DestIPaddr + DestPort TCP (флаги:S) -> Protocol + Flag строка полностью -> Msg согласно правилу Trust определяется скриптом SensorIP определяется скриптом Type определяется скриптом Action Отображение лога "Symantec Desktop Firewall" Типичное событие лога "Symantec Desktop Firewall" выглядит следующим об- разом: 11/27/2002 15:50:48 Rule "Implicit block rule" blocked (10.10.50.1,446). Details: Inbound TCP connection Local address,service is (10.10.50.1,446) Remote address,service is (10.10.50.4,1684) Process name is "N/A" Таблица трансляции лога "Symantec Desktop Firewall" 12/27/2002 15:50:48 -> Time Rule "Implicit block rule" -> Signature blocked -> Action (10.10.50.1,446). Details: игнорируется Inbound TCP connection -> Direction + Protocol Local address,service is игнорируется (10.10.50.1,446) -> DestIPaddr + DestPort Remote address,service is игнорируется (10.10.50.4,1684) -> SrcIPaddr + SrcPort Process name is "N/A" -> Application строка полностью -> Msg согласно правилу Trust определяется скриптом SensorIP определяется скриптом Type К сожалению, номера портов известных служб автоматически отображаются на их названия. Т.е., напр., номер порта 80 в логе будет заменён на строку "http". Это порождает некоторые неудобства, усложняя сравнение логов. Способа отключить эту функцию найти не удалось. Перед дальнейшим изучением следует провести обратное отображение на исходные номера портов. Другая встроенная особенность ─ это раскрытие IP-адресов в имена хостов, которую также невозможно отключить через конфигурирование. Сообщения инициализации, подобные приведённым ниже, отображаются на ин- формационные сообщения с параметром Action, установленным в "info": 1/23/2003 9:19:14 Inbound IGMP packets are being blocked 1/23/2003 9:19:14 Inbound IP fragments are being blocked 1/23/2003 9:19:14 NDIS filtering is enabled 1/23/2003 9:19:14 Interactive learning mode is enabled 1/23/2003 9:19:14 Firewall configuration updated: 149 rules Отображение лога траффика "Sygate Personal Firewall" Типичное событие лога траффика "Sygate Personal Firewall" выглядит следу- ющим образом: 32104 11/27/2002 15:55:24 Blocked TCP Incoming 10.10.50.4 1897 10.10.50.3 446· 1 11/27/2002 15:55:11 11/27/2002 15:55:11 Block_all_unknown Таблица трансляции лога траффика "Sygate Personal Firewall": 103 игнорируется 11/27/2002 15:55:14 -> Time Port Scan Minor -> Action Incoming -> Direction TCP -> Protocol 10.10.50.4 -> SrcIPaddr 10.10.50.3 -> DestIPaddr 10 игнорируется 11/27/2002 15:55:10 игнорируется 11/27/2002 15:55:13 игнорируется строка полностью Msg согласно правилу Trust определяется скриптом SensorIP определяется скриптом Type Отображение системного лога "Sygate Personal Firewall" События в системном логе находятся на более верхнем уровне. Они уже скор- релированы и выглядят как события внутренней IDS. Это делает их отличными от логов, рассмотренных выше. Тем не менее, эта информация представляет для нас огромную ценность, поскольку в ней события сжаты в один сигнал тревоги. Типичное событие системного лога "Sygate Personal Firewall" выглядит сле- дующим образом: 103 11/27/2002 15:55:14 Port Scan Minor Incoming TCP 10.10.50.4 10.10.50.3 10· 11/27/2002 15:55:10 11/27/2002 15:55:13 Таблица трансляции системного лога "Sygate Personal Firewall" 32104 игнорируется 11/27/2002 15:55:24 -> Time Blocked TCP Incoming Action + Protocol + Direction 10.10.50.4 -> SrcIPaddr 1897 -> SrcPort 10.10.50.3 -> DestIPaddr 446 -> DestPort 1 игнорируется 11/27/2002 15:55:11 игнорируется 11/27/2002 15:55:11 игнорируется Block all unknown Signature строка полностью Msg согласно правилу Trust определяется скриптом SensorIP определяется скриптом Type 6.2 Совместная работа 6.2.1 Несколько копий одного персонального фаирволла Наличие нескольких копий одного персонального фаирволла, инсталлированных на разные машины, типично для организаций. Это также конфигурация, использо- ванная при тестировании в реальных условиях, описанном в разделе 6.4. Такие конфигурации проще в обслуживании, поскольку есть только один тип программы и можно создать некоторый набор правил, максимально используя конк- ретные возможности. Преимущество такой конфигурации перед единичной инсталля- цией персонального фаирволла в доступе к одной и той же информации с разных машин. Это даёт возможность видеть, была ли атака направлена на одиночную ма- шину или на целую подсеть, что позволяет обнаруживать атаки, вызвавшие на каж- дой отдельной машине лишь несколько событий, но множество ─ на всех вместе. Недостаток заключается в том, что если выбранный персональный фаирволл имеет уязвимость, все машины в сети подвержены ей одинаково. Используя данную уязвимость, атакующий может вывести из строя всю сеть. 6.2.2 Разные персональные фаирволлы Наличие нескольких видов персональных фаирволлов, инсталлированных в под- сети, может иметь преимущество перед вариантом монокультуры, описанном в раз- деле 6.2.1. Преимущество заключается в том, что, вероятнее всего, не все они подвержены одним и тем же уязвимостям. Благодаря этому, атакующему труднее одолеть всю подсеть. Недостаток же в том, что обслуживать разные наборы правил для разных ви- дов персональных фаирволлов накладнее. По этой причине имеет смысл разработка единого формата правил фаирволлов, о чём подробно сказано в гл. 8. Разумеется, обнаружение атак, направленных на множество хостов, в данной конфигурации также возможно. 6.2.3 Фаирволлы персональные и сетевые Конфигурация, содержащая персональные и сетевые фаирволлы в одной подсе- ти, какую-либо дополнительную информацию не обеспечивает. Но, с помощью фаир- воллов персональных появляется возможность проверить, действительно ли сетевые отфильтровывают то, что должны. Напр., если фаирволлу сетевому задано блокиро- вать весь Telnet-траффик из Интернета в интранет, а фаирволл персональный со- общает о входящем Telnet-траффике с IP-адресов вне интранета, это говорит о том, что что-то работает не так. Либо сетевой фаирволл имеет брешь, либо ка- кая-то из внутренних машин траффик подделывает. Это даёт отправную точку для дальнейшего расследования. 6.2.4 Персональные фаирволлы и системы обнаружения вторжений Данная конфигурация, вероятно, ─ лучшая из возможных. Сетевая система об- наружения вторжений [network-based intrusion detection system (NIDS)] выявляет атаки через поиск в траффике шаблонов. Это делает возможной точную идентифика- цию типа атаки. Пригодная для корреляции, информация из логов персонального фаирволла позволяет затем проверить подозрительные события. Напр., если датчи- ки IDS сообщают о компьютерном черве Nimda, попытавшемся получить доступ к ох- раняемым машинам, то персональный фаирволл на подвергшейся машине также должен сообщить о событии на соответствующем порту. Если какое-либо из двух сообщений отсутствует, это основание для проведения дальнейшего отдельного расследова- ния. Может случиться так, что атакующий внедряет в IDS сигналы тревоги с целью перегрузить её. В этом случае персональный фаирволл ни о чём не сообщит. Или может быть так, что атакующий повредил датчики IDS и блокирует сообщения. 6.3 Коррелирование 6.3.1 Черви Интернета Вероятно, наиболее частая угроза из Интернета в наше время ─ это компью- терные черви [13]. Часто они приходят с e-mail-сообщениями и, будучи активиро- ваны, пытаются распространяться, используя различные способы, такие как само- рассылка другим жертвам в e-mail-сообщениях, поиск сетевых ресурсов, открытых для совместного доступа, или уязвимых машин. Персональный фаирволл в этом случае может помочь чрезвычайно, поскольку предотвратит распространение червя, блокируя ему доступ к сети. Далее, он за- несёт название приложения, являющегося червём, в лог. С консоли может быть оп- ределено правило, требующее сообщать названия конкретных приложений. Это сра- ботает, если название червя известно и варьирует незначительно. Но это будет работать, и когда название неизвестно. Если подозрительное приложение пытается получить доступ в Интернет непрерывно, персональный фаирволл будет каждый раз препятствовать ему и генерировать событие. Простое правило позволяет перехва- тывать эти события и поднимать тревогу по достижении некоторого порога. Если только пользователь не даст этому приложению права доступа, эта мера будет ус- пешно работать. Тем не менее, персональный фаирволл предотвратить заражение машины не мо- жет, если агрессивная программа поступила в неё каким-либо санкционированным образом, напр., вложением по e-mail. В этом случае на этапе раннего обнаруже- ния может помочь только антивирусный сканер. 6.3.2 Сканирование портов Сканирование портов само по себе опасности не представляет и в наше время встречается нередко. Однако, оно часто является первым шагом в атаке, и за ним желательно следить. С помощью персонального фаирволла существует возможность отслеживать ска- нирование портов машины. Если машин с инсталлированными персональными фаирвол- лами много, появляется также возможность отслеживать сканирование IP. За ним скрываются обычные сканирования портов, последовательно повторяемые для мно- жества IP-адресов. Если проверенных одновременно портов получателя немного, определить, был ли это червь или сканирование портов, часто затруднительно, но сканирование часто затрагивает более пяти портов, что червь делает редко. Сканирование портов может быть легко обнаружено при возможности отслежи- вания всех запросов с удалённой машины к целевой. Эти события требуется только проанализировать. Не все события будут иметь статус блокированных, поскольку некоторые из сканированных портов могут находиться в процессе использования и поэтому быть открытыми. Это означает необходимость исследовать события незави- симо от их статуса, из-за этого придётся включить регистрирование также и па- кетов принятых, и это может привести к накоплению в логе большого количества данных. Поскольку атакующий заинтересован в результате, исходящий IP-адрес скани- рования портов всегда будет один и тот же. По крайней мере, так принято счи- тать. Но с появлением технологий слепого сканирования типа Idlscan стало воз- можным сканирование удалённой машины без отправки пакетов непосредственно ей [9]. Сочетание этих приёмов с несколькими различными промежуточными [relay] хостами делает возможным сканирование целевой системы с разных IP-адресов, не выдавая реальный IP-адрес источника в каждом регистрируемом сообщении. Это де- лает определение настоящего источника атаки практически невозможным. В некоторых случаях возможны ситуации, когда атакующий получается даже больше информации, чем обычно. Напр., персональный фаирволл, который позволяет пользователю определить доверяемый IP-адрес и разрешить траффику с него прохо- дить беспрепятственно, может оказаться жертвой трюка, раскрывающего информацию о функционирующих службах. Если атакующий знает, какая машина доверяемая, он может задействовать эту машину для осуществления скрытого Idlscan против фаир- волла. Последний блокировать пакеты с доверяемого хоста не будет, что может привести к утечке информации о действительном состоянии портов. Это делает возможным распределённое сканирование портов из множества источников, так что для проверки открытости портов одной целевой машины используются разные источ- ники. С этой целью могут быть использованы даже веб-сервисы типа "Hexillion" [10]. Изощрённый сканнер портов не будет перебирать их в линейном порядке. В сочетании с тем, что разных атакующих могут интересовать разные порты, это де- лает бессмысленными попытки отслеживать в поисках сканирования портов их ли- нейные последовательности. Из этих соображений вытекают следующие критерии. Признаком сканирования портов является контакт с большим количеством разных портов (первый признак) за короткий отрезок времени (второй признак). Признаки должны рассматриваться с учётом условий конкрет- ной системы. Относительно проблем, рассмотренных выше, нельзя утверждать, что все со- бытия сканирования портов должны иметь один и тот же источник ─ скорее наобо- рот. Тем не менее, добросовестный подход предполагает передачу движку, анали- зирующему событие, всех доступных данных. Может случиться, что скрыть свой ре- альный IP-адрес атакующий забыл. Поскольку гарантировать подлинность IP-адреса атакующего никогда нельзя, следует быть осторожным с функциями автоматической блокировки. Если атакующий узнает, что при каждой атаке система блокирует доступ к целевой машине на один час, он сможет воспользоваться этим против охраняемой системы. Напр., атакую- щий может сымитировать сканирование портов так, что оно будет казаться проис- ходящим с DNS-сервера жертвы. Персональный фаирволл, как следствие, автомати- чески блокирует DNS на один час, блокируя тем самым использование охраняемой машиной DNS-сервера. 6.3.3 DoS-атаки DoS-атака (denial of service ("отказ в обслуживании")) обычно пытается перегрузить целевую машину огромным количеством фиктивных пакетов, так что та прекращает отвечать на санкционированный желательный траффик. Поскольку со стороны цели атакующий заинтересован в полном отсутствии ответов, эта атака рассматривается как односторонняя ─ обратная связь в ней отсутствует. Это объ- ясняет, почему в процессе DoS-атак часто используются фиктивные пакеты. Провести различие между сканированием портов и DoS-атаками против служб TCP, такими как SYN-затопление, очень трудно, поскольку они порождают одни и те же сообщения. SYN-затопление может отличаться большим количеством пакетов, но если некто сканирует все TCP-порты, это также может порождать огромную мас- су траффика. Поэтому точную причину определить невозможно, установить можно только факт атаки. 6.4 Эксперимент в реальных условиях Эксперимент в реальных условиях проводился следующим образом. Было найде- но несколько, согласившихся принять в нём участие, пользователей Windows из "IBM Zurich Research Lab". Они должны были использовать "Symantec Desktop Fi- rewall" в течение недели и передавать полученные логи и свои наборы правил. Последние требовались потому, что пользователи имели возможность создавать правила новые, а правила по умолчанию отключать. Это могло усложнить задачу тем, что на некоторых машинах события могли избежать регистрации, из-за того, что набор правил был изменён так, чтобы этого не происходило. Задачей экспери- мента вцелом была проверка, будет ли идея о коррелировании, рассмотренная в гл. 6, иметь практический смысл и сможет ли она работать в реальном сценарии. По окончании недели были собраны логи и файлы наборов правил 12 человек, находившихся в одной подсети "IBM". После перевода логов в унифицированный формат событий написанным в рамках данной работы скриптом на Perl, было собра- но ок. 6000 сигналов тревоги. Для облегчения обработки данные были загружены в таблицу "Excel". Теперь появилась возможность произвести операции, основанные на предопределённых правилах, обычно осуществляемые консолью безопасности. Данные были проанализированы вручную на предмет работоспособности задейство- ванных методов и возможной необходимости их адаптации. Через поиск событий с одинаковыми исходящим IP-адресом и входящим портом, просматривались подозрительные сигналы тревоги и отфильтровывались все исходя- щие соединения так, чтобы оставались только входящие события, удовлетворяющие вышеописанным критериям. Дополнительно было установлено окно времени, выбираю- щее события, произошедшие в пределах 1 мин. Найденные таким образом группы со- бытий содержали множество крайне подозрительных сигналов тревоги, таких как показанные в таблице ниже (IP-адреса анонимизированы и ненужные поля удалены для лучшей читабельности.). Time SrcIP SrcPort DestIP DestPort 16:53:11 10.10.10.66 2703 10.10.10.134 80 16:53:14 10.10.10.66 2703 10.10.10.134 80 16:53:16 10.10.10.66 2728 10.10.10.159 80 16:53:16 10.10.10.66 2728 10.10.10.159 80 16:53:16 10.10.10.66 2771 10.10.10.222 80 16:53:19 10.10.10.66 2771 10.10.10.222 80 Из таблицы видно, что машина с IP-адресом 10.10.10.66 сканировала нес- колько машин в сети на TCP-порту 80. Если подсчитать соответствующие разности между исходящими портами и аналогичными им IP-адресами получателя, то они ока- зываются равными. В этом можно убедиться следующим расчётом: 2728 ─ 2703 = 25 = 159 ─ 134 2771 ─ 2728 = 43 = 222 ─ 159 Данный факт указывает на то, что атакующий, вероятно, осуществлял последова- тельное сканирование в диапазоне IP-адресов, по крайней мере, от 10.10.10.134 до 10.10.10.222. IP-адрес 10.10.10.135 сканировался с исходящим портом 2704, IP-адрес 10.10.10.136 ─ с исходящим портом 2705 и т.д. Трудность в том, что имея доступ только к логам персонального фаирволла, приведённым в таблице вы- ше, невозможно сказать, было ли это сканирование портов или же компьютерный червь искал уязвимые веб-серверы. Поскольку большинство новейших компьютерных червей ищет новые жертвы в случайном порядке, а не последовательно, можно предположить, что это было обычное сканирование портов. Однако утверждать на- верняка нельзя. Второй использованный поисковый шаблон заключался в просмотре отсортиро- ванных по времени событий с одинаковыми IP-адресами и входящими портами через небольшое временное окно. Часть обнаруженных сигналов тревоги приведена в таб- лице ниже. Time SrcIP SrcPort DestIP DestPort 10:12:11 10.10.10.66 1511 10.10.10.134 80 10:12:14 10.10.10.66 1511 10.10.10.134 80 14:53:42 10.10.10.88 1254 10.10.10.134 80 14:53:45 10.10.10.88 1254 10.10.10.134 80 17:23:31 10.10.10.22 1397 10.10.10.134 80 17:23:34 10.10.10.22 1397 10.10.10.134 80 Во всей совокупности данных было найдено ок. 40 случаев явной последова- тельности событий, содержавших 2 сигнала тревоги с задержкой в 3 с в диапазоне исходящих портов от 1100 до 1600. Все они были нацелены на один входящий порт, являющийся портом веб-сервера TCP 80. Аналогичные последовательности находи- лись и для других входящих IP-адресов, каждый раз по одному шаблону. Это наводит на предположение о том, что данные события могли быть порож- дены компьютерным червём, проверяющим на предмет работающих веб-серверов слу- чайные IP-адреса. К сожалению, как было сказано ранее, доступа к логу сниффера за исследуемый отрезок времени не было, и поэтому проверить, был ли это компь- ютерный червь, не представлялось возможным. Для получения точных выводов нужны иные источники информации, сохраняющие полное содержимое пакетов. Тем не ме- нее, данные адреса можно квалифицировать как подозрительные и даже опасные. Теперь можно предпринять дальнейшие шаги для проверки этих машин. Также наблюдались аналогичные последовательности, группирующие события по 3 вместо 2 ─ вероятно, относящиеся к различным компьютерным червям. Каких-либо недостатков конфигурации сети, могущих быть выявленными по ис- следованным логам, обнаружено не было. Просмотр наборов правил показал, что большинство пользователей по-прежнему использовало одни и те же правила по умолчанию. К ним было добавлено несколько правил для отдельных приложений, ко- торые на соответствующих машинах, очевидно, использовались. Данная информация может быть также задействована для раскрытия фактов использования программного обеспечения запрещённого на этих машинах. 6.5 Выводы Логи персональных фаирволлов для коррелирования событий атак пригодны. Для повышения их ценности, их можно усовершенствовать в различных направ- лениях. Функцию ведения логов следует изменить таким образом, чтобы облегчить дальнейший анализ централизованным коррелирующим движком. Это может быть дос- тигнуто отсылкой событий как syslog-сообщений или записью их в файл в легко интерпретируемом формате. Другим важным усовершенствованием является реализа- ция фильтрации, проверяющей пакеты с сохранением состояния. С этой функцией в сообщение о событии станет возможным добавлять больше полезной информации, напр., строку запроса при попытке установления соединения с веб-сервером. Бо- лее того, она позволит устанавливать более точные правила, способные учитывать содержимое пакетов. Пока же перечисленные выше вопросы не решены, предпочтительной, по мнению автора, конфигурацией является сотрудничество персональных фаирволлов с систе- мой обнаружения вторжений. В нём сочетаются хорошие возможности идентификации атак системой обнаружения вторжений с возможностью защиты от неизвестных атак персональным фаирволлом. Если затем полученные сообщения проанализированы в одном месте и скоррелированы, большинство атак может быть обнаружено и предот- вращено. Глава 7 Заключение В наше время, когда множество людей имеет постоянное подключение к Интер- нету и всё большее и большее их число пытается предпринимать атаки и вредить другим, опасность из Интернета растёт. Разумеется, средства обороны также со- вершенствуются, и для защиты систем появляются новые продукты. Персональные фаирволлы являются одним из таких новых видов продуктов, заполняющим пробел в цепочке средств защиты. Предназначенные преимущественно для конечных пользова- телей, они могут также эксплуатироваться и в организациях на персональных ма- шинах работников. Данная работа состоит из двух частей. Первая демонстрирует огромное раз- нообразие атак против персональных фаирволлов, как из локальных, так и из уда- лённых источников. Персональные фаирволлы хорошо справляются с работой по за- щите от входящих атак с удалённых машин, таких как DoS-атаки. Однако, некото- рые из локальных атак персональным фаирволлом в нынешнем определении предот- вращены быть не могут. Поскольку пользователь в процессе работы персонального фаирволла имеет возможность изменять набор правил, для инструмента агрессии, запущенного пользователем, всегда будет оставаться возможность проделать те же изменения, что и пользователь. Эта проблема может быть решена через исполнение процесса персонального фаирволла с правами администратора, как уже делает большинство антивирусных сканнеров. Однако, тогда пользователь лишится возмож- ности конфигурировать персональный фаирволл "на ходу". В этом заключается ос- новная проблема персональных фаирволлов: они работают в системе, которая может быть атакована изнутри. Поэтому не существует возможности предпринять что-ли- бо, чего злонамеренный пользователь с правами администратора не мог бы изме- нить. Это относится к логам, наборам правил, процессу инициализации. С другой стороны некоторые виды атак могут и должны персональными фаирволлами предот- вращаться, такие как DoS-атаки по неконтролируемым протоколами типа IGMP. Поэ- тому в персональных фаирволлах должен быть реализован фильтр, проверяющий па- кеты с сохранением состояния. Вторая часть работы раскрывает полезность персональных фаирволлов как до- полнительного источника информации. Вцелом, персональные фаирволлы можно расс- матривать как дешёвый способ получения дополнительных логов датчиков уровня хоста распределённых систем. Многие организации используют персональные фаир- воллы, но производимыми ими логами не пользуются. С помощью средств, созданных в данной работе, существует возможность экспортировать эти логи в описанный в данной работе унифицированный формат событий так, чтобы они могли затем быть интегрированы в существующую структуру безопасности. Использование общего адаптера логов делает возможным отправку событий для дальнейшего анализа в коррелирующий движок, напр., консоль "IBM Tivoli Risk Manager". На этом объе- диняющем этапе могут быть применены правила коррелирования с логами других персональных фаирволлов или IDS, так чтобы никакая информация не пропала. По- лученная информация может существенно способствовать принятию решения системой IDS. За счёт коррелирования событий лога можно повысить уровень надёжности: устраняя ложные тревоги и повышая приоритет реальных. Следует заметить, что данные логов персонального фаирволла информации, достаточной для точной иден- тификации атак, сами по себе не обеспечивают. Напр., когда мы имеем атаку на TCP-порту 80, известен факт атаки, но нельзя сказать уверенно, был ли это ком- пьютерный червь, сканирование портов или же какой-то пользователь нечаянно ввёл наш IP-адрес в своём браузере. Для прояснения ситуации необходимо провес- ти коррелирование событий с пакетными логами или с логами IDS, позволяющими анализировать содержимое пакетов. Однако, данная возможность может быть интег- рирована в будущих версиях персональных фаирволлов. Данное применение персональных фаирволлов также видно из эксперимента в реальных условиях, где несколько идентичных инсталляций персональных фаирвол- лов в сети было протестировано в течение недели. Полученные логи дали возмож- ность идентифицировать и классифицировать различные атаки, произошедшие за этот отрезок времени. Они включали компьютерного червя, который пытался расп- ространяться в сети; адварь, пытавшуюся отослать информацию поставщику; и ска- нирование портов сети атакующим в поисках возможных уязвимостей. Глава 8 Перспективы Данная работа может быть продолжена в различных направлениях. Один из первоочередных потенциальных шагов ─ это изучение коррелирующего движка, собирающего полученные события, и проверка того, как этот новый источ- ник информации влияет на качество обнаружения и действительно ли он уменьшает количество ложных срабатываний. Анализ информации логов персональных фаирвол- лов, не рассмотренной в данной работе, такой как время запуска фаирволла, так- же может представлять интерес, скорее, для проверки общего здоровья системы или как метод проверки, не была ли система перезагружена или изменена несанк- ционированным образом. По крайней мере, это сведения, которые используются редко, но легко доступны и могут дать об охраняемой системе информацию. Другое направление ─ проверить, были ли решены в последующих версиях проблемы, упомянутые в заключениях, такие как улучшение защиты от входящих DoS-атак или предотвращение изменений локального набора правил и логов. Кроме того, может представлять интерес разработка концепции идеального персонального фаирволла и возможно, её реализация, поскольку потребность в хо- роших, надёжных, стабильных и притом удобных в обращении персональных фаирвол- лах огромна. Этот идеальный персональный фаирволл должен решить проблемы, свя- занные с тем, что он может быть атакован из системы, в которой они работает. Кроме того, он иметь функции типа защиты от исходящего спуфинга, предотвраще- ния изменения набора правил и защиту от DoS-атак. Неразрешённым также остаётся вопрос, возможно ли определение версии пер- сонального фаирволла, инсталлированного на целевой машине, и что разрешено его правилами. Эта информация может способствовать более изощрённым атакам, ис- пользующим после первичной атаки специфические уязвимости персональных фаи- рволлов. Ещё один вопрос для рассмотрения ─ это проверка возможности подготовки правил персонального фаирволла в унифицированном формате с последующей транс- ляцией его в конкретные форматы различных фаирволлов и инсталляцией правил в их собственные наборы. Идея, лежащая в основе, ─ наличие одного общего файла правил и применение его ко всем различным видам фаирволлов, инсталлированных в данной среде. Библиография 1. M.Ranum. Using Desktop Firewalls as Basic IDSes. ─ http://www.infosecurit· ymag.com/2002/oct/cooltools.shtml, 2002. 2. Log File Analyzer Project on Security Focus. ─ http://analyzer.securityfo· cus.com, 2003. 3. S.Boran. An Analysis of Mini-Firewalls for Windows Users. ─ http://www.bo· ran.com/security/sp/pf/pf_main20001023.html, 2003. 4. G.Bahadur. Article of Attacks Against Personal Firewalls. ─ http://www.in· fosecuritymag.com/articles/july01/cover.shtml, 2001. 5. Leak Test Against Desktop Firewalls. ─ http://www.pcflank.com/art21.htm, 2002. 6. DShield, Distributed Intrusion Detection System Project. ─ http://www.dsh· ield.org, 2003. 7. General Informations About Computer Viruses. ─ http://www.virusbtn.com, 2003. 8. D.Moore, V.Paxson, S.Savage et al. The Spreading of the Sapphire/Slammer Worm. ─ http://www.caida.org/outreach/papers/2003/sapphire/sapphire.html, 2003. 9. Fyodor. Information About idlScans with Nmap. ─ http://www.nmap.org/nmap/ idlescan.html, 2002. 10. Hexillion's Online Information Gathering Tool. ─ http://www.hexillion.com, 2003. 11. ProcessXplorer, a Process Explorer from Sysinternals. ─ http://www.sysint· ernals.com, 2002. 12. T.Bird. This is a Collection of Links Related to Log File Anayzer. ─ http: //www.counterpane.com/log-analysis.html, 2002. 13. Analysis and Surveys About Computer Security. ─ http://www.cert.org/analy· sis/, 2002. 14. R.Graham. Explains Alarms Seen in Firewall Logs. ─ http://packetstormsecu· rity.org/papers/firewall/firewall-seen.htm, 2000. 15. M.Rauen. Website with Low Level System Programming Source Code. ─ http:// www.madshi.net, 2002. 16. W.Hua, J.Ohlund, B.Butterklee. Microsoft's Introduction to Layered Service Provider. ─ http://www.microsoft.com/msj/0599/layeredservice/layeredservi· ce.htm, 1999. 17. D.Brent Chapman, Elizabeth D.Zwicky. Building Internet Firewalls. ─ O'Reilly & Associates, 1995. 18. DiamondCS. How to Shutdown Zonalarm from a Batch File. ─ http://www.diamo· ndcs.com.au/alerts/zonedown.txt, 2000. 19. L.Bowyer. Article of Tunneling with HTTP Protocol and Stegano Messages in Pictures. ─ http://www.networkpenetration.com/protocol_steg.html, 2002. 20. IGMP Fragmentation Bug. ─ http://www.iss.net/security_center/static/2341. php: Internet Security Systems, 1999.