De allerpopulairste methode voor een bedrijf om zich te profileren op het internet is wel de uitbouw van een eigen website. Internetvandalen kunnen echter ook misbruik maken van webservers. In dit artikel bekijken we welke dreigingen er zoal zijn en wat u ertegen kan doen.
Laten we even vooropstellen dat elke server aangevallen kan worden vanaf het internet met de bedoeling zijn dienstverlening te onderbreken: de server in zijn geheel te doen platvallen of crashen, bijvoorbeeld, of alleen een welbepaalde dienst zoals e-mail of webaanbod uitschakelen. Zoiets noemt men een ‘Denial of Service’- of kortweg DoS-aanval. Omdat dit niet specifiek op webservers slaat maar op zowat alle servers, komen we daar later op terug, als we het beveiligen van een netwerk tegen vandalisme behandelen. In verband met webservers en meer algemeen websites zijn er in essentie drie mogelijke categorieën van beveiligingsproblemen:
1) gewijzigd dienstenaanbod; 2) privacy-inbreuken; en 3) misbruik van vertrouwen.
U merkt dat dit heel algemeen geformuleerd is en in feite zijn deze drie categorieën ook van toepassing op andere soorten servers dan webservers. Net zoals bij e-mail zijn misbruiken van een webserver of uw website mogelijk van binnen uw bedrijf (door eigen personeel) als van buiten uit (door vandalen), maar dat neemt niet weg dat her soort misbruiken dat zij plegen wel ondergebracht kan worden in de voornoemde drie categorieën. Voorlopig sluiten we ook even uit dat een server meerdere diensten kan aanbieden, waaronder ook diensten die men nogal eens ‘vergeet’. Zo heeft een webserver meestal ook ftp aan boord, en is het best mogelijk dat de systeembeheerder vergat die ftp-dienst te beveiligen.
Gulden regel
Een gulden regel is dan ook voor eender welke server dat u bepaalt welke diensten deze mag aanbieden en dan al het andere uitschakelt of uitsluit. Kijk bij de installatie van een dienst of een server de standaardinstellingen altijd na en schakel uit wat u niet nodig heeft. Vergeet ook niet overal standaardwachtwoorden te veranderen!
Gewijzigd dienstenaanbod
Onder een gewijzigd dienstenaanbod verstaan we dat een server niet of niet meer de door ons gewenste diensten aanbiedt. Dat kan betekenen dat diensten niet meer beschikbaar zijn, maar ook dat ze wel nog beschikbaar zijn maar qua inhoud iets anders laten zien dan de bedoeling is. Dat een dienst niet meer beschikbaar is, zal gewoonlijk het gevolg zijn van een DoS-aanval en daarop komen we zoals gezegd in een volgend artikel terug. Dat de inhoud van de aangeboden dienst gewijzigd werd, is een kwestie van inbraak of kaping van de site. Bij elk webaanbod geldt, dat de ontwerper of aanbieder van de webinhoud in staat moet zijn om die inhoud te wijzigen, te wissen of nieuwe inhoud te creëren. Daartoe heeft een webserver extra diensten aan boord (zoals ftp) om de inhoudsleverancier toe te staan deze inhoud te bepalen. Helaas betekent dat ook, dat een hacker gebruik kan proberen te maken van deze extra diensten om zelf wijzigingen in de inhoud aan te brengen. Het is dus absoluut noodzakelijk dat u het aantal diensten bedoeld voor het onderhoud van de website strikt beperkt in aantal, maar ook in toegankelijkheid. Alles hoort dus beveiligd te zijn met een gebruikersnaam en -wachtwoord.
Webkaping
Als een hacker niet direct rechtstreeks op de server de inhoud kan wijzigen, dan is een andere populaire techniek het kapen van een site. U kunt zich een websitekaping het eenvoudigst voorstellen als volgt: de hacker versiert een eigen webserver met de gewenste inhoud en zorgt er dan voor dat als een gebruiker de oorspronkelijke website opvraagt, hij in plaats daarvan het systeem van de hacker contacteert en dus de inhoud te zien krijgt die deze hacker bepaalt. Dergelijke kapingen hebben meestal te maken met het inbreken in en wijzigen van de DNS-servers (DNS = Domain Name Service). Deze servers zorgen voor de vertaling van voor de mens makkelijker te onthouden domeinnamen (zoals www.diskidee.be) naar een numeriek ip-adres, wat in feite het echte adres op internet is waarmee de computers werken. Normaal wijzen www.diskidee.be en www.diskidee.nl naar het ip-adres 194.7.249.240, maar als een hacker erin zou slagen de DNS-server te laten wijzen naar zijn eigen ip-adres, dan zou u iedere keer dat u DiskIdee opvraagt een pagina vanaf de server van de hacker te zien krijgen in plaats van het echte DiskIdee-ezine. Net zoals andere servers dienen dus ook DNS-servers beveiligd te zijn tegen ongeoorloofde toegang van buitenaf. Ook hier bereikt u dat door alle andere diensten (onder meer ftp en telnet) uit te schakelen of die tenminste niet voor jan en alleman bereikbaar te maken, en door alle andere tcp-poorten te blokkeren. Dat laatste doet u met behulp van een firewall. Het blokkeren van door u niet gebruikte poorten is noodzakelijk om te voorkomen dat een hacker ze zou gebruiken om via eigen software zichzelf toegang te verschaffen tot het systeem. Achterdeursoftware zoals Back Orifice is daar een berucht voorbeeld van. Een firewall sluit die mogelijkheden echter uit.
Access scope
Voor de wel beschikbare diensten is een vrij makkelijk te implementeren manier van beveiligen het beperken van de toegangsruimte. De Amerikanen spreken hierbij van ‘access scope’ en het slaat op het definiëren van wie toegang heeft tot bepaalde servers of diensten en wie niet, meestal naargelang ip-adres of internetdomein of -subdomein. Voor een vrij beschikbare http-dienst zoals die voor uw website of -server legt u natuurlijk geen toegangsruimte op, maar dat doet u wel voor de diensten waarmee u het onderhoud van die webpagina’s verzorgt. Er bestaan heel wat hulpprogramma’s waarmee u toegangsruimtes kunt onderzoeken en vastleggen. Een heel interessant en gratis hulpprogramma in verband hiermee is Cheops, maar dat is wel bedoeld voor Linux – niet voor Windows.
Privacy-inbreuken
Hiermee bedoelen we niet noodzakelijk dat uw systeem gevoelige data over gebruikers en klanten vrijgeeft (al zou dat natuurlijk ook kunnen), maar wel meer algemeen dat uw systeem meer data vrijgeeft dan de bedoeling is. Vooral bij webservers en websites is dit een vrij vaak voorkomend euvel. Stel dat op een webserver data opgeslagen werd die alleen maar toegankelijk mag zijn voor bepaalde gebruikers (al dan niet met een wachtwoord). Het zou niet de eerste keer zijn dat een willekeurige gebruiker toegang kan krijgen tot deze bestanden door gewoon een rechstreeks pad naar de bestanden op te geven in de http-string van zijn webbrowser. Zoiets als (het fictieve adres) http://www.bedrijf.be/polissen/secure/private/ bijvoorbeeld. Als dit toegang geeft tot de bewuste bestanden, heeft u een groot probleem. We spreken hierbij over het opslaan van privégegevens in publiek toegankelijke directory’s. Met het oog op veiligheid is het sowieso een slecht idee om data op een webserver op te slaan. Gebruik een webserver bij voorkeur alleen voor het weergeven van al dan niet dynamisch samengestelde webpagina’s en laat deze zijn data van een andere en beveiligde database- of fileserver op het netwerk halen. Stel de webserver zo in, dat alleen maar data getoond mag worden van een door u op geven index of inhoudstabel van webpagina’s. Elke andere toegang tot data op het systeem moet dan verboden zijn. Met de Apache webserver kunt u dit bijvoorbeeld vrij makkelijk instellen. Hou er ook rekening mee dat sommige gebruikers kunnen proberen uit de door hen toegewezen http-directoryboom te geraken door met behulp van speciale tekenreeksen zoals ‘..’ te trachten in een hogere directory uit te komen. Ook zoiets moet dus onmogelijk gemaakt worden.
Misbruik van vertrouwen
Nee, niet van u – dat zou immers geen technisch probleem zijn. Het gaat om misbruik van het vertrouwen van de software in andere software. Nogal wat webservers maken immers gebruik van speciale scriptingsoftware om webpagina’s geheel of gedeeltelijk dynamisch samen te stellen. Maar al te vaak gaat de webserver er gewoon van uit, dat de parameters van die scriptingsoftware per definitie geldig en te vertrouwen zijn. De meestgebruikte scriptingsoftware voor webservers is natuurlijk CGI, maar daarnaast kennen we ook ASP en PHP. JavaScript is ook een scripttaal, maar die draait aan de gebruikerskant, niet op de webserver. U maakt het wel heel makkelijk voor een hacker als de webserver de scriptingopdrachten inclusief alle parameters gewoon aan de gebruiker toont via zijn webbrowser. De hacker kan dan daarmee moeiteloos uit de voeten om allerlei varianten uit te proberen. Stap één is dit uitschakelen. Uw webserver hoort gewoon die opdrachtenstrings voor scriptprocessoren niet te tonen aan de gebruiker via diens webbrowser. Tijdens de ontwikkelingsfase van de website kunt u dat wel toestaan om u te helpen de werking van het geheel behoorlijk te verifiëren, maar uiteindelijk moet dat dus uitgeschakeld zijn. Stap twee is de aanvaarding van een scriptopdracht met parameters: uw systeem mag die alleen maar aanvaarden als de opdracht afkomstig is van een bron binnen uw beschermd netwerk en moet die weigeren als de opdracht afkomstig is van buiten uw eigen netwerk. Het is dus niet voldoende alleen te controleren op de geldigheid van de http-string HTTP_REFERER (die geeft aan waar een http-aanvraag vandaan kwam): het is immers niet moeilijk om bij een http-aanvraag die string eender welke gewenste waarde te laten aannemen en u zou dus bedrogen uitkomen als u op deze string zou vertrouwen om te bepalen of een aanvraag van binnen uw eigen netwerk komt of niet.
