Said virtuaalserverit ja muretsed turvalisuse pärast? Siit saate teada, mida peate teadma

Reklaam

Jagatud hostimine. See on odav variant, kas pole? Ja elanikkonna tohutu hulga jaoks on kõik, mida nad kunagi oma veebisaidi või veebirakenduse hostimiseks vajavad. Ja kui seda hästi teha, on jagatud hostimine skaleeritav, kiire ja turvaline.

Mis saab aga siis, kui sellega pole hästi hakkama saanud?

Noh, siis hakkavad ohtlikud turvaprobleemid sisse hiilima. See on siis, kui teie saiti ähvardab rikkuda oht või kui teie privaatsed andmed lekivad. Kuid ärge muretsege. Valdaval osal veebimajutajatest on korralikud turvameetmed. Teil tuleb olla ettevaatlik ainult lendu-öösel ja keldrikorrusel asuvate hostide korraldamisel.

Me soovitame InMotion Hosting jagatud hostimine koos SSD-mäluseadmega.

Uurime jagatud hostimisega seotud turvaprobleeme. Kuid kõigepealt räägime sellest, mis muudab jagatud hostimisplatvormi turvaliseks.

Mis teeb turvalise veebi

Turvalisuse kaalutlustel, mida tuleks jagada jagatud hostimise osas, on mõned.

• Kõik serveri kasutajad peaksid olema teistest kasutajatest isoleeritud ja neil ei tohiks olla juurdepääsu teiste kasutajate failidele ega neid muuta.
instagram viewer
• Serveris hostitava veebisaidi loogika turvaauk ei tohiks teisi kasutajaid mõjutada.
• Arhitektuuriturbe probleemide lahendamiseks on server regulaarselt paigas, värskendatud ja jälgitav.
• Igal kasutajal peaks olema oma isoleeritud juurdepääs andmebaasile ja tal ei tohiks olla lubatud muudetud salvestusdokumentides või teiste kasutajate tabelilubades muudatusi teha.

Enamik veebimajutajaid vastab jällegi neile ühiste pakkumiste nõuetele. Kuid kui soovite hostida mitut veebisaiti ühes serveris või on teil huvitav näha, kuidas teie hostiettevõte kokku kukub, või mõtlete isegi oma hostiettevõtte käivitamise üle ja otsite meelsasti, kuidas oma kasutajaid kaitsta, siis lugege palun läbi peal.

Kuid kõigepealt loobumine

Enne kui hakkame jagama virtuaalserveritega tasandatud ühiseid rünnakuid, tahan lihtsalt teatage, et see postitus ei ole (ja seda ei tohiks lugeda kui) potentsiaalse turvalisuse ammendav loetelu väljaanded.

Turvalisus on ühesõnaga suur. Saidi ohustamiseks on palju viise. See läheb jagatud hostimise korral kahekordseks. Nende ühe artikli katmine polnud kunagi kaartidel.

Kui olete oma turvalisuse osas paranoiline, hankige VPS või spetsiaalne server. Need on keskkonnad, kus teil on (enamasti) täielik kontroll selle üle, mis toimub. Kui te pole kindel erinevat tüüpi veebimajutuses, vaadake seda postitust Veebisaidi majutamise erinevad vormid on lahti seletatud [Technology Explained] Loe rohkem minu kolleegilt James Bruce'ilt.

Samuti peaksin rõhutama, et seda postitust ei tule tõlgendada rünnakuna jagatud hostimise vastu. Pigem on see puhtalt akadeemiline pilk selle kategooria veebimajutuse turbeprobleemidele.

Kataloogi läbimine

Alustame kataloogide läbimise rünnakutega (mida sageli nimetatakse "tee läbimiseks"). Selline rünnak võimaldab teil pääseda juurde failidele ja kataloogidele, mida hoitakse väljaspool veebijuurt.

Lihtsalt inglise keeles? Kujutagem siis ette, et Alice ja Bob kasutavad oma veebisaitide majutamiseks sama serverit. Alice'i failid on salvestatud kausta / var / www / alice, samas kui Bobi dokumendid on kataloogis / var / www / bob. Mõelgem veel, et serveris on veel üks kaust (/ usr / crappyhosting / myfolder) mis hoiab krüptimata tavalist tekstifaili (nimetame seda pwd.txt), mis sisaldab süsteemi kasutajanimesid ja paroolid.

Minuga siiani? Hea küll. Kujutagem nüüd ette, et Bobi veebisait pakub kohapeal loodud PDF-faile ja kohalikule failile viidatakse URL-is. Midagi sellist:

http://example.com/file?=report.pdf

Mis juhtuks, kui asendaksin raporti.pdf mõne UNIXi parameetriga, mis kataloogi muudavad?

http://example.com/file?=../alice/

Kui server on valesti konfigureeritud, võimaldaks see teil näha Alice'i dokumendi juuri. Huvitav, kuid meid huvitab see mahlane passitoimik palju rohkem. Accio paroolid!

http://example.com/file?=../../../usr/crappyhosting/myfolder/pwd.txt

See on tõesti nii lihtne. Aga kuidas sellega toime tulla? See on lihtne.

Kunagi kuulnud vähetuntud Linuxi utiliidist, mida nimetatakse chroot? Olete ilmselt juba aimanud, mida see teeb. See seab Linuxi / UNIX-i juuriks suvalise kausta, muutes kasutajatel sellest väljumise võimatuks. Tegelikult peatab see nende radadel kataloogide läbirünnakuid.

On raske öelda, kas teie hostil on see paigas ilma seadusi rikkumata. Lõppude lõpuks peaksite selle testimiseks pääsema juurde süsteemidele ja failidele, millele teil pole juurdepääsuõigust. Seda silmas pidades oleks ehk mõistlik rääkida oma veebiga ja küsida, kuidas nad isoleerivad oma kasutajad üksteisest.

Kas kasutate oma jagatud hostimise serverit ja ei kasuta oma kasutajate kaitsmiseks chroot? Tõsi, teie keskkondade sirvimine võib olla raske. Õnneks on seal palju pistikprogramme, mis selle lihtsaks teevad. Vaadake eriti mod_chroot.

Käskluse süstimine

Lähme tagasi Alice'i ja Bobi juurde. Niisiis, me teame, et Bobi veebirakendusel on vähe... Ahem... Turvaprobleeme. Üks neist on käsu süstimise haavatavus, mis võimaldab teil käivitada suvalised süsteemi käsud Linuxi käsuridaga tutvumise lühijuhendLinuxis saate käskudega teha palju hämmastavat asja ja seda pole tegelikult raske õppida. Loe rohkem .

Bobi veebisait võimaldab teil käivitada whois-päringu mõnel teisel veebisaidil, mis seejärel kuvatakse brauseris. Seal on tavaline HTML-i sisestuskast, mis aktsepteerib domeeninime ja käivitab seejärel whois-süsteemi käsu. See käsk käivitatakse, kutsudes süsteemi () käsu PHP.

Mis juhtuks, kui keegi sisestaks järgmise väärtuse?

näide.com &&cd ../alice/ &&rm index.html

Jagagem see ära. Mõni sellest võib teile tuttav olla, kui olete lugenud meie lehte „Alustamise juhend Linuxile” Alustamine Linuxist ja UbuntuTeid huvitab üleminek Linuxi peale... aga kust sa alustad? Kas teie arvuti ühildub? Kas teie lemmikrakendused töötavad? Siin on kõik, mida peate Linuxiga alustamiseks teadma. Loe rohkem e-raamat, mille me varem väljastasime 2010. aastal, või oleme meie pilgu heitnud Linuxi käsuridade petaja leht.

Esiteks käivitab see whois-päringu saidil example.com. Siis muudaks see praeguse töökataloogi Alice'i dokumendijuuriks. Siis eemaldaks see faili nimega index.html, mis on tema veebisaidi registrileht. See ei ole hea. Ei, härra.

Niisiis, kuidas süsteemihalduritena seda leevendada? Naastes eelmise näite juurde, saame alati panna iga kasutaja oma isoleeritud, desinfitseeritud ja hiirega keskkonda.

Saame sellele läheneda ka keeletasemelt. Funktsioonide deklaratsioone on võimalik keeltest globaalselt eemaldada (kuigi see võib asju rikkuda). See tähendab, et funktsioonid on võimalik eemaldada keeltest, millele kasutajatel on juurdepääs.

Vaadates eriti PHP-d, saate funktsioonid Runkitist eemaldada - PHP-i ametlik tööriistakomplekt keele funktsioonide muutmiseks. Seal on palju dokumente. Lugege seda.

Samuti saate muuta PHP konfiguratsioonifaili (php.ini) funktsioonide keelamiseks, mida häkkerid sageli kuritarvitavad. Selleks avage oma serveril terminal ja avage oma php.ini-fail tekstiredaktoris. Mulle meeldib kasutada VIM-i, kuid ka NANO on vastuvõetav.

Leidke rida, mis algab keelamisfunktsioonidega, ja lisage funktsioonide definitsioonid, mida soovite keelata. Sel juhul oleks see exec, shell_exec ja system, ehkki tasub märkida, et on ka teisi sisseehitatud funktsioone, mida häkkerid saavad kasutada.

invalid_functions = exec, shell_exec, süsteem

Keele- ja tõlgipõhised rünnakud

Vaatame siis PHP-d. See on keel, mis käivitab üllatava hulga veebisaite. Sellega kaasnevad ka mitmed eripärad ja veidrad käitumised. Nagu nii.

PHP-d kasutatakse tavaliselt koos Apache veebiserveriga. Enamasti on selle konfiguratsiooniga võimatu laadida mitu keele versiooni.

Miks see probleem on? Kujutagem siis ette, et Bobi veebirakendus loodi algselt 2002. aastal. See on juba ammu. Kui Michelle Branch veel edetabeli tippu jõudis, mängis Michael Jordan endiselt Washingtoni võlurite jaoks ja PHP oli palju teistsugune keel.

Kuid Bobi veebisait töötab endiselt! See kasutab tervet hunnikut lõpetatud ja aegunud PHP-funktsioone, kuid töötab! PHP moodsa versiooni kasutamine rikuks Bobi veebisaidi tõhusalt ja miks peaks Bob oma veebisaidi ümber kirjutama oma veebisaidi ümber kirjutama?

See peaks andma teile ettekujutuse dilemmast, millega mõned veebimajutajad silmitsi seisavad. Nad peavad tasakaalus hoidma arhitektuurselt usaldusväärse ja turvalise teenuse, hoides samal ajal kooskõlas sellega, et maksvad kliendid oleksid õnnelikud.

Seetõttu pole harvad juhud, kui väiksemad sõltumatud hostid kasutavad PHP (või mis tahes keeles) tõlgi vanemaid versioone.

Pole haruldane, kui näete, et väiksemad sõltumatud hostid kasutavad vanemaid PHP versioone, pannes kasutajad potentsiaalselt turvariskile.

Miks see halb on? Noh, esiteks paneks see kasutajad paljusid turvariske. Nagu enamikku suuremaid tarkvarapakette, uuendatakse ka PHP-d pidevalt, et lahendada pidevalt avastatavate (ja avalikustatud) turvaaukude arv.

Lisaks tähendab see, et kasutajad ei saa kasutada uusimaid (ja ka kõige paremaid) keelefunktsioone. See tähendab ka seda, et teatud põhjustel vananenud funktsioonid jäävad alles. Kui tegemist on: PHP programmeerimiskeel Õppige PHP-ga ehitama: krahhiradaPHP on keel, mida Facebook ja Vikipeedia kasutavad iga päev miljardite päringute teenindamiseks; inimeste veebiprogrammeerimise õpetamiseks kasutatav de facto keel. See on ilusti lihtne, kuid geniaalselt võimas. Loe rohkem , hõlmab see suhtlemiseks kasutatavaid naeruväärselt kohutavaid (ja hiljuti ka aegunud) mysql_-funktsioone MySQL relatsiooniandmebaasisüsteemiga ja dl (), mis võimaldab kasutajatel importida oma keelt pikendused.

Kasutajana peaksite saama näha, milline tõlgi versioon teie teenuses töötab. Kui see on aegunud või sisaldab mitmeid turvaauke, võtke ühendust oma hostiga.

Aga sysadminid? Siin on mõned võimalused. Esimene (ja paljulubavam) on kasutada Dockerit iga oma kasutaja jaoks. Docker võimaldab teil samaaegselt käitada mitut isoleeritud keskkonda, sarnaselt virtuaalse masinaga, ehkki ilma teise operatsioonisüsteemi käivitamata. Selle tulemusel on see kiire. Tõesti, väga kiiresti.

Lihtsalt inglise keeles? Enamiku oma kasutajate, samal ajal kui klientide jaoks saate kasutada uusimat ja parimat verre kes kasutavad vanu rakendusi, mis kasutavad iidseid vananenud tõlke, ilma et see kahjustaks teisi kasutajad.

Selle eeliseks on ka keeleagnostilisus. PHP, Python, Ruby. Mida iganes. See on kõik sama.

Ärge pidage õudusunenägusid.

Selle postituse eesmärk oli teha paar asja. Esiteks pidi see juhtima teie tähelepanu arvule turbeprobleemidele, millega veebimajutusettevõtted peavad oma klientide ja andmete turvalisuse tagamiseks silmitsi seisma.

Selle eesmärk oli ka näidata teile, kuidas samas serveris hostitavad saidid võivad üksteist mõjutada. Kas soovite sellesse mõlki panna? Hakake järgima häid, turvalisi kodeerimisstandardeid. Eriti alustage sisendite desinfitseerimist nii esi- kui ka tagaosas.

Hea algus on uue HTML5 vormi valideerimise funktsionaalsusega. Oleme sellest HTML5-juhendis varem rääkinud. Kollektiivselt saame veebisaite turvalisemaks muuta, kui oleme paremad, kohusetundlikumad programmeerijad.

Nagu alati, olen valmis teie mõtteid kuulama. Pange mulle allpool kommentaar.

Foto krediit: Häkkerit vajavad kõik (Alexandre Dulaunoy), Taksoakna kleebis (Cory Doctorow), Serveriruum (Torkild Retvedt), Linuxi raamatud ja ajakirjad (Library_mistress), PHP elevant (Markus Tacker)