А вообще, лечение, как и профилактика стандартна и достаточно надежна: Ядро CMS скачиваем заново, подключаем БД и ставим плагины с нуля из репозитория (или другого официального источника).
Большинство шеллов ищется очень несложно. Начать можно с поиска по files_man(), а продолжить айболитами и тому подобными.
сперва нужно выяснить как они туда попадают и только потом лечить и латать иначе смысла нету.
сейчас люди достаточно ленивы поэтому редко встречаются вставки в код сайта а не сторонние файлы и метаданные не меняют, все находиться легко и просто финдом по дате модификации.
"Начать можно с поиска по files_man(), а продолжить айболитами и тому подобными."
я считаю это не универсально - пустая трата времени
IPzon: В случае с web-shell'ом - найти его действительно будет крайне сложно.
Это может быть даже не файл, а 1-2 строки кода в одном из файлов движка - в качестве примера
веб шелл находиться легко если сайт не самописный (методом сравнения файлов из дистрибутива), а вот бэкдор в ОС сложно
визуально с моим 20 мбит интернетом за 4 сек полностью загружается.
если в браузере изначально нет кэшированных элементов сайта то это не плохо.
наращивание серверных мощностей - для лентяев.
на шаред хостинге сайт может работать быстрее.
вообще смотрите визуально
1. время генерации странички
2. как грузиться и из каких элементов состоит страничка, возможно есть смысл применить спрайты/cжатие и объединение js и css/компрессия графики/etc
вообще какие могут быть советы без ссылки на сайт?
начните с простейшего - анализ access.log и логи медленных запросов sql (если хостер предоставит)
а какая разница какое расширение у файла? динамически генерируемые вставки есть - значит могут быть и уязвимости.
права на файлы тут не решают
а ботов не учитываете?
если сайты на популярных cms то от них нагрузка больше будет чем от живых посетителей
Ну есть еще плагины.
А вообще, лечение, как и профилактика стандартна и достаточно надежна:
Ядро CMS скачиваем заново, подключаем БД и ставим плагины с нуля из репозитория (или другого официального источника).
Большинство шеллов ищется очень несложно.
Начать можно с поиска по files_man(), а продолжить айболитами и тому подобными.
сперва нужно выяснить как они туда попадают и только потом лечить и латать иначе смысла нету.
сейчас люди достаточно ленивы поэтому редко встречаются вставки в код сайта а не сторонние файлы и метаданные не меняют, все находиться легко и просто финдом по дате модификации.
"Начать можно с поиска по files_man(), а продолжить айболитами и тому подобными."
я считаю это не универсально - пустая трата времени
В случае с web-shell'ом - найти его действительно будет крайне сложно.
Это может быть даже не файл, а 1-2 строки кода в одном из файлов движка - в качестве примера
веб шелл находиться легко если сайт не самописный (методом сравнения файлов из дистрибутива), а вот бэкдор в ОС сложно
Можем сделать VDS с панелью VESTA CP
Там можно все разнести по разным пользователям, и сама панель удобная.
там все равно остается лазейка :)
нужно настраивать софт.
берите реселлерский тариф тогда будет изоляция.
в случае впс нужна грамотная настройка, настройки по умолчанию при установки панели не дают изоляцию.
Подскажите плиз, сложная это система - скачивать файлы с rescue?
если сервер загружен с дисков то можете скачать и так бэкап, если в нормальном режиме не грузиться то загоняйте в rescue
нужно смонтировать массив или диск (что там у вас) а потом запаковать и скачать нужные файлы, с базами данных есть нюансы.
как уже написал если не разбираетесь то лучше попросите хостера иначе есть высокий риск потери информации.
http://wiki.hetzner.de/index.php/Hetzner_Rescue-System/ru