Hoppa till innehåll 
Säkerhet för PHP-hanterare avgör hur starkt webbplatser är separerade från varandra i delade miljöer och vilka attackytor en webbserver exponerar; i en direkt jämförelse mellan FPM och CGI är processisolering, användarrättigheter och hårda gränser de viktigaste faktorerna. Jag visar varför FPM med dedikerade pooler minskar risken, medan klassisk CGI ger strikt isolering men genererar latens och CPU-belastning på grund av höga overheadkostnader.
Centrala punkter
- Isolering fastställer angreppsytan och riskerna mellan olika konton.
- FPM-pooler separera användare, sätta gränser och skydda resurser.
- CGI isolerar kraftigt, men kostar CPU och tid per begäran.
- OPcache behöver separata lagringssegment för varje konto.
- delat webbhotell drar nytta av dedikerade FPM-instanser.
Hur PHP-hanterare påverkar säkerheten
Varje hanterare kopplar samman webbservern och PHP-tolken, men Verkställighet mod_php laddar PHP direkt in i webbserverprocessen; detta ger hastighet, men delar samma användarkontext och ökar hostingrisken. CGI startar en ny process per begäran under målanvändaren, vilket håller rättigheterna rent åtskilda, men med märkbar overhead. FastCGI håller processerna vid liv och minskar startkostnaderna, men endast FPM ger den fina kontroll som moderna fleranvändarinstallationer kräver. Jag föredrar FPM eftersom det tillåter separata pooler, separata UID:er och strikta gränser per konto utan att förlora effektivitet.
FPM vs CGI: säkerhetsavgränsning i vardagen
I en direkt jämförelse separerar CGI strikt, men FPM fortsätter separationen. permanent och håller latensen låg. FPM-pooler körs under respektive kontoanvändare, isolerar sökvägar och kapslar in resurser; på så sätt förhindrar en exploit på site A åtkomst till site B. Jag begränsar också effekten av felaktiga skript med memory_limit, max_execution_time och request_terminate_timeout. Även om CGI avslutar varje process efter begäran, slösar den CPU-tid genom att ständigt starta och ladda tillägg. I delade miljöer dominerar därför FPM, helst som en dedikerad pool per domän eller projekt.
Isolering i delad hosting: risker och lösningar
I delade miljöer är den största Risk för värdskap, när konton delar resurser eller rättigheter oavsiktligt. Angripare riktar in sig på svaga filbehörigheter, felaktiga temp-kataloger eller oseparerade cacheminnen. Med dedikerade FPM-pooler per konto kapslar jag in processer, filsökvägar, loggar och OPcache-segment. Jag separerar också uppladdningssökvägar och förhindrar symlänkattacker med restriktiva monteringsalternativ och rena ägarmodeller. Flera nivåer Processisolering med chroot, CageFS eller jails minskar avsevärt effekten av ett intrång eftersom angriparen inte kan nå värdsystemet.
Resurshantering: pooler, gränser och timeouts
FPM får poäng eftersom jag kan rikta resurser fördela och på så sätt stävja missbruk. Jag använder pm.max_children för att begränsa samtidiga PHP-processer, medan pm.max_requests startar om långlivade arbetare efter X förfrågningar för att förhindra minnesläckage. request_terminate_timeout avslutar hang-ups som annars skulle binda upp RAM och skyddar mot bromsattacker. För uppladdningar ställer jag in post_max_size och upload_max_filesize så att normala arbetsflöden körs, men gigantiska filer accepteras inte. I kombination med systemomfattande c-grupper för CPU och RAM förblir värden responsiv även under toppbelastningar.
Prestanda och säkerhet i en jämförelse av siffror
En direkt jämförelse av handläggarna avslöjar de praktiska skillnaderna påtaglig. Jag använder följande översikt för att fatta beslut och kalibrera förväntningar. Värdena beskriver typiska tendenser i verkliga installationer och visar varför FPM är förstahandsvalet i scenarier med delad hosting. CGI prioriterar hårdhet genom omstart, FPM balanserar isolering och hastighet, LSAPI glänser med LiteSpeed-stackar. Det är fortfarande viktigt: Isolering utan gränser är inte till någon större hjälp, och det är gränser utan isolering heller inte.
| handlare | Prestanda | Säkerhet | RAM-förbrukning | Isolering | Idealisk för |
|---|---|---|---|---|---|
| mod_php | Hög | Låg | Låg | Låg | Små, enkla webbplatser |
| CGI | Låg | Hög | Hög | Hög | Tester, strikt separation |
| FastCGI | Medium | Medium | Medium | Medium | Övergångsfas |
| PHP-FPM | Mycket hög | Hög | Låg | Hög | Delad hosting, CMS |
| suPHP | Låg | Mycket hög | Hög | Mycket hög | Maximal säkerhet för filer |
| LSAPI | Mycket hög | Medium | Mycket låg | Medium | Hög trafik med LiteSpeed |
Från denna juxtaposition drar jag en tydlig KonsekvenserFör hosting med flera användare ger FPM den bästa övergripande säkerheten per prestandaenhet. CGI är fortfarande ett alternativ för specialfall med maximal separation och få förfrågningar. Jag undviker mod_php i miljöer med flera kunder. LSAPI förtjänar att övervägas när LiteSpeed används och RAM-minnet är extremt knappt. I de flesta scenarier uppväger dock fördelarna med separata FPM-pooler med tydliga gränser nackdelarna.
Konfigurationsfällor: säkra standardvärden för FPM-stackar
Många inbrott orsakas av Felaktig konfiguration, inte genom exotiska bedrifter. Två brytare är obligatoriska för mig: Jag ställer in cgi.fix_pathinfo=0, för att undvika PATH_INFO-genomgångar, och begränsa med säkerhet.limit_extensions de körbara ändelserna (t.ex. .php,.php8,.phtml). I Nginx-konfigurationer kontrollerar jag att SKRIPT_FILNAMN är korrekt inställd och att inga förfrågningar går till godtyckliga sökvägar. Jag avaktiverar också sällan använda funktioner som avrättning, shell_exec, proc_öppna och popen om inaktivera_funktioner. Detta är ingen patentlösning, men det minskar avsevärt effekten av enkla webshells. öppen_basedir Jag använder det mycket selektivt: det kan hjälpa, men leder lätt till bieffekter med CLI-jobb, bildmanipulationsbibliotek eller Composer. Konsekvent vägseparation per konto och rena ägarrättigheter är bättre.
Isolera sessioner, uppladdningar och tillfälliga kataloger på rätt sätt
Vanlig Temp vägar är en klassiker för Privilege Escalation. För varje FPM-pool definierar jag session.save_path och upload_tmp_dir i en kontospecifik katalog under hemmet, med restriktiva rättigheter och sticky bit endast vid behov. noexec, nodv och nosuid på montrarna minskar attackytan för ytterligare nivåer. För session GC ställer jag in session.gc_probability/gc_delare så att filer inom av kontot kan åldras och raderas; Jag avvisar globala sessionshinkar över användare. Alla som använder Redis för sessioner separerar strikt namnområden och tilldelar separata autentiseringsuppgifter och gränser för varje konto. Detta förhindrar att felaktig kod påverkar sessioner i andra projekt.
Utformning av uttag, behörigheter och systemhårdgörning
FPM-pooler kommunicerar via sockets. Jag föredrar UNIX-uttag för lokal kommunikation och placera dem i en kontospecifik katalog med 0660 och lämplig grupp. Global 0666-sockets är tabu. Alternativt använder jag bara TCP med Bind on 127.0.0.1 eller på ett internt gränssnitt och brandväggar. På tjänstenivå systemd på ett tillförlitligt sätt: NoNewPrivileges=true, ProtectSystem=strikt, ProtectHome=true, PrivateTmp=true, KapabilitetBegränsningSet= (tom), gränser för MemoryMax, CPU-kvot, UppgifterMax och BegränsaNOFILE. Detta eliminerar många eskaleringsvägar, även om en sårbarhet i en webbapp träffas. Jag placerar också pooler i sina egna skivor för att dämpa bullriga grannar och genomdriva budgetar.
CLI, cron och queue worker: samma isolering som på webben
En frekvent Blindspot: php-cli körs inte via FPM. Jag startar därför cronjobs, indexerare och köarbetare uttryckligen som den associerade kontoanvändaren och använder en separat php.ini per projekt (eller php_value-overrides), begränsningar, tillägg och öppen_basedir-motsvarigheter. Köarbetare (t.ex. från vanliga CMS och ramverk) får samma RAM/CPU-budgetar som webbprocesser, inklusive en omstartsstrategi i händelse av läckage. För återkommande jobb sätter jag gränser för backoff och rate så att en defekt feed-importör inte blockerar värden. Paritet är viktigt: det som är förbjudet i webbpoolen ska inte plötsligt vara tillåtet i CLI.
Loggning, slowlogs och mottryck
Synlighet avgör hur snabbt jag upptäcker en attack eller en felkonfiguration. För varje pool skriver jag min egen Fel loggar och aktivera begäran_slowlog_timeout sammet slowlog, för att få stackspår för hängen. log_limit förhindrar att enskilda förfrågningar översvämmar loggarna. Med pm.status_path och en ping-slutpunkt övervakar jag processer, väntetider och användning. På webbservernivå ställer jag in Gränsvärden för priser, För att förhindra att backends blir överbelastade i första hand kan FPM införa begränsningar av antalet begäranden, begränsningar av antalet begäranden och timeouts (läsning av header och body). En WAF-regelbas kan också fånga upp triviala attackvektorer, men det är fortfarande avgörande att FPM håller attackytan per konto liten och att begränsningarna fungerar på ett tillförlitligt sätt.
Separera flera PHP-versioner och tillägg på ett snyggt sätt
Särskilt när det gäller delad hosting finns det flera PHP-versioner parallellt. Jag håller mina egna FPM-binärfiler, tillägg och konfigurationer redo för varje version och binder dem per konto till. Socklarna hamnar i separata kataloger så att inga förfrågningar av misstag dirigeras till fel pool. OPcache förblir separat för varje version och varje konto; revalidate_freq och validera_tidsstämplar beroende på utgivningsstrategi. Jag är försiktig med JIT: Det snabbar sällan upp typiska CMS-arbetsbelastningar och ökar komplexiteten - att avaktivera det är ofta det säkrare och stabilare valet. Jag laddar tillägg minimalt; allt som inte är absolut nödvändigt (t.ex. pdo_mysql mot oanvända förare), förblir utanför.
Hotmodell: typiska attackvektorer och påverkan från hanteraren
I praktiken ser jag alltid samma mönster: filuppladdningar med körbara ändelser, osäker deserialisering, oren PATH_INFO-vidarebefordran, lokal filinkludering och symlänk-trick. FPM löser inte detta automatiskt, men det begränsar räckviddenEn komprometterad pool ser bara sitt eget namnområde. Med säkerhet.limit_extensions och korrekt webbserverkonfiguration förhindrar jag att bilduppladdningar tolkas som PHP. Separata temp- och sessionssökvägar förhindrar sessioner mellan konton och tempfilsrace. Tillsammans med restriktiva filbehörigheter, umask och noexec-höjningar sjunker framgångsgraden för enkla exploateringar märkbart.
Filrättigheter, Umask och äganderättsbegrepp
Filsystem är fortfarande ett vanligt Sårbarhet, om behörigheterna är felaktigt inställda. Jag använder umask för att reglera standardbehörigheter så att uppladdningar inte blir globalt skrivbara. suPHP eller FPM med rätt UID/GID-tilldelning säkerställer att skriptägaren matchar filägaren. Detta förhindrar en tredjepartsprocess från att ändra filer eller läsa loggar. Jag låser också känsliga sökvägar, ställer in noexec på /tmp-monteringar och minskar attackytan genom att konsekvent separera läs- och skrivvägar.
Använd OPcache på ett säkert sätt
Cachelagring ökar hastigheten, men utan ren separation skapas delat minne Biverkningar. För FPM-pooler håller jag OPcache separat för varje konto så att nycklar och kod inte överlappar varandra. Jag aktiverar validate_timestamps i utvecklingsläget och sänker den endast i produktionsläget för stabila driftsättningar så att kodändringar får korrekt effekt. Dessutom kontrollerar jag bara file_cache inom kontots hemkatalog, inte globalt. Om du använder delat minne bör du använda Risker med delat minne och strikt begränsa synligheten.
Kombinationer av webbservrar: Apache, Nginx, LiteSpeed
Valet av frontend påverkar latens, TLS-handskakningar och hantering av förfrågningar märkbar. Apache med mpm_event harmoniserar väl med FPM om keep-alive och proxybuffert är korrekta. Nginx före FPM är övertygande med statiska tillgångar och kan flytta belastningen, medan PHP bara tar emot dynamiska sökvägar. LiteSpeed med LSAPI ger mycket låga omkostnader, men är fortfarande knutet till ett annat ekosystem. Följande gäller i varje stack: separera FPM-pooler rent, definiera gränser, övervaka loggar och konfigurera cache-lager medvetet.
Härdning: chroot, CageFS och Jails
Förutom handläggare bestämmer operativsystemets isolering Effekt av ett intrång. Med chroot, CageFS eller Jails låser jag in kontot i sitt eget filsystemuniversum. Detta innebär att en angripare förlorar åtkomst till värdbinärer och känsliga enhetsvägar. Kombinerat med FPM per konto skapar detta ett flerskiktat försvar som även är effektivt mot svagheter i insticksprogram i CMS-system. Om du vill jämföra alternativ kan du hitta Jämförelse av PHP-hanterare värdefull orientering för att kategorisera staplarna.
Containrar, SELinux/AppArmor och realistiska förväntningar
containers och MAC-ramverk som t.ex. SELinux eller . AppArmor komplettera FPM på ett effektivt sätt. Containerisering hjälper till att binda beroenden per projekt och begränsa åtkomsten till rotfilsystemet. Jag håller bilder till ett minimum, tar bort onödiga funktioner och monterar bara de kataloger som verkligen behövs. SELinux/AppArmor-profiler begränsar systemanrop och hindrar en process från att agera utanför sitt sammanhang. Det är fortfarande viktigt: Containrar är ingen ersättning för FPM-isolering och rena filbehörigheter - de utgör ett extra lager som fångar upp fel, inte ersätter grunden.
Praktisk checklista för värdar och team
I projekten börjar jag med en tydlig SekvensFörst separerar jag konton tekniskt, sedan rullar jag ut FPM-pooler per domän. Sedan sätter jag realistiska gränser, mäter belastningstoppar och justerar pm.max_children och pm.max_requests. Sedan kontrollerar jag filbehörigheter, säkrar uppladdningskataloger och tar bort onödiga skrivbehörigheter. Jag konfigurerar OPcache per pool så att kod, sessioner och cacher förblir isolerade. Slutligen testar jag failover: jag simulerar hängningar, DoS-mönster och situationer där minnet inte räcker till tills skyddsmekanismerna fungerar tillförlitligt.
Kortfattat sammanfattat
En sak är säker för mig: FPM erbjuder de bästa Balans av säkerhet och prestanda, särskilt när man jämför fpm med cgi. CGI är fortfarande användbart när absolut separation prioriteras framför hastighet, men FPM uppnår liknande säkerhetsmål med betydligt mindre overhead. Dedikerade pooler, hårda gränser och segregerade cacheminnen minskar avsevärt risken för hosting i delade miljöer. Genom att komplettera med processisolering, rena filbehörigheter och kontrollerad användning av OPcache sätter värden upp de avgörande skyddsräckena. Genom att konsekvent kombinera dessa komponenter skyddas projekten effektivt samtidigt som svarstiderna hålls låga.
