 |
|
|
|
Контрольная сумма на защите Linux/FreeBSD
Контрольная сумма на защите Linux/FreeBSD Из всех аспектов деятельности системного администратора наиболее интересным и в то же время самым сложным является обеспечение безопасности существования системы. Эту тему на различных курсах обычно излагают довольно поверхностно, но защита, определенно, наиболее важная часть работы, вне зависимости от назначения компьютера и типа операционной системы, установленной на нем. После того как компьютер станет доступным тысячам пользователей в Интернете или даже десятку сотрудников в небольшом офисе, придется львиную долю времени уделять проблеме бесперебойной и стабильной работы сервера, недопущению утечки конфиденциальной информации. Причем уделять внимание данному вопросу необходимо не время от времени, а целенаправленно и постоянно. Иначе в один прекрасный день на главной странице сайта появится надпись, что ваш сайт взломан. И это, кстати, не самое страшное, что может произойти. По теории защиты написано много книг и много еще будет написано. Это очень сложная тема, и надеяться, что в одной статье будут даны ответы на все вопросы, тоже не стоит. Начнем, пожалуй, с покупки дистрибутива. Лицензия Linux/FreeBSD хоть и позволяет использовать дистрибутив, купленный на радиорынке, так же, как и купленный официально, но доверять веб-сервер стоимостью свыше тысячи у.е. диску за несколько десятков рублей я бы не стал. Вполне вероятно, что это просто слитый с сайта ISO-образ, записанный на болванку, но точно гарантировать этого никто не может. Кто помешает заменить некоторые пакеты на доработанные под свои нужды с трояном внутри. Причем выдумывать самому ничего и не надо, все давно уже есть в паутине. Если все же другого выхода нет, или просто есть необходимость в установке программы, не входящей в основной дистрибутив, то всегда его нужно проверить на контрольную сумму. На большинстве ftp-архивов рядом с файлом можно найти информацию о контрольной сумме: либо в отдельном файле, например, CHECKSUM.MD5, либо непосредственно на веб-странице. Такая проверка по алгоритму MD5 хоть как-то гарантирует, что в файле никаких изменений не произведено, и перед вами действительно находится оригинал. Узнать контрольную сумму скачанного файла очень просто: $ md5sum mysql-max-3.23.55-unknown-freebsd4.7-i386.tar.gz
Теперь, сравнив обе контрольные суммы, можно сделать вывод. Проверка контрольной суммы должна войти в привычку при каждой установке программного обеспечения. По этой же причине никогда не стоит брать файл с первого попавшегося сервера, лучше всего зайти на домашнюю страницу или специальные сайты, предназначенные для этого: http://rpmfind.net, http://www.freshports.org. И еще один момент, связанный с установкой новой программы под FreeBSD. Если понадобилась программа, которой нет в дистрибутиве, или ее новая версия, тогда, несмотря на то что можно пойти сразу на сайт и скомпилировать ее из исходников, советую все же сначала обратиться к дереву пакаджей или портов. Включение в них утилиты свидетельствует о том, что программа прошла некоторое тестирование на совместимость и безопасность и не станет, по крайней мере, причиной краха системы. В данном случае проверка контрольной суммы происходит автоматически без вмешательства пользователя. К тому же это самый простой и безопасный способ установить новое ПО на вашу систему. Бывает, что компиляция с помощью порта, в том числе и по причине неправильной контрольной суммы, завершается с ошибкой. Здесь может помочь обновление дерева портов. В крайнем случае можно обратиться к человеку, поддерживающему данный порт (MAINTAINER), за консультацией и помощью. Узнать электронный адрес очень просто. Зайдите в каталог нужного порта и дайте команду: $ more Makefile | grep MAINTAINER
Отправьте по этому адресу вывод компилятора и информацию о системе (uname -a) и не забудьте заранее поблагодарить за помощь. С помощью контрольной суммы можно не только проконтролировать устанавливаемые программы. Первое, что злоумышленник произведет в вашей системе, – это установит или, скорее всего, изменит некоторые программы. При этом, например, стандартная и довольно часто используемая программа ps может быть заменена на другую с трояном внутри, а команда ls может не заметить созданные злоумышленником каталоги. Чтобы избежать такого безобразия и иметь некоторый инструмент, позволяющий проконтролировать целостность системных файлов, применяются утилиты, которые автоматически проверяют значения контрольных сумм файлов и каталогов и заносят их в свою базу данных. Впоследствии системный администратор может в автоматическом режиме сверить оригинальную, созданную при установке, базу данных с имеющимися в системе файлами и при расхождении контрольных сумм выдать предупреждение по электронной почте. В таком случае можно сразу узнать о вторжении и оценить ущерб. При этом сразу хочется отметить, что данные средства отнюдь не отменяют, а, скорее, дополняют другие методы защиты. Причем средства, контролирующие состояние файлов, имеют некоторое преимущество перед программами, выявляющими вторжение по наличию определенных сигнатур, хотя ничто не мешает использовать комплексный подход. Наиболее популярным средством для решения этой задачи является утилита Tripwire. Данная утилита доступна как OpenSource (http://www.tripwire.org) и как 30-дневная ознакомительная версия (http://www.tripwire.com). Скачать утилиту можно с сайта http://download.sourceforge.net/tripwire, по последнему адресу дополнительно можно найти документацию tripwire-docs. Для FreeBSD проще установить OpenSource Tripwire, воспользовавшись системой портов. # cd /usr/ports/security/tripwire # make install clean Единственный момент при установке, который может вызвать замешательство,– это когда программа спрашивает после просмотра лицензии:
Необходимо напечатать accept, нажатие Enter приведет к немедленному выходу из программы установки и ее придется повторить. При компиляции в других системах первоначально необходимо раскомментировать строки в файле /src/Makefile для переменной SYSPRE в соответствии с используемой системой (Linux по умолчанию). Далее следует ввести: # make all или # make *_r(d ) для установки одной выбранной программы и следовать дальнейшим указаниям программы. Установочные скрипты сами создадут ключи и инициируют базу данных. После установки при помощи rpm-пакетов следующим шагом необходимо произвести первоначальную инициализацию базы данных. Но для того чтобы не пришлось этого делать дважды, лучше всего сразу отредактировать файлы конфигурации и политик. Для этого в каталоге /etc/tripwire (/usr/local/etc/tripwire – FreeBSD) имеются два шаблона в виде текстовых файлов. В файле twcfg.txt содержится системно-специфическая информация о размещении файлов базы данных, редактор, используемый по умолчанию, программа и ее параметры для отправки почты. А в файле twpol.txt – файл политики, состоящий из серии правил, что должен контролировать tripwire, данные для объектов контроля, серьезность контролируемого объекта и адрес электронной почты (emailto =) для каждой группы контроля, на который высылается уведомление о нарушении (если требуется указать сразу несколько адресов – все их можно перечислить через запятую). Здесь же желательно сменить TEMPDIRECTORY = /tmp на каталог с нормальными правами доступа (в /tmp для всех rwx). Чтобы защитить против неправомерной модификации все важные Tripwire-файлы, они сохранены на диске в закодированной и подписанной форме. Сама база данных, политики, конфигурация и опции файла отчета защищены с El Gamal асимметричной криптографией с сигнатурой в 1024 бита. El Gamal использует набор ключей с одним открытым ключом и одним закрытым ключом шифрования. В криптографической системе Tripwire два файла ключей хранят public/private ключевую пару. Файлы конфигурации и политики защищаются от записи общим ключом, а сама база данных и отчеты – локальным ключом. Для чтения достаточно доступного публичного ключа, для записи требуется частный ключ, защищаемый парольной фразой. Поэтому после их редактирования, в соответствии с реальными настройками системы, необходимо запустить скрипт twinstall.sh, находящийся в этом же каталоге. Далее программа запросит site- и local-фразы (желательно не менее 8 символов) для генерации соответствующих ключевых пар. После этого в каталоге образуются зашифрованные файлы конфигурации и полиса tw.cfg и tw.pol, а также файлы ключей (/etc/tripwire/site.key и /etc/tripwire/host-local.key). В целях безопасности рекомендуется после окончания процедуры инсталляции удалить файлы шаблонов с данного каталога. Далее инициируем базу данных. # /usr/sbin/tripwire--init При этом после запроса локального пароля программа создает отпечаток важных системных файлов (размер, контрольная сумма, права, время доступа и т. д.), записывает ее в файл в каталоге /var/lib/tripwire/$(HOSTNAME).twd. Во время создания базы данных обратите внимание на сообщения об ошибках. Например:
Это означает, что в конфигурационном файле занесена излишняя информация. Желательно тут же подправить, иначе эти сообщения потом постоянно будут вас преследовать и дополнительно перегружать лог-файл. Затем эта база данных ежедневно сравнивается с текущим состоянием файловой системы, позволяя обнаружить добавленные, измененные и удаленные файлы, с выдачей довольно подробных отчетов. Такое расположение файла удобно при запуске утилиты проверки согласованности файловой системы с помощью демона cron, позволяющей полностью автоматизировать данный процесс, включая информирование по указанному электронному адресу о результатах проверки. Но обнаружив присутствие утилиты при получении определенных прав, злоумышленник может заменить (обновить) базу данных или полностью переустановить tripwire (что гораздо проще), и после такой модификации утилита проверки не заметит подвоха. И вы будете получать по почте сообщения о том, что с системой все нормально, пока в один прекрасный день не обнаружите несовпадение парольных фраз. Такой вариант также предусмотрен разработчиками, для этого необходимо поместить отформатированную дискету в дисковод и присвоить значению переменной TRIPWIRE_FLOPPY= YES с командой make install: # make install TRIPWIRE_FLOPPY= YES чтобы создать резервную базу данных: # make floppy После этого на дискете окажется все, что необходимо для восстановления системы и автономной работы утилит: копия начальной базы данных системы и дополнительно утилиты tripwire, twcheck и gunzip и копия файла tw.config. Хотя есть вероятность, что все это не поместится в 1.44 Мб флоппи-диска даже после архивирования, единственным выходом будет уменьшить количество объектов базы данных. В любом случае желательно резервировать всю систему на всякий случай и Tripwire в том числе, и периодически сверять оригинальную и рабочую базы данных. Проверить систему можно запустив программу tripwire без аргументов (или tripwire --check, кому как нравится), при этом программа сравнивает текущее состояние системы с сохраненным в базе данных и при несоответствии выдает сообщение, при этом отмечается даже такая мелочь, как изменение времени модификации программы. Аналогично производит ежедневную проверку демон cron посредством /etc/cron.daily/tripwire-check. А чтобы не ждать, пока система все проверит, можно указать опцию --email-report: # tripwire --check --email-report и сообщение электронной почты будет послано всем получателям, указанным в файле политики, используя формат сообщения, определенное в EMAILREPORTLEVEL. Но перед началом эксплуатации желательно проверить работу электронной почты с помощью команды: # tripwire --test --email user@domain.com Если нет необходимости в проверке всей системы, то можно сразу указать, какие объекты необходимо проверить. # tripwire --check object1 object2 object3 Все системные файлы разбиты по группам важности, что позволяет более гибко строить отчеты, не обращая внимания на некритические для системы файлы, и наоборот. Например, чтобы выполнить проверку для файлов, начиная от средней степени важности и выше, можно ввести такую команду: # tripwire --check --severity 66 Или используя поверку правил по имени rulename, которые прописаны в файле tw.pol. Например, для проверки системных файлов: # tripwire --check --rulename "File System and Disk Administraton Programs" Конечно же, при необходимости частого использования данного типа проверки желательно длинные имена, используемые в файле по умолчанию, заменить на свои, покороче. Ключ --interactive позволяет изменить БД в диалоговом режиме. Запускается текстовый редактор при помощи --visual имя-редактора или прописанный в переменной EDITOR в конфигурационном файле (или переменные окружения VISUAL или EDITOR) и предоставляется возможность отредактировать форму изменения БД, в которой каждый заносимый файл надо отметить крестиком в секции Object Summary, при этом запрашивается парольная фраза. Конечно же, со временем некоторые утилиты обновляются или удаляются и заменяются другими, поэтому с помощью опции --update можно обновить базу данных: # tripwire --update Для обновления всей системы: # tripwire --update /usr/sbin/sshd А если указать конкректную программу, то обновляются сведения только о ней. Программа после проверок создает отчет, по умолчанию это файл /var/db/tripwire/report/(HOSTNAME)-$(DATE).twr. Файл после создания будет иметь примерно такое название: localhost-20030327-071039.twr Но при помощи команды: # tripwire --check --twrfile /var/lib/report/myreport.twr можно задать свой файл отчетов, что удобно использовать в самостоятельно написанных скриптах. По умолчанию при генерации отчетов используется REPORTLEVEL=3 (Concise Report), отражающий довольно подробную информацию с выводом ожидаемых и наблюдаемых значений и прочее, который можно изменить в файле tw.cfg. Tripwire позволяет гибко задавать отчеты, в зависимости от необходимости в той или иной информации, для этого на ходу изменяется report_level в пределах от 0 до 4. # twprint --print-report --report-level 1 --twrfile /var/lib/report/report.twr При необходимости внесения глобальных изменений всегда можно будет получить расшифрованную копию конфигурационного файла при помощи команды: # twadmin –print-cfgfile > /etc/tripwire/twcfg.txt После внесения необходимых изменений и сохранения зашифрованный файл создается командой: # twadmin --create-cfgfile --site-keyfile /etc/tripwire/site.key /etc/tripwire/twcfg.txt Аналогично при добавлении новых файлов, которые вы желаете контролировать, изменении уровня значимости или удалении старых, при изменении адресов электронной почты и засорении файла отчетов ложными сообщениями, захочется изменить файл политик. Создаем копию файла политик: # twadmin --print-polfile > /etc/tripwire/twpol.txt И после внесения необходимых изменений модифицируем политики: # tripwire --update-policy /etc/tripwire/twpol.txt Ключевые site- и local-файлы образуются во время первого запуска, но иногда возникает необходимость в их полной замене. Парольная фраза меняется только одновременно со сменой ключей, поэтому чтобы сменить парольную фразу, надо предварительно дешифровать все файлы, сгенерировать новые ключи, затем уже зашифровать файлы с новыми ключевыми данными. При этом, если забудете парольную фразу или удалите файлы с ключами, то зашифрованные файлы, т.е. конфигурация, политики, база данных и отчеты при их шифровании будут недоступны. В этом случае лучшим решением будет переустановка всей системы. И кстати, шифровка также не помешает хакеру при наличии определенных прав просто удалить любой файл, включая саму базу данных tripwire, поэтому использование tripwire не отменяет обязательности резервного копирования. Узнать, какой ключ был использован (и был ли вообще) для шифровки файла можно при помощи: # twadmin --examine file1 file2 Убрать шифровку ( при этом запрашивается парольная фраза, сам файл остается в двоичном формате): # twadmin --remove-encryption file1 file2 Затем создание нового ключа: # twadmin --generate-keys --local-keyfile /etc/tripwire/localkey.key или # twadmin --generate-keys --site-keyfile /etc/tripwire/sitekey.key И шифрование файла: # twadmin --encrypt --local-keyfile /etc/tripwire/localkey.keyfile1 file2 или # twadmin --encrypt --site-keyfile /etc/tripwire/sitekey.key file1 file2 База данных хранится в закодированной двоичной форме, чтобы распечатать ее в виде текстового файла, можно воспользоваться дополнительной утилитой, входящей в комплект twprint. При использовании базы данных по умолчанию: # twprint --print-dbfile > db.txt Или для произвольной базы данных: # twprint --print-dbfile --dbfile otherfile.twd > db.txt Аналогично для файла с отчетом: # twprint --print-report --twrfile имя-файла-с-отчетом В комплекте пакета имеется вспомогательная программа, вычисляющая контрольную сумму методами CRC-32, MD5, HAVAL и SHA в реализации tripwire, что позволяет сравнить производительность различных методов: # /usr/sbin/siggen /var/lib/tripwire/localhost.twd
Конечно, нельзя говорить, что использование Tripwire является панацеей от всех бед, но использование данной утилиты может существенно усложнить жизнь тем, кому хочется покопаться в чужом компьютере и подать предупреждающий знак системному администратору, когда такой момент наступит. В следующий раз рассмотрим еще некоторые утилиты, позволяющие повысить защищенность системы. Формат конфигурационного файла настроек /etc/tripwire/tw.cfg (twcfg.txt) Содержит пути к вспомогательным программам, адрес электронной почты, каталоги для размещения конфигурационных файлов Tripwire. Файл структурирован как список пар имя_переменной = значение. Любая строка, начинающаяся с #, считается комментарием. При этом в файле могут быть определены переменные, к которым можно обращаться как $(имя_переменной). Две переменные предопределены и не могут быть изменены:
Обязательные переменные:
Опциональные переменные:
Формат конфигурационного файла политик /etc/tripwire/tw.pol (twpol.txt) Файл политик состоит из серии правил, определяющих то, какой реквизит для каждого объекта должен быть собран и сохранен в файле базы данных. Каждый объект в файле политик связан с маской свойства, которая описывает то, что Tripwire должен контролировать, и которые могут безопасно игнорироваться. Настраивая различные аспекты файла политик, администратор системы может через Tripwire управлять проверкой целостности системы. Основным компонентом файла являются правила (rules), в которых определяются проверяемые свойства для каждого объекта. При этом файлы и в каталогах наследуют правила родительского каталога, но при условии, что внутренние каталоги находятся на одном и том же дисковом устройстве, иначе для всех «выпавших» правила нужно определить отдельно. Как и в конфигурационном файле, возможно использование комментариев и переменных. Кроме проверяемых объектов, могут дополнительно указываться игнорируемые, что позволяет исключить «лишние» файлы. object name -> property_mask [attribute=value …]; ! object name; При задании имени объекта необходимо помнить, что пробелы в имени игнорируются, поэтому их требуется заключить в кавычки. То же касается как самой кавычки, так и всех специальных символов применительно к С++ (!{}>(),;=$#|+’ и , ,v, , , f, a, , ?, ’, "), которые можно экранировать обратной чертой, а также чисел, заданных в восьмеричной или шеснадцатеричной форме. Например: "/tex73t2" Свойства, которые будут проверяться, задаются маской свойств, при этом каждому соответствует своя буква. При отсутствии свойств объект не проверяется. Если перед свойством стоит минус «-», то данное свойство игнорируется, если плюс «+», то включается проверка данного свойства. Если знака перед буквой нет, то подразумевается предыдущий в данном правиле знак или знак плюс при отсутствии знаков. Проверяются следующие свойства ([+-]*[pinugtsldbamcrCMSH])+:
Имеет смысл использовать CMSH для файлов парами, а не все четыре сразу, так как определение всех существенно замедлит производительность. Атрибуты правил предназначены для того, чтобы изменить их поведение или обеспечить дополнительную информацию. При этом атрибуты записываются в виде списка имя = значение через запятую и могут применяться к отдельному правилу или группе правил. /usr/lib -> $(ReadOnly) ( emailto = admin@foo.com ) ; Группа правил заключается в фигурные скобки. Список атрибутов для группы правил записывается в скобках перед ней. (attribute = value) { rule1; rule2; ... } Индивидуальные атрибуты имеют больший приоритет, чем групповые, за исключением атрибута emailto – в этом случае атрибут добавляется. Пример. (emailto = admin1@foo.com, severity = 90) { /etc/dog-> +pingus (severity = 75); /etc/cat-> $(Dynamic) (emailto = admin2@foo.com); } Могут использоваться следующие атрибуты:
Tripwire поддерживает маленький набор preprocessor-подобных директив, которые группируют правила, обеспечивают условное выполнение и восполняют некоторую диагностику и действия отладки. Первичное намерение этого механизма состоит в том, чтобы поддержать разделение файла политики среди нескольких машин. Директивы имеют следующий синтаксис: @@directive [arguments] При этом сама директива не может быть получена как значение переменной, но переменные могут использоваться в качестве параметров. Обрабатываются следующие директивы:
@@ifhost machine1 || machine2 /usr/bin -> +pinug ; @@else /usr/bin -> +pinugsmC ; @@endif
Для удобства можно определять и использовать в файле политики два типа переменных. Глобальные переменные имеют видимость всюду в файле политики, в то время как локальные переменные, определенные в разделе UNIX файлы политики имеют видимость только в пределах того раздела. В случае же, где глобальная и локальная переменные имеют то же самое название, локальная переменная будет иметь приоритет в ее разделе, временно маскируя глобальную переменную. Значение переменной присваивается командой имя_переменной = значение, подстановка значения осуществляется конструкцией $(variable). Первоначально имеются следующие предопределенные переменные:
Приложение Уровни отчетов Уровень 0 Отчет одной строкой. Появляется всегда в строке Subject отчета, высылаемого по e-mail. TWReport имя-хоста дата-и-время V:число-нарушений S:макс-уровень A:добавлено R:удалено C:изменено
Уровень 1 Список имен измененных файлов в виде, легко разбираемом программой автоматического восстановления или подобной. Каждая строка состоит из ключевого слова (Added, Modified), двоеточия и имени файла.
Уровень 2 Суммарный отчет, включает список нарушений с указанием имен правил, список добавленных, измененных и удаленных файлов. Секция Object Summary содержит подробный список файлов, которых затронули изменения. Уровень 3 Суммарный отчет, включает список нарушений с указанием имен правил, список добавленных и удаленных файлов, ожидаемые и реальные свойства измененных файлов. Также выводит дополнительные подробности. Уровень 4 Суммарный отчет, выводящий максимальное количество деталей, список нарушений с указанием имен правил, список добавленных, измененных и удаленных файлов, детальный отчет по каждому добавленному файлу (все свойства), каждому измененному файлу (все проверяемые, ожидаемые и реальные свойства), каждому удаленному файлу (все проверяемые и ожидаемые свойства). При этом отличающиеся параметры помечаются звездочкой в начале строки. |
СЕРГЕЙ ЯРЕМЧУК, Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
