Efter installation?

.

Säkerhetstips

Några tips om vad man bör göra, ur säkerhetssynpunkt, efter en installation. Filer som kan raderas, filer som bör döpas om? Något med rättighetsinställningar på kataloger under roten som man bör tänka på?

Några saker att tänka på:

Börja med att säkra din webbserver:

Se till att webbservern äger filerna och ta bort onödig behörighet:

OBS: Byt www-data till din webbservers användarnamn och thomas till en grupp som bara du (eller andra betrodda) hör till.

Radera onödiga filer:

Döp om PHP-filer som inte behövs:

.

Placering av moduler och teman

När man lägger till moduler och teman var ska man stoppa dem? I rotkatalogerna modules themes eller ska man skapa modules och themes katalaoger under sites/default/all och lägga dem där? Var är det bäst att lägga dem ur säkerhetssynpunkt och där Drupal hittar dem?

Vi tillämpar följande princip:

• Moduler som laddas ned från D.o placeras i sites/all/modules. Detta gäller även om modulen behöver patchas så länge som patchen finns i modulens issue queue.
• Moduler som vi utvecklar själva och inte har hunnit släppa placeras i sites/default/modules. Om vi hackar en modul som är core eller contributed och inte postar en patch till modulens issue queue (händer endast i mycket speciella situationer) så placerar vi även den hackade modulen här.
• Theme engines placeras enligt samma princip som moduler.
• Teman som vi tar fram för en kund placeras i linje med ovaan i sites/default/themes. När vi går över till D6 kommer vi sannolikt att placera Zen, som vi numera ofta utgår ifrån, i sites/all/themes och det subtema vi tar fram till kunden i sites/default/themes.

.

Drupals säkerhet med anledning av Lullabot artikeln

Hur är det med Drupal ur säkerhetssynpunkt? Se t.ex. http://www.lullabot.com/articles/drupal-and-expressionengine-security-mo...

Artikeln handlar om den kulturella skillnaden mellan Drupal, som är ett fritt program med öppen källkod, och Expression Engine (EE), som är ett kommersiellt CMS utvecklat av EllisLab. Nate hade vid en utvärdering av EE för en kunds räkning noterat att det fanns viss antagonism mot Drupal på grund av påstådd bristande säkerhet. Som intäkt för påståendet togs det faktum att det under en period av 3 år finns 80 rapporterade säkerhetshål i Drupal och modulerna men bara ett i EE. Vi som dagligen är inne och "grottar" i Drupals kod vet att säkerheten är mycket hög, men vi vet också att det händer att man glömmer att köra användartillhandahållen data genom t.ex. check_plain() och andra funktioner avsedda för att förhindra XSS m.m. Därför var det inte Drupals siffra som var anmärkningsvärd utan EE:s. Nate ägnade därför en dag åt att hitta 3 EE säkerhetshål, varav en tillät att man exekverade valfri PHP-kod på servern(!!), vilka han rapporterade för att se vad som hände. Säkerhetshålen täppttes snabbt igen, men rapporterades aldrig. Resten av artikeln, och kommentarerna, handlar om varför det är att fördra öppenhet i säkerhetsfrågor. Jag vill i detta sammanhang passa på att nämna att EE är en mycket välskriven CMS som är mitt andrahandsval i fråga om CMS.

Jag anser att Drupal är ett av de säkraste CMS:erna. En styrka hos Drupal är det faktum att inte bara är core utan även moduler som är contributed omfattas av Drupals Security announcements. Lejonparten av säkerhetshålen som hittas finns i contributed-moduler och är oftast av lindrig art.

Thomas Barregren – Webbredaktören