Сервер взломан - требуется выполнить резервное копирование rsync в обратном порядке. Это сработает? [дубликат]
Это канонический вопрос о Безопасность сервера - Реагирование на события взлома (взлом)
См. Также:
Каноническая версия
Я подозреваю, что один или несколько моих серверов скомпрометированы хакером, вирусом или другим механизмом:
- Каковы мои первые шаги? Когда я приду на место, должен ли я отключить сервер, сохранить «доказательства», есть ли другие начальные соображения?
- Как мне возобновить работу служб?
- Как предотвратить немедленное повторение того же самого? y снова?
- Есть ли лучшие практики или методики для извлечения уроков из этого инцидента?
- Если бы я хотел составить план реагирования на инцидент, с чего бы я начал? Должно ли это быть частью моего плана аварийного восстановления или обеспечения непрерывности бизнеса?
Исходная версия
2011.01.02 - Я иду на работу в 21:30. в воскресенье, потому что наш сервер каким-то образом был взломан, что привело к атаке DOS на нашего провайдера.Серверы доступа к Интернету были отключены, что означает, что более 5-600 сайтов наших клиентов в настоящее время не работают . Теперь это может быть взлом FTP или какая-то слабость в коде где-то. Я не уверен, пока не доберусь туда.
Как я могу это быстро отследить? Если я не восстановлю сервер как можно скорее, нас ждет много судебных разбирательств. Любая помощь приветствуется . Мы используем Open SUSE 11.0.
2011.01.03 - Всем спасибо за помощь. К счастью, я БЫЛ НЕ единственным человеком, ответственным за этот сервер, просто ближайшим к нему. Нам удалось решить эту проблему, хотя она может не относиться ко многим другим в другой ситуации. Я подробно расскажу, что мы сделали.
Мы отключили сервер от сети. Он выполнял (пытался выполнить) атаку отказа в обслуживании на другом сервере в Индонезии, , и виновная сторона также находилась там.
Сначала мы попытались определить, откуда на сервере это исходило, учитывая, что у нас более 500 сайтов на сервере, мы ожидали, что какое-то время подрабатываем. Однако, по-прежнему имея доступ по SSH, мы выполнили команду , чтобы найти все файлы, отредактированные или созданные в момент начала атак . К счастью, вредоносный файл был создан во время зимних праздников, что означает, что в то время на сервере было создано немного других файлов.
Затем мы смогли идентифицировать вредоносный файл, который находился в папке с загруженными изображениями на веб-сайте ZenCart .
После короткого перерыва мы пришли к выводу, что из-за расположения файлов они должны были быть загружены через средство загрузки файлов, которое не было должным образом защищено.После некоторого поиска в Google мы обнаружили уязвимость системы безопасности, которая позволяла загружать файлы в административную панель ZenCart для изображения для звукозаписывающей компании. (Раздел , который он на самом деле даже не использовал), при отправке этой формы просто загружался любой файл , расширение файла не проверялось, и даже не проверялось чтобы узнать, вошел ли пользователь в систему.
Это означало, что могут быть загружены любые файлы, включая файл PHP для атаки. Мы обезопасили уязвимость с помощью ZenCart на зараженном сайте и удалили вредоносные файлы.
Работа была сделана, и я был дома в 2 часа ночи.
Мораль - Всегда устанавливайте исправления безопасности для ZenCart или любой другой системы CMS, если на то пошло. Как и при выпуске обновлений безопасности, весь мир узнает об уязвимости. - Всегда делайте резервные копии и резервные копии своих резервных копий. - Нанять или нанять кого-то, кто будет будь там в такие времена. Чтобы никто не полагался на паническое сообщение об ошибке Server .