SEGURIDAD - FIREWALLS ( CORTAFUEGOS)

INTRODUCCIÓN

En repetidas ocasiones me habéis solicitado que escriba algún artículo sobre firewalls (cortafuegos). Realmente, aunque es muy fácil escribir sobre ellos, es muy difícil generalizar. Difícil y problemático. No sólo se deben poner las "reglas" de lo que queremos hacer, sino que lo más importante es entenderlas, y por desgracia, para entenderlas, debemos primero entender algo del funcionamiento del TCP/IP. Voy a intentar descender lo menos posible a nivel técnico, de tal manera que un usuario final pueda entender el funcionamiento e incluso los requerimientos de su sistema sin necesidad de ser un experto en el TCP/IP.

La configuración de un firewall, no pasa sólo por bloquear todos los puertos y ya está. Es necesario saber qué bloqueamos y para qué, sobre todo pensando que poco a poco tendremos que establecer reglas, debido a los requerimientos del software que tengamos instalado y que vayamos instalando, con lo cual la administración de dicho cortafuegos se irá complicando.

Muchos de los hackers que entran en los sistemas protegidos con cortafuegos lo consiguen únicamente por una mala administración del cortafuegos. Con el tiempo y debido a la administración del cortafuegos, se va relajando la seguridad... y una regla mal establecida o fuera de orden implica que dejamos abierto un agujero que antes o después alguien intentará aprovechar.

La teoría básica de un firewall debe ser muy sencilla: debe ser el paso entre una red y otra y debe cumplir estos tres requisitos básicos (provisionales):

1) Todo el tráfico que pase entre dos redes, debe ser únicamente a través del firewall.
2) Sólo el tráfico autorizado por el firewall es el que puede pasar de una red a otra.
3) El firewall, en sí mismo, debe ser inmune a un compromiso (se supone que debe estar libre de errores, que no puede comprometerse desde el exterior y por tanto no se puede tomar control de él).

INTRODUCCIÓN AL FUNCIONAMIENTO DE MENSAJES BAJO EL PROTOCOLO TCP/IP.

¿Cómo se envían paquetes de una máquina a otra, y por tanto de una posible red a otra posible red?.

Empecemos viendo qué es un paquete y cuántos tipos de paquetes hay: un paquete no es nada más que un mensaje con datos, al cual se le han añadido unos cuantos bytes de cabecera. Estos bytes los añaden los programas y drivers responsables del TCP/IP en cada sistema operativo .

Básicamente en estas cabeceras, aparte de información técnica, van una serie de datos que son importantísimos:

* Tipo de mensaje. Dentro de los mensajes, existen de múltiples tipos. En nuestro caso, vamos a ceñirnos únicamente a tres, que son los que nos interesan en este caso particular: TCP, UDP e ICMP. A pesar de que solo vamos a analizar estos tres tipos, debemos recordar que existen muchos otros tipos de mensajes.Veremos una introducción un poco más adelante.

* Dirección IP de la máquina origen del mensaje, puerto de esa máquina, dirección IP de la máquina destino del mensaje y puerto al que va a llegar. Recordemos que un puerto no es nada más que un número entre 0 y 65535. Revisemos un poco el concepto de "puerto":

Al arrancar una máquina con TCP/IP, el subsistema de redes de TCP/IP, crea una tabla en principio en vacío con los 65535 posibles puertos de la máquina. Si un programa, desea ser un servicio o servidor de TCP/IP, lo que hace es comunicarle al TCP IP que es un servicio y que quiere tener el puerto 80 (por ejemplo, un servidor web; o el puerto 21: un servidor ftp). El TCP/IP guarda en esa tabla el nombre del programa o la tarea que va a utilizar, en este caso el puerto 80. Y todos los mensajes TCP/IP que reciba, y en cuya cabecera figure la dirección IP de su máquina y el puerto 80, se los enviará directamente a ese programa.

Por definición del TCP/IP, los puertos 0 a 1024 quedan reservados para tareas, servicios y sistemas del TCP/IP. Los puertos superiores al 1024, son para programas de usuario, programas de aplicación, y otros serán "temporalmente" utilizados por servicios a dichos programas. Únicamente debemos recordar, que cuando alguien, (algún programa o servicio) va a utilizar un puerto, debe notificárselo al TCP/IP.

Evidentemente, si nuestra máquina recibe un paquete TCP/IP dirigido a un puerto que no tiene ningún servicio asociado (que no ha sido registrado por el TCP/IP), inmediatamente el mensaje será descartado.

TCP, UDP e ICMP

Básicamente, y a nuestros efectos de usuarios domésticos, únicamente tenemos que "entender" un poquito sobre estos tres tipos de mensajes.

TCP y UDP son mensajes de datos. ICMP son mensajes de control. Dentro de estos últimos, por ejemplo, está el PING que todos conocemos para saber si una máquina responde o no responde.

PING a una determinado dirección IP, ejecutado en una ventana de comandos, nos devolverá un mensaje de si la máquina es alcanzable o no. Realmente el PING no es nada más que un mensaje ICMP de tipo 8 (echo request). Si nos fijamos, estos mensajes no son para llevar datos. Son sólo mensajes de control.

Los mensajes ICMP también son muy importantes de cara a seguridad. A mí, particularmente, no me gusta demostrar si estoy o no conectado a la red (y a muchos servidores de Internet, tampoco). Por tanto, cortando el tráfico de los mensajes ICMP tipo 8, ya sabemos que no responderemos a un ping. Más adelante veremos que a nivel doméstico se pueden cortar todos los mensajes "entrantes" ICMP. Insisto: a nivel doméstico... ya que a otro tipo de niveles no es aconsejable cortar todos los tipos específicos de ICMP.

Veamos los mensajes de datos:
¿Cómo se inicia una conversación? Simplemente, cuando una máquina quiere hablar con otra le envía un mensaje a su dirección y a un puerto. (El puerto, por decirlo de alguna manera, es simplemente el decirle de qué queremos hablar. Recordemos que hay una serie de puertos estándar: el puerto de servidor web, por ejemplo, que es el puerto 80).

Veamos un ejemplo: cuando desde un navegador queremos ir a la página www.microsoft.com, lo primero que hace el navegador es averiguar la dirección IP de www.microsoft.com. Esto lo resuelve consultando a los servidores de nombres: DNS. Una vez que ha recuperado dicha dirección, se dirige a la propia máquina en donde estamos (le pregunta a las rutinas del TCP/IP) para que nos dé un puerto libre de nuestro PC. Imaginemos que nos da el puerto 3124. Yel navegador se coloca "en escucha" en dicho puerto.

A continuación, prepara un mensaje con el socket. Es decir, nuestra dirección IP, nuestro puerto (3124), la dirección IP de destino (www.microsoft.com) y el puerto de web: 80.

El servidor de Microsoft, al recibir la petición, lo que hace es enviar un mensaje, ahora a nuestro puerto 3124 con el contenido de su página (texto, imágenes, etc.).

Realmente es así de sencillo (se complica un poco más, porque la página, normalmente tiene enlaces a gráficos y a otras subpáginas, y por tanto, en vez de un solo mensaje de vuelta, suele ser una combinación, o una especie de conversación entre el navegador y el servidor web, hasta que a través de varios mensajes recupera todos los datos.

Bien, volvamos ahora a lo que realmente son los dos tipos de mensajes mencionados al principio: TCP y UDP. Ambos contienen datos.... pero dependiendo del programa "receptor" en nuestra máquina, pueden usarse datagramas UDP o mensajes TCP.

Recordemos que el TCP/IP se basa en el principio de la "patata caliente". Si nos dan una patata caliente ¿qué hacemos?... Sencillo, una de dos: o la pasamos inmediatamente a otro, o la tiramos al suelo. Nunca nos la quedamos.

Con los mensajes TCP/IP. pasa lo mismo. Estos mensajes atraviesan un montón de máquinas, routers, etc. hasta llegar al destino. Estas máquinas, al no ser un mensaje para ellos, o lo pasan inmediatamente o lo tiran sin decir nada. Con esto quiero decir... que es probable que un mensaje no llegue al destino y por tanto las rutinas del TCP/IP cuando se ha establecido una conversación entre dos máquinas, deben ser capaces de intentar mantener un diálogo... es decir: deben llevar el control de los mensajes recibidos y solicitar una repetición de un mensaje o parte de un mensaje si este se pierde.

Compliquémoslo un poquito más: un mensaje que sale de una máquina con un tamaño determinado, puede ser necesario que otra máquina (un router por ejemplo) lo fragmente. Por lo cual, 1 mensaje emitido puede que se transforme en nmensajes recibidos. Debido a que los mensajes, además, pueden seguir rutas diferentes, a la hora de llegar a nuestra máquina puede que lleguen desordenados, que alguno de los trozos falten, o que incluso lleguen trozos del mensaje duplicados.

Y para complicarlo más: no hay garantía de entrega.

En TCP, los mensajes son recibidos por las rutinas del TCP del sistema operativo. Cuando un mensaje TCP es pasado a nuestro programa de aplicación, el mensaje es bueno. Ya está, por decirlo de alguna manera, "depurado". El mensaje se ha rehecho, a pesar de las posibles fragmentaciones, etc., de tal manera que está en el formato original que salió. Existe garantía de entrega al programa de aplicación, ya que las rutinas del TCP se encargan de la integridad de datos y de solicitar si es necesario los datos de nuevo.

En UDP, no es así: todos los mensajes se pasan al programa de aplicación tal y como se recibe (si es que se recibe, además). Es el programa de aplicación el responsable de gestionar dichos datos.

Parece, según lo anterior, que lo lógico es que todos los mensajes fuesen TCP. De esta manera, efectivamente, los programas de aplicación serían mas sencillos ya que no tienen que controlar casi nada. Pero por contra, hay muchos paquetes que prefieren el UDP. Simplemente porque el mensaje les llega en "crudo"..... y a veces, ya lo veremos posteriormente, tiene sus ventajas.

Continuará...

--
José Manuel Tella Llop
jmtella@compuserve.com