Esta página foi traduzida pela API Cloud Translation.

Limitações e problemas conhecidos da YARA-L

Este documento descreve os problemas e as limitações conhecidos do YARA-L.

Agregações de resultados com campos repetidos desaninhados

Quando uma regra se refere a um campo repetido em uma variável de evento e esse campo repetido contém mais de um elemento, cada elemento é desencapsulado em uma linha de evento separada.

Por exemplo, as duas strings de endereço IP no campo repetido target.ip no evento $e na regra a seguir são desaninhados em duas instâncias do evento $e, cada um com um elemento target.ip diferente.

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
}

Registro de evento antes da eliminação de aninhamento de campo repetido

A tabela a seguir mostra o registro de evento antes da eliminação de aninhamento de campo repetido:

metadata.id	principal.application	target.ip
`aaaaaaaaa`	`Google SecOps`	`[192.0.2.20`, `192.0.2.28]`

Registros de eventos após desaninhamento de campo repetido

A tabela a seguir mostra o registro do evento após o desaninhamento de campo repetido:

metadata.id	principal.application	target.ip
`aaaaaaaaa`	`Google SecOps`	`192.0.2.20`
`aaaaaaaaa`	`Google SecOps`	`192.0.2.28`

Quando uma regra se refere a um campo repetido que é filho de outro campo repetido, como security_results.action, o desaninhamento acontece em ambos no nível do campo pai e do filho. O conjunto resultante de instâncias desaninhar de um único evento é o produto cartesiano dos elementos no campo pai e elementos no campo filho. Na regra de exemplo a seguir, o evento $e com dois valores repetidos em security_results e dois Os valores em security_results.actions são desaninhados em quatro instâncias.

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
}

Registro de evento antes do desaninhamento de campo repetido

A tabela a seguir mostra o registro de evento antes da eliminação de aninhamento de campo repetido:

metadata.id	principal.application	security_results
`aaaaaaaaa`	`Google SecOps`	`[ { actions: [ ALLOW, FAIL ] }`, `{ actions: [ CHALLENGE, BLOCK ] } ]`

Registros de eventos após a eliminação de campos repetidos

A tabela a seguir mostra o registro do evento após o desaninhamento de campo repetido:

metadata.id	principal.application	security_results.actions
`aaaaaaaaa`	`Google SecOps`	PERMITIR
`aaaaaaaaa`	`Google SecOps`	FALHA
`aaaaaaaaa`	`Google SecOps`	DESAFIO
`aaaaaaaaa`	`Google SecOps`	BLOQUEAR

Esse comportamento de desaninhamento na avaliação de regras pode produzir agregações de resultado quando a regra faz referência a um ou mais campos repetidos com um campo pai que também é um campo repetido. Agregações não distintas como sum(), array() e count() não podem contabilizar valores duplicados em outros campos no mesmo evento produzido pelo comportamento de desaninhamento. Na regra de exemplo a seguir, o evento $e tem um único nome de host google.com, mas o resultado hostnames agrega quatro instâncias não aninhadas do mesmo evento $e, cada uma com um valor principal.hostname duplicado. Esse resultado gera quatro nomes de host em vez de um, devido à eliminação de valores repetidos em 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
}

Registro de evento antes do desaninhamento de campo repetido

A tabela a seguir mostra o registro de evento antes da eliminação de aninhamento de campo repetido:

metadata.id	principal.application	principal.hostname	security_results
`aaaaaaaaa`	`Google SecOps`	`google.com`	`[ { action: [ ALLOW, FAIL ] }`, `{ action: [ CHALLENGE, BLOCK ] } ]`

Registro de evento após a eliminação de aninhamento de campo repetido

A tabela a seguir mostra o registro do evento após a eliminação de aninhamento de campo repetida:

metadata.id	principal.application	principal.hostname	security_results.action
`aaaaaaaaa`	`Google SecOps`	`google.com`	PERMITIR
`aaaaaaaaa`	`Google SecOps`	`google.com`	FALHA
`aaaaaaaaa`	`Google SecOps`	`google.com`	DESAFIO
`aaaaaaaaa`	`Google SecOps`	`google.com`	BLOQUEAR

Alternativa

Agregações que ignoram ou eliminam valores duplicados não são são afetadas por esse comportamento de desaninhamento. Use a versão distinta de um agregação se você encontrar valores de resultado inesperados devido ao desaninhamento.

As agregações a seguir não são afetadas pelo comportamento de desencapsulamento descrito anteriormente.

max()
min()
array_distinct()
count_distinct()

Agregações de resultados com múltiplas variáveis de evento

Se uma regra tiver várias variáveis de evento, haverá um item separado na agregação para cada combinação de eventos incluída na detecção. Por exemplo, se a regra de exemplo a seguir for executada nos eventos listados:

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"

A soma é calculada com base em cada combinação de eventos, permitindo que você use variáveis de evento nos cálculos do valor de resultado. Os elementos a seguir são usada no cálculo:

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

Isso resulta em uma soma máxima potencial de 6, mesmo que $e2 só possa correspondem a três eventos distintos.

Isso afeta soma, contagem e matriz. Para contagem e matriz, use count_distinct. ou array_distinct pode resolver o problema, mas não há uma solução alternativa para soma.

Parênteses no início de uma expressão

O uso de parênteses no início de uma expressão aciona o seguinte erro:

parsing: error with token: ")"
invalid operator in events predicate

O exemplo a seguir geraria esse tipo de erro:

($event.metadata.ingested_timestamp.seconds -
$event.metadata.event_timestamp.seconds) / 3600 > 1

As seguintes variações de sintaxe retornam o mesmo resultado, mas com uma sintaxe válida:

$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

A matriz de índice no resultado exige agregação para valores únicos em um campo repetido

A indexação de matrizes na seção de resultados ainda requer agregação. Por exemplo, o seguinte não funciona:

outcome:
  $principal_user_dept = $suspicious.principal.user.department[0]

No entanto, é possível salvar a saída do índice de matriz em uma variável de marcador de posição e usar essa variável na seção de resultados, conforme mostrado aqui:

events:
  $principal_user_dept = $suspicious.principal.user.department[0]

outcome:
  $principal_user_department = $principal_user_dept

Condição OR com inexistência

Se uma condição OR for aplicada entre duas variáveis de evento separadas e se a regra corresponder à não existência, a regra será compilada, mas poderá produzir detecções de falso positivo. Por exemplo, a sintaxe de regra a seguir pode corresponder a eventos com $event_a.field = "something", mesmo que não deva.

events:
     not ($event_a.field = "something" **or** $event_b.field = "something")
condition:
     $event_a and #event_b >= 0

A solução alternativa é separar as condições em dois blocos, em que cada bloco apenas aplica o filtro a uma única variável, conforme mostrado aqui:

events:
     not ($event_a.field = "something")
     not ($event_b.field = "something")
condition:
     $event_a and #event_b >= 0

Aritmética com campos de eventos não assinados

Se você tentar usar uma constante de número inteiro em uma operação aritmética com um comando UDM campo cujo tipo seja um número inteiro não assinado, você receberá um erro. Exemplo:

events:
  $total_bytes = $e.network.received_bytes * 2

O campo udm.network.received_bytes é um número inteiro sem sinal. Isso acontece porque para constantes de número inteiro que têm como padrão números inteiros com sinal, o que não funciona com números inteiros sem assinatura em operações aritméticas.

A solução é forçar a constante de número inteiro a um ponto flutuante que funcionará pelo número inteiro não assinado. Exemplo:

events:
  $total_bytes = $e.network.received_bytes * (2/1)