Har du delat värd och oroat dig för säkerhet? Här är vad du behöver veta

Annons

Delad värd. Det är det billiga alternativet, eller hur? Och för en enorm befolkning är det allt de behöver någonsin för att vara värd för sin webbplats eller webbapplikation. Och när det görs bra är delad hosting skalbar, snabb och säker.

Men vad händer när det inte går bra?

Det är när farliga säkerhetsproblem börjar krypa in. Det är när din webbplats riskerar att bli avskadad, eller om de privata uppgifterna du har läckt ut. Men oroa dig inte. De allra flesta webbhotell har anständiga säkerhetsåtgärder. Det är bara de flyg-by-night, fynd källaren värdar du måste vara försiktig med.

Vi rekommenderar InMotion Hosting delad värd med SSD-lagring.

Vi kommer att utforska säkerhetsproblemen kring delad värd. Men först låt oss prata om vad som gör en delad värdplattform säker.

Vad gör en säker webbhotell

Det finns några framstående säkerhetshänsyn som bör tas med avseende på delad värd.

• Varje användare på servern ska vara isolerad från andra användare och ska inte kunna komma åt eller ändra andra användares filer.
instagram viewer
• En säkerhetsproblem i logiken för en webbplats som är värd på servern bör inte kunna påverka andra användare.
• Servern patchas, uppdateras och övervakas regelbundet för att hantera arkitektoniska säkerhetsproblem.
• Varje användare bör ha sin egen isolerade databasåtkomst och bör inte tillåtas göra ändringar i lagrade poster eller tabellbehörigheter för andra användare.

Återigen uppfyller de flesta webbhotell dessa krav för sina delade erbjudanden. Men om du tittar på värd för flera webbplatser på en server eller är nyfiken på hur ditt värdföretag staplar upp, eller till och med tänker på att starta ditt eget värdföretag och är angelägna om att ta reda på hur du säkra dina användare, läs gärna på.

Men först en ansvarsfriskrivning

Innan vi går in i köttet av att titta på vanliga attacker jämnade på delad värd, vill jag bara göra det ange att detta inlägg inte kommer att vara (och inte bör läsas som) en uttömmande lista över potentiell säkerhet frågor.

Säkerhet är, i ett ord, stort. Det finns många sätt att kompromissa med en webbplats på. Detta går dubbelt för delad värd. Att täcka dem i en enda artikel fanns aldrig på korten.

Om du är paranoid angående din säkerhet, skaffa en VPS eller dedicerad server. Det här är miljöer där du (till största delen) har absolut kontroll över vad som händer. Om du inte är säker på de olika typerna av webbhotell, kolla in det här inlägget De olika formerna av webbhotell förklarade [Teknisk förklarad] Läs mer från min kollega, James Bruce.

Jag bör också betona att det här inlägget inte ska tolkas som en attack på delad värd. Det är snarare en rent akademisk titt på säkerhetsfrågorna kring denna kategori webbhotell.

Katalog Traversal

Låt oss börja med katalogöverskridande attacker (ofta känd som 'path traversal) -attacker. Den här typen av attack ger dig tillgång till filer och kataloger som är lagrade utanför webbroten.

På vanligt engelska? Låt oss föreställa oss att Alice och Bob använder samma server för att vara värd för sina webbplatser. Alice's filer lagras i / var / www / alice, medan Bobs dokument finns i / var / www / bob. Låt oss dessutom låtsas att det finns en annan mapp på servern (/ usr / crappyhosting / myfolder) som har en okrypterad ren textfil (vi kallar den pwd.txt) som innehåller systemnamn och lösenord.

Med mig hittills? Bra. Låt oss nu föreställa oss att Bobs webbplats serverar PDF-filer som genereras lokalt, och den lokala filen hänvisas till i webbadressen. Något liknande:

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

Vad skulle hända om jag ersatte "rapporten.pdf" med några UNIX-parametrar som ändrar katalogen?

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

Om servern är konfigurerad felaktigt gör det att du kan se Alice's root root. Intressant, men vi är mycket mer intresserade av den saftiga passfilen. Accio-lösenord!

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

Det är verkligen lika enkelt som det. Men hur hanterar vi det? Det är lätt.

Har du någonsin hört talas om ett lite känt Linux-verktyg som heter chroot? Du har antagligen redan gissat vad den gör. Det sätter Linux / UNIX-roten till en godtycklig mapp, vilket gör det omöjligt för användare att lämna den. Effektivt stoppar det katalogöverskridande attacker i deras spår.

Det är svårt att se om din värd har detta på plats utan att bryta lagen. När allt kommer omkring, för att testa det, skulle du komma åt system och filer som du inte har behörighet att komma åt. Med det i åtanke kan det kanske vara förnuftigt att prata med din webbhotell och fråga om hur de isolerar sina användare från varandra.

Använder du din egen delade värdserver och använder du inte chroot för att skydda dina användare? Visserligen kan det vara svårt att kvota dina miljöer. Tack och lov finns det en mängd plugins som gör det enkelt. Titta särskilt på mod_chroot.

Kommandoinjektion

Låt oss komma tillbaka till Alice och Bob. Så vi vet att Bobs webbapplikation har några... Ahem... Säkerhetsproblem i den. En av dessa är kommandoinjektionssårbarheten, som låter dig köra godtyckliga systemkommandon En snabbguide för att komma igång med Linux-kommandoradenDu kan göra många fantastiska saker med kommandon i Linux och det är verkligen inte svårt att lära sig. Läs mer .

Bobs webbplats låter dig köra en whois-fråga på en annan webbplats som sedan visas i webbläsaren. Det finns en vanlig HTML-inmatningsbox som accepterar ett domännamn och sedan kör whois-systemkommandot. Detta kommando utförs genom att anropa systemet () PHP-kommandot.

Vad skulle hända om någon matade in följande värde?

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

Tja, låt oss bryta ner det. En del av detta kan vara bekant för dig om du har läst vår "Komma igång guide till Linux" Komma igång med Linux och UbuntuDu är intresserad av att byta till Linux... men var börjar du? Är din dator kompatibel? Fungerar dina favoritappar? Här är allt du behöver veta för att komma igång med Linux. Läs mer e-bok, som vi tidigare publicerade 2010, eller har tittat på vår Linux Command Line Cheat Sheet.

Först kommer det att köra en whois-fråga på example.com. Då skulle den ändra den nuvarande arbetskatalogen till Alice's dokumentrot. Då skulle den ta bort filen som heter 'index.html', som är indexsidan på hennes webbplats. Det är inte bra. Nej sir.

Så som systemadministratörer, hur mildrar vi detta? Tja, tillbaka till föregående exempel, kan vi alltid sätta varje användare i sin egen isolerade, sanerade, hackade miljö.

Vi kan också närma oss detta från språknivå. Det är möjligt (även om detta kan bryta saker) globalt ta bort funktionsdeklarationer från språk. Det är att säga, det är möjligt att ta bort funktionalitet från de språk som användarna har tillgång till.

När du tittar på PHP särskilt kan du ta bort funktionalitet med Runkit - PHP: s officiella verktygssats för att ändra språkets funktionalitet. Det finns en mängd dokumentation där ute. Läs in det.

Du kan också ändra PHPs konfigurationsfil (php.ini) för att inaktivera funktioner som ofta missbrukas av hackare. För att göra det, öppna en terminal på din server och öppna din php.ini-fil i en textredigerare. Jag tycker om att använda VIM, men NANO är också acceptabelt.

Hitta raden som börjar med disable_functions och lägg till de funktionsdefinitioner du vill förbjuda. I det här fallet skulle det vara exec, shell_exec och system, även om det är värt att notera att det finns andra inbyggda funktioner som kan utnyttjas av hackare.

disable_functions = exec, shell_exec, system

Språk- och tolkbaserade attacker

Så låt oss titta på PHP. Detta är det språk som driver ett häpnadsväckande antal webbplatser. Det kommer också med ett antal idiosynkrasier och konstiga beteenden. Så här.

PHP används vanligtvis tillsammans med Apache-webbservern. För det mesta är det omöjligt att ladda flera versioner av språket med den här konfigurationen.

Varför är detta ett problem? Låt oss föreställa oss att Bobs webbapplikation ursprungligen byggdes 2002. Det är för länge sedan. Det var tillbaka när Michelle Branch fortfarande toppade listorna, Michael Jordan spelade fortfarande för Washington Wizards och PHP var ett mycket annat språk.

Men Bobs webbplats fungerar fortfarande! Den använder en hel massa nedlagda och avskrivna PHP-funktioner, men det fungerar! Att använda en modern version av PHP skulle effektivt bryta Bobs webbplats, och varför skulle Bob skriva om sin webbplats för att tillgodose nycklarna hos sin webbhotell?

Detta bör ge dig en uppfattning om det dilemma som vissa webbhotell står inför. De måste balansera att hålla en arkitektoniskt sund och säker tjänst, samtidigt som de håller det i harmoni med att de betalande kunderna är nöjda.

Som ett resultat är det inte ovanligt att mindre, oberoende värdar använder äldre versioner av PHP (eller något språk, för den delen) tolk.

Det är inte ovanligt att se mindre, oberoende värdar som använder äldre versioner av PHP, vilket kan utsätta användare för säkerhetsrisker.

Varför är detta en dålig sak? Tja, för det första skulle det utsätta användare för ett antal säkerhetsrisker. Liksom de flesta stora programvarupaket uppdateras PHP ständigt för att hantera mängden säkerhetsproblem som konstant upptäcks (och avslöjas).

Dessutom betyder det att användare inte kan använda de senaste (och största) språkfunktionerna. Det betyder också att funktioner som har avskrivits av en anledning kvarstår. I fallet med PHP-programmeringsspråk Lär dig att bygga med PHP: En kraschkursPHP är det språk som Facebook och Wikipedia använder för att betjäna miljarder förfrågningar dagligen; de facto-språket som används för att lära människor webbprogrammering. Det är vackert enkelt, men briljant kraftfullt. Läs mer , detta inkluderar de skratta fruktansvärda (och nyligen utskrivna) mysql_-funktionerna som används för att interagera med MySQL Relational Database System och dl (), som låter användare importera sitt eget språk förlängningar.

Som användare bör du kunna se vilken version av en tolk som körs på din tjänst. Om det är föråldrat eller innehåller ett antal säkerhetsproblem kan du kontakta din värd.

Vad sägs om sysadmins? Du har några alternativ här. Den första (och mest lovande) är att använda Docker för var och en av dina användare. Docker låter dig köra flera, isolerade miljöer samtidigt, precis som en virtuell maskin gör, om än utan att behöva köra ett annat operativsystem. Som ett resultat är detta snabbt. Riktigt, riktigt snabbt.

På vanligt engelska? Du kan köra den senaste och bästa blödande tolk för majoriteten av dina användare, medan kunderna som använder gamla applikationer som använder gamla, utskrivna tolkar för att göra det utan att kompromissa med andra användare.

Detta har också fördelen med att vara språkagnostiker. PHP, Python, Ruby. Vad som helst. Allt är samma.

Har inte mardrömmar.

Detta inlägg var avsett att göra ett par saker. För det första var det att uppmärksamma antalet säkerhetsproblem som webbhotell måste möta för att säkerställa säkerheten för sina kunder och deras data.

Det var också avsett att visa hur webbplatser som är värd på samma server kan påverka varandra. Vill du lägga en tand i detta? Börja följa goda, säkra kodningsstandarder. Börja särskilt att sanera dina ingångar både på framsidan och på baksidan.

En bra start är med den nya valideringsfunktionen för HTML5-formulär. Vi har talat om detta tidigare i vår HTML5-guide. Sammantaget kan vi göra webbplatser säkrare genom att vara bättre och mer samvetsgranna programmerare.

Som alltid är jag redo att höra dina tankar. Släpp en kommentar nedan.

Fotokredit: Alla behöver en hacker (Alexandre Dulaunoy), Klistermärke på taxifönster (Cory Doctorow), Serverrum (Torkild Retvedt), Linux böcker och tidskrifter (bibliotek_mistress), PHP Elephant (Markus Tacker)