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.........
(
geocities.com/es/ensolva/Descargas) (
geocities.com/es/ensolva) (
geocities.com/es)