Что такое syn flood атака

Разбор атак на части: SYN-flood

Spoofed SYN — атака, при которой заголовки пакетов подделывается таким образом, что место реального отправителя занимает произвольный либо несуществующий IP-адрес.

Дисклеймеры

Дисклеймер №1

Все, описанное в этом и последующих топиках – по сути не является know-how. Все методики – открытые, и в то или иное время (некоторые – от 2003 года) были опубликованы в открытых источниках. Я взял на себя труд только свести их в одно и описать «глобальную стратегию» защиты, ориентированную на системных администраторов, обслуживающих небольшие проекты, расположенные на выделенных серверах (описанную стратегию можно применить и в shared-проектах, но реализация будет настолько запредельно ужасной, что писать об этом нет никакого желания)

Дисклеймер №2

В топике не рассматриваются аппаратные решения защиты – во-первых, они отлично рассмотрены в многочисленных статьях производителей этих самых решений, во вторых, проекты, располагающие одним сервером не часто могут себе их позволить (грубо говоря, цена на работающие решения стартует от 20 тысяч евро), в третьих – автор не располагает достаточными данными и опытом по работе с таким специализированным железом, что бы делать глобальные выводы о методах и эффективности такой защиты – навряд ли кому-то интересен обзор решений от двух вендоров из дюжины, не подкрепленный серьезной рабочей статистикой их использования. Но стоит заметить, что оба аппаратных решения, которые мне приходилось использовать, как правило очень эффективны на SYN-атаках при выполнении ряда условий.

Дисклеймер №3

В топике не рассматриваются провайдеры защиты от DDoS-атак – сервис-инженеры этих организаций смогут описать их методы работы лучше и подробнее. Стоило бы, наверное, сделать обзор самих провайдеров как таковых — с точки зрения клиента (в разное время проекты, в которых я принимал участие, были клиентами Dragonara, Blacklotus, Gigenet, Vistnet (в настоящий момент), Prolexic (в настоящий момент) и ряда продавцов услуг вышеперечисленных компаний), но это выбивается из рамок топика, попробуем поговорить об этом позже. Опять же, стоит заметить что все провайдеры защиты, с которыми работают или работали проекты автора, справляются с проблемой SYN-атак, показывая хорошую эффективность.

Немного механики и википедии

Не хотелось бы превращать топик в подобие RFC и цитировать и так всем известные истины, поэтому ограничимся тем, чем интересен TCP с точки зрения SYN-атаки и пробежимся по верхам.

Во-первых, TCP — это один из наиболее используемых транспортных протоколов, поверх которого располагаются большинство протоколов прикладных. Во-вторых, он обладает рядом особых признаков (явно подтверждаемые начало и завершение соединения, управление потоком, etc. ) – которые делают его реализацию относительно сложной и ресурсоемкой.

В контексте статьи интересно рассмотреть механизм установки TCP-соединения – трехстороннее рукопожатие. В первом приближении на уровне «клиент-сервер» выглядит это вот так: клиент отправляет серверу SYN-пакет, на который отвечает SYN+ACK.Клиент отправляет в ответ ACK на SYN сервера и соединение переходит в состояние установленного.

SYN-атака – отправка в открытый порт сервера массы SYN-пакетов, не приводящих к установке реального соединения по тем или иным причинам, что влечет за собой создание «полуоткрытых соединений», которые переполняют очередь подключений, вынуждая сервер отказывать в обслуживании очередным клиентам. Плюс к этому, TCP RFC обязывает сервер отвечать на каждый входящий SYN, что дополнительно бьет как по ресурсам сервера, так и по каналу передачи данных. В прочем, если вы уже сталкивались с – по сути – любыми DDoS атаками – описанное выше вы знаете и без меня. Переходим к конкретным рекомендациям.

Один в поле

Используй то, что под рукою, и не ищи себе другое – что можно сделать, находясь один на один с атакой? Честно говоря, не многое, но бывает, что хватает и этого. Далее описано, что делать с FreeBSD, так как в наших проектах в 90% случаев используется именно эта система. Впрочем, от ОС к ОС разница будет невелика – принципы одинаковы.

Первое – необходимо получить доступ к серверу (да, в этом тоже может быть сложность, особенно если атака масштабная и/или продолжительная – сервер просто выбрал все буферы или имеет 100% загрузку CPU). Обычно для этого достаточно закрыть атакуемый сервис фаерволом или просто его – сервис – погасить (впрочем, при обнаружении атаки это нужно сделать в любом случае, хотя бы для того, что бы иметь возможность делать на сервере что-то еще).

Второе – получить первые сведения о атаке. Если у вас уже сделан мониторинг входящего трафика – отлично, если нет – открываем фаервол/поднимаем сервис и используем старые-добрые tcpdump и netstat, что бы узнать, что именно атакуют и какой размер атаки в пакетах в секунду. Попутно можно быстро просмотреть сети, из которых идут массовые запросы – входят ли они в типичную для вашего сервиса аудиторию. Все это пригодится в будущем.

Третье – на интерфейсе, где расположен атакуемый IP-адрес должен остаться только он один. Каждый алиас будет снижать производительность системы. Выражается это в разных числах для разных систем, но числа эти – серьезные, каждый алиас может стоить дополнительных 2-3 тысяч пакетов в секунду.

Четвертое – если вы используете какой-либо фаерволл для входящего трафика по атакуемому адресу – все правила, кроме блокирования, должны быть отключены – к примеру, при spoofed SYN-атаке вероятность того, что вам поможет SYN-proxy от PF стремится к нулю, а CPU это займет очень серьезно.

Пятое – настраиваем систему. Чудес тут не будет, для них нужен рояль в кустах в виде подготовленных драйверов и специально купленных сетевых карт, а единственные две общие рекомендации, которые серьезно отражаются на возможности приема SYN-атаки давно всем известны:
— Размазать обработку прерываний по процессорам сервера;
— Включить syn-cookies и отключить syn-cache.

Остальной тюнинг системы поможет выжать дополнительные 5-10 тысяч пакетов, что в условиях атаки вряд ли окажется определяющим. На случай, если он кому-нибудь пригодится – вот максимально общий конфиг (без включения опций, требующих пересборки ядра или специализированных драйверов):

Система уровня десктопного компьютера, сконфигурированная в соответсвии с данными рекомендациями:

Система уровня IBM System x3630 M3, сконфигурированная в соответсвии с данными рекомендациями:

Детальные конфигурации ОС и машин, и, собственно, как мы пришли именно к ним — я попробую рассказать в следующем топике.

Одно дело делаем

Что делать помимо тюнинга системы В принципе, есть чем заняться.

Тут стоит сделать небольшое отступление – большинство хостинг-компаний помогут в борьбе с атакой крайне неохотно, если помогут вообще, и в этом их трудно винить. Но как минимум данные о атаке они предоставят – если придется работать с провайдерами защиты, это, вкупе с информацией, собранной вами в ходе атаки, здорово облегчит жизнь.

Если хостер попался понимающий (что действительно большая редкость) – то работаем по следующему алгоритму — параллелим и блокируем, блокируем и параллелим:
Если у нас есть несколько сетевых карточек (если нет – просим поставить) – включаем их в режим LACP (для этого придется включить аналогичные опции на свитче хостера) – это даст фактически полуторный прирост производительности (отдельные тонкости процесса мы рассмотрим позже — объять необъятное в рамках топика никак не получается) Выходим вот к такой производительности:

Просим заблокировать все неиспользуемые порты и протоколы – SYN-атака может с легкостью сменится UDP-атакой.
На эти действия способен фактически любая хостниг-компания. Но если вам посчастливилось работать с серьезной компанией — попросите заблокировать трафик из региона, где не проживает большая часть аудитории вашего проекта (например, Китай) – обычно это означает анонс блекхола для вашей сети для магистральных провайдеров определенного региона. Как правило, SYN-атака совершается из Азии, ввиду дешевизны и массовости, и, следовательно, такой анонс может серьезно помочь в борьбе с атакой либо вообще исключить ее возможность.

Помимо вышеописанных мер можно посоветовать использовать GeoDNS-like сервис – при некоторых условиях (атака ведется по домену, к примеру) это сработает аналогично анонсированию блекхола для определенных сетей.

Напоследок

Надеюсь, статья поможет вам справиться с проблемой SYN-флуда, не превысив годовой бюджет какой-нибудь африканской страны. Конечно, здесь даны только самые общие рекомендации, но поверьте – в 90% случаев их вполне достаточно. И главное — don’t panic!

UPD. Продолжение находится в стадии написания, и скоро будет выложено тут. Оставайтесь с нами!

Mikrotik firewall: защита от DDOS атак и SYN-flood

Целью DDoS-атаки является вывод из строя маршрутизатора. Для выстраивания защиты от DDoS-атак необходимо понимать как они устроены. На данный момент наиболее известные типы DDoS-атак основаны на ICMP-flood, UDP-flood, HTTP-flood и SYN-flood и. Названия этих атак говорят о способе воздействия на сетевое устройство и какой протокол при этом используется.

Освоить MikroTik Вы можете с помощью онлайн-куса « Настройка оборудования MikroTik ». Курс основан на официальной программе MTCNA. Автор курса – официальный тренер MikroTik. Подходит и тем, кто уже давно работает с микротиками, и тем, кто еще их не держал в руках. В курс входит 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.

Универсального рецепта защиты никто не даст, так как многое зависит от того какая инфраструктура находится за firewall маршрутизатора и с чем она взаимодействует в интернете. Но даже используя базовые принципы защиты маршрутизатора и корректируя их под конкретные условия можно отсечь большое количество внешних угроз.

Базовый принцип защиты роутера заключается в том, что мы должны блокировать всё кроме разрешенного — нормально закрытый firewall. Поэтому для цепочек input, после разрешенных правил, последним должно идти правило отбрасывающее любые пакеты. Подробно базовая настройка безопасности роутера mikrotik рассматривалась в этой статье.

Виды DDoS-атак

Рассмотрим более подробно виды DDoS-атак, чтобы понять каким образом настраивать firewall mikrotik.

ICMP-flood

ICMP-flood — отправка большего числа поддельных icmp-запросов (многим известно как ping). ICMP-пакеты не требуют подтверждения, в отличии от TCP и поэтому трудно отделить мусорный трафик от легитимного.

В случае использования правила «нормально закрытого firewall» никаких дополнительных действий предпринимать не надо — весь icmp-трафик будет отклонен, если он отдельно не разрешен. Чтобы позволить «пинговать» роутер с определенных адресов нужно создать разрешающее правило.

UDP-flood

UDP-flood схож с icmp-flood в том плане, что его пакеты так же не требуют подтверждения и отсутствует контроль над процессом обмена данными.

Бороться с udp-flood можно так же как и с icmp-flood путем полной блокировки трафика, если это допустимо в ваших условиях. Стоит отдельно отметить, что протокол UDP часто используется в VoIP телефонии. Если вы используете подключение к АТС из интернета, то это необходимо учесть и разрешить подключения на необходимые порты, обычно это порт 5060.

SYN-flood

При атаке типа SYN-flood используется TCP-протокол и его принцип установления сеанса связи. Атакующий посылает поддельные syn запросы на установления соединения. Наш маршрутизатор одобрительно отвечает, но атакующий хост не устанавливает соединение и продолжает слать syn-запросы. Таким образом таблицу памяти соединений начинают заполнять полуоткрытые соединения, что начинает вызывать отказ в обслуживании соединений.

Мы не можем просто блокировать TCP-соединения как это было с icmp и udp т.к это основной сетевой протокол. Но мы можем выявлять и блокировать случаи, когда соединения слишком много.

Обнаружение DDoS и защита от атак.

Для настройки firewall Mikrotik на обнаружение и защиты от DDOS-атак взята за основу статья на официальном Wiki Mikrotik.

Для того, чтобы выявить DDoS атаку нам необходимо захватывать все новые соединения и перенаправлять их в отдельную цепочку chain=detect-ddos.

Далее создаем новую цепочку chain=ddos, в которой для каждой пары хостов «SrcIP:DstIP» разрешаем определенное количество соединений. Для избежания блокирования важных хостов, например DNS-сервер с адресом 192.168.0.1, можно добавить правило, которое будет возвращать соединения с сервером в стандартную цепочку.

Значения, заданные в примере, не являются образцовыми и должны устанавливаться исходя из условий вашей инфраструктуры.

Здесь стоит обратить внимание на параметр dst-limit. Первое значение rate, второе burst. Для burst задано значение 42 и интервал в 1 секунду — это значит, что в течении первой секунды количество соединений может быть увеличено до 42. Значение burst не должно быть меньше rate, потому-что в этом случае правило будет пропускать в первую секунду меньшее количество соединений и по истечении секунды сработает Rate.

Если говорить простым языком, то Burst это одноразовое разрешение на превышение скорости. А превышение скорости не может быть меньше той скорости, которую вы установили как норму — Rate.

Сейчас нам надо обработать те соединения, которые превысили заданные лимиты — их мы добавим в address-list ‘ddoser’ (атакующий) и ‘ddosed’ (атакуемый). Тайм-аут жизни списка 10 минут или определите сами для себя.

Теперь мы можем блокировать хосты ведущие DDoS атаку на основе созданных списков. Сбрасывать пакеты можно в стандартной цепочке firewall таким образом:

Либо создать правило в Raw, чтобы отбрасывать пакеты до их маршрутизации и снизить нагрузку на процессор.

Защита от SYN-flood.

Для защиты конкретно от SYN-flood атак правила настраиваются примерно таким же образом, но нужно будет указать protocol=tcp и tcpflag=syn. То есть правило для переброса в цепочку ddos для дальнейшей обработки будет выглядеть примерно так:

P.S. По-моему тема защиты Mikrotik от DDoS недостаточно подробно рассмотрена в рунете на данный момент. Поэтому жду вопросов, предложений и комментариев от вас.

8 thoughts on “ Mikrotik firewall: защита от DDOS атак и SYN-flood ”

Думаю, в некоторых случаях требуется более глубокий анализ траффика.

В пример приведу задачу, которую мне на данный момент решить не удалось.

Имеется RB4011. Защита от DDoS настроена по тому же принципу, что описан у Вас — сбор адресов в листы и дроп в raw (дроп в filter не годится, потому как даже при не самой серьёзной атаке процессор уходит в 100%). В большинстве случаев работает отлично. Даже мой домашний hAP ac2 таким образом переваривает большинство атак до 900 Мбит/с, оставляя ещё сотку для выхода в интернет (у меня дома гигабит). Процессор при этом нагружен всего в 25-35%. Но.

Столкнулся с атакой, которая для КАЖДОГО пакета подменяет src-address. В итоге простая атака всего в 50000 пакетов в секунду забивает адрес-лист тремя миллионами адресов за минуту. На RB4011 гигабайт оперативки заканчивается, kernel crash, ребут. Конечно, вопрос с оперативкой решается ограничением времени жизни листа десятью секундами, но в целом задачу это не решает, т.к. в raw попадают только пакеты начиная со второго от адрес-листа. А в случае с подменой исходящего адреса для каждого пакета все пакеты являются первыми. Как следствие — вся атака попадает в filter, процессор уходит в 100%, роутер лежит, цель атаки достигнута при ширине атаки всего в 200 Мбит/с.

Нужны более глубокие методы анализа трафика. Продолжаю изучать вопрос. Буду рад, если свяжетесь со мной для дальнейшего общения на эту тему.

admin Автор записи 26.06.2020 в 15:35

Андрей, спасибо за обратную связь. В ближайшее время в статью внесу исправления более широко охватывающие типы DDoS-атак.

я понимаю что это перевод вот этого https://wiki.mikrotik.com/wiki/DDoS_Detection_and_Blocking , но,
jump-target=ddos
add chain=detect-ddos
имя цепочки почему не совпадает? в оригинале всё совпадает.

admin Автор записи 19.08.2020 в 17:48

Благодарю за указание на допущенную ошибку в имени цепочки — будет исправлено.

Добрый день. Читаю, не сходится.
Вы пишете правило:
add chain=detect-ddos dst-limit=32,42,src-and-dst-addresses/1s action=return

Описываете функцию как:
Здесь стоит обратить внимание на параметр dst-limit. Первое значение rate, второе burst. Для burst задано значение 42 и интервал в 1 секунду — это значит, что в течении первой секунды количество соединений может быть увеличено до 42. Значение burst не должно быть меньше rate, потому-что в этом случае правило правило будет пропускать в первую секунду меньшее количество соединений и по истечении секунды сработает Rate.

Вопрос: Ошибка где — вместо 32 надо ставить 1 или Вы ведете речь про 32 секунды, тгда при чем здесь 1 секунда?

Как функцию-то правильно писать?

admin Автор записи 04.09.2020 в 06:26

Здравствуйте.
dst-limit=32,42,src-and-dst-addresses/1s
В конце dst-limit указан интервал /1s.
32 — rate, 42 — burst.
32 и 42 это количество соединений разрешенных в этот интервал.

Добрый вечер. Прошу ногами не пинать, Микротик только начинаю осваивать. Прописал все команды как в статье, но фильтр не срабатывает. Такое впечатление что он определяет пакеты которые атакуют, и сервер который атакует, но пакеты не отбрасывает. Что проделываю не так? Если нужны какие то данные могу предоставить.

Моделируем и определяем DoS атаку типа TCP SYN Flood при помощи Wireshark

В рамках данного руководства мы расскажем вам о сути атаки 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 без последующего подтверждения на запрос сервера, полученных с очень малой разницей во времени. Источники каждого такого SYN-пакета отличаются (все пакеты отправлены с различных IP-адресов), но все они имеют идентичный порт назначения 80 (HTTP), идентичную длину (120) и размер TCP окна (64). Если мы зададим фильтр «tcp.flags.syn == 1 and tcp.flags.ack == 1», то увидим, что количество полученных пар пакетов от клиентов (сразу с установленным флагом SYN, а затем — с флагом ACK) относительно небольшое (детальнее на рисунке 5). Это верный признак атаки TCP SYN Flood на вашу систему.

Мы также можем посмотреть графики 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, и своевременно принять меру для ее нейтрализации.

Появились вопросы или нужна консультация? Обращайтесь!

источники:

http://soft-setup.ru/mikrotik-firewall-zashhita-ot-ddos-atak-i-syn-flood/

http://networkguru.ru/dos-ataka-tcp-syn-flood/