Fikk Delt Hosting og bekymret om sikkerhet? Her er hva du trenger å vite

Delt hosting. Det er det billige alternativet, ikke sant? Og for en stor del av befolkningen, er det alt de trenger for å være vert for deres nettside eller webapplikasjon. Og når det er gjort bra, er delt hosting skalerbar, rask og sikker.

Men hva skjer når det ikke er gjort bra?

Vel, det er når farlige sikkerhetsproblemer begynner å krype inn. Det er når nettstedet ditt står i fare for å bli skadet, eller at de private dataene du holder er lekket. Men ikke frykt. De aller fleste webverter har anstendige sikkerhetstiltak. Det er bare fly-by-night, forhandler-kjelleren vertene må du være forsiktig med.

Vi anbefaler InMotion Hosting delt hosting med SSD-lagring.

Vi skal utforske sikkerhetsproblemene rundt delt hosting. Men først, la oss snakke om hva som gjør en delt hosting plattform sikker.

Hva gjør en sikker webvert

Det er noen standout sikkerhetshensyn som bør gjøres med hensyn til delt hosting.

• Hver bruker på serveren skal være isolert fra andre brukere, og bør ikke kunne få tilgang til eller endre filer fra andre brukere.
• Et sikkerhetsproblem i logikken til et nettsted som er hostet på serveren, burde ikke kunne påvirke andre brukere.
• Serveren oppdateres regelmessig, oppdateres og overvåkes for å takle arkitektoniske sikkerhetsproblemer.
• Hver bruker skal ha sin egen, isolerte database tilgang, og bør ikke ha lov til å gjøre endringer i lagrede poster eller tabellbehörigheter fra andre brukere.

Igjen oppfyller de fleste webverter disse kravene for sine delte tilbud. Men hvis du ser på hosting flere nettsteder på én server, eller er nysgjerrig på å se hvordan hostingfirmaet stabler opp eller tenker på å lansere ditt eget hostingfirma og er ivrige etter å finne ut hvordan du sikrer brukerne dine, så vær så snill å lese på.

Men først, en ansvarsfraskrivelse

Før vi kommer inn i kjøttet med å se på vanlige angrep som er avgrenset til delt hosting, vil jeg bare si at dette innlegget ikke vil være (og ikke bør leses som) en uttømmende liste over potensielle sikkerhetsproblemer.

Sikkerhet er stort sett stort. Det er mange måter å kompromittere et nettsted på. Dette går doble for delt hosting. Å dekke dem i en enkelt artikkel var aldri på kortene.

Hvis du er paranoid om sikkerheten din, får du en VPS eller dedikert server. Dette er miljøer der du (for det meste) har absolutt kontroll over hva som foregår. Hvis du ikke er sikker på de ulike typer web hosting, sjekk ut dette innlegget. De forskjellige skjemaene for webvertvert forklart [Teknologi forklart] De ulike skjemaene for webvertvert forklart [Teknologi forklart] Les mer fra min kollega James Bruce.

Jeg bør også understreke at dette innlegget ikke skal tolkes som et angrep på delt hosting. Snarere er det et rent akademisk utseende på sikkerhetsproblemene rundt denne kategorien av web hosting.

Directory Traversal

La oss starte med katalogenes traversal (ofte kjent som "traversale" angrep). Denne typen angrep gir deg tilgang til filer og kataloger som er lagret utenfor webroten.

På vanlig engelsk? Vel, la oss forestille oss at Alice og Bob bruker samme server til å være vert for deres nettsteder. Alice's filer lagres i / var / www / alice, mens Bobs dokumenter er funnet i / var / www / bob. Videre la oss late som om det er en annen mappe på serveren (/ usr / crappyhosting / myfolder) som inneholder en ukryptert rentekstfil (vi kaller det pwd.txt) som inneholder systembrukernavn og passord.

Med meg så langt? Flink. Nå, la oss forestille oss at Bobs nettside serverer PDF-filer som genereres lokalt, og den lokale filen refereres til i nettadressen. Noe som:

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

Hva ville skje hvis jeg erstattet «report.pdf» med noen UNIX-parametere som endrer katalogen?

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

Hvis serveren er konfigurert feil, vil dette da tillate deg å se Alices dokumentrot. Interessant, men vi er langt mer interessert i den saftige passfilen. Accio passord!

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

Det er så enkelt som det. Men hvordan håndterer vi det? Det er enkelt.

Noen gang høre om et lite kjent Linux-verktøy som heter chroot? Du har sikkert allerede gjettet hva det gjør. Den setter Linux / UNIX-roten til en vilkårlig mappe, noe som gjør det umulig for brukerne å avslutte det. Effektivt stopper det katalogenes traversale angrep i sporene sine.

Det er vanskelig å fortelle om verten har dette på plass uten å bryte loven. Tross alt, for å teste det, ville du få tilgang til systemer og filer som du ikke har tillatelse til å få tilgang til. Med det i tankene, ville det kanskje være fornuftig å snakke med webverten og spørre om hvordan de isolerer sine brukere fra hverandre.

Fungerer du med din egen delte hosting server og ikke bruker chroot for å beskytte brukerne? Ganske vist kan chrooting dine omgivelser være vanskelig. Heldigvis er det et vell av plugins som gjør dette enkelt. Ta en titt på mod_chroot, spesielt.

Kommandoinjeksjon

La oss komme tilbake til Alice og Bob. Så, vi vet at Bobs webapplikasjon har noen ... Ahem ... Sikkerhetsproblemer i den. En av disse er sårbarheten for injeksjon av kommandoen, som lar deg kjøre vilkårlig systemkommandoer. En rask guide for å komme i gang med Linux-kommandolinjen. En rask guide for å komme i gang med Linux-kommandolinjen. Du kan gjøre mange fantastiske ting med kommandoer i Linux og det er egentlig ikke vanskelig å lære. Les mer .

Bobs nettsted lar deg kjøre et whois-spørring på et annet nettsted som deretter vises i nettleseren. Det er en standard HTML-input-boks som aksepterer et domenenavn, og kjører deretter whois-systemkommandoen. Denne kommandoen utføres ved å ringe system () PHP-kommandoen.

Hva ville skje hvis noen innførte følgende verdi?

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

Vel, la oss slå det ned. Noen av dette kan være kjent for deg hvis du har lest vår 'Komme i gang-guide til Linux' Komme i gang-guide til Linux Komme i gang-guide til Linux En nybegynners startveiledning for Linux! Du har sikkert hørt om Linux, det frie operativsystemet med åpen kildekode som har presset opp mot Microsoft. Les mer e-bok, som vi tidligere publiserte i 2010, eller har kikket over Linux Command Line Cheat Sheet.

For det første vil det kjøre en whois-spørring på example.com. Da ville det endre dagens arbeidskatalog til Alices dokumentrot. Da ville det fjerne filen kalt 'index.html' som er indekssiden til nettstedet hennes. Det er ikke bra. Nei herre.

Så, som systemadministratorer, hvordan reduserer vi dette? Vel, å gå tilbake til forrige eksempel, kan vi alltid sette hver bruker i sitt eget isolerte, sanitized, chrooted miljø.

Vi kan også nærme dette fra et språknivå. Det er mulig (selv om dette kan ødelegge ting) for globalt å fjerne funksjonserklæringer fra språk. Det vil si, det er mulig å fjerne funksjonalitet fra språkene brukerne har tilgang til.

Når du ser på PHP spesielt, kan du fjerne funksjonaliteten med Runkit - PHPs offisielle verktøykasse for å endre språkets funksjonalitet. Det er et vell av dokumentasjon der ute. Les inn i det.

Du kan også endre PHPs konfigurasjonsfil (php.ini) for å deaktivere funksjoner som ofte misbrukt av hackere. For å gjøre det, åpne en terminal på serveren din og åpne php.ini-filen i et tekstredigeringsprogram. Jeg liker å bruke VIM, men NANO er ​​også akseptabelt.

Finn linjen som starter med disable_functions og legg til funksjondefinisjonene du ønsker å forby. I dette tilfellet ville det være exec, shell_exec og system, selv om det er verdt å merke seg at det finnes andre innebygde funksjoner som kan utnyttes av hackere.

disable_functions = kjørbart, shell_exec, system

Språk- og tolkbaserte angrep

Så, la oss se på PHP. Dette er språket som driver et oppsiktsvekkende antall nettsteder. Det kommer også med en rekke idiosyncrasies og rare oppføringer. Som dette.

PHP brukes vanligvis i forbindelse med Apache webserveren. For det meste er det umulig å laste flere versjoner av språket med denne konfigurasjonen.

Hvorfor er dette et problem? Vel, la oss forestille oss at Bobs webapplikasjon ble opprinnelig bygget i 2002. Det er for lenge siden. Det er tilbake da Michelle Branch fortsatt var på topplistene, Michael Jordan spilte fortsatt for Washington Wizards, og PHP var et mye annet språk.

Men Bobs nettsted jobber fortsatt! Den bruker en hel mengde avviklet og utdatert PHP-funksjoner, men det fungerer! Bruke en moderne versjon av PHP ville effektivt ødelegge Bobs nettsted, og hvorfor bør Bob omskrive sitt nettsted for å imøtekomme hilsenene til hans webverten?

Dette bør gi deg en ide om dilemmaet noen web verter står overfor. De må balansere å holde en arkitekturlig og sikker tjeneste, samtidig som det holder seg i harmoni med at de betalende kundene er lykkelige.

Som et resultat er det ikke uvanlig å se mindre, uavhengige verter bruke eldre versjoner av PHP (eller noe språk, for den saks skyld) tolk.

Det er ikke uvanlig å se at mindre, uavhengige verter bruker eldre versjoner av PHP, som potensielt utsetter brukere for sikkerhetsrisiko.

Hvorfor er dette en dårlig ting? Vel, for det første vil det utsette brukere for en rekke sikkerhetsrisiko. Som de fleste store programvarepakker blir PHP kontinuerlig oppdatert for å takle overflod av sikkerhetsproblemer som stadig blir oppdaget (og avslørt).

Videre betyr det at brukerne ikke kan bruke de nyeste (og største) språkfunksjonene. Det betyr også at funksjoner som har blitt avskrevet av en grunn, forblir. Når det gjelder PHP-programmeringsspråket, inkluderer dette de latterlig (og nylig avviklede) mysql_-funksjonene som brukes til å samhandle med MySQL Relational Database System, og dl (), som lar brukerne importere sine egne språkutvidelser.

Som bruker bør du kunne se hvilken versjon av tolk som kjører på din tjeneste. Hvis det er utdatert, eller med et antall sikkerhetsproblemer, kontakter du verten.

Hva med sysadmins? Du har noen få alternativer her. Den første (og mest lovende) er å bruke Docker for hver av brukerne. Docker lar deg kjøre flere, isolerte miljøer samtidig, akkurat som en virtuell maskin gjør, om enn uten å måtte kjøre et annet operativsystem. Som et resultat er dette raskt. Virkelig, veldig fort.

På vanlig engelsk? Du kan kjøre den siste og beste blødningskanten tolken for de fleste brukerne dine, mens kundene som bruker gamle applikasjoner som bruker gamle, avskrevne tolker til å gjøre det uten å gå på kompromiss med andre brukere.

Dette har også fordelen av å være språket agnostisk. PHP, Python, Ruby. Samme det. Det er alt det samme.

Ikke ha mareritt.

Dette innlegget var ment å gjøre et par ting. For det første var det å gjøre oppmerksom på antall sikkerhetsproblemer som webvertsselskaper må møte for å sikre sikkerheten til deres kunder og deres data.

Det var også ment å vise deg hvordan nettsteder som er vert på samme server, kan påvirke hverandre. Ønsker du å sette en pute i dette? Begynn å overholde gode, sikre kodingsstandarder. Spesielt begynner du å sanitere inngangene dine både på forsiden og i bakenden.

En god start er med den nye HTML5 skjema validering funksjonalitet. Vi har snakket om dette før i vår HTML5 guide. Samlet kan vi gjøre nettsteder sikrere ved å være bedre, mer samvittighetsfulle programmerere.

Som alltid er jeg opp for å høre tankene dine. Legg meg en kommentar nedenfor.

Foto Kreditt: Alle trenger en hacker (Alexandre Dulaunoy), Klistremerke på taxi vindu (Cory Doctorow), Server rom (Torkild Retvedt), Linux bøker og magasiner (library_mistress), PHP Elephant (Markus Tacker)

Utforsk mer om: Online Security, Web Hosting.