Tenho um certificado curinga para serviços internos. Gostaria de executar o Security Onion atrás de um ALB para poder obter SSL válido com um único certificado armazenado no gerenciador de certificados. (Armazená-lo lá é melhor para segurança, além de manutenção e confiabilidade mais fáceis)
O problema parece ser que no arquivo de configuração do Security Onion /opt/so/saltstack/local/pillar/global.sls
url_base: # IP or FQDN
Pode ser configurado para escutar por endereço IP (ponto em que os redirecionamentos de login apontam para IP e verificam quebras de SSL) OU por FQDN (ponto em que não responde a solicitações por IP e a verificação de integridade do grupo de destino falha).
Eu acidentalmente fiz funcionar mudando de IP para FQDN. Mas suspeito que estava funcionando no período de carência de 2 minutos enquanto a verificação de integridade ainda estava verde, mas o servidor estava funcionando por FQDN.
Nos bastidores, o Security Onion está usando o nginx para realizar o roteamento de host para docker. O arquivo de configuração do nginx está aqui /opt/so/saltstack/default/salt/nginx/etc/nginx.conf
Alguém já fez isso antes?
Responder1
Consegui fazer isso funcionar inserindo uma verificação de integridade simples na configuração do nginx.
server {
listen 443 ssl http2;
server_name 192.168.1.something;
location /health {
access_log off;
add_header 'Content-Type' 'text/plain';
return 200 "healthy\n";
}
}
Duas limitações desta abordagem.
- Codifiquei o endereço IP em minha configuração e isso será interrompido se meu host for movido ou instanciado novamente a partir do instantâneo. (Isso pode ser corrigido fazendo com que o nginx infira o IP local?)
- A verificação de integridade verifica se o nginx está em execução, mas não se o SO está íntegro por trás dele.