biała lista adresów IP

Biała lista adresów IP (IP allowlisting) to reguła, która dopuszcza do wybranego zasobu wyłącznie żądania z wymienionych adresów albo sieci IP, a wszystkie pozostałe odrzuca. Stosuje się ją do paneli administracyjnych, formularzy logowania, interfejsów API i usług serwerowych. Mechanizm odwraca logikę czarnej listy: zamiast wyliczać, kogo zablokować, wylicza, kogo wpuścić. Serwery WWW obsługują go natywnie, na przykład dyrektywą Require ip w Apache ^[1] i dyrektywami allow oraz deny w nginx ^[2].

Jak działa

Serwer porównuje adres źródłowy połączenia z listą dozwolonych adresów i zakresów. Gdy adres pasuje, żądanie trafia dalej, do aplikacji. Gdy nie pasuje, serwer odpowiada błędem, zwykle 403, zanim aplikacja w ogóle się uruchomi. Formularz logowania nie widzi więc żądań spoza listy.

Drogę żądania pokazuje schemat poniżej.

RYS. 1Sprawdzenie adresu na białej liście

Apache 2.4 przyjmuje w Require ip pełny adres, fragment adresu, parę sieć i maska, zapis CIDR oraz adresy IPv6 ^[1]. Dokumentacja Apache zaznacza, że stare dyrektywy Order, Allow i Deny z modułu mod_access_compat są przestarzałe i zostaną usunięte w przyszłych wersjach, więc należy używać dyrektyw Require ^[1]. Odwrotną regułę, czyli odmowę dla wybranych adresów przy dostępie dla pozostałych, buduje się blokiem RequireAll z dyrektywą Require not ip ^[1]. Apache pozwala też wskazywać nazwy hostów zamiast adresów, ale każda taka reguła wymaga zapytań DNS, co spowalnia obsługę żądań ^[1]. W nginx reguły allow i deny są sprawdzane po kolei aż do pierwszego dopasowania, dlatego kolejność ma znaczenie ^[2]. Można je umieścić na poziomie całego serwera HTTP, pojedynczej witryny albo wybranej lokalizacji ^[2], a więc objąć nimi tylko ścieżki panelu.

# Apache 2.4: wp-login.php tylko z sieci biura
<Files "wp-login.php">
    Require ip 192.0.2.0/24 2001:db8:1::/48
</Files>

# nginx: to samo, reguły sprawdzane po kolei
location = /wp-login.php {
    allow 192.0.2.0/24;
    deny  all;
    # dalej zwykła obsługa PHP
}

Odmiany

Pokrewne techniki to geoblokowanie, które dopuszcza albo blokuje całe kraje, oraz zabezpieczenie katalogu hasłem, które zamiast adresu sprawdza dodatkowe dane logowania.

W WordPressie

Najczęstszym zastosowaniem jest ograniczenie dostępu do wp-login.php i katalogu wp-admin. Sekurak w poradniku z 17 lipca 2017 roku pokazuje konfigurację, dzięki której plik wp-login.php i cały zasób wp-admin są dostępne tylko z określonych adresów IP ^[4]. Poradnik używa składni order i allow from ^[4], którą Apache 2.4 uznaje dziś za przestarzałą ^[1]; ten sam efekt daje Require ip. Reguły te trafiają zwykle do pliku .htaccess; zob. zabezpieczenia w .htaccess.

Przy katalogu wp-admin jest jedna pułapka. Dokumentacja WordPressa ostrzega, że zabezpieczenie samego katalogu wp-admin/ może zepsuć część funkcji, na przykład obsługę AJAX w pliku wp-admin/admin-ajax.php ^[6]. Z tego pliku korzystają także formularze i wtyczki na stronie publicznej, więc trzeba go wyłączyć spod reguły.

Biała lista dobrze uzupełnia inne zabezpieczenia logowania. Atak siłowy i credential stuffing spoza listy kończą się na serwerze WWW, zanim WordPress sprawdzi hasło. Warto też pamiętać o innych drogach logowania: interfejs XML-RPC przyjmuje dane uwierzytelniające przez osobny plik xmlrpc.php, który reguła dla wp-login.php nie obejmuje.

Zagrożenia i ograniczenia

Zmienne adresy. Reguła działa dobrze przy stałym adresie IP biura. Przy pracy mobilnej, z domu albo przez operatora komórkowego adres się zmienia i administrator traci dostęp do panelu. Typowym obejściem jest VPN ze stałym adresem wyjściowym albo bastion host.

Serwer za pośrednikiem. Gdy strona stoi za reverse proxy albo siecią CDN, serwer widzi adres pośrednika, a adres klienta dostaje w nagłówku X-Forwarded-For. MDN ostrzega, że nagłówek ten można sfałszować; jeśli serwer jest dostępny bezpośrednio z internetu, żadna część listy w tym nagłówku nie jest wiarygodna do celów bezpieczeństwa ^[3]. Do kontroli dostępu wolno używać tylko adresów dopisanych przez zaufane serwery proxy, czytając listę od prawej strony ^[3]. Źle skonfigurowana reguła, która ufa temu nagłówkowi, pozwala obejść białą listę zwykłym podszyciem.

Pusta lista. Sekurak opisał podatność CVE-2026-33032 w Nginx UI z oceną CVSS 9.8: punkt końcowy /mcp_message nie miał pełnego uwierzytelniania i polegał na whiteliście IP, która domyślnie była pusta ^[5]. Pusta lista, zamiast blokować wszystko, przepuszczała wszystkie żądania ^[5]. Poprawkę wydano w wersji 2.3.4 ^[5].

Fałszywe poczucie bezpieczeństwa. Adres IP nie jest tożsamością. Z adresu biura może łączyć się każdy komputer w tej sieci, również zainfekowany.

Dobre praktyki

• Stosować listę tam, gdzie krąg użytkowników jest mały i znany: panel, SSH, bazy danych, narzędzia administracyjne. Zgodnie z zasadą najmniejszych uprawnień lista powinna być możliwie krótka.
• Egzekwować regułę jak najniżej: na zaporze albo serwerze WWW, a nie dopiero w PHP.
• Za pośrednikiem ufać tylko adresom dopisanym przez znane serwery proxy ^[3].
• Sprawdzić, co oznacza pusta lista w danym narzędziu, i testować regułę z adresu spoza listy ^[5].
• Nie traktować listy jako jedynej ochrony. Po jej stronie potrzebne jest też uwierzytelnianie wieloskładnikowe i limit prób logowania.