Перейти к содержимому 
Безопасность обработчика PHP определяет, насколько сильно веб-сайты отделены друг от друга в общих средах и какие поверхности для атак открывает веб-сервер; при прямом сравнении FPM и CGI наиболее важными факторами являются изоляция процессов, права пользователей и жесткие ограничения. Я показываю, почему FPM с выделенными пулами снижает риск, в то время как классический CGI обеспечивает строгую изоляцию, но создает задержки и нагрузку на процессор из-за высоких накладных расходов.
Центральные пункты
- Изоляция определяет поверхность атаки и кросс-аккаунт риски.
- Бассейны FPM Разделяйте пользователей, устанавливайте ограничения и защищайте ресурсы.
- CGI сильно изолирует, но требует затрат процессора и времени на каждый запрос.
- OPcache нужны отдельные сегменты хранения для каждой учетной записи.
- виртуальный хостинг преимущества выделенных экземпляров FPM.
Как обработчики PHP формируют безопасность
Каждый обработчик соединяет веб-сервер и интерпретатор PHP, но Исполнение mod_php загружает PHP непосредственно в процесс веб-сервера; это обеспечивает скорость, но использует один и тот же пользовательский контекст и повышает риск хостинга. CGI запускает новый процесс на каждый запрос под целевым пользователем, что обеспечивает чистое разделение прав, но приводит к заметным накладным расходам. FastCGI сохраняет процессы живыми и снижает затраты на запуск, но только FPM обеспечивает тонкий контроль, который требуется современным многопользовательским системам. Я предпочитаю FPM, потому что он позволяет использовать отдельные пулы, отдельные UID и строгие ограничения для каждой учетной записи без потери эффективности.
FPM против CGI: демаркация безопасности в повседневной жизни
При прямом сравнении CGI разделяет строго, а FPM продолжает разделение. постоянная и поддерживает низкую задержку. Пулы FPM работают под соответствующей учетной записью пользователя, изолируют пути и инкапсулируют ресурсы; таким образом, эксплойт на сайте A предотвращает доступ к сайту B. Я также ограничиваю влияние ошибочных скриптов с помощью параметров memory_limit, max_execution_time и request_terminate_timeout. Хотя CGI завершает каждый процесс после выполнения запроса, он тратит процессорное время, постоянно запуская и загружая расширения. Поэтому в средах с общим доступом преобладает FPM, в идеале - выделенный пул для каждого домена или проекта.
Изоляция в виртуальном хостинге: риски и способы их устранения
В общей среде самые крупные Риск хостинга, когда учетные записи непреднамеренно разделяют ресурсы или права. Злоумышленники используют слабые разрешения на файлы, неисправные временные каталоги или неразделенные кэши. С помощью выделенных пулов FPM для каждой учетной записи я инкапсулирую процессы, пути к файлам, журналы и сегменты OPcache. Я также разделяю пути загрузки и предотвращаю атаки симлинков с помощью ограничительных опций монтирования и чистых моделей владельцев. Многоуровневый Изоляция процессов с chroot, CageFS или jails значительно снижает последствия вторжения, поскольку злоумышленник не может получить доступ к хост-системе.
Управление ресурсами: пулы, лимиты и тайм-ауты
FPM набирает очки, потому что я могу направлять ресурсы выделить и, таким образом, сдерживает злоупотребления. Я использую pm.max_children для ограничения одновременных процессов PHP, а pm.max_requests перезапускает долгоживущих рабочих после X запросов, чтобы предотвратить утечку памяти. request_terminate_timeout завершает зависания, которые в противном случае занимали бы оперативную память, и защищает от атак торможения. Для закачек я устанавливаю post_max_size и upload_max_filesize, чтобы нормальные рабочие процессы выполнялись, но гигантские файлы не принимались. В сочетании с общесистемными cgroups для CPU и RAM хост остается отзывчивым даже при пиковых нагрузках.
Производительность и безопасность в сравнении цифр
Прямое сравнение манипуляторов выявляет практические различия осязаемые. Я использую следующий обзор для принятия решений и калибровки ожиданий. Значения описывают типичные тенденции в реальных установках и показывают, почему FPM является первым выбором в сценариях виртуального хостинга. CGI отдает приоритет жесткости через перезапуск, FPM балансирует между изоляцией и скоростью, LSAPI сияет со стеками LiteSpeed. Это по-прежнему важно: Изоляция без ограничений мало чем поможет, как и ограничения без изоляции.
| обработчик | Производительность | Безопасность | Потребление оперативной памяти | Изоляция | Идеально подходит для |
|---|---|---|---|---|---|
| mod_php | Высокий | Низкий | Низкий | Низкий | Небольшие, простые сайты |
| CGI | Низкий | Высокий | Высокий | Высокий | Испытания, строгое разделение |
| FastCGI | Средний | Средний | Средний | Средний | Переходная фаза |
| PHP-FPM | Очень высокий | Высокий | Низкий | Высокий | Виртуальный хостинг, CMS |
| suPHP | Низкий | Очень высокий | Высокий | Очень высокий | Максимальная безопасность файлов |
| LSAPI | Очень высокий | Средний | Очень низкий | Средний | Высокий трафик с LiteSpeed |
Из этого сопоставления я делаю четкий вывод. ПоследствияДля многопользовательского хостинга FPM обеспечивает наилучшую общую безопасность на единицу производительности. CGI остается вариантом для особых случаев с максимальным разделением и небольшим количеством запросов. Я избегаю mod_php в средах с несколькими клиентами. LSAPI заслуживает внимания, если используется LiteSpeed и оперативной памяти крайне мало. Однако в большинстве сценариев преимущества отдельных пулов FPM с четкими ограничениями перевешивают недостатки.
Конфигурационные ловушки: безопасные настройки по умолчанию для стеков FPM
Многие взломы происходят по следующим причинам Неправильная конфигурация, а не через экзотические подвиги. Для меня обязательны два переключателя: я устанавливаю cgi.fix_pathinfo=0, чтобы избежать обхода PATH_INFO, и ограничить с помощью security.limit_extensions окончания исполняемых файлов (например. .php,.php8,.phtml). В установках Nginx я проверяю, что ИМЯ_СКРИПТА установлен правильно, и никакие запросы не проскакивают по произвольным путям. Я также отключаю редко используемые функции, такие как exec, shell_exec, proc_open и popen через отключить_функции. Это не панацея, но значительно снижает эффект от простых веб-оболочек. open_basedir Я использую его очень избирательно: он может помочь, но легко приводит к побочным эффектам при работе с CLI, библиотеками для работы с изображениями или Composer. Последовательное разделение путей для каждой учетной записи и чистые права владельца лучше.
Правильно изолируйте сеансы, загрузки и временные каталоги
Общие Температурные дорожки являются классикой эскалации привилегий. Для каждого пула FPM я определяю session.save_path и upload_tmp_dir в каталоге для конкретной учетной записи, расположенном ниже домашнего, с ограниченными правами и липким битом только там, где это необходимо. noexec, nodev и nosuid на креплениях уменьшают площадь атаки последующих уровней. Для сеанса GC я установил session.gc_probability/gc_divisor чтобы файлы в пределах учетной записи могут быть состарены и удалены; я отказываюсь от глобальных бакетов сессий для всех пользователей. Тот, кто использует Redis для сессий, строго разделяет пространства имен и назначает отдельные учетные данные и лимиты для каждой учетной записи. Это не позволяет ошибочному коду повлиять на сессии в других проектах.
Проектирование сокетов, авторизация и укрепление systemd
Пулы FPM взаимодействуют через сокеты. Я предпочитаю Сокеты UNIX для локальной связи и поместите их в каталог для конкретной учетной записи с 0660 и подходящей группы. Global 0666-сокеты - это табу. В качестве альтернативы я использую только TCP с Bind on 127.0.0.1 или на внутреннем интерфейсе и брандмауэрах. На уровне обслуживания systemd надежно: NoNewPrivileges=true, ProtectSystem=strict, ProtectHome=true, PrivateTmp=true, CapabilityBoundingSet= (пустой), пределы для MemoryMax, CPUQuota, TasksMax и LimitNOFILE. Это устраняет многие пути эскалации, даже если уязвимость веб-приложения затронута. Я также размещаю пулы на их собственных участках, чтобы заглушить шумных соседей и обеспечить соблюдение бюджета.
CLI, cron и queue worker: та же изоляция, что и в Интернете
Частый Слепое пятно: php-cli не запускается через FPM. Поэтому я запускаю cronjobs, индексаторы и рабочие очереди явно от имени связанного пользователя учетной записи и использую отдельный php.ini на проект (или php_value-overrides), ограничения, расширения и open_basedir-эквиваленты. Рабочие очереди (например, из распространенных CMS и фреймворков) получают те же бюджеты RAM/CPU, что и веб-процессы, включая стратегию перезапуска в случае утечки. Для повторяющихся заданий я устанавливаю бэкофф и ограничения скорости, чтобы неисправный импортер фида не заблокировал хост. Паритет очень важен: то, что запрещено в веб-пуле, не должно быть внезапно разрешено в CLI.
Ведение журналов, медленные журналы и обратное давление
Наглядность определяет, как быстро я распознаю атаку или неправильную конфигурацию. Для каждого пула я пишу свой собственный Журналы ошибок и активируйте request_slowlog_timeout Бархат slowlog, чтобы получить трассировку стека при зависании. log_limit предотвращает переполнение журналов отдельными запросами. С помощью pm.status_path и конечной точки ping, я отслеживаю процессы, время ожидания и загрузку. На уровне веб-сервера я устанавливаю Ограничения по ставкам, Ограничения на количество тел запросов и таймауты (чтение заголовков и тел), чтобы предотвратить перегрузку бэкендов в первую очередь. База правил WAF также может перехватывать тривиальные векторы атак; однако очень важно, чтобы FPM поддерживал небольшую площадь атаки на одну учетную запись, а ограничения надежно действовали.
Чистое разделение нескольких версий PHP и расширений
В частности, в виртуальном хостинге несколько Версии PHP параллельно. Я держу свои собственные двоичные файлы FPM, расширения и конфигурации готовыми для каждой версии и связываю их на один счёт to. Сокеты находятся в отдельных каталогах, так что никакие запросы не будут случайно направлены не в тот пул. OPcache остается отдельным для каждой версии и каждой учетной записи; revalidate_freq и validate_timestamps в зависимости от стратегии выпуска. Я с осторожностью отношусь к JIT: Он редко ускоряет типичные рабочие нагрузки CMS и увеличивает сложность - его отключение часто является более безопасным и стабильным выбором. Я загружаю расширения по минимуму; все, что не является абсолютно необходимым (например. pdo_mysql по сравнению с неиспользуемыми драйверами), остается снаружи.
Модель угрозы: типичные векторы атак и влияние обработчиков
На практике я всегда вижу одни и те же схемы: загрузка файлов с исполняемыми окончаниями, небезопасная десериализация, нечистые PATH_INFO-переадресация, включение локальных файлов и трюки с симлинками. FPM не решает эту проблему автоматически, но он ограничивает диапазонСкомпрометированный пул видит только свое собственное пространство имен. С помощью security.limit_extensions и правильной конфигурации веб-сервера я предотвращаю интерпретацию загружаемых изображений как PHP. Раздельные пути temp и session предотвращают кросс-аккаунт сессии и гонки tempfile. Вместе с ограничением прав доступа к файлам, umask и noexec-много, процент успеха простых эксплойтов заметно снижается.
Права на файлы, Umask и концепции владения
Файловые системы по-прежнему часто Уязвимость, если разрешения установлены неправильно. Я использую umask для регулирования разрешений по умолчанию, чтобы загруженные файлы не оказались глобально доступными для записи. suPHP или FPM с правильным назначением UID/GID гарантируют, что владелец скрипта совпадает с владельцем файла. Это не позволяет стороннему процессу изменять файлы или читать журналы. Я также блокирую чувствительные пути, устанавливаю noexec на монтирование /tmp и уменьшаю площадь атаки, последовательно разделяя пути чтения и записи.
Безопасное использование OPcache
Кэширование повышает скорость, но без чистого разделения создает общую память Побочные эффекты. Для пулов FPM я держу OPcache отдельно для каждой учетной записи, чтобы ключи и код не пересекались. Я активирую validate_timestamps в режиме разработки и снижаю его в production только для стабильных развертываний, чтобы изменения кода вступали в силу корректно. Кроме того, я проверяю file_cache только в домашнем каталоге учетной записи, а не глобально. Если вы используете общую память, вам следует использовать параметр Риски, связанные с общей памятью и строго ограничить видимость.
Комбинации веб-серверов: Apache, Nginx, LiteSpeed
Выбор фронт-энда влияет на задержку, рукопожатия TLS и обработку запросов. заметно. Apache с mpm_event хорошо гармонирует с FPM, если keep-alive и прокси-буфер корректны. Nginx до FPM убедителен со статическими активами и может смещать нагрузку в сторону, в то время как PHP получает только динамические пути. LiteSpeed с LSAPI обеспечивает очень низкие накладные расходы, но остается привязанным к другой экосистеме. Следующее применимо в каждом стеке: чистое разделение пулов FPM, определение лимитов, мониторинг логов и осознанная настройка уровней кэша.
Усиление: chroot, CageFS и тюрьмы
Помимо обработчиков, изоляция операционной системы определяет Эффект вторжения. При использовании chroot, CageFS или Jails я блокирую учетную запись в ее собственной вселенной файловой системы. Это означает, что злоумышленник теряет доступ к двоичным файлам хоста и чувствительным путям к устройствам. В сочетании с FPM для каждой учетной записи это создает многоуровневую защиту, которая также эффективна против слабых мест плагинов в системах CMS. Если вы хотите сравнить варианты, вы можете найти Сравнение обработчиков PHP Ценная ориентация для классификации стопок.
Контейнеры, SELinux/AppArmor и реалистичные ожидания
контейнеры и MAC-фреймворки, такие как SELinux или AppArmor эффективно дополняют FPM. Контейнеризация помогает связать зависимости по проекту и ограничить доступ к корневой файловой системе. Я свожу образы к минимуму, удаляю ненужные возможности и монтирую только те каталоги, которые действительно нужны. Профили SELinux/AppArmor ограничивают системные вызовы и не позволяют процессу работать вне своего контекста. Это по-прежнему важно: Контейнеры не заменяют изоляцию FPM и чистые права доступа к файлам - они образуют дополнительный слой, который перехватывает ошибки, а не заменяет основу.
Практический контрольный список для хозяев и команд
При работе над проектами я начинаю с четкого ПоследовательностьСначала я разделяю учетные записи технически, затем разворачиваю пулы FPM для каждого домена. Затем я устанавливаю реалистичные ограничения, измеряю пики нагрузки и настраиваю pm.max_children и pm.max_requests. Затем я проверяю разрешения на файлы, защищаю каталоги загрузки и удаляю ненужные разрешения на запись. Я настраиваю OPcache для каждого пула, чтобы код, сессии и кэши оставались изолированными. Наконец, я тестирую обход отказа: моделирую зависания, DoS-шаблоны и ситуации с нехваткой памяти, пока механизмы защиты не будут работать надежно.
Краткое резюме
Одно я знаю точно: FPM предлагает лучшие Баланс безопасности и производительности, особенно при сравнении fpm и cgi. CGI остается полезным, когда абсолютное разделение приоритетнее скорости, но FPM достигает аналогичных целей безопасности с гораздо меньшими накладными расходами. Выделенные пулы, жесткие ограничения и отдельные кэши значительно снижают риск хостинга в общих средах. В дополнение к изоляции процессов, чистым разрешениям на файлы и контролируемому использованию OPcache хост устанавливает решающие ограждения. Последовательное сочетание этих компонентов эффективно защищает проекты, сохраняя при этом низкое время отклика.
