Imate zajedničko gostovanje i brinete zbog sigurnosti? Evo što trebate znati

Zajedničko gostovanje. To je jeftina opcija, zar ne? A za ogromni dio stanovništva to je sve što će im ikada trebati da ugosti njihovu web stranicu ili web aplikaciju. I kada se to učini dobro, zajednički hosting je skalabilan, brz i siguran.

Ali što se događa kad nije dobro izvedeno?

Tada počinju propadati opasni sigurnosni problemi. Tada postoji opasnost da će Vaša web lokacija biti obustavljena ili će privatni podaci koje držite procuriti. Ali ne brini. Velika većina web domaćina ima pristojne sigurnosne mjere. Morate biti oprezni samo domaćini koji lete po noći, i to po podrumima.

Preporučujemo zajedničko gostovanje InMotion Hosting-a s SSD-om.

Istražit ćemo sigurnosna pitanja oko zajedničkog hostinga. Ali prvo, razgovarajmo o tome što sigurnost zajedničke platforme hostinga čini sigurnom.

Što čini sigurnim web domaćinom

Postoji nekoliko sigurnosnih razmatranja koja se trebaju postaviti u vezi s zajedničkim hostingom.

• Svaki korisnik na poslužitelju trebao bi biti izoliran od drugih korisnika i ne bi smio pristupiti ili mijenjati datoteke drugih korisnika.
• Sigurnosna ranjivost u logici web mjesta koje se nalazi na poslužitelju ne bi trebala utjecati na druge korisnike.
• Poslužitelj se redovito zakrpa, ažurira i nadzire radi rješavanja problema sigurnosti arhitekture.
• Svaki korisnik trebao bi imati vlastiti izolirani pristup bazi podataka i ne smije mu biti dopušteno mijenjati pohranjene zapise ili dopuštenja tablica drugih korisnika..

Opet, većina web-domaćina udovoljava tim zahtjevima za zajedničku ponudu. Ali ako gledate hostiranje više web lokacija na jednom poslužitelju ili želite znati kako se vaša hosting tvrtka sprema ili čak razmišljate o pokretanju vlastite hosting tvrtke i željeli ste razraditi kako osigurati svoje korisnike, pročitajte na.

Ali prvo, odricanje

Prije nego što se pozabavimo uobičajenim napadima izjednačenim na zajedničkom hostingu, želim samo reći da ovaj post neće biti (i ne bi ga trebalo čitati kao) iscrpan popis potencijalnih sigurnosnih pitanja.

Sigurnost je, jednom riječju, velika. Postoji puno načina na koje možete kompromitirati web mjesto. Ovo udvostručuje za zajedničko gostovanje. Pokrivanje istih u jednom članku nikada nije bilo na karticama.

Ako ste paranoični po pitanju svoje sigurnosti, nabavite VPS ili namjenski poslužitelj. Ovo su okruženja u kojima (uglavnom) imate apsolutnu kontrolu nad onim što se događa. Ako niste sigurni u razne vrste web hostinga, pogledajte ovaj post Objašnjeni različiti oblici hostinga web stranica [Objasnjena tehnologija] Različiti oblici hostinga web stranica [Objasnjena tehnologija] mog kolege Jamesa Brucea.

Također bih trebao naglasiti da se ovaj post ne smije tumačiti kao napad na zajednički hosting. Umjesto toga, to je čisto akademski pogled na sigurnosna pitanja oko ove kategorije web hostinga.

Obilazak kataloga

Započnimo s napadima kroz presjek direktorija (često poznat kao "prelazak putem"). Ova vrsta napada omogućuje vam pristup datotekama i mapama koje se pohranjuju izvan web korijena.

Na običnom engleskom? Pa, zamislimo da Alice i Bob koriste isti poslužitelj za hosting svojih web stranica. Aliceine datoteke su pohranjene u / var / www / alice, dok se Bob-ovi dokumenti mogu pronaći u / var / www / bob. Nadalje, pretvaramo se da postoji još jedna mapa na poslužitelju (/ usr / crappyhosting / myfolder) koja sadrži nekodiranu datoteku u otvorenom tekstu (nazvaćemo je pwd.txt) koja sadrži korisnička imena i lozinke sustava.

Sa mnom do sada? Dobro. Zamislimo sada da Bob's web mjesto služi PDF datoteke koje se generiraju lokalno, a lokalna datoteka se nalazi u URL-u. Nešto kao:

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

Što bi se dogodilo ako zamijenim 'report.pdf' nekim UNIX parametrima koji mijenjaju direktorij?

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

Ako je poslužitelj pogrešno konfiguriran, to bi vam omogućilo da vidite Aliceov korijen dokumenta. Zanimljivo, ali nas mnogo više zanima ta sočna datoteka putovnice. Accio lozinke!

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

Doista je lako kao to. Ali kako se nositi s tim? To je lako.

Da li ste ikada čuli za malo poznati alat Linux nazvan chroot? Vjerojatno ste već pogodili o čemu se radi. Linux / UNIX korijen postavlja u proizvoljnu mapu, onemogućujući mu korisnike da ga napuste. Učinkovito, zaustavlja napade kroz direktorij u njihovim zapisima.

Teško je reći ima li vaš domaćin ovo mjesto bez kršenja zakona. Napokon, da biste ga testirali, pristupili biste sustavima i datotekama za koje nemate dozvolu pristupa. Imajući to u vidu, možda bi bilo razumno razgovarati s vašim web domaćinom i raspitati se kako izoliraju svoje korisnike jedni od drugih.

Koristite li svoj vlastiti hosting server i ne upotrebljavate chroot za zaštitu svojih korisnika? Doduše, krotiranje okoline može biti teško. Srećom, postoji mnoštvo dodataka koji ovo olakšavaju. Pogledajte posebno mod_chroot.

Ubrizgavanje naredbe

Vratimo se Alice i Bobu. Dakle, znamo da Bobova web aplikacija ima nekoliko… Ahem… Sigurnosna pitanja u njoj. Jedna od njih je ranjivost ubrizgavanja naredbi, koja vam omogućuje pokretanje proizvoljnih naredbi sustava. Kratki vodič za početak rada s naredbenim retkom Linuxa Kratki vodič za početak rada s naredbenim retkom Linuxa Možete napraviti puno nevjerojatnih stvari s naredbama u Linuxu i zaista nije teško naučiti. .

Bobova web stranica omogućuje pokretanje Whois upita na drugoj web stranici koja se zatim prikazuje u pregledniku. Postoji standardni HTML okvir za unos koji prihvaća naziv domene, a zatim pokreće whois sistemsku naredbu. Ova se naredba izvršava pozivom PHP naredbe system ().

Što bi se dogodilo ako netko unese sljedeću vrijednost?

example.com && cd… / alice / && rm index.html

Pa, razbijemo ga. Nešto od ovoga moglo bi vam biti poznato ako ste pročitali naš „Vodič za početak rada Linuxa“ Vodič za početak rada za Linux Vodič za početak rada za Linux Vodič za početnike za početnike za Linux! Vjerojatno ste čuli za Linux, besplatni operativni sustav otvorenog koda koji je gurao Microsoft. e-knjiga koju smo prethodno objavili 2010. godine ili je pregledala naš Linux Cheat Sheet.

Prvo, pokrenut će Whois upit na example.com. Tada bi promijenio trenutni radni imenik u korijenski dokument Alice. Tada će ukloniti datoteku nazvanu 'index.html' koja je indeksna stranica na njezinoj web stranici. To nije dobro. Ne gospodine.

Kao administratori sustava, kako ublažiti to? Pa, vraćajući se prethodnom primjeru, uvijek možemo svakog korisnika staviti u njegovo izolirano, sanitizirano i chrooted okruženje.

Tome možemo pristupiti i s jezične razine. Moguće je (iako, to može razbiti stvari) globalno uklanjanje deklaracija funkcija s jezika. To će reći, moguće je uklanjanje funkcionalnosti s jezika kojima korisnici imaju pristup.

Gledajući posebno PHP, možete ukloniti funkcionalnost pomoću Runkita - PHP službenog priručnika alata za izmjenu funkcionalnosti jezika. Tamo je bogata dokumentacija. Pročitajte.

Možete i izmijeniti PHP-ovu konfiguracijsku datoteku (php.ini) da biste onemogućili funkcije koje hakeri često zloupotrebljavaju. Da biste to učinili, otvorite terminal na vašem poslužitelju i otvorite datoteku php.ini u uređivaču teksta. Uživam u korištenju VIM-a, ali prihvatljivo je i NANO.

Pronađite liniju koja započinje s onemogućenim funkcijama i dodajte definicije funkcija koje želite zabraniti. U ovom slučaju to bi bio exec, shell_exec i sustav, iako je vrijedno napomenuti da postoje i druge ugrađene funkcije koje hakeri mogu iskoristiti.

disable_functions = exec, shell_exec, sustava

Napadi na temelju jezika i tumača

Dakle, pogledajmo PHP. Ovo je jezik koji pokreće zapanjujući broj web stranica. Također dolazi s nizom idiosinkrazija i čudnih ponašanja. Kao ovo.

PHP se obično koristi u kombinaciji s web-poslužiteljem Apache. Uglavnom je nemoguće učitati više verzija jezika s ovom konfiguracijom.

Zašto je to problem? Pa, zamislimo, Bobova web aplikacija izvorno je izgrađena 2002. To je davno prošlo. Vratilo se to kad je Michelle Branch još uvijek bila na vrhu ljestvice, Michael Jordan je još uvijek igrao za Washington Wizards i PHP je bio puno drugačiji jezik.

Ali Bobova web stranica još uvijek radi! Koristi čitav niz prekinutih i zastarjelih funkcija PHP-a, ali djeluje! Korištenje moderne verzije PHP-a učinkovito bi pokvarilo Bobovu web stranicu, i zašto bi Bob prepisivao svoju web stranicu kako bi se zadovoljio ćudima svog web domaćina?

To bi vam moglo dati ideju o dilemi s kojom su neki domaćini suočeni. Moraju uravnotežiti održavanje arhitektonski zdravog i sigurnog servisa, a to je u skladu s osiguravanjem zadovoljstva kupaca koji plaćaju.

Zbog toga nije rijetkost vidjeti da manji, neovisni domaćini koriste starije verzije interpretera PHP (ili bilo kojeg jezika, u tom smislu).

Nije neuobičajeno da manji, neovisni domaćini koriste starije verzije PHP-a, potencijalno izlažući korisnike sigurnosnim rizicima.

Zašto je to loše? Pa, prvo, korisnike bi izložili brojnim sigurnosnim rizicima. Kao i većina glavnih softverskih paketa, PHP se stalno ažurira kako bi se riješio mnoštvo sigurnosnih ranjivosti koje se stalno otkrivaju (i otkrivaju).

Nadalje, to znači da korisnici ne mogu koristiti najnovije (i najveće) jezične funkcije. To također znači da ostaju funkcije koje su zastarjele s razlogom. U slučaju programskog jezika PHP, to uključuje smiješno strašne (i nedavno zastarele) mysql_ funkcije koje se koriste za interakciju s MySQL relacijskim sustavom baza podataka i dl (), koji omogućava korisnicima da uveze vlastita jezična proširenja.

Kao korisnik, trebali biste moći vidjeti koja se verzija prevoditelja prevodi na vašu uslugu. Ako je zastario ili sadrži nekoliko sigurnosnih ranjivosti, obratite se svom domaćinu.

Što je s sysadminima? Ovdje imate nekoliko opcija. Prvo (i najperspektivnije) je koristiti Docker za svakog svog korisnika. Docker vam omogućuje istodobno pokretanje više izoliranih okruženja, baš kao što to radi i virtualni stroj, iako ne morate pokrenuti neki drugi operativni sustav. Kao rezultat toga, ovo je brzo. Stvarno, stvarno brzo.

Na običnom engleskom? Možete pokrenuti najnoviji i najveći rubni tumač za većinu svojih korisnika, dok kupci koji koriste stare aplikacije koji koriste drevne, zastarjele interpretatore to rade bez ugrožavanja drugih korisnika.

To također ima prednost u tome što je jezični agnostik. PHP, Python, Ruby. Što god. Sve je to isto.

Nemoj imati noćne more.

Ovaj post trebao je učiniti nekoliko stvari. Prvo, trebalo je upozoriti na broj sigurnosnih pitanja s kojima se web hosting tvrtke moraju suočiti kako bi osigurale sigurnost svojih kupaca i njihovih podataka..

Također se željelo pokazati kako web lokacije koje se nalaze na istom poslužitelju mogu utjecati jedna na drugu. Želite staviti udubljenje u ovome? Počnite se pridržavati dobrih, sigurnih standarda kodiranja. Konkretno, počnite sanirati unose i na prednjem i na stražnjem kraju.

Dobar početak je s novom funkcionalnošću provjere valjanosti obrasca HTML5. O tome smo već razgovarali u našem HTML5 vodiču. Kolektivno, web mjesta možemo učiniti sigurnijima boljim i savjesnijim programerima.

Kao i uvijek, spremna sam da čujem vaše misli. Ispusti mi komentar ispod.

Kredit za fotografije: svima je potreban haker (Alexandre Dulaunoy), naljepnica na taksi prozoru (Cory Doctorow), server soba (Torkild Retvedt), Linux knjige i časopisi (library_mistress), PHP Elephant (Markus Tacker)