WordPress zaspamowany

Od mniej więcej dwóch tygodni spamboty wyszukują starszych wersji WordPressa, podatnych na atak. Atak nie jest właściwie widoczny na pierwszy rzut oka, ale szkody może poczynić znaczne. Otóż nasz zaatakowany blog zmienia się w farmę linków prowadzących do stron sprzedających viagrę i inne tego typu przyjemności. Jak sobie z tym radzić?

Oczywiście należy zaktualizować bloga do najnowszej wersji, obecnie 2.3.3 i wypada aktualizować go na bieżąco. Nigdy nie wiadomo, jaka dziura nie została jeszcze zauważona i załatana. Co poza tym?

  • Należy sprawdzić plik wp-config.php, w którym możemy mieć dopisaną stertę spamlinków, które będą się pojawiały jeszcze przed deklaracją doctype na każdej podstronie bloga.
  • Po wyczyszczeniu plik wp-config.php ładujemy na serwer i nadajemy mu atrybuty 400, co powinno zabezpieczyć nas przed kolejną próbą ingerencji w ten plik.
  • Zajrzyjmy do najnowszego posta. W nim może być fragment kodu z kolejną porcją spamlinków niewidocznych dla oka, ale widocznych dla wyszukiwarek.
  • Jeśli korzystamy z bloczka na linki, przejrzyjmy je uważnie. Czasem taki rzut oka może pokazać link do serwisu, którego raczej polecać nie chcemy. Te wpisy można wykasować z poziomu panelu administracyjnego.
  • Last but not least możemy mieć wredny wpis w pliku footer.php. Należy zwrócić uwagę na fragmenty kodu takie jak ERROR_REPORTING(0);, a zwłaszcza $d=base64_decode. Odpowiadają one za zaciąganie pliku tekstowego ze zbiorem spamlinków. Adres do strony jest zakodowany w base64, stąd poszukiwanie go tradycyjnymi metodami może być ciężkie.

Po przejściu tych kroków nasz blog powinien być czysty… do następnego razu ;)

PS. Wiem, że blog zarósł pajęczyną, ale miałem trochę innych rzeczy na głowie. Obiecuję jednak, że blog zostanie odkopany, odrestaurowany i przywrócony do dawnej świetności. Ale to zajmie przynajmniej kilka tygodni…

This entry was posted in WWW & Net, Wordpress and tagged , , , , . Bookmark the permalink.

3 Responses to WordPress zaspamowany

  1. Z tymi uprawnieniami 400 bym uważał, bo coś mi się wydaje, że to zależy od tego, czy PHP jest procesem użytkownika, czy jest to proces użytkownika www-data.

  2. Oczywiście wszystko zależy od indywidualnych ustawień, ale wp-config.php jest tylko plikiem odczytywanym, więc ustawienie dla niego uprawnień 400 nie powinno w niczym przeszkadzać :)

  3. Jeżeli PHP działa w trybie FastCGI (tak jak na większości serwerów hostingowych), uprawnienia 400 będą OK.
    Ale jeżeli Apache używa modułu mod_php, uprawnienia 400 spowodują najprawdopodobniej błąd działania skryptu (Failed opening required wp_config.php …).
    Oczywiście wszystko przy założeniu, że my jesteśmy właścicielem pliku.

    Ale jak już napisałeś, wszystko zależy od indywidualnych ustawień. :)