На главную | Содержание | Назад | Вперёд
Наши друзья

 

 

Защита регистрационных журналов


Мы здесь не сможем охватить вопросы систем обнаружения атак
(Intrusion Detection, IDS); на эту тему имеется немало прекрасных публикаций. Если вы заинтересовались этой темой, то я рекомендую
вам обратить внимание на такие приложения, как Network Flight Recorder или snort.
Мы сконцентрируемся на процессе аналитического исследова­ния, а именно, каким образом выяснить, что делает враг путем изуче­ния регистрационных журналов системы. Вы будете удивлены, сколь­ко интересной информации можно в них найти! Однако прежде, чем мы начнем говорить об их изучении, нам надо обсудить их защищен­ность.
Эти журналы не будут представлять никакой ценности, если не обеспечить их целостность. Первое, что делает злоумышленник, про­никнув в систему, — это изменение регистрационных журналов.
Имеется целый ряд средств удаляющих из журналов
все следы присутствия (например, cloack) или полностью подменяю­щих подсистему регистрации (в частности, sys-logd).
Итак, первый шаг при рассмотрении ваших журналов — это их защита. Это означает, что вам придется использовать удаленный sys-log-сервер.
Независимо от того, насколько защищена ваша система, вы не можете доверять регистрационным журналам со скомпрометирован­ного компьютера. Даже если черная шляпа не придумает ничего луч­ше, чем выполнить команду очистив таким образом жесткий диск, это уже сделает восстановление регистрационных журналов затруднительным.
Чтобы защититься от этой ситуации, вам придется настроить ва­ши системы таким образом, чтобы они регистрировали трафик как ло­кально, так и на удаленном log-сервере. Я рекомендую сделать такой
сервер на базе выделенной машины, единственной задачей которой
будет сбор журналов с других систем. Если величина материальных затрат является определяющим фактором, вы можете построить log-сервер под управлением Эта машина должна быть хорошо защи-
щена, все сервисы на ней должны быть выключены, а доступ разрешен только с консоли (см. «Armoring Linux» для примера). Также убеди­тесь, что порт DP блокирован или закрыт межсетевым экраном (firewall) со стороны Internet. Это защитит ваш log-сервер от навязы­вания ложной регистрационной информации снаружи.
Для тех, кто любит перестраховываться, могу порекомендовать
свой любимый трюк, заключающийся в перекомпиляции syslogd та­ким образом, чтобы он читал альтернативный файл конфигурации, на­пример, /var/tmp/.conf. В этом случае черная шляпа не будет знать, где находится настоящий конфигурационный файл. Чтобы достичь этого, просто замените в исходном тексте syslogd строку
iog.conf» на любое другое желаемое значение. После этого настроим наш новый конфигурационный файл на регистрацию событий как ло­кально, так и на удаленном сервере. Удостоверьтесь, что в стандартной копии конфигурационного файла (/etc/syslog.conf) также сделаны настройки на локальную регистрацию. Несмотря на то, что этот файл теперь не играет никакой роли, эта мера предосторож­ности не даст черной шляпе понять, что есть еще и удаленная регист­рация. Другой подход — использовать безопасный метод регистрации. Он заключается в замене стандартного syslogd другим, с проверкой це­лостности и дополнительными опциями. Один из вариантов — syslog-ng, который вы можете найти по адресу http://www.balabit.hu/prod-ucts/syslog-ng.html.
Большинство регистрационных журналов, которые мы будем использовать — это файлы, сохраненные на удаленном log-сервере. Как сказано выше, мы можем быть в достаточной степени уверены в их истинности, т.к. они находятся на удаленном и защищенном серве­ре. Кроме того, поскольку все системы посылают информацию в одно место, вам будет легче ее анализировать. Вы сможете быстро просмот­реть, что происходит во всех системах, используя один источник. Единственный случай, когда вам понадобятся локальные регистраци­онные журналы, — это сравнение их с журналами на log-сервере. Это сравнение поможет вам установить факт подделки локальных журна­лов.
Поиск характерных признаков
Обычно вы можете определить факт сканирования портов ва­шей системы путем простого анализа регистрационных журналов.
Большинство Script Kiddie сканирует сеть в поисках какой-то опреде­ленной уязвимости.
вы замечаете в регистрационных журналах записи, указы­вающие попытку установить соединение на один и тот же порт большинства ваших систем с одного адреса, это указывает на такое специализированное сканирование. Вероятнее всего, злоумышленник имеет готовый эксплоит для какой-то определенной уязвимости и об­следует сеть в ее поисках. Если поиск будет удачным, он попробует применить эксплоит.
По умолчанию, большинство систем на базе Linux устанавлива­ется с программой TCP Wrapper, поэтому мы можем увидеть такие за­писи в /var/log/secure. Для других разновидностей Unix мы можем фиксировать эти события путем запуска супердемона (ine'td) с флаж­ком «-t». Типичное сканирование на определенную уязвимость иыгля-
дит, как приведенный ниже листинг. В данном случае злоумышленник пытается найти демон в котором есть уязвимости.
/var/log/secure
Apr 10 13:43:48 mozart in.ftpd[ 66131 : connect from 192.168.11.200
Apr 10 13:43:51 bach in. ftpd[6613] : connect from 192.168.11.200
Apr   10   13:43:54   hadyen  in. ftpd[6613] :   connect from
192.168.11.200
Apr  10   13:43:57  vivaldi  in.ftpd[6613] :  connect from
192.168.11.200
Apr 10 13:43:58 brahms in.ftpd[6613] : connect from 192.168.11.200
Здесь ясно виден источник сканирования нашей сети — 192.168.11.200.
Обратите внимание, как источник последовательно перебирает каждый IP-адрес (так бывает не всегда). В этом одно из преимуществ выделенного log-сервера — вы можете оценить картину в масштабе се­ти, т. к. регистрационные журналы объединены. Повторяющиеся со­единения на порт (ftp) наиболее вероятно указывают на поиск уяз­вимого демона wu-ftpd. Мы только что определили, что именно ищет черная шляпа.
Очень часто сканирования идут волнами. Кто-то выпускает экс-плоит для imap, и вы обнаруживаете в регистрационных журналах
всплеск сканирований порта imap. В следующем месяце вы обнаружи­те повышенное внимание к ftp. Отличное место для получения инфор­мации о текущих эксплоитах — http://www.cert.org/advisories/.
Иногда сканирование производится на предмет наличия нескольких уязвимостей; тогда вы увидите в регистрационных журналах свидетельствующие о попытках соединения из одного источника к нескольким портам ваших систем.
Помните, что если вы не регистрируете обращения к сервису, вы не сможете отследить факт сканирования. Например, большинство rpc-соединений не регистрируется. Между тем, большинство сервисов могут быть просто добавлены в /etc/inetd.conf и попытки соединений
будут зафиксированы с помощью TCP Wrapper. Например, вы можете
добавить в /etc/inetd.conf запись для NetBus. TCP Wrapper в этом слу­чае настраивается на сброс и регистрацию соединения (см. Intrusion
Detection для дополнительной информации по этому вопросу).

 

На главную | Содержание | Назад | Вперёд
 
Яндекс.Метрика