Технологии протоколирования Honeypot в обеспечении безопасности сетевых UNIX-систем

АНТОН ДАНИЛЕНКО

Технологии протоколирования Honeypot

в обеспечении безопасности сетевых UNIX-систем

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

За основу мы возьмем операционную систему FreeBSD, одну из наиболее популярных в нашей стране, гибкую в настройке и поддерживающую все необходимое программное обеспечение. Большинство Unix-систем объединяет то, что они имеют единую систему протоколирования Syslog, реализация которой настолько удачна, что ее поддержка реализована также в других системах, например, в Windows, правда, к сожалению, не самой фирмой-разработчиком, а сторонними энтузиастами. В ОС Linux и FreeBSD в качестве протоколирующего сервиса используется syslogd, который имеет ряд недостатков и скудные возможности в конфигурировании, в частности отсутствие возможности пересылать протоколы работы служб через TCP/IP или по почте, возможности шифрования передаваемых сообщений, протоколирование с использованием баз данных (mysql). Все эти функции реализованы в более серьезном бесплатном продукте syslog-ng, который мы и будем использовать. В качестве сопутствующего обеспечения будем использовать stunnel для шифрования передаваемых системами протоколирования данных через SSL.

Данную схему можно реализовать двумя способами. В пределах одной физической машины и в масштабе целой сети. Рассмотрим варианты на рисунках соответственно 1 и 2.

Рисунок 1		Рисунок 2

Как видно из рисунка 1, сервер протокола отделяется от машины с сервисами встроенными функциями операционной системы, а именно jailed-окружением (jail – тюрьма). Надо заметить, что эта технология как в ОС FreeBSD, так, впрочем, и в других системах реализована крайне неполно, а именно: практически нет разделения ресурсов между машинами (загрузка процессора, памяти и пр.). Хотя работа, которая ведется разработчиками FreeBSD 5.0 в этом направлении, внушает некоторый оптимизм, полноценно реализована эта технология только в коммерческих продуктах, таких как Virtuozzo. Обычно обе схемы используются одновременно. Т.е. на серверах-клиентах рисунка 2 реализуется схема, изображенная на рисунке 1. Таким образом система протоколирования получается более защищенной. Итак, приступим к настройке.

Настройка протоколируемого сервера

Шаг 1. Создание jail-машины

Если вы только что установили свежую систему (make world), воспользуйтесь следующим скриптом:

#!/bin/sh

D=/JAIL/jail1 # is do use a special mounted partition

mkdir –p ${D}

cd /usr/src

make hierarchy DESTDIR=$D

make obj

make depend

make all

make install DESTDIR=$D

cd etc

make distribution DESTDIR=$D –DNO_MAKEDEV_RUN

cd $D/dev

sh MAKEDEV jail

cd $D

ln –sf dev/null kernel 

Если вы не делали инсталляции системы, то запустите скрипт, представленный ниже:

#!/bin/sh

D=/JAIL/jail1

cd /usr/src

make world DESTDIR=$D

cd etc

make distribution DESTDIR=$D –DNO_MAKEDEV_RUN

cd $D/dev

sh MAKEDEV jail

cd $D

ln –sf dev/null kernel

Шаг 2. Запуск jail-машины

После того как мы установили в выбранную директорию полностью готовую систему FreeBSD, требуется ее запустить. Встроенных приложений в ОС для работы с jail нет, поэтому я рекомендую воспользоваться утилитой jailadmin, написанной Kirk Strauser. Выполните следующие команды для установки:

mkdir –p /usr/src/distrib/jailadmin

cd /usr/src/distrib/jailadmin

wget http://subwiki.honeypot.net/pub/Freebsd/JailAdmin/jailadmin-1.5.tar.gz

tar xzvf jailadmin-1.5.tar.gz

./install.sh

Далее отредактируем файл конфигурации /usr/local/etc/jailadmin.conf, он имеет следующий вид:

jaildir=/var/jailed

virtual1

        ip: 192.168.0.2

        hostname: www.domain.com

virtual2

        ip: 192.168.0.3

        hostname: www.otherdomain.com

Где /var/jailed/virtual[n] – директории, в которые мы установили наши jail-системы.

Перед стартом jail в первую очередь нужно создать алиасы для включения IP-адресов виртуальных машин на материнской, например так:

ifconfig rl0 inet alias 192.168.0.2 netmask 255.255.255.255

ifconfig rl0 inet alias 192.168.0.3 netmask 255.255.255.255

После этого отредактируем /var/jailed/virtual[n]/etc/rc.conf для изменения стартовой конфигурации jail. Особенно рекомендую как на мастер-машине, так и на виртуальных машинах поменять ключи запуска inetd:

hostname=”www.domain.com”

syslogd_enable=”NO”

inetd_enable=”YES”

inetd_flags=”-wW –a 192.168.0.2”

sendmail_outbound_enable=”YES”

sendmail_outbound_flags=”-q30m”

sshd_enable=”YES”

Sshd впоследствии тоже следует «привязать» к конкретному IP-адресу.

Смонтируем директорию /usr/ports в jail:

mount –t union –o –b /usr/ports /var/jailed/virtual1/usr/ports/

Наша виртуальная машина готова к старту:

/usr/local/sbin/jailadmin start all

Шаг 3. Конфигурирование syslog-ng

Дальнейшие действия производятся также на материнской машине. Из jailed-окружения протоколы приложений через специально созданный в нем сокет будут передаваться общему с материнской машиной syslog-ng.

cd /usr/ports/sysutils/syslog-ng

make && make install

cp /usr/local/etc/syslog-ng/syslog-ng.conf.sample /usr/local/etc/syslog-ng/syslog-ng.conf

В /etc/rc.conf добавляем:

syslogd_program=”/usr/local/sbin/syslog-ng”

syslogd_flags=»»

Отредактируем файл конфигурации /usr/local/etc/syslog-ng/syslog-ng.conf:

source gateway {

   unix-dgram(«/dev/log»); # создаем /dev/log на материнской машине

   internal();

   unix-dgram(“/var/jailed/logs/dev/log”); # создаем  /dev/log в jailed-окружении

};

destination localhost {

  file(«/var/log/syslog-ng.all»); # дублируем все протоколы в файл на диске локальной машины

};

destination shell {

  tcp(«127.0.0.1» port(5140)); # перенаправляем все протоколы на локальный порт 5140, где «слушает» stunnel

};

log {

             source(gateway); destination(localhost);

             source(gateway); destination(shell);

};

Отключим стандартный syslogd:

kill `cat /var/run/syslog.pid`

Запускаем демона syslog-ng:

/usr/local/sbin/syslog-ng

Шаг 4. Настройка stunnel

wget http://www.stunnel.org/download/stunnel/src/stunnel-4.04.tar.gz

tar xzvf stunnel-4.04.tar.gz

cd stunnel-4.04/

./configure

make

make install

Отредактируем файл конфигурации /usr/local/etc/stunnel/stunnel.conf:

cert = /usr/local/etc/stunnel/stunnel.pem

pid = /tmp/stunnel.pid

setuid = nobody

setgid = nogroup

Cafile = /usr/local/etc/stunnel/certs.pem

debug = 7 # вывод дополнительной информации о работе stunnel (после настройки можно отключить)

output = stunnel.log # файл вывода дополнительной информации

client = yes        # работа в качестве клиента

[5140]

accept  = 5140

connect = 192.168.0.3:5140

# адрес и портсервера stunnel (сервера протоколов)

Запустим stunnel:

/usr/local/sbin/stunnel

Для того чтобы stunnel запускался во время загрузки системы, его нужно добавить в файл /etc/rc.local.

Опционально могу порекомендовать запускать syslog-ng и stunnel от имени непривилегированных пользователей.

Настройка сервера протоколов

Шаг 1. Настройка stunnel

Процесс установки stunnel на сервере протоколов будет отличаться от примера для клиентской части только конфигурационным файлом. Он будет иметь вид:

cert = /usr/local/etc/stunnel/stunnel.pem

pid = /tmp/stunnel.pid

setuid = nobody

setgid = nogroup

Cafile = /usr/local/etc/stunnel/certs.pem

debug = 7 # вывод дополнительной информации о работе stunnel (после настройки можно отключить

output = stunnel.log # файл вывода дополнительной информации

client = no     # работа в качестве клиента

[514]

accept  = 5140

connect = 192.168.0.2:514  # адрес и порт клиента stunnel

Шаг 2. Настройка syslog-ng

В данном случае настройка также будет отличаться от протоколируемого сервера только конфигурационным файлом.

Отредактируем /usr/local/etc/syslog-ng/syslog-ng.conf:

source gateway {

 unix-dgram(«/dev/log»); # создаем /dev/log на материнской машине

 internal();

 tcp(ip(192.168.0.2) port(514) max-connections(1));

};

destination localhost {

  file(“/var/log/syslog-ng.all”); # дублируем все  протоколы в файл на диске локальной машины

};

 

log {

             source(gateway); destination(localhost);

};

Запустим оба сервиса. Теперь у нас есть готовая связка серверов, состоящая из протоколируемого сервера в jail-окружении и сервера протоколирования, получающего информацию работы приложений по tcp/ip ovel SSL.

Защита приложений на клиент-серверах от пользователя root

Проблема нашей схемы состоит в том, что если злоумышленник получает права root в jailed-окружении, он может удалить как /dev/log, создаваемый syslog-ng материнской машины, так и любой другой системный файл. К сожалению, /dev/log защитить от удаления мы практически никак не можем, т.к. syslog-ng должен удалять и создавать его заново при перезапуске. Единственное решение здесь – это заставить приложения в обход /dev/log пересылать протоколы по tcp/ip. Для этого потребуется переписать syslog-ориентированные системные функции. Для проверки работы нашей связки можно, скажем, раз в минуту посылать из jailed-окружения произвольное сообщение. Остальные же файлы можно защитить следующим образом.

На материнской машине выполним:

sysctl kern.securelevel=1

Чтобы securelevel сохранялся при перезапуске машины, добавим в файл /etc/rc.conf:

kern_securelevel_enable="YES"

kern_securelevel="1"

При securelevel=1 никто, даже пользователь root, не сможет удалить с файлов immutable флаг, system append-only флаг, загрузить в ядро модули и пр.

Также я рекомендую вам включить опцию kern. ps_showallprocs=0, что позволит скрыть весь листинг процессов системы от пользователей рангом ниже root. Однако это только тюнинговое решение, т.к. злоумышленник может найти запущенные процессы, просмотрев /proc. Чтобы сделать изменение перманентным, отредактируйте /etc/sysctl.conf:

kern.ps_showallprocs=0

Далее поставьте immutable флаги на все нужные вам файлы. Я рекомендую поставить их на все важные для нормальной работы системы бинарные файлы, используемые ими библиотеки и файлы конфигурации. В нашем примере мы установим флаг на файл /usr/bin/login:

chflags schg /var/jailed/virtual1/usr/bin/login

Помимо этого способа, нужно не забывать о возможности смонтировать любую нужную директорию материнской машины в jail с правами root.

Теперь ваша система протоколирования настроена и достаточна защищена. Ее плюс в том, что скомпрометировав jail-сервер, злоумышленник не узнает даже о существовании сервера протоколов, не говоря уже о его IP-адресе.

Настройка реакции сервера протоколирования на зафиксированные происшествия

В любой системе активного мониторинга особую роль играет скорость реакции на какую-либо проблему. Для достижения наибольшей оперативности при поддержке сервера я рекомендую включить в схему еще одно звено – swatch.

Шаг 1. Установка swatch

Выполните следующие команды:

wget http://unc.dl.sourceforge.net/sourceforge/swatch/ ї swatch-3.0.5.tar.gz

tar xzvf swatch-3.0.5.tar.gz

cd swatch-3.0.5/

wget http://cpan.org/authors/id/S/ST/STBEY/Date-Calc- ї 5.3.tar.gz

wget http://ftp.u-picardie.fr/local/cricket/TimeDate- ї 1.08.tar.gz

tar xzvf Date-Calc-5.3.tar.gz

cd Date-Calc-5.3/

perl Makefile.PL

make

make test

make install

cd ../

tar xzvf TimeDate-1.08.tar.gz

cd TimeDate-1.08/

perl Makefile.PL

make

make test

make install

cd ../

perl Makefile.PL

make

make test

make install

make realclean

Примечание: Date-Calc и TimeDate необходимы для работы swatch, если они уже установлены на вашей системе, просто пропустите этап их инсталляции.

Далее отредактируем конфигурационный файл /etc/swatch.conf:

watchfor   /stunnel.*: .*Connection refused/

    echo

    exec echo $0 | mail -s\"Проблема с stunnel\" oncall\\@example.com

        throttle 30:00

watchfor   /attackalert:/

    echo

    exec echo $0 | mail -s\"Предупреждение об атаке portsentry\" oncall\\@example.com

        throttle 5:00

watchfor   /No space left on device/

    echo

    exec echo $0 | mail -s\"Не хватает свободного места на диске\" oncall\\@example.com

        throttle 30:00

watchfor   /\'su root\' failed/

        echo bold

        exec echo $0 | mail -s\"Неудачная попытка su root\" oncall\\@example.com

        throttle 30:00

Шаг 2. Настройка syslog-ng для работы со swatch

Чтобы настроить syslog-ng для работы со swatch, внесите следующие изменения в его конфигурационный файл:

  destination swatch {

    program("/usr/bin/swatch --read-pipe="cat /dev/fd/0"");

  };

  # посылать все протоколы swatch

  log {

    source(src);

    destination(swatch);

   };

Чтобы запускать swatch от имени пользователя syslog:

destination swatch {

    program("su syslog -c "/usr/bin/swatch --read- ї pipe="cat /dev/fd/0""");

  };

Как видно из примера, swatch легко интегрировать в нашу уже работающую систему протоколирования.

Резюме

Как бы не была хороша и безопасна представленная система протоколирования, она не поможет вам ровно ничем в предотвращении вторжений/утечек информации без перманентного слежения за ее работой и обрабатываемыми ею протоколами. Нельзя забывать, что протоколирование – лишь средство экстренного оповещения, а не панацея от всех бед. Главная же задача администратора безопасности – это не допустить компрометирования системы как таковой. Нужно следить за появлением уязвимостей во всех функционирующих на серверах сервисов, выходом заплаток и обновлений. Нужно тщательно продумывать политику как внешней, так и локальной безопасности. Даже если в системе нет валидных пользовательских учетных записей, необходимо предусмотреть возможность получения прав в системе путем компрометирования одного из внешних сервисов. Также в среде информационной безопасности известно множество способов обеспечения как повышенного уровня безопасности систем, так и способов облегчения задачи их администрирования. Например, у вас есть два сервиса: web и ftp. Соответственно, вам постоянно приходится следить за обновлениями обоих продуктов. Однако многие не знают, что эти оба сервиса можно скрыть от Интернета и сделать доступными через прокси-сервер, например, squid, который будет как защищать сервисы, так и ускорять их работу. Таким образом, вам придется следить за обновлениями только одного продукта вместо двух. Что касается локальной безопасности, существует множество серьезных решений, которые защищают систему от вторжения изнутри. Защищают нужные вам процессы, программы и данные. Для платформы Linux подойдут такие решения, как gresecurity (www.grsecurity.net), lids (www.lids.org) и т. д. В BSD-системах используются реализации jailed-/chrooted-окружений, а также многочисленные встроенные функции системы, ориентированные на безопасность. Причем эти решения, порой, настолько развиты, что могут защищать систему не только от внутренних, но и от внешних вторжений. Gresecurity, например, может на лету блокировать посылаемые сервисам shell-codes в результате переполнений буфера или других атак. Если вы только начинаете заниматься безопасностью вашей уже функционирующей в Интернете системы, можно воспользоваться дополнительными средствами аудита, такими как сканеры сетевой безопасности. Результаты сканирования позволят вам сделать вывод об общем состоянии вашего сервера, критических уязвимостях сервисов и стабильности работы системы в целом. В любом случае надо помнить, что с совершенствованием технологий защиты, совершенствуются и автоматизируются технологии нападения. Таким образом, люди, которые, порой, в своих знаниях недалеко ушли от рядовых пользователей, могут нанести существенный урон критически важным данным серьезных компаний, воспользовавшись кем-то написанными и опубликованными средствами атаки.