Linux глазами хакера

Флёнов Михаил Евгеньевич

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. Безопасность сети

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