Перед початком
Перелічіть публічні адреси, TCP та UDP порти, вебслужби й керування. Опишіть нормальний трафік і права на зміну маршрутів. До впровадження підтвердьте реальний обсяг фільтрації та порядок повідомлення про збої.
L3 стосується мережевого шару
IP-фільтрація може обробляти трафік до його надходження на origin. Захист залежить від включених адрес і маршрутів. Прихована адреса не є обмеженою, якщо до неї можна підключитися напряму. Перевірте старі DNS-записи, попередні адреси та інші служби, які можуть створювати альтернативний вхід і обходити запланований захищений шлях.
L4 має відповідати транспорту
TCP й UDP працюють по-різному. Підключення, запити сервера, голос і файли можуть використовувати різні шляхи. Підтвердьте дозволені порти та звичайні пакети: надто суворий фільтр заважає також реальним гравцям. Успішна TCP-перевірка не доводить роботу UDP чи захист усіх потрібних функцій гри тими самими правилами.
L7 охоплює конкретну програму
HTTP-проксі може обробляти HTTP, але не автоматично протокол кожної гри. Обіцянка L7 має називати конкретні запити, точки підключення та правила. Врахуйте автентифікацію й завантаження файлів. Якщо вони блокуються, гра може бути недоступною навіть із запущеним серверним процесом. Тестуйте весь ланцюг дій клієнта, а не тільки вебвідповідь.
Потужність не дорівнює гарантії послуги
Сукупна потужність вищої мережі не є швидкістю одного порту чи гарантією для кожної атаки. Відокремте мережеву фільтрацію, власну пропускну здатність та договірні межі. З’ясуйте наслідки перевищення або помилкової класифікації. Одна цифра терабітів не підтверджує гарантованої доступності, затримки чи захисту від усіх прикладних атак; потрібні конкретні умови.
Обмежте origin і адміністрування
Коли архітектура потребує обмеження, дозволяйте лише погоджені шляхи входу. Використовуйте підтверджені мережі джерела, а не весь інтернет. Адміністрування, бази даних та запасні порти перевіряйте окремо. Змінюйте правила поступово й зберігайте незалежне керування та повернення. Неправильний брандмауер може блокувати клієнтів так само ефективно, як сама атака.
Дослідіть також ресурси
Навантаження CPU, брак пам’яті, помилка скрипту або повільний диск можуть нагадувати мережевий збій. До висновків порівняйте час, журнали, ресурси та дані трафіку. Користуйтеся малими дозволеними функціональними тестами й подіями оператора. Після виправлення перевіряйте справжні з’єднання гравців та всі включені служби; одна доступна сторінка не є достатнім результатом.
Що робити у вашій ситуації?
| Ситуація | Наступний крок |
|---|---|
| Гра використовує UDP | Попросіть документований обсяг UDP-захисту й перевірте справжній клієнт. |
| Вебетап потребує фільтрації | Перевірте HTTP-адреси, origin та роботу дозволених запитів. |
| Послуга зупиняється без мережевих доказів | Порівняйте журнали й навантаження перед висновком про DDoS. |
Офіційні джерела
Джерела описують протоколи й налаштування. Перевірте документацію саме вашої версії.