Posted by matsjacobsson on March 26, 2012 at 1:17pm
Tjena,
När jag skapar en hemsida i Drupal lokalt och sedan lägger upp den på mitt webbhotell/VPS måste jag ändra mappen sites/default/files och undermapparnas chmod till 777 för att det ska fungera.
Är detta något dumt ur säkerhetssynpunkt?
Mvh // Mats
P.s. De kommandona som används här:
http://drupal.org/node/244924
Är det kommandon som man gör via t.ex putty?
Comments
Det är ett besvärligt problem.
Ur säkerhetssynpunkt är det ju ganska dumt att tillåta vem som helst att skriva i en katalog som går att access från internet. Men tyvärr är det svårt att lösa på något annat sätt. Vill man tillåta att användare ska kunna ladda upp filer måste man tillåta webbserver att skapa filer. Eftersom i en standard apache körs webbservertjänsten som användare www-data men du själv laddar upp filer och kataloger som användare userA, så för att www-data ska kunna ladda upp filer måste www-data har skrivaccess. Det kan göras med chmod 777 eller så ser man till att www-data är med i samma grupp som userA så man kan använda chmod 770.
Men det är ett litet besvärligt problem det här med att tillåta en extern användare ladda upp filer. Det man gör är att man tillåter att webbserver får skriva filer utan kontroll, för att flytta säkerhetskontrollen till Drupal. Men hackas Drupal (med moduler) eller har en bugg så är man förbi säkerhetskontrollen.
Annan annan nackdel med att köra chmod 777 är att vem som helst på server kan skriva och tabort filer i den katalogen. Är servern endast en webbserver med endast har en kund så är det okej. Men problemet uppkommer om det finns andra användare. Låt säga att det finns två kunder på webbhotellet. Om användare userB's hemsida hackas eller är en elak kund kan man komma över userAs filer (eftersom www-data kan läsa dom filerna), dels läsa allt innehåll (läs: källkoden till php-script inklusive mysql-lösenord). Men då även skriva i användarens webbkatalog, byta ut bilder till trojaner osv.
Det man då kan göra är att fixa så att apache körs med olika användare, beroende på vilken hemsida som efterfrågas. Till userA's hemsida körs apache-tjänsten som userA och userB's hemsida som userB. Det medför att man kan sätta kataloger som chmod 700, och helt begränsa de mellan varandra. Då kan kunderna och dess hemsidor inte läsa data/hemsidor mellan varandra. Webbservern kan då ladda upp filer i Drupal katalogen eftersom det körs som den användaren som äger filerna (men webbservern kan då skriva över alla filer också om man inte sätter chmod 400). Så hackas userB's hemsida så kan den inte komma åt userA's hemsida. Detta är ju den bättre lösningen ur säkerhetssynpunkt. Men denna lösning är mer resurskrävade. Varje kund behöver varsin apache-tjänst som drar minne. De tar typ 20-100MB per tjänst alltså på en 2GB maskin kan man endast ha typ 20 webbar, vilket inte är mycket. Och då kan man endast ha en besökare åt gången på varje sida, alternativ stoppa apache-tjänsten för vissa kunder och då har en längre delay när den obesöktsida får besök för att apache ska starta igång. I det första fallet kan man istället har 20 apache-tjänster som hanterar alla hemsidor var och en så man kan har 20 samtida besökare för var och en av sidorna typ.
Tack för svar!
Det tog lite tid att svara, fick läsa igenom några gånger för att försöka få lite grepp om det hela... Jag blev lite förvånad att minnes-åtgången är så stor. Menar du när du säger att man kan ha 20 besökare samtidigt, att de är inloggade eller gästbesökare? Trodde det gick att ha mycket fler besökare (gästbesökare) samtidigt...
Har du något exempel på hur man använder sig av en användare (userA) istället för www-data?
Vänliga hälsningar /Mats
Apache tweeking.
Jo att få ner problematiken i text kan vara lite svårt.
Ang 20 samtidiga besökare så visst är det lite lågt kanske när man läser det som jag skriver. Och det går att ställa in apache att hantera besöka på lite olika sätt. Men antalet processer är som jag skriver om. I en vanlig apache använder man ofta mpm_prefork. Det innebär att apache starta ett antal servrar/processer. Varje anslutning behöver sin egen process, men när anslutning är klar kan processen hantera en annan anslutning som står i kö.
Exempel på inställningar från apache.
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0
Alltså starta med 5 apache processer. Ha minst 5 processer lediga för nya besökare och max 10 på tomgång. Det är ju bra om vi inte behöver starta nya processer när vi får besökare men vi behöver ju inte hålla igång det som inte används. Som max ska apache ha 150 processer igång. Varje process används för varje anslutning. Alltså 150 processer med 20mb i varje, gör att maskinen borde ha minst 3000MB minne (men i värsta fall kan ju detta lätt stiga till det dubbla eller mer om det görs mycket vid varje anslutning). Så vår begränsning är 150 samtidiga anslutningar. Men med HTTP så är det som så att när en fil är hämtad, så är den anslutningen ledigt för nästa besökare. Protokollet är stateless, att ingen koppling sparas mellan varje anslutning (därför behövs vi kakor).
På en Drupal sida kan man lätt ha 30 resurser som ska hämtas (html, css, js, bilder, osv). Dock kommer inte allt hämtas på en gång. Först hämtas html, för att därefter hämta css, js plus lite bilder, sen hämta lite mer bilder som definieras i css. Det brukar också finnas begränsningar i webbläsarna hur mycket som kan hämtas parallellt. (http://meronymy.blogspot.se/2011/09/overview-of-browser-concurrent.html). Så i detta exempel, säg att vi har 5 parallella anslutningar vilket ger att när vi har 30 besökare som hämtar hela sidan samtidigt kommer server slå i taket och nya besökare behöver vänta på att sin sida ska hämtas. Men när man sedan klickar vidare sig på hemsidan kanske inte allt behöver laddas igen, alternativt behöver man bara kolla med server att innehållet inte har ändrats, vilket går fortare än att ladda ner en bild på 300kb. Så dessa anslutningar går riktigt fort innan processen är redo för nästa besökares förfrågan.
Men nu kanske man inte har besökare som hela tiden laddar om sidan utan någon vänta. Oftast laddar man en sida, läser och sedan klickar sig vidare. Om en standard fil tar 50ms att ladda och vi har 30st att ladda ner, så är server upptagen 1,5sekunder. Alltså krävs det att fler än 30 samtidiga besökare på 1,5 sekund för att server ska börja bygga upp en kö. (30/1,5 = 20 besökare i sekunden). Alltså om man har mer än 72 000 besökare per timme kommer inte servern hinna med. Eller om har massor med twitter vänner som alla besöker din hemsida inom en minut från att du postar, då börjar de bli kö om er än 1800 besöker din sida inom en minut.
Så här kan vi se att 150 apache processer räcker ganska långt. Även om vi stryper server och räknar mitt worst case innan med 20 processer så ger det 240 besökare i minuten innan kö börjar byggas upp. Men om man endast har 1 process för att hantera hemsidan klarar man endast av 12 besökare i minuten. Vilket ändå är helt okej för många hemsidor, men om 12 st personer går in på hemsidan samma minut så kan vissa personer behöva vänta upp till 1minut innan allt innehåll är levererat. Vilket få personer skulle acceptera utan skulle surfa vidare efter 10 sekunder.
Så vad kan man göra åt detta då...
Om man börjar slå i taket så kan man ju göra en hel del. Man kan tweeka apache, eller helt byta ut apache till något annat, alternativt ha något framför apache som cachar. Det är här Varnish kommer in i bilden. Det är en cachemotor som ligger före som cachar innehåll. T.ex. behöver man verkligen ha en apache process på 20MB för att leverera en text-fil som css. Apache behövs för att dra igång php och fixa med mysql koppling osv. Men en text fil.... Det är ju bara att läsa filen och skicka på nätverket. Så i stället för att starta igång apache för statiskt innehåll har man andra program. Och där är det inga 20MB per anslutning, där är det ev 10kB per anslutning alltså typ 2000 gånger mer effektivt, enda nackdelen är att den inte kan hantera php.
Problem går att lösa! :-)
Jag brukar lösa det här problemet genom att köra:
chown :www-data files -Rchmod 770 files -R
Om du bara kommer låta inloggade användare som du har godkänt ladda upp filer så skulle du kunna köra de kommandona, och känna dej hyfsat lugn. Men om du låter anonyma användare ladda upp filer (t ex bilder), så kan det vara en bra idé att läsa vidare.
Den stora risken med att bara göra files-katalogen skrivbar är att den här inställningen innebär att man riskerar att öppna sej för en enkel denial-of-service-attack. Användare kan helt enkelt ladda upp skit tills disken är full, och då kan inget mer skrivas till databas eller logg-filer varpå hela sajten dör. Om du inte har fysisk tillgång till sajten så är det krångligt att återställa. Situationen kan dessutom uppstå av misstag.
Ett smidigt sätt att kringgå problemet är att lägga filerna på en annan disk än resten av installationen. Om du är på ett webbhotell, eller en VPS, så kan du inte lägga till en fysisk disk eller partition - däremot kan du skapa en sparse-fil (googla om du är intresserad) och formatera den som en disk. Sedan kan du montera filsystemet-i-en-fil till katalogen files. Effekten blir att filerna i files inte kan ta upp mer utrymme än du redan har allokerat för sparse-filen, och risken för DOS-attack är undanröjd. (Om filen blir full så får du göra en ny, större.)
Kristoffer tog upp problematiken kring att ditt data är läsbart för andra - men om det gör dej orolig så måste jag avråda från webbhotell å det bestämdaste. Då måste du köra med VPS eller fysisk webbserver, samt i fallet med VPS helst använda ett krypterat filsystem (åtminstone för de känsliga bitarna). Krypterat filsystem kan man också köra i en sparse-fil.
När det gäller var kommandona körs, så stämmer det bra att du kan köra dem i puTTY. Om du vill förstå kommandona du kör på servern genom puTTY så föreslår jag att du googlar "unix cli howto" och tittar på någon av sajterna som kommer överst i träfflistan.
Hej!
Med stycket: Den stora risken med att bara göra files-katalogen skrivbar är att de...
Menade då om man då inte ställer in www-data alls utan bara chmod 777?
Undrar också om files i kommandot:
chown :www-data files -R
chmod 770 files -R
är sökvägen till sites/default/files ?
/Mats
Det gäller i båda fallen. Att
Det gäller i båda fallen. Att ge www-data/webbservern (och där med utomstående) rätt att skriva till hårddisken möjliggör att man laddar upp massor av filer som tillslut fyller disken. Och när disken är full kan inget mer skrivas till disken, alltså inga loggar för apache eller mysql. Så då kommer apache och mysql helt stanna och sajten går inte att komma åt. Men risken för detta innefaller endast då man har användare som man inte kan lite på att de inte gör tokigheter.
Och ang kommangot så är det korrekt det gäller sites/default/files. Så lättast är då att stå i katalogen sites/default och köra kommandot.
Tack för alla svar!
Så här blev inställningarna till slut och det verkar fungera fint!
Kommentera gärna ifall det är något som ser galet ut...
P.s. Kristoffer: Hur nödvändigt är det att installera varnish om man inte har jättemånga besökare. Blir det snabbare överlag ändå? Är det lätt att installera? Har du tips på någon bra tutorial?
Kollade på www.varnish-software.com och de hade support för tusentals kronor... Låter ju på dem som om det krånglar mycket och krävs att det ständingt underhålls, kanske inte värt att försöka sig på det?
-----------------------------------------------------------
Filrättigheter för Drupal
Skapa ny användare utan lösen och hemma mapp:
adduser userA --no-create-home --disabled-login
Ställ dig i Drupal installationen för att sätta ägare till filerna för nyskapade användaren:
chown -R userA:www-data .
Sätter alla fil och mapp-rättigheter för användaren:
find . -type d -exec chmod u=rwx,g=rx,o= {} \;
find . -type f -exec chmod u=rw,g=r,o= {} \;
Listar alla filrättigheter:
ls -al
Ställ dig i sites-mappen för att sätta skrivrättigheter för files mappen:
find . -type d -name files -exec chmod ug=rwx,o= '{}' \;
for d in ./*/files
do
find $d -type d -exec chmod ug=rwx,o= {} \;
find $d -type f -exec chmod ug=rw,o= {} \;
done
När det är färdigt kommer mappar och filer ha följande filrättigheter, CHMOD
I mappen files och underliggande:
Foldrar: 770
Alla filer: 660
För filen settings.php: 640
Resten av filerna och mapparna för Drupal installationen:
Övriga mappar: 755
Filer: 640
// Mats
Bra lösning
Jag tycker dina inställningar låter som en bra lösning.
Och ang Varnish. Börja testa utan. Om server belastningen börjar kliva över 70-90% eller att du måste ha ut de extra millisekundrarna kan man testa det. En vanligt apache kan ju leverera +50 000 pageviews i timmen. Och då en välbesökt sajt har det antalet i månaden så borde det vara lugnt. Så test, mät, kolla tider kolla besökare, kolla laddtider osv. Google Analytics har ju mer stöd för just grafa laddningstiderna hos besökaren. Läste också nyligen en kommentar som berättade att visa en hemsida för användare är endast 30% av laddningstiden på serversidan, resten är på användarens sida med javascript och dyligt. Och det är ett påstående som jag själv kan se.
Statistik från Google Analytics på av våra hemsidor:
Page Load Time = 2,70s
Server Connection Time = 0,03s
Server Response = 0,25s
Page Download Time = 0,11s
Alltså, ladda klart hela hemsidan tar 2.7s. Av det består 0,03s för att ansluta till server, 0,25s att server genererar innehåll, 0,11s att ladda ner innehållet. Övrigt tid består av att webbläsaren presenterar hemsidan. Alltså 2,31s för att att css, bilder, facebook plugin och twitter flöden ska genereras upp.