O Logstash-forwarder está lançando erros de SSL

Question

Eu recebi esta tarefa entregue pelo meu colega e este é o plano de fundo.

Ele obteve a stack ELK (Elasticsearch, Logstash e Kibana) trabalhando com nossos servidores RHEL 6.2, usando o método regular de configuração do Logstash no servidor e o Logstash-forwarder em todos os agentes. Tudo está funcionando bem como esperado, exceto por dois nós do agente logstash. Não está indexando dados desses dois nós e esses dois nós de agente são um pouco diferentes dos outros agentes no ambiente. Todos os agentes (que estão funcionando) estão executando a máquina RHEL 6.2 com 'OpenSSL 1.0.0-fips', enquanto os dois agentes problemáticos estão executando o RHEL 5.5 com 'OpenSSL 0.9.8e-fips-rhel5'. Agora, deixe-me explicar os problemas que esses dois nós estavam enfrentando quando comecei a trabalhar nisso.

Quando reiniciamos o serviço do encaminhador logstash com '/etc/init.d/logstash-forwarder restart', ele gera o seguinte erro:

2014/10/01 09:21:23.898917 Failed to tls handshake with 10.x.x.x x509: cannot validate certificate for 10.x.x.x because it doesn't contain any IP SANs 2014/10/01 09:21:24.900502 Connecting to [10.x.x.x]:5000 (10.x.x.x) 2014/10/01 09:21:24.902081 Failed to tls handshake with 10.x.x.x x509: cannot validate certificate for 10.x.x.x because it doesn't contain any IP SANs 2014/10/01 09:21:25.903970 Connecting to [10.x.x.x]:5000 (10.x.x.x) 2014/10/01 09:21:25.905708 Failed to tls handshake with 10.x.x.x x509: cannot validate certificate for 10.x.x.x because it doesn't contain any IP SANs

Eu entendo que isso ocorre porque o agente está tentando se conectar ao servidor através de SSL usando seu endereço IP, então recriou os certificados novamente com IP SANs e, em seguida, ele começou a me enganar, não apenas com as máquinas 5.2, mas também com máquinas 6.2:

2014/10/03 17:09:12.403253 Failed to tls handshake with 10.x.x.x x509: certificate signed by unknown authority 2014/10/03 17:09:13.404974 Connecting to [10.x.x.x]:5000 (10.x.x.x) 2014/10/03 17:09:13.428156 Failed to tls handshake with 10.x.x.x x509: certificate signed by unknown authority 2014/10/03 17:09:14.429648 Connecting to [10.x.x.x]:5000 (10.x.x.x) 2014/10/03 17:09:14.442006 Failed to tls handshake with 10.x.x.x x509: certificate signed by unknown authority

Eu tentei adicionar o certificado ao ca-bundle.crt anexando o novo certificado logstash ao arquivo CA com:

'openssl x509 em certs / logstash-forwarder.crt -text > > certs / ca-bundle.crt '.

Tenho a sensação de que poderei corrigir todo o problema se eu conseguir que os certificados 'IP SAN' sejam adicionados à lista de certificados confiáveis de todos os nós do agente. Minhas perguntas são:

Só mais uma coisa, o servidor Logstash está executando o RHEL 6.2. E todos os nós do agente (funcionando e não funcionando) têm a mesma versão do logstash-forwarder instalada - logstash-forwarder-0.3.1-1.x86_64.rpm. Qual é o método correto para fazer com que esses nós de agentes aceitem os certificados de SANs IP? Estou entendendo a questão corretamente? É alguma incompatibilidade entre as máquinas RHEL 6.xe RHEL 5.x?

Eu tenho as seguintes entradas no / etc / logstash-forwarder

[root@name2 ~]# cat /etc/logstash-forwarder { "network": { "servers": [ "10.x.x.x:5000" ], "timeout": 15, "ssl ca": "/etc/pki/tls/certs/logstash-forwarder.crt", "ssl strict verify": "false" }, "files": [ { "paths": [ "/var/log/maillog" ], "fields": { "type": "syslog" } } ] } [root@name2 ~]#

Obrigado antecipadamente.

    

Answer 1

O certificado que você está usando não tem nenhuma SAN IP válida, como mencionado na mensagem:

Failed to tls handshake with x.x.x.x x509: cannot validate certificate for x.x.x.x because 
it doesn't contain any IP SANs  

Se você se conectar usando um endereço IP, seu certificado deverá conter uma SAN IP correspondente para passar a validação com o Go 1.3 e superior. Isto não é (ainda?) Mencionado em qualquer arquivo README ou documentação, mas existem alguns problemas ( # 226 , # 221 ) aberto no projeto github repo.
Para permitir o endereço IP como o nome do servidor, o certificado SSL deve incluir o endereço IP como um campo subjectAltName .

Para resolver isso, você pode usar o seguinte procedimento para a criação do certificado SSL e chave:

1. Crie um arquivo notsec.cfr (ou qualquer outro nome) contendo saída como:

   [req]
   distinguished_name = req_distinguished_name
   x509_extensions = v3_req
   prompt = no
   
   [req_distinguished_name]
   C = TG
   ST = Togo
   L =  Lome
   O = Private company
   CN = *
   
   [v3_req]
   subjectKeyIdentifier = hash
   authorityKeyIdentifier = keyid,issuer
   basicConstraints = CA:TRUE
   subjectAltName = @alt_names
   
   [alt_names]
   DNS.1 = *
   DNS.2 = *.*
   DNS.3 = *.*.*
   DNS.4 = *.*.*.*
   DNS.5 = *.*.*.*.*
   DNS.6 = *.*.*.*.*.*
   DNS.7 = *.*.*.*.*.*.*
   IP.1 = 192.168.1.1
   IP.2 = 192.168.69.14  
   

Se você se conectar por meio de nomes de host, poderá remover as SANs IP, caso contrário, adicione o endereço IP do seu servidor logstash.

2. Crie o certificado e a chave com o seguinte comando (usando o arquivo do ponto 1):

   openssl req -x509 -batch -nodes -newkey rsa:2048 -keyout notsecure.key -out notsecure.crt -config notsec.cnf -days 1825
   

Isso criará um tipo de certificado curinga que aceita qualquer nome de host e os endereços IP mencionaram esse arquivo. Claro que este é apenas um exemplo simples e você precisará ajustar as configurações às suas necessidades.