Opublikowano · Zaktualizowano
Cloudflare nie chroni originu dostępnego bezpośrednio
Usługa stała za Cloudflare, ale origin przyjmował bezpośrednie połączenia, a jego IP dało się znaleźć. W czasie ataku DDoS ruch mógł więc ominąć Cloudflare, a reguły WAF i rate limiting, które stroiłem na edge, w ogóle tych requestów nie widziały.
- Cloudflare
- DDoS
- izolacja originu
- WAF
- rate limiting
- incident response
Dlaczego zaostrzanie WAF nie pomagało
Najpierw zaostrzyłem WAF i rate limiting w Cloudflare. Do aplikacji nadal docierało tyle samo ruchu, a Cloudflare nie pokazywał niczego, co odpowiadałoby obciążeniu, którym były zalane logi kontenera.
Właśnie ta rozbieżność między Cloudflare a logami originu była wskazówką, że ruch w ogóle nie przechodzi przez Cloudflare. Censys i Shodan potwierdziły, że origin jest wystawiony do internetu.
Skąd origin był dostępny i co zmieniłem
Aplikacja działała w kontenerze Dockera z opublikowanymi portami i bez reverse proxy przed nim. Docker dopisuje dla opublikowanych portów własne reguły iptables, więc UFW na hoście tego ruchu nie filtrował, mimo że był włączony. Kto znał IP originu, mógł łączyć się z aplikacją bezpośrednio.
Zmieniłem i odizolowałem adres IP originu oraz ograniczyłem drogi, którymi można było dotrzeć do serwera. Dopiero wtedy strojenie WAF i rate limitingu miało sens. Atak nie miał stałego wzorca: zmieniały się kraje, dostawcy, user agenty i ścieżki, a ruch szedł po HTTP/2 i mocno obciążał TLS. Korzystałem też ze społecznościowego zestawu reguł Cloudflare-WAF-Expressions, który utrzymuje Sefinek.
W aplikacji dodałem cache zapytań do bazy, widoków i routingu, żeby każdy request kosztował mniej pracy. To odciążało serwer, ale samo w sobie nie zamykało drogi obok Cloudflare.
- Sprawdź, jak można znaleźć origin: historia DNS, stare rekordy, inne usługi na tym samym IP i skanery w rodzaju Censys czy Shodan.
- Jeśli Docker publikuje porty, sprawdź, czy firewall na hoście naprawdę je filtruje.
- Wpuszczaj ruch do originu tylko tymi drogami, których wymaga konfiguracja proxy.
- WAF i rate limiting strój po zamknięciu bezpośredniego dostępu, nie przed.
- Cache zmniejsza obciążenie, ale nie zastępuje zamknięcia originu.
Co sprawdzam przy kolejnych wdrożeniach
Kiedy usługa stoi za reverse proxy albo CDN-em, najpierw sprawdzam, czy origin przyjmuje ruch poza tą ścieżką. Robię to, zanim ruszę reguły na edge, bo te reguły nie działają dla requestu wysłanego prosto do serwera.