Я запускаю Plesk 9.5 на Ubuntu 8.04 LTS и имею около 15 веб-сайтов, зараженных некоторым вредоносным кодом, добавленным в конец java-файлов. Я установил Clamav, и ему удалось забрать зараженные файлы, которые начинались с одного /*km0ae9gr6m*/ или /*gootkitstart*/ и заканчивая /*qhk6sa6g1c*/ или /*gootkitend*/
Моя панель Plesk обновлена, и были установлены исправления безопасности. Как я могу изолировать уязвимость системы безопасности на сервере?
Во-первых, если есть руткит, вы, вероятно, ведете бесконечную борьбу. Переведите сервер в автономный режим, переустановите и восстановите резервные копии, которые были до заражения. Это «лучший» способ исправления.
Во-вторых, были ли вы в курсе обновлений и т.п. до заражения или исправляли после?
В-третьих, какой пользовательский код работает на сервере вне Plesk? Откуда вы знаете, что это вообще был вектор заражения?
Без аудита и песочницы вам будет сложно сказать, что произошло. Если на нем работает база данных, у кого-то может быть неправильный код в системе. Если кто-то еще имеет доступ к серверу, возможно, они чем-то его заразили. Веб-сайты работают с разными правами доступа к файлам, чтобы избежать возможного ущерба? Или сайты в значительной степени разделяют все ресурсы? Участвуют ли другие пользователи и могут ли они запускать сценарии? У них установлены разные виджеты и еще много чего? Были ли файлы отмечены временными метками, чтобы вы могли вернуться в журналы и попытаться понять, что произошло?
Если журналы находятся на том же сервере, который был скомпрометирован, журналы также могли быть изменены.
В конце концов, лучше всего отключить сервер и исправить его, переустановив из резервных копий. В противном случае вы не сможете полностью ему доверять. А если у вас есть «личные» данные (пароли пользователей?), Их нужно сообщить, что их информация могла быть украдена. Затем начните настраивать какой-то аудит в системе и отправлять файлы журналов на вторичный сервер по безопасному каналу связи, чтобы журналы не могли быть стерты злоумышленником. И запустите какую-нибудь утилиту проверки файлов, такую как Stealth, на другом сервере, чтобы контролировать целостность вашего файла и предупреждать вас об изменениях.
Не зная, что еще работает на вашем сервере, другие люди мало что могут сделать, чтобы рассказать вам, как он был взломан.
Нет универсального подхода - все на практике. Обычно вам необходимо настроить расширенное ведение журнала, желательно не только из системы, которую вы проверяете, но также из независимой IDS, которую вы периодически архивируете. Кроме того, требуется большой опыт в области компьютерной безопасности и судебной экспертизы, иначе у вас нет шансов.
Но поскольку сегодня вредоносные программы обычно массово заражаются, велики шансы, что эта работа уже сделана за вас:
http://www.m86security.com/labs/i/GootKit--Automated-Website-Infection,trace.1368~.asp
Очевидно, что злоумышленники не заражают сотни веб-страниц вручную, они используют скрипт или ботнет, чтобы сделать работу за них. [...] Еще один такой бот известен как GootKit. [...] Мы не уверены, как именно управляющий сервер получил все учетные данные FTP, но чаще всего они были украдены с помощью клавиатурных шпионов и вредоносных программ для кражи информации, установленных на ПК администраторов веб-сайтов.
Мы наблюдали это на серверах plesk 9.5, несмотря на то, что с февраля были установлены исправления безопасности Parallel.
В основном они отправляются на страницу входа и входят без аутентификации, затем переходят прямо к файловому менеджеру WYSIWYG и добавляют код в файлы js. Plesk отказывается признавать это, и единственный вариант - отключить брандмауэр и разрешить определенные IP-адреса.
Вы найдете POST-сообщения в журнале httpsd_access в каталоге plesks admin / log.
Глобальный sed удалит код, поскольку, к счастью, все они начинаются с одной и той же строки.
Похоже, что ваши пароли просочились некоторое время назад и теперь используются для установки скриптов троянских дропперов. См. Следующие этот и этот для более подробной информации.
После пары ужасных недель потери клиентов и повторного заражения мы получили ответ от службы технической поддержки Parallels:
Обратите внимание, что все проблемы уязвимостей, о которых сообщалось в Интернете или на наших форумах, на самом деле восходят к старой уязвимости в Plesk, которая полностью описана в следующей статье базы знаний:
http://kb.parallels.com/113321
Эта информация также упоминается в статье №114379. Пожалуйста, внимательно проверьте статью № 113321 и связанные статьи, чтобы проверить наличие проблемы, установить все необходимые микрогрупповые даты и убедиться, что сервер защищен с помощью массового сброса пароля:
http://kb.parallels.com/en/113424 http://kb.parallels.com/en/9294 http://kb.parallels.com/en/113391
Что довольно интересно в отношении первого заявления, так это то, что 15 июля Parallels представила очередной патч «безопасности».
Я управляю сервером Plesk 9.5.4, который был заражен /km0ae9gr6m/ вредоносное ПО. К вашему сведению - на моем сервере вредоносный код был добавлен в файлы Javascript, PHP и HTML / HTM. Я отправляю сообщение, чтобы сообщить сообществу, что я использовал функцию ограничения IP-адресов Plesk во время заражения. Для ясности - в панели управления Plesk я запретил доступ для входа в систему Plesk для всех, кроме двух IP-адресов (моя собственная студия и офисный IP-адрес одного из моих клиентов). Несмотря на это ограничение, файлы журналов показывают логины для администратора с IP-адресов, которые не должны быть разрешены брандмауэром Plesk. С тех пор я установил идентичные ограничения адресов для порта 8443 с IP-таблицами, и на сегодняшний день (примерно 48 часов) больше не возникло проблем. Основываясь на моем опыте, я говорю, что не доверяйте свою безопасность ограничениям IP-адресов Plesk. Если кому-то интересно, буду рад поделиться своими лог-файлами.
Если вам нужно получить список затронутых файлов и иметь доступ по SSH, вы можете использовать следующее: grep -rl km0ae9gr6m / var / www / vhosts /
Будет выведен список всех файлов в вашем каталоге vhosts, содержащих сигнатуру вредоносного ПО. Я обнаружил, что проще всего отредактировать затронутые файлы с помощью файлового менеджера Plesk. В моем случае весь вредоносный код был добавлен в конец зараженных файлов.
Надеюсь, появится дополнительная информация о том, как эта атака смогла обойти как логин Plesk, так и ограничения IP-адреса.