Buenos dias a todos,
La semana pasada decidí ejecutar los comandos para actualizar paquetes en mi servidor 14.04 para asegurarme de que estuviera parcheado para las vulnerabilidades de Bash encontradas recientemente. Según la información aquí (http://www.ubuntu.com/usn/usn-2362-1/) Ejecuté una actualización de apt-get dist-upgrade. Como referencia, ejecuté apt-get update, apt-get dist-upgrade y luego apt-get Upgrade para probar y asegurarme de que tenía todo actualizado a las últimas versiones (aunque ejecuto rutinariamente apt-get Upgrade).
Después de hacer esto con éxito, descubrí que varios de mis scripts Perl ya no funcionaban. Como referencia, uso este servidor para Nagios para monitorear todos mis otros servidores. Todos los scripts en cuestión que ahora fallan se conectan a un sistema a través de https, inician sesión en el host y consultan diversos fragmentos de información.
Antes de la actualización, pude agregar una línea a cada uno de mis scripts Perl para que ignorara el SSL:
$ENV{PERL_LWP_SSL_VERIFY_HOSTNAME} = 0 }
Sin embargo, después de la actualización, esto parece no tener ningún efecto y todos los scripts fallan porque no pueden verificar los certificados SSL (todos autofirmados).
Aquí hay algunos fragmentos de lo que estoy viendo:
ejecución del guión:
nagios@nagios:/usr/local/nagios/libexec$ ./check_esx.pl -H 192.168.22.18 -u root -p password -l cpu
CHECK_ESX.PL CRITICAL - Can't connect to 192.168.22.18:443 (certificate verify failed)
LWP::Protocol::https::Socket: SSL connect attempt failed error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed at /usr/share/perl5/LWP/Protocol/http.pm line 41.
Este script Perl en particular utiliza el "VMware Infrastructure (VI) Perl Toolkit" para funcionar. El script al que estoy llamando, check_esx.pl, está disponibleaquí
Aquí hay un fragmento del archivo http.pm alrededor de la línea a la que se hace referencia en el error anterior; la línea 41 es la línea "morir".
sub _new_socket
{
my($self, $host, $port, $timeout) = @_;
local($^W) = 0; # IO::Socket::INET can be noisy
my $sock = $self->socket_class->new(PeerAddr => $host,
PeerPort => $port,
LocalAddr => $self->{ua}{local_address},
Proto => 'tcp',
Timeout => $timeout,
KeepAlive => !!$self->{ua}{conn_cache},
SendTE => 1,
$self->_extra_sock_opts($host, $port),
);
unless ($sock) {
# IO::Socket::INET leaves additional error messages in $@
my $status = "Can't connect to $host:$port";
if ($@ =~ /\bconnect: (.*)/ ||
$@ =~ /\b(Bad hostname)\b/ ||
$@ =~ /\b(certificate verify failed)\b/ ||
$@ =~ /\b(Crypt-SSLeay can't verify hostnames)\b/
) {
$status .= " ($1)";
}
die "$status\n\n$@";
}
# perl 5.005's IO::Socket does not have the blocking method.
eval { $sock->blocking(0); };
$sock;
}
Supongo que lo que estoy buscando aquí es una de dos cosas.
Ya sea: (A) ¿Existe una forma nueva/mejor/más correcta de hacer que Perl ignore los certificados SSL? o (B) ¿Existe alguna forma de importar un certificado SSL autofirmado desde otro host a Ubuntu para que el script Perl lo reconozca y confíe en él? Alternativamente: (B-2) ¿Existe alguna manera de hacer que Ubuntu reconozca la autoridad de certificación del directorio activo de Windows de modo que pueda emitir certificados SSL desde mi CA a los sistemas en cuestión y que los scripts de Perl los reconozcan?
¡Gracias de antemano a todos!
Respuesta1
$ENV{PERL_LWP_SSL_VERIFY_HOSTNAME} = 0
Se trataba de un error en LWP (CVE-2014-3230) que se solucionó en versiones más recientes. PERL_LWP_SSL_VERIFY_HOSTNAME solo se usa para omitir la verificación del nombre de host en el certificado, no de la cadena de certificados. Pero, debido a que está utilizando una cadena de certificados autofirmados, la verificación fallará.
Esta opción solo se introdujo para la migración del antiguo backend Crypt::SSLeay al nuevo backend IO::Socket::SSL. Crypt::SSLeay no admite la verificación del nombre de host (y por lo tanto está abierto a ataques de intermediario), mientras que IO::Socket::SSL sí lo hace. Con LWP versión 6, el backend predeterminado es IO::Socket::SSL.
Para deshabilitar completamente la verificación del conjunto de certificados SSL_verify_mode => SSL_VERIFY_NONE(debe use IO::Socket::SSLtener acceso a la constante SSL_VERIFY_NONE, o simplemente usar 0) en ssl_opts de LWP. No existe ninguna variable de entorno para hacer esto.
Ejemplo:
use LWP::UserAgent;
use IO::Socket::SSL;
my $ua = LWP::UserAgent->new(..., ssl_opts => { SSL_verify_mode => SSL_VERIFY_NONE });
$ua->get(...); # or $ua->post(...) or $ua->request(...)
Lamentablemente, no veo ningún uso de LWP en el script al que hizo referencia, por lo que no veo dónde solucionarlo.
En cuanto a sus opciones B:
(B) ¿Existe alguna forma de importar un certificado SSL autofirmado desde otro host a Ubuntu para que el script Perl lo reconozca y confíe en él? Alternativamente: (B-2) ¿Existe alguna manera de hacer que Ubuntu reconozca la autoridad de certificación del directorio activo de Windows de modo que pueda emitir certificados SSL desde mi CA a los sistemas en cuestión y que los scripts de Perl los reconozcan?
Debería poder utilizar la variable de entorno PERL_LWP_SSL_CA_FILE para especificar un archivo qué CA o certificados autofirmados acepta como confiables.
Respuesta2
Creo que es un problema de la versión de Perl, verifique qué versión de Perl usó anteriormente para ejecutar ese script.
De lo que estoy seguro es que Ubuntu instala la última versión estable de cada software. Tomemos, por ejemplo, si tiene un script python3 que se ejecuta en ubuntu 12.04, es posible que no funcione en ubuntu 14.04, y la razón es que el primero tiene python 3.2, cuando el último tiene la versión python 3.4.
Supongo que le sucederá lo mismo al script de Perl, verifique la versión de Perl y la nota de lanzamiento de la nueva versión.