"На сайте вирус - Что делать?" Краткое руководство для начинающих сайтостроителей. - Безопасность сайтов на Joomla

Как это произошло?

Наиболее вероятная причина проблемы - следующий набор "дыр" в безопасности:

• Виноват в этом событии тот человек, который имеет пароль на доступ к директориям хоста по протоколу ftp (если таких людей много - один из них).
• Этот человек пользуется браузером Internet Explorer, каким-то ненадёжным файл-менеджером, и не пользуется антивирусом и файрволом (возможен вариант: антивирус есть, но старые базы данных, а файрвол не настроен). Немало нареканий в связи с кражей паролей возникало на антивирус NOD32.
• При посещении браузером IE сайта, который уже был заражён, в нём запускается JavaScript, загружающий на компьютер пользователя трояна (неэффективный антивирус не срабатывает).
• Троян сканирует систему и ищет файл-менеджеры/ftp-менеджеры (такие как Тотал Коммандер, ФайлЗилла и т.п.)
• После этого троян отправляет злоумышленнику файлы настроек этих файл-менеджеров, в которых хранятся пароли на ftp-доступ к сайту. Если при этом  файрвол выпускает исходящее соединение от трояна - значит неправильно настроен. Ещё одну ошибку допускает пользователь, который рискует сохранять пароли в ненадёжных программах.
• Злоумышленник получает и "вскрывает" файл настроек, извлекая из него логин, пароль и адрес ftp-сервера.
• После этого сетевой робот обходит сайты, к которым имеет пароль доступа по ftp, сканирует директории разыскивая файлы с названием index.html, index.shtml, index.php и т.п. и дописывает в эти файлы свой код. После этого при входе на сайт начинает срабатывать антивирус. Чаще всего в конец файла вставляется скрытый iframe с вредоносным кодом, подгружаемым с другого сайта. Помимо этого может вставляться код JavaScript, ссылки на другие сайты и т.п.
• Чтобы получить "документальное подтверждение" применения этой технологии взлома, нужно посмотреть логи доступа по протоколу ftp (логи http не помогут!)

Что делать - должно быть понятно из описания.  Нужно закрыть все дыры.

• Смените пароль ftp.
• По возможности ограничьте до минимума число людей, использующих ftp. Исключите тех, кто игнорирует требования безопасности.
• Удалите вирусный код по следующим вариантам:
  
  • Скачайте сайт на локальную машину и проверьте хорошим антивирусом со свежими базами (а лучше двумя разными антивирусами) содержимое директорий сайта на наличие шеллов и вирусного JavaScript.
  • Имейте в виду, что вирусный JavaScript, вставляемый в iframe (а это наиболее типичный вариант), как и JavaScript, вставляемый в страницу как src="http://чужой.домен/скрипт.js", антивирус при сканированни сайта на локальной машине не обнаружит, поскольку этот JavaScript "вставляется" в страницу только при просмотре в браузере. Поэтому если антивирус ничего не нашёл, ищите и удаляйте в файлах index.php, index.html и других индексных файлах тэги <iframe> и <script>, которые сами не вставляли. И помните, что злоумышленник не дремлет и возможны другие варианты вставки вредоносного кода.
  • В качестве альтернативного варианта, если есть резервная копия сайта, можно полностью удалить сайт с хоста и восстановить из резервной копии (не забудьте сохранить дамп базы данных, и все другие файлы, загружавшиеся непосредственно на хост).
• Перестаньте пользоваться IE.
• Не храните ftp-пароли в ftp-менеджерах.
• Постоянно пользуйтесь заслуживающим доверия антивирусом со свежими антивирусными базами.
• Установите и правильно сконфигурируйте файрвол.
• Если для доступа по ftp используется статичный IP или адрес IP из известного фиксированного диапазона, и Ваш хостинг позволяет это сделать, ограничьте доступ к директориям хоста по протоколу ftp этими адресами, используя .ftpaccess
• Регулярно читайте бюллетени уязвимостей (хотя бы этот раздел форума)

Обратите внимание! Это далеко не единственный возможный вариант взлома, но один из самых частых.

Следующим по частоте вариантом взлома, вероятно, являются SQL-инъекции, обусловленные недостаточной проверкой передаваемых в скрипт данных. При этом злоумышленники могут как вставлять нежелательный код в базу данных (и генерируемую движком страницу), нередко необратимо разрушая хранимые в БД "легальные" данные, так и читать данные из БД (в том числе хэши паролей). Нередко хакер, обнаруживший уязвимость скрипта, пишет так называемый "эксплоит" - небольшой фрагмент кода (последовательность команд), эксплуатирующий данную уязвимость. Если такой эксплоит публикуется на хакерских сайтах для широкого доступа, он может становиться источником "скрипт-киддинга" - массовых взломов малоквалифицированными "хакерами". В некоторых случаях эксплоит позволяет записывать в директории хоста шеллы (оболочки, которые позволяют делать с сайтом практически всё, что угодно). Решить проблемы sql-инъекций и других уязвимостей скриптов можно только грамотным программированием. Облегчить задачу поиска уязвимости в скриптах, как ни странно, может тот хакер, который эту уязвимость уже нашёл. Чтобы понять, каким образом был осуществлён взлом (какой из скриптов имеет уязвимость и в чём она состоит) иногда достаточно прочитать логи доступа к сайту по протоколу http (файл чаще всего имеет название access_log или похожее - как название так и расположение файла зависит от настроек конкретного сервера).

Ещё пара советов:

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

Дополнения и изменения приветствуются.