From owner-svn-doc-all@FreeBSD.ORG Mon Mar 24 11:00:36 2014 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18B8ACCB; Mon, 24 Mar 2014 11:00:36 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 02C129D; Mon, 24 Mar 2014 11:00:36 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s2OB0ZBY038854; Mon, 24 Mar 2014 11:00:35 GMT (envelope-from remko@svn.freebsd.org) Received: (from remko@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s2OB0ZdT038853; Mon, 24 Mar 2014 11:00:35 GMT (envelope-from remko@svn.freebsd.org) Message-Id: <201403241100.s2OB0ZdT038853@svn.freebsd.org> From: Remko Lodder Date: Mon, 24 Mar 2014 11:00:35 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-translations@freebsd.org Subject: svn commit: r44340 - translations/nl_NL.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-translations MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 24 Mar 2014 11:38:43 +0000 X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 11:00:36 -0000 Author: remko Date: Mon Mar 24 11:00:35 2014 New Revision: 44340 URL: http://svnweb.freebsd.org/changeset/doc/44340 Log: Commit work in progress. Facilitated by: Snow B.V. Modified: translations/nl_NL.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: translations/nl_NL.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- translations/nl_NL.ISO8859-1/books/handbook/firewalls/chapter.xml Mon Mar 24 10:48:45 2014 (r44339) +++ translations/nl_NL.ISO8859-1/books/handbook/firewalls/chapter.xml Mon Mar 24 11:00:35 2014 (r44340) @@ -823,8 +823,1191 @@ pass from { lo0, $localnet } to any keep serieuze onderbrekingen, ook als het externe adres wijzigt. - XXXX RL 773 + Aan de andere kant laat deze ruleset waarschijnlijk + meer verkeer het netwerk in dan gewenst. Een redelijke + instelling zou de volgende makro kunnen bevatten + + client_out = "{ ftp-data, ftp, ssh, domain, pop3, auth, nntp, http, \ +https, cvspserver, 2628, 5999, 8000, 8080 }" + + en bijbehorende passeer regel + + pass inet proto tcp from $localnet to any port $client_out \ +flags S/SA keep state + + Deze wellicht wat vreemde selectie van poorten is + gebaseerd op echte voorbeelden. Per situatie zal deze + ongetwijfeld verschillen, maar de meest bruikbare diensten + worden hier al door gedekt. + + Daarnaast hebben we een aantal extra passeer regels. + Later zullen de meer interessantere behandeld worden. Een + passeer regel die nuttig is voor de gebruikers die de + machine op afstand willen beheren is + + pass in inet proto tcp to port ssh + + of korter gezegd + + pass in inet proto tcp to $ext_if port ssh + + welke er ook de voorkeur heeft. Als laatste moet de + naam-omzettings dienst werken voor de gebruikers: + + udp_services = "{ domain, ntp }" + + Deze wordt aangevuld met een regel die het verkeer + door de firewall heen toestaat: + + pass quick inet proto { tcp, udp } to any port $udp_services keep state + + Let op het quick sleutelwoord in + deze regel. Er is begonnen met het schrijven van een + ruleset welke bestaat uit meerdere regels, hieronder volgt + een uitleg over de relatie tussen de regels in een ruleset. + Regels worden van boven naar beneden ge-evalueerd, in de + volgorde waarin ze beschreven staan in het configuratie + bestand. Voor elk pakketje of elke verbinding welke + ge-evalueerd wordt door PF zal de + laatst overeenkomende regel diegeen + zijn die toegepast wordt. Het quick + sleutelwoord biedt hierin een uitweg van de reguliere + volgorde. Wanneer er een pakketje een quick regel matcht + zal het pakketje verwerkt worden volgens die specifieke + regel. Het verwerken en evalueren van de regels stopt + zonder dat andere regels nog in aanmerking genomen worden + welke mogelijk misschien ook zouden overeenkomen. Dit kan + erg nuttig zijn wanneer er een paar geisoleerde + uitzonderingen zijn op de normale regels. + + Deze regel zorgt er ook voor dat NTP + werkt, welke gebruikt wordt voor tijdsynchronisatie. EEn + ding dat beide protocollen (DNS en NTP) gemeen hebben is + dat beiden onder bepaalde omstandigheden gebruik kunnen + maken van zowel TCP als UDP. + + + + + Het trieste oude <acronym>FTP</acronym> + De korte lijst van voorkomende TCP + poorten zoals hierboven beschreven bevat onder andere + FTP. FTP is een + triest oud ding en een probleemkindje, in het bijzonder + voor iedereen die probeert om FTP + en firewalls met elkaar te combineren. + FTP is een old en raar protocol met + veel dingen om niet leuk te vinden. De meest voorkomende + punten tegen FTP zijn + + + + Wachtwoorden worden onbeveiligd overgestuurd + + + + Het protocol vereist het gebruik van minstens + twee TCP verbindingen (controle + en data) op verschillende poorten + + + + Wanneer er verbinding is wordt data via + willekeurige poorten verstuurd + + + + Al deze voorgaande punten zorgen voor een + beveiligingsuitdaging, nog voordat er ook maar gekeken + kan worden naar potentiele zwakheden in de client of + server software welke kunnen leiden tot beveiligings + incidenten. Deze dingen gebeuren. + + In elk geval bestaan er wel alternatieven die meer + modern en veiliger zijn om bestanden uit te wisselen + zoals &man.sftp.1; en &man.scp.1; welke zowel de + authenticatie als bestandsoverdracht via encryptie regelen. + Competente IT professionals zouden er + goed aan doen om een andere voorkeur te hebben voor + bestandsuitwisseling dan FTP. + + Los van de professionaliteit en voorkeuren is het + algemeen bekend dat er soms gewerkt moet worden met dingen + waar liever niet mee gewerkt wordt. In het geval van + FTP door firewalls heen is onze + belangrijkste handeling het verkeer omleiden naar een + klein programmaatje wat specifiek voor dit doel geschreven + is. + + + <acronym>FTP</acronym> via een omleiding: + <application>ftp-proxy</application> + + Het inschakelen van FTP + overdrachten door de firewall heen is opmerkelijk + simpel dankzij het FTP proxy + programma genaamd &man.ftp-proxy.8; welke bijgeleverd + wordt in het basissysteem van &os; en andere systemen + die PF meeleveren. + + Het FTP protocol accepterende + voor wat het is, moet de proxy in staat zijn om dynamisch + regels toe te voegen aan de ruleset. &man.ftp-proxy.8; + communiceert met de configuratie via een set van + anchors, waar de proxy regels kan toevoegen + en verwijderen die nodig zijn om FTP te + kunnen gebruiken. + + Om &man.ftp-proxy.8; te kunnen gebruiken moet de + volgende regel worden toegevoegd aan + /etc/rc.conf: + + ftpproxy_enable="YES" + + Door de proxy handmatig te starten door + /usr/sbin/ftp-proxy uit te voeren + kan de PF configuratie wijzigingen + die gemaakt gaan worden, worden getest. + + Voor een basis configuratie hoeven er maar drie + elementen te worden toegevoegd aan de ruleset. Als eerste + de anchors: + + nat-anchor "ftp-proxy/*" +rdr-anchor "ftp-proxy/*" + + De proxy zal de regels welke gegenereerd worden voor + FTP hier toevoegen. Een passeer regel + is nodig om het FTP verkeer naar de + proxy toe te staan. + + Nu de daadwerkelijke omleiding. Omleidingsregels en + NAT regels vallen beiden in dezelfde + regel klasse. Er mag direct naar deze regels worden + verwezen, en filter regels mogen afhankelijk zijn van + deze regels. Logisch gezien moeten rdr + en nat regels gedefinieerd worden voor + de filter regels. + + De rdr wordt direct toegevoegd na + de nat regel in + /etc/pf.conf. + + rdr pass on $int_if proto tcp from any to any port ftp -> 127.0.0.1 port 8021 + + Daarnaast moet het omgeleide verkeer worden toegestaan. + Dit kan met + + pass out proto tcp from $proxy to any port ftp + + Waar $proxy vertaald wordt naar het + adres waar de proxy aangekoppeld is. + + Bewaar pf.conf en herlaad de + nieuwe ruleset met: + + &prompt.root; pfctl -f /etc/pf.conf + + Op dit moment zullen gebruikers al meteen merken dat + FTP werkt nog voordat dit ze verteld + is. + + Dit voorbeeld behandelt een basis opstelling waarbij de + gebruikers in het lokale netwerk contact moeten zoeken + met een FTP server ergens anders. Deze + basis configuratie werkt goed met de meeste combinaties + van FTP clients en servers. Zoals te + zien is in de handleiding, kan het gedrag van de proxy + beinvloed worden op verschillende manieren door het + toevoegen van opties aan de + ftpproxy_flags= regel. Sommige clients + of servers hebben specifieke oplossingen nodig welke + opgelost moeten worden in de configuratie, of het kan + benodigd zijn dat de proxy op een speciale manier moet + worden geintegreerd zoals het toewijzen van + FTP verkeer aan een specifieke queue. + Voor deze en andere diepere punten van de &man.ftp-proxy.8; + configuratie wordt verwezen naar de handleiding. + + Voor oplossingen om een eigen FTP + server te draaien welke beveiligd wordt door + PF en &man.ftp-proxy.8; kan gekeken + worden naar het draaien van een aparte + ftp-proxy in omgekeerde modus (door + gebruik te maken van de optie), op een + eigen poort met zijn eigen omleidingsregel. + + + + + Troubleshooting makkelijker maken + + Het makkelijker en vriendelijker maken van netwerk + troubleshooting is een potentieel groot onderwerp. In + de meeste gevallen valt of staat de vriendelijkheid van + het troubleshoot van TCP/IP met hoe + het protocol dat specifiek voor probleemoplossing is + gemaakt wordt behandelt, het + Internet Control Message Protocol of + ICMP kort gezegd. + + ICMP is het protocol voor het + versturen en ontvangen van controle + berichten tussen machines en gateways, + veelal om terugkoppeling te geven naar de verzender + over ongebruikelijke of lastige condities om de doel + machine te bereiken. + + Er is veel ICMP verkeer wat vaak in + de achtergrond actief is waarbij de gebruikers bijvoorbeeld + aan het surfen zijn, een email bericht lezen of bestanden + versturen. Routers maken gebruik van ICMP + om pakket groottes af te stemmen en andere transmissie + parameters in een proces wat vaak path + MTU discovery wordt + genoemd. + + Sommige beheerders noemen ICMP een + puur kwaad, of als het begrip groter is een + noodzakelijk kwaad. De reden voor deze + houding is puur historisch. De reden ertoe kan een aantal + jaar geleden worden teruggevonden toen ontdekt werd dat + verschillende besturingssystemen code in de netwerk stack + hadden zitten welke een machine die een geraakt systeem + gebruikte kon doen crashen of rare dingen laten gebeuren + als er maar een groot genoeg ICMP verzoek + gestuurd werd. + + EEn van de bedrijven die hier hard door getroffen werd + was Microsoft en hiermee is een grote hoeveelheid materiaal + over de ping of death terug te vinden door + gebruik te maken van de favoriete zoekmachine. Dit alles + gebeurde in de tweede helft van de jaren 90, en alle moderne + besturingssystemen hebben sindsdien de netwerk code drastisch + verbeterd. Althans dat is wat men ons doet geloven. + + EEn van de eerste workarounds was het blokkeren van alle + ICMP verkeer, of in ieder geval + ICMP ECHO welke gebrukt wordt door ping. + Deze rulesets zijn inmiddels een kleine 15 jaar in gebruik + en de mensen die die hebben geplaatst, zijn hier nog steeds + bang voor. + + + Moet alles maar worden doorgelaten dan? + + De logische vervolg vraag wordt dan als + ICMP zo goed en bruikbaar is hierin, + moeten we het dan niet altijd toestaan? Het antwoord + daarop is dat hangt er vanaf. + + Het doorlaten van diagnostisch verkeer maakt het + probleemoplossen makkelijker, maar maakt het voor anderen + ook relatief eenvoudig om informatie over het netwerk + te verkrijgen. Dat betekent dat een regel als + + pass inet proto icmp from any to any + + misschien niet optimaal is als het interne netwerk + met een deken van mysterie omvat moet worden. In alle + eerlijkheid moet wel gezegd worden dat sommige + ICMP verkeer redelijk veilig kan zijn + als deze meelift op keep state + regels. + + + + De makkelijke uitweg: alles stopt hier + + De makkelijkste oplossing is om alle + ICMP verkeer vanaf het lokale netwerk + toe te staan en alle andere netwerken te blokkeren op de + gateway: + + pass inet proto icmp from $localnet to any keep state +pass inet proto icmp from any to $ext_if keep state + + Het stoppen van verkeer op de gateway kan sowieso een + interessante optie zijn, maar er wordt ook gekeken naar + een aantal andere opties die de flexibiliteit van + PF laten zien. + + + + Het doorlaten van <command>ping</command> + + De ruleset die tot heden ontwikkeld is, heeft EEn + duidelijk nadeel, veel voorkomende troubleshooting tools + zoals &man.ping.8; en &man.traceroute.8; werken niet. + Dat maakt wellicht niet veel uit voor eind gebruikers + en omdat het ping was die veel mensen + ertoe heeft aangezet om ICMP te + filteren of te blokkeren, zijn er ongetwijfeld mensen + die denken beter af te zijn zonder. Als u echter behoort + aan de doelgroep dan zult u er blij mee zijn dat deze + tools wel beschikbaar zijn. Met een aantal kleine + aanpassingen in de ruleset kan dat ook. &man.ping.8; + maakt gebruik van ICMP en om de + regels netjes te houden, wordt er een nieuwe makro + gedefinieerd: + + icmp_types = "echoreq" + + en een regel welke deze definitie gebruikt + + pass inet proto icmp all icmp-type $icmp_types keep state + + Meer of andere type ICMP pakketjes + kunnen wellicht gewenst zijn, dus + icmp_types kan worden uitgebreid met de + pakket type's die toegestaan zijn. + + + + &man.traceroute.8; helpen + + &man.traceroute.8; is een ander nuttig hulpmiddel + wanneer er gebruikers zijn die claimen dat het Internet + niet werkt. Standaard gebruikt Unix + traceroute UDP verbindingen gebaseerd + op een vastgestelde formule naar de doelmachine. De regel + hieronder werkt met traceroute op alle + Unix'en waaronder GNU/Linux: + + # allow out the default range for traceroute(8): +# "base+nhops*nqueries-1" (33434+64*3-1) +pass out on $ext_if inet proto udp from any to any port 33433 >< 33626 keep state + + De ervaring tot heden leert dat + traceroute implementaties op andere + besturingssystemen grofweg hetzelfde werkt. Met als + uitzondering natuurlijk Microsoft Windows. Op dat + platform maakt TRACERT.EXE gebruik van + ICMP ECHO. Dus om Windows traceroute door te laten is + alleen de eerste regel nodig. Unix + traceroute kan verteld worden dat er + andere protocollen gebruikt moeten worden en het gedrag + van Microsoft wordt wonderbaarlijk nagebootst door de + te gebruiken. Bekijk de + &man.traceroute.8; handleiding (of broncode) voor alle + details. + + Deze oplossing is opgemerkt op de openbsd-misc lijst. + Deze lijst en zijn doorzoekbare archieven (zoals onder + andere beschikbaar op< http://marc.theaimsgroup.com/), + zijn een enorm waardevolle bron als er OpenBSD of + PF informatie gezocht wordt. + + + + Path <acronym>MTU</acronym> Discovey + + Internet protocollen zijn ontwikkeld om apparaat + onafhankelijk te zijn, EEn consequentie daarvan is dat de + optimale pakket grootte voor een gegeven verbinding niet + altijd goed voorspelt kan worden. De belangrijkste + limitatie voor de grootte van een pakket heet + Maximum Transmission Unit, ofwel + MTU, welke de maximale limiet bepaalt + voor de grootte van een pakket op een interface. + &man.ifconfig.8; toont de MTU voor de + netwerk interfaces. + + Moderne TCP/IP implementaties verwachten dat ze in + staat zijn om de juiste pakket grootte te bepalen door + een proces, welke simpelgezegd behelst het versturen van + pakketjes van verschillende groottes met de + Do Not Fragment vlag ingesteld, waarbij een + ICMP pakket wordt teruggestuurd met + type 3, code 4 als de maximale waarde bereikt + is. Niet meteen in de RFCs duiken. Type 3 betekent + destination unreachable, en code 4 staat + voor fragmentation needed, maar de do-not-fragment + vlag is ingesteld. Dus als er verbindingen zijn + naar andere netwerken met een andere MTU + waarde, en er is geen reden om zo specifiek te zijn, kan + de lijst met ICMP types een klein + beetje worden aangepast om de destination + unreachable pakketjes ook door te laten: + + icmp_types = "{ echoreq, unreach }" + + Zoals te zien is, hoeft de passeer regel niet te worden + aangepast hiermee: + + pass inet proto icmp all icmp-type $icmp_types keep state + + PF is in staat om op alle varianten + van ICMP type's en codes te filteren. + Voor degenen die willen onderzoeken wat ze wel en wat niet + willen accepteren met betrekking tot ICMP + verkeer, is de lijst van mogelijke type's en codes + gedocumenteerd in de &man.icmp.4; en &man.icmp6.4; + handleidingen. De achtergrond informatie is beschikbaar + in de RFCs + De belangrijkste Internet + RFCs die ICMP + en gerelateerde technieken beschrijven zijn + RFC792, RFC950, RFC1191, RFC1256, RFC2521, RFC2765 + en belangrijke updates voor ICMP voor IPv6 kunnen + worden gevonden in RFC1885, RFC2463 en RFC2466. + De documenten zijn op diverse plekken beschikbaar + zoals via de + ietf.org + en + faqs.org + websites.. + + + + + Tabellen maken het leven makkelijker + + Op dit moment kan het erop gaan lijken dat dit allemaal + enorm statich en rigide is. Er zal natuurlijk verkeer zijn + dat gefilterd moet worden en omgeleid op een bepaald moment + maar welke niet thuishoort in de configuratie. + PF heeft een mechanisme om deze situaties + te kunnen behandelen. Tabellen zijn zo'n mechanisme, met + name handig om te gebruiken als lijsten welke bewerkt kunnen + worden zonder dat de hele ruleset opnieuw geladen hoef te + worden, en waar snel opzoeken gewenst is. Tabelnamen worden + altijd omringd door < > + zoals: + + table <clients> { 192.168.2.0/24, !192.168.2.5 } + + Hier is het netwerk 192.168.2.0/24 + onderdeel van de tabel, met uitzondering het adres + 192.168.2.5. Deze wordt uitgezonderd + door het ! teken (logische NIET). Het + is ook mogelijk om tabellen uit bestanden te laden waarbij + elk onderdeel op een eigen regel staat, zoals het bestand + /etc/clients. + + 192.168.2.0/24 +!192.168.2.5 + + welke op zijn beurt wordt gebruikt om de tabel te + initialiseren in /etc/pf.conf: + + table <clients> persist file "/etc/clients" + + Hierna kan bijvoorbeeld EEn van de eerdere regels worden + aangepast naar + + pass inet proto tcp from <clients> to any port $client_out flags S/SA keep state + + om uitgaand verkeer van de gebruikers te beheren. Met + deze optie in handen, kan de inhoud van de tabel live worden + aangepast, zoals + + &prompt.root; pfctl -t clients -T add 192.168.1/16 + + Let op, dit verandert enkel de kopie van de tabel in het + geheugen, wat zoveel betekent als dat de wijziging niet + bewaard blijft bij stroomuitval of een herstart tenzij de + wijziging bewaard wordt. + + EEn optie om de disk kopie van te tabel te bewaren is + door gebruik te maken van &man.cron.8; om de inhoud van de + tabel periodiek te dumpen naar de schijf door gebruik te + maken van een commando ala pfctl -t clients -T show + >/etc/clients. Maar ook het bestand + /etc/clients kan bewerkt worden waarna + de kopie in het geheugen wordt vervangen door de inhoud van + het bestand door middel van: + + &prompt.root; pfctl -t clients -T replace -f /etc/clients + + Voor handelingen die frequent worden uitgevoerd zullen + beheerders vroeg of laat shell scripts gaan schrijven voor + taken zoals het toevoegen of verwijderen van items, of het + vervangen van de inhoud van de tabellen. De enige beperking + is de individuele benodigdheden en creativiteit. + + + + Overloop tabellen + + Degenen een Secure Shell login dienst draaien + welke bereikbaar is vanaf het Internet hebben ongetwijfeld + wel iets als volgt in de authenticatie logs gezien: + + Sep 26 03:12:34 skapet sshd[25771]: Failed password for root from 200.72.41.31 port 40992 ssh2 +Sep 26 03:12:34 skapet sshd[5279]: Failed password for root from 200.72.41.31 port 40992 ssh2 +Sep 26 03:12:35 skapet sshd[5279]: Received disconnect from 200.72.41.31: 11: Bye Bye +Sep 26 03:12:44 skapet sshd[29635]: Invalid user admin from 200.72.41.31 +Sep 26 03:12:44 skapet sshd[24703]: input_userauth_request: invalid user admin +Sep 26 03:12:44 skapet sshd[24703]: Failed password for invalid user admin from 200.72.41.31 port 41484 ssh2 + + Etc. Dit is hoe een brute force aanval eruit ziet. In + essentie is dit iemand, of waarschijnlijker een gekraakte + computer, welke door middel van brute force probeert een + juiste combinatie van gebruikersnaam en wachtwoord te + achterhalen om daarmee op het systeem te kunnen + aanloggen. + + De simpelste reactie zou zijn om een regel in + pf.conf te zetten die alle toegang + blokkeert. Dit leidt echter tot een andere klasse problemen + zoals wat te doen met mensen die legitiem toegang nodig + hebben tot het systeem. Een aantal zullen overwegen om de + dienst naar een andere poort te verhuizen, maar dan zullen + ook de mensen die poort 22 scannen in staat zijn om ook + poort 2222 te scannen om het trucje te herhalen. + + Sinds OpenBSD 3.7 en vlak erna in &os versie 6.0 + heeft PF een elegantere oplossing. + Passeer regels kunnen geschreven worden met daarbij + het bijhouden van bepaalde limieten met wat bepaalde + hosten kunnen doen. Voor de goede orde kunnen overtreders + aan een tabel waarmee wordt bepaalt of ze daarmee + beperkte toegang krijgen of geheel geen toegang meer. + Indien gewenst is het ook mogelijk om alle bestaande + verbindingen te verwijderen van het systeem wanneer + de voorgeschreven limieten overtreden worden. Op de + volgende manier wordt dat gedaan: + + Als eerste wordt de tabel opgezet. In de tabel + sectie moet worden toegevoegd: + + table <bruteforce> persist + + En daarna vroeg in de ruleset een regel om de + bruteforcers te blokkeren: + + block quick from <bruteforce> + + Als laatste volgt de passeer regel: + + pass inet proto tcp from any to $localnet port $tcp_services \ +flags S/SA keep state \ +(max-src-conn 100, max-src-conn-rate 15/5, \ +overload <bruteforce> flush global) + + Het eerste gedeelte is gelijk aan de regel die al eerder + gemaakt is. Het deel tussen de ronde haken is nieuw, welke + de belasting op het netwerk alleen maar verbetert. + + max-src-conn is de waarde met hoeveel + simultane verbindingen er mogen zijn vanaf EEn machine. In + dit voorbeeld is de waarde 100. Andere opstellingen kunnen + een hogere of lagere waarde vereisen. + + max-src-conn-rate is de hoeveelheid + nieuwe verbindingen die EEn machine kan opzetten, hier + ingesteld op 15 verbindingen per 5 seconden. Ook hier geldt + dat de beheerder die kan bepalen wat geschikt is voor de + specifieke opstelling. + + overload <bruteforce> betekent + dat elke host die de waarden overschrijd, zijn of haar + adres toegevoegd zal zien worden aan de tabel + bruteforce. De genoemde regel blokkeert + alle verkeer vanaf adressen in de bruteforce tabel. + + Als laatste de flush global optie, + deze geeft aan dat wanneer een machine de maximale waarde + bereikt, alle verbindingen vanaf die machine worden + getermineerd(flushed). Het globale gedeelte geeft aan dat + dit voor de goede orde ook geldt voor verbindingen die + andere regels matchen. + + Het effect is dramatisch. Vanaf nu zullen bruteforcers + vaker wel dan niet uit zullen komen op + "Fatal: timeout before + authentication" meldingen, welke + nergens toe leiden. + + + Deze regels houden langzame bruteforcers + niet tegen, beter bekend als + de Hail + Mary Cloud. + + + Nogmaals, denk erom dat de voorbeeld regel puur bedoeld + is ter illustratie. Het is niet ondenkbaar dat de specifieke + behoeften voor een specifiek netwerk beter bediend worden door + andere regels of een combinatie van regels. + + Als, bijvoorbeeld, een grote hoeveelheid verbindingen + gewenst is maar de wens er is om wat stricter te zijn wanneer + het ssh betreft, moet bovenstaande + regel aangevuld worden met iets als onderstaande zo dicht als + mogelijk bij het begin van de ruleset: + + pass quick proto { tcp, udp } from any to any port ssh \ +flags S/SA keep state \ +(max-src-conn 15, max-src-conn-rate 5/3, \ +overload <bruteforce> flush global) + + Het zou mogelijk moeten zijn om juiste parameters voor + de eigen situatie te vinden door het lezen van de relevante + handleidingen en de + PF User + Guide, en wellicht een klein beetje + experimenteren. + + + Het is wellicht niet nodig om alle overtreders te + blokkeren + + Het is waarschijnlijk nuttig om te vermelden dat het + overload mechanisme een generieke + techniek is welke niet specifiek alleen voor de + ssh dienst geldt, en het is niet + altijd gewenst om alle verkeer van overtreders meteen + te blokkeren. + + Bijvoorbeeld, een overload regel kan gebruikt worden + om een mailserver of een webserver te beschermen, en de + overload tabel kan dan gebruikt worden om de overtreders + in queue te plaatsen met minimale bandbreedte toegewezen, + of in het geval van een webpagina om deze naar een + specifieke webpagina te verwijzen. + + + + Het opruimen van tabel regels met behulp van + <application>pfctl</application> + + Op dit moment is er een tabel welke gevuld wordt door + de overload regels, en omdat een gateway gemiddeld maanden + achtereen beschikbaar is, zal de tabel blijven groeien en + en daardoor ook steeds meer geheugen bezet houden. + + Het kan voorkomen dat een IP adres welke geblokkeerd is + afgelopen week in verband met een brute force aanval + eigenlijk een dynamisch uitgegeven adres is, welke nu + uitgegeven is aan een andere klant van de ISP, die wel + legitieme redenen heeft om te communiceren met machines op + het lokale netwerk. + + Situaties als deze hebben ervoor gezorgd dat Henning + Brauer de mogelijkheid aan pfctl + heeft toegevoegd om regels in tabellen op te ruimen na een + ingestelde hoeveelheid seconden (in OpenBSD 4.1). + Bijvoorbeeld het commando: + + &prompt.root; pfctl -t bruteforce -T expire 86400 + + zal <bruteforce> tabel regels + opruimen die al meer dan 86400 seconden niet gebruikt + zijn. + + + + Het <application>expiretable</application> hulp + programma + + Voordat pfctl de + mogelijkheid kreeg om tabel regels op te schonen had + Henrik Gustafsson een programma geschreven + expiretable, welke regels + opruimde welke een gespecificeerde hoeveelheid tijd niet + gebruikt waren. + + EEn nuttig voorbeeld van het gebruik van het + expiretable programma is een + manier om oude niet meer gebruikte regels in + <bruteforce> te + verwijderen. + + Bijvoorbeeld om expiretable + <bruteforce> tabel regels te laten + verwijderen, welke ouder zijn dan 24 uur, moet er een regel + worden toegevoegd aan /etc/rc.local: + + /usr/local/sbin/expiretable -v -d -t 24h bruteforce + + expiretable is beschikbaar + in de Ports Collectie van &os; als + security/expiretable. + + + + + Andere <acronym>PF</acronym> tools + + Na verloop van tijd zijn er een aantal programma's + ontwikkeld die op diverse manieren met + PF communiceren. + + + Het huidige verkeer tonen met + <application>pftop</application> + + Can Erkin Acar's pftop maakt + het mogelijk om te zien wat er het netwerk in en uitgaat. + pftop is beschikbaar via het + ports systeem als sysutils/pftop. De + naam is een sterke hint over wat het programma doet. + pftop toont een snapshot van + het verkeer in een formaat dat geinspireerd is door + &man.top.1;. + + + + De <application>spamd</application> Spam afweer + daemon + + Deze applicatie moet niet verward worden met de + spamd daemon welke wordt + meegeleverd als onderdeel van + spamassassin. De + PF applicatie + spamd werd ontwikkeld om te + draaien op een PF gateway als onderdeel + om te beschermen tegen spam. + spamd koppelt aan de + PF configuratie door een set + omleidingen. + + Het belangrijkste punt van het ontwerp van + spamd is het feit dat spammers + een grote hoeveelheid berichten versturen waarbij de kans + u de eerste bent die een bepaald bericht ontvang is + bijzonder klein. Daarnaast wordt spam meestal verstuurd + via spam vriendelijke netwerken en een grote hoeveelheid + gekaapte machines. Zowel de individuele berichten als de + machines worden vaak snel gerapporteerd aan blacklists en + dit is precies de informatie die + spamd in ons voordeel kan + gebruiken met blacklists. + + Wat spamd doet met + SMTP verbindingen vanaf adressen die in een blacklist + voorkomen is om de banner te laten zien en meteen daarna + om te schakelen naar een mode waar het SMTP verkeer nog + maar met EEn byte per keer wordt beantwoord. Deze techniek + welke bedoeld is om zoveel mogelijk tijd te verkwanselen + aan de versturende kant terwijl het de ontvanger feitelijk + niets kost wordt tarpitting + genoemd. De specifieke implementatie met EEn byte + antwoorden wordt ook wel stuttering + genoemd. + + + Een standaard blacklistende + <application>spamd</application> + + Hier volgt de basis procedure voor het opzetten van + spamd met automatisch + bijgewerkte blacklists: + + + + Installeer de mail/spamd Port. + Lees in het bijzonder het package berichten doe wat + er wordt gezegd. Specifiek om + spamd's greylisting optie + te gebruiken moet er een bestands descriptor + bestandssysteem gekoppeld worden op + /dev/fd/ (zie &man.fdescfs.5;). + Hiervoor moet de volgende regel worden toegevoegd aan + /etc/fstab: + + fdescfs /dev/fd fdescfs rw 0 0 + + Zorg ervoor dat de fdescfs + code zich in de kernel bevind, ofwel door het + incompileren ervan of door het laden van de module + door middel van &man.kldload.8;. + + + + Hierna moet de ruleset bewerkt worden waarna het + volgende bijgevoegd moet worden: + + table <spamd> persist +table <spamd-white> persist +rdr pass on $ext_if inet proto tcp from <spamd> to \ + { $ext_if, $localnet } port smtp -> 127.0.0.1 port 8025 +rdr pass on $ext_if inet proto tcp from !<spamd-white> to \ + { $ext_if, $localnet } port smtp -> 127.0.0.1 port 8025 + + De twee tabellen <spamd> en + <spamd-white> zijn essentieel. SMTP verkeer + vanaf adressen in de eerste tabel, plus degenen + die niet in de andere tabel staan worden omgeleid + naar een daemon welke luistert op poort 8025. + + + + De volgende stap is het opzetten van + spamd's eigen + configuratie in + /usr/local/etc/spamd.conf + aangevuld met parameters in + /etc/rc.conf. + + Het bijgeleverde voorbeeld bestand levert veel + uitleg aan, en de handleiding biedt nog meer extra + informatie aan. De belangrijkste onderdelen worden + hieronder besproken. + + EEn van de eerste regels zonder een # commentaar + teken aan het begin van de regel bevat het blok + welke de all lijst definieert, + deze specificeert welke lijsten er daadwerkelijk + gebruikt worden: + + all:\ +:traplist:whitelist: + + Hier worden alle gewenste backlists opgevoerd, + gescheiden door dubbele punten + (:). Om whitelists te gebruiken + welke niet gebruikt kunnen worden in de blacklists + moet de naam worden toegevoegd direct na de naam + van de blacklist, zoals + :blacklist:whitelist:. + + Nu volgt de specificatie van de blacklist: + + traplist:\ +:black:\ +:msg="SPAM. Your address %A has sent spam within the last 24 hours":\ +:method=http:\ +:file=www.openbsd.org/spamd/traplist.gz + + Door de naam te volgen zien we dat het eerste + data veld het lijsttype specificeert, in dit geval + black. Het + msg veld bevat het bericht welke + wordt getoond aan verzenders op de zwarte lijst + tijdens de SMTP communicatie. Het + method veld specificeert hoe + spamd-setup de lijst data ophaalt, in dit geval + via http. De andere opties zijn + het ophalen via ftp, via een + file op een gekoppeld + bestandssysteem of via exec een + extern programma. Als laatste specificeert het + file veld de naam van het + bestand welke spamd verwacht te ontvangen. + + De definitie van een whitelist volgt hetzelfde + patroon: + + whitelist:\ +:white:\ +:method=file:\ +:file=/var/mail/whitelist.txt + + maar heeft geen msg + parameter, omdat deze niet nodig is. + + + Kies de bronnen zorgvuldig + + Door alle zwarte lijsten uit het voorbeeld + te gebruiken worden grote delen van het Internet + op de zwarte lijst gezet waaronder enkele + Aziatische landen. Beheerders moeten het bestand + bewerken om een optimale configuratie te kunnen + krijgen. De beheerder is de meester die de keuze + maakt welke data bronnen er gekozen worden en + gebruik maken van andere lijsten dan in het + voorbeeld is mogelijk. + + + Zet de regels voor spamd en alle opstart + parameters die benodigd zijn in + /etc/rc.conf, + bijvoorbeeld: + + spamd_flags="-v" # for normal use: "" and see spamd-setup(8) + + Wanneer men klaar is met het bewerken van + de opstelling, herlaad de ruleset, start + spamd met de gewenste + opties door gebruik te maken van het + /usr/local/etc/rc.d/obspamd + script, en eindig de configuratie door gebruik te + maken van spamd-setup. Als + laatste moet er een &man.cron.8; job gemaakt + worden, welke spamd-setup + aanroept om de tabellen op redelijke intervallen + bij te werken. + + + + Op een typische gateway voor een mailserver zullen + er machines vast komen te zitten binnen een aantal + seconden tot enkele minuten. + + + + Het toevoegen van greylisting aan de + <application>spamd</application> opstelling + + spamd ondersteund ook + het gebruik van greylisting + welke werkt door het weigeren van berichten van + onbekende machines met behulp van + 45n codes en het doorlaten + van machines die het nogmaals proberen binnen redelijke + tijd. Verkeer van goed gedragende machines, dat wil + zeggen versturende machines die ingesteld zijn volgens + de limieten gespecificeerd in de relevante + RFCs + De relevante RFCs zijn met name RFC1123 + en RFC2821. worden + doorgelaten. + + De techniek greylisting werd in 2003 gepresenteerd + in een paper door Evan Harris + De originele paper van Harris en een + aantal andere nuttige artikelen en bronnen kunnen + worden gevonden op de greylisting.org + website., en een aantal + implementaties volgden in de maanden erna. OpenBSD's + spamd verkreeg de + mogelijkheid tot greylisten in OpenBSD 3.5, welke + uitgebracht werd in 2004. + + Het meest verbazingwekkende aan greylisting, naast + de simpelheid ervan, is dat het nog steeds werkt. + Spammers en schrijvers van malware zijn heel traag + geweest om zich hierop aan te passen. + + De basis procedure om greylisting toe te voegen + aan de opstelling volgt hieronder. + + + + Mits nog niet gedaan moet ervoor gezorgd + worden dat het File Descriptor bestandssysteem + (&man.fdescfs.5;) gekoppeld is aan + /dev/fd. Dit kan door + middel van het toevoegen van de volgende regel + aan /etc/fstab: + + fdescfs /dev/fd fdescfs rw 0 0 + + en zorg ervoor dat de &man.fdescfs.5; code zich + ofwel in de kernel bevind of ingeladen is door een + module met &man.kldload.8;. + + + + Om spamd in + greylisting modus te draaien moet + /etc/rc.conf iets worden + aangepast door het volgende toe te voegen + + spamd_grey="YES" # use spamd greylisting if YES + + Verschillende greylisting parameters kunnen + worden aangepast met spamd's + commando regel parameters en bijbehorende + /etc/rc.conf instellingen. + Controleer de spamd + handleiding om te zien wat welke parameter + betekend. + + + + Om de greylisting opstelling compleet te maken + moet spamd herstart *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***