Dopuść tylko adresy IP Cloudflare: nginx, Apache i IIS

Proxy Cloudflare ukrywa adres IP twojego serwera i chroni go przed atakami DDoS, ale tylko wtedy, gdy ruch faktycznie przechodzi przez Cloudflare. [1] Każdy, kto pozna prawdziwy adres IP, może połączyć się bezpośrednio z serwerem i ominąć całą tę ochronę. Ten poradnik pokazuje, jak na portach 80 i 443 dopuścić tylko adresy IP Cloudflare – za pomocą UFW i nginx lub Apache w Ubuntu 24.04 oraz za pomocą Windows Defender Firewall i IIS w Windows Server 2022 lub 2025 – i jak na bieżąco aktualizować listę adresów Cloudflare.

Dlaczego każdy, kto zna IP serwera, może ominąć Cloudflare

Żądania wysłane bezpośrednio na adres IP serwera nie przechodzą przez Cloudflare, więc nie obejmuje ich żadna ochrona Cloudflare. Rekord DNS z włączonym proxy ukrywa adres IP serwera źródłowego (origin), a Cloudflare prosi, by ten serwer przepuszczał ruch z adresów IP Cloudflare – inaczej nie dotrą do niego żądania przesyłane przez Cloudflare. [1] Na poziomie sieci zalecenia Cloudflare idą jeszcze dalej: jawnie zablokuj cały ruch, który nie pochodzi z Cloudflare ani od zaufanych partnerów. [1]

Tylko porty TCP 80 i 443 ogranicz do adresów Cloudflare. Dostęp do SSH w Linuksie i do pulpitu zdalnego w Windows zostaw tylko dla swojego adresu IP lub sieci VPN – oba sposoby opisują nasza lista kontrolna zabezpieczeń SSH i poradnik o prywatnej sieci WireGuard.

Cloudflare ocenia listę dozwolonych adresów IP jako umiarkowanie bezpieczną, a Authenticated Origin Pulls i Cloudflare Tunnel – jako bardzo bezpieczne. [1] Dlatego ten poradnik łączy kilka warstw kontroli:

Zapora działająca na samym serwerze nie zatrzyma zalewu ruchu na tyle dużego, by zapchać łącze serwera. Plany StealthRDP w UE obejmują ochronę przed atakami DDoS na poziomie sieci, a plany w USA – nie. Ten aspekt omawia nasza lista kontrolna ochrony VPS przed atakami DDoS.

Gdzie znaleźć zakresy adresów IP Cloudflare

Cloudflare uznaje stronę IP Ranges pod adresem www.cloudflare.com/ips za miarodajną listę swoich zakresów. Prowadzą z niej odnośniki do wersji w zwykłym tekście pod adresami www.cloudflare.com/ips-v4 i www.cloudflare.com/ips-v6, a ta sama lista jest dostępna w API Cloudflare. [2]

Ta lista naprawdę się zmienia. Historia zmian pokazuje, że w 2017 roku usunięto z niej zakres 199.27.128.0/21, w 2021 roku zakres 104.16.0.0/12 zastąpiono zakresami 104.16.0.0/13 i 104.24.0.0/14, a zakres 2405:b500::/32 usunięto w 2022 roku i przywrócono w 2023. [2] Jeśli pominiesz jakiś zakres, żądania Cloudflare z tego zakresu zostaną zablokowane [1], więc lista wklejona jednorazowo z czasem się zdezaktualizuje.

Jak dopuścić tylko adresy IP Cloudflare w UFW

Aby w UFW dopuścić tylko adresy IP Cloudflare, dodaj reguły, które otwierają porty 80 i 443 dla każdego zakresu Cloudflare, a potem usuń reguły, które otwierają te porty dla wszystkich. UFW to domyślne narzędzie do konfiguracji zapory w Ubuntu, które po instalacji jest wyłączone; potrafi otworzyć port dla pojedynczego hosta lub sieci, jak w poleceniu sudo ufw allow proto tcp from 192.168.0.2 to any port 22, i obsługuje zarówno IPv4, jak i IPv6. [3]

sudo ufw allow proto tcp from 198.51.100.7 to any port 22
sudo ufw enable
sudo ufw status verbose

#!/usr/bin/env bash
# Rebuild Cloudflare's IP ranges for UFW, nginx and Apache.
set -euo pipefail
export LC_ALL=C PATH=/usr/sbin:/usr/bin:/sbin:/bin

STATE=/etc/cloudflare-ips.txt
NEW=$(mktemp)
trap 'rm -f "$NEW"' EXIT

v4=$(curl -fsS --max-time 30 https://www.cloudflare.com/ips-v4)
v6=$(curl -fsS --max-time 30 https://www.cloudflare.com/ips-v6)
printf '%s\n%s\n' "$v4" "$v6" | grep -E '^[0-9a-fA-F:.]+/[0-9]+$' | sort -u > "$NEW"

# Stop before touching anything if a list is missing or cut short.
if ! grep -q '\.' "$NEW" || ! grep -q ':' "$NEW" || [ "$(wc -l < "$NEW")" -lt 10 ]; then
  echo "Cloudflare lists look wrong; nothing changed" >&2
  exit 1
fi

touch "$STATE"
# Add new ranges first, then remove the ones Cloudflare dropped.
comm -13 "$STATE" "$NEW" | while read -r net; do
  ufw allow proto tcp from "$net" to any port 80
  ufw allow proto tcp from "$net" to any port 443
done
comm -23 "$STATE" "$NEW" | while read -r net; do
  ufw delete allow proto tcp from "$net" to any port 80 || true
  ufw delete allow proto tcp from "$net" to any port 443 || true
done
cp "$NEW" "$STATE"

if command -v nginx > /dev/null; then
  { sed 's/.*/set_real_ip_from &;/' "$NEW"; echo 'real_ip_header CF-Connecting-IP;'; } \
    > /etc/nginx/conf.d/cloudflare-realip.conf
  nginx -t && systemctl reload nginx
fi

if command -v apache2ctl > /dev/null; then
  cp "$NEW" /etc/apache2/cloudflare-ips.lst
  apache2ctl configtest && systemctl reload apache2
fi

sudo chmod 755 /usr/local/sbin/cloudflare-ips
sudo /usr/local/sbin/cloudflare-ips
echo '17 4 * * * root /usr/local/sbin/cloudflare-ips' | sudo tee /etc/cron.d/cloudflare-ips

sudo ufw status numbered
# For example, if you once ran "ufw allow 80" and "ufw allow 443":
sudo ufw delete allow 80
sudo ufw delete allow 443
sudo ufw status numbered

Porty publikowane przez Dockera omijają UFW

Docker przekierowuje ruch do opublikowanego portu w tablicy nat, zanim dotrze on do łańcucha INPUT, z którego korzysta UFW, więc reguły UFW są dla tego portu ignorowane. [4] Docker odradza też edytowanie swoich reguł, a wyłączenie obsługi iptables przez Dockera prawdopodobnie zepsuje sieć kontenerów. [4] Serwer WWW, który przyjmuje ruch od Cloudflare, uruchamiaj bezpośrednio na hoście albo filtruj ruch na zaporze stojącej przed serwerem.

nginx i Apache: przywróć IP odwiedzających i odrzucaj żądania na sam adres IP

Oba serwery WWW potrafią zastąpić adres Cloudflare adresem odwiedzającego, który Cloudflare przesyła w nagłówku CF-Connecting-IP. [5] Jest to potrzebne, bo przy działającej zaporze każde żądanie przychodzi z adresu Cloudflare. Ufaj temu nagłówkowi tylko wtedy, gdy pochodzi z zakresów Cloudflare; Cloudflare ostrzega, że w przeciwnym razie można go sfałszować. [5]

nginx

Zalecana przez Cloudflare konfiguracja nginx korzysta z modułu realip: po jednym wierszu set_real_ip_from na każdy zakres Cloudflare oraz real_ip_header CF-Connecting-IP, przy czym zakresy trzeba utrzymywać w aktualnym stanie. [5] Skrypt aktualizujący zapisuje taki plik:

set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
# ...one line for every Cloudflare range...
set_real_ip_from 2c0f:f248::/32;
real_ip_header CF-Connecting-IP;

Następnie odrzucaj żądania dotyczące nazw, których nie obsługujesz na tym serwerze, na przykład żądania wysłane na sam adres IP: Cloudflare zaleca akceptowanie tylko tych wartości nagłówka Host, których się spodziewasz. [1] W nginx zajmuje się tym serwer domyślny. deny all odrzuca każde żądanie, które do niego trafi [6], a ssl_reject_handshake on odrzuca uzgadnianie połączenia TLS (handshake) w jego bloku server; w przykładzie z dokumentacji nginx ta dyrektywa występuje razem z default_server, więc uzgadnianie TLS dla każdej innej nazwy kończy się niepowodzeniem. Dyrektywa wymaga nginx w wersji 1.19.4 lub nowszej. [7]

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    deny all;
}

server {
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    ssl_reject_handshake on;
}

Usuń default_server ze wszystkich innych bloków server na tych portach, włącz ten plik i przeładuj nginx.

Listę Cloudflare można też trzymać w nginx jako wiersze allow zakończone regułą deny all, bo reguły są sprawdzane po kolei do pierwszego dopasowania. [6] Stosuj to tylko na serwerze, który nie przywraca adresów IP odwiedzających; adres odwiedzającego zapisuj tam w logu ze zmiennej $http_cf_connecting_ip. [5] Przywrócony adres należy do odwiedzającego, więc lista dozwolonych adresów zawierająca tylko zakresy Cloudflare odrzucałaby prawdziwych odwiedzających – dokumentacja Apache wyjaśnia to wprost w odniesieniu do własnego modułu. [8]

Apache 2.4

Instrukcja Cloudflare dla Apache opiera się na module mod_remoteip: włącz moduł, ustaw RemoteIPHeader CF-Connecting-IP, wpisz zakresy Cloudflare jako zaufane serwery proxy w pliku /etc/apache2/conf-available/remoteip.conf, włącz ten plik i w pliku /etc/apache2/apache2.conf zmień %h na %a w dyrektywie LogFormat formatu combined. [5] RemoteIPTrustedProxyList wczytuje zakresy z pliku przy starcie serwera, co dobrze współgra ze skryptem. [8]

RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxyList /etc/apache2/cloudflare-ips.lst

sudo a2enmod remoteip
sudo a2enconf remoteip
sudo apache2ctl configtest
sudo systemctl restart apache2

Ważne są dwa szczegóły. Bez listy zaufanych serwerów proxy mod_remoteip ufa temu nagłówkowi od dowolnego hosta, więc każdy mógłby sfałszować swój adres. [8] Poza tym po podmianie adresu Require ip i pole %a w logu widzą adres odwiedzającego, a %{c}a i CONN_REMOTE_ADDR zachowują adres Cloudflare, z którego nawiązano połączenie. [8] Dlatego zakresy Cloudflare trzymaj na liście zaufanych serwerów proxy i w zaporze, a Require ip używaj tylko w regułach dotyczących odwiedzających, na przykład dla strony administracyjnej dostępnej tylko z twojego adresu IP.

IIS w Windows Server: porty 80 i 443 tylko dla Cloudflare

Na VPS Windows z Windows Server 2022 lub 2025 to samo zadanie wykona Windows Defender Firewall skonfigurowany z poziomu PowerShell. New-NetFirewallRule przyjmuje w parametrze -RemoteAddress podsieci IPv4 i IPv6 w notacji CIDR, więc jedna reguła może objąć wszystkie zakresy, a Set-NetFirewallRule zmienia istniejącą regułę. [9]

$ErrorActionPreference = 'Stop'
$ranges = foreach ($list in 'ips-v4', 'ips-v6') {
    (Invoke-RestMethod "https://www.cloudflare.com/$list") -split "`n" |
        ForEach-Object { $_.Trim() } | Where-Object { $_ -match '^[0-9a-fA-F:.]+/\d+$' }
}
$v6 = @($ranges | Where-Object { $_ -match ':' })
if ($ranges.Count -lt 10 -or $v6.Count -eq 0 -or $v6.Count -eq $ranges.Count) {
    throw 'Cloudflare lists look wrong; nothing changed'
}

$name = 'Cloudflare HTTP and HTTPS'
if (Get-NetFirewallRule -DisplayName $name -ErrorAction SilentlyContinue) {
    Set-NetFirewallRule -DisplayName $name -RemoteAddress $ranges
} else {
    New-NetFirewallRule -DisplayName $name -Direction Inbound -Protocol TCP `
        -LocalPort 80,443 -RemoteAddress $ranges -Action Allow
}

Reguła zezwalająca przepuszcza każdy pakiet, który do niej pasuje [9], więc każda inna włączona reguła, która zezwala na ruch na porty 80 lub 443 z dowolnego adresu, nadal otwiera je dla wszystkich. Wyświetl te reguły, sprawdź każdą z nich i wyłącz te, które nie są twoje:

Get-NetFirewallRule -Direction Inbound -Action Allow -Enabled True |
    Where-Object { $_.DisplayName -ne 'Cloudflare HTTP and HTTPS' -and
        (($_ | Get-NetFirewallPortFilter).LocalPort -match '^(80|443)$') } |
    Select-Object Name, DisplayName
# After checking a rule: Set-NetFirewallRule -Name '<Name>' -Enabled False

Dla IIS od wersji 8.5 do 10 Cloudflare zaleca zapisywanie w logu prawdziwego adresu odwiedzającego przez dodanie CF-Connecting-IP jako pola niestandardowego: w IIS Manager otwórz Logging dla witryny, wybierz format W3C, kliknij Select Fields i dodaj nagłówek. [5] Zmienia to tylko log; twoja aplikacja nadal widzi adres Cloudflare. [5]

Authenticated Origin Pulls: najsilniejsze zabezpieczenie serwera źródłowego

Authenticated Origin Pulls (AOP) dodaje wzajemne uwierzytelnianie TLS (mutual TLS): Cloudflare przedstawia certyfikat klienta, gdy łączy się z twoim serwerem źródłowym, a serwer WWW go weryfikuje. Wymaga to trybu szyfrowania SSL/TLS Full lub wyższego. [10] Konfiguracja globalna korzysta z certyfikatu Cloudflare wspólnego dla wszystkich kont Cloudflare, więc potwierdza tylko, że żądanie przyszło z sieci Cloudflare; jeśli chcesz weryfikacji powiązanej z twoim kontem, prześlij własny certyfikat i użyj AOP na poziomie strefy (zone-level) lub dla poszczególnych nazw hostów (per-hostname). [10]

Pobierz z instrukcji konfiguracji certyfikat origin pull Cloudflare (.PEM) i skopiuj go na serwer; to nie jest certyfikat Cloudflare Origin CA. [10] Skonfiguruj serwer WWW tak, by korzystał z tego certyfikatu, ale na razie niczego nie wymuszaj; w nginx oznacza to ustawienie ssl_verify_client optional, przy którym serwer prosi o certyfikat klienta i weryfikuje go, jeśli klient go prześle. [7] Następnie włącz AOP w Cloudflare: strona Origin Server, karta Authenticated Origin Pulls, sekcja Global. [10]

Jeśli strona nadal działa, wymuś weryfikację: w nginx za pomocą ssl_verify_client on, w Apache – SSLVerifyClient require. [10]

ssl_client_certificate /etc/nginx/certs/cloudflare.crt;
ssl_verify_client optional;   # change to "on" to enforce

SSLCACertificateFile /etc/apache2/certs/origin-pull-ca.pem
# add this line to enforce:
SSLVerifyClient require

Cloudflare Tunnel: bez żadnych otwartych portów WWW

Cloudflare Tunnel zamyka porty WWW zamiast je filtrować. Demon cloudflared na twoim serwerze nawiązuje z Cloudflare wyłącznie połączenia wychodzące, więc strona nie potrzebuje publicznie routowalnego adresu IP. [1] Gdy tunel działa, porty 80 i 443 mogą pozostać zamknięte. Cloudflare ocenia Tunnel jako bardzo bezpieczne rozwiązanie i udostępnia je wszystkim klientom; ceną jest jedna usługa więcej do utrzymania. [1]

Jak wycieka adres IP serwera źródłowego i jak sprawdzić blokadę

Adres IP serwera źródłowego zwykle wycieka przez rekordy DNS bez proxy (DNS-only), pocztę na tym samym serwerze albo historię DNS – wyjaśnia to poradnik Cloudflare o ochronie serwera źródłowego. [1]

• Rekordy DNS bez proxy (DNS-only) zawierające adres IP serwera źródłowego, w tym rekordy SPF i TXT.
• Poczta na tym samym serwerze: wiadomość wysłana na nieistniejący adres wraca do nadawcy i ujawnia adres IP serwera pocztowego.
• Historia DNS: stare rekordy są przechowywane i pokazują adres IP sprzed przejścia na Cloudflare.

Cloudflare radzi zmienić adres IP serwera źródłowego, gdy strona działa już za Cloudflare. [1] Zrób to dopiero po zablokowaniu bezpośredniego dostępu, aby nowy adres nigdy nie był publicznie znany. Każdy serwer StealthRDP, zarówno VPS Linux, jak i Windows, ma dedykowany adres IPv4, a każda zmiana adresu IP kosztuje 5 €; zlecasz ją przez zespół wsparcia.

Następnie przetestuj blokadę ze swojego komputera, któremu zapora nie pozwala łączyć się z portami 80 i 443:

# Straight to the origin IP: both should hang, then fail
curl http://203.0.113.10/
curl https://203.0.113.10/

# Through Cloudflare: should return your page
curl https://www.example.com/

Pożądany wynik to przekroczenie limitu czasu (timeout). Strona z błędem 403 albo jakikolwiek błąd TLS lub certyfikatu oznacza, że żądanie dotarło do serwera WWW, czyli zapora nadal jest otwarta.

Gdy AOP jest już wymuszone, żądanie, które nie przechodzi przez Cloudflare, powinno też zostać odrzucone przy weryfikacji certyfikatu. [10] Takie żądanie wysłane z twojego komputera zatrzyma zapora, zanim dotrze ono tak daleko, więc ten test przeprowadź na samym serwerze:

curl -k --resolve www.example.com:443:127.0.0.1 https://www.example.com/

Serwer nginx powinien odpowiedzieć błędem 400, bo nie przesłano certyfikatu klienta, a Apache powinien odrzucić uzgadnianie TLS. Jeśli potem odwiedzający zobaczą strony błędów Cloudflare, sprawdź, czy dodano wszystkie zakresy; inne błędy serwera źródłowego za Cloudflare omawia nasz poradnik o błędzie 502 Bad Gateway.

Częste pytania

Gdzie znaleźć zakresy adresów IP Cloudflare?

Cloudflare publikuje je pod adresem www.cloudflare.com/ips, a listy w zwykłym tekście – pod adresami www.cloudflare.com/ips-v4 i www.cloudflare.com/ips-v6; te same dane są dostępne w API Cloudflare. Lista co jakiś czas się zmienia, więc aktualizuj swoją kopię automatycznie. [2]

Czy ktoś może ominąć Cloudflare, znając adres IP mojego serwera?

Tak, jeśli serwer przyjmuje ruch WWW od każdego. Adres IP mogą ujawnić rekordy DNS bez proxy (DNS-only), wiadomości zwrotne o niedoręczeniu poczty i stare rekordy DNS, dlatego Cloudflare zaleca blokowanie ruchu, który nie pochodzi z adresów Cloudflare. [1]

Jak zobaczyć prawdziwy adres IP odwiedzającego za Cloudflare?

Cloudflare przesyła go w nagłówku CF-Connecting-IP. Moduł realip w nginx i mod_remoteip w Apache mogą z niego korzystać, o ile ufasz temu nagłówkowi tylko wtedy, gdy pochodzi z zakresów Cloudflare. [5]

Czy UFW blokuje porty Dockera?

Nie w przypadku portów publikowanych przez kontener. Docker przekierowuje ten ruch w tablicy nat, zanim dotrze on do łańcuchów, z których korzysta UFW, więc reguły UFW są dla tych portów ignorowane. [4]

Czy Cloudflare Tunnel wymaga otwartych portów?

Nie, nie musisz otwierać żadnych portów WWW dla ruchu przychodzącego. Demon cloudflared nawiązuje z Cloudflare wyłącznie połączenia wychodzące, więc serwer nie potrzebuje dla strony publicznie routowalnego adresu IP. [1]