Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Тестируем системы предотвращения вторжений уровня сети

Майк Фратто

Пока вы не установили “заплаты”, устройства NIP могут предупредить вас о предпринимаемых атаках на вашу сеть и предотвратить по крайней мере некоторые из них.

Вполне вероятно, что вы уже попали в поле зрения маркетинговых служб производителей систем предотвращения вторжений уровня сети (Network Intrusion-Prevention — NIP). Лично нам уже звонили пару раз. И хотя мы уверены в том, что обещаемая ими абсолютная защита от всевозможных атак, как минимум, преувеличение, логика подсказывала, что бахвальства в заявлениях производителей все же меньше, чем правды. Поэтому мы и решили попросить их прислать нам свои устройства NIP на испытания.

В число участников тестирования средств предотвращения вторжений уровня сети мы включили лишь устройства, которые инсталлируются “в линию” (хотя и использовали в ходе испытаний консольный режим их подключения), не требуют изменения IP-адресации и обнаруживают/блокируют атаки на основе известных сигнатур. Нас не интересовали системы обнаружения вторжений, контролирующие трафик и динамически изменяющие правила межсетевого экрана (МЭ), поскольку поддержка МЭ в них нередко ограничивается лишь продуктами Check Point FireWall-1 и Cisco PIX, — в конце концов, ведь существуют еще и другие МЭ. Кроме того, как мы уже объясняли в предыдущей статье (см.: Сети и системы связи. 2003. № 14. С. 86), динамическая настройка правил МЭ — вещь крайне нежелательная.

В результате потенциальными участниками тестирования стали компании NetScreen Technologies, Network Associates и TippingPoint Technologies. Впоследствии TippingPoint отклонила наше предложение принять участие в испытаниях, сославшись на то, что у нее нет лишнего устройства, которое она могла бы отправить нам, поскольку все имевшиеся у нее в наличии уже отгружены покупателям.

В итоге мы инсталлировали продукты IDP 500 компании NetScreen и McAfee IntruShield 4000 компании Network Associates в нашей лаборатории Real-World Labs Сиракузского университета и досконально протестировали их производительность, возможности обнаружения атак, управления и средств генерации отчетов (см. “Как мы тестировали устройства NIP”). Результаты нас приятно удивили: если не считать немногочисленных случаев “неадекватного” поведения устройств, работа с ними в целом является достаточно простой.

Полную версию данной статьи смотрите в 1-ом номере журнала за 2004 год.

Установка

При инсталляции сенсора каждого продукта использовалось как сквозное, так и консольное его включение. Мы сконфигурировали устройства для работы с одним управляющим сервером и установили на рабочую станцию управляющие клиенты. Наши требования были простыми: продукты должны точно определять атаки и аномалии трафика при минимуме ложных срабатываний (false positives) и отказов (false negatives).

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

Мы не наблюдали ложных срабатываний в нашей лаборатории, поскольку трафик в ней генерировался в строгом соответствии с тестовыми сценариями. Однако, когда мы разместили устройства в нашей реальной сети, мы сразу же стали свидетелями многочисленных ложных срабатываний, вызываемых аномалиями протоколов — например, такими, как TTL-параметр RIP-пакета, равный 255, и пр. Тонкая настройка устройств NIP позволила существенно снизить частоту ложных срабатываний.

Хотя, чтобы ненароком не запретить легитимный трафик, нам приходилось очень тщательно настраивать блокировки, мы убеждены в том, что оба продукта способны отразить все известные атаки. Однако вряд ли эти же продукты, “умеющие” выявлять аномалии протоколов, обладают достаточным для обнаружения неизвестных атак “интеллектом”. Производители приложений не всегда разрабатывают стеки сетевых протоколов в полном соответствии со стандартами, а это значит, что легитимный трафик может быть опознан системой предотвращения вторжений как аномальный и враждебный. В связи с этим следует особо подчеркнуть один важный момент: вы должны знать, из каких основных компонентов состоит враждебный трафик, и для его распознавания и блокировки использовать уже существующие сигнатуры или же вновь разработанные собственные.

Итак, нужно ли вам покупать устройство NIP? Если вы еще только планируете внедрить у себя IDS-систему или заменить уже имеющуюся у вас, то мы рекомендуем вам использовать вместо этого устройство NIP, которое по сравнению с IDS-системами обладает такими преимуществами, как простота развертывания, довольно точное соответствие заявленным техническим характеристикам и гибкое интегрирование с сетью. Кроме того, с NIP вы получаете возможность блокирования атак. Тем не менее мы не советуем использовать устройство NIP в дополнение к уже развернутой в вашей сети системе IDS. Лучше потратьте деньги на “залечивание” уязвимых мест в своих серверах — во всяком случае это то, чем вам так или иначе следует заниматься, и самый верный путь к обеспечению защиты ваших данных, поскольку, если даже враждебный трафик все же проникнет в вашу сеть, подновленные хосты будут сохранять “стойкий иммунитет”.

Настройка

Тщательно сконфигурированные правила обнаружения вторжений позволяют снизить число ложных срабатываний устройства NIP, предполагая индивидуальную настройку сигнатур атак, полностью соответствующую требованиям конкретной сетевой среды. К примерам тонких настроек относятся избирательная активизация сигнатур атак, имеющих прямое отношение к вашим серверам (если сервер Apache в вашей сети не инсталлирован, то кому нужны предупреждающие сообщения, специфичные для этого сервера? Думаем, что никому), и игнорирование предупреждающих сообщений, поступающих от некоторых хостов или подсетей. Например, сканер уязвимости “заставит” устройство NIP “мигать, как новогодняя елка”, поэтому следует изначально проигнорировать атаки с этого хоста. ПО обнаружения сетевых устройств, использующее протокол ICMP, сканеры портов, протоколы NetBIOS и SNMP, также будет генерировать значительное число предупреждающих сообщений.

Хотя ПО управления IDP Manager компании NetScreen и IntruShield Manager компании Network Associates в равной степени наделены возможностями тонкой настройки, в них реализованы в корне различные подходы, каждый из которых имеет существенные минусы. С одной стороны, IDP Manager, основанный на всем хорошо знакомой парадигме правил, достаточно прост в использовании, но может оказаться перегруженным этими самыми правилами. С другой стороны, IntruShield устанавливает индивидуальную политику безопасности для каждого субинтерфейса (виртуальной IDS-системы), которых тоже может оказаться чересчур много. Мы предпочитаем подход, основанный на правилах, хотя и не отрицаем того факта, что базы правил могут чрезмерно усложняться. Индивидуальная политика более проста для понимания, но требует многократных изменений, что, в свою очередь, вносит дополнительные сложности.

Снижение числа отказов (или пропусков реальных атак) — это уже несколько иная проблема.

К факторам, способствующим увеличению числа пропусков атак, относятся несвоевременность обновления БД сигнатур, плохо написанные сигнатуры и проверка пакетов в отрыве от контекста протокола (nonstateful packet inspection). Если для некоего программного компонента взлома отсутствует сигнатура, он обнаруживаться не будет, а поэтому совершенно очевидно, что своевременное обновление сигнатур атак имеет первостепенное значение. Конечно, анализ протокола позволяет выявлять неизвестные программные компоненты взлома — в частности, путем обнаружения таких нарушений, как, например, пересылка команд оболочки в заголовках HTTP или SMTP. Однако анализ протокола может также легко приводить и к увеличению частоты ложных срабатываний. Таким образом, хотя основанный на анализе протокола метод и можно использовать для “раннего оповещения”, он тем не менее не является надежным с точки зрения предотвращения атак.

Альтернативой обновлению сигнатур является использование собственноручно создаваемых сигнатур. Хотя их разработка — не простое дело и самое лучшее — доверить ее профессионалам, некоторые знания в области написания сигнатур позволят вам блокировать быстро распространяющихся “червей” и создавать собственные сигнатуры для своей сетевой среды. В каждом из протестированных нами продуктов предлагается свой собственный метод создания сигнатур, на освоение которого вам потребуется какое-то время, но мы считаем, что соответствующие разделы документации на оба устройства NIP изложены подробно и доходчиво и окажутся вам весьма полезными.

Метод контекстной проверки пакетов реализован практически во всех IDS-системах, и устройства NIP не являются здесь исключением. Обычная уловка, к которой прибегают злоумышленники, пытаясь “обмануть” основанные на сигнатурах системы, — это фрагментирование пакетов. Чтобы завуалировать атаки, основанные на протоколе HTTP, чаще всего используют кодирование URL-ссылок. Повторная сборка пакетов и приведение к стандартному виду протоколов обеспечивают их распознавание IDS-системой. Как IDP, так и IntruShield выполняют контекстную проверку пакетов и нормализуют трафик для его сопоставления с сигнатурами атак, так что все ухищрения злоумышленников обычно оказываются бесполезными.

Ложные срабатывания

Мы не ожидали от устройств NIP ничего сверхъестественного. Единственное, что они должны были “уметь” делать, — это правильно обнаруживать направленные против них атаки, в том числе и тогда, когда мы использовали такие хитрости, как фрагментирование и перемешивание пакетов. И по правде говоря, мы в этих устройствах нисколько не разочаровались. В нашей тестовой среде они работали безукоризненно, легко обнаруживая все атаки, которым мы их подвергали. Нас обескуражило только одно: довольно неожиданные ложные срабатывания, которые стали появляться после того, как мы инсталлировали продукты в нашей реальной сети.

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

Затем устройство IDP сообщило, что наш сервер NTP осуществляет UDP-сканирование удаленного хоста. С целью анализа трафика между сервером NTP и удаленным хостом мы использовали ПО EtherPeekNX компании WildPackets. И что же? Трафик, который IDP идентифицировал в своих предупреждающих сообщениях как трафик UDP-сканирования портов, на деле оказался обычным трафиком NTP!

Устройство IntruShield тоже имело свои причуды. Например, оно выдавало предупреждения о том, что отсылаемые по широковещательному адресу сообщения SNMP (UDP 162) якобы являются запросами NetBIOS и что SNMP-ответы — это еще одна форма UDP-сканирования портов. С трудом настроив устройство IntruShield (вот уж поистине бесконечный процесс!), мы наконец-то сумели выследить всех “мерзавцев”, стремящихся проникнуть в нашу сеть.

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

Тема для разговора

Прежде чем приступить к блокированию трафика, нам пришлось изучить предупреждающие сообщения и журнал регистрации событий. Когда на вас обрушивается непрерывный поток событий, управление информацией приобретает первостепенное значение. Особенно преуспел здесь продукт IntruShield — его простые, но мощные инструментальные средства позволяли фильтровать сообщения и углубленно исследовать отдельные события. Последних в журнале IntruShield у нас накопилось более 15 тыс., и мы смогли легко отсортировать их по протоколам. За семь недель непрерывного мониторинга IntruShield зафиксировал 33 атаки. Таблицы событий отсортировываются по любому столбцу, при этом для некоторых из них по умолчанию предусмотрен захват пакетов. Вам потребуется инсталлировать продукт Ethereal или какой-нибудь другой анализатор протоколов, способный читать файлы pcap.

IDP позволяет настраивать фильтры для просмотра событий реального времени, обеспечивая тем самым отсев избыточной информации. Если вы знаете, какую информацию ищете, то легко найдете ее.

К сожалению, мы смогли просмотреть детальную информацию не о всех обнаруженных атаках, а лишь о тех, которые попали в первую десятку списка. По нашему мнению, отчеты устройства IDP оставляют желать лучшего. Кроме того, продукт IDP лишен возможности планировать регулярную генерацию отчетов — такой функциональностью обладает продукт IntruShield.

Всестороннее тестирование устройств показало, что оба они способны предпринимать вполне адекватные меры по защите сети от атак. При сквозном включении IntruShield и IDP в сеть оба могут сбрасывать пакеты и потоки данных. Для тех сообщений, которые генерировались в нашей реальной сетевой среде и имели, по нашим оценкам, довольно низкую вероятность ложного срабатывания, мы активизировали возможность автоблокировки атак. В их число входили атаки с применением закодированных URL-ссылок, атаки типа directory traversal и удаленное выполнение команд. Мы не активизировали автоблокировку атак, для которых вероятность ложного срабатывания была ощутимой. Ваш уровень комфорта, а следовательно, и полезность этих устройств могут варьироваться в зависимости от конкретной сетевой среды.

Титул победителя мы присудили продукту McAfee IntruShield 4000 компании Network Associates в основном за его отличные возможности обнаружения атак и генерации отчетов. Однако организациям они обойдутся недешево. Предприятиям, интенсивность сетевого трафика которых не превышает 500 Мбит/с, определенно имеет смысл обратить внимание на продукт NetScreen-IDP. Его база правил, во многом аналогичная базе правил МЭ, вероятно, знакома большинству сетевых администраторов, а средства генерации отчетов после некоторой настройки оказались в конце концов не такими уж и плохими.

McAfee IntruShield 4000 компании Network Associates

Очень высокая производительность, надежное обнаружение атак и превосходные инструментальные средства анализа — вот что является “лицом” продукта IntruShield 4000. Для того чтобы досконально освоить его управляющую консоль, нам потребовалось несколько дней, зато, после того как мы изучили ее, что называется вдоль и поперек, поиск нужных нам данных не представлял никакого труда.

В целом конфигурирование устройства является простым делом, но, когда мы приступили к процедуре настройки политики безопасности для каждой группы хостов, то нашли эту процедуру на удивление громоздкой и неуклюжей. Кроме того, невозможность задавать произвольные диапазоны адресов и применять несколько вариантов политики к одним и тем же хостам тоже усложнят управление устройством. А вот с обработкой трафика интенсивностью вплоть до 1,2 Гбит/с (предел наших возможностей) продукт IntruShield, как показало тестирование, прекрасно справлялся, причем вносимая им средняя задержка составляла всего 1—2 мс.

Устройство IntruShield можно инсталлировать в режиме сквозного включения, используя пару портов, или в режиме консольного включения. IntruShield сбрасывает пакеты и потоки только при сквозном включении в сеть; при консольном он блокирует трафик лишь путем сброса в исходное состояние протокола TCP или посредством сообщений ICMP о недоступности хоста. Порты устройства можно сконфигурировать таким образом, чтобы все они использовали различные методы захвата трафика — уровень гибкости, нехарактерный для устройства IDP.

В терминологии IntruShield политике безопасности соответствует специальный файл, позволяющий задавать сигнатуры атак и включать и выключать функцию обнаружения атак типа отказ в обслуживании (Denial of Service — DoS). Каждой атаке ставится в соответствие отдельное событие — такое, как появление закодированных URL-ссылок или наличие посторонних данных в заголовке протокола. Атаки группируются по протоколам, поэтому проанализировать политику безопасности и понять, обнаружение каких атак в ней активизировано, не составляет большого труда, к сожалению, компания Network Associates не предоставляет доступа к исходным кодам сигнатур атак. Когда мы поинтересовались у представителей компании, почему такая возможность отсутствует, они заявили нам, что не хотят помогать взломщикам создавать методы обхода устройств сетевой безопасности. Диалог Exploit Alert Detail показывает совпадения сигнатур, соответствующие данному аварийному сообщению, однако эти совпадения, вероятно, являются подмножеством всех возможных совпадений.

Будь у нас время, мы сумели бы разгадать большинство сигнатур, всесторонне проанализировав их, так что компания Network Associates, похоже, попросту темнит. В отличие от нее сигнатуры компании NetScreen доступны для анализа и редактирования — как раз то, что нам и нужно.

Отсутствие достаточной информации о сигнатурах атак быстро стало нас раздражать, поскольку усложняло установление причин совпадения компонентов трафика с сигнатурами в тех случаях, когда последнее было обусловлено аномалиями протокола. Чтобы определить, почему пакеты SNMP воспринимаются как запросы NetBIOS, нам пришлось отправлять результаты трассировки пакетов специалистам компании Network Associates. На решение проблемы и предоставление обновленных сигнатур ей потребовалось несколько дней. Процесс обновления сигнатур автоматизирован, однако осуществить его можно только при заключении контракта на техническую поддержку устройства IntruShield.

Процедура назначения политики безопасности в IntruShield отличается хорошей гибкостью, что является преимуществом этого устройства перед NetScreen-IDP 500. Мы назначали ее как отдельным интерфейсам, так и интерфейсным парам (в случае сквозного подключения устройства). Кроме того, мы задавали политику безопасности для исходящего и для входящего трафика, что позволяло выполнять асимметричное обнаружение атак.

Для настройки политики можно использовать два способа: создать набор ограничивающих пра-вил и обращаться в политике только к тем сигнатурам, которые соответствуют данному набору типов атак, протоколов, ОС, приложений и других критериев. Например, мы создали набор правил, включавший все категории атак против Web-серверов IIS посредством протокола HTTP, и, используя этот набор, определили политику безопасности под названием IIS Web Server Policy. Все сигнатуры, которые не соответствовали данным критериям, в эту политику не включались. Альтернативой использованию наборов правил является включение/выключение опции обнаружения конкретной атаки в политике вручную. Но, если вам нужна политика для симметричного обнаружения атак, вы должны включить или выключить эти опции как для входящего трафика, так и для исходящего.

Варианты политики безопасности применимы к отдельным хостам или группам хостов, однако для IntruShield этот процесс выполнять было гораздо сложнее, чем для IDP. Назначение субинтерфейсов группам хостов осуществляется на основе блоков CIDR или тегов VLAN 802.1Q. К сожалению, к одному и тому же блоку CIDR или виртуальной ЛВС нельзя отнести сразу все хосты, поэтому нам нужно было либо заново конфигурировать IP-адреса, группируя все аналогичные хосты в один блок CIDR, либо индивидуально приписывать каждый хост к субинтерфейсу, используя 32-битовую маску подсети. Мы выбрали второй вариант, так как переназначение адресов — весьма трудоемкая задача. Отметим также, что каждому интерфейсу можно поставить в соответствие лишь один блок CIDR (табл. 3).

У нас на хосте с адресом 192.168.2.40 был установлен “незалатанный” сервер Microsoft SQL Server 2000. Против него мы запустили атаку Resolution Service Stack Overflow, которую в рамках политики, назначенной блоку CIDR 192.168.0.0/16, обнаружило устройство IntruShield. После этого мы запустили ту же атаку против нашей системы Solaris, подключенной к субинтерфейсу с одноименной политикой, назначенной соответствующему блоку CIDR. В результате никакого уведомляющего сообщения мы не получили, поскольку описывающее данную атаку правило в политику Solaris включено не было.

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

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

Функция Alert Viewer позволяет просматривать не только накопленные сообщения, но и сообщения реального времени. На сводных диаграммах представлены сообщения, сгруппированные по степени опасности атак, их частоте, IP-адресам источников и целей. Все диаграммы контекстные и изменяются всякий раз, когда выбирается тот или иной элемент. Например, двойной щелчок мышью на пиктограмме атаки выводит на экран новое окно с относящимися только к ней диаграммами.

Функция Real-Time Attack Details показывает события по мере регистрации каждого из них. После двойного щелчка мышью на соответствующем событии на экране появляется детальная информация, касающаяся этого события, — описание атаки, адреса источника и цели и данные, совпавшие с сигнатурой (если такое совпадение имело место). Для большинства регистрируемых событий выполняется захват пакетов, которые можно проанализировать с помощью анализатора протоколов Ethereal. Некоторые атаки генерировали сразу несколько сообщений. Так, атака типа directory traversal с применением уникода генерировала сразу три сообщения — об атаке посредством закодированных указателей URL-ссылок, об атаке типа directory traversal и о несанкционированном выполнении командного файла cmd.exe.

Окно Real-Time Attack можно “заморозить”, а столбцы таблицы — отсортировать. Функция углубленного анализа делала возможной высокоуровневую категоризацию атак: после выбора опции анализа на экране монитора появлялся список, состоящий примерно из двух десятков обнаруженных атак, отсортированных по частоте. Щелкнув мышью на одной из позиций этого списка, можно вывести на экран информацию, касающуюся только атак данного типа. Все отчеты являются полнофункциональными, и планировщик позволяет осуществлять их генерацию ежедневно или еженедельно.

Продукт IntruShield хорошо работает в качестве системы IDS, а при соответствующих навыках администратора — и в качестве NIP. Отчеты устройства достаточно информативны, и громоздкая на первый взгляд процедура конфигурирования обеспечивает их детальную настройку.

NetScreen-IDP 500 компании NetScreen Technologies

NetScreen-IDP 500 не только обладает многими возможностями, которые есть у более дорогого продукта IntruShield 4000, но он еще и проще в управлении. Используя его основанную на правилах гибкую и простую в настройке политику безопасности, администраторы МЭ будут чувствовать себя как дома. Сенсор IDP, так же как и сенсор IntruShield, может захватывать пакеты при сквозном включении в сеть, при включении через внешний отвод или порт коммутатора. Кроме того, как и McAfee IntruShield 4000, IDP сбрасывает пакеты и потоки в режиме сквозного включения и отправляет команды сброса протокола TCP в исходное состояние или сообщения ICMP о недоступности адресата для блокировки вредоносного трафика в режиме консольного включения.

Вместе с тем средства генерации отчетов у устройства IDP оставляют желать лучшего, да и процесс агрегирования данных является не таким простым, как у IntruShield. Обновление сигнатур осуществляется бесплатно, однако инициируется только вручную.

Компания NetScreen явно стремилась сделать процесс определения политики безопасности в своем устройстве простым и уже как бы привычным для администраторов и, несомненно, добилась в этом больших успехов. В ходе тестирования продукта IDP мы практически не открывали его “Руководство пользователя”. Для определения правил служит набор спецификаторов, таких, как адреса или порты источника и цели. Каждое правило применимо ко всем сенсорам или только к какому-нибудь одному из них. Мы могли задавать одну общую политику безопасности, ставя в соответствие каждому правилу конкретный сенсор, или определять множество ее вариантов, назначая их индивидуальным сенсорам. Во время испытаний мы решили определять индивидуальную политику безопасности для каждого сенсора, поскольку являемся приверженцами принципа “разделяй и властвуй”.

В ходе настройки политики безопасности для нашей производственной сети парадигму IDP, основанную на правилах, мы нашли особенно полезной. Цель состояла в том, чтобы активизировать широкомасштабную политику и в то же время свести к минимуму число ложных срабатываний устройства IDP. Однако нашу производственную сеть вряд ли назовешь статичной: в ней выполняется масса самых разнообразных приложений, в нее периодически добавляются новые серверы и модернизируются старые. Например, у нас имеются сетевые программы-менеджеры, которые регулярно сканируют сеть кампуса. Так как эти менеджеры генерировали тысячи сообщений, мы создали для них отдельную группу, добавили в политику правило игнорирования, после чего сигналов больше не возникало.

В отличие от МЭ, который “перекрывает” трафик сразу, устройство IDP способно подвергать пакеты многократной повторной обработке. Тем не менее мы сумели настроить отдельные правила на завершение обработки трафика: при совпадении с определенной сигнатурой к трафику применяется то или иное действие — будь то “ничего не предпринимать” (none), “сбросить пакет” (drop packet), “разорвать соединение” (drop session) или “послать команду сброса” (send reset), — и процесс обработки трафика прекращается. Порядок следования правил является интуитивно понятным.

Чтобы разрешить беспрепятственное прохождение через устройство IDP отдельных видов трафика, нам даже пришлось добавлять в базу правил свои собственные сигнатуры. В частности, как мы уже отмечали ранее, устройство IDP не распознает команду STARTTLS протокола SMTP, используемую для инициирования зашифрованной передачи данных. Всякий раз, когда поддерживающий TLS агент передачи сообщений или почтовый агент пользователя согласовывал свои параметры с почтовым сервером, генерировалось предупреждение о неверной команде, а когда поступали последующие пакеты SMTP, выдавался сигнал о наличии в их заголовках двоичных данных. Для устранения ложных срабатываний мы создали правило, с помощью которого в трафике отыскивалась команда STARTTLS и игнорировался последующий поток данных.

В отличие от IntruShield сигнатуры IDP можно просматривать и редактировать. Так, относительно небольшое устройство IDP 10, которое мы протестировали в нашей реальной производственной сети, постоянно генерировало предупреждающие сообщения о циркуляции подозрительного HTTP-трафика между хостом IntruShield Manager и ноутбуком, оснащенным управляющим клиентом IntruShield. Посредством одного из правил находились двоичные данные в полезной нагрузке TCP-пакетов и генерировались эти предупреждения. Мы изменили сигнатуру таким образом, чтобы проверялись только HTTP-пакеты с двоичными данными в заголовке. Такая возможность редактирования позволяла нам легко добиваться толерантности сигнатур по отношению к нашему обычному трафику. Конечно, мы никогда не редактируем сигнатуры без особой нужды, поскольку прекрасно понимаем, что после нашего вмешательства они могут стать бесполезными. Однако при разумном подходе функция редактирования сигнатур является достаточно мощным средством продукта NetScreen-IDP 500, несомненно выигрывающего в этом отношении на фоне “закрытой” модели сигнатур устройства компании Network Associates.

Хотя нам понравились многие возможности устройства IDP, к средствам просмотра сообщений и генерации отчетов это не относится. Если мы точно знали, какие именно сообщения ищем (например, касающиеся конкретных атак, портов или хостов), то могли задавать параметры, сужающие область поиска до приемлемого уровня. Эти параметры можно ассоциировать с конкретными просмотрами и использовать повторно. Кроме того, менеджер сообщений реального времени предоставляет журнал регистрации всех событий с возможностью их фильтрации. Двойной щелчок мышью на каком-нибудь событии приводит к появлению диалогового окна с кратким описанием события и всевозможными полезными ссылками. При нажатии на правую кнопку мыши выводится контекстно-зависимое меню с такими опциями, как Filter (фильтровать), Show Data (показать данные) и Locate Attack (локализовать атаку). Опция Filter позволяет фильтровать данные по выбранным полям, повторное ее использование еще более сужает область подлежащих анализу данных. К примеру, нам нужно было выявить и устранить причину возникновения проблемы с протоколом POP3. Для этого мы сначала отфильтровали все сообщения POP3 Command-Failed, а затем ограничили их хостом, который нас интересовал.

При всем при том подсистема регистрации событий продукта IDP не предоставляет удобного для просмотра перечня всех атак. Отчеты являются неинтерактивными и не позволяют осуществлять, в частности, более глубокий анализ представленных в них данных. Устройство не имеет ни планировщика, который позволял бы регулярно генерировать отчеты, ни какого-либо способа для индивидуальной их настройки. Объем данных, “выдаваемый” IDP, является довольно большим, и поэтому все перечисленное — существенный его недостаток.

Максимальная пропускная способность IDP 500 составляет 500 Мбит/с. В ходе тестирования он обрабатывал трафик со скоростью 461 Мбит/с, а вносимая им задержка пакетов равнялась 1,7 с, что негативно сказывалось на общей производительности сети..





  
1 '2004
СОДЕРЖАНИЕ

электронная Россия

• Инфокоммуникации земли сибирской

бизнес

• Закон "О связи" принят. Что дальше?

• Open Source на рабочем столе

инфраструктура

• Развитие БЛВС

• Тестируем инфраструктурное оборудование для БЛВС

информационные системы

• Второй фронт

• Так ли прост SNMPv3

• Как не попасться на уловки фирм-производителей

сети связи

• Азы телефонии для менеджеров ИТ

• IP-телефония: в поисках приложений

• SBC на границе

кабельные системы

• Средства управления коммутационными шнурами

• Оговаривайте тестирование шнуров

защита данных

• Тестируем системы предотвращения вторжений уровня сети

новые продукты

• 64-битовый сервер Depo Iron 6000R1S


• Калейдоскоп



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх