На цій сторінці ми представляємо кілька способів пом’якшення атак DoS. Усі ці підходи можна комбінувати. Однак на даний момент не існує єдиного універсального рішення цієї проблеми. Захист сайту від атаки вимагає креативності та індивідуального підходу.

Огляд реалізованих засобів захисту в демоні tor наведено в розділі Огляд у розділі Механізми запобігання відмові в обслуговуванні в Tor специфікації, і тут ми даємо кілька практичних порад.

Обмеження швидкості в точках вступу

Оскільки Пропозиція 305 була реалізована, деякі torrc було додано параметри, які допомагають пом’якшити атаки DoS у початкових точках:

  • HiddenServiceEnableIntroDoSDefense: увімкнути захист від DoS на рівні початкової точки. Якщо це ввімкнено, параметр швидкості та пакету буде надіслано до точки вступу, яка потім використовуватиме їх для застосування обмеження швидкості для запиту на введення до цієї служби.

  • HiddenServiceEnableIntroDoSBurstPerSec: дозволений пакет введення клієнта за секунду в точці введення. Якщо цей параметр дорівнює 0, він вважається нескінченним, і, таким чином, якщо встановлено HiddenServiceEnableIntroDoSDefense, він фактично вимикає захист.

  • HiddenServiceEnableIntroDoSRatePerSec: дозволена швидкість введення клієнта за секунду в точці введення. Якщо цей параметр дорівнює 0, він вважається нескінченним, і, таким чином, якщо встановлено HiddenServiceEnableIntroDoSDefense, він фактично вимикає захист.

Щоб дізнатися більше про те, як вони працюють, перегляньте довідкову сторінку tor(1) і розширення захисту від відмови в обслуговуванні (DOS_PARAMS) розділу специфікації Onion Services v3.

Доказ роботи (PoW) перед встановленням ланцюгів зустрічі

Механізм захисту Proof of Work (PoW) докладно пояснюється в PoW FAQ, і його можна налаштувати для кожної служби Onion за допомогою таких параметрів torrc:

  • HiddenServicePoWDefensesEnabled: увімкнути захист DoS на основі перевірки роботи. Якщо ввімкнено, tor включатиме параметри для додаткової головоломки клієнта в зашифровану частину дескриптора цієї прихованої служби. Пріоритет вхідних запитів на побачення буде залежати від обсягу зусиль, які клієнт вирішив докласти під час обчислення рішення головоломки. Служба періодично оновлюватиме запропоновану кількість зусиль, виходячи з навантаження на атаку, і повністю відключатиме головоломку, якщо служба не буде перевантажена.

  • HiddenServicePoWQueueRate: постійна швидкість відправки запитів на побачення з пріоритетної черги за секунду.

  • HiddenServicePoWQueueBurst: максимальний розмір пакету для запитів на побачення, які одночасно обробляються з пріоритетної черги.

Наступний глобальний варіант застосовний як до служб onion, так і до їхніх клієнтів:

  • CompiledProofOfWorkHash: коли ввімкнено пом’якшення DoS-атак із підтвердженням роботи, і самі служби, і клієнти, які підключаються, використовуватимуть динамічно згенеровану хеш-функцію як частину обчислення головоломки.

PoW увімкнено за замовчуванням у C Tor версії 0.4.8.1-alpha (але його можна вимкнути, якщо скомпілювати за допомогою --disable-module-pow). Базову підтримку PoW можна перевірити, виконавши цю команду:

tor --list-modules
relay: yes
dirauth: yes
dircache: yes
pow: yes

Якщо у вас є pow: yes, то у вас є механізм захисту PoW, вбудований у C Tor.

Відповідно до ліцензійних вимог клієнтські бібліотеки головоломок PoW v1 (Equi-X і HashX від tevador, обидва під LGPL-3.0) увімкнено, лише якщо tor скомпільовано з --enable-gpl. Це можна підтвердити, виконавши таку команду:

tor --version
Tor версія 0.4.8.3-rc.
На цю збірку Tor поширюється Загальна публічна ліцензія GNU (https://www.gnu.org/licenses/gpl-3.0.en.html)
Tor працює в Linux із Libevent 2.1.12-stable, OpenSSL 3.0.9, Zlib 1.2.13, Liblzma 5.4.1, Libzstd N/A та Glibc 2.36 як libc.
Tor зібрано з GCC версії 12.2.0

Якщо у вашому встановленому C Tor не ввімкнуто PoW або він не створений з підтримкою GNU GPL, вам доведеться шукати інші пакунки або скомпілювати його самостійно.

Обмеження потоків у встановлених каналах зустрічі

Наступні параметри конфігурації можна використовувати для обмеження з’єднань у колах зустрічей:

  • HiddenServiceMaxStreams: Максимальна кількість одночасних потоків (з’єднань) на канал зустрічі. Максимально допустиме значення – 65535. (Якщо встановити значення 0, буде дозволено необмежену кількість одночасних потоків.)

  • HiddenServiceMaxStreamsCloseCircuit: якщо встановлено значення 1, то перевищення HiddenServiceMaxStreams призведе до розриву ланцюга зустрічі, що порушує правила, на відміну від запитів на створення потоку, які перевищують ліміт, мовчки ігноруватимуться.

Onionbalance

Onionbalance дозволяє операторам Onion Service досягти властивості високої доступності, дозволяючи кільком машинам обробляти запити на Onion Service. Ви можете використовувати Onionbalance для горизонтального масштабування. Чим більше ви масштабуєтеся, тим важче зловмисникам перемогти вас. Onionbalance доступний для v3 Onion Services.

Обмеження швидкості веб-сервера

Якщо зловмисники переповнюють вас агресивними схемами, які виконують забагато запитів, спробуйте виявити це надмірне використання та вбити їх за допомогою параметра torrc HiddenServiceExportCircuitID. Ви можете використовувати власну евристику або використовувати вашого веб-сервера модуль обмеження швидкості.

Наведені вище поради допоможуть вам утриматися на плаву в неспокійні часи. Водночас ми працюємо над вдосконаленими засобами захисту, щоб операторам onion потрібно було менше ручного налаштування та майстрування.

Кешування

Ще один спосіб зменшити навантаження на ваш сервіс — реалізувати кешування вмісту безпосередньо у серверній програмі або за допомогою налаштування проксі-інтерфейсу кешування.

Авторизація клієнта або кілька цибулинних адрес для розділення ваших користувачів

Якщо у вас є користувачі, яким ви довіряєте, надайте їм спеціальну службу Onion і облікові дані для авторизації клієнта, щоб вона завжди була доступною. Для користувачів, яким ви не довіряєте, розділіть їх на кілька адрес. Тим не менш, наявність занадто великої кількості адрес цибулі насправді погано впливає на вашу безпеку (через використання багатьох захисних вузлів), тому намагайтеся використовувати авторизацію клієнта, коли це можливо.

Captcha і куки

Якщо вам потрібно ще більше обмежити кількість користувачів, розділіть свою інфраструктуру на рівні та розмістіть Captcha біля інтерфейсу. Таким чином зловмисникам доведеться розгадати Captcha, перш ніж вони зможуть атакувати глибше вашу інфраструктуру.

Captcha – це спосіб пом’якшити DDoS-атаки. Коли запит надходить від клієнта, перевіряється, чи містить клієнт правильний захищений файл cookie, інакше переспрямовує на сторінку recaptcha. Клієнт вводить літери captcha. Nginx надсилає ці вхідні листи на сервер recaptcha для перевірки.

Правильна відповідь від сервера recaptcha починається з "true...", інакше вона починається з "false...". Додайте безпечний файл cookie для правильного перевіреного клієнта, перенаправте клієнта на сторінку, яку він хоче переглянути.

Можна застосувати Captcha безпосередньо на вашому веб-сервері за допомогою Nginx і OpenResty за допомогою Lua для створення та перевірки зображень captcha. Цю реалізацію непросто налаштувати.

Альтернативою може бути просто реалізація виклику тестових файлів cookie. На вашому веб-сервері перевірте, чи можуть клієнти встановлювати дійсні файли cookie, зловмисні клієнти часто не мають цієї функції. У Nginx Cloudflare надає бібліотеку для взаємодії з файлами cookie.

Інші методи включають переконання, що клієнти, які підключаються до вашого .onion, мають дійсний заголовок User-Agent, а заголовок Referer не має значення, яке можна пов’язати з атакою.