Archives mayo 2014

¿Estamos bajo un ataque DoD o DDoS?

Esta tarde he estado leyendo esta entrada (y a la que le “he robado el título”). Como bien comenta el autor, una de las características que un ataque de denegación de servicio (DoS) presenta, ya sea distribuido o no, es el gran número de conexiones que recibirá nuestro sistema. En esta entrada, podéis consultar una serie de órdenes de shell que nos permiten obtener información sobre las conexiones de nuestro servidor y, en función de ésta, detectar un posible ataque.

Algo parecido hace el guión de Python que os copio debajo. Si le introducimos uno de los estados en los puede estar una conexión, nos indica, para cada IP que ha establecido contacto con nuestro servidor, cuantas conexiones están en ese estado (y para cualquier puerto). El guión da para mucho y, evidentemente, también para detectar situaciones anómalas en las que tenemos muchas conexiones “SYN_REC” que denotaría un posible DoS (o DDoS, dependiendo del número de IPs) e, incluso, un posible escaneo de puertos.

#!/usr/bin/python
#encoding:utf-8
try:
 import optparse, sys, re, socket
except:
 print("Error executing 'import optparse, sys, re, socket' command")
 exit(1)
try:
 import socket
 from socket import AF_INET, SOCK_STREAM, SOCK_DGRAM
 import psutil
 from psutil._compat import print_
except:
 print "Error importing socket & psutil module. It is possible you need running 'apt-get install python-psutil'"
 exit(1)
def main():
 parser = optparse.OptionParser("usage%prog " + "-s <state>")
 parser.add_option('-s', dest = 'state', type = 'string', help = 'Please, specify the connection state to analize', default="ESTABLISHED")
 (options, args) = parser.parse_args()
 ipConnected = { }
 for conn in psutil.net_connections(kind='inet'):
 if conn.status == options.state:
 ip=conn.raddr[0]
 if (ip in ipConnected):
 ipConnected[ip]= ipConnected[ip]+1
 else:
 ipConnected[ip]=1
 print "Remote IPtt|# " + options.state + " connections"
 print "---------------------------------"
 for ip in ipConnected.keys():
 print "%stt|%s" % (ip, str(ipConnected[ip]))
if __name__ == '__main__':
 main()

El guión admite muchas mejoras. Por ejemplo, y para el caso comentado, poner un límite a partir del cual nos avise o active un filtro para esa IP. También podríamos comprobar lo mismo, pero solo para un servicio (puerto) determinado y que podríamos introducir como parámetro de entrada.

¡Espero que os sea útil!

 


DNS: el servicio más preciado

La importancia que tiene el Servicio de Nombres de Dominio (DNS) en Internet es algo incuestionable hoy en día. ¿Cuántas direcciones IP podría aprenderse un usuario normal? Sin el DNS, cómo enviaríamos nuestros correos o accederíamos a la información en Internet. Tanto es así, como que es el mecanismo utilizado por la justicia para “encarcelar” sitios delictivos a los que no puede llegar directamente.

Sin embargo, no es oro todo lo que reluce y existen problemas de seguridad de redes que afectan directamente al DNS, servicio que deberemos proteger concienzudamente. Por este motivo, os recomiendo la lectura de la muy recomendable Guía de Seguridad en Servicios DNS. Está basada en BIND9 y ha sido publicada por INTECO-CERT.

La descarga directa está en:

Nota: Esta entrada está basada en esta otra http://jagilma.wordpress.com/2007/11/13/dns-el-servicio-mas-preciado-2/ utilizada como herramienta de aprendizaje sobre DNS en la asignatura Administración e Instalación de Redes de Computadores.


Mejorando la seguridad en el uso de los certificados en Firefox

Como comenté en esta entrada, en las recomendaciones para una navegación más segura, se indica el que configuremos nuestros navegadores para que usen el protocolo UCSP (Online Certificate Status Protocol) para que compruebe la validez de los certificados que recibimos. UCSP es un método para determinar el estado de revocación de un certificado digital X.509 usando otros medios que no sean el uso de CRL (Listas de Revocación de Certificados). Este protocolo se describe en la RFC 2560.

¿Cómo se activa USCP?

Si seleccionamos la opción Editar>Preferencias>Avanzado y, dentro de esta, a la pestaña de los certificados( figura 1) nos encontramos con 3 botones. El del medio, Validación, es el que al pulsarlo nos muestra la activación de UCSP (figura 2)certificadosFigura 1.- Manejo de certificados en Firefox

ocspFigura 2.- Opciones de UCSP

En mi opinión, es una buena idea activar la opción de tratar el certificado como no válido cuando falle la conexión a un servidor OCSP. Así, cualquier error con el servicio (intencionado o no) no nos deja debilitados.

¡Espero que os sea útil!

Referencias

  1. RFC 2560

Add-on que te ayuda a detectar sitios web falsos

¿Cómo podemos saber que la página a la que nos conectamos es la “verdadera”? Si hablamos de la página de nuestro banco online, es importante que nos aseguremos, ¿verdad?.

Si ya nos hemos conectado otras veces, podemos detectar cambios en los certificados relacionados con las páginas que vistamos con la utilidad Certificate Patrol. Es un add-on disponible tanto para Chrome como para Firefox que nos permite detectar plagios (sitios web que se hacen pasar por otros) y mejorar la seguridad de nuestra navegación.

Para Firefox, el add-on lo podemos conseguir en el sitio oficial de Mozilla Siguiendo los pasos habituales instalamos el software y reiniciamos el navegador.

Pulsando en Herramientas>Complementos, veremos Certificate Patrol y podemos configurar las preferencias que deseemos (ver figura 1).

Captura de pantalla de 2014-05-04 13:35:14Figura 1.- Preferencias de Certificate Patrol.

Una opción que, en mi opinión, deberíamos habilitar es Show details of all certificate changes, even harmless ones, by default y Show details of an already accepted wildcard certificate again when it matches a new hostname para que estemos al tanto de los cambios que ocurran.

Espero que os sea de utilidad tal y como recomiendan en este vídeo de Intypedia.


Vídeo sobre la seguridad de SSL y recomendaciones para mitigar problemas

Todos hemos oído hablar del grave error de seguridad en openSSL Heartbleed que permite a un atacante capturar contraseñas y certificados. En Criptored ya explicaban que, dentro de los posibles ataques a SSL, están los fallos de programación en las distintas implementaciones. Aquí os dejo el vídeo. Es muy interesante, sobre todo para profesionales de la informática. En la página de la lección hay más documentación.

Leer más


Protección contra ARP poisoning

Ya he escrito en varias ocasiones acerca de problemas que permiten insertar un equipo entre nosotros y nuestros objetivos (Ataque Man In The Middle): aquí y aquí. En esta entrada, que amplía el “primer aquí”, el objetivo es explicar en qué consiste y cómo podemos abordarlo.

¿Qué es ARP Poisoning?

Consiste en conseguir indicarle a un nodo que la MAC asociada a una IP (por ejemplo la de nuestro router por defecto) es la otra diferente a la que tiene realmente el equipo objetivo. Conseguirlo es bastante fácil y, además, simplemente hay que usar el propio protocolo ARP. Una imagen vale más que mil palabras y, creo, la de la Wikipedia refleja bastante bien en qué consiste el envenamiento de ARP (también llamado, por el efecto, ARP Spoofing):

Leer más


IGMP: tráfico multicast y filtros

Cuando diseñamos una red una de las tecnologías/infraestructuras que planificaremos será la instalación de un cortafuegos*. En estas circunstancias tenemos que tener claro qué paquetes dejamos pasar, cuales desechamos, y todo en función de nuestra política de seguridad y sin perder la funcionalidad para la que estamos diseñando nuestra red.

Si utilizamos OSPF o, en general, si queremos manejar tráfico multicast, debemos habilitar los paquetes IGMP en nuestros filtros (suponiendo que tenemos la estrategia de denegar todo lo que no está explicitamente habilitado) ya que es el protocolo que utilizaran hosts y routers para establecer los miembros de los grupos de multicast. De este protocolo, debemos tener en cuenta, sobre todo, que se encapsula en datagramas IP con el número 2 de protocolo (esto implica que NO utiliza UDP ni TCP ni, por tanto, tiene puertos). Otro detalle que debemos tener en cuenta es que el TTL de los paquetes de IGMP, por defecto, es 1, lo que implica que no “atravesarán” los routers y no saldrán de la subred en la que se genera, aunque puede aumentarse para localizar servidores lejanos utilizando este campo como “barrera” y configurando los routers para que sean transparentes y no decrementen el TTL**.

La ejecución de las siguientes órdenes provocará que nuestro router de filtrado acepte y saque mensajes IGMP:

iptables -A INPUT -p igmp -j ACCEPT
iptables -A OUTPUT -p igmp -j ACCEPT

Para el caso de los grupos multicast relacionados con OSPF que comentábamos en la entrada anterior, podríamos limitar las reglas habilitando solo los grupos relacionados con OSPF:

iptables -A INPUT -p igmp -d 224.0.0.5 -j ACCEPT
iptables -A INPUT -p igmp -d 224.0.0.6 -j ACCEPT
iptables -A OUTPUT -p igmp -d 224.0.0.5 -j ACCEPT

Referencias

  1. Building Internet Firewalls, de Elizabeth D. Zwicky, Simon Cooper y D. Brent Chapman
  2. https://tools.ietf.org/html/rfc3376, RFC para IGMP versión 3
  3. http://tools.ietf.org/html/rfc2236, RFC para IGMP versión 2

* Prefiero usar el concepto de cortafuegos para la infraestructura de protección de red que diseñamos y que puede estar compuesta por varios elementos donde, uno de ellos, el dispositivo de red que filtra paquetes y que -casi- todo el mundo denomina cortafuegos, yo prefiero denominarlo router de filtrado.

** Una orden genérica para este caso es: iptables -A FORWARD -p igmp -j ACCEPT Si queremos, por ejemplo, especificar que el tráfico que queremos es el relacionado con el audio/vídeo: iptables -A FORWARD -p udp -m udp -d 239.0.0.0/16 –dport 5001 -j ACCEPT

 


Las cookies nos permiten ofrecer nuestros servicios. Al utilizar nuestros servicios, aceptas el uso que hacemos de las cookies. Más información.