OpenCyber Academy
Engenharia · Capítulo 12 · Português
Código do curso: OCA-130Capítulo 12: OCA-130-C012

Capítulo 12 — Sistemas operacionais

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 12 publicada. Mapa, exemplo, EX034.

flowchart TD
  N0["12.1 O que um SO faz"]
  N1["12.2 Eventos do Windows"]
  N2["12.3 Logs do Linux"]
  N3["12.4 Usuários e privilégio"]
  N4["12.5 Serviços e tarefas agendadas"]
  N5["12.6 Configuração como cobertura"]
  N6["12.7 Tamanho e rotação dos logs"]
  N7["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX034"]

Desenho lógico

flowchart LR
  N0["12.1 O que um SO faz"]
  N1["12.2 Eventos do Windows"]
  N2["12.3 Logs do Linux"]
  N3["12.4 Usuários e privilégio"]
  N4["12.5 Serviços e tarefas agendadas"]
  N5["12.6 Configuração como cobertura"]
  N6["12.7 Tamanho e rotação dos logs"]
  N7["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX034"]

[12.1 O que um SO faz]
    |
    v
[12.2 Eventos do Windows]
    |
    v
[12.3 Logs do Linux]
    |
    v
[12.4 Usuários e privilégio]
    |
    v
[12.5 Serviços e tarefas agendadas]
    |
    v
[12.6 Configuração como cobertura]
    |
    v
[12.7 Tamanho e rotação dos logs]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX034]

Objetivos de aprendizagem

Você vai (1) explicar como os sistemas operacionais gerenciam processos, arquivos, usuários e logs; (2) localizar os principais eventos de segurança no Windows e no Linux; (3) relacionar as configurações de auditoria do SO à cobertura de detecção; (4) reconhecer como a configuração muda a telemetria.

12.1 O que um SO faz

O sistema operacional escalona processos, gerencia a memória, controla o acesso a arquivos e dispositivos e autentica usuários. Cada uma dessas funções pode produzir eventos de segurança se a auditoria estiver ativada. A auditoria transforma essas funções de bastidor em registros: um processo iniciando, um arquivo aberto, um usuário entrando. A maioria dos sistemas vem com apenas parte disso ativada, porque a auditoria completa produz grandes volumes e algum custo de desempenho. Escolher quais funções auditar é, portanto, uma decisão de projeto ligada às detecções que o SOC pretende executar.

12.2 Eventos do Windows

O Windows registra logons, criação de processos, instalação de serviços e mudanças de política em seus logs de eventos quando a política de auditoria os ativa. A criação de processos com linha de comando, por exemplo, precisa ser ligada de forma deliberada; sem ela, muitas detecções de endpoint não têm com o que casar. Uma instalação padrão pode registrar que um processo iniciou, mas não a linha de comando que recebeu, que é onde fica boa parte do detalhe útil. A Política de Grupo permite aos administradores ativar a auditoria de forma consistente em muitas máquinas. Amara verifica uma amostra de servidores do portal e descobre que a configuração de linha de comando não está aplicada de maneira uniforme, uma lacuna que sua tabela de cobertura depois atribui a um modelo de build mais antigo.

12.3 Logs do Linux

Os sistemas Linux registram a autenticação nos logs do sistema, e o subsistema de auditoria pode registrar acesso a arquivos e execução de programas conforme regras. Como no Windows, a cobertura depende da configuração. As mensagens de autenticação vão para arquivos como o log de autenticação do sistema ou para o journal do systemd, conforme a distribuição. O subsistema de auditoria usa regras que nomeiam o que observar, por exemplo a execução de qualquer programa por uma conta de serviço web. Cada regra acrescenta volume, então as regras são escritas para riscos específicos, em vez de registrar tudo o que o sistema faz.

12.4 Usuários e privilégio

Os sistemas operacionais separam usuários comuns de administradores. Eventos que mudam privilégio — acrescentar um usuário a um grupo de administradores, por exemplo — são sinais de alto valor para a detecção. Atacantes que conseguem um ponto de apoio geralmente querem mais direitos, então mudanças de pertencimento a grupos costumam aparecer cedo numa intrusão. Essas mudanças também são raras na operação normal, o que as torna boas candidatas à detecção, com poucos falsos positivos. Mudanças legítimas ainda acontecem, por isso os alertas são conferidos contra o registro da gestão de mudanças em busca de um pedido aprovado. As remoções de grupos privilegiados também são registradas.

12.5 Serviços e tarefas agendadas

Programas podem ser configurados para iniciar automaticamente. Novos serviços e tarefas agendadas são mecanismos comuns de persistência descritos no MITRE ATT&CK, por isso vale a pena registrar sua criação. A persistência permite que o programa de um atacante sobreviva a uma reinicialização ou ao logout de um usuário. Softwares legítimos também instalam serviços, sobretudo durante atualizações, então um alerta bruto a cada novo serviço seria ruidoso. As detecções estreitam o foco, por exemplo a serviços que rodam a partir de pastas graváveis pelo usuário ou a tarefas criadas por processos pais incomuns, e os analistas comparam com as implantações de software conhecidas.

12.6 Configuração como cobertura

A cobertura de detecção só é tão boa quanto a configuração de auditoria. Amara monta uma tabela que lista cada regra de detecção e a configuração do SO de que ela depende, e depois verifica se as configurações estão implantadas por política em todas as classes de servidor. A tabela revela lacunas que só os testes das regras não pegariam: uma regra pode passar nos testes em laboratório e mesmo assim nunca disparar em produção, porque o evento de que precisa não é gerado ali. A verificação de Amara descobre que uma classe de servidor registra a criação de processos sem a linha de comando. Corrigir a política restaura de uma vez a cobertura de várias regras, e a tabela é conferida de novo após cada mudança de build.

12.7 Tamanho e rotação dos logs

Os logs de eventos têm tamanho máximo; quando cheios, os eventos antigos são sobrescritos. Encaminhar os logs ao SIEM sem demora evita a perda. Num servidor ocupado, um log de eventos pequeno pode dar a volta em horas, de modo que a evidência de um ataque pela manhã pode ter sumido à tarde. Os atacantes às vezes geram ruído de propósito para empurrar as entradas mais antigas para fora. Encaminhar os eventos ao SIEM em segundos mantém uma cópia fora do host, e alertas sobre lacunas no encaminhamento mostram quando um servidor para de enviar. As configurações de tamanho dos logs fazem parte do padrão de build.

Exemplo resolvido

A tabela de Amara revela que os servidores web do portal não têm registro da linha de comando na criação de processos porque foram construídos a partir de um modelo mais antigo. Três regras de detecção, portanto, nunca poderiam disparar nesses servidores. Paolo abre uma mudança para atualizar o modelo e verifica depois com um processo de teste inofensivo.

Caso sintético. Os servidores, os modelos e as regras são inventados.

Erros e limites

Ativar mais auditoria aumenta o volume e o custo; ative o que as detecções e as investigações precisam.

Exercícios

Síntese

Os sistemas operacionais só produzem eventos de segurança ricos quando configurados para isso; mapear as regras às configurações revela pontos cegos.

Continue estudando — capítulo 12 de 50

← Capítulo 11 (rascunho) · Índice de capítulos do curso · Capítulo 13 (rascunho) →

Respostas comentadas

EX034. Porque a configuração de auditoria de que a regra depende, como o registro da linha de comando dos processos, não está ativada ali.

EX035. Concedem mais privilégio, que é o que os atacantes buscam, então as mudanças merecem atenção.

EX036. O modelo do servidor foi atualizado por meio de uma mudança, e um processo de teste inofensivo confirmou que as linhas de comando passaram a ser registradas.