Delt hosting. Det er den billige løsning, ikke? Og for en stor del af befolkningen er det alt, hvad de nogensinde vil være nødt til at være vært for deres hjemmeside eller webapplikation. Og når det gøres godt, er delt hosting skalerbar, hurtig og sikker.
Men hvad sker der, når det ikke gøres godt?
Nå, det er, når farlige sikkerhedsproblemer begynder at krybe ind. Det er, når dit websted risikerer at blive defaceret, eller de private data, du holder ved at blive lækket. Men lad dig ikke bekymre dig. Langt de fleste web værter har anstændige sikkerhedsforanstaltninger. Det er kun fly-by-night, forhandler-kælder værter du skal være forsigtig med.
Vi skal undersøge sikkerhedsproblemerne omkring delt hosting. Men først, lad os tale om, hvad der gør en delt hosting platform sikker.
Hvad gør en sikker webhost
Der er et par standout sikkerhedsmæssige overvejelser, der bør laves med hensyn til delt hosting.
- Hver bruger på serveren skal være isoleret fra andre brugere, og bør ikke kunne få adgang til eller ændre andre brugeres filer.
- En sikkerhedsproblem i logikken på et websted, der er hostet på serveren, bør ikke kunne påvirke andre brugere.
- Serveren opdateres regelmæssigt, opdateres og overvåges for at imødegå arkitektoniske sikkerhedsproblemer.
- Hver bruger skal have deres egen isolerede databaseadgang, og bør ikke have tilladelse til at foretage ændringer i de lagrede poster eller bordtilladelser fra andre brugere.
Igen opfylder de fleste web værter disse krav til deres fælles tilbud. Men hvis du ser på hosting flere websteder på en server eller er nysgerrig efter at se, hvordan dit hostingfirma stabler op eller endda tænker på at starte dit eget hostingfirma og er ivrig efter at finde ud af, hvordan man sikrer dine brugere, så læs venligst på.
Men først, en ansvarsfraskrivelse
Før vi kommer ind i kødet med at se på almindelige angreb, der er udlignet på delt hosting, vil jeg bare sige, at dette indlæg ikke vil være (og ikke bør læses som) en udtømmende liste over potentielle sikkerhedsspørgsmål.
Sikkerhed er stort set stort. Der er mange måder, hvorpå du kan kompromittere et websted. Dette går dobbelt for delt hosting. At dække dem i en enkelt artikel var aldrig på kortene.
Hvis du er paranoid om din sikkerhed, skal du få en VPS eller dedikeret server. Disse er miljøer, hvor du (for det meste) har absolut kontrol over, hvad der foregår. Hvis du ikke er sikker på de forskellige typer web hosting, skal du tjekke dette indlæg. De forskellige former for webstedshosting forklaret. [Teknologi forklaret] De forskellige former for webstedshosting forklaret. [Teknologi forklaret] Læs mere fra min kollega James Bruce.
Jeg skal også understrege, at dette indlæg ikke skal fortolkes som et angreb på delt hosting. Det er snarere et rent akademisk kig på sikkerhedsproblemerne omkring denne kategori af web hosting.
Directory Traversal
Lad os begynde med katalogoverskridelse (ofte kendt som "vejgående" angreb). Denne form for angreb giver dig mulighed for at få adgang til filer og mapper, der er gemt uden for webroten.
I almindelig engelsk? Nå, lad os forestille os, at Alice og Bob bruger den samme server til at være vært for deres websites. Alice's filer gemmes i / var / www / alice, mens Bobs dokumenter kan findes i / var / www / bob. Desuden lad os foregive, at der er en anden mappe på serveren (/ usr / crappyhosting / myfolder), der indeholder en ukrypteret plaintext-fil (vi kalder det pwd.txt) indeholdende system brugernavne og adgangskoder.
Med mig hidtil? Godt. Lad os nu forestille os, at Bobs hjemmeside serverer PDF-filer, der genereres lokalt, og den lokale fil henvises til i URL'en. Noget som:
http://example.com/file?=report.pdf
Hvad ville der ske, hvis jeg erstattede 'report.pdf' med nogle UNIX-parametre, der ændrer biblioteket?
http://example.com/file?=../alice/
Hvis serveren er konfigureret forkert, vil dette så give dig mulighed for at se Alices dokumentrot. Interessant, men vi er langt mere interesserede i den saftige pasfil. Accio adgangskoder !
http://example.com/file?=../../../usr/crappyhosting/myfolder/pwd.txt
Det er så nemt som det. Men hvordan håndterer vi det? Det er nemt.
Har du nogensinde hørt om et lidt kendt Linux-værktøj kaldet chroot ? Du har sikkert allerede gættet hvad det gør. Det sætter Linux / UNIX-roden til en vilkårlig mappe, hvilket gør det umuligt for brugerne at afslutte det. Effektivt stopper den katalogoverskridende angreb i deres spor.
Det er svært at vide, om din vært har dette på plads uden at bryde loven. For at teste det, ville du få adgang til systemer og filer, som du ikke har adgang til. Med det i tankerne ville det måske være fornuftigt at tale med din webhost og spørge om, hvordan de isolerer deres brugere fra hinanden.
Bruger du din egen fælles hosting server og bruger ikke chroot til at beskytte dine brugere? Ganske vist kan chrooting dine omgivelser være svært. Heldigvis er der et væld af plugins, der gør det nemt. Tag et kig på mod_chroot, især.
Command Injection
Lad os komme tilbage til Alice og Bob. Så, vi ved, at Bobs webapplikation har få ... Ahem ... Sikkerhedsproblemer i den. En af disse er sårbarheden for indsprøjtning af kommandoer, som giver dig mulighed for at køre vilkårlig systemkommandoer. En hurtig guide til at komme i gang med Linux-kommandolinjen. En hurtig guide til at komme i gang med Linux-kommandolinjen. Du kan gøre masser af fantastiske ting med kommandoer i Linux og det er virkelig ikke svært at lære. Læs mere .
Bobs hjemmeside giver dig mulighed for at køre en Whois-forespørgsel på en anden hjemmeside, som derefter vises i browseren. Der er en standard HTML-indtastningsboks, der accepterer et domænenavn, og kører derefter whois-systemkommandoen. Denne kommando udføres ved at kalde systemet () PHP-kommandoen.
Hvad ville der ske, hvis nogen indlæste følgende værdi?
example.com && cd ../alice/ && rm index.html
Nå, lad os bryde det ned. Nogle af dette kan være kendt for dig, hvis du har læst vores 'Kom godt i gang til Linux' Kom godt i gang til Linux Kom godt i gang til Linux En nybegynder Kom godt i gang med Linux! Du har sikkert hørt om Linux, det frie, open source-operativsystem, der har skubbet op imod Microsoft. Læs mere e-bog, som vi tidligere offentliggjorde i 2010, eller har kigget på vores Linux Command Line Cheat Sheet.
For det første vil det køre en whois forespørgsel på example.com. Så ville det ændre den nuværende arbejdsmappe til Alice's dokumentrotte. Så ville det fjerne filen kaldet 'index.html', som er indekssiden til hendes hjemmeside. Det er ikke godt. Nej Herre.
Så, som systemadministratorer, hvordan mildner vi dette? Nå, vi går tilbage til det foregående eksempel, vi kan altid sætte alle brugere i deres eget isolerede, sanitized, chrooted miljø.
Vi kan også nærme dette fra et sprogniveau. Det er muligt (selvom dette kan bryde ting) for globalt at fjerne funktionserklæringer fra sprog. Det vil sige at det er muligt at fjerne funktionalitet fra de sprog, brugerne har adgang til.
I særdeleshed på PHP kan du fjerne funktionalitet med Runkit - PHP's officielle værktøjssæt til at ændre sprogets funktionalitet. Der er et væld af dokumentation derude. Læs ind i det.
Du kan også ændre PHPs konfigurationsfil (php.ini) for at deaktivere funktioner, der ofte misbruges af hackere. For at gøre det skal du åbne en terminal på din server og åbne din php.ini-fil i et tekstredigeringsprogram. Jeg nyder at bruge VIM, men NANO er også acceptabelt.
Find linjen, der starter med disable_functions og tilføj de funktionsdefinitioner, du ønsker at forbyde. I dette tilfælde ville det være exec, shell_exec og system, selvom det er værd at bemærke, at der er andre indbyggede funktioner, der kan udnyttes af hackere.
disable_functions = exec, shell_exec, systemet
Sprog- og tolkbaserede angreb
Så lad os se på PHP. Dette er det sprog, der giver et spændende antal hjemmesider. Det kommer også med en række idiosyncrasies og underlige opførsel. Sådan her.
PHP bruges normalt sammen med Apache webserveren. For det meste er det umuligt at indlæse flere versioner af sproget med denne konfiguration.
Hvorfor er dette et problem? Nå, lad os forestille os, at Bobs webapplikation blev oprindeligt bygget i 2002. Det er for længe siden. Det er tilbage, da Michelle Branch stadig var på toppen af diagrammerne, Michael Jordan spillede stadig for Washington Wizards, og PHP var et meget andet sprog.
Men Bobs hjemmeside virker stadig! Det bruger en hel masse afbrudte og forældede PHP-funktioner, men det virker! Brug af en moderne version af PHP ville effektivt ødelægge Bobs hjemmeside, og hvorfor skal Bob omskrive sit websted for at imødekomme hans webhosts luner?
Dette bør give dig en ide om dilemmaet nogle webværter står overfor. De skal balancere med at holde en arkitekturmæssig forsvarlig og sikker service, samtidig med at det er i harmoni med at sikre, at betalende kunder er glade.
Som følge heraf er det ikke ualmindeligt at se mindre, uafhængige værter bruger ældre versioner af PHP (eller hvilket som helst sprog, for den sags skyld) tolk.
Det er ikke ualmindeligt at se, at mindre uafhængige værter bruger ældre versioner af PHP, der potentielt udsætter brugerne for sikkerhedsrisici.
Hvorfor er dette en dårlig ting? Nå for det første vil det udsætte brugerne for en række sikkerhedsrisici. Som de fleste større softwarepakker opdateres PHP hele tiden for at løse de mange sikkerhedsproblemer, der konstant opdages (og afsløres).
Desuden betyder det, at brugerne ikke kan bruge de nyeste (og største) sprogfunktioner. Det betyder også, at funktioner, der er blevet udskrevet af en grund, forbliver. I tilfældet med PHP programmeringssprog inkluderer dette de latterligt forfærdelige (og for nylig udtrukne) mysql_-funktioner, der bruges til at interagere med MySQL Relational Database System og dl (), som giver brugerne mulighed for at importere deres egne sprogudvidelser.
Som bruger skal du kunne se, hvilken version af en tolk der kører på din tjeneste. Kontakt din vært hvis den er forældet eller indeholder et antal sikkerhedsproblemer.
Hvad med sysadmins? Du har et par muligheder her. Den første (og mest lovende) er at bruge Docker til hver enkelt af dine brugere. Docker giver dig mulighed for at køre flere isolerede miljøer samtidigt, ligesom en virtuel maskine gør, om end uden at skulle køre et andet operativsystem. Som et resultat er dette hurtigt. Virkelig, virkelig hurtigt.
I almindelig engelsk? Du kan køre den seneste og største blødkanten tolk for de fleste brugere, mens de kunder, der bruger gamle applikationer, der bruger gamle, forældede tolke til at gøre det uden at gå på kompromis med andre brugere.
Dette har også den fordel at være agnostisk sprog. PHP, Python, Ruby. Uanset hvad. Det er det samme.
Har ikke mareridt.
Dette indlæg var beregnet til at gøre et par ting. For det første var det at gøre opmærksom på antallet af sikkerhedsproblemer, som webhostingvirksomheder skal konfronteres med for at sikre deres kunders sikkerhed og deres data.
Det var også meningen at vise dig, hvordan websteder, der hostes på den samme server, kan påvirke hinanden. Ønsker du at sætte en dent i dette? Begynd at adlyde gode, sikre kodningsstandarder. Især skal du sanere dine input på både front-end og i back-end.
En god start er med den nye HTML5 formular validering funktionalitet. Vi har talt om dette før i vores HTML5 guide. Samlet kan vi gøre hjemmesider mere sikre ved at være bedre og mere samvittighedsfulde programmører.
Som altid står jeg op for at høre dine tanker. Send mig en kommentar nedenfor.
Fotokredit: Alle har brug for en hacker (Alexandre Dulaunoy), Klistermærke på taxivindue (Cory Doctorow), Serverrum (Torkild Retvedt), Linux-bøger og magasiner (library_mistress), PHP Elephant (Markus Tacker)