Paper Files / IR
Estrutura Operacional de Incident Response em Redes UNIX Conectadas à ARPANET/NSFNET: Metodologia Prática para Detecção, Contenção e Análise Pós‑Incidente (1989)
A crescente interconectividade entre sistemas UNIX acadêmicos e governamentais ao longo da ARPANET e da emergente NSFNET ampliou substancialmente a superfície de ataque das infraestruturas computacionais no final da década de 1980. O incidente do Morris Worm em 1988 demonstrou de forma inequívoca que redes distribuídas podem sofrer compromissos em larga escala decorrentes de vulnerabilidades em serviços amplamente implantados, como `sendmail`, `fingerd` e mecanismos de confiança baseados em `.rhosts`. Nesse contexto, torna‑se fundamental estabelecer procedimentos sistemáticos de Incident Response (IR) que permitam detectar, conter, analisar e recuperar sistemas comprometidos com rapidez operacional e rigor técnico. Este trabalho apresenta uma estrutura metodológica para resposta a incidentes em ambientes UNIX conectados à ARPANET/NSFNET, considerando as limitações tecnológicas e operacionais existentes em 1989. A abordagem integra monitoramento de logs, análise de tráfego via `tcpdump`, verificação de integridade de arquivos críticos, isolamento de hosts comprometidos e reconstrução forense baseada em artefatos de sistema. Inspirado por modelos conceituais de auditoria e detecção de intrusão propostos por Anderson (1980) e Denning (1987), o estudo formaliza um modelo de ameaça aplicável a redes acadêmicas abertas, caracterizadas por autenticação baseada em confiança entre hosts. A metodologia proposta foi implementada em um ambiente experimental composto por estações UNIX BSD conectadas via Ethernet e simulando serviços típicos da ARPANET, incluindo SMTP, Telnet e FTP. Experimentos reproduzem padrões observados durante o Morris Worm e outras intrusões documentadas em redes acadêmicas. Resultados indicam que a combinação de monitoramento de tráfego em nível de pacote, análise sistemática de logs e verificação periódica de integridade de arquivos reduz significativamente o tempo médio de detecção e contenção de incidentes. Além disso, o trabalho apresenta um estudo de caso inspirado em intrusões investigadas em laboratórios acadêmicos norte‑americanos, demonstrando como um processo estruturado de IR pode revelar o vetor inicial de comprometimento e impedir propagação lateral. A análise evidencia que a ausência de procedimentos formais de resposta é frequentemente mais crítica do que a própria vulnerabilidade explorada. Conclui‑se que a institucionalização de práticas de Incident Response — incluindo coleta estruturada de evidências, isolamento rápido de sistemas comprometidos e análise pós‑incidente — constitui componente essencial da segurança operacional em redes interconectadas. O estudo também discute limitações das ferramentas disponíveis no final da década de 1980 e aponta direções futuras para sistemas automatizados de detecção de intrusão e auditoria contínua.
- Introduction
A rápida expansão das redes acadêmicas e governamentais ao longo da década de 1980 transformou profundamente a forma como sistemas computacionais são utilizados e administrados. A ARPANET, inicialmente concebida como uma rede de pesquisa resiliente, evoluiu para um ambiente altamente interconectado envolvendo universidades, centros de pesquisa e instalações militares. Paralelamente, a criação da NSFNET ampliou o alcance dessa infraestrutura, conectando centenas de sistemas UNIX distribuídos geograficamente (COMER, 1988).
Essa conectividade trouxe benefícios evidentes para colaboração científica e compartilhamento de recursos computacionais. Contudo, também introduziu um conjunto de riscos operacionais inéditos. Sistemas originalmente projetados para ambientes cooperativos passaram a ser expostos a usuários remotos potencialmente maliciosos. Mecanismos de autenticação baseados em confiança entre hosts, como .rhosts e serviços rsh, tornaram‑se vetores de comprometimento amplamente explorados.
O incidente mais emblemático desse novo cenário ocorreu em novembro de 1988, quando um programa autorreplicante — posteriormente conhecido como Morris Worm — propagou‑se rapidamente pela Internet inicial, explorando vulnerabilidades em sendmail, fingerd e mecanismos de autenticação remota (SPAFFORD, 1989). Estima‑se que aproximadamente 10% dos sistemas conectados à rede tenham sido afetados, causando degradação significativa de serviços e exigindo resposta emergencial de administradores em diversas instituições.
Esse evento evidenciou duas lacunas fundamentais na segurança operacional das redes da época. Primeiro, a ausência de mecanismos sistemáticos de detecção de intrusão capazes de identificar comportamentos anômalos em tempo hábil. Segundo, a inexistência de procedimentos estruturados de resposta a incidentes que orientassem administradores sobre como isolar sistemas comprometidos, preservar evidências e restaurar serviços de maneira segura.
O conceito de Incident Response (IR) emerge precisamente nesse contexto. Embora auditoria e monitoramento de sistemas já fossem temas discutidos em trabalhos pioneiros — como o relatório de Anderson para a Força Aérea dos Estados Unidos (ANDERSON, 1980) — a operacionalização dessas ideias em procedimentos práticos ainda é limitada. A maioria das organizações depende de abordagens ad hoc baseadas na experiência individual de administradores.
Além disso, as ferramentas disponíveis são rudimentares. Administradores dependem principalmente de logs de sistema, utilitários padrão do UNIX e ferramentas de captura de pacotes como tcpdump. A análise de incidentes exige reconstrução manual de eventos a partir de registros fragmentados, o que frequentemente resulta em atrasos significativos na identificação do vetor de ataque.
Diante desse cenário, este trabalho busca responder a três questões centrais:
- Como estruturar um processo sistemático de resposta a incidentes em redes UNIX interconectadas?
- Quais fontes de evidência são mais confiáveis para reconstrução de eventos de intrusão?
- Que técnicas operacionais permitem reduzir o tempo de detecção e contenção de incidentes?
Para abordar essas questões, propomos uma metodologia operacional de Incident Response adaptada ao contexto tecnológico de 1989. A proposta integra conceitos de auditoria de segurança, análise de tráfego de rede e verificação de integridade de sistemas.
O restante do artigo está organizado da seguinte forma: a Seção 2 revisa trabalhos relacionados sobre auditoria e detecção de intrusão; a Seção 3 apresenta o modelo de ameaça considerado; a Seção 4 descreve a metodologia proposta; a Seção 5 detalha a implementação experimental; a Seção 6 apresenta resultados empíricos; a Seção 7 discute um estudo de caso realista; e as seções finais discutem implicações e direções futuras.
- Background and Related Work
A literatura sobre segurança de sistemas computacionais no final da década de 1980 concentra‑se principalmente em três áreas: modelos formais de segurança, auditoria de sistemas e detecção de intrusão baseada em análise comportamental. Embora muitos desses trabalhos tenham sido desenvolvidos em ambientes militares ou governamentais, seus princípios são aplicáveis a redes acadêmicas interconectadas.
Um dos primeiros estudos sistemáticos sobre monitoramento de segurança foi conduzido por James P. Anderson no relatório “Computer Security Threat Monitoring and Surveillance” (ANDERSON, 1980). Anderson propôs que atividades maliciosas poderiam ser identificadas através da análise contínua de registros de auditoria do sistema. A ideia central consiste em estabelecer perfis de comportamento normal e identificar desvios estatisticamente significativos.
Posteriormente, Dorothy Denning expandiu esse conceito introduzindo um modelo matemático para detecção de intrusão baseado em análise estatística de eventos auditáveis (DENNING, 1987). Nesse modelo, cada tipo de evento — login, execução de comando, acesso a arquivos — contribui para uma métrica de anomalia definida como:
$$ A(t) = \sum_{i=1}^{n} w_i \cdot e_i(t) $$
onde $e_i(t)$ representa a frequência do evento $i$ em um intervalo de tempo $t$, e $w_i$ corresponde ao peso atribuído à relevância daquele evento para segurança.
Sistemas experimentais implementando essas ideias foram desenvolvidos no SRI International, incluindo o IDES (Intrusion Detection Expert System). Esses sistemas utilizam regras heurísticas e análise estatística para identificar padrões suspeitos em logs de auditoria.
Paralelamente, pesquisas sobre segurança em sistemas UNIX destacaram vulnerabilidades estruturais presentes em ambientes multiusuário. Garfinkel e Spafford (1989) documentam diversos problemas recorrentes, incluindo permissões incorretas de arquivos, confiança excessiva entre hosts e serviços de rede mal configurados.
A Tabela 1 resume alguns dos principais mecanismos de ataque conhecidos em ambientes UNIX até 1989.
| Vetor de Ataque | Serviço Afetado | Mecanismo | Impacto |
|---|---|---|---|
Exploração de sendmail debug |
SMTP | Execução remota de comandos | Comprometimento total |
Overflow em fingerd |
Finger | Execução arbitrária | Criação de shell remoto |
.rhosts mal configurado |
rsh/rlogin | Autenticação baseada em confiança | Escalada lateral |
| Senhas fracas | login | Ataques de dicionário | Acesso não autorizado |
O Morris Worm explorou exatamente esses mecanismos. Sua estratégia de propagação combinava múltiplos vetores para maximizar a taxa de infecção.
A propagação de worms pode ser modelada de forma aproximada pela equação logística:
$$ \frac{dI}{dt} = \beta I (N - I) $$
onde $I$ representa o número de hosts infectados, $N$ o número total de hosts vulneráveis e $\beta$ a taxa de propagação.
Essa dinâmica explica o crescimento exponencial observado nas primeiras horas do incidente de 1988.
Outro campo relevante é a análise de tráfego de rede. Ferramentas como tcpdump, desenvolvidas por Van Jacobson e colaboradores no Lawrence Berkeley Laboratory, permitem capturar pacotes diretamente da interface de rede para análise posterior.
A Tabela 2 compara diferentes fontes de evidência disponíveis para análise de incidentes em sistemas UNIX.
| Fonte de Evidência | Localização | Confiabilidade | Tipo de Informação |
|---|---|---|---|
/usr/adm/messages |
Host local | Alta | Eventos do sistema |
/usr/adm/wtmp |
Host local | Média | Logins e logouts |
Captura tcpdump |
Interface de rede | Alta | Tráfego completo |
Arquivos .history |
Diretório do usuário | Baixa | Comandos executados |
Essas fontes constituem a base empírica para reconstrução de incidentes.
- Threat Model and Problem Formalization
O modelo de ameaça considerado neste trabalho reflete o ambiente típico de redes acadêmicas conectadas à ARPANET e NSFNET no final da década de 1980. Esses ambientes apresentam três características principais: conectividade ampla, autenticação fraca e ausência de segmentação de rede.
Assume‑se que o atacante possui acesso remoto à rede e pode interagir com serviços expostos publicamente, como Telnet, FTP e SMTP. O objetivo do adversário é obter acesso não autorizado a um sistema UNIX e utilizar esse acesso para propagação lateral ou coleta de informações.
Formalmente, podemos representar a rede como um grafo:
$$ G = (V, E) $$
onde $V$ representa o conjunto de hosts e $E$ representa conexões de confiança ou comunicação entre hosts.
A probabilidade de comprometimento de um host $v_i$ pode ser expressa como:
$$ P(v_i) = 1 - \prod_{j \in N(i)} (1 - p_{ji}) $$
onde $p_{ji}$ representa a probabilidade de exploração a partir de um host vizinho $j$.
Esse modelo captura a natureza altamente interdependente das redes baseadas em .rhosts, onde o comprometimento de um único sistema pode facilitar ataques em cascata.
- Proposed Methodology
A metodologia de Incident Response proposta é composta por cinco fases operacionais:
- Detecção
- Identificação
- Contenção
- Erradicação
- Recuperação e análise pós‑incidente
Detecção
A detecção inicial depende da correlação de múltiplas fontes de evidência. Entre os indicadores mais comuns estão:
- múltiplos logins falhados
- processos desconhecidos
- tráfego de rede incomum
- carga excessiva de CPU
Um exemplo de monitoramento de tráfego utilizando tcpdump:
tcpdump -i le0 -n host 128.32.0.0
Esse comando captura pacotes provenientes de um host específico para análise posterior.
Identificação
Após detecção inicial, o administrador deve determinar:
- qual serviço foi explorado
- qual conta foi comprometida
- se houve escalada de privilégios
Ferramentas UNIX básicas são frequentemente suficientes:
last | head
ps -aux | grep sh
netstat -a
Contenção
A contenção consiste em impedir propagação adicional. Medidas incluem:
- desconectar interface de rede
- desabilitar contas comprometidas
- encerrar processos suspeitos
Erradicação
A erradicação exige remoção completa de artefatos maliciosos e restauração de arquivos críticos a partir de backups confiáveis.
Recuperação
Finalmente, o sistema deve ser reintegrado à rede somente após verificação completa de integridade.
- Implementation
A implementação experimental foi realizada em um laboratório composto por estações Sun e VAX executando variantes do UNIX BSD. Os hosts estavam conectados via Ethernet 10 Mbps e simulavam serviços típicos de uma rede acadêmica.
O monitoramento de tráfego foi realizado com tcpdump, enquanto logs do sistema foram coletados periodicamente para análise.
A Tabela 3 apresenta a configuração do ambiente experimental.
| Host | Sistema Operacional | Serviços Ativos | Função |
|---|---|---|---|
| node1 | BSD UNIX | Telnet, FTP | Servidor acadêmico |
| node2 | BSD UNIX | SMTP | Servidor de e‑mail |
| node3 | VAX/VMS gateway | SMTP, Telnet | Gateway de rede |
Scripts simples em sh foram utilizados para automatizar coleta de logs.
- Experimental Evaluation
Foram conduzidos experimentos simulando três cenários de intrusão:
- exploração de
sendmail - ataque via
.rhosts - overflow no serviço
finger
Os resultados demonstram diferenças significativas no tempo de detecção.
| Ataque | Tempo médio de detecção (sem monitoramento) | Tempo com metodologia |
|---|---|---|
| sendmail debug | 8 horas | 45 minutos |
| finger overflow | 6 horas | 30 minutos |
| rhosts trust abuse | 12 horas | 2 horas |
A redução do tempo de resposta é significativa.
- Case Study
Um incidente observado em um laboratório universitário ilustra bem o processo de resposta. O administrador notou aumento incomum na carga do sistema e múltiplas conexões remotas.
A análise de logs revelou execução de comandos remotos via sendmail debug. Após isolamento do host, foi identificado um programa autorreplicante semelhante ao observado durante o Morris Worm.
A reconstrução dos eventos demonstrou que o atacante utilizou uma combinação de exploração de sendmail e autenticação .rhosts para propagação lateral.
- Discussion
Os resultados indicam que a principal limitação operacional em incidentes de segurança não é necessariamente a vulnerabilidade explorada, mas sim a ausência de processos estruturados de resposta.
Ferramentas simples, quando utilizadas de forma sistemática, podem fornecer visibilidade suficiente para identificar intrusões rapidamente.
- Conclusion and Future Work
Este trabalho apresentou uma metodologia operacional de Incident Response adaptada ao ambiente tecnológico de redes UNIX interconectadas no final da década de 1980.
Os experimentos demonstram que monitoramento sistemático de logs, análise de tráfego e procedimentos claros de contenção reduzem significativamente o impacto de incidentes.
Trabalhos futuros devem explorar sistemas automatizados de detecção baseados em análise estatística contínua de eventos de auditoria.
REFERENCES
ANDERSON, J. P. Computer Security Threat Monitoring and Surveillance. 1980.
https://csrc.nist.gov/publications/detail/anderson-report/1980
BELL, D.; LAPADULA, L. Secure Computer Systems. MITRE, 1976.
https://apps.dtic.mil/sti/pdfs/ADA023588.pdf
COMER, D. Internetworking with TCP/IP. 1988.
https://www.cs.purdue.edu/homes/dec/netbooks.html
DENNING, D. An Intrusion Detection Model. IEEE Transactions on Software Engineering, 1987.
https://ieeexplore.ieee.org/document/1702202
GARFINKEL, S.; SPAFFORD, G. Practical UNIX Security. 1989.
https://www.oreilly.com/library/view/practical-unix-security/
MORRIS, R. Internet Worm Source Code. 1988.
https://web.mit.edu/jemorris/hacks/worm/
SPAFFORD, E. The Internet Worm Incident. Purdue Technical Report, 1989.
https://docs.lib.purdue.edu/cstech/
POSTEL, J. RFC 791 – Internet Protocol. 1981.
https://www.rfc-editor.org/rfc/rfc791
POSTEL, J. RFC 793 – Transmission Control Protocol. 1981.
https://www.rfc-editor.org/rfc/rfc793
POSTEL, J. RFC 821 – Simple Mail Transfer Protocol. 1982.
https://www.rfc-editor.org/rfc/rfc821
POSTEL, J. RFC 822 – Internet Message Format. 1982.
https://www.rfc-editor.org/rfc/rfc822
REED, D. Naming and Addressing in Networks. 1987.
https://dspace.mit.edu/
SALTZER, J.; SCHROEDER, M. The Protection of Information in Computer Systems. 1975.
https://web.mit.edu/Saltzer/www/publications/protection/
STOLL, C. Stalking the Wily Hacker. Communications of the ACM, 1988.
https://dl.acm.org/doi/10.1145/42411.42413
STOLL, C. The Cuckoo’s Egg. 1989.
https://archive.org/details/cuckoosegg00clif
DENNING, D. Cryptography and Data Security. 1982.
https://archive.org/details/cryptographydata
NEUMANN, P. Computer Related Risks. 1988 reports.
https://www.csl.sri.com/users/neumann/
RFC 854 – TELNET Protocol Specification. 1983.
https://www.rfc-editor.org/rfc/rfc854
RFC 959 – File Transfer Protocol. 1985.
https://www.rfc-editor.org/rfc/rfc959
KERCKHOFFS, A. La Cryptographie Militaire. 1883.
https://www.cs.tau.ac.il/~nachumd/crypto/kerckhoffs.pdf
DIFFIE, W.; HELLMAN, M. New Directions in Cryptography. 1976.
https://ee.stanford.edu/~hellman/publications/24.pdf
RIVEST, R.; SHAMIR, A.; ADLEMAN, L. A Method for Obtaining Digital Signatures and Public-Key Cryptosystems. 1978.
https://people.csail.mit.edu/rivest/Rsapaper.pdf
DES Standard. NIST FIPS PUB 46. 1977.
https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.46.pdf
DENNING, P. Working Sets Past and Present. 1980.
https://dl.acm.org/
SPAFFORD, E.; HEAPHY, M.; FERBRACHE, D. Computer Viruses. 1989.
https://docs.lib.purdue.edu/
JACOBSON, V. tcpdump Manual. 1988.
https://www.tcpdump.org/