Мне было предложено исправить взломанный сайт, который был создан с использованием osCommerce на рабочем сервере.
Сайт всегда существовал на удаленном хосте. Нет автономной чистой версии. Давайте забудем, насколько это глупо это на мгновение и разобраться с тем, что это такое.
Он был взломан несколько раз, а другой человек исправил его, удалив файлы веб-оболочки/загрузить сценарии.
Он постоянно взломается.
Что я могу сделать?
Поскольку вы не можете доверять чему-либо на веб-хостинге (возможно, он установил rootkit, самый безопасный подход - перестроить новый веб-сервер с нуля; не забудьте обновить все внешние приложения прежде чем приступить к работе в сети. Сделайте все обновления на счастливой стороне драконовского брандмауэра.
Когда вы перестраиваете систему, обязательно обратите особое внимание на правильную конфигурацию. Если веб-контент принадлежит другому пользователю Unix, чем идентификатор пользователя веб-сервера, а разрешения на файлы настроены так, чтобы запрещать запись, веб-сервер не может изменять файлы программы.
Настройте свою учетную запись пользователя Unix для веб-сервера, чтобы она имела доступ на запись только к своим файлам журналов и сокетам базы данных, если они находятся в файловой системе. Взломанный веб-сервер все равно может обслуживать взломанные страницы для клиентов, но перезапуск "отменит" "живой взлом". Конечно, ваше содержимое базы данных может быть отправлено в Якудзу или испорчено людьми, которые думают, что ваши данные должны включать фотографии единорогов. Принцип наименьшей привилегии будет хорошим ориентиром - для чего нужно, чтобы ваш веб-сервер нуждался для доступа в чтобы выполнить свою работу? Предоставьте только это.
Также рассмотрите возможность развертывания системы обязательного контроля доступа, например AppArmor, SELinux, TOMOYO или SMACK. Любая из этих систем, правильно настроенная, может управлять областью того, что может быть повреждено или утечка при взломе системы. (Я работал над AppArmor уже десять лет, и я уверен, что большинство системных администраторов могут узнать, как развернуть работоспособную политику безопасности в своих системах за один или два исследования. Инструмент не применим ко всем ситуациям, поэтому обязательно чтобы прочитать обо всех ваших вариантах.)
Во второй раз убедитесь, что ваша конфигурация управляется с помощью таких инструментов, как puppet, chef или, по крайней мере, в системе контроля версий.
Обновление
Что-то еще, немного не связанное с возвращением в онлайновом режиме, но потенциально образовательное все-таки: сохраните жесткий диск из взломанной системы, чтобы вы могли смонтировать его и проверить его содержимое из другой системы. Может быть, есть что-то, что можно узнать, сделав криминалистику на скомпрометированных данных: вы можете обнаружить, что компромисс произошел несколько месяцев назад, и он крал пароли или клавиши ssh. Вы можете найти руткит или другие инструменты для использования. Вы можете найти информацию, чтобы показать источник атаки - возможно, администратор этого сайта еще не понял, что они были взломаны.
Будьте внимательны при проверке взломанных данных - что .jpg, которое вы не распознаете, вполне может быть эксплойтом, который взломал систему в первую очередь, и просмотр ее в "хорошо известной" системе может также ее взломать, Выполняйте работу с жестким диском, который вы можете форматировать, когда закончите. (Виртуализированный или с обязательной системой контроля доступа может быть достаточным для ограничения "пассивных" хакеров, основанных на данных, но нет ничего похожего на разовые системы для спокойствия.)
Получите новую копию версии osCommerce, с которой был создан сайт, и выполните разницу между новой новой osCommerce и взломанным сайтом. Также проверьте файлы, которые существуют на сервере, но не в пакете osCommerce.
С помощью ручного сравнения различий вы можете отслеживать все возможные места, которые хак мог создать или изменил сценарии.
Я знаю, что сегодня немного поздно предлагать это решение, но официальное исправление от разработки osCommerce здесь: http://library.oscommerce.com/confluence/display/OSCOM23/(A)+(SEC)+Administration+Tool+Log-In+Update
После того, как эти изменения кода применяются, большая часть фактической работы заключается в очистке веб-сайта. Использование эксплойта входа в админ-админ будет причиной того, что злоумышленники могут загружать файлы через диспетчер файлов (обычно) в каталоги, которые можно записывать, часто в каталог изображений.
Существуют и другие файлы, которые часто могут записываться, и в них может быть добавлен вредоносный код. cookie_usage.php и включает /languages /english/cookie_usage.php - обычные файлы, которые затронуты, однако на некоторых конфигурациях сервера все файлы сайта могут быть восприимчивыми.
Несмотря на то, что официальное исправление osCommerce связано с выше, я также предложил бы внести это изменение: на странице выше прокрутите страницу вниз до тех пор, пока не увидите ссылку "Обновить значение PHP_SELF". Внесите также эти изменения.
Это приведет к исправлению сообщений $PHP_SELF и предотвратит использование злоумышленниками URL-адресов злоумышленников при попытке обойти вход в систему администратора.
Я также предлагаю вам добавить базовую аутентификацию htaccess в каталог администратора.
Также ознакомьтесь с аддоном, автором которого я являюсь osC_Sec, который является единственным исправлением для системы безопасности, которое работает в большинстве поддерживаемых php веб-системами, оно специально предназначено для решения проблем, существующих в более старых версиях osCommerce. http://addons.oscommerce.com/info/8283