Har du delt hosting og bekymret dig for sikkerhed? Her er hvad du skal vide

Reklame

Delt hosting. Det er den billige mulighed, ikke sandt? Og for en enorm gruppe af befolkningen er det alt, hvad de nogensinde har brug for at være vært for deres websted eller webapplikation. Og når det gøres godt, er delt hosting skalerbar, hurtig og sikker.

Men hvad sker der, når det ikke er gjort 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 har, lækkes. Men kæmp ikke. Langt de fleste webværter har anstændige sikkerhedsforanstaltninger. Det er kun de fly-by-night, forhandler-kælderværter, du skal være på vagt over for.

Vi anbefaler InMotion Hosting's delte hosting med SSD-lager.

Vi vil undersøge sikkerhedsproblemerne omkring delt hosting. Men først lad os tale om, hvad der sikrer en delt hostingplatform.

Hvad der skaber en sikker webhost

Der er nogle få fremtrædende sikkerhedshensyn, der skal tages med hensyn til delt hosting.

• Hver bruger på serveren skal være isoleret fra andre brugere og skal ikke være i stand til at få adgang til eller ændre filerne fra andre brugere.
instagram viewer
• En sikkerhedssårbarhed i logikken på et websted, der er vært på serveren, bør ikke kunne påvirke andre brugere.
• Serveren bliver løbende opdateret, opdateret og overvåget for at løse arkitektoniske sikkerhedsproblemer.
• Hver bruger skal have deres egen isolerede databaseadgang og bør ikke have tilladelse til at foretage ændringer i de gemte poster eller tabel tilladelser for andre brugere.

Igen opfylder de fleste webhost disse krav til deres delte tilbud. Men hvis du ser på at være vært for flere websteder på en server, eller er nysgerrig efter at se, hvordan dit hostingfirma stables op, eller endda tænker på at starte dit eget hostingfirma og er ivrige efter at finde ud af, hvordan du sikrer dine brugere, så læs venligst på.

Men først en ansvarsfraskrivelse

Før vi går i kødet ved at se på almindelige angreb, der er niveaueret ved delt hosting, vil jeg bare gerne oplyse, at dette indlæg ikke vil være (og ikke bør læses som) en udtømmende liste over potentiel sikkerhed problemer.

Sikkerhed er på et ord stort. Der er mange måder, hvorpå du kan gå på kompromis med et websted. Dette går dobbelt for delt hosting. Dækningen af ​​dem i en enkelt artikel var aldrig på kortene.

Hvis du er paranoid omkring din sikkerhed, skal du få en VPS eller en dedikeret server. Dette 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 webhosting, tjek dette indlæg 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 blik på sikkerhedsproblemerne omkring denne kategori af webhosting.

Directory Traversal

Lad os starte med biblioteksovergang (ofte kendt som 'sti gennemgang) angreb. Denne form for angreb giver dig adgang til filer og mapper, der er gemt uden for webroten.

På almindeligt engelsk? Lad os forestille os, at Alice og Bob bruger den samme server til at være vært for deres websteder. Alice's filer gemmes i / var / www / alice, mens Bobs dokumenter kan findes i / var / www / bob. Lad os desuden foregive, at der er en anden mappe på serveren (/ usr / crappyhosting / myfolder) der indeholder en ikke-krypteret ren tekstfil (vi kalder den pwd.txt) indeholdende systemnavn og adgangskoder.

Med mig indtil videre? Godt. Lad os forestille os, at Bob's websted serverer PDF-filer, der genereres lokalt, og den lokale fil henvises til i URL-adressen. Noget som:

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

Hvad ville der ske, hvis jeg erstattede 'rapport.pdf' med nogle UNIX-parametre, der ændrer biblioteket?

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

Hvis serveren er konfigureret forkert, vil dette derefter give dig mulighed for at se Alice's dokumentrod. Interessant, men vi er langt mere interesseret i den saftige pasfil. Accio-adgangskoder!

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

Det er virkelig så let som det. Men hvordan skal vi håndtere det? Det er nemt.

Nogensinde hørt om et lidt kendt Linux-værktøj kaldet chroot? Du har sandsynligvis allerede gættet, hvad det gør. Det sætter Linux / UNIX-roden til en vilkårlig mappe, hvilket gør det umuligt for brugere at forlade den. Effektivt stopper det katalogtraversale angreb i deres spor.

Det er svært at se, om din vært har dette på plads uden at overtræde loven. Når alt kommer til alt, for at teste det, får du adgang til systemer og filer, som du ikke har tilladelse til at få adgang til. Med det i tankerne er det måske fornuftigt at tale med din webhost og spørge om, hvordan de isolerer deres brugere fra hinanden.

Betjener du din egen delte hosting-server og bruger du ikke chroot til at beskytte dine brugere? Ganske vist kan det være svært at forkøle dine miljøer. Heldigvis er der et væld af plugins, der gør dette let. Se især mod_chroot.

Kommandoinjektion

Lad os komme tilbage til Alice og Bob. Så vi ved, at Bob's webapplikation har et par... Ahem... Sikkerhedsproblemer i det. En af disse er sårbarheden til kommandoinjektion, som giver dig mulighed for at køre vilkårlige systemkommandoer En hurtig guide til at komme i gang med Linux-kommandolinjenDu 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 websted giver dig mulighed for at køre en whois-forespørgsel på et andet websted, der derefter vises i browseren. Der er en standard HTML-inputboks, der accepterer et domænenavn og derefter kører whois-systemkommandoen. Denne kommando udføres ved at kalde PHP-kommandoen system ().

Hvad ville der ske, hvis nogen indtastede følgende værdi?

eksempel.com && cd ../alice/ && rm index.html

Lad os nedbryde det. Noget af dette er måske kendt, hvis du har læst vores 'Kom godt i gang Guide til Linux' Kom godt i gang med Linux og UbuntuDu er interesseret i at skifte til Linux... men hvor starter du? Er din pc kompatibel? Vil dine foretrukne apps arbejde? Her er alt hvad du har brug for at vide for at komme i gang med Linux. Læs mere e-bog, som vi tidligere udgav i 2010, eller har kigget på vores Linux kommandolinje snyderi.

For det første kører det en whois-forespørgsel på eksempel.com. Derefter ville det ændre det aktuelle arbejdsmappe til Alice's dokumentrod. Derefter fjerner den filen kaldet 'index.html', som er indekssiden til hendes hjemmeside. Det er ikke godt. Nej Herre.

Så som systemadministratorer, hvordan afhjælper vi dette? Når vi går tilbage til det forrige eksempel, kan vi altid sætte enhver bruger i deres eget isolerede, desinficerede, hakkede miljø.

Vi kan også nærme os dette fra et sprogniveau. Det er muligt (skønt dette kan ødelægge ting) globalt at fjerne funktionserklæringer fra sprog. Det er at sige, det er muligt at fjerne funktionalitet fra de sprog, som brugerne har adgang til.

Ser man især på PHP, kan du fjerne funktionalitet med Runkit - PHPs officielle værktøjssæt til ændring af sprogets funktionalitet. Der er et væld af dokumenter 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 en teksteditor. Jeg kan godt lide at bruge VIM, men NANO er ​​også acceptabelt.

Find den linje, 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, skønt det er værd at bemærke, at der er andre indbyggede funktioner, der kan udnyttes af hackere.

disable_functions = exec, shell_exec, system

Sprog- og tolkbaserede angreb

Så lad os se på PHP. Dette er det sprog, der giver et overraskende antal websteder. Det kommer også med en række idiosynkrasier og underlig 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? Lad os forestille os, at Bob's webapplikation oprindeligt blev bygget i 2002. Det er længe siden. Det var tilbage, da Michelle Branch stadig toppede hitlisterne, Michael Jordan spillede stadig for Washington Wizards og PHP var et meget andet sprog.

Men Bob's hjemmeside fungerer stadig! Den bruger en hel masse ophørte og forældede PHP-funktioner, men det fungerer! Brug af en moderne version af PHP ville effektivt ødelægge Bobs websted, og hvorfor skulle Bob omskrive sit websted for at imødekomme luner fra sin webhost?

Dette skulle give dig en idé om det dilemma, som nogle webværter står overfor. De er nødt til at balansere med at holde en arkitektonisk forsvarlig og sikker service, samtidig med at de er i harmoni med at sikre, at de betalende kunder er tilfredse.

Som et resultat er det ikke ualmindeligt at se mindre, uafhængige værter bruge ældre versioner af PHP (eller et hvilket som helst sprog, for den sags skyld) tolk.

Det er ikke ualmindeligt at se mindre, uafhængige værter bruge ældre versioner af PHP, som potentielt udsætter brugerne for sikkerhedsrisici.

Hvorfor er dette en dårlig ting? For det første ville det udsætte brugerne for en række sikkerhedsrisici. Som de fleste større softwarepakker opdateres PHP konstant for at tackle overflod af sikkerhedssårbarheder, der konstant bliver opdaget (og afsløret).

Desuden betyder det, at brugere ikke kan bruge de nyeste (og største) sprogfunktioner. Det betyder også, at funktioner, der er blevet afskrevet af en grund, forbliver. I tilfælde af PHP programmeringssprog Lær at opbygge med PHP: Et nedbrudskursPHP er det sprog, som Facebook og Wikipedia bruger til at tjene milliarder af anmodninger dagligt; de-facto-sproget, der bruges til at lære folk webprogrammering. Det er smukt enkelt, men strålende kraftfuldt. Læs mere , dette inkluderer de latterligt forfærdelige (og for nylig forældede) mysql_-funktioner, der bruges til at interagere med MySQL Relational Database System og dl (), som giver brugerne mulighed for at importere deres eget sprog udvidelser.

Som bruger skal du være i stand til at se, hvilken version af en tolk der kører på din tjeneste. Hvis det er forældet eller indeholder et antal sikkerhedsmæssige sårbarheder, skal du kontakte din vært.

Hvad med sysadmins? Her har du et par muligheder. Den første (og mest lovende) er at bruge Docker til hver af dine brugere. Docker giver dig mulighed for at køre flere, isolerede miljøer samtidigt, ligesom en virtuel maskine gør, omend uden at skulle køre et andet operativsystem. Som et resultat er dette hurtigt. Virkelig, virkelig hurtigt.

På almindeligt engelsk? Du kan køre den nyeste og største blødningstolk for de fleste af dine brugere, mens kunderne 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å fordelen ved at være sprogagnostisk. 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 sikkerhedsspørgsmål, som webhostingfirmaer skal stå over for for at sikre deres kunders sikkerhed og deres data.

Det var også beregnet til at vise dig, hvordan websteder, der er vært på den samme server, kan påvirke hinanden. Vil du lægge en buling i dette? Begynd at overholde gode, sikre kodningsstandarder. Begynd især på at sanere dine input på både front-end og back-end.

En god start er med den nye HTML5-formvalideringsfunktionalitet. Vi har talt om dette før i vores HTML5-guide. Samlet kan vi gøre websteder mere sikre ved at være bedre, mere samvittighedsfulde programmører.

Som altid er jeg klar til at høre dine tanker. Giv mig en kommentar nedenfor.

Fotokredit: Alle har brug for en hacker (Alexandre Dulaunoy), Klistermærke på taxavindue (Cory Doctorow), Serverrum (Torkild Retvedt), Linux bøger og magasiner (library_mistress), PHP Elephant (Markus Tacker)