Guida operativa basata su un caso verificato. Finestra di permanenza della blacklist estesa a 720 ore con verifica degli scadenzari e della coerenza dei record DNS.
Cosa cambiava
Una blacklist basata su eventi temporali tratteneva gli indirizzi per 24 ore. L'obiettivo era applicare una finestra mobile di 30 giorni, mantenendo lo storico e senza ripartire da una lista vuota.
Conversione temporale
# 30 giorni espressi in ore
LIST_HOURS=$((24 * 30))
echo "$LIST_HOURS" # 720È importante distinguere fra scadenza fissa e scadenza mobile: in una politica sliding, una nuova osservazione può spostare in avanti l’istante di scadenza.
Aggiornamento controllato
La nuova configurazione è stata applicata al processo che calcola le scadenze. Sono stati aggiornati gli elementi esistenti senza perdere lo storico: oltre 178 mila righe avevano durata minima e massima di 720 ore dopo la modifica.
Verifiche di consistenza
Il controllo finale ha mostrato min_hours=max_hours=720, nessuna scadenza immediata inattesa dall'expirer e corrispondenza fra il database reputazionale e i record DNS pubblicati. Lo storico è rimasto disponibile per ulteriori indagini.
Controlli operativi
systemctl list-timers --all | grep -Ei 'expire|reputation|dnsbl'
journalctl -u NOME_EXPIRER -n 100 --no-pager
date -uVerificare timezone, timestamp UTC e politica di aggiornamento dell’ultima osservazione: errori su queste variabili possono far scadere in blocco migliaia di record.
Prevenzione
Prima di cambiare la durata di un blocco automatizzato, misurare anche il rischio di falsi positivi e l'impatto sulle utenze legittime. Conservarne una traccia verificabile.
Approfondimenti correlati
Comandi e percorsi riportano segnaposto generici; verificare versioni e backup prima di applicarli in produzione.