Analizzare i pacchetti scartati su Sophos Firewall

Quando Sophos Firewall scarta pacchetti, non è automaticamente un errore. Spesso è esattamente la decisione di sicurezza desiderata: una regola non si applica, una policy blocca, un pacchetto non appartiene a una connessione conosciuta o un modulo come Webfilter, IPS o Application Control interviene.

Diventa complicato quando un servizio non funziona e non è chiaro se la firewall blocca, se il traffico non arriva affatto o se il traffico di ritorno segue un altro percorso. In tal caso, è necessaria una sequenza ordinata: prima Log Viewer, poi Packet Capture, quindi, se necessario, log di servizio o CLI.

Per il matching generale delle regole, consulta Testare le regole del firewall con Log Viewer, Policy Test e Packet Capture. Questo articolo si concentra sui drop e sui pacchetti scartati.

Quale articolo di troubleshooting è adatto?

Non tutti i problemi di connessione sono problemi di drop. A seconda dell’osservazione, un altro punto di partenza può essere più rapido:

• Nel Log Viewer o Packet Capture è visibile un drop, Invalid traffic, Violation o Firewall ID 0: Questo articolo.
• Una regola firewall attesa non viene colpita: Verificare le cause per cui una regola Sophos Firewall non si applica.
• Una regola deve essere validata dopo una modifica: Testare le regole del firewall con Log Viewer e Packet Capture.
• I pacchetti devono essere controllati nel WebAdmin con un filtro stretto: Utilizzare Packet Capture nel WebAdmin di Sophos Firewall.
• Il WebAdmin mostra troppo poco e sono necessari i log: Troubleshooting di Sophos Firewall: Servizi e Log.
• I log devono essere conservati più a lungo o correlati centralmente: Inviare i log di Sophos Firewall a SIEM tramite Syslog.
• WebAdmin, SSH, DNS, VPN Portal o SNMP verso la firewall stessa sono interessati: Proteggere l’accesso a Sophos Firewall: Configurare correttamente Device Access.
• Il tunnel IPsec è attivo, ma il traffico non fluisce correttamente: Troubleshooting VPN IPsec di Sophos Firewall.
• Grandi trasferimenti si bloccano o singole applicazioni si interrompono: Verificare MTU e MSS su Sophos Firewall per problemi VPN.

Questa selezione risparmia tempo, poiché non si tratta ogni problema come un errore di regola firewall. Prima di tutto, è necessario chiarire se la firewall vede il traffico, quale regola o modulo decide e se il percorso di ritorno segue effettivamente lo stesso percorso.

Un drop non è sempre un drop

Per l’analisi, è importante distinguere prima di tutto quale tipo di drop si verifica. Altrimenti, si rischia di cercare nel posto sbagliato.

• Drop voluto: La firewall blocca secondo regola, Web Policy, IPS o Threat Feed. Verificare se la policy è corretta dal punto di vista funzionale.
• Drop inatteso: Traffico legittimo viene scartato da una regola o un modulo. Controllare Rule ID, NAT ID, modulo e motivo nel Log Viewer o Packet Capture.
• Nessun drop firewall: Il traffico non raggiunge affatto la firewall o la risposta prende un altro percorso. Verificare client, VLAN, switch, gateway, route, SD-WAN o percorso di ritorno.

Questa classificazione evita eccezioni inutili. Se il drop è voluto, non è necessaria una riparazione tecnica, ma una decisione di policy. Se il traffico non raggiunge affatto la firewall, una nuova regola firewall non aiuterà. Se un modulo di sicurezza blocca, non si dovrebbe creare ciecamente una regola firewall ampia.

Prima classificazione

Prima dell’analisi, è importante restringere il più possibile l’errore.

Domande importanti:

• Quali IP di origine e destinazione sono coinvolti?
• Quale porta e protocollo vengono utilizzati?
• Si tratta di traffico client-Internet, VPN site-to-site, accesso remoto, DNAT, WAF o traffico interno?
• L’errore è permanente o sporadico?
• Riguarda solo un’applicazione, un solo utente o un’intera rete?
• È stata modificata di recente una regola firewall, una regola NAT, una route, una regola SD-WAN, una TLS Inspection o una Web Policy?

Senza queste informazioni, si rischia di cercare troppo ampiamente nel Log Viewer. È meglio un test riproducibile con orario, indirizzi IP e direzione attesa.

Utilizzare correttamente il Log Viewer

Il Log viewer è il primo punto di partenza. Mostra i log degli eventi e può essere filtrato per modulo, tempo, campo e testo libero.

Il Log Viewer si apre in alto a destra nell’interfaccia WebAdmin. Per i drop, a seconda del caso, questi moduli sono importanti:

• Firewall: Matching delle regole, connessioni consentite e scartate.
• Web: Web Policy, categoria, gruppo URL, scansione malware.
• SSL/TLS inspection: Decryption, errori TLS, eccezioni.
• Application filter: Risultati di Application Control.
• IPS: Prevenzione delle intrusioni e decisioni DPI.
• Active threat response: Threat Feeds, NDR Essentials o altri risultati ATR.
• Web server protection: WAF, Reverse Proxy e servizi web pubblicati.
• VPN: Eventi IPsec, SSL VPN e accesso remoto.

Le regole firewall registrano tipicamente le sessioni quando la firewall riceve un evento Destroy e chiude la connessione. Se una connessione termina senza questo evento, potrebbe non apparire sempre come ci si aspetta. Per le connessioni SSL/TLS, la connessione viene registrata dopo l’handshake e alla chiusura.

È importante anche la configurazione del log. Se un tipo di log non è attivato sotto System services > Log settings, non lo si vede in modo affidabile localmente, in Sophos Central o nel Syslog. Per un’analisi a lungo termine, è adatto Inviare i log di Sophos Firewall a SIEM tramite Syslog o Attivare Central Firewall Reporting.

Inquadrare gli eventi Invalid Traffic

Invalid traffic è un’indicazione importante, ma non è ancora un’analisi della causa. La firewall lo segnala quando il traffico non corrisponde correttamente a una connessione valida o a una decisione di policy. Tipici esempi sono pacchetti fuori dallo stato di sessione previsto, percorsi asimmetrici, sessioni scadute, flag TCP inattesi o traffico di ritorno che non passa dallo stesso percorso.

In questi casi non si dovrebbe creare subito una regola Allow. È meglio procedere così:

1. Rilevare source, destination, porta e ora dall’evento.
2. Verificare nel Log Viewer se sono visibili Firewall Rule ID, NAT Rule ID o un modulo.
3. Con Packet Capture controllare se entrambe le direzioni passano dalla stessa firewall.
4. Controllare routing, SD-WAN, percorsi VPN, ruolo HA e rotta di ritorno.
5. Solo dopo decidere se adattare una regola, la logica NAT, una route o un profilo di sicurezza.

Invalid traffic è particolarmente utile come indizio di problemi di stato o di ritorno. Se si amplia solo la regola Allow, la causa reale spesso rimane.

Utilizzare correttamente Packet Capture

Il percorso del menu è:

Diagnostics > Packet capture

Packet Capture mostra se i pacchetti arrivano a un’interfaccia, vengono inoltrati, elaborati dalla firewall stessa o scartati. Questo è particolarmente importante quando nel Log Viewer non appare nulla di chiaro.

Procedura di base:

1. Restringere il caso di test: annotare IP di origine, IP di destinazione, porta e protocollo.
2. Aprire Diagnostics > Packet capture.
3. Impostare il filtro di cattura il più stretto possibile.
4. Attivare Packet Capture.
5. Riprodurre il problema.
6. Fermare la cattura.
7. Controllare le voci per origine, destinazione, Rule ID, NAT ID, stato e motivo.

Packet Capture mostra tra l’altro Rule ID, NAT ID, Status, Reason, Connection ID, Web filter ID, Application ID, IPS policy ID e Username. Questi campi aiutano quando non è coinvolta solo una regola firewall, ma anche Webfilter, IPS, Application Control o NAT.

Per l’uso dello strumento, Utilizzare Packet Capture nel WebAdmin di Sophos Firewall è la guida più dettagliata.

Comprendere lo stato di Packet Capture

I valori di stato sono cruciali per l’analisi. Sophos Firewall offre sei valori di stato nel filtro di visualizzazione: Allowed, Violation, Consumed, Generated, Incoming e Forwarded.

• Incoming: Il pacchetto arriva su un’interfaccia WAN o LAN. La sorgente raggiunge la firewall.
• Allowed: Il pacchetto è stato consentito dalla regola firewall o dalla policy competente. Questo stato si sovrappone spesso a Forwarded nella pratica; se un pacchetto compare come Allowed ma non come Forwarded, vale la pena controllare il routing, il percorso di ritorno o un modulo di sicurezza a valle.
• Forwarded: Il pacchetto viene inoltrato. La firewall lascia passare il pacchetto in linea di principio.
• Consumed: Il pacchetto è destinato alla firewall stessa. Device Access, VPN Portal, DNS, DHCP o altro servizio locale.
• Generated: Il pacchetto è generato dalla firewall. Risposta o traffico di sistema della firewall.
• Violation: Il pacchetto è scartato per una violazione della policy. Regola, modulo o funzione di sicurezza blocca.

Un singolo Incoming senza un corrispondente Forwarded può significare che la firewall scarta il pacchetto, lo elabora da sola o che il filtro non mostra l’intero flusso. Pertanto, si dovrebbero sempre considerare entrambe le direzioni.

Dopo il primo stato, non si dovrebbe creare immediatamente un’eccezione. È meglio derivare il prossimo test dallo stato:

• Solo Incoming visibile: Controllare il filtro, catturare la direzione opposta, cercare Rule ID ed escludere Firewall ID 0.
• Incoming e Forwarded, ma nessuna risposta: Verificare percorso di ritorno, sistema di destinazione, firewall locale del server, NAT e routing asimmetrico.
• Consumed visibile: Verificare Device Access, Local service ACL e servizio firewall locale interessato.
• Generated visibile: Verificare se la firewall risponde da sola o genera traffico di sistema.
• Violation visibile: Confrontare motivo, Rule ID, NAT ID e modulo interessato nel Log Viewer.

In questo modo, l’analisi rimane riproducibile: lo stato decide quale strumento è più utile successivamente. In caso di Violation, il Log Viewer è importante, in caso di risposta mancante è meglio controllare il percorso di ritorno e Packet Capture, in caso di Consumed Device Access invece della regola firewall.

Triage rapido dei sintomi

Nella pratica, una breve tabella dei sintomi fa risparmiare tempo prima di approfondire log o shell:

• Log Viewer mostra Invalid traffic: Stato della sessione, percorso di ritorno, routing asimmetrico. Controllare entrambe le direzioni con Packet Capture.
• Packet Capture mostra solo Incoming: Drop, servizio locale, regola predefinita o filtro incompleto. Ampliare il filtro, eseguire Policy Test, controllare Firewall ID 0.
• Packet Capture mostra Forwarded, ma nessuna risposta: Sistema di destinazione, rotta di ritorno, NAT, firewall esterno. Controllare pacchetti di risposta e percorso di ritorno.
• Packet Capture mostra Consumed: Traffico verso la firewall stessa. Controllare Device Access e Local service ACL.
• Packet Capture mostra Violation: Regola, modulo di sicurezza o violazione di policy. Confrontare Reason, Rule ID, NAT ID e log del modulo.
• Log Viewer e Packet Capture non mostrano nulla: Il traffico non raggiunge la firewall. Controllare client, VLAN, switch, gateway o obiettivo di test errato.

Firewall ID 0 e regola Drop esplicita

Se nessuna regola firewall esplicita corrisponde, Sophos Firewall scarta il traffico tramite la regola finale integrata con Firewall ID 0 o Policy ID 0. Questa regola si trova sempre alla fine delle regole firewall. Importante per troubleshooting e SIEM: la regola Drop-all integrata non logga il traffico autonomamente. Chi vuole vedere tutte le connessioni scartate in modo tracciabile ha quindi bisogno di una propria regola Drop esplicita con logging attivo.

Se i drop tramite la regola predefinita non sono visibili, la decisione di policy non è automaticamente errata. In Packet Capture si può vedere solo Incoming, senza una voce Violation Firewall corrispondente. Il problema è quindi la tracciabilità nel troubleshooting, non necessariamente la decisione effettiva di drop.

Se un caso di test non corrisponde a nessuna regola e comunque non appare alcun drop, si dovrebbe quindi controllare ulteriormente:

1. Utilizzare Policy Test e controllare se il test cade su Firewall ID 0 o sulla regola predefinita.
2. Controllare l’ordine delle regole e assicurarsi che nessun’altra regola più in alto corrisponda inaspettatamente.
3. Creare alla fine della base regole una regola Drop esplicita se i drop devono essere loggati o inoltrati a Central Reporting o Syslog.
4. Ripetere il test e verificare se il drop è ora visibile con l’ID della regola esplicita.
5. Includere la regola di drop esplicita nella documentazione delle modifiche e nella revisione delle regole, in modo che non venga successivamente fraintesa come una normale regola Allow/Deny.

Quando si crea la regola finale, le zone devono essere scelte consapevolmente. Sophos consiglia di usare singole Source e Destination Zones e non impostare genericamente Any come zona, per non influenzare inutilmente servizi interni. Per un ambiente revisionabile, la regola finale esplicita è utile. Non sostituisce però una struttura di regole pulita. Se molto traffico legittimo finisce sulla regola finale, probabilmente manca una regola consentente più precisa più in alto o una rete è classificata erroneamente.

Leggere i campi importanti in Packet Capture

Per i drop, non è importante solo lo stato. I campi aggiuntivi mostrano quale parte della firewall ha elaborato il traffico.

• Rule ID: Regola firewall corrispondente. Corrisponde alla regola attesa?
• NAT ID: Regola NAT corrispondente. NAT è atteso, manca NAT o si applica una regola NAT errata?
• Reason: Motivo per il drop o la violazione. Non leggere isolatamente, ma confrontare con stato e modulo.
• Web filter ID: Decisione della Web Policy. Controllare categoria, gruppo URL e contesto utente.
• Application ID: Applicazione riconosciuta. Application Control può decidere diversamente da quanto suggerisce la porta.
• IPS policy ID: Policy IPS applicata. Controllare firma, contesto della regola e rischio di false positive.
• Username: Utente riconosciuto. Valutare User Matching solo se l’utente è veramente visibile.

Se Rule ID o NAT ID sono inaspettati, non si dovrebbe creare immediatamente un’eccezione. Prima di tutto, è necessario chiarire se il caso di test era definito correttamente, se una regola più generale più in alto corrisponde o se NAT altera la visibilità su origine e destinazione.

Usare Reason come indicatore

Il valore Reason non è un report completo della root cause, ma è un buon indicatore del modulo successivo da controllare. Firewall indica più probabilmente rule base, regola predefinita o logica delle zone. LOCAL_ACL rimanda a Device Access e Local service ACL. INVALID_TRAFFIC suggerisce stato della sessione, percorso di ritorno o routing asimmetrico. APPLICATION_FILTER, IPS, USER_IDENTITY, IP_SPOOF, SSL_VPN_ACL_VIOLATION o VIRTUAL_HOST indicano che non bisogna controllare solo la regola firewall.

È quindi utile una breve sequenza in tre passi: prima leggere Status, poi classificare Reason, quindi aprire il modulo adatto nel Log Viewer. Così una singola voce Violation diventa un percorso di verifica tracciabile invece di un invito a creare un’eccezione ampia.

Consumed e servizi firewall locali

Consumed non è un drop normale. Lo stato significa che il pacchetto è destinato alla firewall stessa. Destinazioni tipiche sono WebAdmin, User Portal, VPN Portal, SSH, DNS, DHCP, IPsec, SSL VPN o SNMP.

In tali casi, spesso non è decisiva la normale regola firewall, ma Device Access e Local service ACL. Se, ad esempio, WebAdmin, SSH, VPN Portal o SNMP non sono raggiungibili, non si dovrebbe cercare solo sotto Rules and policies > Firewall rules. Il punto di partenza corretto è spesso Administration > Device access.

Per il rafforzamento e il troubleshooting dei servizi firewall locali, consulta Proteggere l’accesso a Sophos Firewall: Configurare correttamente Device Access.

Cause comuni di drop

Nessuna regola firewall corrispondente

La causa più comune è una regola che non corrisponde. I motivi possono essere:

• zona di origine errata
• rete di origine errata
• zona di destinazione errata
• IP di destinazione interpretato erroneamente in caso di DNAT
• servizio mancante o protocollo errato
• utente non autenticato
• pianificazione non corrispondente
• una regola più specifica si trova sotto una regola più generale

Per la struttura delle regole, consulta Comprendere e configurare correttamente le regole di Sophos Firewall. Se è coinvolto DNAT, dovrebbe essere controllato anche Pubblicare server tramite DNAT su Sophos Firewall.

NAT o percorso di ritorno non corrispondente

A volte la firewall consente il percorso di andata, ma la risposta ritorna in modo diverso o viene tradotta erroneamente.

Punti tipici:

• SNAT o MASQ mancante.
• DNAT punta all’host interno sbagliato.
• Una regola NAT collegata è stata disattivata.
• Percorso di ritorno mancante.
• SD-WAN o routing statico invia il traffico di risposta su un altro percorso.
• Per il traffico VPN manca una route IPsec o un percorso di ritorno adeguato.

Il routing asimmetrico genera spesso errori difficili da comprendere, poiché la firewall non può assegnare correttamente lo stato della connessione. In tal caso, i pacchetti possono apparire come non appartenenti alla connessione.

Il pacchetto non appartiene a una connessione conosciuta

Messaggi come Could not associate packet to any connection o simili indicazioni di Conntrack significano spesso che la firewall non trova un oggetto di contesto di connessione corrispondente.

Possibili cause:

• Il traffico di ritorno segue un altro percorso.
• La connessione è stata stabilita su un altro nodo HA.
• La sessione è già scaduta.
• I flag TCP non corrispondono alla connessione attesa.
• Un dispositivo invia risposte senza una richiesta precedente.
• L’ispezione stateful vede solo una parte del flusso di dati.

In questo caso, Packet Capture è più importante di una singola voce di log. È necessario vedere se entrambe le direzioni passano attraverso la stessa firewall e la stessa zona.

Webfilter, TLS Inspection, Application Control o IPS bloccato

Non tutti i drop provengono dalla regola firewall stessa. Spesso il traffico è consentito, ma poi bloccato da un modulo di sicurezza.

Esempi tipici:

• Web Policy blocca una categoria o un gruppo URL.
• TLS Inspection si interrompe a causa di certificato, SNI, cifrario o eccezione.
• Application Control riconosce un’applicazione indesiderata.
• IPS blocca un modello.
• Active Threat Response incontra un IoC.
• Zero-Day Protection trattiene un download o lo blocca.

In caso di risultati IPS, si dovrebbe controllare firma, policy e contesto della regola prima di impostare un’eccezione ampia. La procedura corretta è descritta in Configurare e testare in sicurezza IPS su Sophos Firewall.

In caso di problemi Web e TLS, si dovrebbe anche controllare QUIC. Se i browser evitano tramite UDP 443, le aspettative di Webfilter e TLS non sempre corrispondono. Maggiori dettagli: Bloccare correttamente il protocollo QUIC e HTTP/3 su Sophos Firewall.

MTU, MSS o frammentazione

In caso di VPN, PPPoE, SD-WAN, rete mobile o tunnel annidati, un pacchetto può essere troppo grande per il percorso. In tal caso, non si vede sempre un chiaro drop firewall, ma piuttosto interruzioni di connessione, applicazioni lente o singoli servizi che si bloccano.

Per tali casi, consulta Verificare MTU e MSS su Sophos Firewall per problemi VPN.

Procedura strutturata

Per la pratica, questa sequenza funziona bene:

1. Annotare il caso di test: Origine, destinazione, porta, protocollo, orario.
2. Controllare Log Viewer: Filtrare modulo firewall e moduli di sicurezza pertinenti.
3. Cercare Rule ID e NAT ID: Verificare quale regola è stata effettivamente colpita.
4. Avviare Packet Capture: Impostare un filtro stretto e riprodurre il test.
5. Controllare lo stato: Valutare Incoming, Forwarded, Consumed, Generated o Violation.
6. Controllare la direzione di ritorno: La risposta ritorna e segue lo stesso percorso?
7. Controllare i moduli di sicurezza: Web, TLS, Application Control, IPS, ATR, WAF.
8. Controllare i log di servizio: In caso di problemi di servizio, controllare il file di log pertinente sotto /log.
9. Controllare i log centrali: Includere Central Reporting o SIEM se i log locali non sono sufficienti.

I file di log e di servizio pertinenti sono riassunti in Troubleshooting di Sophos Firewall: Servizi e Log.

Quando nel Log Viewer non appare nulla

Nessuna voce di log non significa automaticamente che la firewall non è coinvolta.

Possibili cause:

• Il logging non è attivato nella regola firewall.
• Il tipo di log rilevante non è attivo sotto System services > Log settings.
• La connessione non è stata terminata correttamente e quindi non è stata registrata.
• Il traffico non raggiunge affatto la firewall.
• Il traffico è elaborato da un servizio locale.
• Il filtro nel Log Viewer è troppo stretto.
• Lo spazio di archiviazione dei log è limitato o le voci vecchie sono già state sovrascritte.

In tali casi, utilizzare prima Packet Capture. Se anche Packet Capture non mostra alcun ingresso, il focus è più su client, switch, VLAN, routing prima della firewall o obiettivo di test errato.

Quando tcpdump o archivi di log sono necessari

Il Packet Capture di WebAdmin è utile per analisi rapide. Per catture più lunghe, file PCAP, filtri molto precisi o casi di supporto, tcpdump tramite SSH è spesso più adatto. Questo è particolarmente vero se un problema si verifica solo sporadicamente o se la cattura deve essere analizzata successivamente in Wireshark o dal supporto Sophos.

Per tali casi, si dovrebbe chiarire prima della cattura:

• Quali IP di origine, IP di destinazione e porte devono essere nel filtro?
• Quanto tempo può durare la cattura?
• Dove verrà salvato il file PCAP?
• Chi può vedere il file?
• Quando verrà eliminato il file dopo l’analisi?

La procedura pratica è descritta in Sophos Firewall tcpdump: Catturare pacchetti tramite CLI. Se oltre ai pacchetti sono necessari anche i log di servizio, consulta Salvare i log di Sophos Firewall per supporto e analisi.

Impostare eccezioni solo in modo mirato

In caso di drop, la tentazione è grande di creare rapidamente un’eccezione. Questo può aiutare a breve termine, ma spesso peggiora la sicurezza o nasconde la causa.

Le eccezioni dovrebbero essere impostate solo se è chiaro:

• quale modulo blocca
• quale host, dominio o applicazione è interessato
• perché il traffico è legittimo
• quanto stretta può essere l’eccezione
• quando l’eccezione verrà rivista o rimossa

Le eccezioni ampie per intere reti, regole Any o eccezioni TLS globali dovrebbero essere evitate. È meglio un’eccezione piccola e documentata con una data di revisione.

Documentare il risultato

Un buon risultato di drop deve essere documentato in modo che un’altra persona possa riprodurre il test. Questo è importante per revisioni interne, documentazione delle modifiche e casi di supporto.

Annotare almeno:

• Data, ora e fuso orario del test.
• IP di origine, IP di destinazione, porta, protocollo e utente.
• Regola firewall attesa e Rule ID effettivamente visibile.
• Regola NAT attesa e NAT ID effettivamente visibile.
• Stato di Packet Capture: Allowed, Incoming, Forwarded, Consumed, Generated o Violation.
• Motivo o messaggio del modulo rilevante.
• Modifica effettuata o consapevolmente nessuna modifica.
• Se è stata impostata un’eccezione: proprietario, scopo, validità e data di revisione.

Questa documentazione impedisce che un passo di troubleshooting temporaneo diventi una lacuna di sicurezza permanente e poco chiara.

Checklist

• IP di origine, IP di destinazione, porta e protocollo noti.
• Ora del test documentata.
• Log Viewer controllato con modulo e filtro temporale corretti.
• Rule ID e NAT ID valutati.
• In caso di mancanza di voce di drop, controllato se Firewall ID 0 o la regola predefinita è interessata.
• Regola firewall e ordine delle regole controllati.
• Regola NAT e percorso di ritorno controllati.
• Packet Capture eseguito con filtro stretto.
• Stato e motivo valutati in Packet Capture.
• Direzione di andata e ritorno controllate.
• Webfilter, TLS Inspection, Application Control, IPS e Active Threat Response controllati.
• In caso di VPN, MTU, MSS e route controllati.
• In caso di DNAT o WAF, host di destinazione, indirizzo ospitato e backend controllati.
• Log centrali o Syslog controllati se i log locali non sono sufficienti.
• In caso di necessità di supporto, tcpdump o archivio di log preparati in modo mirato.
• Eccezioni impostate solo in modo stretto e documentato.
• Risultato documentato con Rule ID, NAT ID, stato, motivo e modifica.

Domande frequenti