Хакер - Спецвыпуск журнала «Хакер» #47, октябрь 2004 г.

Для Linux имеется проект IP Personality (http://ippersonality.sourceforge.net/) – патч к ядру, изменяющий поведение сетевого стека и позволяющий замаскировать систему под все, что не заблагорассудится, хоть под aix, хоть под приставку xbox.

Анализ типа сервиса может быть затруднен сменой баннеров, текстовых комментариев кодов ошибок. Никто не мешает тебе залезть в сорцы любимого SMTP-сервера и ручками поменять алгоритм генерации ID-тега :).

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

Статью Fyodor, переведенную на русский язык, можно найти по адресу http://www.insecure.org/nmap/nmap-fingerprinting-article-ru.html.

От сканирования nmap'ом могут помочь механизмы в OpenBSD PF, нормализующие трафик.

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

Технология remote fingerprinting хорошо зарекомендовала себя при производстве авторутеров/автоэксплоитов. Подобным программам очень полезно бывает сначала проверить версию сервиса или ОС, а уж потом применять эксплоит.

Защита

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

Антон Карпов ([email protected])

Всем давно понятно, что фраза «*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. Впрочем, история показывает, что опытные админы, как правило, консервативные фанаты определенного круга программ и предпочтут патчить свое детище раз в неделю, чем перейти на альтернативный продукт ;).