3.8 Socket. Depois de escrever o parágrafo anterior, resolvi acessar novamente o site do Google. Veja o resultado:

Transcrição

1 Capítulo 3 Redes TCP/IP 81 Depois de escrever o parágrafo anterior, resolvi acessar novamente o site do Google. Veja o resultado: canopus:~# netstat -tna Conexões Internet Ativas (servidores e estabelecidas) Proto Recv-Q Send-Q Endereço Local Endereço Remoto Estado tcp : :80 ESTABELECIDA Conclusão: como já era de se esperar, a porta cliente e o endereço IP do Google mudaram. A porta de destino sempre será 80, pois se trata de um servidor de páginas utilizando uma porta- padrão (registrada). Importante: a cada nova conexão, a porta do cliente mudará (a não ser em casos raros, como um cliente DHCP ou um cliente NIS). Em outras palavras, a mudança da porta de um cliente caracteriza uma nova conexão. Esse é um dado muito importante na análise de tráfego. É possível mudar a porta de um servidor, mas os clientes deverão ser avisados sobre isso. Quando abrimos um navegador, digitamos e pressionamos o ENTER, uma conexão é feita entre o cliente e o servidor. Essa conexão é direcionada à porta 80 do servidor, pois todo navegador sabe que um servidor de páginas estará disponível na sua porta 80. Caso o servidor do Google estivesse disponibilizando sua página na porta 90, o endereço a ser digitado no navegador deveria ser É óbvio que o usuário deveria ser previamente avisado sobre a mudança da porta-padrão. Como foi dito, as portas de serviços já consagrados são registradas pela IANA e há uma relação no endereço No GNU/Linux, há uma relação dentro do arquivo /etc/services. Contudo, esse arquivo nunca estará tão completo e atualizado quanto a relação existente no site da IANA, que é alterado, pelo menos, mensalmente. 3.8 Socket Socket (pronuncia-se sóquete), definido na RFC 793 e em outras, é o nome que se dá ao conjunto IP e porta. Esse nome é muito utilizado nas redes de computadores, principalmente em arquivos de configuração. A representação de um socket é variável para IPv4 e IPv6. Geralmente, adota-se o padrão IP:porta.

2 Socket IPv4 A principal representação de socket no IPv4 é IP:porta. Portanto, a porta 110 do endereço pode ser representada como :110. É importante ressaltar que todo cliente deve conhecer o socket do servidor para contactá-lo. No entanto, os servidores só irão conhecer o socket dos clientes quando estes realizarem uma conexão. Conclusão: toda conexão é iniciada por um cliente e nunca por um servidor. Isso é extremamente importante na análise de tráfego. Apesar de ser pouco usual esse tipo de representação, o socket pode utilizar um simples ponto para separar o IP da porta. No caso do exemplo anterior, teríamos O programa tcpdump, por exemplo, usa esse tipo de representação. Também é possível representar uma URL com sua porta. Exemplo, conforme a RFC 3986: Socket IPv6 O IPv6 admite outras representações para sockets, todas listadas na RFC 5952, apesar de continuar existindo a forma tradicional IP:porta. A seguir, exemplos de algumas representações mais comuns: 2001:db8::cccc: :db8::cccc :db8::cccc# DNS e DHCP Os serviços conhecidos como DNS e DHCP são considerados os mais básicos em redes TCP/IP. A seguir, veremos, de forma introdutória, como eles atuam DNS O Domain Name System (DNS) é um serviço que realiza conversões de nomes de máquinas para IP ou de IP para nomes. É necessário porque, em um primeiro momento, nas redes TCP/IP, as máquinas fazem o envio de dados para endereços IP (considerando o protocolo IP). Assim, quando digitamos br em um navegador, o protocolo IP não sabe o que fazer com isso. É nesse ponto que entra o DNS.

3 Capítulo 3 Redes TCP/IP 83 Na verdade, toda máquina em uma rede TCP/IP, em princípio, sabe o endereço IP de um ou mais servidores DNS. Então, quando digitamos o endereço de um site (URL) em um navegador, este, imediatamente, pergunta a um servidor DNS qual é o endereço IP referente àquele nome. Uma vez recebida a informação, o navegador se conecta com o endereço IP do servidor desejado. A figura 3.8 mostra um servidor DNS em ação. Observe a figura 3.8. Inicialmente, um cliente pergunta ao servidor DNS quem é ❶. O servidor responde que é ❷. Finalmente, o cliente realiza a conexão com o servidor desejado ❸. Cabe ressaltar que um servidor DNS pode resolver nomes e endereços IP. Resolver significa consultar uma tabela para verificar qual é a associação correta ao dado fornecido. Por exemplo: caso seja fornecido um nome de máquina pelo cliente, o DNS deverá devolver, como resposta, o endereço IP correspondente a tal nome. Isso se chama resolução direta. Também há a resolução reversa. Neste caso, quando um endereço IP é fornecido para o DNS, este retorna para o cliente o nome da máquina que possui aquele IP. Ainda, o nome técnico dado a um cliente DNS é resolver. ❶ Servidor DNS Cliente ❷ ❸ Servidor ( ) Figura 3.8 Uma consulta DNS seguida de uma conexão a um site DHCP O Dynamic Host Configuration Protocol (DHCP) é um serviço que fornece os dados de uma rede para que um cliente possa participar da mesma. Alguns dados que poderão ser fornecidos, entre outros:

4 Capítulo 5 Protocolo IPv4 111 pacote IP e, geralmente, os seguintes usarão números subsequentes. Terminada a transmissão da informação em questão, para uma nova informação, será gerado um novo número para o primeiro pacote IP. A identificação total de um pacote IP se dá pelos campos Identification, Protocol, Source Address e Destination Address. Em outras palavras, teremos certeza de que estamos falando de um pacote específico quando o identificarmos pelos valores encontrados nos quatro campos citados Entendendo a fragmentação Antes de continuarmos a ver os campos do IP, deveremos entender como ocorre a fragmentação. Muitas vezes, um pacote IP tem que ser fragmentado (quebrado) antes de ser enviado pela rede. A causa disso será a capacidade total de envio de dados por uma rede. Isso será abordado com mais profundidade no capítulo 12. Mas, em rápidas palavras, geralmente, a rede não é capaz de transmitir um pacote IP de qualquer tamanho. Portanto, muitas vezes, os pacotes IP ficarão maiores do que a capacidade de envio da rede, devendo ser quebrados em pedaços menores. Imagine um pacote IP com um tamanho X. Para ser transmitido pela rede, ele necessitará ser quebrado em, por exemplo, três partes (duas grandes e uma menor, contendo o que sobrou). A figura 5.3 mostra essa situação. Para acompanhar, a figura poderá ser impressa a partir de Na figura 5.3, em ❶, podemos ver um pacote IP. A parte cinza representa seu cabeçalho e a parte branca, seu payload. Contudo, para circular na rede, o pacote precisará ser quebrado em três pedaços, pois a rede que está sendo utilizada não consegue transmitir um pacote IP tão grande. Apenas para que você comece a entender, as redes mais comuns são as do tipo Ethernet, que, normalmente, só conseguem transmitir 1500 bytes de cada vez. Caso o IP a ser transmitido tenha, por exemplo, 3500 bytes, será necessário quebrá-lo em pedaços. Isso será explanado com mais exatidão no capítulo 12.

5 112 Figura 5.3 Um exemplo de fragmentação do IP. Ainda na figura 5.3, em ❷, o IP é quebrado em duas partes. A primeira parte, que inclui o cabeçalho, já está pronta para ser enviada pela rede, pois tem o tamanho ideal. A segunda parte possui dois problemas a serem resolvidos. O primeiro é o tamanho. Deverá haver uma nova quebra para que os dados consigam passar pela rede, pois a segunda parte continua sendo muito grande. O segundo problema é o cabeçalho. Para trafegarem, os dados deverão receber um cabeçalho. Se isso não ocorrer, os dados não saberão, por exemplo, aonde ir. É importante entender que esse novo cabeçalho deverá ser computado no tamanho total permitido pela rede para tráfego. Em outras palavras, o novo cabeçalho, somado ao pedaço de payload, não deverá exceder o tamanho admitido pela rede. O novo cabeçalho, a ser adicionado ao segundo pedaço de IP mostrado em ❷, terá algumas partes copiadas do cabeçalho original e outras adaptadas. Dados como o campo Identification serão copiados. O campo Identification será o mesmo porque ele identifica um pacote IP. No caso, todos os fragmentos serão do mesmo IP. Alguns outros campos, como o endereço de origem e o endereço de destino, também permanecerão inalterados.

6 Capítulo 5 Protocolo IPv4 115 bastando colocar os fragmentos em ordem crescente relativa ao Fragment Offset. A ordem final de montagem será 0, 185 e 370. O campo Fragment Offset possui 13 bits de tamanho e, portanto, poderá ir de (0 em decimal) a (8.191 em decimal) Análise de uma fragmentação IP Vamos realizar nossa primeira análise com o auxílio do tcpdump. É interessante, deste ponto em diante, ter em mãos o guia Análise de tráfego em redes TCP/IP com tcpdump e WinDump, disponível em Será enviado um pacote gerado pelo comando ping, mostrado a seguir: # ping -c 1 -s O comando anterior gerou um pacote com 3500 bytes de payload. Em uma rede Ethernet, com taxa de transmissão de 1500 bytes, esse pacote terá que ser fragmentado em três pedaços. Vamos analisar o resultado com o tcpdump. As linhas serão numeradas para facilitar a análise. root@canopus:~# tcpdump -n icmp and host tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size bytes ❶ 10:59: IP > : ICMP echo request, id 4326, seq 1, length 1480 ❷ ❸ 10:59: IP > : ip-proto-1 10:59: IP > : ip-proto-1 ❹ 10:59: IP > : ICMP echo reply, id 4326, seq 1, length 1480 ❺ ❻ 10:59: IP > : ip-proto-1 10:59: IP > : ip-proto-1 Na linha ❶ é possível ver que foi enviado um ping (ICMP echo request) de para O número de identificação do IP é 4326 (campo Identification). O tamanho do payload do IP é 1480 bytes. Então, já sabemos que seu cabeçalho tem o tamanho de 20 bytes, uma vez que a rede transmite 1500 bytes. E será possível confirmar isso, com o próprio tcpdump, analisando o pacote byte a byte. Essa operação será vista oportunamente. Nas linhas ❷ e ❸ está explícito que está sendo enviado o protocolo IP número 1, que é o ICMP. Estudaremos esse termo protocolo IP número 1 quando virmos o campo Protocol. Mas acredite: é o ICMP! Então, nesse caso, tudo indica que as linhas ❶, ❷ e ❸ tratam de um único pacote IP, contendo um ICMP, fragmentado em três pedaços. As linhas ❹, ❺ e ❻ representam a resposta da máquina

7 116 Pacotes IP poderão conter protocolos ICMP no seu interior. Isso será visto quando estudarmos o campo Protocol. Só será possível afirmar que os fragmentos ❶, ❷ e ❸ são do mesmo pacote se observarmos os detalhes do cabeçalho IP. Assim, com a opção -v do tcpdump, será possível vermos os detalhes. Acompanhe: root@canopus:~# tcpdump -n icmp and host v tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size bytes ❶ 10:59: IP (tos 0x0, ttl 64, id 46171, offset 0, flags [+], proto ICMP (1), length 1500) > : ICMP echo request, id 4326, seq 1, length 1480 ❷ 10:59: IP (tos 0x0, ttl 64, id 46171, offset 1480, flags [+], proto ICMP (1), length 1500) > : ip-proto-1 ❸ 10:59: IP (tos 0x0, ttl 64, id 46171, offset 2960, flags [none], proto ICMP (1), length 568) > : ip-proto-1 ❹ 10:59: IP (tos 0x0, ttl 64, id 21719, offset 0, flags [+], proto ICMP (1), length 1500) > : ICMP echo reply, id 4326, seq 1, length 1480 ❺ 10:59: IP (tos 0x0, ttl 64, id 21719, offset 1480, flags [+], proto ICMP (1), length 1500) > : ip-proto-1 ❻ 10:59: IP (tos 0x0, ttl 64, id 21719, offset 2960, flags [none], proto ICMP (1), length 568) > : ip-proto-1 Com a opção -v surgiram duas linhas por pacote. A primeira se refere diretamente ao protocolo IP e a segunda, ao ICMP que está dentro dele. Para fazermos a análise, em alguns pontos, vamos designar cada uma das linhas pelo seu protocolo. Exemplo: ❶IP e ❶ICMP. Como foi visto, as linhas ❶ a ❸ estão mostrando o envio do ping, conhecido como ICMP echo request, enquanto ❹ a ❻ mostram a resposta a este, ou seja, ICMP echo reply. Na linha ❶, vemos a máquina enviando um ping para O campo Identification tem como valor Note que o Fragment Offset é 0. Você irá reparar que o tcpdump mostra o valor do Fragment Offset multiplicado por 8. Com isso, na verdade, não vemos o offset puro, e sim o byte real que o gerou. Para seres humanos, esse tipo de relatório é bem mais compreensível. Ainda na linha ❶, flags [+] representa que MF é igual a 1. Então, teremos mais fragmentos depois deste. Isso é a prova de que o pacote foi fragmentado. O tamanho total do fragmento atual (cabeçalho + payload) é igual a 1500 bytes, como pode

8 144 notar que se trata de um protocolo TCP pelo fato de existirem flags como S (SYN), P (PSH), F (FIN) e ACK. Essas flags só existem no TCP. Sempre que surgir um caractere ponto entre dois colchetes, esse caractere representará a existência de um ACK. Atente para o fato de que a primeira linha não possui ponto entre os colchetes. Vamos à análise do tráfego. Analisaremos linha por linha. Se você deseja baixar e imprimir a captura mostrada para acompanhar as explicações a seguir, acesse e clique em Capítulo 6 _ Captura 1. Começaremos com a linha ❶. ❶ IP > : Flags [S], seq , win 14600, options [mss 1460,sackOK,TS val ecr 0,nop,wscale 7], length 0 O host , por intermédio de sua porta 49952, enviou uma flag SYN (caracterizada por [S]) para a porta 80 da máquina Com isso, ela está iniciando uma conexão (flag SYN inicia conexões). Já sabemos que quem inicia uma conexão é sempre o cliente. Então, é o cliente e , o servidor. Também podemos deduzir que há uma grande probabilidade de estar havendo uma consulta a um site (na verdade, já sabíamos disso), uma vez que a porta 80 é utilizada por servidores web (protocolo HTTP). Apesar disso, caso não conhecêssemos o teor da comunicação, não seria possível afirmar se tratar de uma transação HTTP sem uma prévia análise do payload do pacote. Cuidado! Na prática, qualquer serviço pode ser configurado em qualquer porta. Então, poderemos, por exemplo, criar um servidor de utilizando o protocolo SMTP, configurando-o para atuar na porta 80. Aliás, muitos programas clandestinos ou com intenções duvidosas, os chamados malwares, usam esse tipo de técnica. Eles levam em consideração que a maioria dos sistemas de firewall permite comunicação com portas 80 externas sem verificar o conteúdo dos pacotes. Então, são montados servidores na Internet, com a porta 80 disponível, permitindo o recebimento de qualquer tipo de dado oriundo de dentro das redes. Por trás dessas portas 80, haverá servidores ftp, ssh, de , de códigos maliciosos etc. Conclusão: sem examinarmos o payload de um pacote ou segmento, não teremos condições de dizer qual tipo de tráfego está ocorrendo. Continuando a análise da primeira linha, temos o número de sequência Observe que esse é o número de sequência do cliente; o servidor terá um número de sequência inicial diferente.

9 154 viando uma flag FIN e, a seguir, na linha ❹, a máquina responde com um ACK. A conexão foi totalmente encerrada. No meio fechamento são necessárias quatro linhas de tráfego. Ainda, lembrese de que flags TCP tramitam entre portas. Assim, na linha ❶, por exemplo, a flag FIN saiu da porta 80 da máquina , em direção à porta da máquina O fechamento completo ocorre de forma similar ao three-way handshake. Observe a captura a seguir: ❶ IP > : Flags [F.], seq , ack , win 16425, length 0 ❷ IP > : Flags [F.], seq , ack , win 12, length 0 ❸ IP > : Flags [.], ack , win 16425, length 0 Na linha ❶, podemos ver que enviou uma flag FIN para Na linha ❷, enviou um ACK para o FIN recebido e, com ele, também uma flag FIN. Dessa forma, no mesmo instante em que fica consumada a finalização da conexão no sentido > , o host também inicia sua finalização em direção a Não ocorre mais a situação na qual um lado está totalmente fechado enquanto o outro está totalmente aberto. Por fim, na linha ❸, o host envia o ACK correspondente ao FIN recebido na linha ❷. No fechamento completo são necessárias apenas três linhas de tráfego, similarmente ao que ocorre com o three-way handshake. Quando ocorrerá o meio fechamento ou o fechamento completo? Da mesma forma como foi citado no início deste item, isso será combinado, previamente, durante a sessão de aplicação. Há uma questão muito importante a ser entendida aqui. Quando um lado fecha a conexão, ele está dizendo que não enviará mais dados. Contudo, ele poderá recebê-los, apesar de isso não ser uma situação praticada normalmente pelos hosts envolvidos Ocorrência da flag RESET Até agora, em momento algum a flag RST apareceu. Isso é bom. Mas veremos um exemplo de RST. Na minha frente, tenho um roteador wireless TP-Link. Como a maioria deve saber, ele possui um pequeno servidor de páginas. Esse servidor disponibiliza a configuração do roteador, via HTTP. Vamos acessar a página

10 156 IP > : Flags [P.], seq : , ack , win 3432, options [nop,nop,ts val ecr ], length 151 IP > : Flags [.], ack , win 123, options [nop,nop,ts val ecr [...] ], length 0 Como já era de se esperar, por ser um site, o navegador conectou-se diretamente com a porta 80. E se forçássemos uma conexão HTTP com a porta 81? O que ocorreria? Vamos observar, na figura 6.8, o browser e a respectiva captura. Figura 6.8 Tentativa de conexão com a porta 81. Na figura 6.8, vemos que não foi possível se conectar com a porta 81 do roteador. Observe agora a captura do respectivo tráfego: IP > : Flags [S], seq , win 14600, options [mss 1460,sackOK,TS val ecr 0,nop,wscale 7], length 0 IP > : Flags [R.], seq 0, ack , win 0, length 0 O host (cliente), pela sua porta 44461, enviou uma flag SYN para a porta 81 da máquina (servidor). Como a porta 81 não existe (está fechada), o servidor enviou um RST (R).

11 162 Podemos deduzir o seguinte sobre o MS Windows 7: O RTO inicial é de 3 segundos. Isso é coerente, pois ele foi lançado em abril de 2011, ou seja, antes de junho de 2011 (RFC 6298). O Windows 7 permite duas retransmissões de SYN (linhas ❷ e ❸). Aqui surgiu uma nova informação: a quantidade de retransmissões SYN permitidas. Essa limitação é feita por cada sistema operacional. A Microsoft cita em support.microsoft.com/kb/ : Note In Windows 7 and Windows Server 2008 R2, the TCP maximum SYN retransmission value is set to 2, and is not configurable. Because of the 3-second limit of the initial time-out value, the TCP three-way handshake is limited to a 21-second timeframe (3 seconds + 2*3 seconds + 4*3 seconds = 21 seconds). Os Kernels Linux, por exemplo, antigamente permitiam cinco retransmissões de SYN. Desde agosto de 2012, o kernel foi ajustado para permitir seis retransmissões do SYN puro (sem o ACK). Dentro do código-fonte do Kernel Linux 3.8.3, de março de 2013, poderemos ver o seguinte trecho no arquivo include/net/tcp.h: #define TCP_SYN_RETRIES 6 /* This is how many retries are done * when active opening a connection. * RFC1122 says the minimum retry MUST * be at least 180secs. Nevertheless * this value is corresponding to * 63secs of retransmission with the * current initial RTO. */ #define TCP_SYNACK_RETRIES 5 /* This is how may retries are done * when passive opening a connection. * This is corresponding to 31secs of * retransmission with the current * initial RTO. */ Já o Kernel , de fevereiro de 2013, utilizado no Debian versão 7.0 (Wheezy), por ser oriundo do Kernel 3.2-rc1, possui a linha: #define TCP_SYN_RETRIES 5 Agora, observe um segmento contendo a flag SYN, oriundo de um GNU/Linux utilizando o kernel 3.8.3, de março de 2013, sendo retransmitido:

12 Capítulo 6 Protocolo TCP 189 Na captura mostrada, observe que sempre estão sendo emitidos dois segmentos PSH seguidos, com 1448 bytes de payload cada um. Note que para cada dupla de PSH, há apenas um ACK, que se refere ao segundo PSH. Talvez, em alguns downloads pela vida, você tenha reparado que a velocidade inicial é baixa, mas que a mesma vai aumentando aos poucos. Isso ocorre porque o sistema de janelas vai se ajustando ao link, permitindo cada vez mais tráfego. O ajuste é gradativo para haver segurança de que não ocorrerá perda de dados desnecessariamente. Só para se ter uma ideia de velocidade, a figura 6.12 mostrará a quantidade de segmentos PSH, com 1448 bytes de payload cada um, emitidos por segundo, durante 25 segundos, em uma conexão de 10 Mb/s (Internet). Figura 6.12 Ajuste da janela TCP em um download. Apenas como curiosidade, o gráfico mostrado foi criado com base em dados referentes ao download da ISO do Debian Wheezy amd64, a partir do site Campo Checksum O campo Checksum do TCP é similar ao Checksum do IP, com a pequena diferença de que, no TCP, o conteúdo do payload também é verificado, além de haver uma ligação com o cabeçalho IP. O protocolo IPv4 não garante os dados do payload para ter agilidade na sua passagem por roteadores. Cabe aos protocolos que por ele são encapsulados a tarefa de garantir seus payloads e, ainda, assegurarem-se de que estão dentro dos pacotes IP corretos. Para demonstrar o cálculo do Checksum, faremos uma requisição HTTP para uma página que não existe. A URL será Observe

13 capítulo 9 Protocolo IPv6 O IPv6 é a mais nova versão de protocolo IP para a Internet. Neste capítulo, veremos como ocorre a análise de tráfego que envolve esse protocolo. 9.1 Tráfego IPv6 No capítulo 3, falamos um pouco sobre IPv6. Já no capítulo 5, vimos a análise de tráfego envolvendo o IPv4. Os conhecimentos que esses capítulos nos passaram já permitem uma análise superficial de tráfego IPv6. Se olharmos uma saída tcpdump sem a opção -v, teremos como diferença, do IPv6 para o IPv4, apenas o tamanho dos endereços IP. Veja um exemplo de um tráfego completo IPv6 com TCP embarcado: 16:39: IP6 2001:db8:: > 2001:db8::2.80: Flags [S], seq , win 14400, options [mss 1440,sackOK,TS val ecr 0,nop,wscale 7], length 0 16:39: IP6 2001:db8::2.80 > 2001:db8:: : Flags [S.], seq , ack , win 14280, options [mss 1440,sackOK,TS val ecr ,nop,wscale 5], length 0 16:39: IP6 2001:db8:: > 2001:db8::2.80: Flags [.], ack , win 113, options [nop,nop,ts val ecr ], length 0 16:39: IP6 2001:db8:: > 2001:db8::2.80: Flags [P.], seq : , ack , win 113, options [nop,nop,ts val ecr ], length :39: IP6 2001:db8::2.80 > 2001:db8:: : Flags [.], ack , win 480, options [nop,nop,ts val ecr ], length 0 16:39: IP6 2001:db8::2.80 > 2001:db8:: : Flags [P.], seq : , ack , win 480, options [nop,nop,ts val ecr ], length :39: IP6 2001:db8:: > 2001:db8::2.80: Flags [.], ack , win 124, options [nop,nop,ts val ecr ], length 0 16:39: IP6 2001:db8:: > 2001:db8::2.80: Flags [F.], seq , ack , win 124, 216

14 Capítulo 11 Protocolos Ethernet, ARP e NDP 261 os dados que estão sendo fornecidos deverão superpor quaisquer dados existentes previamente na memória do destinatário. Com isso, mapeamentos IP/MAC antigos serão descartados, dando lugar à nova informação. Target address, com 16 bytes. Refere-se ao endereço IPv6 de destino da mensagem. Options, com tamanho variável. Por enquanto (julho de 2013), esse campo só tem como opção o target link-layer address, cujo código é 02h, conforme a tabela existente em Tráfego NDP Vamos observar um ping IPv6 (ping6) entre duas máquinas. ❶ 13:21: IP6 2001:db8::1 > ff02::1:ff00:3: ICMP6, neighbor solicitation, who has 2001:db8::3, length 32 ❷ 13:21: IP6 2001:db8::3 > 2001:db8::1: ICMP6, neighbor advertisement, tgt is 2001:db8::3, length 32 ❸ 13:21: IP6 2001:db8::1 > 2001:db8::3: ICMP6, echo request, seq 1, length 64 ❹ 13:21: IP6 2001:db8::3 > 2001:db8::1: ICMP6, echo reply, seq 1, length 64 ❺ 13:21: IP6 2001:db8::1 > 2001:db8::3: ICMP6, echo request, seq 2, length 64 ❻ 13:21: IP6 2001:db8::3 > 2001:db8::1: ICMP6, echo reply, seq 2, length 64 Na linha ❶, podemos observar o Neighbor Solicitation ocorrendo. O ping foi executado da máquina 2001:db8::1, em direção à máquina 2001:db8::3. Então, note a pergunta who has 2001:db8::3 (quem tem 2001:db8::3?). Na linha ❷, há a resposta de 2001:db8::3 para 2001:db8::1. Não é possível ver, aqui, o endereço MAC. Vamos analisar novamente as duas primeiras linhas com a opção -v: ❶ ❷ 13:21: IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2001:db8::1 > ff02::1:ff00:3: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:db8::3 source link-address option (1), length 8 (1): 38:60:77:29:6e:24 13:21: IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2001:db8::3 > 2001:db8::1: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is 2001:db8::3, Flags [solicited, override] destination link-address option (2), length 8 (1): 5c:c9:d3:1b:15:90 Em ❶, vemos o IPv6 na primeira linha do bloco, seguido do ICMPv6 Neighbor Solicitation. Na segunda linha vemos o source link-address option (o mesmo que source link-layer address), que está englobado pelo ICMPv6. Em ❷, vemos o IPv6 na primeira linha do bloco, agora seguido do ICMPv6 Neighbor Advertisement. Na segunda linha, temos o destination link-address (o mesmo

15 Análise de tráfego em DNS Uma vez que já sabemos como funciona um servidor DNS, será fácil analisarmos seu tráfego. Vamos fazer algumas análises específicas a partir de agora Resolução com sucesso Considere o comando a seguir: $ ping -c 2 Agora, veja a captura via tcpdump, feita no cliente, envolvendo também a operação DNS: ❶ 16:35: IP > : A? (32) ❷ 16:35: IP > : /3/6 A (237) ❸ 16:35: IP > : ICMP echo request, id 17346, seq 1, length 64 ❹ 16:35: IP > : ICMP echo reply, id 17346, seq 1, length 64 ❺ 16:35: IP > : PTR? in-addr.arpa. (45) ❻ 16:35: IP > : /2/2 PTR santoro.debian.org. (173) ❼ 16:35: IP > : ICMP echo request, id 17346, seq 2, length 64 ❽ 16:35: IP > : ICMP echo reply, id 17346, seq 2, length 64 Na linha ❶, é possível observar o cliente perguntando ao servidor (porta servidora 53) qual é o endereço IPv4 de (A? www. debian.org). Perguntas DNS, geralmente, possuem menos de 512 bytes e, por isso, ocorrem em UDP (veja o capítulo 12). Vamos observar a linha ❶, em detalhes, para comprovarmos isso: 16:35: IP (tos 0x0, ttl 64, id 50869, offset 0, flags [DF], proto UDP (17), length 60) > : A? (32) Comprovado: o tráfego ocorreu sobre UDP. Observe que há um número antes da pergunta, ou seja, Esse número funciona como uma espécie de tag ou ticket e serve para identificar a operação. Ao responder, o servidor deverá citar essa tag. Apenas relembrando um conceito de análise de tráfego, o TCP e o UDP são protocolos de transporte (camada 4 do Modelo OSI), usam portas e só existirão se houver algum dado oriundo da camada 7 (aplicação) para ser encapsulado. Então, como há portas na transação DNS, isso é um sinal de que estamos lidando com um protocolo de aplicação. Conclusão: DNS é um serviço em nível de aplicação.