Recientemente he usado la herramienta sshuttle y he quedado bastante satisfecho con la misma. Os comento algunos detalles por si la veis de utilidad.

En diversas ocasiones es posible que os hayáis encontrado que tenéis un acceso SSH a un servidor en otra red. Este servidor tiene visibilidad de esa red y lo necesitáis para ‘hacer de puente’. En esta situación se pueden hacer varias cosas:

  1. Conectaros al servidor por SSH y hacer las cosas desde ahí. Si usáis ssh -X podréis incluso tener un entorno gráfico, aunque dependéis de las utilidades instaladas en ese equipo.
  2. Hacer un túnel SSH a través de este servidor al servidor remoto que os apetezca conectaros (ssh -R).
  3. Hacer un túnel SSH a través de este servidor con interfaz SOCKS, de manera que puedas usar aplicaciones que soporten este tipo de proxy (ssh -D)
  4. Hacer un túnel SSH crenado interfaces tun (ssh -w), que es necesario hacerlo como root
  5. Usar sshuttle, que es más cómodo y fácil y empieza a ser mi favorito

Las ventajas principales de esta última solución es que no necesitas ser root y que puedes limitar qué redes vas a enrutar por el túnel. A efectos prácticos, es como si tu equipo fuera el servidor remoto para las redes que tú le digas.

Además te ahorras tener que estar cambiando la configuración de navegadores cada dos por tres o cambiando rutas a mano, etc.

La cosa funciona así de fácil:

sshuttle -r servidor_ssh 10.0.0.1/8 172.16.0.1/16

Con este comando le estás diciendo que para llegar a las redes citadas vaya a través del túnel SSH creado con servidor_ssh.

Lo único que necesitas es tener Python instalado en el servidor (que todos lo suelen tener por defecto) y que el servidor SSH te deje hacer túneles, claro.

Hay que ser absolutamente moderno” — Arthur Rimbaud

Últimamente he estado jugando un poco con IPv6, como pudisteis comprobar en mi post anterior. Ya hace muchos años solía tener el equipo que hacía de router en mi casa conectado con un túnel a la ya extinta 6bone.

El otro día me picó la curiosidad por saber si había alguna forma sencilla de conectarse por IPv6 al ‘mundo exterior’. La característica que buscaba era que el túnel soportara NAT para poder ejecutarlo desde mi equipo en ‘cualquier sitio’.

Por ahora, la mejor forma que he encontrado de hacerlo es usando gogoCLIENT. Un cliente que establece un túnel con la red de gogo6.

Su instalación es muy sencilla y puedes lanzarlo sin configurar nada y funciona perfectamente. Para descargarlo hay que darse de alta en la ‘red social’ de gogo6. Es posible hacer el túnel de forma anónima o bien usando tus credenciales de acceso a su web.

Una vez instalado, debido a que los navegadores solicitan siempre registros AAAA a los DNS… por si acaso pueden usar IPv6, sólo tienes que navegar normalmente y estarás usando IPv6 si el destino ofrece sus servicios por este protocolo.

Un listado de servicios IPv6 en España puede encontrarse en la web www.ipv6es.es. Algunas direcciones IPv6 curiosas, aprovechando que las direcciones pueden tener las 6 primeras letras del alfabeto, también se pueden encontrar en esta página.

Lamentablemente me da que nuestro proveedor no ofrece direcciones IPv6, por lo que no sé si podremos unirnos al World IPv6 day desde este blog, pero al menos podré participar desde el lado de cliente.

Y vosotros ¿os interesa conectaros por IPv6? ¿Vais a participar del World IPv6 day? ¿Pensáis que hay que ser ‘absolutamente moderno’?

Coincidiendo con las noticias del World IPv6 Day (el próximo 8 de junio, reservad vuestras agendas) el otro día me decidí a desempolvar mis limitados conocimientos en el nuevo protocolo que sustentará la Internet del futuro.

Un momento… ¿del futuro?

Si consideramos el uso de IPv6 a escala global pues sí, aún no está (aunque sigue avanzando poco a poco). Pero si consideramos el soporte de sistemas operativos, ya todos lo traen… activado por defecto.

Disponer de funcionalidad que realmente no usas tiene siempre implicaciones de seguridad, claro.

Haced un ip a o un ifconfig y buscad inet6. Lo más seguro es que tengáis ya asignada una dirección IPv6.

No voy a entrar a comentar nada sobre los cambios que supone el IPv6 sobre la versión 4 ni nada que ya bastante podéis encontrar por ahí. Sí quiero incidir en los siguientes puntos interesantes que he podido extraer del vídeo que os empotro al final de este post.

  • Las medidas de filtrado o limitaciones que hayáis puesto para servicios sobre IPv4 no van a ser efectivas en IPv6, lo que significa que es posible que sea posible acceder a servicios limitados a determinados rangos de direcciones IP.
  • Es posible que no encuentres los mismos servicios corriendo en uno y otro protocolo, por lo que la exposición de dichos servicios será diferente.
  • Es bastante probable que tu monitor de red y/o IDS no registre tráfico IPv6, por lo que un intento de explotación usando este protocolo puede pasar más desapercibido.
  • Las herramientas de seguridad suelen tener limitaciones cuando se utiliza IPv6.
  • Normalmente no vas a ser capaz de salir de tu red interna por IPv6 (ya que, a diferencia de equipos y servidores, necesitarías un esfuerzo para conseguirlo. Tendría que estar soportado por tu ISP o emplear algunos de los servicios de túneles disponibles gratuitamente por ahí.

Si tenéis activado IPv6 en algún equipo sobre el que tengáis acceso podéis probar a ejecutar los siguientes comandos:

  • ping6 ff02::1%eth0 para identificar otros equipos con IPv6 activado (y que respondan a ping)
  • ping6 ff02::2%eth0 para identificar equipos con funciones de rutado sobre IPv6 en vuestra red

Sustituid eth0 por la interfaz que queráis usar. Para profesionalizar un poco más el asunto, podéis hacer lo siguiente:

ping6 -c 5 ff02::1%eth0 | cut -d' ' -f4 | grep ^fe80 | sort | uniq | sed -e 's/:$//' > ipv6_addr
nmap -6 -sT -iL ipv6_addr

nmap es una de esas herramientas con limitaciones en el uso de funcionalidad sobre IPv6.

Debido a que la dirección IPv6 autoconfigurada se compone de elementos de la MAC de la interfaz, es posible, mediante un <code>arp -a</code> identificar visualmente a qué equipos (identificados por su dirección IPv4) corresponden las direcciones IPv6 que has encontrado.

Algo así hace automáticamente metasploit con el plugin auxiliary/scanner/discovery/ipv6_neighbor.

Por favor, ved el vídeo porque tiene muchas ideas interesantes desde el punto de vista de seguridad sobre IPv6:

  • Frameworks específicos para análisis y explotación de redes IPv6
  • Uso de socat para pasar de IPv4 a IPv6 y poder ejecutar herramientas que no tienen soporte nativo
  • Servidores de túneles para conectarse a la red mundial de IPv6 y poder participar del World IPv6 Day.
  • etc.

¿Has probado cuántos equipos tienen direcciones IPv6? ¿Has visto si difieren los servicios que ofrecen? Si lo haces no olvides comentarnos tus hallazgos aquí o en el próximo Sec&Beer.

Ah, y si consigues conectarte a Internet con IPv6 no olvides ir a ver a la tortuga bailando.

Por último, el vídeo prometido.

Rick Hayes – Assessing and Pen-Testing IPv6 Networks from Adrian Crenshaw on Vimeo.

“¿No te has dado cuenta al pasar por la terraza de que la noche estaba seca y fría? ¿No sabes lo que eso significa? No lo sabes, claro. Pues eso quiere decir que ahora están brillando las estrellas con todo su esplendor, y que los videntes gozan de la maravilla de su presencia. Esos mundos lejanísimos están ahí (Se ha acercado al ventanal y toca los cristales.) tras los cristales, al alcance de nuestra vista…, ¡si la tuviéramos!” — En la ardiente oscuridad. Antonio Buero Vallejo

Ciego. Así es como me siento cuando no sé qué es lo que está pasando en los sistemas de información y en las redes de comunicación. Toda es información está ahí, “al alcance de nuestra vista…, ¡si la tuviéramos!“.

El problema es que, actualmente, en muchas organizaciones no hay medios implantados para  conocer qué pasando en nuestra infraestructura. Algunas de las razones para no tener medios implantados son:

  • No se han configurado registros de actividad
  • No se han centralizado registros de actividad
  • Se supone que la cantidad de almacenamiento requerido es alta
  • Se supone que no hay recursos suficientes para analizar los registros
  • No se sabe qué buscar en los registros de actividad
  • No se sabe qué hacer con los registros de actividad

Como todo en la vida, uno de los principales problemas es intentar saberlo todo antes de siquiera empezar. Está claro que es un problema difícil que hay que ir resolviendo poco a poco e ir adaptando a las necesidades y limitaciones de cada uno.

Como punto de partida, lo mejor es empezar a centralizar aquellos eventos que puedan ser de interés inmediato, por ejemplo, accesos o errores. e ir viendo qué está ocurriendo. Posteriormente, ampliarlo en función de las necesidades que vayan surgiendo.

La ventaja de ir conociendo, al menos, algunos datos de lo que pasa en los sistemas o redes es que provoca dudas y preguntas que nos llevan a investigar y, por ende, adquirir un conocimiento mucho más completo de nuestra infraestructura.

Y ése es el segundo aspecto de la ceguera: no conocemos nuestra infraestructura. Pensad si sabríais responder a las siguientes preguntas:

  • ¿Qué software requiere mi infraestructura?
  • ¿Qué tráfico es el mínimo necesario?
  • ¿Qué puertos debo tener abiertos?
  • ¿Qué cambios ha habido recientemente?
  • ¿Qué procesos automáticos se ejecutan periódicamente?

Y eso sin considerar otros aspectos como información, aplicaciones, ficheros, copias, replicaciones, etc.

Algunas herramientas interesantes contra la ceguera (no pretende ser muy completa) son las siguientes:

Registros/eventos

  • OSSEC: un HIDS muy completo y, además, software libre.
  • Splunk: el favorito de los niños, el Google de tus logs y mucho más. Puedes usar una versión limitada gratis.
  • Sentinel: recientemente han anunciado una versión limitada también gratuita.
  • Loggly: para los atrevidos que no les importe mandar los logs a la nube.
  • LogstashGraylog2: dos aplicaciones de centralización de logs en software libre de reciente aparición.

Red/tráfico

  • Snort: el archiconocido IDS de red en software libre.
  • Snorby: un entorno web moderno para snort.
  • Ntop: el clásico entorno web de monitorización de tráfico.
  • Nfsen: para monitorización de tráfico con netflow.

Infraestructura

  • Nmap: best… scanner… ever.
  • OneCMDB: una aplicación de ‘inventario’ que, aunque parece muy potente, a mí no me acaba de convencer, pero tampoco es que haya encontrado nada mejor.
  • OCSInventory: tampoco es que me fascine porque es algo viejuno, pero si el objetivo es conocer el hardware y software instalado, puede ser la mejor solución.

Dejo fuera otro tipo de herramientas tipo Nagios que es bastante más común encontrar en cualquier organización.

Y vosotros… ¿también os sentís ciegos? ¿Qué herramientas conocéis/usáis? En cualquier caso, recordad que el objetivo último es conocer para mejorar la seguridad.

Estas herramientas sólo sirven para obtener información y no son, en ningún caso, sustitutos de los humanos. Recordad que solas no hacen nada, hay que usarlas.

Aparte de analizar los datos de herramientas diariamente, conviene buscar los medios para obtener un conjunto de datos de forma periódica que nos ayuden a entender nuestra infraestructura.

El SANS publicó hace mucho la lista de los ‘Top 5 essential log reports‘ donde se indicaban los ‘informes’ a generar periódicamente extraídos de logs y otros datos de los sistemas.

Recientemente, Chuvakin ha hecho una propuesta para los ‘Top 7 essential log reports‘ que os recomiendo que miréis y penséis si sois capaces de obtenerla con los medios actuales y si os sería de utilidad.

Por cierto que acabo de ver que Chuvakin tiene en su blog una lista de herramientas de análisis de logs que acaba de actualizar. Echadle un ojo.

Que desde el CCN se publiquen documentos y guías que aclaren y normalicen el cumplimiento del Esquema Nacional de Seguridad me parece cojonudo.

Sin embargo, que publiquen ‘herramientas’ de poca utilidad como son controles.jar y preguntas.jar, me parece algo patético.

En este post voy a comentar sobre la jarra de preguntas (ya podían darlas de cervezas).

Para empezar esta ‘herramienta’ no vale para nada, ya que no te deja poner comentarios, ni valorar las respuestas en un rango algo más amplio que ‘ok, no, parcial o n.a’. Luego visualmente sólo tiene una vista que no es muy acertada.

Herramienta de preguntas sobre requisitos del ENS

Herramienta de preguntas sobre requisitos del ENS

La exportación es a un fichero XML donde no aparecen las preguntas, por lo que tampoco sirve para nada. No se puede cortar y pegar ni se puede imprimir.

En fin, que para subsanar esta injusticia e incomodidad, he extraído las preguntas y os las paso en un formato más acorde, por si queréis hacer vuestras hojas de cálculo, incluir vuestros comentarios, generar gráficas o mejorarla.

Para los curiosos, la extracción la he hecho así. Primero descomprimís el fichero unzip preguntas.jar, luego un pequeño find nos dice dónde está lo que buscamos find . -type f -exec strings -e S \{\} \; -print | less. Parece que está en questions/ArbolPreguntas.class.

Ahora lo pasamos a un fichero strings -e S ArbolPreguntas.jar > preguntas.txt Y a partir de ahí, con algunos vim commands, llegamos a
este fichero. La codificación es UTF-8, por si alguno no lo ve bien.

Se aceptan comentarios sobre las preguntas, sobre la utilidad de las mismas, sobre las herramientas java del CCN, etc. o nuevas preguntas que se os ocurran. También se aceptan ficheros formateados para usar como cuestionario (compartidlo en googledocs con sevillasecandbeer y lo enlazamos desde aquí).