Iptables: Teoría y práctica para montar un firewall Linux
4.4 (132 ratings)
Course Ratings are calculated from individual students’ ratings and a variety of other signals, like age of rating and reliability, to ensure that they reflect course quality fairly and accurately.
636 students enrolled

Iptables: Teoría y práctica para montar un firewall Linux

Conceptos de firewalling en redes TCP/IP, teoría y práctica para montar un firewall iptables completo.
4.4 (132 ratings)
Course Ratings are calculated from individual students’ ratings and a variety of other signals, like age of rating and reliability, to ensure that they reflect course quality fairly and accurately.
636 students enrolled
Created by Diego Córdoba
Last updated 3/2020
Spanish
Spanish [Auto]
Current price: $69.99 Original price: $99.99 Discount: 30% off
5 hours left at this price!
30-Day Money-Back Guarantee
This course includes
  • 5.5 hours on-demand video
  • 5 articles
  • 45 downloadable resources
  • 2 Practice Tests
  • Full lifetime access
  • Access on mobile and TV
  • Certificate of Completion
Training 5 or more people?

Get your team access to 4,000+ top Udemy courses anytime, anywhere.

Try Udemy for Business
What you'll learn
  • Mejorar las habilidades técnicas en la gestión de filtrado y reenvío de tráfico de red en redes TCP/IP locales y de banda ancha.
  • Comprender el funcionamiento de los firewalls de red en general, y de iptables en particular.
  • Implementar un firewall completo y optimizado para la gestión de tráfico en redes locales.
  • Entender y configurar firewalls stateless/statefull basados en iptables.
Requirements
  • Conceptos de redes TCP/IP
  • Administración básica de sistemas GNU/Linux
  • Administración de la línea de comandos
  • Conocimientos de routing en redes TCP/IP
  • Conocimientos básicos de redes LAN
  • Conocimientos básicos de arquitectura de Internet
Description

¿Eres administrador de redes? ¿Tienes conocimientos de sistemas GNU/Linux?

Esta es tu oportunidad para poder adentrarte en el interesante mundo del filtrado de tráfico de red con Linux, utilizando una excelente herramienta ya incorporada en el núcleo: iptables.

En este curso aprenderás:

  • Las arquitecturas comunes de firewalling en redes.
  • El funcionamiento interno de iptables y la sintaxis de las herramientas afines.
  • La teoría y práctica necesaria para que puedas montar un firewall iptables profesional.

En fin, dispondrás de los conocimientos necesarios para desenvolverte cómodamente con firewalls Linux en cualquier red TCP/IP.

IPTables es el firewall, o cortafuegos, por defecto de todas las distribuciones Linux actuales. Viene a reemplazar, desde la versión 2.4 del núcleo Linux, a ipchains, agregando características novedosas que suelen facilitar la vida del administrador de red y seguridad, como es el caso de la gestión de estados en las conexiones de red.

Entre otros conceptos, aprenderás:

  • Las formas más comunes de implementación de un firewall con y sin DMZ.
  • La arquitectura interna de iptables, el firewall de Linux.
  • Los conceptos fundamentales de conexiones lógicas en redes TCP/IP, y la administración de los estados de estas conexiones.
  • La sintaxis del comando iptables, y sus modificadores más importantes.
  • Los módulos de extensión Match para poder adaptar tu firewall a prácticamente cualquier tráfico de red.
  • Los conceptos de NAT y cómo implementar los diferentes tipos mediante iptables.
  • Las formas prácticas de montar un script de firewall con iptables, y luego administrar sus reglas en caliente.

Con este curso podrás aprender desde cero hasta el nivel avanzado los conceptos de firewalling, y tendrás los conocimientos y habilidades prácticas para montar un firewall profesional sobre un sistema GNU/Linux que controle la red.

Además, mejorará tus habilidades profesionales en el campo, y completarás tus conocimientos sobre seguridad en redes y filtrado de tráfico.

Who this course is for:
  • Administradores de red que quieran optimizar sus redes y gestionar filtrado y NAT de tráfico.
  • Sysadmins Unix/Linux en general
  • Proveedores de servicios de Internet
  • Administradores de seguridad informática
  • Especialistas en seguridad en redes
Course content
Expand all 52 lectures 05:26:06
+ Introducción al curso - Material complementario
10 lectures 59:14
Bienvenid@!! Notas iniciales
01:27

Antes de adentrarnos en los temas puntuales del curso, vale una aclaración sobre lo que incluye y lo que no incluye este curso.

Esta nota viene a aclarar algunas dudas que un alumno me hizo sobre los temas de clase, y me parece provechoso que todos puedan entender desde la primer clase los esquemas simplificados, las abstracciones de redes, y cuales son los contenidos específicos que el curso incluye.

Preview 09:49
Documentación del curso y descargables
00:54

¿Qué riesgos corremos en Internet?

Internet es una red hostil, y como cualquier otra red hostil, simplemente por el hecho de conectarnos a la misma corremos algunos riesgos que pueden mitigarse filtrando algunos tipos de tráfico de red que sean innecesarios para nuestras actividades, o las actividades de la red corporativa que administremos.

Las redes actuales suelen alcanzar niveles de complejidad interesantes, por lo que suelen tenerse servidores internos, servidores en Internet, clientes locales en la LAN que necesitan acceder a dichos servidores, clientes en Internet que, por ejemplo, vía VPN, necesitan acceder a los servidores locales, y por supuesto, estas configuraciones implican riesgos grandes a la hora de asegurar los datos e infraestructura, tanto interna como externa, de nuestros servicios.

Un atacante podría aprovechar una brecha de seguridad de nuestro router, y vulnerar algún software o usuario cliente de nuestra red, y ya dentro de la misma, y con acceso local irrestricto, entrar a otros clientes y servidores locales, con las consecuencias que eso implica en la integridad y privacidad de la información que almacenemos y administremos.

Preview 06:09

¿Qué es un firewall?

Un firewall, o su traducción literal, “muro corta fuegos”, es un software o dispositivo de hardware diseñado para bloquear accesos no autorizados a un equipo o red de ordenadores.

En realidad, si bien esta es la funcionalidad principal de un firewall, no es la única, y comúnmente se suele utilizar también como traductor de direcciones de red y puertos de capa de transporte.

El filtrado de tráfico de red es su principal función, y le permite analizar el contenido de los paquetes de red entrantes y salientes, dejando pasar o no el tráfico según una serie de reglas especificadas por el administrador.

En otras palabras, un firewall permite controlar quién puede enviar y recibir tráfico en la red, con qué destino, y qué tipo de tráfico, teniendo en cuenta patrones de selección tales como direcciones IP, direcciones MAC, protocolos y puertos de capa de transporte, estado de conexiones, y una gran cantidad de parámetro habilitados adicionalmente mediante módulos de extensión.

¿Otras funcionalidades de un Firewall?

Otras de las funcionalidades que un firewall puede llevar a cabo son las de realizar traducción de direcciones de red, o NAT (Network Address Translation), es decir, cambiar direcciones ip de origen o destino en la cabecera IP para poder enmascarar tráfico, o redireccionarlo a servidores internos.

Por otro lado, también un firewall puede realizar traducción de dirección de puerto, o PAT (Port Address Translation), equivalente a reenviar tráfico de un puerto a otro.

Y además de todo, sirve también para administrar zonas desmilitarizadas, o Demilitarized Zones (DMZ por sus siglas en inglés), para poder aislar una región de red del resto, donde las vulnerabilidades que se encuentren no afecten al resto de la red en el caso de un ataque externo.

¿Qué es un firewall?
07:38

Supongamos que tenemos nuestro ordenador conectado a Internet, y con las configuraciones de iptables que vienen por defecto con el sistema operativo.

Supongamos que decidimos establecer políticas por defecto para denegar todo, de modo que el equipo no podrá realizar ningún tipo de conexión con el exterior (ni con el interior, puesto que los procesos que se comunican localmente mediante sockets unix o inet no podrán utilizarlos).

iptables -P INPUT DROP

iptables -P OUTPUT DROP

iptables -P FORWARD DROP

Para evitar tener problemas con el resto de las aplicaciones que utilizan sockets, vamos a habilitar el paso de datos desde y hacia la interfaz de loopback, o conexión local. Esta interfaz en Linux generalmente se denomina “lo”.

Para ello ejecutamos estas dos reglas:

iptables -A INPUT -i lo -j ACCEPT

iptables -A OUTPUT -o lo -j ACCEPT

En la primera aceptamos todo el tráfico entrante a la interfaz de loopback, mientras que en la segunda, todo el saliente desde la misma.

Ahora, supongamos que necesitamos navegar en Internet, enviar correos, y conectarnos a servicios ssh remotos.

Para ello, debemos habilitar el tráfico saliente a puertos http (tcp80), https (tcp443), smtp (tcp465), imap (tcp993) y ssh (tcp22).

Además, deberemos habilitar el tráfico DNS para que los nombres de dominio puedan resolverse a direcciones IP. Este servicio corre en el puerto udp53.

Procedamos a agregar las reglas para los paquetes salientes:

iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT

iptables -A INPUT -p tcp --sport 80 -j ACCEPT

iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT

iptables -A INPUT -p tcp --sport 443 -j ACCEPT

iptables -A OUTPUT -p tcp –dport 465 -j ACCEPT

iptables -A INPUT -p tcp --sport 465 -j ACCEPT

iptables -A OUTPUT -p tcp –dport 993 -j ACCEPT

iptables -A INPUT -p tcp --sport 993 -j ACCEPT

iptables -A OUTPUT -p tcp –dport 22 -j ACCEPT

iptables -A INPUT -p tcp --sport 22 -j ACCEPT

iptables -A OUTPUT -p udp –dport 53 -j ACCEPT

iptables -A INPUT -p udp --sport 53 -j ACCEPT

Como se puede apreciar, hemos dejado salir desde nuestro ordenador (mediante las cadenas OUTPUT de la tabla filter) el tráfico necesario para contactar a los protocolos mencionados, y por ende, hemos dejado entrar desde los servidores remotos, las respuestas de estos paquetes de establecimiento de conexión.

A esto se le denomina firewall state-less, es decir, un cortafuegos sin manejo de estados de las conexiones, ya que hemos aceptado el tráfico en ambos sentidos.

Como nota adicional, a estas reglas se les pueden agregar otros modificadores, que ahí hemos omitido. Por ejemplo, los modificadores -i y -o para indicar la interfaz de red de entrada y salida del tráfico respectivamente, o la dirección local de nuestra máquina, con -s y -d según sea tráfico saliente o entrante.

Además, si por ejemplo conociéramos la dirección IP del servidor remoto al que vamos a conectarnos, o si son pocos servidores, podríamos agregar un par de reglas con protocolo tcp y puerto 22 (destino en las salientes/OUTPUT, origen en las entrantes/INPUT), y especificar las direcciones IP (destino en las salientes/OUTPUT, origen en las entrantes/INPUT).

Ejemplo: Un cliente navegando en Internet
04:54

Tipos de Firewalls

Packet Filter

Este tipo de firewall trabaja en capa 3 del modelo TCP/IP (L3) y valida paquetes basándose en datos propios de las cabeceras de capa 3, tales como las direcciones IP de origen o destino de los paquetes, o el tipo de servicio (ToS).

En algunos casos, mediante módulos de extensión generalmente, también puede validar tráfico utilizando datos de capa 2, como las direcciones MAC de la trama, o de capa 4, como los puertos de identificación de aplicaciones, tanto en cliente como en servidor.

Este tipo de firewall no “ve” datos de aplicación, por lo que no puede filtrar contenido de tráfico tal como contenido html o de correo electrónico por ejemplo.

Por otro lado, un packet filter, al trabajar en capa 3, puede utilizarse prácticamente en cualquier dispositivo de la red, y permite filtrar paquetes individuales.

Proxy Firewalls

Este tipo de filtros de tráfico trabaja en capas superiores, generalmente en la capa de aplicación (capa 7, L7) del modelo TCP/IP, y son también conocidos como http proxy, o simplemente proxy a secas.

Aquí sí puede analizar contenido de los datos de aplicación, por lo que pueden filtrar según nombre de dominio, palabras en la URL, patrones de caracteres en la URL, tipos de archivos de descarga, etc.

Reverse Proxy

Es un tipo de firewall similar al anterior, también filtra tráfico en capa 7, pero está destinado a proteger a los servidores, no a los clientes.

Así, un proxy reverso permite o deniega accesos a servicios internos de los clientes externos, y usualmente también cuenta con capacidades de balanceo de carga, en el caso de que el acceso de clientes concurrentes así lo requiera.

Tipos de firewalls o cortafuegos
09:27

Arquitecturas comunes de Firewalls

Un firewall, al ser un dispositivo físico y/o software montado en nuestra red, su ubicación topológica debe ser la correcta para que cumpla su función.

Así, disponemos de diferentes arquitecturas topológicas de firewalling,

Veamos algunas de las más comunes.

Firewall en una red hogareña

Este tipo de firewalls aísla uno o unos pocos clientes, de una red hostil como Internet.

Así, tendremos el cliente que se conecta al firewall, y el firewall a su vez se conecta a la red de redes. Comúnmente el firewall aquí debería estar corriendo en el router que nos da acceso a Internet… de hecho, muchos routers disponen de capacidades de filtrado y control de acceso para los clientes de la LAN (Local Area Network).

Firewall en una red corporativa

Este tipo de firewalls representan una extensión del anterior. Aquí el dispositivo divide el ambiente de trabajo de los ordenadores locales, de los equipos que se encuentran en Internet. Así, por ejemplo, toda una red corporativa, compuesta por uno o mas segmentos de direccionamiento IP, podrían “salir” a Internet por medio de un firewall.

El firewall se encargará de controlar qué datos pueden salir desde la red corporativa a Internet, y qué datos pueden ingresar desde Internet a la red corporativa, en el caso de que tengamos en la misma algunos servidores que requieran acceso remoto.

Firewall simple con DMZ

Esta es otra arquitectura un poco más compleja, de firewall, y peferida por muchas empresas que poseen servidores que requieren acceso desde Internet.

Para ello primero debemos definir qué es una DMZ.

DMZ – Zona desmilitarizada

Una DMZ, o Zona Desmilitarizada (Demilitarized Zone por sus siglas en Inglés) representa un grupo de equipos informáticos reunidos en un segmento de red considerado inseguro, y que está ubicado por lo general entre la red interna, segura, e Internet.

El objetivo principal de esta región de la red, es que las conexiones desde la red interna y desde la DMZ hacia Internet estén permitidas, es decir, que todos los equipos de la red puedan acceder a Internet, mientras que desde Internet solo se tenga acceso a los equipos de la DMZ, siendo imposible la conexión desde la DMZ a la red interna.

Esta metodología de separación de segmentos de red surge de la necesidad de aislar servidores que requieren acceso público, de los equipos de la red LAN, y por supuesto, de otros servicios privados ubicados en la misma.

Sin DMZ, un atacante desde Internet podría vulnerar un servicio en la red, y desde él, acceder a otros servicios y datos de usuarios, mientras que haciendo uso de la DMZ, el atacante no podrá escalar privilegios y acceder a otros servicios de la red local.

La DMZ se usa habitualmente para ubicar servidores que es necesario que sean accedidos desde fuera, como servidores de correo electrónico, Web y DNS. Y es precisamente estos servicios alojados en estos servidores los únicos que pueden establecer tráfico de datos entre el DMZ y la red interna, por ejemplo, una conexión de datos entre el servidor web y una base de datos protegida situada en la red interna.

Las conexiones que se realizan desde la red externa hacia la DMZ se controlan generalmente utilizando port address translation (PAT).

Una DMZ se crea a menudo a través de las opciones de configuración del cortafuegos, donde cada red se conecta a un puerto distinto de éste. Esta configuración se llama cortafuegos en trípode (three-legged firewall).

Obsérvese que los enrutadores domésticos son llamados DMZ host, aunque no es una definición correcta de zona desmilitarizada.

Un firewall simple con DMZ es un firewall que divide a la red local, de una red de servicios públicos, o DMZ, y a su vez, los separa de una red hostil como Internet.

Aquí en este firewall deberemos configurar, por lo general, reglas que permitan a la comunicación desde la red local hacia la DMZ y a Internet, la comunicación desde la DMZ hacia Internet, y la comunicación desde clientes de Internet a los servicios de la DMZ, bloqueando además, los accesos desde la DMZ a la red local.

Firewall doble con DMZ

Podemos jugar mucho con la cantidad de servicios y las zonas de acceso de los mismos. Aquí, otro ejemplo de firewall con DMZ.

En esta oportunidad, podemos extender el modelo de firewall simple con DMZ, a un esquema más complejo y, si se quiere, paranoico.

En este esquema disponemos de un firewall que separa, como el anterior, a la red local de la zona desmilitarizada, pero a diferencia del ejemplo pasado, este firewall no da acceso directo a Internet, sino que todo el tráfico saliente lo envía a otro firewall.

Este segundo firewall separa la DMZ de Internet, pero no se comunica directamente con la red local.

Así, el primer firewall deberá permitir el acceso del tráfico desde la red local a los servicios de la DMZ, y el resto del tráfico permitido hacia Internet también, aunque este tráfico pase, mediante técnicas de enrutamiento, directamente al segundo firewall.

A su vez el primer firewall denegará todo tipo de acceso desde la DMZ (y por ende, desde Internet) que vaya dirigido a la red local.

Por su parte, el segundo firewall permitirá el acceso a servicios de Internet desde los hosts de la DMZ (y por ende, también desde la red local), y permitirá también el acceso desde los clientes en Internet a los servicios que se encuentren en la DMZ.

Por otro lado, este segundo firewall bloqueará el acceso de tráfico que vaya dirigido desde clientes en Internet con destino a los hosts de la red local.

Arquitecturas de montaje de firewalls
06:02

Tipos de tráfico de red

Otro concepto importante que tenemos que tener en cuenta es el de tipo de tráfico, o dirección del mismo, ya que un firewall tendrá una ubicación relativa a otros equipos de la red, a Internet, e incluso a otros firewalls.

El tipo de tráfico nos va a facilitar la escritura de las reglas para poder determinar si los paquetes de red van de un ordenador a otro que no es el firewall, si van al firewall directamente, o si, por el contrario, son generados en el propio firewall.

Podríamos identificar tres tipos de tráfico diferenciado:

  1. Entrante: todo aquel tráfico o paquetes de red cuya dirección destino en la cabecera IP se corresponda con la o alguna de las direcciones del ordenador en cuestión (el firewall por ejemplo). A este tráfico se lo conoce como INPUT.

  2. Saliente: todo aquel tráfico o paquetes de red cuya dirección origen en la cabecera IP se corresponda con la o alguna de las direcciones del ordenador en cuestión (el firewall por ejemplo). A este tráfico se lo conoce como OUTPUT.

  3. De paso: todo aquel tráfico o paquetes de red que no incluya en su cabecera IP, tanto como dirección origen o dirección destino, a ninguna de las direcciones IP que está utilizando el firewall. A este tráfico se lo conoce como FORWARD.

Cabe aclarar un punto importante: estas distinciones en el tráfico son relativas al ordenador o equipo de red que estemos analizando.

Así, por ejemplo, si nuestro ordenador está conectado a un router, y el router a su vez está conectado a Internet, una petición HTTPS de nuestro ordenador a un servidor en Internet será tráfico OUTPUT en nuestro ordenador (la dirección IP origen del paquete es la del ordenador), será INPUT en el servidor remoto (la dirección IP destino es la del servidor), y será FORWARD en el router (la dirección IP del router no se corresponde con ninguna de las IP’s especificadas en la cabecera de capa 3.

Por su parte, si, por ejemplo, desde la LAN accedemos a la interfaz web de administración del router/firewall, ese será tráfico INPUT en nuestro router (OUTPUT en nuestro ordenador), y las respuestas serán OUTPUT en el router (INPUT en el ordenador).

Tipos de tráfico identificables en un firewall
07:10

¿Qué hemos visto hasta ahora?

Hemos hablado de la definición del firewall, un dispositivo o software que se encarga de interceptar, modificar, filtrar, denegar o aceptar tráfico de red a nivel de capa 3 en general.

Hemos hablado de las diferentes arquitecturas en las cuales podemos nosotros montar un firewall, desde la mas simple, cuando nosotros tenemos un cliente conectado directamente a Internet, el firewall estaría montado en ese propio cliente por ejemplo, o podemos tener arquitecturas un poco más complejas, como un cliente o una red LAN conectada a un firewall, y ese firewall a su vez conectado a Internet... en ese caso el firewall estaría interceptando todo el tráfico de la LAN hacia Internet, y desde Internet hacia la LAN, propiamente hablando.

También podemos montar un firewall con tres interfaces de red, y una zona desmilitarizada. En este caso tendríamos un firewall conectando a una red LAN, conectando a una DMZ, y conectando a Internet... de esta forma: ¿qué podríamos lograr?

Podríamos lograr proteger a la zona LAN local de los accesos indebidos desde Internet... podríamos montar una serie de servidores en la zona desmilitarizada, y de esa zona desmilitarizada nosotros podríamos acceder a esos servicios desde la red LAN o desde Internet, y por supuesto podríamos evitar que el acceso desde Internet vaya directamente a la red LAN donde podríamos tener, además de los equipos de trabajo, otros servicios con información sensible, con información privada.

De la misma forma, a nivel de arquitectura podríamos decir que podríamos montar un firewall doble, en el cual tenemos una red LAN por ejemplo, conectada a un firewall, el firewall conectado a una DMZ, y esa DMZ conectada a otro firewall que le da acceso a Internet. De esta forma, para acceder de la red lan a la DMZ, a los servicios de la dmz, deberiamos pasar el primer firewall, deberíamos configurar ese primer firewall, y lo mismo ocurre para acceder desde Internet a los servicios de la DMZ, deberíamos acceder por el segundo firewall.

De esta forma, si un atacante logra romper uno de los firewall, supongamos el firewall mas exterior que tenemos, que está hacia Internet, el atacante podría pasar por ese  firewall y entrar a la DMZ, y de esa DMZ, para poder acceder a los servicios privados, e información sensible que tenemos en la LAN, debería a su vez saltar un segundo firewall... sería una arquitectura un poco mas paranoica.

Y además hablamos también de los componentes de iptables, hablamos de las tablas que tiene, filter, nat mangle, security, etc, y hablamos de las cadenas que nos indican un poco también el sentido del tráfico, o quién es el originante, a quién va destinado el tráfico, y demás. Por ejemplo input, output, forward, para el caso de filter, prerouting y postrouting para el caso de NAT.

Hablamos también de las reglas. Las reglas son ejecuciones de comandos que nosotros vamos introduciendo en nuestro firewall, y esas ejecuciones de comandos van a ir agregando reglas con patrones específicos de selección de tráfico para una cadena específica de una tabla en particular. Así podríamos tener reglas que permitan la coincidencia de tráfico de input de la tabla filter, de output de la tabla filter, de prerouting de la tabla nat, etc.

Y hablamos también de un tema muy importante, extremadamente importante a la hora de montar un firewall iptables, que es el flujo de funcionamiento interno de iptables. Hablamos sobre cómo ingresa un paquete al firewall, qué pasos se llevan a cabo hasta que el paquete egresa, si es que egresa, desde el firewall. Decíamos por ejemplo que el paquete ingresa al firewall por la parte inferior, considerando al firewall una capa 3 del modelo TCP/IP o el modelo OSI/ISO, ingresa al firewall, analiza reglas de prerouting de la tabla nat, toma una decisión de ruteo para determinar si es un paquete entrante o un paquete que pasa a otro equipo de la red. Una vez que se tomó esa decisión de ruteo se sabe cual de estas dos opciones llevar a cabo: si el paquete va destinado al firewall, si la dirección IP del paquete es la dirección IP del firewall, automáticamente el paquete pasa a evaluar las reglas de input de la tabla filter, para dejarlo pasar o no hacia capas superiores. En el caso de que el paquete vaya destinado a otro equipo de la red, a otro equipo de la LAN, o a un equipo en internet por ejemplo, el paquete va a pasar a evaluar las políticas de forward de la tabla filter, y dejará pasar o no el paquete dependiendo de cual es la acción que se lleve a cabo. Si pasa el paquete automáticamente se toma otra decisión de ruteo para saber a qué nodo de la red va destinado el paquete, y cómo conformar la cabecera IP destinataria, y por último se envía el paquete a internet previo haberle modificado datos con el postrouting de la tabla nat.

Por su parte cuando nosotros generamos paquetes locales en el firewall, una conexión local hacia un servicio remoto, por ejemplo, ese paquete primero evalúa el nat y el filter de output, de la cadena de salida del paquete hacia Internet, y luego lleva a cabo la decisión de ruteo y el postrouting exactamente igual que si se tratara de un paquete que viene desde otro equipo hacia otro equipo mas en la red.

Eso sería entonces un poco los conceptos globales que hemos tratado hasta este punto del curso.

Resumen: recapitulemos sobre los temas
05:44
+ Firewall Basics y ejemplos sencillos
11 lectures 01:12:08

Tablas, cadenas y reglas

Hay varios conceptos que debemos tener claros para poder trabajar con iptables… entre ellos, los de tablas, cadenas y reglas.

Iptables maneja varias tablas que agrupan tipos particulares de reglas, y a su vez, éstas están clasificadas según diversas cadenas propias de cada tabla.

Las tablas permiten configurar el tipo de regla que estamos seteando. Así, por ejemplo, tenemos las tablas filter, nat y mangle.

La tabla filter permite filtrar, como su nombre lo indica, ciertos y determinados paquetes que cumplan con un patrón de selección específico.

La tabla nat, por su parte, permite la modificación de paquetes, específicamente en la cabecera IP, cambiando las direcciones IP de origen o destino según correspondan, y también permite cambiar los números de puertos en la cabecera de transporte, ya sea tcp o udp.

Cuándo se llevan a cabo estas modificaciones? Al momento de ingresar o salir tráfico del procesamiento del firewall. Esto vamos a aprenderlo en seguida, cuando hablemos sobre el flujo de trabajo y procesamiento de datos dentro de iptables.

Mangle, a su vez, permite manipular los paquetes y modificar otros campos de la cabecera IP, y también marcar paquetes mediante tags internos del firewall para aplicarles algún tratamiento particular, como puede ser QoS mediante tc u otras herramientas de iproute2.

En este curso, como hemos comentado, hablaremos sobre las tablas NAT y FILTER específicamente, que van a permitirnos montar un firewall completo para redireccionamiento y filtrado de tráfico en un nodo de la red LAN.

Tabla filter

La tabla filter, como bien comentamos antes, permite bloquear o dejar pasar tráfico de red que cumpla con algún patrón característico.

Esta tabla consta de tres cadenas, o chains, a saber:

  • INPUT: identifica todo el tráfico destinado al firewall, aquel que tiene en la cabecera de capa 3 (generalmente IP) como dirección destino (destination address) a la dirección del firewall (o alguna de las direcciones IP del mismo).

  • OUTPUT: identifica todo el tráfico generado en el firewall, aquel que tiene en la cabecera de capa 3 (generalmente IP) como dirección origen (source address) a la dirección del firewall (o alguna de las direcciones IP del mismo).

  • FORWARD: es todo el tráfico de red que pasa por el firewall por una cuestión topológica, pero que no posee, en capa 3, ninguna de las direcciones IP del firewall, ya sea como dirección de origen o de destino.

Tabla nat

La tabla nat dijimos que sirve para modificar campos en las cabeceras de los paquetes… particularmente en la cabecera IP y de transporte TCP/UDP, tales como las direcciones IP de origen y destino, o los puertos de origen y destino en capa 4.

Las cadenas disponibles en esta tabla son las siguientes:

  • PREROUTING: Permite alterar la información de los paquetes antes de tomar la primer decisión de enrutamiento, ni bien llegan al firewall.

  • POSTROUTING: Permite alterar la información de los paquetes después de tomar la segunda y última decisión de enrutamiento, antes de salir del firewall y encaminarse al destinatario.

  • OUTPUT: Permiten alterar la información de los paquetes generados por el mismo firewall, y antes de tomar la segunda y última decisión de enrutamiento.

Iptables: tablas, cadenas y reglas
10:57

Iptables y el flujo de funcionamiento

Vamos a ver ahora uno de los puntos más importantes a tener en cuenta para poder configurar correctamente un firewall iptables: el funcionamiento interno del mismo.

Montar un firewall iptables regla por regla es complejo en el sentido de que las reglas deben escribirse en determinado orden para que tengan efecto.

Ahora bien, ¿cómo saber qué orden darle al escribirlas? ¿Qué dirección IP utilizar como patrón de búsqueda en un paquete? ¿La que trae originalmente desde la red? ¿O la que resultó de editarla con una regla de la tabla NAT?

Para saber ésto y prácticamente todo acerca del núcleo de trabajo de iptables, analicemos la siguiente figura.

Imaginemos que se trata de una capa 3, la capa de red, o IP, en la que realmente está trabajando el firewall iptables.

Imaginemos que en la parte superior se encuentra la capa 4 (transporte) del ordenador que orquesta el firewall, y debajo, la capa 2 (enlace).

Así, cuando el ordenador que hace las veces de firewall recibe un paquete de red, entrará desde la capa inferior, y pasará a capas superiores si el paquete está destinado a él, o saldrá nuevamente por la capa inferior a otro equipo en la red, si es que el paquete estaba destinado a otro nodo.

Ni bien el paquete entra a nuestro firewall, en la imágen, desde la esquina inferior izquierda, procesará las reglas de la tabla NAT cuya cadena sea la de PREROUTING.

Estas reglas permitirán cambiar, por ejemplo, la dirección de destino de los paquetes IP para reenviarlos a un nodo con direccionamiento privado dentro de nuestra LAN o DMZ.

Una vez procesadas estas reglas (si es que existen estas reglas), el paquete pasará a la primer toma de decisión de enrutameinto.

Aquí el firewall actuará como router, y determinará si el paquete está destinado realmente al firewall, o el destinatario es otro nodo de la red.

Si el paquete tiene como dirección ip destino a una de las direcciones IP del firewall, entonces se procederá a pasar a capas superiores, previo haber evaluado las reglas de la tabla filter, cuya cadena es INPUT.

Si el paquete es aceptado por una regla de filter-INPUT, o, en el caso de que no existan reglas que lo validen, si las políticas por defecto lo habilitan, el paquete pasará a capas superiores, donde se evaluará y, eventualmente, se responderá.

En el caso de que así sea, que el paquete pase a capas superiores, y se genere una respuesta, o en el caso de que sea el firewall el que genere un paquete nuevo para establecer una conexión con un nodo del exterior, el dato de aplicación se encapsulará en transporte, y éste a su vez en IP, formando el paquete que el firewall va a pasar a evaluar.

En este caso, el paquete vendrá desde las capas superiores, y entrará al firewall desde la esquina superior derecha, y pasarán a evaluarse las reglas de la tabla nat cuya cadena sea OUTPUT, para modificarle datos a la cabecera IP o TCP/UDP.

Luego se evaluarán las reglas de la tabla filter para la cadena OUTPUT también, de modo que se dejará pasar, o se descartará, el paquete en cuestión.

Si el paquete pasa el filtro de OUTPUT, se tomará una segunda y última decisión de enrutamiento, para determinar a qué host en la red está destinado el paquete, o si es el mismo firewall el destinatario, y así armar la cabecera IP saliente.

Luego de la decisión de enrutamiento, se evaluarán, si existen, las reglas de la tabla nat para la cadena POSTROUTING, donde se podrá, por ejemplo, modificar la dirección ip origen de los paquetes salientes para enmascarar la salida y cambiar direccionamiento privado por direccionamiento púlbico.

En el caso particular de que el paquete que entra al firewall vaya destinado a otro nodo en la red, al igual que un paquete INPUT, primero se evaluarán las reglas de PREROUTING de la tabla nat, y luego de la decisión de enrutamiento, en vez de enviarlo a capas superiores como en el caso anterior, el paquete pasará a evaluar las reglas de FORWARD de la tabla filter.

Si el paquete es aceptado en esta instancia, seguirá su camino y se tomará la segunda decisión de enrutamiento, al igual que un paquete saliente generado en el firewall.

Luego de esta segunda y última decisión de enrutamiento, se evaluarán, si las tuviere, las reglas de POSTROUTING de la tabla nat, y se enviará al medio.

Flujo de trabajo: ¿qué pasa con cada paquete dentro de iptables?
10:57

Flujo de trabajo: otra apreciación

Veamos ahora otro diagrama que puede aclararnos este funcionamiento del firewall.

Aquí, consideremos que el tráfico entra por la esquina superior izquierda.

Primeramente se evaluarán las reglas de PREROUTING de la tabla nat, y luego se tomará la decisión de enrutamiento.

Si el paquete está destinado al firewall, entonces se procederá a evaluar las reglas de INPUT de la tabla filter, y, al igual que en el caso anterior, si el paquete es aceptado, pasa a capas superiores.

En capas superiores se lleva a cabo el procesamiento del mismo, y se genera una respuesta (o un paquete nuevo hacia otro destino).

Esta respuesta evaluará el destinatario, para poder armar la cabecera saliente de IP, y se procederá a evaluar la tabla nat, particularmente la cadena de OUTPUT, modificando, si existen reglas, algunos parámetros de la cabecera IP.

Acto seguido, se evaluarán, si existen, las reglas de OUTPUT para la tabla filter, bloqueando el paso, o aceptando el paquete.

Si el paquete es aceptado, se procederá a evaluar la serie de reglas de POSTROUTING de la tabla nat, al igual que en el caso anterior, para enviar finalmente el paquete al destinatario.

Flujo de trabajo: otra forma de interpretarlo y aprenderlo
04:45

Vamos a ver en esta oportunidad vamos a aprender qué es el NAT, o Network Address Translation... en español, traducción de direcciones de red.

Vamos a ver cómo es posible que un equipo en una red LAN, con direccionamiento privado (por ejemplo, una IP de la red 192.168.0.0/24 en IPv4) puede enviar tráfico a Internet, donde dicho direccionamiento no es "routeable" o enrutable en la red de redes.

Aprenderemos qué es lo que permite a un servidor remoto responder un paquete de consulta en Internet, y que esta respuesta pueda llegar a un host cliente en una LAN cuya dirección IP pertenece a un rango privado.

NAT - Network Address Translation
11:09

Ahora veamos otro ejemplo de firewall Linux, quizás más común en organizaciones: un cortafuegos que separa una red LAN corporativa, o un cliente, de Internet, o cualquier otra red considerada hostil.

En este caso supongamos que tenemos una serie de clientes en una red LAN, y ésta se conecta a un firewall Linux que le da salida a Internet.

Supongamos también que la red LAN necesita unicamente navegar en el puerto tcp80 (http) y resolver nombres utilizando dns (udp53).

Aquí, a diferencia del caso anterior, todo el tráfico es FORWARD, ya que los paquetes desde la LAN hacia Internet tendrán como IP destino servicios en Internet, y las respuestas tendrán como IP destino los equipos de la LAN que iniciaron las conexiones. Al no tener ningún paquete en el campo de IP destino de la cabecera IP la dirección del firewall (o una de ellas), no es tráfico INPUT, sino FORWARD.

Vamos a montar un firewall que deniegue todo el tráfico, igual que en el ejemplo anterior:

iptables -P INPUT DROP

iptables -P OUTPUT DROP

iptables -P FORWARD DROP

Y ahora vamos a permitir el paso de los paquetes http y dns desde la LAN hacia el exterior, y por supuesto, las respuestas de los servidores en la nube:

iptables -A FORWARD -s ip_lan -p tcp --dport 80 -j ACCEPT

iptables -A FORWARD -d ip_lan -p tcp --sport 80 -j ACCEPT

iptables -A FORWARD -s ip_lan -p udp --dport 53 -j ACCEPT

iptables -A FORWARD -d ip_lan -p udp --sport 53 -j ACCEPT

A estas reglas también le podríamos agregar otros parámetros, como la interfaz de red por la que entra o sale el tráfico.

Ejemplo: Un firewall separando una red LAN de Internet
04:38

Un firewall intermedio con DMZ

Configuremos ahora nuestro primer firewall con DMZ.

Como explicamos en la parte teórica, una DMZ, o zona desmilitarizada (demilitarized zone) es un segmento de red IP que generalmente contiene servidores que están expuestos al acceso desde Internet.

Esta zona nos permite aislar a la red interna de los servicios expuestos, de modo que si éstos son comprometidos, le resulte más difícil al atacante acceder a la red interna, y a los servicios confidenciales que tengamos dentro.

Volvamos a plantear el ejemplo del firewall stateless, pero en este caso, agregándole una DMZ con dos servicios, uno web, y uno de correo electrónico (smtp).

La red LAN contiene clientes que requerirán acceso a Internet y a los recursos de la DMZ, mientras que los clientes desde Internet solamente podrán tener acceso a los servicios de la DMZ.

El firewall cuenta con tres interfaces de red, a saber:

  • eth0: interfaz que conecta al firewall con la red LAN.

  • eth1: interfaz que conecta al firewall con la DMZ.

  • eth2: interfaz que conecta al firewall con Internet.

Aquí los requisitos planteado para el ejemplo son los siguientes:

  • Firewall en modo denegar todo.

  • Acceso desde la LAN a Internet (tcp80 y udp53)

  • Acceso desde la LAN al servidor web (tcp443)

  • Acceso desde la LAN al servidor SMTP (tcp25)

  • Acceso desde Internet al servidor web (tcp443)

  • Acceso SSH al firewall (tcp22)

Como se puede apreciar, requerimos principalmente de reglas de FORWARD para todo el tráfico que pasa por el firewall, dirigido desde la LAN a la DMZ o a Internet, o desde Internet a la DMZ.

Además, también serán necesarias reglas INPUT/OUTPUT para permitir el tráfico de SSH destinado a administrar el firewall.

Igual que antes, primero definimos un firewall en modo denegar todo:

iptables -P INPUT DROP

iptables -P OUTPUT DROP

iptables -P FORWARD DROP

Y luego habilitamos las reglas.

Vamos por parte, según los requerimientos expuestos:

  • Acceso desde la LAN a Internet (tcp80 y udp53)

Aquí necesitamos reglas que permitan el paso de paquetes desde la LAN hacia los puertos tcp80 y udp53 de Internet, y sus respectivas respuestas.

iptables -A FORWARD -s ip_lan -p tcp --dport 80 -j ACCEPT

iptables -A FORWARD -d ip_lan -p tcp --sport 80 -j ACCEPT

iptables -A FORWARD -s ip_lan -p udp --dport 53 -j ACCEPT

iptables -A FORWARD -d ip_lan -p udp --sport 53 -j ACCEPT

  • Acceso desde la LAN al servidor web (tcp443)

Aquí, similar al anterior, necesitamos abrir el puerto tcp443 desde la LAN hacia Internet.

iptables -A FORWARD -s ip_lan -d ip_web -p tcp --dport 443 -j ACCEPT

iptables -A FORWARD -d ip_lan -s ip_web -p tcp --sport 443 -j ACCEPT

  • Acceso desde la LAN al servidor SMTP (tcp25)

Ahora abrimos el puerto tcp25 de smtp desde la LAN hacia el servidor smtp que tenemos en la zona desmilitarizada, y cuya ip vamos a suponer que es ip_smtp.

iptables -A FORWARD -s ip_lan -d ip_smtp -p tcp --dport 25 -j ACCEPT

iptables -A FORWARD -d ip_lan -s ip_smtp -p tcp --sport 25 -j ACCEPT

  • Acceso desde Internet al servidor web (tcp443)

Idem al anterior, pero para permitir el acceso de la LAN hacia el servidor https de la DMZ. La ip del servidor vamos a suponer que es ip_web.

iptables -A FORWARD -i eth2 -d ip_web -p tcp --dport 443 -j ACCEPT

iptables -A FORWARD -o eth2 -s ip_web -p tcp --sport 443 -j ACCEPT

  • Acceso SSH al firewall (tcp22)

Por último, permitimos el acceso desde cualquier origen a nuestro firewall mediante el servicio de SSH, puerto tcp22 por defecto, con tráfico entrante y saliente (respuestas).

iptables -A INPUT -s ip_lan -d ip_fw -p tcp --dport 22 -j ACCEPT

iptables -A OUTPUT -d ip_lan -s ip_fw -p tcp --sport 22 -j ACCEPT

Ejemplo: Agregando una DMZ a nuestro firewall
10:18

Aplicando NAT al firewall del ejemplo

Recordemos, en el ejemplo 2 teníamos un firewall que separaba una red LAN de Internet, y sin DMZ. Un ejemplo sencillo, que ahora vamos a completar.

Ya habíamos escrito las reglas de filter para permitir el paso de paquetes en ambas direcciones, ahora, para lograr que las direcciones IP origen de los paquetes salientes cambien, debemos agregar al menos una regla de NAT.

Si tenemos ip pública en el firewall, bien podríamos utilizar MASQUERADE como se vió recién:

iptables -t nat -A POSTROUTING -s ip_lan -j MASQUERADE

O, en el caso de conocer la ip pública, por una razón de mejora de rendimiento, podemos “hardcodear” la ip pública en una regla SNAT de esta forma:

iptables -t nat -A POSTROUTING -s ip_lan -j SNAT --to-source ip_pub_fw

donde ip_pub_fw es la ip pública del firewall de cara a Internet.

Ejemplo: Reglas NAT en nuestro firewall de LAN
04:50

Escribiendo un script completo

Como hemos visto, un firewall iptables se configura cargando reglas, una detrás de otra, mediante la ejecución de comandos iptables por línea de órdenes.

Es por esto que una de las principales formas que suelo utilizar para configurarlo es mediante scripts de shell.

Además, resulta sumamente útil para configurar políticas por defecto, y luego agregar reglas según las necesidades, y ordenarlas como mejor nos convenga.

Escribir un script también soluciona una parte importante de las configuraciones de firewalling: editar reglas.

Al ejecutarse en orden las reglas de iptables, deben cargarse en orden también, agregándose al final, o insertándose al principio, según sean generales o específicas respectivamente. Con el script, simplemente agregamos reglas al final en el orden que necesitemos, y movemos hacia arriba y abajo las reglas según sea nuestro menester.

Aquí, un punto importante es, al iniciar la configuración del firewall en el script, limpiar todas las reglas de iptables antes de cargarlas, de modo que podamos modificar el script, y las reglas se carguen desde cero en el orden correcto, no interfiriendo con las reglas cargadas en la corrida anterior del mismo.

En este apartado aprenderemos a crear nuestro shell script completo para montar nuestro firewall desde cero.

Finalmente, y antes de pasar a las configuraciones, debemos plantearnos dos maneras de montar un firewall.

Por un lado, podemos establecer políticas por defecto a aceptar todo, y luego ir denegando el tráfico que no deseemos que pase. Por otro, las políticas por defecto serían las de denegar todo, y luego ir aceptando el tráfico que necesitemos.

Para la primera opción, la configuración resulta relativamente sencilla, no requiere mayores conocimientos, y suele funcionar en la mayor parte de los casos. Esta opción puede considerarse, a simple vista, más insegura que la de denegar todo, puesto que si olvidamos bloquear algún tipo de tráfico no deseado, por defecto será aceptado.

La otra opción, la de denegar todo, por su parte, bloquea por defecto todos los accesos en el firewall, y somos nosotros como administradores quienes debemos habilitar los protocolos que sean necesarios.

Esta segunda opción es un tanto más complicada de configurar que la primera, y requiere algunos conocimientos adicionales respecto de paquetes de red y protocolos del stack TCP/IP.

En un firewall denegar todo, por defecto todo el tráfico estará bloqueado, y deberemos habilitar el que sea necesario, por lo que si olvidamos activar algún tipo de filtro particular, el tráfico será descartado.

Políticas: Aceptar todo

Lo primero que tenemos que configurar en nuestro script son las reglas de limpieza del firewall, vaciado de los buffers, y de configuración de las políticas por defecto.

Esto podemos hacerlo de la siguiente manera:

#!/bin/bash

# Inicializamos el firewall limpiando las reglas

iptables -F

iptables -Z

iptables -t nat -F

# Cargamos las politicas por defecto

iptables -P INPUT -j ACCEPT

iptables -P OUTPUT -j ACCEPT

iptables -P FORWARD -j ACCEPT

Y luego deberemos empezar a colocar las reglas que vayan a denegar el tráfico que no creamos conveniente. Estas reglas serán de la tabla filter, corresponderán con cualquiera de las cadenas activas (INPUT, OUTPUT o FORWARD), y corresponderán con acciones como DROP o REJECT.

# Cargamos las reglas de denegación

iptables -A FORWARD … -j DROP

iptables -A INPUT … -j DROP

....

En cualquier ubicación de este script pueden colocarse las reglas de NAT necesarias para enmascarar el tráfico, o para permitir el acceso desde Internet a servicios internos (lo veremos más adelante).

Generalmente suelo colocar estas reglas luego de cargar las políticas por defecto, y de configurar, en caso de que así lo hagamos, el manejo de estados de las conexiones, tópico que analizaremos más adelante en el curso.

Montando un firewall en un script Bash - Opción "Aceptar todo"
01:56

En el ejemplo 3 disponíamos de un firewall que conectaba a la LAN a Internet, y además tenía una “pata” en una DMZ con servicios expuestos.

Recordemos además que el firewall tenía una interfaz llamada eth0 que conectaba a la LAN, eth1 que daba con la DMZ, y eth2 conectada a Internet.

En este ejemplo, para “enmascarar” el tráfico que sale de la LAN a Internet podríamos escribir la siguiente regla:

iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE

O, mediante SNAT, de esta forma:

iptables -t nat -A POSTROUTING -o eth2 -j SNAT --to-source ip_pub_fw

Aquí, todo el tráfico que salga a Internet será enmascarado con la IP pública del firewall.

Debemos hacer una importante aclaración en este caso. Particularmente, esto funcionaría correctamente si tanto la red LAN como la DMZ tienen direccionamiento privado.

En algunos casos, los servicios expuestos en la DMZ tienen direccionamiento público, por lo que no será necesario enmascararlos con NAT.

Una opción interesante en este caso, sería agregar otro modificador a nuestra regla de NAT que permita enmascarar el tráfico proveniente de la red LAN, pero excluya el de la DMZ.

¿Qué parámetro utilizar? ¿qué diferencias tienen los dos segmentos de red? Básicamente, la dirección IP.

Suponiendo, por ejemplo, que la red LAN tiene un direccionamiento 192.168.10.0/24, podríamos reescribir las anteriores reglas como sigue:

iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o eth2 -j MASQUERADE

O, mediante SNAT, de esta forma:

iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o eth2 -j SNAT --to-source ip_pub_fw

Con lo que estaríamos solamente enmascarando el tráfico saliente por la interfaz eth2 (conectada a Internet) y proveniente desde la red LAN.

Ejemplo: Reglas NAT en la DMZ
04:26

Políticas: Denegar todo

Veamos ahora los pasos necesarios para montar nuestro firewall denegando todo el tráfico por defecto.

Lo primero será exactamente igual, limpiar el firewall, y al cargar las políticas, utilizaremos DROP en vez de ACCEPT, de una manera similar a esta:

#!/bin/bash

# Inicializamos el firewall limpiando las reglas

iptables -F

iptables -Z

iptables -t nat -F

# Cargamos las politicas por defecto

iptables -P INPUT -j DROP

iptables -P OUTPUT -j DROP

iptables -P FORWARD -j DROP

Ahora bien, dado que estamos denegando todo tipo de tráfico, esto incluye al tráfico local que utilicen los procesos de nuestra computadora.

En GNU/Linux muchos procesos se comunican entre si utilizando sockets, tanto de tipo UNIX como de tipo INET. Estos últimos hacen uso del stack TCP/IP exactamente igual que los procesos que se comunican en una red de computadoras, con la diferencia de que, en vez de utilizar las interfaces de red físicas, hacen uso de la interfaz de red lógica de loopback, comúnmente llamada “lo” en la mayoría de los sistemas Linux.

Es por esto que, si montamos un firewall que deniegue todo tipo de contenidos de red, será menester habilitar el tráfico saliente y entrante desde y hacia la interfaz de loopback para que los procesos locales puedan trabajar sin inconvenientes.

# Habilitamos el tráfico local

iptables -A OUTPUT -o lo -j ACCEPT

iptables -A INPUT -i lo -j ACCEPT

Una vez hecho esto, ya podremos comenzar a cargar las reglas de filter que acepten el contenido en la dirección que creamos conveniente.

Y por supuesto, podremos cargar las reglas de NAT adicionalmente para realizar los enmascaramientos y traducciones de direcciones de destino.

Montando un firewall en un script Bash - Opción "Denegar todo"
03:40

Hemos analizado los diferentes tipos de tráfico desde el punto de vista de nuestro firewall, tráfico que pasa por el firewall en modo forward, tráfico que se genera en el firewall y sale hacia otra red, a otro destino, en modo output, o tráfico que se genera en otro destino y viene hacia nuestro firewall en modo input.

En este punto cabe recalcar el hecho de que los tipos de tráfico son relativos al equipo que estamos analizando, por ejemplo, en este caso en nuestro firewall, como hemos acabado de ver en la presentación anterior, si el cliente envía un paquete a Internet, hacia un servidor cualquiera en Internet, en el firewall ese tráfico será de tipo forward, pasará por el firewall hacia un cliente en Internet, desde el cliente hacia, por ejemplo, un servicio en Internet, pero si lo analizamos desde el punto de vista del cliente, el tráfico será output en el cliente... el mismo que en el firewall es forward, en el cliente es de tipo output.


Así, el tráfico de respuesta será de tipo forward en el firewall, pero a su vez ese tráfico va a llegar destinado a la ip propia del cliente, por lo tanto va a ser tráfico input en ese cliente.

Como conclusión de esta primera parte podríamos decir que el sentido del tráfico, si es input, output o forward, se analiza de forma relativa al equipo que estamos viendo, si el paquete se genera en mi equipo, y la ip de origen de ese paquete es la ip que tiene mi equipo, será un tráfico de tipo output desde ese equipo hacia otro equipo en la red, mientras que, por ejemple, el paquete generado en otro nodo de la red y destinado a mi equipo, con la dirección ip destino en la cabecera ip coincidente con la dirección ip de mi equipo, será tráfico input a mi equipo, a mi cliente por ejemplo, o a mi firewall.

Por otro lado, el tráfico que sea generado en un nodo de la red y pase por mi equipo hacia otro nodo de la red, es decir, el tráfico generado desde una IP determinada, y con destino a otra ip específica de la red, y que no sean estas ip's ninguna de las de mi firewall, va a ser tráfico forward en el mismo.

Por lo tanto un cliente genera un paquete, sale de ese cliente (es tráfico output para ese cliente), pasa por el firewall (tráfico forward en el firewall), y entra a un servidor remoto (tráfico input en el servidor remoto). El tráfico de respuesta del servidor será output en el servidor, pues es generado en el servidor, con su ip de origen, pasa por el firewall (forward en el firewall) y entra al cliente que lo llamó (tráfico input en el cliente). 

Por lo tanto siempre tenemos que tener en cuenta la ubicación relativa en la cual estamos analizando el sentido de tráfico de nuestro firewall.

Como conclusión, debemos recordar entonces, y un poco para cerrar esta sección del curso, el tipo de tráfico depende del equipo en el que estamos analizandolo. En la generalidad de los casos, y particularmente en el caso de este curso, salvo que se indique lo contrario, todo el tráfico input, output y forward hará referencia al firewall de la red, o a alguno de dichos firewalls.

Este es un concepto muy importante por el hecho de que las reglas de firewalling de iptables que carguemos tendrán el efecto deseado si sabemos interpretar correctamente el sentido en el que viajan los paquetes de la red, y dónde estamos cargando estas reglas... y por supuesto, el tipo de tráfico que representa para nuestro firewall y no para un cliente cualquiera.

¿Qué significa esto?

Que si yo estoy cargando una regla de tipo output por ejemplo, en mi firewall para filtrar tráfico que venga desde un cliente hacia un servicio remoto en Internet, no va a funcionar, simplemente porque esa regla está filtrando tráfico generado en el firewall con cualquier otro destino... si bien el paquete sale del firewall, es paquete que pasa por el firewall desde un cliente cualquiera, y no es paquete generado en el firewall.

Es importante entonces que recordemos la posición relativa del tráfico respecto de la ubicación de nuestro firewall para poder configurarlo correctamente.

Tipos de tráfico - un resumen puntual.
04:32

Mini-examen / quiz para que puedas saber si has entendido bien los conceptos vistos hasta ahora. Exitos!

Autoevaluación - Sección 1
4 questions
+ Iptables: el firewall de los sistemas GNU/Linux
3 lectures 31:15

Iptables: el comando

Iptables es un firewall completo, y sus reglas, tablas y cadenas se configuran mediante un comando homónimo.

Veremos ahora la sintaxis de este comando, y cómo podemos utilizarlo para ingresar las reglas a nuestro firewall.

Antes que nada, es importante notar que el ingreso de las reglas es secuencial, una por una, y en el orden en el que fueron ingresadas, serán luego evaluadas.

Es decir, si en el firewall tenemos configuradas 10 reglas, con cada paquete que pase por el mismo se irán evaluando una a una, hasta que alguna de ellas calce, mediante su patrón de selección, con el paquete en cuestión.

Si la regla coincide, entonces se ejecutará la acción correspondiente, y se saldrá de la ejecución del firewall para ese paquete, así sea aceptarla o denegarla (caso de la tabla filter).

Por lo que, si por ejemplo tenemos una regla que descarta un paquete, porque coincide con una dirección ip de origen o destino, y debajo una que lo acepta, más específica, que a la dirección le agrega un puerto, el paquete será descartado por la primera regla, y nunca llegará a evaluarse la segunda, que lo aceptaba.

Es por esto que siempre las reglas más específicas deben configurarse en la parte superior del firewall, de modo que si no hay reglas que coincidan en primera instancia, se siga evaluando el resto, hasta que alguna regla lo acepte o deniege.

En el caso particular de no tener reglas, o que ninguna regla coincida con el paquete en cuestión, se aplicarán las políticas por defecto, ya sea para aceptar o denegar, según se tenga configurado.

Por esto es importante saber, según vimos en el flujo de trabajo de iptables, qué cadenas y tablas se ejecutan primero, y cuales después, y con ello tener claro cómo escribir las reglas, y en qué orden cargarlas.

Veamos la sintaxis del comando:

Los modificadores explicados son los siguientes, para poder montar una regla básica en iptables:

  • -t: este modificador permite especificar la tabla sobre la que se está agregando la regla. Entre las opciones tenemos “filter”, “nat” o “mangle”, siendo la primera la opción por defecto en el caso de omitir este modificador.

  • Patrón: El patrón de selección permite especificar una serie de parámetros que permitirán validar determinados paquetes de red, o conexiones. Así, podremos “encontrar” cierto paquete con una dirección ip específica, o un puerto, o protocolo, o mac, etc.

  • -j establece la acción (u objetivo, según la documentación) que se llevará a cabo si el paquete que está pasando por el análisis del firewall coincide con el patrón de selección.

  • Y finalmente, el comando nos permite agregar regla, eliminar regla, y hacerlo en determinada cadena de la tabla. Aquí, por ejemplo, un “-A INPUT” permite agregar una regla (-A: Append) en la cadena INPUT de la tabla que hayamos utilizado con “-t”, idealmente, “filter”.

Patrones de selección de tráfico

Veamos ahora cómo podemos especificar los patrones de selección de tráfico que deberán coincidir con los paquetes de nuestro interés.

  • -i | --in-interface name

    Especifica el nombre de una interfaz de red por la que el paquete entró al firewall. Por ejemplo, si queremos capturar todos los paquetes que entran por la interfaz eth0, deberiamos colocar: “-i eth0”.

  • -o | --out-interface name

    Especifica el nombre de una interfaz de red por la que el paquete salió del firewall. Por ejemplo, si queremos capturar todos los paquetes que salen por la interfaz eth0, deberiamos colocar: “-o eth0”.

  • -s | --source address[/mask][,···]

    Especifica la dirección ip de origen que tienen los paquetes en el campo “source” de su cabecera IP. Aquí se pueden colocar:

    • La dirección ip del ordenador de origen, y su máscara en la notación /xx.

    • La dirección ip de la red a la que pertenece el ordenador de origen, y su máscara en la notación /xx.

    • Un nombre de host que, al momento de interpretar la regla, será resuelto a una dirección IP. En este último caso hay que tener cuidado con el nombre de host, y si éste resuelve a varias direcciones IP según balanceo de carga o geolocalización, pues, por ejemplo, si colocamos “google.com” puede que nuestra regla resuelva a una dirección IP determinada, y el paquete venga desde otra dirección IP del mismo google.com, lo que hará que la regla no tenga efecto.

  • -d | --destination address[/mask][,···]

    Idem al anterior, pero considerando la dirección IP destino de los paquetes en la cabecera IP.

  • -p | --protocol proto

    Este parámetro permite especificar el protocolo encapsulado encima de IP. Aquí las opciones válidas son tcp, udp, icmp, icmpv6, esp, ah, sctp o all.

    En el caso de las opciones tcp y udp, además podemos agregar parámetros para especificar puerto de origen o destino que traigan los paquetes en la correspondiente cabecera de transporte:

  • --sport: permite marcar el puerto origen que llevarán los paquetes en la cabecera tcp o udp, en el campo “source port”.

  • --dport: permite marcar el puerto origen que llevarán los paquetes en la cabecera tcp o udp, en el campo “destination port”.

    Por otro lado, utilizando la opción icmp, el protocolo de mensajería en redes tcp/ip, nos da la posibilidad de agregar nuevos parámetros respectivos a este protocolo, como ser el código y tipo de mensaje icmp que deberán llevar los paquetes de red. Esto puede realizarse con la opción:

    • --icmp-type, que permite cargar el tipo y código con el nombre de tipo directamente, o medianteel par tipo/código. Es decir, podemos especficar tipo_mensaje o nro_tipo/nro_codigo, donde el nro_codigo es opcional.

Mas adelante en el curso analizaremos otros patrones adicionales, ya que iptables provee una gran variedad de alternativas a la hora de establecer los patrones de selección de tráfico.

Comandos

Veamos ahora algunos comandos que podemos utilizar en iptables.

Los comandos deben escribirse en mayúsculas, y generalmente van acompañados de una cadena, aunque los hay para tareas generales en el firewall.

Veamos algunos:

  • -A | --append cadena

    Permite agregar una regla en una cadena particular.

  • -D | --delete cadena

    Permite eliminar una regla desde una cadena particular.

  • -I | --insert cadena

    Permite insertar una regla en una cadena particular. A diferencia del “-A”, el “-I” inserta la regla encima de las demás reglas de la tabla, lo que hace que sea evaluada antes que las demás, mientras que “-A” agrega una regla al final de la tabla.

  • -R | --replace cadena

    Permite reemplazar una regla con otra.

  • -L | --list [cadena]

    Permite listar las reglas de una cadena. Si se omite la cadena, se listarán todas las reglas de todas las cadenas de la tabla en cuestión, por defecto, “filter”.

  • -F | --flush [cadena]

    Permite eliminar todas las reglas de una tabla. Si se especifica la cadena, solamente aplicará a la cadena de dicha tabla.

  • -Z | --zero [cadena]

    Pone a cero los contadores de paquetes del firewall para una cadena particular, o para todas.

  • -P | --policy cadena

    Permite especificar una política por defecto para una cadena particular de una tabla. Aquí, por ejemplo, se puede establecer aceptar o denegar todos los paquetes en el caso de que no se encuentre ninguna regla que los deniegue/acepte. Esto se analizará más adelante.

Iptables: el comando y su sintaxis
12:17

Analicemos algunas acciones

Ya hemos visto cómo se establece una regla con el comando iptables, cómo especificar una tabla, un patrón de selección, y un comando para agregar o eliminar, por ejemplo, la regla, de una cadena.

Veamos ahora cómo especificar la acción a llevar a cabo con los paquetes que coincidan con la regla, y cómo podemos establecer esta acción.

Entre las acciones comunes, tenemos las siguientes:

  • DROP / ACCEPT

    DROP descarta el paquete, lo elimina, sin ningún tipo de notificación, mientras que ACCEPT lo acepta y deja pasar dentro del firewall.

    • Esta acción está disponible para la tabla filter.

  • LOG

    Permite generar una línea de log mediante protocolo syslog. Por defecto en implementaciones como rsyslog en Debian, los logs van a ser almacenados en el archivo /var/log/messages. Esta opción también da la posibilidad de agregar un nivel de log para syslog, al igual que un prefijo dentro del archivo de texto para identificar el log. Algunas opciones válidas son:

    • --log-level nivel: especifica un nivel de log para syslog.

    • –log-prefix prefijo: especifica un prefijo, en texto.

    • --log-uid: loguea el uid del usuario que genera el log.

    • --log-tcp-sequence: agrega al mensaje los numeros de secuencia de tcp,

    • --log-ip-options: agrega al mensaje la información de opciones de la cabecera IP.

  • DNAT (solo en PREROUTING y OUTPUT)

    Permite realizar destination nat en las cadenas OUTPUT y PREROUTING de la tabla NAT. Aquí podremos modificar la ip de destino de los paquetes salientes desde el firewall (OUTPUT), o los paquetes entrantes al mismo (PREROUTING).

    Esta dirección IP de destino se establece mediante el modificadro –-to-destination.

    • Esta acción está disponible para la tabla nat.

  • SNAT (solo en POSTROUTING e INPUT)

    Idem al anterior, pero para modificar la dirección ip de origen de los paquetes salientes (POSTROUTING) o entrantes directamente al firewall (INPUT).

    Esta dirección ip origen se establece mediante la opción --to-source.

    • Esta acción está disponible para la tabla nat.

  • MASQUERADE (solo para POSTROUTING)

    Idem al SNAT, con la diferencia de que, en vez de especificar una dirección ip de origen con “--to-source”, lee la información desde la interfaz de red saliente del firewall, y reemplaza esa dirección IP en la cabecera IP del paquete, en el campo “source address”.

    Esto es muy útil cuando nuestro firewall tiene una conexión ip pública con ip dinámica.

    • Esta acción está disponible para la tabla nat.

  • REDIRECT (solo para OUTPUT y POSTROUTING)

    Permite redirigir el paquete saliente a otro puerto que es diferente del puerto destino original en cabecera de transporte.

    • Esta acción está disponible para la tabla nat.

  • REJECT (solo para INPUT, OUTPUT Y FORWARD)

    Es similar a DROP, con la diferencia que en vez de descartar el paquete, lo rechaza, enviando al originante un mensaje particular.

    Este mensaje puede especificarse con la opción “--reject-tith tipo”, donde el tipo puede ser, por ejemplo, icmp-net-unreachable, icmp-host-unreachable, icmp-port-unreachable, icmp-proto-unreachable, icmp-net-prohibited, icmp-host-prohibited, o icmp-admin-prohibited.

Iptables: ¿qué podemos hacer con los paquetes? -> Acciones
09:55

Hagamos un breve paréntesis de lo que hemos visto hasta ahora para ordenarnos un poco las ideas.

Hablamos de la sintaxis del comando iptables, dijimos que el comando iptables cada vez que se ejecuta permite modificar el estado del firewall en el núcleo linux, agregando, eliminando o modificando reglas, y esta sintaxis involucraba un modificador -t que nos permitía especificar la tabla en la cual íbamos a estar trabajando con la regla, y en el caso de no especificar ninguna tabla, decíamos que la tabla por defecto era filter.

Luego teníamos diferentes comandos para manipular las reglas dentro del firewall.

Esos comandos eran por ejemplo:

  • -A para agregar una regla al final del firewall, 
  • -I para insertar una regla al principio del firewall
  • -D para eliminar una regla
  • -R para reemplazar una regla por otra
  • -F por ejemplo cuando nosotros queremos "flushear" o eliminar todas las reglas del firewall, o de alguna cadena particular
  • -Z para limpiar los contadores de tráfico entrante, saliente, descartado y demás.

Esos eran algunos de los comandos que nosotros teníamos en nuestro iptables.

El patrón de selección nos iba a permitir a nosotros especificar si la regla iba a coincidir con cierto y determinado tipo de tráfico o no.

En este caso si nosotros queremos aceptar o denegar o llevar a cabo alguna acción particular sobre un determinado tipo de tráfico, el patrón de selección debe coincidir con ese tipo de tráfico.

Y aquí teníamos algunas opciones particulares como ser:

  • -i o -o en minúscula para permitirnos especificar si el tráfico entra por una determinada interfaz de red, o sale una detemrinada interfaz de red.
  • -s o -d para especificar la dirección IP o la dirección IP de una red, o el nombre de dominio de un host que luego va a ser resuelto a una dirección IP para poder "matchear" con ese tipo de tráfico, ya sea una dirección IP entrante o saliente, siempre considerando la cabecera IP de los paquetes.
  • Además este patrón nos iba a permitir especificar el protocolo a nivel de capa 3, capa 4, en este caso serían protocolos TCP, UDP, ICMP, ICMPv6, ALL para especificar todos los protocolos. Esto quiere decir que si nosotros especificamos un protocolo particular podíamos hacer coincidir esa regla con todos los paquetes de ese protocolo, podíamos denegar por ejemplo, o aceptar todo el tráfico de protocolos TCP, de protocolos UDP, de protocolos ICMP.

A su vez, ciertos protocolos, como TCP o UDP, nos habilitaban unas opciones extra como ser --sport o --dport, que nos permitían especificar el puerto origen y el puerto destino para hacer mas específica la regla que nosotros estamos escribiendo. Por ejemplo podíamos aceptar o denegar tráfico de cierto protocolo de capa 4 como TCP, con cierto puerto destino u origen, coincidiendo por ejemplo la regla con lo que se encuentra por supuesto en las cabeceras de tráfico TCP o IP.

Y luego estos patrones que nos permiten seleccionar cierto y determinado tipo de tráfico nos iban a permitir llevar a cabo alguna acción particular, es decir, con todo el tipo de tráfico que coincide con cierto patrón yo podía llevar a cabo una acción: podía denegar o aceptar el tráfico, podía loguear ese tráfico, podíamos reenviar el tráfico con un redirect a otro puerto, a otro servicio de aplicación, podíamos descartar el tráfico enviándole un mensaje de paquete rechazado al originante de ese mensaje, en vez de simplemente descartar completamente el paquete.

Por otro lado hablamos del orden de las reglas. Dijimos que era importante especificarlas en orden, y dijimos que las reglas más específicas van en la parte superior del firewall y las reglas más generales van en la parte inferior del mismo.
De esta forma nosotros podíamos, si se quiere, denegar algún tipo de contenido en reglas superiores, y el tráfico que no coincide con ese contenido podíamos aceptarlo.

Nosotros cuando aceptamos un tipo de tráfico o paquete particular a través de iptables, automáticamente salimos de la ejecución del firewall y no volvemos a entrar hasta el siguiente paquete. De esta forma podemos ordenar correctamente las reglas, ya que si por ejemplo tengo una regla que deniega cierto tipo de contenido, y encima coloco una regla que lo acepta, vamos a aceptar el contenido y vamos a salir de la ejecución del firewall, y nunca vamos a llegar a ejecutar la regla que lo deniega. Si quiero denegar cierto tipo de tráfico debo colocar esa regla encima de la regla que lo acepta, por ejemplo.

Para esto también tenemos que tener en cuenta una concepción fundamental sobre cómo montar un firewall, y aquí tenemos dos formas: aceptar todo tipo de tráfico por defecto, mediante políticas por defecto (estas políticas las cargábamos al firewall con la opción -P) y luego ir denegando ciertos contenidos utilizando reglas comunes.

La política por defecto me iba a permitir a mi aceptar o denegar cierto tipo de tráfico en el caso de que éste no coincida con ninguna regla especificada en el firewall. De hecho, si no tengo ninguna regla especificada en el firewall, por defecto estoy siempre ejecutando estas políticas.

En un Linux recién instalado, por defecto las políticas son de aceptar todo, y es por eso que no hace falta que escribamos ninguna regla para permitirnos entrar a una página web, resolver nombres o conectarnos a un ssh, estamos aceptando todo.

Esta es una de las concepciones de un firewall: o ponemos políticas de aceptar todo tipo de contenido y luego vamos denegando algunos tipos de tráfico que no queremos que pasen.

Por otra parte podríamos denegar todo tipo de contenidos, y luego ir aceptando simplemente el tráfico que yo quiero que pase por ese firewall.

En la primera opción la escritura del firewall es sencilla, tenemos menos riesgos de cometer errores o bloquear tráfico que deberíamos dejar pasar, ya que si olvidamos escribir alguna regla que deniegue un paquete, lo estaremos aceptando. Eso también influye negativamente en la seguridad, nosotros, si vamos a abrir por defecto todo el firewall, debemos cerrar específicamente todos los puertos y tipos de conexiones que no queremos que pasen por el firewall, y debemos ser muy conscientes a la hora de escribir estas reglas.

Sin embargo, si escribimos el firewall que deniega todo y luego abrimos las conexiones que deseamos que pasen, ese problema de seguridad no lo tenemos, ya que al olvidar abrir un tipo de contenido, por defecto va a ser descartado o denegado, con las políticas por defecto a denegar todo (DROP). Sin embargo montar este tipo de firewalls es mas complejo y requiere más conocimientos por parte de quien lo administra, puesto que tenemos que saber muy bien los nombres de los protocolos, números de puertos, qué conexiones establecen conexiones relacionadas (si manejamos estados de conexiones), y algunas cuestiones que hacen al manejo más experto de un firewall.

En este caso la recomendación siempre es denegar todo, y luego ir abriendo lo que nos hace falta para poder trabajar.

Sin embargo en las primeras prácticas que hagamos vamos a trabajar con firewalls que tengan todo abierto por defecto para no comenter errores y para ir aprendiendo sobre el manejo del firewall y la configuración de las reglas.

Resumen: el comando, patrones de tráfico y acciones
09:03

¿Vas entendiendo bien todos los conceptos del curso? Esta es tu oportunidad de probarlo! Éxitos!

Autoevaluación - Sección 2
7 questions
+ Montando firewalls stateful con iptables
7 lectures 31:34

Definiendo un firewall statefull

En un firewall stateless debemos aceptar el tráfico en ambas direcciones.

Esto puede traernos algunos inconvenientes, entre ellos:

1) Un atacante podría inyectar tráfico modificado por medio de las reglas que utilizamos para aceptar tráfico de respuesta.

Imaginemos que necesitamos que la red interna salga a Internet al puerto 80 de tcp (http).
Con lo que sabemos hasta ahora, deberíamos aceptar el tráfico saliente desde la red LAN, con protocolo tcp y puerto destino 80 y el tráfico entrante hacia la red LAN, con protocolo tcp y puerto origen 80.

Ahora bien, nada le impide a algún atacante en Internet generar tráfico, paquetes IP, colocando como puerto de origen al puerto tcp80, y enviarlo a nuestra red.

Ese tráfico (por supuesto, bajo algunas consideraciones) será aceptado por nuestro firewall ya que para el firewall no hay diferencia entre un paquete nuevo que llega desde un puerto 80 y uno que representa la respuesta de un paquete saliente.

2) La definición es compleja, y por ello es propensa a errores.

La solución para esto es utilizar los estados de conexiones que administra el mismo firewall iptables.

Estados de las conexiones

En iptables los paquetes se encuentran en un estado particular, y este puede ser:

  • INVALID, o paquetes no asociados a ninguna conexión conocida
  • NEW: primer paquete transferido entre dos nodos este paquete es el que crea una nueva conexión
  • ESTABLISHED: paquete perteneciente a una conexión previamente establecida
  • RELATED: paquete nuevo, pero asociado a una conexión previamente establecida.

Estas conexiones relacionadas son propias de protocolos multiconexión, como por ejemplo ftp, que utiliza una conexión para comandos de control y otra conexión relacionada para transferencia de datos de subida o bajada.

Stateful: conceptos fundamentales
04:32

Módulos adicionales

Antes de seguir, es necesario, y para mejorara nuestra comprensión de las reglas que vendrán que hablemos de módulos de extensión de iptables, o simplemente, "match".

Las opciones que permiten especificar un patrón de selección para tráfico en iptables, mayormente, ya las hemos venido estudiando.

Hemos visto que podemos seleccionar tráfico por interfaz de red de entrada, o de salida, por dirección ip de host, red, etc., tanto de origen como destino por protocolo de transporte, puertos
de origen y destino, etc.

Para diseñar algunas reglas más específicas y con la intención de satisfacer algunas necesidades puntuales de los administradores de firewalls, iptables permite cargar módulos
de extensión o match que nos habilitan nuevas opciones para hacer aún más "fina" la selección
con nuestro patrón de tráfico.

Estos módulos se cargan con la opción "-m" acompañada del nombre del módulo, y cada módulo sumará opciones adicionales...

Algo así como cuando cargábamos la opción "-p" para protocolo, que en el caso de ser éste tcp o udp nos "habilitaba" las opciones de puerto origen o destino, --sport o --dport respectivamente.

Algunos módulos comunes son, por ejemplo,

  • connbytes, para contabilizar bytes o numeros de paquetes de una conexión o flujo de tráfico.
  • connlimit, para limitar el número de conexiones en paralelo, y con ello disminuir, por ejemplo, los destrozos que puede hacernos un ataque de denegación de servicios distribuido.
  • ah, o esp, para gestionar paquetes de autenticación y cifrado de vpn's de capa 3 como ipsec.
  • state, que nos permite especificar el estado de conexión que deberán tener los paquetes que coincidan con la regla.

En este apartado nos centraremos en state... al finalizar el curso comentaremos ejemplos de algunos módulos de extensión adicionales que pueden llegar a ser de utilidad.

Match: módulos de extensión de iptables
03:28

Stateful FORWARD

Veamos ahora algunos ejemplos siempre, por supuesto, considerando un firewall con políticas por defecto DROP.
Supongamos que tenemos un cliente conectado a un firewall que le da acceso a Internet.

El primer paquete de una comunicación entre el cliente y un equipo en Internet para iptables será considerada de tipo nueva, o NEW.

Imaginemos que este cliente necesita salir a internet a los puertos http(tcp80) dns (udp53) y ssh (tcp22).

Estas tres reglas de firewalling iptables les va a permitir la salida de los primeros paquetes hacia Internet.

Todas son forward, puesto que el tráfico pasa por el firewall, proveniente desde el cliente y con un destino en Internet, dirección ip que no corresponde con ninguna de las del firewall.

Hemos especificado la dirección ip de la LAN  que incluye al cliente y los protocolos y puertos respectivos según las necesidades.

Ahora bien, las respuestas desde Internet no están aceptadas, y serán descartadas puesto que no hemos colocado las reglas que acepten estos paquetes en el sentido opuesto, como haríamos en un firewall stateless.

Sin embargo, si agregamos una sola regla podríamos tener un efecto similar y aceptar los paquetes de respuesta.

Como se ve, esta regla también es para  la tabla filter, cadena FORWARD, con la única diferencia, y contenido nuevo, que hemos agregado la opción "-m state".

Esta opción nos permite cargar el módulo de extensión "state" de iptables.

Al cargar módulos de extensión estamos habilitando una serie de modificadores y opciones nuevos para nuestra regla.
En este caso, el módulo state nos permite especificar, entre otras cosas, el estado del paquete, mediante la opción --state.

Como se ve en la regla, los modificadores completos quedaron "-m state --state ESTABLISHED" esto quiere decir que agregamos el módulo state, y como estado, dentro del patrón de selección solamente consideramos los paquetes que pertenezcan a conexiones establecidas.

En este caso, primero aceptamos todos los paquetes salientes desde nuestra red LAN con las reglas clásicas. Estos paquetes pertenecen a conexiones nuevas. Las respuestas serán aceptadas con la regla de gestión de estado, ya que perteneceran, para iptables, a una conexión de tipo ESTABLISHED.

Como se puede apreciar, por un lado, la regla de estado permite aceptar todo el tráfico de tipo establecido en cualquier sentido, ya sea desde la red LAN hacia Internet, o desde Internet hacia los clientes de la LAN, y no solamente para los protocolos expuestos, es decir, si por ejemplo, permitimos tráfico saliente al puerto tcp443 las respuestas también serán aceptadas por la regla de estado.

Claro está que podemos restringir la regla de estados, o incluso crear más de una, según nuestras necesidades.

Por otro lado, nótese que no hemos especificado el estado de las conexiones salientes, puesto que generalmente serán todas nuevas.

No obstante, si quisiéramos, y ya con un nivel de paranoia superior, podríamos especificarlo con algo similar a "-m state --state NEW" en cada una de las reglas de protocolo.

Stateful: el caso de tráfico FORWARD
05:02

Stateful en OUTPUT

Consideremos un esquema similar al de recién donde tenemos un cliente en una LAN que conecta contra un firewall para permitirse su acceso a Internet.

En este caso, imaginemos que el cliente no desea salir a Internet si no conectar directamente al firewall por ejemplo, para administrarlo mediante un protocolo como ssh (tcp22).

Lo mismo, si desde Internet deseamos conectar contra nuestro firewall para administrarlo este tipo de tráfico será todo de tipo INPUT ya que la dirección destino de los paquetes que lleguen al firewall va a coincidir con alguna de las direcciones del firewall, ya sea la interna y privada de la LAN o la pública que expone a Internet.

La regla que no s va a permitir aceptar este tráfico desde la LAN, será una similar a la que se ve en pantalla.

Aquí, la regla es de tipo INPUT de la tabla filter tráfico proveniente desde la LAN o desde Internet (ya que no especificamos origen) y destinado al puerto 22 de tcp del firewall.

Este tráfico será aceptado, pero las respuestas no, puesto que no hemos habilitado el tráfico en sentido opuesto.

Bien, en este caso, podemos simplemente agregar una regla de gestión de estados para permitir estos paquetes de respuesta, tanto hacia la LAN, como hacia Internet.

Como se puede ver, el módulo match cargado vuelve a ser state, y el estado especificado established, como en el caso anterior.

La única diferencia es que la cadena es OUTPUT en vez de FORWARD, ya que como los paquetes entrantes
eran de tipo input, las respuestas fueron generadas en el mismo firewall, y enviadas desde su stack TCP/IP al destino, al cliente que los solicitó... esta es la definición del tráfico OUTPUT.

Como conclusión, aquí estamos aceptando todo el tráfico saliente, OUTPUT, perteneciente a conexiones ya establecidas, previamente mediante tráfico nuevo de INPUT como se puede ver en las reglas.

Al igual que el caso anterior, la regla de estados puede enriquecerse con otros modificadores y patrones de selección de paquetes, y hacerla más específica que ésta, para necesidades particulares.

Stateful: el caso del tráfico OUTPUT
03:38

Stateful en INPUT

Consideremos ahora este ejemplo, como siempre, un firewall que separa  una red LAN de Internet.

En este caso, supongamos que es el mismo firewall el que "desea" establecer conexiones hacia el exterior, por ejemplo, para llevar a cabo una actualización del sistema.

Si es este el caso, requerirá acceso a los puertos http, https y dns, tcp80, tcp443 y udp53 respectivamente.

Escribimos las reglas con las que vamos a permitir la salida de estos paquetes, son reglas OUTPUT de la tabla filter, ya que es tráfico generado en el firewall con un destino en Internet.

Ahora bien, las respuestas de estos paquetes OUTPUT, serán de tipo INPUT, ya que irán destinados al firewall, a alguna de sus direcciones IP.

Este tráfico podrá ser aceptado por medio de una regla de manejo de estados para conexiones establecidas, con la cadena INPUT de la tabla filter.

Stateful: el caso del tráfico INPUT
03:05

Stateful: conexiones relacionadas (RELATED)

Veamos ahora un ejemplo de conexiones relacionadas.

Una conexión relacionada puede considerarse una conexión establecida (established), pero que depende, o ha sido generada por otra conexión establecida ya en curso.

Este es el caso del protocolo FTP, file transfer protocol, o protocolo de transferencia de archivos.

Este protocolo utiliza dos canales  de comunicación, uno para control  y comandos, y otro para transferencia de datos.

Así, por ejemplo, cuando conectamos a un servidor ftp, estaremos utilizando el canal de control, y si ejecutamos un comando get para descargar un archivo, el comando irá por el canal de control mientras que el archivo,  viajará por el canal de datos.

Supongamos que en nuestra red LAN deseamos permitir a los clientes conectar contra servicios FTP del exterior.

Deberemos permitir, primero, las conexiones al puerto tcp21, el canal de control de FTP en el servidor.

En este caso, la regla será de tipo FORWARD, permitirá paquetes provenientes desde los equipos de la LAN y destinados al puerto 21 de tcp remoto.

Las respuestas a estos paquetes serán aceptadas por una regla de estado en la que permitamos las conexiones establecidas en forward.

Ahora bien, si el ordenador de la red ordena una descarga, o una subida de archivos al servidor ftp, la conexión puede generarse desde el interior de la red, en forma saliente, hacia el servidor, o puede ser generada por el servidor en forma entrante hacia la red.

Esto depende del modo en que el servidor y cliente estén interactuando, si es pasivo o activo, etc.

No vamos a hacernos eco de esto ahora, ya que cualquiera sea el caso, todos estos datos pertenecientes a la nueva conexión podemos tratarlos como datos pertenecientes a una conexión relacionada a otra conexión ya establecida, en este caso, la conexión de control.

Por lo que simplemente podríamos agregar una regla como esta para aceptar todos los datos de las conexiones relacionadas, independientemente de quién sea el que la establece.

Por último, el intercambio de paquetes subsiguiente, para subida o bajada de archivos, va a ser aceptado por medio de la primer regla para conexiones establecidas, puesto que la nueva conexión de datos,  la conexión relacionada, ahora es una conexión establecida nueva.

Stateful y las conexiones RELATED
06:02

En esta clase veremos algunos ejemplos adicionales del uso de reglas que apliquen el módulo match state en otros ámbitos, y con algunas particularidades especiales que pueden llegar a ser útiles para entender mejor los conceptos y aplicabilidad del módulo de extensión.

Otros ejemplos de stateful iptables
05:47
+ ¿Servidores en la LAN? Usando DNAT
2 lectures 15:19

Introducción a DNAT

Analicemos entonces el siguiente esquema.

De este lado tenemos un servidor conectado a nuestro firewall, y el firewall conectado a su vez a Internet.

El esquema es similar al que utilizamos para SNAT con la diferencia de que el servidor se encuentra en nuestra red LAN, conectado al firewall, y el firewall conectado a Internet, y en Internet vamos a disponer de clientes remotos, que bien pueden estar conectados en una ip pública directamente, o pueden estar colgados en alguna LAN corporativa por ejemplo, o alguna red hogareña en el lado de Internet.

La idea de esto es que nosotros podamos conectar desde nuestro cliente hacia nuestro servidor y podamos ver, por ejemplo, un sitio web, o cualquier otro servicio que nosotros quisiéramos acceder.

Para empezar vamos a tener un set de IP's privadas, una ip_priv1 del lado del servidor, y una ip_priv2 del lado del firewall. Vamos a denominarlas así para facilitar los cálculos.

Del lado de Internet vamos a tener una ip_pub1 del lado del firewall, va a ser la ip pública que va a tener el firewall hacia Internet, la que va a exponer a Internet, y una ip_pub2 que va a ser la de nuestro cliente.

Si bien nuestro cliente puede llegar a tener una ip privada, vamos a considerar la ip pública del router que le da acceso a ese cliente a Internet, ya que la negociación del SNAT del cliente con el router ya la conocemos.

La conexión va a venir directamente desde la IP pública del cliente hacia la ip pública de nuestro firewall, y la idea va a ser acceder desde esa ip_pub1 hacia nuestro servidor en una ip privada.

Consideremos la siguiente situación. En este caso el cliente va a intentar establecer una conexión a un protocolo que brinde nuestro servidor... un servicio que brinde nuestro servidor en nuestra ip privada.

El paquete que genera el cliente, como dijimos, si bien puede ser privado, después su router, una vez que haga el SNAT, va a ir destinado a la ip pública de nuestro firewall de alguna forma... ya sea, como dijimos, una resolución de nombres de dominio (DNS) o una DNS dinámica, o directamente mediante la dirección IP si la conocemos, y nuestro servicio por supuesto está atendiendo y trabajando con esa configuración.

El paquete va a estar originado en la ip pública del firewall o el router del cliente, y destinado a la ip pública de nuestro firewall.

Ese firewall deberá realizar un procesamiento interno que le permita cambiar la dirección ip destino, que en este caso es la ip_pub1, por la ip privada del servidor que nosotros tenemos en nuestra red LAN, y con esa ip privada automáticamente lo inyecta en la red LAN y el paquete va a llegarle al servidor que nosotros tenemos montado en la red.

Cuando el servidor pueda interpretar ese paquete, por ejemplo, si es un servidor web, generará una respuesta http o https; si es un servidor ftp generará una respuesta ftp, o DNS, o dependiendo del protocolo que esté atendiendo ese servidor, va a generar la respuesta y la respuesta va a ir originada en la IP privada del servidor, como puede verse, y va a ir destinada a la ip_pub2 que es la ip que utilizó el cliente que consultó... esa IP no se modificó en ningún momento.

El paquete va a viajar a nuestro router, y el router va a hacer ahora un paso inverso y va a cambiar la ip de origen, la ip privada del servidor, por la ip pública del router, que es la ip "routeable" en Internet que le va a permitir al cliente obtener una respuesta directa desde nuestro router firewall.

Ese cambio es automático y se lleva a cabo mediante la tabla de asociaciones de conexiones que mantiene el firewall, y que va a hacer uso para poder establecer o mantener esta conexión.

Esa ip_pub1 va a ser colocada entonces en la cabecera del protocolo IP del paquete saliente desde el firewall hacia Internet, y va a llegar al cliente, que va a poder interpretar esa información.

Este comportamiento puede analizarse desde dos puntos de vista diferentes.

Por un lado, si vemos desde la parte del cliente que intentó hacer la conexión con nuestro servidor privado en la LAN, vemos que el cliente genera tráfico desde su dirección ip pública, en este caso la ip_pub2, ya sea directamente o indirectamente a través del SNAT, y ese tráfico va a ser destinado a la ip publica del firewall, ip_pub1, por lo tanto desde el punto de vista del cliente, el cliente "cree" que el servidor es el firewall. Así, toda la interacción entre el cliente y el servidor va a ser tráfico que viaje entre el cliente y el firewall.

Por otro lado, si lo analizamos desde el punto de vista del nuestro servidor local en la LAN, va a "ver" que el tráfico proviene desde un cliente remoto, una ip_pub2, y va destinado a su ip privada, es decir, para el servidor también es indistinto quién genera o transforma esas IP's en el camino.

El servidor va a recibir tráfico desde la ip_pub2 a su ip_priv1 y va a generar la respuesta hacia la ip_pub2. Entonces, desde el punto de vista del servidor, el tráfico va a pertenecer a una conexión que se establece entre la ip del cliente, ip_pub2, y la ip del servidor, ip_priv1.

Veamos ahora cuáles son las reglas que permiten darle vida a este mecanismo de iptables.

Por un lado tenemos una regla de tipo filter de la cadena FORWARD, que va a permitir todo el tráfico con destino puerto tcp80, por ejemplo, si nuestro servidor privado es un servidor http, con destino a la ip_priv1, y vamos a aceptar ese tipo de tráfico.

Por supuesto aquí hay que agregar las reglas de manejo de estados para que las respuestas en forward también sean aceptadas, o en el caso de que no trabajemos con estados, para que las respuestas desde la ip_priv1, con puerto origen tcp80 también sean aceptadas por nuestro firewall.

Y por otro lado, tenemos una regla de la tabla NAT que es la que termina realizando la "magia" de traducir las direcciones de red para que el cliente remoto pueda acceder, en definitiva, al servidor privado que nosotros tenemos en la LAN.

Esta regla de la tabla NAt pertenece a la cadena de PREROUTING, antes de realizar cualquier decisión de ruteo cuando el paquete entra en nuestro firewall. Si el paquete pertenece o va destinado a un puerto tcp80 destino en este caso, vamos a realizarle una acción denominada DNAT para cambiar la ip de destino de ese paquete con --to-destination a la ip_priv1.

Recordemos, el paquete viene destinado a la ip_pub1 de nuestro firewall, y debemos con esta regla modificar esa ip de destino a la ip_priv1, la ip de nuestro servidor en la LAN.

Hasta aquí el paquete ha llegado al servidor, ha salido del cliente, hemos cambiado la dirección ip de destino por la dirección privada de nuestro servidor, el paquete ha sido aceptado con la cadena FORWARD de la tabla filter, ha pasado el firewall y ha llegado al servidor.

La respuesta del servidor irá destinada a la dirección IP pública del cliente, llegará al firewall, deberá ser aceptado con otra regla que previamente deberíamos haber agregado al firewall para que acepte los paquetes correspondientes de FORWARD, ya sea en stateless o stateful, y el cambio de la dirección de origen, en este caso, que es la dirección privada del servidor, ip_priv1, por la ip_pub1 va a ser automático gracias a que iptables mantiene una tabla de asociación de las conexiones, y el paquete va a llegar hacia el cliente en Internet.

Para terminar de entender esta implementación hay que tener en cuenta un punto muy importante. En la tabla filter la cadena de FORWARD que nos sirvió a nosotros para aceptar el tráfico que llega desde el cliente hacia nuestro servidor privado, hemos utilizado el puerto destino TCP 80, y hemos utilizado la dirección ip privada del servidor.

¿Por qué utilizando la dirección ip privada del servidor y no la ip pública con la que viene el paquete originalmente? Porque recordemos que antes de ejecutar esa regla de filtrado en la tabla filter con la cadena de FORWARD, primero se realiza una decisión de ruteo para saber a qué equipo interno vamos a enviarle, y para saber también si el paquete va destinado a un equipo que está detrás del firewall, o va destinado al propio firewall, y antes de realizar esa decisión de ruteo es que se ejecuta la regla de la tabla NAT para PREROUTING.

Entonces al ejecutar la regla de la tabla NAT, ni bien llega el paquete, cambiamos la dirección destino de ese paquete por la dirección privada de nuestro servidor, y cuando tomamos la decisión de ruteo, y cuando pasamos a la tabla filter, el paquete ya cuenta con la dirección privada en la cabecera IP, en el campo de ip de origen, de modo que una vez que entra el paquete, se ejecuta el PREROUTING de NAT, y todo el procesamiento interno de filtrado, ya sea para INPUT o para FORWARD, como es el caso de este ejemplo, va a tener ya la ip modificada.

Luego cambiará en el POSTROUTING, que en este caso es automático cuando el paquete sale a Internet hacia el cliente remoto... ahí cambiaremos la dirección origen del paquete por la dirección pública del router/firewall.

Esto es importante tenerlo en cuenta porque si colocamos la ip pública en la regla de filtrado, ningún paquete va a coincidir con esa ip pública en nuestro ejemplo, puesto que cuando se analiza el paquete ya la ip pública ha sido modificada por la ip privada del servidor, que es la que nosotros tenemos que tener en cuenta para analizar el tráfico y dejarlo pasar o bloquearlo.

DNAT: Introducción y conceptos
04:44

En esta oportunidad aprenderemos a configurar iptables para que, mediante reglas de PREROUTING (tabla NAT) podamos publicar, hacia Internet, un servicio interno que tengamos montado en nuestra red local.

Cabe aclarar que, si bien el servicio estará publicado en la dirección IP que tenga el firewall, esta dirección IP puede cambiar periódicamente dependiendo del servicio de banda ancha que nos entregue nuestro proveedor de servicios de Internet (ISP), por lo que para poder acceder a nuestro servidor deben cumplirse algunas condiciones adicionales, tales como que la IP sea la correcta en el momento de establecer la conexión desde el cliente, y, opcionalmente, que tengamos apuntado correctamente un dominio o DDNS a la ip pública.

Por supuesto, no hay que olvidar que cada servicio tendrá sus parámetros de configuración particulares que también deberemos considerar a la hora de acceder al servicio.

DNAT: Manos a la obra con iptables!
10:35
+ Un ejemplo completo ( o casi :P )
6 lectures 46:42

En esta clase introduciremos nuestro entorno de laboratorio. Este ejemplo de configuración de firewall vamos a realizarlo sobre un sistema Debian GNU/Linux, que estará conectado a Internet por un lado, y por otro, conectado a un cliente Ubuntu, que hará las veces de red LAN.

Veremos qué configuraciones básicas tienen tanto el firewall Debian, como el Ubuntu, en cuanto a iptables, y analizaremos la topología de red y direccionamiento IP.

Preview 05:28

Aquí veremos cómo empezar a escribir nuestro script de firewalling paso a paso. Analizaremos y explicaremos las reglas básicas que debería tener un script de iptables.

A esto agregaremos las reglas necesarias para montar un firewall statefull mediante el módulo match state de extensión de iptables.

Por último, agregaremos las reglas necesarias para poder conectarnos al firewall en forma remota por medio de SSH, conexión necesaria en este ejemplo para poder administrarlo (caso particular de estudio).

Configuración básica del firewall iptables
05:37

Ahora agregaremos las reglas necesarias para permitirle a nuestro cliente Ubuntu la navegación en Internet. Esto es, puertos http, https y dns, por supuesto, con manejo de estados de conexiones.

También veremos en esta clase cómo listar las reglas del firewall para cada tabla, y cómo entender las salidas del comando "-L" y "-nL" de iptables.

Para el cometido de permitirle al cliente la navegación, también será necesario cargar la regla básica de NAT para la cadena POSTROUTING en la que "enmascaremos" o realicemos un SNAT/MASQUERADE con los paquetes salientes a la red.

Agregando reglas: filter y SNAT/MASQUERADE
12:18

Con el firewall configurado, ha llegado el momento de probarlo!

En esta oportunidad vamos a probar los protocolos que nuestro cliente Ubuntu tiene habilitados gracias a las reglas que cargamos en el firewall Debian, y veremos cómo funcionan.

Un caso interesante en este video es cómo, al modificar una regla de firewall y recargar el mismo, podemos ver el efecto inmediato en el cliente, particularmente bloqueándo el servicio de resolución de nombres (DNS, udp53).

Por último, vamos a considerar que este cliente Ubuntu es la estación de trabajo (workstation) del administrador de la red, o sysadmin, y necesita "salir" a Internet para conectarse a un servidor SSH remoto. Para ello configuraremos en el iptables las reglas necesarias para que el Ubuntu pueda realizar esta tarea, con un caso de ejemplo de conexión satisfactoria.

Probando el firewall! Y agregando mas reglas
10:18

Ahora vamos a suponer que nuestro cliente Ubuntu es, además, un servidor web (o de cualquier otro servicio), y vamos a proceder a configurar las reglas de filter que permitan el acceso desde Internet a dicho servicio.

Por supuesto, aquí también configuraremos las reglas de NAT necesarias para permitir la redirección del tráfico desde Internet hacia el servidor Ubuntu, que está corriendo los servicios en una dirección IP privada de la red LAN (DNAT).

Montando nuestro servidor en la LAN: DNAT
10:23

Finalmente hemos terminado de montar nuestro firewall! Aquí algunas notas adicionales.

Este ejemplo permite analizar cómo se utilizan las reglas de filter, tanto de INPUT como OUTPUT, y además las reglas FORWARD para conexión del cliente remoto.

Hemos visto también las reglas de NAT tanto para POSTROUTING (SNAT/MASQUERADE) como para PREROUTING (DNAT), abarcando prácticamente todo el espectro de reglas del firewall vistas en el curso.

Cada una de las reglas planteadas funcionan, pero pueden adaptarse con otros modificadores y patrones de selección de tráfico para que puedan servir en cualquier entorno. Esto fue solamente un ejemplo sencillo que tuvo la intención de mostrar, en directo, cómo ir escribiendo un script de iptables para un firewall GNU/Linux.

Si bien este ejemplo sirvió para configurar iptables en Debian, el firewall es parte del núcleo Linux, por lo que las mismas configuraciones son válidas para cualquier distribución del sistema operativo del pingüino :)

En el material adicional de esta clase podrán acceder a un link en el que explico cómo configurar un script para que se ejecute al inicio de la distribución GNU/Linux systemd (la mayoría de las distros actuales). Ese contenido es válido para permitir que nuestro script de iptables se ejecute cada vez que se inicie la computadora firewall.

Notas finales: cerrando el ejemplo
02:38
+ Bonus y clases adicionales (nuevos contenidos segun requerimiento de alumnos)
13 lectures 01:09:54
GNS3 + VirtualBox - Intro
00:36
GNS3 + VirtualBox - Parte 1
07:51
GNS3 + VirtualBox - Parte 2
06:21

aaaa

GNS3 + VirtualBox - Parte 3
07:18
GNS3 + VirtualBox - Parte 4
05:35
NUEVO: Configuración de red en GNS3+VirtualBox - Parte 1
06:53
NUEVO: Configuración de red en GNS3+VirtualBox - Parte 2
08:54
NUEVO: Configuración de red en GNS3+VirtualBox - Parte 3
04:27
NUEVO: Configuración de red en GNS3+VirtualBox - Parte 4
05:02
NUEVO: Configuración de red en GNS3+VirtualBox - Parte 5
05:19
Mitigando ataques de DDoS con iptables
00:29

Modelo de capas TCP/IP

OSI es una sigla que identifica al MODELO DE INTERCONEXIÓN DE SISTEMAS ABIERTOS (Open System Interconection). Es un estandar de la ISO creado en 1984.

Cabe destacar que el modelo OSI es un estándar y modelo de referencia teórico, no tiene ninguna implementación práctica, pero sirve de referencia a otros modelos de interconexión de sistemas.

Es una norma formada por 7 capas, y define las diferentes fases por las que deben pasar los datos desde un dispositivo de red a otro.

Debido al avenimiento de multitud de fabricantes y tecnologías de comunicación, es sumamente útil poder estratificar las conexiones y sus tareas en diferentes capas, asignando funcionalidades específicas en cada una.

Además, y como ventaja de este tipo de modelos de comunicaciones, es que los protocolos de cada capa definen la forma de comunicarse con protocolos de otras capas, y de esta manera, manteniendo la misma interfaz de comunicación, es posible cambiar un protocolo de capa por otro de la misma capa para lograr otro tipo de conexión, y que el modelo de comunicación siga trabajando sin problemas.

Capas

El modelo OSI tiene el siguiente esquema de capas:

Capa física

Se encarga de establecer el medio físico y la forma en que se comunican los datos.

Define, entre otras cosas, el medio físico (cable de pares trenzados, RS232/EIA232, coaxial, guías de onda, aire, fibra óptica, etc. También establece las características de los materiales, como conectores, tensiones, etc.

La función de la capa física es transmitir señales eléctricas en el medio de transmisión, como un flujo de bits.

Capa de enlace de datos

Esta capa se ocupa del direccionamiento físico, de la topología de la red, del acceso al medio, de la detección de errores, de la distribución ordenada de tramas y del control del flujo.

Se encarga de verificar la transmisión de tramas de enlace. La trama es la unidad de transporte de esta capa. Se encarga de corregir errores sobre el medio físico, tal como cables utp de 8 hilos.

Un equipo que corre en esta capa, o dispositivo de comunicaciones que “entiende” protocolos de capa de enlace es el switch. Un switch recibe los datos desde algún router, y los envía a los destinatarios. Es el switch entonces, en este caso, quien realiza todos estos chequeos de integridad y errores antes de enviar los datos a quien corresponda.

Capa de red

Entre las tareas de la capa de red se encuentran el direccionamiento lógico de equipos, y el enrutamiento de los paquetes entre hosts. La unidad de transferencia se denomina paquete.

El objetivo de la capa de red es hacer que los datos lleguen desde el origen al destino, aún cuando ambos no estén conectados directamente.

El dispositivo de capa de red por excelencia es el router, o “encaminador”.

Los firewalls actúan sobre esta capa principalmente, para descartar direcciones de máquinas.

Capa de transporte

Capa encargada de efectuar el transporte de los datos (que se encuentran dentro del paquete) de la máquina origen a la de destino, independizándolo del tipo de red física que se esté utilizando.

La unidad de transferencia en transporte se denomina segmento (si es transporte orientado a la conexión) o udp (si es transporte no orientado a la conexión).

Las conexiones se llevan a cabo a través de sockets del tipo ip:puerto.

Capa de sesión

Se encarga de controlar y mantener el enlace establecido. Se trata de manejar las sesiones establecidas entre dos equipos, y en caso de que hubieran fallos, reanudarlas o reiniciarlas.

Son por lo general tareas prescindibles y sirven para mejorar el manejo y fiabilidad de las conexiones establecidas.

Capa de presentación

En esta capa se logra que, independientemente de los mecanismos de codificación de cada equipo particular, los datos lleguen de manera legible a las aplicaciones.

Se trabaja con el contenido de los mensajes, más que con los mecanismos de comunicación, y se definen sintaxis y semántica de los mensajes y cabeceras de datos.

Permite, entre otras cosas, cifrar datos mediante diferentes mecanismos, a modo de intermediario entre el dato que se envía y el dato generado en la aplicación, o viceversa.

Capa de aplicación

Ofrece a las aplicaciones la manera de intercambiar datos mediante protocolos determinados, que les permiten a las mismas acceder al stack de protocolos tcp/ip y con ellos efectuar la comunicación.

Protocolos de aplicación son, por ejemplo, smtp, snmp, pop, imap, http, etc.

Aunque se denomina “aplicación”, el usuario generalmente no está en contacto directo con esta capa, sino que la utiliza a través de diferentes aplicaciones de usuario final que le permiten interactuar de una manera sencilla.

MODELO TCP/IP:

El modelo tcp/ip es un modelo práctico basado en el anterior ISO/OSI.

Es un modelo de comunicaciones práctico simplificado creado por DARPA (Departamento de defensa de USA).

Describe un modelo de comunicación también basado en capas, pero en este caso se trata de 4 capas solamente, cada una con sus funcionalidades y sus comunicaciones entre sí.

El modelo tcp/ip está definido en la rfc1122, donde se especifican todos sus detalles de funcionamiento e implementación.

Para lograr un intercambio correcto y fiable de datos, es necesario un software complejo que pueda llevar a cabo muchas tareas. Con el modelo de capas, se estratifica el software o los softwares en implementaciones más sencillas en cada capa, y el funcionamiento general se logra interactuando entre estas implementaciones.

Aplicación

Equivale a las capas de sesión, presentación y aplicación del modelo OSI, y todas sus funcionalidades.

Los protocolos de esta capa deben llevar a cabo tareas tales como la representación, codificación y control de comunicación entre los hosts.

Transporte

Equivalente a la capa de transporte del modelo OSI.

Red

Equivalente a la capa de red del modelo OSI.

Acceso al medio

Equivale a las capas de enlace y capa física del modelo OSI.

Si bien cuando sale un paquete desde una aplicación de un equipo hacia otra en otro equipo, primero pasa a capa de transporte, luego red, y luego al medio físico, para "subir" por el stack destino hasta la aplicación destino, existe una comunicación "virtual" entre capas del mismo nivel en ambos equipos.

Encapsulación

Cuando una aplicación envía datos a otra en otro equipo, se les adosa un header de aplicación, y estos datos pasan a la capa de transporte local.

En esta capa se le adosa un header de transporte, creando el segmento tcp, que se manda a la capa de red. En la capa de red se le adosa un header IP creando el datagrama IP, y se envía a la capa de acceso al medio. En esta capa se le adosa un header ethernet, y un trailer ethernet para poder enviarla al medio físico.

De manera similar, cuando el paquete ethernet llega a destino, va pasando sucesivamente por cada una de las capas tcp/ip quitándoles los headers adicionales, hasta llegar el dato de aplicación a la aplicación destino.

Nociones del stack de protocolos TCP/IP
09:01

Udemy nos permite a los instructores facilitarles algunos beneficios a nuestros alumnos. En esta clase extra (Bonus Lecture) podrás encontrar mis otros cursos, y accesos al mínimo precio sólo disponibles para alumnos.

¡¡¡ CLASE EXTRA / BONUS !!!
02:07