1. Panoramica
iptables è il programma firewall a riga di comando di Linux.
Utilizza diverse catene di policy per filtrare il traffico di rete.
Ad esempio, la catena INPUT serve a filtrare il traffico di rete in entrata.
Oltre alle catene di policy, sono presenti anche regole di destinazione integrate. Queste regole integrate forniscono una decisione sul pacchetto.
Le regole di destinazione integrate più comuni sono ACCEPT , che lascia passare il pacchetto, DROP, che lo filtra scartandolo, e REJECT, che lo filtra rifiutandolo.
Come possiamo vedere, le regole di destinazione DROP e REJECT sono simili tra loro. Vengono utilizzate per filtrare i pacchetti.
In questo tutorial analizzeremo le differenze tra queste due regole.
2. Esempio di configurazione
Esamineremo il comportamento di REJECT e DROP utilizzando due host. Gli host sono host1 e host2 . I loro indirizzi IP sono rispettivamente 192.39.59.16 e 192.39.59.17 .
Entrambi gli host non hanno regole in nessuna delle catene. Verifichiamolo su uno degli host usando iptables :
$ iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
L' opzione –L di iptables elenca le regole della catena selezionata.
Poiché non abbiamo specificato alcuna catena specifica, nell'output sono state elencate tutte le catene.
dobbiamo avere privilegi di root Per usare iptables .
utilizzeremo i comandi ping e nc .
Per comunicare tra gli host
3. Analisi di REJECT
Esamineremo REJECT utilizzando i protocolli ICMP, TCP e UDP. Per prima cosa, applichiamo la regola REJECT su host1 :
$ iptables –A INPUT –s 192.39.59.17 –j REJECT
L' opzione –A di iptables serve per aggiungere regole alla catena specificata.
In questo caso, abbiamo aggiunto la regola alla catena di input usando –A INPUT . Ciò significa che siamo interessati al traffico in entrata.
Inoltre, la parte –s 192.39.59.17 del comando specifica che siamo interessati solo al traffico in arrivo dall'host con indirizzo IP 192.39.59.17 .
L' opzione –s specifica l'indirizzo IP sorgente dei pacchetti in arrivo.
Infine, la parte –j REJECT del comando implica che vogliamo applicare la regola REJECT ai pacchetti in arrivo dall'host con indirizzo IP 192.39.59.17 .
L' opzione –j specifica cosa faremo per i pacchetti corrispondenti.
Poiché abbiamo modificato solo le regole nella catena INPUT , controlliamo solo le regole nella catena INPUT utilizzando iptables :
$ iptables –L INPUT
Chain INPUT (policy ACCEPT)
target prot opt source destination
REJECT all -- 192.39.59.17 anywhere reject-with icmp-port-unreachable
Quindi abbiamo aggiunto correttamente la regola alla catena INPUT .
3.1. Comportamento in ICMP
Dopo aver applicato la REJECT regola su host1 , eseguiamo il ping su host1 da host2 :
$ ping –c 1 192.39.59.16
PING 192.39.59.16 (192.39.59.16) 56(84) bytes of data.
From 192.39.59.16 icmp_seq=1 Destination Port Unreachable
--- 192.39.59.16 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
Abbiamo inviato una sola richiesta di eco ICMP all'host di destinazione 192.39.59.16 utilizzando –c 1. Tuttavia ,
abbiamo ricevuto immediatamente un errore "Destination Port Unreachable" .
Questo errore indica che siamo riusciti a raggiungere l'host di destinazione, ma non abbiamo ricevuto una risposta di eco ICMP.
Ciò è dovuto alla regola REJECT che abbiamo specificato su host1 .
L' errore "Destination Port Unreachable" è l'errore predefinito per REJECT .
È possibile modificare il tipo di errore durante l'aggiunta della regola alla catena utilizzando iptables .
È necessario utilizzare l' –reject-with opzione di iptables .
Ad esempio, se avessimo utilizzato il seguente comando con –reject-with icmp-host-prohibited , avremmo ricevuto l' "Destination Host Prohibited ": errore
$ iptables –A INPUT –s 192.39.59.17 –j REJECT –-reject with icmp-host-prohibited
3.2. Comportamento in TCP
Utilizzeremo nc per analizzare la regola REJECT . Per prima cosa, eseguiamo nc su host1 come processo server:
$ nc –l 1234
L' –l opzione di nc ci consente di eseguire nc come processo server.
Si collega e rimane in ascolto per le connessioni in ingresso sulla porta TCP specificata.
Il protocollo di trasporto predefinito utilizzato da nc è TCP.
Come risultato dell'esecuzione di questo comando, abbiamo generato un processo in attesa di connessioni TCP su host1 sulla porta 1234 .
Ora eseguiamo nc su host2 :
$ nc 192.39.59.16 1234
Ncat: Connection refused.
In questo caso, abbiamo provato a stabilire una connessione TCP con il processo server in attesa su host1 sulla porta 1234
Tuttavia, abbiamo ricevuto un errore di connessione rifiutata non appena abbiamo eseguito il comando, comportamento è come se non ci fosse alcun processo server in attesa di input su host1 sulla porta 1234 .
3.3. Comportamento in UDP
Analizzeremo il comportamento di REJECT per il protocollo UDP utilizzando nc . Eseguiamo nc su host1 :
$ nc -u –l 1234
Qui, l'unica differenza rispetto al caso TCP è l' opzione -u .
Questa opzione indica a nc di utilizzare UDP come protocollo di trasmissione.
Il processo generato ha iniziato ad attendere i datagrammi UDP sulla porta UDP 1234 .
Ora eseguiamo nc su host2 per inviare datagrammi UDP a host1 . Per prima cosa, useremo l' opzione –u per indicare a nc di utilizzare UDP come protocollo di trasmissione. Tutte le altre opzioni sono le stesse della comunicazione TCP:
$ nc –u 192.39.59.16 1234
Questa volta non abbiamo ricevuto un errore immediato di "Connessione rifiutata" come nel caso di TCP.
nc attende l'input. Ora proviamo a inviare un messaggio da host2 a host1 :
$ nc –u 192.39.59.16 1234
Hello host1
Ncat: Connection refused.
Abbiamo ricevuto un errore di connessione rifiutata quando abbiamo provato a inviare il messaggio Hello host1 .
4. Analisi di DROP
Esaminiamo DROP utilizzando i protocolli ICMP, TCP e UDP. Per prima cosa, eliminiamo la regola REJECT che avevamo applicato in precedenza su host1 :
$ iptables –D INPUT –s 192.39.59.17 –j REJECT
L' opzione –D di iptables ha eliminato la regola che avevamo precedentemente aggiunto.
Ora applichiamo la DROP regola su host1 :
$ iptables –A INPUT –s 192.39.59.17 –j DROP
Controlliamo le regole nella catena INPUT dopo aver applicato DROP :
$ iptables –L INPUT
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all -- 192.39.59.17 anywhere
Quindi abbiamo applicato correttamente la regola DROP .
4.1. Comportamento in ICMP
Dopo aver applicato la regola DROP su host1 , eseguiamo il ping di host1 da host2 :
$ ping –c 1 192.39.59.16
PING 192.39.59.16 (192.39.59.16) 56(84) bytes of data.
--- 192.39.59.16 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
Abbiamo inviato una sola richiesta ICMP all'host di destinazione 192.39.59.16 utilizzando –c 1.
In questo caso, non abbiamo ricevuto risposta alla richiesta ICMP.
La nostra richiesta è semplicemente scaduta dopo un po' .
4.2. Comportamento in TCP
Analizzeremo il comportamento di TCP mentre la regola DROP è in azione. Iniziamo eseguendo nc su host1 :
$ nc –l 192.39.59.16 1234
Come in precedenza, abbiamo generato un processo in attesa di connessioni TCP su host1 sulla porta 1234 .
Ora eseguiamo di nuovo nc su host2 come prima e proviamo a inviare un messaggio a host1 :
$ nc 192.39.59.16 1234
Hello host1
Ncat: Connection timed out.
Dopo un po' abbiamo ricevuto un errore di connessione scaduta .
Il messaggio non è stato inviato nemmeno a host1 . Il processo client non è riuscito a stabilire una connessione con il processo server in attesa su host1 .
4.3. Comportamento in UDP
Analizzeremo il comportamento di UDP mentre la regola DROP è in azione. Eseguiamo nc su host1 usando l' opzione –u affinché nc utilizzi UDP come protocollo sottostante:
$ nc –u –l 192.39.59.16 1234
Ora eseguiamo nuovamente nc su host2 utilizzando l' opzione –u :
$ nc –u 192.39.59.16 1234
In questo caso, non succede nulla.
Sia il processo server su host1 che il processo client su host2 attendono.
Proviamo a inviare un messaggio da host2 a host1 :
$ nc –u 192.39.59.16 1234
Hello host1
Non abbiamo ricevuto alcun errore, ma il messaggio non è stato inviato al server su host1 .
Sembra che il messaggio inviato sia andato perso nella rete.
5. Conclusion
In questo articolo abbiamo discusso le differenze tra le regole DROP e REJECT nell'utilizzo di iptables . Le abbiamo esaminate utilizzando la catena INPUT .
La regola REJECT ha immediatamente respinto le richieste di eco ICMP con un "Destination Port Unreachable" errore .
D'altra parte, per DROP , la richiesta di eco ICMP è scaduta dopo un po'.
Utilizzando TCP, abbiamo ricevuto un errore immediato di "Connessione rifiutata" nel caso di REJECT , abbiamo ricevuto un errore di "Connessione scaduta" per DROP . .
Ma, dopo un po'
Infine, utilizzando UDP con la regola REJECT abilitata, abbiamo ricevuto un di connessione rifiutata errore quando abbiamo provato a inviare un messaggio dal processo client al processo server.
Tuttavia, non abbiamo ricevuto alcun errore di DROP quando abbiamo provato a inviare un messaggio al processo server.
Il team di sviluppo di IPFire è entusiasta di presentare Core Update 200, una pietra miliare storica per il progetto!
In un mondo sempre più connesso, la sicurezza delle reti è diventata una priorità assoluta. Un elemento chiave nella difesa di queste reti è rappresentato dai firewall, strumenti cruciali per filtrare il traffico in ingresso e in uscita. Ma quando si configura un firewall, una delle decisioni più importanti riguarda le azioni da intraprendere quando un pacchetto di dati che non soddisfa le regole di accesso arriva al dispositivo: rifiutare (REJECT) o abbandonare (DROP)? Esploriamo insieme le differenze tra queste due strategie e come scegliere quella più adatta alle proprie esigenze.
È finalmente arrivato IPFire 2.29 - Core Update 198, un aggiornamento cruciale per tutti gli utenti del nostro firewall open-source preferito. Questa nuova release porta con sé un notevole potenziamento al sistema di prevenzione delle intrusioni (IPS) grazie all'integrazione di Suricata 8. Le performance migliorate, le capacità di ispezione più dettagliate e l'affidabilità superiore non sono che un assaggio di ciò che ci attende.
La comunità italiana di IPFire è entusiasta di annunciare la sua partecipazione a due eventi eccezionali, che rappresentano un’occasione imperdibile per tutti gli appassionati e professionisti della sicurezza informatica. Il primo evento si svolgerà a Firenze il 24 ottobre, durante l’evento dedicato all’e-privacy, mentre il secondo avrà luogo ad Ancona, presso l'Università, il 21 novembre, nel contesto del Ctrl Sec Day. Questi due appuntamenti non solo offriranno l'opportunità di far conoscere le potenzialità del sistema operativo IPFire, ma anche di rafforzare il legame con la comunità internazionale, creando occasioni di scambio e apprendimento.
Siamo entusiasti di annunciare che l'attesa è finalmente terminata: IPFire 2.29 - Core Update 197 è ufficialmente disponibile! Questo aggiornamento non rappresenta solo un semplice passaggio di versione; porta con sé una serie di innovazioni che fanno davvero la differenza.