Sigurno konfigurirati Apache za PHP

Ukratko: Da biste Apache za PHP konfigurirali sigurno, PHP povežite putem PHP-FPM-a i mod_proxy_fcgi, isključite .htaccess pomoću AllowOverride None i postavite ServerTokens Prod, ServerSignature Off, TraceEnable Off i Options -Indexes. LimitRequestBody prilagodite PHP granicama, a nepotrebne module isključite. Konfiguracija ne zamjenjuje PHP ažuriranje, ali znatno smanjuje napadnu površinu.

Apache nakon PHP2Shella: više od ponovnog pokretanja

Operateri Apachea u listopadu 2026. bili su pod osobitim pritiskom. PHP tim rizik kod mod_php-a ocjenjuje najvišim jer je tamo pokazan exploit prije nego što se uopće izvrši kod aplikacije. Akutne korake, dakle zakrpanje i potpuno ponovno pokretanje, opisuje stranica Zašto mod_php nosi najveći rizik.

Nakon zakrpe ostaje pitanje koliko je dobra sama Apache konfiguracija. Poslužitelji koji su rasli često nose postavke iz mnogih godina: popise direktorija, otvorena .htaccess prava, module koje nitko više ne treba. Svaka od njih može kasniju pogrešku učiniti većom nego što bi morala biti.

Ovaj članak opisuje vitku, sigurnu osnovnu konfiguraciju za Apache 2.4 s PHP-FPM-om. Primjeri koriste Debian i Ubuntu putove; u RHEL obitelji datoteke se nalaze pod /etc/httpd/.

PHP povezati putem PHP-FPM-a umjesto mod_php-a

S PHP-FPM-om PHP radi u vlastitim procesima, odvojeno od web-poslužitelja. Apache zahtjeve prosljeđuje putem mod_proxy_fcgi. Prema dokumentaciji Apachea povezivanje putem SetHandler ima prednost pred ProxyPassMatch: Apache zahtjev najprije sam pridruži datoteci u datotečnom sustavu, a tek zatim ga prosljeđuje PHP-FPM-u.

<FilesMatch "\.php$">
    SetHandler "proxy:unix:/run/php/seite1.sock|fcgi://localhost/"
</FilesMatch>

Module na Debianu i Ubuntuu uključujete naredbom a2enmod proxy_fcgi. Tko prelazi s mod_php-a, deaktivira PHP modul i zatim prelazi s Prefork na Event MPM. Pozadinu starog načina rada objašnjava članak mod_php objašnjen: PHP u Apache procesu.

Na strani PHP-FPM-a security.limit_extensions = .php pripada u svaki pool. Prema PHP priručniku FPM inače izvršava i .phar datoteke.

Apache PHP sigurno konfigurirati: temeljne opcije

Neke postavke vrijede za cijeli poslužitelj i pripadaju u zasebnu konfiguracijsku datoteku, primjerice /etc/apache2/conf-available/haertung.conf, aktiviranu pomoću a2enconf haertung.

# Skratiti podatke o verziji (moguće samo na razini cijelog poslužitelja)
ServerTokens Prod
ServerSignature Off

# Isključiti TRACE metodu
TraceEnable Off

# Načelno ništa ne odobravati, web-stranicama dopuštati ciljano
<Directory />
    Options None
    AllowOverride None
    Require all denied
</Directory>

Sljedeća tablica svrstava najvažnije opcije. Zadane vrijednosti i učinak potječu iz dokumentacije Apachea.

Važno kod AllowOverride: mnoge distribucije i upute za CMS za web-korijen postavljaju AllowOverride All. Time svaka .htaccess datoteka može mijenjati pravila prepisivanja, handlere, a kod mod_php-a čak i PHP postavke. Napadač s pravima pisanja u mapi za prijenose može tamo odložiti vlastitu .htaccess. S AllowOverride None taj je put zatvoren.

VirtualHost kao predložak

Sljedeći VirtualHost povezuje točke za jednu web-stranicu. Putove certifikata, socket i direktorije prilagodite. mod_ssl i mod_headers moraju biti aktivni.

<VirtualHost *:443>
    ServerName www.example.de
    DocumentRoot /var/www/seite1/public

    SSLEngine on
    SSLCertificateFile    /etc/ssl/seite1/fullchain.pem
    SSLCertificateKeyFile /etc/ssl/seite1/privkey.pem

    <Directory /var/www/seite1/public>
        Options -Indexes +SymLinksIfOwnerMatch
        AllowOverride None
        Require all granted
    </Directory>

    <FilesMatch "\.php$">
        SetHandler "proxy:unix:/run/php/seite1.sock|fcgi://localhost/"
    </FilesMatch>

    # Blokirati upravljanje verzijama i datoteke okruženja
    <DirectoryMatch "/\.(git|svn|hg)">
        Require all denied
    </DirectoryMatch>
    <FilesMatch "^\.env">
        Require all denied
    </FilesMatch>

    # 32 MiB, prilagođeno post_max_size = 32M
    LimitRequestBody 33554432

    Header unset X-Powered-By
    Header always unset X-Powered-By
</VirtualHost>

Dvostruki Header unset nije previd. Prema dokumentaciji Apachea zaglavlja iz mod_proxy_fcgi završavaju u drugoj internoj tablici od zaglavlja samog poslužitelja; s obje varijante obuhvaćate oba slučaja. Daljnja zaglavlja koja aktivno štite posjetitelje opisuje vodič Sigurnosna zaglavlja za web-stranice.

Mape za prijenose i predmemoriju trebaju dodatnu zabranu izvršavanja. Kako pronaći i blokirati sve zapisive mape, piše u članku Zabraniti izvršavanje PHP-a u mapama za prijenose.

Počistiti module i provjeriti rezultat

Svaki učitani modul je kod koji reagira na zahtjeve. Provjerite koji su moduli aktivni i isključite što Vam ne treba. Tipični kandidati su autoindex, status bez ograničenja pristupa, cgi i userdir.

# Prikazati aktivne module
apachectl -M | sort
# Primjer Debian/Ubuntu: isključiti modul za popise direktorija
sudo a2dismod autoindex
# Provjeriti konfiguraciju i tek zatim ponovno učitati
sudo apachectl configtest && sudo systemctl reload apache2
# Test izvana: TRACE treba vratiti 405, .git 403
curl -s -o /dev/null -w "%{http_code}\n" -X TRACE https://www.example.de/
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/.git/HEAD

Osobitu pažnju zaslužuje mod_status. Status stranica prikazuje pokrenute zahtjeve s adresama i pozvanim putovima. Ako je potrebna, pristup ograničite pomoću Require ip na Vaše administrativne mreže. Isto vrijedi za status stranice PHP-FPM-a koje su učinjene dostupnima putem Apachea.

Kao dodatni sloj ispred aplikacije može imati smisla vlastiti Web Application Firewall; uvod opisuje članak Primijeniti ModSecurity i OWASP Core Rule Set.

Zaključak: red pobjeđuje pojedinačne mjere

Sigurna Apache konfiguracija za PHP sastoji se od nekoliko dobro shvaćenih gradivnih elemenata. PHP radi putem PHP-FPM-a odvojeno od web-poslužitelja, .htaccess se ne evaluira, podaci o verziji i TRACE su isključeni, granice veličine odgovaraju PHP-u, a zapisive mape ne izvršavaju skripte. Nijedna od tih točaka sama po sebi nije spektakularna. Zajedno osiguravaju da pogreška na jednom mjestu ne dovede odmah do preuzimanja poslužitelja.

Za upravu i voditelje projekata gotovo je važnije drugo svojstvo: pospremljena konfiguracija je razumljiva. Ako sva pravila stoje u VirtualHostu umjesto da su razasuta po desecima .htaccess datoteka, kod sljedeće kritične ranjivosti brzo se može provjeriti koja je web-stranica kako povezana. U situaciji poput one u listopadu 2026. to štedi upravo vrijeme koje je presudno.

Prijelaz ipak planirajte mirno i s testnim okruženjem. Prenagljena promjena s mod_php-a na PHP-FPM neposredno prije vikenda prije stvara nove probleme nego što ih rješava.

Kako PHP SOS konkretno pomaže?

• Provjeriti stanje: čitamo cijelu Apache konfiguraciju, sve aktivne module i sve .htaccess datoteke.
• Planirati prijelaz: gdje još radi mod_php, pripremamo prelazak na PHP-FPM sa zasebnim poolovima po web-stranici.
• Ojačati konfiguraciju: postavljamo temeljne opcije, .htaccess pravila preuzimamo u VirtualHostove i blokiramo zapisive mape.
• Testirati i dokumentirati: nakon svake izmjene izvana provjeravamo web-stranice i bilježimo stanje u sklopu ojačavanja poslužitelja.

Česta pitanja

Izvori

• Apache: temeljne funkcije (core)
• Apache: mod_proxy_fcgi
• Apache: mod_headers
• php.net: sigurnosne obavijesti