Към съдържанието
AS213382 / PEERYX NETWORKПод атака ли сте?Свържете се с мрежовия екип
PEERYXNETWORK
Обсъдете тази архитектура

Изисквания за внедряване

DDoS защита за корпоративни и SaaS мрежи

Публичната услуга изисква достъпен мрежов път и приложение, способно да обработва легитимна работа. Определете контролираните адреси и маршрутизация преди избор на доставка на защитен трафик.

Обсъдете тази архитектура Сравнете вариантите за внедряване
Работно място за разработка с монитори, клавиатура и компютър.
Илюстративна снимка · Anete Lusina / Pexels

Определете кой ресурс става недостъпен

Мрежово насищане и скъпи заявки са различни проблеми
Запълнена връзка може да блокира достъпа преди приложението. Тежка удостоверена заявка може да изчерпи backend ресурси без насищане на връзката. Една графика за трафик не диагностицира и двата случая.
Изходният сървър може да е зад няколко слоя
CDN, приложно прокси, защитна стена и сървър могат да виждат различен трафик. Опишете публичното име, изложените адреси и обратния път, включително точки извън основния сайт, преди промяна на защитата.
Адресът може да принадлежи на друг доставчик
Хостинг или облачни адреси не се пренасят автоматично през нова BGP услуга. Проверете собствеността и ограниченията за маршрутизация или тунели; проектът трябва да съответства на разрешеното от всеки оператор.

Нека мрежовата защита допълва приложните контроли

Защитен Transit IP или съвместимо локално филтриране могат да покрият мрежовия слой. HTTP разрешенията, бюджетите за заявки и специфичните контроли остават в подходящ приложен или защитен компонент; не се подразбира универсална WAF услуга.

  1. Опишете публичните услуги

    Определете крайни точки, хостинг отговорности, нужни протоколи и приложното действие, което трябва да остане достъпно.

  2. Проверете защитения мрежов път

    Прегледайте вариантите за доставка, разрешената маршрутизация, MTU и видимостта, нужна на избрания филтриращ режим.

  3. Запазете приложните мерки

    Съгласувайте достъпа до изходния сървър, удостоверяването, ограниченията на заявки и наблюдението на backend с приложението.

Примерна последователност. Офертата и приемателният протокол определят предоставената услуга.

Изберете границата, която екипът може да управлява

Можете ли да променяте маршрутизацията или само приложната крайна точка?
Отговорът определя дали да се разглеждат транзит, съвместим тунел или друг слой за доставка. Потвърдете ограниченията на доставчика преди избор на архитектура.
Какво означава достъпност за тази услуга?
Използвайте успешно бизнес действие, не само отворен порт. Запишете очакван отговор, време за изчакване и поведение на зависимостите, за да сравняват екипите един и същ инцидент.
Кой разследва, когато мрежата остава достъпна?
Осигурете приложни грешки, използване на ресурси и мрежови броячи за общ интервал. Здрав маршрут не доказва работещо удостоверяване, база данни или външна зависимост.

Проверете цялото потребителско действие

  • Запишете нормалния успех на приложението и зависимостите преди промяна на пътя за доставка.
  • Проверете нужните протоколи, двете посоки и представителни по-големи обмени през предложения мрежов слой.
  • Уточнете връщане назад и отговорност при инцидент между хостинг, мрежови и приложни екипи; запазете съществуващите приложни контроли.

Въпроси за това внедряване

Мрежовата DDoS защита заменя ли WAF или приложните разрешения?

Не. Мрежовата доставка и поддържаното филтриране на пакети не заменят решенията за достъп според приложението. Оценявайте тези слоеве отделно.

Трябва ли приложението да се премести на нов сървър?

Зависи от съвместимия път за доставка и ограниченията на текущия доставчик. Проверете маршрутизацията и достъпността на изходния сървър преди ангажимент за миграция.

Технически източник : OWASP: защита от отказ на услуга в системните слоеве