Está en la página 1de 51

BENEMÉRITA UNIVERSIDAD AUTÓNOMA DE PUEBLA

FACULTAD DE CIENCIAS DE LA COMPUTACIÓN

TOCHTLI: Una implementación de prueba de concepto de Port Knocking.

TESIS
QUE PARA OBTENER EL TÍTULO DE

LICENCIADO EN CIENCIAS DE LA COMPUTACIÓN

PRESENTA:

ALFREDO CAMPOS ENRÍQUEZ

DIRECTOR:

MC DAVID EDUARDO PINTO AVENDAÑO

Puebla, 2005
Agradecimientos
A mi asesor MC David Eduardo Pinto Avendaño, por todo el apoyo brindado durante el
desarrollo de este trabajo y por su valiosa contribución para su realización.

A mis jurados: MC Hilda Castillo Zacatelco y Dr Manuel Martín Ortiz, por sus contribuciones
efectivas a este trabajo y por su gran disposición.

Y a todos aquellos que lo consideren necesario.


Dedicatorias
A mi mamá.
Tabla de contenido
Página
Tabla de contenido I
Índice de figuras II
Índice de tablas III
Introducción IV
1. Marco teórico 1
1.1.Visión general de la red Internet 1
1.1.1 ¿Qué es Internet? 1
1.1.2 ARPANET 1
1.1.3 INTERNET 1
1.2 Modelo de referencia TCP/IP 2
1.2.1 Historia del TCP/IP 2
1.2.2 Consideraciones de diseño 2
1.2.3 Características del TCP/IP 2
1.2.4 Comparación con el modelo de referencia OSI 2
1.2.4.1 Capa de Internet 3
1.2.4.2 Capa de sesión 3
1.2.4.3 Comunicación orientada / no orientada a la conexión 3
1.2.5 Problemas del modelo TCP/IP 3
1.2.6 Aplicación del modelo de referencia 3
1.2.7 Capas del modelo de referencia TCP/IP 4
1.2.8 Protocolos del modelo de referencia 4
1.2.9 Protocolos de acceso a la red 4
1.2.9.1 Protocolo ARP 4
1.2.9.2 Protocolo RARP 4
1.2.9.3 El protocolo de Internet (IP) 4
1.2.9.3.1 Servicios básicos 4
1.2.9.3.2 Datagramas IP 5
1.2.9.3.3 Direcciones IP 6
1.2.9.3.4 Encaminamiento 9
1.2.9.3.5 Subredes 9
1.2.9.3.6 Resolución de direcciones 9
1.2.10 Los protocolos de transporte 10
1.2.10.1El protocolo UDP 11
1.2.10.2Cabecera TCP 11
1.2.10.3Protocolos de nivel de aplicación 11
1.2.10.3.1 Protocolos que usan UDP 11
1.2.10.3.2 Protocolos que usan TCP 11
1.3 Firewalls 13
1.3.1 ¿Qué es un firewall? 13
1.3.2 Implementación 15
1.4 IPTables 16
1.4.1 Características 16
1.4.2 Filtrado de paquetes 16
1.5 Scripts de Shell 17
1.5.1 Intérprete de comandos 17
1.5.2 Programas de procesamiento por lotes o scrips 17
1.5.3 BASH 18
2 Análisis y diseño 19
2.1 Planteamiento del problema 19
2.2 Análisis de requerimientos 19
2.2.1 Del lado del servidor 20
2.2.2 Del lado del cliente 20
2.3 Diseño de la aplicación 21
2.3.1 Diseño del servidor 21
2.3.2 Diseño del cliente 27
3 Pruebas e implementación 30
4 Conclusiones 42
5 Referencia 44

I
Índice de figuras
Página
1.1 Primitivas de servicio en la interfaz de IP 5
1.2 Formato de la cabecera IP 6
1.3 Dirección IP codificada 7
1.4 Direcciones IP especiales 8
1.5 Esquema de interconexión de diferentes clases de redes 8
1.6 Formato de la cabecera TCP 11
1.7 Topología clásica de un firewall 13
1.8 Esquema de una DMZ 14
1.9 Estructura de una DMZ con doble firewall 14
1.10Esquema de un ISP 15
2.1 Fase de lectura de argumentos 22
2.2 Esquema de la carga en memoria de las contraseñas de usuarios 23
2.3. Algoritmo de generación de secuencias válidas para usuarios 24
2.4. Fase de inicialización de TOCHTLI 24
2.5. Fase de monitoreo. 25
2.6. Fase de monitoreo detallado. 27
2.7. Generación de secuencia candidata 28
3.1. Generación de usuarios de tpasswd 31
3.2. Inicio de tochtlid, tiempo de generación de secuencias y enumeración. 32
3.3. Código de generación de secuencias válidas 32
3.4. Reglas del firewall después de ser cargadas en el núcleo 33
3.5. Ejecución el escáner de puertos nmap contra el Servidor. 34
3.6. Código de monitoreo al archivo de bitácoras. 34
3.7. Envío de secuencia candidata del usuario acampos. 35
3.8. Envío de la secuencia candidata del usuario jjimenez. 35
3.9. Código para la generación de las secuencias candidatas. 36
3.10. Código para enviar la secuencia candidata al Servidor. 36
3.11. Proceso de recepción de secuencias candidatas para el usuario acampos. 37
3.12. Acceso al sistema Servidor del usuario acampos. 38
3.13. Inserción de la regla para permitir el acceso desde 192.168.1.3 38
3.14. Salida del comando netstat. 39
3.15. Recepción y verificación de la secuencia candidata del usuario jjimenez. 39
3.16 Conexión exitosa para el usuario jjimenez. 40
3.17. Recepción y comparación exitosa de la secuencia del usuario jjimenez. 40

IV
Índice de tablas

Página
1.1. Opciones de calidad de servicio 5
1.2 Número de redes y hosts por clase 7
3.1 Características de las computadoras utilizadas en las pruebas 30
3.2 Direcciones IP de las computadoras utilizadas en las pruebas 30
3.3. Datos de los usuarios usados en las pruebas 30
3.4. Parámetros aceptados por tochtlid. 31

IV
Introducción

En el presente trabajo de tesis se presenta un sistema experimental a manera de prueba de

concepto de Port Knocking que hace las veces de mecanismo para el filtrado de accesos no

deseados en un ambiente TCP/IP. El método más común entre las organizaciones es la

instalación de un firewall, ya sea de hardware o software. Lamentablemente aún no poseen

medidas de protección contra el tráfico no deseado como los virus, los troyanos y los hackers.

Los firewalls realizan filtrado de datos a nivel de protocolos como TCP, UDP e ICMP (entre

otros), imposibilitando la autenticación a nivel de usuario, ya que esa es responsabilidad de la

aplicación en sí. Antes de que una conexión sea establecida, los puertos se abren mediante

una secuencia de knocks o llamados a los puertos. Dicho llamado es una serie de intentos de

conexión a puertos cerrados que un cliente remoto genera y envía a fin de manipular las reglas

del firewall del servidor para abrir uno o más puertos específicos.

El análisis realizado sobre el escenario anterior sugirió el diseño de tres aplicaciones: una para

servidor, otra para cliente y una más que sirve para generar usuarios para este sistema.

Finalmente se hace una revisión detallada de las pruebas realizadas, así como de los

resultados arrojados.

IV
1. Marco teórico
1.2.Visión general de la red Internet

1.1.1 ¿Qué es Internet?

Internet es una enorme red de comunicaciones de ámbito mundial que permite la interconexión
de sistemas informáticos, independientemente de su tipo y situación [1]. Está físicamente
compuesta por computadoras de diversos tipos, marca y sistema operativo y ruteadores que
están distribuidos por todo el mundo y unidos a través de enlaces de comunicaciones muy
diversos. Sobre éstos, aprovechando los servicios de comunicaciones de la red, se ejecutan
diversos tipos de aplicaciones, que permiten realizar intercambios de información.

La interconexión física se alcanza mediante una red heterogénea: redes de área local
(normalmente Ethernet), MAN, enlaces nacionales, enlaces internacionales y redes telefónicas.
Sobre esta red física es necesario que las computadoras tengan un software de
comunicaciones, que permitan el intercambio de información entre los diferentes puntos.

Para que los diferentes sistemas puedan entenderse es necesario tener un lenguaje común que
sea independiente del tipo de sistema operativo. Esta diversidad provoca numerosos problemas
de entendimiento, que se resuelven con el empleo de diferentes protocolos de comunicaciones.

1.1.2 ARPANET

Las redes de comunicaciones entre computadores y autopistas de la información han


evolucionado desde la red ARPANET hasta la actual Internet. A finales de los 60, los científicos
de la empresa RAND, quienes realizaban una investigación para el Departamento de Defensa
de los Estados Unidos, propusieron la tecnología de conmutación de paquetes. Esta tecnología
fue originalmente concebida para asegurar el funcionamiento de la red en la fase del ataque
nuclear. Así la agencia de proyectos de investigación avanzados del Departamento de Defensa
(DoD), construyó en 1969 Arpanet, la primera red de datos del mundo. El primer nodo se creó
en la Universidad de California (Los Ángeles). A pesar de que la red fue originalmente diseñada
para soportar computadores centrales de tiempo compartido, posteriormente los usuarios
comenzaron a disfrutar de otras aplicaciones como el correo electrónico, la transferencia de
archivos y la posibilidad de trabajar con archivos compartidos.

Esta red era de conmutación de paquetes y estaba basada en un conjunto de pequeños


dispositivos interconectados llamados procesadores de mensajes con interfaz (IMPs). Estos
IMP’s, los precursores de los modernos ruteadores, ofrecieron encaminamiento y
almacenamiento. El éxito de Arpanet fue el ser el catalizador para la investigación en la red
dando como resultado un protocolo de emergencia: el TCP/IP, el cual se estableció firmemente
en 1980. Arpanet completó su transición al TCP/IP en 1983, y en 1990 dejó de ser la espina
dorsal (backbone) de la red Internet.

1.1.3 INTERNET

En 1986, la National Science Foundation de Estados Unidos, comenzó el desarrollo de una


espina dorsal de alta velocidad llamada NSFnet, para conectar los centros de súper cómputo de
la nación.

A medida que fue creciendo la demanda del ancho de banda de esta espina dorsal, la NSF dio
origen a Merit en una muy productiva unión con MCI e IBM, para desarrollar una espina dorsal
de 1.5 Mbps. NSFnet, que enlazó los sitios de súper cómputo, comenzó a servir como el mayor
soporte entre redes, dando origen a la red Internet, que por supuesto reemplazó a la red
Arpanet.
Fuera de la Merit, surgió una nueva corporación sin ánimo de lucro para redes avanzadas y
servicios: la ANS. Esta corporación, fue inicialmente responsable del desarrollo de la espina
dorsal de redes y servicios de la NSF a 45 Mbps, la red TCP/IP mas veloz del mundo.

La red Internet, nació en los años 1990, creciendo desde mas o menos 500.000 hosts hasta
mas de 10 millones que había en 1996 [1]. Actualmente el número de nodos es mucho mayor

1
cada día. La World Wide Web, desarrollada por el CERN [1] (Laboratorio Europeo de Física
Nuclear), ha sido la mayor fuerza cercana al exponencial crecimiento de la red Internet.

1.2 Modelo de referencia TCP/IP

TCP/IP es el nombre que normalmente se da al conjunto de protocolos que se utilizan para la


comunicación a través de Internet. Fue el primer conjunto de protocolos desarrollados para ser
usados en Internet. Estos protocolos se definen en base a RFCs (Request For Comment) que
se encuentran disponibles públicamente en la misma Internet [2].

1.2.1 Historia del TCP/IP

Los trabajos en TCP/IP empezaron en la década de los 70 [2], aproximadamente al mismo


tiempo que se empezaban a desarrollar las redes de área local. El ejercito americano gracias al
proyecto ARPA (Advanced Research Projects Agency) invirtió muchos recursos en investigar el
TCP/IP y en la interconexión de redes. Fueron unas de las primeras organizaciones que tuvo
varias redes y por lo tanto de las primeras que se encontraron con la necesidad de tener
servicios universales. La capacidad de conectar entre sí múltiples redes de manera
transparente fue uno de los primeros objetivos de diseño.

1.2.2 Consideraciones de diseño

Debido a la preocupación del Departamento de Defensa por que alguno de sus costosos nodos
de la red pudiera ser objeto de un atentado en cualquier momento, otro de los objetivos
principales fue que la red fuera capaz de seguir funcionando sin que las comunicaciones
existentes se interrumpieran si algunos de los dispositivos de hardware fallaba. La idea era que
las comunicaciones permanecieran intactas mientras las máquinas origen y destino estuvieran
funcionando, aunque algunas de las máquinas o de las líneas de transmisión en el trayecto
dejara de funcionar de forma repentina. Por otra parte, debido a que se estaban pensando en
aplicaciones que tuvieran diferentes requerimientos, se necesitaba que la arquitectura fuera
flexible.

1.2.3 Características del TCP/IP

Las características principales del protocolo TCP/IP son:

- Tiene un sistema para localizar un sistema determinado dentro de Internet,


independientemente de donde esté ubicado físicamente y de los enlaces necesarios
para alcanzarlo.
- Resuelve de forma automática los problemas que se puedan dar durante el intercambio
de información: fallos en los enlaces, errores, pérdidas o duplicación de datos
información.
- Resuelve las posibles incompatibilidades en la comunicación entre computadoras

1.2.4 Comparación con el modelo de referencia OSI

A continuación se comparan ambos modelos de referencia, no los protocolos correspondientes


en cada uno de los modelos. Una de las contribuciones más importantes del modelo OSI es la
distinción que hace entre servicios, interfaces y protocolos. Originalmente el modelo TCP/IP no
distinguía claramente entre estos tres conceptos, aunque posteriormente se ha reajustado para
hacerlo mas parecido a OSI. En el modelo OSI se ocultan mejor los protocolos que en el
modelo TCP/IP y se pueden reemplazar con relativa facilidad al cambiar de tecnología. El
modelo OSI se definió antes que los protocolos, mientras que en TCP/IP se definieron primero
los protocolos y el modelo fue en realidad una descripción de los protocolos existentes, por lo
que lo protocolos se ajustaban al modelo. El único problema es que el modelo no se ajustaba a
ninguna pila de protocolos por lo que no fue de mucha utilidad para describir redes que no
fueran del tipo TCP/IP.

Una diferencia obvia entre los dos modelos es el número de capas. El modelo OSI tiene 7
capas y el TCP/IP tiene 5.

2
1.2.4.1 Capa de Internet

Aunque algunas capas del modelo de referencia TCP/IP se corresponden con capas del
modelo de referencia OSI descrito en un tema anterior, el esquema de capas OSI no tiene
ninguna capa que corresponda con la capa internet del modelo TCP/IP. Esto se debe a que el
modelo OSI se definió antes de que se inventara el internetworking, por lo que este modelo no
contiene ninguna capa para los protocolos internet.

1.2.4.2 Capa de Sesión

Además, el modelo OSI dedica una capa completa para los protocolos de sesión, que han
perdido mucha importancia a medida que las computadoras han cambiado desde sistemas de
tiempo compartido a estaciones de trabajo. Por este motivo, los investigadores que diseñaron
TCP/IP inventaron un nuevo modelo de capas.

1.2.4.3 Comunicación orientada y no orientada a la conexión

Otra diferencia se encuentra en el área de comunicación no orientada a la conexión frente a la


orientada a la conexión. El modelo OSI considera ambos tipos, pero en la capa de transporte
donde es más importante (porque el servicio de transporte es visible al usuario) lo hace
únicamente con la comunicación orientada a la conexión. El modelo TCP/IP en la capa de red
sólo tiene el modo sin conexión pero considera ambos modos en la capa de transporte,
ofreciendo una alternativa a los usuarios. Esta elección es importante sobre todo para los
protocolos simples de petición y respuesta.

1.2.5 Problemas del modelo TCP/IP

El modelo TCP/IP tiene algunos problemas que se mencionan a continuación:

- Como ya se ha comentado anteriormente, este modelo no distingue con claridad los


conceptos de servicio, interfaz y protocolo. En el modelo TCP/IP no se hace una
diferenciación entre las especificaciones y la implementación, y por lo tanto no es un
buen ejemplo para construir redes nuevas.
- Otra limitación del modelo es que no es general y no se puede utilizar para describir
otra pila de protocolos.
- La capa de acceso a la red no es una capa en el sentido estricto sino que es una
interfaz entre la red y la capa de enlace de datos.
- En este modelo, no se distingue entre la capa física (que tiene que ver con las
características de transmisión en el alambre de cobre, la fibra óptica y la comunicación
inalámbrica) y la capa de enlace de datos (encargada de delimitar el inicio y el fin de los
marcos y transferirlos de un lado a otro con el grado deseado de confiabilidad) cuando
en realidad son completamente diferentes y por lo tanto ambas capas deberían
aparecer separadas en un modelo bien diseñado.
- Aunque los protocolos IP y TCP se diseñaron cuidadosamente, las implementaciones
de otros grupos de investigación se distribuían gratuitamente, como la de BSD o POSIX
que se utilizan mucho y por lo tanto son difíciles reemplazar aunque tuvieran problemas
de diseño.

1.2.6Aplicación del modelo de referencia

TCP/IP tiene una implantación mayor aplicación que el modelo OSI (el cual nunca se ha
desarrollado totalmente). Por las siguientes razones:

- TCP/IP se desarrolló antes que el protocolo OSI, por lo que las empresas implantaron
TCP/IP mientras esperaban el protocolo OSI.
- La demanda de productos por parte del Departamento de Defensa de EEUU creó un
mercado real muy importante (hay que tener en cuenta que es el primer consumidor de
software del mundo).
- Internet utiliza TCP/IP. Algunos de los protocolos TCP/IP se han usado como la base
para los estándares ISO. Además, como todas las especificaciones asociadas a los

3
protocolos TCP/IP son de dominio público han sido usados extensivamente por
autoridades comerciales y públicos para crear entornos de redes abiertos.

1.2.7 Capas del modelo de referencia TCP/IP

En este apartado se define brevemente este nuevo modelo para posteriormente explicar con
detalle los protocolos de cada una de las capas. Hay que tener en cuenta que no hay un modelo
oficial de referencia TCP/IP.

Basándose en los protocolos que se han desarrollado, todas las tareas involucradas en la
comunicación se pueden organizar en cinco capas relativamente independientes. Un modelo de
capas es una forma común de dividir un conjunto de protocolos. Ethernet se corresponde con el
nivel 1 y parte del nivel 2, siendo independiente de TCP/IP, que es un conjunto de protocolos
que también funciona sobre otros tipos de redes.

Las capas físicas y de acceso a la red proporcionan la interacción entre el sistema final y la red,
mientras que las capas de aplicación y transporte albergan los protocolos denominados punto a
punto, ya que facilitan la interacción entre los dos sistemas finales. La capa internet tiene algo
de las dos aproximaciones anteriores. En esta capa, los sistemas origen y destino proporcionan
a la red la información necesaria para realizar el encaminamiento, pero a la vez, deben
proporcionar algunas funciones adicionales de intercambio entre los dos sistemas finales.
El modelo de referencia TCP/IP consta principalmente de tres protocolos: IP, UDP y TCP. El
protocolo básico es IP y permite enviar mensajes entre dos sistemas. UDP y TCP utilizan los
mensajes del nivel IP para construir un diálogo más complejo entre las computadoras.
En el modelo TCP/IP el uso de todas las capas no es obligatorio, por ejemplo, hay algunos
protocolos de la capa de aplicación que operan directamente sobre IP.

1.2.8 Protocolos del modelo de referencia

Una vez visto como se estructura esta pila de protocolos, se describirán brevemente los más
importantes de cada una de las capas empezando por los niveles inferiores.

1.2.9 Protocolos de acceso a la red

1.2.9.1 Protocolo ARP

El protocolo ARP (Address Resolution Protocol) definido en el RFC 826 [3], indica que las redes
físicas tienen sus propios esquemas de direccionamiento y hay tantos esquemas de
direccionamiento como redes físicas. Se conoce la dirección Ethernet, sin embargo para enviar
el paquete se debe conocer la dirección IP, pues la red física no entiende las direcciones IP.
El protocolo ARP realiza dos funciones: la primera es dada una dirección IP obtener una
dirección física cuando se envía un paquete y la segunda función consiste en contestar
peticiones realizadas por otras máquinas.

1.2.9.2 Protocolo RARP

Cada máquina, además de su dirección física que está en la tarjeta de red, debe tener
guardada en algún dispositivo la dirección IP que le corresponde. ¿Pero cómo una máquina que
no disponga de disco duro puede determinar su dirección IP?. El problema es crítico para
aquellas estaciones de trabajo que almacenan todos sus archivos en un servidor remoto ya que
ellas deben utilizar los protocolos de transferencia TCP/IP para obtener su imagen de arranque
inicial.

1.2.9.3 El protocolo de Internet IP

1.2.9.3.1 Servicios básicos

En el nivel IP hay dos primitivas de servicio en la interfaz con la capa superior como se muestra
en la figura 1.1

4
Send (o envío) se Deliver (o entrega) la
utiliza para solicitar la utiliza IP para avisar a
transmisión de una un usuario la llegada de
unidad de datos. una unidad de datos.

Figura 1.1. Primitivas de servicio en la interfaz de IP.

En la primitiva Deliver, los parámetros identificador, indicador de no fragmentación y tiempo de


vida no se encuentran presentes por proporcionar instrucciones IP que no deben ser utilizadas
por el receptor. El emisor puede incluir el campo tipo de servicio para solicitar una calidad de
servicio particular. La tabla 1.1 muestra las opciones que hay de calidad de servicio

Una medida de la importancia relativa del datagrama. Se utilizan ocho


PRECEDENCIA niveles de precedencia. IP tratará de proporcionar un tratamiento
preferencial a los datagramas con precedencias superiores.
Se puede especificar uno de dos niveles: normal o alta. Un valor alto indica
SEGURIDAD una petición para que se intente minimizar la probabilidad de que este
datagrama se pierda o resulte dañado.
Se puede especificar uno de dos niveles: normal o bajo. Un valor bajo indica
RETARDO
una petición para minimizar el retardo que experimentará este datagrama.
Se puede especificar uno de dos niveles: normal o alto. Un valor alto indica
RENDIMIENTO
una petición para maximizar el rendimiento para este datagrama.
Tabla 1.1. Opciones de calidad de servicio.

Los parámetros de opciones permiten ampliaciones futuras y la inclusión de parámetros que


normalmente no se utilizan. Actualmente están definidas las siguientes opciones:

– Seguridad
– Encaminamiento en la fuente
– Registro de la ruta
– Identificación de secuencia
– Marcas de tiempo.

1.2.9.3.2 Datagramas IP

El formato de los datagramas IP consiste en una parte de cabecera y en una parte de datos
cuyo tamaño es variable.

1.2.9.3.2.1 Cabecera

En la cabecera hay una parte fija de 20 bytes y una parte opcional de longitud variable. En la
figura 1.2 se puede ver el formato de la cabecera IP.

5
Figura 1.2. Formato de la cabecera IP

1.2.9.3.3 Direcciones IP

Cada computadora y cada dispositivo de encaminamiento tendrán una dirección única cuya
longitud será de 32 bits, que será utilizada en los campos dirección origen y dirección destino de
la cabecera. Esta dirección consta de un identificador de red y de un identificador de
computador. La dirección, como puede verse en la figura 1.3 , está codificada para permitir una
asignación variable de los bits utilizados al especificar la red y el computador. Este formato de
direcciones permite mezclar las tres clases de direcciones en el mismo conjunto de redes. La
dirección IP más pequeña es la 0.0.0.0 y la mayor es 255.255.255.255.

Existen tres clases de redes que se pueden clasificar teniendo en cuenta la longitud del campo
de red y del campo de la computadora. La clase a la que pertenece una dirección puede ser
determinada por la posición del primer 0 en los cuatro primeros bits. Las direcciones están
codificadas para permitir una asignación variable de bits para especificar la red y la
computadora.

– Clase A: Pocas redes, cada una con muchos clientes. 7 y 24 bits (+1). Por ejemplo
ARPANET.
– Clase B: Un número medio de redes, cada una con un número medio de clientes. 14 y 16
bits (+2)
– Clase C: Muchas redes, cada una con pocos clientes. 21 y 8 bits (+3). Por ejemplo un red de
área local.
– Clase D: Permite hacer multitransmisión (o multicasting) en la cual el datagrama se dirige a
múltiples clientes. Es posible enviar un paquete IP a un grupo de máquinas que por ejemplo
pueden estar cooperando de alguna manera mediante la utilización de una dirección de
grupo.
– Clase E: Reservado para el futuro.

6
Figura 1.3. Dirección IP codificada

La tabla 1.2 muestra el número de redes y de computadoras por red en cada una de las tres
clases primarias de direcciones IP:

CLASE BITS EN EL MAXIMO BITS EN EL MAXIMO Nº DE


PREFIJO Nº DE REDES SUFIJO CLIENTES POR RED
A 7 128 24 16777216
B 14 16384 16 65536
C 21 2097152 8 256
Tabla 1.2. Número de redes y hosts por clase.

Normalmente las direcciones se suelen escribir en notación decimal con puntos. Por ejemplo, la
dirección 82CE7C0D (1000 0010 1100 1110 0111 1100 0000 1101 que es de clase B) se
escribe como 130.206.124.13.

Observando la tabla 1.2 puede verse que no todas las direcciones han sido asignadas a una
clase en concreto. Algunas de estas direcciones se utilizan como direcciones especiales (ver
figura 1.4):

– Esta máquina: La dirección 0.0.0.0 significa esta red o esta computadora y únicamente es
usada por las computadoras cuando son arrancadas, sin que se vuelva a utilizar
posteriormente. De esta forma las máquinas se pueden referir a su propia red sin saber su
número, pero tiene que saber su clase para saber cuantos ceros debe incluir.
– Una computadora de esta red: Poniendo el campo red todo a ceros (es necesario saber la
clase de la red para decidir cuantos ceros se deben poner).
– Difusión de red local o limitada: La dirección 255.255.255.255 (todos 1s) se usa como
dirección para indicar todas las computadoras de la red indicada y es utilizada para hacer
difusión.
– Difusión de una red distante o dirigida: También se puede hacer difusión a una red distante
poniendo la dirección de la red y rellenando el campo de la dirección del cliente con 1’s.
– Retrociclo: Las direcciones 127.xx.yy.zz se reservan para pruebas de realimentación. Los
paquetes que tienen esta dirección no son enviados por la red sino que son procesados
localmente y se tratan como si fueran paquetes de entrada. Esto permite que los paquetes
se envíen a la red local sin que el transmisor conozca su número. Esta característica
también se usa para la detección de fallos en el software de red.

Figura 1.4. Direcciones IP especiales

Una máquina puede estar conectada a varias redes y tener una dirección IP diferente en cada
red. En este caso recibe el nombre de “multihomed”. Esto se utiliza para aumentar la seguridad
pues si una red falla el sistema aún esta conectado a Internet utilizando la otra red. Por otra
parte, también es usado para aumentar el rendimiento de la red pues permite enviar
directamente el tráfico a una red en concreto sin tener que pasar por los dispositivos de
encaminamiento.

7
En la figura 1.5 se puede ver las direcciones asignadas a diferentes computadoras y
dispositivos de encaminamiento que están conectados en tres redes diferentes: a una Token
Ring de clase C, a una Ethernet de clase B y a una red de clase A, en concreto Arpanet. Para la
interconexión de las tres redes se estan utilizando 2 dispositivos de encaminamiento (routers).

Figura 1.5. Esquema de interconexión de diferentes clases de redes.

El que la dirección de la red esté guardada en la dirección Internet tiene algunos


inconvenientes:

– Si la dirección IP identifica la red a la que se conecta el sistema, no al cliente que está


conectado, no es posible asignarle una dirección IP permanente. Por lo tanto, si se mueve
físicamente una computadora de una red a otra su dirección IP debe cambiar.
– Como el número de máquinas asignadas a la clase C (255) puede resultar insuficiente en
muchos casos y que la transición a la clase B no es fácil debido a que muchos programas no
permiten que una red física tenga múltiples direcciones, no se pueden introducir nuevas
direcciones poco a poco y es necesario reconfigurar toda la red para la nueva clase.
– Como existe la facilidad de que una máquina pueda estar conectada a dos redes y por lo
tanto tenga dos direcciones diferentes, y que el encaminamiento se hace teniendo en cuenta
la dirección IP, el comportamiento de los paquetes puede ser totalmente diferente
dependiendo de la dirección que se esté utilizando. Esto puede resultar sorprendente para
los usuarios.
– En algunos casos, el conocer una dirección IP puede resultar insuficiente para alcanzar la
máquina que utiliza esta dirección

1.2.9.3.4 Encaminamiento

Cuando un paquete llega a un dispositivo de encaminamiento se debe determinar cual es la


dirección del siguiente dispositivo de encaminamiento teniendo en cuenta la dirección IP destino
que hay almacenada en el campo correspondiente del paquete y de la información que hay
almacenada en las tablas de encaminamiento. Hay que tener en cuenta que es necesario
realizar una conversión entre la dirección IP y la dirección MAC (cuando el enlace entre los dos
dispositivos de encaminamiento sea una LAN) que se efectúa de manera automática mediante
el protocolo ARP.

Esta tabla puede ser estática o dinámica. En el primer caso puede contener rutas alternativas
que serán utilizadas cuando algún dispositivo de encaminamiento no esté disponible. Las tablas
dinámicas son más flexibles cuando aparecen errores o congestión en la red. Estas tablas
también pueden proporcionar servicios de seguridad y de prioridad, por ejemplo, para
asegurarse que a ciertos datos no se les permita pasar por determinadas redes.

8
Otra técnica de encaminamiento es el encaminamiento en la fuente. En este caso, como ya se
comentó, el sistema origen incluye en la cabecera del paquete la dirección de los dispositivos
de encaminamiento que debe utilizar el paquete.

1.2.9.3.5 Subredes

El que todos los clientes de una red deban tener el mismo número de red puede causar
problemas. A medida que aumenta la utilización de las redes locales puede ser interesante
considerar que un conjunto de computadoras forman una red independientes, pero que
externamente se vea a todas como una sola red. La manera de hacerlo consiste en subdividir el
campo correspondiente a la identificación de la máquina en dos subcampos, uno para la subred
(por ejemplo de 6 bits) y otro para los sistemas (que deberá tener 10 bits).

1.2.9.3.6 Resolución de direcciones

Dos computadoras de una red física sólo pueden comunicarse si cada uno de ellas conoce la
dirección física de la otra. Cuando se envía un paquete IP entre estas dos máquinas sólo se
indica la dirección IP. Por lo tanto es necesario tener un mecanismo que proporcione la
correspondencia entre la dirección IP y la dirección física. El problema de traducir las
direcciones de alto nivel en direcciones físicas recibe el nombre de “address resolution”.

Existen tres mecanismos para hacerlo:

El primero utiliza una tabla en cada máquina para almacenar, para cada dirección IP, la
correspondiente dirección física. Cada entrada de la tabla contiene una dirección IP y una
dirección física. Como existe una tabla para cada red física, todas las direcciones IP tienen el
mismo prefijo. La principal ventaja de este mecanismo es su generalidad.

Cuando se quiere obtener una dirección, si el número de entradas de la tabla es pequeño la


búsqueda se puede hacer secuencialmente, si es gran se pueden utilizar técnicas de hashing o
de indexación directa. Esta última sólo es posible si el rango de direcciones es compacto pues
en otro caso se desaprovecharían muchas posiciones de memoria.

El segundo realiza la traducción mediante una función matemática. Aunque muchas tecnologías
utilizan direcciones físicas estáticas, algunas usan direccionamiento configurable, es decir, el
administrador de la red elige tanto la dirección física como la dirección IP. En este caso, los
valores pueden ser elegidos para que la traslación sea trivial.

El tercero es el más interesante pues usa una computación distribuida en la que los dos
sistemas intercambian mensajes dinámicamente. Existen dos posibles diseños:

En el primero hay uno o más servidores que se encargan de enviar las respuestas. La principal
ventaja de este diseño es que es centralizado y por lo tanto fácil de configurar, gestionar y
controlar.

En el segundo diseño, se hace un broadcast de la petición y todas las computadoras participan


en la resolución de la dirección, en concreto responde el que tiene la dirección pedida. La
principal ventaja de este diseño es que el cálculo es distribuido. Una de las ventajas de este
método sobre tener unos archivos de configuración es su sencillez. El propio protocolo se
encarga de construir las tablas en lugar de tener que hacerlo el administrador del sistema.

1.2.10 Los protocolos de transporte

Los protocolos de transporte tienen la función de actuar de interfaz entre los niveles orientados
a la aplicación y los niveles orientados a la red dentro de la jerarquía de protocolos TCP/IP. Se
encargan de ocultar a los niveles altos del sistema el tipo de tecnología a la que se estén
conectando las computadoras.

En la jerarquía de TCP/IP se definen dos protocolos de transporte: el UDP y el TCP. El UDP es

9
un protocolo no orientado a la conexión mientras que el TCP es orientado a la conexión.

Se definen dos direcciones para relacionar el nivel de transporte con los niveles superior e
inferior: La dirección IP y el puerto.

La dirección IP es la dirección que identifica un dispositivo dentro de una red.


El puerto es un número de 16 bits que se coloca en cada paquete y sirve para identificar la
aplicación que requiere la comunicación. La utilidad de los puertos es que permite multiplexar
aplicaciones sobre protocolos del nivel de transporte. Es decir, un mismo protocolo de
transporte puede llevar información de diferentes aplicaciones y éstas son identificadas por el
puerto.
Para establecer una comunicación entre dos máquinas, se ha de utilizar uno de los protocolos
de transporte (TCP o UDP) y es necesario conocer tanto el puerto que identifica la aplicación
destino como la dirección IP que identifica el terminal o el servidor dentro del conjunto de redes.
Los datos que se envían durante la comunicación son empaquetados por los protocolos del
nivel de transporte. Los bytes que se transmiten en el TCP reciben el nombre de segmento TCP
y los que se transmiten en el UDP el de datagrama UDP.
Para establecer una comunicación se utiliza el modelo cliente/servidor. En este caso, el cliente
inicia la comunicación y para hacerlo necesita conocer la dirección IP asignada a la
computadora, al servidor y al puerto de la aplicación que identifica la aplicación que se quiere
utilizar.
El cliente conoce su dirección IP (dirección origen), la dirección del servidor (dirección destino) y
el puerto que identifica su aplicación cliente. Para que pueda saber el puerto destino que
identifica la aplicación deseada, se utilizan los llamados puertos conocidos, que consisten en un
número de puerto reservado para identificar una aplicación determinada.

El servidor responderá a las peticiones de cualquier cliente. Como el cliente envía en el


datagrama UDP y en el segmento TCP tanto el puerto origen como el destino, el servidor
conoce el puerto origen una vez que ha recibido una petición.

1.2.10.1 El protocolo UDP

Este protocolo es no orientado a la conexión, y por lo tanto no proporciona ningún tipo de


control de errores ni de flujo, aunque sí utiliza mecanismos de detección de errores. Cuando se
detecta un error en un datagrama en lugar de entregarlo a la aplicación se descarta.

Como el protocolo es no orientado a la conexión cada datagrama UDP existe


independientemente del resto de datagramas UDP.

El protocolo UDP es muy sencillo y tiene utilidad para las aplicaciones que requieren pocos
retardos o para ser utilizado en sistemas sencillos que no pueden implementar el protocolo
TCP.

Las características del protocolo UDP son las siguientes:

- No garantiza la fiabilidad. No es posible asegurar que cada datagrama UDP transmitido


llegue a su destino. Es un protocolo del tipo best-effort porque hace lo que puede para
transmitir los datagramas hacia la aplicación, pero no puede garantizar que la
aplicación los reciban.
- No preserva la secuencia de la información que proporciona la aplicación. La
información se puede recibir desordenada (como ocurría en IP) y la aplicación debe
estar preparada por si se pierden datagramas, llegan con retardo o llegan
desordenados.

1.2.10.2 Cabecera TCP

La unidad de datos de este protocolo recibe el nombre de segmento TCP. Como la cabecera
debe implementar todos los mecanismos del protocolo su tamaño es bastante grande, como
mínimo 20 bytes.

En la figura 1.6 se puede ver el formato de la cabecera TCP.

10
Figura 1.6. Formato de la cabecera TCP

1.2.10.3. Protocolos del Nivel de Aplicación

1.2.10.3.1 Protocolos que utilizan UDP

- NFS (Network File System) [4]: Utiliza el protocolo UDP y está basado en el Remote
Procedure Call de SUN. El núcleo del sistema operativo de la máquina cliente es
modificado con un nuevo tipo de sistema de archivo NFS, de manera que cuando un
programa intenta abrir, cerrar, leer o escribir en un archivo remoto, el código NFS es
llamado en lugar del código “normal” para acceder a los manejadores de los discos
físicos. El código del sistema de archivos NFS usa el protocolo RPC de SUN para
comunicar con el código servidor NFS que se ejecuta en la máquina remota, leyendo o
escribiendo bloques de archivos en él.
- SNMP (Simple network management protocol) [5]: SNMP es un protocolo
cliente/servidor que normalmente es usado para configurar y monitorear remotamente
los equipos de la red Internet. Este protocolo se basa en el protocolo UDP. En
terminología SNMP es descrito como un protocolo manager/agent.
- DNS (Domain Name Server, usualmente en el puerto 53) [6]: El servicio de nombres de
dominio (DNS) se utiliza para relacionar los nombres de dominio de los nodos con sus
direcciones IP. Tal como se ha comentado al explicar el protocolo IP, la asignación de
direcciones sigue una estructura jerárquica. Para hacer mas sencillo el acceso a los
sistemas, cada sistema puede tener asignados uno o varios nombres de dominio DNS,
que son identificadores descriptivos que permiten hacer referencia al equipo y equivalen
a su dirección IP. Los nombres DNS también se asignan de forma jerárquica,
añadiendo a la derecha del nombre del sistema una serie de identificadores que
corresponden con la organización o empresa a la que pertenece el sistema. Cuando en
un comando se introduce un nombre de máquina, el sistema siempre convierte ese
nombre en una dirección IP antes de establecer la conexión. Desde la máquina que
necesita saber la dirección IP, se envía un paquete UDP a un servidor DNS, que busca
el nombre y devuelve la dirección IP. Con la dirección IP, el programa puede entonces
establecer una conexión TCP con el destino, o enviarle paquetes UDP.

1.2.10.3.2 Protocolos que usan TCP

- SMTP (Simple Mail Transfer Protocol, usualmente en el puerto 25) [7] y [8]: Este es el
protocolo dedicado a la transmisión de mensajes electrónicos sobre una conexión TCP.
El protocolo especifica el formato de los mensajes definiendo la estructura de la
información sobre el remitente, el destinatario, datos adicionales y naturalmente el
cuerpo de los mensajes. Este protocolo no especifica como los mensajes deben ser
editados. Es necesario tener un editor local o un aplicación nativa de correo electrónico.
Una vez el mensaje es creado, el SMTP lo acepta y usa el protocolo TCP para enviarlo
a un módulo SMTP de otra máquina. El TCP es el encargado de intercomunicar
módulos SMTP de las máquinas implicadas.
- Telnet (Remote login, usualmente en el puerto 23) [9] y [10]: Este protocolo permite a
los usuarios conectarse a máquinas remotas y utilizarlas desde el sistema local,
mediante la emulación de terminal sobre una conexión TCP. Interconecta el cliente
local de una máquina con el servidor con el que se comunica. Los caracteres que se
teclean en un cliente local son enviados por la red y procesados en el sistema remoto,

11
utilizando la información que contiene. El resultado de su ejecución se muestra en la
pantalla local. Este protocolo fue uno de los primeros que se definió y ha sido diseñado
para trabajar con terminales de modo texto. Se implementa en dos módulos. El módulo
cliente relaciona el módulo de entrada y salida del terminal para que pueda
comunicarse con el terminal local. Convierte las características de los terminales reales
con los standards de las redes y viceversa. El módulo servidor interactua con una
aplicación, de manera que los terminales remotos sean vistos por la aplicación como
terminal local.
- FTP (File Transfer Protocol, usualmente en el puerto 21) [11]: Permite la transferencia
de archivos de texto o binarios desde un servidor a un cliente sobre una conexión TCP.
FTP implementa un sistema estricto de restricciones basadas en propiedades y
permisos sobre los archivos. Hay un control de acceso de los usuarios, y cuando un
usuario quiere realizar la transferencia de un archivo, el FTP establece una conexión
TCP para el intercambio de mensajes de control. De esta manera se puede enviar el
nombre de usuario, el password, los nombres de los archivos y las acciones que se
quieren realizar. Una vez se ha aceptado la transferencia del archivo, una segunda
conexión TCP se establece para la transferencia de datos. El archivo se transfiere
sobre la conexión de datos, sin la utilización de ninguna cabecera o información de
control en la capa de aplicación. Cuando se completa la transferencia, la conexión de
control es usada para transmitir la señalización de que la transferencia se ha
completado y para aceptar nuevos comandos de transferencia.
- HTTP (Hyper Text Transfer Protocol, usualmente en el puerto 80): Este es un sencillo
protocolo cliente-servidor que articula los intercambios de información entre los clientes
web y los servidores HTTP. Este protocolo fue propuesto por Tim Berners-Lee [12],
atendiendo a las necesidades de un sistema global de distribución de información
multimedia como el World Wide Web. Se utiliza para transferir páginas de hipertexto.
Está soportado sobre los servicios de conexión TCP/IP. Un proceso servidor espera las
solicitudes de conexión de los clientes Web, y una vez que se establece la conexión, el
protocolo TCP se encarga de mantener la comunicación y garantizar un intercambio de
datos libre de errores [13].
- SSH (Secure SHell, usualmente en el puerto 22): Es el nombre de un protocolo y del
programa que lo implementa. Este protocolo sirve para acceder a máquinas remotas a
través de una red, de forma similar a como se hace con telnet. La diferencia principal es
que SSH usa técnicas de cifrado que hacen que la información que viaja por el medio
de comunicación vaya de manera no legible y ninguna persona pueda descubrir el
usuario y contraseña de la conexión ni lo que se escribe durante toda la sesión; aunque
es posible atacar este tipo de sistemas por medio de ataques de REPLAY y manipular
así la información entre destinos. Al igual que telnet, sólo permite conexiones tipo
terminal de texto, aunque puede redirigir el tráfico para poder ejecutar programas
gráficos.
Además de la conexión a otras máquinas, SSH permite copiar datos de forma segura,
gestionar claves RSA para no escribir claves al conectar a las máquinas y pasar los
datos de cualquier otra aplicación por un canal seguro de SSH (esto sólo si se tiene
acceso como administrador a ambas máquinas). La primera versión del protocolo y el
programa eran libres y los creó un sueco llamado Tatu Ylönen, pero su licencia fue
cambiando y terminó apareciendo la compañía `SSH Communications Security', que lo
ofrecía gratuitamente para uso doméstico y académico, pero exigía el pago a otras
empresas. A principios de 1999 se empezó a escribir una versión que se convertiría en
la implementación libre por excelencia, la de OpenBSD, llamada OpenSSH. [14]

Hasta este punto se han comentado los aspectos básicos de la comunicación en Internet. Un
aspecto avanzado sobre este tema es el de la seguridad de las redes. Si bien existen varias
propuestas al respecto, una herramienta que se ha popularizado ampliamente es el firewall que
se comentará a continuación.

1.3 Firewalls

1.3.1. ¿Qué es un firewall?

Un firewall es un dispositivo que filtra el tráfico entre redes, como mínimo dos [15]. El firewall
puede ser un dispositivo físico o un software sobre un sistema operativo. En general se debe
ver como una caja con dos o más interfaces de red en la que se establecen una reglas de

12
filtrado con las que se decide si una conexión determinada puede establecerse o no. Incluso
puede ir más allá y realizar modificaciones sobre las comunicaciones, como el NAT.

Esa sería la definición genérica, hoy en día un firewall es un hardware específico con un
sistema operativo que filtra el y decide si un paquete pasa, se modifica, se convierte o se
descarta.

Figura 1.7. Topología clásica de un firewall

En la figura 1.7 se muestra la tipología clásica de un firewall en donde se esquematiza su uso


para proteger una red local conectada a internet a través de un dispositivo encaminador. El
firewall debe colocarse entre el ruteador (con un único cable) y la red local (conectado al switch
o al hub de la LAN).

Dependiendo de las necesidades de cada red, puede ponerse uno o más firewalls para
establecer distintos perímetros de seguridad en torno a un sistema. Es frecuente también que
se necesite exponer algún servidor a Internet (como es el caso de un servidor web, un servidor
de correo, etc.), y en esos casos obviamente en principio se debe aceptar cualquier conexión a
ellos. Lo que se recomienda en esa situación es situar ese servidor en un lugar aparte de la red,
el que se denomina DMZ o zona desmilitarizada. El firewall tiene entonces tres entradas (ver
figura 1.8):

Figura 1.8. Esquema de una DMZ.

En la zona desmilitarizada se pueden poner tantos servidores como se necesiten. Con esta
arquitectura, se permite que el servidor sea accesible desde Internet de tal forma que si es
atacado y se gana acceso a él, la red local sigue protegida por el firewall. Esta estructura de
DMZ puede hacerse también con un doble firewall (aunque como se ve se puede usar un único
dispositivo con al menos tres interfaces de red). Sería un esquema como el que se muestra en
la figura 1.9.

13
Figura 1.9. Estructura de una DMZ con doble firewall.

Los firewalls se pueden usar en cualquier red. Es habitual tenerlos como protección de internet
en las empresas, aunque ahí también suelen tener una doble función: controlar los accesos
externos hacia dentro y también los internos hacia el exterior; esto último se hace con el firewall
o frecuentemente con un proxy (que también utilizan reglas, aunque de más alto nivel).
También, en empresas de hosting con muchos servidores alojados lo normal es encontrarnos
uno o más firewalls ya sea filtrando toda la instalación o parte de ella como se muestra en la
figura 1.10:

Figura 1.10. Esquema de un ISP.

Sea el tipo de firewall que sea, generalmente no tendrá mas que un conjunto de reglas en las
que se examina el origen y destino de los paquetes del protocolo TCP/IP. En cuanto a
protocolos es probable que sean capaces de filtrar muchos tipos de ellos, no solo los TCP,
también los UDP, los ICMP y otros protocolos vinculados a VPNs. Este podría ser (en pseudo-
lenguaje) un el conjunto de reglas de un firewall de la figura 1.7:

Politica por defecto ACEPTAR.


Todo lo que venga de la red local al firewall ACEPTAR
Todo lo que venga de la ip de mi casa al puerto tcp 22 ACEPTAR
Todo lo que venga de la ip de casa del jefe al puerto tcp 1723 ACEPTAR
Todo lo que venga de hora.rediris.es al puerto udo 123 ACEPTAR
Todo lo que venga de la red local y vaya al exterior ENMASCARAR
Todo lo que venga del exterior al puerto tcp 1 al 1024 DENEGAR

14
Todo lo que venga del exterior al puerto tcp 3389 DENEGAR
Todo lo que venga del exterior al puerto udp 1 al 1024 DENEGAR

En definitiva lo que se hace es:

- Habilitar el acceso a puertos de administración a determinadas IPs privilegiadas.


- Enmascarar el trafico de la red local hacia el exterior (NAT, una petición de una computadora
de la LAN sale al exterior con la IP pública), para poder salir a Internet
- Negar el acceso desde el exterior a puertos de administración y a todo lo que este entre los
puertos 1 y 1024.

1.3.2 Implementación

- Política por defecto ACEPTAR: en principio todo lo que entra y sale por el firewall se
acepta y solo se denegará lo que se diga explícitamente.
- Política por defecto DENEGAR: todo esta denegado, y solo se permitirá pasar por el
firewall aquellos que se permitan explícitamente.

Como es obvio imaginar, la primera política facilita mucho la gestión del firewall, ya que
simplemente debe preocuparse de proteger aquellos puertos o direcciones que se sabe sond e
interés; el resto no importa tanto y se deja pasar. Por ejemplo, si se desea proteger una
máquina Linux, podemos hacer un netstat -ln (o netstat -an, o netstat -aptu |
grep LISTEN), saber que puertos están abiertos, poner reglas para proteger esos puertos y ya
está.
El único problema que se puede tener es que no se controle qué es lo que esta abierto, o que
en un momento dado se instale un software nuevo que abra un puerto determinado, o que no
se conozca que determinados paquetes ICMP son peligrosos. Si la política por defecto es
ACEPTAR y no se protege explícitamente, puede resultar peligroso.

En cambio, si la política por defecto es DENEGAR, a no ser que se permita explícitamente, el


firewall se convierte en un auténtico muro infranqueable. El problema es que es mucho más
difícil preparar un firewall así, y hay que tener muy claro como funciona el sistema (sea
iptables o el que sea) y que es lo que se tiene que abrir sin caer en la tentación de empezar
a insertar reglas super-permisivas.

Esta configuración de firewall es la recomendada, aunque no es aconsejable usarla si no se


domina el sistema. Uno de los objetos principales de este documento es mostrar la forma de
crear este tipo de firewalls.

El orden en el que se ponen las reglas de firewall es determinante. Normalmente cuando hay
que decidir que se hace con un paquete, se va comparando con cada regla del firewall hasta
que se encuentra una que le afecta (match), y se hace lo que dicte esta regla (aceptar o
denegar); después de eso no se buscarán más reglas para ese paquete. En peligro consiste en
colocar reglas muy permisivas entre las primeras del firewall, lo cual puede ocasionar que las
siguientes no se apliquen y no sirvan de nada.

En el presente trabajo de tesis se utilizó un firewall llamado IPTables que viene incluido dentro
del sistema operativo GNU/Linux que se describirá en la siguiente sección.

1.4 IPTables

IPtables es un sistema de firewall vinculado al kernel de linux que se ha extendido


enormemente a partir del kernel 2.4 de este sistema operativo [15]. Al igual que el anterior
sistema ipchains, un firewall de iptables no es como un servidor que se inicie o que se pueda
caer por un error de programación, puesto que iptables al estar integrado con el kernel, es parte
del sistema operativo. Para ponerlo en funcionamiento basta aplicar reglas. Para ello se
ejecuta el comando iptables, con el que se añaden, borran o modifican reglas. Por ello un
firewall de iptables no es sino un script de shell en el que se van ejecutando las reglas de
firewall.

15
1.4.1 Características

- Filtrado de paquetes sin estado para IPv4 e IPv6.


- Filtrado de paquetes con estado para IPv4
- Traducción de puertos y direcciones de red de todo tipo.
- Infraestructura flexible y extensible.
- Capas múltiples de API’s y extensiones de terceras partes.
- Un gran número de módulos adicionales

1.4.2 Filtrado de paquetes

Un filtro de paquetes es un software que examina la cabecera de los paquetes según van
pasando, y decide la suerte del paquete completo. Podría decidirse descartarlo (DROP) (esto
es, como si nunca lo hubiera recibido), aceptarlo (ACCEPT) (dejar que pase), o cosas más
complicadas.

Con el filtrado de paquetes se gana:

- Control cuando está usando una máquina Linux para conectar una red interna a otra
(por ejemplo, Internet), se tiene la oportunidad de permitir ciertos tipos de tráfico, y
restringir otros.
- Seguridad cuando una máquina Linux es lo único Internet y una red interna, se puede
restringir el tráfico de entrada.
- Vigilancia sobre todo el tráfico que entra y sale de un firewall, puesto que a veces
ciertas máquinas mal configuradas podrían enviar información hacia lugares no
deseados.

De lo que se desprende que IPTables es una herramienta adecuada para construir firewalls
para Internet basados en filtrado de paquetes con o sin estado, implementar NAT para
compartir accesos a Internet o para implementar proxys transparentes y hasta crear
encaminadores que soporten políticas de QoS (Calidad de servicio).

Para mayor información sobre IPTables consulte [16] y sobre los conceptos de filtrado de
paquetes véase [17].

Finalmente, como se mencionó anteriormente, el proceso de arranque de IPTables es sencillo y


basta con crear un script de shell que introduzca las reglas deseadas. Es por ello que a
continuación se discutirá brevemente lo que es el shell scripting.

1.5 Scripts de Shell

1.5.1 Intérprete de comandos

Un intérprete de comandos se define como la parte fundamental de un sistema operativo


encargada de ejecutar las órdenes básicas para el manejo del sistema. También denominado
shell. Suelen incorporar características tales como control de procesos, redirección de
entrada/salida y un lenguaje de órdenes para escribir programas por lotes o scripts.

1.5.2 Programas de procesamiento por lotes o scripts

Los lenguajes interpretados forman un subconjunto de los lenguajes de programación.

A diferencia de los lenguajes compilados, en los lenguajes interpretados el código no necesita


ser preprocesado mediante un compilador, eso significa que el ordenador es capaz de ejecutar
la sucesión de instrucciones dadas por el programador sin necesidad de leer y traducir
exhaustivamente todo el código.

16
Para que esto sea posible, hace falta un intermediario, un programa encargado de traducir cada
instrucción escrita con una semántica “humana” a código máquina (instrucciones de la CPU del
ordenador), este programa recibe el nombre de intérprete (en inglés 'parser').

El intérprete se encarga de leer una a una las instrucciones textuales del programa conforme
éstas necesitan ser ejecutadas y descomponerlas en instrucciones del sistema, además se
encarga de automatizar algunas de las tareas típicas de un programador como declaraciones
de variables o dependencias. De esta manera el proceso de programar se suele agilizar mucho,
lo cual repercute en la eficiencia del que tiene que escribir el código.

La principal ventaja de un lenguaje interpretado es que es independiente de la máquina y del


sistema operativo, ya que no contiene instrucciones propias de un procesador sino que contiene
llamadas a funciones que el intérprete deberá reconocer. Basta que exista un intérprete de un
lenguaje para dicho sistema y todos los programas escritos en ese lenguaje podrán ejecutarse
en ese sistema.

Además, un lenguaje interpretado permite modificar en tiempo de ejecución el código que se


está ejecutando así como añadirle algo nuevo que resulta práctico cuando se desea hacer
pequeñas modificaciones en una aplicación y no es deseable tener que recompilarla toda cada
vez.

Sin embargo, no todo son virtudes, un lenguaje interpretado es mucho más lento que uno
compilado ya que constantemente el código tiene que ser analizado y 'traducido' a lenguaje
máquina, aunque con el auge de los procesadores cada vez más rápidos esto ya no debería
suponer un problema.

Los programas escritos mediante lenguajes interpretados se suelen llamar scripts aunque no
todos los scripts están hechos en lenguajes interpretados ya que algunos realizan la fase de
compilado (de una manera transparente al usuario)

Un intérprete ampliamente conocido es bash, y dado que se utilizó en este trabajo de tesis, se
describe a continuación.

1.5.3 BASH

Bash es un Intérprete de comandos de tipo Unix (shell) escrito para el proyecto GNU. Su
nombre es un acrónimo de Bourne-Again SHell: un juego de palabras de Bourne shell sh, el
cual fue el intérprete original de Unix, y el grupo de cristianos de Estados Unidos
autodenominados "Born again Christians". La sintaxis de comandos de Bash mantiene, en gran
medida, la compatibilidad con sh, e incluye ideas tomadas desde ksh y csh, como son el
historial de comandos, la pila de directorios, la variable $RANDOM, y la forma POSIX de
sustitución de comandos, '$('.

El Bourne shell original fue escrito por Stephen Bourne. Bash fue escrito principalmente por
Brian Fox y Chet Ramey.

Bash es el intérprete por defecto en casi todos los sitemas GNU/Linux, y puede ser ejecutado
en casi todos los sistemas operativos Unix. Además, ha sido portado a Microsoft Windows por
el proyecto Cygwin.

17
Bash se distribuye bajo los términos de la Licencia General GNU. Está disponible para ser
descargado desde muchos sitios en Internet, incluyendo el sitio FTP del proyecto GNU.

Una referencia más detallada de bash se puede encontrar en [18].


Así mismo, pueden encontrarse tutoriales muy buenos sobre la programación de shell scripts
en bash en [19] y [20].

18
2 Análisis y diseño
2.1 Planteamiento del problema.

Los firewalls son hasta ahora una medida de seguridad para que las organizaciones aíslen sus
redes del acceso desde Internet. Ya sea que se trate de un firewall de hardware o software, aún
no poseen medidas de protección contra el tráfico no deseado como los virus, los troyanos y los
hackers. De cualquier modo, sirven como una capa extra de seguridad que frecuentemente
inhibe la administración adecuada de un sistema o un dispositivo de red. [21]

Lamentablemente, el garantizar estos accesos causa conflictos con las políticas de seguridad
establecidas por las organizaciones en cuestión por lo que muchos administradores
simplemente niegan todo acceso a los servicios del sistema de cómputo por medio del firewall.
Esta práctica es frecuentemente más simple que establecer las reglas necesarias o efectuar
cambios frecuentes sobre las políticas de seguridad o los límites sobre las cuentas de los
usuarios.

Otro escenario se presenta cuando un host debe conectarse a Internet, como es el caso de los
firewalls basados en sistemas Unix, en virtud de que el propio host hace las veces de firewall.
Una manera de mejorar la seguridad en dichos servidores es la de establecer un esquema en el
que se habiliten ciertos servicios después de establecer algún método de identificación.

El problema radica en que la función básica de un firewall, como se explicó en el primer


capítulo, es la de filtrar tráfico. Dicho filtrado se hace a nivel de protocolos como TCP, UDP e
ICMP (entre otros), lo cual hace prácticamente imposible la autenticación a nivel de usuario, ya
que esa es responsabilidad de la aplicación en sí y no del protocolo; y establecer este tipo de
autenticación resultaría altamente costoso puesto que entonces el firewall debería ser capaz de
desensamblar los paquetes e indagar en su contenido, lo cual sería una falta a la privacidad de
la información.

La idea es no exponer servicios específicos como accesos remotos por SSH o incluso sistemas
de administración remota basados en web hasta que alguna persona autorizada gane el acceso
y se permita una entrada temporal a la dirección IP de la cual proviene la conexión.

Para resolver este problema se propone la implementación de una técnica llamada “Port
Knocking”. [22]

Una definición propuesta por Martin Krzywinsky es: “Port knocking es un método de establecer
una conexión a una computadora en red que no tiene puertos abiertos”. [23]

Antes de que la conexión sea establecida, los puertos se abren mediante una secuencia de
knocks o llamados a los puertos. Dicho llamado es una serie de intentos de conexión a puertos
cerrados que un cliente remoto genera y envía a fin de manipular las reglas del firewall del
servidor para abrir uno o más puertos específicos. Estos intentos de conexión son detectados
por un demonio que el servidor ejecuta y que monitorea al firewall, a fin de traducirlos en
secuencias de llamados de autenticación. Una vez que los puertos deseados se abren, el
cliente remoto puede establecer la conexión y comenzar una sesión.

La definición de una secuencia de llamadas es arbitraria y se deja a criterio del implementador.

2.2. Análisis de requerimientos.

En virtud de la naturaleza inherente del port knocknig, se plantea la necesidad de dividir el


sistema en un servidor y uno o varios clientes. Por tanto, el sistema operativo en el que se lleve
a cabo la implementación deberá tener las capacidades de trabajar en red y de soportar
múltiples usuarios.

19
2.2.1 Consideraciones en el lado del servidor

Siguiendo la definición de port knocking se debe partir de un sistema que tenga incorporado un
firewall mediante el cual se tengan cerrados los 65535 puertos admisibles y que sea lo
suficientemente flexible como para permitir la modificación de las reglas en cualquier momento.

Como se explicó en el apartado anterior, se desea construir un sistema que sea capaz de
monitorear el firewall en la búsqueda de ciertas secuencias de intentos de conexión, de manera
que lo más simple es buscar esos intentos de manera interactiva en el archivo de bitácoras del
sistema. Por tanto, el sistema operativo deberá proveer de las facilidades para que el firewall
escriba a un archivo de bitácora y que permita la lectura filtrada e interactiva del texto.

Una vez encontrada una secuencia, el sistema debe ser capaz de compararla contra una serie
de secuencias válidas dependiendo del usuario que desee conectarse. Por consecuencia el
sistema debe soportar el manejo de múltiples usuarios, cada uno con su respectiva contraseña
(secuencia de knocks).

De lo se desprende la necesidad de un subsistema para otorgar secuencias válidas para los


usuarios del sistema. Cabe destacar que los usuarios necesariamente deberán concordar con
los usuarios propios del sistema operativo en cuanto al nombre del usuario (login), pero no para
la contraseña. En virtud de lo cual, el sistema operativo deberá proveer de los métodos
necesarios para la encriptación de cadenas a fin de obtener las secuencias (passwords) fuera
del alcance de los usuarios internos.

Al encontrar la secuencia válida para un usuario determinado, el sistema deberá modificar las
reglas del firewall, de manera que permita la conexión a la dirección IP de la cual proviene la
secuencia válida. Este proceso se deberá llevar a cabo insertando una regla que permita lo
anterior.

La autenticación posterior la llevará a cabo la aplicación que esté escuchando en el puerto


indicado. En este trabajo de tesis se trabajó preferentemente con los accesos al puerto TCP 22
de SSH. Por consiguiente, el sistema operativo deberá soportar la incorporación de un servidor
de SSH.

Finalizado el periodo válido de conexión el sistema deberá eliminar la regla que permita el
acceso independientemente de que la conexión se lleve a cabo o no eliminando la regla que
garantiza la entrada. Con lo cual se evitará la necesidad de diseñar un sistema que monitoree la
finalización de las sesiones.

La ejecución de los pasos anteriores no deberá afectar en modo alguno las conexiones
establecidas previamente (en caso de existir alguna) por lo que es deseable establecer una
regla inmutable que permita el tráfico que haya establecido.

2.2.2 Consideraciones del lado del cliente

Por parte del cliente de la aplicación, se requiere un sistema operativo que permita el trabajo en
red.

La aplicación cliente deberá ser capaz de solicitar al usuario su login y password de manera
interactiva, así como la dirección IP del servidor y el puerto del servicio al cual se desea
conectar. De esto se desprende que el sistema operativo del cliente deberá permitir la ejecución
de programas interactivos, al menos en modo de línea de comandos.

Una vez alimentado con estos datos, el cliente deberá generar la secuencia de llamados
(knocking secuence) y enviarla al servidor de manera ordenada mediante alguna aplicación
propia del sistema como sería el caso de telnet o netcat. De aquí que el sistema operativo
deberá tener presentes estos programas así como una facilidad para generar la secuencia de
llamadas.

Después de enviar la secuencia, el cliente deberá esperar un periodo razonable de tiempo a fin
de que el servidor procese los datos, y en su caso abra el puerto solicitado, para que
posteriormente se lleva a cabo el intento de establecimiento de conexión.

20
En caso de que la autenticación del cliente haya sido exitosa, el proceso de garantizar el acceso
al sistema correrá totalmente a cargo de la aplicación que se encuentre a la escucha del puerto
deseado, en este caso SSH. Por lo que resulta claro mencionar que el sistema operativo deberá
contar también con este comando.

El mismo criterio del párrafo anterior se deberá aplicar al trabajo en la sesión establecida, que
quedará a cargo del propio sistema operativo anfitrión; por lo que tanto este proceso como el de
desconexión no serán de interés alguno para el servidor.

2.3 Diseño de la aplicación.

A fin de cumplir con los requerimientos anteriores se propone que como sistema operativo base
tanto del servidor como del cliente se utilice GNU/Linux por sus bien conocidas capacidades
inherentes al trabajo en red, soporte multiusuario, multitarea y de multiprocesamiento, así como
de su soporte para firewalls mediante iptables. [24]

El firewall de elección es iptables puesto que:

2. Viene incorporado por defecto dentro del núcleo de GNU/Linux


3. Puede modificar, dar de alta y baja reglas de manera flexible.
4. Tiene la capacidad de modificar sus comportamiento sin necesidad de ser reiniciado
5. Puede escribir en archivos de bitácoras mediante syslogd
6. Puede marcar sus entradas en los archivos de bitácoras, es decir, sea posible distinguir
las secuencias de llamados sin necesidad de hacer un exhaustivo filtrado de texto.

Por tanto, la elección natural es iptables [15] y [16].

Como lenguaje de programación se propone un lenguaje interpretado como Shell Script, en


específico de bash en virtud de sus capacidades [19] y [20]:

2. Incluido por defecto en el sistema operativo GNU/Linux


3. Monitoreo interactivo y filtrado de archivos de texto con los comandos watch, tail y grep
4. Pseudo encriptación de la información mediante las sumas md5 (md5sum).
5. Acceso transparente al firewall mediante los comandos propios de iptables.
6. Sencillez de implantación en cualquier sistema operativo que tenga incorporado bash.
7. Acceso transparente a todos los comandos del sistema

Finalmente, la arquitectura de la propuesta se basa en el paradigma cliente-servidor. Además


de una aplicación auxiliar para el servidor que generará la base de datos de los usuarios
registrados.

2.3.1 Diseño del servidor

El servidor, desde ahora conocido como tochtlid, divide su actividad en dos fases distintivas, a
saber:

– La fase de inicialización y
– La fase de monitoreo.

Cada una de estas fases se describe a continuación.

– Fase de inicialización

En esta fase, el servidor lleva a cabo las siguientes tareas:

– Busca los argumentos si es que alguno se insertó desde la línea de comando.


– Establece las reglas del firewall
– Carga en memoria las contraseñas de los usuarios y calculo de secuencias de llamado.
– Inicializa sus variables.

21
2.3.1.1.1Lectura de argumentos

En esta primera etapa, tochtlid se encarga de leer los argumentos que se le pasen en la línea
de comandos, por medio del comando getopts1. En caso de que alguno se encuentre
presente, el sistema leerá y validará los valores obtenidos, y en caso de ser correctos, los
pondrá en las variables de ambientes correspondientes. En caso de que no se encuentre
presente alguna de las opciones modificables, el sistema adoptará sus valores por defecto.
Estos argumentos son:
– El puerto base para escuchar las secuencias, típicamente 1.
– El puerto tope para escuchar las secuencias, típicamente 65535.
– Cadena de marcado de las entradas del firewall para la bitácora. Típicamente TOCHTLI.
– La ruta del archivo de bitácora donde iptables escribe. Por defecto
/var/log/messages
– La interfaz por la cual se espera la llegada de las secuencias, generalmente eth0. Y
finalmente,
– La ruta del archivo donde se encuentra la base de datos de los usuarios de TOCHTLI. En
este caso definido como tusers.

El funcionamiento de la lectura de argumentos se esquematiza en la figura 2.1

Figura 2.1. Fase de lectura de argumentos

– Establecimiento de las reglas del firewall.

En esta segunda fase, el sistema deberá cargar las reglas del firewall en el siguiente orden:
– Vaciado de las reglas anteriores
– Activación del sistema de registro en bitácoras.
– Establecimiento de la regla para cerrar los puertos 1 a 21.
– Establecimiento de la regla para cerrar el puerto 22.
– Establecimiento de la regla para cerrar los puertos 23 a 65535
– Establecimiento de la regla para permitir el tráfico de conexiones establecidas al puerto 22.

– Carga en memoria las contraseñas de los usuarios.

A continuación el sistema deberá leer el archivo de base de datos de contraseñas de los


usuarios de TOCHTLI, a fin de cargar en memoria tanto los nombres de usuario, como las
1
Para mayores referencias sobre los comandos de bash refiérase a Learning shell:
http://www.linuxcommand.org/learning_the_shell.php

22
contraseñas y a partir de estos datos, generar las secuencias de llamadas válidas para cada
uno. Esto tiene la ventaja de que las secuencias se generan una sola vez, por lo que el sistema
no necesita recalcularla, lo que puede resultar contraproducente puesto que para que el
sistema reconozca un nuevo usuario o bien que reconozca un cambio de contraseña es
necesario que se reinicie. Sin embargo, dado el carácter experimental de este proyecto, se ha
optado por esta técnica.

El proceso de la carga en memoria de las contraseñas de usuarios se esquematiza en la figura


2.2

Figura 2.2. Esquema de la carga en memoria de las contraseñas de usuarios

El algoritmo que se utiliza en el servidor para generar las secuencias válidas para cada usuario
se observa en la figura 2.3:

Figura 2.3. Algoritmo de generación de secuencias válidas para usuarios.

23
2.3.1.1.4Inicialización de variables

Finalmente se inician ciertas variables que el programa utilizará durante su ejecución, como por
ejemplo:

- Periodo válido de conexión.


- IP asignado a la interfaz que se va a escuchar.
- Periodo de tiempo en el cual no se permite la conexión desde un IP que estableció
conexión con anterioridad.

La totalidad del proceso de la fase de inicialización se muestra en la figura 2.4

Figura 2.4. Fase de inicialización de TOCHTLI

– Fase de Monitoreo

Quizás la parte más importante del servidor (tochtlid) es la fase del monitoreo, la cual es la
encargada de:

- Monitorear el archivo de bitácora


- Seleccionar de las cadenas concordantes
- Descomponer de los registros de entrada.
- Verificar la validez para el IP
- Comparar las secuencias entrantes con las almacenadas en memoria
- Garantizar el acceso al servidor
- Cerrar el acceso una vez transcurrido el periodo válido de conexión

En la figura 2.4 se esquematiza el funcionamiento de la fase de monitoreo.

24
Figura 2.5. Fase de monitoreo.

A continuación se describirán cada uno de estos procesos:

2.3.1.2.1 Monitoreo del archivo de bitácora

Se comienza el proceso mediante la ejecución del comando watch con algunas opciones que
permitan llevar a cabo la lectura de las líneas del archivo de bitácora, conforme se agregan al
mismo. Estas opciones son follow y retry.

A continuación el sistema entra en un ciclo infinito en el cual se llevan a cabo las funciones
restantes.

2.3.1.2.2 Selección de las cadenas concordantes

En virtud de que los resultados devueltos por el comando watch pudieran no ser relevantes
para TOCHTLI, es necesario hacer un filtrado de selección de los datos de interés, es decir, se
necesita buscar la cadena de identificación, que como se mencionó en secciones anteriores es,
por defecto “TOCHTLI”.

Las líneas de texto que se van agregando al archivo de bitácoras que contengan esta cadena
de identificación serán aquellas registradas por el firewall, por lo tanto, son los únicos sujetos de
interés para el sistema.

Este filtrado se lleva a cabo por medio del comando grep.

2.3.1.2.3 Descomposición de las cadenas de entrada.

Después de identificar las cadenas de interés, el sistema obtendrá los datos de relevancia
como son el IP fuente y el puerto destino. Es decir, la dirección IP de la cual provienen los
intentos de conexión y el puerto al cual intentan acceder.

La importancia de estos datos radica en el hecho de que en base a ellos se detecta la


secuencia de llamados realizada por un IP específico, lo cual es el concepto fundamental del
port knocking.

25
2.3.1.2.4 Verificación de validez para el IP

Para cada uno de los llamados que componen las secuencias se debe verificar que su arribo en
un periodo de tiempo válido, es decir, no deben transcurrir más allá de dos segundos entre la
recepción de cada uno de los llamados. En el caso de que el periodo de validez sea rebasado,
el sistema regresará al inicio del ciclo de lectura.

Esta no es la única verificación que se lleva a cabo, pues tiene lugar una segunda en la que
TOCHTLI revisa que no exista un procesamiento simultáneo de la misma dirección IP. Si
resulta que el IP ya está siendo procesado simplemente se omitirá esta nueva secuencia. En
caso contrario, se procederá al siguiente paso que es la comparación de las secuencias
entrantes con las almacenadas en memoria.

2.3.1.2.5 Comparación de las secuencias entrantes con las almacenadas en memoria

Una secuencia válida para el sistema se compone de al menos 16 llamados provenientes de la


misma dirección IP. Como se describió con anterioridad, la validez de una secuencia se deja
totalmente a criterio del implementador.

Al recibir al menos 16 llamados, el sistema tendrá una secuencia candidata que deberá
comparar con cada una de las secuencias válidas generadas en la etapa de inicialización del
sistema.

Si se comparan todas las secuencias válidas sin encontrar una coincidencia plena entonces
simplemente se desecharán y el proceso continuará nuevamente desde el principio del ciclo de
lectura.

En caso de encontrar una coincidencia plena con alguna de las secuencias, el sistema se
encargará de garantizar el acceso al servidor.

2.3.1.2.6 Otorgamiento del acceso al sistema

Este paso es simple y se realiza en dos pasos:

1. Se elimina la regla para cerrar el puerto 22, y


2. Se crea una nueva regla para permitir la entrada a los paquetes con bandera SYN
activada dentro de la cabecera TCP desde la dirección IP de la cual proviene la
secuencia validada. Con una regla de este tipo se garantiza que únicamente pase
tráfico para establecer una nueva conexión.

Hecho lo cual, TOCHTLI entrará en una etapa de suspensión de 10 segundos que es tiempo
suficiente para que el usuario establezca una conexión.

2.3.1.2.7 Cerrado del puerto

Al transcurrir este periodo de conexión, TOCHTLI eliminará la regla que permitió el acceso de
tráfico de solicitud de conexión y restablecerá la regla mediante la cual el puerto 22 se cierra a
todo tipo de tráfico.

La permanencia de esta nueva sesión así como de las ya establecidas se garantiza por medio
de la regla que permite el tráfico tipo “establecido”. Por tanto, este proceso será totalmente
transparente para la nueva conexión así como para las establecidas con anterioridad.

En virtud de que los cuatro procesos que se han explicado con anterioridad mantienen una
relación muy estrecha, en la figura 2.6 se muestran:

26
Figura 2.6. Fase de monitoreo detallado.

2.3.2 Diseño del cliente

La aplicación cliente es mucho más simple puesto que solamente se encarga de recibir
parámetros de entrada tales como el nombre de usuario (login), la dirección IP del servidor, el
password y el puerto al que se desea acceder para generar la secuencia de llamados al
servidor, ejecutarlos y en su caso establecer la conexión.

El proceso realizado por el cliente puede dividirse en tres fases:

- Solicitud de datos del usuario


- Generación y envío de la secuencia de llamados.
- Establecimiento de la conexión.

2.3.2.1 Solicitud de datos del usuario

Esta es propiamente la fase de inicialización de la aplicación cliente, puesto que se establecen


el valor del periodo de espera entre el envío de la secuencia y el intento de establecimiento de
sesión con el servidor.

Una parte de los datos se le proporcionan desde la línea de comandos (login y dirección IP del
servidor). El resto (password y puerto de conexión), se solicitan de forma interactiva mediante el
comando read.

La última parte del proceso consiste en la creación de una cadena que se usará como semilla
para la generación de la secuencia de llamados. Esta cadena se obtiene del resultado de la
suma md5 de la concatenación del nombre de usuario y el password.

27
2.3.2.2 Generación y envío de la secuencia de llamados

Una vez que se tiene la suma indicada en la sección anterior, se procede a obtener los 16
números de puerto que conforman la secuencia de llamados mediante un algoritmo que se
basa en la multiplicación del valor de un contador por el valor de una subcadena de dos dígitos
de la cadena de suma.

Este mismo algoritmo se utiliza en la aplicación servidor para obtener las secuencias válidas
para cada uno de los usuarios de TOCHTLI.

Después se utiliza el programa definido para realizar los intentos de conexión para hacer los
llamados a los puertos indicados.

Finalmente el cliente entra en una etapa de suspensión de dos segundos que se otorgan al
servidor para procesar los datos.

Este proceso se muestra en la figura 2.7:

Figura 2.7. Generación de secuencia candidata

2.3.2.3 Establecimiento de la conexión

Al transcurrir este tiempo, el cliente intentará realizar la conexión al puerto deseado, típicamente
se solicitara la atención de un servidor SSH que escucha en el puerto 22. Este comportamiento
puede variar de acuerdo a la implementación.

2.3.3 Diseño de la aplicación auxiliar generadora de usuarios

Una característica interesante de la propuesta es que los usuarios que pueden hacer uso del
sistema, no necesariamente deben concordar con los usuarios registrados en el sistema
operativo del servidor, por lo que es necesario contar con una aplicación auxiliar que pueda
generar la base de datos de usuarios propia para almacenar a los usuarios de TOCHTLI.

Esta aplicación se llama tpasswd y tiene las funciones de alta, modificación y eliminación de
usuarios. Cabe mencionar que esta aplicación está programada en shell script, lo mismo que
las aplicaciones servidor y cliente.

Del funcionamiento de la aplicación vale la pena mencionar el método para la generación de los
passwords del usuario, que no es más que el resultado de la suma md5 de la concatenación del
login y el password.

Resta mencionar que el archivo en el que se guardan los logins y passwords es por defecto
tusers.

28
3. Pruebas e implementación.
En las secciones siguientes se explicarán todos los pasos que deben llevarse a cabo, tanto del
lado del servidor como del cliente a fin de establecer una conexión exitosa.

Cabe mencionar que algunas de las imágenes de ventanas tienen un color de fondo un poco
más oscuro que otras, esto se hizo a propósito para que el lector distinga aquellas imágenes
tomadas desde el servidor (fondo más oscuro) que aquellas de los clientes (fondo blanco).

Las pruebas realizadas se llevaron a cabo en tres máquinas, todas ellas con un sistema
operativo GNU/Linux Slackware 10.1. Se usaron dos computadoras como clientes y una para el
servidor con las características señaladas en la tabla 3.1:

Procesador RAM Nombre Kernel


AMD Athlon XP 2000 a 1.6 GHz 512 Mb Cliente1 2.6.11.6
Intel celeron a 700 MHz 512 Mb Cliente2 2.4.29.0
Intel Pentium 4 a 2.7 GHz 512 Mb Servidor 2.4.29.0
Tabla 3.1 Características de las computadoras utilizadas en las pruebas

Se utilizó una red Ethernet a 100 Mbps con dirección 192.168.1.0/24

Las direcciones IP usadas en las tres computadoras se muestran en la Tabla 3.2

Nombre Dirección IP
Servidor 192.168.1.10
Cliente1 192.168.1.5
Cliente2 192.168.1.3
Tabla 3.2 Direcciones IP de las computadoras utilizadas en las pruebas

En primera instancia, deben crearse usuarios para TOCHTLI en el equipo Servidor; esto se
hace mediante la aplicación auxiliar tpasswd. Cabe recordar que estos usuarios no deben ser
diferentes de los usuarios locales, aunque en el caso de sus contraseñas es diferente, pues
estas pueden variar. Para este ejemplo se usarán los usuarios mostrados en la tabla 3.3

Login local Password local Login TOCHTLI Password TOCHTLI


Acampos passwd1 acampos secreto1
Jiménez passwd2 Jiménez secreto2
Tabla 3.3. Datos de los usuarios usados en las pruebas

Para este ejemplo se hace una correspondencia uno a uno entre los usuarios locales con los
usuarios TOCHTLI, lo cual no es forzoso. Este proceso se ilustra en la figura 3.1.

29
Figura 3.1. Generación de usuarios de tpasswd

Otro dato relevante mostrado por la figura 3.1, es el tiempo de creación de cada usuario,
medido usando el comando date +%k:%M:%S.%N, que muestra el formato
hh:mm:ss.nanosegundos.

El siguiente paso, es ejecutar la aplicación servidor (tochtlid). Para este ejemplo se utilizan los
parámetros. Estos se muestran en la tabla 3.4.

Parámetro Valor por defecto Significado


-p 1 Puerto límite inferior de escucha
-P 65535 Puerto límite superior de escucha
-s TOCHTLI Marca de las entradas del firewall
-l /var/log/mesages Archivo de bitácora
-i eth0 Nombre de la interfaz
-w Tusers Archivo de usuarios de TOCHTLI
Tabla 3.4. Parámetros aceptados por tochtlid.

Para este ejemplo, también se muestran en la figura 3.2 los tiempos ocupados para llevar a
cabo la generación de la secuencia válida de llamados para cada uno de los usuarios, así como
la enumeración de dichas secuencias.

30
Figura 3.2. Inicio de tochtlid, tiempo de generación de secuencias y enumeración.

Este proceso corresponde con la fase de carga en memoria de las contraseñas de los usuarios.
El código responsable de realizar esta fase se muestra en la figura 3.3

Figura 3.3. Código de generación de secuencias válidas

En la figura 3.3 también se muestran las declaraciones de los arreglos para guardar los
passwords (SUMAS, por ser sumas md5), los logins de los usuarios (USERS) y las secuencias
de puertos seguros (sec_ports).

De acuerdo con el diseño de tochtlid, la siguiente fase se refiere a la inserción de las reglas de
iptables para cerrar todos los puertos, proceso que tardó en la máquina Servidor 10898000
nanosegundos. Al finalizar este proceso, las reglas del firewall quedaron como se muestra en la
figura 3.4:

31
Figura 3.4. Reglas del firewall después de ser cargadas en el núcleo.

Una ejecución de un escáner de puertos como nmap muestra que absolutamente todos los
puertos están cerrados. Véase figura 3.5

Figura 3.5. Ejecución el escáner de puertos nmap contra el Servidor.

32
Después de esto, tochtlid entrará a la fase de monitoreo del archivo de bitácora. El código que
hace lo hace posible se presenta en la figura 3.6.

Figura 3.6. Código de monitoreo al archivo de bitácoras.

A partir de este momento tochtlid quedará a la espera de cualquier intento de conexión de parte
de sus clientes. A continuación se explicará el proceso que los clientes llevan a cabo para
conectarse al servidor.

Lo primero que un usuario debe hacer a fin de intentar la conexión con el Servidor, es la
invocación del programa cliente (tochtli). Este programa debe llevar como argumentos iniciales
el login para tochtlid y la dirección IP del servidor. A continuación tochtli pedirá el password para
generar la secuencia candidata. Este proceso se muestra en las figuras 3.7 y 3.8 para Cliente1
y Cliente2 respectivamente; así como el tiempo de creación de dicha secuencia y la secuencia
en sí.

Figura 3.7. Envío de secuencia candidata del usuario acampos.

33
Figura 3.8. Envío de la secuencia candidata del usuario jjimenez.

A partir de un examen comparativo de las figuras 3.7 y 3.8 contra los datos mostrados en la
figura 3.2, se puede ver que el password suministrado por el usuario acampos fue el correcto,
puesto que la secuencia de llamados candidata corresponde perfectamente con la secuencia
válida generada por tochtlid, en cambio el usuario jjimenez escribió un password erróneo, por lo
que la secuencia candidata no concuerda con la válida.

El código que genera la secuencia candidata por parte del cliente se muestra en la figura 3.9.

Figura 3.9. Código para la generación de las secuencias candidatas.

Por otro lado, el código que se encarga de lanzar la secuencia de llamados se puede ver en la
figura 3.10.

34
Figura 3.10. Código para enviar la secuencia candidata al Servidor.

Es conveniente hacer notar la posibilidad de la aplicación auxiliar tpasswd, la cual pudiera crear
dos entradas diferentes para un mismo usuario (el mismo usuario con dos o más passwords).
Así, cuando se deseara modificar alguna de las contraseñas, siempre se modificaría la primera
que se encuentre, lo cual podría resultar en un comportamiento no deseado de la aplicación. Un
comportamiento similar podría suceder cuando se requiriese eliminar al usuario. En este último
caso bastará con ejecutar el comando tantas veces como sea necesario.

En este punto, los clientes han enviado ya la secuencia de llamados y tochtlid los recibirá y
comparará con las secuencias válidas almacenadas en memoria.

Para el caso del usuario acampos, en la figura 3.11 se muestra el proceso de recepción de la
secuencia de llamados.

Figura 3.11. Proceso de recepción de secuencias candidatas para el usuario acampos.

35
En la figura 3.11 también se puede observar el tiempo que le toma a tochtlid hacer la
comparación con la primera secuencia válida almacenada, que resulta ser también la correcta.

Es de recalcar que en la última línea que muestra la secuencia candidata, existe un llamado al
puerto 22, lo que sugiere que el tiempo de espera entre el envío de la secuencia candidata y el
intento de conexión del cliente es quizás demasiado corto y quizás se deba incrementar al
menos un segundo más. De cualquier modo, tochtlid solamente hará caso de los primeros 16
llamados de la secuencia, por lo que hará caso omiso de los llamados posteriores.

Finalmente se ve que tochtlid entra en un periodo de suspensión de 10 segundos a fin de que el


cliente establezca la conexión.

La figura 3.12 muestra que al transcurrir el periodo de espera se intenta la conexión por ssh la
cual resulta exitosa. Esto se sabe en vista de la aparición del prompt del cliente de ssh
solicitando la contraseña local del usuario acampos y su posterior ingreso al servidor.

Figura 3.12. Acceso al sistema Servidor del usuario acampos.

Un vistazo rápido al estado de las reglas de iptables mostrará que se ha insertado una regla de
aceptación para la dirección IP de cliente1. Esto se ve en la figura 3.13

36
Figura 3.13. Inserción de la regla para permitir el acceso desde 192.168.1.3

En la figura 3.14 se muestra también el estado de las conexiones TCP del servidor mediante
una ejecución del comando netstat.

Figura 3.14. Salida del comando netstat.

Para el caso del usuario jjimenez, la figura 3.15 muestra claramente que a pesar de que
llegaron las 16 llamadas, tochtlid no pudo otorgar el acceso al sistema en virtud de que las
secuencias no concuerdan.

37
Figura 3.15. Recepción y verificación de la secuencia candidata del usuario jjimenez.

De tal manera, aunque el cliente de ssh trate de establecer la conexión, el Servidor no lo


permitirá. Para que pueda hacer otro intento satisfactorio, el cliente deberá esperar a que
transcurran al menos 20 minutos. En la figura 3.16 se muestra el reintento del cliente, esta vez,
con una conexión exitosa.

Figura 3.16 Conexión exitosa para el usuario jjimenez.

38
La prueba de la aceptación de la secuencia para el usuario jjimenez se muestra en la figura
3.17, en la que se presenta el proceso se recepción y comparación de la secuencia candidata y
su comparación exitosa garantizando el acceso al sistema.

Figura 3.17. Recepción y comparación exitosa de la secuencia del usuario jjimenez.

39
4. Conclusiones
Se ha desarrollado un mecanismo para el filtrado de accesos no deseados en una ambiente
TCP/IP, basándose en el concepto de Port Knocking. Esta técnica establece los mecanismos
para abrir y cerrar puertos de un equipo Servidor, mediante una secuencia de llamados
(knocks) a diversos puertos TCP (Ports).

En nuestro caso, hemos considerado un ambiente de experimentación, con un equipo de


cómputo que hace las veces de Servidor y dos equipos más que hacen el papel de Clientes. Se
cerraron todos los puertos TCP del equipo servidor y se diseñó un mecanismo para la
generación de secuencias de llamados (port knocking).

Nuestros experimentos fueron realizados, usando únicamente el puerto 22 como puerto de


entrada. Así, si alguno de los clientes envía una secuencia válida hacia el Servidor, éste abrirá
este puerto para su acceso exclusivo a dicho cliente y 10 segundos después de la conexión, el
puerto se cerrará automáticamente.

Se realizaron diversas pruebas para determinar el comportamiento del mecanismo implantado,


y se observó que éste funciona correctamente, aunque es posible mejorarlo a futuro.

Al ser el presente trabajo de tesis una implantación de carácter experimental que sirva como
prueba del concepto de port knocking, no se recomienda para implantación en un servidor de
producción debido a la alta carga de tráfico que debe soportar, de manera que habría que
encontrar un método más rápido de hacer la lectura de los llamados de secuencia. Sobre esto
sería deseable desarrollar un sistema que no utilice lenguajes interpretados como el caso del
lenguaje C.

En este mismo orden de ideas, sería deseable incorporar el uso de librerías especializadas
para la captura y análisis de paquetes directamente de la pila TCP/IP, como es el caso de
libnet, ya que brindaría mayor velocidad al sistema, puesto que como se sabe que el acceso al
sistema de archivos es más lento que a la memoria. Inclusive, si se desea continuar con el
diseño planteado en este trabajo sería recomendable que el archivo de bitácoras se encontrase
en una partición con ReiserFS, que por su diseño es más veloz que ext3, el cual es el sistema
de archivos por defecto de varias distribuciones de GNU/Linux. Lamentablemente ReiserFS
presenta problemas de pérdida de datos en ambientes en los que la alimentación eléctrica falle
continuamente.

Otro problema de seguridad se presenta en virtud de que el presente trabajo solamente se basa
en la dirección IP del solicitante. Esto resulta peligroso cuando alguna entidad externa falsifica
la identidad de la máquina original mediante una técnica llamada IP spoofing (sustitución de
identidad). Una posible solución que no resulta muy práctica es la de agregar la dirección física
de la interfaz de red a los datos almacenados en tusers, lo cual conlleva problemas de
mantenimiento del sistema. Por otro lado, una solución más viable es la activación del filtro rp
(rp_filter), con lo cual el propio sistema operativo se encargaría de hacer las revisiones
correspondientes.

Así mismo, un aspecto importante a considerar es que por la naturaleza del port knocking, es
sensible a una variante del ataque DDoS (Distributed Denial of Service o negación de servicio
distribuido), en el cual se envía un número muy grande de paquetes con la opción SYN activada
en tiempos relativamente largos. Generalmente los ataques tipo DoS (Denial of Service o
negación de servicio) o DDoS comunes pueden contrarrestarse activando las syn_cookies en el
núcleo del sistema, puesto que evitan el consumo excesivo de recursos del sistema a la llegada
de paquetes SYN en tiempos cortos. Ante esto podría incluso plantearse la posibilidad de
modificar las reglas del firewall para limitar el arribo de paquetes en un lapso de tiempo
determinado, pero esto podría incluso bloquear los intentos reales de conexión llevando
nuevamente a un problema de DoS. Según el diseño presentado en este trabajo, existe otro
tipo peligro puesto que se escribe un registro por cada paquete recibido, el archivo de bitácoras
puede crecer hasta alcanzar el tamaño máximo de la partición que lo contenga, causando que
otras aplicaciones que hagan uso de él se encuentren imposibilitadas de hacerlo o incluso que
no se pueda escribir nada más en el disco duro (dependiendo del esquema de particionamiento
utilizado).

40
Digno de mención es el hecho de que este tipo de ataques (DoS y DDoS), junto con todas sus
variantes, no tienen aún un antídoto que los contrarreste

Otra mejora substancial al sistema sería el de hacer que los logins de usuario no
correspondiesen con los del sistema operativo, aunque también provocaría que los usuarios
tuviesen que recordar dos logins y dos passwords, lo que en términos reales no es muy práctico
ya que la tendencia de los usuarios es la de escribir esos datos sensibles en algún lugar poco
seguro, dado lo cual algún usuario mal intencionado podría hacer mal uso de ellos.

Un último punto a considerar es que en la implementación aquí presentada, las secuencias


candidatas son siempre las mismas y son susceptibles a ser capturadas mediante un sniffer,
por lo que sería deseable que en futuras propuestas se incluyese algún método para crear
secuencias candidatas que presentaran variaciones cada vez que se presente un intento de
conexión, lo cual acarrearía una mejora en el diseño de la aplicación, en el sentido de que
deberá mejorarse los procesos de generación y comparación de secuencias válidas y
candidatas.

Para terminar, port knocking no es el mejor sistema de seguridad, lo mismo que los firewalls,
pero sirve como una línea más de defensa ante intentos de accesos no deseados a los
sistemas de cómputo. En la medida en la que el ingenio humano encuentra nuevas formas de
ganar accesos no autorizados, se encuentran también medidas ingeniosas para defender los
sistemas o viceversa. El hecho es que no importa que se utilice el sistema operativo más
seguro del mundo, siempre existirá una aplicación vulnerable a algún tipo de ataque.

41
5. Referencias
[1] Internet. Wikipedia en Español. [Online] http://es.wikipedia.org/wiki/Internet

[2] TCP/IP. Wikipedia en Español. [Online] http://es.wikipedia.org/wiki/TCP/IP

[3] David C. Plummer. An Ethernet Address Resolution Protocol. Internet Engineering Task
Force. Noviembre de 1982. [Online] http://www.ietf.org/rfc/rfc0826.txt?number=826

[4] Sun Microsystems. NFS: Network File System Protocol Specification. Internet Engineering
Task Force. Marzo de 1989. [Online] http://www.ietf.org/rfc/rfc1094.txt?number=1094

[5] J. Case, K. McCloghire, M. Rose. Protocol Operations for version 2 of the Simple Network
Management Protocol (SNMPv2). Internet Engineering Task Force. Abril de 1993. [Online]
http://www.ietf.org/rfc/rfc1448.txt?number=1448

[6] P. Mockapetris. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. Internet


Engineering Task Force. Noviembre de 1987. [Online]
http://www.ietf.org/rfc/rfc1035.txt?number=1035

[7] Jonathan B. Postel. SIMPLE MAIL TRANSFER PROTOCOL. Internet Engineering Task
Force. Agosto de 1982. [Online] http://www.ietf.org/rfc/rfc0821.txt?number=821

[8] David H. Crocker. STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT
MESSAGES. Internet Engineering Task Force. Agosto de 1982. [Online]
http://www.ietf.org/rfc/rfc0822.txt?number=822

[9] J. Postel. TELNET PROTOCOL SPECIFICATION. Internet Engineering Task Force. Junio de
1980. [Online] http://www.ietf.org/rfc/rfc0764.txt?number=764

[10] J. Postel, J. Reynolds.TELNET PROTOCOL SPECIFICATION. Internet ENgineering Task


Force. Mayo de 1983. [Online] http://www.ietf.org/rfc/rfc0854.txt?number=854

[11] J. Postel, J. Reynolds. FILE TRANSFER PROTOCOL (FTP). Internet Engineering Task
Force. Octubre de 1985. [Online] http://www.ietf.org/rfc/rfc0959.txt?number=959

[12] HTTP. Wikipedia en Español. [Online] http://es.wikipedia.org/wiki/HTTP

[13] T. Berners-Lee, R. Fielding, H. Frystyk. Hypertext Transfer Protocol -- HTTP/1.0. Internet


Engineering Task Force. Mayo de 1996. [Online]
http://www.ietf.org/rfc/rfc1945.txt?number=1945

[14] SSH. Wikipedia en Español. [Online] http://es.wikipedia.org/wiki/SSH

[15] IPTables manual práctico. Pello Xabier Altadill Izura. [Online]


http://www.pello.info/filez/firewall/iptables.html

[16] Netfilter/IPTables Home page. [Online] http://www.netfilter.org/

[17] Rusty Russell. Packet filtering HOWTO. Enero de 2002. [Online]


http://www.netfilter.org/documentation/HOWTO/es/packet-filtering-HOWTO.html

[18] Página manual de BASH. [Online] http://www.linuxcommand.org/man_pages/bash1.html

[19] Mike G. BASH Programming Introduction HOWTO. [Online]


http://www.tldp.org/HOWTO/Bash-Prog-Intro-HOWTO.html

[20] Mendel Cooper. Advanced Bash-Scripting Guide. Junio de 2005. [Online]


http://www.tldp.org/LDP/abs/html/index.html

[21]Firewalls Linux, Guía Avanzada. Roert L. Ziegler. Prentice Hall. España 2003

42
[22] J Yarden. Use port knocking to bypass firewall rules and keep security intact. SANS
Institute. 2005. [Online]. http://techrepublic.com.com/5100-1009-5798871.html

[23] Maddock B. Port Knocking: An overview of Concepts, Issues and Implementations. SANS
Institute. 2004 [Online] http://www.giac.org/practical/GSEC/Ben_Maddock_GSEC.pdf

[24] Matt Welsh. Guía de instalación de Linux y primeros pasos. 1992. [Online].
http://es.tldp.org/Manuales-LuCAS/LIPP2/lipp-2.0-beta-html

43