Internet Firewall FAQ in Dutch

Discussion in 'Computer Security' started by William L. Sun, Feb 6, 2005.

  1. Firewall FAQ in Nederlands Deel 1
    De Firewalls van Internet:
    Vaak Gestelde Vragen
    Paul D. Robertson
    Matte Curtin
    Marcus J. Ranum
    (vertaald door William Sun
    )


    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
    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/brannmur/brannmur-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/listinfo/firewall-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 in@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/assignments/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/manuals/security/sslin/contents.htm
    ... firewall7
    http://www.real.com/firewall/
    ... bugtraq8
    http://www.securityfocus.com
    ... online.9
    http://www.thegild.com/firewall/.
     
    William L. Sun, Feb 6, 2005
    #1
    1. Advertising

  2. "William L. Sun" <> 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.
     
    you mean dutch?, Feb 6, 2005
    #2
    1. Advertising

  3. 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?" <> wrote in message
    news:...
    > "William L. Sun" <> 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.
    >
    >
     
    William L. Sun, Feb 6, 2005
    #3
  4. William L. Sun

    Guest

    How about the ENGLISH one?!

    On Sun, 6 Feb 2005 11:23:30 -0800, "William L. Sun" <>
    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?" <> wrote in message
    >news:...
    >> "William L. Sun" <> 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 :)
     
    , Feb 7, 2005
    #4
  5. "William L. Sun" <> 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 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.
     
    you mean dutch?, Feb 7, 2005
    #5
  6. William L. Sun

    Moe Trin Guest

    In article <>,
    lid 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
     
    Moe Trin, Feb 7, 2005
    #6
  7. 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
    Matt Curtin
    Marcus J. Ranum


    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
    . 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/brannmur/brannmur-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/listinfo/firewall-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
    in@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/assignments/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/manuals/security/sslin/contents.htm
    ... firewall7
    http://www.real.com/firewall/
    ... bugtraq8
    http://www.securityfocus.com
    ... online.9
    http://www.thegild.com/firewall/.




    ==============

    "you mean dutch?" <> wrote in message
    news:...
    > "William L. Sun" <> 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 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.
    >
    >
    >
     
    William L. Sun, Feb 8, 2005
    #7
  8. William L. Sun

    Jim Watt Guest

    On Mon, 7 Feb 2005 23:55:51 -0800, "William L. Sun" <>
    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
     
    Jim Watt, Feb 8, 2005
    #8
  9. "William L. Sun" <> 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
     
    you mean dutch?, Feb 8, 2005
    #9
  10. William L. Sun

    sakura Guest

    "Jim Watt" <_way> wrote in message
    news:...
    > On Mon, 7 Feb 2005 23:55:51 -0800, "William L. Sun" <>
    > 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 :).
     
    sakura, Feb 8, 2005
    #10
  11. That is great. Could you please cc it to ? Thank you very much!
    "you mean dutch?" <> wrote in message
    news:...
    >
    > "William L. Sun" <> 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
    >
    >
    >
    >
     
    William L. Sun, Feb 9, 2005
    #11
  12. "William L. Sun" <> wrote in message
    news:FrjOd.12297$6u.7174@fed1read02...
    > That is great. Could you please cc it to ? Thank you very

    much!

    no. I'm not willing to send it by email anymore, not even a post in a
    newsgroup.
    Some people ( Jim Watt, winged ) are writing a lot of negative stuff about
    your posting in other newsgroups. So, I did some research; joined some other
    newsgroups. Yes, the next time I'm offering something I'll do that first.

    You are not named on http://www.compuwar.net/pubs/fwfaq/ or
    http://www.interhack.net/pubs/fwfaq/;
    your email address isn't linked to interhack or compuwar, you are not a
    contributor, etc.
    There is a norwegian FAQ, but that one isn't post in the newsgroups!! I'm
    not willing to translate 42 pages just for your fun. I thought it was
    serious.

    Thanks winged and Jim, you saved me a lot of translation time. I did read a
    lot of the FAQ and I think it could be half the lenght as it is today. It
    has a lot of Unix stuff in it and not much M$ (= windows) related. I don't
    agree with the writings about DMZ or even about the firewall basics. There
    must be information in the FAQ about the one way XP firewall ( a terrible
    construction and why it's terrible. To much people say "I have a firewall
    protecting me"; but have lots of active trojans on there pc because XP isn't
    interested in blocking outgoing information. You could stop the M$
    phone-home information ;-)).
    I miss the today's combination router and firewall; much attacks are
    blocked by the router and not by the firewall. The FAQ gives a lot of
    information about routers, but not enough ( VPN is missing ; wireless
    security is missing)

    >> We wrote this FAQ for computer systems developers and administrators (

    FAQ 1.2 )

    okee, but if there security knowledge is that low they should have end-user
    privilages and NO administrator rights (never!).
    I think the FAQ was good 10 years ago but not for today's security.
     
    ypu mean dutch?, Feb 9, 2005
    #12
  13. William L. Sun

    Jim Watt Guest

    On Wed, 9 Feb 2005 11:17:16 +0100, "ypu mean dutch?" <>
    wrote:

    >I think the FAQ was good 10 years ago but not for today's security.


    Nothing against those who speak languages other than English
    but newgroups are really for discussion rather than lengthy reference
    material in multiple languages and machine translation generates
    spam rather than useful information.
    --
    Jim Watt
    http://www.gibnet.com
     
    Jim Watt, Feb 9, 2005
    #13
  14. William L. Sun

    Guest

    In alt.computer.security Jim Watt <_way> wrote:
    > Nothing against those who speak languages other than English
    > but newgroups are really for discussion rather than lengthy reference
    > material in multiple languages and machine translation generates
    > spam rather than useful information.


    Perhaps you ought to reconsider your definition of "spam."

    It does not mean "stuff I do not want to read."

    -E
     
    , Feb 9, 2005
    #14
  15. William L. Sun

    Jim Watt Guest

    On Wed, 09 Feb 2005 09:01:25 -0600, wrote:

    >In alt.computer.security Jim Watt <_way> wrote:
    >> Nothing against those who speak languages other than English
    >> but newgroups are really for discussion rather than lengthy reference
    >> material in multiple languages and machine translation generates
    >> spam rather than useful information.

    >
    >Perhaps you ought to reconsider your definition of "spam."


    I know a lot about it and wrote a Spam analysis program
    in 1969, errr what were you doing at the time?

    >It does not mean "stuff I do not want to read."


    The stuff posted is stuff nobody wants to read and is
    inappropriate content.

    --
    Jim Watt
    http://www.gibnet.com
     
    Jim Watt, Feb 9, 2005
    #15
  16. In article <>,
    Jim Watt <_way> wrote:
    :On Wed, 09 Feb 2005 09:01:25 -0600, wrote:

    :>Perhaps you ought to reconsider your definition of "spam."

    :I know a lot about it and wrote a Spam analysis program
    :in 1969, errr what were you doing at the time?

    What were you doing writing a Spam analysis program before the
    first spam existed?

    http://www.multicians.org/thvv/mail-history.html

    "There was an earlier mass electronic mail message sent to a large
    community of unwilling readers [my definition of spam] that predates
    the 1978 DEC spam. This message was sent using CTSS MAIL about 1971, at
    a time of campus unrest and anti-war rallies."

    The first IMPs weren't even delivered until August 1969, and though
    MIT's single-system email system predates that, there is no
    recorded history of spam before 1971, and no recorded history
    of commercial spam before 1978.
    --
    Caution: A subset of the statements in this message may be
    tautologically true.
     
    Walter Roberson, Feb 9, 2005
    #16
  17. William L. Sun

    Guest

    In alt.computer.security Jim Watt <_way> wrote:
    > I know a lot about it and wrote a Spam analysis program
    > in 1969, errr what were you doing at the time?


    You a time traveller?

    Spam dates back at *best* to the late 70's.

    I have personally been an ardent spamfighter since the mid 90's. I know
    what the stuff is, and what it is not.

    > >It does not mean "stuff I do not want to read."

    >
    > The stuff posted is stuff nobody wants to read and is
    > inappropriate content.


    "Inappropriate content" != "Spam."

    Some inappropriate content is Spam. What you were complaining about was
    not Spam. It was noise.

    Such overuse of the label "Spam" dilutes the meaning of the term.

    -Ed
     
    , Feb 10, 2005
    #17
  18. William L. Sun

    Jim Watt Guest

    On Thu, 10 Feb 2005 09:42:52 -0600, wrote:

    >In alt.computer.security Jim Watt <_way> wrote:


    >> I know a lot about it and wrote a Spam analysis program
    >> in 1969, errr what were you doing at the time?

    >
    >You a time traveller?
    >
    >Spam dates back at *best* to the late 70's.


    1937 to be precise.

    >I have personally been an ardent spamfighter since the mid 90's.


    Ah a newcomer to computers.

    >I know what the stuff is, and what it is not.


    Clearly you don't.

    `When I use a word,' Humpty Dumpty said, in rather a scornful tone,
    `it means just what I choose it to mean -- neither more nor less.'

    `The question is,' said Alice, `whether you can make words mean so
    many different things.'
    --
    Jim Watt
    http://www.gibnet.com
     
    Jim Watt, Feb 10, 2005
    #18
  19. William L. Sun

    Moe Trin Guest

    Followup-To: set to comp.security.misc

    In article <>, wrote:

    >Perhaps you ought to reconsider your definition of "spam."


    Why? There is a perfectly adequate on posted weekly to
    news.admin.net-abuse.bulletins,
    news.admin.net-abuse.usenet,
    news.admin.net-abuse.sightings,
    news.admin.net-abuse.misc,
    news.answers

    called "FAQ: Current Usenet spam thresholds and guidelines" (all 162
    lines of it). By that document, this junk didn't hit the definition of
    spam, only because it was only spewed to a "few" groups. It's certainly
    going to hit the BI=20 threshold if posted again (it's at 13 in seven
    days by my count right now).

    The idiot posted the same articles to multiple newsgroups, without
    bothering to see if this was normal or on-topic for those groups, never
    mind setting a followup header. I also notice that he doesn't seem to
    have paid attention to earlier negative responses a week ago in the group
    'comp.security.firewalls' where it probably was somewhat closer to being
    on topic though equally unwanted. The fact that it seems to be a poorly
    written document incompetently "translated" isn't relevant to the _spam_
    issue though certainly relevant to the _abuse_ issue. But it's obviously
    a classic example of wasted bandwidth.

    He posted from a cable connection - hopefully Cox canceled his account
    for abuse complaints - ignoring the fact that the documents are seen
    world wide, and that some people don't have wide bandwidth connections,
    and that some people AND COMPANIES pay for the number of bytes received.

    Old guy
     
    Moe Trin, Feb 10, 2005
    #19
  20. William L. Sun

    Guest

    In alt.computer.security Jim Watt <_way> wrote:
    > >I have personally been an ardent spamfighter since the mid 90's.

    >
    > Ah a newcomer to computers.


    Nope. I've been using these things a lot longer than that. Apparently
    reading comprehension is not your strong point.

    > >I know what the stuff is, and what it is not.

    >
    > Clearly you don't.
    >
    > `When I use a word,' Humpty Dumpty said, in rather a scornful tone,
    > `it means just what I choose it to mean -- neither more nor less.'
    >
    > `The question is,' said Alice, `whether you can make words mean so
    > many different things.'


    If you insist on making up new meanings for words that are at odds with
    the accepted definitions, you will continue to have difficulty communicating
    effectively with others.

    -Ed
     
    , Feb 11, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Harrison

    FAQ - Use Windows XP Firewall

    Harrison, Oct 20, 2003, in forum: Computer Support
    Replies:
    10
    Views:
    703
  2. William L. Sun

    Internet Firewall FAQ in Italian

    William L. Sun, Feb 6, 2005, in forum: Computer Security
    Replies:
    6
    Views:
    1,539
  3. William L. Sun

    Internet Firewall FAQ in French

    William L. Sun, Feb 6, 2005, in forum: Computer Security
    Replies:
    0
    Views:
    2,246
    William L. Sun
    Feb 6, 2005
  4. William L. Sun

    Internet Firewall FAQ in German

    William L. Sun, Feb 6, 2005, in forum: Computer Security
    Replies:
    0
    Views:
    1,772
    William L. Sun
    Feb 6, 2005
  5. William L. Sun

    Internet Firewall FAQ in Portuguese

    William L. Sun, Feb 6, 2005, in forum: Computer Security
    Replies:
    0
    Views:
    1,524
    William L. Sun
    Feb 6, 2005
Loading...

Share This Page