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