Что такое атака syn flood и как она работает?

Обнаружение 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.

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

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

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

Защита от основных видов DoS-атак

Чтобы защитится от HTTP-flood нужно прибавить одновременное количество максимальных подключений к БД сервера, нужно установить перед апачем еще и энжинкс для кэширования всех запросов. Данный конфиг приведу файликом, который можно глянуть:

nginx.conf

Защита от ICMP-flood

Расскажу сейчас как бороться от ICMP-flood, а всего то нужно отключить ответы на запросы ICMP ECHO:

# sysctl net.ipv4.icmp_echo_ignore_all=1

Так же это можно сделать с помощью брандмауэра:

# iptables -A INPUT -p icmp -j DROP --icmp-type 8

Защита от UDP-flood

Т.к UDP-пакеты посылаются на разные UDP-сервисы, то  собственно достаточно вырубить их от мира и прописать собственно ограничение на количество соединений к DNS-серверу:

# iptables -I INPUT -p udp --dport 53 -j DROP -m iplimit --iplimit-above 1

Защита от SYN-flood

Эта данная защита  заключается в выключении самой очереди «полуоткрытых» TCP-соединений:

# sysctl -w net.ipv4.tcp_max_syn_backlog=1024

Так же нужно включить сам механизм TCP syncookies, для этого следует выполнить:

# sysctl -w net.ipv4.tcp_syncookies=1

Следующим этапом мы ограничиваем максимального число «полуоткрытых» соединений с 1-го IP для нужного порта:

# iptables -I INPUT -p tcp --syn --dport 80 -m iplimit --iplimit-above 10 -j DROP

У вас  должна быть настроена система, которая будет анализировать трафик и которая сможет своевременно узнать о  ДДос-атаке, а так же по мере возможности, принимать меры по ее избежанию.

Защита от DDoS с iptables, готовый скрипт

Защита от спуфинга

Для этого нужно выполнить:

# net.ipv4.conf.default.rp_filter = 1

Проверяем TCP-соединение каждую минуту (если на др стороне — нормальный сервер, то сразу ответит. (Стандартное значение — 2ч):

# net.ipv4.tcp_keepalive_time = 60

Проверяем через 10 сек:

# net.ipv4.tcp_keepalive_intvl = 10

Устанавливаем количество проверок перед закрытием соединения:

# net.ipv4.tcp_keepalive_probes = 5

Я очень бегло рассказал и описал что и как, но постепенно ( со временем) я буду рассказывать и приводить примеры по борьбе с ДДосиками, так же я буду более глубоко уделять вниманию каждому из видов атак. Чтобы это я мог сделать, мне нужно время, время для   того чтобы я смог найти нужный и полезный материал, а так же более подробно расписал, чтобы всем было понятно. Надеюсь я нормально пишу статьи, если есть замечания или может предложения, добавляйтесь  в группы, можно и в друзья, а так же можете просто писать в комментах.

Собственно, я завершу наверное на этом «защита от ddos атак», надеюсь было полезно. Спасибо что посещаете мой сайт  https://linux-notes.org

Практическая часть.¶

Для эффективной защиты от распределённых сетевых атак типа «отказ в обслуживании» требуется своевременное обнаружение начала атаки. Чтобы обнаружить DDoS-атаку необходимо накапливать статистические данные о трафике сервера в сети, работающем в штатном режиме. При знании среднестатистических значений характеристик сервера, можно отследить появление аномалии трафика в сети.

Для выполнения данной лабораторной работы необходимо создать две виртуальные машины или объединить в локальную сеть два компьютера. Одна машина будет жертвой, другая злоумышленником.

На машине жертве необходимо установить:

Примечание

Дополнительно ознакомьтесь со следующими ресурсами , , , .

На машине злоумышленника необходимо установить:

Примечание

Чтобы сделать сервис уязвимым, ознакомьтесь со следующими ресурсами , .

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

Скриншоты мониторинга и трафика

Примечание

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

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

Пошаговый алгоритм методики:

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

Примечание

Скачать набор программного обеспечения можно по этой ссылке .

Debian: борьба с DDoS

По умолчанию ОС Debian и другие ОС не в состоянии поддерживать огромное количество соединений создаваемое ботнетом. Необходимо внести изменения в настройки ядра, чтобы укрепить стек TCP/IP. Пример такой конфигурации:

net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.eth0.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.core.rmem_max = 996777216
net.core.wmem_max = 996777216
net.ipv4.tcp_rmem = 4096 87380 4194304
net.ipv4.tcp_mem= 786432 1048576 996777216
net.ipv4.tcp_wmem = 4096 87380 4194304
net.ipv4.tcp_max_orphans = 2255360
net.core.netdev_max_backlog = 10000
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_synack_retries = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 494967295
kernel.shmall = 268435456
net.core.somaxconn= 16096

Аккуратно меняем конфигурацию ядра и перезагружаем сервер…

FreeBSD: борьба с DDoS

Уменьшаем время ожидания ответного пакета на запрос SYN-ACK (защита от SYN-флуда):

# sysctl net.inet.tcp.msl=7500

Превращаем сервер в черную дыру. Так ядро не будет слать ответные пакеты при попытке подключиться к незанятым портам (снижает нагрузку на машину во время DDoS’а на случайные порты):

# sysctl net.inet.tcp.blackhole=2
# sysctl net.inet.udp.blackhole=1

Ограничиваем число ответов на ICMP-сообщения 50-ю в секунду (защита от ICMP-флуда):

# sysctl net.inet.icmp.icmplim=50

Увеличиваем максимальное количество подключений к серверу (защита от всех видов DDoS):

# sysctl kern.ipc.somaxconn=32768

Включаем DEVICE_POLLING — самостоятельный опрос сетевого драйвера ядром на высоких нагрузках (существенно снижает нагрузку на систему во время DDoS’а):

Пересобираем ядро с опцией «options DEVICE_POLLING»;
Активируем механизм поллинга: «sysctl kern.polling.enable=1»;
Добавляем запись «kern.polling.enable=1» в /etc/sysctl.conf.

  • FreeBSD для обслуживания 100-200 тысяч соединений

  • Методы защиты от DDoS нападений — попробовать скрипт написать по tcpdump
  • ANTI DDOS. ЗАЩИТА ОТ DDOS

Универсальные советы

Чтобы не попасть в безвыходное положение во время обрушения DDoS-шторма на системы, необходимо тщательным образом подготовить их к такой ситуации:

  1. Все сервера, имеющие прямой доступ во внешнюю сеть, должны быть подготовлены к простому и быстрому удаленному ребуту (sshd спасет отца русской демократии). Большим плюсом будет наличие второго, административного, сетевого интерфейса, через который можно получить доступ к серверу в случае забитости основного канала.
  2. ПО, используемое на сервере, всегда должно находиться в актуальном состоянии. Все дырки — пропатчены, обновления установлены (простой, как сапог, совет, которому многие не следуют). Это оградит тебя от DoS-атак, эксплуатирующих баги в сервисах.
  3. Все слушающие сетевые сервисы, предназначенные для административного использования, должны быть спрятаны брандмауэром ото всех, кто не должен иметь к ним доступ. Тогда атакующий не сможет использовать их для проведения DoS-атаки или брутфорса.
  4. На подходах к серверу (ближайшем маршрутизаторе) должна быть установлена система анализа трафика (NetFlow в помощь), которая позволит своевременно узнать о начинающейся атаке и вовремя принять меры по ее предотвращению.

Виды 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 т.к это основной сетевой протокол. Но мы можем выявлять и блокировать случаи, когда соединения слишком много.

UDP-флуд

Метод захламления полосы пропускания. Основан на бесконечной посылке UDP-пакетов на порты различных UDP-сервисов. Легко устраняется за счет отрезания таких сервисов от внешнего мира и установки лимита на количество соединений в единицу времени.

#Ставим ограничение на 5 соединений на 80 порт.
iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 5 -j REJECT
# Разрешаем только одно одновременное соединение с одного айпи на smtp
iptables -A FORWARD -p tcp --syn --dport smtp -m connlimit --connlimit-above 1 -j DROP
#Ставим ограничение на 200 соединений на 1720 порт.
iptables -A INPUT -p tcp --syn --dport 1720 -m connlimit --connlimit-above 200 -j REJECT
# udp 5060
$IPT -A INPUT -p udp --dport 5060 -m connlimit --connlimit-above 60 -j LOG --log-level info --log-prefix "REJECT 5060: "
$IPT -A INPUT -p udp --dport 5060 -m connlimit --connlimit-above 60 -j REJECT
# tcp 1720
$IPT -A INPUT -p tcp --syn --dport 1720 -m connlimit --connlimit-above 60 -j LOG --log-level info --log-prefix "REJECT 1720: "
$IPT -A INPUT -p tcp --syn --dport 1720 -m connlimit --connlimit-above 60 -j REJECT

Attack description

When a client and server establish a normal TCP “three-way handshake,” the exchange looks like this:

  1. Client requests connection by sending SYN (synchronize) message to the server.
  2. Server acknowledges by sending SYN-ACK (synchronize-acknowledge) message back to the client.
  3. Client responds with an ACK (acknowledge) message, and the connection is established.

In a SYN flood attack, the attacker sends repeated SYN packets to every port on the targeted server, often using a fake IP address. The server, unaware of the attack, receives multiple, apparently legitimate requests to establish communication. It responds to each attempt with a SYN-ACK packet from each open port.

The malicious client either does not send the expected ACK, or—if the IP address is spoofed—never receives the SYN-ACK in the first place. Either way, the server under attack will wait for acknowledgement of its SYN-ACK packet for some time.

Progression of a SYN flood.

During this time, the server cannot close down the connection by sending an RST packet, and the connection stays open. Before the connection can time out, another SYN packet will arrive. This leaves an increasingly large number of connections half-open – and indeed SYN flood attacks are also referred to as “half-open” attacks. Eventually, as the server’s connection overflow tables fill, service to legitimate clients will be denied, and the server may even malfunction or crash.

While the “classic” SYN flood described above tries to exhaust network ports, SYN packets can also be used in DDoS attacks that try to clog your pipes with fake packets to achieve network saturation. The type of packet is not important. Still, SYN packets are often used because they are the least likely to be rejected by default.

See how Imperva DDoS Protection can help you with TCP DDoS attacks.

Request Demo
or learn more

Defending SYN Flood Attack

• Using SYN cookies

This is the most effective method of defending from SYN Flood attack. The use of SYN cookies allow a server to avoid dropping connections when the SYN queue fills up. Instead, the server behaves as if the SYN queue has been enlarged. The server sends back the appropriate SYN+ACK response to the client but discards the SYN queue entry. If the server then receives a subsequent ACK response from the client, it is able to reconstruct the SYN queue entry using information encoded in the TCP sequence number.

SYN cookies can be enabled by adding the following to /etc/sysctl.conf

net.ipv4.tcp_syncookies = 1

After modifying the sysctl configuration file, you need to execute the following command to load sysctl settings from the file /etc/sysctl.conf

sysctl -p

• Increasing the SYN backlog queue

An optional defending technique is to increase the SYS backlog queue size. The default size is 1024. This can be done by adding the following to /etc/sysctl.conf

net.ipv4.tcp_max_syn_backlog = 2048

• Reducing SYN_ACK retries

Tweaking the kernel parameter tcp_synack_retries causes the kernel to close the SYN_RECV state connections earlier. Default value is 5.

net.ipv4.tcp_synack_retries = 3

• Setting SYN_RECV timeout

Lowering the timeout value for SYN_RECV will help in reducing the SYN flood attack. The default value is 60 and we can reduce it to 40 or 45. This can be done by adding the following line to sysctl.conf.

net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv=45

• Preventing IP spoofing

The following sysctl parameter will help to protect against IP spoofing which is used for SYN flood attacks.

net.ipv4.conf.all.rp_filter = 1

Many hosting companies provide protection against SYN attack by deploying firewalls that employ SYN flood defense such as Netscreen or Appsafe.

Detecting SYN flood Attack

The generic symptom of SYN Flood attack to a web site visitor is that a site takes a long time to load, or loads some elements of a page but not others. If you suspect a SYN Flood attack on a web server, you can use netstat command to check the web server connection requests that are in “SYN_RECEIVED” state.

netstat -tuna | grep :80 | grep SYN_RECV

If it shows numerous connections with this state, the server could be under SYN Flood attack. If the attack is direct with large number of SYN_RECV packets from a single IP address, you can stop this attack by adding that IP address in the firewall. If you have APF or CSF firewall installed on your server, you can accomplish this by executing the following command:

apf -d IPADDRESS
csf -d IPADDRESS

Methods of mitigation

While modern operating systems are better equipped to manage resources, which makes it more difficult to overflow connection tables, servers are still vulnerable to SYN flood attacks.

There are a number of common techniques to mitigate SYN flood attacks, including:

Micro blocks—administrators can allocate a micro-record (as few as 16 bytes) in the server memory for each incoming SYN request instead of a complete connection object.

SYN cookies—using cryptographic hashing, the server sends its SYN-ACK response with a sequence number (seqno) that is constructed from the client IP address, port number, and possibly other unique identifying information. When the client responds, this hash is included in the ACK packet. The server verifies the ACK, and only then allocates memory for the connection.

RST cookies—for the first request from a given client, the server intentionally sends an invalid SYN-ACK. This should result in the client generating an RST packet, which tells the server something is wrong. If this is received, the server knows the request is legitimate, logs the client, and accepts subsequent incoming connections from it.

Stack tweaking—administrators can tweak TCP stacks to mitigate the effect of SYN floods. This can either involve reducing the timeout until a stack frees memory allocated to a connection, or selectively dropping incoming connections.

Obviously, all of the above mentioned methods rely on the target network’s ability to handle large-scale volumetric DDoS attacks, with traffic volumes measured in tens of Gigabits (and even hundreds of Gigabits) per second.

Imperva mitigates a 38 day-long SYN flood and DNS flood multi-vector DDoS attack.

Imperva DDoS protection leverages Anycast technology to balance the incoming DDoS requests across its global network of high-powered scrubbing centers. With the combined capacity of its global network, Incapsula can cost-effectively exceed attacker resources, rendering the DDoS attack ineffective. The service is build to scale on demand, offering ample resources to deal with even the largest of volumetric DDoS attacks.

To assure business continuity, Imperva filtering algorithm continuously analyzes incoming SYN requests, using SYN cookies to selectively allocate resources to legitimate visitors. This enables transparent DDoS mitigation, wtih no downtime, latency of any other business disruptions.

Оцените статью
Рейтинг автора
5
Материал подготовил
Илья Коршунов
Наш эксперт
Написано статей
134
Добавить комментарий