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

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.

12.6. Работа с журналами

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

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