Har du delt vertskapet og bekymret deg for sikkerhet? Her er hva du trenger å vite

Annonse

Delt vertskap. Det er det billige alternativet, er det ikke? Og for en stor befolkning, er det alt de trenger å være vertskap for nettstedet eller webapplikasjonen deres. Og når det er gjort bra, er delt hosting skalerbar, rask og sikker.

Men hva skjer når det ikke er bra?

Vel, det er da farlige sikkerhetsproblemer begynner å krype inn. Det er da nettstedet ditt risikerer å bli belastet, eller de private dataene du har, blir lekket. Men ikke bekymre deg. De aller fleste webverter har anstendige sikkerhetstiltak. Det er bare de fly-by-natt, kjøpekjeller-vertene du må være på vakt mot.

Vi anbefaler InMotion Hosting delte hosting med SSD-lagring.

Vi skal utforske sikkerhetsproblemene rundt delt hosting. Men først, la oss snakke om hva som sikrer en delt hostingplattform.

Hva gjør en sikker webvert

Det er noen få fremtredende sikkerhetshensyn som bør tas med hensyn til delt hosting.

• Hver bruker på serveren skal være isolert fra andre brukere, og skal ikke kunne få tilgang til eller endre filene til andre brukere.
instagram viewer
• Et sikkerhetsproblem i logikken til et nettsted som er vert på serveren, bør ikke kunne påvirke andre brukere.
• Serveren blir regelmessig oppdatert, oppdatert og overvåket for å løse arkitektoniske sikkerhetsproblemer.
• Hver bruker skal ha sin egen isolerte databasetilgang, og skal ikke ha lov til å gjøre endringer i lagrede poster eller tabellstillatelser for andre brukere.

Igjen oppfyller de fleste webhotell disse kravene for deres delte tilbud. Men hvis du ser på å være vertskap for flere nettsteder på en server, eller er nysgjerrig på å se hvordan hostingfirmaet stabler opp, eller til og med tenker på å starte ditt eget hostingfirma og er ivrige etter å finne ut hvordan du kan sikre brukerne dine, så vennligst les på.

Men først en ansvarsfraskrivelse

Før vi setter oss inn i kjøttet av å se på vanlige angrep som er nivået på delt hosting, vil jeg bare gjøre det oppgi at dette innlegget ikke vil være (og ikke bør leses som) en uttømmende liste over potensiell sikkerhet problemer.

Sikkerhet er på et ord stort. Det er mange måter du kan gå på akkord med et nettsted. Dette blir dobbelt for delt hosting. Å dekke dem i en enkelt artikkel sto aldri på kortene.

Hvis du er paranoid om sikkerheten din, kan du få en VPS eller en dedikert server. Dette er miljøer der du (for det meste) har absolutt kontroll over hva som skjer. Hvis du ikke er sikker på de forskjellige typene webhotell, sjekk ut dette innlegget De forskjellige formene for webhotell forklart [Technology Explained] Les mer fra min kollega, James Bruce.

Jeg må også understreke at dette innlegget ikke skal tolkes som et angrep på delt hosting. Snarere er det et rent akademisk blikk på sikkerhetsproblemene rundt denne kategorien webhotell.

Katalog Traversal

La oss begynne med katalogovergang (ofte kjent som ‘sti gjennomkjøring’) -angrep. Denne typen angrep gir deg tilgang til filer og kataloger som er lagret utenfor webroten.

På vanlig engelsk? La oss tenke oss at Alice og Bob bruker den samme serveren for å være vert for nettstedene sine. Alice's filer er lagret i / var / www / alice, mens Bobs dokumenter kan bli funnet i / var / www / bob. La oss dessuten late som det er en annen mappe på serveren (/ usr / crappyhosting / myfolder) som inneholder en ukryptert ren tekstfil (vi kaller den pwd.txt) som inneholder systemnavn og passord.

Med meg så langt? Flink. La oss tenke oss at Bobs nettsted serverer PDF-filer som er generert lokalt, og den lokale filen vises i URL-en. Noe som:

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

Hva ville skje hvis jeg byttet ut ‘report.pdf’ med noen UNIX-parametere som endrer katalogen?

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

Hvis serveren er konfigurert feil, vil dette gi deg muligheten til å se Alice's 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 virkelig så enkelt som det. Men hvordan takler vi det? Det er enkelt.

Hørt noen gang om et lite kjent Linux-verktøy som heter chroot? Du har sikkert allerede gjettet hva den gjør. Den setter Linux / UNIX-roten til en vilkårlig mappe, noe som gjør det umulig for brukere å avslutte den. Effektivt stopper det katalogovergangsangrep i sporene deres.

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

Bruker du din egen delte hosting-server og bruker du ikke chroot for å beskytte brukerne dine? Riktignok kan det være vanskelig å tøye miljøene. Heldigvis er det et vell av plugins som gjør dette enkelt. Se spesielt på mod_chroot.

Kommandoinjeksjon

La oss komme tilbake til Alice og Bob. Så vi vet at Bobs nettapplikasjon har noen få... Ahem... Sikkerhetsproblemer i seg. En av disse er sårbarheten for kommandoinjeksjon, som lar deg kjøre vilkårlige systemkommandoer En rask guide for å komme i gang med Linux-kommandolinjenDu kan gjøre mange fantastiske ting med kommandoer i Linux, og det er virkelig ikke vanskelig å lære. Les mer .

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

Hva ville skje hvis noen la inn følgende verdi?

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

La oss bryte det ned. Noe av dette kan være kjent for deg hvis du har lest vår 'Komme i gang guide til Linux' Komme i gang med Linux og UbuntuDu er interessert i å bytte til Linux... men hvor begynner du? Er datamaskinen din kompatibel? Vil favorittappene dine fungere? Her er alt du trenger å vite for å komme i gang med Linux. Les mer e-bok, som vi tidligere har utgitt i 2010, eller har sett over vår Linux Command Line Cheat Sheet.

For det første kjører det en whois-spørring på eksempel.com. Da vil den endre gjeldende arbeidskatalog til Alice's dokumentrot. Da ville den fjerne filen som heter ‘indeks.html’, som er indekssiden til nettstedet hennes. Det er ikke bra. Nei herre.

Så som systemadministratorer, hvordan demper vi mot dette? Vel, tilbake til forrige eksempel, kan vi alltid sette hver bruker i sitt eget isolerte, desinfiserte, hakkede miljø.

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

Ser du spesielt på PHP, kan du fjerne funksjonalitet med Runkit - PHPs offisielle verktøysett for å endre funksjonaliteten til språket. Det finnes et vell av dokumentasjon der ute. Les inn i det.

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

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

disable_functions = exec, shell_exec, system

Språk- og tolkebaserte angrep

La oss se på PHP. Dette er språket som gir et oppsiktsvekkende antall nettsteder. Det kommer også med en rekke idiosynkrasier og rare atferd. 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? La oss tenke oss at Bobs nettapplikasjon opprinnelig ble bygget i 2002. Det er lenge siden. Det var tilbake da Michelle Branch fortsatt toppet listene, Michael Jordan spilte fortsatt for Washington Wizards og PHP var et mye annet språk.

Men Bobs nettsted fungerer fortsatt! Den bruker en hel haug med utgåtte og avskrevne PHP-funksjoner, men det fungerer! Å bruke en moderne versjon av PHP ville effektivt ødelegge Bobs nettsted, og hvorfor skulle Bob omskrive nettstedet sitt for å imøtekomme det lune webhotellet sitt?

Dette bør gi deg en ide om dilemmaet som noen webhoteller står overfor. De må balansere med å holde en arkitektonisk forsvarlig og sikker tjeneste, mens de holder det i harmoni med å sikre at betalende kunder er fornøyde.

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, og potensielt utsetter brukere for sikkerhetsrisiko.

Hvorfor er dette en dårlig ting? For det første vil det utsette brukere for en rekke sikkerhetsrisikoer. I likhet med de fleste større programvarepakker blir PHP kontinuerlig oppdatert for å adressere mengden av sikkerhetsproblemer som stadig blir oppdaget (og avslørt).

Videre betyr det at brukere ikke kan bruke de nyeste (og største) språkfunksjonene. Det betyr også at funksjoner som har blitt avskrevet av en grunn, forblir. I tilfelle av PHP-programmeringsspråk Lær å bygge med PHP: Et krasjkursPHP er språket som Facebook og Wikipedia bruker for å tjene milliarder av forespørsler daglig; de-facto-språket som brukes til å lære folk programmering på nettet. Det er vakkert enkelt, men strålende kraftig. Les mer , dette inkluderer de latterlig forferdelige (og nylig utdaterte) mysql_-funksjonene som brukes til å samhandle med MySQL Relational Database System, og dl (), som lar brukere importere sitt eget språk utvidelser.

Som bruker skal du kunne se hvilken versjon av en tolk som kjører på tjenesten din. Hvis den er utdatert, eller inneholder en rekke sikkerhetsproblemer, kan du kontakte verten.

Hva med sysadminer? Du har noen få alternativer her. Den første (og mest lovende) er å bruke Docker for hver av brukerne dine. Docker lar deg kjøre flere, isolerte miljøer samtidig, omtrent 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 nyeste og beste blødende tolk for de fleste brukerne dine, mens kundene som bruker gamle applikasjoner som bruker gamle, utdaterte tolker for å gjøre det uten å gå på akkord med andre brukere.

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

Ikke ha mareritt.

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

Det var også ment å vise deg hvordan nettsteder som er vert på den samme serveren kan påvirke hverandre. Vil du ta en bukse i dette? Begynn å følge gode, sikre kodingsstandarder. Begynn spesielt å desinfisere inngangene dine både på frontenden og på baksiden.

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

Som alltid er jeg opptatt av å høre tankene dine. Send meg en kommentar nedenfor.

Fotokreditt: Everybody Needs A Hacker (Alexandre Dulaunoy), Klistremerke på taxivindu (Cory Doctorow), Serverrom (Torkild Retvedt), Linux-bøker og -magasiner (library_mistress), PHP Elephant (Markus Tacker)