5.2.3.5 Атаки в сети интернет
Сценарий (рисунок 5.22) представляет собой скачивание большого файла с сервера TCP SACK (TCP-S) клиентом (TCP-R). Настройки TCP-S хоста: minRTO=1, измерения полосы пропускания с помощью iperf (/usr/ports/net/iperf). Атаки были запущены с 3-х хостов, используя программы активного зондирования, работающие по UDP-протоколу. Все эксперименты проводились три раза и как результаты брались усреднения.
Внутрисетевой сценарий. В этом варианте оба — и отправитель TCP-S и хост DoS-A — находятся на одном сегменте 10-мегабитной, в то время как атакующий — в другой сети 10 Мбит/с в двух хопах от TCP-S и DoS-A. Пиковая скорость импульса — 10 Мбит/с, длительность — 200 мс.
Кривая, отмеченная DoS-A (внутрисетевая атака) на рисунке 5.23 показывает результаты этого эксперимента. Нулевая пропускная способность приходится на время ~1,2 сек. Скорость передачи атакующего в этот момент 1.67 Мбит/с, в то время как без атаки пропускная способность 6.6 Мбит/с. При атаке она снижается до 780 Кбит/с.
Межсетевой сценарий. В этом случае отправитель TCP-S, источник атаки DoS-B и атакуемый хост TCP-R располагаются в 3-х разных сетях кампусной. Маршрут проходит через два роутера и два Ethernet-свитча. Сети TCP и DoS 100 Мбит/с, а у атакующего — 10 Мбит/с. Скорость импульса атакующего такая же — 10 Мб/с, но длительность уменьшена (по сравнению с предыдущим сценарием) до 100 мс.
Кривая, обозначенная DoS-B (Межсетевая атака) на рисунке 5.23 показывает результат атаки. В этом сценарии минимальная пропускная способность наблюдается в момент времени 1.1 сек при пропускной способность 800 Кбит/с, что составляет всего 8,1% от нормальной пропускной способности (без атаки — 9.8 Мбит/с). В то время, как скорость атакующего в этот момент 909 Кб/с.
Рисунок 5.22 - Сценарий DoS-атаки
Сценарий с глобальной сетью (WAN). И в последнем эксперименте возьмем те же пары приемник/передатчик, что и в межсетевом сценарии, источник DoS-C начинает атаку из сети, что расположена в восьми хопах. Скорость импульса 10 Мбит/с, длительность — 100 мс. Кривая DoS-C (WAN) на рисунке 5.23 показывает, что практически нулевая пропускная способность приходится к моменту времени 1.1 сек. В этом сценарии пропускная способность снизилась с 9.8 Мб/с до 1.2 Мб/с при скорости атакующего 909 Кб/с. На основании этого эксперимента можно сделать вывод о возможности удаленной атаки, т.к. трафик атакующего прошел локальную сеть, роутеры и свитчи. Даже при возможном искажении импульса трафика DoS-атака по прежнему эффективна.
Рисунок
5.23 - эксперимент в Интернет
Таким образом доказано, что источник атаки может быть и «рядом», и довольно далеко.
5.2.4 Syn атака
Рассмотрим процесс создания и поддержки виртуальных каналов связи. Разделим процесс на несколько этапов:
Какой-либо порт, точнее, связанный с этим портом сервис удаленной машины ожидает запроса на создание соединения (находится в состоянии ожидания SYN_WAIT).
Клиент посылает на сервер запрос: TCP-пакет с установленным битом SYN и с произвольным инициализационным номерком SEQ примерно такого содержания:
0000: 45 00 00 28 А7 00 00 00 FF 06 93 7В СО А8 00 02 оооооооооооооооо
0010: СО А8 00 01 13 88 00 15 00 00 7А 69 00 00 00 00 оооооооооооооооо
0020: 50 02 OF АО 90 Е8 00 00 оооооооо
Первые двадцать байт пакета составляют IP-заголовок: мы обращаемся с адреса 192.168.0.2 на адрес 192.168.0.1 по протоколу 06 (IPPROTO_TCP). Имеет смысл детально разобрать заголовок TCP, начинающийся с байта 14h:
Слово 14h-15h (Source Port): 1388h, мы обращаемся с порта 5000;
Слово 16h-17h (Destination Port): 0015h, мы обращаемся на порт 21, по умолчанию ftp.
Двойное слово 18h-1Bh (Sequence Number): 00007A69h, мы устанавливаем инициализационный номер SEQ в значение 31337.
Двойное слово 1Ch-1Fh (Acknowledgement Number): 00000000, за ненадобностью пустое.
Слово 20h-21h нашего пакета соответствует сразу трем полям заголовка TCP: первый полубайт соответствует Data Offset и содержит значение 5 (длина заголовка равна 5 х 4 = 20 байт). Следующие шесть бит относятся к полю резервных, не используются и пустуют. Последние шесть соответствуют полю флаговых бит и содержат значение 000010b (установлен бит SYN). Далее, флаговое поле мы будем связывать с целым байтом 21h.
Слово 22h-23h (Window): 0FA0h (4000 в десятичной).
Слово 24h-25h (Checksum): 0A090h, составляет контрольную сумму заголовка TCP и псевдозаголовка.
Слово 26h-27h (Urgent Pointer) пусто, так как бит URG пуст.
Сервер получает это сообщение, обрабатывает его, открывая на своей стороне сокет под виртуальный канал связи с клиентом и отсылает подтверждение клиенту с установленными битами АСК и SYN. В поле Sequence Number он записывает свой номер SEQ, а в поле АСК он отправляет увеличенный на единицу SEQ пришедшего сообщения. Сообщение выглядит примерно так:
0000: 45 00 00 2С 6D 00 40 00 80 06 ОС 78 СО А8 00 01 оооооооооооооооо
0010: СО А8 00 02 00 15 13 88 00 АЕ 9А 5Е 00 00 7А 6А оооооооооооооооо
0020: 60 12 21 80 СС 2Е 00 00 02 04 05 В4 оооооооооооо
Удаленный сервер отвечает нам таким образом: Слово 14h-15h (Source Port): 0015hs отвечает с порта 21h. Слово 16h-17h (Destination Port): 1388h, туда, куда мы его просили.
Слово 18h-1Bh (Sequence Number): OOAE9A5Eh, устанавливает значение SEQ в 11442782.
Слово 1Ch-1Fh (Acknowledgement Number) : 00007A6Ah, содержит увеличенный на единицу пришедший номер SEQ первого пакета: 31338.
Первый полубайт октета 20h содержит значение 6, значит, сервер решил снабдить свой заголовок четырьмя байтами поля опций. Его мы пропускаем, так как поле опций не играет роли.
Байт 21 h содержит значение 12h, что соответствует взведенным битам SYN и АСК. Окно: 2180h в слове 22h-23h (Window).
Контрольная сумма пакета (слово 24h-25h) равна 0СС2Еh.
Поле Urgent Pointer пустое.
Открытый на сервере сокет ожидает продолжения создания виртуального канала связи в течение некоторого количества времени (тайм-аута), опциональной, зависящей от конкретной реализации и настройки сервиса, величины (от нескольких секунд до нескольких минут). Величина тайм-аута не регламентирована спецификацией протокола TCP.
Сервер должен успеть за это время получить подтверждение от клиента, иначе сокет закрывается и освобождается, а клиенту необходимо будет повторить процедуру с самого начала.
Клиент получает это сообщение и отсылает серверу подтверждение с установленным битом АСК. В поле SEQ он сохраняет значение АСК пришедшего сообщения, а в поле АСК он записывает увеличенное на единицу значение пришедшего SEQ:
3000: 45 00 00 28 А7 00 00 00 FF 06 93 7В СО А8 00 02 оооооооооооооооо
0010: СО А8 00 01 13 88 00 15 00 00 7А 6А 00 АЕ 9А 56 оооооооооооооооо
3020: 50 10 OF АО ВЗ 77 00 00 оооооооо
После проведения этих манипуляций виртуальный канал связи считается установленным и в следующем сообщении от сервера к клиенту сервис, в рамках своего интерфейсного протокола, предоставляет реквизиты своих услуг. Время тайм-аута многократно повышается. Для поддержки конфиденциальности соединения обе стороны должны выполнять простое правило: каждая сторона увеличивает на единицу пришедший номер SEQ и помещает его в поле АСК. Пришедший номер АСК необходимо помещать в поле SEQ без изменений.
Многие серверы, не получив сию же секунду АСК ответ (шаг 4) от клиента, повторяют отправку клиенту ACK/SYN ответов в течение времени тайм-аута с определенной периодичностью (периодичность зависит от настройки сервера и может колебаться в пределах нескольких секунд). Этот момент также не регламентирован стандартом протокола TCP: на основе этой «самодеятельности» серверов очевиден флудер-множитель.
Таким образом, мы имеем флудер-множитель с коэффициентом умножения от 4 до 60.
Реализация сервисов некоторых сетевых операционных систем сильно страдает от обилия ограничений, наложенных на них обработчиком сетевого уровня этих ОС. Наиболее характерное и ощутимое ограничение выражается прежде всего в количестве сокетов, которые операционная система способна выделить своим сервисам. Например, в Windows прикладные программы могут позволить себе открыть не более 96 сокетов. Очень характерен тот факт, что под собственные нужды и сервисы (такие, как, например, стек NetBIOS) эта система выделяет более тысячи сокетов. Помимо ограниченности операционной системы иногда имеет место не всегда оправданная небрежность разработчиков, снабжающих реализацию сервисов константной величиной максимально возможного количества сокетов. Все это говорит о том, что сервер, работающий под управлением одной из таких операционных систем, сможет открыть одновременно не более определенного и весьма малого количества виртуальных каналов связи.
Рисунок 5.24 - SYN атака
Классическая TCP SYN основана именно на этой особенности и заключается в том, что атакующий отсылает целенаправленный поток SYN-запросов (т. е. запросов на получение виртуального канала связи) удаленной системе с целью «забить» на атакуемой стороне как можно большее количество сокетов под эти каналы, тем самым лишив всех остальных потенциальных клиентов сервера общаться с сервисами последнего. Фактически это означает denial of service удаленного сервера.
Сервер принимает весь этот поток и, следуя стандарту, открывает сокет, отсылая обратно подтверждение на каждый пришедший SYN-пакет, и в течение тайм-аута ожидает получения подтверждения со стороны пакета. Такова суть классической TCP SYN-атаки. Для того, чтобы не утруждать себя приемом подтверждений от сервера, а также для того, чтобы обеспечить себе относительную анонимность, не имеет смысла снабжать все свои SYN-пакеты легальными Source IP-адресами.
После завершения процесса создания виртуального канала связи время тайм-аута повышается в десятки раз: некоторые FTP-серверы увеличивают время тайм-аута для уже установленного канала до двадцати минут. Поэтому имеет смысл доводить процесс создания TCP-соединения до конца, многократно повышая время тайм-аута, и лишь изредка (например, за несколько секунд до истечения времени тайм-аута) поддерживать этот канал каким-нибудь сообщением. Так как статус такого соединения будет максимальным, эффективность атаки увеличится.
Иногда измерять время тайм-аута даже не нужно. Например, многие FTP-серверы в случае истечения времени тайм-аута отсылают сообщение, в дейтаграмме которого дословно сообщается нечто вроде «900 seconds timeout exceed». Некоторые же FTP-северы время тайм-аута сообщают сразу после установки соединения.
5.2.5 Teardrop
Передаваемый, во время TCP сеанса, пакет может разбиваться на несколько меньших пакетов, а принимающая сторона возвращает ему первоначальный вид. Точнее, более высокоуровневые, чем IP, протоколы TCP и UDP могут передаваться фрагментированно на уровне IP. Каждый фрагмент характеризуется смещением от начала исходного пакета и своей длиной. Драйвер TCP/IP-стека собирает фрагменты на принимающей стороне до тех пор, пока не получит их все. При передаче возможны различные ситуации, которые умная реализация TCP/IP должна распознавать. В частности, может быть, что несколько полученных фрагментов будут пересекаться. Нас интересует ситуация, когда новый фрагмент имеет смещение, лежащее внутри уже полученного фрагмента. Рассмотрим, что делает TCP/IP-стек в этом случае. Во-первых, вычисляется размер пересечения: смещение старого фрагмента плюс длина старого фрагмента есть смещение нового фрагмента. А затем в буфер копируется только та часть нового фрагмента, которая "выступает за границу" старого фрагмента. Однако возможна ситуация, когда новый фрагмент не только начинается внутри старого, но и заканчивается в нем же.
Такой фрагмент должен быть пропущен, но этого не предусмотрено в стеке протоколов Windows и Linux. Предположим у нас есть уже полученный фрагмент A, со смещением A_offs и длиной A_len. Пришел новый фрагмент B, со смещением B_offs и длиной B_len. Причем A_offs < B_offs < B_offs + B_len < A_offs + A_len, то есть фрагмент B лежит внутри фрагмента A.
Проследим действия принимающей стороны по шагам. Начало нового фрагмента лежит внутри имеющегося. Пересекающаяся часть имеет смещение A_offs + A_len - B_offs. А тот кусочек, что нужно добавить в буфер, начинается с A_offs + A_len и имеет длину (B_offs + B_len) - (A_offs + A_len). В результате получатся длина-меньше нуля или (в представлении машинной арифметике) является очень большим положительным числом. Далее происходит копирование блока памяти, очень большого размера, уничтожая при этом все данные лежащие рядом (обычно это операционная система). Так реализуется атака Teardrop. Приведенное объяснение так же верно для Linux.