Cesar Cielo, é do Brasil, é o nadador mais rápido do mundo!!!
A emoção é grande, Cielo acaba de conquistar o ouro olímpico. É um feito histórico para o Brasil, em breve ouviremos o Hino Nacional na natação das olimpíadas de Pequim, é de mexer com o coração.
PS. Não só tocou o Hino, como Cielo foi o mais aplaudido dos medalhistas, a emoção dele contagiou a todos. Nesta noite Michael Phelps fez história e foi Cesar Cielo o mais aplaudido.
Eu pensei que seria exclusividade da geração anterior dizer “em minha época teve um Mark Spitz”.
Eis que temos a honra de testemunhar o maior fenômeno olímpico de todos os tempos. Com tantos recordes mundiais sendo batidos na natação, com tantos tempos excelentes sendo marcados, o feito de Phelps parece quase normal.
Não é normal. É algo que acontece a cada 40, 50 anos. Aliás, isso é apenas uma especulação minha, visto que o que Phelps acaba de fazer, ninguém nunca fez. Portanto não sabemos se acontecerá de novo. É raríssimo uma pessoa vencer mais de uma prova, mais de uma modalidade.
Estamos diante de um gigante. Valeu Michael Phelps, o maior vencedor olímpico de todos os tempos.
Atualização 17/8
É inacreditável o profissionalismo(ou frieza?) do Phelps. Hoje parece um dia como outro qualquer. Acabou de terminar sua coletiva à imprensa e, além da admiração que sinto pelo que fez, só consegui notar como é tranquilo, tudo parece normal, conforme ensaiado. Enfim, obviamente não posso compreender o que se passa na cabeça dele, mas deve ser uma pessoa muito especial para conseguir fazer o que fez.
Steve Jobs admitiu hoje que o iPhone 3G tem uma “chave” remota que permite a Apple remover qualquer software, de qualquer aparelho, que a Empresa julgar ser uma ameaça à segurança dos usuários.
Segundo Jobs, a função serve para “proteger o usuário” contra vírus ou trojans que poderiam se difundir com alta velocidade e que poderiam impedir a rede 3G de funcionar. Ao acionar a função, a Apple poderia “limpar” todos os iPhones remotamente.
O envio do software que controlaria os iPhones 3G se dá pela App Store, loja online da Apple. Especulo que, tendo essa “porta dos fundos” implementada em hardware, nada impede a Apple de enviar esse mesmo comando através de atualizações, ou a qualquer momento que o aparelho acesse os servidores da empresa. Lembre-se que o 3G tem conexão de alta velocidade com a Internet que lhe permite efetuar download de qualquer atualização Apple em questão de segundos.
Tanto a desculpa da Apple quanto o fato deles terem tentado ocultar a função são provas de que a empresa agiu, no mínimo, de maneira traiçoeira com seus clientes. Como já mencionamos aqui em outras críticas à Apple, Steve Jobs tem a estranha mania de atirar no próprio pé.
Na ânsia de controlar(literalmente) o múndo móvel, a Apple inseriu um software completamente intrusivo e inaceitável no seu produto mais popular. Imagine você: é como se a Ford, a Volks e a GM tivessem um botão que parassem o carro de qualquer cliente remotamente para “protegê-lo”.
Leia mais nesta matéria da newsfactor.com reproduzida no Yahoo!
Detalhes técnicos da falha de segurança no sistema DNS descoberta no início do mês de Julho começam a se tornar públicos, e alguns provedores de acesso já são vítimas do problema, segundo esta matéria do site Security Focus. A grande imprensa tem noticiado esta falha como sendo uma das piores da história. E, pelo pouco que foi divulgado ao distinto público pelos técnicos envolvidos na correção da mesma, parece que desta vez a imprensa não está exagerando.
Pode uma falha tão absurda existir no software mais testado do mundo?
O responsável pela divulgação da falha, Dan Kaminsky, foi questionado publicamente sobre a veracidade de sua “descoberta”. Foi então que decidiu revelar o problema a um seleto grupo de pesquisadores para que eles confirmassem ao público, ou não, a gravidade do problema. Resulta que todos saíram da reunião acendando um sinal de positivo: o problema era grave.
O megaproblema: A falha é na especificação DNS
A especificação do sistema de DNS se baseia em parte, em confiança entre servidores mestre publicados por donos de domínios, assim como outras tecnologias relacionadas à Internet(o sistema de email, por exemplo). Quando um servidor mestre responde, o DNS tradicional não verifica se a resposta veio do servidor correto, por exemplo.
Há um consenso entre especialistas que o DNS é naturalmente vulnerável a ataques mais sofisticados. O fato de um problema dessa magnitude ter sido descoberto no DNS aos seus 40 anos de idade mostra a complexidade do software: uma falha pode se esconder décadas, e um dia aparecer arriscando a integridade de toda a Internet.
Sentados ao redor de uma mesa em reunião emergencial dia 9 de Julho, alguns dos maiores especialistas de segurança de DNS do mundo solucionaram rapidamente o problema. Bem, em termos. Acontece que o problema não tem solução, é uma falha natural do sistema DNS – ele foi feito assim, e agora descobriu-se que parte da especificação contém uma falha de segurança.
Software é conhecimento. Programar computadores é uma forma de compilar conhecimento computável por uma máquina. E, assim como existem falhas, bugs nos softwares, há falhas também nas suas especificações. Neste caso a especificação DNS tem um bug, e todos os servidores que a implementam corretamente, possuem a falha também. Daí resulta a gravidade do problema: o bug está em toda a infraestrutura da Internet.
A falha
Os detalhes técnicos da falha não foram divulgados, mas eis o que conseguí compreender pelo que foi divulgado na imprensa : quando você pergunta a um servidor DNS de seu provedor “qual o endereço do site www.google.com”, esse servidor deve perguntar aos servidores Google qual o endereço.
Acontece que o Google é um site muito acessado, portanto o servidor DNS de seu provedor mantém os endereços mais comuns em memória, para não consultar os servidores Google bilhões de vezes por dia. Em termos informáticos, como você deve saber se está lendo este post até aqui, o nome de um armazém temporário de dados com finalidade de acelerar uma consulta é um “cache”.
DNS Cache poisoning
O que acontece, então, se você conseguir alterar os dados desse cache dos provedores de acesso? Digamos que o servidor consulta o DNS mestre do Google, e obtém o endereço correto. Porém, o servidor precisará consultar o Google novamente em 24 ou 48 horas para saber se o endereço mudou, e assim manter o cache sincronizado com o servidor principal.
E se, por acaso, fosse possível interferir nessa comunicação do seu servidor cache com o servidor mestre e inserir no cache um endereço IP diferente daquele do Google? Se voce conseguir a proeza, terá sequestrado o site do Google. Você terá “envenenado” o cache DNS. É disso que se trata esta falha de segurança: Dan Kaminskydescobriu que é possível fazer exatamente isso interferindo com a resposta do servidor mestre antes que ela chegue ao servidor cache.
E qual é a falha?
Como poderiam alterar a resposta do servidor mestre? Bem, esse é o detalhe que não foi divulgado. A falha poderia parar a Internet, então Kaminsky trabalhou com os proprietários de redes de infraestrutura para trampar o furo antes que ele se tornasse 100% público. Porém alguns detalhes vazaram, e há exploits na web que exploram a falha com sucesso. O que sabemos é que a solução proposta torna aleatória a porta UDP de origem quando o DNS se conecta ao servidor mestre(sempre porta 53) para renovar o cache.
Tornar a porta UDP de origem aleatória significa que de alguma maneira o atacante estaria conseguindo adivinhar quando o servidor consultava o servidor mestre e conectava-se à essa porta antes da resposta do mestre, com endereço de origem falso, devolvendo informação inválida(e de interesse do vândalo). Seria como substituir o endereço do Google com o de seu site. Imagine o potencial disso…
A solução
Tecnicamente não há nada de novo na solução proposta, pois ela já havia sido descrita há anos atrás pelo matemático e especialista em segurança Daniel J Bernstein : as portas de origem das conexões DNS devem ser aleatórias para dificultar o ataque.
Após algumas horas de trabalho duro (segundo este relato de Kaminsky) o grupo decidiu que a solução do problema era adotar a idéia de Bernstein : remendar todos os principais softwares de DNS tornando a porta de origem das consultas aos servidores mestres aleatória.
Está passando da hora de proteger o seu DNS
O número de exploits para a falha está crescendo, já existem pelo menos 2 sendo divulgados sendo que um deles permite “substituir todos os servidores DNS de um domínio”, efetivamente sequestrando toda uma rede. Imagine o seguinte: o vândalo poderia substituir os servidores do domínio globo.com, por exemplo, e todos os subsites do globo.com passariam a seu controle.
Os detalhes que permitiram aos desenvolvedores de exploits produzirem o código funcional foram compilados até ontem, 7/8. Ou seja, hoje é um bom dia para atualizar seu sistema DNS. Se o seu cache for envenenado, você permanecerá envenenado por 24 a 72 horas, dependendo do TTL(Time To Live, ou tempo depois do qual o cache deve recarregar), então evite perder dias de trabalho e atualize já seu servidor.
Nota: não existe conserto para o BIND 8. Se você estiver rodando a versão 8 será preciso migrar para 9.5. O Yahoo! era o maior usuário de BIND 8 conhecido e foi obrigado a atualizar toda sua infraestrutura.
Se você trabalha com um terminal SSH ou semelhante já deve ter passado por uma situação parecida : após passar horas digitando em seu editor de texto predileto em modo gráfico você passa para o terminal e tenta salvar um arquivo no Vi apertando Ctrl + s. Pronto, terminal congelado…
Calma, não é um bug no shell ou no seu terminal. Ctrl + s significa “pare de ecoar qualquer coisa no terminal”.
Ctrl + s ecoa (invisivelmente) um caractere especial de controle de fluxo que interrompe tudo o que estava sendo mostrado na tela. Foi criado para você poder interromper telas que estivessem passando rápido demais para ler. Enquanto a tela está congelada, o Ctrl + s grava tudo o que for digitado no buffer do teclado porém não executa nada.
Para liberar o terminal de novo basta pressionar Ctrl + q
Lembre-se que tudo que for digitado durante o congelamento será ecoado após liberar o terminal.
Pode parecer óbvio, mas acontece: não digite nada que possa comprometê-lo(ou a integridade de sua estação de trabalho) enquanto o terminal estiver congelado.
O usuário “A. Clay Stephenson” deste fórum explica que Ctrl + s e Ctrl + q foram criados para protocolos seriais onde o handshake via hardware não existe. Assim, Ctrl + s emite o caractere 0×13 para avisar que o terminal serial não pode mais receber caracteres, e Ctrl + q emite 0×11 liberando a linha serial para envio.
Num terminal padrão do Linux você pode verificar todos os caracteres de comando especiais utilizando o comando:
[root@jimi ~]# stty -a
Referência adicional: Orientação para usuários de UNIX da Universidade de Stanford
A CNN afirma que é o maior caso de crime cibernético que o FBI já investigou em sua história.
A polícia federal Americana conhece a nacionalidade da maioria dos suspeitos mas não deixa claro se já sabe quem são. Pelo menos um suspeito é desconhecido e não há pistas sobre sua nacionalidade.
Segundo a rede de notícias Americana, os cartões foram utilizados internacionalmente e muitos foram vendidos em certa ocasião por milhões de dólares. Outros foram usados para efetuar saques ao redor do mundo.
Os suspeitos teriam utilizado programas espiões nas redes de pelo menos 9 grandes redes comerciais dos EUA, capturando transações de cartão de crédito e transmitindo tudo para um servidor seguro no Leste Europeu.
O crime cibernético é um crime comum, não há nada de heróico nisso. Nos anos 1970 e 1980 havia um certo romantismo eu usar a tecnologia para causar transtornos aos outros. Hoje em dia a tecnologia é tão universal que o uso dela para o crime é apenas uma consequência de sua adoção pela sociedade.
