Linux Netfilter/IPTables grunder

Linux Netfilter/IPTables grunder Brandvägg på klientdatorn Kalevi Nyman kalevi.nyman@linuxhuset.se 2005 10 26

Översikt Att driva Internetanslutet nätverk (TCP, UDP, IP, ICMP) Vad är klientdatorbaserad brandvägg? Varför använda klientdatorbaserad brandvägg? Grunder Stateful (dynamisk) paketfiltrering IPTables grunder Att skapa regler för en stand alone dator Diagnos, felsökning Referenser

Netfilter/IPTables Netfilter är en programmodul i Linuxkärnan Netfilter styrs med hjälp av programmmet IPTables IPTables fungerar som ett gränssnitt mot Netfilter Skapar kedjor av regler Statiska Dynamiska

Protokollstack OBS! Förenklad bild. Presentations och Sessionsskiktet är borttaget mellan Application och Transport skikten av utrymmesskäl.

Application layer Klient och servertillämpningar Endpunkterna kommunicerar med tillämpningsspecifika protokoll. Här: HTTP, POP, SMTP, NTP; SSH o.s.v. Tillämpningsprogrammet ber transportprogrammet att skapa en pålitlig förbindelse till till måldatorn (enbart TCP).

Transport layer TCP & UDP protokol Endpunkterna kommunicerar med TCP och UDP protokoll Endpunkterna identifieras av portnummer 1 65355 UDP ger en osäker förbindelse. Varken paketordning eller ankomst garanteras TCP ger en säker förbindelse. Förbindelsen garanterar paketordning och ankomst

Network layer IP protokoll, ICMP meddelanden Datorer identifieras med unik IP Adress Tillhandahåller även routingtjänster Endpunkterna är medvetna om mellanliggande hopp ICMP meddelanden utväxlas mellan datorer på Network layer

Data Link och Physical layer Drivrutiner till nätverkskort och topologisecifika protokoll som Ethernet, ATM, FDDI, Token Ring Nätverkskort kan variera beroende på vilken topologi nätverket har. Drivrutiner varierar beroende på tillverkare och topologi Det fysiska mediet varierar. Ex. Fiber, koppartråd, radiovågor med flera

Sammanfattning protokollstack OBS! Förenklad bild. Presentations och Sessionsskiktet är borttaget mellan Application och Transport skikten av utrymmesskäl.

OSI modellen och TCP/IP

Protokoll som berörs av Netfilter ICMP Internet Control Messagr Protocol (Network) ICMP används typiskt för att kontrolera om en dator är vid liv (igång), rapportera fel och meddela routing information UDP User Datagram Protocol (Transport) UDP skapar ingen förbindelse eller kontrollfunktioner och är därför snabb och effektiv. UDP är förbindelselös osäker protokoll. Jämför med vykort på posten TCP Transmission Control Protocol (Transport) TCP är förbindelseorienterat, pålitlig protokoll som skapar tvåvägs förbindelse mellan datorerna, med bekräftelser att paket har kommit fram och mycket mer. Jmf. telefon.

Internet Control Message Protocol ICMP paket skickas för att kontrollera om en dator är vid liv, rapportera fel och vidarebefordra routing information Ett ICMP paket skickas till en IP Adress inte till en port ICMP paket identifiera av typ och i vissa fall koder för undertyp (se RFC 1700 för en lista) ICMP paket är sk. råa datagram och dessa är opålitliga som UDP Vanligaste användningsområdet är PING eller ICMP echorequest fråga (typ 8) och svar (typ 0) En annan vanlig ICMP typ är destination unreachable (typ 3) Det finns många undertyper som host unreachable eller port unreachable. Om du ser port unreachable finns ingen process igång som stöder anropet Vissa ICMP paket är mycket viktiga. En del andra kan användas för en DoS attack eller värre. Vi måste sålla bort dom som vi inte vill ha eller ta emot.

User Datagram Protocol UDP paket är förbildelselösa, ej pålitliga, ingen bekräftelse av mottaget paket krävs och därför är UDP snabb och effektiv UDP paket skickas från källa/port till mål/port (IP Adress/port) Hos måldatorn kan följande hända: svar kan skickas av UDP tillämpning hos mottagaren port unreachable kan skickas av mottagande datorns operativsystem Ingenting Det är svårt att veta om en UDP tjänst är igång hos mottagaren eller om måldatorn är nere. Därför kan vi använda programmet PING för att bestämma om måldatorn är vid liv. Med programmet nmap kan vi kontrollera alla öppna portar hos måldatorn. DNS Domain Name Services använder UDP vid en förfrågan om var en dator finns på nätverket.

User Datagram Protocol UDP port öppen: DNS fråga skickas från nod A till nod B som får korrekt svar UDP port stängt: frågan ger ett negativt svar port unreachable (typ 3 kod 3) ICMP paket UDP port tillstånd okänd: Inget svar erhålles. Nod B är nere, eller DNSservern vill inte svara eller dess port (53) är filtrerat

Transmission Control Protocol TCP paket är förbindelseorienterade, pålitliga och behåller interna ordningen. Innan data sänds över TCP skapas en förbindelse mellan noderna. En TCP förbindelse skapas mellan källan (ip Adress/port) och målet (IP Adress/port). Notera att TCP och UDPportarna är olika. TCP Transportskiktet försäkrar pålitliga förbindelser. En tillämpning kan lita på förbindelsen när den väl är etablerat. TCP Förbindelse skapas med en trestegs handskakningsprocedur.

Transmission Control Protocol Diagrammet visar principen för trestegshandskakning för etablering och avslutning av en förbindelse. Att förstå flaggornas betydelse i huvudet på ett TCP paket är mycket viktigt när man skapar regler för brandvägg. I många attacker används TCPpaket med felaktiga flaggor i pakethuvuden. Ett TCP paket utan flaggor är aldrig ett giltigt paket.

Transmission Control Protocol Om datorn tar emot ett paket som inte alls tillhör en pågående session, skickas ett RST (reset) paket som svar för att återställa förbindelsen Det är vad som händer när ett SYN paket skickas i ett försök att öppna förbindelse till en stängd port (ICMP 3.3 fungerar också men RFC 793 föreslår att RST TCP paket skickas i stället). Till skillnad för UDP trafik, är ett uteblivet svar ett oväntat tillstånd som resuterar i en timeout. Om noden är igång indikerar detta ett nätverksfel eller att porten är filtrerat. Här kommer verktyget nmap till nytta igen. Den skannar snabbt alla öppna portar på måldatorn och vi får reda på sakernas tillstånd väldigt lätt utan besvär.

Blandat Förbindelser till kända tjänster skapas genom att ansluta till kända tjänsteportar Dessa definieras i filen /etc/services Huvudet i ett IP paket innehåller ett 8 bitars protokollfält som anger protokollet I Linux identifieras protokollet i filen /etc/protocols Ibland är det bra att veta att protokollnumren är ICMP=1, TCP=6 och UDP=17. Man möter i vissa situationer dessa nummer när vi hanterar Netfilter.

Vad är Brandvägg på en klientdator? I det här sammanhanget definierar brandväggen exakt den tillåtna trafiken till och från en dator. Det är ett paketfilter som bestämmer för varje enskild paket om den släpps in eller ej. Den är normalt en del av operativsystemet och fungerar på OSI skikten 3 och 4. I Linux är filtret implementerad som moduler till kärnan (kernel) och användarverktyg.

Varför brandvägg på en klientdator? Säkerhet och integritet I maskiner som är anslutna till Internet skannas öppna portar ofta Ju mindre en utomstående kan få veta om en dator desto svårare blir det att bryta sig in. En lokal demon kanske inte kan konfigureras att lyssna endast på 127.0.0.1 LPD krävs även för att skriva ut lokalt NTPD och BIND har begränsade konfigurationstillägg. Protokollen exploateras ofta under inbrytningsförsök Tillämpningar kan lyssna på portar som du inte känner till. Här kommer nmap än en gång till hjälp när du skall testa om din brandvägg håller tätt!

Varför brandvägg på en klientdator? Även om en tillämpning eller tjänst kan konfigureras med begränsningar (TCP wrapper) skapas en kortvarig förbindelse som är avslöjande Om portarna till dessa tjänster är filtrerade stoppas obehöriga redan i Network skiktet och kommer aldrig upp till tillämpningen eller demonen. Även om någon försöker skapa en paketflod kan det begränsas eller helt hindras i de nedre skikten. Ju tidigare paketen kastas, desto bättre!

Varför brandvägg på en klientdator? Skall jag använda en brandvägg på min klientdator även om lokala nätverket redan är bakom en brandvägg? Här några argument: Om någon dator inom det lokala nätverket blir knäckt/hackad är brandväggen mot Internet värdelös. Brandväggen släpper in trafik som du helst är utan En central brandvägg kan vara svår att konfigurera för varje dator i nätverket. Det är betydligt enklare att bestämma vilken trafik du vill/måste tillåta på din lokala dator. Det finns inga garantier mot lokala knäckare på insidan av brandväggen.

Brandvägg grunder Filtrerande brandväggar är alltid snabbare än någon annan typ. Filtrerande brandvägg filtrerar varje paket för sig Kriterierna kan vara alla som brandväggen stöder. Nedan några vanliga kriterier: Käll eller måldator och IP Adress Protokoll, portar (TCP och UDP) och typ och kod för ICMP TCP flaggor i pakethuvudet (SYN,RST,ACK...) MAC hårdvaruadresser Nätverkskort Paketstorlek Frekvensbegränsning (antal paket per tidsenhet)

Brandvägg grunder När ett pakets egenskaper passar en regel kan följande tre åtgärder vidtas: Paketet accepteras och vidarebefordras in eller ut Paketet kastas som om det aldrig existerade Någon sorts nix meddelande skickas till avsändaren De flesta paketfilter har särskilda regler för: Inkommande paket Utgående paket Paket som skall vidarebefordras t.ex. via en router.

Dynamisk paketfiltrering Hittills har de beskrivna kriterierna varit statiska. Ingen hänsyn har tagits till paketens tillstånd. Kommer paketet som svar till ett anrop? Har paket från källan blivit tidigare avvisade? Kommer paketet från en redan etablerad förbindelse? Är paketet nytt fast vi har en etablerad förbindelse? Är det ett SYN paket från en etablerad förbindelse? Ser paketet ut att komma från den lokala datorn eller nätet fast den vill komma in från Internet via nätverkskortet / routern / modemet? o.s.v.

Dynamisk paketfiltrering Det finns många fall då vi har nytta av att komma ihåg hur föregående paket som matchade ett visst kriterium hanterades, när vi skall bestämma hur vi hanterar samma sorts paket i framtiden. Om du vill begränsa inkommande TCP paket som svar på frågor som är initierade från din dator, har du två val: Acceptera alla inkommande paket utom paket som innehåller enbart en ensam SYN flagga. Vi kastar dessa. Acceptera alla inkommande TCP paket som anger källan (IP Adress/port) och målet (IP Adress/port) av en SYN förfrågan från din dator (med omväda end punkter).

Dynamisk paketfiltrering Dynamiska paketfilter håller sig med en tillståndstabell av accepterade paket. Den kan användas som ett kriterium för andra regler. Tabeller som berör aktuell etablerad förbindelse existerar enbart under förbindelsen och raderas då förbindelsen bryts eller efter lång time out nås. Alla dynamiska filter har tabeller på protokollen UDP och ICMP, vilka i sig själv är statiska.

Dynamisk paketfiltrering För UDP gäller relativt korta tidsintervaller i tillståndstabellen då vi kan bara uppskatta överföringstiden för UDP paket Dynamisk inspektion av paket möjliggör en förenklad och optimerad mängd regler Enbart regler för input behöver vara explicita Genom att placera dynamiska regler i början av kedjan undviks att paketen löper genom hela regelkedjan Dynamisk filtrering är implementerad från 2.4.x kärnan

Regler, Kedjor och Åtgärder IPTables organiserar regler i kedjor När ett paket når filtret, granskas paketet med filterregler en i taget från första till sista. När ett paket stämmer överens med en regel kan åtgärden vara terminal (vi kastar paketet) åtgärden är inte terminal, vi kanske loggar händelsen och låter paketet löpa vidare till nästa kedja Om åtgärden är terminal, stannar processen där och nästa paket står i tur

Regler, Kedjor och Åtgärder Netfilter har tre inbyggda filterkedjor: INPUT, OUTPUT och FORWARD I en inbyggd kedjas slut gäller standardåtgärden policy (ACCEPT eller DROP) I slutet av en användardefinierad kedja, hoppar processen tillbaka och fortsätter där den avslutade.

Regler, Kedjor och Åtgärder Alla inkommande paket, även loopback måste passera input. De flesta regler hamnar i kedjan input. Alla paket filtreras en gång utom loopback som filtreras två gånger Jag tar inte upp NAT här. Den tillhör en avancerad kurs.

Regler, Kedjor och Åtgärder iptables är uppbyygt i moduler både moduler i kärnan (kernel) och programmet iptables med vilken användaren kan skapa och manipulera kedjor mm. Det finns moduler för att jämföra paket med kriterier och hoppa ( j = jump) till mål (target). De enda inbyggda målen är ACCEPT och DROP Andra nyttiga mål är: Användardefinierade mål LOG loggar förekomst av paket i sysloggen (kärnan) som är icke terminal mål där processen fortsätter efter loggning REJECT som kastar paket och skickar ett ICMP meddelande eller RST TCP svar. Det finns även nya experimentella mål skrivna som nya moduler av Linux gemenskapen. Dessa kommer att spela en viktig roll i framtiden.

Kommandosyntax All manipulation av Netfilter sker med programmet iptables En regel skapas genom att ange kriterier och mål enlig nedan: Regeln ovan säger att lägg till regel (-A) i kedjan INPUT ocht när ett paket har käll adressen (-s) på den lokala datorn (127.0.0.0/8) men kommer in via nätverket (-i eth0) hoppa (-j=jump) till målet DROP dvs. kasta paketet. iptables-save och iptables-restore är tillägsverktyg.

Kommandosyntax Grundläggande kommandon:

Kommandosyntax Grundläggande kriterier och andra tillägg:

Kommandosyntax Jämförelsekriterier för TCP, UDP och ICMP:

Kommandosyntax Jämförelsekriterier för paketens tillstånd:

Kommandosyntax Multiport, MAC och limit jämförelsekriterier

Kommandosyntax Mål (Target) jämförelsekriterier

Kommandosyntax REJECT och LOG jämförelsekriterier

Regelverk När du skapar ett regelverk måste du veta: Vilka tjänster du behöver (HTTP, SSH o.s.v.)? Behöver någon av dessa tjänster RPC? Behöver du dela filer med NFS (NFS behöver RPC)? Hur restriktiv vill du vara? Hur mycket information vill du dela? Behöver din organisation speciella öppna portar, tjänster eller beteenden? Är din dator en del av en NIS domän? Använder ni DHCP för dynamiska IP Adresser?

Regelverk Antaganden för detta exempel: Vi vill vara extremt restriktiva. Vi kan ändra senare Vi vill bevara data integritet Vi använder inte NIS, NFS eller andra RPC tjänster Vi har en fast IP Adress lokalt (Ingen DHCP) Vi vill använda SSH från överallt! Vi vill ha en Webbserver igång Vi vill logga kastade paket Inga andra speciella restriktioner finns

Regelverk Vår dator: IP Adress: 12.5.7.15 Netmask: 255.255.255.0 (24) Router mot Internet: 12.5.7.1 Lokala IP nätverk: 12.5.7.0/24 och 12.5.8.0/24

Regelverk konf. start, ex. 1/6 Först rensar vi alla gamla regler och kedjor iptables -F iptables -X iptables -t nat -F iptables -t mangle -F Sedan bestämmer vi standardregler (Default policy) iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT iptables -t nat -P PREROUTING ACCEPT iptables -t nat -P POSTROUTING ACCEPT iptables -t nat -P OUTPUT ACCEPT Här skapar vi några egna kedjor iptables -N EXT-IN iptables -N ONSITE-IN iptables -N SPOOF iptables -N SCAN iptables -N ICMP # rensar alla filterkedjor # rensar alla anv. def. kedjor # rensar alla nat kedjor # rensar alla mangle kedjor # källa utanför lokala nätet # källa lokala nätet # kollar efter falska IP-Adresser # kollar efter konstiga TCP-paket # siktar in sig på OK icmp-paket

Regelverk konf. nya kedjor, ex. 2/6 Logga och kasta paket kräver två regler, därför skapar vi en kedja logga/kastat. Vi skapar även kedjor med olika beskrivningar för att analysera logfilerna. (ex. -j LOG -log-prefix spoofdrop ) iptables -N SPOOFDROP # falska paket loggas och kastas iptables -A SPOOFDROP -j LOG -log-prefix spoofdrop --log-ip-options -log-tcp-options - log-tcp-sequence # skriv allt på en rad ovan iptables -A SPOOFDROP -j DROP Nu fortsätter vi att skapa nya kedjor och skriva in regler iptables -N SCANDROP # scannerpaket loggas/kastas iptables -A SCANDROP -j LOG log-prefix scan drop --log-ip-options log-tcp-options --log-tcp-sequence # skriv allt på en rad ovan iptables -A SCANDROP -j DROP iptables -N ICMPDROP # konstiga ICMP-paket loggas/kastas iptables -A ICMPDROP -j LOG log-prefix ICMP DROP --log-ip-options - log-tcp-options - log-tcp-sequence # skriv allt på en rad ovan iptables -A ICMPDROP -j DROP # fortsätter...

Regelverk konf. nya kedjor, ex. 2/6... fortsättning iptables -N POLICYLOG # logga/kasta om standardregel bryts iptables -A POLICYLOG -j LOG - log-prefix POLICY DROP --log-ip-options - log-tcp-options - log-tcp-sequence # skriv allt på en rad ovan iptables -N INVALDROP # logga/kasta om fel tillstånd iptables -A INVALDROP -j LOG -log-prefix INVALID DROP --log-ip-options - log-tcp-options - log-tcp-sequence # skriv allt på en rad ovan iptables -A INVALDROP -j DROP iptables -N EXTDROP # logga/kasta det som blir över från EXT-IN iptables -A EXTDROP -j LOG - log-prefix EXT-IN DROP --log-ip-options - log-tcp-options - log-tcp-sequence # skriv allt på en rad ovan iptables -A EXTDROP -j DROP

Regelverk konf. INPUT, ex. 3/6 iptables -A INPUT -i lo -j ACCEPT # släpp in paket f. egen dator iptables -A INPUT -p tcp -j SCAN # kolla om scannerpaket iptables -A INPUT -i eth0 -j SPOOF # kolla eth0 paket om falska # Ta emot paket enligt nedan iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Logga/kasta ogltiga enligt ovan iptables -A INPUT -m state --state INVALID -j INVALDROP # skicka lokala paket till kedjan ONSITE-IN iptables -A INPUT -s 12.5.7.0/24 -d 12.5.7.15 -i eth0 -j ONSITE-IN iptables -A INPUT -s 12.5.8.0/24 -d 12.5.7.15 -i eth0 -j ONSITE-IN # skicka alla andra eth0 paket till kedjan EXT-IN iptables -A INPUT -i eth0 -j EXT-IN # kolla för konstiga ICMP paket iptables -A INPUT -p icmp -i eth0 -j ICMP # Logga (markera) resten så att den kastas av grundregeln iptables -A INPUT -j POLICYLOG

Regelverk konf. SPOOF, ex. 4/6 Här definierar vi kedjan SPOOF med regler mot falska IP Adresser. SPOOF används enbart mot falska paket som kommer från eth0 iptables -A SPOOF -s 12.5.7.15 -j SPOOFDROP #datorns egen ip-adress iptables -A SPOOF -s 10.0.0.0/8 -j SPOOFDROP #Klass A pr. adr. iptables -A SPOOF -s 172.16.0.0/12 -j SPOOFDROP #Klass B pr. adr. iptables -A SPOOF -s 192.168.0.0/16 -j SPOOFDROP #Klass C pr. adr. iptables -A SPOOF -s 224.0.0.0/4 -j SPOOFDROP #Multicast adr. iptables -A SPOOF -p! udp -d 224.0.0.0/4 -j SPOOFDROP #!udp mcast iptables -A SPOOF -s 240.0.0.0/5 -j SPOOFDROP #Klass E (res.) iptables -A SPOOF -s 127.0.0.0/8 -j SPOOFDROP #loopback iptables -A SPOOF -s 169.254.0.0/16 -j SPOOFDROP #Länk lokala nät iptables -A SPOOF -s 192.0.2.0/24 -j SPOOFDROP #TEST-NET iptables -A SPOOF -s 255.255.255.255/32 -j SPOOFDROP #Bcast mål/käl. iptables -A SPOOF -d 0.0.0.0/32 -j SPOOFDROP #Bcast käl./mål OBS! Om din IP Adress är på ett privat undernät, måste du modifiera reglerna därefter, annars får du inga paket! Tänkvärt så här nära Julen!

Regelverk konf. SCAN&ICMP ex. 5/6 Definition av SCAN som kontrollerar konstiga TCP flaggor. iptables -A SCAN -p tcp --tcp-flags ALL NONE -j SCANDROP iptables -A SCAN -p tcp --tcp-flags SYN,FIN SYN,FIN -j SCANDROP iptables -A SCAN -p tcp --tcp-flags SYN,RST SYN,RST -j SCANDROP iptables -A SCAN -p tcp --tcp-flags FIN,RST FIN,RST -j SCANDROP iptables -A SCAN -p tcp --tcp-flags ACK,FIN FIN -j SCANDROP iptables -A SCAN -p tcp --tcp-flags ACK,PSH PSH -j SCANDROP iptables -A SCAN -p tcp --tcp-flags ACK,URG URG -j SCANDROP Definiton av ICMP. Sorterar önskade paket och kastar resten. iptables -A ICMP --fragment -p icmp -j ICMPDROP iptables -A ICMP -p icmp --icmp-type source-quench -j ACCEPT iptables -A ICMP -p icmp --icmp-type parameter-problem -j ACCEPT iptables -A ICMP -p icmp --icmp-type destination-unreachable -j ACCEPT iptables -A ICMP -p icmp --icmp-type time-exceeded -j ACCEPT iptables -A ICMP -p icmp --icmp-type echo-request -j ACCEPT iptables -A ICMP -j ICMPDROP OBS! source-quench kan användas i en DoS attack, dessvärre används den fortfarande som flödeskontroll i vissa nät. Nej så bra!

Regelverk konf. ONSITE-IN & Definition av ONSITE-IN, paket från lokala nätet. Definiton av resten: EXT-IN ex. 6/6 # Tillåt alla HTTP (SYN) paket från lokala nätet. # Resten av trafiken hanteras av regeln ESTABLISHED. iptables -A ONSITE-IN -p tcp --dport 80 syn -m state --state NEW -j ACCEPT # Skriv allt på samma rad! iptables -A EXT-IN -p tcp --dport 22 -syn -m state --state NEW -j ACCEPT # Skriv allt på samma rad! iptables -A EXT-IN -p tcp --dport 113 -j REJECT --reject-with tcp-reset # Skriv allt på samma rad! iptables -A EXT-IN -p tcp -j EXTDROP iptables -A EXT-IN -p udp -j EXTDROP # Skriv allt på samma rad! REJECT på port 113 är till för att ident frågor avvisas snyggt. Även om standardregeln kastar återstående TCP och UDP paket gör jag detta uttryckligen så att dessa loggas som externa paket.

Flera regler OK, det är en säkerthetsrisk, men hur tillåter jag en FTP server? Det är enkelt genom att skapa en ny regel som tillåter port 21 (FTP kommando kanal). Den fungerar för aktiv FTP. Bara du skriver in dessa före EXTDROP regler i kedjan EXT-IN). iptables -A EXT-IN -p tcp --dport 21 -m state --state NEW --syn -j ACCEPT # Skriv allt på samma rad!

Diagnos felsökning Om du har en eller flera tillämpningar som inte fungerar när brandväggen är aktiv: Använd loggar skapade av Netfilter: # tail f /var/log/messages grep... Använd tcpdump (se man 8 tcpdump) Använd lsof -i för att se vilka processer har öpnna portar Kolla räkneverken för paket/byte så ser du om dina paket kastas # iptables -vnl Titta i tabellen för connection tracking. Du kanske har problem med paketens tillstånd? # cat /proc/net/ip_conntrack För ytterligare analys tar vi till nmap (som vanligt) och kollar vad knäckarna ser! Om du inte har nmap eller är ny användare, ladda ner senaste versionen och dokumentatinen hos: http://www.insecure.org/nmap

Om RPC Tillämpningar som använder RPC kräver specialåtgärder för att att fungera med ovan beskrivna brandväggen. NFS fungerar(?) på NFS klienterna, men inte fullständigt, eftersom rpc.statd inte kan ses utanför brandväggen. Om du absolut behöver RPC tjänster, får du lov att skriva ett skript som läser output från rpcinfo -p och genererar regler dynamiskt. Skriptet körs i slutet av boot processen.

Källor och referenser Ziegler, Robert L. Linux Firewalls, Second Edition. Indianapolis, Indiana: New Riders Publishing, 2002. ISBN: 0 7357 1099 6. Zwicky, Elizabeth D., et al. Building Internet Firewalls (2nd Edition). Sebastopol, CA: O Reilly & Associates, 2000. ISBN: 1 5659 2871 7. Otaliga howto dokument och Netfilters egen dokumentation på Internet: http://netfilter.org/documentation/index.html Värt att läsa: Networking concepts Howto Packet filtering Howto NAT Howto