Capítulo 17 — Infraestrutura crítica e segurança setorial: ferramental
Mapa da aula
Aula 17 publicada. Mapa, exemplo, EX049.
flowchart TD
N0["17.1 O que registrar"]
N1["17.2 Tempo"]
N2["17.3 Logs estruturados e syslog"]
N3["17.4 Normalização"]
N4["17.5 Ferramentas em que você pode confiar"]
N5["17.7 Atividade prática: normalizador"]
N6["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX049"]
Desenho lógico
flowchart LR
N0["17.1 O que registrar"]
N1["17.2 Tempo"]
N2["17.3 Logs estruturados e syslog"]
N3["17.4 Normalização"]
N4["17.5 Ferramentas em que você pode confiar"]
N5["17.7 Atividade prática: normalizador"]
N6["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX049"]
[17.1 O que registrar]
|
v
[17.2 Tempo]
|
v
[17.3 Logs estruturados e syslog]
|
v
[17.4 Normalização]
|
v
[17.5 Ferramentas em que você pode confiar]
|
v
[17.7 Atividade prática: normalizador]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX049]
Objetivos de aprendizagem e conexão
Depois deste capítulo, você deve ser capaz de:
- configurar sistemas para produzir logs que respondam a perguntas operacionais e de segurança;
- manter os relógios sincronizados e registrar o tempo num formato único e sem ambiguidade;
- normalizar logs de fontes diferentes numa estrutura comum;
- escrever e testar uma pequena ferramenta para poder confiar na sua saída, e saber quando usar uma existente em vez disso.
O monitoramento (Capítulo 19), a resolução de problemas (Capítulo 20) e a avaliação (Capítulo 23) dependem todos de logs. A maioria das falhas de log não é a falta de produtos, mas a falta do básico: uma fonte que nunca encaminhou, um carimbo de tempo sem fuso horário, um parser que descarta em silêncio as linhas que não entende.
17.1 O que registrar
Registre o que você vai precisar para responder às perguntas que lhe farão: quem fez login, de onde, com que resultado; que configuração mudou; o que o relay aceitou, rejeitou e quarentenou, com contagens; quais fluxos atravessaram fronteiras de zona; quando os serviços iniciaram, pararam ou falharam. O guia do NIST de gestão de logs cobre o planejamento, a geração, a transmissão, o armazenamento e a análise de logs (NIST SP 800-92). Encaminhe os logs para fora do host prontamente — não se pode confiar que um host comprometido ou com defeito guarde os seus próprios registros — e monitore se o encaminhamento continua.
17.2 Tempo
Ordenar eventos entre sistemas exige um tempo acordado. Sincronize todo host com uma fonte de tempo confiável usando NTP (RFC 5905); no LANTERN, os relays tomam a hora de dois servidores internos e a fornecem às estações. Registre os carimbos de tempo num formato com deslocamento explícito, como os definidos na RFC 3339, e converta para UTC na análise. Monitore o próprio deslocamento do relógio: um host cuja fonte de tempo falhou deriva devagar e em silêncio.
17.3 Logs estruturados e syslog
O protocolo syslog, RFC 5424, define uma mensagem com prioridade (facility e severidade), versão, carimbo de tempo, nome do host, nome da aplicação, ID do processo, ID da mensagem, dados estruturados (parâmetros chave–valor entre colchetes) e uma mensagem em texto livre. Os dados estruturados são o que torna os logs pesquisáveis: src="192.0.2.44" user="root" pode ser contado e filtrado; a mesma informação enterrada em prosa precisa ser adivinhada com padrões. Dispositivos mais antigos costumam enviar o formato BSD anterior, sem ano nem fuso horário; registre essas fontes como de qualidade inferior e converta com cuidado.
17.4 Normalização
Um normalizador transforma o formato de cada fonte num registro comum: hora em UTC, host, aplicação, severidade e campos nomeados como src, user, dst, dport, action. As regras posteriores (Capítulo 19) são então escritas uma só vez. Um normalizador precisa contar o que não consegue interpretar e relatá-lo: os descartes silenciosos são como um sistema de monitoramento fica cego para a única fonte que mudou de formato.
A linha em formato BSD do relay, na noite do exemplo resolvido, mostra por quê: sem uma contagem de não interpretadas, ela simplesmente teria desaparecido.
A linha do quiosque sem carimbo de tempo algum é o outro caso: o normalizador precisa sinalizá-la, e não carimbá-la com a hora de chegada.
17.5 Ferramentas em que você pode confiar
Os implementadores escrevem pequenas ferramentas o tempo todo. A confiança na saída de uma ferramenta vem de: uma declaração clara do que ela trata e do que não trata; testes com casos ruins e de borda (Capítulo 3); contagens de entradas, saídas e rejeições que fecham; saída determinística para a mesma entrada; e controle de versões. Escreva a sua própria ferramenta quando a tarefa for pequena e específica; use uma ferramenta estabelecida e mantida quando a tarefa for geral (um coletor syslog completo, uma biblioteca TLS, um banco de dados). Nunca escreva a sua própria criptografia — use a da biblioteca padrão.
17.6 Exemplo resolvido: os logs de uma noite (sintético)
O Laboratório 17 interpreta sete linhas do relay, do firewall, do historiador e do quiosque da garagem. Seis são interpretadas, uma não: uma linha em formato BSD da própria aplicação do relay, revelando que um componente do LANTERN nunca foi configurado para o formato acordado. Uma linha não tem carimbo de tempo algum (o quiosque). A linha do historiador traz +01:00; convertida para UTC, ela é 22:02:11 — antes dos eventos de SSH, e não depois, como a sua hora local sugere. Ordenada em UTC, a noite se lê assim: erro de cota de disco do historiador às 22:02, um login legítimo de administrador às 22:14, dois logins de root malsucedidos a partir de um endereço externo às 22:15, e um fluxo Modbus corporativo-para-PS-04 às 22:16, a partir da mesma estação de trabalho usada no login de administrador.
17.7 Atividade prática: normalizador
Laboratório 17 (salve como lab17.py, execute com python3 lab17.py):
# Lab 17 - normalizing RFC 5424-style syslog lines into JSON records (offline, standard library only)
# Synthetic log lines from the relay, historian and firewall. Simplified parser for teaching, not a full RFC 5424 implementation.
import json, re
from datetime import datetime, timezone
LINE = re.compile(r"<(?P<pri>\d{1,3})>1 (?P<ts>\S+) (?P<host>\S+) (?P<app>\S+) (?P<proc>\S+) (?P<msgid>\S+) (?P<sd>-|\[.*?\]) ?(?P<msg>.*)")
SEV = ["emerg", "alert", "crit", "err", "warning", "notice", "info", "debug"]
lines = [
'<86>1 2026-10-11T22:14:03.120Z rly-01 sshd 812 AUTH [meta src="10.40.3.7" user="b.lind"] Accepted publickey',
'<84>1 2026-10-11T22:15:40.004Z rly-01 sshd 813 AUTH [meta src="192.0.2.44" user="root"] Failed password',
'<84>1 2026-10-11T22:15:41.917Z rly-01 sshd 813 AUTH [meta src="192.0.2.44" user="root"] Failed password',
'<134>1 2026-10-11T22:16:00.000Z fw-hub filter - FLOW [flow src="10.40.3.7" dst="10.20.0.11" dport="502" act="allow"]',
'<131>1 2026-10-11T23:02:11+01:00 hist-01 histsvc 4410 DBERR - write failed: disk quota',
'Oct 11 22:17:00 rly-01 relay: legacy BSD-format line',
'<13>1 - kiosk-depot app - - - no timestamp supplied',
]
SDPARAM = re.compile(r'(\w+)="((?:[^"\\]|\\.)*)"')
out, bad = [], 0
for raw in lines:
m = LINE.fullmatch(raw)
if not m:
bad += 1; print("UNPARSED:", raw[:40]); continue
pri = int(m["pri"])
rec = {"ts": None if m["ts"] == "-" else m["ts"], "host": m["host"], "app": m["app"],
"facility": pri // 8, "severity": SEV[pri % 8], "msgid": m["msgid"], "msg": m["msg"]}
rec.update(dict(SDPARAM.findall(m["sd"])))
if rec["ts"]: # normalize every timestamp to UTC so sources can be ordered together
rec["ts_utc"] = datetime.fromisoformat(rec["ts"]).astimezone(timezone.utc).strftime("%Y-%m-%dT%H:%M:%S.%f")[:-3] + "Z"
out.append(rec)
for r in sorted(out, key=lambda r: r.get("ts_utc") or ""):
print(r.get("ts_utc"), r["host"], r["severity"], r.get("src", "-"), r["msg"] or r["msgid"])
print(json.dumps(out[1], sort_keys=True))
print(f"parsed {len(out)}, unparsed {bad}, missing timestamp {sum(r['ts'] is None for r in out)}")
Saída esperada (Python 3.13.5):
UNPARSED: Oct 11 22:17:00 rly-01 relay: legacy BSD
None kiosk-depot notice - no timestamp supplied
2026-10-11T22:02:11.000Z hist-01 err - write failed: disk quota
2026-10-11T22:14:03.120Z rly-01 info 10.40.3.7 Accepted publickey
2026-10-11T22:15:40.004Z rly-01 warning 192.0.2.44 Failed password
2026-10-11T22:15:41.917Z rly-01 warning 192.0.2.44 Failed password
2026-10-11T22:16:00.000Z fw-hub info 10.40.3.7 FLOW
{"app": "sshd", "facility": 10, "host": "rly-01", "msg": "Failed password", "msgid": "AUTH", "severity": "warning", "src": "192.0.2.44", "ts": "2026-10-11T22:15:40.004Z", "ts_utc": "2026-10-11T22:15:40.004Z", "user": "root"}
parsed 6, unparsed 1, missing timestamp 1
Confira duas coisas na saída. Primeiro, a contagem de não interpretadas é 1, a linha em formato BSD da aplicação do relay, que é uma falha de configuração num componente do LANTERN, e não ruído. Segundo, a linha +01:00 do historiador, convertida para UTC, fica em 22:02:11, antes do login de administrador das 22:14 e dos logins de root malsucedidos das 22:15, e não depois deles. Ordenado assim, o fluxo Modbus corporativo-para-PS-04 das 22:16 vem depois de um login de administrador a partir da mesma estação de trabalho, que é a sequência que a Regra B vai sinalizar mais tarde.
17.8 Erros comuns e limites
- Registrar tudo em nível de depuração, enchendo os discos (Capítulo 1) e escondendo os eventos que importam.
- Logs mantidos apenas no host que os produziu.
- Carimbos de tempo sem fuso horário; misturar hora local e UTC numa mesma análise.
- Parsers que descartam linhas não interpretáveis sem contá-las.
- Presumir que o encaminhamento de logs ainda funciona porque funcionava no mês passado.
- Construir uma ferramenta caseira onde existe uma mantida, ou criptografia caseira em qualquer caso.
O parser do laboratório é uma simplificação didática da RFC 5424: ele não trata todas as sequências de escape nem múltiplos elementos de dados estruturados. Ele relata o que não consegue interpretar, que é a propriedade que mais importa.
Exercícios — capítulo 17
EX049 — Corrija o formato do relay. Objetivo: tratar uma fonte fora do padrão. Entradas: a linha não interpretada do Laboratório 17. Restrições: duas opções. Etapas: (1) descreva corrigir a fonte (mudança de configuração no relay); (2) descreva acrescentar um segundo parser para o formato BSD; (3) diga o que você faria primeiro e por quê, e o que o parser BSD não consegue recuperar. Evidência esperada: meia página. Rubrica: 3 = corrigir na fonte primeiro (é um componente nosso, sob controle de mudanças), parser BSD como alternativa para dispositivos de terceiros; as linhas BSD não têm ano nem fuso, então o parser precisa presumi-los e marcar os registros como de qualidade inferior; 2 = uma opção; 1 = "ignorar"; 0 = nada.
EX050 — Ordem dos eventos. Objetivo: ver o efeito dos fusos horários. Entradas: a saída do Laboratório 17. Restrições: nenhuma. Etapas: (1) liste os eventos na ordem dos seus carimbos de tempo escritos, ignorando os deslocamentos; (2) liste-os na ordem em UTC; (3) explique como um investigador usando a primeira ordem leria mal o evento do historiador. Evidência esperada: duas listas e explicação. Rubrica: 3 = o evento do historiador aparece por último na ordem escrita (23:02), mas primeiro em UTC (22:02); o investigador poderia ligar erroneamente o erro de cota de disco aos logins malsucedidos; 2 = listas certas, explicação rasa; 1 = uma lista; 0 = nada.
EX051 — Conte o que você descarta. Objetivo: acrescentar uma autoverificação à ferramenta. Entradas: Laboratório 17. Restrições: apenas a biblioteca padrão. Etapas: (1) acrescente uma verificação de que o número de linhas de entrada é igual a interpretadas mais não interpretadas, saindo com erro caso contrário; (2) acrescente uma contagem por host das linhas não interpretadas; (3) explique por que um sistema de monitoramento deveria alertar quando a contagem de não interpretadas de um host sobe. Evidência esperada: código, saída, explicação. Rubrica: 3 = invariante aplicado, contagens por host impressas (rly-01: 1), explicação de que uma mudança de formato numa fonte cega as regras em silêncio; 2 = parcial; 1 = não executado; 0 = nada.
Síntese do capítulo
Registre o que você vai precisar responder, encaminhe para fora do host e confira se o encaminhamento continua. Sincronize os relógios, registre o tempo com deslocamentos explícitos e analise em UTC. Normalize as fontes numa estrutura única, conte tudo o que você não consegue interpretar e construa pequenas ferramentas com testes e invariantes, para que a sua saída mereça confiança; use ferramentas estabelecidas para os trabalhos gerais e nunca invente criptografia.
Continue estudando — capítulo 17 de 30
← Capítulo 16 · Índice de capítulos do curso · Capítulo 18 →
Siga para a próxima lição escrita.