Configurar Mobile IPSec VPN con XAuth (Active Directory) en pfSense

En este post veremos como configurar una VPN para usuarios móviles en pfSense y autenticando con un dominio Active Directory a través de LDAP. De esta forma los usuarios podrán utilizar sus credenciales del dominio para acceder a la VPN, y podrán conectarse a la red utilizando tanto sus computadoras como sus dispositivos móviles, ya sean Android o iOS.

Servidor de Autenticacion

Lo primero que necesitamos es agregar nuestro controlador de dominio como "Autentication Server" o Servidor de Autenticacion en pfSense. Para este ejemplo, supongamos que tenemos un dominio llamado "midominio.com", que todos los usuarios están en el contenedor por defecto para usuarios de Active Directory "Users" y que nuestro controlador de dominio tiene la IP 10.0.0.10. Para agregarlo nos movemos a "System --> User Manager" y en esta ventana nos vamos a "Authentication Servers".

En esta ventana hacemos clic en "Add" para agregar los datos del controlador de dominio que autenticara los usuarios. Completamos los datos de esta ventana de esta manera:

• Descriptive Name: Nombre con el que identificaremos el servidor, por ejemplo, MyDominio

• Type: LDAP

• Hostname or IP: Nombre del host o dirección IP del controlador de dominio, en el caso de este ejemplo, 10.0.0.10

• Port Value: 389

• Transport: TCP - Standard

• Protocol version: 3

• Server Timeout: 25

• Search scope: One Level

• Base DN: DN Base del dominio, por ejemplo: "DC=midominio,DC=com"

• Autentication containers: aqui insertamos el contenedor o la OU donde están los usuarios a los cuales les permitiremos el acceso, por ejemplo, el contenedor Users: "CN=Users,DC=midominio,DC=com".

• Extended query: hacemos clic en la opción "Enable Extended query" y se habilitara la siguiente opción:

• Query: acá agregamos lo siguiente: "&(objectClass=user)" (sin las comillas). Con esto le decimos al sistema que solo consulte objetos que sean del tipo usuario.

• Bind anonymous: Esta opción debemos desactivarla para poder indicar un usuario del dominio que pfSense utilizara para conectarse al Controlador de Dominio y hacer la consulta. Al quitar la selección de este punto se habilitara la siguiente opción:

• Bind Credentials: acá indicamos el usuario y password que se utilizara para hacer la consulta en el controlador de dominio. En "User DN:" escribimos un usuario del dominio (puede ser un usuario creado para este fin, no necesita ningún privilegio especial), y lo insertamos en el formato dominio\usuario, por ejemplo: mydominio\pfsense. Luego en el campo "Password" como ya se imaginaran, se inserta el password para el usuario que indicamos previamente.

• Initial Template: Aquí seleccionamos "Microsoft AD".

Las demás opciones se dejan por defecto. 

Para probar la conexión al controlador de dominio, podemos hacer clic en el botón "Select a Container", si todos los parámetros están correctos debería abrir una ventana mostrando los demás contenedores y unidades organizativas (OU) que tenga definido el dominio. Luego para probar la autenticacion, hacemos clic en el menú superior en "Diagnostic --> Authentication". En "Authentication Server" seleccionan el servidor de autenticacion que acabamos de agregar (MiDominio) y luego insertamos las credenciales de algún usuario del dominio. Si pfSense puede autenticar correctamente el usuario verán una ventana como la siguiente:

En caso de que les presente un error autenticando, deben asegurarse de que el usuario que estén probando pertenezca al contenedor que se selecciono en la configuración del servidor de autenticacion. O sea, que se encuentre, por ejemplo, en el contenedor "Users" o en el OU que hayan seleccionado.

Configuración Mobile VPN

Una vez hemos definido nuestro servidor de autenticacion, nos movemos en el menu superior a "VPN --> IPsec" y luego hacemos clic en "Mobile Clients. En esta ventana completaremos de la siguiente manera:

• IKE Extension: Seleccionamos "Enable IPSec Mobile Client Support"

• User Authentication: Hacemos clic encima del servidor de autenticacion que definimos, para el caso de este ejemplo, seleccionamos "MiDominio". 

• Group Authentication: None

• Vritual Address Pool: Seleccionamos "Provide a virtual IP address to clients" e indicamos mas abajo el rango IP que asignaremos a los usuarios que se conecten via VPN, por ejemplo, 10.0.2.0 y en el campo de al lado seleccionamos 24

• Network List: Seleccionamos "Provide a list of accessible networks to clients"     

• DNS Default Domain: Seleccionamos "Provide a default domain name to clients",y mas abajo indicamos el nombre de nuestro dominio Active Directory, en el caso de este ejemplo seria "midominio.com"

• DNS Servers: Seleccionamos "Provide a DNS server list to clients" y mas abajo insertamos las direcciones IP's de los servidores DNS de nuestra red, por lo general sera la misma del controlador de dominio que agregamos como Servidor de Autenticacion.

Al hacer clic en "Save" veremos un mensaje como el siguiente, donde se nos indica que debemos crear los parametros de fase 1 (Phase 1) de IPSec para el VPN que acabamos de crear, haremos clic en el boton "Create Phase 1"

En esta ventana solo necesitamos modificar las siguientes propiedades:

• Description: Descripción o nombre para el tunel, podemos usar por ejemplo "VPN Usuarios"

• Authentication Method: Seleccionamos "Mutual PSK + Xauth"

• Negocitation Mode: Aggressive

• My Identifier: Podemos usar la opcion "IP Address" e indicar la IP externa de nuestro firewall, en este ejemplo usaremos "100.50.25.5".

• Peer identifier: Aqui indicamos como el usuario se identificara incialmente con el Firewall, podemos seleccionar "KeyID tag" y en el campo de al lado insertar "vpn-users"

• Pre-Share Key: El Firewall y el usuario se autenticaran mutuamente utilizando un password compartido o "Pre-Share Key", en esta sección indicamos este password. Para el caso de este ejemplo utilizaremos "MySuperPassword".

Las demas opciones las dejamos por defecto, pero necesitaremos conocerlas para configurar los clientes:

• Encription Algorithm:    AES - 256 bits
• Hash Algorithm:             SHA1
• DH Group:                      2 (1024 bit)
• Lifetime (Seconds):        28800
• Dead Peer Detection:      Enable DPD

Al hacer clic en "Save" iremos a la pantalla "Tunnels", veremos el tunel que acabamos de crear. Aquí haremos clic en el boton "Show Phase 2 Entries", luego en boton "Add P2" para agregar las opciones de la fase 2 de IPSec.

En esta sección seleccionaremos los siguientes parametros:

• Mode: Tunnel IPv4

• Local Network: LAN subnet

• NAT/BINAT Translation: None

• Description: Nombre para el tunel, podemos agregar "VPN-Usuarios"

• Protocol: ESP

• Encryption Algorithms: AES-256 bits

• Hash Algorithm: SHA1

• PFS key group: 2 (1024)

• Lifetime: 3600

Hacemos clic en "Save" y luego en el boton "Apply Changes" para aplicar los cambios. Al finalizar esta parte deberíamos ver ambas fases de la siguiente manera:

Con esto ya tenemos configurado el VPN en nuestro pfSense, ahora solo tenemos que configurarlo del lado de los clientes o usuarios. 

Configuración Cliente VPN en Windows

Para los usuarios Windows, usaremos el cliente IPsec de Shrew Soft que pueden descargar aqui. Este cliente IPsec es gratuito y muy fácil de instalar, básicamente es solo next, next, next. Pero tengan en cuenta seleccionar durante la instalación la edición "Standard", ya que la Professional requiere licencia y solo les funcionara por 30 dias. Una vez instalado el cliente, al hacer doble clic sobre "VPN Access Manager" verán la siguiente ventana:

Haremos clic en el boton "Add" para definir una nueva conexion. Los parametros que usaremos aqui son los mismos parametros que definimos en la configuracion del VPN en pfSense. En el primer tab de esta ventana insertaremos la IP publica del firewall, en este ejemplo utilizamos 100.50.25.5

Nos movemos al tab "Client", podemos dejar los valores por defecto que tiene:

El tab "Name Resolution" podemos dejarlo también con los valores por defecto que trae, y nos movemos al tab "Authentication". En "Authentication Method" seleccionamos "Mutual PSK+XAuth". En esta misma ventana, en el tab "Local Identity", como "Identification Type" seleccionamos "Key Identifier", esta fue la forma que indicamos en la configuración del VPN, e insertamos aquí el nombre "vpn-users". En esta misma ventana nos movemos al tab "Remote Identity" y seleccionamos "any", por ultimo nos movemos al tab "Credentials". En esta tab nos movemos a la sección "Pre-Shared Key", aqui escribiremos el password compartido que definimos en la configuración del VPN de pfSense, en este ejemplo utilizamos "MySuperPassword".

Luego nos movemos al tab superior "Phase 1". Aquí indicaremos los parámetros de la fase 1 que configuramos previamente en pfSense (Exchange Type: Aggressive, DH Exchange: group 2, Cipher Algorithm: aes, Cipher Key Length: 256, Hash Algorithm: sha1). Lo mismo hacemos en el tab "Phase 2" (Transform Algorithm: esp-aes, Transform Key Length: 256, HMAC Algorithm: sha1, PFS Exchange: group 2).

Por ultimo, nos movemos al tab "Policy". En este tab se indican las redes o equipos que accederemos a través de la VPN. Como le indicamos a pfSense que envíe el listado de redes, seleccionamos la opción "Obtain Topology Automatically or Tunnel All".

Hacemos clic en "Save" y con esto ya creamos nuestra conexión IPsec. Volveremos entonces a la ventana principal, pero ahora veremos un pequeño icono con la dirección IP publica del pfSense. Hacemos doble clic encima y veremos la ventana de conexión. Aquí insertamos nuestro usuario y password del dominio y hacemos clic en Connect.

Si todo esta bien, veremos una ventana como la siguiente. Al hacer la conexión el botón de "Connect" cambiara a "Desconect"

Con esto ya podremos tener acceso a los recursos de la red. Recuerden que deben habilitar una regla de Firewall que permita el trafico desde la red interna del firewall y el rango de direcciones que se asignara a los usuarios VPN. En el próximo post veremos como configurar el VPN en equipos Android y Iphones. Como siempre espero que esta información les haya sido de ayuda. 

Hasta el Próximo!

Inspeccion de Trafico HTTPS con WatchGuard XTM

Con WatchGuard podemos crear reglas de Proxy HTTP que inspeccionan el trafico de negación de los usuarios y nos permiten analizar el contenido. Esta inspección permite analizar los headers HTTP, el contenido de las paginas, aplicar antivirus, reglas de DLP que podría buscar patrones o palabras especificas en contenido de las paginas, etc., mas adelante se muestra la ventana de configuracion de una regla de proxy HTTP donde se muestra los diferentes chequeos que hace el equipo en el trafico HTTP. 

Opciones de análisis de trafico HTTP en reglas de Proxy

Pero con el trafico HTTPS es distinto. Como este trafico es encriptado, el equipo no puede hacer este tipo de análisis una vez se realiza la conexion. Lo único que podemos hacer es permitir o denegar el acceso a sitios Web en base al nombre de dominio, porque es la única información que el equipo puede ver, el nombre del site al que el usuario solicita la conexion. Así que el equipo permitirá la conexion al sitio pero no tendrá idea de lo que se este transfiriendo. 

• Inspección de Trafico HTTPS

Para prevenir esto, se utiliza la inspección de trafico HTTPS. Como la encriptacion se realiza utilizando el certificado SSL que envía el servidor al cliente (el certificado contiene la clave publica del servidor, que se utilizara para negociar la clave simétrica para encriptacion de todo el trafico), lo que hace el equipo al activarse esta opción es capturar este certificado que envía el servidor al cliente, generar el mismo otro certificado para el dominio que solicito el usuario y pasarlo al usuario como que es el certificado original. El computador cliente empieza entonces la negociación de encriptacion del trafico en base al certificado que le envío el Firewall. De esta forma el trafico se encripta entre el cliente y el Firewall, donde este entonces puede desenciptar porque es con su propio certificado que se encripto, y realizar el análisis al trafico. Luego el Firewall hace la conexion al servidor remoto utilizando el certificado original. El cliente cree que esta hablando con el servidor remoto, y el servidor remoto cree que esta hablando con el cliente. 

Para activar esto en WatchGuard, solo tenemos que editar la regla de proxy HTTPS y seleccionar la opcion "Enable deep inspection of HTTPS content" como se muestra a continuación. 

En la regla, hacer clic en el botón de edición del proxy

Una vez en la ventana de edicion de la regla de proxy HTTPS, se activa la opción "Enable deep inspection....", pueden seleccionar la opcion "Allow SSLv3". También verán que se activa una drop box llamado "Proxy Action", esto es para seleccionar la regla de proxy HTTP que se le aplicara al trafico una vez se desencripte. En el caso de este ejemplo la regla que seleccione se llama "ACCESO_INTERNET_NORMAL". Al trafico HTTPS de esta regla se le aplicaran los análisis que se definan en esta regla HTTP.

Activación inspección trafico HTTPS

• Importar Certificado CA WatchGuard

Al aplicar salvar la regla que modificamos anteriormente y aplicarla notaran que cuando intentan acceder cualquier sitio HTTPS les aparece un mensaje como el siguiente en el navegador:

Error de Certificado SSL en Internet Explorer

Esto significa que el cliente recibió el certificado SSL que genero el WatchGuard, pero no confía en este certificado. Si hacemos clic en "Continue to the website..." podremos acceder al site, pero esto no es algo que queremos que todos los usuarios tengan que hacer. Además, si utilizan Chrome, no tendrán esa opción de continuar. Para corregir esto lo que tenemos que hacer es importar el certificado que usa Watchguard para firmar los certificados que crea para cada dominio, el certificado CA. Para esto, una vez dentro de un sitio HTTPS, hacemos clic en la barra de navegación encima de "Certificate Error" y luego hacemos clic en "View certificates":

Esto nos mostrara información del certificado SSL que genero el Firewall para este site. Como podrán ver, indica el sitio para el cual se genero (en este caso *.google.com.do) y nos dice que el certificado no puede ser verificado con una autoridad certificadora de confianza. 

Como pueden ver, podemos instalar el certificado en el equipo haciendo clic en "Install Certificate", pero si instalamos este certificado, el mensaje de error dejara de aparecer solo para este dominio, para todos los demás sitios HTTPS seguirá apareciendo. Lo que necesitamos es agregar el certificado que usa WatchGuard para firmar todos estos certificados que genera como un CA de confianza, así que en la ventana anterior haremos clic en "Certification Path", donde podremos ver el certificado del CA:

Aquí podemos ver el certificado CA que uso el equipo Watchguard para generar y firmar, hacemos clic encima de el y luego hacemos clic en el boton "View Certificate", se nos mostrara una ventana similar a la del certificado para google.com.do, pero en este caso si haremos clic en "Install Certificate":

Al hacer clic en "Install Certificate" se abrirá el wizard para la importación de certificados. Hacemos clic en next en la primera ventana y luego hacemos clic en "Browse", donde indicaremos donde almacenaremos el certificado. Como queremos agregarlo como una CA de confianza, seleccionaremos "Trusted Root Certification Authorities": 

Al seleccionar la ubicación del certificado en la ventana "Select Certificate Storage", hacemos clic en OK y luego en Next. En la próxima ventana hacemos clic en "Finish", se nos presentara una ventana como la siguiente de confirmación de importación del certificado, donde haremos clic en "Yes":

Con esto ya hemos importado en este equipo el certificado CA de nuestro equipo WatchGuard, si cerramos el Internet Explorer y abrimos nuevamente algún sitio HTTPS veremos que ya no saldrá la alerta de que el certificado no es confiable:

En este punto, ya tenemos nuestro proxy HTTPS inspeccionando trafico cifrado y nuestro equipo confía en el certificado que le envía el WatchGuard, pero hay que tener en cuenta que por ahora solo este equipo confía en este certificado, los demás equipos de la red continuaran presentando la alerta de que no confía en este certificado. Lo que resta ahora es publicar este certificado a todas las computadoras del dominio con una Política de Grupo (GPO) para no tener que hacer este procesamiento en cada equipo de la red. En el próximo post veremos entonces como exportar este certificado y propagarlo mediante una GPO a todos los equipos del dominio.

IPSec Site-to-Site VPN entre WatchGuard XTM y Linux OpenSwan

Supongamos que tenemos que conectar 2 oficinas a traves una conexión VPN, en una de las oficinas tenemos un equipo WatchGuard XTM como Gateway y en la otra tenemos un equipo Linux con OpenSwan (que es una implementación de IPSec para Linux). Podemos hacer la conexión VPN entre estos 2 equipos (y la red detras de ellos) usando IPSec, solo tenemos que asegurarnos de configurar correctamente los parámetros de  IPsec para cada fase, de manera que en la negociación de los algoritmos criptograficos a utilizar ambos equipos puedan elegir protocolos compatibles. Hay que tener en cuenta que basicamente la conexión IPSec en modo tunel (que es el modo a utilizar cuando queremos crear un VPN) se realizara en 2 fases: en la primera fase (llamada "Main Mode") los 2 puntos se autenticaran uno a otro mediante una clave compartida  o certificados y negociaran los algoritmos de encriptacion a utilizar durante el intercambio de esta clave, y en la segunda fase se negociara la politica IPSec que utilizaran, por ejemplo, el tipo de trafico y las direcciones o segmentos de red en ambos lados que utilizaran el tunel. Esta es una explicación bastante resumida de todo lo que hace IPSec (a mi entender), si quieren entender mejor todo lo que hace IPSec les recomiendo visitar este link.

Para la autenticación entre los puntos de nuestro VPN utilizaremos una clave compartida o "Shared Key", e identificaremos cada punto por la IP externa de cada uno. Vamos a llamar al punto donde esta el WatchGuard XTM el punto A, y su IP sera la 6.6.6.6, la red que estará detrás de este equipo sera la 192.168.1.0/24. El punto donde esta el equipo Linux con OpenSwan sera el punto B y su IP sera 7.7.7.7, la red detras de este sera 192.168.2.0/24. La clave compartida que utilizaremos para autenticarlos sera "MiClaveVpn". Así que el escenario se veria mas o menos de esta forma:

Como ven, incluyo en el diagrama los routers instalados por el suplidor de Internet en ambos lados, mas adelante veran porque. Ya que tenemos claro el escenario, vamos a empezar la configuración desde el equipo WatchGuard, así que abriremos el "Policy Manager", en el menu superior hacemos clic en "VPN" y seleccionamos "Brach Office Gateways...":

En la ventana de "Gateways" que abrira, haremos clic en "Add" y nos abrira la siguiente ventana. En esta pondremos el nombre para esta conexión, para este ejemplo le puse "VPN01", insertaremos tambien aqui la clave compartida que definimos para esta conexión (MiClaveVPN). Luego haremos clic en el boton "Add" mostrado mas abajo:

En esta próxima ventana (mostrada en el siguiente grafico) insertaremos la información sobre los dos gateways, como la IP del punto remoto (OpenSwan) y la interface del WachGuard que utilizaremos para esta conexión. En la primera sección de esta ventana (Local Gateway) definiremos el ID de este punto para el tunel, que sera el nombre con el que se identificara el WatchGuard con el punto remoto. Seleccionamos la opción "By Domain Information" y hacemos clic en el boton "Configure" que se encuentra justo al lado, esto nos abrira una nueva ventana donde seleccionaremos "Domain Name", escribiremos al lado la IP con la cual llegaremos al otro punto (para el caso de este ejemplo seria "6.6.6.6") y hacemos clic en OK. Volveremos la ventana anterior donde seleccionaremos la interface externa del WatchGuard correspondiente a la IP con la cual haremos la conexión VPN (en el caso de este ejemplo, la interface externa utilizada se llama "Internet"). En la sección de mas abajo (Remote Gateway) indicaremos la IP del punto remoto, seleccionaremos "Static IP Address" e insertaremos la IP del punto remoto (para este caso 7.7.7.7). Luego al igual que en "Local Gateway" y seleccionaremos la opción "By Domain Information" y haremos clic en "Configure" para escribir en "Domain Name" la IP remota (7.7.7.7), este sera el nombre con el que WatchGuard esperara que se identifique el equipo Linux. Al final la ventana se veria de esta manera:

Hacemos clic en "Ok" y volveremos a la ventana inicial donde escribimos la clave compartida. En esta ventana haremos clic en el Tab "Phase 1 Settings". Desactivaremos la opción "Dead Peer Detection", se vera entonces de esta manera:

Hacemos clic en "OK" y con esto hemos configurado los Gateways para esta conexión, ahora definiremos el "Tunel" que usara estos Gateways, donde indicaremos las redes detrás de cada Gateway y la dirección del trafico, o sea, si el trafico sera en una sola dirección o en ambas. Para este caso, y quizas para la mayoría, sera en ambas direcciones (bidireccional).  Hacemos clic nuevamente en "VPN" del "Policy Manager", seleccionamos "Brach Office Tunnel..." y luego hacemos clic en "Add". Debemos ponerle un nombre a esta Tunel un nombre, podemos nombrarlo "TUNEL-01", debajo seleccionaremos el Gateway que utilizaremos, que es el que creamos anteriormente "VPN01". Luego hacemos clic en el boton "Add" para indicar cuales seran las redes que transitaran por el tunel. En la local agregaremos "192.168.1.0/24" y en la remota "192.168.2.0/24", nos aseguramos que en la sección "Direction" este indicado "<==>", que indica que el trafico sera bireccional, y luego hacemos clic en OK. Luego hacemos clic en el tab "Phase 2 Settings", en la sección "IPSec Proposals" veremos agregado "ESP-AES-SHA1" por defecto. Agregaremos a esta lista dos mas haciendo clic en "Add", estas seran "ESP-3DES-SHA1" y "ESP-DES-SHA1". Hacemos clic en "OK" y ya tenemos configurado el Tunel para nuestra conexión, al final la ventana del tunel que creamos se veria de esta manera:

Ahora podemos guardar y aplicar la configuración en el WatchGuard y pasar entonces al equipo Linux con Openswan. Primero vamos a asegurarnos que IPTables este configurado adecuadamente, si necesitan un repaso de IPTables les recomiendo que visiten este post. Debemos tener una regla INPUT para la interface externa que permita el trafico UDP a los puertos 4500 y 500 desde la IP 6.6.6.6 (damos por sentado que ya tiene OpenSwan instalado). Si usan una regla "MASQUERADE" asignar la IP externa del equipo al trafico saliente a Internet, o si usan "SNAT", tendrán que hacer una excepcion para que el trafico que se dirija a la red remota con la cual nos conectaremos via VPN no vaya a ser afectada por el NAT configurado por estas reglas, la regla seria de esta manera:

iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -d ! 192.168.1.0/24 -j SNAT --to-source 7.7.7.7

Con esto le decimos a IPTables que enmascare cualquier trafico saliente de la red con excepción del trafico que vaya dirigido a la red remota. Basicamente esto es lo necesario en IPTables, vamos ahora a la configuración de OpenSwan. El archivo de configuración se encuentra en /etc/ipsec.conf, aqui configuraremos los parámetros de IPSec, como los puntos del VPN, las redes a enlazar, etc. el contenido de este archivo para este ejemplo seria el siguiente:

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

# basic configuration

config setup

        # NAT-TRAVERSAL support, see README.NAT-Traversal

        nat_traversal=yes

        protostack=netkey

        nhelpers=0

        uniqueids=yes

# Add connections here

conn $default

        keyingtries=3

conn vpn-watchguard

        authby=secret

        left=6.6.6.6

        leftsubnet=192.168.1.0/24 

        leftnexthop=6.6.6.5

        leftid=@6.6.6.6

        right=7.7.7.7

        rightid=@7.7.7.7

        rightnexthop=%defaultroute

        rightsubnet=192.168.2.0/24

        type=tunnel

        auto=start

        pfs=no

#Disable Opportunistic Encryption

include /etc/ipsec.d/examples/no_oe.conf

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------          

Todo lo que es "left" se refiere al otro lado de la conexión VPN. La sección "leftnexthop" que señalo en negrita de la configuración anterior, indica el proximo salto antes de llegar al equipo al equipo que manejara el VPN del otro lado del tunel (en este caso el WatchGuard), generalmente habra un router delante que es quien le da la conexión a Internet, como se muestra en el diagrama de mas arriba. El resto de esta configuración es bien descriptiva así que podemos continuar. El siguiente paso sera configurar el "Share Key" o clave compartida para esta conexión VPN, para esto editaremos el archivo "/etc/ipsec.conf" y agregaremos la siguiente linea:

@7.7.7.7 @6.6.6.6 : PSK "MiClaveVPN"

Con esto ya tenemos nuestro OpenSwan configurado para la conexión (mucho mas rapido verda?). Antes de iniciar el tunel, vamos a verificar que esto este bien con Openswan, ejecutaremos el comando "ipsec auto verify" y si todo esta bien deberia devolvernos algo como esto:

Ahora para iniciar nuestro tunel podemos ejecutar desde este equipo el siguiente comando:

#ipsec auto --start vpn-watchguard 

Ya debe estar arriba nuestro VPN entre WatchGuard y OpenSwan, podemos verificarlo ejecutando "ipsec auto --status", aparecerán varias lineas, pero las que buscaremos serán las siguientes:

Y con esto ya tenemos nuestras redes conectadas via VPN a traves de dos equipos diferentes usando el standard IPSec. En caso de que les de algún error les recomiendo hacer el debugging desde Linux, pueden buscar en el archivo /var/log/auth.log ya que en este archivo Openswan va registrando cada actividad y es mas facil seguir cualquier error. 

Estudiando para el Examen 70-648: Un poco de IPv6

Como el titulo de este post dice, me encuentro estudiando para el examen de Microsoft 70-648, este examen es para migrar la certificación MCSA de Windows Server 2003 a Windows Server 2008, ahora llamados "Microsoft Certified Techology Specialist", ya que cambiaron el nombre de las certificaciones. Como ya soy MCSA en Server 2003 el tomar este examen me economiza 2 exámenes para certificarme como  "MCITP: Server Administrator", el 70-640 y el 70-642, y solo me faltaría tomar el 70-646. Si quieren mas información sobre esta certificación pueden visitar este sitio. Bueno, el caso es que compre el libro de preparación para este examen y ya empece a leerlo. Hay muchas cosas que permanecen igual que en Windows Server 2003, pero también hay cosas nuevas y mejoradas, como se ira viendo mas adelante. Decidí entonces ir haciendo un resumen de cada lección del libro, esto me ayuda a mi a retener mejor cada lección (ya que encuentro que escribirlas me ayuda a aprender mas fácil mas que solo leer), y también les sirve a cualquiera de ustedes que también este pensando en tomar este examen, o que simplemente quieran refrescar cosas que ya saben.

La primera lección es sobre configuración de IPv4 e IPv6, pero no se habla mucho sobre IPv4, ya que se da por sentado es que algo que un MCSA debe manejar, cosas como las clases de IPv4, Subneting, VLSM y direcciones APIPA. Hace mas hincapié en la configuración de IPv6 y eso es lo que haré en este post. Esto no sera una explicacion completa del protocolo IPv6, solo sera un resumen de lo que es necesario saber para configurar IPv6 en Windows Server 2008.

• Porque  necesitamos IPv6?

Los bloques de direcciones IPv4 publicas se están acabando, gracias a NAT se ha podido extender la vida del protocolo IP versión 4 que todos conocemos pero ya se están agotando las direcciones IPv4 publicas y la migración a IPv6 cada dia se hace mas necesaria. Como saben IPv4 ofrece aproximadamente 4.3 billones de direcciones, ese era un numero grande hace unos años atrás, pero hoy día no son suficientes ya que una sola persona puede tener varios dispositivos conectados a Internet y cada dispositivo necesitara una IP para salir a Internet. Este es el principal problema (diria yo) que viene a corregir IPv6, la cantidad de direcciones IP. Dado que una dirección IPv4 es un numero de 32 bits y que cada uno de estos 32 bit solo puede tener 2 valores (1 o 0), IPv4 nos ofrece un espacio de direcciones disponibles de 2^32,  que serian unos 4,294,967,296 direcciones.  Del lado de IPv6 las direcciones están compuestas por 128 bits en lugar de 32. Siguiendo la misma lógica anterior tendríamos 2^128, lo que seria igual a 340,282,366,920,938,463,463,374,607,431,768,211,456 o mejor expresado 3.4 x 10^38 direcciones IP disponibles, lo cual parece ser  una cantidad suficiente de direcciones no creen?.

• Sintaxis de una dirección IPv6

Las direcciones IPv6 no se expresan de la manera en que expresamos las direcciones IPv4 tradicionales; los 32 bits de la dirección eran separados en 4 grupos de 8 bits (binarios) convertidos a números decimales separados por puntos, como "192.168.1.2". Ahora con IPv6 los 128 bits se dividen en 8 grupos de 16bits pero en lugar de ser expresados en forma decimal son expresados en notación Hexadecimal, de la siguiente manera:

21dc:0053:0000:0000:03ad:003f:af37:8d62

Pero esta representación puede ser simplificada eliminando los ceros (0) que encabezan cada bloque, utilizando esto la dirección anterior pudiera expresarse de la siguiente manera:

21dc:53:0:0:3ad:3f:af37:8d62

Otra forma de simplificar las direcciones IPv6 es sustituir los bloques continuos que están compuestos solo de ceros por 2 puntos seguidos, o sea. "::". Por ejemplo, en la dirección del ejemplo, el 3er y 4to bloque (de izquierda a derecha) esta compuesto solo de ceros, por lo que podemos sustituir estos 2 bloques por "::",  quedaría entonces de esta forma:

21dc:53::3ad:3f:af37:8d62 

Hay que tomar en cuenta tambien que en IPv6 la mascara de red ya no se expresa de la forma tradicional de IPv4, en forma decimal separados por puntos (255.255.255.0). Ahora se expresan siempre como se expresan con CIDR (Classless Inter-domain  Routing), con la notacion usando "Slash" ("/"), por ejemplo "/64". La antigua notación de la mascara no se utiliza en IPv6.

• Tipos de Direcciones IPv6

En IPv6 tenemos 3 tipos de direcciones, Unicast, Multicast y Anycast:

- Direcciones Unicast: Al igual que en IPv4, las direcciones Unicast son direcciones que identifican un host, solo que ahora en IPv6 no identifican un host sino una "interface". En IPv4 un equipo era identificado por una IP y en algunos casos un equipo podría tener varias direcciones IP (multihome). En IPv6 la IP identifica únicamente una interface en especifico en el Host, y esto es lo que identifican las direcciones Unicast. Estas son las direcciones IP que utilizamos mas frecuentemente en una red o en Internet. Un paquete dirigido a una dirección Unicast sera recibido solo por una interface en la red.

- Direcciones Multicast: Este tipo de direcciones también se utilizan en IPv4, identifican múltiples interfaces. Un paquete dirigido a una dirección Multicast sera recibido por varios equipos (o interfaces).

- Direcciones Anycast: Este tipo de direcciones no se encuentra en IPv4, es intrucido por IPv6. Al igual que las direcciones Multicast las direcciones Anycast indentifican varias interfaces, con la direferencia de que el paquete enviado a una de estas direcciones no sera recibida por todas las interfaces que posean esta direccion sino únicamente por la mas cercana (en terminos de routing) al origen del paquete. Es algo entre una direccion multicast y una direccion unicast ya que el paquete es recibido por una sola interface. Este tipo de coomunicacion se le llama "uno-a-uno-de-muchos" (one-to-one-of-many).

• Direcciones Unicast

Dentro de las direcciones Unicast, que como dijimos son las que se utilizan para comunicaciones uno-a-uno, tenemos 3 tipos principales de direcciones, Global, Link-Local, Site-Local y direcciones Especiales.

- Global Unicast: Las direcciones Global son las direcciones equivalentes a las direcciones publicas de IPv4, o sea que estas direcciones son ruteadas en Internet. Estas direcciones se reconocen porque el prefijo siempre es "001". Estas direcciones están formadas de la siguiente manera: Como dijimos, los 3 primeros bits de la dirección o "Format Prefix" o "FP", que siempre es "001". Los siguientes 13 bits son asignados por IANA, esto es conocido como "Top Level Aggregator" o "TLA", estos son asignados a los registers de Internet y estos a su vez los asignan a grandes proveedores de Internet o ISP. Luego siguen 8 bit que se encuentran reservados. Le siguen 24 bits contienen el "Next Level Aggregator" o "NLA", estos identifican a clientes o sitios específicos, estos permiten a los ISP crear múltiples niveles de jerarquía dentro de su red para organizar el direccionamiento y el enrutamiento. Luego siguen los 16 bit del "Site Level Aggregator" o "SLA" que se utilizan para identificar subredes dentro de una organización, también son utilizados por ISP's menores. Los últimos 64 bits identifican la interface, a estos se les llama "Extended Unique Identifier" o "EUI-64".

- Link-Local: Estas direcciones son equivalentes a las direcciones APIPA en IPv4, el limite o alcance de estas direcciones es el link local, o sea, la red interna, por lo que NO son ruteadas. Se pueden identificar por su prefijo "fe8". Esta dirección es configurada automáticamente.

- Site-Local: Estas direcciones son equivalentes a las direcciones privadas de IPv4, o sea, las direcciones que usamos a diario en redes internas como "192.168.1.0" o "10.0.0.0". El prefijo de estas direcciones es "fec0".

- Especiales: Hay 2 direcciones especiales, iguales a 2 direcciones especiales usadas tambien en IPv4, la dirección "loop-back" y la llamada dirección "no especificada" o "unspecified". La dirección de "loop-back" en IPv4 es "127.0.0.1", ahora en IPv6 es "0:0:0:0:0:0:0:1" o expresada de manera simplificada "::0". La dirección "no especificada" en IPv4 se expresa como "0/0", en IPv6 ahora se expresa "0:0:0:0:0:0:0:0" o de forma simplificada seria "::".

• Direcciones Multicast

Como decíamos al inicio, las direcciones Multicast pueden ser usadas por varias interfaces, lo que permite que un paquete sea dirigido a varios equipos o Interfaces, a diferencia de las direcciones Unicast en las que el paquete es destinado a una sola interface. Las direcciones Multicast se reconocen porque siempre empiezan con 11111111 o "ff".

Bueno, hasta aquí lo que considero mas importante del contenido de IPv6, y creo que es lo mas importante a tener en cuenta para ir adaptandonos a IPv6. Espero que les sea de utilidad, sobre todo si piensan como yo tomar el examen 70-648. Mas adelante seguiré subiendo resúmenes de los demas capitulos a medida que vaya avanzando.

Un Poco de IPTables (Parte 2)

En el post anterior sobre IPTables vimos de manera rápida lo que, a mi entender, es necesario conocer antes de empezar a utilizar IPTables. Ahora les voy a decir las cosas que he aprendido de IPTables. Las funciones del Firewall de Linux están integradas en el Kernel del sistema operativo en un modulo llamado “NetFilter”, este modulo del kernel se maneja a través de un conjunto de herramientas llamadas iptables que utilizamos para crear las reglas de Firewall. iptables también es el comando que se utiliza para modificar o crear estas reglas. Este comando nos permite definir reglas las cuales se aplicaran a los paquetes basándose en la información de la cabeceras (o headers) de los protocolos, y nos permiten indicarle al Kernel la acción que queremos que realice sobre los paquetes, estas acciones pueden ser, por ejemplo, aceptar el paquete, rechazarlo, entre otras. Cada paquete que llega al equipo es comparado con cada una de estas reglas en el orden en que estén definidas, hasta encontrar un "match", o sea, hasta que el paquete coincida con una de las reglas con las cuales se esta evaluando. Cuando el paquete coincide con lo que describe la regla, entonces se ejecutara la acción que la regla especifica para ese tipo de paquete.

Estas reglas están organizadas en grupos llamados "Cadenas". Las cadenas (o "chains" en ingles) son agrupaciones de reglas, todas estas reglas comparten características comunes, por ejemplo, hay una cadena de reglas que se aplicaran solamente a los paquetes que se dirigen hacia el equipo que corre IPTables, otra cadena compara los paquetes salen del equipo que ejecuta IPTables hacia cualquier otro equipo. Las cadenas a su vez están organizadas o agrupadas dentro de "Tablas". En IPTables existen básicamente 3 tablas: MANGLE, NAT, y FILTER. Cada una de esas tablas contiene su respectivo grupo de cadenas que realizan diferentes operaciones en los paquetes:

• Filter: esta es la tabla por defecto y es la que se utiliza para las tareas de filtrado de paquetes. Esta es la regla que mas utilizaremos, y donde se definen las reglas que permitirán o no el acceso de los paquetes al equipo que corre IPTables o a la red.
• Nat: esta tabla se utiliza para alterar las direcciones y los puertos de los paquetes y crear reglas de NAT (Network Address Translations) en el equipo.
• Mangle: esta tabla también se utiliza para la alteración de paquetes, pero alteraciones mas especificas, como QoS. No es muy común su uso, particularmente nunca he tenido que utilizarla.

Como había mencionado, estas tablas contienen "cadenas". Cuando el equipo recibe un paquete, el paquete pasa por las 3 tablas de IPTables pero no necesariamente por todas las cadenas que contienen las tablas. El kernel analiza el paquete y lo envía a la cadena que corresponda. La tabla "Filter" contiene por defecto 3 cadenas:

• INPUT: las reglas contenidas dentro de esta cadena se aplicaran solamente a los paquetes destinados al equipo que ejecuta IPTables. Por ejemplo, supongamos que en nuestro equipo Linux instalamos un servidor Web y lo configuramos para que escuche en el puerto TCP 89 y queremos descartar cualquier paquete entrante a nuestro equipo que no sea destinado a ese puerto. En esta cadena es donde debemos crear la regla que permita acceso al puerto TCP 89 y descarte todo lo demás. Mas adelante veremos como crear las reglas.
• FORWARD: las reglas que contiene esta cadena se aplicaran a los paquetes que son ruteados a través de nuestro equipo. Esto es en el caso de que instalemos nuestro equipo Linux con IPTables configurado entre dos redes, o por ejemplo, entre Internet y nuestra red interna, donde los paquetes pasaran por el Firewall para llegar a la red interna, o desde la red interna hacia el Internet. Aquí definíamos reglas como por ejemplo, que ninguna computadora de nuestra red pueda conectarse a un determinado equipo en Internet.
• OUTPUT: esta cadena contiene las reglas que se aplicaran a los paquetes que salgan desde el mismo equipo, o sea, los paquetes generados localmente.

La tabla NAT también contiene 3 cadenas por defecto:

• PREROUTING: esta cadena contiene las reglas que modificaran el paquete al momento de entrar al equipo. En esta cadena crearemos las reglas que, por ejemplo, cambiaran el puerto y la IP de destino de paquetes destinados a equipos en nuestra red interna.
• OUTPUT: esta contiene reglas para modificar los paquetes generados internamente en el equipo antes de ser enrrutados.
• POSTROUTING: esta cadena contiene las reglas que modificaran los paquetes que saldrán del equipo una vez que se han tomado las decisiones de ruteo de hacia donde se enviara el paquete.

Esas son las cadenas por defecto de la tabla Filter y Nat, pero podemos también crear nuestras propias cadenas si queremos. Cuando IPTables evalúa los paquetes contra cada una de las reglas contenidas dentro de estas cadenas y no encuentra una regla que coincida con el paquete, entonces tomara una "Acción por Defecto" la cual es definida en cada cadena. Podemos por ejemplo especificar que la acción por defecto de la cadena "INPUT" sea descartar el paquete, en este caso, si al analizar un paquete destinado a nuestro firewall no se encuentra una regla que coincida con el paquete, el paquete sera descartado.

Bien, creo que eso ha sido suficiente preámbulo, ahora vamos a ver como crear algunas reglas básicas de IPTables, estoy seguro que luego de ver un par de estas reglas se entenderá mejor todo esto. La mejor forma de entenderlo es con casos de uso prácticos, y para este caso voy a utilizar un caso de uso de IPTables básico y muy común. Observemos el siguiente gráfico: 

Tenemos nuestro equipo Linux corriendo IPTables funcionando como firewall. Nuestro firewall tiene 2 tarjetas de red, con una conecta a la red Interna (192.168.1.1) y con la otra conecta a Internet (172.23.45.7). Vamos a configurar IPTables de forma de que los equipos de la red interna tengan acceso a Internet a través de nuestro Firewall. Lo primero que vamos a hacer sera crear una regla en la tabla NAT y configurar Network Address Translation (NAT) en nuestro equipo, de modo que los equipos de la red interna compartan la dirección IP de Internet de nuestro Firewall. Para esto ejecutamos:

root@firewall:~# iptables -F

root@firewall:~# iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -d 0/0 -j MASQUERADE

Ahora la explicación de las reglas que creamos anteriormente:

iptables: Este es el comando que permite agregar las reglas al modulo netfilter

-t: Esta opción especifica la tabla que vamos a modificar, en este caso la tabla NAT.

-A: especifica la cadena en la que se quiere agregar la regla, en este caso cadena POSTROUTING.

-s: Esta opción especifica el origen de los paquetes que se rutearan, en este caso es la red interna.

-d: Esta opción específica el destino al cual se dirigen los paquetes.

-j: Esta opción se utiliza para decirle al Firewall que acción tomar con los paquetes que coincidan con lo antes citado.

Lo hicimos con la primera linea de comando fue borrar cualquier otra regla que haya sido creada en nuestro firewall utilizando el comando "iptables -F". Luego creamos una regla en la cadena POSTROUTING (usando la opción "-A") de la tabla NAT (usando la opción "-t"), esta regla le indica a IPTables que los paquetes provinientes de la red 192.168.1.0/24 (usando la opción "-s" que significa "source" u "origen") y que se dirijan hacia cualquier destino, o sea, hacia Internet (utilizando la opción "-d" que significa "destino") se les aplique la acción "MASQUERADE" (utilizando la opción "-j"). Esta acción hace que el firewall altere los paquetes que saldrán a Internet y que proceden de los equipos de red interna cambiando en el header del paquete el campo "IP de origen" sutituyendola por su propia dirección IP externa (172.23.45.7). De esta forma, los paquetes salen a Internet como si se originaran desde nuestro Firewall, o sea, hemos configurado NAT en nuestro equipo. Pero esto no es todo, para que los equipos de la red interna puedan salir hacia Internet a través de nuestro Firewall debemos crear reglas de FORWARD en la tabla FILTER. Supongamos que vamos a permitirles a los equipos de la red interna que puedan navegar en Internet, para esto necesitamos permitirles conexiones al puerto TCP 80 (puerto de http) a cualquier equipo en Internet. Para esto ejecutamos:

root@firewall:~# iptables -t filter -A FORWARD -p tcp -s 192.168.1.0/24 -d 0/0 --dport 80 -j ACCEPT

Como de lo que se trata ahora no es de modificación de paquetes, sino de determinar cuales paquetes estarán permitidos a salir de la red a través de nuestro Firewall, utilizaremos la tabla "Filter" y la especificamos utilizando la opción "-t filter". Como los paquetes que se analizaran no son dirigidos al firewall mismo sino que serán ruteados a través de el utilizaremos la cadena FORWARD, y la especificamos con la opción "-A FORWARD". Ahora bien, el tipo de paquete que permitiremos serán paquetes TCP, por lo que utilizamos la opcion "-p tcp". Utilizamos nuevamente las opciones "-s" y "-d" para especificar el origen y destino de los paquetes (192.168.1.0/24 y 0/0 respectivamente). Luego utilizamos la opción "--dport" para especificar el puerto de destino del paquete, para el caso de nuestra regla como estaremos permitiendo las conexiones a servidores Web en Internet, el puerto http es el puerto 80. Por ultimo especificamos la acción que queremos que ejecute IPTables sobre los paquetes que coincidan con la regla que acabamos de definir, en este caso aceptaremos que los paquetes salgan hacia Internet, por eso indicaremos la acción "ACCEPT". Vamos a hacer otro ejemplo, supongamos que queremos evitar que la computadora con la IP 192.168.1.2 haga conexiones FTP a un servidor en Internet con la IP 66.77.88.99, vamos a hacer una regla que bloque este tipo de trafico solo para esa IP pero que permita a las demás hacerlo:

root@firewall:~# iptables -t filter -A FORWARD -p tcp -s 192.168.1.2 -d 66.77.88.99 --dport 21 -j DROP

root@firewall:~# iptables -t filter -A FORWARD -p tcp -s 192.168.1.0/24 -d 66.77.88.99 --dport 21 -j ACCEPT

Como las reglas se van evaluando en el orden en que van siendo creadas, lo primero que hice fue crear la regla que bloquea el acceso al equipo especificado, como ven especifique la acción "DROP", esta acción bloqueara los paquetes que coincidan con lo que especificamos en la regla. Luego cree una regla que permite a cualquier otro equipo el trafico FTP pero solo lo permite al equipo especificado (66.77.88.99).  Supongamos ahora que instalamos SSH en nuestro Firewall para tener acceso remoto a el desde Internet. Tenemos que crear una regla en IPTables para que este permita conexiones SSH al equipo a través de su IP externa, para esto ejecutamos:

root@firewall:~# iptables -t filter -A INPUT -p tcp -s 0/0 -d 172.23.45.7 --dport 22 -j ACCEPT

Como pueden ver ahora utilizamos la cadena INPUT, porque se trata de paquetes que irán dirigidos al Firewall, no a algún equipo detrás de el. Como queremos conectarnos desde Internet y puede que no siempre lleguemos a nuestro firewall usando la misma dirección IP, indicamos en el "source IP" (opción -s) "0/0" esto le indica a IPTables que las conexiones pueden ser desde cualquier dirección IP. Supongamos ahora que no queremos que desde Internet se pueda acceder al servidor SSH que tenemos corriendo en nuestro Firewall, sino que solo se pueda acceder a este desde la red interna. Para esto tendríamos que crear 2 reglas, una que bloque el acceso SSH desde Internet y otra que lo permita desde la red interna:

root@firewall:~# iptables -t filter -A INPUT -p tcp -s 0/0 -d 172.23.45.7 --dport 22 -j DROP

root@firewall:~# iptables -t filter -A INPUT -p tcp -s 192.168.1.0/24 -d 192.168.1.1 --dport 22 -j ACCEPT

Ok, supongamos que ya hemos creado las reglas que necesitamos en nuestro Firewall, ahora debemos especificar la acción por defecto que queremos para cada cadena. Como les mencione la acción por defecto es la acción que tomara IPTables sobre los paquetes que no coincidan con ninguna de las reglas especificadas en la cadena. Le diremos a IPTables que descarte todo paquete que no coincida con ninguna regla, para esto ejecutamos:

root@firewall:~# iptables -t filter -P INPUT DROP

root@firewall:~# iptables -t filter -P FORWARD DROP

Utilicé la opción "-P" para definir la acción o política por defecto, como ven utilice 2 comandos, uno por cada cadena. Ahora, para ver las reglas que se han definido en el firewall ejecutamos el siguiente comando:

root@firewall:~# iptables -nL

Si ejecutamos este comando tal como esta aquí, nos mostrara solamente información de la tabla FILTER, que es la tabla por defecto. Si queremos información sobre otra tabla solo tenemos que incluir la opción "-t" y el nombre de la tabla que queremos. Bueno, hasta aquí este intento de tutorial de IPTables, espero que hayan podido entender mis explicaciones y que los minutos dedicados a leer esto no hayan sido en vano. Mas adelante continuare hablando sobre otras cosas de IPTables, como por ejemplo, como cargar las reglas al iniciar el equipo, como hacer "baclup" de las reglas que hemos definido, módulos, etc.

Un Poco de IPTables (Parte 1)

Hace un par de años, cuando empezaba a dar mis primeros pasos en Linux (en los cuales todavia estoy), escuchaba a algunas personas que hablaban de IPTables como algo dificil y complicado, no muy facil de entender por los simples mortales. Hasta que me toco (al mas simple de los mortales) empezar a estudiar sobre IPTables y note que no existia tal complejidad, claro, afortunadamente antes de empezar a "meter mano" con IPTables ya habia aprendido algo de redes y sobre todo de TCP/IP, entonces me di cuenta de que talves la razon por la que algunas personas encuentran complicado IPTables es porque no saben como trabaja TCP/IP o saben muy poco sobre el protocolo. Asi que creo que antes de empezar a hablar de IPTables debemos entender lo basico TCP/IP y entender como viajan los datos a traves de la red, asi entenderemos el trabajo de IPTables y veremos que el configurar sus reglas no es nada del otro mundo. 

Empecemos entonces con lo basico, una breve y resumida explicacion de TCP/IP. TCP/IP es un conjunto de protocolos que permite la transmision de datos en una red. Este es el protocolo en el cual esta basado Internet. En las redes TCP/IP la informacion es transmitida en "paquetes", o sea, los datos que se van a transmitir por la red son separados en "pedacitos" y transmitidos a traves del cable. TCP/IP esta divido en 4 capas, en cada una de estas capas de agrupan diferentes protocolos (de ahi el hecho de que es un "Conjunto" de protocolos). La primera capa (de arriba hacia abajo) es la capa de aplicacion, esta es la capa donde se generan los datos. Se encuentran los protocolos HTTP, POP3, FTP, DNS, etc. como pueden ver, son los protocolos que a diario utilizamos para navegar, descargar emails, descargar o transmitir archivos, etc. Luego se encuentra la capa de "Transporte". Esta capa se encargar de gestionar el transporte de los datos y asegurarse de que no hayan errores en la transmision, se encarga de crear una especie de "circuito virtual" con el equipo que recibira o transmitira la informacion. En esta capa se encuentran los protocolos TCP y UDP. Luego sigue la capa de "Red". Esta capa se encarga del enrutamiento o encaminamiento de los paquetes y de su direccionamiento. En esta capa  trabaja el procolo IP (me imagino que muchos de ustedes han configurado "direcciones IP"). Por ultimo, se encuentra la capa de "Acceso al medio" o capa "Fisica". Esta es la capa que se encarga de, digamos, "escribir" los datos en el cable. En esta capa se encuentra, por ejemplo, el protocolo Ethernet.

A medida que los paquetes pasan de una capa a la otra, los protocolos que trabajan en las capas le agregan informacion al paquete, la cual sera leida por los protocolos de la misma capa del equipo que recibira el paquete que se esta enviando. A esta informacion se le llama "header" o "cabecera". Cada capa "encapsula" o "reempaqueta" la data que proviene de la capa de aplicacion dentro de otro paquete que contiene la cabecera del protocolo de la capa.

Por ejemplo, TCP, en la capa de transporte, utiliza el concepto de "numero de puerto" para diferenciar las aplicaciones de la capa superior, de esta forma es que podemos recibir informacion desde diferentes sitios de internet hacia diferentes aplicaciones en nuestros equipos, de esta forma TCP sabe a cual aplicacion enviar los datos que recibe desde la red, ya sea al browser de Internet, al cliente de email o a nuestro programa de Chat. Y como TCP necesita esta informacion (entre otras mas), agrega un "numero de puerto de origen", que es el puerto que le asigna a la aplicacion que solicita o transmite la informacion desde nuestra computadora, y un "numero de puerto de destino", que es el puerto de la aplicacion al que va dirigido el paquete en el equipo remoto. De esta forma de establece una especie de circuito entre los 2 puertos (origen y destino). Pero ademas de esto, TCP tambien numera los paquetes para establecer una secuencia y mantener control sobre la transmision, asi que tambien agrega dentro de la cabecera un "numero de secuencia". A continuacion un grafico que muestra la cabecera que agrega TCP al paquete original con todos sus campos.

 Como pueden ver, luego de todos los campos de la cabecera TCP se encuentra la Data del paquete. Luego que el paquete sale de la capa de transporte, se dirige a la capa de red, donde el protocolo IP se encarga tambien de agregar otra cabecera al paquete, pero esta vez con informacion concerniente a IP. Como mencionamos anteriormente una de las funciones de IP es direccionar los paquetes, por esto la informacion que agrega al paquete es informacion que se utilizara para hacer llegar el paquete hacia el equipo destino y tambien informara cual equipo envio el paquete, de modo que el equipo receptor pueda contestar o confirmar su recepcion. Parte de la informacion que se encuentra en la cabecera IP es, por ejemplo, la direccion IP del equipo al que va dirigido el paquete (IP Destino) y la direccion IP del equipo que emite el paquete (IP origen), entre otros. A continuacion la cabecera IP con todos sus campos:

Cuando el paquete sale de esta capa, pasa a la capa fisica. En esta capa tambien se agrega otra cabecera al paquete, pero esta vez lo hace el protocolo Ethernet (para el caso de las redes Ethernet, que son las mas comunes hoy dia). Entre la informacion que le agrega este protocolo al paquete se encuentra el MAC Address de origen y el MAC Address de destino. Como saben el MAC Address es la direccion fisica y unica de cada tarjeta de red. No abundaremos mucho en esta capa, ya que mayormente trabajaremos con IPTables con las capas de Tranporte (TCP y UDP) y la capa de Red (IP).

Ahora que ya sabemos como viajan los datos a traves de la red, podemos empezar a hablar sobre IPTables. IPTables es capaz de leer toda la informacion en la cabecera de los paquetes segun van entrando al equipo, incluso antes de que la misma pila TCP/IP pueda tener acceso a ellos. Entonces, al ser capaz de leer y analizar toda la informacion de cabecera del paquete, como IP de origen y destino, puerto de origen y destino, tipo de protocolo (TCP o UDP), y practicamente todos los otros campos de cabecera, pueden establecerse "reglas" o "filtros" en base a esa informacion. De esa forma, podemos hacer que IPTables bloquee o no permita el acceso de paquetes que en su cabecera TCP indiquen que  se dirigen hacia un "puerto 80" de algun equipo remoto, o que en la cabecera IP indique que se dirige a un IP destino en especifico.

Bueno, creo que por ahora esta bien como introduccion a IPTables, basicamente porque ya me esta ganando el sueño (son las 1 y tanto de la mañana) y porque se haria muy extenso este post.  En el proximo post hablaremos en mas detalle de que es IPTables, su funcionamiento y como configurarlo.

Un Poco de IPTables (Parte 2)