[Debian] IPtables vraag

[dôh]

Ik zit een tijdje met iptables te rommelen maar ik krijg het volgende niet voor elkaar;

Ik wil voor een bepaald ip range al het uitgaande verkeer vanaf mijn server blokkeren, maar al het inkomende verkeer vanaf dit ip range wil ik toestaan.

Dus ik heb de volgende 2 regels geprobeerd;

iptables -A INPUT -s 91.121.0.0/16 -j ACCEPT
iptables -A OUTPUT -d 91.121.0.0/16 -j DROP

Dit heeft niet de goede uitwerking, want ik heb nu geen verkeer beide kanten op. Dat is niet mijn bedoeling!

Wat doe ik fout?

[battler]

Is je server ook een router?

Input = inkomende bestemd voor de server
Output = uitkomend vanaf de server
Forward = gerouteerde data

_{Waarom een /16 filteren?}

[ Voor 12% gewijzigd door battler op 04-04-2010 18:13 ]

[dôh]

Nee, het is geen router. Hij zit wel achter een router! Hoe zou ik de iptables regels dan moeten invoeren?

[battler]

Volgens mij heb je geen idee wat je doet. Je data moet toch ook terug gaan?
Zoek even een tut. op, en kijk even naar related en established.

[ Voor 30% gewijzigd door battler op 04-04-2010 18:15 ]

[burne]

dôh schreef op zondag 04 april 2010 @ 18:10:
Wat doe ik fout?

Dit doet wat je wilt, maar enkel voor UDP en ICMP. Voor TCP heb je twee kanten op packets nodig, en je dropt het uitgaande verkeer, dus de verbinding zal nooit tot stand komen.

Controleer maar met tcpdump:

code:

tcpdump net 91.121.0.0/16

Wat voor soort verkeer probeer je precies tegen te houden?

[dôh]

burne schreef op zondag 04 april 2010 @ 18:15:
[...]


Dit doet wat je wilt, maar enkel voor UDP en ICMP. Voor TCP heb je twee kanten op packets nodig, en je dropt het uitgaande verkeer, dus de verbinding zal nooit tot stand komen.

Controleer maar met tcpdump:

code:

tcpdump host 91.121.0.0/16

Wat voor soort verkeer probeer je precies tegen te houden?

Aha, vandaar! Ik probeer FTP verkeer tegen te houden.

[burne]

dôh schreef op zondag 04 april 2010 @ 18:16:
Aha, vandaar! Ik probeer FTP verkeer tegen te houden.

Maar waarom wil je inkomend verkeer toestaan? Bedoel je misschien niet dat 91.121.0.0/16 wel mag uploaden en niet mag downloaden?

[battler]

Je firewall doet nu dit.

Alles wat bestemd is voor mij mag naar binnen.
Alles wat ik moet versturen wordt gedropt.

Wat jij wilt is.
Als het FTP verkeer is bestemd voor mij dan moet het worden gedropt.
Alles wat voor mij is mag naar binnen.
Alles wat ik moet versturen mag naar buiten.

[dôh]

burne schreef op zondag 04 april 2010 @ 18:20:
[...]

Maar waarom wil je inkomend verkeer toestaan? Bedoel je misschien niet dat 91.121.0.0/16 wel mag uploaden en niet mag downloaden?

Ja, ik bedoel inderdaad dat iemand wel mag uploaden maar niet mag downloaden. Vandaar dat ik dus inkomend verkeer wil toestaan. In mijn beleving moest dat dus zoals in de startpost. Niet dus...

Kun jij me een voorbeeld geven van hoe het wel moet? Ik ben namelijk niet echt thuis in iptables. Omdat hij achter NAT zit is het passive mode.

[dôh]

battler schreef op zondag 04 april 2010 @ 18:20:
Je firewall doet nu dit.

Alles wat bestemd is voor mij mag naar binnen.
Alles wat ik moet versturen wordt gedropt.

Wat jij wilt is.
Als het FTP verkeer is bestemd voor mij dan moet het worden gedropt.
Alles wat voor mij is mag naar binnen.
Alles wat ik moet versturen mag naar buiten.

Alles wat van dat ene range komt mag naar mij, maar alles wat daar heen moet, moet worden gedropt. Dat is wat ik wil.

[burne]

dôh schreef op zondag 04 april 2010 @ 18:24:
Ja, ik bedoel inderdaad dat iemand wel mag uploaden maar niet mag downloaden. Vandaar dat ik dus inkomend verkeer wil toestaan. In mijn beleving moest dat dus zoals in de startpost. Niet dus...

Maar als je inlogt op een ftp-server wil je toch bepaalde dingen wel zien? Het ding vraagt om een username en password als je inlogt, en dat verkeer moet wel bij je komen.

Je zult het probleem dus ergens anders op moeten lossen. Je ftp-server (vsftpd?) is de baas waar het zaken als uploaden en en downloaden betreft, en die zul je dus uit moeten leggen wat je bedoeling is.

[dôh]

burne schreef op zondag 04 april 2010 @ 18:32:
[...]


Maar als je inlogt op een ftp-server wil je toch bepaalde dingen wel zien? Het ding vraagt om een username en password als je inlogt, en dat verkeer moet wel bij je komen.

Je zult het probleem dus ergens anders op moeten lossen. Je ftp-server (vsftpd?) is de baas waar het zaken als uploaden en en downloaden betreft, en die zul je dus uit moeten leggen wat je bedoeling is.

Daar heb je gelijk in. Maar, wanneer je bijvoorbeeld naar een bepaalde server gaat fxpen, die dus een ander ip adres heeft dan de gebruiker die verbinding maakt, dan is het een ander verhaal. Daarom wil ik dit blokkeren en volgens mij moet dat met iptables.

[burne]

dôh schreef op zondag 04 april 2010 @ 20:18:
Daarom wil ik dit blokkeren en volgens mij moet dat met iptables.

Bedenk je wel dat iptables erg dom is. Het kan niet zien of een packet deel uitmaakt van een ftp-sessie of iets anders. Je hebt beperkt parameters om op te filteren, en geen daarvan geeft je een antwoord op de vraag 'is dit een upload uit een bepaald netblock?'.

Wat je wilt gaat je niet lukken, dat zul je echt in je ftp-daemon op moeten lossen.

code:

    <Directory pub/incoming>
        <Limit STOR>
            AllowAll  # iedereen mag uploaden
        </Limit>
        <Limit READ> 
            Deny 91.121.0.0/16
        </Limit>
        <Limit CWD XCWD CDUP>
            AllowAll
        </Limit>
    </Directory>

(ongetest) zou proftpd vertellen dat iedereen mag uploaden maar 91.121.0.0/16 niet mag downloaden.

[Osiris]

iptables -I INPUT 1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -I OUTPUT 1 -m state --state RELATED,ESTABLISHED -j ACCEPT

Dit slechts als aanvulling op je starterspost. Want het kan prima, inkomende verbindingen blokkeren en uitgaande niet, maar dan moet je bovenstaande zinnetjes wel even toepassen. Maar voor je FTP-probleem zal 't je niet helpen.

[ Voor 50% gewijzigd door Osiris op 08-04-2010 09:26 ]

[sloth]

Misschien niet helemaal een antwoord op je vraag maar toch nuttig:

Waarom gebruik je geen grafische frontend voor iptables? Zelf zie ik anno 2010 het nut van complexe regels invoeren niet meer in.

Kijk bijvoorbeeld eens naar Vuurmuur. Gebruikt erg weinig resources en firewall rules toevoegen, monitoring en logging is nog nooit zo eenvoudig geweest.

[Osiris]

sloth schreef op zondag 04 april 2010 @ 21:18:
Misschien niet helemaal een antwoord op je vraag maar toch nuttig:

Waarom gebruik je geen grafische frontend voor iptables? Zelf zie ik anno 2010 het nut van complexe regels invoeren niet meer in.

Kijk bijvoorbeeld eens naar Vuurmuur. Gebruikt erg weinig resources en firewall rules toevoegen, monitoring en logging is nog nooit zo eenvoudig geweest.

Ach, als je genoeg kennis van zaken hebt, dan is iptables via de CLI ook helemaal niet lastig hoor. En als ik die voorbeeldjes bij Vuurmuur bekijk heb je ook daarbij wel enigszins kennis van zaken nodig. Dus dan kun je net zo goed in de CLI aan 't werk, zo lastig is 't niet?

[Borromini]

Een bepaalde poort blokkeren helpt ook niet? Ik dacht dat 21 voor gegevensoverdracht werd gebruikt en 20 voor andere communicatie van het FTP-protocol. Dan kan je eventueel de poort en de IP-range combineren.

[Osiris]

Da's bij active FTP zo (en dan is de poort-21-verbinding juist niet voor de data, maar voor de commando's) en dat werkt nog "vreemd" ook. Want die data-connectie wordt opgebouwd met poort 20 als source-poort vanaf de server náár de client toe op destination-poort source-poort-van-de-commando-verbinding+1.

Met alle NAT-devices hier en daar reden genoeg om daar vanaf te stappen dus. Passive werkt puur client -> server, dus "prikt' prima door NAT-apparaatjes heen.

[ Voor 9% gewijzigd door Osiris op 04-04-2010 21:44 ]

[dôh]

Vuurmuur ziet er aardig uit, daar ga ik eens naar kijken. Hoewel ik hem nu via APT niet geinstalleerd krijg, omdat ik de x64 versie heb.

[sloth]

Osiris schreef op zondag 04 april 2010 @ 21:32:
[...]

Ach, als je genoeg kennis van zaken hebt, dan is iptables via de CLI ook helemaal niet lastig hoor. En als ik die voorbeeldjes bij Vuurmuur bekijk heb je ook daarbij wel enigszins kennis van zaken nodig. Dus dan kun je net zo goed in de CLI aan 't werk, zo lastig is 't niet?

Precies, als je genoeg kennis van zaken hebt... Ik zou zelf bijvoorbeeld niet eens weten hoe ik een simpele port open kan zetten voor bepaalde individuele ip's, een group van zelf toegevoegde ip's, een hele netblock, al dan niet met wildcards.

Met Vuurmuur lukte me dit bijna meteen, zonder diepgaande kennis van iptables. Ik zeg niet dat een (gui) frontend dé oplossing is, wel dat het voor beginners zoals ik, of mensen die het e.e.a. snel willen laten werken veel prettiger en sneller werken is.

Bovendien vind ik het wel prettig snel en overzichtelijk geblockte connecties te kunnen loggen, ip's te blocken enz. Hoe dit met iptables precies werkt weet ik niet, en je zal vast met wat creatief cat, grep en piping ver komen, Vuurmuur werkt m.i. simpeler met een minimum aan overhead of beveiligingsrisico's die je hiervoor aan zou kunnen inboeten.

dôh schreef op zondag 04 april 2010 @ 21:50:
Vuurmuur ziet er aardig uit, daar ga ik eens naar kijken. Hoewel ik hem nu via APT niet geinstalleerd krijg, omdat ik de x64 versie heb.

Leuk om te horen dat je het gaat proberen
Zelf heb ik geen ervaring met de x64 versie, maar ik vermoed wel dat het mogelijk moet zijn deze via APT te installeren, en anders even manueel doen via de tarball.

Mocht het je toch niet lukken, ga dan even op irc: de ontwikkelaar idled daar en er zit een altijd even vriendelijke en behulpzame community.

[t1mmy]

Als hij achter een router zit, waarin je dus alle poorten regelt is het eigenlijk gemakkelijker om iptables gewoon helemaal uit te zetten, toch?

Scheelt een hoop gedoe.

[Osiris]

sloth schreef op zondag 04 april 2010 @ 22:00:
[...]


Precies, als je genoeg kennis van zaken hebt... Ik zou zelf bijvoorbeeld niet eens weten hoe ik een simpele port open kan zetten voor bepaalde individuele ip's, een group van zelf toegevoegde ip's, een hele netblock, al dan niet met wildcards.

Met Vuurmuur lukte me dit bijna meteen, zonder diepgaande kennis van iptables. Ik zeg niet dat een (gui) frontend dé oplossing is, wel dat het voor beginners zoals ik, of mensen die het e.e.a. snel willen laten werken veel prettiger en sneller werken is.

Bovendien vind ik het wel prettig snel en overzichtelijk geblockte connecties te kunnen loggen, ip's te blocken enz. Hoe dit met iptables precies werkt weet ik niet, en je zal vast met wat creatief cat, grep en piping ver komen, Vuurmuur werkt m.i. simpeler met een minimum aan overhead of beveiligingsrisico's die je hiervoor aan zou kunnen inboeten.

't Zal ongetwijfeld makkelijker werken, maar met `man iptables` kom je een heel eind. Gewoon eens doorlezen op een regenachtige zondag.

En je kunt je afvragen of je überhaupt 'beginners' soms cruciele dingen als een firewall in wil laten stellen

[burne]

Osiris schreef op zondag 04 april 2010 @ 23:32:
En je kunt je afvragen of je überhaupt 'beginners' soms cruciele dingen als een firewall in wil laten stellen

Voor een ftp-servertje thuis is 'cruciel' (cruciaal) een nogal zware term, en je leert van niets zo goed als van je eigen fouten. Ik ben te vaak 's nachts naar een serverruimte gereden vanwege dat soort foutjes, dat kun je beter doen als je naast de machine zit.

[Osiris]

Ik mag hopen dat de TS (of andere 'beginners') niet richting serverruimtes kan/mag rijden

No offence jegens de TS verder. Immers, als je niet over de benodigde informatie beschikt, dan is 't nogal lastig om meteen alles goed te doen/bedenken ofcourse, maar basale kennis over "waar grijpt iptables op aan, hoe werkt TCP/FTP, hoe werkt up/downloaden" et cetera zijn vrij elementair. Zonder die basiskennis ben je maar wat aan 't kloten en dat schiet niet op natuurlijk.

[sloth]

t1mmy schreef op zondag 04 april 2010 @ 22:03:
Als hij achter een router zit, waarin je dus alle poorten regelt is het eigenlijk gemakkelijker om iptables gewoon helemaal uit te zetten, toch?

Scheelt een hoop gedoe.

Daar ben ik het niet met je eens. Stel je voor dat zo'n router spontaan een reboot doet en dan maar besluit je in een DMZ te zetten, wat dan? Of je maakt zelf een instelfout waardoor dit gebeurd?

Bovendien doet NAT afaik alleen binnenkomende connecties op port niveau blokkeren, vaak wil je ook nog een of meerdere ip(range)'s toelaten om een service te benaderen, iets wat op een alledaags consumentenroutertje niet altijd in te stellen valt.

Met iptables heb je ook nog eens controle over uitgaande connecties en imho een veel veiligere configuratie dan enkel NAT.

Osiris schreef op zondag 04 april 2010 @ 23:32:
[...]

't Zal ongetwijfeld makkelijker werken, maar met `man iptables` kom je een heel eind. Gewoon eens doorlezen op een regenachtige zondag.

En je kunt je afvragen of je überhaupt 'beginners' soms cruciele dingen als een firewall in wil laten stellen

Je zou de vraag anders moeten stellen: wil je beginners een (linux)server volledig laten inrichten
Als je dit doet, dan doe het meteen goed en implementeer firewall rules. Doe je dit niet dan kunnen deze foutjes je duur komen te staan op het grote boze internet...

[burne]

sloth schreef op dinsdag 06 april 2010 @ 13:13:
Je zou de vraag anders moeten stellen: wil je beginners een (linux)server volledig laten inrichten

Nee, de vraag is: hoe kweek je ervaren systeembeheerders?

Kruipen is te langzaam en vallen doet pijn. Dat is de enige reden dat je ooit hebt leren lopen. dôh moet eens flink googlen en een paar avonden lang naar iptables, tcpdump en een ftp-server en client zitten kijken. Als 'ie nu begint valt donderdagavond het kwartje en hoeft 'ie nooit meer na te denken over dit specifieke probleem of andere netwerk- en iptablesproblemen.

Natuurlijk, ik kan zo de nodige stappen uit m'n mouw schudden en 'm de oplossing vertellen. Maar hij zit met iptables op een linux-doos te rommelen om wat van linux en netwerken te leren. Als 'ie mijn howto volgt leert 'ie niets en is alleen maar het probleem weg.

dôh: Bekijk http://www.youtube.com/watch?v=z40w3G8szK0 eens.

'Klassiek' ftp (en fxp valt daar ook onder) gebruikt twee tcp-verbindingen. Het control-channel, waarin je commando's geeft, en wat tcp-poort 21 (op de server) gebruikt, en het data-channel, waarover de daadwerkelijke bestanden uitgewisseld worden, wat standaard poort 20 (op de server) gebruikt. Het verschil tussen ftp en fxp is dat bij fxp data- en commandchannel wat de client (jouw ftp-programma) beftreft op verschillende machines kunnen leven maar gebruik maken van dezelfde server, en dat ftp data- en commandchannel op dezelfde machines hebben, zowel voor de server als voor de client.

Maar zowel het command-channel als het data-channel zijn volwaardige tcp-verbindingen, en zoals het filmpje laat zien vereist dat tcp packets twee kanten op. Zonder die eerste ACK zal er nooit een verbinding komen, en dus geen up- of download, enkel een foutmelding.

Zodra die tcp-verbinding er is kun je over het data-channel uploaden of downloaden. De enige die een download kan voorkomen is de ftp-server zelf, die dan wel een STOR toe moet laten maar geen RETR.

[dôh]

Bedankt voor al jullie reacties. Ik heb behoorlijk wat kennis op het gebied van netwerken en het instellen van firewalls e.d.. De uitleg die jullie geven is voor mij bekend gebied. Echter ben ik niet ervaren in de werking van iptables.

Ik ben inmiddels bijna 10 jaar lid van GoT en waar ik mij soms een beetje aan kan irriteren is het feit dat er vaak meteen wordt verwezen naar Google en dat er kreten als 'RTFM' worden geroepen. Ik begrijp best dat er een hoop users zijn die meteen vragen alvorens zij zelf gezocht hebben. Zelf ben ik echter niet van dit soort.

Eigenlijk had ik gehoopt dat jullie een beetje van jullie kennis met mij wilden delen, zodat ik dus juist niet een hele avond hoef te lopen kutten en klooien.

Misschien ben ik niet duidelijk geweest of ben ik inderdaad lui...

Wat ik nog even wilde toevoegen is dat dit niet voor iedereen die in dit topic heeft gereageerd opgaat.

Tot slot ben ik er inmiddels ook uit;

iptables -A OUTPUT -p tcp --source-port pasv_portrange_start:pasv_portrange_end -d te_blokkeren_ip -j DROP

[ Voor 14% gewijzigd door dôh op 07-04-2010 23:40 . Reden: toevoeging en nog een toevoeging ]

[Osiris]

Nou nou, er wordt maar 1x verwezen naar Google en RTFM wordt nergens geroepen hoor

burne heeft je handje verder in 't begin van het topic prima vastgehouden

Om het nog maar eens te herhalen dan: iptables is DOM. Het doet *exact* wat je zegt en als jij dus zegt: blokkeer uitgaande pakketjes, zonder dat je extra voorwaarden opgeeft, dan blokkeert ie ALLE uitgaande pakketjes (tof als je bestaande SSH-verbinding spontaan niet meer werkt joh )

Enige wat iptables doet is het pakketje erbij pakken en vervolgens, afhankelijk van waar het pakketje zich in jouw systeem zich "bevindt" het lijstje met rules erbij pakken en van boven af aan bekijken of de rule "matcht". Matcht ie? Dan voert ie het opgegeven "beleid" uit en dan is het (meestal) ook gewoon afgelopen voor dat pakketje. Hij kijkt niet meer verder, hij is er klaar mee en schopt 'em "door" naar het volgende stapje in het systeem (de UTP-kabel op of naar een programma of of of...)

Dus als jij zegt: ik wil inkomende TCP verbindingen wel toestaan, maar jij hebt vervolgens "iptables -A OUTPUT -d 91.121.0.0/16 -j DROP" in je iptables gepleurt en een host uit 91.121.0.0/16 wil verbinding maken met je server, dan gebeurt er het volgende:

91.121.0.0/16 richting server: SYN op poort 80! HOOIII!!! -> iptables: Ah, dat mag, kommaar..
Kernel: Hoi 91.121.0.0/16, tof, een TCP-verbindinkje maken, prima: SYN/ACK! Asjeblieft!: iptables: ho eens even.. Dat mag niet.. *DROP*..
91.121.0.0/16: Joehoe? Ik stuurde net een SYN voor die TCP-verbinding? Nog maar een keer.. SYN op poort 80! HOOII!! Joehoe! -> iptables: weer eentje? Naja, sure, kommaar, dat mag.
Kernel: Hey 91.121.0.0/16, jij weer? Ok, prima: SYN/ACK naar 91.121.0.0/16 toe: iptables: Ja rot op met je verkeer naar 91.121.0.0/16, wegwezen *DROP*..
*ga zo maar door tot timeout aan 91.121.0.0/16's kant*

dôh schreef op woensdag 07 april 2010 @ 23:24:
Tot slot ben ik er inmiddels ook uit;

iptables -A OUTPUT -p tcp --source-port pasv_portrange_start:pasv_portrange_end -d te_blokkeren_ip -j DROP

Waarom niet:

iptables -A INPUT -p tcp --destination-port pasv_portrange_start:pasv_portrange_end -s te_blokkeren_ip -j DROP

[ Voor 10% gewijzigd door Osiris op 07-04-2010 23:47 ]

[dôh]

Ja, duidelijk verhaal. Ik had het eerst inderdaad bij het verkeerde eind, ik dacht iets te simpel, maar ik moest het inderdaad op poort niveau zoeken.

Waarom niet:

iptables -A INPUT -p tcp --destination-port pasv_portrange_start:pasv_portrange_end -s te_blokkeren_ip -j DROP

Omdat de verbinding vanaf mijn pasv portrange naar de andere kant gaat en niet naar het pasv portrange aan de andere kant. Ik had hem eerst inderdaad zoals jij hem net schreef, maar daarmee werkte het niet! Op mijn manier wel!

[burne]

dôh schreef op woensdag 07 april 2010 @ 23:24:
Ik heb behoorlijk wat kennis op het gebied van netwerken en het instellen van firewalls e.d..

Om je even wat context te geven: Je bent lid geworden van Tweakers op het moment dat ze net een paar maanden in 'mijn' serverruimte hingen. In juni 2001 ging het spul naar True, en ik ging er in september zelf achteraan. Ik ben inmiddels met m'n veertiende jaar als netwerk- en systeembeheerder bij een internet-provider bezig, maar m'n eerste modem-verbinding stamt uit 1895. Euh.. 1985.

Laat ik zeggen dat ik niet geheel vrij van ervaring ben.

Ik kan je voorspellen dat je met de regel die je gevonden hebt een probleem gaat hebben. De ftp-client gebruikt een random poort (boven de 1023) om vanaf te connecten naar poort 20 van je ftp-server. Je weet pas welke poort op het moment dat de SYN bij je aankomt, en dan is het te laat om dat in je iptables te zetten. Osiris geeft je dat ook als hint, maar zonder uitleg waarom. Maar probeer het gerust uit. Het topic zit nog niet op slot, dus je kunt er achterkomen dat het niet werkt en dan helpen wij je wel weer een stukje verder.

[Osiris]

dôh schreef op donderdag 08 april 2010 @ 00:10:
[...]

Omdat de verbinding vanaf mijn pasv portrange naar de andere kant gaat en niet naar het pasv portrange aan de andere kant. Ik had hem eerst inderdaad zoals jij hem net schreef, maar daarmee werkte het niet! Op mijn manier wel!

En als ik jou nou vertel dat beide regels (goed de verschillen zoeken ) in principe exact hetzelfde doen? Met als enige verschil dat in jouw geval binnenkomende SYN-pakketjes nog wel geaccepteerd worden, maar dat de SYN/ACK van jouw FTP-programma er vervolgens niet meer uit komen, terwijl bij mijn rule zelfs de allereerste SYN-pakketjes al tegengehouden worden.

Kweenie of je al naar die --state gekeken hebt?

Verder schijn je met je "jaren ervaring" nog steeds niet te beseffen dat ook *uploads* naar jouw server gemaakt worden vanaf de client naar jouw passive ports. Voor iptables of qua TCP-verbinding is er geen enkel onderscheid tussen een upload of een download. Al het verkeer wordt bij passive FTP vanuit de client geinitialiseerd.
Bij FXP is 't maar net een kwestie of je server ontvangend of versturend is. Dan zal de versturende server een verbinding opzetten naar de ontvangende server.

burne schreef op donderdag 08 april 2010 @ 00:25:
[...]

Ik kan je voorspellen dat je met de regel die je gevonden hebt een probleem gaat hebben. De ftp-client gebruikt een random poort (boven de 1023) om vanaf te connecten naar poort 20 van je ftp-server.

Da's alleen bij active FTP zo, de TS gebruikt passive

[ Voor 39% gewijzigd door Osiris op 08-04-2010 10:13 ]