Clique aqui e veja nosso novo site

Iae galera,

Estamos agora em outro site… http://www.segurancaemrede.com

E la iremos disponibilizar tudo quanté conteudo que pensarem.

Inclusive os livros que muitas pessoas estao pedindo atraves deste site

Clique aqui e veja nosso novo site

Clique aqui e veja nosso novo site
Os hackers lançaram um programa que, dizendo eles, pode sabotar a suíte de utilitários forenses que a Microsoft fornece gratuitamente para autoridades no mundo todo.

Conhecida como Decaf, a ferramenta lançada pelos hackers monitora sistemas com o Windows visando detectar a presença do COFEE, uma suíte com 150 utilitários usados pela polícia para a coleta de evidências digitais.

Quando um pendrive com a ferramenta da Microsoft é inserido em um computador com o Decaf, o programa dos hackers executa uma série de medidas contra ela.

A Microsoft fornece o COFEE gratuitamente para as autoridades desde 2007. O COFEE (abreviatura de Computer Online Forensic Evidence Extractor) permite a coleta de histórico de navegação, arquivos temporários e outros dados presentes nos computadores baseados em Windows. A ferramenta da Microsoft é distribuída através da Interpol.

Quando o COFEE vazou na internet em novembro de 2009, a Microsoft minimizou a possibilidade de que os hackers poderiam criar contra-medidas contra sua ferramenta.

O Decaf pode remover os logs do COFEE, desativar os drives USB e até mesmo contaminar ou simular uma grande variedade de endereços MAC (identificadores únicos de placas de rede). Futuras versões permitirão que os usuários travem remotamente os sistemas protegidos.

O Decaf pode ser encontrado em quase todos lugares da internet hoje, a partir do BitTorent.

___________________________________________________________

O que é Prática Forense?

Prática forense é a aplicação de técnicas científicas dentro de um processo legal. Essas práticas envolvem pesquisadores altamente especializados – ou criminalistas – que localizam vestígios. Mas esses vestígios só podem proporcionar provas conclusivas quando são testados em laboratório.

Como os criminosos desenvolveram vias cada vez mais criativas de driblar a lei, nossa força policial foi obrigada a descobrir maneiras mais eficientes de levar esses delinqüentes a julgamento. Mesmo que aparentemente eles não deixem pistas, os detetives(Especialistas) descobriram há algum tempo que isto não é verdade.

Fontes: discoverybrasil, baboo

Clique aqui e veja nosso novo site

Evolução do IP vs Clean Slate

Uma das discussões centrais destes dois dias de evento foi em torno da forma que a rede terá no futuro. Há pesquisadores que defendem que uma nova Internet deve ser criada, ou seja, que deve-se abandonar o protocolo IP, sobre o qual está fundamentada a Internet atual, e desenvolver uma base inteiramente nova sobre a qual a rede passará a funcionar. Esta idéia de “recomeçar a Internet do zero” é conhecida entre os pesquisadores como Clean Slate, ou arquitetura disruptiva.

Os que pensam desta forma argumentam que a Internet como conhecemos foi criada há aproximadamente 30 anos, com o objetivo de atender um público restrito (cientistas e pesquisadores). Hoje, entretanto, a mesma estrutura básica é usada mundialmente por centenas de milhões de pessoas que enviam, consultam e recebem cada vez mais informações (de texto, de imagens, de áudio, de vídeo etc). Como a rede não foi a princípio preparada para isto, os novos aplicativos que surgiram ao longo dos anos foram sendo “ajustados” a rede de maneira desordenada. Atualmente, portanto, a Internet seria constituída por vários “remendos”, responsáveis por uma série de vulnerabilidades, instabilidades, incompatibilidades e outros problemas da rede. Os defensores do Clean Slate argumentam que uma Internet recalculada do zero seria mais robusta e confiável, com maior flexibilidade e facilidade de administração.

Os que defendem o IP argumentam que este protocolo vem funcionando satisfatoriamente nos últimos 30 anos e que, embora uma mudança na Internet seja necessária, ela partirá de uma evolução do próprio IP, e não de uma ruptura com ele. Vale ressaltar que estas visões não são totalmente excludentes: além de ser possível que o novo desenho seja baseado em uma adaptação do protocolo IP (e não uma ruptura completa com este), é possível, ainda, que o IP seja agregado a uma nova estrutura, mesmo que ela não tenha este protocolo como base.

Aparentemente há um consenso entre os pesquisadores de que as mudanças estruturais na Internet (ocorram elas em decorrência de uma evolução do IP ou a partir de um redesenho da arquitetura), ainda devem ser amplamente discutidas durante a próxima década. Isto pois embora todos concordem que a Internet precisa passar por profundas mudanças, ainda não se tem estabelecida nenhuma solução concreta. Desta forma, o workshop do CPqD incluiu também palestras sobre possíveis soluções para alguns dos problemas pontuais da rede, assim como apresentações sobre possibilidades de novas aplicações para a Internet atual e futura.

Problemas e possíveis soluções

Além das questões relativas às redes experimentais, o workshop contou ainda com palestras sobre diversos outros fatores que gravitam em torno do tema “Futuro da Internet”, tais como: desafios e tendências em segurança; questões em torno da mobilidade crescente dos dispositivos conectados a Internet; possibilidades para separar identificação e localização; hiperconectividade; novos requisitos na engenharia de tráfego e gerenciamento de recursos; monitoramento de redes; soluções ópticas para o aumento da sustentabilidade energética das redes, entre outros.

Um dos temas apresentados no evento diz respeito aos ambientes experimentais para o teste das novas soluções para a Internet, importante tanto quando se fala da rede do futuro, quanto quando se fala das redes atuais. Embora muitos pesquisadores concordem que em muitos casos estes ambientes (também conhecidos como testbeds) não dão a medida exata do que ocorre em situações reais, a necessidade deles é não somente inegável, como também crescente, dado o número cada vez maior de aplicações para a Internet.

A palestra do diretor de Inovação da RNP, Michael Stanton, teve como tema justamente os ambientes de suporte para trabalhos de Pesquisa e Desenvolvimento (P&D) experimentais em redes e aplicações distribuídas.

Stanton descreveu a evolução desses ambientes, que podem ser infraestruturas físicas ou virtuais, bem como a maneira como o suporte é dado. Além das atividades já realizadas no Brasil, ele também examinou o contexto de algumas redes experimentais usadas no exterior, especialmente as relacionadas ao futuro desenvolvimento da Internet.

No cenário internacional, o diretor de Inovação da RNP destacou o PlanetLab, uma infraestrutura mundial para a realização de pesquisas em tecnologias e protocolos de aplicações Internet (TCP/IP), atualmente presente em mais de 400 nós espalhados pelo mundo. A contribuição fundamental do PlanetLab para a realização de pesquisa experimental é o uso da virtualização de recursos computacionais nestes nós, permitindo que múltiplas aplicações possam ser instaladas paralelamente em cada nó, e que uma determinada aplicação possa estar presente em uma fração de muitos nós diferentes, o que é chamada de uma “fatia”.

Em 2006, o ambiente PlanetLab foi estendido para permitir experimentos com outras arquiteturas de Internet, além do TCP/IP. Este “meta-testbed” se chama Vini, e permite que os servidores nos nós possam funcionar como roteadores para diversos protocolos. A virtualização dos recursos em Vini inclui também os roteadores e os enlaces entre estes.

O Vini serviu como inspiração para o Global Environment for Network Innovations (Geni), uma iniciativa da norte-americana National Science Foundation (NSF) para criação de um ambiente compartilhado de experimentação que auxilie na validação de novas arquiteturas de redes. O objetivo do Geni é apoiar pesquisas que possam levar a uma futura Internet melhor, com características como maior segurança, integração com tecnologias ópticas e de rádio, maior atratividade econômica, entre outras. Uma das palavras-chave do ambiente Geni é a virtualização, que permite que múltiplas arquiteturas funcionem em uma infraestrutura compartilhada, dando uma representação razoável da complexidade da Internet. Michael falou ainda de outras iniciativas similares ao Geni, como a europeia Future Internet Research & Experimentation (Fire) e a japonesa Akari.

Para concluir, o diretor de Inovação da RNP examinou as perspectivas para montar no Brasil um programa de P&D experimental sobre a Internet do Futuro, com a participação da RNP. Inicialmente falou sobre o projeto Giga, que tratou da implementação de uma rede óptica experimental própria, com de 2,5 Gbps e 735 Km de extensão. A primeira fase do projeto foi oficialmente encerrada em 200. Atualmente, a RNP e o CPqD buscam recursos para continuar mantendo a rede experimental ativa, sendo a proposta da RNP a realização de P&D em arquiteturas novas de rede, visando o futuro da Internet. Além disto, a RNP e quatro universidades formularam em 2008 uma linha de pesquisa experimental em futuras arquiteturas de rede, com base em ambiente inspirado no Vini, para compor o projeto Ciência Web (consórcio liderado pela UFRJ), um dos selecionados no recente edital do INCT (Institutos Nacionais de Ciência e Tecnologia) do CNPq. Nesta proposta a RNP proveria conectividade a longa distância para a rede experimental pretendida.

O uso de Vini neste contexto requereria uma infraestrutura subjacente de camada 2 do modelo OSI, para poder implementar possivelmente múltiplos protocolos de rede (camada 3), sendo IP apenas uma das alternativas. Os atuais planos da RNP são compatíveis com este projeto, com a migração do backbone para tecnologia de rede de camadas 1 e 2, e o uso amplo de Ethernet (camada 2) nas redes metro (pertencentes a iniciativa Redes Comunitárias de Educação e Pesquisa – Redecomep) e nas principais conexões internacionais (Whren-Lila/AtlanticWave). Seria possível, portanto, imaginar que a RNP do futuro pudesse reservar banda para experimentação, isolada do tráfego de “produção”, em toda sua extensão, como é feito em Geni.

Stanton encerrou a apresentação apontando as oportunidades que surgiriam para realizar P&D colaborativos com pesquisadores de outros países se existisse uma rede experimental do tipo Geni no Brasil, que pudesse ser interconectada (federada) com as iniciativas semelhantes em outros países, e notou que as políticas enunciadas por Geni e Fire dão suporte a esta forma de colaboração. Para Stanton, isto permitiria ao Brasil participar no esforço internacional para definir como seria a Internet do Futuro.

Redes híbridas

Outro assunto bastante abordado ao longo do workshop foram as redes híbridas, que se apresentam no cenário acadêmico como uma tendência mundial. Em uma rede híbrida, a mesma infraestrutura de comunicação é usada simultaneamente para prestar serviço de pacotes IP, como opera hoje a rede Ipê, e para circuitos fim-a-fim voltados a aplicações selecionadas. Atualmente, estes circuitos fim-a-fim, que funcionam como canais diretos de transferência de dados entre dois pontos, são configurados manualmente, uma atividade demorada, trabalhosa e sujeita a erros.

A discussão sobre qual é a melhor solução tecnológica para tornar automático o aprovisionamento dos circuitos fim-a-fim, permitindo que ele seja feito sob demanda e de maneira agendada, também foi abordada durante o workshop, assim como diversos outros assuntos relativos às redes híbridas.

Em maio, o projeto Futura RNP, que lança as bases para a próxima a nova rede acadêmica brasileira (possivelmente de arquitetura híbrida), completará um ano. Vale ressaltar que a maioria dos palestrantes que se apresentaram no workshop são parceiros da RNP no Futura RNP.

O futuro da internet está nas maos de quem ?

Fonte: RNP

Esse POST tem como objetivo detalhar os estados de uma conexão TCP para instantaneamente viabilizar a análise do resultado da captura de pacotes na rede.

O TCP é o protocolo da camada de transporte do modelo de referência OSI que é orientado a conexão.

Por ter essa característica, antes de ocorrer a transmissão de dados deve-se estabelecer uma sessão de comunicação entre as duas partes. Essa sessão é estabelecida através de um processo chamado three-way handshake, Figura 1, que irá sincronizar os números de seqüência e oferecer informações de controle necessárias para estabelecimento da conexão.

Como o início e o fim de uma sessão de comunicação são bem definidos e o TCP acompanha o estado de suas conexões com flags é importante saber quais são os muitos estados que uma conexão TCP passa.

O estabelecimento da conexão TCP com o 3-way handshake.

Os estados possíveis da conexão TCP são os seguintes:

  • LISTEN: esse é o estado verdadeiro de uma conexão TCP, ele ocorre quando um host está esperando um pedido para iniciar uma conexão.
  • SYN-SENT: esse estado indica que o host enviou um SYN para iniciar a conexão e está aguardando a resposta SYN-ACK adequada.
  • SYN-RCVD: esse estado indica que o host enviou a resposta SYN-ACK depois de ter recebido o SYN.
  • ESTABLISHED: esse estado indica que a conexão foi estabelecida. O host que iniciou a conexão entra nesse estado depois de receber o SYN-ACK e o host que responde depois que recebe o ACK.

Como verificamos na Figura 1 esses são os estados que os hosts passam no processo de estabelecimento da conexão TCP no processo chamado 3-way handshake.

Existem outros estados que acontecem no desmembramento de uma conexão TCP:

  • FIN-WAIT-1: O estado que um host se encontra após ter enviado um pacote FIN inicial pedindo um fechamento correto da conexão TCP.
  • CLOSE-WAIT: O estado da conexão do host que recebeu um FIN inicial e envia de volta um ACK para confirmar o FIN.
  • FIN-WAIT-2: O estado da conexão do host que recebeu a resposta ACK para seu FIN inicial, e indica que agora está esperando um FIN final.
  • LAST-ACK: Esse estado indica que o host acabou de enviar seu segundo FIN, que é necessário para encerramento correto da conexão TCP, e está aguardando uma confirmação.
  • TIME-WAIT: Nesse estado encontra-se o host iniciador que recebeu um FIN final e enviou um ACK para fechar a conexão. Nesse momento ele não irá mais receber nenhuma confirmação do ACK que acabou de enviar, portanto espera um período de tempo para fechar a conexão.
  • CLOSED: pode-se considerar como “sem estado”. Esse estado existe antes que uma conexão seja iniciada ou quando ela é finalizada.

Estes estados estão ilustrados na Figura 2, e ocorrem no fechamento correto da conexão TCP:


Neste artigo vamos demonstrar o uso do Beef, um framework para exploits em browsers (Firefox, Opera, IE e outros navegadores), veja na sequência.

1° passo

Executar o instalador do Beef. Há duas opções (menu K—> Services —> BEFF —> Setup BeFF) ou, como usaremos aqui, via shell bash (para isso, você deve ter privilégios com root ou autenticar como root):

beff

2° passo

Digite uma senha para acessar futuramente o painel administrativo via Web do BeFF.

tutorial beff

3° passo

Como estamos testando, por sugestão usamos a palavra “teste” como senha, mas lembre-se das regras para obter uma senha forte. Em ambiente real e de produção, ao instalar este framework, verifique se não há ninguém por perto, pois a senha é exibida, não ofuscada por ******, tome cuidado.

befff

4° passo

Agora o BeFF nos orienta a abrir um browser (pode ser o Firefox ou IE) e digitarmos o IP que ele demonstra nesta tela (no meu caso foi http://192.168.1.4/beff), no seu computador pode estar um pouco diferente.

O BeFF avisa sobre um exemplo de página de Internet para testar um exploits XSS, que você pode

acessar em http://192.168.1.4/beff/example.html.

explicaçao beff

5° passo

Usando o BeFF em um browser você pode ver um painel de controle que só tem acesso quem tiver a senha administrativa, que foi configurada na instalação do BeFF.

5

O painel de controle do BeFF é dividido em três partes básicas:

  1. Menu
  2. Status
  3. Geral

6

Para testarmos a eficiência do BeFF sobre exploits de browsers, já há um exemplo criado (apenas para testes mesmo), na própria página.

7

Esta é a página contendo uma simulação de ataque XSS Cross-posting, que por sinal, sendo em ambiente real de produção, dentro de uma empresa é bastante perigoso.

8

Repare agora (onde? ZOMBIES) que foi gerado um alerta no status do BeFF, demonstrando quem está atacando através do IP de origem, sistema operacional (que o atacante está usando) e até mesmo o gerenciador de janelas (no caso KDE).

9

Basicamente o BeFF lhe oferece isso, detecção sobre ataques por exploits em browsers (navegadores de Internet). Aqui vemos um módulo sobre exploit para IMAP4 (protocolo para emails). Para verificar os módulos você deve criar o menu “Standard Modules” e escolher o módulo que você deseja.

10

Este módulo é para configurar detecção de exploit para Asterisk via browser navegador.

11

Módulo para detecção de exploit XSS (acho que testei isso num site “bem conhecido esses dias”, humm…não vou falar quem é não. Tenho ética profissional).

12

Este módulo detecta informações sobre Steal Clipboard (roubo de dados do Clipboard – Copiar/Colar ou Recortar/Colar) via Browsers (navegadores) – só funciona em Internet Explorer.

13

Módulo para teste de exploits em plugins Flash

14

Módulo para teste de exploits em plugins Java Applet.

15

Módulo para teste de exploits em Javascripts

16

Módulo para teste de exploits por URL Request (geralmente os atacantes anexam algum executável Win32).

17

Módulo para teste de exploits em URLs visitadas.

18

Módulo para detecção de exploit para Service Pack 2 do Microsoft Windows XP.

19

Módulo para detecção de exploit para Safari do Mac OS.

20

Módulo para detecção de Distributed Port Scanner (Scanner de Portas Distribuídos pela Internet).

21

Módulo para detecção de Distributed Port Scanner (Scanner de Portas Distribuídos pela Internet).

transflash

Configuração do BeFF, no caso em qual caminho, para você acessar via IP.

tutorial beff

End if

//Créditos: firebits

~juancarloscunha~

Clique aqui e veja nosso novo site

 

SYN flood ou ataque SYN é uma forma de ataque de negação de serviço (também conhecido como Denial of Service – DoS) em sistemas computadorizados, na qual o atacante envia uma seqüência de requisições SYN para um sistema-alvo.

Quando um cliente tenta começar uma conexão TCP com um servidor, o cliente e o servidor trocam um série de mensagens, que normalmente são assim:

  • O cliente requisita uma conexão enviando um SYN (synchronize) ao servidor.
  • O servidor confirma esta requisição mandando um SYN-ACK(acknowledge) de volta ao cliente.
  • O cliente por sua vez responde com um ACK, e a conexão está estabelecida.

Isto é o chamado aperto de mão em três etapas (Three-Way Handshake).

Um cliente malicioso pode não mandar esta última mensagem ACK. O servidor irá esperar por isso por um tempo, já que um simples congestionamento de rede pode ser a causa do ACK faltante, Ou seja. O servidor ficará esperando varias respostas deixando de responder as outras requisições que são feitas por outros clientes.

Esta chamada conexão semi-aberta pode ocupar recursos no servidor ou causar prejuízos para empresas usando softwares licenciados por conexão. Pode ser possível ocupar todos os recursos da máquina, com pacotes SYN. Uma vez que todos os recursos estejam ocupados, nenhuma nova conexão (legítima ou não) pode ser feita, resultando em negação de serviço. Alguns podem funcionar mal ou até mesmo travar se ficarem sem recursos desta maneira.

Algumas contra-medidas para este ataque são os SYN cookies. Apenas máquinas Sun e Linux usam SYN cookies.

Ao contrário do que muitos pensam, não se resolve negação de serviço por Syn flood limitando conexões por minuto (como usar o módulo limit ou recent do iptables), pois as conexões excedentes seriam descartadas pelo firewall, sendo que desta forma o próprio firewall tiraria o serviço do ar. Se eu, por exemplo, limito as conecões SYN a 10/seg, um atacante precisa apenas manter uma taxa de SYNs superior a 10/s para que conexões legítimas sejam descartadas pelo firewall. O firewall tornou a tarefa do atacante ainda mais fácil. Em “Iptables protege contra SYN Flood?” tem uma boa descrição dos motivos pelos quais uma configuração de firewall não resolve.

Um ataque de Syn Flood é feito com os ips forjados (spoof), para que o atacante não receba os ACKs de suas falsas solicitações.

~juancarloscunha.wordpress.com~

tutorial trojan shark:

Só para deixar bem claro a diferença entre trojan e cavalo de tróia.

Trojan é um programa que é usado em conexão reversa ou inversa que geralmente é usado para invasão para pegar senha ou outras informações. O cavalo de troia é um programa que tem um pacote de virus que é usado geralmente para destruir um computador.

SharK é um trojan de conexão reversa, ele ao ser enviado para a vitima, faz com que o pc diga qual o seu ip!

Como criar um server:
-Primeiro de Tudo baixe o SharK:
http://www.4shared.com/file/29631048/c5b57345/sharK_232.html
Agora execute ele e vá em SharK > Create Server
-Veja a img e siga a legenda a seguir:
http://img167.imageshack.us/my.php?image=shaaarksettingstl7.png
De preto- é o nome do seu Server!
Vermelho- é o nome do seu server onde ira aparecer na barra de tarefas (ctrl +alt +del)
Verde- É onde o trojan ira se instalar.
Roxo- É a senha do seu server

Install Events
Enable msg on first start-Isso fara com que abra uma msg de erro quando a vitima executar o arquivo!
Execute File- Executara um programa junto com o Trojan.
Open WebPage- Abrira uma pagina (www.site.com.br) ao executar o server

Binde Files- Faz com que vc junte o server com um arquivo qualquer

Finalmente!
Va em compile e aperte COMPILE

Agora é só mandar o server para alquem

Vídeos Aula
http://br.youtube.com/watch?v=rqddB-BubEI