In generale:
La visualizzazione e la modifica della configurazione del firewall richiede i privilegi di amministratore ( root) così come l'apertura dei servizi nell'intervallo di numeri di porta limitati. Ciò significa che è necessario accedere come rooto in alternativa utilizzare sudoper eseguire il comando come root. Proverò a contrassegnare tali comandi con il facoltativo [sudo].
Contenuti:
- L'ordine è importante o la differenza tra
-Ie-A
- Visualizza la configurazione corrente del firewall
- Interpretazione dell'uscita 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 -Ie-A
La cosa da ricordare è che le regole del firewall sono controllate nell'ordine in cui sono elencate. Il kernel interromperà l'elaborazione della catena quando viene attivata una regola che consentirà o non consentirà un pacchetto o una connessione.
Penso che l'errore più comune per gli amministratori di firewall principianti sia 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 l' -Aopzione 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 conseguente
...
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 -Ila nuova regola sarebbe stata la prima della catena e funzionerà.
2. Visualizza la configurazione corrente del firewall
La mia raccomandazione per l'amministratore del firewall è di esaminare la configurazione effettiva che il kernel Linux sta eseguendo, piuttosto che cercare di diagnosticare i problemi del firewall con strumenti intuitivi. Spesso, una volta comprese le problematiche sottostanti, è possibile risolverle facilmente in una questione supportata da tali strumenti.
Il comando [sudo] iptables -L -v -nè tuo amico (anche se ad alcune persone piace di iptables-savepiù). Spesso quando si discute di configurazioni è utile usare anche l' --line-numbersopzione per numerare le righe. Fare riferimento alla regola #X rende un po 'più facile discuterne.
Nota: le regole NAT sono incluse iptables-savenell'output ma devono essere elencate separatamente aggiungendo l' -t natopzione cioè [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.
[root@host ~]# 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-savefornisce uno script in grado di rigenerare la configurazione del firewall sopra:
[root@host ~]# 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'uscita di iptables -L -v -n
La politica imposta l'azione di default gli usi della catena quando non ci sono esplicite regole di fiammiferi. Nella INPUTcatena impostata su ACCETTA tutto il traffico.
La prima regola nella catena INPUT è immediatamente 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, esegue la scansione dei file di registro di sistema per possibili abusi e blocca l'indirizzo IP dell'utente malintenzionato).
Tale regola sarebbe stata creata da una riga di comando di iptables simile iptables -I INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSHo si trova nell'output di iptables-save as -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 abbinato 784'000 pacchetti e 65 Megabyte di dati.
Il traffico corrispondente a questa prima regola viene quindi elaborato dalla fail2ban-SSHcatena che, come catena non standard, viene elencata sotto la catena OUTPUT.
Quella catena è composta da due regole, una per ciascun abusatore (indirizzo IP sorgente 117.253.221.166 o 58.218.211.166) che è bloccato (con a 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é non consentiti e ora il completamento della catena personalizzata verrà verificato 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 saranno anche valutati nella regola INPUT n. 2.
La regola INPUT numero 2 rende questo inteso come un firewall statefull , che tiene traccia delle connessioni. Ciò presenta alcuni vantaggi, solo i pacchetti per le nuove connessioni devono essere verificati rispetto al set di regole completo, ma una volta consentiti i pacchetti aggiuntivi appartenenti a una connessione stabilita o correlata vengono accettati senza ulteriore controllo.
La regola di input n. 2 corrisponde a tutte le connessioni aperte e correlate e i pacchetti corrispondenti a tale regola non dovranno essere ulteriormente valutati.
Nota: le modifiche alle regole nella configurazione di un firewall con stato influiranno solo sulle nuove connessioni, non su quelle stabilite.
Al contrario, un semplice filtro di pacchetti verifica ogni pacchetto rispetto al set di regole completo, senza tenere traccia dello stato della connessione. In quali un firewall non statali parole chiave sarebbero stati utilizzati.
La regola INPUT n. 3 è abbastanza noiosa, loè consentito tutto il traffico connesso all'interfaccia loopback ( o 127.0.0.1).
Le regole INPUT 4, 5 e 6 vengono utilizzate per aprire le porte TCP 22, 80 e 443 (le porte predefinite per risp. 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 tali 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 la POLICY di default su REJECT.
Indaga sempre su tutta la catena.
4. Conosci il tuo ambiente
4.1 Le impostazioni in un firewall software non influiranno sulle impostazioni di sicurezza mantenute altrove nella rete, vale a dire nonostante l'apertura di un servizio di rete con iptablesgli elenchi di controllo degli accessi non modificati su router o altri firewall nella tua rete possa ancora bloccare il traffico ...
4.2 Quando nessun servizio è in ascolto, non sarà possibile connettersi e ricevere un errore di connessione rifiutata , indipendentemente dalle impostazioni del firewall. Perciò:
- Conferma che un servizio è in ascolto (sull'interfaccia / indirizzo IP di rete corretti) e utilizza i numeri di porta previsti
[sudo] netstat -plnuto in alternativa utilizza ss -tnlp.
- Se i tuoi servizi non devono ancora essere in esecuzione, emula un semplice listener con ad esempio netcat:
[sudo] nc -l -p 123o openssl s_server -accept 1234 [options] se hai bisogno di un listener TLS / SSL (controlla le man s_serveropzioni).
- Verificare che sia possibile connettersi dal server stesso, ovvero
telnet <IP of Server> 123o echo "Hello" | nc <IP of Server> 123o durante il test del servizio protetto TLS / SSL openssl 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 è possibile abilitare / disabilitare correttamente i servizi che non si comprendono a sufficienza. Per 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 registra con Portmap)?
- famigerato FTP utilizza anche due porte , sia un numero di porta fisso che uno dinamico quando configurato per utilizzare la modalità passiva ...
- le descrizioni dei servizi, delle porte e dei protocolli in
/etc/servicesnon corrispondono necessariamente al servizio effettivo che utilizza una porta.
4.4 Il filtro 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 diventano leggermente oscuri i wrapper TCP sono ancora uno strumento potente per rafforzare la sicurezza della rete. Verificare con
ldd /path/to/service |grep libwrape i /hosts.[allow|deny]file di controllo.
5. INPUTo FORWARDCatene
Il concetto di catene è spiegato più a fondo qui, ma il corto è:
La INPUTcatena è il punto in cui si aprono e / o si chiudono le porte di rete per i servizi eseguiti localmente, sull'host in cui si emettono i comandi iptables.
La FORWARDcatena è dove si applicano le regole per filtrare il traffico che viene inoltrato dal kernel ad altri sistemi, sistemi reali ma anche container Docker e server Virtual guest Server quando la macchina Linux agisce come bridge, router, hypervisor e / o indirizzo di rete traduzione e port forwarding.
Un malinteso comune è che poiché un contenitore docker o un guest KVM viene eseguito localmente, le regole di filtro che si applicano dovrebbero essere nella catena INPUT, ma di solito non è così.
6. Moduli del kernel
Poiché il filtro 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 che vengano caricati manualmente. Ciò riguarda principalmente i moduli di tracciamento delle connessioni, come quelli nf_conntrack_ftpche possono essere caricati 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 persistente tra i riavvii dipende dalla distribuzione Linux.
