Linux глазами хакера - Михаил Флёнов

Такая политика соответствует нашему основному правилу "Что не разрешено, то запрещено" и обеспечит максимальную безопасность сервера.

4.6. Дополнительные возможности защиты

Помимо прав доступа у любого файла есть еще и атрибуты, которые позволяют построить дополнительную стену безопасности на пути взломщика. Единственное условие — атрибуты могут использоваться только на файловых системах Ext2 и Ext3. Но ограничением это можно назвать с большой натяжкой, потому что Ext3 уже давно становится стандартом для всех дистрибутивов.

Просмотреть текущие атрибуты можно с помощью команды lsattr:

lsattr filename.txt

-------------- filename.txt

Первая строка демонстрирует использование команды, а во второй — отображается результат работы. Как видите, мы получили набор символов тире вместо атрибутов, а значит, ни один из них не определен.

Для установки атрибута применяется команда chattr:

chattr атрибуты файл

Если требуется рекурсивное изменение доступа к каталогу и всем содержащимся в нем файлам и подкаталогам, можно использовать ключ -R. В этом случае вместо имени файла укажите директорию.

Приведу перечень атрибутов, применяемых в команде chattr:

□ A — не создавать метку atime записи времени последнего обращения к файлу. С точки зрения безопасности этот атрибут несет отрицательный эффект, потому что по дате обращения можно контролировать, когда файл был модифицирован. Поэтому не рекомендую устанавливать этот флаг. Но если у вас под ОС Linux работает личный компьютер, и нет необходимости отслеживать историю изменений, то можно установить этот атрибут, тем самым уменьшить количество обращений к диску (избавитесь от лишней операции записи при сохранении файла);

□ a — позволяет открывать файл только в режиме добавления. Это значит, что уже существующие данные изменить или удалить нельзя;

□ d — игнорирует файл при копировании. Этот флаг позволяет уменьшить размер резервной копии, но устанавливать его нужно только на файлы, не имеющие ценности и важности, например, временные;

□ i — запрещает выполнение с файлом каких-либо действий по корректировке (изменение, удаление, переименование, создание ссылок);

□ s — делает невозможным восстановление файла после удаления. Все пространство на диске, где был файл, будет заполнено нулями;

□ S — во время изменения файла все действия будут фиксироваться на жестком диске.

Для установки атрибута перед ним нужно поставить знак плюс, для снятия — знак минус. Рассмотрим несколько примеров:

chattr +i test

chattr +s test

lsattr test

s--i----------- test

В первой строке мы добавляем атрибут i, а значит, запрещаем какие-либо изменения файла. Во второй строке устанавливаем флаг s, и теперь при удалении файла можно быть уверенным, что он уничтожен полностью. Команда в третьей строке запрашивает текущие атрибуты, и в последней строке вы можете увидеть, что в перечне атрибутов первый символ равен "s", а четвертый — "i".

Итак, у нашего файла два взаимоисключающих атрибута. Один запрещает изменения, другой требует полного стирания с диска. Что произойдет, если мы попытаемся удалить файл. Посмотрим?

rm test

rm: remove write-protected file "test"?

В первой строке мы выполняем команду удаления файла. На это ОС просит подтвердить операцию над защищенным от записи файлом (сообщение показано во второй строке). Как видите, ОС определила наш атрибут i. Попробуйте ввести букву "Y", чтобы удостоверить действие. Вы увидите сообщение об ошибке, и файл останется на месте.

Давайте снимем атрибут i:

chattr -i test

lsattr test

s-------------- test

После отмены атрибута я использовал команду lsattr , чтобы убедиться в правильности выполнения команды. Вот теперь файл легко удалить с помощью команды rm.

4.7. Защита служб

В данной книге будет рассматриваться множество серверных служб. Безопасность их работы для системы в целом зависит не только от правильной настройки самой службы, но и от прав, которые вы ей дадите. Хакеры очень часто атакуют определенные сервисы и ищут в них изъяны, через которые можно было бы проникнуть в систему, а как мы знаем, ошибки есть всегда и везде.

Во время написания этой книги на мой сайт было произведено несколько удачных атак, потому что в силу занятости я просто не обновлял свой сайт, который располагался на сервере известной хостинговой компании. За два дня на сайте дважды меняли главную страницу, а потом злоумышленники захватили форум. Мне пришлось его убирать в недоступное место, чтобы восстановить свои права администратора, напрямую редактируя базу данных MySQL.

Как произошел взлом? На сайте стоял форум phpBB. Это один из популярных движков и абсолютно бесплатный, поэтому его выбирают многие владельцы сайтов. Большинство хакеров стремятся найти ошибки в наиболее известных разработках, и иногда им это удается. Только своевременное обновление форума (в данном случае) позволяет защититься от нападения.

После атаки я обновил движок, но это не помогло. Разработчики в последнюю версию не включили устранение одной критической ошибки, а инструкции по исправлению дали только на форуме своего сайта. Конечно же, я не увидел этих предписаний и в итоге мог потерять всю базу данных, если бы один из посетителей сайта не указал на ссылку, исправляющую ошибку.

Давайте на примере абстрактного сайта www.sitename.com посмотрим, как происходило вторжение. На форуме нужно войти в просмотр какой-нибудь темы, и в строке адреса появится ссылка:

http://www.sitename.com/forum/viewtopic.php?p=5583

Если к этой ссылке добавить в конец текст

&highlight=%2527.$poster=%60команда Linux%60.%2527,

то указанная команда Linux выполнится на сервере.

Вот так, например, можно было просмотреть файлы каталога /etc на сервере:

&highlight=%2527.$poster=%60ls%09/etc%09-la%60.%2527

А вот эта команда могла удалить главную страницу сайта:

&highlight=%2527.$poster=%60rm%09index.php%60.%2527

Как видите, благодаря ошибке в одной строке программы форума под угрозой оказалось существование всего сервера.

А ведь опасность можно уменьшить, ограничив права Web-сервера в ОС. Для этого администраторы должны создать виртуальную среду для выполнения Web-сервиса и страницы, при этом все остальные разделы сервера становятся недоступными для злоумышленника. В этом случае и каталог /etc окажется недосягаемым, и максимальный вред, который сможет нанести злоумышленник, — уничтожить сайт и нарушить работу Web-сервиса, но все остальные будут трудиться в штатном режиме. Восстановить один сервис проще, чем налаживать абсолютно все.

После этого случая я целый день бродил по Интернету в поисках уязвимых форумов, и таких оказалось много, потому что администраторы сайтов явно не следят за обновлениями. Я думаю, что в скором времени эти администраторы пройдут через все круги ада. Рано или поздно взломщик найдет форум, и в этом случае нужно молиться, чтобы он не уничтожил всю базу, а только пошалил. Хочется еще раз напомнить о необходимости обновления всех программ, сервисов и самой ОС. Если вы сможете исправить ошибку раньше хакера, то обезопасите свою жизнь.

Во время поисков уязвимых форумов я просматривал возможность получения доступа к каталогу /etc, чтобы увидеть не только количество неопытных владельцев сайтов, но и некомпетентных администраторов. Вы не поверите, но доступ открыт, наверное, на 90% серверов. Это безграмотность администраторов или их лень? Не знаю, и точно сказать не могу. Только крупные серверы были защищены, а мелкие хостинговые компании явно экономят на заработной плате хороших администраторов.

4.7.1. Принцип работы

Итак, давайте рассмотрим принцип работы защиты служб. Для этого создается директория, которая является для программы корневой. В Linux для этого существует команда chroot, которая создает chroot-окружение. Получается псевдокорневая файловая система внутри существующей.

Выше этой директории программа, работающая в окружении chroot, попасть не может. Посмотрите на рис. 4.1. Здесь показана часть файловой системы Linux. Во главе всего стоит корневая директория /. В ней находятся /bin, /usr, /var, /home. В папке /home расположены каталоги пользователей системы. Мы создаем здесь новую директорию, для примера назовем ее chroot, и она станет корнем для службы. В ней есть свои каталоги /bin, /usr и т.д., и сервис должен работать с ними, а все, что выше /home/chroot, будет недоступно.

Рис. 4.1. Схема работы chroot-окружения