Problemi noti e limitazioni di YARA-L
Questo documento descrive i problemi noti e le limitazioni di YARA-L.
Aggregazioni di risultati con annullamento della nidificazione dei campi ripetuti
Quando una regola fa riferimento a un campo ripetuto in una variabile evento con più elementi, ogni elemento viene suddiviso in una riga evento separata.
Ad esempio, i due indirizzi IP nel campo ripetuto target.ip nell'evento $e sono suddivisi in due istanze di $e, ciascuna con un valore target.ip diverso.
rule outbound_ip_per_app {
meta:
events:
$e.principal.application = $app
match:
$app over 10m
outcome:
$outbound_ip_count = count($e.target.ip) // yields 2.
condition:
$e
}
Record evento prima dell'estrazione dal nido del campo ripetuto
La tabella seguente mostra il record dell'evento prima di annullare l'annidamento del campo ripetuto:
| metadata.id | principal.application | target.ip |
|---|---|---|
aaaaaaaaa |
Google SecOps |
[192.0.2.20, 192.0.2.28] |
Record di eventi dopo lo snidamento del campo ripetuto
La tabella seguente mostra il record dell'evento dopo lo snidificazione del campo ripetuto:
| metadata.id | principal.application | target.ip |
|---|---|---|
aaaaaaaaa |
Google SecOps |
192.0.2.20 |
aaaaaaaaa |
Google SecOps |
192.0.2.28 |
Quando una regola fa riferimento a un campo ripetuto nidificato in un altro, come security_results.action, l'annullamento del nidificazione avviene sia a livello di elemento principale che secondario. Le istanze risultanti dall'estrazione di un singolo evento formano un prodotto cartesiano degli elementi nei campi principale e secondario.
Nella seguente regola di esempio, l'evento $e con due valori ripetuti in security_results e due valori ripetuti in security_results.actions vengono espulsi da quattro istanze.
rule security_action_per_app {
meta:
events:
$e.principal.application = $app
match:
$app over 10m
outcome:
$security_action_count = count($e.security_results.actions) // yields 4.
condition:
$e
}
Record evento prima dell'estrazione dal nido del campo ripetuto
La tabella seguente mostra il record dell'evento prima di annullare l'annidamento del campo ripetuto:
| metadata.id | principal.application | security_results |
|---|---|---|
aaaaaaaaa |
Google SecOps |
[ { actions: [ ALLOW, FAIL ] }, { actions: [ CHALLENGE, BLOCK ] } ] |
Record di eventi dopo l'estrazione da un insieme nidificato di campi
La tabella seguente mostra il record dell'evento dopo lo snidificazione del campo ripetuto:
| metadata.id | principal.application | security_results.actions |
|---|---|---|
aaaaaaaaa |
Google SecOps |
CONSENTI |
aaaaaaaaa |
Google SecOps |
FAIL |
aaaaaaaaa |
Google SecOps |
SFIDA |
aaaaaaaaa |
Google SecOps |
BLOCCO |
Questo comportamento di estrazione dalla nidificazione nella valutazione delle regole può produrre aggregazioni di risultati impreviste quando la regola fa riferimento a uno o più campi ripetuti con un campo principale che è anche un campo ripetuto. Le aggregazioni non distinte come sum(), array() e count() non possono tenere conto dei valori duplicati in altri campi dello stesso evento prodotto dal comportamento di estrazione dal nido. Nella regola di esempio riportata di seguito, l'evento $e ha un singolo nome host google.com, ma il risultato hostnames viene aggregato su quattro istanze non nidificate dello stesso evento $e, ciascuna con un valore principal.hostname duplicato. Questo risultato genera quattro nomi host anziché uno
a causa dello snidamento dei valori ripetuti in security_results.actions.
rule security_action_per_app {
meta:
events:
$e.principal.application = $app
match:
$app over 10m
outcome:
$hostnames = array($e.principal.hostname) // yields 4.
$security_action_count = count($e.security_results.action) // yields 4.
condition:
$e
}
Record evento prima dell'estrazione dal nido del campo ripetuto
La tabella seguente mostra il record dell'evento prima di annullare l'annidamento del campo ripetuto:
| metadata.id | principal.application | principal.hostname | security_results |
|---|---|---|---|
aaaaaaaaa |
Google SecOps |
google.com |
[ { action: [ ALLOW, FAIL ] }, { action: [ CHALLENGE, BLOCK ] } ] |
Record evento dopo l'estrazione dal nido di campi ripetuti
La tabella seguente mostra il record dell'evento dopo lo snidificazione del campo ripetuto:
| metadata.id | principal.application | principal.hostname | security_results.action |
|---|---|---|---|
aaaaaaaaa |
Google SecOps |
google.com |
CONSENTI |
aaaaaaaaa |
Google SecOps |
google.com |
FAIL |
aaaaaaaaa |
Google SecOps |
google.com |
SFIDA |
aaaaaaaaa |
Google SecOps |
google.com |
BLOCCO |
Soluzione
Le aggregazioni che ignorano o eliminano i valori duplicati non sono interessate da questo comportamento di estrazione dal nido. Utilizza la versione distinta di un'aggregazione se riscontri valori di risultati imprevisti a causa del disaccoppiamento.
Le seguenti aggregazioni non sono interessate dal comportamento di estrazione descritto in precedenza.
max()min()array_distinct()count_distinct()
Aggregazioni di risultati con più variabili evento
Se una regola contiene più variabili evento, nell'aggregazione è presente un elemento separato per ogni combinazione di eventi inclusa nel rilevamento. Ad esempio, se la seguente regola di esempio viene eseguita sugli eventi elencati:
events:
$e1.field = $e2.field
$e2.somefield = $ph
match:
$ph over 1h
outcome:
$some_outcome = sum(if($e1.otherfield = "value", 1, 0))
condition:
$e1 and $e2
event1:
// UDM event 1
field="a"
somefield="d"
event2:
// UDM event 2
field="b"
somefield="d"
event3:
// UDM event 3
field="c"
somefield="d"
La somma viene calcolata su ogni combinazione di eventi, consentendoti di utilizzare entrambe le variabili evento nei calcoli del valore del risultato. Nel calcolo vengono utilizzati i seguenti elementi:
1: $e1 = event1, $e2 = event2
2: $e1 = event1, $e2 = event3
3: $e1 = event2, $e2 = event1
4: $e1 = event2, $e2 = event3
5: $e1 = event3, $e2 = event1
5: $e1 = event3, $e2 = event2
Il risultato è una potenziale somma massima di 6, anche se $e2 può corrispondere solo a 3 eventi distinti.
Questo influisce su somma, conteggio e array. Per conteggio e array, l'utilizzo di count_distinct
o array_distinct può risolvere il problema, ma non esiste una soluzione alternativa per la somma.
Parentesi all'inizio di un'espressione
L'utilizzo di parentesi all'inizio di un'espressione attiva il seguente errore:
parsing: error with token: ")"
invalid operator in events predicate
Il seguente esempio genererebbe questo tipo di errore:
($event.metadata.ingested_timestamp.seconds -
$event.metadata.event_timestamp.seconds) / 3600 > 1
Le seguenti varianti di sintassi restituiscono lo stesso risultato, ma con una sintassi valida:
$event.metadata.ingested_timestamp.seconds / 3600 -
$event.metadata.event_timestamp.seconds / 3600 > 1
1 / 3600 * ($event.metadata.ingested_timestamp.seconds -
$event.metadata.event_timestamp.seconds) > 1
1 < ($event.metadata.ingested_timestamp.seconds -
$event.metadata.event_timestamp.seconds) / 3600
L'array di indici nell'esito richiede l'aggregazione per i singoli valori nel campo ripetuto
L'indicizzazione dell'array nella sezione dei risultati richiede ancora l'aggregazione. Ad esempio, quanto segue non funziona:
outcome:
$principal_user_dept = $suspicious.principal.user.department[0]
Tuttavia, puoi salvare l'output dell'indice dell'array in una variabile segnaposto e utilizzarla nella sezione relativa al risultato, come mostrato di seguito:
events:
$principal_user_dept = $suspicious.principal.user.department[0]
outcome:
$principal_user_department = $principal_user_dept
Condizione OR con assenza
Se viene applicata una condizione OR tra due variabili evento distinte e se la regola corrisponde a una condizione di non esistenza, la regola viene compilata correttamente, ma può produrre rilevamenti di falsi positivi. Ad esempio, la seguente sintassi della regola può corrispondere agli eventi con $event_a.field = "something" anche se non dovrebbe.
events:
not ($event_a.field = "something" **or** $event_b.field = "something")
condition:
$event_a and #event_b >= 0
La soluzione consiste nel separare le condizioni in due blocchi in cui ogni blocco applica il filtro solo a una singola variabile, come mostrato di seguito:
events:
not ($event_a.field = "something")
not ($event_b.field = "something")
condition:
$event_a and #event_b >= 0
Aritmetica con campi evento non firmati
Se provi a utilizzare una costante intera in un'operazione aritmetica con un campo UDM il cui tipo è un numero intero non firmato, viene visualizzato un errore. Ad esempio:
events:
$total_bytes = $e.network.received_bytes * 2
Il campo udm.network.received_bytes è un numero intero non firmato. Questo accade perché le costanti intere hanno per impostazione predefinita interi con segno, che non funzionano con interi senza segno nelle operazioni aritmetiche.
La soluzione alternativa è forzare la costante intera su un numero in virgola mobile, che funzionerà con il numero intero non firmato. Ad esempio:
events:
$total_bytes = $e.network.received_bytes * (2/1)
Coerenza finale e falsi positivi nell'arricchimento GeoIP
Il sistema dà la priorità alla velocità rispetto alla precisione immediata nelle fasi iniziali di arricchimento (streaming e sensibili alla latenza), il che può comportare la mancanza di dati e potenziali falsi positivi. Il sistema continuerà ad arricchire i dati in background, ma questi potrebbero non essere disponibili al momento dell'esecuzione della regola. Si tratta della normale procedura di coerenza finale. Per evitare questi tipi di falsi positivi, non fare affidamento sull'esistenza di campi arricchiti negli eventi per attivare i rilevamenti.
Ad esempio, considera questo evento regola:
$e.principal.ip_geo_artifact.network.asn = "16509" AND
$e.principal.ip_geo_artifact.location.country_or_region = "United Kingdom"
La regola si basa sul fatto che l'evento deve avere $e.principal.ip_geo_artifact.network.asn = "16509" E $e.principal.ip_geo_artifact.location.country_or_region = "United Kingdom", entrambi campi arricchiti. Se l'arricchimento non viene completato in tempo, la regola produrrà un falso positivo.
Per evitare questo problema, un controllo migliore per questa regola sarebbe:
$e.principal.ip_geo_artifact.network.asn != "" AND
$e.principal.ip_geo_artifact.network.asn = "16509" AND
$e.principal.ip_geo_artifact.location.country_or_region != "" AND
$e.principal.ip_geo_artifact.location.country_or_region = "United Kingdom"
Questa regola elimina la possibilità che l'evento venga attivato da IP con l'ASN 16509, ma situati al di fuori del Regno Unito. In questo modo, viene migliorata la precisione complessiva della regola.