Geum.ru

Брандмауэры и специальное программное обеспечение 8 Часть 4

Вид материалаРеферат

Содержание


Другие меры
Восстановление после атаки
ССЫЛКА О конфигурации syslog и чтении файлов syslog рассказывается в главах 22 и 23 соответственно.
Подобный материал:
1   ...   50   51   52   53   54   55   56   57   ...   101

Другие меры


Запуск служб в рабочей среде с измененным корнем — это лишь один из способов, которыми вы можете воспользоваться для того, чтобы защитить вашу систему. В качестве дополнительных средств защиты можно использовать IP Chains (ядро версии 2.2.x) или NetFilter (ядро версии 2.4.x) для наблюдения за портами и/или блокирования портов. Вы также можете использовать tripwire для того, чтобы связать службу с ловушкой. В остальных частях книги мы рассмотрим программные средства, которые можно использовать для защиты.

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

Как уже говорилось ранее, помимо прочего для контроля безопасности вы можете воспользоваться командой lsattr -v. Очевидно, этот метод не является на 100% надежным. Говоря точнее, если версия inod файла изменилась с 3302778664 на 1, вы можете быть уверенными в том, что файл модифицирован. Однако если номер версии не изменился, вы не можете сказать с полной уверенностью, осталось ли содержимое файла неизменным или файл был модифицирован. Чтобы проверить это, вы должны воспользоваться каким-либо иным способом.

Причина подобной неуверенности лежит в том, каким образом работают команды копирования (cp) и перемещения (mv) файлов. Если вас это интересует, я расскажу об этом подробнее.

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

- Команда cp копирует данные из блока данных одного файла в блок данных другого файла и обновляет atime и mtime (время доступа и время модификации).

- Команда mv изменяет указатель каталога и перенаправляет имя файла от одного inode на другой inode. После этого имя файла указывает на другой mode. Значения atime и mtime не обновляются. Если же файлы размещаются на двух разных разделах:

- Команда cp выполняется так же, как и в первом случае.

- Команда mv не только выполняет копирование блоков данных, но и меняет некоторую информацию inode (только не всю). Номер версии inode не меняется, однако меняются значения atime и mtime. Таким образом, в этом случае указатель каталога не изменяется, inode используется повторно, благодаря чему номер версии inode остается прежним.

Исходя из только что сказанного можно сделать вывод, что изменение номера версии inode осуществляется только в одном из четырех рассмотренных случаев: в ситуации, когда выполняется команда mv и два файла размещаются на одном и том же разделе.

Восстановление после атаки


Если вы обнаружили, что кто-либо обладает доступом к вашей системе на уровне привилегий root, вы можете действовать в соответствии с одним из трех вариантов. Первый вариант предусматривает полную переустановку всей системы и всех программ — сделайте резервную копию рабочих данных, отформатируйте каждый из разделов и начните формирование системы с нуля. Это гарантированный и самый лучший метод (самый простой, дающий полную уверенность в решении проблемы и самый практичный), однако данный вариант далеко не всегда является приемлемым. Если вы отформатируете все разделы и выполните установку заново, вы уничтожите все следы взлома. При этом вы также потеряете все конфигурационные файлы, данные и т. п. Иногда подобное недопустимо.


ПРИМЕЧАНИЕ

Если вы видите некоторую запись в журнале, которая выглядит как искаженная передача данных, попробуйте найти строку /bin/sh. Зачастую эта команда располагается в глубине строки, окруженная множеством специальных символов (каждый из которых выглядит как буква верхнего регистра, перед которым стоит символ ). Если вы обнаружите подобную запись, имейте в виду, что это не случайный набор символов, а преднамеренная попытка переполнения буфера.

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

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


ССЫЛКА

О конфигурации syslog и чтении файлов syslog рассказывается в главах 22 и 23 соответственно.

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

Прежде всего следует убедиться в том, что никаких изменений не внесено в любой из подкаталогов etc/. В вашей системе может быть несколько таких подкаталогов. Зачастую программы, устанавливаемые в системе, создают конфигурационные файлы в подкаталогах /usr/local/etc, var/etc, /use/etc и проч. В подкаталогах /opt также могут находиться подкаталоги etc/. Однако корневой каталог /etc является наиболее важным.

В главном каталоге /etc содержатся файлы passwd, shadow, group и (возможно) gshadow. Необходимо убедиться в том, что ни один из этих файлов не модифицирован. Фактически невозможно (а на самом деле и бессмысленно) проверить, завладел ли взломщик копией файла shadow или нет. Поэтому всегда следует считать, что этот файл уже известен взломщику. Исходя из этого следует сменить пароль пользователя root.

Изучая содержимое упомянутых файлов, следует обращать внимание на пользователей, обладающих UID 0 и не являющихся пользователем root, появление пустых паролей (паролей null) для любой из учетных записей, разблокирование ранее заблокированных учетных записей, пользователей, добавленных в любую из системных групп, и т. п. Подобные проверки можно выполнить с использованием grep (если файлы очень крупные, например, как в университетских компьютерных сетях) или вручную (для небольших офисных и домашних сетей).

В каталоге /etc располагается также подкаталог pam.d. Расположенные в нем файлы определяют работу служб с ограниченным доступом, и если изменить любой из них, можно открыть доступ к соответствующей службе через вход, который ранее был закрытым. Также можно просто отключить некоторые из проверок. Более подробно о содержимом этих файлов рассказывается в главе 1. Однако следует помнить, что некоторые файлы каталога /etc/pam.d указывают на другие файлы, расположенные в каталоге /etc, поэтому они могут быть также модифицированы.

В каталоге /etc также содержится подкаталог rc.d и файл inittab. Все программы, упоминаемые в файле inittab и подкаталоге rc.d, запускаются от имени пользователя root, и злоумышленник может воспользоваться этим. Например, он может добавить строку, которая будет от имени пользователя root запускать командную оболочку, и связывать ее с любым удобным для него портом. Так как оболочка будет запущена от имени пользователя root, ее вовсе не обязательно связывать с портом ниже 1024.

В каталоге /etc/X11 содержится набор подкаталогов, содержащих файлы, запускаемые от имени пользователя root. Поэтому данный каталог тоже может заинтересовать взломщика, впрочем, как и каталог /etc/cron.d. На самом деле весь каталог /etc (и его подкаталоги) является идеальным местом для взломщика, желающего добавить в какой-нибудь файл строку, запускающую какую-либо службу от имени root.

Проверяя, модифицировал ли взломщик какие-либо файлы, следует уделить внимание подкаталогам sbin/ и bin/. Такие подкаталоги размещаются в каждом из крупных каталогов, начиная с корневого каталога файловой системы (в этих подкаталогах размещаются наиболее важные исполняемые файлы) и заканчивая /usr, /usr/local и даже в подкаталогах каталога /opt.

Наиболее часто модификациям подвергается исполняемый файл /bin/login. Для любой системы этот исполняемый файл является воротами, которые ведут внутрь системы. Без всякого сомнения, этот исполняемый файл является наиболее уязвимым местом системы. Даже не пытайтесь проверить его неизменность — просто замените его на заведомо корректную версию. Корректная (изначальная) версия этого файла содержится в пакете util-linux-x.xx-x.i386.rpm. Всегда используйте самую последнюю версию, кроме того, сделайте соответствующий более свежий пакет RPM пакетом по умолчанию. Система администрирования пакетов RPM (kpackage) позволяет форсировать (force) использование более свежих версий пакетов вместо пакетов, которые уже установлены в системе. Благодаря этому вы сможете заменить более свежими версиями значительное количество исполняемых файлов, расположенных в подкаталогах /bin и /usr/bin.

Далее следует уделить внимание каталогам lib/. В подкаталоге /lib корневого каталога системы располагается подкаталог modules, в котором размещаются модули ядра, добавляемые пользователем root. В этих подкаталогах также содержится весь код общего доступа, то есть код, используемый разнообразными утилитами и программами. Если в вашей системе произошла замена службы login, новая версия login могла быть сформирована одним из трех способов: сборка могла быть выполнена на вашей системе с использованием ваших библиотек (в этом случае новая версия абсолютно точно будет работать в вашей рабочей среде); сборка могла быть выполнена на аналогичной системе с использованием библиотек, аналогичных вашим (таким образом, новая версия опять же должна работать); сборка могла быть выполнена с использованием произвольной библиотеки, в этом случае в вашей системе должны быть установлены как бинарный файл login, так и используемая им библиотека.

Наконец, следует выполнить проверку подкаталогов tmp/. Здесь следует искать не столько модифицированные файлы, сколько файлы неизвестного назначения. Если вы сомневаетесь относительно некоторого файла, лучше всего просто уничтожьте его. Временные каталоги часто используются в качестве места хранения комплектов доступа к системе на уровне root (root kit). Иными словами, злоумышленник размещает во временном каталоге файлы, необходимые для несанкционированного доступа в систему. Если во временном каталоге обнаруживаются файлы, к которым никто не обращался на протяжении всей минувшей недели, скорее всего, такие файлы следует удалить.


ПРИМЕЧАНИЕ

Входящая в состав комплекта Caldera OpenLinux 2.3 программа cleandir упрощает процесс очистки каталога tmp.

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

Хороший метод проверки показан в листинге 14.2.

Листинг 14.2. Процедура проверки установленных в системе пакетов RPM #!/bin/bash

PATH=/bin:/sbin:/usr/bin:/usr/sbin

export PATH

VFILE=/root/rpm.verify.'date +%d%m%y'

for i in 'rpm -qa'

do

rpm -V $i >> $VFILE

done

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


ПРИМЕЧАНИЕ

Среди файлов dailyscript есть программа под названием check-packages, которая выполняет проверку установленных в системе пакетов, а затем сравнивает их с результатами, полученными за день до этого.

Сценарий просматривает каждый из RPM-файлов, упоминаемых в базе данных пакетов RPM, установленных в системе, а затем выполняет сравнение так, как это показано в листинге 14.3.

Листинг 14.3. Сокращенный вывод команды rpm -V, выполненной в отношении всех установленных в системе пакетов

.M...UG. /dev/vcsa1

.M....G. /dev/vcsa2

....L... /dev/video

S.5....Т с /etc/printcap

.......Т с /etc/sysconfig/daemons/bigfs

SM5....T с /usr/XllR6/lib/Xll/app-defaults/Bitmap
missing /usr/src/linux-2.2.10/vmlinux

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

Листинг 14.4. Обозначения, используемые в листинге 14.3

S размер файла

М режим доступа (включая разрешения и тип файла)

5 MD5 сумма

D устройство (Device)

L символическая ссылка (Symlink)

U пользователь (User)

G группа (Group)

Т время модификации (Mtime)

с обозначает конфигурационный файл

Обратите внимание, что в результирующий файл вносятся только записи об обнаруженных несоответствиях. Если для некоторого файла все тесты выполнены, соответствующая запись не вносится в результирующий файл. Например, если вы проверяете пакет util-linux и в ходе проверки не обнаружено ни одного несоответствия (все восемь тестов пройдены), запись об этом не будет добавлена в результирующий файл проверки.

Также следует убедиться в том, что ни в одном из пользовательских домашних подкаталогов не содержится программ, которые способны работать в режиме SUID root или SGID root. Поиск подобных программ обсуждался в начале книги.