A SYN flood is a form of denial-of-service attack in which an attacker sends a progression of SYN requests to an objective’s framework trying to consume enough server assets to make the framework inert to authentic activity.
TCP three-way handshake
Typically, when a customer begins a TCP connection with a server, the customer and server trade a progression of messages which regularly runs this way:
1) The customer asks for a connection by sending a SYN (synchronize) message to the server.
2) The server recognizes this request by sending SYN-ACK back to the customer.
3) The customer reacts with an ACK, and the connection is built up.
This is known as the TCP three-way handshake, and is the establishment for each connection set up utilizing the TCP protocol.
Working of SYN flood attack
A SYN flood attack works by not reacting to the server with the normal ACK code. The pernicious customer can either basically not send the normal ACK, or by satirizing the source IP address in the SYN, bringing about the server to send the SYN-ACK to a distorted IP address – which won’t send an ACK on the grounds that it “knows” that it never sent a SYN.
The server will sit tight for the affirmation for quite a while, as straightforward system clog could likewise be the reason for the missing ACK. In any case, in an attack, the half-open connections made by the pernicious customer tie resources on the server and may in the long run surpass the resources accessible on the server. By then, the server can’t be access by any customers.
Security against SYN Flood Attacks
There are various surely understood countermeasures including:
1) Filtering
2) Increasing Backlog
3) TCP half-open: The term half-open alludes to TCP associations whose state is out of synchronization between the two potentially because of an accident on one side. A connection which is being set up is otherwise called a embryonic connection. The absence of synchronization could be because of malignant purpose. A TCP connection is alluded to as half-open when the host toward one side of that TCP association has slammed, or has generally evacuated the attachment without informing the flip side. In the event that the rest of the end is inert, the association may stay in the half-open state for unbounded time frames. These days, the term half-open association is regularly used to portray an embryonic connection, i.e. a TCP connection which is being set up.
The TCP convention has a three state framework for opening a connection. To begin with, the beginning endpoint (A) sends a SYN bundle to the destination (B). A is currently in an embryonic state (particularly, SYN_SENT), and anticipating a reaction. B now redesigns its portion data to demonstrate the approaching connection from A, and conveys a request to open a channel back (the SYN/ACK bundle). Now, B is additionally in an embryonic state (particularly, SYN_RCVD). Note that B was put into this state by another machine, outside of B’s control.
Under typical conditions (see foreswearing of-administration attack for conscious disappointment cases), A will get the SYN/ACK from B, overhaul its tables (which now have enough data for A to both send and get), and send a last ACK back to B. When B gets this last ACK, it additionally has adequate data for two-way correspondence, and the connection is completely open. Both endpoints are currently in an established state.
4) Firewalls and Proxies
5) Reducing SYN-RECEIVED Timer
6) SYN Cache
7) Recycling the Oldest Half-Open TCP
8) Hybrid Approaches
9) SYN cookies: SYN cookie is a strategy used to oppose SYN surge assaults. Daniel J. Bernstein, the procedure’s essential creator, characterizes SYN treats as “specific decisions of beginning TCP arrangement numbers by TCP servers”. The utilization of SYN treats permits a server to abstain from dropping associations when the SYN line tops off. Rather, the server carries on as though the SYN line had been amplified. The server sends back the suitable SYN+ACK reaction to the customer yet disposes of the SYN line section. In the event that the server then gets a resulting ACK reaction from the customer, the server can reproduce the SYN line section utilizing data encoded as a part of the TCP succession number.
If you need any further assistance please contact our support department.
Spoofed SYN - атака, при которой заголовки пакетов подделывается таким образом, что место реального отправителя занимает произвольный либо несуществующий IP-адрес.
Так как по сути SYN является частым инструментом "интенсивной конкурентной борьбы " и - в то же время - большинство решений DDoS mitigation показывают впечатляющую эффективность именно на этом виде атак, то и мы начнем c SYN-flood, рассмотрев spoofed-вид атаки, как самый грозный из них.
Дисклеймеры
Дисклеймер №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 тысяч пакетов, что в условиях атаки вряд ли окажется определяющим. На случай, если он кому-нибудь пригодится – вот максимально общий конфиг (без включения опций, требующих пересборки ядра или специализированных драйверов):
Net.isr.direct=1
kern.ipc.nmbclusters=400000
net.inet.tcp.nolocaltimewait=1
net.inet.tcp.recvspace=16384
net.inet.tcp.sendspace=32768
net.inet.tcp.msl=5000
net.inet.tcp.blackhole=1
net.inet.ip.intr_queue_maxlen=3000
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
net.inet.icmp.log_redirect=1
net.inet.ip.redirect=0
net.inet.icmp.maskrepl=1
net.inet.tcp.syncookies_only=1
net.route.netisr_maxqlen=4096
kern.ipc.maxsockbuf=83886080
net.inet.ip.intr_queue_maxlen=10240
Система уровня десктопного компьютера, сконфигурированная в соответсвии с данными рекомендациями:
First# netstat -w1 -h -d
input (Total) output
packets errs idrops bytes packets errs bytes colls drops
260K 0 0 15M 230K 0 13M 0 0
Система уровня IBM System x3630 M3, сконфигурированная в соответсвии с данными рекомендациями:
Second# netstat -w1 -h -d
input (Total) output
packets errs idrops bytes packets errs bytes colls drops
477K 0 0 36M 457K 0 25M 0 0
Детальные конфигурации ОС и машин, и, собственно, как мы пришли именно к ним - я попробую рассказать в следующем топике.
Одно дело делаем
Что делать помимо тюнинга системы В принципе, есть чем заняться.Тут стоит сделать небольшое отступление – большинство хостинг-компаний помогут в борьбе с атакой крайне неохотно, если помогут вообще, и в этом их трудно винить. Но как минимум данные о атаке они предоставят – если придется работать с провайдерами защиты, это, вкупе с информацией, собранной вами в ходе атаки, здорово облегчит жизнь.
Если хостер попался понимающий (что действительно большая редкость
) – то работаем по следующему алгоритму - параллелим и блокируем, блокируем и параллелим
:
Если у нас есть несколько сетевых карточек (если нет – просим поставить) – включаем их в режим LACP (для этого придется включить аналогичные опции на свитче хостера) – это даст фактически полуторный прирост производительности (отдельные тонкости процесса мы рассмотрим позже - объять необъятное в рамках топика никак не получается) Выходим вот к такой производительности:
Second# netstat -w1 -h -d
input (Total) output
packets errs idrops bytes packets errs bytes colls drops
1.2M 16K 0 65M 1.1M 0 59M 0 0
Просим заблокировать все неиспользуемые порты и протоколы – SYN-атака может с легкостью сменится UDP-атакой.
На эти действия способен фактически любая хостниг-компания. Но если вам посчастливилось работать с серьезной компанией - попросите заблокировать трафик из региона, где не проживает большая часть аудитории вашего проекта (например, Китай) – обычно это означает анонс блекхола для вашей сети для магистральных провайдеров определенного региона. Как правило, SYN-атака совершается из Азии, ввиду дешевизны и массовости, и, следовательно, такой анонс может серьезно помочь в борьбе с атакой либо вообще исключить ее возможность.
Помимо вышеописанных мер можно посоветовать использовать GeoDNS-like сервис – при некоторых условиях (атака ведется по домену, к примеру) это сработает аналогично анонсированию блекхола для определенных сетей.
Напоследок
Надеюсь, статья поможет вам справиться с проблемой SYN-флуда, не превысив годовой бюджет какой-нибудь африканской страны. Конечно, здесь даны только самые общие рекомендации, но поверьте – в 90% случаев их вполне достаточно. И главное - don"t panic!UPD. Продолжение находится в стадии написания, и скоро будет выложено тут. Оставайтесь с нами!
Disclaimer 1: прошу простить мне тот факт, что статья довольно скомкана, и многие темы не раскрыты полностью. Не стесняйтесь задавать вопросы в комментариях. Я, в свою очередь, постараюсь раскрыть наиболее интересные темы в дальнейших статьях.
Disclaimer 2: в сети есть множество статей с заголовками “Как защитить сервер от SYN-атак” или “Защита Linux от DDoS”. Должен предупредить, что многим из них ни в коем случае нельзя слепо верить! Они зачастую написаны людьми, которые плохо понимают, что происходит во время атаки, и рекомендуют делать сумасшедшие вещи - кто-то “оптимизирует” sysctl так, что на сервер перестает проходить даже нормальный трафик, а большинство советуют еще и включить syncookies, чего делать категорически нельзя при большей части реальных атак!
Этой статьей я преследую 3 цели:
Что такое SYN-атака?
SYN-флуд или SYN-атака - это метод вызова отказа в обслуживании, влияющий на хосты, выполняющие серверные процессы TCP. Атака используется тот факт, что TCP хранит состояние сессии после получения SYN-сегмента на порту, находящемся в состоянии LISTEN. Основная идея - эксплуатировать это поведение, заставляя хост хранить столько состояний для ложных полуоткрытых сессий, что у него не остается ресурсов для установки новых соединений (RFC4987).
С SYN-флудом относительно сложно бороться, поэтому атаки этого типа так популярны. Почему же?
1) Обычно используются случайные Source IP, которые бесполезно банить, потому что они заново генерируются в каждом пакете;
2) SYN-атака потребляет мало ресурсов на стороне атакующего и очень много на стороне жертвы;
3) Защита от этого типа атак довольно комплексная, полна нюансов и требует времени, чтобы понять и внедрить ее.
Я считаю, что серверы, которые потенциально подвержены атакам (по сути, все серверы, которые имеют публичные IP-адреса, в особенности Web-серверы) должны быть защищены от SYN-атак заранее.
Рисунок 1: SYN-атака
Как производятся SYN-атаки?
Пример утилиты, которая часто используется для осуществления атак - hping3. Вы можете использовать ее для того, чтобы устроить стресс-тест своего сервера до того, как злоумышленники сделают это за Вас.
hping3 - это богатая возможностями утилита, которая может проделывать множество типов атак с различными параметрами. Я не буду давать мастер-класс по ее использованию, покажу только пример того, как можно проверить свой сервер на уязвимость к небольшой SYN-атаке:
# hping3 -S <--fast|--faster|--flood> -p 80 xx.xx.xx.xx
80 (HTTP) в этом примере - это порт назначения. Обратите внимание на другие параметры (hping3 --help), чтобы понять, как атаки могут отличаться друг от друга.
Пользуйтесь этой утилитой аккуратно и только в целях тестирования собственных ресурсов! Если быть честным, большая часть Интернета уязвима к этим простым операциям, даже если у атакующего канал значительно меньше, чем у атакуемого.
Как определить и измерить SYN-атаку?
1) Во время SYN-атаки атакующий открывает множество подключений к Вашему серверу, но никогда не завершает их, и подключения продолжают висеть в состоянии SYN_RECV. Их можно подсчитать вот так:
# netstat -anutp | grep SYN_RECV | wc -l
Если это число >30 - Вы, вероятно, под SYN-атакой.
2) Вы можете мониторить текущую нагрузку на сеть с помощью vnstat:
# vnstat -l -i eth0
Это очень полезная утилита, которая поможет понять, насколько сильная идет атака.
Нажмите F2, зайдите в "Display options" и выберите "Display threads in a different color". Розовым цветом можно будет увидеть нагрузку от системных прерываний.
4) Просмотрите SYN-сегменты, которые получает сервер - что в них общего? "-c 100" говорит tcpdump ограничиться 100 пакетами.
# tcpdump -i eth0 -nn "tcp port 80" and "tcp == 2" -c 100
И наконец, помните, что многие SYN-атаки не “равномерны”, у них есть пики и провалы, которые нужно учитывать в процессе анализа.
Рисунок 2. Динамика типичной атаки
Сначала - главное
Сетевая карта, прерывания, очереди…
Первая вещь, над которой нужно поработать - это драйвер сетевой карты. Когда на сетевую карту приходит фрейм, она должна инициировать системное прерывание, которое говорит процессору приостановить выполнение текущей задачи и обработать пришедшую порцию трафика. Однако если бы каждый фрейм вызывал незамедлительное прерывание и “отвлекал” CPU от текущих задачи, заметную деградацию производительности можно было бы наблюдать даже на простейших сетевых операциях, таких как передача файла по FTP. Поэтому эти прерывания организованы в очередь, которая скапливается на сетевой карте и обрабатывается процессором за один раз. Обычно это происходит 250-1000 раз в секунду, чем реже - тем меньше загрузка CPU, тем выше задержка.
С другой стороны, большинство современных десктопов и серверов имеют насколько процессорных ядер. Поскольку каждое из них работает для ОС как отдельный процессор, мы можем равномерно распределить между ними нагрузку от прерываний. Есть 2 способа это сделать.
1) Первый и рекомендуемый - использовать аппаратные очереди. Современные сетевые карты имеют несколько очередей прерываний, обычно 4-16. По какой-то причине, в Linux они часто отключены по умолчанию. Нам нужно их включить, а затем равномерно распределить их по процессорам.
2) Второй способ называется RPS - Receive Packet Steering. Это довольно новый механизм ядра, который автоматически распределяет нагрузку между всеми ядрами, неважно, есть на карточке несколько аппаратных очередей или нет. Используйте этот способ только если у Вас больше ядер, чем аппаратных очередей (кстати, рассмотрите возможность отключения SMT/HyperThreading - во время атаки это будет весьма кстати).
Рисунок 3. Intel 10Gb NIC
Шаги, которые нужно предпринять:
1) Определите производителя и модель сетевой карты (лучше бы это был Intel)
# ethtool -i eth0
2) Установите последние драйверы. Зайдите на сайт производителя чипа для сетевой карты и скачайте последнюю версию драйвера под Linux (чтобы его собрать, понадобятся исходники текущего ядра)
3) Настройте аппаратные очереди. Для этого Вам понадобится воспользоваться документацией от драйвера сетевой карты, которая идет вместе с ним. Для igb (драйвера Intel) c 8 очередями и 4 портами это выглядит примерно так:
# rmmod igb
# modprobe igb QueuePairs=1,1,1,1 RSS=8,8,8,8 IntMode=3,3,3,3 InterruptThrottleRate=3000,3000,3000,3000
Для драйвера igb в RHEL/CentOS Вы можете просто добавить строку параметров драйвера в /etc/modprobe.conf и перезагрузиться:
options igb QueuePairs=1,1,1,1 RSS=8,8,8,8 IntMode=3,3,3,3 InterruptThrottleRate=3000,3000,3000,3000
4) Распределите загрузки прерываний равномерно между ядрами.
Нужно будет определить, какие номера прерываний использует карточка (в нашем случае eth0).
# cat /proc/interrupts | grep eth0
Здесь Вы можете увидеть все номера прерываний, которые использует Ваша NIC, и то, как они по факту сейчас распределяются по ядрам. Запишите эти числа. Теперь нам нужно поменять SMP affinity, чтобы назначить каждому прерыванию свое ядро (interrupt 1 > cpu 1, interrupt 2 > cpu 2 и т.д.). Вот как это делается:
# echo
5) ОПЦИОНАЛЬНО: Включите RPS (это может не понадобиться, см. выше)
# echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus
Выберите соответствующее устройство (если это не eth0) и все очереди приема, которые оно поддерживает (rx-0..n).
Sysctl
Следующая вещь называется sysctl. Это программный интерфейс, позволяющий Вам настраивать множество параметров системы “на лету”. Однако в рамках данной статьи мы воздержимся от обсуждения того, как с их помощью защититься от SYN-атак - об этом в Интернете и так написано слишком много.
В отличие от того, как думает большинство “советчиков”, НЕ СУЩЕСТВУЕТ “универсальных оптимизаций”, которые подошли бы каждому, у кого есть сервер. Каждая так называемая оптимизация влечет за собой последствия, такие как повышенное потребление памяти или уменьшение доступности/функциональности. Безусловно, определенные изменения должны применяться, но эта тема заслуживает отдельной статьи, более обширной, чем эта.
Единственное, что хочется отметить как важное и зачастую неправильно применяемое - так называемые syncookies. Вкратце, это системный механизм борьбы с SYN-атаками путем отправки cookies в ответ на каждый SYN-запрос для подтверждения легитимности соединения. Факт в том, что это может быть действительно полезно, если скорость атаки составляет 40% от эффективной пропускной способности сервера или меньше (под эффективной я имею в виду такую пропускную способность, которую сервер по факту способен обработать). В остальных случаях использование syncookies ведет к повышению нагрузки на сеть, CPU и, таким образом, к отказу в обслуживании.
Лично я в большинстве случаев отключаю syncookies.
Базовые техники защиты с помощью iptables
Не забудьте “укрепить” свой файрвол: блокируйте весь входящий трафик, кроме того, который ДЕЙСТВИТЕЛЬНО нужен на Вашем сервера. Разрешите управление только из доверенных сетей.
Самый простой случай - это атака с 1 IP без подмены адресов (спуфинга). С такими бороться просто:
# iptables -A INPUT -p tcp -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j DROP
# iptables -A INPUT -p tcp -m state --state NEW -m recent --set -j ACCEPT
Эти правила ограничивают количество SYN-пакетов с одного адреса до 20 в минуту. Только не пользуйтесь этим на постоянной основе! Вы можете заблокировать легитимный трафик, идущий из-за NAT.
Многие SYN-атаки можно отфильтровать по “необычным” и повторяющимся параметрам TCP-заголовка, которыми “грешат” атакующие утилиты.
Первый такой параметр - это MSS (Maximum Segment Size) - максимальный размер сегмента, который хочет разрешить хост, инициирующий соединение. Большинство атакующих утилит (включая hping) не задействуют эту опцию по умолчанию. С другой стороны, я еще не видел легитимных клиентов, которые бы ее не ставили. “Нормальные” значения находятся в диапазоне от 536 до 65535, давайте это использовать:
# iptables -t mangle -I PREROUTING -p tcp -m tcp --dport 80 -m state --state NEW -m tcpmss ! --mss 536:65535 -j DROP
Кстати, таблица mangle быстрее, чем filter, потому что обрабатывается раньше, однако через нее проходит ВЕСЬ трафик, и нет возможности разделить INPUT, OUTPUT и FORWARD.
Еще один крайне полезный параметр - это размер окна TCP (window size). Большинство атакующих не генерируют его каждый раз, и он остается одинаковым в течение всей атаки. Чтобы отфильтровать и заблокировать сегменты по window size, понадобится модуль u32 для iptables. После того, как Вы узнаете размер окна, с которым идет атака (например, 512), преобразуйте его в hex (в нашем случае 0x200) и выполните следующую команду:
# iptables -t mangle -I PREROUTING -d xx.xx.xx.xx -p tcp -m u32 --u32 "6&0xFF=0x6 && 32&0xFFFF=0x200" -j DROP
Но будьте осторожны! Не блокируйте well-known размеры окон, используемые популярными операционными системами: 14600, 1892, 65535, 62240, 5840, 32120, 5720, 4128, 8760, 16384, 62920, 64380 и 17820.
Наконец, упомянем параметр TTL (Time To Live). Я хочу, чтобы это был самый последний параметр, на котором основываются Ваши проверки, поскольку диапазон значений невелик и Вы практически наверняка заблокируете не того, кого надо. Но когда вы видите множество пакетов атаки, и совпадает у них только TTL - это может помочь.
# iptables -A FORWARD -p tcp -m ttl --ttl-eq=55 -m state --state NEW -j DROP
Если ничего не помогает
Обратитесь к профессионалам! Я серьезно. То, что описано здесь - это только верхушка айсберга. Помните, есть две стратегии защиты, которые должны использоваться вместе:
1) Наращивание/оптимизация вычислительных/сетевых ресурсов для обработки большего числа запросов;
2) Отделение нежелательного трафика от легального с целью его дальнейшей блокировки.
Таким образом, у Вас есть 3 причины попросить помощи со стороны:
1) У Вас недостаточно полосы пропускания или же вычислительных ресурсов для отделения нежелательного трафика от легального;
2) Атака сложная, и нежелательные пакеты не отличаются или почти не отличаются от легальных. Профессионалы используют более продвинутые методы фильтрации, а иногда дорогостоящее специализированное оборудование и ПО.
И наконец,
Собственно, речь пойдет о защите от SYN flood атак:
Очень популярная DoS атака заключается в посылке большого числа SYN пакетов на ваш сервер. При этом установка TCP связи не доводится до конца. Очередь полуоткрытых запросов соединений быстро заполняется, что мешает установке нормальных соединений. Так как соединение не должно быть обязательно завершено, такая атака не требует больших ресурсов от атакующей машины, поэтому её легко реализовать и контролировать.
Определить SYN атаку просто - команда netstat выдает огромный список полуоткрытых подключений:
Netstat -n --tcp | grep SYN_RECV tcp 0 0 xxx.xxx.xxx.xxx:80 yyy.yyy.yyy.yyy:1084 SYN_RECV tcp 0 0 xxx.xxx.xxx.xxx:80 yyy.yyy.yyy.yyy:1228 SYN_RECV tcp 0 0 xxx.xxx.xxx.xxx:80 yyy.yyy.yyy.yyy:2652 SYN_RECV tcp 0 0 xxx.xxx.xxx.xxx:80 yyy.yyy.yyy.yyy:3446 SYN_RECV
Netstat -n --tcp | grep SYN_RECV | wc -l 238
Для начала - проверяем параметр tcp_syncookies - он должен быть равен 1:
Cat /proc/sys/net/ipv4/tcp_syncookies 1
Так и оставляем. По умолчанию в новых дистрибутивах этот параметр всегда включен.
Если параметр tcp_syncookies установлен (доступен только когда ядро собрано с CONFIG_SYNCOOKIES), тогда ядро обрабатывает SYN пакеты TCP в обычном режиме до тех пор, пока очередь не заполнится. После заполнения очереди включается механизм SYN cookies.
SYN cookies вообще не использует очередь SYN. Вместо этого ядро отвечает на каждый SYN пакет, как обычно SYN|ACK, но туда будет включено специально сгенерированное число на основе IP адресов и портов источника и получателя, а также времени посылки пакета. Атакующий никогда не получит эти пакеты, а поэтому и не ответит на них. При нормальном соединении, будет послан третий пакет, содержащий число, а сервер проверит был ли это ответ на SYN cookie и, если да, то разрешит соединение даже в том случае, если в очереди SYN нет соответствующей записи.
Включение механизма SYN cookies является очень простым способом борьбы против атаки SYN флудом. При этом немного больше загружается процессор из-за необходимости создавать и сверять cookie. Так как альтернативным решением является отклонять все запросы на соединение, SYN cookies являются хорошим выбором.
Также нужно увеличить очередь полуоткрытых соединений - tcp_max_syn_backlog (в Debian Lenny по-умолчанию 1024 соединения):
Cat /proc/sys/net/ipv4/tcp_max_syn_backlog 1024
Увеличиваем:
Echo "20000" > /proc/sys/net/ipv4/tcp_max_syn_backlog
Кроме того, можем уменьшить время ожидания соединения tcp_synack_retries :
cat /proc/sys/net/ipv4/tcp_synack_retries 5Целочисленное значение (1 байт) tcp_synack_retries определяет число попыток повтора передачи пакетов SYNACK для пассивных соединений TCP. Число попыток не должно превышать 255. Используемое по умолчанию значение 5 соответствует приблизительно 180 секундам на выполнение попыток организации соединения.
Уменьшаем до 1 (это примерно 9 секунд):
Echo "1" > /proc/sys/net/ipv4/tcp_synack_retries
tcp_fin_timeout
cat /proc/sys/net/ipv4/tcp_fin_timeout 60Целое число в файле tcp_fin_timeout определяет время сохранения сокета в состоянии FIN-WAIT-2 после его закрытия локальной стороной. Партнер может не закрыть это соединение никогда, поэтому следует закрыть его по своей инициативе по истечении тайм-аута. По умолчанию тайм-аут составляет 60 секунд. В ядрах серии 2.2 обычно использовалось значение 180 секунд и вы можете сохранить это значение, но не следует забывать, что на загруженных WEB-серверах вы рискуете израсходовать много памяти на сохранение полуразорванных мертвых соединений. Сокеты в состоянии FIN-WAIT-2 менее опасны, нежели FIN-WAIT-1, поскольку поглощают не более 1,5 Кбайт памяти, но они могут существовать дольше.
Меняем на 30:
Echo "30" > /proc/sys/net/ipv4/tcp_fin_timeout
tcp_keepalive_probes
cat /proc/sys/net/ipv4/tcp_keepalive_probes 9Целочисленная переменная tcp_keepalive_probes задает число передач проб keepalive, после которого соединение считается разорванным. По умолчанию передается 9 проб.
Echo "5" > /proc/sys/net/ipv4/tcp_keepalive_probes
tcp_keepalive_intvl
cat /proc/sys/net/ipv4/tcp_keepalive_intvl 75Целочисленная переменная tcp_keepalive_intvl определяет интервал передачи проб. Произведение tcp_keepalive_probes * tcp_keepalive_intvl определяет время, по истечении которого соединение будет разорвано при отсутствии откликов. По умолчанию установлен интервал 75 секунд, т.е., время разрыва соединения при отсутствии откликов составит приблизительно 11 минут.
Ставим 15:
Echo "15" > /proc/sys/net/ipv4/tcp_keepalive_intvl
netdev_max_backlog
Здесь указывается максимальное количество пакетов в очередь на обработку если интерфейс получает пакеты быстрее, чем ядро может их обработать.
Cat /proc/sys/net/core/netdev_max_backlog 1000
Увеличиваем:
Echo "20000" > /proc/sys/net/core/netdev_max_backlog
somaxconn
Максимальное число открытых сокетов, ждущих соединения.
Cat 1024
Увеличиваем:
Echo "20000" > /proc/sys/net/core/somaxconn
Так как подобные изменения параметров ядра не сохранятся после перезагрузки - добавляем в /etc/rc.local :
Echo "20000" > /proc/sys/net/ipv4/tcp_max_syn_backlog echo "1" > /proc/sys/net/ipv4/tcp_synack_retries echo "30" > /proc/sys/net/ipv4/tcp_fin_timeout echo "5" > /proc/sys/net/ipv4/tcp_keepalive_probes echo "15" > /proc/sys/net/ipv4/tcp_keepalive_intvl echo "20000" > /proc/sys/net/core/netdev_max_backlog echo "20000" > /proc/sys/net/core/somaxconn
Кроме того, можно добавить ограничение числа SYN пакетов в единицу времени в iptables:
Iptables -N syn_flood iptables -A INPUT -p tcp --syn -j syn_flood iptables -A syn_flood -m limit --limit 500/s --limit-burst 1500 -j RETURN iptables -A syn_flood -j DROP
Число новых SYN пакетов - максимум 500 в секунду, при превышении порога в 1500 - новые пакеты блокируются:
Более наглядно этот критерий можно представить себе как некоторую емкость с выпускным отверстием, через которое проходит определенное число пакетов за единицу времени (т.е. скорость «вытекания»). Скорость «вытекания» как раз и определяет величина --limit. Величина --limit-burst задает общий «объем емкости». А теперь представим себе правило --limit 3/minute --limit-burst 5, тогда после поступления 5 пакетов (за очень короткий промежуток времени), емкость «наполнится» и каждый последующий пакет будет вызывать «переполнение» емкости, т.е. «срабатывание» критерия. Через 20 секунд «уровень» в емкости будет понижен (в соответствии с величиной --limit), таким образом она готова будет принять еще один пакет, не вызывая «переполнения» емкости, т.е. срабатывания критерия.
Неужели ты думаешь, что знаешь все о DoS? Тогда читай!
Denial-of-service (DoS), атаки отказа от обслуживания, стали опаснее и легче. DoS это разновидность
сетевых атак (от червей до SYN flooding), цель которых сделать сервер недоступным для пользователей. ‘Distributed Reflection’ это новый вид DoS атак с использованием SYN flood"а. Его особенность в том, что на атакуемый сервер не посылаются миллионы SYN пакетов, они посылаются на router"ы или сервера и ответ приходит целевому серверу. А
роутеров существует миллионы!
Чтобы понять как все это работает и почему это так важно
давайте кое-что вспомним... Подтверждение TCP соединения происходит посредствам обмена тремя пакетами между двумя
компьютерами, так называемое рукопожатие. Вот примерная схема:
- SYN клиент (web браузер, ftp клиент, etc.) входит в связь с сервером, посылая ему SYN пакет.
- SYN/ACK: Когда запрос о соединении(SYN пакет) получен на открытом порту сервера, тот подтверждает соединение посылая клиенту SYN/ACK пакет.
- ACK: Когда клиент получает подтверждение сервера SYN/ACK пакет для ожидаемой связи, то отвечает ACK пакетом.
Что происходит?
Традиционные "SYN flooding DoS" атаки работают по двум принципам:
- "one-on-one" одна машина отсылает достаточное количество SYN пакетов чтобы заблокировать доступ к серверу.
- "many-on-one" множество программ зомби,
установленых на разных серверах, атакуют целевую машину SYN пакетами.
С использованием "reflection SYN flooding" посылаются пакеты,
но с исходным IP адресом, указывающим на целевую машину. TCP соединение с использованием этих трех пакетов требует, чтобы любая TCP служба, которая получает SYN пакет, ответила SYN/ACK пакетом. Сервер или router, которые получают эти поддельные SYN пакеты, посылают SYN/ACK ответы на машину, указанную SYN пакетами с исходным адресом
IP. Основной протокол Интернета и инфраструктура
сети используются сами против себя!
В деталях
Любая TCP связь с сервером общего назначения может использоваться, чтобы "отразить" SYN пакеты. Вот
короткий список наиболее популярных TCP портов:
22 (Secure Shell), 23 (Telnet), 53 (DNS) и 80 (HTTP/web). И фактически router"ы всего Интернета подтвердят TCP связь на
179 порту. Давайте оценим потенциал этой атаки:
- Она использует фундаментальный Интернет протокол коммуникаций;
- Машин, которые используют этот протокол, существует миллионы;
- чрезвычайно просто организовать атаку ‘SYN packet
reflectors’.
Довольно легко может быть построен список,
в котором будут перечислены router’ы и
сервера, отвечающие на SYN пакеты. Имея
большой список SYN "отражателей", каждый
хакер может распределить поддельные SYN
пакеты равномерно через весь набор
роутеров/серверов в списке. Ни один из невинных "отражателей" не испытает
существенной сетевой нагрузки. Роутеры вообще не сохраняют отчеты про пакеты с запросами на
предварительное соединение, это делает
отслеживание нападения чрезвычайно трудным.
"Отражатели"(роутеры и сервера) отправят в три или четыре раза большее количество SYN/ACK пакетов, чем число SYN пакетов которые они
получат. TCP соединение, которое получает команду
SYN, ожидает ACK ответ от машины на которую послало
SYN/ACK пакет, поэтому компьютер посылается еще несколько SYN/ACK ответов через несколько минут. Эта особенность TCP протокола по существу умножает число злонамеренных SYN/ACK пакетов, посылаемых целевой машине на три или четыре. Это также означает, что flood SYN/ACK
пакеты продолжат атаковать целевой сервер в течение минуты или
двух даже после того, как нападавший отозвал нападение.
