Veebilehe turvalisus ja kaitse – kuidas veebisaiti kaitsta?

Veebisaidi kaitse — kuidas oma veebisaiti kaitsta ja kaitsta? Veebisaidi turvalisus võib olla keeruline (või isegi segane) teema pidevalt muutuvas keskkonnas. Selle juhendi eesmärk on pakkuda selget raamistikku veebisaitide omanikele, kes soovivad riske maandada ja oma veebivaradele turvapõhimõtteid rakendada.

Enne alustamist on oluline meeles pidada, et turvalisus ei ole kunagi "seadi ja lähe" lahendus. Selle asemel soovitan teil mõelda sellest kui pidevast protsessist, mis nõuab pidevat hindamist, et vähendada teie üldist riski.

Kandideerimine süsteemne lähenemine veebisaidi turvalisusele, võime seda pidada raamistikuks, mis koosneb paljudest üheks elemendiks ühendatud kaitsekihtidest. Peame vaatama veebisaidi turvalisust terviklikult ja lähenema sellele põhjaliku kaitsestrateegiaga.

Mis on veebisaidi turvalisus?

Veebisaidi turvalisus on võetud meetmed veebisaidi kaitse küberrünnakute eest. Selles mõttes on veebisaidi turvalisus pidev protsess ja veebisaidi haldamise lahutamatu osa.

Miks on veebisaidi turvalisus oluline?

Näiteks kui veebisaiti häkitakse ja see lisatakse musta nimekirja, võib see kaotada kuni 98% oma liiklusest. Turvalise veebisaidi puudumine võib olla sama halb kui veebisaidi puudumine või veelgi hullem. Näiteks võib kliendiandmete lekkimine põhjustada kohtuasju, suuri trahve ja kahjustada mainet.

1. Sügavkaitsestrateegia

Veebisaidi turvalisuse süvakaitsestrateegia võtab virnas kasutatavate tööriistade analüüsimisel arvesse kaitse sügavust ja ründepinna laiust. Selline lähenemine annab täpsema pildi tänapäeva veebisaidi turvaohtude maastikust.

Kuidas veebiprofessionaalid veebisaidi turvalisust näevad

Me ei saa unustada statistikat, mis muudab veebisaidi turvalisuse iga veebiettevõtte jaoks atraktiivseks teemaks, olenemata suurusest.
Pärast enam kui 1000 veebiprofessionaalide küsitluse vastuse analüüsimist saab teha mõned järeldused turbemaastiku kohta.

Miks saite häkitakse

2019. aastal oli veebis üle 1,94 miljardi veebisaidi. See pakub häkkeritele suure mänguväljaku. Sageli on eksiarvamus selle kohta, miks veebisaite häkitakse. Omanikud ja administraatorid usuvad sageli, et neid ei häkita, kuna nende saidid on väiksemad ja seetõttu häkkerite jaoks vähem atraktiivsed. Häkkerid võivad valida suuremaid saite, kui nad soovivad teavet varastada või saboteerida. Muudel eesmärkidel (mis on rohkem levinud) on iga väike sait väga väärtuslik.
Veebilehtede häkkimisel püütakse saavutada erinevaid eesmärke, kuid põhilisi:

2. Automaatsed rünnakud veebisaitidele

Kahjuks vähendab automatiseerimine üldkulusid, võimaldab massilist avalikustamist ja suurendab eduka kompromissi võimalusi – olenemata liikluse mahust või veebisaidi populaarsusest.
Tegelikult on automatiseerimine häkkimise maailmas kuningas. Automatiseeritud rünnakud hõlmavad sageli teadaolevate haavatavuste ärakasutamist suure hulga saitide mõjutamiseks, mõnikord isegi saidi omaniku teadmata.

Automaatsed rünnakud põhinevad võimalusel. Vastupidiselt levinud arvamusele on automatiseeritud rünnakud nende ulatuse ja hõlpsa juurdepääsu tõttu palju tavalisemad kui käsitsi valitud sihitud rünnakud. CMS-is töötab peaaegu 60% Internet.

CMS-i turvaprobleemid

Avatud lähtekoodiga sisuhaldussüsteemiga (CMS), nagu WordPress, Magento, Joomla või Drupal ja palju muud, on keskmisel veebisaidi omanikul lihtsam kiiresti võrku pääseda.
Kuigi need platvormid pakuvad sageli sagedasi turvavärskendusi, põhjustab kolmanda osapoole laiendatavate komponentide (nt pistikprogrammid või teemad) kasutamine turvaauke, mida saab hõlpsasti ära kasutada võimaluste rünnakuteks.

Infoturbe standard on - konfidentsiaalsus, terviklikkus ja kättesaadavus. Seda mudelit kasutatakse organisatsioonide turvalisuse poliitika väljatöötamiseks.

3. Konfidentsiaalsus, terviklikkus ja kättesaadavus

Nüüd, kui meil on teadmised automatiseeritud ja sihitud rünnakute kohta, saame sukelduda mõnda levinumatesse veebisaidi turvaohtudesse.

Veebisaidi haavatavused ja ohud

Siin on kõige levinumad veebisaidi turvanõrkused ja ohud.

1. SQL-i süstimine - Sellised SQL-i süstimise rünnakud viiakse läbi pahatahtliku koodi sisestamisega haavatavasse SQL-päringusse. Nad tuginevad sellele, et ründaja lisab spetsiaalselt koostatud päringu sõnumile, mille veebisait saadab andmebaasi.
Edukas rünnak muudab andmebaasi päringut nii, et see tagastab teabe, mida ründaja soovib, selle asemel, mida veebisait ootab. SQL-i süstid võivad isegi muuta või lisada andmebaasi pahatahtlikku teavet.
2. Saididevaheline skriptimine (XSS) Saidiülesed skriptirünnakud seisnevad pahatahtlike kliendipoolsete skriptide sisestamises veebisaidile ja veebisaidi kasutamises levitamismeetodina. XSS-i oht seisneb selles, et see võimaldab ründajal sisestada veebisaidile sisu ja muuta selle kuvamisviisi, pannes ohvri brauseri käivitama lehe laadimisel ründaja antud koodi. Kui sisselogitud saidi administraator laadib koodi üles, käivitatakse skript tema privileegide tasemel, mis võib viia saidi ülevõtmiseni.
3. Brute Force mandaadirünnakud Juurdepääs veebisaidi administraatoripaneelile, juhtpaneelile või isegi SFTP-serverile on üks levinumaid vektoreid, mida veebisaitide kahjustamiseks kasutatakse. Protsess on väga lihtne:

4. Veebisaidi pahavara nakatumine ja rünnakud Kasutades mõnda eelmist turvaprobleemi veebisaidile volitamata juurdepääsu saamiseks, saavad ründajad:
5. DoS/DDoS rünnakud Hajutatud teenuse keelamise (DDoS) rünnak on mittetungiv Interneti-rünnak. Seda tehakse sihtveebisaidi keelamiseks või aeglustamiseks, ujutades võrgu, serveri või rakenduse võltsliiklusega üle.

E-kaubanduse veebisaidi turvalisus ja PCI vastavus

Maksekaarditööstuse andmeturbe standardid (PCI-DSS) määratleda nõuded veebipoodide veebisaitide omanikele. Need nõuded aitavad tagada, et kaardiomaniku andmed, mida veebipoena kogute, on piisavalt kaitstud. PCI DSS-i all viitavad kaitsmisele kuuluvad kaardiomaniku andmed täielikule esmasele kontonumbrile (PAN), kuid need võivad ilmuda ka ühel järgmistest vormidest:

PCI vastavuseeskirjad kehtivad siis, kui edastate andmeid digitaalselt, kirjalikult või suhtlete teise isikuga, kellel on andmetele juurdepääs.

E-kaubanduse veebisaitidel on väga oluline teha kõik endast oleneva, et kaardiomanike andmed edastataks brauserist veebiserverisse korraliku krüptimisega HTTPS-i kaudu. Samuti tuleb see turvaliselt ja sarnaselt krüpteeritult serverisse salvestada, kui see edastatakse mis tahes kolmanda osapoole maksete töötlemise teenustele.

Häkkerid võivad proovida kaardiomanike andmeid varastada või pealt kuulata igal ajal, olenemata sellest, kas andmed on puhkeolekus või edastamisel.

Veebisaidi turvaraamistik

Sõltumata teie ettevõtte suurusest võib turvasüsteemi väljatöötamine aidata teie üldist riski vähendada. Mõistmine, et turvalisus on pidev protsess, tähendab, et see algab veebisaidi turvalisuse aluse loomisest. See struktuur hõlmab "ohutuskultuuri" loomist, kus plaanilised kontrollid aitavad hoida asjad lihtsad ja õigeaegsed.
Viit funktsiooni: "Identifitseeri", "Kaitse", "Tuvasta", "Reageeri" ja "Taasta" kirjeldatakse üksikasjalikult koos rakendatavate toimingutega.
1. Et tuvastada - selles etapis dokumenteeritakse ja kontrollitakse kogu laoseisu ja varahaldust. Laovarude ja varade haldamist saab astuda sammu võrra edasi järgmistes alamkategooriates:

Kui olete oma veebisaidi varade loendi koostanud, saate neid kõiki auditeerida ja rünnakute eest kaitsta.
2. Kaitsta On palju põhjuseid, miks ennetavate veebiturvameetmete rakendamine on ülioluline, kuid millest alustada? Neid nimetatakse turvatehnoloogiateks ja turbetasemeteks. Mõnikord vastavad need meetmed vastavusnõuetele (nt PCI-le) või hõlbustavad rünnete suhtes haavatavate keskkondade virtuaalset parandamist ja tugevdamist. Turvalisus võib hõlmata ka töötajate koolitust ja juurdepääsu kontrollimise eeskirju.
3. Tuvasta (pidev jälgimine) on kontseptsioon, mis viitab teie veebisaidi (varade) jälgimise ja probleemidest teavitamise tööriistade rakendamisele. Turvaoleku kontrollimiseks tuleks installida seire:
Võite kasutada ka turvaskannereid ja tööriistu (nt SiteCheck), et otsida ohu või haavatavuse näitajaid.
4. Reageerima — analüüs ja leevendamine aitavad luua vastusekategooria. Juhtumi korral peaks olema reageerimisplaan. Reageerimisplaani koostamine enne kompromissijuhtumit teeb psüühika jaoks imet. Õige intsidentidele reageerimise plaan sisaldab järgmist:
Paigutamise käigus ei tea me kunagi ette, millist pahavara me leiame. Mõned probleemid võivad kiiresti levida ja nakatada teisi veebisaite jagatud serverikeskkonnas (ristinfektsioon). Juhtumitele reageerimise protsess, nagu NIST on määratlenud, jaguneb neljaks peamiseks etapiks:
Tugev ettevalmistusetapp ja veebisaidi turvameeskond, kellele võite usaldada, on missiooni õnnestumise jaoks üliolulised. See peaks välja nägema järgmine:

Ettevalmistus ja planeerimine

Selles etapis veendume, et meil on kõik vajalikud tööriistad ja ressursid enne intsidendi toimumist. Kõik see käib käsikäes turvaraamistiku eelmiste osadega.
Majutusettevõtted mängivad selles etapis otsustavat rolli, tagades, et süsteemid, serverid ja võrgud on piisavalt turvalised. Samuti on oluline veenduda, et teie veebiarendaja või tehniline meeskond on valmis turvaintsidendiga toime tulema.

Avastamine ja analüüs

Kuigi ründemeetodeid on mitu, peame olema valmis iga juhtumiga tegelema. Enamik nakkusi on veebisaidile installitud haavatavad komponendid (peamiselt pistikprogrammid), paroolide kompromissid (nõrk parool, toores jõud) ja muud.
Sõltuvalt probleemist ja kavatsusest võib avastamise etapp olla keeruline. Mõned ründajad otsivad kuulsust, teised võivad soovida ressursse ära kasutada või tundlikku teavet pealt kuulata.
Mõnel juhul ei viita miski sellele, et installitud on tagauks, mis ootab, kuni ründaja sellele pahatahtliku tegevuse tõttu juurde pääseb. Seetõttu on väga soovitatav rakendada mehhanisme, mis tagavad teie failisüsteemi terviklikkuse.

Piiramine, likvideerimine ja taastamine

Piiramise, kõrvaldamise ja taastamise faasi osas peaks protsess kohanduma veebisaidil leitud probleemi tüübi ja eelnevalt määratletud rünnakupõhiste strateegiatega. Näiteks krüptomeeri infektsioon kulutab tavaliselt palju serveri (leecheri) ressursse ja intsidendile reageerimise meeskond peab enne parandusprotsessi alustamist ohu kõrvaldama.

Selle rünnaku ohjeldamine on oluline samm ressursside täiendava ammendumise ja edasise kahju ärahoidmiseks. See otsustussüsteem ja strateegiad on selle etapi oluline osa. Näiteks kui tuvastame konkreetse faili 100% pahatahtlikuna, tuleks see hävitada. Kui fail sisaldab osaliselt pahatahtlikku koodi, tuleks eemaldada ainult see osa. Igal skriptil peab olema määratletud protsess.

Tegevused pärast intsidenti

Viimaseks, kuid mitte vähemtähtsaks, võib intsidendijärgset tegevust nimetada ka õppetundide etapiks. Siinkohal peaks intsidentidele reageerimise meeskond esitama aruande, milles kirjeldatakse üksikasjalikult, mis juhtus, milliseid meetmeid võeti ja kui hästi sekkumine toimis. Peame juhtunu üle järele mõtlema, sellest õppima ja tegutsema, et sarnaseid probleeme tulevikus ära hoida. Need toimingud võivad olla sama lihtsad nagu komponendi värskendamine, paroolide muutmine või veebisaidi tulemüüri lisamine, et vältida rünnakuid serval.

Vaadake üle toimingud, mida teie osakond peab turvalisuse edasiseks tugevdamiseks tegema. Seejärel tehke need toimingud nii kiiresti kui võimalik. Kõik edasised toimingud saate teha järgmiste näpunäidete põhjal.

Samuti, kui kasutate aktiivselt veebirakenduse tulemüüri (WAF), vaadake üle oma olemasolev konfiguratsioon, et teha kindlaks muudatused, mida on vaja teha. Pidage meeles, et kuigi WAF-id aitavad täita mitmeid maksekaarditööstuse andmeturbestandardeid (PCI DSS), ei ole need imerohi. On ka teisi tegureid, mis võivad teie ettevõtet mõjutada, eriti inimfaktor.
5. taastuda — taastamise planeerimine toimub siis, kui intsidendi korral analüüsitakse kõiki etappe. Taastamine on seotud ka varuplaani olemasoluga olukordadeks, kus kõik eelnevad sammud ebaõnnestusid, näiteks lunavararünnakud.

See protsess peaks hõlmama ka aja kokkuleppimist, et rääkida oma turvamüüjaga nõrkade kohtade parandamise kohta. Nad on paremini varustatud, et anda ülevaade sellest, mida saab teha.

Omage suhtlusstrateegiat

Kui andmed on ohus, andke sellest oma klientidele teada. See on eriti oluline, kui tegelete äritegevusega ELis, kus organisatsioon peab andmekaitse üldmääruse (GDPR) artikli 33 kohaselt teavitama andmete rikkumisest 72 tunni jooksul.

Kasutage automaatset varundamist

Ükskõik, mida teete oma veebisaidi kaitsmiseks, ei ole risk kunagi null. Kui teie veebisaidi funktsionaalsus on kahjustatud, vajate võimalust andmete kiireks taastamiseks – mitte ühte, vaid vähemalt kahte. Äärmiselt oluline on kogu rakenduse lokaalne varukoopia olemasolu ja riistvararikke või rünnaku korral väline varukoopia, mis pole rakendusega otseselt seotud.

Kuidas oma saiti kaitsta ja turvalisus tagada?

Veebisaidi turvalisuse tähtsust ei saa alahinnata. Selles jaotises vaatleme, kuidas oma veebisaiti turvalisena ja kaitstuna hoida. See ei ole samm-sammuline juhend, kuid see annab teile veebisaidi turvalisuse soovitusi, et leida teie vajadustele vastavad teenused.
1. Värskendage kõike - Vananenud ja ebaturvalise tarkvara tõttu on iga päev ohus lugematu arv veebisaite. Oluline on värskendada oma saiti niipea, kui CMS-i uus pistikprogramm või versioon on saadaval. Need värskendused võivad sisaldada lihtsalt turvatäiustusi või parandada turvaauke.
Enamik veebisaitidele suunatud rünnakuid on automatiseeritud. Botid roomavad pidevalt igal saidil, et kasutada võimalusi. Enam ei piisa kord kuus või isegi nädalas värskendamisest, sest suure tõenäosusega leiavad robotid haavatavuse enne, kui selle parandate.
Seetõttu peaksite kasutama veebisaidi tulemüüri, mis sulgeb turvaaugu praktiliselt kohe, kui värskendused ilmuvad. Kui teil on WordPressi veebisait, peaksite arvestama ühe pistikprogrammiga WP Updates Notifier. See saadab teile meili, et teavitada teid, kui pistikprogramm või WordPressi põhivärskendus on saadaval.
2. Kasutage tugevaid paroole Turvalise veebisaidi olemasolu sõltub paljuski teie turvalisusest. Kas olete kunagi mõelnud, kuidas teie kasutatavad paroolid võivad teie saidi turvalisust ohustada?
Nakatunud veebisaitide puhastamiseks peavad parandajad logima sisse kliendi saidile või serverisse, kasutades oma administraatori kasutaja mandaate. Nad võivad olla üllatunud, nähes, kui ebaturvalised võivad juurparoolid olla. Sisselogimisandmetega nagu admin/admin ei pruugi teil parooli üldse olla.
Häkkerid ühendavad võrgu andmed sõnastiku sõnaloenditega, et luua veelgi suuremaid potentsiaalsete paroolide loendeid. Kui teie kasutatavad paroolid on ühes neist loenditest, on vaid aja küsimus, millal teie sait rikutakse.

Tugevad paroolisoovitused

Soovitused tugeva parooli loomiseks:

• Ärge kasutage paroole uuesti: iga teie parool peab olema kordumatu. Paroolihaldur võib selle ülesande lihtsamaks teha.
• Kasutage pikki paroole. Proovige kasutada rohkem kui 12 tähemärki. Mida pikem on parool, seda kauem kulub arvutiprogrammil selle lahtimurdmiseks.
• Kasutage juhuslikke paroole. Paroolimurdmise programmid suudavad minutitega ära arvata miljoneid paroole, kui need sisaldavad Internetist või sõnaraamatutest leitud sõnu. Kui teie parool sisaldab tõelisi sõnu, pole see juhuslik. Kui saate oma parooli kergesti hääldada, tähendab see, et see pole piisavalt tugev. Isegi märkide asendamisest (st O-tähe asendamisest numbriga 0) ei piisa. On mitmeid kasulikke paroolihaldureid, nagu LastPass (võrgus) ja KeePass 2 (võrguühenduseta). Need tööriistad salvestavad kõik teie paroolid krüptitud vormingus ja saavad lihtsalt ühe nupuvajutusega luua juhuslikke paroole. Paroolihaldurid võimaldavad teil kasutada tugevaid paroole, ilma et peaksite nõrgemaid paroole meeles pidama või üles kirjutama.

3. Üks sait = üks salvestusruum Paljude veebisaitide majutamine ühes serveris võib tunduda ideaalne, eriti kui teil on "piiramatu" veebimajutusplaan. Kahjuks on see üks halvimaid turvatavasid, mida saate kasutada. Mitme saidi ühte asukohta paigutamine loob väga suure rünnakupinna. Peaksite teadma, et ristsaastumine on väga levinud. See on siis, kui saiti mõjutavad negatiivselt sama serveri naabersaidid serveri halva isolatsiooni või konto konfiguratsiooni tõttu.
Näiteks ühte saiti majutavas serveris võib olla üks WordPressi installimine teema ja 10 pistikprogrammiga, mis võivad olla ründaja sihtmärgiks. Kui majutate ühes serveris viit saiti, võib ründajal olla kolm WordPressi installi, kaks Joomla installi, viis teemat ja 50 pistikprogrammi, mis võivad olla potentsiaalsed sihtmärgid. Veelgi hullem, kui ründaja on leidnud ühelt saidilt ärakasutamise, võib nakkus kergesti levida sama serveri teistele saitidele.

See võib mitte ainult põhjustada kõigi teie saitide üheaegse häkkimise, vaid muudab puhastamise ka palju aeganõudvamaks ja keerulisemaks. Nakatunud saidid võivad üksteist uuesti nakatada, põhjustades lõputu ahela.

Kui puhastamine oli edukas, on teil nüüd paroolide lähtestamine palju keerulisem. Ühe saidi asemel on teil mitu. Iga serveri iga veebisaidiga seotud parool tuleb pärast nakatumise kadumist muuta. See hõlmab kõiki teie CMS-i andmebaase ja kõigi nende veebisaitide failiedastusprotokolli (FTP) kasutajaid. Kui jätate selle sammu vahele, võivad kõik veebisaidid uuesti nakatuda ja peate protsessi taaskäivitama.
4. Kasutajate juurdepääsu ja lubade piiramine Teie veebisaidi kood ei pruugi olla ründaja sihtmärk, kuid teie kasutajad küll. IP-aadresside ja kogu tegevusajaloo salvestamine on hilisemaks kohtuekspertiisi analüüsiks kasulik.
Näiteks võib registreeritud kasutajate arvu märkimisväärne kasv viidata registreerimisprotsessi ebaõnnestumisele ja lubada rämpspostitajatel teie saidi võltsitud sisuga üle ujutada.

Väiksemate privileegide põhimõte

Väiksemate privileegide põhimõte põhineb põhimõttel, mille eesmärk on saavutada kaks eesmärki:

Teatud rollidele õiguste andmine määrab, mida nad saavad teha ja mida mitte. Ideaalses süsteemis takistaks roll kellelgi katset sooritada toimingut väljaspool seda, mida see oli ette nähtud.
Oletame näiteks, et administraator saab manustada postitustesse filtreerimata HTML-i või käivitada pistikprogrammide installimiseks käske. Kas see on haavatavus? Ei, see on funktsioon, mis põhineb ühel väga olulisel elemendil – usaldusel. Kuid kas autoril peaksid olema samad õigused ja juurdepääs? Kaaluge rollide eraldamist usalduse alusel ja lukustage kõik kontod.
See kehtib ainult saitide kohta, millel on mitu kasutajat või sisselogimist. On oluline, et igal kasutajal oleks oma töö tegemiseks vajalikud õigused. Kui vajate praegu laiendatud õigusi, andke need. Seejärel vähendage seda, kui töö on tehtud.

Näiteks kui keegi soovib teile külalisblogi postitust kirjutada, veenduge, et tema kontol poleks täielikke administraatoriõigusi. Konto peaks saama luua ainult uusi postitusi ja redigeerida oma postitusi, sest nad ei pea veebisaidi seadeid muutma. Hoolikalt määratletud kasutajarollid ja juurdepääsureeglid piiravad võimalikke vigu. Samuti vähendab see ohtu sattunud kontode arvu ja võib kaitsta petturlike kasutajate tekitatud kahju eest.
See on kasutajahalduse sageli tähelepanuta jäetud osa: vastutus ja jälgimine. Kui mitu inimest kasutavad sama kasutajakontot ja see kasutaja teeb soovimatuid muudatusi, siis kuidas teate, kes teie meeskonnast vastutab?
Kui teil on iga kasutaja jaoks eraldi konto, saate jälgida nende käitumist, vaadates logisid ja teades nende tavalisi trende, näiteks seda, millal ja kus nad tavaliselt veebisaiti külastavad. Seega, kui kasutaja logib sisse veidral ajal või kahtlasest asukohast, saate seda uurida. Auditilogide pidamine on teie veebisaidi kahtlaste muudatuste jälgimiseks ülioluline.

Muidugi võib käsitsi auditi logimine olla mõne kasutaja jaoks keeruline. Kui teil on WordPressi veebisait, saate kasutada tasuta Sucuri turbepluginat, mille saab alla laadida ametlikust WordPressi hoidlast.

Faili õigused

Failiõigused määravad, kes mida failiga teha saab. Igal failil on kolm saadaolevat õigust ja iga õigust tähistab number:

Kui soovite lubada mitut õigust, lisage lihtsalt numbrid kokku, näiteks lugemise (4) ja kirjutamise (2) lubamiseks määrate kasutaja loa väärtuseks 6. Kui soovite lubada kasutajal lugeda (4), kirjutage (2) ja tehke (1), seejärel määrake kasutajaõiguseks 7.

Kasutajatüübid

Samuti on kolme tüüpi kasutajaid:

Seega, kui soovite, et omanikul oleks lugemis- ja kirjutamisõigus, grupil kirjutuskaitstud juurdepääs ja üldsusel poleks juurdepääsu, peaksid faililoa seaded olema järgmised:
5. Muutke CMS-i vaikeseadeid Kaasaegsed CMS-i rakendused (kuigi neid on lihtne kasutada) võivad lõppkasutajatele turvalisuse osas väljakutseid pakkuda. Kõige tavalisemad rünnakud veebisaitidele on täielikult automatiseeritud. Paljud neist rünnakutest põhinevad kasutajatel, kellel on ainult vaikeseaded. See tähendab, et saate vältida paljusid rünnakuid, kui muudate oma valitud CMS-i installimisel lihtsalt vaikesätteid.
Näiteks on mõned CMS-i rakendused kasutaja poolt kirjutatavad, mis võimaldab kasutajal installida soovitud laiendusi.
Kommentaare, kasutajaid ja kasutajateabe nähtavust saate reguleerida seadistustega. Failiõigused on veel üks näide vaikesätetest, mida saab täiustada.
Saate neid vaikeseadeid muuta CMS-i või uuema installimisel, kuid ärge unustage seda teha.
6. Laienduse valik (pluginad) Veebihalduritele meeldib tavaliselt CMS-i rakenduste laiendatavus, kuid see võib olla ka üks suurimaid puudusi. Seal on pistikprogramme, lisandmooduleid ja laiendusi, mis pakuvad peaaegu kõiki funktsioone, mida võite ette kujutada. Aga kuidas sa tead, milline neist on ohutu paigaldada?

Ohutute laienduste (pluginate) valimine - saidi peamine turvalisus

Laiendite valimisel tuleb silmas pidada järgmist.

7. Tehke oma veebisaitide varukoopiad – Häkkimise korral on veebisaidi varukoopiad teie veebisaidi taastamiseks suurest turvarikkumisest kriitilise tähtsusega. Kuigi seda ei tohiks pidada veebisaidi turvalahenduse asendajaks, võib varukoopia aidata rikutud faile taastada.

Parima veebisaidi varunduslahenduse valimine

Hea varulahendus peaks vastama järgmistele nõuetele:
— Esiteks peavad nad olema väljaspool asukohta. Kui teie varukoopiad on salvestatud teie veebisaidi serverisse, on need rünnakute suhtes sama haavatavad kui miski muu. Peaksite oma varukoopiaid salvestama väljaspool saiti, kuna soovite, et teie varundatud andmed oleksid häkkerite ja riistvaratõrgete eest kaitstud. Varukoopiate salvestamine veebiserverisse on samuti suur turvarisk. Need varukoopiad sisaldavad alati teie CMS-i ja laienduste parandamata versioone, mis annab häkkeritele hõlpsa juurdepääsu teie serverile.
- Teiseks peaks teie varukoopiad olema automaatsed. Teete iga päev nii palju asju, et veebisaidi varundamine võib olla mõeldamatu. Kasutage varulahendust, mida saab ajastada vastavalt teie veebisaidi vajadustele.
Lõpetuseks looge usaldusväärne taastumine. See tähendab oma varukoopiate varukoopiate tegemist ja nende testimist, et veenduda nende tegelikus töös. Koondamise jaoks vajate mitut varukoopiat. Seda tehes saate taastada faile enne häkkimist.
8. Serveri konfiguratsioonifailid – kontrollige oma veebiserveri konfiguratsioonifaile: Apache veebiserverid kasutavad .htaccess-faili, Nginxi serverid kasutavad faili nginx.conf, Microsoft IIS-i serverid kasutavad faili web.config.
Serveri konfiguratsioonifailid, mis asuvad enamasti veebi juurkataloogis, on väga võimsad. Need võimaldavad teil jõustada serverireegleid, sealhulgas direktiive, mis suurendavad teie saidi turvalisust. Kui te pole kindel, millist veebiserverit kasutate, käivitage oma veebisait Sitechecki kaudu ja minge vahekaardile „Veebisaidi üksikasjad”.

Saidi turvalisus – veebiserveri parimad tavad

Siin on mõned juhised, mida saate konkreetse veebiserveri jaoks lisada.

• Keelake juurdepääs kataloogidele: see takistab ründajatel veebisaidi iga kataloogi sisu vaadata. Ründajatele kättesaadava teabe piiramine on alati kasulik turvameede.
• Kujutiste kiirlinkide ennetamine: kuigi see ei ole rangelt turvatäiustus, takistab see teistel veebisaitidel teie veebiserveris hostitud pilte kuvamast. Kui inimesed hakkavad teie serverist pilte viima linkima, saab teie hostimisplaani lubatud ribalaiust kiiresti kasutada kellegi teise saidi piltide kuvamiseks.
• Konfidentsiaalne failikaitse: saate määrata reeglid teatud failide ja kaustade kaitsmiseks. CMS-i konfiguratsioonifailid on ühed olulisemad veebiserverisse salvestatud failid, kuna need sisaldavad lihttekstina andmebaasi sisselogimisteavet. Teised kohad, näiteks haldusalad, võivad olla blokeeritud. Samuti saate piirata PHP täitmist pilte sisaldavate või üleslaadimist lubavate kataloogidega.

9. Installige SSL-sertifikaat — SSL-sertifikaadid kasutatakse hosti (veebiserveri või tulemüüri) ja kliendi (veebibrauseri) vahel edastatavate andmete krüptimiseks. See aitab tagada, et teie teave saadetakse õigesse serverisse ja seda ei peatata.
Teatud tüüpi SSL-sertifikaadid, nagu organisatsiooni SSL-sertifikaat või laiendatud valideerimisega SSL-sertifikaat, lisavad täiendava usalduskihi, kuna külastaja näeb teie organisatsiooni üksikasju ja teab, et olete seaduslik isik.
Veebisaitide turvaettevõttena peame veebihaldureid koolitama ja teadvustama, et SSL-sertifikaadid ei kaitse veebisaite rünnakute ja häkkimiste eest. SSL-sertifikaadid krüpteerivad edastatavaid andmeid, kuid ei lisa veebisaidile turvakihti.
10. Installige skannimis- ja jälgimistööriistad - kontrollige iga sammu, et tagada rakenduse terviklikkus. Hoiatusmehhanismid võivad vähendada reageerimisaega ja vähendada kahjusid rikkumise korral. Kuidas saate ilma kontrollideta teada, kas teie saiti on ohustatud?
Vähemalt kuuajalised logid võivad olla rakenduste krahhide tuvastamisel väga kasulikud. Samuti näitavad need, kas server on DDoS-i rünnaku all või on see ebavajaliku koormuse all. Salvestage ja vaadake regulaarselt üle kõik tegevused, mis toimuvad rakenduse kriitilistes osades, eriti (kuid mitte ainult) haldusalades. Ründaja võib hiljem proovida kasutada saidi vähem olulist osa kõrgema juurdepääsutaseme saavutamiseks.
Looge kindlasti päästikud, mis teavitavad teid jõhkra jõu rünnakust või saidi mis tahes funktsiooni kasutamise katsest, sealhulgas need, mis ei ole seotud autentimissüsteemidega. Tähtis on regulaarselt värskendusi kontrollida ja neid rakendada, et veenduda, kas teil on installitud uusimad turvapaigad. See kehtib eriti siis, kui te ei luba veebirakenduse tulemüüril haavatavuse ärakasutamise katseid blokeerida.
11. Järgige isiklikke ohutusjuhiseid - personaalarvuti kaitsmine on veebisaitide omanike jaoks oluline ülesanne. Teie seadmed võivad muutuda nakkusvektoriks ja viia teie saidi häkkimiseni.
Hea veebisaidi turvajuhend mainib teie arvuti kontrollimist pahavara suhtes, kui teie veebisaiti on häkitud. On teada, et pahavara imbub nakatunud kasutaja arvutist tekstiredaktorite ja FTP-klientide kaudu.
Peate arvutist eemaldama kõik kasutamata programmid. See samm on oluline, kuna nendel programmidel võib olla ka privaatsusprobleeme, nagu ka teie veebisaidi kasutamata pistikprogrammide ja teemade puhul.
Kui midagi pole installitud, ei saa see muutuda teie arvuti, eriti brauseri laienduse, nakatamiseks rünnakuvektoriks. Neil on täielik juurdepääs veebisaitidele, kui veebihaldurid on oma administraatoriliidesesse sisse logitud. Mida vähem olete oma arvutisse installinud, seda parem.
Kui te pole kindla rakenduse eesmärgis kindel, uurige veebis veidi, kas see on vajalik või mida saate eemaldada. Kui te ei kavatse seda kasutada, eemaldage see.
12. Kasutage veebisaidi tulemüüri - Ainult SSL-sertifikaatide kasutamisest ei piisa, et takistada ründaja juurdepääsu konfidentsiaalsele teabele. Teie veebirakenduse haavatavus võib lubada ründajal liiklust pealt kuulata, külastajaid võltsitud veebisaitidele saata, valeteavet kuvada, veebisaiti pantvangis hoida (lunavara) või kõik selle andmed kustutada.
Isegi täielikult paigatud rakenduse korral võib ründaja rünnata teie serverit või võrku, kasutades veebisaidi aeglustamiseks või keelamiseks DDoS-i rünnakuid. Veebirakenduste tulemüür (WAF) on loodud selliste rünnakute ärahoidmiseks veebisaitide vastu ja võimaldab teil keskenduda oma ettevõttele.

Lisameetmed ilma veebisaidita

Oma veebisaitide kaitsmiseks ja Interneti turvalisemaks muutmiseks kasutage neid tasuta ressursse ja tööriistu.
1. Veebisaidi kaitsetööriistad - Siin on mõned tasuta veebisaidi turvatööriistad:

1.1 SiteCheck on tasuta saidivaba kontrolli ja pahavara skanner.
1.2 Sucuri laadimisaja tester – kontrollige ja võrrelge veebisaidi kiirust.
1.3 Sucuri WordPressi turbeplugin – WordPressi veebisaitide audit, pahavara skanner ja turvalisuse tugevdamine.
1.4 Google Search Console – turvahoiatused ja tööriistad otsinguliikluse ja veebisaidi toimivuse mõõtmiseks.
1.5 Bing Webmaster Tools – otsingumootori diagnostika ja turbearuandlus.
1.6 Yandex Webmaster – veebiotsingu ja turvarikkumiste teatised.
1.6 Demaskparasites – lehtede kontrollimine varjatud ebaseadusliku sisu suhtes.
1.7 Parim WAF – pilveveebirakenduste parimate tulemüüride võrdlus.

2. Lisaressursid Siin on mõned veebisaidi turvalisuse õppematerjalid:

2.2 Sucuri Labs – ohtude uurimine, pahavara allkirjade andmebaas ja statistika.
2.3 OWASP on avatud lähtekoodiga veebirakenduste turbeprojekt.
2.4 PCI vastavuse kontrollnimekiri – PCI vastavuse kontrollnimekiri.
2.5 SANS Institute - infoturbealane koolitus, sertifitseerimine ja teadusuuringud.
2.6 NIST – Riiklik Standardi- ja Tehnoloogiainstituut.

Korduma kippuvad küsimused veebisaidi turvalisuse kohta

Miks on veebisaidi turvalisus oluline?

Veebisaidi turvalisus on veebisaidi võrgus ja külastajate jaoks turvalisena hoidmiseks ülioluline. Kui veebisaidi turvalisusele ei pöörata piisavalt tähelepanu, saavad häkkerid teie veebisaiti ära kasutada, selle keelata ja teie veebis kohalolekut mõjutada. Veebisaidi häkkimise tagajärjed võivad hõlmata rahalist kahju, kaubamärgi mainega seotud probleeme ja otsingumootorite madalat asetust.

Millised on veebisaidi turvariskid?

Peamised veebisaidi turvariskid on järgmised: haavatav kood, halb juurdepääsukontroll ja serveriressursside kasutamine. Näiteks võivad DDoS-i rünnakud muuta saidi külastajatele mõne minutiga ligipääsmatuks. Põhjuseid, miks veebisaite häkitakse, on palju; nõrk parool või aegunud pistikprogramm võib viia saidi häkkimiseni.

Mis teeb saidi turvaliseks?

Rünnakute ja häkkimiste vältimiseks aktiveeritakse turvalisel veebisaidil veebirakenduse tulemüür. See järgib ka veebisaidi turvalisuse parimaid tavasid ning sellel pole konfiguratsiooniprobleeme ega teadaolevaid haavatavusi. Saate kasutada SiteChecki, et näha, kas veebisaidil on tulemüür, mis tahes turbeanomaaliaid, pahavara või see on mustas nimekirjas. SiteCheck, et näha, kas veebisaidil on tulemüür, mis tahes turbeanomaaliaid, pahavara või see on mustas nimekirjas.

Kas ma vajan oma saidi turvalisust?

Jah muidugi. Veebisaidi turvalisus ei sisaldu enamikus veebimajutuspakettides. Veebisaidi turvalisuse eest vastutab veebisaidi omanik. Turvalisus peaks olema veebisaidi loomisel ja käimasoleval kinnitusprotsessil üks esimesi kaalutlusi. Kui veebisait pole turvaline, võib see saada küberkurjategijate jaoks lihtsaks saagiks.

Kuidas muuta oma sait turvaliseks?

Saate oma veebisaiti kaitsta, järgides veebisaidi turvalisuse parimaid tavasid, näiteks:

• Kasutage veebisaidi tulemüüri.
• Kasutage alati saidi CMS-i, pistikprogrammide, teemade ja kolmandate osapoolte teenuste uusimat versiooni.
• Hoidke ja kasutage tugevaid paroole.
• Andke ainult seda tüüpi juurdepääs, mida keegi vajab ülesande täitmiseks.
• Installige oma saidi terviklikkuse tagamiseks skannimis- ja jälgimistööriistad.
• Installige andmete krüptimiseks SSL-sertifikaadid.
• Hoidke veebisaitide varukoopiaid.

Täname, et lugesite Nicola Topi