Первый уровень контроля доступа состоит из устройств контроля доступа, таких как брандмауэр и маршрутизатор. Любой пакет, входящий или исходящий из Honeynet, должен пройти через эти устройства, вот почему они являются превосходным источником информации. Как правило, они отслеживают пакеты, входящие и исходящие из сети Honeynet. Многие пользователи считают журналы регистрации брандмауэра бесполезными, так как ежедневно там записывается по 100-500 Мб данных. Объем этой информации может показаться очень большим, и его трудно анализировать. Однако помните, что любые данные, входящие или исходящие из Honeynet, подозрительны. Для большинства организаций деятельность TELNET, RPC (Remote Processing Call - удаленный вызов процедуры) и ICMP (Internet Control Message Protocol - протокол управляющих сообщений в сети Internet) нормальна. Иногда трудно отличить невинный запрос RPC и угрожающее сканирование rpc.mountd. Honeynet решает эту проблему, маркируя все входящие и исходящие из сети данные.
Вы будете поражены тем, какой объем трафика является сомнительным. То, что кажется ложным сообщением об ошибке ICMP, может означать, что кто-то сканирует системы в поисках черного хода. То, что кажется ошибочной попыткой установления соединения TELNET, на самом деле означает, что кто-то сканирует систему в поисках троянских логинов, которые ищут настройку терминала ELITE. Мы рассказываем об анализе данных в следующих главах этой книги. Однако очень важно записывать и регистрировать любой входящий и исходящий из Honeynet трафик.
Любой трафик, направляющийся в сети Honeynet, подозрителен. Мы хотим не только зарегистрировать эту информацию на брандмауэре, но и получить сообщение о ней. Брандмауэр Honeynet можно настроить так, чтобы он предупреждал администраторов всякий раз, когда предпринимается попытка установить исходящее соединение. Этот принцип доказал свою эффективность, так как предупреждения приходят в режиме реального времени, извещая администраторов о подозрительных действиях.
В качестве примера можно привести соединение DNS с Honeynet. Обычно сервис DNS не считается подозрительным. Однако в случае с Honeynet мы всегда подозрительны, особенно если пакет DNS оказывается запросом о номере версии или попыткой передачи зон на основе протокола управления передачей (Transmission Control Protocol - TCP). Процедура предупреждения о входящих соединениях очень похожа на предупреждение об исходящих соединениях, которое было описано ранее. Фактически для того, чтобы послать разные извещения, используется тот же самый, лишь слегка измененный, сценарий. Ниже приведен пример сообщения о TCP-соединении с портом 53, которое, скорее всего, является попыткой передачи зон DNS. Это предупреждение извещает нас в режиме реального времени о том, что кто-то пытается установить TCP-соединение с DNS, то есть о передаче зон, а это обычно первый этап в процессе сбора информации. Обратите внимание на то, что электронные сообщения подсчитываются. Значит, можно установить их максимальное количество, защищая систему от наплыва электронных писем, например о том, что она сканируется через тысячу портов.
Вы получили это сообщение, потому что кто-то, возможно, сканирует вашу систему. Ниже приводится пакет, зарегистрированный брандмауэром. Это первое из пяти электронных предупреждений от evil-hacker.example.com.
CRITICAL INFORMATION
Date: 22Nov2000
Time: 18:23:20
Source: evil-hacker.example.com
Destination: honeypot-7
Service: domain-tcp
ACTUAL FW-1 LOG ENTRY
22Nov2000 18:23:20 accept firewall >qfe1 useralert proto tcp src evil-hacker, example, com dst honeypot-7 service domain-tcp s_port 4269 len 48 rule 9 xlatesrc evil-hacker.example.com xlatedst honeypot-7 xlatesport 4269 xlatedport domain-tcp
Такие сообщения помогают отслеживать действия в реальном времени. Если все системы в Honeynet сканируются для FTP, вы можете быстро установить это по электронным сообщениям. То же самое правило применяется и тогда, когда сканируется одна система через несколько портов. Данный сценарий предупреждения можно использовать для поддержания базы данных о том, кто, что и когда сканировал. Предупреждения необычайно полезны при анализе данных, когда их можно сравнить с предупреждениями и регистрационными записями IDS, о чем мы рассказываем в главе 5. Эти данные также должны быть защищены, поэтому они или хранятся локально на брандмауэре, или передаются в качестве электронного предупреждения в защищенную, доверяемую систему, такую как ваш почтовый сервер. Запомните, ни в коем случае нельзя хранить какие-либо данные в системах honeypot. Они могут быть обнаружены и использованы для взлома honeypot и/или изменены или удалены взломщиком. Уязвимость брандмауэра заключается в том, что он не в состоянии отслеживать действия между системами Honeynet, как и все, что происходит локально. Брандмауэр может зарегистрировать только ту информацию, которая проходит через него. Для того чтобы отследить подобные действия, должны быть дополнительные способы контроля.
Сценарий, который мы разработали для предупреждения о входящих соединениях, аналогичен сценарию для предупреждения и блокировки исходящих соединений, который уже описывался в этой главе. Единственное отличие заключается в том, что электронное сообщение немного модифицировано. Для запуска сценария мы изменяем базу правил брандмауэра. Вместо того, чтобы просто зарегистрировать входящее соединение с Honeynet, брандмауэр должен зарегистрировать соединение и выполнить сценарий для каждого входящего соединения. Посмотрите на рис. 3.4 и обратите внимание на то, как мы изменили правило 1 (на рисунке выделено), чтобы не только регистрировать входящие соединения, но и посылать электронные извещения.
Имейте в виду, что разработанные нами сценарии подходят не только к FireWall-1. Вы можете использовать какие угодно виды брандмауэров или сценариев. Важно только, чтобы в случае входящего или исходящего трафика вам посылалось извещение. Любой входящий трафик сомнителен, так что, скорее всего, вы захотите о нем знать.
У сценария есть второе преимущество: он архивирует все попытки соединения, зарегистрированные брандмауэром. Помимо того что сценарий создает электронное предупреждение о каждой попытке соединения, он архивирует записи об этих попытках в двух разных файлах для дальнейшего просмотра - alert.archives и alert.uniq. Первый файл, alert.archives, записывает все входящие соединения в отдельный однородный файл. Если система из сети Internet зондировала восемь систем honeypot через один 1?'local - Check Point Policy Editor
порт, например домен TCP, каждая попытка соединения будет зарегистрирована и записана в этом файле. Эту информацию можно использовать для анализа тенденций и глубокого разбора отдельных атак и попыток зондирования. Например, полученное нами электронное предупреждение будет записано в этот однородный файл следующим образом:
22Nov2000 18:23:20 accept firewall >qfe1 useralert proto tcp src evil-hacker, example, com dst honeypot-7 service domain-tcp s_port 4269 len 48 rule 9 xlatesrc evil-hacker.example.com xlatedst honeypot-7 xlatesport 4269 xlatedport domain-tcp
Второй файл, alert.uniq, регистрирует только первую попытку соединения с каждого уникального IP-адреса за сутки. В этом файле записываются только четыре параметра: дата, время, система, от которой исходил запрос, и сервис, с которым осуществлялось соединение. Это дает возможность прослеживать, какие системы (с уникальными IP-адресами) сканировали или зондировали вашу сеть. Полученную информацию можно использовать для анализа тенденций или для того, чтобы быстро определить, зондировала ли данная система вас раньше. Этот файл первоначально использовался для определения внезапного роста сканирования сети на базе протокола NetBIOS (Network Basic Input Output System - сетевая базовая система ввода/вывода), который описывается в главе 10. Например, первое - и только первое - соединение на основе нашего электронного предупреждения будет записано в этот однородный файл следующим образом:
