<!doctype linuxdoc system>

<article>

<title>Brandväggar och Proxyservers HOWTO (Firewall HOWTO)</title>
<author>Mark Grennan, <tt>markg@netplus.net</tt>. Svensk översättning av
<url url="mailto:md5tc@mdstud.chalmers.se" 
                    name="Tomas Carlsson">
<date>v0.4, 8 November 1996, Svensk version 15 Juni 1998
<abstract>
Detta dokument är designat för att lära ut grunderna i brandväggssystem
och att ge dig lite detaljer om hur man konfigurerar både en filtrerande och
proxy brandvägg på en Linuxbaserad PC. En (engelsk) HTML-version av detta
dokument finns tillgänglig på 
<em>http://okcforum.org/&tilde;markg/Firewall-HOWTO.html</em>
</abstract>

<toc>

<sect>Introduktion
<p>
Originalversionen av Firewall-HOWTO skrevs av David Rudder, 
<bf>drig@execpc.com</bf>. Jag skulle vilja tacka honom för att han tillät
mig att uppdatera hans arbete.

Brandväggar har fått stor uppmärksamhet som `det ultimata' i Internetsäkerhet 
den senaste tiden. Som med de flesta saker som får stor uppmärksamhet, så 
följer med detta missuppfattningar. Denna HOWTO kommer att ta upp grunderna om 
vad en brandvägg är för något, hur man sätter upp en, vad proxyservrar är, hur
man sätter upp proxyservrar och applikationerna för denna teknik utanför 
säkerhetens sfär.

<sect1>Feedback
<p>
All feedback är väldigt välkommen. <bf/ VAR VÄNLIG ATT RAPPORTERA ALLA 
ORIKTIGHETER I DETTA DOKUMENT!!!/. Jag är mänsklig och benägen att göra fel. Om
du hittar några så är jag mycket intresserad att rätta till dem. Jag kommer att
försöka svara på alla e-postmeddelanden, men jag är upptagen så bli inte 
förolämpad om jag inte gör det.

<em>Min e-postadress är <bf>markg@netplus.net</bf></em>

<sect1>Disclaimer
<p>
<bf>JAG ÄR INTE ANSVARIG FÖR NÅGRA SKADOR SOM INTRÄFFAR PÅ GRUND AV AGERANDE 
SOM ÄR BASERAT PÅ DETTA DOKUMENT</bf>. Detta dokument är tänkt att vara en 
introduktion till hur brandväggar och proxyservrar fungerar. Jag är inte, och 
jag låtsas inte heller att vara, en säkerhetsexpert. Jag är bara en person som
har läst för mycket och tycker om datorer mer än de flesta. Snälla, jag skriver
detta för att hjälpa folk att bli bekanta med ämnet och jag är inte beredd att 
satsa mitt liv på att allt som finns i detta dokument är korrekt.

<sect1>Copyright
<sect2>Svensk version
<p>
<bf/Denna översättning skall inte ses som juridiskt bindande, det är den 
engelska versionen som gäller. Se nästa delavsnitt./
<p>
Om inte annat anges, så är Linux HOWTO dokument kopieringsrättsskyddade av
dess respektive författare. Linux HOWTO dokument får reproduceras och
distribueras i sin helhet eller i delar i vilket medium som helst, fysiskt 
eller elektroniskt, så länge som denna kopieringsrättsnotis finns med i alla 
kopior. Komersiell distribution är tillåten och uppmuntrad; men, författaren
skulle vilja bli informerad om en sådan distribution.

Alla översättningar, härledda arbeten eller förenade arbeten som införlivar 
något Linux HOWTO dokument måste täckas under denna kopieringsrättsnotisen. Dvs
att du får inte producera ett härleda ett arbete ur en HOWTO och sedan lägga
till ytterligare restriktioner för dess distribution. Undantag för dessa regler
kan tillåtas under särskilda förhållanden; var vänlig att kontakta koordinatorn
för Linux HOWTOs.

Kort sagt, vi vill gynna spridandet av denna information genom så många kanaler
som möjligt. Men vi vill behålla kopieringsrätten på HOWTO-dokumenten och vill
bli informerade om alla planer på att distribuera HOWTOs.

Om du har några frågor, var vänlig kontakta Mark Grennan på 
&lt;markg@netplus.net&gt;.

<sect2>Engelsk version, oförändrad från originaldokumentet
<p>
<bf/Det är denna som gäller/
<p>
Unless otherwise stated, Linux HOWTO documents are copyrighted by
their respective authors. Linux HOWTO documents may be reproduced and
distributed in whole or in part, in any medium physical or electronic,
as long as this copyright notice is retained on all copies. Commercial
redistribution is allowed and encouraged; however, the author would
like to be notified of any such distributions.

All translations, derivative works, or aggregate works incorporating
any Linux HOWTO documents must be covered under this copyright notice.
That is, you may not produce a derivative work from a HOWTO and impose
additional restrictions on its distribution. Exceptions to these rules
may be granted under certain conditions; please contact the Linux
HOWTO coordinator.

In short, we wish to promote dissemination of this information through
as many channels as possible. However, we do wish to retain copyright
on the HOWTO documents, and would like to be notified of any plans to
redistribute the HOWTOs.

If you have any questions, please contact Mark Grennan at 
&lt;markg@netplus.net&gt;.

<sect1>Anledningar till att jag skriver detta
<p>
Även om det har varit många diskussioner i <tt/comp.os.linux.*/ om brandväggar
det senaste året, så hade jag svårt för att hitta den information jag behövde 
för att sätta upp en brandvägg. Originalversionen av denna HOWTO hjälpte till 
men det saknades fortfarande lite grann. Jag hoppas att denna `upp-hottade' 
version av David Rudder's Firewall HOWTO kommer att ge alla den information de 
behöver för att skapa en fungerande brandvägg på några timmar, inte veckor.

Jag känner också att jag borde ge tillbaka någonting till Linuxvärlden.

<sect1>Att göra
<p>
<itemize>
<item>Ge lite instruktioner om hur man sätter upp klienterna.
<item>Hitta en bra UDP proxyserver som fungerar med Linux
</itemize>

<sect1>Ytterligare Läsning
<p>
<itemize>
<item>NET-2 HOWTO (nuvarande NET-3-HOWTO (SvÖ))
<item>Ethernet HOWTO
<item>Multiple Ethernet Mini HOWTO
<item>Networking with Linux
<item>PPP HOWTO
<item>TCP/IP Network Administrator's Guide av O'Reilly and Associates
<item>Dokumentation för TIS Firewall Toolkit
</itemize>

Trusted Information Systems (TIS) www-sajt har en stor samling dokumentation om
brandväggar och relaterat material. 
<url url="http://www.tis.com/" name="TIS www-sajt">

Dessutom så arbetar jag med ett säkerhetsprojekt som jag kallar för 
<em>Secure Linux</em>. På www-sajten för <em>Secure Linux</em> så samlar jag 
all information, dokumentation och program som man behöver för att skapa ett
pålitligt Linuxsystem. E-posta mig om du vill ha information.

<sect1>Översättarens kommentarer
<p>
Jag kommer använda översättningen `Internet' i detta dokument, med vilket jag 
menar det allmänt kända Internet. Men informationen i detta dokument bör även
gälla för vilket annat internätverk som helst, åtminstonde ett som använder
samma protokoll som Internet.

Jag har ändrat alla förekomster av `NET-2 HOWTO' till `NET-3 HOWTO' eftersom
det är den versionen av det dokumentet som är aktuell för tillfället.

De tillägg som jag har gjort i texten har jag markerat med `(SvÖ)'.


<sect>Att förstå brandväggar
<p>
En brandvägg är en term som används för en bildel. I bilar så är brandväggar
fysiska objekt som separerar motorn från passagerarna. De är till för att 
skydda passageraren ifall bilens motor fattar eld medans den fortfarande låter
föraren använda motorns kontroller.

En brandvägg i en dator är en enhet som skyddar ett privat nätverk från den 
publika delen (Internet som helhet). 

Brandväggsdatorn, från och med nu kallad &dquot;brandväggen&dquot;, kan nå både
det skyddade nätverket och Internet. Det skyddade nätverket kan inte nå 
Internet och Internet kan inte nå det skyddade nätverket. 

För att någon skall kunna nå Internet från insidan av det skyddade nätverket, 
så måste de göra en telnetanslutning till brandväggen och använda Internet
därifrån.

Den enklaste formen av branvägg är ett `dual homed' system (ett system med två
nätverksanslutningar). Om du kan LITA på ALLA dina användare, så kan du helt
enkelt sätta upp ett Linuxsystem (kompilera med IP forwarding/gatewaying 
avstängt) och ge alla användare konton till den. De kan sedan logga in på 
detta system och använda telnet, FTP, läsa e-post och andra tjänster som du
erbjudit. Med denna inställning så är brandväggen den enda dator på ditt 
privata nätverk som vet någonting om världen utanför. De andra systemen på ditt
skyddade nätverk behöver inte ens någon <em/default route/.

Detta måste upprepas: För att ovanstående brandvägg skall fungera så <bf/MÅSTE 
DU LITA PÅ ALLA DINA ANVÄNDARE!/. Jag rekommenderar inte detta.

<sect1>Nackdelar med brandväggar
<p>
Det finns två typer av brandväggar.
<enum>
<item>IP Filtrerande Brandväggar - som blockerar all nätverkstrafik utom
viss utvald trafik.
<item>Proxyservrar - som gör nätverksanslutningarna åt dig.
</enum>

<sect2>IP Filtrerande Brandväggar
<p>

En IP filtrerande brandvägg arbetar på paketnivån. Den är designad för att 
kontrollera flödet av paket baserat på källan, destinationen, porten och 
pakettypen som finns lagrade i varje paket.

Denna typ av brandvägg är väldigt säker men den saknar all form av användbara
loggningsfunktioner. Den kan hindra personer från att komma åt privata system 
men den kommer inte att tala om vem som accessade dina publika system eller
vem som accessade Internet från insidan.

Filtrerande brandväggar är absoluta filter. Även om du vill ge någon access
till dina privata servrar från utsidan så kan du inte göra detta utan att 
ge alla access till servrarna.

Linux innehåller mjukvara för paketfiltrering i kärnan från och med version 
1.3.x.

<sect2>Proxyservrar
<p>
Proxyservrar tillåter indirekt access till Internet genom brandväggen. Det 
bästa exemplet på hur detta fungerar är en person som telnettar till ett system
och sedan telnettar därifrån till ytterligare ett system. Men med en 
proxyserver så görs detta automatiskt. När du ansluter till en proxyserver med
din klientprogramvara så startar proxyservern sin klientprogramvara och skickar
informationen till dig.

Eftersom proxyservrar duplicerar all kommunikation så kan de logga allt de gör.

Den stora fördelen med proxyservrar är att de är helt säkra, när de är korrekt
konfigurerade. De tillåter inte några anslutningar igenom dem. Det finns inga
direkta IP-routes.

<sect>Att konfigurera brandväggen

<sect1>Hårdvarukrav
<p>
I vårt exempel så är datorn en 486-DX66 med 16Mb minne och en 500Mb 
Linuxpartition. Detta systemet har två nätverkskort, ett anslutet till vårt
privata LAN och det andra anslutet till ett LAN som vi kallar för den 
de-militariserade zonen (DMZ). DMZ är ansluten till en router som i sin tur är
ansluten till Internet.

Detta är en ganska typisk konfiguration för ett företag. Man skulle kunna 
använda ett nätverkskort och ett modem med en PPP-länk till Internet. Poängen
är att brandväggen måste ha två IP-adresser.

Jag vet många personer som har små LANs hemma med två eller tre datorer 
anslutna. Något som man skulle kunna tänka sig då är att koppla alla sina
modem till en Linuxburk (kanske en gammal 386:a) och ansluta dem till Internet
med lastbalansering. Med denna konfiguration kan man fördubbla 
genomströmmningen om endast en person tog hem data från Internet. :-)

<sect>Programvara för brandväggar

<sect1>Tillgängliga paket
<p>
Om allt du vill ha är en filtrerande brandvägg, så behöver du endast Linux och
de grundläggande nätverkspaketen. Ett paket som kanske inte följer med din 
distribution är IP Firewall Administration tool, <em/ipfwadm/. Detta kan du 
hitta på <url url="http://www.xos.nl/linux/ipfwadm/" 
             name="www.xos.nl">.

Om du vill sätta upp en proxyserver så behöver du ett av följande paket.
<enum>
<item>SOCKS
<item>TIS Firewall Toolkit (FWTK)
</enum>

<sect1>TIS Firewall Toolkit eller SOCKS
<p>
<url url="http://www.tis.com" name="Trusted Information System"> har gjort en 
samling program som är designade för brandväggar. Programmen gör i stort sett
samma sak som SOCKS-paketet, men med en annan designstrategi. Där SOCKS har 
ett program som täcker alla Internettransaktioner, så har TIS ett program för
varje tjänst som önskar använda brandväggen.

För att jämföra de båda, låt oss använda exemplet med <em/www/ och <em/telnet/
access.
Med SOCKS sätter du upp en konfigurationsfil och en daemon. Genom denna fil och
daemon så aktiveras både <em/www/ och <em/telnet/, såväl som alla andra 
tjänster som du inte stängt av.

Med TIS-paketet kan du sätta upp en daemon för var och en av <em/www/ och 
<em/telnet/, såväl som konfigurationsfiler för båda. När du gjort detta så är 
andra accesser till Internet fortfarande inte tillåtna förrän du explicit 
sätter upp dem också. Om det inte har tillhandahållits en daemon för en viss 
tjänst (såsom <em/talk/) så finns det en &dquot;plug-in&dquot; daemon, men den
är varken så flexibel eller så enkel att sätta upp som de andra daemonerna.

Detta kan verka obetydligt, men det har en stor betydelse. SOCKS tillåter dig 
att vara slarvig. Med en dålig konfigurerad SOCKS-server, så kan någon från 
insidan få mer access till Internet än vad som var meningen från början. Med
TIS-paketet så har personerna på insidan endast tillgång till det som 
systemadministratören vill att de skall ha tillgång till.

SOCKS är lättare att konfigurera, lättare att kompilera och tillåter större
flexibilitet. TIS-paketet är säkrare om man vill reglera användarna i det 
skyddade nätverket. Båda tillhandahåller absolut skydd från utsidan.

Jag kommer att täcka installationen och konfigurationen av båda.

<sect>Att förbereda Linuxsystemet

<sect1>Att kompilera kärnan
<p>
Börja med en ren installation av din Linuxdistribution (jag använde RedHat 
3.0.3 och exemplen här baseras på den distributionen). Ju mindre programvara
du har installerad desto mindre säkerhetshål, bakdörrar och/eller buggar 
kommer det att finnas som inbringar säkerhetsproblem i ditt system. Så 
installera endast minimalt med applikationer.

Välj en stabil kärna. Jag använde Linux 2.0.14 kärnan till mitt system, så
denna dokumentationen är baserad på dess inställningar.

Du kommer att behöva kompilera om Linuxkärnan med passande altenativ. Vid denna
tidpunkten bör du titta i Kernel HOWTO, Ethernet HOWTO och NET-3 HOWTO om du
inte redan gjort detta.

Här är de nätverksrelaterade inställningar som jag vet fungerar i `make config'

<enum>
<item>Under `General setup'
<enum>
<item>Sätt på `Networking Support'
</enum>
<item>Under `Networking Options'
<enum>
<item>Sätt på `Network firewalls'
<item>Sätt på `TCP/IP Networking'
<item>Stäng av `IP forwarding/gatewaying' (OM DU INTE vill använda 
IP-filtrering)
<item>Sätt på `IP Firewalling' 
<item>Sätt på `IP firewall packet logging' (detta är inte nödvändigt men det är
en bra ide)
<item>Stäng av `IP: masquerading' (Jag täcker inte detta ämnet här.)
<item>Sätt på `IP: accounting'
<item>Stäng av `IP: tunneling'
<item>Stäng av `IP: aliasing'
<item>Stäng av `IP: PC/TCP compatibility mode'
<item>Stäng av `IP: Reverse ARP'
<item>Sätt på `Drop source routed frames'
</enum>
<item>Under `Network device support'
<enum>
<item>Sätt på `Network device support'
<item>Sätt på `Dummy net driver support'
<item>Sätt på `Ethernet (10 or 100Mbit)'
<item>Välj ditt nätverkskort
</enum>
</enum>

Nu kan du kompilera om och installera om kärnan och sedan starta om systemet.
Dina nätverkskort skall nu dyka upp bland all text vid uppstarten. Om inte, gå
igenom de andra HOWTOerna igen tills det fungerar.

<sect1>Att konfigurera två nätverkskort
<p>
Om du har två nätverkskort i din dator, så måste du med all sannolikhet lägga
till ett appenduttryck i din <tt>/etc/lilo.conf</tt>-fil för att tala om IRQ 
och I/O-adress för båda korten. Mitt appenduttryck ser ut så här:
<verb>
    append=&dquot;ether=12,0x300,eth0 ether=15,0x340,eth1&dquot;
</verb>

<sect1>Att konfigurera nätverksadresser
<p>
Detta är den riktigt intressanta delen. Nu har du några olika val att göra.
Eftersom vi inte vill att Internet skall ha tillgång till någon del av det 
privata nätverket, så behöver vi inte använda riktiga adresser. Det finns ett
antal intressanta adresser som är reserverade för privata nätverk. Eftersom
alla behöver fler adresser och eftersom dessa adresserna inte kan nås över
Internet så är de ett bra val.

Ibland dessa adresser så är tex 192.168.2.xxx reserverad och vi kommer att
använda den i våra exempel.

Din proxybrandvägg kommer att vara medlem av båda nätverken och kan därför
skicka igenom data till och från det privata nätverket.

<verb>
            199.1.2.10   __________    192.168.2.1
      _  __  _        \ |          | /           _______________
     | \/  \/ |        \| Firewall |/           |               |
    / Internet \--------|  System  |------------| Workstation/s |
    \_/\_/\_/\_/        |__________|            |_______________|
</verb>

Om du skall använda en filtrerande brandvägg så kan du fortfarande använda de 
här adresserna. Du behöver använda IP-maskering (Masquerading) för att det 
skall fungera. Med IP-maskering så skickar brandväggen vidare alla paket och 
översätter dem till &dquot;riktiga&dquot; IP-paket så att de kan skickas på Internet.

Du måste tilldela den riktiga IP-adressen till nätverkskortet som är anslutet till
Internetsidan (utsidan). Och tilldela 192.168.2.1 till Ethernet-kortet på insidan.
Detta kommer att vara din proxy/gateway IP-adress. Du kan tilldela alla de andra
maskinerna på det skyddade nätverket någon adress i området 192.168.2.2 till 
192.168.2.254.

Eftersom jag använder RedHat Linux så konfigurerar jag nätverket vid uppstart genom 
att lägga till en <tt/ifcfg-eth1/-fil i katalogen <tt>/etc/sysconfig/network-scripts</tt>. Denna
filen läses under uppstarten för att konfigurera ditt nätverk och dina 
routingtabeller.

Så här ser min <tt/ifcfg-eth1/ ut:

<verb>
    #!/bin/sh
    #>>>Device type: ethernet
    #>>>Variable declarations:
    DEVICE=eth1
    IPADDR=192.168.2.1
    NETMASK=255.255.255.0
    NETWORK=192.168.2.0
    BROADCAST=192.168.2.255
    GATEWAY=199.1.2.10
    ONBOOT=yes
    #>>>End variable declarations
</verb>

Du kan också använda dessa script för att automatiskt ansluta till Internet med
modem. Titta på scriptet <tt/ipup-ppp/.

Om du skall använda ett modem till din Internetanslutning så kommer din IP-adress
på utsidan att tilldelas av din leverantör när du ansluter.

<sect1>Att testa ditt nätverk
<p>
Börja med med att kolla <em/ifconfig/ och <em/route/. Om du har två 
nätverkskort så bör din <em/ifconfig/ se ut ungefär så här:
<verb>
  #ifconfig
  lo        Link encap:Local Loopback
            inet addr:127.0.0.0  Bcast:127.255.255.255  Mask:255.0.0.0
            UP BROADCAST LOOPBACK RUNNING  MTU:3584  Metric:1
            RX packets:1620 errors:0 dropped:0 overruns:0
            TX packets:1620 errors:0 dropped:0 overruns:0

  eth0      Link encap:10Mbps Ethernet  HWaddr 00:00:09:85:AC:55
            inet addr:199.1.2.10 Bcast:199.1.2.255  Mask:255.255.255.0
            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
            RX packets:0 errors:0 dropped:0 overruns:0
            TX packets:0 errors:0 dropped:0 overruns:0
            Interrupt:12 Base address:0x310

  eth1      Link encap:10Mbps Ethernet  HWaddr 00:00:09:80:1E:D7
            inet addr:192.168.2.1  Bcast:192.168.2.255  Mask:255.255.255.0
            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
            RX packets:0 errors:0 dropped:0 overruns:0
            TX packets:0 errors:0 dropped:0 overruns:0
            Interrupt:15 Base address:0x350
</verb>

och din routingtabell ungefär så här:

<verb>
  #route -n
  Kernel routing table
  Destination     Gateway         Genmask         Flags MSS    Window Use Iface
  199.1.2.0       *               255.255.255.0   U     1500   0       15 eth0
  192.168.2.0     *               255.255.255.0   U     1500   0        0 eth1
  127.0.0.0       *               255.0.0.0       U     3584   0        2 lo
  default         199.1.2.10      *               UG    1500   0       72 eth0
</verb>

<bf/Observera:/ 199.1.2.0 är Internet-sidan av denna brandväggen och 
192.168.2.0 är den privata sidan.

Försök nu att <em/ping/a Internet från brandväggen. Jag brukade använda 
<tt/nic.ddn.mil/ som testpunkt. Det är fortfarande en bra test, men har visat
sig mindre pålitlig än jag hade hoppats. Om det inte fungerar med en gång, 
försök med att <em/ping/a några andra ställen som inte är anslutna till ditt
LAN. Om detta inte fungerar så är din PPP felaktigt konfigurerad. Läs NET-3 
HOWTO igen och försök sedan igen.

Försök nu <em/ping/a en dator på det skyddade nätverket från brandväggen. Alla
datorer på det privata nätverket skall kunna <em/ping/a varandra. Om inte så
försök med NET-3 HOWTO igen och jobba lite till på nätverket.

Försök nu att <em/ping/a brandväggens yttre IP-adress (observera att detta inte
är en av 192.168.2.xxx adresserna) från en dator inne i det skyddade nätverket.
Om detta fungerar så har du inte stängt av IP-vidareskickning (forwarding). Se
till att vara säker på att detta är vad du vill i sådana fall. Om du låter den
vara påslagen så måste du även läsa igenom avsnittet om IP-filtrering också.

Försök nu att <em/ping/a Internet ifrån det skyddade nätverket (dvs bakom 
brandväggen). Använd samma adress som fungerade när du gjorde detta från 
brandväggen (tex nic.ddn.mil). Återigen, om du har stängt av IP-vidareskickning
så skall detta inte fungera men annars så skall det fungera.

Om du har IP-vidareskickning påslagen och använder &dquot;RIKTIGA&dquot; (inte 
192.168.2.*) IP-adresser till ditt privata nätverk, och om du inte kan 
<em/ping/a Internet men du kan <em/ping/a Internet-sidan av din brandvägg, så
kolla om nästa router `uppströms' routar paket för din privata nätverksadress 
(din leverantör kanske måste göra detta åt dig).

Om du har gett ditt nätverk reserverade adresser (192.168.2.*), så kan inga
paket routas till det ändå. Om du har gått i förväg och redan har IP-maskering
påslagen, så skall detta testet fungera.

Nu har du din grundläggande systemkonfiguration.

<sect1>Att säkra brandväggen
<p>
En brandvägg är inte till någon nytta om den lämnas vidöppen för attacker genom
en oanvänd tjänst. En &dquot;bad guy&dquot; skulle kunna få tillgång till
brandväggen och modifiera den så att den passar hans egna syften.

Börja med att stänga av alla tjänster som inte behövs. Titta på filen 
<tt>/etc/inetd.conf</tt>. Denna filen kontrollerar vad som kallas 
&dquot;super servern&dquot;. Den i sin tur kontrollerar en mängd andra 
serverdaemoner och startar dem när de efterfrågas. 

Stäng definitivt av <em/netstat/, <em/systat/, <em/tftp/, <em/bootp/ och 
<em/finger/. För att stänga av en tjänst, sätt ett &num som första tecken på
raden som beskriver tjänsten. När du är färdig så skickar du en SIG-HUP signal
till <em/inetd/-processen genom att skriva <bf>&dquot;kill -HUP 
&lt;pid&gt;&dquot;</bf>, där &lt;pid&gt; är processnumret för <em/inetd/. Detta
gör att <em/inetd/ läser om sin konfigurationsfil (<tt/inetd.conf/) och 
återstartas.

Testa detta genom att telnetta till port 15 (porten för <em/netstat/) på 
brandväggen. Om du får en utskrift från <em/netstat/ så har du inte återstartat
<em/inetd/ korrekt.

<sect>Att konfigurera IP-filtrering (<em/ipfwadm/)
<p>
Till att börja med så bör du ha IP-vidareskickning (IP Forwarding) påslagen i 
din kärna och ditt system skall vara igång och skicka vidare allt som du 
skickar till den. Dina routingtabeller skall vara på plats och du skall kunna
ha tillgång till allt, både från insidan till utsidan och från utsidan till 
insidan.

Men vi bygger en brandvägg så vi behöver börja begränsa vad som går att få 
tillgång till.

I mitt system så skapade jag ett par script för att ställa in brandväggens
vidareskickningspolicy och redovisningspolicy. Jag kör dessa script ifrån
scripten i <tt>/etc/rc.d</tt> så att mitt system konfigureras vid uppstart.

Med standardinställningarna så skickar Linuxkärnans system för 
IP-vidareskickning vidare allt. På grund av detta så bör din brandvägg börja 
med att neka access till allt och tömma alla <em/ipfwadm/-regler som finns kvar
sedan det kördes sist. Följande script fixar detta:

<verb>
  #
  # setup IP packet Accounting and Forwarding
  #
  #   Forwarding
  #
  # By default DENY all services
  ipfwadm -F -p deny
  # Flush all commands
  ipfwadm -F -f
  ipfwadm -I -f
  ipfwadm -O -f
</verb>

Nu har vi den ultimata brandväggen. Inget kan komma igenom. Du har utan tvekan
några tjänster som du behöver skicka vidare genom brandväggen, så här kommer
några exempel som kan vara användbara för dig:

<verb>
  #  Skicka vidare e-post till din server
  ipfwadm -F -a accept -b -P tcp -S 0.0.0.0/0 1024:65535 -D 192.1.2.10 25

  # Skicka vidare e-postanslutningar till utomstående e-postservrar
  ipfwadm -F -a accept -b -P tcp -S 196.1.2.10 25 -D 0.0.0.0/0 1024:65535

  # Skicka vidare www-anslutningar till din www-server
  /sbin/ipfwadm -F -a accept -b -P tcp -S 0.0.0.0/0 1024:65535 -D 196.1.2.11 80

  # Skicka vidare www-anslutningar till utomstående www-server
  /sbin/ipfwadm -F -a accept -b -P tcp -S 196.1.2.* 80 -D 0.0.0.0/0 1024:65535 

  # Skicka vidare DNS-trafik
  /sbin/ipfwadm -F -a accept -b -P udp -S 0.0.0.0/0 53 -D 196.1.2.0/24
</verb>

Du kanske också är intresserad av att hålla reda på trafik som går igenom din
brandvägg. Följande script kommer att räkna alla paket. Du kan lägga till en 
eller ett par rader för att hålla reda på paket till ett enskilt system.

<verb>                      
  # Flush the current accounting rules
  ipfwadm -A -f
  # Accounting
  /sbin/ipfwadm -A -f
  /sbin/ipfwadm -A out -i -S 196.1.2.0/24 -D 0.0.0.0/0
  /sbin/ipfwadm -A out -i -S 0.0.0.0/0 -D 196.1.2.0/24
  /sbin/ipfwadm -A in -i -S 196.1.2.0/24 -D 0.0.0.0/0
  /sbin/ipfwadm -A in -i -S 0.0.0.0/0 -D 196.1.2.0/24
</verb>

Om allt du ville ha var en filtrerande brandvägg så kan du sluta här. 
Ha skoj :-)

<sect>Att installera TIS proxyserver
<p>
<sect1>Att få tag på programvaran
<p>
TIS FWTK finns på <url url="ftp://ftp.tis.com" name="TIS ftp-sajt">.

Gör inte mistaget som jag gjorde. När du hämtar filer från TIS, LÄS 
README-filerna. TIS FWTK är inlåst i en gömd katalog på deras server. TIS 
kräver att du <bf>sickar ett e-postmeddelande till 
<url url="mailto:fwtk-request@tis.com" name="fwtk-request@tis.com"></bf> med 
endast ordet <bf/SEND/ i textkroppen för att få reda på namnet på den gömda 
katalogen.
Det behövs inget `subject' i meddelandet. Deras system kommer då att e-posta
tillbaka namnet på katalogen (som gäller i tolv timmar) så att du kan ladda hem
källkoden.

När detta skrivs så har TIS släppt version 2.0 (beta) av FWTK. Denna versionen
verkar kompilera bra (med ett par undantag) och allt fungerar för mig. Detta
är versionen som jag täcker här. När de släpper den slutgiltliga koden så 
kommer jag att uppdatera HOWTOn.

För att installera FWTK, skapa en <tt/fwtk-2.0/ katalog i din <tt>/usr/src</tt>
katalog. Flytta din kopia av FWTK (<tt/fwtk-2.0.tar.gz/) till denna katalogen
och packa upp den (<tt/tar zxf fwtk-2.0.tar.gz/).

FWTK kan inte använda proxyn på SSL www-dokument men det finns en addon för 
detta skriven av Jean-Christophe Touvet. Den finns på 
<url url="ftp://ftp.edelweb.fr/pub/contrib/fwtk/ssl-gw.tar.Z" 
    name="ftp.edelweb.fr">.
Touvet supportar inte denna koden.

Jag använder en modifierad version som inkluderar access till Netscapes säkra
nyhetsservrar som är skriven av Eric Wedel. Den finns tillgänglig på 
<url url="ftp://mdi.meridian-data.com/pub/tis.fwtk/ssl-gw/ssl-gw2.tar.Z" 
    name="mdi.meridian-data.com">. 

I vårt exempel kommer jag att använda Eric Wedels version.

För att installera, skapa en <tt/ssl-gw/ katalog i din 
<tt>/usr/src/fwtk-2.0</tt> katalog och lägg filerna i den.

När jag installerade denna gatewayen så krävdes det lite ändringar innan den
kunde kompileras tillsammans med resten av paketet.

Den första ändringen skall göras i filen <tt/ssl-gw.c/. Jag kom på att den 
inte inkluderade en fil som den behövde.

<verb>
  #if defined(__linux)
  #include        <sys/ioctl.h>
  #endif
</verb>

För det andra så följde det inte med någon <tt/Makefile/. Jag kopierade en 
ifrån en av de andra gatewayernas kataloger och ersatte den gatewayens namn med
<tt/ssl-gw/.

<sect1>Att kompilera TIS FWTK
<p>
Version 2.0 av FWTK kompilerar mycket lättare än någon av de tidigare 
versionerna. Jag hittade ett par saker som behövde ändras innan BETA-versionen
kompilerade ordentligt. Förhoppningsvis så finns dessa ändringar i den 
slutgiltliga versionen.

För att fixa till detta så börja med att byta till katalogen 
<tt>/usr/src/fwtk/fwtk</tt> och kopiera filen <tt/Makefile.config.linux/ till
<tt/Makefile.config/.

<bf>KÖR INTE FIXMAKE</bf>. Instruktionerna säger åt dig att köra den. Om du
gör det så kommer den att förstöra <tt/Makefile/-filerna i alla kataloger.

Jag har en fix för fixmake. Problemet är att sed-scriptet lägger till en '.' 
och '' i <tt/include/-raden i alla <tt/Makefile/-filerna. Följande sed-script 
fungerar.

<verb>
  sed 's/^include[        ]*\([^  ].*\)/include \1/' $name .proto > $name 
</verb>

Efter detta måste vi editera filen <tt/Makefile.config/. Det finns två 
ändringar som du kanske måste göra.

Författaren ställde in käll-katalogen till sin hemkatalog. Vi kompilerar våran
kod i <tt>/usr/src</tt> så du bör ändra variabeln <tt/FWTKSRCDIR/ så att det
stämmer överens.

<verb>
  FWTKSRCDIR=/usr/src/fwtk/fwtk
</verb>

Sedan, vissa Linuxsytem använder gdbm-databasen. <tt/Makefile.config/ använder
dbm. Du kanske behöver ändra detta. Jag behövde göra det för RedHat 3.0.3.

<verb>
  DBMLIB=-lgdbm
</verb>

Sista fixen är i <tt/x-gw/. Buggen är i BETA-versionen av <tt/socket.c/ koden.
För att fixa det, ta bort följande rader från koden.

<verb>
  #ifdef SCM_RIGHTS  /* 4.3BSD Reno and later */
                       + sizeof(un_name->sun_len) + 1
  #endif
</verb>

Om du lade till <tt/ssl-gw/ till din FWTK källkatalog så måste du lägga till
den till listan av kataloger i <tt/Makefile/.

<verb>
  DIRS=   smap smapd netacl plug-gw ftp-gw tn-gw rlogin-gw http-gw x-gw ssl-gw
</verb>

Nu kan du köra <bf><tt/make/</bf>.

<sect1>Att installera TIS FWTK
<p>
Kör <bf><tt/make install/</bf>.

Standardkatalogen för installation är <tt>/usr/local/etc</tt>. Du kan ändra 
detta (jag gjorde det inte) till en säkrare katalog. Jag valde att ändra 
rättigheterna på denna katalogen till <tt/chmod 700/.

Allt som är kvar nu är att konfigurera brandväggen.

<sect1>Att konfigurera TIS FWTK
<p>
Nu börjar det roliga. Vi måste lära systemet att använda dessa nya tjänster
och skapa tabellerna för att kontrollera dem.

Jag tänker inte försöka skriva om manualen för TIS FWTK här. Jag kommer att 
visa dig inställningarna som fungerade för mig och förklara de problem som 
jag sprang på och hur jag kom runt dem.

Det finns tre filer som utgör dessa kontroller.
<p>
<itemize>
<item><tt>/etc/services</tt>
<itemize>
<item>Talar om för systemet vilka portar tjänsterna finns på.
</itemize>
</itemize>
<itemize>
<item><tt>/etc/inetd.conf</tt>
<itemize>
<item>Talar om för <em/inetd/ vilket program som skall köras när någon 
`knackar' på en tjänsts port.
</itemize>
</itemize>
<itemize>
<item><tt>/usr/local/etc/netperm-table</tt>
<itemize>
<item>Talar om för FWTK-tjänsterna vem som skall tillåtas och vem som skall
nekas access till tjänster.
</itemize>
</itemize>

För att få igång FWTK så bör du editera dessa filer nerifrån och upp. Att 
editera <tt>services</tt> utan att <tt>inetd.conf</tt> eller 
<tt>netperm-table</tt> är korrekt inställda kan göra ditt system oåtkomligt.

<sect2>Filen <tt>/usr/local/etc/netperm-table</tt>
<p>
Denna filen kontrollerar vem som får tillgång till tjänsterna i TIS FWTK. Du 
bör tänka på trafiken som använder brandväggen från båda sidor. Personer 
utanför ditt nätverk skall identifiera sig innan de får tillgång, men personer
inuti ditt nätverk kan tillåtas att passera rakt igenom.

Brandväggen använder ett program som heter <em/authsrv/ för att hålla en 
databas med användarnamn och lösenord, så att personer kan identifiera sig.
Autentiseringsdelen av <tt/netperm-table/ kontrollerar var databasen finns
och vem som kan komma åt den.

Jag hade lite problem med att stänga av access till denna tjänsten. Notera att
<em/permit-hosts/-raden som jag visar innehåller en '*' vilket ger alla access.
Den korrekta inställningen är <tt>authsrv: premit-hosts localhost</tt> om du
kan få det att fungera.

<verb>
  #
  # Proxy configuration table
  #
  # Authentication server and client rules
  authsrv:	database /usr/local/etc/fw-authdb
  authsrv:	permit-hosts *
  authsrv:	badsleep 1200
  authsrv:	nobogus true
  # Client Applications using the Authentication server
  *:		authserver 127.0.0.1 114
</verb>

För att initialisera databasen, <em/su/:a till <em/root/ och kör <tt>./authsrv</tt>
i katalogen <tt>/var/local/etc</tt> för att skapa administratörens 
användarprofil. Här följer en exempelsession.

Läs dokumentationen för FWTK för att lära dig hur man lägger till användare och
grupper.

<verb>
    #
    # authsrv
    authsrv# list
    authsrv# adduser admin &dquot;Auth DB admin&dquot;
    ok - user added initially disabled
    authsrv# ena admin
    enabled
    authsrv# proto admin pass
    changed
    authsrv# pass admin &dquot;plugh&dquot;
    Password changed.
    authsrv# superwiz admin
    set wizard
    authsrv# list
    Report for users in database
    user   group  longname           ok?    proto   last 
    ------ ------ ------------------ -----  ------  -----
    admin         Auth DB admin      ena    passw   never
    authsrv# display admin
    Report for user admin (Auth DB admin)
    Authentication protocol: password
    Flags: WIZARD
    authsrv# ^D
    EOT
    #
</verb>

Kontrollerna för <em/telnet/-gatewayen (<tt/tn-gw/) är okomplicerade och är de
första som du bör sätta upp.

I mitt exempel så tillåter jag datorer från det privata nätverket att passera
igenom brandväggen utan att autentisera sig 
(<tt/permit-hosts 196.1.2.* -passok/). Men alla andra användare måste lämna 
användarid och lösenord för att använda proxyn (<tt/permit-hosts * -auth/).

Jag låter även ett annat system (196.1.2.202) få tillgång till brandväggen utan
att gå igenom brandväggen över huvud taget. Raderna med <tt/inetacl-in.telnetd/
fixar detta. Jag förklarar hur dessa rader anropas senare.

Timeouten för <em/telnet/ bör vara kort.

<verb>
  # telnet gateway rules:
  tn-gw:		denial-msg	/usr/local/etc/tn-deny.txt
  tn-gw:		welcome-msg	/usr/local/etc/tn-welcome.txt
  tn-gw:		help-msg	/usr/local/etc/tn-help.txt
  tn-gw:		timeout 90
  tn-gw:		permit-hosts 196.1.2.* -passok -xok
  tn-gw:		permit-hosts * -auth
  # Only the Administrator can telnet directly to the Firewall via Port 24
  netacl-in.telnetd: permit-hosts 196.1.2.202 -exec /usr/sbin/in.telnetd
</verb>

Det fungerar på samma sätt för <em/r-kommandona/ som för <em/telnet/.

<verb>
  # rlogin gateway rules:
  rlogin-gw:	denial-msg	/usr/local/etc/rlogin-deny.txt
  rlogin-gw:	welcome-msg	/usr/local/etc/rlogin-welcome.txt
  rlogin-gw:	help-msg	/usr/local/etc/rlogin-help.txt
  rlogin-gw:	timeout 90
  rlogin-gw:	permit-hosts 196.1.2.* -passok -xok
  rlogin-gw:	permit-hosts * -auth -xok
  # Only the Administrator can telnet directly to the Firewall via Port
  netacl-rlogind: permit-hosts 196.1.2.202 -exec /usr/libexec/rlogind -a
</verb>

Du bör inte låta någon få direkt tillgång till din brandvägg och det 
inkluderar FTP, så lägg inte en FTP-server på din brandvägg.

Nu till <em/ftp-gw/. Återigen så gör raden med <tt/permit-hosts/ att alla i 
det skyddade nätverket får fri tillgång till Internet men alla andra måste 
autentisera sig. Jag har även med loggning av alla filer som sänds och tas 
emot av mina kontroller (<tt/-log { retr stor }/).

Timeouten för FTP kontrollerar hur lång tid det kommer att ta att släppa en 
dålig förbindelse och dessutom hur lång tid en anslutning hålls öppen utan 
aktivitet.

<verb>
  # ftp gateway rules:
  ftp-gw:		denial-msg	/usr/local/etc/ftp-deny.txt
  ftp-gw:		welcome-msg	/usr/local/etc/ftp-welcome.txt
  ftp-gw:		help-msg	/usr/local/etc/ftp-help.txt
  ftp-gw:		timeout 300
  ftp-gw:		permit-hosts 196.1.2.* -log { retr stor }
  ftp-gw:		permit-hosts * -authall -log { retr stor }
</verb>

WWW, gopher och bläddrarbaserad FTP kontrolleras av <em/http-gw/. De två första
raderna skapar en katalog för att spara <em/ftp/ och <em/www/ dokument 
allteftersom de passerar genom brandväggen. Jag gör så att <em/root/ blir ägare
till filerna och så att endast <em/root/ kan läsa katalogen.

Timeouten för <em/www/ skall vara kort. Den kontrollerar hur lång tid en 
användare skall vänta på dåliga förbindelser.

<verb>
  # www and gopher gateway rules:
  http-gw:	userid		root
  http-gw:	directory	/jail
  http-gw:	timeout 90
  http-gw:	default-httpd	www.afs.net
  http-gw:	hosts 		196.1.2.* -log { read write ftp }
  http-gw:	deny-hosts 	* 
</verb>
<em/ssl-gw/ är egentligen bara en `släpp igenom allt'-gateway. Var försiktig
med den. I detta exemplet låter jag vem som helst i det skyddade nätverket
ansluta till vilken server som helst utanför nätverket, förutom adresserna
127.0.0.* och 192.1.1.*, och då endast till portarna 443 till 563. Portarna 443
till 563 är kända SSL-portar.

<verb>
  # ssl gateway rules:
  ssl-gw:         timeout 300
  ssl-gw:         hosts           196.1.2.* -dest { !127.0.0.* !192.1.1.* *:443:563 }
  ssl-gw:         deny-hosts      *
</verb>

Här är ett exempel på hur man använder <em/plug-gw/ för att tillåta 
anslutningar till en nyhetsserver. I detta exemplet låter jag vem som helst i 
det skyddade nätverket ansluta endast till ett system och då endast till dess
<em/news/-port.

Den andra raden tillåter nyhetsservern att skicka sin data tillbaka till det
skyddade nätverket.

Eftersom de flesta klienter förväntas hålla kvar anslutningen medans användaren
läser nyheter så bör timeouten vara lång.

<verb> 
  # NetNews Pluged gateway
  plug-gw:        timeout 3600
  plug-gw: port nntp 196.1.2.* -plug-to 199.5.175.22 -port nntp
  plug-gw: port nntp 199.5.175.22 -plug-to 196.1.2.* -port nntp
</verb>

Gatewayen för <em/finger/ är enkel. Alla i det skyddade nätverket måste först 
logga in och sedan tillåts de att använda <em/finger/-programmet på 
brandväggen. Alla andra får bara ett meddelande.

<verb>
  # Enable finger service 
  netacl-fingerd: permit-hosts 196.1.2.* -exec /usr/libexec/fingerd
  netacl-fingerd: permit-hosts * -exec /bin/cat /usr/local/etc/finger.txt
</verb>

Jag har inte satt upp <em/Mail/ och <em/X-Windows/ tjänsterna än så jag 
inkluderar inte några exempel. Om någon har fungerande exempel så får ni gärna
e-posta dem till mig.

<sect2> Filen <tt>/etc/inetd.conf</tt>
<p>
Här följer en komplett <tt>/etc/inetd.conf</tt> fil. Alla onödiga tjänster har
kommenterats bort. Jag har med hela filen för att visa vad som bör stängas av, 
såväl som för att visa hur man konfigurerar de nya tjänsterna för brandväggen.

<verb> 
  #echo	stream	tcp  nowait  root	internal 
  #echo	dgram	udp  wait    root	internal
  #discard	stream	tcp  nowait  root	internal
  #discard	dgram	udp  wait    root	internal
  #daytime	stream	tcp  nowait  root	internal
  #daytime	dgram	udp  wait    root	internal
  #chargen	stream	tcp  nowait  root	internal
  #chargen	dgram	udp  wait    root	internal
  # FTP firewall gateway
  ftp-gw      stream  tcp  nowait.400  root  /usr/local/etc/ftp-gw  ftp-gw
  # Telnet firewall gateway
  telnet	stream  tcp  nowait      root  /usr/local/etc/tn-gw /usr/local/etc/tn-gw
  # local telnet services
  telnet-a    stream  tcp  nowait      root  /usr/local/etc/netacl in.telnetd
  # Gopher firewall gateway
  gopher	stream  tcp  nowait.400  root  /usr/local/etc/http-gw /usr/local/etc/http-gw 
  # WWW firewall gateway
  http	stream  tcp  nowait.400  root  /usr/local/etc/http-gw /usr/local/etc/http-gw 
  # SSL firewall gateway
  ssl-gw  stream  tcp     nowait  root /usr/local/etc/ssl-gw   ssl-gw
  # NetNews firewall proxy (using plug-gw)
  nntp    stream  tcp     nowait  root    /usr/local/etc/plug-gw plug-gw nntp
  #nntp	stream	tcp	nowait	root	/usr/sbin/tcpd	in.nntpd
  # SMTP (email) firewall gateway
  #smtp	stream  tcp 	nowait  root    /usr/local/etc/smap smap
  #
  # Shell, login, exec and talk are BSD protocols.
  #
  #shell	stream	tcp	nowait	root	/usr/sbin/tcpd	in.rshd
  #login	stream	tcp	nowait	root	/usr/sbin/tcpd	in.rlogind
  #exec	stream	tcp	nowait	root	/usr/sbin/tcpd	in.rexecd
  #talk	dgram	udp	wait	root	/usr/sbin/tcpd	in.talkd
  #ntalk	dgram	udp	wait	root	/usr/sbin/tcpd	in.ntalkd
  #dtalk	stream	tcp	waut	nobody	/usr/sbin/tcpd	in.dtalkd
  #
  # Pop and imap mail services et al
  #
  #pop-2   stream  tcp  nowait  root  /usr/sbin/tcpd	ipop2d
  #pop-3   stream  tcp  nowait  root  /usr/sbin/tcpd	ipop3d
  #imap    stream  tcp  nowait  root  /usr/sbin/tcpd	imapd
  #
  # The Internet UUCP service.
  #
  #uucp    stream  tcp  nowait  uucp  /usr/sbin/tcpd  /usr/lib/uucp/uucico -l
  #
  # Tftp service is provided primarily for booting.  Most sites
  # run this only on machines acting as &dquot;boot servers.&dquot; Do not uncomment
  # this unless you *need* it.  
  #
  #tftp	dgram	udp	wait	root	/usr/sbin/tcpd	in.tftpd
  #bootps	dgram	udp	wait	root	/usr/sbin/tcpd	bootpd
  #
  # Finger, systat and netstat give out user information which may be
  # valuable to potential "system crackers."  Many sites choose to disable 
  # some or all of these services to improve security.
  #
  # cfinger is for GNU finger, which is currently not in use in RHS Linux
  #
  finger	stream	tcp  nowait  root   /usr/sbin/tcpd  in.fingerd
  #cfinger      stream	tcp  nowait  root   /usr/sbin/tcpd  in.cfingerd
  #systat	stream	tcp  nowait  guest  /usr/sbin/tcpd  /bin/ps -auwwx
  #netstat	stream	tcp  nowait  guest  /usr/sbin/tcpd  /bin/netstat -f inet
  #
  # Time service is used for clock syncronization.
  #
  #time	stream	tcp  nowait  root  /usr/sbin/tcpd  in.timed
  #time	dgram	udp  wait    root  /usr/sbin/tcpd  in.timed
  #
  # Authentication
  #
  auth          stream  tcp  wait    root  /usr/sbin/tcpd  in.identd -w -t120
  authsrv	stream	tcp  nowait  root  /usr/local/etc/authsrv authsrv
  #
  # End of inetd.conf
</verb>

<sect2>Filen <tt>/etc/services</tt>
<p>
Det är här allting börjar. När en klient ansluter till brandväggen så ansluter 
den till en känd port (mindre än 1024). Till exempel så ansluter <em/telnet/ på
port 23. Daemonen för <em/inetd/ hör anslutningen och letar upp namnet för
tjänsten i filen <tt>/etc/services</tt>. Sedan startar den programmet som hör
ihop med namnet i filen <tt>/etc/inetd.conf</tt>.

Vissa av tjänsterna som vi skapar finns inte normalt i filen 
<tt>/etc/services</tt>. Du kan para ihop vissa av dem med vilken port du vill.
Till exempel så har jag låtit administratörens <em/telnet/-port (telnet-a) vara
port 24. Du skulle kunna sätta den till 2323 om du ville. För att 
administratören (DU) skall kunna ansluta direkt till brandväggen så måste han
telnetta till port 24 och inte 23, och om du sätter upp filen 
<tt/netperm-table/ som jag gjorde så kan detta endast göras från en maskin i 
ditt skyddade nätverk.

<p>
<verb> 
  telnet-a        24/tcp
  ftp-gw          21/tcp    	   # this named changed
  auth            113/tcp   ident    # User Verification
  ssl-gw          443/tcp
</verb>

<sect>SOCKS Proxyserver
<sect1>Att installera proxyservern
<p>
SOCKS proxyserver finns att hämta ifrån <url url="ftp://sunsite.unc.edu/pub/Linux/system/Network/misc/socks-linux-src.tgz" name="sunsite">. Det finns även ett
exempel på en konfigurationsfil i den katalogen som heter 
<tt/socks-conf/. Packa upp filerna till en katalog på ditt system och
följ instruktionerna för hur man kompilerar det. Jag hade ett par problem när
jag gjorde detta. Se till att dina <tt/Makefile/-filer är korrekta.

En viktig sak att notera är att proxyservern måste läggas till i 
<tt/inetd.conf/. Du skall lägga till en rad

<verb>
  socks  stream  tcp  nowait  nobody  /usr/local/etc/sockd  sockd
</verb>

så att servern kan köras då den efterfrågas.

<sect1>Att konfigurera proxyservern
<p>
SOCKS-programmet använder två konfigurationsfiler. En som beskriver vilken 
access som tillåts, och en som routar förfrågningar till den korrekta 
proxyservern. Access-filen skall finnas på servern och routing-filen skall
finnas på alla Un*x-maskiner. DOS och Macintosh datorer gör sin egen routing.

<sect2>Accessfilen
<p>
Med socks4.2 Beta så heter accessfilen <tt/sockd.conf/. Den skall innehålla
två rader, en tillåt-rad och en neka-rad. Varje rad har tre element:

<itemize>
<item>Identifieraren (permit/deny)
<item>IP-adressen
<item>Adressmodifieraren
</itemize>

Identifieraren är antingen <em/permit/ eller <em/deny/. Du skall ha en rad för
varje.

IP-adressen är en fyrabytes adress i vanligt format (tex 192.168.2.0).

Adressmodifieraren är också en typisk IP-adress. Den fungerar som en nätmask.
Tänk dig adressen som 32-bitars tal. Om en bit är en `1' så måste den 
motsvarande biten i adressen den kontrollerar vara samma som den i IP-adressen.
Till exempel om raden ser ut så här

<verb>
    permit 192.168.2.23 255.255.255.255
</verb>

så tillåter den endast den IP-adress där alla bitar är samma som i 
192.168.2.23, dvs endast 192.168.2.23. Följande rad

<verb>
    permit 192.168.2.0 255.255.255.0
</verb>

tillåter alla adresser i gruppen 192.168.2.0 till 192.168.2.255, dvs hela klass
C domänen. Man skall inte ha följande rad 

<verb>
    permit 192.168.2.0 0.0.0.0
</verb>

eftersom den tillåter alla adresser, oavsett vilken det är.

Så, tillåt först alla adresser som du vill tillåta och neka sedan resten. För
att tillåta alla i domänen 192.168.2.xxx fungerar följande rader bra.

<verb>
    permit 192.168.2.0 255.255.255.0
    deny 0.0.0.0 0.0.0.0
</verb>

Notera den första &dquot;0.0.0.0&dquot; i <em/deny/-raden. Med en modifierare 
som är 0.0.0.0 så spelar fältet med IP-adressen ingen roll. Men att ha endast
nollor är normen eftersom det är enkelt att skriva.

Det är tillåtet med mer än en rad av varje.

Specifika användare kan också ges eller nekas access. Detta görs via <em/ident/
autentisering. Alla system stöder inte <em/ident/, tex Trumpet Winsock, så jag
tar inte upp detta här. Dokumentationen för SOCKS täcker detta ganska bra.

<sect2>Routingfilen
<p>
Routingfilen i SOCKS är dåligt namnsatt till <tt/socks.conf/. Jag säger
&dquot;dåligt namnsatt&dquot; eftersom det är så likt namnet på accessfilen så
det kan vara lätt att blanda ihop dem.

Routingfilen finns för att tala om för SOCKS-klienterna när de skall använda
SOCKS eller inte. Till exempel i vårat nätverk så behöver inte 192.168.2.3
använda SOCKS för att kommunicera med 192.168.2.1 (brandväggen). Den har en 
direkt anslutning via Ethernet. Den definierar loopback-enheten, 127.0.0.1, 
automatiskt. Naturligtvis så behövs inte SOCKS för att kommunicera med sig
själv. Det finns tre nyckelord:
<p>
<itemize>
<item>deny
<item>direct
<item>sockd
</itemize>

<tt/deny/ talar om när SOCKS skall neka en förfrågan. Här används samma tre 
fält som i <tt/sockd.conf/: identifierare, adress och modifierare. Generellt, 
eftersom detta även kontrolleras av accessfilen <tt/sockd.conf/, så sätts 
fältet för modifieraren till 0.0.0.0. Om du vill göra så att du inte kan 
kontakta någon dator, så kan du göra det här.

Raden med <tt/direct/ bestämmer vilka adresser man inte skall använda SOCKS 
för. Detta är adresser vilka man kan nå utan att gå igenom proxyservern. 
Återigen har vi de tre fälten identifierare, adress och modifierare. Vårt 
exempel skulle ha

<verb>
    direct 192.168.2.0 255.255.255.0
</verb>

vilket ger direkt kontakt med alla datorer på vårt skyddade nätverk.

Raden med <tt/sockd/ talar om vilken dator som har daemonen för SOCKS-servern
på sig. Syntaxen är 

<verb>
  sockd @=<serverlist> <IP address> <modifier>
</verb>

Notera `@='. Detta låter dig specificera IP-adresserna för en lista av 
proxyservrar. I vårt exempel så använder vi endast en proxyserver. Men man kan
ha många, för att tillåta större belastning och för redundans i fall något går
sönder.

Fälten för IP-adress och modifierare fungerar som för de andra exemplena. Du 
specificerar vilka adresser som går vart genom dessa.

<sect1> DNS bakom en brandvägg
<p>
Att sätta upp en DNS innanför en brandvägg är en ganska enkel uppgift. Du 
behöver bara sätta upp en DNS på brandväggen och sedan låta alla maskiner 
bakom brandväggen använda denna.

<sect1>Att arbeta med en proxyserver
<sect2>Unix
<p>
För att dina applikationer skall fungera med proxyservern så måste de vara
&dquot;sockifierade&dquot;. Du behöver två olika <em/telnet/ar, en för direkt
kommunikation och en för kommuntikation via proxyservern. Med SOCKS följer
instruktioner om hur man SOCKiferar ett program, såväl som ett par 
för-SOCKifierade program. Om du använder den SOCKifireade versionen för en 
direkt anslutning så kommer SOCKS automatiskt att byta till rätt version. På
grund av detta så vill vi ändra namn på alla programmen på vårt skyddade 
nätverk och ersätta dem med de SOCKifierade versionerna. &dquot;Finger&dquot; 
blir &dquot;finger.orig&dquot;, &dquot;telnet&dquot; blir 
&dquot;telnet.orig&dquot;, osv. Du måste informera SOCKS om dessa via filen
<tt>include/socks.h</tt>.

Vissa program tar hand om routing och sockifiering själva. Netscape är ett av 
dessa. Du kan använda en proxyserver under Netscape genom att skriva in
serverns adress (192.168.2.1 i vårt fall) i SOCKS-fältet under Proxies. Man 
måste iallafall pilla lite med alla applikationer oavsett hur de hanterar en 
proxyserver.

<sect2>MS Windows med Trumpet Winsock
<p>
Trumpet Winsock har inbyggt stöd för proxyserver. I &dquot;setup&dquot; menyn, 
skriv in IP-adressen för proxyservern och alla adresser som kan nås direkt. 
Trumpet hanterar sedan alla utgående paket.

<sect2>Att få proxyservern att fungera med UDP-paket
<p>
SOCKS-paketet fungerar endast med TCP-paket, inte UDP. Detta gör det lite 
mindre användbart. Många användbara program, som <em/talk/ och <em/Archie/, 
använder UDP. Det finns ett paket som är designat för att användas som en 
proxyserver för UDP-paket som heter UDPrelay, av Tom Fitzgerald
&lt;fitz@wang.com&gt;. Tyvärr så är det inte, när detta skrivs, kompatibelt med
Linux.

<sect1>Nackdelar med proxyservrar
<p>
Proxyservern är, framför allt, en <bf/säkerhetsenhet/. Att använda det för att
öka tillgången till Internet med ett begränsat antal IP-adresser har många 
nackdelar. En proxyserver medför bättre access till Internet från insidan av 
det skyddade nätverket, men det gör insidan helt oåtkomligt från utsidan. Detta
betyder att inga servrar, talk eller archieanslutningar, eller direkt e-post 
fungerar till maskinerna i det skyddade nätverket. Dessa nackdelar kan verka 
obetydliga, men tänk på det på detta sättet:

<itemize>
<item>Du har lagt en rapport som du håller på att jobba med på din dator i 
ett brandväggsskyddat nätverk. Du är hemma och bestämmer dig för att du vill gå
igenom den. Det kan du inte. Du kan inte nå din dator eftersom den är bakom
brandväggen. Du försöker att logga in på brandväggen först, men eftersom alla
har proxyserveraccess, så har ingen lagt upp ett konto åt dig på den.

<p>
<item>Din dotter går på college. Du vill mäjla henne. Du har några privata 
saker att prata med henne om, och vill helst att hon skickar e-posten direkt 
till din maskin. Du litar helt och hållet på systemadministratören, men det är
ju trots allt privat post. Men detta går inte.

<p>
<item>Oförmågan att använda UDP-paket är en stor nackdel med proxyservrar. Jag
föreställer mig att detta kommer att fungera snart.
</itemize>

FTP skapar ett annat problem med en proxyserver. När man ger kommandot <tt/ls/,
så öppnar FTP-servern en socket på klientmaskinen och skickar informationen 
genom den. En proxyserver tillåter inte detta, så FTP fungerar inte.

Dessutom är proxyservrar långsamma. På grund av den större overheaden så är 
nästan alla andra sätt att få accessen snabbare.

Så om du har IP-adresserna och inte bekymrar dig för säkerheten så skall du 
inte använda en brandvägg och/eller proxyserver. Om du inte har IP-adresserna
och inte bekymrar dig för säkerheten så kan du kanske använda en IP-emulator
som <em/Term/, <em/Slirp/ eller <em/TIA/. <em/Term/ finns på 
<url url="ftp://sunsite.unc.edu" name="sunsite">, <em/Slirp/ finns på 
<url url="ftp://blitzen.canberra.edu.au/pub/slirp" 
name="blitzen.canberra.edu.au"> och <em/TIA/ finns på 
<url url="http://www.marketplace.com" name="marketplace.com">. Dessa paket är
snabbare, tillåter bättre anslutningar och tillhandahåller bättre 
tillgänglighet till det privata nätverket från Internet. Proxyservrar är bra 
för de nätverk som har många datorer som vill ansluta till Internet 
`on the fly', med en inställning och lite arbete efter det.

<sect>Avancerade Konfigurationer
<p>
Det finns en konfiguration som jag vill gå igenom innan jag avslutar detta 
dokumentet. Det som jag precis har gått igenom räcker antagligen för de flesta.
Men det som följer kommer att visa en mer avancerad konfiguration och kan 
dessutom klara upp lite frågor. Om du har frågor om det som jag just gått 
igenom, eller bara är intresserad av mångsidigheten hos proxyservrar och 
brandväggar, läs vidare.

<sect1>Ett stort nätverk med tyngdpunkten på säkerhet
<p>
Antag till exempel att du är ledare för en milis och du vill ha ett nätverk. Du
har 50 datorer och ett subnät med 32 (5 bitar) IP-adresser. Du behöver lite 
olika nivåer på access inom nätverket eftersom du säger olika saker till dina
anhängare. Därför behöver du skydda vissa delar av nätverket från resten.

Nivåerna är:

<enum>
<item><bf/Den yttre nivån./ Denna nivån är öppen för alla. Det är här där du 
skrönar och skrävlar för att locka nya frivilliga.

<item><bf/Troop/. Detta är nivån för personer som har kommit förbi den yttre
nivån. Det är här du lär dem om den elaka statsmakten och hur man gör bomber.

<item><bf/Mercenary./ Det är här de <em/riktiga/ planerna finns. På denna nivån
lagras all information om hur den 3:e världens regering skall ta över världen, 
dina planer härrörande Newt Gingrich, Oklahoma City och vad som verkligen finns
i de där hangarerna i area 51.
</enum>

<sect2>Att sätta upp nätverket
<p>
IP-adresserna arrangeras som följer:

<itemize>
<item>En adress är 192.168.2.255, vilken är broadcastadressen och kan inte 
användas.
<item>23 av de 32 IP-adresserna allokeras till 23 datorer som skall vara 
åtkomliga från Internet.
<item>En IP-adress går till en Linuxburk på det nätverket
<item>En går till en annan Linuxburk på det nätverket.
<item>Två IP-adresser går till routern.
<item>Fyra adresser blir över, men ges domännamnen paul, ringo, john och 
george, bara för att förvilla lite grann.
<item>De skyddade nätverken har båda adresserna 192.168.2.xxx
</itemize>

Sedan byggs två separata nätverk i olika rum. De routas via infraröd Ethernet
så de är helt osynliga utanför rummen. Lyckligtvis så fungerar infraröd 
Ethernet precis som vanlig Ethernet.

Dessa båda nätverk kopplas till en av Linuxburkarna med en extra IP-adress.

Det finns en filserver som kopplar ihop de två skyddade nätverken. Detta för 
att planerna för att ta över världen involverar några av de högre trupperna.
Filservern har adressen 192.168.2.17 för `Troop'-nätverket och 192.168.2.23 för
`Mercenary'-nätverket. Den måste ha två olika IP-adresser eftersom den har två
nätverkskort. IP-vidareskickning är avstängt.

IP-vidareskickning är även avstängt på de två Linuxburkarna. Routern kommer 
inte att skicka vidare paket ämnade för 192.168.2.xxx adresser om den inte
explicit får sådana direktiv, så Internet kan inte komma in. Anledningen att
vidareskickning skall vara avstängt här är att paket från `Troop'-nätverket 
inte skall kunna nå `Mercenary'-nätverket, och vice versa.

NFS-servern kan även ställas in för att erbjuda olika filer till de olika 
nätverken. Detta kan bli användbart, och lite trixande med symboliska länkar 
gör så att vissa filer kan delas av alla. Denna inställning och ett extra 
nätverkskort gör att denna filservern kan användas av alla tre nätverken.

<sect2>Att sätta upp proxyservern
<p>
Eftersom alla tre nivåerna vill kunna ha koll på Internet för sina egna oärliga
syften, så måste alla tre ha access till Internet. Det externa nätverket är
direktkopplat till Internet så vi behöver inte anstränga oss med proxyservrar 
där. `Mercenary' och `Troop' nätverken är bakom brandväggar så vi behöver
sätta upp proxyservrar där.

Båda nätverken kommer att sättas upp likartat. Båda är tilldelade samma 
IP-adresser. Jag lägger in några extra parametrar, bara för att göra det lite
mer intressant.

<enum>
<item>Ingen kan använda filservern för access till Internet. Det skulle öppna
filservern för virus och andra hemska saker, och den är hyfsat viktig, så den
får inte användas mot Internet.

<item>Vi kommer inte tillåta att trupperna har tillgång till World Wide Web. De
är under utbildning och den typen av informationshämtande kan vara skadlig.
</enum>

Så filen <tt/sockd.conf/ på `Troop'-Linuxburken kommer ha en rad som den här:

<verb>
    deny 192.168.2.17 255.255.255.255
</verb>

Och på `Mercenary'-maskinen:

<verb>
    deny 192.168.2.23 255.255.255.255
</verb>

Och, `Troop'-Linuxburken har även en rad som denna:

<verb>
    deny 0.0.0.0 0.0.0.0 eq 80
</verb>

Detta säger att man skall neka alla maskiner som försöker komma åt port 80 
(http porten). Det tillåter fortfarande alla andra tjänster, endast www-access
nekas.

Sedan så har båda filerna följande:

<verb>
    permit 192.168.2.0 255.255.255.0
</verb>

för att tillåta alla datorer på 192.168.2.xxx nätverket att använda denna 
proxyserver, förutom de som redan har blivit nekade (dvs filservern och 
www-access från `Troop'-nätverket).
<p>

Så filen <tt/sockd.conf/ på `Troop'-nätverkets Linuxburk kommer se ut så här:

<verb>
    deny 192.168.2.17 255.255.255.255
    deny 0.0.0.0 0.0.0.0 eq 80
    permit 192.168.2.0 255.255.255.0
</verb>

och på `Mercenary'-nätverkets Linuxburk ser den ut så här:

<verb>
    deny 192.168.2.23 255.255.255.255
    permit 192.168.2.0 255.255.255.0
</verb>

Detta borde konfigurera allting korrekt. Alla nätverk är isolerade med lagom
mängd interaktion. Alla borde vara lyckliga.

Nu, ta över världen!
</article>
