Защита wordpress блога от взлома или как изменить логин admin

Опубликовано: 14.06.2017

видео Защита wordpress блога от взлома или как изменить логин admin

Вирусы Wordpress. Как проверить тему Вордпресс на вредоносный код.

Невзирая на то что WordPress развивается уже довольно издавна и код всегда анализируется, уязвимости в движке находят повсевременно, и можно представить, что продолжат отыскивать и в дальнейшем. Необходимо дать подабающее разработчикам: они оперативно реагируют на все сообщения и избавляют трудности, а простота обновления позволяет админам просто обезопасить собственный ресурс. Хотя анализ указывает, что далековато не все торопятся обновляться. Но вот главные трудности безопасности WP не в самом движке. Сейчас доступно огромное количество тем и плагинов, которые пишутся программерами различного уровня и часто содержат уязвимости. Некие темы и плагины распространяются через непонятные веб-сайты и уже вначале могут содержать бэкдоры. Добавим сюда неправильные опции веб-сайта, неправильные права и внедрение учетных записей по дефлоту, дозволяющие атакующему расслабленно подбирать пароли, — и без дополнительных мер защиты веб-сайт на WP обречен.



Итак, имеем несколько веб-сайтов на WP различного предназначения, размещенных в VDS. Стандартная связка PHP5 + Apache 2 + MySQL. ОС Ubuntu 14.04.3 LTS. Также были установлены панель управления хостингом Vesta Control Panel и phpMyAdmin. Последним, вобщем, никто не воспользовался, и, по-моему, о его существовании даже не знали, хотя журнальчики проявили, что и то и это тоже пробовали взломать. На момент атаки движок блога, активные плагины и Vesta были обновлены до животрепещущего состояния. Применяемые темы в большинстве взяты из бесплатного каталога и подогнаны под свои условия. Бэкап SQL делался раз в неделю, бэкап файлов — очень издавна. Все это работало до поры до времени.


Защита админки Wordpress от подбора паролей. Как защитить блог от взлома

1-ый сигнал поступил от MySQL. VDS, ранее не очень нагруженный, закончил тянуть. В итоге сервер баз данных просто отвалился, а совместно с ним и закончили отвечать веб-сайты. При всем этом количество гостей на счетчике вписывалось в стандартную посещаемость. Перезапуск вернул работу, но нагрузка, показанная htop, была очень высочайшей.


Wordpress - двухфакторная аутентификация

Последующий сигнал поступил от поисковых машин. При этом сообщения и, разумеется, методы работы у Yandex'а и Гугл отличаются и по-разному полезны. Yandex сказал, что на веб-сайте найден вредный контент, в панели вебмастера веб-сайт был помечен подходящим значком, указан предполагаемый тип (троян JS), и в поиске выводилась информация о том, что ресурс может навредить. Сходу скажу, что код, который раздражал Yandex, был найден в файле заголовков практически всех тем в файле header.php, и после того, как он был убран, все веб-сайты в течение одного-трех дней были признаны незапятнанными. Хотя в это время битва еще длилась.

Гугл прислал сообщение спустя 6 часов после Yandex'а, но отметил, что на веб-сайте найден «взломанный контент», в панели можно было просмотреть перечень подозрительных файлов (на момент получения письма большая часть было найдено и удалено). Информация сама по для себя увлекательна, потому что в ней указаны новые файлы, оставленные взломщиком, на которые нет прямых ссылок на веб-сайте. Такие файлы, вероятнее всего, совершенно точно необходимо будет удалять. Google в сообщении предлагает ссылку на «Инструмент для восстановления взломанных веб-сайтов», позволяющий просмотреть, как смотрится веб-сайт, и советы. После удаления файлов нужно вручную выслать на перепроверку те веб-сайты, у каких при использовании site: в строке поиска указывает «Может быть, этот веб-сайт был взломан». Позднее Google убрал отметку об угрозы части веб-сайтов и начал выдавать сообщение о том, что на веб-сайтах появилось огромное количество ошибок. Неувязка 404 появилась или из-за неправильно внедренного кода, когда часть URL не работала, или из-за того, что код ссылался на вредный файл, который уже был найден и удален.

Забегая вперед, скажу о итоге. Атака шла с нескольких IP и массированно началась за три денька до взлома. Обнаружилось огромное количество излишних файлов с расширением php, которые были разбросаны по всем каталогам, плюс каталог gopni3d с кучей HTML-файлов снутри. Тут и шелл, и бэкдор-загрузчик, и дор, и рассыльщик мусора. Внедрен PHP- и JS-код в тему header.php и некие файлы WP, включая wp-config.php. Изменен файл .htaccess. В WP появились две дополнительные учетные записи с правами админа. Каталог SMTP-сервера /var/spool/exim4/input был завален огромным количеством спам-писем.

Сейчас разберем, как это все отыскать, потратив малые усилия и имея минимум познаний. Последующие шаги понятны: отыскать чужой код, осознать деяния взломщика, убрать уязвимости либо понизить их количество, затруднить последующие атаки. Все это необходимо будет делать стремительно и параллельно.