Защита от ddos linux ubuntu

Как защитить Linux-сервер от DDoS?

Защита сервера от DDoS своими силами.

В данной статье мы расскажем как Вы можете защитить свой сервер от небольшой DDoS атаки под управлением самой популярной операционной системы Linux(CentOS, Debian, Ubuntu и т.п.).

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

Проверяем, есть ли DDoS атака

Итак, приступим. Первым делом посмотрим с какого IP сколько подключений к нашему проекту, для этого используем команду:

netstat -ntu | awk ‘‘| cut -d: -f1 | sort | uniq -c | sort -nr | more

Таким образом мы увидим с каких адресов наиболее много обращений. Если это 1-3 адреса — то это обычная DoS атака, и мы решим проблему заблокировав эти несколько адресов через iptables, командой:

iptables -A INPUT -s ip_адрес -j DROP

Если же адресов гораздо больше — то можно автоматизировать это действие и попробовать защитить свои проекты на уровне Вашего сервера.

Автоматизация защиты при DDoS атаке

Понятно, что все вышеописанное вручную выполнять долго. Давайте автоматизируем этот процесс и напишем небольшой скрипт. Мы так же написали подробные комментарии, что бы Вы могли изменять его параметры.

#!/bin/sh # Находим IP входящих соедениений и записываем их в файл ddos.ip netstat -ntu | awk ‘‘ | cut -d: -f1 | sort | uniq -c | sort -nr | grep -v «127.0.0.1» > /usr/local/antidd/ddos.ip # создаем DROP правила (сбрасывать соединения) для IP с количеством подключений более 30 и добавляем их в файл awk ‘ 50) >’ /usr/local/antidd/ddos.ip >> /usr/local/antidd/iptables_ban.sh # запускаем скрипт который забанит адреса в iptables bash /usr/local/antidd/iptables_ban.sh # Очищаем скрипт, который производит бан cat /dev/null > /usr/local/antidd/iptables_ban.sh

Давайте теперь его установим и добавим в крон. Создадим для него каталог:

Теперь перейдем в эту папку командой:

И вставим в него код нашего скрипта. Выставляем права 777 на файл скрипта командой:

chmod 777 /usr/local/antidd/antidd.sh

Запускаем скрипт для теста командой:

В папке со скриптом появятся два файла:

ddos.ip — в него скидываются все подключения
iptables_ban.sh — сформированный скрипт для блокировки IP адресов

Теперь добавим задание в CRON. Откроем файл:

И добавляем в него следующее:

*/5 * * * * root /bin/sh /usr/local/antidd/antidd.sh @monthly root iptables -F

Первая строка — запускает анти-ddos скрипт каждые 5 минут.
Вторая — производит раз в месяц очистку всех блокировок (что бы не нагружать IPTABLES).

На этом наша простенькая защита автоматизирована и работает.

Если возникнут какие-либо проблемы — откройте тикет из личного кабинета, и наши специалисты обязательно Вам помогут.

Источник

Защита от DDOS атак своими руками

Снова меня DDOS-ят. В этот раз атака не сильная и заметил я ее случайно во время очередного этапа самообразования с целью заполнения пробелов в знаниях в области безопасности.

Если кто-то открыл эту статью просто так, то рекомендую все же ее прочитать. Я все писал «понятным»языком для лучшего восприятия.

DoS—атака (Denial of Service) — закидывание неугодных ресурсов различным флудом, приводящее их к нокдауну. А DDoS—атака — это такая DoS—атака, которую осуществляет не один энтузиаст, а разгневанная толпа, желающая Страшный Суд, Ад и Погибель неправославному ресурсу. Весь профит этого метода заключается в том, что грамотно спланированную атаку невозможно отразить вообще. В результате сервер начинает как минимум безбожно тормозить при ответах на нормальные запросы, а то и вовсе ложится, не вынеся такого издевательства.

Проще говоря, что такое DoS? Это, к примеру, когда ведёшь разговор с кем-то, но тут подходит алкаш, и начинает громко нести бред. Говорить либо невозможно, либо очень сложно. Решение: зовёшь охрану, она скручивает синяка и уводит.

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

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

Для начала нужно посмотреть сколько запросов идет с IP адресов клиентов. Для этого в консоли выполним команду:

netstat -ntu | awk ‘‘| cut -d: -f1 | sort | uniq -c | sort -nr | more

Видно, что с IP 192.230.77.217 поступило 129 обращений. «Алкаш» (смотреть выше) один, значит не DDOS, а просто DOS—атака. Заголовок статьи менять уже не буду — позже поймете почему.

Ради интереса, можно посмотреть на какие порты идут обращения с этого IP адреса выполнив команду:

Ага. 443 порт пользуется популярностью. Я думал как обычно на 80-й будет, но в принципе не важно.

Блокирую по всем портам исходящие и входящие соединения с этого IP адреса командами:

iptables -A INPUT -s 192.230.77.217 -j DROP

iptables -A INPUT -d 192.230.77.217 -j DROP

Исходящие блокирую «на всякий случай». Вдруг меня взломают и начнут атаковать с моего сервера. Неприятностей потом будет куча, поэтому лучше подстраховаться.

Все порты блокирую на случай, если будет идти подбор паролей к FTP или еще к чему-то.

Проверяем заново текущую ситуацию после применения блокировки командой:

netstat -ntu | awk ‘‘| cut -d: -f1 | sort | uniq -c | sort -nr | more

Все чисто. Враг не пройдет!

Автоматизация защиты при DDoS атаке

Понятно, что все вышеописанное ручками выполнять лениво и не практично. Давайте этот процесс автоматизируем для нашего удобства и оперативности реагирования на атаки.

На основе одного примера, найденного в Интернете, я написал свой скрипт для защиты от DoS и DDoS атак. Он получился простой, но очень эффективный. Скрипт блокирует IP адреса, количество подключений с которых превысило 50. Это значение можно изменять — скрипт хорошо прокомментирован.

# Находим все соединения на все порты и записываем их в файл ddos.iplist
netstat -ntu | awk ‘‘ | cut -d: -f1 | sort | uniq -c | sort -nr | grep -v «127.0.0.1» > /usr/local/ddos/ddos.iplist

# создаем DROP правила (не выдавать ответа сервера на запросы забаненых) для IP с количеством подключений более 50 и добавляем их в файл
awk ‘ 50) >’ /usr/local/ddos/ddos.iplist >> /usr/local/ddos/iptables_ban.sh

# запускаем скрипт бана IP атакующих
bash /usr/local/ddos/iptables_ban.sh

# Очищаем скрипт, который производит бан
cat /dev/null > /usr/local/ddos/iptables_ban.sh

Давайте его установим.

Для начала, необходимо создать рабочую папку для нашего скрипта. Вводим в консоли команду:

Теперь перейдем в эту папку командой:

Загружаем скрипт в эту папку командой:

Выставляем права 755 на файл скрипта командой:

Запускаем скрипт для теста командой:

В папке со скриптом появятся два файла:

ddos.iplist — в него скидываются все подключения

iptables_ban.sh — сформированный скрипт для блокировки IP адресов

Теперь открываем файл /etc/crontab и добавляем в него следующие строки

*/5 * * * * root /bin/sh /usr/local/ddos/ddos.sh
@monthly root iptables -F

• Первая строка — запускает наш скрипт каждые 5 минут.
• Вторая — производит раз в месяц очистку всех блокировок (амнистия).

За неделю работы скрипта ситуация с банами IP сложилась следующая (команда iptables -L).

На этом все. Возникнут вопросы — пишите в комментариях.

Источник

Оптимальная защита от DDoS с помощью netstat и iptables

Доброго времени суток!

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

Перекопав полчища статей и опробовав множество вариантов, так и не нашел, что помогло бы с защитой. Взяв за основу статьи Простой и эффективный метод отразить http DDoS от 50мбит с помощью nginx и iptables и (D)DoS Deflate решил написать свой скрипт. Ну вернее не решил, а методом тыка и исправлений он получился сам.

Должен заметить, что статья от Алексея Кузьмина не идеальна, т.к. в логах nginx`a не достаточно копаться, да и обработка логов может потребовать много ресурсов. А именно в моем случае создавались логи более 50 Гиг, плюс запросы шли не «GET / HTTP/1.1», а «GET / HTTP/1.0», плюс, как оказалось, мой сервер сам от себя получал редиректы (127.0.0.1), которые не отображались в логах, которые отображались в запросе

Суть скрипта такова, что через определенное время кроном запускается скрипт и проверяет все соединения с сервером, ip и кол-во их соединений которые записываются в файл. Потом запускается другой скрипт, который смотрит, если соединения, превышают заданное число (у меня стоит 20), то создается скрипт с блокировкой этих айпишников через iptables.

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

Теперь к практике:
создаем каталог, где будет скрипт

в нем создаем файл ddos.sh и меняем его права:

записываем в него:

Вот в принципе и все. Теперь запускаем кронтаб, предпочитаю команду:

и добавляем новую задачу в него, выполняющуюся каждые 10 минут:

Также я изменил ротацию логов в файле /etc/logrotate.d/nginx от nginx`a, чтобы многогиговые файлы не создавались

и записал еще задачу в крон, выполняющуюся каждый час

ну и для больше комфорта еще и раз в сутки решил перезагружать сервак, опять же через крон:

общий список заданий, выведенный через crontab -l:

я записывал все под пользователем root, поэтому если вы не под этим пользователем, перед каждой командой стоит добавить root, типа:

Все пути делал абсолютными, т.к. не все команды без полного пути срабатывали.

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

Источник

Доступные методы борьбы с DDoS-атаками для владельцев vds/dedicated серверов с Linux

Начать свое присутствие на Хабре мы решили с материала, подготовленного для Конференции уральских веб-разработчиков, в котором описаны проверенные на собственной практике и оказавшиеся вполне успешными методы борьбы с DDoS-атаками. Целевая аудитория данной статьи — это программисты, имеющие в распоряжении vds или dedicated. Статья не претендует на полноценное руководство и многие сисадминские нюансы в ней намеренно опущены. Мы рассматриваем только DDoS типа http flood как наиболее распространенный тип DDoS и наиболее дешевый для заказчика.

Целевая аудитория данной статьи – это программисты, имеющие в распоряжении VDS или Dedicated.

Связка nginx – apache – fastcgi/wsgi. Узкие места

Типовая схема организации работы веб-приложения состоит из 3х уровней: это reverse proxy-сервер (например nginx), apache (web-сервер) и какое-то fastcgi/wsgi/… приложение. На практике имеют место вырожденные случаи, когда нет apache или при использовании mod_php/mod_python, когда нет выделенного приложения (оно встроено в веб-сервер), но суть работы схемы при этом не меняется, меняется только количество уровней в ней.

Fcgi сервер может запустить несколько десятков процессов, параллельно обрабатывающих входящие запросы. Увеличить это значение можно только до определенного предела, пока процессы помещаются в памяти. Дальнейшее увеличение приведет к swapping’у. При DDoS-атаке или при высокой посещаемости, когда все текущие процессы fcgi уже заняты обработкой поступивших запросов, вновь поступающие запросы apache ставит в очередь, пока либо не освободится какой-то из fcgi процессов, либо не возникнет таймаут нахождения в очереди (в этом случае возникает ошибка 503).

Apache точно также имеет лимит на количество коннектов, как правило несколько сотен (на порядок больше, чем fcgi). После того, как все коннекты к apache исчерпаны, запросы в очередь уже ставит nginx.
Nginx, в силу своей асинхронной архитектуры, может спокойно держать несколько тысяч коннектов при очень скромном расходе памяти, поэтому типовые DDoS-атаки не доходят до уровня, когда nginx не в состоянии принимать новые коннекты, если nginx настроен соответствующим образом.

Фильтрация трафика на nginx. Разбор логов nginx

Предлагаемая нами методика сводится к тому, чтобы лимитировать общее количество запросов к сайту определенным значением (например, 1500 в минуту, в зависимости от того, сколько максимум хитов может выдержать движок сайта при текущих серверных мощностях). Все, что будет превышать это значение, мы первоначально будем фильтровать с помощью nginx (limit_req_zone $host zone=hostreqlimit:20m rate=1500r/m;).
Затем мы будем смотреть в логи nginx и вычислять там те IP-адреса, которые были отфильтрованы более определенного количества раз за определенный промежуток времени (например, более 100 раз за 5 минут) и запрещать доступ к нам этим IP-адресам с помощью firewall.

Почему мы не используем традиционный и часто рекомендуемый лимит по подключениям с одного и того же ip адреса (limit_req_zone $binary_remote_addr . )? Во-первых, под этот лимит попадут клиенты провайдеров, сидящие за nat’ом. Во-вторых, установить универсальное значение порога невозможно, потому что есть сайты с ajax и большим количеством js/css/картинок, у которых в принципе на загрузку одной страницы может требоваться несколько десятков хитов, и использовать такой порог можно только индивидуально для каждого сайта. В-третьих, для так называемых «вялотекущих» DDoS-атак боты вообще не будут попадать под этот порог – ботов будет много, но каждый из них в отдельности будет делать немного запросов за короткий период времени, в результате мы ничего не сможем отфильтровать, а сайт при этом работать не будет.

Для того чтобы воспользоваться нашим методом, конфигурационный файл nginx, при работе nginx в качестве reverse proxy для apache, должен выглядеть примерно следующим образом:

В этом конфиге также подразумевается, что apache у нас слушает на loopback интерфейсе на 127.0.0.1:80, а nginx на 80-м порту на нашем внешнем ip-адресе (1.2.3.4) и на порту 8080 на 127.0.0.1.

Отфильтрованные nginx’ом хиты будут сопровождаться такой записью в error.log nginx’а:

Чтобы получить из error.log список всех блокировавшихся ip-адресов мы можем выполнить следующее:

Но мы с вами помним, что в этом случае мы блокируем всех, кто обратился к сайту после того, как счетчик обращений насчитал 1500 раз в минуту, поэтому не все заблокированные – боты. Ботов же можно выделить, если провести какую-то условную черту по количеству блокировок. Как правило, для черты выбирается значение в несколько сотен раз за 5-15 минут. Например, мы пополняем список ботов раз в 5 минут и считаем что все, кого nginx заблокировал более 200 раз – боты.

Теперь перед нами стоит две проблемы:

1. Как выбрать из лога период «последние 5 минут»?
2. Как отсортировать только тех, кто был заблокирован более N раз?

Первую проблему решаем при помощи tail -c +OFFSET. Идея сводится к тому, что после разбора error.log мы записываем во вспомогательный файл его текущий размер в байтах (stat -c ‘%s’ error.log > offset), а при следующем разборе отматываем error.log на последнюю просмотренную позицию (tail -c +$(cat offset)). Таким образом, запуская разбор логов раз в 5 минут, мы будем просматривать только ту часть лога, которая относится к последним 5 минутам.

Вторую проблему решаем при помощи скрипта на awk. В итоге получим (THRESHOLD — это тот самый лимит по количеству блокировок, после которого соответствующий IP-адрес считается принадлежащим атакующему нас боту):

Подразумевается, что этот набор команд выполняется в той директории, где лежит error.log от nginx, то есть как правило это/var/log/nginx. Полученный в результате список мы можем отправить в firewall на блокировку (об этом ниже).

Как просто можно построить список сетей для бана

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

Первое, что нам может помочь, это список сетей Рунета на сайте NOC masterhost. В настоящий момент в этом списке насчитывается почти 5000 сетей. Большинство российских сайтов ориентированы на посетителей из России, поэтому отсечь всех заграничных посетителей, а вместе с этим и всех заграничных ботов, выглядит вполне логичным решением. Однако, в последнее время внутри Российских сетей возникает все больше и больше самостоятельных ботнетов, поэтому такое решение хоть и обосновано, но очень часто не спасает от атаки.

Если сайт имеет устоявшееся community (ядро), то мы можем выбрать список IP адресов постоянных посетителей из логов веб-сервера за последние 3-4 недели. Хотя новые посетители на время атаки на сайт попадать не смогут, но зато старые активные пользователи скорее всего даже не заметят никакой атаки. Кроме того, среди постоянных посетителей вряд ли будут боты, поэтому такой метод может в принципе сам по себе остановить атаку на какое-то время.

Если сайт местного значения, то можно забанить на firewall всех, кроме сетей местных провайдеров и сетей поисковых систем (Яндекс).

Введение в iptables, пример простейшего firewall

В ОС Linux firewall работает на базе iptables. Фактически суть работы iptables сводится к тому, чтобы для каждого пакета трафика, принимаемого снаружи или отправляемого с сервера, был применен определенный набор правил, которые могут повлиять на судьбу данного пакета. В самом простом случае правила просто говорят, что пакет нужно либо принять (ACCEPT), либо отбросить (DROP). Правила подразделяются на цепочки (chains). Например, принимаемые сервером из Интернета пакеты попадают в цепочку INPUT, где для каждого пакета с самого начала правил в цепочке проверяется, подходит ли данный пакет под описанные в правиле условия и если подходит, то к пакету применяется это правило, а если нет, то пакет передается следующему правилу. Если ни одно из правил для пакета не было применено, то к пакету применяется политика по-умолчанию (policy).

В качестве простого примера напишем правила firewall, которые разрешают подключение к серверу по ssh только из нашего офиса (с ip-адреса 1.2.3.4), а всем остальным доступ по ssh блокируют:

Эти строки можно записать в текстовый файл и загрузить в firewall с помощью: iptables-restore firewall.txt.

Работают эти правила следующим образом. Первая строка — разрешаем весь трафик для всех соединений, которые уже открыты (процедура handshake пройдена). Вторая строка — разрешаем любой трафик с ip-адреса 1.2.3.4 и помечаем комментарием, что это наш офис. На самом деле сюда доходят только пакеты, устанавливающие какое-либо соединение, то есть пакеты типа syn и ack, все остальные пакеты проходят только первую строку. Третья строка – запрещаем всем подключение по tcp на 22-й порт. Сюда доходят попытки подключения (syn, ack) по ssh от всех, кроме нашего офиса.

Интересно, что первую строчку можно смело удалить. Плюс наличия такой строки в том, что для уже открытых соединений в firewall отработает всего одно правило, а пакеты в рамках уже открытых соединений – это подавляющее большинство принимаемых нами пакетов, то есть firewall с такой строкой в самом начале практически не будет вносить никаких дополнительных задержек в работу сетевого стека сервера. Минус — эта строка приводит к активации модуля conntrack, который держит в памяти копию таблицы всех установленных соединений. Что затратнее – держать копию таблицы соединений или необходимость обрабатывать несколько правил firewall на каждый пакет? Это индивидуальный нюанс каждого сервера. Если firewall содержит всего несколько правил, на наш взгляд правильнее строить его правила так, чтобы модуль conntrack не активизировался.

В iptables можно создавать дополнительные цепочки, задаваемые пользователем. В каком-то смысле это выглядит как аналог вызова функций в языках программирования. Создаются новые цепочки просто: iptables -N chain_name. Используются создаваемые таким образом цепочки для того, чтобы разделять firewall на разные логически блоки.

Рекомендуемая структура firewall для противодействия DDoS

Рекомендуемая нами структура для противодействия DDoS состоит из следующих логических блоков:

1. Разрешаем трафик по уже установленным соединениям.
2. Прописываем разрешения для «своих» ip-адресов.
3. Таблица whitelist – это исключения.
4. Таблица DDoS – это идентифицированные нами боты.
5. Таблица friends – это сети РуНета, которым мы разрешаем доступ, если пакет дошел до этого уровня.
6. Всем остальным – -j DROP.

В терминах iptables это выглядит так:

Опять же, целесообразность наличия второй строки под вопросом и в зависимости от полного размера firewall она может как ускорять его работу, так и тормозить.

Заполняем таблицу friends:

Проблема такого firewall в его монстроидальности: таблица friends в случае Рунета будет содержать порядка 5000 правил. Таблица DDoS в случае более-менее среднего DDoS’а будет содержать еще 1-2 тысячи записей. Итого firewall будет состоять из 5-7 тысяч строк. При этом все пакеты, прилетающие от заграничных отправителей, которые должны быть просто отброшены, на самом деле будут проходить все 5-7 тысяч правил, пока не доберутся до последнего: -A INPUT -j DROP. Сам по себе такой firewall будет отъедать огромное количество ресурсов.

Ipset – решение для монстроидальных firewall’ов

Ipset полностью решает проблему с монстроидальными firewall, в которых присутствуют тысячи строк с описанием того, что делать с пакетами с разными адресами отправителей или получателей. Ipset представляет собой утилиту по управлению специальными set’ами (наборами однотипных данных), где для нескольких заранее определенных типов данных сделаны специальные hash-таблицы, позволяющие очень быстро устанавливать факт наличия или отсутствия определенного ключа в этой таблице. В каком-то смысле это аналог memcached, но только гораздо более быстрый и позволяющий при этом хранить только несколько конкретных типов данных. Создадим новый набор данных для хранения информации об ip-адресах DDoS-ботов:

Здесь последним параметром указывается тип создаваемой таблицы: nethash – это set для списка сетей, iphash – для отдельных ip адресов. Есть разные варианты таблиц, подробности в man ipset. Соответственно whitelist и friends – это таблицы типа nethash, а DDoS — iphash.
Чтобы воспользоваться созданной таблицей ipset в firewall, достаточно одного правила (строки firewall), например:

Добвить какой-то ip-адрес во вновь созданную таблицу можно так:

Таким образом, весь наш firewall при использовании ipset сводится к:

Заполняем set friends (тип nethash):

Заполняем set ddos из показанной ранее команды:

Используем модуль TARPIT

Модуль iptables под названием tarpit представляет собой так называемую «ловушку». Принцип работы tarpit такой: клиент присылает syn-пакет для попытки установки handshake (начало установки tcp-соединения). Tarpit отвечает ему syn/ack пакетом, о котором тут же забывает. При этом никакое соединение на самом деле не открывается и никакие ресурсы не выделяются. Когда от бота приходит конечный ACK-пакет, модуль tarpit отправляет назад пакет, устанавливающий размер окна для передачи данных на сервер равным нулю. После этого любые попытки закрыть это соединение со стороны бота tarpit’ом игнорируются. Клиент (бот) считает, что соединение открыто, но «залипло» (размер окна 0 байт) и пытается закрыть это соединение, но он ничего не может сделать вплоть до истечения таймаута, а таймаут, в зависимости от настроек – это порядка 12-24 минут.

Использовать tarpit в firewall можно следующим образом:

Собираем xtables-addons

К сожалению, модули ipset и tarpit в стандартном наборе современных дистрибутивов отсутствуют. Их нужно установить дополнительно. Для более-менее свежих дистрибутивов Debian и Ubuntu это делается просто:

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

Тюнинг ядра

Как правило, разговоры о борьбе с DDoS-атаками начинаются с рекомендаций по тюнингу ядра ОС. Однако, на наш взгляд, если ресурсов в принципе мало (например, при наличии менее одного Гб памяти), то тюнинг ядра смысла не имеет, так как почти ничего не даст. Максимум полезного в этом случае будет — включить так называемые. syncookies. Включение syncookies позволяет эффективно бороться с атаками типа syn flood, когда сервер забрасывается большим количеством syn-пакетов. Получая syn-пакет сервер должен выделить ресурсы на открытие нового соединения. Если за syn-пакетом не последует продолжение процедуры установки соединения, сервер выделит ресурсы и будет ждать, пока не произойдет таймаут (несколько минут). В конечном итоге, без syncookies, при достаточном количестве отправленных серверу syn-пакетов, он не сможет более принимать соединения, потому что система израсходует на хранение информации о полуоткрытых соединениях все свои ресурсы.

Параметры ядра, о которых пойдет речь, правятся с помощью команды sysctl:

Опция -w означает, что вы хотите записать новое значение в какой-то параметр, а ее отсутствие – что вы хотите прочитать текущее значение этого параметра. Рекомендуется поправить следующие параметры:

Источник