У вас є атака відмови в службі. Якщо ви бачите трафік, що надходить з декількох мереж (різні IP-адреси в різних підмережах), у вас є розподілене відмову в обслуговуванні (DDoS); якщо все відбувається з того самого місця, у вас є звичайний старий DoS. Це може бути корисно перевірити, якщо ви в змозі; використовуйте netstat для перевірки. Однак це може бути важко зробити.
Відмова в обслуговуванні зазвичай підпадає на пару категорій: на основі трафіку та навантаження. Останній пункт (із сервісом збоїв) - це DoS на основі експлоатації і зовсім інший.
Якщо ви намагаєтеся визначити, який тип атаки відбувається, можливо, вам захочеться зафіксувати деякий трафік (використовуючи дротяний штрих, tcpdump або libpcap). Ви повинні, по можливості, але також пам’ятати, що ви, мабуть, захопите досить багато трафіку.
Як часто це не так, вони надходитимуть із ботнетів (мереж компрометованих хостів під центральним контролем якогось зловмисника, чиї торги вони будуть робити). Це хороший спосіб для зловмисника (дуже дешево) придбати пропускну здатність висхідної лінії безлічі різних хостів у різних мережах для нападу на вас, охоплюючи їх сліди. Низька орбіта Іон гармата є одним з прикладів ботнету (незважаючи на те , добровільно замість шкідливого походження); Зевс - більш типовий.
На основі трафіку
Якщо ви перебуваєте під DoS на основі трафіку, ви виявите, що на ваш сервер надходить стільки трафіку, що його зв'язок з Інтернетом повністю насичений. Під час пінгнгу вашого сервера з інших місць є високий показник втрат пакетів, і (залежно від використовуваних методів маршрутизації) іноді ви також бачите дійсно високу затримку (ping - висока). Цей вид атаки зазвичай є DDoS.
Хоча це справді "гучна" атака, і очевидно, що відбувається, адміністратору сервера важко пом'якшити (а користувачеві спільного хостингу неможливо пом'якшити). Вам знадобиться допомога вашого провайдера; дайте їм знати, що ви знаходитесь під DDoS, і вони можуть допомогти.
Однак більшість провайдерів Інтернет-послуг та транзитних постачальників будуть активно усвідомлювати, що відбувається, і опублікує маршрут чорного каналу для вашого сервера. Це означає, що вони публікують маршрут до вашого сервера з якомога 0.0.0.0меншими витратами через : вони роблять трафік на ваш сервер більше не маршрутизованим в Інтернеті. Ці маршрути зазвичай / 32, і з часом вони видаляються. Це вам зовсім не допомагає; мета - захистити мережу провайдера від потоку. На час роботи ваш сервер фактично втратить доступ до Інтернету.
Єдиний спосіб, коли ваш Інтернет-провайдер (або ви, якщо у вас є власний АС), зможе допомогти - це якщо вони використовують інтелектуальні формувачі трафіку, які можуть виявити та обмежити швидкість ймовірного DDoS-трафіку. Не у всіх є ця технологія. Однак якщо трафік надходить з однієї або двох мереж або одного хоста, вони також можуть перекрити трафік перед вами.
Коротше кажучи, у цій проблемі можна зробити дуже мало . Найкращим довгостроковим рішенням є розміщення ваших послуг у багатьох різних місцях в Інтернеті, які повинні мати DDoSed індивідуально і одночасно, що робить DDoS значно дорожчим. Стратегії цього залежать від послуги, яку потрібно захистити; DNS можна захистити за допомогою декількох авторитетних серверів імен, SMTP із резервними записами MX та обмінниками пошти та HTTP з кругоспроможним DNS або мультихомінгом (але деяка деградація може бути помітна протягом тривалості).
Балансири навантажень рідко є ефективним рішенням цієї проблеми, оскільки сам балансир навантаження піддається одній і тій же проблемі і просто створює вузьке місце. IPTables або інші правила брандмауера не допоможуть, оскільки проблема полягає в тому, що ваша труба насичена. Як тільки з'єднання бачать ваш брандмауер, уже пізно ; пропускна здатність вашого веб-сайту була витрачена. Не має значення, що ви робите зі зв’язками; атака пом'якшується або закінчується, коли кількість вхідного трафіку повертається до нормального.
Якщо ви це можете зробити, подумайте про використання мережі розподілу вмісту (CDN), наприклад Akamai, Limelight та CDN77, або скористайтеся службою очищення DDoS, наприклад CloudFlare або Prolexic. Ці служби вживають активних заходів для пом’якшення таких типів атак, а також мають стільки доступної пропускної здатності в стільки різних місцях, що затоплення їх взагалі неможливо.
Якщо ви вирішили використовувати CloudFlare (або будь-який інший CDN / проксі), не забудьте приховати IP вашого сервера. Якщо зловмисник дізнається IP-адресу, він знову може DDoS безпосередньо на вашому сервері, минаючи CloudFlare. Щоб приховати IP-адресу, ваш сервер ніколи не повинен спілкуватися безпосередньо з іншими серверами / користувачами, якщо вони не є безпечними. Наприклад, ваш сервер не повинен надсилати електронні листи безпосередньо користувачам. Це не застосовується, якщо ви розміщуєте весь вміст на CDN і не маєте власного сервера.
Також деякі VPS і хостинг-провайдери краще пом'якшують ці атаки, ніж інші. Взагалі, чим вони більше, тим краще вони будуть у цьому; постачальник, який дуже добре вписується та має велику пропускну здатність, буде, природно, більш стійким, а той, хто має активну та повністю укомплектовану команду мережевих операцій, зможе реагувати швидше.
На основі навантаження
Коли ви відчуваєте DDoS на основі завантаження, ви помічаєте, що середнє значення завантаження аномально високе (або використання процесора, оперативної пам’яті чи диска, залежно від вашої платформи та особливостей). Хоча сервер, здається, не робить нічого корисного, він дуже зайнятий. Часто в журналах є велика кількість записів, що вказують на незвичні умови. Частіше за все це відбувається з багатьох місць і є DDoS, але це не обов'язково. Тут навіть не повинно бути багато різних господарів .
Ця атака заснована на тому, щоб ваша служба робила багато дорогих речей. Це може бути щось на кшталт відкриття великої кількості з'єднань TCP та змусити вас підтримувати стан для них, або завантажувати на вашу послугу надмірно великі чи численні файли, або, можливо, робити дуже дорогі пошуки, або робити все, що дорого обробляти. Трафік знаходиться в межах того, що ви запланували і може взяти на себе, але типи запитів, які надсилаються, занадто дорогі, щоб обробляти так багато .
По-перше, те, що такий тип атаки можливий, часто є свідченням проблеми конфігурації або помилкиу вашій службі. Наприклад, у вас може бути ввімкнено надмірно багатослівний журнал і ви можете зберігати журнали на те, що дуже повільно писати. Якщо хтось усвідомлює це і робить багато чого, що змушує вас записувати на диск багато журналів, ваш сервер сповільниться до повзання. Ваше програмне забезпечення також може робити щось надзвичайно неефективно для певних випадків введення; причин настільки ж багато, як і програм, але два приклади - це ситуація, яка змушує вашу службу не закривати сеанс, який інакше закінчився, і ситуація, яка змушує породити дочірній процес і залишити його. Якщо у вас з’являються десятки тисяч відкритих зв’язків із станом, які слід відстежувати, або десятки тисяч дочірніх процесів, у вас виникнуть проблеми.
Перше, що ви можете зробити, це використовувати брандмауер, щоб скинути трафік . Це не завжди можливо, але якщо є якась характеристика, яку ви можете знайти у вхідному трафіку (tcpdump може бути приємним для цього, якщо трафік невеликий), ви можете скинути його на брандмауер, і він більше не спричинить проблем. Інше, що потрібно зробити - це виправити помилку у вашій службі (зв’яжіться з продавцем і будьте готові до тривалого досвіду підтримки).
Однак якщо це проблема з конфігурацією, починайте там . Відключіть журнал на виробничих системах до розумного рівня (залежно від програми, це зазвичай за замовчуванням, і зазвичай передбачає переконання, що рівень "налагодження" та "багатослівний" журнал вимкнено; якщо все, що робить користувач, увійшло в точне та точні деталі, ваш журнал занадто багатослівний). Крім того, перевірте обмеження щодо дочірніх процесів та запитів , можливо, заглушіть вхідні запити, з'єднання за IP та кількість дозволених дочірніх процесів, якщо це застосовно.
Само собою зрозуміло, що чим краще налаштований і краще забезпечений ваш сервер, тим складніше буде такий тип атаки. Уникайте особливих завдань, зокрема, оперативної пам'яті та процесора. Забезпечте швидке та надійне підключення до речей, таких як бази даних та дискове зберігання.
На основі експлуатації
Якщо ваша служба таємничим чином виходить з ладу надзвичайно швидко після того, як вас вивели, особливо якщо ви можете встановити шаблон запитів, що передують збою, і запит є нетиповим або не відповідає очікуваним шаблонам використання, ви можете відчути DoS на основі експлуатації. Це може прийти лише від одного хоста (із майже будь-яким типом підключення до Інтернету) або з багатьох хостів.
Це багато в чому схоже на DoS на основі навантаження і має в основному ті ж причини і пом'якшення. Різниця полягає лише в тому, що в цьому випадку помилка не спричиняє марнотратство вашого сервера, а вмирає. Зловмисник, як правило, використовує віддалену вразливість аварійних ситуацій, наприклад, скритий вхід, який спричиняє затримку нуля або щось у вашій службі.
Поводьтесь із цим аналогічно з несанкціонованою атакою віддаленого доступу. Брандмауер проти вихідних хостів та тип трафіку, якщо їх можна буде зафіксувати. Використовуйте перевірку зворотних проксі, якщо це можливо. Зберіть криміналістичні докази (спробуйте зафіксувати частину трафіку), подайте квиток на помилку у постачальника та розгляньте можливість подати скаргу на зловживання (або юридичну скаргу) також на походження.
Ці напади досить дешеві, якщо їх можна знайти, і вони можуть бути дуже потужними, але також відносно легко відстежувати та зупиняти. Однак методи, корисні проти DDoS на основі трафіку, як правило, марні проти DoS на основі експлуатації.