Библиотека Интернет Индустрии I2R.ru

Мы не собираемся начинать статью рассказом о фантастических денежных суммах, потерянных известными Интернет-компаниями из-за атак на службы (Denial-of-Service - DoS), которым эти компании подверглись в последнее время. С атаками, сопровождающимися огромным числом пакетов, нам приходилось иметь дело, и они действительно могут причинить серьезный вред. Противодействуя этому, можно делать деньги, и за последние несколько месяцев на рынке появилось множество устройств типа анти-DoS. Их создатели уверяют, что с помощью таких устройств можно ослабить натиск различных DoS-атак. На первый взгляд может показаться, что это действительно так. Но, когда мы начинаем использовать эти продукты, возникает вопрос: а они и правда работают?

В надежде развеять свое скептическое отношение к подобным устройствам мы решили протестировать в лаборатории Neohapsis некоторые из них и посмотреть, на что же они годны. Для испытаний мы выбрали продукты компаний: Captus Networks, Foundry Networks, Mazu Networks, Radware, Reactive Network Solutions и Top Layer Networks, затем выработали программу тестирования, включив в нее разные известные DoS-атаки (см. "Как мы тестировали устройства анти-DoS"). Используя распространенные типы DoS-атак, мы оценивали возможности устройств по их выявлению и противодействию этим атакам. Оценка выставлялась на основании объемов отфильтрованного либо остановленного ими как "враждебного", так и безопасного трафика. Логика простая: полная защита от DoS-атаки - это отключение Web-сервера или запрещение всего трафика. Да, вы остановили атаку. Да, вы спасли сервер. Но вы также потеряли и своих потенциальных покупателей. И именно поэтому устройства, которые могли запретить боўльшую часть "враждебного" трафика и пропустить боўльшую часть разрешенного оценивались нами выше устройств, блокировавших боўльшую часть разрешенного трафика при фильтрации атаки.

Как остановить DoS-атаку

Сначала нужно уяснить разницу между атаками DoS и DDoS (Distributed DoS) - в последнем случае атака ведется сразу с множества хостов. Таким образом, DDoS - это широкомасштабная атака. Поскольку задачей DoS-атаки является перегрузка ограниченных ресурсов целевой системы, вовлечение в атаку множества компьютеров делает ее потенциально опаснее.

Если атака осуществляется из одного источника или даже из нескольких (небольшого их числа), блокировать их довольно просто. Однако остановка DoS-атаки - дело не всегда такое простое. Часто в некоторых типах атак используется спуфинг или другие способы подмены исходных адресов. Кроме того, исходный адрес может генерироваться случайно. В результате оказывается, что трафик от одного атакующего хоста выглядит так, как будто атака предпринимается с сотен, тысяч и даже миллионов разных хостов. Блокировать эти случайные адреса бесполезно, поскольку атака продолжится с других случайных адресов.

Что же делать?

Самый надежный способ остановить DoS-атаку - просто запретить весь поступающий на целевой хост трафик. Это хорошая тактика против атак с использованием служебных протоколов, например ICMP (Internet Control Message Protocol), но остановка трафика TCP или UDP (User Datagram Protocol) отрицательно скажется на работе некоторых служб, в частности служб HTTP или DNS. Тем не менее запрет всего трафика действительно защищает ваш хост от атаки, поэтому иногда (например, в случае с атакой SYN flood) это лучше, чем совсем ничего.

Если атака предпринята c одного или нескольких хостов и адреса атакующих машин не генерируются случайным образом, то устройство, способное определять исходные IP-адреса, сможет запретить трафик с враждебных хостов. Это наилучшим образом блокирует атаку, а мы, со своей стороны, продукту с такой способностью присудим в наших испытаниях высокую оценку. Однако отслеживать каждый уникальный IP-адрес - непростая задача, требующая больших вычислительных ресурсов. Поэтому в некоторых устройствах заложена упрощающая данную задачу функция: делить все пространство адресов Интернет на несколько частей. Хотя это позволяет быстро выделить участок атаки, его блокирование, особенно если это участок с большим числом легитимных пользователей, сделает ваш сайт недоступным для них. И все же описанные здесь действия могут быть эффективным способом ослабления атаки и поэтому заслуживают достойной оценки.

Следующий метод ослабления атаки - использование так называемого принципа "водоспуска" (floodgate). Устройство блокирует боўльшую часть трафика, но иногда на короткое время пропускает малую его порцию. В этих порциях содержится, вероятно, как обычный трафик, так и трафик DoS-атак. В таком случае атакующие пакеты поступают на целевую систему в меньшем количестве, что предотвращает ее перегрузку, одновременно позволяя худо-бедно обрабатывать обычный трафик. Метод "водоспуска" особенно полезен против атаки типа SYN flood, но эффективен также и против атак на службы, вроде DNS.

Последний способ ослабления DoS-атак - анализ трафика и его селективная фильтрация. При этом устройство в реальном режиме времени проверяет характеристики трафика и по определенным критериям выявляет (т. е. отфильтровывает) трафик атаки. Конечно же, это проще сказать, чем сделать! Тут все зависит от уникальных особенностей атакующего трафика. Примеры - постоянные параметр TTL (Time To Live), порядковый номер, исходный порт и идентификатор IP. К счастью, трафику, генерируемому многими общедоступными инструментами для проведения DoS-атак, свойственны эти характеристики, поэтому такой подход доказывает свою эффективность.

Признаться, сначала мы скептически относились к тому, что какое-либо устройство может автоматически ослабить некоторые разновидности DoS-атак, в особенности атаки с генерацией случайных адресов. Не только мы одни сомневались: компании Arbor Networks и Asta Networks разработали продукты, в основу которых был положен принцип, заключающийся в том, что без вмешательства администратора эффективно отразить атаку невозможно. Опробовав устройства этих фирм в действии, мы пришли к выводу, что они на самом деле очень эффективны в отношении многих известных атак. Лишь некоторые - особо опасные и хорошо продуманные - DoS-атаки могут пробить такую оборону (см. http://www.nwc.com/1225/1225rd3.html).

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

И вот победитель...

Устройства, которые мы тестировали, не обязательно должны были быть функционально одинаковыми. Мы имели дело с коммутаторами, средствами балансировки нагрузки, межсетевыми экранами и анализаторами трафика. Некоторые из них предназначались для наблюдения за коммерческими магистральными сетями, а некоторые - для защиты небольших кластеров. Одни устройства только защищали от DoS-атак, в то время как в других такая защита являлась дополнительной функцией. Часть устройств обладали полнофункциональными графическими интерфейсами для анализа пакетов и просмотра истории атак, в то время как были и такие, которые просто сообщали, что такая-то атака имела место.

Не все продукты работали одинаково хорошо, но ведь и рабочая среда бывает разной.

В ходе тестирования мы пытались понять, каким видам атак может противостоять то или иное устройство и насколько успешно. Мы не ставили перед собой задачу найти "лучшее из лучших". Поэтому наш подход к выбору победителя был, безусловно, субъективен. Продукту FireProof 2.2 фирмы Radware в комплекте с ПО SynApps мы присудили первое место. Решающим фактором для нас являлось соотношение цены и функциональности. Продукт компании Radware поддерживает маршрутизацию и коммутацию на гигабитовых скоростях, а также управляет нагрузкой межсетевого экрана (МЭ).

FireProof - это универсальное самодостаточное устройство, которое легко устанавливается на границе или внутри корпоративной сети. Еще одно похожее устройство - Web Server Director тоже включает в себя ПО SynApps, но ориентировано оно в основном на использование совместно с Web-сервером (а не в качестве МЭ).

Нельзя сказать, что устройство FireProof - это самый лучший выбор: оно не смогло справиться с некоторыми видами атак или хотя бы эффективно ослабить их. Вот почему мы должны сказать здесь и о другом устройстве - это TrafficMaster от компании Mazu. ПО TrafficMaster обладает способностью анализировать данные. В будущем, после некоторого усовершенствования, как нам кажется, оно сможет лучше отражать атаки без ущерба для работы пользователей. Фактически к моменту публикации данной статьи у устройства TrafficMaster должны были появиться некоторые новые функции, способные сделать его весьма и весьма достойным продуктом.

Нам также представляется, что с усложнением DoS-атак анализ трафика остается единственным способом их остановки без блокирования нормальной работы пользователей. TrafficMaster - одно из двух протестированных нами устройств (второе - FloodGuard), которые можно устанавливать в нескольких точках, что позволяет организовать их совместную работу.Тем, кто нуждается в МЭ, следует подумать над приобретением продукта CaptIO фирмы Captus, чье ПО TLIDS (Traffic-Limiting Intrusion-Detection System) обладает некоторыми базовыми возможностями анализа трафика: в ближайшее время этот продукт будет оснащен дополнительными функциями. Используя CaptIO и как МЭ и как устройство анти-DoS, вы сумеете ослабить атаки без усложнения структуры сети.

FireProof 2.2 фирмы Radware

Продукт FireProof обладает множеством функций, типичных для других продуктов фирмы, включая коммутацию, маршрутизацию и балансировку нагрузки. Нас особенно заинтересовала технология SynApps. Для защиты от DoS-атак нужно просто настроить FireProof и затем включить функцию Application Security. FireProof работал у нас в качестве маршрутизатора, отделяющего сегмент Web-сервера от маршрутизатора выхода в Интернет.

Мы изучили техническую документацию на ПО SynApps, чтобы точно понять, как FireProof отражает атаки. Устройство заблокировало весь трафик ICMP во время атаки ICMP flood и действовало по принципу "водоспуска" во время всех атак SYN flood. Единственный минус продукта FireProof таков: элементарная атака SYN flood с одного хоста без подмены адресов заставляет его перейти в режим floodgate, при котором ограничивается весь трафик. Было бы лучше, если бы устройство могло идентифицировать атаку, исходящую из одного источника, и блокировать только трафик последнего.

Продукт FireProof не стал подсчитывать число открытых соединений на нашем Web-сервере (т. е. не защитил нас от атаки Naptha). Устройство Web Server Director (которое мы не тестировали) можно настроить так, чтобы ограничить количество соединений; это похоже на противодействие атаке методом "водоспуска", но все-таки лучше, чем ничего. FireProof смог обнаружить и сдержать некоторые атаки Targa, тем не менее боўльшая часть "враждебных" пакетов дошла до сервера.

Продукту FireProof явно не хватает инструментов для создания подробных отчетов и анализа атак. Фактически единственным указанием на наличие атак были записи в журнале регистрации событий. Поэтому администратору, имеющему дело с FireProof, для получения более подробной информации о конкретной атаке потребуется приобрести какой-нибудь анализатор трафика.

TrafficMaster Enforcer фирмы Mazu Networks

Продукт TrafficMaster Enforcer реализован на платформе eServer фирмы IBM с сильно модифицированным вариантом ОС Linux. В процессе его инсталляции и настройки не возникло никаких затруднений, его графический интерфейс мы нашли довольно удобным. Трафик отображается на диаграммах в реальном масштабе времени, но просматривать характеристики отдельных пакетов неудобно. За один раз можно просмотреть только один пакет, поэтому визуально сравнивать пакеты между собой трудно. Хотя это не так уж и плохо, поскольку ядро TrafficMaster само отлично находит в них похожие части. Фактически основное отличие TrafficMaster от конкурирующих продуктов - это умение обнаруживать в трафике схожие элементы, с тем чтобы отслеживать и пресекать атаки.

Продукт TrafficMaster выявляет аномалии в трафике и, работая как мост Ethernet, суммирует характеристики аномальных пакетов. На основе полученных данных он создает фильтр, который затем "предлагает" администратору для установки. Администратор изучает этот фильтр и, если его все устраивает, нажимает кнопку его установки во внутренний МЭ TrafficMaster.

Одна вещь не понравилась нам в продукте TrafficMaster - это чрезмерная сложность структуры и избыточность в функционировании некоторых фильтров. Например, в результате атаки ICMP flood, фильтр начал блокировать целые куски адресного пространства сети Интернет, вместо того чтобы всего-навсего запретить ICMP-трафик. В версии, которую мы тестировали, отсутствовала возможность отредактировать фильтр. Фирма Mazu собирается добавить эту функцию в свой продукт и работает над упрощением процесса создания фильтров по выбору пользователя.

Фильтры, имеющиеся в продукте TrafficMaster против атаки SYN flood, заблокировали все входящие SYN-пакеты. Проанализировав эти фильтры, мы выбрали две характеристики: время существования и длина IP-пакета, использование которых в созданных уже нами самими фильтрах позволило успешно заблокировать атаку без ущерба для обычного трафика. Мы уверены, что продукт компании Mazu мог бы и сам справиться с такой задачей. Но в нашем случае изменение настроек вручную помогло получить лучший результат. Хотя TrafficMaster и не "заработал" на этом дополнительных очков, поскольку всю работу за него сделали мы, данное обстоятельство можно засчитать в его пользу. Все-таки инструменты анализа, имеющиеся в продуктах TrafficMaster, Peakflow и Vantage System, помогают администратору разобраться в проблеме и принять решение о том, как лучше всего справиться с атакой.

TrafficMaster поддерживает технологию SYNQueue, которая позволяет автоматически сдерживать атаки без использования фильтров. Нужно отметить, что устройство осуществляет мониторинг числа поступающих пакетов SYN. Если это число превышает установленный предел, TrafficMaster начинает посылать серверу пакеты RST (сброс соединения), тем самым защищая его от перегрузки. Это происходит почти мгновенно, в то время как при использовании фильтров имеет место задержка, поскольку требуется вмешательство пользователя. Однако при генерации ответного "шквала" пакетов RST устройство не различает обычный и "атакующий" трафик.

Мощь TrafficMaster в полную меру проявилась во время атаки Targa, когда ему удалось отфильтровать основную часть аномального трафика. В конце концов мы пришли к выводу, что установка рекомендованных фирмой Mazu фильтров напоминает игру "русская рулетка". Из-за сложной структуры фильтров мы так и не смогли толком уяснить, что же на самом деле ими фильтруется? К тому же эти фильтры еще и невозможно редактировать. Создается впечатление, что их влияние на обычный трафик непредсказуемо. Представители компании заверили нас, что ко времени публикации статьи перечисленные проблемы будут решены, и сообщили об уже внесенных в продукт исправлениях.

ServerIron 400 фирмы Foundry Networks

На первый взгляд может показаться, что ServerIron 400 является продуктом фирмы Cisco. Почему?

Да просто потому, что при его конфигурировании в режиме командной строки сразу же вспоминаешь о продукции Cisco. С этим устройством все сертифицированные специалисты по продуктам Cisco будут чувствовать себя как дома. Мы тоже очень обрадовались наличию командной строки, поскольку это позволило нам вручную ввести пять простых команд, вместо того чтобы утомительно блуждать по экранам Web-интерфейса с десятками меню.

Для защиты от атаки SYN flood нам пришлось установить виртуальный Web-сервер с балансировкой нагрузки. Это создало ситуацию, в которой трудно оценивать работу продукта: атакам подвергалась виртуальная служба балансировки нагрузки; в ее роли выступал сам ServerIron, а не настоящий Web-сервер. Это означало, например, что все аномальные пакеты, посылаемые "противником" во время атаки Targa, не достигали Web-сервера, вместо этого они "поглощались" IP-стеком виртуального сервера.

При тестировании других устройств мы не использовали виртуальные хосты с балансировкой нагрузки, во-первых, по причине их сложности, а во-вторых, ради объективности выставления оценок (не все тестируемые нами устройства поддерживали их). Что касается ServerIron, то с ним нам нужно было организовать защиту от атаки SYN flood. Используемая нами конфигурация очень напоминала конфигурацию с сервером-посредником, где мишенью становится не Web-сервер, а сервер-посредник. Таким образом, мы оценивали возможности ServerIron по его противодействию некоторым атакам, в то время как сам Web-сервер реально атакован не был.

Согласно документации, ServerIron способен противодействовать двум разновидностям DoS-атак: smurf и SYN flood. При отражении атаки smurf, хотя трафик ICMP и блокировался, пакетный шторм остановлен не был: мы посылали множество ICMP-запросов, результатом же должно было стать множество ICMP-ответов. Однако, к счастью, ServerIron обладает функцией ограничения нагрузки, которая предотвратила отсылку огромного количества ICMP-ответов.

С атакой SYN flood устройство справилось так, как мы и ожидали: по достижении определенного числа входящих пакетов SYN устройство ServerIron запретило на некоторое время дальнейший их прием. В результате имело место ослабление атаки методом "водоспуска" со всеми недостатками, присущими решению Radware. При настройке виртуального Web-сервера мы установили лимит на число соединений с настоящим Web-сервером. Это помогло спасти его от перегрузки во время атаки Naptha, но инициировало сброс всех дальнейших входящих запросов на установление соединения с ним.

Возможности ServerIron по противодействию DoS-атакам неплохи, но это не главная его функция. Если вам нужен коммутатор для балансировки нагрузки на уровне приложений, обладающий полезной дополнительной функцией ослабления DoS-атак, то ServerIron будет подходящим выбором. Но мы не рекомендуем приобретать его в качестве исключительно устройства анти-DoS.

CaptIO G-2 фирмы Captus Networks

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

Своей мощью продукт CaptIO обязан ядру TLIDS, которое позволяет создавать различные правила, описывающие процедуры мониторинга и ослабления трафика атак. Ну и, разумеется, для того, чтобы CaptIO начал защищать вашу сеть, сначала нужно запрограммировать его. К счастью, синтаксис языка правил TLIDS прост и интуитивно понятен: кроме того, в комплект поставки продукта включен учебник по их написанию. В цену CaptIO также входит визит инженера фирмы Captus - он настроит правила для вашей среды. Мы использовали набор правил, рекомендованный компанией Captus, слегка модифицировав его под нашу среду.

Хотя устройство CaptIO имеет неплохое ядро, нам не понравились его средства оповещения и анализа отчетов. Узнать о предринятой атаке можно, только если периодически просматривать журнал системных событий или если использовать прерывания SNMP. С данным продуктом невозможно выделять фрагменты трафика, в нем отсутствует функция анализа данных, не говоря уже о простой функции получения статистики использования сетевого интерфейса. Фактически компания Captus - это единственный поставщик решений анти-DoS, который не снабдил свой продукт инструментами для анализа трафика.

Отсутствие графиков реального масштаба времени и инструментария для просмотра пакетов не помешало CaptIO успешно противодействовать атакам. ICMP-атака была быстро остановлена с помощью простого правила предельной нагрузки. С атакой SYN flood из одного источника устройству тоже удалось быстро справиться; к сожалению, то же нельзя сказать об атаке с подменой адресов. Это иллюстрирует характерную особенность CaptIO: эффективность ослабления атаки зависит от того, с какой степенью тщательности написаны правила. В нашем случае отсутствовали правила противодействия атаке SYN flood с подменой адресов; мы попытались создать собственное правило, но безуспешно. Ослабление этой атаки посредством хорошо написанного правила в принципе, наверное, возможно, но, поскольку нам пришлось пользоваться правилами, рекомендованными Captus, мы отметили это как минус и продолжили тестирование. Атака Naptha тоже удалась, поскольку устройство CaptIO не подсчитывало открытые соединения. Зато оно смогло остановить часть избыточного трафика UDP и ICMP, сгенерированного атакой Targa. Таким образом, общий объем трафика атаки был значительно уменьшен.

AppSwitch 3500 фирмы Top Layer Networks

Устройство AppSwitch 3500 выполняет массу задач, включая маршрутизацию и прозрачную коммутацию приложений. Графический интерфейс AppSwitch сначала было испугал нас своей сложностью, но, немного поработав, мы вполне освоились с ним. Настроив AppSwitch для выполнения им функций маршрутизатора, мы поместили Web-сервер и маршрутизатор выхода в Интернет в разные сегменты.

AppSwitch может остановить большинство известных атак: land, smurf, fraggle, UDP- и SYN-атаки. Он также может справиться с множеством других аномалий трафика, таких, как большие пакеты ICMP, фрагментирование пакетов TCP, включение опций протокола IP и маршрутизация источника. К сожалению, хотя наша ICMP-атака и не подходила под категорию smurf (как и в случае с ServerIron), пакеты были достаточно малы для того, чтобы успешно преодолевать фильтр, останавливавший большие ICMP-пакеты.

Во время атаки Targa устройство выдало предупреждение о "UDP-бомбе", и, конечно же, атака SYN flood из одного источника была успешно остановлена. К несчастью, та версия ПО TopPath, которая используется в AppSwitch 3500, не способна распознать атаку SYN flood с генерацией случайных адресов, хотя и фильтрует входящие пакеты. Это может привести к ситуации, когда администратор не будет знать о том, что Web-сервер подвергся атаке и что AppSwitch "втихую" сбрасывает пакеты. В компании Top Layer нам подтвердили наличие этой недоработки и заверили, что в последующих версиях ее не будет.

Более грамотно устройство AppSwitch справляется с решением задачи по ослаблению простой атаки SYN flood: оно действует как сервер-посредник на уровне протокола IP, вначале завершая процедуру "рукопожатия" с клиентом перед отправлением исходного SYN-пакета серверу. Это означает, что пропускается только обычный трафик и AppSwitch удаляет все ложные SYN-пакеты еще до того, как их "увидит" атакуемый сервер, которому в этом случае не приходится обрабатывать трафик атаки. С этой целью устройству AppSwitch приходится переписывать все пакеты для трансляции порядковых номеров TCP, подобно тому как переписываются пакеты при трансляции адресов, хотя в последнем случае все, конечно же, гораздо сложнее.

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

И еще. В нашей конфигурации устройство AppSwitch не могло считать количество открытых соединений. Функция коммутации приложений предоставляет возможность настройки AppSwitch на ограничение числа открытых соединений с атакованным сервером, но в базовом наборе функций по ослаблению атак эта возможность почему-то отсутствует. Таким образом, атака Naptha нам удалась, то же самое можно сказать и об атаке Targa (несколько предупреждений об атаке с помощью "UDP-бомб" можно не принимать во внимание).

FloodGuard фирмы Reactive Networks

Компания Reactive Networks прислала нам продукт FloodGuard, реализованный на платформе Dell. FloodGuard использует ОС Linux и отслеживает трафик сети посредством "отводов". Продукт не устанавливается в сеть: он отражает атаки, управляя настройками маршрутизатора Cisco через списки контроля доступа для входного интерфейса. Мы уверены, что это понравится не всем: дополнительные списки контроля доступа на маршрутизаторе снижают его производительность.

Что еще хуже, в момент пиковой нагрузки (во время DoS-атаки) устройство FloodGuard начинает устанавливать дополнительные списки контроля доступа, еще более "нагружая" маршрутизатор. К тому же возможности FloodGuard по ослаблению атак ограничены фирменной реализацией списков контроля доступа Cisco, которая не позволяет осуществлять фильтрацию на основе особых параметров пакетов, таких, как порядковые номера, размеры окон или идентификаторы IP.

Устройство FloodGuard ослабляет атаки двумя способами: пытается фильтровать трафик с помощью списков контроля доступа и генерирует RST-пакеты для того, чтобы закрыть входящие соединения с сервером, когда поступает слишком много пакетов SYN, причем для него неважно, атака это или обычный трафик. RST-пакеты практически единственная мера противодействия во время атак Naptha и SYN flood со случайной подменой адресов. В конце концов, RST-пакеты в равной мере воздействуют на обычный трафик и на трафик атаки. Это означает, что FloodGuard попросту "забивает" ими все поступающие пакеты SYN по превышении определенного их числа.

Во время атаки Naptha это вылилось в непредсказуемое изменение характера трафика - его всплески то появлялись, то пропадали. Один из недостатков подхода, реализованного фирмой в продукте FloodGuard, - чрезмерно расточительное использование полосы пропускания: вместо блокировки поступившего пакета синхронизации FloodGuard посылает серверу RST-пакет, - обычно через небольшой промежуток времени после того, как сервер пошлет ответный пакет SYN/ACK. Это означает, что на каждый пакет синхронизации генерируются еще два пакета и "забирается" еще часть полосы пропускания. Получается, что атака не ослабляется, а, наоборот, усиливается!

Атака ICMP flood спровоцировала устройство FloodGuard на приведение в действие правила запрета всех IP-пакетов, поступающих на сервер. Затем FloodGuard попыталось установить несколько правил, чтобы разрешить прохождение обычного трафика. К сожалению, боўльшую часть времени никакого трафика не поступало вовсе.

В компании Reactive утверждают, что эта недоработка будет исправлена ко времени публикации статьи. И еще. Атака Targa не вызвала никакой реакции у устройства FloodGuard, кроме посылки нескольких пакетов RST. А мы-то ожидали, что продукт, предварительно "исследовавший" нашу сеть, сумеет заметить ошибочные и подозрительные пакеты UDP и ICMP.

Графический интерфейс пользователя FloodGuard иначе как сырым не назовешь. Его, правда, украшают несколько диаграмм реального времени, а также схема IP-адресации источников и приемников, но это все из инструментов анализа, чем может располагать администратор, не считая аплета мониторинга. Данные о событиях хранятся только в виде текстовых журналов. В компании Reactive знают обо всех этих недостатках и заверяют, что в следующей версии продукта FloodGuard интерфейс пользователя будет доработан.