Przejdź do treści głównej

Incydent produkcyjny · Diagnoza i usunięcie problemu

Incydent DDoS spowodowany odsłoniętym originem

Incydent produkcyjny, w którym można było ominąć warstwę ochronną

Produkcyjna usługa klienta była celem ataku DDoS. Stała za Cloudflare, ale serwer źródłowy nadal przyjmował bezpośrednie połączenia z internetu.

Problem

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 firewalla, więc UFW ich nie filtrował i każdy, kto znalazł IP originu, mógł całkiem pominąć Cloudflare.

Rezultat

Po zamknięciu originu ruch znowu szedł przez Cloudflare i reguły na edge mogły wreszcie zadziałać. Legalni użytkownicy odzyskali stabilny dostęp. Nie mam liczb dotyczących ataku ani ruchu z tego incydentu, więc ich tu nie podaję.

Decyzje i implementacja

  • Najpierw zaostrzyłem WAF i rate limiting w Cloudflare. Ruch docierający do aplikacji nie spadł, a Cloudflare nie pokazywał obciążenia, którym były zalane logi kontenera. Ta rozbieżność wskazywała na ruch, który w ogóle nie przechodził przez Cloudflare.
  • Sprawdziłem origin w Censys i Shodanie, które potwierdziły, że jest wystawiony do internetu. Porównałem też dane z Cloudflare z logami originu.
  • Zmieniłem i odizolowałem adres IP originu oraz ograniczyłem drogi, którymi można było dotrzeć do serwera.
  • Po zamknięciu bezpośredniej drogi dostroiłem WAF i rate limiting, starając się przy tym nie blokować zwykłych użytkowników. 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.

Wykorzystane technologie

  • Cloudflare
  • WAF
  • Rate limiting
  • Docker
  • Linux
  • Izolacja originu
  • Application caching
  • Analiza logów

Notatki z tego projektu

Notatki techniczne powiązane z tym projektem: