|
|
Index
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.
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.
- 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.
- 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).
- 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.
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.
- 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.
- 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.
- 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).
- 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.
- 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.
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.
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.
- 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.
- 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.
- 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.
- 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.
|
|
