INTRODUCCION ------------ En repetidas ocasiones me habeis solicitado que escriba algún articulo sobre firewalls (cortafuegos). Realmente aunuqe es muy facil escribir sobre ellos, es muy dificil del generalizar. Dificil y problematico. No solo se deben poner las "reglas" de lo que queremos hacer sino que lo mas 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 tecnico de tal manera que un usuario final pueda entender el funcionamiento e incluso los requerimientos de sus sistema sin necesidad de ser un experto en el tcp/ip. La configuracion de un firewall, ni pasa solo por bloquear todos los puertos y ya está. Es necesario saber que bloqueamos y para que, 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 administracion de dicho cortafuegos se irá complicando. Muchos de los hackers que entran en los sistemas protegidos con cortafuegos lo consiguen unicamente por una mala administracion del cortafuegos. Con el tiempo y debido a la administracion 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 despues alguien intentará aprovecharlo. La teoría basica 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 trafico que pase entre dos redes, debe ser unicamente a través del firewall. 2) Solo el tráfico autorizado por el firewall es el que puede pasar de una red a otra. 3) El firewall, en si mismo, debe ser imnune a un compromiso. (se supone que es debe estar libre de errores, que no puede comprometers desde el exterior y por tanto no se puede tomar control de él). INTRODUCCION AL FUNCIONAMIENTO DE MENSAJES BAJO EL PROTOCOLO TCP/IP ------------------------------------------------------------------- * ¿como se envían paquetes de una maquina a otra, y por tanto de una posible red a otra posible red?. Empecemos viendo que es un paquete y cuantos tipos de paquetes hay: un paquete no es nada más que un mensaje con datos, al cual se le ha añadido unos cuantos bytes de cabecera. Estos bytes los añaden los programas y drivers responsables en cada sitema operativo del tcp/ip. Basicamente en estas cabeceras, aparte de informacion tecnica, van una serie de datos que son importantisimos: * Tipo de mensaje: (UDP, TCP, ICMP, etc....). Veremos una introduccción un poco más adelante. * Direccion IP de la maquina origen del mensaje, puerto de esa maquina, dirección IP de la maquina destino del mensaje y puerto al que va a llegar. Recordemos, que un puerto, no es nada más que un numero entre 0 y 65535. Revisemos un poco el concepto de "puerto". * Al arrancar una maquina con tcp/ip, el subsistema de redes de tcp/ip, crea una tabla en principio en vacio con los 65535 posibles puertos de la maquina. 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 serivdor web, o el puerto 21: un servidor ftp). El tcp/ip, se 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 que figure en la cabecera la direccion IP de su maquina y el puerto 80, se lo enviará directamente a ese programa. Por definicion del tcp/ip, de 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 aplicacion, y otros serán "temporalmente" utilizados por servicios a dichos programas. Unicamente debemos recordar, que cuando alguien, (algun programa o servicio) va a utilizar un puerto, debe notificarselo al tcp/ip. Evidentemente, si nuestra maquina recibe un paquete tcp/ip dirigido a un puerto que no tiene ningun servicio asociado (que no ha sido registrado por el tcp/ip), inmediatamente el mensaje será descartado. * Dentro de los mensajes, existen de multiples tipos. En nuestro caso, vamos a ceñirnos unicamente 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. TCP UDP e ICMP -------------- Basicamente, y a nuestros efectos de usuarios domesticos, unicamente 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 ultimos, por ejemplo, está el PING que todos conocemos para saber si una maquina responde o no responde. PING a una determinado direccion IP, ejecutado en una ventana de comandos, nos devolverá un mensaje de si la maquina 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 solo mensajes de control. Los mensajes ICMP tambien son muy importantes de cara a seguridad. A mi, particularmente, no me gusta demostrar si estoy o no conectado a la red (y a muchos servidores de internet, tampoco). Por tanto, cortando el trafico de los mensajes ICMP tipo 8, ya sabemos que no responderemos a un ping. Mas adelante veremos, que a nivel domestico, se pueden cortar todos los mensajes "entrantes" ICMP. Insisto: a nivel Domestico.... ya que a otro tipo de niveles no es aconsejable cortar todos los tipos especificos de ICMP. Veamos los mensajes de datos: ¿como se inicia una conversacion?: Simplemente cuando una maquina quiere hablar con otra, le envia un mensaje a su direccion y a un puerto. (el puerto, por decirlo de alguna manera, es simplemente el decirle de que queremos hablar. Recordemos que hay una serie de puertos estandar: el puerto de servidor web, por ejemplo, que es el puerto 80). Veamos un ejemplo: cuando desde un navegador queremos ir a la pagina www.microsoft.com, lo primero que hace el navegador es averiguar la direccion IP de www.microsoft.com. Esto lo resuelve consultando a los servidores de nombres: DNS. Una vez que ha recuperado dicha direccion, lo que hace, es pregunta a la propia maquina en donde estamos (le pregunta a las rutinas del tcp/ip) que nos de un puerto libre de nuestor PC. Imaginemos que nos da el puerto 3124. I el navegador se coloca "en escucha" en dicho puerto. A continuacion, prepara un mensaje con el socket. Es decir, nuestra direccion IP, nuestro puerto (3124), la direccion IP de destino (www.microsoft.com) y el puerto de web: 80. El servidor de microsoft, al recibir la peticion, lo que hace es enviar un mensaje, ahora a nuestro puerto 3124 con el contenido de su pagina (texto, imagenes, etc). Realmente es así de sencillo (se complica un poco más, porque la pagina, normalmente tiene enlaces a graficos y a otras subpaginas, y ppor tanto, en vez de un solo mensaje de vuelta, suele ser una combinacion, o una especie de conversacion 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 continen datos.... pero dependiendo del programa "receptor" en nuestra maquina, 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 patatan caliente ¿que 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 monton de maquinas, routeres, etc hasta llegar al destino. Estas maquinas, al no ser un mensaje para ellos, o lo pasan inmediatamente o lo tiran y 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 conversacion entre dos maquinas, deben ser capaces de intentar mantener un dialogo... es decir: deben llevar el control de los mensajes recibidos y solicitar una repeticion de un mensaje o parte de un mensaje si este se pierde. Compliquemoslo un poquito más: un mensaje que sale de una maquina con un tamaño determinado, puede ser necesario que otra maquina (un router por ejemplo), lo fragmente. Por lo cual, de un mensaje emitido, puede que se transforme en n mensajes recibidos. Debido a que los mensajes, además, pueden seguri rutas diferentes, a la hora de llegar a nuestra maquina, 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 garantia 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 garantia de entrega al programa de aplicacion, 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 aplicacion tal y como se recibe (si es que se recibe, además). Es el programa de aplicacion el responsable de gestionar dichos datos. Parece, segun lo anterior, que lo logico 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. Continuara.........