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

Delt hosting. Det er den billige mulighed, ikke? Og for en enorm befolkning er det alt, hvad de nogensinde har brug for 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 gøres godt?

Det er, når farlige sikkerhedsproblemer begynder at krybe ind. Det er, når dit websted risikerer at blive defaced, eller de private data, du har, lækkes. Men bekymre dig 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.
• 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 sin 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 overvejer at starte dit eget hostingfirma og er ivrig 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 ind i kødet ved at se på almindelige angreb, der er niveaueret ved delt hosting, vil jeg bare oplyse, 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 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 former for webhosting, så tjek dette indlæg De forskellige former for webstedshosting forklaret [Teknologi forklaret] De forskellige former for webstedshosting forklaret [Teknologi forklaret] 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 katalogtraversal (ofte kendt som 'sti traversal) 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), der indeholder brugernavne og adgangskoder til systemet.

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 'report.pdf' med nogle UNIX-parametre, der ændrer kataloget?

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

Hvis serveren er konfigureret forkert, giver dette 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 vende 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 med kommandoinjektion, som giver dig mulighed for at køre vilkårlige 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. .

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 dig måske velkendt, hvis du har læst vores 'Kom godt i gang-guide til Linux' Kom godt i gang Vejledning til Linux Kom godt i gang Vejledning til Linux En begyndelsesvejledning til Newbie til Linux! Du har sandsynligvis hørt om Linux, det gratis, open source-operativsystem, der har skubbet op mod Microsoft. e-bog, som vi tidligere udgav i 2010, eller har kigget på vores Linux Command Line Cheat Sheet.

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 reducerer vi mod 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 at ændre 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, systemet

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 var 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 hans 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, mens de holder det i harmoni med at sikre, at de betalende kunder er glade.

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, hvilket 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 afskrevet af en grund, forbliver. For PHP-programmeringssprog inkluderer dette 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 egne sprogudvidelser.

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? Du har et par muligheder her. 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 størstedelen af ​​dine brugere, mens kunderne, der bruger gamle applikationer, der bruger gamle, forældede tolke, gør 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 sikkerhedsproblemer, 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 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 (bibliotek_mesterinde), PHP Elephant (Markus Tacker)