Spis treści
Zlokalizowanie plików wykonywalnych (przeważnie PHP) z podejrzaną zawartością
Poniższy poradnik jest ogólnikowy. Zobacz rozbudowany artykuł dotyczący usuwania wirusów ze strony opartej o CMS WordPress: http://linuxporady.pl/procedura-usuwania-wirusow-ze-strony-opartej-o-system-cms-wordpress/
Przydatne w wyszukiwaniu takich plików mogą być polecenia SSH:
|
1 |
find . -name "*.php" -type f -perm 600 -print0 | xargs -0 grep -iHlnrE 'filesman|eval.*base64_decode|PCT4BA6ODSE|globals' 2> /dev/null |
lub
|
1 |
grep -Hilr 'function.*strlen.*isset' . 2> /dev/null ; grep -iHlnr -E 'filesman|eval.*base64_decode' * 2> /dev/null |
Każdy znaleziony w ten sposób plik musi być przepatrzony pod kątem występowania potencjalnych zagrożeń.
Najlepiej wpisać wyniki do pliku:
|
1 |
find . -name "*.php" -type f -perm 600 -print0 | xargs -0 grep -iHlnrE 'filesman|eval.*base64_decode|PCT4BA6ODSE|globals' 2> /dev/null > lista.txt |
lub
|
1 |
grep -Hilr 'function.*strlen.*isset' . 2> /dev/null ; grep -iHlnr -E 'filesman|eval.*base64_decode' * 2> /dev/null > lista.txt |
I wtedy je po kolei przeglądać.
Dodatkowo możemy użyć wyrażeń regularnych celem znalezienia plików PHP z podejrzaną zawartością – gdzie kod jet zaciemniony poprzez zapis przy użyciu hexów:
|
1 |
/\\x\d{1,3}/g |
Porównanie aktualnej zawartości plików strony z domyślnym systemem CMS o tej samej wersji
Jest to dość pomocna czynność. Przypuśćmy, że mamy stronę opartą o wersję Joomla_3.0.3-Stable-Full_Package. Ściągamy z internetu wersję instalacyjną tego oprogramowania. Następnie poprzez systemy kontroli wersji (SVN, GIT, Mercurial) porównujemy zawartość plików jądra CMS.
Jest to dość żmudna praca jednak przynosi bardzo czytelna informację które pliki się zmieniły w stosunku do wersji bazowej. W tym celu najlepiej korzystać z wtyczek (pluginów) tych systemów kontroli wersji dołączonych do popularnych środowisk programistycznych. Np. do Netbeans, Eclipse itp.2016/08/usuniecie-wirusow-ze-strony-kilka-porad/
Niestety często wraz z CMS mamy dostarczone także moduły. Należy ściągnąć je w podobnej wersji co te zainstalowane i też porównać pod tym kątem.
Blokada plików wykonywalnych w folderach z obrazkami
W zależności od użytego systemu CMS na serwerze mogą być osadzone foldery z prawami do zapisu. Mogą być one wykorzystane przez hakera do osadzenia tam pliku wykonywalnego i przeprowadzenia ataku. Najlepszym sposobem jest tam umieszczenie specjalnego pliku blokującego .htaccess:
|
1 2 3 4 |
<FilesMatch "\.(php|tpl)$"> Order allow,deny Deny from all </FilesMatch> |
Zmiana dostępów do CMS.
Jeśli na naszej stronie jest zainstalowany jakikolwiek system CMS, który umożliwia zalogowanie administratorowi – należy zmienić hasła wszystkich administratorów. Najlepiej na losowe lub składające się ze znaków specjalnych, cyfr, dużych i małych liter,
Zmiana dostępów FTP.
Jest to czynność, która musi być wykonana wraz z procesem usuwania zagrożeń. Z jakiego powodu? Otóż często dostępy są wykradane ze źle zabezpieczonych lub nieaktualnych programów. Niekiedy (jak ze starymi wersjami programu Total Commander) wystarczy skopiować odpowiedni plik konfiguracyjny tego programu aby móc połączyć się z FTP. Oczywiście pod warunkiem, że hasło zostało zapisane w tym programie.
Nie bez znaczenia jest też zainstalowany w systemie operacyjnym antywirus (lub jego brak).
Dostępy do wszystkich kont FTP muszą być zresetowane, a nieużywane konta FTP – najlepiej usunięte.
Zmiana dostępów MySQL.
„Strzeżonego Pan Bóg strzeże” – przy usuwaniu zagrożeń ze strony musimy się kierować tą zasadą. Z tego powodu najlepiej zresetować także dostępy do bazy danych oraz uaktualnić te ustawienia w pliku konfiguracyjnym CMS.
Aktualizacja systemu CMS.
Jeżeli wszystkie zagrożenia na stronie zostały usunięte i mamy pewność, że nikt nie zna dostępów do strony (system CMS) i serwera (FTP, MySQL) – należy zaktualizować oprogramowanie CMS oraz jeśli to możliwe – wszystkie dołączone do niego moduły. Może wiązać się to z koniecznością prac programistycznych, jeśli np. moduły są dopasowane specjalnie pod stronę lub sam system CMS jest przebudowany pod tym kątem.
Aktualizacja aktualnego stanu CMS do repozytorium w systemie kontroli wersji.
Jeśli nasza witryna jest przechowywana w systemie kontroli wersji (np. GIT, Mercurial, SVN) – po wykonaniu powyższych prac należy zaktualizować przetrzymywany tam kod do aktualnej wersji. Pozwoli nam to w przyszłości porównać aktualny stan plików z tymi w repozytorium z czasu ostatniej naprawy.
Zgłoszenie do Google.com witryny jako wolnej od wirusów
Finalnym zadaniem jest poinformowanie Google.com o tym, że nasza strona jest wolna od wirusów. Naznaczenie naszej witryny przez tą firmę niestety rzutuje na drastyczne komunikaty zgłaszane przez popularne przeglądarki WWW jak Mozilla Firefox czy co logiczne – Google Chrome. Należy zatem w centrali Google’a zgłosić, że zagrożenie już nie występuje.
Na początek zakładamy profil w „Narzędziach dla Webmasterów”:
https://www.google.com/webmasters/tools/home?hl=pl
Następnie przechodzimy na zakładkę „Problemy dotyczące bezpieczeństwa” i zaznaczamy kratkę „Rozwiązałem te problemy”. Oczywiście należy się upewnić, że problemy już nie występują. Szczególnie pod lokalizacjami które tam są zgłoszone przez Google Inc.
Należy pamiętać, że weryfikacja strony przez Google.com może zająć bliżej nieokreślony czas i zależy to tylko i wyłącznie od jednego podmiotu tj Google Inc.
