[iptables] detail vraagjes over werking.

[Verwijderd]

Dit is zo'n typische correct-me-WHERE-i'm-wrong (niet 'if', want ik zal hier wel fouten gemaakt hebben.)

Na het lezen van Rusty's guides en de info pages van iptables, had ik nog wat vraagjes die onopgelost bleven en die hier met de search ook niet gevonden werden.

Als ik bvb check dat maar 1 IP adres mag aanvaard worden worden zowel op (INPUT) de linux-router als erdoor (FORWARD), dan schrijf ik dit:
(alle default policies zijn DROP)
(geen masquarading wordt gebruikt. Gewoon linuxbox die gaat gebruikt worden om 2 interne netwerken te scheiden; bvb 0.1 tot 0.10 scheiden van 0.11 tot 0.20)

code:

${IPTABLES} -t nat -A PREROUTING -i eth0 -s 192.168.0.9 \
        --mac-source 01:02:03:04:05:06 -j ACCEPT

(is het juist om dit in prerouting te zetten?)

Als een pakketje binnenkomt (laten we zeggen een http pakketje) van mijn PC naar de linuxbox, dan komt het pakketje eerst in de PREROUTING chain van eth0.

Als die daar een "-j ACCEPT" tegenkomt, dan springt ie naar de routing (die eigenlijk gewoon beslist naar welke chain er wordt gesprongen op basis van het destination IP).

Als het pakketje voor de linuxbox zelf bestemd is, gaat die naar de INPUT chain en doorloopt daar ook wat regeltjes totdat die ook een match vindt waar "-j ACCEPT" staat. Dan wordt het pakketje aan de applicatie gegeven die loopt op de linuxbak (webserver).

Als destination adres iets anders is, wordt de FORWARD chain doorlopen totdat ie "-j ACCEPT" tegenkomt en dan komt hij uiteindelijk in de POSTROUTING chain waar hij ook een "-j ACCEPT " moet tegenkomen om uiteindelijk uit eth1 te worden gespuwd.


Btw, als je ergens een rule toevoegd (bvb in INPUT), geldt dat dan automatisch voor eth0 en eth1 als je dat er niet expliciet bijzet?

Ten laatste, dingen zoals "-A INPUT -o eth0" en "-A OUTPUT -i eth0" zijn toch onmogelijk, niet?

Hoe kan ik syn gebruiken om portscans te vermijden?

[Verwijderd]

Ik zie er op het eerste zicht geen fouten in

--mac-source in prerouting kan geen kwaad

een rule geld voor alle packetjes die aan de beschrijving voldoen. Dus als je geen interface meegeeft aan een regel voor INPUT geld dit voor alle inkomende packetjes van beide interfaces. Alle INPUT rules gaan zo-ie-zo toch doorlopen worden voor alle inkomende packetten op eendert welke interface tot een match gevonden word of men aan het einde van de chain is

en inderdaad "-A INPUT -o eth0" en "-A OUTPUT -i eth0" zijn onmogelijk

[Verwijderd]

Ik zou hem niet gebruiken voor de PREROUTING chain, maar alleen voor de FORWARD en INPUT chain.
En dan natuurlijk beide kanten op, dus ook een FORWARD accepteren vanaf internet naar je lokale computer.

De PREROUTING chain gebruik je eigenlijk alleen voor speciale doelen, zoals een portmap, of eventueel logging.
Hetzelfde geldt voor de POSTROUTING, die gebruik je bijv. voor NAT.
Voor het gewone verkeer, of voor gewone filter-rules is dat niet nodig, daar zijn INPUT/OUTPUT en FORWARD voor.

[Verwijderd]

PREROUTING gebruik je om poorten te forwarden naar andere machines. Deze wordt altijd als eerste aangedaan (in de nat-table). Je verandert daarmee dus het destinationadres.

Met POSTROUTING doe je dus precies het omgekeerde; je veranderd het source-adres. De natmachine houdt precies de mappings bij zodat de adressen ook weer ge-denat worden.

Een PREROUTING gaat normaliter samen met een -j DNAT (Destination NAT), de POSTROUTING gaat samen met een SNAT (Source NAT).

De PREROUTING regel zoals je hem hierboven gebruikt is absoluut verkeerd. Je hebt die regel alleen nodig als je bijvoorbeeld voor het ene segment (cq subnet) een webserver toegankelijk wil maken voor het ander segment (cq subnet). Het lijkt voor de persoon die de request doet, dan net alsof hij het request doet naar de NAT-machine, terwijl eigenlijk het pakketje gewoon geforward wordt naar de werkelijke machine in het andere segment.

Wat jij wil is packetjes forwarden. Dit gebeurt in de FORWARD chain. In een FORWARD chain heb je zowel de beschikking over de -i switch (incomming) als de -o (outgoing) switch.
Je kan dus precies bepalen vanaf welke interface request toegestaan zijn en over welke interface ze naar buiten toe mogen via de FORWARD chain. (Dit alles naast de controle op source-adres (-s switch) en destination adres (-d switch).
Daar kan je ook MAC-adres controle in doen, zolas je in bovenstaande PREROUTING chain doet.

Normaliter geef je in zo'n FORWARD chain dus zowel een source (met subnetmask) aan als een destination (met subnetmask). Dat zie ik in je foutieve PREROUTING chain niet terug.

Verder valt mij nog iets op aan je post. Je hebt het over scheiden van 0.1-0.10 en 0.11 en 0.20!
Heb je daar bijbehorende subnetten van gemaakt?
Blijkbaar moet het verkeer namelijk allemaal door die Linux NAT machine heen als ik het goed begrijp. Als al die adressen in hetzelfde subnet zitten, dan vindt er geeneens routering plaats, simpelweg omdat vanaf elke machine alle adressen in hetzelfde subnet direkt toegankelijk moeten zijn.
Als je echt 2 groepen computers van elkaar wil scheiden d.m.v. die linux NAT machine, dan zul je wel 2 aparte subnetten aan moeten maken, omdat het anders niet gaat werken.

[Verwijderd]

Ik zit in een groot bedrijf (~2500 PCs). Momenteel hebben we verscheidene beveilingingsopdrachten en het labo waarin we werken is niet veilig meer geacht. (wel fysiek, maar niet ivm netwerk).

We zitten allemaal op hetzelfde (grote klasse netwerk en de opzet is om remote te kunnen inloggen op die labopc's enkel via SSH, en maar door 4 personen van dat grote netwerk. 3 personen die het werk gaan doen en 1 persoon die bij IT zit om backups te kunnen uitvoeren. (en die allemaal screening ondergaan hebben en CDA'tjes & NDA'tjes hebben ondertekend )

Er zijn strenge eisen aan de opzet verbonden en daarom is gedacht aan een 100% custom (maar toch goedkope) oplossing.
(LFS router die ook in die afgeschermde ruimte komt te staan)

We vonden het niet erg slim om de beveiling in handen te leggen van derden. (bvb software pakket kopen dat zogezegd 'superveilig' zou moeten zijn -- je geeft dan ook nog eens de controle over die veiligheid vh netwerk weg)

(het netwerk is natuurlijk niet in de aard van 192.168.x.y)

Er is gedacht aan een apart subnet op te zetten, maar dit werd te omslachtig gevonden. Veel effort nodig (dns servers aanpassen, backup programmas aan de IT kant , labo pcs, etc aanpassen.) Nu blijven ze allemaal hun PC naam houden en hun vast ip adres, en wordt er hevig gefilterd wie er allemaal op wilt aanloggen.

Daarom is het een pure pakket filter die eigenlijk tussen 2 hubs komt te staan. 1 hub fysiek buiten de ruimte en 1 binnen. Enkel pakketjes die vd 4 PCs komen die toegelaten zijn en enkel SSH aanspreken, mogen door de router. Al de rest moet genegeerd worden.

Ik wist dat PREROUTING enkel voor Network Adress Translation werd gebruikt, maar ik dacht zo 'als alle pakketjes toch door die chain komen, kan ik die regeltjes best daar zetten.' Anders moeten ze ook in de INPUT en in de FORWARD chain komen te staan. Misschien bekeek ik het een beetje teveel vanuit een programmeers standpunt en wou ik wat besparen op typen .


btw, als ik enkel 4 welbepaalde PCs (ip/mac) wil toestaan, moet ik dan voor elk regeltje ook het subnetmask aanduiden?
Zoals dat -foutieve- PREROUTING regeltje, '-s 192.168.x.y/32' of moet ik echt het algemene netwerk subnetmask ingeven ( /16 )?


Nelske, ik ben geen linux guru ( zoals jij hehe ), maar wel linux freak.
Wat bedoelde je juist met het schrijven van 'als ze op hetzelfde netwerk zitten, zal het niet gaan omdat er geen routering word toegepast?'

Netwerk pakketjes worden toch gebroadcast op het medium (1 botsingsdomein) en de router zal deze toch ook binnenkrijgen als ze op de eth0 aankomen? Of mis ik iets?

(i know... i love long replies )

[Equator]

Wat nelske bedoelt met "Er vindt geen routering plaats binnen 1 subnet." is dit:

routing is op zijn simpelste manier, aangeven via welke weg je van a naar b komt.
Woon jij in straat a, met 253 woningen, 1 poort en 1 groot gat, en je ben op zoek naar een woning in straat b, dan zal je via de poort moeten lopen.
Je komt dan in straat b.
in routing, is dat (heel simplistisch) je zit in a.201 en je bent op zoek naar b.15, dan ga je via a.254 naar b254 naar b.15
lekker duidelijk, je weet dat je naar een andere straat moet, dus loop je via de poort.
Maar wat jij hebt gedaan in je voorbeeld, is geprobeerd een straat te verdelen in 2 straaten, zonder er een poort in te plaatsen.
opdat moment wil je van a.203 naar a.13. Je weet dat je dan niet door de poort hoeft, omdat het in je eigen straat ligt.

Wil je dus kunnen routeren binnen een netwerk, dan moeten de netwerken logisch van alkaar gescheiden zijn.
dus in een ander subnet.
192.168.1.0 255.255.255.0 ligt in een ander subnet als 192.168.2.0 255.255.255.0.
In een netwerkvorm:

code:

192.168.1.0 / 24 <---->|Router|<---->192.168.2.0 / 24

Dit gaat werken.

code:

192.168.1.0 / 24 <---->|Router|<---->192.168.1.0 / 24

dat werkt niet. Omdat alle adressen in het netwerk denken dat ze in hun eigen straat moeten zijn

Ik hoop dat het duidelijk is.
gr
CJ

[Verwijderd]

Op dinsdag 08 januari 2002 11:26 schreef DeJean het volgende:
Ik zit in een groot bedrijf (~2500 PCs). Momenteel hebben we verscheidene beveilingingsopdrachten en het labo waarin we werken is niet veilig meer geacht. (wel fysiek, maar niet ivm netwerk).

Kijk, dit zijn de leukere netwerkjes
Is dat netwerk onderverdeelt in subnetten (wat ik wel mag hopen) of vallen alle computers in het netwerk binnen 1 subnet (Wat niet te hopen is)?

We zitten allemaal op hetzelfde (grote klasse netwerk en de opzet is om remote te kunnen inloggen op die labopc's enkel via SSH, en maar door 4 personen van dat grote netwerk. 3 personen die het werk gaan doen en 1 persoon die bij IT zit om backups te kunnen uitvoeren. (en die allemaal screening ondergaan hebben en CDA'tjes & NDA'tjes hebben ondertekend )

Die labopc's zitten staan die fysiek gescheiden van alle andere PC's of staan er nog meer PC's in de directe omgeving? Als ze fysiek gescheiden staan, dan is de kans namelijk redelijk groot aanwezig (als het netwerk goed in elkaar zit), dat ze al in een apart subnet vallen.
Als dit het geval is, dan ben je al een heel eind
Een goed netwerk (zeker als het zo groot is) wordt onderverdeeld in subnetten, zodat per subnet een stel regels opgesteld kan worden (denk aan routering, beveiliging etc).
Dit is echt iets om even duidelijk uit te vogelen in ieder geval. De structuur van het netwerk, is zeker bij zo'n groot netwerk met dergelijke wensen heel erg belangrijk. Zeker als die 4 personen zich niet allemaal op ongeveer dezelfde fysieke locatie in het bedrijf bevinden.

Er zijn strenge eisen aan de opzet verbonden en daarom is gedacht aan een 100% custom (maar toch goedkope) oplossing.
(LFS router die ook in die afgeschermde ruimte komt te staan)

Het woordje "router" doet mijn vermoeden waarschijnlijk bevestigen dat het om verschillende subnetten gaat (anders kan je het moeilijk router noemen )
Dit moet dus de machine zijn, die het ene subnet (of meerdere subnetten) verbind met het subnet waarin de labopc's zich bevinden.
Als alles in 1 groot subnet zit, dan gaat het niet werken zoals ik al eerder gezegd heb. Binnen een subnet betekent het, dat wanneer je een andere computer wil bereiken in datzelfde subnet je hem direct moet kunnen bereiken. Er mag dus geen computer, cq router tussen staan. Simpelweg omdat zo'n router dan 2 IP's in hetzelfde subnet zou moeten hebben.
Hij krijgt een request op interface1, maar weet vervolgens niet over welke interface hij het naar buiten moet sturen, omdat beide ip's in hetzelfde subnet vallen. Hij kan dus geen routeringsbeslissing nemen.
Als je 2 aparte subnetten hebt, zeg "A" en "B", dan weet een router dat wanneer een request vanaf subnet A komt dat bestemd is voor subnet B, dat er gerouteerd moet worden.
Zoals jij de situatie schetst, komt er een request vanaf subnet A en dat moet gerouteerd worden naar subnet A (Laat hij nou net 2 interfaces voor subnet A hebben en dus niet kunnen bepalen over welke hij het naar buiten moet sturen).

Hier zou eventueel met iproute2 een oplossing voor te verzinnen zijn, maar dat lijkt me niet gewenst, aangezien de beveiling met aparte subnetten veel beter en netter te maken is, dan een oplossing waarbij je allereli kunstgrepen moet toe gaan passen.

We vonden het niet erg slim om de beveiling in handen te leggen van derden. (bvb software pakket kopen dat zogezegd 'superveilig' zou moeten zijn -- je geeft dan ook nog eens de controle over die veiligheid vh netwerk weg)

(het netwerk is natuurlijk niet in de aard van 192.168.x.y)

Mjah, mensen die iets dergelijks aan moeten leggen hebben ook non--disclosure contracten moeten tekenen; desnoods stel je die nog extra op voordat je ze inhuurt

Maar zelf spelen is natuurlijk veel leuker, zeker als je wat ervaring met linux en netwerken hebt. Verzeker jezelf er echter wel van dat alles veilig is zodra je het af hebt!! (sorry voor het vette deel, maar als ik het zo hoor is veiligheid echt een major issue in dit geval )

Er is gedacht aan een apart subnet op te zetten, maar dit werd te omslachtig gevonden. Veel effort nodig (dns servers aanpassen, backup programmas aan de IT kant , labo pcs, etc aanpassen.) Nu blijven ze allemaal hun PC naam houden en hun vast ip adres, en wordt er hevig gefilterd wie er allemaal op wilt aanloggen.

Ik zou er toch echt voor kiezen om een apart subnet op te zetten, vanwege eerder genoemde punten. DNS omzetting moet niet zo'n probleem zijn, aangezien het maar om een paar computers gaat in dat laboratorium. Verder neem ik aan dat er in een dergelijk groot bedrijf met DHCP/BOOTP gewerkt wordt en dat netwerkinstellingen niet statisch ingevoerd worden op elke PC. Dit zou een ramp zijn voor systeembeheerders
Ofwel de subnet instellingen zijn relatief eenvoudig op de DHCP server aan te passen.

Daarom is het een pure pakket filter die eigenlijk tussen 2 hubs komt te staan. 1 hub fysiek buiten de ruimte en 1 binnen. Enkel pakketjes die vd 4 PCs komen die toegelaten zijn en enkel SSH aanspreken, mogen door de router. Al de rest moet genegeerd worden.

Het kan wel hoor (immers hubs werken op dezelfde manier als je nu wil bereiken met die NAT machine ), dit betekent dat je verkeer dat op de ene interface binnenkomt ten alle tijden naar buiten moet sturen over de andere interface en viceversa. Daar is de Advanced Routing HOWTO denk ik geen slechte start bij (www.linuxdoc.org).
Daarbij is broadcast verkeer uiteraard erg belangrijk, omdat hubs nu eenmaal zo werken.

Ik wist dat PREROUTING enkel voor Network Adress Translation werd gebruikt, maar ik dacht zo 'als alle pakketjes toch door die chain komen, kan ik die regeltjes best daar zetten.' Anders moeten ze ook in de INPUT en in de FORWARD chain komen te staan. Misschien bekeek ik het een beetje teveel vanuit een programmeers standpunt en wou ik wat besparen op typen .

Ghehehe
Dat standpunt ken ik maar al te goed
Waarom meer moeite doen dan nodig is (/me is ook programmeur ).

btw, als ik enkel 4 welbepaalde PCs (ip/mac) wil toestaan, moet ik dan voor elk regeltje ook het subnetmask aanduiden?
Zoals dat -foutieve- PREROUTING regeltje, '-s 192.168.x.y/32' of moet ik echt het algemene netwerk subnetmask ingeven ( /16 )?

Als het om hosts gaat (dus subnetmask van 32), dan mag je het weglaten, aangezien een IP adres alleen een host impliceert.
Je zal dus een aantal FORWARD regels krijgen waarmee je die 4 personen met hun IP en MAC-adres doorlaat naar die labopc's.
Je moet aangezien je geen subnetten hebt, dus voor elke persoon voor alle labopc's een ACCEPT regel aanmaken in de FORWARD chain.
Dus per persoon worden dit voor de 4 labopc's 4 regels die verkeer vanaf die persoon naar die labopc's toelaten en 4 regels die verkeer vanaf de labopc's naar die betreffende persoon teolaten.
Je krijgt zo dus voor 4 mensen en 4 labopc's 32 accept regels (16 richting labo en 16 vanaf labo)
Daarachteraan maak je dus de catch al REJECT/DROP regel (of je zet de FORWARD policy op REJECT/DROP).

Nelske, ik ben geen linux guru ( zoals jij hehe ), maar wel linux freak.
Wat bedoelde je juist met het schrijven van 'als ze op hetzelfde netwerk zitten, zal het niet gaan omdat er geen routering word toegepast?'

Zie bovenstaande

Netwerk pakketjes worden toch gebroadcast op het medium (1 botsingsdomein) en de router zal deze toch ook binnenkrijgen als ze op de eth0 aankomen? Of mis ik iets?

Yupz, dat is zo
Echter zal die machine normaliter niet weten dat hij die broadcast door moet sturen. Daar is wel een oplossing voor te verzinnen, zoals ik al eerder aangaf, hoewel ik toch voor verschillende subnetten zou gaan (ja ik blijf er op hameren )
Ik heb regelmatig (ook wel eens voor werk) met netwerken gewerkt (en hier thuis heb ik een absurt ingewikkeld netwerk liggen ) en dit is hetgene ik naar beste weten over netwerken weet; ik hoop dat je er iets aan hebt

(i know... i love long replies )

You're not the only one

[edit]
Aargh, als chello nou ook nog eens mee zou willen werken.
Deze post stond dus al bijna een uur klaar om te verzenden

[Verwijderd]

Wow cool.
Bedankt voor de reply...

Die labopc's zitten staan die fysiek gescheiden van alle andere PC's of staan er nog meer PC's in de directe omgeving?

ja, ze staan (of zitten ) fysiek gescheiden. We hebben veel ruimtes hier. Labo ruimte voor maken prototypen enzo, administratieve ruimte waar ik nu deze reply aan het schrijven ben, fabrieksgebouw en testruimte.

Na wat rondgeneus in de ip instellingen van verschillende PCs, zie ik dat voor de ipadressen (A.B.C.D) A.B voor administratief gebouw dezelfde zijn als laboruimte.
C (en D natuurlijk ook) verschillend.
Submask is 255.255.252.0 voor ene en 255.255.254.0 voor andere. Ehh.. dat is respectievelijk A.B.C.D/22 en A.B.C.D/23, right?

Dus dat betekend dat ze al in aparte subnetten staan. (was eigenlijk wel te verwachten) Oef!

Als alles in 1 groot subnet zit, dan gaat het niet werken zoals ik al eerder gezegd heb. Binnen een subnet betekent het, dat wanneer je een andere computer wil bereiken in datzelfde subnet je hem direct moet kunnen bereiken. Er mag dus geen computer, cq router tussen staan. Simpelweg omdat zo'n router dan 2 IP's in hetzelfde subnet zou moeten hebben.

Bij het lezen van die laatste zin, viel natuurlijk mijnen euro . Hehe, tuurlijk is er dan geen sprake van routering als beide nics in de router in hetzelfde subnet zitten. Was gisteren wat veel aan het dromen denk ik.

Maar zelf spelen is natuurlijk veel leuker, zeker als je wat ervaring met linux en netwerken hebt. Verzeker jezelf er echter wel van dat alles veilig is zodra je het af hebt!! (sorry voor het vette deel, maar als ik het zo hoor is veiligheid echt een major issue in dit geval )

'major issue' is nog licht uitgedrukt. "het gaat toch wel écht veilig zijn eh?!?", hoor ik ze constant vragen
Perfecte beveiliging is utopia, maar ik ga natuurlijk wel m'n best doen om het zo veilig mogelijk te maken zonder alle gebruiksvriendelijkheid uit de raam te smijten.

Maar eigenlijk is dit de eeuwige balans/weegschaal: aan de ene kant gebruiksvriendelijkheid en gemak. Andere kant de veiligheid/privacy/...

Je kunt absolute veiligheid garanderen door de servers in een betonnen, dan stalen en om zeker te zijn nog eens in een loden bunker bunker te plaatsen. Dit 58km onder de grond plaatsen zonder enige toegangswegen, servers uitrusten zonder netwerk interfaces en zorgen dat ze nooit opgezet worden.

Het kan wel hoor (immers hubs werken op dezelfde manier als je nu wil bereiken met die NAT machine ), dit betekent dat je verkeer dat op de ene interface binnenkomt ten alle tijden naar buiten moet sturen over de andere interface en viceversa.
Daarbij is broadcast verkeer uiteraard erg belangrijk, omdat hubs nu eenmaal zo werken.

hm, voor de toepassing van die linuxrouter hoeft er toch geen broadcast verkeer door te worden gelaten? (als hij zou worden geconfigureerd als een 'filtering hub') Enkel een paar poorten vd dns servers en de connectie van SSH en X11-SSH-FORWARD van/naar die 4 personen.

Voor de rest moet dat labo bijna 'onzichtbaar' zijn op de 'netwerk-map' vh bedrijf als een geheel.

Of droom ik weer ?

Dus per persoon worden dit voor de 4 labopc's 4 regels die verkeer vanaf die persoon naar die labopc's toelaten en 4 regels die verkeer vanaf de labopc's naar die betreffende persoon teolaten.
Je krijgt zo dus voor 4 mensen en 4 labopc's 32 accept regels (16 richting labo en 16 vanaf labo)
Daarachteraan maak je dus de catch al REJECT/DROP regel (of je zet de FORWARD policy op REJECT/DROP).

Alle policies staan op DROP, en heel nauwlettend moeten zaken die wel doormogen apart ge-'iptabled' worden.
Ik heb gisteren het iptables script min of meer afgewerkt en, zoals je hierboven aangeeft, het is heel wat typ en copy-en-paste werk

Maar ik heb "-s ${LABO_LAN} -m state --state RELATED,ESTABLISHED" genomen voor verkeer dat terug moet komen. (alle pc's in labo mogen zélf geen connecties nr buiten (internet of naar een lukrake pc van iemand in het bedrijf) maken. Enkel maar "antwoorden" op SSH. (ik weet niet juist hoe ik hier moeten omschrijven...)

Ik heb regelmatig (ook wel eens voor werk) met netwerken gewerkt (en hier thuis heb ik een absurt ingewikkeld netwerk liggen ) en dit is hetgene ik naar beste weten over netwerken weet; ik hoop dat je er iets aan hebt

Tuuuuurlijk!
Ik heb voor gisteren nog nooit met iptables gewerkt, dus zoveel ken ik er ook niet van, maar eens je het doorhebt is iptables wel een vd krachtigste netwerk tools die je voorhanden hebt in linux. (samen met iproute2, wat ook iets zeer krachtig is (GRE tunnels out of the box, you got to love it ! ))

Aargh, als chello nou ook nog eens mee zou willen werken.
Deze post stond dus al bijna een uur klaar om te verzenden

hehe, niet álle netwerken zijn evengoed opgebouwd als we graag zouden willen...

[Verwijderd]

/me heeft weer wat geleerd!

Als 't super veilig moet zijn zou ik ook is openBSD in overweging nemen.

Ik zou ook wat tijd in de config van die ssh server steken, en b.v. enkel de nodige users toegang geven, en zo veel mogelijk andere dingen uitzetten.

En dan natuurlijk aboneren op de mailinglist met security updates...en die ook installeren, duh! (op router en ssh-server)

En alles uitzetten wat je niet echt nodig hebt...maar dat spreekt voor zich.

Al zou je dit alles waarschijnlijk automatisch wel doen...