Skip to content

Debug di iptables e insidie comuni del firewall?

È essenziale comprendere bene il codice prima di utilizzarlo nel tuo progetto, se hai qualcosa da contribuire puoi commentarlo.

Soluzione:

Soluzione 1:

In generale:

La visualizzazione e la modifica della configurazione del firewall richiede i privilegi di amministratore (root), così come
l'apertura di servizi nell'intervallo dei numeri di porta limitati. Ciò significa che è necessario effettuare l'accesso
come root o in alternativa utilizzare sudo per eseguire il comando come root. Cercherò di contrassegnare tali comandi con l'opzione [sudo].

Contenuto:

  1. L'ordine conta o la differenza tra -I e -A
  2. Visualizza la configurazione corrente del firewall
  3. Interpretare il risultato di iptables -L -v -n
  4. Conoscere l'ambiente
  5. Le catene INPUT e FORWARD
  6. Moduli del kernel

1. L'ordine o la differenza tra -I e -A

La cosa da ricordare è che le regole del firewall vengono controllate nell'ordine in cui sono elencate. Il kernel interrompe l'elaborazione della catena quando viene attivata una regola che consente o non consente un pacchetto o una connessione.

Penso che l'errore più comune per gli amministratori di firewall alle prime armi è quello di seguire le istruzioni corrette per aprire una nuova porta, come quella riportata di seguito:

[sudo] iptables -A INPUT -i eth0 -p tcp --dport 8080 -j ACCEPT

per poi scoprire che non ha effetto.

Il motivo è che l'opzione -A aggiunge questa nuova regola, dopo tutte le regole esistenti
e poiché molto spesso la regola finale del firewall esistente era una regola che bloccava tutto il traffico non esplicitamente consentito, il risultato era

...
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 avrebbe funzionato.

2. Visualizzare la configurazione attuale del firewall

Il mio consiglio per l'amministratore del firewall è di guardare la configurazione attuale del kernel Linux, piuttosto che cercare di diagnosticare i problemi del firewall da strumenti di facile utilizzo.
piuttosto che cercare di diagnosticare i problemi del firewall con strumenti di facile utilizzo. Spesso una volta compresi i problemi sottostanti è possibile
risolverli facilmente in un modo supportato da questi strumenti.

Il comando [sudo] iptables -L -v -n è il vostro amico (anche se alcuni preferiscono iptables-save ). Spesso, quando si discute di configurazioni, è utile usare il comando --line-numbers per numerare le righe.
per numerare le righe. Fare riferimento alla regola #X rende la discussione un po' più semplice.
Nota: Le regole NAT sono incluse nella sezione iptables-save ma devono essere elencate separatamente aggiungendo l'opzione -t nat cioè [sudo] iptables -L -v -n -t nat --line-numbers.

Eseguire il comando più volte e controllare l'incremento dei contatori 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 configurazione del firewall di cui sopra:

[[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 preferenze su cosa sia più facile da capire.

3. Interpretare il risultato di iptables -L -v -n

Il Politica imposta l'azione predefinita che la catena utilizza quando nessuna regola esplicita corrisponde. Nel campo INPUT è impostata su ACCETTA tutto il traffico.

La prima regola della 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 a una destinazione personalizzata (fail2ban-SSH).
Come indica il nome, questa regola è gestita da fail2ban (un prodotto di sicurezza che, tra le altre cose, analizza i file di log del sistema per individuare eventuali abusi e blocca l'indirizzo IP dell'autore dell'abuso).

Questa regola sarebbe stata creata da una riga di comando di 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 si trova 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 elaborato dalla regola fail2ban-SSH che, in quanto catena non standard, viene elencata sotto la catena OUTPUT.

Questa catena è composta da due regole, una per ogni utente abusivo (indirizzo ip di origine 117.253.221.166 o 58.218.211.166) che viene bloccato (con una regola 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 questi host bloccati non sono ancora né permessi né disconosciuti e ora che la catena personalizzata è completata saranno controllati dalla seconda regola della catena INPUT.

Tutti i pacchetti non destinati alla porta 22 hanno superato la prima regola della catena INPUT e saranno valutati anche nella regola INPUT #2.

Il numero 2 della regola di INPUT significa che si tratta di una regola di firewall completo di stato che tiene traccia delle connessioni. Questo ha alcuni vantaggi: solo i pacchetti per le nuove connessioni devono essere controllati rispetto a
l'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 ingresso #2 corrisponde a tutte le connessioni aperte e correlate e i pacchetti che corrispondono a questa regola non devono essere valutati ulteriormente.

Nota: le modifiche alle regole nella configurazione di un firewall stateful avranno un impatto solo sulle nuove connessioni, non su quelle già stabilite.

Al contrario, un semplice filtro dei pacchetti verifica ogni pacchetto rispetto all'intero set di regole, senza tenere traccia dello stato della connessione. In un firewall di questo tipo nessun stato verrebbero utilizzate.

La regola INPUT #3 è piuttosto noiosa, tutto il traffico che si connette al loopback (lo o 127.0.0.1) è consentito.

Le regole INPUT 4, 5 e 6 sono utilizzate per aprire le porte TCP 22, 80 e 443 (le porte predefinite per SSH, HTTP e HTTPS), consentendo l'accesso a nuove connessioni (le connessioni esistenti sono già consentite da INPUT).
(le connessioni esistenti sono già consentite dalla regola INPUT 2).

In un firewall stateless queste regole appaiono 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, la #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 viene negato. In teoria questa regola potrebbe essere omessa impostando la POLICY predefinita su REJECT.

Esamina sempre l'intera catena.

4. Conoscere l'ambiente

4.1 . Le impostazioni di un firewall software non influiscono sulle impostazioni di sicurezza mantenute altrove nella rete,
cioè, nonostante l'apertura di un servizio di rete con iptables le liste di controllo degli accessi non modificate sui router o su altri firewall della rete possono ancora bloccare il traffico...

4.2 . Se nessun servizio è in ascolto, non sarà possibile connettersi e si otterrà un errore di connessione rifiutata, indipendentemente dalle impostazioni del firewall. Pertanto:

  • Confermare che un servizio è in ascolto (sulla corretta interfaccia di rete/indirizzo IP) e che utilizza i numeri di porta previsti con [sudo] netstat -plnut o in alternativa utilizzare ss -tnlp.
  • Se i servizi non sono ancora in esecuzione, emulare un semplice ascoltatore con, ad esempio, netcat: [sudo] nc -l -p 123 oppure openssl s_server -accept 1234 [options] se si ha bisogno di un ascoltatore TLS/SSL (controllare man s_server per le opzioni).
  • Verificare che sia possibile connettersi dal server stesso, ad esempio telnet 123 o echo "Hello" | nc 123 oppure quando si testa un servizio protetto TLS/SSL openssl s_client -connect :1234prima di provare lo stesso da un host remoto.

4.3 . Comprendere i protocolli utilizzati dai servizi. Non è possibile abilitare/disabilitare correttamente servizi che non si conoscono a sufficienza. Ad esempio:

  • si utilizza TCP o UDP o entrambi (come nel caso del DNS)?
  • il servizio utilizza una porta predefinita fissa (ad esempio la porta TCP 80 per un server web)?
  • in alternativa, viene scelto un numero di porta dinamico che può variare (ad esempio, servizi RPC come NFS classico che si registrano con Portmap)?
  • Il famigerato FTP utilizza addirittura due porte, sia un numero di porta fisso che dinamico quando è configurato per usare la modalità passiva...
  • le descrizioni dei servizi, delle porte e dei protocolli in /etc/services non corrispondono necessariamente al servizio effettivo che utilizza una porta.

4.4 . Il filtro dei pacchetti del kernel non è l'unico elemento che può limitare la connettività di rete:

  • Anche SELinux potrebbe limitare i servizi di rete. getenforce conferma se SELinux è in esecuzione.
  • Sebbene stiano diventando un po' oscuri, i TCP Wrapper sono ancora uno strumento potente per garantire la sicurezza della rete. Controllare con ldd /path/to/service |grep libwrap e il /hosts.[allow|deny] e i file di controllo /hosts.[allow|deny].

5. INPUT o FORWARD Catene

Il concetto di catena è spiegato in modo più approfondito qui, ma in breve è così:

Il INPUT è il punto in cui si aprono e/o chiudono le porte di rete per i servizi in esecuzione localmente, sull'host in cui si impartiscono i comandi iptables.

La catena FORWARD è quella in cui si applicano le regole per filtrare il traffico che viene inoltrato dal kernel ad altri sistemi,
sistemi veri e propri, ma anche container Docker e server Virtual guest quando la macchina Linux funge da ponte, router, hypervisor e/o esegue la traduzione degli indirizzi di rete e il port forwarding.

Un'idea sbagliata comune è che, poiché un container Docker o un guest KVM viene eseguito localmente, le regole di filtro applicabili dovrebbero essere 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ò essere compilato come modulo dinamico, anzi come modulo multiplo. La maggior parte delle distribuzioni include netfilter come modulo e i moduli netfilter
moduli netfilter richiesti vengono caricati nel kernel quando necessario,
ma per alcuni moduli l'amministratore del firewall dovrà assicurarsi manualmente che vengano caricati. Questo riguarda principalmente i moduli di tracciamento delle connessioni, come ad esempio nf_conntrack_ftp che possono essere caricati con insmod.

I moduli attualmente caricati nel kernel in esecuzione possono essere visualizzati con lsmod.

Il metodo per assicurare che i moduli siano caricati in modo persistente tra i vari 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 del kernel per l'elaborazione dei pacchetti di rete, composto da diversi moduli del kernel che svolgono compiti specifici:

  1. Il modulo FILTER (sempre caricato per impostazione predefinita) consente principalmente di ACCETTARE o SCARICARE pacchetti IP in base a determinati criteri di corrispondenza.
  2. Il modulo NAT consente di eseguire traduzioni di indirizzi di rete (SNAT, DNAT, MASQUERADE).
  3. Il modulo MANGLE consente di alterare alcuni campi dei pacchetti IP (TOS, TTL).

Gli utenti configurano il framework Netfilter in base alle loro esigenze di firewall utilizzando iptables dalla riga di comando. Con iptables si definiscono le regole che istruiscono il kernel su cosa fare dei pacchetti IP quando arrivano, attraversano o lasciano la nostra Linux box.
Ogni processo principale di Netfilter è rappresentato da una TABELLA (FILTER, NAT, MANGLE) nel linguaggio di iptables. Essi hanno diversi punti di aggancio specifici sulla mappa del flusso dei pacchetti di rete, dove vengono invocati dal kernel per svolgere le loro funzioni.
Alcune sequenze specifiche di chiamate a TABELLE sono chiamate genericamente CATENE incorporate che ricevono i nomi di PREROUTING, INPUT, FORWARD, OUTPUT e POSTROUTING.
È facile da ricordare se si associa una TABELLA a un "tipo di processo" e una CATENA alla "posizione" sulla mappa del flusso di pacchetti di rete in cui vengono invocate le istanze di tali processi.

enter image description here

Da quando un pacchetto IP viene ricevuto su un'interfaccia di rete, o creato da un processo locale, fino a quando non viene consegnato o scartato, il motore Netfilter verifica e applica in sequenza le regole contenute nella mappa del flusso dei pacchetti di rete. A ogni blocco identificato da un [email protected] l'utente può aggiungere una o più regole consecutive contenenti un criterio di corrispondenza dei pacchetti IP e un'azione corrispondente. Esistono azioni (ad esempio ACCEPT, DROP, ecc.) che possono essere eseguite da più di una TABELLA e altre azioni (ad esempio SNAT, DNAT, ecc.) che sono specifiche della TABELLA.

Quando un pacchetto IP arriva da un'interfaccia di rete, viene prima elaborato dalla catena PREROUTING invocando le regole definite dall'utente della tabella MANGLE, se presenti. Se non ci sono regole che corrispondono al pacchetto corrente, viene elaborata la corrispondente regola [email protected] di azione predefinita o "politica". A questo punto, se il pacchetto non è stato abbandonato, il processo continuerà invocando le regole della tabella NAT alla catena PREROUTING (vedere la mappa) e così via.
Per facilitare la disposizione delle regole, gli utenti possono anche creare catene personalizzate e "saltare" in esse da diversi punti della mappa, come desiderano.

enter image description here

Mentre le catene integrate possono avere politiche definite dall'utente di ACCEPT o DROP dei pacchetti, le catene definite dall'utente hanno sempre una politica predefinita immutabile di RETURN al chiamante per continuare il processo.

Comandi Iptables

I comandi principali di iptables popolano la mappa del flusso dei pacchetti di rete con le regole di elaborazione richieste.

La regola generica di iptables può essere scritta come:

# iptables

Può essere letta come:

Netfilter (kernel module) please this rule for

at where packets matching have to be ed

-t filter (the filter table is assumed when omitted) -t nat -t mangle -A (append rule at the end of the chain list) -I (insert rule at the begining of the chain list) -D (Delete rule) PREROUTING INPUT FORWARD OUTPUT POSTROUTING USER_DEFINED_CHAIN ISO Level-2 matching: -i [!] or --in-interface [!] (OUTPUT and POSTROUTING chains cannot match on input interfaces) -o [!] or --out-interface [!] (INPUT and PREROUTING chains cannot match on output interfaces) -mac-source [!] (OUTPUT and POSTROUTING chains cannot match on input interfaces) ISO Level-3 matching: -s [!] or --src [!] or --source [!] -d [!] or --src [!] or --destination [!] ISO Level-4 matching: -p [!] or --protocol [!] (udp|tcp|icmp) Also available when ICMP protocol is defined --icmp-type [!] Also available when UDP protocol is defined --source-port [!] or --sport [!] --destination-port [!] or --dport [!] Also available when TCP protocol is defined --source-port [!] or --sport [!] --destination-port [!] or --dport [!] --tcp-flags [!] (SYN|ACK|FIN|RST|URG|PSH|ALL|NONE) --syn --tcp-option [!] --state [!] -m [options] note: [!] = negation operator (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 -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 --log-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 -j SAME (idem SNAT; used when more than one source address) options: --nodst --to -j MASQUERADE (idem SNAT; used when the replace IP is dynamic) -j DNAT (rewrite the destination IP address of the packet) option: --to -j REDIRECT (rewrite dst IP to 127.0.0.1, PREROUTING and OUTPUT only) option: –-to-port mangle table specific -j ROUTE (explicitly route packets, valid at PREROUTING) options: --iface --ifindex -j MARK (set Netfilter mark values) options: --set-mark --and-mark --or-mark -j TOS (set the IP header Type of Service field) option: --set-tos -j DSCP (set the IP header Differentiated Services Field) options: --set-dscp --set-dscp-class -j TTL (set the IP header Time To Live field) options: --ttl-set --ttl-dec --ttl-inc

I comandi ausiliari di iptables completano lo scenario impostando condizioni predefinite, elencando regole, scaricando regole, ecc.

#iptables -t 
-L (Lists the
rules in all chains) #iptables -t
-L (Lists the
rules in ) #iptables -t
-N (Creates a user-defined for holding
rules) #iptables -t
-E (Renames that holds
rules to ) #iptables -t
-X (Deletes all user-defined chains created for holding
rules) #iptables -t
-X (Deletes user-defined created for holding
rules) #iptables -t
-P where = ACCEPT|DROP (Sets the default policy of
rules at to ) #iptables -t
-F (Flushes (deletes) all
rules in all chains) #iptables -t
-F (Flushes (deletes) all
rules in ) #iptables -t
-R (Replaces
rule at position in with

Iptables carica i nostri comandi nel motore di 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 utility iptables che permettono di salvare il set di regole attualmente attivo in un file e di ricaricarlo in seguito.

#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 ha un prezzo da pagare: Iptables è complesso. Dal punto di vista dell'utente, alcuni termini come TABLE, CHAIN, TARGET non corrispondono molto bene al concetto che rappresentano e non hanno molto senso all'inizio. L'argomento è lungo, i comandi sembrano avere un elenco infinito di parametri. A peggiorare le cose non c'è un solo libro che padroneggi davvero le Iptables. Per lo più rientrano in due categorie: "libri di ricette" o "libri di pagine man". Penso che questa introduzione fornisca un'istantanea del panorama di Netfilter/Iptables e la necessaria dose di manpage pre-digerite. Se siete alle prime armi con iptables, dopo aver letto questi paragrafi un paio di volte sarete pronti a leggere gli esempi di iptables. Con un po' di pratica vi troverete presto a scrivere le vostre 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 Netfilter/Iptables di Linux è perfetto per la costruzione di firewall.
Osservando la mappa del flusso dei pacchetti di rete, troviamo due punti particolarmente interessanti nella tabella FILTER, in corrispondenza delle catene INPUT e FORWARD; lì possiamo decidere in base all'indirizzo IP di origine, al protocollo IP (UDP/TCP), alla porta di destinazione (80, 21, 443, ecc.), ecc. se ACCETTARE, RIFIUTARE o semplicemente ELIMINARE un particolare pacchetto IP. Questo è ciò che un firewall fa per l'80% del tempo, ovvero proteggere un server web da richieste di rete non autorizzate. Il restante 20% del tempo manipola (NAT, MANGLE) i pacchetti di rete.

Scenari dei firewall

Esistono centinaia di layout diversi di firewall che rispondono a esigenze diverse, ma 3 di essi possono essere considerati gli scenari più tipici dei firewall.

  1. Semplice server web con una o più interfacce collegate a Internet. I criteri includono regole di base per consentire l'accesso limitato in entrata, l'accesso illimitato in uscita e regole anti-spoofing. L'inoltro IP è disattivato.
  2. Questo firewall si collega a Internet e a un'area interna protetta. Il criterio 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 un NAT sorgente. L'inoltro IP è attivo.
  3. Questo firewall si connette a Internet, all'area interna protetta e demilitarizzata. Il criterio 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.
    enter image description here

Ho scritto questo per:
http://www.vercot.com/~jeoss/howto/JeossEasyFirewall.html


Soluzione 3:

Problemi comuni con diversi protocolli

DNS: Il DNS utilizza la porta 53 UDP per impostazione predefinita, ma i messaggi che non si adattano a un singolo datagramma UDP vengono trasmessi utilizzando il TCP (tipicamente i trasferimenti di zone e simili).
(tipicamente trasferimenti di zone e simili), richiedendo l'apertura della porta 53 TCP anche quando si esegue un server di nomi.

Email: Molti ISP di consumo bloccano il traffico SMTP (o almeno la porta predefinita TCP 25), rendendo impossibile la ricezione diretta o l'invio di e-mail.
o inviare 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 entrata.
Si riferisce al §1.1.

FTP: L'FTP è un protocollo strano in quanto due connessioni. La prima è la connessione di controllo, per impostazione predefinita un server FTP si mette in ascolto sulla porta TCP 21. La connessione di controllo viene utilizzata per l'autenticazione e l'emissione di comandi.
La connessione di controllo è usata per l'autenticazione e l'emissione di comandi. I trasferimenti effettivi di file e le cose come l'output di un elenco di directory passano su una seconda connessione TCP,
la connessione DATA
. In FTP attivo, la connessione DATA 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 che si trovano dietro a firewall e gateway NAT, per cui è 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 DATA su una seconda porta, alla quale il client FTP può connettersi.
Il problema per un firewall è che la porta DATA può essere una qualsiasi porta non privata tra 1024 e 6536.

In un firewall stateless questo problema viene tipicamente risolto limitando il numero di porte passive che il server FTP può assegnare e quindi aprendo esplicitamente tali porte.

iptables -A INPUT -p tcp --match multiport --dports 21000:21050 -j ACCEPT

In un firewall stateful non è necessario aprire esplicitamente la porta DATA, il modulo helper di netfilter riconoscerà la porta dinamica che viene assegnata e aprirà dinamicamente quella porta per il client corretto, contrassegnandola con un segno di riconoscimento.
per il client corretto, contrassegnando la connessione DATA come RELATED dopodiché corrisponderà alla regola generica:

  iptables -I INPUT -p tcp -m state ESTABLISHED,RELATED -j ACCEPT

Ciò richiede che la porta corretta modulo del kernel sia caricato, nel caso dell'FTP manualmente eseguendo, ad esempio, il comando insmod nf_conntrack_ftp, facendo in modo che la persistenza del modulo dipenda dal riavvio della distribuzione.

Nota: Il modulo di tracciamento delle connessioni FTP fallirà quando FTP è usato con SSL, poiché la connessione di controllo sarà criptata e nf_conntrack_ftp non sarà più in grado di leggere la risposta PASV.

NFS e simili servizi RPC: Il problema dei servizi RPC è che, per loro stessa natura, non utilizzano una porta fissa specifica. Possono scegliere a caso qualsiasi porta disponibile,
che verrà registrata con il demone RPC Portmap. Un client che cerca di connettersi interroga il demone Portmap e si connette direttamente alla porta corretta. Questo 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 che il servizio RPC sta utilizzando.
Il problema dell'apertura di una porta casuale in un firewall viene in genere risolto limitando il servizio RPC, come il server NFS, all'uso di una porta fissa predefinita.

Alla fine di questo articolo puoi trovare le osservazioni di altri creatori, hai anche il potere di inserire le tue se lo ritieni conveniente.



Utilizzate il nostro motore di ricerca

Ricerca
Generic filters

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.