Як і в які моменти системи може статися атака відмови в обслуговуванні? Ми не лише отримуємо відповідь із цієї статті, але й про інструменти, які ми можемо використовувати для перевірки DoS, DDoS-атак.

Моя стаття намагається представити технічну основу атак відмови в обслуговуванні (DoS). З одного боку, я обговорюю те, що ми маємо на увазі під атаками DoS та DDoS (розподілений DoS). Пізніше, заглибившись трохи глибше, я поясню, чому ці атаки можливі і наскільки технічно вони працюють. Нарешті, ми розглянемо можливі способи захистити себе, виділивши найбільш інноваційні доступні рішення.

Атаки відмови в обслуговуванні - це випадки, коли один або кілька зловмисників роблять доступ до послуг клієнтів, до яких користувачі хочуть отримати доступ. Цікаво, що якщо зловмисник здійснює атаку, це, як правило, здійснюється шляхом спільного запуску атакуючого пристрою (який є спеціально розробленим програмним забезпеченням). Найбільш пам’ятним прикладом цього є LOIC, створений анонімною групою (похідною від абревіатури “Іонна гармата з низькою орбітою”), яка розпочала атаку на Церкву Саєнтології, RIAA (Американська асоціація видавців) та організації, що атакують Wikileaks.

Далі ми поговоримо про мережеві послуги та чому вони можуть стати недоступними. Це може бути пов'язано, серед іншого, з тим, що запити, надіслані через мережу, не надходять на сервер або не можуть бути оброблені сервером. Причини можуть включати пропускну здатність, проміжний мережевий пристрій або переривчасте перевантаження сервера, або збій і вимкнення деякого програмного забезпечення (веб-сервера, менеджера баз даних, веб-програми), що працює на сервері. Ми обробляємо характер атак у відповідному порядку. Для того, щоб не лише залишатися на рівні теоретичного пояснення, для кожної теми я описав інструменти, за допомогою яких читач може перевірити стійкість власної програми та інфраструктури до DoS та DDoS-атак.

Атака на мережевому рівні стає можливою завдяки тому, що найбільш широко використовувана в даний час комбінація мережевих протоколів базується на протоколах TCP/IP для побудови свого роду каналу зв'язку (сокету TCP) між сервером і клієнтом. При цьому т. Зв. Відбувається тристороннє рукостискання TCP. Але що трапиться, якщо клієнт ніколи не надсилає пакет TCP третього кроку? Ресурси (пам'ять, час процесора) виділяються для створеного сокета як на сервері, так і на деяких проміжних мережевих пристроях. Вони випускаються лише тоді, коли встановлений тайм-аут закінчується, а сервер звільняє ресурси. На рівні інфраструктури це виглядає так: Інтернет-інфраструктура розташована між клієнтами (наприклад, зловмисниками) та сервером, маршрутизатором (провайдерами) провайдера, що надає IP-адресу сервера, та компанією чи організацією, яка належним чином працює з сервером. у цьому випадку він також працює брандмауер, IDS і, можливо, IPS. Будь-яка з них може постраждати через відмову в обслуговуванні та стати вузьким місцем.

практиці

Програма під назвою hping3, яку можна викликати за допомогою смуги пропускання лише за умови виклику з відповідною параметризацією (– Flood). Очевидним способом захисту є збільшення доступних ресурсів або зменшення затримки для напіввідкритих TCP-з'єднань. Сучасні мережеві пристрої роблять це можливим. Можна бачити, що за допомогою цього методу ми можемо збільшити потреби в ресурсах для атаки, але ми не досягаємо зміни величини. Зміна величини вимагає більш сміливого рішення, про яке я розповім наприкінці статті. Блокування вихідних адрес проти інтелектуальних зловмисників не є хорошим рішенням на практиці, оскільки вихідна IP-адреса в IP-пакетах може бути підроблена. Зловмисник може використати це за первісною метою, оскільки, якщо вихідна адреса постійно підробляється до певної IP-адреси або діапазону адрес, вона буде заборонена. Зазначений hping3 може також підробляти адресу джерела, але корисно знати, що більш інтелектуальні маршрутизатори не дозволятимуть вихідні IP-пакети, які не надходять з діапазону, що відповідає вихідній адресі в IP-пакеті.

Нижче описані ще два хитрі варіанти, які намагаються скористатися помилками, які можуть виникнути під час обробки HTTP-запитів. Суть обох прийомів полягає в тому, щоб спробувати подовжити обробку HTTP-запиту якомога довше. Кожен запит HTTP містить заголовок, який може містити інформацію та специфікації, пов'язані з його обробкою, крім того, запити POST також містять дані у певному форматі, які повинні бути оброблені сервером для обслуговування запиту.

Подовження надсилання заголовка HTTP змушує веб-сервер довго чекати інструменту під назвою Slowloris (http://ha.ckers.org/slowloris/), що є програмою, написаною на perl. Суть фокусу полягає в тому, щоб робити незавершені HTTP-запити на сервер, час від часу надсилаючи черговий фрагмент із заголовка, щоб терпіння не закінчилося досить швидко. Якщо ми мали протестувати такий тип атак, варто зазначити, що різні реалізації веб-серверів можуть по-різному обробляти різні запити HTTP. Наприклад, до завершення запиту GET певний тип веб-сервера може фактично не розподіляти ресурси, виділені для обслуговування цього запиту. І навпаки, якщо, наприклад, запити POST обробляються по-різному, ресурси все одно можуть вичерпатися. Подібними інструментами є PyLoris, QSlowloris та slowhttptest.

Інструмент RUDY (r-u-dead-yet) (http://www.hybridsec.com/tools/rudy/) насправді є програмою, написаною на python. Запити HTTP POST надсилають частину вмісту повільно, поштучно, на сервер, змушуючи його чекати. Інструмент можна параметризувати за допомогою командного рядка та конфігураційного файлу, що робить ще зручнішим розпізнавання параметрів POST, ввівши URL-адресу та вибравши, який із них спробувати в меню.

Самі веб-додатки можуть бути вразливими до DoS-атак, якщо вони підтримують функції, які можуть спричинити значне навантаження на внутрішні системи. Наприклад, ви можете думати про складні запити або обробку інтенсивного введення-виведення даних. Якщо зловмисник може ідентифікувати таку функцію, це може відносно легко спричинити серйозні проблеми у операторів серверів. У деяких програмах неправильне ведення журналу також може спричинити проблеми для користувачів послуг. Наприклад, якщо файли журналу знаходяться на сервері додатків, а пул зберігання заповнюється, операційна система, що запускає програму, може назавжди стати непрацездатною. Спочатку ця проблема може здатися банальною, але, виходячи з практичного досвіду, веб-програми, які працюють тривалий час, також можуть містити такі помилки. Apache JMeter чудово підходить для тестування подібних проблем.

Після проблем давайте також коротко розглянемо варіанти захисту. Теоретично ідеального захисту не існує, оскільки на практиці ми можемо лише збільшити вимоги до ресурсів для зловмисника для успішної атаки. Сучасні мережеві пристрої можуть включати захист від DoS, наприклад, маршрутизатор може обробляти TCP-тристороннє рукостискання: наприклад, напіввідкриті TCP-з'єднання ще не переадресовані на фактичний сервер. Подумавши, легко помітити, що атака пов’язує ресурси оборонного пристрою, тому ресурси, витрачені на захист, також можуть бути вичерпані. Вже згаданий захист на основі блокування IP-джерел також можна знайти у багатьох брандмауерах, на практиці в цьому випадку підозрілі IP-адреси можуть бути заблоковані на короткий час. Тут проблема може бути у виявленні підозрілої діяльності та термінах заборони. На практиці пристрої з IP-адресами, які виконують звичайну діяльність, також можуть бути заборонені, якщо вони намагаються підключитися до сервера "занадто багато разів" за певний проміжок часу. З цієї причини заборона зазвичай використовується протягом короткого часу. У цьому випадку ми можемо врахувати міркування зловмисника: через проміжок часу він запускає лише вихідний IP, який ще не ініціював заборону, і збільшує кількість вихідних IP, поки атака не буде успішною.

Для вже цитованого інноваційного рішення уявіть, що зловмисник може не тільки використовувати декілька IP-адрес джерела, але й захист розподілити. Якщо трафік від клієнтів направляється через «хмару» великої кількості спеціальних мережевих пристроїв, а елементи хмари можуть індивідуально виявляти та захищатись від атак, завдання зловмисника може бути ускладнено. Таким чином, для того, щоб атака була успішною, зловмисникові доведеться вимкнути всю хмару, а не невелику кількість маршрутизаторів, брандмауерів та серверів. Така інфраструктура, очевидно, не варта для всіх компаній, але є постачальники послуг (Verizon - Terremark, Verisign, CloudFlare, Incapsula), які можуть забезпечити такий захист.

Нарешті, я хотів би розповісти про власний досвід тестування вразливості DoS. Інфраструктуру будь-якого хмарного провайдера тепер можна використовувати як очевидне рішення для моделювання великої кількості зловмисників. Особисто я маю практичний досвід роботи з хмарною службою Amazon EC2. Тут, після введення реєстрації та номера кредитної картки, ми можемо змоделювати ботнети зловмисників за допомогою 20 віртуальних машин (загалом 140 хостів) на регіон у 7 регіонах (європейському, 3 північноамериканських, південноамериканських та двох азіатських). Звичайно, слід зазначити, що у віддалених регіонах пропускна здатність може бути меншою, а затримка мережі може бути вищою, але досвід показав, що моделювання широкомасштабних атак можна вирішити деякий час і за рахунок декількох сотень доларів .