Entendendo TCP flags

TCP ou Protocolo de Controle de Transmissão, é um protocolo de rede orientado a fluxo que foi criado há décadas. Agora é usado praticamente em todos os lugares, destacando como, por vezes, as tecnologias antigas ainda são relevantes ou mesmo essenciais hoje. Um protocolo orientado a fluxo abstrai os detalhes e complexidades do envio e recebimento de pacotes de rede. Ele lida com a detecção de pacotes perdidos, duplicados e fora de ordem para fornecer à camada de aplicação um fluxo suave de bytes, daí o nome “protocolo orientado a fluxo”.

No cabeçalho do protocolo, o TCP usa sinalizadores para gerenciar conexões e fluxos de tráfego. Um resumo dos sinalizadores PCT e seus significados pode ser encontrado na tabela a seguir:

Esse post fornecerá uma rápida revisão dos sinalizadores TCP e explicará alguns de seus usos.

Visão geral do TCP

O TCP é construído sobre IP, ou protocolo da Internet. IP trata do envio e recebimento de pacotes. Os pacotes IP consistem em um cabeçalho e uma carga útil. O cabeçalho contém informações como o endereço IP de origem, o endereço IP de destino e o protocolo usado na carga útil (como ICMP, UDP ou TCP).

O TCP não lida com pacotes fora de ordem, perdidos ou duplicados. Também não tem conceito de “conexões” no sentido de que a pilha IP não é capaz de agrupar logicamente pacotes enviados ou recebidos de acordo com determinados critérios (por exemplo, uma construção lógica que é uma “conexão” conforme vista pela camada de aplicação). Portanto, o TCP se baseia no IP para fornecer um protocolo orientado a fluxo.

Para fazer isso, o TCP estabelece uma conexão entre dois pontos, usando sinalizadores para estabelecer tal conexão. Este conceito de conexão é necessário para apresentar o fluxo de dados como um fluxo contínuo em ambas as extremidades. Assim que a comunicação terminar, a conexão pode ser fechada usando sinalizadores nos cabeçalhos dos pacotes TCP.

Como o TCP é necessário para lidar com pacotes fora de ordem, duplicados ou perdidos, ele precisa detectar e reordenar pacotes e retransmitir pacotes. Esse fluxo de dados é novamente gerenciado usando sinalizadores nos cabeçalhos TCP, bem como contadores, que discutiremos com mais detalhes em uma seção posterior.

Estabelecendo uma conexão da maneira tradicional

Uma conexão TCP é iniciada pelo cliente e passa por um three-way handshake conforme mostrado abaixo:

Aqui está uma sequência típica, com o sinalizador TCP SYN significando “sincronizar” e ACK indicando “reconhecimento”:

• O cliente envia um pacote TCP para o servidor com o sinalizador SYN definido.
• O servidor recebe o pacote, cria um TBC (Bloco de controle de transmissão) em sua memória e responde com um pacote TCP com os sinalizadores SYN e ACK configurados.
• O cliente responde com um pacote TCP com o sinalizador ACK definido.

Depois disso, ambos os lados podem enviar dados.

Ressalta-se que no passo (2) acima, o servidor precisa armazenar algumas informações sobre a conexão em andamento para poder processar o pacote que o cliente envia no passo (3). Isso é chamado de Bloco de Controle de Transmissão e torna o servidor vulnerável a um ataque DoS (negação de serviço).

Se um invasor enviar um pacote SYN, o servidor deverá manter um estado sobre essa conexão até receber o pacote ACK do cliente ou considerar a tentativa de conexão obsoleta e excluir o estado. Conseqüentemente, um invasor pode enviar muitos pacotes SYN para iniciar uma conexão, mas nunca enviar o pacote ACK final. O servidor acumulará um grande número de estados relacionados a essas conexões falsas, o que pode encher a memória do servidor, fazendo com que conexões legítimas sejam negadas. As vezes, esse ataque também é chamado de ataque de inundação SYN.

Estabelecendo uma conexão evitando um ataque de inundação sincronizada

Existe uma maneira de mitigar esses ataques de inundação SYN.

Em vez de armazenar o estado da conexão na memória, o servidor enviará seu pacote SYN+ACK com um número de sequência N especialmente criado que representa as informações necessárias sobre a conexão. O cliente então responderá com seu pacote ACK usando um número de sequência N+1, e o servidor será capaz de reconstruir o estado da conexão usando esse número de sequência:

A informação de estado incorporada no número de sequência também é chamada de “cookie SYN” porque a resposta do cliente contém esse cookie, semelhante aos cookies HTTP.

Fluxo de dados assim que uma conexão é estabelecida

O sinalizador ACK

Após a conexão ser estabelecida, os dados são enviados e confirmados por ambos os lados. Cada ponto na conexão mantém alguns contadores:

• O contador de sequência, que conta o número de bytes enviados
• O contador de confirmação, que conta o número de bytes recebidos

O diagrama de sequência a seguir ilustra como isso funciona:

O número de bytes que foram enviados, mas ainda não reconhecidos, é chamado de “janela TCP”. Na verdade, existem duas janelas TCP, uma para cada ponto na conexão TCP. No diagrama acima, a janela TCP antes do último pacote do lado direito tem 90 bytes. O tamanho das janelas TCP é limitado a 65.535 bytes na especificação TCP original, mas pode ser aumentado por meio de extensões TCP.

Um pacote com o sinalizador ACK definido é usado para reconhecer os bytes recebidos por um ponto. É usado em combinação com o contador de confirmação para informar ao outro par os últimos bytes recebidos. Esta informação é então usada para determinar se alguns pacotes foram perdidos, caso em que o ponto remetente retransmitirá os pacotes perdidos.

Os sinalizadores PSH e URG

Ao enviar dados, qualquer lado da conexão TCP pode usar adicionalmente os sinalizadores PSH e URG (que significam respectivamente “puxe” e “urgente”). Os sinalizadores PSH instruem o sistema operacional a enviar (para o lado emissor) e receber (para o lado receptor) os dados imediatamente. Em outras palavras, esse sinalizador instrui a pilha de rede do sistema operacional a enviar/receber todo o conteúdo de seus buffers imediatamente.

Sem esse sinalizador, o sistema operacional pode decidir esperar antes de enviar ou passar os dados recebidos para o aplicativo porque deseja aguardar que mais dados sejam enviados ou recebidos para maximizar a utilização dos recursos do host e da rede. No entanto, alguns aplicativos gostariam que os dados fossem enviados e recebidos o mais rápido possível, por exemplo, com uma sessão SSH ou no final de uma solicitação ou resposta HTTP.

O sinalizador URG é usado para sinalizar dados “urgentes” que devem ser priorizados em relação aos dados não urgentes. Ele é utilizado para enviar os chamados “dados out-of-band”, que são tratados de maneira especial pelo sistema operacional e geralmente sinalizam algum tipo de exceção no protocolo da aplicação. Observe que, na prática, esse recurso do TCP raramente é usado.

Terminando uma conexão

Finalizando eficientemente

Um ponto da conexão TCP pode sinalizar ao outro que deseja encerrar a conexão enviando um pacote com um sinalizador FIN. O outro lado então reconhece isso ao enviar um pacote com os sinalizadores FIN e ACK definidos e pode então prosseguir para encerrar seu lado da conexão. Este four-way handshake é ilustrado no diagrama abaixo:

Quando a conexão for encerrada, quaisquer dados armazenados em buffer ou em trânsito ainda serão processados. Na verdade, qualquer ponto que não tenha enviado um pacote FIN ainda poderá enviar dados. Na prática, isso é raro, pois um protocolo de nível superior (HTTP, por exemplo) geralmente possui seu próprio mecanismo para sinalizar que a conexão está terminando e que não é necessário enviar mais dados por nenhum dos lados.

Interrompendo uma conexão

Qualquer um dos lados da conexão TCP pode decidir interromper a conexão. Isso é feito quando o ponto em questão acredita que a conexão não deveria existir por algum motivo. Nesse caso, um ponto envia um pacote com o sinalizador RST definido. O outro ponto, ao receber o pacote RST, deve interromper imediatamente o envio de quaisquer dados.

Quando uma conexão é interrompida dessa forma, os dados em trânsito e os dados armazenados em buffer são perdidos. Portanto, existe o potencial de perda de dados, mas isso não deveria ser um problema se essa conexão não fosse válida para começar. Os pacotes RST são raros na vida real e provavelmente são usados mais para fins maliciosos do que legítimos.

Recapitulação da tabela

As diferenças entre FIN e RST estão resumidas na tabela abaixo:

Analise os TCP flags na linha de comando usando Tcpdump

A maioria dos engenheiros de rede conhece o tcpdump, uma ferramenta de linha de comando para capturar tráfego de rede. É versátil e, na verdade, não se limita somente ao TCP, apesar do seu nome.

Aqui está um comando que podemos usar para gerar algum tráfego de rede:

$ curl http://google.com

O comando tcpdump, executado em um terminal separado, daria a seguinte saída:

$ sudo tcpdump -i any host google.com

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes

07:23:41.829027 IP thinkpad.58400 > lhr48s09-in-f14.1e100.net.http: Flags [S], seq 479485488, win 64240, options [mss 1460,sackOK,TS val 2441158056 ecr 0,nop,wscale 7], length 0

07:23:41.846135 IP lhr48s09-in-f14.1e100.net.http > thinkpad.58400: Flags [S.], seq 1617638117, ack 479485489, win 65160, options [mss 1357,sackOK,TS val 2779514051 ecr 2441158056,nop,wscale 8], length 0

07:23:41.846163 IP thinkpad.58400 > lhr48s09-in-f14.1e100.net.http: Flags [.], ack 1, win 502, options [nop,nop,TS val 2441158073 ecr 2779514051], length 0

07:23:41.846234 IP thinkpad.58400 > lhr48s09-in-f14.1e100.net.http: Flags [P.], seq 1:75, ack 1, win 502, options [nop,nop,TS val 2441158073 ecr 2779514051], length 74: HTTP: GET / HTTP/1.1

07:23:41.860886 IP lhr48s09-in-f14.1e100.net.http > thinkpad.58400: Flags [.], ack 75, win 255, options [nop,nop,TS val 2779514067 ecr 2441158073], length 0

07:23:41.884595 IP lhr48s09-in-f14.1e100.net.http > thinkpad.58400: Flags [P.], seq 1:529, ack 75, win 255, options [nop,nop,TS val 2779514090 ecr 2441158073], length 528: HTTP: HTTP/1.1 301 Moved Permanently

07:23:41.884616 IP thinkpad.58400 > lhr48s09-in-f14.1e100.net.http: Flags [.], ack 529, win 501, options [nop,nop,TS val 2441158112 ecr 2779514090], length 0

07:23:41.884782 IP thinkpad.58400 > lhr48s09-in-f14.1e100.net.http: Flags [F.], seq 75, ack 529, win 501, options [nop,nop,TS val 2441158112 ecr 2779514090], length 0

07:23:41.906850 IP lhr48s09-in-f14.1e100.net.http > thinkpad.58400: Flags [F.], seq 529, ack 76, win 255, options [nop,nop,TS val 2779514112 ecr 2441158112], length 0

07:23:41.906877 IP thinkpad.58400 > lhr48s09-in-f14.1e100.net.http: Flags [.], ack 530, win 501, options [nop,nop,TS val 2441158134 ecr 2779514112], length 0

07:23:41.922266 IP lhr48s09-in-f14.1e100.net.http > thinkpad.58400: Flags [R], seq 1617638647, win 0, length 0

^C
11 packets captured
19 packets received by filter
0 packets dropped by kernel

Tcpdump mostra os sinalizadores TCP entre colchetes após a palavra-chave “Flags”. Tcpdump fornece apenas abreviações, que são:

• “S” para SYN
• “.” (um único ponto) para ACK
• “P” para PSH
• “F” para FIN
• “R” para RST

Podemos ver que os três primeiros pacotes são a sequência SYN, SYN/ACK, ACK usada para estabelecer uma conexão. O próximo pacote envia alguns dados HTTP para o servidor do Google e tem o sinalizador PSH definido para instruir o sistema operacional a enviar os dados imediatamente.

O Google então responde com um pacote vazio com o sinalizador ACK definido, seguido por outro pacote com a resposta HTTP real. Isso parece ser um desperdício, pois o servidor poderia ter enviado apenas um único pacote. O lado do cliente então responde com um pacote com o sinalizador ACK definido, mas sem dados, o que é esperado.

Finalmente, podemos ver o four-way handshake FIN/ACK encerrar a conexão. É interessante que o servidor do Google também envie um pacote RST após o desligamento normal, o que provavelmente é feito para garantir que clientes realmente desliguem ao final da conexão.

Conclusão

Engenheiros de rede e especialistas em segurança precisam ter um bom entendimento das TCP flags e de como eles são usados. Esta é parte integrante da compreensão e análise do tráfego de rede.