Обнаружение использования уязвимостей
Как уже упоминалось в главе 2, на этапе сбора информации и реализации атаки (1 и 2 этапы соответственно) злоумышленники ищут и задействуют найденные уязвимости. Проиллюстрировать обнаружение использования всех уязвимостей в одной книге невозможно, и поэтому я остановлюсь только на некоторых из них. Например, уязвимости Web-сервера (в данном случае HTTP Glimpse cgi-bin и HTTP test-cgi) могут быть обнаружены путем анализа записей журнала регистрации сервера (см. выше) или при помощи системы анализа трафика.
Другой пример связан со слабым местом в реализаций IР-стека в ОС Windows 98. Посланные ICMP-пакеты с типом 13 (TimeStamp) (листинг 5.26)
содержат в поле данных определенные значения номера последовательности и идентификация (Oxffff) (листинг 5.27).
Они приводят к "зависанию" узла и появлению "голубого экрана". Для обнаружения этой атаки своими силами (точнее средствами TCPdump) достаточно применить небольшой фильтр:
(icmp[0]=13) and (iсmр[1]=0) and (icmp[4:2]=0xffff) and
(icmp[6:2]=0xffff)
Еще одна уязвимость (Win IGMP) реализации TCP/IP-стека в ОС Windows 98 также влекла появление "голубого экрана" в случае возникновения в сети фрагментированных пакетов, передаваемых по протоколу маршрутизации IGMP (листинг 5.28).
Единственной мерой отражения этой атаки является запрет передачи по сети фрагментированных IGMP-пакетов. Обнаружить такого рода пакеты достаточно легко:
iqmp and ( (iр[6:1]&0х20) = 0) or (ip[6:2]&0x1fff ]= 0))
Обнаружение "троянских коней"
Одним из основных способов обнаружения работы "троянских коней" является анализ определенных портов (контроль обращений или выявление открытого порта). По такому принципу можно опознать абсолютное большинство "троянцев", в которых жестко "защиты" номера используемых портов. В том случае, если "троян" использует нестандартные порты, то обнаружить его можно либо по ключевым словам в сетевом трафике, например, по получаемым и отправляемым командам. Вторым способом обнаружения "троянских коней" является анализ конфигурации системы (системного реестра, файлов автозагрузки или запущенных процессов).
Ниже показаны несколько примеров обнаружения широко известного "троянского коня" SubSeven (листинги 5.29—5.35), который обычно соединяется через порт 1243 (или 27374 в версии 2.1).
"Троянский конь" Satans использует для соединения "число зверя" 666 (аналогичный номер порта в ходу и у "троянца" BackConstruction). При этом Satans можно "вычислить" еще и по наличию запущенной программы WinVMM32 (листинг 5.36).
"Троянский конь" BackOrifice "общается" с владельцем через Порт 31337, и в ОС может "наследить" в системном реестре в разделе HKLM \ Software \ Microsoft \ Windows \ CurгentVeгsion \ RunSeгvices (листинги 5.37, 5.38).
Как уже отмечалось выше, "троянские кони" могут быть обнаружены не только путем анализа обращений к определенным портам, но и посредством слежения за появлением в сетевом трафике ключевых слов. Например, троянец "Back Orifice" может быть обнаружен по сигнатуре пароля "се 63 d1 d2 16 е7 f2 cf т.е. первых 8-ми байтах поля данных UDP-пакета (листинг 5.39).
В главе 2 упоминалось, что помимо классических атак, построенных в соответствии с моделью "один-к-одному" или "один-ко-многим", существуют новые, так называемые распределенные атаки, соответствующие моделям "многие-к-одному" и "многие-ко-многим". По этому принципу сконструированы некоторые "троянские кони", например, WinTrinoo (листинг 5.40), TFN2K, Stacheldraht, mstream (листинг 5.41) и т. д., которые также могут быть выявлены по номерам используемых портов.
Обнаружение атак "отказ в обслуживании"
Атаки типа "отказ в обслуживании" могут быть обнаружены так же просто, как и другие типы несанкционированной деятельности. Например, атака SMURF характеризуется использованием широковещательных пакетов, передаваемых в течение длительного времени. Известны случаи, когда пакеты посылались в течение нескольких дней, приводя атакуемую сеть к неспособности обрабатывать санкционированный трафик. Ниже показаны фрагменты журналов регистрации TCPdump (листинг 5.42) и маршрутизатора Cisco (листинг 5.43), в которых зафиксированы примеры атак Smurf Fraggle (аналог Smurf, но для протокола UDP). В реальной практике число таких случаев давно превысило первую сотню.
Примером фильтра TCPdump, позволяющим обнаруживать атаку Smurf, является:
icmp and (ip[19] = 0xff) and (icmp[0] = 8)
Необходимо заметить, что существует еще одна атака, очень похожая на Smurf. Это — предварительные действия перед атакой (network mapping), которые заключаются в широковещательном запросе активности узлов, которые в дальнейшем будут выбраны в качестве цели атаки (листинг 5.44). Частным примером данных действий является сканирование отдельных узлов атакуемой сети, описываемое выше.
Отличие от атаки Smurf состоит в использовании реального адреса источника широковещательных пакетов, систематическом увеличении номеров подсетей для анализа активности входящих в них узлов и времени, затрачиваемого на обработку ответов на посланные запросы (echo reply).
Другим признаком атак типа "отказ в обслуживании" могут служить неправильные адреса, заданные в полях "Адрес получателя" или "Адрес отправителя". Например, атака Land обнаруживается по совпадению этих адресов одном пакете (листинг 5.45).
Для фильтрации сетевого трафика, перехватываемого утилитой TCPdump можно воспользоваться фильтром:
iр[12:4] = ip[16:4] или tcp and (ip[12:4] = ip[16:4]) and (tcp[0:2] = tcp[2:2])
Первый фильтр отслеживает только те пакеты, в которых идентичны только адреса получателя и отправителя, а второй — обнаруживает пакеты с совпадением не только этих адресов, но и портов источника и приемника. Кстати, различные системы обнаружения атак используют разные сигнатуры для атаки Land. Например, если Cisco Secure IDS оперирует только адресами передающей и принимающей системы, то система RealSecure Network Sensor — еще и портами отправителя и получателя.
Следующим признаком атак "отказ в обслуживании" являются широко известные уязвимости, часть которых уже была рассмотрена выше (Win IGMP и т. д.). Помимо уязвимостей реализации существуют и уязвимости проектирования. Например, широко известная атака Chargen (или Echo), которая ориентируется на особенность реализации IP-сервисов Echo и Chargen, вследствие которых посылка пакетов с порта 19 (Chargen) на порт 7 (Echo) приводит к зацикливанию и выделению всех доступных ресурсов атакуемых компьютеров для обработки бесконечного цикла (листинг 5.46).
При этом вместо 7-го порта может быть атакован любой порт, автоматически отвечающий на любой запрос, направленный на него. К. таким пор относятся 13 (daytime), 37 (time) и т. д. Фильтр, обнаруживающий такие атаки, выглядит следующим образом:
udp and (((port 7) and (port 13)) or ((port 7) and (port 19)) or ((port 7) and (port 37)) or ((port 13) and (port 19)) or ((port 13) and (port 37)) or ((port 19) or (port 37)) or ((srcport 7) and (dst port 7)) or ((src port 13) and (dst port 13)) or ((src port 19) and (dst port 9)) or ((src port 37) and (dst port 37)))
или (в тем случае, если доступ к этим портам извне запрещен):
udp and (port 7 or port 13 or port 19 or port 37)
При анализе сетевого трафика необходимо обращать внимание на поле IP Options заголовка пакета. Это поле достаточно редко используется в обычной жизни, и появление в сети пакетов с информацией в данном поле может свидетельствовать о "нештатной" ситуации. Данное поле может быть задействовано злоумышленником для изучения маршрута следования пакетов (source routing) или для реализации атак типа "отказ в обслуживании". Например, 20 октября 1999 года в Bugtraq было опубликовало сообщение о том, что модуль анализа IP-пакетов межсетевого экрана Raptor 6.0 неправильно обрабатывает поле IP Options, в результате чего экран может быть выведен из строя и только перезагрузка компьютера с межсетевым экраном возвращает Raptor в нормальное состояние. И хотя эта уязвимость позже была устранена, факт остается фактом.
Выше я уже упоминал, что обнаружить распределенные атаки (например, TFN) можно по номерам используемых портов. Это отчетливо прослеживается в выдержке из журнала регистрации TCPdump, приведенной в листинге 5.48. Кроме этого, в качестве признака атаки может выступать большое число сетевых пакетов, передаваемых на заданный узел с сотен и тысяч узлов.
В заключение данного раздела хочу остановиться еще на одном типе атак типа "отказ в обслуживании" — атаках, связанных с фрагментацией. Наиболее известным примером такой атаки является Ping of Death, принцип действия которой заключается в посылке ICMP-пакета длиной более 65 500 байтов (максимального размера IP-пакета) (листинг 5.49).
Длина этого сообщения, состоящего из множества фрагментов, составляет 65740 (380+65360) байтов. Другая проблема, связанная с фрагментированными пакетами, заключается в том, что длина передаваемого фрагмента должна быть кратна 8, что в вышеприведенном примере, как это легко увидеть, не соблюдается (размер фрагмента 380 байтов). Некоторые сетевые устройства или программы "не умеют" правильно собирать фрагменты с нестандартным размером, что приводит к выходу их из строя.