Ga naar de inhoud 
PHP Behandeling Beveiliging bepaalt hoe sterk websites van elkaar gescheiden zijn in gedeelde omgevingen en welke aanvalsoppervlakken een webserver blootstelt; in een directe vergelijking tussen FPM en CGI zijn procesisolatie, gebruikersrechten en harde limieten de belangrijkste factoren. Ik laat zien waarom FPM met dedicated pools het risico verkleint, terwijl klassieke CGI strikte isolatie biedt maar door hoge overhead latency en CPU-belasting genereert.
Centrale punten
- Isolatie bepaalt het aanvalsoppervlak en de accountoverstijgende risico's.
- FPM zwembaden Gebruikers scheiden, limieten instellen en bronnen beschermen.
- CGI isoleert sterk, maar kost CPU en tijd per verzoek.
- OPcache heeft aparte opslagsegmenten nodig voor elke account.
- gedeelde hosting voordelen van speciale FPM-instanties.
Hoe PHP handlers de beveiliging vormgeven
Elke handler verbindt de webserver en PHP-interpreter, maar de Uitvoering mod_php laadt PHP rechtstreeks in het webserverproces; dit biedt snelheid, maar deelt dezelfde gebruikerscontext en verhoogt het hostingrisico. CGI start een nieuw proces per aanvraag onder de doelgebruiker, wat de rechten netjes gescheiden houdt, maar met merkbare overhead. FastCGI houdt processen in leven en verlaagt de opstartkosten, maar alleen FPM biedt de fijne controle die moderne multi-user setups vereisen. Ik geef de voorkeur aan FPM omdat het aparte pools, aparte UID's en strikte limieten per account toestaat zonder aan efficiëntie in te boeten.
FPM vs CGI: veiligheidsafbakening in het dagelijks leven
In een directe vergelijking scheidt CGI strikt, maar FPM zet de scheiding voort. permanent en houdt de latentie laag. FPM-pools draaien onder de respectieve accountgebruiker, isoleren paden en kapselen bronnen in; op deze manier voorkomt een exploit op site A toegang tot site B. Ik beperk ook het effect van foute scripts met memory_limit, max_execution_time en request_terminate_timeout. Hoewel CGI elk proces na het verzoek beëindigt, verspilt het CPU-tijd door het constant starten en laden van extensies. In gedeelde omgevingen overheerst daarom FPM, idealiter als een dedicated pool per domein of project.
Isolatie in shared hosting: risico's en oplossingen
In gedeelde omgevingen is de grootste Hostingrisico, wanneer accounts onbedoeld bronnen of rechten delen. Aanvallers richten zich op zwakke bestandspermissies, foutieve tijdelijke mappen of ongescheiden caches. Met speciale FPM pools per account, kapsel ik processen, bestandspaden, logs en OPcache segmenten in. Ik scheid ook uploadpaden en voorkom symlink aanvallen met restrictieve mount-opties en schone eigenaarmodellen. Multi-level Procesisolatie met chroot, CageFS of jails vermindert de impact van een inbraak aanzienlijk omdat de aanvaller het hostsysteem niet kan bereiken.
Bronnenbeheer: pools, limieten en time-outs
FPM scoort punten omdat ik bronnen kan richten toewijzen en zo misbruik tegen te gaan. Ik gebruik pm.max_children om gelijktijdige PHP processen te beperken, terwijl pm.max_requests langlevende workers herstart na X verzoeken om geheugenlekken te voorkomen. request_terminate_timeout beëindigt hang-ups die anders het RAM-geheugen in beslag zouden nemen en beschermt tegen remaanvallen. Voor uploads stel ik post_max_size en upload_max_filesize in zodat normale workflows draaien, maar gigantische bestanden niet worden geaccepteerd. In combinatie met systeembrede cgroups voor CPU en RAM blijft de host zelfs tijdens piekbelastingen responsief.
Prestaties en veiligheid in een vergelijking van cijfers
Een directe vergelijking van de handlers onthult de praktische verschillen tastbaar. Ik gebruik het volgende overzicht om beslissingen te nemen en verwachtingen te ijken. De waarden beschrijven typische tendensen in echte setups en laten zien waarom FPM de eerste keuze is in shared hosting scenario's. CGI geeft voorrang aan hardheid door herstart, FPM balanceert isolatie en snelheid, LSAPI schittert met LiteSpeed stacks. Het blijft belangrijk: Isolatie zonder limieten helpt weinig, net als limieten zonder isolatie.
| handelaar | Prestaties | Beveiliging | RAM-verbruik | Isolatie | Ideaal voor |
|---|---|---|---|---|---|
| mod_php | Hoog | Laag | Laag | Laag | Kleine, eenvoudige sites |
| CGI | Laag | Hoog | Hoog | Hoog | Tests, strikte scheiding |
| FastCGI | Medium | Medium | Medium | Medium | Overgangsfase |
| PHP-FPM | Zeer hoog | Hoog | Laag | Hoog | Shared hosting, CMS |
| suPHP | Laag | Zeer hoog | Hoog | Zeer hoog | Maximale bestandsbeveiliging |
| LSAPI | Zeer hoog | Medium | Zeer laag | Medium | Veel verkeer met LiteSpeed |
Uit deze juxtapositie trek ik een duidelijk GevolgVoor multi-user hosting biedt FPM de beste algemene beveiliging per prestatie-eenheid. CGI blijft een optie voor speciale gevallen met maximale scheiding en weinig aanvragen. Ik vermijd mod_php in omgevingen met meerdere klanten. LSAPI verdient overweging wanneer LiteSpeed wordt gebruikt en RAM extreem schaars is. In de meeste scenario's wegen de voordelen van aparte FPM pools met duidelijke limieten echter op tegen de nadelen.
Configuratievallen: veilige standaardinstellingen voor FPM-stacks
Veel inbraken worden veroorzaakt door Verkeerde configuratie, niet door exotische uitbuiting. Twee schakelaars zijn voor mij verplicht: ik stel cgi.fix_pathinfo=0, om PATH_INFO-traversals te vermijden en te beperken met beveiliging.beperken_uitbreidingen de uitvoerbare eindes (bijv. .php,.php8,.phtml). In Nginx setups, controleer ik dat SCRIPT_BESTANDSNAAM correct is ingesteld en er geen verzoeken doorglippen naar willekeurige paden. Ik deactiveer ook zelden gebruikte functies zoals uitvoeren, shell_exec, proces_openen en popen via functies uitschakelen. Dit is geen wondermiddel, maar het vermindert het effect van eenvoudige webshells aanzienlijk. open_gebaseerdir Ik gebruik het zeer selectief: het kan helpen, maar leidt gemakkelijk tot neveneffecten met CLI-taken, bibliotheken voor beeldmanipulatie of Composer. Een consistente scheiding van paden per account en duidelijke rechten voor eigenaars zijn beter.
Sessies, uploads en tijdelijke mappen goed isoleren
Gewoon Temp paden zijn een klassieker voor Privilege Escalation. Voor elke FPM pool definieer ik session.save_path en upload_tmp_dir in een account-specifieke map onder de home, met beperkte rechten en sticky bit alleen waar nodig. noexec, nodev en nosuid op de mounts verminderen het aanvalsoppervlak van verdere niveaus. Voor sessie GC stel ik session.gc_probability/gc_verdeler zodat bestanden binnen van het account kan worden verouderd en verwijderd; ik verwerp globale sessiebuckets voor alle gebruikers. Iedereen die Redis gebruikt voor sessies scheidt strikt namespaces en wijst aparte credentials en limieten toe voor elk account. Dit voorkomt dat foutieve code sessies in andere projecten beïnvloedt.
Socketontwerp, autorisaties en systemd hardening
FPM pools communiceren via sockets. Ik geef de voorkeur aan UNIX sockets voor lokale communicatie en plaats ze in een accountspecifieke map met 0660 en geschikte groep. Wereldwijd 0666-sockets zijn taboe. Als alternatief gebruik ik alleen TCP met Bind op 127.0.0.1 of op een interne interface en firewalls. Op serviceniveau systemd betrouwbaar: NoNewPrivileges=waar, ProtectSystem=strict, ProtectHome=waar, Privémp=waar, CapabilityBoundingSet= (leeg), limieten voor MemoryMax, CPUQuota, TakenMax en LimitNOFILE. Dit elimineert veel escalatiepaden, zelfs als een kwetsbaarheid in een webapp wordt geraakt. Ik plaats pools ook in hun eigen schijfjes om luidruchtige buren te dempen en budgetten af te dwingen.
CLI, cron en queue worker: dezelfde isolatie als op het web
Een vaak Blindspot: php-cli draait niet via FPM. Daarom start ik cronjobs, indexers en wachtrijwerkers expliciet als de gebruiker van de geassocieerde account en gebruik ik een aparte php.ini per project (of php_value-overschrijdingen), de grenzen, uitbreidingen en open_gebaseerdir-equivalenten. Wachtrijwerkers (bijvoorbeeld van veelgebruikte CMS en frameworks) krijgen dezelfde RAM/CPU budgetten als webprocessen, inclusief een herstartstrategie in het geval van lekken. Voor terugkerende jobs stel ik backoff- en snelheidslimieten in zodat een defecte feed importer de host niet blokkeert. Pariteit is belangrijk: wat verboden is in de webpool zou niet plotseling toegestaan moeten zijn in de CLI.
Loggen, slowlogs en tegendruk
Zichtbaarheid bepaalt hoe snel ik een aanval of een verkeerde configuratie herken. Voor elke pool schrijf ik mijn eigen Foutlogboeken en activeer verzoek_slowlog_timeout fluwelen slowlog, om stack traces te verkrijgen voor hangs. loglimiet voorkomt dat individuele verzoeken de logboeken overspoelen. Met pm.status_path en een ping eindpunt, monitor ik processen, wachttijden en gebruik. Op webserverniveau stel ik Tariefgrenzen, De WAF kan ook triviale aanvalsvectoren onderscheppen. Het blijft echter van cruciaal belang dat FPM het aanvalsoppervlak per account klein houdt en de limieten betrouwbaar hun werk doen. Een WAF rule base kan ook triviale aanvalsvectoren onderscheppen; het blijft echter cruciaal dat FPM het aanvalsoppervlak per account klein houdt en limieten betrouwbaar effect hebben.
Multi-PHP-versies en extensies netjes scheiden
Vooral bij shared hosting zijn er verschillende PHP versies parallel. Ik houd mijn eigen FPM-binaire bestanden, extensies en configuraties klaar voor elke versie en bind ze per account aan. De sockets komen in aparte directories terecht zodat er niet per ongeluk verzoeken naar de verkeerde pool worden gerouteerd. OPcache blijft apart voor elke versie en elke account; opnieuw valideren_freq en validate_timestamps afhankelijk van de release-strategie. Ik ben voorzichtig met JIT: Het versnelt zelden typische CMS workloads en verhoogt de complexiteit - het uitschakelen ervan is vaak de veiligere en stabielere keuze. Ik laad extensies minimaal; alles wat niet absoluut noodzakelijk is (bijv. pdo_mysql vs. ongebruikte bestuurders), blijft buiten.
Bedreigingsmodel: typische aanvalsvectoren en invloed van de handler
In de praktijk zie ik altijd dezelfde patronen: uploads van bestanden met uitvoerbare eindes, onveilige deserialisatie, onzuivere PATH_INFO-forwarding, lokale bestandsinsluiting en symlink trucs. FPM lost dit niet automatisch op, maar het beperkt het bereikEen gecompromitteerde pool ziet alleen zijn eigen naamruimte. Met beveiliging.beperken_uitbreidingen en correcte webserverconfiguratie, voorkom ik dat het uploaden van afbeeldingen wordt geïnterpreteerd als PHP. Gescheiden temp- en sessiepaden voorkomen cross-account sessies en tempfile races. Samen met beperkende bestandspermissies, umask en noexec-toenamelt, daalt het succespercentage van eenvoudige exploits aanzienlijk.
Bestandsrechten, Umask en eigendomsconcepten
Bestandssystemen blijven een veelvoorkomend Kwetsbaarheid, als de permissies verkeerd zijn ingesteld. Ik gebruik umask om standaard permissies te regelen zodat uploads niet globaal beschrijfbaar worden. suPHP of FPM met de juiste UID/GID toewijzing zorgen ervoor dat de eigenaar van het script overeenkomt met de eigenaar van het bestand. Dit voorkomt dat een proces van een derde partij bestanden wijzigt of logs leest. Ik vergrendel ook gevoelige paden, stel noexec in op /tmp mounts en verminder het aanvalsoppervlak door consequent lees- en schrijfpaden te scheiden.
OPcache veilig gebruiken
Caching brengt snelheid, maar zonder schone scheiding ontstaat er gedeeld geheugen Bijwerkingen. Voor FPM pools houd ik OPcache apart voor elke account zodat sleutels en code elkaar niet overlappen. Ik activeer validate_timestamps in ontwikkelingsmodus en verlaag het alleen in productie voor stabiele implementaties, zodat veranderingen in de code correct worden doorgevoerd. Daarnaast controleer ik file_cache alleen binnen de homedirectory van de account, niet globaal. Als je gedeeld geheugen gebruikt, moet je de Risico's van gedeeld geheugen en beperken de zichtbaarheid strikt.
Webservercombinaties: Apache, Nginx, LiteSpeed
De keuze van het front-end beïnvloedt de latentie, TLS-handshakes en verzoekafhandeling. merkbaar. Apache met mpm_event harmonieert goed met FPM als keep-alive en proxybuffer correct zijn. Nginx voor FPM is overtuigend met statische activa en kan belasting wegschuiven, terwijl PHP alleen dynamische paden ontvangt. LiteSpeed met LSAPI levert zeer lage overhead, maar blijft gebonden aan een ander ecosysteem. In elke stack geldt: FPM-pools netjes scheiden, limieten definiëren, logs monitoren en cachelagen bewust configureren.
Hardening: chroot, CageFS en Jails
Naast handlers bepaalt de isolatie van het besturingssysteem de Effect van een inbraak. Met chroot, CageFS of Jails, vergrendel ik de account in zijn eigen bestandssysteem universum. Dit betekent dat een aanvaller de toegang verliest tot host binaries en gevoelige apparaatpaden. Gecombineerd met FPM per account creëert dit een meerlaagse verdediging die ook effectief is tegen zwakke plekken in de plugin van CMS systemen. Als je opties wilt vergelijken, kun je het volgende vinden PHP handler vergelijking waardevolle oriëntatie voor het categoriseren van de stapels.
Containers, SELinux/AppArmor en realistische verwachtingen
containers en MAC-raamwerken zoals SELinux of AppArmor FPM effectief aanvullen. Containerisatie helpt om afhankelijkheden per project te binden en de toegang tot het root bestandssysteem te beperken. Ik beperk images tot een minimum, verwijder onnodige mogelijkheden en koppel alleen de mappen aan die echt nodig zijn. SELinux/AppArmor profielen beperken systeemaanroepen en voorkomen dat een proces buiten zijn context handelt. Het blijft belangrijk: Containers zijn geen vervanging voor FPM-isolatie en schone bestandspermissies - ze vormen een extra laag die fouten onderschept, niet de basis vervangt.
Praktische checklist voor hosts en teams
In projecten begin ik met een duidelijke VolgordeEerst scheid ik accounts technisch, daarna rol ik FPM-pools uit per domein. Vervolgens stel ik realistische limieten in, meet ik belastingspieken en pas ik pm.max_children en pm.max_requests aan. Vervolgens controleer ik de bestandsrechten, beveilig ik uploaddirectories en verwijder ik onnodige schrijfrechten. Ik configureer OPcache per pool zodat code, sessies en caches geïsoleerd blijven. Tenslotte test ik failover: ik simuleer hangs, DoS patronen en out-of-memory situaties totdat de beschermingsmechanismen betrouwbaar werken.
Kort samengevat
Eén ding staat voor mij vast: FPM biedt de beste Saldo van veiligheid en prestaties, vooral bij het vergelijken van fpm vs cgi. CGI blijft nuttig wanneer absolute scheiding voorrang krijgt op snelheid, maar FPM bereikt gelijkaardige veiligheidsdoelstellingen met beduidend minder overhead. Dedicated pools, harde limieten en gescheiden caches verminderen het risico op hosting in gedeelde omgevingen aanzienlijk. Aangevuld met procesisolatie, schone bestandspermissies en gecontroleerd gebruik van OPcache zet een host de beslissende bewakingsrails. Het consequent combineren van deze componenten beschermt projecten effectief en houdt de responstijden laag.
