Jak chronić /wp-admin/install.php w WordPress

Każda instalacja WordPress jest dostarczana z plikiem o nazwie wp-admin/install.php. Na zdrowej witrynie jest zwykle nieszkodliwy. WordPress zauważa, że witryna jest już skonfigurowana, i zwraca krótką stronę "Already Installed". Ale istnieje przypadek brzegowy, który wielu właścicieli witryn niedocenia. W momencie, gdy coś idzie nie tak z bazą danych, ten sam plik zamienia się w pełni działający kreator instalacji. Atakujący, który natknie się na niego w odpowiednim momencie, może ponownie zainstalować WordPress na Twojej domenie, wskazać go na bazę danych, którą kontroluje, i odejść z kompletnym przejęciem.

Ten przewodnik wyjaśnia, kiedy install.php jest rzeczywiście niebezpieczny, które wtyczki bezpieczeństwa rzeczywiście obejmują ten przypadek (nie wszystkie, mimo tego, co sugeruje ich marketing), i jak prawidłowo zablokować plik. Obejmuje to również mniej komfortową sytuację, w której jesteś na shared hoście bez dostępu do konfiguracji serwera.

Kiedy install.php jest rzeczywiście problemem?

Jeśli odwiedzisz https://twojadomena.com/wp-admin/install.php na zdrowej witrynie, WordPress sprawdza, czy tabela wp_options zawiera już siteurl. Jeśli tak, wyświetla ekran "Already Installed" i na tym kończy się historia. Brak formularza, brak akcji, brak przejęcia.

Problem zaczyna się w momencie, gdy WordPress nie może odczytać tej wartości. Typowe scenariusze:

• Dane uwierzytelniające bazy danych w wp-config.php zostały zepsute (złe hasło po migracji hostingu, źle wpisana nazwa DB).
• Ktoś usunął lub opróżnił tabelę wp_options, albo przypadkowo podczas migracji, albo celowo poprzez SQL injection w podatnej wtyczce.
• Nieudany klon stagingowy pozostawił system plików na miejscu, ale bazę danych pustą.
• Użytkownik bazy danych stracił uprawnienia do określonych tabel.

We wszystkich tych przypadkach kreator instalacji staje się dostępny dla każdego w internecie. Kto pierwszy do niego dotrze, może wybrać nazwę użytkownika administratora, hasło i e-mail i faktycznie posiadać domenę. Dlatego ta kontrola istnieje w InspectWP, mimo że plik jest "normalny" w każdej instalacji WordPress.

Które wtyczki bezpieczeństwa mogą rzeczywiście chronić install.php?

To jest część, na której ludzie się potykają, więc warto być precyzyjnym. Większość ludzi zakłada, że każda wtyczka bezpieczeństwa WordPress automatycznie obejmuje install.php. To jest pół-prawda. Odpowiedź zależy całkowicie od tego, jak wtyczka się ładuje.

Normalna wtyczka WordPress startuje wewnątrz WordPress. Potrzebuje bazy danych, aby się uruchomić. Jeśli Twoja DB jest zepsuta lub pusta (co jest jedynym realistycznym scenariuszem, w którym install.php staje się niebezpieczny), WordPress nigdy nie startuje wystarczająco daleko, aby załadować wtyczkę. Żądanie trafia bezpośrednio do install.php i PHP wesoło renderuje kreator instalacji. Wtyczki bezpieczeństwa, które działają jako normalne wtyczki, nie mogą pomóc w tej sytuacji z definicji.

Jednak kilka wtyczek używa mechanizmu PHP zwanego auto_prepend_file. To ustawienie mówi PHP, aby wykonał określony plik przed każdym innym skryptem PHP na serwerze. Gdy wtyczka bezpieczeństwa rejestruje się w ten sposób, działa przed wp-config.php, przed próbą połączenia z bazą danych i przed install.php. Ma własne pliki konfiguracyjne i, w razie potrzeby, własne połączenie z bazą danych. Zepsuta instalacja WordPress na to nie wpływa.

Wtyczki, które wspierają ten tryb (i dlatego mogą chronić install.php, nawet gdy baza danych WordPress nie działa):

• Wordfence w trybie Extended Protection (czasem nazywanym Optimized Mode). To nie jest domyślne po instalacji. Musisz to wyraźnie włączyć w ustawieniach firewalla Wordfence. Po aktywacji plik o nazwie wordfence-waf.php jest umieszczany w katalogu głównym WordPress i rejestrowany przez .htaccess, .user.ini lub php.ini.
• NinjaFirewall (WP Edition). Używa auto_prepend_file jako trybu domyślnego. Jest tak skonfigurowany przy instalacji, bez dodatkowego przełącznika.
• NinjaFirewall (Pro / Full WAF). Ten sam mechanizm, ale zarejestrowany na poziomie serwera. Działa całkowicie poza WordPress.
• BitFire Security. Wspiera tryb "Always On Protection", również oparty na auto_prepend_file. Podobne w zachowaniu do Wordfence Extended Protection.
• Shield Security (ShieldPRO). Również ładuje się przez auto_prepend_file, choć ma bardziej konserwatywne podejście i nie modyfikuje .htaccess bezpośrednio.
• MalCare. Używa auto_prepend_file jako część instalacji WAF.

Wtyczki, które nie mogą zablokować install.php, gdy WordPress jest zepsuty, ponieważ działają jako normalne wtyczki WordPress:

• Wordfence w domyślnym Basic Mode (zanim włączysz Extended Protection).
• Solid Security (wcześniej iThemes Security). Nie dostarcza WAF, który działa przed WordPress.
• All-In-One WP Security & Firewall. Dobry w hartowaniu plików i logowania, ale działa wewnątrz WordPress.
• Większość firewalli opartych na wtyczkach, które nie polegają na auto_prepend_file.

Praktyczna konsekwencja: jeśli używasz Wordfence, przejdź do Wordfence, Firewall, Manage WAF i sprawdź, czy wiadomość mówi "Optimized" lub "Extended Protection Enabled". Jeśli nadal mówi Basic Mode, kreator optymalizacji prowadzi Cię przez konfigurację auto_prepend_file dla Twojego serwera. Ta pojedyncza zmiana zamienia Wordfence z reaktywnej wtyczki w prawdziwy firewall pre-WordPress.

Jedno zastrzeżenie dla obu ścieżek. Mechanizm wymaga, aby Twój host rzeczywiście pozwalał na auto_prepend_file przez .htaccess, .user.ini lub php.ini. Na większości shared hostów działa to od razu. Na niektórych zablokowanych managed hostach ustawienie jest ograniczone, a kreator optymalizacji po cichu zawiedzie lub wyświetli ostrzeżenie. W tym przypadku wracasz do podejścia reguł webserwera opisanego poniżej.

Opcja 1: Zablokuj install.php przez .htaccess (Apache)

Jeśli Twój host działa na Apache (co dotyczy większości dostawców shared hostingu, takich jak IONOS, Strato, All-Inkl, Hostinger, DomainFactory, SiteGround, Bluehost), możesz dodać następujący blok do pliku .htaccess w katalogu głównym WordPress:

<Files "install.php">
  Require all denied
</Files>

To działa na Apache 2.4 i nowszych, co jest używane przez praktycznie każdego hosta od lat. Jeśli jesteś na czymś starszym (Apache 2.2), użyj zamiast tego starej składni:

<Files "install.php">
  Order allow,deny
  Deny from all
</Files>

Umieść fragment nad znacznikiem # BEGIN WordPress, aby automatyczne zarządzanie rewrite WordPress go nie dotykało podczas aktualizacji.

Po zapisaniu pliku odwiedź https://twojadomena.com/wp-admin/install.php w prywatnym oknie przeglądarki. Powinieneś zobaczyć odpowiedź 403 Forbidden. Jeśli nadal widzisz stronę "Already Installed", nadpisania .htaccess są wyłączone na Twoim hoście. Przejdź do Opcji 3.

Opcja 2: Zablokuj install.php przez nginx

Na nginx nie ma .htaccess. Jeśli zarządzasz własnym serwerem (VPS, dedykowany lub elastyczny host taki jak Hetzner Cloud), dodaj to wewnątrz bloku server swojej witryny:

location = /wp-admin/install.php {
  deny all;
  return 403;
}

Przeładuj nginx za pomocą sudo nginx -t && sudo systemctl reload nginx i przetestuj za pomocą curl -I https://twojadomena.com/wp-admin/install.php. Powinieneś otrzymać 403.

Niektóre managed hosty używające nginx pod maską (jak Raidboxes, Kinsta, WP Engine) już dostarczają takie reguły. Warto sprawdzić dokumentację Twojego hosta lub otworzyć ticket wsparcia. Odpowiedź zwykle jest albo "już objęte", albo dodają regułę za Ciebie.

Opcja 3: Shared hosting bez nadpisań Apache

Jeśli jesteś na shared nginx hoście i .htaccess jest ignorowany, masz mniej opcji, ale nie utknąłeś. W kolejności preferencji:

1. Zainstaluj jeden z wyżej wymienionych firewalli pre-WordPress. Na shared hostach, gdzie auto_prepend_file jest dozwolony, wtyczka taka jak NinjaFirewall lub Wordfence w trybie Extended Protection daje Ci tę samą ochronę co reguła serwera, bez dotykania żadnej konfiguracji serwera. To często najbardziej pragmatyczna droga.
2. Zapytaj swojego hosta. Większość managed WordPress hostów na żądanie dodaje regułę na poziomie serwera za Ciebie. Zajmuje im to pięć minut i robią to rutynowo.
3. Zastąp zawartość pliku. Możesz otworzyć wp-admin/install.php przez SFTP i zastąpić cały plik pojedynczą linią:

   <?php // intentionally disabled, see install.php.bak

   Zachowaj kopię zapasową oryginału (install.php.bak) poza publiczną webroot na wypadek, gdybyś kiedykolwiek musiał legalnie ponownie zainstalować. Wada: aktualizacje core WordPress przywracają oryginalny plik, więc musisz ponownie zastosować zmianę po każdej dużej aktualizacji. Mała wtyczka must-use może to zautomatyzować (zobacz powiązany fragment kodu).
4. Odmów dostępu przez uprawnienia plików. Zmiana trybu pliku na 000 przez SFTP również blokuje dostęp na większości hostów. To samo zastrzeżenie: aktualizacje core to zresetują.

Co z przemianowaniem lub usunięciem install.php?

Technicznie możesz całkowicie usunąć install.php. WordPress nie potrzebuje go do normalnego działania. Jest używany tylko podczas początkowej instalacji i niektórych wewnętrznych procedur aktualizacji. Problem polega na tym, że plik jest przywracany przy każdej aktualizacji core WordPress, więc usunięcie nie jest trwałym rozwiązaniem. Jest też okazjonalnie odwoływany przez proces automatycznej aktualizacji, więc możesz widzieć ostrzeżenia w logu błędów, jeśli brakuje.

Przemianowanie jest jeszcze gorsze. WordPress nie znajdzie pliku pod jego nową nazwą, ale wesoło utworzy oryginał ponownie podczas następnej aktualizacji. Skończysz z dwoma kopiami.

Blokowanie dostępu na poziomie webserwera, lub przez firewall pre-WordPress, jest prawie zawsze lepszą odpowiedzią.

Jak zweryfikować swoją instalację

Po zastosowaniu jednej z powyższych opcji:

1. Otwórz https://twojadomena.com/wp-admin/install.php w prywatnym oknie lub oknie incognito.
2. Powinieneś zobaczyć stronę 403 Forbidden (lub 404, jeśli usunąłeś plik, lub niestandardową stronę blokowania firewalla, jeśli wybrałeś trasę wtyczki).
3. Jeśli widzisz stronę "Already Installed" lub, znacznie gorzej, prawdziwy formularz instalacji, reguła nie jest aktywna. Sprawdź dokładnie ścieżkę pliku, wyczyść wszelkie cache (Cloudflare, Varnish, cache strony na poziomie serwera) i spróbuj ponownie.
4. Uruchom nowy skan InspectWP. Kontrola "install.php exposed" w sekcji WordPress powinna stać się zielona.

Powiązane kontrole warte uruchomienia

Gdy już blokujesz rzeczy, warto zastosować ten sam rodzaj blokowania na poziomie webserwera (lub regułę firewalla pre-WordPress) do kilku innych wrażliwych endpointów: xmlrpc.php (chyba że aktywnie go używasz), wp-config.php.bak, .git/, .env i wszelkie pliki phpinfo.php, które deweloper mógł zostawić. InspectWP automatycznie oznacza je wszystkie w sekcji bezpieczeństwa.

Przypadek install.php jest dobrym przykładem defense in depth. WordPress chroni siebie, prawidłowo skonfigurowana wtyczka bezpieczeństwa dodaje dodatkową warstwę, a reguła webserwera obejmuje jeden scenariusz, w którym oba mogą zawieść. Wybierz kombinację, która pasuje do Twojego hosta. Pięć linii konfiguracji lub jeden przełącznik w wtyczce firewalla wystarczy, aby zamknąć lukę na dobre.