( Publicado originalmente no e-zine CTRL-C nº 01, de novembro/99 )

Como devem imaginar, toda essa história de comunicação, teleinformática e arquitetura TCP/IP tinha um objetivo: falarmos um pouco a respeito dos Phreakers. Agora que já ficou esclarecido como funciona nossa rede de telefonia, podemos analisar essas figuras difíceis que conseguem tirar proveito máximo da rede instalada.

Ao contrário do que pode-se pensar, os phreakers – os quais vejo como precursores dos hackers modernos – não surgiram nessa era digital em que vivemos. Surgiram, praticamente, junto com os telefones. A “Bell Telephone Company”, já no ano de 1878, possuía centenas de jovens contratados para operarem as mesas telefônicas. Estes jovens eram irreverentes, pregavam peças nos colegas e nos assinantes e logo foram substituídos por mulheres, as quais tinham mais responsabilidade no tratamento com o público.

Estes “proto-hackers” criaram tantos problemas que um dos engenheiros da empresa equiparou-os a “índios selvagens”. Inicialmente se dedicavam a enganar as companhias telefônicas e eram chamados de “phone Phreaks” – algo que pode ser toscamente traduzido como “anomalias dos telefones”. Como dominavam plenamente o funcionamento das redes telefônicas, telefonavam sem pagar, transferiam contas, modificavam os sistemas e não deixavam nenhuma marca da sua passagem.

O alvo preferido dos phreakers na década de sessenta era a rede de telefonia a longa distância da AT&T, devido à uma sobretaxa que era cobrada para custear a Guerra do Vietnã (isso não soa familiar? E essa taxa de R$ 2,50 que estão querendo cobrar em nossas contas telefônicas para custear a “comunicação” da polícia militar?…). Pois bem, tantos ataques acabaram gerando uma verdadeira guerra particular, uma guerra que começou quando um certo Mr. John Draper, também conhecido como Captain Crunch, descobriu que numa determinada caixa de cereais vinha de brinde um apito que produzia um tom com a freqüência exata de 2.600 hertz, que era usado pela AT&T para controlar as estações telefônicas. Os phreakers começaram a produzir as chamadas “blue boxes”, “red boxes” e outras enquanto uma certa companhia produtora de cereais não entendia porque, subitamente, suas vendas aumentaram sem explicação aparente…

Em 1978, Ward Christenson e Randy Suess criaram o primeiro BBS pessoal (Bulletin Board System – uma base de dados de mensagens, onde as pessoas podiam se conectar e publicar mensagens para outros grupos). Assim, como já possuíam o controle da rede telefônica de longa distância da AT&T, com o auxílio das BBSs que foram sendo criadas, os hackers criaram um novo mundo privado, livre da interferência do sistema estabelecido – o ciberespaço. Desta feita o phreaking torna-se mais importante que nunca para conexão das BBSs mais distantes.

A troca de experiências, senhas e software através dos meios eletrônicos aumentou o número e a perícia dos phreakers e hackers, estimulando o surgimento de uma estranha confraria secreta, uma subcultura do ciberespaço com seus próprios códigos e regras. Uma cultura onde se competia pelo poder. O poder de controlar o sistema telefônico que é, sem dúvida alguma, a maior e mais complexa máquina já colocada em operação na face da Terra. Dominar um assunto, ou uma técnica é uma forma de poder, é um poder sobre a tecnologia e sobre os mecanismos de segurança dos sistemas. É um sentimento que produz uma sensação de superioridade. Ora, PODER, AVENTURA e ANONIMATO é uma combinação explosiva para aqueles que possuem o conhecimento para tal.

Eles não se consideravam criminosos mas sim uma elite, uma elite acima da lei. Nos primórdios seus códigos proclamavam: primeiro, nada de dinheiro, e segundo, nunca causar danos, não destruir um byte de informação sequer. Para eles o hacking era um jogo, nada mais que um excitante game. Era como entrar invisível em um prédio, poder observar todas as pessoas sem ser notado, ter o poder de destruir tudo e não fazê-lo.

Na medida em que a rede telefônica foi sendo informatizada os phreakers foram se adaptando e desenvolvendo habilidades específicas com os computadores. Com seu domínio da rede telefônica faziam longas chamadas interurbanas e internacionais ligando para parentes, amigos e para sistemas computadorizados em todo o mundo a fim de praticar seu esporte preferido: o hacking. Durante anos eles entraram nos computadores da AT&T e de outras companhias. Qualquer senha descoberta, qualquer falha na segurança de um sistema era rapidamente passada de mão em mão para os outros membros da tribo. Achavam que não estavam fazendo mal algum já que a AT&T não tomava conhecimento do que eles faziam e portanto não haviam chamadas a serem pagas.

Mas na guerra entre a AT&T e os phreakers ocorriam vitórias e derrotas de ambos os lados. Com a melhoria dos sistemas de segurança nas estações da AT&T os phreakers se voltaram para as centrais de PABX dos usuários e conseguiam facilmente telefonar sem pagar. Mas desta vez eles deixavam contas para os donos dos PABXs e essa brincadeira passou a ser encarada como um problema empresarial.

Quando o problema das invasões do sistema telefônico veio a tona no final da década de 80 os especialistas em segurança das empresas telefônicas americanas constataram estupefatos que os phreakers manipulavam com facilidade as estações telefônicas, tinham centenas de contas telefônicas sem nome ou endereço nos bancos de dados da AT&T e conseguiam redirecionar chamadas em qualquer ponto do país e até mesmo do exterior. Até o sistema ReMob (Remote Observation) foi intensamente reprogramado por eles. Usando este recurso eles conseguiam ouvir qualquer conversa telefônica nos EUA!

Um fato insólito ocorreu no dia 13 de junho de 1989: todas pessoas que ligavam para o Departamento da Condicional do Condado de Palm Beach, na Flórida, eram atendidas por um serviço do tipo disk-sexo em Nova Iorque. Alguém havia redirecionado todas as chamadas para um telefone em uma outra cidade e desativado a cobrança das ligações interurbanas. Este evento motivou uma forte reação das autoridades americanas auxiliadas pelos agentes de segurança das companhias telefônicas. O autor da façanha foi o hacker Fry Guy, de apenas 16 anos, que foi preso. Fry Guy (“cara frito”) tinha esse nick por ter conseguido entrar nos computadores do McDonald’s…

Chamo a atenção para o fato de que os Phreakers de outrora naturalmente se tornaram os Hackers da atualidade. No meu ponto de vista o que difere um de outro é simplesmente o grau de especialização atingido pelo primeiro em face do segundo, pois enquanto os phreakers se utilizam de computadores para colocar em prática seus conhecimentos e habilidades, os novos-hackers praticam suas invasões utilizando técnicas de phreaking, sem necessariamente compreender a fundo como funciona o sistema como um todo.

Voltando à nossa resumida história, as hostilidades entre os phreakers/hackers e a AT&T prosseguiram sem alarde durante décadas, principalmente porque não havia interesse da companhia em divulgar para os usuários que intrusos estavam reprogramando seus sistemas e zombando dos seus engenheiros. Isto é comum, pois muitas vezes as empresas não denunciam os ataques que sofrem simplesmente para não perder a credibilidade junto a seus clientes; o que tentam é justamente controlar as invasões através de sistemas conhecidos como “firewalls”, ou seja, programas de segurança. Mas após o dia 15 de janeiro de 1990 o panorama começou a mudar.

A data de 15 de janeiro é um dos mais importantes feriados americanos, o Martin Luther King Day. Ele é considerado o mais político das datas nacionais americanas. E foi também no dia 15 de janeiro de 1990 dois terços da rede de telefonia internacional da AT&T entrou em colapso. Setenta milhões de chamadas telefônicas de longa distância deixaram de ser feitas. Uma estranha reação em cadeia durante algumas horas colocou fora de operação milhares de estações telefônicas. Os engenheiros da AT&T só conseguiram controlar a situação 24 horas depois. Entretanto este formidável acontecimento não foi obra de phreakers mas a consequência de um bug em um recém-instalado programa de gerenciamento das estações telefônicas. Mas já há algum tempo os phreakers vinham espalhando pelos BBS’s que podiam, se quisessem, derrubar a AT&T. Mesmo não tendo sido eles os autores do colapso os engenheiros da AT&T e de outras companhias perceberam que eram uma ameaça verdadeira e que poderiam, se quisessem, levar realmente todo o sistema ao colapso. Além de quê, era muito mais cômodo jogar a culpa neles que assumir o próprio erro.

As companhias telefônicas conseguiram sensibilizar a comunidade de segurança dos EUA atentando com o perigo de um colapso proposital do sistema telefônico e a possível repercussão sobre instalações militares. No decorrer do ano de 90 a comunidade hacker sofreu uma enorme perseguição numa operação conjunta da procuradoria do Arizona, o Serviço Secreto e o FBI, que ficou conhecida como a OPERAÇÃO SUNDEVIL.

Mas aí já é outra história…

Bem, como sempre costuma acontecer comigo na hora de definir um conceito, eu SEI o que é Phreaker, mas como passar todas as nuances que a palavra traz? Fui buscar em meus dicionários – que, diga-se de passagem, devem estar todos desatualizados – não encontrei nada. Ato contínuo, uma busca na Rede. Nada que se aproveitasse. Então lembrei-me de um arquivo que estava perdido em algum lugar em meu HD: The Jargon File 4.0. Apesar de ser de meados de 96, consegui uma definição bem melhor que as que encontrei por aí (a propósito, já baixei a versão mais nova – a 4.1.4 – e a definição continua a mesma…). Vejamos:

:phreaker: Aquele que se ocupa com phreaking.

Legal. E daí? Se eu já não soubesse o que significa, iria me sentir meio que abobalhado, da mesma maneira que fico quando minha esposa me explica algo com palavras em japonês e ainda quer que eu entenda… Bem, vamos em frente:

:phreaking: [de ‘phone phreak’] 1. A arte e ciência de violar a rede telefônica (de forma que, por exemplo, se possa fazer chamadas de longa distância – interurbanos – gratuitas). 2. Por extensão, violação de segurança em qualquer outro contexto (especialmente, mas não exclusivamente, em redes de comunicações).

“Algumas vezes o phreaking era uma atividade quase-respeitável entre hackers; havia um acordo de cavalheiros de que o phreaking como um jogo intelectual e uma forma de pesquisa seria aceitável, mas roubos graves eram tabu. Havia uma substancial troca de informações entre a comunidade hacker e os phreakers da pesada que construíam redes de comunicações clandestinas de sua própria autoria, troca esta que se dava através de alguma mídia, como a legendária “TAP Newsletter”. Entretanto essas tribos começaram a “pegar pesado” em meados dos anos 80, na medida que houve uma larga disseminação de técnicas de ataque que deixavam as centrais telefônicas nas mãos de uma pequena quantidade de phreaks irresponsáveis. Aproximadamente na mesma época mudanças na rede telefônica fizeram com que as velhas técnicas de invasão ficassem sem efeito, de modo que o phreaking passou a depender mais de atos evidentemente criminosos, tal como roubar números de placas de expansão de centrais telefônicas. Os crimes e punições de gangues como do “Grupo 414” transformaram o phreaking em um jogo difícil. Uns poucos hackers dos velhos tempos continuam praticando o phreak casualmente apenas para “treinar a mão”, mas atualmente a maioria dificilmente ouviu falar das “blue boxes” ou qualquer outra parafernália dos grandes phreaks de antigamente”.

Tá, não ajudou muito, mas é um começo. Os Phreakers, na realidade, são ténicos altamente especializados em telefonia – conhecem as centrais telefônicas por dentro e por fora, de modo que sabem quais são os seus pontos fracos que podem ser explorados. Sabem reprogramar essas centrais, fazer instalação de escutas, etc. Seu conhecimento é tal que, aliado à informática, torna possível que ataques a um sistema tenha como ponto de partida provedores de acessos de outros países, pois suas técnicas permitem não somente ficar invisível diante de um provável rastreamento, como também forjar um culpado pela ligação fraudulenta.

Na realidade não há magia no que eles fazem. A maioria das informações, truques e segredos podem inclusive ser encontradas na própria Internet. Nos dias de hoje atividades suspeitas relacionadas exclusivamente à telefonia não fazem mais parte do mundo hacker. Considero que os últimos remanescentes dos “verdadeiros” Phreakers são os profissionais que trabalham com segurança, mais especificamente em espionagem industrial e afins.

Entretanto, na hierarquia que se criou no ciberespaço, também existe a figura do Phreaker. Mas e então? Qual dos dois é legítimo? Ambos, é claro. Pelo menos no meu entendimento. O que ocorre é que um Hacker, para poder se considerar como tal, deve TAMBÉM ser um Phreaker. Ou pelo menos ter um conhecimento considerável sobre phreaking.

E juridicamente, como ficamos? Ora, uma coisa não se mistura com a outra. Uma posição que sempre vou defender é a de que um genuíno Hacker não oferece perigo algum para o Sistema. Infelizmente a mídia atual não ajuda muito, pois qualquer tipo de invasão ou furto eletrônico que ocorra e pronto – lá vem eles dizendo que um hacker entrou em algum sistema e foi responsável por tudo. Há que se criar uma distinção definitiva entre Hacker e Cracker (ou qualquer outra nomenclatura válida) para diferenciar o joio do trigo.

Pior ainda são alguns auto-intitulados “hackers” que se apresentam em público dizendo que podem invadir qualquer sistema e ajudam a disseminar essa paranóia. Pode parecer exagero, mas vejam um caso real da força da mídia: há algum tempo a maior rede de tv do país – não vou citar o nome da Globo que é para não me meter em encrenca >;) – fez uma chamada em um telejornal do horário de almoço que hackers estariam acessando as conta-correntes de bancos e desviando fundos.

Pois bem, estava eu almoçando na casa de meus pais quando ouvi essa chamada. Não é preciso dizer que dei um vôo rasante para perto da televisão para ver o que é que estava pegando. Após muita embromação e num tom completamente fora de propósito soltaram uma reportagem de alguns minutos que, por incrível que pareça, não acrescentou absolutamente nada ao que foi dito na chamada. Não disse se algum banco havia sido invadido, se alguém levou prejuízo, em que estado ou país isso estaria acontecendo, como estaria sendo feito, enfim, nada. Até meu pai, que estava do meu lado e entende praticamente nientes de informática, foi veemente em concordar a inutilidade daquela notícia.

Voltei para o escritório confabulando comigo mesmo nos absurdos da mídia e no estrago que informações como essa poderiam causar no dia a dia de pessoas menos esclarecidas no assunto. É óbvio que existem alguns poucos profissionais que teriam o dom e a capacidade de burlar todo um sistema de segurança de um banco para poder efetuar um desvio não autorizado em uma conta-corrente e não ser detectado, mas nada tão simplista como havia sido enfocado na reportagem. Mesmo assim, pasmem, no momento em que cheguei no escritório recebi de imediato uma ligação de uma grande amiga querendo saber de tudo quanto é jeito como é que ela poderia remover completamente o programa de acesso ao banco que estava instalado em seu computador. Ela havia visto a reportagem…

Ops, dei uma viajada. Tudo bem, estávamos falando de Phreakers, certo?

Na realidade, não temos muito mais o que falar a respeito dos Phreakers, pois é o tipo de atividade que está definida em si mesmo: um expert em telefonia. Na clássica comparação com o chaveiro comum, ele tem o conhecimento para abrir as portas de qualquer sistema telefônico, entretanto somente se tornará um criminoso se utilizar esse conhecimento com fins também criminosos.

Essa matéria comportaria também uma análise mais detalhada dessas atividades, bem como o uso das famosas “boxes” – dispositivos ou esquemas de ligação que permitem ao usuário obter vantagens ou comodidades dos sistemas telefônicos (e que, ao contrário do que se possa pensar, nem sempre têm caráter ilegal). Mas, devido à legislação, esse Zine já está três vezes maior que o número anterior. Assim, vamos deixar um gostinho de quero mais e concluir essa matéria num futuro (quiçá) bem próximo.

( Publicado originalmente no e-zine CTRL-C nº 01, de novembro/99 )

Para possibilitar a interconexão de diferentes equipamentos informáticos através das diferentes redes de comunicações faz-se necessário estabelecer uma série de normas que incluem os requisitos físicos e os procedimentos a serem seguidos. Disso se encarregam diversos organismos internacionais, entre os quais a ISO (International Standard Organization) e o CCITT (Consultive Committe for International Telephone and Telegraph).

Antes das normatizações, cada fabricante estabelecia suas próprias normas ou protocolos, o que impossibilitava a comunicação entre equipamentos de diferentes fabricantes.

Assim, podemos definir como protocolo de comunicações o conjunto de convenções e procedimentos que regulamentam a transmissão de dados entre diferentes equipamentos, completamente ou em alguns de seus aspectos. Ou seja, graças ao protocolo de comunicações é que os computadores conseguem se comunicar, “falando a mesma língua”.

A organização ISO definiu a normatização de comunicações entre equipamentos informáticos estabelecendo sete níveis no que se refere à arquitetura:

1. Físico – define as características dos equipamentos e requisitos para a realização das ligações entre um terminal e um modem.

2. Ligação/Enlace – define os meios e procedimentos para a transmissão de blocos de informação e controle dos possíveis erros que possam ocorrer.

3. Rede – define o intercâmbio de informação dentro de uma rede de teleprocessamento. Trata do agrupamento de quadros em pacotes, do endereçamento e da detecção e correção de erros.

4. Transporte – trata da transferência de mensagens, do agrupamento dos pacotes de dados (mensagens) e da sua decomposição, relacionando-se desta forma com o nível inferior.

5. Sessão – o seu principal objetivo é o controle das operações realizadas sobre os dados, a fim de assegurar a sua integridade com respeito ao uso compartilhado dos mesmos. Neste nível agrupam-se as mensagens relacionadas estabelecendo uma sessão, cada uma das quais devendo ser independente das demais.

6. Apresentação – trata da organização das entradas e saídas, definindo os formatos necessários dos terminais, os arquivos e os trabalhos, a fim de que possam ser utilizados pela sessão e pela aplicação do usuário.

7. Aplicação – a sua principal função consiste no controle e supervisão dos processamentos de usuários que se intercomunicam.

Mas o que verdadeiramente importa, no nosso caso, é a arquitetura TCP/IP – o protocolo de comunicação oficial utilizado na Internet. E dá-lhe história !

Tudo começou na década de 60, com o Comunismo no auge e a chegada de armas nucleares em Cuba. Nos Estados Unidos foi sentido um grande aumento das pressões imposta pela Guerra Fria – que também estava sendo travada em laboratórios de pesquisa patrocinados pelo governo, pois tinha-se como regra que a habilidade de criar e manter vantagens tecnológicas sobre o adversário é que determinaria o vencedor do conflito.

Assim, quando a década de 60 aproximava-se do final, a maioria dos centros de pesquisa financiados pelo governo e universidades já estavam equipados com os melhores recursos computacionais disponíveis à época. Era primordial providenciar a conexão destes centros, mas, para atender aos militares “donos do dinheiro” havia um fator determinante a ser respeitado na escolha da tecnologia de rede a ser utilizada: a informação deveria continuar a fluir, mesmo sob as piores condições possíveis, tal como um ataque nuclear.

Em 1957 havia sido criado a ARPA (Advanced Research Projects Agency), ligada ao Departamento de Defesa (DoD) – diga-se de passagem que sua criação teve por intuito fazer frente ao lançamento do satélite Sputnik por parte da União Soviética. E foi delegado à ARPA a responsabilidade de desenvolver a tecnologia de rede necessária.

Para resolver a questão a ARPA financiou um projeto para a empresa BBN (Bolt Beranek and Newman) para desenvolver um modelo de comunicações que se aplicasse ao caso. Assim, em 1969, a BBN apresentou um protocolo de rede comutada por pacotes denominada NCP (Network Control Protocol) e desenvolveu um computador para controlar a rede, denominado IMP (Information Message Processor), que foi instalado na UCLA, em Los Angeles. No ano seguinte a primeira rede comutada por pacotes já estava em funcionamento, conectando quatro localidades nos estados da Califórnia e Utah: a UCLA, em Los Angeles; o SRI (Stanford Research Institute); a UCSB, em Santa Bárbara; e a Universidade de Utah. Surgia a ARPANET – Advanced Research Projects Agency Network.

Em 1972, 40 diferentes localidades já estavam conectadas à ARPANET. Nesse ano houve o primeiro ICCC (International Conference on Computer Communications), sediado em Washington, que buscava um consenso sobre protocolos de comunicação entre computadores e redes distintas. Foi instituído o INWG (InterNetwork Working Group), um grupo responsável pela criação de um protocolo que pudesse ser utilizado para a comunicação entre a maioria das redes de computadores do mundo, e cujo primeiro moderador nomeado foi Vinton Cerf. Por sua vez a DARPA (Defense Advanced Research Projects Agency), antiga ARPA, iniciou um projeto para investigar as formas possíveis de conexão entre redes de pacotes comutados.

Como resultado destes estudos foram desenvolvidos e apresentados os dois protocolos básicos da Internet. Em 1974, Vinton Cerf e Robert Kahn apresentaram o IP (Internet Protocol) e o TCP (Transmission Control Protocol), que especificavam a forma pela qual as mensagens (arquivos ou comandos) seriam transferidos entre os computadores na Internet.

Em que pese o conjunto de protocolos TCP/IP não pertencer a nenhuma organização, entidade ou fabricante específico, existe uma organização responsável pela padronização, documentação e desenvolvimento da arquitetura TCP/IP e da Internet: é o IAB (Internet Activities Board), o qual é dividido em dois grandes grupos, o IETF (Internet Engineering Task Force) – que concentra seus esforços em problemas de engenharia de curto e médio prazo, e o IRTF (Internet Research Task Force) – que coordena as atividades de pesquisa.

As propostas para revisão ou criação de protocolos relacionados ao TCP/IP são documentadas através de relatórios técnicos, conhecidos como RFCs (Request for Comments). As RFCs podem ser pequenas ou grandes, podem cobrir aspectos gerais ou apenas detalhes, e podem ser padrões ou meramente propostas para um novo protocolo ou modificação do já existente.

Já a função de organizar e distribuir toda a documentação, assim como a administração de nomes de domínio e faixas de endereço IP foi atribuída ao NIC (Network Information Center).

Bem, até aqui vimos um pouco de história e um pouco de padronização. Agora vem a parte para fundir os miolos. Diga a verdade, você nunca se perguntou o que significam aqueles números e nomes esotéricos que utilizamos para conexão em diversos sites? Pois é, vou revelar a cabala que existe neles. Ah, seria totalmente impossível repassar estas informações se não fosse o excelente artigo escrito muitos anos atrás por Alexandre Martins Gomes, especialista em redes e consultor de informática, seja lá ele quem for. ADVERTÊNCIA: a leitura a seguir contém fortes elementos maçantes para os “não-iniciados”, sendo plenamente recomendável para casos de insônia profunda.

O endereço IP é uma estrutura virtual, totalmente implementada em software, de modo a haver plena liberdade para a escolha do formato e tamanho dos pacotes, endereços, etc, já que nada é ditado pelo hardware. Ou seja, a cada máquina participante de uma rede IP é atribuído um endereço IP único de 32 bits que é utilizado em todas as comunicações com aquela máquina.

Conceitualmente, cada endereço é formado por um par, onde o primeiro identifica a rede (net_id), e o segundo identifica a máquina dentro desta rede (host_id). Na prática, cada endereço IP deve possuir uma das três primeiras formas abaixo:

 Classe A
 0 + 7 bits + 24 bits = 32 bits
 - o campo de 7 bits representa a rede
   e o de 24 representa a máquina

 Classe B
 10 + 14 bits + 16 bits = 32 bits
 - o campo de 14 bits representa a rede
   e o de 16 representa a máquina

 Classe C
 110 + 21 bits + 8 bits = 32 bits
 - o campo de 21 bits representa a rede
   e o de 8 representa a máquina

 Classe D (Endereços de Multicast)
 1110 + 28 bits = 32 bits

 Classe E (Reservado para utilização futura)
 11110 + 27 bits = 32 bits

 
Assim, a partir de um determinado endereço IP, podemos descobrir sua classe observando os três bits de maior magnitude, sendo que precisamos de apenas dois para distinguirmos entre as três primeiras classes. A tabela abaixo especifica o número máximo de redes de cada classe, assim como o número máximo de host_id suportado por cada rede.

Classe                                A        B           C

Nr. de bits para net_id               7       14          21
Nr. de bits para host_id             24       16           8
Nr. máximo teórico de redes         128   16.384   2.097.152
Nr. máximo teórico  de  nós  16.777.216   65.536         256
    por rede

 
Observando essa tabela, pode parecer um absurdo alguém querer ou mesmo precisar construir uma rede que possua mais de 16 milhõees de nós, ou até mesmo 65.536; porém, quando a técnica de “subnetting” (RFC 950) é utilizada, ganhamos muito mais flexibilidade para criar um grande número de redes físicas distintas utilizando apenas uma faixa de endereço IP.

Como estamos acostumados a trabalhar na base decimal, a representação em binário de um endereço IP fica um tanto complicado, pois possui um total de 32 números. Tendo isto em vista, foi adotada a notação decimal pontuada (dotted decimal notation) para a representação daqueles números. Como exemplo, abaixo temos um inteiro de 32 bits e logo a seguir seu correspondente:

 11001000 10110010 00010001 00000001 = 200.178.17.1

 
Existem, porém, alguns endereços IP especiais, a saber:

net_id    host_id   SIGNIFICADO     OBSERVAÇÃO

todos     todos     este            permitido apenas na
zero      zero      nó              inicialização do sistema,
                                    nunca sendo um endereço
                                    de destino válido

todos     host      nó              permitido apenas na
zero                nesta           inicialização do sistema,
                    rede            nunca sendo um endereço
                                    de destino válido

todos     todos     broadcast       não é um endereço de
um        um        limitado        origem válido

net       todos     broadcast       não é um endereço de
          um        direcionado     origem válido
                    para a rede
                    net

 
Qualquer endereço válido da rede classe A 127.0.0.0 (127.0.0.1 a 127.255.255.254) são reservados para loopback e foram projetados para testes e comunicações entre processos na máquina local. A título de teste, experimente pingar o endereço 127.0.0.1 em sua máquina e observe o resultado.

Por fim, endereços IP podem ser utilizados para referenciarmos redes, nós individuais ou todos os nós da rede. Por convenção, o endereço de rede possui a parte host_id com todos os bits em zero e o endereço de broadcast da mesma rede possui a parte host_id com todos os bits em um. Em resumo, se uma rede possui, teoricamente, n endereços disponíveis, na verdade a quantidade de endereços realmente disponíveis é n-2, já que um endereço IP é reservado para a rede em si e outro é reservado para broadcast. Maiores informações nas RFCs 990 e 997.

Well, devemos ter em mente que para duas máquinas efetivamente se comunicarem dentro de uma mesma rede IP, isto é feito através de um meio físico (linha telefônica, cabos de rede, ondas de rádio, etc). O hardware de cada um destes equipamentos possui um endereço específico e completamente sem vínculo com o endereço IP, o qual é apenas uma abstração genérica. Ou seja, a única forma de selecionarmos uma máquina entre várias é pelo endereço da interface de hardware, que chamaremos de endereço físico.

Existem algumas técnicas para a resolução de endereços, porém a mais utilizada é a Amarração Dinâmica, implementada através do protocolo ARP (Address Resolution Protocol). Funciona da seguinte maneira:

Suponhamos que a máquina A (192.10.10.1) tenha que enviar uma informação para a máquina B (192.10.10.2), ambas participantes da mesma rede IP. A máquina A sabe o endereço IP da máquina B, mas não seu endereço físico, o qual é essencial. Desta forma, antes que a máquina A possa enviar a informação, esta enviará um ARP request em broadcast (todas as máquinas daquela rede “escutarão” a requisição) com o seguinte pedido: “APENAS a máquina que possuir o endereço IP 192.10.10.2, favor responder”. Se a máquina B estiver ligada e funcionando corretamente, atenderá esse pedido enviando seu endereço de hardware para a máquina A. Neste momento, a máquina A “aprenderá” o endereço físico da máquina B e então poderá efetuar a transmissão da informação.

Por questões de eficiência, existe uma área reservada em memória que contém uma espécie de cache de resolução de endereços, pois se a cada informação que A precisasse enviar para B fosse precedida de um broadcast a fim de resolver endereços, provavelmente o desempenho seria comprometido. Neste caso, se for enviada uma segunda informação de A para B, não mais será necessário o ARP request, uma vez que A já sabe o endereço físico de B. Maiores detalhes na RFC 826.

Com relação ao roteamento (o caminho a se percorrer para entregar a informação), podemos dividir o problema em dois grupos: roteamento direto e roteamento indireto.

O roteamento direto é utilizado quando duas máquinas estão conectadas diretamente numa mesma rede, o que é facilmente verificável através da análise de semelhança entre o net_ide e host_id de ambas as máquinas.

O roteamento indireto é necessário quando a máquina destino não está diretamente conectada à rede da máquina de origem, forçando o transmissor a enviar a informação para um gateway. Gateway é um dispositivo que conecta duas redes locais diferentes, ou uma rede local e uma rede remota; possui processador e memória próprios, podendo fazer a conversão de protocolos e de larguras de banda.

No roteamento indireto o transmissor deve enviar a informação para um gateway e este deverá determinar o melhor caminho para alcançar a rede dstino e enviá-la. Concluímos, pois, que existem múltiplos caminhos para uma origem chegar a um destino, sendo que o gerenciamento destas rotas pode ser administrado manualmente (sempre que uma nova rota for adicionada ou removida, alguém deve “reprogramar” os gateways) ou dinamicamente, isto é, os próprios gateways trocarão informações sobre as tabelas de roteamento e adicionarão ou removerão rotas quando for necessário.

Justamente por isso temos o ICMP (Internet Control Message Protocol), que provê aos gateways e aos hosts um mecanismo para reportar informações de controle ou erro. As mensagens ICMP são enviadas em várias situações, como, por exemplo: quando uma informação não consegue alcançar seu destino ou quando um gateway informa a um host a existência de uma rota mais curta. Existem alguns utilitários que nos permitem gerar mensagens ICMP, normalmente com objetivo de testar a rede, parte dela, ou um host/gateway específico. Os mais utilizados são PING e TRACEROUTE.

O utilitário ping gera um ICMP ECHO_REQUEST para obter um ICMP ECHO_RESPONSE de um host ou gateway. É útil para determinação do estado da rede; descobrir e isolar problemas de hardware e software; testar, medir o desempenho e gerenciar redes. Por default o ping envia uma informação por segundo e imprime uma linha para cada resposta recebida. Podemos obter, ainda, algumas estatísticas, como tempo médio de resposta e taxa de perda de pacotes.

Já o utilitário traceroute determina a rota utilizada até um destino enviando pacotes ICMP_ECHO com o TTL (Time-To-Live) variando. Cada gateway ao longo da rota decrementa o TTL de pelo menos uma unidade antes de propagá-lo. Quando o TTL de um pacote chega a zero, o gateway envia a origem uma mensagem ICMP_TIME_EXCEEDED. Assim o traceroute determina a rota enviando o primeiro ICMP_ECHO com um TTL igual a 1, incrementando-o de uma unidade a cada transmissão subsequente, até que o destino responda ou o TTL máximo seja alcançado. A rota é determinada observando-se as mensagens de ICMP_TIME_EXCEEDED dos gateways intermediários. Maiores detalhes, RFC 792.

Uma vez que entendemos como as redes se distinguem na Internet, agora precisamos verificar de perto como funciona o endereçamento completo, ou seja, as sub-redes. A forma mais fácil para o entendimento do endereçamento de sub-rede é imaginarmos a seguinte situação: uma organização obteve junto ao NIC o seguinte endereço classe B: 158.56.0.0 (conforme já vimos, número máximo teórico de 65.536 endereços IP); considerando que possui 5 escritórios em cidades diferentes e que cada escritório possui 150 computadores, como seria possível conectar todas as 5 redes sob o mesmo endereço classe B, já que para cada rede distinta é necessário um endereço IP distinto?

A solução se baseia na forma de como um endereço IP é interpretado. Antes da padronização do endereçamento de sub-rede, o endereço IP era dividido em 2 partes (um prefixo para a rede e um sufixo para o host). Agora, as duas partes identificam uma porção para rede e uma porção para endereçamento local. Esta última porção ainda pode ser dividida em duas, a saber: rede física e host.

Portanto, estamos aptos a resolver satisfatoriamente o exemplo proposto. Como cada rede local é composta de 150 máquinas, precisaremos de 8 bits para representar cada host em cada rede física. A porção rede já foi definida pela NIC (158.56), utilizando 16 bits. Como o IP é um identificador de 32 bits, sobraram 8 bits para representarmos a rede física. Um dos possíveis resultados seria:

 Rede 1 - 158.5.10.0
 (endereços IP válidos: 158.56.10.1 à 158.56.10.254)

 Rede 2 - 158.5.11.0
 (endereços IP válidos: 158.56.11.1 à 158.56.11.254)

 Rede 3 - 158.5.12.0
 (endereços IP válidos: 158.56.12.1 à 158.56.12.254)

 Rede 4 - 158.5.13.0
 (endereços IP válidos: 158.56.13.1 à 158.56.13.254)

 Rede 5 - 158.5.14.0
 (endereços IP válidos: 158.56.14.1 à 158.56.14.254)

 
Neste caso, podemos fazer a seguinte associação ao endereço IP 158.56.12.15:

 158.56 - identifica a organização (site);
 .12 - identifica a rede física no site;
 .15 - identifica o host na rede física.

 
É importante observarmos que a associação supra só foi possível devido ao fato de conhecermos o número de bits utilizado para representar os hosts em cada rede física. O nome formal do identificador que contém esta informação é subnet mask (máscara de sub-rede). A subnet mask também é um identificador de 32 bits e seu conteúdo pode ser interpretado da seguinte forma: quando os bits na máscara são setados em 1, os bits correspondentes do endereço IP são tratados como parte do endereço da rede; caso contrário, são tratados como parte do identificador do host.

Em nosso exemplo, todas as redes têm máscara 255.255.255.0, ou seja, os três primeiros bytes identificam a rede e o último identifica um host numa determinada rede. De posse desta informação, podemos garantir que os endereços 158.56.12.15 e 158.56.12.89 pertencem à mesma rede. O mesmo não acontece para os endereços 158.56.13.45 e 158.56.14.1. Cabe ressaltar que esta análise do terceiro byte só é válida quando a máscara de sub-rede for 255.255.255.0, em outros casos deve-se proceder a uma comparação através de um “E” booleano. Vide RFC 950.

Na arquitetura TCP/IP temos que o objetivo básico dos protocolos de transporte é prover um mecanismo de multiplexação, permitindo que processos diversos em uma determinada máquina possam se comunicar com um ou mais processos em outras máquinas simultaneamente. Para isso são utilizados dois protocolos de transporte com características bastante distintas, o UDP (User Datagram Protocol) e o TCP (Transmission Control Protocol).

O UDP utiliza os serviços do IP para transportar as mensagens de uma máquina para outra. Porém não existe a garantia da entrega das mensagens, já que o UDP não utiliza acknowledgements (reconhecimentos) para assegurar a chegada das mesmas, de modo que podem ser perdidas, duplicadas, entregues fora de ordem ou os pacotes podemser recebidos numa taxa mais elevada do que o destinatário possa processar. Porém, existe um ponto positivo na utilização do UDP: desempenho. O processamento de suas mensagens gera um overhead bastante pequeno, possibilitando uma maior taxa de transferência. Como exemplo, uma das aplicações mais conhecidas que utilizam o UDP é o NFS (Network File System). Maiores referências na RFC 768.

Já o protocolo TCP especifica o formato dos dados e dos acknowledgements que duas máquinas trocam para obter uma transferência de dados confiável, assim como os procedimentos utilizados para assegurar que os dados chegaram ao destino corretamente. Detalhes em RFC 793.

Se você chegou até aqui, parabéns! Você realmente promete, pequeno gafanhoto… Antes que me perguntem o porquê de colocar um texto tão técnico no que “deveria” ser um e-zine jurídico, permita-me lembrar (mais uma vez) que somente através do conhecimento detalhado do funcionamento da Rede é que se tornará viável a criação de uma legislação mais de acordo com a realidade. Para finalizar, o autor do texto original no qual este foi baseado, Alexandre Martins Gomes, recomenda o livro Internetworking with TCP/IP, v. I, de Douglas E. Comer, Editora Prentice Hall International Editions. Se alguém achar, me avise.