11.11.2012
під флудоммається на увазі величезний потік даних у вигляді повідомлень, який направляється для розміщення на всіляких форумах і чатах. Якщо дивитися з технічної ж точки зору, flood - це один з найбільш поширених видів комп'ютерної атаки, І метою його є відправка такого числа запитів, що обладнання сервера буде змушене виконати відмова в обслуговуванні сервісів користувачів. якщо напад на обчислювальну техніку здійснюється з великого числа комп'ютерів, то Ви маєте справу з.
Існує кілька типів DDoS-атак із застосуванням флуду, основні з них перераховані нижче:
- SYN-ACK-флуд
- HTTP-флуд
- ICMP-флуд
- UDP-флуд
SYN-ACK-флуд
SYN-ACK-флуд - один з типів мережевих атак, Який заснований на відправку величезної кількості SYN-запитів в одиницю часу. Результатом стане виведення з ладу сервісу, робота якого була заснована на TCP протоколі. Спочатку клієнт відправляє на сервер пакет, що містить SYN-прапор, наявність якого говорить про бажання клієнт встановити з'єднання. Сервер, в свою чергу, посилає пакет-відповідь. У ньому крім SYN-прапора є і ACK-прапор, який звертає увагу клієнта на те, що запит прийнятий і очікується підтвердження встановлення з'єднання з боку клієнта. Той відповідає пакетом з ACK-прапором про успішне з'єднання. Всі запити на «коннект» від клієнтів сервер зберігає в черзі певного розміру. Запити зберігаються в черзі до повернення від клієнта ACK-прапора. SYN-атака заснована на відправку сервера пакетів з неіснуючого джерела, кількістю перевищує розмір черги. Сервер, просто не зможе відповісти на пакет з вигаданого адресою. Черга не зменшуватиметься і сервіс перестане функціонувати.
HTTP-flood
HTTP-flood - застосовується у разі роботи сервісу з базою даних. Атака націлена або на web-сервер, Або на скрипт працює з базою. Відправляється величезна кількість запитів GET на 80 порт, щоб web-сервер не зміг приділяти належну увагу запитам іншого типу. Log-файли збільшуються, а робота з базою даних ставати неможливою.
ICMP-флуд
ICMP-флуд - простий спосіб зменшення пропускної здатності і збільшення навантажень на стек за коштами відправки однотипних запитів ICMP PING. Небезпечний у разі малого приділення уваги мережевим екранам, так як сервер, який відповідає на нескінченні запити ECHO, приречений. Так що в разі однакової кількості вхідного і вихідного трафіку просто пропишіть правила в iptables.
UDP-флуд
UDP-флуд - черговий спосіб захаращення пропускної смуги, Заснований на роботі з протоколом, який не вимагає синхронізації перед відправкою даних. Атака зводиться до звичайної посилці пакету на UDP порт сервера. Після отримання пакета, сервер починає його посилено обробляти. Потім клієнт відправляє Udp-пакети некоректного змісту один за одним. В результаті порти перестануть функціонувати і система дасть збій.
В принципі, на визначення типу DDoS-атаки часто не обов'язково витрачати багато часу. Досить знати кілька ознак. якщо значно збільшився розмір logфайлов - Ви маєте справу з HTTP-флудом. якщо обмежений доступ до сервісу в результаті перевищення кількості допустимих з'єднань - це SYN-ACK-флуд. У разі якщо вихідний і вхідний трафік приблизно рівні - Ви маєте справу з ICMP-флуд. Головне, не забувати про підтримку безпеки свого сервера від ДДоС і приділяти їй належну увагу. Найкраще - подбати про
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 \u003d 1 kern.ipc.nmbclusters \u003d 400000 net.inet.tcp.nolocaltimewait \u003d 1 net.inet.tcp.recvspace \u003d 16384 net.inet.tcp.sendspace \u003d 32768 net.inet.tcp.msl \u003d 5000 net.inet.tcp.blackhole \u003d 1 net.inet.ip.intr_queue_maxlen \u003d 3000 net.inet.tcp.blackhole \u003d 2 net.inet.udp.blackhole \u003d 1 net.inet.icmp.log_redirect \u003d 1 net.inet.ip .redirect \u003d 0 net.inet.icmp.maskrepl \u003d 1 net.inet.tcp.syncookies_only \u003d 1 net.route.netisr_maxqlen \u003d 4096 kern.ipc.maxsockbuf \u003d 83886080 net.inet.ip.intr_queue_maxlen \u003d 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
Якщо це число\u003e 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 \u003d\u003d 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 \u003d 1,1,1,1 RSS \u003d 8,8,8,8 IntMode \u003d 3,3,3,3 InterruptThrottleRate \u003d 3000,3000,3000,3000
Для драйвера igb в RHEL / CentOS Ви можете просто додати рядок параметрів драйвера в /etc/modprobe.conf і перезавантажитися:
options igb QueuePairs \u003d 1,1,1,1 RSS \u003d 8,8,8,8 IntMode \u003d 3,3,3,3 InterruptThrottleRate \u003d 3000,3000,3000,3000
4) Розподіліть завантаження переривань рівномірно між ядрами.
Потрібно буде визначити, які номери переривань використовує картка (в нашому випадку eth0).
# Cat / proc / interrupts | grep eth0
Тут Ви можете побачити всі номери переривань, які використовує Ваша NIC, і то, як вони по факту зараз розподіляються по ядрах. Запишіть ці числа. Тепер нам потрібно поміняти SMP affinity, щоб призначити кожному переривання своє ядро \u200b\u200b(interrupt 1\u003e cpu 1, interrupt 2\u003e cpu 2 і т.д.). Ось як це робиться:
# echo
5) опціонально: Увімкніть RPS (це може не знадобитися, див. Вище)
# Echo f\u003e / 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 \u003d 0x6 && 32 & 0xFFFF \u003d 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 \u003d 55 -m state --state NEW -j DROP
Якщо нічого не допомагає
Зверніться до професіоналів! Я серйозно. Те, що описано тут - це тільки верхівка айсберга. Пам'ятайте, є дві стратегії захисту, які повинні використовуватися разом:
1) Нарощування / оптимізація обчислювальних / мережевих ресурсів для обробки більшого числа запитів;
2) Відділення небажаного трафіку від легального з метою його подальшого блокування.
Таким чином, у Вас є 3 причини попросити допомоги з боку:
1) У Вас недостатньо смуги пропускання або ж обчислювальних ресурсів для відділення небажаного трафіку від легального;
2) Атака складна, і небажані пакети не відрізняються або майже не відрізняються від легальних. Професіонали використовують більш просунуті методи фільтрації, а іноді дороге спеціалізоване обладнання та програмного забезпечення.
І наостанок,
syn-flood атака - практика
Alexander Antipov
Деякі провайдери (і чим далі, тим більше таких з'являється) фільтрують трафік своїх клієнтів на предмет підробки адреси відправника. Є велика ймовірність, що возможнось спуфинга обмежується підмережею класу 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-атаки на перевищення пропускної здатності каналу.
Власне, мова піде про захист від 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: тисяча вісімдесят чотири 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 встановлений (доступний тільки коли ядро \u200b\u200bзібрано з CONFIG_SYNCOOKIES), тоді ядро \u200b\u200bобробляє SYN пакети TCP в звичайному режимі до тих пір, поки черга не заповниться. Після заповнення черги включається механізм SYN cookies.
SYN cookies взагалі не використовує чергу SYN. Замість цього ядро \u200b\u200bвідповідає на кожен 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 1 024
збільшуємо:
Echo "20000"\u003e / 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"\u003e / 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"\u003e / 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"\u003e / 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"\u003e / proc / sys / net / ipv4 / tcp_keepalive_intvl
netdev_max_backlog
Тут вказується максимальна кількість пакетів в чергу на обробку якщо інтерфейс отримує пакети швидше, ніж ядро \u200b\u200bможе їх обробити.
Cat / proc / sys / net / core / netdev_max_backlog 1000
збільшуємо:
Echo "20000"\u003e / proc / sys / net / core / netdev_max_backlog
somaxconn
Максимальне число відкритих сокетів, що чекають з'єднання.
Cat 1 024
збільшуємо:
Echo "20000"\u003e / proc / sys / net / core / somaxconn
Так як подібні зміни параметрів ядра не будуть збережені після перезавантаження - додаємо в /etc/rc.local:
Echo "20000"\u003e / proc / sys / net / ipv4 / tcp_max_syn_backlog echo "1"\u003e / proc / sys / net / ipv4 / tcp_synack_retries echo "30"\u003e / proc / sys / net / ipv4 / tcp_fin_timeout echo "5"\u003e / proc / sys / net / ipv4 / tcp_keepalive_probes echo "15"\u003e / proc / sys / net / ipv4 / tcp_keepalive_intvl echo "20000"\u003e / proc / sys / net / core / netdev_max_backlog echo "20000"\u003e / 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), таким чином вона готова буде прийняти ще один пакет, не викликаючи «переповнення» ємності, тобто спрацьовування критерію.
