Многие администраторы часто вообще игнорируют логи, считая их почему-то ненужными. Наоборот, логи позволяют пролить свет на все события, которые происходят в системе. Рекомендуется просматривать логи хотя бы два раза в день. Если система работает ночью, каждое утро нужно просматривать логи, потому что очень много взломов происходит как раз в это время - когда администратор отдыхает.

     Защита /var/log

     Практически все файлы логов находятся в каталоге /var/log. Первым делом крекер, получивший права root, попытается скрыть следы своего присутствия, модифицировав файлы логов.

     Если используется ACL, можно сделать файлы в каталоге /var/log досягаемыми только для добавления данных. Но в конкретном случае, к сожалению,  больше нельзя будет применять программу logrotate, выполняющую ротацию логов: данной программе можно удалять файлы из каталога /var/log.

     Наиболее безопасное решение - отключить logrotate, учитывая объемы современных жестких дисков, ничего страшного с системой не случится.

Далее...

Сервер имен выполняет две роли: разрешает запросы клиентов и выступает в роли авторитетного сервера для какой-то зоны. Представим, что у нас есть средняя компания. Имеется домен www.test.net. Целесообразно разделить функции серверов имен.

     Один сервер имен будет находиться во внутренней сети и разрешать запросы клиентов - это будет сервер для внутреннего употребления. Второй сервер будет авторитетным для зоны - он будет отвечать на запросы интернет-пользователей для этой зоны. Месторасположение данного сервера - нейтральная зона (DMZ).

Далее...

Учитывая популярность вышеописанных систем, можно сказать, какая наиболее подходит для защиты конкретной системы. DTE является наименее распространенной, поэтому можно скон­центрировать все внимание на хорошо опробованных технологиях - SE­Linux, Grsecurity, LIDS и RSBAC.

     SELinux - самая сложная в настройке системы. Чтобы понять, как работа­ет SELinux, надо заново воспринять фундаментальные Unix-концепции пользователей, групп и прав доступа. Масла в огонь добавляет язык опи­сания правил - он очень сложен, хотя таким он кажется на первый взгляд, пока не разберешся с ним. Однако, несмотря на сложность настройки, SELinux - наверное, самая мощная и защищенная реализация МАС-модели.

     LIDS, RSBAC и Grsecurity основаны на ACL, благодаря чему данные системы заметно проще изучать, чем SELinux. Кроме данного, они содержат много дополнительных функций, к примеру определение сканирования портов (LIDS), защиту памяти РаХ (Grsecurity и RSBAC), и «укрепление» chroot (Grsecurity).

Далее...

Rule-Set Based Access Control (RSBAC).

     Rule-Set Based Access Control (RSBAC) - контроль доступа на основании набора правил - такое название еще у одной системы безопасности, доступной по адресу: http: //www.rsbac.org - которая появилась на свет в 1996 г. как несложной университетский проект. Как и другие проекты безо­пасности, со временем RSBAC набирала силу и становилась более гибкой и мощной.

     RSBAC использует общий интерфейс управления доступом (Generalized Framework for Access Control, GFAC), который позволяет употреблять много альтернативных методов управления доступом. Поддерживаются следующие методы:

Далее...

Рассмотрим пример ACL, который позволяет работать DNS-серверу на машине. ACL будет состоять из двух частей. Первая часть будет содержать общий набор правил, предоставляющих базовый доступ. Эта часть универсальна - она подойдет не только для DNS-сервера, но и для разных остальных приложений, запущенных в Linux-системе.

     Во второй части будут описаны специфические для DNS-сервера правила, ограничивающие доступ к файлам, и определяющие возможности DNS-сервера. Как было написано ранее, набор правил будет представлен в виде shell-сценария, который содержит серию команд lidsconf.

     Сначала надо сделать системные исполнимые файлы и библиотеки доступными только для чтения. Обойти данное ограничение нужно только в LFS-оболочке. Итак, надо защитить каталоги /bin, /sbin, /usr и /opt:

Далее...

Теперь, когда известно, как работает LIDS, и знакомы ее основные опции, нужно приступить к практической реализации LIDS в системе.

     Нужно помнить, что написание ACL для всей системы - очень трудоемкая задача, поэтому, как и в случае с iptables, рекомендуется создать shell-сценарий, содержащий директивы lidsconf. Первой директивой будет lidsconf -Z - эта директива удаляет все ранее существующие ACL. Этот сценарий надо поместить в /etc/lids, что сделает его невидимым за пределами LFS-сессии.

Далее...

Возможности.

     В ACL из предыдущей статье описано действие GRANT, предостав­ляющее возможность CAP SETUID. А возможности до этого и не рассматривались, поэтому самое время их рассмотреть.

     LIDS предоставляет расширенное применение возможностей (однако, как было отмечено до этого, модуль возможностей (capability security module) нужно отключить в ядре). Кроме стандартных возможностей Linux, LIDS дает две собственные возможности:

Далее...