Bezpieczeństwo Joomla - 8 warstw ochrony strony internetowej

Bezpieczna Joomla to nie Joomla, której nikt jeszcze nie zaatakował. To serwis zbudowany tak, aby pojedynczy błąd, przejęte hasło albo podatne rozszerzenie nie wystarczyły do uzyskania pełnej kontroli nad stroną. Sam aktualny CMS jest tylko jedną z warstw ochrony. Powyżej i poniżej niego znajdują się serwer, PHP, baza danych, rozszerzenia, konta użytkowników, formularze, kopie zapasowe i procedury reagowania na incydent. Dopiero ich połączenie decyduje o rzeczywistym bezpieczeństwie witryny.

Bezpieczeństwo Joomla jako system warstw

Popularny sposób myślenia o bezpieczeństwie strony internetowej sprowadza się do jednego pytania: "Czy Joomla jest aktualna?". To ważne pytanie, ale zdecydowanie niewystarczające.

Można mieć aktualną Joomla 6, a jednocześnie korzystać ze starego komponentu, który nie jest już rozwijany. Można posiadać wszystkie aktualizacje, ale pozostawić konto Super User z łatwym do przejęcia hasłem. Można poprawnie zabezpieczyć zaplecze, a następnie dopuścić możliwość przesyłania dowolnych plików przez źle przygotowany formularz. Można wreszcie mieć dobrze skonfigurowany serwis i codzienny backup, którego nigdy nie próbowano odtworzyć.

Dlatego bezpieczeństwo Joomla lepiej przedstawić jako kilka kolejnych barier:

Internet -> serwer -> PHP -> Joomla -> rozszerzenia -> użytkownicy -> dane -> backup i reakcja

Atakujący nie musi pokonać wszystkich warstw. Szuka najsłabszej. Zadaniem administratora jest doprowadzenie do sytuacji, w której awaria jednej bariery nie oznacza automatycznie utraty całej witryny.

Warstwa 1 - serwer, PHP i pliki

Joomla działa w środowisku, którego sama nie kontroluje. Nawet poprawnie napisany CMS nie naprawi starego oprogramowania serwera, niewłaściwych praw dostępu do plików czy źle skonfigurowanego konta hostingowego.

Pierwszym zadaniem jest więc utrzymywanie wspieranej wersji PHP i aktualnego środowiska serwera. W przypadku Joomla 6 aktualna konfiguracja PHP ma znaczenie nie tylko dla bezpieczeństwa, ale także dla zgodności i wydajności całego systemu.

Warto też przejrzeć same pliki. Na wieloletnim koncie hostingowym można znaleźć katalogi pozostawione po wcześniejszej wersji strony, archiwa ZIP, stare instalacje Joomla, kopie testowe i pliki konfiguracyjne, które nie są już potrzebne.

Stara kopia strony może być większym zagrożeniem niż właściwa witryna

Wyobraźmy sobie, że właściwy serwis działa na aktualnej Joomla, ale pod adresem /old/ pozostawiono instalację sprzed kilku lat. Nie jest linkowana z menu i właściciel praktycznie o niej zapomniał.

Dla automatycznego skanera nie ma jednak znaczenia, czy instalacja jest widoczna w menu. Jeśli jej adres da się odnaleźć, podatny kod nadal znajduje się na serwerze.

Niepotrzebna aplikacja powinna zostać usunięta, a nie tylko ukryta przed użytkownikami.

Prawa plików nie powinny być ustawiane "na wszelki wypadek"

Zbyt szerokie prawa zapisu bywają stosowane jako szybki sposób rozwiązania problemu z instalacją rozszerzenia albo zapisem pliku. To niewłaściwe podejście. Uprawnienia powinny wynikać z konfiguracji serwera oraz rzeczywistych potrzeb aplikacji.

Jeśli Joomla nie może zapisać pliku, najpierw należy znaleźć powód, zamiast automatycznie nadawać wszystkim użytkownikom możliwość zapisu.

Warstwa 2 - aktualny rdzeń Joomla

Aktualizacje rdzenia pozostają jednym z podstawowych elementów bezpieczeństwa. Gdy poprawka bezpieczeństwa jest publicznie dostępna, informacja o problemie staje się również wskazówką dla osób i automatów szukających nieaktualnych instalacji.

W nowej generacji Joomla mechanizm aktualizacji został dodatkowo rozwinięty. Joomla 5.4 i Joomla 6 wprowadziły automatyczne aktualizacje rdzenia dla odpowiednich wydań, wykorzystujące TUF - The Update Framework. Mechanizm ma zwiększać bezpieczeństwo dystrybucji aktualizacji i ograniczać ryzyko manipulacji informacją o pakiecie aktualizacyjnym.

Automatyzacja nie oznacza jednak, że administrator może całkowicie przestać interesować się aktualizacjami. Nadal trzeba wiedzieć, czy aktualizacja zakończyła się prawidłowo, czy rozszerzenia są zgodne z nowym wydaniem oraz czy serwis działa po zmianie tak samo jak wcześniej.

Aktualizacja to proces, nie przycisk

W przypadku rozbudowanej strony bezpieczna procedura wygląda inaczej niż spontaniczne kliknięcie "Aktualizuj". Warto mieć aktualną kopię zapasową, znać kompatybilność rozszerzeń i po zmianie sprawdzić najważniejsze funkcje serwisu.

Bezpieczeństwo nie polega więc na unikaniu aktualizacji z obawy, że coś się zepsuje. Polega na przygotowaniu środowiska tak, aby aktualizacje można było wykonywać regularnie i przewidywalnie.

Warstwa 3 - komponenty, moduły i pluginy

Dodatkowe rozszerzenia wymagają szczególnej uwagi, ponieważ Joomla może być aktualna, a podatny kod nadal znajdować się w jednym z komponentów, modułów albo pluginów. Oficjalna dokumentacja Joomla wprost zwraca uwagę na podatności rozszerzeń firm trzecich i odsyła administratorów do listy Vulnerable Extensions List.

Nie oznacza to, że należy unikać rozszerzeń. Ich instalowanie jest normalną częścią budowania serwisów Joomla. Znaczenie ma natomiast selekcja i późniejsze utrzymanie.

Przed instalacją warto odpowiedzieć na kilka pytań:

• czy rozszerzenie jest nadal rozwijane,
• czy producent publikuje aktualizacje,
• czy wspiera używaną wersję Joomla i PHP,
• czy rzeczywiście potrzebujemy jego funkcji,
• czy istnieją informacje o znanych podatnościach,
• czy potrafimy je bezpiecznie usunąć, gdy przestanie być rozwijane.

Wyłączone rozszerzenie nadal może pozostawać na serwerze

To ważne rozróżnienie. Wyłączenie pluginu lub modułu nie zawsze jest równoważne z usunięciem jego kodu. Jeśli rozszerzenie nie jest już używane, bezpieczniejszym rozwiązaniem jest zazwyczaj jego prawidłowa deinstalacja niż pozostawianie kolejnych nieaktywnych dodatków przez następne lata.

Mniejsza liczba niepotrzebnych elementów oznacza nie tylko mniejszą powierzchnię potencjalnego ataku, ale również prostsze aktualizacje, diagnostykę i utrzymanie strony.

Własny kod też jest rozszerzeniem systemu

W dużych serwisach część funkcjonalności powstaje indywidualnie. Wtedy bezpieczeństwo zależy również od jakości tego kodu. Joomla udostępnia mechanizmy pomocne między innymi w filtrowaniu danych, ochronie przed CSRF i bezpiecznej pracy z bazą danych, ale trzeba z nich prawidłowo korzystać.

Kod napisany wiele lat temu warto przy większej modernizacji przejrzeć ponownie. Fakt, że przez kilka lat nie spowodował widocznego problemu, nie jest dowodem jego bezpieczeństwa.

Warstwa 4 - użytkownicy i uprawnienia ACL

Joomla posiada rozbudowany system ACL, czyli kontroli dostępu. Pozwala określić, kto może wykonywać określone działania w serwisie. To jedna z funkcji, które nabierają szczególnego znaczenia w portalach obsługiwanych przez wiele osób.

Problem zaczyna się wtedy, gdy dla wygody prawie każdy pracownik otrzymuje najwyższy poziom dostępu.

Konto osoby, która tylko publikuje artykuły, nie powinno posiadać możliwości instalowania rozszerzeń, zmiany konfiguracji globalnej albo zarządzania innymi administratorami.

Zasada minimalnych uprawnień jest prosta: użytkownik powinien mieć dostęp do funkcji niezbędnych do wykonywania jego pracy - i nie więcej.

Dlaczego to ma znaczenie po przejęciu konta?

Jeżeli atakujący pozna dane logowania redaktora mającego ograniczone uprawnienia, zakres możliwych działań pozostaje ograniczony. Jeśli ten sam redaktor został dodany do grupy Super Users, przejęcie jego konta może oznaczać praktycznie pełną kontrolę administracyjną nad Joomla.

ACL nie zapobiega więc samemu przejęciu hasła. Ogranicza konsekwencje takiego zdarzenia.

Stare konta są łatwe do przeoczenia

W serwisie rozwijanym przez lata mogą pozostawać konta dawnych pracowników, wykonawców, programistów i administratorów. Dlatego okresowo warto przejrzeć użytkowników z dostępem administracyjnym i usunąć lub zablokować konta, które nie są już potrzebne.

Warstwa 5 - logowanie i uwierzytelnianie

Najlepiej zabezpieczony kod niewiele pomoże, jeśli osoba nieuprawniona zaloguje się jako rzeczywisty administrator. Dlatego ochrona kont uprzywilejowanych ma wyjątkowo duże znaczenie.

Joomla obsługuje uwierzytelnianie wieloskładnikowe. Po podaniu loginu i hasła użytkownik może zostać poproszony o dodatkową metodę potwierdzenia tożsamości. Dzięki temu samo poznanie hasła nie musi wystarczyć do zalogowania na konto.

W przypadku osób posiadających szerokie uprawnienia administracyjne MFA powinno być traktowane jako standardowa warstwa ochrony, a nie egzotyczny dodatek.

Długie i unikalne hasło nadal ma znaczenie

MFA nie uzasadnia używania tego samego hasła w kilku usługach. Dane uwierzytelniające do panelu Joomla powinny być unikalne, a osoby zarządzające większą liczbą kont powinny korzystać z bezpiecznego menedżera haseł.

Nie należy też współdzielić jednego konta administratora pomiędzy kilka osób. Osobne konta pozwalają odebrać dostęp konkretnej osobie bez zmieniania danych wszystkim pozostałym i ułatwiają ustalenie, kto wykonał daną operację.

Warstwa 6 - formularze i dane od użytkownika

Każde miejsce, w którym użytkownik może wysłać dane do strony, trzeba traktować jako granicę pomiędzy kodem aplikacji a informacją pochodzącą z zewnątrz. Dotyczy to nie tylko formularza kontaktowego.

Danymi wejściowymi są między innymi:

• pola formularzy,
• parametry URL,
• wyszukiwane frazy,
• komentarze,
• pliki przesyłane przez użytkowników,
• dane API,
• wartości przekazywane przez własne komponenty i moduły.

Dobra aplikacja nie zakłada, że dane przesłane przez użytkownika są poprawne tylko dlatego, że formularz w przeglądarce ogranicza możliwe wartości. Ograniczenia po stronie interfejsu można ominąć. Walidacja i filtrowanie muszą następować również po stronie serwera.

SQL injection, XSS i CSRF to różne problemy

Warto rozróżnić kilka często używanych pojęć. SQL injection dotyczy sytuacji, w której nieprawidłowo obsłużone dane wejściowe mogą wpłynąć na zapytanie do bazy. XSS polega na doprowadzeniu do wykonania niepożądanego kodu w kontekście strony użytkownika. CSRF wykorzystuje natomiast zalogowaną sesję użytkownika do wykonania operacji, której sam użytkownik świadomie nie zlecił.

Każdy z tych problemów wymaga innego mechanizmu ochronnego. Dlatego dodanie jednego filtra do formularza nie jest uniwersalnym zabezpieczeniem aplikacji.

Upload plików wymaga szczególnej ostrożności

Jeżeli użytkownik może przesłać plik na serwer, trzeba kontrolować między innymi jego typ, nazwę, sposób przechowywania oraz to, co serwer będzie mógł z tym plikiem później zrobić.

Mechanizm uploadu zaprojektowany dla zdjęć nie powinien w praktyce umożliwiać przesłania i wykonania dowolnego pliku zawierającego kod.

Warstwa 7 - kopia zapasowa, którą da się odtworzyć

Backup nie zapobiega włamaniu. Jest zabezpieczeniem przed jego konsekwencjami - podobnie jak przed awarią serwera, przypadkowym usunięciem danych czy nieudaną aktualizacją.

Problem polega na tym, że informacja "mamy backup" może oznaczać bardzo różne rzeczy.

Dobra strategia kopii odpowiada przynajmniej na cztery pytania:

• jak często kopia jest wykonywana,
• jak długo jest przechowywana,
• czy znajduje się również poza serwerem produkcyjnym,
• czy została kiedykolwiek skutecznie odtworzona.

Backup przechowywany wyłącznie obok strony może zniknąć razem z nią

Jeśli jedyna kopia znajduje się na tym samym koncie hostingowym co witryna, awaria lub przejęcie całego konta może dotknąć zarówno wersję produkcyjną, jak i jej backup.

Dlatego przynajmniej część kopii powinna być przechowywana niezależnie od środowiska produkcyjnego.

Nieprzetestowany backup jest tylko obietnicą

Można przez rok codziennie tworzyć archiwa i dopiero podczas awarii odkryć, że baza nie była kopiowana prawidłowo albo pliki są uszkodzone. Dopóki nie przeprowadzono testowego odtworzenia, nie wiadomo z pełną pewnością, czy kopia rzeczywiście pozwala odbudować serwis.

Test odtwarzania jest więc częścią systemu backupu, a nie dodatkową czynnością dla szczególnie ostrożnych administratorów.

Warstwa 8 - monitoring i reakcja na incydent

Bezpieczeństwo nie kończy się na zapobieganiu atakom. Trzeba również możliwie szybko zauważyć, że wydarzyło się coś nieprawidłowego.

Niepokojącymi sygnałami mogą być między innymi:

• nowe konto administratora, którego nikt nie tworzył,
• zmodyfikowane pliki systemowe,
• nagły wzrost wykorzystania CPU,
• wysyłanie dużej liczby wiadomości z serwera,
• przekierowania użytkowników do obcej domeny,
• nieznane zadania lub skrypty uruchamiane cyklicznie,
• nowe pliki PHP w katalogach, w których wcześniej ich nie było,
• ostrzeżenie przeglądarki lub wyszukiwarki dotyczące szkodliwej zawartości.

Nie każdy z tych objawów musi oznaczać włamanie, ale każdy zasługuje na wyjaśnienie.

Logi mogą powiedzieć więcej niż wygląd strony

Po incydencie bardzo ważne są logi serwera i aplikacji. Pozwalają ustalić, jakie żądania pojawiały się przed zmianą plików, z jakich adresów następowały logowania i które elementy strony były wywoływane.

Dlatego w przypadku podejrzenia włamania nie należy od razu kasować wszystkiego, co wygląda podejrzanie. Część informacji może być potrzebna do ustalenia sposobu wejścia.

Jak wygląda droga ataku na źle zabezpieczoną stronę?

Warto spojrzeć na bezpieczeństwo nie od strony administratora, lecz potencjalnego napastnika. Nie musi on znać firmy ani mieć osobistego powodu do ataku. Wiele prób jest wykonywanych automatycznie - skanery przeszukują ogromną liczbę domen w poszukiwaniu określonych wersji oprogramowania, plików lub charakterystycznych odpowiedzi serwera.

Przykładowy scenariusz może wyglądać następująco:

odnalezienie Joomla -> rozpoznanie rozszerzenia -> wykorzystanie podatności -> zapis pliku -> utrzymanie dostępu -> modyfikacja strony

Inna droga może być znacznie prostsza:

wyciek hasła z innej usługi -> użycie tego samego hasła w Joomla -> logowanie jako administrator

W drugim przypadku perfekcyjnie bezpieczny kod Joomla nie zostaje w ogóle zaatakowany. System poprawnie wpuszcza osobę podającą prawidłowe dane uwierzytelniające. Dopiero MFA lub dodatkowe ograniczenia konta mogą przerwać ten scenariusz.

Jeszcze inny przypadek:

podatny formularz -> manipulacja danymi wejściowymi -> wykorzystanie błędu własnego komponentu

Dlatego stwierdzenie "Joomla jest bezpieczna" albo "Joomla jest niebezpieczna" niewiele mówi o bezpieczeństwie konkretnej witryny. Trzeba oceniać cały system.

Strona Joomla została zhakowana - czy wystarczy usunąć złośliwy plik?

Nie. Usunięcie widocznego efektu ataku nie jest tym samym co usunięcie jego przyczyny.

Jeżeli na serwerze znaleziono złośliwy plik i administrator po prostu go kasuje, nie wiadomo jeszcze:

• jak plik znalazł się na serwerze,
• czy atakujący utworzył inne pliki,
• czy zmienił istniejący kod,
• czy utworzył nowe konto administratora,
• czy zmodyfikował bazę danych,
• czy pozyskał hasła albo inne dane dostępowe,
• czy pozostawił drugi mechanizm umożliwiający ponowne wejście.

Jeśli luka nadal istnieje, usunięty plik może pojawić się ponownie po kilku minutach, godzinach albo dniach.

Najpierw trzeba odpowiedzieć na pytanie "jak?"

Po wykryciu incydentu trzeba ustalić jego zasięg i możliwy punkt wejścia. Analizie podlegają między innymi wersje Joomla i rozszerzeń, konta użytkowników, zmiany plików, logi serwera, baza danych oraz dane dostępowe.

Dopiero później można przeprowadzić właściwe czyszczenie, usunąć podatność i zmienić dane uwierzytelniające.

Odtworzenie kopii również nie zawsze rozwiązuje problem

Przywrócenie backupu sprzed włamania może szybko odtworzyć poprawny wygląd witryny. Jeśli jednak przyczyną była podatna wersja komponentu, po odtworzeniu wracamy również do podatnego komponentu.

Dlatego właściwa kolejność zależy od konkretnego incydentu, ale zawsze trzeba uwzględnić zarówno odtworzenie czystego środowiska, jak i usunięcie drogi, którą doszło do naruszenia.

Które zabezpieczenia dają największy efekt?

Nie każda strona wymaga tego samego poziomu ochrony. Inaczej wygląda niewielka witryna informacyjna, inaczej portal z kilkunastoma redaktorami, a jeszcze inaczej serwis przetwarzający dane klientów.

Istnieje jednak zestaw działań, które w większości instalacji mają bardzo wysoki stosunek efektu do nakładu pracy:

Dopiero na takim fundamencie warto budować kolejne zabezpieczenia - filtrowanie ruchu, dodatkowe mechanizmy monitorowania, reguły WAF, alerty dotyczące zmian plików czy ograniczenia dostępu do wybranych części zaplecza.

Nie powinno się natomiast rozpoczynać od najbardziej efektownego narzędzia bezpieczeństwa, pozostawiając jednocześnie Joomla sprzed kilku lat, porzucone rozszerzenia i jedno wspólne konto administratora.

Bezpieczeństwo Joomla nie jest pojedynczą funkcją CMS. Jest sposobem utrzymywania całego serwisu. Aktualny rdzeń zamyka jedną grupę problemów, MFA chroni przed inną, ACL ogranicza konsekwencje przejęcia konta, prawidłowo napisany kod zabezpiecza dane wejściowe, a backup pozwala odzyskać system wtedy, gdy wcześniejsze bariery zawiodą.

Najbezpieczniejsza strona nie jest więc tą, na której zainstalowano najwięcej narzędzi ochronnych. Jest nią serwis, w którym wiadomo, jakie elementy działają, kto ma do nich dostęp, kiedy były aktualizowane, gdzie znajdują się kopie i co należy zrobić, jeśli pojawi się pierwszy sygnał incydentu.