Меня попросили исправить взломанный сайт, который был создан с использованием osCommerce на производственном сервере.
Сайт всегда существовал на удаленном хосте. Нет автономной чистой версии. Давайте забудем, насколько это глупо это на мгновение и разобраться с тем, что это такое.
Он был взломан несколько раз, и другой человек исправил его, удалив файлы веб-оболочки / загрузить сценарии.
Он постоянно взломан.
Что я могу сделать?
Поскольку вы не можете доверять чему-либо на веб-хостинге (возможно, был установлен руткит ), самый безопасный подход – перестроить новый веб-сервер с нуля; не забудьте обновить все программное обеспечение, обращенное к внешнему виду, перед тем, как подключить его к сети . Сделайте все обновления на счастливой стороне драконовского брандмауэра.
Когда вы перестраиваете систему, обязательно обратите особое внимание на правильную конфигурацию. Если веб-контент принадлежит другому пользователю Unix, чем идентификатор пользователя веб-сервера, а разрешения на файлы запрещены для записи, веб-сервер не может изменять файлы программы.
Настройте учетную запись пользователя Unix вашего веб-сервера, чтобы он имел доступ на запись только к своим файлам журналов и сокетам базы данных, если они находятся в файловой системе. Взломанный веб-сервер все равно может обслуживать взломанные страницы для клиентов, но перезапуск «отменит» «живой взлом». Конечно, ваше содержимое базы данных может быть отправлено в Якудзу или испорчено людьми, которые думают, что ваши данные должны включать фотографии единорогов. Принцип наименьшей привилегии будет хорошим ориентиром – что именно нужно вашему веб-серверу для доступа к своей работе? Предоставьте только это.
Также рассмотрите возможность развертывания обязательной системы контроля доступа, такой как AppArmor , SELinux , TOMOYO или SMACK . Любая из этих систем, правильно настроенная, может управлять областью того, что может быть повреждено или утечка при взломе системы. (Я работал над AppArmor уже десять лет, и я уверен, что большинство системных администраторов могут узнать, как развернуть работоспособную политику безопасности в своих системах за один или два исследования. Инструмент не применим ко всем ситуациям, поэтому обязательно чтобы прочитать обо всех ваших вариантах.)
Во второй раз убедитесь, что ваша конфигурация управляется с помощью таких инструментов, как марионетка , шеф-повар или, по крайней мере, в системе контроля версий .
Обновить
Что-то еще, немного не связанное с возвращением в онлайновом режиме, но потенциально образовательное все-таки: сохраните жесткий диск из взломанной системы, чтобы вы могли смонтировать его и проверить его содержимое из другой системы. Возможно, есть что-то, чему можно научиться, сделав судебную экспертизу скомпрометированных данных: вы можете обнаружить, что компромисс произошел несколько месяцев назад и крал пароли или ключи ssh . Вы можете найти руткит или другие инструменты для использования. Вы можете найти информацию, чтобы показать источник атаки – возможно, администратор этого сайта еще не понял, что они были взломаны.
Будьте внимательны при проверке взломанных данных – что .jpg вы не можете признать, что это может быть эксплойтом, который взломал систему в первую очередь, и просмотр ее на «хорошо известной» системе также может ее взломать. Выполняйте работу с жестким диском, который вы можете форматировать, когда закончите. (Виртуализированный или с обязательной системой контроля доступа может быть достаточным для ограничения «пассивных» хакеров, основанных на данных, но нет ничего похожего на разовые системы для спокойствия.)
Получите новую копию версии osCommerce, с которой был создан сайт, и выполните разницу между новой новой osCommerce и взломанным сайтом. Также проверьте файлы, которые существуют на сервере, но не в пакете osCommerce.
Путем ручного сравнения различий вы можете отслеживать все возможные места, в которых может быть создан или изменен скрипт.
Я знаю, что это немного поздно, чтобы предлагать это решение, но официальное исправление от разработки osCommerce находится здесь: http://library.oscommerce.com/confluence/display/OSCOM23/(A)+(SEC)+Administration + Инструмент + 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