Хакер - Спецвыпуск журнала «Хакер» #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.