News

Siamo lieti di annunciare il rilascio di IPFire 2.29 – Core Update 200, un aggiornamento di rilievo che rappresenta un traguardo significativo nel ciclo di sviluppo del progetto.
Questa release introduce il kernel Linux 6.18 LTS, una preview tecnologica di IPFire DBL (Domain Blocklist), numerosi aggiornamenti dei pacchetti di sistema, ottimizzazioni prestazionali, correzioni di sicurezza e ulteriori miglioramenti architetturali.

Il raggiungimento del 200° aggiornamento principale è stato possibile grazie al contributo continuo della community: feedback, segnalazioni e supporto economico hanno giocato un ruolo fondamentale nel garantire qualità e affidabilità alla piattaforma.

Anteprima IPFire DBL e roadmap verso il firewall DNS

Con questa versione viene introdotta una anteprima di IPFire DBL (Domain Blocklist), un nuovo database proprietario progettato per il blocco centralizzato dei domini malevoli o indesiderati.

IPFire DBL costituisce la base per un obiettivo strategico più ampio: la realizzazione di un firewall DNS nativo completamente integrato.
Questo componente fornirà funzionalità avanzate di content filtering a livello DNS, consentendo il blocco di:

• pubblicità invasive
• malware e infrastrutture C2
• contenuti indesiderati o non conformi alle policy aziendali

tutto direttamente all’interno di IPFire, senza la necessità di soluzioni esterne.

Kernel Linux 6.18 LTS

Il kernel di IPFire è stato ribasato su Linux 6.18.7 LTS, introducendo:

• miglioramenti alla sicurezza del kernel
• ottimizzazioni delle prestazioni di rete (throughput e latenza)
• capacità di packet filtering avanzato
• mitigazioni aggiornate per vulnerabilità hardware note

Deprecazione di ReiserFS

Il supporto per ReiserFS è stato deprecato dal kernel Linux.
Le installazioni IPFire basate su questo filesystem non potranno procedere con l’aggiornamento e richiederanno una reinstallazione completa su un filesystem supportato (es. ext4, XFS).

IPFire DBL – Domain Blocklist

A seguito del ritiro della Shalla List, IPFire necessitava di una fonte affidabile e mantenuta per il filtraggio dei domini. IPFire DBL nasce per rispondere a questa esigenza e sarà inizialmente integrato in due componenti chiave:

Integrazioni disponibili

• Filtro URL (Web Proxy)
  IPFire DBL può essere utilizzato per bloccare l’accesso ai domini vietati tramite proxy HTTP/HTTPS.
• Suricata (IDS/IPS)
  IPFire diventa fornitore diretto di regole Suricata, consentendo:
  • ispezione approfondita (DPI)
  • enforcement delle policy su DNS, TLS, HTTP e QUIC
  • maggiore efficacia nel blocco delle comunicazioni verso domini proibiti

Attualmente IPFire DBL è in fase beta iniziale: feedback e contributi sono fortemente incoraggiati.

Miglioramenti e modifiche varie

Sistema di prevenzione delle intrusioni (IDS/IPS)

• Risolta la crescita illimitata della cache delle firme Suricata tramite backport di una patch di pulizia automatica.
• Il reporter ora include hostname e metadati per traffico DNS/HTTP/TLS/QUIC nelle email di allerta e nei report PDF.

OpenVPN

• MTU ora gestita dal server e non più inclusa nella configurazione client.
• Token OTP inviato dal server se il client supporta l’autenticazione a due fattori.
• Rimozione della CA dai file client (già inclusa nel PKCS#12) per migliorare la compatibilità con NetworkManager.

Access Point wireless

• Ripristinato il supporto 802.11a/g
• Riduzione del logging di debug non intenzionale
• Accettazione di PSK con caratteri speciali

DNS e networking

• Unbound ora utilizza un thread per core CPU, migliorando i tempi di risposta.
• PPP invia pacchetti LCP keep-alive solo in assenza di traffico, riducendo l’overhead su DSL e reti mobili.
• Miglioramenti di coerenza nella visualizzazione della legenda DNS nella UI.

Sicurezza e aggiornamenti critici

OpenSSL

Aggiornato a OpenSSL 3.6.1, con patch per numerose vulnerabilità di sicurezza (CVE 2025–2026).

glibc

Patch di sicurezza applicate per:

• CVE-2026-0861
• CVE-2026-0915
• CVE-2025-15281

Aggiornamenti dei pacchetti

Sono stati aggiornati numerosi pacchetti core e add-on, tra cui:

• Apache 2.4.66
• OpenVPN 2.6.17
• OpenSSL 3.6.1
• Suricata 8.0.3
• Unbound 1.24.2
• Rust 1.92.0
• Samba 4.23.4
• Tor 0.4.8.21

Per maggiori dettagli potete visitare il sito ufficiale al seguente link.

Per poter scaricare l'aggiornamento a questo link

Ehi, appassionato di tecnologia!  Sei pronto a dare una svolta alla tua carriera con la certificazione IPFire?

È un’opportunità imperdibile! Se sei interessato, contatta il fantastico staff di IPFire Italia.

Per ottenere la certificazione, dovrai sostenere un esame online, e una volta superato, riceverai il tuo attestato direttamente da noi.

Certificazione IPFire

Vuoi unirti alla nostra squadra? Non essere timido! Scrivici attraverso il modulo che trovi qui e assicurati di lasciare un recapito telefonico per poterti ricontattare. E non dimenticare: puoi anche supportare il progetto IPFire Italia con un piccolo contributo economico tramite PayPal. Ogni aiuto conta!

Nel mondo della sicurezza di rete, il filtraggio dei domini è una di quelle funzionalità fondamentali che tutti danno per scontata… finché non smette di funzionare come dovrebbe. Liste troppo grandi, decisioni opache, consumo eccessivo di risorse e, non ultimo, dubbi legali sulla provenienza dei dati: problemi noti a chiunque gestisca firewall, resolver DNS o infrastrutture di rete anche solo mediamente complesse.

È proprio da qui che nasce IPFire DBL (Domain Blocklist): una nuova soluzione di blocco dei domini, sviluppata da zero, gestita dalla community e progettata per restituire agli utenti il pieno controllo sulle policy di filtraggio.

Perché una nuova Domain Blocklist?

Negli anni il team IPFire ha analizzato sia soluzioni commerciali sia alternative gratuite. Il risultato? Nessuna rispondeva davvero alle esigenze reali degli utenti. L’approccio dominante è quello della blocklist monolitica: milioni di domini inseriti in un unico elenco “onnicomprensivo”, buono (forse) per tutti ma ottimale per nessuno.

Dal punto di vista tecnico questo significa:

• spreco di memoria sui resolver DNS,
• latenza inutile nelle risposte,
• zero flessibilità nelle decisioni di blocco.

Ancora più preoccupante, molte liste aggregano dati da fonti terze senza un chiaro diritto di ridistribuzione, esponendo gli utenti a potenziali problemi di compliance legale.

IPFire DBL nasce per risolvere tutti questi aspetti.

I principi alla base di IPFire DBL

Categorizzazione, non imposizione

Il cuore di IPFire DBL è un concetto semplice ma potente: non esiste una policy di blocco valida per tutti.
Invece di imporre decisioni prese da altri, IPFire DBL organizza milioni di domini in categorie funzionali, lasciando all’amministratore la scelta finale.

Vuoi bloccare:

• malware e phishing,
• ma consentire giochi online?

Oppure:

• pornografia e gioco d’azzardo,
• mantenendo accesso a social e piattaforme educative?

Con IPFire DBL è possibile, perché la logica è modulare.

Le categorie attualmente disponibili

Le liste curate includono, tra le altre:

• Malware
  Blocca domini malevoli prima che possano distribuire payload o stabilire canali di Command & Control (C2).
• Phishing
  Protezione a livello di rete contro il furto di credenziali, indipendentemente dal dispositivo utilizzato.
• Pubblicità
  Riduzione del tracciamento, recupero di banda e miglioramento della privacy direttamente alla fonte DNS.
• Pornografia
  Filtraggio coerente su tutta la rete, ideale per ambienti familiari o scolastici.
• Gioco d’azzardo
  Blocco di casinò online e siti di scommesse.
• Giochi
  Per ambienti lavorativi o didattici dove la concentrazione conta.
• DNS-over-HTTPS (DoH)
  Impedisce l’aggiramento delle policy DNS mantenendo la visibilità del traffico.

E questo è solo l’inizio.

Standard aperti, integrazione immediata

Uno dei punti di forza più importanti di IPFire DBL è la scelta consapevole degli standard aperti. Nessun lock-in, nessun formato proprietario.

Dal punto di vista tecnico, IPFire DBL supporta:

• DNS Response Policy Zones (RPZ)
  Standard industriale per il blocco DNS, con supporto completo a AXFR/IXFR per aggiornamenti rapidi e incrementali.
• Formato SquidGuard
  Perfetto per chi utilizza proxy HTTP/HTTPS con filtraggio URL.
• Liste testuali via HTTPS
  Compatibilità massima con firewall, resolver e strumenti di rete eterogenei.
• Sintassi Adblock Plus
  Utilizzabile anche a livello di browser o estensioni client-side.

Che tu stia gestendo BIND, Unbound, PowerDNS, Pi-hole, firewall commerciali o soluzioni personalizzate, se supportano formati standard… supportano anche IPFire DBL.

Performance, aggiornamenti e intelligence collaborativa

Con aggiornamenti orari e un processo di cura continua, IPFire DBL si adatta rapidamente a un panorama delle minacce in costante evoluzione.

Ma il vero valore aggiunto è il coinvolgimento diretto della community.

Grazie allo strumento di segnalazione online puoi:

• indicare falsi positivi,
• proporre nuovi domini malevoli,
• contribuire a migliorare la qualità delle liste in tempo reale.

È threat intelligence distribuita, costruita da chi la rete la usa davvero.

IPFire Core Update 200: il futuro del filtraggio

Gli utenti IPFire vedranno IPFire DBL integrato nativamente nel prossimo Core Update 200, inizialmente tramite URL Filter.

Ma la vera novità è l’integrazione con Suricata.

Stiamo lavorando a un approccio completamente nuovo per applicare l’intelligence di dominio direttamente al motore IDS/IPS. Questo significa:

• maggiore visibilità sul traffico,
• applicazione delle policy in tempo reale,
• nuove possibilità di correlazione tra eventi di rete e domini.

I dettagli arriveranno presto, ma una cosa è certa: non si è mai visto nulla di simile in IPFire.

Open source, per davvero

IPFire DBL è:

• GPLv3+ per il codice,
• Creative Commons BY-SA 4.0 per le liste.

È una risorsa della community, pensata per essere usata, studiata, migliorata e condivisa. Non solo per IPFire, ma per chiunque creda in un Internet più sicuro, trasparente e controllabile.

Un progetto comunitario: ora tocca a noi

IPFire DBL è il risultato di mesi di sviluppo e di un’esigenza sentita da anni. Le fondamenta sono solide, ma come ogni progetto open source c’è una risorsa che manca sempre: il tempo.

Per portare IPFire DBL al livello successivo – inclusa l’integrazione completa delle RPZ direttamente in IPFire – il team ha avviato una raccolta fondi per sostenere lo sviluppo.

Visita www.ipfire.org/dbl per iniziare subito a usare le liste.
Se IPFire DBL ti fa risparmiare tempo, migliora la sicurezza o semplicemente rispecchia i tuoi valori, considera di supportare il progetto.

Questo è solo l’inizio.
Vediamo cosa possiamo costruire insieme.

Il team di sviluppo di IPFire è entusiasta di presentare Core Update 200, una pietra miliare storica per il progetto!
Questa versione include il kernel Linux 6.18 LTS, un’anteprima molto promettente di IPFire DBL (il nuovo sistema di Domain Blocklist), numerosi aggiornamenti di pacchetti, miglioramenti prestazionali, correzioni di sicurezza e, in generale, tantissime migliorie diffuse in tutto il sistema.

Siamo profondamente grati alla community per il supporto continuo che ci ha permesso di raggiungere questo traguardo del 200° aggiornamento core, e speriamo che apprezziate il lavoro svolto.

Kernel 6.18

Il kernel di IPFire è stato ribasato su Linux 6.18.7, una versione LTS (Long Term Support) che introduce importanti miglioramenti in termini di sicurezza, prestazioni e stabilità.

Dal punto di vista tecnico, questo aggiornamento porta:

• Miglioramenti generali nel throughput di rete e nella riduzione della latenza
• Capacità avanzate di packet filtering e gestione dello stack di rete
• Le più recenti mitigazioni hardware contro vulnerabilità note (side-channel, speculative execution, ecc.)

Deprecazione di ReiserFS

Gli sviluppatori Linux hanno ufficialmente deprecato il filesystem ReiserFS.
Se la tua installazione IPFire utilizza ancora questo filesystem:

• L’interfaccia web lo segnala già da tempo
• Non sarà possibile installare questo aggiornamento

In questo caso è necessario reinstallare IPFire utilizzando un filesystem supportato (ad esempio ext4 o XFS).

IPFire Domain Blocklist (DBL)

Con il ritiro della storica Shalla List, il proxy web di IPFire si è trovato privo di una sorgente affidabile per il blocco dei domini (malware, social network, contenuti per adulti, ecc.).

Per colmare questa lacuna e fornire una soluzione stabile e controllata, il team IPFire ha deciso di sviluppare internamente una propria Domain Blocklist.

IPFire DBL è ancora in una fase iniziale (“baby stage”), ma rappresenta la base di un sistema molto più potente che verrà ampliato nel prossimo futuro.

Attualmente IPFire DBL è integrata in due componenti chiave:

🔹 URL Filter

È ora possibile usare IPFire DBL direttamente nel proxy per bloccare l’accesso ai domini classificati come non consentiti.

🔹 Suricata (IPS)

Con il lancio di IPFire DBL, IPFire diventa anche fornitore ufficiale di regole per Suricata.

Grazie al nuovo database:

• L’IPS può bloccare l’accesso ai siti vietati anche quando il traffico è cifrato
• Viene sfruttata la Deep Packet Inspection (DPI) su:
  • DNS
  • TLS
  • HTTP
  • QUIC

Questo consente un controllo molto più profondo rispetto al semplice filtraggio DNS o IP.

👉 La funzionalità è attualmente in beta iniziale e il team accoglie con piacere feedback e segnalazioni.

Varie (Misc.)

Intrusion Prevention System (Suricata)

• Nella versione precedente era stata introdotta la cache pre-compilata delle firme, che però poteva crescere senza limiti e occupare molto spazio su disco.
  • È stata backportata una patch che consente a Suricata di ripulire automaticamente le firme inutilizzate
• Il reporter è stato migliorato:
  • Gli alert DNS, HTTP, TLS e QUIC ora includono hostname e informazioni aggiuntive
  • I dettagli vengono mostrati nelle email di allerta e nei report PDF
  • Questo facilita le indagini su violazioni delle policy aziendali

OpenVPN

• La MTU non è più hard-coded nel file di configurazione client
  • Ora viene pushata dinamicamente dal server
  • Questo consente all’amministratore di modificarla senza rigenerare i profili
  • ⚠️ Alcuni client molto datati potrebbero non supportare questa modalità
• Anche il token OTP viene ora pushato dal server se il client ha OTP abilitato
• Il certificato CA non è più incluso nei file client
  • È già contenuto nel PKCS#12
  • Questo risolve problemi di importazione con NetworkManager via CLI

Access Point Wireless

• Reintrodotto il supporto per 802.11a/g
• Corretto un problema per cui hostapd produceva log di debug eccessivi
• Ora sono accettate PSK con un set più ampio di caratteri speciali

DNS (Unbound)

Unbound, il DNS proxy di IPFire, ora:

• Avvia un thread per ogni core CPU
• In precedenza funzionava in single-thread
• Questo porta a tempi di risposta più rapidi e maggiore capacità sotto carico

PPP

• IPFire invia pacchetti LCP keep-alive solo in assenza di traffico
• Riduzione dell’overhead su connessioni DSL, 4G e 5G

Interfaccia Utente

• La pagina DNS ora mostra sempre la legenda, migliorando la chiarezza dell’interfaccia

Sicurezza

OpenSSL

Aggiornato a OpenSSL 3.6.1, con patch per le seguenti vulnerabilità:

• CVE-2025-11187
• CVE-2025-15467
• CVE-2025-15468
• CVE-2025-15469
• CVE-2025-66199
• CVE-2025-68160
• CVE-2025-69418 / 69419 / 69420 / 69421
• CVE-2026-22795 / 22796

glibc

Patch applicate per:

• CVE-2026-0861
• CVE-2026-0915
• CVE-2025-15281

Pacchetti aggiornati (selezione)

Come sempre, l’elenco è molto ampio. Tra i principali:

• Apache 2.4.66
• OpenVPN 2.6.17
• Suricata 8.0.3
• Unbound 1.24.2
• StrongSwan 6.0.4
• Rust 1.92.0
• SQLite 3.51.100
• Vim 9.1.2098
• xz 5.8.2
  (segue elenco completo come da release notes)

Add-on aggiornati

Tra i più rilevanti:

• ClamAV 1.5.1
• FreeRADIUS 3.2.8
• Samba 4.23.4
• Tor 0.4.8.21
• TShark 4.6.3
• Git 2.52.0
  (elenco completo incluso nella release)

Come eseguire l'aggiornamento alla versione di test

L'aggiornamento alla versione di test viene eseguito sempre tramite interfaccia web e Pakfire. Possiamo verificare la versione attualmente presente anche da console:

Il primo passaggio da fare è modificare il Repository in modo che ci restituisca il ramo Testing:

Dopo che Pakfire avrà scaricato le informazioni necessarie per l'aggiornamento avrete a disposizione in alto la versione di IPFire da poter selezionare:

L'update effettuerà l'aggiornamento alla nuova release e ci avviserà che per questo tipo di aggiornamento è necessario il riavvio:

Eseguiamo il reboot e verifichiamo lo stato della situazione:

Benissimo adesso il nostro IPFire è aggiornato all'ultima versione e possiamo procedere a effettuare i nostri test.

Mi raccomando, segnalateci eventuali anomalie che riscontrate per fixarle sulla prossima stable che uscirà prossimamente.

1. Panoramica

In questo breve tutorial esploreremo come il comando ping di Linux può aiutarci a diagnosticare e risolvere i problemi di rete.

2. Sintassi

Cominciamo dando un'occhiata alla sintassi di base:

ping [OPTIONS] DESTINATION

Il comando ping (Packet INternet Groper) utilizza il protocollo ICMP (Internet Control Message) per inviare pacchetti a un server.

Per illustrare il comando ping , proviamo a effettuare il ping su www.ipfireitalia.it :

$ ping www.ipfireitalia.it

PING www.ipfireitalia.it (194.76.116.194): 56 data bytes

64 bytes from 194.76.116.194: icmp_seq=0 ttl=54 time=202.324 ms

64 bytes from 194.76.116.194: icmp_seq=1 ttl=54 time=171.035 ms

^C

--- www.ipfireitalia.it ping statistics ---

2 packets transmitted, 2 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 171.035/181.566/202.324 /11.452 ms

Innanzitutto, il comando ping determina l'indirizzo IP dal nome di dominio specificato.

Successivamente, inizia a inviare pacchetti ICMP al server.

Quando il pacchetto raggiunge la destinazione, il server risponde e il comando ping visualizza una riga sulla nostra console.

Per impostazione predefinita, stampa una riga che include le seguenti informazioni:

• Numero di byte inviati , che per impostazione predefinita è 64 byte di dati ICMP
• Indirizzo IP di destinazione , in questo caso, 194.76.116.194
• Numero di sequenza del pacchetto ICMP , ad esempio, icmp_seq=0
• Tempo di vita (TTL) , indica il numero di salti prima che il pacchetto venga eliminato, qui è 54
• Tempo di andata e ritorno del comando ping , in questo caso 202.324 ms

Quindi, possiamo vedere che invia pacchetti ICMP in modo continuo e dobbiamo interrompere manualmente l'invio dei pacchetti utilizzando Ctrl + C (Windows) o Comando + C (Mac).

Inoltre, mostra la percentuale di pacchetti persi a causa di problemi di rete.

3. Utilizzo di base

Ora che abbiamo visto l'output predefinito, è il momento di vedere alcune delle opzioni in azione.

3.1. Specifica dell'intervallo tra i pacchetti

Per impostazione predefinita, il comando ping invia un nuovo pacchetto ogni secondo.

Usiamo il flag -i per modificare l'intervallo del ping :

$ ping -i 3 www.ipfireitalia.it

PING www.ipfireitalia.it (194.76.116.194): 56 data bytes

64 bytes from 194.76.116.194: icmp_seq=0 ttl=54 time=190.037 ms

64 bytes from 194.76.116.194: icmp_seq=1 ttl=54 time=186.061 ms

64 bytes from 194.76.116.194: icmp_seq=2 ttl=54 time=187.458 ms

^C

--- www.ipfireitalia.it ping statistics ---

3 packets transmitted, 3 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 186.061/187.852/190.037/1.647 ms

Ora non c'è alcun output che lo dimostri, ma eseguendolo possiamo vedere che otteniamo una nuova riga di output ogni tre secondi.

3.2. Controllo del numero di pacchetti

In pratica, utilizziamo spesso l'   opzione -c per specificare il numero di pacchetti ICMP che vogliamo inviare al server di destinazione:

$ ping -c 3 www.ipfireitalia.it

PING www.ipfireitalia.it (194.76.116.194): 56 data bytes

64 bytes from 194.76.116.194: icmp_seq=0 ttl=54 time=191.813 ms

64 bytes from 194.76.116.194: icmp_seq=1 ttl=54 time=177.645 ms

64 bytes from 194.76.116.194: icmp_seq=2 ttl=54 time=186.750 ms

--- www.ipfireitalia.it ping statistics ---

3 packets transmitted, 3 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 177.645/185.403/191.813/5.862 ms

Come possiamo vedere sopra, abbiamo inviato solo 3 pacchetti ICMP anziché un flusso continuo di pacchetti.

3.3. Specificazione della dimensione del pacchetto

Inoltre, il ping ci consente anche di specificare la dimensione del pacchetto utilizzando il -s flag :

$ ping -s 40 -c 4 www.ipfireitalia.it

PING www.ipfireitalia.it (194.76.116.194): 40 data bytes

48 bytes from 194.76.116.194: icmp_seq=0 ttl=54 time=180.801 ms

48 bytes from 194.76.116.194: icmp_seq=1 ttl=54 time=181.822 ms

48 bytes from 194.76.116.194: icmp_seq=2 ttl=54 time=175.019 ms

48 bytes from 194.76.116.194: icmp_seq=3 ttl=54 time=172.405 ms

--- www.ipfireitalia.it ping statistics ---

4 packets transmitted, 4 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 172.405/177.512/181.822/3.927 ms

Nell'esempio precedente abbiamo utilizzato sia l'opzione -s che -c insieme. Di conseguenza, sono stati inviati solo quattro pacchetti, ciascuno di 40 byte (ICMP: 48 byte).

Questo può essere utilizzato per determinare la latenza nella rete a diverse dimensioni di pacchetto.

Ad esempio, in molte reti complesse, si verificano problemi quando la dimensione del pacchetto supera i 1500 byte. Modificando la dimensione del pacchetto, possiamo determinare la dimensione ideale per il nostro sistema.

4. Utilizzo avanzato

Diamo ora un'occhiata alle opzioni più avanzate.

4.1 Specificare un timeout

In pratica, su una rete congestionata, potrebbe essere utile impostare un timeout per la risposta dopo un periodo di attesa specifico .   Possiamo farlo con l' -W : opzione

$ ping -c 4 -W 2 www.ipfireitalia.it

PING www.ipfireitalia.it (194.76.116.194): 56 data bytes

--- www.ipfireitalia.it ping statistics ---

4 packets transmitted, 4 packets received, 0.0% packet loss, 4 packets out of wait time

round-trip min/avg/max/stddev = 192.397/195.137/198.573/2.480 ms

Per prima cosa, inviamo la richiesta al server.

Poi, aspettiamo due secondi per ricevere una risposta.

Grazie alla bassa latenza della nostra rete, abbiamo ricevuto tutti i pacchetti correttamente senza alcuna perdita.

4.2. Inondazione della rete tramite ping

A volte vogliamo testare le prestazioni della rete inviando quanti più pacchetti possibile.

Per illustrare questo concetto, eseguiamo il comando ping utilizzando l' opzione -f :

$ ping -f localhost

PING localhost (127.0.0.1): 56 data bytes

..Request timeout for icmp_seq 250

.Request timeout for icmp_seq 251

.Request timeout for icmp_seq 252

.Request timeout for icmp_seq 253

...

^C

--- localhost ping statistics ---

271 packets transmitted, 250 packets received, 7.7% packet loss

round-trip min/avg/max/stddev = 0.010/0.019/0.049/0.005 ms

In questo caso specifico, abbiamo inviato 271 pacchetti con un tempo medio di andata e ritorno di 0,019 secondi.

4.3. Recupero del riepilogo di rete

Successivamente, possiamo recuperare il riepilogo della rete utilizzando il comando con l'aiuto del flag -q :

Per prima cosa, eseguiamo il comando ping utilizzando entrambi i flag -c e -q :

$ ping -c 4 -q www.ipfireitalia.it

PING www.ipfireitalia.it (194.76.116.194): 56 data bytes

--- www.ipfireitalia.it ping statistics ---

4 packets transmitted, 4 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 180.232/189.512/206.033/10.120 ms

Pertanto, questa opzione viene utilizzata per eseguire il comando in modalità silenziosa.

In questo caso, otteniamo solo un riepilogo e non vediamo i dettagli dei singoli pacchetti inviati.

4.4. Utilizzo del ping udibile

Eseguiamo l' utilità ping in modalità udibile utilizzando il flag -a :

$ ping -a www.google.com

PING www.google.com (172.217.163.164): 56 data bytes

64 bytes from 172.217.163.164: icmp_seq=0 ttl=54 time=107.001 ms

64 bytes from 172.217.163.164: icmp_seq=1 ttl=54 time=52.143 ms

64 bytes from 172.217.163.164: icmp_seq=2 ttl=54 time=54.163 ms

^C

--- www.google.com ping statistics ---

3 packets transmitted, 3 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 52.143/71.102/107.001/25.398 ms

Qui possiamo sentire un segnale acustico ogni volta che il nostro client riesce a raggiungere il server host.

5. Conclusion

In questo breve tutorial abbiamo visto come utilizzare il comando ping .

Per prima cosa abbiamo visto come controllare l'intervallo, la dimensione e il numero di pacchetti che inviamo nel comando.

Infine, abbiamo esplorato alcuni utilizzi avanzati, come il recupero del riepilogo della rete e il flooding della rete.

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.