Início / server / Perguntas / 1164095
Accepted
Rodolfo Saccani
Asked: 2024-08-21 00:05:04 +0800 CST

Auditoria para jumphost SSH e proxy de meias

  • 772

Problema: Para atividades de suporte técnico, os técnicos devem fazer login nos sistemas do cliente usando credenciais fornecidas pelo cliente, mas precisamos registrar qual técnico está conectado a qual sistema para segurança e conformidade com a ISO.

Configuração atual: configurei hosts bastion ssh (Debian 12) para essas atividades de suporte ao cliente. Reforçamos o acesso aos sistemas do cliente através do(s) bastião(ões); cada técnico possui uma conta no bastião e se autentica por meio de chaves ssh.

O bastião é usado para acesso ssh e web aos sistemas do cliente. O acesso SSH é realizado por meio do recurso de salto SSH (ssh -J) e o acesso à Web é realizado por meio de proxy SSH SOCKS5.

Precisamos registrar cada conexão TCP de saída do bastião com pelo menos o nome de usuário do técnico que iniciou a conexão, o endereço IP de destino e a porta.

Fomos auditados, os logs são ingeridos em um SIEM por meio do RSyslog. A configuração de trabalho atual usa uma configuração auditada simples para registrar conexões:

auditctl -a always, exit -S connect -F success=1

Por algum motivo que ainda não entendi, quando um usuário inicia uma conexão com um sistema do cliente usando o bastião como jumphost, uma consulta DNS é registrada (com atribuição correta do usuário), mas não a conexão real com o host de destino.

Aqui está o que recebo nos logs de auditoria:

Aug 20 15:26:09 bastion1 audisp-syslog: type=SYSCALL msg=audit(**1724167569.113:16994887**): arch=c000003e syscall=42 success=yes exit=0 a0=b a1=7f49a2dfa454 a2=10 a3=7ffe86122474 items=0 ppid=3840918 pid=3840929 auid=1002 uid=1002 gid=1002 euid=1002 suid=1002 fsuid=1002 egid=1002 sgid=1002 fsgid=1002 tty=(none) ses=5005 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined key=(null) ARCH=x86_64 SYSCALL=connect AUID="firstname-lastname" UID="firstname-lastname" GID="firstname-lastname" EUID="firstname-lastname" SUID="firstname-lastname" FSUID="firstname-lastname" EGID="firstname-lastname" SGID="firstname-lastname" FSGID="firstname-lastname"
Aug 20 15:26:09 bastion1 audisp-syslog: type=SOCKADDR msg=audit(**1724167569.113:16994887**): saddr=02000035080808080000000000000000 SADDR={ saddr_fam=inet **laddr=8.8.8.8 lport=53** }
Aug 20 15:26:09 bastion1 audisp-syslog: type=PROCTITLE msg=audit(**1724167569.113:16994887**): proctitle=737368643A20726F646F6C666F2D73616363616E69205B707269765D
Aug 20 15:26:09 bastion1 audisp-syslog: type=EOE msg=audit(**1724167569.113:16994887**):

Esta consulta DNS é registrada, mas não há registro sobre a conexão SSH real.

Em relação ao proxy SOCKS, o auditd não parece ser capaz de fornecer os logs que precisamos, as conexões de saída parecem ser iniciadas pelo usuário sshd.

Alguma sugestão sobre como resolver esse problema?

Obrigado

ssh

1 respostas

  1. Best Answer
    auditctl -a always,exit -S connect -F success=1

    Não consegui descobrir por que isso não funciona. Eu suspeito que tenha algo a ver com sshd usando soquetes sem bloqueio (onde connect() nunca retorna sucesso, apenas -EINPROGRESS).

    Portanto, pode ser mais fácil usar o log do firewall, com iptables -j LOG --log-uidque incluirá o UID do soquete em cada mensagem, ou similarmente nftables log flag skuid. Isso tem uma grande vantagem, pois não depende de como a conexão é feita (soquete bloqueador ou não bloqueador; syscall de 32 bits ou syscall de 64 bits ou io_uring).

    Alternativamente: Execute seu sshd em LogLevel DEBUG1pois ele próprio gravará os detalhes da conexão no syslog:

    sshd-session[1213015]: Authorized to grawity, krb5 principal [email protected] (krb5_kuserok)
sshd-session[1213015]: Accepted gssapi-with-mic for grawity from 10.147.21.6 port 47240 ssh2: [email protected]
sshd-session[1213015]: User child is on pid 1213018
sshd-session[1213018]: debug1: server_request_direct_tcpip: originator 127.0.0.1 port 65535, target ember.sym port 22
sshd-session[1213018]: debug1: connect_next: start for host ember.example.com ([10.147.1.4]:22)
sshd-session[1213018]: debug1: connect_next: connect host ember.example.com ([10.147.1.4]:22) in progress, fd=6

    Se o seu daemon syslog suportar, o UID do processo sshd poderá ser adicionado diretamente às mensagens debug1 para obter tudo em uma linha.

    O bastião é usado para acesso ssh e web aos sistemas do cliente. O acesso SSH é realizado por meio do recurso de salto SSH (ssh -J), o acesso à web é realizado por meio de proxy SSH SOCKS5.

    São exatamente a mesma coisa. Eles diferem apenas no tratamento do lado do cliente, mas o servidor vê ambos como o mesmo tipo de direct-tcpipsolicitações de canal e são tratados no mesmo processo por meio do mesmo código. (Sim, é o cliente que finge ser um servidor SOCKS5.)

    Em relação ao proxy SOCKS, o auditd não parece ser capaz de fornecer os logs que precisamos, as conexões de saída parecem ser iniciadas pelo usuário sshd.

    Este não pode ser o caso, já que o sshd geralmente é rigoroso quanto ao isolamento de seus processos de sessão - uma vez autenticado, toda a conexão é entregue a um processo de sessão que é executado sob sua conta e é isso que lida com os canais shell e os canais TCP . Ter um processo controlado pelo usuário executado na conta 'sshd' compartilhada seria muito incomum de se ver.

    • 3

relate perguntas