Soluzione 1:
In generale:
La visualizzazione e la modifica della configurazione del firewall richiede privilegi di amministratore (root ) così come i servizi di apertura nell'intervallo limitato di numeri di porta. Ciò significa che dovresti essere loggato come root o in alternativa usa sudo per eseguire il comando come root. Proverò a contrassegnare tali comandi con l'opzionale [sudo] .
Contenuto:
- L'ordine è importante o la differenza tra
-Ie-A - Visualizza la configurazione attuale del firewall
- Interpretazione dell'output di
iptables -L -v -n - Conosci il tuo ambiente
- Le catene INPUT e FORWARD
- Moduli del kernel
1. L'ordine è importante o la differenza tra -I e -A
La cosa da ricordare è che le regole del firewall vengono verificate nell'ordine in cui sono elencate. Il kernel interromperà l'elaborazione della catena quando viene attivata una regola che consentirà o meno un pacchetto o una connessione.
Penso l'errore più comune per gli amministratori di firewall inesperti è che seguono le istruzioni corrette per aprire una nuova porta, come quella qui sotto:
[sudo] iptables -A INPUT -i eth0 -p tcp --dport 8080 -j ACCEPT
e poi scopri che non avrà effetto.
Il motivo è che -A L'opzione aggiunge quella nuova regola, dopo tutte le regole esistenti e poiché molto spesso la regola finale nel firewall esistente era quella che blocca tutto il traffico che non è esplicitamente consentito, con il risultato di
...
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
O equivalente in iptables-save:
...
iptables -A INPUT -j REJECT
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
e la nuova regola che apre la porta TCP 8080 non sarà mai raggiunta. (come evidenziato dai contatori che rimangono ostinatamente a 0 pacchetti e zero byte).
Inserendo la regola con -I la nuova regola sarebbe stata la prima della catena e funzionerà.
2. Visualizza la configurazione attuale del firewall
La mia raccomandazione per l'amministratore del firewall è di esaminare la configurazione effettiva in cui è in esecuzione il kernel Linux, piuttosto che provare a diagnosticare i problemi del firewall con strumenti intuitivi. Spesso, una volta compresi i problemi sottostanti, è possibile risolverli facilmente in una questione supportata da tali strumenti.
Il comando [sudo] iptables -L -v -n è tuo amico (anche se ad alcune persone piace iptables-save meglio). Spesso quando si discute di configurazioni è utile usare il --line-numbers opzione anche alle linee numeriche. Fare riferimento alla regola #X rende la loro discussione un po' più facile.
Nota: Le regole NAT sono incluse nel iptables-save output ma devono essere elencati separatamente aggiungendo -t nat opzione, ad esempio [sudo] iptables -L -v -n -t nat --line-numbers .
Eseguire il comando più volte e verificare la presenza di contatori incrementali può essere uno strumento utile per vedere se una nuova regola viene effettivamente attivata.
[[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
In alternativa, l'output di iptables-save fornisce uno script che può rigenerare la precedente configurazione del 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
È una questione di preferenza ciò che troverai più facile da capire.
3. Interpretazione dell'output di iptables -L -v -n
La Norma imposta l'azione predefinita che la catena utilizza quando nessuna regola esplicita corrisponde. Nel INPUT catena impostata per ACCETTARE tutto il traffico.
La prima regola nella catena INPUT è subito interessante, invia tutto il traffico (sorgente 0.0.0.0/0 e destinazione 0.0.0.0/0) destinato alla porta TCP 22 (tcp dpt:22 ) la porta predefinita per SSH verso una destinazione personalizzata (fail2ban-SSH ).Come indica il nome, questa regola è gestita da fail2ban (un prodotto di sicurezza che, tra le altre cose, scansiona i file di registro di sistema alla ricerca di possibili abusi e blocca l'indirizzo IP dell'aggressore).
Quella regola sarebbe stata creata da una riga di comando iptables simile a iptables -I INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH o si trova nell'output di iptables-save come -A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH . Spesso troverai una di queste notazioni nella documentazione.
I contatori indicano che questa regola ha soddisfatto 784.000 pacchetti e 65 Megabyte di dati.
Il traffico che corrisponde a questa prima regola viene quindi elaborato dal fail2ban-SSH catena che, come catena non standard, viene elencata sotto la catena OUTPUT.
Quella catena è composta da due regole, una per ogni aggressore (indirizzo IP di origine 117.253.221.166 o 58.218.211.166) che viene bloccato (con un 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
I pacchetti SSH che non provengono da quegli host bloccati non sono ancora né consentiti né vietati e, ora che la catena personalizzata è stata completata, verranno verificati rispetto alla seconda regola nella catena INPUT.
Tutti i pacchetti che non erano destinati alla porta 22 hanno superato la prima regola nella catena INPUT e verranno valutati anche nella regola INPUT n. 2.
La regola INPUT numero 2 significa che si tratta di un firewall statefull , che tiene traccia delle connessioni. Ciò presenta alcuni vantaggi, solo i pacchetti per le nuove connessioni devono essere verificati rispetto all'intero set di regole, ma una volta consentiti, i pacchetti aggiuntivi appartenenti a una connessione stabilita o correlata vengono accettati senza ulteriori controlli.
La regola di input n. 2 corrisponde a tutte le connessioni aperte e correlate e i pacchetti che corrispondono a tale regola non dovranno essere valutati ulteriormente.
Nota: le modifiche alle regole nella configurazione di un firewall con stato influiranno solo sulle nuove connessioni, non sulle connessioni stabilite.
Al contrario, un semplice filtro di pacchetti verifica ogni pacchetto rispetto all'intero set di regole, senza tenere traccia dello stato della connessione. In un tale firewall nessuno stato verrebbero utilizzate parole chiave.
La regola INPUT n. 3 è piuttosto noiosa, tutto il traffico si connette al loopback (lo o 127.0.0.1) è consentita.
Le regole INPUT 4, 5 e 6 vengono utilizzate per aprire le porte TCP 22, 80 e 443 (le porte predefinite per rispettivamente SSH, HTTP e HTTPS) concedendo l'accesso a NUOVE connessioni (le connessioni esistenti sono già consentite dalla regola INPUT 2).
In un firewall senza stato queste regole apparirebbero senza gli attributi di stato:
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
o
-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
La regola INPUT finale, #7 è una regola che blocca tutto il traffico a cui NON è stato concesso l'accesso nelle regole INPUT 1-7. Una convenzione abbastanza comune:tutto ciò che non è permesso è negato. In teoria questa regola avrebbe potuto essere omessa impostando il POLICY predefinito su REJECT.
Esamina sempre l'intera catena.
4. Conosci il tuo ambiente
4.1 . Le impostazioni in un firewall software non influiranno sulle impostazioni di sicurezza mantenute altrove nella rete, ad es. nonostante l'apertura di un servizio di rete con iptables le liste di controllo degli accessi non modificate sui router o altri firewall nella tua rete potrebbero ancora bloccare il traffico...
4.2 . Quando nessun servizio è in ascolto, non sarai in grado di connetterti e riceverai un errore di connessione rifiutata, indipendentemente dalle impostazioni del firewall. Pertanto:
- Conferma che un servizio è in ascolto (sull'interfaccia di rete/indirizzo IP corretto) e utilizza i numeri di porta previsti con
[sudo] netstat -plnuto in alternativa usass -tnlp. - Se i tuoi servizi non dovrebbero ancora essere in esecuzione, emula un semplice listener con ad esempio netcat:
[sudo] nc -l -p 123oopenssl s_server -accept 1234 [options]se hai bisogno di un listener TLS/SSL (selezionaman s_serverper le opzioni). - Verifica di poterti connettere dal server stesso, ad esempio
telnet <IP of Server> 123oecho "Hello" | nc <IP of Server> 123o durante il test del servizio protetto TLS/SSLopenssl s_client -connect <IP of Server>:1234, prima di provare lo stesso da un host remoto.
4.3 . Comprendi i protocolli utilizzati dai tuoi servizi. Non puoi abilitare/disabilitare correttamente i servizi che non comprendi a sufficienza. Ad esempio:
- viene utilizzato TCP o UDP o entrambi (come con DNS)?
- il servizio utilizza una porta predefinita fissa (ad esempio qualcosa come la porta TCP 80 per un server web)?
- in alternativa viene scelto un numero di porta dinamico che può variare (ad es. servizi RPC come NFS classico che si registrano con Portmap)? Il
- famigerato FTP utilizza anche due porte , sia un numero di porta fisso che dinamico quando configurato per utilizzare la modalità passiva...
- le descrizioni del servizio, della porta e del protocollo in
/etc/servicesnon corrispondono necessariamente al servizio effettivo che utilizza una porta.
4.4 . Il filtro dei pacchetti del kernel non è l'unica cosa che può limitare la connettività di rete:
- SELinux potrebbe anche limitare i servizi di rete.
getenforceconfermerà se SELinux è in esecuzione. - Anche se stanno diventando un po' oscuri, i wrapper TCP sono ancora un potente strumento per rafforzare la sicurezza della rete. Controlla con
ldd /path/to/service |grep libwrape il/hosts.[allow|deny]file di controllo.
5. INPUT o FORWARD Catene
Il concetto di catene è spiegato in modo più approfondito qui, ma il punto è:
Il INPUT chain è il punto in cui apri e/o chiudi le porte di rete per i servizi in esecuzione localmente, sull'host in cui esegui i comandi iptables.
Il FORWARD chain è dove applichi le regole per filtrare il traffico che viene inoltrato dal kernel ad altri sistemi, sistemi reali ma anche contenitori Docker e server Virtual guest Server quando la tua macchina Linux funge da bridge, router, hypervisor e/o esegue la traduzione dell'indirizzo di rete e il port forwarding.
Un malinteso comune è che, poiché un contenitore docker o un guest KVM viene eseguito localmente, le regole di filtro applicabili dovrebbero trovarsi nella catena INPUT, ma di solito non è così.
6. Moduli del kernel
Poiché il filtro dei pacchetti viene eseguito all'interno del kernel Linux, può anche essere compilato come modulo dinamico, in realtà più moduli. La maggior parte delle distribuzioni include netfilter come moduli e i moduli netfilter richiesti verranno caricati nel kernel secondo necessità, ma per alcuni moduli un amministratore del firewall dovrà assicurarsi manualmente che vengano caricati. Ciò riguarda principalmente i moduli di monitoraggio della connessione, come nf_conntrack_ftp che può essere caricato con insmod .
I moduli attualmente caricati nel kernel in esecuzione possono essere visualizzati con lsmod .
Il metodo per garantire che i moduli vengano caricati in modo permanente tra i riavvii dipende dalla distribuzione Linux.
Soluzione 2:
"Introduzione" a Iptables/Firewall
Un firewall è fondamentalmente un filtro di rete basato su criteri. I firewall Linux sono costruiti attorno a Netfilter; il framework di elaborazione dei pacchetti di rete del kernel che è costituito da diversi moduli del kernel che eseguono compiti specifici:
- Il modulo FILTER (sempre caricato per impostazione predefinita) ci consente principalmente di ACCEPT o DROP pacchetti IP in base a determinati criteri di corrispondenza.
- Il set di moduli NAT ci consente di eseguire traduzioni degli indirizzi di rete (SNAT, DNAT, MASQUERADE).
- Il modulo MANGLE ci consente di modificare alcuni campi del pacchetto IP (TOS, TTL).
Gli utenti configurano il framework Netfilter per soddisfare le proprie esigenze di firewall utilizzando iptables dalla riga di comando. Con iptables definiamo regole che istruiscono il kernel su cosa fare con i pacchetti IP quando arrivano, attraversano o escono dalla nostra macchina Linux. Ogni processo principale di Netfilter è rappresentato da una TABELLA (FILTER, NAT, MANGLE) nel gergo di iptables. Hanno diversi punti di aggancio specifici sulla mappa del flusso dei pacchetti di rete in cui vengono richiamati dal kernel per svolgere i loro compiti. Alcune sequenze di chiamate TABLE localizzate in modo specifico sono genericamente chiamate CATENE incorporate che ricevono i nomi di PREROUTING, INPUT, FORWARD, OUTPUT, e POSTROUTING. È facile da ricordare se associamo una TABELLA a un "tipo di processo" e una CATENA alla "posizione" sulla mappa del flusso dei pacchetti di rete in cui vengono invocate le istanze di quei processi.
Poiché un pacchetto IP viene ricevuto su un'interfaccia di rete, o creato da un processo locale, fino a quando non viene finalmente consegnato o scartato, il motore Netfilter testerà e applicherà in sequenza le regole contenute lungo la mappa del flusso dei pacchetti di rete. Ad ogni blocco identificato da una coppia [email protected] l'utente può aggiungere una o più di queste regole consecutive contenenti un criterio di corrispondenza del pacchetto IP e una linea di condotta corrispondente. Ci sono azioni (es. ACCEPT, DROP, ecc.) che possono essere eseguite da più di una TABELLA e altre azioni (es. SNAT, DNAT, ecc.) che sono specifiche della TABELLA.
cioè quando un pacchetto IP arriva da un'interfaccia di rete viene prima elaborato dalla catena PREROUTING richiamando le eventuali regole definite dall'utente della tabella MANGLE. Se non ci sono regole che corrispondono al pacchetto corrente, si applica la linea di condotta predefinita o "policy" corrispondente [email protected]. A questo punto se il pacchetto non è stato droppato il processo continuerà ora invocando le regole della tabella NAT alla catena PREROUTING (vedi la mappa) e così via. Per facilitare il layout delle regole, gli utenti possono anche creare le proprie catene personalizzate e "saltarci" dentro da diversi punti della mappa come desiderano.
Mentre le catene integrate possono avere politiche definite dall'utente di pacchetti ACCEPT o DROP, le catene definite dall'utente hanno sempre una politica predefinita immutabile di RITORNO al chiamante per continuare il processo.
Comandi di Iptables
I comandi principali di iptables popolano la mappa del flusso di pacchetti di rete con le regole di elaborazione richieste.
La regola generica di iptables può essere scritta come:
# iptables <table> <Add/Insert/Delete> <CHAIN> <PKT_MATCHING_CRITERIA> <ACTION>
Potrebbe essere letto come:
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>
I comandi ausiliari di iptables completano lo scenario impostando condizioni predefinite, regole di elenco, regole di svuotamento, ecc.
#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 carica i nostri comandi nel motore Netfilter in fase di esecuzione, Netfilter applica immediatamente le regole e le impostazioni caricate ma non sono persistenti. Dopo il riavvio, tutte le regole e le impostazioni di Netfilter precedentemente caricate andranno perse. Per questo motivo esistono delle utility iptables che permettono di salvare in un file il set di regole attualmente attivo e di ricaricarlo successivamente.
#iptables-save > fileName
(Save the currently active Netfilter ruleset to fileName)
#iptables-restore < fileName
(Restore Netfilter ruleset to the one saved in fileName)
Riepilogo di Iptables
Netfilter è un framework estremamente flessibile e potente ma c'è un prezzo da pagare per questo; Iptables è complesso. Dal punto di vista dell'utente certi termini come TABLE, CHAIN, TARGET non corrispondono molto bene al concetto che rappresentano e all'inizio non hanno molto senso. L'argomento è lungo, i comandi sembrano avere una lista infinita di parametri. A peggiorare le cose non c'è un solo libro che padroneggi davvero Iptables. Rientrano principalmente in due categorie:"libro di ricette" o "libro di manpage". Penso che questa introduzione ti fornisca un'istantanea del panorama di Netfilter/Iptables più la dose necessaria di roba di manpage pre-digerita. Se sei nuovo in iptables, dopo aver letto questi paragrafi un paio di volte sarai pronto per leggere esempi di iptables. Con un po' di pratica ti ritroverai presto a scrivere le tue regole.
Firewall
Un firewall è progettato principalmente per consentire o negare dinamicamente il traffico di rete in base a un insieme di regole. A questo punto è facile capire perché il framework Linux Netfilter/Iptables è perfetto per la costruzione di firewall. Osservando la mappa del flusso dei pacchetti di rete troviamo due punti particolarmente interessanti sulla tabella FILTER alle catene INPUT e FORWARD; Possiamo decidere lì l'indirizzo IP di origine, il protocollo IP (UDP/TCP), la porta di destinazione (80, 21, 443, ecc.), ecc., se ACCETTIAMO, RIFIUTIAMO o semplicemente ELIMINIAMO un particolare pacchetto IP. Questo è ciò che fa un firewall l'80% delle volte quando, ad esempio, protegge un server Web da richieste di rete non autorizzate. L'altro 20% del tempo manipola i pacchetti di rete (NAT, MANGLE).
Scenari di firewall
Esistono centinaia di diversi layout di firewall che rispondono a esigenze diverse, ma 3 di essi possono essere considerati gli scenari di firewall più tipici.
- Semplice web server con una o più interfacce connesse a Internet. La politica include regole di base per consentire l'accesso limitato in entrata, l'accesso illimitato in uscita e le regole anti-spoofing. L'inoltro IP è disattivato.
- Questo firewall si connette a Internet ea un'area interna protetta. La politica include regole di base per consentire l'accesso limitato in entrata, l'accesso illimitato in uscita e le regole anti-spoofing. Poiché l'area protetta utilizza indirizzi IP privati, è necessario il NAT di origine. L'inoltro IP è attivo.
- Questo firewall si connette a Internet, area interna protetta e demilitarizzata. La politica include regole di base per consentire l'accesso limitato in entrata, l'accesso illimitato in uscita e regole anti-spoofing. Poiché le aree protette e DMZ utilizzano indirizzi IP privati, necessitano di NAT di origine e destinazione. L'inoltro IP è attivo.
Ho scritto questo per:http://www.vercot.com/~jeoss/howto/JeossEasyFirewall.html
Soluzione 3:
Problemi comuni con protocolli diversi
DNS: Il DNS utilizza la porta 53 UDP per impostazione predefinita, ma i messaggi che non rientrano in un singolo datagramma UDP verranno invece trasmessi utilizzando TCP (tipicamente trasferimenti di zona e simili) che richiedono l'apertura anche della porta 53 TCP quando si esegue un server dei nomi.
Email: Molti ISP consumer bloccano il traffico SMTP (o almeno la porta predefinita TCP 25), rendendo impossibile la ricezione o l'invio diretto di e-mail e i loro clienti sono costretti a utilizzare il relay SMTP dell'ISP per tutte le e-mail in uscita e talvolta anche per quelle in arrivo.Si riferisce a §1.1.
FTP: FTP è un protocollo strano in quanto due vengono utilizzati i collegamenti. La prima è la connessione di controllo, per impostazione predefinita un server FTP ascolterà sulla porta TCP 21. La connessione di controllo viene utilizzata per l'autenticazione e l'emissione di comandi. I trasferimenti di file effettivi e cose come l'output di un elenco di directory passano attraverso una seconda connessione TCP, la connessione DATI . In FTP attivo quella connessione DATI verrebbe avviata dal server FTP dalla porta TCP 20 e si connetterebbe al client FTP. L'FTP attivo non funziona molto bene con gli utenti dietro firewall e gateway NAT, quindi è per lo più caduto in disuso. La maggior parte dei server FTP supporta invece l'FTP passivo. Con l'FTP passivo il server FTP apre un listener per la connessione DATI su una seconda porta, alla quale il client FTP può quindi connettersi. Il problema per un firewall è che la porta DATI può essere qualsiasi porta non privilegiata disponibile tra 1024-65536.
In un firewall senza stato che viene in genere risolto limitando il numero di porte passive che il server FTP può assegnare e quindi aprendo esplicitamente tali porte. cioè
iptables -A INPUT -p tcp --match multiport --dports 21000:21050 -j ACCEPT
In un firewall con stato non è necessario aprire esplicitamente la porta DATI, il modulo helper netfilter riconoscerà la porta dinamica che viene assegnata e aprirà dinamicamente quella porta per il client corretto contrassegnando la connessione DATI come RELATED dopodiché corrisponderà alla regola generica:
iptables -I INPUT -p tcp -m state ESTABLISHED,RELATED -j ACCEPT
Ciò richiede che il modulo del kernel corretto viene caricato, nel caso FTP manualmente eseguendo ad esempio insmod nf_conntrack_ftp , fare in modo che la dipendenza persistente al riavvio dipenda dalla distribuzione.
Nota: Il modulo di monitoraggio della connessione FTP fallirà quando FTP viene utilizzato con SSL, poiché la connessione di controllo verrà crittografata e nf_conntrack_ftp non sarà più in grado di leggere la risposta PASV.
NFS e simili servizi RPC: Il problema con i servizi RPC è che per progettazione non utilizzano una porta fissa specifica. Possono scegliere qualsiasi porta disponibile a caso, che verrà quindi registrata con il demone RPC Portmap. Un client che tenta di connettersi interrogherà il demone Portmap e quindi si connetterà direttamente alla porta corretta. Ciò ha risolto il problema dell'esaurimento delle porte riservate...
Dal punto di vista del firewall, è necessario aprire la porta TCP/UDP 111 e la porta effettiva attualmente utilizzata dal servizio RPC. Il problema dell'apertura di una tale porta casuale in un firewall viene in genere risolto limitando il servizio RPC, ad esempio NFS server, per utilizzare una porta fissa predefinita.