|
Internet Firewall FAQ in Dutch
Firewall FAQ in Nederlands Deel 1
De Firewalls van Internet: Vaak Gestelde Vragen Paul D. Robertson paul@compuwar.net Matte Curtin cmcurtin@interhack.net Marcus J. Ranum mjr@ranum.com (vertaald door William Sun sun@thegild.com ) Datum: 2004/07/26 15:34:42 Revisie: 10.4 Dit document beschikbaar in Postscriptumand PDF. Inhoud 1 Administrativia 1.1 Over FAQ 1.2 Voor wie wordt FAQ geschreven? 1.3 Alvorens Post Te verzenden 1.4 Waar kan ik de Huidige Versie van FAQ vinden? 1.5 Waar kan ik niet Engelse Versies van FAQ vinden? 1.6 Medewerkers 1.7 Auteursrecht en Gebruik 2 Achtergrond en van de Firewall Grondbeginselen 2.1 Wat is een netwerkfirewall? 2.2 Waarom zou ik een firewall willen? 2.3 Wat kan een firewall tegen beschermen? 2.4 Wat niet kan een firewall tegen beschermen? 2.5 Wat over virussen en andere malware? 2.6 Zal IPSEC firewalls verouderd maken? 2.7 Wat zijn goede bronnen van af:drukken informatie over firewalls? 2.8 Waar kan ik meer informatie over firewalls op Internet krijgen? 3 De Kwesties van het ontwerp en van de Implementatie 3.1 Wat zijn enkele basisontwerpbesluiten in een firewall? 3.2 Wat zijn de basistypes van firewalls? 3.3 Wat zijn volmachtsservers en hoe werken zij? 3.4 Wat zijn sommige goedkope hulpmiddelen van het pakketonderzoek? 3.5 Wat zijn sommige redelijke het filtreren regels voor het op pit-gebaseerd pakketscherm? 3.6 Wat zijn sommige redelijke het filtreren regels voor een Cisco? 3.7 Wat zijn de kritieke middelen in een firewall? 3.8 Wat is een DMZ, en waarom ik wil één? 3.9 Hoe ik de veiligheid en scalability van mijn DMZ zou kunnen verhogen? 3.10 Wat is één enkel punt ` van mislukking ', en hoe vermijd ik hebbend? 3.11 Hoe kan ik het elk van slecht materiaal blokkeren? 3.12 Hoe kan ik Web beperken toegang zodat kunnen de gebruikers niet niet verwante plaatsen om te werken bekijken? 4 Diverse Aanvallen 4.1 Wat is bron geleid verkeer en waarom is het een bedreiging? 4.2 Wat zijn ICMP opnieuw richten en opnieuw richten bommen? 4.3 Wat over ontkenning van de dienst? 4.4 Wat zijn sommige gemeenschappelijke aanvallen, en hoe kan ik mijn systeem tegen hen beschermen? 5 Hoe ik... 5.1 Wil ik werkelijk toestaan alles die mijn gebruikers om vragen? 5.2 Hoe maak ik Web/het werk van HTTP door mijn firewall? 5.3 Hoe maak ik SSL het werk door de firewall? 5.4 Hoe maak ik DNS het werk met een firewall? 5.5 Hoe maak ik het werk van FTP door mijn firewall? 5.6 Hoe maak ik het werk van Telnet door mijn firewall? 5.7 Hoe maak ik Vinger en whois door mijn firewall werken? 5.8 Hoe maak ik gopher, Archie, en werken andere diensten door mijn firewall? 5.9 Wat zijn de kwesties over X11 door een firewall? 5.10 Hoe maak ik RealAudio door mijn firewall werken? 5.11 Hoe maak ik mijn Webserver als voorkant voor een dienst doen gegevensbestand dat op mijn privé netwerk leeft? 5.12 Maar mijn gegevensbestand heeft een geïntegreerde Webserver, en ik wil dat gebruiken. Kan ik niet een gat in de firewall en de tunnel die haven enkel porren? 5.13 Hoe maak ik tot IP Multicast Werk met Mijn Firewall? 6 Havens TCP en UDP 6.1 Wat is een haven? 6.2 Hoe weet ik welke toepassing gebruikt welke haven? 6.3 Wat zijn het LUISTEREN havens? 6.4 Hoe bepaal ik welke dienst de haven voor is? 6.5 Welke havens zijn veilig om door een firewall over te gaan? 6.6 Het gedrag van FTP 6.7 Welke software gebruikt welke wijze van FTP? 6.8 Probeert mijn firewall buiten te verbinden? 6.9 De anatomie van een aansluting van TCP A. Sommige Commerciële Producten en Verkopers B. Verklarende woordenlijst van firewall-Verwante Termijnen Bibliografie 1 Administrativia 1.1 Over FAQ Deze inzameling van Frequenty stelde Vragen (FAQs) en de antwoorden is gecompileerd over een periode van jaren, ziend welke vragenmensen over firewalls in dergelijke forums zoals Usenet, adressenlijsten, en Websites vragen. Als u een vraag hebt, hier kijkend om te zien of het alvorens uw vraag te posten is goede vorm wordt beantwoord. Verzend uw vragen over firewalls niet naar de handhavers FAQ. De handhavers stemmen in met input en commentaren op de inhoud van dit FAQ. De commentaren met betrekking tot FAQ zouden aan firewall-faq@interhack.net moeten worden gericht. Alvorens u ons post verzendt, gelieve te zijn zeker om secties 1.2 te zien en 1.3 om dit ervoor te zorgen zijn het juiste document voor u om te lezen. 1.2 Voor wie wordt FAQ geschreven? De firewalls zijn ver van de dagen gekomen toen dit FAQ begon. Zij zijn van het zijn hoogst aangepaste systemen gegaan die door hun implementors aan heersende stromingsgoederen worden beheerd. De firewalls zijn niet meer alleen in de handen van zij die ontwerpen en veiligheidssystemen uitvoeren; zelfs thuis hebben de veiligheid-bewuste eindgebruikers hen. Wij schreven dit FAQ voor computersystemenontwikkelaars en beheerders. Wij hebben vrij inclusief geprobeerd te zijn, makend ruimte voor de nieuwkomers, maar wij veronderstellen nog wat fundamentele technische achtergrond. Als u vindt dat u dit document niet begrijpt, maar denk dat u meer over firewalls moet kennen, zou het goed kunnen zijn dat u eigenlijk meer achtergrond in computervoorzien van een netwerk eerste moet krijgen. Wij verstrekken verwijzingen die ons hebben geholpen; misschien zullen zij u ook helpen. Wij concentreren ons overwegend op "netwerk" firewalls, maar `` de gastheer '' of ``"personal'' firewalls zal worden gericht waar aangewezen. 1.3 Alvorens Post Te verzenden Merk op dat deze inzameling van vaak-gevraagde vragen een resultaat van het in wisselwerking staan met vele mensen van verschillende achtergronden in een grote verscheidenheid van openbare forums is. Het firewalls -firewall-faqadres is geen helpdesk. Als u probeert om een toepassing te gebruiken die zegt dat het niet wegens een firewall werkt en u denkt dat u uw firewall moet verwijderen, te verzenden gelieve ons geen post vragend hoe. Als u hoe te `` wilt kennen doe uw firewall '' van de hand omdat u één of andere toepassing niet kunt gebruiken, verzendt ons geen post vragend om hulp. Wij kunnen u helpen niet. Werkelijk. Wie kan u helpen? Goede vraag. Dat zal afhangen van wat precies het probleem is, maar is hier verscheidene wijzers. Als geen van deze werken, gelieve ons om meer geen te vragen. Wij weten niet het. De leverancier van de software u gebruikt. De leverancier van het hardware`` toestel '' u gebruikt. De leverancier van de netwerkdienst u gebruikt. Namelijk als u op AOL bent, vraag hen. Als u probeert om iets op een collectief netwerk te gebruiken, bespreking aan uw systeembeheerder. 1.4 Waar kan ik de Huidige Versie van FAQ vinden? FAQ kan op het Web bij worden gevonden http://www.compuwar.net/pubs/fwfaq/. http://www.interhack.net/pubs/fwfaq/. Het wordt ook gepost maandelijks aan comp.security.firewalls, comp.security.unix, comp.security.misc, comp.answers, en news.answers. De geposte versies worden gearchiveerd in alle gebruikelijke plaatsen. Jammer genoeg, de versie die aan Usenet wordt gepost en die van dat versiegebrek de mooie beelden en de nuttige hyperlinks wordt gearchiveerd die in de Webversie worden gevonden. 1.5 Waar kan ik niet Engelse Versies van FAQ vinden? Verscheidene vertalingen zijn beschikbaar. (Als u een vertaling hebt gedaan en het niet hier vermeld is, te schrijven gelieve ons zodat kunnen wij het hoofddocument bijwerken.) Noors Vertaling door Jon Haugsand http://helmersol.nr.no/haandbok/doc/...nnmur-faq.html 1.6 Medewerkers Vele mensen hebben nuttige suggesties en nadenkende commentaar geschreven. Wij zijn dankbaar aan alle medewerkers. We'd houdt van afew door naam te danken: Keinanen ;Vesa, Allen Leibowitz, Brent Chapman, Hoop Brian Boyle, D. Clyde Williamson, Richard Reiner, William Sun, Humberto Ortiz Zuazaga, en Theodore. 1.7 Auteursrecht en Gebruik Auteursrecht ©1995-1996, 1998 Marcus J. Ranum. Auteursrecht ©1998-2002 Matte Curtin. Auteursrecht 2004, Paul D. Robertson. Alle voorgebe*houde rechten. Dit document kan worden gebruikt, worden herdrukt en, worden opnieuw verdeeld zoals deze verklaring inzake auteursrecht en alle toewijzingen intact blijven verstrekt. De vertalingen van de volledige tekst van de originele Engelsen aan andere talen worden ook uitdrukkelijk toegestaan. De vertalers kunnen hun namen aan de sectie van de ``- Medewerkers ' toevoegen. 2 Achtergrond en van de Firewall Grondbeginselen Alvorens een volledige bespreking van firewalls te kunnen begrijpen, is het belangrijk om de basisprincipes te begrijpen die firewalls maken werken. 2.1 Wat is een netwerkfirewall? Een firewall is een systeem of een groep systemen dat een toegangsbeheerbeleid tussen twee of meer netwerken afdwingen. Het daadwerkelijke middel waardoor dit wordt verwezenlijkt verschilt sterk, maar in principe, kan de firewall van als paar mechanismen worden gedacht: die bestaan om verkeer te blokkeren, en andere die bestaat om verkeer toe te laten. Sommige firewalls leggen een grotere nadruk bij het blokkeren van verkeer, terwijl anderen het toelaten van verkeer benadrukken. Waarschijnlijk is het belangrijkste ding over een firewall te erkennen dat het een toegangsbeheerbeleid uitvoert. Als u geen goed idee hebt van welk soort toegang u wilt toestaan of ontkennen, zal een firewall u niet werkelijk helpen. Het is ook belangrijk om te erkennen dat de configuratie van de firewall, omdat het een mechanisme is om beleid af te dwingen, zijn beleid aan alles achter het oplegt. Beheerders die voor firewalls de connectiviteit voor een groot aantal gastheren de beheren hebben daarom een zware verantwoordelijkheid. 2.2 Waarom zou ik een firewall willen? Internet, zoals een andere maatschappij, wordt geteisterd met het soort schokken die van het elektronische tearing equivalent van het schrijven op de muren van andere mensen met weg spraypaint genieten, hun brievenbussen, of enkel zittend in de straat die hun autohoornen blaast. Sommige mensen proberen om het echte werk dat over Internet wordt gedaan te krijgen, en anderen hebben gevoelige of merkgebonden gegevens zij moeten beschermen. Gewoonlijk, het doel van een firewall is de schokken van uw netwerk weg te houden terwijl nog het laten van u uw baan gedaan krijgen. Vele bedrijven en gegevenscentra in traditionele stijl hebben gegevensverwerkingsveiligheidsbeleid en praktijken dat moeten worden gevolgd. In een geval waar het beleid van een bedrijf dicteert hoe de gegevens moeten worden beschermd, is een firewall zeer belangrijk, aangezien het de belichaming van het collectieve beleid is. Vaak, rechtvaardigt het hardste deel van het vasthaken aan Internet, als u een groot bedrijf bent, de uitgave of de inspanning, maar geen overtuigend beheer dat het veilig is dit te doen. Een firewall verstrekt niet alleen echte veiligheid -- het speelt vaak een belangrijke rol als veiligheidsdeken voor beheer. Ten slotte, kan een firewall als uw collectieve `` ambassadeur '' aan Internet dienst doen. Vele bedrijven gebruiken hun firewallsystemen als plaats om openbare informatie over collectieve producten en de diensten, te downloaden dossiers op te slaan, insect-moeilijke situaties, enzovoort. Verscheidene van deze systemen zijn belangrijke delen van de de dienststructuur van Internet (b.v., UUnet.uu.net ,whitehouse.gov ,gatekeeper.dec.com )geworden en goed hun organisatorische sponsors overdacht. Merk op dat terwijl dit historisch waar is, de meeste organisaties nu openbare informatie over een server van het Web plaatsen, die vaak door een firewall wordt beschermd, maar niet normaal over de firewall zelf. 2.3 Wat kan een firewall tegen beschermen? Sommige firewalls laten slechts e-mailverkeer door hen toe, daardoor beschermend het netwerk tegen om het even welke aanvallen buiten aanvallen tegen de e-maildienst. Andere firewalls bieden minder strikte bescherming, en de blokdiensten die gekend om problemen zijn te zijn. Over het algemeen, worden de firewalls gevormd om tegen niet bekrachtigde interactieve logins van `` buiten wereld te beschermen ''. Dit, meer dan om het even wat, hulp verhindert vandalen registreren in machines op uw netwerk. De gedetailleerdere firewalls blokkeren verkeer van de buitenkant aan de binnenkant, maar laten gebruikers op de binnenkant toe om vrij met de buitenkant te communiceren. De firewall kan u tegen om het even welk type van netwerk-gedragen aanval beschermen als u het afsluit. De firewalls zijn ook belangrijk aangezien zij één enkel `` vernauwingspunt '' kunnen verstrekken waar de veiligheid en de controle kunnen worden opgelegd. In tegenstelling tot in een situatie waar een computersysteem door iemand aangevallen wordt dat met een modem inkiest, kan de firewall als efficiënte `` telefoonkraan '' en vindend hulpmiddel dienst doen. De firewalls verstrekken een belangrijke het registreren en controlefunctie; vaak verstrekken zij samenvattingen aan de beheerder over welke soorten en hoeveelheid verkeer door het overging, hoeveel pogingen er in het, enz. te breken waren. Wegens dit, zijn de firewalllogboeken kritisch belangrijke gegevens. Zij kunnen als bewijsmateriaal in een hof van wet in de meeste landen worden gebruikt. U zou de logboeken van de yorufirewall beschermen analyseren en dienovereenkomstig moeten beschermen. Dit is een belangrijk punt: het verstrekken van dit `` vernauwingspunt '' kan het zelfde doel op uw netwerk dienen dat een bewaakte poort voor het fysieke gebouw van uw plaats kan. Dat betekent u om het even wanneer een verandering in streken `` ' hebt of de niveaus van gevoeligheid, een dergelijke controlepost aangewezen is. Een bedrijf heeft slechts een buitenpoort en zelden geen receptionnist of veiligheidspersoneel om kentekens op de manier in te controleren. Als er lagen van veiligheid op uw plaats zijn, is het redelijk om lagen van veiligheid op uw netwerk te verwachten. 2.4 Wat niet kan een firewall tegen beschermen? De firewalls kunnen tegen aanvallen beschermen niet die niet door de firewall gaan. Vele bedrijven die met Internet verbinden zijn zeer betrokken over merkgebonden gegevens die uit het bedrijf door die route lekken. Jammer genoeg voor betroffen die, kunnen een magnetische band, een compact disc, DVD, of USB de flitsaandrijving enkel zoals effectief om gegevens worden gebruikt uit te voeren. Vele organisaties die (op een beheersniveau) van de aanslutingen angst aangejaagd zijn van Internet hebben geen coherent beleid over hoe wijzerplaat-in toegang via modems zou moeten worden beschermd. Het is dwaas om een zes-voet dikke staaldeur te bouwen wanneer u in een houten huis leeft, maar er zijn heel wat organisaties die daar dure firewalls kopen en talrijk veronachtzamen andere achter-deuren in hun netwerk. Voor een firewall om te werken, moet het een deel van een verenigbare algemene organisatorische veiligheidsarchitectuur zijn. Het beleid van de firewall moet realistisch zijn en op het niveau van veiligheid in het volledige netwerk wijzen. Bijvoorbeeld, vergt een plaats met hoogste geheime of geclassificeerde gegevens een firewall helemaal niet: zij zouden niet tot Internet in de eerste plaats moeten vasthaken, of de systemen met de werkelijk geheime gegevens zouden van de rest van het collectieve netwerk moeten worden geïsoleerd. Een ander ding een firewall niet kan werkelijk beschermen u tegen is verraders of idioten binnen uw netwerk. Terwijl een industriële spion informatie door uw firewall zou kunnen uitvoeren, hij enkel waarschijnlijk heeft om het door een een telefoon, machine van de FAX, of een Compact disc uit te voeren. CDs zijn een veel waarschijnlijker middel voor informatie om van uw organisatie te lekken dan een firewall. De firewalls kunnen ook niet u tegen stompzinnigheid beschermen. De gebruikers die gevoelige informatie over de telefoon openbaren zijn goede doelstellingen voor sociale techniek; een aanvaller kan in uw netwerk kunnen breken door uw firewall volledig te mijden, als hij kan vinden een werknemer `` nuttige '' binnen wie kan zijn in het geven van toegang tot een modempool fooled. Alvorens dit te beslissen geen probleem in uw organisatie is, vraag me hoeveel probleem een contractant wordt geregistreerd het worden die in het netwerk heeft of hoeveel moeilijkheid een gebruiker die zijn wachtwoord vergat teruggesteld het krijgen van het heeft. Als de mensen op de helpdesk geloven dat elke vraag intern is, hebt u een probleem dat niet kan worden bevestigd door controles op de firewalls aan te halen. De firewalls kunnen beschermen niet tegen het een tunnel graven over de meeste toepassingsprotocollen aan trojaned of slecht geschreven cliënten. Er zijn geen magische kogels en een firewall is geen verontschuldiging softwarecontroles op interne netwerken niet om uit te voeren of gastheerveiligheid op servers te negeren. Een tunnel gravend dingen `` slechte '' over HTTP, zijn SMTP, en andere protocollen vrij eenvoudig en onbelangrijk aangetoond. De veiligheid is geen brand `` en vergeet ''. Ten slotte, kunnen de firewalls tegen slechte dingen die beschermen niet door hen worden toegestaan. Bijvoorbeeld, gebruiken vele Trojan Paarden het protocol van het Relais van Internet van het Praatje (IRC) om een aanvaller toe te staan om een gecompromitteerde interne gastheer van een openbare server te controleren IRC. Als u om het even welk intern systeem om met om het even welk extern systeem toestaat te verbinden, dan zal uw firewall geen bescherming tegen deze vector van aanval bieden. 2.5 Wat over virussen en andere malware? De firewalls kunnen zeer goed tegen dingen zoals virussen of kwaadwillige software (malware) beschermen niet. Er zijn teveel manieren om binaire dossiers voor overdracht over netwerken te coderen, en teveel verschillende architectuur en virussen proberen om naar hen allen te zoeken. Met andere woorden, kan een firewall veiligheid-bewustzijn namens uw gebruikers vervangen niet. In het algemeen, kan een firewall tegen een gegeven-gedreven aanval beschermen niet -- aanvallen waarin iets wordt gepost of aan een interne gastheer gekopieerd waar het dan wordt uitgevoerd. Deze vorm van aanval is in het verleden tegen diverse versies van sendmail ,ghostscript voorgekomen, scripting de agenten van de postgebruiker zoals Vooruitzichten, en browsers van het Web zoals de Ontdekkingsreiziger van Internet. De organisaties die diep bezorgd over virussen zijn zouden organization-wide viruscontrolemaatregelen moeten ten uitvoer leggen. Eerder dan slechts het uitproberen aan het schermvirussen bij de firewall, zorg ervoor dat elke kwetsbare Desktop de software heeft van het virusaftasten die in werking wordt gesteld wanneer de machine wordt gereboot. Het bedekken van uw netwerk met de software van het virusaftasten zal tegen virussen beschermen die binnen via floppy disks, CDs, modems, en Internet komen. Het proberen zal om virussen bij de firewall te blokkeren slechts tegen virussen van Internet beschermen. Het aftasten van het virus bij de firewall of e-mailgateway zal een groot aantal besmettingen tegenhouden. Niettemin, biedt een stijgend aantal firewallverkopers virus `` aan ontdekkend firewalls ''. Zij zijn waarschijnlijk slechts nuttig voor naïeve gebruikers die uitvoerbare programma's venster-op-Intel en kwaadwillig-macro-geschikt toepassingsdocumenten ruilen. Er zijn vele op firewall-gebaseerde benaderingen voor het behandelen van problemen zoals de worm `` ILOVEYOU '' en de verwante aanvallen, maar dit zijn werkelijk te eenvoudig voorgestelde benaderingen die proberen om de schade van iets te beperken die het nooit zou moeten in de eerste plaats voorgekomen zijn zo stom is. Tel niet op enige bescherming tegen aanvallers met deze eigenschap. (Aangezien `` ILOVEYOU '' rond ging, hebben wij gezien minstens een gelijkaardig half dozijn, met inbegrip van Melissa, Happy99 aanvalt, Rood, en Badtrans. B codeert, die gelukkig door velen werden overgegaan virus-ontdekt firewalls en e-mailgateways.) Een sterke firewall is nooit een substituut voor zinnige software die de aard van wat behandelt het -- onbetrouwbare gegevens van een niet bekrachtigde partij -- erkent en zich geschikt gedraagt. Denk niet dat omdat `` iedereen '' gebruikt dat mailer of omdat de verkoper een gargantuesk multinationaal bedrijf is, u veilig bent. In feite, is het niet waar dat `` iedereen '' om het even welke mailer gebruikt, en de bedrijven die zich in het veranderen van elders uitgevonden technologie in iets specialiseren dat `` makkelijk te gebruiken '' zonder enige deskundigheid eerder zullen software produceren die kan zijn fooled. De verdere overweging van dit onderwerp zou lonend [ 3]zijn, maar is voorbij het toepassingsgebied van dit document. 2.6 Zal IPSEC firewalls verouderd maken? Sommigen hebben gedebatteerd dat dit het geval is. Alvorens een dergelijke vegende voorspelling uit te spreken, echter, is het lonend om te overwegen welke IPSEC is en wat het doet. Zodra wij dit kennen, kunnen wij overwegen of IPSEC de problemen zal oplossen die wij proberen om met firewalls op te lossen. IPSEC (IP SECurity) verwijst naar een reeks normen die door de Werkgroep van de Techniek van Internet (IETF) worden ontwikkeld. Er zijn vele documenten die collectief bepalen wat `` IPSEC '' [ 6 ]genoemd gewordenis. IPSEC lost twee problemen op die de IP protocolreeks jarenlang hebben geteisterd: gastheer-aan-gastheer authentificatie (die gastheren zullen laten weten dat zij aan de gastheren spreken die zij zij) hebben gedacht zijn en encryptie (wat aanvallers zal verhinderen op het verkeer te kunnen letten gaand tussen machines). Merk op dat geen van beiden van deze problemen welke is firewalls om werden gecreeerd op te lossen. Hoewel de firewalls kunnen helpen om enkele risico's te verlichten huidig op Internet zonder authentificatie of encryptie, zijn er werkelijk twee klassen hier van problemen: integriteit en privacy van de informatie die tussen gastheren en de geplaatste grenzen stroomt op welke soorten connectiviteit tussen verschillende netwerken wordt toegestaan. IPSEC richt de eerstgenoemde klasse en de firewalls laatstgenoemde. Wat dit betekent is dat één zal elimineren niet de behoefte aan andere, maar het leidt tot sommige interessante mogelijkheden wanneer wij het combineren van firewalls met ipsec-Toegelaten gastheren bekijken. Namelijk, zullen dergelijke dingen zoals verkoper-onafhankelijke virtuele privé netwerken (VPNs), het betere pakket filtreren (door op of te filtreren de pakketten Ipsec- authentificatieheader) hebben, en toepassing-laag firewalls betere middelen van gastheercontrole kunnen hebben door Ipsec- authentificatieheader in plaats van `` eigenlijk te gebruiken enkel vertrouwend op '' het IP voorgestelde adres. 2.7 Wat zijn goede bronnen van af:drukken informatie over firewalls? Er zijn verscheidene boeken die op firewalls betrekking hebben. Het best het geweten is: De bouw Firewalls van Internet, 2d ED. Authors Elizabeth D. Zwicky, Simon Cooper, en ISBN 1-56592-871-7 van de Uitgave 2000 van de Uitgever O'Reilly van D. Brent Chapman Firewalls en de Veiligheid van Internet: Het afweren van de Wily Auteurs Bill Cheswick, Steve Bellovin, Uitgave 2003 ISBN 020163466X van de Hakker van Addison Wesley van de Uitgever van Avi Rubin De praktische Internet & Auteurs Simson Garfinkel van de Veiligheid van Unix en ISBN 1-56592-148-8 van de Uitgave 1996 van de Uitgever O'Reilly van Spafford van het Gen de Nota bespreken hoofdzakelijk de veiligheid van de gastheer. De verwante verwijzingen zijn: Onderlinge verbinding van netwerken met TCP/IP Bezoeker van Douglas van de Auteurs van Vols I, II, en de III en ISBN van David Stevens Publisher Prentice-Hall Edition 1991 0-13-468505-9 (I), 0-13-472242-6 (II), 0-13-474222-2 (Iii) de Commentaar A detailleerde bespreking over de architectuur en de implementatie van Internet en zijn protocollen. Volume I (op principes, protocollen en architectuur) is leesbaar door iedereen. Volume 2 (op ontwerp, implementatie en internals) is technischer. Volume 3 dekkingsclient-server gegevensverwerking. De Veiligheid van het Systeem van Unix -- een Gids voor ISBN 0-201-56327-4 van de Uitgave 1992 van David Curry Publisher Addison Wesley van de Auteur van Gebruikers en van de Beheerders van het Systeem 2.8 Waar kan ik meer informatie over firewalls op Internet krijgen? Het Handboek http://www.rfc-editor.org/rfc/rfc2196.txt van de Veiligheid van de plaats het Handboek van de Veiligheid van de Plaats is een informatieIetf- document dat de basiskwesties beschrijft die voor de bouw van goede plaatsveiligheid moeten worden behandeld. De firewalls zijn één deel van een grotere veiligheidsstrategie, zoals het Handboek van de Veiligheid van de Plaats toont. De Adressenlijst http://www.isc.org/index.pl?/ops/lists/firewalls van firewalls/de Internet firewalls adressenlijst zijn een forum voor firewallbeheerders en implementors. Firewall-tovenaars is de http://honor.icsalabs.com/mailman/li...wall-tovenaars van de Adressenlijst de Adressenlijst van de Tovenaars van de Firewall een gematigde firewall en een veiligheid verwante lijst die meer als een dagboek dan een openbare soapbox is. De firewall HOWTO http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html beschrijft precies wat nodig is om een firewall te bouwen, in het bijzonder gebruikend Linux. Toolkit van de firewall (FWTK) en de Documenten ftp://ftp.tis.com/pub/firewalls van de Firewall/de verwante publicaties http://www.ranum.com/pubs van Marcus Ranum's firewall/Universitaire de veiligheidshulpmiddelen http://www.net.tamu.edu/ftp/security/TAMU van Texas A&M/de pagina http://www.cerias.purdue.edu/coast/firewalls van de Firewalls van Internet van het Project van de KUST/ Back to Top Firewall FAQ in Nederlands Deel 2 3 De Kwesties van het ontwerp en van de Implementatie 3.1 Wat zijn enkele basisontwerpbesluiten in een firewall? Er zijn een aantal basisontwerpkwesties die door de gelukkige persoon zouden moeten worden behandeld die met de verantwoordelijkheid om is belast, op de installatie van een firewall in het leven te roepen te specificeren en uit te voeren of toezicht te houden. Het eerste en belangrijkste besluit vormt een weerspiegeling van het beleid van hoe uw bedrijf of organisatie het systeem willen in werking stellen: is vormt de firewall op zijn plaats uitdrukkelijk om alle diensten behalve die kritiek aan de opdracht van het verbinden met Netto, of de firewall op zijn plaats om een gemeten en gecontroleerde methode van `` toegang een rij '' op een niet-dreigt manier te verstrekken te ontkennen? Er zijn graden van paranoia tussen deze posities; de definitieve houding van uw firewall zou meer het resultaat van politiek kunnen zijn dan een techniekbesluit. De tweede is: welk niveau van controle, overtolligheid, en controle wilt u? Hebben duidelijk gemaaktd het aanvaardbare risiconiveau (d.w.z., hoe paranoïde u) bent door de eerste kwestie op te lossen, kunt u een controlelijst vormen van wat worden gecontroleerd, zou moeten worden toegelaten en, worden ontkend. Met andere woorden, begint u door uw algemene doelstellingen te berekenen, en combineert dan een behoeftenanalyse met een risicoberekening, en regelt de bijna altijd tegenstrijdige vereisten in een wasserijlijst die specificeert wat u van plan bent om uit te voeren. De derde kwestie is financieel. Wij kunnen dit één in allesbehalve vage termen hier richten niet, maar het is belangrijk proberen om om het even welke voorgestelde oplossingen te kwantificeren in termen van hoeveel het of om zal kosten te kopen of uit te voeren. Bijvoorbeeld, kan een volledig firewallproduct tussen $100.000 op het hoge eind kosten, en vrij op het lage eind. De vrije optie, van het doen van wat het buitensporige vormen op een Cisco of een gelijkaardige router zal niets dan personeelstijd en een paar koppen van koffie kosten. Het uitvoeren van een hoge eindfirewall van zou kras kunnen kosten verscheidene man-maanden, die aan waarde $30.000 van personeelssalaris en voordelen kunnen vergelijken. De systeembeheersingsoverheadkosten zijn ook een overweging. De bouw huis-brouwt is fijn, maar het is belangrijk om het te bouwen zodat het geen constante (en dure) aandacht vereist. Het is belangrijk, met andere woorden, om firewalls niet alleen te evalueren in termen van wat zij nu, maar voortdurende kosten zoals steun kosten. Technisch gezien, zijn er een paar besluiten te maken, gebaseerd op het feit dat voor alle praktische doeleinden wat wij spreken over de statische verkeers leidende dienst die tussen de netwerkrouter van de dienstverlener en uw intern netwerk wordt geplaatst is. De verkeers leidende dienst kan op een IP niveau via iets als onderzoeksregels in een router, of op een toepassingsniveau via de volmachtsgateways en diensten worden uitgevoerd. Het besluit te maken is hetzij blootgesteld ont*doen-onderaan machine op het buitennetwerk te plaatsen om de volmachtsdiensten voor Telnet, FTP, nieuws, enz. te leiden, of of om een onderzoeksrouter als filter op te zetten, toelatend communicatie met één of meerdere interne machines. Er zijn voordelen en nadelen aan beide benaderingen, met de volmachtsmachine die een groter niveau van controle en, potentieel, veiligheid in ruil daarvoor voor verhoogde kosten in configuratie en een daling van het niveau van dienstverlening verstrekt dat kan worden verstrekt (aangezien een volmacht voor elke gewenste dienst) moet worden ontwikkeld. De oude inruil tussen handigheid en veiligheid komt terug om ons met vengeance te achtervolgen. 3.2 Wat zijn de basistypes van firewalls? Conceptueel, zijn er drie types van firewalls: De laag van het netwerk De laag van de toepassing Hybriden Zij zijn niet zo verschillend aangezien u zou kunnen denken, en de recentste technologieën vertroebelen het onderscheid aan het punt waar het niet meer duidelijk is als of één `` betere '' of slechter ``.' ' is Zoals altijd, moet u zorgvuldig zijn om het type te plukken dat aan uw behoeften voldoet. Welke is welke afhangt van welke mechanismen de firewall gebruikt om verkeer van één veiligheidsstreek tot een andere over te gaan. De Open Systemen Van de Internationale Organisatie voor normalisatie (ISO) verbinden (OSI) model onderling want het voorzien van een netwerk zeven lagen bepaalt, waar elke laag de diensten verleent dat lagen `` higher-level '' van afhangen. In orde van de bodem, zijn deze lagen fysiek, dataverbinding, netwerk, vervoer, zitting, presentatie, toepassing. Het belangrijke te erkennen ding is dat het op lager niveau het het door:sturen mechanisme, het minder onderzoek de firewall kan uitvoeren. In het algemeen, de firewalls zijn op lager niveau sneller, maar zijn gemakkelijker aan dwaas in het doen van het verkeerde ding. Deze dagen, vallen de meeste firewalls in de categorie `` hybride '', die netwerk het filtreren evenals één of andere hoeveelheid toepassingsinspectie doen. Het bedrag verandert afhankelijk van de verkoper, het product, het protocol en de versie, zodat is één of ander niveau van het graven en/of het testen vaak noodzakelijk. 3.2.1 De laagfirewalls van het netwerk Deze nemen over het algemeen hun besluiten die op de bron, de bestemmingsadressen en de havens (zie Bijlage 6 voor een meer gedetailleerde bespreking van havens) worden gebaseerd in individuele IP pakketten. Een eenvoudige router is de `` traditionele '' firewall van de netwerklaag, aangezien het in het bijzonder geen verfijnde besluiten kan nemen over wat een pakket eigenlijk spreekt aan of waar het eigenlijk uit kwam. De moderne firewalls van de netwerklaag zijn meer en meer verfijnd geworden, en nu interne informatie over de staat van aanslutingen die door hen, de inhoud overgaan gehandhaafd van enkele gegevensstromen, enz. zo. Één ding dat een belangrijk onderscheid over vele firewalls van de netwerklaag is dat zij niettemin verkeer direct hen leiden, zodat om één te gebruiken u of moet een geldig toegewezen IP adresblok hebben of een blok van het `` privé Internet '' adres gebruiken [5]. De de laagfirewalls van het netwerk neigen zeer snel te zijn en zeer transparant te neigen aan gebruikers te zijn. Figuur 1: De onderzochte Firewall van de Gastheer In Figuur 1, wordt een firewall van de netwerklaag genoemd een `` onderzochte gastheerfirewall '' vertegenwoordigd. In een onderzochte gastheerfirewall, wordt de toegang tot en van één enkele gastheer met behulp van een router gecontroleerd die bij een netwerklaag werkt. De enige gastheer is een bastion gastheer; een hoogst-verdedigd en beveiligd sterk-punt dat (hopelijk) zich tegen aanval kan verzetten. Figuur 2: Onderzochte Subnet Firewall De laagfirewall van het Netwerk van het voorbeeld: In Figuur 2, wordt een firewall van de netwerklaag genoemd een `` onderzochte subnet firewall '' vertegenwoordigd. In een onderzochte subnet firewall, wordt de toegang tot en van een geheel netwerk met behulp van een router gecontroleerd die bij een netwerklaag werkt. Het is gelijkaardig aan een onderzochte gastheer, behalve dat is het, effectief, een netwerk van onderzochte gastheren. 3.2.2 De laagfirewalls van de toepassing Dit over het algemeen zijn gastheren die volmachtsservers in werking stellen, die direct geen verkeer tussen netwerken toelaten, en die gedetailleerde registreren en controle van verkeer verrichten dat door hen overgaat. Aangezien de volmachtstoepassingen softwarecomponenten die op de firewall lopen zijn, is het een goede plaats om veel registreren en toegangsbeheer te doen. De de laagfirewalls van de toepassing kunnen als vertalers van het netwerkadres worden gebruikt, aangezien het verkeer in één `` zij'' en uit andere, na door een toepassing gaat overgegaan te hebben die effectief de oorsprong van de het in werking stellen aansluting maskeert. Het hebben van een toepassing op de manier kan in sommige gevallen prestaties beïnvloeden en kan de firewall minder transparant maken. De vroege gebouwde firewalls van de toepassingslaag zoals die gebruikend TIS firewalltoolkit, zijn niet bijzonder transparant aan eindgebruikers en kunnen wat opleiding vereisen. De moderne firewalls van de toepassingslaag zijn vaak volledig transparant. De de laagfirewalls van de toepassing neigen om meer gedetailleerde controleverslagen te verstrekken en te neigen om conservatievere veiligheidsmodellen af te dwingen dan de firewalls van de netwerklaag. Figuur 3: Dubbele Automatisch begesturde Gateway De laagfirewall van de Toepassing van het voorbeeld: In Figuur 3, wordt een firewall van de toepassingslaag genoemd een `` dubbele automatisch begesturde gateway '' vertegenwoordigd. Een dubbele automatisch begesturde gateway is een hoogst beveiligde gastheer die volmachtssoftware in werking stelt. Het heeft twee netwerkinterfaces, op elk netwerk, en blokkeert al verkeer dat door het overgaat. De meeste firewalls liggen nu someplace tussen de firewalls van de netwerklaag en de firewalls van de toepassingslaag. Zoals verwacht, zijn de firewalls van de netwerklaag meer en meer `` bewuste '' van de informatie geworden die door hen gaat, en de firewalls van de toepassingslaag zijn meer en meer `` laag niveau '' en transparant geworden. Het eindresultaat is dat nu er snelle pakket-onderzoekende systemen zijn die logboek en controlegegevens aangezien zij door het systeem overgaan. Meer en meer, nemen de firewalls (netwerk en toepassingslaag) encryptie op zodat zij kunnen verkeer beschermen dat tussen hen over Internet overgaat. De firewalls met de encryptie van begin tot eind kunnen door organisaties met veelvoudige punten van de connectiviteit van Internet worden gebruikt om Internet als `` privé backbone '' te gebruiken zonder zich het ongerust maken over hun gegevens of wachtwoorden die worden gesnoven. (IPSEC, die in Sectie 2.6 wordt beschreven, speelt een meer en meer significante rol in de bouw van dergelijke virtuele privé netwerken.) 3.3 Wat zijn volmachtsservers en hoe werken zij? Een volmachtsserver (die soms als toepassingsgateway of forwarder wordt bedoeld) is een toepassing die verkeer tussen een beschermd netwerk en Internet bemiddelt. De volmachten worden vaak gebruikt in plaats van op router-gebaseerde verkeerscontroles, om verkeer te verhinderen direct tussen netwerken over te gaan. Vele volmachten bevatten extra registreren of steun voor gebruikersauthentificatie. Aangezien de volmachten `` '' moeten begrijpen het toepassingsprotocol dat wordt gebruikt, kunnen zij protocol-specifieke veiligheid (b.v., zou een volmacht van FTP configureerbaar kunnen zijn om inkomend FTP toe te laten en uitgaand FTP te blokkeren) ook uitvoeren. De servers van de volmacht zijn specifieke toepassing. Om een nieuw protocol via een volmacht te steunen moet een volmacht voor het worden ontwikkeld. Één populaire reeks volmachtsservers is Toolkit van de Firewall van TIS Internet (``FWTK '') die volmachten voor Telnet omvat, rlogin, FTP, het Systeem van het Venster van X, HTTP/het Web, en het nieuws van NNTP/van Usenet. De SOKKEN is een generisch volmachtssysteem dat in een cliënt-zijtoepassing kan worden gecompileerd om het te maken door een firewall werken. Zijn voordeel is dat het makkelijk te gebruiken is, maar het steunt niet de toevoeging van authentificatiehaken of protocol-specifiek registreren. Voor meer informatie over SOKKEN, zie http://www.socks.nec.com/. 3.4 Wat zijn sommige goedkope hulpmiddelen van het pakketonderzoek? De Universitaire de veiligheidshulpmiddelen van Texas A&M omvatten software voor het uitvoeren van onderzoeksrouters. Karlbridge is een Pc-based uitrusting van de onderzoeksrouter beschikbaar bij ftp://ftp.net.ohio-state.edu/pub/kbridge/. Er zijn talrijke pit-vlakke pakketschermen, met inbegrip van ipf, ipfw, ipchains, pf, en ipfwadm. Typisch, zijn deze inbegrepen in diverse vrije implementaties van Unix, zoals FreeBSD, OpenBSD, NetBSD, en Linux. U zou deze hulpmiddelen in uw commerciële implementatie van Unix beschikbaar ook kunnen vinden. Als u bereid bent om uw handen een weinig vuil te krijgen, is het volledig mogelijk om een veilige en volledig functionele firewall voor de prijs van hardware en sommige van uw tijd te bouwen. 3.5 Wat zijn sommige redelijke het filtreren regels voor het op pit-gebaseerd pakketscherm? Dit voorbeeld wordt geschreven specifiek voor ipfwadm op Linux, maar de principes (en zelfs veel van de syntaxis) zijn voor andere pitinterfaces van toepassing voor pakketonderzoek op `` de open systemen bron'' van Unix. Er zijn vier basiscategorieën die door de ipfwadm regels worden behandeld: - A De Boekhouding van het pakket - I De firewall van de input - O De firewall van de output - F Het door:sturen van firewall ipfwadm heeft zich ook het vermommen van (- M) mogelijkheden. Voor meer informatie over schakelaars en opties, zie de pagina van de ipfwadm mens. 3.5.1 Implementatie Hier, onze organisatie gebruikt een privé (RFC ;1918) netwerk 192.168.1.0. van de Klasse C Onze ISP heeft ons adres 201.123.102.32 voor de externe interface van onze gateway en 201.123.102.33 voor onze externe postserver toegewezen. Het organisatorische beleid zegt: Sta alle uitgaande aanslutingen van TCP toe Sta inkomende SMTP en DNS aan externe postserver toe Blokkeer al ander verkeer Het volgende blok van bevelen kan in een dossier van de systeemlaars worden geplaatst (misschien rc.local op de systemen van Unix). ipfwadm - F - F ipfwadm - F - p ontkent ipfwadm - F - I m - B - TCP van P - S 0.0.0.0/0 1024:65535 - D 201.123.102.33 25 ipfwadm - F - I m - B - TCP van P - S 0.0.0.0/0 1024:65535 - D 201.123.102.33 53 ipfwadm - F - I m - B - P udp - S 0.0.0.0/0 1024:65535 - D 201.123.102.33 53 ipfwadm - F - m - S 192.168.1.0/24 - D 0.0.0.0/0 - W eth0/22#sbin/route voegt toe - gastheer 201.123.102.33 GW 192.168.1.2 3.5.2 Verklaring De lijn spoelt (- F) allen die (door:sturen- F) regels. Lijn twee reeksen het default- te ontkennen beleid(-p) . Lijnen drie door vijf zijn ingevoerde regels (- I) in het volgende formaat: ipfwadm - F (vooruit) - I (input) m (masq.) - B (tweerichtings) - protocol)[protocol van P ]- S (source)[subnet/masker ] [ voortkomende havens ]- D (destination)[subnet/mask][port ] Lijn zes voegt (- a) een regel toe die uit alle interne IP adressen aan alle externe adressen op alle protocollen, alle havens toelaat. Lijn acht voegt een route toe zodat het verkeer dat naar 201.123.102.33 gaat aan intern adres 192.168.1.2 zal worden geleid. 3.6 Wat zijn sommige redelijke het filtreren regels voor een Cisco? Het voorbeeld in Figuur 4 toont één mogelijke configuratie voor het gebruiken van Cisco als het filtreren van router. Het is een steekproef die de implementatie van als specifiek beleid toont. Uw beleid zal ongetwijfeld variëren. Figuur 4: De Filtrerende Router van het pakket In dit voorbeeld, heeft een bedrijf het netwerkadres 195.55.55.0. van de Klasse C het netwerk van het Bedrijf met Internet via IP Dienstverlener Worden verbonden. Het beleid van het bedrijf is iedereen toegang tot de diensten van Internet te verlenen, zodat worden alle uitgaande aanslutingen goedgekeurd. Alle inkomende aanslutingen gaan door `` mailhost ''. De post en DNS zijn slechts de inkomende diensten. 3.6.1 Implementatie Sta alle uitgaande TCP-Verbindingen toe Sta inkomende SMTP en DNS aan mailhost toe Sta inkomende FTP- gegevensaanslutingen aan de hoge haven van TCP toe (1024) Probeer om de diensten te beschermen die op hoge havenaantallen leven Slechts worden de inkomende pakketten van Internet gecontroleerd in deze configuratie. De regels worden getest in orde en einde wanneer de eerste gelijke wordt gevonden. Er zijn impliciet ontkent regel aan het eind van een toegangslijst die alles ontkent. Deze IP toegangslijst veronderstelt dat u Cisco IOS v. 10,3 of later in werking stelt. geen ip bron-route! interface ethernet 0 ip adres 195.55.55.1 geen ip leiden-uitzending! interface serie 0 geen ip leiden-uitzendingsip toegang-groep 101 binnen! toegang-lijst 101 ontkent ip 127.0.0.0 0.255.255.255 om het even welke toegang-lijst 101 ontkent ip 10.0.0.0 0.255.255.255 om het even welke toegang-lijst 101 ontkent ip 172.16.0.0 0.15.255.255 om het even welke toegang-lijst 101 ontkent ip 192.168.0.0 0.0.255.255 om het even welke toegang-lijst 101 ip ontkent om het even welke 0.0.0.255 255.255.255.0 toegang-lijst 101 ip om het even welke 0.0.0.0 255.255.255.0 ontzegt! toegang-lijst 101 ontzegt ip 195.55.55.0 0.0.0.255 toegang-lijst 101 gevestigd om het even welk van vergunningscTcp! toegang-lijst 101 vergunningscTcp om het even welke gastheer 195.55.55.10 eq smtp toegang-lijst 101 vergunningscTcp om het even welke gastheer 195.55.55.10 eq22#dns toegang-lijst 101 vergunning udp om het even welke gastheer 192.55.55.10 eq dns! toegang-lijst 101 ontzegt TCP om het even welk om het even welk gamma 6000.6003 toegang-lijst 101 TCP om het even welk om het even welk gamma ontzeggen 2000.2003 toegang-lijst 101 TCP ontkennen om het even welke om het even welke eq 2049 toegang-lijst 101 udp om het even welke om het even welke eq 2049 ontkent! toegang-lijst 101 vergunningscTcp om het even welke 20 om het even welk GT 1024! toegang-lijst 101 vergunning icmp om het even welke om het even welk! de SNMP-SERVER communautaire FOOBAR RO 2 lijn vty 0.4 toegang-klasse 2 in toegang-lijst 2 laat 195.55.55.0 0.0.0.255 toe 3.6.2 Verklaringen Laat vallen alle bron-geleide pakketten. Het bron leiden kan voor adresvoor de gek houden worden gebruikt. De daling leidde uitzendingen, die in smurfaanvallen worden gebruikt. Als een inkomend pakket om van lokale netto eist te zijn, loopback laat vallen het netwerk, of het privé netwerk, het. Alle pakketten die deel reeds gevestigde TCP-Verbindingen uitmaken kunnen door zonder verder het controleren overgaan. Alle aanslutingen aan lage havenaantallen worden geblokkeerd behalve SMTP en DNS. Blokkeer alle diensten die op de aanslutingen van TCP op hoge havenaantallen letten. X11 (haven 6000 +), zijn OpenWindows (haven 2000 +) een paar kandidaten. NFS (haven 2049) loopt gewoonlijk over UDP, maar het kan over TCP worden in werking gesteld, zodat zou u het moeten blokkeren. De inkomende aanslutingen van haven 20 in hoge havenaantallen zijn verondersteld om FTP- gegevensaanslutingen te zijn. Toegang-lijst 2 beperkt toegang tot router zelf (Telnet & SNMP) Al verkeer UDP wordt geblokkeerd om de diensten te beschermen RPC 3.6.3 Tekortkomingen U kunt sterk toegangsbeleid met de lijsten van de routertoegang afdwingen niet. De gebruikers kunnen backdoors aan hun systemen gemakkelijk installeren om over `` geen inkomend Telnet '' te krijgen of `` geen X11 '' regels. Ook installeren de crackers Telnet backdoors op systemen waar zij binnen breken. U kunt nooit zeker zijn welke diensten u het letten van op aanslutingen op hoge havenaantallen hebt. (U kunt zeker zijn niet van welke diensten u het letten van op aanslutingen op lage havenaantallen hebt, of vooral in hoogst gedecentraliseerde milieu's waar de mensen hun eigen machines op het netwerk kunnen zetten of waar zij administratieve toegang tot hun eigen machines kunnen krijgen.) Het controleren van de bronhaven op inkomende FTP- gegevensaanslutingen is een zwakke veiligheidsmethode. Het breekt ook toegang tot sommige plaatsen van FTP. Het maakt gebruik van de dienst moeilijker voor gebruikers zonder slechte kerels te verhinderen uw systemen af te tasten. Gebruik minstens Cisco versie 9.21 zodat kunt u inkomende pakketten filtreren en adresvoor de gek houden controleren. Het is nog beter om 10,3 te gebruiken, waar u sommige extra eigenschappen (als het filtreren op bronhaven) en sommige verbeteringen op filtersyntaxis krijgt. U hebt nog een paar manieren om uw opstelling sterker te maken. Blokkeer alle inkomende TCP-Verbindingen en vertel gebruikers om cliënten te gebruiken passief-FTP. U kunt uitgaand Icmp echo--antwoord en bestemming-onbereikbare berichten ook blokkeren om uw netwerk te verbergen en gebruik van netwerkscanners te verhinderen. Cisco.com schijnt het gebruik om een archief van voorbeelden te hebben om firewalls te bouwen die routers Cisco met behulp van, maar het niet meer online te zijn. Er zijn sommige nota's over Cisco toegangsbeheerlijsten, minstens, bij ftp://ftp.cisco.com/pub/mibs/app_notes/access-lijsten. 3.7 Wat zijn de kritieke middelen in een firewall? Het is belangrijk om de kritieke middelen van uw firewallarchitectuur te begrijpen, zodat wanneer u capaciteit planning doet, de prestatiesoptimalisering, enz., u wat u precies weten moet doen, en hoeveel u nodig hebt om het te doen het gewenste resultaat krijgen. Wat precies de kritieke middelen van de firewall zijn neigen om van plaats aan plaats, afhankelijk van de soort verkeer te variëren die het systeem laadt. Sommige mensen denken zij automatisch de gegevensproductie van hun firewall door een vakje met een snellere cpu aan te brengen, of een andere cpu zullen kunnen verhogen, wanneer dit niet noodzakelijk het geval is. Potentieel, zou dit een groot afval van geld kunnen zijn dat om het even wat niet het dichtbije probleem doet oplossen of verwachte scalability verstrekken. Voor bezige systemen, is het geheugenuiterst belangrijk. U moet genoeg RAM hebben om elke instantie van elk programma te steunen noodzakelijk om de lading te onderhouden die op die machine wordt geplaatst. Anders, zal het ruilen beginnen en de productiviteit zal ophouden. Het lichte ruilen is niet gewoonlijk veel van een probleem, maar als de het ruilmiddelruimte van een systeem bezig begint te worden, dan is het gewoonlijk tijd voor meer RAM. Een systeem dat zwaar ruilen vaak vrij gemakkelijk om over de rand in een de ontkenning-van-dienst aanval is te duwen, of eenvoudig in de verwerking van de lading achterop raken plaatste op het. Dit is waar de lange e-mailvertragingen beginnen. Voorbij de eis van het systeem ten aanzien van geheugen, is het nuttig om te begrijpen dat de verschillende diensten verschillende systeemmiddelen gebruiken. Zo zou de configuratie die u voor uw systeem hebt van het soort lading indicatief moeten zijn u aan de dienst plant. Een bewerker 1400 MHz gaat niet veel goed u doen als allen u doet netnews en post is, en probeert om het op een schijf van winde met een ISA controlemechanisme te doen. Lijst 1: Kritieke Middelen voor de Diensten van de Firewall De dienst Kritiek Middel E-mail Schijf I/O Netnews Schijf I/O Web Os van de gastheer de Prestaties van de Contactdoos Ip het Leiden Os van de gastheer de Prestaties van de Contactdoos Het Geheime voorgeheugen van het Web Os van de gastheer de Prestaties van de Contactdoos, Schijf I/O 3.8 Wat is een DMZ, en waarom ik wil één? `` DMZ '' is een afkorting voor `` gedemilitariseerde streek ''. In de context van firewalls, verwijst dit naar een deel van het netwerk dat noch een deel van het interne netwerk noch direct een deel van Internet is. Typisch, is dit het gebied tussen uw de toegangsrouter van Internet en uw bastion gastheer, hoewel het tussen om het even welke twee beleid-afdwingende componenten van uw architectuur kan zijn. Een DMZ kan worden gecreeerd door toegangsbeheerlijsten op uw toegangsrouter te zetten. Dit minimaliseert de blootstelling van gastheren op uw externe LAN door slechts toegankelijk de erkende en beheerde diensten op die gastheren toe te staan om te zijn door gastheren op Internet. Vele commerciële firewalls maken weg eenvoudig een derde interface van de bastion gastheer en etiketteren het DMZ, is het punt dat het netwerk noch `` binnen '' noch `` buiten ''. is Bijvoorbeeld, zou een Webserver die op NT loopt aan een aantal de ontkenning-van-dienst aanvallen tegen dergelijke diensten kwetsbaar kunnen zijn zoals RPC, NetBIOS en SMB. Deze diensten worden niet vereist voor de verrichting van een Webserver, zo blokkerend de aanslutingen van TCP aan havens 135..137..138, en 139 op die gastheer zullen de blootstelling aan een de ontkenning-van-dienst aanval verminderen. In feite, als u alles maar het verkeer van HTTP aan die gastheer blokkeert, zal een aanvaller slechts de één aan te vallen dienst hebben. Dit illustreert een belangrijk principe: nooit bied aanvallers meer aan het werk met dan aan absoluut noodzakelijk is om de diensten te steunen u het publiek wilt Back to Top Firewall FAQ in Nederlands Deel 3 3.9 Hoe ik de veiligheid en scalability van mijn DMZ zou kunnen verhogen? Een gemeenschappelijke benadering voor een aanvaller is in een gastheer te breken die kwetsbaar aan aanval, en vertrouwensverband tussen de kwetsbare gastheer en de interessantere doelstellingen exploiteer. Als u een aantal diensten leidt die verschillende niveaus van veiligheid hebben, zou u kunnen willen nadenken brekend uw DMZ in verscheidene `` veiligheidsstreken '. Dit kan door het hebben van een aantal verschillende netwerken binnen DMZ worden gedaan. Bijvoorbeeld, kon de toegangsrouter twee Ethernets, zowel voeden die door ACLs, en daarom in DMZ wordt beschermd. Op één van Ethernets, zou u gastheren kunnen hebben het van wie doel de behoefte van uw organisatie aan de connectiviteit van Internet te onderhouden is. Deze zullen post, waarschijnlijk nieuws, en gastheer DNS aflossen. Op andere Ethernet uw Webserver (s) en andere gastheren zou kunnen zijn die de diensten ten voordele van de gebruikers van Internet verlenen. In vele organisaties, neigen de diensten voor de gebruikers van Internet minder zorgvuldig worden bewaakt en zullen eerder onzekere dingen doen. (Bijvoorbeeld, in het geval van een Webserver, zouden de niet bekrachtigde en onbetrouwbare gebruikers CGI, PHP, of andere uitvoerbare programma's kunnen leiden. Dit zou voor uw Webserver redelijk kunnen zijn, maar brengt met het een bepaalde reeks risico's die moeten worden beheerd. Het is waarschijnlijk deze diensten is te gewaagd voor een organisatie om hen op een bastion gastheer in werking te stellen, waar misstap-omhooggaand in de volledige mislukking van de veiligheidsmechanismen kan resulteren.) Door gastheren met gelijkaardige niveaus van risico op netwerken in DMZ samen te brengen, kunt u helpen het effect van een test bij uw plaats minimaliseren. Als iemand in uw Webserver door één of ander insect in uw Webserver te exploiteren breekt, zullen zij het als lanceringspunt kunnen gebruiken om in uw privé netwerk te breken als de Webservers op afzonderlijke LAN van de bastion gastheren zijn, en u hebt geen vertrouwensverband tussen de de Webserver en bastion gastheer. Nu, houd in mening dat dit Ethernet is. Als iemand in uw Webserver breekt, en uw bastion gastheer op zelfde Ethernet is, kan een aanvaller een sniffer installeren op uw Webserver, en op het verkeer letten aan en van uw bastion gastheer. Dit zou dingen kunnen openbaren die kunnen worden gebruikt om in de bastion gastheer te breken en tot het interne netwerk toegang te krijgen. (Geschakelde Ethernet kan uw blootstelling aan dit soort probleem verminderen, maar zal het niet. elimineren) De verdelende diensten omhoog niet alleen door gastheer, maar door netwerk, en het beperken van het niveau van vertrouwen tussen gastheren op die netwerken, u kunnen de waarschijnlijkheid van een test die op één om gastheer zeer verminderen worden gebruikt om in andere te breken. Beknopt verklaard: het breken in de Webserver in zal dit geval het geen gemakkelijker maken om in de bastion gastheer te breken. U kunt scalability van uw architectuur ook verhogen door gastheren op verschillende netwerken te plaatsen. De minder machines dat er de beschikbare bandbreedte zijn, de meer bandbreedte te delen die elk zal krijgen. 3.10 Wat is één enkel punt ` van mislukking ', en hoe vermijd ik hebbend? Een architectuur de waarvan veiligheid op één mechanisme van een scharnier voorziet heeft één enkel punt van mislukking. De software die bastion gastheren in werking stelt heeft insecten. De toepassingen hebben insecten. Software dat de controlesrouters insecten heeft. Het houdt steek om elk van deze componenten te gebruiken om een veilig ontworpen netwerk te bouwen, en hen te gebruiken op overtollige manieren. Als uw firewallarchitectuur onderzochte subnet is, hebt u twee pakket filtrerende routers en een bastion gastheer. (Merk vraag 3,2 aan deze sectie.) Uw de toegangsrouter zal van Internet geen verkeer van Internet toelaten om al manier in uw privé netwerk te krijgen. Nochtans, als u niet afdwingt dat de regel met een andere mechanismen op de bastion gastheer en/of vernauwingsrouter, slechts één component van uw architectuur moet ontbreken of worden gecompromitteerd binnen te worden. Enerzijds, als u een overtollige regel op de bastion gastheer, en opnieuw op de vernauwingsrouter hebt, zal een aanvaller drie mechanismen moeten verslaan. Verder, als de bastion gastheer of de vernauwingsrouter zijn regel moeten aanhalen om buitentoegang tot het interne netwerk te blokkeren, zou u kunnen willen het hebben een alarm van één of andere soort teweegbrengen, aangezien u weet dat iemand door uw toegangsrouter heeft gekregen. 3.11 Hoe kan ik het elk van slecht materiaal blokkeren? Voor firewalls waar de nadruk op veiligheid in plaats van connectiviteit is, zou u moeten nadenken blokkerend alles door gebrek, en slechts toestaand specifiek welke diensten u op een basis geval per geval wenst. Als u alles, behalve een specifieke reeks diensten blokkeert, dan hebt u reeds uw baan veel gemakkelijker gemaakt. In plaats van het moeten zich over elk veiligheidsprobleem met rond alles product en de dienst ongerust maken, moet u slechts zich over elk veiligheidsprobleem met een specifieke reeks de diensten en producten ongerust maken. Alvorens de dienst aan te zetten, zou u een paar vragen moeten overwegen: Is het protocol voor dit product een bekend, gepubliceerd protocol? Is de toepassings dienst dit protocol beschikbaar voor openbare inspectie van zijn implementatie? Hoe bekend zijn de dienst en het product? Hoe verandert het toestaan van deze dienst de firewallarchitectuur? Zal een aanvaller dingen verschillend zien? Kon het om bij mijn intern netwerk, dingen op gastheren in mijn DMZ te veranderen te krijgen of worden geëxploiteerd? Wanneer het overwegen van de bovengenoemde vragen, houd het volgende in mening: `` de veiligheid door obscurity '' is geen veiligheid bij allen. De ongepubliceerde protocollen zijn onderzocht door slechte kerels en verslagen. Ondanks wat de op de markt brengende vertegenwoordigers zeggen, niet elke protocol of dienst wordt ontworpen met veiligheid in mening. In feite, is het aantal dat is zeer weinigen. Zelfs in gevallen waarbij de veiligheid een overweging is, niet hebben alle organisaties bekwaam veiligheidspersoneel. Onder zij die niet, niet zijn allen bereid om een bekwame adviseur in het project te brengen. Het eindresultaat is anders-bekwaam dat, kunnen de goed-bedoelde ontwikkelaars onzekere systemen ontwerpen. Is minder dat een verkoper bereid om u over hoe is te vertellen hun systeem werkelijk werkt, waarschijnlijker het dat veiligheid (of andere) er problemen bestaan. Slechts hebben de verkopers met iets aan huid een reden om hun ontwerpen en implementaties [ 2]te verbergen. 3.12 Hoe kan ik Web beperken toegang zodat kunnen de gebruikers niet niet verwante plaatsen om te werken bekijken? Een paar jaar geleden, kreeg iemand het idee dat het een goed idee is om websites `` slechte '' te blokkeren, d.w.z., die die materiaal dat de meningen van het Bedrijf `` ongepaste ''. bevatten Het idee is in populariteit gestegen, maar er zijn verscheidene te overwegen dingen wanneer het denken over het uitvoeren van dergelijke controles in uw firewall. Het is niet mogelijk alles praktisch om te blokkeren dat een werkgever `` ongepaste ''. acht Internet is volledig van elke soort materiaal. Het blokkeren van één bron zal slechts verkeer aan een andere bron van dergelijk materiaal, opnieuw richten of zal iemand ertoe bewegen om een manier rond het blok voor te stellen. De meeste organisaties hebben geen norm voor het beoordelen van de geschiktheid van materiaal die hun werknemers brengen om, b.v., boeken en tijdschriften te werken. Inspecteert u de aktentas van iedereen voor `` ongepaste materiële '' elke dag? Als u niet, dan waarom u elk pakket voor `` ongepaste materiële ''? zou inspecteren Om het even welke besluiten volgens die lijnen in een dergelijke organisatie zullen willekeurig zijn. Proberen om disciplinaire actie tegen een werknemer te voeren waar de enige norm typisch willekeurig is is niet wijs, goed om redenen voorbij het toepassingsgebied van dit document. De producten die commercieel plaats-blokkeert uitvoeren, en anders, zijn typisch gemakkelijk te omringen. Hostnames kan als IP adressen worden herschreven. Ip de adressen kunnen als geheelwaarde met 32 bits, of als vier gehelen met 8 bits worden geschreven (de gemeenschappelijkste vorm). Andere mogelijkheden bestaan, eveneens. De aanslutingen kunnen zijn proxied. De Web-pagina's kunnen via e-mail worden gehaald. U kunt hen blokkeren niet allen. De inspanning dat u het proberen zult besteden om dergelijke controles uit te voeren en te beheren zal bijna zeker ver om het even welk niveau van schadecontrole overschrijden dat u hoopt te hebben. Rule-of-thumb zich hier te herinneren is dat u sociale problemen met technologie niet kunt oplossen. Als er een probleem met iemand dat naar een website `` gaat ongepaste '' is, is dat omdat iemand anders zag het en werd beledigd door wat hij zag, of omdat de productiviteit van die persoon onder verwachtingen is. In één van beide geval, zijn die kwesties voor de personeelsafdeling, niet de firewallbeheerder. 4 Diverse Aanvallen 4.1 Wat is bron geleid verkeer en waarom is het een bedreiging? Normaal, wordt de route een pakket uit zijn bron aan zijn bestemming neemt bepaald door de routers tussen de bron en de bestemming. Het pakket zelf zegt slechts waar het wil gaan (het bestemmingsadres), en niets over hoe het denkt daar te worden. Er is een facultatieve manier want de afzender van een pakket (de bron) om informatie in het pakket te omvatten dat de route het pakket vertelt zou moeten nemen om aan zijn bestemming te krijgen; aldus naam`` bron het leiden ''. Voor een firewall, het bron is leiden opmerkelijk, aangezien een aanvaller verkeer kan produceren eisend om van een systeem `` binnen '' de firewall te zijn. In het algemeen, zou dergelijk verkeer niet aan de firewall behoorlijk leiden, maar met de bron het leiden optie, zullen alle routers tussen de machine van de aanvaller en het doel verkeer langs de omgekeerde weg van de bronroute terugkeren. Uitvoeren van een dergelijke aanval is vrij gemakkelijk; zo zouden de firewallbouwers niet het moeten voorzien onwaarschijnlijk te gebeuren. In de praktijk, het bron wordt leiden zeer weinig gebruikt. In feite, over het algemeen is het belangrijkste wettige gebruik in het zuiveren netwerk problemen of het leiden verkeer over specifieke links voor congestiecontrole voor gespecialiseerde situaties. Wanneer het bouw van een firewall, het bron zou leiden op wat punt moeten worden geblokkeerd. De meeste commerciële routers nemen de capaciteit op om het bron specifiek leiden te blokkeren, en vele versies van Unix die zouden kunnen worden gebruikt om firewallbastion gastheren te bouwen hebben de capaciteit om bron geleid verkeer onbruikbaar te maken of te negeren. 4.2 Wat zijn ICMP opnieuw richten en opnieuw richten bommen? Een ICMP richt vertelt het ontvankelijke systeem opnieuw om iets in zijn het leiden lijst met voeten te treden. Het wordt wettig gebruikt door routers om gastheren te vertellen dat de gastheer een niet optimale of overledde route aan een bepaalde bestemming, d.w.z., de gastheer verzendt het naar de verkeerde router gebruikt. De verkeerde router verzendt de gastheerrug een ICMP pakket opnieuw richt dat de gastheer vertelt wat de correcte route zou moeten zijn. Als u ICMP kunt smeden richt pakketten opnieuw, en als uw doelgastheer aandacht aan hen besteedt, kunt u de het leiden lijsten aangaande de gastheer veranderen en misschien de veiligheid van de gastheer ontwrichten door verkeer te veroorzaken om via een weg te stromen de netwerkmanager niet van plan was. ICMP richt ook kan voor ontkenning van de dienstaanvallen opnieuw worden aangewend, waar een gastheer een route wordt verzonden die verliest het connectiviteit, of een Onbereikbaar pakket van het Netwerk ICMP vertellend het verzonden dat het to t een bepaald netwerk kan niet meer toegang hebben. Veel het schermicmp verkeer van firewallbouwers van hun netwerk, aangezien het de capaciteit van buitenstaanders tot ping gastheren beperkt, of wijzigt hun het leiden lijsten. Alvorens u beslist alle pakketten te blokkeren ICMP, zou u van zich bewust moeten zijn hoe het protocol van TCP `` de Ontdekking van de Weg MTU '', dat doet bepaald maken u geen connectiviteit aan andere plaatsen breekt. Als u het niet kunt veilig blokkeren overal, kunt u nadenken toestaand geselecteerde soorten ICMP aan geselecteerde het leiden apparaten. Als u het niet blokkeert, zou u minstens moeten ervoor zorgen dat uw routers en gastheren niet aan uitzendingsping pakketten antwoorden. 4.3 Wat over ontkenning van de dienst? De ontkenning van de dienst is wanneer iemand beslist uw netwerk of firewall nutteloos te maken door het onderbreken van het, het verpletteren van het, het te blokkeren, of het te overstromen. Het probleem met ontkenning van de dienst op Internet is dat het onmogelijk is te verhinderen. De reden moet met de verdeelde aard van het netwerk doen: elke netwerkknoop wordt verbonden via andere netwerken die beurtelings met andere netwerken, enz. verbinden. Een firewallbeheerder of ISP hebben slechts controle van enkelen van de lokale elementen binnen bereik. Een aanvaller kan een aansluting `` stroomopwaartse '' van altijd onderbreken waar het slachtoffer het controleert. Met andere woorden, als iemand een netwerk uit de lucht wilde verwijderen, kon hij het doen of door het netwerk uit de lucht te verwijderen, of door de netwerken te nemen het met van de lucht, advertentieinfinitum verbindt. Er zijn velen, velen, manieren iemand kan dienst ontkennen, die zich van het complex aan de onbelangrijke bruut-kracht de uitstrekt. Als u gebruikend Internet voor de dienst nadenkt die absoluut kritieke tijd of opdracht is, zou u uw reservepositie moeten overwegen in het geval dat het netwerk beneden of beschadigd is. De de echodienst wordt van UDP van TCP/IP'S onbelangrijk misbruikt om twee servers ertoe te brengen om een netwerksegment met echopakketten te overstromen. U zou moeten becommentariërend uit ongebruikte ingangen in / enz./inetd.conf van de gastheren van Unix overwegen, die aan no ip small-servers routers Cisco toevoegen, of het equivalent voor uw componenten. 4.4 Wat zijn sommige gemeenschappelijke aanvallen, en hoe kan ik mijn systeem tegen hen beschermen? Elke plaats is een weinig verschillend van elke andere in termen van welke aanvallen waarschijnlijk tegen het zullen worden gebruikt. Sommige terugkomende thema's doen zich, niettemin voor. 4.4.1 Het Kapen van de Server SMTP (het Onbevoegde Aflossen) Dit is waar een spammer vele duizenden exemplaren van een bericht zal nemen en het naar een reusachtige lijst van e-mailadressen zal verzenden. Omdat deze lijsten, en vaak zo slecht zijn om de snelheid van verrichting voor spammer te verhogen, hebben velen zijn toevlucht genomen tot eenvoudig het verzenden van elk van hun post naar een server SMTP die zorg van eigenlijk het leveren van de post zal nemen. Natuurlijk, komen de elk van sprongen, spam klachten, haatpost, en slecht PR voor de plaats die als relais werd gebruikt. Er zijn zeer echte kosten verbonden aan dit, meestal in het betalen van mensen om schoon te maken knoei daarna. Systeem 1 Initiatief 2van de Preventievan het Misbruik van de Post van de Veiligheidvan het Vervoerhandhaaft een volledige omschrijving van het probleem, en hoe te over elke mailer op de planeet te vormen tegen deze aanval te beschermen. 4.4.2 Het exploiteren van Insecten in Toepassingen Diverse versies van Webservers, postservers, en andere de dienstsoftware van Internet bevatten insecten die toestaan de verre gebruikers (van Internet) om dingen te doen die zich van aanwinstencontrole van de machine aan het maken uitstrekken die toepassingsneerstorting en enkel over alles ertussen. De blootstelling aan dit risico kan worden verminderd door omhoog het leiden van slechts de noodzakelijke diensten, tot op heden op flarden te houden, en producten te gebruiken die rond een tijdje zijn geweest. 4.4.3 Insecten in Werkende Systemen Opnieuw, worden deze typisch ver in werking gesteld door gebruikers. De werkende systemen die aan IP voorzien van een netwerk vrij nieuw zijn neigen problematischer te zijn, zoals de rijpere werkende systemen tijd hebben gehad om hun insecten te vinden en te elimineren. Een aanvaller kan de doelapparatuur onophoudelijk vaak maken de capaciteit rebooten, verpletteren, verliezen om aan het netwerk te spreken, of dossiers op de machine te vervangen. Hier, kan het lopen als weinig werkend systeemdiensten zoals mogelijk helpen. Ook, kan het hebben van een pakketfilter voor het werkende systeem de blootstelling aan een groot aantal deze soorten aanvallen verminderen. En, natuurlijk, zal het chosing van een stabiel werkend systeem hier eveneens helpen. Wanneer het selecteren van OS, ben niet fooled in het geloven van dat `` meer pricier, betere ''. De vrije werkende systemen zijn vaak veel robuuster dan hun commerciële tegenhangers 5 Hoe ik... 5.1 Wil ik werkelijk toestaan alles die mijn gebruikers om vragen? Het is volledig mogelijk dat het antwoord `` geen ''. is Elke plaats heeft zijn eigen beleid over wat is en niet nodig is, maar het is belangrijk om te herinneren dat een groot deel van de baan van het zijn de portier van een organisatie onderwijs is. De gebruikers willen stromend video, in real time praatje, en de diensten aan externe klanten kunnen aanbieden die interactie met levende gegevensbestanden op het interne netwerk vereisen. Dat betekent dat geen van deze dingen kunnen worden gedaan zonder meer risico voor de organisatie neer voor te stellen dan de vermeende `` waarde '' van rubriek die de weg waard is. De meeste gebruikers willen niet hun organisatie op risico zetten. Zij lezen enkel de handelsvodden, zie reclame, en zij willen die dingen doen, ook. Het is belangrijk om in wat te kijken het dat zij werkelijk willen doen, en om hen te helpen begrijpen is hoe zij hun echte doelstelling op een veiligere manier zouden kunnen kunnen verwezenlijken. U zult niet altijd populair zijn, en u zou zelfs kunnen vinden gevend richting om ongelooflijk stom iets te doen, als `` stel enkel havensfoo door staaf ''. open Als dat gebeurt, me maak niet over het ongerust. Het zou wijs zijn om elk van uw uitwisselingen op een dergelijke gebeurtenis te houden zodat wanneer een de 12-jaar-oude manuscript kiddie onderbrekingen binnen, u minstens van het geheel zullen kunnen scheiden knoei. 5.2 Hoe maak ik Web/het werk van HTTP door mijn firewall? Er zijn drie manieren om het te doen. Sta `` uit gevestigde aanslutingen '' via een router toe, als u onderzoeksrouters gebruikt. Gebruik een Webcliënt die SOKKEN steunt, en stel SOKKEN op uw bastion gastheer in werking. Stel één of ander soort volmacht-geschikt Webserver op in werking de bastion gastheer. Sommige opties omvatten Pijlinktvis3, Apache4, Volmacht 5van Netscape, en HTTP-GW van TIS firewalltoolkit. De meesten hiervan kunnen ook volmacht andere protocollen (zoals gopher en FTP), en kunnen gehaalde voorwerpen in het voorgeheugen onderbrengen, die ook typisch in een prestatiesverhoging voor de gebruikers, en efficiënter gebruik van uw aansluting aan Internet zullen resulteren. Hoofdzakelijk alle Webcliënten (Mozilla, de Ontdekkingsreiziger van Internet, Lynx, enz.) heb de steun van de volmachtsserver die direct in hen wordt gebouwd. 5.3 Hoe maak ik SSL het werk door de firewall? Ssl is een protocol dat veilige aanslutingen over Internet toestaat. Typisch, wordt SSL gebruikt om het verkeer van HTTP te beschermen. Nochtans, kunnen andere protocollen (zoals Telnet) boven op SSL lopen. Het toelaten van SSL door uw firewall kan de zelfde manier worden gedaan dat u het verkeer van HTTP zou toestaan, als het HTTP is dat u SSL om gebruikt te beveiligen, wat gewoonlijk waar is. Het enige verschil is dat in plaats van het gebruiken van iets die eenvoudig HTTP zal aflossen, u iets nodig zult hebben die SSL kan een tunnel graven. Dit is een eigenschap huidig op de meeste Webobjecten geheime voorgeheugens. U kunt meer over SSL van Netscape 6te weten komen. 5.4 Hoe maak ik DNS het werk met een firewall? Sommige organisaties willen DNS namen van de buitenkant verbergen. Vele deskundigen denken niet DNS die namen verbergt lonend is, maar als de plaats/het collectieve beleid verbergende domeinnamen verplicht stellen, is dit één benadering die gekend om is te werken. Een andere reden u domeinnamen kunt moeten verbergen is als u een niet genormaliseerde het richten regeling op uw intern netwerk hebt. In dat geval, u geen keus dan hebt om die adressen te verbergen. Niet dwaas zelf in het denken dat als uw DNS namen verborgen zijn dat het een aanvaller onderaan veel zal vertragen als zij in uw firewall breken. De informatie over wat op uw netwerk is wordt te gemakkelijk verzameld van de voorzien van een netwerklaag zelf. Als u een interessante demonstratie van dit, ping het subnet uitzendingsadres op uw LAN wilt en dan een `` arp - ` a.' ' doet Merk ook op dat het verbergen van namen in DNS niet het probleem van gastheernamen `` uit lekkend '' in postheaders, nieuwsartikelen, enz. aanpakt. Deze benadering is één van velen, en is nuttig voor organisaties die wensen om hun gastheernamen van Internet te verbergen. Het succes van deze benadering ligt op het feit dat DNS de cliënten op een machine niet aan een DNS server op die zelfde machine moeten spreken. Met andere woorden, enkel omdat daar een DNS server op een machine, daar niets verkeerd met (en er zijn vaak voordelen) het opnieuw richten van DNS van die machine cliëntactiviteit aan een DNS server op een andere machine. Eerst, zet u een DNS server op de bastion gastheer op wie kan spreken de buitenwereld aan. U zet deze server op zodat het voor uw domeinen gebiedend eist te zijn. In feite, weet al deze server is wat u de buitenwereld wilt weten; de namen en de adressen van uw gateways, uw vervangingsmx verslagen, enzovoort. Dit is de server `` openbare ''. Dan, zet u een DNS server op een interne machine op. Deze server eist ook gebiedend voor uw domeinen te zijn; in tegenstelling tot de openbare server, dit vertelt men de waarheid. Dit is uw `` normale '' nameserver, waarin u al uw `` normaal '' DNS materiaal zet. U plaatst ook deze server tot voorwaartse vragen die het niet kan aan de openbare server die (een forwarders' `` ' lijn in/een enz./een named.boot op een machine van Unix gebruikt, bijvoorbeeld) oplossen. Tot slot zet u al uw DNS cliënten ( / enz./ resolv.conf- dossier op een vakje van Unix, bijvoorbeeld), met inbegrip van degenen op de machine met de openbare server op, om de interne server te gebruiken. Dit is de sleutel. Een interne cliënt die over een interne gastheer vraagt vraagt de interne server, en krijgt een antwoord; een interne cliënt die over een externe gastheer vraagt vraagt de interne server, die de openbare server vraagt, die Internet vraagt, en het antwoord wordt terug afgelost. Een cliënt op de openbare server werkt enkel de zelfde manier. Een externe cliënt die, echter, over een interne gastheer vraagt krijgt het `` beperkte antwoord '' van de openbare server terug. Deze benadering veronderstelt dat daar een pakket filtrerende firewall tussen deze twee servers die hen zullen toestaan om DNS aan elkaar te spreken, maar anders DNS tussen andere gastheren beperkt. Een andere truc die nuttig in deze regeling is om vervangingsPtr- verslagen in uw domeinen van ARPA aan te wenden in-ADDR.. Deze veroorzaken een adres-aan-naam raadpleging voor om het even welk van uw niet-openbare gastheren aan terugkeer iets als `` unknown.YOUR.DOMAIN '' eerder dan een fout. Dit stelt de anonieme plaatsen van FTP zoals ftp.uu.net tevreden die aandringen op het hebben van een naam voor de machines die zij hebben gesproken aan. Dit kan ontbreken wanneer het spreken aan plaatsen die een DNS kruiscontrole doen waarin de gastheernaam tegen zijn adres en vice versa wordt aangepast. 5.5 Hoe maak ik het werk van FTP door mijn firewall? Over het algemeen, wordt het maken van het werk van FTP door de firewall gedaan of gebruikend een volmachtsserver zoals firewalltoolkit's FTP-GW of door inkomende aanslutingen aan het netwerk bij een beperkte havenwaaier toe te laten, en anders inkomende aanslutingen te beperken gebruikend iets als `` vastgelegde '' onderzoeksregels. De cliënt van FTP wordt dan gewijzigd om de gegevenshaven aan een haven binnen dat gamma te binden. Dit brengt met zich mee kunnend de de cliënttoepassing van FTP op interne gastheren wijzigen. In sommige gevallen, als de downloads van FTP allen zijn wenst u te steunen, zou u kunnen willen nadenken verklarend FTP een `` dood protocol '' en latend u dient de gebruikersdownload in plaats daarvan via het Web in. Het gebruikersinterface zeker is aardiger, en het krijgt rond het lelijke callback havenprobleem. Als u de fTP-via-Web benadering kiest, zullen uw gebruikers aan FTP- dossiers uit onbekwaam zijn, die, afhankelijk van wat u probeert om te verwezenlijken, een probleem kunnen zijn. Een verschillende benadering is de optie PASV '' te gebruiken van FTP `` om erop te wijzen dat de verre server van FTP de cliënt zou moeten toelaten om aanslutingen in werking te stellen. De benadering PASV veronderstelt dat de server van FTP op de verre systeemsteunen die verrichting. (Zie `` firewall-Vriendschappelijk FTP '' [1].) Andere plaatsen verkiezen cliëntversies van het FTP- programma te bouwen die tegen een bibliotheek van SOKKEN verbonden zijn. 5.6 Hoe maak ik het werk van Telnet door mijn firewall? Telnet wordt over het algemeen gesteund of door een toepassingsvolmacht zoals firewalltoolkit's tn-GW te gebruiken, of door een router eenvoudig te vormen om uitgaande aanslutingen toe te laten gebruikend iets als de `` vastgelegde '' onderzoeksregels. Volmachten van de toepassing zouden in de vorm van een standalone volmacht die op de bastion gastheer loopt, of in de vorm van een server van SOKKEN en een gewijzigde cliënt kunnen zijn. 5.7 Hoe maak ik Vinger en whois door mijn firewall werken? Vele firewall admins laat aanslutingen aan de vingerhaven van toe slechts vertrouwde op machines, die vingerverzoeken in de vorm van kunnen uitgeven: vinger user@host.domain@firewall. Deze benadering werkt slechts met de standaardversie van Unix van vinger. De controlerende toegang tot de diensten en het beperken van hen tot specifieke machines wordt beheerd gebruikend of tcp_wrappers of netacl van firewalltoolkit. Deze benadering zal niet werken aan alle systemen, aangezien sommige vingerservers user@host@host geen vingertechniek toelaten. Vele plaatsen blokkeren binnenkomende vingerverzoeken om een verscheidenheid van redenen, het belangrijkste zijn afgelopen veiligheidsinsecten in de vingerserver (de worm van Morris maakte Internet deze insecten beroemd) en het risico van merkgebonden of gevoelige informatie die in de vingerinformatie van de gebruiker wordt geopenbaard. In het algemeen, echter, als uw gebruikers gebruikelijk zijn aan het zetten van merkgebonden of gevoelige informatie in hun plan dossiers, hebt u een ernstiger veiligheidsprobleem dan enkel een firewall kan oplossen. 5.8 Hoe maak ik gopher, Archie, en werken andere diensten door mijn firewall? De meerderheid van firewallbeheerders verkiest om gopher en Archie door Webvolmachten, in plaats van direct te steunen. De volmachten zoals firewalltoolkit's HTTP-GW zetten gopher/gopher + vragen in HTML om en vice versa. Voor het steunen van Archie en andere vragen, baseren vele plaatsen zich op op Internet-Gebaseerde servers Web-aan-Archie, zoals ArchiePlex. De tendens van het Web om alles op Internet te maken als de Webdienst kijken is zowel een zegen als een vloek. Er zijn vele nieuwe diensten die constant opduiken. Vaak zijn zij misdesigned of niet worden ontworpen met veiligheid in mening, en hun ontwerpers zullen u vertellen cheerfully of wilt u hen gebruiken u moet haven xxx door uw router laten. Jammer genoeg, niet kan iedereen dat doen, en zodat is een aantal interesserend nieuw speelgoed moeilijk om voor mensen achter firewalls te gebruiken. De dingen zoals RealAudio, die directe toegang UDP vereisen, zijn in het bijzonder ongehoorde voorbeelden. Het in gedachten te houden ding als u zich met één van deze problemen geconfronteerd vindt moet zo veel te weten komen aangezien u over de veiligheidsrisico's kunt die de dienst kan voorstellen, alvorens u het enkel door toestaat. Het is vrij mogelijk de dienst heeft geen veiligheidsimplicaties. Het is even mogelijk dat het onontdekte gaten heeft u kon drijven een vrachtwagen door. 5.9 Wat zijn de kwesties over X11 door een firewall? Het Systeem van de Vensters van X is een zeer nuttig systeem, maar jammer genoeg heeft sommige belangrijke veiligheidsgebreken. De verre systemen die kunnen bereiken of spoof toegang tot de vertoning van een werkstation X11 kunnen aanslagen controleren die een gebruiker, downloadexemplaren van de inhoud van hun vensters, enz. ingaat. Terwijl de pogingen zijn gemaakt om hen te overwinnen (B.v., is `` Magisch Koekje MIT '') het nog volledig te gemakkelijk voor een aanvaller om zich in de vertoning van een gebruiker te mengen X11. De meeste firewalls blokkeren al X11 verkeer. Sommigen laten X11 verkeer door toepassingsvolmachten zoals toe de volmacht van Dec CRL X11 (FTP crl.dec.com). Firewalltoolkit omvat een volmacht voor X11, genoemd x-GW, dat een gebruiker via de volmacht van Telnet kan aanhalen, om tot een virtuele X11 server op de firewall te leiden. Wanneer de verzoeken voor een X11 aansluting op de virtuele X11 server worden ingediend, wordt de gebruiker voorgesteld met pop-up vragend hen als het O.K. is om de aansluting toe te staan. Terwijl dit een weinig unaesthetic is, is het volledig in overeenstemming met de rest van X11. 5.10 Hoe maak ik RealAudio door mijn firewall werken? RealNetworks handhaaft wat informatie over hoe te om RealAudio werkend door uw firewall 7te krijgen. Het zou onverstandig zijn om om het even welke veranderingen in uw firewall aan te brengen zonder te begrijpen wat de veranderingen, precies zullen doen, en wetend welke risico's de nieuwe veranderingen met hen zullen brengen. 5.11 Hoe maak ik mijn Webserver als voorkant voor een dienst doen gegevensbestand dat op mijn privé netwerk leeft? De beste manier om dit te doen is zeer beperkte connectiviteit tussen uw Webserver en uw gegevensbestandserver via een specifiek protocol toe te staan dat slechts het niveau van functionaliteit steunt u gaat gebruiken. Het toestaan van ruwe SQL, of iets anders waar de douaneextracties door een aanvaller zouden kunnen worden uitgevoerd is over het algemeen geen goed idee. Veronderstel dat een aanvaller in uw Webserver gaat kunnen breken, en vragen op de zelfde manier maken dat de Webserver kan. Is er een mechanisme om gevoelige te halen informatie geen die de Webserver, als creditcardinformatie vergt? Kan een aanvaller uitgezocht SQL uw volledig merkgebonden gegevensbestand halen uitgeven en? `` de toepassingen van de elektronische handel '', als al het andere, worden het best ontworpen met omhoog veiligheid in mening van de grond, in plaats van het hebben van veiligheid `` toegevoegde '' bij nadere overweging. Herzie uw architectuur kritisch, vanuit het perspectief van een aanvaller. Veronderstel dat de aanvaller alles over uw architectuur kent. Me nu vraag wat moet worden gedaan uw gegevens stelen, onbevoegde veranderingen aanbrengen, of iets anders doen geen die u gedaan wilt. U zou kunnen vinden dat u veiligheid zonder dalende functionaliteit kunt beduidend verhogen door een paar ontwerp en implementatiebesluiten te nemen. Sommige ideeën voor hoe te om dit te behandelen: Haal de gegevens u van het gegevensbestand op een regelmatige basis nodig hebt zodat maakt u geen vragen tegen het volledige gegevensbestand, volledig met informatie die de aanvallers interessant zullen vinden. Beperk zeer en controleer wat u tussen de Webserver en het gegevensbestand toestaat. 5.12 Maar mijn gegevensbestand heeft een geïntegreerde Webserver, en ik wil dat gebruiken. Kan ik niet een gat in de firewall en de tunnel die haven enkel porren? Als uw plaatsbrandwall policy is sufficiently lax het muur beleid is voldoende los dat u bereid bent om het risico dat te beheren iemand een kwetsbaarheid in uw Webserver die in gedeeltelijke of volledige blootstelling van uw gegevensbestand zal resulteren, dan verhindert u niet daar veel dit te doen zal exploiteren. Nochtans, in vele organisaties, hebben de mensen die voor eenvoudig het binden van het Web vooreind aan de gegevensbestand naherfst verantwoordelijk zijn niet het gezag om die verantwoordelijkheid te nemen. Verder, als de informatie in het gegevensbestand over mensen is, zou u schuldig kunnen vinden van het breken van een aantal wetten als u geen redelijke voorzorgsmaatregelen hebt genomen om het systeem worden misbruikt te verhinderen. In het algemeen, is dit geen goed idee. Zie vraag 5,11 voor sommige ideeën op andere manieren om deze doelstelling te verwezenlijken. 5.13 Hoe maak ik tot IP Multicast Werk met Mijn Firewall? Multicast IP is een middel om IP verkeer van één gastheer aan een reeks gastheren te krijgen zonder het uitzenden te gebruiken; namelijk in plaats van elke gastheer die het verkeer krijgt, slechts zullen die die willen het het krijgen, zonder elk die een afzonderlijke aansluting aan de server moet handhaven. Ip unicast is waar de één gastheerbesprekingen aan multicast andere, is waar één gastheer aan een reeks gastheren spreekt, en de uitzending is waar één gastheer aan alle gastheren spreekt. Openbaar Internet heeft een multicast backbone (``MBone '') waar de gebruikers in multicast verkeersuitwisseling kunnen in dienst nemen. Het gemeenschappelijke gebruik voor MBone is stromen van vergaderingen IETF en gelijkaardig dergelijke interactie. Het krijgen van zijn eigen netwerk zal dat met MBone wordt verbonden vereisen dat het stroomopwaartse multicast verkeer van de leveranciersroute aan en van uw netwerk. Bovendien, zal uw intern netwerk het multicast leiden moeten steunen. De rol van de firewall in het multicast leiden, conceptueel, is geen verschillend van zijn rol in andere verkeer het leiden. Namelijk moet een beleid dat zich identificeert wat multicast groepen zijn en aren't toegestaan worden bepaald en toen een systeem om toe te staan dat het verkeer volgens beleid moet worden bedacht. Het grote detail op hoe precies om dit te doen is voorbij het toepassingsgebied van dit document. Gelukkig, RFC 2588.4 ] bespreekt het onderwerp meer in detail. Tenzij uw firewallproduct sommige middelen van het selectieve multicast door:sturen steunt of u de capaciteit hebt om het aan te brengen zelf, zou u het door:sturen van multicast verkeer op een manier kunnen vinden verenigbaar met uw veiligheidsbeleid om een grotere hoofdpijn te zijn dan het de moeite waard is. Back to Top Firewall FAQ in Nederlands Deel 4 6 Havens TCP en UDP door Mikael Olsson Dit bijlage zal op vrij niveau `` basis'' beginnen, zodat zelfs als de eerste punten aan u childishly duidelijk schijnen, zou u iets van het overslaan vooruit aan iets later in de tekst nog kunnen leren. 6.1 Wat is een haven? Een `` haven '' is `` virtuele groef '' in uw stapel TCP en UDP die wordt gebruikt om een aansluting tussen twee gastheren, en ook tussen de laag TCP/UDP en de daadwerkelijke toepassingen in kaart te brengen die op de gastheren lopen. _ zij nummeren 0-65535, met de waaier 0-1023 merken als `` reserveren '' of `` privlileged '', en de rest (1024-65535) als `` dynamisch '' of `` onbevoorrecht ''. Er is fundamenteel twee gebruik voor havens: `` het luisteren '' op een haven. Dit wordt door servertoepassingen gebruikt die op gebruikers wachten te verbinden, om aan wat `` bekend de dienst'', bijvoorbeeld HTTP (haven 80 van TCP) te worden, Telnet (haven van TCP 23), DNS (UDP en soms haven van TCP 53). Het openen van een haven `` dynamische ''. Beide kanten van een aansluting van TCP moeten door IP adressen en havenaantallen worden geïdentificeerd. Vandaar, wanneer u aan `` wilt verbind '' met een serverproces, vergt uw eind van het communicatiekanaal ook een `` haven ''. Dit wordt gedaan door een haven boven 1024 op uw machine te kiezen die niet momenteel in gebruik door een ander communicatiekanaal en, is het te gebruiken als `` afzender '' in de nieuwe aansluting. De dynamische havens kunnen ook als het luisteren `` '' havens in sommige toepassingen worden gebruikt, het meest in het bijzonder FTP. De havens in waaier 0-1023 zijn bijna altijd serverhavens. De havens in waaier 1024-65535 zijn gewoonlijk dynamische havens (d.w.z., opende dynamisch wanneer u met een serverhaven verbindt). Nochtans, kan om het even welke haven als serverhaven worden gebruikt, en om het even welke haven kan als haven `` uitgaande '' worden gebruikt. Zo, om het op te sommen, hier wat in een basisaansluting gebeurt: Op wat punt op tijd, beslist een servertoepassing op gastheer 1.2.3.4 aan `` '' bij haven 80 (HTTP) voor nieuwe aanslutingen luister. U (5.6.7.8) wilt aan 1.2.3.4, haven 80 surfen, en uw browser geeft uit verbindt vraag met het. Verbind vraag realiseert, die dat het nog niet lokaal havenaantal, gaat jagend voor heeft. Het lokale havenaantal is noodzakelijk sindsdien wanneer de antwoorden wat tijd in de toekomst terugkomen, zal uw stapel van TCP/IP aan welke toepassing moeten kennen om het antwoord over te gaan. Het doet dit door te herinneren welk toepassingsgebruik dat lokaal havenaantal. (Dit wordt in grote trekken vereenvoudigd, geen vlammen van programmeurs, tevreden.) Uw stapel van TCP vindt een ongebruikte dynamische haven, gewoonlijk ergens boven 1024, veronderstel dat het 1029 vindt. Uw eerste pakket wordt dan verzonden, van uw lokale IP, 5.6.7.8, haven 1029, naar 1.2.3.4, haven 80. De server antwoordt met een pakket van 1.2.3.4, haven 80, aan u, 5.6.7.8, haven 1029. Deze procedure is eigenlijk langer dan dit, verder gelezen voor een meer diepgaande verklaring van TCP opeenvolgingen verbindt. 6.2 Hoe weet ik welke toepassing gebruikt welke haven? Er zijn verscheidene lijsten schetsend de `` gereserveerde havens '' en `` bekende '', evenals havens `` algemeen gebruikte '', en beste is: ftp://ftp.isi.edu/in-notes/iana/assi...port-aantallen. Voor die van u die nog RFC 1700 lezen om te weten te komen welk havenaantal doet wat, OPHOUD DOEND IT. Het is afschuwelijk verouderd, en het zal niet minder zo morgen zijn. Nu, zoals voor het vertrouwen van op deze informatie: Deze lijsten, in geen geval, vormen om het even welk soort heilige bijbel waarop de havens doen wat. Wacht, laat me herformuleren dat: ER IS GEEN MANIER OM BETROUWBAAR TE BEPALEN WELKE HAVEN DOET WAT EENVOUDIG DOOR IN een LIJST TE KIJKEN. 6.3 Wat zijn het LUISTEREN havens? Veronderstel u `` netstat - ` een '' op uw machine deed en havens 1025 en 1030 als LISTENing verschenen. Wat doen zij? Het recht, nemen een blik in de toegewezen lijst van havenaantallen. blackjack 1025/tcp netwerk blackjack iad1 1030/tcp BBN IAD Wacht, wat gebeurt? Heeft mijn werkstation mijn aantal van het VISUM gestolen en spel blackjack met één of andere schurkenserver op Internet beslist te gaan? En wat is die software die BBN heeft geïnstalleerd? Dit is NIET waar u begint panicking en post naar de firewallslijst verzendt. In feite, is deze vraag gesteld misschien een dozijn keer tijdens de afgelopen zes maanden, en telkens als het wordt beantwoord. Niet dat DIE levensonderhoudmensen van het vragen van het zelfde opnieuw vragen. Als u deze vraag stelt, bent u waarschijnlijkst gebruikend een venstersdoos. De havens u zien zijn (het waarschijnlijkst) twee het luisteren havens die het subsysteem RPC opent wanneer het begint. Dit is een voorbeeld van waar de dynamicly toegewezen havens door serverprocessen kunnen worden gebruikt. De toepassingen die RPC gebruiken zullen later met haven 135 verbinden (netbios `` portmapper '') aan vraag waar te om wat dienst te vinden RPC, en een antwoord achter te krijgen zeggend dat die bepaalde dienst op haven 1025 kan worden gecontacteerd. Nu, hoe kennen wij dit, sinds daar geen ``- lijst '' beschrijvend deze havens? Eenvoudig: Daar geen substituut voor ervaring. En het gebruiken van de motoren van het adressenlijstonderzoek helpt een ook een hel van. 6.4 Hoe bepaal ik welke dienst de haven voor is? Aangezien het doen onmogelijk is om te leren welke haven doet wat door in een lijst, hoe te kijken ik het? De oude hands-on manier om te doen het is door het sluiten van bijna elke dienst/daemon het lopen op uw machine, netstat -a nota te doen en te nemen van welke havens open is. Er zou niet zeer vele luisterdegenen moeten zijn. Dan begint u alle diensten aan te zetten, één voor één, en nota van wat nieuwe havens tonen omhoog in uw netstatoutput neem. Een andere manier, die meer gissingswerk vergt, telnetting eenvoudig aan de havens en ziet wat uit komt. Als niets uit komt, probeer typend wat brabbeltaal en dichtslaand ga een paar keer in, en zie of verschijnt iets. Als u binair wordt vermink, of niets helemaal niet, dit zal u duidelijk helpen. Nochtans, zal dit u vertellen slechts welke het luisteren havens worden gebruikt. Het zal niet u over dynamisch geopende havens vertellen die later door deze toepassingen kunnen worden geopend. Er zijn een paar toepassingen die u zouden kunnen helpen de gebruikte havens opsporen. Voor de systemen van Unix, daar preinstalled een aardig geroepen lsof nut dat komt op vele systemen. Het zal u alle open havenaantallen en namen van de toepassingen tonen die hen gebruiken. Dit betekent dat het u heel wat plaatselijk geopende dossiers zou kunnen tonen aswell als contactdozen van TCP/IP. Lees de hulptekst. Voor vensterssystemen, niets preinstalled komt om u in deze taak bij te staan. (Nieuw) Daar riep een nut `` Inzider '' die zich binnen de laag van vensterscontactdozen installeert en dynamisch herinnert welk proces opent welke haven. Het nadeel van deze benadering is dat het u niet kan vertellen welke havens vóór begonnen inzider werden geopend, maar het is het beste dat u op vensters (aan mijn kennis) zult krijgen. http://ntsecurity.nu/toolbox/inzider/. 6.5 Welke havens zijn veilig om door een firewall over te gaan? ALLEN. Nr, wacht, NIETS. Nr, wacht, uuhhh... Ik heb gehoord dat alle havens boven 1024 veilig zijn aangezien zij slechts dynamische?? zijn Nr. werkelijk. U KUNT vertellen niet welke havens eenvoudig door zijn aantal te bekijken veilig zijn, eenvoudig omdat dat werkelijk allen is is het. Een aantal. U kunt een aanval door een aantal met 16 bits opzetten niet. De veiligheid van een `` haven '' hangt van welke toepassing af u door die haven zult bereiken. Een gemeenschappelijke misvatting is dat havens 25 (SMTP) en 80 (HTTP) veilig om door een VERKEERDE firewall zijn over te gaan * meep *. Enkel omdat iedereen is doend betekent het niet dat het veilig is. Opnieuw, hangt de veiligheid van een haven van welke toepassing af u door die haven zult bereiken. Als u een well-written Webserver in werking stelt, wordt dat ontworpen van de grond tot veilig is, kunt u waarschijnlijk redelijk verzekerd voelen dat het veilig is om buitenmensentoegang het door haven 80 te laten. Anders, KUNT u niet. Het probleem is niet hier in de netwerklaag. Het is in hoe de toepassing de gegevens verwerkt die het ontvangt. Dit gegeven kan door haven 80, haven 666, een periodieke lijn, floppy of door zingend telegram worden ontvangen. Als de toepassing niet veilig is, is het niet van belang hoe de gegevens aan het krijgen. De toepassingsgegevens zijn waar het echte gevaar ligt. Als u in de veiligheid van uw toepassing geinteresseerd bent, ga intekenen aan bugtraq8of of proberen zoekend hun archieven. Dit is meer van een kwestie van de toepassingsveiligheid eerder dan een kwestie van de firewallveiligheid. Men kon debatteren dat een firewall alle mogelijke aanvallen, maar met het aantal nieuwe netwerkprotocollen, NIET zou moeten tegenhouden dat met veiligheid in mening wordt ontworpen, en de genetwerkte toepassingen, die ook niet met veiligheid in mening worden ontworpen, het voor een firewall om tegen alle gegeven-gedreven aanvallen onmogelijk wordt te beschermen. 6.6 Het gedrag van FTP Of, `` waarom ik alle havens boven 1024 voor mijn server van FTP moet openen?' ' FTP werkelijk kijkt geen gehele partij zoals andere toepassingen vanuit een voorzien van een netwerkperspectief. Het houdt één het luisteren haven, haven 21, de gebruikers waarmet verbinden. Allen het doet is gelaten mensen inlogt, en vestigt EEN ANDERE aansluting om daadwerkelijke gegevensoverdrachten te doen. Deze tweede aansluting is gewoonlijk op één of andere haven boven 1024. Er zijn twee wijzen, wijze `` actieve (normale) '' en `` passieve ''. Dit woord beschrijft het gedrag van de server. Op actieve wijze, verbindt de cliënt (5.6.7.8) met haven 21 op de server (1.2.3.4) en opent het programma. Wanneer de dossieroverdrachten gepast zijn, wijst de cliënt een dynamische haven boven 1024 toe, informeert de server over welke haven het opende, en dan opent de server een nieuwe aansluting voor die haven. Dit is de rol `` actieve '' van de server: het vestigt actief nieuwe aanslutingen aan de cliënt. Op passieve wijze, is de aansluting aan haven 21 het zelfde. Wanneer de dossieroverdrachten gepast zijn, wijst de SERVER een dynamische haven boven 1024 toe, informeert de cliënt over welke haven het opende, en dan opent de CLIËNT een nieuwe aansluting voor die haven. Dit is de rol `` passieve '' van de server: het wacht op de cliënt om de tweede (gegevens) aansluting te vestigen. Als uw firewall niet de toepassingsgegevens van de het bevelaansluting van FTP inspecteert, zal het weten niet dat het nieuwe havens boven 1024 moet dynamisch openen. Op een zijnota: Het traditionele gedrag van de servers van FTP op actieve wijze moet de gegevenszitting VAN haven 20, en aan de dynamische haven op de cliënt vestigen. De servers van FTP sturen vanaf dit gedrag enigszins wegens de behoefte als `` wortel '' op Unixsystemen lopen havens onder 1024, kunnen toewijzen Lopend aangezien `` de wortel '' niet goed voor veiligheid is, sinds als daar een insect in de software, de aanvaller de volledige machine zou kunnen compromitteren. Het zelfde gaat voor het lopen als `` Beheerder '' of `` SYSTEEM '' (``LocalSystem '') op machines NT, hoewel het lage havenprobleem niet op NT van toepassing is. Om het op te sommen, als uw firewall FTP begrijpt, zal het de gegevensaanslutingen alleen kunnen behandelen, en u zult niet zich over havens boven 1024 moeten ongerust maken. Als het NIET, zijn er vier kwesties die u moet behandelen: Firewalling een server van FTP op actieve wijze U moet uw server open nieuwe aanslutingen aan de buitenwereld op havens 1024 laten en hierboven Firewalling een server van FTP op passieve wijze U moet de buitenwereld laten aan havens 1024 en hierboven op uw server verbinden. VOORZICHTIGHEID!!!! kunnen Er toepassingen zijn die op sommige van deze havens lopen dat u het buitenmensen gebruiken niet wilt. Verbied toegang tot deze havens alvorens toegang tot de 1024-65535 havenwaaier te verlenen. De cliënten van FTP van Firewalling op actieve wijze U moet de buitenwereld laten aan havens 1024 en hierboven op uw cliënten verbinden. VOORZICHTIGHEID!!!! kunnen Er toepassingen zijn die op sommige van deze havens lopen dat u het buitenmensen gebruiken niet wilt. Verbied toegang tot deze havens alvorens toegang tot de 1024-65535 havenwaaier te verlenen. De cliënten van FTP van Firewalling op passieve wijze U moet uw cliënten open nieuwe aanslutingen aan de buitenwereld op havens 1024 laten en hierboven. Opnieuw, als uw firewall FTP begrijpt, is geen van de vier punten hierboven op u van toepassing. Laat de firewall het werk voor u doen. 6.7 Welke software gebruikt welke wijze van FTP? Het is aan de cliënt te beslissen welke wijze aan gebruik; de default- wijze wanneer een nieuwe aansluting wordt geopend is `` actieve wijze ''. De meeste cliënten van FTP komen preconfigured om actieve wijze te gebruiken, maar verstrekken een optie om `` passieve '' te gebruiken (wijze ``PASV ''). Een uitzondering is de cliënt van de lijncFtp van het venstersbevel wat slechts op actieve wijze werkt. Browsers van het Web gebruiken over het algemeen passieve wijze wanneer het verbinden via FTP, aan een bizarre uitzondering: MSIE 5 zal actief FTP wanneer FTP:ing op de wijze van de Ontdekkingsreiziger '' van het ``- Dossier en passief FTP wanneer FTP:ing in ``- de wijze van de Web-pagina '' gebruiken. Er is geen reden van om het even welke aard voor dit gedrag; mijn gissing is dat iemand in Redmond zonder kennis van FTP dat `` besliste wij natuurlijk actieve wijze wanneer wij op de wijze van de dossierontdekkingsreiziger zijn, sinds die blikken actiever dan een Web-pagina ''. zullen gebruiken Ga cijfer. 6.8 Probeert mijn firewall buiten te verbinden? Mijn firewalllogboeken vertellen me dat mijn Webserver om van haven 80 met havens boven 1024 op de buitenkant probeert te verbinden. Wat dit? is! Als u gelaten vallen pakketten aan haven 80 op uw Webserver (of van haven 25 op uw postserver) aan hoge havens op de buitenkant merkt, betekenen zij gewoonlijk niet dat uw Webserver probeert ergens te verbinden. Zij zijn het resultaat uit van de firewalltiming een aansluting, en het zien van de server opnieuw overbrengend oude reacties (of proberend om de aansluting te sluiten) op de cliënt. De aanslutingen van TCP impliceren altijd pakketten die in BEIDE richtingen in de aansluting reizen. Als u de vlaggen van TCP in de gelaten vallen pakketten kunt zien, zult u dat de ACK vlag maar niet de vlag wordt geplaatst SYN zien, bedoelend dat dit echt een nieuwe aansluting, maar eerder geen reactie die van een eerder gevormde aansluting is vormen zich. Lees punt 8 hieronder voor een diepgaande verklaring van wat gebeurt wanneer de aanslutingen van TCP worden gevormd (en gesloten) 6.9 De anatomie van een aansluting van TCP TCP is uitgerust met 6 vlaggen `` ', die of WEG kunnen zijn. Deze vlaggen zijn: VIN `` gecontroleerde aansluting '' dicht SYN Open nieuwe aansluting RST `` directe dichte aansluting '' PSH Draag ontvangersgastheer op om de gegevens tot de toepassing te duwen eerder dan om het enkel een rij te vormen Ack `` erken '' een vorig pakket URG `` dringend ''- gegeven dat moet onmiddellijk worden verwerkt In dit voorbeeld, is uw cliënt 5.6.7.8, en de haven die aan u wordt toegewezen dynamisch is 1049. De server is 1.2.3.4, haven 80. U begint met de aansluting poging: 5.6.7.8:1049 -> 1.2.3.4:80 SYN=ON De server ontvangt dit pakket en begrijpt dat iemand een nieuwe aansluting wil vormen. Een reactie wordt verzonden: 1.2.3.4:80 -> 5.6.7.8:1049 SYN=ON ACK=ON De cliënt ontvangt de reactie, en informeert dat de reactie wordt ontvangen 5.6.7.8:1049 -> 1.2.3.4:80 ACK=ON Hier, wordt de aansluting geopend. Dit wordt genoemd een handdruk met drie richtingen. Zijn doel is te verifiëren aan BEIDE gastheren dat zij een het werk aansluting tussen hen hebben. Wat het is is, onbetrouwbaar en overstroomd Internet dat, zijn er bepalingen om pakketverlies te compenseren. Als de cliënt aanvankelijke SYN stuurt zonder een SYN+ACK binnen een paar seconden te ontvangen, zal het SYN opnieuw versturen. Als de server SYN+ACK stuurt zonder ACK in een paar seconden te ontvangen, zal het het pakket SYN+ACK opnieuw versturen. De laatstgenoemde is eigenlijk de reden dat de overstroming SYN zo goed werkt. Als u pakketten SYN van veel verschillende havens stuurt, zal dit heel wat middelen op de server blokkeren. Als u ook om aan de teruggekeerde pakketten weigert te antwoorden SYN+ACK, zal de server deze aanslutingen voor een lange tijd HOUDEN, opnieuw versturend de pakketten SYN+ACK. Sommige servers zullen geen nieuwe aanslutingen goedkeuren terwijl er genoeg aanslutingen die zich zijn momenteel vormen; dit is waarom de overstroming SYN werkt. Alle pakketten die in één van beide richting na de handdruk worden overgebracht zullen met drie richtingen de ACK geplaatste bit hebben. De statenloze pakketfilters maken gebruik van dit in de zogenaamde `` gevestigde filters '': Zij zullen slechts pakketten door dat de ACK geplaatste bit laten hebben. Deze manier, geen pakket kan door in een bepaalde richting overgaan die een nieuwe aansluting kon vormen. Typisch, staat u geen buitengastheren toe om nieuwe aanslutingen voor binnengastheren te openen door de ACK bit te vereisen die op deze pakketten wordt geplaatst. Wanneer de tijd is gekomen om de aansluting te sluiten, zijn er twee manieren om het te doen: Het gebruiken van de vlag van de VIN, of het gebruiken van de vlag RST. Gebruikend de vlaggen van de VIN, worden beide implementaties vereist om de vlaggen van de VIN te sturen om erop te wijzen dat zij de aansluting willen sluiten, en dan erkenning te sturen die aan deze FINs erop wijzen, dat zij begrepen dat het andere eind de aansluting wil sluiten. Wanneer het sturen van RST'S, is de aansluting krachtig gesloten, en u wordt werkelijk geen aanwijzing van of het andere eind uw het terugstellenorde begreep, of dat het in feite alle gegevens heeft ontvangen die u naar het verzond. De manier van de VIN om de aansluting te sluiten stelt u ook aan een de ontkenning-van-dienst situatie bloot, aangezien de stapel van TCP de gesloten aansluting voor een vrij lange tijd moet herinneren, voor het geval dat het andere eind geen één van de pakketten van de VIN heeft ontvangen. Als voldoende vele aanslutingen worden geopend en gesloten, kunt u het hebben van `` gesloten aanslutingen '' in al uw aansluting groeven omhoog beëindigen. Deze manier, zou u niet meer aanslutingen kunnen dynamisch toewijzen, ziend dat zij allen worden gebruikt. Verschillende OSes behandelen verschillend deze situatie. A. Sommige Commerciële Producten en Verkopers Wij vinden dit onderwerp voor adres in een FAQ, echter te gevoelig is, een onafhankelijk gehandhaafde lijst (geen garantie of aanbevelingen zijn impliciet) kan online worden gevonden.9 B. Verklarende woordenlijst van firewall-Verwante Termijnen Misbruik van Voorrecht Wanneer een gebruiker een werking uitvoert geen die zij zouden moeten hebben, volgens organisatorische beleid of wet. De Lijsten van het Toegangsbeheer Regels voor pakketfilters (typisch routers) die bepalen wat pakketten overgaan en die om te blokkeren. De Router van de toegang Een router die uw netwerk met extern Internet verbindt. Typisch, is dit uw eerste lijn van defensie tegen aanvallers van buitenInternet. Door toegangsbeheerlijsten op deze router toe te laten, zult u een mate van bescherming voor de elk van gastheren `` achter '' kunnen verstrekken die router, effectief makend tot dat netwerk een DMZ in plaats van onbeschermde externe LAN. Toepassing-laag Firewall Een firewallsysteem waarin de dienst door processen wordt verleend die het volledige de aansluting van TCP staat en rangschikken handhaven. De de laagfirewalls van de toepassing sturen vaak verkeer door zodat het uitgaande verkeer om uit de firewall, eerder dan de interne gastheer schijnt voortgekomen te zijn. Authentificatie Het proces om de identiteit van een gebruiker te bepalen die probeert om tot een systeem toegang te hebben. Het Teken van de authentificatie Een draagbaar apparaat dat voor het voor authentiek verklaren van een gebruiker wordt gebruikt. De tekenen van de authentificatie werken door uitdaging/reactie, op tijd-gebaseerde codeopeenvolgingen, of andere technieken. Dit kan lijsten op papier van éénmalige wachtwoorden omvatten. Vergunning Het proces om te bepalen welke soorten activiteiten worden toegelaten. Gewoonlijk, is de vergunning in de context van authentificatie: zodra u een gebruiker voor authentiek hebt verklaard, kunnen zij gemachtigde verschillende soorten toegang of activiteit zijn. Bastion Gastheer Een systeem dat vaste vorm is gegeven om zich tegen aanval te verzetten, en dat op een netwerk geïnstalleerd is zodanig dat het potentieel onder aanval zou moeten komen. Bastion de gastheren zijn vaak componenten van firewalls, of kunnen `` buiten '' Webservers of openbare toegangssystemen zijn. Over het algemeen, stelt een bastion gastheer één of andere vorm van algemeen doel werkend systeem (in werking b.v., Unix, VMS, NT, enz.) eerder dan een op ROM-Gebaseerd of ingebouwde programmatuur werkend systeem. Uitdaging/Reactie Een authentificatietechniek waardoor een server een onvoorspelbare uitdaging aan de gebruiker verzendt, die een reactie gebruikend één of andere vorm van authentificatieteken gegevens verwerkt. Chroot Een techniek onder Unix waardoor een proces tot een geïsoleerde ondergroep van filesystem permanent beperkt is. Cryptografische Controlesom Een unidirectionele functie was op een dossier van toepassing om een unieke `` vingerafdruk '' van het dossier voor recentere verwijzing te produceren. De systemen van de controlesom zijn een primair middel om filesystem het knoeien op Unix te ontdekken. Gegevens Gedreven Aanval Een vorm van aanval waarin de aanval in onschadelijk-schijnt gegeven wordt gecodeerd dat door een gebruiker of andere software wordt uitgevoerd om een aanval uit te voeren. In het geval van firewalls, is een gegevens gedreven aanval een zorg aangezien het door de firewall in gegevensvorm kan krijgen en een aanval lanceren tegen een systeem achter de firewall. Diepgaand defensie De veiligheidsbenadering waardoor elk systeem op het netwerk aan de grootste mogelijke graad wordt beveiligd. Mag samen met firewalls worden gebruikt. Dns voor de gek houden Veronderstellend de DNS naam van een ander systeem door of het geheime voorgeheugen van de naamdienst van een slachtoffersysteem te bederven, of door een server van de domeinnaam voor een geldig domein te compromitteren. Dubbele Automatisch begesturde Gateway Een dubbele automatisch begesturde gateway is een systeem dat twee of meer netwerkinterfaces heeft, elk waarvan met een verschillend netwerk wordt verbonden. In firewallconfiguraties, handelt een dubbele automatisch begesturde gateway gewoonlijk om of wat of het elk van verkeer te blokkeren te filtreren dat tussen de netwerken probeert over te gaan. Coderende Router zie Een tunnel gravende Router en de Virtuele Perimeter van het Netwerk. Firewall Een systeem of een combinatie systemen dat een grens tussen twee of meer netwerken afdwingen. Op gastheer-gebaseerde Veiligheid De techniek om een individueel systeem van aanval te beveiligen. Is de gastheer gebaseerde veiligheid werkend afhankelijk systeem en versie. De Aanval van de insider Een aanval die van binnenuit een beschermd netwerk voortkomt. De Opsporing van het binnendringen De opsporing van inbraken of inbraak probeert of manueel of via software expert-systemen die op beschikbare logboeken of andere informatie over het netwerk werken. Ip Voor de gek houden Een aanval waardoor een systeem impersonate onwettig een ander systeem door zijn IP netwerkadres te gebruiken probeert. / Ip die verbindt kaapt Een aanval waardoor actief, gevestigd, zitting wordt onderschept en door de aanvaller gecoöpteerd. Ip die aanvallen verbindt kan voorkomen nadat een authentificatie is gemaakt, toelatend de aanvaller om de rol van een reeds erkende gebruiker te vervullen. De primaire bescherming tegen IP het Verbinden baseren zich bij de encryptie bij de zitting of netwerklaag. Minste Voorrecht Het ontwerpen van operationele aspecten van een systeem om met een minimumhoeveelheid systeemvoorrecht te werken. Dit vermindert het vergunningsniveau waarop diverse acties worden uitgevoerd en de kans vermindert dat een proces of een gebruiker met hoge voorrechten kan worden ertoe gebracht om onbevoegde activiteit uit te voeren resulterend in een veiligheidsbreuk. Registreren Het proces om informatie over gebeurtenissen op te slaan die op de firewall of het netwerk voorkwamen. Het Behoud van het logboek Hoe lang de controlelogboeken worden behouden en gehandhaafd. De Verwerking van het logboek Hoe de controlelogboeken worden verwerkt, gezocht naar zeer belangrijke gebeurtenissen, of samengevat. Netwerk-laag Firewall Een firewall waarin het verkeer bij de het pakketlaag van het netwerkprotocol wordt onderzocht. Op perimeter-gebaseerde Veiligheid De techniek om een netwerk te beveiligen door toegang tot alle ingang en uitgangspunten van het netwerk te controleren. Beleid Organisatie-vlakke regels die aanvaardbaar gebruik van de gegevensverwerking van middelen, veiligheidspraktijken, en operationele procedures reglementeren. Volmacht Een softwareagent die namens een gebruiker handelt. De typische volmachten keuren een aansluting van een gebruiker goed, nemen een besluit over de vraag of of niet het gebruiker of cliëntip adres wordt toegelaten om de volmacht te gebruiken, misschien extra authentificatie, doet en dan een aansluting namens de gebruiker aan een verre bestemming voltooit. Onderzochte Gastheer Een gastheer op een netwerk achter een onderzoeksrouter. De graad waaraan een onderzochte gastheer kan worden betreden hangt van de onderzoeksregels af in de router. Onderzochte Subnet Subnet achter een onderzoeksrouter. De graad waaraan subnet kan worden betreden hangt van de onderzoeksregels af in de router. De Router van het onderzoek Een router die wordt gevormd om verkeer toe te laten of te ontkennen dat op een reeks toestemmingsregels wordt gebaseerd die door de beheerder worden geïnstalleerd. De Diefstal van de zitting Zie IP het Verbinden. Trojan Paard Een softwareentiteit die schijnt om normaal iets te doen maar die, in feite, een trapdoor of aanvalsprogramma bevat. Een tunnel gravende Router Een router of een systeem geschikt om verkeer te leiden door het te coderen en het in te kapselen voor transmissie over een onbetrouwbaar netwerk, voor uiteindelijke DE-INKAPSELING en decryptie. Sociale Techniek Een aanval die bij het bedriegen van gebruikers of beheerders bij de doelplaats wordt gebaseerd. De sociale techniekaanvallen worden typisch uitgevoerd door gebruikers of exploitanten te telefoneren en te beweren een erkende gebruiker te zijn, om ongeoorloofde toegang tot systemen proberen te verkrijgen. De virtuele Perimeter van het Netwerk Een netwerk dat één enkel beschermd netwerk achter firewalls schijnt te zijn, dat eigenlijk gecodeerde virtuele links over onbetrouwbare netwerken omvat. Virus Een het herhalen codesegment dat zich aan een programma of gegevensdossier vastmaakt. De virussen zouden of zouden aanvalsprogramma's of trapdoors kunnen kunnen niet niet bevatten. Jammer genoeg, hebben velen aan het roepen van om het even welke kwaadwillige code virussen `` ' genomen. Als u betekent `` zegt trojan paard '' of `` worm '', `` trojan paard '' of `` worm ''. Worm Een standalone programma dat, wanneer in werking gesteld, kopiëert zelf van één gastheer aan een andere, en loopt dan zelf over elke onlangs besmette gastheer. De wijd gemelde ``Internet Virussen ' van 1988 waren een virus helemaal niet, maar eigenlijk een worm. ---------------------------------------------------------------------- ---------- Voetnoten ... Systeem1 http://mail-abuse.org/ ... Initiatief2 http://mail-abuse.org/tsi/ ... Pijlinktvis3 http://squid.nlanr.net/ ... Apache4 http://www.apache.org/docs/mod/mod_proxy.html ... Volmacht5 http://home.netscape.com/proxy/v3.5/index.html ... Netscape6 http://developer.netscape.com/docs/m...n/contents.htm ... firewall7 http://www.real.com/firewall/ ... bugtraq8 http://www.securityfocus.com ... online.9 http://www.thegild.com/firewall/. |
Re: Internet Firewall FAQ in Dutch
"William L. Sun" <88sun@cox.net> wrote in message
news:CSdNd.10971$6u.4455@fed1read02... > Firewall FAQ in Nederlands Deel 1 computer translated? Indeed, it's dutch, better said it's a great collection of dutch words. But to understand it it's not that easy. To translate it in real dutch it will take me a day I'm afraid. Oh man, what a terrible sentence constructions. |
Re: Internet Firewall FAQ in Dutch
Yes, It is computer translated. Just want to start the effort. If you can
help to correct it, We would be grateful. It will benefit more people in the world. Thank you "you mean dutch?" <me@privacy.net> wrote in message news:36m4djF51qpqaU1@individual.net... > "William L. Sun" <88sun@cox.net> wrote in message > news:CSdNd.10971$6u.4455@fed1read02... > > Firewall FAQ in Nederlands Deel 1 > > > computer translated? > Indeed, it's dutch, better said it's a great collection of dutch words. > But to understand it it's not that easy. > To translate it in real dutch it will take me a day I'm afraid. > Oh man, what a terrible sentence constructions. > > |
Re: Internet Firewall FAQ in Dutch
How about the ENGLISH one?!
On Sun, 6 Feb 2005 11:23:30 -0800, "William L. Sun" <88sun@cox.net> spewed: >Yes, It is computer translated. Just want to start the effort. If you can >help to correct it, We would be grateful. It will benefit >more people in the world. > >Thank you >"you mean dutch?" <me@privacy.net> wrote in message >news:36m4djF51qpqaU1@individual.net... >> "William L. Sun" <88sun@cox.net> wrote in message >> news:CSdNd.10971$6u.4455@fed1read02... >> > Firewall FAQ in Nederlands Deel 1 >> >> >> computer translated? >> Indeed, it's dutch, better said it's a great collection of dutch words. >> But to understand it it's not that easy. >> To translate it in real dutch it will take me a day I'm afraid. >> Oh man, what a terrible sentence constructions. >> >> > -- __________________________________________________ ___ For email response, or CC, please mailto:see.my.sig.4.addr(at)bigfoot.com. Yeah, it's really a real address :) |
Re: Internet Firewall FAQ in Dutch
"William L. Sun" <88sun@cox.net> wrote in message
news:n9uNd.11112$6u.7419@fed1read02... > Yes, It is computer translated. Just want to start the effort. If you can > help to correct it, We would be grateful. It will benefit > more people in the world. the other FAQ's requires also a lot of attention; you need for every language a good translator. I will give it a try after you post the original english ( I hope ) version. Without it it's sometimes very hard to understand what the FAQ wants to tell me. Give me a week ( maybe two? ) after your english FAQ posting. It takes a lot of time to translate it from dutch to dutch :-). ( for example 6.1 havens (dutch FAQ) = harbour ( eng ) ; kanal (german FAQ) = canal or channel ( eng ) ; port (french FAQ) ah-ha you mean port (eng ) ; so 6.1 should be poorten or poort. I'm used to the english word "port" but I have to look in a dutch manual to be sure if 'poort' is the correct word). Sometimes I really have no idea what the FAQ tries to tell me. This is a once-only offer if that's no problem. You have to do the PDF part. There are no problems with copyrights if I translated it to a readable faq? The good news for you ;;-)) is that someone looked at the FAQ, but the bad thing for me is that I hope to have enough TCP/UDP/Internet knowledge. What about firewalls-faq@interhack.net named in the FAQ? Maybe it's much better that I send an email to this email address to be sure that I'm the only one translating it and not somebody else just finished a translation. Or give me an email address in your reply I could use to contact you. |
Re: Internet Firewall FAQ in Dutch
In article <1v2e0112rvqlepsuig2e1ervkqm2gctuff@4ax.com>,
see.my.sig.4.addr@nowhere.com.invalid wrote: >How about the ENGLISH one?! Is your access to http://www.google.com broken? Or can't you think of the right keywords to search for? Here, let me help: Google Search: Internet Firewall FAQ (p1 of 3) Go to Google Home Web Images Groups News Froogle LocalNew! more >> Internet Firewall FAQ____________________ Search Advanced Search Preferences Web Results 1 - 10 of about 4,830,000 for Internet Firewall FAQ. (0.32 seconds) Sheesh! Only four million choices of web sites. Old guy |
Re: Internet Firewall FAQ in Dutch
Thank you very much for your help. Here is the english version. Please take
your time to do it. ============== Internet Firewalls: Frequently Asked Questions Paul D. Robertson paul@compuwar.net Matt Curtin cmcurtin@interhack.net Marcus J. Ranum mjr@ranum.com Date: 2004/07/26 15:34:42 Revision: 10.4 This document available in Postscript.and PDF. Contents 1 Administrativia 1.1 About the FAQ 1.2 For Whom Is the FAQ Written? 1.3 Before Sending Mail 1.4 Where Can I find the Current Version of the FAQ? 1.5 Where Can I Find Non-English Versions of the FAQ? 1.6 Contributors 1.7 Copyright and Usage 2 Background and Firewall Basics 2.1 What is a network firewall? 2.2 Why would I want a firewall? 2.3 What can a firewall protect against? 2.4 What can't a firewall protect against? 2.5 What about viruses and other malware? 2.6 Will IPSEC make firewalls obsolete? 2.7 What are good sources of print information on firewalls? 2.8 Where can I get more information on firewalls on the Internet? 3 Design and Implementation Issues 3.1 What are some of the basic design decisions in a firewall? 3.2 What are the basic types of firewalls? 3.3 What are proxy servers and how do they work? 3.4 What are some cheap packet screening tools? 3.5 What are some reasonable filtering rules for a kernel-based packet screen? 3.6 What are some reasonable filtering rules for a Cisco? 3.7 What are the critical resources in a firewall? 3.8 What is a DMZ, and why do I want one? 3.9 How might I increase the security and scalability of my DMZ? 3.10 What is a `single point of failure', and how do I avoid having one? 3.11 How can I block all of the bad stuff? 3.12 How can I restrict web access so users can't view sites unrelated to work? 4 Various Attacks 4.1 What is source routed traffic and why is it a threat? 4.2 What are ICMP redirects and redirect bombs? 4.3 What about denial of service? 4.4 What are some common attacks, and how can I protect my system against them? 5 How Do I... 5.1 Do I really want to allow everything that my users ask for? 5.2 How do I make Web/HTTP work through my firewall? 5.3 How do I make SSL work through the firewall? 5.4 How do I make DNS work with a firewall? 5.5 How do I make FTP work through my firewall? 5.6 How do I make Telnet work through my firewall? 5.7 How do I make Finger and whois work through my firewall? 5.8 How do I make gopher, archie, and other services work through my firewall? 5.9 What are the issues about X11 through a firewall? 5.10 How do I make RealAudio work through my firewall? 5.11 How do I make my web server act as a front-end for a database that lives on my private network? 5.12 But my database has an integrated web server, and I want to use that. Can't I just poke a hole in the firewall and tunnel that port? 5.13 How Do I Make IP Multicast Work With My Firewall? 6 TCP and UDP Ports 6.1 What is a port? 6.2 How do I know which application uses what port? 6.3 What are LISTENING ports? 6.4 How do I determine what service the port is for? 6.5 What ports are safe to pass through a firewall? 6.6 The behavior of FTP 6.7 What software uses what FTP mode? 6.8 Is my firewall trying to connect outside? 6.9 The anatomy of a TCP connection A. Some Commercial Products and Vendors B. Glossary of Firewall-Related Terms Bibliography 1 Administrativia 1.1 About the FAQ This collection of Frequenty Asked Questions (FAQs) and answers has been compiled over a period of years, seeing which questions people ask about firewalls in such fora as Usenet, mailing lists, and Web sites. If you have a question, looking here to see whether it's answered before posting your question is good form. Don't send your questions about firewalls to the FAQ maintainers. The maintainers welcome input and comments on the contents of this FAQ. Comments related to the FAQ should be addressed to firewalls-faq@interhack.net. Before you send us mail, please be sure to see sections 1.2 and 1.3 to make sure this is the right document for you to be reading. 1.2 For Whom Is the FAQ Written? Firewalls have come a long way from the days when this FAQ started. They've gone from being highly customized systems administered by their implementors to a mainstream commodity. Firewalls are no longer solely in the hands of those who design and implement security systems; even security-conscious end-users have them at home. We wrote this FAQ for computer systems developers and administrators. We have tried to be fairly inclusive, making room for the newcomers, but we still assume some basic technical background. If you find that you don't understand this document, but think that you need to know more about firewalls, it might well be that you actually need to get more background in computer networking first. We provide references that have helped us; perhaps they'll also help you. We focus predominately on "network" firewalls, but ``host'' or ``"personal'' firewalls will be addressed where appropriate. 1.3 Before Sending Mail Note that this collection of frequently-asked questions is a result of interacting with many people of different backgrounds in a wide variety of public fora. The firewalls-faq address is not a help desk. If you're trying to use an application that says that it's not working because of a firewall and you think that you need to remove your firewall, please do not send us mail asking how. If you want to know how to ``get rid of your firewall'' because you cannot use some application, do not send us mail asking for help. We cannot help you. Really. Who can help you? Good question. That will depend on what exactly the problem is, but here are several pointers. If none of these works, please don't ask us for any more. We don't know. The provider of the software you're using. The provider of the hardware ``appliance'' you're using. The provider of the network service you're using. That is, if you're on AOL, ask them. If you're trying to use something on a corporate network, talk to your system administrator. 1.4 Where Can I find the Current Version of the FAQ? The FAQ can be found on the Web at http://www.compuwar.net/pubs/fwfaq/. http://www.interhack.net/pubs/fwfaq/. It's also posted monthly to comp.security.firewalls, comp.security.unix, comp.security.misc, comp.answers, and news.answers. Posted versions are archived in all the usual places. Unfortunately, the version posted to Usenet and archived from that version lack the pretty pictures and useful hyperlinks found in the web version. 1.5 Where Can I Find Non-English Versions of the FAQ? Several translations are available. (If you've done a translation and it's not listed here, please write us so we can update the master document.) Norwegian Translation by Jon Haugsand http://helmersol.nr.no/haandbok/doc/...nnmur-faq.html 1.6 Contributors Many people have written helpful suggestions and thoughtful commentary. We're grateful to all contributors. We'd like to thank afew by name: Keinanen Vesa, Allen Leibowitz, Brent Chapman, Brian Boyle, D. Clyde Williamson, Richard Reiner, Humberto Ortiz Zuazaga, William Sun and Theodore Hope. 1.7 Copyright and Usage Copyright ©1995-1996, 1998 Marcus J. Ranum. Copyright ©1998-2002 Matt Curtin. Copyright 2004, Paul D. Robertson. All rights reserved. This document may be used, reprinted, and redistributed as is providing this copyright notice and all attributions remain intact. Translations of the complete text from the original English to other languages are also explicitly allowed. Translators may add their names to the ``Contributors'' section. 2 Background and Firewall Basics Before being able to understand a complete discussion of firewalls, it's important to understand the basic principles that make firewalls work. 2.1 What is a network firewall? A firewall is a system or group of systems that enforces an access control policy between two or more networks. The actual means by which this is accomplished varies widely, but in principle, the firewall can be thought of as a pair of mechanisms: one which exists to block traffic, and the other which exists to permit traffic. Some firewalls place a greater emphasis on blocking traffic, while others emphasize permitting traffic. Probably the most important thing to recognize about a firewall is that it implements an access control policy. If you don't have a good idea of what kind of access you want to allow or to deny, a firewall really won't help you. It's also important to recognize that the firewall's configuration, because it is a mechanism for enforcing policy, imposes its policy on everything behind it. Administrators for firewalls managing the connectivity for a large number of hosts therefore have a heavy responsibility. 2.2 Why would I want a firewall? The Internet, like any other society, is plagued with the kind of jerks who enjoy the electronic equivalent of writing on other people's walls with spraypaint, tearing their mailboxes off, or just sitting in the street blowing their car horns. Some people try to get real work done over the Internet, and others have sensitive or proprietary data they must protect. Usually, a firewall's purpose is to keep the jerks out of your network while still letting you get your job done. Many traditional-style corporations and data centers have computing security policies and practices that must be followed. In a case where a company's policies dictate how data must be protected, a firewall is very important, since it is the embodiment of the corporate policy. Frequently, the hardest part of hooking to the Internet, if you're a large company, is not justifying the expense or effort, but convincing management that it's safe to do so. A firewall provides not only real security--it often plays an important role as a security blanket for management. Lastly, a firewall can act as your corporate ``ambassador'' to the Internet. Many corporations use their firewall systems as a place to store public information about corporate products and services, files to download, bug-fixes, and so forth. Several of these systems have become important parts of the Internet service structure (e.g., UUnet.uu.net, whitehouse.gov, gatekeeper.dec.com) and have reflected well on their organizational sponsors. Note that while this is historically true, most organizations now place public information on a Web server, often protected by a firewall, but not normally on the firewall itself. 2.3 What can a firewall protect against? Some firewalls permit only email traffic through them, thereby protecting the network against any attacks other than attacks against the email service. Other firewalls provide less strict protections, and block services that are known to be problems. Generally, firewalls are configured to protect against unauthenticated interactive logins from the ``outside'' world. This, more than anything, helps prevent vandals from logging into machines on your network. More elaborate firewalls block traffic from the outside to the inside, but permit users on the inside to communicate freely with the outside. The firewall can protect you against any type of network-borne attack if you unplug it. Firewalls are also important since they can provide a single ``choke point'' where security and audit can be imposed. Unlike in a situation where a computer system is being attacked by someone dialing in with a modem, the firewall can act as an effective ``phone tap'' and tracing tool. Firewalls provide an important logging and auditing function; often they provide summaries to the administrator about what kinds and amount of traffic passed through it, how many attempts there were to break into it, etc. Because of this, firewall logs are critically important data. They can be used as evidence in a court of law in most countries. You should safeguard, analyze and protect yoru firewall logs accordingly. This is an important point: providing this ``choke point'' can serve the same purpose on your network as a guarded gate can for your site's physical premises. That means anytime you have a change in ``zones'' or levels of sensitivity, such a checkpoint is appropriate. A company rarely has only an outside gate and no receptionist or security staff to check badges on the way in. If there are layers of security on your site, it's reasonable to expect layers of security on your network. 2.4 What can't a firewall protect against? Firewalls can't protect against attacks that don't go through the firewall. Many corporations that connect to the Internet are very concerned about proprietary data leaking out of the company through that route. Unfortunately for those concerned, a magnetic tape, compact disc, DVD, or USB flash drives can just as effectively be used to export data. Many organizations that are terrified (at a management level) of Internet connections have no coherent policy about how dial-in access via modems should be protected. It's silly to build a six-foot thick steel door when you live in a wooden house, but there are a lot of organizations out there buying expensive firewalls and neglecting the numerous other back-doors into their network. For a firewall to work, it must be a part of a consistent overall organizational security architecture. Firewall policies must be realistic and reflect the level of security in the entire network. For example, a site with top secret or classified data doesn't need a firewall at all: they shouldn't be hooking up to the Internet in the first place, or the systems with the really secret data should be isolated from the rest of the corporate network. Another thing a firewall can't really protect you against is traitors or idiots inside your network. While an industrial spy might export information through your firewall, he's just as likely to export it through a telephone, FAX machine, or Compact Disc. CDs are a far more likely means for information to leak from your organization than a firewall. Firewalls also cannot protect you against stupidity. Users who reveal sensitive information over the telephone are good targets for social engineering; an attacker may be able to break into your network by completely bypassing your firewall, if he can find a ``helpful'' employee inside who can be fooled into giving access to a modem pool. Before deciding this isn't a problem in your organization, ask yourself how much trouble a contractor has getting logged into the network or how much difficulty a user who forgot his password has getting it reset. If the people on the help desk believe that every call is internal, you have a problem that can't be fixed by tightening controls on the firewalls. Firewalls can't protect against tunneling over most application protocols to trojaned or poorly written clients. There are no magic bullets and a firewall is not an excuse to not implement software controls on internal networks or ignore host security on servers. Tunneling ``bad'' things over HTTP, SMTP, and other protocols is quite simple and trivially demonstrated. Security isn't ``fire and forget''. Lastly, firewalls can't protect against bad things being allowed through them. For instance, many Trojan Horses use the Internet Relay Chat (IRC) protocol to allow an attacker to control a compromised internal host from a public IRC server. If you allow any internal system to connect to any external system, then your firewall will provide no protection from this vector of attack. 2.5 What about viruses and other malware? Firewalls can't protect very well against things like viruses or malicious software (malware). There are too many ways of encoding binary files for transfer over networks, and too many different architectures and viruses to try to search for them all. In other words, a firewall cannot replace security-consciousness on the part of your users. In general, a firewall cannot protect against a data-driven attack--attacks in which something is mailed or copied to an internal host where it is then executed. This form of attack has occurred in the past against various versions of sendmail, ghostscript, scripting mail user agents like Outlook, and Web browsers like Internet Explorer. Organizations that are deeply concerned about viruses should implement organization-wide virus control measures. Rather than only trying to screen viruses out at the firewall, make sure that every vulnerable desktop has virus scanning software that is run when the machine is rebooted. Blanketing your network with virus scanning software will protect against viruses that come in via floppy disks, CDs, modems, and the Internet. Trying to block viruses at the firewall will only protect against viruses from the Internet. Virus scanning at the firewall or e-mail gateway will stop a large number of infections. Nevertheless, an increasing number of firewall vendors are offering ``virus detecting'' firewalls. They're probably only useful for naive users exchanging Windows-on-Intel executable programs and malicious-macro-capable application documents. There are many firewall-based approaches for dealing with problems like the ``ILOVEYOU'' worm and related attacks, but these are really oversimplified approaches that try to limit the damage of something that is so stupid it never should have occurred in the first place. Do not count on any protection from attackers with this feature. (Since ``ILOVEYOU'' went around, we've seen at least a half-dozen similar attacks, including Melissa, Happy99, Code Red, and Badtrans.B, all of which were happily passed through many virus-detecting firewalls and e-mail gateways.) A strong firewall is never a substitute for sensible software that recognizes the nature of what it's handling--untrusted data from an unauthenticated party--and behaves appropriately. Do not think that because ``everyone'' is using that mailer or because the vendor is a gargantuan multinational company, you're safe. In fact, it isn't true that ``everyone'' is using any mailer, and companies that specialize in turning technology invented elsewhere into something that's ``easy to use'' without any expertise are more likely to produce software that can be fooled. Further consideration of this topic would be worthwhile [3], but is beyond the scope of this document. 2.6 Will IPSEC make firewalls obsolete? Some have argued that this is the case. Before pronouncing such a sweeping prediction, however, it's worthwhile to consider what IPSEC is and what it does. Once we know this, we can consider whether IPSEC will solve the problems that we're trying to solve with firewalls. IPSEC (IP SECurity) refers to a set of standards developed by the Internet Engineering Task Force (IETF). There are many documents that collectively define what is known as ``IPSEC'' [6]. IPSEC solves two problems which have plagued the IP protocol suite for years: host-to-host authentication (which will let hosts know that they're talking to the hosts they think they are) and encryption (which will prevent attackers from being able to watch the traffic going between machines). Note that neither of these problems is what firewalls were created to solve. Although firewalls can help to mitigate some of the risks present on an Internet without authentication or encryption, there are really two classes of problems here: integrity and privacy of the information flowing between hosts and the limits placed on what kinds of connectivity is allowed between different networks. IPSEC addresses the former class and firewalls the latter. What this means is that one will not eliminate the need for the other, but it does create some interesting possibilities when we look at combining firewalls with IPSEC-enabled hosts. Namely, such things as vendor-independent virtual private networks (VPNs), better packet filtering (by filtering on whether packets have the IPSEC authentication header), and application-layer firewalls will be able to have better means of host verification by actually using the IPSEC authentication header instead of ``just trusting'' the IP address presented. 2.7 What are good sources of print information on firewalls? There are several books that touch on firewalls. The best known are: Building Internet Firewalls, 2d ed. Authors Elizabeth D. Zwicky, Simon Cooper, and D. Brent Chapman Publisher O'Reilly Edition 2000 ISBN 1-56592-871-7 Firewalls and Internet Security: Repelling the Wily Hacker Authors Bill Cheswick, Steve Bellovin, Avi Rubin Publisher Addison Wesley Edition 2003 ISBN 020163466X Practical Internet & Unix Security Authors Simson Garfinkel and Gene Spafford Publisher O'Reilly Edition 1996 ISBN 1-56592-148-8 Note Discusses primarily host security. Related references are: Internetworking with TCP/IP Vols I, II, and III Authors Douglas Comer and David Stevens Publisher Prentice-Hall Edition 1991 ISBN 0-13-468505-9 (I), 0-13-472242-6 (II), 0-13-474222-2 (III) Comment A detailed discussion on the architecture and implementation of the Internet and its protocols. Volume I (on principles, protocols and architecture) is readable by everyone. Volume 2 (on design, implementation and internals) is more technical. Volume 3 covers client-server computing. Unix System Security--A Guide for Users and System Administrators Author David Curry Publisher Addison Wesley Edition 1992 ISBN 0-201-56327-4 2.8 Where can I get more information on firewalls on the Internet? Site Security Handbook http://www.rfc-editor.org/rfc/rfc2196.txt The Site Security Handbook is an information IETF document that describes the basic issues that must be addressed for building good site security. Firewalls are one part of a larger security strategy, as the Site Security Handbook shows. Firewalls Mailing List http://www.isc.org/index.pl?/ops/lists/firewalls/ The internet firewalls mailing list is a forum for firewall administrators and implementors. Firewall-Wizards Mailing List http://honor.icsalabs.com/mailman/li...rewall-wizards The Firewall Wizards Mailing List is a moderated firewall and security related list that is more like a journal than a public soapbox. Firewall HOWTO http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html Describes exactly what is needed to build a firewall, particularly using Linux. Firewall Toolkit (FWTK) and Firewall Papers ftp://ftp.tis.com/pub/firewalls/ Marcus Ranum's firewall related publications http://www.ranum.com/pubs/ Texas A&M University security tools http://www.net.tamu.edu/ftp/security/TAMU/ COAST Project Internet Firewalls page http://www.cerias.purdue.edu/coast/firewalls/ 3 Design and Implementation Issues 3.1 What are some of the basic design decisions in a firewall? There are a number of basic design issues that should be addressed by the lucky person who has been tasked with the responsibility of designing, specifying, and implementing or overseeing the installation of a firewall. The first and most important decision reflects the policy of how your company or organization wants to operate the system: is the firewall in place explicitly to deny all services except those critical to the mission of connecting to the Net, or is the firewall in place to provide a metered and audited method of ``queuing'' access in a non-threatening manner? There are degrees of paranoia between these positions; the final stance of your firewall might be more the result of a political than an engineering decision. The second is: what level of monitoring, redundancy, and control do you want? Having established the acceptable risk level (i.e., how paranoid you are) by resolving the first issue, you can form a checklist of what should be monitored, permitted, and denied. In other words, you start by figuring out your overall objectives, and then combine a needs analysis with a risk assessment, and sort the almost always conflicting requirements out into a laundry list that specifies what you plan to implement. The third issue is financial. We can't address this one here in anything but vague terms, but it's important to try to quantify any proposed solutions in terms of how much it will cost either to buy or to implement. For example, a complete firewall product may cost between $100,000 at the high end, and free at the low end. The free option, of doing some fancy configuring on a Cisco or similar router will cost nothing but staff time and a few cups of coffee. Implementing a high end firewall from scratch might cost several man-months, which may equate to $30,000 worth of staff salary and benefits. The systems management overhead is also a consideration. Building a home-brew is fine, but it's important to build it so that it doesn't require constant (and expensive) attention. It's important, in other words, to evaluate firewalls not only in terms of what they cost now, but continuing costs such as support. On the technical side, there are a couple of decisions to make, based on the fact that for all practical purposes what we are talking about is a static traffic routing service placed between the network service provider's router and your internal network. The traffic routing service may be implemented at an IP level via something like screening rules in a router, or at an application level via proxy gateways and services. The decision to make is whether to place an exposed stripped-down machine on the outside network to run proxy services for telnet, FTP, news, etc., or whether to set up a screening router as a filter, permitting communication with one or more internal machines. There are benefits and drawbacks to both approaches, with the proxy machine providing a greater level of audit and, potentially, security in return for increased cost in configuration and a decrease in the level of service that may be provided (since a proxy needs to be developed for each desired service). The old trade-off between ease-of-use and security comes back to haunt us with a vengeance. 3.2 What are the basic types of firewalls? Conceptually, there are three types of firewalls: Network layer Application layer Hybrids They are not as different as you might think, and latest technologies are blurring the distinction to the point where it's no longer clear if either one is ``better'' or ``worse.'' As always, you need to be careful to pick the type that meets your needs. Which is which depends on what mechanisms the firewall uses to pass traffic from one security zone to another. The International Standards Organization (ISO) Open Systems Interconnect (OSI) model for networking defines seven layers, where each layer provides services that ``higher-level'' layers depend on. In order from the bottom, these layers are physical, data link, network, transport, session, presentation, application. The important thing to recognize is that the lower-level the forwarding mechanism, the less examination the firewall can perform. Generally speaking, lower-level firewalls are faster, but are easier to fool into doing the wrong thing. These days, most firewalls fall into the ``hybrid'' category, which do network filtering as well as some amount of application inspection. The amount changes depending on the vendor, product, protocol and version, so some level of digging and/or testing is often necessary. 3.2.1 Network layer firewalls These generally make their decisions based on the source, destination addresses and ports (see Appendix 6 for a more detailed discussion of ports) in individual IP packets. A simple router is the ``traditional'' network layer firewall, since it is not able to make particularly sophisticated decisions about what a packet is actually talking to or where it actually came from. Modern network layer firewalls have become increasingly sophisticated, and now maintain internal information about the state of connections passing through them, the contents of some of the data streams, and so on. One thing that's an important distinction about many network layer firewalls is that they route traffic directly though them, so to use one you either need to have a validly assigned IP address block or to use a ``private internet'' address block [5]. Network layer firewalls tend to be very fast and tend to be very transparent to users. Figure 1: Screened Host Firewall In Figure 1, a network layer firewall called a ``screened host firewall'' is represented. In a screened host firewall, access to and from a single host is controlled by means of a router operating at a network layer. The single host is a bastion host; a highly-defended and secured strong-point that (hopefully) can resist attack. Figure 2: Screened Subnet Firewall Example Network layer firewall: In Figure 2, a network layer firewall called a ``screened subnet firewall'' is represented. In a screened subnet firewall, access to and from a whole network is controlled by means of a router operating at a network layer. It is similar to a screened host, except that it is, effectively, a network of screened hosts. 3.2.2 Application layer firewalls These generally are hosts running proxy servers, which permit no traffic directly between networks, and which perform elaborate logging and auditing of traffic passing through them. Since the proxy applications are software components running on the firewall, it is a good place to do lots of logging and access control. Application layer firewalls can be used as network address translators, since traffic goes in one ``side'' and out the other, after having passed through an application that effectively masks the origin of the initiating connection. Having an application in the way in some cases may impact performance and may make the firewall less transparent. Early application layer firewalls such as those built using the TIS firewall toolkit, are not particularly transparent to end users and may require some training. Modern application layer firewalls are often fully transparent. Application layer firewalls tend to provide more detailed audit reports and tend to enforce more conservative security models than network layer firewalls. Figure 3: Dual Homed Gateway Example Application layer firewall: In Figure 3, an application layer firewall called a ``dual homed gateway'' is represented. A dual homed gateway is a highly secured host that runs proxy software. It has two network interfaces, one on each network, and blocks all traffic passing through it. Most firewalls now lie someplace between network layer firewalls and application layer firewalls. As expected, network layer firewalls have become increasingly ``aware'' of the information going through them, and application layer firewalls have become increasingly ``low level'' and transparent. The end result is that now there are fast packet-screening systems that log and audit data as they pass through the system. Increasingly, firewalls (network and application layer) incorporate encryption so that they may protect traffic passing between them over the Internet. Firewalls with end-to-end encryption can be used by organizations with multiple points of Internet connectivity to use the Internet as a ``private backbone'' without worrying about their data or passwords being sniffed. (IPSEC, described in Section 2.6, is playing an increasingly significant role in the construction of such virtual private networks.) 3.3 What are proxy servers and how do they work? A proxy server (sometimes referred to as an application gateway or forwarder) is an application that mediates traffic between a protected network and the Internet. Proxies are often used instead of router-based traffic controls, to prevent traffic from passing directly between networks. Many proxies contain extra logging or support for user authentication. Since proxies must ``understand'' the application protocol being used, they can also implement protocol specific security (e.g., an FTP proxy might be configurable to permit incoming FTP and block outgoing FTP). Proxy servers are application specific. In order to support a new protocol via a proxy, a proxy must be developed for it. One popular set of proxy servers is the TIS Internet Firewall Toolkit (``FWTK'') which includes proxies for Telnet, rlogin, FTP, the X Window System, HTTP/Web, and NNTP/Usenet news. SOCKS is a generic proxy system that can be compiled into a client-side application to make it work through a firewall. Its advantage is that it's easy to use, but it doesn't support the addition of authentication hooks or protocol specific logging. For more information on SOCKS, see http://www.socks.nec.com/. 3.4 What are some cheap packet screening tools? The Texas A&M University security tools include software for implementing screening routers. Karlbridge is a PC-based screening router kit available from ftp://ftp.net.ohio-state.edu/pub/kbridge/. There are numerous kernel-level packet screens, including ipf, ipfw, ipchains, pf, and ipfwadm. Typically, these are included in various free Unix implementations, such as FreeBSD, OpenBSD, NetBSD, and Linux. You might also find these tools available in your commercial Unix implementation. If you're willing to get your hands a little dirty, it's completely possible to build a secure and fully functional firewall for the price of hardware and some of your time. 3.5 What are some reasonable filtering rules for a kernel-based packet screen? This example is written specifically for ipfwadm on Linux, but the principles (and even much of the syntax) applies for other kernel interfaces for packet screening on ``open source'' Unix systems. There are four basic categories covered by the ipfwadm rules: -A Packet Accounting -I Input firewall -O Output firewall -F Forwarding firewall ipfwadm also has masquerading (-M) capabilities. For more information on switches and options, see the ipfwadm man page. 3.5.1 Implementation Here, our organization is using a private (RFC 1918) Class C network 192.168.1.0. Our ISP has assigned us the address 201.123.102.32 for our gateway's external interface and 201.123.102.33 for our external mail server. Organizational policy says: Allow all outgoing TCP connections Allow incoming SMTP and DNS to external mail server Block all other traffic The following block of commands can be placed in a system boot file (perhaps rc.local on Unix systems). ipfwadm -F -f ipfwadm -F -p deny ipfwadm -F -i m -b -P tcp -S 0.0.0.0/0 1024:65535 -D 201.123.102.33 25 ipfwadm -F -i m -b -P tcp -S 0.0.0.0/0 1024:65535 -D 201.123.102.33 53 ipfwadm -F -i m -b -P udp -S 0.0.0.0/0 1024:65535 -D 201.123.102.33 53 ipfwadm -F -a m -S 192.168.1.0/24 -D 0.0.0.0/0 -W eth0 /sbin/route add -host 201.123.102.33 gw 192.168.1.2 3.5.2 Explanation Line one flushes (-f) all forwarding (-F) rules. Line two sets the default policy (-p) to deny. Lines three through five are input rules (-i) in the following format: ipfwadm -F (forward) -i (input) m (masq.) -b (bi-directional) -P protocol)[protocol]-S (source)[subnet/mask] [originating ports]-D (destination)[subnet/mask][port] Line six appends (-a) a rule that permits all internal IP addresses out to all external addresses on all protocols, all ports. Line eight adds a route so that traffic going to 201.123.102.33 will be directed to the internal address 192.168.1.2. 3.6 What are some reasonable filtering rules for a Cisco? The example in Figure 4 shows one possible configuration for using the Cisco as filtering router. It is a sample that shows the implementation of as specific policy. Your policy will undoubtedly vary. Figure 4: Packet Filtering Router In this example, a company has Class C network address 195.55.55.0. Company network is connected to Internet via IP Service Provider. Company policy is to allow everybody access to Internet services, so all outgoing connections are accepted. All incoming connections go through ``mailhost''. Mail and DNS are only incoming services. 3.6.1 Implementation Allow all outgoing TCP-connections Allow incoming SMTP and DNS to mailhost Allow incoming FTP data connections to high TCP port (1024) Try to protect services that live on high port numbers Only incoming packets from Internet are checked in this configuration. Rules are tested in order and stop when the first match is found. There is an implicit deny rule at the end of an access list that denies everything. This IP access list assumes that you are running Cisco IOS v. 10.3 or later. no ip source-route ! interface ethernet 0 ip address 195.55.55.1 no ip directed-broadcast ! interface serial 0 no ip directed-broadcast ip access-group 101 in ! access-list 101 deny ip 127.0.0.0 0.255.255.255 any access-list 101 deny ip 10.0.0.0 0.255.255.255 any access-list 101 deny ip 172.16.0.0 0.15.255.255 any access-list 101 deny ip 192.168.0.0 0.0.255.255 any access-list 101 deny ip any 0.0.0.255 255.255.255.0 access-list 101 deny ip any 0.0.0.0 255.255.255.0 ! access-list 101 deny ip 195.55.55.0 0.0.0.255 access-list 101 permit tcp any any established ! access-list 101 permit tcp any host 195.55.55.10 eq smtp access-list 101 permit tcp any host 195.55.55.10 eq dns access-list 101 permit udp any host 192.55.55.10 eq dns ! access-list 101 deny tcp any any range 6000 6003 access-list 101 deny tcp any any range 2000 2003 access-list 101 deny tcp any any eq 2049 access-list 101 deny udp any any eq 2049 ! access-list 101 permit tcp any 20 any gt 1024 ! access-list 101 permit icmp any any ! snmp-server community FOOBAR RO 2 line vty 0 4 access-class 2 in access-list 2 permit 195.55.55.0 0.0.0.255 3.6.2 Explanations Drop all source-routed packets. Source routing can be used for address spoofing. Drop directed broadcasts, which are used in smurf attacks. If an incoming packet claims to be from a local net, loopback network, or private network, drop it. All packets which are part of already established TCP-connections can pass through without further checking. All connections to low port numbers are blocked except SMTP and DNS. Block all services that listen for TCP connections on high port numbers. X11 (port 6000+), OpenWindows (port 2000+) are a few candidates. NFS (port 2049) runs usually over UDP, but it can be run over TCP, so you should block it. Incoming connections from port 20 into high port numbers are supposed to be FTP data connections. Access-list 2 limits access to router itself (telnet & SNMP) All UDP traffic is blocked to protect RPC services 3.6.3 Shortcomings You cannot enforce strong access policies with router access lists. Users can easily install backdoors to their systems to get over ``no incoming telnet'' or ``no X11'' rules. Also crackers install telnet backdoors on systems where they break in. You can never be sure what services you have listening for connections on high port numbers. (You can't be sure of what services you have listening for connections on low port numbers, either, especially in highly decentralized environments where people can put their own machines on the network or where they can get administrative access to their own machines.) Checking the source port on incoming FTP data connections is a weak security method. It also breaks access to some FTP sites. It makes use of the service more difficult for users without preventing bad guys from scanning your systems. Use at least Cisco version 9.21 so you can filter incoming packets and check for address spoofing. It's still better to use 10.3, where you get some extra features (like filtering on source port) and some improvements on filter syntax. You have still a few ways to make your setup stronger. Block all incoming TCP-connections and tell users to use passive-FTP clients. You can also block outgoing ICMP echo-reply and destination-unreachable messages to hide your network and to prevent use of network scanners. Cisco.com use to have an archive of examples for building firewalls using Cisco routers, but it doesn't seem to be online anymore. There are some notes on Cisco access control lists, at least, at ftp://ftp.cisco.com/pub/mibs/app_notes/access-lists. 3.7 What are the critical resources in a firewall? It's important to understand the critical resources of your firewall architecture, so when you do capacity planning, performance optimizations, etc., you know exactly what you need to do, and how much you need to do it in order to get the desired result. What exactly the firewall's critical resources are tends to vary from site to site, depending on the sort of traffic that loads the system. Some people think they'll automatically be able to increase the data throughput of their firewall by putting in a box with a faster CPU, or another CPU, when this isn't necessarily the case. Potentially, this could be a large waste of money that doesn't do anything to solve the problem at hand or provide the expected scalability. On busy systems, memory is extremely important. You have to have enough RAM to support every instance of every program necessary to service the load placed on that machine. Otherwise, the swapping will start and the productivity will stop. Light swapping isn't usually much of a problem, but if a system's swap space begins to get busy, then it's usually time for more RAM. A system that's heavily swapping is often relatively easy to push over the edge in a denial-of-service attack, or simply fall behind in processing the load placed on it. This is where long email delays start. Beyond the system's requirement for memory, it's useful to understand that different services use different system resources. So the configuration that you have for your system should be indicative of the kind of load you plan to service. A 1400 MHz processor isn't going to do you much good if all you're doing is netnews and mail, and are trying to do it on an IDE disk with an ISA controller. Table 1: Critical Resources for Firewall Services Service Critical Resource Email Disk I/O Netnews Disk I/O Web Host OS Socket Performance IP Routing Host OS Socket Performance Web Cache Host OS Socket Performance, Disk I/O 3.8 What is a DMZ, and why do I want one? ``DMZ'' is an abbreviation for ``demilitarized zone''. In the context of firewalls, this refers to a part of the network that is neither part of the internal network nor directly part of the Internet. Typically, this is the area between your Internet access router and your bastion host, though it can be between any two policy-enforcing components of your architecture. A DMZ can be created by putting access control lists on your access router. This minimizes the exposure of hosts on your external LAN by allowing only recognized and managed services on those hosts to be accessible by hosts on the Internet. Many commercial firewalls simply make a third interface off of the bastion host and label it the DMZ, the point is that the network is neither ``inside'' nor ``outside''. For example, a web server running on NT might be vulnerable to a number of denial-of-service attacks against such services as RPC, NetBIOS and SMB. These services are not required for the operation of a web server, so blocking TCP connections to ports 135, 137, 138, and 139 on that host will reduce the exposure to a denial-of-service attack. In fact, if you block everything but HTTP traffic to that host, an attacker will only have one service to attack. This illustrates an important principle: never offer attackers more to work with than is absolutely necessary to support the services you want to offer the public. 3.9 How might I increase the security and scalability of my DMZ? A common approach for an attacker is to break into a host that's vulnerable to attack, and exploit trust relationships between the vulnerable host and more interesting targets. If you are running a number of services that have different levels of security, you might want to consider breaking your DMZ into several ``security zones''. This can be done by having a number of different networks within the DMZ. For example, the access router could feed two Ethernets, both protected by ACLs, and therefore in the DMZ. On one of the Ethernets, you might have hosts whose purpose is to service your organization's need for Internet connectivity. These will likely relay mail, news, and host DNS. On the other Ethernet could be your web server(s) and other hosts that provide services for the benefit of Internet users. In many organizations, services for Internet users tend to be less carefully guarded and are more likely to be doing insecure things. (For example, in the case of a web server, unauthenticated and untrusted users might be running CGI, PHP, or other executable programs. This might be reasonable for your web server, but brings with it a certain set of risks that need to be managed. It is likely these services are too risky for an organization to run them on a bastion host, where a slip-up can result in the complete failure of the security mechanisms.) By putting hosts with similar levels of risk on networks together in the DMZ, you can help minimize the effect of a breakin at your site. If someone breaks into your web server by exploiting some bug in your web server, they'll not be able to use it as a launching point to break into your private network if the web servers are on a separate LAN from the bastion hosts, and you don't have any trust relationships between the web server and bastion host. Now, keep in mind that this is Ethernet. If someone breaks into your web server, and your bastion host is on the same Ethernet, an attacker can install a sniffer on your web server, and watch the traffic to and from your bastion host. This might reveal things that can be used to break into the bastion host and gain access to the internal network. (Switched Ethernet can reduce your exposure to this kind of problem, but will not eliminate it.) Splitting services up not only by host, but by network, and limiting the level of trust between hosts on those networks, you can greatly reduce the likelihood of a breakin on one host being used to break into the other. Succinctly stated: breaking into the web server in this case won't make it any easier to break into the bastion host. You can also increase the scalability of your architecture by placing hosts on different networks. The fewer machines that there are to share the available bandwidth, the more bandwidth that each will get. 3.10 What is a `single point of failure', and how do I avoid having one? An architecture whose security hinges upon one mechanism has a single point of failure. Software that runs bastion hosts has bugs. Applications have bugs. Software that controls routers has bugs. It makes sense to use all of these components to build a securely designed network, and to use them in redundant ways. If your firewall architecture is a screened subnet, you have two packet filtering routers and a bastion host. (See question 3.2 from this section.) Your Internet access router will not permit traffic from the Internet to get all the way into your private network. However, if you don't enforce that rule with any other mechanisms on the bastion host and/or choke router, only one component of your architecture needs to fail or be compromised in order to get inside. On the other hand, if you have a redundant rule on the bastion host, and again on the choke router, an attacker will need to defeat three mechanisms. Further, if the bastion host or the choke router needs to invoke its rule to block outside access to the internal network, you might want to have it trigger an alarm of some sort, since you know that someone has gotten through your access router. 3.11 How can I block all of the bad stuff? For firewalls where the emphasis is on security instead of connectivity, you should consider blocking everything by default, and only specifically allowing what services you need on a case-by-case basis. If you block everything, except a specific set of services, then you've already made your job much easier. Instead of having to worry about every security problem with everything product and service around, you only need to worry about every security problem with a specific set of services and products. Before turning on a service, you should consider a couple of questions: Is the protocol for this product a well-known, published protocol? Is the application to service this protocol available for public inspection of its implementation? How well known is the service and product? How does allowing this service change the firewall architecture? Will an attacker see things differently? Could it be exploited to get at my internal network, or to change things on hosts in my DMZ? When considering the above questions, keep the following in mind: ``Security through obscurity'' is no security at all. Unpublished protocols have been examined by bad guys and defeated. Despite what the marketing representatives say, not every protocol or service is designed with security in mind. In fact, the number that are is very few. Even in cases where security is a consideration, not all organizations have competent security staff. Among those who don't, not all are willing to bring a competent consultant into the project. The end result is that otherwise-competent, well-intended developers can design insecure systems. The less that a vendor is willing to tell you about how their system really works, the more likely it is that security (or other) problems exist. Only vendors with something to hide have a reason to hide their designs and implementations [2]. 3.12 How can I restrict web access so users can't view sites unrelated to work? A few years ago, someone got the idea that it's a good idea to block ``bad'' web sites, i.e., those that contain material that The Company views ``inappropriate''. The idea has been increasing in popularity, but there are several things to consider when thinking about implementing such controls in your firewall. It is not possible to practically block everything that an employer deems ``inappropriate''. The Internet is full of every sort of material. Blocking one source will only redirect traffic to another source of such material, or cause someone to figure a way around the block. Most organizations do not have a standard for judging the appropriateness of material that their employees bring to work, e.g., books and magazines. Do you inspect everyone's briefcase for ``inappropriate material'' every day? If you do not, then why would you inspect every packet for ``inappropriate material''? Any decisions along those lines in such an organization will be arbitrary. Attempting to take disciplinary action against an employee where the only standard is arbitrary typically isn't wise, for reasons well beyond the scope of this document. Products that perform site-blocking, commercial and otherwise, are typically easy to circumvent. Hostnames can be rewritten as IP addresses. IP addresses can be written as a 32-bit integer value, or as four 8-bit integers (the most common form). Other possibilities exist, as well. Connections can be proxied. Web pages can be fetched via email. You can't block them all. The effort that you'll spend trying to implement and manage such controls will almost certainly far exceed any level of damage control that you're hoping to have. The rule-of-thumb to remember here is that you cannot solve social problems with technology. If there is a problem with someone going to an ``inappropriate'' web site, that is because someone else saw it and was offended by what he saw, or because that person's productivity is below expectations. In either case, those are matters for the personnel department, not the firewall administrator. 4 Various Attacks 4.1 What is source routed traffic and why is it a threat? Normally, the route a packet takes from its source to its destination is determined by the routers between the source and destination. The packet itself only says where it wants to go (the destination address), and nothing about how it expects to get there. There is an optional way for the sender of a packet (the source) to include information in the packet that tells the route the packet should take to get to its destination; thus the name ``source routing''. For a firewall, source routing is noteworthy, since an attacker can generate traffic claiming to be from a system ``inside'' the firewall. In general, such traffic wouldn't route to the firewall properly, but with the source routing option, all the routers between the attacker's machine and the target will return traffic along the reverse path of the source route. Implementing such an attack is quite easy; so firewall builders should not discount it as unlikely to happen. In practice, source routing is very little used. In fact, generally the main legitimate use is in debugging network problems or routing traffic over specific links for congestion control for specialized situations. When building a firewall, source routing should be blocked at some point. Most commercial routers incorporate the ability to block source routing specifically, and many versions of Unix that might be used to build firewall bastion hosts have the ability to disable or to ignore source routed traffic. 4.2 What are ICMP redirects and redirect bombs? An ICMP Redirect tells the recipient system to override something in its routing table. It is legitimately used by routers to tell hosts that the host is using a non-optimal or defunct route to a particular destination, i.e., the host is sending it to the wrong router. The wrong router sends the host back an ICMP Redirect packet that tells the host what the correct route should be. If you can forge ICMP Redirect packets, and if your target host pays attention to them, you can alter the routing tables on the host and possibly subvert the security of the host by causing traffic to flow via a path the network manager didn't intend. ICMP Redirects also may be employed for denial of service attacks, where a host is sent a route that loses it connectivity, or is sent an ICMP Network Unreachable packet telling it that it can no longer access a particular network. Many firewall builders screen ICMP traffic from their network, since it limits the ability of outsiders to ping hosts, or modify their routing tables. Before you decide to block all ICMP packets, you should be aware of how the TCP protocol does ``Path MTU Discovery'', to make certain that you don't break connectivity to other sites. If you can't safely block it everywhere, you can consider allowing selected types of ICMP to selected routing devices. If you don't block it, you should at least ensure that your routers and hosts don't respond to broadcast ping packets. 4.3 What about denial of service? Denial of service is when someone decides to make your network or firewall useless by disrupting it, crashing it, jamming it, or flooding it. The problem with denial of service on the Internet is that it is impossible to prevent. The reason has to do with the distributed nature of the network: every network node is connected via other networks which in turn connect to other networks, etc. A firewall administrator or ISP only has control of a few of the local elements within reach. An attacker can always disrupt a connection ``upstream'' from where the victim controls it. In other words, if someone wanted to take a network off the air, he could do it either by taking the network off the air, or by taking the networks it connects to off the air, ad infinitum. There are many, many, ways someone can deny service, ranging from the complex to the trivial brute-force. If you are considering using Internet for a service which is absolutely time or mission critical, you should consider your fallback position in the event that the network is down or damaged. TCP/IP's UDP echo service is trivially abused to get two servers to flood a network segment with echo packets. You should consider commenting out unused entries in /etc/inetd.conf of Unix hosts, adding no ip small-servers to Cisco routers, or the equivalent for your components. 4.4 What are some common attacks, and how can I protect my system against them? Each site is a little different from every other in terms of what attacks are likely to be used against it. Some recurring themes do arise, though. 4.4.1 SMTP Server Hijacking (Unauthorized Relaying) This is where a spammer will take many thousands of copies of a message and send it to a huge list of email addresses. Because these lists are often so bad, and in order to increase the speed of operation for the spammer, many have resorted to simply sending all of their mail to an SMTP server that will take care of actually delivering the mail. Of course, all of the bounces, spam complaints, hate mail, and bad PR come for the site that was used as a relay. There is a very real cost associated with this, mostly in paying people to clean up the mess afterward. The Mail Abuse Prevention System1Transport Security Initiative2maintains a complete description of the problem, and how to configure about every mailer on the planet to protect against this attack. 4.4.2 Exploiting Bugs in Applications Various versions of web servers, mail servers, and other Internet service software contain bugs that allow remote (Internet) users to do things ranging from gain control of the machine to making that application crash and just about everything in between. The exposure to this risk can be reduced by running only necessary services, keeping up to date on patches, and using products that have been around a while. 4.4.3 Bugs in Operating Systems Again, these are typically initiated by users remotely. Operating systems that are relatively new to IP networking tend to be more problematic, as more mature operating systems have had time to find and eliminate their bugs. An attacker can often make the target equipment continuously reboot, crash, lose the ability to talk to the network, or replace files on the machine. Here, running as few operating system services as possible can help. Also, having a packet filter in front of the operating system can reduce the exposure to a large number of these types of attacks. And, of course, chosing a stable operating system will help here as well. When selecting an OS, don't be fooled into believing that ``the pricier, the better''. Free operating systems are often much more robust than their commercial counterparts 5 How Do I... 5.1 Do I really want to allow everything that my users ask for? It's entirely possible that the answer is ``no''. Each site has its own policies about what is and isn't needed, but it's important to remember that a large part of the job of being an organization's gatekeeper is education. Users want streaming video, real-time chat, and to be able to offer services to external customers that require interaction with live databases on the internal network. That doesn't mean that any of these things can be done without presenting more risk to the organization than the supposed ``value'' of heading down that road is worth. Most users don't want to put their organization at risk. They just read the trade rags, see advertisements, and they want to do those things, too. It's important to look into what it is that they really want to do, and to help them understand how they might be able to accomplish their real objective in a more secure manner. You won't always be popular, and you might even find yourself being given direction to do something incredibly stupid, like ``just open up ports foo through bar''. If that happens, don't worry about it. It would be wise to keep all of your exchanges on such an event so that when a 12-year-old script kiddie breaks in, you'll at least be able to separate yourself from the whole mess. 5.2 How do I make Web/HTTP work through my firewall? There are three ways to do it. Allow ``established'' connections out via a router, if you are using screening routers. Use a web client that supports SOCKS, and run SOCKS on your bastion host. Run some kind of proxy-capable web server on the bastion host. Some options include Squid3, Apache4, Netscape Proxy5, and http-gw from the TIS firewall toolkit. Most of these can also proxy other protocols (such as gopher and ftp), and can cache objects fetched, which will also typically result in a performance boost for the users, and more efficient use of your connection to the Internet. Essentially all web clients (Mozilla, Internet Explorer, Lynx, etc.) have proxy server support built directly into them. 5.3 How do I make SSL work through the firewall? SSL is a protocol that allows secure connections across the Internet. Typically, SSL is used to protect HTTP traffic. However, other protocols (such as telnet) can run atop SSL. Enabling SSL through your firewall can be done the same way that you would allow HTTP traffic, if it's HTTP that you're using SSL to secure, which is usually true. The only difference is that instead of using something that will simply relay HTTP, you'll need something that can tunnel SSL. This is a feature present on most web object caches. You can find out more about SSL from Netscape6. Back to Top Marcus J. Ranum's Firewall FAQ Part 2 5.4 How do I make DNS work with a firewall? Some organizations want to hide DNS names from the outside. Many experts don't think hiding DNS names is worthwhile, but if site/corporate policy mandates hiding domain names, this is one approach that is known to work. Another reason you may have to hide domain names is if you have a non-standard addressing scheme on your internal network. In that case, you have no choice but to hide those addresses. Don't fool yourself into thinking that if your DNS names are hidden that it will slow an attacker down much if they break into your firewall. Information about what is on your network is too easily gleaned from the networking layer itself. If you want an interesting demonstration of this, ping the subnet broadcast address on your LAN and then do an ``arp -a.'' Note also that hiding names in the DNS doesn't address the problem of host names ``leaking'' out in mail headers, news articles, etc. This approach is one of many, and is useful for organizations that wish to hide their host names from the Internet. The success of this approach lies on the fact that DNS clients on a machine don't have to talk to a DNS server on that same machine. In other words, just because there's a DNS server on a machine, there's nothing wrong with (and there are often advantages to) redirecting that machine's DNS client activity to a DNS server on another machine. First, you set up a DNS server on the bastion host that the outside world can talk to. You set this server up so that it claims to be authoritative for your domains. In fact, all this server knows is what you want the outside world to know; the names and addresses of your gateways, your wildcard MX records, and so forth. This is the ``public'' server. Then, you set up a DNS server on an internal machine. This server also claims to be authoritative for your domains; unlike the public server, this one is telling the truth. This is your ``normal'' nameserver, into which you put all your ``normal'' DNS stuff. You also set this server up to forward queries that it can't resolve to the public server (using a ``forwarders'' line in /etc/named.boot on a Unix machine, for example). Finally, you set up all your DNS clients (the /etc/resolv.conf file on a Unix box, for instance), including the ones on the machine with the public server, to use the internal server. This is the key. An internal client asking about an internal host asks the internal server, and gets an answer; an internal client asking about an external host asks the internal server, which asks the public server, which asks the Internet, and the answer is relayed back. A client on the public server works just the same way. An external client, however, asking about an internal host gets back the ``restricted'' answer from the public server. This approach assumes that there's a packet filtering firewall between these two servers that will allow them to talk DNS to each other, but otherwise restricts DNS between other hosts. Another trick that's useful in this scheme is to employ wildcard PTR records in your IN-ADDR.ARPA domains. These cause an an address-to-name lookup for any of your non-public hosts to return something like ``unknown.YOUR.DOMAIN'' rather than an error. This satisfies anonymous FTP sites like ftp.uu.net that insist on having a name for the machines they talk to. This may fail when talking to sites that do a DNS cross-check in which the host name is matched against its address and vice versa. 5.5 How do I make FTP work through my firewall? Generally, making FTP work through the firewall is done either using a proxy server such as the firewall toolkit's ftp-gw or by permitting incoming connections to the network at a restricted port range, and otherwise restricting incoming connections using something like ``established'' screening rules. The FTP client is then modified to bind the data port to a port within that range. This entails being able to modify the FTP client application on internal hosts. In some cases, if FTP downloads are all you wish to support, you might want to consider declaring FTP a ``dead protocol'' and letting you users download files via the Web instead. The user interface certainly is nicer, and it gets around the ugly callback port problem. If you choose the FTP-via-Web approach, your users will be unable to FTP files out, which, depending on what you are trying to accomplish, may be a problem. A different approach is to use the FTP ``PASV'' option to indicate that the remote FTP server should permit the client to initiate connections. The PASV approach assumes that the FTP server on the remote system supports that operation. (See ``Firewall-Friendly FTP'' [1].) Other sites prefer to build client versions of the FTP program that are linked against a SOCKS library. 5.6 How do I make Telnet work through my firewall? Telnet is generally supported either by using an application proxy such as the firewall toolkit's tn-gw, or by simply configuring a router to permit outgoing connections using something like the ``established'' screening rules. Application proxies could be in the form of a standalone proxy running on the bastion host, or in the form of a SOCKS server and a modified client. 5.7 How do I make Finger and whois work through my firewall? Many firewall admins permit connections to the finger port from only trusted machines, which can issue finger requests in the form of: finger user@host.domain@firewall. This approach only works with the standard Unix version of finger. Controlling access to services and restricting them to specific machines is managed using either tcp_wrappers or netacl from the firewall toolkit. This approach will not work on all systems, since some finger servers do not permit user@host@host fingering. Many sites block inbound finger requests for a variety of reasons, foremost being past security bugs in the finger server (the Morris internet worm made these bugs famous) and the risk of proprietary or sensitive information being revealed in user's finger information. In general, however, if your users are accustomed to putting proprietary or sensitive information in their .plan files, you have a more serious security problem than just a firewall can solve. 5.8 How do I make gopher, archie, and other services work through my firewall? The majority of firewall administrators choose to support gopher and archie through web proxies, instead of directly. Proxies such as the firewall toolkit's http-gw convert gopher/gopher+ queries into HTML and vice versa. For supporting archie and other queries, many sites rely on Internet-based Web-to-archie servers, such as ArchiePlex. The Web's tendency to make everything on the Internet look like a web service is both a blessing and a curse. There are many new services constantly cropping up. Often they are misdesigned or are not designed with security in mind, and their designers will cheerfully tell you if you want to use them you need to let port xxx through your router. Unfortunately, not everyone can do that, and so a number of interesting new toys are difficult to use for people behind firewalls. Things like RealAudio, which require direct UDP access, are particularly egregious examples. The thing to bear in mind if you find yourself faced with one of these problems is to find out as much as you can about the security risks that the service may present, before you just allow it through. It's quite possible the service has no security implications. It's equally possible that it has undiscovered holes you could drive a truck through. 5.9 What are the issues about X11 through a firewall? The X Windows System is a very useful system, but unfortunately has some major security flaws. Remote systems that can gain or spoof access to a workstation's X11 display can monitor keystrokes that a user enters, download copies of the contents of their windows, etc. While attempts have been made to overcome them (E.g., MIT ``Magic Cookie'') it is still entirely too easy for an attacker to interfere with a user's X11 display. Most firewalls block all X11 traffic. Some permit X11 traffic through application proxies such as the DEC CRL X11 proxy (FTP crl.dec.com). The firewall toolkit includes a proxy for X11, called x-gw, which a user can invoke via the Telnet proxy, to create a virtual X11 server on the firewall. When requests are made for an X11 connection on the virtual X11 server, the user is presented with a pop-up asking them if it is OK to allow the connection. While this is a little unaesthetic, it's entirely in keeping with the rest of X11. 5.10 How do I make RealAudio work through my firewall? RealNetworks maintains some information about how to get RealAudio working through your firewall7. It would be unwise to make any changes to your firewall without understanding what the changes will do, exactly, and knowing what risks the new changes will bring with them. 5.11 How do I make my web server act as a front-end for a database that lives on my private network? The best way to do this is to allow very limited connectivity between your web server and your database server via a specific protocol that only supports the level of functionality you're going to use. Allowing raw SQL, or anything else where custom extractions could be performed by an attacker isn't generally a good idea. Assume that an attacker is going to be able to break into your web server, and make queries in the same way that the web server can. Is there a mechanism for extracting sensitive information that the web server doesn't need, like credit card information? Can an attacker issue an SQL select and extract your entire proprietary database? ``E-commerce'' applications, like everything else, are best designed with security in mind from the ground up, instead of having security ``added'' as an afterthought. Review your architecture critically, from the perspective of an attacker. Assume that the attacker knows everything about your architecture. Now ask yourself what needs to be done to steal your data, to make unauthorized changes, or to do anything else that you don't want done. You might find that you can significantly increase security without decreasing functionality by making a few design and implementation decisions. Some ideas for how to handle this: Extract the data you need from the database on a regular basis so you're not making queries against the full database, complete with information that attackers will find interesting. Greatly restrict and audit what you do allow between the web server and database. 5.12 But my database has an integrated web server, and I want to use that. Can't I just poke a hole in the firewall and tunnel that port? If your site firewall policy is sufficiently lax that you're willing to manage the risk that someone will exploit a vulnerability in your web server that will result in partial or complete exposure of your database, then there isn't much preventing you from doing this. However, in many organizations, the people who are responsible for tying the web front end to the database back end simply do not have the authority to take that responsibility. Further, if the information in the database is about people, you might find yourself guilty of breaking a number of laws if you haven't taken reasonable precautions to prevent the system from being abused. In general, this isn't a good idea. See question 5.11 for some ideas on other ways to accomplish this objective. 5.13 How Do I Make IP Multicast Work With My Firewall? IP multicast is a means of getting IP traffic from one host to a set of hosts without using broadcasting; that is, instead of every host getting the traffic, only those that want it will get it, without each having to maintain a separate connection to the server. IP unicast is where one host talks to another, multicast is where one host talks to a set of hosts, and broadcast is where one host talks to all hosts. The public Internet has a multicast backbone (``MBone'') where users can engage in multicast traffic exchange. Common uses for the MBone are streams of IETF meetings and similar such interaction. Getting one's own network connected to the MBone will require that the upstream provider route multicast traffic to and from your network. Additionally, your internal network will have to support multicast routing. The role of the firewall in multicast routing, conceptually, is no different from its role in other traffic routing. That is, a policy that identifies which multicast groups are and aren't allowed must be defined and then a system of allowing that traffic according to policy must be devised. Great detail on how exactly to do this is beyond the scope of this document. Fortunately, RFC 2588 [4] discusses the subject in more detail. Unless your firewall product supports some means of selective multicast forwarding or you have the ability to put it in yourself, you might find forwarding multicast traffic in a way consistent with your security policy to be a bigger headache than it's worth. 6 TCP and UDP Ports by Mikael Olsson This appendix will begin at a fairly ``basic'' level, so even if the first points seem childishly self-evident to you, you might still learn something from skipping ahead to something later in the text. 6.1 What is a port? A ``port'' is ``virtual slot'' in your TCP and UDP stack that is used to map a connection between two hosts, and also between the TCP/UDP layer and the actual applications running on the hosts. They are numbered 0-65535, with the range 0-1023 being marked as ``reserved'' or ``privlileged'', and the rest (1024-65535) as ``dynamic'' or ``unprivileged''. There are basically two uses for ports: ``Listening'' on a port. This is used by server applications waiting for users to connect, to get to some ``well known service'', for instance HTTP (TCP port 80), Telnet (TCP port 23), DNS (UDP and sometimes TCP port 53). Opening a ``dynamic'' port. Both sides of a TCP connection need to be identified by IP addresses and port numbers. Hence, when you want to ``connect'' to a server process, your end of the communications channel also needs a ``port''. This is done by choosing a port above 1024 on your machine that is not currently in use by another communications channel, and using it as the ``sender'' in the new connection. Dynamic ports may also be used as ``listening'' ports in some applications, most notably FTP. Ports in the range 0-1023 are almost always server ports. Ports in the range 1024-65535 are usually dynamic ports (i.e., opened dynamically when you connect to a server port). However, any port may be used as a server port, and any port may be used as an ``outgoing'' port. So, to sum it up, here's what happens in a basic connection: At some point in time, a server application on host 1.2.3.4 decides to ``listen'' at port 80 (HTTP) for new connections. You (5.6.7.8) want to surf to 1.2.3.4, port 80, and your browser issues a connect call to it. The connect call, realising that it doesn't yet have local port number, goes hunting for one. The local port number is necessary since when the replies come back some time in the future, your TCP/IP stack will have to know to what application to pass the reply. It does this by remembering what application uses which local port number. (This is grossly simplified, no flames from programmers, please.) Your TCP stack finds an unused dynamic port, usually somewhere above 1024. Let's assume that it finds 1029. Your first packet is then sent, from your local IP, 5.6.7.8, port 1029, to 1.2.3.4, port 80. The server responds with a packet from 1.2.3.4, port 80, to you, 5.6.7.8, port 1029. This procedure is actually longer than this, read on for a more in-depth explanation of TCP connect sequences. 6.2 How do I know which application uses what port? There are several lists outlining the ``reserved'' and ``well known'' ports, as well as ``commonly used'' ports, and the best one is: ftp://ftp.isi.edu/in-notes/iana/assi...s/port-numbers. For those of you still reading RFC 1700 to find out what port number does what, STOP DOING IT. It is horribly out of date, and it won't be less so tomorrow. Now, as for trusting this information: These lists do not, in any way, constitute any kind of holy bible on which ports do what. Wait, let me rephrase that: THERE IS NO WAY OF RELIABLY DETERMINING WHAT PORT DOES WHAT SIMPLY BY LOOKING IN A LIST. 6.3 What are LISTENING ports? Suppose you did ``netstat -a'' on your machine and ports 1025 and 1030 showed up as LISTENing. What do they do? Right, let's take a look in the assigned port numbers list. blackjack 1025/tcp network blackjack iad1 1030/tcp BBN IAD Wait, what's happening? Has my workstation stolen my VISA number and decided to go play blackjack with some rogue server on the internet? And what's that software that BBN has installed? This is NOT where you start panicking and send mail to the firewalls list. In fact, this question has been asked maybe a dozen times during the past six months, and every time it's been answered. Not that THAT keeps people from asking the same question again. If you are asking this question, you are most likely using a windows box. The ports you are seeing are (most likely) two listening ports that the RPC subsystem opens when it starts up. This is an example of where dynamicly assigned ports may be used by server processes. Applications using RPC will later on connect to port 135 (the netbios ``portmapper'') to query where to find some RPC service, and get an answer back saying that that particular service may be contacted on port 1025. Now, how do we know this, since there's no ``list'' describing these ports? Simple: There's no substitute for experience. And using the mailing list search engines also helps a hell of a lot. 6.4 How do I determine what service the port is for? Since it is impossible to learn what port does what by looking in a list, how do i do it? The old hands-on way of doing it is by shutting down nearly every service/daemon running on your machine, doing netstat -a and taking note of what ports are open. There shouldn't be very many listening ones. Then you start turning all the services on, one by one, and take note of what new ports show up in your netstat output. Another way, that needs more guess work, is simply telnetting to the ports and see what comes out. If nothing comes out, try typing some gibberish and slamming Enter a few times, and see if something turns up. If you get binary garble, or nothing at all, this obviously won't help you. However, this will only tell you what listening ports are used. It won't tell you about dynamically opened ports that may be opened later on by these applications. There are a few applications that might help you track down the ports used. On Unix systems, there's a nice utility called lsof that comes preinstalled on many systems. It will show you all open port numbers and the names of the applications that are using them. This means that it might show you a lot of locally opened files aswell as TCP/IP sockets. Read the help text. On windows systems, nothing comes preinstalled to assist you in this task. (What's new?) There's a utility called ``Inzider'' which installs itself inside the windows sockets layer and dynamically remembers which process opens which port. The drawback of this approach is that it can't tell you what ports were opened before inzider started, but it's the best that you'll get on windows (to my knowledge). http://ntsecurity.nu/toolbox/inzider/. 6.5 What ports are safe to pass through a firewall? ALL. No, wait, NONE. No, wait, uuhhh... I've heard that all ports above 1024 are safe since they're only dynamic?? No. Really. You CANNOT tell what ports are safe simply by looking at its number, simply because that is really all it is. A number. You can't mount an attack through a 16-bit number. The security of a ``port'' depends on what application you'll reach through that port. A common misconception is that ports 25 (SMTP) and 80 (HTTP) are safe to pass through a firewall. *meep* WRONG. Just because everyone is doing it doesn't mean that it is safe. Again, the security of a port depends on what application you'll reach through that port. If you're running a well-written web server, that is designed from the ground up to be secure, you can probably feel reasonably assured that it's safe to let outside people access it through port 80. Otherwise, you CAN'T. The problem here is not in the network layer. It's in how the application processes the data that it receives. This data may be received through port 80, port 666, a serial line, floppy or through singing telegram. If the application is not safe, it does not matter how the data gets to it. The application data is where the real danger lies. If you are interested in the security of your application, go subscribe to bugtraq8or or try searching their archives. This is more of an application security issue rather than a firewall security issue. One could argue that a firewall should stop all possible attacks, but with the number of new network protocols, NOT designed with security in mind, and networked applications, neither designed with security in mind, it becomes impossible for a firewall to protect against all data-driven attacks. 6.6 The behavior of FTP Or, ``Why do I have to open all ports above 1024 to my FTP server?'' FTP doesn't really look a whole lot like other applications from a networking perspective. It keeps one listening port, port 21, which users connect to. All it does is let people log on, and establish ANOTHER connection to do actual data transfers. This second connection is usually on some port above 1024. There are two modes, ``active'' (normal) and ``passive'' mode. This word describes the server's behaviour. In active mode, the client (5.6.7.8) connects to port 21 on the server (1.2.3.4) and logs on. When file transfers are due, the client allocates a dynamic port above 1024, informs the server about which port it opened, and then the server opens a new connection to that port. This is the ``active'' role of the server: it actively establishes new connections to the client. In passive mode, the connection to port 21 is the same. When file transfers are due, the SERVER allocates a dynamic port above 1024, informs the client about which port it opened, and then the CLIENT opens a new connection to that port. This is the ``passive'' role of the server: it waits for the client to establish the second (data) connection. If your firewall doesn't inspect the application data of the FTP command connection, it won't know that it needs to dynamically open new ports above 1024. On a side note: The traditional behaviour of FTP servers in active mode is to establish the data session FROM port 20, and to the dynamic port on the client. FTP servers are steering away from this behaviour somewhat due to the need to run as ``root'' on unix systems in order to be able to allocate ports below 1024. Running as ``root'' is not good for security, since if there's a bug in the software, the attacker would be able to compromise the entire machine. The same goes for running as ``Administrator'' or ``SYSTEM'' (``LocalSystem'') on NT machines, although the low port problem does not apply on NT. To sum it up, if your firewall understands FTP, it'll be able to handle the data connections by itself, and you won't have to worry about ports above 1024. If it does NOT, there are four issues that you need to address: Firewalling an FTP server in active mode You need to let your server open new connections to the outside world on ports 1024 and above Firewalling an FTP server in passive mode You need to let the outside world connect to ports 1024 and above on your server. CAUTION!!!! There may be applications running on some of these ports that you do NOT want outside people using. Disallow access to these ports before allowing access to the 1024-65535 port range. Firewalling FTP clients in active mode You need to let the outside world connect to ports 1024 and above on your clients. CAUTION!!!! There may be applications running on some of these ports that you do NOT want outside people using. Disallow access to these ports before allowing access to the 1024-65535 port range. Firewalling FTP clients in passive mode You need to let your clients open new connections to the outside world on ports 1024 and above. Again, if your firewall understands FTP, none of the four points above apply to you. Let the firewall do the job for you. 6.7 What software uses what FTP mode? It is up to the client to decide what mode to use; the default mode when a new connection is opened is ``active mode''. Most FTP clients come preconfigured to use active mode, but provide an option to use ``passive'' (``PASV'') mode. An exception is the windows command line FTP client which only operates in active mode. Web Browsers generally use passive mode when connecting via FTP, with a weird exception: MSIE 5 will use active FTP when FTP:ing in ``File Explorer'' mode and passive FTP when FTP:ing in ``Web Page'' mode. There is no reason whatsoever for this behaviour; my guess is that someone in Redmond with no knowledge of FTP decided that ``Of course we'll use active mode when we're in file explorer mode, since that looks more active than a web page''. Go figure. 6.8 Is my firewall trying to connect outside? My firewall logs are telling me that my web server is trying to connect from port 80 to ports above 1024 on the outside. What is this?! If you are seeing dropped packets from port 80 on your web server (or from port 25 on your mail server) to high ports on the outside, they usually DO NOT mean that your web server is trying to connect somewhere. They are the result of the firewall timing out a connection, and seeing the server retransmitting old responses (or trying to close the connection) to the client. TCP connections always involve packets traveling in BOTH directions in the connection. If you are able to see the TCP flags in the dropped packets, you'll see that the ACK flag is set but not the SYN flag, meaning that this is actually not a new connection forming, but rather a response of a previously formed connection. Read point 8 below for an in-depth explanation of what happens when TCP connections are formed (and closed) 6.9 The anatomy of a TCP connection TCP is equipped with 6 ``flags'', which may be ON or OFF. These flags are: FIN ``Controlled'' connection close SYN Open new connection RST ``Immediate'' connection close PSH Instruct receiver host to push the data up to the application rather than just queue it ACK ``Acknowledge'' a previous packet URG ``Urgent'' data which needs to be processed immediately In this example, your client is 5.6.7.8, and the port assigned to you dynamically is 1049. The server is 1.2.3.4, port 80. You begin the connection attempt: 5.6.7.8:1049 -> 1.2.3.4:80 SYN=ON The server receives this packet and understands that someone wants to form a new connection. A response is sent: 1.2.3.4:80 -> 5.6.7.8:1049 SYN=ON ACK=ON The client receives the response, and informs that the response is received 5.6.7.8:1049 -> 1.2.3.4:80 ACK=ON Here, the connection is opened. This is called a three-way handshake. Its purpose is to verify to BOTH hosts that they have a working connection between them. The internet being what it is, unreliable and flooded, there are provisions to compensate for packet loss. If the client sends out the initial SYN without receiving a SYN+ACK within a few seconds, it'll resend the SYN. If the server sends out the SYN+ACK without receiving an ACK in a few seconds, it'll resend the SYN+ACK packet. The latter is actually the reason that SYN flooding works so well. If you send out SYN packets from lots of different ports, this will tie up a lot of resources on the server. If you also refuse to respond to the returned SYN+ACK packets, the server will KEEP these connections for a long time, resending the SYN+ACK packets. Some servers will not accept new connections while there are enough connections currently forming; this is why SYN flooding works. All packets transmitted in either direction after the three-way handshake will have the ACK bit set. Stateless packet filters make use of this in the so called ``established'' filters: They will only let packets through that have the ACK bit set. This way, no packet may pass through in a certain direction that could form a new connection. Typically, you don't allow outside hosts to open new connections to inside hosts by requiring the ACK bit set on these packets. When the time has come to close the connection, there are two ways of doing it: Using the FIN flag, or using the RST flag. Using FIN flags, both implementations are required to send out FIN flags to indicate that they want to close the connection, and then send out acknowledgements to these FINs, indicating that they understood that the other end wants to close the connection. When sending out RST's, the connection is closed forcefully, and you don't really get an indication of whether the other end understood your reset order, or that it has in fact received all data that you sent to it. The FIN way of closing the connection also exposes you to a denial-of-service situation, since the TCP stack needs to remember the closed connection for a fairly long time, in case the other end hasn't received one of the FIN packets. If sufficiently many connections are opened and closed, you may end up having ``closed'' connections in all your connection slots. This way, you wouldn't be able to dynamically allocate more connections, seeing that they're all used. Different OSes handle this situation differently. A. Some Commercial Products and Vendors We feel this topic is too sensitive to address in a FAQ, however, an independently maintained list (no warranty or recommendations are implied) can be found online.9 B. Glossary of Firewall-Related Terms Abuse of Privilege When a user performs an action that they should not have, according to organizational policy or law. Access Control Lists Rules for packet filters (typically routers) that define which packets to pass and which to block. Access Router A router that connects your network to the external Internet. Typically, this is your first line of defense against attackers from the outside Internet. By enabling access control lists on this router, you'll be able to provide a level of protection for all of the hosts ``behind'' that router, effectively making that network a DMZ instead of an unprotected external LAN. Application-Layer Firewall A firewall system in which service is provided by processes that maintain complete TCP connection state and sequencing. Application layer firewalls often re-address traffic so that outgoing traffic appears to have originated from the firewall, rather than the internal host. Authentication The process of determining the identity of a user that is attempting to access a system. Authentication Token A portable device used for authenticating a user. Authentication tokens operate by challenge/response, time-based code sequences, or other techniques. This may include paper-based lists of one-time passwords. Authorization The process of determining what types of activities are permitted. Usually, authorization is in the context of authentication: once you have authenticated a user, they may be authorized different types of access or activity. Bastion Host A system that has been hardened to resist attack, and which is installed on a network in such a way that it is expected to potentially come under attack. Bastion hosts are often components of firewalls, or may be ``outside'' web servers or public access systems. Generally, a bastion host is running some form of general purpose operating system (e.g., Unix, VMS, NT, etc.) rather than a ROM-based or firmware operating system. Challenge/Response An authentication technique whereby a server sends an unpredictable challenge to the user, who computes a response using some form of authentication token. Chroot A technique under Unix whereby a process is permanently restricted to an isolated subset of the filesystem. Cryptographic Checksum A one-way function applied to a file to produce a unique ``fingerprint'' of the file for later reference. Checksum systems are a primary means of detecting filesystem tampering on Unix. Data Driven Attack A form of attack in which the attack is encoded in innocuous-seeming data which is executed by a user or other software to implement an attack. In the case of firewalls, a data driven attack is a concern since it may get through the firewall in data form and launch an attack against a system behind the firewall. Defense in Depth The security approach whereby each system on the network is secured to the greatest possible degree. May be used in conjunction with firewalls. DNS spoofing Assuming the DNS name of another system by either corrupting the name service cache of a victim system, or by compromising a domain name server for a valid domain. Dual Homed Gateway A dual homed gateway is a system that has two or more network interfaces, each of which is connected to a different network. In firewall configurations, a dual homed gateway usually acts to block or filter some or all of the traffic trying to pass between the networks. Encrypting Router see Tunneling Router and Virtual Network Perimeter. Firewall A system or combination of systems that enforces a boundary between two or more networks. Host-based Security The technique of securing an individual system from attack. Host based security is operating system and version dependent. Insider Attack An attack originating from inside a protected network. Intrusion Detection Detection of break-ins or break-in attempts either manually or via software expert systems that operate on logs or other information available on the network. IP Spoofing An attack whereby a system attempts to illicitly impersonate another system by using its IP network address. IP Splicing / Hijacking An attack whereby an active, established, session is intercepted and co-opted by the attacker. IP Splicing attacks may occur after an authentication has been made, permitting the attacker to assume the role of an already authorized user. Primary protections against IP Splicing rely on encryption at the session or network layer. Least Privilege Designing operational aspects of a system to operate with a minimum amount of system privilege. This reduces the authorization level at which various actions are performed and decreases the chance that a process or user with high privileges may be caused to perform unauthorized activity resulting in a security breach. Logging The process of storing information about events that occurred on the firewall or network. Log Retention How long audit logs are retained and maintained. Log Processing How audit logs are processed, searched for key events, or summarized. Network-Layer Firewall A firewall in which traffic is examined at the network protocol packet layer. Perimeter-based Security The technique of securing a network by controlling access to all entry and exit points of the network. Policy Organization-level rules governing acceptable use of computing resources, security practices, and operational procedures. Proxy A software agent that acts on behalf of a user. Typical proxies accept a connection from a user, make a decision as to whether or not the user or client IP address is permitted to use the proxy, perhaps does additional authentication, and then completes a connection on behalf of the user to a remote destination. Screened Host A host on a network behind a screening router. The degree to which a screened host may be accessed depends on the screening rules in the router. Screened Subnet A subnet behind a screening router. The degree to which the subnet may be accessed depends on the screening rules in the router. Screening Router A router configured to permit or deny traffic based on a set of permission rules installed by the administrator. Session Stealing See IP Splicing. Trojan Horse A software entity that appears to do something normal but which, in fact, contains a trapdoor or attack program. Tunneling Router A router or system capable of routing traffic by encrypting it and encapsulating it for transmission across an untrusted network, for eventual de-encapsulation and decryption. Social Engineering An attack based on deceiving users or administrators at the target site. Social engineering attacks are typically carried out by telephoning users or operators and pretending to be an authorized user, to attempt to gain illicit access to systems. Virtual Network Perimeter A network that appears to be a single protected network behind firewalls, which actually encompasses encrypted virtual links over untrusted networks. Virus A replicating code segment that attaches itself to a program or data file. Viruses might or might not not contain attack programs or trapdoors. Unfortunately, many have taken to calling any malicious code a ``virus''. If you mean ``trojan horse'' or ``worm'', say ``trojan horse'' or ``worm''. Worm A standalone program that, when run, copies itself from one host to another, and then runs itself on each newly infected host. The widely reported ``Internet Virus'' of 1988 was not a virus at all, but actually a worm. ---------------------------------------------------------------------- ---------- Footnotes ... System1 http://mail-abuse.org/ ... Initiative2 http://mail-abuse.org/tsi/ ... Squid3 http://squid.nlanr.net/ ... Apache4 http://www.apache.org/docs/mod/mod_proxy.html ... Proxy5 http://home.netscape.com/proxy/v3.5/index.html ... Netscape6 http://developer.netscape.com/docs/m...n/contents.htm ... firewall7 http://www.real.com/firewall/ ... bugtraq8 http://www.securityfocus.com ... online.9 http://www.thegild.com/firewall/. ============== "you mean dutch?" <me@privacy.net> wrote in message news:36ov5cF552dooU1@individual.net... > "William L. Sun" <88sun@cox.net> wrote in message > news:n9uNd.11112$6u.7419@fed1read02... > > > Yes, It is computer translated. Just want to start the effort. If you can > > help to correct it, We would be grateful. It will benefit > > more people in the world. > > the other FAQ's requires also a lot of attention; you need for every > language a good translator. > I will give it a try after you post the original english ( I hope ) version. > Without it it's sometimes very hard to understand what the FAQ wants to tell > me. > Give me a week ( maybe two? ) after your english FAQ posting. It takes a > lot of time to translate it from dutch to dutch :-). > ( for example 6.1 havens (dutch FAQ) = harbour ( eng ) ; kanal (german FAQ) > = canal or channel ( eng ) ; port (french FAQ) ah-ha you mean port (eng ) > ; so 6.1 should be poorten or poort. I'm used to the english word "port" but > I have to look in a dutch manual to be sure if 'poort' is the correct word). > Sometimes I really have no idea what the FAQ tries to tell me. > > > This is a once-only offer if that's no problem. You have to do the PDF part. > There are no problems with copyrights if I translated it to a readable faq? > The good news for you ;;-)) is that someone looked at the FAQ, but the bad > thing for me is that I hope to have enough TCP/UDP/Internet knowledge. > > What about firewalls-faq@interhack.net named in the FAQ? > Maybe it's much better that I send an email to this email address to be sure > that I'm the only one translating it and not somebody else just finished a > translation. Or give me an email address in your reply I could use to > contact you. > > > |
Re: Internet Firewall FAQ in Dutch
On Mon, 7 Feb 2005 23:55:51 -0800, "William L. Sun" <88sun@cox.net>
wrote: >Thank you very much for your help. Here is the english version. Please consider NOT spamming newsgroups with this in future. -- Jim Watt http://www.gibnet.com |
Re: Internet Firewall FAQ in Dutch
"William L. Sun" <88sun@cox.net> wrote in message news:Kg_Nd.11878$6u.5041@fed1read02... > Thank you very much for your help. Here is the english version. Please take > your time to do it. I'll send the translated FAQ to firewalls-faq@interhack.net |
Re: Internet Firewall FAQ in Dutch
"Jim Watt" <jimwatt@aol.no_way> wrote in message news:l3ug01pn69jtrlmnr06i1pfkah8vh3v0s5@4ax.com... > On Mon, 7 Feb 2005 23:55:51 -0800, "William L. Sun" <88sun@cox.net> > wrote: > > >Thank you very much for your help. Here is the english version. > > Please consider NOT spamming newsgroups with this in future. it's a FAQ so please shut up. I consider it NOT as spamming and! it is the best readable FAQ :-). |
| All times are GMT. The time now is 03:40 AM. |
Powered by vBulletin®. Copyright ©2000 - 2013, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.