Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Computer Security (http://www.velocityreviews.com/forums/f38-computer-security.html)
-   -   Internet Firewall FAQ in Dutch (http://www.velocityreviews.com/forums/t306354-internet-firewall-faq-in-dutch.html)

William L. Sun 02-06-2005 12:51 AM

Internet Firewall FAQ in Dutch
 
Firewall FAQ in Nederlands Deel 1
De Firewalls van Internet:
Vaak Gestelde Vragen
Paul D. Robertson paul@compuwar.net
Matte Curtin cmcurtin@interhack.net
Marcus J. Ranum mjr@ranum.com
(vertaald door William Sun sun@thegild.com
)


Datum: 2004/07/26 15:34:42
Revisie: 10.4

Dit document beschikbaar in Postscriptumand PDF.




Inhoud
1 Administrativia
1.1 Over FAQ
1.2 Voor wie wordt FAQ geschreven?
1.3 Alvorens Post Te verzenden
1.4 Waar kan ik de Huidige Versie van FAQ vinden?
1.5 Waar kan ik niet Engelse Versies van FAQ vinden?
1.6 Medewerkers
1.7 Auteursrecht en Gebruik


2 Achtergrond en van de Firewall Grondbeginselen
2.1 Wat is een netwerkfirewall?
2.2 Waarom zou ik een firewall willen?
2.3 Wat kan een firewall tegen beschermen?
2.4 Wat niet kan een firewall tegen beschermen?
2.5 Wat over virussen en andere malware?
2.6 Zal IPSEC firewalls verouderd maken?
2.7 Wat zijn goede bronnen van af:drukken informatie over firewalls?
2.8 Waar kan ik meer informatie over firewalls op Internet krijgen?


3 De Kwesties van het ontwerp en van de Implementatie
3.1 Wat zijn enkele basisontwerpbesluiten in een firewall?
3.2 Wat zijn de basistypes van firewalls?
3.3 Wat zijn volmachtsservers en hoe werken zij?
3.4 Wat zijn sommige goedkope hulpmiddelen van het pakketonderzoek?
3.5 Wat zijn sommige redelijke het filtreren regels voor het op
pit-gebaseerd pakketscherm?
3.6 Wat zijn sommige redelijke het filtreren regels voor een Cisco?
3.7 Wat zijn de kritieke middelen in een firewall?
3.8 Wat is een DMZ, en waarom ik wil één?
3.9 Hoe ik de veiligheid en scalability van mijn DMZ zou kunnen
verhogen?
3.10 Wat is één enkel punt ` van mislukking ', en hoe vermijd ik
hebbend?
3.11 Hoe kan ik het elk van slecht materiaal blokkeren?
3.12 Hoe kan ik Web beperken toegang zodat kunnen de gebruikers niet
niet verwante plaatsen om te werken bekijken?


4 Diverse Aanvallen
4.1 Wat is bron geleid verkeer en waarom is het een bedreiging?
4.2 Wat zijn ICMP opnieuw richten en opnieuw richten bommen?
4.3 Wat over ontkenning van de dienst?
4.4 Wat zijn sommige gemeenschappelijke aanvallen, en hoe kan ik mijn
systeem tegen hen beschermen?


5 Hoe ik...
5.1 Wil ik werkelijk toestaan alles die mijn gebruikers om vragen?
5.2 Hoe maak ik Web/het werk van HTTP door mijn firewall?
5.3 Hoe maak ik SSL het werk door de firewall?
5.4 Hoe maak ik DNS het werk met een firewall?
5.5 Hoe maak ik het werk van FTP door mijn firewall?
5.6 Hoe maak ik het werk van Telnet door mijn firewall?
5.7 Hoe maak ik Vinger en whois door mijn firewall werken?
5.8 Hoe maak ik gopher, Archie, en werken andere diensten door mijn
firewall?
5.9 Wat zijn de kwesties over X11 door een firewall?
5.10 Hoe maak ik RealAudio door mijn firewall werken?
5.11 Hoe maak ik mijn Webserver als voorkant voor een dienst doen
gegevensbestand dat op mijn privé netwerk leeft?
5.12 Maar mijn gegevensbestand heeft een geïntegreerde Webserver, en
ik wil dat gebruiken. Kan ik niet een gat in de firewall en de tunnel die
haven enkel porren?
5.13 Hoe maak ik tot IP Multicast Werk met Mijn Firewall?


6 Havens TCP en UDP
6.1 Wat is een haven?
6.2 Hoe weet ik welke toepassing gebruikt welke haven?
6.3 Wat zijn het LUISTEREN havens?
6.4 Hoe bepaal ik welke dienst de haven voor is?
6.5 Welke havens zijn veilig om door een firewall over te gaan?
6.6 Het gedrag van FTP
6.7 Welke software gebruikt welke wijze van FTP?
6.8 Probeert mijn firewall buiten te verbinden?
6.9 De anatomie van een aansluting van TCP


A. Sommige Commerciële Producten en Verkopers
B. Verklarende woordenlijst van firewall-Verwante Termijnen
Bibliografie


1 Administrativia


1.1 Over FAQ
Deze inzameling van Frequenty stelde Vragen (FAQs) en de antwoorden is
gecompileerd over een periode van jaren, ziend welke vragenmensen over
firewalls in dergelijke forums zoals Usenet, adressenlijsten, en Websites
vragen. Als u een vraag hebt, hier kijkend om te zien of het alvorens uw
vraag te posten is goede vorm wordt beantwoord. Verzend uw vragen over
firewalls niet naar de handhavers FAQ.

De handhavers stemmen in met input en commentaren op de inhoud van dit
FAQ. De commentaren met betrekking tot FAQ zouden aan
firewall-faq@interhack.net moeten worden gericht. Alvorens u ons post
verzendt, gelieve te zijn zeker om secties 1.2 te zien en 1.3 om dit ervoor
te zorgen zijn het juiste document voor u om te lezen.



1.2 Voor wie wordt FAQ geschreven?
De firewalls zijn ver van de dagen gekomen toen dit FAQ begon. Zij
zijn van het zijn hoogst aangepaste systemen gegaan die door hun
implementors aan heersende stromingsgoederen worden beheerd. De firewalls
zijn niet meer alleen in de handen van zij die ontwerpen en
veiligheidssystemen uitvoeren; zelfs thuis hebben de veiligheid-bewuste
eindgebruikers hen.

Wij schreven dit FAQ voor computersystemenontwikkelaars en beheerders.
Wij hebben vrij inclusief geprobeerd te zijn, makend ruimte voor de
nieuwkomers, maar wij veronderstellen nog wat fundamentele technische
achtergrond. Als u vindt dat u dit document niet begrijpt, maar denk dat u
meer over firewalls moet kennen, zou het goed kunnen zijn dat u eigenlijk
meer achtergrond in computervoorzien van een netwerk eerste moet krijgen.
Wij verstrekken verwijzingen die ons hebben geholpen; misschien zullen zij u
ook helpen.

Wij concentreren ons overwegend op "netwerk" firewalls, maar `` de
gastheer '' of ``"personal'' firewalls zal worden gericht waar aangewezen.



1.3 Alvorens Post Te verzenden
Merk op dat deze inzameling van vaak-gevraagde vragen een resultaat
van het in wisselwerking staan met vele mensen van verschillende
achtergronden in een grote verscheidenheid van openbare forums is. Het
firewalls -firewall-faqadres is geen helpdesk. Als u probeert om een
toepassing te gebruiken die zegt dat het niet wegens een firewall werkt en u
denkt dat u uw firewall moet verwijderen, te verzenden gelieve ons geen post
vragend hoe.

Als u hoe te `` wilt kennen doe uw firewall '' van de hand omdat u één
of andere toepassing niet **** gebruiken, verzendt ons geen post vragend om
hulp. Wij kunnen u helpen niet. Werkelijk.

Wie kan u helpen? Goede vraag. Dat zal afhangen van wat precies het
probleem is, maar is hier verscheidene wijzers. Als geen van deze werken,
gelieve ons om meer geen te vragen. Wij weten niet het.

De leverancier van de software u gebruikt.
De leverancier van het hardware`` toestel '' u gebruikt.
De leverancier van de netwerkdienst u gebruikt. Namelijk als u op AOL
bent, vraag hen. Als u probeert om iets op een collectief netwerk te
gebruiken, bespreking aan uw systeembeheerder.


1.4 Waar kan ik de Huidige Versie van FAQ vinden?
FAQ kan op het Web bij worden gevonden

http://www.compuwar.net/pubs/fwfaq/.
http://www.interhack.net/pubs/fwfaq/.
Het wordt ook gepost maandelijks aan

comp.security.firewalls,
comp.security.unix,
comp.security.misc,
comp.answers, en
news.answers.
De geposte versies worden gearchiveerd in alle gebruikelijke plaatsen.
Jammer genoeg, de versie die aan Usenet wordt gepost en die van dat
versiegebrek de mooie beelden en de nuttige hyperlinks wordt gearchiveerd
die in de Webversie worden gevonden.



1.5 Waar kan ik niet Engelse Versies van FAQ vinden?
Verscheidene vertalingen zijn beschikbaar. (Als u een vertaling hebt
gedaan en het niet hier vermeld is, te schrijven gelieve ons zodat kunnen
wij het hoofddocument bijwerken.)


Noors
Vertaling door Jon Haugsand
http://helmersol.nr.no/haandbok/doc/...nnmur-faq.html


1.6 Medewerkers
Vele mensen hebben nuttige suggesties en nadenkende commentaar
geschreven. Wij zijn dankbaar aan alle medewerkers. We'd houdt van afew door
naam te danken: Keinanen ;Vesa, Allen Leibowitz, Brent Chapman, Hoop Brian
Boyle, D. Clyde Williamson, Richard Reiner, William Sun, Humberto Ortiz
Zuazaga, en Theodore.



1.7 Auteursrecht en Gebruik
Auteursrecht ©1995-1996, 1998 Marcus J. Ranum. Auteursrecht ©1998-2002
Matte Curtin. Auteursrecht 2004, Paul D. Robertson. Alle voorgebe*houde
rechten. Dit document kan worden gebruikt, worden herdrukt en, worden
opnieuw verdeeld zoals deze verklaring inzake auteursrecht en alle
toewijzingen intact blijven verstrekt. De vertalingen van de volledige tekst
van de originele Engelsen aan andere talen worden ook uitdrukkelijk
toegestaan. De vertalers kunnen hun namen aan de sectie van de ``-
Medewerkers ' toevoegen.



2 Achtergrond en van de Firewall Grondbeginselen
Alvorens een volledige bespreking van firewalls te kunnen begrijpen,
is het belangrijk om de basisprincipes te begrijpen die firewalls maken
werken.



2.1 Wat is een netwerkfirewall?
Een firewall is een systeem of een groep systemen dat een
toegangsbeheerbeleid tussen twee of meer netwerken afdwingen. Het
daadwerkelijke middel waardoor dit wordt verwezenlijkt verschilt sterk, maar
in principe, kan de firewall van als paar mechanismen worden gedacht: die
bestaan om verkeer te blokkeren, en andere die bestaat om verkeer toe te
laten. Sommige firewalls leggen een grotere nadruk bij het blokkeren van
verkeer, terwijl anderen het toelaten van verkeer benadrukken.
Waarschijnlijk is het belangrijkste ding over een firewall te erkennen dat
het een toegangsbeheerbeleid uitvoert. Als u geen goed idee hebt van welk
soort toegang u wilt toestaan of ontkennen, zal een firewall u niet
werkelijk helpen. Het is ook belangrijk om te erkennen dat de configuratie
van de firewall, omdat het een mechanisme is om beleid af te dwingen, zijn
beleid aan alles achter het oplegt. Beheerders die voor firewalls de
connectiviteit voor een groot aantal gastheren de beheren hebben daarom een
zware verantwoordelijkheid.



2.2 Waarom zou ik een firewall willen?
Internet, zoals een andere maatschappij, wordt geteisterd met het
soort schokken die van het elektronische tearing equivalent van het
schrijven op de muren van andere mensen met weg spraypaint genieten, hun
brievenbussen, of enkel zittend in de straat die hun autohoornen blaast.
Sommige mensen proberen om het echte werk dat over Internet wordt gedaan te
krijgen, en anderen hebben gevoelige of merkgebonden gegevens zij moeten
beschermen. Gewoonlijk, het doel van een firewall is de schokken van uw
netwerk weg te houden terwijl nog het laten van u uw baan gedaan krijgen.

Vele bedrijven en gegevenscentra in traditionele stijl hebben
gegevensverwerkingsveiligheidsbeleid en praktijken dat moeten worden
gevolgd. In een geval waar het beleid van een bedrijf dicteert hoe de
gegevens moeten worden beschermd, is een firewall zeer belangrijk, aangezien
het de belichaming van het collectieve beleid is. Vaak, rechtvaardigt het
hardste deel van het vasthaken aan Internet, als u een groot bedrijf bent,
de uitgave of de inspanning, maar geen overtuigend beheer dat het veilig is
dit te doen. Een firewall verstrekt niet alleen echte veiligheid -- het
speelt vaak een belangrijke rol als veiligheidsdeken voor beheer.

Ten slotte, kan een firewall als uw collectieve `` ambassadeur '' aan
Internet dienst doen. Vele bedrijven gebruiken hun firewallsystemen als
plaats om openbare informatie over collectieve producten en de diensten, te
downloaden dossiers op te slaan, insect-moeilijke situaties, enzovoort.
Verscheidene van deze systemen zijn belangrijke delen van de de
dienststructuur van Internet (b.v., UUnet.uu.net ,whitehouse.gov
,gatekeeper.dec.com )geworden en goed hun organisatorische sponsors
overdacht. Merk op dat terwijl dit historisch waar is, de meeste
organisaties nu openbare informatie over een server van het Web plaatsen,
die vaak door een firewall wordt beschermd, maar niet normaal over de
firewall zelf.



2.3 Wat kan een firewall tegen beschermen?
Sommige firewalls laten slechts e-mailverkeer door hen toe, daardoor
beschermend het netwerk tegen om het even welke aanvallen buiten aanvallen
tegen de e-maildienst. Andere firewalls bieden minder strikte bescherming,
en de blokdiensten die gekend om problemen zijn te zijn.

Over het algemeen, worden de firewalls gevormd om tegen niet
bekrachtigde interactieve logins van `` buiten wereld te beschermen ''. Dit,
meer dan om het even wat, hulp verhindert vandalen registreren in machines
op uw netwerk. De gedetailleerdere firewalls blokkeren verkeer van de
buitenkant aan de binnenkant, maar laten gebruikers op de binnenkant toe om
vrij met de buitenkant te communiceren. De firewall kan u tegen om het even
welk type van netwerk-gedragen aanval beschermen als u het afsluit.

De firewalls zijn ook belangrijk aangezien zij één enkel ``
vernauwingspunt '' kunnen verstrekken waar de veiligheid en de controle
kunnen worden opgelegd. In tegenstelling tot in een situatie waar een
computersysteem door iemand aangevallen wordt dat met een modem inkiest, kan
de firewall als efficiënte `` telefoonkraan '' en vindend hulpmiddel dienst
doen. De firewalls verstrekken een belangrijke het registreren en
controlefunctie; vaak verstrekken zij samenvattingen aan de beheerder over
welke soorten en hoeveelheid verkeer door het overging, hoeveel pogingen er
in het, enz. te breken waren.

Wegens dit, zijn de firewalllogboeken kritisch belangrijke gegevens.
Zij kunnen als bewijsmateriaal in een hof van wet in de meeste landen worden
gebruikt. U zou de logboeken van de yorufirewall beschermen analyseren en
dienovereenkomstig moeten beschermen.

Dit is een belangrijk punt: het verstrekken van dit `` vernauwingspunt
'' kan het zelfde doel op uw netwerk dienen dat een bewaakte poort voor het
fysieke gebouw van uw plaats kan. Dat betekent u om het even wanneer een
verandering in streken `` ' hebt of de niveaus van gevoeligheid, een
dergelijke controlepost aangewezen is. Een bedrijf heeft slechts een
buitenpoort en zelden geen receptionnist of veiligheidspersoneel om
kentekens op de manier in te controleren. Als er lagen van veiligheid op uw
plaats zijn, is het redelijk om lagen van veiligheid op uw netwerk te
verwachten.



2.4 Wat niet kan een firewall tegen beschermen?
De firewalls kunnen tegen aanvallen beschermen niet die niet door de
firewall gaan. Vele bedrijven die met Internet verbinden zijn zeer betrokken
over merkgebonden gegevens die uit het bedrijf door die route lekken. Jammer
genoeg voor betroffen die, kunnen een magnetische band, een compact disc,
DVD, of USB de flitsaandrijving enkel zoals effectief om gegevens worden
gebruikt uit te voeren. Vele organisaties die (op een beheersniveau) van de
aanslutingen angst aangejaagd zijn van Internet hebben geen coherent beleid
over hoe wijzerplaat-in toegang via modems zou moeten worden beschermd. Het
is dwaas om een zes-voet dikke staaldeur te bouwen wanneer u in een houten
huis leeft, maar er zijn heel wat organisaties die daar dure firewalls kopen
en talrijk veronachtzamen andere achter-deuren in hun netwerk. Voor een
firewall om te werken, moet het een deel van een verenigbare algemene
organisatorische veiligheidsarchitectuur zijn. Het beleid van de firewall
moet realistisch zijn en op het niveau van veiligheid in het volledige
netwerk wijzen. Bijvoorbeeld, vergt een plaats met hoogste geheime of
geclassificeerde gegevens een firewall helemaal niet: zij zouden niet tot
Internet in de eerste plaats moeten vasthaken, of de systemen met de
werkelijk geheime gegevens zouden van de rest van het collectieve netwerk
moeten worden geïsoleerd.

Een ander ding een firewall niet kan werkelijk beschermen u tegen is
verraders of idioten binnen uw netwerk. Terwijl een industriële spion
informatie door uw firewall zou kunnen uitvoeren, hij enkel waarschijnlijk
heeft om het door een een telefoon, machine van de FAX, of een Compact disc
uit te voeren. CDs zijn een veel waarschijnlijker middel voor informatie om
van uw organisatie te lekken dan een firewall. De firewalls kunnen ook niet
u tegen stompzinnigheid beschermen. De gebruikers die gevoelige informatie
over de telefoon openbaren zijn goede doelstellingen voor sociale techniek;
een aanvaller kan in uw netwerk kunnen breken door uw firewall volledig te
mijden, als hij kan vinden een werknemer `` nuttige '' binnen wie kan zijn
in het geven van toegang tot een modempool fooled. Alvorens dit te beslissen
geen probleem in uw organisatie is, vraag me hoeveel probleem een
contractant wordt geregistreerd het worden die in het netwerk heeft of
hoeveel moeilijkheid een gebruiker die zijn wachtwoord vergat teruggesteld
het krijgen van het heeft. Als de mensen op de helpdesk geloven dat elke
vraag intern is, hebt u een probleem dat niet kan worden bevestigd door
controles op de firewalls aan te halen.

De firewalls kunnen beschermen niet tegen het een tunnel graven over
de meeste toepassingsprotocollen aan trojaned of slecht geschreven cliënten.
Er zijn geen magische kogels en een firewall is geen verontschuldiging
softwarecontroles op interne netwerken niet om uit te voeren of
gastheerveiligheid op servers te negeren. Een tunnel gravend dingen ``
slechte '' over HTTP, zijn SMTP, en andere protocollen vrij eenvoudig en
onbelangrijk aangetoond. De veiligheid is geen brand `` en vergeet ''.

Ten slotte, kunnen de firewalls tegen slechte dingen die beschermen
niet door hen worden toegestaan. Bijvoorbeeld, gebruiken vele Trojan Paarden
het protocol van het Relais van Internet van het Praatje (IRC) om een
aanvaller toe te staan om een gecompromitteerde interne gastheer van een
openbare server te controleren IRC. Als u om het even welk intern systeem om
met om het even welk extern systeem toestaat te verbinden, dan zal uw
firewall geen bescherming tegen deze vector van aanval bieden.



2.5 Wat over virussen en andere malware?
De firewalls kunnen zeer goed tegen dingen zoals virussen of
kwaadwillige software (malware) beschermen niet. Er zijn teveel manieren om
binaire dossiers voor overdracht over netwerken te coderen, en teveel
verschillende architectuur en virussen proberen om naar hen allen te zoeken.
Met andere woorden, kan een firewall veiligheid-bewustzijn namens uw
gebruikers vervangen niet. In het algemeen, kan een firewall tegen een
gegeven-gedreven aanval beschermen niet -- aanvallen waarin iets wordt
gepost of aan een interne gastheer gekopieerd waar het dan wordt uitgevoerd.
Deze vorm van aanval is in het verleden tegen diverse versies van sendmail
,ghostscript voorgekomen, scripting de agenten van de postgebruiker zoals
Vooruitzichten, en browsers van het Web zoals de Ontdekkingsreiziger van
Internet.

De organisaties die diep bezorgd over virussen zijn zouden
organization-wide viruscontrolemaatregelen moeten ten uitvoer leggen. Eerder
dan slechts het uitproberen aan het schermvirussen bij de firewall, zorg
ervoor dat elke kwetsbare Desktop de software heeft van het virusaftasten
die in werking wordt gesteld wanneer de machine wordt gereboot. Het bedekken
van uw netwerk met de software van het virusaftasten zal tegen virussen
beschermen die binnen via floppy disks, CDs, modems, en Internet komen. Het
proberen zal om virussen bij de firewall te blokkeren slechts tegen virussen
van Internet beschermen. Het aftasten van het virus bij de firewall of
e-mailgateway zal een groot aantal besmettingen tegenhouden.

Niettemin, biedt een stijgend aantal firewallverkopers virus `` aan
ontdekkend firewalls ''. Zij zijn waarschijnlijk slechts nuttig voor naïeve
gebruikers die uitvoerbare programma's venster-op-Intel en
kwaadwillig-macro-geschikt toepassingsdocumenten ruilen. Er zijn vele op
firewall-gebaseerde benaderingen voor het behandelen van problemen zoals de
worm `` ILOVEYOU '' en de verwante aanvallen, maar dit zijn werkelijk te
eenvoudig voorgestelde benaderingen die proberen om de schade van iets te
beperken die het nooit zou moeten in de eerste plaats voorgekomen zijn zo
stom is. Tel niet op enige bescherming tegen aanvallers met deze eigenschap.
(Aangezien `` ILOVEYOU '' rond ging, hebben wij gezien minstens een
gelijkaardig half dozijn, met inbegrip van Melissa, Happy99 aanvalt, Rood,
en Badtrans. B codeert, die gelukkig door velen werden overgegaan
virus-ontdekt firewalls en e-mailgateways.)

Een sterke firewall is nooit een substituut voor zinnige software die
de aard van wat behandelt het -- onbetrouwbare gegevens van een niet
bekrachtigde partij -- erkent en zich geschikt gedraagt. Denk niet dat omdat
`` iedereen '' gebruikt dat mailer of omdat de verkoper een gargantuesk
multinationaal bedrijf is, u veilig bent. In feite, is het niet waar dat ``
iedereen '' om het even welke mailer gebruikt, en de bedrijven die zich in
het veranderen van elders uitgevonden technologie in iets specialiseren dat
`` makkelijk te gebruiken '' zonder enige deskundigheid eerder zullen
software produceren die kan zijn fooled. De verdere overweging van dit
onderwerp zou lonend [ 3]zijn, maar is voorbij het toepassingsgebied van dit
document.



2.6 Zal IPSEC firewalls verouderd maken?
Sommigen hebben gedebatteerd dat dit het geval is. Alvorens een
dergelijke vegende voorspelling uit te spreken, echter, is het lonend om te
overwegen welke IPSEC is en wat het doet. Zodra wij dit kennen, kunnen wij
overwegen of IPSEC de problemen zal oplossen die wij proberen om met
firewalls op te lossen.

IPSEC (IP SECurity) verwijst naar een reeks normen die door de
Werkgroep van de Techniek van Internet (IETF) worden ontwikkeld. Er zijn
vele documenten die collectief bepalen wat `` IPSEC '' [ 6 ]genoemd
gewordenis. IPSEC lost twee problemen op die de IP protocolreeks jarenlang
hebben geteisterd: gastheer-aan-gastheer authentificatie (die gastheren
zullen laten weten dat zij aan de gastheren spreken die zij zij) hebben
gedacht zijn en encryptie (wat aanvallers zal verhinderen op het verkeer te
kunnen letten gaand tussen machines).

Merk op dat geen van beiden van deze problemen welke is firewalls om
werden gecreeerd op te lossen. Hoewel de firewalls kunnen helpen om enkele
risico's te verlichten huidig op
Internet zonder authentificatie of encryptie, zijn er werkelijk twee
klassen hier van problemen: integriteit en privacy van de informatie
die tussen gastheren en de geplaatste grenzen stroomt op welke soorten
connectiviteit tussen verschillende netwerken wordt toegestaan.
IPSEC richt de eerstgenoemde klasse en de firewalls laatstgenoemde.

Wat dit betekent is dat één zal elimineren niet de behoefte aan
andere, maar het leidt tot sommige interessante mogelijkheden wanneer
wij het combineren van firewalls met ipsec-Toegelaten gastheren
bekijken. Namelijk, zullen dergelijke dingen zoals
verkoper-onafhankelijke virtuele privé netwerken (VPNs), het
betere pakket filtreren (door op of te filtreren de pakketten Ipsec-
authentificatieheader) hebben, en toepassing-laag firewalls betere
middelen van gastheercontrole kunnen hebben door Ipsec-
authentificatieheader in plaats van `` eigenlijk te gebruiken enkel
vertrouwend op '' het IP voorgestelde adres.



2.7 Wat zijn goede bronnen van af:drukken informatie over firewalls?
Er zijn verscheidene boeken die op firewalls betrekking hebben. Het
best het geweten is:

De bouw Firewalls van Internet, 2d ED. Authors Elizabeth D. Zwicky,
Simon Cooper, en ISBN 1-56592-871-7 van de Uitgave 2000 van de
Uitgever O'Reilly van D. Brent Chapman

Firewalls en de Veiligheid van Internet: Het afweren van de Wily
Auteurs Bill Cheswick, Steve Bellovin, Uitgave 2003 ISBN 020163466X
van de Hakker van Addison Wesley van de Uitgever van Avi
Rubin

De praktische Internet & Auteurs Simson Garfinkel van de
Veiligheid van Unix en ISBN 1-56592-148-8 van de Uitgave 1996 van
de Uitgever O'Reilly van Spafford van het Gen de Nota bespreken
hoofdzakelijk de veiligheid van de gastheer. De verwante verwijzingen
zijn:

Onderlinge verbinding van netwerken met TCP/IP Bezoeker van Douglas
van de Auteurs van Vols I, II, en de III en ISBN van David
Stevens Publisher Prentice-Hall Edition 1991 0-13-468505-9 (I),
0-13-472242-6 (II), 0-13-474222-2 (Iii) de Commentaar A
detailleerde bespreking over de architectuur en de implementatie van
Internet en zijn protocollen. Volume I (op principes, protocollen en
architectuur) is leesbaar door iedereen. Volume 2 (op ontwerp,
implementatie en internals) is technischer. Volume 3
dekkingsclient-server gegevensverwerking.

De Veiligheid van het Systeem van Unix -- een Gids voor ISBN
0-201-56327-4 van de Uitgave 1992 van David Curry Publisher Addison
Wesley van de Auteur van Gebruikers en van de Beheerders van het
Systeem


2.8 Waar kan ik meer informatie over firewalls op Internet krijgen?

Het Handboek http://www.rfc-editor.org/rfc/rfc2196.txt van de
Veiligheid van de plaats het Handboek van de Veiligheid van de Plaats
is een informatieIetf- document dat de basiskwesties beschrijft die
voor de bouw van goede plaatsveiligheid moeten worden behandeld. De
firewalls zijn één deel van een grotere veiligheidsstrategie, zoals
het Handboek van de Veiligheid van de Plaats toont. De Adressenlijst
http://www.isc.org/index.pl?/ops/lists/firewalls van firewalls/de
Internet firewalls adressenlijst zijn een forum voor
firewallbeheerders en implementors. Firewall-tovenaars is de
http://honor.icsalabs.com/mailman/li...wall-tovenaars van de
Adressenlijst de Adressenlijst van de Tovenaars van de Firewall een
gematigde firewall en een veiligheid verwante lijst die meer als een
dagboek dan een openbare soapbox is. De firewall HOWTO
http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html beschrijft precies
wat nodig is om een firewall te bouwen, in het bijzonder gebruikend
Linux. Toolkit van de firewall (FWTK) en de Documenten
ftp://ftp.tis.com/pub/firewalls van de Firewall/de verwante
publicaties http://www.ranum.com/pubs van Marcus Ranum's
firewall/Universitaire de veiligheidshulpmiddelen
http://www.net.tamu.edu/ftp/security/TAMU van Texas A&M/de pagina
http://www.cerias.purdue.edu/coast/firewalls van de Firewalls van
Internet van het Project van de KUST/


Back to Top
Firewall FAQ in Nederlands Deel 2
3 De Kwesties van het ontwerp en van de Implementatie


3.1 Wat zijn enkele basisontwerpbesluiten in een firewall?
Er zijn een aantal basisontwerpkwesties die door de gelukkige persoon
zouden moeten worden behandeld die met de verantwoordelijkheid om is belast,
op de installatie van een firewall in het leven te roepen te specificeren en
uit te voeren of toezicht te houden.

Het eerste en belangrijkste besluit vormt een weerspiegeling van het
beleid van hoe uw bedrijf of organisatie het systeem willen in werking
stellen: is vormt de firewall op zijn plaats uitdrukkelijk om alle diensten
behalve die kritiek aan de opdracht van het verbinden met Netto, of de
firewall op zijn plaats om een gemeten en gecontroleerde methode van ``
toegang een rij '' op een niet-dreigt manier te verstrekken te ontkennen? Er
zijn graden van paranoia tussen deze posities; de definitieve houding van uw
firewall zou meer het resultaat van politiek kunnen zijn dan een
techniekbesluit.

De tweede is: welk niveau van controle, overtolligheid, en controle
wilt u? Hebben duidelijk gemaaktd het aanvaardbare risiconiveau (d.w.z., hoe
paranoïde u) bent door de eerste kwestie op te lossen, **** 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 **** 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 **** nooit zeker zijn welke diensten u het letten van op
aanslutingen op hoge havenaantallen hebt. (U **** 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 **** 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 **** 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, **** 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 **** 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 **** 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 **** 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 **** smeden richt pakketten
opnieuw, en als uw doelgastheer aandacht aan hen besteedt, **** 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 **** veilig blokkeren overal, **** 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 **** 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 **** moeten verbergen is als u een niet genormaliseerde het
richten regeling op uw intern netwerk hebt. In dat geval, u geen keus dan
hebt om die adressen te verbergen. Niet dwaas zelf in het denken dat als uw
DNS namen verborgen zijn dat het een aanvaller onderaan veel zal vertragen
als zij in uw firewall breken. De informatie over wat op uw netwerk is wordt
te gemakkelijk verzameld van de voorzien van een netwerklaag zelf. Als u een
interessante demonstratie van dit, ping het subnet uitzendingsadres op uw
LAN wilt en dan een `` arp - ` a.' ' doet Merk ook op dat het verbergen van
namen in DNS niet het probleem van gastheernamen `` uit lekkend '' in
postheaders, nieuwsartikelen, enz. aanpakt.

Deze benadering is één van velen, en is nuttig voor organisaties die
wensen om hun gastheernamen van Internet te verbergen. Het succes van deze
benadering ligt op het feit dat DNS de cliënten op een machine niet aan een
DNS server op die zelfde machine moeten spreken. Met andere woorden, enkel
omdat daar een DNS server op een machine, daar niets verkeerd met (en er
zijn vaak voordelen) het opnieuw richten van DNS van die machine
cliëntactiviteit aan een DNS server op een andere machine.

Eerst, zet u een DNS server op de bastion gastheer op wie kan spreken
de buitenwereld aan. U zet deze server op zodat het voor uw domeinen
gebiedend eist te zijn. In feite, weet al deze server is wat u de
buitenwereld wilt weten; de namen en de adressen van uw gateways, uw
vervangingsmx verslagen, enzovoort. Dit is de server `` openbare ''.

Dan, zet u een DNS server op een interne machine op. Deze server eist
ook gebiedend voor uw domeinen te zijn; in tegenstelling tot de openbare
server, dit vertelt men de waarheid. Dit is uw `` normale '' nameserver,
waarin u al uw `` normaal '' DNS materiaal zet. U plaatst ook deze server
tot voorwaartse vragen die het niet kan aan de openbare server die (een
forwarders' `` ' lijn in/een enz./een named.boot op een machine van Unix
gebruikt, bijvoorbeeld) oplossen.

Tot slot zet u al uw DNS cliënten ( / enz./ resolv.conf- dossier op
een vakje van Unix, bijvoorbeeld), met inbegrip van degenen op de machine
met de openbare server op, om de interne server te gebruiken. Dit is de
sleutel.

Een interne cliënt die over een interne gastheer vraagt vraagt de
interne server, en krijgt een antwoord; een interne cliënt die over een
externe gastheer vraagt vraagt de interne server, die de openbare server
vraagt, die Internet vraagt, en het antwoord wordt terug afgelost. Een
cliënt op de openbare server werkt enkel de zelfde manier. Een externe
cliënt die, echter, over een interne gastheer vraagt krijgt het `` beperkte
antwoord '' van de openbare server terug.

Deze benadering veronderstelt dat daar een pakket filtrerende firewall
tussen deze twee servers die hen zullen toestaan om DNS aan elkaar te
spreken, maar anders DNS tussen andere gastheren beperkt.

Een andere truc die nuttig in deze regeling is om vervangingsPtr-
verslagen in uw domeinen van ARPA aan te wenden in-ADDR.. Deze veroorzaken
een adres-aan-naam raadpleging voor om het even welk van uw niet-openbare
gastheren aan terugkeer iets als `` unknown.YOUR.DOMAIN '' eerder dan een
fout. Dit stelt de anonieme plaatsen van FTP zoals ftp.uu.net tevreden die
aandringen op het hebben van een naam voor de machines die zij hebben
gesproken aan. Dit kan ontbreken wanneer het spreken aan plaatsen die een
DNS kruiscontrole doen waarin de gastheernaam tegen zijn adres en vice versa
wordt aangepast.



5.5 Hoe maak ik het werk van FTP door mijn firewall?
Over het algemeen, wordt het maken van het werk van FTP door de
firewall gedaan of gebruikend een volmachtsserver zoals firewalltoolkit's
FTP-GW of door inkomende aanslutingen aan het netwerk bij een beperkte
havenwaaier toe te laten, en anders inkomende aanslutingen te beperken
gebruikend iets als `` vastgelegde '' onderzoeksregels. De cliënt van FTP
wordt dan gewijzigd om de gegevenshaven aan een haven binnen dat gamma te
binden. Dit brengt met zich mee kunnend de de cliënttoepassing van FTP op
interne gastheren wijzigen.

In sommige gevallen, als de downloads van FTP allen zijn wenst u te
steunen, zou u kunnen willen nadenken verklarend FTP een `` dood protocol ''
en latend u dient de gebruikersdownload in plaats daarvan via het Web in.
Het gebruikersinterface zeker is aardiger, en het krijgt rond het lelijke
callback havenprobleem. Als u de fTP-via-Web benadering kiest, zullen uw
gebruikers aan FTP- dossiers uit onbekwaam zijn, die, afhankelijk van wat u
probeert om te verwezenlijken, een probleem kunnen zijn.

Een verschillende benadering is de optie PASV '' te gebruiken van FTP
`` om erop te wijzen dat de verre server van FTP de cliënt zou moeten
toelaten om aanslutingen in werking te stellen. De benadering PASV
veronderstelt dat de server van FTP op de verre systeemsteunen die
verrichting. (Zie `` firewall-Vriendschappelijk FTP '' [1].)

Andere plaatsen verkiezen cliëntversies van het FTP- programma te
bouwen die tegen een bibliotheek van SOKKEN verbonden zijn.



5.6 Hoe maak ik het werk van Telnet door mijn firewall?
Telnet wordt over het algemeen gesteund of door een
toepassingsvolmacht zoals firewalltoolkit's tn-GW te gebruiken, of door een
router eenvoudig te vormen om uitgaande aanslutingen toe te laten gebruikend
iets als de `` vastgelegde '' onderzoeksregels. Volmachten van de toepassing
zouden in de vorm van een standalone volmacht die op de bastion gastheer
loopt, of in de vorm van een server van SOKKEN en een gewijzigde cliënt
kunnen zijn.



5.7 Hoe maak ik Vinger en whois door mijn firewall werken?
Vele firewall admins laat aanslutingen aan de vingerhaven van toe
slechts vertrouwde op machines, die vingerverzoeken in de vorm van kunnen
uitgeven: vinger user@host.domain@firewall. Deze benadering werkt slechts
met de standaardversie van Unix van vinger. De controlerende toegang tot de
diensten en het beperken van hen tot specifieke machines wordt beheerd
gebruikend of tcp_wrappers of netacl van firewalltoolkit. Deze benadering
zal niet werken aan alle systemen, aangezien sommige vingerservers
user@host@host geen vingertechniek toelaten.

Vele plaatsen blokkeren binnenkomende vingerverzoeken om een
verscheidenheid van redenen, het belangrijkste zijn afgelopen
veiligheidsinsecten in de vingerserver (de worm van Morris maakte Internet
deze insecten beroemd) en het risico van merkgebonden of gevoelige
informatie die in de vingerinformatie van de gebruiker wordt geopenbaard. In
het algemeen, echter, als uw gebruikers gebruikelijk zijn aan het zetten van
merkgebonden of gevoelige informatie in hun plan dossiers, hebt u een
ernstiger veiligheidsprobleem dan enkel een firewall kan oplossen.



5.8 Hoe maak ik gopher, Archie, en werken andere diensten door mijn
firewall?
De meerderheid van firewallbeheerders verkiest om gopher en Archie
door Webvolmachten, in plaats van direct te steunen. De volmachten zoals
firewalltoolkit's HTTP-GW zetten gopher/gopher + vragen in HTML om en vice
versa. Voor het steunen van Archie en andere vragen, baseren vele plaatsen
zich op op Internet-Gebaseerde servers Web-aan-Archie, zoals ArchiePlex. De
tendens van het Web om alles op Internet te maken als de Webdienst kijken is
zowel een zegen als een vloek.

Er zijn vele nieuwe diensten die constant opduiken. Vaak zijn zij
misdesigned of niet worden ontworpen met veiligheid in mening, en hun
ontwerpers zullen u vertellen cheerfully of wilt u hen gebruiken u moet
haven xxx door uw router laten. Jammer genoeg, niet kan iedereen dat doen,
en zodat is een aantal interesserend nieuw speelgoed moeilijk om voor mensen
achter firewalls te gebruiken. De dingen zoals RealAudio, die directe
toegang UDP vereisen, zijn in het bijzonder ongehoorde voorbeelden. Het in
gedachten te houden ding als u zich met één van deze problemen
geconfronteerd vindt moet zo veel te weten komen aangezien u over de
veiligheidsrisico's **** 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 **** beduidend verhogen door
een paar ontwerp en implementatiebesluiten te nemen.

Sommige ideeën voor hoe te om dit te behandelen:


Haal de gegevens u van het gegevensbestand op een regelmatige basis
nodig hebt zodat maakt u geen vragen tegen het volledige gegevensbestand,
volledig met informatie die de aanvallers interessant zullen vinden.
Beperk zeer en controleer wat u tussen de Webserver en het
gegevensbestand toestaat.


5.12 Maar mijn gegevensbestand heeft een geïntegreerde Webserver, en
ik wil dat gebruiken. Kan ik niet een gat in de firewall en de tunnel die
haven enkel porren?
Als uw plaatsbrandwall policy is sufficiently lax het muur beleid is
voldoende los dat u bereid bent om het risico dat
te beheren iemand een kwetsbaarheid in uw Webserver die in
gedeeltelijke of volledige blootstelling van uw gegevensbestand zal
resulteren, dan verhindert u niet daar veel dit te doen zal
exploiteren.

Nochtans, in vele organisaties, hebben de mensen die voor eenvoudig
het binden van het Web vooreind aan de gegevensbestand naherfst
verantwoordelijk zijn niet het gezag om die verantwoordelijkheid te
nemen. Verder, als de informatie in het gegevensbestand over mensen
is, zou u schuldig kunnen vinden van het breken van een aantal wetten
als u geen redelijke voorzorgsmaatregelen hebt genomen om het systeem
worden misbruikt te verhinderen.

In het algemeen, is dit geen goed idee. Zie vraag 5,11 voor sommige
ideeën op andere manieren om deze doelstelling te verwezenlijken.



5.13 Hoe maak ik tot IP Multicast Werk met Mijn Firewall?
Multicast IP is een middel om IP verkeer van één gastheer
aan een reeks gastheren te krijgen zonder het uitzenden te gebruiken;
namelijk in plaats van elke gastheer die het verkeer krijgt, slechts
zullen die die willen het het krijgen, zonder elk die een
afzonderlijke aansluting aan de server moet handhaven. Ip
unicast is waar de één gastheerbesprekingen aan multicast
andere, is waar één gastheer aan een reeks gastheren spreekt, en de
uitzending is waar één gastheer aan alle gastheren spreekt.

Openbaar Internet heeft een multicast backbone (``MBone '') waar
de gebruikers in multicast verkeersuitwisseling kunnen in dienst
nemen. Het gemeenschappelijke gebruik voor MBone is stromen van
vergaderingen IETF en gelijkaardig dergelijke interactie. Het
krijgen van zijn eigen netwerk zal dat met MBone wordt verbonden
vereisen dat het stroomopwaartse multicast verkeer van de
leveranciersroute aan en van uw netwerk. Bovendien, zal uw intern
netwerk het multicast leiden moeten steunen.

De rol van de firewall in het multicast leiden, conceptueel, is
geen verschillend van zijn rol in andere verkeer het leiden. Namelijk
moet een beleid dat zich identificeert wat multicast groepen zijn
en aren't toegestaan worden bepaald en toen een systeem om toe te
staan dat het verkeer volgens beleid moet worden bedacht. Het grote
detail op hoe precies om dit te doen is voorbij het toepassingsgebied
van dit document. Gelukkig, RFC 2588.4 ] bespreekt het onderwerp
meer in detail. Tenzij uw firewallproduct sommige middelen van het
selectieve multicast door:sturen steunt of u de capaciteit hebt om
het aan te brengen zelf, zou u het door:sturen van multicast
verkeer op een manier kunnen vinden verenigbaar met uw
veiligheidsbeleid om een grotere hoofdpijn te zijn dan het de moeite
waard is.


Back to Top
Firewall FAQ in Nederlands Deel 4
6 Havens TCP en UDP
door Mikael Olsson
Dit bijlage zal op vrij niveau `` basis'' beginnen, zodat zelfs als de
eerste punten aan u childishly duidelijk schijnen, zou u iets van het
overslaan vooruit aan iets later in de tekst nog kunnen leren.



6.1 Wat is een haven?
Een `` haven '' is `` virtuele groef '' in uw stapel TCP en UDP die
wordt gebruikt om een aansluting tussen twee gastheren, en ook tussen de
laag TCP/UDP en de daadwerkelijke toepassingen in kaart te brengen die op de
gastheren lopen.

_ zij nummeren 0-65535, met de waaier 0-1023 merken als `` reserveren
'' of `` privlileged '', en de rest (1024-65535) als `` dynamisch '' of ``
onbevoorrecht ''.

Er is fundamenteel twee gebruik voor havens:


`` het luisteren '' op een haven.
Dit wordt door servertoepassingen gebruikt die op gebruikers wachten
te verbinden, om aan wat `` bekend de dienst'', bijvoorbeeld HTTP (haven 80
van TCP) te worden, Telnet (haven van TCP 23), DNS (UDP en soms haven van
TCP 53).
Het openen van een haven `` dynamische ''.
Beide kanten van een aansluting van TCP moeten door IP adressen en
havenaantallen worden geïdentificeerd. Vandaar, wanneer u aan `` wilt
verbind '' met een serverproces, vergt uw eind van het communicatiekanaal
ook een `` haven ''. Dit wordt gedaan door een haven boven 1024 op uw
machine te kiezen die niet momenteel in gebruik door een ander
communicatiekanaal en, is het te gebruiken als `` afzender '' in de nieuwe
aansluting.
De dynamische havens kunnen ook als het luisteren `` '' havens in
sommige toepassingen worden gebruikt, het meest in het bijzonder FTP.

De havens in waaier 0-1023 zijn bijna altijd serverhavens. De havens
in waaier 1024-65535 zijn gewoonlijk dynamische havens (d.w.z., opende
dynamisch wanneer u met een serverhaven verbindt). Nochtans, kan om het even
welke haven als serverhaven worden gebruikt, en om het even welke haven kan
als haven `` uitgaande '' worden gebruikt.

Zo, om het op te sommen, hier wat in een basisaansluting gebeurt:

Op wat punt op tijd, beslist een servertoepassing op gastheer 1.2.3.4
aan `` '' bij haven 80 (HTTP) voor nieuwe aanslutingen luister.
U (5.6.7.8) wilt aan 1.2.3.4, haven 80 surfen, en uw browser geeft uit
verbindt vraag met het.
Verbind vraag realiseert, die dat het nog niet lokaal havenaantal,
gaat jagend voor heeft. Het lokale havenaantal is noodzakelijk sindsdien
wanneer de antwoorden wat tijd in de toekomst terugkomen, zal uw stapel van
TCP/IP aan welke toepassing moeten kennen om het antwoord over te gaan. Het
doet dit door te herinneren welk toepassingsgebruik dat lokaal havenaantal.
(Dit wordt in grote trekken vereenvoudigd, geen vlammen van programmeurs,
tevreden.)
Uw stapel van TCP vindt een ongebruikte dynamische haven, gewoonlijk
ergens boven 1024, veronderstel dat het 1029 vindt.
Uw eerste pakket wordt dan verzonden, van uw lokale IP, 5.6.7.8, haven
1029, naar 1.2.3.4, haven 80.
De server antwoordt met een pakket van 1.2.3.4, haven 80, aan u,
5.6.7.8, haven 1029.
Deze procedure is eigenlijk langer dan dit, verder gelezen voor een
meer diepgaande verklaring van TCP opeenvolgingen verbindt.


6.2 Hoe weet ik welke toepassing gebruikt welke haven?
Er zijn verscheidene lijsten schetsend de `` gereserveerde havens ''
en `` bekende '', evenals havens `` algemeen gebruikte '', en beste is:
ftp://ftp.isi.edu/in-notes/iana/assi...port-aantallen. Voor die van u
die nog RFC 1700 lezen om te weten te komen welk havenaantal doet wat,
OPHOUD DOEND IT. Het is afschuwelijk verouderd, en het zal niet minder zo
morgen zijn.

Nu, zoals voor het vertrouwen van op deze informatie: Deze lijsten, in
geen geval, vormen om het even welk soort heilige bijbel waarop de havens
doen wat.

Wacht, laat me herformuleren dat: ER IS GEEN MANIER OM BETROUWBAAR TE
BEPALEN WELKE HAVEN DOET WAT EENVOUDIG DOOR IN een LIJST TE KIJKEN.



6.3 Wat zijn het LUISTEREN havens?
Veronderstel u `` netstat - ` een '' op uw machine deed en havens 1025
en 1030 als LISTENing verschenen. Wat doen zij?

Het recht, nemen een blik in de toegewezen lijst van havenaantallen.


blackjack 1025/tcp netwerk blackjack iad1
1030/tcp BBN IAD

Wacht, wat gebeurt? Heeft mijn werkstation mijn aantal van het VISUM
gestolen en spel blackjack met één of andere schurkenserver op Internet
beslist te gaan? En wat is die software die BBN heeft geïnstalleerd?

Dit is NIET waar u begint panicking en post naar de firewallslijst
verzendt. In feite, is deze vraag gesteld misschien een dozijn keer tijdens
de afgelopen zes maanden, en telkens als het wordt beantwoord. Niet dat DIE
levensonderhoudmensen van het vragen van het zelfde opnieuw vragen.

Als u deze vraag stelt, bent u waarschijnlijkst gebruikend een
venstersdoos. De havens u zien zijn (het waarschijnlijkst) twee het
luisteren havens die het subsysteem RPC opent wanneer het begint.

Dit is een voorbeeld van waar de dynamicly toegewezen havens door
serverprocessen kunnen worden gebruikt. De toepassingen die RPC gebruiken
zullen later met haven 135 verbinden (netbios `` portmapper '') aan vraag
waar te om wat dienst te vinden RPC, en een antwoord achter te krijgen
zeggend dat die bepaalde dienst op haven 1025 kan worden gecontacteerd.

Nu, hoe kennen wij dit, sinds daar geen ``- lijst '' beschrijvend deze
havens? Eenvoudig: Daar geen substituut voor ervaring. En het gebruiken van
de motoren van het adressenlijstonderzoek helpt een ook een hel van.



6.4 Hoe bepaal ik welke dienst de haven voor is?
Aangezien het doen onmogelijk is om te leren welke haven doet wat door
in een lijst, hoe te kijken ik het?

De oude hands-on manier om te doen het is door het sluiten van bijna
elke dienst/daemon het lopen op uw machine, netstat -a nota te doen en te
nemen van welke havens open is. Er zou niet zeer vele luisterdegenen moeten
zijn. Dan begint u alle diensten aan te zetten, één voor één, en nota van
wat nieuwe havens tonen omhoog in uw netstatoutput neem.

Een andere manier, die meer gissingswerk vergt, telnetting eenvoudig
aan de havens en ziet wat uit komt. Als niets uit komt, probeer typend wat
brabbeltaal en dichtslaand ga een paar keer in, en zie of verschijnt iets.
Als u binair wordt vermink, of niets helemaal niet, dit zal u duidelijk
helpen.

Nochtans, zal dit u vertellen slechts welke het luisteren havens
worden gebruikt. Het zal niet u over dynamisch geopende havens vertellen die
later door deze toepassingen kunnen worden geopend.

Er zijn een paar toepassingen die u zouden kunnen helpen de gebruikte
havens opsporen.

Voor de systemen van Unix, daar preinstalled een aardig geroepen lsof
nut dat komt op vele systemen. Het zal u alle open havenaantallen en namen
van de toepassingen tonen die hen gebruiken. Dit betekent dat het u heel wat
plaatselijk geopende dossiers zou kunnen tonen aswell als contactdozen van
TCP/IP. Lees de hulptekst.

Voor vensterssystemen, niets preinstalled komt om u in deze taak bij
te staan. (Nieuw) Daar riep een nut `` Inzider '' die zich binnen de laag
van vensterscontactdozen installeert en dynamisch herinnert welk proces
opent welke haven. Het nadeel van deze benadering is dat het u niet kan
vertellen welke havens vóór begonnen inzider werden geopend, maar het is het
beste dat u op vensters (aan mijn kennis) zult krijgen.
http://ntsecurity.nu/toolbox/inzider/.



6.5 Welke havens zijn veilig om door een firewall over te gaan?
ALLEN.

Nr, wacht, NIETS.

Nr, wacht, uuhhh... Ik heb gehoord dat alle havens boven 1024 veilig
zijn aangezien zij slechts dynamische?? zijn

Nr. werkelijk. U **** vertellen niet welke havens eenvoudig door zijn
aantal te bekijken veilig zijn, eenvoudig omdat dat werkelijk allen is is
het. Een aantal. U **** 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, **** u waarschijnlijk redelijk verzekerd voelen
dat het veilig is om buitenmensentoegang het door haven 80 te laten. Anders,
**** 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 **** 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, **** u het
hebben van `` gesloten aanslutingen '' in al uw aansluting groeven omhoog
beëindigen. Deze manier, zou u niet meer aanslutingen kunnen dynamisch
toewijzen, ziend dat zij allen worden gebruikt. Verschillende OSes
behandelen verschillend deze situatie.




A. Sommige Commerciële Producten en Verkopers
Wij vinden dit onderwerp voor adres in een FAQ, echter te gevoelig is,
een onafhankelijk gehandhaafde lijst (geen garantie of aanbevelingen zijn
impliciet) kan online worden gevonden.9



B. Verklarende woordenlijst van firewall-Verwante Termijnen

Misbruik van Voorrecht
Wanneer een gebruiker een werking uitvoert geen die zij zouden moeten
hebben, volgens organisatorische beleid of wet.

De Lijsten van het Toegangsbeheer
Regels voor pakketfilters (typisch routers) die bepalen wat pakketten
overgaan en die om te blokkeren.

De Router van de toegang
Een router die uw netwerk met extern Internet verbindt. Typisch, is
dit uw eerste lijn van defensie tegen aanvallers van buitenInternet. Door
toegangsbeheerlijsten op deze router toe te laten, zult u een mate van
bescherming voor de elk van gastheren `` achter '' kunnen verstrekken die
router, effectief makend tot dat netwerk een DMZ in plaats van onbeschermde
externe LAN.

Toepassing-laag Firewall
Een firewallsysteem waarin de dienst door processen wordt verleend die
het volledige de aansluting van TCP staat en rangschikken handhaven. De de
laagfirewalls van de toepassing sturen vaak verkeer door zodat het uitgaande
verkeer om uit de firewall, eerder dan de interne gastheer schijnt
voortgekomen te zijn.

Authentificatie
Het proces om de identiteit van een gebruiker te bepalen die probeert
om tot een systeem toegang te hebben.

Het Teken van de authentificatie
Een draagbaar apparaat dat voor het voor authentiek verklaren van een
gebruiker wordt gebruikt. De tekenen van de authentificatie werken door
uitdaging/reactie, op tijd-gebaseerde codeopeenvolgingen, of andere
technieken. Dit kan lijsten op papier van éénmalige wachtwoorden omvatten.

Vergunning
Het proces om te bepalen welke soorten activiteiten worden toegelaten.
Gewoonlijk, is de vergunning in de context van authentificatie: zodra u een
gebruiker voor authentiek hebt verklaard, kunnen zij gemachtigde
verschillende soorten toegang of activiteit zijn.

Bastion Gastheer
Een systeem dat vaste vorm is gegeven om zich tegen aanval te
verzetten, en dat op een netwerk geïnstalleerd is zodanig dat het potentieel
onder aanval zou moeten komen. Bastion de gastheren zijn vaak componenten
van firewalls, of kunnen `` buiten '' Webservers of openbare
toegangssystemen zijn. Over het algemeen, stelt een bastion gastheer één of
andere vorm van algemeen doel werkend systeem (in werking b.v., Unix, VMS,
NT, enz.) eerder dan een op ROM-Gebaseerd of ingebouwde programmatuur
werkend systeem.

Uitdaging/Reactie
Een authentificatietechniek waardoor een server een onvoorspelbare
uitdaging aan de gebruiker verzendt, die een reactie gebruikend één of
andere vorm van authentificatieteken gegevens verwerkt.

Chroot
Een techniek onder Unix waardoor een proces tot een geïsoleerde
ondergroep van filesystem permanent beperkt is.

Cryptografische Controlesom
Een unidirectionele functie was op een dossier van toepassing om een
unieke `` vingerafdruk '' van het dossier voor recentere verwijzing te
produceren. De systemen van de controlesom zijn een primair middel om
filesystem het knoeien op Unix te ontdekken.

Gegevens Gedreven Aanval
Een vorm van aanval waarin de aanval in onschadelijk-schijnt gegeven
wordt gecodeerd dat door een gebruiker of andere software wordt uitgevoerd
om een aanval uit te voeren. In het geval van firewalls, is een gegevens
gedreven aanval een zorg aangezien het door de firewall in gegevensvorm kan
krijgen en een aanval lanceren tegen een systeem achter de firewall.

Diepgaand defensie
De veiligheidsbenadering waardoor elk systeem op het netwerk aan de
grootste mogelijke graad wordt beveiligd. Mag samen met firewalls worden
gebruikt.

Dns voor de gek houden
Veronderstellend de DNS naam van een ander systeem door of het geheime
voorgeheugen van de naamdienst van een slachtoffersysteem te bederven, of
door een server van de domeinnaam voor een geldig domein te compromitteren.

Dubbele Automatisch begesturde Gateway
Een dubbele automatisch begesturde gateway is een systeem dat twee of
meer netwerkinterfaces heeft, elk waarvan met een verschillend netwerk wordt
verbonden. In firewallconfiguraties, handelt een dubbele automatisch
begesturde gateway gewoonlijk om of wat of het elk van verkeer te blokkeren
te filtreren dat tussen de netwerken probeert over te gaan.

Coderende Router
zie Een tunnel gravende Router en de Virtuele Perimeter van het
Netwerk.

Firewall
Een systeem of een combinatie systemen dat een grens tussen twee of
meer netwerken afdwingen.

Op gastheer-gebaseerde Veiligheid
De techniek om een individueel systeem van aanval te beveiligen. Is de
gastheer gebaseerde veiligheid werkend afhankelijk systeem en versie.

De Aanval van de insider
Een aanval die van binnenuit een beschermd netwerk voortkomt.

De Opsporing van het binnendringen
De opsporing van inbraken of inbraak probeert of manueel of via
software expert-systemen die op beschikbare logboeken of andere informatie
over het netwerk werken.

Ip Voor de gek houden
Een aanval waardoor een systeem impersonate onwettig een ander systeem
door zijn IP netwerkadres te gebruiken probeert.

/ Ip die verbindt kaapt
Een aanval waardoor actief, gevestigd, zitting wordt onderschept en
door de aanvaller gecoöpteerd. Ip die aanvallen verbindt kan voorkomen nadat
een authentificatie is gemaakt, toelatend de aanvaller om de rol van een
reeds erkende gebruiker te vervullen. De primaire bescherming tegen IP het
Verbinden baseren zich bij de encryptie bij de zitting of netwerklaag.

Minste Voorrecht
Het ontwerpen van operationele aspecten van een systeem om met een
minimumhoeveelheid systeemvoorrecht te werken. Dit vermindert het
vergunningsniveau waarop diverse acties worden uitgevoerd en de kans
vermindert dat een proces of een gebruiker met hoge voorrechten kan worden
ertoe gebracht om onbevoegde activiteit uit te voeren resulterend in een
veiligheidsbreuk.

Registreren
Het proces om informatie over gebeurtenissen op te slaan die op de
firewall of het netwerk voorkwamen.

Het Behoud van het logboek
Hoe lang de controlelogboeken worden behouden en gehandhaafd.

De Verwerking van het logboek
Hoe de controlelogboeken worden verwerkt, gezocht naar zeer
belangrijke gebeurtenissen, of samengevat.

Netwerk-laag Firewall
Een firewall waarin het verkeer bij de het pakketlaag van het
netwerkprotocol wordt onderzocht.

Op perimeter-gebaseerde Veiligheid
De techniek om een netwerk te beveiligen door toegang tot alle ingang
en uitgangspunten van het netwerk te controleren.

Beleid
Organisatie-vlakke regels die aanvaardbaar gebruik van de
gegevensverwerking van middelen, veiligheidspraktijken, en operationele
procedures reglementeren.

Volmacht
Een softwareagent die namens een gebruiker handelt. De typische
volmachten keuren een aansluting van een gebruiker goed, nemen een besluit
over de vraag of of niet het gebruiker of cliëntip adres wordt toegelaten om
de volmacht te gebruiken, misschien extra authentificatie, doet en dan een
aansluting namens de gebruiker aan een verre bestemming voltooit.

Onderzochte Gastheer
Een gastheer op een netwerk achter een onderzoeksrouter. De graad
waaraan een onderzochte gastheer kan worden betreden hangt van de
onderzoeksregels af in de router.

Onderzochte Subnet
Subnet achter een onderzoeksrouter. De graad waaraan subnet kan worden
betreden hangt van de onderzoeksregels af in de router.

De Router van het onderzoek
Een router die wordt gevormd om verkeer toe te laten of te ontkennen
dat op een reeks toestemmingsregels wordt gebaseerd die door de beheerder
worden geïnstalleerd.

De Diefstal van de zitting
Zie IP het Verbinden.

Trojan Paard
Een softwareentiteit die schijnt om normaal iets te doen maar die, in
feite, een trapdoor of aanvalsprogramma bevat.

Een tunnel gravende Router
Een router of een systeem geschikt om verkeer te leiden door het te
coderen en het in te kapselen voor transmissie over een onbetrouwbaar
netwerk, voor uiteindelijke DE-INKAPSELING en decryptie.

Sociale Techniek
Een aanval die bij het bedriegen van gebruikers of beheerders bij de
doelplaats wordt gebaseerd. De sociale techniekaanvallen worden typisch
uitgevoerd door gebruikers of exploitanten te telefoneren en te beweren een
erkende gebruiker te zijn, om ongeoorloofde toegang tot systemen proberen te
verkrijgen.

De virtuele Perimeter van het Netwerk
Een netwerk dat één enkel beschermd netwerk achter firewalls schijnt
te zijn, dat eigenlijk gecodeerde virtuele links over onbetrouwbare
netwerken omvat.

Virus
Een het herhalen codesegment dat zich aan een programma of
gegevensdossier vastmaakt. De virussen zouden of zouden aanvalsprogramma's
of trapdoors kunnen kunnen niet niet bevatten. Jammer genoeg, hebben velen
aan het roepen van om het even welke kwaadwillige code virussen `` '
genomen. Als u betekent `` zegt trojan paard '' of `` worm '', `` trojan
paard '' of `` worm ''.

Worm
Een standalone programma dat, wanneer in werking gesteld, kopiëert
zelf van één gastheer aan een andere, en loopt dan zelf over elke onlangs
besmette gastheer. De wijd gemelde ``Internet Virussen ' van 1988 waren een
virus helemaal niet, maar eigenlijk een worm.





----------------------------------------------------------------------
----------

Voetnoten
... Systeem1
http://mail-abuse.org/
... Initiatief2
http://mail-abuse.org/tsi/
... Pijlinktvis3
http://squid.nlanr.net/
... Apache4
http://www.apache.org/docs/mod/mod_proxy.html
... Volmacht5
http://home.netscape.com/proxy/v3.5/index.html
... Netscape6
http://developer.netscape.com/docs/m...n/contents.htm
... firewall7
http://www.real.com/firewall/
... bugtraq8
http://www.securityfocus.com
... online.9
http://www.thegild.com/firewall/.






you mean dutch? 02-06-2005 08:56 AM

Re: Internet Firewall FAQ in Dutch
 
"William L. Sun" <88sun@cox.net> wrote in message
news:CSdNd.10971$6u.4455@fed1read02...
> Firewall FAQ in Nederlands Deel 1



computer translated?
Indeed, it's dutch, better said it's a great collection of dutch words.
But to understand it it's not that easy.
To translate it in real dutch it will take me a day I'm afraid.
Oh man, what a terrible sentence constructions.



William L. Sun 02-06-2005 07:23 PM

Re: Internet Firewall FAQ in Dutch
 
Yes, It is computer translated. Just want to start the effort. If you can
help to correct it, We would be grateful. It will benefit
more people in the world.

Thank you
"you mean dutch?" <me@privacy.net> wrote in message
news:36m4djF51qpqaU1@individual.net...
> "William L. Sun" <88sun@cox.net> wrote in message
> news:CSdNd.10971$6u.4455@fed1read02...
> > Firewall FAQ in Nederlands Deel 1

>
>
> computer translated?
> Indeed, it's dutch, better said it's a great collection of dutch words.
> But to understand it it's not that easy.
> To translate it in real dutch it will take me a day I'm afraid.
> Oh man, what a terrible sentence constructions.
>
>




see.my.sig.4.addr@nowhere.com.invalid 02-07-2005 06:36 AM

Re: Internet Firewall FAQ in Dutch
 
How about the ENGLISH one?!

On Sun, 6 Feb 2005 11:23:30 -0800, "William L. Sun" <88sun@cox.net>
spewed:
>Yes, It is computer translated. Just want to start the effort. If you can
>help to correct it, We would be grateful. It will benefit
>more people in the world.
>
>Thank you
>"you mean dutch?" <me@privacy.net> wrote in message
>news:36m4djF51qpqaU1@individual.net...
>> "William L. Sun" <88sun@cox.net> wrote in message
>> news:CSdNd.10971$6u.4455@fed1read02...
>> > Firewall FAQ in Nederlands Deel 1

>>
>>
>> computer translated?
>> Indeed, it's dutch, better said it's a great collection of dutch words.
>> But to understand it it's not that easy.
>> To translate it in real dutch it will take me a day I'm afraid.
>> Oh man, what a terrible sentence constructions.
>>
>>

>


--
__________________________________________________ ___
For email response, or CC, please mailto:see.my.sig.4.addr(at)bigfoot.com.
Yeah, it's really a real address :)

you mean dutch? 02-07-2005 10:46 AM

Re: Internet Firewall FAQ in Dutch
 
"William L. Sun" <88sun@cox.net> wrote in message
news:n9uNd.11112$6u.7419@fed1read02...

> Yes, It is computer translated. Just want to start the effort. If you can
> help to correct it, We would be grateful. It will benefit
> more people in the world.


the other FAQ's requires also a lot of attention; you need for every
language a good translator.
I will give it a try after you post the original english ( I hope ) version.
Without it it's sometimes very hard to understand what the FAQ wants to tell
me.
Give me a week ( maybe two? ) after your english FAQ posting. It takes a
lot of time to translate it from dutch to dutch :-).
( for example 6.1 havens (dutch FAQ) = harbour ( eng ) ; kanal (german FAQ)
= canal or channel ( eng ) ; port (french FAQ) ah-ha you mean port (eng )
; so 6.1 should be poorten or poort. I'm used to the english word "port" but
I have to look in a dutch manual to be sure if 'poort' is the correct word).
Sometimes I really have no idea what the FAQ tries to tell me.


This is a once-only offer if that's no problem. You have to do the PDF part.
There are no problems with copyrights if I translated it to a readable faq?
The good news for you ;;-)) is that someone looked at the FAQ, but the bad
thing for me is that I hope to have enough TCP/UDP/Internet knowledge.

What about firewalls-faq@interhack.net named in the FAQ?
Maybe it's much better that I send an email to this email address to be sure
that I'm the only one translating it and not somebody else just finished a
translation. Or give me an email address in your reply I could use to
contact you.




Moe Trin 02-07-2005 11:57 PM

Re: Internet Firewall FAQ in Dutch
 
In article <1v2e0112rvqlepsuig2e1ervkqm2gctuff@4ax.com>,
see.my.sig.4.addr@nowhere.com.invalid wrote:

>How about the ENGLISH one?!


Is your access to http://www.google.com broken? Or can't you think of the
right keywords to search for? Here, let me help:

Google Search: Internet Firewall FAQ (p1 of 3)

Go to Google Home
Web Images Groups News Froogle LocalNew! more >>
Internet Firewall FAQ____________________ Search Advanced Search
Preferences
Web Results 1 - 10 of about 4,830,000 for Internet Firewall FAQ. (0.32
seconds)

Sheesh! Only four million choices of web sites.

Old guy


William L. Sun 02-08-2005 07:55 AM

Re: Internet Firewall FAQ in Dutch
 
Thank you very much for your help. Here is the english version. Please take
your time to do it.
==============
Internet Firewalls:
Frequently Asked Questions
Paul D. Robertson paul@compuwar.net
Matt Curtin cmcurtin@interhack.net
Marcus J. Ranum mjr@ranum.com


Date: 2004/07/26 15:34:42
Revision: 10.4

This document available in Postscript.and PDF.




Contents
1 Administrativia
1.1 About the FAQ
1.2 For Whom Is the FAQ Written?
1.3 Before Sending Mail
1.4 Where Can I find the Current Version of the FAQ?
1.5 Where Can I Find Non-English Versions of the FAQ?
1.6 Contributors
1.7 Copyright and Usage


2 Background and Firewall Basics
2.1 What is a network firewall?
2.2 Why would I want a firewall?
2.3 What can a firewall protect against?
2.4 What can't a firewall protect against?
2.5 What about viruses and other malware?
2.6 Will IPSEC make firewalls obsolete?
2.7 What are good sources of print information on firewalls?
2.8 Where can I get more information on firewalls on the Internet?


3 Design and Implementation Issues
3.1 What are some of the basic design decisions in a firewall?
3.2 What are the basic types of firewalls?
3.3 What are proxy servers and how do they work?
3.4 What are some cheap packet screening tools?
3.5 What are some reasonable filtering rules for a kernel-based packet
screen?
3.6 What are some reasonable filtering rules for a Cisco?
3.7 What are the critical resources in a firewall?
3.8 What is a DMZ, and why do I want one?
3.9 How might I increase the security and scalability of my DMZ?
3.10 What is a `single point of failure', and how do I avoid having
one?
3.11 How can I block all of the bad stuff?
3.12 How can I restrict web access so users can't view sites unrelated
to work?


4 Various Attacks
4.1 What is source routed traffic and why is it a threat?
4.2 What are ICMP redirects and redirect bombs?
4.3 What about denial of service?
4.4 What are some common attacks, and how can I protect my system
against them?


5 How Do I...
5.1 Do I really want to allow everything that my users ask for?
5.2 How do I make Web/HTTP work through my firewall?
5.3 How do I make SSL work through the firewall?
5.4 How do I make DNS work with a firewall?
5.5 How do I make FTP work through my firewall?
5.6 How do I make Telnet work through my firewall?
5.7 How do I make Finger and whois work through my firewall?
5.8 How do I make gopher, archie, and other services work through my
firewall?
5.9 What are the issues about X11 through a firewall?
5.10 How do I make RealAudio work through my firewall?
5.11 How do I make my web server act as a front-end for a database
that lives on my private network?
5.12 But my database has an integrated web server, and I want to use
that. Can't I just poke a hole in the firewall and tunnel that port?
5.13 How Do I Make IP Multicast Work With My Firewall?


6 TCP and UDP Ports
6.1 What is a port?
6.2 How do I know which application uses what port?
6.3 What are LISTENING ports?
6.4 How do I determine what service the port is for?
6.5 What ports are safe to pass through a firewall?
6.6 The behavior of FTP
6.7 What software uses what FTP mode?
6.8 Is my firewall trying to connect outside?
6.9 The anatomy of a TCP connection


A. Some Commercial Products and Vendors
B. Glossary of Firewall-Related Terms
Bibliography


1 Administrativia


1.1 About the FAQ
This collection of Frequenty Asked Questions (FAQs) and answers has
been compiled over a period of years, seeing which questions people ask
about firewalls in such fora as Usenet, mailing lists, and Web sites. If you
have a question, looking here to see whether it's answered before posting
your question is good form. Don't send your questions about firewalls to the
FAQ maintainers.

The maintainers welcome input and comments on the contents of this
FAQ. Comments related to the FAQ should be addressed to
firewalls-faq@interhack.net. Before you send us mail, please be sure to see
sections 1.2 and 1.3 to make sure this is the right document for you to be
reading.



1.2 For Whom Is the FAQ Written?
Firewalls have come a long way from the days when this FAQ started.
They've gone from being highly customized systems administered by their
implementors to a mainstream commodity. Firewalls are no longer solely in
the hands of those who design and implement security systems; even
security-conscious end-users have them at home.

We wrote this FAQ for computer systems developers and administrators.
We have tried to be fairly inclusive, making room for the newcomers, but we
still assume some basic technical background. If you find that you don't
understand this document, but think that you need to know more about
firewalls, it might well be that you actually need to get more background in
computer networking first. We provide references that have helped us;
perhaps they'll also help you.

We focus predominately on "network" firewalls, but ``host'' or
``"personal'' firewalls will be addressed where appropriate.



1.3 Before Sending Mail
Note that this collection of frequently-asked questions is a result of
interacting with many people of different backgrounds in a wide variety of
public fora. The firewalls-faq address is not a help desk. If you're trying
to use an application that says that it's not working because of a firewall
and you think that you need to remove your firewall, please do not send us
mail asking how.

If you want to know how to ``get rid of your firewall'' because you
cannot use some application, do not send us mail asking for help. We cannot
help you. Really.

Who can help you? Good question. That will depend on what exactly the
problem is, but here are several pointers. If none of these works, please
don't ask us for any more. We don't know.

The provider of the software you're using.
The provider of the hardware ``appliance'' you're using.
The provider of the network service you're using. That is, if you're
on AOL, ask them. If you're trying to use something on a corporate network,
talk to your system administrator.


1.4 Where Can I find the Current Version of the FAQ?
The FAQ can be found on the Web at

http://www.compuwar.net/pubs/fwfaq/.
http://www.interhack.net/pubs/fwfaq/.
It's also posted monthly to

comp.security.firewalls,
comp.security.unix,
comp.security.misc,
comp.answers, and
news.answers.
Posted versions are archived in all the usual places. Unfortunately,
the version posted to Usenet and archived from that version lack the pretty
pictures and useful hyperlinks found in the web version.



1.5 Where Can I Find Non-English Versions of the FAQ?
Several translations are available. (If you've done a translation and
it's not listed here, please write us so we can update the master document.)


Norwegian
Translation by Jon Haugsand
http://helmersol.nr.no/haandbok/doc/...nnmur-faq.html


1.6 Contributors
Many people have written helpful suggestions and thoughtful
commentary. We're grateful to all contributors. We'd like to thank afew by
name: Keinanen Vesa, Allen Leibowitz, Brent Chapman, Brian Boyle, D. Clyde
Williamson, Richard Reiner, Humberto Ortiz Zuazaga, William Sun and Theodore
Hope.



1.7 Copyright and Usage
Copyright ©1995-1996, 1998 Marcus J. Ranum. Copyright ©1998-2002 Matt
Curtin. Copyright 2004, Paul D. Robertson. All rights reserved. This
document may be used, reprinted, and redistributed as is providing this
copyright notice and all attributions remain intact. Translations of the
complete text from the original English to other languages are also
explicitly allowed. Translators may add their names to the ``Contributors''
section.



2 Background and Firewall Basics
Before being able to understand a complete discussion of firewalls,
it's important to understand the basic principles that make firewalls work.



2.1 What is a network firewall?
A firewall is a system or group of systems that enforces an access
control policy between two or more networks. The actual means by which this
is accomplished varies widely, but in principle, the firewall can be thought
of as a pair of mechanisms: one which exists to block traffic, and the other
which exists to permit traffic. Some firewalls place a greater emphasis on
blocking traffic, while others emphasize permitting traffic. Probably the
most important thing to recognize about a firewall is that it implements an
access control policy. If you don't have a good idea of what kind of access
you want to allow or to deny, a firewall really won't help you. It's also
important to recognize that the firewall's configuration, because it is a
mechanism for enforcing policy, imposes its policy on everything behind it.
Administrators for firewalls managing the connectivity for a large number of
hosts therefore have a heavy responsibility.



2.2 Why would I want a firewall?
The Internet, like any other society, is plagued with the kind of
jerks who enjoy the electronic equivalent of writing on other people's walls
with spraypaint, tearing their mailboxes off, or just sitting in the street
blowing their car horns. Some people try to get real work done over the
Internet, and others have sensitive or proprietary data they must protect.
Usually, a firewall's purpose is to keep the jerks out of your network while
still letting you get your job done.

Many traditional-style corporations and data centers have computing
security policies and practices that must be followed. In a case where a
company's policies dictate how data must be protected, a firewall is very
important, since it is the embodiment of the corporate policy. Frequently,
the hardest part of hooking to the Internet, if you're a large company, is
not justifying the expense or effort, but convincing management that it's
safe to do so. A firewall provides not only real security--it often plays an
important role as a security blanket for management.

Lastly, a firewall can act as your corporate ``ambassador'' to the
Internet. Many corporations use their firewall systems as a place to store
public information about corporate products and services, files to download,
bug-fixes, and so forth. Several of these systems have become important
parts of the Internet service structure (e.g., UUnet.uu.net, whitehouse.gov,
gatekeeper.dec.com) and have reflected well on their organizational
sponsors. Note that while this is historically true, most organizations now
place public information on a Web server, often protected by a firewall, but
not normally on the firewall itself.



2.3 What can a firewall protect against?
Some firewalls permit only email traffic through them, thereby
protecting the network against any attacks other than attacks against the
email service. Other firewalls provide less strict protections, and block
services that are known to be problems.

Generally, firewalls are configured to protect against unauthenticated
interactive logins from the ``outside'' world. This, more than anything,
helps prevent vandals from logging into machines on your network. More
elaborate firewalls block traffic from the outside to the inside, but permit
users on the inside to communicate freely with the outside. The firewall can
protect you against any type of network-borne attack if you unplug it.

Firewalls are also important since they can provide a single ``choke
point'' where security and audit can be imposed. Unlike in a situation where
a computer system is being attacked by someone dialing in with a modem, the
firewall can act as an effective ``phone tap'' and tracing tool. Firewalls
provide an important logging and auditing function; often they provide
summaries to the administrator about what kinds and amount of traffic passed
through it, how many attempts there were to break into it, etc.

Because of this, firewall logs are critically important data. They can
be used as evidence in a court of law in most countries. You should
safeguard, analyze and protect yoru firewall logs accordingly.

This is an important point: providing this ``choke point'' can serve
the same purpose on your network as a guarded gate can for your site's
physical premises. That means anytime you have a change in ``zones'' or
levels of sensitivity, such a checkpoint is appropriate. A company rarely
has only an outside gate and no receptionist or security staff to check
badges on the way in. If there are layers of security on your site, it's
reasonable to expect layers of security on your network.



2.4 What can't a firewall protect against?
Firewalls can't protect against attacks that don't go through the
firewall. Many corporations that connect to the Internet are very concerned
about proprietary data leaking out of the company through that route.
Unfortunately for those concerned, a magnetic tape, compact disc, DVD, or
USB flash drives can just as effectively be used to export data. Many
organizations that are terrified (at a management level) of Internet
connections have no coherent policy about how dial-in access via modems
should be protected. It's silly to build a six-foot thick steel door when
you live in a wooden house, but there are a lot of organizations out there
buying expensive firewalls and neglecting the numerous other back-doors into
their network. For a firewall to work, it must be a part of a consistent
overall organizational security architecture. Firewall policies must be
realistic and reflect the level of security in the entire network. For
example, a site with top secret or classified data doesn't need a firewall
at all: they shouldn't be hooking up to the Internet in the first place, or
the systems with the really secret data should be isolated from the rest of
the corporate network.

Another thing a firewall can't really protect you against is traitors
or idiots inside your network. While an industrial spy might export
information through your firewall, he's just as likely to export it through
a telephone, FAX machine, or Compact Disc. CDs are a far more likely means
for information to leak from your organization than a firewall. Firewalls
also cannot protect you against stupidity. Users who reveal sensitive
information over the telephone are good targets for social engineering; an
attacker may be able to break into your network by completely bypassing your
firewall, if he can find a ``helpful'' employee inside who can be fooled
into giving access to a modem pool. Before deciding this isn't a problem in
your organization, ask yourself how much trouble a contractor has getting
logged into the network or how much difficulty a user who forgot his
password has getting it reset. If the people on the help desk believe that
every call is internal, you have a problem that can't be fixed by tightening
controls on the firewalls.

Firewalls can't protect against tunneling over most application
protocols to trojaned or poorly written clients. There are no magic bullets
and a firewall is not an excuse to not implement software controls on
internal networks or ignore host security on servers. Tunneling ``bad''
things over HTTP, SMTP, and other protocols is quite simple and trivially
demonstrated. Security isn't ``fire and forget''.

Lastly, firewalls can't protect against bad things being allowed
through them. For instance, many Trojan Horses use the Internet Relay Chat
(IRC) protocol to allow an attacker to control a compromised internal host
from a public IRC server. If you allow any internal system to connect to any
external system, then your firewall will provide no protection from this
vector of attack.



2.5 What about viruses and other malware?
Firewalls can't protect very well against things like viruses or
malicious software (malware). There are too many ways of encoding binary
files for transfer over networks, and too many different architectures and
viruses to try to search for them all. In other words, a firewall cannot
replace security-consciousness on the part of your users. In general, a
firewall cannot protect against a data-driven attack--attacks in which
something is mailed or copied to an internal host where it is then executed.
This form of attack has occurred in the past against various versions of
sendmail, ghostscript, scripting mail user agents like Outlook, and Web
browsers like Internet Explorer.

Organizations that are deeply concerned about viruses should implement
organization-wide virus control measures. Rather than only trying to screen
viruses out at the firewall, make sure that every vulnerable desktop has
virus scanning software that is run when the machine is rebooted. Blanketing
your network with virus scanning software will protect against viruses that
come in via floppy disks, CDs, modems, and the Internet. Trying to block
viruses at the firewall will only protect against viruses from the Internet.
Virus scanning at the firewall or e-mail gateway will stop a large number of
infections.

Nevertheless, an increasing number of firewall vendors are offering
``virus detecting'' firewalls. They're probably only useful for naive users
exchanging Windows-on-Intel executable programs and malicious-macro-capable
application documents. There are many firewall-based approaches for dealing
with problems like the ``ILOVEYOU'' worm and related attacks, but these are
really oversimplified approaches that try to limit the damage of something
that is so stupid it never should have occurred in the first place. Do not
count on any protection from attackers with this feature. (Since
``ILOVEYOU'' went around, we've seen at least a half-dozen similar attacks,
including Melissa, Happy99, Code Red, and Badtrans.B, all of which were
happily passed through many virus-detecting firewalls and e-mail gateways.)

A strong firewall is never a substitute for sensible software that
recognizes the nature of what it's handling--untrusted data from an
unauthenticated party--and behaves appropriately. Do not think that because
``everyone'' is using that mailer or because the vendor is a gargantuan
multinational company, you're safe. In fact, it isn't true that ``everyone''
is using any mailer, and companies that specialize in turning technology
invented elsewhere into something that's ``easy to use'' without any
expertise are more likely to produce software that can be fooled. Further
consideration of this topic would be worthwhile [3], but is beyond the scope
of this document.



2.6 Will IPSEC make firewalls obsolete?
Some have argued that this is the case. Before pronouncing such a
sweeping prediction, however, it's worthwhile to consider what IPSEC is and
what it does. Once we know this, we can consider whether IPSEC will solve
the problems that we're trying to solve with firewalls.

IPSEC (IP SECurity) refers to a set of standards developed by the
Internet Engineering Task Force (IETF). There are many documents that
collectively define what is known as ``IPSEC'' [6]. IPSEC solves two
problems which have plagued the IP protocol suite for years: host-to-host
authentication (which will let hosts know that they're talking to the hosts
they think they are) and encryption (which will prevent attackers from being
able to watch the traffic going between machines).

Note that neither of these problems is what firewalls were created to
solve. Although firewalls can help to mitigate some of the risks present on
an Internet without authentication or encryption, there are really two
classes of problems here: integrity and privacy of the information flowing
between hosts and the limits placed on what kinds of connectivity is allowed
between different networks. IPSEC addresses the former class and firewalls
the latter.

What this means is that one will not eliminate the need for the other,
but it does create some interesting possibilities when we look at combining
firewalls with IPSEC-enabled hosts. Namely, such things as
vendor-independent virtual private networks (VPNs), better packet filtering
(by filtering on whether packets have the IPSEC authentication header), and
application-layer firewalls will be able to have better means of host
verification by actually using the IPSEC authentication header instead of
``just trusting'' the IP address presented.



2.7 What are good sources of print information on firewalls?
There are several books that touch on firewalls. The best known are:

Building Internet Firewalls, 2d ed.
Authors
Elizabeth D. Zwicky, Simon Cooper, and D. Brent Chapman
Publisher
O'Reilly
Edition
2000
ISBN
1-56592-871-7

Firewalls and Internet Security: Repelling the Wily Hacker
Authors
Bill Cheswick, Steve Bellovin, Avi Rubin
Publisher
Addison Wesley
Edition
2003
ISBN
020163466X

Practical Internet & Unix Security
Authors
Simson Garfinkel and Gene Spafford
Publisher
O'Reilly
Edition
1996
ISBN
1-56592-148-8
Note
Discusses primarily host security.
Related references are:

Internetworking with TCP/IP Vols I, II, and III
Authors
Douglas Comer and David Stevens
Publisher
Prentice-Hall
Edition
1991
ISBN
0-13-468505-9 (I), 0-13-472242-6 (II), 0-13-474222-2 (III)
Comment
A detailed discussion on the architecture and implementation of the
Internet and its protocols. Volume I (on principles, protocols and
architecture) is readable by everyone. Volume 2 (on design, implementation
and internals) is more technical. Volume 3 covers client-server computing.

Unix System Security--A Guide for Users and System Administrators
Author
David Curry
Publisher
Addison Wesley
Edition
1992
ISBN
0-201-56327-4


2.8 Where can I get more information on firewalls on the Internet?

Site Security Handbook
http://www.rfc-editor.org/rfc/rfc2196.txt The Site Security Handbook
is an information IETF document that describes the basic issues that must be
addressed for building good site security. Firewalls are one part of a
larger security strategy, as the Site Security Handbook shows.
Firewalls Mailing List
http://www.isc.org/index.pl?/ops/lists/firewalls/ The internet
firewalls mailing list is a forum for firewall administrators and
implementors.
Firewall-Wizards Mailing List
http://honor.icsalabs.com/mailman/li...rewall-wizards The
Firewall Wizards Mailing List is a moderated firewall and security related
list that is more like a journal than a public soapbox.
Firewall HOWTO
http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html Describes exactly
what is needed to build a firewall, particularly using Linux.
Firewall Toolkit (FWTK) and Firewall Papers
ftp://ftp.tis.com/pub/firewalls/
Marcus Ranum's firewall related publications
http://www.ranum.com/pubs/
Texas A&M University security tools
http://www.net.tamu.edu/ftp/security/TAMU/
COAST Project Internet Firewalls page
http://www.cerias.purdue.edu/coast/firewalls/


3 Design and Implementation Issues


3.1 What are some of the basic design decisions in a firewall?
There are a number of basic design issues that should be addressed by
the lucky person who has been tasked with the responsibility of designing,
specifying, and implementing or overseeing the installation of a firewall.

The first and most important decision reflects the policy of how your
company or organization wants to operate the system: is the firewall in
place explicitly to deny all services except those critical to the mission
of connecting to the Net, or is the firewall in place to provide a metered
and audited method of ``queuing'' access in a non-threatening manner? There
are degrees of paranoia between these positions; the final stance of your
firewall might be more the result of a political than an engineering
decision.

The second is: what level of monitoring, redundancy, and control do
you want? Having established the acceptable risk level (i.e., how paranoid
you are) by resolving the first issue, you can form a checklist of what
should be monitored, permitted, and denied. In other words, you start by
figuring out your overall objectives, and then combine a needs analysis with
a risk assessment, and sort the almost always conflicting requirements out
into a laundry list that specifies what you plan to implement.

The third issue is financial. We can't address this one here in
anything but vague terms, but it's important to try to quantify any proposed
solutions in terms of how much it will cost either to buy or to implement.
For example, a complete firewall product may cost between $100,000 at the
high end, and free at the low end. The free option, of doing some fancy
configuring on a Cisco or similar router will cost nothing but staff time
and a few cups of coffee. Implementing a high end firewall from scratch
might cost several man-months, which may equate to $30,000 worth of staff
salary and benefits. The systems management overhead is also a
consideration. Building a home-brew is fine, but it's important to build it
so that it doesn't require constant (and expensive) attention. It's
important, in other words, to evaluate firewalls not only in terms of what
they cost now, but continuing costs such as support.

On the technical side, there are a couple of decisions to make, based
on the fact that for all practical purposes what we are talking about is a
static traffic routing service placed between the network service provider's
router and your internal network. The traffic routing service may be
implemented at an IP level via something like screening rules in a router,
or at an application level via proxy gateways and services.

The decision to make is whether to place an exposed stripped-down
machine on the outside network to run proxy services for telnet, FTP, news,
etc., or whether to set up a screening router as a filter, permitting
communication with one or more internal machines. There are benefits and
drawbacks to both approaches, with the proxy machine providing a greater
level of audit and, potentially, security in return for increased cost in
configuration and a decrease in the level of service that may be provided
(since a proxy needs to be developed for each desired service). The old
trade-off between ease-of-use and security comes back to haunt us with a
vengeance.



3.2 What are the basic types of firewalls?
Conceptually, there are three types of firewalls:

Network layer
Application layer
Hybrids
They are not as different as you might think, and latest technologies
are blurring the distinction to the point where it's no longer clear if
either one is ``better'' or ``worse.'' As always, you need to be careful to
pick the type that meets your needs.

Which is which depends on what mechanisms the firewall uses to pass
traffic from one security zone to another. The International Standards
Organization (ISO) Open Systems Interconnect (OSI) model for networking
defines seven layers, where each layer provides services that
``higher-level'' layers depend on. In order from the bottom, these layers
are physical, data link, network, transport, session, presentation,
application.

The important thing to recognize is that the lower-level the
forwarding mechanism, the less examination the firewall can perform.
Generally speaking, lower-level firewalls are faster, but are easier to fool
into doing the wrong thing.

These days, most firewalls fall into the ``hybrid'' category, which do
network filtering as well as some amount of application inspection. The
amount changes depending on the vendor, product, protocol and version, so
some level of digging and/or testing is often necessary.


3.2.1 Network layer firewalls
These generally make their decisions based on the source, destination
addresses and ports (see Appendix 6 for a more detailed discussion of ports)
in individual IP packets. A simple router is the ``traditional'' network
layer firewall, since it is not able to make particularly sophisticated
decisions about what a packet is actually talking to or where it actually
came from. Modern network layer firewalls have become increasingly
sophisticated, and now maintain internal information about the state of
connections passing through them, the contents of some of the data streams,
and so on. One thing that's an important distinction about many network
layer firewalls is that they route traffic directly though them, so to use
one you either need to have a validly assigned IP address block or to use a
``private internet'' address block [5]. Network layer firewalls tend to be
very fast and tend to be very transparent to users.


Figure 1: Screened Host Firewall

In Figure 1, a network layer firewall called a ``screened host
firewall'' is represented. In a screened host firewall, access to and from a
single host is controlled by means of a router operating at a network layer.
The single host is a bastion host; a highly-defended and secured
strong-point that (hopefully) can resist attack.


Figure 2: Screened Subnet Firewall

Example Network layer firewall: In Figure 2, a network layer firewall
called a ``screened subnet firewall'' is represented. In a screened subnet
firewall, access to and from a whole network is controlled by means of a
router operating at a network layer. It is similar to a screened host,
except that it is, effectively, a network of screened hosts.


3.2.2 Application layer firewalls
These generally are hosts running proxy servers, which permit no
traffic directly between networks, and which perform elaborate logging and
auditing of traffic passing through them. Since the proxy applications are
software components running on the firewall, it is a good place to do lots
of logging and access control. Application layer firewalls can be used as
network address translators, since traffic goes in one ``side'' and out the
other, after having passed through an application that effectively masks the
origin of the initiating connection. Having an application in the way in
some cases may impact performance and may make the firewall less
transparent. Early application layer firewalls such as those built using the
TIS firewall toolkit, are not particularly transparent to end users and may
require some training. Modern application layer firewalls are often fully
transparent. Application layer firewalls tend to provide more detailed audit
reports and tend to enforce more conservative security models than network
layer firewalls.


Figure 3: Dual Homed Gateway

Example Application layer firewall: In Figure 3, an application layer
firewall called a ``dual homed gateway'' is represented. A dual homed
gateway is a highly secured host that runs proxy software. It has two
network interfaces, one on each network, and blocks all traffic passing
through it.

Most firewalls now lie someplace between network layer firewalls and
application layer firewalls. As expected, network layer firewalls have
become increasingly ``aware'' of the information going through them, and
application layer firewalls have become increasingly ``low level'' and
transparent. The end result is that now there are fast packet-screening
systems that log and audit data as they pass through the system.
Increasingly, firewalls (network and application layer) incorporate
encryption so that they may protect traffic passing between them over the
Internet. Firewalls with end-to-end encryption can be used by organizations
with multiple points of Internet connectivity to use the Internet as a
``private backbone'' without worrying about their data or passwords being
sniffed. (IPSEC, described in Section 2.6, is playing an increasingly
significant role in the construction of such virtual private networks.)



3.3 What are proxy servers and how do they work?
A proxy server (sometimes referred to as an application gateway or
forwarder) is an application that mediates traffic between a protected
network and the Internet. Proxies are often used instead of router-based
traffic controls, to prevent traffic from passing directly between networks.
Many proxies contain extra logging or support for user authentication. Since
proxies must ``understand'' the application protocol being used, they can
also implement protocol specific security (e.g., an FTP proxy might be
configurable to permit incoming FTP and block outgoing FTP).

Proxy servers are application specific. In order to support a new
protocol via a proxy, a proxy must be developed for it. One popular set of
proxy servers is the TIS Internet Firewall Toolkit (``FWTK'') which includes
proxies for Telnet, rlogin, FTP, the X Window System, HTTP/Web, and
NNTP/Usenet news. SOCKS is a generic proxy system that can be compiled into
a client-side application to make it work through a firewall. Its advantage
is that it's easy to use, but it doesn't support the addition of
authentication hooks or protocol specific logging. For more information on
SOCKS, see http://www.socks.nec.com/.



3.4 What are some cheap packet screening tools?
The Texas A&M University security tools include software for
implementing screening routers. Karlbridge is a PC-based screening router
kit available from ftp://ftp.net.ohio-state.edu/pub/kbridge/.

There are numerous kernel-level packet screens, including ipf, ipfw,
ipchains, pf, and ipfwadm. Typically, these are included in various free
Unix implementations, such as FreeBSD, OpenBSD, NetBSD, and Linux. You might
also find these tools available in your commercial Unix implementation.

If you're willing to get your hands a little dirty, it's completely
possible to build a secure and fully functional firewall for the price of
hardware and some of your time.



3.5 What are some reasonable filtering rules for a kernel-based packet
screen?
This example is written specifically for ipfwadm on Linux, but the
principles (and even much of the syntax) applies for other kernel interfaces
for packet screening on ``open source'' Unix systems.

There are four basic categories covered by the ipfwadm rules:


-A
Packet Accounting
-I
Input firewall
-O
Output firewall
-F
Forwarding firewall
ipfwadm also has masquerading (-M) capabilities. For more information
on switches and options, see the ipfwadm man page.


3.5.1 Implementation
Here, our organization is using a private (RFC 1918) Class C network
192.168.1.0. Our ISP has assigned us the address 201.123.102.32 for our
gateway's external interface and 201.123.102.33 for our external mail
server. Organizational policy says:


Allow all outgoing TCP connections
Allow incoming SMTP and DNS to external mail server
Block all other traffic
The following block of commands can be placed in a system boot file
(perhaps rc.local on Unix systems).


ipfwadm -F -f
ipfwadm -F -p deny
ipfwadm -F -i m -b -P tcp -S 0.0.0.0/0 1024:65535 -D 201.123.102.33 25
ipfwadm -F -i m -b -P tcp -S 0.0.0.0/0 1024:65535 -D 201.123.102.33 53
ipfwadm -F -i m -b -P udp -S 0.0.0.0/0 1024:65535 -D 201.123.102.33 53
ipfwadm -F -a m -S 192.168.1.0/24 -D 0.0.0.0/0 -W eth0

/sbin/route add -host 201.123.102.33 gw 192.168.1.2


3.5.2 Explanation
Line one flushes (-f) all forwarding (-F) rules.
Line two sets the default policy (-p) to deny.
Lines three through five are input rules (-i) in the following format:
ipfwadm -F (forward) -i (input) m (masq.) -b (bi-directional) -P
protocol)[protocol]-S (source)[subnet/mask] [originating ports]-D
(destination)[subnet/mask][port]


Line six appends (-a) a rule that permits all internal IP addresses
out to all external addresses on all protocols, all ports.

Line eight adds a route so that traffic going to 201.123.102.33 will
be directed to the internal address 192.168.1.2.


3.6 What are some reasonable filtering rules for a Cisco?
The example in Figure 4 shows one possible configuration for using the
Cisco as filtering router. It is a sample that shows the implementation of
as specific policy. Your policy will undoubtedly vary.


Figure 4: Packet Filtering Router

In this example, a company has Class C network address 195.55.55.0.
Company network is connected to Internet via IP Service Provider. Company
policy is to allow everybody access to Internet services, so all outgoing
connections are accepted. All incoming connections go through ``mailhost''.
Mail and DNS are only incoming services.


3.6.1 Implementation

Allow all outgoing TCP-connections
Allow incoming SMTP and DNS to mailhost
Allow incoming FTP data connections to high TCP port (1024)
Try to protect services that live on high port numbers
Only incoming packets from Internet are checked in this configuration.
Rules are tested in order and stop when the first match is found. There is
an implicit deny rule at the end of an access list that denies everything.
This IP access list assumes that you are running Cisco IOS v. 10.3 or later.


no ip source-route
!
interface ethernet 0
ip address 195.55.55.1
no ip directed-broadcast
!
interface serial 0
no ip directed-broadcast
ip access-group 101 in
!
access-list 101 deny ip 127.0.0.0 0.255.255.255 any
access-list 101 deny ip 10.0.0.0 0.255.255.255 any
access-list 101 deny ip 172.16.0.0 0.15.255.255 any
access-list 101 deny ip 192.168.0.0 0.0.255.255 any
access-list 101 deny ip any 0.0.0.255 255.255.255.0
access-list 101 deny ip any 0.0.0.0 255.255.255.0
!
access-list 101 deny ip 195.55.55.0 0.0.0.255
access-list 101 permit tcp any any established
!
access-list 101 permit tcp any host 195.55.55.10 eq smtp
access-list 101 permit tcp any host 195.55.55.10 eq dns
access-list 101 permit udp any host 192.55.55.10 eq dns
!
access-list 101 deny tcp any any range 6000 6003
access-list 101 deny tcp any any range 2000 2003
access-list 101 deny tcp any any eq 2049
access-list 101 deny udp any any eq 2049
!
access-list 101 permit tcp any 20 any gt 1024
!
access-list 101 permit icmp any any
!
snmp-server community FOOBAR RO 2
line vty 0 4
access-class 2 in
access-list 2 permit 195.55.55.0 0.0.0.255


3.6.2 Explanations
Drop all source-routed packets. Source routing can be used for address
spoofing.
Drop directed broadcasts, which are used in smurf attacks.
If an incoming packet claims to be from a local net, loopback network,
or private network, drop it.
All packets which are part of already established TCP-connections can
pass through without further checking.
All connections to low port numbers are blocked except SMTP and DNS.
Block all services that listen for TCP connections on high port
numbers. X11 (port 6000+), OpenWindows (port 2000+) are a few candidates.
NFS (port 2049) runs usually over UDP, but it can be run over TCP, so you
should block it.
Incoming connections from port 20 into high port numbers are supposed
to be FTP data connections.
Access-list 2 limits access to router itself (telnet & SNMP)
All UDP traffic is blocked to protect RPC services

3.6.3 Shortcomings

You cannot enforce strong access policies with router access lists.
Users can easily install backdoors to their systems to get over ``no
incoming telnet'' or ``no X11'' rules. Also crackers install telnet
backdoors on systems where they break in.

You can never be sure what services you have listening for connections
on high port numbers. (You can't be sure of what services you have listening
for connections on low port numbers, either, especially in highly
decentralized environments where people can put their own machines on the
network or where they can get administrative access to their own machines.)

Checking the source port on incoming FTP data connections is a weak
security method. It also breaks access to some FTP sites. It makes use of
the service more difficult for users without preventing bad guys from
scanning your systems.
Use at least Cisco version 9.21 so you can filter incoming packets and
check for address spoofing. It's still better to use 10.3, where you get
some extra features (like filtering on source port) and some improvements on
filter syntax.

You have still a few ways to make your setup stronger. Block all
incoming TCP-connections and tell users to use passive-FTP clients. You can
also block outgoing ICMP echo-reply and destination-unreachable messages to
hide your network and to prevent use of network scanners. Cisco.com use to
have an archive of examples for building firewalls using Cisco routers, but
it doesn't seem to be online anymore. There are some notes on Cisco access
control lists, at least, at
ftp://ftp.cisco.com/pub/mibs/app_notes/access-lists.



3.7 What are the critical resources in a firewall?
It's important to understand the critical resources of your firewall
architecture, so when you do capacity planning, performance optimizations,
etc., you know exactly what you need to do, and how much you need to do it
in order to get the desired result.

What exactly the firewall's critical resources are tends to vary from
site to site, depending on the sort of traffic that loads the system. Some
people think they'll automatically be able to increase the data throughput
of their firewall by putting in a box with a faster CPU, or another CPU,
when this isn't necessarily the case. Potentially, this could be a large
waste of money that doesn't do anything to solve the problem at hand or
provide the expected scalability.

On busy systems, memory is extremely important. You have to have
enough RAM to support every instance of every program necessary to service
the load placed on that machine. Otherwise, the swapping will start and the
productivity will stop. Light swapping isn't usually much of a problem, but
if a system's swap space begins to get busy, then it's usually time for more
RAM. A system that's heavily swapping is often relatively easy to push over
the edge in a denial-of-service attack, or simply fall behind in processing
the load placed on it. This is where long email delays start.

Beyond the system's requirement for memory, it's useful to understand
that different services use different system resources. So the configuration
that you have for your system should be indicative of the kind of load you
plan to service. A 1400 MHz processor isn't going to do you much good if all
you're doing is netnews and mail, and are trying to do it on an IDE disk
with an ISA controller.





Table 1: Critical Resources for Firewall Services Service Critical
Resource
Email Disk I/O
Netnews Disk I/O
Web Host OS Socket Performance
IP Routing Host OS Socket Performance
Web Cache Host OS Socket Performance, Disk I/O







3.8 What is a DMZ, and why do I want one?
``DMZ'' is an abbreviation for ``demilitarized zone''. In the context
of firewalls, this refers to a part of the network that is neither part of
the internal network nor directly part of the Internet. Typically, this is
the area between your Internet access router and your bastion host, though
it can be between any two policy-enforcing components of your architecture.

A DMZ can be created by putting access control lists on your access
router. This minimizes the exposure of hosts on your external LAN by
allowing only recognized and managed services on those hosts to be
accessible by hosts on the Internet. Many commercial firewalls simply make a
third interface off of the bastion host and label it the DMZ, the point is
that the network is neither ``inside'' nor ``outside''.

For example, a web server running on NT might be vulnerable to a
number of denial-of-service attacks against such services as RPC, NetBIOS
and SMB. These services are not required for the operation of a web server,
so blocking TCP connections to ports 135, 137, 138, and 139 on that host
will reduce the exposure to a denial-of-service attack. In fact, if you
block everything but HTTP traffic to that host, an attacker will only have
one service to attack.

This illustrates an important principle: never offer attackers more to
work with than is absolutely necessary to support the services you want to
offer the public.



3.9 How might I increase the security and scalability of my DMZ?
A common approach for an attacker is to break into a host that's
vulnerable to attack, and exploit trust relationships between the vulnerable
host and more interesting targets.

If you are running a number of services that have different levels of
security, you might want to consider breaking your DMZ into several
``security zones''. This can be done by having a number of different
networks within the DMZ. For example, the access router could feed two
Ethernets, both protected by ACLs, and therefore in the DMZ.

On one of the Ethernets, you might have hosts whose purpose is to
service your organization's need for Internet connectivity. These will
likely relay mail, news, and host DNS. On the other Ethernet could be your
web server(s) and other hosts that provide services for the benefit of
Internet users.

In many organizations, services for Internet users tend to be less
carefully guarded and are more likely to be doing insecure things. (For
example, in the case of a web server, unauthenticated and untrusted users
might be running CGI, PHP, or other executable programs. This might be
reasonable for your web server, but brings with it a certain set of risks
that need to be managed. It is likely these services are too risky for an
organization to run them on a bastion host, where a slip-up can result in
the complete failure of the security mechanisms.)

By putting hosts with similar levels of risk on networks together in
the DMZ, you can help minimize the effect of a breakin at your site. If
someone breaks into your web server by exploiting some bug in your web
server, they'll not be able to use it as a launching point to break into
your private network if the web servers are on a separate LAN from the
bastion hosts, and you don't have any trust relationships between the web
server and bastion host.

Now, keep in mind that this is Ethernet. If someone breaks into your
web server, and your bastion host is on the same Ethernet, an attacker can
install a sniffer on your web server, and watch the traffic to and from your
bastion host. This might reveal things that can be used to break into the
bastion host and gain access to the internal network. (Switched Ethernet can
reduce your exposure to this kind of problem, but will not eliminate it.)

Splitting services up not only by host, but by network, and limiting
the level of trust between hosts on those networks, you can greatly reduce
the likelihood of a breakin on one host being used to break into the other.
Succinctly stated: breaking into the web server in this case won't make it
any easier to break into the bastion host.

You can also increase the scalability of your architecture by placing
hosts on different networks. The fewer machines that there are to share the
available bandwidth, the more bandwidth that each will get.



3.10 What is a `single point of failure', and how do I avoid having
one?
An architecture whose security hinges upon one mechanism has a single
point of failure. Software that runs bastion hosts has bugs. Applications
have bugs. Software that controls routers has bugs. It makes sense to use
all of these components to build a securely designed network, and to use
them in redundant ways.

If your firewall architecture is a screened subnet, you have two
packet filtering routers and a bastion host. (See question 3.2 from this
section.) Your Internet access router will not permit traffic from the
Internet to get all the way into your private network. However, if you don't
enforce that rule with any other mechanisms on the bastion host and/or choke
router, only one component of your architecture needs to fail or be
compromised in order to get inside. On the other hand, if you have a
redundant rule on the bastion host, and again on the choke router, an
attacker will need to defeat three mechanisms.

Further, if the bastion host or the choke router needs to invoke its
rule to block outside access to the internal network, you might want to have
it trigger an alarm of some sort, since you know that someone has gotten
through your access router.



3.11 How can I block all of the bad stuff?
For firewalls where the emphasis is on security instead of
connectivity, you should consider blocking everything by default, and only
specifically allowing what services you need on a case-by-case basis.

If you block everything, except a specific set of services, then
you've already made your job much easier. Instead of having to worry about
every security problem with everything product and service around, you only
need to worry about every security problem with a specific set of services
and products.

Before turning on a service, you should consider a couple of
questions:


Is the protocol for this product a well-known, published protocol?
Is the application to service this protocol available for public
inspection of its implementation?
How well known is the service and product?
How does allowing this service change the firewall architecture? Will
an attacker see things differently? Could it be exploited to get at my
internal network, or to change things on hosts in my DMZ?
When considering the above questions, keep the following in mind:


``Security through obscurity'' is no security at all. Unpublished
protocols have been examined by bad guys and defeated.
Despite what the marketing representatives say, not every protocol or
service is designed with security in mind. In fact, the number that are is
very few.
Even in cases where security is a consideration, not all organizations
have competent security staff. Among those who don't, not all are willing to
bring a competent consultant into the project. The end result is that
otherwise-competent, well-intended developers can design insecure systems.
The less that a vendor is willing to tell you about how their system
really works, the more likely it is that security (or other) problems exist.
Only vendors with something to hide have a reason to hide their designs and
implementations [2].


3.12 How can I restrict web access so users can't view sites unrelated
to work?
A few years ago, someone got the idea that it's a good idea to block
``bad'' web sites, i.e., those that contain material that The Company views
``inappropriate''. The idea has been increasing in popularity, but there are
several things to consider when thinking about implementing such controls in
your firewall.


It is not possible to practically block everything that an employer
deems ``inappropriate''. The Internet is full of every sort of material.
Blocking one source will only redirect traffic to another source of such
material, or cause someone to figure a way around the block.
Most organizations do not have a standard for judging the
appropriateness of material that their employees bring to work, e.g., books
and magazines. Do you inspect everyone's briefcase for ``inappropriate
material'' every day? If you do not, then why would you inspect every packet
for ``inappropriate material''? Any decisions along those lines in such an
organization will be arbitrary. Attempting to take disciplinary action
against an employee where the only standard is arbitrary typically isn't
wise, for reasons well beyond the scope of this document.
Products that perform site-blocking, commercial and otherwise, are
typically easy to circumvent. Hostnames can be rewritten as IP addresses. IP
addresses can be written as a 32-bit integer value, or as four 8-bit
integers (the most common form). Other possibilities exist, as well.
Connections can be proxied. Web pages can be fetched via email. You can't
block them all. The effort that you'll spend trying to implement and manage
such controls will almost certainly far exceed any level of damage control
that you're hoping to have.
The rule-of-thumb to remember here is that you cannot solve social
problems with technology. If there is a problem with someone going to an
``inappropriate'' web site, that is because someone else saw it and was
offended by what he saw, or because that person's productivity is below
expectations. In either case, those are matters for the personnel
department, not the firewall administrator.



4 Various Attacks


4.1 What is source routed traffic and why is it a threat?
Normally, the route a packet takes from its source to its destination
is determined by the routers between the source and destination. The packet
itself only says where it wants to go (the destination address), and nothing
about how it expects to get there.

There is an optional way for the sender of a packet (the source) to
include information in the packet that tells the route the packet should
take to get to its destination; thus the name ``source routing''. For a
firewall, source routing is noteworthy, since an attacker can generate
traffic claiming to be from a system ``inside'' the firewall. In general,
such traffic wouldn't route to the firewall properly, but with the source
routing option, all the routers between the attacker's machine and the
target will return traffic along the reverse path of the source route.
Implementing such an attack is quite easy; so firewall builders should not
discount it as unlikely to happen.

In practice, source routing is very little used. In fact, generally
the main legitimate use is in debugging network problems or routing traffic
over specific links for congestion control for specialized situations. When
building a firewall, source routing should be blocked at some point. Most
commercial routers incorporate the ability to block source routing
specifically, and many versions of Unix that might be used to build firewall
bastion hosts have the ability to disable or to ignore source routed
traffic.



4.2 What are ICMP redirects and redirect bombs?
An ICMP Redirect tells the recipient system to override something in
its routing table. It is legitimately used by routers to tell hosts that the
host is using a non-optimal or defunct route to a particular destination,
i.e., the host is sending it to the wrong router. The wrong router sends the
host back an ICMP Redirect packet that tells the host what the correct route
should be. If you can forge ICMP Redirect packets, and if your target host
pays attention to them, you can alter the routing tables on the host and
possibly subvert the security of the host by causing traffic to flow via a
path the network manager didn't intend. ICMP Redirects also may be employed
for denial of service attacks, where a host is sent a route that loses it
connectivity, or is sent an ICMP Network Unreachable packet telling it that
it can no longer access a particular network.

Many firewall builders screen ICMP traffic from their network, since
it limits the ability of outsiders to ping hosts, or modify their routing
tables.

Before you decide to block all ICMP packets, you should be aware of
how the TCP protocol does ``Path MTU Discovery'', to make certain that you
don't break connectivity to other sites. If you can't safely block it
everywhere, you can consider allowing selected types of ICMP to selected
routing devices. If you don't block it, you should at least ensure that your
routers and hosts don't respond to broadcast ping packets.



4.3 What about denial of service?
Denial of service is when someone decides to make your network or
firewall useless by disrupting it, crashing it, jamming it, or flooding it.
The problem with denial of service on the Internet is that it is impossible
to prevent. The reason has to do with the distributed nature of the network:
every network node is connected via other networks which in turn connect to
other networks, etc. A firewall administrator or ISP only has control of a
few of the local elements within reach. An attacker can always disrupt a
connection ``upstream'' from where the victim controls it. In other words,
if someone wanted to take a network off the air, he could do it either by
taking the network off the air, or by taking the networks it connects to off
the air, ad infinitum. There are many, many, ways someone can deny service,
ranging from the complex to the trivial brute-force. If you are considering
using Internet for a service which is absolutely time or mission critical,
you should consider your fallback position in the event that the network is
down or damaged.

TCP/IP's UDP echo service is trivially abused to get two servers to
flood a network segment with echo packets. You should consider commenting
out unused entries in /etc/inetd.conf of Unix hosts, adding no ip
small-servers to Cisco routers, or the equivalent for your components.



4.4 What are some common attacks, and how can I protect my system
against them?
Each site is a little different from every other in terms of what
attacks are likely to be used against it. Some recurring themes do arise,
though.


4.4.1 SMTP Server Hijacking (Unauthorized Relaying)
This is where a spammer will take many thousands of copies of a
message and send it to a huge list of email addresses. Because these lists
are often so bad, and in order to increase the speed of operation for the
spammer, many have resorted to simply sending all of their mail to an SMTP
server that will take care of actually delivering the mail.

Of course, all of the bounces, spam complaints, hate mail, and bad PR
come for the site that was used as a relay. There is a very real cost
associated with this, mostly in paying people to clean up the mess
afterward.

The Mail Abuse Prevention System1Transport Security
Initiative2maintains a complete description of the problem, and how to
configure about every mailer on the planet to protect against this attack.


4.4.2 Exploiting Bugs in Applications
Various versions of web servers, mail servers, and other Internet
service software contain bugs that allow remote (Internet) users to do
things ranging from gain control of the machine to making that application
crash and just about everything in between.

The exposure to this risk can be reduced by running only necessary
services, keeping up to date on patches, and using products that have been
around a while.


4.4.3 Bugs in Operating Systems
Again, these are typically initiated by users remotely. Operating
systems that are relatively new to IP networking tend to be more
problematic, as more mature operating systems have had time to find and
eliminate their bugs. An attacker can often make the target equipment
continuously reboot, crash, lose the ability to talk to the network, or
replace files on the machine.

Here, running as few operating system services as possible can help.
Also, having a packet filter in front of the operating system can reduce the
exposure to a large number of these types of attacks.

And, of course, chosing a stable operating system will help here as
well. When selecting an OS, don't be fooled into believing that ``the
pricier, the better''. Free operating systems are often much more robust
than their commercial counterparts



5 How Do I...


5.1 Do I really want to allow everything that my users ask for?
It's entirely possible that the answer is ``no''. Each site has its
own policies about what is and isn't needed, but it's important to remember
that a large part of the job of being an organization's gatekeeper is
education. Users want streaming video, real-time chat, and to be able to
offer services to external customers that require interaction with live
databases on the internal network.

That doesn't mean that any of these things can be done without
presenting more risk to the organization than the supposed ``value'' of
heading down that road is worth. Most users don't want to put their
organization at risk. They just read the trade rags, see advertisements, and
they want to do those things, too. It's important to look into what it is
that they really want to do, and to help them understand how they might be
able to accomplish their real objective in a more secure manner.

You won't always be popular, and you might even find yourself being
given direction to do something incredibly stupid, like ``just open up ports
foo through bar''. If that happens, don't worry about it. It would be wise
to keep all of your exchanges on such an event so that when a 12-year-old
script kiddie breaks in, you'll at least be able to separate yourself from
the whole mess.



5.2 How do I make Web/HTTP work through my firewall?
There are three ways to do it.


Allow ``established'' connections out via a router, if you are using
screening routers.
Use a web client that supports SOCKS, and run SOCKS on your bastion
host.
Run some kind of proxy-capable web server on the bastion host. Some
options include Squid3, Apache4, Netscape Proxy5, and http-gw from the TIS
firewall toolkit. Most of these can also proxy other protocols (such as
gopher and ftp), and can cache objects fetched, which will also typically
result in a performance boost for the users, and more efficient use of your
connection to the Internet. Essentially all web clients (Mozilla, Internet
Explorer, Lynx, etc.) have proxy server support built directly into them.


5.3 How do I make SSL work through the firewall?
SSL is a protocol that allows secure connections across the Internet.
Typically, SSL is used to protect HTTP traffic. However, other protocols
(such as telnet) can run atop SSL.

Enabling SSL through your firewall can be done the same way that you
would allow HTTP traffic, if it's HTTP that you're using SSL to secure,
which is usually true. The only difference is that instead of using
something that will simply relay HTTP, you'll need something that can tunnel
SSL. This is a feature present on most web object caches.

You can find out more about SSL from Netscape6.


Back to Top
Marcus J. Ranum's Firewall FAQ Part 2
5.4 How do I make DNS work with a firewall?
Some organizations want to hide DNS names from the outside. Many
experts don't think hiding DNS names is worthwhile, but if site/corporate
policy mandates hiding domain names, this is one approach that is known to
work. Another reason you may have to hide domain names is if you have a
non-standard addressing scheme on your internal network. In that case, you
have no choice but to hide those addresses. Don't fool yourself into
thinking that if your DNS names are hidden that it will slow an attacker
down much if they break into your firewall. Information about what is on
your network is too easily gleaned from the networking layer itself. If you
want an interesting demonstration of this, ping the subnet broadcast address
on your LAN and then do an ``arp -a.'' Note also that hiding names in the
DNS doesn't address the problem of host names ``leaking'' out in mail
headers, news articles, etc.

This approach is one of many, and is useful for organizations that
wish to hide their host names from the Internet. The success of this
approach lies on the fact that DNS clients on a machine don't have to talk
to a DNS server on that same machine. In other words, just because there's a
DNS server on a machine, there's nothing wrong with (and there are often
advantages to) redirecting that machine's DNS client activity to a DNS
server on another machine.

First, you set up a DNS server on the bastion host that the outside
world can talk to. You set this server up so that it claims to be
authoritative for your domains. In fact, all this server knows is what you
want the outside world to know; the names and addresses of your gateways,
your wildcard MX records, and so forth. This is the ``public'' server.

Then, you set up a DNS server on an internal machine. This server also
claims to be authoritative for your domains; unlike the public server, this
one is telling the truth. This is your ``normal'' nameserver, into which you
put all your ``normal'' DNS stuff. You also set this server up to forward
queries that it can't resolve to the public server (using a ``forwarders''
line in /etc/named.boot on a Unix machine, for example).

Finally, you set up all your DNS clients (the /etc/resolv.conf file on
a Unix box, for instance), including the ones on the machine with the public
server, to use the internal server. This is the key.

An internal client asking about an internal host asks the internal
server, and gets an answer; an internal client asking about an external host
asks the internal server, which asks the public server, which asks the
Internet, and the answer is relayed back. A client on the public server
works just the same way. An external client, however, asking about an
internal host gets back the ``restricted'' answer from the public server.

This approach assumes that there's a packet filtering firewall between
these two servers that will allow them to talk DNS to each other, but
otherwise restricts DNS between other hosts.

Another trick that's useful in this scheme is to employ wildcard PTR
records in your IN-ADDR.ARPA domains. These cause an an address-to-name
lookup for any of your non-public hosts to return something like
``unknown.YOUR.DOMAIN'' rather than an error. This satisfies anonymous FTP
sites like ftp.uu.net that insist on having a name for the machines they
talk to. This may fail when talking to sites that do a DNS cross-check in
which the host name is matched against its address and vice versa.



5.5 How do I make FTP work through my firewall?
Generally, making FTP work through the firewall is done either using a
proxy server such as the firewall toolkit's ftp-gw or by permitting incoming
connections to the network at a restricted port range, and otherwise
restricting incoming connections using something like ``established''
screening rules. The FTP client is then modified to bind the data port to a
port within that range. This entails being able to modify the FTP client
application on internal hosts.

In some cases, if FTP downloads are all you wish to support, you might
want to consider declaring FTP a ``dead protocol'' and letting you users
download files via the Web instead. The user interface certainly is nicer,
and it gets around the ugly callback port problem. If you choose the
FTP-via-Web approach, your users will be unable to FTP files out, which,
depending on what you are trying to accomplish, may be a problem.

A different approach is to use the FTP ``PASV'' option to indicate
that the remote FTP server should permit the client to initiate connections.
The PASV approach assumes that the FTP server on the remote system supports
that operation. (See ``Firewall-Friendly FTP'' [1].)

Other sites prefer to build client versions of the FTP program that
are linked against a SOCKS library.



5.6 How do I make Telnet work through my firewall?
Telnet is generally supported either by using an application proxy
such as the firewall toolkit's tn-gw, or by simply configuring a router to
permit outgoing connections using something like the ``established''
screening rules. Application proxies could be in the form of a standalone
proxy running on the bastion host, or in the form of a SOCKS server and a
modified client.



5.7 How do I make Finger and whois work through my firewall?
Many firewall admins permit connections to the finger port from only
trusted machines, which can issue finger requests in the form of: finger
user@host.domain@firewall. This approach only works with the standard Unix
version of finger. Controlling access to services and restricting them to
specific machines is managed using either tcp_wrappers or netacl from the
firewall toolkit. This approach will not work on all systems, since some
finger servers do not permit user@host@host fingering.

Many sites block inbound finger requests for a variety of reasons,
foremost being past security bugs in the finger server (the Morris internet
worm made these bugs famous) and the risk of proprietary or sensitive
information being revealed in user's finger information. In general,
however, if your users are accustomed to putting proprietary or sensitive
information in their .plan files, you have a more serious security problem
than just a firewall can solve.



5.8 How do I make gopher, archie, and other services work through my
firewall?
The majority of firewall administrators choose to support gopher and
archie through web proxies, instead of directly. Proxies such as the
firewall toolkit's http-gw convert gopher/gopher+ queries into HTML and vice
versa. For supporting archie and other queries, many sites rely on
Internet-based Web-to-archie servers, such as ArchiePlex. The Web's tendency
to make everything on the Internet look like a web service is both a
blessing and a curse.

There are many new services constantly cropping up. Often they are
misdesigned or are not designed with security in mind, and their designers
will cheerfully tell you if you want to use them you need to let port xxx
through your router. Unfortunately, not everyone can do that, and so a
number of interesting new toys are difficult to use for people behind
firewalls. Things like RealAudio, which require direct UDP access, are
particularly egregious examples. The thing to bear in mind if you find
yourself faced with one of these problems is to find out as much as you can
about the security risks that the service may present, before you just allow
it through. It's quite possible the service has no security implications.
It's equally possible that it has undiscovered holes you could drive a truck
through.



5.9 What are the issues about X11 through a firewall?
The X Windows System is a very useful system, but unfortunately has
some major security flaws. Remote systems that can gain or spoof access to a
workstation's X11 display can monitor keystrokes that a user enters,
download copies of the contents of their windows, etc.

While attempts have been made to overcome them (E.g., MIT ``Magic
Cookie'') it is still entirely too easy for an attacker to interfere with a
user's X11 display. Most firewalls block all X11 traffic. Some permit X11
traffic through application proxies such as the DEC CRL X11 proxy (FTP
crl.dec.com). The firewall toolkit includes a proxy for X11, called x-gw,
which a user can invoke via the Telnet proxy, to create a virtual X11 server
on the firewall. When requests are made for an X11 connection on the virtual
X11 server, the user is presented with a pop-up asking them if it is OK to
allow the connection. While this is a little unaesthetic, it's entirely in
keeping with the rest of X11.



5.10 How do I make RealAudio work through my firewall?
RealNetworks maintains some information about how to get RealAudio
working through your firewall7. It would be unwise to make any changes to
your firewall without understanding what the changes will do, exactly, and
knowing what risks the new changes will bring with them.



5.11 How do I make my web server act as a front-end for a database
that lives on my private network?
The best way to do this is to allow very limited connectivity between
your web server and your database server via a specific protocol that only
supports the level of functionality you're going to use. Allowing raw SQL,
or anything else where custom extractions could be performed by an attacker
isn't generally a good idea.

Assume that an attacker is going to be able to break into your web
server, and make queries in the same way that the web server can. Is there a
mechanism for extracting sensitive information that the web server doesn't
need, like credit card information? Can an attacker issue an SQL select and
extract your entire proprietary database?

``E-commerce'' applications, like everything else, are best designed
with security in mind from the ground up, instead of having security
``added'' as an afterthought. Review your architecture critically, from the
perspective of an attacker. Assume that the attacker knows everything about
your architecture. Now ask yourself what needs to be done to steal your
data, to make unauthorized changes, or to do anything else that you don't
want done. You might find that you can significantly increase security
without decreasing functionality by making a few design and implementation
decisions.

Some ideas for how to handle this:


Extract the data you need from the database on a regular basis so
you're not making queries against the full database, complete with
information that attackers will find interesting.
Greatly restrict and audit what you do allow between the web server
and database.


5.12 But my database has an integrated web server, and I want to use
that. Can't I just poke a hole in the firewall and tunnel that port?
If your site firewall policy is sufficiently lax that you're willing
to manage the risk that someone will exploit a vulnerability in your web
server that will result in partial or complete exposure of your database,
then there isn't much preventing you from doing this.

However, in many organizations, the people who are responsible for
tying the web front end to the database back end simply do not have the
authority to take that responsibility. Further, if the information in the
database is about people, you might find yourself guilty of breaking a
number of laws if you haven't taken reasonable precautions to prevent the
system from being abused.

In general, this isn't a good idea. See question 5.11 for some ideas
on other ways to accomplish this objective.



5.13 How Do I Make IP Multicast Work With My Firewall?
IP multicast is a means of getting IP traffic from one host to a set
of hosts without using broadcasting; that is, instead of every host getting
the traffic, only those that want it will get it, without each having to
maintain a separate connection to the server. IP unicast is where one host
talks to another, multicast is where one host talks to a set of hosts, and
broadcast is where one host talks to all hosts.

The public Internet has a multicast backbone (``MBone'') where users
can engage in multicast traffic exchange. Common uses for the MBone are
streams of IETF meetings and similar such interaction. Getting one's own
network connected to the MBone will require that the upstream provider route
multicast traffic to and from your network. Additionally, your internal
network will have to support multicast routing.

The role of the firewall in multicast routing, conceptually, is no
different from its role in other traffic routing. That is, a policy that
identifies which multicast groups are and aren't allowed must be defined and
then a system of allowing that traffic according to policy must be devised.
Great detail on how exactly to do this is beyond the scope of this document.
Fortunately, RFC 2588 [4] discusses the subject in more detail. Unless your
firewall product supports some means of selective multicast forwarding or
you have the ability to put it in yourself, you might find forwarding
multicast traffic in a way consistent with your security policy to be a
bigger headache than it's worth.



6 TCP and UDP Ports
by Mikael Olsson
This appendix will begin at a fairly ``basic'' level, so even if the
first points seem childishly self-evident to you, you might still learn
something from skipping ahead to something later in the text.



6.1 What is a port?
A ``port'' is ``virtual slot'' in your TCP and UDP stack that is used
to map a connection between two hosts, and also between the TCP/UDP layer
and the actual applications running on the hosts.

They are numbered 0-65535, with the range 0-1023 being marked as
``reserved'' or ``privlileged'', and the rest (1024-65535) as ``dynamic'' or
``unprivileged''.

There are basically two uses for ports:


``Listening'' on a port.
This is used by server applications waiting for users to connect, to
get to some ``well known service'', for instance HTTP (TCP port 80), Telnet
(TCP port 23), DNS (UDP and sometimes TCP port 53).
Opening a ``dynamic'' port.
Both sides of a TCP connection need to be identified by IP addresses
and port numbers. Hence, when you want to ``connect'' to a server process,
your end of the communications channel also needs a ``port''. This is done
by choosing a port above 1024 on your machine that is not currently in use
by another communications channel, and using it as the ``sender'' in the new
connection.
Dynamic ports may also be used as ``listening'' ports in some
applications, most notably FTP.

Ports in the range 0-1023 are almost always server ports. Ports in the
range 1024-65535 are usually dynamic ports (i.e., opened dynamically when
you connect to a server port). However, any port may be used as a server
port, and any port may be used as an ``outgoing'' port.

So, to sum it up, here's what happens in a basic connection:

At some point in time, a server application on host 1.2.3.4 decides to
``listen'' at port 80 (HTTP) for new connections.
You (5.6.7.8) want to surf to 1.2.3.4, port 80, and your browser
issues a connect call to it.
The connect call, realising that it doesn't yet have local port
number, goes hunting for one. The local port number is necessary since when
the replies come back some time in the future, your TCP/IP stack will have
to know to what application to pass the reply. It does this by remembering
what application uses which local port number. (This is grossly simplified,
no flames from programmers, please.)
Your TCP stack finds an unused dynamic port, usually somewhere above
1024. Let's assume that it finds 1029.
Your first packet is then sent, from your local IP, 5.6.7.8, port
1029, to 1.2.3.4, port 80.
The server responds with a packet from 1.2.3.4, port 80, to you,
5.6.7.8, port 1029.
This procedure is actually longer than this, read on for a more
in-depth explanation of TCP connect sequences.


6.2 How do I know which application uses what port?
There are several lists outlining the ``reserved'' and ``well known''
ports, as well as ``commonly used'' ports, and the best one is:
ftp://ftp.isi.edu/in-notes/iana/assi...s/port-numbers. For those of you
still reading RFC 1700 to find out what port number does what, STOP DOING
IT. It is horribly out of date, and it won't be less so tomorrow.

Now, as for trusting this information: These lists do not, in any way,
constitute any kind of holy bible on which ports do what.

Wait, let me rephrase that: THERE IS NO WAY OF RELIABLY DETERMINING
WHAT PORT DOES WHAT SIMPLY BY LOOKING IN A LIST.



6.3 What are LISTENING ports?
Suppose you did ``netstat -a'' on your machine and ports 1025 and 1030
showed up as LISTENing. What do they do?

Right, let's take a look in the assigned port numbers list.


blackjack 1025/tcp network blackjack
iad1 1030/tcp BBN IAD

Wait, what's happening? Has my workstation stolen my VISA number and
decided to go play blackjack with some rogue server on the internet? And
what's that software that BBN has installed?

This is NOT where you start panicking and send mail to the firewalls
list. In fact, this question has been asked maybe a dozen times during the
past six months, and every time it's been answered. Not that THAT keeps
people from asking the same question again.

If you are asking this question, you are most likely using a windows
box. The ports you are seeing are (most likely) two listening ports that the
RPC subsystem opens when it starts up.

This is an example of where dynamicly assigned ports may be used by
server processes. Applications using RPC will later on connect to port 135
(the netbios ``portmapper'') to query where to find some RPC service, and
get an answer back saying that that particular service may be contacted on
port 1025.

Now, how do we know this, since there's no ``list'' describing these
ports? Simple: There's no substitute for experience. And using the mailing
list search engines also helps a hell of a lot.



6.4 How do I determine what service the port is for?
Since it is impossible to learn what port does what by looking in a
list, how do i do it?

The old hands-on way of doing it is by shutting down nearly every
service/daemon running on your machine, doing netstat -a and taking note of
what ports are open. There shouldn't be very many listening ones. Then you
start turning all the services on, one by one, and take note of what new
ports show up in your netstat output.

Another way, that needs more guess work, is simply telnetting to the
ports and see what comes out. If nothing comes out, try typing some
gibberish and slamming Enter a few times, and see if something turns up. If
you get binary garble, or nothing at all, this obviously won't help you.

However, this will only tell you what listening ports are used. It
won't tell you about dynamically opened ports that may be opened later on by
these applications.

There are a few applications that might help you track down the ports
used.

On Unix systems, there's a nice utility called lsof that comes
preinstalled on many systems. It will show you all open port numbers and the
names of the applications that are using them. This means that it might show
you a lot of locally opened files aswell as TCP/IP sockets. Read the help
text.

On windows systems, nothing comes preinstalled to assist you in this
task. (What's new?) There's a utility called ``Inzider'' which installs
itself inside the windows sockets layer and dynamically remembers which
process opens which port. The drawback of this approach is that it can't
tell you what ports were opened before inzider started, but it's the best
that you'll get on windows (to my knowledge).
http://ntsecurity.nu/toolbox/inzider/.



6.5 What ports are safe to pass through a firewall?
ALL.

No, wait, NONE.

No, wait, uuhhh... I've heard that all ports above 1024 are safe since
they're only dynamic??

No. Really. You CANNOT tell what ports are safe simply by looking at
its number, simply because that is really all it is. A number. You can't
mount an attack through a 16-bit number.

The security of a ``port'' depends on what application you'll reach
through that port.

A common misconception is that ports 25 (SMTP) and 80 (HTTP) are safe
to pass through a firewall. *meep* WRONG. Just because everyone is doing it
doesn't mean that it is safe.

Again, the security of a port depends on what application you'll reach
through that port.

If you're running a well-written web server, that is designed from the
ground up to be secure, you can probably feel reasonably assured that it's
safe to let outside people access it through port 80. Otherwise, you CAN'T.

The problem here is not in the network layer. It's in how the
application processes the data that it receives. This data may be received
through port 80, port 666, a serial line, floppy or through singing
telegram. If the application is not safe, it does not matter how the data
gets to it. The application data is where the real danger lies.

If you are interested in the security of your application, go
subscribe to bugtraq8or or try searching their archives.

This is more of an application security issue rather than a firewall
security issue. One could argue that a firewall should stop all possible
attacks, but with the number of new network protocols, NOT designed with
security in mind, and networked applications, neither designed with security
in mind, it becomes impossible for a firewall to protect against all
data-driven attacks.



6.6 The behavior of FTP
Or, ``Why do I have to open all ports above 1024 to my FTP server?''

FTP doesn't really look a whole lot like other applications from a
networking perspective.

It keeps one listening port, port 21, which users connect to. All it
does is let people log on, and establish ANOTHER connection to do actual
data transfers. This second connection is usually on some port above 1024.

There are two modes, ``active'' (normal) and ``passive'' mode. This
word describes the server's behaviour.

In active mode, the client (5.6.7.8) connects to port 21 on the server
(1.2.3.4) and logs on. When file transfers are due, the client allocates a
dynamic port above 1024, informs the server about which port it opened, and
then the server opens a new connection to that port. This is the ``active''
role of the server: it actively establishes new connections to the client.

In passive mode, the connection to port 21 is the same. When file
transfers are due, the SERVER allocates a dynamic port above 1024, informs
the client about which port it opened, and then the CLIENT opens a new
connection to that port. This is the ``passive'' role of the server: it
waits for the client to establish the second (data) connection.

If your firewall doesn't inspect the application data of the FTP
command connection, it won't know that it needs to dynamically open new
ports above 1024.

On a side note: The traditional behaviour of FTP servers in active
mode is to establish the data session FROM port 20, and to the dynamic port
on the client. FTP servers are steering away from this behaviour somewhat
due to the need to run as ``root'' on unix systems in order to be able to
allocate ports below 1024. Running as ``root'' is not good for security,
since if there's a bug in the software, the attacker would be able to
compromise the entire machine. The same goes for running as
``Administrator'' or ``SYSTEM'' (``LocalSystem'') on NT machines, although
the low port problem does not apply on NT.

To sum it up, if your firewall understands FTP, it'll be able to
handle the data connections by itself, and you won't have to worry about
ports above 1024.

If it does NOT, there are four issues that you need to address:

Firewalling an FTP server in active mode
You need to let your server open new connections to the outside world
on ports 1024 and above
Firewalling an FTP server in passive mode
You need to let the outside world connect to ports 1024 and above on
your server. CAUTION!!!! There may be applications running on some of these
ports that you do NOT want outside people using. Disallow access to these
ports before allowing access to the 1024-65535 port range.
Firewalling FTP clients in active mode
You need to let the outside world connect to ports 1024 and above on
your clients. CAUTION!!!! There may be applications running on some of these
ports that you do NOT want outside people using. Disallow access to these
ports before allowing access to the 1024-65535 port range.
Firewalling FTP clients in passive mode
You need to let your clients open new connections to the outside world
on ports 1024 and above.
Again, if your firewall understands FTP, none of the four points above
apply to you. Let the firewall do the job for you.



6.7 What software uses what FTP mode?
It is up to the client to decide what mode to use; the default mode
when a new connection is opened is ``active mode''.

Most FTP clients come preconfigured to use active mode, but provide an
option to use ``passive'' (``PASV'') mode. An exception is the windows
command line FTP client which only operates in active mode.

Web Browsers generally use passive mode when connecting via FTP, with
a weird exception: MSIE 5 will use active FTP when FTP:ing in ``File
Explorer'' mode and passive FTP when FTP:ing in ``Web Page'' mode. There is
no reason whatsoever for this behaviour; my guess is that someone in Redmond
with no knowledge of FTP decided that ``Of course we'll use active mode when
we're in file explorer mode, since that looks more active than a web page''.
Go figure.



6.8 Is my firewall trying to connect outside?
My firewall logs are telling me that my web server is trying to
connect from port 80 to ports above 1024 on the outside. What is this?!

If you are seeing dropped packets from port 80 on your web server (or
from port 25 on your mail server) to high ports on the outside, they usually
DO NOT mean that your web server is trying to connect somewhere.

They are the result of the firewall timing out a connection, and
seeing the server retransmitting old responses (or trying to close the
connection) to the client.

TCP connections always involve packets traveling in BOTH directions in
the connection.

If you are able to see the TCP flags in the dropped packets, you'll
see that the ACK flag is set but not the SYN flag, meaning that this is
actually not a new connection forming, but rather a response of a previously
formed connection.

Read point 8 below for an in-depth explanation of what happens when
TCP connections are formed (and closed)



6.9 The anatomy of a TCP connection
TCP is equipped with 6 ``flags'', which may be ON or OFF. These flags
are:

FIN
``Controlled'' connection close
SYN
Open new connection
RST
``Immediate'' connection close
PSH
Instruct receiver host to push the data up to the application rather
than just queue it
ACK
``Acknowledge'' a previous packet
URG
``Urgent'' data which needs to be processed immediately
In this example, your client is 5.6.7.8, and the port assigned to you
dynamically is 1049. The server is 1.2.3.4, port 80.

You begin the connection attempt:

5.6.7.8:1049 -> 1.2.3.4:80 SYN=ON

The server receives this packet and understands that someone wants to
form a new connection. A response is sent:

1.2.3.4:80 -> 5.6.7.8:1049 SYN=ON ACK=ON

The client receives the response, and informs that the response is
received

5.6.7.8:1049 -> 1.2.3.4:80 ACK=ON

Here, the connection is opened. This is called a three-way handshake.
Its purpose is to verify to BOTH hosts that they have a working connection
between them.

The internet being what it is, unreliable and flooded, there are
provisions to compensate for packet loss.

If the client sends out the initial SYN without receiving a SYN+ACK
within a few seconds, it'll resend the SYN.

If the server sends out the SYN+ACK without receiving an ACK in a few
seconds, it'll resend the SYN+ACK packet.

The latter is actually the reason that SYN flooding works so well. If
you send out SYN packets from lots of different ports, this will tie up a
lot of resources on the server. If you also refuse to respond to the
returned SYN+ACK packets, the server will KEEP these connections for a long
time, resending the SYN+ACK packets. Some servers will not accept new
connections while there are enough connections currently forming; this is
why SYN flooding works.

All packets transmitted in either direction after the three-way
handshake will have the ACK bit set. Stateless packet filters make use of
this in the so called ``established'' filters: They will only let packets
through that have the ACK bit set. This way, no packet may pass through in a
certain direction that could form a new connection. Typically, you don't
allow outside hosts to open new connections to inside hosts by requiring the
ACK bit set on these packets.

When the time has come to close the connection, there are two ways of
doing it: Using the FIN flag, or using the RST flag. Using FIN flags, both
implementations are required to send out FIN flags to indicate that they
want to close the connection, and then send out acknowledgements to these
FINs, indicating that they understood that the other end wants to close the
connection. When sending out RST's, the connection is closed forcefully, and
you don't really get an indication of whether the other end understood your
reset order, or that it has in fact received all data that you sent to it.

The FIN way of closing the connection also exposes you to a
denial-of-service situation, since the TCP stack needs to remember the
closed connection for a fairly long time, in case the other end hasn't
received one of the FIN packets.

If sufficiently many connections are opened and closed, you may end up
having ``closed'' connections in all your connection slots. This way, you
wouldn't be able to dynamically allocate more connections, seeing that
they're all used. Different OSes handle this situation differently.




A. Some Commercial Products and Vendors
We feel this topic is too sensitive to address in a FAQ, however, an
independently maintained list (no warranty or recommendations are implied)
can be found online.9



B. Glossary of Firewall-Related Terms

Abuse of Privilege
When a user performs an action that they should not have, according to
organizational policy or law.

Access Control Lists
Rules for packet filters (typically routers) that define which packets
to pass and which to block.

Access Router
A router that connects your network to the external Internet.
Typically, this is your first line of defense against attackers from the
outside Internet. By enabling access control lists on this router, you'll be
able to provide a level of protection for all of the hosts ``behind'' that
router, effectively making that network a DMZ instead of an unprotected
external LAN.

Application-Layer Firewall
A firewall system in which service is provided by processes that
maintain complete TCP connection state and sequencing. Application layer
firewalls often re-address traffic so that outgoing traffic appears to have
originated from the firewall, rather than the internal host.

Authentication
The process of determining the identity of a user that is attempting
to access a system.

Authentication Token
A portable device used for authenticating a user. Authentication
tokens operate by challenge/response, time-based code sequences, or other
techniques. This may include paper-based lists of one-time passwords.

Authorization
The process of determining what types of activities are permitted.
Usually, authorization is in the context of authentication: once you have
authenticated a user, they may be authorized different types of access or
activity.

Bastion Host
A system that has been hardened to resist attack, and which is
installed on a network in such a way that it is expected to potentially come
under attack. Bastion hosts are often components of firewalls, or may be
``outside'' web servers or public access systems. Generally, a bastion host
is running some form of general purpose operating system (e.g., Unix, VMS,
NT, etc.) rather than a ROM-based or firmware operating system.

Challenge/Response
An authentication technique whereby a server sends an unpredictable
challenge to the user, who computes a response using some form of
authentication token.

Chroot
A technique under Unix whereby a process is permanently restricted to
an isolated subset of the filesystem.

Cryptographic Checksum
A one-way function applied to a file to produce a unique
``fingerprint'' of the file for later reference. Checksum systems are a
primary means of detecting filesystem tampering on Unix.

Data Driven Attack
A form of attack in which the attack is encoded in innocuous-seeming
data which is executed by a user or other software to implement an attack.
In the case of firewalls, a data driven attack is a concern since it may get
through the firewall in data form and launch an attack against a system
behind the firewall.

Defense in Depth
The security approach whereby each system on the network is secured to
the greatest possible degree. May be used in conjunction with firewalls.

DNS spoofing
Assuming the DNS name of another system by either corrupting the name
service cache of a victim system, or by compromising a domain name server
for a valid domain.

Dual Homed Gateway
A dual homed gateway is a system that has two or more network
interfaces, each of which is connected to a different network. In firewall
configurations, a dual homed gateway usually acts to block or filter some or
all of the traffic trying to pass between the networks.

Encrypting Router
see Tunneling Router and Virtual Network Perimeter.

Firewall
A system or combination of systems that enforces a boundary between
two or more networks.

Host-based Security
The technique of securing an individual system from attack. Host based
security is operating system and version dependent.

Insider Attack
An attack originating from inside a protected network.

Intrusion Detection
Detection of break-ins or break-in attempts either manually or via
software expert systems that operate on logs or other information available
on the network.

IP Spoofing
An attack whereby a system attempts to illicitly impersonate another
system by using its IP network address.

IP Splicing / Hijacking
An attack whereby an active, established, session is intercepted and
co-opted by the attacker. IP Splicing attacks may occur after an
authentication has been made, permitting the attacker to assume the role of
an already authorized user. Primary protections against IP Splicing rely on
encryption at the session or network layer.

Least Privilege
Designing operational aspects of a system to operate with a minimum
amount of system privilege. This reduces the authorization level at which
various actions are performed and decreases the chance that a process or
user with high privileges may be caused to perform unauthorized activity
resulting in a security breach.

Logging
The process of storing information about events that occurred on the
firewall or network.

Log Retention
How long audit logs are retained and maintained.

Log Processing
How audit logs are processed, searched for key events, or summarized.

Network-Layer Firewall
A firewall in which traffic is examined at the network protocol packet
layer.

Perimeter-based Security
The technique of securing a network by controlling access to all entry
and exit points of the network.

Policy
Organization-level rules governing acceptable use of computing
resources, security practices, and operational procedures.

Proxy
A software agent that acts on behalf of a user. Typical proxies accept
a connection from a user, make a decision as to whether or not the user or
client IP address is permitted to use the proxy, perhaps does additional
authentication, and then completes a connection on behalf of the user to a
remote destination.

Screened Host
A host on a network behind a screening router. The degree to which a
screened host may be accessed depends on the screening rules in the router.

Screened Subnet
A subnet behind a screening router. The degree to which the subnet may
be accessed depends on the screening rules in the router.

Screening Router
A router configured to permit or deny traffic based on a set of
permission rules installed by the administrator.

Session Stealing
See IP Splicing.

Trojan Horse
A software entity that appears to do something normal but which, in
fact, contains a trapdoor or attack program.

Tunneling Router
A router or system capable of routing traffic by encrypting it and
encapsulating it for transmission across an untrusted network, for eventual
de-encapsulation and decryption.

Social Engineering
An attack based on deceiving users or administrators at the target
site. Social engineering attacks are typically carried out by telephoning
users or operators and pretending to be an authorized user, to attempt to
gain illicit access to systems.

Virtual Network Perimeter
A network that appears to be a single protected network behind
firewalls, which actually encompasses encrypted virtual links over untrusted
networks.

Virus
A replicating code segment that attaches itself to a program or data
file. Viruses might or might not not contain attack programs or trapdoors.
Unfortunately, many have taken to calling any malicious code a ``virus''. If
you mean ``trojan horse'' or ``worm'', say ``trojan horse'' or ``worm''.

Worm
A standalone program that, when run, copies itself from one host to
another, and then runs itself on each newly infected host. The widely
reported ``Internet Virus'' of 1988 was not a virus at all, but actually a
worm.





----------------------------------------------------------------------
----------

Footnotes
... System1
http://mail-abuse.org/
... Initiative2
http://mail-abuse.org/tsi/
... Squid3
http://squid.nlanr.net/
... Apache4
http://www.apache.org/docs/mod/mod_proxy.html
... Proxy5
http://home.netscape.com/proxy/v3.5/index.html
... Netscape6
http://developer.netscape.com/docs/m...n/contents.htm
... firewall7
http://www.real.com/firewall/
... bugtraq8
http://www.securityfocus.com
... online.9
http://www.thegild.com/firewall/.




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

"you mean dutch?" <me@privacy.net> wrote in message
news:36ov5cF552dooU1@individual.net...
> "William L. Sun" <88sun@cox.net> wrote in message
> news:n9uNd.11112$6u.7419@fed1read02...
>
> > Yes, It is computer translated. Just want to start the effort. If you

can
> > help to correct it, We would be grateful. It will benefit
> > more people in the world.

>
> the other FAQ's requires also a lot of attention; you need for every
> language a good translator.
> I will give it a try after you post the original english ( I hope )

version.
> Without it it's sometimes very hard to understand what the FAQ wants to

tell
> me.
> Give me a week ( maybe two? ) after your english FAQ posting. It takes a
> lot of time to translate it from dutch to dutch :-).
> ( for example 6.1 havens (dutch FAQ) = harbour ( eng ) ; kanal (german

FAQ)
> = canal or channel ( eng ) ; port (french FAQ) ah-ha you mean port

(eng )
> ; so 6.1 should be poorten or poort. I'm used to the english word "port"

but
> I have to look in a dutch manual to be sure if 'poort' is the correct

word).
> Sometimes I really have no idea what the FAQ tries to tell me.
>
>
> This is a once-only offer if that's no problem. You have to do the PDF

part.
> There are no problems with copyrights if I translated it to a readable

faq?
> The good news for you ;;-)) is that someone looked at the FAQ, but the bad
> thing for me is that I hope to have enough TCP/UDP/Internet knowledge.
>
> What about firewalls-faq@interhack.net named in the FAQ?
> Maybe it's much better that I send an email to this email address to be

sure
> that I'm the only one translating it and not somebody else just finished

a
> translation. Or give me an email address in your reply I could use to
> contact you.
>
>
>






Jim Watt 02-08-2005 08:30 AM

Re: Internet Firewall FAQ in Dutch
 
On Mon, 7 Feb 2005 23:55:51 -0800, "William L. Sun" <88sun@cox.net>
wrote:

>Thank you very much for your help. Here is the english version.


Please consider NOT spamming newsgroups with this in future.
--
Jim Watt
http://www.gibnet.com

you mean dutch? 02-08-2005 09:54 AM

Re: Internet Firewall FAQ in Dutch
 

"William L. Sun" <88sun@cox.net> wrote in message
news:Kg_Nd.11878$6u.5041@fed1read02...
> Thank you very much for your help. Here is the english version. Please

take
> your time to do it.


I'll send the translated FAQ to firewalls-faq@interhack.net





sakura 02-08-2005 11:46 AM

Re: Internet Firewall FAQ in Dutch
 

"Jim Watt" <jimwatt@aol.no_way> wrote in message
news:l3ug01pn69jtrlmnr06i1pfkah8vh3v0s5@4ax.com...
> On Mon, 7 Feb 2005 23:55:51 -0800, "William L. Sun" <88sun@cox.net>
> wrote:
>
> >Thank you very much for your help. Here is the english version.

>
> Please consider NOT spamming newsgroups with this in future.


it's a FAQ so please shut up. I consider it NOT as spamming and! it is the
best readable FAQ :-).





All times are GMT. The time now is 10:52 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.