Introduktion till brandväggsskydd

TCP

För TCP-trafik behövs en brandväggsregel som släpper fram uppkopplingstrafiken från kliendatorn till servern och en brandväggsregel som släpper fram svarstrafiken från servern. Då vi oftast endast vill ha svarstrafik från en server och inte några uppkopplingsförsök från servern sätter vi upp en regel för svarstrafiken som endast tillåter svarstrafik och inte några uppkopplingsförsök (SYN utan ack).

UDP

UDP-trafik är inte förbindelseorienterad och där går det inte att titta på SYN (uppkopplingsförsök) i trafiken eftersom det inte finns något sådant i UDP. På samma sätt som för TCP behövs en brandväggsregel för trafiken från klienten till servern och en regel för trafiken från servern till klienten.

Utgående trafik

För utgående trafik från en Linuxdator finns inte så stor anledning att begränsa trafiken. Det är lätt att glömma öppna för någon tjänst och dessutom finns det få anledningar att begränsa sin egen utgående trafik. Det som kan vara är om man är rädd för att ha fått in en mask eller en trojansk häst och vill hindra dessa från att etablera kontakt med omvärlden. Då kan det vara bra att begränsa den utgående trafiken. På en linuxdator går det även att med hjälp av netfilter/iptables begränsa så endast vissa program/processer får komma åt nätet. Du kan läsa mer om det under Netfilter/Iptables -> Mer avancerade saker -> Reglera utgående trafik för lokala processer.

Inkommande trafik

För inkommande TCP-trafik kan det vara bra att begränsa så att inga uppkopplingar (SYN-paket) får komma in förutom för de få tjänster man vill ha igång. Däremot behöver svarstrafik från servrar ute på nätet komma in till den egna maskinen. Med ipfwadm, ipchains och netfilter/iptables går det att begränsa så att svarstrafiken kommer fram men inga uppkopplingar kan göras (se separata avsnitt för ipfwadm, ipchains respektive netfilter/iptables).

För UDP sker inga uppkopplingar och därmed blir den trafiken lite svårare att begränsa utan att spärra ut för mycket så att svarstrafik inte stoppas. UDP-trafik in till höga portar som är svarstrafik vill man att den ska komma fram förutom trafik in till port 2049 (NFS) och portar från 6000 och en bit uppåt ( typiskt 6000 - 6100 för X Window trafik). Trafik till NFS och X Window system bör spärras. UDP-trafik in till portar under 1024 finns oftast ingen anledning till att tillåta. I netfilter/iptables går det med modulen state och tillståndet ESTABLISHED att kontrollera så att endast UDP-svar släpps in som är hör ihop med en utgående förbindelse. Netfilter/iptables håller reda på alla förbindelser och när det kommer in UDP-paket som hör ihop med en utgående förbindelse så ser netfilter att de hör ihop. Tack vare det kan state, ESTABLISHED, användas för att släppa in endast svarstrafik.

ICMP

ICMP används för att skicka meddelanden. För ICMP gäller samma sak som för UDP att inga förbindelser kopplas upp. ICMP är envägskommunikation men ofta skickar en klientapplikation ett ICMP-meddelande och servern skickar ett annat ICMP-meddelande som svar. ICMP kan också vara ett meddelande till klienten att någonting inte fungerade, som t.ex. att datorn, nätet eller tjänsten inte går att nå. För detta behövs brandväggsregler som släpper fram ICMP.

Vilken ICMP-trafik som ska släppas in är en smaksak men det är sällan som mer än ICMP 0, 3, 4, 8 och 11 behövs. ICMP 3 Destination Unreachable anger att en dator, ett nätverk, en tjänst eller liknande inte är nåbar. Det är oftast bra att släppa in sådana svar. ICMP 11 Time Exceeded talar om att paketen har blivit kastade någonstans på vägen. Det är bra att få reda på sådant också. Om UDP-trafik skickas för fort får man ett ICMP 4, Source Quench, som svar. Det är bra att ta emot dessa så att datorn kan få reda på det och skicka UDP-paket i lite långsammare tempo.

Inkommande ICMP 0, 3, 4, 8 och 11 kan spärras men då kommer utgående traceroute, ping och en del annat att inte fungera. Inkommande och utgående ICMP-trafik från/till det egna nätverkets broadcastadress kan vara bra att spärra så att datorn inte svarar på t.ex. broadcastping från det egna nätverket. Eventuellt kan det vara bra att även släppa in ICMP-typ 5, redirect.

DNS

För att slippa hålla reda på IP-adresser används nameservrar, DNS, som sköter om uppslagningarna mellan namn och IP-adress. DNS-uppslagningar från Linuxdatorn vill man att det ska gå att göra. All utgående trafik enligt ovan släpps fram och svarstrafiken måste kunna komma tillbaka. För detta behövs en brandväggsregel som släpper fram UDP-svarstrafiken från DNS-servern till klientprogrammet på den egna Linuxdatorn.

ssh

SSH ger en säker krypterad förbindelse. SSH krypterar även din X-trafik. För att det ska fungera måste dock din dator som du sitter vid kunna kommunicera med sig själv. För detta behövs brandväggsregler som släpper fram X-trafik från den egna datorn till den egna datorn. Notera att ssh körs över TCP och den enkelriktade pilen mellan de två datorerna är en förenkling och borde egentligen se ut som i bilden för tcp-trafik i kapitlet "De vanligaste nätverkstjänsterna".

FTP

FTP används vid filöverföringar. FTP-trafiken skickas i klartext. Krypterad filöverföring kan enkelt fås med ssh. För att aktiv FTP ska fungera måste servern kunna göra en TCP-uppkoppling från port 20 mot en hög port på den egna datorn. Det kan vara lite vanskligt att tillåta TCP-uppkopplingar (SYN-paket) mot höga portar på den egna datorn. De flesta FTP-programmet kan köra i passiv mode och bör göra så. Om aktiv mode inte absolut måste användas undvik den och spärra inkommande TCP-uppkopplingar (SYN-paket) till höga portar.

Se avsnitten "Introduktion till TCP/IP och nätverk" och "Introduktion till hur de vanligaste nätverkstjänsterna fungerar" för utförligare beskrivning av hur nätverkstrafiken fungerar.

Copyright © 2010 Kjell Enblom.
This document is covered by the GNU Free Documentation License, Version 1.1