Capítulo 11 — Sistemas operacionais
Mapa da aula
Aula 11 publicada. Mapa, exemplo, EX031.
flowchart TD
N0["11.1 Superfícies"]
N1["11.2 Jump hosts"]
N2["11.3 Imagens"]
N3["11.4 Logs"]
N4["11.5 Privilégios"]
N5["11.6 Baselines de endurecimento"]
N6["11.7 Fixar versões no pipeline de imagens"]
N7["11.8 Censo de administradores locais"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX031"]
Desenho lógico
flowchart LR
N0["11.1 Superfícies"]
N1["11.2 Jump hosts"]
N2["11.3 Imagens"]
N3["11.4 Logs"]
N4["11.5 Privilégios"]
N5["11.6 Baselines de endurecimento"]
N6["11.7 Fixar versões no pipeline de imagens"]
N7["11.8 Censo de administradores locais"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]
[11.1 Superfícies]
|
v
[11.2 Jump hosts]
|
v
[11.3 Imagens]
|
v
[11.4 Logs]
|
v
[11.5 Privilégios]
|
v
[11.6 Baselines de endurecimento]
|
v
[11.7 Fixar versões no pipeline de imagens]
|
v
[11.8 Censo de administradores locais]
|
v
[Exemplo resolvido] --> [Exercício EX031]
Objetivos de aprendizagem
Você vai (1) comparar superfícies administrativas; (2) exigir jump hosts; (3) tratar imagens como parte do escopo quando acordado.
11.1 Superfícies
Níveis de correção, administradores locais e serviços remotos diferem entre Windows e Linux. Os achados nomeiam o sistema operacional e o controle que falhou. Num servidor Windows, as superfícies habituais são atualizações cumulativas ausentes, membros do grupo local Administrators e serviços remotos como RDP, SMB e WinRM. No Linux, são pacotes desatualizados, contas com direitos de sudo e daemons escutando, como SSH ou uma porta de banco de dados exposta. Um achado que só diz que o servidor é inseguro não dá ao dono nada para fazer. Um achado que diz que um host Linux de staging aceita logins SSH por senha a partir da VLAN de usuários, ao contrário da baseline de endurecimento, nomeia o sistema operacional, o controle que falhou e como é a correção.
11.2 Jump hosts
Os caminhos administrativos passam pelo jump host; RDP da VLAN de e-mail para servidores é um achado. Um jump host concentra o acesso administrativo num único lugar que pode ser endurecido, monitorado e protegido com autenticação multifator. Se os administradores também conseguem alcançar os servidores diretamente a partir da rede em que leem e-mail, o comprometimento de suas estações por phishing vira uma rota para os servidores que contorna todos esses controles. Sam testa o caminho a partir de um host sintético da VLAN de usuários com uma conta autorizada. Se uma sessão RDP com um servidor de staging abre sem passar pelo jump host, o achado registra a rede de origem, o destino e a regra de firewall que deveria tê-la bloqueado.
11.3 Imagens
Golden images com agentes antigos reintroduzem risco quando há reconstrução. Uma golden image é o modelo a partir do qual novos hosts são construídos; portanto, o que ela contiver é copiado para todo host construído com ela. Se a imagem traz um agente de endpoint duas versões atrás, ou uma conta local criada para uma sessão de depuração, cada reconstrução traz essa fraqueza de volta, muitas vezes depois de o host original ter sido corrigido à mão. A reconstrução deveria remover a deriva, mas uma imagem desatualizada a acrescenta. É por isso que Sam trata uma fraqueza que reaparece depois de uma reconstrução primeiro como um problema de imagem e confere a data de build e o conteúdo da imagem antes de escrever um achado de host.
11.4 Logs
Os logs do sistema operacional sustentam recomendações de detecção ligadas ao ATT&CK. Um teste pode mostrar mais do que se um ataque funciona. Ele também pode mostrar se os defensores o teriam visto. Depois de uma ação autorizada, como criar uma tarefa agendada com uma conta de teste, Sam pergunta ao SOC se o evento do Windows de criação de tarefa chegou ao SIEM e se alguma regra disparou. Mapear a ação para sua técnica do ATT&CK dá às duas equipes um nome comum para ela. A recomendação passa então a ser uma melhoria de detecção, por exemplo encaminhar o evento de criação de tarefa dos servidores de staging e alertar quando um não administrador cria uma tarefa, em vez de um pedido vago por mais logs.
11.5 Privilégios
A administração do hipervisor é uma camada de escopo separada. Quem administra o hipervisor controla toda máquina virtual nele: pode tirar snapshots, anexar discos e abrir consoles sem que o sistema operacional convidado registre grande coisa. A permissão para testar os servidores convidados, portanto, não cobre a camada de virtualização, que geralmente tem outro dono e outro risco. No TRB, a equipe de virtualização precisa assinar sua própria entrada de escopo antes que alguém teste o console de gerenciamento. Se Sam encontra credenciais do hipervisor enquanto testa um convidado, ele registra isso como achado e para ali, porque usá-las levaria o teste a uma camada que ninguém autorizou.
11.6 Baselines de endurecimento
Desvios precisam de tickets, não de folclore. Uma baseline é a lista escrita das configurações que todo host de determinado tipo deve ter, como protocolos legados desativados, uma política mínima de senhas e log de auditoria ligado. Sistemas reais se desviam por motivos reais, por exemplo uma aplicação antiga que precisa de um protocolo legado. O desvio só é aceitável se estiver registrado com um dono, um motivo e uma data de expiração. Sem esse registro, um testador não consegue distinguir uma exceção aprovada de negligência, e o próximo administrador herda uma configuração que ninguém sabe explicar. Sam confere cada desvio que encontra contra o registro de exceções antes de decidir se escreve um achado.
11.7 Fixar versões no pipeline de imagens
Os tickets do pipeline de imagens precisam nomear as versões dos agentes embutidos. Sam rejeita "latest" como string de versão. Builds reproduzíveis de golden images são tratados como lançamentos de aplicação. A tag latest descreve um momento, não uma versão. Uma imagem construída na segunda-feira com o agente mais recente e reconstruída na sexta pode conter código diferente, e nenhum dos tickets mostra qual. Números de versão exatos permitem a um testador comparar um host em execução com a imagem da qual ele diz vir, e permitem ao dono do pipeline voltar a um estado conhecido. Tratar imagens como lançamentos também significa que cada uma tem um changelog, um revisor e uma data de aposentadoria.
11.8 Censo de administradores locais
Uma consulta trimestral lista os administradores locais em staging. Nomes inesperados viram tickets. Sam faz a correlação com as listas de desligados. Os direitos de administrador local se acumulam em silêncio. Alguém é adicionado para consertar um driver de impressora e nunca é removido, ou uma conta de serviço recebe direitos de administrador porque isso foi mais rápido do que descobrir de que ela precisava. O censo compara o grupo local Administrators de cada host com a lista esperada para a função desse host. Nomes ausentes da lista esperada são conferidos primeiro contra a lista de desligados, porque uma conta de administrador de alguém que saiu é o caso mais urgente. Cada censo é salvo, para que o seguinte mostre se a contagem está caindo.
11.9 Deriva de agentes
Hosts cuja versão do agente difere do catálogo de imagens por mais de uma versão menor abrem tickets automaticamente. O agente de endpoint é a forma como os defensores enxergam um host; por isso, um agente desatualizado pode deixar de ver técnicas que versões mais novas detectam, ou pode falhar em silêncio. A tolerância de uma versão menor permite implantações escalonadas, nas quais alguns hosts atualizam uma semana antes de outros, sem abrir tickets por um atraso normal. Qualquer coisa mais atrasada geralmente significa que o host parou de receber atualizações, muitas vezes porque foi movido para um segmento de rede que o servidor de atualizações não alcança. O ticket automático nomeia o host, os dois números de versão e a data em que o host se comunicou pela última vez.
11.10 Uma reconstrução que reintroduziu o RDP
Um host de staging reconstruído volta com uma postura antiga de RDP. O catálogo de imagens dizia que isso não deveria acontecer. Sam registra tanto um achado de host quanto um achado de pipeline de imagens. Dois donos, dois tickets, uma classe de causa raiz. O dono do host pode corrigir seu servidor no mesmo dia, desativando o RDP a partir da VLAN de usuários. Isso não faz nada pelo próximo servidor construído pelo mesmo pipeline. O ticket do dono da imagem pergunta por que o catálogo e o build discordaram. Neste caso, uma etapa de configuração tinha sido movida para um estágio opcional que a reconstrução pulou. Ligar os dois tickets permite ao revisor fechar o achado de host só depois que o achado de imagem tiver uma correção implantada.
11.11 Um administrador temporário esquecido
O censo de administradores locais encontrou um administrador "temp" dormente criado durante uma indisponibilidade. Ticket, remoção, verificação. Temporários dormentes são permanentes até serem caçados. A conta tinha sido criada às 02:00, durante uma indisponibilidade de armazenamento, para que um terceirizado pudesse reiniciar serviços, e o registro do incidente dizia que ela seria removida na manhã seguinte. Não foi. Sua senha nunca tinha sido trocada e ela não fazia login havia sete meses, o que a tornava ao mesmo tempo inútil e perigosa. Depois de removê-la, Sam verificou a remoção no host e acrescentou ao modelo de indisponibilidade um campo para contas de emergência, cada uma com um horário de expiração que a revisão de encerramento precisa conferir.
11.12 Copiar os donos de imagens nos achados
Os achados de imagem sempre põem em cópia o dono do pipeline, não só o dono do host. Os donos de hosts muitas vezes não enxergam o pipeline que construiu seus servidores, e os donos de pipelines raramente olham tickets de hosts individuais. Uma fraqueza herdada de uma imagem cai entre os dois. O dono do host corrige sua máquina e fecha o ticket, e o pipeline continua produzindo a mesma fraqueza. Pôr o dono do pipeline em cópia coloca o achado diante da pessoa que pode impedir que ele se repita. O FindingsDesk faz isso automaticamente quando a causa raiz de um achado é definida como imagem, de modo que o roteamento não depende de o testador se lembrar.
11.13 Ponderar os achados de imagem pela recorrência
Os achados de pipeline usam uma rubrica de severidade separada, ponderada pela recorrência. Uma imagem ruim pode cunhar cem hosts ruins. Num único host, uma configuração fraca pode ser classificada como média porque poucas pessoas conseguem alcançá-lo. A mesma configuração numa imagem que constrói todos os servidores web de staging e de produção é um risco diferente, porque seu alcance cresce a cada build e ela volta depois de cada correção local. A rubrica de imagens, portanto, pergunta quantos hosts são construídos a partir da imagem, com que frequência são reconstruídos e se algum deles está voltado para a internet. Um achado de host médio pode se tornar um achado de pipeline alto sem nenhuma mudança na fraqueza técnica.
11.14 Publicar as duas escalas de severidade
A rubrica ponderada pela recorrência para imagens é publicada ao lado da severidade de hosts. Bichos diferentes, escalas diferentes. Publicar as duas escalas evita uma discussão previsível. Um dono de pipeline que vê uma classificação alta para uma configuração que a equipe de hosts classificou como média vai suspeitar de inconsistência, a menos que o motivo esteja escrito. A página publicada mostra as duas rubricas lado a lado, com um exemplo resolvido de uma fraqueza classificada em cada uma. Os revisores conferem que todo achado de imagem declara qual escala usou. Ter uma escala separada também permite ao TRB acompanhar a dívida de pipeline por conta própria, o que fundamentou o pedido de financiamento para testes automatizados de imagens.
Exemplo resolvido (TRB sintético)
Sam registra o RDP de staging a partir da VLAN de e-mail, contornando o jump host, como um achado com o hash da captura de tela.
Caso sintético — Riverstone Transit Bank (TRB). O banco, Sam Ito, TrackScope/FindingsDesk/PulseMap e todos os números são inventados para fins didáticos.
Erros e limites
Este livro não concede nenhuma autoridade para testar bancos ou sistemas de pagamento reais. Os laboratórios usam apenas endereços de faixas de documentação e dados sintéticos; código de exploit nunca é fornecido.
Exercícios
- EX031 — Contorno do jump host. Por que o RDP da VLAN de e-mail para servidores é um achado? Rubrica: 3 = contorna o caminho controlado/registrado do jump host; 2 = parcial; 1 = tudo bem; 0 = nada.
- EX032 — Risco das imagens. Como imagens desatualizadas criam fraquezas? Rubrica: 3 = reimplantam agentes/configurações antigos; 2 = parcial; 1 = sem risco; 0 = nada.
- EX033 — Hipervisor. A administração do hipervisor está implícita no escopo web? Rubrica: 3 = não; camada separada; 2 = não; 1 = sim; 0 = nada.
Síntese
Os achados de sistema operacional nomeiam a camada; a administração passa por jump hosts.
Continue estudando — capítulo 11 de 40
← Capítulo 10 (rascunho) · Índice de capítulos do curso · Capítulo 12 (rascunho) →