Własny serwer za Cloudflare — jak nie zostawić otwartych drzwi

Postawienie Cloudflare przed własnym serwerem ma sensowny cel: adres maszyny przestaje być widoczny w DNS-ie, a ruch przechodzi przez warstwę, która filtruje i ogranicza tempo żądań.

Problem polega na tym, że Cloudflare ukrywa adres, ale go nie chroni. Jeżeli zapora serwera przyjmuje połączenia na porty 80 i 443 od kogokolwiek, to każdy, kto pozna adres, wchodzi bezpośrednio — z pominięciem filtrowania, ograniczania tempa i wszystkiego innego, za co ta warstwa odpowiada.

Cała ochrona sprowadza się wtedy do tego, że adres jest trudny do znalezienia. A nie jest.

Cztery drogi, którymi adres wycieka

1. Historia DNS

Domena istniała, zanim trafiła za Cloudflare. Wpisy z tamtego okresu są zarchiwizowane w publicznych serwisach śledzących zmiany w DNS-ie. Jeżeli serwer stoi pod tym samym adresem co dwa lata temu, adres jest publiczny — tyle że nie w bieżącym rekordzie.

To najczęstsza droga i zarazem jedyna, której nie da się cofnąć. Można tylko zmienić adres serwera.

2. Certificate Transparency

Każdy certyfikat wystawiony publicznie trafia do jawnych rejestrów. Jeżeli kiedykolwiek wystawiłeś certyfikat bezpośrednio na origin — na przykład na origin.twojafirma.pl albo na sam adres — nazwa jest do wyszukania w kilka sekund. Rejestry są przeszukiwalne przez każdego.

3. Poczta wychodząca z tego samego serwera

Nagłówek Received w wysłanej wiadomości niesie adres maszyny, która ją nadała. Wystarczy, że ktoś dostanie od Ciebie jednego maila.

To droga zaskakująco często pomijana, bo poczta i strona są traktowane jako osobne tematy — a stoją na tej samej maszynie.

4. Subdomeny wskazujące wprost na serwer

ftp., mail., cpanel., test., stary. — subdomeny, które nie przechodzą przez Cloudflare, bo ktoś je pominął albo dodał później. Automat przechodzący po typowych nazwach znajduje je w minutę.

Jak to domknąć

Jedna zmiana załatwia sprawę: wpuść na porty 80 i 443 wyłącznie zakresy adresów Cloudflare, resztę odrzuć.

Aktualną listę zakresów Cloudflare publikuje pod cloudflare.com/ips. Zakresy zmieniają się rzadko, ale się zmieniają — warto to sprawdzać przy okazji przeglądów, bo nieaktualna lista oznacza odcięcie części ruchu.

Do tego trzy rzeczy, które warto zrobić przy okazji:

• Tryb SSL ustawiony na Full (strict). Przy trybie Flexible połączenie między Cloudflare a serwerem idzie po HTTP. Reguła wymuszająca HTTPS po stronie serwera widzi wtedy ruch jako nieszyfrowany i przekierowuje w kółko — objawem jest błąd o zbyt wielu przekierowaniach.
• Certyfikat origin zamiast publicznego. Cloudflare wystawia certyfikaty ważne tylko dla połączeń od siebie. Nie trafiają do publicznych rejestrów, więc zamykają drogę numer dwa.
• Poczta z innego adresu niż strona. Jeżeli to możliwe, wysyłkę przenieś na osobną usługę — zamyka to drogę numer trzy i zwykle poprawia dostarczalność.

Jak sprawdzić, czy jest domknięte

Symulacja połączenia bezpośredniego, z pominięciem DNS-u:

curl -sI --resolve twojafirma.pl:443:ADRES_SERWERA https://twojafirma.pl/

Jeżeli dostajesz odpowiedź ze strony — warstwa jest do obejścia. Po poprawnym domknięciu zapory połączenie powinno wygasnąć bez odpowiedzi.

Warto też pamiętać o rzeczy myląco oczywistej: zwykłe curl -sI na domenie pokazuje nagłówki wychodzące z Cloudflare, a nie te ustawione na serwerze. Sprawdzając konfigurację serwera, trzeba odpytać go bezpośrednio.

Kiedy to w ogóle ma znaczenie

Jeżeli za Cloudflare stoi wyłącznie statyczna strona, obejście warstwy niewiele daje — nie ma czego atakować. Sprawa robi się poważna, gdy na tej samej maszynie działa cokolwiek dynamicznego: panel, aplikacja, API, poczta.

I to jest właściwy sposób oceny: poziom ryzyka wyznacza nie strona, tylko to, co jeszcze pracuje pod tym samym adresem.