Спецвыпуск журнала «Хакер» 47, октябрь 2004 г.
Шрифт:
Еще одна вещь, которая может помочь при расследовании инцидентов, да и вообще полезна в качестве контроля за системой, это аккаунтинг процессов (во FreeBSD включается установкой переменной accounting_enable="YES» в /etc/rc.conf, в Linux – CONFIG_BSD_PROCESS_ACCT=y в конфиге ядра). Будучи включенным, он протоколирует в /var/account/acct (в Linux – /var/log/pacct) запуск всех процессов, позволяя посмотреть, когда, что и от имени какой учетной записи было запущено (lastcomm(1)), а также позволяет выдать статистику по выполненным процессам (sa(8)).
Хорошая
Помимо самой системы уязвимости находят и в софте, инсталлируемом из пакетов/портов. Полезно, конечно, читать адвайзори от вендоров, но наиболее удобный способ – положиться на автоматизированный аудит безопасности. Так, во 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
Докучаев Дмитрий aka Forb (forb@real.xakep.ru)
Фаервол – неотъемлемая часть *nix-системы. Но, как любой программный продукт, он нуждается в тщательной настройке. Сейчас я расскажу о том, как грамотно защитить свой сервер с помощью сетевого экрана iptables. Этот фаервол является самым простым и надежным, поэтому рекомендую ознакомиться с этим материалом.