Table of Contents
Wprowadzenie
W poniższym wpisie omówimy kolejny krok pozwalający na poprawienie bezpieczeństwa naszego serwera w sieci. Jest to drugi artykuł z serii trzech opisujących poprawną konfigurację wykorzystującą usługę Cloudflare. Jeśli nie miałeś okazji, zapoznaj się proszę z pierwszą częścią naszej serii dostępnej pod tym linkiem, ponieważ niniejszy artykuł jest jego kontynuacją i konfiguracja w nim przedstawiona jest wymagana do przeprowadzenia dalszych prac.
Opisane w artykule sugestie dotyczące poprawienia konfiguracji komunikacji, które są częstymi zaleceniami wydawanymi przez nas, podczas przeprowadzanych prac audytowych. Klienci często zgłaszają problemy, że pomimo wykorzystania serwisu Cloudflare jako proxy aplikacja jest atakowana, np za pomocą ataków typu DoS lub DDoS. Bardzo często również zapomniany jest krok, dzięki któremu w przypadku wystąpienia incydentów bezpieczeństwa, będziemy mogli poznać adres IP atakującego. Zanim jednak przystąpimy do poprawiania konfiguracji warto wspomnieć jakie opcje komunikacji end to end oferuje Cloudflare. Na rysunku nr 1 przedstawione są wszystkie możliwe do ustawienia metody komunikacji połączeń.
Rysunek 1. Metody komunikacji z naszym serwerem oferowane przez Cloudflare.
Serwis Cloudflare oferuje użytkownikowi cztery metody komunikacji z serwerem mianowicie:
- Off (not secure) – Żaden odwiedzający nie będzie mógł przeglądać naszej witryny przez HTTPS; wszyscy zostaną przekierowani na HTTP.
- Flexible – Wykorzystywany w przypadku, kiedy nie możemy skonfigurować HTTPS na naszym serwerze, nawet z certyfikatem, który nie jest poprawny (np. podpisany samodzielnie). Odwiedzający będą mogli uzyskać dostęp do naszej witryny przez HTTPS, ale połączenia z serwerem będą nawiązywane przez HTTP. Uwaga: w przypadku wyboru tej metody możemy napotkać pętlę przekierowań. Np. jeśli docelowo nasz serwer www ruch HTTP będzie przekierowywał na HTTPS.
- Full – Wykorzystywany, kiedy nasz serwer obsługuje HTTPS, ale zainstalowany na nim certyfikat nie jest zgodny z domeną lub jest podpisany samodzielnie. Cloudflare połączy się z serwerem za pomocą protokołu HTTPS, ale nie będzie weryfikować certyfikatu.
- Full (strict) – Wykorzystywany, kiedy na serwerze jest zainstalowany ważny certyfikat (nie wygasł i podpisany jest przez zaufane Certificate Authority lub Cloudflare Origin CA). Cloudflare połączy się z serwerem za pomocą protokołu HTTPS i zweryfikuje certyfikat przy każdym żądaniu.
W dalszej części artykułu skupimy się na konfiguracji komunikacji za pomocą metody Full (strict) z wykorzystaniem Cloudflare Origin CA dla serwera NGINX oraz Apache.
Wymagania wstępne
Aby móc poprawnie skonfigurować usługę Cloudflare dla swojego serwera, będziesz potrzebował:
- serwer z systemem operacyjnym Debian lub Ubuntu, w którym możesz wykonywać polecenia za pomocą sudo lub jako użytkownik root oraz masz otwarty port HTTPS(443),
- w pełni zarejestrowaną domenę,
- zarejestrowane konto w serwisie Cloudflare.
- wykonane kroki migracji name serwerów opisane w poprzednim artykule.
Na potrzeby niniejszego opisu wykorzystamy domenę dsecure.dev, która została kupiona za pomocą OVH oraz serwer uruchomiony w serwisie DigitalOcean z systemem operacyjnym Ubuntu 20.04 (LTS).
Konfiguracja
W tym miejscu zakładam że udało Ci się wykonać poprawnie migracje name serwerów opisaną w części pierwszej. Na początek pokaże w jaki sposób można próbować ominąć Cloudflare z wykorzystaniem rzeczywistego adresu IP serwera. Adres ten atakujący mogą uzyskać w różny sposób w tak zwanej fazie rekonesansu, np poprzez wykorzystanie historii rekordów DNS.
Weryfikacja możliwości ominięcia usługi Cloudflare
Kiedy otworzymy stronę w przeglądarce certyfikat, którym serwer nam się przedstawi będzie pochodził z Cloudflare (Rysunek 2). Analizując plik z logami np. dla serwera NGINX możemy zauważyć, że adres IP nie należy do nas lecz do Cloudflare (Rysunek 3). Prostą weryfikację adresów IP możemy przeprowadzić za pomocą serwisu whois (Rysunek 4).
Rysunek 2.Prawidłowe działanie naszej strony internetowej
Rysunek 3. Włączenie domyślnej minifikacji.
Rysunek 4. Informacje zawarte w bazie whois na temat wykrytego adresu IP.
Na pierwszy rzut wszystko wygląda prawidłowo, pomijając to że w obecnej konfiguracji w logach serwera zamiast adresów IP odwiedzających zapisują się adresy IP Cloudflare. Ale jeśli atakujący znajdzie rzeczywisty adres IP serwera będzie próbował ominąć Cloudflare i będzie próbował wykonywać zapytania bezpośrednio do naszego serwera. Jeśli nie mamy odpowiednio zabezpieczonej komunikacji end to end to może mu się to udać.
W pierwszym podejściu, jeżeli nasz serwer nie ma skonfigurowanych wirtualnych hostów lub nasza strona nie jest na serwerze współdzielonym to wprowadzenie adresu IP serwera w przeglądarce może już pozwolić na pominięcie Cloudflare (Rysunek 5). W tym przypadku w logach serwera wykryjemy rzeczywisty adres IP atakującego (Rysunek 6), lecz jeśli mamy kilkanaście tysięcy odwiedzających, znalezienie adresu IP niepochodzącego z Cloudflare może nam chwilę zająć.
Rysunek 5. Możliwość ominięcia Cloudflare za pomocą przeglądarki.
Rysunek 6. Zawartość pliku /var/log/nginx/access.log z adresem IP atakującego.
W przypadku kiedy mamy skonfigurowane wirtualne hosty lub serwer współdzielony, powyższa technika nie zadziała. Możemy sobie z tym poradzić np poprzez dodanie odpowiedniego wpis w pliku /etc/hosts na swoim komputerze:
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
134.122.49.73 dsecure.devEfekt działania powyższej zmiany w pliku /etc/hosts będzie taki sam jak w przypadku powyżej z tą różnicą, że zamiast odwoływać się do serwera za pomocą adresu IP odwołujemy się do niego po domenie (Rysunek 7). Dodatkowo na rysunku nr 7 widać, że konfiguracja HTTPS jest prawidłowa. Dzieje się tak dlatego, że w poprzednich krokach wykorzystałem ten serwer do skonfigurowania Let’s Encrypt.
Rysunek 7. Możliwość ominięcia Cloudflare za pomocą pliku /etc/hosts.
Oba powyższe przykłady są błędami w konfiguracji, które należy poprawić. Jeśli nie jesteś pewny czy dobrze skonfigurowałeś komunikację pomiędzy Cloudflare a swoim serwerem, zachęcam Cię do własnoręcznego przetestowania swojej konfiguracji. W dalszej części wpisu zajmiemy się poprawieniem obu wskazanych tutaj problemów.
Generowanie certyfikatów Cloudflare Origin CA
Cloudflare pozwala na wygenerowanie bezpłatnego certyfikatu TLS podpisanego przez Cloudflare CA do zainstalowania na naszym serwerze. Korzystając z tego certyfikatu możemy lepiej zabezpieczyć połączenie pomiędzy naszym serwerem a Cloudflare, dodatkowo unikniemy przypadków, w których poprzez wykorzystanie automatów takich jak Let’s Encrypt może wyciec rzeczywisty adres IP naszego serwera.
Aby wygenerować certyfikat z Cloudflare Origin CA, zaloguj się na swoje konto Cloudflare w przeglądarce internetowej. Wybierz domenę, którą chcesz zabezpieczyć (w naszym przypadku jest to dsecure.dev) i przejdź do sekcji SSL/TLS. Stamtąd przejdź do zakładki Origin Server i kliknij Create Certificate (Rysunek 8).
Rysunek 8. Tworzenie Cloudflare Origin certificate.
Po ukazaniu się konfiguracji tworzenia Cloudflare Origin certificate (Rysunek 9) pozostaw wszystkie opcje domyślne i kliknij Create.
Rysunek 9. Konfiguracja Cloudflare Origin certificate.
W kolejnym kroku zobaczysz okno dialogowe z certyfikatem oraz kluczem prywatnym (Rysunek 10). Certyfikat oraz klucz prywatny musisz przenieść na swój serwer. Ze względów bezpieczeństwa klucz prywatny wyświetlany jest tylko raz, więc upewnij się że skopiowałeś go poprawnie.
Rysunek 10. Wygenerowany certyfikat oraz klucz prywatny Cloudflare Origin CA.
Uwaga!
Skonfigurowanie certyfikatów Cloudflare Origin CA spowoduje, że są one zaufane tylko przez Cloudflare i dlatego powinny być używane tylko przez niego. Jeśli w dowolnym momencie wyłączysz tryb Proxy lub nawet przestaniesz korzystać z Cloudflare. Twój certyfikat zgłosi błąd, że jest niezaufany.
Wygenerowane certyfikaty należy zapisać na serwerze. Zapiszemy je w katalogu /etc/ssl. Katalog ten już istnieje na naszym serwerze. Najpierw skopiuj zawartość Origin Certificate z poprzedniego okna dialogowego w przeglądarce. Następnie na swoim serwerze otwórz /etc/ssl/cert.pem w preferowanym przez Ciebie edytorze tekstu:
sudo nano /etc/ssl/cert.pemDodaj zawartość certyfikatu do pliku. Następnie zapisz i wyjdź z edytora. Wróć do przeglądarki i skopiuj zawartość klucza prywatnego. Otwórz plik /etc/ssl/key.pem:
sudo nano /etc/ssl/key.pemWklej klucz prywatny do pliku, zapisz plik i zamknij edytor. Po zapisaniu certyfikatu oraz klucza prywatnego musimy zaktualizować konfigurację naszego serwera www aby zaczął z nich korzystać.
Uwaga!
Czasami, gdy kopiujemy certyfikaty i klucze prywatne z Cloudflare i wklejamy go do odpowiednich plików na serwerze na końcu pliku dodawane są puste linie. Serwer NGINX oraz Apache będzie traktował takie certyfikaty i klucze jako nieprawidłowe, dlatego też upewnij się, że podczas kopiowania zawartości certyfikatów na końcu pliku nie dodały się puste linie.
Konfiguracja certyfikatów dla serwera NGINX
W poprzednim kroku wygenerowaliśmy certyfikat oraz klucz prywatny za pomocą Cloudflare Origin CA oraz zapisaliśmy je na naszym docelowym serwerze. W tym kroku skonfigurujemy serwer NGINX tak aby z nich korzystał.
Uwaga!
Przed dokonaniem zmian, zrób kopię zapasową edytowanych plików!
Poniżej bedziemy używać domeny dsecure.dev jako przykładu, w swojej konfiguracji zastąp ją swoją domeną. Otwórz plik /etc/nginx/sites-available/twoja_domena:
sudo nano /etc/nginx/sites-available/dsecure.devI zmodyfikuj zawartość aby wyglądała podobnie do tej:
server {
# SSL configuration
listen 443 ssl http2;
listen [::]:443 ssl http2;
ssl on;
ssl_certificate /etc/ssl/cert.pem;
ssl_certificate_key /etc/ssl/key.pem;
server_name twoja_domen www.twoja_domena;
root /var/www/twoja_domena/html;
index index.html index.htm index.nginx-debian.html;
location / {
try_files $uri $uri/ =404;
}
}Na rysunku nr 11 przedstawiona jest przykładowa konfiguracja NGINX dla domeny dsecure.dev. Jeśli dobrze się przyjrzysz to możesz zauważyć, że usuneliśmy z konfiguracji obsługę HTTP i zostawiliśmy tylko HTTPS. Obsługa protokołu HTTP przy wykorzystaniu Cloudflare nie będzie nam już potrzebna.
Rysunek 11. Przykładowa konfiguracja NGINX dla domeny dsecure.dev
Następnie wyłączamy domyślną konfigurację poprzez usunięcie linku symbolicznego z katalogu sites-enabled:
sudo rm /etc/nginx/sites-enabled/defaultOraz włączamy nową konfigurację za pomocą linku symbolicznego:
sudo ln -s /etc/nginx/sites-available/dsecure.dev /etc/nginx/sites-enabled/dsecure.devPo wykonaniu powyższych zmian, sprawdź poprawność konfiguracji za pomocą polecenia:
sudo nginx -t
Rysunek 12. Wynik polecenia nginx -t.
Zrestartuj serwer NGINX:
sudo systemctl restart nginxTeraz przejdź do sekcji SSL/TLS w panelu zarządzania Cloudflare, następnie wybierz Overview i upewni się, że masz zaznaczoną opcję Full (strict) (Rysunek 13).
Rysunek 13. Skonfigurowana metoda połączenia end to end Full (strict) za pomocą Cloudflare.
W tym momencie konfiguracji odwiedź swoją witrynę, aby sprawdzić czy wszystko jest skonfigurowane prawidłowo. Jeśli zobaczysz swoją stronę główną a w pasku adresu jest “zielona kłódka” to wszystko działa tak jak powinno. W następnym kroku skonfigurujemy uwierzytelnianie za pomocą Origin Pulls, aby sprawdzić czy nasz serwer komunikuje się rzeczywiście tylko z Cloudflare i nie możliwa jest komunikacja z jakimkolwiek innym serwerem, tzn nie jest możliwe ominięcie serwisu Cloudflare. Dzięki temu sposobowi NGINX będzie akceptował tylko żądania korzystające z ważnego certyfikatu klienta (Cloudflare), wszystkie inne żądania, które nie przeszły przez Cloudflare, zostaną odrzucone.
Konfiguracja certyfikatów dla serwera Apache
W kroku Generowanie certyfikatów Cloudflare Origin CA wygenerowaliśmy certyfikat oraz klucz prywatny za pomocą Cloudflare Origin CA oraz zapisaliśmy je na naszym docelowym serwerze. W tym kroku skonfigurujemy serwer Apache tak aby z nich korzystał.
| Jeśli korzystasz z hostingu współdzielonego możesz pominąć ten krok. Wgranie certyfikatów będzie znajdować się w panelu zarządzania certyfikatami u Twojego dostawcy. |
Uwaga!
Przed dokonaniem zmian, zrób kopię zapasową edytowanych plików!
Na początku, upewnijmy się, że mamy włączony moduł SSL dla Apache za pomocą polecenia:
sudo a2enmod ssl
Rysunek 14. Wynik polecenia sudo a2enmod ssl.
Poniżej bedziemy używać domeny dsecure.dev jako przykładu, w swojej konfiguracji zastąp ją swoją domeną. Otwórz plik /etc/apache2/sites-available/twoja_domena.conf:
sudo nano /etc/apache2/sites-available/dsecure.dev.confI zmodyfikuj zawartość aby wyglądała podobnie do tej:
<VirtualHost *:443>
ServerAdmin contact@twoja_domena
ServerName twoja_domena
ServerAlias www.twoja_domena
DocumentRoot /var/www/twoja_domena/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/cert.pem
SSLCertificateKeyFile /etc/ssl/key.pem
</VirtualHost>Na rysunku nr 15 przedstawiona jest przykładowa konfiguracja Apache dla domeny dsecure.dev. Jeśli dobrze się przyjrzysz to możesz zauważyć, że nie mam konfiguracji dla obsługi HTTP. Obsługa protokołu HTTP nie będzie nam już potrzebna.
Rysunek 15. Przykładowa konfiguracja Apache dla domeny dsecure.dev
Dodatkowo możemy wyłączyć port 80 w konfiguracji w pliku /etc/apache2/ports.conf zakomentowując linie zawierającą wpis Listen 80 tak jak na rysunku nr 16:
Rysunek 16. Wyłączona obsługa portu 80 dla serwera Apache.
Następnie wyłączamy domyślną konfigurację poprzez usunięcie linku symbolicznego z katalogu sites-enabled:
sudo rm /etc/apache2/sites-enabled/000-default.confWłączamy nową konfigurację za pomocą linku symbolicznego:
sudo ln -s /etc/apache2/sites-available/dsecure.dev.conf
/etc/apache2/sites-enabled/dsecure.dev.confSprawdzamy czy nasza konfiguracja jest prawidłowa za pomocą polecenia:
sudo apachectl configtestWynik powinien wyglądać podobnie jak na poniższym zrzucie ekranu:
Rysunek 17. Wynik polecenia apachectl configtest
Teraz przejdź do sekcji SSL/TLS w panelu zarządzania Cloudflare, następnie wybierz Overview i upewni się, że masz zaznaczoną opcję Full (strict) (Rysunek 13).
W tym momencie konfiguracji odwiedź swoją witrynę, aby sprawdzić czy wszystko jest skonfigurowane prawidłowo. Jeśli zobaczysz swoją stronę główną a w pasku adresu jest “zielona kłódka” to wszystko działa tak jak powinno. W następnym kroku skonfigurujemy uwierzytelnianie za pomocą Origin Pulls, aby sprawdzić czy nasz serwer komunikuje się rzeczywiście tylko z Cloudflare i nie możliwa jest komunikacja z jakimkolwiek innym serwerem, tzn nie jest możliwe ominięcie serwisu Cloudflare. Dzięki temu sposobowi Apache będzie akceptował tylko żądania korzystające z ważnego certyfikatu klienta (Cloudflare), wszystkie inne żądania, które nie przeszły przez Cloudflare, zostaną odrzucone.
Konfiguracja uwierzytelniania klienta
Skonfigurowany w poprzednim kroku Certyfikat Origin CA pomoże Cloudflare zweryfikować, czy łączy się z właściwym serwerem. W tym kroku skorzystamy z Origin Pulls, czyli uwierzytelniania klienta TLS, aby sprawdzić czy Twój serwer komunikuje się tylko z Cloudflare i niemożliwe jest jego ominięcie.
W tym kroku skonfigurujemy serwer tak aby akceptował tylko żądania korzystające z ważnego certyfikatu klienta Cloudflare. Żądania, które nie przeszły przez Cloudflare, zostaną odrzucone z powodu jego braku. Oznacza to, że atakujący nie będzie mógł obejść Cloudflare i bezpośrednio połączyć się z serwerem tak jak to pokazane jest to w sekcji Weryfikacja możliwości ominięcia usługi Cloudflare.
Cloudflare przedstawia swoje żądania podpisane przez następujący certyfikat:
—–BEGIN CERTIFICATE—– MIIGCjCCA/KgAwIBAgIIV5G6lVbCLmEwDQYJKoZIhvcNAQENBQAwgZAxCzAJBgNV BAYTAlVTMRkwFwYDVQQKExBDbG91ZEZsYXJlLCBJbmMuMRQwEgYDVQQLEwtPcmln aW4gUHVsbDEWMBQGA1UEBxMNU2FuIEZyYW5jaXNjbzETMBEGA1UECBMKQ2FsaWZv cm5pYTEjMCEGA1UEAxMab3JpZ2luLXB1bGwuY2xvdWRmbGFyZS5uZXQwHhcNMTkx MDEwMTg0NTAwWhcNMjkxMTAxMTcwMDAwWjCBkDELMAkGA1UEBhMCVVMxGTAXBgNV BAoTEENsb3VkRmxhcmUsIEluYy4xFDASBgNVBAsTC09yaWdpbiBQdWxsMRYwFAYD VQQHEw1TYW4gRnJhbmNpc2NvMRMwEQYDVQQIEwpDYWxpZm9ybmlhMSMwIQYDVQQD ExpvcmlnaW4tcHVsbC5jbG91ZGZsYXJlLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBAN2y2zojYfl0bKfhp0AJBFeV+jQqbCw3sHmvEPwLmqDLqynI 42tZXR5y914ZB9ZrwbL/K5O46exd/LujJnV2b3dzcx5rtiQzso0xzljqbnbQT20e ihx/WrF4OkZKydZzsdaJsWAPuplDH5P7J82q3re88jQdgE5hqjqFZ3clCG7lxoBw hLaazm3NJJlUfzdk97ouRvnFGAuXd5cQVx8jYOOeU60sWqmMe4QHdOvpqB91bJoY QSKVFjUgHeTpN8tNpKJfb9LIn3pun3bC9NKNHtRKMNX3Kl/sAPq7q/AlndvA2Kw3 Dkum2mHQUGdzVHqcOgea9BGjLK2h7SuX93zTWL02u799dr6Xkrad/WShHchfjjRn aL35niJUDr02YJtPgxWObsrfOU63B8juLUphW/4BOjjJyAG5l9j1//aUGEi/sEe5 lqVv0P78QrxoxR+MMXiJwQab5FB8TG/ac6mRHgF9CmkX90uaRh+OC07XjTdfSKGR PpM9hB2ZhLol/nf8qmoLdoD5HvODZuKu2+muKeVHXgw2/A6wM7OwrinxZiyBk5Hh CvaADH7PZpU6z/zv5NU5HSvXiKtCzFuDu4/Zfi34RfHXeCUfHAb4KfNRXJwMsxUa +4ZpSAX2G6RnGU5meuXpU5/V+DQJp/e69XyyY6RXDoMywaEFlIlXBqjRRA2pAgMB AAGjZjBkMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMB0GA1Ud DgQWBBRDWUsraYuA4REzalfNVzjann3F6zAfBgNVHSMEGDAWgBRDWUsraYuA4REz alfNVzjann3F6zANBgkqhkiG9w0BAQ0FAAOCAgEAkQ+T9nqcSlAuW/90DeYmQOW1 QhqOor5psBEGvxbNGV2hdLJY8h6QUq48BCevcMChg/L1CkznBNI40i3/6heDn3IS zVEwXKf34pPFCACWVMZxbQjkNRTiH8iRur9EsaNQ5oXCPJkhwg2+IFyoPAAYURoX VcI9SCDUa45clmYHJ/XYwV1icGVI8/9b2JUqklnOTa5tugwIUi5sTfipNcJXHhgz 6BKYDl0/UP0lLKbsUETXeTGDiDpxZYIgbcFrRDDkHC6BSvdWVEiH5b9mH2BON60z 0O0j8EEKTwi9jnafVtZQXP/D8yoVowdFDjXcKkOPF/1gIh9qrFR6GdoPVgB3SkLc 5ulBqZaCHm563jsvWb/kXJnlFxW+1bsO9BDD6DweBcGdNurgmH625wBXksSdD7y/ fakk8DagjbjKShYlPEFOAqEcliwjF45eabL0t27MJV61O/jHzHL3dknXeE4BDa2j bA+JbyJeUMtU7KMsxvx82RmhqBEJJDBCJ3scVptvhDMRrtqDBW5JShxoAOcpFQGm iYWicn46nPDjgTU0bX1ZPpTpryXbvciVL5RkVBuyX2ntcOLDPlZWgxZCBp96x07F AnOzKgZk4RzZPNAxCXERVxajn/FLcOhglVAKo5H0ac+AitlQ0ip55D2/mf8o72tM fVQ6VpyjEXdiIXWUq/o= —–END CERTIFICATE—–
Możesz również pobrać ten certyfikat bezpośrednio z Cloudflare.
Skopiuj lub pobierz certyfikat a następnie zapisz go w pliku /etc/ssl/cloudflare.crt:
sudo nano /etc/ssl/cloudflare.crtKonfiguracja dla serwera NGINX
Aby skonfigurować uwierzytelnianie klienta dla serwera NGINX zaktualizuj swoją konfigurację w pliku /etc/nginx/sites-available/twoja_domena:
sudo nano /etc/nginx/sites-available/dsecure.devDodaj dyrektywy ssl_client_certificate i ssl_verify_client tak jak na przykładzie poniżej:
server {
# SSL configuration
listen 443 ssl http2;
listen [::]:443 ssl http2;
ssl on;
ssl_certificate /etc/ssl/cert.pem;
ssl_certificate_key /etc/ssl/key.pem;
ssl_client_certificate /etc/ssl/cloudflare.crt;
ssl_verify_client on;
server_name your_domain www.your_domain;
root /var/www/your_domain/html;
index index.html index.htm index.nginx-debian.html;
location / {
try_files $uri $uri/ =404;
}
}Twoja konfiguracja powinna być podobna do tej przedstawionej na rysunku nr 18.
Rysunek 18. Przykładowa konfiguracja NGINX dla domeny dsecure.dev.
Po wykonaniu powyższych zmian, sprawdź poprawność konfiguracji za pomocą polecenia:
sudo nginx -t
Rysunek 19. Wynik polecenia nginx -t.
Następnie zrestartuj serwer NGINX:
sudo systemctl restart nginxNa koniec, aby włączyć uwierzytelniania Origin Pulls, otwórz sekcję SSL/TLS w panelu zarządzania Cloudflare, przejdź do zakładki Server Origin i włącz opcję Authenticated Origin Pulls (Rysunek 20).
Rysunek 20. Włączona opcja Authenticated Origin Pulls w panelu zarządzania Cloudflare.
W tym momencie konfiguracji odwiedź swoją witrynę, aby sprawdzić czy wszystko jest skonfigurowane prawidłowo. Jeśli zobaczysz swoją stronę główną a w pasku adresu jest “zielona kłódka” to wszystko działa tak jak powinno. Następnie aby sprawdzić, czy Twój serwer będzie akceptował tylko żądania podpisane przez CA Cloudflare, wyłącz opcję Authenticated Origin Pulls. Możesz również powtórzyć metodę opisaną w sekcji Weryfikacja możliwości ominięcia usługi Cloudflare. Gdy wyłączysz Origin Pulls lub spróbujesz ominąć Cloudflare za pomocą opisanych wcześniej metod powinieneś otrzymać komunikat o błędzie taki sam jak na rysunku nr 21. W następnym kroku skonfigurujemy serwer NGINX tak aby w logach zapisywał informacje na temat adresów IP odwiedzających a nie usługi Cloudflare.
Rysunek 21. Błąd połączenia z serwerem, brak prawidłowego certyfikatu klienta.
Konfiguracja dla serwera Apache
Jeśli korzystasz z hostingu współdzielonego, zapytaj swojego dostawcy czy i w jaki sposób
możesz skonfigurować uwierzytelnianie klienta za pomocą Cloudflare. Jeśli Twój dostawca nie obsługuje opcji uwierzytelniania klienta, możesz zawsze ograniczyć dostęp do serwera za pomocą pliku .htaccess. W tym celu w głównym katalogu swojej witryny internetowej wyedytuj plik .htaccess oraz dodaj na samym jego początku następującą zawartość:
order deny,allow
deny from all
allow from 103.21.244.0/22
allow from 103.22.200.0/22
allow from 103.31.4.0/22
allow from 104.16.0.0/12
allow from 108.162.192.0/18
allow from 131.0.72.0/22
allow from 141.101.64.0/18
allow from 162.158.0.0/15
allow from 172.64.0.0/13
allow from 173.245.48.0/20
allow from 188.114.96.0/20
allow from 190.93.240.0/20
allow from 197.234.240.0/22
allow from 198.41.128.0/17
allow from 199.27.128.0/21
allow from 2400:cb00::/32
allow from 2405:8100::/32
allow from 2405:b500::/32
allow from 2606:4700::/32
allow from 2803:f800::/32
allow from 2c0f:f248::/32
allow from 2a06:98c0::/29Listę aktualnych adresów Cloudflare możesz znaleźć pod tym linkiem. W efekcie, każdy kto będzie próbował połączyć się z Twoim serwerem pomijając Cloudflare otrzyma następujący komunikat o błędzie:
Rysunek 22. Zabezpieczenie połączenie z pliku .htaccesss.
Aby skonfigurować uwierzytelnianie klienta dla serwera Apache zaktualizuj swoją konfigurację w pliku /etc/apache2/sites-available/twoja_domena.conf:
sudo nano /etc/apache2/sites-available/dsecure.dev.confDodaj dyrektywy SSLVerifyClient, SSLVerifyDepth oraz SSLCACertificateFile tak jak na poniższym przykładzie:
<VirtualHost *:443>
ServerAdmin contact@twoja_domena
ServerName twoja_domena
ServerAlias www.twoja_domena
DocumentRoot /var/www/twoja_domena/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
SSLVerifyClient require
SSLVerifyDepth 1
SSLCACertificateFile /etc/ssl/cloudflare.crt
</VirtualHost>Twoja konfiguracja powinna być podobna do tej przedstawionej na rysunku nr 23.
Rysunek 23. Przykładowa konfiguracja Apache dla domeny dsecure.dev.
Po wykonaniu powyższych zmian, sprawdź poprawność konfiguracji za pomocą polecenia:
sudo apachectl configtest
Rysunek 24. Wynik apachectl configtest.
Następnie zrestartuj serwer Apache:
sudo systemctl restart apache2Na koniec, aby włączyć uwierzytelniania Origin Pulls, otwórz sekcję SSL/TLS w panelu zarządzania Cloudflare, przejdź do zakładki Server Origin i włącz opcję Authenticated Origin Pulls (Rysunek 25).
Rysunek 25. Włączona opcja Authenticated Origin Pulls w panelu zarządzania Cloudflare.
W tym momencie konfiguracji odwiedź swoją witrynę, aby sprawdzić czy wszystko jest skonfigurowane prawidłowo. Jeśli zobaczysz swoją stronę główną a w pasku adresu jest “zielona kłódka” to wszystko działa tak jak powinno. Następnie aby sprawdzić, czy Twój serwer będzie akceptował tylko żądania podpisane przez CA Cloudflare, wyłącz opcję Authenticated Origin Pulls. Możesz również powtórzyć metodę opisaną przeze mnie w sekcji Weryfikacja możliwości ominięcia usługi Cloudflare. Powinieneś otrzymać komunikat o błędzie taki sam jak na rysunku nr 26 lub informacje o odrzuceniu połączenia z powodu nieprawidłowego certyfikatu klienta. W następnym kroku skonfigurujemy serwer Apache tak aby logach zapisywał informacje na temat adresów IP odwiedzających a nie usługi Cloudflare.
Rysunek 26. Błąd połączenia z serwerem, brak prawidłowego certyfikatu klienta.
Konfiguracja logów serwera
W sekcji Weryfikacja możliwości ominięcia usługi Cloudflare oprócz problemu dotyczącego możliwości ominięcia usługi Cloudflare, przedstawiłem jeszcze jeden problem dotyczący zapisywania w logach adresów IP Cloudflare zamiast adresów IP odwiedzających. Dzieję się tak dlatego, że usługa Cloudflare działa jako proxy dla naszego serwera. Na rysunku nr 27 pokazane jest, jaki adres IP zapisywany jest w logach jeśli zapomnimy wykonać przedstawione poniżej kroki.
Rysunek 27. Adresy IP zapisywane w logach serwera z poprawną konfiguracją oraz bez niej.
Oryginalny adres IP odwiedzającego przesyłany jest do naszego serwera w nagłówku CF-Connecting-IP. Więc aby nasz serwer zapisywał poprawną informacje w logach należy dokonać małych zmian w jego konfiguracji. Minusem tego rozwiązania jest natomiast to, że jeśli Cloudflare dokona aktualizacji w swojej adresacji (na szczęście nie robi tego za często oraz informuje o zmianach dużo wcześniej, dając tym samym nam czas na dokonanie zmian), musimy ręcznie poprawić konfigurację serwera.
Konfiguracja dla serwera NGINX
Dla serwera NGINX musimy skorzystać z modułu ngx_http_realip_module, który standardowo jest zainstalowany wraz z pakietem NGINX więc wystarczy tylko edycja pliku /etc/nginx/sites-available/twoja_domena:
sudo nano /etc/nginx/sites-available/dsecure.devI dodanie dyrektywy set_real_ip_from i real_ip_header tak jak na przykładzie poniżej:
server {
# SSL configuration
listen 443 ssl http2;
listen [::]:443 ssl http2;
ssl on;
ssl_certificate /etc/ssl/cert.pem;
ssl_certificate_key /etc/ssl/key.pem;
ssl_client_certificate /etc/ssl/cloudflare.crt;
ssl_verify_client on;
server_name your_domain www.your_domain;
set_real_ip_from 192.0.2.1 (przykładowy adres IP);
real_ip_header CF-Connecting-IP;
root /var/www/your_domain/html;
index index.html index.htm index.nginx-debian.html;
location / {
try_files $uri $uri/ =404;
}
}Listę aktualnych adresów Cloudflare możesz znaleźć pod tym linkiem. Twoja konfiguracja powinna być podobna do tej przedstawionej na rysunku nr 28.
Rysunek 28. Przykładowa konfiguracja NGINX dla domeny dsecure.dev.
sudo nginx -t
Rysunek 29. Wynik polecenia nginx -t.
Następnie zrestartuj serwer NGINX:
sudo systemctl restart nginxOdśwież stronę i sprawdzić zawartość pliku /var/log/nginx/access.log:
Jeśli jest podobnie i w logach znalazłeś swój adres IP to znaczy, że cała konfiguracje wykonałeś prawidłowo.
Konfiguracja dla serwera Apache
Dla serwera Apache musimy skorzystać z modułu mod_remoteip, który możemy włączyć za pomocą polecenia:
sudo a2enmod remoteip
Rysunek 30. Wynik polecenia a2enmod remoteip.
Stwórz plik /etc/apache2/conf-enabled/remoteip.conf:
sudo nano /etc/apache2/conf-enabled/remoteip.confDodaj do niego zawartość:
RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxy 173.245.48.0/20
RemoteIPTrustedProxy 103.21.244.0/22
RemoteIPTrustedProxy 103.22.200.0/22
RemoteIPTrustedProxy 103.31.4.0/22
RemoteIPTrustedProxy 141.101.64.0/18
RemoteIPTrustedProxy 108.162.192.0/18
RemoteIPTrustedProxy 190.93.240.0/20
RemoteIPTrustedProxy 188.114.96.0/20
RemoteIPTrustedProxy 197.234.240.0/22
RemoteIPTrustedProxy 198.41.128.0/17
RemoteIPTrustedProxy 162.158.0.0/15
RemoteIPTrustedProxy 104.16.0.0/12
RemoteIPTrustedProxy 172.64.0.0/13
RemoteIPTrustedProxy 131.0.72.0/22Listę aktualnych adresów Cloudflare możesz znaleźć pod tym linkiem. Twoja konfiguracja powinna być podobna do tej przedstawionej na rysunku nr 31.
Rysunek 31. Zawartość pliku /etc/apache2/conf-enabled/remoteip.conf.
Zrestartuj serwer Apache:
sudo systemctl restart apache2Następnie odśwież stronę i sprawdzić zawartość pliku /var/log/apache2/access.log:
Jeśli jest podobnie i w logach znalazłeś swój adres IP to znaczy, że cała konfiguracje wykonałeś prawidłowo.
Podsumowanie
W niniejszym artykule zabezpieczyliśmy komunikację pomiędzy Cloudflare a naszym serwerem w taki sposób aby atakujący jeśli pozna rzeczywisty adres naszego serwera nie mógł się z nim połączyć. Dodatkowo poprawiliśmy konfigurację tak aby w logach serwera www pokazywany był rzeczywisty adres użytkownika, który łączy się z naszą stroną a nie adres IP usługi Cloudflare. Jeśli wcześniej korzystałeś z certyfikatów Let’s Encrypt to po wykonaniu wszystkich kroków zawartych w tym artykule możesz odinstalować cerbota oraz wykorzystywane przez niego pluginy. Opisane w artykule sugestie dotyczące poprawienia konfiguracji komunikacji są częstymi sugestiami po audytowymi dla klientów, którzy często zgłaszają problemy, że pomimo wykorzystania przez nich serwisu Cloudflare jako proxy aplikacja jest atakowana. Bardzo często zapomniany jest również krok, dzięki któremu w przypadku wystąpienia jakiegoś incydentu bezpieczeństwa będziemy mogli poznać adres IP atakującego. W kolejnej części zajmiemy się poprawieniem konfiguracji nagłówków bezpieczeństwa. Jeśli masz dodatkowe pytania dotyczące korzystania z Cloudflare, dobrym miejscem do poszukiwania odpowiedzi jest dokumentacja. Jeżeli potrzebujesz pomocy możesz również skontaktować się z nami za pomocą formularza kontaktowego.