Вирус на сайте

на 4.

---------- Добавлено 17.10.2017 в 19:05 ----------

ОК.

Вот блин.. Ну что ты хочешь? Узнать степень опасности? Тебе ЭТО надо? Точно?

А первое, о чем ты должен быть подумать - откуда и как он появился. Вот где ты его нашел?

/wp-content/index.php

/wp-admin/admin-functions.php

/wp-admin/edit-form-comment.php

/wp-admin/admin-header.php

/wp-admin/admin-post.php

А до этого много файлов с вирусами удалил.

Для общего развития.

Я хотел через поиск найти, что это значит, не получается.

Если подскажите, я хоть буду знать, для чего это, от этого уже буду отталкиваться )) как-то так))

Да пофик "для чего" (расшифровать можно, но смысла нет). Ты не о том думаешь и не тем занимаешься.

Вот качаешь отсюда свою версию ВП http://ru.wordpress.org/releases/ и убеждаешься что в ВП этого нет. Заменяешь ядро через синхронизацию файлов - спец ПО или в тоталкомандире или др нормальном файл-менеджере. Увидишь и лишние и неправильные.

Аналогично по всем плагинам и теме.

Плаги и тема должны быть из оф каталога и не древние (только плаг транслитерации может быть древним ;) ).

Потом делаешь дамп базы и кладёшь рядом. Прогоняешь все айболитом.

ПК ессно тоже должен быть безопасным.

Спасибо! Сложно, но сделаю))

последний вопрос))

на первое время, если поставлю плагин iThemes Security, он мне даст время, 1-2 дня, чтобы снова не заразили?

:) Этим может не ограничиться. Это первый только шаг. Но иногда, да, этого бывает достаточно.

Не знаю. Мож чем-то и поможет, смотря где дыра, какие способы внедрения кода и какие он имеет настройки.

Я такие плаги не юзаю. От них вреда больше, чем пользы.

SeVlad, подскажите, пожалуйста, что вы еще добавили бы в htaccess ? Или так уже норм?

Хотел задать вопрос в ветку, которая у вас в подписи, а там уже нельзя, тема старая.

<Files wp-config.php>

order allow, deny

deny from all

</Files>



<IfModule mod_rewrite.c>

RewriteEngine On

RewriteBase /

RewriteRule ^index\.php$ - [L]

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule . /index.php [L]

Options All -Indexes

</IfModule>



AuthUserFile .htpasswd

AuthName "Private access"

AuthType Basic

<FilesMatch "wp-login.php">

Require valid-user

</FilesMatch>



<files .htaccess>

order allow, deny

deny from all

</files>



RewriteEngine On

RewriteCond %{REQUEST_METHOD} ^TRACE

RewriteRule .* - [F]



Options +FollowSymLinks

RewriteEngine On

RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]

RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]

RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})

RewriteRule ^(.*)$ index.php [F,L]

iThemes Security - не панацея, но он автоматически применяет ряд блокировок, подобных тем, что вы сейчас прописываете в htaccess, и действительно может немного помочь хотя бы сэкономить время.

По htaccess. Не только содержимым GET-запросов ломают. Если вы хотите что-то нафильтровать по ним, то писать придётся ещё много, а результат всё равно будет далёк от желаемого.

Одна из не универсальных, но действительно надежных методик - белые списки на всё потенциально опасное.

Просто заблокировать в htaccess или на файрволе POST-запросы и запросы с не-пустым QUERY_STRING для всех адресов вообще, исключая белый список (или конкретные QS).

На большинстве WP-сайтов белый список на практике получается очень скромным (скрипт комментариев, формы заявок, пользовательские аяксы).

А системные папки сделать открытыми только для себя (блокировкой по IP-адресу или HTTP-авторизации).

Для современных Вордпрессов нет большого смысла, но для многих не лишнее поудалять до попадания в CMS заголовки User-Agent \ X-Forwarded-For, если не используются.

С тем, что никакая защита не абсолютна, мы на практике сочетаем комплекс решений:

1) Внешний файрвол - для реализации подобных блокировок, только в более удобном и эффективном виде, чем через htaccess

2) Лёгкие бэкапы - позволяют делать "снимки" хоть каждый час

3) Антивирус - автоматически проверяет каждый бэкап и высылает уведомления

4) Подробный контроль всех изменений - если антивирус не определил проблему, то всё равно будет видно добавление\изменение потенциально опасных файлов

Ещё ряд дополнительных модулей оптимизирует ситуацию. Но уже эти позволяют главное - и защитить, и, в случае прорыва, сразу узнать о проблеме да почти моментально вылечить сайт.

Если про закреплённый в разделе топик, то его нужно читать (3х первых страниц достаточно), а не там спрашивать.

Я бы половину удалил. Оставил только ВПшный блок (кстати, почему он не в своих комментах?) и ограничение на доступ к wp-login.php. Только я не уверен, что у тебя этот блок правильно написан.

Обычно это выглядит типа так (ну я во всяком случае привык к такому синтаксису):

<Directory "/www/docs/private">
    AuthName "Private"
    AuthType Basic
    AuthBasicProvider dbm
    AuthDBMUserFile "/www/passwords/passwd.dbm"
    Require valid-user
</Directory>

Только не Directory, а Files, тк ограничение для файла.

Но если все работает, значит всё ОК.

На сам сайт-то пускает без авторизации? А к wp-admin/admin-ajax.php? Проверь в приватном режиме или через http://bertal.ru/ чтобы 200 было.

ЗЫ. Код на форум вставяй в ббкоде [code][/code]. # в расширенном режиме.

qvaro, для wordpress это дело привычное. Взламывание для бесплатного движка дело времени. Обновления нужны обязательно.

Ага, а платный движок — прям панацея от взлома.