Videre til indhold 
PHP Handler-sikkerhed bestemmer, hvor stærkt hjemmesider er adskilt fra hinanden i delte miljøer, og hvilke angrebsflader en webserver udsætter sig for; i en direkte sammenligning mellem FPM og CGI er procesisolering, brugerrettigheder og hårde grænser de vigtigste faktorer. Jeg viser, hvorfor FPM med dedikerede pools reducerer risikoen, mens klassisk CGI giver streng isolation, men genererer latenstid og CPU-belastning på grund af høje overheads.
Centrale punkter
- Isolering bestemmer angrebsfladen og risici på tværs af konti.
- FPM-pools adskille brugere, sætte grænser og beskytte ressourcer.
- CGI isolerer kraftigt, men koster CPU og tid pr. anmodning.
- OPcache har brug for separate lagersegmenter til hver konto.
- delt hosting drager fordel af dedikerede FPM-instanser.
Hvordan PHP-handlere former sikkerhed
Hver handler forbinder webserveren og PHP-fortolkeren, men Udførelse mod_php indlæser PHP direkte i webserverprocessen; det giver hastighed, men deler den samme brugerkontekst og øger hostingrisikoen. CGI starter en ny proces pr. anmodning under målbrugeren, hvilket holder rettighederne rent adskilt, men med mærkbart overhead. FastCGI holder processerne i live og reducerer opstartsomkostningerne, men kun FPM giver den fine kontrol, som moderne flerbrugeropsætninger kræver. Jeg foretrækker FPM, fordi den tillader separate pools, separate UID'er og strenge grænser pr. konto uden at miste effektivitet.
FPM vs CGI: sikkerhedsmæssig afgrænsning i hverdagen
I en direkte sammenligning adskiller CGI strengt, men FPM fortsætter adskillelsen. permanent og holder ventetiden lav. FPM-pools kører under den respektive kontobruger, isolerer stier og indkapsler ressourcer; på den måde forhindrer et angreb på site A adgang til site B. Jeg begrænser også effekten af defekte scripts med memory_limit, max_execution_time og request_terminate_timeout. Selvom CGI afslutter alle processer efter anmodningen, spilder den CPU-tid ved konstant at starte og indlæse udvidelser. I delte miljøer dominerer FPM derfor, ideelt set som en dedikeret pool pr. domæne eller projekt.
Isolation i delt hosting: risici og løsninger
I delte miljøer er den største Risiko ved hosting, når konti deler ressourcer eller rettigheder utilsigtet. Angribere går efter svage filtilladelser, defekte midlertidige mapper eller ikke-adskilte cacher. Med dedikerede FPM-pools pr. konto indkapsler jeg processer, filstier, logfiler og OPcache-segmenter. Jeg adskiller også upload-stier og forhindrer symlink-angreb med restriktive monteringsmuligheder og rene ejermodeller. Flere niveauer Procesisolering med chroot, CageFS eller jails reducerer virkningen af en indtrængen betydeligt, fordi angriberen ikke kan nå værtssystemet.
Ressourcestyring: puljer, grænser og timeouts
FPM scorer point, fordi jeg kan målrette ressourcer tildele og dermed dæmme op for misbrug. Jeg bruger pm.max_children til at begrænse samtidige PHP-processer, mens pm.max_requests genstarter langtidsholdbare arbejdere efter X anmodninger for at forhindre hukommelseslækager. request_terminate_timeout afslutter hang-ups, der ellers ville binde RAM og beskytter mod bremseangreb. Til uploads sætter jeg post_max_size og upload_max_filesize, så normale workflows kører, men gigantiske filer ikke accepteres. I kombination med systemdækkende cgroups for CPU og RAM forbliver værten responsiv selv under spidsbelastninger.
Performance og sikkerhed i en sammenligning af tal
En direkte sammenligning af håndteringsmaskinerne afslører de praktiske forskelle håndgribelig. Jeg bruger følgende oversigt til at træffe beslutninger og kalibrere forventninger. Værdierne beskriver typiske tendenser i virkelige opsætninger og viser, hvorfor FPM er førstevalget i scenarier med delt hosting. CGI prioriterer hårdhed gennem genstart, FPM afbalancerer isolation og hastighed, LSAPI skinner med LiteSpeed-stakke. Det er stadig vigtigt: Isolering uden grænser er ikke til megen hjælp, og det samme gælder grænser uden isolering.
| handler | Ydelse | Sikkerhed | RAM-forbrug | Isolering | Ideel til |
|---|---|---|---|---|---|
| mod_php | Høj | Lav | Lav | Lav | Små, enkle sider |
| CGI | Lav | Høj | Høj | Høj | Test, streng adskillelse |
| FastCGI | Medium | Medium | Medium | Medium | Overgangsfase |
| PHP-FPM | Meget høj | Høj | Lav | Høj | Delt hosting, CMS |
| suPHP | Lav | Meget høj | Høj | Meget høj | Maksimal sikkerhed for filer |
| LSAPI | Meget høj | Medium | Meget lav | Medium | Høj trafik med LiteSpeed |
Ud fra denne sammenstilling tegner jeg en klar KonsekvenserTil hosting af flere brugere giver FPM den bedste samlede sikkerhed pr. ydelsesenhed. CGI er stadig en mulighed i særlige tilfælde med maksimal adskillelse og få anmodninger. Jeg undgår mod_php i miljøer med flere kunder. LSAPI bør overvejes, når LiteSpeed bruges, og der er ekstremt lidt RAM. I de fleste scenarier opvejer fordelene ved separate FPM-pools med klare grænser dog ulemperne.
Konfigurationsfælder: sikre standardindstillinger for FPM-stakke
Mange indbrud er forårsaget af Fejlkonfiguration, ikke gennem eksotiske bedrifter. To kontakter er obligatoriske for mig: Jeg indstiller cgi.fix_pathinfo=0, for at undgå PATH_INFO-traverseringer, og begræns med security.limit_extensions de eksekverbare endelser (f.eks. .php,.php8,.phtml). I Nginx-opsætninger kontrollerer jeg, at SCRIPT_FILNAVN er indstillet korrekt, og ingen anmodninger slipper igennem til vilkårlige stier. Jeg deaktiverer også sjældent brugte funktioner som f.eks. Eksekutor, shell_exec, proc_open og popen om disable_functions. Det er ikke et universalmiddel, men det reducerer effekten af simple webshells betydeligt. open_basedir Jeg bruger det meget selektivt: Det kan hjælpe, men fører let til bivirkninger med CLI-jobs, billedmanipulationsbiblioteker eller Composer. Konsekvent stiadskillelse pr. konto og rene ejerrettigheder er bedre.
Isolér sessioner, uploads og midlertidige mapper korrekt
Fælles Temp stier er en klassiker for Privilege Escalation. For hver FPM-pulje definerer jeg session.save_path og upload_tmp_dir i en kontospecifik mappe under home, med restriktive rettigheder og kun sticky bit, hvor det er nødvendigt. noexec, nodev og nosuid på mounts reducerer angrebsfladen for yderligere niveauer. For session GC sætter jeg session.gc_probability/gc_divisor så filer inden for af kontoen kan ældes og slettes; jeg afviser globale session buckets på tværs af brugere. Alle, der bruger Redis til sessioner, adskiller strengt navneområder og tildeler separate legitimationsoplysninger og grænser for hver konto. Det forhindrer fejlbehæftet kode i at påvirke sessioner i andre projekter.
Socket-design, autorisationer og systemd-hærdning
FPM-pools kommunikerer via sockets. Jeg foretrækker UNIX-sokler til lokal kommunikation og placere dem i en kontospecifik mappe med 0660 og passende gruppe. Globalt 0666-sockets er tabu. Alternativt bruger jeg kun TCP med Bind on 127.0.0.1 eller på en intern grænseflade og firewalls. På serviceniveau systemd pålideligt: NoNewPrivileges=true, ProtectSystem=strict, ProtectHome=true, PrivateTmp=true, CapabilityBoundingSet= (tom), grænser for MemoryMax, CPU-kvote, OpgaverMax og LimitNOFILE. Dette eliminerer mange eskaleringsstier, selv hvis en webapp-sårbarhed rammes. Jeg placerer også pools i deres egne slices for at dæmpe støjende naboer og håndhæve budgetter.
CLI, cron og queue worker: samme isolation som på nettet
En hyppig Blindspot: php-cli kører ikke gennem FPM. Jeg starter derfor cronjobs, indekserere og køarbejdere eksplicit som den tilknyttede kontobruger og bruger en separat php.ini pr. projekt (eller php_value-overskridelser), grænserne, udvidelserne og open_basedir-ækvivalenter. Queue workers (f.eks. fra almindelige CMS og frameworks) får de samme RAM/CPU-budgetter som webprocesser, herunder en genstartstrategi i tilfælde af lækager. For tilbagevendende jobs sætter jeg backoff- og hastighedsgrænser, så en defekt feed-importør ikke blokerer værten. Paritet er vigtigt: Det, der er forbudt i web-poolen, bør ikke pludselig være tilladt i CLI.
Logning, slowlogs og modtryk
Synlighed afgør, hvor hurtigt jeg genkender et angreb eller en fejlkonfiguration. For hver pulje skriver jeg min egen Fejl-logfiler og aktiver request_slowlog_timeout fløjl slowlog, for at få stakspor for hangs. log_limit forhindrer individuelle anmodninger i at oversvømme logfiler. Med pm.status_path og et ping-endepunkt overvåger jeg processer, ventetider og udnyttelse. På webserverniveau indstiller jeg Prisgrænser, Det er vigtigt, at FPM bruger grænser og timeouts (header og body read) for at forhindre, at backends bliver overbelastede i første omgang. En WAF-regelbase kan også opfange trivielle angrebsvektorer; det er dog stadig afgørende, at FPM holder angrebsoverfladen pr. konto lille, og at grænserne træder pålideligt i kraft.
Ren adskillelse af flere PHP-versioner og -udvidelser
Især inden for delt hosting er der flere PHP-versioner parallelt. Jeg holder mine egne FPM-binære filer, udvidelser og konfigurationer klar til hver version og binder dem pr. konto til. Sockets ender i separate mapper, så ingen anmodninger ved et uheld bliver sendt til den forkerte pool. OPcache forbliver separat for hver version og hver konto; revalidate_freq og validere_tidsstempler afhængigt af udgivelsesstrategien. Jeg er forsigtig med JIT: Det fremskynder sjældent typiske CMS-arbejdsbelastninger og øger kompleksiteten - at deaktivere det er ofte det sikreste og mest stabile valg. Jeg indlæser udvidelser minimalt; alt, hvad der ikke er absolut nødvendigt (f.eks. pdo_mysql vs. ubrugte chauffører), forbliver udenfor.
Trusselsmodel: typiske angrebsvektorer og handlerens indflydelse
I praksis ser jeg altid de samme mønstre: filuploads med eksekverbare slutninger, usikker deserialisering, urene PATH_INFO-forwarding, lokal filinklusion og symlink-tricks. FPM løser ikke dette automatisk, men det begrænser rækkeviddenEn kompromitteret pool ser kun sit eget navnerum. Med security.limit_extensions og korrekt webserverkonfiguration forhindrer jeg billeduploads i at blive fortolket som PHP. Separate temp- og sessionsstier forhindrer sessioner på tværs af konti og tempfile race. Sammen med restriktive filtilladelser, umask og noexec-stiger, falder succesraten for simple exploits mærkbart.
Filrettigheder, Umask og ejerskabskoncepter
Filsystemer er stadig et hyppigt Sårbarhed, hvis tilladelserne er sat forkert. Jeg bruger umask til at regulere standardtilladelser, så uploads ikke ender med at være globalt skrivbare. suPHP eller FPM med den korrekte UID/GID-tildeling sikrer, at scriptejeren matcher filejeren. Det forhindrer en tredjepartsproces i at ændre filer eller læse logfiler. Jeg låser også følsomme stier, sætter noexec på /tmp-mounts og reducerer angrebsfladen ved konsekvent at adskille læse- og skrivestier.
Brug OPcache sikkert
Caching giver hastighed, men uden ren adskillelse skaber det delt hukommelse Bivirkninger. For FPM-pools holder jeg OPcache adskilt for hver konto, så nøgler og kode ikke overlapper hinanden. Jeg aktiverer validate_timestamps i udviklingstilstand og sænker den kun i produktion til stabile udrulninger, så kodeændringer træder i kraft korrekt. Desuden tjekker jeg kun file_cache i kontoens hjemmebibliotek, ikke globalt. Hvis du bruger delt hukommelse, skal du bruge Risici ved delt hukommelse og strengt begrænse synligheden.
Kombinationer af webservere: Apache, Nginx, LiteSpeed
Valget af frontend påvirker latenstid, TLS-håndtryk og håndtering af anmodninger mærkbar. Apache med mpm_event harmonerer godt med FPM, hvis keep-alive og proxy-buffer er korrekt. Nginx før FPM overbeviser med statiske aktiver og kan flytte belastningen væk, mens PHP kun modtager dynamiske stier. LiteSpeed med LSAPI giver meget lave omkostninger, men er fortsat bundet til et andet økosystem. Følgende gælder i alle stakke: Adskil FPM-pools rent, definer grænser, overvåg logfiler, og konfigurer bevidst cachelag.
Hærdning: chroot, CageFS og Jails
Ud over handlere bestemmer operativsystemets isolation den Effekt af en indtrængen. Med chroot, CageFS eller Jails låser jeg kontoen i sit eget filsystemunivers. Det betyder, at en angriber mister adgang til binære værtsfiler og følsomme enhedsstier. Kombineret med FPM pr. konto skaber det et forsvar i flere lag, som også er effektivt mod plugin-svagheder i CMS-systemer. Hvis du vil sammenligne mulighederne, kan du finde Sammenligning af PHP-handler værdifuld orientering til kategorisering af stakkene.
Containere, SELinux/AppArmor og realistiske forventninger
containere og MAC-frameworks som f.eks. SELinux eller AppArmor supplerer FPM effektivt. Containerisering hjælper med at binde afhængigheder pr. projekt og begrænse adgangen til rodfilsystemet. Jeg holder images på et minimum, fjerner unødvendige funktioner og monterer kun de mapper, der virkelig er brug for. SELinux/AppArmor-profiler begrænser systemopkald og forhindrer en proces i at operere uden for sin kontekst. Det er stadig vigtigt: Containere er ikke en erstatning for FPM-isolering og rene filtilladelser - de udgør et ekstra lag, der opfanger fejl, ikke erstatter grundlaget.
Praktisk tjekliste til værter og teams
I projekter starter jeg med en klar SekvensFørst adskiller jeg konti teknisk, og derefter udruller jeg FPM-pools pr. domæne. Derefter sætter jeg realistiske grænser, måler belastningsspidser og justerer pm.max_children og pm.max_requests. Derefter kontrollerer jeg filtilladelser, sikrer uploadmapper og fjerner unødvendige skriverettigheder. Jeg konfigurerer OPcache pr. pool, så kode, sessioner og cacher forbliver isolerede. Til sidst tester jeg failover: Jeg simulerer hangs, DoS-mønstre og out-of-memory-situationer, indtil beskyttelsesmekanismerne fungerer pålideligt.
Kort opsummeret
En ting er sikkert for mig: FPM tilbyder det bedste Balance af sikkerhed og ydeevne, især når man sammenligner fpm med cgi. CGI er stadig nyttigt, når absolut adskillelse prioriteres over hastighed, men FPM opnår lignende sikkerhedsmål med betydeligt mindre overhead. Dedikerede pools, hårde grænser og separate cacher reducerer hostingrisikoen betydeligt i delte miljøer. Suppleret med procesisolering, rene filtilladelser og kontrolleret OPcache-anvendelse sætter en vært de afgørende skinner. Ved konsekvent at kombinere disse komponenter beskyttes projekterne effektivt, samtidig med at svartiderne holdes lave.
