Все в одном, или Hogwash как пример Gateway-IDS::Журнал СА 1.2005
www.samag.ru
Льготная подписка для студентов      
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
О журнале
Журнал «БИТ»
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

Jobsora


  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
28.05.2019г.
Просмотров: 2271
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 2257
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 1805
Комментарии: 0
Django 2 в примерах

 Читать далее...

28.05.2019г.
Просмотров: 1328
Комментарии: 0
Введение в анализ алгоритмов

 Читать далее...

27.03.2019г.
Просмотров: 1853
Комментарии: 1
Arduino Uno и Raspberry Pi 3: от схемотехники к интернету вещей

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Все в одном, или Hogwash как пример Gateway-IDS

Архив номеров / 2005 / Выпуск №1 (26) / Все в одном, или Hogwash как пример Gateway-IDS

Рубрика: Безопасность /  Механизмы защиты

Сергей Яремчук СЕРГЕЙ ЯРЕМЧУК, фрилансер. Автор более 800 статей и шести книг. С «СА» с первого номера. Интересы: сетевые технологии, защита информации, свободные ОС

Все в одном, или Hogwash как пример Gateway-IDS

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

Я думаю, нельзя не согласиться с тем, что основой сетевой защиты является в первую очередь брандмауэр, на втором месте по значимости стоит система обнаружения атак. Брандмауэр способен остановить большую часть атак, направленных на компьютеры. Принцип его работы прост и широко известен. Такие устройства, как правило, имеют два сетевых интерфейса, один из которых «смотрит» во внутреннюю сеть, а второй подключен к сети провайдера. Получая пакет с любого из этих интерфейсов, брандмауэр сверяется с правилами, анализирует заголовок пакета и принимает решение о его дальнейшем прохождении или отбрасывании, после чего уменьшает TTL и переправляет пакет по назначению. В сетевых системах обнаружения атак присутствует анализ содержимого пакетов, но они в большинстве случаев не пропускают их сквозь себя, а просто перехватывают то, что проходит по сети. Таким образом, для того чтобы остановить атаку, им приходится либо связаться с брандмауэром, либо включаться в разрыв и самим заниматься отбраковкой пакетов.

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

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

Кстати, работа связки «брандмауэр + мост», позволяющей обходиться в такой системе без IP-адресов, была описана еще в конце прошлого века в документе «Linux Bridge+Firewall Mini-HOWTO» (в русском переводе «Мини-HOWTO: Совместное использование мостов и Firewall в Linux»). Вручную возиться со всем этим сейчас не придется, так как данная идея получила дальнейшее развитие в проектах вроде ebtables (http://ebtables.sourceforge.net), которые представляют уже готовое решение, позволяющее без особых проблем собрать подобную систему. На данный момент код ebtables официально включен в ядро 2.6, на указанном выше сайте можно найти патчи к еще популярной в народе версии 2.4. Кроме фильтрации кадров, ebtables позволяет изменять Ethernet MAC-адреса внутри кадров и параметры маршрутизации, также никто не запрещает использовать ebtables совместно с iptables/ip6tables/arptables, хотя особого смысла в этом лично я не вижу. Как и в iptables, в ebtables имеется возможность контроля за соответствием MAC- и IP-адресов. Правила также имеют схожий синтаксис, поэтому освоить работу с ebtables весьма просто.

ebtables -A FORWARD -p IPv4 --ip-src 192.168.1.4 -s ! 00:11:22:33:44:55 -j DROP

iptables -A FORWARD -s 192.168.1.4 -m mac --mac-source ! :11:22:33:44:55 -j DROP

Конечно, есть и различия, исходящие из особенностей работы этих утилит. Так, кадр Ethernet будет отброшен раньше, чем IP-датаграмма. Кроме того, ebtables берет за основу МАС-адрес, который сравнивается с IP-адресом, а iptables поступает с точностью наоборот. Но не ebtables герой этой статьи. Итак, если возможна фильтрация Ethernet-кадров, то почему бы не использовать и систему обнаружения атак на втором уровне? Преимущества данного подхода очевидны. Кроме невозможности идентификации, такая система сможет не только определять угрозы, но и тут же останавливать их, отбрасывая кадры, изменяя настройки таблиц маршрутизации или фильтров брандмауэра.

Проект Hogwash

Такой подход показался настолько логичным и простым решением проблемы, что когда в 1996 году Джейсон Ларсон (Jason Larson) и Джед Хейл (Jed Haile) столкнулись с необходимостью защиты веб-сервера, был сразу же написан начальный вариант системы, позволяющей отфильтровывать опасные пакеты использовавшиеся для вторжения. Первое время проект носил название Scrub и был простым фильтром пакетов, работающим на втором уровне. Постепенно был разработан язык описания атак и движок детектирования, который в 1999 году был заменен кодом Snort (развитие последнего к тому времени шло полным ходом). При этом проект изменил свое название на SnortScrub, которое, впрочем, тоже долго не продержалось, и по маркетинговым соображениям было изменено на Hogwash. В процессе добавления новых функциональных возможностей движок Snort оказался малопригодным для массовой обработки кадров. Поэтому в текущей и пока еще не доведенной до финала версии 0.5 происходит возрождение старого движка «H2». Совместимость со Snort будет сохранена и вынесена в отдельный слой. На данном этапе Hogwash позволяет анализировать информацию и регистрировать большие потоки данных в режиме реального времени. Система, построенная с применением Hogwash, способна реагировать на сканирование, некоторые атаки, направленные на переполнение буфера, определение типа ОС (OS fingerprinting) и другие. Hogwash относится к классу Gateway Intrusion Detection System и может быть настроен для работы в трех режимах:

  • Классическая система обнаружения атак (IDS).
  • Встроенная система предотвращения атак (IPS) – Scrubber.
  • Контроллер обманных (HoneyPot) систем.

В первом случае Hogwash работает подобно любой другой системе обнаружения атак (рис. 1), контролируя проходящий трафик на одном или нескольких интерфейсах и генерируя предупреждения. При этом система способна разрывать подозрительные TCP-соединения и отбрасывать пакеты. Необходимо отметить, что сборка всего потока не производится. Если в принятом пакете имеется частичное совпадение с правилом, то будет принята его следующая часть, и если правило совпадет полностью, то пакеты, принадлежащие данному сеансу, будут отброшены. Для обнаружения сканирования Hogwash отслеживает каждый новый сеанс связи (tcp, udp, icmp) в течение 60 секунд, и если обнаруживается один и тот же источник, то все пакеты, приходящие с него, отбрасываются. Аналогичная реакция имеет место и при обращении с одного источника к 20 уникальным портам и 5 адресам.

Рисунок 1

Рисунок 1

При применении в качестве IPS, Hogwash активно просматривает трафик (рис. 2). При этом он способен не только отбрасывать пакеты и изменять параметры маршрутизации, но и переписывать их содержимое (т.н. процедура «промывки» пакетов), убирая опасные данные. Конечно, ничто не мешает использовать его и как обычный пакетный фильтр. В этом режиме поддерживается одновременное наблюдение за 16 интерфейсами. Подключение системы в данном режиме к сети полностью прозрачно, так как она не имеет собственного IP-адреса. Это практически идеальное (и к тому же труднообнаруживаемое) устройство для остановки всех известных атак.

Рисунок 2

Рисунок 2

Чтобы не перегружать систему, занимаясь одним и тем же пакетом дважды, в режиме IPS желательно (но в принципе необязательно) отключить переадресацию.

echo "0" > /proc/sys/net/ipv4/ip_forward

В стартовых скриптах версии 0.4 эта строка уже имеется, версия 0.5 пока не имеет сценариев настройки и запуска, поэтому многое придется проделывать вручную.

В экспериментальном на данный момент режиме управления системами HoneyPot (рис. 3), Hogwash не выполняет никаких действий для остановки атаки. Вместо этого он перенаправляет нападающих к одной из обманных (HoneyPot) систем, позволяя таким образом собрать информацию о целях и методах злоумышленников, а также выиграть время, сбить их с толку и лучше подготовиться к обороне.

Рисунок 3

Рисунок 3

Установка Hogwash

Как уже упоминалось ранее, работа над версией 0.5 еще не полностью закончена, так как в ней произведена первая попытка возрождения движка «H2» вместо Snort. Однако стоит отметить, что она является полностью работоспособной и готовой к применению. Учитывая более адаптированный для работы на втором уровне движок и некоторые изменения в настройках и размещении файлов, я рекомендую остановить свой выбор именно на ней, так как в дальнейшем будет легче осваивать новые версии и обновлять продукт. Также стоит отметить, что в версии 0.4 используется Snort 1.8.6, имеющий проблемы с безопасностью (http://www.iss.net/issEn/delivery/xforce/alertdetail.jsp?oid=21951), заключающиеся в возможности выполнения произвольного кода, который может быть специально помещен в захваченных сетевых пакетах. С другой стороны, для версии 0.4 можно использовать готовые правила Snort, а для 0.5 пока придется пользоваться имеющимся набором правил и при необходимости составлять их самому. Кроме того, новый движок имеет только 17 параметров для формирования правил, и их явно недостаточно, особенно для работы с UDP-пакетами.

Hogwash на сегодняшний день из операционных систем поддерживает только Linux, не требует наличия в ядре стека IP, так что при желании его можно отключить, что только повысит общую защищенность. Также желательно наличие MySQL, куда будут заноситься правила и «отловленные» данные, поскольку при большом их количестве скорость обработки существенно возрастет. Исходный код Hogwash свободно доступен и распространяется по лицензии GPL. Сайт проекта http://hogwash.sourceforge.net.

Установка пакета происходит не просто, а очень просто:

# tar xzvf devel-0.5-latest.tar.gz

# cd devel-0.5

На данный момент сценарий конфигурации не имеет никаких дополнительных параметров настройки.

# ./configure

****************************

Configure script for Hogwash

****************************

 

Checking OS.................LINUX

Checking for a C compiler.../usr/bin/gcc

Checking endian-ness........LITTLE

Checking for MySQL..........Found

Checking for daemon.........Found

Checking for freopen........Found

Checking for dlopen.........Found

Done.

# make

Размещение файлов по каталогам производится вручную. Для начала скопируем в положенное место основной исполняемый файл.

# cp ./hogwash /usr/sbin/

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

# mkdir /etc/hogwash

# cp -R rules /etc/hogwash/

Для примера возможных настроек пакет содержит два конфигурационных файла stock.config и test.config.

# cp ./stock.config /etc/hogwash

# mkdir /var/log/hogwash

Теперь можно открыть файл stock.config и познакомиться с настройками.

Для удобства работы все настройки разбиты по группам: system, interface, IPList, action, module, routing. Имеется также экспериментальная секция mangling.

Раздел «system» содержит общие параметры, которые можно оставить без изменения.

<system>

Name=Hogwash Sensor

ID=1001

Threads=1

# количество потоков, предназначенных для обработки пакетов, как правило, один поток на один интерфейс (т.е. Threads=1),

# при работе на многопроцессорных системах или в кластерах значение можно увеличить.

AlertHeader=%ac %m/%d/%y %h:%min:%s %sip:%sp->%dip:%dp

# эта необязательная секция указывает формат заголовков предупреждений, можно изменить на любой другой,

# необходимые данные приведены в таблице 1.

</system>

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

<interface NAME>

Type=INTERFACE TYPE

# и две необязательных опции

# пока поддерживается только этот протокол, поэтому можно его опустить

Proto= Ethernet

Role =     INTERFACE ROLE

</interface>

В поле Type можно выставить следующие значения: linux_raw (Linux), obsd_bpf (OpenBSD), osx_bpf (MacOS X), solaris_dlpi (Solaris, пока еще не полностью работоспособный вариант) и tcpdump. Для type= tcpdump в interface вместо NAME указывается имя файла, куда будут записываться результаты, и значение Threads в большинстве случаев должно равняться 0. Необязательное поле Role содержит подсказку для Hogwash, необходимую при возможном конфликте IP- и МАС-адресов, и может понадобиться для работы с обманными системами. Возможны четыре значения: Internal (внутренний интерфейс), External (внешний интерфейс), Normal (обычный, т.е. без возможного конфликта) и Honey (сюда подключена обманная система и возможна подмена адресов, чтобы нападающий ничего не заподозрил). Пример настройки секции:

<interface eth0>

Type=linux_raw

Proto=Ethernet

Role=Normal

</interface>

Списки IPLists необходимы для использования в правилах и других частях файла конфигурации. Для удобства можно задать любое число списков. Имя также может быть любым, но чтобы было легче ориентироваться, рекомендуется выбирать осмысленные названия. Возможно использование как отдельного адреса, так и списка адресов, в том числе, и в CIDR-нотации (Classless Internet Domain Routing). 0.0.0.0/0 означает «любой адрес».

Пример:

<IPList WebServers>

10.34.10.0/16

</list>

<IPList DNSServers>

0.0.0.0/0

</list>

<IPList FTPServers>

23.3.14.10

10.2.10.3-10.2.10.6

</list>

<IPList HonePotServer>

23.3.14.111

</list>

<IPList Green>

192.168.100.0/24

</list>

Возможно объединение списков.

<IPList AllServers>

WebServers

DNSServers

FTPServers

10.14.10.1

</list>

В секции action создаются наборы реакций на обнаружение тех или иных событий, которые затем будут использованы в правилах. Всего возможно создание 64 наборов реакций. Например:

<action default>

response=alert console

# вывод сообщения на консоль

response=alert file(/var/log/hogwash/hogwash.alert)

# запись предупреждающего сообщения в указанный файл

response=dump packet(/var/log/hogwash/packet.log)

# захват пакета, который сгенерировал сообщение и запись в файл

</action>

<action drop>

response=alert console

response=alert file(/var/log/hogwash/hogwash.alert)

response=dump packet(/var/log/hogwash/packet.log)

response=drop

# отбрасывание пакета (игнорируется при работе в IDS-режиме)

</action>

<action log>

response=alert console

response=alert file(/var/log/hogwash/hogwash.alert)

</action>

Возможны также и другие реакции:

  • Запись предупреждения в syslog:

response=alert syslog(facility=LOG_AUTH, priority=LOG_INFO, options=LOG_NDELAY|LOG_PID)

  • Посылка предупреждения в сетевой или UNIX-сокет:

response=alert socket(www.logger.com:12345)

  • Запись предупреждения в базу данных:

response=alert mysql(user=hogwash,dbase=hogwash5, host=localhost,port=3306,pass=password, logpackets=1)

  • Отправка предупреждения по e-mail:

response=email(host, from, to, subject)

  • Экспериментальная опция, позволяющая отсылать пакеты, удовлетворяющие определенным правилам, на HoneyPot-систему. В качестве параметров указываются временная задержка и адреса, с которых не должно происходить переключение на HoneyPot. При timeout = -1 перенаправление на ложный сервер будет производиться без задержки.

response=bns(, )

Режим требует наличия трех сетевых карт.

<action honeypot>

response=alert console

response=alert file(/var/log/hogwash/hogwash.alert)

response=bns(3600, Green)

</action>

Плюс ко всему на данный момент имеется недоработанная, а потому и не описанная в документации опция response=route sip(, ,), позволяющая внести изменения в таблицу маршрутизации и отослать исходящие пакеты с определенным IP-адресом в другое место, например, в систему-ловушку. Однако очень трудно представить ситуацию, когда адрес атакующего будет известен заранее. К сожалению, в версии 0.5 исчезла возможность «промывки» пакетов, опции replace в списке действий нет. Объяснений от разработчиков по этому поводу не последовало, возможно, это явление временное и связано с переходом на новый движок, а может быть, разработчики посчитали эту возможность лишней, т.к. для остановки вторжения достаточно отбросить пакет или перенаправить нападающего на обманную систему.

Секция module служит для подключения сторонних модулей, которые производят дополнительные проверки, независимо от того, в каком режиме сейчас работает Hogwash (IDS, IPS или управление обманными системами). На момент написания статьи в каталоге modules лежало четыре готовых модуля:

  • ATS и ATS2 от All Traffic Summary Logging, предназначены для записи в журнал информации о событиях, происходящих в сети (протоколируется время, IP-адреса и порт источника и получателя, а также некоторая другая информация, позволяющая идентифицировать запросы).
23442543 03/12/2004 19:38:35-19:38:35 192.168.1.1:80<-192.168.1.58:24567  -  T 4:4 U 0:0 I 0:0 O 0:0

    Модуль ATS2 может быть полезен для сбора статистических данных. ATS является его старой версией, одновременный запуск ATS и ATS2 не допускается. Запись в один журнал ведется на протяжении часа, затем открывается новый файл.

<module ATS2>

filename=(/var/log/hogwash/TEST_%y_%m_%d_%h.ats)

</module>

  • Модули WebUnique и DNSUnique позволяют находить ранее неизвестные атаки, направленные на эти сервисы, путем сбора данных и их дальнейшего анализа для внесения изменений в настройки сервисов или код скриптов. Общая идея примерно такова. Большинство «нормальных» посетителей сайта будут постоянно и помногу раз обращаться к одним и тем же страницам, и только злоумышленник с большой вероятностью постарается каждый раз загрузить что-либо уникальное. DNSUnique реализует эту идею в отношении DNS.

<module WebUnique>

dbase=hogwash5

user=hogwash

password=password

host=localhost

servers=WebServers

logfile=WebUnique.log

</module>

<module DNSUnique>

dbase=hogwash5

user=hogwash

password=password

host=localhost

servers= DNSServers

logfile= DNSUnique.log

</module>

Относительно недавно появился еще один простой модуль covert, демонстрирующий некоторые скрытые механизмы обнаружения. На сегодняшний день он работает только с протоколом ICMP.

Наконец, рассмотрим секцию routing, включающую режим маршрутизации пакетов. Если этой секции нет, то Hogwash будет работать в режиме IDS. В самом простом случае, когда требуется маршрутизация, т.е. кадры отправляются только на нужный интерфейс (такая система имеет возможности Flood Protection), секция выглядит так.

<routing>

MacFilter(eth0, eth1, …)

</routing>

Режим моста, когда пакеты после анализа и фильтрации передаются на другой интерфейс, включается опцией SBridge(eth0, eth1). Опция Broadcast() включает специфическую обработку широковещательных Еthernet-сообщений (в реальной системе ей трудно найти применение). Опции SIP(INTERFACE IPLIST) и DIP(INTERFACE IPLIST) схожи. Первая пропускает через указанный интерфейс все пакеты, у которых IP-адрес источника указан в списке, вторая пропускает только те, у которых IP-адрес назначения имеется в списке. Использовав в этой секции опцию bns(, , , ), например, «bns(eth0,eth1,eth2, BlackList)», можно перенаправлять пакеты, подпадающие под действие response=bns, на HoneyPot-систему. В данном случае BlackList содержит список адресов, которые всегда должны перенаправляться в ловушку. Желательно, чтобы HoneyPot имел такие же настройки, что и основная система, но вот IP-адреса у них должны быть обязательно одинаковыми, иначе нападающий заметит подлог и убежит (что тоже в принципе хорошо, хотя и не всегда желательно).

Правила обнаружения атак описываются весьма гибко. Например, при обнаружении попытки запуска на одном из веб-серверов команды cmd.exe, правило может выглядеть так.

<rule>

ip  dst(WebServers)

tcp dst(80)

tcp nocase(cmd.exe)

message=%sip:%sip->%dip:%dp cmd.exe attempt

action=default

</rule>

Или, в случае UNIX-систем:

<rule>

ip dst(WebServers)

tcp nocase(/bin/sh)

message=attempt to execute /bin/sh

action= drop

</rule>

<rule>

icmp type(8)

message=%sip-%dip icmp echo request

action=log

</rule>

В правила может быть включена разнообразная информация, например, IP-адреса, интерфейсы, номера портов, тип протокола верхнего уровня, содержащегося в Еthernet-кадре (IP, ARP и т. д) или IP-датаграмме (TCP, UDP, ICMP, IGMP, PIM, OSPF), содержимое пакетов, код и тип ICMP, сюда же заносятся предупреждающие сообщения, выводимые при обнаружении совпадения и требуемая реакция. Сейчас разработчики работают над прямой совместимостью с правилами Snort (данная функция будет частью финальной версии Hogwash 0.5).

Таблица 1.  Возможные данные, выводимые в сообщении

Обозначение

Выводимое значение

%sip

Исходный IP-адрес

%dip

IP-адрес назначения

%sp

Исходный порт

%dp

Порт назначения

%y

Год

%m

Месяц

%d

День

%h

Час

%min

Минуты

%s

Секунды

%usec

Микросекунды

%pn

Номер пакета

%ac

Счетчик предупреждений

На момент написания статьи в базу было занесено 7 358 правил, описания которых находились в следующих 7 файлах: general.rules, jason.rules, nikto.rules, nimda.rules, stock.rules, test.rules и x11.rules. Основным является файл stock.rules, остальные при необходимости подключаются в нем инструкциями вроде <include nikto.rules>. При желании правила можно занести в MySQL.

Теперь, когда все готово, можно запускать Hogwash.

# /usr/sbin/hogwash -c stock.conf -r stock.rules &

Для запуска в качестве демона необходимо добавить опцию –d. Если необходимо только произвести синтаксический анализ составленных правил, используется –t.

Для автоматического запуска при старте системы лучше всего написать простенький скрипт.

# mcedit /etc/hogwash/hogwash.sh

Тело сценария:

#!/bin/bash

PATH=/bin:/sbin:/usr/bin:/usr/sbin

cd /etc/hogwash

killall hogwash

echo "0" > /proc/sys/net/ipv4/ip_forward

hogwash -c stock.conf -r stock.rules –d

Изменяем права доступа.

# chmod 700 /etc/hogwash/hogwash.sh

И далее любым приемлемым способом прописываем запуск hogwash.sh в стартовых скриптах. Например, для Slackware можно поступить так:

# echo /etc/hogwash/hogwash.sh >> /etc/init.d/rc.local

Все, теперь Hogwash будет добросовестно защищать ваши сети.

Hogwash является простым в инсталляции и использовании Gateway-IDS. Систему такого типа достаточно тяжело обнаружить: утилиты вроде traceroute не замечают ее и, таким образом, риск проведения DOS сводится к минимуму. Быстрая настройка и небольшое число регулируемых параметров делают Hogwash хорошим средством защиты сетей. Возможность автоматической отсылки пакетов на ложные системы является несомненным достоинством, позволяющим вовремя заметить проблемные участки сети. Вполне возможно, что будущее сетевой безопасности как раз за Hogwash и ему подобными решениями. Как говорится, поживем – увидим.

Ссылки:

  1. An introduction to gateway intrusion detection systems – http://www.blackhat.com/presentations/bh-usa-02/bh-us-02-haile-hogwash.ppt
  2. Securing an Unpatchable Webserver... HogWash! – http://www.securityfocus.com/infocus/1208

Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru