DoS — это не операционная система
Алексей Лукацкий
заместитель технического директора Научно-инженерного предприятия "Информзащита",
luka@infosec.ru
В предыдущих двух статьях (см. "BYTE/Россия" №3 и 5'2001) мы уже рассказывали о способах обнаружения различной несанкционированной деятельности — троянских коней, сканирования портов и узлов, удаленной идентификации узлов. Теперь пора поговорить и о другой, не менее известной и распространенной враждебной активности — атаках типа "отказ в обслуживании" (Denial of Service, DoS). Поскольку данная тема весьма обширна, мы рассмотрим только несколько классов атак этого типа.
Суть первого из них заключается в посылке большого количества пакетов на заданный узел сети (цель атаки), что может привести к выведению этого узла из строя, поскольку он "захлебнется" в лавине посылаемых пакетов и не сможет обрабатывать запросы авторизованных пользователей. По такому принципу действуют атаки SYN Flood, Smurf, UDP Flood, Targa3 и т.д. Самая известная из них — это SYN Flood, с помощью которой хакер Кевин Митник атаковал компьютер специалиста по защите информации Цутому Шимомуры. В атаке этого типа злоумышленник посылает запрос на установление соединения (посылка SYN-пакета) с атакуемым узлом. Реализация большого числа таких запросов за короткое время приведет к тому, что очередь узла, с которым устанавливается соединение, будет переполнена и он не сможет принимать новые запросы. В атаке Митника против Шимомуры переполнение произошло после восьми запросов к сервису login, "висящему" на 513-м порту (как и в предыдущих статьях, большинство примеров иллюстрируется фрагментами листингов утилиты TCPdump).
|
Атака SYN Flood (фрагмент журнала TCPdump) 14:18:22.516699 WS_LUKA.600 > WS_LUKICH.login: S 1382726960:1382726960(0) win 4096 14:18:22.566069 WS_LUKA.601 > WS_LUKICH.login: S 1382726961:1382726961(0) win 4096 14:18:22.744477 WS_LUKA.602 > WS_LUKICH.login: S 1382726962:1382726962(0) win 4096 14:18:22.830111 WS_LUKA.603 > WS_LUKICH.login: S 1382726963:1382726963(0) win 4096 14:18:22.886128 WS_LUKA.604 > WS_LUKICH.login: S 1382726964:1382726964(0) win 4096 14:18:22.943514 WS_LUKA.605 > WS_LUKICH.login: S 1382726965:1382726965(0) win 4096 14:18:23.002715 WS_LUKA.606 > WS_LUKICH.login: S 1382726966:1382726966(0) win 4096 14:18:23.103275 WS_LUKA.607 > WS_LUKICH.login: S 1382726967:1382726967(0) win 4096 14:18:23.162781 WS_LUKA.608 > WS_LUKICH.login: S 1382726968:1382726968(0) win 4096 14:18:23.225384 WS_LUKA.609 > WS_LUKICH.login: S 1382726969:1382726969(0) win 4096 14:18:23.282625 WS_LUKA.610 > WS_LUKICH.login: S 1382726970:1382726970(0) win 4096 14:18:23.342657 WS_LUKA.611 > WS_LUKICH.login: S 1382726971:1382726971(0) win 4096 14:18:23.403083 WS_LUKA.612 > WS_LUKICH.login: S 1382726972:1382726972(0) win 4096 14:18:23.903700 WS_LUKA.613 > WS_LUKICH.login: S 1382726973:1382726973(0) win 4096 14:18:24.003252 WS_LUKA.614 > WS_LUKICH.login: S 1382726974:1382726974(0) win 4096 |
Данная атака имеет особенность, которая не позволяет слепо копировать шаблон ее обнаружения на все без исключения порты. Если для сервиса login действительно имеет место атака, то, например, для сервиса HTTP (80-й порт по умолчанию) это уже не так. Дело в том, что браузер Microsoft Internet Explorer на каждый загружаемый файл с расширением JPG, GIF, HTML создает новое соединение с Web-сервером. Таким образом, загрузка HTML-странички с десятью картинками означает открытие 11 соединений, что при неполном понимании может быть принято за атаку типа SYN Flood.
|
Ложное обнаружение атаки SYN Flood (фрагмент журнала TCPdump) 14:18:22.516699 WS_LUKA.600 > WS_LUKICH.80: S 1382726960:1382726960(0) win 4096 14:18:22.566069 WS_LUKA.601 > WS_LUKICH.80: S 1382726961:1382726961(0) win 4096 14:18:22.744477 WS_LUKA.602 > WS_LUKICH.80: S 1382726962:1382726962(0) win 4096 14:18:22.830111 WS_LUKA.603 > WS_LUKICH.80: S 1382726963:1382726963(0) win 4096 14:18:22.886128 WS_LUKA.604 > WS_LUKICH.80: S 1382726964:1382726964(0) win 4096 14:18:22.943514 WS_LUKA.605 > WS_LUKICH.80: S 1382726965:1382726965(0) win 4096 14:18:23.002715 WS_LUKA.606 > WS_LUKICH.80: S 1382726966:1382726966(0) win 4096 14:18:23.103275 WS_LUKA.607 > WS_LUKICH.80: S 1382726967:1382726967(0) win 4096 14:18:23.162781 WS_LUKA.608 > WS_LUKICH.80: S 1382726968:1382726968(0) win 4096 14:18:23.225384 WS_LUKA.609 > WS_LUKICH.80: S 1382726969:1382726969(0) win 4096 14:18:23.282625 WS_LUKA.610 > WS_LUKICH.80: S 1382726970:1382726970(0) win 4096 |
Действие другого класса атак типа "отказ в обслуживании" заключается в некорректном использовании данных, описанных в заголовке сетевого пакета (в частности, адресов получателя и отправителя и номеров портов). Например, атака Smurf обнаруживается по использованию широковещательных пакетов, передаваемых в течение длительного времени по протоколу ICMP. Известны случаи, когда такие пакеты передавались в течение нескольких дней, в результате чего атакуемая сеть оказывалась неспособна обрабатывать санкционированный трафик. Ниже приведены фрагменты журнала регистрации TCPdump и маршрутизатора Cisco, в которых зафиксированы примеры атак Smurf и Fraggle (аналог Smurf для протокола UDP).
|
Обнаружение атаки Smurf (фрагмент журнала TCPdump) 02:31:06.162135 172.20.20.1 > 200.0.0.255: icmp: echo request 02:31:06.597051 172.20.20.1 > 200.0.0.255: icmp: echo request 02:31:06.986372 172.20.20.1 > 200.0.0.255: icmp: echo request 02:31:07.162839 172.20.20.1 > 200.0.0.255: icmp: echo request Обнаружение атак Smurf и Fraggle (фрагмент журнала Dec 22 16:15:26: %SEC-6-IPACCESSLOGDP: list Internet denied icmp 172.20.20.1 -> 200.0.0.255 (8/0), 1 packet Dec 22 16:16:26: %SEC-6-IPACCESSLOGDP: list Internet denied icmp 172.20.20.2 -> 200.0.0.255 (8/0), 24 packets Dec 22 16:16:56: %SEC-6-IPACCESSLOGP: list Internet denied udp 172.20.20.3(21820) -> 200.0.0.255 (19), 1 packet Dec 22 16:26:26: %SEC-6-IPACCESSLOGDP: list Internet denied icmp 172.20.20.4 -> 200.0.0.255 (8/0), 3 packets Dec 22 16:27:26: %SEC-6-IPACCESSLOGDP: list Internet denied icmp 172.20.20.5 -> 200.0.0.255 (8/0), 4 packets |
Существует и еще одна атака, очень похожая на Smurf. Это предварительные действия перед атакой (network mapping), которые заключаются в широковещательном запросе активности узлов, выбираемых в дальнейшем в качестве цели атаки. Частный пример таких действий — сканирование отдельных узлов атакуемой сети, описанное в предыдущей статье (см. "BYTE/Россия" №5'2001) .
|
Обнаружение Network Mapping (фрагмент журнала TCPdump) 00:43:58.094644 pinger.mappem.com > 200.0.0.255: icmp: echo request 00:43:58.604889 pinger.mappem.com > 200.0.0.0: icmp: echo request 00:50:02.297035 pinger.mappem.com > 200.0.1.255: icmp: echo request 00:50:02.689911 pinger.mappem.com > 200.0.1.0: icmp: echo request 00:54:56.911891 pinger.mappem.com > 200.0.2.255: icmp: echo request 00:54:57.265833 pinger.mappem.com > 200.0.2.0: icmp: echo request 00:59:52.822243 pinger.mappem.com > 200.0.3.255: icmp: echo request 00:59:53.415182 pinger.mappem.com > 200.0.3.0: icmp: echo request |
Отличие от атаки Smurf заключается в использовании реального адреса источника широковещательных пакетов, систематическом увеличении номеров подсетей для анализа активности входящих в них узлов и времени, затрачиваемого на обработку ответов на посланные запросы (echo reply).
Другим признаком атак типа "отказ в обслуживании" рассматриваемого класса могут служить неправильные адреса, заданные в полях "адрес получателя" или "адрес отправителя". Например, атака Land обнаруживается по совпадению этих адресов в одном пакете.
|
Обнаружение атаки Land (фрагмент журнала TCPdump) 10:56:32.395383 200.0.0.104.139 > 200.0.0.104.139: S 10:56:35.145383 200.0.0.104.139 > 200.0.0.104.139: S 10:56:36.265383 200.0.0.104.139 > 200.0.0.104.139: S |
Кстати, различные системы обнаружения атак используют различные сигнатуры для атаки Land. Например, в Cisco Secure IDS пакет признается враждебным, если в нем совпадают только адреса получателя и отправителя, а в системе RealSecure Network Sensor совпадать должны не только адреса, но и порты получателя и отправителя.
Примером атаки, некорректно использующей порты отправителя и получателя, служит Chargen (некоторые специалисты называют эту атаку Echo или Echo-Chargen). Эта атака использует особенности реализации IP-сервисов Echo и Chargen, вследствие которых посылка пакетов с порта 19 (Chargen) на порт 7 (Echo) приводит к зацикливанию, и все доступные ресурсы атакуемых компьютеров используются для обработки бесконечного цикла. При этом вместо порта 7 может быть атакован любой порт, автоматически отвечающий на любой направленный на него запрос (к таким относятся порты 13 (daytime), 37 (time) и т.д.).
|
Обнаружение атаки Chargen или Echo (фрагмент журнала TCPdump) 08:08:16.155354 200.0.0.200.echo > 200.0.0.104.chargen: udp |
При анализе сетевого трафика необходимо обращать внимание на поле IP Options заголовка пакета. Это поле достаточно редко используется в обычной жизни, и появление в сети пакетов с информацией в нем может свидетельствовать о нестандартной ситуации. Это поле может служить для изучения маршрута следования пакетов (source routing) или для реализации атак типа "отказ в обслуживании". Например, 20 октября 1999 года в Bugtraq появилось сообщение о том, что модуль анализа IP-пакетов межсетевого экрана Raptor 6.0 компании Symantec неправильно обрабатывает поле IP Options, в результате чего он может быть выведен из строя, и только перезагрузка компьютера с межсетевым экраном возвращает Raptor в нормальное состояние. И хотя эта уязвимость позже была устранена, факт остается фактом.
|
Обнаружение атаки на межсетевой экран Raptor 6.0 13:07:52 10.0.0.1.www > target.net.61374:
P 2018915346:2018915378(32) ack 558065031 win 8192
[tos 0x32] (ttl 255, id 48879, optlen=4[|ip op len 0])
4632 004c beef 0000 ff06 a222 0a00 0001 0a01 0165 4400 0001
0050 efbe 7856 3412
2143 6587 5018 2000 5724 0000 0000 0000 0000 0000 0000
|
Следующий признак атак типа "отказ в обслуживании" — использование широко известных уязвимых мест. Например, посылка ICMP-пакетов с типом 13 (TimeStamp) на узел с установленной ОС Microsoft Windows 98 вследствие некорректной реализации стека TCP/IP в этой ОС может привести к "зависанию" узла и появлению "голубого экрана".
|
Использование уязвимости стека TCP/IP в ОС Windows 98 14:07:44 200.0.0.200 > win98.net: icmp: time stamp request 4500 0028 0100 0000 ff01 fec3 336f 7d3c 0a01 0165 0d00 bdb5 ffff ffff 8b52 2dee 99dd ec91 73a3 81f6 |
Наличие еще одного уязвимого места (Win IGMP) в реализации TCP/IP-стека в Windows 98 также может привести к появлению "голубого экрана" в том случае, если в сети по протоколу маршрутизации IGMP передаются фрагментированные пакеты.
|
Использование уязвимости стека TCP/IP в Windows 98/2000 13:20:12 200.0.0.200 > target.net: igmp-2[|igmp] (frag 17664:1480@0+) 13:20:12 200.0.0.200 > target.net: igmp-2[|igmp] (frag 17664:1480@1480+) 13:20:12 200.0.0.200 > target.net: igmp-2[|igmp] (frag 17664:1480@5920+) 13:20:12 200.0.0.200 > target.net: igmp-2[|igmp] (frag 17664:811@7400) |
Упомянув фрагментированный трафик, нельзя не сказать, что во многих случаях он служит признаком, позволяющим распознать атаку. Многие средства сетевой безопасности (маршрутизаторы с функцией контроля доступа, межсетевые экраны, системы обнаружения атак и т.д.) не умеют правильно собирать фрагментированные пакеты, что приводит или к выходу их из строя, или к пропуску таких пакетов внутрь защищаемой сети. Первое происходит в случае фрагментов с неправильным смещением, а второе — в результате так называемой атаки tiny fragment. При такой атаке создается два TCP-фрагмента: первый из них настолько мал, что даже не включает полного TCP-заголовка, особенно порта получателя. Второй фрагмент содержит остаток заголовка. Многие межсетевые экраны пропускают первый фрагмент или оба внутрь корпоративной сети.
|
Атака Tiny Fragment (фрагмент журнала TCPdump) 06:25:55.315 [|tcp] (frag 38783:16@0+) 06:25:55.315 WS_LUKA > WS_LUKICH: (frag 38783:4@16) 06:25:55.315 [|tcp] (frag 16422:16@0+) 06:25:55.315 WS_LUKA > WS_LUKICH: (frag 16422:4@16) 06:25:55.315 [|tcp] (frag 43143:16@0+) 06:25:55.315 WS_LUKA > WS_LUKICH: (frag 43143:4@16) 06:25:55.315 [|tcp] (frag 18544:16@0+) 06:25:55.315 WS_LUKA > WS_LUKICH: (frag 18544:4@16) 06:25:55.315 [|tcp] (frag 8231:16@0+) 06:25:55.315 WS_LUKA > WS_LUKICH: (frag 8231:4@16) 06:25:55.315 [|tcp] (frag 45846:16@0+) 06:25:55.315 WS_LUKA > WS_LUKICH: (frag 45846:4@16) 06:25:55.315 [|tcp] (frag 6245:16@0+) 06:25:55.315 WS_LUKA > WS_LUKICH: (frag 6245:4@16) |
Нотация [|tcp] указывает на то, что утилита TCPdump не смогла захватить весь TCP-заголовок и интерпретировать назначение пакета.
Однако самый известный пример атаки, использующей фрагментированные пакеты, — это Ping of Death. Принцип ее действия заключается в посылке ICMP-пакета длиной более 65 535 байтов (максимальный размер IP-пакета).
|
Обнаружение атаки Ping of Death (фрагмент журнала TCPdump) 12:43:58.431 WS_LUKICH > 200.0.0.104: icmp: echo request (frag 4321:380@0+) 12:43:58.431 WS_LUKICH > 200.0.0.104: icmp: echo request (frag 4321:380@2656+) 12:43:58.431 WS_LUKICH > 200.0.0.104: icmp: echo request (frag 4321:380@3040+) 12:43:58.431 WS_LUKICH > 200.0.0.104: icmp: echo request (frag 4321:380@3416+) 12:43:58.431 WS_LUKICH > 200.0.0.104: icmp: echo request (frag 4321:380@376+) 12:43:58.431 WS_LUKICH > 200.0.0.104: icmp: echo request (frag 4321:380@3800+) 12:43:58.431 WS_LUKICH > 200.0.0.104: icmp: echo request (frag 4321:380@4176+) 12:43:58.431 WS_LUKICH > 200.0.0.104: icmp: echo request (frag 4321:380@760+) ... 12:43:58.491 WS_LUKICH > 200.0.0.104: icmp: echo request (frag 4321:380@63080+) 12:43:58.491 WS_LUKICH > 200.0.0.104: icmp: echo request (frag 4321:380@63456+) 12:43:58.491 WS_LUKICH > 200.0.0.104: icmp: echo request (frag 4321:380@63840+) 12:43:58.491 WS_LUKICH > 200.0.0.104: icmp: echo request (frag 4321:380@64216+) 12:43:58.491 WS_LUKICH > 200.0.0.104: icmp: echo request (frag 4321:380@64600+) 12:43:58.491 WS_LUKICH > 200.0.0.104: icmp: echo request (frag 4321:380@64976+) 12:43:58.491 WS_LUKICH > 200.0.0.104: icmp: echo request (frag 4321:380@65360) |
Длина данного сообщения, состоящего из множества фрагментов, составляет 65 740 (380+65 360) байтов. Еще одна проблема, связанная с фрагментированными пакетами, заключается в том, что длина передаваемого фрагмента должна быть кратна 8, что в приведенном примере не соблюдается (длина фрагмента 380 байт). Некоторые сетевые устройства или программы "не умеют" правильно собирать фрагменты нестандартного размера, что приводит к выходу их из строя.
В заключение хочу остановиться на распределенных атаках, которые существенно усложняют защиту корпоративной сети. Дело здесь в том, что если пропускная способность канала до цели атаки превышает пропускную способность атакующего, то традиционная атака типа "отказ в обслуживании" (UDP Bomb, ICMP Flood и т.д.) не будет успешной. Распределенная же атака происходит уже не из одной точки Интернета, а сразу из нескольких, что приводит к резкому возрастанию трафика и выведению атакуемого узла из строя. Злоумышленник может послать большой объем данных сразу со всех узлов, задействованных в распределенной атаке. Атакуемый узел захлебнется огромным трафиком и не сможет обрабатывать запросы от нормальных пользователей. Именно так были реализованы нашумевшие атаки в начале февраля 2000 года.
При обычной реализации аналогичной атаки необходимо иметь достаточно "толстый" канал доступа в Интернет, чтобы отправить лавину пакетов на атакуемый узел. В случае же распределенной атаки это условие перестает быть необходимым: достаточно иметь dialup-соединение с Интернетом. Принцип же лавины или шторма пакетов достигается за счет большого числа таких относительно медленных соединений.
Приведем пример: по данным "Россия-Онлайн" в течение двух суток, начиная с 9 часов утра 28 декабря 2000 г., крупнейший Интернет-провайдер Армении "Арминко" подвергался распределенной атаке. Суть ее состояла в том, что хакер, обнаружив слабо защищенный сервер, с помощью особой программы принудил его к выдаче бессмысленной информации по любому компьютерному адресу. В данном случае к атаке подключилось более 50 машин из разных стран, которые посылали по адресу "Арминко" бессмысленные сообщения. Кто организовал эту атаку и в какой стране находился хакер, установить не удалось. Хотя атаке подверглась в основном "Арминко", перегруженной оказалась вся магистраль, соединяющая Армению со Всемирной паутиной. 30 декабря благодаря сотрудничеству другого провайдера, "АрменТел", связь была полностью восстановлена. Несмотря на это, компьютерная атака продолжалась, но с меньшей интенсивностью.
Распределенные атаки (например, TFN) можно обнаружить по номерам используемых портов. Кроме того, признаком атаки может служить большое число сетевых пакетов, передаваемых на заданный узел с сотен и тысяч узлов.
|
Обнаружение атаки TFN (фрагмент журнала TCPdump) 17:25:21.369 251.244.87.90 > 200.0.0.104: icmp: echo request 17:25:21.389 91.105.122.14 > 200.0.0.104: icmp: echo request 17:25:21.409 74.120.20.9 > 200.0.0.104: icmp: echo request 17:25:21.429 134.136.57.119 > 200.0.0.104: icmp: echo request 17:25:21.449 167.114.59.72 > 200.0.0.104: icmp: echo request 17:25:21.469 119.45.18.39 > 200.0.0.104: icmp: echo request 17:25:21.489 99.76.37.50 > 200.0.0.104: icmp: echo request 17:25:21.509 227.172.27.94 > 200.0.0.104: icmp: echo request 17:25:21.529 103.233.187.43 > 200.0.0.104: icmp: echo request 17:25:21.549 40.93.8.52 > 200.0.0.104: icmp: echo request 17:25:21.569 2.32.117.59 > 200.0.0.104: icmp: echo request |