Servidores Web e TCP
Antes de encerrar essa discussão, é instrutivo falar um pouco mais sobre servidores Web e como eles usam números de porta. Considere um hospedeiro rodando um servidor Web, tal como um Apache, na porta 80. Quando clientes (por exemplo, browsers) enviam segmentos ao servidor, todos os segmentos terão a porta de destino 80. Em especial, os segmentos que estabelecem a conexão inicial e os segmentos que carregam as mensagens de requisição HTTP, ambos terão a porta de destino 80. Como acabamos de descrever, o servidor distingue os segmentos dos diferentes clientes pelos endereços IP e pelos números de porta da fonte.
Como mostra a Figura 3.5, cada um desses processos tem seu próprio socket de conexão através do qual chegam requisições HTTP e são enviadas respostas HTTP. Mencionamos, contudo, que nem sempre existe uma correspondência unívoca entre sockets de conexão e processos. Na verdade, os servidores Web de alto desempenho atuais muitas vezes utilizam somente um processo, mas criam uma nova thread com um novo socket de conexão para cada nova conexão cliente. (Uma thread pode ser considerada um subprocesso leve.) Se você fez a primeira tarefa de programação do Capítulo 2, construiu um servidor Web que faz exatamente isso. Para um servidor desses, a qualquer dado instante podem haver muitos sockets de conexão (com identificadores diferentes) ligados ao mesmo processo.
Se o cliente e o servidor estiverem usando HTTP persistente, então, durante toda a conexão persistente, eles trocarão mensagens HTTP através do mesmo socket do servidor. Todavia, se o cliente e o servidor usarem HTTP não persistente, então uma nova conexão TCP é criada e encerrada para cada requisição/resposta e, portanto, um novo socket é criado e mais tarde encerrado para cada requisição/resposta. Essa criação e encerramento frequentes de sockets podem causar sério impacto sobre o desempenho de um servidor Web movimentado (embora o sistema operacional possa usar vários estratagemas para atenuar o problema). Aconselhamos o leitor interessado em questões de sistema operacional referentes a HTTP persistente e não persistente a consultar [Nielsen, 1997; Nahum, 2002].
Varredura de Porta
Vimos que um processo servidor espera pacientemente em uma porta aberta para contato por um cliente remoto. Algumas portas são reservadas para aplicações familiares (por exemplo, Web, FTP,DNS e os servidores SMTP); outras portas são utilizadas por convenção por aplicações populares (por exemplo, o Microsoft SQL Server 2000 ouve as solicitações na porta 1434 do UDP). Desta forma, se determinarmos que uma porta está aberta no hospedeiro, talvez possamos mapear essa porta para uma aplicação específica sendo executada no hospedeiro. Isso é muito útil para administradores de sistema, que frequentemente têm interesse em saber quais aplicações de rede estão sendo executadas nos hospedeiros em suas redes. Porém, os atacantes, a fim de “examinarem o local”, também querem saber quais portas estão abertas nos hospedeiros direcionados. Se o hospedeiro estiver sendo executado em uma aplicação com uma falha de segurança conhecida (por exemplo, um SQL Server ouvindo em uma porta 1434 estava sujeito a esgotamento de buffer, permitindo que um usuário remoto execute um código arbitrário no hospedeiro vulnerável, uma falha explorada pelo worm Slammer [CERT, 2003-04]), então esse hospedeiro está pronto para o ataque.
Determinar quais aplicações estão ouvindo em quais portas é relativamente uma tarefa fácil. De fato há um número de programas de domínio público, denominados varredores de porta, que fazem exatamente isso. Talvez o mais utilizado seja o nmap, disponível gratuitamente em http://insecure.org/nmap e está incluso na maioria das distribuições Linux. Para o TCP, o nmap varre portas sequencialmente, procurando por portas que aceitam conexões TCP. Para o UDP, o nmap novamente varre portas sequencialmente, procurando por portas UDP que respondem aos segmentos UDP transmitidos. Em ambos os casos, o nmap retorna uma lista de portas abertas, fechadas ou inalcançáveis. Um hospedeiro executando o nmap pode tentar varrer qualquer hospedeiro direcionado em qualquer lugar da Internet. Voltaremos a falar sobre o nmap na Seção 3.5.6, ao discutirmos gerenciamento da conexão TCP.
Agora que já discutimos multiplexação e demultiplexação na camada de transporte, passemos à discussão de um dos protocolos da Internet, o UDP. Na próxima seção, veremos que a contribuição desse protocolo não é muito mais do que um serviço de multiplexação/demultiplexação.
Comentários
Postar um comentário