reverse proxy

Reverse proxy to serwer postawiony przed serwerami aplikacji, który przyjmuje żądania z internetu w ich imieniu i przekazuje je dalej. Działa odwrotnie niż zwykły serwer proxy: tamten występuje w imieniu klientów i może ukrywać ich tożsamość, a reverse proxy występuje w imieniu serwerów i może ukrywać ich tożsamość ^[1]. Typowe zadania to rozkładanie obciążenia na kilka serwerów, buforowanie treści statycznej i kompresja odpowiedzi ^[1]. W praktyce na tym samym urządzeniu kończy się też szyfrowanie TLS i działa filtrowanie żądań.

Jak działa

Przeglądarka łączy się z adresem, pod którym słucha reverse proxy, i nie widzi serwera aplikacji. Proxy odbiera żądanie, podejmuje decyzję (obsłużyć z pamięci podręcznej, odrzucić, przekazać) i otwiera osobne połączenie do serwera źródłowego. Odpowiedź wraca tą samą drogą. W serwerze nginx za przekazywanie odpowiada moduł ngx_http_proxy_module, który według dokumentacji pozwala przekazywać żądania do innego serwera, a dyrektywa proxy_pass wskazuje protokół i adres serwera docelowego ^[2].

RYS. 1Żądanie przez reverse proxy

Ponieważ połączenie do serwera aplikacji zestawia proxy, serwer widzi adres IP proxy, a nie klienta. Informacje o kliencie trzeba przekazać w nagłówkach. Standardem jest nagłówek Forwarded z RFC 7239 z czerwca 2014 roku, który zastąpił niestandardowe X-Forwarded-For, X-Forwarded-By i X-Forwarded-Proto ^[3]. W praktyce nadal najczęściej spotyka się wersje X-Forwarded-* ^[1]. Nginx domyślnie nie przekazuje dalej oryginalnych nagłówków Host i Connection, tylko ustawia własne wartości ^[2], więc konfiguracja musi je jawnie ustawić:

location / {
    proxy_pass       http://127.0.0.1:8080;
    proxy_set_header Host              $host;
    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

Zastosowania

Jedno urządzenie może łączyć kilka ról. Zestawienie poniżej pokazuje najczęstsze.

Tak zbudowane są usługi CDN i chmurowe zapory aplikacyjne: ruch domeny trafia najpierw do sieci dostawcy, a dopiero potem do serwera klienta. Sekurak opisuje HAProxy jako reverse proxy TCP/HTTP dla środowisk wysokiej dostępności ^[7].

W WordPressie

WordPress za reverse proxy działa poprawnie tylko wtedy, gdy wie, jakim protokołem i z jakiego adresu przyszedł klient.

HTTPS. Dokumentacja WordPressa ostrzega, że jeśli strona stoi za reverse proxy obsługującym SSL, a sama działa bez SSL, wymuszenie HTTPS w panelu wpada w nieskończoną pętlę przekierowań ^[5]. Zalecane rozwiązanie to odczytanie nagłówka X-Forwarded-Proto w pliku wp-config.php i ustawienie zmiennej HTTPS ^[5]. Ta sama strona przypomina, że przy przekazywaniu żądania do innego hosta nagłówki nie przechodzą same; proxy musi je ustawić ^[5].

// wp-config.php, tylko gdy serwer jest osiągalny wyłącznie przez proxy
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
     && false !== strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) ) {
    $_SERVER['HTTPS'] = 'on';
}

Adres IP klienta. Wtyczki liczące próby logowania (limit prób logowania), blokujące adresy albo prowadzące dziennik zdarzeń potrzebują prawdziwego IP. Za proxy każde żądanie ma ten sam adres, więc blokada jednego „intruza” odcina wszystkich. Odwrotny błąd jest groźniejszy: wtyczka, która ufa nagłówkowi X-Forwarded-For bez sprawdzenia, pozwala atakującemu wpisać tam dowolny adres. MDN wymienia jako skutki takiego zaufania ominięcie ograniczania liczby żądań i ominięcie kontroli dostępu ^[4].

Zagrożenia i skutki

Reverse proxy przesuwa granicę zaufania. Kilka błędów konfiguracji powtarza się szczególnie często.

• Sfałszowane nagłówki. RFC 7239 zastrzega, że na nagłówku Forwarded nie można polegać, bo każdy węzeł po drodze może go zmienić, przez pomyłkę albo celowo ^[3]. MDN dodaje, że jeśli serwer jest osiągalny z internetu bezpośrednio, żadna część listy adresów w X-Forwarded-For nie jest wiarygodna dla celów bezpieczeństwa ^[4].
• Obejście przez adres źródłowy. Ochrona na proxy nie działa, jeśli atakujący zna adres IP serwera za nim. Cloudflare zaleca ukrycie adresów źródłowych, zmianę adresu IP po wdrożeniu usługi, bo dawne rekordy DNS pozostają publicznie dostępne, oraz blokadę ruchu spoza swoich adresów ^[6]. Obejście otwiera drogę m.in. do ataku DDoS na sam serwer.
• Rozbieżna interpretacja żądań. Gdy proxy i serwer inaczej rozumieją granice żądania albo nagłówek Host, powstają błędy takie jak HTTP request smuggling, host header injection i web cache poisoning.
• Ujawnienie danych. RFC 7239 zauważa, że nagłówek zawiera dane, które część użytkowników uważa za wrażliwe, i nie powinien być kopiowany przez serwer do odpowiedzi ^[3].

Dobre praktyki

1. Serwer źródłowy przyjmuje połączenia tylko od proxy. Cloudflare zaleca jawne blokowanie całego ruchu spoza adresów dostawcy i uwierzytelnienie połączeń między proxy a serwerem ^[6]; zob. biała lista adresów IP i zapora sieciowa (firewall).
2. Adres klienta odczytuje się tylko z wartości dopisanej przez zaufane proxy. MDN opisuje dwie metody: stałą liczbę proxy liczoną od prawej strony listy albo listę zaufanych adresów proxy pomijanych od prawej ^[4].
3. Nagłówki X-Forwarded-* przychodzące od klienta proxy nadpisuje, a nie dopisuje do nich.
4. Połączenie proxy z serwerem aplikacji w innej sieci też szyfruje się TLS, a nie tylko odcinek od przeglądarki.
5. Dziennik zdarzeń zapisuje zarówno adres połączenia, jak i adres z nagłówka, co ułatwia analizę po incydencie.