Jak zweryfikować, czy reverse proxy przesyła poprawny adres IP klienta

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

How to Verify a Reverse Proxy Is Sending the Correct Client IP

Zweryfikuj przekazywanie adresu IP klienta, porównując znane zewnętrzne źródło z każdym nagłówkiem proxy oraz ostatecznym analizowanym adresem backendu.

Reverse proxy kończy połączenie klienta, więc backend zazwyczaj widzi adres gniazda proxy, chyba że proxy przekazuje zaufane metadane żądania. Test musi rozróżniać bezpośredni adres peer od Forwarded, X-Forwarded-For i X-Real-IP, dokumentować każdy zaufany przeskok oraz udowodnić, że klient internetowy nie może podszyć się pod wartość używaną do logów, limitów szybkości ani kontroli dostępu.

Utwórz test znanego adresu IP klienta spoza domu

Użyj urządzenia korzystającego z danych mobilnych lub innej zewnętrznej sieci i zanotuj jego publiczny adres IPv4 lub IPv6 tuż przed wysłaniem żądania. Prześlij unikalną ścieżkę, wartość zapytania lub znacznik czasu przez publiczne reverse proxy.

MDN opisuje X-Forwarded-For jako de facto nagłówek do zachowania adresu klienta źródłowego w połączeniach proxy.

Zbierz logi edge proxy, wszelkich pośrednich proxy oraz log aplikacji backendowej dla tego jednego żądania. Bez znanego źródła i skorelowanego znacznika czasu wielu jednoczesnych użytkowników może uczynić łańcuch nagłówków niejednoznacznym.

Zanotuj adres gniazda peer i każdy przekazany nagłówek

Na backendzie zaloguj bezpośredni adres TCP peer oddzielnie od Forwarded, X-Forwarded-For, X-Real-IP oraz wszelkich specyficznych dla CDN nagłówków klienta. Nie nadpisuj surowych wartości podczas pierwszego testu.

Praktyczna analiza obsługi „prawdziwego” adresu IP klienta ostrzega, że dokładność zależy od tego, jak proxy ustawia lub dopisuje nagłówki oraz czy wcześniejsze wartości mogą być sfałszowane. Cały model zaufania proxy musi odpowiadać rzeczywistej architekturze sieci.

Adres gniazda backendu powinien odpowiadać bezpośredniemu zaufanemu proxy, podczas gdy wybrany adres klienta powinien odpowiadać zewnętrznemu urządzeniu testowemu. Jeśli backend loguje tylko adres proxy, oznacza to brak tworzenia lub parsowania nagłówków.

Zweryfikuj, jak każde proxy dodaje lub zastępuje nagłówek

Sprawdź każdy przeskok od CDN lub tunelu do edge proxy, proxy wewnętrznego i aplikacji. Zanotuj, czy każdy przeskok dopisuje do istniejącej listy, zastępuje niezaufane dane wejściowe, czy przekazuje nagłówek bez zmian.

Sling Academy wyjaśnia, że NGINX może ustawić X-Real-IP z bezpośredniego połączenia i dopisać łańcuch za pomocą proxy_add_x_forwarded_for.

Skonfiguruj pierwszy zaufany edge tak, aby usuwał lub zastępował nagłówki przekazywane przez klienta, a następnie dopisuj adresy na kontrolowanych, wewnętrznych przeskokach. Unikaj bezkrytycznego akceptowania wartości najbardziej z lewej lub z prawej strony bez określenia, ile proxy jest zaufanych.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Skonfiguruj backend, aby ufał tylko znanym adresom proxy

Ustaw listę zaufanych proxy aplikacji lub serwera WWW na dokładne adresy reverse proxy lub kontrolowane podsieci. Potwierdź, że bezpośrednie połączenia od zwykłych klientów LAN lub internetu nie są traktowane jako zaufane źródła nagłówków.

Wyjaśnienie Ip2Geo wskazuje, że połączenie aplikacji pochodzi od load balancera lub reverse proxy, a bezpieczne parsowanie oryginalnego IP wymaga reguły zaufanego przeskoku, a nie akceptowania dowolnych danych wejściowych.

Jeśli adres proxy zmienia się z powodu kontenerów, sieci nakładkowych lub CDN, udokumentuj obsługiwany zakres i aktualizuj go świadomie. Nie ufaj wszystkim prywatnym adresom tylko dlatego, że proxy obecnie używa jednego z nich.

Przeprowadź test z sfałszowanym nagłówkiem

Z zewnętrznego urządzenia testowego wyślij podrobioną wartość X-Forwarded-For lub Forwarded podczas łączenia się przez prawdziwe proxy. Porównaj surowy przychodzący nagłówek, znormalizowany nagłówek proxy oraz wybrany przez backend adres klienta.

Prawidłowy wynik to taki, że zaufany edge zastępuje lub bezpiecznie dopisuje do niezaufanych danych, a backend wybiera adres na podstawie udokumentowanej liczby zaufanych przeskoków. Sfałszowany adres nie może stać się wartością używaną do uwierzytelniania lub listy dozwolonych.

Powtórz test bezpośrednio do backendu z segmentu LAN, jeśli port jest dostępny. Backend powinien ignorować przekazywane nagłówki od niezaufanego bezpośredniego klienta i rejestrować faktyczny adres gniazda peer.

Zweryfikuj ścieżki IPv4, IPv6 i wieloproxy

Powtórz test przez IPv4 i IPv6, przez normalną publiczną nazwę hosta oraz przez dowolne CDN, tunel lub drugorzędne proxy używane w produkcji. Potwierdź, że logi zachowują poprawne formaty adresów i nie obcinają łańcucha.

Przewodnik ZimaSpace dotyczący tożsamości żądania reverse proxy dostarcza kontekst, dlaczego poprawne wartości przekazywane mają znaczenie wykraczające poza samo logowanie.

Proxy jest weryfikowane tylko wtedy, gdy znane źródło zgadza się z analizowanym adresem IP klienta, zaufane proxy pozostają widoczne w surowym łańcuchu, próby podszycia się nie powiodły, a kontrole bezpieczeństwa konsekwentnie używają znormalizowanej wartości. Sprawdź ponownie po dodaniu CDN, tunelu lub kolejnego przeskoku proxy.