• Безопасность сервера / Основные методы защиты *nix-систем
  • Выжми все из фаервола! / Возможности iptables
  • Хитрый тюнинг и грамотная защита / Приемы настройки сервера
  • Логи для умных / Система log-файлов для *nix-систем
  • IDS/SNORT / Системы обнаружения атак
  • Хакеры любят мед / Разбираемся в работе Ноneypot

    • Защита

    Безопасность сервера / Основные методы защиты *nix-систем

    Антон Карпов (toxa@real.xakep.ru)

    Всем давно понятно, что фраза «*nix – безопасная ОС» по своей сути некорректна. *nix, если под этим понимать дизайн, реализацию ядра ОС и базовую ее начинку (утилиты), лишь предоставляет отличные предпосылки для построения на своей базе защищенной серверной системы. Но на одном ядре и прикладных утилитах сервер не построишь, нужны сервисы, и безопасность их напрямую не связана с безопасностью операционки. Помнишь известные слова: «Безопасность – это не продукт, а процесс»? Так вот, безопасность как процесс – не свойство системы, а свойство взаимодействия системы и админа, который ее настраивает.

    Мы рассмотрим типичный сценарий установки, настройки и сопровождения сервера с точки зрения security-параноиков. Мне не хотелось бы давать разрозненные советы из серии «хозяйке на заметку», поэтому мы пройдем по шагам все этапы от установки ОС до запуска сервисов, обращая внимание на важные моменты. Я не буду предлагать здесь детальное руководство по настройке каждого сервиса, а лишь дам общие советы, которые нужно иметь в виду. По этой же причине я не завязываюсь на конкретную ОС – кто-то любит Linux, кто-то FreeBSD, а кто-то по долгу службы обхаживает Solaris. Замечания по определенной ОС, если таковые встретятся, будут даваться по ходу.

    Спасительные флаги

    Веселье начинается уже при разметке винчестера на партиции при установке системы. В Linux-мире как-то не принято обращать на это серьезное внимание, и один большой корневой раздел (/) на всю систему там – норма. Иногда, правда, выделяют /home. Но этого все равно мало. Не зря опыт поколений рекомендует иметь как минимум следующие разделы:

    / – корневой;

    /home – если сервер будет иметь много пользовательских учетных записей (хостинг, хранение почты, FTP-архив, да практически всегда);

    /tmp – обязательно выделяй /tmp в отдельный раздел диска;

    /var – для хранения логов, спула почты, бэкапов и прочего мусора;

    /usr – для исполняемых файлов, библиотек, исходных текстов системы.

    Пользователи BSD могут прочитать более подробное описание исторически сложившейся иерархии в man 7 hier, для остальных систем существует схожий (хотя и спорный) документ Filesystem Hierarchy Standart (FHS, www.pathname.com/fhs). Но какое это имеет отношение к безопасности? Дело в удобстве оперирования флагами монтирования. Любая файловая система позволяет указать набор флагов, с которыми будет примонтирована соответствующая партиция, и некоторые из них имеют непосредственное отношение к безопасности системы. Покажу это на примере FFS (Fast File System), практически все остальные FS имеют схожие по названию флаги (см. «man mount» в своей системе).

    noexec – запрещает исполнять файлы;

    nosuid – запрещает повышение привилегий для исполняемых suid/sgid файлов. Иными словами, теряется suid-бит и программа выполняется как обычная;

    nosymfollow – запрещает использование символических («мягких») ссылок;

    nodev – запрещает использование файлов устройств.

    В общем случае операционке, безусловно, нужно иметь возможность исполнять файлы. Также в системе обязательно присутствует некоторое количество суидных программ, да и ссылки тоже, как правило, имеются. Но есть ли смысл в суидных файлах, например, в каталоге /tmp? Часто хакеры бросают суидный /bin/sh куда-нибудь в складки /tmp или здесь же компилируют эксплоит, пока еще не имея прав рута, но надеясь их получить. То же касается и пользователей в их домашних каталогах. Вряд ли среднестатистический хостер, дающий своим клиентам доступ по ssh для правки\заливки контента, нуждается в том, чтобы эти клиенты что-то у себя запускали или, тем более, компилировали и затем запускали. Поэтому очень часто на /tmp и /home оправданы флаги nosuid, а нередко и noexec. В некоторых случаях они могут помешать, например, noexec на /tmp не позволит пересобрать мир (make world) на FreeBSD, но это не более чем кратковременное исключение. Нет нужды пояснять, что в случае одного большого раздела (/) такая манипуляция флагами была бы исключена. Сам же корневой раздел, включающий каталоги с конфигурационными файлами системы, базовыми бинарниками, библиотеками и ядром, вполне реально монтировать в режиме read-only.

    Не лишен смысла также трюк против злонамеренных операций с ядром (таких, как его перекомпиляция и замена :)), заключающийся вот в чем. Каталог /boot, в котором находятся ядро, в случае BSD и модули с конфигурационным файлом loader.conf, а в случае Linux – файл предварительной загрузки модулей initrd, оформляется в виде отдельного раздела на каком-нибудь съемном носителе (USB-флэшка), с него производится загрузка, а затем, после запуска системы и загрузки всех модулей, раздел размонтируется и носитель вынимается (кладется в сейф :)). Подменить ядро, initrd или подсунуть модуль становится на порядок проблематичней.

    Помимо флагов на FS существуют дополнительные атрибуты безопасности на файлы. В BSD атрибуты выставляются и просматриваются командой chflags(1), в Linux – chattr(1)/lsattr(1). Так, из полезных флагов chfags(1) можно выделить:

    sappnd – позволяет открывать файл только в режиме «append only»;

    schg – выставляет флаг «immutable», такой файл нельзя переместить, удалить или переименовать;

    sunlnk – запрещает удаление файлов.

    Эти флаги имеет право выставлять/снимать только суперпользователь. Но даже если взломщик получил права рута, они могут спасти от катастрофы, если помимо флагов приняты другие меры безопасности.

    Выживает сильнейший

    При старте системы запускаются всевозможные сервисы. Какие-то системы (OpenBSD) относятся к этому моменту очень ответственно, запрещая по умолчанию практически все, какие-то (большинство дистрибутивов Linux) действуют в лучших традициях Windows-style, запуская все, что может когда-либо понадобиться. «ps wax» («ps -ef» в Solaris) покажет тебе, кто понапрасну работает, а «sockstat -l» (во FreeBSD) и «netstat -na | grep LISTEN» – кто понапрасну биндит порты, ожидая remote эксплоита по свою душу. Рекомендую также и полезную утилиту lsof (list of open files), которая, сродни bsd'шному sockstat, показывает, какие сокеты или устройства открыты определенными процессами. Ничего нового здесь придумать нельзя – отключаем все, что не нужно, правкой rc.conf в BSD, ковырянием в /etc/init.d/ или /etc/rc.d/ – в Linux и Solaris и т.д. Некоторые демоны по умолчанию слушают сетевой сокет, тогда как вполне могут обойтись без него, например, syslogd(8), который, если нет необходимости принимать логи по сети, рекомендуется запускать с флагом -ss (secure mode).

    Те же сервисы, что нам нужны, тоже должны иметь кредит доверия. Тут тебе не Windows, и выбор сравнимых по функциональности демонов имеется. Если с системы не планируется сдувать пылинки, пребывая в боевой готовности пропатчить, скажем, почтовый сервер сразу, как только выйдет secuity advisory, то выбор сервисов с хорошей репутацией и отсутствием истории уязвимостей – первейшее дело. Хотя хороший админ все равно должен уметь быстро реагировать (баги находят везде), ничто не мешает ему снизить шанс форсмажора до минимума (где-то все же их находят существенно чаще). Не буду призывать использовать что-либо конкретное, но если ты не законченный фанат какой-либо одной программы либо тебе не нужна особая функциональность определенного демона, то знай, что гарантированно не доставят тебе головой боли из smtp-серверов qmail и postfix, из ftp-серверов – vsftpd, pureftpd и publicfile, из DNS-серверов – djbdns, из pop3-серверов – все тот же qmail и popa3d. Впрочем, история показывает, что опытные админы, как правило, консервативные фанаты определенного круга программ и предпочтут патчить свое детище раз в неделю, чем перейти на альтернативный продукт ;).

    Отдельно хочется сказать про «суперсерверы» inetd и xinetd. Они существуют для поддержки демонов, которые не умеют запускаться в так называемом standalone-режиме, то есть принимать сетевые соединения, самостоятельно ограничивать количество одновременных сессий, использовать возможности tcp-wrappers и т.п. В таком случае inetd/xinetd выступают в качестве посредника между клиентом и сервером, реализуя вышеописанные возможности. При всем удобстве «суперсерверов» их идея не кажется мне замечательной. Во-первых, если «положить» inetd DoS-атакой или эксплоитом, то упадут и все обслуживаемые им демоны. Во-вторых, большинство используемых для работе в агрессивном интернете сервисов умеют самостоятельно отрабатывать почти все, что предлагает inetd. «Суперсервер» – это сложная система, так что лучше не использовать ее там, где без нее можно обойтись. Гуру безопасного программирования Дэн Бернстейн предлагает свой вариант под названием tcpserver (ucsp-tcp), частично выполняющий функции inetd. Если есть необходимость запустить программу, требующую inetd, можно воспользоваться tcpserver, который частично избавляет от неудобств inetd.

    Каким бы безопасным ни был демон, существуют механизмы, позволяющие администраторам еще крепче спать по ночам. Процесс, взаимодействующий с пользователем, должен исполняться от имени непривилегированного пользователя. И правда, сегодня найти apache или named, запущенный от рута, довольно сложно ;-). Помимо этого каждый демон можно изолировать в его собственной среде. Образно, все необходимые для работы демона файлы и библиотеки копируются в измененный корневой каталог, и затем в получившуюся иерархию выполняется системный вызов chroot(2). С точки зрения демона, он работает в нормальной среде, ведь все необходимые для него файлы присутствуют, зато взломщик, получив контроль над дырявым сервисом, будет не в состоянии даже получить shell, так как /bin/sh может просто отсутствовать в chroot-директории. Во FreeBSD эту идею развили, и присутствующий там системный вызов и утилита jail(8) совместно с удобным управлением через sysctl-переменные позволяют удобно засадить демона «за решетку», из благих побуждений.

    Еще одно веяние времен эпохи параноиков – отслеживание системных вызовов, совершаемых программой, и дальнейшее их ограничение. Любое действие программы (такое, как чтение файла или открытие сетевого сокета) – это системный вызов ядру ОС. Значит, можно ограничить набор легитимных вызовов для каждой программы. Действительно, зачем DNS-серверу биндить какой-либо локальный порт, кроме 53-го, для приема входящих запросов? Механизм systrace (www.citi.umich.edu/u/provos/systrace), присутствующий в стандартной поставке OpenBSD и NetBSD, а также портированный на остальные платформы, занимается тем, что отслеживает системные вызовы программ и сопоставляет их с указанной политикой. Любые аномалии протоколируются, и соответствующий системный вызов запрещается. В идеале это означает, что shell-коду можно помахать платочком.

    Наконец, не только бесполезные сервисы следует убирать из системы. Зачем, например, на настроенной и работающей машине компилятор или дизассемблер? Чтобы взломщику было легче скомпилить и применить сплоит? Многие дистрибутивы Linux практикуют исключительно binary upgrade, так что компилятор там может вообще не понадобиться.

    Ядро. Без паники

    Обезопасив свои сервисы, обратим взор к ядру. Так как обыкновенная подмена системных утилит в два счета детектится системой контроля целостности, то без вариаций на тему модульного руткита не обходится ни один серьезный хакер. Не так уж это и страшно. Самое простое – собрать ядро без поддержки модулей. Для FreeBSD существует патч, позволяющий собрать ядро с опцией NO_KLD (people.freebsd.org/~cjc – не самый, правда, свежий). В Linux достаточно просто не указывать соответствующую опцию CONFIG_MODULES=n. К несчастью, многие производители железа предоставляют драйвера для своей продукции в виде подгружаемых модулей, исключительно в бинарном виде. В BSD эту, а заодно и многие другие проблемы, снимает kernel securelevel(8). В многопользовательском режиме он может принимать значения -1, 1, 2 и 3.

    –1 – не накладывает никаких ограничений («небезопасный режим»). По умолчанию система запускается с таким значением;

    1 – «безопасный режим», запрещает снятие флагов immutable и append-only даже root'у, запрещает писать в память ядра или совершать привилегированные операции ввода/вывода на уровне ядра (/dev/mem, /dev/kmem, /dev/io), запрещает загрузку/выгрузку модулей ядра;

    2 – «очень безопасный режим», наследует все возможности предыдущего режима, а также не позволяет ничего писать на примонтированные файловые системы;

    3 (присутствует во FreeBSD) – «сетевой безопасный режим», наследует возможности безопасного, а также не позволяет менять конфигурацию правил пакетного фильтра (удалять или добавлять правила).

    Значение securelevel выставляется утилитой sysctl (переменная kern.securelevel) после запуска системы и загрузки всех модулей и демонов и во время работы системы может быть только увеличено. Практически всегда сервер без графической системы X-Window или прочей экзотики обязан без проблем работать со значением kern.securelvel=1; если же он по совместительству является фаерволом с постоянным набором правил фильтрации, то со значением kern.securelvel=3. Очень многие пренебрегают это полезной возможностью, а ведь в таком случае, чтобы загрузить вредоносный модуль или добавить свое правило в цепочку пакетного фильтра, взломщику придется перезагрузить машину, что не может остаться незамеченным.

    Помнится, один известный в определенных кругах хакер временно залочил мне аккаунт на его FreeBSD-боксе, мотивировав это тем, что «там сейчас крутится много важных процессов», видимо, опасаясь команды «ps -a» с моей стороны. Однако если бы он знал о существовании sysctl-переменной kern.ps_showallprocs (security.bsd.see_other_uids для FreeBSD 5), то, возможно, не стал бы принимать столь крайние меры. Выставление этой переменной в 0 позволит пользователям любоваться списком исключительно своих процессов, скрывая чужие. Это незаменимо на хостингах, где много пользователей имеют shell-аккаунт.

    Часто хакеры запускают на взломанной машине снифер, особенно если эта машина – пограничный маршрутизатор, через который проходит весь трафик. В Linux для этого необходима библиотека libpcap, а вот в BSD пакеты ловятся через псевдоустройство bpf(4) (berkeley packet filter), вкомпилированное в ядро или загруженное как модуль. Часто отсутствие bpf(4) в системе (в любом виде) может быть оправдано с точки зрения безопасности. Без него снифинг пакетов в BSD невозможен. Но, правда, невозможна и, например, корректная работа пакетного фильтра OpenBSD PF, так что всегда есть исключения.

    Еще одна вещь, которая может помочь при расследовании инцидентов, да и вообще полезна в качестве контроля за системой, это аккаунтинг процессов (во FreeBSD включается установкой переменной accounting_enable="YES» в /etc/rc.conf, в Linux – CONFIG_BSD_PROCESS_ACCT=y в конфиге ядра). Будучи включенным, он протоколирует в /var/account/acct (в Linux – /var/log/pacct) запуск всех процессов, позволяя посмотреть, когда, что и от имени какой учетной записи было запущено (lastcomm(1)), а также позволяет выдать статистику по выполненным процессам (sa(8)).

    Аудит системы

    Хорошая система должна требовать минимум внимания. В идеале, около трех секунд в день – ровно столько нужно времени, чтобы пробежать глазами ежедневный отчет и убедиться в отсутствии аномалий. В отчет должны включаться как минимум мониторинг создания новых учетных записей (если взломщик имел неосторожность добавить пользователя или сменить пароль существующему, ты это заметишь), появление новых суидных программ, количество заблокированных фаерволом пакетов и количество попыток неудачного входа в систему. Все эти меры призваны обнаружить атаки на ранней их стадии. В BSD подобный отчет генерируется по умолчанию, утилитой periodic(8). По сути, она выполняет последовательность скриптов, запускаясь по расписанию из crontab(1), результат работы сваливается администратору в почту. В /etc/periodic.conf можно определить указанные в /etc/defaults/periodic.conf опции составления отчета – помимо репорта periodic(8) может выполнять скрипты очистки /tmp, бэкапа важных файлов и т.п.

    Помимо самой системы уязвимости находят и в софте, инсталлируемом из пакетов/портов. Полезно, конечно, читать адвайзори от вендоров, но наиболее удобный способ – положиться на автоматизированный аудит безопасности. Так, во FreeBSD имеется утилита portaudit (/usr/ports/security/portaudit). Она скачивает базу уязвимостей и анализирует установленные пакеты на предмет присутствия их в текущем списке проблемных программ.

    Пропиши скачивание свежей базы в crontab(5) (корректнее: установи daily_status_security_portaudit_enable="YES» в /etc/periodic.conf) и любуйся ежедневными отчетами.

    Нетрадиционные методы

    Если ты заметил, BSD больше подходит для организации защищенной системы в рамках классической модели безопасности UNIX. Тому способствуют как защитные механизмы системы (kernel securelevel, jail, systrace), так и средства аудита (accounting, periodic), доступные, что называется, «из коробки». Но можно пойти дальше и радикально поменять саму модель защиты, вместо традиционной дискреционной модели доступа применив одну из мандатных моделей. Это уже серьезно и требует хотя бы поверхностного знакомства с моделями безопасности. И здесь выигрывает Linux, для которого существуют такие проекты, как RSBAC (www.rsbac.org) и SELinux (www.nsa.gov/selinux). Они делают из Linux мощную систему с поддержкой Role Based Access Control (RBAC), Domain Type Enforcement (DTE) и кучей другого. Во FreeBSD 5, правда, тоже появилась возможность контроля доступа по расширенным атрибутам файлов (Mandatory Access Control), но это капля в море. Мандатные модели доступа – отдельная, серьезная тема, сложная в реализации применительно к конкретному production серверу и требующая внимательной эксплуатации.

    Напоследок процитирую известную фразу: «If you fuck up OpenBSD it gets unsecure. Linux must be fucked up to be secure. Windows must be secure erased to be secure». Доля правды в ней есть, но помни, что главное для безопасности системы – не операционка, а тот, кто ей управляет.

    Бойся жестких ссылок

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

    Посмотри полный вывод команды ls:

    ЛИСТИНГ

    [(3:47)(85.32%)(p3):~ ] ls -al rfc2818.txt

    –rw-r-r– 1 toxa toxa 15170 15 июл 19:54 rfc2818.txt

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

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

    Почему же просто не скопировать программу себе в каталог? А потому, что потеряются первоначальные права на файл и владельцем вместо рута станет хакер, после чего наличие на ней suid-бита станет бессмысленным.

    Следи за паролями

    Если заглянуть в /etc/shadow (/etc/master.passwd в BSD), то можно увидеть массу системных учетных записей, но все они залочены – в поле пароля вместо хэша у них символ «*» или «!!», а вместо шелла – что-то вроде /sbin/nologin или /bin/false. Если у системного пользователя (не реального юзера) ты увидишь прописанный реальный шелл и хэш пароля, бей тревогу.

    Безопасность – это не продукт, а процесс.

    При желании ядро можно убрать в ящик в прямом смысле слова :).

    Еще одно веяние времени эпохи параноиков – отслеживание системных вызовов, совершаемых программой, и дальнейшее их ограничение.

    Изначальный подсчет контрольных сумм (MD5-хэшей) системных утилит и файлов и дальнейшая их проверка с помощью утилит типа tripwire или aide может избавить от сильной головной боли в дальнейшем. В случае изменения файла утилита найдет расхождение в MD5-отпечатке и поднимет тревогу.

    Хардлинки работают только в пределах одной файловой системы (одной партиции).

    Найти все suid/sgid бинарники в системе можно следующей командой:

    # find / -type f \( -perm -4000 -o -perm -2000 \) -ls

    цифра 4 в маске означает suid, 2 – sgid.

    Выжми все из фаервола! / Возможности iptables

    Докучаев Дмитрий aka Forb (forb@real.xakep.ru)

    Фаервол – неотъемлемая часть *nix-системы. Но, как любой программный продукт, он нуждается в тщательной настройке. Сейчас я расскажу о том, как грамотно защитить свой сервер с помощью сетевого экрана iptables. Этот фаервол является самым простым и надежным, поэтому рекомендую ознакомиться с этим материалом.

    Грамотный админ никогда не забудет установить фаервол на свою машину. Ведь брандмауэр позволяет решать множество важных задач. В первую очередь, он «заботится» о сетевой безопасности, фильтруя хакерские пакеты. При желании можно замутить и локальную безопасность, запретив юзерам выкачивать порнофильмы и варезные программы. Также с помощью сетевого экрана реально поднять NAT (Network Address Translation), позволяющий локальным машинам полноценно юзать ресурсы интернета.

    Закроемся от внешних врагов

    Если ты работал с iptables, то знаешь принцип действия этого фаервола. Он содержит несколько таблиц, в каждой из которых могут находиться так называемые цепочки. Дефолтовая таблица filter содержит три цепи – INPUT, OUTPUT и FORWARD. Первая отвечает за входящие пакеты, вторая – за исходящие. Последняя служит для управления обменом данных между соседними узлами. Наиболее популярный метод настройки iptables заключается в добавлении разрешающих правил в цепь INPUT с последующим изменением ее политики. У каждой цепочки есть своя политика: ACCEPT, REJECT и DROP. По умолчанию все пакеты проходят без ограничений. Но стоит лишь изменить политику на REJECT (запрещение соединения с взведением флага RST в ответном пакете) или DROP (простое игнорирование пакета), как данные будут нещадно отфильтровываться. Естественно, что администратор заранее пропишет правила, по которым нужные пакеты будут без проблем проходить на сервер.

    Давай проведем подобную настройку фаервола. В первую очередь, позаботимся, чтобы пакеты беспрепятственно проходили через петлевой интерфейс (нам незачем запрещать локальные соединения). Выполним несложную команду:

    iptables –A INPUT –i lo –j ACCEPT.

    Как видно, команда iptables понимает различные параметры. Первый из них передает цепь, в которую будут занесены данные. Второй указывает на интерфейс. Последний определяет политику правила. Дословно команда означает следующее: «анести в цепь INPUT правило, разрешающее прием пакетов с интерфейса lo. Просто? Еще бы :).

    Дальше чуть сложнее. Любой пакет может иметь 4 различных состояния. NEW представляет собой обычный пакет, инициирующий новое соединение. ESTABLISHED – пакет от уже установленного соединения. RELATED – новый пакет данных, который был создан старым соединением. И, наконец, INVALID – неизвестный пакет. Тебе необходимо разрешить только два вида – RELATED и ESTABLISHED, потому как они являются доверенными. Без дополнительных средств iptables не умеет различать состояния. В этом ему помогает специальный модуль state.

    iptables –A INPUT –p tcp –m state –state RELATED,ESTABLISHED –j ACCEPT.

    Правило усложнилось тремя новыми опциями. Параметр –p показывает, что рулес применяется к TCP-протоколу (без этого флажка нельзя заюзать модуль state). Опция –m позволяет подключать дополнительные модули. Третий параметр state относится к одноименному модулю. Он показывает, что правило обрабатывает пакеты определенного вида.

    Следующий шаг направлен на настройку соединения с сервисами. Допустим, на сервере установлен proftpd, postfix и popa3d. На самом деле, сервисов может быть и больше, суть в том, чтобы не забыть о каждом из них. Итак, предположим, что postfix должен принимать данные от узла 192.168.1.1. К proftpd имеют право подключаться только клиенты сегмента 192.168.0.0/24, а снимать почту могут все. Давай оформим такую политику в виде трех несложных правил. Для удобства рекомендую создать дополнительную цепь services и подключить ее к основной INPUT.

    Листинг

    iptables –N services

    iptables –A INPUT –j services

    iptables –A services –p tcp –dport 25 –s 192.168.1.1 –j ACCEPT

    iptables –A services –p tcp –dport 21 –s 192.168.0.0/24 –j ACCEPT

    iptables –A services –p tcp –dport 110 –j ACCEPT

    Флаг –s отвечает за IP-адрес отправителя. Он может принимать значение как отдельной станции, так и целого сегмента. Теперь, когда цепь INPUT полностью настроена, можно менять ее политику и тестировать созданные правила. Последний штрих достигается следующей командой:

    iptables –P INPUT DROP

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

    Фаервол покажет, кто хозяин!

    Библиотека owner.so является весьма полезной. Она создана для того, чтобы запретить локальному пользователю обращаться к ресурсам сети. Часто хакеры совершают свои злодеяния с веба, и стандартная настройка брандмауэра не спасает. В случае если ты подвяжешь модуль owner, можно сделать так, чтобы процесс httpd не мог открывать порты, а тем более коннектиться на чужие машины. Это достигается всего двумя командами:

    iptables –A OUTPUT -m owner -uid-owner 99 -p tcp -dport 80 -j ACCEPT

    iptables -A OUTPUT -m owner -uid-owner 99 –j DROP

    Модуль позволяет анализировать UID локального пользователя. Если он равен 99 (что соответствует логину nobody), правило запретит обращение к неизвестным портам. Второе правило запрещает любые действия под nobody. Оно должно располагаться ниже первого, потому что iptables анализирует рулесы по принципу от частного к общему.

    Существует еще одна проблема, с которой ты можешь столкнуться. В случае если на твоем сервере прописаны другие пользователи и ты не хочешь, чтобы они прокачивали через машину фильмы и музыку, придется добавить несколько правил, которые аналогичны предыдущему. Пришло время урезать сетевые права пользователя по самые уши :). Необходимо помнить, что юзеру надо разрешить пропуск RELATED– и ESTABLISHED-пакетов, в противном случае он не сможет заливать файлы на локальный FTP.

    iptables –A OUTPUT –p tcp –m state –state ! RELATED,ESTABLISHED –m owner –uid-owner 31337 –j DROP.

    Этот рулес позволит фильтровать все пакеты, посланные юзером 31337. Помимо uid ты можешь ограничивать и gid, а также мутить доступ к произвольной сетевой команде. Если ты заинтересовался этим модулем, можешь ознакомиться со всеми его параметрами, набрав команду iptables –help –m owner.

    Модификация пакетов

    Настало время поговорить о второй таблице iptables, которая называется nat. Эта чудесная таблица содержит три цепочки: PREROUTING, OUTPUT и POSTROUTING. Правила, расположенные в этих цепях, нужны для корректировки пакета. Например, ты хочешь, чтобы машина с IP-адресом 192.168.0.2 выходила в интернет напрямую. Для этого достаточно воспользоваться маскарадингом, добавив всего одно правило в таблицу POSTROUTING.

    iptables –t nat –A POSTROUTING –s 192.68.0.2 –j MASQUERADE

    Суть маскарадинга заключается в замене локального IP на адрес шлюза. Получается, что конечный узел фактически соединится не с локальной машиной, а с маршрутизатором. Последний будет форвардить все пришедшие пакеты узлу с адресом 192.168.0.2.

    Вообще, использовать NAT в крупной сети не рекомендуется. Если какой-нибудь юзер стянет пару гигов с порносайта, администратор не определит виновника. Поэтому вместо NAT используется прокси-сервер. При переходе на прокси возникает одна проблема: админа ломает бегать по всем машинам и прописывать адрес проксика в настройки браузера. К счастью, не все так плохо: можно просто оформить редирект портов, а затем немного настроить конфиг squid. В этом случае клиент соединится с прокси-сервером, сам того не желая :). Для выполнения редиректа вписывай легкое правило в цепь PREROUTING.

    iptables –t nat –A PREROUTING –s 192.168.0.0/24 –p tcp –dport 80 –j REDIRECT –to-port 3138

    Рассмотрим ситуацию сложнее. В твоей локалке есть сервер, не имеющий внешнего адреса. А управлять им хочется из дома. С помощью iptables ты легко можешь намутить модификацию не только портов, но и IP-адресов. В результате небольшой подмены шлюз соединит твой домашний комп с локальным сервером. Вот правило, которое прописано на моем фаерволе. Оно связывает мой компьютер и терминальный сервер в локальной сети.

    iptables –t nat –A PREROUTING –s 194.225.226.3 –p tcp –dport 3389 –j DNAT –to-destination 10.50.40.255:3389

    Таким образом, если пакет направлен на порт 3389, шлюз заменит в нем адрес назначения на 10.50.40.225 и перенаправит данные на локальный сервер. С помощью этого механизма я без проблем могу рулить терминалкой из дома. Чего и тебе желаю :).

    Хочешь большего? Ставь патчи!

    Несмотря на столь широкие возможности iptables не превосходит OpenBSD’шный pf по функциональности. Его конкурент умеет различать операционные системы по хитрому fingerprinting’у, защищать сервер от скана портов и т.д. Пришло время нанести ответный удар. Итак, встречаем новый патч для iptables под названием Patch-o-Matic. Набор POM создан для админов, которым мало стандартных возможностей фаервола. Он включает в себя набор модулей, позволяющих творить невероятные вещи. Правда, чтобы пропатчить брандмауэр, придется пройти через семь кругов ада. Сперва убедись, что твое ядро собрано из исходников. Сорцы ядра понадобятся инсталлятору POM, ведь все таблицы и цепочки создаются именно в кернеле. Если твоя система построена на RPM-пакетах, тебе придется перекомпилить ядрышко, предварительно стянув его с ftp.kernel.com (либо с диска). Не забудь включить в ядро поддержку ipfiltering и прочих сетевых вещей. После того как отмучаешься с кернелом, скачивай свежий iptables (http://netfilter.org/files/iptables-1.2.11.tar.bz2 ), а также прилагающийся к нему патч (http://netfilter.org/files/patch-o-matic-ng-20040621.tar.bz2 ). Теперь распаковывай фаервол и компилируй его. Когда ты сделаешь все эти шаги, наступит время для установки патча.

    Внутри архива с POM содержится перловый инсталлятор. Для его корректной работы тебе понадобится библиотека termcap, поэтому убедись в наличии файла /etc/termcap. Запусти инсталлятор с параметром base. В интерактивном режиме выбери нужный патч из этой категории (проверенные базовые обновления). К каждому фиксу приводится развернутое описание с конкретным правилом. После базовой установки можно заинсталлить дополнительные патчи, запустив инсталлер с опцией extra. Процесс установки очень прост, ты с ним разберешься без дополнительной помощи. Сложности возникнут после инсталляции.

    Итак, все фиксы установлены, и ты жаждешь применить их на практике. Перед тем как это сделать, тебе придется выполнить два финальных шага. Во-первых, зайди в каталог с исходниками ядра и запусти make menuconfig. Затем переходи в раздел ipfiltering и выбирай все патчи, которые были установлены скриптом runme. Сохрани все изменения и открой .config для редактирования. Если ты установил обновления TARPIT и OSF, убедись в наличии двух установочных директив и в случае их отсутствия внеси их самостоятельно.

    CONFIG_IP_NF_TARGET_TARPIT=m

    CONFIG_IP_NF_MATCH_OSF=m,

    Во-вторых, заново перекомпилируй iptables и набери make install, чтобы все модули были скопированы в каталог /lib/iptables. Если все произошло без осложнений, можно сказать, что POM успешно установлен.

    Практикуемся?

    Настало время для легкой практики после тяжелой установки. Рассмотрим модули из коллекции POM, которые действительно облегчат твою жизнь. Первая библиотека, которая мне очень понравилась, называется time.so. Она поможет активировать правило в определенное время. Это очень удобно, с помощью нее ты можешь либо открывать ночной интернет, либо ограничивать доступ к некоторым популярным ресурсам в час пик. Тебе достаточно добавить одно-единственное правило в цепь INPUT.

    iptables -A INPUT -p tcp -dport 80 -m time -timestart 13:00 -timestop 15:00 -days Mon,Tue,Wed,Thu,Fri -j REJECT

    Данный рулес запрещает обращаться к вебу в дневное время. Как я уже сказал, ты можешь юзать time.so в качестве ограничителя интернета. Для этого добавь правило в цепь POSTROUTING таблицы nat. Следующий модуль называется random.so. Он позволяет регулировать вероятность правила. В некоторых ситуациях библиотека просто незаменима. К тому же, ты можешь раскрутить своего шефа на апгрейд, показав ему великую нагрузку на сервер. Предварительно ты, конечно же, пропишешь хитрое правило, которое выставляет вероятность 33% на соединение с Web-сервером.

    iptables -A INPUT -p tcp -dport 80 -m random -average 33 -j REJECT.

    Но эти модули сделают работу удобной лишь в конкретных ситуациях. В повседневной практике ты можешь применять другие библиотеки. Например, mport.so и iprange.so. Эти дополнения – великая сила, ибо они позволяют гибко формировать целый диапазон портов и IP-адресов в одном правиле! Не веришь? Просто набери в консоли команду:

    iptables -A INPUT -p tcp -m mport -dports 21,22,25,110,4000:5000 -j ACCEPT

    и действие хитрого правила сразу вступит в силу. Теперь тебе не надо расписывать два десятка рулесов для каждого сервера. То же самое можно сказать и про IP-адреса. Разрешить соединения целому диапазону айпишников можно также одним правилом:

    iptables –A INPUT –p tcp –m iprange –src-range 192.168.0.1-192.168.0.100 –j ACCEPT.

    Соединение с пустотой

    Иногда нужно имитировать соединение. Для этого админом пишется специальная программа, прослушивающая определенный порт. Теперь можно добиться результата с помощью модуля tarpit.so. Он нужен для открытия пустого порта. Причем порт будет светиться в выводе netstat’а после фактического соединения. Эта библиотека может быть полезна, если админ решается написать фаервольную утилиту против скана определенных портов, с последующим занесением в лог всех попыток соединения. Не буду тебя мучить, просто напишу правило.

    iptables –A INPUT –p tcp –dport 31337 –j TARPIT

    Фильтруй базар

    Теперь iptables умеет искать подстроку в пакете. В этом ему помогает модуль string.so. Например, ты захочешь намутить защиту от пересылки shell-кодов на твою машину либо просто не желаешь, чтобы юзер заливал бинарник на сервер. Если раньше приходилось патчить кернел и ставить дополнительный модуль, то сейчас достаточно вбить всего одно правило:

    iptables -A INPUT -p tcp -dport 21 -m string -string '|7F|ELF' -j DROP

    Раз уж мы заговорили об ограничениях, расскажу, как предостеречь свою машину от DoS-атаки. Нужно воспользоваться модулем limit.so, позволяющим ограничивать пропускную способность. Если ты видишь, что твой FTPD зажирает процессор и захлебывается в данных, сделай ограничение в 5 пакетов за одну секунду.

    iptables –A INPUT –p tcp –dport 21 –m limit –limit 5/sec –j REJECT

    Вероятно, у тебя уже кружится голова от наворотов POM. Но самое вкусное я оставил напоследок :). Теперь ты способен контролировать одновременное число подключений не только с одного IP-адреса, а даже с целой подсети! Это возможно, даже если сам сервис не поддерживает такую функцию. Модуль connlimit.so создан специально для подобной работы. Библиотека способна ограничить подключения к определенному сервису, например, к демону sshd. Просто добавь рулес в цепь INPUT:

    iptables –A INPUT –p tcp -syn -dport 22 -m connlimit -connlimit-above 3 -j REJECT.

    И в заключение…

    Думаю, этого материала тебе хватит не только для освоения азов iptables, но и для грамотной защиты своего сервера. Благо брандмауэр это позволяет :). Синтаксис iptables прост как три копейки, думаю, ты все понял уже после первого правила. Теперь все зависит только от тебя, я же могу пожелать немного терпения и изобретательности. Остальное прибавится после установки Patch-o-Matic :).

    Ликбез по iptables

    Вот несколько команд, которые ты можешь использовать при работе с iptables.

    Листинг

    iptables –N цепь – создание новой цепочки

    iptables –F цепь – очистка произвольной цепи

    iptables –X цепь – удаление цепи

    iptables –D цепь номер_правила – удалить правило из определенной цепи

    iptables –P цепь политика – изменение политики цепи

    iptables –line-numbers –nvL цепь – просмотр всех правил в определенной цепи в verbose-режиме, без преобразования адресов с нумерацией каждого правила (быстрый и подробный просмотр)

    service iptables save/restore – сохранение (восстановление) всех правил в отдельный конфиг

    service iptables start/stop – запуск (останов) фаервола

    Мнение эксперта

    Андрей «Andrushock» Матвеев, редактор рубрики «UNIXoid» журнала «Хакер»:

    «Число пользователей интернета с каждым днем неуклонно растет, а прогресс и информационные технологии не желают стоять на месте. В связи с этим провайдерам приходится выделять физическим лицам и организациям IP-адреса для маршрутизаторов и серверов, рабочих станций и WAP-терминалов, беспроводных устройств и даже бытовой техники. Так как число доступных адресов в реализации IPv4 составляет примерно 2 в 32-й степени, то мы невольно становимся свидетелями кризиса IP-адресов. По независимым статистическим исследованиям последний свободный адрес будет занят уже в 2008 году. Для решения проблемы были предложены, а затем внедрены три „лекарства“: протокол CIDR (бесклассовая доменная маршрутизация), качественно новый протокол IPv6 (адресное пространство составляет 2 в 128-й степени) и система NAT (трансляция сетевых адресов). Как раз за счет системы NAT пограничный шлюз может выполнять следующие процедуры: перехват всех клиентских запросов из доверенной подсети, подмена исходного порта и адреса источника своим непривилегированным портом и адресом своего внешнего сетевого интерфейса, ведение специальной таблицы соответствия установленных соединений, чтобы, получив от удаленного хоста ответный пакет, корректно перенаправить его клиенту, инициировавшему запрос. Благодаря такому подходу достаточно иметь всего один реальный IP-адрес, всем клиентским машинам назначаются специально зарезервированные IP-адреса, немаршрутизируемые во внешних сетях (RFC 1918). Поскольку все исходящие соединения устанавливаются от имени шлюза, полностью скрывается топология внутренней сети – это огромный плюс с точки зрения безопасности. Однако из-за трансляции адресов могут возникнуть проблемы при работе с FTP, IRC и некоторыми другими сложными протоколами (решается установкой специальных прокси). Нужно четко понимать, что брандмауэр с фильтрацией пакетов, такой, как iptables, ipfw, ipfilter, pf, – это не панацея от всех напастей глобальной сети. Это всего лишь, как ясно из названия, фильтр пакетов. Да, он может помешать выяснению доступности хоста (ping sweep), пресечь попытки сканирования портов, отсеять пакеты с недопустимыми комбинациями флагов (SYN+FIN, FIN+URG+PUSH), предотвратить DoS-атаку, разграничить доступ к службам на основе IP-адреса источника, перенаправить валидный трафик, защитить демилитаризованную зону и скрыть доверенную подсеть. Однако такой брандмауэр бессилен против червей, троянов, бэкдоров, эксплоитов, снифинга и, конечно же, против braindamaged пользователей, так как он работает, к сожалению, только на сетевом и транспортном уровнях. Поэтому многочасовая оптимизация правил непроницаемого брандмауэра – это зря потерянное время, если в системе крутится непропатченный Sendmail или инсекьюрный Wu-ftpd. К защите как сервера, так и клиентского хоста необходим комплексный подход.

    Сохранить или восстановить правила помогут бинарники /sbin/iptables-save и /sbin/iptables-restore.

    Поброди по каталогам POM и ознакомься с документацией по каждому модулю. Правда, сведений там не очень много.

    Помимо главных патчей, POM содержит фиксы для содружества iptables с eggdrop, warcraft и quake3 :).

    Чтобы узнать какие параметры понимает тот или иной модуль, выполни команду iptables -help –m имя_модуля.

    Я не проверял работу POM с ядром 2.6.х. Разработчики о совместимости также умалчивают. Поэтому я не гарантирую стабильность работы с подобными кернелами.

    Помимо DNAT существует и SNAT, когда заменяется адрес отправителя. Это бывает необходимым в некоторых случаях.

    Существует специальный модуль netmap, который позволяет более удобно производить NAT. В ядре создается цель NETMAP, после чего можно сделать статическую привязку вида 1:1 к любой сети.

    С документацией по iptables ты можешь ознакомиться на известном портале www.opennet.ru.

    Хитрый тюнинг и грамотная защита / Приемы настройки сервера

    Toxa (toxa@cterra.ru)

    Ты поставил и настроил сервер. У тебя все работает, пользователи довольны, и теперь настало время добавить в систему ту самую изюминку, о которую, возможно, сломает зуб не один взломщик.

    Тюнингуем систему

    Первый шаг – обезопасить себя встроенными средствами. Общение с ядром будем проводить через sysctl – удобный интерфейс для тюнинга сетевой подсистемы. Расскажу на примере FreeBSD. В этой системе нужно обратить внимание, как минимум, на следующие переменные:

    Листинг

    net.inet.tcp.blackhole=2

    net.inet.udp.blackhole=1

    По стандарту, если на закрытый порт сервера приходит SYN-пакет, машина должна ответить RST-пакетом. Это упрощает сканирование портов, а также дает достаточное количество информации (в виде ответов от сканируемого сервера) для определения версии ОС. «Черные дыры» заставляют FreeBSD быть предельно лаконичной, не отсылая ничего в ответ на запросы к закрытым портам. Идем дальше.

    Маршрутизацию от источника можно смело отключить:

    Листинг

    net.inet.ip.sourceroute=0

    net.inet.ip.accept_sourceroute=0

    Чтобы сервер не стал жертвой DoS-атаки, можно включить механизм syncookies, который служит для защиты сервера от SYN-флуда.

    При серьезной атаке может не менее серьезно выручить. Выстави следующую переменную:

    Листинг

    net.inet.tcp.syncookies=1

    Чтобы затруднить определение версии твоей ОС анализом приходящих от нее пакетов, изменим значение Time To Live:

    Листинг

    net.inet.ip.ttl=64

    Современная система не должна отвечать на широковещательные пинги, но и по сей день существуют сети, которые могут стать источником DoS-атаки. Чтобы не попасть в их список, выставляем:

    Листинг

    net.inet.icmp.bmcastecho=0

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

    Листинг

    net.inet.tcp.log_in_vain=1

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

    Если не нужна поддержка смешного протокола T/TCP (TCP for Transactions), то пакеты с флагами SYN+FIN можно смело отбрасывать как неликвидные :). Протокол редко где используется, а потому это имеет смысл.

    Листинг

    net.inet.tcp.drop_synfin=1

    Обманываем сканеры

    Вторжение в систему начинается со сканирования – это прописная истина. Можно (и нужно) уже на этом этапе усложнить жизнь злоумышленнику. Так, пакетный фильтр OpenBSD PF имеет встроенную возможность определения и блокирования сканеров, используя технологию Passive OS Fingerprinting. Достаточно добавить правило «block quick from any os NMAP» в pf.conf, чтобы результаты работы популярного сканера nmap заставили хакера почесать затылок. Также nmap'у можно противодействовать с помощью «scrub in all» и фильтрации TCP-пакетов с особыми флагами, к примеру:

    Листинг

    block return-rst in log quick proto tcp all flags FP/FP

    block return-rst in log quick proto tcp all flags SE/SE

    block return-rst in log quick proto tcp all flags FUP/FUP

    Но можно обойтись и userland-средствами. Например, утилитой portsentry.

    Она открывает для прослушивания указанные TCP/UDP-порты, логирует обращения к ним и позволяет реагировать на сканирование. После скачивания с http://packetstormsecurity.nl/UNIX/IDS/ и установки portsentry правим portsentry.conf:

    Листинг

    TCP_PORTS="42,88,135,139,145,389,443,445,464,593,636,637,1025,1026,1027,1029,1433,3372,3389»

    UDP_PORTS="»

    Я указал набор TCP-портов, очень похожий на тот, что открывает Windows 2000 Server в дефолтовой установке. UDP-порты прослушивать мы не будем – их редко сканируют.

    После этого имеет смыл указать хосты, чье сканирование мы будем игнорировать, например, машины из локалки. Пропиши путь к файлу со списком игнорируемых хостов:

    Листинг

    IGNORE_FILE="/usr/local/psionic/portsentry/portsentry.ignore»

    Чтобы portsentry не занималась ненужным отображением IP-адреса в имя хоста, отключи обратный резольвинг:

    Листинг

    RESOLVE_HOST = «0»

    Далее блокируем IP-адреса хостов, с которых производится сканирование:

    Листинг

    BLOCK_TCP="1»

    А теперь укажи, как ты хочешь это делать. Например, добавлением правила фаервола:

    Листинг

    KILL_ROUTE="/sbin/ipfw add 1 deny all from $TARGET$:255.255.255.255 to any»

    Также можно заносить атакующих в hosts.deny для усиления защиты демонов, использующих tcpwrappers:

    Листинг

    KILL_HOSTS_DENY="ALL: $TARGET$ : DENY»

    Наконец, можно указать баннер, выдаваемый при подключении к порту, прослушиваемому portsentry:

    Листинг

    PORT_BANNER="WHOM DO YOU WANT TO HACK TODAY?»

    Учти, что блокировать хосты таким образом – крайняя мера, так как есть возможность превратить network в notwork, заблокировав легитимных клиентов. В общем случае я бы не рекомендовал использовать KILL_ROUTE. У меня уже два с лишним года работает машинка, приспособленная в свое время именно для снятия подобной статистики (ради интереса). В настоящее время в hosts.deny содержится 12373 записи, и помимо злачных притонов интернета в черный список попали вполне легитимные адреса. Сервисы, работающие на том сервере, не используют tcpwrappers, так что никто не страдает. Но сам факт достоин внимания.

    Меняем баннеры

    Любой демон, принимающий внешние соединения, так или иначе «демонстрирует себя» баннером – однострочным приветствием, выдающимся клиенту в ответ на соединение с ним. Самый простой способ увидеть это – совершить соединение telnet'ом с сервером на порт, прослушиваемый демоном:

    Листинг

    [(22:42)(29.10%)(p1):~/articles/tricksec ] telnet smtp.gameland.ru 110

    Trying 62.213.71.4…

    Connected to smtp.gameland.ru.

    Escape character is '^]'.

    +OK Microsoft Exchange Server 2003 POP3 server version 6.5.7226.0 (server500.gameland.ru) ready.

    Почти всегда это служебная информация, нужная для работы сервиса, но иногда – совершенно бесполезная и даже вредная. Разные сервисы ведут себя по-разному: кто-то ограничивается лаконичным именем хоста и типом сервиса (domain.com ESMTP), а кто-то выдает себя с потрохами, раскрывая свое имя и версию. Если в нашем примере будет найдена уязвимость в определенных версиях Exchange, то взломщик за пару минут напишет баннер-граббер, который соединяется с хостами и снимает с них версию Exchange. Таким нехитрым способом можно легко найти уязвимый хост. Теперь понятно, почему смена баннера имеет смысл: она позволяет скрыть версию сервиса или даже ввести в заблуждение взломщика. По этой причине многие демоны имеют возможность считывать баннер прямо из конфига. Если же нет – мы в мире OpenSource и не поленимся залезть в исходники. Учти, смена баннера не даст нам полной иллюзии «другого» сервиса. Шанс определить демона и, например, отличить Apache от IIS все равно остается – по поведению программы в ответ на различные запросы, коду ошибок, специфичных сообщений, формированию заголовков писем (в случае SMTP-сервера) и т.п., так как жестких стандартов поведения того же почтового сервера нет и каждый реализует протокол по-своему. Однако от примитивных механизмов определения демона мы защитимся (подробнее про fingerprinting читай в другой статье этого номера).

    OpenSSH

    Самый популярный пакет для удаленного администрирования по протоколу ssh, хоть и написанный весьма компетентными хакерами из OpenBSD team, но имеющий длинную историю взломов. Баннер в конфиге не выставляется, так что будем править сорцы. Найди в файле version.h следующие строки:

    #define SSH_VERSION «OpenSSH_3.8p1»

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

    Apache

    Это классика. Смена баннера самого популярного web-сервера – весьма частое развлечение админов. Здесь тоже не обойтись без правки исходных текстов. В каталоге с исходниками найди файл src/include/httpd.h, а в нем – следующие строки:

    Листинг

    #define SERVER_BASEPRODUCT «Apache»

    #define SERVER_BASEREVISION «1.3.29»

    Теперь меняй их на Microsoft-IIS 4.0 и коллекционируй сигнатуры старых добрых unicode-атак :). В Apache 2.0.x надо править файл include/ap_release.h, строки:

    Листинг

    #define AP_SERVER_BASEPRODUCT «Apache»

    #define AP_SERVER_MAJORVERSION «2»

    #define AP_SERVER_MINORVERSION «0»

    #define AP_SERVER_PATCHLEVEL «50»

    Postfix

    Этот удобный и (относительно, как и все в этом мире) безопасный SMTP-сервер позволяет указать баннер прямо в конфиге, main.cf:

    $smptd_banner = $mydomain ESMTP MyCoolServer

    Sendmail

    По умолчанию sendmail выдает слишком много информации. В нем часто находят уязвимости, так что светить версией – себе дороже. Можно поправить sendmail.cf:

    O SmtpGreetingMessage=$j ESMTP InsecureMailserver

    Или sendmail.mc:

    define(`confSMTP_LOGIN_MSG', `$j ESMTP UnsecureMailserver')

    BIND

    Named – популярный DNS-сервер от Internet Software Consorcium. Известен прежде всего своей историей уязвимостей, так что рассказать миру о том, какая у тебя версия named – значит жить как на иголках до следующей Security Advisory. Правь named.conf, в глобальной секции options {} пиши:

    version «Microsoft DNS»;

    VsFTPd

    Это чрезвычайно безопасный ftp-сервер с поддержкой ssl-соединений. Указать баннер можно прямо в vsftpd.conf:

    ftpd_banner=mydomain.com Microsoft FTP Service (Version 5.0)

    BSD FTPd

    Во Free/Net/OpenBSD можно поправить приветствие стандартного ftpd. Для этого нужно найти в файле /usr/src/libexec/ftpd/ftpd.c строчку:

    reply(220, «%s FTP server (%s) ready.», hostname, version);

    Она может встретиться несколько раз, так, во FreeBSD за баннер отвечает конструкция:

    Листинг

    if (hostinfo)

    reply(220, «%s FTP server (%s) ready.», hostname, version);

    else

    reply(220, «FTP server ready.»);

    В обоих случаях в выводе строки можно написать, что душа пожелает (а можно поступить более 31337-но – изменить значение hostinfo на 0 перед вышеуказанным блоком if).

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

    Мнение эксперта

    Андрей «Andrushock» Матвеев, редактор рубрики «Unixoid» журнала «Хакер»:

    «Идеальной или совершенной защиты не бывает. Мы можем только стремиться к обеспечению должного уровня безопасности за счет своевременного обновления программного обеспечения, грамотного разграничения доступа, корректной настройки интернет-служб и, конечно же, предотвращения утечек информации – здесь я подразумеваю весь спектр предпринимаемых действий начиная от сокрытия сервисных баннеров и заканчивая воспрепятствованию перехвату конфиденциальных данных организации. Очень многое зависит от системного администратора, от его политики, опыта, навыков работы и знаний. Известны случаи, когда правильно сконфигурированные серверы на базе Red Hat Linux могли похвастаться тысячедневными аптаймами, в то время как хосты под управлением OpenBSD не выдерживали и недельного натиска глобальной сети. За счет открытого исходного кода можно каждый день изменять поведение системы и/или стека TCP/IP, главное – придерживаться одного простого правила: не ломать стандарты, задокументированные в RFC.

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

    SYN-флуд – переполнение очереди открытых соединений в состоянии SYN-sent.

    Утилита portsentry проверена временем – она написана еще в 1998 году.

    Узнать конкретную версию какого-либо сервиса не из баннера значительно труднее.

    Логи для умных / Система log-файлов для *nix-систем

    the_Shadow (theshadow@sources.ru)

    Логи – органы чувств администратора в чреве системы. В этой статье я постараюсь рассказать тебе о работе системы ведения log-файлов, ее грамотной настройке и о том, что из нее вообще можно выжать.

    Теория

    При старте системы запускается механизм протоколирования, состоящий из двух подсистем ведения протокола – ядра и процессов. Собственно, работа их начнется сразу после того, как syslogd и klogd стартанутся в процессе init. Тогда создастся сокет /dev/log, на который в дальнейшем смогут поступать логи с удаленных машин, также откроются файлы, описанные для логирования в твоей системе.

    С этого момента система будет ждать твоих логов.

    klogd

    Сообщения ядра – это не самое важное, но упомянуть о них я обязан. Ты наверняка встречался с этими сообщениями, так как при загрузке система вовсю выводит их на консоль. Их можно получить также в любой момент с помощью команды dmesg либо заглянув в файлы /var/adm/messages и /var/adm/syslog, в которых по умолчанию хранится весь протокол ядра.

    Все сообщения от ядра и его модулей хранятся в кольцевом буфере, размер которого – 16 Кб по умолчанию. Если размера буфера не хватает (к примеру, если ты используешь его для вывода отладочных сообщений от твоего модуля), то его можно увеличить, подкорректировав сорцы ядра. Именно за работу с данным буфером и отвечает демон klogd, который во многом похож на рассматриваемый ниже syslogd (без него он, кстати, даже работать не может).

    syslogd

    syslogd – демон, отвечающий как за протоколирование сообщений процесса, так и всей системы в целом. Процесс, которому надлежит, по замыслу авторов, протоколировать свои данные, должен включать в свое тело библиотечные функции, при вызове которых происходит обращение к syslogd и передача тому данных для записи (см. врезку).

    Как правило, большая часть демонов, функционирующих в системе, имеет в опциях конфигурации настройку параметров подсистемы протоколирования (см. тот же BIND). Со стороны системы все еще проще. Существует файл (у меня это /etc/syslog.conf) – основа для конфигурации всей работы демона syslogd, и если что-то надо поменять в протоколировании сообщений системы, то именно здесь.

    В принципе, нам никто не мешает работать с логами даже из простого приложения. Таким образом, в протокол можно сбрасывать все действия приложения/пользователя, что применимо для отладки, хотя для отладки приложения есть другие и более адекватные механизмы. А вот для чего это точно может понадобиться, так это для контроля за действиями пользователя. Своего рода «черный ящик» для систем, где действия пользователей стоит записывать.

    Настройка syslog

    Для настройки надо понять, что есть ряд уровней («уровней приоритета» или «серьезности») того или иного условия, которое протоколируется, и ряд типов приложений («средств»). Для каждой конкретной системы они описаны в коде ядра. И их значения разъяснены в манах.

    «Серьезность» имеет 8 значений (0-7), где 0 – аварийная ситуация, когда всем пользователям шлется широковещательное сообщение и система останавливает свою работу. После такого отказа система, в принципе, может и не завестись. 7 – отладочное сообщение (для отладки приложения, и не более). Стоит заметить, что аналогичные уровни серьезности используются и в Cisco IOS. Эта система протоколирования очень похожа на никсовую.

    «Средства» – это ряд типов процессов от ядра до подсистемы почтовых сообщений, включая аутентификацию, авторизацию, демонов etc.

    То есть любая запись в файлы логов производится на основании того, что процесс хочет записать и с каким уровнем серьезности. Система (syslogd) перехватывает вывод процесса и отправляет строку в файл, указанный в конфиге. Как видишь, все просто.

    Настраивая демона syslogd через /etc/syslog.conf, вполне можно добиться достойной нас информативности.

    Вот пример (кусок реального файла) с комментариями:

    ЛИСТИНГ

    #Все, что касаемо аутентификации.

    authpriv.* -/var/log/secure

    #Все сообщения уровня Emergency (0) всем пользователям.

    *.emerg *

    #Писать сообщения от info до warn для сервисов, за исключением

    #authpriv, cron – для этих сервисов есть другое место

    #см. первую строку.

    .info;*.!warn;\

    authpriv.none, cron.none -/var/log/messages

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

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

    1) utmp хранит данные о подключении пользователей в текущий момент (см. команду who, к примеру);

    2) wtmp хранит данные обо всех подключениях к системе. Если, к примеру, некто вошел в систему и сразу вышел, то именно здесь он и «наследил». Самые свежие записи хранятся в начале файла;

    3) если файлов в системе нет, syslogd их создавать не станет. Самому придется создать через touch. Но! Если они были, то где они теперь?

    Безопасность

    Во-первых, до настройки логов определяемся, что и с каких хостов писать, так как логи не резиновые и их надобно смотреть. Потеряется смысл записи, если в них будет куча всякого мусора. Необходимо четко понять, что писать важно, а что нет.

    К примеру, есть роутер Cisco, есть web-сервер, FTP-сервер (на одной системе), есть мэйл-сервер и DNS (на второй). Знаю, что не по правилам, но так уж вышло.

    Также есть тачка админа, который для повседневной работы использует ту же систему, что и на его серверах. Где писать логи? Ответ сам напрашивается: на компьютере админа! Если система взломана, то логов хакер на ней не найдет! Придется еще и систему админа ломать :).

    Что писать? Аутентификация – раз, подсистемы (FTP, mail …) – два. Это минимум. В данном случае любые попытки доступа и/или использования наших серверов будут записываться. Получаем картинку того, что в сети творится.

    Во-вторых (я противник такого метода, но… он самый надежный), все логи, поступающие на машину админа, следует немедленно отправлять на печать. Даже в случае взлома системы админа, при котором все логи, конечно, будут неизменны, у нас останется жесткая копия. Здесь, правда, перед нами встает этический вопрос – а стоит ли весь этот бред жизни деревьев, переводимых на бумагу :)?

    Получив логи, отвечающие должным требованиям, не стоит забывать об их обслуживании.

    Обслуживание логов

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

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

    «Что искать», – спросишь ты? Все подозрительное: некорректные входы в систему, отказы в аутентификации пользователя, строки login/password etc. Как пример, многие win-пользователи привыкли к тому, что при входе в систему имя пользователя уже введено и остается только вбить пароль. В *nix это не так. В результате, в логе вполне могут оказаться актуальные пароли, вбитые как имя пользователя. Система, конечно же, не пропустила, но в лог записала. Если это повторится, то пора с данным юзером профилактическую беседу проводить.

    Особое внимание стоит уделить поиску строк типа /bin/sh. В этом случае, если строчка чередуется с «мусором», вполне логично предположить, что тебя пытались поломать (и ты видишь shell-код).

    Кроме того, при логировании сетевых служб следует искать некорректные входы в систему, попытки подбора пароля.

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

    Логи должны храниться в течение некоторого разумного времени (к примеру, в течение недели). В особенных случаях можно писать логи на CD и хранить их столько, сколько нужно. Для этих целей есть фича logrotate. Идея такова: прописать в /etc/logrotate.conf, как и что хранить (пересылать ли на e-mail, копировать, сжимать, обрезать размер до нуля – см. man logrotate), а затем через cron раз в какой-то период запускать этого хозяйство. Важно то, что ты сам можешь настроить механизм замены логов так, как это нужно. К примеру, все отладочные сообщения просто и без затей уничтожать, доступ к HTTP – хранить и т.д.

    На этом все! Если возникли вопросы, то читай маны, рой сеть и только потом пиши мне :).

    Учимся писать логи

    Сначала добавляем к сорцу хидер <syslog.h> .

    Открываем подсистему логов из приложения с помощью функции openlog, прототип которой можно найти в хидере.

    На этом этапе можно писать лог с помощью функции syslog(уровень_серьезности, сообщение) или vsyslog(), которая работает с форматированным выводом, как и printf.

    В конце закрываем подсистему: closelog().

    Для программного доступа к буферу ядра есть функция (man klogctl), которая очень похожа на syslog(). По идеям. По релизу – разберешься.

    Увеличить размер буфера ядра можно (к примеру, для Linux-2.4.20 в файле /usr/src/linux/kernel/printk.c). Тебе должно быть интересно значение LOG_BUF_LEN. Естественно, придется пересобрать ядро.

    Демон syslog работает на порту 514/UDP (сокет /dev/log), но можно перенаправить его и на иной порт через фаервол.

    Хранилище логов в любом случае должно принадлежать root'у.

    IDS/SNORT / Системы обнаружения атак

    the_Shadow (theshadow@sources.ru)

    Крайне важным помощником в админовском деле является IDS, или по-русски система обнаружения атак. С ее помощью админы всего мира уже предотвратили огромное число взломов. Пора и тебе включить ее в постоянный рацион :).

    Теория

    При анализе атак, причем как на реальные, работающие системы, так и на различные OpenHack\honeypot\honeynet (о которых ты сможешь прочесть в этом номере), были выявлены общие признаки, демаскирующие взломщика. И основываясь именно на этих признаках, умные девелоперы создали первую IDS.

    Системы обнаружения вторжений в «чистом виде» бывают двух типов:

    – (HIDS) host based intrusion detection system – анализ того, что творится на хосте. Системы tripware, анализаторы log'ов.

    – (NIDS) network based intrusion detection system – анализ сетевого трафика. Это куда интереснее, но и сложнее. Дело в том, что такая система работает как снифер, перехватывая и анализируя весь собранный трафик. По идее, NIDS должен уметь обнаруживать атаки как по сигнатурам, встречающимся в перехваченных пакетах, так и по хитрому анализу протоколов. Отличным примером такой системы является SNORT, о котором и пойдет дальше речь. Снорт седлает сетевые интерфейсы и осуществляет наблюдение за трафиком. Если вдруг что-то ему кажется подозрительным, то он громко «визжит» в логи. Идея несложная, правда?

    Установка свиньи

    Для начала надо понять, где же предпочтительнее всего ставить поросячью IDS. Так как наша задача – герметизировать сеть или подсети, то в достаточной мере очевидным будет то, что основное место для установки SNORT'а – роутеры.

    Но помни: вторжение может осуществляться как извне, так и изнутри сети. Да, и свои «внутресетевые», пардон, дятлы могут «помочь».

    Скачивай Снорта с его официальной паги: www.snort.org/downloads/snort-stable.tgz, растаривай в каталог, а в нем набирай:

    ЛИСТИНГ

    ./configure; make; su; make install

    Затем создавай директорию для поросячьих логов:

    ЛИСТИНГ

    mkdir /var/log/snort.

    Теперь Снорт должен быть готов к настройке.

    Конфигурировать нужно файлик /etc/snort.conf. Конкретно ты должен сделать следующее:

    1. Опиши свою сеть – адреса, используемые протоколы (порты) и т.п. Тем самым ты укажешь, за чем надо присматривать. Чем полнее пропишешь, тем лучше.

    2. Укажи, где и какие брать сигнатуры. В стандартной поставке хряка должны быть файлы типа *.rules. Тебе надо указать только те правила, которые реально необходимы твоей системе (какие сервисы в сети крутятся, такие *.rules и отбирай). По этим сигнатурам будет анализироваться трафик. Все это чем-то напоминает работу антивируса, только для TCP/IP. Кстати, когда разберешься, как работает эта IDS, то и сам сможешь создавать рулесы.

    3. Опиши правила, на основании которых анализировать трафик, то есть какие атаки, с какого интерфейса возможны и что делать. Тут также все зависит от сервисов и их настроек.

    Настроив, имеем полное право запустить SNORT:

    ЛИСТИНГ

    snort -D -c snort.conf

    Уязвимость

    Но рано радоваться. Увы, старина Снорт уязвим. У взломщика есть возможность (и ещё какая!) заставить Снорт никак не реагировать на твои действия. Если есть правила, то их не стоит нарушать, их следует обойти. Свинка-то у нас глупенькая, и даже если она поймает в свои лапки shell-код, но сигнатура его окажется ей неизвестна, то будет молчать себе свинка в тряпочку.

    Придется разбираться с *.rules. Есть некое свинское правило, shellcode.rules зовется. Ты только посмотри на него: в нем практически все мыслимые и несколько немыслимых shell-кодов. Ох-ох-ох, что ж я маленьким не сдох… ;)

    Но как ни странно, не зря не сдох. Обойти это правило очень просто. Дело в том, что SNORT – это не антивирус, и он не обладает эмулятором кода, который сможет распознать shell-код не по сигнатуре, а по алгоритму (даешь эвристический IDS :)! – прим. AvaLANche'а). Следовательно, тебе надо несколько видоизменить сигнатуру shell-кода. Это можно сделать, просто переписав shell-код до неузнаваемости под себя. Самый простой способ – изменить (но без потери функциональности!) порядок следования команд или понатыкать NOP'ов (op-код – 90), создав «промежутки» в shell-коде. Конечно, при этом вырастет размер кода, но зато его сигнатура обманет Снорта. Как еще можно поменять сигнатуру?

    1) Менять одни команды на другие. Тут тебе надо очень хорошо ориентироваться в асме и инструкциях целевого процессора. По сути дела, нужно написать свой shell-код, «неизученный» Снортом.

    2) Вариант попроще – поменять вызов шелла. Строка /bin/sh приводит к поросячьей активности Снорта и, позже, админа, а строка %2Fbin%2Fsh – нет. Вот только не всегда это возможно. Хорошо этот способ работает, как правило, на web-сервисах.

    3) Более сложный вариант – применение вирусных технологий (правда, вирусами тут и не пахнет). Никто не забыл о шифрации/дешифрации исполняемого кода? Можно написать (и многие пишут) shell-код, который будет в зашифрованном виде передаваться жертве, а при запуске расшифровываться «на лету». Меняя алгоритм шифрования или ключ, можно будет получать все новые и новые сигнатуры, неизвестные ранее этой IDS. Естественно, в сигнатуре будет светиться коротенький расшифровщик, но его видоизменить до неузнаваемости не составляет труда (подробнее о написании shell-кодов читай в августовском Спеце #08.04(45)).

    Таким образом, грамотный взломщик помнит о SNORT'е и готовит эксплоиты собственоручно. Как в армии, где есть правило: оружие, обмундирование и снаряжение каждый готовит себе САМ!

    SNORT.

    SNORT – одна из самых первых и наиболее удачных реализаций системы IDS, работающая на основе анализа трафика. Я называю эту систему обнаружения атак «грязным свинтусом», так как на первом сайте, посвященном Снорту (еще до версии 1.0), на титульной странице, была вывешена фотография матерого хряка, упершегося рылом прямо в объектив фотографа. С тех пор система значительно повзрослела, сайт перенесли из домена .au в домен .org, а тельце старины Снорта отправили живым весом на колбасу, но имя его и образ живут. На логотипе по-прежнему присутствует довольная рожа (или рыло?) мультяшного хряка.

    Альтернатива есть всегда!

    ТИП: Soft

    Не одинок наш Снорти в этом мире. Полезно посмотреть:

    – libnids – библиотека для создания такого рода систем (libnids.sourceforge.net). Собственно, я сам при необходимости именно ей и пользуюсь. Всегда приятно несколько обескуражить скриптодятла.

    – iplog – анализ протокола на предмет атак.

    – courtney – старушка Кортни, которая является простеньким перловым скриптом для обнаружения факта сканирования. Безнадежная пенсионерка.

    Мнение эксперта

    Антон Карпов, специалист по сетевой безопасности, системный администратор

    Часто говорят: если ты отражаешь атаку – ты уже проиграл. Доля правды в этих словах есть. Любые атаки желательно выявлять еще на стадии их зарождения, нежели разбираться с их результатом. К счастью, *nix-системы имеют для этого все средства. Развитая система протоколирования событий и своевременное наблюдения за аномалиями в системном журнале, а также использование сетевых средств обнаружения вторжений, конечно, помогут, но все что они позволяют – это отработать по факту того, что атака уже идет. Вот почему популярны не только системы обнаружения, но также и системы предотвращения вторжений. Простейший пример превентивной меры – соединение IDS с пакетным фильтром и подача команды на блокирование атакующего адреса.

    SNORT – одна из самых первых и наиболее удачных реализаций системы IDS.

    Снорт седлает сетевые интерфейсы и осуществляет наблюдение за трафиком.

    Основное место для установки Снорта – роутеры.

    Снорта можно легко обойти, видоизменив по максимуму сигнатуру shell-кода.

    Хакеры любят мед / Разбираемся в работе Ноneypot

    Крис Касперски aka мыщъх

    В последнее время создаются все более и более изощренные системы борьбы с хакерами, одной из которых является honeypot – своеобразный капкан для атакующих. Сколько людей отправилось за решетку с его «помощью»! Даже в нашей традиционно лояльной к хакерам стране имеется несколько случаев условных осуждений. Единственный выход – задавить идею honeypot'ов в зародыше.

    Горшочек меда

    Однажды некий мужчина приобрел супернавороченный сейф и повсюду хвастался им: какой он надежный и прочный. Забравшиеся к нему грабители прожгли какой-то хитрой кислотой в сейфе дыру и… не обнаружили внутри ничего! Деньги и драгоценности хранились совсем в другом месте.

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

    Сервер, играющий роль приманки, называется «горшок с медом» («honeypot»), а сеть из таких серверов – honeynet.

    Противостоять honeypot'ам довольно сложно. Внешне они ничем не отличаются от обычных серверов, но в действительности это хорошо замаскированный капкан. Один неверный шаг – и хакеру уже ничто не поможет. Утверждают, что опытная лиса ухитряется съесть приманку, не попав в капкан. Так чем же мы хуже?

    Внутри горшка

    Типичный honeypot представляет собой грандиозный программно-аппаратный комплекс, состоящих из следующих компонентов: узла-приманки, сетевого сенсора и коллектора (накопителя информации).

    Приманкой может служить любой север, запущенный под управлением произвольной операционной системы и сконфигурированный на тот или иной уровень безопасности. Изолированность от остальных участков сети препятствует использованию сервера-приманки как плацдарма для атак на основные узлы, однако дает взломщику быстро понять, что он на полпути к ловушке и отсюда следует немедленно ретироваться, заметая следы. Теоретически администратор может организовать подложную локальную сеть, практически же это оказывается неподъемно дорогостоящим решением, и приходится искать компромисс: либо ослабленная изоляция, ограждающая только критически важные узлы, либо эмулятор локальной сети, запущенный на одном компьютере. Чаще всего узлов с приманкой бывает несколько. Одни из них содержат давно известные дыры и рассчитаны на начинающих хакеров, только-только осваивающих командую строку и читающих книги десятилетней давности. Другие – защищены по самые помидоры и ориентированы на выявление еще неизвестных атак, совершающихся опытными взломщиками. Поэтому, даже обнаружив новую дыру, не спеши ломиться на первый же попавшийся сервер. Ведь, если атака завершится неудачно, информация об уязвимости попадет в загребущие лапы специалистов по информационной безопасности, а ты можешь оказаться на скамье подсудимых или (что еще хуже) больничной койке, считая перебитые ребра. Кстати говоря, очень многие узлы-приманки построены на ОС с настройками по умолчанию. И в этом есть свой резон. Дыры стандартных конфигураций хорошо известны, что обеспечивает максимальный приток атакующих.

    Сетевой сенсор чаще всего реализуется на базе UNIX-подобной ОС, а для мониторинга информации используется утилита tcpdump или ее аналоги. В зависимости от конфигурации сети сенсор может как находиться на одном из узлов данного сегмента локальной сети, так и являться маршрутизатором, расположенным перед приманкой. Иногда сетевой сенсор совмещается непосредственно с самой приманкой. Это существенно упрощает и удешевляет систему honeypot'а, однако ослабляет ее иммунитет (захватив управление приманкой, атакующий быстро обнаружит сенсор и сделает ему харакири). Размещение сенсора внутри широковещательного сегмента обеспечивает ему наибольшую скрытость. Сетевой интерфейс сенсора может и не иметь собственного IP-адреса, прослушивая трафик в Stealth-режиме, что достигается путем физического обрезания передающего провода на сетевой карте (см. статью о сниферах в этом номере). Маршрутизатор в этом смысле намного более заметен, однако определить, работает ли на нем сетевой сенсор или нет, в общем случае невозможно.

    Дампы tcpdump'а обрабатываются различными анализаторами (например, IDS), во-первых, распознающими сам факт атаки, а, во-вторых, определяющими IP-адрес нарушителя. Накапываемая информация оседает в коллекторе, сердцем которого является база данных. Это самое уязвимое место honeypot'а. Необходимо заранее выбрать четкие критерии, позволяющие однозначно определить, какие действия являются нормальными, а какие – нет. В противном случае администратор будет либо постоянно дергаться, вздрагивая от каждого сканирования портов, либо пропустит слегка видоизмененный вариант известной атаки. Есть и другая проблема. Если приманка не имеет никакого другого трафика, кроме хакерского (что легко определить по характеру изменения поля ID в заголовках IP-пакетов, подробнее о котором рассказывается в статье о брандмауэрах), то атакующий немедленно распознает ловушку и не станет ее атаковать. Если же приманка обслуживает пользователей внешней сети, непосредственный анализ дампа трафика становится невозможным и хакеру ничего не стоит затеряться на фоне легальных запросов. Достаточно эффективной приманкой являются базы данных с номерами кредитных карт или другой конфиденциальной информацией (естественно, подложной). Всякая попытка обращения к такому файлу, равно как и использование похищенной информации на практике, недвусмысленно свидетельствует о взломе. Существуют и другие способы поимки нарушителей, но все они так или иначе сводятся к жестким шаблонам, а значит, в принципе, не способны распознать хакеров с нетривиальным мышлением.

    Короче говоря, опытный взломщик может обойти honeypot'ы. Попробуем разобраться как.

    Срывая вуаль тьмы

    Прежде чем бросаться в бой, взломщику необходимо тщательно изучить своего противника: реконструировать топологию сети, определить места наибольшего скопления противодействующих сил и, естественно, попытаться выявить все honeypot'ы. Основным оружием хакера на этой стадии атаки будет сканер портов, работающий через «немой» узел и потому надежно скрывающий IP-адрес атакующего.

    Явно уязвимые сервера лучше сразу отбросить – с высокой степенью вероятности среди них присутствуют honeypot'ы, дотрагиваться до которых небезопасно. Исключение составляют публичные сервера компаний, расположенные в DMZ-зоне – совмещать их honeypot'ом никому не придет в голову, правда, на них вполне может работать IDS.

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

    Отвлекающие маневры

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

    Естественно, артобстрел необходимо вести через защищенный канал.

    Атака на honeypot

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

    Как вариант, можно наводнить сеть SYN-пакетами или вызвать ECHO-death (шторм ICMP-пакетов, направленный на жертву с нескольких десятков мощных серверов, что достигается спуфингом IP-адресов).

    Саму же атаку лучше всего осуществлять поверх протоколов, устойчивых к перехвату трафика и поддерживающих прозрачное шифрование, ослепляющее сетевой сенсор. Чаще всего для этой цели используется SSH (Secure Shell), однако он ограничивает выбор атакующего только явно поддерживающими его узлами, что сводит на нет весь выигрыш от шифрования.

    Заключение

    Сила honeypot'ов – в их новизне и неизученности. У хакеров пока нет адекватных методик противостояния, но не стоит думать, что такая расстановка сил сохранится и в дальнейшем. Архитектура honeypot'ов плохо проработана и уязвима. Уже сегодня опытному взломщику ничего не стоит обойти их, завтра же это будет уметь каждый подросток, установивший *nix и, презрев мышь, взявшийся за клавиатуру.

    Мнение эксперта

    Никита Кислицин, редактор рубрики «Взлом» журнала «Хакер»:

    «Не стоит думать, что honeypot и honeynet – это что-то экзотичное, чрезвычайно редкое и малоэффективное. Это не так. Могу совершенно определенно сказать, что в ряде сетей популярных российских сетевых проектов действуют развернутые сети honeypot, которые вылавливают тысячи скрипткидисов в месяц. Хотя иногда попадаются и действительно ценные рыбки – взломщики с приватными сплоитами, которые пытаются повалить какой-то сетевой демон доселе неизвестным shell-кодом. Это является первоочередной задачей подобных систем. Именно поэтому сетевому взломщику чрезвычайно важно уметь идентифицировать и определять honeypot-системы, чтобы не пропалить собственные секреты».

    Типичный honeypot представляет собой грандиозный программно-аппаратный комплекс, состоящий из узла-приманки, сетевого сенсора и коллектора.

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

    Выходить в сеть по коммутируемому доступу равносильно самоубийству, в особенности со своего домашнего номера.

    Многие бесплатные прокси в действительности являются приманками, установленными спецслужбами и существенно помогающими им в отлове горе-хакеров.

    Honeypot удобнее всего выявить сканером портов, работающим через «немой» узел и потому надежно скрывающим IP-адрес атакующего.

    Архитектура honeypot'ов плохо проработана и уязвима.
     

    Главная | В избранное | Наш E-MAIL | Добавить материал | Нашёл ошибку | Наверх