Svetainės apsaugos stiprinimas: teisės, antraštės ir saugumo įskiepiai

7 modulis: Saugumas · Skaitymo trukmė: 10 min.

Mokymosi tikslas: Po šios pamokos galėsite sustiprinti WordPress svetainės apsaugą naudodami teises, nustatymus ir saugumo antraštes, taip pat sąžiningai įvertinti saugumo įskiepių naudą.

Pagrindinės sąvokos: apsaugos stiprinimas (hardening), failų teisės (644, 755), DISALLOW_FILE_EDIT, jokio PHP uploads aplanke, aplankų sąrašo rodymas, versijos slėpimas, X-Powered-By, saugumo antraštės, atsarginių kopijų failai ir .git žiniatinklio aplanke, WAF serveryje, WAF įskiepyje, kenkėjiškų programų skaitytuvas

Kas yra apsaugos stiprinimas

Apsaugos stiprinimas (hardening) reiškia: taip sukonfigūruoti svetainę, kad klaida ar saugumo spraga padarytų kuo mažiau žalos. Tai nepakeičia atnaujinimų ir stiprių slaptažodžių (pamoka 7.2 ir 7.3), bet sumažina pasekmes. Pagalvokite apie namą: atnaujinimai yra spynos, o apsaugos stiprinimas tai užtikrinimas, kad įsilaužėlis, kuris vis dėlto pateko į vidų, negalėtų pasiekti seifo.

Failų teisės

Kiekvienas failas ir aplankas serveryje turi teises: kas gali skaityti, rašyti ir vykdyti. Jos užrašomos trimis skaitmenimis: savininkui, grupei ir visiems kitiems. WordPress dokumentacijoje pateikiama rekomendacija:

Kokia reikšmė tinka wp-config.php, priklauso nuo to, kaip Jūsų talpinimo paslaugų teikėjas paleidžia PHP: daugumoje bendro talpinimo aplinkų PHP veikia kaip Jūsų paties naudotojas, ir tuomet pakanka 600. Išbandykite ir patikrinkite, ar svetainė vis dar veikia.

Niekada nenaudokite 777. Tai reiškia: visi serveryje gali rašyti. Instrukcija, kurioje rašoma „nustatykite aplankui 777, jei įkėlimas neveikia“, problemą sprendžia neteisingai. Kokybiškame talpinime to niekada nereikia.

Nustatymai faile wp-config.php

Kelios eilutės, kurios labai padeda (virš „Nebekeiskite!“):

// Jokio failų redagavimo iš Skydelio (Išvaizda > Temos redaktorius ir Įskiepiai > Įskiepio redaktorius).
define( 'DISALLOW_FILE_EDIT', true );

// Klaidų pranešimai niekada nerodomi lankytojų ekrane (pamoka 5.4).
define( 'WP_DEBUG', false );

Su DISALLOW_FILE_EDIT iš Skydelio dingsta redaktorius, kuriuo galima keisti temų ir įskiepių PHP failus. Įsilaužėlis, kuris perima administratoriaus paskyrą, tuomet negalės dviem paspaudimais įterpti kenkėjiško kodo į Jūsų temą. Įskiepius diegti vis dar bus galima; jei norite uždrausti ir tai (pavyzdžiui, svetainėje, kurią administruojate kliento vardu), yra DISALLOW_FILE_MODS, tačiau tada ir atnaujinimai per Skydelį nebeveiks.

Jokio PHP uploads aplanke, jokio aplankų sąrašo

Aplanke wp-content/uploads turi būti paveikslėliai ir dokumentai, niekada ne PHP failai. Įsilaužėliai, kurie per saugumo spragą gali įkelti failą, kaip tik bando ten patalpinti PHP failą ir jį iškviesti. Užblokuokite tai su .htaccess failu uploads aplanke (su LiteSpeed ir Apache):

<Files *.php>
Require all denied
</Files>

Taip pat išjunkite aplankų turinio rodymą. Jei aplanke nėra index.php ar index.html, kai kurie žiniatinklio serveriai parodo visų failų sąrašą („Index of /wp-content/uploads/2026/11“). Tai lyg vitrina tiems, kas ieško atsarginių kopijų ar jautrių dokumentų. Žiniatinklio aplanko .htaccess faile:

Options -Indexes

Daugelis talpinimo paslaugų teikėjų tai jau standartiškai išjungę. Šios pamokos užduotis tai patikrina.

Jokių likučių žiniatinklio aplanke

Viskas, kas yra žiniatinklio aplanke, gali būti pasiekiama per internetą, išskyrus tai, ką serveris vykdo kaip PHP arba blokuoja. Pavojinga yra:

• wp-config.php kopijos (wp-config.php.bak, wp-config.old, wp-config.php~ iš teksto redaktoriaus): jose yra Jūsų duomenų bazės slaptažodis, ir jos siunčiamos kaip tekstas (pamoka 1.3);
• atsarginės kopijos, pavyzdžiui, backup.zip, site.tar.gz ar database.sql žiniatinklio aplanke;
• .git aplankas iš kūrėjo, su kuriuo kas nors gali atsisiųsti visą Jūsų kodą (o kartais ir slaptažodžius);
• debug.log aplanke wp-content (pamoka 5.4);
• seni diegimo ar testiniai failai, pavyzdžiui, info.php su phpinfo().

Atsargines kopijas laikykite už žiniatinklio aplanko ribų arba už serverio ribų, o likučius pašalinkite.

Versijos slėpimas: nedidelė nauda

WordPress standartiškai įterpia į HTML:

<meta name="generator" content="WordPress 7.1.4" />

ir tą patį RSS kanale. Kartais PHP taip pat prisistato antraštėje: X-Powered-By: PHP/8.3.14. Tai paslėpti yra prasminga, bet nesitikėkite per daug: įsilaužėlių programos saugumo spragą tiesiog bando, nepriklausomai nuo rodomos versijos, o versiją dažnai galima nustatyti ir iš ?ver= parametro po skriptų nuorodomis. Slėpimas yra sutvarkymas, o ne apsauga. Svetainė, kuri slepia savo versiją, bet neatnaujinama, yra lygiai taip pat pažeidžiama.

Štai kaip tai padaryti, nuosavame mažame įskiepyje arba vaikinės temos (child theme) faile functions.php:

remove_action( 'wp_head', 'wp_generator' );
add_filter( 'the_generator', '__return_empty_string' );

O PHP antraštę pašalinkite nustatydami expose_php = Off talpinimo paslaugų teikėjo PHP nustatymuose (su DirectAdmin: Select PHP version, Options), arba su Header unset X-Powered-By faile .htaccess.

Saugumo antraštės

Keliomis antraštėmis pasakote naršyklei, kaip ji turėtų elgtis su Jūsų svetaine. Svarbiausios:

Faile .htaccess (su LiteSpeed ir Apache):

<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>

Po to patikrinkite, ar viskas veikia: įterptas turinys, mokėjimo mygtukai, pokalbių valdiklis (chat widget). Išoriniai įrankiai, tokie kaip securityheaders.com ir internet.nl, parodo, ką Jūsų svetainė siunčia.

Saugumo įskiepiai, sąžiningai įvertinti

Yra daug saugumo įskiepių (pavyzdžiui, Wordfence, Solid Security, All-In-One Security, Sucuri). Jie dažnai apjungia: ugniasienę (firewall), kenkėjiškų programų skaitytuvą, prisijungimo apsaugą, dviejų veiksnių autentifikavimą, pranešimus ir apsaugos stiprinimo sąrašą. Naudinga, bet turi ribas:

• Ugniasienė įskiepyje (WAF) pradeda veikti tik tada, kai jau veikia PHP. Kenkėjiška užklausa pirmiausia turi praeiti per žiniatinklio serverį ir PHP, kol įskiepis ją pamato. Saugumo spraga PHP faile, kuris iškviečiamas tiesiogiai, arba ataka, kuri stipriai apkrauna patį PHP, ne visada bus sustabdyta. Ugniasienė serveryje (pavyzdžiui, ModSecurity, Imunify360 ar Jūsų talpinimo paslaugų teikėjo ugniasienė) yra anksčiau grandinėje ir sustabdo daugiau, be to, Jūsų įskiepiui nereikia atlikti šio skaičiavimo darbo. Paklauskite savo talpinimo paslaugų teikėjo, kas veikia serveryje.
• Skaitytuvas randa po fakto. Kenkėjiškų programų skaitytuvas praneša, kad kažkas negerai. Tai vertinga, bet nieko neužkerta kelio. O skaitytuvas tame pačiame serveryje, kaip ir nulaužta svetainė, gali ir pats būti įsilaužėlio pakeistas.
• Jie nepakeičia atnaujinimų. Įskiepis su žinoma saugumo spraga lieka pažeidžiamas, net ir su greta veikiančiu saugumo įskiepiu. Kai kurios saugumo paslaugos siūlo „virtualius pataisymus“ (virtual patches), kurie sustabdo žinomas atakas, kol atnaujinsite; naudinga kaip laikinas sprendimas, bet ne kaip pakaitalas.
• Jie patys yra įskiepis. Daugiau kodo, daugiau ką atnaujinti, kartais ir patys turi saugumo spragą. Du saugumo įskiepiai vienu metu dažnai konfliktuoja.
• Jie reikalauja skaičiavimo galios, ypač skaitytuvai, veikiantys Jūsų paties serveryje.

Pagrįstas pasirinkimas: pirmiausia pažiūrėkite, ką jau daro Jūsų talpinimo paslaugų teikėjas (ugniasienė, kenkėjiškų programų nuskaitymas, prisijungimo bandymų blokavimas). Papildykite tai, ko trūksta, dažniausiai dviejų veiksnių autentifikavimą ir prisijungimo bandymų ribojimą. Išsamus saugumo įskiepis ypač naudingas, kai pats talpinimas siūlo nedaug.

Santrauka

• Apsaugos stiprinimas sumažina klaidos ar saugumo spragos padaromą žalą; tai nepakeičia atnaujinimų ir slaptažodžių.
• Aplankai 755, failai 644, wp-config.php griežčiau; niekada 777.
• Įjunkite DISALLOW_FILE_EDIT, užblokuokite PHP uploads aplanke, išjunkite aplankų sąrašo rodymą ir pašalinkite atsargines kopijas, .git ir debug.log iš žiniatinklio aplanko.
• Versijos slėpimas yra sutvarkymas, o ne apsauga; saugumo antraštės padeda naršyklei apsaugoti Jūsų lankytojus.
• Ugniasienė serveryje sustabdo daugiau nei įskiepis; saugumo įskiepiai yra papildymas, o ne pakaitalas.

Testas (quiz)

Užduotis

Užduotis A7.4: Ką Jūsų svetainė rodo visiems? Įveskite savo svetainės adresą. Programa nuskaito pagrindinį puslapį ir RSS kanalą (/feed/) bei patikrina: ar HTML ir kanalo generator žymoje nėra WordPress versijos, ar antraštė X-Powered-By nerodo PHP versijos, ir ar Jūsų svetainė siunčia X-Content-Type-Options: nosniff, apsaugą nuo kadrų (X-Frame-Options arba frame-ancestors) ir Referrer-Policy? HSTS (pamoka 3.1) ir Permissions-Policy trūkumas leidžiamas (oranžinė spalva).

Užduotis A7.4b: Jokių likučių žiniatinklio aplanke. Įrodykite, kad tai Jūsų pačių svetainė (TXT įrašas arba failas su užduoties kodu). Tuomet programa patikrina trumpą fiksuotą sąrašą: aplanką /wp-content/uploads/ (jokio aplankų sąrašo), /.git/HEAD, /wp-content/debug.log ir kelis dažniausiai pasitaikančius wp-config.php kopijų pavadinimus. Gerai, jei nė vienas iš jų negrąžina turinio (404 arba 403). Programa nieko daugiau nebando ir nieko nekeičia.

Papildoma literatūra

Šiuose straipsniuose aprašyti žingsniai WebOké valdymo skydeliuose; kituose skydeliuose jie veikia panašiai.

• DirectAdmin vadovas 11.5: Teisės į failus ir katalogus (chmod)
• DirectAdmin vadovas 11.4: Paslėptų failų, tokių kaip .htaccess, rodymas ir redagavimas
• DirectAdmin vadovas 15.10: Web aplikacijų ugniasienė
• DirectAdmin vadovas 15.11: Imunify360: patikrinkite savo svetainę dėl kenkėjiškų programų
• Failų, pvz., plugin-googlemap2-proxy.php, blokavimas per .htaccess
• PHP saugumas
• WordPress apsaugos stiprinimas (developer.wordpress.org, anglų kalba): https://developer.wordpress.org/advanced-administration/security/hardening/
• Saugumo antraštės (MDN, anglų kalba): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#security