Firewall чи WAF: що бачить і зупиняє кожен з них

Що вирішує stateful firewall

Firewall рівнів 3/4 відстежує з'єднання і судить кожне нове за його адресами, портом і станом потоку, до якого воно належить. Cisco Firepower, OPNsense і netfilter усі роблять це добре: порт, якого не відкриває жодне правило, закритий, відповідь дозволена лише для з'єднання, яке почала внутрішня сторона, а порти керування відповідають лише діапазонам зі списку дозволених. Його погляд зупиняється на транспортному рівні. З TLS на шляху він узагалі не бачить усередину корисного навантаження, якщо не термінує сесію, і навіть у відкритому вигляді не має поняття про URL, заголовок, статус відповіді чи вхід.

Що додає WAF

Web application firewall читає HTTP-транзакцію після термінації TLS, що на практиці означає, що він живе в reverse proxy або поруч із ним. Він додає три види контролю, які firewall не може виразити. Сигнатурні правила, як ModSecurity з OWASP Core Rule Set, зіставляють ін'єкції, обхід каталогів і відомі експлойти в запиті. Поведінкові правила рахують на клієнта і на шлях: запити за хвилину на маршруті входу, відповіді про невдалий вхід на адресу, ознаки бота в заголовках і таймінгах. Позитивні правила визначають, що приймає шлях, наприклад які методи, які типи вмісту і який розмір тіла, і відхиляють решту.

WAF не є заміною firewall. Він бачить лише той трафік, що до нього доходить, і нічого не знає про SSH, порти баз даних чи площину керування.

Де стає видимим зловживання входом

Невдалий вхід є фактом у відповіді. Застосунок відповідає на POST на шлях входу статусом або перенаправленням, яке відрізняє невдачу від успіху, і проксі записує це у свій журнал доступу при кожній спробі. Підрахунок невдач на клієнта за хвилину є одним рядком awk над цим журналом, і це сигнал, який пакетний фільтр не має як побачити.

Контроль має бути прив'язаний до клієнта, а не до облікового запису. Блокування облікового запису саме по собі зупиняє спроби проти одного імені користувача і замикає його власника, тоді як бот переходить до наступного імені у своєму списку. Обмеження частоти на клієнта на маршруті входу робить те, чого блокування не може:

# nginx: at most 5 login attempts a minute per client, small burst allowed
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

location = /login {
    limit_req zone=login burst=5 nodelay;
    proxy_pass http://app;
}

HAProxy виражає ту саму ідею через stick table з ключем за адресою джерела, а набір правил WAF може рахувати код відповіді про невдалий вхід безпосередньо.

Як ці два поєднуються

Порядок такий: firewall, потім термінація TLS і проксі з його правилами WAF, потім застосунок. Виявлення належить рівню 7, бо саме там докази. Примус може бути на будь-якому рівні. Проксі може відповісти клієнту-порушнику кодом 429 або 403 на його наступний запит, чого достатньо для більшості зловживань. Для клієнта, який не вгамовується, проксі може відправити адресу в динамічну таблицю пакетного фільтра на визначений період, що також скидає інші з'єднання цього клієнта і не коштує firewall нічого на пакет.

Два проєктні рішення передують зведенню цього зворотного зв'язку. Діапазони керування й моніторингу оператора потрапляють у список дозволених першими, щоб тест чи помилка не могли замкнути людей, які керують платформою. І спільні адреси реальні: офісний NAT або carrier-grade NAT ставить багатьох людей за однією адресою, тож блокування мають короткий термін дії і задокументований спосіб їх зняти. Увесь ланцюжок потім тестується з хоста поза мережею, так, як його зустрів би зловмисник, перш ніж хтось на нього покладеться.

Чого не бачить жоден з них

Правильний пароль. Credential stuffing із витеклим, дійсним паролем виглядає як успішний вхід для кожного рівня. Цю прогалину закриває багатофакторна автентифікація на обліковому записі та список дозволених для адміністративних шляхів на firewall, щоб дійсні облікові дані були марними з адреси, яка не є вашою.