VMFIT - Virtual Machine-based Fault and Intrusion Tolerance
1. VM-FIT
Supporting Intrusion Tolerance
with Virtualisation Technology
Autores: Hans P. Reiser e Rüdiger Kapitza
Aluno: Leandro Quibem Magnabosco
2. Programa
● O que é VM-FIT?
● Virtual Machine-based Fault and Intrusion
Tolerance
● Problemas de trabalhos relacionados
● Características do Sistema
● Diagrama Xen (Dom0)
● Diagrama VM-FIT (DomNV)
● Arquitetura VM-FIT
– DomainNV
● Implementação de Protótipo
3. O que é VM-FIT
● Implementa Tolerância a Faltas Bizantinas
através do uso de Virtualização
● Cria uma entidade confiável para todos os nós
(DomNV)
● Possibilita:
● Encapsulamento
● Isolamento de faltas
● Detecção a Intrusão
● Verificação formal de componentes
4. Problemas de trabalhos
relacionados
● A implementação em middleware de esquemas
baseados em software
● Inviabiliza encapsulamento e isolamento de faltas
● Alguns trabalhos não assumem a possibilidade da
ocorrência de faltas maliciosas
● Assumem um comportamento para faltas no modelo
crash-stop para faltas benignas (não-maliciosas)
● Componentes comprometidos ficam sem detecção
● Com o tempo, um atacante pode obter acesso
aum número maior de nós, ultrapassando o
número de nós faltosos que o sistema tolera
5. Características do VM-FIT
● Implementação de um novo Domínio
● DomNV – Entidade confiável para todos os nós
● Recuperação Proativa
● Renovação rotineira do estado das VMs
● Encapsulamento e Isolamento de Faltas
● Realizado através separação de componentes em
VMs diferentes
● Simplifica Verificação Formal
de componentes
6. Características do VM-FIT
● Possibilita o uso de ferramentas e métodos de
segurança diretamente no Hypervisor
● Detecção de Intrusão
● Análise de ataques
● Direcionamento de ataques para Honeypots
● Uso de VLANs e DMZs
● Permite alocação dinâmica de recursos
9. Arquitetura VM-FIT
● Assume-se que:
● Clientes somente interagem com serviços através
de um request-reply
– Possibilita a interceptação e análise das interações no
nível de rede
● Os serviços tem comportamento determinístico
– Juntamente com a limitação das interações ao formato
request-reply, produz um modelo do
estado de máquina determinístico que é
utilizado para garantir algumas
características do sistema
10. Arquitetura VM-FIT
(BASE)
● Hypervisor
● Fina camada de software que roda em cima do
hardware
● Domínios Guest
● Rodam em cima do Hypervisor
● Contém os serviços do sistema
● Dom0
● Domínio privilegiado para criação e
manutenção de VMs
11. Arquitetura VM-FIT
(BASE)
● DomainNV
● Domain Network & Voting, concentra funções da camada
de rede e eleição
● Pode ou não estar integrado ao Dom0
● Isolado dos Guests
● Implementa:
– Lógica básica de replicação
– Gerente de replicação
– Funcionalidade básica de rede
● Driver de Rede
● Pilha de comunicação
● Protocolo de comunicação em grupo
● É esperado que falhe apenas no modelo crash-stop,
caindo apenas quando o próprio host cair
12. Arquitetura VM-FIT
Suporte a Replicação
● As réplicas de serviço rodam isoladas no domínio Guest
● Gerente de Replicação
● Intercepta a comunicação entre cliente e serviço
– Independentemente de middleware, sistema operacional no domínio Guest ou implementações de
serviços de gravação
● Implementado no domínio DomainNV
● Possibilita um modelo composto de tolerância a
faltas
● Considera-se dois modelos para VM-FIT:
1) Todos os elementos do sistema podem apresentar faltas
2) O DomainNV só falha no modelo crash-stop, em caso de falha do próprio host
● Em caso de queda do DomainNV, as réplicas pode usar a votação para verificar respostas a
clientes
– Neste caso aplica-se a fórmula n ≥ 2f + 1, onde f é o número máximo de nós com faltas
que serão tolerados
● A opção 1 é mais interessante em termos de
tolerância, mas requer um protocolo de comunicação
de grupo também tolerante a faltas
13. Arquitetura VM-FIT
Suporte a Replicação
● Cada réplica processa o pedido do cliente e
envia a resposta para o nó que recebeu a
conexão do cliente
● O Gerente de Replicação escolhe a resposta
correta através de maioria em votação
● As réplicas podem ser completamente
heterogêneas
● Desde que respeitem o princípio de
comportamento determinístico
14. Arquitetura VM-FIT
Recuperação Proativa
● Consiste em rejuvenescer os nós periodicamente para estados
comprovadamente funcionais
● Aumenta a resistência do sistema
● Com a recuperação proativa, o limite de f nós passa a valer apenas para
cada ciclo de rejuvenescimento ao invés do ciclo de vida total do sistema
● Requer um componente no sistema para controlar o processo
● Um hardware externo a prova de falsificação reiniciando réplicas através de
uma imagem confiável
● O próprio DomainNV pode ser utilizado para a função
15. Arquitetura VM-FIT
Recuperação Proativa
● A recuperação baseada no Hypervisor permite que a
réplica rejuvenescida seja levantada enquanto a
antiga ainda opera, eliminando a necessidade de
réplicas adicionais completas para manter o grau de
disponibilidade atual
● A réplica rejuvenescida é ativada pelo coordenador de
replicação quando o processo for completado, desligando
a réplica não-rejuvenescida
● A réplica rejuvenescida só é ativada quando sincronizado
seu estado com as outras réplicas
● O estado repassado a réplica rejuvenescida é
validado através de maioria em votação
16. Implementação de Protótipo
● Replicação transparente de uma aplicação
baseada em CORBA
● Hypervisor Xen 3.0
● Domínios Dom0, Guest e DomainNV no mesmo
sistema
● Uma vulnerabilidade do Sistema Operacional afetaria
os 3 domínios ao mesmo tempo
– Os autores recomendam Xen como
Hypervisor básico e um kernel minimalista
ou o microkernel L4KA (http://www.l4ka.org/)
para hospedar o DomainNV
17. Implementação de Protótipo
Gerenciando consistência
● O DomainNV do protótipo opera o serviço de endereçamento
CORBA (IOR) e publica estes endereços para um servidor de
nomes
● São utilizados objetos CORBA determinísticos
● Estes objetos devem ser inicializados em 3 níveis:
– Sistema Operacional
– Middleware
– Réplicas
● Objetos CORBA tornam possível a comparação
entre o suporte de replicação do hypervisor e do
middleware
● O algoritmo Paxos é utilizado para ordenação
de mensagens
18. Implementação de Protótipo
Transferência de estado e
Recuperação Proativa
● A cada operação de recuperação proativa é
necessário um checkpoint consistente
resultante de uma maioria entre as réplicas
● Este checkpoint é transferido para a réplica que
está sendo criada
● Finalmente, a nova réplica é inicializada com o
desligamento da antiga