Seguridad

Tipos de certificados de Seguridad SSL

¿Qué permite un certificado SSL? Los certificados de seguridad permiten que la información que viaje entre los extremos (servidor – cliente) se encuentre cifrada, esto se consigue a través del intercambio de una clave pública entre el navegador del cliente y el servidor, y la fuerza del cifrado dependerá del algoritmo utilizado por el certificado.

Sabremos que nuestra conexión se encuentra cifrada cuando accedamos a la página web a través de https, y el certificado se encuentre validado por la empresa certificadora (GeoTrust, Symantec,…). En la barra de direcciones de nuestro navegador deberá aparecer un candado junto al nombre del dominio o con recuadros en verde con el nombre de la empresa asociada al dominio y/o certificado.

nerion_https

Algunas de las ventajas de usar certificados de seguridad para nuestros sitios web son:

  • Aumento de la seguridad, ya que la información irá encriptada.
  • Aumento de la confianza, las personas que visiten tu página web se sentirán más seguras si saben que el envío de datos por la red se encuentran encriptados y puede traducirse en un aumento de ventas.
  • Garantizar la identidad de la empresa u organización
  • Eliminación de malware, ya que se escanea la web en busca de código dañino (dependiendo del certificado).
  • Mejora el posicionamiento.

Hay diferentes certificados en el mercado, habrá que seleccionar el más apropiado dependiendo del uso que tenga el sitio web, de si únicamente es para un dominio o para varios, etc…

Según el número de dominios que certifica:

Certificados de Dominio Único

Los certificados de dominio único te permiten añadir seguridad SSL a un único dominio, por este motivo suelen tener un precio más ajustado que los certificados de otro tipo. Si únicamente dispones de un proyecto web en el que deseas asociarle un certificado de seguridad esta será tu mejor opción.  Algunos ejemplos de certificados de este tipo son:

  • RapidSSL
  • Thawte SSL 123
  • GeoTrust True BusinessID

Certificados Multidominio (SAN)

Se pueden certificar varios dominios con un mismo certificado SSL, esta sería la forma más facil de certificar varios dominios. El precio de este tipo de certificados es mayor que el de certificado de dominio único, pero es más barato que comprar un certificado para cada dominio. Disponemos de los siguientes certificados de tipo SAN:

  • GeoTrust True BusinessID SAN
  • GeoTrust True BusinessID EV Multi-Domain

Certificados WildCard

Este tipo de certificado nos da la posibilidad de asociar un único certificado al dominio y sus subdominios.

  • GeoTrust True BusinessID Wildcard
  • RapidSSL Wildcard

Los certificados también pueden ser divididos según el tipo de validación, es decir, según el proceso que debe de seguir la persona o empresa que solicita el certificado para que se lo faciliten.

Certificados de Seguridad SSL

Según el tipo de validación:

Validación por dominio:

Este tipo de validación es la más sencilla, la más rápida, podrás disponer de tu certificado en pocos minutos, y normalmente va asociada a los certificados más baratos. Esta verificación se realiza a través de un correo electrónico que se enviará al email que aparece en el whois con un enlace para su confirmación.

Hay que tener en cuenta que los dominios que se encuentran con whois privado deberán desactivar el servicio de privacidad temporalmente hasta que se complete la verificación.

Estos son algunos de los certificados que tienen este tipo de validación:

  • RapidSSL Standard
  • RapidSSL Wildcard
  • Thawte SSL 123

Validación por empresa:

Este tipo de validación precisa de datos adicionales para completar su emisión. El primer paso será confirmar el certificado a través del correo electrónico que enviarán a la cuenta de correo del whois, posteriormente la empresa solicitante deberá de presentar el Documento de incorporación de la empresa (CIF) o la licencia de apertura, y por último una vez se hayan realizado los dos anteriores pasos la entidad encargada de la emisión del certificado se pondrá en contacto con la empresa solicitante a través de una llamada telefónica.

Importante: El número de teléfono de la empresa debe aparecer en alguna base de datos pública (como páginas amarillas).

A continuación se indican algunos certificados que requieren este tipo de validación:

  • GeoTrust True BusinessID
  • GeoTrust True BusinessID SAN
  • GeoTrust True BusinessID Wildcard

Validación extendida:

La Validación Extendida (EV) es la verificación más completa de las disponibles, pues además de validar el dominio y la empresa, se debe de enviar documentos adicionales que nos facilitarán desde la empresa certificadora.

Se recomienda este tipo de certificados SSL a tiendas online y empresas que cuentan con compras integradas en su sitio web. Este tipo de certificado se reconoce por la barra verde que aparece en la barra de direcciones, es el signo más visible y por lo tanto aumentará la confianza de tus clientes a la hora de introducir datos sensibles en tu sitio.

Estos son algunos de los certificados con este tipo de validación:

  • GeoTrust True BusinessID EV
  • GeoTrust True BusinessID EV Multi-Domain

Si estás interesado en contratar uno de estos certificados no dudes en ponerte en contacto con nosotros, si quieres conocer más a fondo las características echa un vistazo a nuestro catálogo de certificados de seguridad.

Vulnerabilidad Crítica en WordPress que afecta a 10 millones de sitios web

Actualización de Seguridad - WordPress 4.0.1

Ha sido detectada una vulnerabilidad crítica en WordPress que afecta principalmente a la versión 3 del sistema de gestión de contenidos. La empresa que ha localizado la vulnerabilidad, Klikki Oy, alerta que está activa hasta la versión 3.9.2. Según las estadísticas de WordPresss, alrededor de un 86% de los sitios web con WordPress utilizan una versión vulnerable. Se estima que el número total de WordPress instalados a día de hoy supera los 10 millones.

La vulnerabilidad se ha encontrado activa en los últimos 4 años, en concreto desde el lanzamiento de la versión 3.0 de WordPress. La versión 4.0. liberada en Septiembre de este año, no es vulnerable.

¿En qué consiste la vulnerabilidad?

Para aprovecharse del error, el atacante sólo necesita que exista un campo de texto, tal como el formulario de introducción de comentarios que se encuentra habilitado por defecto.

De esta forma el atacante podría aprovechar esta vulnerabilidad mediante la introducción de comentarios sin la necesidad de loguearse como administrador. El código inyectado en forma de comentario podría ser ejecutado por el navegador web del administrador al leerlo. Es en ese momento cuando el código se activa y comienza a realizar operaciones con permisos administrador. Estas operaciones incluyen acciones tales como: cambio de contraseña de la cuenta administrador, creación de nuevas cuentas, y en el caso más grave puede afectar al servidor inyectando código PHP en él.

Os recomendamos encarecidamente que actualicéis vuestro WordPress a esta última versión estable, ya que además de introducir mejoras y nuevas funcionalidades, se corrigen fallos de seguridad como éste. Así mismo si utilizáis otros CMS también es recomendable estar al día de las actualizaciones estables.

Aspectos Técnicos

Una función desconocida del archivo wp-includes/formatting.php del componente Comment Handler es afectada por esta vulnerabilidad. El problema ocurre en una función de manipulación de texto llamada wptexturize(), que habitualmente es ejecutada para cada comentario y otros bloques de texto. La función reemplaza ciertos caracteres con entidades utilizadas en HTML. Por ejemplo, los símbolos de comillas rectas son reemplazadas por comillas en cursiva (unicode 8220 y 8221 respectivamente). El problema está en que la manipulación no se hace de forma correcta causando un agujero de seguridad de clase cross site scripting. Concretamente la vulnerabilidad se encuentra en esta parte del código:

$textarr = preg_split('/(<.*>|[.*])/Us', $text, -1, PREG_SPLIT_DELIM_CAPTURE);

Una actualización a la versión 4.0.1 elimina esta vulnerabilidad. Para aquellos que no puedan realizar una actualización de la versión de WordPress, por ejemplo por incompatiblidad en el tema o plugins instalados, ha sido publicada inmediatamente después de descubrir esta brecha de seguridad. La vulnerabilidad se tratará con las siguientes líneas de código:

function wptexturize($text) {
    return $text; // ADD THIS LINE
    global $wp_cockneyreplace;

Más información técnica del exploit: http://klikki.fi/adv/wordpress.html

Poodle, un nuevo golpe al modelo de seguridad SSL

Tres investigadores de Google han descubierto recientemente un bug en el protocolo de criptografía SSL 3.0 (SSLv3 – Secure Sockets Layer). El bug, conocido como Poodle (CVE-2014-3566) podría ser utilizado por alguien externo para interceptar datos. Estos datos supuestamente deberían estar encriptados por el protocolo HTTPS durante la comunicación entre los usuarios y los servicios webs a los que acceden.

Según los investigadores, no es una vulnerabilidad en la implementación de los protocolos SSL/TLS, sino una vulnerabilidad en el diseño del protocolo SSLv3 a la hora de utilizar bloques cifrados. Tampoco es un defecto en el modelo clave pública/privada utilizado por los certificados SSL, por lo que los usuarios con certificados instalados en sus servidores no tendrán que reemplazarlos.

Se cree que el bug no es un fallo tan grave como Heartbleed, que afectó a OpenSSL y se detectó en abril de este año. En el fallo Poodle, los atacantes necesitan tener una posición de privilegio en la red para poder hacer el exploit. Sin embargo, la utilización extendida de Hotspots o wifis públicas si que hacen este ataque un problema real.

Tanto los usuarios como los administradores de servidores tienen que realizar cambios en sus equipos de tal forma que no se utilice el protocolo SSLv3 en las comunicaciones.

Usuario final

El usuario debe comprobar que el protocolo SSL 3.0 está deshabilitado en su navegador. En este enlace se puede ver como desactivar el protocolo SSLv3 en distintos navegadores.

Firefox ya ha comunicado que en próximas versiones desactivará la utilización de este protocolo:

https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/

Por último recomendamos que estemos atentos durante estos días a la recepción de correos de phising que nos soliciten cambiar nuestras credenciales. En ningún caso deberemos acceder a estos sitios web falsos que intentarán conseguir nuestros datos de acceso.

Administradores de Servidores

En estas web podremos consultar si nuestro servicio es vulnerable o no a Poodle:

https://www.tinfoilsecurity.com/poodle

https://www.ssllabs.com/ssltest/index.html

A continuación indicamos como solucionar el bug Poodle en diferentes entornos:

RedHat/CentOS

Si administramos un servidor con sistema operativo RedHat/CentOS, desde RedHat ya se ha publicado una versión actualizada del software OpenSSL. Esta actualización realmente no soluciona el bug, sino que utiliza la opción TLS_FALLBACK_SCSV, un mecanismo que previene a los atacantes a forzar a los navegadores a utilizar SSL 3.0.

Para actualizar OpenSSL ejecutaremos:

yum update openssl

Más información: wiki.centos.org/Security/POODLE

 

Windows

Poodle está presente en todas las versiones de windows 2003, 2008 y 2012, independientemente de si tenemos una versión 32 o 64bit. La solución a adoptar es deshabilitar los protocolos SSL v2.0 y v3.0.

Este cambio se deber hacer modificando el registro, lo cual se debe hacer con cuidado. En este enlace de Microsoft se indica como hacer este cambio:  http://support.microsoft.com/kb/187498.

Una vez realizado el cambio, deberemos reiniciar nuestro servidor para que los cambios se confirmen.

 

Apache

En el caso de que administremos un servidor web, probablemente utilicemos un servidor Apache con mod_ssl, editaremos el fichero de configuración correspondiente deshabilitando los protocolos SSLv3:

  1. Opción 1: deshabilitar SSLv2 y SSLv3 (habilitar todo menos SSLv2 y SSLv3):
    SSLProtocol All -SSLv2 -SSLv3
  2. Opción 2: deshabilitar todo excepto TLSv1. Indicaremos una de estas dos líneas según la versión de RedHat/CentOS que tengamos. Normalmente será la segunda línea de las que indicamos a continuación:
    SSLProtocol -All +TLSv1 +TLSv1.1 +TLSv1.2
    SSLProtocol -All +TLSv1

Una vez hechos los cambios reiniciaremos el servicio apache. En un servidor CentOS, el fichero de configuración de mod_ssl se encuentra en /etc/httpd/conf.d/ssl.conf

Más información: https://access.redhat.com/solutions/1232413

 

Nginx

Otro servidor web que va ganando adeptos es Nginx. Si queremos proteger nuestro servidor web Nginx frente a Poodle tendremos que hacer una configuración similar a Apache, deshabilitando el protocolo SSLv3:

ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;  # don’t use SSLv3 ref: POODLE

cPanel

cPanel es un panel de gestión que nos permite administrar de forma completa nuestro servidor mediante un entorno web. Si tenemos un servidor cPanel, seguramente utilicemos como servidor web Apache, como servidor POP3/IMAP Dovecot y como servidor SMTP Exim. A continuación indicamos como proteger a nuestro servidor para estos tres elementos:

Apache (HTTP/HTTPS):

  1. Accedemos al administrador WHM / Service Configuration / Apache Configuration / Include Editor / Pre Main Include.
  2. Elegimos como versión, todas las versiones
  3. Añadimos el siguiente código en la caja de texto que aparece:
    SSLHonorCipherOrder On
    SSLProtocol -All +TLSv1
  4. Pulsamos el botón de actualizar para reiniciar el servidor Apache.

 

Dovecot (POP3/IMAP):

  1. Accedemos al administrador WHM / Service Configuration / Mailserver Configuration
  2. Cambiamos la casilla nombrada como SSL Cipher List a:
    ALL:-SSLv3:RC4:-SSLv2:!ADH:+HIGH:+MEDIUM:-LOW:-EXP

Exim (SMTP):

  1. Accedemos al administrador WHM / Service Configuration / Exim Configuration Manager / Advanced Editor
  2. Cambiamos la casilla nombrada como tls_require_ciphers a:
    ALL:-SSLv3:RC4:-SSLv2:!ADH:+HIGH:+MEDIUM:-LOW:-EXP

Otras plataformas

RedHat ha publicado diferentes páginas donde se indica como proteger nuestros servidores frente a la vulnerabilidad Poodle:

  1. Tomcat/Jboss: https://access.redhat.com/solutions/1232233
  2. vsftpd: https://access.redhat.com/solutions/1234773
  3. Otros servicios: https://access.redhat.com/articles/1232123

 

Descubierta vulneralidad Bash (GNU/Linux/Unix) – Shellshock

Bash es el interprete de comandos de la mayoria de sistemas GNU/Linux/Unix. La vulnerabilidad, denominada CVE-2014-6271 (Shellshock), ha sido descubierta por Stéphane Chazelas, y permite la ejecución de código malicioso, con lo que se podría conseguir el control del sistema.

bash-500x375

El error se encuentra en como Bash trabaja con las variables de entorno, y permite la ejecución de cualquier código añadiendolo al final de una línea de ejecución Bash dentro de las variables de entorno.

La mayoría de servidores web LAMP ejecutan PHP como CGI (normalmente mediante FCGI o FastCGI). Dependiendo de la configuración del servidor, las páginas PHP en modo CGI se ejecutan a través del intérprete Bash. De este modo, esta vulnerabilidad pone en riesgo la seguridad del sistema que aloja tus páginas web, p0r lo que recomendamos la actualización urgente de tu interprete Bash desactualizado.

¿Cómo detectar si mi servidor es vulnerable?

Para detectar si tu servidor tiene una versión de bash vulnerable a este fallo de seguridad, puedes conectarte a tu servidor por SSH y ejecutar:

env x='() { :;}; echo Vulnerable' bash -c /bin/true

Si es vulnerable la salida estándar de este comando te devolverá la palabra ‘Vulnerable’

Si no es vulnerable no te devolverá nada.

¿Cómo resolver la vulnerabilidad Shellshock?

Muchas distribuciones de Linux como Ubuntu, Red Hat y CentOS ya disponen de parches que impiden la ejecución de código después del final de una función Bash.

En caso de tener que actualizar el bash de tu servidor Cloud con sistema Red Hat/CentOS es necesario escribir el siguiente comando en el sistema:

yum update bash

En caso de tener que actualizar el bash de tu servidor Cloud con Ubuntu o Debian 7 es necesario escribir el siguiente comando en el sistema:

sudo apt-get update && sudo apt-get upgrade bash

Si tu servidor tiene instalada una distribución Debian 6, es necesario añadir un repositorio adicional a tu fichero /etc/apt/sources.list y ejecutar el comando de Ubuntu/Debian 7:

  • Editar el archivo /etc/apt/sources.list
  • Agregar la siguiente linea al final del fichero: deb http://ftp.us.debian.org/debian squeeze-lts main non-free contrib
  • Una vez agregado el repositorio ejecutar sudo apt-get update && sudo apt-get upgrade bash
  • Borrar la línea agregada al fichero /etc/apt/sources.list

¿Servidor Cloud o Hosting Compartido?

¿Qué necesito contratar para que mi aplicación web funcione sin problemas, un servidor cloud o un plan de hosting compartido? ¿Qué me sale mejor en relación calidad/precio? Estas pueden ser las preguntas que se formulan las personas que vayan a comenzar a trabajar en la red ya sea para montar un CMS, una aplicación web, una tienda virtual, etc…En este artículo analizaremos y compararemos ambos servicios e intentaremos responder a estas preguntas.

cloud - hosting

Para realizar una comparación de ambos servicios deberemos comenzar con el análisis de las siguientes características:

  • Rendimiento
  • Límites
  • Gestión
  • Precio

Rendimiento

Hay que tener en cuenta que si comparamos en rendimiento un servidor cloud con uno compartido, el servidor dedicado responderá con mayor velocidad a las peticiones de los usuarios. Esto no significa  que las características del servidor compartido sean menores que las del servidor cloud, pero obviamente en el servidor compartido no seremos los únicos que vayamos a utilizar los recursos de la máquina y esto podría provocar una respuesta más baja que la que nos podría proporcionar el servidor dedicado.

Entonces, ¿Debo de contratar un servidor cloud para que funcione bien mi página web?

No, si acabas de empezar con tu negocio o página y no esperas tener muchas visitas al principio, lo más fácil y económico es que contrates un hosting en un servidor compartido. El servidor cloud estaría pensado para aplicaciones que consuman más recursos, como por ejemplo Magento o para páginas que tengan un alto número de visitas al día.

Si necesitamos un rendimiento alto nos veremos obligados a contratar un servidor cloud ya que en el podemos optimizar los recursos como nosotros queramos y sabremos que nadie más los va a usar.

Límites

Las limitaciones que nos encontraremos en un servidor compartido serán mayores que en un servidor cloud.

Por ejemplo, los planes de alojamiento compartido tienen un límite de transferencias que si se rebasa podría traer como consecuencia un recargo en la factura del servicio contratado, en un servidor cloud los límites de transferencia son más elevados.

Otras de las limitaciones a tener en cuenta serían las de espacio en disco, aunque los planes de hosting pueden llegar a tener la misma cuota de disco que un servidor cloud. En nerion se adaptan las cuotas de espacio a las necesidades de cada cliente.

Gestión

Los alojamientos compartidos son gestionados por la propia empresa del hosting, pero se le concede al usuario un panel donde puede gestionar de forma bastante sencilla e intuitiva su sitio.

Por el contrario, los servidores cloud suelen ser administrados por los propios usuarios y es necesario tener experiencia para configurar correctamente los diferentes sitios o aplicaciones web que se vayan a alojar en él. En el caso de nerion, se pueden contratar servidores cloud administrados por nosotros con un límite de horas al mes de servicio administrado.

Precio

Obviamente el plan de alojamiento compartido va a ser más barato que el servidor cloud.

Hay que tener en cuenta que si esperas ganar dinero con tu negocio en Internet hace falta una inversión para que todo funcione correctamente, si no la haces podrías estar perdiendo clientes potenciales que decidan comprar en la competencia únicamente por la velocidad de respuesta de la página.

Bienvenido al blog de nerion

Empresa de servicios cloud, hosting y registro de dominios. Trust us, we take care of you!.
Suscripción a nerion
Siguenos en Twitter Siguenos en Facebook Siguenos en Linkedin Siguenos en YouTube Siguenos en Flickr Siguenos en Foursquare
Entradas antiguas por mes
Twitter
nerion en Facebook