Zabezpieczanie paneli administracyjnych przez IP, VPN lub dodatkową ochronę

Krótko: Panel administracyjny najskuteczniej chronisz, otwierając go tylko dla znanych sieci: przez listę dozwolonych adresów IP w serwerze WWW, przez VPN ze stałym adresem wyjściowym lub przez drugie, wstępne logowanie. Ważne są kompletna lista wszystkich adresów administracyjnych, prawidłowa obsługa proxy i CDN oraz test z zewnątrz. Takie zabezpieczenie uzupełnia uwierzytelnianie dwuskładnikowe i aktualizacje, ale ich nie zastępuje.

Dlaczego backend w ogóle jest otwarty?

W wielu firmach administratorzy w zeszłym tygodniu zaktualizowali PHP i zrestartowali procesy worker. Kto potem zajrzy do logów dostępu, często zauważa coś innego: strona logowania CMS, narzędzie do obsługi bazy danych i panel hostingu są całą dobę wywoływane z całego świata. Potrzebuje ich jednak tylko garstka osób z własnego zespołu.

Każdy z tych adresów to powierzchnia ataku. Formularze logowania są sprawdzane metodą prób, narzędzia administracyjne mają własne luki, a wtyczki do backendu są często gorzej przetestowane niż rdzeń CMS. Jeśli obce osoby w ogóle nie mogą dotrzeć do tych obszarów, wiele ataków kończy się, zanim się zaczną.

Uczciwie oceniając: przed samym PHP2Shell niewiele to daje. Luki tkwią w interpreterze i według php.net można je wywołać bez logowania przez publiczne strony PHP. Zabezpieczenie backendu to trwałe utwardzanie, a nie awaryjna poprawka.

Ochrona panelu admina przez IP, VPN lub drugie logowanie

Nie ma jednej właściwej metody. Decyduje to, jak pracuje Państwa zespół i gdzie działa strona.

W praktyce sprawdza się połączenie: dostęp tylko dla VPN lub sieci firmowej, a do tego drugie logowanie jako warstwa zapasowa. Właściwe logowanie w CMS pozostaje z uwierzytelnianiem dwuskładnikowym, jak opisano w poradniku Uwierzytelnianie dwuskładnikowe dla dostępów administratora.

Które adresy w ogóle należą do backendu?

Najczęstszą słabością nie jest technika, lecz niekompletna lista. Dlatego postępuj w tej kolejności:

1. Spisać strony logowania CMS lub sklepu, łącznie z alternatywnymi adresami logowania tworzonymi przez wtyczki.
2. Wyszukać narzędzia administracyjne: interfejsy baz danych, menedżery plików, skrypty instalacyjne, strony statusu i monitoringu.
3. Uwzględnić panele hostingu i serwera, które często działają na własnych portach.
4. Sprawdzić instancje testowe i stagingowe, które często używają tych samych danych dostępowych co strona produkcyjna.
5. Wyodrębnić interfejsy: niektóre ścieżki backendu są wywoływane także przez publiczny frontend, na przykład w żądaniach Ajax. Nie wolno ich ślepo blokować, inaczej przestaną działać formularze lub koszyki.

Punkt piąty jest powodem, dla którego zabezpieczenie zawsze trzeba przetestować. Na przykład w WordPressie plik w katalogu admina jest używany także do funkcji publicznych.

Konfiguracja: lista IP plus drugie logowanie

W Nginx oba warunki można połączyć. Dzięki satisfy all żądanie musi pochodzić z dozwolonej sieci i dodatkowo przejść drugie logowanie. Ścieżka, adresy i przekazanie do PHP są wartościami zastępczymi:

location ^~ /backend/ {
    satisfy all;

    allow 192.0.2.0/24;      # sieć firmowa (wartość zastępcza)
    allow 198.51.100.10;     # wyjście VPN (wartość zastępcza)
    deny  all;

    auth_basic           "Interner Bereich";
    auth_basic_user_file /etc/nginx/htpasswd-backend;

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php-fpm.sock;
    }
}

Zagnieżdżona lokalizacja PHP jest ważna: przez ^~ inne reguły dla .php nie są już oceniane. W Apache to samo osiągniesz blokiem, w którym muszą być spełnione oba warunki:

<Location "/backend">
    AuthType Basic
    AuthName "Interner Bereich"
    AuthUserFile /etc/apache2/htpasswd-backend
    <RequireAll>
        Require ip 192.0.2.0/24 198.51.100.10
        Require valid-user
    </RequireAll>
</Location>

Plik z hasłami należy trzymać poza webroot. Drugie logowanie przesyła dane dostępowe przy każdym żądaniu, dlatego stosuj je wyłącznie przez HTTPS.

Pułapki: CDN, proxy, IPv6 i praca zdalna

Jeśli Państwa strona znajduje się za CDN, takim jak Cloudflare, lub za load balancerem, serwer WWW początkowo widzi tylko jego adresy. Lista IP zablokowałaby wtedy wszystkich albo przepuściła wszystkich. Serwer WWW musi przejąć prawdziwy adres z nagłówka: w Nginx za pomocą set_real_ip_from i real_ip_header, w Apache za pomocą mod_remoteip.

Obowiązuje przy tym zasada: nagłówek akceptuj tylko od własnych adresów proxy. W przeciwnym razie każdy odwiedzający może podszyć się pod dowolne pochodzenie. Równie ważne jest, aby serwer źródłowy nie był bezpośrednio dostępny, bo inaczej proxy wraz z jego regułami można obejść. Wskazówki znajdują się w artykule Firewall dla serwera WWW.

Dwa kolejne punkty są często pomijane. Jeśli serwer jest dostępny przez IPv6, także adresy IPv6 Państwa sieci potrzebują wpisu, inaczej administratorzy z IPv6 trafią na blokadę. Ponadto prywatne łącza internetowe regularnie zmieniają adres. Dla pracy zdalnej i zewnętrznych usługodawców VPN jest więc zwykle rozwiązaniem stabilniejszym.

Jak sprawdzić, czy zabezpieczenie działa

Reguła, która nie została przetestowana, nie jest uznawana za wdrożoną. Sprawdź z łącza spoza sieci firmowej, na przykład przez sieć komórkową:

# Oczekiwane: 403 (zablokowane) lub 401 (wymagane drugie logowanie)
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/
# Sprawdzić też bezpośrednio pliki PHP, a nie tylko katalog
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/index.php

Następnie te same wywołania z sieci firmowej lub z VPN: tam strona musi być dostępna. Potem skontroluj publiczny frontend, czyli formularze, wyszukiwarkę i koszyk. W logach z kolejnych dni dostęp do adresów administracyjnych powinien pojawiać się niemal wyłącznie ze statusem 401 lub 403.

Jeśli obszar był dotąd otwarty, warto przejrzeć istniejące konta. Jak znaleźć nieznanych administratorów, opisuje wpis Obce konta administratora w CMS i na serwerze: jak je znaleźć. Dodatkowo spowalnia ochrona przed masowym zgadywaniem haseł, zob. Ochrona logowania administratora przed atakami brute force.

Jak konkretnie pomaga PHP SOS?

• Spisujemy wszystkie adresy administracyjne Państwa stron, paneli i narzędzi i oddzielamy je od ścieżek potrzebnych publicznie.
• Wspólnie z Państwem wybieramy odpowiednią metodę, zależnie od wielkości zespołu, pracy zdalnej i hostingu.
• Wdrażamy reguły w serwerze WWW, uwzględniamy CDN, proxy i IPv6 i przy tym zostawiamy otwartą drogę powrotu.
• Testujemy z zewnątrz i od wewnątrz oraz przekazujemy krótką dokumentację z dozwolonymi sieciami.

Zabezpieczenie paneli administracyjnych jest częścią naszego utwardzania serwerów PHP.

Częste pytania

Źródła

• Seria ściągawek OWASP (Cheat Sheet Series)
• Dokumentacja Nginx
• Serwer HTTP Apache: dokumentacja