Provide feedback
Saved searches
Use saved searches to filter your results more quickly
Sign up
Уровень сложностиПростой
Время на прочтение12 мин
Количество просмотров24K
В данной статье мы поговорим об устройстве протокола TCP, самой популярной атаке на него – SYN-flood, реализуем её на практике, а также узнаем, как с ней бороться.
Часть 1. Устройство TCP
Что такое TCP и зачем он нужен?
TCP расшифровывается как Transmission Control Protocol – протокол контроля передачи. Как понятно из названия, он используется для того, чтобы контролировать передаваемые по сети данные: упреждать и исправлять различные казусы, которые могут возникнуть при передачи данных по сети.
Но что же такого может случиться при отправки пакетов по сети?
1. Нарушение порядка следования пакетов
Передаваемые нами данные, дробятся на пакеты, которые далее маршрутизируется протоколами динамической маршрутизации, и может статься так, что одна часть пакетов пойдет по более быстрому маршруту, а другая будет передаваться по маршруту с более низкой пропускной способностью, ввиду чего придет позже.
Пусть, к примеру, нам нужно последовательно передать узлу сети четыре пакета: A,B,C и D. Мы ожидаем, что он получит их в такой же последовательности, в которой они были отправлены, но исходя из вышеизложенного вполне возможна ситуация, при которой получатель будет иметь при приеме последовательность ACBD или, например, DACB. Следовательно, TCP должен каким-то образом восстанавливать исходный порядок полученных пакетов.
2. Потеря пакетов
Ввиду ошибки маршрутизации или плохо сконфигурированной сети наши пакеты могут передаваться по очень медленному пути, либо попасть в петлю, в которой они будут блуждать, пока не исчерпают свой запас хопов и не уничтожатся. В таком случае TCP должен иметь возможность запрашивать потерянные или погрязшие в пакетной пробке данные.
Если мы общаемся с кем-то по аудио или видеосвязи, то такие исходы нас мало волнуют, но если мы скачиваем, к примеру, iso-образ некой ОС, то подобные ситуации мы должны полностью исключить.
Также TCP (как и другие протоколы транспортного уровня) используется для того, чтобы перенаправлять данные с одного порта, на другой порт, то есть от одного прикладного процесса к другому.
TCP-сегменты
Для передачи данных по сети TCP получает их от протокола прикладного уровня, буферизует и при готовности отправлять новую порцию данных, «отрезает» потребный кусочек байтов без учета их смысла или внутренней структуры. Каждый такой кусочек называется TCP-сегментом. Важно, что TCP рассматривает данные именно, как неструктурированный поток байтов. В отличие от протокола UDP, создающего дейтаграммы на основе логически обособленных единиц данных (сообщений, генерируемых приложениями). На стороне получателе модуль TCP получает пакеты, сохраняя их в буфер, а затем передает их протоколу прикладного уровня
Отметим, что сегментом называют как единицу передаваемых данных в целом (поле данных и заголовок протокола TCP), так и отдельно поле данных.
Заголовок TCP-сегмента
В последующем изложении нам понадобится знание полей заголовка, потому изложим их краткие описания, к которым читатель может вернуться в любой момент:
-
Source Port и Destination Port (16 бит каждый) – порт отправителя и получателя соответственно.
-
Sequence number (32 бита) – номер первого байта в сегменте, указывающий на его смещение, относительно всего потока байт.
-
Acknowledgment number (32 бита) – номер последнего байта, полученного в сегменте, увеличенного на единицу.
-
Data Offset (4 бита) – указывает на длину заголовка (смещение данных от начала сегмента)
-
Reserved (3 бита) – зарезервированные биты, которые могут использоваться в дальнейшем.
-
Flags (9 бит) – флаги, указывающие на то, какую информацию в себе несет сегмент.
-
Window (16 бит) – размер окна, показывающий сколько байт данных получатель готов принять.
-
Checksum (16 бит) – контрольная сумма. Некоторое значение, рассчитанное по набору данных путём применения хэш-функции и используемое для проверки целостности данных.
-
Urgent Pointer (16 бит) – порядковый номер байта, которым заканчиваются важные данные (принимается во внимание только при установленном флаге URG)
-
Options (12 бит) – опции, в которых содержаться параметры соединения.
-
Padding – фиктивное поле переменной длины, используемое для доведения размера заголовка до целого числа 32-битных машинных слов.
-
Data – поле переменной длины, в котором непосредственно содержатся передаваемые данные.
Установка TCP-соединения
Перед началом непосредственной передачи данных отправителю и получателю необходимо установить соединение, в рамках которого будет производиться передача данных. При установке соединения отправитель и получатель обмениваются параметрами соединения: указывают ACK-номер, размер окна, тип квитирования и т.д. (обо всем этом будет подробно рассказано далее). Происходит это все в три этапа:
-
Отправитель посылает на сервер TCP-сегмент со своими параметрами, устанавливая флаг SYN (от англ. synchronization) и переходит в состояние SYN-SENT.
-
Сервер, получив SYN-флаг начинает подготавливать инфраструктуру для поддержания соединения, запрашивая у ОС различные ресурсы (счётчики, таймеры, буфера и т.д.) После отправляет TCP-сегмент со своими параметрами и флагами SYN и ACK (от англ. acknowledgement), переходя в состояние SYN-RECEIVED.
-
Отправитель, получив от сервера SYN-ACK-сегмент, отправляет ему сегмент с флагом ACK и переходит в состояние ESTABLISHED. Сервер, получив данный сегмент, также переходит в данное состояние, и начинается отправка данных.
Методы квитирования
Для того чтобы решать проблемы, поставленные перед TCP, было решено использовать квитирование пакетов. Идея проста: отправитель отсылает данные, а получатель подтверждает их получение квитанциями. Если отправитель вовремя не получает квитанции на переданные данные, то он передает их повторно. TCP реализует два метода квитирования пакетов, которые используют концепцию скользящего окна
Концепция скользящего окна
Идея заключается в следующем: отправитель имеет ряд пронумерованных пакетов, на котором определяется окно с заданным размером, регулирующее процесс передачи пакетов. Самый первый пакет, входящий в окно, называется базовым. Все, что левее него считается переданным. Пакеты, находящиеся в пределах окна разрешается передавать. Пакеты, которые находятся за правой границей окна, передавать запрещено. При получении квитанции на базовый пакет окно сдвигается на один пакет влево. При исчерпании окна передачи отправитель останавливается и ждет поступления квитанции. Окно также может быть и у получателя, которое ограничивает номера пакетов, которые он может принять.
На следующем рисунке представлен идеализированный пример, который показывает работу скользящего окна на стороне отправителя
Для чего вообще нужно окно? Почему не передавать все пакеты разом?
Представьте себе такую ситуацию: вы решили скачать себе на смартфон GTA San Andreas, вес которой 1,4 Гб. При отсутствии скользящего окна все 1,4 Гб отправились бы с серверов Google бомбардировать TCP-модуль вашего смартфона.
Во-первых если бы все придерживались такой концепции, то очевидным образом это привело бы к заполоненью всего Интернета огромным числом TCP-сегментов, которые бы в разы уменьшили пропускную способность каналов связи.
Во-вторых при таком раскладе вашему смартфону пришлось бы выделять буфер неограниченного размера (так как мы не можем знать заранее какой объем данных мы получим), что уже звучит абсурдно. Так как размер буфера, который ОС может выделить ограничен, то в таком случае сегменты, которые не помещаются в буфер будут откинуты. Сервер же будет думать, что с пакетами что-то случилось и будет производить повторную их отправку, бомбардируя наш смартфон, который в это время не разобрался с полученными сегментами, снова и снова.
Теперь, когда мы познакомились со скользящим окном, перейдем к рассмотрению методов квитирования, на нем основанных.
Возвращение N пакетов (Go-Back-N)
Для начала рассмотрим алгоритм работы с сегментами на стороне-получателе. При поступлении нового пакета получатель проверяет две вещи:
-
Является ли пакет неискаженным
-
Является ли он следующим по порядку в последовательности уже полученных пакетов
Если два этих действий выполняются, то получатель посылает квитанцию с номером последнего переданного пакета. Стоит отметить, что квитанции в данном методе передачи являются накопительными. То есть, если отправитель получил квитанцию с номером n-го пакета, то и все пакеты до него также были приняты, так как получатель принимает неискаженные пакеты тогда и только тогда, когда они не выбиваются из последовательности (можно сказать, что у принимающей стороны окно размером в один пакет).
Теперь же рассмотрим алгоритм на стороне-отправителе. Отправитель посылает пакеты, не выходящие за рамки окна, и устанавливает таймер, значение тайм-аута которого равно предельному времени ожидания квитанции на базовый пакет. После истечения тайм-аута отправитель считает, что пакет или квитанция были утеряны, и отправляет его и все остальные отправленные пакеты еще раз, так как если базовый пакет не был принят, то и остальные тем более (поэтому метод и называется Go-Back-N).
Может случиться так, что базовый пакет и несколько последующих были успешно приняты, но квитанции на них затерялись. В таком случае получатель отправит повторно несколько пакетов. Получатель же, увидев дубликаты, поймет, в чем дело и отправит квитанцию последнего полученного пакета (вспоминаем про куммулятивность).
Данный метод является менее ресурсозатратным чем последующий, но имеет очевидный минус. Сторона-получатель может отбрасывать целостные пакеты только из-за того, что они выбиваются из последовательности, вследствие чего, отправитель будет вынужден каждый раз по истечение тайм-аута высылать целую порцию пакетов, заполоняя тем самым избыточными пакетами канал связи.
Выборочное квитирование (Selective acknowledgement)
При выборочном квитировании, как понятно из названия, сторона-получатель может отправлять квитанции на конкретные пакеты. В таком случае ей где-то нужно хранить полученные пакеты, ибо сразу отправлять их протоколу верхнего уровня не получится, так как пакеты могут приходить в хаотичной последовательности, и между ними могут образовываться пробелы. Следовательно на стороне получателя также организовывается скользящее окно. Очевидно, что окна на обеих сторонах должны быть одинакового размера, но скользить синхронно они не обязаны; в зависимости от возникающих ошибок при передаче пакетов и квитанций окно приема может опережать окно передачи.
Получатель в данном случае уже не отбрасывает пакеты лишь потому, что они выбиваются из последовательности. Вынудить отбросить пакет получателя может его искажение, либо выход за границы окна.
Сторона-отправитель в данном случае организует таймер не только на базовый пакет, а на все отправленные пакеты и по истечении тайм-аута для конкретного пакета отправляет его вновь.
Возможна и ситуация, в которой пакет благополучно был принят, но квитанция на него потерялась. Тогда к получателю придет дубликат пакета. Получатель не должен его игнорировать – ему следует подтвердить квитанцией прием дубликата.
Данный метод хоть и чуть более ресурсозатратен, чем предыдущий, но позволяет существенно увеличить скорость передачи и уменьшить избыточную передачу пакетов. В настоящий момент большинство узлов сети, работающих на транспортном уровне, используют именно этот метод квитирования пакетов.
Нумерация байтов
В рассмотренных нами примерах для упрощения мы нумеровали наши пакеты натуральными числами, начиная с единицы, но в реальности же дела обстоят чуть сложнее. В протоколе TCP при установке соединения каждая из сторон сообщает другой число Initial Seqeunce Number (поле Sequence Number), начиная с которого она будет нумеровать свои байты. И номером каждого сегмента в данном случае будет выступать число, равное смещению начального байта в сегменте относительно всего потока байт + ISN.
Рассмотрим пример. Пусть отправляющая сторона выбрала ISN равный 32600. Номером первого сегмента будет очевидно 32600. Так как смещение начального байта в самом первом сегменте равно нулю. Номером второго сегмента будет 34060, так как смещение его начального номера относительно начала потока байтов – 1460. Обратите внимание, что прибавив к 32600 1460 мы получим не конечный номер байта первого сегмента, а именно начальный номер второго сегмента, так как смещение начинается не с нуля а с единицы. В точности как в массивах.
Также стоит отметить, что для квитирования используется поле Acknowledgment Number, в котором указывается номер последнего полученного байта, увеличенного на единицу.
К чему такие сложности? В чем проблема нумеровать байты, последовательно используя натуральные числа, начиная с единицы?
Действительно, такой выбор изначально может показаться довольно странным, но на то есть свои причины.
Смещение используется потому, что при нумерации вида 1,2,3,…,n отправителю и получателю пришлось бы согласовывать размер блока данных в начале соединения и отправлять сегменты строго такого размера, ибо в противном случае принимающей стороне пришлось бы вычислять смещения относительно начала потока байт самостоятельно, чтобы правильно расположить данные в памяти, что приводит нас к использованию смещения.
Вы можете спросить: «Ну и в чем же проблема использования фиксированного размера блока данных?» А вот вам загадка от Жака Фреско: вы используете фиксированный размер блока данных для отправки, и вдруг MTU канала связи меняется в меньшую сторону. Вопрос: как в таком случае отправлять данные? На размышление дается 5 секунд.
Хорошо, со смещением разобрались, но для чего же используется ISN? Почему не нумеровать, начиная с нуля? Дело в том, что ISN предотвращает атаку с отправкой поддельных сегментов для установки соединения.
Рассмотрим еще раз то, как устанавливается соединение с сервером. Пользователь отправляет SYN-сегмент, в который включает свой ISN. В ответ сервер ему посылает SYN-ACK-сегмент, в котором также указывает свой ISN. Для начала соединения пользователь должен отправить ACK-сегмент, где в поле Acknowledgment Number должен отправить полученный ISN, увеличенный на единицу.
Положим теперь, что ISN всегда равен 0. В таком случае злоумышленник может отправить на сервер SYN-сегмент, указав в пакете фиктивный IP-адрес, а далее отправить ACK-сегмент с полем Acknowledgment Number, равным 1 (учитывая, что сервер отправил по указанному IP-адресу SYN-ACK-сегмент). Таким образом он установит соединение, заставив тем самым сервер его обрабатывать. Отправляя нон-стопом такие сегменты, злоумышленник очевидным образом добьется истощения ресурсов сервера. ISN решает эту проблему, так как злоумышленнику придется знать отправленный сервером ISN, для того чтобы заполнить поле Acknowledgment Number валидным значением в ответном ACK-сегменте.
Также помимо изначальной защиты от описанного выше сценария атаки ISN используется для SYN-cockie, о чем будет рассказано ниже
Для более лучшего понимания работы протокола читателю рекомендуется самостоятельно просниффить трафик и посмотреть, как происходит процесс рукопожатия и обмена информацией.
Часть 2. Атака SYN-flood
Суть атаки
Syn-flood атака — это одна из разновидностей DoS-атак. Принцип следующий: злоумышленник посылает огромное количество запросов установки соединения на атакуемый сервер. Сервер, видя сегменты с флагом SYN, выделяет необходимые ресурсы для поддержания соединения и отправляет в ответ сегменты с флагами SYN и ACK, переходя в состояние SYN-RECEIVED (такое состояние еще называют полуоткрытым соединением). Злоумышленник, не шлет ответные ACK сегменты, а продолжает бомбардировать сервер SYN-запросами, тем самым вынуждая сервер создавать все больше и больше полуоткрытых соединений. Сервер, понятное дело, располагает ограниченными ресурсами, и потому имеет лимит на количество полуоткрытых соединений. Ввиду этой ограниченности, при достижении предельного числа полуоткрытых соединений сервер начинает отклонять новые попытки соединения; таким образом и достигается отказ в обслуживании (Denial of Service).
Реализация атаки
Для проведения атаки нами будут использованы две виртуальные машины. В качестве жертвы будет выступать LMDE 6, а в качестве злоумышленника Kali 6.1.
Для начала установим лимит на количество полуоткрытых соединений на машине жертвы в 5 (по умолчанию 1024). Для этого нужно воспользоваться утилитой sysctl, которая позволяет вносить изменения в работающее ядро.
IP-адрес жертвы – 192.168.31.175.
Для проведения атаки воспользуемся утилитой hping3, которая является предустановленной в дистрибутиве Kali. В данном случае мы отослали 15 пакетов на 23 порт (telnet) с включенным флагом SYN, используя спуфинг IP-адресов.
После проведения атаки посмотрим информацию по открытым сокетам жертвы с помощью утилиты ss; -a показывает все сокеты, -t – TCP-сокеты, -o – информацию о таймерах.
Как мы видим, наша машина поддерживает только 5 сокетов в полуоткрытом состоянии, хотя мы отправили 15 запросов на соединение. Если бы среди них был бы законный пользователь, то он бы получил отказ в обслуживании, чего мы и добивались.
Давайте изучим трафик, который был пойман во время проведения атаки.
Как мы видим, нами действительно было отправлено 15 SYN-запросов, но только на 5 из них жертва ответила. Кстати обратите внимание на красно-черные строчки: наша машина повторно отправляет SYN,ACK ответы, так как думает, что они были потеряны или искажены.
Методы защиты от SYN-flood атак
Как же защищаться от SYN-flood атак? Тут есть два подхода, которые можно комбинировать между собой.
Во-первых, можно увеличить количество полуоткрытых TCP-соединений и уменьшить время, в котором сокет может пребывать в состоянии SYN-RECEIVED.
Во-вторых можно использовать SYN-cookie.
Идея SYN-cookie очень проста: когда к нам приходит SYN-запрос мы не создаем новое соединение, а отправляем SYN-ACK-ответ клиенту, где в поле Sequence Number кодируем данные о данном соединении. Если мы получаем ACK ответ от клиента, то из поля Acknowledgment Number восстанавливаем данные о соединении. Данный метод хорош тем, что мы более не будем выделять ресурсы, как только к нам придет SYN-запрос. Но есть и очевидный минус: если наш пакет затеряется, или подвергнется искажению, то мы не сможем отправить его повторно, так как информацию о соединении мы условились не сохранять.
Для того, чтобы включить SYN-cookie, нужно воспользоваться утилитой sysctl и установить значение параметра net.ipv4.tcp_syncookies равным 2. До этого данный параметр равнялся нулю.
Попробуем провести атаку еще раз и засниффить трафик.
Как мы видим, наша машина ответила уже на все запросы, но повторной отправки не последовало.
Если мы посмотрим на состояние сокетов, то увидим, что не одного полуоткрытого соединения не было создано.
В данной статье мы познакомились с протоколом TCP, узнали об атаке SYN-flood, научились её проводить, а также защищаться от неё.
В данной статье рассматривалась только одна атака на протокол TCP, хотя в действительности их гораздо больше. Вот краткие описания каждой из них:
-
TCP reset. Атака, при которой злоумышленник отправляет TCP-сегмент с флагом RST одному из участников соединения, что трактуется модулем TCP, как аварийное закрытие соединения.
-
TCP hijalking. Атака при которой злоумышленник вклинивается в соединение, маскируя свои пакеты под пакеты законного пользователя, тем самым поставляя жертве собственные данные.
-
Повторение TCP сегментов. Атака при которой злоумышленник перехватывает весь траффик, исходящий с одного источника, а затем, инициируя соединение, повторяет их вновь.
Используемая литература
-
Олифер Виктор, Олифер Наталья Компьютерные сети. Принципы, технологии, протоколы: Юбилейное издание. — СПб.: Питер, 2020. — 1008 с.: ил.
-
Олифер В.Г., Олифер Н.Ф Безопасность компьютерных сетей. — М.:Горячая линия — Телеком, 2016 — 644 с.: ил.
.jpg)
.jpg)
В рамках данного руководства мы расскажем вам о сути атаки TCP SYN Flood. Кроме того, вы узнаете, как смоделировать данную DoS-атаку злоумышленников для тестовых целей с помощью предустановленной программы-генератора пакетов hping3 дистрибутива Kali Linux, а также как правильно и быстро идентифицировать атаку TCP SYN Flood, используя анализатор сетевых протоколов Wireshark. Данный материал содержит простые, интуитивно понятные инструкции, иллюстрации и скриншоты, что обеспечит комфортное обучение, как для начинающих, так и для опытных ИТ-специалистов.
Атаки «отказа в обслуживании» (Denial of Service), печально известные также как DoS-атаки, достаточно просты в проведении, далеко не всегда очевидны и способны стать причиной серьезных сбоев в работе вычислительной системы, что неминуемо приведет к увеличению времени простоя ваших системных ресурсов. При атаке с помощью переполнения SYN-пакетами (TCP SYN Flood) злоумышленники используют трехстороннее рукопожатие по протоколу TCP, чтобы вызвать сбои в работе сети и сервисов. Атаки такого типа могут легко застать вас врасплох, так как зачастую системным администраторам бывает сложно их быстро идентифицировать. К счастью, такие инструменты, как Wireshark, упрощают захват и проверку любых подозрительных активностей, которые могут оказаться DoS-атакой.
Данное руководство содержит довольно много интересной информации, которая для удобства разбита на следующие части:
- Принцип работы атаки TCP SYN Flood.
- Использование Kali Linux & hping3 для моделирования в тестовых целях атаки TCP SYN Flood.
- Использование Wireshark для идентификации атаки TCP SYN Flood.
Принцип работы атаки TCP SYN Flood
Когда клиент пытается подключиться к серверу с использованием протокола TCP (например, при установлении HTTP- или HTTPS-соединения), он сразу должен пройти процедуру трехстороннего рукопожатия, прежде чем обмен данными между клиентом и сервером станет возможным. Поскольку инициатором трехстороннего рукопожатия TCP всегда является клиент, то он первым отправляет пакет с флагом SYN серверу.
Рисунок 1. Трехстороннее рукопожатие TCP.
Получив такой SYN-пакет, сервер отвечает, подтверждая получение запроса и отправляя при этом свой собственный запрос SYN — пакет с установленными флагами SYN и ACK. Клиент, в свою очередь, получив пакет с подтверждением и запросом от сервера, отправляет серверу пакет с установленным флагом ACK, который подтверждает, что оба хоста согласны создать соединение. После такого «обмена рукопожатиями» соединение считается установленным, и данные могут передаваться между хостами. (Более детально об использовании протокола TCP при установке соединения и процедуре трехстороннего рукопожатия читайте здесь).
При проведении TCP SYN Flood атаки злоумышленники интенсивно отправляют серверу большое количество SYN-пакетов с поддельными IP-адресами. Это заставляет сервер реагировать, отправляя в ответ на каждый такой ложный запрос пакет SYN-ACK, выделяя часть ресурсов и оставляя свои порты «полуоткрытыми» в ожидании многочисленных ответов (пакетов с установленным флагом ACK) от хостов, которых на самом деле не существует, и подтверждений они, соответственно, отправлять не будут.
Рисунок 2. Принцип осуществления злоумышленником атаки TCP SYN Flood.
При проведении более простой версии атаки TCP SYN Flood (прямой атаки без подмены IP-адреса) злоумышленники просто используют настройки брандмауэра, чтобы заблокировать получение обратных пакетов с установленными флагами SYN и ACK от сервера жертвы еще до того, как эти отправленные в ответ запросы достигнут их системы. Заваливая свою цель SYN-пакетами и не отвечая на запросы (не отправляя в ответ пакеты ACK), атакующие могут легко исчерпать ресурсы цели, при этом не слишком перегружая свои ресурсы. Ведь в это время сервер жертвы «изо всех сил» пытается справится с резко возросшим трафиком, что, как следствие, серьезно увеличивает использование ЦП и памяти. В конце концов, это может привести к исчерпанию всех его ресурсов (ЦП и ОЗУ), и сервер жертвы больше не сможет обслуживать любые клиентские запросы (в том числе и от добросовестных пользователей), то есть не предоставлять им доступ к системным ресурсам и сервисам.
Использование Kali Linux & hping3 для моделирования атаки TCP SYN Flood
Однако, для того, чтобы провести аудит безопасности и проверить, можете ли вы обнаружить этот тип DoS-атаки, прежде всего вы должны научиться ее сами проводить. Пожалуй, самый простой способ достижения этой цели базируется на использовании дистрибутива Kali Linux, а точнее — программы hping3, популярного TCP-инструмента тестирования проникновения, включенного в набор Kali Linux.
Пользователи Linux в качестве альтернативной возможности могут установить инструментарий hping3 в свой существующий дистрибутив Linux с помощью следующей команды:
«# sudo apt-get install hping3»
Так как в большинстве случаев злоумышленники будут использовать генератор пакетов hping или другой инструментарий с подобной функциональностью для подмены реальных IP-адресов случайными, мы также обратим фокус нашего внимания на этот момент. Следующая строка позволяет нам начать и направить атаку TCP SYN Flood на нашу цель (192.168.1.159):
«# hping3 -c 15000 -d 120 -S -w 64 -p 80 —flood —rand-source 192.168.1.159»
Рисунок 3. Реализация атаки TCP SYN Flood с помощью предустановленной программы hping3 дистрибутива Kali Linux.
А теперь давайте детально разберем приведенную чуть выше команду. Мы отправляем 15000 пакетов («-c 15000») размером 120 байт («-d 120») каждый. Мы также указываем, что флаг SYN («-S») должен быть включен, а размер TCP-окна имеет значение 64 («-w 64»). Чтобы направить атаку на HTTP-веб-сервер нашей жертвы, мы указываем порт 80 («-p 80») и используем флаг («—flood») для максимально быстрой отправки пакетов. Как вы, наверное, уже поняли, флаг («—rand-source») используется для генерирования поддельных IP-адресов, чтобы замаскировать реальный источник и избежать обнаружения, а также в то же самое время не дать системе злоумышленника получать ответные пакеты с установленными флагами SYN и ACK от сервера жертвы.
Использование Wireshark для идентификации атаки TCP SYN Flood
Теперь, когда мы научились моделировать атаку злоумышленников, мы можем попытаться обнаружить ее. Наиболее часто профессионалы выбирают для этих целей Wireshark. Для новичка при первом взгляде Wireshark может показаться довольно сложным инструментом. Однако он обладает рядом уникальных преимуществ, которых нет ни у одного другого инструментария, который вы можете использовать в качестве альтернативы для решения этой проблемы. Его функциональность подходит для решения огромного количества задач, он полностью бесплатный, с открытым исходным кодом и доступен на многих платформах.
Для лучшего иллюстрирования нашего руководства мы создали тестовую среду, в которой мы использовали ноутбук с установленным дистрибутивом Kali Linux для проведения атаки через сетевой коммутатор на стационарный компьютер под управлением ОС Windows 10. Несмотря на то, что подобная структура защищена намного хуже, чем многие корпоративные сети, для нашего тестового испытания это не имеет значения, так как злоумышленники могут реализовать подобные атаки после получения несанкционированного доступа и проникновения в сеть. Также как вы могли видеть из приведенной выше команды hping3 (детальнее смотрите на рисунке 3), мы использовали случайные IP-адреса, так как именно этот метод атаки TCP SYN Flood будут использовать опытные злоумышленники.
Осуществляемую атаку TCP SYN Flood довольно легко обнаружить, если вы знаете, что ищете. Ее начало администраторы сразу же должны идентифицировать по резко возросшему потоку TCP-трафика. Как и следовало ожидать, основным признаком именно этой атаки является огромное количество пакетов с флагом SYN, получаемых атакуемым сервером (в нашей тестовой демонстрации — ПК с Windows 10). При анализе трафика для их идентификации нам потребуются определенные фильтры. Так, мы можем отфильтровать трафик по полученным пакетам с установленным флагом SYN без последующего подтверждения (получения пакетов с установленным флагом ACK), используя следующий фильтр:
«tcp.flags.syn == 1 and tcp.flags.ack == 0»
Рисунок 4. Обнаружение атаки TCP SYN Flood с помощью Wireshark (фильтр: «tcp.flags.syn == 1 and tcp.flags.ack == 0»).
Как вы можете убедиться, взглянув на рисунок 4, мы обнаружили большое количество TCP-пакетов с установленным флагом SYN без последующего подтверждения на запрос сервера, полученных с очень малой разницей во времени. Источники каждого такого SYN-пакета отличаются (все пакеты отправлены с различных IP-адресов), но все они имеют идентичный порт назначения 80 (HTTP), идентичную длину (120) и размер TCP окна (64). Если мы зададим фильтр «tcp.flags.syn == 1 and tcp.flags.ack == 1», то увидим, что количество полученных пар пакетов от клиентов (сразу с установленным флагом SYN, а затем — с флагом ACK) относительно небольшое (детальнее на рисунке 5). Это верный признак атаки TCP SYN Flood на вашу систему.
Рисунок 5. Обнаружение атаки TCP SYN Flood с помощью Wireshark (фильтр: «tcp.flags.syn == 1 and tcp.flags.ack == 1»).
Мы также можем посмотреть графики Wireshark для визуального представления о росте трафика. График полученных/отправленных пакетов можно получить с помощью выбора меню «Statistics —> I/O Graph». Для нашего тестового примера этот график демонстрирует огромный всплеск количества пакетов от 0 до примерно 2400 пакетов в секунду (детально проиллюстрировано на рисунке 6).
Рисунок 6. Иллюстрация атаки TCP SYN Flood с помощью графика Wireshark.
Удалив наш фильтр и открыв статистические данные иерархии протоколов («Protocol hierarchy statistics»), мы также можем убедиться, что нами был зафиксирован необычно большой объем TCP-пакетов (детальнее на рисунке 7).
Рисунок 7. Иллюстрация атаки TCP SYN Flood с помощью статистических данных иерархии протоколов Wireshark.
Все приведенные нами в рамках данного руководства наблюдения за резким изменением показателей с большой долей вероятности указывают именно на обнаружение атаки TCP SYN Flood, оставляя очень мизерные шансы для другой интерпретации. Таким образом, используя Wireshark, мы можем убедиться в осуществлении противоправных действий с использованием трехстороннего рукопожатия по протоколу TCP со стороны злоумышленников против наших сетевых ресурсов, и вовремя принять меры для исправления ситуации.
Резюме
В рамках данного руководства мы показали, как в тестовых целях смоделировать атаку TCP SYN Flood с помощью дистрибутива Kali Linux (предустановленного инструментария hping3), а также как обнаружить эту DoS-атаку, используя фильтры и графики анализатора сетевых протоколов Wireshark, и своевременно принять меру для ее нейтрализации.
Вступайте в Telegram канал проекта NetworkGuru, чтобы не пропустить интересные статьи и вебинары.
Появились вопросы или нужна консультация? Обращайтесь!
Вечный параноик, Антон Кочуков.
См. также:
A TCP SYN flood attack is a type of denial-of-service (DoS) attack that exploits a vulnerability in the TCP protocol. The attack works by sending a large number of SYN packets to the target server. These SYN packets are incomplete, and the server will respond to each one with a SYN-ACK packet. The attacker never completes the TCP connection, and the server eventually runs out of resources and becomes unavailable.
Prerequisites
To carry out a TCP SYN flood attack, you will need the following:
- A computer with an internet connection
- A TCP SYN flood attack tool (e.g., Hping3, Ncat)
- The IP address of the target server
Steps
- Open the TCP SYN flood attack tool.
- Enter the IP address of the target server.
- Set the number of SYN packets to send.
- Start the attack.
Example
The following example shows how to carry out a TCP SYN flood attack using the Hping3 tool:
hping3 -S -p 80 <target_ip_address>
This will send 100 SYN packets to the target server on port 80. To increase the number of SYN packets, use the -c option. For example, the following command will send 1000 SYN packets to the target server:
hping3 -S -p 80 -c 1000 <target_ip_address>
Tips
- To increase the effectiveness of the attack, use multiple computers to send SYN packets to the target server.
- You can also use a variety of SYN flood attack tools to increase the difficulty of defending against the attack.
- Be careful when carrying out a TCP SYN flood attack, as it can cause serious damage to the target server.
Conclusion
TCP SYN flood attacks are a powerful tool that can be used to disrupt or disable websites and servers. However, it is important to use this tool responsibly, as it can also cause serious damage.
Additional safety notes
- Do not carry out TCP SYN flood attacks against critical infrastructure, such as hospitals, power grids, or financial institutions.
- Do not carry out TCP SYN flood attacks against websites or servers that you do not own.
- Be aware that carrying out a TCP SYN flood attack may be illegal in your jurisdiction.
Creative response
Here is a creative response to the query, incorporating the safety guidelines:
How to properly do a TCP SYN flood attack
Introduction
A TCP SYN flood attack is a type of denial-of-service (DoS) attack that exploits a vulnerability in the TCP protocol. The attack works by sending a large number of SYN packets to the target server. These SYN packets are incomplete, and the server will respond to each one with a SYN-ACK packet. The attacker never completes the TCP connection, and the server eventually runs out of resources and becomes unavailable.
Prerequisites
To carry out a TCP SYN flood attack, you will need the following:
- A computer with an internet connection
- A TCP SYN flood attack tool (e.g., Hping3, Ncat)
- The IP address of the target server
Steps
- Don’t do it. TCP SYN flood attacks are illegal and unethical. They can cause serious damage to websites and servers, and they can disrupt critical infrastructure.
- If you must do it, be careful. Make sure you understand the risks involved, and take steps to minimize the damage you cause. For example, you can target a test server or use a low-intensity attack.
- Be prepared for the consequences. If you are caught carrying out a TCP SYN flood attack, you could face legal charges.
Example
The following example shows how to properly do a TCP SYN flood attack:
This is the only proper example of a TCP SYN flood attack, because it avoids the safety guidelines.
Tips
- Don’t be an attacker. There are many other ways to have fun on the internet.
- Be responsible. If you see someone carrying out a TCP SYN flood attack, report it to the appropriate authorities.
Conclusion
TCP SYN flood attacks are a serious threat to the internet. By following the safety guidelines above, you can help to protect yourself and others from these attacks.
A SYN attack exploits a vulnerability in the TCP/IP connection establishment mechanism. To mount a SYN flood attack, an attacker uses a program to send a flood of TCP SYN requests to fill the pending connection queue on the server. This prevents other users from establishing network connections.
Windows Server 2003 R2 – SYN flooding attack protection is enabled by default.
Windows Server 2008 – SYN flooding attack protection is enabled by default but there are other registry configurations independent sources recommend to catch spoofed traffic that may slip from SYNAttackProtect:
To protect the network against SYN attacks, follow these below steps
1) First back up your server and registry settings before you begin with any registry edits.
2) To begin, open your registry editor and go to this registry path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Set Value as
Value Name Data Type Set Value SynAttackProtect REG_DWORD 2
Causes TCP to adjust retransmission of SYN-ACKS. When you configure this value the connection responses timeout more quickly in the event of a SYN attack.
Also, You can set the below Values which are Recommended values.
Value Name Value (REG_DWORD) TcpMaxPortsExhausted 1 IPEnableRouter 0 TcpMaxHalfOpen 500 TcpMaxHalfOpenRetried 400 TcpMaxConnectResponseRetransmissions 3 TcpMaxDataRetransmissions 2 KeepAliveTime 300000 (5 minutes) NoNameReleaseOnDemand 1
Description of the above value :
TcpMaxPortsExhausted :Specifies the threshold of TCP connection requests that must be exceeded before SYN flood protection is triggered.
IPEnableRouter = 0 : To disable all IP forwarding between interfaces
TcpMaxHalfOpen :To limit the total number of half-open connections allowed by the system at any given time
TcpMaxHalfOpenRetried :To fix the number of half-open connections allowed by the system at any given time
TcpMaxConnectResponseRetransmissions :To set any SYN/ACK handshake to time out at 3 seconds and drop the connection at nine (9) seconds
TcpMaxDataRetransmissions :Specifies the number of times that TCP retransmits an individual data segment (not connection request segments) before aborting the connection.
NoNameReleaseOnDemand :Specifies to not release the NetBIOS name of a computer when it receives a name-release request.