Arquivo

Posts Tagged ‘Indisponibilidade’

Gmail restaura contas de usuários

O Google informou hoje que recuperou de fitas de backup as mensagens de 40.000 contas de e-mail, ou 0.02% da base (antes o percentual era 0.08). No final do dia 28.02 uma pane apagou milhares de contas e os detalhes sobre o problema podem ser visualizados no blog do Gmail em http://gmailblog.blogspot.com/2011/02/gmail-back-soon-for-everyone.html.

Esta não é a primeira vez que o Gmail sofre de indisponibilidade temporária. Em incidentes ocorridos nos últimos anos, o Gmail ficou indisponível para alguns usuários que não conseguiam acessar o site do serviço. Dessa vez, pequena parte dos usuários foi afetada, recebendo a tela inicial de criação de conta ao tentar fazer logon. Ou seja, a conta estava vazia.

Para reduzir o risco de indisponibilidade, o usuário pode baixar suas mensagens para o computador local. Isso evita apenas que o usuário fique temporariamente sem uma informação necessária (se estiver com acesso ao computador onde as mensagens estão armazenadas), no entanto, dependendo do problema, pode não conseguir enviar e-mails. Qualquer programa de e-mail que suporte conexões criptografadas (SSL) pode ser usado.

Exército Cibernético Iraniano ataca o Baidu

O grupo hacker que se denomina Exército Cibernético Iraniano atacou o Baidu.com, maior site de buscas da China (a página principal e a de resultados do Baidu lembra um pouco o Google, mantendo a fama que o chineses tem de copiar tudo).

A invasão ocorreu no dia 12.01.10, e assim como na invasão ao site do Twitter em dezembro, a página principal ganhou fundo preto e a imagem com a bandeira do Irã.

Malditas pequenas URLs

As pequenas URLs (Tiny URLs, em inglês) surgiram há bastante tempo, bem antes do Twitter e sua limitação de 140 caracteres. No início da década de 90, as pequenas URLs começaram a ser usadas para encurtar e evitar que URLs grandes fossem “quebradas” em mais de uma linha em um e-mail e assim perdessem a funcionalidade. Entre os sites geradores mais conhecidos estão: tinyurl.com, tiny.cc, bit.ly e tr.im.

Acontece que agora os clientes de e-mail já sabem lidar com URLs quebradas e isso não é mais um problema. No entanto, agora temos os serviços de mensagens tipo SMS que tem restrições de 140 caracteres, como o Twitter, e as pequenas URLs são usadas para poupar espaço na mensagem.

Mas, por que malditas?

  1. Você nunca saberá pra onde a pequena URL realmente está te levando. Clicar em uma pequena URL é uma questão de confiança (ou de fé). Você não sabe qual é o verdadeiro destino daquela URL. Há sites na Internet que tentam explorar vulnerabilidades do navegador, por exemplo, apenas com o acesso, sem necessitar que o usuário clique em qualquer link. Com URLs normais podemos tentar identificar o destino analisando o site, a pasta e tipo de arquivo que será acessado.
  2. O site gerador passa a ser um intermediário entre o usuário e a informação. Neste caso precisamos confiar no autor que criou a pequena URL e também no site gerador, que a qualquer momento pode mudar a URL ou simplesmente tirá-la do ar.
  3. O site gerador pode fechar ou sair do ar. Quando o usuário clicar na pequena URL receberá uma página de erro e aquela informação pode ser perdida ou ficar indisponível até que o autor gere outra pequena URL de outro site gerador.
  4. As pequenas URLs podem ser bloqueadas. Em determinadas redes (principalmente de empresas), alguns sites são bloqueados por filtros de conteúdo. Independentemente do destino da pequena URL, vários geradores de pequenas URL podem ser bloqueados, deixando os leitores na mão.
  5. É mais uma camada de informação para os sites de busca. Na verdade, não faço a menor ideia de como sites de busca, como o Google, vão tratar esse tipo de link para organizar as páginas mais visitadas, mas certamente haverá um trabalho extra.
  6. A adição de mais uma camada requer mais conversão e acesso a dados. Normalmente precisamos converter o nome de domínio em um endereço IP e depois acessar o IP em busca da informação. Com a adição de pequenas URL, precisamos converter o nome de domínio da pequena URL em IP, acessar o site, buscar a URL original através de uma consulta em banco de dados, converter o nome de domínio da URL original em IP para então finalmente acessar a informação.

Por exemplo, esse blog pode ser acessado através da URL http://ad.ag/jpmwdp. Ou seja, esta URL lhe direcionará para http://www.administrandoriscos.com.br. Isso pode ser mentira ou verdade. A utilização vai depender da confiança que você tem em quem está escrevendo.

No caso da URL acima é verdade. Repare que somente as primeiras letras de cada tecla de teclado de celular são usadas, evitando que a mesma tecla tenha que ser pressionada várias vezes para chegar na letra desejada. Isso é muito interessante e poupa o esforço de digitação do leitor. Esse serviço é prestado pelo site Mobile Tiny URL em http://www.mobiletinyurl.com, que permite que o usuário configure a URL. Por exemplo, eu permiti que seja feito acesso a URL que eu criei a partir de uma estação de trabalho (desktop ou laptop). Por padrão, apenas acessos via celular são permitidos.

O que fazer a respeito?

Se você está em dúvida sobre clicar em uma pequena URL, tente utilizar o serviço Untiny. O Untiny consegue converter uma pequena URL em uma grande URL (URL original) para 228 sites que geram pequenas URLs. Infelizmente, para o Mobile Tiny URL, que eu utilizei acima, o serviço não está disponível. De qualquer forma, o número é expressivo. Tanto porque agora sabemos que há mais de 228 sites que geram pequenas URLs, tanto porque o Untiny consegue “falar” com um número tão grande de sites geradores.

É muito complicado não usar pequenas URLs. No papel de leitor, pode significar ficar sem acessar a informação, já que as pequenas URL estão em todo lugar, principalmente no Twitter. No papel de autor, pode reduzir as possibilidades de escrita em textos pequenos. Ou seja, tenha cuidado com as URLs que acessa, seja a partir do celular ou da sua estação de trabalho. Na dúvida, acesse o Untiny e tente descobrir para onde aquela URL vai te levar. Lembre-se: também existe vírus e exploração de vulnerabilidades em smartphones.

Promessas de 100% de segurança (ou Risco Zero)

26 . dezembro . 2009 Deixe um comentário

Nesta véspera de Natal, os sistemas da Redecard ficaram indisponíveis por algumas horas, prejudicando milhares de compradores de última hora que pretendiam adquirir ou trocar presentes, como foi informado pelo G1.

O curioso é que ultimamente a Redecard tem alardeado possuir um “sistema que não cai”, que traz “segurança para o lojista e para o seu cliente”.

Dessa vez a Redecard trouxe prejuízo “para o lojista e para o seu cliente”.

Essas promessas de 100% de segurança nunca dão certo. Primeiro, porque não existe 100% de segurança ou Risco Zero. Segundo, porque sempre que uma empresa anuncia que seus produtos são 100% seguros (ainda que elas saibam que isso é historinha), esse tipo de anuncio cola um alvo bem grande nas costas da empresa e chama a atenção de milhares de hackers em todo o mundo prontos para provar o contrário.

Foi exatamente o que aconteceu nesta década com a Oracle. Depois de Larry Elisson, CEO da empresa, afirmar em 2001 que o servidor de banco de dados Oracle 9i era “inquebrável” (unbreakable, no original em inglês), os especialistas em segurança se esforçaram pra provar o contrário. Em 2002 o pesquisador britânico David Litchfield apresentou, durante uma conferência Black Hat, uma séria falha de segurança que permitia que hackers controlassem remotamente o servidor de banco de dados. De acordo com a CNET, em 2005 novas apresentações mostraram que o Oracle não era “inquebrável”, apesar das tentativas posteriores da Oracle de se descolar desse termo infeliz.

Há um detalhe em toda essa história: ainda hoje, com grande avanço no uso da Internet para compras e operações financeiras, sabemos que muitas pessoas ainda não usam a Internet para estes fins por não considerá-la segura. São pessoas que, apesar de lerem que um site é 100% seguro, preferem não enviar os dados de seu cartão de crédito pela Internet ou usar o Internet banking para pagamento de contas. É claro que além da segurança do site em questão, o computador do usuário também precisa ser seguro. Imagine agora se os sites de compra e operações financeiras na Internet começassem a se entitular “99% seguros”… Por outro lado, acredito que uma afirmação de “100% de segurança” ou “100% de disponibilidade” seguida de um incidente desse tipo seja passível de ação na justiça.

Twitter hacked

18 . dezembro . 2009 2 comentários

Reparei de madrugada que o site do Twitter estava fora do ar. Hoje ao começar a ler os jornais encontrei uma notícia da CNN que informa que o site do Twitter foi atacado por hackers que se dizem ligados ao Exército Cibernético do Irã.

De acordo com o próprio Twitter, os registros DNS do site foram atacados mas já foram corrigidos. Aqueles que tentaram acessar o Twitter durante o ataque foram direcionados para uma página com uma bandeira verde (exceto eu, que ganhei uma informação de tempo excedido).

Ainda não se sabe se os hackers realmente tem alguma ligação o Exército Cibernético do Irã. O Twitter ficou fora do ar por quase uma hora.

O fantasma do apagão elétrico

18 . dezembro . 2009 Deixe um comentário

O G1 noticiou nesta quinta-feira um registro de incidente no site do ONS, indicando que novamente ocorreu uma falha nas linhas de transmissão da região de Itaberá (SP), que originou o apagão de novembro.

De acordo com o Boletim Diário da Operação do Operador Nacional do Sistema Elétrico (ONS), a falha que ocorreu na quarta-feira (16), não afetou a transmissão de energia porque das três linhas de transmissão que foram desligadas, uma foi religada automaticamente.

Ainda segundo o ONS, “havia forte incidência de descargas atmosféricas” e se passaram 11 minutos entre o desligamento das linhas e a solução do problema. O ONS informou ainda que o incidente será investigado pelo próprio órgão e por Furnas.

Comentário meu: é importante descobrir a causa do incidente para evitar que volte a acontecer. Já falamos disso no post Gestão de incidentes, integração e o ‘Risco Apagão’. Falhas podem acontecer em qualquer sistema e é importante corrigir as falhas em tempo de evitar novos incidentes. Melhor ainda seria um trabalho prévio para evitar que acontecesse da primeira vez. Enquanto o motivo não for identificado contaremos com a sorte. Afinal, se não se sabe o que está acontecendo não é possível afirmar com certeza que o mecanismo de segurança do sistema funcionou corretamente. É normal passarmos por um período de insegurança agora e somente o esclarecimento do incidente trará tranquilidade novamente.

DDoS no Speedy

Não estou perseguindo a Telefônica. Uso esses incidentes conhecidos para mostrar como os incidentes de Segurança da Informação podem afetar as pessoas e as organizações. Segurança da informação não é assunto apenas para analistas e consultores de segurança, hackers ou grandes organizações. Todos nós temos informações que precisamos proteger e serviços que precisamos utilizar. Seja por lazer ou por questões de negócios.

Neste ano, após o apagão da Telefônica no ano passado, o Speedy sofreu um ataque de DDoS (Distributed Denial of Service – Negação de Serviço Distribuída). O ataque de DoS (sem o primeiro D) consiste em utilizar um computador para enviar mais tráfego do que um servidor pode processar, fazendo então com que ele fique ‘ocupado’ e não consiga responder aos clientes legítimos que tentam usar o serviço. O DDoS consiste em infectar um grande número de computadores e fazer com que todos ataquem o mesmo servidor (ou conjunto de servidores).

Discordo um pouco do consultor no fim da matéria. Se defender de um ataque de DDoS não é trivial. Se o ataque tiver como alvo o servidor web de uma organização, o que ela pode fazer é bloquear os endereços IP que estão estabelecendo muitas conexões em um curto período de tempo ou conexões de um determinado tipo (SYN Flood). O problema é que, para usuários de banda larga e acesso discado, sempre que uma nova conexão é efetuada, o endereço IP muda e o bloqueio do IP antigo não apenas se torna inútil mas tem que ser removido para não bloquear o usuário que recebeu aquele IP e não está com o computador infectado. Bloquear nos firewalls da organização ou do provedor de acesso o tráfego web (http) faria com que ninguém conseguisse acessar o serviço afetado.

É claro que existem sistemas e ferramentas que analisam tráfego e tentam determinar, de maneira automática, se este é legítimo ou não. Entre esses sistemas temos o IDS (Sistema de Detecção de Intrusos) e o IPS (Sistemas de Prevenção de Intrusão), que analisam os dados trafegados, a frequência e o tipo de conexão. Firewalls, roteadores e switches, além de um ótimo link com a Internet, também ajudam a conter o ataque. Se o tráfego não for legítimo, é feito um bloqueio automático naquele endereço para que o tráfego não chegue ao destino. O que torna a resolução do problema não trivial é um número enorme de computadores infectados. Imagine cerca de 1.000.000 de computadores executando o ataque simultaneamente. Esse foi o caso da worm MyDoom, de janeiro de 2004. Se a resolução do incidente fosse trivial, a Microsoft e a SCO não teriam oferecido US$ 250.000 de recompensa por informações que levassem ao criador da worm e a SCO não teria ficado fora do ar.

Dependendo do tipo de ataque, aumentar a banda com Internet pode não ajudar, porque o atacante pode aumentar o número de computadores infectados, aumentando o ataque. Além disso, nem todos os ataques consomem banda. Alguns são feitos para consumir tempo de processamento do servidor no destino, por exemplo. Outros tem como alvo uma determinada vulnerabilidade, que ao ser explorada, faz com que o servidor trave ou reinicie. Ainda que aumentar a banda ajude, o custo do aumento de banda pode ser astronômico a partir de um certo ponto, fazendo com que a organização tenha que avaliar o custo do link com a Internet versus o custo da operação parada.

O efeito do ataque é similar ao que acontece com o site de uma empresa que faz uma promoção relâmpago no estilo das companhias aéreas brasileiras. Quando muitos usuários estão acessando o serviço ao mesmo tempo, o processamento fica lento e no final ninguém consegue usar o serviço.

%d blogueiros gostam disto: