Kodulehe turvalisus

wp-config.php kõvendamine: 5 konstanti, mida enamik omanikke ei sea

Kui sul on WordPressi koduleht või e-pood, siis wp-config.php on üks neist failidest, mida enamik inimesi ei puutu. Ja ausalt öeldes, arusaadav ka – seal sees on üsna tehniline kraam. Aga asi on selles, et paar väikest seadistust selles failis võivad anda su lehele päris korraliku turvakihi juurde.

See ei ole mingi maagia. Pigem selline normaalne kõvendamine, mis teeb ründaja elu raskemaks ja sinu elu rahulikumaks. Nii et vaatame 5 konstanti üle, mida päris tihti ei seata, kuigi võiks.


Miks wp-config.php üldse tähtis on?

wp-config.php on WordPressi üks tähtsamaid faile. Seal on andmebaasi ühendus, turvavõtmed ja muud põhiseaded. Kui see fail on läbimõtlemata setup’iga, siis jäävad mõned vaikimisi augud või ebavajalikud mugavused lihtsalt lahti.

Vaata, enamik väikeseid ettevõtteid ei mõtle selle peale enne, kui midagi juhtub. Alles siis hakatakse uurima, miks pluginid uuendasid end valel ajal, miks failiredaktor oli adminis lahti või miks debug info kuskile nähtavale lekkis. See on nii-öelda vaikne risk.

Kui sa tahad laiemalt aru saada, miks WordPressi uuendusi ja turvaseadeid ei tasu edasi lükata, siis see lugu selgitab hästi: Miks WordPressi uuendusi ei tohi edasi lükata.


Enne kui midagi muudad, tee üks asi ara

Enne faili muutmist tee alati backup. Mitte “kunagi peaks tegema”, vaid kohe. Kui wp-config.php sisse läheb üks vale märk, võib leht minna valgele ekraanile. Seda juhtub rohkem kui arvad.

  • Tee failist koopia oma arvutisse
  • Kui saad, tee ka kogu kodulehest backup
  • Muuda faili tekstiredaktoris, mitte suvalises vormindavas programmis
  • Salvesta muudatused ja kontrolli kohe, kas leht töötab

Kui sa ei taha neid asju ise käsitsi näppida või tahad, et keegi jälgiks lehte ka pärast muudatusi, siis WordPressi hooldusteenus on selle jaoks päris mugav variant.


1. DISALLOW_FILE_EDIT – keera failiredaktor kinni

Vaikimisi saab WordPressi adminis mõnikord teema- ja pluginifaile otse muuta. See võib tunduda mugav. Praktikas on see aga paras risk.

Kui keegi saab admini ligi – kas nõrga parooli, varastatud sisselogimise või pahatahtliku kasutaja kaudu – siis saab ta otse administ koodi sisse kirjutada. Ja siis ongi jama majas.

Lisa wp-config.php faili see rida:

define('DISALLOW_FILE_EDIT', true);

See ei riku su lehte ära. Lihtsalt eemaldab administ faili muutmise võimaluse. Kui on vaja koodi muuta, tee seda turvalisemalt üle failihalduse või git workflow kaudu. Väikeettevõtte puhul piisab enamasti sellest, et arendaja teeb muudatused kontrollitult.

  • Hea siis, kui lehel on mitu kasutajat
  • Hea siis, kui kasutad palju pluginaid
  • Väga hea siis, kui sa ise koodi nagunii ei muuda

2. DISALLOW_FILE_MODS – peata faili muutmised administ

See konstant on eelmisest sammu võrra karmim. Kui DISALLOW_FILE_EDIT paneb kinni ainult faili redigeerimise, siis DISALLOW_FILE_MODS keelab administ ka pluginate ja teemade paigaldamise ning uuendamise.

define('DISALLOW_FILE_MODS', true);

Nüüd, see ei sobi kõigile. Kui sa haldad ise aktiivselt oma lehte ja teed update’e administ, siis see võib sulle ette jääda. Aga kui sul on stabiilne koduleht, kus muudatusi tehakse harva ja pigem kontrollitult, siis on see väga asjalik kaitse.

Eriti e-poe puhul. Sest seal võib üks vale update valel hetkel katkestada tellimused või maksed.

Kasuta seda siis, kui:

  1. Lehel on kindel hooldaja või arendaja
  2. Sa ei taha, et töötajad ise pluginaid juurde paneks
  3. Soovid vältida juhuslikke või pahatahtlikke muudatusi administ

Samas, kui valid selle konstanti, peab sul olema normaalne hooldusprotsess. Muidu hakkad uuendusi liiga kauaks edasi lükkama, ja see pole ka hea mõte.


3. FORCE_SSL_ADMIN – admin alati HTTPS peale

Kui su leht kasutab SSL-serti ehk avaneb https peal, siis adminiala peaks samuti alati sunniviisiliselt HTTPS-i kasutama. Mõnel lehel on see juba serveri poolelt korras, mõnel mitte. Kontrollida tasub ikka.

define('FORCE_SSL_ADMIN', true);

See aitab kaitsta sisselogimist ja adminis tehtavaid tegevusi. Ilma selleta võivad sessioonid või sisselogimisandmed kehva setupi korral lekkida lihtsamini, eriti vanemates või valesti seadistatud keskkondades.

Lühidalt – kui sul on SSL olemas, siis see rida võiks olla paigas. Kui SSL-i pole, siis tee see korda enne. Ilma HTTPS-ita on 2026. aastal ettevõtte koduleht ausalt öeldes juba kahtlane.

Kui tahad lisaks sisselogimise turvet tugevdada, siis soovitan lugeda ka seda artiklit: Kuidas kaitsta WordPressi sisselogimist robotrünnakute eest.


4. WP_AUTO_UPDATE_CORE – ära jäta tuuma uuendusi juhuse hooleks

See on koht, kus paljud omanikud ei tea, et neil üldse valik on. WordPressi tuuma automaatsed uuendused võivad olla osalised, täielikud või kinni keeratud. Vaikeseade ei ole alati see, mida sinu ärile vaja.

Kui tahad lubada kõik tuuma uuendused automaatselt:

define('WP_AUTO_UPDATE_CORE', true);

Kui tahad ainult väiksemaid turva- ja hooldusuuendusi:

define('WP_AUTO_UPDATE_CORE', 'minor');

Enamiku väikeettevõtete jaoks on 'minor' täitsa okei valik. See tähendab, et kriitilised väiksemad parandused tulevad automaatselt, aga suuremad versioonihüpped ei lenda su lehele ilma kontrollita peale.

Praktikas on see mõistlik tasakaal:

  • turvapaigad jõuavad kiiremini peale
  • väheneb risk, et vana tuum jääb haavatavaks
  • samal ajal ei teki nii suurt ohtu, et mõni suur update layouti või pluginad sassi lööb

Tegelikult on just uuenduste venimine üks sagedasemaid põhjuseid, miks WordPress lõpuks pihta saab. Mitte ainus, aga omjagu levinud.


5. WP_DEBUG ja WP_DEBUG_DISPLAY – ära näita vigu külastajale

Arenduses on debug väga kasulik. Avalikul ärilehel mitte eriti. Kui debug on valesti seadistatud, võib veateade näidata külastajale failiteid, pluginanimesid, serveri infot ja muud kraami, mida ründajal on hea kasutada.

Turvalisem valik on selline:

define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);

Kui sul on vaja vigu logida, siis tee seda faili, mitte ekraanile. Arenduskeskkond ja live-leht ei peaks käituma samamoodi. See on detail, mida päris sageli unustatakse pärast arendust ära.

Eriti ohtlik on see siis, kui:

  • lehte on hiljuti arendatud
  • kasutati testimiseks debug mode’i
  • arendaja lõpetas töö, aga seaded jäid koristamata

Lühike sentence. Kontrolli see üle juba täna.


Kuhu need read täpselt panna?

Üldiselt lähevad need read wp-config.php faili enne rida, kus on kiri:

/* That's all, stop editing! Happy publishing. */

Ära pane neid faili suvalisse kohta, kui sa ei tea mida teed. WordPress loeb seda faili kindlas järjekorras. Vale koht ei pruugi alati midagi katki teha, aga vahel teeb küll.

Lihtne meelespea:

  1. Ava wp-config.php
  2. Leia lõpu poole “stop editing” kommentaar
  3. Lisa konstandid selle rea kohale
  4. Salvesta ja testi lehte

Kas ainult neist piisab?

Ei. Need 5 konstanti on hea algus, aga mitte kogu turvalisus. WordPressi kaitse tähendab tavaliselt mitme asja koosmõju – uuendused, backupid, sisselogimise kaitse, tulemüür, seire, korralik majutus, mõistlikud kasutajaõigused.

Kui su leht on juba imelikult käitunud, näiteks tekivad võõrad adminid, suunamised või kahtlased failid, siis ära jää oletama. Siis on targem vaadata seda teenust: abi häkitud veebilehe puhastamisel.

Ja kui midagi on juba valesti, siis loe ka seda praktilist juhendit: WordPress sai häkitud – mida kohe teha ja kuidas leht puhtaks saada.


Mida ma soovitaks väikeettevõtte omanikule päriselt teha?

Kui sul on üks koduleht ja sa ei taha tehnilise poolega iganädalaselt jännata, siis tee vähemalt need sammud ära:

  • keera kinni failiredaktor
  • sunni admin HTTPS peale
  • pane tuuma väiksed uuendused automaatselt tulema
  • veendu, et debug vead ei oleks avalikult nähtavad
  • tee enne muudatusi backup

Kui sul on WooCommerce e-pood, siis lisaks sellele ära testi muudatusi reedel kell 16. See kõlab naljakalt, aga päriselt. Päris tihti tehakse just siis update ära ja nädalavahetus läheb tulekahju kustutamise peale.

Vaata, point ei ole kõike ise teha. Point on teada, mis peab paigas olema, ja vajadusel lasta see korda teha. Nii on lõpuks odavam ka.


Viimane mõte

wp-config.php kõvendamine ei ole suur projekt. See on paar rida koodi, aga mõju võib olla üllatavalt suur. Eriti siis, kui su leht teenib päriselt raha või toob kliente.

Ausalt öeldes on see üks neist väikestest turvasammudest, mis jääb üsna sageli tegemata lihtsalt sellepärast, et keegi ei ütle. Nüüd ütlesin. Tee need viis asja üle vaadata ja su WordPress on juba natuke tugevam kui enamikul.