Береги ОС с инсталляции

Сергей ЯРЕМЧУК, оригинал

К сожалению, абсолютно защищенных систем пока еще не придумали - готовые программы для проникновения в любую из существующих, равно как и описание соответствующих технологий, можно найти в открытых источниках. Старые бреши в операционных системах и сервисах со временем благополучно сменяются новыми, и процессу этому пока не видно конца. Утверждения сторонников ОС GNU/Linux о том, что эта система гораздо защищеннее систем от Microsoft, мне кажутся несколько преувеличенными. Да, я согласен, возможность прямого анализа кода системы, без необходимости ее дизассемблировать, существенно облегчает поиск уязвимостей - вопрос только в том, кто первый эту уязвимость найдет. До недавнего времени Linux, как и Unix в целом, спасала фрагментация - наличие большого количества дистрибутивов и операционных систем, а также различие входящих в их состав приложений или их версий. Эта неразбериха отнюдь не способствовала большим вирусным эпидемиям, характерных для мира Windows, основной код которой вряд ли так уж существенно переделывается от версии к версии. Но в последнее время наметилась тенденция к уменьшению спасительного разнообразия, и что там дальше будет, неизвестно. Можно, конечно, кричать, топать ногами, писать письма, но действительно хороших аналитических материалов, сравнивающих архитектуру Linux и Windows, в Сети не так уж много - бо[ударение!!!]льшая часть статей основана на эмоциях. Различные же статистики зафиксированных взломов сами по себе ни о чем не говорят, а отражают, скорее, распространенность систем, да и настоящей, полной статистики не знает никто, о многих взломах пострадавшие предпочитают промолчать. Между тем ведь и в Unix/Linux-системах также водятся всякие вирусы, черви, троянцы, rootkits и прочая тварь. Принцип "этого не может быть, потому что не может быть никогда" - плохое основание для защиты.

Справедливости ради стоит отметить, что все-таки общая культура защиты у пользователей систем Open Source развита получше. Несколько причин способствует этому. Все-таки, что ни говори, а среднестатистический Linux-пользователь более подготовлен, он знает, что компьютерный вирус - это (как ни странно это звучит) всего лишь программа, которую надо сначала запустить на своем компьютере (не все же они используют уязвимости в тех или иных сервисах). Дополнительную ответственность на разработчиков и дополнительный контроль со стороны пользователей налагает распространение программ в исходных кодах. Добавить пару-тройку функций, открывающих доступ к компьютеру, - плевое дело - пересобирать заново rpm-пакеты захочет/сможет далеко не каждый. А посему за новыми программами ходят на те ресурсы, которым полностью доверяют, и которые беспокоятся о своей репутации (домашняя страница программы, специальные сайты вроде http://rpmfind.net/ и http://www.freshports.org/). На домашнюю страницу Васи Пупкина вряд ли стоит идти за новой версией XMMS. Также каждый уважающий себя разработчик или распространитель ПО рядом с программой в отдельном файле вроде checksum.md5 (и/или внутри в отдельном файле) указывает контрольную сумму, которую можно тут же проверить. Такая проверка по алгоритму MD5 по возможности гарантирует, что в файле нет изменений, и перед вами действительно оригинал.

Узнать контрольную сумму скачанного файла очень просто (утилита md5sum имеется в каждом дистрибутиве - если нет, возьмите на http://www.gnu.org/software/textutils/textutils.html):

Теперь, сравнив значения контрольной суммы, выданной программой, с указанной в файле, можно сделать вывод о подлинности файла. Аналогично, купив дистрибутив где-нибудь на рынке, желательно для успокоения души зайти на сайт производителя и выяснить контрольную сумму выложенных iso-образов или отдельных приложений. Проверка контрольной суммы вообще должна войти в привычку при каждой установке программного обеспечения. В FreeBSD-системах при отсутствии в дистрибутиве нужной программы или версии, прежде чем обращаться на сайт или компилировать ее из исходных текстов, перво-наперво следует обратиться к дереву пакаждей или портов. Если утилита в них включена, значит, она прошла тестирование на совместимость/безопасность и по крайней мере не станет причиной краха системы. В данном случае контрольная сумма сверяется при установке автоматически, без явного участия пользователя. К тому же это самый простой и безопасный способ установить новое ПО.

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

Узнать его электронный адрес очень просто. Зайдите в каталог нужного порта и дайте команду:

Пошлите по этому адресу вывод компилятора и информацию о системе (uname -a), и не забудьте заранее поблагодарить за помощь.

С помощью контрольной суммы можно не только проверить устанавливаемые программы. Если злоумышленнику все-таки удастся проникнуть в сеть, то его первым действием, скорее всего, будет установка или изменение некоторых программ. Например, он может заменить стандартную и довольно часто используемую программу ps на другую, с "трояном" внутри, а команда ls может не заметить созданные им каталоги. Чтобы избежать обнаружения, например, командой find, такие утилиты "умеют" имитировать время своего создания, но вот организовать подделку контрольной суммы куда сложнее.

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

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

то измененные файлы необходимо проверить. Опции:

• M - Отличается состояние (включая разрешения и тип файла);

• S - отличается размер файла;

• 5 - отличается сумма MD5;

• D - не соответствует число основных/второстепенных устройств;

• L - не соответствует путь readLink(2);

• U - отличается пользователь-владелец;

• G - отличается группа-владелец;

• T - отличается mTime.

Если, как в приведенном примере, это конфигурационные файлы, которые, естественно, должны измениться по сравнению с оригиналом по причине особенностей конкретной системы, то ничего страшного нет. А вот если будут попадаться файлы из каталогов, содержащих исполняемые файлы, то стоит насторожится. При помощи команды rpm -qf /path/to/file можно проверить, является ли данный файл частью пакета. Обнаруженное расхождение можно - естественно, предварительно сохранив измененные файлы для дальнейшего изучения, - тут же восстановить:

Но это еще не все. Более простое и четко структурированное файловое дерево во всех Unix-системах, в которых исполняемые файлы, файлы конфигурации, постоянно изменяющиеся (например, лог-файлы) и прочее лежат в разных ветках дерева, позволяет не только вынести целые дисковые разделы в read-only или ограничить доступ к ним на уровне ядра при помощи специальных патчей, но и контролировать целостность нужных файлов. В Windows же, например, выполнить подобную задачу несколько сложнее, т.к. придется охватить больший объем данных (программа пишет данные, необходимые для работы, куда посчитает нужным ее создатель, и поэтому они бывает раскиданы по всему диску). Впрочем, отдельные решения имеются - именно с их помощью удается узнать о том, что нечто или некто пытался изменить без ведома хозяина компьютера реестр и прочие критические области данных. Например, при испытании антивируса как-то гавкнул WinPatrol, о котором я писал (см. статью "Зубастый патруль", МК №47 (270)), сообщив, что какая-то программа пытается добавить себя в автозапуск - антивирус при этом спокойно висел в трее, ни о чем не подозревая. Так что применение специально обученных программ, проверяющих целостность системных файлов, может быть тем крайним средством, которое помешает злоумышленнику закрепиться на вашем компьютере.

Среди Open-Source программ, предназначенных для автоматизации процесса подсчета контрольных сумм и выдачи результата сравнения, наиболее популярны Tripwire ( http://www.tripwire.org/) и AIDE - Advanced Intrusion Detection Environment ( http://www.cs.tut.fi/~rammer/aide.html или http://sourceforge.net/projects/aide). Какую то из них вы точно найдете в своем дистрибутиве, хотя бывает, что разработчики включают и оба пакета, предоставляя выбор. Сегодня разберемся с тем, как настроить и использовать AIDE.

Протестирован и работает AIDE на большинстве Unix-системах: Solaris, Linux, FreeBSD, Unixware, BSDi, OpenBSD, AIX 4.2, TRU64 4.0x и под Cygwin.

Установка особой сложности не представляет. Распаковываем архив и компилируем обычным образом:

В качестве дополнительных опций могу порекомендовать –with-zlib для возможности использования zlib-компресии и –with-psql для хранения данных во внешней базе данных РostgresSQL.

Если компиляция прошла нормально, самое время приняться за конфигурационный файл. Называется он aide.conf, и после установки оказывается в каталоге /usr/local/etc. Разберем на примере (хотя и на сложном - для нормальной работы достаточно указать лишь проверяемые каталоги).

Как видите, единственная проблема состоит в том, чтобы определиться, к каким каталогам применять какие правила, чтобы избежать лишней избыточности и избавить себя от ложных предупреждений. Впрочем, после двух-трех прогонов на конкретной системе правила можно скорректировать по ситуации. В файле также возможно назначение переменных - например, в строке @@define MAILTO root переменной MAILTO присваивается значение root. В дальнейшем при запуске aide при помощи cron (см. статью Сергея ПАРИЖСКОГО "Пингвин на автопилоте", МК №50 (273)) отчет о работе будет послан по указанному адресу. После задания правил сохраняемся, и следующим шагом создаем базу. Для этого запускаем утилиту aide с параметром –i:

Этот шаг создаст базу и сохранит ее в database_out, в нашем случае это /var/lib/aide/aide.db.new. Это основная база, с которой будем в дальнейшем сверяться. При этом желательно базу держать на отдельном носителе, тем самым защищая ее от модификации. Например, сохранив ее на дискету:

И не указывая какого-либо значения переменной database в файле aide.conf, затем при проверке ее монтируем, заходим в каталог и даем команду для проверки.

Если вывод большой, чего не избежать при первоначальной настройки, перенаправляем вывод в файл:

И смотрим, что изменилось после создания базы. В файле увидите приблизительно такие строки:

Сразу становится ясно, что происходит в системе и какую информацию следует исключить из контроля, чтобы не перезагружать вывод. Так, например, для исполняемых файлов контроль времени доступа atime избыточен, иначе при каждом запуске программы информация об этом будет включена в отчет, а вот изменение времени создания (ctime) для /bin/ash выглядит очень даже подозрительно. Если в системе произошли глобальные изменения (например, обновлены некоторые пакеты), то базу следует обновить, воспользовавшись опцией –update.

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

Linux forever!