Виды DoS-атак
Теперь пора поговорить и о другой, не менее известной и распространенной враждебной активности - атаках типа "отказ в обслуживании" (Denial of Service, DoS). Поскольку данная тема весьма обширна, мы рассмотрим только несколько классов атак этого типа.
Суть первого из них заключается в посылке большого количества пакетов на заданный узел сети (цель атаки), что может привести к выведению этого узла из строя, поскольку он "захлебнется" в лавине посылаемых пакетов и не сможет обрабатывать запросы авторизованных пользователей. По такому принципу действуют атаки SYN FloodSmurf, UDP Flood, Тarga3 и т. д. Самая известная из них - это SYN Flood, с помощью которой хакер Кевин Митник атаковал компьютер специалиста по защите информации Цутому Шимомуры. В атаке этого типа злоумышленник посылает запрос на установление соединения (посылка SYN-пакета) с атакуемым узлом. Реализация болцшого числа таких запросов за короткое время приведет к тому, что очередь узла, с которым устанавливается соединение, будет переполнена и он не сможет принимать новые запросы. В атаке Митника против Имомуры переполнение произошло после восьми запросов к сервису 1оgin, "висящему" на 513-м порту (как и в предыдущих статьях, большинство примеров иллюстрируется фрагментами листингов утилиты ТСРdump).
Атака SYN Flood; (фрагмент журнала ТСРdump)
14:18:22.516699 WS_LUKA.600 >
WS_LUKICH.1оgin: 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 )
МS_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
листинг можно продлжить...
Данная атака имеет особенность, которая не позволяет слепо копировать шаблон ее обнаружения на все без исключения порты. Если для сервиса 1оgin действительно имеет место атака, то, например, для сервиса НТТР (80-й порт по умолчанию) это уже не так. Дело в том, что браузер Microsoft Internet Ехр1оrer на каждый загружаемый файл с расширением JPG, GIF, НТМL создает новое соединение с Web-сервером. Таким образом, загрузка НТМL-странички с десятью картинками означает открытие 11 соединений, что при неполном понимании может быть принято за атаку типа SYN Flood.
Ложное обнаружение атаки SYN Flood (фрагмент журнала ТСРdump)
14:18:22.516699
WS_LUKA.600 > WS_LUKICH.80: S
1382726960:1382726960(0)
14:18:22.566069
WS_LUKA.601 ) WS_LUKICH.80: S
1382726961:1382726961(0)
14:18:22 744477
WS_LUKA.602 ) WS_LUKICH.80: S
1382726962:1382726962(0)
14:18:22.830111
WS_LUKA.603 > WS_LUKICH.80: S
1382726963:1382726963(0)
14:18:22.886128
WS_LUKA.604 > WS_LUKICH.80: S
1382726964:1382726964(0)
14:18:22.943514
WS_LUKA.605 ) WS_LUKICH.80: S
1382726965:1382726965(0)
14:18:23.002715
WS_LIKA.606 > WS_LUKICH.80: S
1382726966:1382726966(0)
14:1823.103275
WS_LUKA.607 ) WS_LUKICH.80: S
1382726967:1382726967(0)
14:18:23.162781
WS_LUKA.608 ) WS_LUKICH.80: S
1382726968:1382726968(0)
Действие другого класса атак типа <отказ в обслуживании> заключается в некорректном использовании данных, описанных в заголовке сетевого пакета (в частности, адресов получателя и отправителя и номеров портов). Например, атака Smurf обнаруживается по использованию широковещательных пакетов, передаваемых в течение длительного времени по протоколу IСМР. Известны случаи, когда такие пакеты передавались в течение нескольких дней, в результате чего атакуемая сеть оказывалась неспособна обрабатывать санкционированный трафик. Ниже приведены фрагменты журнала регистрации ТСРdump и маршрутизатора Сisco, в которых зафиксированы примеры атак Smurf и Рraggle (аналог Smurf для протокола UDP).
Обнаружение атаки Smurf (фрагмент журнала ТСРdump)
02:31:06.162135 172.20.20.1 > 200.0.0.255: icmp: есho 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: еcho request
02:31:07.162839 172.20.20.1 > 200.0.0.255: icmp: еcho request
Обнаружение атак Smurf и Fraggle(фрагмент журнала маршрутизатора Сisco)
Dec 22 16:15:26: %SEC-6-IPACCESSLODP: list internet
denied icmp 172.20.20.1 -> 200.0.0.255 (8/0), 1 packet
Dec 22 16:16:26: %SEC-6-IPACCESSLODP: list internet
denied icmp 172.20.20.2 -> 200.0.0.255 (8/0), 24 packets
Dec 22 16:16:56: %SEC-6-IPACCESSLODP: list internet
denied icmp 172.20.20,3(21820) -> 200.0.0.255 (19), 1 packet
Dec 22 16:26:26: %SEC-6-IPACCESSLODP: list internet
denied icmp 172.20.20.4 -> 200.0.0.255 (8/0), 3 packets
Dec 22 16:27:26: %SEC-6-IPACCESSLODP: list internet
denied icmp 172.20.20.5 -> 200.0.0.255 (8/0), 4 packets
Существует и еще одна атака, очень похожая на Smurf. Это предварительные действия перед атакой (network mapping), которые заключаются в широкoвещательном запросе активности узлов, выбираемых в дальнейшем в качестве цели атаки. Частный пример таких действий - сканирование отдельных узлов атакуемой сети, описанное в предыдущей статье (см. <ВУТE Россия> #5'2001).
Обнаружение Network Mapping (фрагмент журнала ТСРdump)
00:43:58.094644 pinger.mapper.com > 200.0.0.255: icmp: echo request
00:43:58.604889 pinger.mapper.com> 200.0.0.0: icmp: echo request
00:50:02.297035 pinger.mapper.com > 200.0.1.255: icmp: echo request
00:50:02.689911 pinger.mapper.com > 200.0.1.0: icmp: есho request
00:54:56.911891 pinger.mapper.com > 200.0.2.255: icmp: есho request
00:54:57.265833 р4пдег.паррень.ссип > 200.0.2.0: icmp: есho request
00:59:52.822243 pinger.mapper.com > 200.0.3.255: icmp: есho request
00:59:53.415182 pinger.mapper.com > 200.0.3.0: icmp: есho request
Отличие от атаки Smurf заключается в использовании реального адреса источника широковещательных пакетов, систематическом увеличении номеров подсетей для анализа активности входящих в них узлов и времени, затрачиваемого на обработку ответов на посланные запросы (есhо гер1у).
Другим признаком атак типа <отказ в обслуживании> рассматриваемого класса могут служить неправильные адреса, заданные в полях <адрес получателя> или <адрес отправителя>. Например, атака Land обнаруживается по совпадению этих адресов в одном пакете.
Обнаружение атаки Land (фрагмент журнала ТСРdump)
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. Например, в Сisco Secure IDS пакет признается враждебным, если в нем совпадают только адреса получателя и отправителя, а в системе RealSecure Network Sensor сoвпадать должны не только адреса, но и порты получателя и отправителя.
Примером атаки, некорректно использующей порты отправителя и получателя, служит Сhargen (некоторые специалисты называют эту атаку Еcho или Еcho Chargen). Эта атака использует особенности реализации IР-сервисов ЕсЬо и Сhargen, вследствие которых посылка пакетов с порта 19 (Сhargen) на порт 7 (Есhо) приводит к зацикливанию, и все доступные ресурсы атакуемых компьютеров используются для обработки бесконечного цикла. При этом вместо порта 7 может быть атакован любой порт, автоматически отвечающий на любой направленный на него запрос (к таким относятся порты 13 (daytime), 37 (time) и т. д.).
Обнаружение атаки Сhargen или Еchо (фрагмент журнала ТСРdump)
08:08:16.155354 200.0.0.200.есhо > 200.0.0.104.сhargen: udp
При анализе сетевого трафика необходимо обращать внимание на поле 1Р Options заголовка пакета. Это по
ле достаточно редко используется в обычной жизни, и появление в сети пакетов с информацией в нем может свидетельствовать о нестандартной ситуации. Это поле может служить для изучения маршрута следования пакетов (source routing) или для реализации атак типа <отказ в обслуживании>. Например, 20 октября 1999 года в Bugtraq появилось сообщение о том, что модуль анализа 1Р-пакетов межсетевого экрана Raptor 6.0 компании Symantec неправильно обрабатывает поле 1Р Оptions, в результате чего он может быть выведен из строя, и только перезагрузка компьютера с межсетевым экраном возвращает Raptor в нормальное состояние. И хотя эта уязвимость позже была устранена, факт остается фактом.
Обнаружение атаки на межсетевой экран Raptor 6.0 (фрагмент журнала ТСРdump)
13:07:52 10.0.0.1.www > target.net.61374: Р
2018915346:2018915378(32) асk 558065031 win 8192
[8ов 0х32] ttl 255, id 48879, орtlen=4[|iр ор 1еn 0])
4632 004с beef 0000 ff06 а222 0а00 0001
0а01 0165 4400 0001 0050 еfbe 7856 3412
2143 6587 5018 2000 5724 0000 0000 0000 0000 0000 0000
Следующий признак атак типа <отказ в обслуживании> - использование широко известных уязвимых мест. Например, посылка IСМР-пакетов с типом 13 (Тimestamp) на узел с установленной ОС Мicrosoft Windows 98 вследствие некорректной реализации стека ТСP/IР в этой ОС может привести к <зависанию> узла и появлению <голубого экрана>.
Использование уязвимости стека ТСР/IР в ОС Windows 98 (фрагмент журнала ТСРdump)
14:07:44 200.0.0.200 > иin98.net: icmp: time stamp request 4500 0028 0100 0000 FF01 FECЗ 3362 7d3с
Оа01 0165 0d00 bdb5 ffff ffff 8b52 2dее 99dd ес91 73аЗ 8126
Наличие еще одного уязвимого места (Win IGМР) в реализации ТСР/IP стека в Windows 98 также может привести к появлению <голубого экрана> в том случае, если в сети по протоколу маршрутизации IGМР передаются фрагментированные пакеты. (Если команда DaGo не ошибается, именно на основе этой ошибки реализации и был создан знаменитый voidozer командой void.ru)
Использование уязвимости стека ТСР/IР в Windows 98/2000 (фрагмент журнала ТСРdump)
13:20:12 200.0.0.200 > targey.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. При такой атаке создается два ТСР-фрагмента: первый из них настолько мал, что даже не включает полного ТСР-заголовка, особенно порта получателя. Второй фрагмент содержит остаток заголовка. Многие межсетевые экраны пропускают первый фрагмент или оба внутрь корпоративной сети.
Атака Tiny Frafment (фрагмент журнала TCP dump)
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)
Нотация [|tср] указывает на то, что утилита ТСРdump не смогла захватить весь ТCР-заголовок и интерпретировать назначение пакета.
Однако самый известный пример атаки, использующей фрагментированные пакеты, - это Рing of Death. Принцип ее действия заключается в посылке IСМР пакета длиной более б5 535 байтов (максимальный размер 1Р-пакета). Длина данного сообщения, состоящего из множества фрагментов, может составлять например 65 740 (380+65 360) байтов. Еще одна проблема, связанная с фрагментированными пакетами, заключается в том, что длина передаваемого фрагмента должна быть кратна 8, что в приведенном примере не соблюдается (длина фрагмента 380 байт). Некоторые сетевые устройства или программы <не умеют> правильно собирать фрагменты нестандартного размера, что приводит к выходу их из строя.
В заключение хочу остановиться на распределенных атаках, которые существенно усложняют защиту корпоративной сети. Дело здесь в том, что если пропускная способность канала до цели атаки превышает пропускную способность атакующего, то традиционная атака типа <отказ в обслуживании> (UDP Bomb, IСМР Flood и т. д.) не будет успешной. Распределенная же атака происходит уже не из одной точки Интернета, а сразу из нескольких, что приводит к резкому возрастанию трафика и выведению атакуемого узла из строя. Злоумышленник может послать большой объем данных сразу со всех узлов, задействованных в распределенной атаке. Атакуемый узел захлебнется огромным трафиком и не сможет обрабатывать запросы от нормальных пользователей. Именно так были реализованы нашумевшие атаки в начале февраля 2000 года.
При обычной реализации аналогичной атаки необходимо иметь достаточно <толстый> канал доступа в Интернет, чтобы отправить лавину пакетов на атакуемый узел. В случае же распределенной атаки это условие перестает быть необходимым: достаточно иметь dialup-cоединение с Интернетом. Принцип же лавины или шторма пакетов достигается за счет большого числа таких относительно медленных соединений.
Приведем пример: по данным <Россия-Онлайн> в течение двух суток, начиная с 9 часов утра 28 декабря 2000 г., крупнейший Интернет-провайдер Армении <Арминко> подвергался распределенной атаке. Суть еесостояла в том, что хакер, обнаружив слабо защищенный сервер, с помощью особой программы принудил его к выдаче бессмысленной информации по любому компьютерному адресу. В данном случае к атаке подключилось более 50 машин из разных стран, которые посылали по адресу <Арминко> бессмысленные сообщения. Кто организовал эту атаку и в какой стране находился хакер, установить не удалось. "Хотя атаке подверглась в основном <Арминко>, перегруженной оказалась вся магистраль, соединяющая Армению со Всемирной паутиной. 30 декабря благодаря сотрудничеству другого провайдера, <АрменТел>, связь была полностью восстановлена. Несмотря на это, компьютерная атака продолжалась, но с меньшей интенсивностью.
Распределенные атаки (например, ТFN ) можно обнаружить по номерам используемых портов. Кроме того, признаком атаки может служить большое число сетевых пакетов, передаваемых на заданный узел с сотен и тысяч узлов.
Обнаружение атаки TFN (фрагмент журнала TCPdump)
17:25:21.369 251.244.87.90 > 200.0.0.104: icmp: есhо request
17:25:21.389 91.105.122.14 > 200.0.0.104: icmp: есЬо геquest
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 гequest
Алексей Лукацкий
Dago.Org
|
