P. 1
[Dutch] Raamwerk beveiliging webapplicaties, Govcert

[Dutch] Raamwerk beveiliging webapplicaties, Govcert

|Views: 1,222|Likes:
Published by Pascal Van Hecke
Whitepaper published by Dutch Governmental digital security watchdog Govcert.nl.
Gives a thorough overview of all aspects of Web application security.
Source: http://www.govcert.nl/render.html?it=146
Whitepaper published by Dutch Governmental digital security watchdog Govcert.nl.
Gives a thorough overview of all aspects of Web application security.
Source: http://www.govcert.nl/render.html?it=146

More info:

Published by: Pascal Van Hecke on May 17, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

10/26/2011

pdf

text

original

Sections

Deze paragraaf besteedt aandacht aan de maatregelen die een organisatie kan
treffen om netwerkbeveiliging voor webapplicaties in te richten. Aangezien het
netwerk een generiek ‘onderstel’ is voor alle mogelijke toepassingen zijn veel
maatregelen niet specifiek gericht op de beveiliging van webapplicaties maar meer
op de algemene beveiliging van de infrastructuur rondom de webapplicatie.

3.3.1

Besteed veel aandacht aan het DMZ-ontwerp

Een Demilitarised Zone (DMZ) is een apart stuk netwerk dat specifiek bedoeld is
om webapplicaties – en andere vanaf het internet bereikbare applicaties – in
onder te brengen. De DMZ vormt de koppeling tussen het internet enerzijds en
het interne netwerk anderzijds. Een veilige inrichting van de DMZ is daarom van
groot belang om te voorkomen dat kwaadwillenden via internet toegang krijgen
tot het interne netwerk van de organisatie.

8

De rulebase van een firewall beschrijft de verbindingen die een firewall toestaat. De rulebase bevat een lijst
met bronnen en doelen (IP-adressen) en toegestane poorten.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

18/116

Een aantal verschillende overwegingen moeten als input dienen voor het ontwerp
van de DMZ. Enkele belangrijke overwegingen die hierbij een rol kunnen spelen
zijn:

• Welke verkeersstromen zijn benodigd?
• Gaan we compartimentering toepassen (zie 3.3.2)?
• Welke typen applicaties willen we via de DMZ ontsluiten?
• Welke ondersteunende applicaties (bijvoorbeeld databases) hebben we
nodig voor het ontsluiten van deze applicaties?
• Hoe gaan we het verkeer richting deze applicaties door de DMZ routeren
(zie 3.3.3)?
• Waar en hoe koppelen we de DMZ aan internet?
• Waar en hoe koppelen we de DMZ aan de backoffice?
• Moeten de webapplicaties ook toegankelijk zijn vanuit onze backoffice (zie

3.3.4)?
• Hoe regelen we het beheer van de DMZ in (welke protocollen, welke
koppelingen, welke compartimenten, etc… - zie 3.3.5)?
• Gaan we een dual-vendor concept implementeren (zie 3.3.6)?

Figuur 3-2 beschrijft een voorbeeldinrichting van een DMZ. De DMZ heeft hierbij
een centrale ingang en een centrale uitgang. Daarnaast is te zien dat de DMZ
bestaat uit verschillende compartimenten die allen een andere gradatie (gekleurd
bolletje) hebben meegekregen. De komende paragrafen beschrijven deze
verschillende onderdelen in meer detail.

Figuur 3-2: inrichting DMZ

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

19/116

3.3.2

Pas compartimentering toe

Rondom de firewall(s) in de DMZ kan men segmenten of compartimenten creëren.
Uitgangspunt kan hierbij zijn dat applicaties en toepassingen van een gelijk
beveiligingsniveau in één gezamenlijk segment terecht komen. Zo komen
bijvoorbeeld web proxies in één segment, webservers voor internetsites in één
segment, webservers voor extranetten in één segment, databases in één
segment, etc… Door deze compartimentering toe te passen zorgt men ervoor dat
compromittering van een server of applicatie in een compartiment geen directe
gevolgen hoeft te hebben voor servers of applicaties in een ander compartiment.
Daarnaast kan men via deze compartimentering onderscheid maken in servers die
wel rechtstreeks vanaf internet bereikbaar zijn (bijvoorbeeld webservers) en
servers die dat niet zijn (bijvoorbeeld directory servers).

OPMERKING Voorkom te allen tijde dat webservers een rechtstreekse –
ongefilterde - verbinding hebben met de backoffice. Webservers die in de
backoffice geplaatst zijn, vormen een zeer ernstig beveiligingsrisico. Webservers
dienen daarom altijd via minimaal één firewall gescheiden te zijn van de
backoffice.

3.3.3

Leg routepaden vast

De vastgestelde compartimentering van de DMZ vormt de basis voor het opstellen
van routepaden. Een routepad beschrijft een toegestane verkeersstroom door de
DMZ. Figuur 3-2 geeft een voorbeeld van twee routepaden die de DMZ toestaat.
Verkeer richting een internetsite verloopt hierbij altijd via internet (rood), een
proxy segment (rood/oranje), een tussensegment (oranje) en het websegment
(groen). Verkeer richting een extranet volgt in grote lijnen dezelfde weg maar
maakt vanaf het tussensegment (oranje) eerst nog een afslag richting een
authenticatie- en autorisatiesegment (oranje/groen) alvorens bij de webserver te
geraken.

Door routepaden vast te stellen verzekert men zich ervan dat het omzeilen van
verplichte beveiligingsmechanismen niet mogelijk is. Daarnaast beschrijft men op
deze manier tevens een soort ‘template rulebase’ die de opzet van
verkeersstromen bepaalt voor nieuwe webapplicaties.

3.3.4

Bepaal de toegang tot de webapplicaties vanuit de backoffice

Veel van de webapplicaties die een organisatie ondersteunt, moeten ook
bereikbaar zijn vanaf het interne netwerk. Om deze koppeling tot stand te
brengen heeft men de beschikking over grofweg twee alternatieven:

• Routeer verkeer vanuit de backoffice via de internetkoppeling naar
internet en vervolgens weer terug naar de eigen DMZ. Bij dit alternatief
komt het erop neer dat men de webapplicaties vanuit de backoffice op
eenzelfde manier benadert als alle andere webapplicaties op internet. Een
argument dat tegen dit alternatief spreekt, is dat het onzinnig lijkt om

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

20/116

intern verkeer via het (externe) internet te routeren.

• Routeer verkeer vanuit de backoffice rechtstreeks naar de webservers in
de DMZ.

De keuze voor het tweede alternatief brengt een aantal beveiligingsrisico’s met
zich mee. Doordat een rechtstreekse koppeling ontstaat tussen het interne
netwerk en de DMZ, kan het gebeuren dat interne medewerkers mogelijke
beveiligingsbeperkingen die zijn opgelegd door componenten in de DMZ
(onbedoeld) omzeilen. Aangezien aanvallen op webapplicaties zeker ook intern
hun oorsprong kunnen vinden, is het van belang om de vastgestelde routepaden
ook voor intern verkeer te bekrachtigen. Hierdoor zal intern verkeer in grote lijnen
dezelfde weg moeten volgen als internetverkeer met als gevolg dat intern verkeer
op dezelfde plek de DMZ moet binnenkomen als regulier internetverkeer (op een
aparte tak op de buitenste firewall). Figuur 3-3 beschrijft de twee opties die in
deze paragraaf aan bod kwamen.

Figuur 3-3: interne/externe routering van webverkeer

Merk op dat in figuur 3-3 twee firewalls de werkstations in de backoffice en het
internet van elkaar scheiden. Wanneer de werkstations een rechtstreekse
verbinding met de buitenste firewall zouden hebben, zou namelijk een nieuw
beveiligingsrisico kunnen ontstaan. In dit geval zou er zich namelijk maar één
firewall bevinden tussen het internet en het interne netwerk waardoor eventuele
kwetsbaarheden en configuratiefouten op deze firewall tot grote
beveiligingsproblemen zouden leiden.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

21/116

3.3.5

Scheid beheer- en productieverkeer

In het DMZ-ontwerp van figuur 3-2 is een onderscheid gemaakt tussen een
‘productie’-gedeelte (oranje lijnen) en een beheergedeelte (grijze lijnen/zwarte
bolletjes). Het productiegedeelte is in feite het gedeelte van de DMZ waarop
verkeer vanaf internet terecht komt. Het onderscheid is aangebracht om te
voorkomen dat beheer- en productieverkeer door elkaar heen gaan lopen. Beheer
werkt vaak via webinterfaces en door beheer toe te staan via het
productiegedeelte loopt men het risico dat ook de bijbehorende webinterfaces en
andere beheervoorzieningen te benaderen zijn vanaf het internet.

Scheiding van beheer en productie betekent dat servers minimaal twee
netwerkaansluitingen krijgen: één voor aansluiting op het productiegedeelte en
één voor aansluiting op het beheergedeelte.

OPMERKING Het is belangrijk dat de compartimentering die is aangebracht in
het productiegedeelte ook terugkomt in het beheergedeelte. Is dit niet het geval
dan kan een kwaadwillende via het beheergedeelte de compartimentering alsnog
omzeilen.

Het beheernetwerk kan tijdens kantooruren ondersteuning bieden voor het
uitvoeren van reguliere beheerwerkzaamheden (bijvoorbeeld SSH-verbindingen
opzetten met systemen). Aangezien beheerwerkzaamheden ’s nachts meestal niet
plaatsvinden, kan men buiten kantooruren over dit netwerkgedeelte back-ups
laten lopen zonder daarbij het productieverkeer in de weg te zitten.

Een laatste belangrijk aandachtspunt is te bepalen hoe beheerders toegang
krijgen tot het beheergedeelte. Hiertoe bestaan verschillende mogelijkheden:

• Implementeer beheerclients in het beheergedeelte die alleen te gebruiken
zijn door er via een afgeschermde ruimte achter plaats te nemen. Beheer
over de omgeving kan alleen plaatsvinden via deze fysiek afgeschermde
beheerclients.
• Implementeer beheerclients in het beheergedeelte die op basis van een
remote interface (bijvoorbeeld Citrix of Microsoft RDP) te benaderen zijn
voor een beperkte groep werkstations in het backoffice LAN. Beheerders
maken vanaf hun werkstation in het LAN een verbinding met de
beheerclients en kunnen vervolgens via deze beheerclients het beheer
over de omgeving uitvoeren.
• Implementeer een apart beheer-LAN in het backoffice LAN en sta
verbindingen richting het beheergedeelte alleen toe vanuit dit beheer-LAN.

Afhankelijk van de inrichting van de infrastructuur van de organisatie bestaan er
uiteraard ook nog andere mogelijkheden om het beheer in te regelen.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

22/116

3.3.6

Overweeg de invoering van een dual-vendor concept

Door de centrale plaatsing van de firewall(s) kan een kwetsbaarheid op deze
firewall(s) grote gevolgen hebben (zie 3.2.4). Om de schade bij een dergelijke
kwetsbaarheid te beperken kan men overwegen een dual-vendor concept te
implementeren. Het dual-vendor concept houdt in dat twee firewalls de
netwerkbeveiliging in de DMZ uitvoeren en dat deze firewalls van verschillende
makelij zijn. In figuur 3-2 gebruikt het productiegedeelte van de DMZ twee
verschillende firewalls. Eén firewall is rechtstreeks aangesloten op internet, de
andere op de backoffice. Zouden deze firewalls van dezelfde makelij zijn dan zal
een potentiële kwetsbaarheid ook op beide systemen aanwezig zijn. Een
kwaadwillende kan hierdoor, na het compromitteren van de eerste firewall, op
eenzelfde manier mogelijk ook de tweede firewall compromitteren. Door
verschillende (merken) firewalls in te zetten voorkomt men dit.

OPMERKING Het toepassen van een dual-vendor concept hoeft niet automatisch
te betekenen dat men twee typen centrale firewalls in de omgeving plaatst. Dit
concept kan men bijvoorbeeld ook invullen door, naast de centraal geplaatste
firewalls, ook firewalls lokaal op de machines te installeren. Tools als ipfilter,
ipfw en iptables bieden hiertoe mogelijkheden. Zie hoofdstuk 4
(“Platformbeveiliging”) voor meer informatie over dit type firewalls.

3.3.7

Behoud overzicht

Het is belangrijk dat beheerders overzicht behouden over de verkeersstromen die
de firewall toestaat. Bij nieuwe verkeersstromen moet de beheerder de
bijbehorende toegangsregels efficiënt inpassen in de bestaande rulebase.
Projecten moeten daarnaast een helder en gefundeerd overzicht aanleveren van
de verkeersstromen die de te implementeren webapplicatie nodig heeft. Het
gebruik van speciaal daartoe ontwikkelde ‘verkeersoverzichten’ kunnen hieraan
een bijdrage leveren. Een voorbeeld van een dergelijk verkeersoverzicht is
weergegeven in figuur 3-4.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

23/116

Figuur 3-4: voorbeeld verkeersoverzicht

Het verkeersoverzicht bevat ten eerste alle firewalls en servers die betrokken zijn
bij het aanbieden van de webapplicatie. Dit betekent dat naast de webserver ook
andere servers waarvan de webapplicatie gebruik maakt (zoals databaseservers),
onderdeel uitmaken van het verkeersoverzicht. Vervolgens tekent men de
verkeersstromen tussen de componenten in. Hierdoor ontstaat een overzicht van
de regels die op de firewalls benodigd zijn om de webapplicatie te kunnen laten
functioneren.

Daarnaast dient men wijzigingen op de firewall gecontroleerd door te voeren.
Inpassing van firewallwijzigingen in een bestaand proces van wijzigingsbeheer
(change management) is ideaal.

OPMERKING Nog meer voorzichtigheid is vereist bij het doorvoeren van
infrastructurele wijzigingen. Het aanbrengen van bijvoorbeeld nieuwe
verbindingen tussen netwerkcomponenten kan ervoor zorgen dat routepaden en
compartimenteringen plotseling (in negatieve zin) wijzigen.

3.3.8

Breng fysieke scheiding aan

Door veel aandacht te besteden aan de inrichting van de DMZ (zie 3.3.1) ontstaat
een logische scheiding van netwerksegmenten rondom de firewall(s). Deze
logische scheiding hoeft niet per definitie ook een fysieke scheiding van
netwerksegmenten te betekenen. Verschillende netwerkcomponenten, servers en
andere apparatuur kunnen immers wel zijn aangesloten op dezelfde switch of hub
waardoor een fysieke koppeling ontstaat. Door deze fysieke koppeling tussen
componenten is het in sommige gevallen mogelijk om de logische segmentering
van het netwerk via deze netwerkcomponenten te omzeilen.

Het risico dat kwaadwillenden in staat zijn om via fysieke (laag 2) koppelingen de
logische (laag 3) segmentering te omzeilen, is in de praktijk vrij klein. Een kleine

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

24/116

ingreep op de belangrijkste ingangspunten van de DMZ voorkomt dit echter. In
figuur 3-5 is (rechts) een voorbeeld opgenomen van een fysieke scheiding tussen
twee belangrijke segmenten. Daarnaast is in het figuur ook het verschil
weergegeven met een situatie waarin wel één fysiek segment bestaat (links).

Figuur 3-5: fysieke scheiding van segmenten

Een fysieke scheiding kan men ook realiseren door (reverse) proxies inline te
plaatsen. Dit betekent dat de proxies twee interfaces krijgen: één interface voor
de buitenkant en één interface voor de binnenkant. Al het verkeer van en naar de
webapplicatie is in dit geval verplicht om via de proxy te lopen. Het nadeel van
een dergelijke plaatsing van een proxy is dat alle applicaties via deze proxy
moeten verlopen waardoor men afhankelijk is van ondersteuning van de proxy
voor het specifieke type verkeer (bijvoorbeeld een HTTP-proxy voor webverkeer,
een SMTP-proxy voor e-mailverkeer, etc…). De mogelijkheid tot het inline
plaatsen van een proxy is dan ook zeer afhankelijk van de andere typen
applicaties die de organisatie via de DMZ ontsluit. Meer details over (web) proxies
kunt u terugvinden in het hoofdstuk over applicatiebeveiliging (hoofdstuk 5).

OPMERKING Ook bij het gebruik van inline proxies is het van belang dat de twee
interfaces gebruik maken van verschillende switches. Plaatst men de
componenten uit de compartimenten die de proxy van elkaar scheidt in dezelfde
switches, dan ontstaat alsnog hetzelfde probleem als uit figuur 3-5 (links).

3.3.9

Implementeer maatregelen tegen (D)DoS

Het whitepaper “Aanbevelingen ter bescherming tegen Denial-of-Service-
aanvallen” (DDoS-GOVCERT, 2005) beschrijft een aantal maatregelen die een
organisatie kan treffen om zichzelf tegen (D)DoS-aanvallen te beschermen. De
maatregelen die dit whitepaper voorstelt, zijn hieronder kort samengevat:

• Maak gebruik van anti-spoofingmechanismen:

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

25/116

o Unicast Reverse-Path Forwarding (uRPF); URPF controleert op een
interface of een IP-pakket afkomstig is van een source IP-adres dat
volgens de routeringstabel bereikbaar is via de betreffende interface.
o Bogon lists; via bogon lists kan men IP-adressen die nog niet door
IANA zijn uitgegeven blokkeren.
o Access Control Lists (ACL); reguleren dataverkeer op basis van
bijvoorbeeld IP-adres of poortnummer.

• Zet firewalls in.
• Harden systemen. Met name het ‘tunen’ van de TCP/IP-stack kan helpen in
het beveiligen tegen (D)DoS-aanvallen.
• Besteed aandacht aan de netwerkomgeving.
• Maak afspraken met (hosting) providers.
• Monitoor de infrastructuur zodat detectie van (D)DoS-aanvallen mogelijk

is.

3.3.10

Harden de (externe) DNS-infrastructuur

Door de vitale rol die DNS speelt in het bereikbaar houden van webapplicaties, is
het belangrijk dat het aspect beveiling bij de inrichting van DNS-services voorop
staat. Enkele aandachtspunten die van belang zijn bij het beveiligen van DNS:

• Beperk de (bron) IP-adressen die zone transfers mogen uitvoeren met de
DNS-server. Alleen primaire en secundaire DNS-servers zouden hiertoe
gerechtigd mogen zijn.
• Sta via de firewall alleen verkeer toe richting 53/udp. Vrijwel alle DNS-
verzoeken maken gebruik van UDP. Alleen bij zeer grote verzoeken en
zone transfers zal DNS overschakelen op het gebruik van TCP. Door 53/tcp
te blokkeren in de firewall, voorkomt men dat willekeurige IP-adressen in
staat zijn om zone transfers uit te voeren.
• Maak gebruik van meerdere authoritieve DNS-servers voor een zone.
• Verwijder onnodige records uit de zone. Onnodige records (bijvoorbeeld
HINFO- en TXT-records) zijn niet benodigd en leveren een kwaadwillende
alleen extra informatie.

MEER INFORMATIE Het National Institute of Standards and Technology (NIST)
heeft een zeer omvangrijk document geschreven over de manier waarop men
DNS kan beveiligen. Dit document kunt u vrij downloaden vanaf de website van
NIST: http://csrc.nist.gov/publications/nistpubs/800-81/SP800-81.pdf

3.3.11

Harden ook de rest van de infrastructuur

De vorige aanbeveling (3.3.10) beschreef de specifieke hardening van DNS-
servers. Hardening is een begrip dat bij de inrichting van webomgevingen op elk
component van toepassing is. Daarom moeten ook firewalls, switches, routers en
andere netwerkcomponenten deel uitmaken van het hardeningsproces.
Onderstaand volgen enkele voorbeelden van mogelijke hardeningsmaatregelen op
netwerkniveau:

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

26/116

• Sluit beheermogelijkheden zoveel mogelijk af. Biedt webinterfaces alleen
aan via beheersegmenten.
• Maak alleen gebruik van versleutelde beheermechanismen. Maak dus
bijvoorbeeld gebruik van Secure Shell (SSH) in plaats van Telnet en
Secure Copy (SCP) in plaats van File Transfer Protocol (FTP).
• Sta beheer alleen toe vanaf vooraf gedefinieerde IP-adressen.
• Maak gebruik van complexe wachtwoorden en/of sterke
authenticatiemechanismen voor het uitvoeren van beheer op de
componenten.
• Maak gebruik van logon banners. Een logon banner verschijnt op het
moment dat een gebruiker een beheersessie opstart met een
netwerkcomponent. Deze banner bevat een waarschuwing die de
toegangsvoorwaarden tot het systeem beschrijft. De banner kan daarnaast
waarschuwen voor juridische acties wanneer de gebruiker misbruik van
het systeem maakt.
• Harden het onderliggende besturingssysteem. Veel leveranciers leveren
netwerkcomponenten in de vorm appliances9

waarop weinig extra

hardeningsmaatregelen mogelijk zijn. In de gevallen dat een
netwerkcomponent echter niet gebaseerd is op een appliance, is het van
belang dat men het onderliggende systeem ‘hardent’. Meer hiervoor kunt u
vinden in hoofdstuk 4: platformbeveiliging.
• Besteed voldoende aandacht aan de beveiligingsconfiguratie van
veelgebruikte netwerkservices en -protocollen: Simple Network
Management Protocol (SNMP), Network Time Protocol (NTP), SYSLOG,
Trivial FTP (TFTP), finger en routeringsprotocollen zoals Border Gateway
Protocol (BGP) en Open Shortest Path First (OSPF).
• Schakel alle ongebruikte protocollen, services en netwerkpoorten uit.
Voorbeelden van protocollen die veelal standaard zijn aangeschakeld op
netwerkcomponenten maar in veel gevallen niet benodigd zijn, zijn Cisco
Discovery Protocol (CDP) en Spanning Tree Protocol (STP)
• Maak op switches gebruik van Virtual LAN’s (VLAN) en beperk de toegang
tot netwerkpoorten op basis van MAC-adres (port security).

MEER INFORMATIE Via internet zijn een groot aantal templates en
handleidingen te vinden die ingaan op het beveiligen van specifieke protocollen of
services. Hieronder vindt u een kleine greep uit een aantal interessante artikelen
op dit gebied:

• On the Vulnerabilities and Protection of OSPF Routing Protocol (NCSU):
http://www.cs.ucsb.edu/~rsg/Routing/references/wang98vulnerability.pdf
• Secure BGP Template (Cymru Team):
http://www.cymru.com/Documents/secure-bgp-template.html
• Securing Cisco Routers (SANS/GIAC):
http://www.giac.org/practical/GSEC/Nicholas_Vigil_GSEC.pdf

9

Een appliance is een deels voorgeconfigureerde machine met een specifieke functionaliteit (bijvoorbeeld
firewalling, routing, switching) en gelimiteerde toegang tot het besturingssysteem

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

27/116

• Secure IOS Configuration Template (Cymru Team):
http://www.cymru.com/Documents/secure-ios-template.html
• Secure Network Infrastructure and Switched Networks (SANS):
http://www.sans.org/reading_room/whitepapers/basics/451.php

3.3.12

Besteed aandacht aan beschikbaarheidvraagstukken

Door de belangrijke rol die het netwerk speelt als ‘onderstel’ van de
webapplicaties is het van belang dat het netwerk te maken krijgt met een
minimum aan storingen. Het ontwerp van het netwerk dient daarom zodanig te
zijn dat deze zo min mogelijk (liefst geen) Single Points-of-Failure (SPOF) bevat.
Load balancing en redundantie zijn twee technieken die een organisatie kan
inzetten om de beschikbaarheid van de infrastructuur te vergroten. De volgende
twee paragrafen beschrijven deze twee technieken in meer detail.

3.3.12.1

Maak gebruik van load balancing technieken

Load balancers kunnen verkeer richting een webapplicatie over verschillende
gelijkwaardige componenten verdelen. Voor webapplicaties bestaan twee
belangrijke load balancing technieken:

• Local Server Load Balancing (LSLB); een ‘LSLB load balancer’ verdeelt
verkeer lokaal (dat wil zeggen binnen hetzelfde datacenter) over
verschillende webservers. Uitval van een webserver zal in dit geval niet
per definitie leiden tot het niet meer beschikbaar zijn van de website.

• Global Server Load Balancing (GSLB); een ‘GSLB load balancer’ is een
stuk complexer dan een ‘LSLB load balancer’ en heeft als doel om load
balancing uit te voeren over geografisch gescheiden locaties. DNS-
functionaliteit is een mechanisme om GSLB voor webapplicaties te
bewerkstelligen. De ‘GSLB load balancer’ is hierbij autoritief voor de zone
waarin de webapplicatie zich bevindt en fungeert voor deze zone als DNS-
server. Door verzoeken voor de zone te beantwoorden met steeds
wisselende IP-adressen komen gebruikers uit op de verschillende
geografisch gescheiden locaties. Deze aanpak verschilt van de standaard
Round Robin (RR) functionaliteit in DNS omdat GSLB rekening houdt met
de load die een bepaalde locatie op dat moment ondervindt en de
beschikbaarheid van deze locatie. Valt een geografische locatie
bijvoorbeeld uit dan zal de ‘GSLB load balancer’ de bijbehorende IP-
adressen niet meer uitdelen. Bij gebruik van RR-DNS zal de DNS-server
het IP-adres van de uitgevallen server gewoon blijven retourneren omdat
de DNS-server geen middelen heeft om te achterhalen of de betreffende
webserver nog bereikbaar is.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

28/116

Figuur 3-6: voorbeeldinrichting GSLB

In figuur 3-6 is een voorbeeld opgenomen van de inrichting van een GSLB-
oplossing. Hierbij is te zien dat de ‘GSLB load balancers’ status informatie
over een locatie krijgen via lokale ‘LSLB load balancers’. Op basis van deze
statusinformatie en polling-gegevens besluit de GSLB load balancer om
een bepaald IP-adres te koppelen aan een DNS-verzoek van een client.

Door de afhankelijkheid van GSLB-oplossingen van DNS kan dit in de
praktijk tot problemen leiden. Zo gebruiken GSLB-oplossingen een zeer
kleine Time-to-Live (TTL) voor DNS-records. De lengte van de TTL bepaalt
hoe lang componenten (werkstations, DNS caching servers, etc…)
opgevraagde DNS-informatie mogen bewaren. Internet Service Providers
(ISP’s) kunnen ervoor kiezen om deze TTL te negeren en een standaard
TTL van 24 uur aan te houden. In dit soort gevallen werkt de oplossing
niet goed voor klanten die zijn aangesloten via deze provider omdat deze
providers DNS-records minimaal 24 uur cachen. Hierdoor duurt het
mogelijk 24 uur voordat een uitgevallen locatie niet meer wordt
geadverteerd richting clients. Bij de keuze voor een GSLB-oplossing is het
raadzaam voldoende aandacht te besteden aan deze factoren.

3.3.12.2

Voer centrale componenten redundant uit

Centrale componenten in de infrastructuur kan men redundant uitvoeren zodat zij
geen Single Point-of-Failure (SPOF) vormen. Veel netwerkcomponenten bieden
standaard ondersteuning voor redundantie en bijbehorende statussynchronisatie.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

29/116

Componenten (op netwerkniveau) die met name in aanmerking komen voor
redundante uitvoering zijn:

• Communicatieverbindingen;
• Firewalls;
• Load balancers;
• Proxies;
• Routers;
• Switches.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

30/116

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->