Fick delad hosting och orolig över säkerhet? Här är vad du behöver veta

Delad hosting. Det är det billiga alternativet, eller hur? Och för en stor del av befolkningen är det allt de någonsin behöver vara värd för deras hemsida eller webbapplikation. Och när det är bra är delad hosting skalbar, snabb och säker.

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

Nå då börjar farliga säkerhetsproblem krypa in. Det är då din webbplats riskerar att bli defacerad eller de privata uppgifterna du håller läckta. Men var inte arg. De allra flesta webbhotell har anständiga säkerhetsåtgärder. Det är bara fly-by-night, bargain-källaren värdar du måste vara försiktig med.

Vi rekommenderar InMotion Hosting delad hosting med SSD-lagring.

Vi ska undersöka säkerhetsproblemen kring delad hosting. Men först, låt oss prata om vad som gör en gemensam värdplattform säker.

Vad gör en säker webbhotell

Det finns några standout säkerhetshänsyn som bör göras med avseende på shared hosting.

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

Återigen uppfyller de flesta webbhotell de här kraven för sina delade erbjudanden. Men om du tittar på värd flera webbplatser på en server eller är nyfiken på att se hur ditt webbhotell stackar upp eller till och med tänker på att starta ditt eget webbhotell och är angelägna om att utreda hur man säkrar dina användare, var god läs på.

Men först en ansvarsfriskrivning

Innan vi kommer in i köttet när vi tittar på vanliga attacker som planeras på delad hosting, vill jag bara ange att det här inlägget inte kommer att vara (och borde inte läsas som) en uttömmande lista över potentiella säkerhetsproblem.

Säkerhet är i stort sett stor. Det finns många sätt att kompromissa med en webbplats. Detta går dubbelt för delat hosting. Att täcka dem i en enda artikel var aldrig på korten.

Om du är paranoid om din säkerhet, få en VPS eller dedikerad server. Det här är miljöer där du (för det mesta) 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 för webbhotell förklaras. [Teknologi förklaras] De olika formerna för webbhotell förklaras. [Teknologi förklaras] Läs mer från min kollega James Bruce.

Jag borde också betona att detta inlägg inte ska tolkas som en attack mot delad hosting. Snarare är det en rent akademisk titt på säkerhetsproblemen kring denna kategori av webbhotell.

Directory Traversal

Låt oss börja med katalogtransversal (ofta känd som "väggenomgång"). Denna typ av attack låter dig komma åt filer och kataloger som lagras utanför webbrotten.

På vanlig engelska? Tja, 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. Alices 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 innehåller en okrypterad plaintext-fil (vi kallar det pwd.txt) som innehåller system användarnamn 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 refereras till i webbadressen. Något liknande:

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

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

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

Om servern är konfigurerad felaktigt kan du då se Alices dokumentrots. 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 någonsin hört talas om ett litet känt Linux-verktyg chroot? Du har antagligen redan gissat vad det gör. Den sätter Linux / UNIX-roten i en godtycklig mapp vilket gör det omöjligt för användarna att avsluta det. Effektivt stoppar den katalysera traversa attacker i sina spår.

Det är svårt att berätta om din värd har detta på plats utan att bryta lagen. För att testa det, skulle du få tillgång till system och filer som du inte har behörighet att få åtkomst till. Med det i åtanke kanske det är vettigt att prata med din webbhotell och fråga om hur de isolerar sina användare från varandra.

Fungerar du med din egen delade webbhotell och använder inte chroot för att skydda dina användare? Det kan vara svårt att chrooting dina miljöer. Tack och lov finns det en mängd plugins som gör det enkelt. Ta en titt på mod_chroot, i synnerhet.

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 sårbarheten för injektion av kommandot, vilket gör att du kan köra godtyckliga systemkommandon En snabbguide för att komma igång med Linux-kommandoraden En snabbguide för att komma igång med Linux-kommandoraden Du kan göra massor av fantastiska saker med kommandon i Linux och det är egentligen 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 då visas i webbläsaren. Det finns en standard HTML-inmatningsruta som accepterar ett domännamn och kör sedan whois-systemkommandot. Detta kommando utförs genom att anropa systemet () PHP-kommandot.

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

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

Tja, låt oss bryta ner det. Några av detta kan vara bekant för dig om du har läst vår "Komma igångsguiden till Linux" Komma igång Guide till Linux Komma igång till Linux En nybörjare Komma igång Guide till Linux! Du har nog hört talas om Linux, det fria operativsystemet med öppen källkod som har drivit upp mot Microsoft. Läs mer e-bok, som vi tidigare publicerade 2010, eller har tittat på vårt Linux Command Line Cheat Sheet.

För det första kommer det att köras en whois-fråga på example.com. Då skulle det ändra den nuvarande arbetskatalogen till Alices dokumentrots. Då skulle det ta bort filen som heter index.html som är indexsidan till hennes hemsida. Det är inte bra. Ingen herre.

Så, som systemadministratörer, hur motverkar vi det här? Tja, går tillbaka till föregående exempel kan vi alltid sätta varje användare i sin egen isolerade, saniterade, chrooted miljö.

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

Titta på PHP i synnerhet, du kan 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 PHP: s 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 linjen 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, systemet

Språk- och tolkbaserade attacker

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

PHP används vanligtvis i samband 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 det här ett problem? Tja, låt oss föreställa oss att Bobs webbapplikation ursprungligen byggdes 2002. Det är länge sedan. Det är tillbaka när Michelle Branch fortfarande fyllde i tabellerna, Michael Jordan spelade fortfarande för Washington Wizards och PHP var ett mycket annat språk.

Men Bobs hemsida fungerar fortfarande! Det använder en hel massa avbrutna och avvecklade PHP-funktioner, men det fungerar! Att använda en modern version av PHP skulle effektivt bryta Bobs hemsida, och varför ska Bob skriva om sin hemsida för att tillgodose whimsna hos hans webbhotell?

Detta borde 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 service, samtidigt som det håller i harmoni med att de betalande kunderna är lyckliga.

Som ett resultat är det inte ovanligt att se mindre oberoende värdar använder äldre versioner av PHP (eller vilket språk som helst) tolk.

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

Varför är det här en dålig sak? Tja, för det första skulle det utsätta användarna för ett antal säkerhetsrisker. Liksom de flesta större mjukvarupaket uppdateras PHP ständigt för att hantera de många säkerhetsproblem som ständigt upptäckes (och avslöjas).

Dessutom betyder det att användarna inte kan använda de senaste (och bästa) språkfunktionerna. Det betyder också att funktioner som har avlägsnats av en anledning kvarstår. När det gäller PHP-programmeringsspråket inkluderar detta de skrämmande hemska (och nyligen avlägsna) mysql_-funktionerna som används för att interagera med MySQL Relational Database System och dl (), vilket gör det möjligt för användare att importera sina egna språktillägg.

Som användare borde du kunna se vilken version av tolk som körs till din tjänst. Om det är föråldrat eller med ett antal säkerhetsproblem, kontakta din värd.

Vad sägs om sysadminer? 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, ungefär som en virtuell maskin gör, om än utan att behöva köra ett annat operativsystem. Som ett resultat är detta snabbt. Verkligen, riktigt snabbt.

På vanlig engelska? Du kan köra den senaste och bästa blödningskanten tolken för majoriteten av dina användare, medan de kunder som använder gamla applikationer som använder gamla, avlägsna tolkar för att göra det utan att kompromissa med andra användare.

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

Har inte mardrömmar.

Det här inlägget var tänkt att göra ett par saker. För det första var det att uppmärksamma antalet säkerhetsproblem som webbhotell företag måste möta för att säkerställa deras kunders säkerhet och deras data.

Det var också avsett att visa dig hur webbplatser som är värd på samma server kan påverka varandra. Vill du lägga ett dugg i detta? Börja lyda goda, säkra kodningsstandarder. Särskilt börja med att sanitera dina ingångar både på fronten och baksidan.

En bra start är med den nya HTML5-formulärvalideringsfunktionen. Vi har pratat om detta tidigare i vår HTML5 guide. Sammantaget kan vi göra webbplatser säkrare genom att vara bättre, mer samvetsgranna programmörer.

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

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

Utforska mer om: Online-säkerhet, webbhotell.