Apache Veilig Maken

Inleiding

Apache Webserver is één van de meest gebruikte webservers, ter wereld.

De Apache Webserver staat vooral bekend om flexibiliteit en snelheid, veilig is vanuit de basis-installatie is echter minder goed geregeld.

Maar wees niet bang, met een paar simpele tips en gebruik van bepaalde Modules is Apache zeker goed te beveiligen. En ook geschikt te maken voor web applicaties die aan strenge veiligheidseisen moeten voldoen zoals Creditcard betaal systemen.

Een veilige webserver is nog geen veilig systeem.

Apache helemaal dichtspijkeren geeft geen garantie dat kwaadwillende hackers niet meer in je systeem kunnen komen. Naast het beveiligen van de webserver software is het zeker geen overbodige luxe om je systeem ook op andere punten te beveiligen.

Het installeren van de laatste veiligheidspatches (waaronder ook die van Apache zelf) is zeker aan te raden.

De standaard instellingen van Apache zijn gericht op een minimale veiligheid en om snel aan de slag te gaan. Vooral voor beginners is dit erg makkelijk, maar brengt ook enkele veiligheidsrisico's met zich mee.

Daarom zal ik in deze handleiding (proberen) uitleggen hoe je de Apache webserver software veilig(er) kunt maken.

Voor we beginnen.

Ik ga er vanuit dat je bekend met de terminal en editors, en dat je de minimale kennis hebt van Linux of BSD.

Ik beperk mij in deze handleiding enkel tot de installatie en configuratie van de Apache Webserver. Dingen als een HTTPS verbinding instellen laat ik achterwege. Hiervoor kan je beter de handleiding raadplegen of andere bronnen op internet.

Het is aan te raden om altijd de laatst stabiele versie te gebruiken en deze regelmatig bij te werken.

Als je gebruik maakt van een software systeem als apt-get of yum krijg je veelal de laatste versie automatisch binnen.

De eerste punten

Allereerst wil ik je waarschuwen dat je dit beter niet direct op een productiesysteem kunt toepassen. Test eerst alles goed op een apart systeem, voor je aan een productiesysteem begint!!

Het is niet gegarandeerd dat deze instellingen (altijd) werken, de auteur noch de PFZ verenging aanvaardt enige aansprakelijkheid. Gebruik op is geheel eigen risico!

Verberg alles wat gevoelig is

Apache toont standaard bij foutpagina's welke versie er wordt gedraaid, welke modules zijn geïnstalleerd en welke versie van die module en veelal ook welk besturingssysteem en versie.

Het is voor een kwaadwillend persoon nu heel makkelijk om te zien wat jij gebruikt, en als je het geluk hebt dat deze versie kwetsbaar is voor aanvallen.

Dus die informatie gaan we verbergen.

Het verbergen van deze informatie is GEEN is geen vrijbrief om de software niet bij te werken. Je maakt het voor de aanvaller, alleen moeilijker.

Zoek in httpd.conf de volgende regel en pas de waarde aan naar 'prod'.

ServerTokens prod

Met deze waarde wordt alleen de naam Apache, de hostname en port getoond.

Software pakketten hebben veelal een andere bestandsstructuur. Om de de juiste waarde zoeken voer dit commando uit in de terminal.

Let op dat example niet het juist bestand is. Als je problemen hebt raadpleeg dan de handleiding van leverancier of stel je vraag in het Forum van PFZ.

egrep 'ServerTokens .' /etc/* -R

Server Status/info handler

Apache biedt (mits geïnstalleerd) de mogelijkheid om een overzicht te zien van open verbindingen en de huidige server-status.

Zo iets als dit.

<Location /server-status>
    SetHandler server-status
    Order deny,allow
    Deny from all
    Allow from 127.0.0.1
</Location>

En

<Location /server-info>
    SetHandler server-status
    Order deny,allow
    Deny from all
    Allow from 127.0.0.1
</Location>

Nu zou je zeggen dat alles toestaan van de lokale host veilig is, toch? Helaas is dit niet geval, als de server meerdere websites hosts, kunnen deze ook de status door middel van een PHP of Perl script opvragen (draaien immers ook lokaal).

Maar wat biedt deze informatie nu precies? In de informatie staat vermeld wie wat opvraagt. En ook de volledige URL, met soms de sessionid of nog erger, een authenticatie token. En dat wil je liever niet.

En voor server-info geldt hetzelfde: deze pagina geeft een volledig overzicht van de huidige configuratie, dus ook welke modules en versies. Maar dat niet alleen, ook de VirtualHosts configuratie wordt hier getoond, in sommige gevallen staan hier wachtwoorden in voor Database authenticatie met HTTP-AUTH.

Verwijder deze configuratie-regels of stel ze in een veilig IP-adres zoals jouw werk-computer.

Een andere optie/toevoeging is om ze te beveiligen met een wachtwoord.

Allow from all

PHP

Ook de PHP versie kan gevoelige informatie vrijgeven.

Zoek de volgende waarde in php.ini En verander deze naar off.

expose_php Off

PHP blijft gewoon werken, maar zal niet worden weergeven in de X-Powered-By HTTP header. Als bonus bespaar je ook nog op dataverkeer.

En schakel dl() uit. Met deze functie kunnen bestanden worden geladen die mogelijk de kwaadaardige code kunnen uitvoeren.

dl() staat sinds de laatste PHP versies standaard uit en is in PHP5.3 niet langer beschikbaar.

enable_dl = Off

Het doel van het verbergen is om niet vrij te geven welke versie er wordt gebruikt.

Een andere tip maar helaas moeilijk te voorkomen is om geen phpinfo pagina publiekelijk te tonen. Echter is dit in het uiterste geval.

Installatie (Linux/BSD enkel)

Deze stap is alleen voor Posix gebaseerde systemen zoals Linux, BSD, Mac en Unix, etc...

In deze stap ga ik uitleggen hoe je de Apache installatie zelf goed kunt beveiligen. Dit lijkt misschien een beetje dubbelop maar installatie en configuratie staan los van elkaar.

Voor deze uitleg maak ik gebruik van de Apache handleiding. Te vinden op: [1]

Ga naar de map waar Apache is geïnstalleerd, meestal /usr/local/apache2 of /usr/apache2

En voer daar de volgende commando's uit (als root):

chown 0 . bin conf logs
chgrp 0 . bin conf logs
chmod 755 . bin
chmod 700 conf logs
 
chown 0 bin/httpd
chgrp 0 bin/httpd
chmod 511 bin/httpd

De Library en Executable bestanden moeten altijd onder de root gebruiker staan. Plaats deze nooit onder de zelfde gebruiker als waar Apache onder wordt gedraaid! Anders kunnen anderen de Apache installatie overschrijven!!

Als je Apache hebt geïnstalleerd via een software pakket kunnen de paden anders zijn. Veelal zijn deze installaties al goed ingesteld.

De conf directory op chmod 700: Zorg er voor dat alleen de gebruiker root de configuratie bestanden kan lezen en schrijven. Tip: door deze optie op de map zelf toe te passen kunnen andere gebruikers niet meer in de map komen. (let op: ontneem van de map ook de executable rechten voor public).

Web-bestanden onder de juiste gebruiker uitvoeren

Standaard voert Apache alle web-bestanden als HTML en PHP, uit onder één gebruiker. Veelal apache of www-data of zelfs nobody.

De hier beschreven methode werken alleen onder Posix gebaseerde systemen.

Ik ontraad met klem iedereen om Apache op Windows in productie te draaien, voor een test systeem is het prima te doen. Maar voor productie systemen is het gewoon niet mogelijk Apache veilig op Windows te (laten) draaien.

Als je persé Windows wilt/moet gebruiken voor productie kies dan voor MS Internet Information Server (IIS).

Het probleem

De methode van 'alle websites één gebruiker/eigenaar' kent een aantal grote problemen.

Als er meerdere websites op de server staan, draaien deze allemaal onder één gebruiker en kunnen dus ook elkaars bestanden lezen en (over)schrijven.

Voor alleen HTML pagina's is dit geen probleem, voor PHP en andere scrip/programmeertalen is dit echter een groot veiligheidslek.

Bestanden worden veelal met FTP 'wel' onder een aparte gebruiker geplaatst. Met als resultaat: gebruiker 'www-data' wil naar een map/bestand schrijven die met de FTP is aangemaakt als gebruiker-a.

Omdat de gebruiker www-data geen toegang heeft tot de bestanden van gebruiker-a krijg je een foutmelding over onvoldoende rechten.

De verkeerde oplossing

Maar ze hebben beide, wel dezelfde groep, namelijk www-data.

Daarom wordt helaas te vaak geadviseerd om de map op chmod 777 en bestanden op 666 te zetten. Met andere woorden, iedereen kan nu de bestanden lezen en overschrijven!

Nee maar dat is handig zeg, je hoeft nu maar één site hacken en je kunt alle andere websites gelijk overschrijven. - Deze simpele hack is al te vaak toegepast.

Dan kan je net zo goed alle bestanden onder één gebruiker plaatsen. Geen goede oplossing dus, hoe het wel moet vertel ik zo.

De goede oplossing

Gelukkig zijn er verschillende mogelijkheden die wel werken. Maar allemaal hebben zij één ding gemeen, zij voeren iedere website uit onder een andere gebruiker.

Samen met deze methodes is het verstandig om alle web-bestanden altijd te plaatsen onder chmod 600 en mappen als 700. Dit is ook in te stellen bij de FTP server zelf, hoe je dit doet kan je terug vinden in de handleiding van je FTP server.

Een betere oplossing is om gebruik te maken van umask, alle bestanden en mappen die dan worden aangemaakt hebben automatisch de juiste rechten.

umask lijkt op chmod maar werkt toch anders.

• umask Ubuntu man page

De volgende onderdelen beschrijven enkele oplossingen die beschikbaar zijn, welke voor jou het beste is ligt helemaal aan de situatie.

De veiligste optie is en blijft 'voor nu' om PHP uit te voeren via een Common Gateway Interface. Echter kleven hier wat nadelen aan, dus zoals ik al zei: Kijk wat voor jouw het beste werkt.

mod_suPHP

De eerste optie is mod_suPHP, deze voert het bestand uit onder een andere gebruiker door een apart PHP proces te starten buiten Apache om (CGI).

Voordelen:

• Makkelijk te installeren
• Een nieuwe PHP versie wordt direct actief zonder eerst Apache te moeten herstarten
• Actieve ontwikkeling
• Verbiedt gevaarlijke chmod-rechten.

Nadelen:

• PHP moet opnieuw gecompileerd worden als CGI versie, als je een script los wilt uitvoeren moet je dus twee installaties hebben.
• Doordat elke keer een nieuw proces wordt gestart ontstaat een vertraging
• Kan voor performance problemen zorgen

Website: http://www.suphp.org/Home.html

mod_ruid-ng

Een andere optie is om gebruik te maken van mod_ruid-ng.

mod_ruid-ng is een nieuwe versie van mod_ruid, welke door iemand anders dan de originele ontwikkelaar wordt onderhouden.

Mod_ruid-ng neemt het kind proces over en verandert de gebruiker van het proces naar een andere. Deze methode werkt erg goed en heeft geen snelheidsproblemen.

Bij het gebruik van mod-ruid-ng is het absoluut noodzakelijk om de dl() functie in PHP uit te schakelen. Gebruikers hebben via deze functie de mogelijkheid om een module laden waarmee actieve gebruiker aangepast kunnen worden (ook naar root).

Voordelen:

• Een gewone PHP installatie werkt gewoon, geen CGI versie nodig.
• Geen snelheidsvermindering
• Zeer makkelijke installatie

Nadelen:

• Momenteel is er geen controle om voor gevaarlijke bestandsrechten te waarschuwen.
• Omdat PHP word uitgevoerd als Apache Module kunnen veiligheidslekken in PHP Apache onveilig maken (up-to-date houden van Apache en PHP is een must!).

Website: mod_ruid-ng

Let op: Deze Module werkt alleen met Apache Prefork-MPM.

SuExec

Zelf biedt Apache ook een methode om bestanden onder een aparte gebruiker te draaien, namelijk met SuExec.

SuExec kan niet alleen worden gebruikt maar moet gebruikt worden in combinatie met een CGI Module als FastCGI of mod_cgid.

Fcgi

Fcgi, niet verwarren met FastCGI, is ook een optie, deze methode heeft veel weg van mod_suphp.

Echter heb ik (ook hier) geen ervaring mee, dus kan ik hier geen informatie over kwijt.

PHP-FPM

Dit is een nieuwe speler in de markt die ook standaard beschikbaar zal zijn bij PHP5.4.

I.p.v gebruik te maken van mod_php voor Apache, maakt deze gebruik van een CGI werking. Een groot verschil met mod_suphp is dat niet voor elke aanvraag een nieuw proces wordt gestart maar er wordt gewerkt met application pools.

De informatie op de website is wat mager en ik heb er nog weinig over gehoord.

PHP-FPM

--Rctweber 1 jul 2010 15:55 (CEST) Over een tijdje wil ik hier mee gaan experimenteren en kijken of het wat is, omdat Apache Worker-MPM sneller schijnt te zijn dan Prefork ben zeer benieuwd naar de prestaties.

PHP werkt alleen met Prefork.

Slot woord

Hopelijk heb je met deze tips een beeld gekregen hoe Apache beter te beveiligen. Uiteraard zijn er nog veel meer punten om de veilheid te verbeteren, vooral de handleiding heeft een paar handige tips.

In ieder geval veel succes.

Oorspronkelijk artikel door Sebastiaan Stok.