Esse é outro assunto bastante difundido na internet e temido por muita gente. Mas antes, merece uma descrição detalhada:

              Tal como os números IP, números de portas são formados por bits. As portas são atendidas em números que vão de 0 a 65534 (na verdade o mais correto seria de 1 a 65535. Até agora não vi nenhum servidor que atendesse em portas de número 0). Números de portas de comunicação são formadas por sequência de 16 bits dividido em duas partes cada uma com um byte portanto e separados por pontos de divisão como em um número IP.

              Como havia dito, números de portas vão de 0 a 65535, são muitas portas portanto e cada uma destinada a alguma conexão qualquer. Lembre-se que a cada dia são inventados novos serviços que se utilizam do protocolo TCP/IP como meio e esses novos serviços, vamos citar como exemplo o ICQ, precisam de uma dessas portas disponíveis para conexão. "Qualquer uma?" -- Sim, qualquer uma. Não há um padrão para as portas serem abertas com o mesmo número anterior. O Sistema Operacional se encarregará de escolher uma porta adequada não necessariamente igual a anterior.

              Números de porta inferiores a 1024 são destinadas ao computador que atende determinado serviço. Voltando ao exemplo anterior, o dos servidores: observe que esse pedido é sempre atendido na porta 80 (porta padrão de serviços http), contudo, nada impede que essa porta seja atendida em outro número. Em relação a isso, tal prática é muito corriqueira, ou seja, numa Intranet, por exemplo, é bastante comum o administrador da rede reservar um número maior a um serviço especial que não possa ser acessado assim tão facilmente. Nesse último exemplo, vamos supor que o administrador tenha ficado receoso porque algumas pessoas estão conseguindo acessar um determinado serviço que, embora deva ficar sempre no ar porque atende a certas pessoas, não deve ser acessível a todos. Então ele pode muito bem mudar a porta padrão do serviço - vamos supor um telnet que atende na porta 23 - para algo em torno de 56263. Bem, o administrador é realmente uma pessoa responsável e muda todos os dias o endereço da porta de forma a que ninguém possa acessá-lo assim tão facilmente, dessa forma se tornando bastante difícil a alguém o acesso a esse serviço. Essa é uma prática bastante difundida em servidores particulares visando a segurança de toda a rede, mas não pde ser usada em servidores permanentes como um provedor de acesso a intenet. Nesse caso , a medida mais correta é inabilitar o servico inteiro já que não se pode avisar a todos os usuários que o número da porta mudou de número.

              Alguém pode estar se perguntando: "Ok, entendi o que você quis dizer. Mas vamos supor que o meu progama cliente, o que envia o pedido, vamos supor um telnet, queira se comunicar com um servidor telnet remoto. Não saberia ele a porta correta de comunicação?" -- Bem, não é assim tão simples. Já pensou se tudo fosse assim? Simplesmente eu saberia onde qualquer serviço é atendido e todo o trabalho do administrador vai por água a baixo com todas aquelas mudanças de números. Na verdade, o seu telnet envia o pedido e o inetd o repassa ao telned. Mas acontece uma coisa: se eu mudar o endereço de porta do telnet para outro número qualquer, o inetd não saberá o número a não ser que eu o informe. O pedido vai ser atendido? Nesse caso não. Mas se você indicar a porta correta onde o serviço esta disponível, a comunicação será estabelecida. Então, você teria de apontar o número correto ao seu cliente telnet e este enviaria o número ao servidor remoto. Simples? Pois é, é assim que as coisas funcionam e a segurança é mantida.

              Algo importante que não foi explicado anteriormente é que um dos papéis que o TCP exerce nesse monte de protocolos é que ele fornece o número da porta a ser atendida. Assim, me utilizando do cliente telnet, o TCP fornece o número da porta. Mas quem envia é o IP.

              Confundiu? Vamos dizer assim: O IP é responsável na rede pela transmissão de pacotes, como você já sabe. Em cada pacote vai o IP de destino e de origem (isso esta meio repetitivo mas é necessário). Isso é como se fosse um envelope onde no corpo externo da carta vai o endereço para onde quero enviar, o destinatário, e de onde foi mandado, o remetente. Dentro do envelope vai uma carta. Nessa carta são fornecidos os endereços de portas onde o serviço é atendido. É interessante dizer que o IP não sabe o número da porta, isso é papel do TCP ou do próprio UDP. Nem o UDP nem o TCP sabem para onde vão, ou seja, eles não sabem quais são os números IP.

              Bom, ok. Mas e quanto aos números de portas acima de 1024? Bem, essas são destinadas apenas a comunicação entre programas que se utilizam de TCP/IP. Como havia dito mais acima, vamos citar o exemplo do ICQ. Ótimo programa. Quando você estabelece uma comunicação com os servidores que conectam você ao ICQ, automaticamente é aberta uma porta de comunicação. Se você executar qualquer PortScan para rastreamento de portas abertas, você irá verificar que uma porta, sempre acima de 1024, foi aberta.

              Você pode verificar agora mesmo se alguma porta de comunicação foi aberta no seu micro. Simplesmente no prompt do seu MS-DOS digite: netstat -an. Algo como o que segue abaixo vai aparecer:

              Essas conexões eu tirei de uma lista de discussão e não são de meu computador:

Route Table
Active Connections

  Proto              Local Address                    Foreign Address              State             

              Podemos interpretar isso assim:

Proto: é o protocolo utilizado para transportar o servico, nesse caso foi utilizado o TCP, mas poderia ter sido utilizado o UDP sem problemas, quer dizer, até certo ponto e dependendo do serviço.

Local Address: É o número de porta local ode foi estabelecida a conexão. Observe que foram todas acima de 1024. Exceções foram vistas mas serão explicadas.

Foreign Address: É o endereço de porta remoto onde a conexão foi estabelecida. Foi colocado o nome do protocolo que atende o serviço, o pop3. Poderia ter sido colocado o número de porta sem problemas, nesse caso ficaria 110.

State: Define o estado em que a conexão se encontra no momento. Desses estados, três foram efetuados:

listening: isso é a espera de conexão que ainda não foi estabelecida. No momento em que foi executado o netstat, a porta estava sendo ouvida.

Established: Essa não precisa de muita definição, a conexão foi efetuada com sucesso nas portas em questão e o programa cliente esta recebendo dados de forma normal.

Time Wait: O servidor parou momentaneamente de enviar dados e no momento em que o comando netstat foi executado isso estava ocorrendo.

              Observe as portas que foram estabelecidas no computador local: 1041, 1034, 1040, 137, 138, 139. Como você pode verificar foram estabelecidas conexões nas portas menores a 1024, como 137, 138, 139. Essas portas atendem serviços portanto. Vamos a elas:

              A porta 139 na realidade é apenas um bug encontrado nas versoes Windows® anteriores a OSR2 e pode ser fechada pelo usuário com programas específicos ou pelo renomeamento de um driver de dispositivo virtual que nesse caso é o vnbt.386. Os efeitos provocados pelo mau uso dessa porta já sao bastante divulgados: isso causa uma pane geral nos sistemas Windows® e mesmo os NTs mais antigos ainda sofrem com esse problema. Não é um nuke propriamente dito porque os efeitos são diferentes. Na realidade aproveita-se a falha que o Windows® possui em atender serviços marcados como urgente (os chamados OOB ou out-of-band). O Windows® da preferencia a pacotes marcados dessa forma e relega a segundo plano as outras conexões que você possui. O efeito é o término da sua conexão TCP/IP.

              Isso significa que alguém poderia tentar usar seu micro com alguma forma de hacking? Provavelmente não. Digo provavelmente porque a porta 139 é usada ainda como brincadeira por muita gente metida a hacker mas que nada mais fazem do que cancelar uma conexão TCP/IP e travar a máquina de um usuário inocente (existem exceções). Brincadeira de criança. Essa porta, portanto, não atende serviços a não ser o de enviar resposta ao pacote OOB.

              As portas 137 e 138 são reservadas ao NetBios (Network Input/Output System) do Windows®. Na verdade não é exclusividade dos sistemas Windows® e pode ser implementado em qualquer máquina. O NetBios foi desenvolvido pela IBM como forma de servir o micro cliente como host servidor em alguns casos específicos. Assim, alguém usando um Windows® 95 poderia disponibilizar essas duas portas para permitir serviços como acesso a uma impressora compartilhada por exemplo. Mas é altamente recomendável que estas portas estejam fechadas. Se você não é usuário de uma rede interna de algum departamento e ninguém usa seu micro como host servidor temporário para, por exemplo, compartilhar sua impressora então não há nenhum motivo para permanecer com essas portas abertas. O usuário dessa configuração de portas precisa urgentemente de uma re-configuração do Windows®. Verifique em seu micro, caso use Windows®, se você está com algum serviço compartilhador de redes como o NetBios. Se está, não permita nenhum compartilhamento então. Isso constitui-se de uma forma de hacking realmente e não é usada por criancas que adoram nukar o usuário inocente, hackers que possuem conhecimento dessas portas abertas (e tem conhecimento da técnica) podem acessar seu micro da forma como quiserem já que essas portas são atendentes de servicos ao contrário da porta 139. O Windows® usando o NetBios vai permitir acesso nesse caso.

              Essa descrição acima (do NetBios) não se constitui de uma falha dos sistemas Windows® propriamente dita - é inclusive anunciada pela Microsoft. É sim uma má configuração do usuário que, por algum descuido, permitiu essa forma de conexão.

              Mas as três portas se encontravam em modo listening o que quer dizer que nenhuma conexão foi estabelecida, o que não significa que não possa ser feito.

              Agora poderia sobrevir uma duvida: "Ok, essas três portas foram estabelecidas e estavam em modo listening mas e quanto ao endereço do host? Por que não foi informado nada?" - Bom, é simples. As portas estavam abertas apenas, todas as três, mas nenhum host externo, naquele momento, estava tentando acessá-las. Exatamente por isso não foi informado nenhum IP de identificação remoto. Possivelmente, quando alguém tentasse firmar uma conexão, o IP seria fornecido.

              As outras portas maiores, acima de 1024 foram estabecidas normalmente no computador local sem problemas. O que acontece é o seguinte: Como expliquei mais acima a respeito de uma conexão telnet, o programa cliente informa a porta na qual devera ser estabelecida a conexão mas não informa a porta local. Isso será feito depois e quem o fara é o seu Sistema Operacional. Assim, o computador remoto, o servidor envia um pacote qualquer de volta ao computador de origem (lembre-se que ele sabe qual o IP de origem) e somente depois disso a porta é aberta. Será que isso seria motivo de preocupação de alguém? Acredito que, infelizmente, a maioria das pessoas ainda temem essas portas abertas quando dão o comando netstat. Na verdade não há o que se preocupar. As portas são estabelecidas temporariamente e depois que a conexão é terminada a porta se fecha, a não ser aquelas que são conhecidas, como o bug do Windows® da porta 139 e/ou as 137 e 138. Se isso não acontecesse ninguém receberia informação de lugar nenhum. Assim, uma porta origem e destino devem ser abertas.