recuerden que es una vulnerabilidad mas del lado del cliente, y que para
explotarla se requieren dos acciones, aún así es recomendable des habilitar
el soporte de SSLv3

Aquí se dan cuenta si son vulnerables https://www.poodletest.com/

Por acá hay una información que me gusto
http://linux-audit.com/protect-linux-systems-against-sslv3-poodle-vulnerability/

http://www.globbtv.com/4355/noticias/poodle--vulnerabilidad-en-ssl-30-como-nos-afecta-y-posibles-soluciones

Finalmente mas que una vulnerabilidad de sistema operativo es una
vulnerabilidad de navegador, la solución es deshabilitar el soporte para
ese protocolo en el navegador.

Ahora desde el lado del servidor también se puede deshabilitar y así
proteger los usuarios.


Si me equivoco en algo o falta algo me ayudan por favor.


gracias.

El 16 de octubre de 2014, 19:10, Oscar Fabian <[email protected]>
escribió:

> testing...
>
> El 16 de octubre de 2014, 17:26, Jhosman Lizarazo - Ubuntu Colombia <
> [email protected]> escribió:
>
> > En el sitio web de RedHat encontré un script para que veamos si somos
> > vulnerables o no (aplica sobre todo a servidores, no tanto al usuario
> > final, pero puede pasar)
> >
> > Copiar y pegar en un documento.sh
> >
> > #!/bin/bash
> > ret=$(echo Q | timeout 5 openssl s_client -connect
> > "${1-`hostname`}:${2-443}" -ssl3 2> /dev/null)
> > if echo "${ret}" | grep -q 'Protocol.*SSLv3'; then
> >   if echo "${ret}" | grep -q 'Cipher.*0000'; then
> >     echo "SSLv3 disabled"
> >   else
> >     echo "SSLv3 enabled"
> >  fi
> > else
> >   echo "SSL disabled or other error"
> > fi
> >
> >
> > Guardar y dar permisos de ejecución, luego correr el script y ver los
> > resultados, si el SSLv3 está habilitado se debe actuar.
> >
> > El 16 de octubre de 2014, 16:58, Oscar Fabian<[email protected]>
> > escribió:
> >
> > > ham se publico esta mañana en facebook link oficial de la falla
> > > https://www.openssl.org/~bodo/ssl-poodle.pdf
> > >
> > > interesante que se esta diciendo que la falla mata a SSL v3 y piden
> > migrar
> > > a TLS
> > >
> > > El 16 de octubre de 2014, 16:51, Jhosman Lizarazo - Ubuntu Colombia <
> > > [email protected]> escribió:
> > >
> > > >  La vulnerabilidad CANICHE es una debilidad en la versión 3 del
> > protocolo
> > > > SSL que permite a un atacante en un contexto-man-in-the-middle de
> > > descifrar
> > > > el contenido de texto sin formato de un mensaje cifrado SSLv3.
> > > >
> > > > Mas información en:
> > > >
> > http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-3566.html
> > > >
> > > >
> > > > *¿Quién está afectado por esta vulnerabilidad? *
> > > > Esta vulnerabilidad afecta a cada pieza de software que puede ser
> > > > coaccionado para comunicarse con SSLv3. Esto significa que cualquier
> > > > software que implementa un mecanismo de reserva que incluye soporte
> > SSLv3
> > > > es vulnerable y puede ser explotado.Algunas piezas comunes de
> software
> > > que
> > > > pueden ser afectados son los navegadores web, servidores web,
> > servidores
> > > > VPN, servidores de correo, etc-
> > > >
> > > > *¿Cómo funciona?*
> > > >
> > > > En resumen, la vulnerabilidad existe CANICHE porque el protocolo
> SSLv3
> > no
> > > > comprueba adecuadamente los bytes de relleno que se envían con
> mensajes
> > > > cifrados.Puesto que éstos no pueden ser verificados por la parte
> > > receptora,
> > > > un atacante puede sustituir a estos y pasarlos al destino previsto.
> > > Cuando
> > > > se hace de una manera específica, la carga útil modificada
> > potencialmente
> > > > será aceptado por el receptor sin queja.
> > > >
> > > > Un promedio de una vez de cada 256 solicitudes será aceptado en el
> > > destino,
> > > > lo que permite al atacante descifrar un solo byte. Esto se puede
> > repetir
> > > > fácilmente con el fin de descifrar progresivamente bytes adicionales.
> > > > Cualquier atacante capaz de forzar repetidamente un participante para
> > > > volver a enviar los datos mediante este protocolo puede romper el
> > cifrado
> > > > en un lapso muy corto de tiempo.
> > > >
> > > > *¿Cómo puedo protegerme?*
> > > >
> > > > Deberían tomarse medidas para asegurarse de que usted no es
> vulnerable
> > en
> > > > sus papeles como un cliente y un servidor. Desde encriptación
> > normalmente
> > > > se negocia entre clientes y servidores, es un tema que involucra a
> > ambas
> > > > partes.Los servidores y los clientes deben deben tomar medidas para
> > > > desactivar el soporte SSLv3 completamente.
> > > >
> > > > Muchas aplicaciones utilizan mejor encriptación por defecto, pero
> > > > implementan soporte SSLv3 como una opción de reserva. Esto se debe
> > > > desactivar, como un usuario malicioso puede forzar la comunicación
> > SSLv3
> > > si
> > > > ambos participantes lo permiten como un método aceptable.
> > > >
> > > > *Cómo proteger aplicaciones comunes*
> > > >
> > > > A continuación, vamos a cubrir cómo deshabilitar SSLv3 en algunas
> > > > aplicaciones de servidor comunes. Tenga cuidado al evaluar sus
> > servidores
> > > > para proteger a los servicios adicionales que pueden confiar en el
> > > cifrado
> > > > SSL / TCP.
> > > >
> > > > Debido a la vulnerabilidad CANICHE no representa un problema de
> > > aplicación
> > > > y es un problema inherente con todo el protocolo, no hay ninguna
> > > solución y
> > > > la única solución fiable es no usarlo.
> > > > Nginx servidor Web
> > > >
> > > > Para desactivar SSLv3 en el servidor web Nginx, puede utilizar el
> > > > ssl_protocols Directiva. Esto se encuentra en los server o http
> bloques
> > > en
> > > > su configuración.
> > > >
> > > > Por ejemplo, en Ubuntu, puede agregar esta a nivel mundial para
> > > > /etc/nginx/nginx.conf interior del http bloque, o para cada server
> > bloque
> > > > en el /etc/nginx/sites-enabled directorio.
> > > >
> > > >  sudo nano /etc/nginx/nginx.conf
> > > >
> > > > *Para desactivar SSLv3, su ssl_protocols directiva debe establecerse
> > > así:*
> > > >
> > > >  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
> > > >
> > > > Debe reiniciar el servidor después de haber hecho la modificación
> > > anterior:
> > > >
> > > >  sudo service nginx restart
> > > >
> > > > *Apache Web Server*
> > > >
> > > > Para desactivar SSLv3 en el servidor web Apache, usted tendrá que
> > ajustar
> > > > el SSLProtocol directiva proporcionada por el mod_ssl módulo.
> > > >
> > > > Esta directiva se puede establecer en el nivel de servidor o en una
> > > > configuración de host virtual. Dependiendo de la configuración de su
> > > > distribución de Apache, la configuración SSL se puede situar en un
> > > archivo
> > > > independiente que proviene.
> > > >
> > > > En Ubuntu, la especificación a nivel de servidor para los servidores
> se
> > > > puede ajustar mediante la edición del
> > > /etc/apache2/mods-available/ssl.conf
> > > > archivo. Si mod_ssl está habilitada, un enlace simbólico se conectará
> > > este
> > > > archivo al mods-enabled subdirectorio:
> > > >
> > > >  sudo nano /etc/apache2/mods-available/ssl.conf
> > > >
> > > > *En CentOS*, puede puede ajustar esto en el archivo de configuración
> > SSL
> > > se
> > > > encuentra aquí (si SSL está habilitado):
> > > >
> > > >  sudo nano /etc/httpd/conf.d/ssl.conf
> > > >
> > > > En el interior se encuentra el SSLProtocol Directiva. Si esto no está
> > > > disponible, lo crea. Modifique esto para eliminar explícitamente el
> > > apoyo a
> > > > SSLv3:
> > > >
> > > >  SSLProtocol all -SSLv3 -SSLv2
> > > >
> > > > Guarde y cierre el archivo. Reinicie el servicio para permitir los
> > > cambios.
> > > >
> > > > En Ubuntu, puede escribir:
> > > >
> > > >  sudo service apache2 restart
> > > >
> > > > En CentOS, esto sería:
> > > >
> > > >  sudo service httpd restart
> > > >
> > > > *HAProxy equilibrador de carga*
> > > >
> > > > Para desactivar SSLv3 en un equilibrador de carga HAProxy, tendrá que
> > > abrir
> > > > el haproxy.cfg archivo.
> > > >
> > > > Esta se encuentra en /etc/haproxy/haproxy.cfg :
> > > >
> > > >  sudo nano /etc/haproxy/haproxy.cfg
> > > >
> > > > En la configuración de su extremo delantero, si ha habilitado SSL, tu
> > > bind
> > > > Directiva especificará la dirección IP pública y el puerto. Si está
> > > > utilizando SSL, tendrá que añadir no-sslv3 hasta el final de esta
> > línea:
> > > >
> > > >  frontend name bind public_ip :443 ssl crt /path/to/certs no-sslv3
> > > >
> > > > Guarde y cierre el archivo.
> > > >
> > > > Tendrá que reiniciar el servicio para aplicar los cambios:
> > > >
> > > >  sudo service haproxy restart
> > > >
> > > > *OpenVPN servidor VPN*
> > > >
> > > > Las versiones recientes de OpenVPN en realidad no permiten SSLv3. El
> > > > servicio no es vulnerable a este problema específico, por lo que no
> > > tendrá
> > > > que ajustar su configuración.
> > > >
> > > > Ver este post en los foros de OpenVPN para más información .
> > > > Postfix SMTP del servidor https://forums.openvpn.net/topic17268.html
> > > >
> > > > Si la configuración de Postfix está configurado para requerir el
> > cifrado,
> > > > se utilizará una directiva llamada smtpd_tls_mandatory_protocols .
> > > >
> > > > Usted puede encontrar esto en el archivo principal de configuración
> de
> > > > Postfix:
> > > >
> > > >  sudo nano /etc/postfix/main.cf
> > > >
> > > > Para un servidor Postfix configurado para utilizar cifrado en todo
> > > momento,
> > > > puede asegurarse de que SSLv3 y SSLv2 no son aceptadas por el
> > > > establecimiento de este parámetro. Si no forzar el cifrado, usted no
> > > tiene
> > > > que hacer nada:
> > > >
> > > >  smtpd_tls_mandatory_protocols=!SSLv2, !SSLv3
> > > >
> > > > Guarde la configuración. Reinicie el servicio para implementar los
> > > cambios:
> > > >
> > > >  sudo service postfix restart
> > > >
> > > > *Dovecot IMAP y POP3 Servidor*
> > > >
> > > > Para desactivar SSLv3 en un servidor Dovecot, usted tendrá que
> ajustar
> > > > directiva llamados ssl_protocols . Dependiendo de sus métodos de
> > > > distribución de envasado, las configuraciones SSL se pueden mantener
> en
> > > un
> > > > archivo de configuración alternativa.
> > > >
> > > > Para la mayoría de las distribuciones, puede ajustar esta directiva
> > > > mediante la apertura de este archivo:
> > > >
> > > >  sudo nano /etc/dovecot/conf.d/10-ssl.conf
> > > >
> > > > En el interior, establecer el ssl_protocols directiva para
> deshabilitar
> > > > SSLv2 y SSLv3:
> > > >
> > > >  ssl_protocols = !SSLv3 !SSLv2
> > > >
> > > > Guarde y cierre el archivo.
> > > >
> > > > Reinicie el servicio con el fin de aplicar los cambios:
> > > >
> > > >  sudo service dovecot restart
> > > >
> > > > *Medidas adicionales*
> > > >
> > > > Junto con las aplicaciones del lado del servidor, también debe
> > actualizar
> > > > las aplicaciones cliente.
> > > >
> > > > En particular, los navegadores web pueden ser vulnerables a este
> > > problema a
> > > > causa de su negociación del protocolo de bajada. Asegúrese de que sus
> > > > navegadores no permiten SSLv3 como un método de cifrado aceptable.
> Esto
> > > > puede ser ajustable en la configuración o mediante la instalación de
> un
> > > > plugin o extensión adicional.
> > > > Conclusión
> > > >
> > > > Debido al amplio apoyo SSLv3, incluso cuando el cifrado fuerte está
> > > > habilitada, esta vulnerabilidad es de gran alcance y peligroso. Usted
> > > > tendrá que tomar medidas para protegerse a sí mismo tanto como un
> > > > consumidor y el proveedor de los recursos que utilizan cifrado SSL.
> > > >
> > > > Asegúrese de revisar todos sus servicios de redes accesibles que
> pueden
> > > > aprovechar SSL / TLS en cualquier forma. A menudo, estas aplicaciones
> > > > requieren instrucciones explícitas para desactivar por completo las
> > > formas
> > > > más débiles de cifrado como SSLv3.
> > > >
> > > > --
> > > > Cordialmente.
> > > >
> > > >
> > > >
> > > > Jhosman Lizarazo
> > > > https://launchpad.net/~jhosman
> > > > --
> > > > Al escribir recuerde observar la etiqueta (normas) de esta lista:
> > > > http://goo.gl/Pu0ke
> > > > Para cambiar su inscripción, vaya a "Cambio de opciones" en
> > > > http://goo.gl/Nevnx
> > > >
> > >
> > >
> > >
> > > --
> > >
> > >         .---.        .-----------  Cordialmente.
> > >        /     \  __  /    ------   #Oscar Fabian Prieto Gonzalez
> > >       / /     \(  )/    -----     #Tecnico en Sistemas
> > >      //////   ' \/ `   ---        #GNU/user
> > >     //// / // :    : ---          #www.ofprieto.blogspot.com
> > >    // /   /  /`    '--
> > >   //          //..\\
> > > =============UU====UU====
> > >              '//||\\`
> > >                ''``
> > > --
> > > Al escribir recuerde observar la etiqueta (normas) de esta lista:
> > > http://goo.gl/Pu0ke
> > > Para cambiar su inscripción, vaya a "Cambio de opciones" en
> > > http://goo.gl/Nevnx
> > >
> >
> >
> >
> > --
> > Cordialmente.
> >
> >
> >
> > Jhosman Lizarazo
> > https://launchpad.net/~jhosman
> > --
> > Al escribir recuerde observar la etiqueta (normas) de esta lista:
> > http://goo.gl/Pu0ke
> > Para cambiar su inscripción, vaya a "Cambio de opciones" en
> > http://goo.gl/Nevnx
> >
>
>
>
> --
>
>         .---.        .-----------  Cordialmente.
>        /     \  __  /    ------   #Oscar Fabian Prieto Gonzalez
>       / /     \(  )/    -----     #Tecnico en Sistemas
>      //////   ' \/ `   ---        #GNU/user
>     //// / // :    : ---          #www.ofprieto.blogspot.com
>    // /   /  /`    '--
>   //          //..\\
> =============UU====UU====
>              '//||\\`
>                ''``
> --
> Al escribir recuerde observar la etiqueta (normas) de esta lista:
> http://goo.gl/Pu0ke
> Para cambiar su inscripción, vaya a "Cambio de opciones" en
> http://goo.gl/Nevnx
>



-- 


Twitter: @Fercho_Giraldo @Medellinlibre
*GNU/LINUX USER # 553303*
There is a difference between knowing the path and walking the path
-- 
Al escribir recuerde observar la etiqueta (normas) de esta lista: 
http://goo.gl/Pu0ke
Para cambiar su inscripción, vaya a "Cambio de opciones" en http://goo.gl/Nevnx

Responder a