Даже если вы следовали всем рекомендациям, приведенным выше, никто не может гарантировать 100%-ю безопасность вашей системы, поэтому психологически нужно быть готовым, что вашу систему можно взломать. Если же это случилось, нужно подумать, как вы будете восстанавливать систему. Причем лучше подумать заранее, чем потом, когда это уже случилось.

     Обнаружение нарушения безопасности

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

     Хотя знания среднего крекера можно с натяжкой считать умеренными, он может использовать утилиты, скрывающие его присутствие, написанные более образованными крекерами. Зачастую знания опытного крекера (того, кто пишет подобные программы), превышают знания среднего администратора.

     Самое первое, что нужно сделать - это отключить вашу машину от сети (мы подразумеваем, что ваша система была взломана именно по сети, а не локальным пользователем, у которого есть физический доступ к машине). После этого в спокойной обстановке (если ее можно назвать таковой, когда за спиной стоят десятка два пользователей с одним вопросом: «Когда будет работать сервер?») нужно проанализировать ваши протоколы. Да, крекер может модифицировать протоколы, но он этого не сделает, если вы следовали приведенным в книге рекомендациям и установили одну из ACL (хотя быту же LIDS).

Далее...

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

     Защита /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-сессии.

Далее...