Drupal 7 bez wsparcia: jak zamknąć do niego dostęp, zanim ktoś inny to zrobi za Ciebie

Drupal 7 przestał dostawać poprawki bezpieczeństwa 5 stycznia 2025 roku, po czternastu latach na rynku. W teorii sprawa jest prosta: migrujesz na nową wersję i temat się zamyka. W praktyce spotykamy klientów, którzy mają po kilka witryn na D7, każda z osobną bazą i garstką kont, i żadna z nich nie zniknie w najbliższym czasie, bo migracja kosztuje, a budżet jest gdzie indziej.

To nie jest odosobniony przypadek. Trafiliśmy niedawno na projekt, w którym kilka takich witryn obsługiwało zamkniętą grupę użytkowników z zewnątrz, konkretnie wykonawców logujących się sezonowo, żeby zgłaszać wykonane zlecenia. Żadnej z tych stron nie dało się w tym momencie zamknąć ani przenieść na nowszy CMS. Trzeba było więc odpowiedzieć na inne pytanie: jak dalej bezpiecznie utrzymywać coś, czego już nikt nie łata.

Dlaczego Drupal 7 bez wsparcia to większy problem, niż się wydaje

Same statystyki nie brzmią najgorzej: przez lata dla Drupala zgłoszono ułamek tego, co dla WordPressa. Problem w tym, że po 5 stycznia 2025 nowe luki w rdzeniu D7 po prostu nie są już łatane, chyba że kupi się płatne wsparcie od jednego z certyfikowanych dostawców programu D7ES (obecnie HeroDevs, Tag1 Consulting i Dropsolid). Bez tego każda nowa podatność zostaje otwarta na stałe.

Historia D7 zna już takie sytuacje z bliska. Atak Drupalgeddon z 2014 roku wykorzystywał lukę SQL injection w rdzeniu i infekował strony w ciągu kilku godzin od publikacji łatki, bo administratorzy nie zdążyli zaktualizować systemów. Cross-site scripting odpowiada za sporą część wszystkich zgłoszonych podatności Drupala. Skoro to były problemy przy aktywnym wsparciu, trudno oczekiwać poprawy, kiedy łatek już nie ma.

Do tego dochodzi drugi front: moduły firm trzecich. Nawet gdyby ktoś opłacił D7ES dla rdzenia, większość instalacji korzysta z dodatkowych modułów, które już dawno przestały być rozwijane. Skaner podatności może milczeć tygodniami, zanim ktoś w ogóle zauważy, że witryna została przejęta.

Migracja to właściwa odpowiedź, ale nie zawsze da się jej zrobić od razu

Rekomendacja “przenieś się na Drupal 10 albo 11” jest słuszna i to jest cel, do którego trzeba dążyć. Jak taka migracja z D7 na D11 wygląda w praktyce, opisaliśmy osobno. Problem w tym, że w rzeczywistych projektach migracja wielu witryn z niestandardowymi modułami to tygodnie albo miesiące pracy, a strona ma działać już teraz. W takiej sytuacji chodzi nie o to, żeby udawać, że D7 jest bezpieczny, tylko o to, żeby ograniczyć, kto w ogóle może do niego dotrzeć.

Zasada: nieautoryzowany ruch nigdy nie dociera do PHP

Jeśli rdzeń aplikacji nie może być łatany, to jedynym sensownym zabezpieczeniem zostaje kontrola dostępu przed aplikacją, a nie w niej. W praktyce oznacza to bramkę logowania ustawioną przed serwerem WWW: każde żądanie trafia najpierw do niej, a dopiero po pozytywnym uwierzytelnieniu jest przepuszczane dalej do PHP-FPM i Drupala.

Do tego celu użyliśmy Authelii w trybie forward-auth za reverse proxy Caddy. Mechanizm jest prosty: proxy pyta Authelię “czy ten użytkownik może tu wejść?”, a Authelia odpowiada tak albo nie, zanim żądanie w ogóle dotrze do aplikacji. Nikt nieautoryzowany nie zobaczy nawet strony logowania Drupala, bo do niej też trzeba się najpierw zalogować w Authelii, z drugim składnikiem uwierzytelnienia (TOTP) do kompletu.

Dzięki temu D7 przestaje być bezpośrednio wystawiony na świat. Skanery podatności i boty szukające znanych exploitów uderzają w ścianę logowania, zanim dotrą do czegokolwiek, co można wykorzystać. To nie usuwa luk w kodzie, ale usuwa okazję do ich wykorzystania przez przypadkowego atakującego z internetu.

Jeden katalog kont zamiast osobnych baz na każdej witrynie

Druga część układanki to zarządzanie samymi kontami. Przy kilku niezależnych instalacjach D7 klasyczne podejście to osobna tabela użytkowników na każdej stronie, osobne hasła i osobny proces resetowania. To niewygodne dla administratora i ryzykowne dla bezpieczeństwa: im więcej miejsc przechowuje hasła, tym więcej miejsc może je wyciekać.

Zamiast tego wpięliśmy LLDAP jako jeden, wspólny katalog tożsamości. LLDAP to lekka implementacja LDAP, pomyślana właśnie pod niewielkie wdrożenia, gdzie pełny Active Directory czy FreeIPA byłby przerostem formy nad treścią. Samą integrację Drupala z katalogiem LDAP omawialiśmy już wcześniej, tu wykorzystujemy ją jako element większej całości. Authelia pyta LLDAP o dane logowania, a każda witryna Drupala już nie przechowuje realnego hasła użytkownika, tylko dostaje potwierdzenie tożsamości od bramki i loguje na tej podstawie odpowiednie konto lokalne.

Efekt praktyczny: dodanie nowego wykonawcy albo pracownika to jedna operacja w jednym miejscu, a nie ręczne zakładanie konta na czterech czy pięciu różnych stronach. Odebranie dostępu, na przykład po zakończeniu sezonu współpracy, też jest jedną zmianą, a nie listą rzeczy do sprawdzenia i odhaczenia po kolei.

To nie jest docelowe rozwiązanie

Bramka logowania i wspólny katalog kont nie są magiczną łatką na luki w kodzie D7. Zalogowany użytkownik z przejętym kontem albo złośliwym zamiarem nadal może wykorzystać podatność w samej aplikacji, jeśli taka istnieje. To rozwiązanie zawęża krąg osób, które w ogóle mają szansę spróbować, z całego internetu do zamkniętej, znanej grupy kont, ale nie zastępuje aktualizacji, kopii zapasowych ani monitoringu logów. Traktuj je jako jedną z warstw, obok pozostałych praktyk bezpieczeństwa Drupala.

Warto też pamiętać o jednym szczególe technicznym: jeśli integracja SSO opiera się na przekazywaniu tożsamości użytkownika w nagłówku HTTP między proxy a aplikacją, całe bezpieczeństwo tego mechanizmu zależy od tego, że nic poza proxy nie ma bezpośredniego dostępu do PHP-FPM. Jeśli kiedykolwiek pojawi się inna droga do aplikacji, ten nagłówek trzeba przestać ufać, dopóki się jej nie zamknie.

Kiedy to podejście ma sens

To rozwiązanie sprawdza się tam, gdzie krąg użytkowników jest znany i zamknięty, na przykład pracownicy, kontrahenci czy partnerzy logujący się do wewnętrznego narzędzia, a nie ogólnodostępna witryna publiczna, którą każdy powinien móc odwiedzić bez logowania. Dla publicznej strony na D7 ta sama zasada “ogranicz dostęp” nie zadziała, bo strona z definicji ma być otwarta. Tam jedyną drogą pozostaje realna migracja albo płatne wsparcie rozszerzone.

Jeśli u Ciebie w organizacji nadal działa Drupal 7, i to niekoniecznie dla szerokiej publiki, tylko dla zamkniętego grona osób, ograniczenie dostępu bramką logowania i uporządkowanie kont w jednym miejscu to coś, co można wdrożyć w dniach, a nie miesiącach, podczas gdy planujesz właściwą migrację. Jeśli chcesz przegadać, jak to zrobić u siebie, napisz do nas.