Brandvägg

 När man sätter upp brandväggar för att skydda sitt eget nät
 från det hemska internet uppstår ett antal komplikationer.

 Ni ska få lösa två av de DNS-relaterade problem.

TIPS! Många säkerhets-funktioner i BIND kan ni hitta i kap. 10. i
 boken DNS and BIND.

1. Interna och externa namntjänster  (oglibatorisk)

 För att inte ge nätinbrottstjuvar onödig information
 om sitt eget nät, kan man ha två olika namntjänster.
 En för internt bruk innanför brandväggen, som känner till
 allt. Sedan har man en extern namntjänst utanför brandväggen
 som bara känner till den informationen som man vill sprida
 till omvärlden, tex ftp-, http-, och mailservrar.

 Eftersom ni bara har en dator per grupp får rotnamntjänsten
 dubblera som extern namntjänst och er egen dator blir intern
 namntjänst.

 Sätt upp de båda så att om man frågar den externa namntjänsten
 (rotnamntjänsten) ska man bara kunna få reda på följande
 information (även bakåtuppslagning):

 ftp.er-domän.world   med adress   192.168.ert-nät.5
 www.er-domän.world   med adress   192.168.ert-nät.6
 mail.er-domän.world  med adress   192.168.ert-nät.7

 Låt även mail-datorn vara den ansvariga för epost (MX).

 Frågar man den interna namntjänsten så ska den däremot
 utöver ovanstående även känna till de övriga datornamnen
 och adresserna som tidigare.

 Ni behöver inte bry er om tänkbara problem med sekundär-
 tjänsten eller den delegerade domänen.
 

 Nu kan man alltså "se ut" ifrån ert nät, men inte in.
 

 Redovisa detta när allting fungerar :-)

 

2. Egen rotnamntjänst    (frivillig)
 

 Att tillåta att man kan "se ut" kombineras ofta med att man
 släpper igenom relativt mycket trafik rakt igenom brandväggen.
 
 Detta är i många fall inte tillräckligt säkert, utan man
 stänger av all direkt trafik i båda riktningarna genom
 brandväggen.

 Detta gör att alla applikationer som behöver kommunicera med
 omvärlden utanför det egna nätet måste konfigureras för att
 gå via ombud (proxies) som körs på någon brandväggsdator
 (en dator med kontakt både med det interna nätet och med
 omvärlden).

 Dessa ombudsprogram kommunicerar i sin tur med omvärlden.

 Dessa ombudsprogram bör/måste specialskrivas för varje typ av
 applikation. Tex för Netscape och andra onämnbara nätsurf-
 programvaror så använder man en http-proxy.
 
 På detta sätt går ingen kommunikation direkt in till det egna
 nätet utan alltid via ombuden, som kan kontrollera att det inte
 skickas paket dit det inte ska skickas paket, och att paketen
 inte är utformade på ett illvilligt sätt.

 I dessa fall väljer man ibland att inte ha namntjänstkontakt
 med omvärlden. Eftersom alla applikationer ändå alltid går via
 ombud då de ska kommunicera med omvärlden kan man låta ombuden
 sköta namntjänstuppslagningen. Inuti ditt nät behöver man inte
 känna till omvärlden, det räcker med att känna till datorerna
 som ombuden körs på.

 Man sätter alltså upp egna interna rotnamntjänster som bara
 känner till det egna nätet.

 Det bör dock inte bli någon skillnad på den externa
 rotnamntjänsten (ns.adm.world).
 Den ska ju bara som i uppgift 1 känna till www-, ftp- och
 mail-datorerna.

 Ni ska skapa en egen rotnamntjänst. Frågar man den ska man
 få reda på informationen om ert nät, men den ska inte känna
 till omvärlden.

 Utöver tidigare, ska den interna namntjänsten känna till
 
 proxy.er-domän.world  med adress  192.168.ert-nät.8
 
 Ni behöver som tidigare inte bry er om att se till att ha
 någon sekundärserver.

 På den egna rotnamntjänsten, utöver tidigare filer, ha en
 databasfil för "roten". Ni ska ju vara en primär namntjänst
 för namntjänstroten. Denna nya domän ni tar ansvaret för
 ersätter "cache"-posten i named.conf. Ni behöver ju inte
 längre någon lista med rotnamntjänster. Ni har ju en själva
 och i dess databasfil ska ju rotnamntjänsterna redan finnas.

 OBS! "Bind" kräver minst 3 rotservrar, så rada upp er egen
 rotserver 3 gånger.