-
As requisições a porta 80 são compativeis com mensagens do serviço HTTP. Porém, a captura não mostra o conteúdo dos segmentos para afirmar o que está acontecendo na camada de aplicação.
-
Que pegadinha safada.
-
Apesar de não ser necessário para realizar a questão, quero compartilhar com v6 um pouco do que compreendi do tráfego acima linha a linha com base em uma boa bibliografia. Vou númerar a linha para facilitar o entendimento. (Não será uma análise profunda!)
As três primeiras linha estão respresentando o three-way handshake o TCP,também chamado por 3WHS.
1) IP 192.168.1.91.33632 > 192.168.1.90.80: Flags [s], seq 2738002527, win 14600, options [mss 1460,sackoK,Ts val 10493310 ecr 0,nop,wscale 7], length 0
**O IP 192.168.1.91 (cliente) através da sua porta alta 33632 está enviando um pacote para o host 192.168.1.90(servidor) na porta 80. Este pacote contém um segmento TCP com a flag [s] (Syn) ativada e com um número aleatório de sequência , seq 2738002527. O payload desse pacote é 0, pois o campo length é 0.
---------------||-----------------
2)IP 192.168.1.90.80 > 192.168.1.91.33632: Flags [s.], seq 589427923, ack 2738002528, win 5840, options [mss 1460,nop,nop,sackoK,nop,wscale 9], length 0
**Agora é a vez do servidor 192.168.1.90. Em sua porta 80 ele está enviando um pacote para o cliente 192.168.1.91 na porta alta 33632. O socket cliente é representado por 192.168.1.91.33632 e o socket servidor por 192.168.1.90.80. A porta alta do cliente junto aos sockets identificam a conexão. Se vocês notarem, todas as linhas possuem os mesmos sockets,portanto se trata de uma única conexão. Agora voltando para a descrição da linha 2. O servidor agora está abrindo uma conexão também(lembrando que se trata da mesma conexão), assim como foi realizado na linha 1, com o cliente 192.168.1.91. Isso está sendo feito através da flag SYN no campo Flags [s.] . Notem também que dentro dos colchetes existe também o caracte ([.]ponto) acompanhando a flag SYN. Isso significa que o segmento TCP também está com a flag ACK ativada. O valor de seq 589427923 trata-se de um valor aleatório , e através do valor ack 2738002528, o servidor está confirmando para o cliente 192.168.1.91 que recebeu o segmento anterior com o seq 2738002527. Como assim, não entendi? Simples. Olhem. Como na linha 1 o length teve valor 0, logo a confirmação do segmento anterior é o seq da linha 1, ou seja,2738002527 +1, o que nos dá um valor ACK na linha 2 de 2738002528.
----------||---------
-
3)IP 192.168.1.91.33632 > 192.168.1.90.80: Flags [.], ack 589427924, win 115, length 0
**É aqui que termina o handskake do TCP. Trata-se do último ACK do 3WHS. Ele está sendo enviado do cliente 192.168.1.91 para o servidor 192.168.1.90. O trecho Flags [.] significa que o segmento possui a flag ACK ativada e está realizando uma confirmação. Neste caso, o cliente está confirmando o segmento da linha 2, com seq 589427923, através do ack 589427924. Como isso? Simples. Pegando o valor seq da linha anterior de 589427923 e adicionando +1, porque na linha 2 o length foi de valor zero. Lembrando que estamos na linha 3. Pronto, a conexão TCP agora está completa, e já podemos trocar dados!
4)IP 192.168.1.91.33632 > 192.168.1.90.80: Flags [p .], seq 2738002528:2738002959, ack 589427924, win 115, length 431
**Com a conexão estabelecida, o cliente agora envia dados com PUSH para o servidor. Sei disso porque o campo flags possui [p.] que significa "p" de push e tem também um ACK porque temos o caractere de "ponto ." junto com o p. Essa é a parte mais difícil. Na linha 2, o servidor enviou para o cliente um ack 2738002528, que pode ser interpretado assim, "Senhor cliente eu recebi até o segmento 2738002528, ou seja, recebi tudo até o 2738002527 pq não conta o próprio valor,então por favor quando enviar o próximo segmento me envie o segmento com seq 2738002528. Podemos notar isso voltando para a linha 4,onde estávamos anteriormente. Olhem o trecho seq 2738002528:2738002959 que significa que agora o cliente está enviando justamente o segmento que o servidor tinha solicitado. Detalhe: além do segmento com seq 2738002528, valor 2738002959 está indicando um intervalo de bytes enviados. Como assim?Simples, notem que esse segmento com PUSH possui 431 bytes, isso pode ser notado através do campo length 431. Subtraiam 2738002959 por 2738002528 e também obterão este valor. Agora temos um ack 589427924 que refere-se apenas a uma reconfirmação e já foi realizado pela linha 3.
--------||----------
5)IP 192.168.1.90.80 > 192.168.1.91.33632: Flags [.], ack 2738002959, win 14, length 0
**Aqui temos apenas uma confirmação. O servidor está confirmando para o cliente que recebeu até o segmento 2738002958. Na lina anterior vimos que o cliente enviou o seguinte 2738002528:2738002959, ou seja foi enviado até o 2738002958, e agora o cliente está aguardando o seq de número 2738002959.
Bibliografia: ANÁLISE DE TRÁFEGO EM REDES TCP/IP-JOÃO ERIBERTO MOTA FILHO-2013,P.143
-
Agora sobre a questão.
Segundo Eriberto(2013,p.144),"Por trás dessas portas 80, poderá haver servidores ftp,ssh,de e-mail,de códidos maliciosos etc. Conclusão: sem examinarmos o payload de um pacote ou segmento, não teremos condições de dizer qual o tipo de tráfego está ocorrendo."
**No tráfego acima só temos informações das portas, que são a 80, que é tipicamente usada pelo HTTP, e a porta alta 33632, daí não da para tirar informações da camada de aplicação não.
Bibliografia:
ANÁLISE DE TRÁFEGO EM REDES TCP/IP-JOÃO ERIBERTO MOTA FILHO-2013, PÁGINA144
-
O que quer dizer o item E? Por que ele está errado?