bronvermelding

Hoofdregel 1: Vertrouw niets en niemand!

Dit klinkt heel erg, maar aan de hand van een aantal voorbeelden zal het nut van deze regel worden aangetoond.

Anekdote 1
U wordt gebeld door iemand die u het volgende vertelt: "Hallo, ik ben v/d Water van de afdeling infrastructuur. Ik heb het rootwachtwoord nodig voor de configuratie van de hubs in de backbone." In de veronderstelling dat u met een collega te maken hebt, geeft u hem het rootwachtwoord.

Anekdote 2
U wordt gebeld door iemand die een telefonische enquete afneemt. De resultaten van dit onderzoek staan binnenkort in uw IT-vakblad. "Of uw netwerk is aangesloten op internet?". "Of u weet op welke manier dat is aangesloten?". "Welke firewall-software u gebruikt?". Op alle vragen geeft u gehoorzaam antwoord, ten slotte vraagt men niet om het rootwachtwoord.

Anekdote 3
U krijgt een e-mailbericht van een bekende relatie met daarbij een programma dat "u gezien moet hebben!" U pakt het bestand uit en bekijkt met plezier de leuke animatie. Natuurlijk bent u als beheerder van het netwerk altijd als root ingelogd.

Bovenstaande anekdotes zijn praktijdvoorbeelden. De eerste anekdote is natuurlik vrij eenvoudig te doorzien. Geef nooit het rootwachtwoord af. Anekdote 2 lijkt onschuldig, maar levert potentiele inbrekers een schat aan informatie op. Als men weet welke gatewaysoftware u gebruikt, kan men ook de bekende bugs daarin achterhalen en gebruiken. Een simpel voorbeeld is het gebruik van het programma 'nmap'.

Starting nmap V. 2.12 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
Interesting ports on pcp (192.168.5.1):
 

Port	State	Protocol	Service
21	open	tcp	ftp
22	open	tcp	ssh
25	open	tcp	smtp
79	open	tcp	finger
515	open	tcp	printer
1024	open	tcp	unknown
6000	open	tcp	X11

Nmap run completed -- 1 IP address (1 host up) scanned in 1 second
root@pcp:~#

Zoals u ziet, laat dit programa al zien welke poorten er bij een systeem openstaan .
Zijn al deze diensten nodig? Zo te zien staat het programma 'finger' open. Wat laat dat zien?

Welcome to Linux version 2.2.19 at pcp !

    11:08 up 9 days, 22:13, 2 users, load average: 0.41, 0.29, 0.16

Login: root             Name: root
Directory: /root        Shell: /bin/bash
On since Thu Aug 30 18:45 (CEST) on tty1, idle 2 days 19:22
On since Thu Aug 30 18:41 (CEST) on tty2, idle 18:12
On since Thu Aug 30 18:46 (CEST) on tty3, idle 4 days 19:00
Mail last read Wed Aug 29 02:55 2001 (CEST)
No Plan.
root@pcp:~#

Zo weet u in twee stappen dat het betreffende systeem Linux versie 2.2.19 gebruikt en kunt u op het internet bekende bugs opzoeken om deze te gebruiken. Een hekje (#) in /etc/inetd.conf en dit was wat moeilijker te achterhalen geweest.
Anekdote 3 is wat subtieler. Wat u niet weet, is dat het animatieprogramma het SUID-bit op de standaar-shell heeft gezet. Dat was mogelijk omdat u toch als root was ingelogd. Iedereen die nu inlogt, heeft dezelfde rechten als de rootgebruiker en kan deze misbruiken.
Een van de uitwerkingen van de eerdergenoemde 'regel 1' betekent dat een systeem zodanig dient te zijn ingesteld dat men geen toegang krijgt, tenzij... Dit is een veel betere methode dan proberen om alles wat gevaarlijk kan zijn, dicht te maken. In het laatste geval kunt u iets over het hoofd zien. Dat is met de eerste methode niet mogelijk.
Aan de basis van alle beveiligingsmaatregelen moet een goed beveiligingsbeleid staan. Dat zou kunnen beginnen met de eerdergenoemde 'regel 1'. Meer over het opzetten van een beveiligingspolicy vind u in rfc1244 en een goed voorbeeld staat gedocumenteerd in rfc1281.
In de rest van deze tekst richten we ons op de maatregelen die kunnen worden genomen.

Bovenstaande anekdotes zijn maar een paar voorbeelden van het brede arsenaal dat systeemkrakers tot hun beschikking hebben. Maar gelukkig kunt u ook wat doen. Een aantal van deze maatregelen komen hier aan de orde.

TCP-wrappers
Een voorbeeld va een inetd-configuratieregel is het telnet-serverproces. De regel in /etc/inetd.conf ziet er als volgt uit:

Dit betekent dat in /etc/services een regel staat met de term 'telnet'. In het bestand staat:

Sterker nog, als er een pakket binnenkomt op poort 23 en het is een TCP- of UDP-pakket, dan wordt de dienst 'telnet' gestart.
Verder staat er in /etc/inetd.conf dat het een 'stream' aan pakketjes is, dat men deze via TCP verwacht (dus 'inetd' luistert niet naar 23/UDP hoewel dit volgens /etc/services wel mag). Er wordt niet gewacht na het starten van de betreffende server en deze server wordt als rootgebruiker gestart.
Het te starten programma is het programma '/usr/sbin/tcpd' met als argumen 'in.telnetd'. Maar dat is een beetje merkwaardig, want men zou mogen verwachten dat 'in.telnetd' het gewenste serverprogramma is.

Zoals u zojuist zag, wordt er door het inetd-programma geen telnetd-programma gestart, maar 'tcpd'. Dit is een zogenaamde 'TCP-wrapper'. Het programma 'tcpd' fungeert als een soort veiligheidslaag voordat het gewenste serverproces, in dit geval 'in.telnetd', wordt gestart.
Het tcpd-programma zal beoordelen aan de hand van de inhoud van twee bestanden of het systeem dat de server 'in.telnetd' wil starten, dat wel mag. Daarvoor gebruikt het twee bestanden, te weten /etc/hosts.allow en /etc/hosts.deny. De volgorde daarbij is als volgt. Als een systeem in /etc/hosts.allow is vermeld, zal de dienst worden toegestaan. Als het systeem in /etc/hosts.deny staat vermeld, zal de dienst worden geweigerd. In alle andere gevallen zal de dienst worden toegestaan.

hosts.allow
In het bestand /etc/hosts.allow kunt u alle systemen vermelden die een bepaalde server wel mogen opstarten. Een voorbeeldbestand kan er als volgt uitzien:

Hierin betekend 'ALL: LOCAL' dat alle poorten toegankelijk zijn voor alle diensten vanaf hetzelfde systeem.
'ALL: .dsinet.org' betekent dat systemen uit het domein 'dsinet.org' toegang hebben tot alle diensten.
'in.telnetd: .selwerd.nl' betekent dat het is toegestaan om vanaf alle systemen uit het domein 'selwerd.nl' een telnet-verbinding te starten met uw systeem.

hosts.deny
In het bestand /etc/hosts.deny kunt u alle systemen vermelden die een bepaalde server niet mogen opstarten. Een voorbeeldbestand kan er als volgt uitzien:

Dit is tevens de beste instelling. Alle verbindingen van alle systemen worden geweigerd. Omdat er eerst gecontroleerd wordt in het bestand /etc/hosts.allow betekent dit, dat als men daar niet in staat vermeld, men geen rechten heeft tot willekeurig welke server.
Dit is altijd de beste beveiligingsstrategie. Alles dicht, tenzij...

SUID-recht
Let op de programma's die het SUID-recht gebruiken. Een aantal van deze programma's hebben het nodig om op de juiste wijze te functioneren, een aantal andere hebben het door gemakzucht van de maker van het programma. Deze programma's kunnen vaak op creatieve wijze worden misbruikt. Het vinden van alle bestanden op het systeem waarvan het SUID-bit is ingesteld, gaat met de volgende opdracht:

U kunt het systeem zodanig configureren dat dit regelmatig wordt gecontroleerd.

Pakketbeheer
Als u software via .rpm- of .deb-bestanden installeert, is het zaak te kunnen vaststellen dat deze niet gecorrumpeerd zijn. U kunt de integriteit van de bestanden controleren door gebruik te maken van het PGP- of GPG-programma. Het installeren van deze programma's is een aanrader voor iedereen die beveiliging serieus neemt.
Ook komt het ovor dat u na verloop van tijd bepaalde bestanden afkomstig uit een .rpm-pakket zult overschrijven met een andere versie. Om te constateren met welke pakketen dit is gebeurt, kan de volgende opdracht uikomst bieden:

Zoals u ziet, is dat een behoorlijke lijst aan bestanden die afwijken van de orginele rpm-versie. De letters voor de bestandsnamen verduidelijken meer over de afwijking:

• 5: de MD5-check ging niet goed
• S: de bestandsgrootte komt niet overeen met de originele versie.
• L: een Symlink is gewijzigd.
• T: de Mtime wijkt af.
• D: het Device is gewijzigd.
• U: er is een andere gebruiker eigenaar geworden.
• G: er is een andere groep eigenaar geworden.
• M: de Modus is gewijzigd (inclusief rechten en bestandstype).

Ook is het aan te raden om regelmatig te controleren of de leverancier van uw Linux-distributie updates heeft gemaakt die gevonden bugs oplossen. De betere Linux-distributies hebben daar zeer geavanceerde gereedschappen voor.

setgid
Het setgid-recht kan zeer nuttig zijn voor het consistent houden van de groepsrechten voor bestanden in bepaalde directories.

Wachtwoorden
Stel wachtwoordveroudering in. Zorg dat de verouderingsperiode niet samenvalt met een makkelijke periode. Dus niet driemaandelijks om te voorkomen dat gebruikers wachtwoorden als 'lente' en 'voorjaar' gaan gebruiken. Geef nieuwe gebruikers ook niet meteen een makkelijk wachtwoord dat ze een tijdje kunnen gebruiken. Geef ze een makkelijk wachtwoord met de instelling dat ze deze zelf direct moeten wijzigen. Op die manier weten ze ook dat geen adnere gebruikers even hun account kunnen 'lenen'.
Zorg dat bepaalde accounts niet worden 'gedeeld'. Als iemand een bepaalde functionaliteit wil, geef deze dan. Of beter, laat zijn of haar meerdere deze functionaliteit aanvragen.

ssh
De afkorting 'ssh' staat voor 'secure shell'. Het is precies wat de naam zegt, een veilige shell. De werking is als volgt:

Het ssh-programma zorgt voor een versleutelde telnet-sessie met een ander systeem en is de methode waarmee een beheerder meerdere systemen kan beheren zonder dat hij bang hoeft te zijn dat iemand zijn wachtwoord van het netwerk plukt.

Bij het gebruik van 'ssh' kunt u ook gebruikmaken van zogenaamde public-key-encryptie. Daartoe maakt u een sleutelpaar aan, bestaande uit een publiek en een geheim deel. Het maken van de sleutel gebeurt met het programma 'ssh-keygen':

Zoals u ziet, moet u twee keer een ontcijferzin intypen. Dit is een voor u makkelijk te onthouden zin zoals: "Dit is mijn geheim." Vervolgens wordt een publieke (in ~/.ssh/identity) en en geheime sleutel (in ~/.ssh/identity.pub) aangemaakt. De bovenstaande <heel veel nummers> is in werkelijkheid een hele lange regel cijfers. U kopieert nu deze regel naar uw bestand ~/.ssh/authorized_keys op het systeem waar u op wilt kunnen inloggen. Als u daarna 'ssh' opstart, kunt u zonder wachtwoord op te geven inloggen. Wel moet u natuurlijk uw 'passphrase'  intypen.

Host security

Shadow passwords
Zorg ervoor dat de versleutelde wachtwoorden van gebruikers niet in /etc/passwd staan mar in /etc/shadow en dat dit bestand geen rechten heeft. Door het SUID-bit op het programma 'passwd' kunnen wachtwoorden toch wel worden gewijzigd.

inetd
Controleer, bijvoorbeeld met het programma 'nmap', of er diensten door 'inetd' kunnen worden verricht die niet nodig zijn. Als u een Samba-file- en -printerserver gebruikt die ook de e-mail van gebruikers beheert, hoeven alelen de betreffende poorten open te staan en geen telnet, ftp of een dergelijk programma.

root
Log niet als root in op het systeem! Log in onder een normale account. Als u vervolgens beheerstaken uit wilt voeren, gebruikt u de opdracht 'su' (van SuperUser):

Als u achter de opdracht een minteken (-) zet, wordt de root-shell als login-shell opgestart. De opstartbestanden zoals /etc/profile worden dan doorlopen. Zo kunt u ook inloggen onder een andere gebruikersnaam ('su - koos'). Beperk het gebruik van die sessie tot het minimum. Als u uw systeem verlaat (ook als u 'even' naar het toilet gaat), moet u de toegang tot het werkstation blokkeren. Gebruik 'xlock' onder X-windows en 'vlock' of 'screen' op een terminal.
Atel ook een mailalias of '.forward' in zodat u berichten voor de rootgebruiker op uw eigen account ontvangt. Stel ook 'syslogd' zodanig in dat u ernstige meldignen zo snel mogelijk te zien krijgt.
Als de rootgebruiker de enige gebruiker is dei mag telnetten naar het systeem, kunt u ook het /etc/securetty-bestand hebt, dient deze een lijst van alle devices te bevatten (zonder /dev ervoor en op elke regel een) vanwaar de rootgebruiker mag inloggen. Als u bijvoorbeeld alleen de regels 'tty1' en 'tty2' plaatst, kan met niet via een telnet-sessie rechtstreeks als root inloggen. Wel as normale gebruiker om dan via de opdracht 'su' alsnog rootrechten te verkrijgen.

Limieten
Ook de gebruikersomgeving kan leiden tot beveiligingsproblemen. Zo is de Linux-kernel (versie 2.2) op dit moment in staat om maximaal 1024 processen te beheren. Als u geen limiet hanteert op het aantal processen dat een individule gebruiker mag starten, kan een gebruiker bijvoorbeeld een script schrijven dat elke keer zichzelf start. Op een bepaald moment is het maximum bereikt en kunnen geen nieuwe processen meer worden gecreeerd. Ook niet als dit een shell is voor de rootgebruiker om het probleem op te lossen. Gelukkig is hier een oplossing voor in de vorm van de opdracht 'ulimit'. Met de optie '-a' geeft het de actuele instellingen weer:

Hieruit blijkt dat het maximumaantal processen dat deze gebruiker mag starten 1024 is, oftewel het maximum van het systeem. Met de volgende opdracht wordt dit aantal drastisch gereduceerd:

De betreffende gebruiker kan nu maximaal 200 processen starten. Deze regel opnemen in /etc/profile is dus voor dit probleem een aanrader. Zo kunt u ook de hoeveelheid CPU-tijd (optie '-t'), de maximale hoeveelheid virtueel geheugen (optie '-v') enzovoort aanpassen.
Nu is het probleem met het maximumaantal processen van tijdelijke aard want per kernelversie 2.4 is dit aantal opgehoogd naar een zelf instelbare maximumwaarde. Tests met 13.000 processen zijn reeds succesvol verlopen.

In dit deel van het hoofdstuk volgen nog een paar tips rond het loginproces.

/etc/nologin
Het bestand /etc/nologin de mogelijkheid dat alleen maar de rootgebruiker mag inloggen.

/etc/securetty
De poorten die in /etc/securetty worden genoemd, zijn de poorten via welke de rootgebruiker direct mag inloggen. Dit kan de moglijkheid ontnemen om vanaf een telnet-sessie rechtstreeks als rootgebruiker in te loggen.

/etc/login.defs
Het bestand /etc/login.defs bevat een groot aantal parameters waarmee het gedrag van het programma 'login' kan worden gestuurd. Het bestand /etc/issue bevat de teksten waarmee het loginprogramma zich presenteert. Daarin kunt u ook variabelen opnemen zoals de devicenaam.

chsh
Met de opdracht 'chsh' kan elke gebruiker zijn login-shell wijzigen in een van de shells die in het bestand /etc/shells is vermeld.

utmp/wtmp
Tijdens het inloggen worden de bestanden /var/run/utmp en /var/log/wtmp bijgewerkt. Deze bevatten records van de diverse in- en uitlogactiviteiten. Deze bestanden zijn niet met bijvoorbeeld 'less' leesbaar, maar wel met andere programma's.

last
Een van de programma's waarmee de records in 'utmp' en 'wtmp' kunnen worden gelezen, is de opdracht 'last':

Hieruit valt af te leiden dat er een aantal usersessies vanaf het netwerk zijn geweest vanaf het systeem 'piii-800'. Daarvan duurt de langste sessie nog steeds voort :). Het betrof een sessei vanaf het netwerk omdat een pseudo-tty (pts) werd gebruikt. Op het systeem is op de virtuele console 6 de gebruiker root ingelogd. Gebruiker 'koos' is op virtuele console 2 ingelogd. Het systeem is voor het laatst geboot op 28 augustus.

who
Ook de opdracht 'who' gebruikt de records uit het utmp-bestand:

ac
Ook het programma 'ac' leest de utmp- en wtmp-records omdaaruit te bepalen hoe lang het systeem door wie is gebruikt. Met de optie '-p' krijgt u bijvoorbeeld persoonlijke totalen te zien:

bronvermelding

Inleiding

Een firewall is een systeem dat fungeert als gateway in een netwerk en daarmee twee netwerken met elkaar verbindt. De firewall is het deel dat zorgt dat niet alle pakketten van netwerk A naar netwerk B kunnen. Op deze manier wordt bijvoorbeeld voorkomen dat iemand vanaf het internet een telnet-sessie kan starten op uw, via het ISDN aangesloten, gateway systeem.
Er bestaan grofweg twee soorten firewalls, te weten de proxy- en de kernel-firewall. Hieronder een beschrijving van beide soorten.

Proxy
Een proxy-firewall is een applicatie op een besturingssysteem. Het besturingssysteem zelf doet niets om de gegevens van de enenetwerkinterface naar de andere te verplaatsen, dat doet de applicatie. Doordat de pakketten wel door het besturingssysteem en de applicatie moeten worden getransporteerd, levert dat een zekere vertraging op. Daarentegen zijn proxy-firewalls vaak erg flexibel in de manier waarop ze kunnen worden geconfigureerd.

Kernel
Een andere type firewall is de kernel-firewall. Deze regelt in de kernel zelf het doorgeven van gegevens van interface A naar interface B. Daardoor is deze firewall ook sneller dan een proxy-firewall. Daarentegen is de kernel-firewall vaak minder uitgebreid in het aantal configuratiemogelijkheden. De Linux-kernel beschikt over alle mogelijkheden om als kernel-firewall te fungeren. Hoe, dat leest u in dit hoofdstuk.

De basis
Het configureren van de firewall op Linux kent al een lange geschiedenis. Met kernelversie 2.0 gebeurde dit met het programma 'ipfwadm', waarmee men allerlei firewallzaken regelde. Met versie 2.2 gebeurd dat in de vorm van 'ipchains'. Dit zijn regels die eventueel ook achter elkaar kunnen worden gezet om complexe zaken te besturen. Het instellen van deze regels of 'ipchains' gebeurt met de opdracht 'ipchains'.
De Linux-kernel kent vier verschillende sooren regels. de IP INPUT-regels, de IP OUTPUT-regels, de IP FORWARD-regels en de door de gebruiker zelf gedefinieerde regels. Voor elk van deze categorieen wordt een aparte tabel met regels beheerd.
Elke regel bevat criteria voor een datapakket en een bestemming. Als een pakket niet aan de criteria voldoet, wordt de volgende regel geevalueerd. Als deze wel overeenkomt, wordt de volgende regel bepaald door de bijbehorende bestemming. Deze bestemming kan een andere regel zijn of een van de bijzondere waarden ACCEPT, DENY, REJECT, MASQ, REDIRECT of RETURN.

ACCEPT betekend 'laat het pakket door'. DENY betekent dat het pakket moet worden vergeten. REJECT doet hetzelfde als DENY, maar is iets beleefder. Het stuurt nog even een ICMP-pakket naar de afzender met de mededeling dat het pakket is vergeten. MASQ is alleen maar toepasbaar op de FORWARD-chain en zorgt ervoor dat pakketten zodanig gemaskeerd worden dat het lijkt alsof ze van de gateway zelf komen. Dit is wat u doet als u Network Adres Translation (NAT) wilt toepassen. Pakketten die retour komen, worden als zodanig herkend en direct intern doorgestuurd. REDIRECT betekent dat pakketten naar een ander systeem worden doorgestuurd dan oorspornkelijk de bedoeling was. RETURN kan worden gebruikt om vanuit een IP-chain terug te springen naar een vorige.

De praktijk
De opdracht 'ipchains' kent een groot aantal opties. Een aantal daarvan zijn:

• A: voeg de regel toe aan de opgegeven chain.
• D: verwijder een regel uit de opgegeven chain.
• L: geef een overzicht van de opgegeven chain. Als er geen chain is opgegeven, geef dan alle regels weer.
• j: de actie die dient te gebeuren.
• F: flush de regels in een chain. Dit betekent dat alle regels uit de betreffende Chain worden verwijderd.
• X: verwijder de gehele chain. Zonder opties probeert de opdracht om alle niet-standaardchains te verwijderen.
• p: het protocol waarvoor de regel geldt.

Alleen masquerading
Het eerste wat u wilt doen, is waarschijnlijk een lijst zien van de ingestelde regels:

Zoals u ziet, is er maar een regel ingesteld en dat is de FORWARD-chain. Het betreft hier de optie 'masquerading'. De volgende opdracht zet masquerading aan op uw systeem. Dit is wat u vaak als eerste zult willen doen.

Natuurlijk kunt u het hierbij laten en uw systeem verder helemaal open laten staan voor eventuele nieuwsgierige derden. Als het een gatewaysysteem betreft, wilt u waarschijnlijk toch enige mate van beveiliging hebben.

Echte beveiliging
Als u uw firewall goed wilt configureren, gaat u als volgt te werk:

De eerste regel maakt alle chains leeg en de tweede regel verwijderd alle niet-standaard chains (dus alles behalve INPUT, OUTPUT en FORWARD).

Bovenstaande opdrachten betekenen dat de policy van deze chains betekent dat alle pakketten worden geweigerd. Dit komt overeen met de basisregel 1 van het beveiligingsbeleid. Alles uit, tenzij...
Omdat u DENY hebt ingesteld, hoeft u nu alleen nog maar ACCEPT-condities in te stellen voor de diensten die u nodig hebt. Het protocol waarvoor u een ACCEPT-regel wilt invoegen, kunt u vinden door het /etc/services-bestand te raadplegen.

Deze regels voegen aan de INPUT- en OUTPUT-chain de actie ACCEPT toe voor alle pakketten die vanaf de loopback-interface komen. Dit betekent dat u alleen netwerkdiensten van het systeem kunt gebruiken als deze via de loopback-interface worden gegeven. Andere netwerkgebruikers komen voor een gesloten deur.
Voor de resterende regels dient u uit te zoeken welke diensten u allemaal via de firewall wilt doorlaten. De algemene opbouw van de opdracht is:

Via de inhoud van het /etc/services-bestand vindt u het gebruikte protocol en het poortnummer van deze diensten.

Hierbij valt op dat bijvoorbeeld ftp-data via poort 20 gaat en zowel TCP als UDP kan gebruiken, terwijl ftp op poort 21 alleen maar TCP gebruikt. De poortnummers behoren thuis in de velden $SRC_PORT en $DST_PORT. Om een firewall goed te kunnen opbouwen is uitgebreide kennis van de protocollen onontbeerlijk. Het zou te ver gaan om deze uitgebreid te bespreken :) Een goede bron van informatie zijn de RFC's en STD's voor de verschillende protocollen.
De $SRC_IF bij de optie '-i' kan worden gebruikt om naast de IP-adressen $SRC_IP en $DST_IP ook nog de interface op te geven. Dit lijkt dubbel, maar kan een handige methode zijn om bijvoorbeeld spoofing, het imiteren van het IP-adres van een ander systeem, te voorkomen. Op deze manier kan bijvoorbeeld een intern gebruikt IP-adres nooit voorkomen op de externe interface.

Voor het zoeken naar een storing in de firewall, die volgens u goed ozu moeten zijn, maar waar toch bepaalde connecties niet doorheen komen, is de optie '-l' een uitkomst. Als u achter de default-DENY-regel '-l' zet, zal elk niet-doorkomend pakket worden gelogd. Hierna kunt door analyse van het logbestand uitzoeken wat er wel en niet open zou moeten staan. Denk er hierbij aan dat het TCP-protocol nummer 6 is en het UDP-protocol nummer 17, 'ipchains' logt deze namelijk als nummers, niet als namen. Voor de overige protocollen verwijs ik naar het /etc/protocols-bestand.

Voorbeelden
Hieronder een aantal eenvoudige voorbeelden van 'ipchains'. Deze dient u dus aan uw eigen situatie aan te passen.
Als u wilt dat niemand vanuit het interne netwerk een verbinding kan maken met bijvoorbeeld www.telegraaf.nl, zoekt u eerst met 'nslookup' het bijbehorende IP-adres op:

Name: www.telegraaf.nl
Address: 195.64.78.4

>

Nu u het IP-adres weet, kunt u in 'ipchains' de regel toevoegen waarmee u verkeer naar deze site blokeert.

Natuurlijk gebruikt u een DNS-server en deze forward-verzoeken en krijgt U de antwoorden van deze forwarder retour en van niemand anders (LOCIP is uw eigen IP-adres, ippp0 is uw ISDN-interface):

U wilt ftp kunnen gebruiken (de verbindingen gebruiken poortnummers boven de 1023 en onder de 6000):

Voor uw eigen maatwerk is nalezing van de IPCHAINS-HOWTO een absolute aanrader.