Wydrukuj tę stronę

Postępowanie po włamaniu

Postępowanie po włamaniu
Oceń ten artykuł
(19 głosów)

Zdarzy Ci się niemal na pewno, że Twoja witryna zostanie uszkodzona w wyniku włamania lub na skutek innego zdarzenia. Ryzyko włamania można wprawdzie zmniejszyć, ale zupełnie go nie wyeliminujesz. Dlatego przygotuj się na tę okoliczność. Opracuj swój plan działania na wypadek awarii i poczyń odpowiednie przygotowania, aby w razie potrzeby można go zrealizować.

Plan minimum

Zacznij od planu minimum. Z czasem, bogatszy w wiedzę i doświadczenia, rozbudujesz go.

Na początek wystarczy, jeśli przyjmiesz, że lepszy jest jakikolwiek plan działania, niż żaden. A ponieważ nie znasz dnia ani godziny ataku, wiec dobrze być choć trochę przygotowanym już w momencie udostępnienia witryny w Internecie. W dalszej części artykułu przedstawiamy Ci scenariusz działań po włamaniu lub uszkodzeniu witryny wskutek innych niepomyślnych zdarzeń.

Typowa procedura postępowania po włamaniu

Twój plan odtwarzania witryny po awarii czy też przywracania sprawności uszkodzonej witryny powinien obejmować nie tylko działania po włamaniu, ale także działania w innych sytuacjach awaryjnych. Tutaj - dla czytelności instrukcji - skupimy się tylko na postępowaniu po włamaniu.

Oto przykładowy zestaw kroków, które należy podjąć po włamaniu do witryny, aby rozwiązać problem. Nie jest to ani najdoskonalsza, ani jedyna możliwa procedura. Swoje reakcje musisz dopasować do wydarzenia.

Bądź przygotowany

Oprócz planu działania, zawsze potrzebujesz minimum pięciu poniższych rzeczy:

  • aktualnych danych kontaktowych z firmą hostingową
  • aktualnych danych dostępowych do swojego konta na serwerze
  • gotowej strony HTML z komunikatem o chwilowym wyłączeniu witryny,
  • aktualnej kopii bezpieczeństwa
  • środowiska, w którym bez problemów odtworzysz uszkodzoną witrynę.

Informacje mają taką dziwną właściwość, że znikają akurat wtedy, gdy ich pilnie potrzebujemy. Sporządź i wydrukuj wizytówkę z danymi kontaktowymi do swojego usługodawcy. Zawieś ją na tablicy przy komputerze. Plik na wszelki wypadek umieść na pulpicie swojego komputera (w chwili ataku możesz przecież być np. w podróży służbowej). Ponadto - zachowaj kontakt z pełnymi danymi w swoim programie pocztowym.

Wybór sposobu bezpiecznego przechowywania danych dostępowych należy do Ciebie. Na pewno nie jest dobrym pomysłem wydrukowanie ich i wywieszenie na tablicy informacyjnej w firmie. Tablica w Twoim pokoju w firmie też nie jest dobrym pomysłem.

Zanotuj dane dostępowe do panelu klienta (CPanel, Plesko itp.), do konta FTP, do bazy danych i - oczywiście - do witryny, choć w tym przypadku spotka Cię czasem przykra niespodzianka - napastnik może te dane zmienić. Nie polegaj zbytnio na tym, że dane dostępowe do FTP i bazy danych odczytasz w razie potrzeby za pomocą narzędzi w panelu klienta. Tam też możesz nie uzyskać dostępu (wystarczy, że zestresowany będziesz konsekwentne mylić jeden znak w haśle).

Przygotowanie prostego pliku index.html z logo witryny i zwięzłym komunikatem typu: „Witryna chwilowo wyłączona. Trwają prace konserwacyjne. Zapraszamy wkrótce!” nie powinno Ci sprawić kłopotu. Kopię tego pliku możesz przechowywać na serwerze pod zmienioną nazwą. W razie potrzeby po prostu zmienisz nazwę.

Kilka lat temu sporządzanie kopii zapasowych wymagało sporych zabiegów. Dziś może to być operacja banalnie prosta. Wystarczy, że posłużysz się rozszerzeniem AkeebaBackup lub XCloner. Sporządzanie kopii zapasowych możesz nawet zautomatyzować tak, że nie trzeba będzie wykonywać prawie żadnych związanych z nimi czynności. Prawie żadnych, bo... niesprawdzona kopia jest warta tyle, co brak kopii. Kopię trzeba więc np. co najmniej raz w tygodniu pobrać na swój komputer i przetestować, odtwarzając z niej witrynę w lokalnym środowisku testowym.

Najpewniejszym bezproblemowym środowiskiem do odtwarzania uszkodzonej witryny jest... własny komputer i zainstalowane w nim oprogramowanie lokalnego serwera internetowego, np. JAMP, LAMP, MAMP czy XAMPP. Poradniki, jak stworzyć lokalny serwer testowy, znajdziesz w naszej Elektronicznej Bibliotece Dokumentacji Joomla.

Zachowuj się profesjonalnie

Przede wszystkim - nie panikuj, zachowaj spokój, aby nie popełnić trudnych do naprawienia błędów. Skoro się już stało, to trzeba skupić się na przywróceniu witryny do działania, usunięciu skutków włamania oraz przeciwdziałaniu ponownym napaściom. Zdaj sobie sprawę, że nie jesteś ani pierwszym, ani jedynym, ani ostatnim administratorem, któremu trafia się taka przypadłość. Jeśli wcześniej uczyniłeś wszystko, co było w Twojej mocy, aby uchronić witrynę przed włamaniem, to nie masz sobie nic do zarzucenia. A jeśli nie uczyniłeś? No cóż, masz szansę, nauczony przykrym doświadczeniem, zastosować się do przysłowia o Polaku mądrym po szkodzie.

Jeśli sądzisz, że Twoja witryna została zaatakowana, nie twórz kolejnego, nikomu niepotrzebnego, nudnego powiadomienia na forum pod tytułem „Pomocy! Zostałem zhakowany”. Taka wiadomość nie mówi niczego istotnego. Zaatakowane witryny w ogromnej większości albo były źle skonfigurowane, albo działały na przestarzałych wydaniach, albo korzystały z rozszerzeń podatnych na włamania. To są rzeczy, które musisz najpierw zbadać. Postem na forum co najwyżej przedstawiasz się społeczności jako niekompetentny i niezbyt odpowiedzialny administrator.

Jeżeli odkryjesz rzeczywistą podatność Joomla! na włamanie, tym bardziej nie rozgłaszaj o tym wiadomości, by nie zaszkodzić innym witrynom. Zamiast wiadomości na forum, przekaż informację Zespołowi ds. bezpieczeństwa przy Centrum Projektu Joomla!.

Zablokuj dostęp do witryny

Zrób to z dwóch powodów. Po pierwsze, aby nie kompromitować witryny w oczach odwiedzających i nie narazić jej na zablokowanie przez wyszukiwarki. Po drugie, aby nie narażać innych użytkowników Internetu na rozprzestrzenianie złośliwego oprogramowania.

Jak to zrobić? Wykonaj dwa działania:

  1. umieść w głównym katalogu witryny plik index.html z komunikatem o przerwie technicznej
  2. wyłącz dostępność witryny w Konfiguracji globalnej witryny lub w pliku configuration.php.

Jeśli nie masz przygotowanej strony HTML z komunikatem o chwilowym wyłączeniu witryny, możesz umieścić po prostu pusty plik nazwany index.html.

Umieszczenie pustego pliku index.html w głównym katalogu witryny spowoduje wyświetlanie białej strony. Oczywiście, lepiej, żeby ta strona zawierała komunikat informujący odwiedzających, że strona będzie przez jakiś czas niedostępna.

Operacja ta nie uchroni jednak od wywoływania innych niż główna strona witryny. Dlatego, niezależnie od tego kroku, trzeba wyłączyć witrynę w Konfiguracji globalnej lub - gdy niemożliwe jest zalogowanie się do zaplecza - poprzez zmianę w pliku configurtion.php.

Aby wyłączyć dostępność witryny, zaloguj się do zaplecza, wejdź na stronę Konfiguracja globalna (skorzystaj z ikony skrótu) i ustaw Tak dla opcji Witryna wyłączona.

Jeśli zalogowanie się do zaplecza jest niemożliwe, zaloguj się na swoje konto FTP, pobierz plik configurtion.php na swój komputer, otwórz go do edycji i dokonaj zmiany:

  • w Joomla 1.5 wiersza var $offline = '0'; na var $offline = '1';,
  • w Joomla 2.5 - 3.x wiersza public $offline = '0'; na public $offline = '1';.

Uwaga: Jeśli masz inne witryny opublikowane w subdomenach i umieszczone w podkatalogach, należy zablokować dostęp do każdej z nich.

Powiadom o incydencie zainteresowanych

O incydencie powinni być poinformowani co najmniej:

  • wydawca witryny - szefostwo firmy,
  • osoba odpowiedzialna w firmie za bezpieczeństwo systemu informatycznego,
  • firma hostingowa,
  • użytkownicy witryny.

Po zawiadomieniu szefostwa firmy i osoby odpowiedzialnej za bezpieczeństwo systemu informatycznego w firmie, skontaktuj się najszybciej jak to możliwe z technikiem dyżurnym w firmie hostingowej, aby mogła przeciwdziałać działaniom napastnika, które ten może podjąć wobec innych witryn, a także, aby uzyskać niezbędną pomoc w usuwaniu skutków włamania. Przekaż wszystkie informacje o włamaniu, jego objawach i skutkach, jakie udało Ci się do momentu powiadomienia ustalić.

Jeśli pracownik odbierający powiadomienie zignoruje je, nie wahaj się żądać kontaktu z jego przełożonym. Włamanie do witryny jest istotnym incydentem na serwerze i nie może być przez obsługę serwera ignorowane. Twoja witryna mogła zostać zaatakowana z innego konta na serwerze podatnego na włamania.

Powiadom użytkowników

To, niestety, dość często pomijany etap procedury postępowania po włamaniu. Jeśli administrujesz popularną witryną, albo witryną, która służy transakcjom z użytkownikami, czy choćby witryną, która umożliwia użytkownikom rejestrację i gromadzi jakieś ich dane, nie zwlekaj z powiadomieniem ich o incydencie i wynikających z niego zagrożeniach. Jeśli przypuszczasz, że zostały wykradzione wrażliwe dane, masz o wiele większą szansę na odzyskanie ich zaufania, jeśli otrzymają informację o wycieku danych od Ciebie.

Powiadomienie wyślij pocztą elektroniczną. Nie musisz ujawniać szczegółów incydentu. Przekażesz zwięzłą informację, że w wyniku włamania została naruszona integralność bazy danych oraz że trwają prace nad przywróceniem sprawności witryny i wdrożeniem dodatkowych zabezpieczeń. Nie od rzeczy będzie też zamieszczenie wskazówki, by użytkownicy, którzy stosują takie same loginy i hasła w innych witrynach, dokonali pilnie ich zmiany.

Przygotuj informację dla mediów

Jeśli Twoja witryna jest popularna, musisz się liczyć również z zainteresowaniem mediów. Przygotuj się więc zawczasu na przekazanie odpowiednich informacji czy komunikatu. Może nawet warto przećwiczyć odpowiedzi na prawdopodobne pytania? Media mogą być zainteresowane, kto dokonał włamania, kiedy to się stało, jakie luki w systemie zostały wykorzystane, czy włamanie nastąpiło na wskutek zaniedbań i kto ponosi za nie odpowiedzialność, jakie szkody poczynił napastnik, czy i jakie dane użytkowników zostały ujawnione, jakie kroki zostały podjęte, aby ograniczyć skutki ataku, jakie podjęto kroki, aby zapobiec podobnym zdarzeniom w przyszłości.

Na większość z tych i podobnych pytań należy odpowiadać rzetelnie, co nie znaczy, że należy ujawniać wszystkie znane informacje. Jeśli zbyt dokładnie opiszesz sposób przeprowadzenia włamania, możesz niepotrzebnie lub przedwcześnie ujawnić słabe punkty zabezpieczeń.

Zmień wszystkie dane dostępowe

Podczas ataku napastnik prawdopodobnie poznał dane dostępowe do zasobów witryny. Zmień je więc czym prędzej.

Zacznij od konta FTP. Zaloguj się do panelu zarządzania Twoim kontem na serwerze (CPanel, Plesk, itp.) i zmień swoje hasło dostępu do FTP. Jeśli utworzyłeś wcześniej więcej kont FTP dla swoich współpracowników, wyłącz albo najlepiej usuń wszystkie, bez których można się tymczasem obejść. W pozostałych zmień hasła dostępu.

Następnie zmień hasła dostępu do bazy danych. Jeśli masz więcej baz danych, np. obsługujących witryny w subdomenach, również pozmieniaj do nich hasła dostępu. (Pamiętaj jednak, że zmiana haseł dostępu unieruchomi te witryny, dopóty nie dokonasz stosownych zmian w ich konfiguracji.) Te witryny również należy być może zablokować do momentu, aż będziesz mieć pewność, że działają poprawnie i są bezpieczne. Taką decyzję trzeba jednak podejmować bardzo rozważnie.

Na koniec zaloguj się do zaplecza witryny Joomla i:

  1. zablokuj wszystkie konta z prawami logowania do zaplecza, a więc konta wszystkich operatorów, administratorów i superużytkowników poza własnym i ewentualnie osób, z którymi będziesz usuwać skutki włamania,
  2. zmień hasła we wszystkich pozostawionych kontach administracyjnych.

Zgromadź i zabezpiecz dokumentację włamania

Na dokumentację składają się pliki dzienników oraz kopia uszkodzonej witryny.

Dokumentacja jest Ci potrzebna do zbadania, w jaki sposób napastnik dokonał włamania oraz zbadania skutków włamania. Ponadto może stanowić dowody dla policji i prokuratury, jeżeli zdecydujesz się złożyć doniesienie o włamaniu.

Dokumentację włamania powinieneś utworzyć, zanim poczynisz jakiekolwiek inne działania na serwerze (poza wyłączeniem witryny i zmianą danych dostępowych).

  1. Skopiuj pliki dziennika i usuń je z serwera. Skopiowane pliki zapisz na nośniku służącym tylko do odczytu, np. na płycie CD).
  2. Wykonaj kopię uszkodzonej witryny. Jeśli to możliwe, skorzystaj z rozszerzenia typu AkeebaBackup czy XCloner. Jeśli nie, wykonaj kopię ręcznie - skopiuj system plików i wykonaj zrzut bazy danych. Odtwórz witrynę na serwerze testowym, aby przeprowadzić niezbędne badania i analizy. Pamiętaj, aby zachować plik kopii. W postępowaniu wyjaśniającym może być konieczne kilkakrotne odtworzenie uszkodzonej witryny.

Oceń skutki ataku

Zanim przystąpisz do naprawiania lub odtwarzania witryny, przeprowadź wstępne rozpoznanie, oceń skutki ataku i oszacuj czas potrzebny na naprawę, aby wybrać adekwatną ścieżkę postępowania. W wyniku wstępnego rozpoznania powinieneś sobie odpowiedzieć na pytanie, czy witryna zostanie wyłączona do momentu wykrycia i usunięcia wszystkich przyczyn i skutków ataku, czy też tymczasowo zostanie odtworzona z dobrej kopii zapasowej, a dalsze kroki będą zależeć od wyników dokładnego zbadania incydentu.

  1. Dokonaj dokładnego przeglądu witryny, by odkryć, co zostało zmienione lub usunięte,
  2. Przejrzyj zaplecze, sprawdź, czy funkcjonuje poprawnie,
  3. Sprawdź w wykazie kont użytkowników, czy nie zostały założone nowe konta superużytkowników lub administratorów.
  4. Sprawdź, czy na listach poziomów dostępu i grup użytkowników nie pojawiły się nowe podejrzane pozycje,
  5. Szczególnie starannie przejrzyj konfigurację globalną poszczególnych grup użytkowników, upewnij się, że nie zostały zmodyfikowane ich uprawnienia,
  6. Ustal, czy napastnik dodał lub zmodyfikował pliki. Sporządź listę ostatnio dodanych i zmodyfikowanych plików, a następnie zbadaj wszystkie podejrzane pliki.
  7. Przejrzyj pliki dziennika - może uda się szybko znaleźć ślady czynności napastnika i ustalić sposób włamania.
  8. Upewnij się, że na serwerze nie ma złośliwego oprogramowania - rootkitów, wirusów, itp.
  9. Zbadaj zrzut bazy danych

Pierwszymi sygnałami awarii w witrynie są zwykle niespodziewane zmiany w witrynie lub na zapleczu. Przeglądając witrynę i zaplecze, zbadaj, jak rozległe są skutki awarii i spisz, co wymaga naprawy. Oczywiście, możesz polegać na własnej pamięci, jeśli sa to 2-3 zmiany, ale jeśli będzie ich więcej, lepiej każdą zanotować, by potem sprawdzić, czy wszystkie zostały usunięte.

Dokonując tego przeglądu, pamiętaj, że zaobserwowane objawy niekoniecznie muszą być skutkami włamania. Mogło się wszak zdarzyć, że uszkodzenie nastąpiło w wyniku innych zdarzeń, np. zmiany konfiguracji serwera. Od oceny, czy rzeczywiście są efektami włamania, będzie zależało dalsze postępowanie.

Jeśli ze wstępnego oglądu wynika, że masz do czynienia z włamaniem, wykonaj czynności określone powyżej w punktach od 3 do 8.

Sprawdź listy kontroli dostępu

Jeśli napastnik uzyskał dostęp do bazy danych, mógł założyć sobie konto administratora czy superużytkownika albo przejąć jedno z istniejących kont. W witrynach opartych na Joomla 2.5 i nowszych napastnik mógł zmodyfikować konfigurację poziomów dostępu, gdup użytkowników i ich uprawnień.

Sprawdź to. Zwróć uwagę na daty ostatnich wizyt administratorów i superadministratorów. Upewnij się, że to oni, a nie ktoś inny, wykonywali na zapleczu jakieś czynności w odnotowanym czasie. Uważnie przejrzyj listę poziomów dostępu, listę grup użytkowników i globalną konfigurację uprawnień. Zwróć uwagę nie tylko na uprawnienia administratorów i superadministratorów. Napastnik mógł nadać wszelkie możliwe uprawnienia każdej grupie użytkownikom, np. grupie Goście.

Zbadaj wszystkie podejrzane pliki

Jeśli nie masz zainstalowanego rozszerzenia monitorującego zmiany w plikach albo zostało ono uszkodzone, skorzystaj ze skryptu wypier.zip, za pomocą którego wygenerujesz listę ostatnio dodanych i zmodyfikowanych plików. Wyodrębnij z paczki plik wypier.php i prześlij go na serwer do głównego katalogu, a następnie uruchom, wywołując w przeglądarce adres: http://twoja_domena.pl/wypier.php. Po stworzeniu listy usuń ten plik z serwera!

Pliki podejrzane to te spośród ostatnio zmodyfikowanych lub dodanych, które prawdopodobnie nie zostały zmienione lub dodane w wyniku typowych działań administracyjnych.

Podejrzane są więc wszystkie pliki w domyślnych katalogach Joomla, które zostały zmienione po ostatnio dokonywanej aktualizacji oprogramowania. Podejrzane są wszystkie pliki dodane do standardowych katalogów Joomla później, niż zostały zainstalowane. Oczywiście, mogły one być dodane w wyniku aktualizacji oprogramowania, ale trzeba to sprawdzić.

Szczególnie dokładnie przejrzyj katalogi, do których przesyłane są grafiki, pliki multimedialne i różne dokumenty (foldery w katalogach /images i /media).

Sprawdź logi serwera

Jeśli dzienniki zdarzeń przechowywane są w bezpiecznej lokalizacji, do której napastnik nie miał dostępu, można będzie z nich odczytać, kiedy, gdzie i w jaki sposób napastnik zdobył dostęp do Twojej witryny, jakie luki wykorzystał. Nawet jeśli nie masz żadnego doświadczenia w czytaniu logów, przejrzyj je. Najpewniej w ciągu kilku minut nauczysz się je czytać. Są to pliki tekstowe. Każde zdarzenie odnotowane jest w jednym wierszu (akapicie). Zwykle mają standardowy format CLF (Commomn Log Format). Oto przykładowy wpis:

127.0.0.1 - - [12/Oct/2012:23:47:26 +0200] "GET /phpinfo/index.php?=PHPE9568F34-D428-11d2-A769-00AA001ACF42 HTTP/1.1" 200 2524

W kolejności od lewej mamy tu następujące informacje: IP serwera zgłaszającego żądanie, prawie zawsze puste zastępniki (- -), data i czas zgłoszenia żądania według uniwersalnego czasu koordynowanego(UTC), plik lub inny zasób żądany od serwera (to pole składa się z trzech sekcji - metody, zasobu i protokołu), kod stanu HTTP, rozmiar przesłanego pliku.

Przeskanuj witrynę

Aby upewnić się, że na serwerze nie ma złośliwego oprogramowania, skorzystaj ze skanerów dostępnych w sieci, np.:

Zbadaj zrzut bazy danych

Mniej doświadczeni napastnicy próbują zainfekować tylko skrypty witryny, rzadko kiedy psują bazy danych. Niestety, skutecznych włamań dokonują wytrawni fachowcy. Nie możesz więc wykluczyć, a wręcz powinieneś zakładać, że przypuścili także atak na bazę danych Twojej witryny. Ich celem mogła być kradzież danych - wówczas raczej nie zobaczysz żadnych śladów, ale także zainfekowanie bazy złośliwym kodem.

Zapewne wiesz, że plik kopii bazy danych to zwykły plik tekstowy. Przejrzenie pliku i wykrycie ewentualnego złośliwego kodu nie powinno być zadaniem ponad siły. Wystarczy zwykły notatnik i przeglądanie strona po stronie. Aby się upewnić, że niczego nie przegapisz, posłuż się wyszukiwarką - znajdź i skontroluj wpisy zawierające słowa „script”, „applet”, „iframe”, „object”. Upewnij się, że wpisy z tym kodem zostały dodane przez administratorów witryny, a jeśli nie masz 100-procentowej pewności, że tak było - usuń je.

Usuń uszkodzoną witrynę z głównego katalogu domeny

Jeżeli ze wstępnego rozpoznania wynika, że witryna uległa poważnym uszkodzeniom albo też że trudno jest oszacować, jak poważne są uszkodzenia, zdecyduj o usunięciu uszkodzonej witryny z serwera i odtworzeniu jej z ostatniej dobrej kopii zapasowej. Uszkodzoną witrynę możesz też przenieść tymczasowo do innego katalogu poza głównym katalogiem domeny.

Wielu administratorów podejmuje próbę naprawienia uszkodzonej witryny. Ale decydując się na takie rozwiązanie w przypadku, gdy uszkodzenia są poważne albo nie jesteś ich w stanie w pełni oszacować, sporo ryzykujesz.

Prawdopodobnie nie będziesz w stanie określić w miarę precyzyjnie, jak długo potrwa naprawianie uszkodzeń. Może się więc zdarzyć, że zamiast planowanej godzinnej czy dwugodzinnej przerwy witryna będzie niedostępna znacznie dłużej, niż jesteś to w stanie zaakceptować (albo Twoje szefostwo).

Po wtóre, dopóki nie ustalisz dokładnie, w jaki sposób napastnik dokonał włamania oraz jakie poczynił szkody, nie będziesz mieć pewności, że rezultatem naprawy widocznych uszkodzeń będzie także usunięcie wszystkich luk w systemie i ewentualnych „tylnych furtek”, ukrytych przez napastnika. A to grozi ponownym skutecznym atakiem, być może poważniejszym w skutkach, a na pewno podważającym i tak już naruszone zaufanie do witryny.

Tylko wówczas, gdy nie posiadasz sprawdzonej, w miarę aktualnej i nieuszkodzonej kopii witryny, możesz być zmuszony ponieść opisane przed chwilą ryzyko.

Jeśli jednak dysponujesz kopią witryny, której można użyć do jej odtworzenia, zrób to. Nawet jeśli witryna nie będzie w pełni aktualna, jest to niewątpliwie rozsądniejsze, niż narażenie się na kolejną kompromitację albo zbyt długo trwającą przerwę techniczną.

Ważne: Po tym, gdy Twoje konto zostało zaatakowane, istnieje wielkie prawdopodobieństwo że intruz zostawił sobie wejście do Twojej strony, by znów w łatwy sposób się na nią włamać. Dlatego samo nadpisywanie i poprawianie plików może być nieskuteczne.

Znalezienie tylnego wejścia, które mógł pozostawić napastnik, jest bardzo czasochłonne i wymaga sporej wiedzy, za którą profesjonaliści każą sobie słono płacić. Dlatego zwłaszcza mało doświadczeni administratorzy nie powinni ryzykować pozostawiania uszkodzonej witryny na serwerze. Bezpieczniej jest odtworzyć witrynę z dobrej kopii lub przeinstalować ją.

Napraw uszkodzoną witrynę

Procedura postępowania naprawczego zależy od oceny skutków ataku, oceny stopnia zagrożenia ponownym atakiem, a także szacowanego czasu i innych kosztów naprawy.

Zdecyduj się na jedną z poniższych ścieżek:

  • ścieżka I: usuń pliki dodane przez włamywacza, a pliki zmienione zastąp oryginalnymi z kopii zapasowej,
  • ścieżka II: odtwórz witrynę z ostatniej dobrej kopii bezpieczeństwa, wykonanej przed odkryciem incydentu,
  • ścieżka III: przeinstaluj witrynę, korzystając z najnowszych wersji instalacyjnych zarówno Joomla!, jak i rozszerzeń.

Pierwsza, najmniej inwazyjna ścieżka będzie skuteczna pod jednym warunkiem - że odkryjesz lukę, która umożliwiła napastnikowi umieszczenie na serwerze szkodliwych plików, oraz wykryjesz wszystkie pliki dodane lub zmodyfikowane przez napastnika.

Jeśli napastnik uzyskał nieuprawniony dostęp do serwera poprzez lukę w którymś z rozszerzeń Joomla, należy je przeinstalować, zastępując poprawioną bezpieczną wersją, albo odinstalować.

Jeśli napastnik dostał się na serwer, korzystając z podsłuchanych, wykradzionych czy rozszyfrowanych danych dostępowych, przed ponownym włamaniem uchroni Cię zmiana haseł na odpowiednio silne.

Jeśli napastnik dostał się na Twoje konto z innego zhakowanego konta na serwerze współdzielonym, problem trzeba rozwiązać we współpracy z dostawcą hostingu. Rozważ przy tym, czy chcesz ryzykować w przyszłości - nie masz bowiem żadnej gwarancji, że sytuacja się nie powtórzy.

Korzystając z listy ostatnio zmodyfikowanych lub dodanych plików usuwamy pliki, które na pewno nie należą do systemu plików witryny, a wiec zostały umieszczone na serwerze przez włamywacza, oraz podmieniamy wszystkie pliki ostatnio zmienione.

Druga metoda będzie skuteczna tylko wówczas, gdy dysponujesz nieuszkodzoną kopią bezpieczeństwa witryny. Jest to najkrótsza, a tym samym bardzo atrakcyjna ścieżka. W ciągu kilku minut jesteśmy w stanie uzyskać działającą witrynę. Ale niejeden już administrator miał przykrą okazję przekonać się, że jego bezpieczna nieuszkodzona kopia tylko sprawiała wrażenie bezpiecznej i nieuszkodzonej. Napastnicy często przygotowują atak bez pośpiechu, przez wiele miesięcy.

Zastosuj tę metodę jedynie wówczas, gdy masz 100-procentową pewność, że dysponujesz rzeczywiście bezpieczną i nieuszkodzoną kopią witryny. A dopóki nie rozpoznasz precyzyjnie, w jaki sposób zostało dokonane włamanie, nie możesz mieć takiej pewności.

Trzecia ścieżka może wydawać się czaso- i pracochłonna, ale w praktyce okazuje się najbardziej efektywną, zwłaszcza w przypadku gdy nie mamy pewności, kiedy i w jaki sposób napastnik dokonał włamania.

Stosując tę metodę, zyskujemy pewność:

  • że w systemie plików nie ma niewykrytych skryptów pozostawionych przez napastnika,
  • że użyte pakiety instalacyjne są najnowsze i bezpieczne (oczywiście, jeśli tylko takie zainstalujemy).

Do odtwarzanej witryny będziesz zapewne przenosić pliki graficzne z uszkodzonej witryny. Trzeba je kopiować plik po pliku i dokładnie przejrzeć oraz sprawdzić oprogramowaniem antywirusowym, aby przypadkiem nie przenieść do nowej witryny plików zawierających złośliwy kod albo skryptów, które otwierają napastnikowi „tylne drzwi”.

Zbadaj uszkodzoną witrynę i napraw luki, które umożliwiły włamanie

Wykrycie, w jaki sposób zostało dokonane włamanie, odnalezienie w systemie luk, które wykorzystał napastnik, wymaga na pewno kompetencji oraz sporego nakładu czasu i pracy. Jakkolwiek małe byłoby Twoje doświadczenie, nie możesz pominąć tego etapu. Twoja witryna nie będzie dopóty bezpieczna, dopóki nie usuniesz podstawowej przyczyny włamania. A nie jest nią, niestety, przestępcze działanie intruza, ale luka bądź luki w systemie, które pozwoliły włamywaczowi osiągnąć zamierzony skutek.

Przeanalizuj typowe przyczyny

Zacznij od przeanalizowania typowych przyczyn. Odpowiedz sobie na pytania:

  • Czy Twoja witryna obsługiwana jest przez najnowsze wydanie Joomla w wersji wspieranej długoczasowo (LTS) lub przejściowo (STS)?
  • Czy wszystkie dodatkowo zainstalowane rozszerzenia są na pewno bezpieczne? Czy któreś z nich nie znajduje się przypadkiem na liście rozszerzeń podanych na uszkodzenia?
  • Czy z witryny zostały usunięte wszystkie nieużywane instalacje szablonów, dodatków i innych rozszerzeń?
  • Czy korzystasz z bezpiecznego serwera? Czy na serwerze zainstalowano zalecane bezpieczne wersje oprogramowania? Czy w ustawieniach serwera zostały wyłączone wszystkie niezalecane, potencjalnie niebezpieczne ustawienia?
  • Czy należycie chroniony jest dostęp do serwera i witryny - czy stosowane są silne hasła?, czy dostęp do kont FTP ograniczony jest do niezbędnego minimum?, czy ustawienia programu FTP są bezpieczne (np., czy hasło dostępu jest szyfrowane?)
  • Czy uprawnienia do plików i katalogów na serwerze są zgodne z zalecanymi (odpowiednio 0644 i 0755)?

Naprawdę, nie trzeba być ani wykształconym informatykiem, ani tym bardziej specjalistą od bezpieczeństwa, by stwierdzić, że któreś z powyższych warunków nie zostały dochowane i wymagają zmiany.

Zbadaj pliki dzienników

Pewnej odpowiedzi na pytania, kiedy i w jaki sposób intruz przeprowadził skuteczny atak, mogą udzielić pliki dzienników. Oczywiście, tylko wówczas, gdy nie zostały uszkodzone.

Pliki dzienników mogą być tak obszerne, że znalezienie niepokojących wpisów będzie sporym wyzwaniem. Zacznij więc od sprawdzenia, czy napastnik nie wykorzystał znanych luk w Joomla! (jeśli używasz lub używałeś przez jakiś czas przestarzałej wersji) albo rozszerzeniach zainstalowanych w witrynie. Jeśli napastnik umieścił lub zmodyfikował jakieś pliki na serwerze, możesz - korzystając z nazw tych plików odszukać je w logach i dociec na podstawie wpisów w dzienniku, z jakiego IP zostały przesłane, a następnie poddać analizie wszystkie żądania z tego IP.

Do analizy dzienników serwera nie są konieczne specjalne narzędzia. Wystarczy zwykły Notatnik. Jeśli jednak chcesz posłużyć się pomocnymi narzędziami graficznymi, zapoznaj się z projektami:

Napraw wykryte luki

Gdy wykryjesz luki, jakie wykorzystał napastnik, doprowadź do ich wyeliminowania - uaktualnij oprogramowanie, odinstaluj oprogramowanie podatne na uszkodzenia albo popraw je, jeśli potrafisz. Jeżeli stwierdzisz, że przyczyną były luki w oprogramowaniu lub konfiguracji serwera, rozważ zmianę hostingodawcy. Trudno bowiem ufać usługodawcy, który naraził witrynę na kompromitację i straty finansowe (nawet, jeśli to jest tylko czas stracony na naprawę). Jeśli witryna była zawirusowana, spowoduj, aby wszyscy operatorzy, którzy dysponują nieco większym dostępem, niż dostęp zwykłego użytkownika, zbadali i wyczyścili swoje komputery. Istnieje duże prawdopodobieństwo, że są zawirusowane i mogą się stać narzędziem ponownego uszkodzenia witryny.

Przejrzyj i popraw zabezpieczenia

Nie pocieszaj się opinią, że każdy może być skutecznie zaatakowany. Fakt, że integralność Twojej witryny została naruszona, powinien Cię skłonić do ponownego przeanalizowania stosowanych zabezpieczeń i ich udoskonalenia. Między innymi:

  • Przejrzyj jeszcze raz informacje o konfiguracji systemu i sprawdź, czy zastosowano zalecane bezpieczne ustawienia.
  • Sprawdź, czy został włączony plik .htaccess (na serwerach Apache) lub web.config na serwerach IIS 7 (oba pliki, obok funkcji związanych z translacją adresów, zabezpieczają witryny przed niektórymi popularnymi atakami).
  • Upewnij się, że wszystkie katalogi i pliki mają bezpieczne uprawnienia (0755 i 0644).
  • Upewnij się, że nie ma na serwerze żadnych zbędnych plików i katalogów, np. z nieużywanymi szablonami
  • Jeśli dotychczas nie stosowałeś rozszerzeń poprawiających bezpieczeństwo, rozważ instalację i konfigurację komponentu AdminTools czy RSFirewall lub podobnych.

Plan odtwarzania witryny po awarii a polityka zarządzania incydentami

Skoro już wiesz, że lepszy jest jakikolwiek plan działania na wypadek awarii niż żaden, to możemy teraz nieco „zamieszać”, by przygotować Cię na podjęcie większego wysiłku, w wyniku którego z czasem będziesz dysponować polityką zarządzania incydentami. Słowo „incydent” oznacza tutaj wypadki związane z bezpieczeństwem, np. włamania (ale nie tylko). Politykę zarządzania incydentami trzeba ściśle dostosować do planu działań na wypadek awarii, choć każdy z tych planów to coś innego.

Jak obszerna i dokładna będzie Twoja polityka zarządzania incydentami, zależy od potrzeb Twojej firmy, znaczenia i wartości, jaką dla Ciebie czy firmy stanowi witryna, a także doświadczenia, które z czasem w naturalny sposób będzie coraz większe. Tom Canavan w książce „Joomla! Zabezpieczanie witryn” wydanej przez Helion w 2010 roku, pisze, że niezależnie od możliwości firmy w Polityce reagowania na incydenty trzeba ująć następujące elementy:

  • deklaracje zaangażowania zarządu
  • cele realizowane dzięki polityce
  • zakres polityki (kogo, w jakim zakresie i w jakich warunkach dotyczy plan)
  • definicja incydentów z zakresu bezpieczeństwa komputerów i opis ich konsekwencji dla firmy
  • struktura organizacyjna i opis ról, obowiązków oraz uprawnień związanych z obsługą incydentów
  • skala priorytetów i ważności incydentów
  • miary wydajności
  • formularze zgłoszeniowe i kontaktowe

Tę obszerną listę elementów Tom Canavan opatruje komentarzem:

Na pierwszy rzut oka wydaje się, że takie plany dla opartych na Joomla! witryn to przesada. Rzeczywiście, czasem tak jest. Jeśli jednak serwis jest dla organizacji źródłem dochodów, zalecam oszacowanie ich dla okresu 5 lat. Oceń, czy utrata tych zysków (ze względu na brak możliwości naprawienia szkód) nie będzie większa niż poświęcenie czasu na przemyślenie i zrealizowanie wymienionych elementów.

Decyzje i ich realizacja - w Twoich rękach.

Ostatnio zmieniany Pn. 27 Maj 2019
comments powered by Disqus

Najnowsze od Stefan Wajda