Nginx PHP jaoks turvaliselt seadistamine

Lühidalt: Nginxi turvaliseks seadistamiseks PHP jaoks annate PHP-FPM-ile edasi ainult skriptid, mis tegelikult olemas on, Front-Controller-rakenduste puhul isegi ainult index.php. Lisaks tulevad blokeeritud punktfailid nagu .git ja .env, vaikeserver tundmatute hostinimede jaoks, sobivad suuruspiirid ja security.limit_extensions = .php poolis. See ei kaitse aukude eest PHP-s endas, kuid piirab, mis on pärast viga käivitatav.

Kõige ohtlikumad read asuvad PHP-location'is

Alates PHP2Shellist kontrollivad paljud meeskonnad oma PHP-FPM-i versioone ja poole, nagu kirjeldab leht Nginxi ja PHP-FPM-i turvamine, ning taaskäivitavad pärast uuendust kõik töölised. Teine pilk kehtib Nginxi konfiguratsioonile endale. Seal otsustatakse, millised failid üldse PHP-na käivitatakse.

Paljudes konfiguratsioonides on plokk, mis annab iga päringu laiendile .php PHP-FPM-ile edasi, olenemata sellest, kus fail asub. Kui sissetoodud PHP-fail satub üleslaadimiskausta, käivitab server selle. Failiveast saab nii tagauks.

See artikkel keskendub Nginxi poolele: millised direktiivid loevad, kuidas location-plokkide järjekord mõjub ja kuidas tulemust testida.

Kuidas Nginx otsustab, milline plokk rakendub

Kes tahab Nginxi PHP jaoks turvaliselt seadistada, peab teadma location-plokkide valikut. Nginxi dokumentatsiooni järgi kulgeb see nii:

1. Täpne vaste location = lõpetab otsingu kohe.
2. Prefiks-location'ite seast jäetakse meelde pikim sobiv. Kui sellel on ^~, regulaaravaldisi enam ei kontrollita.
3. Muidu kontrollitakse regulaaravaldisi (~, ~*) konfiguratsioonifaili järjekorras; esimene vaste võidab.
4. Kui ükski regulaaravaldis ei sobi, kehtib meeldejäetud prefiks-location.

Sellest tulenevad kaks praktilist reeglit. PHP blokeering üleslaadimiskaustades peab olema kas ^~-prefiksina või regulaaravaldisena üldise PHP-ploki ees. Ja tavaline prefiks-location nagu location /uploads/ ei kaitse, sest .php regulaaravaldis kirjutab selle üle.

Turvaline põhikonfiguratsioon

Järgmine näide näitab server-plokki Front-Controlleriga rakenduse jaoks, nagu see on tavaline Laraveli, Symfony, Shopware 6 või paljude omaarenduste puhul. Teed, sokli ja sertifikaadid kohandate ise.

server {
    listen 443 ssl;
    server_name www.example.de;
    root /var/www/seite1/public;
    index index.php;

    ssl_certificate     /etc/ssl/seite1/fullchain.pem;
    ssl_certificate_key /etc/ssl/seite1/privkey.pem;

    server_tokens off;
    client_max_body_size 32m;

    # Lubage Let's Encrypt ja teised tuntud teed
    location ^~ /.well-known/ {
        try_files $uri =404;
    }

    # Blokeerige peidetud failid ja kaustad (.git, .env, .htaccess)
    location ~ /\. {
        deny all;
    }

    location / {
        try_files $uri $uri/ /index.php$is_args$args;
    }

    # PHP-FPM-ile antakse üle ainult Front-Controller
    location = /index.php {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        fastcgi_param DOCUMENT_ROOT $realpath_root;
        fastcgi_hide_header X-Powered-By;
        fastcgi_pass unix:/run/php/seite1.sock;
    }

    # Ühtegi teist PHP-faili ei käivitata
    location ~ \.php$ {
        return 404;
    }
}

$realpath_root lahendab sümbolilingid. See on oluline juurutuste puhul, kus sümbolilink osutab vahelduvalt praegusele väljalasele, et PHP-FPM ja OPcache näeksid õiget teed. Arvestage lisaks: Nginxi dokumentatsiooni järgi päritakse fastcgi_param-direktiive kõrgematelt tasanditelt ainult siis, kui praegusel tasandil oma direktiive ei ole. Seetõttu kuulub include fastcgi_params; samasse plokki.

Klassikalistel CMS-idel nagu WordPress, TYPO3 või Contao on mitu sisenemispunkti. Seal asendate Front-Controller-ploki üldise PHP-location'iga, mis annab edasi ainult olemasolevad failid (try_files $uri =404;), ning blokeerite käivitamise kõigis kirjutatavates kaustades. Kuidas see õnnestub, on kirjas artiklis PHP käivitamise keelamine üleslaadimiskaustades.

Teine kaitsekiht PHP-FPM-is

Nginx otsustab, mis edasi antakse, PHP-FPM otsustab, mida ta käivitab. PHP käsiraamatu järgi käivitab PHP-FPM vaikimisi faile laienditega .php ja .phar ning soovitab ise selle laiendile .php piirata. See püüab kinni veebiserveri konfiguratsioonivead.

; poolis, nt /etc/php/8.3/fpm/pool.d/seite1.conf
security.limit_extensions = .php
listen = /run/php/seite1.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

Sokkel peaks olema kättesaadav ainult Nginxile. FPM-i pordid võrgus, näiteks 9000, ei kuulu väljapoole avada. Kuidas server tervikuna näitab ainult vajalikke porte, kirjeldab Veebiserveri tulemüür: avage ainult vajalikud pordid.

Tundmatud hostinimed ja muud häälestusnupud

Ilma oma vaikeserverita vastab Nginx tundmatute hostinimede päringutele esimese sobiva server-plokiga. Automatiseeritud skannimised, mis pöörduvad ainult IP-aadressi poole, satuvad siis otse teie rakendusse. Oma vaikeserver lõpetab sellised päringud vastuseta.

server {
    listen 80 default_server;
    listen 443 ssl default_server;
    server_name _;
    ssl_reject_handshake on;
    return 444;
}

Muud end õigustanud punktid:

Rohkem versiooniandmete kohta on artiklis expose_php ja Server-päised.

Üks häälestusnupp puudutab lubatud HTTP-meetodeid. Enamik veebisaite vajab ainult GET, HEAD ja POST. Käsuga limit_except saab muud meetodid location'is tagasi lükata; Nginxi dokumentatsiooni järgi lubab GET vabastamine automaatselt ka HEAD. Kontrollige enne, kas teie rakenduse liidesed kasutavad näiteks PUT või DELETE, sest REST-API-d teevad seda sageli.

Testimine enne uuesti laadimist

Iga muudatuse kontrollite esmalt käsuga nginx -t ja laadite Nginxi uuesti alles seejärel. Seejärel testite käitumist väljastpoolt tavaliste päringutega oma domeenile:

sudo nginx -t && sudo systemctl reload nginx
# Oodatav: 403 või 404
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/.git/HEAD
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/.env
# Oodatav: 404, sest käivitatakse ainult Front-Controller
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/info.php
# Millised plokid annavad PHP-FPM-ile üle?
sudo nginx -T 2>/dev/null | grep -nE "location|fastcgi_pass"

Kindlustage enne iga suuremat muudatust käsu nginx -T täielik väljund kuupäevaga. See sisaldab kogu kehtivat konfiguratsiooni, kõik ühendatud failid kaasa arvatud. Kui pärast muudatust läheb midagi viltu, näitab võrdlus kohe, mis erineb. Järgmise kriitilise augu korral on teil sellega lisaks usaldusväärne alus inventuuriks, ilma et peaksite kõigepealt faile kokku otsima.

Kuidas PHP SOS konkreetselt aitab?

• Konfiguratsiooni lugeda: analüüsime kogu Nginxi konfiguratsiooni käsuga nginx -T ja seome iga PHP üleandmise selle veebisaidi ja pooliga.
• Sisenemispunktid määrata: koos teie arendajatega määrame, millised skriptid peavad käivitatavad olema, ja blokeerime ülejäänud.
• Rakendada ja testida: kohandame server-plokke ja poole, kontrollime käsuga nginx -t ning testime vorme, maksetee ja üleslaadimisi.
• Püsivalt kindlustada: konfiguratsioonist saab osa meie serveri karastamisest ja teie serveri dokumentatsioonist.

Korduma kippuvad küsimused

Allikad

• Nginx: ngx_http_core_module
• Nginx: ngx_http_fastcgi_module
• PHP käsiraamat: FPM-i konfiguratsioon
• OWASP Cheat Sheets