Os alertas de início de sessão VPN não são alertas de intrusão: observe a sessão
Um início de sessão invulgar é um motivo de revisão, não um veredicto. Ligue o registo de autenticação a uma sessão e depois ao que ela tocou, antes de lhe chamar intrusão.
Um alerta de VPN que dispara para um país novo parece conclusivo, e normalmente não é. A autenticação diz que uma tentativa foi aceite; a sessão diz que ligação a transportou; os registos de recursos dizem o que aconteceu dentro dessa ligação. Cada um responde a uma pergunta diferente. Uma regra que funde os três produz trinta tickets numa segunda-feira e deixa passar o caso real numa sexta-feira.
Um endereço estrangeiro é uma pergunta, não uma resposta
As viagens, os operadores móveis que saem noutro país, um proxy web empresarial e um pool de NAT de operadora reatribuído movem todos a origem aparente sem mover o atacante. O registo de início de sessão reflete por onde a ligação entrou na rede, não quem segurava o dispositivo.
A falha inversa é pior porque é silenciosa. Uma palavra-passe roubada usada a partir da cidade do próprio utilizador produz um início de sessão que coincide com todos os anteriores na verificação geográfica.
Tratar a geografia como o veredicto tem um custo mensurável. Os portáteis que viajam geram um fluxo constante de revisões, os revisores aprendem a fechá-las sem ler, e o hábito sobrevive até um caso real chegar à mesma fila.
Três tipos de registo respondem a três perguntas diferentes
Comece pelo que os produtos implementados emitem de facto, não pelo que um folheto sugere que poderiam emitir. A decisão de autenticação nomeia a identidade afirmada, o método e o resultado. O ciclo de vida da sessão nomeia a ligação, o gateway e o endereço atribuído, do início à paragem.
| Record | Question it answers | What it cannot prove |
|---|---|---|
| Authentication decision | Which identity was accepted or rejected, by which method, at what time | That the person operating the device was the account owner |
| Session lifecycle | Which connection, gateway and assigned address were active, and for how long | What the session did with that access |
| Resource event | Which read, write or denied operation a service observed | Which human behind the session triggered it |
| Policy change | Whether an administrator altered the rule that governs the access | Whether the change was reviewed or intended |
Uma célula vazia é uma lacuna de recolha, não uma absolvição. Se os eventos de recursos nunca chegam, a ausência de uma leitura suspeita significa que o pipeline não tem nada a relatar, e um painel silencioso descreve o pipeline e não a rede. Anote que registos a implementação produz realmente antes de prometer uma regra que dependa deles, e nomeie o responsável de cada feed em falta.
O detalhe contabilístico é onde as sessões se tornam verificáveis. A contabilidade RADIUS descrita em RFC 2866 transporta atualizações de início, paragem e intermédias ligadas a um identificador de sessão, pelo que uma sessão com início e sem paragem é uma lacuna que pode nomear em vez de um mistério.
Una pela sessão, não pelo nome de utilizador
Uma conta mantém legitimamente várias sessões ao mesmo tempo: um portátil, um telemóvel, uma máquina de laboratório deixada ligada durante a noite. Unir todos os eventos desse nome de utilizador funde três dispositivos numa história e depois lê a combinação como compromisso. Os endereços atribuídos também são reciclados, pelo que uma junção que continua a coincidir com um endereço depois de a sessão terminar arrasta o dispositivo do mês passado para o incidente de hoje. Guarde a chave de sessão junto ao endereço e limite a correspondência à janela temporal que a sessão realmente cobriu.
Onde a tradução remove a origem original antes de um serviço a ver, use a identidade que sobrevive nessa fronteira, como um sujeito de TLS mútuo ou uma asserção de início de sessão único. Inventar uma correspondência um para um entre um endereço e uma pessoa é o mesmo erro com passos extra.
Um alerta sem dono é um painel
Cada regra precisa de uma condição, das explicações benignas que a produzem, das provas a recolher e da pessoa que age. Uma operação administrativa negada repetida, uma rajada de palavras-passe falhadas e um recoletor silencioso são três incidentes diferentes com três relógios diferentes.
A notificação não é a contenção, e uma lista de distribuição não restringe nada. Alterar uma sessão ativa exige o componente que o consegue fazer, seja o gateway que corta a ligação ou o fornecedor de identidade que revoga a sessão. Os feeds obsoletos e os registos de paragem em falta também pertencem ao texto da regra, porque um recoletor que não enviou nada durante um dia parece exatamente uma rede silenciosa visto do painel. A diferença só é visível no próprio pipeline.
Verifique o caminho de recolha antes de confiar numa semana calma
Prove o pipeline de ponta a ponta antes de ajustar uma única regra. Os comandos abaixo confirmam que os escutadores de autenticação e contabilidade estão ativos, que uma credencial de teste é rejeitada pelo motivo correto e que os eventos de sessão continuam a chegar:
ss -uanp | grep -E ':(1812|1813)\b' radtest alice 'not-the-password' 127.0.0.1 0 testing123 journalctl -u openvpn-server@server --since '-30 min' | grep -c 'Peer Connection Initiated' timedatectl | grep -E 'System clock|synchronized'
Um Access-Reject do teste prova que o pedido chegou ao servidor e que o segredo partilhado coincidiu, e é essa a parte que as pessoas saltam. Um tempo limite, em vez disso, aponta para o segredo, o escutador ou um filtro à frente dele, e cada alerta a jusante é inverificável até isso ser corrigido.
O estado do relógio importa porque as janelas de correlação pressupõem acordo. Um gateway desviado alguns minutos torna impossível uma junção de sessão de outra forma limpa, e os revisores compensam alargando a janela até a junção deixar de distinguir. Verifique o desvio antes de editar a regra.
Depois ponha uma regra à prova num teste inofensivo: gere um início de sessão a partir de um endereço inesperado, confirme que o alerta dispara, confirme que o respondedor consegue extrair a sessão e os seus eventos de recursos, e confirme que o ticket leva o identificador de sessão. Uma regra que produz uma história coerente passa. Uma regra que produz uma pilha de linhas de registo continua a ser um painel. Registe o resultado junto à regra para que a próxima revisão comece com evidência e não com intuição.