PHP käivitamise keelamine üleslaadimiskaustades

Lühidalt: PHP käivitamise keelamiseks üleslaadimistes selgitate esmalt välja kõik kaustad, kuhu PHP tohib kirjutada, ja blokeerite seejärel igaühes neist skriptide käivitamise serverikonfiguratsioonis, mitte .htaccess kaudu. Nginxis peab blokeering rakenduma enne üldist PHP-plokki, Apache'is kuulub see VirtualHosti koos AllowOverride None-iga. security.limit_extensions = .php FPM-poolis ja test kahjutu failiga lõpetavad töö.

Miks just praegu üleslaadimiskaustad loevad

Pärast kriitilist auku nagu PHP2Shell ei taha ründajad harva koodi käivitada vaid üks kord. Nad tahavad tagasi tulla, ka siis kui server hiljem paigatakse. Lihtsaim tee selleks on veebishell: väike PHP-fail, paigutatud kirjutatavasse kausta ja hiljem brauseri kaudu avatud.

Paik sellist faili ei eemalda. Kes oli 20. oktoobrist 2026 alates paigata võrgus, peaks seetõttu mitte ainult uuendama, vaid ka kontrollima, kas kuskil on uusi PHP-faile, ja edaspidi takistama nende käivitamist. Kuidas leide tõlgendada, kirjeldab PHP-failid üleslaadimiskaustas: leidude õige tõlgendamine.

Käivitusblokeering seab tingimuse teisele küljele. See ei takista faili paigutamist, kuid takistab, et server seda programmina käsitleks.

Esmalt inventuur: kuhu tohib PHP kirjutada?

Enamik juhendeid nimetab ainult üleslaadimiskausta. Praktikas kirjutab PHP rakendus palju rohkemates kohtades. Igaüks neist, mis on veebiserveri kaudu kättesaadav, vajab blokeeringut.

Millised kaustad need teie serveris on, näitab otsing käitusaja kasutaja õigustega. See ei muuda midagi:

# Kõik kaustad kataloogi /var/www all, kuhu PHP kasutaja tohib kirjutada
# (kohandage kasutajat: www-data, nginx, apache või oma pooli kasutaja)
sudo -u www-data find /var/www -type d -writable 2>/dev/null | sort
# Kas nendes kaustades on juba PHP-faile?
sudo -u www-data find /var/www -type d -writable -print0 2>/dev/null \
  | xargs -0 -I{} find {} -maxdepth 1 -type f -iname "*.ph*" 2>/dev/null

Kui esimene otsing tagastab kogu veebijuurkataloogi, kuulub programmikood käitusaja kasutajale. Seda peaksite enne muutma, nagu kirjeldab juhend Failiõigused veebiserveris. Muidu ei ole ühtegi kausta, mida poleks vaja blokeerida.

PHP käivitamise keelamine üleslaadimistes: Nginx

Nginxis otsustab järjekord. Nginxi dokumentatsiooni järgi kontrollitakse regulaaravaldisi konfiguratsioonifaili järjekorras ja esimene vaste võidab. Kui üldine plokk location ~ \.php$ asub enne teie blokeeringut, käivitatakse fail. Lihtne prefiks-location ilma ^~-ta ei kaitse samal põhjusel.

Turvaline on kõigi blokeeritud kaustade regulaaravaldis, mis asub enne PHP-plokki. See katab ka harva kasutatavad laiendid:

server {
    # ... põhikonfiguratsioon ...

    # 1. Kirjutatavate kaustade blokeering, PEAB olema enne PHP-plokki
    location ~* ^/(uploads|media|cache|tmp|export)/.*\.(php\d?|phtml|phar|pht|phps)$ {
        deny all;
    }

    # 2. Üldine PHP-plokk: anda edasi ainult olemasolevad failid
    location ~ \.php$ {
        try_files $uri =404;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php/seite1.sock;
    }
}

Kohandage kaustade nimed oma inventuurile. Ühe ainsa sisenemispunktiga rakenduste puhul on tee lubatud loendi kaudu veel tugevam; mustrit näitab Nginx PHP jaoks turvaliselt seadistamine.

Apache ja PHP-FPM: blokeering õiges kohas

Apache'is kuulub blokeering serverikonfiguratsiooni või VirtualHosti. .htaccess üleslaadimiskaustas ei sobi, sest seda saab muuta igaüks, kes seal kirjutada tohib. Kogu veebijuurkataloogi jaoks kehtib seetõttu AllowOverride None. Apache'i dokumentatsiooni järgi on AllowOverride lubatud ainult <Directory>-plokkides ilma regulaaravaldisteta, seega seate selle veebijuurkataloogile ja blokeeringu käsuga <DirectoryMatch> selle all:

<Directory /var/www/seite1/public>
    AllowOverride None
    Require all granted
</Directory>

<DirectoryMatch "^/var/www/seite1/public/(uploads|media|cache|tmp|export)/">
    <FilesMatch "\.(php\d?|phtml|phar|pht|phps)$">
        Require all denied
    </FilesMatch>
</DirectoryMatch>

Kui mod_php veel töötab, lisage samasse plokki php_admin_flag engine off. PHP-FPM-i puhul toimib teine tõkend poolis: security.limit_extensions määrab, milliseid laiendeid FPM üldse käivitab. PHP käsiraamatu järgi on vaikeväärtus .php .phar; soovitatav on piirduda laiendiga .php.

; poolis, nt /etc/php/8.3/fpm/pool.d/seite1.conf
security.limit_extensions = .php

Testimine kahjutu failiga

Kas blokeering mõjub, näitab ainult test. Pange igasse blokeeritud kausta korraks fail, mis väljastab ainult teksti, avage see domeeni kaudu ja kustutage seejärel.

1. Kontrollige konfiguratsiooni: nginx -t või apachectl configtest, seejärel laadige uuesti.
2. Looge testfail, näiteks uploads/sperrtest.php sisuga <?php echo 'ausgefuehrt';.
3. Avage käsuga curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/uploads/sperrtest.php. Oodatav on 403.
4. Kui ilmub selle asemel 200 ja tekst „ausgefuehrt“, blokeering ei rakendu. Kontrollige konfiguratsiooni ja järjekorda.
5. Kustutage testfail ja korrake testi iga kausta ja iga veebisaidi jaoks.

Kuidas üleslaadimisfunktsioone koodis turvaliselt ehitada, tüübikontrolli ja veebijuurkataloogist väljaspool hoiustamisega, on kirjas juhendis Failide üleslaadimise turvaline teostus PHP-s.

Kokkuvõte: kirjutada jah, käivitada ei

Käivitusblokeering kirjutatavates kaustades on üks tõhusamaid üksikmeetmeid püsivate tagauste vastu. See maksab mõne rea konfiguratsiooni ja ei riku korralikult ehitatud rakendustes midagi. Otsustavad on kolm asja: täielik inventuur, mitte ainult ilmselge üleslaadimiskaust, õige järjekord Nginxis või õige tasand Apache'is ja tõeline test kahjutu failiga.

Täiendatuna programmikoodi eraldatud omanikega, poolis oleva security.limit_extensions-iga ja uute PHP-failide korrapärase otsinguga tekib seis, kus paigutatud fail on küll tüütu, kuid vaevalt enam kasutatav. See ei asenda ei uuendust ega jäljeotsingut, kuid võtab ründajatelt ühe nende olulisema tööriista.

Kuidas PHP SOS konkreetselt aitab?

• Inventuur: selgitame välja kõik kirjutatavad kaustad veebisaidi kaupa ja kontrollime neid olemasolevate PHP-failide suhtes.
• Blokeeringud seada: kanname käivitusblokeeringud Nginxi, Apache'i ja PHP-FPM-i, õiges järjekorras ja ilma .htaccess-sõltuvuseta.
• Testida: kontrollime iga blokeeringut kahjutu failiga ja dokumenteerime tulemuse.
• Puhastada: leidude korral teeme jälgede kindlustamise ja pahavara eemaldamise.

Korduma kippuvad küsimused

Allikad

• Nginx: location-plokkide valik
• Apache: põhifunktsioonid (AllowOverride, FilesMatch)
• PHP käsiraamat: FPM-i konfiguratsioon (security.limit_extensions)
• OWASP Cheat Sheets (File Upload)