# Serveri karastamine PHP veebiserveritele

> Serveri karastamine PHP jaoks: eraldame veebisaidid, seadistame php.ini, õigused ja ligipääsud turvaliselt ning dokumenteerime iga muudatuse.

Allikas: https://phpsos.de/et/leistungen/server-haertung/  
Seis: 25.10.2026  
Pakkuja: PHP SOS, PHP hädaabi ja serveri turvalisus. Kohene abi WhatsAppis: https://wa.me/491736494914?text=Tere%2C%20PHP%20SOS%2C%20vajame%20abi%20oma%20PHP-serveriga.%20Ettev%C3%B5te%3A%20%E2%80%A6%20Veebisait%3A%20%E2%80%A6

**Lühidalt:** Kes tahab oma serverit PHP jaoks karastada, hoolitseb selle eest, et üksik turvaauk ei avaks kogu serverit. Eraldame veebisaidid üksteisest, seadistame PHP ja veebiserveri turvaliselt, piirame õigusi ja ligipääse ning dokumenteerime iga muudatuse. Nii jääb kahju väiksemaks, kui midagi siiski juhtub.

## Miks karastamine on pärast PHP2Shelli olulisemaks muutunud

PHP2Shell on näidanud, kui kiiresti võib turvaauk PHP-s endas saada probleemiks kõigile serveri veebisaitidele. Turvaaukude CVE-2026-109618 ja CVE-2026-109619 kaudu saavad ründajad koodi käivitada ilma sisselogimata. Paik sulgeb selle ukse. Karastamine vastab teisele küsimusele: mida saab teha see, kes sellest või järgmisest turvaaugust hoolimata sisse pääseb?

Karastamata serveris töötavad sageli kõik veebisaidid sama kasutaja all, PHP tohib käivitada süsteemikäske ja ligipääsuandmed asuvad kõigile protsessidele loetavalt. Sissemurdmine väikesesse kõrvalsaiti ulatub siis kuni e-poeni. Hea karastus eraldab need alad. See ei ole ühekordne tegevus, vaid algseisund, mis peab säilima iga uue veebisaidi ja iga versioonivahetuse korral.

## Serveri karastamine PHP jaoks: mida me konkreetselt kohandame

### Veebisaitide isolatsioon

Iga veebisait saab oma süsteemikasutaja ja oma PHP-FPM-i kogumi (pool). Valikuga `open_basedir` ja sobivate failiõigustega näeb rakendus ainult oma kataloogi. Lähemalt lehel [open_basedir ja isolatsioon veebisaidi kaupa](https://phpsos.de/et/ratgeber/open-basedir/).

### Turvaline PHP seadistus

Seadistame php.ini ja pooli seadistuse nii, et rakendused ei saa turvalisuse seisukohalt olulisi väärtusi ise üle kirjutada. Väljavõte sellest, kuidas see võib FPM-i poolis välja näha:

```ini
; Väärtused FPM-i poolis kindlalt ette anda, ini_set() kaudu muudetavad ei ole
php_admin_flag[expose_php] = off
php_admin_flag[display_errors] = off
php_admin_flag[log_errors] = on
php_admin_value[open_basedir] = /var/www/kunde1/:/tmp/
php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[allow_url_include] = off
```

Milliseid funktsioone saab lisaks keelata, sõltub rakendusest. Näpunäited leiate lehtedelt [php.ini turvaline seadistamine](https://phpsos.de/et/ratgeber/php-ini-sicher-konfigurieren/) ja [disable_functions õige kasutamine](https://phpsos.de/et/ratgeber/disable-functions/).

### Failiõigused ja kirjutusõigus

Veebiserver tohib kirjutada ainult seal, kus see on vajalik, näiteks üleslaadimiskaustas. Üleslaadimiskataloogides keelatakse PHP käivitamine. Programmikood kuulub teisele kasutajale kui see, mille all PHP töötab. Põhimõtteid selgitab [failiõigused veebiserveris](https://phpsos.de/et/ratgeber/dateirechte-webserver/).

### Ligipääsud, teenused ja protokollid

SSH ainult võtmega, haldusliidesed kahefaktorilise sisselogimisega, mittevajalikud teenused ja pordid suletud. Logisid hoitakse ja kindlustatakse nii, et need on pärast intsidenti veel olemas. Varukoopiate taastatavust kontrollime.

### Veebiserver ja turvapäised

Ka veebiserver ise kuulub karastamise juurde: versiooniteabe peitmine, kataloogiloendite väljalülitamine, juurdepääsu blokeerimine seadistus-, varukoopia- ja versioonihaldusfailidele ning haldusalade täiendav kaitse, näiteks IP-lubade kaudu. Turvapäised nagu Content-Security-Policy või HSTS kaitsevad teie veebisaidi külastajaid brauseris.

## Mida me inventuuri käigus sageli leiame

Paljud nõrkused kordavad end serverist serverisse. Tüüpilised on mitu veebisaiti ühe ühise kasutaja all, avalikult ligipääsetavad andmebaasi liidesed, vanad testpaigaldused alamkaustades, unustatud PHP versioonid praeguse kõrval ning varukoopiad, mis asuvad veebikataloogis ja on allalaaditavad. Sageli puudub ka igasugune sisselogimiste logimine või logid kustutatakse mõne päeva pärast.

Ükski neist punktidest pole iseenesest märkimisväärne. Koos otsustavad nad aga selle üle, kas sissemurdmine jääb ühe veebisaidi piiresse või mõjutab kogu serverit.

## Kuidas PHP SOS konkreetselt aitab?

1. **Inventuur:** Kaardistame operatsioonisüsteemi, veebiserveri, PHP versioonid, veebisaidid, kasutajad, avatud teenused ja olemasolevad varukoopiad.
2. **Meetmeplaan:** Saate prioriseeritud loendi koos iga punkti töömahu ja võimalike mõjudega. Teie otsustate, mida ellu viiakse.
3. **Elluviimine sammude kaupa:** Muudame seadistusi kokkuleppel, testime veebisaite pärast iga sammu ja kirjutame üles, kuidas iga muudatuse saab tagasi võtta.
4. **Kontroll:** Pärast elluviimist kontrollime mõju, näiteks seda, kas veebisait tõesti enam võõraid katalooge lugeda ei saa.
5. **Üleandmine:** Saate uue seisu dokumentatsiooni, millest saavad aru ka teie veebimajutaja või agentuur.

## Mida te saate ja mida me vajame

Saate karastusaruande, kus on algseis, rakendatud meetmed, teadlikult lahtiseks jäetud punktid koos põhjendusega ja soovitus regulaarseks kontrolliks. Muudatused seadistusfailides on jälgitavalt dokumenteeritud.

Teilt vajame:

- **root- või administraatoriligipääsu** serverile, paneelide puhul lisaks paneeliligipääsu
- **rakenduste loendit** ja nende eripärasid, näiteks üleslaadimised, liidesed, cron-tööd
- **tehnilist kontaktisikut**, kes saab pärast muudatusi funktsioone kinnitada
- **hooldusaknaid** taaskäivituste jaoks
- **värsket varukoopiat** või tellimust see enne luua

## Mida me ei luba

Karastamine ei tee serverit rünnakukindlaks. See vähendab ründepinda ja piirab kahju, kuid ei asenda ei uuendusi ega seiret. Paigata PHP versioon jääb haavatavaks, hoolimata sellest, kui hästi ülejäänu on seadistatud. Seetõttu ühendame karastamise [PHP paikamisteenusega](https://phpsos.de/et/leistungen/php-patch-service/) ja soovitame seejärel pidevat hooldust [turvahoolduslepingu](https://phpsos.de/et/leistungen/security-wartungsvertrag/) kaudu.

Jagatud veebimajutuse puhul ei ole paljut võimalik seadistada, sest seadistuse määrab veebimajutaja. Siis näitame, mis on teie paketi raames võimalik ja kus oleks mõistlik üle minna oma või hallatavale serverile.


## Korduma kippuvad küsimused

**Mida tähendab serveri karastamine?**  
Karastamine tähendab kõige välja lülitamist või piiramist, mis tööks vajalik pole. Siia kuuluvad üleliigsed teenused, liiga laiad õigused, avatud pordid ja ebaturvalised vaikesätted. Eesmärk on, et üksik viga ei avaks kohe kogu serverit.

**Kas karastamine oleks PHP2Shelli ära hoidnud?**  
Ei, turvaaugu vastu PHP-s endas aitab ainult paik. Karastamine piirab aga seda, mida ründaja pärast edukat sissemurdmist saavutada võib, näiteks kas ta pääseb ligi teistele veebisaitidele või ligipääsuandmetele.

**Kas karastamine rikub mu veebisaidi?**  
Risk on olemas, kui sätteid muudetakse ilma testimiseta. Rakendame muudatused järk-järgult, kontrollime funktsioone pärast iga sammu ja kirjutame üles, kuidas iga muudatuse saab tagasi võtta.

**Kui tihti tuleks karastust üle kontrollida?**  
Hiljemalt pärast suuremaid uuendusi, PHP versiooni vahetust või uusi rakendusi serveris. Mõistlik on regulaarne kontroll jooksva hoolduse raames.

## Allikad

- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [php.net: turvateated](https://www.php.net/)