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
