 |
|
|
|
Тени исчезают в полдень
Тени исчезают в полдень Известно, что появлению Интернета мы обязаны американскому министерству обороны. Поэтому интересными являются и разрабатываемые в этом ведомстве технологии, направленные на защиту информации. На страницах журнала уже рассказывалось о проекте Security Enhanced Linux (http://www.nsa.gov/selinux) от U.S. National Security Agency (NSA), основной задачей которого является создание высокозащищенных систем. Сегодняшняя статья о не менее интересной системе, помогающей выявить проблемы в сети. Разработанная в 1994 году, система обнаружения атак SHADOW или Secondary Heuristic Analysis for Defensive Online Warfare (http://www.nswc.navy.mil/ISSEC/CID) является результатом деятельности другого проекта Cooperative Intrusion Detection Evaluation and Response (CIDER). CIDER в свою очередь был попыткой совместной разработки инструментов для автоматического сбора и анализа потоков информации в целях обнаружения атак. Основные работы ведутся Naval Surface Warfare Center, но свои усилия приложили и другие не менее известные организации вроде NSWC Dahlgren, NFR, NSA и SANS. Некоторое время система была закрыта, затем SHADOW так же стал свободно доступен, так как основой являются программы с открытым исходным кодом. Одним из требований при разработке системы было обнаружение максимального количества атак (насколько это возможно), с максимальной эффективностью и контролем большого количества сетей. Это уникальная в своем роде разработка, она базируется на идее статистического анализа потоков информации. Проверяются только размеры пакетов, откуда они приходят и куда направлены, без проверки внутреннего содержания. Это означает, что SHADOW пытается отыскать в первую очередь исследования, предшествующие атаке, а не саму атаку. Поэтому такая система в принципе способна выдать раннее предупреждение, что отличает ее от сигнатурных реализаций или определяющих аномалии в реальном времени. Такой анализ потоков информации делает возможным работу системы при использовании различных форм шифрования трафика. Также эта система может помочь отследить статистику работы компьютеров в сети, если же обнаружится неизвестный, то администратор получит предупреждение. Также администратор получает в свои руки полезный инструмент, позволяющий визуально определить происходящее в сети. Собранная информация поможет определиться со стратегией безопасности и будет полезна при задании правил firewall. Архитектура SHADOW Основу проекта составляют tcpdump и libpcap, применяющиеся для сбора сетевых пакетов. Как уже говорилось, анализируются только заголовки без анализа информации. Первоначально это может показаться не совсем разумно, так как некоторые атаки могут быть выявлены только при анализе содержимого, но для организаций, в которых повышенное внимание к конфиденциальности информации, – это, наверное, единственно разумный выход. Ведь если злоумышленник либо лицо, на это не уполномоченное, сможет получить доступ к данным базы собранных пакетов, то грош цена такой IDS. К тому же подобный подход требует меньшего количества ресурсов. Сама же система состоит из датчиков, анализаторов и базы собранных пакетов (рис. 1). При этом не имеет значения количество и место расположения датчиков, он просто собирает пакеты и по запросу переправляет их дальше анализатору. Их можно установить в зависимости от задач на внешнем интерфейсе, в DMZ или внутри сети. Установка вне firewall – большой риск, поэтому разработчики старались максимально его уменьшить и подстраховаться от возможной компрометации датчика. Анализатор всегда должен находиться за firewall. Его задача загрузить и оценить данные, собранные различными датчиками. Датчики и анализаторы для выборки данных и обслуживания соединяются посредством SSH. Для отбора событий, представляющих интерес, используются фильтры и скрипты. Последние позволяют обнаруживать и некоторые медленные, т.е. растянутые по времени атаки, а также распределенные атаки. Вся собранная информация в дальнейшем будет выводиться администратору в виде веб-страницы. Веб-интерфейс позволяет исследовать информацию, полученную от различных датчиков, за различные периоды времени, с подробной информацией относительно отдельного узла или образца, а также создавать готовые отчеты отправки для посылки в CIRT.
Рисунок 1 Установка SHADOW К сожалению, проект практически лишен нормальной документации. Имеется инструкция по установке да пара ссылок на устаревшие статьи с других сайтов. Инструкция показывает процесс установки в пошаговом режиме, но при этом в некоторых ключевых местах допущены мелкие, но сбивающие и запутывающие ошибки, а о некоторых важных деталях там совсем ничего не сказано. Вся же конфигурация производится исключительно вручную и требует знаний архитектуры сетей, строения UNIX и особенностей настройки некоторых Open Source-разработок. Поэтому это занятие не тривиальное, требующее внимательности и знаний, и у новичков, скорее всего, возникнут трудности. Но вот что мне нравится, так это подход. Фактически пользователь (или злоумышленник) в правильно настроенной системе обставлен флажками, за которые он выскочить не сможет при всем своем желании. Поэтому использование SHADOW, даже при многочисленных сенсорах, вряд ли может снизить общую защищенность сети и служить источником утечки информации или дать информацию о строении сети. С другой стороны, тем, кто хочет разобраться с безопасной настройкой и использованием всех упоминаемых ниже сервисов, стоит для ознакомления почитать эту инструкцию. Также одной из целей этой статьи является показ варианта безопасного конфигурирования разных сервисов. В различной литературе не всегда можно найти ответы на все вопросы. Для датчиков и анализаторов подойдет любая UNIX-подобная система, под которую можно скомпилировать libpcap, tcpdump, Perl, gzip, Apache и OpenSSH. Датчики и анализатор в целях безопасности должны находиться на разных машинах. Хотя в принципе и возможно их размещение на одном компьютере, но подразумевается, что датчик будет находиться в агрессивной среде, и поэтому в целях безопасности рекомендуется раздельное размещение. Девиз такой – никакого доверия датчикам. Датчик сконфигурирован так, чтобы работать только по SSH и только с анализаторами. Датчики должны быть защищены в максимально возможной степени. Чтобы сделать датчик невидимым, рекомендуется использование двух сетевых плат. Одна «невидимая» без IP-адреса будет собирать данные, а другая, которую желательно поместить за firewall, будет передавать информацию анализаторам. DEVICE=eth0 ONBOOT= no В других дистрибутивах это будет скорее выглядеть несколько иначе, например, в SuSE за загрузку отвечает переменная STARTMODE. Системные требования невысоки. Единственное, в больших и активных сетях может понадобиться применение SCSI-диска и больший объем жесткого диска (в основном для анализаторов) для хранения захваченной информации. В моем случае система на детекторы захватывала около 2-3 Гб в день. Дополнительно рекомендуется выкинуть все ненужное из ядра и отказаться от использования модулей (ответ «N» в «Enable loadable module support.»). В документации приведен пример .config-файла для перекомпиляции ядра, желательно также обновить систему. В целях безопасности все процессы и каталоги на датчиках и анализаторах работают от имени отдельного непривилегированного пользователя. Поэтому его необходимо будет завести перед установкой: # useradd -c "SHADOW" -u 666 -d /home/SHADOW shadow Для защиты рекомендуется выключить все лишние сервисы на используемых компьютерах (получить их список можно, введя chkconfig --list). Для отключения запускаемых через xinetd можно удалить все файлы в каталоге /etc/xinetd.d или проверить наличие строки «disable = yes» в каждом из них. Вторым шагом сетевой защиты является использование tcp_wrappers. Для чего в файле /etc/hosts.allow должны быть описаны адреса компьютеров, которым разрешен доступ к тем или иным сервисам. Формат файла прост: список_сервисов: список_машин [: команда] Например: sshd: 192.168.2. : allow ALL: 192.168.1.100,127.0.0.1 : allow ALL: ALL : deny В приложении «С», в инструкции по установке, вы найдете рекомендуемые опции для настройки iptables. Документ описывает установку на Red Hat Linux (конкретно версии 8.0), именно под него разрабатывается SHADOW. Я использовал White Box Linux 3.0 и SuSE Linux 9.1. Если с первым проблем практически не было, что и не-удивительно, ведь его основой служат исходные коды Red Hat Enterprise Linux. То при установке в SuSE пришлось немного повозиться, в основном это касается путей к конфигурационным файлам, которые пришлось изменять практически во всех скриптах. Это общие вопросы, теперь отдельно рассмотрим особенности настройки датчика и анализатора. Построение датчика Скачиваем архив размером чуть меньше 7 Мб. И создаем каталоги для размещения. В документации предлагается /usr/local/, можно выбрать и другой, но при этом придется указать новый путь во многих конфигурационных файлах. # mkdir -p /usr/local/SHADOW И распаковываем в него архив (tar xvfz /tmp/SHADOW-1.8.tar.gz). Все основные файлы подписаны при помощи GPG, и при сомнении подпись можно проверить. # gpg --verify some_file_name.sig Теперь в каталоге появится большое количество скриптов и подкаталогов, о назначении некоторых станет ясно по ходу изложения. В подкаталоге Doc вы найдете инструкцию по установке, в accessories – необходимые для работы утилиты libcap, tcpdump и openssh в rpm-пакетах и исходных кодах. Здесь последние версии этих утилит на момент выпуска SHADOW (апрель 2003), поэтому можно оставить имеющиеся в используемом дистрибутиве или взять более новые версии с официальных сайтов. Еще один момент, связанный с tcpdump. В RedHat, начиная с версии 6.2, применяют патчи, расширяющие возможности, но изменяющие выходной формат данных, с которыми анализатор работать не может. Поэтому если вы не уверены, tcpdump лучше все-таки взять и установить с http://www.tcpdump.org. О настройке и работе этих утилит уже рассказывалось на страницах журнала, поэтому этот вопрос в статье затрагиваться будет в объеме, необходимом для понимания процесса конфигурирования SHADOW. Теперь три скрипта в /usr/local/SHADOW/sensor требуют настройки. Это sensor_init.sh, std.ph и std.filter. Скрипт sensor_init.sh используется для запуска датчика. В нем переменная SENSOR_PATH должна указывать на каталог, куда установлен сенсор, SENSOR_PARAMETER указывает на файл, содержащий настройки датчика (без расширения .ph). Для примера настроек, в каталоге имеется файл std.ph. При необходимости можно использовать сразу несколько сенсоров с индивидуальными конфигурационными файлами. Далее необходимо проверить наличие файлов, прописанных в следующих переменных. # Source function library. . /etc/rc.d/init.d/functions # Source networking configuration. . /etc/sysconfig/network В SuSE первую строку пришлось закомментировать. Теперь копируем скрипт в положенное место. # cd /usr/local/SHADOW/sensor # cp sensor_init.sh /etc/rc.d/init.d/sensor Это для RedHat, в других дистрибутивах путь, возможно, будет другим. Например, в SuSE команда будет такой: # cp sensor_init.sh /etc/rc.d/sensor И добавляем скрипт в автозапуск. # chkconfig --add sensor В файле std.ph (или как вы его назвали) также проверьте наличие файлов и каталогов, указанных в переменных. В std.filter указываются параметры фильтра для захватываемых tcpdump-пакетов. По умолчанию в файле одна строка ip, можно использовать и собственные конструкции вроде: icmp and icmp[0] != 8 and icmp[0] != 0 для icmp-пакетов или для NetBIOS: ip and (port 137 or port 138 or port 139) Сценарий sensor_driver.pl управляет сенсорами. Для того чтобы собирать данные, каждый час во время работы системы используется crontab-сценарий – sensor_crontab. Для реализации последней возможности копируем его в каталог /etc/cron.hourly. Этот сценарий содержит три строки. Первые две предназначены для синхронизации времени посредством Network Time Protocol (NTP), последняя, которую нужно раскомментировать, управляет запуском sensor_driver.pl. Параметры внутри, конечно же, можно подправить (список серверов времени на http://www.ntp.org, плюс статья Михаила Платова «NTP – атомные часы на каждом столе», журнал «Системный администратор», № 4, апрель 2004 г.). 17 23 * * * /usr/sbin/ntpdate time-a.nist.gov 18 23 * * * /sbin/hwclock --systohc 0 * * * * /usr/local/SHADOW/sensor/sensor_driver.pl std > /dev/null 2>&1 Все, датчик готов, можно приступать к настройке анализатора. Настройка анализатора Все первичные действия для анализаторов ничем не отличаются от проводимых на датчиках. Но после распаковки архива на свое место внимания требуют совсем другие файлы. Также для работы потребуется установленный веб-сервер Apache любой версии (в целях безопасности обновление рекомендуемо всегда), желательно с модулями mod_ssl и mod_perl. Практически во всех дистрибутивах он есть. Можно использовать веб-сервер параллельно основной работе, но лучше только для работы с SHADOW. В каталоге /usr/local/SHADOW/httpd/apache-conf найдете примеры конфигурационных файлов для версий 1.3 и 2.0, в том числе и оригинальный httpd.conf. Общим для всех файлов веб-сервера, включая и .htaccess, является наличие для всех упоминаемых в них каталогов, конструкций вида. Order deny,allow Deny from all Allow from 172.21.122 Allow from localhost Allow from 127.0.0.1 Не забудьте заменить адреса своими, иначе в доступе будет отказано. В файле httpd-2.0.40.basic содержатся минимальные настройки веб-сервера, с которыми система уже может быть запущена (в RedHat). Для этого достаточно его скопировать на свое место. # cp /etc/apache2/httpd.conf /etc/apache2/httpd.conf.orig # cp /usr/local/SHADOW/httpd/apache-conf /httpd-2.0.40.basic /etc/apache2/httpd.conf В SuSE необходимо заменить пользователя и группу. User wwwrun Group www И дописать в файл строку: Include /etc/apache2/sysconfig.d/loadmodule.conf Можно как вариант использовать более подробный httpd-2.0.40.conf. Теперь готовим каталоги, в которых будут размещаться результаты, выводимые пользователю. # mkdir -p /home/shadow/html/tcpdump_results # cd /usr/local/SHADOW/httpd/home # cp * /home/shadow/html # cp .htaccess /home/shadow/html Не забудьте изменить адреса в .htaccess. # chown -R shadow:shadow /home/shadow Все, можно перезапускать веб-сервер. # /etc/init.d/httpd restart И теперь самое интересное и хлопотное – настройка ключей ssh. Для правильной работы OpenSSH, необходимо, чтобы файл /home/shadow/.ssh/authorized_keys на детекторах содержал копии открытых ключей пользователя shadow, которые были сгенерированы на анализаторе. Но поначалу необходимо, естественно, установить OpenSSH на датчике и анализаторе. Если команда ls /etc/ssh не покажет наличия файлов вида ssh_host_key.pub, то ключи можно сгенерировать автоматически, просто запустив сервер. # /etc/init.d/sshd start И не забудьте добавить запуск OpenSSH при загрузке системы. # chkconfig --add sshd Теперь необходимо, чтобы участвующие в работе узлы узнали о публичных ключах друг друга. Есть много способов, самый простой – соединиться с нужным узлом, и эта операция будет проделана автоматически. Разработчики считают более безопасным другой вариант. Монтируем дискету на датчике и копируем в нее все необходимые файлы. # mount -t vfat /dev/fd0 /mnt/floppy # cd /etc/ssh # cat ssh_host_key.pub ssh_host_dsa_key.pub ssh_host_rsa_key.pub > /mnt/floppy/ssh_known_hosts # umount /mnt/floppy Теперь вставляем дискету в дисковод анализатора и копируем полученный файл на свое место. # mount -t vfat /dev/fd0 /mnt/floppy # cd /etc/ssh # cp /mnt/floppy/ssh_known_hosts . # umount /mnt/floppy Теперь на анализаторе необходимо сгенерировать от имени пользователя shadow ключи и скопировать их затем на датчики. # su – shadow В некоторых дистрибутивах при создании пользователя создается и каталог .ssh, если такого нет, создаем его. # mkdir .ssh # chmod 700 .ssh # cd .ssh Генерируем ключи: # /usr/bin/ssh-keygen -b 1024 -t dsa -f .id_dsa
# /usr/bin/ssh-keygen -b 1024 -t rsa -f .id_rsa2
В этом моменте в документации допущена ошибка. По умолчанию ключ rsa генерирует вторую версию, а в инструкции указано rsa2, что приводит к ошибке. Номер показывать необходимо как раз для первой версии. # /usr/bin/ssh-keygen -b 1024 -t rsa1 -f .id_rsa1
# cat .id_dsa.pub .id_rsa2.pub .id_rsa1.pub > authorized_keys # mount -t vfat /dev/fd0 /mnt/floppy/ # cp authorized_keys /mnt/floppy/ # umount /mnt/floppy И на датчиках: # mount -t vfat /dev/fd0 /mnt/floppy # cd /home/shadow/.ssh # cp /mnt/floppy/authorized_keys . # umount /mnt/floppy Теперь можно попробовать зайти с анализатора по ssh на датчик от имени пользователя shadow. Если получилось, то можно продолжать дальше. Иначе проверьте имена файлов и права доступа к ним (700 для каталогов и 600 для файлов). Тему безопасности соединений ssh можно продолжать и далее. Например, используя инструкции ListenAddress и AllowUsers файла /etc/ssh/sshd_config можно еще более сузить диапазон возможных действий пользователя. Еще для полноценной работы необходимо установить nmap и сконфигурировать sudo, для того чтобы Apache мог его запустить. Для этого редактируем файл /etc/sudoers, примерно так. # Host alias specification Host_Alias SHADOW = analyzer1.com, analyzer2.com # Cmnd alias specification Cmnd_Alias NMAP = /usr/bin/nmap # User privilege specification root ALL=(ALL) ALL apache SHADOW=NOPASSWD: NMAP Кроме того, такой инструмент, как nmap, не рекомендуется раздавать кому попало, тем более что он запускается от имени root. Поэтому некоторые скрипты, находящиеся в /home/shadow/httpd/cgi-bin/privileged (в документации здесь тоже ошибка), защищены дополнительно файлом .htaccess с использованием директивы Satisfy (надо отметить, что в большинстве советов по построению защищенного веб-сервера, о Satisfy почему-то забывают). Теперь при запросе из незащищенной сети от пользователя потребуют дополнительной авторизации. AuthType Basic AuthName "Privileged SHADOW Users" AuthUserFile /usr/local/SHADOW/httpd/cgi-bin/privileged/nmap_pwd Satisfy any require valid-user order deny,allow deny from all allow from 172.16.47 Как видите, только пользователи сети 172.16.47 могут запускать nmap без ввода пароля. Пароль можно создать при помощи htpasswd, формат вызова которой: htpasswd -c /path/to/store/password username Например: # htpasswd -c /usr/local/SHADOW/httpd/cgi-bin/privileged/nmap_pwd grinder Опция -с создает файл заново, что нам сейчас и нужно, но при добавлении нового пользователя в уже используемый файл вызывайте htpasswd без нее. В каталоге /usr/local/SHADOW/filters имеются шесть фильтров, отдельно для каждого протокола, с подробными комментариями внутри: filter.getall.doc, goodhost.filter.doc, icmp.filter.doc, ip.filter.doc, tcp.filter.doc, и udp.filter.doc. Скрипт find_scan.pl использует файл filter.getall.doc для определения внутренних сетей, fetchem.pl при помощи good host.filter.doc определяет свои mail, web servers и DNS-серверы. После проверки адресов и внесения своих параметров убираем комментарии при помощи скрипта comment_strip. # /usr/local/SHADOW/comment_strip ip.filter.doc > /usr/local/SHADOW/filters/Site1/ip.filter # /usr/local/SHADOW/comment_strip icmp.filter.doc > /usr/local/SHADOW/filters/Site1/icmp.filter # /usr/local/SHADOW/comment_strip tcp.filter.doc > /usr/local/SHADOW/filters/Site1/tcp.filter # /usr/local/SHADOW/comment_strip udp.filter.doc > /usr/local/SHADOW/filters/Site1/udp.filter # /usr/local/SHADOW/comment_strip goodhost.filter.doc > /usr/local/SHADOW/filters/Site1/goodhost.filter #/usr/local/SHADOW/comment_strip filter.getall.doc > /usr/local/SHADOW/filters/Site1/filter.getall После чего рекомендуется проверить работу фильтров. # tcpdump -i eth0 -n -F /usr/local/SHADOW/filters/Site1/tcp.filter Если не получена ошибка «parse error», то фильтр можно использовать в работе. Теперь осталось заглянуть в файл /usr/local/SHADOW/etc/shadow.conf, который содержит настройки для конкретной системы. Надо отметить, что появление этого файла в последних версиях SHADOW заметно упростило настройку, теперь многие скрипты берут параметры отсюда. Ранее все параметры приходилось вбивать в каждый файл, что приводило к ошибкам и затрудняло конфигурацию. Проверьте, чтобы совпадали пути к утилитам и измените IP-адреса и e-mail на реальные. После этого его можно скопировать в /etc или просто создать символическую ссылку. # ln –s /usr/local/SHADOW/etc/shadow.conf /etc/shadow.conf На сенсорах файл /etc/shadow.conf не используется, вместо него применяется файл Site.ph, лежащий в /usr/local/SHADOW/sites/. Файл примера, который найдете в этом каталоге, содержит настройки для первого детектора «Outside Network Perimeter» с именем Site1.ph. Для других детекторов параметры $SITE и $SITE_LABEL и имя необходимо изменить, сверившись с /etc/shadow.conf. Кроме того, в переменных $SENSOR, $WEB_SERVER и @LOCAL_IP проставьте нужные параметры. Переменная $SENSOR_DIR=»/LOG», указывает на каталог, куда детекторы будут сохранять собранные данные. Мне показалось, что-то вроде /var/shadow с вынесеным в отдельный дисковый раздел /var будет более правильно. Теперь осталось проверить наличие всех каталогов, указанных в переменных файлов /etc/shadow.conf на анализаторе и Site1.ph на всех детекторах и изменить пользователя/группу chown –R shadow:shadow, где это потребуется. Все детекторы собирают информацию (не менее часа), теперь можно попробовать ее получить и проанализировать. Для начала лучше это проделать вручную. Для получения информации с определенного детектора используется скрипт fetchem.pl. Основная задача которого получить с указанного детектора нужный файл, содержащий собранные данные, создать для него подкаталог на анализаторе и выходной html-файл, сортировать данные, заменить IP-адреса именами и еще много чего. Например, данные за 21 час 31 октября 2004 года, с выводом логов в /tmp/fetchem.log можно получить так. # /usr/local/SHADOW/fetchem.pl -l Site1 -d 2004103121 -debug В результате с указанного детектора будет скачан файл с указанными данными и положен в /usr/local/SHADOW/data/Site1/Oct31/tcp.2004103120.gz. После первичного анализа в домашнем каталоге веб-сервера будет создан каталог /home/shadow/html/tcpdump_results/Site1/Oct31 с несколькими файлами, пользователю будет выводиться 2004103121.html. Для автоматизации этого процесса в работе используется cron-файл analyzer_crontab.shadow # Run fetchem to get SHADOW data files: # SHADOW_PATH=/usr/local/SHADOW # 1 * * * * $SHADOW_PATH/fetchem.pl -l Site1 3 * * * * $SHADOW_PATH/fetchem.pl -l Site2 -debug # # Cleanup once per day. # 15 1 * * * $SHADOW_PATH/cleanup.pl -l Site1 24 1 * * * $SHADOW_PATH/cleanup.pl -l Site2 # # Collect statistics each night. # 1 0 * * * $SHADOW_PATH/stats/do_daily_stats.pl -l Site1 1 3 * * * $SHADOW_PATH/stats/do_daily_stats.pl -l Site2 Теперь можно запускать браузер и пробовать соединиться с веб-сервером, запустится два окна (рис. 2). В результате экспериментов выяснилось, что левая панель инструментов, запускаемая из /cgi-bin/tools.cgi не может быть нормально отображаться всеми браузерами. Разработчики указали на совместимость практически со всеми браузерами старых версий, но из всего имеющегося набора в SuSE 9.1 комфортно работать можно было только в konqueror. Вероятно, функции, прописанные в openwin.js, требуется переписать.
Рисунок 2 Если подойти к процессу настройки внимательно и творчески, то сейчас все должно работать. И только при желании для удобства использования можно потихоньку подправить скрипты под себя. В дальнейшем необходимо изучение захваченной информации и подстройка фильтров, для того чтобы система получала только необходимое. Успехов. |
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
