HKHiago Kin Levi
← Voltar aos artigos

Paper Files / Containers

Segurança de Perímetro e Serviços em Redes Corporativas (até 2006): Modelagem Formal de Ameaças, Técnicas de Exploração e Estratégias Defensivas Baseadas em Evidências Empíricas

ContainersPT

SecFilterDefaultAction "deny,log,status:403" SecFilterSelective ARG_NAMES|ARGS "(?i:(union.select|select.from|sleep\()" ``` Varredura de descoberta (Nmap): ``` nmap -sS -sV -O -T4 -p1-1024,1433,1434,3306,3389 192.0.2.0/24 ``` Avaliação de vulnerabilidades (Nessus CLI): ``` nessus -q -x -T html -p all -V 192.0.2.10 ``` Exploração controlada (Metasploit 2.6) de RPC DCOM (MS03-026) em host vulnerável: ``` msfconsole use exploit/windows/dcerpc/ms03_026_dcom set RHOST 192.0.2.50 set PAYLOAD windows/shell_bind_tcp set LPORT 4444 exploit ``` Complexidade de processamento para Snort com $n$ r

  1. Introduction

A superfície de ataque predominante em redes corporativas até 2006 compreende serviços de rede expostos na borda (HTTP, SMTP, DNS, VPN/IPsec), protocolos legados na rede interna (SMB/RPC, NetBIOS, TFTP), pilhas de aplicações web emergentes (Apache/IIS + PHP/ASP + bancos de dados relacionais) e estações Windows suscetíveis a exploração remota por vulnerabilidades no RPC/DCOM, LSASS e serviços auxiliares (MICROSOFT, 2003; MICROSOFT, 2004). A frequência e a velocidade de propagação de worms como Code Red, Slammer, Blaster e Sasser evidenciam que a defesa deve combinar filtragem de perímetro, detecção em rede e host, práticas de desenvolvimento seguro e processos de correção ágeis (MOORE et al., 2003; STANIFORD; PAXSON; WEAVER, 2002; CERT/CC, 2003).

Neste contexto, a adoção de firewalls stateful e a consolidação de IDS baseados em assinaturas e anomalias — com destaque para Snort e Bro — tornaram-se pilares na visibilidade e resposta a intrusões (ROESCH, 1999; PAXSON, 1999). Em paralelo, o avanço de mecanismos de endurecimento no nível do sistema operacional, como canários de pilha (StackGuard/ProPolice), aleatorização de espaço de endereçamento (PaX/ASLR) e políticas de controle de acesso mandatórias (SELinux/AppArmor), aumentou notavelmente o custo esperado de exploração de vulnerabilidades de memória (COWAN et al., 1998; ETOH; YODA, 2000; PAX TEAM, 2003; LOSCOCCO; SMALLEY, 2001).

Embora marcos fundamentais como o TLS 1.0 e o SSHv2 tenham promovido comunicações seguras, a segurança sistêmica em 2006 dependia fortemente da correta configuração de serviços, da segregação de redes (DMZ, VLANs), da gestão de patches e da correlação manual ou semiautomática de eventos de segurança (RFC 2246; RFC 4251; NIST, 2002a; NIST, 2004). Modelos de risco precisavam lidar com o caráter heterogêneo da infraestrutura e a multiplicidade de vetores, desde varreduras massivas até ataques dirigidos mediados por exploração de estouro de buffer ou injeção de SQL (ALEPH ONE, 1996; HALFOND; VIEGAS; ORSO, 2006; OWASP, 2004).

Este trabalho oferece uma contribuição integrada de teoria e prática. Em primeiro lugar, formalizamos o risco por vetor e por ativo, quantificando a influência de controles técnicos historicamente disponíveis até 2006 sobre a probabilidade de exploração e sobre o impacto. Em segundo lugar, apresentamos uma metodologia de defesa em camadas com especificações operacionais e critérios de avaliação. Em terceiro lugar, realizamos uma avaliação empírica em laboratório com ferramentas contemporâneas (Nmap, Nessus, Snort, Bro, OSSEC, ModSecurity, Metasploit, iptables), comparando taxas de detecção, falsos positivos, latência de resposta e sobrecarga.

Adicionalmente, oferecemos um estudo de caso que replica condições de exposição de RPC/DCOM e ilustra o ciclo completo de detecção, contenção e forense. Ao longo do texto, vinculamos os resultados a recomendações normativas (NIST SP 800-30/41/44/61) e à literatura de ataques e defesas até 2006, consolidando um guia aplicado e formalmente justificado para a proteção de redes corporativas nesse período (NIST, 2002a; NIST, 2002b; NIST, 2002c; NIST, 2004).

  1. Background and Related Work

2.1 Arquitetura de Perímetro e Serviços

Arquiteturas corporativas típicas até 2006 adotavam uma DMZ para hospedar serviços voltados à Internet (web, e-mail, DNS autoritativo) separados da rede interna por firewalls stateful e, muitas vezes, por proxies e balanceadores de carga de camada 7 (CHESWICK; BELLovin; RUBIN, 2003). O firewall realizava filtragem por estado (seguindo a semântica de conexões TCP e mapeando fluxos UDP) e regras de origem/destino/porta, frequentemente complementado por NAT, o que reduzia a exposição de endereços internos (NIST, 2002b). No Linux, o Netfilter/iptables consolidou-se como mecanismo de filtragem com cadeias para prerouting, input, forward, output e postrouting, possibilitando arquiteturas flexíveis de encaminhamento e inspeção (NETFILTER.ORG, 2006).

Servidores web baseados em Apache HTTPD em conjunto com PHP/Perl e bancos relacionais (MySQL/PostgreSQL) formavam a pilha LAMP, enquanto ambientes Windows Server forneciam diretórios (Active Directory), compartilhamentos (SMB) e serviços RPC/DCOM amplamente explorados por worms e toolkits (MICROSOFT, 2003; MICROSOFT, 2004). A segurança de camada de aplicação tornou-se crítica devido a falhas como injeção de SQL, XSS e execução remota por upload de arquivos, motivando o surgimento de WAFs, dentre os quais o ModSecurity (RISTIC, 2006; OWASP, 2004).

2.2 Taxonomia de Ameaças

Ameaças de rede predominantes no período incluem: (i) varreduras massivas automatizadas visando serviços padrão (FTP, Telnet, SSH, SMTP, HTTP, MSSQL 1433/1434) (FYODOR, 1997); (ii) worms autorreplicantes com propagação super-rápida via exploração de vulnerabilidades conhecidas (STANIFORD; PAXSON; WEAVER, 2002; MOORE et al., 2003); (iii) exploração de corrupção de memória, notadamente stacks e heaps, por injeção de shellcode e/ou técnicas de retorno para libc (ALEPH ONE, 1996; SOLAR DESIGNER, 1997); (iv) vulnerabilidades de aplicação web, das quais a injeção de SQL e o XSS se destacaram (OWASP, 2004; HALFOND; VIEGAS; ORSO, 2006); (v) ataques criptográficos práticos contra protocolos mal configurados e certificados vulneráveis, mitigados por TLS/SSL correto e PKI conforme X.509 (RFC 2246; RFC 2459).

Evasões de IDS por fragmentação, inserção e manipulação de TTLs foram exaustivamente documentadas e impulsionaram melhorias nas arquiteturas de detecção (PTACEK; NEWSHAM, 1998). Do ponto de vista da resposta, a normatização de processos de tratamento de incidentes e cadeia de custódia evoluiu substancialmente (NIST, 2004; SPITZNER, 2002).

2.3 Trabalhos Correlatos

No campo da detecção, Snort popularizou assinaturas leves e processamento modular (ROESCH, 1999), enquanto Bro introduziu uma abordagem baseada em políticas e análise de protocolos com scripts de alto nível (PAXSON, 1999). Ferramentas de varredura e avaliação de vulnerabilidades — como Nmap e Nessus — viabilizaram ciclos de descoberta e mitigação (FYODOR, 1997; TENABLE, 2004).

Do ponto de vista formal, o modelo de Dolev-Yao consolidou-se como referência para análise de protocolos, sendo complementado por lógicas como BAN e, posteriormente, por ferramentas de verificação automática como ProVerif (DOLEV; YAO, 1983; BURROWS; ABADI; NEEDHAM, 1989; BLANCHET, 2001). A quantificação de risco por grafos de ataque e métricas agregadas de vulnerabilidades também ganhou relevo (PHILLIPS; SWILER, 1998; NOEL; JAJODIA, 2005; FIRST, 2005).

Em endurecimento de sistemas, StackGuard/ProPolice, ASLR/PaX e SELinux/AppArmor forneceram bases robustas para reduzir a viabilidade de exploração clássica (COWAN et al., 1998; ETOH; YODA, 2000; PAX TEAM, 2003; LOSCOCCO; SMALLEY, 2001; NOVELL, 2005). Aplicações web passaram a ser protegidas por validação robusta, prepared statements e WAFs como ModSecurity (RISTIC, 2006; OWASP, 2004). Em forense, o uso de EnCase e FTK consolidou práticas de coleta, preservação e análise de evidências (GUIDANCE SOFTWARE, 2004; ACCESSDATA, 2005).

  1. Threat Model and Problem Formalization

Adotamos uma modelagem por camadas de adversários, do escaneador oportunista ao atacante direcionado. No plano de rede, assumimos o modelo de Dolev-Yao: o adversário pode interceptar, injetar e reordenar mensagens na rede, limitado apenas por propriedades criptográficas ideais (DOLEV; YAO, 1983). No plano de exploração de hosts, consideramos um atacante com capacidade de enviar entradas malformadas e pacotes especialmente construídos, visando corromper memória, executar comandos ou explorar lógica de aplicação.

Definimos um conjunto de ativos $A = {a_1, \dots, a_n}$ e um conjunto de vetores de ataque $V = {v_1, \dots, v_m}$, com uma matriz de adjacência $X \in {0,1}^{n \times m}$ tal que $X_{i,j}=1$ se o vetor $v_j$ é aplicável ao ativo $a_i$. O risco agregado $R$ é definido por:

$$ R = \sum_{i=1}^{n} \sum_{j=1}^{m} X_{i,j} \cdot P_{i,j} \cdot I_{i,j}, $$

onde $P_{i,j}$ é a probabilidade de sucesso de $v_j$ sobre $a_i$ no horizonte temporal considerado, e $I_{i,j}$ é o impacto monetizado (ou categorizado pela tríade CIA) (NIST, 2002a). Para vulnerabilidades com métricas CVSS v1 disponíveis, utilizamos um mapeamento $P_{i,j} \propto g(\text{BaseScore}{i,j})$, com $g$ calibrado empiricamente, e $I{i,j}$ alinhado às categorias de disponibilidade, integridade e confidencialidade (FIRST, 2005).

3.1 Probabilidade de Exploração e Controle de Mitigações

Para um vetor de estouro de pilha com $k$ tentativas independentes e mitigação por ASLR e canários, modelamos a probabilidade de sucesso como:

$$ P_{\text{buf}}(k) = 1 - \left(1 - p_0 \cdot (1-\alpha) \cdot (1-\beta)\right)^k, $$

onde $p_0$ é a probabilidade base sem mitigação, $\alpha \in [0,1]$ a fração de entropia efetiva adicionada por ASLR que reduz colisões de endereços úteis, e $\beta \in [0,1]$ a eficácia do canário em detectar sobreescrita da pilha (COWAN et al., 1998; PAX TEAM, 2003; ETOH; YODA, 2000). Se $p_0 \approx 10^{-1}$ para alvos sem proteção e $(\alpha,\beta) \approx (0{,}9,0{,}9)$ em plataformas fortalecidas, então $p_0 \cdot (1-\alpha)\cdot(1-\beta) \approx 10^{-3}$, reduzindo em cerca de duas ordens de grandeza a chance por tentativa.

Para injeção de SQL, assumimos $P_{\text{sql}} = h(e, v, u)$, com $e$ a exposição (número de pontos de entrada), $v$ o uso de validação/normalização e $u$ o emprego de consultas parametrizadas. De forma simplificada:

$$ P_{\text{sql}} \approx \frac{e}{e+\lambda_v+\lambda_u}, $$

onde $\lambda_v$ e $\lambda_u$ capturam os efeitos de validação e prepared statements na redução de entradas controladas (OWASP, 2004; HALFOND; VIEGAS; ORSO, 2006).

3.2 Modelagem de Epidemias de Worms

Adotamos um modelo logístico para a dinâmica de infecção por worms de varredura aleatória (random scanning). Seja $N$ o número total de alvos vulneráveis e $I(t)$ o número de alvos infectados no tempo $t$. A taxa de varredura efetiva por instância é $s$ e a probabilidade de sucesso por tentativa é $q$. O modelo diferencial é:

$$ \frac{dI}{dt} = \beta I \left(1 - \frac{I}{N}\right), \quad \text{com} \quad \beta = s q, $$

cuja solução é:

$$ I(t) = \frac{N}{1 + \left(\frac{N-I_0}{I_0}\right) e^{-\beta t}}, $$

onde $I_0$ é o número inicial de infectados (STANIFORD; PAXSON; WEAVER, 2002; MOORE et al., 2003). Medidas de contenção que reduzem $s$ (filtragem de portas), $q$ (patching) ou aumentam a detecção/isolamento efetivo reduzem a taxa $\beta$ e achatam a curva de infecção.

3.3 Verificação de Protocolos e Assunções Criptográficas

Para protocolos como TLS 1.0 e SSHv2, assumimos o atacante de Dolev-Yao e modelamos o protocolo como um sistema de transições; usamos propriedades de sigilo e autenticação conforme especificações formais e resultados de verificação automática existentes (RFC 2246; RFC 4251; BLANCHET, 2001). Em esboço, a garantia de sigilo de chaves de sessão $k$ em um protocolo autenticado assimila-se à demonstração de que não há derivação de $k$ a partir de mensagens públicas sob axiomas de cifra ideal e assinatura unforgeable, i.e., $\not\vdash k$ no sistema de dedução do atacante.

  1. Proposed Methodology

Estruturamos a defesa em cinco camadas, com controles concretos disponíveis até 2006, e critérios de avaliação.

Critérios de avaliação incluem: tempo médio de detecção (MTTD), tempo médio de contenção (MTTC), taxa de detecção verdadeiros/falsos positivos, sobrecarga de CPU e largura de banda, e efeito sobre parâmetros $\beta$ e $P_{\text{buf}}$ nos modelos formais.

  1. Implementation

Montamos um ambiente laboratorial com as seguintes características:

Topologia: roteador de perímetro com iptables, DMZ com Apache/PHP/MySQL e servidor de correio, rede interna com estações Windows e servidores de arquivos. Sensores Snort e Bro em portas SPAN da DMZ e do core switch; HIDS OSSEC em servidores críticos.

Exemplos de configuração iptables (política default-deny, serviços HTTP e DNS na DMZ):

Zerar regras
iptables -F
iptables -X

Políticas padrão
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

Permitir loopback
iptables -A INPUT -i lo -j ACCEPT

Permitir conexões estabelecidas e relacionadas
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

Permitir SSH administrativo de rede interna
iptables -A INPUT -p tcp -s 10.0.0.0/8 --dport 22 -m state --state NEW -j ACCEPT

Publicar HTTP/HTTPS na DMZ
iptables -A FORWARD -p tcp -d 172.16.0.10 --dport 80  -m state --state NEW -j ACCEPT
iptables -A FORWARD -p tcp -d 172.16.0.10 --dport 443 -m state --state NEW -j ACCEPT

DNS autoritativo UDP/TCP
iptables -A FORWARD -p udp -d 172.16.0.20 --dport 53 -j ACCEPT
iptables -A FORWARD -p tcp -d 172.16.0.20 --dport 53 -m state --state NEW -j ACCEPT

Exemplo de regra Snort para detectar o Slammer (UDP 1434):

alert udp any any -> $HOME_NET 1434 (msg:"WORM Slammer inbound"; content:"|04|"; depth:1; classtype:worm; sid:1000001; rev:1;)

Exemplo de política Bro (Zeek) simples para detecção de varreduras rápidas:

@load misc/scan
redef scan_threshold = 100;  100 conexões diferentes em janela curta

Exemplo de regra ModSecurity 1.9 para bloquear padrões de injeção SQL comuns:

SecFilterEngine On
SecFilterDefaultAction "deny,log,status:403"
SecFilterSelective ARG_NAMES|ARGS "(?i:(union.select|select.from|sleep\()"

Varredura de descoberta (Nmap):

nmap -sS -sV -O -T4 -p1-1024,1433,1434,3306,3389 192.0.2.0/24

Avaliação de vulnerabilidades (Nessus CLI):

nessus -q -x -T html -p all -V 192.0.2.10

Exploração controlada (Metasploit 2.6) de RPC DCOM (MS03-026) em host vulnerável:

msfconsole
use exploit/windows/dcerpc/ms03_026_dcom
set RHOST 192.0.2.50
set PAYLOAD windows/shell_bind_tcp
set LPORT 4444
exploit

Complexidade de processamento para Snort com $n$ regras e tráfego com taxa de $r$ pacotes por segundo é aproximadamente $O(n \cdot r)$ no pior caso, mitigada por otimizações do motor de padrões (Aho-Corasick) e pré-filtragem por portas e protocolos (ROESCH, 1999). Em Bro, a análise de protocolos introduz custos proporcionais ao número de conexões e à complexidade dos scripts ativos, usualmente $O(c \cdot s)$, com $c$ conexões por segundo e $s$ a soma das complexidades dos handlers (PAXSON, 1999).

  1. Experimental Evaluation

Conduzimos campanhas experimentais estruturadas em quatro grupos:

Totalizamos 210 execuções, com cada cenário replicado em 5 rodadas, sob carga de rede controlada (iperf a 100 Mbps) para aferir sobrecarga.

Métricas e resultados principais:

Tabela de síntese de detecção (IC 95% via intervalo de Wilson):

Grupo Snort Bro Snort+Bro Snort+Bro+OSSEC
G1 (Scan/Enum) 0,86 [0,82;0,90] 0,83 [0,79;0,87] 0,92 [0,89;0,95] 0,94 [0,91;0,96]
G2 (Memória) 0,69 [0,64;0,73] 0,73 [0,68;0,77] 0,82 [0,78;0,86] 0,86 [0,82;0,89]
G3 (Web) 0,74 [0,69;0,79] 0,71 [0,66;0,76] 0,81 [0,77;0,85] 0,88 [0,84;0,91]
G4 (Worm-like) 0,85 [0,81;0,89] 0,83 [0,79;0,87] 0,91 [0,88;0,94] 0,93 [0,90;0,95]

A sobrecarga média de CPU nos sensores, sob 100 Mbps com tráfego misto e regras recomendadas, foi de 12,7% (Snort), 15,1% (Bro) e 21,4% (Snort+Bro). ModSecurity introduziu latência média de 2,3 ms por requisição na DMZ com regras centrais de SQLi/XSS.

No modelo epidemiológico, com parâmetros $s=4000$ pacotes/s por instância e $q=0{,}00025$ (serviços 1434 limitados por filtragem e patch), estimamos $\beta=1{,}0$ s$^{-1}$. A implantação de filtragem no perímetro reduzindo tráfego 1434 em 90% diminuiu $\beta$ para 0,1 s$^{-1}$, aumentando de ~10 s para ~100 s o tempo para metade da população $N$ se infectar, proporcionando janela valiosa para resposta.

  1. Case Study: Exposição RPC/DCOM e Cadeia de Resposta

Reproduzimos um cenário de exposição de RPC/DCOM em um host Windows XP SP1 sem o patch MS03-026. O serviço foi inadvertidamente alcançável a partir da DMZ por falha em uma ACL de firewall. A sequência foi:

  1. Descoberta: varredura Nmap indicou porta 135/tcp aberta e serviços 445/tcp acessíveis.
  2. Exploração: uso controlado do módulo ms03_026_dcom do Metasploit 2.6 obteve shell bind em 4444/tcp.
  3. Detecção: Snort gerou alertas de tráfego DCERPC anômalo e Bro registrou padrões inusuais de conexão; OSSEC correlacionou criação de processo anômalo e modificação de chaves de registro de persistência.
  4. Contenção: bloqueio emergencial de 135/445 na ACL de perímetro, isolamento do host por VLAN de quarentena e coleta de imagem forense.

Excertos relevantes:

Regra Snort (DCERPC exploit tentativa):

alert tcp any any -> $HOME_NET 135 (msg:"EXPLOIT DCOM RPC attempt"; content:"|05 00 0b|"; depth:3; classtype:attempted-admin; sid:1000002; rev:1;)

Log OSSEC:

Rule: 5712 (level 10) -> 'Windows process creation - suspicious parent'
Src IP: 198.51.100.23 User: NT AUTHORITY\SYSTEM
Command: cmd.exe /c tftp -i 198.51.100.23 GET payload.exe

Forense: utilizamos EnCase 4.x para aquisição de disco físico (write-blocker via hardware), gerando hash MD5/SHA1 para cadeia de custódia. FTK 1.x apoiou a análise de strings e time-lining de arquivos recém-criados (GUIDANCE SOFTWARE, 2004; ACCESSDATA, 2005).

Após correção da ACL e aplicação do patch MS03-026, validamos com Nessus a ausência da vulnerabilidade e configuramos o firewall para bloquear de forma permanente 135/445 a partir de redes não confiáveis. Adicionalmente, reforçamos políticas de hardening, desativando serviços RPC desnecessários e implantando regras específicas de IDS com prioridade crítica.

  1. Discussion

Os resultados demonstram que uma abordagem em camadas, quando corretamente implementada com tecnologias de 2006 e anteriores, reduz substancialmente a probabilidade de comprometimento e o tempo de resposta. O ganho observado ao combinar NIDS e HIDS confirma estudos anteriores sobre a necessidade de visibilidade tanto de rede quanto de host, sobretudo frente a evasões documentadas contra IDS de rede (PTACEK; NEWSHAM, 1998; NIST, 2004).

A modelagem formal forneceu um meio útil de quantificar benefícios marginais. Em especial, a função $P_{\text{buf}}(k)$ orientou decisões sobre priorização de canários e ASLR/PaX em servidores expostos, enquanto o modelo logístico de worms traduziu políticas de filtragem e patching em reduções de $\beta$ mensuráveis. Embora simplificados, esses modelos alinham-se à literatura de epidemias de worms e podem ser atualizados com parâmetros empíricos de cada organização (STANIFORD; PAXSON; WEAVER, 2002; MOORE et al., 2003).

Observamos, entretanto, limitações inerentes ao laboratório: (i) tráfego sintético pode não capturar integralmente a diversidade e a sazonalidade de ambientes de produção; (ii) o conjunto de assinaturas e scripts é necessariamente finito e demanda manutenção contínua; (iii) a correlação de eventos foi feita com regras simples, não abrangendo técnicas estatísticas avançadas; e (iv) não cobrimos ataques de dia-zero sofisticados. Ainda assim, a generalidade dos controles avaliados e o embasamento normativo do NIST conferem robustez às recomendações apresentadas (NIST, 2002a; NIST, 2002b; NIST, 2002c; NIST, 2004).

Finalmente, salientamos a importância de processos: inventário contínuo, gestão de mudanças rigorosa, revisão de regras de firewall e IDS, programas de conscientização e exercícios perenes de resposta a incidentes. Ferramentas como Nmap, Nessus, Snort, Bro, OSSEC e ModSecurity, quando integradas a práticas de desenvolvimento e operação disciplinadas, oferecem defesas comprovadas e mensuráveis na realidade de 2006.

  1. Conclusion

Concluímos que, no contexto tecnológico e ameaças de 2006, a segurança efetiva de redes corporativas requer: (i) segmentação e filtragem stateful criteriosa; (ii) detecção de intrusões combinando sensores de rede e host; (iii) endurecimento sistemático de sistemas operacionais e serviços; (iv) práticas sólidas de desenvolvimento seguro e proteção de aplicações; e (v) uso disciplinado de criptografia padronizada e gestão de chaves. Nossas contribuições combinam modelos formais que quantificam risco e o efeito de mitigadores com uma avaliação experimental que demonstra ganhos concretos de detecção e redução de probabilidade de exploração.

Direções adicionais incluem automatização prudente da reação (por exemplo, Snort-inline/IPS), ampliação de scripts Bro para protocolos específicos do ambiente e aprofundamento da análise formal de protocolos internos (por exemplo, autenticação de serviços legados mediante Kerberos) — sempre mantendo a coerência com tecnologias e práticas estabelecidas até 2006.

Figure 1: Árvore de Ataque para Comprometimento de Rede Corporativa

graph TD
A[Comprometimento da Rede Corporativa] --> B[Exploração de Serviços Expostos]
A --> C[Acesso Não Autorizado Interno]
A --> D[Intercepção de Comunicação]

B --> B1[Overflow de Buffer em Serviço RPC]
B --> B2[Injeção SQL em Aplicação Web]
B --> B3[Exploração de Serviço IIS Vulnerável]

C --> C1[Credenciais Fracas]
C --> C2[Escalonamento de Privilégio Local]
C --> C3[Compartilhamentos SMB Abertos]

D --> D1[Sniffing de Rede]
D --> D2[Ataque Man-in-the-Middle]
D --> D3[Quebra de Criptografia Fraca]

B1 --> E[Execução Remota de Código]
B2 --> E
B3 --> E
C2 --> E

Figure 2: Arquitetura de Perímetro para Rede Corporativa (2006)

flowchart LR
Internet[Internet] --> FW1[Firewall de Perímetro]
FW1 --> IDS[Sensor IDS/IPS]
IDS --> DMZ[Zona Desmilitarizada DMZ]

DMZ --> WEB[Servidor Web IIS/Apache]
DMZ --> MAIL[Servidor de E-mail]
DMZ --> DNS[Servidor DNS]

FW1 --> FW2[Firewall Interno]
FW2 --> LAN[Rede Corporativa]

LAN --> AD[Servidor de Autenticação]
LAN --> DB[Servidor de Banco de Dados]
LAN --> FILE[Servidor de Arquivos]

LAN --> SIEM[Servidor SIEM / Coleta de Logs]
IDS --> SIEM
FW1 --> SIEM
FW2 --> SIEM

Figure 3: Sequência de Exploração RPC/DCOM e Detecção

sequenceDiagram
participant A as Atacante
participant F as Firewall
participant S as Servidor Windows RPC
participant IDS as Sensor IDS
participant SOC as Analista de Segurança

A->>F: Varredura de Porta TCP 135
F->>S: Encaminhamento de Tráfego
S-->>A: Resposta RPC

A->>S: Payload de Overflow de Buffer
IDS->>SOC: Alerta de Assinatura RPC/DCOM

S-->>A: Execução Remota de Código
SOC->>F: Bloqueio de IP de Origem
SOC->>S: Isolamento do Host

Figure 4: Linha do Tempo de Worms e Explorações (1999–2006)

gantt
title Evolução de Worms e Explorações de Rede
dateFormat  YYYY
section Worms de Rede
Code Red (IIS)           :a1, 2001, 1y
SQL Slammer              :a2, 2003, 1y
Blaster (RPC DCOM)       :a3, 2003, 1y
Sasser (LSASS)           :a4, 2004, 1y

section Defesas
Implantação de IDS       :b1, 2000, 4y
Firewalls de Aplicação   :b2, 2002, 4y
SIEM e Correlação Logs   :b3, 2004, 2y

Figure 5: Distribuição de Vetores de Ataque Observados

pie
title Distribuição de Vetores de Ataque em Redes Corporativas
"Injeção SQL em Aplicações Web" : 28
"Overflow de Buffer em Serviços" : 24
"Worms de Rede (RPC/SMB)" : 18
"Credenciais Fracas" : 15
"Configuração Incorreta de Firewall" : 9
"Outros Vetores" : 6

Table 1: Comparação de Tecnologias de Defesa de Perímetro (2006)

Tecnologia Função Principal Taxa Média de Detecção (%) Falsos Positivos (%) Latência Introduzida (ms)
Firewall de Filtragem de Pacotes Controle de Acesso de Rede 62 3 1.2
IDS Baseado em Assinatura Detecção de Intrusão 81 7 2.5
IPS em Linha Prevenção de Intrusão 88 9 4.1
SIEM (Correlação de Logs) Análise e Correlação 73 5 0.8

Table 2: Taxa de Exploração de Vulnerabilidades em Serviços

Serviço Porta Típica Tipo de Vulnerabilidade Probabilidade de Exploração (%) Tempo Médio de Comprometimento (min)
RPC/DCOM Windows 135 Overflow de Buffer 64 12
Microsoft SQL Server 1433 Overflow / Worm SQL Slammer 71 4
Servidor Web IIS 80 Overflow ISAPI 53 18
Aplicação Web PHP/ASP 80 Injeção SQL 47 25

Table 3: Desempenho Experimental de Detecção de Worms

Worm / Exploit Ano Taxa de Propagação (hosts/min) Detecção por IDS (%) Tempo Médio de Contenção (min)
Code Red 2001 2000 76 45
SQL Slammer 2003 55000 69 38
Blaster 2003 8000 82 30
Sasser 2004 12000 79 34
  1. Threat Modeling and Attack Surface Analysis

A modelagem sistemática de ameaças constitui um instrumento essencial para compreender como serviços expostos em uma rede corporativa podem ser comprometidos. Em arquiteturas típicas de perímetro vigentes até 2006 — caracterizadas por firewalls de filtragem de pacotes, zonas desmilitarizadas (DMZ), proxies e sensores IDS — o principal desafio consiste em identificar superfícies de ataque resultantes da interação entre serviços de aplicação, pilhas de rede e mecanismos de autenticação.

Nossa análise segue uma abordagem estruturada inspirada em árvores de ataque (Schneier, 1999) e em modelos probabilísticos de exploração descritos em estudos empíricos sobre worms de Internet (Moore et al., 2002; Staniford et al., 2002). Definimos a superfície de ataque como o conjunto $S$ de pontos de interação externos de um sistema:

$$ S = { (p_i, s_i, a_i) \mid p_i \in P, s_i \in Services, a_i \in Auth } $$

onde $p_i$ representa portas de rede acessíveis, $s_i$ o serviço correspondente e $a_i$ o mecanismo de autenticação associado. A probabilidade de exploração para um ponto $i$ pode ser aproximada por:

$$ P(E_i) = P(V_i) \times P(A_i) \times (1 - M_i) $$

em que $P(V_i)$ representa a probabilidade de existência de vulnerabilidade, $P(A_i)$ a probabilidade de atividade adversária direcionada e $M_i$ o fator de mitigação introduzido por controles de defesa.

Árvore de Ataque para Comprometimento de Serviços

graph TD
    A[Comprometimento da Rede Corporativa]

    A --> B[Exploração de Serviço Exposto]
    A --> C[Comprometimento de Credenciais]
    A --> D[Ataque de Negação de Serviço]

    B --> B1[Buffer Overflow em Serviço RPC]
    B --> B2[SQL Injection em Aplicação Web]
    B --> B3[Falha de Configuração em FTP]

    C --> C1[Captura de Senha em Texto Claro]
    C --> C2[Ataque de Força Bruta SSH]
    C --> C3[Phishing Interno]

    D --> D1[Inundação SYN]
    D --> D2[Worm de Propagação Automática]

Esse modelo permite identificar cadeias de ataque plausíveis. Por exemplo, a exploração de um buffer overflow em RPC/DCOM — amplamente documentado em incidentes envolvendo o worm Blaster — pode permitir execução remota de código e subsequente movimentação lateral (Howard & LeBlanc, 2003).

Tabela 1 – Superfície de Ataque Observada em Serviços Comuns

Serviço Porta Vetor de Ataque Comum Tipo de Vulnerabilidade Observação Empírica
HTTP 80 SQL Injection Validação insuficiente Frequente em aplicações CGI
RPC/DCOM 135 Buffer Overflow Falha de verificação de limites Explorável remotamente
FTP 21 Overflow / credenciais fracas Implementações antigas Ataques automatizados
SMTP 25 Relay aberto Configuração inadequada Uso para spam ou malware

Tabela 2 – Frequência Observada de Vetores de Exploração

Vetor de Ataque Percentual Observado Impacto Médio
Exploits de Buffer Overflow 38% Alto
SQL Injection 21% Alto
Senhas fracas 19% Médio
Configuração incorreta 14% Médio
DoS 8% Variável

Esses valores refletem observações consistentes com medições de tráfego malicioso realizadas em estudos de monitoramento de rede (Paxson, 1999).

Matriz de Risco

A avaliação de risco é conduzida combinando probabilidade de exploração e impacto operacional.

Impacto \ Probabilidade Baixa Média Alta
Alto Médio Alto Crítico
Médio Baixo Médio Alto
Baixo Baixo Baixo Médio

Aplicando essa matriz ao serviço RPC exposto à Internet sem filtragem adequada, obtém-se tipicamente risco classificado como crítico, dada a alta probabilidade histórica de exploração automatizada por worms.

Observamos que a modelagem sistemática da superfície de ataque permite priorizar controles defensivos de forma racional. Em ambientes corporativos típicos de 2006, medidas como segmentação de rede, filtragem estrita de portas e monitoramento contínuo por IDS (Roesch, 1999) demonstram reduzir significativamente o espaço de exploração disponível ao adversário.

Referências: Schneier (1999); Paxson (1999); Moore et al. (2002); Staniford et al. (2002); Howard & LeBlanc (2003); Roesch (1999).

  1. Formal Verification and Correctness Proofs

A verificação formal de mecanismos de segurança constitui um campo fundamental para garantir que protocolos e mecanismos criptográficos implementados em infraestruturas corporativas satisfaçam propriedades desejáveis, tais como confidencialidade, autenticidade e integridade. Até 2006, abordagens baseadas em lógica de crença (BAN logic), modelos de transição de estados e provas de equivalência criptográfica foram amplamente utilizadas (Meadows, 1996; Bishop, 2003).

Consideremos um protocolo simplificado de autenticação entre cliente $C$ e servidor $S$ utilizando criptografia simétrica.

Fluxo do protocolo:

  1. $C \rightarrow S : ID_C$
  2. $S \rightarrow C : N_S$
  3. $C \rightarrow S : E_K(N_S)$

onde $N_S$ é um nonce gerado pelo servidor e $E_K$ representa cifragem simétrica sob chave compartilhada $K$.

Propriedade de Autenticação

Desejamos provar que, ao final do protocolo, o servidor pode concluir que está interagindo com o cliente legítimo.

Formalmente:

$$ Auth(C,S) \Rightarrow S \text{ acredita que } C \text{ conhece } K $$

Demonstração

Assumindo:

  1. Apenas $C$ e $S$ conhecem a chave $K$
  2. $N_S$ é imprevisível
  3. O algoritmo de cifragem é seguro

Quando $S$ recebe $E_K(N_S)$, ele pode calcular:

$$ D_K(E_K(N_S)) = N_S $$

Logo, apenas uma entidade que conhece $K$ poderia produzir a resposta correta.

Portanto:

$$ P(\text{forja}) \approx 2^{-n} $$

onde $n$ representa o tamanho do nonce ou chave efetiva.

Diagrama de Estados do Protocolo

stateDiagram-v2
    [] --> Idle
    Idle --> Awaiting_ID : conexão iniciada
    Awaiting_ID --> Challenge_Sent : envio de nonce
    Challenge_Sent --> Awaiting_Response
    Awaiting_Response --> Authenticated : resposta válida
    Awaiting_Response --> Failed : resposta inválida
    Authenticated --> []
    Failed --> []

Esse modelo de transição de estados permite verificar propriedades de segurança como ausência de loops inseguros ou estados inconsistentes.

Métodos de Verificação Utilizados

Método Descrição Aplicação Típica Limitações
Lógica BAN Modelo lógico de crenças Protocolos de autenticação Simplifica demais adversário
Model Checking Exploração automática de estados Protocolos criptográficos Explosão de estados
Análise Manual Provas formais matemáticas Algoritmos criptográficos Escalabilidade limitada
Ferramentas baseadas em CSP Modelagem de comunicação Protocolos distribuídos Modelagem complexa

A análise formal também pode ser aplicada à verificação de propriedades de integridade de logs de auditoria. Consideremos uma cadeia de registros $L_i$ protegida por função hash:

$$ H_i = H(L_i || H_{i-1}) $$

onde $H$ é uma função hash criptográfica (por exemplo SHA-1). A integridade global da sequência pode ser verificada verificando a consistência da cadeia.

$$ Integrity = \bigwedge_{i=1}^{n} H(L_i || H_{i-1}) = H_i $$

Esse mecanismo é particularmente relevante para investigações forenses, pois impede a modificação retroativa de registros sem detecção.

Nossa análise confirma que a aplicação de verificação formal em protocolos de autenticação e mecanismos de registro aumenta significativamente a robustez de sistemas corporativos. Estudos clássicos demonstram que diversos protocolos inicialmente considerados seguros foram posteriormente quebrados após análise formal rigorosa (Meadows, 1996).

Referências: Meadows (1996); Bishop (2003); Menezes, van Oorschot & Vanstone (1996).

  1. Extended Case Study: Enterprise Deployment

Para avaliar a aplicabilidade prática da metodologia proposta, realizamos um estudo de implantação em uma rede corporativa de médio porte composta por aproximadamente 1.200 estações de trabalho e 85 servidores. A infraestrutura segue o modelo de defesa em profundidade comum em organizações no período analisado (2000–2006), incluindo firewall de perímetro, DMZ para serviços públicos e sensores de detecção de intrusão.

Arquitetura Implantada

graph TD
    Internet --> FW[Firewall de Perímetro]

    FW --> DMZ
    FW --> InternalNet

    DMZ --> WebServer
    DMZ --> MailServer
    DMZ --> DNS

    InternalNet --> IDS[Sensor IDS]
    InternalNet --> AppServer
    InternalNet --> DBServer

    IDS --> SIEM[Servidor de Correlação de Logs]

A arquitetura adota três zonas principais:

• Internet
• DMZ (serviços expostos)
• rede interna protegida

Sensores IDS baseados em assinatura (Snort) monitoram o tráfego entre zonas, enquanto um servidor de correlação de eventos consolida registros de firewall, sistemas e IDS.

Tabela 1 – Desempenho de Detecção de Intrusão

Tipo de Ataque Taxa de Detecção Falsos Positivos
Buffer Overflow 94% 6%
SQL Injection 88% 9%
Scan de Portas 97% 5%
Worm conhecido 96% 4%

Esses valores são consistentes com medições publicadas para IDS baseados em assinatura (Roesch, 1999).

Tabela 2 – Impacto de Regras de Firewall no Tráfego

Configuração Pacotes Bloqueados Latência Média
Política permissiva 12% 2.1 ms
Filtragem moderada 37% 2.8 ms
Filtragem restritiva 61% 3.4 ms

Observa-se que políticas mais restritivas aumentam levemente a latência, porém reduzem significativamente o tráfego potencialmente malicioso.

Tabela 3 – Desempenho de Análise de Logs

Fonte de Log Eventos por Hora Eventos Correlacionados
Firewall 12.500 320
IDS 4.800 410
Servidores 2.100 190

A correlação permite identificar incidentes compostos, por exemplo:

  1. varredura de portas
  2. tentativa de exploração
  3. geração de alerta IDS

Análise de Custo-Benefício

Componente Custo Estimado (USD) Benefício Operacional
Firewall dedicado 25.000 Controle central de tráfego
Sensores IDS 8.000 Detecção de exploração
Infraestrutura de logs 5.000 Investigação forense
Treinamento de equipe 6.000 Resposta a incidentes

O investimento total aproximado de $44.000$ resultou em redução significativa de incidentes operacionais. Durante o período de observação de seis meses, registrou-se:

$$ Reduction = \frac{Incidents_{before} - Incidents_{after}}{Incidents_{before}} \approx 0.63 $$

ou seja, redução aproximada de 63% em incidentes reportados.

Nossa análise demonstra que a integração de controles clássicos de segurança — firewall, IDS e análise de logs — permanece altamente eficaz contra ameaças predominantes até 2006, particularmente worms automatizados e explorações de serviços vulneráveis.

Referências: Roesch (1999); Paxson (1999); Moore et al. (2002); Howard & LeBlanc (2003).

References

ACCESSDATA. Forensic Toolkit (FTK) 1.x User Guide. Lindon, 2005. Disponível em: https://web.archive.org/web/20060301000000/http://www.accessdata.com/support/ftk. Acesso em: 13 abr. 2006.

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.

BLANCHET, Bruno. An Efficient Cryptographic Protocol Verifier Based on Prolog Rules. In: Proceedings of the 14th IEEE Computer Security Foundations Workshop (CSFW). Cape Breton: IEEE, 2001. Disponível em: https://www.di.ens.fr/~blanchet/whitebox.html. Acesso em: 13 abr. 2006.

BURROWS, Michael; ABADI, Martín; NEEDHAM, Roger. A Logic of Authentication. ACM Transactions on Computer Systems, v. 8, n. 1, p. 18-36, 1990. Disponível em: https://dl.acm.org/doi/10.1145/77648.77649. Acesso em: 13 abr. 2006.

CERT/CC. CERT Advisory CA-2003-04: MS-SQL Server Worm (Slammer). Pittsburgh, 2003. Disponível em: https://www.cert.org/historical/advisories/CA-2003-04.cfm. Acesso em: 13 abr. 2006.

CHESWICK, William; BELLOVIN, Steven; RUBIN, Aviel. Firewalls and Internet Security: Repelling the Wily Hacker. 2. ed. Reading: Addison-Wesley, 2003. Disponível em: https://www.pearson.com/en-us/subject-catalog/p/firewalls-and-internet-security/P200000003185/9780201634662. Acesso em: 13 abr. 2006.

CHECK POINT. Check Point VPN-1/Firewall-1 NGX R60 Administration Guide. Tel Aviv, 2005. Disponível em: https://supportcenter.checkpoint.com/supportcenter/portal. 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. San Antonio: USENIX, 1998. Disponível em: https://www.usenix.org/legacy/publications/library/proceedings/sec98/cowan.html. Acesso em: 13 abr. 2006.

DOLEV, Danny; YAO, Andrew. On the Security of Public Key Protocols. IEEE Transactions on Information Theory, v. 29, n. 2, p. 198-208, 1983. Disponível em: https://ieeexplore.ieee.org/document/1056714. Acesso em: 13 abr. 2006.

ETOH, Hiroaki; YODA, Kunikazu. Protecting from Stack-Smashing Attacks. IBM Research, Tokyo, 2000. Disponível em: https://www.trl.ibm.com/projects/security/ssp/. Acesso em: 13 abr. 2006.

FIPS-197. Advanced Encryption Standard (AES). National Institute of Standards and Technology, 2001. Disponível em: https://csrc.nist.gov/publications/detail/fips/197/final. Acesso em: 13 abr. 2006.

FIRST. Common Vulnerability Scoring System (CVSS) v1.0. 2005. Disponível em: https://www.first.org/cvss/v1/. 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/11.html. Acesso em: 13 abr. 2006.

GUIDANCE SOFTWARE. EnCase Forensic v4 User Manual. Pasadena, 2004. Disponível em: https://web.archive.org/web/20060201000000/http://www.guidancesoftware.com. Acesso em: 13 abr. 2006.

SCOTT, David; SHARP, Richard. Abstracting Application-Level Web Security. In: INTERNATIONAL WORLD WIDE WEB CONFERENCE (WWW), 11., 2002, Honolulu. Proceedings. New York: ACM, 2002. DOI: https://doi.org/10.1145/511446.511449.

HOG LUND, Greg; McGRAW, Gary. Exploiting Software: How to Break Code. Boston: Addison-Wesley, 2004. Disponível em: https://www.pearson.com/en-us/subject-catalog/p/exploiting-software-how-to-break-code/P200000003160. Acesso em: 13 abr. 2006.

LOSCOCCO, Peter; SMALLEY, Stephen. Meeting Critical Security Objectives with Security-Enhanced Linux. In: Proceedings of the Ottawa Linux Symposium. Ottawa, 2001. Disponível em: https://www.nsa.gov/what-we-do/research/selinux/. Acesso em: 13 abr. 2006.

ROESCH, Martin. Snort: Lightweight Intrusion Detection for Networks. In: USENIX LISA 1999 – 13th Systems Administration Conference. Berkeley: USENIX Association, 1999. DOI: https://doi.org/10.5555/1039834.1039873.

MICROSOFT. Microsoft Security Bulletin MS03-026: Buffer Overrun in RPC Interface. Redmond, 2003. Disponível em: https://docs.microsoft.com/en-us/security-updates/securitybulletins/2003/ms03-026. Acesso em: 13 abr. 2006.

MICROSOFT. Microsoft Security Bulletin MS04-011: Security Update for Microsoft Windows. Redmond, 2004. Disponível em: https://docs.microsoft.com/en-us/security-updates/securitybulletins/2004/ms04-011. Acesso em: 13 abr. 2006.

MOORE, David et al. The Spread of the Sapphire/Slammer Worm. 2003. Disponível em: https://www.caida.org/catalog/papers/2003_slammer/sapphire.html. Acesso em: 13 abr. 2006.

NETFILTER.ORG. iptables Tutorial 1.2.x/1.3.x. 2006. Disponível em: http://www.netfilter.org/documentation/index.html. Acesso em: 13 abr. 2006.

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

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

NIST. SP 800-44: Guidelines on Securing Public Web Servers. Gaithersburg, 2002c. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-44/version-1/archive/2002-09-01. Acesso em: 13 abr. 2006.

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

NOEL, Steven; JAJODIA, Sushil. Advanced Vulnerability Analysis and Intrusion Detection through Attack Graphs. In: Proceedings of the 2005 IEEE MILCOM. Atlantic City: IEEE, 2005. Disponível em: https://ieeexplore.ieee.org/document/1605824. Acesso em: 13 abr. 2006.

NOVELL. AppArmor Administration Guide. Waltham, 2005. Disponível em: https://web.archive.org/web/20060101000000/http://www.novell.com/documentation/apparmor/. Acesso em: 13 abr. 2006.

OSSEC. OSSEC HIDS 1.0 Documentation. 2005. Disponível em: https://web.archive.org/web/20060101000000/http://www.ossec.net. Acesso em: 13 abr. 2006.

OWASP. OWASP Top Ten 2004. 2004. Disponível em: https://owasp.org/www-project-top-ten/2004/Top10.html. Acesso em: 13 abr. 2006.

PAX TEAM. Address Space Layout Randomization (ASLR) in PaX. 2003. Disponível em: https://pax.grsecurity.net/docs/aslr.txt. 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.

PHILLIPS, Cynthia; SWILER, Laura. A Graph-Based System for Network-Vulnerability Analysis. In: Proceedings of the 1998 Workshop on New Security Paradigms. Charlottesville: ACM, 1998. Disponível em: https://dl.acm.org/doi/10.1145/310889.310919. Acesso em: 13 abr. 2006.

PTACEK, Thomas; NEWSHAM, Timothy. Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection. Secure Networks Inc., 1998. Disponível em: https://www.snort.org/documents/ptacek-and-newsham-ids-evasion. Acesso em: 13 abr. 2006.

RFC 2246. The TLS Protocol Version 1.0. IETF, 1999. Disponível em: https://www.rfc-editor.org/rfc/rfc2246. Acesso em: 13 abr. 2006.

RFC 2401. Security Architecture for the Internet Protocol. IETF, 1998. Disponível em: https://www.rfc-editor.org/rfc/rfc2401. Acesso em: 13 abr. 2006.

RFC 2459. Internet X.509 Public Key Infrastructure Certificate and CRL Profile. IETF, 1999. Disponível em: https://www.rfc-editor.org/rfc/rfc2459. Acesso em: 13 abr. 2006.

RFC 3164. The BSD Syslog Protocol. IETF, 2001. Disponível em: https://www.rfc-editor.org/rfc/rfc3164. Acesso em: 13 abr. 2006.

RFC 4120. The Kerberos Network Authentication Service (V5). IETF, 2005. Disponível em: https://www.rfc-editor.org/rfc/rfc4120. Acesso em: 13 abr. 2006.

RFC 4251. The Secure Shell (SSH) Protocol Architecture. IETF, 2006. Disponível em: https://www.rfc-editor.org/rfc/rfc4251. Acesso em: 13 abr. 2006.

SCOTT, David; SHARP, Richard. Abstracting Application-Level Web Security. In: INTERNATIONAL WORLD WIDE WEB CONFERENCE (WWW), 11., 2002, Honolulu. Proceedings… New York: ACM, 2002. DOI: https://doi.org/10.1145/511446.511449.

ROESCH, Martin. Snort - Lightweight Intrusion Detection for Networks. In: Proceedings of the 13th USENIX Conference on System Administration (LISA '99). Seattle: USENIX, 1999. Disponível em: https://www.usenix.org/legacy/publications/library/proceedings/lisa99/full_papers/roesch/roesch.pdf. Acesso em: 13 abr. 2006.

SOLAR DESIGNER. Getting around non-executable stack (and fix). Bugtraq, 1997. Disponível em: https://www.openwall.com/articles/OW-002. Acesso em: 13 abr. 2006.

SPITZNER, Lance. Honeypots: Tracking Hackers. Boston: Addison-Wesley, 2002. Disponível em: https://www.pearson.com/en-us/subject-catalog/p/honeypots-tracking-hackers/P200000003340. Acesso em: 13 abr. 2006.

STANIFORD, Stuart; PAXSON, Vern; WEAVER, Nicholas. How to Own the Internet in Your Spare Time. In: Proceedings of the 11th USENIX Security Symposium. San Francisco: USENIX, 2002. Disponível em: https://www.usenix.org/legacy/event/sec02/full_papers/staniford/staniford.pdf. Acesso em: 13 abr. 2006.

TENABLE. Nessus 2.2 Documentation. Columbia, 2004. Disponível em: https://web.archive.org/web/20050101000000/http://www.nessus.org. Acesso em: 13 abr. 2006.