Sistemas Tolerantes a Falhas: Conceitos e T

1
Sistemas Tolerantes a Falhas Conceitos e Técnicas

• FURB DSC
• Paulo Fernando da Silva

2
Sumário

• Introdução
• Conceitos e Terminologia
• Redundância Temporal
• Redundância de Hardware
• Redundância de Software

3
Introdução

• Falhas são inevitáveis
• Paralisia do sistema pode ser evitada
• Técnicas têm alto custo
• Computacional backup
• Financeiro Redundâncias
• Avaliação Custo x Benefício

4
Introdução

• Expansão das redes de computadores
• Maior disponibilidade de serviços
• Ex. transações eletrônicas
• Maior dependência de serviços
• Ex. Site de vendas pela internet
• Falhas podem prejudicar empresas

5
Introdução

• Confiabilidade e disponibilidade são cada vez
  mais importantes
• Dependência da sociedade
• Tráfego aéreo
• Área da saúde
• Área financeira
• Telecomunicações

6
Introdução

• Hardware
• Teve grande aumento de confiabilidade
• Software
• Está se tornando cada vez mais complexo
• Apresenta muito problemas
• Só o hardware não garante a confiabilidade e
  disponibilidade dos sistemas

7
Introdução

• Algumas falhas
• Falhas em mísseis na guerra do golfo (1991)
• Falhas na comunicação de ambulâncias em Londres
  (1992)
• Falhas no sistema de crédito da França (1993)

8
Introdução - Desafios

• Como evitar, detectar e contornar bugs?
• Como explorar a rede aumentando a confiabilidade
  e a disponibilidade?
• Como desenvolver um sistema confiável em uma
  plataforma não confiável?

9
Conceitos TF x Depend.

• Tolerância a Falhas
• Localização e recuperação de falhas do sistema
• Chamados de sistemas redundantes
• Falsa impressão de que o sistema não falha!!!
• Dependabilidade
• Conceito mais atual
• Confiança que se pode ter em um sistema

10
Conceitos - Objetivo
11
Conceitos Falha, Erro e Defeito

• Defeito
• Desvio da especificação
• Não pode ser tolerado
• Erro
• Causador de defeito em potencial
• Falha
• Causa física ou algoritmica do erro

12
Conceitos Falha, Erro e Defeito
13
Conceitos Falha, Erro e Defeito
14
Conceitos Falha, Erro e Defeito

• Falhas são inevitáveis
• Componentes físicos envelhecem
• Projetos de software podem apresentar falhas
  humanas
• Defeitos são evitáveis
• Através de técnicas de tolerância a falhas

15
Conceitos Falha, Erro e Defeito

• Exemplo
• Chip com defeito falha
• Interpretação errada da informação erro
• Provoca negação de acesso ao usuário defeito
• Nem toda falha leva a um erro
• Nem todo erro leva a um defeito
• Podem não aparecer durante a execução do sistema

16
Conceitos Classificação das Falhas
17
Conceitos Classificação das Falhas

• Natureza falhas de hardware, software, operação
• Extensão local ou global
• Valor determinado ou indeterminado no tempo
• Falhas de interação intencional
• são tratadas por técnicas de segurança, não por
  tolerância a falhas

18
Conceitos Classificação das Falhas

• Tf 1.2.doc
• Atributos e dependabilidade
• xxx

19
Técnicas de Dependabilidade
20
Técnicas de Dependabilidade
21
Técnicas de Dependabilidade
22
Técnicas de Tolerância a Falhas

• Classificam-se em
• Técnicas de mascaramento
• Técnicas de detecção e reconfiguração
• Mascaramento
• Usa redundância para mascarar o defeito
• É mais rápida
• Própria para tempo real

23
Técnicas de Tolerância a Falhas

• Detecção e Reconfiguração
• Fase de Detecção
• xxx

24
Redundância da Informação

• Repete bits na transmissão
• Códigos de paridade
• Técnicas de checksum
• Detecta apenas erros simples
• Usado em componentes de hardware
• Memórias e processadores
• Redes de computadores

25
Redundância Temporal

• Torna redundante as informações no tempo
• Evita custo de harware, aumentando o tempo
• Usado onde o tempo não é crítico
• Para detectar falhas transitórias
• Repete-se a computação no tempo
• Resultados diferentes indicam falhas

26
Redundância Temporal

• Para detectar falhas permanentes
• Com base em uma computação normal
• Repete-se a computação com dados codificados
• Compara-se o resultado da computação normal com o
  resultado esperado na computação codificada
• A codificação força o uso diferente do componente

27
Redundância HW - Passiva

• Faz mascaramento de falhas
• Vários componentes executam a mesma tarefa
• Resultado determinado por votação
• Resultado obtido por maioria ou valor médio

28
Redundância HW - Passiva
29
Redundância HW - Passiva
30
Redundância HW - Passiva

• TMR redundância modular tripla
• NMR redundância modular N
• É ideal para falhas temporárias
• Suporta apenas uma falha permanente

31
Redundância HW - Ativa

• Técnicas de detecção, localização e
  reconfiguração

32
Redundância HW - Ativa
33
Redundância HW - Ativa

• Reconfiguração do módulo estepe
• Alimentado minimiza a descontinuidade do
  sistema
• Não alimentado espete só começa a operar quando
  necessário
• Módulo não alimentado minimiza a vida útil do
  estepe

34
Redundância HW - Híbrida

• Baseado em votação
• Módulo que descorda é desconectado
• Estepe entra em seu lugar
• Modelo redundância auto-eliminadora
• xxx

35
Redundância HW - Híbrida
36
Redundância Software

• Se a falha está no software, replicação de
  hardwares é inútil
• Solução replicar o software
• Diversidade
• Blocos de recuperação
• Verificação de consistência

37
Redundância SW - Diversidade

• São implementadas diversas soluções em software
• Resultado determinado por votação
• Diversidade de algoritmos
• Diversidade de versões

38
Redundância SW - Diversidade
39
Redundância SW - Diversidade

• xxx
• Problemas
• Aumento do custo de desenvolvimento
• Não há garantias de que o erro não esteja em
  todas as versões

40
Redundância SW Blocos Recuperação

• xxx

41
Pesquisas sobre IDSs

• Aspectos em desenvolvimento
• Técnicas de Detecção
• Inteligência Artificial
• Sistemas Imunológicos
• Técnicas de Correlação
• Diminuir informações no log
• Identificar ataques distribuídos
• Interoperabilidade
• Diferentes IDSs trocando informações

42
Pesquisas - Interoperabilidade

• Existe uma grande diversidade de IDSs
• análise de assinaturas, métodos estatísticos
• baseados em rede, baseados em host
• centralizados, distribuídos
• Sem padrão de arquitetura e comunicação
• A necessidade de interoperabilidade leva à
  necessidade de padronização

43
Interoperabilidade Padrões

• Modelo CIDF
• Divisão em módulos
• Atualmente abandonado
• Modelo IDWG
• Está em fase de Draft (IETF)
• Modelo de dados IDMEF
• Tendência a ser implementado

44
Interoperabilidade - IDMEF

• Define formato e significados dos dados
• Diversidade de informações
• alertas grandes e pequenos
• rede, sistema operacional, aplicativos
• É orientado a objetos

45
Interoperabilidade IDMEFVisão Geral
46
Interoperabilidade - IDMEF

• Não define comunicação de respostas
• Não gerencia respostas
• Sem interoperabilidade de respostas
• Operador tem que conhecer cada IDS
• Atrazo no envio de respostas

47
Pesquisa LRG Extensão IDWG

• Objetivo geral
• Propor uma extensão ao modelo IDWG, de forma a
  suportar o envio de respostas
• Objetivos específicos
• estender a arquitetura IDWG
• estender o modelo de dados IDMEF
• desenvolver um gerenciador de alertas e respostas

48
Pesquisa LRG Modelo PropostoArquitetura
49
Pesquisa LRG Modelo IDREFVisão Geral
50
Pesquisa LRG - Desenvolvimento

• Componentes desenvolvidos
• IDSMan gerenciador IDMEF / IDREF
• IDSAna ponte entre Analisador e Gerenciador
• IDSRes componente de Contra-Medidas
• Desenvolvida biblioteca IDREF
• Linguagem Java
• Orientação a objetos
• Bibliotecas existentes

51
Pesquisa LRG - Desenvolvimento Bibliotecas
Utilizadas

• Beepcore protocolo BEEP mapeado no TCP
• IDXP-Java perfil IDXP do BEEP
• JavaIDMEF modelo de dados IDMEF
• JPcap captura/geração de pacotes de rede

52
Pesquisa LRG - Desenvolvimento Componente IDSMan
53
Pesquisa LRG - Validação Componente IDSMan
54
Pesquisa LRG - Desenvolvimento Componente IDSAna

• Lê mensagens IDMEF de um arquivo
• Transmite mensagens para o IDSMan
• Um IDS deve alimentar o arquivo

55
Pesquisa LRG - Desenvolvimento Componente IDSRes

• Recebe respostas IDREF do IDSMan
• Armazena as respostas em log
• Aplica as ações aos recursos

56
Pesquisa LRG - Ambiente
57
Considerações Finais

• Atualmente existem vários mecanismos voltados
  para a prevenção de ataques
• Firewall, Criptografia
• Menos representativa é a utilização de mecanismos
  para
• Detecção de ataques
• Identificação de ataques/vulnerabilidades
• Resposta a ataques em andamento

58
Considerações Finais

• Identifica que os mecanismos de prevenção foram
  ultrapassados
• Muitos ataques ocorrem dentro do ambiente
• Funcionários, estudantes
• Um ambiente seguro deve combinar diversos
  mecanismos
• Criptografia, Firewall, IDS, etc.