меры предосторожности при работе с несколькими подузлами на одном главном сайте

Question

У меня общий хостинг, и в моем собственном пространстве пользователя я управляю тремя разными доменами .com. Один из них служит основным доменом фактического плана хостинга, а другие являются подпрограммами с помощью перенаправления URL-адресов и указания домена.

Одна из этих подпрограмм - блог Wordpress, и меня беспокоит способность злоумышленника использовать дыры в безопасности в Wordpress для доступа к другим сайтам под моим виртуальным зонтиком. Если сам блог потерпел крах, я не собираюсь терять из-за этого сон. Но если другие сайты будут прибиты, я буду довольно грустной пандой.

Какие разрешения сервера и что такое я могу использовать для изоляции этого блога? Он полностью содержится в своем собственном подкаталоге.

При необходимости можно предоставить больше информации, я новичок в этом и, возможно, пропустил некоторую ключевую информацию.

Спасибо.

Answer 1

Это действительная проблема. Если они не разделены должным образом, уязвимость на одном сайте затронет их все.

1) Первое, что вам нужно сделать, это использовать suPHP , который заставляет приложение запускаться с правами конкретного пользователя. Эта учетная запись пользователя не должна иметь доступ к оболочке (/bin/false).

2) Все три каталога приложений должны быть chown user -R /home/user/www/ и chmod 500 -R /home/user/www/ Последние два нуля в chmod означают, что никакие другие учетные записи не имеют доступа к файлам. Это обеспечивает только права на чтение и выполнение, идеально, если права на запись запрещены для всего веб-корня.

3) Все три приложения должны иметь отдельную базу данных MySQL и отдельные учетные записи пользователей MySQL. Эта учетная запись пользователя должна только иметь доступ к своей собственной базе данных. Эта учетная запись не должна иметь привилегий GRANT или FILE. Где привилегия FILE является самой опасной привилегией, которую вы можете дать учетной записи пользователя MySQL, поскольку она используется для загрузки бэкдоров и чтения файлов. Это защищает от внедрения sql на одном сайте, позволяя злоумышленнику читать данные для всех сайтов.

После того, как будут предприняты эти три шага, если один сайт, где будет взломан, остальные 2 не будут затронуты. Вы должны запустить сканер уязвимостей, такой как Sitewatch (коммерческий, но есть бесплатная версия) или Skipfish (с открытым исходным кодом). После сканирования приложения запустите phpsecinfo и измените файл php.ini, чтобы удалить как можно больше красного и желтого. Модификация вашего php.init может обмануть сканеры уязвимостей, но часто все еще существует недостаток, чтобы убедиться, что вы исправляете свой код и обновляете все.

Answer 2

Зависит от дыры, которую атакующий находит. Если вы используете один и тот же пользователь / пароль для всех ваших баз данных, включая WP db, то это может быть проблемой. Конечно, проблема с правами доступа к файлам ... все, что доступно веб-серверу для доступа, может быть прочитано и часто записано.

Здесь много проблем с безопасностью, но если вы используете ftps, ssh и обновляете WP, когда они выпускают исправление безопасности, то вы снижаете вероятность возникновения проблем. Самый безопасный компьютер заключен в цемент и утоплен в Марианском желобе. Но это не очень полезно. Вы ищете баланс.

Answer 3

Chmod файлы 755 и известные настройки chmod, чтобы оставаться в курсе классической проблемы: хакер получает оболочку через строку запроса uri из-за ошибки в perl, php или на каком языке сценариев используется.Наличие защищенного интернет-провайдера, такого как secureserver.net, должно соответствовать его названию, быть в курсе конкретных ошибок в языковой реализации и выбирать наиболее безопасный доступный вместо большей производительности, а чтение insecure.org - это то, что я делаю, выполняя все экспериментальные и опытно-конструкторские работы с secureserver.net doable, о проблемах безопасности не сообщалось.