Защита от SYN flood атак. Разбор атак на части: SYN-flood
Некоторые провайдеры (и чем дальше, тем больше таких появляется) фильтруют трафик своих клиентов на предмет подделки адреса отправителя. Есть большая вероятность, что возможнось спуфинга ограничивается подсетью класса C. Кроме того, хост, адрес которого указывается в запросе на подключение, не должен реагировать на ответы сервера - проще всего выбрать адрес, на котором нет машины. При практической реализации, особенно создавая универсальный инструмент для координированной атаки, нужно учитывать эти две особенности, и проводить атаку только со своей подсети и с тех адресов, которые не отвечают. Еще одна проблема - для проведения атаки необходимо иметь администраторские привелегии.
Проблемы, не зависящие от атакующего.
Некоторые провайдеры (и чем дальше, тем больше таких появляется) фильтруют трафик своих клиентов на предмет подделки адреса отправителя. Есть большая вероятность, что возможнось спуфинга ограничивается подсетью класса C. Кроме того, хост, адрес которого указывается в запросе на подключение, не должен реагировать на ответы сервера - проще всего выбрать адрес, на котором нет машины. При практической реализации, особенно создавая универсальный инструмент для координированной атаки, нужно учитывать эти две особенности, и проводить атаку только со своей подсети и с тех адресов, которые не отвечают. Еще одна проблема - для проведения атаки необходимо иметь администраторские привелегии.Программная реализация.
Для реализации подходит как unix, так и windows-платформы. Программа должна запускаться с правами root и администратора соответственно. Под unix много готовых реализаций, например, synk4.c (искать поисковиками). Специализированные для координированых DDoS-атак реализации найти сложнее, но при минимальных навыках программирования можно доработать существующие или создать свои.Кроме стандартных сырых сокетов, D0minat0r из Nerf нашел очень красивый способ реализации SYN flood под linux, на других юниксоподобных не тестировалось, на win не работает. Linux позволяет root"у биндить сокет к любому адресу, в т.ч. не принадлежащему локальному хосту. После этого можно вызывать connect() для этого сокета, и локальный хост пошлет SYN-пакет от адреса, к которому прибинжен сокет. Если сокет был в неблокирующем режиме, то сразу после connect() можно вызывать close(), и повторять операцию.
Реализации под windows встречаются реже, из-за расхожего мифа о невозможности генерации сырых пакетов в этой OS. На самом деле, win98 поддерживает сырые сокеты уровня до заголовка IP, а win2k и XP - и заголовок тоже (опция IP_HDRINCL), т.е. реализация атаки под win2k и XP отличается от юниксовской лишь несколькими строчками. Готовая реализация от меня, проверенная на win2k, лежала одно время на www.nerf.ru, но после смены хостинга, моего ухода из этой группы и форматцевта потерялась. Если у кого-то сохранилась - свяжитесь, плиз, выложу.
Механизмы защиты OS от SYN-flood.
a) Стандартный таумаут. Полуоткрытые соединения по прошествии некоторого времени выбрасываются из буфера. При истощении буфера запросы клиентов на подключение будут проходить с вероятностью C1/C2, где C1 - количество SYN-пакетов от клиента, C2 - количество SYN-пакетов от всех остальных (включая атакующего). Даже при нагрузке на канал атакующего в 6 пакетов в секунду C1/C2 - примерно 1/100, т.е. служба выведена из строя на 99%.
б) Безлимитный буфер полуоткрытых соединений. При нагрузке на канал атакующего 100 Mb/сек и таймауту около минуты очередь полуоткрытых соединений будет занимать примерно 1 Gb памяти, что для крупных серверов не смертельно. Побочный эффект: атакуемый сервер отвечает трафиком, в 3 раза большим, чем трафик атакующего (говорят, что происходит DDoS с умножением в 4 раза), что может привести к истощению пропускной способности канала. Однако, при невозможности истощить ширину канала, защита от атаки будет абсолютной, ни одно клиентское соединение не будет отвергнуто.
в) Очистка наиболее старых полуоткрытых соединений. При переполнении буфера из него удаляется самое старое полуоткрытое соединение. Побочный эффект: если при атаке буфер заполняется за время t, то клиент не сможет подключиться во время атаки, если время подтверждения соединения больше t - его запрос тоже будет выброшен. Например, для нагрузки канала атакующего 4 Мбит/сек и длины буфера 512 (рекомендуемое значение для Win2K) время t - около 50 msec, что гарантированно отбросит все попытки подключения к серверу с диалапа и многие - с выделенных линий. Увеличивая размер буфера, защиту можно свести к предыдущему варианту.
г) SYN COOKIE. После истощения буфера информация, которая не помещается в буфер, отсылается клиенту, который якобы запросил ее. Если клиент - настоящий, то он возвращает информацию обратно, если поддельный - она теряется, причем механизм реализован в рамках RFC по TCP, т.е. его поддерживают и клиенты, не знакомые с этой технологией. Операционная система c SYN COOKIE, независимо от размера буфера полуоткрытых соединений, совершенно неуязвима для SYN-flood атак. Побочный эффект: запрет "больших окон".
Резюме: SYN-flood атака морально устарела, и сегодня может использоваться в лучшем случае в качестве обычной flood-атаки на превышение пропускной способности канала.
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.
DoS (аббр. Denial of Service «отказ в обслуживании») - хакерская атака на вычислительную систему с целью довести её до отказа, то есть создание таких условий, при которых добросовестные пользователи системы не могут получить доступ к предоставляемым системным ресурсам (серверам), либо этот доступ затруднён.
Существует два типа DoS-атака /DDoS-атак, и наиболее распространенная из них основана на идее флуда, то есть заваливания жертвы огромным количеством пакетов. Флуд бывает разным: ICMP-флуд, SYN-флуд, UDP-флуд и HTTP-флуд. Современные DoS-боты могут использовать все эти виды атак одновременно, поэтому следует заранее позаботиться об адекватной защите от каждой из них.
Обнаружение DoS-атак
SYN-флуд
Наличие SYN- флуда устанавливается легко - через подсчет числа «полуоткрытых» TCP- соединений. В обычной ситуации их не должно быть совсем (или очень небольшое количество: максимум 1-3).
Защита от DoS-атак
Блокирует фрагменты - пакетов. Так как, в силу функционального назначения протокола, ICMP-пакеты должны быть очень небольшими и нормально укладываться в MTU , наличие их фрагментов обычно свидетельствует об ошибке или попытке атаки. iptables -A INPUT -p icmp -f -j DROP
Запретить Спуфинг от вашего имени. iptables -A INPUT -m conntrack --ctstate NEW,INVALID -p tcp --tcp-flags SYN,ACK SYN,ACK -j LOG --log-level info --log-prefix "DROP SYN,ACK: " iptables -A INPUT -m conntrack --ctstate NEW,INVALID -p tcp --tcp-flags SYN,ACK SYN,ACK -j REJECT --reject-with tcp-reset
Ведь если мы получаем пакет с установленными флагами SYN и ACK (такой комбинацией флагов обладает только ответ на SYN-пакет) по еще не открытому соединению, это означает, что кто-то послал другому хосту SYN-пакет от нашего имени, и ответ пришел к нам. Конечно, злоумышленнику предстоит еще угадать номер последовательности, но лучше не предоставлять ему такого шанса. Согласно приведенному правилу, наш хост ответит RST- пакетом, после получения которого атакуемый хост закроет соединение. Добавление такого правила в конфигурацию фаервола настоятельно рекомендуется, потому что если злоумышленнику удастся осуществить спуфинг-атаку от вашего имени, при расследовании этого эпизода следы приведут к вам.
SYN-флуд
Один из распространенных способов не только забить канал связи, но и ввести сетевой стек операционной системы в такое состояние, когда он уже не сможет принимать новые запросы на подключение. Основан на попытке инициализации большого числа одновременных TCP-соединений через посылку SYN-пакета с несуществующим обратным адресом. После нескольких попыток отослать ответный ACK-пакет на недоступный адрес большинство операционок ставят неустановленное соединение в очередь. И только после n-ой попытки закрывают соединение. Так как поток ACK-пакетов очень велик, вскоре очередь оказывается заполненной, и ядро дает отказ на попытки открыть новое соединение. Наиболее умные DoS-боты еще и анализируют систему перед началом атаки, чтобы слать запросы только на открытые жизненно важные порты. Идентифицировать такую атаку просто: достаточно попробовать подключиться к одному из сервисов. Оборонительные мероприятия обычно включают в себя:
Увеличение очереди «полуоткрытых» TCP-соединений:
# sysctl -w net.ipv4.tcp_max_syn_backlog=1024Уменьшение времени удержания «полуоткрытых» соединений:
# sysctl -w net.ipv4.tcp_synack_retries=1Включение механизма TCP syncookies:
# sysctl -w net.ipv4.tcp_syncookies=1UDP-флуд
Метод захламления полосы пропускания. Основан на бесконечной посылке 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
ICMP- флуд
Очень примитивный метод забивания полосы пропускания и создания нагрузок на сетевой стек через монотонную посылку запросов ICMP протокол диагностики перегрузки сети ECHO (пинг). Легко обнаруживается с помощью анализа потоков трафика в обе стороны: во время атаки типа ICMP-флуд они практически идентичны. Почти безболезненный способ абсолютной защиты основан на отключении ответов на запросы ICMP ECHO:
Sysctl net.ipv4.icmp_echo_ignore_all=1
Или с помощью брандмауэра:
Iptables -A INPUT -p icmp -j DROP --icmp-type 8
HTTP-флуд
Количество процессов ps aux | grep apache | wc -l
Количество конектов на 80 порту netstat -na | grep ":80\ " | wc -l
Просмотреть список IP- адресов, с которых идут запросы на подключение: netstat -na | grep ":80\ " | sort | uniq -c | sort -nr
sysctl
Защита от спуфинга net.ipv4.conf.default.rp_filter = 1
Проверять TCP-соединение каждую минуту. Если на другой стороне - легальная машина, она сразу ответит. Дефолтовое значение - 2 часа. net.ipv4.tcp_keepalive_time = 60
Повторить пробу через десять секунд net.ipv4.tcp_keepalive_intvl = 10
Количество проверок перед закрытием соединения net.ipv4.tcp_keepalive_probes = 5
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.
Чтобы не попасть в безвыходное положение во время обрушения DDoS-шторма на системы, необходимо тщательным образом подготовить их к такой ситуации:
Все сервера, имеющие прямой доступ во внешнюю сеть, должны быть подготовлены к простому и быстрому удаленному ребуту (sshd спасет отца русской демократии). Большим плюсом будет наличие второго, административного, сетевого интерфейса, через который можно получить доступ к серверу в случае забитости основного канала.
ПО, используемое на сервере, всегда должно находиться в актуальном состоянии. Все дырки - пропатчены, обновления установлены (простой, как сапог, совет, которому многие не следуют). Это оградит тебя от DoS-атак, эксплуатирующих баги в сервисах.
Все слушающие сетевые сервисы, предназначенные для административного использования, должны быть спрятаны брандмауэром ото всех, кто не должен иметь к ним доступ. Тогда атакующий не сможет использовать их для проведения DoS-атаки или брутфорса.
На подходах к серверу (ближайшем маршрутизаторе) должна быть установлена система анализа трафика (NetFlow в помощь), которая позволит своевременно узнать о начинающейся атаке и вовремя принять меры по ее предотвращению.
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) Атака сложная, и нежелательные пакеты не отличаются или почти не отличаются от легальных. Профессионалы используют более продвинутые методы фильтрации, а иногда дорогостоящее специализированное оборудование и ПО.
И наконец,
A SYN flood attack is a form of denial-of-service attack in which an attacker sends a large number of SYN requests to a target system’s services that use TCP protocol. This consumes the server resources to make the system unresponsive to even legitimate traffic. This attack can occur on any services that use TCP protocol but mainly on web service. In this article, we will go through the basics of SYN flood attacks and the mitigation steps in detail.
The SYN Flood attack exploits an implementation characteristic of the Transmission Control Protocol (TCP), which is called 3-way handshake. Following are the steps that occur in a normal 3-way handshake:
1. The client requests a connection by sending a SYN (synchronize) message to the server.
2. The server acknowledges this request by sending SYN-ACK back to the client.
3. The client responds with an ACK, and the connection is established.
A SYN flood attack works by not responding to the server with the expected ACK code. By these half-open connections, the target machines TCP backlog will get filled up and hence all new connections may get ignored. This will cause the legitimate users to also get ignored.
This attack can take place in two ways:
1. Direct Attack
In this kind of attack, attackers rapidly send SYN segments without spoofing their IP source address. When detected, this type of attack is very easy to defend, because we can add a simple firewall rule to block packets with the attacker"s source IP address which will shutdown the attack.
2. Using Ip address Spoofing
This is a more complex form of attack than the direct attack. In this method, the malicious machine will send SYN request floods to the target machine from spoofed IP addresses, causing the server to send the SYN-ACK to a falsified IP address - which will not send an ACK because it "knows" that it never sent a SYN.
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
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
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.
Bobbin Zachariah 8:24 am
About Bobbin Zachariah
Founder of LinOxide, passionate lover of Linux and technology writer. Started his career in Linux / Opensource from 2000. Love traveling, blogging and listening music. Reach Bobbin Zachariah
Загрузка...
