Alguns aplicativos (é desconhecido) fazem solicitações HTTP(S) de saída curtas e raras e esporádicas e não regulares para um host/porta/url conhecido (este é um honeypot WAF, host/url/porta é conhecido) usando o protocolo HTTPS. As solicitações podem ocorrer uma vez a cada 3-5 dias. É literalmente uma solicitação curta a cada 3-5 dias. O objetivo é definir qual aplicação (caminho para o binário, PID etc) faz essas solicitações. O servidor tem muitos softwares instalados, incluindo nginx, php, mariadb, redis, dockeretc.
Para simplificar, o IP do honeypot terá 7.7.7.7 aqui.
O que eu tentei até agora:
- tcpdump
$ sudo tcpdump -i any dst host 7.7.7.7 and "tcp[tcpflags] & (tcp-syn) != 0" and "tcp[tcpflags] & (tcp-ack) == 0" &> /tmp/out_7.7.7.7_$(date "+%Y.%m.%d-%H.%M.%S").log &
Parece que tcpdumpnão permite detectar o ID do processo ou executável que faz solicitações http de saída.
- auditctl/auditd
sudo auditctl -a exit,always -F arch=b64 -S connect -k connectLog
auditctl/auditdparece poder gerar o caminho e o pid, mas não possui recurso de filtragem. Se eu iniciar a regra de auditoria por 3 a 5 dias, meu disco ficará cheio de log de auditoria. Ou, se os logs de auditoria estiverem girando, posso perder os dados de log necessários no arquivo de log já girados e eliminados. Se auditctltivesse recurso de filtragem na gravação (não nos logs de análise) por IP de destino, provavelmente seria o melhor candidato. Talvez esteja faltando alguma coisa e tenha recurso de filtragem?
Outra opção que descobri é criar um script bash, que:
- iniciou a auditoria de
connect - iniciou o processo de monitoramento assim:
( tail -f -n0 /var/log/audit/audit.log & ) | grep -q "7.7.7.7" - assim que o monitor detectar isso, pare de auditar
auditctl -d...
O problema é que esse evento pode ocorrer após 3 a 5 dias, quando todos os discos estarão cheios.
- netstat
$ sudo netstat -tupnc | grep 7.7.7.7
Parece que netstatcom -ca opção (contínuo) repete a leitura a cada 1 segundo. Como as solicitações são muito curtas, essa solicitação pode ser perdida.
- ss
ssparece não exibir o processo que originou a conexão de saída.
- lsof
lsof -i TCP:80,443 -r 1
A conexão de saída é muito curta e rápida, pode não ser registrada executando lsof a cada 1 segundo
wireshark O Wireshark possui bons recursos de filtragem (por IP), mas parece que não exibe o nome do processo originador da conexão ou pid.
Atualmente estou preso com a solução: combine
syslog-ng(que possui recursos de filtragem ao receber logs via TCP/rede) como receptor eauditdcomo remetente de eventos de log. Consegui iniciarsyslog-ngna porta 2222, receber dados da rede e filtrá-los por alguma string (testada comcurl). Mas não consigoauditdenviar logs para a rede.
O que eu fiz:
7.1) Instalado audisp-remote-plugin:
$ sudo apt install audispd-plugins
7.2) Habilitado audisp-remote plugin:
no arquivo /etc/audit/plugins.d/au-remote.conf: conjuntoactive = yes
7.3) audisp-remotePlugin configurado:
no arquivo /etc/audit/auditsp-remote.conf:
remote_server = 127.0.0.1
port = 2222
7.4) Gravação desabilitada em um log_file local
no arquivo /etc/audit/auditd.conf:
write_logs = no
e reiniciei o auditd:
$ sudo systemctl restart auditd
7.5) Adicionada regra de auditoria para capturar conexões ( connectsyscalls):
$ sudo auditctl -a exit,always -F arch=b64 -F saddr_fam=2 -S connect -k sckt
7.6) Logs girados para limpar dados anteriores nos auditdlogs
$ service auditd rotate
7.7) Feita chamada HTTP de teste:
$ curl -v https://7.7.7.7/api/v1/t
7.8) Log verificado syslog-ng, mas não possui registros esperados.
Se alguém souber a melhor abordagem mais apropriada, fácil e simples para fazer isso, qualquer ajuda será apreciada!
Responder1
Você provavelmente poderia ingerir o log de auditoria usando uma origem de arquivo no syslog-ng e, em seguida, usar um tempo de retenção relativamente curto para logs de auditoria.
Com isso você pode aplicar filtragem no lado do syslog-ng e gerar os registros interessantes em um arquivo de log separado.