RuWeb.net - хостинг и регистрация доменных имен
ГЛАВНАЯ ХОСТИНГ ДОМЕНЫ VDS СЕРВЕР ИНФОРМАЦИЯ КЛИЕНТЫ ПРАВИЛА ОПЛАТА ЗАКАЗ ФОРУМ
go to bottom

Версия для печати | Подписаться | Добавить в избранное  
Автор: Тема: Взлом CMS
timru
Administrator
********




Сообщения: 38
Зарегистрирован: 12.10.2008
Пользователя нет на форуме


[*] когда размещено 27.9.2014 в 00:33
Взлом CMS


В последнее время участились случаи взлома сайтов через уязвимости в CMS (системах управления содержимым), таких как Joomla, WordPress, Drupal и др., или их компонентах. Владельцы сайтов зачастую не занимаются обновлениями CMS, либо делают это редко и неохотно, ошибочно полагая что "раз оно работает, то будет работать и дальше". В результате злоумышленникам удается заливать на сайты сторонние файлы, и использовать их для осуществления компьютерных преступлений. Причем сам владелец, как правило, остается в неведении, так как его сайт продолжает нормально функционировать. На уведомления от техподдержки он часто не реагирует, либо не понимает их сути. Вникнуть в проблему он пытается уже только после того как его сайт блокируется за нарушение правил хостинга.

Рассмотрим типичный случай. Чужеродный файл обычно размещается злоумышленником не в корне сайта, а где-нибудь поглубже в иерархии каталогов, либо в каталоге уязвимого компонента, через который и был произведен взлом. Например, здесь: http://имя-сайта.ру/wp-content/plugins/more-fields/core.php. Как правило, он имеет безобидное название (например core.php, system.php, script.php и т.д.) и обратимо зашифрованный код, например:
<?php
eval(gzinflate(base64_decode('80jNyclXyFTPVUhJTc5PSU0BAA==')));
?>

В зависимости от содержимого файла, он может например:
а) рассылать спам (причем сам текст рассылки и базу данных e-mail он не содержит, такие данные передаются злоумышленником уже в процессе обращения к этому файлу);
б) переадресовывать посетителя на другой сайт (например adult-тематики), ссылка на него обычно рекламируется посредством спам-рассылок с других серверов;
в) являться поддельной страницей какого-нибудь зарубежного банка или платежной системы, предлагающей ввести данные пользователя (которые впоследствии отправляются злоумышленнику);
г) являться PHP-шеллом (т.е. командной оболочкой, доступной через веб, и позволяющей злоумышленнику выполнять любые действия, в частности выполнять атаки на другие сервера).

О подобных случаях в конце-концов становится известно нам, о чем мы уведомляем владельца через нашу тикет-систему, и, как правило, принимаем временные меры по их предотвращению путем блокировки/переименования/удаления таких файлов.
Уведомления от нас, соответственно, выглядят следующим образом:
а) жалоба на спам: с вашего сайта производится спам-рассылка, и текст письма вместе с RFC-заголовками, в которых часто фигурирует заголовок с названием скрипта, с помощью которого было отправлено письмо, например:
X-PHP-SCRIPT : http://имя-сайта.ру/wp-content/plugins/more-fields/core.php
б) жалоба на рекламу спамом: ваш сайт рекламируется посредством спам-рассылок, и текст письма вместе с RFC-заголовками, в теле письма фигурирует ссылка: http://имя-сайта.ру/wp-content/plugins/more-fields/core.php
в) жалоба на фишинг: на вашем сайте находится поддельная страница банка, и ссылка на адрес такой страницы: http://имя-сайта.ру/wp-content/plugins/more-fields/core.php;
г) жалоба на атаку: с вашего сайта ведется атака, и ссылка на PHP-шелл: http://имя-сайта.ру/wp-content/plugins/more-fields/core.php

К сожалению, очень часто, наши уведомления остаются без ответа. Типичные заблуждения владельца сайта:
а) "я не рассылаю спам, это какая-то ошибка" (слепая вера в то, что кроме владельца никто другой никаких рассылок с сайта делать не может);
б) "хостер уже что-то сделал, заблокировал, принял меры, значит мне делать ничего не нужно" (игнорирование предупреждения о том что принятые нами меры лишь временные, и что проблема в скором времени может повториться снова);
в) "это не мои проблемы" (мнение что хостер несет полную ответственность за безопасность на сайте, несмотря на то что хостинг - это лишь площадка для работы программного обеспечения клиента, ответственность за которое лежит уже на владельце аккаунта).

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

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

----------------------------------------------------------------

Что делать для защиты ваших сайтов (советы с сайта searchengines.guru)
http://searchengines.guru/showthread.php?t=774117

1. изоляция сайтов (один сайт - один эккаунт)
2. все директории и файлы cms делаем read-only
3. все директории, в которые производится загрузка файлов или кэширование - делаем read-write и кладем в них волшебный .htaccess, который либо делает

deny from all

либо запрещает вызов php

Options -Indexes
php_flag engine 0

RemoveHandler .phtml .php .php3 .php4 .php5 .php6 .phps .cgi
.exe .pl .asp .aspx .shtml .shtm .fcgi .fpl .jsp .htm .html .wml
AddType application/x-httpd-php source .phtml .php .php3 .php4 .php5 .php6
.phps .cgi .exe .pl .asp .aspx .shtml .shtm .fcgi .fpl .jsp .htm .html .wml

4. на файл с данными БД ставим минимальные возможные права (например, 0400 или 0444)
5. закрываем админку через .htaccess для вашего IP или по кодовому слову
6. удаляем все ненужные плагины и шаблоны
7. обновляем cms и оставшиеся плагины до свежих версий
8. сканируем свой комп на вирусы Касперским и AVZ
9. пользуемся SFTP (SCP) протоколом при работе с сайтом и не храним пароли в клиенте
10. после проверки компьютера на вирусы меняем все пароли у сайта и хостинга (включая пароль от БД). И делаем это раз в два месяца хотя бы.

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

----------------------------------------------------------------

Интересные и полезные ссылки

Новая тема о вирусах
http://forum.ruweb.net/viewthread.php?tid=3025

Старая тема по безопасности на нашем форуме
http://forum.ruweb.net/viewthread.php?tid=2007

Безопасность CMS (рекомендации от Яндекса)
http://safesearch.ya.ru/replies.xml?item_no=120

Массовое поражение интернет-магазинов на базе osCommerce и блогов WordPress
http://www.opennet.ru/opennews/art.shtml?num=31377

Онлайн-декодер gzinflate(base64_decode...
http://www.tareeinternet.com/scripts/decrypt.php

Плагин FTPKey в панели управления DirectAdmin
http://forum.ruweb.net/viewthread.php?tid=2927


[Отредактировано 16.8.2015 кто timru]

[Отредактировано 31.5.2017 кто cosupport]
Просмотреть Профиль Пользователя Просмотреть все сообщения этого пользователя Отправить пользователю личное сообщение

Powered by XMB
Разработано Группа XMB © 2001-2008
[запросов: 21] [PHP: 68.1% - SQL: 31.9%]
go to top
Центр поддержки (круглосуточно)
https://ruweb.net/support/
Москва(499) 502-44-31
Санкт-Петербург(812) 336-42-55
Нижний Новгород(831) 411-12-44
Екатеринбург(343) 204-71-16
© 2002-2013 ЗАО "РУВЕБ"

Дизайн - CredoDesign
Rambler\'s Top100 Рейтинг@Mail.ru
RuWeb.net - Хостинг веб-сайтов (первый месяц - бесплатно). Регистрация доменов.