Linux глазами хакера - Михаил Флёнов

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

Например, вы заметили строку о неправомерном доступе к 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 уже входят различные шаблоны, с помощью которых можно выделять потенциально опасные записи.

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

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

12.7. Безопасность журналов

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

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

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

ls -al /var/log

Результат работы команды:

drwxr-xr-x  9 root root  4096 Jan 12 13:18 .

drwxr-xr-x 21 root root  4096 Jan 24 23:00 ..

drwx------  2 root root  4096 Jan 12 11:14 bc1security

-rw-r-----  1 root root 83307 Jan 12 13:18 boot.log

-rw-r-----  1 root root 89697 Jan  6 09:01 boot.log.1

-rw-r-----  1 root root 48922 Jan 30 11:45 boot.log.2

-rw-r-----  1 root root 64540 Jan 23 19:55 boot.log.3

-rw-r-----  1 root root 36769 Jan 16 12:36 boot.log.4

-rw-r-----  1 root root  8453 Jan 12 13:18 cron

-rw-r-----  1 root root  8507 Jan  6 09:06 cron.1

-rw-r-----  1 root root  7189 Jan 30 11:50 cron.2

-rw-r-----  1 root root  6935 Jan 23 20:01 cron.3

-rw-r-----  1 root root  4176 Jan 16 12:41 cron.4

...

...

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

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

Следующие команды создают новую группу loggroup и устанавливают ее для всех log-файлов:

groupadd logsgroup

cd /var/log

chgrp -R logsgroup

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

cd /var/log

find . -type f | xargs chmod 640

Вторая строка состоит из двух директив. Команда find . -type f ищет в текущем каталоге все объекты, у которых тип равен f, т.е. все файлы. Вторая (xargs chmod 640)— изменяет у всех найденных объектов права доступа на 640. Можно даже понизить это значение до 600, чтобы читать и писать мог только администратор.

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

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

Но и этого недостаточно для обеспечения максимальной защиты. Если посмотреть на суть журналов, то станет очевидным, что в них ОС только добавляет новые записи. Таким образом, можно поставить дополнительную защиту от удаления и изменения с помощью ключей. В файловых системах Ext2 и Ext3 есть команда chattr, с помощью которой можно устанавливать дополнительные атрибуты на файлы. Один из них (ключ +a) позволяет задать условие, при котором файл можно только пополнять. Например, следующая команда устанавливает для файла /var/log/boot.log такой атрибут:

chattr +а /var/log/boot.log

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

chattr -a /var/log/boot.log

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

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

12.8. Безопасность сети

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