Index | Geschiedenis | Cursus IP | Intranet | Security | Firewall | Management | Voip | Html | Faq's
Inleiding | Risico's | Tools | Firewall | Overzicht virussen
Google

Index

Ga naar de homepage. Ga naar het begin van de pagina.

Inleiding

Wat is een firewall. Een firewall is een scheiding in een netwerk die ervoor zorgt dat de communicatie tussen deze netwerken op een gecontroleerde manier plaatsvindt. We kennen dit fenomeen hoofdzakelijk uit koppelingen naar het internet, maar je kunt je ook voorstellen dat firewalls intern, binnen "intranetten" gebruikt worden om delen van het netwerk af te schermen.
De basis van de beveiliging wordt gelegd in een security policy. M.a.w. je zult eerst moeten definieren wat er toegestaan is en welke procedures er gevolgd moeten worden. Een dergelijke policy kun je echter slechts implementeren door het creeren van een voldoende draagvlak binnen de organisatie. Immers als er geen begrip is voor de gestelde maatregelen, dan zullen gebruikers er alles aan doen deze maatregelen te omzeilen. Beter is het in een dergelijk geval te kijken wat de gebruiker voor functionaliteit nodig heeft en daar te zoeken naar een voor alle partijen acceptabele oplossing.
In dit verhaal zullen we ons echter beperken tot de technische kant van het verhaal en voor een aantal scenario's een oplossing zoeken (wellicht dat ik later een verkorte vorm van de organisatorische kant toevoeg). Let wel, net zoals bij het intranet, is de mate van beveiliging mede afhankelijk van het beschikbare budget voor de hardware, het beheer (en hiermee het verhogen van het interne kennis nivo) en de gewenste / eiste functionaliteit. Aan de kosten kant moet je echter ook denken aan de kosten die het uitvoeren van extra maatregelen (door het dalen van de productiviteit bijvoorbeeld) kosten.

Tot slot.
Er bestaat niet zoiets als totale veiligheid en wat nu wellicht veilig is, kan morgen een groot risico zijn. Ga naar de homepage. Ga naar het begin van de pagina.


Een eenvoudige firewall voor http, ftp en pop3 email verkeer.

We beginnen met de eenvoudigste setup van een firewall, waarbij meerdere gebruikers gelijktijdig kunnen surfen (ftp en http) en hun email kunnen ophalen. We gaan er hierbij vanuit dat er vooralsnog gebruik gemaakt wordt van een dialup account (via de telefoon, ADSL of de kabel) waarbij we door de provider iederekeer een ander IP adres toegewezen krijgen.

Ook bij een dergelijke eenvoudige opzet, hebben we al de keuze uit een aantal scenario's. Op het eerste gezicht lijkt het simpel, maar ook hier kunnen we (en moeten we) kiezen.

    Ga naar de homepage. Ga naar het begin van de pagina.
  1. Een firewall met adrestranslatie mogelijkheden
    Dit is verreweg de eenvoudigste oplossing. Hoe werkt het?

    Een voorbeeld van een (firewall) koppeling op het internet op basis van adrestranslatie.

    Voor de gebruikers lijkt het of ze een direkte internet connectie hebben. Immers ze kunnen vanaf hun pc surfen en mail downloaden zoals ze dat vroeger deden. In de achterliggende techniek gebeurt het volgende. Op het moment dat de firewall een connectie opbouwt, zal hij op zijn externe interface een IP adres toegewezen krijgen. We noemen dit adres "ip-ex". Aan de intranet zijde van het netwerk, had hij reeds een ip adres. Voor de interne routers staat een zogenaamde default route (zie begrippenlijst) gedefinieerd naar de interne interface van de externe router (of hij is de default gateway voor de werkstations die zowiezo het verkeer voor zijn kiezen krijgt).
    Door het gebruik van de adrestranslatie en het feit dat sessies slechts van binnen naar buiten gestart (kunnen) worden, kunnen hiermee actieve inbraken van buiten direkt naar binnen voorkomen worden. Hackers kunnen echter wel proberen in te breken op de firewall, die daartegen beschermt dient te worden m.b.v. een afdoende afscherming (via packet filtering o.i.d.).
      Aandachtspunten
    • Eenvoudige snelle te implementeren oplossing ook op eenvoudige dialup verbindingen.
    • Transparant voor achterliggende applicaties, voor zover deze door de adrestranslatie module ondersteund worden.
    • Geen controle op data die het netwerk binnen komt (programma's virussen etc)
    • Ondersteunde protocollen afhankelijk van de ondersteuning in de adrestranslatie module van de firewall (simpele adrestranslatie of vele modules voor de diverse protocollen.
    • Sterkte van de beveiliging mede afhanekelijk van de robuustheid van de firewall tegen inbraakpogingen.
    • De mail blijft bij dergelijke implementaties bij de ISP (internet service provider) en wordt m.b.v. pop3 door de interne clients opgehaald. Voor het versturen kan tevens gebruik gemaakt worden van de smtp mailserver van de provider. Deze weet niet beter, of de mail wordt gehaald en verstuurd door de firewall.
    Ga naar de homepage. Ga naar het begin van de pagina.
  2. Een oplossing met proxies op de firewall die voor de connectie zorgen.
    Waarom zouden we proxies gaan toevoegen? Proxies werken op applicatie nivo en bieden afhankelijk van het type wat je gebruikt een aantal mogelijkheden. Ik zelf maak momenteel gebruik van de proxy mogelijkheden in de Apache webserver, een heel eenvoudige proxyfunctie met "slechts" een caching functie. Daarnaast biedt de proxyserver uitgebreide logging functies, waardoor het troubleshooten van gebruikers vereenvoudigd wordt. Voor de wat grotere netwerken die meer controle willen is wellicht meer functionaliteit vereist.

    Een voorbeeld van een koppeling naar het internet via een proxyserver op de firewall.

    Voor een uitgebreidere beschrijving van de mogelijkheden en toegevoegde waarde van een proxyserver, ga ik in de rest van dit verhaal uit van de Netscape (tegenwoordig Iplanet) proxyserver. Kijk voor meer info op http://docs.iplanet.com/docs/manuals/proxy.html .

    Voorwaarde voor het gebruik van de proxyserver is wel, dat de applicaties die gebruikt worden om te server de instelling van een proxyserver ondersteunen. Dit is voor de "standaard" browsers van o.a. Netscape en MS geen probleem echter als applicaties specifieke ftp agenst gebruiken, kun je tegen een probleem aanlopen.

    Wat kunnen we met deze proxyserver wat we hiervoor niet konden?

    • 1 weg naar buiten. We kunnen alle gebruikers via 1 gecontroleerde weg naar buiten laten gaan. We zouden een deel van het verkeer wel kunnen controleren met accessfilters (toegang naar poort 80 bijvoorbeeld), maar in de praktijk blijken net niet alle webservers van deze poort gebruik te maken. Door de instelling van de proxyserver kunnen we echt op protocol nivo controleren.
    • Controle op applicatie nivo. Daar waar firewalls slechts kijken tot op het netwerk nivo (IP, protocol TCP, poort 80) kan een proxyserver veel verder kijken en controleren. Uitgaande van de Netscape proxyserver kun je bijvoorbeeld filteren op URL's (welke sites / domeinen je wel of niet wil toelaten), wat voor type bestanden (worden mime-types genoemd) je wel of niet wil toelaten en zelfs kun je filteren op de inhoud van (html) pagina's. Je kunt hierdoor zaken als Java en allerlei soorten scripts, te herkennen aan de tags, dynamisch uit de pagina's verwijderen.
    • Virusscanning. Deze proxyserver bevat een ingebouwde virusscanner die data voordat deze doorgegeven wordt aan de client, scant. Hierdoor wordt een extra bescherming ingebouwd tegen virussen. Als de proxyserver niet over een dergelijke virusscanning beschikt, kun je ook eens kijken naar de virusswall van Trend Micro op www.trend.com . Deze werkt ook als een soort proxyserver. Let er bij het aanscaffen van virusscanners ook op dat ook de files in bijvoorbeeld zipped files gescanned dienen te worden.
    • Access controle. Met de bovenstaande proxyserver is het mogelijk toegangs profilen op gebruikers nivo of groeps nivo. Je hebt hierdoor een betere controle over individuele gebruikers , het verkeer dat gegenereerd wordt enz....

      Bovenstaande zaken zijn voorbeelden van de extra mogelijkheden die je krijgt door de implementatie van een proxyserver. Het is geen totaal oplossing, maar biedt weer een stukje extra bescherming tegen de toenemende gevaren die op het internet gevonden worden. De Netscape server moet je zien als een voorbeeld van de functies die proxyservers bieden.

    Voor de mail gaan we er in dit verhaal vanuit dat hierbij gebruik gemaakt wordt van de adrestranslatie mogelijkheden van de firewall. Een andere optie is echter het gebruik van een fetchmail service die de mail uit de mailboxen van de gebruikers haalt en deze doorstuurt naar de interne mailserver. Voor de uitgaande mail zou dan een sendmail service op de firewall moeten draaien die zorgt voor het doorsturen van de mail richting het internet (al dan niet via de smtp server van de ISP). Ga naar de homepage. Ga naar het begin van de pagina.
  3. Een oplossing met proxies op een dmz.
    Bij deze oplossing scheiden we de functies netwerkfiltering en controle op applicatienivo. Ook is deze oplossing geschikt voor internet koppelingen waarbij gebruik gemaakt wordt van zgn hardware oplossingen, waarop geen additionele proxies e.d. geinstalleerd kunnen worden. Indien we een zgn dynamisch IP adres toegewezen krijgen, dient de firewall een extra translatie slag uit te voeren.

    Een voorbeeld van een firewall met proxies op een dmz.

    Het voordeel van deze oplossing is, dat we de firewall volledig dicht kunnen zetten en slechts zo hoeven te configureren dat sessies geinitieerd van de proxies richting het internet toegestaan zijn. Daarnaast krijgen ook de interne gebruikers slechts toegang tot de proxyservers op poort x (zelf te configureren). De firewall zelf is praktisch afgeschermd voor alle verkeer (echter ook hier zijn weer DOS uitzonderingen voor gevonden) en mocht een inbreker binnen komen op het dmz, dan is de verdere weg naar binnen afgesloten in de rulebase van de firewall.

    De proxyservers zelf dienen bij voorkeur zo inbraakbestendig mogelijk gemaakt te worden, door het verwijderen van onnodigge programmatuur / processen.

Kunnen/willen we in deze configuratie geen gebruik maken van de adrestranslatie mogelijkheden van de firewall voor het versturen en ophalen van de mail, dan zijn we wellicht toe aan een eigen mailserver. Ga naar de homepage. Ga naar het begin van de pagina.

Het toevoegen van een "eigen" mailserver.

Nu begint het verhaal een beetje interessant te worden. Maar eerst moeten we weten wat we verstaan onder een "eigen" mailserver. We gaan er even vanuit dat we over het domein "netwerkinformatie.com" beschikken.

    Ga naar de homepage. Ga naar het begin van de pagina.
  1. Ons domein wordt gehost bij een ISP en daar staan individuele mailboxen.
    Bij deze optie kunnen zullen we de mail per mailbox op moeten halen bij de provider. Dit is op eenvoudige wijze te regelen door een fetchmail programma op geregelde tijden de mailboxen leeg te laten halen en via pop3 en naar een lokale mailbox te laten sturen. Een voorbeeldje van een fetchmail configuratie file op een unix machine:
    poll pop.provider.net proto pop3 user "jantje" pass "geheim" is "janklaasen" here 
    poll pop.ispa.net proto pop3 user "pietje" pass "secret" is "bernard" here
    poll pop.ispb.net proto pop3 user "klaastje" pass "nono" is "klaassje" here
    
    We zien gelijk het nadeel van een dergelijke oplossing, immers op de mailgateway moeten de userid's en passwords van de gebruikers opgenomen worden. Zou iemand inbreken op de machine, dan zou hij deze op eenvoudige wijze kunnen lezen.

    De verkeersstromen van mail gehost bij de provider.

    We zien in de bovenstaande tekening onder punt 1 het sturen van de mail door de pc m.b.v. smtp naar zijn lokale smtp server. Vervolgens zal deze server in dns (zie ook de volgende paragraven) opzoeken waar de mail naartoe gestuurt moet worden voor dat domein en deze forwarden. Onder stap drie zien we het ophalen van de mail m.b.v. bijvoorbeeld het pop protocol. Uiteindelijk kan de mail m.b.v. bijvoorbeeld pop3 opgehaald worden door de client.
    Met name door het op de mailserver moeten configureren van diverse individuele accounts met passwords, is deze oplossing minder geschikt voor de langere termijn, maar meer geschikt als een tussenoplossing. Ga naar de homepage. Ga naar het begin van de pagina.
  2. Ons domein wordt gehost bij de provider met 1 grote (smtp) mailbox voor het domein.
    Een oplossing die door diverse providers gebruikt wordt om te voorkomen dat er passwords verstuurd worden, is het het gebruiken van bijvoorbeeld een finger commando door de client, om de service provider te laten weten dat de client klaar is de mail te ontvangen (omdat de dailup verbinding tot stand is gebracht).
    Vervolgens wordt de mail vanuit de smtp server bij de provider doorgestuurd naar de smtp server van de "klant". Hoe werkt dit?
    Wil iemand iets naar een gebruiker binnen het domein netwerkinformatie.com sturen (bijvoorbeeld bernard@netwerkinformatie.com), dan stuurt een gebruiker zijn mailtje naar zijn smtp server (en hoopt dat het mailtje aankomt). De smtp server kijkt middels een dns query welke nameserver er geconfigureerd zijn voor "netwerkinformatie.com". We bekijken de output van het dig commando.

    ; <<>> DiG 8.2 <<>> netwerkinformatie.com any mx ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; QUERY SECTION: ;; netwerkinformatie.com, type = MX, class = IN ;; ANSWER SECTION: netwerkinformatie.com. 15M IN MX 10 mail.netwerkinformatie.com. netwerkinformatie.com. 15M IN MX 20 mail.provider.com. ;; AUTHORITY SECTION: netwerkinformatie.com. 15M IN NS ns1.netwerkinformatie.com. ;; ADDITIONAL SECTION: ns1.netwerkinformatie.com. 15M IN A 195.96.111.73 mail.netwerkinformatie.com. 15M IN A 195.96.111.74 ;; Total query time: 3 msec ;; FROM: fozzy.netwerkinformatie.com to SERVER: default -- 127.0.0.1 ;; WHEN: Fri Aug 25 16:10:23 2000 ;; MSG SIZE sent: 39 rcvd: 110
    In het bovenstaande voorbeeld zien we welke mailserver er voor netwerkinformatie.com geconfigureerd zijn, de server mail.provider.com en de server mail.netwerkinformatie.com. met een hogere prioriteit. Stel dan netwerkinformatie.com over een dialup verbinding beschikt, dan dient de server van de provider getriggert te worden dat "onze" server nu bereikbaar is. We zien dat in onderstaande tekening terug.

    Milhosting bij de provider met een trigger via bijvoorbeeld finger.

    Op het moment dat de firewall de verbinding maakt (middels bijvoorbeeld een dail on demand routing proces), moet de smtp server bij de provider weten dat hij de mail nu moet gaan opsturen. Smtp is immers een store en forward proces, waarbij op reguliere intervallen (1000 seconden default voor postfix) geprobeerd wordt de mail nog eens te versturen. Op de mailserver is in dergelijke gevallen vaak een proces actief dat bijvoorbeeld op de finger poort luistert en zodra er een connectie binnen komt, de mail nog eens probeert te bezorgen.
    Vervolgens zal de mailserver de mail naar de mailserver op ons dmz sturen, die dit weer forward naar de interne mailserver. Deze extra stap wordt vaak ingebouwd, omdat mailservers relatief vaak aan hacking onderhevig zijn en mail een steeds belangrijkere plaats aan het innemen is.
    Ga naar de homepage. Ga naar het begin van de pagina.
  3. Een wat complexere setup, met meer redundantie.


    ; <<>> DiG 8.2 <<>> cm.be any mx
    ;; res options: init recurs defnam dnsrch
    ;; got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 2, ADDITIONAL: 4
    ;; QUERY SECTION:
    ;;      cm.be, type = MX, class = IN
     
    ;; ANSWER SECTION:
    cm.be.                  23h58m19s IN MX  15 relay.cm.be.
    cm.be.                  23h58m19s IN MX  20 c.md.uunet.be.
    cm.be.                  23h58m19s IN MX  30 md.gate.uunet.be.
    cm.be.                  23h58m19s IN MX  10 mailhost.cm.be.
     
    ;; AUTHORITY SECTION:
    cm.be.                  23h58m15s IN NS  ns.reference.be.
    cm.be.                  23h58m15s IN NS  mail.reference.be.
     
    ;; ADDITIONAL SECTION:
    relay.cm.be.            23h58m19s IN A  194.7.177.76
    mailhost.cm.be.         23h58m19s IN A  194.7.177.74
    ns.reference.be.        23h58m15s IN A  195.13.20.1
    mail.reference.be.      23h58m15s IN A  195.13.20.3
     
    ;; Total query time: 5 msec
    ;; FROM: fozzy.netwerkinformatie.com to SERVER: default -- 127.0.0.1
    ;; WHEN: Fri Aug 25 16:06:47 2000
    ;; MSG SIZE  sent: 23  rcvd: 233
    
    We zien hier een viertal mailservers geconfigureerd. Een mailserver zal hierbij de mail in principe proberen af te leveren bij de mailserver met de laagste kosten (is de mailserver ailhost.cm.be. met een kost van 10), gevolgd door de mail met de daarna laagste kosten enz. We zien hierbij dat de cm een tweetal interne mailservers geconfigureerd hebben (kun je zien aan de adressen die dicht bij elkaar liggen) en een tweetal backup mailservers bij vermoedelijk hun provider uunet.be (wat een beetje tegenvalt is dat beide mailservers bij uunet zich ook op het zelfde segment bevinden, over beschikbaarheid gesproken).

    Ga naar de homepage. Ga naar het begin van de pagina.

  4. We regelen zelf onze DNS mail instellingen en beheren onze eigen mailserver(s).
    Nu we de bovenstaande instellingen hebben gezien, is dit minder complex als het op het eerste gezicht lijkt. Wat we nodig hebben is een (primairy) dns server (bij voorkeur 2 i.v.m. de beschikbaarheid, die beide individueel geupdate worden.). Als we een backup voor de mail op het internet willen regelen (omdat de mailserver er weleens langer als 5 dagen uit zou kunnen liggen, de default waarna mailservers het bericht bouncen naar de oorspronkelijke zender).
    Sommige bedrijven willen de mail echter koste wat kost weg hebben bij de zender, zodat eventuele problemen met hun eigen infrastructuur wat minder snel zichtbaar zullen zijn (de mail staat dan immers bij de ISP). Je moet je echter ernstig afvragen wat erger is, een meldig bij de oorspronkelijke zender dat de mail "nog" niet afgeleverd kon worden, of het niet ontvangen van een reactie door de ontvangende partij, omdat de mail rondzweeft bij de provider.
    Het voordeel van het regelen van de eigen dns instellingen is, dat men flexibel in kan spelen op wijzigingen / problemen in de infrastructuur. Ga naar de homepage. Ga naar het begin van de pagina.
  5. Waar gaan we onze eigen mailserver neerzetten.
    In de bovenstaande stukjes hebben we al een aantal opties de revu zien passeren. Voor "kleine" netwerken voldoet wellicht een mailserver achter een nat oplossing (m.b.v. pop3 o.i.d.), waarbij de mailprovider zorgt voor de mailboxen. Ook het hosten van de mailserver op een gecombineerde firewall (zoals linux) is een optie voor de wat kleinere netwerken.
    Voor de grotere netwerken en de netwerken met een hoger risico, verdient het gebruik van een soort forwarding mailgateway de voorkeur. Deze mailservers dienen zo geconfigureerd te worden dat ze tot op server nivo weten waar de mail naar doorgestuurd moet worden. Dit is tevens een goede plaats om later virusscanning toe te voegen (hierover verderop meer).

    Optie met een soort tussensluis op DMZ en een extra mailserver voor "eigen" gebruikers op het internet.

Ga naar de homepage. Het afschermen van virussen.

Hoe houden we virussen buiten de deur.

Binnen dit hoofdstuk zal beschreven worden hoe we (wellicht de meeste) virussen buiten de deur kunnen houden.
Als we het over virussen hebben, dan hebben we het over een complexe problematiek. Binnen dit hoofdstuk beperk ik mij tot de methoden die we hebben om virussen die binnen komen via man en http (web) verkeer tegen te houden. Als we bekijken hoe gebruikers aan virussen komen, dan kunnen deze binnen komen via bijvoorbeeld floppies, software, programma's die gedownload worden en vooral bekend het mail verkeer. Willen we iets tegen virussen doen, dan moeten we bij de basis beginnen. De gebruiker. Deze moet zich ervan bewust zijn dat virussen bestaan. Vervolgens dient de pc van de gebruiker voorzien te zijn van een virusscanner, bijvoorkeur een exemplaar die realtime alle documenten die geopend worden en/of binnen gehaald worden scant. Hiermee kunnen ook virussen gevangen woden die via netwerkdrives of bijvoorbeeld de floppy drive op de pc kunnen binnen komen.
Om te voorkomen dat virussen via servers verspreid worden (als bijvoorbeeld niet alle pc's over een uptodate versie van een virusscanner beschikken), dient er geregeld een virusscanner op de server te runnen, bij voorkeur een die tevens alle bestanden die op de server geplaatst worden scant (en regelmatig een totale scan uitvoert). Laat gebruikers data die ze via hun floppy drive binnen krijgen checken.
Vervolgens dienen we ervoor te zorgen dat mail die binnen komt danwel naar buiten verstuurd wordt, ook gescanned wordt op virussen. Hiervoor zijn een aantal alternatieven voorhanden:
  • Een virusscanner op de mailserver. Voor bepaalde typen mailservers zijn er virusscanners als plugins te krijgen. Je maakt beiden dan wel van elkaar afhankelijk, maar wellicht dat het beheer hierdoor eenvoudigger wordt? Een ander voordeel is dat deze oplossing ook voor de interne mail gebruikt kan worden.
  • Een virusscanner die samenwerkt met de firewall. Kijken we naar bijvoorbeeld de CheckPoint Firewalls, dan zijn er diverse scanners te krijgen die rechstreeks samenwerken met een op de firewall te installeren "mini" mailserver. Het voordeel van deze oplossing is metname dat de logging van de virusscanner en de firewall geintegreerd wordt. Als nadeel geld weer de afhankelijkheid van beiden onderling, waardoor de communicatie niet altijd even vlekkeloos verloopt. Daarnaast wordt de firewall mailserver, waardoor deze kwetsbaarder wordt voor aanvallen, immers je moet hier de smtp poort open zetten, en hackers kunnen kijken of ze hier op binnen kunnen komen.
    Plaatje volgt.
  • Een virusscanner die werkt als een "separate" mail-relay server op bijvoorbeeld het DMZ.
    Bij het gebruik van deze oplossing wordt er op het DMZ een separate mailgateway / virusscanner geplaatst voor mail verkeer. Voor zowel ingaand als uitgaand verkeer geld, dat de mail gestuurd wordt naar de smtp poort van de mail-relay server, waar de virusscanner de mail oppakt. Deze zal vervolgens de mail scannen en doorsturen naar een mailserver op de zelfde host of op een separaat systeem op het dmz (zie tekening). Vervolgens kan deze mailserver middels dns (dynamische) of via statische routes zijn mail verder afleveren. Door van dns gebruik te maken kun je in veel gevallen een stabilere verbinding realiseren (niet meer afhankelijk van je smtp-server van je provider en intern ook meerdere servers waarop de mail afgeleverd kan worden te configureren.
    Plaatje volgt.
Ga naar de homepage. Ga naar het begin van de pagina.

Hoe sluiten we een webserver aan.

Als we willen beslissen waar en hoe we een webserver aansluiten op het netwerk moeten we een beetje meer weten van de werking van de webserver en de beperkingen van firewalls.
  1. De werking en beperkingen van een firewall
    Normaal gesproken houden firewalls zich uitsluitend op het IP protocol nivo bezig, en hebben ze geen idee van de onderliggende akties die uitgevoerd worden. Nu zijn er ook firewalls die specifieke "proxies" hebben, maar de bescherming hiervan kan nooit volledig zijn. Primair zorgen firewalls ervoor dat servers niet op andere (ip)poorten aangevallen worden. Voor de afscherming van de webserver, moeten ze op de webserver vertrouwen. Wel kunnen firewalls ervoor zorgen dat de schade die inbrekers op "andere" systemen aan kunnen richten beperkt is.
  2. De werking van de webserver Een webserver is niets meer als een stuk software die wacht op requests (vragen) van web clients en deze dan zogoed mogelijk beantwoord. De firewall kan niet weten of een vraag voor een bepaald document legitiem is en of er wellicht een speciale authorisatie nodig is voor dat specifieke document. Dit is de verantwoordelijkheid van de webserver (geschreven door de maker en geconfigureerd door de beheerder). Problemen met webservers ontstaan dan ook door verkeerd geconfigureerde webservers, waardoor gebruikers toegang krijgen tot files die niet voor hen bestemd waren, of bijvoorbeeld programma's op de server kunnen starten. Andere problemen ontstaan door problemen / fouten in de webserversoftware of het onderliggende operating systeem. Het Code Red virus, is hiervan een berucht voorbeeld, maar er zijn vele bugs bekend en zullen er nog vele volgen.
  3. Hoe gaat een hacker aan de slag Hackers die websites willen kraken heb je in vele soorten. De gene waar we het meeste last van hebben, zijn wellicht de scriptkiddies, die met de informatie van een bekend probleem, het hele internet afscannen op servers die hiertegen nog niet beschermd zijn. Vinden ze een probleem, dan is het afhankelijk van dit probleem, wat ze er mee (kunnen) doen.
    Lastiger zijn de intelligentere hackers, met kennis van specifieke implementaties. Deze kunnen gerichter specifieke systemen aanvallen, door na het bepalen van de soort, te gaan zoeken naar specifieke zwakke punten en van daaruit verder te graven. Dergelijke aanvallen nemen vaak weken in beslag.
    En verder, de bugs, virussen en trojan horses, die verder aan de werking van webserver blijven graven.
  4. Wat kunnen we er aan doen Het eerste wat je moet doen, is begrijpen waar je als beheerder van een webserver mee bezig bent. Zorg dat je een redelijk stukje basis kennis opbouwt, over de werking van html en de diverse scripts en programma's. Kies vervolgens een webserver en platform uit, dat een redelijke mate van betrouwbaarheid kent. Een goede keuze is bijvoorbeeld de Apache webserver, draaiend op een Sun of Linux platform. Vermijd als je de keuze (en de kennis) hebt het gebruik van de IIS server op het Windows platform. Microsoft heeft niet zo'n geweldige reputatie als het om beveiliging gaat, en de IIS server wordt ook wel eens vergeleken met een zwitserse gatenkaas. Bouw vervolgens voldoende kennis op over het betreffende platform en de configuratie hiervan. Configureer en bouw vervolgens je website, met zo weinig mogelijk features / scripts.
bernard@netwerkinformatie.com