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. Очень многие пренебрегают это полезной возможностью, а ведь в таком случае, чтобы загрузить вредоносный модуль или добавить свое правило в цепочку пакетного фильтра, взломщику придется перезагрузить машину, что не может остаться незамеченным.