Итак, вот оно что: на старом сайте, который мы размещали для клиента, была версия FCKEditor, которая позволяла кому-то загрузить на наш веб-хостинг ужасный эксплойт c99madshell.
Я не большой фанат безопасности -- честно говоря, я просто разработчик, который в настоящее время отвечает за обязанности S/A из-за потери персонала. Соответственно, я был бы рад любой помощи, которую вы, server-faulters, могли бы оказать в оценке ущерба от эксплойта.
Чтобы дать вам немного информации:
Файл был загружен в каталог в корневом каталоге веб-сайта, "/_img/fck_uploads/File/". Пользователь и группа Apache ограничены таким образом, что они не могут войти в систему и не имеют разрешений за пределами каталога, из которого мы обслуживаем сайты.
Все файлы имели права доступа 770 (пользователь rwx, группа rwx, другие нет) — я хотел это исправить, но мне сказали подождать, так как это не было «высоким приоритетом» (надеюсь, это изменит ситуацию). Так что, похоже, хакеры могли легко выполнить скрипт.
Теперь я не смог найти сам c99madshell.php -- только кучу других HTML-файлов, содержащих русский текст, и несколько .xl и .html-файлов со встроенным PHP, которые были интерпретациями хака madshell. Однако после небольшого исследования выяснилось, что хак, похоже, уничтожает себя после выполнения -- здорово.
В любом случае, моя первоначальная оценка будет такой:
Нет необходимости перестраивать весь хост, так как, учитывая изоляцию пользователя/группы Apache, они не должны были иметь возможности получить пароли системного уровня.
Необходимо устранить эту уязвимость, ограничив загрузки, чтобы они не имели разрешения на выполнение, обновив версию FCKEditor для исправления исходной цели эксплойта и добавив конфигурацию на уровне сервера, которая запрещает выполнение PHP-скрипта в каталоге загрузок.
Мне следует изменить пароли БД для приложения — учитывая, что файл конфигурации для подключения к базе данных находится в корневом каталоге веб-сайта, хакер, скорее всего, мог украсть его, а вместе с ним и пароль к БД.
В любом случае, пожалуйста, предоставьте любые соображения, которые у вас есть относительно того, что мне следует сказать боссу. Очевидно, было бы идеально избежать перестройки всего хоста -- но если это то, что нам нужно сделать, чтобы убедиться, что мы не используем взломанную машину, то это то, что нужно сделать.
Я действительно ценю вашу помощь, ребята. Также не стесняйтесь спрашивать больше информации (я был бы рад запустить команды / поработать с вами, ребята, чтобы оценить ущерб). Чертовы хакеры :(.
решение1
Очевидно, как уже говорили другие, официальным «безопасным» ответом было бы восстановление машины.
Реальность ситуации может помешать этому. Вы можете запустить несколько вещей, чтобы проверить компромиссы:
- Chkrootkit- тесты на общие признаки взлома сервера
- Если система rpm, 'rpm -Va|grep 5' проверит все установленные двоичные файлы rpm и выдаст "5", если сумма MD5 изменилась. Необходимо пересобрать, если вы обнаружили какие-либо несоответствия, не объясненные в настроенном двоичном файле.
- Проверьте /tmp на наличие подозрительных объектов.
- Проверьте 'ps fax' на наличие аномальных процессов. Если 'ps' скомпрометирован или с помощью других методов, у вас все еще могут быть запущены скрытые процессы.
- Если в ходе поиска вы обнаружили КАКИЕ-ЛИБО файлы, владельцем которых является не Apache, ваши системные учетные записи определенно были скомпрометированы, и вам необходимо выполнить пересборку.
Исправления, которые необходимо внести в конфигурацию вашей системы:
- Если возможно, отключите загрузку через FCKeditor
- Убедитесь, что ваши временные каталоги имеют статус NOEXEC, чтобы предотвратить запуск программ из них.
- Все PHP-скрипты должны быть обновлены.
- Если вы хотите получить что-то поинтереснее, установите mod_security, чтобы следить за эксплойтами во время выполнения PHP-скриптов.
Я упускаю кучу всего, но это были бы первые шаги, которые я бы предпринял. В зависимости от того, что вы запускаете на сервере и насколько важна его безопасность (вы обрабатываете транзакции CC?), может потребоваться пересборка, но если это сервер с «низким уровнем безопасности», вам может подойти проверка вышеизложенного.
решение2
Вам нужно перестроить хост. Вы не знаете, какие атаки повышения привилегий они использовали против хоста, и вы не можете быть абсолютно уверены, что на нем не установлены трояны, кейлоггеры или руткиты.
Если вы подверглись взлому, у вас не останется другого выбора, кроме как перестроить систему с «голого железа».
решение3
Короче говоря - я бы перестроил сервер.
Если у них есть доступ к локальному пользователю (теперь у них был доступ как у пользователя apache), они могут запускать локальные эксплойты. Поэтому вы должны считать, что весь сервер скомпрометирован. Вы должны проверить и другие серверы.
Какой дистрибутив вы используете? Если он основан на rpm, вы можете проверить подписи файлов. Загрузите установочный CD и запустите rpm -V on, чтобы проверить пакеты.
решение4
Я понимаю, что это не то, что вам хотелось бы услышать, но я бы настоятельно рекомендовал сделать резервную копию данных, переустановить сервер и повторно импортировать все данные.
Также обязательно проверьте другие сайты, чтобы убедиться, что этот не единственный, затронутый взломом. Если все скрипты вашего сервера запущены как один пользователь Apache ( nodoby/ www_data/what-ever-your-distro-uses), все, что может писать на один сайт, почти наверняка может писать и на остальные.
Помимо смены всех паролей, убедитесь, что все ключи SSH на сервере аннулированы на всех других серверах (т. е. отзовите открытые ключи, где бы они ни хранились, а не просто удалите закрытый ключ), и что все другие системы, для которых вы могли ввести пароль (или сохранить пароль в файле) на этом сервере или через него, изменили пароли.