Archivo por meses: febrero 2017

Podcast – 15 – Categorización de Hackers

En el capítulo 12 hablamos sobre los riesgos de un atacante interno para una empresa, así que hoy vamos ha ver las diferentes categorizaciones de los atacantes externos, en función de su motivación,  y cómo estas pueden hacer que las empresas modulen sus medidas de seguridad.

Micro con feed

Fuente imagen:PerfectYourPodcast

Tras comentar la clásica clasificación de los hacker y sus sombreros, veremos como su motivación e interés, sus conocimientos técnicos y el objetivo buscado influyen en las capacidades y peligrosidad de sus acciones.

Las defensas y medidas de seguridad no serán la misma si debemos proteger un sistema frente a script-kiddies casuales o bien ante atacantes profesionales con un objetivo claro.

¿Añadiríais alguna clasificación más? ¿No te convence algo de lo que he dicho? No te cortes y ¡usa los comentarios!

Descarga directa.

Evitar vulnerabilidad de Open DNS Resolver en nuestros servidores DNS

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.

DNS logo

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

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:

  1. 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.
  2. 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.
  3. 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.

Micropíldora 5 – Deshabilitar función xmlrpc.php de WordPress

Según podemos leer en la Wikipedia, XML-RPC es un protocolo de llamada a procedimiento remoto (Remote Procedure Call) que usa el formato XML para codificar los datos y utiliza el protocolo web (HTTP) para la transmisión de los datos.

Logo de XML-RPC WordPress

XML-RPC WordPress logo. Fuente imagen: JJW Design

Dentro de la plataforma WordPress podríamos traducir esta frase como el sistema que permite la ejecución de instrucciones en nuestro blog de forma remota.

Gracias a este sistema podemos publicar de forma remota o gestionar nuestro blog con la aplicación móvil de WordPress, pero claro se trata de una herramienta de gestión que es muy probable que la gran mayoría de usuarios no utilicemos (y muchos ni siquiera conozcan).

A partir de WordPress 3.5 se habilitó esta posibilidad de gestión remota por defecto (antes era opcional), llegando incluso a quitar la opción de activar o desactivarlo desde los ajustes del panel de control. Por el principio de mínima exposición si no vamos a utilizarlo es preferible bloquearlo.

Cómo bloquear el acceso al sistema XML-RPC

Ya que no existe la posibilidad de deshabilitar el sistema XML-RPC en los ajustes de WordPress, tenemos dos opciones:

  1. Utilizar un plugin específico como puede ser Disable XML-RPC.
  2. Utilizar el fichero .htaccess de nuestro blog para bloquear el acceso. Esta es la opción que veremos a continuación

Bloquear acceso al fichero xmlrpc.php desde .htaccess

XMLRPC habilitado

Ejemplo de acceso habilitado al sistema xmlrpc.php

Utilizaremos las opciones de gestión de ficheros del archivo .htaccess para bloquear cualquier acceso al fichero xmlrpc.php, deshabilitando así esta funcionalidad de control remoto.

En la primera captura podéis ver cómo se ve un acceso al fichero xmlrpc.php desde un navegador normal: nos avisa de que el formato recibido no es el esperado pero el mero hecho de que responda demuestra que el servicio está activo.

Para bloquear el acceso a este fichero bastará con añadir al fichero .htaccess las siguientes líneas:

# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

Bloqueo del sistema xmlrpc

Ejemplo de bloqueo de acceso al sistema xmlrpc

Con esto indicamos al servidor que cualquier acceso al fichero xmlrpc.php debe ser bloqueado. Si intentamos acceder al fichero con nuestro navegador veremos un mensaje del servidor indicando que no estamos autorizados a acceder. Así eliminamos la posibilidad de que nadie acceda a la gestión de nuestro WordPress desde este entorno.

Podcast – 14 – Seguridad por oscuridad

En el capítulo de hoy hablaré sobre el concepto de seguridad por oscuridad y sus implicaciones en la seguridad informática.

Micro con feed

Fuente imagen:PerfectYourPodcast

Cuando hablamos, en el capítulo 7, de la esteganografía vimos que se trataba de ocultar un mensaje dentro de otro medio de forma que pasara desapercibido. Pues
ese es un ejemplo de seguridad por oscuridad. El envío del mensaje es seguro porque nadie sabe que está allí ni cómo está, pero en el momento que ese
secreto desaparezca también lo hará la seguridad y el mensaje será descubierto.

Hace no tantos años en España había operadoras de televisión por satélite que utilizaban un cifrado, denominado NAGRA, que basaba su seguridad en el hecho de que nadie conocía como funcionaba. En cuanto un equipo de criptoanalistas consiguió romper el sistema se generó un mercado negro de tarjetas y códigos de descifrado que permitió que muchos hogares vieran la televisión por satélite sin pagar a la compañía operadora.

Debate sobre la seguridad por oscuridad

En el audio podéis ver mi posición ante la seguridad por oscuridad, pero ¿qué me decís de vosotros? ¿Es algo útil o contraproducente?

Descarga directa.