Preview only show first 10 pages with watermark. For full document please download

Introdução Sobre Worms Containment

Contenção de Worms, um verme que pode destruir o seu computador ou permitir a entrada de outros vírus

   EMBED

  • Rating

  • Date

    December 2018
  • Size

    21.2KB
  • Views

    9,564
  • Categories


Share

Transcript

1- Introdução sobre Vigilante: Worms Containment (contenção de vírus): Worm Contaiment deve ser automática para ter alguma chance sucesso, pois os vírus espalham rápido de mais nos sistemas. Um exemplo é o vírus Slammer onde ele infectou 90% dos hosts que estavam vulneráveis em 10 minutos. Trabalhos recentes têm feito abordagens em nível de rede, para analisar o trafego das redes e o numero de encaminhamento de vírus na rede. É difícil fornecer garantias sobre os falsos positivos e os falsos negativos, pois não há informações dobre a vulnerabilidade dos softwares que são explorados pelos vírus. Os falsos positivos causam interrupção na rede dificultando a navegação, já os negativos permitem os vírus escaparem da contenção. Este trabalho propõe um novo sistema chamado Vigilante onde aborda estas limitações, usando a abordagem end-to-end (ponta a ponta, ou extremo a extremo) para conter os vírus automaticamente. Uma vez que os hosts executem um software que seja vulnerável à infecção por vírus, que podem reunir informações que não estão disponíveis na rede no nível de abordagem o Vigilante aproveita destas informações para conter os vírus falsos negativos para eliminar os falsos positivos. O Vigilante introduz o conceito de um alerta de auto certificação (SCA), um SCA é a prova que uma máquina seja vulnerável. Os SCAs retira a necessidade de confiança entre os hosts, isso permite a detecção de vírus em modo de cooperação com detectores distribuídos em toda rede. Além disso a cooperação permite que os hosts executem mecanismos de detecção mais caros com alta precisão, porque ele espalha carga de detecção. SCAs também fornecer uma linguagem comum para descrever as vulnerabilidades e um mecanismo de verificação comum. Em Vigilante, os anfitriões detectam vírus por instrumentação enfrentando a rede de serviços para analisar as tentativas de infecção. Detectores usam esta análise para gerar automaticamente SCAs e distribuem para outros hospedeiros. Antes de um hospedeiro distribuir uma SCA ou após receber um SCA de outro host, ele verifica o SCA, reproduzindo o processo de infecção descrito no SCA em um sandbox. Se a verificação for bem sucedida, o host está certo que o serviço é vulnerável, a verificação procedimento não tem falsos positivos. Exercito alertados protege-se por gerar filtros que bloqueiam as mensagens do vírus antes de serem entregues a um serviço vulnerável. Esses filtros são gerados automaticamente usando dados dinâmicos e analise de controle de fluxo do caminho da execução. Cada host vulnerável executa esse procedimento localmente e instala o filtro para se proteger. As principais contribuições deste trabalho são: Os conceitos de SCAs e ao end-to-end automático arquitetura verme contenção que permite, mecanismos para gerar, verificar e distribuir SCAs automaticamente, um mecanismo automático para gerar filtros baseados em host que o tráfego de verme bloco. 2- Auto certificação de alertas (SELF-CERTIFYING ALERTS): Esta secção descreve o formato de SCAs, bem como os mecanismos de verificação, gerar e distribuir alertas 2.1- Tipos de Alerta: Um SCA prova que um serviço é vulnerável por descrever como explorar o serviço e como gerar uma saída que sinaliza o sucesso da exploração. Usamos mecanismos de detecção em combinação com mensagem de log para gerar SCAs em detectores. Nós desenvolvemos três tipos de auto certificação de alerta para o Vigilante: Controle Arbitrário de Execução: Alerta que identifica a vulnerabilidade que permitem que os vírus redirecionem a execução para as peças arbitrarias de código no espaço de um serviço de endereço. Execução de Código Arbitrário: Alerta que descrevem códigos de injeções vulneráveis. Eles descrevem como executar um pedaço de código arbitrário que é fornecido em uma mensagem enviada para os serviços vulneráveis. Função Arbitrária de Argumentos: Alerta que identificam os dados de injeções vulneráveis que permitem os vírus alterarem os valores dos argumentos para funções críticas. Eles descrevem como invocar uma função especificada crítica com um valor de argumento, que é fornecido em uma mensagem enviada para o serviço vulnerável. Estes tipos de alerta são gerais. Eles demonstram como o vírus pode ganhar o controle usando a interface de mensagens externas a um serviço sem especificar a codificação de baixo nível, defeito usado para obter o controle. Isto permite que os mesmos tipos de alerta e procedimentos de verificação podem ser usados com diferentes os tipos de motores de detecção. Diversidade motor de detecção reduza taxa de falso negativo. Os três tipos de SCAs tem um formato comum: uma identificação do serviço vulnerável, uma identificação do tipo de alerta, informações de verificação para auxiliar a verificação de alerta e uma sequência de mensagens com os parâmetros de rede, que devem ser enviadas para durante a verificação. A informação de verificação permite que o verificador de ofício um exploit possa verificar de forma inequívoca. É diferente para os diferentes tipos de alertas. A verificação de informações para um controle de execução arbitrária SCA especifica onde coloca o endereço do código para executar na sequência de mensagens. 2.2-Alertas de Verificação: Verificando uma SCA implica reproduzir o processo de infecção enviando a sequência de mensagens no alerta para um serviço vulnerável. É importante para executar a verificação de procedimento em uma caixa de areia, porque podem vir de SCAs fontes não confiáveis. É importante executar em uma maquina virtual para evitar quaisquer efeitos secundários. Os hosts devem usar a mesma configuração para rodar a instância de produção de serviço e da instancia de modo seguro para a verificação. Para verificar SCAs, cada host executa uma máquina virtual com um gerente de verificação e versões instrumentadas de networkfacing serviços. Cada serviço é instrumentado por carregar uma nova biblioteca em seu espaço de endereço com uma função, verificado, sinaliza o sucesso de confirmação para o gerente de verificação. O anfitrião também executa um verificador SCA processo do lado de fora da máquina virtual que fornece outros processos com uma interface para o módulo de verificação e age como um firewall reverso para garantir contenção. Após executar essas modificações, o gerente de verificação envia a sequência de mensagens para o serviço vulnerável. Se Verificado é executado, o gestor de sinais de verificação envia sinais de êxito ao SCAs da máquina virtual. Caso contrário, o verificador SCA declara falência depois de um tempo limite. O estado da máquina virtual é guardado para o disco antes qualquer verificação realizada. Este estado de referência é utilizado para iniciar cópias descomprometidas da máquina virtual para verificação. Após a realização de uma verificação, a máquina virtual é destruída e um novo é iniciado a partir do estado de referência, para assegurar que não existe uma máquina virtual pronta para verificar a SCA. Três importantes procedimentos de verificação de alerta: Verificação é rápida: O tempo para verificar um SCA é semelhante para o tempo que demora o verme de infectar o serviço porque a sobrecarga da instrumentação e da máquina virtual é pequena. A verificação é simples e genérica: O procedimento de verificação É simples e independente do mecanismo de detecção utilizados para gerar o alerta. Verificação não tem falsos positivos: Se o procedimento de verificação sinais de sucesso, o serviço é vulnerável ao exploit descrito na SCA. A verificação foi bem sucedida mostra que os atacantes podem controlar um serviço vulnerável por meio de sua interface de mensagens externa.