Reflexões Sobre Segurança Durante Pane da GVT

Percebi ontem pela manhã o que parecia ser uma falha de roteamento ou em algum ponto de troca de tráfego da GVT, a provedora do link ADSL aqui da minha residência. Consigo acessar sites no Brasil, mas não fora dele – consigo acessar o site Folha de São Paulo, por exemplo, mas o da Wikipedia, não. Resolvi acompanhar e relatar o incidente, entremeando-o com algumas reflexões sobre segurança contra indisponibilidade, segurança contra acesso indevido e um pouquinho de segurança jurídica.

Um rápido traceroute confirma o problema:

[email protected]:~$ traceroute blog.tempest.com.br
traceroute to blog.tempest.com.br (76.74.239.147), 30 hops max,
40 byte packets
 1  plunder (XXX.XXX.XXX.XXX)  
    1.499 ms  2.354 ms  3.298 ms
 2  dinky (XXX.XXX.XXX.XXX) 
    19.097 ms  19.673 ms  20.218 ms
 3  189.115.166.1.dynamic.adsl.gvt.net.br (189.115.166.1)
    20.790 ms  21.329 ms  21.916 ms
 4  corporativo.gvt.net.br (189.115.160.2)
    22.436 ms  23.013 ms  23.535 ms
 5  gvt-host.gvt.net.br (189.59.244.197)
    55.484 ms  56.119 ms  56.800 ms
 6  gvt-po-4-2-0-rc01.sdr.gvt.net.br (189.59.244.106)
    84.595 ms  83.733 ms  84.284 ms
 7  * * *
 8  * * *

Nesse rastreamento e nos demais que vou mostrar, cada linha numerada representa um roteador – um computador intermediário especializado em receber os dados e repassá-los para o próximo trecho.

O roteador chamado "plunder", o primeiro no rastreamento, é um switch cabeado + ponto de acesso sem fio, modelo DLink DIR-300 (rodando um dd-wrt Linux). Se você tem banda larga e Wifi em casa, provavelmente tem algum brinquedinho semelhante.

O roteador "dinky", o segundo "hop" no rastreamento, é o modem ADSL da GVT. Ele se localiza fisicamente na minha residência, mas pertence à GVT. Foi esse modem que o técnico da GVT veio instalar aqui na minha residênica quando contratei o serviço, há vários meses atrás. Esse modem se conecta à uma fiação na minha residência, que passa pela fiação do prédio, segue pelos postes nas ruas ao redor até chegar se ligar a outro roteador conhecido como "concentrador ADSL" em algum lugar aqui no meu bairro que eu, por sinal, nem sei onde é. A turma de telecom chama esse trecho de "a última milha".

Eu mascarei alguns endereços IP para aderir à convenção de não revelar muitos detalhes de redes internas.

Daí em diante os meus dados, congregados com os de vários outros assinantes do meu bairro, segue por vários outros roteadores, cujos endereços IP podemos ver no rastreamento. Alguns deles têm nome, outros não, sendo distinguíveis apenas pelo seu endereço IP. Alguns respondem às sondas do programa traceroute, outros não – esses aparecem com três asteriscos. É o que se vê a partir do sexto trecho: nada mais responde. O problema deve estar ali, mas, sem conhecermos o mapa da rede da GVT, não tenho como identificar a natureza exata do problema nem avaliar sua gravidade, dimensões, nem tampouco ajudar. Só me resta aguardar que eles resolvam.

Confirmei que o problema era mesmo restrito à GVT acionando o HSDPA do meu celular e prontamente consegui acessar vários sites que não estava conseguindo pelo notebook.

Todavia, o problema se limitava a sites estrangeiros. Eis abaixo o resultado do traçado de rota até o Google Brasil:

traceroute to www.google.com.br (64.233.163.104), 30 hops max, 40 byte packets
 1  plunder (XXX.XXX.XXX.XXX)
    1.408 ms  2.256 ms  3.207 ms
 2  dinky (XXX.XXX.XXX.XXX)
    17.733 ms  18.247 ms  18.799 ms
 3  * * *
 4  corporativo.gvt.net.br (189.115.160.2)
    19.448 ms  19.991 ms  20.535 ms
 5  gvt-ge-4-1-2-rd02.rjo.gvt.net.br (189.59.244.49)
    68.501 ms  69.226 ms  70.129 ms
 6  gvt-ge-7-0-0-rc02.spo.gvt.net.br (189.59.248.113)
    80.216 ms  79.612 ms  65.271 ms
 7  189.59.249.74.static.host.gvt.net.br (189.59.249.74)
    66.489 ms  67.746 ms  68.957 ms
 8  gvt-ge-0-1-4-rc01.spo.gvt.net.br (189.59.248.61)
    70.380 ms  71.022 ms  71.799 ms
 9  * * *
10  209.85.249.232 (209.85.249.232)
    67.723 ms  69.016 ms  69.693 ms
11  72.14.233.95 (72.14.233.95) 84.569 ms 
    72.14.233.91 (72.14.233.91)  72.313 ms  73.406 ms
12  64.233.175.54 (64.233.175.54)
    71.205 ms  71.919 ms  72.455 ms
13  * * *

O último hop falhou porque o Google, tal como muitos outros sites, bloqueia os pacotes UDP usados por padrão como sondas pelo traceroute do Linux. Todavia, o acesso estava ok. Basta ver pela semelhança entre o IP do penúltimo hop com o IP de destino originalmente reportado pelo DNS. Além disso, acessando pelo navegador, funcionava perfeitamente.

Curiosamente, havia rota funcionando entre a minha casa e a Tempest; e, logando remoto via SSH lá, também constatei que da Tempest o problema não existia – outra confirmação que se trata de um problema restrito à GVT. Isso também me permitiu facilmente circunavegar o problema – acionei minha VPN com a Tempest e usei os seguintes comandos no meu Linux para reconfigurar minhas rotas para que quase todo meu tráfego para a Internet passasse "por dentro" da VPN da Tempest:

route add -host ip_do_endpoint_da_VPN_da_Tempest gw plunder
route add default gw ip_do_endpoint_interno_da_VPN_da_Tempest

Isso, naturalmente, aumenta um pouco a latência média do meu acesso, pois passa a haver mais hops entre eu e meus destinos. Mas, pelo menos, passou a funcionar:

traceroute to blog.tempest.com.br (76.74.239.147), 30 hops max, 40 byte packets
 1  vpn-tsi-ingress (XXX.XXX.XXX.XXX)
    247.230 ms  247.802 ms  247.817 ms
 2  vpn-tsi-egress (XXX.XXX.XXX.XXX) 
    247.823 ms  247.829 ms  247.838 ms
 3  ebt-rec-tsi-gw (XXX.XXX.XXX.XXX)
    247.845 ms  247.854 ms  247.855 ms
 4  ebt-G3-1-bras01.spo.embratel.net.br (200.230.242.21)
    247.858 ms  298.665 ms  386.981 ms
 5  ebt-C2-core03.spo.embratel.net.br (200.230.243.18)
    387.046 ms  440.809 ms  440.903 ms
 6  ebt-G0-3-3-1-tcore01.spo.embratel.net.br (200.230.251.189)
    587.831 ms  464.056 ms  320.098 ms
 7  ebt-T0-5-3-0-intl01.nyk.embratel.net.br (200.230.251.22)
    434.081 ms  434.542 ms  434.577 ms
 8  12.90.4.41 (12.90.4.41)
    434.580 ms  434.600 ms  434.602 ms
 9  cr1.n54ny.ip.att.net (12.123.2.18) 434.615 ms 
    cr1.n54ny.ip.att.net (12.122.131.242)  463.894 ms 
    cr1.n54ny.ip.att.net (12.123.2.18)  434.645 ms
10  cr2.cgcil.ip.att.net (12.122.1.2)  
    434.573 ms  463.750 ms  618.445 ms
11  cr1.cgcil.ip.att.net (12.122.2.53) 
    618.480 ms  618.511 ms  618.452 ms
12  cr2.dvmco.ip.att.net (12.122.31.85) 
    497.074 ms  563.905 ms  386.073 ms
13  cr1.slkut.ip.att.net (12.122.30.25)
    454.090 ms  454.116 ms  454.105 ms
14  cr2.la2ca.ip.att.net (12.122.30.30)
    454.092 ms  454.084 ms  454.073 ms
15  cr84.la2ca.ip.att.net (12.123.30.249)
    581.412 ms  581.471 ms  581.578 ms
16  gar2.lsrca.ip.att.net (12.122.129.49)
    581.465 ms  581.483 ms  582.226
17  12.118.130.42 (12.118.130.42)
    582.240 ms  389.943 ms  570.160 ms
18  * * *

Dá pra ver o rastreamento até a borda da rede da AT&T americana, quando então entra na rede do ServerBeach, um dos nossos provedores de hospedagem, onde é bloqueado pelo firewall de borda deles. Todavia, conectando-me com o navegador no site do blog funciona perfeitamente bem.

Particularmente interessante nesse rastreio é o nono item. Note que cada uma das três respostas vieram de dois endereços IPs diferentes. Esse é um dos vários casos onde fica evidente que há mais de um caminho entre dois pontos na Internet.

Note ainda que todo o caminho entre minha casa e a Tempest ficou "abstraído" no primeiro hop, por causa da VPN.

Outra maneira que eu poderia ter usado para circunavegar essa falha da GVT seria usar meu celular como modem 3G – há vários programinhas de tethering pro Android que fazem isso. Mas isso não me daria uma oportunidade tão legal de estar discutindo roteamento IP com vocês. ;) Mas foi o que ia tendo de fazer quando a conectividade da GVT com o resto do mundo caiu de vez; eis como isso se parece no traceroute – note que nem passa do segundo hop:

[email protected]:~$ traceroute ip_vpn_tempest
traceroute to ip_vpn_tempest (XXX.XXX.XXX.XXX), 30 hops max, 40 byte packets
 1  plunder (XXX.XXX.XXX.XXX)  1.358 ms  2.194 ms  3.038 ms
 2  * * *
 3  * * *
    (...)

Todavia, o problema durou pouco e logo pude voltar a usar a VPN da Tempest.

Desde que eu aprendi, há muitos anos, como funciona o sistema de roteamento global da Internet, eu sempre gostei de traçar rotas e ver por onde os dados passam. Para um nerd como eu, é algo como olhar um mapa rodoviário e ver todos aqueles nomes de cidades, a maioria delas nas quais jamais estive, algumas poucas delas pelas quais passei brevemente durante alguma viagem. Quanta gente vive nelas, quanta gente trabalhou para fazer as estradas que as interligam. Quantas fibras óticas, cabos de cobre e antenas de microondas.

Muita gente gosta de viajar de carro pela aventura e pelo cenário. Na Internet não há tempo para esse romantismo – como mostra o rastreamento, o pacote chega daqui de Recife a um dos sites do Google e volta em menos de um décimo de segundo. A aventura dura muito pouco por padrões humanos. Isso nos dá a impressão que a Internet é só destinos e que as estradas não existem – de fato, nos gráficos esquemáticos e slides, é comum desenharmos a Internet como uma nuvem, sem estrutura interna, como se seus detalhes pouco importassem. Mas, importam, sim, e é uma "malha viária virtual" extensa e complexa.

Para um cara de segurança de sistemas de informação como eu, esses rastreamentos são um lembrete muito concreto de que meus dados passam por vários intermediários. Diz-se muito por aí que a Internet é um "mundo virtual" onde as regras do mundo físico pouco ou nada importam. É uma visão romântica, mas equivocada: nossos dados têm sim, uma existência física muito concreta, na forma de pulsos elétricos, de luz ou de rádio que trafegam entre aqueles cabos de cobre, fibras óticas e antenas de microondas que eu mencionei.

E, por isso, esses intermediários, donos desses cabos, fibras e antenas, têm total controle físico sobre nossos dados. Podem repassá-los, como em geral o fazem, sem lhes dar muita atenção. Mas também podem interceptá-los, gravá-los, adulterá-los ou bloqueá-los, tudo isso apertando alguns poucos botões ou cliques de mouse em algum painel de controle. E podem fazê-lo quando quiserem, pelo tempo que quiserem, sem deixar rastros e de forma que nós nem sequer notamos, de sorte que não precisam do nosso consentimento. Eles têm esse poder e o usam, às vezes por razões próprias, às vezes quando intimados pela Justiça.

A Internet não foi projetada para prover segurança contra acesso indevido. Isso não foi acidente ou omissão; foi uma decisão de projeto deliberada dos projetistas originais da Internet, que a rede em si não tentaria impor medidas para conter, segregar ou classificar o tráfego. Há quem diga que foi essa decisão de projeto que fez a Internet efetivamente decolar, ao invés de patinar, como aconteceu com outras iniciativas semelhantes à época. "Segurança [contra acesso indevido]", diziam os gurus, "deve ser provida pelas pontas, não pelo 'miolo' da rede".

Como o leitor pode imaginar, fui escrevendo esse post ao longo de várias horas, enquanto fazia outras coisas. Numa dessas, ao voltar pra frente do notebook, notei que o rastreamento mudara:

traceroute to blog.tempest.com.br (76.74.239.147), 30 hops max, 40 byte packets
 1  plunder (XXX.XXX.XXX.XXX)
    1.611 ms  2.467 ms  3.621 ms
 2  dinky (XXX.XXX.XXX.XXX)
    20.022 ms  20.576 ms  21.078 ms
 3  189.115.166.1.dynamic.adsl.gvt.net.br (189.115.166.1)
    21.850 ms  23.572 ms  24.131 ms
 4  corporativo.gvt.net.br (189.115.160.1)
    24.846 ms  25.431 ms  25.941 ms
 5  gvt-ge-4-1-1-rc01.rjo.gvt.net.br (189.59.244.45)
    68.446 ms  69.172 ms  70.163 ms
 6  * * *

Compare este rastreamento com o primeiro que eu mostrei e verá a diferença começando no item 5. Sem conhecer o mapa e os detalhes da rede da GVT, é difícil fazer afirmações precisas, mas parece que eles tentaram acionar uma outra rota através do Rio de Janeiro ("rjo").

Recentemente eu tenho escrito bastante aqui no Blog sobre segurança contra indisponibilidade e projetos de sistemas com "alta disponibilidade". Ao contrário da segurança contra acesso indevido, a Internet como um todo foi deliberaramente projetada para prover segurança contra indisponibilidade e ser um sistema com "alta disponibilidade": idealmente, cada intermediário da rede deveria ter mais de uma conexão com seus vizinhos. Assim, se uma conexão falhar, os dados podem trafegar pela outra – da mesma forma que você circunavega uma rua interditada.

Talvez você já tenha ouvido falar que a Internet foi concebida originalmente pelos militares americanos por volta de 1960 a 1970 porque eles queriam ter uma rede de comunicações que resistisse a ataques com bombas atômicas que arrasariam cidades inteiras e, com ela, vários links de comunicação. Daí essa filosofia de ter múltiplas vias de acesso redundantes.

Ou seja, a Internet é como uma grande cidade: a cidade em si não para se uma única avenida for interditada. Costuma causar um engarrafamento e transtorno danados, mas as pessoas circunavegam a falha e a cidade como um todo continua funcionando. Mas partes da cidade param, sobretudo aqueles que estão em posições em que não têm caminhos alternativos.

É o que aconteceu hoje comigo: se meus dados, saindo daqui de casa e indo pela GVT não encontraram o caminho certo, certamente algo deu errado na GVT ou redondezas: um dos canais de comunicação (as "estradas" virtuais) pode ter tido uma pane ou alguém pode ter errado na configuração do roteamento (as "placas" que indicam que curvas os dados precisam seguir para chegarem ao destino). Isso também sugere que, ou eles não tinham caminhos alternativos para compensar essas "ruas interditadas", ou que esses caminhos também falharam.

Outra coisa observar é que esse é um tipo de falha bastante pernicioso: trata-se uma falha parcial. E a falha não é na "última milha" que liga minha casa ao concentrador local da GVT em algum ponto do meu bairro. Se eu ligasse para o telefone de suporte deles, seria bem capaz de eu ouvir um "daqui tudo funciona" totalmente honesto e verdadeiro. Talvez o atendente me fizesse passar por aquele procedimento de reiniciar o modem, só que não iria adiantar nada porque o problema não era ali.

Por rasteira que seja essa explicação, isso já começa a dar uma ideia de por que é bastante difícil medir níveis de disponibilidade em redes grandes como a Internet: o valor exato depende do trecho que você está medindo.

É também interessante notar que o contrato de prestação de serviços da GVT (e de nenhuma operadora de telecom de "consumo" que eu conheça) não oferece nenhuma garantia mínima de disponibilidade. Os provedores de Internet não pagam multas se eles pararem temporariamente de cumprir suas obrigações. Contraste isso com o caso das empresas aéreas, que são multadas por atrasos e nos oferecem todo tipo de compensação quando algum vôo é cancelado. Alguns provedores ofercem descontos se algo deles der errado, mas a monitoração é deles e a decisão se houve ou não algo a ressarcir é deles. Eles não são auditados independente e externamente. Por que temos mais segurança jurídica quanto à disponibilidade das linhas aéreas do que das linhas de comunicação? Será que isso faz sentido? O que diferencia os provedores de acesso das empresas aéreas, que lhe permite faltar com suas obrigações impunemente?

Enquanto escrevia, notei que o rastreamento mudou mais uma vez e agora mostrava o caminho completo:

[email protected]:/$ traceroute blog.tempest.com.br
traceroute to blog.tempest.com.br (76.74.239.147), 30 hops max, 40 byte packets
 1  plunder (XXX.XXX.XXX.XXX)
    1.679 ms  2.645 ms  3.549 ms
 2  dinky (XXX.XXX.XXX.XXX)
    19.892 ms  20.457 ms  21.029 ms
 3  189.115.166.1.dynamic.adsl.gvt.net.br (189.115.166.1)
    21.860 ms  23.330 ms  23.921 ms
 4  corporativo.gvt.net.br (189.115.160.1)
    24.736 ms  25.385 ms  25.943 ms
 5  gvt-ge-4-1-1-rc01.rjo.gvt.net.br (189.59.244.45)
    68.491 ms  69.179 ms  70.405 ms
 6  gvt-host.gvt.net.br (189.59.244.226)
    71.791 ms  70.881 ms  71.333 ms
 7  64.215.24.209 (64.215.24.209)
    108.573 ms  56.671 ms  56.648 ms
 8  xe-0-3-0.mia10.ip4.tinet.net (213.200.84.37)
    185.889 ms  186.569 ms  187.890 ms
 9  xe-7-2-0.lax20.ip4.tinet.net (89.149.187.93)
    235.515 ms  236.442 ms  237.133 ms
10  peer1-gw.ip4.tinet.net (77.67.70.206)
    306.511 ms  307.290 ms  307.835 ms
11  * * *

Testando com o navegador, vi que conseguia novamente acessar o Blog de forma direta, sem ser pela VPN da Tempest. No rastreamento, dá pra ver a parte, do sétimo trecho em diante, em que os dados saem da rede da GVT e vão para uma tal de "tinet.net", de onde chegam à Peer1, a empresa-pai do ServerBeach. Daí em diante as sondas falham pela mesma razão que já descrevi anteriormente: o firewall de bordas deles bloqueia as sondas UDP.

Sábado, 14-ago-2010, quatro da tarde. O acesso está normal agora. Hora de navegar.

Comentários
Aceita-se formatação à la TWiki. HTML e scripts são filtrados. Máximo 15KiB.

 
Enviando... por favor aguarde...
Comentário enviado com suceso -- obrigado.
Ele aparecerá quando os moderadores o aprovarem.
Houve uma falha no envio do formulário!
Deixei uma nota para os admins verificarem o problema.
Perdoe-nos o transtorno. Por favor tente novamente mais tarde.
Marco Carnut | 2010-08-16 21:28:54 | permalink | topo

Bruno,

Difícil ter certeza sem ter coletado dados na ocasião em que a tal falha aconteceu. Há muita coisa que pode ter dado errado.

Mas, se tem uma coisa que o incidente da Telefónica deixou claro é que eles tinham muitos esqueletos nos armários.

Obrigado!

Grande Cleiton,

Obrigado! Fico feliz que tenha gostado do post. É um prazer contar com suas opiniões lúcidas aqui no Blog!

-K.

Cleiton Martins | 2010-08-16 20:45:29 | permalink | topo

Kiko,

Belo post, um pouco técnico para alguns, mas pra mim bem compreensível e didático. Já guardei nos meus "Favoritos" e devo, em breve, recomendar a leitura pros meus alunos de redes de computadores. Interessante e útil, também, pode ser o mapa de cabos que clm mandou.

Como costuma falar nosso amigo Netux: beleza massa! parabéns!

Cleiton

Bruno S. Drago | 2010-08-16 17:25:45 | permalink | topo

Gostei do POST Kiko.

Isso me fez pensar sobre um problema que tive coisa de ano e meio atrás, onde NINGUÉM com acesso que não fosse Vivo ou Telefonica(speedy, e parcialmente) em São Paulo ou outros lugares do Brasil conseguiam acessar meu site de EAD.

Seria essa indisponibilidade proposital em função da cobrança de tráfego externo ou uma simples constatação de como estão os roteadores dessas empresas? Pouco tempo depois dessa constatação, houve aquele apagão da telefónica aqui em São Paulo...

Enfim... parabéns pelo Blog. Estou acompanhando... :D

Abs!

Diogo | 2010-08-16 14:37:00 | permalink | topo

Muito bom Tio! Esse é o primeiro post que leio e achei interessante, vou ler os post mais antigos e sempre ler os que estão por vir :)

Marco Carnut | 2010-08-16 08:20:00 | permalink | topo

L,

Muito bacana o site com os mapas dos cabos submarinos, não o tinha visto antes. Faz qualquer projeto de cabeamento estruturado parecer brincadeira de criança. Outra coisa que chama a atenção é como há muito mais banda e rotas no hemisfério norte.

-K.

Cristiano Lincoln | 2010-08-15 18:46:43 | permalink | topo

K,

Grande post! O Michael Hayden fez um dos keynotes da Blackhat USA desse ano, e ele comentou sobre essas decisões de projeto originais da Arpanet - que o framework cultural da época de endpoints conhecidos e implicitamente confiáveis colocava a ênfase na transmissão dos dados; e que temos este mesmo framework cultural hoje, apesar de termos basicamente endpoints ilimitados e quase nenhum deles é confiável.

Dá uma olhada em http://www.cablemap.info/, um site que tropecei um dia desses com um mapa interativo de undersea cables ao redor do mundo.

Lincoln