Řešení 1:
Obecně:
Zobrazení a úprava konfigurace brány firewall vyžaduje oprávnění správce (root ) jako služby otvírání v omezeném rozsahu čísel portů. To znamená, že byste měli být buď přihlášeni jako root nebo alternativně použijte sudo pro spuštění příkazu jako root. Pokusím se takové příkazy označit nepovinným [sudo] .
Obsah:
- Na pořadí záleží nebo na rozdílu mezi
-Ia-A - Zobrazit aktuální konfiguraci brány firewall
- Interpretace výstupu
iptables -L -v -n - Poznej své prostředí
- Řetězce INPUT a FORWARD
- Moduly jádra
1. Na pořadí záleží nebo je rozdíl mezi -I a -A
Je třeba si zapamatovat, že pravidla brány firewall jsou kontrolována v pořadí, v jakém jsou uvedena. Jádro zastaví zpracování řetězce, když se spustí pravidlo, které povolí nebo zakáže paket nebo spojení.
Myslím, že nejčastější chyba pro začínající administrátory firewallu je, že postupují podle správných pokynů k otevření nového portu, jako je ten níže:
[sudo] iptables -A INPUT -i eth0 -p tcp --dport 8080 -j ACCEPT
a pak zjistíte, že to nebude platit.
Důvodem je to, že -A možnost přidá toto nové pravidlo, za všechna stávající pravidla a protože velmi často bylo posledním pravidlem ve stávajícím firewallu pravidlo, které blokuje veškerý provoz, který není výslovně povolen, což má za následek
...
7 2515K 327M REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
8 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080
Nebo ekvivalent v iptables-save:
...
iptables -A INPUT -j REJECT
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
a nové pravidlo otevírající TCP port 8080 nebude nikdy dosaženo. (jak dokazují čítače, které tvrdošíjně zůstávají na 0 paketech a nule bajtů).
Vložením pravidla s -I nové pravidlo by bylo první v řetězci a bude fungovat.
2. Zobrazit aktuální konfiguraci brány firewall
Moje doporučení pro správce brány firewall je podívat se na skutečnou konfiguraci linuxového jádra, než se snažit diagnostikovat problémy s bránou firewall pomocí uživatelsky přívětivých nástrojů. Často, jakmile pochopíte základní problémy, můžete je snadno vyřešit v záležitosti podporované těmito nástroji.
Příkaz [sudo] iptables -L -v -n je váš přítel (ačkoli někteří lidé mají rádi iptables-save lepší). Při diskusích o konfiguracích je často užitečné použít --line-numbers možnost i na číselné řady. Odkaz na pravidlo #X usnadňuje jejich diskusi.
Poznámka: Pravidla NAT jsou zahrnuta v iptables-save výstup, ale musí být uveden samostatně přidáním -t nat možnost, tj. [sudo] iptables -L -v -n -t nat --line-numbers .
Spuštění příkazu vícekrát a kontrola narůstajících čítačů může být užitečným nástrojem, jak zjistit, zda se nové pravidlo skutečně spustí.
[[email protected] ~]# iptables -L -v -n
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 784K 65M fail2ban-SSH tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
2 2789K 866M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
3 15 1384 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
4 44295 2346K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
5 40120 2370K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80
6 16409 688K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:443
7 2515K 327M REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT 25 packets, 1634 bytes)
num pkts bytes target prot opt in out source destination
Chain fail2ban-SSH (1 references)
num pkts bytes target prot opt in out source destination
1 0 0 REJECT all -- * * 117.239.37.150 0.0.0.0/0 reject-with icmp-port-unreachable
2 4 412 REJECT all -- * * 117.253.208.237 0.0.0.0/0 reject-with icmp-port-unreachable
Alternativně výstup iptables-save poskytuje skript, který dokáže obnovit výše uvedenou konfiguraci brány firewall:
[[email protected] ~]# iptables-save
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [441:59938]
:fail2ban-SSH - [0:0]
-A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A fail2ban-SSH -s 117.239.37.150/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-SSH -s 117.253.208.237/32 -j REJECT --reject-with icmp-port-unreachable
COMMIT
Je otázkou preferencí, čemu budete snáze rozumět.
3. Interpretace výstupu iptables -L -v -n
Zásady nastaví výchozí akci, kterou řetězec použije, když neodpovídá žádné explicitní pravidlo. V INPUT řetězec, který je nastaven na PŘIJÍMAT veškerý provoz.
První pravidlo v řetězci INPUT je hned zajímavé, posílá veškerý provoz (zdroj 0.0.0.0/0 a cíl 0.0.0.0/0) určený pro TCP port 22 (tcp dpt:22 ) výchozí port pro SSH na vlastní cíl (fail2ban-SSH ). Jak název napovídá, toto pravidlo je udržováno systémem fail2ban (bezpečnostní produkt, který mimo jiné prohledává systémové protokolové soubory kvůli možnému zneužití a blokuje IP adresu násilníka).
Toto pravidlo by bylo vytvořeno příkazovým řádkem iptables podobným iptables -I INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH nebo se nachází ve výstupu ofiptables-save jako -A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH . V dokumentaci často najdete kterýkoli z těchto zápisů.
Počítadla ukazují, že toto pravidlo odpovídá 784 000 paketům a 65 megabajtům dat.
Provoz, který odpovídá tomuto prvnímu pravidlu, je poté zpracován pomocí fail2ban-SSH řetězec, který je jako nestandardní řetězec uveden pod řetězcem OUTPUT.
Tento řetězec se skládá ze dvou pravidel, jedno pro každého zneužívatele (zdrojová IP adresa 117.253.221.166 nebo 58.218.211.166), který je blokován (s reject-with icm-port-unreachable ).
-A fail2ban-SSH -s 117.253.221.166/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-SSH -s 58.218.211.166/32 -j REJECT --reject-with icmp-port-unreachable
Pakety SSH, které nepocházejí z těchto blokovaných hostitelů, zatím nejsou ani povoleny, ani zakázány a nyní, když je vlastní řetězec dokončen, budou zkontrolovány podle druhého pravidla v řetězci INPUT.
Všechny pakety, které nebyly určeny pro port 22, prošly prvním pravidlem v řetězci INPUT a budou také vyhodnoceny v pravidle INPUT #2.
Pravidlo INPUT číslo 2 znamená, že se jedná o stavový firewall , která sleduje spojení. To má určité výhody, pouze pakety pro nová připojení je třeba kontrolovat podle úplného souboru pravidel, ale jakmile je to povoleno, další pakety patřící k navázanému nebo souvisejícímu připojení jsou přijímány bez další kontroly.
Vstupní pravidlo č. 2 odpovídá všem otevřeným a souvisejícím připojením a pakety vyhovující tomuto pravidlu nebudou muset být dále vyhodnocovány.
Poznámka: změny pravidel v konfiguraci stavového firewallu ovlivní pouze nová připojení, nikoli vytvořená připojení.
Naproti tomu jednoduchý paketový filtr testuje každý paket proti úplné sadě pravidel bez sledování stavu připojení. V takovém firewallu žádný stav budou použita klíčová slova.
Pravidlo INPUT #3 je docela nudné, veškerý provoz se připojuje ke zpětné smyčce (lo nebo 127.0.0.1) rozhraní je povoleno.
Pravidla INPUT 4, 5 a 6 se používají k otevření portů TCP 22, 80 a 443 (výchozí porty pro resp. SSH, HTTP a HTTPS) udělením přístupu k NOVÝM připojením (existující připojení jsou již povolena pravidlem INPUT 2).
V bezstavovém firewallu by se tato pravidla objevila bez atributů stavu:
4 44295 2346K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
5 40120 2370K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
6 16409 688K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
nebo
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
Poslední pravidlo INPUT, #7, je pravidlo, které blokuje veškerý provoz, kterému NEBYL udělen přístup v pravidlech INPUT 1-7. Docela běžná konvence:vše, co není dovoleno, je odepřeno. Teoreticky mohlo být toto pravidlo vynecháno nastavením výchozí POLICY na REJECT.
Vždy prozkoumejte celý řetězec.
4. Poznejte své prostředí
4.1 Nastavení v softwarové bráně firewall neovlivní nastavení zabezpečení udržovaná jinde v síti, tj. navzdory otevření síťové služby s iptables neupravené seznamy řízení přístupu na směrovačích nebo jiných bránách firewall ve vaší síti mohou stále blokovat provoz...
4.2 Když žádná služba neposlouchá, nebudete se moci připojit a dostanete chybu odmítnutí připojení, bez ohledu na nastavení brány firewall. Proto:
- Potvrďte, že služba naslouchá (na správném síťovém rozhraní/ip-adrese) a používá čísla portů, která očekáváte s
[sudo] netstat -plnutnebo alternativně použijtess -tnlp. - Pokud vaše služby ještě nemají být spuštěny, emulujte jednoduchý posluchač s například netcat:
[sudo] nc -l -p 123neboopenssl s_server -accept 1234 [options]pokud potřebujete posluchač TLS/SSL (zaškrtněteman s_serverpro možnosti). - Ověřte, že se můžete připojit ze samotného serveru, tj.
telnet <IP of Server> 123neboecho "Hello" | nc <IP of Server> 123nebo při testování zabezpečené služby TLS/SSLopenssl s_client -connect <IP of Server>:1234, než to zkusíte ze vzdáleného hostitele.
4.3 Pochopte protokoly používané vašimi službami. Služby, kterým dostatečně nerozumíte, nemůžete správně povolit/zakázat. Například:
- je použit TCP nebo UDP nebo obojí (jako u DNS)?
- Používá služba pevný výchozí port (například něco jako port TCP 80 pro webový server)?
- je alternativně zvoleno dynamické číslo portu, které se může lišit (tj. služby RPC, jako je klasický NFS, které se registrují u Portmap)?
- nechvalně známý FTP dokonce používá dva porty , pevné i dynamické číslo portu při konfiguraci pro použití pasivního režimu...
- popisy služby, portu a protokolu v
/etc/servicesnemusí nutně odpovídat skutečné službě pomocí portu.
4.4 Filtr paketů jádra není jediná věc, která může omezit připojení k síti:
- SELinux může také omezovat síťové služby.
getenforcepotvrdí, zda je spuštěn SELinux. - Přestože se TCP Wrappers stávají poněkud nejasnými, stále jsou mocným nástrojem pro prosazování zabezpečení sítě. Zkontrolujte pomocí
ldd /path/to/service |grep libwrapa/hosts.[allow|deny]kontrolní soubory.
5. INPUT nebo FORWARD Řetězy
Koncept řetězců je podrobněji vysvětlen zde, ale zkratka zní:
INPUT řetězec je místo, kde otevíráte a/nebo zavíráte síťové porty pro služby spuštěné lokálně na hostiteli, kde zadáváte příkazy iptables.
FORWARD řetězec je místo, kde aplikujete pravidla pro filtrování provozu, který je předáván jádrem do jiných systémů, skutečných systémů, ale také kontejnerů Docker a serverů virtuálních hostujících serverů, když váš počítač se systémem Linux funguje jako most, směrovač, hypervizor a/nebo provádí překlad síťových adres. a přesměrování portů.
Obvyklá mylná představa je, že protože kontejner dockeru nebo host KVM běží lokálně, pravidla filtrování, která se použijí, by měla být v řetězci INPUT, ale to obvykle není tento případ.
6. Moduly jádra
Protože paketový filtr běží v jádře Linuxu, může být také zkompilován jako dynamický modul, tedy více modulů. Většina distribucí obsahuje moduly netfilter a požadované moduly netfilter se načtou do jádra podle potřeby, ale u některých modulů bude muset správce firewallu ručně zajistit jejich načtení. Týká se to především modulů pro sledování připojení, jako je nf_conntrack_ftp který lze načíst pomocí insmod .
Moduly aktuálně načtené do běžícího jádra lze zobrazit pomocí lsmod .
Způsob, jak zajistit trvalé načítání modulů během restartování, závisí na distribuci Linuxu.
Řešení 2:
Iptables/Firewall "Úvod"
Firewall je v podstatě síťový filtr založený na zásadách. Linuxové firewally jsou postaveny na Netfilter; rámec pro zpracování síťových paketů jádra, který se skládá z několika modulů jádra provádějících specifické úkoly:
- Modul FILTER (ve výchozím nastavení je vždy načten) nám hlavně umožňuje PŘIJÍMAT nebo ODHAZOVAT IP pakety na základě určitých kritérií shody.
- Sada modulů NAT nám umožňuje provádět překlady síťových adres (SNAT, DNAT, MASQUERADE).
- Modul MANGLE nám umožňuje měnit určitá pole paketů IP (TOS, TTL).
Uživatelé konfigurují rámec Netfilter tak, aby vyhovoval jejich potřebám brány firewall, pomocí iptables z příkazového řádku. S iptables definujeme pravidla, která dávají jádru pokyn, co má dělat s IP pakety, když dorazí do, projdou nebo opustí náš linuxový box. Každý hlavní proces Netfilteru je v žargonu iptables reprezentován TABULKOU (FILTR, NAT, MANGLE). Mají několik specifických bodů na mapě toku síťových paketů, kde je volá jádro, aby vykonávaly své povinnosti. Některé specificky umístěné sekvence volání TABLE se obecně nazývají vestavěné ŘETĚZY přijímající názvy PREROUTING, INPUT, FORWARD, OUTPUT, a POSTROUTING. Je snadno zapamatovatelné, pokud spojíme TABULKU s „typem procesu“ a ŘETĚZ s „umístěním“ na mapě toku síťových paketů, kde jsou instance těchto procesů vyvolány.
Vzhledem k tomu, že IP paket je přijat na síťovém rozhraní nebo vytvořen lokálním procesem, dokud není nakonec doručen nebo vyřazen, bude modul Netfilter postupně testovat a aplikovat pravidla obsažená v mapě toku síťových paketů. Ke každému bloku označenému párem [email protected] může uživatel přidat jedno nebo více těchto po sobě jdoucích pravidel obsahujících kritéria pro shodu IP paketů a odpovídající postup. Existují akce (např. ACCEPT, DROP atd.), které může provádět více než jedna TABLE, a další akce (např. SNAT, DNAT atd.), které jsou specifické pro TABLE.
tj. když IP paket přijde ze síťového rozhraní, je nejprve zpracován řetězcem PREROUTING, který vyvolá uživatelsky definovaná pravidla tabulky MANGLE, pokud existují. Pokud neexistují pravidla, která by odpovídala aktuálnímu paketu, použije se odpovídající výchozí postup nebo „zásady“ [email protected]. V tomto okamžiku, pokud nebyl paket zahozen, proces bude nyní pokračovat vyvoláním pravidel tabulky NAT v řetězci PREROUTING (viz mapa) atd. Aby se usnadnilo uspořádání pravidel, mohou uživatelé také vytvářet své vlastní řetězce a „skákejte“ do nich z různých bodů mapy, jak chtějí.
Zatímco vestavěné řetězce mohou mít uživatelsky definované zásady buď ACCEPT nebo DROP paketů, uživatelsky definované řetězce mají vždy neměnnou výchozí zásadu RETURN volajícímu, aby mohl proces pokračovat.
Příkazy Iptables
Hlavní příkazy iptables naplní mapu toku síťových paketů požadovanými pravidly zpracování.
Obecné pravidlo iptables lze zapsat jako:
# iptables <table> <Add/Insert/Delete> <CHAIN> <PKT_MATCHING_CRITERIA> <ACTION>
Dalo by se to číst takto:
Netfilter (kernel module) please <Add/Insert/Delete> this rule for <table> at <CHAIN> where packets matching <PKT_MATCHING_CRITERIA> have to be <ACTION>ed
<table>
-t filter (the filter table is assumed when omitted)
-t nat
-t mangle
<Add/Insert/Delete>
-A (append rule at the end of the chain list)
-I (insert rule at the begining of the chain list)
-D (Delete rule)
<CHAIN>
PREROUTING
INPUT
FORWARD
OUTPUT
POSTROUTING
USER_DEFINED_CHAIN
<PKT_MATCHING_CRITERIA>
ISO Level-2 matching:
-i [!] <if_name> or --in-interface [!] <if_name>
(OUTPUT and POSTROUTING chains cannot match on input interfaces)
-o [!] <if_name> or --out-interface [!] <if_name>
(INPUT and PREROUTING chains cannot match on output interfaces)
-mac-source [!] <xx-xx-xx-xx-xx-xx>
(OUTPUT and POSTROUTING chains cannot match on input interfaces)
ISO Level-3 matching:
-s [!] <src_ip> or --src [!] <src_ip> or --source [!] <src_ip>
-d [!] <dst_ip> or --src [!] <dst_ip> or --destination [!] <dst_ip>
ISO Level-4 matching:
-p [!] <prot_name> or --protocol [!] <prot_name> (udp|tcp|icmp)
Also available when ICMP protocol is defined
--icmp-type [!] <icmp_type>
Also available when UDP protocol is defined
--source-port [!] <udp_src_port> or --sport [!] <udp_src_port>
--destination-port [!] <udp_dst_port> or --dport [!] <udp_dst_port>
Also available when TCP protocol is defined
--source-port [!] <tcp_src_port> or --sport [!] <tcp_src_port>
--destination-port [!] <tcp_dst_port> or --dport [!] <tcp_dst_port>
--tcp-flags [!] <tcp_flags> (SYN|ACK|FIN|RST|URG|PSH|ALL|NONE)
--syn
--tcp-option [!] <tcp_option#>
--state [!] <state>
-m <match> [options]
note: [!] = negation operator
<ACTION> (also called TARGET)
-j ACCEPT (process continues with rules of the next table in map)
-j DROP (discard current packet)
-j REJECT (discard current packet with ICMP notification)
option:
--reject-with <reject_type>
-j USER_DEFINED_CHAIN (start traversing USER_DEFINED_CHAIN rules)
-j RETURN (return from USER_DEFINED_CHAIN)
-j LOG (log to syslog, then process next rule in table)
options:
--log-level <level>
--log-prefix <prefix>
--log-tcp-sequence
--log-tcp-options
--log-ip-options
--log-uid
nat table specific
-j SNAT (rewrite the source IP address of the packet)
option:
--to <ip_address>
-j SAME (idem SNAT; used when more than one source address)
options:
--nodst
--to <a1-a2>
-j MASQUERADE (idem SNAT; used when the replace IP is dynamic)
-j DNAT (rewrite the destination IP address of the packet)
option:
--to <ip_address>
-j REDIRECT (rewrite dst IP to 127.0.0.1, PREROUTING and OUTPUT only)
option:
–-to-port <port#>
mangle table specific
-j ROUTE (explicitly route packets, valid at PREROUTING)
options:
--iface <iface_name>
--ifindex <iface_idx>
-j MARK (set Netfilter mark values)
options:
--set-mark <value>
--and-mark <value>
--or-mark <value>
-j TOS (set the IP header Type of Service field)
option:
--set-tos <value>
-j DSCP (set the IP header Differentiated Services Field)
options:
--set-dscp <value>
--set-dscp-class <class>
-j TTL (set the IP header Time To Live field)
options:
--ttl-set <value>
--ttl-dec <value>
--ttl-inc <value>
Pomocné příkazy iptables dokončují nastavení scénáře výchozí podmínky, pravidla pro výpis, pravidla pro vyplachování atd.
#iptables -t <table> -L
(Lists the <table> rules in all chains)
#iptables -t <table> -L <CHAIN>
(Lists the <table> rules in <CHAIN>)
#iptables -t <table> -N <CHAIN>
(Creates a user-defined <CHAIN> for holding <table> rules)
#iptables -t <table> -E <CHAIN> <NEWCHAIN>
(Renames <CHAIN> that holds <table> rules to <NEWCHAIN>)
#iptables -t <table> -X
(Deletes all user-defined chains created for holding <table> rules)
#iptables -t <table> -X <CHAIN>
(Deletes user-defined <CHAIN> created for holding <table> rules)
#iptables -t <table> -P <CHAIN> <ACTION> where <ACTION> = ACCEPT|DROP
(Sets the default policy of <table> rules at <CHAIN> to <ACTION>)
#iptables -t <table> -F
(Flushes (deletes) all <table> rules in all chains)
#iptables -t <table> -F <CHAIN>
(Flushes (deletes) all <table> rules in <CHAIN>)
#iptables -t <table> -R <CHAIN> <INDEX> <NEWRULE>
(Replaces <table> rule at position <INDEX> in <CHAIN> with <NEWRULE>
Iptables načítá naše příkazy do enginu Netfilter za běhu, Netfilter okamžitě vynucuje načtená pravidla a nastavení, ale nejsou trvalé. Po restartu budou všechna dříve načtená pravidla a nastavení Netfilter ztracena. Z tohoto důvodu existují nástroje iptables, které umožňují uložit aktuálně aktivní sadu pravidel do souboru a později ji znovu načíst.
#iptables-save > fileName
(Save the currently active Netfilter ruleset to fileName)
#iptables-restore < fileName
(Restore Netfilter ruleset to the one saved in fileName)
Přehled Iptables
Netfilter je extrémně flexibilní a výkonný framework, ale stojí za to zaplatit; Iptables je komplexní. Z uživatelského hlediska některé pojmy jako TABULKA, ŘETĚZ, CÍL ve skutečnosti příliš neodpovídají konceptu, který představují, a zpočátku nedávají příliš smysl. Téma je dlouhé, zdá se, že příkazy mají nekonečný seznam parametrů. Aby toho nebylo málo, neexistuje jediná kniha, která by Iptables skutečně zvládla. Většinou spadají do dvou kategorií:„receptář“ nebo „manuál“. Myslím, že tento úvod vám poskytne snímek prostředí Netfilter/Iptables plus nezbytnou dávku předem připravených věcí z manuálové stránky. Pokud jste v iptables noví, po přečtení těchto odstavců budete připraveni číst příklady iptables. S trochou praxe brzy zjistíte, že si píšete svá vlastní pravidla.
Brány firewall
Brána firewall je navržena především tak, aby dynamicky povolovala nebo zakazovala síťový provoz na základě sady pravidel. V tomto bodě je snadné pochopit, proč je Linux Netfilter/Iptables framework ideální pro konstrukci firewallu. Při pohledu na mapu toku síťových paketů najdeme dvě zvláště zajímavá místa v tabulce FILTER v řetězcích INPUT a FORWARD; Můžeme se zde rozhodnout pro zdrojovou IP adresu, IP protokol (UDP/TCP), cílový port (80, 21, 443 atd.), atd., zda přijmeme, ODMÍTNEME nebo prostě ZAhodíme konkrétní IP paket. To dělá firewall 80% času, když chrání webový server před neoprávněnými síťovými požadavky. Zbývajících 20 % času je manipulace (NAT, MANGLE) síťových paketů.
Scénáře brány firewall
Existují stovky různých rozvržení firewallů, které řeší různé potřeby, ale 3 z nich lze považovat za nejtypičtější scénáře firewallu.
- Jednoduchý webový server s jedním nebo více rozhraními připojenými k internetu. Zásady zahrnují základní pravidla pro povolení omezeného příchozího přístupu, neomezeného odchozího přístupu a pravidla proti falšování. Přesměrování IP je vypnuté.
- Tento firewall se připojuje k internetu a do chráněné vnitřní oblasti. Zásady zahrnují základní pravidla pro povolení omezeného příchozího přístupu, neomezeného odchozího přístupu a pravidla proti falšování. Protože chráněná oblast používá privátní IP adresy, je potřeba zdrojový NAT. Přesměrování IP je zapnuto.
- Tento firewall se připojuje k internetu, vnitřní chráněné a demilitarizované oblasti. Zásady zahrnují základní pravidla pro povolení omezeného příchozího přístupu, neomezeného odchozího přístupu a pravidla proti falšování. Protože chráněné oblasti a oblasti DMZ používají soukromé IP adresy, potřebují zdrojový a cílový NAT. Přesměrování IP je zapnuto.
Napsal jsem to pro:http://www.vercot.com/~jeoss/howto/JeossEasyFirewall.html
Řešení 3:
Běžné problémy s různými protokoly
DNS: DNS standardně používá port 53 UDP, ale zprávy, které se nevejdou do jednoho datagramu UDP, budou místo toho přenášeny pomocí TCP (typicky zónové přenosy a podobně), což vyžaduje otevření portu 53 TCP také při spuštění jmenného serveru.
E-mail: Mnoho spotřebitelských ISP blokuje provoz SMTP (nebo alespoň výchozí port TCP 25), což znemožňuje přímé přijímání nebo odesílání e-mailů a jejich zákazníci jsou nuceni používat přenos SMTP poskytovatele internetových služeb pro všechny odchozí e-maily a někdy také pro příchozí e-maily. §1.1.
FTP: FTP je zvláštní protokol v tom ohledu, že dva se používají připojení. První je kontrolní spojení, na to bude standardně naslouchat FTP server na TCP portu 21. Kontrolní spojení se používá pro autentizaci a vydávání příkazů. Vlastní přenosy souborů a věci, jako je výstup seznamu adresářů, procházejí druhým připojením TCP, připojením DATA . V aktivním FTP by bylo DATA připojení iniciováno z FTP serveru z TCP portu 20 a připojení k FTP klientovi. Aktivní FTP nefunguje příliš dobře s uživateli za firewally a bránami NAT, takže se většinou nepoužívá. Většina FTP serverů místo toho podporují pasivní FTP. S pasivním FTP otevře FTP server posluchače pro DATA připojení na druhém portu, ke kterému se může FTP klient připojit. Problém brány firewall je v tom, že DATA port může být jakýkoli dostupný neprivilegovaný port mezi 1024-65536.
V bezstavové bráně firewall, která se obvykle řeší omezením počtu pasivních portů, které může FTP server přiřadit, a poté explicitním otevřením těchto portů. tj.
iptables -A INPUT -p tcp --match multiport --dports 21000:21050 -j ACCEPT
Ve stavovém firewallu nemusíte explicitně otevírat DATA port, pomocný modul netfilter rozpozná dynamický port, který je přiřazen, a dynamicky tento port otevře pro správného klienta označením DATA připojení jako RELATED poté bude odpovídat obecnému pravidlu:
iptables -I INPUT -p tcp -m state ESTABLISHED,RELATED -j ACCEPT
To vyžaduje správný modul jádra se načte, v případě FTP ručně spuštěním například insmod nf_conntrack_ftp , takže trvalá závisí na restartu závisí na distribuci.
Poznámka: Modul sledování připojení FTP selže, když je FTP používáno s SSL, protože řídicí připojení bude šifrováno a nf_conntrack_ftp již nebude moci číst odpověď PASV.
NFS a podobné služby RPC: Problém se službami RPC je, že podle návrhu nepoužívají konkrétní pevný port. Mohou si náhodně vybrat libovolný dostupný port, který pak bude registrován u démona RPC Portmap. Klient, který se pokouší připojit, zadá dotaz na démona Portmap a poté se připojí přímo ke správnému portu. To vyřešilo problém s vyčerpáním rezervovaných portů...
Z pohledu firewallu je třeba otevřít TCP/UDP port 111 a aktuální port, který služba RPC aktuálně používá. Problém otevření takového náhodného portu ve firewallu se obvykle řeší omezením služby RPC, jako je NFS. k použití předem definovaného pevného portu.