corelight/community-id-specUm padrão aberto para aplicar hash a fluxos de rede, convertendo-os em identificadores, também conhecido como "Community IDs".
Ao processar dados de fluxo provenientes de uma variedade de aplicações de monitorização (como Zeek e Suricata), é frequentemente desejável pivotar rapidamente de um conjunto de dados para outro. Embora a informação do tuplo de fluxo necessária esteja normalmente presente nos conjuntos de dados, os detalhes desses "joins" podem ser tediosos, particularmente em casos extremos. Esta especificação descreve a hash de fluxo "Community ID", padronizando a produção de um identificador de string que representa um determinado fluxo de rede, para reduzir o pivot a uma simples comparação de strings.
function community_id_v1(ipaddr saddr, ipaddr daddr, port sport, port dport, int proto, int seed=0)
{
# Get seed and all tuple parts into network byte order
seed = pack_to_nbo(seed); # 2 bytes
saddr = pack_to_nbo(saddr); # 4 or 16 bytes
daddr = pack_to_nbo(daddr); # 4 or 16 bytes
sport = pack_to_nbo(sport); # 2 bytes
dport = pack_to_nbo(dport); # 2 bytes
# Abstract away directionality: flip the endpoints as needed
# so the smaller IP:port tuple comes first.
saddr, daddr, sport, dport = order_endpoints(saddr, daddr, sport, dport);
# Produce 20-byte SHA1 digest. "." means concatenation. The
# proto value is one byte in length and followed by a 0 byte
# for padding.
sha1_digest = sha1(seed . saddr . daddr . proto . 0 . sport . dport)
# Prepend version string to base64 rendering of the digest.
# v1 is currently the only one available.
return "1:" + base64(sha1_digest)
}
function community_id_icmp(ipaddr saddr, ipaddr daddr, int type, int code, int seed=0)
{
port sport, dport;
# ICMP / ICMPv6 endpoint mapping directly inspired by Zeek
sport, dport = map_icmp_to_ports(type, code);
# ICMP is IP protocol 1, ICMPv6 would be 58
return community_id_v1(saddr, daddr, sport, dport, 1, seed);
}
O Community ID é um identificador de fluxo adicional e não precisa de substituir os mecanismos de identificação de fluxo existentes já suportados pelos monitores. No entanto, é aceitável que um monitor seja configurado para registar apenas o Community ID, se desejável.
O Community ID pode ser calculado à medida que um monitor produz fluxos, ou pode também ser adicionado a registos de fluxo existentes numa fase posterior, assumindo que esses registos transmitem toda a informação de endpoints de fluxo necessária.
Colisões no Community ID, embora indesejáveis, não são consideradas fatais, uma vez que o utilizador deve ainda possuir informação de temporização do fluxo e possivelmente o mecanismo de ID nativo do monitor (idealmente mais forte do que o Community ID) para desambiguação.
O mecanismo de hash utiliza semeadura (seeding) para permitir controlo adicional sobre "domínios" de utilização do Community ID. A semente (seed) tem como padrão 0, portanto este mecanismo fica fora do caminho para não afetar a operação de operadores que não estejam interessados nele.
Na versão 1 do ID, o algoritmo de hash é SHA1. Versões futuras de hash podem alterá-lo ou permitir configuração adicional.
O resultado binário SHA1 de 20 bytes é codificado em base64 para reduzir o volume de saída em comparação com a representação SHA1 habitual baseada em ASCII. Isto pressupõe que o espaço, e não o tempo de computação, é a principal preocupação, e pode tornar-se configurável numa versão posterior.
O ID de fluxo resultante inclui um número de versão para tornar explícita a implementação subjacente do Community ID. Isto permite que os utilizadores garantam que estão a comparar "maçãs com maçãs", ao mesmo tempo que suportam futuras alterações ao algoritmo. Por exemplo, quando a versão do ID de um monitor incorpora VLAN IDs mas a de outro não, as comparações dos valores de hash devem falhar de forma fiável. Uma forma mais complexa desta funcionalidade poderia permitir capturar definições de configuração para além da versão da implementação.
O esquema de versionamento atualmente simplesmente prefixa o valor de hash com "<versão>:", produzindo algo como isto na versão 1 atual:
1:hO+sN4H+MG5MY/8hIrXPqc4ZQz0=
A entrada do hash está alinhada em limites de 32 bits. Os componentes do tuplo de fluxo utilizam ordem de bytes de rede (big-endian) para padronizar a ordenação independentemente do hardware do anfitrião.
A entrada do hash é ordenada para remover a direcionalidade no tuplo de fluxo: troque os endpoints, se necessário, para que o tuplo IP:porta numericamente menor venha primeiro. Se os endereços IP forem iguais, as portas decidem. Por exemplo, os seguintes 5-tuplos netflow criam hashes Community ID idênticos porque ambos são ordenados para a sequência 10.0.0.1, 127.0.0.1, 1234, 80.
Esta versão inclui os seguintes protocolos e campos:
TCP / UDP / SCTP:
IP origem / IP destino / proto IP / porta de origem / porta de destino
ICMPv4 / ICMPv6:
IP origem / IP destino / proto IP / tipo ICMP + "tipo-contador" ou código
O tratamento exato do tipo e código ICMP é retirado do Zeek; veja implementações aqui:
Outros protocolos transportados sobre IP:
IP origem / IP destino / proto IP
O acima não cobre atualmente como lidar com aninhamento (IP em IP, v6 sobre v4, etc.) nem encapsulamentos como VLAN e MPLS.
Se um monitor de rede não suportar nenhuma das constelações de protocolo acima, pode reportar com segurança uma string vazia (ou outro valor não colidente) para o ID de fluxo.
Considere a v1 um protótipo. O feedback da comunidade, particularmente de implementadores e utilizadores operacionais do ID, é muito apreciado. Por favor, crie issues diretamente no projeto GitHub em https://github.com/corelight/community-id-spec, ou contacte Christian Kreibich ([email protected]).
Muitos agradecimentos pela discussão útil e feedback a Victor Julien, Johanna Amann e Robin Sommer, e a todos os implementadores e apoiantes.
Uma implementação completa está disponível no pacote pycommunityid. Inclui uma série de testes para verificar o cálculo correto para os vários protocolos. Recomendamos que sirva de guia para novas implementações.
Uma implementação mais pequena também está disponível através do script community-id.py neste repositório, incluindo o layout de bytes dos valores com hash (veja packet_get_comm_id()). Consulte --help e make.sh para começar:
$ ./community-id.py --help
usage: community-id.py [-h] [--seed NUM] PCAP [PCAP ...]
Community flow ID reference
positional arguments:
PCAP PCAP packet capture files
optional arguments:
-h, --help show this help message and exit
--seed NUM Seed value for hash operations
--no-base64 Don't base64-encode the SHA1 binary value
--verbose Show verbose output on stderr
Para resolução de problemas, a implementação suporta omitir a operação base64, e pode fornecer detalhes adicionais sobre a sequência exata de bytes que entram no cálculo do hash SHA1.
O diretório baseline neste repositório contém conjuntos de dados para
ajudá-lo a verificar que a sua implementação das funções Community ID
funciona corretamente.
Sinta-se à vontade para discutir aspetos do Community ID via GitHub aqui: https://github.com/corelight/community-id-spec/issues