Veebilehe turvalisus: praktiline juhend
Enamikku lehti ei rünnata sihilikult. Nad leitakse automaatsete skanneritega, mis pühivad internetti teadaolevate haavatavuste ja nõrkade paroolide otsingul. See on hea uudis, sest see tähendab, et põhimeetmed peatavad enamiku rünnetest.
See juhend katab need meetmed, umbes selles järjekorras, kui palju riski nad kulutatud vaeva kohta eemaldavad.
Ligipääsud: kust enamik murdmisi algab#
Varastatud või ära arvatud tunnused on levinuim viis, kuidas väikesed lehed langevad — levinum kui ükski tehniline haavatavus.
- Kaheastmeline autentimine igal halduskontol, eranditeta.
- Unikaalsed paroolid paroolihaldurist; korduvkasutatud paroolid lekivad mujal ja testitakse siin.
- Kustuta lahkunud inimeste ja vanade agentuuride kontod — see unustatakse peaaegu alati.
- Anna minimaalsed vajalikud õigused; toimetaja ei pea olema administraator.
- Piira sisselogimiskatseid ja blokeeri korduvate ebaõnnestumiste järel.
- Kaitse ka ümbritsevat: server, DNS, domeeniregistripidaja ja e-post. DNS-i kaotamine on hullem kui lehe kaotamine.
- Kasuta SFTP-d või SSH võtmeid, mitte kunagi tavalist FTP-d parooliga.
Domeeniregistripidaja konto jääb kõige sagedamini ilma teise astmeta ja põhjustab kõige suuremat kahju, kui see langeb.
Uuendused ja ründepind#
Iga paigaldatud tarkvara on midagi, mida tuleb ajakohasena hoida. Odavaim turvatöö on eemaldada see, mida sa ei kasuta.
| Meede | Miks see loeb |
|---|---|
| Sisuhaldussüsteemi tuum ajakohane | Teadaolevaid haavatavusi skaneeritakse päevadega |
| Pluginad ajakohased | Levinuim sissepääsutee WordPressi lehtedel |
| Eemalda kasutamata pluginad | Väljalülitatud ei ole turvaline; kood on ikka seal |
| Eemalda kasutamata teemad | Sama põhjus, unustatakse veel sagedamini |
| Toetatud PHP versioon | Vanad versioonid ei saa turvaparandusi |
| Serveri paketid ajakohased | Hallatud majutuses pakkuja vastutus — kontrolli |
| Sõltuvused oma koodis | Teegid vananevad samuti |
Käivita uuendused testkeskkonnas ja testi seejärel vormid ning e-poes ostuvoog. Uuendus, mis lõhub vormi vaikselt, on omaette rikketüüp.
Rakenduse ja serveri kaitse#
Meetmed, mis katavad tehnilisi haavatavusi, mitte ligipääse.
- Valideeri ja puhasta kõik sisendid serveripoolel. Brauseri kontroll on mugavus, mitte turvalisus.
- Kasuta ettevalmistatud päringuid kogu andmebaasitöös — see sulgeb SQL-i süstimise.
- Kaitse väljundit kuvamisel, et vältida saitidevahelist skriptimist.
- HTTPS kõikjal, koos HSTS-i ja automaatselt uueneva sertifikaadiga.
- Sea turvapäised: Content-Security-Policy, X-Content-Type-Options, Referrer-Policy.
- Piira failide üleslaadimist tüübi ja suuruse järgi ning salvesta need veebikataloogist väljapoole.
- Lülita veateadete kuvamine tootmises välja; veateated ütlevad ründajale, mis töötab.
- Kaalu veebirakenduse tulemüüri sisuhaldussüsteemis, kus on palju pluginaid.
Varundus ja taastumine pärast murdmist#
Turvalisus vahel ebaõnnestub. Mis siis juhtub, sõltub täielikult sellest, mida sa ette valmistasid.
- Hoia varukoopiaid väljaspool serverit. Koopia samal masinal krüpteeritakse või kustutatakse koos ülejäänuga.
- Hoia mitut põlvkonda. Kui murdmine avastatakse kahe nädala pärast, on eilne koopia samuti nakatunud.
- Testi taastamist kvartalis. See on samm, mis kõige sagedamini puudub.
- Murdmise korral: võta leht maha või pane hooldusrežiimi, enne kui midagi muud teed.
- Vaheta iga parool — sisuhaldus, server, andmebaas, FTP, DNS — enne taastamist.
- Taasta murdmiseelsest koopiast ja uuenda kõik, enne kui avalikuks lähed.
- Selgita välja, kuidas nad sisse said. Taastamine ilma põhjuseta tähendab, et see kordub.
Isikuandmeid puudutava juhtumi korral kehtivad teavitamiskohustused lühikeste tähtaegadega. Tea ette, kes seda hindab, mitte juhtumi keskel.
Korduma kippuvad küsimused
Kas WordPress on ebaturvaline?
Tuum on mõistlikult hästi hooldatud; risk on peaaegu alati pluginates, teemades ja nõrkades administraatoriparoolides. WordPressi leht kaheastmelise autentimise, väheste pluginate ja ajakohaste versioonidega on täiesti korras. Leht neljakümne pluginaga, millest pooli pole kaks aastat uuendatud, on aja küsimus.
Kas ma vajan turvapluginat?
Need on kasulikud sisselogimiste piiramiseks, failide jälgimiseks ja hoiatusteks, kuid nad ei asenda ühtegi punkti ülaltoodud nimekirjast. Turvaplugin lehel, kus on vananenud pluginad ja jagatud parool, ei lahenda päris probleemi. Kohtle seda suitsuandurina, mitte tulekindla konstruktsioonina.
Mida teha, kui leht murtakse?
Võta see maha, vaheta iga parool sealhulgas server ja DNS, ning taasta seejärel puhtast murdmiseelsest koopiast. Uuenda kõik enne avalikuks minekut ja selgita välja, kuidas nad sisse said — muidu kordub see nädalatega. Kui isikuandmed on mängus, kehtivad teavitamiskohustused lühikeste tähtaegadega.
Kas HTTPS kaitseb mu lehte häkkerite eest?
Ei, ja see on levinud arusaamatus. HTTPS krüpteerib liikluse külastaja ja serveri vahel, mis takistab pealtkuulamist ja muutmist teel. See ei tee midagi nõrkade paroolide, vananenud pluginate või SQL-i süstimise vastu. See on hädavajalik ja täiesti ebapiisav.
veebilehe turvalisusmurdmise vältiminewordpress turvalisusssl sertifikaatturvapäisedmurtud veebileht