Aumentare la visibilità dei server DNS Linux con la log collection

Benvenuti nella quarta parte di questa serie di articoli su DNS e domain logging con DomainTools, lo scopo di questo post è concentrarsi sulla Log Collection su Linux e altre piattaforme simili a Unix; sebbene gli ambienti aziendali oggigiorno siano ibridi, piuttosto che completamente omogenei, utilizzeremo questo post per concentrarci su un altro standard di eventi di telemetria: syslog daemon (syslogd) e Syslog message logging.

Questo post inizierà con un esempio di log collection deployment su un server DNS Linux, seguito da una breve panoramica del significato di questi esempi di sorgenti di log e quindi terminerà con l’auditing di Linux. Se si sta lavorando con Windows Event Log di Microsoft, consulta la parte 3 di questa serie, consigliamo inoltre la lettura del primo e del secondo post della serie.

Linux Log Deployment Scenario
Elenco di server DNS che supportano piattaforme Linux/Unix-like:

From Source to SIEM

Aumenta la visibilità dei server DNS Linux con la Log Collection

Di seguito è riportato un esempio di deployment di un server DNS Linux, con un’origine dell’infrastruttura: il BIND9 DNS Server.

From Source (BIND9 DNS Server e auditd Events)

Aumenta la visibilità dei server DNS Linux con la Log Collection

A partire da un BIND9 DNS Server, vengono definite due source principali di telemetria: Auditing Logging Rule e DNS Server Configuration FIle che vengono utilizzati per definire una varietà di regole di logging.

Esempio Source 1: Audit Logging Rules
Questi definiscono le regole per la collection degli auditing log, che possono informare potenziali attacchi all’infrastruttura come modifiche non autorizzate alla configurazione del server DNS. Le modifiche alle autorizzazioni di file o cartelle di attacco nel file di configurazione, l’eliminazione dei log e la disabilitazione del logging sono altre forme di attacchi all’infrastruttura. La mancanza di visibilità di questi eventi costituisce il terreno fertile per gli attacchi di movimento laterale, originati dal server DNS e da altre infrastrutture associate.

Esempio Source 2: DNS Server Configuration FIle
Una parte del file di configurazione del server DNS copre i criteri di logging del server, come ad esempio:

  1. I tipi di eventi DNS da loggare (query only, query e risposta)
  2. Quanto sono dettagliati gli eventi (ad esempio verbose)
  3. I tipi di eventi da raccogliere (come solo eventi warning o tutti gli eventi che vanno da quelli Informational a Warning)

Gli attuali criteri di logging e la configurazione, differiranno per ciascuna implementazione del server DNS. Per BIND9, ecco un esempio di grammatica delle istruzioni di logging dal loro manuale utente:

logging {
  category string { string; ... };
  channel string {
    buffered boolean;
    file quoted_string [ versions ( unlimited | integer ) ]
         [ size size ] [ suffix ( increment | timestamp ) ];
    null;
    print-category boolean;
    print-severity boolean;
    print-time ( iso8601 | iso8601-utc | local | boolean );
    severity log_severity;
    stderr;
    syslog [ syslog_facility ];
  };
};

 

To SIEM

Aumenta la visibilità dei server DNS Linux con la Log Collection

All’interno del file di configurazione BIND9 DNS, è possibile specificare determinati eventi da scrivere su disco o da inviare tramite flusso TCP/UDP direttamente a un server di gestione dei log. Nel server DNS BIND9, questo è definito nella parte del canale del file di configurazione. Questo informa la destinazione dei messaggi selezionati per il canale: per andare a un file, a una particolare funzione syslog, al flusso di errore standard (stderr) o a null (scartato). Gli eventi in questo esempio di distribuzione, solo gli eventi di sicurezza, vengono inviati al flusso Syslog e scritti su disco (/var/log/security_events.log).

Gli eventi dovrebbero essere scritti in un formato standard. Esistono vari modi per scrivere e trasportare i dati degli eventi. Per Syslog, questi sono BSD Syslog, IETF (implementazione che precede BSD) Syslog, CEF (o Common Event Format, un’implementazione ArcSight), LEEF (Log Event Extended Format, un formato proprietario in relazione a IBM QRadar), Snare Syslog. Esistono anche altri formati accettati, come JSON.

Il modo appropriato per arricchire e scrivere eventi è descritto in dettaglio nella documentazione del proprio SIEM e del Log Collector. Indipendentemente da ciò, l’arricchimento avviene come parte del processo di raccolta dei log sul server DNS e nell’istanza del server di centralizzazione dei log a seconda dei requisiti di distribuzione. Potenzialmente sul SIEM, gli eventi possono essere consumati e presentati come eventi “raw” se non sono stati correttamente arricchiti. Potrebbero esserci anche regole aggiuntive per instradare questi log poiché non tutti potrebbero avere un valore di sicurezza immediato, come i log a scopo di debug.

Dal lato SIEM, è necessario lavorare ulteriormente per arricchire i log per l’analisi, le regole di automazione e altro ancora. Ad esempio, deve essere chiaro che esiste una coppia chiave-valore per i metadati del dominio poiché costituisce la base per DomainTools App for Splunk e l’origine dei metadati dovrebbe essere rilevante indipendentemente dall’origine della piattaforma.

Esempio di BINDDNS Server Event

Informazioni su BIND9 DNS Server

BIND9 è un software open source DNS ampiamente utilizzato, BIND9 è attualmente mantenuto dall’ISC (Internet Systems Consortium). Il software BIND9 include un Domain Name Resolver che risolve le query sui nomi comunicandole ai server appropriati e rispondendo alle replies dei server. Il BIND9 Domain Name Authority server, risponde alle richieste dei resolver. Di seguito è riportato un esempio dal Resolver.

Esempio BIND9 named.conf
I file di configurazione per il logging di BIND9 coprono come, cosa e dove. Di seguito è riportato un esempio per il logging delle query in un file.

logging {
        channel query {
                file "/var/log/queries.log";
                print-severity yes;
                print-time yes;
        };
       category queries { query };
};

Snippet del resolver BIND9 DNS
Come messaggio di log semistrutturato, di seguito è riportato un log di esempio da un ambiente di test per query example.com:

30-May-2020 11:11:11.553613 queries: info: client @0x7f39604b8660 127.0.0.1#50587 (example.com): query: example.com IN A +E(0)K (127.0.0.1)

Sebbene quanto sopra sia leggibile dall’uomo, non è necessariamente consumabile nel proprio SIEM e può essere presentato come un log non elaborato e non utilizzabile per ulteriori elaborazioni. Con il parsing e l’arricchimento in corso, il messaggio non strutturato viene suddiviso in questo tipo di coppia valore-chiave:

EventTime: 2020-05-30T11:11:11.533613+01:00
Category: queries
Severity: info
Client: 127.0.0.1#50587
Address: 127.0.0.1
Query: example.com
Type: A
Class: IN
Flags: +E(0)K

Pertanto, i metadati che risiedono in campi importanti, come nel campo Query, hanno valore per un’ulteriore elaborazione. Ad esempio, una delle integrazioni DomainTools ruota attorno alla capacità di elaborare domini che sorgono all’interno del perimetro della rete. In tal caso, si desidera che ogni query venga elaborata come parte di questo lavoro poiché, dopo tutto, fa parte di un evento che si è verificato nel perimetro. Inoltre, si potrebbe notare che il timestamp dell’evento è già impostato per accedere a timestamp ad alta precisione e non solo, EventTime è nello standard ISO8601, con millisecondi e fuso orario aggiunti alla fine (UTC+01:00), per garantire coerenza e precisione nei timestamp.

Linux DNS Audit Logging
Applicare l’audit logging al proprio server DNS per tenere traccia degli eventi rilevanti per la sicurezza. L’applicazione delle regole di logging dei controlli, consente di tenere traccia di eventi di sicurezza più mirati. Sapere di più sul sistema di controllo nella propria piattaforma è utile quando si impostano le regole di logging dell’audit e si leggono gli eventi, di seguito è riportato un esempio.

Esempio BIND9 Linux Audit Logging:
Si consiglia di consultare la documentazione della propria piattaforma per le auditing rules (se non se ne ha una a portata di mano, è possibile fare riferimento alla  RHEL documentation on Linux Audit Logs).

Per guardare /etc/bind/ per le modifiche e aggiungere un tag:

-w /etc/bind/named.conf -p wa -k conf-change-bind9

Lo snippet del risultato nel formato delle coppie chiave-valore (non raw log):

type: CONFIG_CHANGE
UID: 0
comm: nano
exe: /bin/nano
Key: conf-change-bind9
EventTime: 2020-05-30T12:19:20.055718+01:00

Viene aggiunta una regola per controllare /etc/bind per creare i log in caso di accesso in scrittura e ogni modifica di attributo del file named.conf nel server BIND9. Quando questo viene osservato, viene registrato un log con il tag conf-change-bind9.

Lo snippet del risultato dovrebbe essere leggibile dagli utenti. CONFIG_CHANGE è il tipo di record di audit osservato. Il codice uid, che è 0, indica che era un account di superuser che ha modificato il file di configurazione con l’editor nano (e invocando il comando nano).

Quando è impostata l’audit logging per questi e altri eventi, l’amministratore può fare riferimento alla documentazione della propria piattaforma per leggere le regole di audit. Si può anche osservare il trail dei log di audit; ad esempio, possono vedere quale utilità è stata utilizzata per modificare il file di configurazione.

Domande finali
Con questo post, abbiamo presentato un esempio di deployment di una collection di log BIND9 DNS su una piattaforma Linux/Unix like, con un evento di esempio e, sia un evento resolver che un evento di auditing di una modifica alla configurazione del server. Sentiti libero di tornare all’inizio e verificare se la tua distribuzione ha coperto quanto segue:

  1. Quali informazioni di monitoraggio su DNS e domain activity possono essere ottenute dalle source esistenti?
  2. Quali aree devono essere ampliate per migliorare la visibilità dei log, in particolare per i metadati contenenti log di dominio e DNS?
  3. Quali altre opportunità ci sono per aumentare l’ambito complessivo della raccolta dei log?
  4. Quale di queste source porta a una migliore intelligenza per i tuoi casi d’uso?
  5. L’attuale log deployment soddisfa le esigenze della fase finale in termini di informazioni per la threat hunting, incidence response, orchestration, automation, ecc.

Sebbene non sia possibile approfondire i dettagli del deployment effettivo (come più esempi di configurazione, logging DNSSEC e altro), è possibile controllare la documentazione della piattaforma e del server DNS, nonché il proprio Collector e la documentazione SIEM, per vedere quali configurazioni devono essere applicate e quali opzioni sono disponibili.

Utilizza le integrazioni e le API di DomainTools per arricchire ulteriormente gli eventi rilevanti con DNS e domain intelligence (Domain Risk Score), oltre a utilizzare gli IOC di dominio con la piattaforma Iris. Usa DomainTools come parte della tua difesa proattiva e reattiva, oltre al logging mirato.

Foto di Green Pass digitali e stampati fornite dai venditori ai loro acquirenti.

PUBBLICATO DA:<br>Domenico Panetta
PUBBLICATO DA:
Domenico Panetta
Presales Technical Engineer

ARTICOLI CORRELATI

Netwrix acquisisce PolicyPak, sicurezza ai desktop

Netwrix acquisisce PolicyPak, sicurezza ai desktop

I Clienti PolicyPak avranno accesso al portafoglio Netwrix di soluzioni di sicurezza e conformità, per identificare e mitigare i rischi per la sicurezza dei dati Netwrix acquisisce PolicyPak, produttore di software che aiuta le organizzazioni di tutte le dimensioni a...