Это - вторая из трех статей, посвященная Honeyd, OpenSource решению, которое превосходно подходит для обнаружения атак и неавторизованной активности. В первой статье, мы обсудили, что такое honeypots, их назначение и какими они бывают. Затем мы перешли к детальному рассмотрению Honeyd. В этой статье мы еще подробнее рассмотрим Honeyd. Точнее говоря, мы развернем Honeyd в огромном и опасном Интернете на одну неделю и посмотрим, что произойдет. Цель в том, чтобы проверить Honeyd, позволив плохим парням атаковать его. Затем мы проанализируем, как действовал honeypot, и что обнаружилось.
Михаил Разумов, по материалам SecurityFocus
Это - вторая из трех статей, посвященная Honeyd, OpenSource решению, которое превосходно подходит для обнаружения атак и неавторизованной активности. В первой статье, мы обсудили, что такое honeypots, их назначение и какими они бывают. Затем мы перешли к детальному рассмотрению Honeyd. В этой статье мы еще подробнее рассмотрим Honeyd. Точнее говоря, мы развернем Honeyd в огромном и опасном Интернете на одну неделю и посмотрим, что произойдет. Цель в том, чтобы проверить Honeyd, позволив плохим парням атаковать его. Затем мы проанализируем, как действовал honeypot, и что обнаружилось.
Перед тем, как перейти к рассказу о том, как действовал Honeyd, и что обнаружилось, давайте уделим немного времени для обсуждения, как я сконфигурировал и ввел honeypot в действие. Для целей этой статьи, я развернул Honeyd версии 0.5 на защищенной системе Red Hat Linux 7.3. Эта версия Honeyd имеет новые возможности. Особенно важно, что теперь можно задавать множественные IP адреса и диапазоны для одновременного контроля honeypot. Это дает нам больше гибкости в том, что контролирует honeypot. Также, версия 0.5 имеет новые возможности для ведения логов. Мало того, что все соединения регистрируются в /var/log/messages, Honeyd теперь поддерживает опциональный файл регистрации, в котором все соединения регистрируются более детально, что очень ценно для последующей обработки. Мы рассмотрим эти возможности, а также другие, позже.
Сеть, которую я выбрал, является сетью мелкой компании с выходом в Интернет. Эта сеть не защищена файрволом, и потому подвержена всем типам взломов, червей, и другой злонамеренной активности, существующей в Интернет. Это является превосходной почвой для тестирования honeypot. В этой сети было пять IP адресов, которые не использовались. Я настроил Honeyd контролировать четыре IP адреса с помощью виртуальных honeypot. Как вы помните, Honeyd работает путем наблюдения за неиспользуемым IP пространством и взаимодействуя с любой активностью, адресованной к неиспользуемым IP. Я использовал пятый IP адрес для удаленного управления honeypot. Этот IP – реальный IP, присвоенный реальному компьютеру, на котором запущено программное обеспечение honeypot. Используя конфигурацию IPTables, показанную ниже, я защитил свой honeypot. Файрвол позволяет все входящие подсоединения ко всем четырем виртуальным honeypots. В то же время, файрвол строго ограничивает доступ к самой системе, в данном случае только я имею доступ по SSH с моей администраторской системы. Чтобы еще больше защитить ваш honeypot, вы можете применить к процессу Honeyd chroot() или даже systrace(). Ниже представлена конфигурация IPTables, которую я использовал для доступа к системе honeypot и четырем виртуальным honeypots.
$IPTABLES -A INPUT -i lo -j ACCEPT # Allow the following inbound connections $IPTABLES -A INPUT -p tcp --tcp-flags ALL SYN --dport 22 -j LOG --log- prefix "Inbound SSH Connection: " $IPTABLES -A INPUT -p tcp --tcp-flags ALL SYN -s 192.168.1.1 –d 192.168.1.100 -- dport 22 -j ACCEPT $IPTABLES -A INPUT -d 192.168.1.101 -j ACCEPT $IPTABLES -A INPUT -d 192.168.1.102 -j ACCEPT $IPTABLES -A INPUT -d 192.168.1.103 -j ACCEPT $IPTABLES -A INPUT -d 192.168.1.104 -j ACCEPT # Maintain state of inbound connections. $IPTABLES -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT ### Set Policies $IPTABLES -P INPUT DROP $IPTABLES -P FORWARD DROP $IPTABLES -P OUTPUT ACCEPTПосле того, как я защитил файрволом свою платформу и определил IP, которые я хотел контролировать с помощью Honeyd, следующим шагом было конфигурирование самих honeypots. Я решил протестировать Honeyd с использованием различных операционных систем и сервисов. Таким образом, я создал следующие три honeypots: Windows NT 4.0 Server, Linux 2.4.X, and a Cisco router. Четвертый honeypot, с IP 192.168.1.103, остался без конфигурационного файла. Мне было интересно посмотреть, как будет действовать Honeyd, контролируя определенный IP без конфигурации. Ниже находится конфигурационный файл, который я использовал.
### Windows computers create windows set windows personality "Windows NT 4.0 Server SP5-SP6" set windows default tcp action reset set windows default udp action reset add windows tcp port 80 "perl scripts/iis-0.95/iisemul8.pl" add windows tcp port 139 open add windows tcp port 137 open add windows udp port 137 open add windows udp port 135 open set windows uptime 3284460 bind 192.168.1.101 windows ### Linux 2.4.x computer create linux set linux personality "Linux 2.4.16 - 2.4.18" set linux default tcp action reset set linux default udp action reset add linux tcp port 110 "sh scripts/pop3.sh" add linux tcp port 25 "sh scripts/smtp.sh" add linux tcp port 21 "sh scripts/ftp.sh" set linux uptime 3284460 bind 192.168.1.102 linux ### Cisco router create router set router personality "Cisco IOS 11.3 - 12.0(11)" set router default tcp action reset set router default udp action reset add router tcp port 23 "/usr/bin/perl scripts/router-telnet.pl" set router uid 32767 gid 32767 set router uptime 1327650 bind 192.168.1.104 router
Как вы можете увидеть из конфигурационного файла, каждой операционной системе были присвоены соответствующие сервисы, которые должны ожидаться на соответствующих системах. Система Windows имела открытые порты NetBIOS (как UDP, так и TCP), Linux имел сервисы почты и FTP, и наконец Cisco router имел стандартный порт Telnet. После того, как я сконфигурировал honeypots, все было готово к их запуску под управлением Honeyd. В версии 0.5 мы имеем несколько дополнительных возможностей, включая конфигурационные файлы xprobe2.prints. Этот файл используется для обмана попыток определения отпечатков с помощью Xprobe. Я также использовал новую возможность регистрации Honeyd, сохраняя детали атак в добавочный файл, /var/log/honeyd. Ниже вы можете увидеть, как я запустил свой honeypot.
honeyd -p nmap.prints -f honeyd.conf -x xprobe2.prints -a nmap.assoc –l /var/log/honeyd 192.168.1.101-192.168.1.104
В добавление к возможностям регистрации Honeyd, я добавил дополнительную функцию ведения логов с использованием Snort. Snort был сконфигурирован для перехвата пакетов и их данных всей активности на четырех виртуальных honeypots. Также, Snort генерировал предупреждения на любую обнаруженную злонамеренную активность. Я использовал конфигурационный файл Snort похожий на тот, что используют Honeynet Project с Honeynets. Использованные вместе, Honeyd и Snort являются мощным решением для регистрации.
Во-первых, имейте в виду, что поскольку Honeyd не производит никакой активности, ничто не должно взаимодействовать с четырьмя IP адресами, которые он контролирует. Это делает анализ собранной информации очень простым, так как практически все, что он перехватывает, наверняка имеет враждебные намерения. Во-вторых, комбинация логов Honeyd и Snort является чрезвычайно ценной. Логи Honeyd дают вам общую картину, а именно, какие системы исследуют какие порты, и когда. Версия 0.5 теперь поддерживает два формата регистрации, так что вы можете выбрать для анализа данные, которые лучше соответствуют вашим нуждам. После того, как вы определили, какой трафик вас интересует, можно использовать Snort для анализа перехваченых пакетов с более детальной информацией.
Не удивительно, что Honeyd продемонстрировал, что Интернет – чрезвычайно враждебная среда. Если уязвимые системы развернуты в Интернет, они будут быстро обнаружены и компрометированы. Черви, авторутеры, и активные взломщики непрерывно обыскивают Интернет в поисках чего-нибудь ценного. Honeyd быстро и просто продемонстрировал это. В течение одной недели в феврале 2003, Honeyd сканировался в среднем 67 уникальными системами в день. Давайте взглянем на типичный день и посмотрим на активность, перехваченную Honeyd.
12 февраля 2003 года был загруженный день. В течение этого дня 82 различных компьютера зондировали honeypots. Ни одна из этих систем не имела никаких оснований или разрешений соединяться с нашим honeypot. А если так, мы полагаем, что они были враждебными. Начнем с просмотра var/log/messages. Здесь Honeyd регистрирует всю обнаруженную активность в читабельном для человека формате. Ниже мы видим несколько различных попыток сканирования, с разъяснениями, что происходит в каждом случае.
/var/log/messages Feb 12 23:06:33 laptop honeyd[30948]: Connection to closed port: udp(210.35.1192.168.1.102:8028.1:1978 - 192.168.1.101:1978) Feb 12 23:23:40 laptop honeyd[30948]: Connection request: tcp(66.136.92.78:3269 - 192.168.1.102:25) Feb 12 23:23:40 laptop honeyd[30948]: Connection established: tcp (66.136.92.78:3269 - 192.168.1.102:25) <-> sh scripts/smtp.sh Feb 12 23:24:14 laptop honeyd[30948]: Connection dropped with reset:tcp (66.136.92.78:3269 - 192.168.1.102:25) Feb 12 23:34:53 laptop honeyd[30948]: Killing attempted connection:tcp (216.237.78.227:3297 - 192.168.1.102:80) Feb 12 23:39:14 laptop honeyd[30948]: Connection: udp (10.5.5.71:1026 -192.168.1.101:137) Feb 12 23:39:14 laptop honeyd[30948]: Connection established: udp(10.5.5.71:1026 - 192.168.1.101:137) /tmp/honeyd/smtp-.log Wed Feb 12 23:23:40 UTC 2003: SMTP started from Port EHLO relay.verizon.net MAIL From: RCPT To:В лог-файле /varlog/honeyd, мы видим ту же информацию, но в несколько другом формате. Эта информация предназначена для чтения и обработки скриптами и утилитами. Обратите внимание также на крайнюю правую часть соединения. Это число показывает общее количество байт при попытке соединения.
/var/log/honeyd 2003-02-12-23:06:33.0633 udp(17) - 210.35.128.1 1978 192.168.1.101 1978: 69 2003-02-12-23:23:40.0600 tcp(6) S 66.136.92.78 3269 192.168.1.102 25 2003-02-12-23:24:14.0940 tcp(6) E 66.136.92.78 3269 192.168.1.102 25: 98 342 2003-02-12-23:34:53.0969 tcp(6) - 216.237.78.227 3297 192.168.1.102 80: 48 S 2003-02-12-23:39:14.0008 udp(17) S 10.5.5.71 1026 192.168.1.101 137 2003-02-12-23:39:14.0194 udp(17) - 10.5.5.71 1026 192.168.1.102 137: 78
Логи Honeyd эффективно показывают нам, что происходит. Я обычно начинаю с них, чтобы определить, какая происходит активность. Если происходят подсоединения к портам с прикрепленными скриптами, эти скрипты часто имеют собственные возможности ведения логов, встроенные в них, как мы видели в скрипте smtp.sh. Единственное огорчение состояло в том, что я не смог найти Honeyd скрипт для эмуляции веб-сервера IIS.
В добавок к логам Honeyd, каждое из этих соединений также перехватывалось Snort. Мы можем проанализировать пакеты и их данные для каждого атакующего в поисках дополнительной информации, такой как пассивные отпечатки. Если бы была предпринята реальная атака, Snort бы обнаружил атаку и сгенерировал предупреждение. 12 февраля Snort обнаружил 48 атак, включая попытки переполнения FTP CWD, Socks Scans, и WEB-IIS unicode обхода директории. В целом, типичный день в Интернет.
Реальная ценность Honeyd и honeypots вообще состоит не только в том, что они обнаруживают, но и в том, чего они не обнаруживают: ложные тревоги. Honeypots практически устраняют ложные сигналы. Почти вся информация, которую они собирают, индицирует злонамеренную активность. Поскольку количество данных мало, вы можете быстро обнаруживать и реагировать на угрозу. Инструменты, такие как Honeyd, представляют превосходную технологию, дополняющую ваши IDS системы. Представьте, что вы обнаружите, если развернете что-нибудь вроде этого в вашей внутренней сети?
Honeyd демонстрирует истинные способности обнаружения, присущие honeypots. Имейте в виду, что этот инструмент еще совсем молод: вы можете ожидать много новых, захватывающих возможностей у Honeyd в будущем. Если вы хотите побольше узнать о Honeyd, или honeypots вообще, вы можете начать с сайта http://www.tracking-hackers.com/, или с книги Honeypots: Tracking Hackers.
Ладно, не доказали. Но мы работаем над этим