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

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

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

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

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

Всем давно понятно, что фраза «*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).