Часто можно увидеть в сети: сайт работал нормально и вдруг начал работать, как дворник с похмелья, хостер пишет гневные письма, поисковики обходят сайт стороной, а браузеры блокируют предупреждением «Имеется информация, что этот сайт атакует компьютеры!»

Откуда же берутся вирусы?

Самая распространённая на сегодня причина — это использование quickstart (quickstart это установочный архив, позволяющий в несколько минут развернуть точную копию сайта, со всеми расширениями), как правило, скачанного с варезных ресурсов; квикстарта, купленного у разработчика, разумеется, можно не бояться. Очень удобно, не нужно мучатся с дизайном, установкой расширений, настройкой сайта. Правда, зачастую вместе с сайтом можно получить набор скриптов, дающих контроль над вашим ресурсом, таких как рассылка спама, «раздача» вирусов или размещение невидимых ссылок на сторонние ресурсы (черный SEO).

Для чего варезные ресурсы включают backdoor (от англ. back door — «чёрный ход») в архив? Как правило, варезные ресурсы живут за счет отчислений за каждое скачивание от файлообменников, а те, в свою очередь, показом рекламы и платными подписками, позволяющими увеличить скорость загрузки, которая для простых пользователей обычно ограничена. Но многим этого кажется мало, тем более когда есть возможность управлять сотнями и даже тысячами сайтов. Если уж хотите использовать quickstart, то купите его у разработчика, тем более его стоимость в среднем составляет 30-50 долларов, что, в общем, недорого даже при нынешнем курсе.

На второе место можно поставить взлом CMS через уязвимости, причем с защищённостью движков все в порядке, причина банальна - пользователи не устанавливают обновления. Кто-то боится, что после обновления «слетит» сайт, кому-то просто лень, или студия разработала сайт и передала его заказчику. Заказчик поручил вести сайт одному из сотрудников, и тот исправно наполняет его по инструкции, а обновление в его функции не входит…

Так одной из возможных причин утечки «Панамского архива» специалисты называют устаревшие CMS - Drupal, содержавший на момент взлома не менее 25 уязвимостей, и WordPress 4.1 с уязвимым плагином.

Ищем черный ход

Во-первых, антивирус ищет вредоносы именно для ПК, сколько бы Вы не размещали на своем компьютере backdoor на php, заразить его (ПК) не удастся.

Во-вторых, это может быть короткий кусочек кода (обычно зашифрованный), который подгружает вредоносные скрипты с другого ресурса, а раз так, то искать его у себя бесполезно.

Можно пойти разными путями.

Первый вариант

Поскольку сайт содержит несколько тысяч файлов, то поиск измененных или «лишних» может занять довольно много времени, а результат неутешительным - после лечения на ресурсе через некоторое время снова появляются «левые» ссылки.

Ставим чистую Joomla (или другую CMS), устанавливаем шаблон, все компоненты, модули, плагины, что стояли на вашем сайте. Переносим все изображения со старого сайта, директория images, предварительно проверив, чтобы в ней не оставалось никаких файлов, кроме изображений, в том числе и во внутренних директориях. В случае если у вас установлен компонент K2, то изображения будут находиться в директории media/k2/items/cache/.

Внимание! Не лишним будет проверить наличие изображений с явно рандомным названием, как i2495mg.gif, обычно в таких изображениях прячется исполняемый код.

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

Подключаем базу со старого сайта

Экспортируем базу. Заходим на хостинге в phpmyadmin, выбираем в столбце слева нужную базу и переходим во вкладку «Экспорт». Нажимаем «Выделить все», можно поставить сжатие zip, и в самом низу страницы нажимаем «Ок». Сохраняем базу на свой ПК. Заходим в phpmyadmin, создаем новую базу, переходим в нее, открываем вкладку импорт и указываем путь к скачанному дампу. Теперь осталось подправить configuration.php, который находится в корне каталога, открываем его любым редактором. Например, Notepad++.

public $db = "base"; - вместо base указываем свое имя базы;

public $user = "root"; - если вы не меняли имя пользователя на локальном сервере, то оставляем как есть;

public $password = ""; - на локальном сервере обычно стоит пустой пароль, тоже оставляем.

Сохраняем изменения, проверяем работу сайта.

Второй вариант

Если у вас достаточно опыта, то можно включить просмотр исходного кода и посмотреть, присутствует ли «чужие» ссылки, далее посмотреть, например через firebug, откуда они берутся. Как правило, они зашифрованы и, как правило, алгоритмом base64.

Если опыта не хватает, то можно воспользоваться онлайн-сервисом, самый простой вариант - в кабинете вебмастера Яндекс или Гугл либо веб-сканер https://rescan.pro/ . Я больше склоняюсь к ручному просмотру кода страницы, хотя, конечно, стоит признать, что всевозможные скрипты и сканеры заметно ускоряют работу.

Пример по поиску «левых»​ ссылок

Для примера я взял квикстарт с одного из варезных ресурсов. Нажимаем Ctrl+F5 для просмотра исходного кода, даже при беглом просмотре сразу находим:

Переключаем в административной панели шаблон сайта на стандартный, ссылки исчезли, значит, код прописан в варезном шаблоне, там и будем искать.

Открываем Notepad++, нажимаем Ctrl+F, переходим во вкладку «Найти в файлах», указываем директорию шаблона, а в строке поиска искомое, в данном случае "sa_wqngs". Нажимаем «Найти все». Поиск находит два совпадения.

Удаляем строки, обновляем страницу, строки с ссылками не исчезли, а поскольку я раньше не нашел прямых ссылок, значит, код зашифрован.

Запускаем новый поиск, теперь по «base64» и видим в коде шаблона:

Удаляем строки 174, 184, 186 (код комментировать не буду, кто хочет, может найти описание в сети). Снова обновляем страницу с исходным кодом, ссылки исчезли. Также проходим все результаты поиска с «base64», к слову, подобных вставок в шаблоне нашлось с десяток. Тут хорошо помогает сортировка по времени, так если большинство файлов шаблона датированы, предположим, 1 мая 2014 года, то файлы, изменённые, скажем, восемь месяцев спустя по меньшей мере подозрительны.

Для чего обновлять сайт?

В наше время «злобные хакеры» не ломают сайты вручную, если, конечно, это не крупный портал или база конфиденциальной информации. Взломы давно поставлены на конвейер. Для этого написаны боты (скрипты), которые перебирают в сети все сайты на популярных CMS, после чего пытаются применить библиотеку уязвимостей, удачное внедрение отправляется в отчет. Соответственно, как только появляется новая уязвимость, она сразу же добавляется в библиотеку.

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

Используем сканер

Конечно, вручную не всегда удается найти некоторые «сюрпризы», так, возможно, вы вовремя не обновили систему или расширения, и на сайт был установлен backdoor... Сейчас существует множество сканеров, один из них AI-Bolit. К тому же он бесплатен для некоммерческого использования.

Используем его для «экспериментального» сайта, где я искал «лишние» ссылки. Как им пользоваться, хорошо документировано на официальном ресурсе, поэтому не буду дублировать информацию.

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

Вторая говорила об уязвимости в administrator/components/com_k2/lib/elfinder/elFinder.class.php - AFU: elFinder. Возможно, причина в том, что компонент тоже устарел.

На всякий случай я скачал последнюю версию компонента с официального сайта и сравнил версию, на который жаловался сканер, со свежескачанной. Для этого удобно использовать плагин для Notepad++, Compare. Как и предполагалось, отличие состояло только в версиях.

Сидим в засаде

На этом проверку можно было бы и завершить, но на всякий случай я решил почувствовать себя параноиком. Один из верных способов - посмотреть, какие пакеты ваш сайт засылает в сеть. Ставим Wireshark , он также хорошо задокументирован на сайте разработчика. Переходим по страницам сайта, действительно, сайт обращается к сети, но тут ничего страшного. Идет подгрузка шрифтов с Google Fonts, видео с YouTube…

Занавес

Этот материал, конечно, не подробная инструкция по «лечению» сайтов, а лишь небольшое руководство к действию. Дорогу осилит идущий...

Конечно, неплохо поставить элементарные средства защиты, но об этом уже в следующей части.

Необходимо выполнять совместно. Если устранить первоначальную причину взлома (например, уязвимость в расширении CMS), но не удалить все вредоносные файлы, злоумышленник сможет снова получить доступ к сайту, воспользовавшись одним из своих скриптов. Если же удалить все загруженные вредоносные скрипты, но не устранить причину взлома, злоумышленник сможет повторно взломать сайт и снова загрузить на него скрипты.

Выполнять работу по удалению вредоносных скриптов и проводить анализ причин взлома должен специалист с соответствующими знаниями и опытом :

• Для удаления вредоносных скриптов необходимо знание языка программирования PHP , а также знание «изнутри» популярных CMS (Joomla, WordPress и т. п.) и расширений для них. Эти знания требуются, чтобы отличить скрипты непосредственно CMS и ее расширений от посторонних файлов, а также чтобы при встрече с сомнительными скриптами иметь возможность однозначно определить, какие действия они выполняют.
• Для анализа причин взлома требуется опыт администрирования сервера . Это необходимо для анализа состояния файлов на аккаунте, времени их изменения, а также для сопоставления этих данных с журналами сервера для определения, какие именно действия злоумышленника привели к взлому сайтов.

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

Тем не менее, существует ряд мер, которые в некоторых случаях помогают возобновить безопасную работу сайта без наличия специальных знаний . Ограничением приведенного ниже способа является то, что для возобновления работы сайта требуется наличие его резервной копии, созданной на момент до взлома. Если дата взлома неизвестна, можно попробовать применить этот способ, используя самую раннюю резервную копию из имеющихся. Вторым ограничением, как следствие из первого, является то, что после восстановления сайта будут потеряны данные, добавленные на сайт после создания восстанавливаемой резервной копии (например, новые статьи, изображения или документы). Если требуется восстановить работу сайта, сохранив при этом новые данные, необходимо обратиться к специалисту.

Эти меры не позволяют установить причину взлома сайта , однако каждая из них направлена на устранение одной из потенциальных причин проникновения. Так как точная причина взлома неизвестна, необходимо выполнить их все. Действия расположены в таком порядке, чтобы сначала полностью исключить возможность продолжения деятельности злоумышленника на сайте или аккаунте хостинга в настоящий момент, после чего предупредить проникновение злоумышленника на сайт в будущем.

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

Очередность действий важна, поэтому необходимо выполнять их именно в том порядке, в котором они расположены ниже.

1. Сразу после обнаружения взлома сайта необходимо полностью заблокировать к нему доступ посетителей . Это, во-первых, помешает злоумышленнику вести вредоносную деятельность на сайте, а во-вторых, не позволит ему препятствовать проведению восстановительных работ. Этот шаг очень важен, так как удаление вредоносных скриптов и устранение причины взлома не происходит одномоментно — как правило, на это требуется несколько часов. Если сайт останется доступным извне, злоумышленник сможет произвести повторную загрузку скриптов в тот раздел сайта, который уже был очищен. При этом злоумышленник может использовать различные IP-адреса для подключения, поэтому запрет доступа только для списка IP-адресов не даст результата. Чтобы гарантированно очистить сайт от найденных вредоносных скриптов, необходимо полностью закрыть для злоумышленника возможность обращения к сайту, что можно сделать только с помощью полной блокировки сайта для любых посетителей. Обратитесь в службу технической поддержки хостинга, на котором размещается ваш сайт, чтобы произвести блокировку.
2. После блокировки сайта необходимо проверить компьютеры , с которых производилась работа с сайтом, современным антивирусом с обновленными вирусными базами. Если сайт был взломан путем кражи паролей от аккаунта с помощью вируса, необходимо убедиться, что дальнейшая работа со взломанным сайтом ведется с компьютера, на котором вирусы отсутствуют, иначе после смены паролей доступа они снова могут быть украдены.
3. После блокировки сайта и проверки на вирусы необходимо изменить все пароли доступа к аккаунту: доступы через FTP, через SSH, а также доступы к панели управления хостингом. Если злоумышленник получал доступ к файлам аккаунта одним из этих способов, после смены паролей он больше не сможет сделать это.
4. После смены паролей необходимо уничтожить все процессы сервера , работающие от имени аккаунта, на котором обслуживается сайт. Запущенные злоумышленником в фоновом режиме процессы, не будучи уничтожены, смогут после проведения восстановительных работ повторно разместить вредоносные скрипты на сайте. Чтобы этого не произошло, все процессы, запущенные до блокировки сайта, должны быть уничтожены. Сайт в этот момент уже должен быть заблокирован, чтобы злоумышленник не смог запустить новые процессы, обратившись к одному из своих скриптов на сайте. Для уничтожения запущенных на аккаунте процессов обратитесь в службу технической поддержки хостинга, на котором размещается ваш сайт.
5. Теперь проникновение на сайт извне невозможно и можно приступать к его восстановлению.
6. Перед дальнейшими действиями удалите все существующие файлы сайта , чтобы среди них гарантированно не осталось вредоносных скриптов, или скриптов CMS, в которые злоумышленник внедрил вредоносный код. Этот шаг также важен, так как при восстановлении сайта из резервной копии не всегда удаляются файлы, которые существовали до восстановления. Если после восстановления из резервной копии на сайте останутся старые вредоносные скрипты, злоумышленник сможет повторно проникнуть на сайт. Избежать этого можно, удалив все файлы сайта перед проведением восстановления.
7. После удаления всех файлов сайта восстановите сайт из резервной копии , созданной до его взлома. Часто достаточно восстановить только файлы сайта, однако если после их восстановления в работе сайта наблюдаются ошибки, необходимо восстановить сайт полностью: и файлы и базу данных.
8. После восстановления из резервной копии обновите используемые версии системы управления сайтом (CMS) и ее расширений до последних. Это необходимо, чтобы исключить присутствие на сайте известных уязвимостей, через которые он может быть взломан. Как правило, обновление можно произвести через раздел администрирования CMS. Для получения полных инструкций по обновлению CMS необходимо обратиться на сайт разработчика системы. Важно обновить не только саму CMS, но и все ее расширения, так как часто взлом происходит через уязвимость, присутствующую в одном из расширений CMS (например, плагины, темы оформления, виджеты и пр.). В этот момент еще нельзя снимать блокировку сайта для посетителей, так как он может быть еще уязвим. Чтобы получить доступ к сайту для обновления, обратитесь в техническую поддержку хостинга, на котором размещается ваш сайт, и попросите разрешить доступ к сайту только с IP-адреса вашего компьютера. Узнать ваш IP-адрес вы можете, например, на inet.yandex.ru .
9. После обновления системы управления сайтом и ее расширений зайдите в раздел администрирования сайта и измените пароль доступа администратора к нему. Убедитесь, что среди пользователей сайта нет других пользователей с административными привилегиями (они могли быть добавлены злоумышленником), а если таковые обнаружатся — удалите их.
10. Теперь, когда сайт восстановлен из резервной копии и не содержит вредоносных скриптов, CMS и ее расширения обновлены до последних версий, в которых отсутствуют уязвимости, а пароли доступа к сайту и аккаунту хостинга изменены, можно вновь открыть сайт для посетителей.

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

Чтобы защитить сайт от повторных взломов в будущем необходимо придерживаться следующих рекомендаций:

1. Следите за обновлениями CMS и расширений для нее на сайтах разработчиков и своевременно производите их обновление до последних версий. Если в комментарии об обновлении присутствует информация о том, что оно устраняет какую-либо уязвимость, установите это обновление как можно быстрее.
2. Производите работу с сайтом и с аккаунтом хостинга только с компьютеров, которые защищены от вирусов современными антивирусами с постоянно обновляемыми вирусными базами.
3. Используйте сложные пароли, чтобы их нельзя было подобрать перебором по словарю.
4. Не сохраняйте в программах для подключения к сайту пароли от FTP и SSH, а также не сохраняйте в браузере пароль доступа в административный радел сайта и в панель управления хостингом.
5. Время от времени (например, раз в три месяца) изменяйте пароли доступа к сайту и к аккаунту хостинга.
6. Если на компьютере, с которого производилась работа с сайтом, были обнаружены вирусы, измените пароли доступа к сайту и аккаунту хостинга как можно быстрее. Изменять необходимо все пароли: пароли доступа по FTP, SSH, пароль от административной панели сайта, а также пароль от панели управления хостингом.
7. Не предоставляйте доступ к сайту третьим лицам, если вы не уверены, что они также будут следовать приведенным рекомендациям.

Joomla — не только одна из самых популярных CMS в сети Интернет. К глубокому сожалению, эта система управления контентом наиболее подвержена атакам хакеров. Сегодня мы поговорим о том, что делать, если ваш сайт на Joomla взломан, а также рассмотрим меры профилактики и борьбы со злоумышленниками.

Общение с читателями заставило дописать абзац. Мы не осуществляем бесплатные или платные консультации, связанные со взломом вашего сайта, но готовы платно оказать услугу лечения и восстановления сайта после атаки хакеров.

Зачем хакеры взламывают сайт?

Не буду рассматривать экзотические случаи, когда атака на сайт происходит целенаправлено в целях добычи информации. Ибо при размещении конфиденциальных данных в сети Интернет, используется что угодно, только не Joomla. Мотивация современных взломщиков достаточно понятна и ее можно разбить на три основных раздела.

Продвижение сайта злоумышленника.

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

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

Взлом для повышения самооценки хакера

Файлы Joomla могут быть или полностью удалены или заменены скриптами злоумышленника. Есть высокая вероятность, что посетитель увидит нечто в красно-темных тонах, где будет написано, что взлом совершен замечательным парнем из Турции.

Рассылка спама «от лица» вашего сайта.

В 2015 году по этой причине происходило большинство взломов.

Каков алгоритм работы вредоносных скриптов и злоумышленников?

Атака на сайт осуществляется через уязвимость CMS Joomla либо компонента. Бывают случаи, когда вредоносный код изначально присутствует в установленном расширении.

Это касается тех компонентов, плагинов, модулей, которые были скачены нелегально.

Результат проникновения на сайт — появление многочисленных файлов скриптов в разных каталогах Joomla.

Имена файлов и их размещение в каталогах таковы, что на первый взгляд отличить вредоносные скрипты от «родных» файлов Joomla непросто. По этой причине нередко «лечение» сайта оказывается неполным и спустя несколько дней или недель от имени вашего домена уходит очередная порция спама.

Практически сразу от техподдержки хостинга в ваш адрес летит грозное письмо, где предлагают решить проблему с безопасностью. Бездействие грозит блокированием аккаунта и отключением сайта.

Что делать, если сайт на Joomla взломали?

Начало вашей войны с вредоносными скриптами начнется с хостинг-провайдера. Скорее всего, именно его письмо даст отмашку военным действиям

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

Встроенный в хостинг панель антивирус. Он, как правило, не производит лечение, но поможет найти значительную часть вредоносных скриптов

Доступ по SSH. Без него говорить о полноценной борьбе с вирусами невозможно

Оперативная и квалифицированная техподдержка

Ежедневное резервное копирование. Идеальный вариант - возможность восстановить или скачать копию месячной давности

Если ваш хостинг провайдер не предоставляет антивирусное программное обеспечение (оно может быть встроено в хостинг панель, либо запускаться самостоятельно хостинг провайдером по вашей просьбе) — хватайте в охапку свой зараженный сайт и меняйте компанию, предоставляющую услугу хостинга. Рынок просто изобилует подобными предложениями.

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

Совершенно другая история, если вы арендуете сервер целиком. Первый, третий и четвертый пункты будут целиком на вашей совести. А пункт два будет самим собой разумеющимся.

Порядок действий при взломе

Шаг 1. Очищаем сайт от вредоносных файлов

Как правило, проходит не так много времени от взлома до письма от техподдержки хостинга. В редких случаях владелец сайта сам обнаруживает взлом.

Самый простой способ — это восстановить сайт из незараженной резервной копии. Однако, он годится только в том случае, если на сайте длительное время не проводилось никаких изменений.

На регулярно обновляемом сайте поиск придется проводить вручную. И делать это посредством SSH. Задача будет предельно простой. Необходимо выяснить: какие файлы изменялись за последнее время. Например, за неделю. Для операционной системы Debian команда будет выглядеть так:

find /каталог, где осуществляется поиск/ -type f -mtime -7

Согласно этой команде система отобразит те файлы, что изменялись за последние 7 дней. Обращаем внимание на файлы с расширением PHP.

Именно они несут угрозу. При этом вы должны понимать, что часть отображенных файлов может оказаться незараженными и принадлежать самой Joomla. Поэтому у вас под рукой должен быть исходный дистрибутив той версии, что работает в данный момент.

На скриншоте мы видим два файла. Первый — вероятнее всего вирус. Второй — это системный файл Joomla.

Откуда такие выводы?

Дело в том, что в каталоге /components/com_weblinks/views/category/ никакого файла start.php не должно присутствовать в принципе.

А файл error.php в каталоге /logs/ является частью CMS. Впрочем, если конкретно он будет удален, ничего критичного не произойдет, поскольку служит хранилищем логов Joomla.

Шаг 2. Защищаем сайт от взломов

Предположим, вы успешно справились с удалением всех вредоносных скриптов. Техподдержка хостинга и антивирус отрапортовали: «да, все чисто». Что необходимо сделать, чтобы предотвратить подобное?

Обновление Joomla и расширений до последней актуальной версии

Если ваш сайт работает на версии Joomla до 3.X — есть очередной повод задуматься об обновлении. Последнее время на этом настаивают и многие хостинг провайдеры.

Это не решит проблему безопасности на 100 процентов, но в будущем у вас появится возможность оперативно обновлять систему, кликом одной кнопки устанавливать патчи безопасности, которые последнее время выходят практически каждую неделю.

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

Все ли расширения используются?

В силу низкой квалификации современные веб мастера решают любой вопрос установкой плагина или модуля, хотя достаточно добавить пару строчек в код шаблона сайта. Или подправить CSS.

Чем меньше на вашем сайте дополнительных расширений, тем меньше вероятность взлома!

Компонент RSFirewall

Независимо от содержимого, сайт, работающий под управлением CMS Joomla, ежедневно подвержен атакам. Подбор хакерами пароля к административной панели и попытки внедрить вредоносный код происходят с пугающей регулярностью. В одиночку противостоять атакам и внедрениям — невозможно.

Обращаю ваше внимание на компонент, который решает огромное количество задач, связанных с безопасностью сайта. Имя ему - «RSFirewall».

Рассмотрим вкратце основные возможности, функции и задачи, решаемые RSFirewall:

Проверка вашей системы на наличие уязвимостей. Осуществляется анализ базы данных, файлов, а также среды, в которой работает сайт

Сравнение файлов вашей системы с оригинальным дистрибутивом Joomla. Это существенно облегчает поиск зараженных файлов.

Анализ прав на каталоги и файлы.

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

Логирование попыток входа в административную панель Joomla и возможность блокирования пользователей, которые ввели неверно логин и пароль определенное количество раз

Логирование любых посещений сайта и возможность блокирования IP адресов, с которых осуществлялась попытка взлома

Запрет доступа к сайту из указанных стран.

Компонент платный. Актуальная версия доступна исключительно для Joomla версий 3.X

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

Исследовать RSFirewall будем при локализации «по умолчанию». То есть, языком интерфейса останется английский.

Установка компонента стандартная, осуществляется через менеджер расширений. После того, как компонент установлен, заходим «Компоненты — RSFirewall — System Check»

Откроется страница, где нам будет предложено проверить конфигурацию Joomla и сервера на предмет устойчивости ко взломам. Также будет осуществлен поиск:

файлов Joomla, которые подвергались изменению и отличаются от аналогов из оригинального дистрибутива

вредоносных файлов

будет осуществлена проверка прав на каталоги и файлы

Для того, чтобы проверка началась, достаточно нажать кнопку «Perform the System Check».

Рассмотрим результат анализа.

В верхней части можно наблюдать количество баллов или процентов, которые компонент выставляет после проверки сайта. Значение «100» - высшая оценка. На данный момент тестируемый сайт оценен всего на 84 балла. Давайте разберемся — почему.

Рассмотрим подробно полностью список, не исключая и текст выделенный зеленым цветом.

Раздел Joomla Configuration

Checking if you have the latest Joomla! Version — Проверка: является ли установленная версия Joomla самой последней. Как видим, с этим все в порядке. На момент написания статьи таковой была версия Joomla 3.4.8

Checking if you have the latest RSFirewall! Version — Проверка: является установленная версия компонента RSFirewall самой последней. Это важная характеристика безопасности вашей системы, поскольку от версии к версии компонент не только обрастает базой данных вредоносных скриптов, но постоянно меняется функционально согласно обнаруженным в Joomla уязвимостям.

Checking if you have a weak database password — В данном случае компонент проверяет взломоустойчивость пароля к базе данных.

Checking if the default "admin" user is active . - Логин супер администратора сайта в целях безопасности должен отличаться от широкораспространенного «admin». Если компонент находит в базе данных пользователя с таким логином, появится предупреждение.

Checking if you have set your FTP password — На этапе установки Joomla или редактировании ее настроек, допускается фатальная ошибка. Доступ по протоколу FTP указывается в конфигурационном файле Joomla. Имеет место быть и не менее трагичный вариант. При сохранении общих настроек Joomla в поле доступа по FTP записывается логин и пароль к административной панели. Поэтому следим, чтобы в файле configuration.php соответствующие параметры были пустыми.

Checking if you have Search Engine Friendly URLs enabled — Проверка: включена ли в общих настройках Joomla поддержка SEF URL.

Checking the integrity of configuration.php — Проверка файла configuration.php на корректность и целостность.

Checking if any admin users have weak passwords — Проверка всех паролей супер администраторов вашего сайта на взломоустойчивость

Checking your session lifetime — Проверка времени жизни сессии, что задается в общих настройках Joomla. Если оно превышает 15 минут, то появится предупреждение.

Checking if there are any files left in the Joomla! temporary folder — В данном случае проверяется: располагаются ли файлы во временном каталоге Joomla. По умолчанию таким каталогом является папка «tmp». Нужно следить за чистотой данного каталога, поскольку после установки расширений или обновления Joomla там могут находиться лишние архивы и скрипты.

Checking for .htaccess — Проверка на существование файла.htaccess. После установки Joomla в корне сайта по умолчанию создается файл htaccess.txt. Ваша задача переименовать его в.htaccess. Именно так, как написан, с точкой в начале и без.txt в конце

Checking if the Joomla! temporary folder is publicly accessible — Проверяется: доступен ли каталог для временных файлов Joomla для открытого доступа. Что подразумевается под этим? Проще говоря, возможно ли набрать в адресной строке браузера ссылку вида www.ваш сайт.com/tmp.

Не все знают, что разместить временный каталог возможно так, что доступ к нему будут получать исключительно скрипты Joomla. Достаточно создать папку с произвольным именем уровнем выше каталога, где расположен сайт и прописать путь к этой папке в файле configuration.php

Checking your Session Handler — Проверка типа обработчика сессий. Нам рекомендуют поставить значение «Нет». Сделать это можно в общих настройках Joomla

Раздел Server Configuration

Перейдем к исследованию следующего раздела, где проводился анализ конфигурации сервера.

Мы видим, что конфигурационные директивы PHP с точки зрения компонента не настроены должным образом.

Разбираться в том какая директива за что отвечает необходимости нет. Однако, предварительно нужно решить вопрос со временным каталогом Joomla, про который я писал выше.

Скопируйте его на жесткий диск своего компьютера, а из корня сайта удалите, ибо он носит исключительно информативный характер и сообщает значение директив PHP, которые вы должны вставить в свой php.ini

Как его найти на сервере и разрешен ли туда доступ, следует уточнить у вашего хостинг провайдера. Нередко директивы PHP меняются путем изменения настроек хостинг панели. Поэтому универсального рецепта здесь нет.

Раздел Scan Result

Здесь представлены результаты сканирования вашей системы. Предлагаю изучить их результат.

Scanning the integrity of your Joomla! (CMS) files — в данном разделе будет показан результат сканирования файлов CMS Joomla и сравнение с оригинальным дистрибутивом на целостность и возможное изменение файлов. Сравниваться будут не только скрипты, но также файлы изображений, CSS. В общем, все.

Scanning your folders — сканирование по протоколу FTP посетить каждый и убедиться, что он чист от вредоносных скриптов

Scanning your files — в данном случае идет речь о правах на файлы. Действия должны быть аналогичными, как в случае с каталогами

Scanning your files for common malware — сканирование на предмет наличия вредоносного кода. Как видим, RSFirewall нашел один файл и при его анализе в текстовом редакторе, он был признан действительно вредоносным и удален мной с сервера.

Подведем итоги

К сожалению, в рамках одного материала охватить все возможности и настройки компонента RSFirewall не представляется возможным. В следующем материале мы займемся исследованием конфигурации компонента.

Если вы не готовы самостоятельно решить вопрос со взломом сайта, напишите через раздел «Контакты», либо в чат в правом нижнем углу экрана.

Лечение сайта осуществляется платно.

Актуальная стоимость работ указана на странице: «Лечение сайтов (CMS Joomla) от вирусов »

С уважением, Владимир Егоров

Мы уже рассмотрели различные способы и средства защиты Joomla от хакерских атак и вирусов. Но что делать, если ваш сайт уже заражен? Как его вылечить?

В этой статье приведено пошаговое руководство лечения сайта на Joomla от вирусов (приведенные шаги актуальны и для сайтов на других CMS). Выполните все шаги, и ваш сайт будет восстановлен.

Кто и зачем заражает сайты вирусами?

Предположим, что в один «прекрасный» день хостер или Яндекс.Вебмастер сообщили вам, что на вашем сайте обнаружены вредоносные скрипты. Первые мысли, которые приходят в голову после такой новости: «Да как так? Почему мой сайт? У нас ведь маленькая компания. Кто? Конкуренты? Зачем? Как?».

Давайте, в первую очередь, разберемся в теоретических причинах заражения. Предположим, что у вас действительно не столь посещаемый сайт, чтобы заинтересовать хакеров (его посещают десятки – сотни человек ежедневно). Кто, зачем и как заразил ваш сайт?

Не стоит сразу перебирать врагов и конкурентов. Скорее всего, заражение вашего сайта – это случайность и опосредовано, виноваты в нем ВЫ (или веб-мастер, который отвечает за ваш сайт компании).

Вы спросите: «Каким образом?». Приведу пример из обычной жизни. Скоро зима. Ожидается эпидемия гриппа. Вам уже все уши прожужжали о необходимости прививки, гигиены, избегания многолюдных мест в пик эпидемии. Но вы решили: «Фу, ерунда какая! Уже столько лет живу и не болею без всяких там прививок и советов!» и проигнорировали все предостережения. Пришла зима. Вы заразились гриппом. Кого в этом винить? Человека, который чихнул на вас? Или, может быть, государство, которое насильно не вкололо вам вакцину? Или, все-таки, себя любимого?

С большой долей вероятности точно также получилось и с вашим сайтом.

Спросите себя:

• Я регулярно обновляю Joomla и все используемые на сайте расширения?
• Я изменил стандартный адрес админки?
• На компьютере, с которого я вхожу в админку сайта, есть антивирус?

Невыполнение хотя бы одного из этих трех пунктов уже подвергает ваш сайт высокому риску.

Дальше в дело вступает лотерея. Предположим, в один прекрасный день кто-то обнаружил уязвимость в Joomla. Он отправил информацию о ней разработчикам Joomla. Они исправили уязвимость и выпустили обновленную версию. Через некоторое время о найденной уязвимости становится известно широкой публике, в которой встречаются и не очень хорошие личности. Одна из таких личностей пишет паука – программу, которая сканирует интернет на предмет поиска необновлённых сайтов с этой уязвимостью и, находя их, использует уязвимость для взлома.

Ну, вот скажите мне, кто здесь виноват? Сначала неопытные веб-мастера нагружают сайт на Joomla десятком-другим сторонних расширений, потом передают такой сайт заказчику, берут оплату и удаляются. Заказчик не очень в теме по поводу обновлений и уязвимостей. Он работает с контентом сайта. Так проходит пара лет. Потом сайт находит паук, настроенный на эксплуатацию одной из свежих уязвимостей в одном из расширений Joomla, установленных на сайте. А потом заказчик и веб-мастер, который делал сайт, в два горла кричат, что Joomla – дырявый движок.

Конечно, нельзя исключать и целенаправленной хакерской атаки на ваш сайт, но вероятность такой атаки очень мала по сравнению с тем, что вы поймали паука. Я бы сказал, 1% против 99%. С ростом популярности, посещаемости и показателей вашего сайта вероятность будет смещаться в сторону хакерской атаки, но пока ваш сайт не содержит ничего особо ценного, хакеры не будут тратить на него время, т.к. их время стоит дороже.

В общем, наиболее вероятные первопричины заражения должны быть вам ясны. Можно вырвать у себя на голове пару клоков волос, пару раз удариться головой о стену со словами «#@@*$#!!!» (или ударить головой о стену веб-мастера, который обслуживал сайт =)) и после этого приступать к лечению сайта.

Мой сайт заражен. Что делать?

Ваш сайт заражен. Чтобы вылечить его, а предлагаю вам использовать инструкцию, состоящую из 10 шагов. Выполнять шаги нужно последовательно, а не в произвольном порядке.

Шаг 1. Резервная копия.

Если ваш сайт заражен, то по уровню халатности вы попадаете в одну из двух категорий:

1. Я регулярно делаю резервные копии своего сайта / Я настроил регулярное резервное копирование на хостинге.
2. Резервные копии? Ээээ… Что это?

Если вы попали в первую категорию, то у меня для вас хорошие новости: вам не придется лечить сайт от вирусов. Просто восстановите резервную копию и переходите к шагу 7 .

Если же вы попадаете во вторую категорию, то придется попотеть, либо потратиться на специалиста. Кроме того, для вас есть и очень плохая новость:

При чистке сайта от вирусов нет, и не может быть никакой гарантии полного излечения.

Давайте разберемся почему.

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

Примерно такой же принцип в заражении сайта. Файлы сайта, коих несколько тысяч, могут быть изменены. Также могут быть добавлены новые файлы, с названиями, которые себя ничем не выдают. Вирус может записать себя в любые каталоги и файлы файловой структуры сайта. Потом сайт почистят от вирусов. Все зараженные файлы удалят. Но где гарантия, что один из таких файлов не будет упущен? Ее нет. А такой файл может, в конечном итоге, привести к повторному заражению всего сайта.

Всё это не значит, что нужно опустить руки и пойти делать новый сайт. Всё-таки, шаги, описанные далее, позволяют в высокой долей вероятности вычистить весь вредоносный код, до последней строчки.

Подведем итог шага 1.

• Если вы делали резервные копии, найдите ту из них, которая еще не заражена и восстановите из нее сайт. Далее переходите к шагу 7.
• Если вы не делали резервные копии, будьте готовы к тому, что никто не даст вам 100% гарантии на полную отчистку сайта от вирусов. Переходите к шагу 2.

Шаг 2. Создание копии сайта и первичная проверка.

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

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

Стандартный Joomla-сайт состоит из двух частей:

• Файловая система сайта
• База данных

Вредоносный код может быть и в файлах и в базе данных, но всё-таки наиболее вероятно найти его в файлах.

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

Если у вас есть лицензионный обновленный антивирус на компьютере, то можете использовать его.

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

После проверки будет найдено несколько вирусов или не найдено ничего. Найденные зараженные файлы лечим (вручную отчищаем от вредоносного кода) или удаляем. Переходим к шагу 3 .

Шаг 3. Проверка специализированными инструментами

На этом этапе разминка закончилась. Впереди рутиный и нудный труд. Пришло время проверить зараженный сайт специализированным средствами поиска вредоносного кода. К таковым относятся:

• AiBolit – бесплатный сканер вирусов и вредоносных скриптов. Он удобен тем, что может быть очень легко запущен под Windows.
• Manul – антивирусная утилита от Яндекса.

Советую использовать AiBolit, поскольку проект Manul закрыт Яндексом и более не обновляется. По результатам проверки для вас будет сгенерирован отчет о подозрительных файлах и уязвимостях.

Проверка AiBolit.

1. Скачиваете с официального сайта AiBolit для Windows.
2. Копируйте файлы зараженного сайта в папку site .
3. Запускаете файл start.bat .

По результатам будет сгенерирован файл отчета AI-BOLIT-REPORT. html

Проверка Manul.

Manul – это php-скрипт. Чтобы его запустить, нужен локальный web-сервер. Вы можете использовать для этих целей Open Server или Denwer . Далее следуйте инструкциям с официального сайта Manul.

Важно! Ни в коем случае не запускайте на локальном сервере зараженный сайт. Не вылеченные на данном этапе вредоносные скрипты могут размножиться.

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

Далее следует довольно нудный этап. Нужно вручную пройтись по всем подозрительным файлам и проверить код, расположенный в них. Зачастую вредоносный код выделяется форматированием из основного. Код Joomla стройный и не содержит ничего лишнего. Код вредоносных скриптов часто внедряется без форматирования. Посмотрите пример ниже.

Код вредоносного скрипта:

Подсказки:

Не бойтесь открывать зараженные php-файлы для просмотра через текстовый редактор. Пока не запущен интерпретатор PHP (локальный сервер, который может выполнить PHP-код), вирусы и вредоносные скрипты не представляют опасности.

Если зараженных файлов найдено слишком много, можно воспользоваться такой хитростью: уточните текущую версию Joomla на вашем сайте, скачайте именно эту версию с официального сайта. Скопируйте файлы скачанной версии в папку с зараженной, переписывая совпадения. Таким образом, вы сможете переписать большую часть зараженных файлов оригинальными. Аналогичным образом можно заменить файлы крупных расширений Joomla. Более подробно это описано в шаге 5.

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

Данный шаг может отнять много времени, а также может быть сложен для тех, кто не очень хорошо разбирается в PHP-коде. Общий совет: если сомневаетесь вредоносный перед вами скрипт или нет, считайте, что да. Не бойтесь удалять зараженные файлы Joomla и расширений. На следующих шагах мы их восстановим. Исключение составляют лишь файлы, находящиеся в каталоге используемого вами шаблона сайта. Их не получится восстановить и работать с ними нужно очень осторожно.

Когда все файлы из отчетов проверены/отчищены/удалены, проведите сканирование файловой структуры сайта повторно. Не должно быть найдено ничего. После этого можно переходить к шагу 4 .

Шаг 4. Поиск повторений и работа с датами создания файлов.

Теперь пришла пора постепенно включать голову. Надеюсь, что вы последовали моему совету, на предыдущем шаге и копировали фрагменты кода вредоносных скриптов в отдельный файл.

Если вирус, которым заражен ваш сайт, писал не гений, а скорее всего это так, то от файла к файлу зараженные фрагменты кода должны, так или иначе, повторяться. Этим мы и воспользуемся для того чтобы найти то, что пропустили сканеры и антивирусы.

Для выполнения данного шага нам понадобится программа Total Commander или любая другая утилита, умеющая искать по файлам. Я все же советую использовать Total Commander.

Открыв файловую структуру сайта через Total Commander, переходим в Команды –> Поиск файлов…

Здесь нам интересны две вкладки.

Вкладка «Общие параметры»:

Позволяет указать текст, который нужно искать в файлах. У вас уже есть сохраненные фрагменты кода вируса. Смекаете? Выбираем фрагмент и ищем его повторения в файлах по всей файловой системе сайта. Будьте уверены, что-то найдется. Далее проверяем найденные файлы, чистим/удаляем.

Вкладка «Дополнительно»:

Еще одна прекрасная возможность найти все зараженные файлы – использовать дату изменения файла. Посмотрите еще раз внимательно отчет AiBolit . Он показывает дату создания/изменения подозрительных файлов. Вероятнее всего все зараженные файлы были созданы примерно в недельный временной промежуток или даже в один день. Вычислите его, а затем задайте на вкладке Дополнительно этот промежуток или день. Так вы сможете определить все подозрительные файлы.

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

После выполнения всех описанных действий можно выполнять шаг 5 .

Шаг 5. Восстановление файловой структуры сайта.

К данному этапу файловая структура вашего сайта, скорее всего уже не содержит вирусов, но, она уже и не является работоспособной. Вы изменили и удалили множество файлов. Наверняка среди них были и «невинно погибшие». Теперь пришло время восстановить файловую структуру сайта, а заодно и выполнить еще один шаг по его отчистке.

Этапы тут следующие:

1. Откройте админку зараженного сайта (старого, не отчищенного!) и перейдите в Расширения –> Менеджер расширений –> Управление.
2. Перепишите себе все установленные сторонние расширения и их версии. Запишите версию Joomla.
3. Скачайте Joomla заданной (не последней!) версии и все расширения заданных версий.
4. Обновите вручную файловую структуру Joomla путем копированием скачанной версии с заменой.
5. Обновите вручную файловую структуру расширений путем копирования с заменой.

Выполнив эти пункты, вы можете быть уверены, что все исполняемые файлы сайта чисты. Теоретически, зараженными могут остаться только файлы, которые были созданы вирусом и которые создали вы. Также, если у вас на сайте установлено несколько шаблонов Joomla, очень внимательно нужно проверить их файлы. Файлы шаблонов не перезаписываются при обновлении.

На данный момент, мы сделали всё, что было в наших силах, чтобы отчистить и восстановить файловую структуру сайта. Пришло время базы данных. Переходим к шагу 6 .

Шаг 6. Чистка базы данных сайта.

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

1. Скачать дамп базы данных сайта и проверить его вручную. Вы можете скачать через PhpMyAdmin базу данных сайта в виде текстового файла и открыть ее через Nodepad++ или другой текстовый редактор. Данный файл желательно просмотреть на предмет присутствия странных фрагментов, проверить на наличие опасных элементов, таких, как iframe.
2. В таблице #__ users базы данных сайта, найти всех пользователей с правами суперадминистратора и проверить, нет ли там посторонних.

После этого нужно развернуть и запустить сайт на локальном сервере (шаг 7 ).

Шаг 7. Тестовый запуск.

Поскольку я, в некоторой степени, параноик, советую на этом шаге запускать сайт на локальном сервере с отключенным интернетом.

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

1. Обновляем Joomla до последней версии путем установки обновления через менеджер расширений Joomla.
2. Обновляем все расширения до последних версий путем установки обновлений через менеджер расширений Joomla.

После этого сайт должен работать корректно и без ошибок. Если что-то осталось, исправляем вручную и переходим к шагу 8 .

Шаг 8. Смена всех паролей.

Изменяем:

• Пароли администраторов
• Пароль на сервере базы данных
• Пароль FTP
• Пароль от панели управления хостингом

На этом всё, ваш сайт отчищен. Осталось убедиться, что уязвимость, которая привела к заражению, закрыта.

Шаг 9. Анализ и устранение причин заражения

Снова включаем голову (да знаю, она у вас уже устала и ничего не соображает). Что же всё-таки привело к заражению? В начале статьи я дал пару мыслей на этот счет.

Постарайтесь понять, где на вашем сайте могут быть уязвимости. Не обязательно быть большим специалистом. Важно просто здраво мыслить.

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

Также почитайте информацию о расширениях Joomla, которые вы используете на сайте. Какое-то из них может быть уязвимым.

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

Шаг 10. Запуск сайта и отслеживание изменений.

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

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

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

Но что делать, если даже после чистки и восстановления сайта вирусы появляются вновь? Здесь есть два варианта:

1. Вы можете отдать уже отчищенную копию специалистам по безопасности, чтобы они проверили ее на предмет того, что упущено вами.
2. Вы можете создать новый сайт (в некоторых случаях это может быть дешевле), но надеюсь, что до этого, всё-таки, не дойдет.

Главный вывод.

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

Главное, что нужно делать, чтобы не оказаться один на один с взломанным сайтом – регулярное резервное копирование. Позаботьтесь о том, чтобы у вас на компьютере хранилась хотя бы одна резервная копия за каждый месяц, и спите спокойно;-).

Вконтакте

Если у вас есть доступ к сайту по SSH, вы можете найти файлы с инжектированным кодом выполнением следующих команд:

#grep -lr --include=*.php "eval(base64_decode" /pathWebroot #grep -lr --include=*.php "strrev(" /pathWebroot

Если доступа нет, можете попросить службу поддержки хостинга сделать это за вас и выслать вам отчет.

Вот пример листинга: ./components/com_wrapper/wrapper.php ./components/com_wrapper/controller.php ./components/com_wrapper/router.php ./components/com_wrapper/views/wrapper/view.html.php ./components/com_banners/models/banner.php ./components/com_banners/models/banners.php ./components/com_banners/controller.php ./components/com_banners/router.php ./components/com_finder/views/search/view.html.php ./components/com_finder/helpers/route.php ./components/com_finder/helpers/html/filter.php ./components/com_finder/helpers/html/query.php ./components/com_finder/controllers/suggestions.json.php ./components/com_jshopping/tables/productfiles.php ./components/com_jshopping/tables/statictext.php ./components/com_jshopping/tables/country.php ./components/com_jshopping/tables/productlabel.php ./components/com_jshopping/tables/shippingext.php .... ./administrator/components/com_jshopping/controllers/orderstatus.php ./administrator/components/com_jshopping/controllers/shippingsprices.php ./administrator/components/com_jshopping/controllers/vendors.php ./administrator/components/com_jshopping/controllers/productlabels.php ./administrator/components/com_jshopping/controllers/categories.php ./administrator/components/com_cache/cache.php ./administrator/components/com_cache/models/cache.php ./administrator/components/com_cache/controller.php ./administrator/components/com_cache/views/purge/view.html.php ./administrator/components/com_cache/views/cache/view.html.php ./administrator/components/com_cache/helpers/cache.php ./administrator/components/com_content/tables/featured.php

Итого 1606 вхождений. Это практически все PHP файлы. Удалять инжектированный код вручную бесполезно. На это уйдет слишком много времени. Обнаружен и новый файл images/post.php для исполнения любого кода.

Удаление вредоносного кода из зараженных файлов

Сначала необходимо сделать полную резервную копию сайта на тот случай, если что-то пойдет не так.

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

#grep -lr --include=*.php "eval(base64_decode" /pathWebroot | xargs sed -i.bak "s/eval(base64_decode[^;]*;//" #grep -lr --include=*.php "strrev(" /pathWebroot | xargs sed -i._bak "s/$_ = strrev([^;]*; @$_([^;]*;//"

Команды удалят все вхождения подобного вредоносного кода из файлов и сделает их резервные копии с расширением.bak. Это позволит вам только выиграть время для осуществления полного восстановления сайта, но не избавит вас от последующих атак. Следует понимать, что высока вероятность наличия файлов, типа images/post.php описанного выше, для исполнения любого кода и старые дыры в установленных расширениях.

Сторонние расширения

Если вас не лишили административной панели сайта, вы можете посмотреть установленные компоненты, модули, плагины и шаблоны. Если доступа нет, необходимо просмотреть содержимое сайта подключившись по FTP или SSH.

Смотрим список модулей

#ls ./modules index.html mod_banners mod_login mod_users_latest mod_articles_archive mod_breadcrumbs mod_menu mod_weblinks mod_articles_categories mod_custom mod_random_image mod_whosonline mod_articles_category mod_feed mod_related_items mod_wrapper mod_articles_latest mod_finder mod_search mod_articles_news mod_footer mod_stats mod_articles_popular mod_languages mod_syndicate #ls ./administrator/modules index.html mod_latest mod_menu mod_quickicon mod_title mod_custom mod_logged mod_multilangstatus mod_status mod_toolbar mod_feed mod_login mod_popular mod_submenu mod_version

Используются только стандартные модули Joomla

Смотрим список компонентов

#ls ./components com_banners com_finder com_media com_search com_wrapper com_contact com_jshopping com_newsfeeds com_users index.html com_content com_mailto com_phocapdf com_weblinks #ls ./administrator/components com_admin com_config com_installer com_media com_phocapdf com_users com_banners com_contact com_joomlaupdate com_menus com_plugins com_weblinks com_cache com_content com_jshopping com_messages com_redirect index.html com_categories com_cpanel com_languages com_modules com_search com_checkin com_finder com_login com_newsfeeds com_templates

Кроме стандартных компонентов используются com_jshopping и com_phocapdf .

Смотрим список плагинов

#ls ./plugins authentication content editors-xtd finder phocapdf search user captcha editors extension index.html quickicon system

Кроме того, необходимо просмотреть содержимое всех этих папок. Они представляют собою группы плагинов.

#ls ./plugins/authentication gmail index.html joomla ldap #ls ./plugins/captcha index.html recaptcha #ls ./plugins/content emailcloak geshi joomla pagebreak rokbox finder index.html loadmodule pagenavigation vote #ls ./plugins/editors codemirror index.html none tinymce #ls ./plugins/editors-xtd article image index.html pagebreak readmore #ls ./plugins/extension index.html joomla #ls ./plugins/finder categories contacts content index.html newsfeeds weblinks #ls ./plugins/quickicon extensionupdate index.html joomlaupdate #ls ./plugins/search categories contacts content index.html newsfeeds weblinks #ls ./plugins/system cache highlight languagecode log p3p remember sef debug index.html languagefilter logout redirect rokbox #ls ./plugins/user contactcreator index.html joomla profile

Кроме стандартных плагинов используется плагин phocapdf .

Смотрим список шаблонов

#ls ./templates atomic beez_20 beez5 index.html system templ1

Кроме стандартных шаблонов используется templ1 .

Восстановление зараженного сайта

• Скачиваем дистрибутив последнего релиза, распаковываем архив в директорию будущего сайта и удаляем из нее директорию installation.
• Переименовываем файл htaccess.txt в.htaccess. Если в нем использовались директивы записанные вами , перенесите их из зараженной копии.
• Копируем файл configuration.php из зараженной копии, предварительно просмотрев на отсутствие в нем инжектированного кода.

Сторонние расширения

• Находим используемые сторонние компоненты Phoca PDF, JoomShopping, плагин "Phoca PDF Content Plugin", скачиваем.
• Распаковываем и копируем файлы, предварительно создав структуру директорий как у зараженной копии. Не забываем про файлы локализации.

Немного сложнее обстоит дело с шаблоном. Шаблон сгенерирован специальным программным обеспечением и найти его не представляется возможным. Придется "выковыривать из него все ненужное".

К счастью, в шаблоне присутствует 21 PHP файл и весь инжектированный код был удален командой #grep -lr --include=*.php "strrev(" /pathWebroot | xargs sed -i._bak "s/$_ = strrev([^;]*; @$_([^;]*;//"

Собственные файлы

• Создайте каталоги, в которых вы держали изображения, документы и прочие файлы и скопируйте их.

Сайт должен начать работать сразу, как только вы замените старое содержимое новым.

Зайдите в административную панель сайта, замените имя пользователя и пароль доступа к CMS и посмотрите, не заменен ли e-mail SuperUsers (злоумышленник может воспользоваться функцией восстановления забытого пароля). Никогда не используйте стандартное имя пользователя admin . Внимательно посмотрите права всех пользователей. Не исключена возможность заведения злоумышленником еще одного администратора.

Замените имя пользователя, пароль к базе данных MySQL, если используется стандартный префикс таблиц базы данных jos_ необходимо его заменить другим, это предотвратит вероятность атаки SQL инъекциями.

По окончанию восстановительных работ установите плагин BotsGo404.

Если эта статья показалась вам полезной, пожалуйста, проголосуйте за нее. Это поможет другим быстрее найти эту статью из множества других менее полезных. (17 Голосов)