Pull to refresh

Comments 6

Спасибо за статью, очень полезно. В моем случае, сражаюсь с проблемой зловредных скриптов рассылающих письма.
Реквестирую статью, по методике отлова источника, который создает php шеллы (система контроля версий без проблем указывает на новые файлы на сайте, но того, кто их порождает отловить не удается)
Ну самое простое — посмотреть переменные окружения порожденных скриптов /proc/$pid/… поискать get подозрительные с строкой wget, post запросы… По найденным ip посмотреть логи.
Cron ещё посмотреть :))
скрипты php-ные, исполняются от php, по GET-у или POST-у извне.Так что pid единый от /usr/bin/php, я правильно понимаю?.. И похоже что дата создания зловредных скриптов подменяется. В итоге в логах каша из тысяч запросов к шеллам, к сложно найти управляющий POST который дает команду их создать.
IP в логах разные (перенаправляется трафик пользователей с поисковиков по кликам на выдачу по популярным запросам)
Права доступа на запись настроены, но CMS хочет как минимум /cache и /administrator/cache на запись — скрипты не растерялись — теперь там создаются :)
Cron чистый, слава богу не настолько все плохо, пароли меняются, auth log красивый
Настройте на сервере auditd. Вот, к примеру, статья о нём — https://habrahabr.ru/company/selectel/blog/267833/
При помощи него вы сможете отследить кто и когда создаёт файлы с шелами, скорее всего это будет ваш вэб-сервер, но так вы уже узнаете точное время создания файлов и сможете по логам отследить откуда их создают.
Права доступа на запись настроены, но CMS хочет как минимум /cache и /administrator/cache на запись — скрипты не растерялись — теперь там создаются :)
Да пусть сколько угодно создаются — зачем разрешать выполнение php в кэше?
https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/, см раздел 'Passing Uncontrolled Requests to PHP'
гениально! *посыпаю голову пеплом*
Действительно, зачем им выполняться, спасибо
Sign up to leave a comment.

Articles