КСЗІ2010:Виступ на семінарі:Симчак Володимир:Захист інформації - Історія редагувань

WikiSysop: перейменував «КСЗІ2010:» на «КСЗІ2010:Виступ на семінарі:Симчак Володимир:Захист інформації» поверх перенаправлення: відкинути

2010-04-05T15:02:16Z

перейменував «КСЗІ2010:» на «КСЗІ2010:Виступ на семінарі:Симчак Володимир:Захист інформації» поверх перенаправлення: відкинути

Symchak: перейменував «КСЗІ2010:Виступ на семінарі:Симчак Володимир:Захист інформації» на «КСЗІ2010:»

2010-03-29T17:59:00Z

перейменував «КСЗІ2010:Виступ на семінарі:Симчак Володимир:Захист інформації» на «КСЗІ2010:»

Symchak: Сторінка очищена

2010-03-29T16:53:08Z

Сторінка очищена

Показати зміни

Symchak в 16:47, 29 березня 2010

2010-03-29T16:47:18Z

Symchak в 16:46, 29 березня 2010

2010-03-29T16:46:54Z

Symchak в 16:41, 29 березня 2010

2010-03-29T16:41:23Z

Symchak в 16:32, 29 березня 2010

2010-03-29T16:32:19Z

Symchak в 16:21, 29 березня 2010

2010-03-29T16:21:34Z

Symchak в 16:11, 29 березня 2010

2010-03-29T16:11:02Z

Symchak в 16:06, 29 березня 2010

2010-03-29T16:06:07Z

@@ Рядок 1: / Рядок 1: @@
-[http://elartu.tstu.edu.ua/handle/123456789/427 Презентація доповіді (університетський репозиторій)]
+  [http://elartu.tstu.edu.ua/handle/123456789/427 Презентація доповіді (університетський репозиторій)]
 == Анатомія DoS-атак ==
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;DoS-атаки поділяються на локальні і віддаленні. До локальних відносяться різні експлойти, форк-бомби і програми, що відкривають по мільйону файлів або запускають якийсь циклічний алгоритм, який зжирає пам'ять і процесорні ресурси. На всьому цьому ми зупинятися не будемо. А ось віддалені DoS-атаки розглянемо детальніше. Вони діляться на два види:

← Попередня версія		Версія за 16:46, 29 березня 2010
Рядок 1:		Рядок 1:
		+	[http://elartu.tstu.edu.ua/handle/123456789/427 Презентація доповіді (університетський репозиторій)]
	== Анатомія DoS-атак ==		== Анатомія DoS-атак ==
	DoS-атаки поділяються на локальні і віддаленні. До локальних відносяться різні експлойти, форк-бомби і програми, що відкривають по мільйону файлів або запускають якийсь циклічний алгоритм, який зжирає пам'ять і процесорні ресурси. На всьому цьому ми зупинятися не будемо. А ось віддалені DoS-атаки розглянемо детальніше. Вони діляться на два види:		DoS-атаки поділяються на локальні і віддаленні. До локальних відносяться різні експлойти, форк-бомби і програми, що відкривають по мільйону файлів або запускають якийсь циклічний алгоритм, який зжирає пам'ять і процесорні ресурси. На всьому цьому ми зупинятися не будемо. А ось віддалені DoS-атаки розглянемо детальніше. Вони діляться на два види:

@@ Рядок 99: / Рядок 99: @@
 <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.	На підходах до сервера (найближчому маршрутизаторі) має бути встановлена система аналізу трафіку (Netflow в допомогу), яка дозволить своєчасно дізнатися про атаку, що починається, і вчасно прийняти заходи по її запобіганню.
 <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Додай в /etc/sysctl.conf наступні рядки:
-<br>&#035; vi /etc/sysctl.conf
+<br>''&#035; vi /etc/sysctl.conf''
-<br>&#035; Захист від спуфінга
+<br>''&#035; Захист від спуфінга''
-<br>net.ipv4.conf.default.rp_filter = 1
+<br>''net.ipv4.conf.default.rp_filter = 1''
-<br>&#035; Перевіряти TCP-з’єднання кожну хвилину. Якщо на іншій стороні - легальна машина, вона зразу відповість. Значення по замовчуванні - 2 години.
+<br>''&#035; Перевіряти TCP-з’єднання кожну хвилину. Якщо на іншій стороні - легальна машина, вона зразу відповість. Значення по замовчуванні - 2 години.
 <br>net.ipv4.tcp_keepalive_time = 60
 <br>&#035; Повторити попитку через десять секунд
 net.ipv4.tcp_keepalive_intvl = 10
 <br>&#035; Кількість повірок перед закриттям з’єднання
-<br>net.ipv4.tcp_keepalive_probes = 5
+<br>net.ipv4.tcp_keepalive_probes = 5''
 <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Слід зазначити, що всі прийоми, приведені у минулому і цьому розділах, направлені на зниження ефективності DDoS-атак, що ставлять своєю метою витратити ресурси машини. Від флуда, що забиває канал сміттям, захиститися практично неможливо, і єдино правильний, але не завжди здійсненний спосіб боротьби полягає в тому, щоб "позбавити атаку сенсу". Якщо ти отримаєш в своє розпорядження дійсно широкий канал, який легко пропустить трафік невеликого ботнета, вважай, що від 90% атак твій сервер захищений. Є витонченіший спосіб захисту. Він заснований на організації розподіленої обчислювальної мережі, що включає безліч дублюючих серверів, які підключені до різних магістральних каналів. Коли обчислювальні потужності або пропускна спроможність каналу закінчуються, все нові клієнти перенаправляються на інший сервер (або ж поступово "розмазуються" по серверах за принципом round-robin). Це неймовірно дорога, але дуже стійка структура, завалити яку практично нереально.
 <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Інше більш-менш ефективне рішення полягає в покупці дорогих хардварних систем Cisco Traffic Anomaly Detector і Cisco Guard. Працюючи у в'язці, вони можуть подавити атаку, що починається, але, як і більшість інших рішень, заснованих на вченні і аналізі станів, дають збої. Тому слід гарненько подумати перед тим, як вибивати з начальства десятки тисячі доларів на такий захист.
@@ Рядок 114: / Рядок 114: @@
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Перед безпосереднім початком атаки боти "розігріваються", поступово нарощуючи потік пакетів на машину, що атакується. Важливо зловити момент і почати активні дії. Допоможе в цьому постійне спостереження за маршрутизатором, підключеним до зовнішньої мережі (аналіз графіків Netflow). На сервері-жертві визначити початок атаки можна підручними засобами.
 <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Наявність Syn-флуда встановлюється легко - через підрахунок числа "напіввідкритих" tcp-з'єднань:
-<br>&#035; netstat -na | grep ":80\ " | grep Syn_rcvd
+<br>''&#035; netstat -na | grep ":80\ " | grep Syn_rcvd''
 <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;У звичайній ситуації їх не повинно бути зовсім (або дуже невелика кількість: максимум 1-3). Якщо це не так - ти атакований, терміново переходь.
 <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; З Http-флудом дещо складніше. Спершу потрібний підрахувати кількість процесів Apache і кількість з’єднань на 80-й порт (Http-флуд):
-<br>&#035; ps aux | grep httpd | wc -l
+<br>''&#035; ps aux | grep httpd | wc -l
-<br>&#035; netstat -na | grep ":80\ " | wc –l
+<br>&#035; netstat -na | grep ":80\ " | wc –l''
 <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Значення, у декілька разів вищі за середньостатистичні, дають підстави задуматися. Далі слід проглянути список ip-адрес, з яких йдуть запити на підключення:
-<br>&#035; netstat -na | grep ":80\ " | sort | uniq -c | sort -nr | less
+<br>''&#035; netstat -na | grep ":80\ " | sort | uniq -c | sort -nr | less''
 <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Однозначно ідентифікувати DoS-атаку не можна, можна лише підтвердити свої припущення про наявність такої, якщо одна адреса повторюється в списку надто багато разів. Додатковим підтвердженням буде аналіз пакетів за допомогою tcpdump:
-<br>&#035; tcpdump -n -i eth0 -s 0 -w output.txt dst port 80 and host ip-сервера
+<br>''&#035; tcpdump -n -i eth0 -s 0 -w output.txt dst port 80 and host ip-сервера''
 <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Показником служить великий потік одноманітних (і що не містять корисної інформації) пакетів від різних IP, направлених на один порт/сервіс (наприклад, корінь web-сервера або певний cgi-скріпт).  Остаточно визначившись, починаємо банити по ip-адресах (буде значно більше ефекту, якщо ти зробиш це на маршрутизаторі):
-<br>&#035; iptables -A INPUT -s xxx.xxx.xxx.xxx -p tcp --destination-port http -j DROP
+<br>''&#035; iptables -A INPUT -s xxx.xxx.xxx.xxx -p tcp --destination-port http -j DROP''
 <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Або відразу по підмережах:
-<br>&#035; iptables -a INPUT -s xxx.xxx.0.0/16 -p tcp --destination-port http -j  DROP
+<br>''&#035; iptables -a INPUT -s xxx.xxx.0.0/16 -p tcp --destination-port http -j  DROP''
 <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Це дасть тобі деяку фору, яку ти повинен використовувати для того, щоб звернутися до провайдеру/хостеру (з прикладеними до повідомлення балками web-сервера, ядра, брандмаузера і списком виявлених тобою ip-адрес). Більшість з них, звичайно, проігнорують це повідомлення (а хостинги з оплатою трафіку ще і порадіють - DoS-атака принесе їм прибуток) або просто відключать твій сервер. Але у будь-якому випадку це слід зробити обов'язково, – ефективний захист від DDoS можливий лише на магістральних каналах. Поодинці ти впораєшся з дрібними нападками, направленими на виснаження ресурсів сервера, але виявишся беззахисним перед більш-менш серйозним DDoS’ом.
 == Боротьба з DDoS в FREEBSD  ==
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Зменшуємо час чекання у відповідь пакету на запит SYN-ACK (захист від Syn-флуда):
-<br>&#035; sysctl net.inet.tcp.msl=7500
+<br>''&#035; sysctl net.inet.tcp.msl=7500''
 <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Перетворюємо сервер на чорну діру. Так ядро не слатиме у відповідь пакети при спробі підключитися до незайнятих портів (знижує навантаження на машину під час DDoS’а на випадкові порти):
-<br>&#035; sysctl net.inet.tcp.blackhole=2
+<br>''&#035; sysctl net.inet.tcp.blackhole=2
-<br>&#035; sysctl net.inet.udp.blackhole=1
+<br>&#035; sysctl net.inet.udp.blackhole=1''
 <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Обмежуємо число відповідей на icmp-повідомлення 50 в секунду (захист від Icmp-флуда):
-<br>&#035; sysctl net.inet.icmp.icmplim=50
+<br>''&#035; sysctl net.inet.icmp.icmplim=50''
 <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Збільшуємо максимальну кількість підключень до сервера (захист від всіх видів DDoS):
-<br>&#035; sysctl kern.ipc.somaxconn=32768
+<br>''&#035; sysctl kern.ipc.somaxconn=32768''
 <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Включаємо Device_polling - самостійний опит мережевого драйвера ядром на високих навантаженнях (істотно знижує навантаження на систему під час DDoS'а):
 <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;•	Збираємо заново ядро з опцією "options Device_polling";

@@ Рядок 98: / Рядок 98: @@
 <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.	Всі слухаючі мережеві сервіси, призначені для адміністративного використання, мають бути заховані брандмаузером від всіх, хто не повинен мати до них доступу. Тоді той, що атакує не зможе використовувати їх для проведення DoS-атаки або брутфорса.
 <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.	На підходах до сервера (найближчому маршрутизаторі) має бути встановлена система аналізу трафіку (Netflow в допомогу), яка дозволить своєчасно дізнатися про атаку, що починається, і вчасно прийняти заходи по її запобіганню.
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Додай в /etc/sysctl.conf наступні рядки:
+<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Додай в /etc/sysctl.conf наступні рядки:
 <br>&#035; vi /etc/sysctl.conf
 <br>&#035; Захист від спуфінга
@@ Рядок 110: / Рядок 110: @@
 <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Слід зазначити, що всі прийоми, приведені у минулому і цьому розділах, направлені на зниження ефективності DDoS-атак, що ставлять своєю метою витратити ресурси машини. Від флуда, що забиває канал сміттям, захиститися практично неможливо, і єдино правильний, але не завжди здійсненний спосіб боротьби полягає в тому, щоб "позбавити атаку сенсу". Якщо ти отримаєш в своє розпорядження дійсно широкий канал, який легко пропустить трафік невеликого ботнета, вважай, що від 90% атак твій сервер захищений. Є витонченіший спосіб захисту. Він заснований на організації розподіленої обчислювальної мережі, що включає безліч дублюючих серверів, які підключені до різних магістральних каналів. Коли обчислювальні потужності або пропускна спроможність каналу закінчуються, все нові клієнти перенаправляються на інший сервер (або ж поступово "розмазуються" по серверах за принципом round-robin). Це неймовірно дорога, але дуже стійка структура, завалити яку практично нереально.
 <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Інше більш-менш ефективне рішення полягає в покупці дорогих хардварних систем Cisco Traffic Anomaly Detector і Cisco Guard. Працюючи у в'язці, вони можуть подавити атаку, що починається, але, як і більшість інших рішень, заснованих на вченні і аналізі станів, дають збої. Тому слід гарненько подумати перед тим, як вибивати з начальства десятки тисячі доларів на такий захист.

@@ Рядок 10: / Рядок 10: @@
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Небезпека більшості DDoS-атак – в їх абсолютній прозорості і "нормальності". Адже якщо помилка в ПЗ завжди може бути виправлена, то повне зжирання ресурсів - явище майже буденне. З ними стикаються багато адміністраторів, коли ресурсів машини (ширина каналу) стає недостатньо, або web-сайт піддається слешдот-ефекту. І якщо різати трафік і ресурси для всіх підряд, то врятуєшся від DDoS, но втратиш велику половину клієнтів.
 <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Виходу з цієї ситуації фактично немає, проте наслідки DDoS-атак і їх ефективність можна істотно понизити за рахунок правильного налаштування маршрутизатора, брандмаузера і постійного аналізу аномалій в мережевому трафіку. У наступній частині статті ми послідовно розглянемо:
-<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1.	способи розпізнавання DDoS-атаки, що починається;
+<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1.	способи розпізнавання DDoS-атаки, що починається;
-<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.	методи боротьби з конкретними типами DDoS-атак;
+<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2.	методи боротьби з конкретними типами DDoS-атак;
 <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.	універсальні поради, які допоможуть підготуватися до DoS-атаки і понизити її ефективність.
 <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;В самому кінці буде дана відповідь на питання: що робити, коли почалася DDoS-атака.
@@ Рядок 93: / Рядок 93: @@
 == Універсальні поради ==
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbspЩоб не попасти в безвихідь під час обвалення DDoS-штурму на системи, необхідно ретельно підготувати їх до такої ситуації:
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Щоб не попасти в безвихідь під час обвалення DDoS-штурму на системи, необхідно ретельно підготувати їх до такої ситуації:
-<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp1.	Всі сервера, що мають прямий доступ в зовнішню мережу, мають бути підготовлені до простої і швидкої віддаленої. Великим плюсом буде наявність другого, адміністративного, мережевого інтерфейсу, через який можна дістати доступ до сервера в разі затурканості основного каналу.
+<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1.	Всі сервера, що мають прямий доступ в зовнішню мережу, мають бути підготовлені до простої і швидкої віддаленої. Великим плюсом буде наявність другого, адміністративного, мережевого інтерфейсу, через який можна дістати доступ до сервера в разі затурканості основного каналу.
-<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp2.	ПЗ, використовуване на сервері, завжди повинно знаходитися в актуальному стані. Всі дірки - пропатчені, оновлення встановлені. Це захистить тебе від DoS-атак, експлуатуючих баги в сервісах.
+<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.	ПЗ, використовуване на сервері, завжди повинно знаходитися в актуальному стані. Всі дірки - пропатчені, оновлення встановлені. Це захистить тебе від DoS-атак, експлуатуючих баги в сервісах.
-<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp3.	Всі слухаючі мережеві сервіси, призначені для адміністративного використання, мають бути заховані брандмаузером від всіх, хто не повинен мати до них доступу. Тоді той, що атакує не зможе використовувати їх для проведення DoS-атаки або брутфорса.
+<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.	Всі слухаючі мережеві сервіси, призначені для адміністративного використання, мають бути заховані брандмаузером від всіх, хто не повинен мати до них доступу. Тоді той, що атакує не зможе використовувати їх для проведення DoS-атаки або брутфорса.
-<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp4.	На підходах до сервера (найближчому маршрутизаторі) має бути встановлена система аналізу трафіку (Netflow в допомогу), яка дозволить своєчасно дізнатися про атаку, що починається, і вчасно прийняти заходи по її запобіганню.
+<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.	На підходах до сервера (найближчому маршрутизаторі) має бути встановлена система аналізу трафіку (Netflow в допомогу), яка дозволить своєчасно дізнатися про атаку, що починається, і вчасно прийняти заходи по її запобіганню.
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Додай в /etc/sysctl.conf наступні рядки:
 <br>&#035; vi /etc/sysctl.conf
 <br>&#035; Захист від спуфінга
@@ Рядок 109: / Рядок 108: @@
 <br>&#035; Кількість повірок перед закриттям з’єднання
 <br>net.ipv4.tcp_keepalive_probes = 5
-<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbspСлід зазначити, що всі прийоми, приведені у минулому і цьому розділах, направлені на зниження ефективності DDoS-атак, що ставлять своєю метою витратити ресурси машини. Від флуда, що забиває канал сміттям, захиститися практично неможливо, і єдино правильний, але не завжди здійсненний спосіб боротьби полягає в тому, щоб "позбавити атаку сенсу". Якщо ти отримаєш в своє розпорядження дійсно широкий канал, який легко пропустить трафік невеликого ботнета, вважай, що від 90% атак твій сервер захищений. Є витонченіший спосіб захисту. Він заснований на організації розподіленої обчислювальної мережі, що включає безліч дублюючих серверів, які підключені до різних магістральних каналів. Коли обчислювальні потужності або пропускна спроможність каналу закінчуються, все нові клієнти перенаправляються на інший сервер (або ж поступово "розмазуються" по серверах за принципом round-robin). Це неймовірно дорога, але дуже стійка структура, завалити яку практично нереально.
+<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Слід зазначити, що всі прийоми, приведені у минулому і цьому розділах, направлені на зниження ефективності DDoS-атак, що ставлять своєю метою витратити ресурси машини. Від флуда, що забиває канал сміттям, захиститися практично неможливо, і єдино правильний, але не завжди здійсненний спосіб боротьби полягає в тому, щоб "позбавити атаку сенсу". Якщо ти отримаєш в своє розпорядження дійсно широкий канал, який легко пропустить трафік невеликого ботнета, вважай, що від 90% атак твій сервер захищений. Є витонченіший спосіб захисту. Він заснований на організації розподіленої обчислювальної мережі, що включає безліч дублюючих серверів, які підключені до різних магістральних каналів. Коли обчислювальні потужності або пропускна спроможність каналу закінчуються, все нові клієнти перенаправляються на інший сервер (або ж поступово "розмазуються" по серверах за принципом round-robin). Це неймовірно дорога, але дуже стійка структура, завалити яку практично нереально.
-<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbspІнше більш-менш ефективне рішення полягає в покупці дорогих хардварних систем Cisco Traffic Anomaly Detector і Cisco Guard. Працюючи у в'язці, вони можуть подавити атаку, що починається, але, як і більшість інших рішень, заснованих на вченні і аналізі станів, дають збої. Тому слід гарненько подумати перед тим, як вибивати з начальства десятки тисячі доларів на такий захист.
+<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Інше більш-менш ефективне рішення полягає в покупці дорогих хардварних систем Cisco Traffic Anomaly Detector і Cisco Guard. Працюючи у в'язці, вони можуть подавити атаку, що починається, але, як і більшість інших рішень, заснованих на вченні і аналізі станів, дають збої. Тому слід гарненько подумати перед тим, як вибивати з начальства десятки тисячі доларів на такий захист.

← Попередня версія	Версія за 15:02, 5 квітня 2010
(Немає відмінностей)

← Попередня версія	Версія за 17:59, 29 березня 2010
(Немає відмінностей)

← Попередня версія		Версія за 16:11, 29 березня 2010
Рядок 91:		Рядок 91:
	<br>      Але, навіть якщо провайдерське устаткування зможе впоратися з цим алогічним алгоритмом обміну, замість вичавлених з провайдера декількох зайвих відсотків смуги, клієнт ризикує втратити значно більше завдяки збільшеному пакетному навантаженню . на свій домашній шлюз і, можливо навіть – на свій не дуже сучасний ПК! А що він зробить, побачивши, що швидкість закачування знизилася? Правильно, без тіні сумніву звернеться в технічну підтримку і звалить свої проблеми на провайдера.		<br>      Але, навіть якщо провайдерське устаткування зможе впоратися з цим алогічним алгоритмом обміну, замість вичавлених з провайдера декількох зайвих відсотків смуги, клієнт ризикує втратити значно більше завдяки збільшеному пакетному навантаженню . на свій домашній шлюз і, можливо навіть – на свій не дуже сучасний ПК! А що він зробить, побачивши, що швидкість закачування знизилася? Правильно, без тіні сумніву звернеться в технічну підтримку і звалить свої проблеми на провайдера.
	<br>      Оскільки локальна ситуація моделюється досить нескладно, я провів невеликий експеримент з наявним adsl-wifi-шлюзом, який можу запропонувати просунутим користувачам µTorrenta. Особливо вражаючим тест виглядатиме на древніх роутерах з Wifi. У моєму циклі випробувань пристрій почав «притормажувати» приблизно вже при 30-40 активних сесіях «звичайного» закачування, але при агресивній роботі по UDP (всього 5 роздач) втратило відразу майже третина смуги. Поза сумнівом, причина – в перевищення можливої кількості коректно оброблюваних пакетів за одиницю часу.		<br>      Оскільки локальна ситуація моделюється досить нескладно, я провів невеликий експеримент з наявним adsl-wifi-шлюзом, який можу запропонувати просунутим користувачам µTorrenta. Особливо вражаючим тест виглядатиме на древніх роутерах з Wifi. У моєму циклі випробувань пристрій почав «притормажувати» приблизно вже при 30-40 активних сесіях «звичайного» закачування, але при агресивній роботі по UDP (всього 5 роздач) втратило відразу майже третина смуги. Поза сумнівом, причина – в перевищення можливої кількості коректно оброблюваних пакетів за одиницю часу.
		+
		+	== Універсальні поради ==
		+	&nbspЩоб не попасти в безвихідь під час обвалення DDoS-штурму на системи, необхідно ретельно підготувати їх до такої ситуації:
		+	<br>          &nbsp1. Всі сервера, що мають прямий доступ в зовнішню мережу, мають бути підготовлені до простої і швидкої віддаленої. Великим плюсом буде наявність другого, адміністративного, мережевого інтерфейсу, через який можна дістати доступ до сервера в разі затурканості основного каналу.
		+	<br>          &nbsp2. ПЗ, використовуване на сервері, завжди повинно знаходитися в актуальному стані. Всі дірки - пропатчені, оновлення встановлені. Це захистить тебе від DoS-атак, експлуатуючих баги в сервісах.
		+	<br>          &nbsp3. Всі слухаючі мережеві сервіси, призначені для адміністративного використання, мають бути заховані брандмаузером від всіх, хто не повинен мати до них доступу. Тоді той, що атакує не зможе використовувати їх для проведення DoS-атаки або брутфорса.
		+	<br>          &nbsp4. На підходах до сервера (найближчому маршрутизаторі) має бути встановлена система аналізу трафіку (Netflow в допомогу), яка дозволить своєчасно дізнатися про атаку, що починається, і вчасно прийняти заходи по її запобіганню.
		+
		+	<br>     &nbspДодай в /etc/sysctl.conf наступні рядки:
		+	<br># vi /etc/sysctl.conf
		+	<br># Захист від спуфінга
		+	<br>net.ipv4.conf.default.rp_filter = 1
		+	<br># Перевіряти TCP-з’єднання кожну хвилину. Якщо на іншій стороні - легальна машина, вона зразу відповість. Значення по замовчуванні - 2 години.
		+	<br>net.ipv4.tcp_keepalive_time = 60
		+	<br># Повторити попитку через десять секунд
		+	net.ipv4.tcp_keepalive_intvl = 10
		+	<br># Кількість повірок перед закриттям з’єднання
		+	<br>net.ipv4.tcp_keepalive_probes = 5
		+	<br>     &nbspСлід зазначити, що всі прийоми, приведені у минулому і цьому розділах, направлені на зниження ефективності DDoS-атак, що ставлять своєю метою витратити ресурси машини. Від флуда, що забиває канал сміттям, захиститися практично неможливо, і єдино правильний, але не завжди здійсненний спосіб боротьби полягає в тому, щоб "позбавити атаку сенсу". Якщо ти отримаєш в своє розпорядження дійсно широкий канал, який легко пропустить трафік невеликого ботнета, вважай, що від 90% атак твій сервер захищений. Є витонченіший спосіб захисту. Він заснований на організації розподіленої обчислювальної мережі, що включає безліч дублюючих серверів, які підключені до різних магістральних каналів. Коли обчислювальні потужності або пропускна спроможність каналу закінчуються, все нові клієнти перенаправляються на інший сервер (або ж поступово "розмазуються" по серверах за принципом round-robin). Це неймовірно дорога, але дуже стійка структура, завалити яку практично нереально.
		+	<br>     &nbspІнше більш-менш ефективне рішення полягає в покупці дорогих хардварних систем Cisco Traffic Anomaly Detector і Cisco Guard. Працюючи у в'язці, вони можуть подавити атаку, що починається, але, як і більшість інших рішень, заснованих на вченні і аналізі станів, дають збої. Тому слід гарненько подумати перед тим, як вибивати з начальства десятки тисячі доларів на такий захист.

← Попередня версія		Версія за 16:06, 29 березня 2010
Рядок 73:		Рядок 73:
	<br>}''		<br>}''
	<br>У разі потреби можна задіювати nginx-модуль ngx_http_limit_req_module, що обмежує кількість одночасних підключень з однієї адреси <br>(http://sysoev.ru/nginx/docs/http/ngx_http_limit_req_module.html). Ресурсоємні скрипти можна захистити від ботів за допомогою затримок, кнопок "Натискуй мене", виставляння кукисів і інших прийомів, направлених на перевірку "людяності".		<br>У разі потреби можна задіювати nginx-модуль ngx_http_limit_req_module, що обмежує кількість одночасних підключень з однієї адреси <br>(http://sysoev.ru/nginx/docs/http/ngx_http_limit_req_module.html). Ресурсоємні скрипти можна захистити від ботів за допомогою затримок, кнопок "Натискуй мене", виставляння кукисів і інших прийомів, направлених на перевірку "людяності".
		+
		+	== Застосування кластера для вирішення проблеми атак на відмову ==
		+	Рішення прийшло само-собою - у нас в том-же ДЦ що і веб-сервер-сервер коштують ще і файлові сервера, в яких дуже навантажені гвинти, але проц і пам'ять практично гуляє. Серед таких серверів знайшовся двохядерний оптерон з 4Гб оператіви, вирішили сайт перенести туди. Щоб не міняти запису в ДНС, не юзати забиті канали, які служать для роздачі файлів і т.д. ми зробили наступне: оптерон був налагоджений для праці backend сервером, на основному сервері в конфіге nginx прописали для домена fileshare.in.ua цей backend, а останні сайти (їх на тому сервері всього біля десятка, окрім файлшари, сумарною відвідуваністю порядку 15К хостів і 70К хітів в добу) залишити як є.
		+	<br>      Рішення допомогло на якийсь час, сайт став нормально працювати і інші сайти теж пожвавіше стали відгукуватися. Десь через годин 6 після такого ось нововведення атака посилилася у декілька разів. Оптерон не витримав, файлшара знову просіла, проте останні сайти, які працювали не на оптероне, а на основному веб-сервері-сервері відмінно відгукувалися.
		+	<br>      Цього разу я вирішив що файлшара важливіше і зробив кластер: файлшара працювала на обох серверах, балансування робив nginx, а останні сайти крутилися на основному. При чому для файлшари веб-сервер-сервер був прописаний як резервний (тобто на основному сервері скрипти файлшари виконувалися лише якщо оптерон помер), і, щоб довго не чекати, я встановив параметр чекання відповіді від backend 2 секунди. Все налагодилося, отперон не завжди витримував, був постійно завантажений на 100%, але другий сервер підхоплював сайт якщо оптерон падав і все більш-менш працювало.
		+	<br>      Мабуть зловмисники стежили за розвитком подій тому, що буквально за годину, після того, як я розвів навантаження з файлшари на 2 сервери на атаку були кинута велика частина ресурсів. Вхідний трафік підріс в 3 рази в порівнянні із звичайним (далі йому просто вже нікуди зростати із-за обмежень провайдера), сайт впав і не піднімався, завантаження сервера (будь-якого) було на 100% вже відразу після рестарту апача, a на основному сервері підскочив до 60%, все було в ступорі небуло жодних шансів піднятися. Атака йшла не лише на файлшару але і останні сайти, навіть по ssh зайти було проблемою (не дивлячись на підвищений пріоритет) і я загасив nginx, щоб мати можливість щось зробити. Мабуть по маштабам атака була порівнянна з тими, від яких лежав 0day і progs не так давно. Не знаю вже кому ми так жити заважаємо, але думати про цей небуло часу, через 20 хвилин атака була повністю відбита;). Насамперед я додав в кластер ще 3 машини. По-друге залив на всі машини по nfs ісходники сайтів, подрехтовал конфіги апача і php і перевів сесію на mysql. Тепер всі сервера могли працювати як backend’и. Після цього я поставив на все сервера APC (php-акселератор), перевірив працездатність сайтів на кожному з серверів, прописав їх в конфіге nginx і знову його запустив. Атака, яка легко посадила 2 сервери, цього разу спасувала. Вхідний трафік не зменшився, атака йшла до ранку, але всім сайтам на хостингу це вже було по барабану. Навіть ab в 200 потоків, який я запустив паралельно з атакою нічого не змінив. Я боявся за базу - вона хоч і на потужній машині, але на одній, проте, мабуть за рахунок агресивного кешированія, база впоралася. А на веб-сервері-сервері опустився до 3, на сервері з'явився idle і тут-же взявся за справу антидос-скрипт. Запити валили шквалом, проте антидос знаходила час їх аналізувати і забанити найактивніших, тим самим понизивши навантаження десь на 40%. Підсумок: під час атаки сервера були завантажені не більше ніж на 60% (багато ресурсів віджирала роздача файлів), всі сайти (навіть на Вордпресі) відгукувалися швидко, атака йшла лісом. Сьогодні півдня довелося витратити на пошук багов, які з'явилися у зв'язку з такою зміною архітектури, проте в цілому результат хороший. Сподіватимемося, що сайт тепер захищений від ДДОС повністю. Чому повністю? тому що в ua-ix не буде достатньої кількості комп'ютерів, щоб його покласти, а ширина вхідного світу така, що сама стримає великий наплив ботів. Максимум, чого можна буде добитися, так це того, що сайт не буде доступний зі світу, проте і для цього треба буде сильно постаратися.
		+	<br>      Принаймні це мій оптимістичний прогноз, думаю, що організатори атак не зупиняться на досягнутому і сайт ще не раз перевірять на міцність (та в і нас є ще гуляючі сервера+можно зібрати mysql кластер), проте те що якась кількість грошей вони вже спустили в унітаз (10 годин безрезультатної досить масованої атаки), це радує.
		+
		+	== UDP та торенти ==
		+	Очима фахівця, суть того, що відбувається така: з кінця січня (стабільна µTorrent версія 2.0 з µTP вийшла якраз 25 січня, офіційно доступна з 3 лютого) в статистичних звітах операторів зв'язку виявлено безперервне зростання UDP-трафіку і одночасне зменшення середньої величини пакетів, які істотно збільшували навантаження на мережеве устаткування. Спостереження показали, що чим сильніше завантажений канал клієнта, тим дрібніші пакети, довша черга і вище навантаження на роутерах.
		+	<br>      У всіх випадках причиною що відбувається був названий МікроТоррент (µTorrent), з версії 1.8.1 що почав освоювати протокол обміну µTP (Micro Transport Protocol, до речі, що так не дістав схвалення IETF). І провайдерам просто повезло, що через низку обставин клієнти до версії µTorrent v2.0 не оновилися одномоментно. (У ній, за умовчанням, udp-завантаження стартує першим, а якщо не вийде, то лише тоді – по TCP). Інакше наростання проблем в мережі замість плавного носило б миттєвий характер і, можливо, відразу «повалило» до третини вітчизняних провайдерів. Останні могли б трактувати поведінку як ddos-атаки на провайдерське устаткування з відповідним недемократичним «закручуванням гайок» в аварійному порядку.
		+	<br>      Остаточний аналіз ситуації був ускладнений тим, що у відкритому доступі повного опису протоколу, який став займати значну долю UDP трафіку, немає: цей опис застарілий і не дає повної картини, а стаття у Вікіпедії досить поверхневий описує характер проблем.
		+	<br>      Реінженеринг дозволив не лише переконатися, що згідно з алгоритмами µTP в процесі обміну зменшується довжина пакету із зростанням завантаження каналу, але і передбачити, що для підтвердження використовуються udp-пакети квитування (з функцією, типа ACK) розміром в 2 десятки байт.
		+	<br>      Логіка розробників протоколу і алгоритмів µTorrent може виправдовуватися тим, що вони не вважають розумними чекати TCP-ACK від доставки пакету. Адже tcp-потік формується послідовно, і якщо в стеку, наприклад, вже знаходиться 50 пакетів, але немає два, то передачу вони не здійснюватимуть, поки втрачені не прийдуть. А ось пірінгове застосування за своєю суттю якраз і не критично до строгої послідовності у вступі інформації, адже воно запрошує і збирає файли по шматочках.
		+	<br>      І що виходить насправді? Додаток, відповідно, зменшує розмір пакету, тому що у нього зростає час між відсиланням пакету і приходом квитанції. Але зростає-то воно тому, що пакети стоять в переповненій черзі на «шейпері». І замість того що б спочатку зменшити кількість посланих, алгоритм ... далі зменшує їх розмір. В результаті, при даному агресивному алгоритмі використання udp-протоколу МікроТоррентом результуючий трафік (ємкість каналу) на клієнтові практично не міняється. Тобто вихідна мрія творців даного ПЗ – завантажити канал «під зав'язку» від цього ближче не стає. Міняється лише структура трафіку – з'являється більше дрібних пакетів, що для провайдера насправді небезпечніше чим зростання трафіку.
		+	<br>      Давайте порахуємо: якщо в ходу пакети по 150 байт, то при швидкості 100 мегабіт операторові потрібно буде обробити в секунду ... 87 тисяч пакетів! Не всякий провайдер зможе оперативно відреагувати на виниклу проблему: замінити ті ж сервери доступа/роутери на високопродуктивних не всім по кишені. В результаті, багато провайдерів вимушено було для своїх клієнтів ввести на додаток до обмежень по Mbps, ще і по pps.
		+	<br>      Але, навіть якщо провайдерське устаткування зможе впоратися з цим алогічним алгоритмом обміну, замість вичавлених з провайдера декількох зайвих відсотків смуги, клієнт ризикує втратити значно більше завдяки збільшеному пакетному навантаженню . на свій домашній шлюз і, можливо навіть – на свій не дуже сучасний ПК! А що він зробить, побачивши, що швидкість закачування знизилася? Правильно, без тіні сумніву звернеться в технічну підтримку і звалить свої проблеми на провайдера.
		+	<br>      Оскільки локальна ситуація моделюється досить нескладно, я провів невеликий експеримент з наявним adsl-wifi-шлюзом, який можу запропонувати просунутим користувачам µTorrenta. Особливо вражаючим тест виглядатиме на древніх роутерах з Wifi. У моєму циклі випробувань пристрій почав «притормажувати» приблизно вже при 30-40 активних сесіях «звичайного» закачування, але при агресивній роботі по UDP (всього 5 роздач) втратило відразу майже третина смуги. Поза сумнівом, причина – в перевищення можливої кількості коректно оброблюваних пакетів за одиницю часу.