Раздел: Документация
0 ... 12 13 14 15 16 17 18 ... 169 держащимися в файле /usr/lib/crontab, но команды из этих полей выполняются с ID пользователя с именем, соответствующим имени этого файла. Формат полей аналогичен. Обычно с помощью утилиты запускаются программы, проверяющие целостность системы: проверяются длина и/или контрольные суммы файлов, наличие в системе пользователей с UID - 0, и т. д. О всех подозрительных явлениях пишется письмо rooty. При модификации файлов сгоп пишется протокол в файл /usr/adm/cronlog. В некоторых системах, например, во FreeBSD существуют командные файлы /etc/daily, /etc/weekly и /etc/monthly, /etc/daily запускается сгопом ежедневно в 2:00 am и сравнивает информацию, выдаваемую по команде Is -1аТ для всех suidHbix файлов, с информацией предыдущего дня. Иными словами /etc/daily сравнивает /var/log/setuid. today и yesterday. О всех изменениях посылаются письма администратору. Так что, если вы изменили или добавили какой-нибудь файл, не забудьте сделать соответствующие изменения в этих двух файлах. Некоторые способы защиты от несанкционированного доступа в среду Linux Среда Linux легко доступна хакерам, поскольку конструировалась хакерами и для хакеров. В году студент Университета Хельсинки по имени Linus Torvalds начал разрабатывать бесплатное Unix ядро для 386 машин с использованием инструментария Фонда бесплатного программного обеспечения. Его изначальный, быстрый успех привлек много Internet-хакеров, которые помогали ему разрабатывать Linux со всеми свойствами Unixa и полностью бесплатный с распространяемыми исходными текстами. Linux был не без конкурентов. В 1991 году, одновременно с ранними экспериментами Линуса Торвальдса, William и Lynne Jolitz экспериментально перенесли исходные тексты BSD Unix на 386. Большинство обозревателей, сравнивающих BSD технологию с ранними сырыми усилиями Линуса, ожидали, что перенос BSD сделает его главным бесплатным Unix-ом на PC. Наиболее важная особенность Linux, однако, была не техническая, а социологическая. До разработки Linux каждый полагал, что лю- 47 бое программное обеспечение как комплекс, как операционная система должны быть разработаны тщательно скоординированными и относительно маленькими группами сильно связанных людей. Эта модель была и все еще остается типичной и для коммерческого программного обеспечения, и для больших соборов свободно распространяемых программ, построенных Фондом Бесплатного Программного Обеспечения в 1980-ых, и для FreeBSD/NetBSD/OpenBSD проектов, которые происходили от оригинального 386BSD, перенесенного JolitzaMH. Linux развивался совершенно другим способом. С самого начала он был довольно небрежно перемолот огромным числом добровольцев, скоординированных только через Internet. Качество поддерживалось не по твердым стандартам или автократии, а наивно простой стратегией еженедельного выпуска и получения обратной связи от сотен пользователей в пределах нескольких дней, созданием своего рода быстрой селекции Дарвина на мутациях, представленных разработчиками. Ко всеобщему изумлению, это работало весьма хорошо. К концу 1993 года Linux мог конкурировать по стабильности и надежности со многими коммерческимии оказал гостепри- имство значительно большему количеству программного обеспечения. Это даже начало привлекать перенос коммерческих программных приложений. Косвенным результатом этих разработок было уничтожение большинства малых коммерческих продавцов Unix-a — без разработчиков и хакеров они загнулись. Один из немногих выживших BSDI (Berkeley System Design Incorporated) процветал, предлагая полные исходные тексты с UnixoM, базирующимся на BSD, и культивируя закрытые связи с общиной хакеров. Приведенные ниже примеры взлома сетей ориентированы на Linux, но могут быть с успехом применены и к большинству других Unix-подобных операционных систем. Учтите, что нет гарантированного способа точно отследить каждый шаг злоумышленника, однако данная глава поможет вам начать движение в этом направлении. Защита регистрационных журналов Мы здесь не сможем охватить вопросы систем обнаружения атак (Intrusion Detection, IDS); на эту тему имеется немало прекрасных публикаций. Если вы заинтересовались этой темой, то я рекомендую вам обратить внимание на такие приложения, как Network Flight Recorder или snort. 48 Мы сконцентрируемся на процессе аналитического исследования, а именно, каким образом выяснить, что делает враг путем изучения регистрационных журналов системы. Вы будете удивлены, сколько интересной информации можно в них найти! Однако прежде, чем мы начнем говорить об их изучении, нам надо обсудить их защищенность. Эти журналы не будут представлять никакой ценности, если не обеспечить их целостность. Первое, что делает злоумышленник, проникнув в систему, — это изменение регистрационных журналов. Имеется целый ряд средств (rootkits), удаляющих из журналов все следы присутствия (например, cloack) или полностью подменяющих подсистему регистрации (в частности,sys- logd). Итак, первый шаг при рассмотрении ваших журналов — это их защита. Это означает, что вам придется использовать удаленный sys-log-сервер. Независимо от того, насколько защищена ваша система, вы не можете доверять регистрационным журналам со скомпрометированного компьютера. Даже если черная шляпа не придумает ничего лучше, чем выполнить командуочистив таким образом жесткий диск, это уже сделает восстановление регистрационных журналов затруднительным. Чтобы защититься от этой ситуации, вам придется настроить ваши системы таким образом, чтобы они регистрировали трафик как локально, так и на удаленном log-сервере. Я рекомендую сделать такой сервер на базе выделенной машины, единственной задачей которой будет сбор журналов с других систем. Если величина материальных затрат является определяющим фактором, вы можете построить log-сервер под управлениемЭта машина должна быть хорошо защи- щена, все сервисы на ней должны быть выключены, а доступ разрешен только с консоли (см. «Armoring Linux» для примера). Также убедитесь, что порт DP блокирован или закрыт межсетевым экраном (firewall) со стороны Internet. Это защитит ваш log-сервер от навязывания ложной регистрационной информации снаружи. Для тех, кто любит перестраховываться, могу порекомендовать свой любимый трюк, заключающийся в перекомпиляции syslogd таким образом, чтобы он читал альтернативный файл конфигурации, например, /var/tmp/.conf. В этом случае черная шляпа не будет знать, где находится настоящий конфигурационный файл. Чтобы достичь этого, просто замените в исходном тексте syslogd строку 49 0 ... 12 13 14 15 16 17 18 ... 169
|
