Загрузки вредоносного ПО

Написал им что все в порядке, санкции сняли.Ну, это вряд ли. Я на нем уже несколько лет.

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

У вас открыта регистрация новых юзверей на сайте? Посмотрите файл /engine/modules/functions.php на предмет переменных $set_cookie, $get_url_var, $news_num, $bannermass, $check_newsnum, $news_num, $check_category, $check_newsnum, $_REQUEST['newsnum'],  $_REQUEST['category'],  $_REQUEST['numer'],  $_REQUEST['bannerid']  (не функции!). Если хоть одну из них в файле найдете, не удивляйтесь что вас взламывают ))) (в чистом двиге их там не должно присутствовать)

Не нашел, но спасибо за наводку.

Это не от антибота. В нем все под контролем.

Картинки откуда? Содержимое файла проверяется при загрузке чтоб там внутри небыло xss вместо картинки? Через  getimagesize и прочие функции.

Mik Foxi, если в курсе, подскажи по дыре в ДЛЕ, которую я выше писал: если открыть регистрацию юзерам, то при регистрации вливают шелл в виде картинки (типа, аватар) и рядом htaccess ложат, где прописано что изображение это исполняемый php файл). Далее уже модифицируют /engine/modules/functions.php и по тихому рекламу подвешивают (разную, кто на что гаразд).

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

Я сам лично  подобные находил в двиге и на их форуме постил в раздел "Прием багов" - принимали и в последующих релизах правили. Я хоть и нуледом сам пользуюсь, но приятно что хоть лицуху не купил (точнее, ранее покупал, а потом забил, т.к. дыра на дыре у них), так полезное дело сделал для сообщества :)

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

Готового скрипта нету, но суть: смотрим через getimagesize тип картинки, в зависимости от типа открываем его функцией imagecreatefromjpeg и т.п., дальше сохраняем через imagejpeg. Все, гарантированно у тебя будет картинка настоящей картинкой, если это была не картинка, то обработка выдаст ошибку. Ну и заодно изменить размер, качество, exif данные  и т.п. обработать и оптимизировать картинку.

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

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

Не используйте apache =)) связка nginx+php-fpm более производительная

1. Не у всех сайт на VPS.
2. Зависит от CMS.
3. Насчёт "более" - это не обязательно/не существенно.

Когда один/два сайта однотипных на сервере - то самое оно, и то не намного быстрее.

А когда дела с разными двигами имеешь регулярно, то замучаешься правила htaccess переносить в конфигу nginx.