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. Продолжение находится в стадии написания, и скоро будет выложено тут. Оставайтесь с нами!
