У нас есть корпоративный сервер с множеством сайтов. Их обслуживают разные люди из нашей компании. Все веб-сайты общедоступны. Доступ к серверу ограничен только нашей компанией. Это НЕ среда общего хостинга.
Мы изучаем безопасность сервера, в настоящее время анализируя риски, связанные с разрешениями файлов. Мы считаем, что наибольший риск возникает, когда файлы загружаются, а затем открываются / запускаются публикой. Этого не должно происходить, но ошибка в скрипте может позволить людям это сделать (есть загрузчики изображений, загрузчики файлов и т. Д.). Скрипты загрузчика используют PHP.
Возникает вопрос: как лучше всего настроить / организовать права доступа к файлам и процессам? Кажется, есть несколько вариантов запуска PHP (и Apache) и установки разрешений. Что нужно учитывать? Какие-нибудь советы?
Мы рассматриваем mod_php и FastCGI, но, возможно, учитывая нашу ситуацию, предпочтительнее другие решения?
Я очень рекомендую бегать suPHP. Используя suPHP, каждый веб-сайт может быть разделен на собственное имя пользователя вместо того, чтобы работать от имени обычного пользователя Apache. Это будет означать, что если кто-то может «взломать» сервер из-за небезопасного сценария на сервере; они будут ограничены только этим сайтом, а не всем сервером. Исключением является то, что при использовании эксплойта root они могут получить доступ ко всему серверу ... но, по крайней мере, suPHP поможет защитить каждый отдельный сайт.
Если у вас есть Apache / PHP для разных пользователей, важны разрешения на чтение / запись файлов на сервере. Вы также можете более полно использовать разрешения с организационной точки зрения, позволяя пользователям обновлять файлы на их сайт, а не какой-либо.
Что касается mod_php / fastcgi, я предпочитаю реализацию FastCGI в php-fpm, которая теперь включена в PHP (начиная с версии 5.33). PHP-FPM предоставляет каждому «пулу» (веб-сайту) свои собственные процессы (динамические или статические), из которых он обслуживает php. каждый виртуальный хост в apache / nginx подключается к своему собственному пулу php-fpm на определенном порту (например, 9000). Это, по сути, выполняет то же самое, что и suExec, в том, что каждый процесс / запрос php является «Exec», как его собственный пользователь (вы указываете user: group для каждого пула, который должен быть chrooted / заключен в тюрьму).
Это также дает более детальный контроль использования памяти и разделяет обработку статических файлов / изображений и динамического содержимого (php). Из-за этого разделения apache не загружает PHP в свои процессы при обслуживании статического содержимого. При использовании mod_php для каждого запроса от пользователя потребуется процесс размером ~ 40 МБ, даже если это статический запрос (30 из которых являются php). По крайней мере, я так понимаю ... поправьте меня, если я ошибаюсь.
Вы можете настроить один пул (www.domain1.com) на 5 статических процессов PHP для обработки запросов, а другой пул (www.domain2.com) на минимум 10 и максимум 30.
Загрузки хранятся в /var/tmp по умолчанию, поэтому смонтируйте его как +noexec +nosuid и настройте свой Apache VirtualHostс php_flag engine 0 (см. руководство по PHP) для каталогов, которые будут содержать загруженные файлы (если вы должен разрешить загрузку файлов - в противном случае установите file_uploads 0 в твоем php.ini)
Устанавливать allow_url_fopen 0 в php.ini (на случай, если одному из ваших кодировщиков придет в голову яркая идея включить URL-адреса) и рассмотрите Сухосин если у вас в штате есть сомнительные кодеры
Еще два варианта с разной безопасностью:
suexec на apache. Apache может съесть память. (и я верю, что не работает с fcgi)
виртуальные устройства, по одному для каждого сайта. Это решение, конечно же, предлагает самую большую свободу в отношении php-версий и т. Д. (Я с большим успехом запускаю openvz).
С уважением, / т
Черт возьми, этого не должно происходить - а если вы админ сайта это твоя вина, что это произошло
Мы рассматриваем mod_php и FastCGI,
Это ничего общего с проблемами у вас в настоящее время, ни как вы собираетесь сделать систему безопасной.
Первое, что вам нужно, это модель разрешений и процессы для поддержки развертывания кода на сервере контролируемым образом.
Один из подходов - создать группу для каждого проекта, исключающую uid веб-сервера, а затем развернуть все файлы как rw-rw-r для пользователя и группы разработки - веб-сервер полагается на «другие» разрешения на чтение файлов. Настройте все каталоги с установленным битом закрепления группы.
Каждый проект должен находиться в своем собственном подкаталоге в корне документа, и каждый проект должен иметь каталог загрузки, доступный для записи uid веб-сервера вне корня документа, и по крайней мере один выделенный (на группу) каталог включает каталог вне корня документа (для предпочтения каждый должен быть на собственном vhost). Доступ должен быть ограничен open_basedir
Опубликуйте стандарт кодирования, в котором должно быть указано, что разрешениями нельзя управлять из стандартных настроек, и настройте вашу IDS, чтобы она учитывала любые добавленные файлы PHP или измененные разрешения.
Но есть и другие модели.
Важно то, что:
Веб-сервер никогда не должен иметь возможность записывать файлы, доступные напрямую через веб-сервер.
Если загружаемый пользователем контент должен быть доступен, он должен быть тщательно очищен при загрузке, а доступ должен осуществляться через сценарий контроллера.
в случае развертывания вредоносного кода на сервере следует строго ограничивать размер ущерба, который он может нанести
должно быть возможно определить, когда в системе вносятся изменения кода
Ваша модель разрешений должна препятствовать тому, чтобы один проект вмешивался в поведение другого проекта (например, предположим, что у вас есть общий каталог include - даже если разные проекты не могут изменять файлы других, они могут замаскировать поведение, используя то же имя файла в другом месте. путь включения - или, что еще хуже, создать ошибки, используя одно и то же имя функции или класса дважды).