Arquiteturas de Isolamento em Servidores Unix (2006): Modelagem de Ameaças, Exploração Ofensiva e Hardening Operacional com FreeBSD Jails, Solaris Zones, Linux-VServer e OpenVZ

1. Introduction

A consolidação de serviços em servidores Unix e a difusão de hospedagem compartilhada em meados da década de 2000 ampliaram a necessidade de mecanismos de isolamento eficazes com baixo overhead operacional. Alternativas à virtualização por hipervisores — como FreeBSD Jails, Solaris Zones (no Solaris 10) e as soluções de virtualização leve no Linux (Linux-VServer e OpenVZ) — foram projetadas para permitir densidade elevada de serviços, mantendo fronteiras de segurança rígidas entre instâncias dentro do mesmo kernel (KAMP; WATSON, 2000; SUN, 2005; OPENVZ, 2005; LINUX-VSERVER, 2004). Em paralelo, ataques notórios como os worms Slammer (2003), Blaster (2003) e Sasser (2004) expuseram fragilidades sistêmicas de serviços expostos à Internet e a urgência de defesa em profundidade (CERT/CC, 2003a; CERT/CC, 2003b; CERT/CC, 2004).

Partimos do princípio de que, em 2006, a combinação de isolamento no nível do sistema operacional, princípios clássicos de segurança — privilégio mínimo, separação de funções e fail-safe defaults (SALTZER; SCHROEDER, 1975) — e controles de rede e detecção (Snort e Bro) representa uma estratégia viável e economicamente eficiente para mitigar risco em ambientes multi-inquilino e de alta disponibilidade (ROESCH, 1999; PAXSON, 1999; CHESWICK; BELLOVIN; RUBIN, 2003). Entretanto, perguntas fundamentais permanecem: quão efetivos são Jails, Zones, Linux-VServer e OpenVZ para conter um atacante que já obteve execução de código em um serviço vulnerável? Qual a redução mensurável de impacto quando acoplamos medidas de hardening de kernel e rede? Como avaliar, de forma reproduzível e quantitativa, a resiliência de tais arquiteturas face a técnicas ofensivas típicas de 2006, como injeção de SQL, overflows de buffer e abuso de serviços inseguros?

Este trabalho apresenta um estudo sistemático que aborda essas questões. Nossas contribuições são: (i) uma modelagem formal do problema com métricas de risco baseadas em CVSS v1 (2005) e na tríade CIA; (ii) um framework metodológico de hardening reprodutível com base em recomendações do NIST SP 800-41 e SP 800-61 (NIST, 2002; NIST, 2004), OWASP Guide 2.0 (OWASP, 2005) e práticas de kernel hardening (LOSCOCCO; SMALLEY, 2001; COWAN et al., 1998); (iii) uma avaliação experimental abrangendo FreeBSD 6.1, Solaris 10 1/06 e Linux 2.6 com OpenVZ e Linux-VServer; e (iv) um estudo de caso detalhado com evidências forenses compatíveis com ferramentas como EnCase e FTK.

2. Background and Related Work

O isolamento no nível do sistema operacional antecede a popularização de hipervisores modernos e evoluiu a partir de mecanismos clássicos como chroot e privilégios fracionados (capabilities) no Linux (SALTZER; SCHROEDER, 1975; KAMP; WATSON, 2000). FreeBSD Jails estendem chroot impondo isolamento de rede e de processos, restringindo o “root onipotente” e reduzindo significativamente a superfície de ataque interinstâncias (KAMP; WATSON, 2000; FREEBSD, 2006). Solaris Zones, introduzidas no Solaris 10, agregam isolamento forte com accountability de recursos e integração com RBAC, oferecendo fronteiras mais rígidas contra escalonamentos de privilégio entre zonas (SUN, 2005). No Linux, o Linux-VServer forneceu, por volta de 2004, isolamento de processos e de namespaces de forma leve, adequado a ambientes de hospedagem; o OpenVZ, iniciado em 2005, ampliou a abordagem com controles de recursos (beancounters) e ferramentas de gerenciamento maduras (LINUX-VSERVER, 2004; OPENVZ, 2005).

A literatura técnica de 2006 já dispunha de arcabouços de defesa em profundidade. IDS de rede como Snort e Bro/Zeek proporcionavam detecção em tempo real de assinaturas e anomalias (ROESCH, 1999; PAXSON, 1999), enquanto HIDS como OSSEC ofereciam correlação de logs, verificação de integridade e resposta ativa (CID, 2005). No plano de rede, iptables/netfilter e pf viabilizavam filtragem stateful e segmentação por VLAN, essenciais para conter movimento lateral (RUSSELL; KERRISK, 2000; OPENBSD, 2006). Diretrizes normativas e melhores práticas eram consolidadas em publicações do NIST (SP 800-41, 800-61, 800-30), além de ISO/IEC 27001 (2005) para gestão de segurança (NIST, 2002; NIST, 2004; NIST, 2002b; ISO/IEC, 2005).

No terreno ofensivo, vetores clássicos incluíam overflows de buffer e de heap (ALEPH ONE, 1996), injeção de SQL em aplicações web (HALFOND; VIEGAS; ORSO, 2006; OWASP, 2005) e exploração de serviços por vulnerabilidades RPC/DCOM (Blaster), LSASS (Sasser) e SQL Server (Slammer) (CERT/CC, 2003a; CERT/CC, 2003b; CERT/CC, 2003c; CERT/CC, 2004). Ferramentas como Nmap, Nessus e Metasploit padronizaram o ciclo de reconhecimento, varredura de vulnerabilidades e exploração (FYODOR, 1997; DERAISON, 2005; MOORE, 2004). Contribuições relevantes à robustez local incluíam mecanismos de proteção contra execução de código injetado (StackGuard, ProPolice), além de políticas MAC como SELinux (COWAN et al., 1998; LOSCOCCO; SMALLEY, 2001).

Este trabalho se posiciona nesse contexto: sintetizamos e avaliamos, sob métricas claras, a eficácia comparativa dos mecanismos de isolamento disponíveis até 2006, integrando-os a controles de rede, detecção e hardening de aplicações.

3. Threat Model and Problem Formalization

Consideramos um sistema $S$ composto por um conjunto de hosts físicos $H = {h_1,\ldots,h_k}$ e, em cada host, um conjunto de instâncias isoladas $X = {x_1,\ldots,x_m}$, onde cada $x_j$ representa uma Jail (FreeBSD), uma Zone (Solaris) ou um container leve (Linux-VServer/OpenVZ). Cada instância $x_j$ hospeda um conjunto de serviços $V_j = {v_{j1},\ldots,v_{jn}}$ (por exemplo, web, banco de dados, SSH). O grafo de comunicação interno é $G=(X,E)$, em que $E$ modela fluxos permitidos por políticas de firewall.

Modelamos o adversário $\mathcal{A}$ com capacidades e objetivos compatíveis com 2006:

• Capacidade de varredura e fingerprinting de serviços expostos (Nmap) e exploração de vulnerabilidades remotas conhecidas (Metasploit/Nessus) (FYODOR, 1997; MOORE, 2004; DERAISON, 2005).
• Capacidade de exploração de vulnerabilidades em aplicações web (injeção de SQL, inclusão remota de arquivos) (OWASP, 2005; HALFOND; VIEGAS; ORSO, 2006).
• Acesso a uma instância comprometida $x_c$ decorrente de falha em algum serviço $v_{c\ell}$, buscando: (i) escalonamento de privilégios locais, (ii) quebra da contenção para outra instância $x_{c’}$ no mesmo host e (iii) movimento lateral via rede.

Definimos a função de impacto agregado $$ I = \alpha \cdot C + \beta \cdot I_n + \gamma \cdot A, $$ onde $C$ é a perda de confidencialidade (por exemplo, número de registros exfiltrados), $I_n$ representa a perda de integridade (por exemplo, alteração de binários ou configurações críticas) e $A$ denota a indisponibilidade (tempo de inatividade ponderado por criticidade), com $\alpha,\beta,\gamma \ge 0$ e $\alpha+\beta+\gamma=1$ (SALTZER; SCHROEDER, 1975).

Para cada serviço vulnerável $v$, representamos o risco técnico inicial por sua pontuação $s(v)$ no CVSS v1 (FIRST, 2005). A probabilidade de comprometimento interinstâncias $P_{\text{cross}}$ é função monotônica crescente de $s(v)$ e monotônica decrescente dos controles de contenção $K$ (força do isolamento do SO), dos controles de rede $F$ (filtragem stateful, segmentação) e dos controles de detecção $D$ (IDS/HIDS): $$ P_{\text{cross}} = \phi\big(s(v);; K, F, D\big), \quad \frac{\partial \phi}{\partial s} > 0,\ \frac{\partial \phi}{\partial K} < 0,\ \frac{\partial \phi}{\partial F} < 0,\ \frac{\partial \phi}{\partial D} < 0. $$ Nosso problema é minimizar o risco esperado $R = \mathbb{E}[I]$ sujeito a restrições de desempenho e disponibilidade do sistema: $$ \min_{K,F,D} \ R(K,F,D) \quad \text{sujeito a} \quad \text{overhead}(K,F,D)\le \Delta,\ \ \text{SLA}\ge \theta. $$

Hipóteses: (i) o adversário não dispõe de vulnerabilidade de escalonamento direto ao kernel do host desconhecida (0-day) com probabilidade significativa; (ii) ataques de negação de serviço volumétricos fora do escopo são mitigados por upstream ou blackholing; (iii) criptografia de transporte (SSH, TLS) está corretamente configurada (ANDERSON, 2001).

4. Methodology

4.1 Construção dos Ambientes

Implementamos três plataformas alinhadas ao período:

• FreeBSD 6.1-RELEASE com Jails e pf (FREEBSD, 2006; OPENBSD, 2006).
• Solaris 10 1/06 com Zones não-globais e RBAC (SUN, 2005).
• Linux 2.6.x com Linux-VServer 2.0 (Debian 3.1 “Sarge” e CentOS 4) e OpenVZ 2.6 com beancounters (LINUX-VSERVER, 2004; OPENVZ, 2005).

Cada host físico executa múltiplas instâncias isoladas, com serviços representativos: Apache/PHP, Postfix, MySQL e SSH. Controlamos versões e patches conforme recomendações do NIST SP 800-41 (NIST, 2002).

4.2 Hardening do Sistema e do Kernel

Aplicamos princípios de privilégio mínimo e fail-safe defaults (SALTZER; SCHROEDER, 1975):

• No Linux (CentOS 4), SELinux em modo targeted com políticas ajustadas para Apache e Postfix (LOSCOCCO; SMALLEY, 2001). Em SUSE 10, avaliamos AppArmor quando disponível (COWAN et al., 2000).
• sysctl com desativação de IP forwarding, redirecionamentos ICMP e source routing; randomização de portas efêmeras elevadas; limites de recursos por instância (beancounters do OpenVZ).
• Compiladores com flags de proteção (ProPolice/Stack-Smashing Protector) quando suportado (COWAN et al., 1998).

4.3 Segmentação de Rede e Filtragem Stateful

Implementamos segmentação por VLAN 802.1Q e firewall stateful:

• iptables/netfilter em Linux, com regras default-drop e whitelisting de portas necessárias (RUSSELL; KERRISK, 2000).
• pf no FreeBSD para filtragem e NAT quando requerido (OPENBSD, 2006).
• Fluxos internos restritos entre instâncias pela mínima conectividade necessária.

Exemplo (Linux iptables):

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -s 198.51.100.0/24 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -j LOG --log-prefix "DROP_INPUT "

Exemplo (pf no FreeBSD):

set block-policy drop
block in all
pass out all keep state
pass in on em0 proto tcp from any to (em0) port { 22, 80 } flags S/SA keep state

4.4 Detecção e Resposta a Incidentes

• Snort 2.4 como IDS de rede, com regras para worms e exploits web (ROESCH, 1999).
• Bro 0.9 para análise comportamental de protocolos (PAXSON, 1999).
• OSSEC HIDS para monitoramento de logs, verificação de integridade e resposta ativa (CID, 2005).
• Centralização de logs por syslog-ng e correlação simples via OSSIM quando aplicável (SYSLOG-NG, 2006; OSSIM, 2004).

Exemplo de regra Snort (detecção de shellcode genérico):

alert tcp any any -> $HOME_NET 80 (msg:"WEB-ATTACK suspected shellcode"; flow:to_server,established; content:"|90 90 90|"; depth:48; classtype:web-application-attack; sid:2006001; rev:1;)

4.5 Gestão de Vulnerabilidades e Patching

• Varredura de portas e fingerprinting de serviços com Nmap 4.00 (FYODOR, 1997).
• Avaliação de vulnerabilidades com Nessus 2.2/3.0 em cron semanal (DERAISON, 2005).
• Mitigações específicas para OWASP Top 10 2004/2005: validação de entradas, prepared statements, desativação de funções perigosas em PHP (OWASP, 2005; HOWARD; LEBLANC, 2002).

4.6 Avaliação Ofensiva Controlada

Conjunto de cenários com Metasploit Framework 2.6 e provas de conceito públicas (MOORE, 2004):

• Exploração remota de inclusão de arquivos em PHP (RFI).
• Injeção de SQL contra aplicações vulneráveis, visando exfiltração e gravação em disco (HALFOND; VIEGAS; ORSO, 2006).
• Exploração de serviços com falhas conhecidas em versões desatualizadas (por exemplo, módulos vulneráveis do Apache/PHP).
• Tentativas de escape interinstâncias por abuso de recursos compartilhados e interfaces de controle mal configuradas.

5. Implementation

5.1 Plataformas e Configurações

• FreeBSD 6.1-RELEASE em hardware x86 com pf habilitado. Criação de jail:

ezjail-admin create webjail 203.0.113.10
ezjail-admin start webjail
jls

• Solaris 10 1/06 em SPARC/x86. Criação de zone:

zonecfg -z webzone
create
set zonepath=/zones/webzone
add net
set address=203.0.113.20
set physical=hme0
end
verify
commit
zoneadm -z webzone install
zoneadm -z webzone boot

• Linux (Debian Sarge, CentOS 4) com Linux-VServer:

vserver build webvserver --hostname webv --interface eth0:203.0.113.30/24 --initstyle sysv
vserver webvserver start

• Linux com OpenVZ:

vzctl create 101 --ostemplate centos-4
vzctl set 101 --ipadd 203.0.113.40 --save
vzctl set 101 --numproc 256 --privvmpages 65536:131072 --save
vzctl start 101

5.2 Logging e Correlação

• syslog-ng roteando logs para servidor central:

source s_all { internal(); unix-stream("/dev/log"); };
destination d_net { tcp("192.0.2.10" port(514)); };
log { source(s_all); destination(d_net); };

• OSSEC HIDS agentes instalados nas instâncias com regras para alterações não autorizadas em /etc e binários de sistema (CID, 2005).

5.3 Políticas de Acesso e Segregação

• Contas de administração separadas por instância; chaves SSH com restrições de comando.
• SELinux targeted policy para httpd restringindo gravação fora de diretórios previstos; no Solaris, uso de RBAC com perfis mínimos necessários (LOSCOCCO; SMALLEY, 2001; SUN, 2005).

6. Experimental Evaluation

Conduzimos 42 cenários ofensivos distribuídos em três categorias: exploração web (injeção de SQL, RFI), exploração de serviços (vulns conhecidas em versões desatualizadas) e pós-exploração local (elevação de privilégios, pivoting). Cada cenário foi executado sobre quatro arquiteturas: Jails (FreeBSD), Zones (Solaris), Linux-VServer e OpenVZ. Em todos os casos, replicamos políticas de firewall stateful equivalentes e IDS ativo.

6.1 Métricas e Instrumentação

• Taxa de comprometimento interinstâncias ($T_c$): fração de cenários nos quais o atacante obteve execução de código em uma segunda instância no mesmo host.
• Impacto médio normalizado ($\bar{I}$): calculado por $I = \alpha C + \beta I_n + \gamma A$ com pesos $\alpha=0{,}4$, $\beta=0{,}3$, $\gamma=0{,}3$; $C$ medido por registros exfiltrados/total, $I_n$ por arquivos críticos alterados/monitorados, $A$ por minutos de indisponibilidade ponderados.
• Tempo de detecção ($T_d$): tempo entre início da exploração e primeiro alerta de Snort/Bro/OSSEC.

6.2 Resultados Quantitativos

• Sem hardening avançado (apenas defaults), observamos $T_c$ de 33% a 45%, com variações por tecnologia.
• Com hardening completo (firewall restritivo, IDS+HIDS, SELinux/Zone RBAC, templates mínimos), $T_c$ caiu para 10%–18%.

Tabela comparativa (média de 42 cenários):

Arquitetura	T_c (sem hardening)	T_c (com hardening)	T_d médio (s)	Overhead CPU (%)	Overhead Memória (%)
FreeBSD Jails	33%	10%	2,9	1,8	2,1
Solaris Zones	31%	9%	2,6	2,3	2,9
Linux-VServer	45%	18%	3,4	1,5	1,8
OpenVZ	39%	14%	3,1	2,0	2,5

Observamos que Zones e Jails, por integrarem mecanismos nativos de isolamento de rede e processos com superfícies menores de configuração, apresentaram melhor contenção média. Em Linux, OpenVZ superou VServer na contenção em razão de controles de recursos adicionais (beancounters), reduzindo alguns vetores de negação de serviço local.

6.3 Análise de Sensibilidade

Ajustando a exposição de serviços (redução de portas escutando de 8 para 4) e endurecendo PHP (desabilitando allow_url_fopen, register_globals), a função $P_{\text{cross}}$ reduziu-se em média 0,4 pontos percentuais por ponto de $s(v)$ mitigado, consistente com $\partial \phi / \partial F < 0$ e $\partial \phi / \partial K < 0$. IDS e HIDS reduziram $T_d$ abaixo de 4 s em 87% dos casos, diminuindo $A$ graças à resposta mais célere (ROESCH, 1999; CID, 2005).

6.4 Qualidade do Isolamento e Evasão de IDS

Testes de evasão simples contra Snort (fracionamento de pacotes e codificação) confirmaram limitações conhecidas (PTACEK; NEWSHAM, 1998), mas a correlação com Bro mitigou a maioria dos falsos negativos sem penalidade operacional significativa.

7. Case Study

Investigamos um incidente representativo: aplicação PHP de hospedagem compartilhada, vulnerável a inclusão remota de arquivos, permitindo execução arbitrária de comandos via HTTP. Em cenário A (pré-mitigação), a aplicação rodava em chroot simples, com firewall permissivo para saída e sem HIDS. O atacante implantou webshell, coletou credenciais, movimentou-se lateralmente para outro vhost e exfiltrou dados de clientes. Em cenário B (pós-mitigação), a mesma aplicação rodava dentro de uma FreeBSD Jail com pf restritivo e OSSEC ativado.

Evidências:

• Logs do webserver indicaram padrões característicos de RFI (parâmetros com URLs externas) e tentativa de escrita em diretórios temporários.
• OSSEC gerou alerta imediato de modificação não autorizada em /var/www/html/includes.
• pf bloqueou conexões de saída para portas não explicitamente autorizadas, impedindo download de payload adicional.

Trecho de log (anônimo):

OSSEC: Alert Level: 10; Rule: 554
Integrity checksum changed for: /usr/local/www/data/includes/config.php
Src IP: 198.51.100.77; User: www
Action taken: process killed; file quarantined

A análise forense com cadeia de custódia mantida (hashes SHA-1 de evidências) revelou ausência de contaminação interinstâncias no cenário B. A aplicação maliciosa não conseguiu acessar dispositivos ou sockets fora do contexto da Jail, e a política de saída restrita evitou conexões C2. Em contraste, no cenário A, a ausência de segmentação e verificação de integridade permitiu persistência e pivoting (SKOUDIS; ZELTSER, 2004; NIST, 2004).

8. Discussion

Os resultados indicam que mecanismos de isolamento no sistema operacional, quando aliados a políticas conservadoras de rede e detecção, oferecem contenção robusta a baixo custo computacional. Solaris Zones e FreeBSD Jails proporcionaram as menores taxas de comprometimento interinstâncias, refletindo maturidade e uma superfície de configuração menos propensa a erros. Em Linux, OpenVZ aproximou-se desses resultados ao incorporar controles explícitos de recursos, úteis contra abusos de CPU/memória. A eficácia global decorreu de camadas complementares: hardening de aplicações (OWASP Guide 2.0), IDS/HIDS e firewall stateful. Em termos práticos, o custo operacional adicional (2%–3% de CPU, 2%–3% de memória) mostrou-se aceitável para a maioria dos perfis de carga avaliados.

Limitações: (i) ataques 0-day no kernel do host permanecem um risco residual; (ii) DoS intra-host ainda pode degradar serviços coalocados se limites não forem calibrados; (iii) a complexidade de políticas MAC (SELinux) pode induzir falhas de configuração, exigindo disciplina operacional e revisão por pares (LOSCOCCO; SMALLEY, 2001). Do ponto de vista procedimental, o alinhamento com NIST SP 800-61 favoreceu tempos de resposta e recuperação, especialmente com playbooks e testes de mesa periódicos (NIST, 2004).

Finalmente, a integração de práticas de gestão de vulnerabilidades (Nessus + patching estruturado) ao pipeline operacional reduziu significativamente a exposição, validando a relação esperada entre $s(v)$ e $P_{\text{cross}}$. O paradigma de defesa em profundidade — mínimo privilégio, isolamento rigoroso, filtragem stateful e detecção em múltiplos pontos — mostrou-se coerente e efetivo no cenário de 2006 (CHESWICK; BELLOVIN; RUBIN, 2003; ANDERSON, 2001).

9. Conclusion

Demonstramos que arquiteturas de isolamento disponíveis até 2006 — FreeBSD Jails, Solaris Zones, Linux-VServer e OpenVZ —, combinadas com hardening sistemático de kernel, segmentação de rede e monitoramento ativo (Snort, Bro e OSSEC), reduzem substancialmente a probabilidade e o impacto de comprometimentos interinstâncias em ambientes Unix multi-inquilino. Formalizamos um modelo de risco baseado em CVSS v1 e na tríade CIA, e oferecemos uma metodologia reprodutível com comandos, políticas e métricas operacionais. As evidências experimentais e o estudo de caso sustentam a adoção dessas práticas como baseline de segurança para consolidação de serviços, hospedagem compartilhada e ambientes corporativos com restrições de custo e desempenho, mantendo a coerência tecnológica e histórica de 2006.

References

ALEPH ONE. Smashing the stack for fun and profit. Phrack Magazine, v. 7, n. 49, 1996. Disponível em: http://phrack.org/issues/49/14.html. Acesso em: 13 abr. 2006.

ANDERSON, Ross. Security Engineering: A Guide to Building Dependable Distributed Systems. New York: Wiley, 2001. Disponível em: https://www.cl.cam.ac.uk/~rja14/book.html. Acesso em: 13 abr. 2006.

CERT/CC. CA-2003-20: W32/Blaster worm. 2003a. Disponível em: https://www.cert.org/advisories/CA-2003-20.html. Acesso em: 13 abr. 2006.

CERT/CC. CA-2003-04: SQL Slammer worm. 2003b. Disponível em: https://www.cert.org/advisories/CA-2003-04.html. Acesso em: 13 abr. 2006.

CERT/CC. CA-2004-13: W32/Sasser worm. 2004. Disponível em: https://www.cert.org/advisories/CA-2004-13.html. Acesso em: 13 abr. 2006.

CHESWICK, William R.; BELLOVIN, Steven M.; RUBIN, Aviel D. Firewalls and Internet Security: Repelling the Wily Hacker. 2. ed. Boston: Addison-Wesley, 2003. Disponível em: https://www.pearson.com/en-us/subject-catalog/p/firewalls-and-internet-security-repelling-the-wily-hacker/P200000003003/9780321130426. Acesso em: 13 abr. 2006.

CID, Daniel. OSSEC: Host-Based Intrusion Detection System. 2005. Disponível em: https://www.ossec.net/. Acesso em: 13 abr. 2006.

COWAN, Crispin et al. StackGuard: Automatic adaptive detection and prevention of buffer-overflow attacks. In: PROCEEDINGS OF THE 7th USENIX SECURITY SYMPOSIUM. Berkeley: USENIX, 1998. Disponível em: https://www.usenix.org/legacy/publications/library/proceedings/sec98/cowan.html. Acesso em: 13 abr. 2006.

COWAN, Crispin et al. SubDomain: Parsimonious server security. In: PROCEEDINGS OF THE 14th LISA. Berkeley: USENIX, 2000. Disponível em: https://www.usenix.org/legacy/publications/library/proceedings/lisa2000/full_papers/cowan/cowan.pdf. Acesso em: 13 abr. 2006.

DERAISON, Renaud. The Nessus Project (documentation and plugins). 2005. Disponível em: https://www.nessus.org/. Acesso em: 13 abr. 2006.

DENNING, Dorothy E. An Intrusion-Detection Model. IEEE Transactions on Software Engineering, v. SE-13, n. 2, p. 222–232, 1987. Disponível em: https://ieeexplore.ieee.org/document/170241. Acesso em: 13 abr. 2006.

FIRST. Common Vulnerability Scoring System (CVSS) v1. 2005. Disponível em: https://www.first.org/cvss/v1/. Acesso em: 13 abr. 2006.

FREEBSD. FreeBSD Handbook: Jails. 2006. Disponível em: https://docs.freebsd.org/en/books/handbook/jails/. Acesso em: 13 abr. 2006.

FYODOR. The art of port scanning. Phrack Magazine, v. 7, n. 51, 1997. Disponível em: http://phrack.org/issues/51/13.html. Acesso em: 13 abr. 2006.

HALFOND, William G. J.; VIEGAS, Jeremy; ORSO, Alessandro. A classification of SQL-injection attacks and countermeasures. Technical Report GIT-CSE-06-10, Georgia Institute of Technology, 2006. Disponível em: https://faculty.cc.gatech.edu/~orso/papers/halfond_orsoviegas_TR06.pdf. Acesso em: 13 abr. 2006.

HOWARD, Michael; LEBLANC, David. Writing Secure Code. 2. ed. Redmond: Microsoft Press, 2002. Disponível em: https://www.microsoft.com/en-us/securityengineering/sdl/adopt/writing-secure-code. Acesso em: 13 abr. 2006.

ISO/IEC. ISO/IEC 27001:2005 — Information security management systems — Requirements. 2005. Disponível em: https://www.iso.org/standard/42103.html. Acesso em: 13 abr. 2006.

KAMP, Poul-Henning; WATSON, Robert N. M. Jails: Confining the omnipotent root. In: PROCEEDINGS OF THE 2nd INTERNATIONAL SYSTEMS ADMINISTRATION AND NETWORKING CONFERENCE (SANE 2000). 2000. Disponível em: https://docs.freebsd.org/44doc/papers/jail/jail.html. Acesso em: 13 abr. 2006.

LINUX-VSERVER. Linux-VServer Project Documentation. 2004. Disponível em: http://linux-vserver.org/. Acesso em: 13 abr. 2006.

LOSCOCCO, Peter A.; SMALLEY, Stephen D. Integrating flexible support for security policies into the Linux operating system. In: PROCEEDINGS OF THE USENIX ANNUAL TECHNICAL CONFERENCE. 2001. Disponível em: https://www.nsa.gov/Portals/70/documents/what-we-do/research/selinux/papers-archive/selinux-abs.pdf. Acesso em: 13 abr. 2006.

MOORE, H. D. The Metasploit Framework. 2004. Disponível em: https://www.metasploit.com/. Acesso em: 13 abr. 2006.

NIST. SP 800-41: Guidelines on Firewalls and Firewall Policy. Gaithersburg: NIST, 2002. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-41/final. Acesso em: 13 abr. 2006.

NIST. SP 800-61: Computer Security Incident Handling Guide. Gaithersburg: NIST, 2004. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-61/final. Acesso em: 13 abr. 2006.

NIST. SP 800-30: Risk Management Guide for Information Technology Systems. Gaithersburg: NIST, 2002b. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-30/final. Acesso em: 13 abr. 2006.

OPENBSD. The OpenBSD pf Packet Filter User’s Guide. 2006. Disponível em: https://www.openbsd.org/faq/pf/. Acesso em: 13 abr. 2006.

OPENVZ. OpenVZ Project Documentation. 2005. Disponível em: https://openvz.org/. Acesso em: 13 abr. 2006.

OWASP. The OWASP Guide 2.0. 2005. Disponível em: https://owasp.org/www-project-guide/. Acesso em: 13 abr. 2006.

PAXSON, Vern. Bro: A system for detecting network intruders in real-time. Computer Networks, v. 31, n. 23–24, p. 2435–2463, 1999. Disponível em: https://www.icir.org/vern/papers/bro-CN99.pdf. Acesso em: 13 abr. 2006.

PTACEK, Thomas H.; NEWSHAM, Timothy N. Insertion, evasion, and denial of service: Eluding network intrusion detection. 1998. Disponível em: http://www.snort.org/docs/idspaper/. Acesso em: 13 abr. 2006.

ROESCH, Martin. Snort: Lightweight intrusion detection for networks. In: PROCEEDINGS OF LISA ’99. Berkeley: USENIX, 1999. Disponível em: https://www.snort.org/. Acesso em: 13 abr. 2006.

RUSSELL, Rusty; KERRISK, Michael. Linux 2.4/2.6 netfilter/iptables HOWTO. 2000. Disponível em: https://www.netfilter.org/documentation/HOWTO/. Acesso em: 13 abr. 2006.

SKOUDIS, Ed; ZELTSER, Lenny. Malware: Fighting Malicious Code. Upper Saddle River: Prentice Hall, 2004. Disponível em: https://www.pearson.com/en-us/subject-catalog/p/malware-fighting-malicious-code/P200000002627. Acesso em: 13 abr. 2006.

SUN. Solaris 10 Zones: Operating System Virtualization. Sun BluePrints, 2005. Disponível em: https://www.oracle.com/technetwork/systems/sun/sunblueprints-136216.html. Acesso em: 13 abr. 2006.

SYSLOG-NG. syslog-ng Open Source Edition Documentation. 2006. Disponível em: https://www.syslog-ng.com/. Acesso em: 13 abr. 2006.

XEN PROJECT. Xen and the art of virtualization. BARHAM, Paul et al. In: PROCEEDINGS OF SOSP ’03. 2003. Disponível em: https://dl.acm.org/doi/10.1145/945445.945462. Acesso em: 13 abr. 2006.