o que é um fluxo de tráfego de rede?
os fluxos de tráfego de rede (fluxos) são úteis para construir uma compreensão grosseira do tráfego em uma rede de Computadores, fornecendo uma unidade conveniente para a medição e/ou tratamento do tráfego.
os fluxos podem ser medidos para entender o que os hosts estão falando na rede, com detalhes de endereços, volumes e tipos de tráfego. Essa visão da rede pode ser útil para solucionar problemas, detectar incidentes de segurança, planejamento e faturamento
, mas o que exatamente é um fluxo e como ele é definido?
esta pergunta parece trivial de responder, no entanto, quando nos aprofundamos, encontramos nuances e casos de Canto que tornam os fluxos interessantes e, em última análise, difíceis de definir.
Background
para realmente entender os fluxos, precisamos começar com algum plano de fundo.
as redes começaram como comutadas por circuito. Quando um host queria se comunicar com outro host, ele perguntou à rede configurar um circuito. Depois que o fluxo de informações terminou, o circuito foi demolido.
Figura 1-Exemplo de rede comutada por Circuito
as redes comutadas por Circuito têm sua herança em redes telefônicas. Eles têm uma série de desvantagens, incluindo baixa escalabilidade e utilização de baixa capacidade.
era necessária uma alternativa para construir o que acabou se tornando as redes comutadas por pacotes da Internet. As mensagens são cortadas em pedaços de tamanho variável que são endereçados individualmente e enviados como pacotes pela rede.
Figura 2-Exemplo de rede comutada por pacotes
o host Receptor remonta a carga útil dos pacotes de volta à mensagem. Nota: Os pacotes também podem conter informações de controle, como controle de fluxo e caminhos não precisam ser simétricos.Definir fluxos em uma rede comutada por circuito é fácil, pois o circuito é um fluxo e segue um protocolo para estabelecer e descomissionar (circuito = fluxo); no entanto, em uma rede comutada por Pacote, as coisas são menos óbvias.
Imagine por um segundo que você está no ponto de observação em Um a rede de comutação de circuitos da Figura 1, você verá:
Figura 3 – Ampliar Rede de Comutação de Circuitos
Dois fluxos de ser observado – circuitos entre os hosts 3 & 4 e hosts 5 & 6. Observar fluxos em uma rede comutada por circuito é relativamente fácil porque a rede está envolvida na configuração dos circuitos, portanto, conhece seu estado e os terminais.
Imagine agora que você está no ponto de observação a na rede comutada por pacotes da Figura 2, você veria:
Figura 4-amplie a rede comutada por pacotes
de repente, as coisas ficam menos claras. Há um pacote vindo do Host 5 destinado ao Host 6. Supondo que observemos por um período de tempo, vemos mais pacotes chegarem e partirem. Observar fluxos em uma rede comutada por pacotes leva tempo e requer gravação e análise de informações de pacotes.
primeira tentativa (ingênua) de definir um fluxo
usando nosso conhecimento de redes comutadas por pacotes, uma primeira tentativa de responder ‘o que é um fluxo’ pode ser:
Um fluxo é uma seqüência de pacotes de transporte de informações entre dois hosts
Esta definição parece:
Figura 5 – Primeira Tentativa para Definir um Fluxo de
no entanto, Existe um problema. O que acontece se houver mais de um tipo de comunicação acontecendo entre os hosts, por exemplo, a tem uma conexão SSH e HTTPS com B? Os pacotes SSH e HTTPS fazem parte do mesmo fluxo? Intuitivamente dizemos não, são sessões diferentes e até protocolos totalmente diferentes. Podemos fazer melhor …
segunda tentativa de definir
que tal usarmos informações de Protocolo de cabeçalhos de pacotes como propriedades comuns para identificar pacotes em fluxos? Isso separará diferentes tipos de conexão em diferentes fluxos.
uma grande proporção de pacotes em uma rede provavelmente será o protocolo IP layer-3, com TCP ou UDP como o protocolo de transporte layer-4. Portanto, é razoável considerar o uso de parâmetros TCP e UDP como chaves de fluxo dos cabeçalhos dos pacotes.
usaremos 5 parâmetros dos cabeçalhos dos pacotes; IP de origem, IP de destino, protocolo, porta de origem TCP ou UDP e porta de destino TCP ou UDP como uma lista ordenada, comumente conhecida como 5 tuplas, como as propriedades comuns para mapear os pacotes para fluxos.
Figura 6 – Exemplo 5-tupla
Aqui vai tentativa 2:
Um fluxo é uma seqüência de pacotes de transporte de informações entre dois hosts, onde os pacotes têm propriedades comuns:
- Todos os pacotes no fluxo de compartilhar o mesmo 5-tupla
Nosso cenário parece com isso agora:
Figura 7-segunda tentativa de definir um fluxo
perfeito que você diz. A vida é boa. Temos uma definição para um fluxo, nada mais para ver aqui … mas espere, e a direção dos pacotes?
terceira tentativa-bidirecional
uma tupla de 5 é unidirecional (unidirecional). Por padrão, ele corresponderá apenas aos pacotes que viajam em uma direção, uma vez que os pacotes na direção inversa transpuseram endereços IP e números de porta e, portanto, um hash de 5 tuplas diferente.
existem boas razões para considerar os fluxos bidirecionais em oposição aos unidirecionais, incluindo a capacidade de determinar o comportamento do cliente/servidor e calcular os tempos de ida e volta, bem como melhorar a detecção de incidentes de segurança, como varredura.
considere uma conexão TCP simples na Figura 8, onde os pacotes saltam para frente e para trás entre o Host A & B:
Figura 8-Diagrama de escada de um fluxo TCP simples
vemos um handshake TCP 3-way clássico (SYN, SYN+ACK, ACK) seguido de troca de dados. Fluxo unidireccional de análise em um ponto de observação na rede consulte separada em dois fluxos, um por direção, conforme Figura 9:
Figura 9 – Unidirecional Escadas para o Simples Fluxo TCP
O problema com o fluxo unidireccional de medição é de nós perca a oportunidade de capturar algum metadados importantes sobre o fluxo. Claro, cada fluxo unidirecional pode armazenar metadados direcionais para bytes e pacotes nessa direção. Isso pode incluir o tempo entre pacotes (consulte pontos rotulados na Figura 9). Mas perdemos a oportunidade de reunir metadados que exigem a medição de Parâmetros de tráfego em ambas as direções.
considere a observação bidirecional na Figura 10:
Figura 10-Escada de observações bidirecionais para fluxo TCP simples
agora podemos observar e medir o handshake TCP de 3 vias (pontos F1, B1, F2) e observar outras métricas como tempos de resposta.
para fluxos bidirecionais, precisamos de duas 5 tuplas, a segunda das quais inverte a ordem das tuplas dos endereços IP e dos números das portas. Abaixo está um exemplo de fluxo SSH para frente e reverso 5 tuplas:
Figura 11-Invertendo uma tupla 5
direita, isso não foi muito difícil. Mas espere, um pequeno detalhe se esconde que requer mais atenção. Como sabemos qual é a direção para a frente do fluxo? Determinamos a direção com base no primeiro pacote observado, que se supõe estar viajando na direção do cliente para o servidor, mas isso não será 100% confiável, pois os pacotes podem estar fora de ordem e/ou a observação pode começar parcialmente através de um fluxo. Vamos usar com este método, mas precisamos lembrar quando olhamos para os resultados que não é perfeito.
um método alternativo está inspecionando os campos do protocolo de transporte. No TCP, por exemplo, a presença de apenas o sinalizador SYN é um indicador razoável de que o pacote é o primeiro no fluxo.
nossa definição para um fluxo é agora:
um fluxo é uma sequência de pacotes que transportam informações entre dois hosts onde os pacotes têm propriedades comuns:
- todos os pacotes no fluxo compartilham a mesma 5-tupla ou 5-tupla transposta
quarta tentativa-incluindo tráfego IP Não TCP
até este ponto, assumimos que o protocolo de transporte é TCP. E quanto a outros protocolos de transporte IP?
UDP é a escolha óbvia para o segundo protocolo de transporte mais comum, especialmente com o aumento do tráfego em tempo real sobre UDP, bem como novos protocolos, como QUIC. UDP se encaixa facilmente no mesmo modelo que tem números de porta de origem e destino, de acordo com o exemplo QUIC abaixo:
Figura 12 – reverter uma tupla UDP 5 (igual a TCP)
Stream Control Transmission Protocol (SCTP) é outro protocolo de transporte que usa números de porta e, portanto, funciona com uma tupla de 5.
mas e quanto a outros protocolos, IPsec por exemplo?
IPsec ESP (Encapsulating Security Payload) é um protocolo que não inclui números de porta de origem/destino, portanto, precisamos voltar a uma tupla de 3, pois é improvável que a compreensão da carga útil do protocolo seja prática.
Figura 13 – Bidirecional 3-Tupla
a Nossa definição de um fluxo de agora é:
Um fluxo é uma seqüência de pacotes de transporte de informações entre dois hosts onde os pacotes têm propriedades comuns:
- Para protocolos de transporte com números de porta (que eu.e.TCP/UDP/SCTP):
Todos os pacotes no fluxo de compartilhar o mesmo 5-tupla ou transposição 5-tupla
else:
Todos os pacotes no fluxo de compartilhar o mesmo 3-tupla ou transposta 3-tupla
no entanto, Há ainda outro fator a considerar – tempo.
quinta tentativa – expiração do fluxo
um fluxo existe apenas por um certo período de tempo. É possível que a mesma 5-tupla (ou 3-tupla) possa ser reutilizada em um ponto diferente no tempo, para um fluxo diferente, entre os mesmos hosts.
considere dois hosts onde um inicia muitas novas conexões TCP para o outro. Cada nova conexão TCP obtém uma nova porta de origem, geralmente incrementada em 1 da alocação anterior. A IANA aloca o intervalo 49152 a 65535 para essas portas efêmeras, dando 16384 portas. Com o tempo, a porta de origem TCP rolará pelo intervalo e a porta de origem original será reutilizada, e esse fluxo terá a mesma tupla de 5 que o fluxo original. Isso apresenta um problema, pois não é o mesmo fluxo!
para resolver isso, precisamos que os fluxos sejam expirados, onde nenhum pacote é visto por mais de um período de tempo especificado. Aqui vamos nós outra vez:
um fluxo é uma sequência de pacotes que transportam a informação entre dois anfitriões onde os pacotes têm propriedades comuns:
- para protocolos do transporte com números de porta (isto é TCP / UDP / SCTP):
Todos os pacotes no fluxo de compartilhar o mesmo 5-tupla ou transposição 5-tupla
else:
Todos os pacotes no fluxo de compartilhar o mesmo 3-tupla ou transposta 3-tupla
- Todas as inter-pacote vezes são menos arbitrária do fluxo de valor de tempo limite de expiração
Sexta Tentativa – Parâmetros Arbitrários
às Vezes você pode querer parâmetros diferentes para identificar fluxos, ou estes podem ser obrigado a você pelo tipo de hardware/software na rede.
em um roteador Cisco, por exemplo, os fluxos são identificados por uma 7 tupla que adiciona o tipo de serviço (ToS) e a subinterface de entrada à 5 tupla padrão. Também pode haver situações em que os campos de camada 2, como endereço MAC de origem ou destino, podem fazer sentido como teclas de fluxo (embora observe que eles são apenas localmente significativos).
existem outros parâmetros que podem ser usados como propriedades comuns para identificação de fluxo; cabe ao operador decidir e as capacidades do equipamento. Com base nisso, refinamos ainda mais a definição:
Um fluxo é uma seqüência de pacotes de transporte de informações entre dois hosts onde os pacotes têm propriedades comuns:
- Para protocolos de transporte com números de porta (que eu.e.TCP/UDP/SCTP):
Todos os pacotes no fluxo de compartilhar o mesmo 5-tupla ou transposição 5-tupla
else:
Todos os pacotes no fluxo de compartilhar o mesmo 3-tupla ou transposta 3-tupla
- Todas as inter-pacote vezes são menos arbitrário de fluxo de expiração de tempo limite de valor
- Pode usar qualquer arbitrária de parâmetros como fluxo de chaves, incluindo ToS, interface, etc.
encerrando tudo
mostramos que produzir uma única definição de fluxo abrangente é um problema difícil. A definição de fluxo é específica da implementação, dependente dos requisitos do usuário, bem como dos recursos do equipamento de rede que mede os fluxos.
na parte 2 desta postagem do blog, entraremos em outras considerações para fluxos como rótulos de fluxo IPv6, fragmentação (problema IPv4 e IPv6..), criptografia, pacotes Não IP e como os fluxos são medidos e usados em outros sistemas, como SDN.
ver: https://www.eecs.yorku.ca/course_archive/2015-16/W/3214/CSE3214_01_PacketCircuitSwitching_2016_posted_part2.pdf
Para alguns artigos relacionados, consulte: https://www.researchgate.net/profile/Brian_Trammell/publication/245587221_Bidirectional_Flow_Measurement_IPFIX_and_Security_Analysis/links/0f3175331dd3b49103000000/Bidirectional-Flow-Measurement-IPFIX-and-Security-Analysis.pdf e https://is.muni.cz/th/hilnn/cse2009.pdf
relevante, RFC, consulte: https://tools.ietf.org/html/rfc5103
Para mais informações sobre a normalização de PCL, consulte: https://datatracker.ietf.org/wg/quic/about/
Ver: https://www.cisco.com/en/US/tech/tk812/technologies_white_paper09186a008022bde8.shtml
Leave a Reply