Ukratko: Tko želi ojačati poslužitelj za PHP, brine da jedna ranjivost ne otvori cijeli poslužitelj. Razdvajamo web-stranice jednu od druge, sigurno postavljamo PHP i web-poslužitelj, ograničavamo prava i pristupe te dokumentiramo svaku promjenu. Tako šteta ostaje manja ako se ipak nešto dogodi.
Zašto je ojačavanje nakon PHP2Shella postalo važnije
PHP2Shell je pokazao koliko brzo ranjivost u samom PHP-u postaje problem za sve web-stranice na poslužitelju. Putem CVE-2026-109618 i CVE-2026-109619 napadači mogu bez prijave izvršavati kod. Zakrpa zatvara ta vrata. Ojačavanje odgovara na drugo pitanje: što može učiniti netko tko ipak uđe, putem ove ili sljedeće ranjivosti?
Na neojačanom poslužitelju sve web-stranice često rade pod istim korisnikom, PHP smije izvršavati sistemske naredbe, a pristupni podaci leže čitljivo za sve procese. Provala u malu sporednu stranicu tada seže sve do internetske trgovine. Dobro ojačavanje razdvaja ta područja. Ono nije jednokratna radnja nego osnovno stanje koje se mora zadržati kod svake nove web-stranice i svake promjene verzije.
Ojačavanje poslužitelja za PHP: što konkretno prilagođavamo
Izolacija po web-stranici
Svaka web-stranica dobiva vlastitog sistemskog korisnika i vlastiti PHP-FPM pool. Uz open_basedir i odgovarajuća prava nad datotekama aplikacija vidi samo svoj direktorij. Više na stranici open_basedir i izolacija po web-stranici.
Sigurna PHP konfiguracija
php.ini i konfiguraciju poola postavljamo tako da aplikacije ne mogu same nadjačati sigurnosno relevantne vrijednosti. Isječak kako to može izgledati u FPM poolu:
; Vrijednosti u FPM poolu zadati fiksno, ne mijenjati putem ini_set()
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
Koje se funkcije dodatno mogu zabraniti, ovisi o aplikaciji. Napomene su na stranicama Sigurna konfiguracija php.ini i Ispravna uporaba disable_functions.
Prava nad datotekama i pristup pisanju
Web-poslužitelj smije pisati samo tamo gdje je potrebno, primjerice u mapu za prijenos. U mapama za prijenos onemogućuje se izvršavanje PHP-a. Programski kod pripada drugom korisniku od onoga pod kojim PHP radi. Načela objašnjava Prava nad datotekama na web-poslužitelju.
Pristupi, usluge i zapisnici
SSH samo s ključem, administratorska sučelja s dvofaktorskom prijavom, nepotrebne usluge i portovi zatvoreni. Zapisnici se čuvaju i osiguravaju tako da nakon incidenta još postoje. Sigurnosne kopije provjeravamo može li se iz njih oporaviti.
Web-poslužitelj i sigurnosna zaglavlja
I sam web-poslužitelj pripada ojačavanju: sakriti podatke o verzijama, isključiti popise direktorija, zabraniti pristup konfiguracijskim datotekama, sigurnosnim kopijama i datotekama sustava za kontrolu verzija te dodatno osigurati administratorska područja, primjerice odobrenjem po IP adresi. Sigurnosna zaglavlja poput Content-Security-Policy ili HSTS štite posjetitelje Vaše web-stranice u pregledniku.
Što često nalazimo pri popisu stanja
Mnoge se slabe točke ponavljaju od poslužitelja do poslužitelja. Tipično su to više web-stranica pod zajedničkim korisnikom, javno dostupna sučelja baza podataka, stare testne instalacije u podmapama, zaboravljene verzije PHP-a pored aktualne i sigurnosne kopije koje leže u web-direktoriju i mogu se preuzeti. Često uz to nedostaje bilo kakvo bilježenje prijava ili se zapisnici brišu nakon nekoliko dana.
Nijedna od tih točaka nije sama po sebi spektakularna. No zajedno odlučuju ostaje li provala ograničena na jednu web-stranicu ili pogađa cijeli poslužitelj.
Kako PHP SOS konkretno pomaže?
- Popis stanja: Bilježimo operacijski sustav, web-poslužitelj, verzije PHP-a, web-stranice, korisnike, otvorene usluge i postojeće sigurnosne kopije.
- Plan mjera: Dobivate prioritetan popis s utroškom i mogućim posljedicama za svaku točku. Vi odlučujete što će se provesti.
- Provedba po koracima: Konfiguracije mijenjamo nakon dogovora, nakon svakog koraka testiramo web-stranice i bilježimo kako se svaka promjena može poništiti.
- Kontrola: Nakon provedbe provjeravamo učinak, primjerice može li web-stranica doista više čitati tuđe direktorije.
- Predaja: Dobivate dokumentaciju novog stanja koju može razumjeti i Vaš pružatelj hostinga ili agencija.
Što dobivate i što trebamo
Dobivate izvješće o ojačavanju s polaznim stanjem, provedenim mjerama, namjerno otvorenim točkama s obrazloženjem i preporukom za redovitu kontrolu. Promjene konfiguracijskih datoteka dokumentirane su razumljivo.
Od Vas trebamo:
- Root ili administratorski pristup poslužitelju, a kod panela i pristup panelu
- popis aplikacija i njihovih posebnosti, primjerice prijenosi, sučelja, cron poslovi
- tehničku kontakt osobu koja nakon promjena može potvrditi funkcije
- prozore za održavanje za ponovna pokretanja
- aktualnu sigurnosnu kopiju ili nalog da se prije toga izradi
Što ne obećavamo
Ojačavanje ne čini poslužitelj nenapadivim. Smanjuje površinu napada i ograničava štetu, ali ne zamjenjuje ni ažuriranja ni nadzor. Nezakrpana verzija PHP-a ostaje ranjiva, bez obzira na to koliko je dobro postavljeno sve ostalo. Zato ojačavanje povezujemo s uslugom PHP zakrpe i potom preporučujemo trajnu skrb putem sigurnosnog ugovora o održavanju.
Kod shared hostinga mnogo toga nije moguće podesiti jer konfiguraciju zadaje pružatelj hostinga. Tada pokazujemo što je moguće u okviru Vašeg paketa i gdje bi prelazak na vlastiti ili upravljani poslužitelj bio smislen.
Česta pitanja
Što znači ojačati poslužitelj?
Ojačavanje znači isključiti ili ograničiti sve što nije potrebno za rad. Tome pripadaju suvišne usluge, preširoka prava, otvoreni portovi i nesigurne zadane postavke. Cilj je da jedna pogreška ne otvori odmah cijeli poslužitelj.
Bi li ojačavanje spriječilo PHP2Shell?
Ne, protiv ranjivosti u samom PHP-u pomaže samo zakrpa. Ojačavanje ipak ograničava što napadač može postići nakon uspješne provale, primjerice može li pristupiti drugim web-stranicama ili pristupnim podacima.
Hoće li se zbog ojačavanja pokvariti moja web-stranica?
Taj rizik postoji ako se postavke mijenjaju bez testa. Promjene provodimo korak po korak, nakon svakog koraka provjeravamo funkcije i bilježimo kako se svaka promjena može poništiti.
Koliko često treba provjeravati ojačavanje?
Najkasnije nakon većih ažuriranja, promjene verzije PHP-a ili novih aplikacija na poslužitelju. Smislena je redovita kontrola u sklopu tekućeg održavanja.