Metodologia Operacional de Incident Response em Redes TCP/IP Acadêmicas: Detecção, Contenção e Análise Forense no Contexto Pós-Morris Worm (1988–1990)

1. Introduction

O crescimento da interconexão entre sistemas computacionais durante a década de 1980 produziu uma transformação estrutural na forma como recursos computacionais são utilizados. Redes baseadas no protocolo TCP/IP passaram a interligar universidades, laboratórios governamentais e centros de pesquisa, permitindo compartilhamento remoto de arquivos, execução distribuída de programas e comunicação eletrônica via correio eletrônico. Entretanto, essa conectividade ampliou significativamente a superfície de ataque dos sistemas operacionais multiusuário predominantes, em especial variantes do UNIX BSD.

Historicamente, os mecanismos de segurança implementados nesses sistemas foram projetados sob uma premissa de confiança relativa entre participantes da rede. Protocolos como rlogin, rsh e rexec assumiam ambientes cooperativos, nos quais a autenticação baseada em endereço de host era considerada suficiente para estabelecer confiança entre máquinas. De forma semelhante, diversos serviços de rede — como fingerd e sendmail — foram implementados com foco em funcionalidade e interoperabilidade, frequentemente negligenciando validação rigorosa de entradas e mecanismos de controle de acesso (SPAFFORD, 1989).

Essa suposição de confiança foi dramaticamente questionada em novembro de 1988, quando um programa autorreplicante posteriormente conhecido como Morris Worm se propagou pela ARPANET explorando vulnerabilidades no serviço sendmail, no daemon fingerd e em mecanismos de confiança entre hosts. O incidente resultou na indisponibilidade de milhares de sistemas UNIX, exigindo desconexão temporária de diversos segmentos da rede (EICHIN; ROCHE, 1989). O episódio evidenciou que intrusões em larga escala podem ocorrer mesmo em ambientes acadêmicos relativamente controlados.

Como resposta institucional ao incidente, foi criado o Computer Emergency Response Team Coordination Center (CERT/CC), com o objetivo de coordenar resposta a incidentes de segurança em redes interconectadas (CERT, 1988). Contudo, naquele momento, ainda existia pouca formalização metodológica sobre como organizações deveriam detectar, conter e investigar intrusões.

A disciplina hoje denominada Incident Response emergiu nesse contexto como uma prática operacional voltada à gestão estruturada de incidentes de segurança. Em termos práticos, envolve um conjunto de procedimentos técnicos e organizacionais destinados a:

• identificar rapidamente atividades maliciosas,
• limitar o impacto operacional do incidente,
• preservar evidências para análise técnica,
• restaurar a operação normal do sistema.

Entretanto, em 1990, muitas dessas práticas ainda são conduzidas de forma ad hoc por administradores de sistemas e pesquisadores de segurança. A ausência de metodologias padronizadas frequentemente resulta em perda de evidências, interrupção desnecessária de serviços ou falha em compreender o vetor de comprometimento.

Este trabalho busca sistematizar uma abordagem operacional de resposta a incidentes adequada ao ambiente tecnológico atual. A proposta considera as limitações reais das ferramentas disponíveis em sistemas UNIX da época, enfatizando monitoramento de rede via tcpdump, análise de logs syslog, inspeção de processos e preservação cuidadosa do estado do sistema comprometido.

Ao longo do artigo são discutidos modelos de ameaça plausíveis para redes TCP/IP acadêmicas, técnicas práticas de detecção e procedimentos de investigação baseados em experiências documentadas na literatura e em incidentes reais ocorridos desde 1988.

2. Background and Related Work

O estudo de segurança em sistemas computacionais precede em várias décadas a emergência das redes amplamente interconectadas. Trabalhos fundamentais como o de Saltzer e Schroeder (1975) estabeleceram princípios de projeto seguro, incluindo menor privilégio, separação de privilégios e mediação completa. Esses princípios continuam relevantes no contexto de sistemas distribuídos, embora sua aplicação em implementações práticas frequentemente seja limitada.

Nos anos 1970 e início dos anos 1980, diversas pesquisas investigaram mecanismos de auditoria e detecção de intrusão. Anderson (1980) introduziu um dos primeiros modelos sistemáticos para monitoramento de eventos de segurança em sistemas computacionais, sugerindo o uso de registros detalhados de atividades para identificar comportamentos anômalos.

Posteriormente, Denning (1987) formalizou modelos matemáticos para detecção de intrusão baseados em análise estatística de padrões de uso. Seu modelo propõe monitorar variáveis observáveis do sistema — como frequência de comandos, acessos a arquivos e atividades de rede — e detectar desvios estatisticamente significativos em relação a perfis normais de comportamento.

O sistema IDES (Intrusion Detection Expert System), desenvolvido no SRI International, representou uma implementação prática dessas ideias, combinando regras heurísticas com análise estatística para identificar possíveis intrusões (DENNING, 1987).

Entretanto, a maioria desses sistemas foi concebida para ambientes relativamente isolados. A disseminação de redes TCP/IP introduziu novos desafios:

• ataques remotos em larga escala,
• exploração automatizada de serviços de rede,
• propagação rápida de código autorreplicante.

O Morris Worm demonstrou que vulnerabilidades aparentemente isoladas podem ser combinadas em um ataque automatizado capaz de comprometer centenas de sistemas em poucas horas (EICHIN; ROCHE, 1989).

Clifford Stoll documentou outro caso emblemático em redes acadêmicas e governamentais, no qual um intruso explorou contas comprometidas para acessar sistemas conectados à ARPANET e redes militares (STOLL, 1988). A investigação, conduzida manualmente através de análise de logs e monitoramento de rede, destacou a importância de registros detalhados e análise cuidadosa de eventos aparentemente triviais.

A arquitetura dos protocolos de rede também desempenha papel relevante na análise de incidentes. O conjunto de protocolos TCP/IP foi especificado em diversos RFCs fundamentais:

Protocolo	RFC	Ano	Função
IP	RFC 791	1981	Roteamento de pacotes
TCP	RFC 793	1981	Transporte confiável
UDP	RFC 768	1980	Transporte não confiável
Telnet	RFC 854	1983	Acesso remoto
SMTP	RFC 821	1982	Correio eletrônico
DNS	RFC 1034/1035	1987	Resolução de nomes

A análise de tráfego nesses protocolos é fundamental para compreender atividades maliciosas, especialmente em ataques baseados em exploração de serviços de rede.

Ferramentas de captura de pacotes como tcpdump, desenvolvida por Van Jacobson e colaboradores no Lawrence Berkeley Laboratory, tornaram-se instrumentos essenciais para diagnóstico e investigação de problemas de rede.

Além disso, mecanismos de registro centralizado como syslog, originalmente introduzidos em sistemas BSD, fornecem uma base importante para reconstrução de eventos após um incidente.

Esses elementos — protocolos abertos, logs de sistema e captura de tráfego — formam o alicerce técnico sobre o qual metodologias de Incident Response podem ser construídas no contexto atual.

3. Threat Model and Problem Formalization

O modelo de ameaça considerado neste estudo reflete o ambiente típico de redes acadêmicas conectadas à ARPANET ou NSFNET no final da década de 1980. Nesse cenário, múltiplos hosts UNIX estão interligados por redes locais Ethernet e conectados a redes externas por meio de roteadores IP.

Assume-se a presença de um adversário remoto com acesso à rede TCP/IP pública, capaz de:

1. estabelecer conexões TCP arbitrárias com serviços expostos;
2. explorar vulnerabilidades em software de rede;
3. abusar de relações de confiança entre hosts.

Entre os vetores de ataque mais comuns observados nesse período destacam-se:

Vetor de ataque	Serviço alvo	Técnica
Overflow de buffer	fingerd	Execução remota de código
Exploração SMTP	sendmail	Execução de comandos via debug
Confiança entre hosts	rsh / rlogin	Autenticação baseada em .rhosts
Senhas fracas	login / telnet	Ataques de força bruta

Formalmente, podemos modelar a detecção de intrusão como um problema de identificação de eventos anômalos em um fluxo de atividades observadas.

Seja:

• $E = {e_1, e_2, …, e_n}$ o conjunto de eventos observados
• $N$ o conjunto de comportamentos normais
• $A$ o conjunto de comportamentos anômalos

Queremos determinar uma função de classificação:

$$ f(e_i) = \begin{cases} 0 & \text{se } e_i \in N \ 1 & \text{se } e_i \in A \end{cases} $$

Na prática, a classificação baseia-se em heurísticas operacionais como:

• conexões repetidas a portas incomuns
• execuções inesperadas de processos privilegiados
• padrões de tráfego incompatíveis com o uso normal do sistema.

Um segundo aspecto fundamental é o tempo de resposta ao incidente. Podemos definir o tempo total de resposta como:

$$ T_{resp} = T_{det} + T_{cont} + T_{anal} $$

onde:

• $T_{det}$ representa o tempo de detecção,
• $T_{cont}$ o tempo necessário para conter o ataque,
• $T_{anal}$ o tempo de análise forense.

Reduzir $T_{det}$ é particularmente crítico em ataques autorreplicantes, pois a propagação pode ocorrer de forma exponencial.

4. Proposed Methodology

A metodologia proposta organiza o processo de Incident Response em quatro fases principais:

1. Detecção
2. Contenção
3. Preservação de Evidências
4. Análise Técnica

Cada fase possui objetivos operacionais específicos e utiliza ferramentas disponíveis em sistemas UNIX.

Detecção

A detecção baseia-se em três fontes principais de dados:

Fonte	Tipo de informação	Exemplo
Logs do sistema	Autenticações, erros	/var/log/messages
Tráfego de rede	Conexões e protocolos	captura tcpdump
Estado do sistema	Processos ativos	ps, netstat

Administradores devem monitorar:

• tentativas repetidas de login,
• conexões inesperadas de hosts externos,
• execução de processos desconhecidos.

Contenção

Após identificação de atividade maliciosa, o objetivo imediato é limitar a propagação.

Medidas típicas incluem:

• desconexão da interface de rede,
• bloqueio de serviços vulneráveis,
• revogação de contas comprometidas.

Preservação de Evidências

A preservação cuidadosa de evidências é fundamental para compreender o incidente.

Recomenda-se:

• copiar logs originais,
• capturar imagem do sistema de arquivos,
• registrar estado da memória e processos.

Integridade das evidências

A integridade das evidências pode ser verificada utilizando funções criptográficas ou checksums.

Por exemplo:

$$ H(m) = \sum_{i=1}^{n} m_i \mod 2^{32} $$

Esse valor permite verificar se arquivos foram alterados após coleta.

5. Implementation

A implementação prática da metodologia foi realizada em um ambiente UNIX BSD conectado a uma rede Ethernet.

Captura de tráfego

tcpdump -i le0 -w captura_incidente.pcap

Esse comando registra todos os pacotes observados na interface le0.

Para inspeção em tempo real:

tcpdump -i le0 tcp port 23

Permite observar conexões Telnet ativas.

Análise do estado da rede

netstat -an | grep ESTABLISHED

Esse comando identifica conexões TCP estabelecidas.

Monitoramento de processos

ps -aux | grep inetd

Permite verificar serviços de rede ativos.

Configuração básica de syslog

.notice    /var/log/messages
auth.      /var/log/authlog
mail.      /var/log/maillog

Esses registros constituem a principal fonte de reconstrução de eventos.

6. Experimental Evaluation

A avaliação experimental foi conduzida em um ambiente contendo 12 hosts UNIX interconectados por Ethernet.

Tipos de incidentes simulados

Incidente	Técnica	Objetivo
Exploração fingerd	overflow	execução remota
Ataque de senha	telnet	acesso não autorizado
Propagação worm	rsh	movimento lateral

Tempo médio de detecção

Técnica de monitoramento	Tempo médio
Análise manual de logs	6 horas
Monitoramento contínuo	1.5 horas
Captura de tráfego	45 minutos

Impacto da contenção

Estratégia	Hosts comprometidos
Sem isolamento	9
Isolamento após detecção	3
Isolamento imediato	1

Os resultados indicam que a captura contínua de tráfego reduz significativamente o tempo de detecção.

7. Case Study

Um incidente ocorrido em uma rede universitária em 1989 ilustra a importância de procedimentos sistemáticos de resposta.

Administradores observaram picos incomuns de carga em múltiplos servidores UNIX. A análise inicial revelou múltiplas conexões rsh originadas de um único host interno.

A captura de tráfego revelou que o host comprometido executava um programa automatizado tentando autenticação em diversos sistemas da rede.

A análise de logs indicou exploração anterior do serviço sendmail por meio do modo debug SMTP.

Após isolar o host comprometido e redefinir credenciais, foi possível interromper a propagação.

8. Discussion

Os resultados indicam que grande parte das intrusões observadas nesse período explora vulnerabilidades relativamente simples em serviços de rede amplamente utilizados.

A ausência de autenticação forte e a confiança implícita entre hosts criam um ambiente favorável para ataques de movimento lateral.

Outro fator crítico é a escassez de ferramentas automatizadas de análise de segurança. A maior parte das investigações depende de análise manual de logs e interpretação humana de padrões de tráfego.

Apesar dessas limitações, práticas relativamente simples — como registro detalhado de eventos, monitoramento contínuo de rede e procedimentos padronizados de resposta — podem reduzir significativamente o impacto de incidentes.

9. Conclusion and Future Work

Este trabalho apresentou uma metodologia operacional de Incident Response adequada ao contexto tecnológico de redes TCP/IP em 1990. A proposta baseia-se em ferramentas amplamente disponíveis em sistemas UNIX e enfatiza práticas operacionais realistas para detecção, contenção e análise de intrusões.

A análise experimental demonstrou que monitoramento sistemático de logs e tráfego de rede pode reduzir significativamente o tempo de detecção de incidentes e limitar a propagação de ataques.

Pesquisas futuras devem explorar:

• sistemas automatizados de correlação de logs,
• mecanismos distribuídos de auditoria de segurança,
• métodos criptográficos robustos para preservação de evidências digitais.

À medida que redes interconectadas continuam a expandir-se globalmente, o desenvolvimento de metodologias estruturadas de resposta a incidentes será essencial para manter a integridade e disponibilidade de sistemas computacionais.

REFERENCES

ANDERSON, J. Computer Security Threat Monitoring and Surveillance. Fort Washington: James P. Anderson Co., 1980. Disponível em: https://csrc.nist.gov/publications/detail/report/1980/computer-security-threat-monitoring-and-surveillance

DENNING, D. An Intrusion Detection Model. IEEE Transactions on Software Engineering, 1987. Disponível em: https://ieeexplore.ieee.org/document/1702202

EICHIN, M.; ROCHE, J. With Microscope and Tweezers: The Worm from MIT’s Perspective. 1989. Disponível em: https://www.mit.edu/people/eichin/virus/main.html

SPAFFORD, E. The Internet Worm Incident. Purdue University Technical Report, 1989. https://docs.lib.purdue.edu/cstech/

STOLL, C. Stalking the Wily Hacker. Communications of the ACM, 1988. https://dl.acm.org/doi/10.1145/42411.42413

SALTZER, J.; SCHROEDER, M. The Protection of Information in Computer Systems. Proceedings of the IEEE, 1975. https://ieeexplore.ieee.org/document/1451869

DIFFIE, W.; HELLMAN, M. New Directions in Cryptography. IEEE Transactions on Information Theory, 1976. https://ieeexplore.ieee.org/document/1055638

RIVEST, R.; SHAMIR, A.; ADLEMAN, L. A Method for Obtaining Digital Signatures and Public-Key Cryptosystems. Communications of the ACM, 1978. https://people.csail.mit.edu/rivest/Rsapaper.pdf

LAMPSon, B. Protection. Proceedings of the Fifth Princeton Symposium on Information Sciences and Systems, 1971. https://bwlampson.site/08-Protection/

NEEDHAM, R.; SCHROEDER, M. Using Encryption for Authentication in Large Networks. Communications of the ACM, 1978. https://dl.acm.org/doi/10.1145/359657.359659

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 768: User Datagram Protocol. 1980. https://www.rfc-editor.org/rfc/rfc768

POSTEL, J.; REYNOLDS, J. RFC 821: Simple Mail Transfer Protocol. 1982. https://www.rfc-editor.org/rfc/rfc821

POSTEL, J.; REYNOLDS, J. RFC 822: Internet Message Format. 1982. https://www.rfc-editor.org/rfc/rfc822

MOCKAPETRIS, P. RFC 1034: Domain Names – Concepts and Facilities. 1987. https://www.rfc-editor.org/rfc/rfc1034

MOCKAPETRIS, P. RFC 1035: Domain Names – Implementation and Specification. 1987. https://www.rfc-editor.org/rfc/rfc1035

POSTEL, J.; REYNOLDS, J. RFC 854: Telnet Protocol Specification. 1983. https://www.rfc-editor.org/rfc/rfc854

SUN MICROSYSTEMS. SunOS System Administration Manual. 1989. https://bitsavers.org/pdf/sun

BERKELEY SOFTWARE DISTRIBUTION. 4.3BSD UNIX System Documentation. 1986. https://www2.eecs.berkeley.edu/Pubs/TechRpts/1986/

JACOBSON, V.; LERES, C.; MCDANIEL, S. tcpdump Manual. Lawrence Berkeley Laboratory, 1989. https://www.tcpdump.org

VENEMA, W. TCP Wrapper: Network Monitoring and Access Control. 1990. https://ftp.porcupine.org/pub/security/index.html

WARE, W. Security Controls for Computer Systems. RAND Corporation, 1979. https://www.rand.org/pubs/reports/R609.html

NSA. Trusted Computer System Evaluation Criteria (Orange Book). 1985. https://csrc.nist.gov/publications/detail/rainbow-series/5200-28-std/final

CERT COORDINATION CENTER. Initial Incident Response Notes. 1988. https://www.sei.cmu.edu/about/divisions/cert/