martes, 13 de diciembre de 2011

NTFS y Alternate Data Streams. El peligro está oculto

El sistema de ficheros NTFS tiene un peculiaridad bastante llamativa derivada de proporcionar compatibilidad con HFS (Hierarchical File System) de Macintosh. En HFS la información de un fichero se almacena en bifurcaciones (forks) de datos y de recursos. Los forks de datos mantienen la información del contenido propiamente dicho mientras que los forks de recursos indican metadatos como por ejemplo tipo de fichero

 Esta propiedad provoca que un mismo recurso tenga varios identificadores y puede sacarse provecho para ocultar ficheros en NTFS. EL formato es conocido como Alternate Data Stream ADS.

 Mejor, veamoslo con un ejemplo.

La sintaxis de un ADS es sencilla. Para crear un ADS asociado con un fichero, basta con añadir el carácter dos puntos ":" al nombre del fichero, por ejemplo:
Creamos un fichero de texto:

C:\Users\Usuario\ADS>echo "Fichero de texto" > file.txt
C:\Users\Usuario\ADS>dir

 El volumen de la unidad C no tiene etiqueta.

13/12/2011 11:00 <DIR> .
13/12/2011 11:00 <DIR> ..
13/12/2011 11:00 21 file.txt

 1 archivos 21 bytes
 2 dirs 367.935.696.896 bytes libres
 

C:\Users\Usuario\ADS>type file.txt

"Fichero de texto"


Ahora utilizando la sintaxis apropiada creamos un fichero ADS:

C:\Users\Usuario\ADS>echo "Texto oculto" > file.txt:hidden


Comprobamos como, aparentemente nada ha cambiado:

C:\Users\Usuario\ADS>dir

  El volumen de la unidad C no tiene etiqueta.
 Directorio de C:\Users\Usuario\ADS

13/12/2011 11:00 <DIR> .
13/12/2011 11:00 <DIR> ..

13/12/2011 11:01 21 file.txt

 1 archivos 21 bytes
 2 dirs 367.935.696.896 bytes libres

C:\Users\Usuario\ADS>type file.txt
"Fichero de texto"


El fichero no existe con estructura como tal ....

C:\Users\Usuario\ADS>type file.txt:hidden

El nombre de archivo, el nombre de directorio o la sintaxis de la etiqueta del volumen no son correctos.

... pero podemos extraer el stream por ejemplo, haciendo uso de la redirección hacia el comando more:

C:\Users\Usuario\ADS> more < file.txt:hidden
"Texto oculto"



Como vemos, hemos podido "asociar" un stream a un fichero de modo que aparentemente sólo sea visible el fichero "file.txt" pero asociado a él existe el stream oculto "file.txt:hidden" con su propio contenido. Obsérvese que el tamaño del fichero no cambia ya que realmente sigue siendo el mismo. De hecho son independientes, es sólo una forma de demostrar que añadiendo los dos puntos ":" asociamos el data stream al mismo y será  invisible en un listado usual. Esta propiedad de los sistemas de ficheros NTFS contituye en cierto modo un  riesgo de seguridad  al permitir ocultar al usuario contenidos, permitiéndose incluso insertar de forma silenciosa archivos ejecutables.

Afinando un poco,  podemos listar y encontrar ADS usando la opción /R del comando DIR en windows:

C:\Users\Usuario\ADS> help DIR
Muestra la lista de subdirectorios y archivos de un directorio.

DIR [unidad:][ruta][archivo] [/A[[:]atributos]] [/B] [/C] [/D] [/L] [/N]

  [/O[:]orden]] [/P] [/Q] [/R] [/S] [/T[[:]fecha]] [/W] [/X] [/4]

...

..
  /R          Muestra las secuencias alternativas de datos del archivo.

..


De este modo, entonces:

C:\Users\Usuario\ADS>dir /R

El volumen de la unidad C no tiene etiqueta.
Directorio de C:\Users\Usuario\ADS

13/12/2011 11:00 <DIR> .
13/12/2011 11:00 <DIR> ..

13/12/2011 11:01             21 file.txt
13/12/2011 11:01           6.002 file.txt:hidden:$DATA






Existen varias herramientas para buscar y detectar cómodamente ficheros ADS. Por ejemplo Nirsoft, proporciona el programa AlternateDatastreamView que nos permite de forma muy sencilla escanear el disco en busca de este tipo de archivos:






Mas info:




lunes, 5 de diciembre de 2011

X Forwarding y túneles ssh


Puff, ya hacía tiempo que no posteaba. Mucho lío , poco tiempo , muchas cosas... o una combinación de todas.
Bueno pues voy a hablar del forwarding de X en sesiones ssh, cosa que más de una vez me ha "salvado la vida".

Tunelizando conexiones a servidor X


Cuando necesitemos acceso a otra máquina y hacer uso de herramientas gráficas, pero sólo podemos acceder vía ssh, podemos usar un túnel ssh y a través de la conexión  hacer  forwarding, de modo que las aplicaciones ejecutadas en la máquina remota tengan acceso al servidor X local.

El mecanismo es el siguiente:

Para establecer la sesión ssh con túnel para las x, ejecutaremos

ssh -X <host_remoto>  (*)
login: userx
Password:
Have a lot of fun...
/usr/bin/xauth:  creating new authority file /home/userx/.Xauthority
userx@server>$

(*) Si no inidcamos la opción -X, debemos tener habilitado el forwading  del servidor local de X (ForwardX11 yes) en el fichero de configuración del cliente ssh (/etc/ssh/ssh_config)

Con esto, el  cliente ssh local genera una cookie de autenticación y la envía al servidor ssh remoto que añadirá al fichero $HOME/.Xauthority de la máquina remota en la conexión.

El servidor remoto, abre el socket TCP 6010 en modo escucha. Además, inserta en el entorno del usuario que se logea la variable de entorno DISPLAY=localhost:10.0. En el caso de que el socket estuviese ya ocupado, asignará el siguiente (TCP 6011) y la correspondiente variable de entorno DISPLAY=11.0 y así sucesivamente.

Observemos la siguiente salida de netstat que nos muestra el estado de los sockets LISTEN en la máquina remota:

Sockets Listen en la máquina remota




Conexiones establecidas
Tenemos que:

Se crea una conexión ssh entre la máquina local 10.70.4.11 y la remota 10.70.4.4.  En la máquina remota se lanza una aplicacion gráfica (iceweasel). Esta  leerá la cookie del fichero $HOME/.Xauthority e iniciará una conexión TCP al socket local que corresponda, en este caso el 6010. El cliente recibirá la cookie y comprueba que, efectivamente, es la que él generó inicialmente. A continuación establece una conexión con el servidor X local. A partir de este momento el túnel está establecido.

En este ejemplo la sesión que abrió el socket 6010 y se  ejecutó iceweasel:

userx@server>$ pstree 15094
sshd----bash----iceweasel-----22*[{iceweasel}]

Conexión al servidor X. Tipos

La conexión de una aplicación al servidor X puede realizarse por varios métodos. En GNU/Linux los métodos son socket local (socket Unix)  y TCP. Es la aplicación cliente la que escoje el protocolo y la localización del servidor con la variable DISPLAY o bien con la opción --display.
En el caso de usar socket unix local , la variable DISPLAY será un signo de dos puntos seguido del número de display, generalmente 0 (aunque puede ser distinto si se ejecutan varios servidores de X). Opcionalmente puede añadirse un punto y número de pantalla (también suele ser cero salvo que el servidor X controle varias pantalllas) .Entonces DISPLAY tomará generalmente el valor :0 (o :0.0). El socket local se creará en /tmp/.X11-unix/Xn siendo n el número de display:

linux:/etc/ssh # ls -l /tmp/.X11-unix/
total 0
srwxrwxrwx 1 root root 0 Dec  5 10:53 X0

Cuando la conexión es por socket TCP, DISPLAY será el hostname o IP del servidor X seguido de dos puntos y el número de display. Al igual que antes puede añadirse punto y el numero de pantalla. Por ejemplo en una conexión local pero por TCP el valor será DISPLAY=localhost:0. El puerto TCP mas usado es el 6000 mas el número de display.
Téngase en cuenta que las comunicaciones con el servidor X no están cifradas por lo que si se usa TCP las comunicaciones pueden monitorizadas. Es por ello que GNU/Linux no permite la conexión al servidor X por TCP. Esto puede comprobarse observando el parámetro -nolisten tcp en el proceso X:

linux:/etc/ssh # ps -ef | grep X

root      4177  4163  0 10:53 tty7     00:00:07 /usr/bin/X :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-APoml7/database -nolisten tcp vt7 

Nota: En el ejemplo, la conexión de la aplicación cliente (en la máquina remota) se conecta al servidor X a través de un túnel ssh, con lo cual realmente el puerto TCP 6010 (6000 + 10 display) remoto está redirigido al túnel ssh y  la conexión al servidor X local a través de él

sábado, 22 de octubre de 2011

Demo de Japitracing

Hola a todos. Mucho tiempo sin escribir nada, pero estas últimas semanas dispongo de poco tiempo. He sacado un ratito para colgar el enlace del video-demostración sobre el proyecto de Fin de Máster que realicé en la Universidad Europea de Madrid junto a mis compañeros Jon, Pedro e Isa (gracias Isa por currarte el video)
Espero os guste: Demostración de trazabilidad IP por envenamiento de la caché del navegador vía google-analitics.
También en vimeo: Japi Demo

martes, 20 de septiembre de 2011

Caché poisoning e inyección de javascript. Huella digital, Geolocalización y seguimiento a través de Google Analytics

El pasado 14 de Septiembre se presentaron en la Universidad Europea de Madrid los ultimos proyectos de Fin de Máster de Seguridad de la Información y las Telecomunicaciones.  En concreto yo, con mis compañeros presentamos el proyecto Japitracing sobre Geolocalización IP usando cache poisoning con inyección de javascript a través del servicio Google Analytics..
Portada de la memoria Fin de Master



Logo de la aplicación



En dicho proyecto se ha implementado la idea de hacer un envenamiento de la caché de los navegadores aprovechando la confianza que ofrece un servicio como Google Analytics. Este servicio se basa un un código javascript ( ga.js ) que es descargado desde la páginas que hacen uso de analytics y cuya función es recopilar información  variada del navegador y de aspectos de la navegación dentro de  la página para generar estadísticas que se envían al propietario de la  misma. Este script, es un objeto cacheable con una vida media de una o dos horas hasta que el navegador solicita actualización. Además está ampliamente extendido por internet, de modo que,  casi con total seguridad en una sesión de navegación normal se  visita una página que lo contiene. Esta situación se ha aprovechado para conseguir obtener información sobre una persona y su localización después de haber modificado el  script original ga.js de Gooogle Analytics y , tras una intervención en la comunicación, lograr inyectar en la caché del navegador de la "victima". La manipulación del ga.js ha sido de forma que al descargarse, se cachée con un tiempo largo de expiración para lograr  hacerlo "persistente" y que no sea de nuevo sustituido por el original una vez se deje de intervenir la comunicación (MiTM). El script modificado incluye un código que recogerá información sobre la IP ( y localización por tanto) , sobre el sistema operativo,  el navegador, sus plugins y su  historial. Una vez recopilada toda esa información será enviada, esquivado las restricciones de same origin policy  gracias a un  iFrame invisible que se crea en la carga de la página , a continuación, tras meter la información en un formulario se envía con POST hacia un servidor ajeno. Todo esto ocurre de forma transparente para el usuario cada vez que se visite una página con Analytics y el script ga.js (ya almacenado en caché) se invoque.

Una muestra de la información obtenida

En definitiva  un trabajo muy interesante, durante el cual hemos ido descubriendo las posibilidades que tiene javascript , la información del navegador ,su funcionamiento y caché para establecer un ataque que vulnere gravemente la privacidad del usuario. Todo ello incrementado aun más por las características particulares de las aplicaciones y configuraciones que cada usuario tiene y que conformarán lo que se da en llamar "huella digital". Para profundizar en este tema, las huellas digitales y la privacidad a la hora de navegar, que mejor que leer esta entrada en el blog de nuestro tutor en el proyecto.

Finalmente, agradecer públicamente el gran trabajo y la motivación de mis compañeros de máster asi como la ayuda de nuestros tutores en informática64, Pablo González y Chema Alonso.

jueves, 1 de septiembre de 2011

Cluster de alta disponibilidad + balanceo de carga


Hace un tiempo tuve que implementar un balanceo de carga con alta disponibilidad y me resultó una tarea interesante. Cuento un poco como lo hice.
Vamos a implementar un cluster de alta disponibilidad (ha) que mantenga un servicio de balanceo entre
dos servidores, en este caso y a modo de ejemplo dos servidores Web.
IP Virtual: 192.168.50.205
IP Nodo 1 ha: 192.168.50.215
IP Nodo 2 ha :192.168.50.225
IP servidor Web1: 192.168.50.211
IP servidor Web2: 192.168.50.221

Necesitaremos:

  • Alta disponibilidad : Heartbeat

Con este paquete se establece una comunicacion entre los miembros del cluster (nodos) y se
definen unos servicios que se quieran poner en alta disponibilidad. Uno de los nodos será el master y
será quien dé el servicio. Si se cae, el/los otros nodos tomarán el servicio hasta que se recupere.
Nosotros vamos a poner como servicio el ldirectord que es el que se encarga de balancear la carga
sobre los servidores Web.

  • Balanceo LVS: Ldirectord

Es el paquete que propiamente proporciona el balanceo de carga. Se configura definiendo una
IP Virtual que el servicio se encarga de mantener a la “escucha” y repartir las demandas sobre los
servidores reales (web).


  • IP_Forwarding:

Como el balanceador tiene que hacer forwarding de las peticiones sobre la IP virtual a las reales, es
requisito habilitar en el kernel esta característica:
# /etc/sysctl.conf
net.ipv4.ip_forward = 1

Instalación :

apt-get install heartbeat ldirectord (debian)
yum heartbeat ldirectord install (RedHat)

Configuración:

Ldirectord
Lo primero y como queremos que este servicio sea controlado por heartbeat y que sea éste quien lo
arranque, lo deshabilitamos del boot de la máquina:

update_rc.d ldirectord remove (debian)
chkconfig ldirectord off (RedHat)


Creamos el fichero de configuración : ldirectord.cf y lo ubicamos en /etc/ha.d/conf
En este caso va a tener la pinta:

(No entro a describir todos los parámetros puesto que es extensísmo, consultar man)


# vim /etc/ha.d/ldirectord.cf
checktimeout=10
checkinterval=2
autoreload=no
logfile="/var/log/ldirectord.log"
quiescent=yes
virtual=192.168.50.205:80
real=192.168.50.211:80 gate
real=192.168.50.221:80 gate
fallback=127.0.0.1:80 gate
#protocolo que se gestionará
service=http
#Scheduler es el algoritmo usado para hacer el reparto de carga rr=RoundRObin, lc= least
conections... etc (ver man ldirectrd)
scheduler=rr
protocol=tcp
#Checktype es la “prueba de vida” que hará el ldirectord para saber si el servidor real esta vivo, en
este caso negotiate que comprobará una respuesta (hay otros por ej connection..)
checktype=negotiate
#archivo que se solicitará en los servidores web para la prueba de vida, debe estar en DocumentRoot
request="test/ldirector.html"
#El archivo debe contener unicamente esta linea de texto para confirmar la validez del sitio
web
receive="Si, estoy vivo!"


Con esto el ldirectord creará una IP virtual 192.168.50.205:80 que repartirá a los servidores reales por
el método Direct Routing (gate). Existen 3 métodos: NAT ,Direct Routing e IP Tunneling.

  • NAT:

 Las peticiones entrantes llegan a la IP virtual y son reenviadas hacia los servidores reales
   cambiando la IP destino (NATeo). La respuesta de los servidores reales vuelve al balanceador
  quien de nuevo cambia la IP y reenviía al petcionario. Como todo el tráfico pasa por el
   balanceador suponde normalmente un cuello de botella para el cluster.

  •  IP Tunneling

   LVS manda las peticiones a los servidores reales a través de un tunel IP y los servidores
   responde directamente al peticionario a través de sus tablas de enrutamiento (necesitan pues de
   gateway).

  •   Direct routing

 Los paquetes del peticionario son enviados directamente a los servidores reales (forwarding).
Como el paquete IP no es modificado los servidores reales para aceptarlo necesitan una interfaz
virtual no-ARP ( para evitar conflictos de red al tener la misma IP que la virtual). La respuesta
se envía directamente al peticionario desde el servidor real.

Lo que hace Ldirectord:
Conecta cada 10 segundos (checkinterval) con cada servidor real y pide la prueba
192.168.50.205:80/test/ldirector.html (request/receive). Si no recibe la cadena que pusimos en ese
fichero (“Si, estoy vivo”) en un tiempo de 2 segundos (checktimeout), eliminara ese servidor del “pool”
de servidores disponilbles a los que mandar peticiones. Estará de nuevo disponible cuando el test sea
exitoso.
Copiamos este fichero de configuracion ldirectord.cf en /etc/ha.d/conf del resto de nodos
Una vez definido el servicio de balanceo, vamos a ponerlo en Alta Disponibilidad a través de
HeartBeat.

Hearbeat


Para establecer la comunicación entre los nodos hay que definir un método de autenticación que se
hace a través del ficherito /etc/ha.d/authkeys
#vim /etc/ha.d/authkeys
auth 1
1 md5 EstaEsmiClaveSecreta
Este fichero que contiene la clave de autenticacion y el método de encriptación (md5) lo protegemos
para que solo lo lea root:
#chmod 600 /etc/ha.d/authkeys


Otra cosa a tener en cuenta es que los nodos se “conozcan”, es decir editar /etc/hosts en ambos y poner
los nombres de los nodos del cluster. Poner el nombre que devuelva el comando : uname -n

# vi /etc/hosts
192.168.50.215 Nodo1 NODO1
192.168.50.225 Nodo2 NODO2


Definimos el cluster: /etc/ha.d/ha.cf (bastante simplificado)


#Fichero de log
logfile /var/log/ha-log
logfacility local0
keepalive 2
deadtime 30
initdead 120
# Tarjeta por la que se realizará el broadcast
bcast eth0
udpport 694
auto_failback on
#nombre de host (uname -n) de los equipos directores
node Nodo01
node Nodo02
Copiamos este fichero en /etc/ha.d/ del resto de nodos.
Nota: La definicion del cluster se puede simplificar bastante con la herramienta gráfica hb_gui
Por último ya solo queda definir los servicios en alta disponiblidad que en nuestro ejemplo será el
ldirectord.
Los recursos se definiran en /etc/ha/haresources

El formato viene bien descrito en los comentarios del propio fichero. En este ejemplo va a tener la
pinta:


#vi /etc/ha.d/haresources
Nodo01 IPaddr2::192.168.50.205/24/eth0/192.168.50.255 ldirectord::ldirectord.cf
LVSSyncDaemonSwap::master


El ficherito haresources será identico en todos los nodos del cluster. La referencia al nombre del nodo
es el nodo que será el preferido para actuar como master (en este caso el Nodo1).
El formato que vemos es:

Nodopreferido IP_para_el recurso1 recurso:parametro1.......
En el formato de la IP se ha especificado IP/mascara/interfaz/broadcast.
El recurso LVSSyncDaemonSwap es el demonio que habilita las capacidades de la alta disponibilidad.
Sincronización en te los nodos, commutación...

Configuración de los servidores reales


Debemos configurar los servidores reales de modo que acepten el forwarding que les envía el
balanceador LVS por la IP virtual.
Tenemos que configurar un alias virtual que levante la direccion virtual y además hacer que sea “sorda”
a ARP de modo que no desvele la IP y no entre en conflicto.
Los cambios a realizar en los parámetros del kernel de los sevidores reales serán:

# /etc/sysctl.conf
#habilitar la opcion de ignorar ARP
net.ipv4.conf.all.ARP_ignore = 1
#No responder a las solicitudes de ARP si la direccion IP esta configurada sobre el interfaz
“lo” (loopback) o cualquier otro interfaz virtual eth0:0
net.ipv4.conf.eth0.ARP_ignore = 1
#Habilitar la opcion de anuncio ARP
net.ipv4.conf.all.ARP_announce = 2

Como la fuente IP de la peticon ARP entrará en la cache ARP del destino esto tiene el efecto de
anunciar esta direccion. Esto no es deseable para “lo” o cualquier otro interfaz virtual ethx:0 de los
servidores reales. Usando este valor haremos que los servidores reales siempre que reciban una peticion
ARP usen la IP real como fuente de la peticion ARP.

net.ipv4.conf.eth0.ARP_announce = 2

Y cargamos los cambios con:

# sysctl -p


Una vez hechos estos cambios ya tendremos la posibilidad de levantar el interfaz virtual que nos sirva
la IP virtual sin conflictos.
Definimos en los servidores reales sobre lo, la interfaz virtual lo:0 añadiendo:


# /etc/network/interfaces
...
iface lo inet loopback
auto lo:0
iface lo:0 inet static
address 192.168.50.205
netmask 255.255.255.255
Esta interfaz será la encargada de recibir el forwarding del balanceador.

Gateway:
Hay que tener en cuenta que la respuesta de los servidores reales será directa a los usuarios con lo cual
estos deben tener el router en el default gateway.
Con esto ya queda acabada la configuración.
Finalmente, ya solo queda arrancar el cluster ejecutando en todos los nodos del cluster :

# service hearbeat start
.... Y a depurar, claro.

sábado, 27 de agosto de 2011

¿ Quieres aprender más y mejor ? Practica !!

Edgar Dale pedagogo estadounidense desarrolló un estudio sobreproceso de aprendizaje y enseñanza. Fruto de ello diseñó un gráfico que de forma visual resume en qué medida las experiencias sensoriales afectan a la capacidad de aprender y de retener lo que se recibe. Este gráfico es conocido como el "cono  del la experiencia Edgar Dale" :


Cono de la experiencia de Dale


Estos últimos meses me he visto inmerso en un proceso de aprendizaje en el que me he enfrentado al reto de asimilar  gran volumen de información  en poco tiempo. Echando vista atrás  compruebo, cuan ajustada es la visión de Dale respecto a la absorción de conocimientos. De todo lo recibido, aquello que se ha fijado mejor en mi, ya de por sí penosa memoria, ha sido aquello en lo que he realizado o resuelto casos prácticos. Leer, he leído mucho si, pero lo retenido no es comparable  a lo que aprendí practicando. También en la realización de trabajos o exposiciones, todo el proceso de preparar la materia con objeto de transmitirla a terceros me ha hecho retener de forma más sólida esos conocimientos. Muchas veces he resuelto un problema cuando, desesperado,  he querido pedir ayuda a otra persona y en el proceso de plantearme como explicar el asunto a esa persona de forma que entiendese mi dificultad, yo mismo he encontrado la solución.

Por ello desde mi propia experiencia recomiendo tener en cuenta las indicaciones de Dale para un mejor aprendizaje. Asi que.. Si quieres aprender más y mejor... Practica y enseña !!!

Saludos

lunes, 8 de agosto de 2011

Nace Piruletous Hacking Team , grupo de (in)Seguridad.

Este año  participé con unos  amigos en el "ESET Wargame" de la  Campus Party  2011 de Valencia . Fué una gran experiencia y pasamos una semana entretenida e intensa con la competición.  Tras finalizar  en sexta posición  y con ganas de más, decidimos crear un blog para exponer nuestros intereses e ideas. El blog de PHT ( Piruletous Hacking Team ) nace a partir de la idea de un grupo de alumnos del Máster de Seguridad TIC de la UEM, cuyos integrantes y seguidores podeis ver en LinkedIn buscando Piruletous Hacking Team.

Os animo a seguir a PHT donde esperamos ofrecer una info útil , didáctica y entretenida.

Saludos



miércoles, 6 de julio de 2011

Malware. Algo raro está sucediendo

Hoy en día la sofistificación de los programas de malware, botnets y demás "joyas" hacen muy complicado la defensa. ¿Antivirus ?. Bueno, menos da una piedra. Pero amigo, no creas que el tener un antivirus actualizado te garantiza que tu máquina está libre de infecciones. Es más, existen "kits" de creación de botnets como Zeus o Spyeye que ponen a tu disposición un "framework" para crearte tu propio malware a medida y con relativa facilidad , y por supuesto el resultado invisible a antivirus.

Por ejemplo en este vídeo vemos un ejemplo con Spyeye que se está convirtiendo en el sucesor de Zeus:


Desde la explosión de la web 2.0 (y del malware 2.0), las botnets han descubierto en el HTTP un método mucho más eficaz de controlar a sus zombis. HTTP es un protocolo que no suele ser filtrado "hacia afuera" en un sistema, puesto que impediría la navegación estándar. Poco a poco Internet migra hacia el navegador como contenedor de toda la experiencia en la Red y esto no es diferente para los atacantes. Para ellos también resulta mucho más cómodo controlar una botnet desde el navegador. El malware ha ido migrando hacia este sistema, que permite cifrado sencillo (SSL) y pasar más desapercibido para las soluciones de seguridad.

Identificando la infección

Buff, complicado. Pero siendo observadores podemos sospechar que algo extraño sucede:

• Aparecen nuevas barras de herramientas, vínculos o favoritos que no se han agregado intencionadamente al explorador web.
• Su página principal, el puntero del mouse o el programa de búsqueda cambia de forma inesperada.
• Escribe la dirección de un sitio concreto, como un motor de búsqueda, pero se le dirige a otro sitio web sin previo aviso.
• Los archivos se eliminan automáticamente del equipo.
• Ve anuncios emergentes aunque no esté en Internet.
• Su equipo de repente comienza a funcionar más lento de lo habitual. 

• De pronto se muestran mensajes o imágenes inesperados se reproducen sonidos o música inusuales de forma aleatoria.
• Su cortafuegos le informa de que algunas aplicaciones intentan conectarse a Internet, aunque usted no las haya iniciado.
• Sus amigos mencionan que han recibido mensajes desde su dirección, y usted está seguro de no que usted no los ha enviado.
• Su bandeja de entrada contiene muchos mensajes sin la dirección del remitente o encabezado.
• Su ordenador se paraliza con frecuencia o encuentra errores.
• Su ordenador se vuelve lento cuando se inician los programas.
• El sistema operativo no puede cargarse.
• Los archivos y carpetas han sido borrados o su contenido ha cambiado.
• Su disco duro es accedido con mucha frecuencia.

Cualquiera de estos síntomas podrían indicar que formamos parte de una botnet y nuestra máquina es un "zombie"

Recomendaciones


Linux
Yo como usuario de Linux, recomiendo usar linux y tenerlo actualizado. Evitarás con ello la mayor parte de los problemas. No considero windows un mal sistema pero sí es el objetivo de la mayoría de ataques y software malintencionado.

Si usas windows:
No confíes en el antivirus.
Mantén actualizado el sistema operativo y los programas. Windows Update y Secunia (gracias, Héctor)
Sé inteligente, no ignores las alertas de seguridad de certificados ni aceptes sin más la ejecución de programas que no conoces.
Crackers, generadores de seriales etc,etc. Te la juegas.
Usa software reconocido y de fuentes fiables.

Contramedidas

Si ya crees que estás infectado  por software malicioso, empieza por echar un vistazo a los puntos clave de tu sistema: procesos, conexiones abiertas (netstat) y utilizar software especializado.


Utilidades de Sysinternals: Proceso. Process explorer es muy bueno, no te fies del "explorador de tareas"

Utilidades de Sysinternals: Funciones de red. TCPview
Proceso de una botnet y conexión abierta


De Nirsoft recomiendo CurrportsIPNetInfo
CurrPorts de Nirsoft

Otro punto importante es comprobar la integridad de los ejecutables del sistema, es decir, comprobar que los programas y librerias son las auténticas y no han sido sustituidas por copias falsas de malware. Para ello debemos comprobar la firma y podemos usar Sigcheck de Windows Sysinternals


Update:
Como comenta Héctor , muy interesante también analizar los programas que se ejecutan en el inicio. Para ello podemos usar , también de Sysinternal Autoruns

Igualmente completar el test de firmas de procesos con un análisis de Rootkits, para ello usad RootkitRevealer, del amigo Russinovich.

Secunia para mantener todo el software actualizado

Mucha paciencia, y sobre todo ser previsor y prudente. Mas vale prevenir que curar

Mucha suerte

miércoles, 22 de junio de 2011

Don't track me, please. Proteger nuestra privacidad en Internet

Cada vez son más numerosas las páginas de Internet que registran nuestra navegación y comportamientos al movernos por la red, y lo que es mas inquietante, de forma "transparente" para nosotros. Seguro que os habéis fijado, y posiblemente molestado con esos anuncios en vuestro correo que parecen conocer que asuntos tratais o os interesan. Amigo, estás rastreado.

La preocupación por  evitar ser rastreados ha llevado a las principales marcas de navegadores a implemetar en su software funcionalidades anti-tracking. IE9 ya lo incluye con las "Listas de protección de rastreo"con las que  podrás determinar qué sitios web de terceros podrán recibir tus datos y realizar un seguimiento de tus actividades por Internet. Al agregar una lista podrás bloquear contenidos de sitios web susceptibles de afectar a tu privacidad.

Por su parte, firefox anuncia en su versión 5 la  función de privacidad "No rastrear", convirtiéndose en el primer navegador en ofrecer esta opción en múltiples plataformas : para Windows, Mac, Linux y ...Android llevando de este modo la extensión a los móviles.

¿ Y Chrome ? Podemos pensar que para el gigante de los anuncios en línea, Google la idea de de perder "rastros" no le parece atractiva. ¿Que pasará entonces con el negocio de google analytics y otras empresas cuyo negocio se basa en ofrecer estadísticas de visitas?. De momento chrome nos ofrece el plugin Keep my Opt-outs para que de manera opcional deniegues a Google analice tu navegación.

lunes, 20 de junio de 2011

Cursos Seguridad Informática UEM

Los próximos 28, 29 y 30 de junio de 2011 tendrán lugar los cursos de Verano en Seguridad Informática. Se celebrarán en la Universidad Europea de Madrid en colaboración con empresas como Informática64, s21sec, Zendal, Bitdefender y Microsoft . Cuenta  con un plantel de ponentes de la talla de Rubén Santamarta experto en Seguridad de Sistemas Informáticos con una gran labor investigadora en sistemas SCADA  Chema Alonso , Juan Luís García Rambla de Informática64 Fernando Guillot, de Microsoft Ibérica o José Selvi, de S21Sec por citar algunos. Entre las conferencias me gustaría destacar las relacionadas con ataques Man in the middle sobre ipv6 ( J.L. García Rambla) y Recuperación de Desastres en Cloud computing ,  por la importacia futura (y ya presente) de ambas Tecnologías.

Una buena ocasión de conocer y profundizar en asuntos clave en Seguridad TIC.

viernes, 10 de junio de 2011

Guerra cibernética y terrorismo digital. ¿Como podemos defendernos ?

De nuevo, la manifestación de la amenaza y el impacto de los ataques informáticos.

 INTECO, centro nacional orientado a proporcionar información y guías para la seguridad y confianza de la información en las Telecomunicaciones ha sido atacada y se ha conseguido acceso a la BBDD robándose datos de 20.000 usuarios.

Actuación policial sobre Anonymous, quizás el fenómeno más conocido de como un grupo de personas sin una organización específica (por eso  de anónimos) y bajo una ideología común perpretan ataques de gran impacto mediático. Incluso grandes entidades bancarias como Citibank han sido atacadas con éxito con las graves consecuencias que ello implica.

Quería aprovechar para dar una referencia muy interesante sobre el tema. En la edición de este año del Máster en Seguridad TIC impartido en la Universidad Europea de Madrid se presentó un proyecto de fin de Máster  sobre Ciberterrorismo y ataques digitales sobre las infraestructuras de la Información y cómo definir  una política adecuada para afrontar esta amenaza  presente y creciente . Se hace un analisis de la situación, se describe la evolución de los ataques digitales y  se proponen políticas de seguridad aplicables para prevenir estas amenazas .Se han elegido varios temas de actualidad que, previsiblemente, en los próximos años cambiarán la sociedad de la Información

Un gran trabajo que os invito a leer, y por supuesto a tener en cuenta. El futuro les dará la razón.



sábado, 21 de mayo de 2011

Probando, probando... ipv6 !!

Bueno va llegando hora de ponerse manos a la obra y probar la conectividad de ipv6. Yo utilizo Linux, en concreto Fedora. Actualmente las distros de Linux vienen con el módulo de ipv6 cargado por defecto, si no basta con ejecutar:

modprobe ipv6

Con esto el módulo del kernel para ipv6 se cargará en memoria y podemos configurar la tarjeta de red con una dirección ipv6. Pero... vivimos aun en un mundo ipv4. Mi router es ipv4, mi ISP me asigna dirección ipv4, así que la única solución que me queda es configurar un túnel para encapsular las direcciones IPv6 en un paquete ipv4 para enrutarlo por internet. Para ello busco un "tunnel broker" que son sitios que nos asignan un prefijo de red ipv6 y nos gestionan un los extremos de túnel con un servidor de túneles ipv6-ipv4, facilitándonos las cosas bastante. Un tunnel broker puede entenderse entoces  como un "ISP virtual". Existen muchos brokers ,en mi caso escogí  el ofrecido por hurricane electric donde te registras y mediante un sencillo menú seleccionas un servidor de túnel y configuras tu tarjeta para encapsular tu tráfico ipv6 sobre ipv4.

Los pasos que da un tunel broker unas vez te has autenticado son: ver RFC 3053

  • Te asigna un servidor de tunel que será usado como un extremo del tunel
  • Te asigna un prefijo de red
  • Fija un tiempo de vida para el túnel
  • Registra en su DNS las direcciones ipv6 globales asignadas a los extremos del túnel
  • Configura el lado servidor del túnel
  • Informa al cliente de la configuración de su extremo, incluso instruye sobre los comandos para la creación del túnel.


En mi caso una vez configurado la cosa quedó:

modprobe ipv6
ip tunnel add he-ipv6 mode sit remote 216.66.84.42 local 192.168.50.201 ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:1f12:813::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6
ip -f inet6 addr


Donde  216.66.84.42 es la dirección del tunel server que me asignaron ,  192.168.64.21 es mi dirección local (tras el NAT de mi router, pensé que no funcionaría :D ) y 2001:470:1f12:813::2/64 es la direccion ipv6 global asignada:
[root@lobobinario networking]# ifconfig -a

eth1      Link encap:Ethernet  HWaddr 00:23:CD:B4:DC:5E  
          inet addr:192.168.50.201  Bcast:192.168.50.255  Mask:255.255.255.0
          inet6 addr: fe80::223:cdff:feb4:dc5e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11323 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10868 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:8961913 (8.5 MiB)  TX bytes:1942426 (1.8 MiB)
          Interrupt:23 Base address:0x4c00 

he-ipv6   Link encap:IPv6-in-IPv4  
          inet6 addr: 2001:470:1f12:813::2/64 Scope:Global
          inet6 addr: fe80::c0a8:32c9/128 Scope:Link
          UP POINTOPOINT RUNNING NOARP  MTU:1480  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:12 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:720 (720.0 b)  TX bytes:720 (720.0 b)

sit0      Link encap:IPv6-in-IPv4  
          NOARP  MTU:1480  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0bio
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
NOTA: Estas configuraciones son temporales. Para hacerlas permanentes tras un reinicio de la máquina debes hacer los cambios necesarios en los ficheros de configuracion de los interfaces de red.

El resultado fue: 


Hubieran estado bien unas capturas de Wireshark... peeeero.

Aullidos binarios.

martes, 17 de mayo de 2011

Notas de Seguridad en IPv6: Seguridad en el control del tráfico. (III de III)

Para prevenir  tráfico ipv6  no deseado o no autorizado relacionado con  internet algunas recomendaciones serían:

  • Firewalls
    • Si no tenemos soporte IPv6 en nuestro site, debemos evitar que hosts de la intranet usen túneles Ipv6 a Ipv4 para alcanzar internet configurarndo los firewall IPv4 para descartar todo el tráfico de salida marcado con protolo IP 41 (tunel). En el otro sentido, denegando en el firewall los paquetes IP 41 de entrada, evitaremos que alguien desde internet use un tunel para inyectar trafico ipv6 en la red
  • Intranet con IPv6 ISATAP
    • Configurar correctamente ISATAP de modo que la ruta por defecto nunca se dirija hacia la red IPv4 y siempre lo haga hacia el router ISTAP que es el elemento que manejará la redirección hacia la porción interna de la red que implementa IPv6
    • En el firewall asegurar que se descartará el trafico IP 41
  • Teredo
    • Para prevenir que via Teredo se pueda establecer contacto con internet , igualmente como medida preventiva se descartará en el firewall el tráfico UDP 3544. Esta medida no sería eficaz si el puerto UDP se cambiase a otro y en ese caso tendríamos que recurrir a  técnicas de inspeccion de tráfico
En el caso que tuviésemos que permitir tráfico IPv6 con internet, la recomendación principal es actualizar firewall, proxy e IDS para incluir funcionalidades IPv6, añadido a las ya comentadas de autoconfiguración de direccion y de seguridad en los paquetes IP




sábado, 14 de mayo de 2011

Notas de Seguridad en IPv6: Seguridad en los paquetes IP. (II de III)


Continuando con las recomendaciones de seguridad para IPv6, vamos a abordar el tema de la seguridad de los paquetes. IPv6 por definición implementa obligatoriamente IPSec lo cual nos brinda un gran avance en la seguridad respecto a IPv4 donde es opcional. IPSec usa criptografía para proporcionar seguridad de los datos e incluso las cabeceras (modo túnel) evitando con ello el spoofing o cambio de las direcciones IP de los paquetes. Es un estándar definido en los RFCs 4301-4303.

En este caso vulnerabilidad  se localiza en las tecnologías de transición de IPv4 a IPv6, en concreto en los túneles  que se usan para transmitir paquetes de versión 6 sobre redes IPv4. Las tecnologías de túneles que se contemplan son 6to4 que establece comunicación unicast a través de internet sobre IPv4,  ISATAP  o comunicación unicast dentro de una intranet IPv4  y Teredo (desarrollo de Microsoft, RFC 4380) donde la comunicación unicast es por internet IPv4 añadiendo soporte para redes con NAT.

En el caso de los túneles para IPv4 el paquete IPv6 se encapsula en un paquete IPv4 y por tanto con las mismas vulnerabilidades. Lo que debemos hacer es identificar los túneles y  proteger su tráfico en IPv4 con IPSec:
  • ISATAP fija el campo "IP Protocol" a 41------> Establecer IPSec para IPv4 si IP protocol=41 y proteger ese tráfico. Puede hacerse ya que al estar en una intranet podemos fijar la clave compartida por los extremos IPSec sobre ipv4
  • 6to4 también marca IP protocol a 41 pero atraviesa internet. 6to4  se identifica porque las direcciones tienen el prefijo 2002::/16 y son direcciones IPv6 que se encaminarán a través de ipv4 hacia otro domino 6to4 , para ello el router cuando debe recibe este prefijo sabe que dentro hay un destino 6to4 que tiene que atravesar IPv4 y que debe entegarlo a otro router que maneje los prefijos 2002::/16 y que tenga conectividad ipv4 (llamado relay 6to4). El relay se encargará enrutar el paquete por internet bajo IPv4 encápsulandolo en un paquete marcado con "IP=41". En este caso solo podremos usar IPSec para proteger ipv4 si el router Ipv6 y el relay 6to4 se encuentran en el mismo dominio administrativo de de red  y se supone que existe una confianza entre ambos como para compartir la configuración necesaria para establecer IPSec (autenticación). Si la organización no tuviese su propio relay 6to4 no podríamos usar IPSec (salvo que nuestro proovedor de relay nos diese confianza) . Sin IPSec,  la seguridad debemos basarla en el filtrado del tráfico en el router de relay y establecer reglas para que solo se admitan paquetes IP 41 con el prefijo anycast de nuestra red. O quizás en una VPN....
  • Teredo usa el puerto 3544 y encapsula el paquete IPv6 en un datagrama UDP----->Establecer IPSec para IPv4 si puerto origen o destino es UDP 3544 . Teredo no necesita una IP v4 pública en el destino para hacer llegar el paquete Ipv6 encapsulado ya que se basa en una solución cliente/servidor UDP



Notas de Seguridad en IPv6: Seguridad en la autoconfiguración de direcciones

Con la inevitable llegada de IPv6 llegarán nuevas amenazas para la seguridad de la información. Por ello, además de ir planeando la actualización de protocolos y equipos a IPv6 habrá revisar las implicaciones a nivel de seguridad, y teniendo en cuenta aquellas características necesarias de este protocolo debemos hacer hincapié en:

  1. Seguridad en Autoconfiguración  y autorización de direcciones. Amenaza de Denegación (DoS) o suplantación de identidad , Man in the Middle. (Disponibilidad, Autenticidad) 
  2. Seguridad en Protección de los paquetes IP. ( Confidencialidad, Integridad )
  3. Seguridad en Control del tráfico de y hacia internet. ( Autorización, control acceso )
Vamos a discutir estos tres aspectos a los que dedicaré una entrada independiente para cada uno.

Comencemos pues: 

  1. Seguridad en la Autoconfiguración y Autorización para las direcciones y configuraciones automáticamente asignadas

Bien, como sabemos, una de las novedades de IPv6 es la autoconfiguración de la dirección IP. Esto puede hacerse por dos métodos: stateless o stateful .

En la autoconfiguración stateless el host genera su  dirección IP bien a partir de su propia MAC o bien generando una direccion aleatoria. Durante este este proceso el host interroga al entorno de red  por si algún dispositivo está usando esa dirección. Además si está conectado a una red donde exista un enrutador recibirá de él el resto de parámetros, como puede ser el prefijo de red. Estas acciones se realizan siguiendo el protocolo Neighbor Discovery Protocol (NDP) descrito por el RFC 2461 y a través de  los mensajes Neighbor Solicitation, Neighbor Advertisement, Router Solicitation y Router Advertisement. 
Aquí ya surge la primera amenaza de un posible ataque de DoS  si un host malicioso interceptara y  propagase un mensaje de Neighbor Solicitation, informando que la dirección solicitada está en uso (ICMP 136) e impidendo el acceso a la red (DoS)
ATAQUE DoS

Neighbor Solicitation ICMP 135 (Duplicate Address Detection) y ataque con ICMP 136 (Direccion ocupada)

Del mismo modo el atacante pude hacerse pasar por un router estableciendo un ataque  Man in the Middle atacando al mensaje Router Solicitation (ICMP 133) con el Router Advertisement (ICMP 134).


En la configuración stateful, la dirección IP se obtiene por DHCPv6 (RFC 3315) que puede ser blanco también de los mismos ataques que la autoconfiguración stateless por alguien mailintencionado que generase los mensajes DHCPv6.

En resumen, el ataque de spoofing ARP de IPv4/icmp se convierte en un ataque NDP spoofing en IPv6/icmpv6
Mensajes informativos ICMPv6

Recomendaciones de Seguridad

Contra esta amenaza  de denegación o suplantación (DoS o Man in the Midle), concluimos que la solución pasa por autentificar al dispositivo en capa 2 antes de darle acceso a la capa de red que inicie la autoconfiguración de IP.
Una opción posible contra  este problema la ofrece el protocolo de capa 2 SEND (SEcure Neighbor Discovery, RFC 3971) que es una extensión de NDP, y que haciendo uso de criptografía asimétrica y firma electrónica autentifica un host antes de permitirle acceso a la capa de red . SEND aún no es implementado por muchos sistemas operativos, careciendo de él, por ejemplo  los de Microsoft (Vista, XP, Server 2008, Server 2003...).
Otra opción, esta ya más extendida y soportada por la mayoría de Sistemas  ( incluido Microsoft }:-)  ) es la autenticación en capa 2 manejada por el protocolo 802.1X basado en EAP  ( Protocolo de Autenticación Extensible RFC 2284 )que del mismo modo, provee la autenticación de un dispositivo en un switch (red cableada) o en un Punto de Acceso inalámbrico antes de permitirle mandar tráfico a la red. 

miércoles, 11 de mayo de 2011

Plan de implantación Ipv6 en España

El 29 de abril,el consejo de Ministros aprobó un Plan para el fomento de la implantación de Ipv6 a nivel nacional impulsado por el Ministerio de Industria, Turismo y Comercio. El Plan difundirá información didáctica sobre el nuevo protocolo de Internet, desarrollará acciones formativas y dinamizará en los agentes interesados los cambios tecnológicos que resulten necesarios para la incorporación efectiva de IPv6.

El Plan describe 10 puntos donde se definen las estrategias adoptadas para afrontar el paso a Ipv6 con apoyo de las administraciones públlicas, RedIris, jornadas de formación... Además se ha creado un portal web donde se ofrece seguimiento e información del Plan. Puede visitarse en http://www.ipv6.es/
Podremos encontrar mucha información útil tanto a nivel de usuario como de empresa así como un test para comprobar tu conectividad.

Aullidos binarios

martes, 10 de mayo de 2011

El protocolo del café

Hoy navegando por la ietf buscando estándares y borradores sobre dkim me llevé una sorpresa. El sueño me vencía y medio "groggy" pensaba en tomar un café para despejarme.... cuando entre líneas mientras avanzo páginas y páginas de búsquedas de RFCs me parece leer la palabra "coffee". Me detengo un momento y me digo.. puff si, necesito un café. Pero un momento.... CTRL+F.... buscar.. "coffe" ein?. RFC 2324... HTCPCP = Hiper Text Coffe Pot Control Protocol , si sí un RFC sobre un protocolo de hipertexto para controlar cafeteras!!!!


 Busco en la wiki y ahi está también !! .Alucinante, y esto está publicado desde 1998. Echad un vistazo por curiosidad al RFC, o a la entrada a la wiki. Implementa métodos GET, POST (BREW "infusionar café") , WHEN (para señalizar el vertido de leche)...e incluso mensajes de error no exentos de humor:
418: I'm a teapot (soy una  tetera)


Genial!!

miércoles, 4 de mayo de 2011

Esperando al hombre del medio con el ArpON en la mano

¿ Quién no ha sentido cierta inquietud cuando ha pensado en introducir sus contraseñas de acceso a alguna cuenta y estaba en una red no controlada?. Si, me refiero al miedo al  "hombre del medio" que hoy en día sirve para asustar más que "el hombre del saco".
En serio, a pesar de ser de los más antiguos y conocidos, el famoso ataque  "Man in the Middle" es uno de los más peligrosos para nuestra seguridad informática puesto que a pesar de su sencillez de concepto, su funcionamiento es impecable. Se basa en alterar nuestra tabla de resolución de direcciones MAC que se actualiza vía ARP de modo que a la víctima le hacemos creer que nosotros somos a quien debe mandar paquetes para enrutarlos, y por el otro sentido hacemos creer al gateway que nosotros somos la víctima. Es decir, hacemos de paso intermedio entre la víctima y el gateway, recogiendo y reenviado todo el tráfico entre ambos. De ahi, lo del hombre en el medio.

Hoy en Security by Default se publicaba un artículo comentando una herramienta para Linux llamada ArpON que actúa como un demonio y vigila nuestras interfaces de red para asegurar que no estamos siendo "spoofeados". El artículo lo escribe Alberto Ortega y podemos verlo en la página de SbD.

Merece la pena echarle un vistazo, y si eres usuario de Linux, tenerlo disponible entre tus "demonios".

lunes, 28 de marzo de 2011

NAT/PAT con Iptables

En una anterior entrega discutimos sobre los posibles opciones y sus características a la hora de diseñar una red segura que ofreciese servicios web  a Internet. EL empleo de NAT (Network Adress Translation) es un elemento común a la hora de poner una red interna con direcciones privadas tras un router con salida hacia internet. Además suele ir acompañada de las redirecciones de puertos, conocido como PAT (Port Adress Translation).  Con ello logramos que las direcciones/puertos internos sean "transparentes" hacia afuera ya que al ser enrutadas se las "enmascara" con la IP pública. NAT es por ello considerado una medida de seguridad, pero no es suficiente y debe ser complementado con un firewall. Vamos a mostrar el funcionamiento de NAT/PAT con un ejemplo usando un servidor Linux e iptables

Un diseño común y sencillo de topología utilizando un sólo firewall y sacándole el máximo partido es el siguiente:


Tenemos un firewall con 3 interfaces o "patas" (three-legged firewall). Una dirigida hacia el router de salida a internet,  otra para la DMZ y una tercera para la LAN interna.

NOTA: Quizás lo más estricto si pensamos en la red 192.168.1.0/24 como DMZ es que  estuviera delante del FW, en el segmento 172.28.0.0/24 (y ahorrar un interfaz de red, eth2). En ese caso la DMZ estaría directamente expuesta a internet sin ningún tipo de filtrado y es una opción que aunque válida nunca acabó de convencerme. El caso que presento es un firewall con   zonas de seguridad donde podemos  colocar distintos niveles de filtrado de forma mas ordenada para la LAN y la DMZ.  Este diseño de 3 patas, dentro de las topologias más simples (de un solo firewall) es lo recomendable.

Partiendo  de este diseño veamos unas breves indicaciones de como se implementaría el firewall y como haríamos NAT/PAT.

Bien, lo primero es preparar el kernel de nuestra máquina Linux de modo que pueda actuar como router, para ello debemos fijar los parámetros del kernel :

Paso 1: Preparar el kernel para actuar como router

net.ipv4.ip_forward = 1--------------------------> Nos permite reenviar paquetes entre interfaces (eth0-->eth1<-->eht2)

Añadimos por seguridad:
net.ipv4.conf.default.rp_filter =1------> Activar la verificacion de la ruta origen, rechaza si la IP no corresponde con el segmento esperado del interfaz 

Paso 2: Limpieza de IPtables
Limpiaremos cuaquier rastro de reglas de firewall y establecemos políticas por defecto.

iptables -F
iptables -X
iptables -Z
iptables -t nat -F

Paso 3: Políticas por defecto
Tenemos 2 opciones: Bien dejar la política por defecto a ACCEPT e ir cerrando acceso o bien denegar por defecto e ir aceptando conexiones. La opción más cómoda es la primera pero, a efectos de asegurar todo bien es mejor adoptar la denegación por defecto aunque ello suponga mucho más trabajo al tener que ir  habilitando lo necesario para tener una comunicación fiable (ICMP, DNS, SYN, MAIL, puertos espcíficos...)

Politica permitir por defecto:

iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT

O,

Politica denegar por defecto:


iptables -P INPUT  DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT


Paso 4: Escribir reglas del firewall.

Escojeremos la política de denegación por defecto al ser mas didáctica y  empezamos a filtrar...

Pero antes, aclaremos las nociones de reenvío y traducción de direcciones con NAT

Conceptos de NAT ( Network Adress Translation )

Reenvío  y enmascaramiento de la red interna

Para que los usuarios de la LAN puedan salir a Internet y obtener tráfico de vuelta, debemos establecer NAT ya que de lo contrario al regreso en el router WAN se encontraría con una dirección de destino 192.168.0.x que no sabría redirigirla al ser una red interna que desconoce.

Para ello enmascaramos la LAN y la DMZ:

iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/24 MASQUERADE   # (LAN)
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.1.0/24 MASQUERADE   # (DMZ)


Con ello decimos al firewall que cuando pase una direccion origen  de la LAN o la DMZ hacia el interfaz externo eth0 (172.28.0.254) la enmascare con esa dirección (NAT)

Ahora tenemos permitido el tráfico de la LAN y la DMZ  a internet, pero sin ningún tipo de filtrado y si la política es permisiva deberíamos filtrar las conexiones, de modo que se acepten solo si se originaron desde dentro.

Para la LAN una primera aproximación sería denegar las conexiones que no estuviesen originadas desde dentro, sustituyendo:

iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
por
iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED, ESTABLISHED -j ACCEPT

Así la conexión desde fuera entrará solo si previamente fue establecida o relacionada con un conexión desde dentro.

Traducción de direcciones de red con NAT


El uso de  NAT  permite a un firewall  modificar las direcciones de origen y destino de los paquetes así como  los puertos a los que van dirigidos.
Principalmente, encontramos 2 tipos de reglas NAT:
  1. Traducción de direcciones de red de destino: DNAT (cambiamos la IP destino del paquete)
  2. Traducción de direcciones de red de origen: SNAT (cambiamos la IP origen del paquete)
Con Iptables hay que recordar unas cuestiones muy simples pero importantes:
  • DNAT se utiliza con la cadena PREROUTING
  • SNAT se utiliza con la cadena POSTROUTING
  • Al modificar un paquete en el origen (SNAT) , la cadenas INPUT,FORWARD y OUTPUT ven la dirección de origen sin modificar
  • Si modificamos el paquete en destino  (DNAT) ,  las cadenas FORWARD e INPUT  ven la dirección modificada
Veremos algunos ejemplos de aplicación.

  1. Traducción de direcciones de red destino. DNAT. Acceso de clientes externos a servicios internos
Este tipo de traducción puede cumplir 3 objetivos:

A. Envío en representación transparente. Como si fuese un proxy transparente reverso
B. Reenvío a puertos .PAT
C. Balanceo de carga.

       A. DNAT como envío transparente
.
           Permite a los clientes usar una dirección interna "prestada", de ahí que digamos que es como un proxy            transparente. DNAT lo usaremos para ofrecer nuestros servicios a redes externas. 
Por ejemplo:
iptables -t nat -A PREROUTING -i eth0  -j DNAT --to-destination 192.168.1.50

Con esta regla redirigimos todas las peticiones y de cualquier puerto entrantes por eth0 a la máquina de la DMZ 192.168.1.50, es decir, traducimos(cambiamos) la dirección destino que recibimos (la del FW) por la de  la máquina destino interna que queremos reciba el paquete  . Ahora necesitamos PAT para filtrar el puerto

      B.  Reenvío a puertos. PAT

Por ej:
Filtramos un poco más para redirigir todo el tráfico entrante dirigido al puerto 80 al servidor web:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 192.168.1.50:80

Con esta regla, a todo paquete entrante se le cambia la IP destino y se manda a la IP y al puerto 80 del servidor web de la DMZ.

      C. Balanceo de carga

No es caso del ejemplo, pero imaginemos que tenemos 6 servidores Web (192.168.1.50 al 192.168.1.55) y queremos que las peticiones entrantes al puerto 80 se balanceen entre ellos:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.50-192.168.1.55

¿A que mola?

     2.  Traducción de direcciones de red de origen: SNAT.De clientes internos a servicios externos

SNAT es lo opuesto a DNAT, mientras que DNAT modifica las direcciones y puertos destino de los paquetes, SNAT lo hace con el origen de los mismos, es decir es la traducción de dentro hacia afuera. Observemos que con MASQUERADE ya hacíamos esto de forma generalizada para todos los hots, pero si queremos especificar debemos usar SNAT.

SNAT puede usarse para:
  • Comunicar con  máquinas internas que no tienen enrutado con otras redes o con internet
  • Permitir que varios hosts de la red interna compartan una dirección de salida.
  • Ocultar la verdadera IP de una máquina.
  • Resolver problemas que pueden surgir con DNAT.
 Como vemos hace justamente el inverso a DNAT. Si DNAT se ocupaba de los accesos de clientes externos a servicios internos, con SNAT damos comunicación desde clientes internos a servicios externos, traduciendo direcciones en origen en lugar de en destino. Podemos entender SNAT como proxy (transparente) y DNAT como  reverso.

Recordemos, siempre:

                  DNAT:                                                                                       SNAT:
cadena PREROUTING                                                        cadena POSTROUTING
-i interfaz                                                                              -o interfaz
modificar puertos y direcciones de destino:                        modificar puertos y direcciones  de origen:
-d , --dport y -to-destination                                               -s, --sport, --to-source

Ejemplo:

iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/24 -j SNAT --to-source 172.28.0.254

Esta regla proporciona SNAT para toda la red LAN interna traduciendo la dirección origen (192.168.0.x)  a 172.28.0.254, que será la que vean los hosts con los que comunica. Esta regla es equivalente a MASQUERADE ya que no especificamos ningún host/puerto y damos salida a toda la red.

Si solo quiséramos que un host (92.168.0.25) saliera a internet (puerto 80), la regla a aplicar sería:

iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.25 -p tcp --dport 80  -j SNAT --to-source 172.28.0.254

Si queremos dar salida a todos los hosts y hay mucho tráfico puede que nos quedemos sin puertos si solo estamos dando una dirección de salida. Podemos hacer NAT permitiendo varias:

iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/24 -j SNAT --to-source 172.28.0.250-172.28.254

Con esto nos hemos hecho una idea del uso de iptables para hacer NAT/PAT.
Estas reglas habría que ir complementándolas con más reglas para conseguir un filtrado y control eficaz del flujo de tráfico entre nuestra red e internet.
Por ejemplo el control de la salida hacia internet de los usuarios de la LAN, el control de las conexiones entre la DMZ y la LAN (por ejemplo, consultas hacia la BBDD desde el servidor Web), etc

Otro día profundizaremos un poco más y  añadiremos más reglas para formar un firewall completo

Ver tambien: