 |
|
|
|
Все в одном, или Hogwash как пример Gateway-IDS
Все в одном, или 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 и может быть настроен для работы в трех режимах:
В первом случае Hogwash работает подобно любой другой системе обнаружения атак (рис. 1), контролируя проходящий трафик на одном или нескольких интерфейсах и генерируя предупреждения. При этом система способна разрывать подозрительные TCP-соединения и отбрасывать пакеты. Необходимо отметить, что сборка всего потока не производится. Если в принятом пакете имеется частичное совпадение с правилом, то будет принята его следующая часть, и если правило совпадет полностью, то пакеты, принадлежащие данному сеансу, будут отброшены. Для обнаружения сканирования Hogwash отслеживает каждый новый сеанс связи (tcp, udp, icmp) в течение 60 секунд, и если обнаруживается один и тот же источник, то все пакеты, приходящие с него, отбрасываются. Аналогичная реакция имеет место и при обращении с одного источника к 20 уникальным портам и 5 адресам.
Рисунок 1 При применении в качестве IPS, Hogwash активно просматривает трафик (рис. 2). При этом он способен не только отбрасывать пакеты и изменять параметры маршрутизации, но и переписывать их содержимое (т.н. процедура «промывки» пакетов), убирая опасные данные. Конечно, ничто не мешает использовать его и как обычный пакетный фильтр. В этом режиме поддерживается одновременное наблюдение за 16 интерфейсами. Подключение системы в данном режиме к сети полностью прозрачно, так как она не имеет собственного IP-адреса. Это практически идеальное (и к тому же труднообнаруживаемое) устройство для остановки всех известных атак.
Рисунок 2 Чтобы не перегружать систему, занимаясь одним и тем же пакетом дважды, в режиме IPS желательно (но в принципе необязательно) отключить переадресацию. echo "0" > /proc/sys/net/ipv4/ip_forward В стартовых скриптах версии 0.4 эта строка уже имеется, версия 0.5 пока не имеет сценариев настройки и запуска, поэтому многое придется проделывать вручную. В экспериментальном на данный момент режиме управления системами HoneyPot (рис. 3), Hogwash не выполняет никаких действий для остановки атаки. Вместо этого он перенаправляет нападающих к одной из обманных (HoneyPot) систем, позволяя таким образом собрать информацию о целях и методах злоумышленников, а также выиграть время, сбить их с толку и лучше подготовиться к обороне.
Рисунок 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
# 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> Возможны также и другие реакции:
response=alert syslog(facility=LOG_AUTH, priority=LOG_INFO, options=LOG_NDELAY|LOG_PID)
response=alert socket(www.logger.com:12345)
response=alert mysql(user=hogwash,dbase=hogwash5, host=localhost,port=3306,pass=password, logpackets=1)
response=email(host, from, to, subject)
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 лежало четыре готовых модуля:
Модуль ATS2 может быть полезен для сбора статистических данных. ATS является его старой версией, одновременный запуск ATS и ATS2 не допускается. Запись в один журнал ведется на протяжении часа, затем открывается новый файл. <module ATS2> filename=(/var/log/hogwash/TEST_%y_%m_%d_%h.ats) </module>
<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. Возможные данные, выводимые в сообщении
На момент написания статьи в базу было занесено 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 и ему подобными решениями. Как говорится, поживем – увидим. Ссылки:
|
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
