Делаем систему пуленепробиваемой!

Shaman (aka_shaman@mail.ru)

Xakep, номер #058, стр. 058-078-1

Безопасность LFS

Вот мы и подошли вплотную к вопросу обеспечения безопасности LFS, который ты должен был благополучно установить после статьи в предыдущем номере ][, где я вел речь о преимуществах LFS перед обычным дистрибутивом Пингвина. Несомненно, это один из самых интересных и захватывающих вопросов администрирования систем. Вместе с тем относиться к нему надо со всей серьезностью. Одно дело, если ты поставил LFS на настольную систему, работаешь один и не подключен к интернету. И совсем другое, если ты решил создать на основе LFS сервер в домашней или, что еще серьезнее, в корпоративной сети. Я не говорю про другие дистрибутивы Linux, которые (этого у них не отнять) более-менее защищены с самого начала. LFS - открытая система с точки зрения безопасности, и исправлением этого мы сейчас и займемся.

Локальная безопасность

Начнем с банальных вещей, о которых многие почему-то забывают. Никогда не работай под рутом, используй эту учетную запись только в случае крайней необходимости. Для повседневной работы используй непривилегированную учетную запись (например, admin). Во многих справочных материалах это не объясняется. А нужно это вот зачем: команда rm –r рекурсивно удаляет данные с диска. Если же ты случайно введешь ее под рутом (хотелось бы посмотреть на человека, который способен случайно под рутом ввести rm –r :)) то эта команда удалит все, тогда как под обычным пользователем основные системные файлы сохранятся. Возьмем более жизненный пример: некоторые вредоносные Java-апплеты могут получить твои права доступа и использовать их для атаки - а это случай не такой уж и редкий. Идем дальше. В противовес команде для выполнения административных задач – su, ты можешь использовать другую – sudo. Ее преимущество перед su - возможность работы без ввода рутного пароля. В конфигурационный файл /etc/sudoers прописываются команды, хосты и пользователи, которые эти команды могут выполнять. Например, в файле /etc/sudoers есть такая запись:

admin ALL=(ALL) ALL

Это значит, что пользователь admin может выполнять все команды на всех хостах от имени любого пользователя. О списке всех полезных опций sudo читай в мануале: man sudo. Теперь поговорим о правах доступа, точнее, о специальных правах доступа. Их два:

SGID (установить идентификатор группы - 2000)

SUID (установить идентификатор пользователя - 4000)

О том, что программы с такими правами доступа опасны, знают все (или почти все), однако не все знают, почему они опасны. Обычно программа выполняется с правами юзера, запустившего ее. Но SUID-программа выполняется с правами ее владельца. Это не страшно, если ее владельцем является обычный юзер, но что, если ее владельцем станет root? А будет вот что: если в программе есть ошибки (читай - баги), то непривилегированный юзер может получить привилегии рута. Поэтому сначала стоит проверить, так ли уж нужен программам этот бит, и если все-таки нужен - внимательно следить за ними. А поможет в этом программа sXid - программа для контроля за SUID/SGID программами. Запускаемая из cron, эта программа отслеживает любые изменения в suid’ных программах и папках. После ее инсталляции можно забыть о проблеме suid’ных файлов раз и навсегда. Скачиваем здесь: www.mirrors.wiretapped.net/security/host-intrusion-detection/sxid/sxid_4.0.2.tar.gz

Содержание  Вперед на стр. 058-078-2
ttfb: 3.3929347991943 ms