

Estude fácil! Tem muito documento disponível na Docsity
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Prepare-se para as provas
Estude fácil! Tem muito documento disponível na Docsity
Prepare-se para as provas com trabalhos de outros alunos como você, aqui na Docsity
Encontra documentos específicos para os exames da tua universidade
Prepare-se com as videoaulas e exercícios resolvidos criados a partir da grade da sua Universidade
Responda perguntas de provas passadas e avalie sua preparação.
Ganhe pontos para baixar
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Contenção de Worms, um verme que pode destruir o seu computador ou permitir a entrada de outros vírus
Tipologia: Notas de estudo
1 / 3
Esta página não é visível na pré-visualização
Não perca as partes importantes!


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:
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: