Archivo de la categoría: Definiciones

Diferentes definiciones relativas a los sistemas de ciberseguridad

Podcast – 26 – Adware

Podcast: Reproducir en una nueva ventana | Descargar

Suscríbete: Spotify | RSS

En este capítulo hablaremos sobre la estrategia de algunos malware para conseguir beneficios económicos al mostrar publicidad a los usuarios: el adware.

Fuente imagen:PerfectYourPodcast

El adware puede ser una estrategia comercial en la que un desarrollador publica su software de forma gratuita a cambio de que el usuario vea anuncios mientras lo esté utilizando. Aquí el desarrollador espera tener un beneficio económico gracias a la visualización de dichos anuncios por parte del usuario de su programa. Este enfoque ha tenido una gran expansión en las aplicaciones móviles donde los usuarios puedes descargarse y usar las aplicaciones de forma gratuita mientras una porción de su pantalla muestra un anuncio o se ve un anuncio al arrancar o al cambiar de pantalla, etc. Así pues el adware como estrategia de comercialización no tiene implicaciones en el mundo de la seguridad informática.

Cuando hablamos de adware en seguridad informática nos referíamos a aquel software que muestra anuncios no previstos a los usuarios.

Hace una década, antes de la aparición de los smartphones el adware más habitual era uno que simplemente hacia aparecer una ventana emergente con un anuncio en nuestro pantalla. Por regla general solían incluir audio y la gran mayoría eran de contenido erótico o bien de portales de descargas. Era la principal fuente de ingresos de esas páginas de descarga de programas piratas que nadie se descargaba pero todo el mundo tenía. Así pues podríamos decir que la mayoría eran troyanos. Como el sistema anterior era muy visible, la mayoría de usuarios acabó instalándose un sistema antimalware y realizaba una limpieza de sus ordenadores por lo que la estrategia dejó de ser eficiente desde el punto de vista económico.

Adware. Fuente imagen: HowTouninstallMallware

Actualmente los sistemas de adware han evolucionado para que los usuarios no sepan que los tienen instalados y, por lo tanto, no los eliminen. Su operativa actual suele ser sustituir los anuncios que el usuario ve en una página web por los asociados al atacante. Así cuando accedemos a nuestro blog favorito (que sabemos que tiene publicidad) y vemos los anuncios no nos sorprendemos. Aquí el perjudicado no es el usuario final (que al fin y al cabo ve un anuncio donde espera que esté) sino el dueño de la página visitada que no contabiliza su anuncio sino el del atacante. Otra variante puede consistir en mostrar un anuncio no solicitado a pantalla completa al acceder a una página web: aquí el usuario se suele molestar con la página visitada pensando que «se pasa» con este tipo de anuncios cuando en realidad la web no tiene nada que ver y el responsable es el adware que tenemos instalado en nuestro terminal móvil.

Descarga directa.

Podcast – 22 – Certificados digitales

Podcast: Reproducir en una nueva ventana | Descargar

Suscríbete: Spotify | RSS

Los certificados de claves públicas X.509 nacieron como estándar de la Unión Internacional de Telecomunicaciones en 1988, si bien han ido evolucionando y actualmente la versión 3 se definió en 2008. La seguridad se basa en que una autoridad de certificación en la que confiamos (en realidad confia nuestro navegador), indica que la web a la que accedemos es la que dice ser (se evalúa el dominio) y por lo tanto se puede usar esta clave pública para cifrar la información de tal forma que sólo el servidor web pueda leer la información enviada.

Icono de certificado digital.
Fuente imagen:TuAsesorProfesional

Veamos los campos básicos de un certificado de dominio:

Identificador de versión. Los valores aceptables son 1, 2 y 3. En el caso del certificado de Securizando.com la versión es la 3.
Número de serie del certificado. Cada certificado emitido por una autoridad de certificación debe tener un número de serie único.
Identificador del algoritmo de firmado. En el caso del certificado del blog es algoritmo es SHA-256 con cifrado RSA.
Nombre del emisor. En el ejemplo el certificado de securizando.com está emitido por COMODO
Periodo de validez. Este campo se basa en dos fechas: la de inicio de validez y la de caducidad. En nuestro ejemplo el certificado es válido del 22 de diciembre de 2016 al 23 de diciembre de 2018.
Nombre del sujeto. Este campo identifica la identidad cuya clave pública está certificada. En nuestro ejemplo securizando.com
Información de clave pública del sujeto. Este campo contiene la clave pública, sus parámetros y el identificador del algoritmo con el que se emplea la clave.
Aquí aparecen algunos campos opcionales, si bien casi siempre se incluye la información de los protocolos CRL y OCSP que permiten confirmar que un certificado sea válido. Como estos protocolos no están estandarizados (aunque todas las autoridades de certificación los usen) no tienen un campo específico en el certificado y cae dentro de los opcionales
Firma del certificado. La autoridad de certificación firma todo el contenido del cifrado para demostrar que ha sido emitido por dicha CA y no ha sido modificado

Existen diferentes campos opcionales (declaración de políticas de la entidad certificadora, restricciones del certificado, etc.).

¿Cómo se usa el certificado X.509?

Fuente imagen:PerfectYourPodcast

Cuando nuestro navegador accede a una web, descarga el certificado asociado a la misma. El navegador comprueba que el certificado está correctamente firmado por la CA, corresponde al dominio de la web accedida y el estamos dentro del período de validez. Una vez realizadas estas comprobaciones básicas, revisará mediante los protocolos CRL y OCSP
que no haya sido revocado. Si todas las comprobaciones son correctas, empezará un intercambio de mensajes para definir una clave de sesión usando el certificado recién comprobado como punto de inicio del protocolo de cifrado. En realidad por cada sesión se calcula una nueva clave de cifrado, pero el protocolo siempre se inicia con mensajes cifrados usando el certificado digital X.509.

Recomendaciones

La Universidad Complutense de Madrid organiza, dentro de los Cursos de Verano de El Escorial,
el curso de dos días títulado «La ciberseguridad como eje de la transformación digital». El curso se celebra los dia 10 y 11 de julio y el primer día tiene un corte más empresarial, con
los CISO de Orange y FCC y una mesa redonda donde irá el director del Instituto Nacional de Ciberseguridad. El segundo día, será una jornada más práctica, incluyendo un taller.
La segunda recomendación tiene un alcance más sencillo: se trata de una charla «Ciberseguridad: El reto empresarial del siglo XXI» de la Cámara de Comercio de Mallorca que se celebra el próximo jueves 22 de junio. Es gratuita y estaré por ahí de oyente.

Descarga directa.

Podcast – 21 – Red DMZ

Podcast: Reproducir en una nueva ventana | Descargar

Suscríbete: Spotify | RSS

En seguridad informática denominados redes DMZ (o zona desmilitarizada) a una red perimetral donde se alojan todos los servicios de una corporación que deben ser accesibles desde Internet (servidores web, correo electrónico, servicios FTP, etc.). Esta red debería ser la única accesible desde Internet. En un entorno ideal las redes internas (la de los usuarios, intranets, etc.) pueden acceder a la DMZ mientras que los equipos que se ubican en la red DMZ sólo pueden salir a Internet pero no pueden acceder a las redes internas.

Diagrama simple de una red DMZ.
Fuente imagen: Wikipedia

Una red DMZ no es una red externa conectada directamente a Internet, sino aquella red corporativa a la que enviamos todo el tráfico de peticiones desde Internet. Así pues la red DMZ es la red donde se ubican los servicios que ofrecemos de cara al público y, por lo tanto, será nuestra cara visible tanto para nuestros clientes como para usuarios malintencionados. Debemos tener en cuenta que todos los servicios ubicados en la red DMZ serán accesibles desde Internet y por lo tanto, tarde o temprano, atacados. Así pues las políticas de seguridad de la empresa debe hacer especial hincapié en todos los equipos que están en la red DMZ: son los que serán más atacados y, por ello, deberían ser los mejor securizados, con una correcta política de actualización, controles de acceso, protección por IDS/IPS, etc.

Aunque idealmente las redes DMZ no deberían conectar con redes internas de la empresa, la realidad es que sí hay una red a la que necesitan acceder: la red de base de datos. Generalmente las aplicaciones web modernas realizan consultas a una base de datos, de allí la existencia de los ataques por SQL Injection que vimos en los capítulos 17 y 18. Es habitual crear una segunda red para las bases de datos que sí es accesible desde la DMZ para que los servicios web puedan funcionar. las conexiones entre la red DMZ y la red de bases de datos está protegida, mínimo, por un firewall que asegura que los servidores web únicamente puedan acceder a su base de datos y exclusivamente en los puertos necesarios.

Fuente imagen:PerfectYourPodcast

¿Por qué crear esta segunda red para bases de datos y no meterlas directamente en la DMZ? Se trata de una capa más de protección para las bases de datos. Como sabemos que en algún momento la DMZ será atacada y es posible que el atacante pueda llegar a comprometer un equipo (quizás consiguiendo una shell por una vulnerabilidad de nuestra aplicación) y desde allí moverse dentro de la red, esto comprometería las propias bases de datos aunque no tuvieran visibilidad directa desde Internet. Así está separación entre los frontales web y las bases de datos es una capa más de seguridad.

Descarga directa.

Evitar vulnerabilidad de Open DNS Resolver en nuestros servidores DNS

Deja un comentario

Se denomina como Open DNS Resolver a aquel servidor que resolverá cualquier petición recursiva de información sin importar el origen de la misma.

Fuente imagen: bleepingtech.com

El funcionamiento normal del protocolo DNS indica que si recibe una petición de un dominio que desconozca buscará dicha información (pidiéndosela a sus servidores DNS de referencia) y la entrega al cliente que la ha solicitado. Esto permite que cualquier ordenador pueda conectarse a cualquier sitio del mundo aunque no lo conozca previamente. El problema del Open DNS Resolver es que un tercero, que no tiene nada que ver con nuestra empresa, puede utilizar los recursos de nuestro servidor y nuestro ancho de banda para su propio beneficio. Ya no es sólo el mero hecho de asegurar la eficiencia del servicio al eliminar un uso externo ni previsto ni autorizado, sino que pueden utilizar nuestra infraestructura como parte de un ataque a un tercero e involucrarnos sin ni siquiera tener constancia de él.

Comparativa del tamaño relativo de una petición DNS válida y su respuesta

Comparativa del tamaño relativo de una petición DNS válida y la respuesta originada, que se envía a la víctima del ataque espejo. Fuente imagen: ArsTechnica

Los ataques de denegación de servicio mediante técnicas de espejo se basan en localizar la mayor cantidad de servicios no protegidos, a los que realizar peticiones aparentemente legítimas pero con la dirección IP originaría falseada por la de la víctima que quieren atacar. En nuestro caso un atacante solicitará la resolución de un nombre de dominio extraño, solicitando el máximo de información posible, de tal manera que la respuesta se envíe a la víctima. Este equipo víctima recibiría una gran cantidad de información desde diferentes fuentes de tal forma que sufriría un ataque DDoS. Si la víctima investiga el origen del atacante únicamente encontrará a los servidores DNS utilizados pero no el causante primario del ataque.

Cómo evitar tener un servidor Open DNS Resolver

Diagrama de un ataque de espejo. Fuente imagen: Wikimedia

A continuación indicaremos las principales medidas de protección para que no nuestro sistema DNS no tenga esta debilidad y evitar así que se convierta en parte de un ataque DDoS en espejo:

Deshabilitar la búsqueda recursiva. Tal cómo hemos indicado el propio funcionamiento del protocolo DNS hace que las búsquedas recursivas sean necesarias por lo que deshabilitarla no parece una opción práctica en la mayoría de situaciones. Quizás sí sea interesante si los servidores DNS públicos (aquellos que dan servicios a nuestras páginas web, sitios FTP, etc.) no son utilizados por nuestros trabajadores.
Bloquear las peticiones externas. Al igual que en el caso anterior bloquear las peticiones externas, vía firewall o sistema similar, sólo sería útil si los servidores DNS son de uso interno exclusivo y son diferentes a los que dan servicio público.
Limitar las peticiones de resolución con recursividad. La mayoría de sistemas DNS modernos permiten limitar desde qué redes es aceptable generar peticiones que incluyan resoluciones con recursividad. Así podemos configurar nuestro sistema DNS para que acepte las peticiones de las redes internas (las generadas por nuestros usuarios) mientras que descarte aquellas que provengan de redes externas que no controlemos. En la mayoría de empresas sería suficiente con indicar que sólo se permitan las direcciones IP de rangos privados.

Si bien las dos primeras opciones evitarían el uso de nuestros sistemas (tanto servidores, como anchos de banda, confiabilidad de nuestras direcciones IP, etc.) para formar parte de estos ataques es preferible configurar siempre las redes de confianza para realizar resoluciones con recursividad de tal forma que aunque debido a un fallo de configuración los servidores DNS quedarán expuestos a Internet tampoco pudieran usarse.