без паники и всерьез
подробно о проекте
 |  |
Анализ криптографических сетевых...| главная | обзор | RSN | блог | библиотека | закон | бред | форум | dnet | о проекте |  |
|
Проект Honeynet, перевод В.В.Мяснянкина Опубликовано: dl, 28.01.02 15:04
©
Проект Honeynet
Эта статья является второй в серии "Узнай своего врага". В первой статье мы рассмотрели средства и методологию, которые используют Script Kiddie, а именно как они отыскивают уязвимости и затем нападают. Третья статья рассказывает о том, что делают Script Kiddie, получив права root, а именно каким образом они заметают следы и что делают дальше. А здесь мы рассмотрим вопрос отслеживания действий злоумышленника. Как и в военных действиях, Вы должны следить за перемещениями плохих парней и знать, что они собираются делать. Мы узнаем, что Вы сможете, и что не сможете определить, используя регистрационные журналы Вашей системы. Вы можете установить, были ли попытки исследования Вашей системы, как это было сделано, какие инструментальные средства применялись, и привело ли это к успеху. Приведенные примеры ориентированы на Linux, но могут быть с успехом применены и к большинству других Unix-подобных операционных систем. Учтите, что нет гарантированного способа точно отследить каждый шаг злоумышленника, однако данная статья поможет Вам начать движение в этом направлении. Защита регистрационных журналовЭта статья не охватывает вопросы систем обнаружения атак (Intrusion Detection, IDS); на эту тему имеется немало прекрасных публикаций. Если Вы заинтересовались этой темой, то я рекомендую Вам обратить внимание на такие приложения как Network Flight Recorder или snort. Мы сконцентрируемся на процессе аналитического исследования, а именно, каким образом выяснить, что делает враг путем изучения регистрационных журналов системы. Вы будете удивлены, сколько интересной информации можно в них найти! Однако, прежде чем мы начнем говорить об их изучении, нам надо обсудить их защищенность. Эти журналы не будут представлять никакой ценности, если не обеспечить их целостность. Первое, что делает злоумышленник, проникнув в систему - это изменение регистрационных журналов. Имеется целый ряд средств (rootkits), удаляющих из журналов все следы присутствия (например, cloack), или полностью подменяющих подсистему регистрации (в частности "троянизированный" syslogd). Итак, первый шаг при рассмотрении Ваших журналов - это их защита. Это означает, что Вам придется использовать удаленный syslog-сервер. Независимо от того, насколько защищена Ваша система, Вы не можете доверять регистрационным журналам со скомпрометированного компьютера. Даже если черная шляпа не придумает ничего лучше, чем выполнить команду rm -rf /*, очистив таким образом жесткий диск, это уже сделает восстановление регистрационных журналов затруднительным. Чтобы защититься от этой ситуации, Вам придется настроить Ваши системы таким образом, чтобы они регистрировали трафик как локально, так и на удаленном log-сервере. Я рекомендую сделать такой сервер на базе выделенной машины, единственной задачей которой будет сбор журналов с других систем. Если величина материальных затрат является определяющим фактором, Вы можете построить log-сервер под управлением linux. Эта машина должна быть хорошо защищена, все сервисы на ней должны быть выключены, а доступ разрешен только с консоли (см. "Armoring Linux" для примера). Также, убедитесь, что 514 порт UDP блокирован или закрыт межсетевым экраном (firewall) со стороны Internet. Это защитит Ваш log-сервер от навязывания ложной регистрационной информации снаружи. Для тех, кто любит перестраховываться, могу порекомендовать свой любимый трюк, заключающийся в перекомпиляции syslogd таким образом, чтобы он читал альтернативный файл конфигурации, например, /var/tmp/.conf. В этом случае черная шляпа не будет знать, где находится настоящий конфигурационный файл. Чтобы достичь этого, просто замените в исходном тексте syslogd строку "/etc/syslog.conf" на любое другое желаемое значение. После этого настроим наш новый конфигурационный файл на регистрацию событий как локально, так и на удаленном сервере (см. пример). Удостоверитесь, что в стандартной копии конфигурационного файла (/etc/syslog.conf) также сделаны настройки на локальную регистрацию. Не смотря на то, что этот файл теперь не играет никакой роли, эта мера предосторожности не даст черной шляпе понять, что есть еще и удаленная регистрация. Другой подход - использовать безопасный метод регистрации. Он заключается в замене стандартного syslogd другим, с проверкой целостности и дополнительными опциями. Один из вариантов - syslog-ng, который Вы можете найти по адресу http://www.balabit.hu/products/syslog-ng.html Большинство регистрационных журналов, которые мы будем использовать - это файлы, сохраненные на удаленном log-сервере. Как сказано выше, мы можем быть в достаточной степени уверены в их истинности, т.к. они находятся на удаленном и защищенном сервере. Кроме того, поскольку все системы посылают информацию в одно место, Вам будет легче ее анализировать. Вы сможете быстро просмотреть, что происходит во всех системах, используя один источник. Единственный случай, когда Вам понадобятся локальные регистрационные журналы - это сравнение их с журналами на log-сервере. Это сравнение поможет Вам установить факт подделки локальных журналов. Поиск характерных признаковОбычно Вы можете определить факт сканирования портов Вашей системы путем простого анализа регистрационных журналов. Большинство Script Kiddie сканирует сеть в поисках какой-то определенной уязвимости. Если Вы замечаете в регистрационных журналах записи, указывающие на попытку установить соединение на один и тот же порт большинства Ваших систем с одного адреса, это указывает на такое специализированное сканирование. Вероятнее всего, злоумышленник имеет готовый эксплоит для какой-то определенной уязвимости и обследует сеть в ее поисках. Если поиск будет удачным, он попробует применить эксплоит. По умолчанию, большинство систем на базе Linux устанавливаются с программой TCP Wrapper, поэтому мы можем увидеть такие записи в /var/log/secure. Для других разновидностей Unix, мы можем фиксировать эти события путем запуска супердемона (inetd) с флажком "-t". Типичное сканирование на определенную уязвимость выглядит как приведенный ниже листинг. В данном случае злоумышленник пытается найти демон wu-ftpd, в котором есть уязвимости. /var/log/secure Apr 10 13:43:48 mozart in.ftpd[6613]: 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-сервера - Вы можете оценить картину в масштабе сети, т.к. регистрационные журналы объединены. Повторяющиеся соединения на порт 21 (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 для дополнительной информации по этому вопросу). Какое средство применяется?
Иногда Вы можете достаточно точно определить, какое средство использовано для
сканирования Вашей сети. Большинство простых средств сканирования, таких как ftp-scan.c,
исследуют сеть в поисках конкретной уязвимости. Если в Вашей сети наблюдается
интерес к какому-то определенному порту, наиболее вероятно, что
используется одно из таких специализированных средств. Существуют, однако, и
более универсальные средства, проверяющие наличие сразу нескольких
уязвимостей. Два наиболее известных - это sscan (автор - jsbach) и nmap (автор - Fyodor). Я выделили
именно эти два средства, так как они представляют две "категории" сканеров. Я
настойчиво рекомендую Вам изучить собственные сети этими средствами -
результаты могут вас удивить :). Sscan, часто применяемый Script Kiddie, является многоцелевым сканером. Он проверяет сеть на наличие набора заранее определенных уязвимостей. Это настраиваемое средство: оно позволяет Вам добавить описание новых типов уязвимостей. Вы просто сообщаете ему адрес сети, и sscan делает остальную работу самостоятельно. Однако, для его использования необходимо иметь права root в системе, на которой он запускается. Выдаваемая им информация чрезвычайно легко интерпретируется, что и сделало его настолько популярным. Он выдает сводную информацию о многих уязвимых сервисах. Все, что Вам надо - это запустить сканирование выбранной сети, проанализировать выходную информацию (найти с помощью grep слово "VULN") и запустить соответствующий "эксплоит дня". Ниже приведен результат работы sscan, запущенного на анализ системы под названием mozart (172.17.6.30). otto #./sscan -o 172.17.6.30 --------------------------<[ * report for host mozart * <[ tcp port: 80 (http) ]> <[ tcp port: 23 (telnet) ]> <[ tcp port: 143 (imap) ]> <[ tcp port: 110 (pop-3) ]> <[ tcp port: 111 (sunrpc) ]> <[ tcp port: 79 (finger) ]> <[ tcp port: 53 (domain) ]> <[ tcp port: 25 (smtp) ]> <[ tcp port: 21 (ftp) ]> --<[ *OS*: mozart: os detected: redhat linux 5.1 mozart: VULN: linux box vulnerable to named overflow. <[ *CGI*: 172.17.6.30: tried to redirect a /cgi-bin/phf request. <[ *FINGER*: mozart: root: account exists. <[ *VULN*: mozart: sendmail will 'expn' accounts for us <[ *VULN*: mozart: linux bind/iquery remote buffer overflow <[ *VULN*: mozart: linux mountd remote buffer overflow ---------------------------<[ * scan of mozart completed * Nmap входит в группу средств, добывающих "чистые данные". Он не пытается найти уязвимости, а просто сообщает, какие порты открыты, оставляя принятие решения об их защищенности Вам. Nmap быстро стал самым популярным сканером, и на то есть объективные причины. Он соединяет в одном средстве черты лучших сканеров, включая определение типа операционной системы, различные способы построения пакетов, сканирование как UDP, так и TCP, рандомизацию и т.д. Однако, необходимо обладать достаточными знаниями в области сетевых технологий, чтобы интерпретировать полученные данные. Ниже приведен пример работы nmap, запущенного для изучения той же самой системы.
otto #nmap -sS -O 172.17.6.30
Starting nmap V. 2.08 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
Interesting ports on mozart (172.17.6.30):
Port State Protocol Service
21 open tcp ftp
23 open tcp telnet
25 open tcp smtp
37 open tcp time
53 open tcp domain
70 open tcp gopher
79 open tcp finger
80 open tcp http
109 open tcp pop-2
110 open tcp pop-3
111 open tcp sunrpc
143 open tcp imap2
513 open tcp login
514 open tcp shell
635 open tcp unknown
2049 open tcp nfs
TCP Sequence Prediction: Class=truly random Difficulty=9999999 (Good luck!)
Remote operating system guess: Linux 2.0.35-36
Nmap run completed -- 1 IP address (1 host up) scanned in 2 seconds
Просматривая Ваши регистрационные журналы, Вы можете определить, какое из этих
средств было использовано для изучения Вашей системы. Чтобы сделать это, Вам
необходимо понять механизмы работы этих средств. Сканирование при помощи sscan
отражается в регистрационных журналах, как приведено ниже (это режим по
умолчанию, без внесения изменений в конфигурационные файлы):
/var/log/secure
/var/log/maillog
/var/log/messages Sscan также определяет уязвимости cgi (common gateway interface). Эти попытки не будут зафиксированы в журналах syslogd, Вы найдете их в файле access_log. Я решил включить и этот пример для иллюстрации. /var/log/httpd/access_log 192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/phf HTTP/1.0" 302 192 192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/Count.cgi HTTP/1.0" 404 170 192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/test-cgi HTTP/1.0" 404 169 192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/php.cgi HTTP/1.0" 404 168 192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/handler HTTP/1.0" 404 168 192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/webgais HTTP/1.0" 404 168 192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/websendmail HTTP/1.0" 404 172 192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/webdist.cgi HTTP/1.0" 404 172 192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/faxsurvey HTTP/1.0" 404 170 192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/htmlscript HTTP/1.0" 404 171 192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/pfdisplay.cgi HTTP/1.0" 404 174 192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/perl.exe HTTP/1.0" 404 169 192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/wwwboard.pl HTTP/1.0" 404 172 192.168.11.200 - - [14/Apr/1999:16:44:50 -0500] "GET /cgi-bin/ews/ews/architext_query.pl HTTP/1.0" 404 187 192.168.11.200 - - [14/Apr/1999:16:44:50 -0500] "GET /cgi-bin/jj HTTP/1.0" 404 163 Обратите внимание, что для каждого порта создается полноценное соединение (SYN, SYN-ACK, ACK), которое затем закрывается. Это происходит потому, что sscan в данном режиме работает на уровне приложений. sscan не просто определяет, открыт ли порт ftp, но и какой именно демон ftp запущен. То же самое можно сказать и про imap, pop и т.д. Это легко увидеть при помощи sniffit - средства, широко применяемого для перехвата паролей.
mozart $ cat 172.17.6.30.21-192.168.11.200.7238 Как видно из приведенного выше примера, для определения версии wu-ftpd также создавалось полноценное соединение. Когда Вы видите в Ваших регистрационных журналах такие следы, это означает, что применялось средство поиска уязвимостей. Такие программы всегда создают полноценные соединения для определения версий исполняемого программного обеспечения. Nmap, как и большинство сканеров портов, не интересуется, какая версия программного обеспечения запущена, он определяет, открыт ли соответствующий порт. Для этого nmap снабжен мощным набором опций, позволяющих Вам задать тип используемого соединения, включая SYN, FIN, Xmas, Null и т.п. Детальное описание этих опций можно получить по адресу http://www.insecure.org/nmap/nmap_doc.html. . Эти опции влияют на вид записей в Ваших регистрационных журналах, в зависимости от использованного атакующим набора параметров. Соединение с флагом -sT являются полноценными, поэтому записи в регистрационных журналах будут похожи на записи после применения sscan, с той лишь разницей, что nmap проверяет большее количество портов.
/var/log/secure Еще один момент, о котором следует помнить, это опция -D (decoy). Эта опция позволяет установить для сканера поддельный обратный адрес. Вы можете увидеть соединения с 15 различных адресов одновременно, но только один из них будет настоящим. Чрезвычайно трудно определить, который из 15 источников является истинным. Более того, при сканировании портов часто используется опция -sS. Этот режим позволяет осуществить скрытное (стелс) сканирование. В этом случае сканер посылает только SYN-пакет, а после получения ответа от удаленной системы сразу же его разрывает посылкой пакета с флагом RST. /var/log/secure Ух! Здесь ничего нет! Причина кроется в том, что подсистема регистрации записывает данные только о полностью установленных соединениях. Так как nmap запускался с параметром sS, полноценное TCP-соединение не устанавливалось, и факт сканирования, таким образом, зафиксирован не был. Именно по этой причине данный тип сканирования является скрытным (стелс) - он не фиксируется в системных журналах. Для систем на базе Linux со старыми версиями ядра (а именно: 2.0.x), неполные соединения фиксируются, но как несостоявшиеся. Регистрационные журналы системы с таким ядром и просканированной с параметром -sS выглядят следующим образом (ПРИМЕЧАНИЕ: приведены только первые пять записей):
/var/log/secure Обратите внимание на ошибки в установлении соединения. Так как последовательность SYN-ACK прерывается и установка соединения не завершена, демон не может определить систему-источник. Из регистрационных журналов видно, что Вас сканируют, но невозможно определить кто. Еще более тревожным является тот факт, что большинство систем (включая Linux с новыми ядрами) не фиксируют эти ошибки в журналах. Как сказал Fyodor "... основываясь на сообщениях 'connection reset by peer'. Эта особенность Linux 2.0.XX, практически все остальные системы (включая ядра 2.2 и поздние ядра 2.1) не показывают ничего. Ошибка (accept(), возвращающий управление до завершения трехшагового процесса установления соединения) исправлена." Nmap имеет и другие опции для осуществления скрытого сканирования, такие как -sF, -sX, -sN, использующие различные флаги. Вот так выглядят регистрационные журналы после такого сканирования: /var/log/secure И снова, обратите внимание, что журналы пусты! Страшно подумать, Вы просканированы, но даже не подозреваете об этом! Все три типа сканирования дают одинаковые результаты, но Вы можете зафиксировать только первый - с опцией -sT (полное соединение). Чтобы обнаружить факты скрытного сканирования, Вам придется использовать специальные средства регистрации, такие как tcplogd или ippl. Некоторые коммерческие межсетевые экраны также могут обнаруживать и фиксировать попытки такого сканирования, в частности IPFilter, SunScreen или FireWall-1. Получили ли они доступ?После того, как Вы определили факт сканирования, следующий вопрос, которым Вы задаетесь "Смогли ли они проникнуть внутрь?" Большинство современных эксплоитов основано на переполнении буфера (известном также как срыв стека). Говоря простым языком, переполнение буфера возникает, когда программа (как правило, демон) получает на вход данные большего размера, чем ожидалось, перезаписывая критичные области памяти. В результате выполняется некоторый код, дающий права привилегированного пользователя (root). Дополнительную информацию о переполнении буфера можно найти в прекрасной статье (автор - Aleph1) по адресу ftp://ftp.technotronic.com/rfc/phrack49-14.txt. Обычно следы атак на переполнение буфера можно обнаружить в файле /var/log/messages (или /var/adm/messages для других разновидностей Unix) для атак типа mountd. Вы также можете обнаружить аналогичные следы в файле maillog, если атака осуществлена на imapd. В регистрационных журналах это выглядит так:
Apr 14 04:20:51 mozart mountd[6688]: Unauthorized access by NFS client 192.168.11.200. Если Вы видите нечто подобное в Ваших регистрационных журналах, это означает, что кто-то пытался использовать уязвимость Вашей системы. Очень сложно определить, была ли попытка эксплоита успешной. Один из путей сделать это - сразу после попытки применения эксплоита посмотреть, нет ли соединений удаленной системы с Вашей. Если имеет место успешный вход из удаленной системы, то попытка применения эксплоита оказалась удачной. Другой признак - появление новых пользователей типа "moof", "rewt", "crak0" или "w0rm" в файле /etc/passwd. Эти пользователи (с UID=0) добавляются многими распространенными сценариями-эксплоитами. Как только черная шляпа получила доступ к Вашей системе, первая вещь, которую она обычно делает - это очистка регистрационных журналов и установка "троянизированной" подсистемы регистрации (см. "Они получают права root"). С этого момента Вы не сможете получать регистрационную информацию от Вашей системы, так как все уже скомпрометировано. Что делать дальше, является темой отдельной статьи :). А тем временем я рекомендую Вам изучить документ http://www.cert.org/nav/recovering.html Чтобы облегчить себе процесс поиска аномалий в регистрационных журналах, я написал специальный сценарий (см. ниже), который осуществляет проверку журналов. Дополнительную информацию по разбору и сортировке журналов можно получить из письма, опубликованного Маркусом Ранумом.
ЗаключениеРегистрационные журналы Вашей системы могут очень много рассказать о Вашем противнике. Однако, первым шагом должно стать обеспечение их целостности. Одним из лучших решений этой проблемы является организация выделенного log-сервера, собирающего регистрационную информацию со всех систем. После того, как журналы защищены, Вы можете использовать их для поиска в них характерных последовательностей. На базе этой информации Вы сможете определить, какие цели преследует черная шляпа и, возможно, какими средствами она пользуется. Полученные сведения помогут Вам наилучшим образом организовать защиту Вашей системы.
|
 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
