Взломали сайт, помогите найти дыру в защите

#администрирование #ssl #хостинг #защита #взлом

Доброго времени суток!

Я администрирую сайты у нас в компании.
Недавно нам взломали сайт, и не один. Атакам ежедневно подвергаются все сайты, находящиеся
на хостинге. Выглядит это как добавление php файлов, архивов и целых папок в корни
сайтов и в директории типа images.
Результатами взлома сначала являлась подмена главной страницы для роботов гугл, затем
2 рассылки с нашего почтового сервера и рассылка со ссылкой на нехороший файл на одном
из наших сайтов.

Что было сделано:


Почистили все от вредоносного кода, обновили cms основного нашего сайта, так как
сначала думали, что только он был взломан, запретили доступ к системным папкам по другим ip.
Поменяли все пароли (к ftp, cms, бд). 
Дальнейшие действия не очевидны. Наш хостер не дает изолировать друг от друга папки
на хостинге, как и не может ограничить доступ к ftp по другим ip( 


Какой следующий шаг?

UPD 4.12.17


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


UPD 18.12.17


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


Спасибо всем за помощь. С наступающим вас!
    

Ответы

Ответ 1

Можно попробовать перекрыть вот этот вектор атаки:


  Выглядит это как добавление php файлов, архивов и целых папок в корни сайтов и
в директории типа images.


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



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

В UNIX-подобных ОС без использования ACL такого поведения можно достигнуть включив
обоих пользователей в одну группу, далее первый пользователь делается владельцем файлов
и директорий, и права на файлы устанавливаются 640 (740 на директории или 750 если
важен листинг директории).

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

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


    RemoveHandler .php .phtml .php3
    RemoveType .php .phtml .php3
    AllowOverride None



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

При использовании Nginx надо закрыть директории со статикой от поиска в них скриптов
через использование ^~:

location ^~ /uploads/ {
    try_files $uri =404;
}


Также в случае использования сайтом паттерна Front Controller можно отказаться от
популярного location ~* \.php(/|$) в пользу непосредственного направления нужных маршрутов
на фронт-контроллер (да, для этого придется внимательно изучать используемую CMS):

location / {
    fastcgi_pass  127.0.0.1:9000;
    fastcgi_param SCRIPT_FILENAME /path/to/index.php;
    fastcgi_param PATH_INFO       $uri;
}


Если у вас внезапно Windows и IIS - надо убрать все обработчики кроме статических
файлов и заблокировать конфигурацию от изменений:


    
        
            
            
        
    



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

3. После закрытия папок куда пользователи могут загружать файлы от загрузки туда
серверных скриптов надо закрыть их от загрузки html-страниц. Это уже атака не на ваш
сервер, а на ваших пользователей - но это же не означает что от нее не надо защищаться?

В Apache это делается через RemoveType .html (полный список типов уточните в своем
конфиге), в nginx надо будет явно перечислить разрешенные к загрузке типы файлов (types
{ ... }), а в IIS это делается настройкой system.webServer/staticContent по аналогии
со списком обработчиков (там можно как удалить несколько типов так и полностью составить
список с нуля).



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