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

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

 

12.3.1. lsat

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

Программа lsat поставляется в исходных кодах, и найти ее можно по адресу http://usat.sourceforge.net/. На момент написания этой книги была доступна версия 0.9.2. Скачайте архив в свою домашнюю директорию, и давайте рассмотрим, как установить и использовать программу. На сайте доступны tgz- и zip-версия. Я рекомендую воспользоваться первой, потому что это родной архив для Linux и проще в использовании.

Для установки выполните следующие команды:

tar xzvf lsat-0.9.2.tgz

./lsat-0.9.2.tgz/configure

./lsat-0.9.2.tgz/make

Первая директива распаковывает архив lsat-0.9.2.tgz. Имя файла может отличаться, если у вас другая версия программы. Вторая команда запускает конфигурирование, а третья — собирает проект из исходных кодов в один исполняемый файл.

Для запуска программы используйте следующую команду:

./lsat-0.9.2.tgz/lsat

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

□ -o имя файла — отчет записывать в указанный файл. По умолчанию отчет попадает в lsat.out;

□ -v — выдавать подробный отчет;

□ -s — не выдавать никаких сообщений на экран. Это удобно при выполнении команды через cron;

□ -r — выполнять проверку контрольных сумм (это делается с помощью RPM). Это позволяет выявить незаконно измененные программы.

Лучше всего lsat будет работать на Red Hat-подобных системах, потому что в нее встроена возможность работы с RPM-пакетами, которые являются отличительной особенностью дистрибутива Red Hat Linux и его клонов.

Во время проверки вы увидите примерно следующий текст на экране:

Starting LSAT...

Getting system information...

Running modules...

Running checkpkgs module...

...

...

Running checkx module...

Running checkftp module...

Finished.

Check lsat.out for details.

Don't, forget to check your umask or file perms

when modifying files on the system.

Пока слова о безопасности отсутствуют. Только информация о том, что сканировалось. Все самое интересное после тестирования можно найти в файле ./lsat-0.9.2.tgz/lsat.out. Я прогнал эту программу на системе сразу после установки и получил документ размером 190 Кбайт. Таким образом, есть над чем подумать и что изучать в вашей системе.

В выходном файле вы найдете множество советов. Так, в самом начале можно увидеть рекомендации по пакетам, которые нужно удалить:

****************************************

Please consider removing these packages.

sendmail-8.11.6-15.asp

portmap-4.0-41

bind-utils-9.2.1-1.asp

nfs-utils-0.3.3-5

pidentd-3.0.14-5

sendmail-devel-8.11.6-15.asp

sendmail-cf-8.11.6-15.asp

ypbind-1.10-7

ypbind-1.10-7

В самом деле, некоторые пакеты можно отнести к разряду не очень надежных. Например, в программе Sendmail регулярно находят ошибки, поэтому lsat предлагает его подчистить.

В выходном файле мне очень понравилась надпись:

default init level is not set to 5. Good.

(уровень загрузки по умолчанию не равен 5. Хорошо.)

Мой уровень загрузки равен 3 (текстовый режим) и программа сообщает, что это хорошо. Разработчик lstat посчитал, что загрузка в графическом режиме хуже для безопасности. Действительно, это лишние программы и дополнительные проблемы. Текстовый режим не требует столько ресурсов, работает меньше утилит, а значит, он быстрее и безопаснее.

Если немного опуститься ниже, то вы увидите список всех файлов в системе с установленными битами SUID и SGID. При использовании программы lsat нет смысла самостоятельно заниматься поисками потенциально опасных программ.

Еще немного ниже идет список общедоступных файлов:

****************************************

This is a list of world writable files

/var/lib/texmf/ls-R

/var/www/html/cache/archive/index.html

/var/www/html/cache/categories/category.cgi

/var/www/html/cache/categories/index.html

/var/www/html/cache/download/download-2-1.cgi

/var/www/html/cache/download/download-3-1.cgi

/var/www/html/cache/download/download-4-1.cgi

Это те файлы, которые имеют право изменять любые пользователи системы, даже с минимальными правами.

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

Отчеты удобны и легко читаются, но в самом конце появляется ложка дегтя. Пусть она и небольшая, но она есть. Программа показывает изменения в файловой системе с момента последнего запуска. Вот тут разобраться с чем-либо очень сложно. Информация выводится как угодно, а ведь удобнее было разделить модификации по степени опасности. Например, удаленный или добавленный в разделе /tmp файл не так важен, потому что там изменения происходят тоннами каждые пять минут. А вот все, что касается раздела /etc, намного опаснее, и эти записи нужно выделять.

 

12.3.2. bastille

Проект bastille (http://bastille-linux.sourceforge.net/) существует уже давно и создан специалистами по безопасности Linux. Разработчики собирались написать свою версию ОС, которая будет более безопасной, но, видимо, не рассчитали свои силы. Глядя на bastille, так и хочется сказать: "Жаль!!!".

Программа проверяет систему и выдает отчет, из которого вы можете узнать о найденных слабостях в ОС, и если пожелаете, то bastille автоматически примет необходимые меры по устранению уязвимости.

Работа программы настолько проста и удобна, что я даже не буду ее описывать. В отличие от подобных средств, bastille может работать не только в текстовом, но и в графическом режиме. Для установки программы можно воспользоваться RPM-архивом или скомпилировать файлы из исходного кода.

 

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

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

Средства автоматического выявления атак достаточно хороши, но не всегда приемлемы. Например, если ваш сервер популярен, то количество сканирований в день будет довольно большим. Я думаю, что такие узлы, как www.yahoo.com или www.microsoft.com, сканируют тысячи, а то и миллионы раз в день, и на каждую попытку обращать внимание бесполезно. А самое главное, автоматическое выявление атак требует ресурсы, а иногда и немалые. Если попытаться протоколировать каждое сканирование, то злоумышленник может сделать такие пакеты, которые будут имитировать атаки, и тогда вся вычислительная мощь сервера уйдет на выявление этих наскоков. Получится классический отказ от обслуживания (DoS), потому что сервер уже не будет обрабатывать запросы клиентов.

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

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

 

12.4.1. Klaxon

Самой простой и эффективной является утилита Klaxon (http://www.eng.auburn.edu/users/doug/second.html). Она следит за неиспользуемыми системой портами и при обращении на них пытается определить всю возможную информацию о сканирующем IP-адресе и сохранить ее в журнале.

Программа устанавливается достаточно просто. В конфигурационный файл /etc/inetd.conf нужно добавить строки, как показано в примере:

#

# Local testing counterintelligence

#

rexec  stream tcp nowait root /etc/local/klaxon klaxon rexec

link   stream tcp nowait root /etc/local/klaxon klaxon link

supdup stream tcp nowait root /etc/local/klaxon klaxon supdup

tftp   dgram  udp wait   root /etc/local/klaxon klaxon tftp

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

Такой метод хорош тем, что, например, сервис rexec (удаленное выполнение команд) не нужен пользователям, и его очень часто ищут хакеры для проникновения в систему. Если с определенного адреса была попытка (пусть и неудачная) обратиться к rexec, можно взять на заметку это событие и этот IP и уделять ему больше внимания.

Я рекомендую установить klaxon в системе не более чем на 2–3 сервиса, потому что слишком большое количество портов вызовет подозрение у взломщика. К тому же, если klaxon возьмет на обслуживание более 5 портов, то многократное сканирование может отнять лишние ресурсы системы. Это создаст предпосылки для проведения успешной атаки отказа от обслуживания.

 

12.4.2. PortSentry

Раньше эта программа принадлежала компании Psionic, но сейчас ссылка www.psionic.com ведет на один из разделов компании Cisco, и утилиты там уже нет. Но в Интернете она еще осталась, и полный исходный код можно взять с сайта http://sourceforge.net/projects/sentrytools.

Так как программа поставляется в исходных кодах, то для ее установки требуется распаковка архива и компиляция. Это уже не должно у вас вызывать проблем.

Для разархивирования выполняем команду:

tar xzvf portsentry-1.2.tar.gz

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

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

cd portsentry_beta

Теперь поговорим о компиляции. Программа PortSentry написана универсально и может работать в разных Unix-подобных системах, и помимо Linux это может быть Solaris, FreeBSD, OpenBSD и т.д. При компиляции вы должны явно указать, какая ОС у вас установлена:

make linux

Теперь собственно установка. По умолчанию файлы программы копируются в директорию /usr/local/psionic, но этим можно управлять, если в файле makefile поменять параметр INSTALLDIR. Если все устраивает, то выполняем команду:

make install

Затем нужно установить описанным для PortSentry способом программу Logcheck, поэтому приведу только команды:

tar xzvf logcheck-1.1.1.tar.gz

cd logcheck-1.1.1

make linux

make install

Эта программа по умолчанию устанавливается в директорию /usr/local/etc. Каталог также можно изменить, отредактировав параметр INSTALLDIR в файле makefile.

Все настройки программы PortSentry находятся в файле /usr/local/psionic/portsentry/prtsentry.conf. По умолчанию все закомментировано, и вам необходимо только открыть нужные строки.

Например, вы хотите, чтобы программа следила за определенными портами. На этот случай в конфигурационном файле подготовлены закомментированные записи для разных типов серверов. Выберите нижний и уберите в начале строки знак "#". Тем самым вы укажете порты для наблюдения:

TCP_PORTS="1,11,15,79,111,119,143,540,635,1080,1524,2000,5742,6667"

UDP_PORTS="1,7,9,69,161,162,513,635,640,641,700,32770,32771,32772"

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

Мы рассматриваем Linux, а в нем, чаще всего, используют Firewall ipchains. Для него нужна запись:

KILL_ROUTE="/sbin/ipchains -I input -s $TARGET$ -j DENY -l"

Убедитесь только, что программа сетевого экрана установлена по указанному пути (/sbin/ipchains). Для этого можно выполнить команду поиска программы:

which ipchains

Если в вашей системе применяется iptables, то нужно использовать строку:

KILL_ROUTE="/usr/local/bin/iptables -I INPUT -s $TARGET$ -j DROP"

Я считаю возможность выявления атаки и автоматического конфигурирования сетевого экрана очень мощной. В то же время, любая программа может ошибиться и запретить доступ не тому, кому надо. Например, взломщик может имитировать атаку от имени другого пользователя (скажем, босса), и тогда PortSentry запретит шефу доступ к ресурсам сервера. А это уже не есть хорошо.

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

Для запуска программы мониторинга выполните команды:

/usr/local/psionic/portsentry/portsentry -atcp

/usr/local/psionic/portsentry/portsentry -audp

Первая команда запускает мониторинг TCP-портов, а вторая — заставит программу наблюдать за UDP-портами. Вся активность будет сохраняться в журнале, который можно проверить с помощью установленной нами ранее программы Logcheck. Я рекомендую поместить эту программу в задания, чтобы она выполнялась через определенные интервалы времени (не менее 15 минут) и сообщала администратору о событиях в системе.

Для начала желательно сконфигурировать программу Logcheck. Для этого откройте файл /usr/local/etc/logcheck.sh и добавьте в него следующую строку (если ее нет):

"mailto:[email protected]"

Здесь [email protected] — это ваш E-mail-адрес, на который нужно отправлять электронные сообщения с информацией о сохраненных программой PortSentry в журнале записях. Теперь остается только сделать так, чтобы сценарий /usr/local/etc/logcheck.sh выполнялся через определенные промежутки времени. Для этого подойдет программа crontab.

Для тестирования программы PortSentry я сконфигурировал ее, как показано выше, и запустил прослушивание портов. Сканер CyD NET Utils (http://www.cydsoft.com) показал только первые два открытых канала. Все остальные оказались для программы закрыты, хотя реально их больше двух. Я сел за клавиатуру своего Linux-сервера и выполнил команду cat /etc/hosts.deny, чтобы увидеть файл /etc/hosts.deny, который содержит IP-адреса всех компьютеров, которым запрещено подключаться к серверу.

На экране появилось содержимое этого файла, и последней строкой был IP-адрес компьютера, с которого я производил сканирование:

ALL: 192.168.77.10

Программа PortSentry среагировала достаточно быстро и эффективно, прописав в файл /etc/hosts.deny запрет использования любого сервиса с адреса 192.168.77.10. Больше я уже ничего сделать не мог. Единственный способ снова получить доступ — удаление строки из файла /etc/hosts.deny, показанной выше.

Нужно заметить, что некоторые порты могут использоваться достаточно часто, и программа будет думать, что это попытки взлома. К ним относятся ident (113) и NetBIOS-порты (139), и их лучше всего исключить из наблюдения. Для этого в конфигурационном файле /usr/local/psionic/portsentry/prtsentry.conf найдите строки ADVANCED_EXCLUDE_TCP (для TCP-портов) и ADVANCED_EXCLUDE_UDP (для UDP-портов) и добавьте нужные каналы в список. По умолчанию в программе исключены следующие порты:

ADVANCED_EXCLUDE_TCP="113,139"

ADVANCED_EXCLUDE_UDP="520,138,137,67"

Как видите, 113 и 139 порты по умолчанию уже исключаются из мониторинга.

 

12.4.3. LIDS

Пакет LIDS (Linux Intrusion Detection/Defence System, определение вторжения в Linux и система безопасности). Несмотря на то, что я не очень люблю использовать патчи ядра, этот заслуживает вашего внимания, потому что обладает большими возможностями и реально позволяет повысить безопасность системы.

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

Функция определения попыток сканирования — это самая малость, что может делать этот пакет. Кроме того, LIDS позволяет ограничить доступ к файлам на уровне программ, а не пользователей, тем самым расширяются возможности по управлению правами доступа и увеличивается общая безопасность. Например, командам ls, cat и текстовым редакторам можно категорически запретить работу с каталогом /etc. Таким образом, мы усложняем хакеру задачу по просмотру файла паролей /etc/passwd.

Установка LIDS не из простых, потому что требуется инсталляция патча на исходные коды и перекомпиляция ядра Linux. И вот тут на первый план выходит неудобство патча — при его обновлении нет гарантии, что он будет работать верно или не нарушит функционирование ядра. Исходные коды могут быть испорчены, и компиляция станет невозможной. При выходе новой версии ядра приходится на тестовой машине проверять его работу и устанавливать все на свой страх и риск. А если не обновлять ядро, то нет уверенности, что в дальнейшем оно будет удовлетворять новым требованиям безопасности.

Более подробную информацию по работе пакета LIDS вы можете узнать на официальном сайте www.lids.org.

 

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

 

12.5.1. Основные команды

Информация о текущих пользователях системы сохраняется в файле /var/run/utmp. Если попытаться посмотреть его содержимое, например, командой cat, то ничего хорошего нашему взору не откроется. Этот журнал хранит данные не в текстовом, а бинарном виде, и получение информации возможно только с помощью специализированных программ (команд).

who

Команда who позволяет узнать, кто сейчас зарегистрирован в системе и сколько времени в ней находится. Информация достается из файла /var/run/utmp. Введите эту команду, и на экране появится список примерно следующего вида:

robert tty1 Dec 8 10:15

root tty2 Dec 8 11:07

Из этого списка становится ясно, что пользователь robert работает за первым терминалом (tty1) и вошел в систему 8 декабря в 10 часов 15 минут.

Большинство хакеров при входе в систему выполняют эту команду, чтобы выяснить, есть ли сейчас в системе администратор. Если пользователь root присутствует, то начинающие хакеры стараются уйти, т.к. опасаются, что их знаний не хватит, чтобы остаться незамеченными.

Это еще одна причина, по которой администратор не должен входить в систему под учетной записью root. Лучше всего работать как простой пользователь, а когда не хватает прав, то переключаться на привилегированного. На такой случай я создал учетную запись, для которой установил UID, равный нулю. Она позволяет получить доступ ко всей системе, и при этом имеет имя отличное от root, и не вызовет подозрений, когда я буду работать. Так что в моем случае никогда нельзя увидеть пользователя root.

users

Эта команда позволяет вытащить из журнала /var/run/utmp список всех пользователей, которые сейчас зарегистрированы в системе.

В журнале /var/run/utmp информация хранится временно, только на момент присутствия пользователя. Когда он выходит из системы, соответствующая запись удаляется. После этого выяснить, кто и когда работал, можно только по журналу /var/log/wtmp. Это также бинарный файл, поэтому его содержимое можно увидеть с помощью специализированных программ.

last

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

last robert

Выполнив команду, вы увидите на экране примерно следующий список:

robert tty1 Thu Dec 2 12:17 - 12:50 (00:33)

По этой записи можно понять, что robert находился за терминалом (tty1), зашел в систему 2 декабря на 33 минуты (с 12:17 до 12:50). Если пользователь работал не локально, а через сеть, то будет отображена информация о хосте, с которого входили в систему.

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

last -n 5 robert

lastlog

Если выполнить команду lastlog, то она выведет на экран перечень всех пользователей с датами их последнего подключения к системе. Пример списка можно увидеть в листинге 12.1.

Листинг 12.1. Результат выполнения команды lastlog

Username Port     From          Latest

root     ftpd2022 192.168.77.10 Mon Feb 21 12:05:06 +0300 2005

bin                             **Never logged in**

daemon                          **Never logged in**

adm                             **Never logged in**

lp                              **Never logged in**

sync                            **Never logged in**

shutdown                        **Never logged in**

halt                            **Never logged in**

mail                            **Never logged in**

news                            **Never logged in**

uucp                            **Never logged in**

operator                        **Never logged in**

games                           **Never logged in**

gopher                          **Never logged in**

ftp                             **Never logged in**

nobody                          **Never logged in**

vcsa                            **Never logged in**

mailnull                        **Never logged in**

rpm                             **Never logged in**

xfs                             **Never logged in**

apache                          **Never logged in**

ntp                             **Never logged in**

rpc                             **Never logged in**

gdm                             **Never logged in**

rpcuser                         **Never logged in**

nscd                            **Never logged in**

ident                           **Never logged in**

radvd                           **Never logged in**

squid                           **Never logged in**

mysql                           **Never logged in**

flenov   ftpd2022 192.168.77.10 Mon Feb 21 12:05:06 +0300 2005

named                           **Never logged in**

robert   tty1                   Mon Feb 21 12:10:47 +0300 2005

Список состоит из четырех колонок:

□ имя пользователя из файла /etc/passwd;

□ порт или терминал, на который происходило подключение;

□ адрес компьютера, если вход был по сети;

□ время входа.

С помощью lastlog удобно контролировать системные записи. У них дата последнего входа должна быть **Never logged in**, потому что под ними нельзя войти в систему (в качестве командной оболочки установлены /bin/false, /dev/null, /sbin/nologin и др.). Если вы заметили, что кто-либо проник в систему через одну из этих учетных записей, то это значит, что хакер использует ее, изменив настройки.

Простая замена командной оболочки в файле /etc/passwd может открыть хакеру потайную дверь, и администратор не заметит этой трансформации. Но после выполнения команды lastlog все неявное становится явным.

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

lsof

С помощью этой команды можно определить, какие файлы и какими пользователями открыты в данный момент. Результат выполнения директивы приведен в листинге 12.2.

Листинг 12.2. Результат выполнения команды lsof

COMMAND PID USER FD  TYPE DEVICE SIZE   NODE NAME

init     1  root cwd DIR  3,2    4096      2 /

init     1  root rtd DIR  3,2    4096      2 /

init     1  root txt REG  3,2   26920 635256 /sbin/init

init     1  root mem REG  3,2   89547 553656 /lib/ld-2.2.5.so

init     1  root 10u FIFO 3,2         195499 /dev/initctl

keventd  2  root cwd DIR  3,2    4096      2 /

keventd  2  root rtd DIR  3,2    4096      2 /

kapmd    3  root 10u FIFO 3,2         195499 /dev/initctl

Это далеко не полный результат. Даже если в данный момент вы один работаете с системой, количество открытых файлов может исчисляться парой десятков, и число их заметно растет, если в системе несколько пользователей, ведь один файл может открываться несколько раз каждым из них. Это касается в основном системных конфигурационных файлов.

 

12.5.2. Системные текстовые журналы

Представленные в этом разделе журналы — это текстовые файлы. Их можно без проблем просматривать такими командами, как cat, или любыми текстовыми редакторами.

В файле /var/log/messages находится основная информация о заходах пользователей, о неверных авторизациях, остановках и запусках сервисов и многое другое. В один документ все подобные события поместиться не могут, иначе он будет нечитаемым, поэтому в папке /var/log/ могут находиться файлы с именами messages.X, где X — это число.

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

Рис. 12.1. Снимок экрана с открытым файлом /var/log/messages

Следующий журнал расположен в файле /var/log/secure. Что в нем такого особенного? Это самый основной журнал, который нужно проверять максимально часто, и каждой записи следует уделять особое внимание. В этом файле отображается, под каким именем и с какого адреса пользователь вошел в систему. Например, на сервис FTP может подключаться главный бухгалтер. Если вы увидели, что он пользуется сервисом, но при этом журнал показывает чужой IP-адрес, то это может стать поводом для беспокойства.

В этом же файле отображается информация а внесении изменений в список пользователей или групп. Злоумышленники очень редко используют запись root для своих злобных целей и заводят какую-нибудь более незаметную, с нулевым идентификатором. Если это сделано не руками, а с помощью команды Linux, то вы в журнале /var/log/secure увидите подозрительные изменения.

Хакеры, конечно же, знают о таких уловках, поэтому корректируют список вручную, ведь это не так уж и сложно — добавить по одной записи в файлы /etc/passwd и /etc/shadow. Но даже в этом случае вы почувствуете неладное, когда увидите запись о том, что в систему вошел пользователь, которого вы не создавали.

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

Журнал почтового сервера Sendmail находится в файле /var/log/maillog. В данном файле можно будет увидеть строки примерно следующего вида:

Jan 16 13:01:01 FlenovM sendmail[1571]: j0GA11S01571: from=root, size=151, class=0, nrcpts=1,

msgid=<[email protected]>, relay=root@localhost

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

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

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

 

12.5.3. Журнал FTP-сервера

Войдя в систему, взломщики нередко закачивают на сервер собственные программы для повышения своих прав или для открытия потайных дверей. Для закачки можно использовать FTP-протокол. Кто подключался к серверу можно узнать из файла /var/log/secure. А вот что закачивали — подскажет /var/log/xferlog. О журнале FTP-сервера мы уже немного говорили в разд. 10.3. Теперь познакомимся с ним поближе.

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

Посмотрим на пример содержимого файла /var/log/xferlog:

Sun Jan 16 13:21:28 2005 1 192.168.77.10 46668 /home/flenov/sendmail.cf b _ o r flenov ftp 0 * c

Из данной строки видно, что 16 января в 13:21 пользователь с адреса 192.168.77.10 скачал файл /home/flenov/sendmail.cf.

Протокол FTP является наиболее опасным, потому что через него злоумышленник может скачать секретные данные (например, файл с паролями) или положить на сервер свою программу (в частности, rootkit или трояна). Необходимо научиться понимать каждую запись, чтобы знать, что происходит с файлами в системе. Давайте рассмотрим каждый параметр в журнале:

□ полная дата, которая состоит из дня недели, месяца, числа, времени и года;

□ продолжительность сеанса или время, потраченное на скачивание/закачивание файла;

□ имя или IP-адрес удаленного хоста;

□ размер файла в байтах;

□ полный путь к файлу, который был скачен или закачен;

□ тип передачи — буква a (символьная) или b (бинарная);

□ символ, определяющий специальные действия над файлом:

 • C — сжат;

 • U — разархивирован;

 • T — обработан программой tar;

 • _ — не было никаких действий;

□ символ, определяющий направление передачи: о (скачивание с сервера) или i (закачивание на сервер);

□ символ, определяющий тип пользователя: a (анонимный), g (гость) или r (действительный);

□ локальное имя пользователя. Для анонимных пользователей здесь можно увидеть номер ID;

□ имя сервиса, обычно это слово ftp;

□ способ аутентификации. Здесь можно увидеть 0, если определение подлинности отсутствовало, или 1 для идентификации по RFC 931;

□ идентификатор пользователя. Если он не определен, то можно увидеть звездочку;

□ символ, определяющий состояние передачи: с (прошла успешно) или i (была прервана).

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

 

12.5.4. Журнал прокси-сервера squid

Основным журналом прокси-сервера squid является /var/log/squid/access.log. Это текстовый файл, в котором каждая строка состоит из следующих полей:

□ время начала соединения или события;

□ продолжительность сессии;

□ IP-адрес клиента;

□ результат обработки запроса. Здесь может быть одно из следующих значений:

 • TCP_HIT — в кэше найдена нужная копия;

 • TCP_NEGATIVE_HIT — объект кэширован негативно, получена ошибка при его запросе;

 • TCP_MISS — объект не найден в кэше;

 • TCP_DENIED — отказ в обслуживании запроса;

 • TCP_EXPIRED — объект найден, но устарел;

 • TCP_CLIENT_REFRESH — запрошено принудительное обновление;

 • TCP_REFRESH_HIT — при попытке обновления сервер сообщил, что объект не изменился;

 • TCP_REFRESH_MISS — после попытки обновления сервер вернул новую версию объекта;

 • TCP_REFRESH_HIT — после обновления выяснилось, что объект в кэше свежий;

 • TCP_REF_FAIL_HIT — объект из кэша устарел, а новую версию получить не удалось;

 • TCP_SWAPFAIL — объект должен находиться в кэше, но он не найден;

□ количество байт, полученных клиентом;

□ метод запроса — GET, POST, HEAD или ICP_QUERY;

□  URL-адрес запрашиваемого объекта;

□ поле ident (знак "-", если недоступно);

□ результат запроса к другим кэшам:

 • PARENT_HIT — объект найден;

 • PARENT_UDP_HIT_OBJECT — объект найден и возвращен в UDP-запросе;

 • PARENT — объект запрошен с оригинального сервера;

□ тип содержимого MIME.

Когда в гл. 9 мы говорили о squid-прокси-сервере, то упоминали и о других журналах, например, cache.log и useragent.log.

 

12.5.5. Журнал Web-сервера

Сервер Apache хранит свои журналы в файлах access.log и error.log, которые расположены в директории /var/log/httpd. Эти журналы позволяют узнать об активности и доступе пользователей.

С другой стороны, журналы текстовые и легко читаемые. Любой хакер может просмотреть их. А т.к. в журнале сохраняются пароли, с которыми пользователи получили доступ к серверу, то хакер легко их может вычислить.

Отказаться совсем от ведения журнала нельзя. Но необходимо сделать все возможное, чтобы он не был доступен злоумышленнику. Как минимум, я всегда изменяю расположение журнала по умолчанию. По моим наблюдениям редко кто смотрит файл httpd.conf, а лезут сразу в каталоги по умолчанию. Если журналов нет, то хакер думает, что они отключены.

Итак, в директории /var/log/httpd создайте пустые файлы access_log, access_log.1, access_log.2, access_log.3, access_log.4, error_log, error_log.1, error_log.2, error_log.3 и error_log.4. Для большей правдоподобности в них можно поместить копию реальных данных, только убедитесь, что там нет важной информации. Правда по дате изменения и по строкам внутри файла злоумышленник легко увидит, что данные старые, но не догадается, что эта информация только для отвода глаз. Главное, чтобы даты изменения файла и формирования записей в нем совпадали.

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

После этого измените директивы ErrorLog и CustomLog в файле конфигурации Apache-сервера httpd.conf, указав другую директорию для хранения журналов. Вот такой простой метод позволяет затуманить мозги большинству взломщиков.

 

12.5.6. Кто пишет?

Записью в журналы, находящиеся в директории /var/log, занимаются демоны syslogd и klogd, но в программе setup при настройке автоматически загружаемых сервисов вы увидите только первый. Настройки автозапуска syslogd влияют и на загрузку klogd. Если вы используете изолированную систему или просто не нуждаетесь в протоколировании событий, происходящих в системе, то можете отключить эти сервисы, чтобы они не расходовали процессорное время. Для сервера я не рекомендую этого делать. Если сейчас вы еще не почувствовали необходимость использования журналов, то после первой проблемы или взлома системы увидите все их преимущества.

Программа syslogd сохраняет в файлах журналов всю информацию о сообщениях системы. Программа klogd предназначена для сохранения сообщений ядра. Настройки журналов находятся в файле /etc/syslog.conf. Пример содержимого файла можно увидеть в листинге 12.3.

Листинг 12.3. Файл конфигурации программы syslogd

# Log all kernel messages to the console.

# Logging much else clutters up the screen.

# Выводить все сообщения ядра на экран

# Вывод других параметров создаст на экране беспорядок

#kern.* /dev/console

# Log anything (except mail) of level info or higher.

# Don't log private authentication messages!

# Протоколировать в указанный файл все сообщения

# уровня info и выше

# Исключения составляют письма, сообщения аутентификации и демона cron

*.info;mail.none;authpriv.none;cron.none /var/log/messages

# The authpriv file has restricted access.

# Файл authpriv содержит ограниченный доступ

authpriv.* /var/log/secure

# Log all the mail messages in one place.

# Сохранять все события почтовой системы в указанное место

mail.* /var/log/maillog

# Log cron stuff

# Протоколировать сообщения cron

cron.* /var/log/cron

# Everybody gets emergency messages

# Все получают критические сообщения

*.emerg

# Save news errors of level crit and higher in a special file.

# Сохранять сообщения новостей уровня crit (критический)

# и выше в специальный файл

uucp,news.crit /var/log/spooler

# Save boot messages also to boot.log

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

lосаl7.* /var/log/boot.log

Назначение директив легко можно проследить по их комментарию. Все они имеют вид:

название.уровень

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

□ kern — от ядра;

□ auth — о нарушении безопасности и авторизации;

□ authprith — об использовании привилегированного доступа;

□ mail — от почтовых программ;

□ cron — от планировщиков задач cron и at;

□ daemon — генерируются сервисами;

□ user — от пользовательских программ;

□ uucp — UUCP-сообщения (Unix To Unix Copy, копирование с Unix на Unix). В настоящее время практически не используется;

□ news — из новостей;

□ lpr — поступает с принтеров.

Уровень может быть один из следующих:

□ * — протоколировать все сообщения системы;

□ debug — отладочная информация;

□ info — информационные сообщения;

□ notice — уведомления;

□ warn — предупреждения;

□ err — ошибки;

□ crit — критические сообщения;

□ alert — требуется немедленное вмешательство;

□ emerg — авария, дальнейшая работа невозможна.

В журнал попадают сообщения указанного уровня и выше. Например, установка значения err определяет, что в журнал будут попадать сообщения уровней err, crit и emerg.

Чем больше ошибок вы сохраняете, тем выше нагрузка на жесткий диск, да и расход ресурсов увеличивается. Для большей эффективности функционирования системы раздел /var, на котором хранятся журналы, лучше всего перенести на отдельный винчестер. Таким образом, запись в журналы и работа ОС сможет происходить параллельно. Но вы должны быть уверенными, что раздел /var содержит достаточное количество дискового пространства.

Я уже говорил, что в своих системах убираю журналы из расположения по умолчанию, что усложняет хакеру жизнь. Но этого недостаточно. Опытный взломщик просмотрит конфигурационный файл /etc/syslog.conf и найдет новое расположение журналов.

Но мы можем поступить еще умнее, и для этого достаточно штатных средств ОС Linux. В моей системе в сервисе cron установлено задание, по которому каждый час делается резервная копия директории /var. Таким образом, если хакер подчистит журнал, я легко смогу определить его по резервной копии.

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

Для сброса содержимого журнала по сети в файле /etc/services должна быть доступна строка:

syslog 514/udp

После этого открываем файл /etc/syslog.conf и добавляем следующую строку:

сообщения @адрес

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

Второй параметр — это адрес сервера, на который будут отправляться сообщения журналов. Если вы хотите, чтобы все сообщения отправлялись на сервер Iog.myserver.com, то добавьте строку:

*.* @log.myserver.com

Но тут есть одна проблема — для определения IP-адреса необходим DNS. При загрузке системы сервис syslogd стартует раньше DNS, поэтому определение адреса окажется невозможным. Чтобы решить эту задачу, соответствие IP-адреса и имени сервера можно прописать в файл /etc/hosts.

И последнее, на сервере служба syslogd должна быть запущена с ключом -r, который позволяет получать сообщения по сети и сохранять их в журнале. Для этого нужно изменить сценарий запуска сервиса. Напоминаю, что все сценарии хранятся в директории /etc/rc.d/init.d/, и для syslogd это файл syslog, основное содержимое которого можно увидеть в листинге 12.4.

Листинг 12.4. Содержимое файла /etc/rc.d/initd/syslog

# /bin/bash

. /etc/init.d/functions

[ -f /sbin/syslogd ] || exit 0

[ -f /sbin/klogd ] || exit 0

# Source config

# Загрузка конфигурационного файла

if [ -f /etc/sysconfig/syslog ] ; then

 . /etc/sysconfig/syslog

else

 SYSLOGD_OPTIONS="-m 0"

 KLOGD_OPTIONS="-2"

fi

RETVAL=0

umask 077

start() {

 echo -n $"Starting system logger: "

 daemon syslogd $SYSLOGD_OPTIONS

 RETVAL=$?

 echo

 echo -n $"Starting kernel logger: "

 daemon klogd $KLOGD_OPTIONS

 echo

 [ $RETVAL -eq 0 ] && touch /var/lock/subsys/syslog

 return $RETVAL

}

stop() {

 # Команды остановки сервиса

}

rhstatus() {

 # Команды вывода состояния

}

restart() {

 stop

 start

}

...

...

Самое интересное спрятано в следующих строчках:

if [ -f /etc/sysconfig/syslog ] ; then

 . /etc/sysconfig/syslog

else

 SYSLOGD_OPTIONS="-m 0"

 KLOGD_OPTIONS="-2"

fi

Здесь происходит проверка. Если файл /etc/sysconfig/syslog существует, то используются опции загрузки из этого файла, иначе явно задаются в строке:

SYSLOGD_OPTIONS="-m 0"

Здесь в кавычках указываются параметры. Чтобы добавить ключ -r, измените строку следующим образом:

SYSLOGD_OPTIONS="-m 0 -r"

Если файл /etc/sysconfig/syslog существует, то в нем будет такая же строка, и вам достаточно внести изменения туда, и не надо будет трогать сценарий запуска /etc/rc.d/init.d/syslog.

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

Вопрос решается достаточно просто, если зашифровать трафик, направив его через туннель SSL. Самый простой вариант — выполнить следующие действия:

□ на сервере, отправляющем сообщения, в конфигурационном файле прописываем пересылку сообщений на локальный компьютер:

*.* @localhost

□ все сообщения будут передаваться на локальный компьютер, т.е. самому себе на 514 порт UDP. Чтобы все работало верно, сервер не должен находиться в режиме приема сообщений, т.е. запущен без ключа -r. Иначе порт 514 будет занят, а нам это не нужно;

□ на 514 порту локального компьютера запускаем stunnel-клиент:

stunnel -c -d 127.0.0.1:514 -r loagserver:1050

Все сообщения, полученные на этот порт, будут шифроваться и передаваться на порт 1050 компьютера loagserver. В вашем случае вместо имени loagserver нужно указать адрес вашего сервера;

□ на компьютере loagserver создаем stunnel-сервер:

stunnel -d 1050 -r 127.0.0.1:514

После этих действий stunnel-сервер будет получать зашифрованные сообщения на 1050 порт и в расшифрованном виде направлять их на порт 514. На сервере loagserver сервис syslogd должен быть запущен с ключом -r для приема сообщений на 514 порту.

Теперь все сообщения будут передаваться по сети в зашифрованном виде.

 

12.5.7. logrotate

Чтобы файлы журнала слишком сильно не раздувались, в Linux включена утилита logrotate. Рассмотрим принцип ее работы на примере журнала /var/log/messages:

1. Когда размер файла /var/log/messages превышает максимально допустимое значение или проходит определенный промежуток времени, содержимое текущего журнала переносится в файл /var/log/messages.1, а файл /var/log/messages очищается и заполняется заново.

2. В следующий раз, при достижении максимального размера, содержимое файла /var/log/messages.1 переносится в /var/log/messages.2, а из журнала /var/log/messages — в /var/log/messages.1.

Таким образом, история изменений сохраняется в отдельных файлах, и ее можно всегда просмотреть, при этом сам журнал никогда не превысит определенного размера, и с ним будет удобно работать.

За сохранение истории и перенос данных между файлами отвечает программа logrotate. Рассмотрим ее конфигурационный файл (/etc/logrotate.conf), который показан в листинге 12.5.

Листинг 12.5. Файл конфигурации программы /etc/logrotate.conf

# see "man logrotate" for details

# Выполните команду man logrotate для получения дополнительной информации

# rotate log files weekly

# Смена файлов происходит еженедельно

weekly

# keep 4 weeks worth of backlogs

# Будут использоваться 4 файла для сохранения истории

rotate 4

# create new (empty) log files after rotating old ones

# После сохранения журнала создается пустой новый файл

create

# uncomment this if you want your log files compressed

# Уберите комментарий со строки compress,

# чтобы файлы журналов сжимались

#compress

# RPM packages drop log rotation information into this directory

# Пакеты RPM переносят информацию о смене журнала в эту директорию

include /etc/logrotate.d

# no packages own wtmp -- we'll rotate them here

# для журнала /var/log/wtmp задаются собственные правила

/var/log/wtmp {

 monthly

 create 0664 root utmp

 rotate 1

}

# system-specific logs may be also be configured here.

# специфичные системные журналы могут быть сконфигурированы здесь

Посмотрим на параметры, которые нам доступны:

□ weekly — указывает на то, что файлы журналов должны меняться еженедельно. Если сервер используется редко, то можно изменить это значение на monthly, чтобы обновление происходило ежемесячно;

□ rotate — задает количество файлов, которые будут использоваться для хранения истории. В данном случае стоит число 4, т.е. имена журналов будут иметь вид: /etc/log/имя.X, где X изменяется от 1 до 4;

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

□ compress — позволяет сжимать файлы журналов. На серверах, обрабатывающих запросы огромного количества пользователей, журналы могут занимать очень много места, и чтобы сэкономить дисковое пространство, их можно сжимать. Так как журналы содержат текст, компресс-версия может иметь объем на 70 % (и даже более) меньше.

В начале файла идут описания значений по умолчанию. Затем можно указать специфичные значения для определенных журналов. В данном конфигурационном файле выделен журнал /var/log/wtmp:

/var/log/wtmp {

 monthly

 create 0664 root utmp

 rotate 1

}

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

/var/log/wtmp {

 monthly size = 100k

 create 0664 root utmp

 rotate 1

}

Теперь файл журнала будет меняться в двух случаях (по событию, которое наступит раньше):

□ ежемесячно, т.к. указан параметр monthly;

□ когда файл достигнет размера 100 Кбайт.

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

Пытаться защищать журнал, увеличивая его размер до бесконечности, бесполезно, потому что хакер не будет добавлять записи в log-файл вручную, а воспользуется простой программой на Perl или написанной прямо из командного интерпретатора (Shell). Такая программа чрезвычайно проста. Достаточно только в цикле выполнять команду:

logger -р kern.alert "Текст сообщения"

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

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

/var/log/wtmp {

 monthly

 size = 100k

 create 0664 root utmp

 postrotate

 # Команда отправки журнала имя.1

 endscript

 rotate 1

}

В данном случае после первой смены журнала будет выполняться сценарий отправки этого файла на почтовый ящик администратора.

Если вы настраиваете сервис таким образом, убедитесь, что ваш почтовый ящик способен принять необходимое количество данных. Например, если вы установили максимальный размер файла в 10 Мбайт, а ваш почтовый ящик способен принять только 5 Мбайт, то вы никогда не получите этот файл, он будет удален почтовым сервером.

 

12.5.8. Пользовательские журналы

Все команды, которые выполняются пользователем, сохраняются в файле .bash_history (если используется интерпретатор команд /bin/bash), который находится в пользовательской домашней директории. Когда вы определили, под какой учетной записью в системе находился взломщик, его действия можно проследить по этому журналу.

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

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

Пользовательские журналы нужно регулярно проверять и очищать. Любой (да и вы сами) может ошибиться при написании какой-либо команды и указать свой пароль. Взломщик, проанализировав файл .bash_history, увидит пароли и сможет уничтожить ваш сервер.

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

Пароли администраторов могут указываться в командной строке и при использовании программы mysql. Если вы выполнили команду /usr/bin/mysql -uroot -ppassword, то она полностью сохранится в журнале. Получив доступ к вашему журналу bash-команд, злоумышленник приобретает возможность использовать базу данных MySQL с правами root. В лучшем случае это будет только база данных, а в худшем (если пароль root на систему и на MySQL совпадают), — весь сервер будет под контролем взломщика.

Внимание!

Никогда не выполняйте в командной строке директивы, требующие указания пароля, а если сделали это, то удалите соответствующую запись из журнала bash. В случае с MySQL нужно было задать команду /usr/bin/mysql -uroot . В ответ на это сервер запросит пароль, который не сохранится в журнале, а запишется только введенная команда.

Если вы работаете с сервером базы данных MySQL, то в вашей домашней директории помимо файла .bash_history будет еще и .mysql_history. В этом файле хранятся все команды, которые выполнялись в программе конфигурирования mysql. Его также надо очищать, если при выполнении команды был указан какой-либо пароль. БД MySQL — это еще не вся ОС, но может послужить отправной точкой для дальнейшего взлома, к тому же сами базы данных могут содержать секретную информацию, например, пароли доступа к закрытым частям Web-сайта.

 

12.5.9. Обратите внимание

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

Если стали быстро увеличиваться журналы, значит, возросла активность и, возможно, началась атака отказа от обслуживания. Нужно срочно реагировать, иначе рост нагрузки на сервер или каналы связи может стать неуправляемым, и к определенному моменту сервер перестанет обрабатывать запросы пользователей. К тому же, если журналы заполнят весь диск, то система может выйти из строя. Убедитесь, что у вас достаточно места для хранения файлов журналов.

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

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

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

При анализе журнала нужно быть очень бдительным и обращать внимание на каждую мелочь. Например, чтобы подобрать пароль, злоумышленник может использовать различные методы маскировки, в частности самостоятельно записывать в журнал подложные записи.

Если хакер будет подбирать пароль простым перебором, то вы легко увидите большое количество неудачных попыток войти под определенным пользователем, т.к. при этом в журнале /var/log/messages появляется следующая запись:

Feb 12 17:31:37 FlenovM login(pam_unix)[1238]: authentication failure;

logname=LOGIN uid=0 euid=0 tty=tty1 ruser= rhost= user=root

Параметр login(pam_unix) указывает на то, что хакер только пытается войти в систему. Если он уже проник, но неудачно использовал команду su, то в поле logname будет имя, под которым хакер находится в системе, и текст login(pam_unix) будет заменен на su(pam_unix).

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

logger -р kern.alert -t 'su(pam_unix)' "authentication failure ;

logname=robert uid=0 euid=0 tty=tty1 ruser= rhost= user=root "

В ответ на это в журнале будет создана примерно следующая запись:

Feb 12 17:31:37 FlenovM login(pam_unix)[1238]: authentication failure;

logname=robert uid=0 euid=0 tty=tty1 ruser= rhost= user=root

Теперь представим, что хакер накидал строк, в которых поле logname всегда разное. Тогда выделить из них реальные практически невозможно.

Благо если при использовании директивы logger хакер не будет использовать ключ -t, а укажет команду следующим образом:

logger -р kern.alert "authentication failure ;

logname-robert uid=0 euid=0 tty=tty1 ruser= rhost= user=root "

В этом случае в журнале будет строка:

Feb 12 17:31:37 FlenovM logger: authentication failure;

logname=robert uid=0 euid=0 tty=tty1 ruser= rhost= user=root

Как видите, перед сообщением об ошибке стоит ключевое слово logger, которое как раз и выдает подделку.

Даже если команда logger не будет доступна хакеру, он может создать записи своей программой. Чтобы этого не произошло, журналы должны быть доступны на запись только администратору root.

 

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

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

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

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

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

Есть еще один недостаток просмотра журнала построчно. Допустим, что анализатор выдал сообщение о попытке обращения к запрещенной области диска. Для большинства сервисов в этой записи отсутствует информация о пользователе.

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

 

12.6.1. tail

Когда я нахожусь непосредственно за сервером, то в отдельном окне терминала запускаю следующую команду:

tail -f /var/log/messages

После этого на экране появляется содержимое журнала, которое изменяется в реальном времени. При записи в журнал новой строки она тут же появляется у меня на мониторе.

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

 

12.6.2. Swatch

Это очень мощная утилита, написанная на простом и знакомом многим администраторам языке Perl. Это позволяет легко изменять и добавлять возможности самостоятельно. Скачать программу можно по адресу http://sourceforge.net/project/swatch.

Утилита позволяет анализировать записи по расписанию (если занести выполнение программы в cron) или сразу после их попадания в журнал.

Так как это Perl-программа, то процесс ее установки отличается от рассмотренных ранее. В данном случае выполните следующие действия:

tar xzvf swatch-3.1.tgz

cd swatch-3.1

perl Makefile.PL

make test

make install

make realclean

Как всегда, у медали есть оборотная сторона. То, что программа написана на Perl, является и недостатком, т.к. требует наличия интерпретатора. Я уже говорил, что нельзя устанавливать на сервер то, что может открыть дверь злоумышленнику и при этом не является сверх нужным. Без необходимости я рекомендую не подключать интерпретаторы типа Perl, потому что хакеры очень часто используют их для написания собственных rootkit-программ.

 

12.6.3. Logsurfer

Одна из немногих программ, которая может просматривать журнал в динамике, — Logsurfer (http://www.sourceforge.net/projects/logsurfer). Как я уже говорил, большинство средств разбирает журнал построчно, что не очень эффективно, потому что в результате мы получаем слишком много мусора.

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

 

12.6.4. Logcheck/LogSentry

Самая простая в использовании программа. Она написана теми же программистами, что и PortSentry, которую мы рассматривали в разд. 12.4.2. В состав LogSentry уже входят различные шаблоны, с помощью которых можно выделять потенциально опасные записи.

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

Но будем надеяться на лучшее.