Tochtli: Una implementación de la prueba de concepto de port knocking

8/8/2019 Tochtli: Una implementación de la prueba de concepto de port knocking

http://slidepdf.com/reader/full/tochtli-una-implementacion-de-la-prueba-de-concepto-de-port-knocking 1/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.

TESISQUE 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 eldesarrollo 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 contenidoPágina

Tabla de contenido IÍndice de figuras IIÍndice de tablas IIIIntroducción IV

1. Marco teórico 11.1.Visión general de la red Internet 11.1.1 ¿Qué es Internet? 11.1.2 ARPANET 11.1.3 INTERNET 11.2 Modelo de referencia TCP/IP 21.2.1 Historia del TCP/IP 21.2.2 Consideraciones de diseño 21.2.3 Características del TCP/IP 21.2.4 Comparación con el modelo de referencia OSI 21.2.4.1 Capa de Internet 31.2.4.2 Capa de sesión 31.2.4.3 Comunicación orientada / no orientada a la conexión 3

1.2.5 Problemas del modelo TCP/IP 31.2.6 Aplicación del modelo de referencia 31.2.7 Capas del modelo de referencia TCP/IP 41.2.8 Protocolos del modelo de referencia 41.2.9 Protocolos de acceso a la red 41.2.9.1 Protocolo ARP 41.2.9.2 Protocolo RARP 41.2.9.3 El protocolo de Internet (IP) 41.2.9.3.1 Servicios básicos 41.2.9.3.2 Datagramas IP 51.2.9.3.3 Direcciones IP 61.2.9.3.4 Encaminamiento 91.2.9.3.5 Subredes 9

1.2.9.3.6 Resolución de direcciones 91.2.10 Los protocolos de transporte 101.2.10.1El protocolo UDP 111.2.10.2Cabecera TCP 111.2.10.3Protocolos de nivel de aplicación 111.2.10.3.1 Protocolos que usan UDP 111.2.10.3.2 Protocolos que usan TCP 111.3 Firewalls 131.3.1 ¿Qué es un firewall? 131.3.2 Implementación 151.4 IPTables 161.4.1 Características 161.4.2 Filtrado de paquetes 16

1.5 Scripts de Shell 171.5.1 Intérprete de comandos 171.5.2 Programas de procesamiento por lotes o scrips 171.5.3 BASH 182 Análisis y diseño 192.1 Planteamiento del problema 192.2 Análisis de requerimientos 192.2.1 Del lado del servidor 202.2.2 Del lado del cliente 202.3 Diseño de la aplicación 212.3.1 Diseño del servidor 212.3.2 Diseño del cliente 273 Pruebas e implementación 304 Conclusiones 425 Referencia 44

I



Índice de figuras

Página1.1 Primitivas de servicio en la interfaz de IP 51.2 Formato de la cabecera IP 61.3 Dirección IP codificada 7

1.4 Direcciones IP especiales 81.5 Esquema de interconexión de diferentes clases de redes 81.6 Formato de la cabecera TCP 111.7 Topología clásica de un firewall 131.8 Esquema de una DMZ 141.9 Estructura de una DMZ con doble firewall 141.10Esquema de un ISP 152.1 Fase de lectura de argumentos 222.2 Esquema de la carga en memoria de las contraseñas de usuarios 232.3. Algoritmo de generación de secuencias válidas para usuarios 242.4. Fase de inicialización de TOCHTLI 242.5. Fase de monitoreo. 252.6. Fase de monitoreo detallado. 272.7. Generación de secuencia candidata 283.1. Generación de usuarios de tpasswd 313.2. Inicio de tochtlid , tiempo de generación de secuencias y enumeración. 323.3. Código de generación de secuencias válidas 323.4. Reglas del firewall después de ser cargadas en el núcleo 333.5. Ejecución el escáner de puertos nmap contra el Servidor. 343.6. Código de monitoreo al archivo de bitácoras. 343.7. Envío de secuencia candidata del usuario acampos. 353.8. Envío de la secuencia candidata del usuario jjimenez . 353.9. Código para la generación de las secuencias candidatas. 363.10. Código para enviar la secuencia candidata al Servidor. 363.11. Proceso de recepción de secuencias candidatas para el usuario acampos. 373.12. Acceso al sistema Servidor del usuario acampos. 383.13. Inserción de la regla para permitir el acceso desde 192.168.1.3 38

3.14. Salida del comando netstat. 393.15. Recepción y verificación de la secuencia candidata del usuario jjimenez . 393.16 Conexión exitosa para el usuario jjimenez. 403.17. Recepción y comparación exitosa de la secuencia del usuario jjimenez . 40

IV



Índice de tablas

Página1.1. Opciones de calidad de servicio 51.2 Número de redes y hosts por clase 73.1 Características de las computadoras utilizadas en las pruebas 30

3.2 Direcciones IP de las computadoras utilizadas en las pruebas 303.3. Datos de los usuarios usados en las pruebas 303.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ónde sistemas informáticos, independientemente de su tipo y situación [1]. Está físicamentecompuesta por computadoras de diversos tipos, marca y sistema operativo y ruteadores queestán distribuidos por todo el mundo y unidos a través de enlaces de comunicaciones muydiversos. Sobre éstos, aprovechando los servicios de comunicaciones de la red, se ejecutandiversos 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 decomunicaciones, 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 quesea independiente del tipo de sistema operativo. Esta diversidad provoca numerosos problemasde 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 hanevolucionado desde la red ARPANET hasta la actual Internet. A finales de los 60, los científicosde la empresa RAND, quienes realizaban una investigación para el Departamento de Defensade los Estados Unidos, propusieron la tecnología de conmutación de paquetes. Esta tecnologíafue originalmente concebida para asegurar el funcionamiento de la red en la fase del ataquenuclear. 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ñadapara soportar computadores centrales de tiempo compartido, posteriormente los usuarios

comenzaron a disfrutar de otras aplicaciones como el correo electrónico, la transferencia dearchivos y la posibilidad de trabajar con archivos compartidos.

Esta red era de conmutación de paquetes y estaba basada en un conjunto de pequeñosdispositivos interconectados llamados procesadores de mensajes con interfaz (IMPs). EstosIMP’s, los precursores de los modernos ruteadores, ofrecieron encaminamiento yalmacenamiento. El éxito de Arpanet fue el ser el catalizador para la investigación en la reddando como resultado un protocolo de emergencia: el TCP/IP, el cual se estableció firmementeen 1980. Arpanet completó su transición al TCP/IP en 1983, y en 1990 dejó de ser la espinadorsal (backbone) de la red Internet.

1.1.3 INTERNET

En 1986, la National Science Foundation de Estados Unidos, comenzó el desarrollo de unaespina dorsal de alta velocidad llamada NSFnet, para conectar los centros de súper cómputo dela nación.

A medida que fue creciendo la demanda del ancho de banda de esta espina dorsal, la NSF dioorigen a Merit en una muy productiva unión con MCI e IBM, para desarrollar una espina dorsalde 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 redArpanet.Fuera de la Merit, surgió una nueva corporación sin ánimo de lucro para redes avanzadas yservicios: la ANS. Esta corporación, fue inicialmente responsable del desarrollo de la espinadorsal 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 hastamas 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ísicaNuclear), 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) quese 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 mismotiempo que se empezaban a desarrollar las redes de área local. El ejercito americano gracias alproyecto ARPA (Advanced Research Projects Agency) invirtió muchos recursos en investigar elTCP/IP y en la interconexión de redes. Fueron unas de las primeras organizaciones que tuvovarias 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 maneratransparente 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 nodosde la red pudiera ser objeto de un atentado en cualquier momento, otro de los objetivosprincipales fue que la red fuera capaz de seguir funcionando sin que las comunicacionesexistentes se interrumpieran si algunos de los dispositivos de hardware fallaba. La idea era quelas comunicaciones permanecieran intactas mientras las máquinas origen y destino estuvieranfuncionando, aunque algunas de las máquinas o de las líneas de transmisión en el trayectodejara de funcionar de forma repentina. Por otra parte, debido a que se estaban pensando enaplicaciones que tuvieran diferentes requerimientos, se necesitaba que la arquitectura fueraflexible.

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 necesariospara alcanzarlo.

- Resuelve de forma automática los problemas que se puedan dar durante el intercambiode información: fallos en los enlaces, errores, pérdidas o duplicación de datosinformació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 correspondientesen cada uno de los modelos. Una de las contribuciones más importantes del modelo OSI es ladistinción que hace entre servicios, interfaces y protocolos. Originalmente el modelo TCP/IP nodistinguía claramente entre estos tres conceptos, aunque posteriormente se ha reajustado parahacerlo mas parecido a OSI. En el modelo OSI se ocultan mejor los protocolos que en elmodelo TCP/IP y se pueden reemplazar con relativa facilidad al cambiar de tecnología. Elmodelo OSI se definió antes que los protocolos, mientras que en TCP/IP se definieron primerolos protocolos y el modelo fue en realidad una descripción de los protocolos existentes, por loque lo protocolos se ajustaban al modelo. El único problema es que el modelo no se ajustaba aninguna pila de protocolos por lo que no fue de mucha utilidad para describir redes que nofueran del tipo TCP/IP.

Una diferencia obvia entre los dos modelos es el número de capas. El modelo OSI tiene 7capas 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 delmodelo de referencia OSI descrito en un tema anterior, el esquema de capas OSI no tieneninguna 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 nocontiene 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 detiempo compartido a estaciones de trabajo. Por este motivo, los investigadores que diseñaronTCP/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 laorientada 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 redsó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 losprotocolos 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 losconceptos de servicio, interfaz y protocolo. En el modelo TCP/IP no se hace unadiferenciación entre las especificaciones y la implementación, y por lo tanto no es unbuen 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 unainterfaz 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 lascaracterísticas de transmisión en el alambre de cobre, la fibra óptica y la comunicacióninalámbrica) y la capa de enlace de datos (encargada de delimitar el inicio y el fin de losmarcos y transferirlos de un lado a otro con el grado deseado de confiabilidad) cuandoen realidad son completamente diferentes y por lo tanto ambas capas deberíanaparecer separadas en un modelo bien diseñado.

- Aunque los protocolos IP y TCP se diseñaron cuidadosamente, las implementacionesde 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 problemasde 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 hadesarrollado totalmente). Por las siguientes razones:

- TCP/IP se desarrolló antes que el protocolo OSI, por lo que las empresas implantaronTCP/IP mientras esperaban el protocolo OSI.

- La demanda de productos por parte del Departamento de Defensa de EEUU creó unmercado real muy importante (hay que tener en cuenta que es el primer consumidor desoftware del mundo).

- Internet utiliza TCP/IP. Algunos de los protocolos TCP/IP se han usado como la basepara 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 condetalle los protocolos de cada una de las capas. Hay que tener en cuenta que no hay un modelooficial de referencia TCP/IP.

Basándose en los protocolos que se han desarrollado, todas las tareas involucradas en lacomunicación se pueden organizar en cinco capas relativamente independientes. Un modelo decapas es una forma común de dividir un conjunto de protocolos. Ethernet se corresponde con elnivel 1 y parte del nivel 2, siendo independiente de TCP/IP, que es un conjunto de protocolosque 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 apunto, ya que facilitan la interacción entre los dos sistemas finales. La capa internet tiene algode 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, debenproporcionar 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. Elprotocolo básico es IP y permite enviar mensajes entre dos sistemas. UDP y TCP utilizan losmensajes 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 algunosprotocolos 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ásimportantes de cada una de las capas empezando por los niveles inferiores.

1.2.9 Protocolos de acceso a la red1.2.9.1 Protocolo ARP

El protocolo ARP (Address Resolution Protocol) definido en el RFC 826 [3], indica que las redesfísicas tienen sus propios esquemas de direccionamiento y hay tantos esquemas dedireccionamiento 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 unadirecció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 queno disponga de disco duro puede determinar su dirección IP?. El problema es crítico paraaquellas estaciones de trabajo que almacenan todos sus archivos en un servidor remoto ya queellas deben utilizar los protocolos de transferencia TCP/IP para obtener su imagen de arranqueinicial.

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 muestraen la figura 1.1

4



Send (o envío) seutiliza para solicitar latransmisión de unaunidad de datos.

Deliver (o entrega) lautiliza IP para avisar aun usuario la llegada deuna 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 devida no se encuentran presentes por proporcionar instrucciones IP que no deben ser utilizadaspor el receptor. El emisor puede incluir el campo tipo de servicio para solicitar una calidad deservicio particular. La tabla 1.1 muestra las opciones que hay de calidad de servicio

PRECEDENCIAUna medida de la importancia relativa del datagrama. Se utilizan ochoniveles de precedencia. IP tratará de proporcionar un tratamientopreferencial a los datagramas con precedencias superiores.

SEGURIDADSe puede especificar uno de dos niveles: normal o alta. Un valor alto indicauna petición para que se intente minimizar la probabilidad de que estedatagrama se pierda o resulte dañado.

RETARDO Se puede especificar uno de dos niveles: normal o bajo. Un valor bajo indica

una petición para minimizar el retardo que experimentará este datagrama.RENDIMIENTO

Se puede especificar uno de dos niveles: normal o alto. Un valor alto indicauna 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 quenormalmente 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 datoscuyo 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 lafigura 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 cuyalongitud será de 32 bits, que será utilizada en los campos dirección origen y dirección destino dela cabecera. Esta dirección consta de un identificador de red y de un identificador decomputador. La dirección, como puede verse en la figura 1.3 , está codificada para permitir unaasignación variable de los bits utilizados al especificar la red y el computador. Este formato dedirecciones permite mezclar las tres clases de direcciones en el mismo conjunto de redes. Ladirecció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 campode 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áncodificadas para permitir una asignación variable de bits para especificar la red y lacomputadora.

– Clase A: Pocas redes, cada una con muchos clientes. 7 y 24 bits (+1). Por ejemploARPANET.

– Clase B: Un número medio de redes, cada una con un número medio de clientes. 14 y 16bits (+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 amúltiples clientes. Es posible enviar un paquete IP a un grupo de máquinas que por ejemplopueden estar cooperando de alguna manera mediante la utilización de una dirección degrupo.

– 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 tresclases primarias de direcciones IP:

CLASE BITS EN EL

PREFIJO

MAXIMO

Nº DE REDES

BITS EN EL

SUFIJO

MAXIMO Nº DE

CLIENTES POR REDA 7 128 24 16777216

B 14 16384 16 65536

C 21 2097152 8 256Tabla 1.2. Número de redes y hosts por clase.

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

Observando la tabla 1.2 puede verse que no todas las direcciones han sido asignadas a unaclase 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 esusada 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 sunú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 laclase 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 comodirecció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 distanteponiendo 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. Lospaquetes que tienen esta dirección no son enviados por la red sino que son procesadoslocalmente y se tratan como si fueran paquetes de entrada. Esto permite que los paquetesse envíen a la red local sin que el transmisor conozca su número. Esta característicatambié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 cadared. En este caso recibe el nombre de “multihomed”. Esto se utiliza para aumentar la seguridadpues si una red falla el sistema aún esta conectado a Internet utilizando la otra red. Por otraparte, 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 ydispositivos de encaminamiento que están conectados en tres redes diferentes: a una TokenRing de clase C, a una Ethernet de clase B y a una red de clase A, en concreto Arpanet. Para lainterconexió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 algunosinconvenientes:

– 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 nopermiten que una red física tenga múltiples direcciones, no se pueden introducir nuevasdirecciones 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 lotanto tenga dos direcciones diferentes, y que el encaminamiento se hace teniendo en cuentala dirección IP, el comportamiento de los paquetes puede ser totalmente diferentedependiendo de la dirección que se esté utilizando. Esto puede resultar sorprendente paralos usuarios.

– En algunos casos, el conocer una dirección IP puede resultar insuficiente para alcanzar lamá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 ladirección del siguiente dispositivo de encaminamiento teniendo en cuenta la dirección IP destinoque hay almacenada en el campo correspondiente del paquete y de la información que hayalmacenada en las tablas de encaminamiento. Hay que tener en cuenta que es necesariorealizar una conversión entre la dirección IP y la dirección MAC (cuando el enlace entre los dosdispositivos de encaminamiento sea una LAN) que se efectúa de manera automática medianteel protocolo ARP.

Esta tabla puede ser estática o dinámica. En el primer caso puede contener rutas alternativasque 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 tablastambién pueden proporcionar servicios de seguridad y de prioridad, por ejemplo, paraasegurarse 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 secomentó, el sistema origen incluye en la cabecera del paquete la dirección de los dispositivosde 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 interesanteconsiderar que un conjunto de computadoras forman una red independientes, pero queexternamente se vea a todas como una sola red. La manera de hacerlo consiste en subdividir elcampo 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 ladirección física de la otra. Cuando se envía un paquete IP entre estas dos máquinas sólo seindica la dirección IP. Por lo tanto es necesario tener un mecanismo que proporcione lacorrespondencia 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, lacorrespondiente dirección física. Cada entrada de la tabla contiene una dirección IP y unadirección física. Como existe una tabla para cada red física, todas las direcciones IP tienen elmismo 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 labúsqueda se puede hacer secuencialmente, si es gran se pueden utilizar técnicas de hashing ode indexación directa. Esta última sólo es posible si el rango de direcciones es compacto puesen otro caso se desaprovecharían muchas posiciones de memoria.

El segundo realiza la traducción mediante una función matemática. Aunque muchas tecnologíasutilizan direcciones físicas estáticas, algunas usan direccionamiento configurable, es decir, eladministrador de la red elige tanto la dirección física como la dirección IP. En este caso, losvalores 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 dossistemas 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 principalventaja de este diseño es que es centralizado y por lo tanto fácil de configurar, gestionar ycontrolar.

En el segundo diseño, se hace un broadcast de la petición y todas las computadoras participanen la resolución de la dirección, en concreto responde el que tiene la dirección pedida. Laprincipal ventaja de este diseño es que el cálculo es distribuido. Una de las ventajas de estemétodo sobre tener unos archivos de configuración es su sencillez. El propio protocolo seencarga 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 orientadosa la aplicación y los niveles orientados a la red dentro de la jerarquía de protocolos TCP/IP. Seencargan de ocultar a los niveles altos del sistema el tipo de tecnología a la que se esténconectando 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 einferior: 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 laaplicació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 detransporte puede llevar información de diferentes aplicaciones y éstas son identificadas por elpuerto.Para establecer una comunicación entre dos máquinas, se ha de utilizar uno de los protocolosde transporte (TCP o UDP) y es necesario conocer tanto el puerto que identifica la aplicacióndestino 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 delnivel de transporte. Los bytes que se transmiten en el TCP reciben el nombre de segmento TCPy 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 clienteinicia la comunicación y para hacerlo necesita conocer la dirección IP asignada a lacomputadora, 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) yel puerto que identifica su aplicación cliente. Para que pueda saber el puerto destino queidentifica la aplicación deseada, se utilizan los llamados puertos conocidos, que consisten en unnú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 eldatagrama 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 sedetecta 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 existeindependientemente del resto de datagramas UDP.

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

Las características del protocolo UDP son las siguientes:

- No garantiza la fiabilidad. No es posible asegurar que cada datagrama UDP transmitidollegue 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 laaplicación los reciban.

- No preserva la secuencia de la información que proporciona la aplicación. Lainformación se puede recibir desordenada (como ocurría en IP) y la aplicación debeestar preparada por si se pierden datagramas, llegan con retardo o llegandesordenados.

1.2.10.2 Cabecera TCP

La unidad de datos de este protocolo recibe el nombre de segmento TCP. Como la cabeceradebe implementar todos los mecanismos del protocolo su tamaño es bastante grande, comomí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 RemoteProcedure Call de SUN. El núcleo del sistema operativo de la máquina cliente esmodificado con un nuevo tipo de sistema de archivo NFS, de manera que cuando unprograma intenta abrir, cerrar, leer o escribir en un archivo remoto, el código NFS esllamado en lugar del código “normal” para acceder a los manejadores de los discosfísicos. El código del sistema de archivos NFS usa el protocolo RPC de SUN paracomunicar con el código servidor NFS que se ejecuta en la máquina remota, leyendo oescribiendo bloques de archivos en él.

- SNMP (Simple network management protocol) [5]: SNMP es un protocolocliente/servidor que normalmente es usado para configurar y monitorear remotamentelos equipos de la red Internet. Este protocolo se basa en el protocolo UDP. Enterminología SNMP es descrito como un protocolo manager/agent.

- DNS (Domain Name Server, usualmente en el puerto 53) [6]: El servicio de nombres dedominio (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 dedirecciones sigue una estructura jerárquica. Para hacer mas sencillo el acceso a lossistemas, cada sistema puede tener asignados uno o varios nombres de dominio DNS,que son identificadores descriptivos que permiten hacer referencia al equipo y equivalena 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 quecorresponden con la organización o empresa a la que pertenece el sistema. Cuando enun comando se introduce un nombre de máquina, el sistema siempre convierte esenombre en una dirección IP antes de establecer la conexión. Desde la máquina quenecesita saber la dirección IP, se envía un paquete UDP a un servidor DNS, que buscael nombre y devuelve la dirección IP. Con la dirección IP, el programa puede entoncesestablecer 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 lainformación sobre el remitente, el destinatario, datos adicionales y naturalmente elcuerpo 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 enviarloa 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 alos 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 clientelocal de una máquina con el servidor con el que se comunica. Los caracteres que seteclean 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 lapantalla local. Este protocolo fue uno de los primeros que se definió y ha sido diseñadopara trabajar con terminales de modo texto. Se implementa en dos módulos. El módulocliente relaciona el módulo de entrada y salida del terminal para que puedacomunicarse con el terminal local. Convierte las características de los terminales realescon los standards de las redes y viceversa. El módulo servidor interactua con unaaplicación, de manera que los terminales remotos sean vistos por la aplicación comoterminal local.

- FTP (File Transfer Protocol, usualmente en el puerto 21) [11]: Permite la transferenciade 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 ypermisos sobre los archivos. Hay un control de acceso de los usuarios, y cuando unusuario quiere realizar la transferencia de un archivo, el FTP establece una conexiónTCP para el intercambio de mensajes de control. De esta manera se puede enviar elnombre de usuario, el password, los nombres de los archivos y las acciones que sequieren realizar. Una vez se ha aceptado la transferencia del archivo, una segundaconexión TCP se establece para la transferencia de datos. El archivo se transfieresobre la conexión de datos, sin la utilización de ninguna cabecera o información decontrol en la capa de aplicación. Cuando se completa la transferencia, la conexión decontrol 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 clientesweb 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ónmultimedia 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 lassolicitudes de conexión de los clientes Web, y una vez que se establece la conexión, elprotocolo TCP se encarga de mantener la comunicación y garantizar un intercambio dedatos libre de errores [13].

- SSH (Secure SHell, usualmente en el puerto 22): Es el nombre de un protocolo y delprograma que lo implementa. Este protocolo sirve para acceder a máquinas remotas atravé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 mediode comunicación vaya de manera no legible y ninguna persona pueda descubrir elusuario y contraseña de la conexión ni lo que se escribe durante toda la sesión; aunquees 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 tipoterminal de texto, aunque puede redirigir el tráfico para poder ejecutar programasgrá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 losdatos de cualquier otra aplicación por un canal seguro de SSH (esto sólo si se tieneacceso como administrador a ambas máquinas). La primera versión del protocolo y elprograma eran libres y los creó un sueco llamado Tatu Ylönen, pero su licencia fuecambiando y terminó apareciendo la compañía `SSH Communications Security', que loofrecía gratuitamente para uso doméstico y académico, pero exigía el pago a otrasempresas. A principios de 1999 se empezó a escribir una versión que se convertiría enla 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. Unaspecto avanzado sobre este tema es el de la seguridad de las redes. Si bien existen variaspropuestas al respecto, una herramienta que se ha popularizado ampliamente es el firewall quese 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 debever 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. Inclusopuede 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 unsistema operativo que filtra el y decide si un paquete pasa, se modifica, se convierte o sedescarta.

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 usopara proteger una red local conectada a internet a través de un dispositivo encaminador. Elfirewall 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 paraestablecer distintos perímetros de seguridad en torno a un sistema. Es frecuente también quese 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 aellos. 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 estaarquitectura, se permite que el servidor sea accesible desde Internet de tal forma que si esatacado y se gana acceso a él, la red local sigue protegida por el firewall. Esta estructura deDMZ puede hacerse también con un doble firewall (aunque como se ve se puede usar un únicodispositivo con al menos tres interfaces de red). Sería un esquema como el que se muestra enla 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 interneten las empresas, aunque ahí también suelen tener una doble función: controlar los accesosexternos hacia dentro y también los internos hacia el exterior; esto último se hace con el firewallo 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 lafigura 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 lasque se examina el origen y destino de los paquetes del protocolo TCP/IP. En cuanto aprotocolos 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 ACEPTARTodo lo que venga de la ip de mi casa al puerto tcp 22 ACEPTARTodo lo que venga de la ip de casa del jefe al puerto tcp 1723 ACEPTARTodo lo que venga de hora.rediris.es al puerto udo 123 ACEPTAR

Todo lo que venga de la red local y vaya al exterior ENMASCARARTodo lo que venga del exterior al puerto tcp 1 al 1024 DENEGAR

14



Todo lo que venga del exterior al puerto tcp 3389 DENEGARTodo 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 computadorade 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 lospuertos 1 y 1024.

1.3.2 Implementación

- Política por defecto ACEPTAR: en principio todo lo que entra y sale por el firewall seacepta y solo se denegará lo que se diga explícitamente.

- Política por defecto DENEGAR: todo esta denegado, y solo se permitirá pasar por elfirewall aquellos que se permitan explícitamente.

Como es obvio imaginar, la primera política facilita mucho la gestión del firewall, ya quesimplemente 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 unamá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 yaestá.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 nose conozca que determinados paquetes ICMP son peligrosos. Si la política por defecto esACEPTAR 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, elfirewall se convierte en un auténtico muro infranqueable. El problema es que es mucho másdifícil preparar un firewall así, y hay que tener muy claro como funciona el sistema (seaiptables 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 sedomina el sistema. Uno de los objetos principales de este documento es mostrar la forma decrear este tipo de firewalls.

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

En el presente trabajo de tesis se utilizó un firewall llamado IPTables que viene incluido dentrodel 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 extendidoenormemente 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 puedacaer por un error de programación, puesto que iptables al estar integrado con el kernel, es partedel sistema operativo. Para ponerlo en funcionamiento basta aplicar reglas. Para ello seejecuta el comando iptables, con el que se añaden, borran o modifican reglas. Por ello unfirewall de iptables no es sino un script de shell en el que se van ejecutando las reglas defirewall.

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 vanpasando, y decide la suerte del paquete completo. Podría decidirse descartarlo (DROP) (estoes, como si nunca lo hubiera recibido), aceptarlo (ACCEPT) (dejar que pase), o cosas máscomplicadas.

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, yrestringir otros.

- Seguridad cuando una máquina Linux es lo único Internet y una red interna, se puederestringir el tráfico de entrada.

- Vigilancia sobre todo el tráfico que entra y sale de un firewall, puesto que a vecesciertas máquinas mal configuradas podrían enviar información hacia lugares nodeseados.

De lo que se desprende que IPTables es una herramienta adecuada para construir firewallspara Internet basados en filtrado de paquetes con o sin estado, implementar NAT paracompartir 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 depaquetes véase [17].

Finalmente, como se mencionó anteriormente, el proceso de arranque de IPTables es sencillo ybasta con crear un script de shell que introduzca las reglas deseadas. Es por ello que acontinuació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 operativoencargada de ejecutar las órdenes básicas para el manejo del sistema. También denominadoshell . 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 necesitaser 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 cadainstrucción escrita con una semántica “humana” a código máquina (instrucciones de la CPU delordenador), 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 seencarga de automatizar algunas de las tareas típicas de un programador como declaracionesde 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 delsistema operativo, ya que no contiene instrucciones propias de un procesador sino que contienellamadas a funciones que el intérprete deberá reconocer. Basta que exista un intérprete de unlenguaje para dicho sistema y todos los programas escritos en ese lenguaje podrán ejecutarseen ese sistema.

Además, un lenguaje interpretado permite modificar en tiempo de ejecución el código que seestá 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 cadavez.

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

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

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

1.5.3 BASH

Bash es un Intérprete de comandos de tipo Unix (shell ) escrito para el proyecto GNU. Sunombre 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 Unidosautodenominados "Born again Christians". La sintaxis de comandos de Bash mantiene, en granmedida, la compatibilidad con sh, e incluye ideas tomadas desde ksh y csh, como son elhistorial de comandos, la pila de directorios, la variable $RANDOM, y la forma POSIX desustitució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 scriptsen 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 susredes 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 loshackers. De cualquier modo, sirven como una capa extra de seguridad que frecuentementeinhibe 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 seguridadestablecidas por las organizaciones en cuestión por lo que muchos administradoressimplemente 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 losusuarios.

Otro escenario se presenta cuando un host debe conectarse a Internet, como es el caso de losfirewalls 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 elque 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 eICMP (entre otros), lo cual hace prácticamente imposible la autenticación a nivel de usuario, yaque esa es responsabilidad de la aplicación en sí y no del protocolo; y establecer este tipo deautenticación resultaría altamente costoso puesto que entonces el firewall debería ser capaz dedesensamblar los paquetes e indagar en su contenido, lo cual sería una falta a la privacidad dela información.

La idea es no exponer servicios específicos como accesos remotos por SSH o incluso sistemasde administración remota basados en web hasta que alguna persona autorizada gane el accesoy 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 “PortKnocking”. [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 deknocks o llamados a los puertos. Dicho llamado es una serie de intentos de conexión a puertoscerrados que un cliente remoto genera y envía a fin de manipular las reglas del firewall delservidor para abrir uno o más puertos específicos. Estos intentos de conexión son detectadospor un demonio que el servidor ejecuta y que monitorea al firewall, a fin de traducirlos ensecuencias de llamados de autenticación. Una vez que los puertos deseados se abren, elcliente 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 elsistema en un servidor y uno o varios clientes. Por tanto, el sistema operativo en el que se llevea 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 unfirewall mediante el cual se tengan cerrados los 65535 puertos admisibles y que sea losuficientemente 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 demonitorear el firewall en la búsqueda de ciertas secuencias de intentos de conexión, de maneraque lo más simple es buscar esos intentos de manera interactiva en el archivo de bitácoras delsistema. Por tanto, el sistema operativo deberá proveer de las facilidades para que el firewallescriba 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 seriede secuencias válidas dependiendo del usuario que desee conectarse. Por consecuencia elsistema 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 losusuarios del sistema. Cabe destacar que los usuarios necesariamente deberán concordar conlos 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étodosnecesarios para la encriptación de cadenas a fin de obtener las secuencias (passwords) fueradel alcance de los usuarios internos.

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

La autenticación posterior la llevará a cabo la aplicación que esté escuchando en el puertoindicado. En este trabajo de tesis se trabajó preferentemente con los accesos al puerto TCP 22de 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 elacceso independientemente de que la conexión se lleve a cabo o no eliminando la regla quegarantiza la entrada. Con lo cual se evitará la necesidad de diseñar un sistema que monitoree lafinalización de las sesiones.

La ejecución de los pasos anteriores no deberá afectar en modo alguno las conexionesestablecidas previamente (en caso de existir alguna) por lo que es deseable establecer unaregla 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 enred.

La aplicación cliente deberá ser capaz de solicitar al usuario su login y password de manerainteractiva, así como la dirección IP del servidor y el puerto del servicio al cual se deseaconectar. De esto se desprende que el sistema operativo del cliente deberá permitir la ejecuciónde 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ónpropia del sistema como sería el caso de telnet o netcat. De aquí que el sistema operativodeberá tener presentes estos programas así como una facilidad para generar la secuencia dellamadas.

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 queposteriormente 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 accesoal sistema correrá totalmente a cargo de la aplicación que se encuentre a la escucha del puertodeseado, 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, quequedará a cargo del propio sistema operativo anfitrión; por lo que tanto este proceso como el dedesconexió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 basetanto del servidor como del cliente se utilice GNU/Linux por sus bien conocidas capacidadesinherentes al trabajo en red, soporte multiusuario, multitarea y de multiprocesamiento, así comode 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/Linux3. Puede modificar, dar de alta y baja reglas de manera flexible.

4. Tiene la capacidad de modificar sus comportamiento sin necesidad de ser reiniciado5. Puede escribir en archivos de bitácoras mediante syslogd6. 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, enespecífico de bash en virtud de sus capacidades [19] y [20]:

2. Incluido por defecto en el sistema operativo GNU/Linux3. Monitoreo interactivo y filtrado de archivos de texto con los comandos watch, tail y grep4. 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ásde una aplicación auxiliar para el servidor que generará la base de datos de los usuariosregistrados.

2.3.1 Diseño del servidor

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

– 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íneade comandos, por medio del comando getopts1. En caso de que alguno se encuentrepresente, el sistema leerá y validará los valores obtenidos, y en caso de ser correctos, lospondrá 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 losusuarios 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 cadauno. Esto tiene la ventaja de que las secuencias se generan una sola vez, por lo que el sistemano necesita recalcularla, lo que puede resultar contraproducente puesto que para que elsistema reconozca un nuevo usuario o bien que reconozca un cambio de contraseña esnecesario que se reinicie. Sin embargo, dado el carácter experimental de este proyecto, se haoptado por esta técnica.

El proceso de la carga en memoria de las contraseñas de usuarios se esquematiza en la figura2.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 usuariose 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 laencargada 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 quepermitan llevar a cabo la lectura de las líneas del archivo de bitácora, conforme se agregan almismo. 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 relevantespara TOCHTLI, es necesario hacer un filtrado de selección de los datos de interés, es decir, senecesita 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 cadenade identificación serán aquellas registradas por el firewall, por lo tanto, son los únicos sujetos deinteré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 relevanciacomo son el IP fuente y el puerto destino. Es decir, la dirección IP de la cual provienen losintentos 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 lasecuencia de llamados realizada por un IP específico, lo cual es el concepto fundamental delport 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 enun periodo de tiempo válido, es decir, no deben transcurrir más allá de dos segundos entre larecepció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 queTOCHTLI revisa que no exista un procesamiento simultáneo de la misma dirección IP. Siresulta que el IP ya está siendo procesado simplemente se omitirá esta nueva secuencia. Encaso contrario, se procederá al siguiente paso que es la comparación de las secuenciasentrantes 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 lamisma dirección IP. Como se describió con anterioridad, la validez de una secuencia se dejatotalmente 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 delsistema.

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

En caso de encontrar una coincidencia plena con alguna de las secuencias, el sistema seencargará 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, y2. 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 lasecuencia validada. Con una regla de este tipo se garantiza que únicamente pasetráfico para establecer una nueva conexión.

Hecho lo cual, TOCHTLI entrará en una etapa de suspensión de 10 segundos que es tiemposuficiente 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 detráfico de solicitud de conexión y restablecerá la regla mediante la cual el puerto 22 se cierra atodo tipo de tráfico.

La permanencia de esta nueva sesión así como de las ya establecidas se garantiza por mediode la regla que permite el tráfico tipo “establecido”. Por tanto, este proceso será totalmentetransparente 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 unarelació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, elpassword y el puerto al que se desea acceder para generar la secuencia de llamados alservidor, 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 establecenel valor del periodo de espera entre el envío de la secuencia y el intento de establecimiento desesión con el servidor.

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

La última parte del proceso consiste en la creación de una cadena que se usará como semillapara 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 16números de puerto que conforman la secuencia de llamados mediante un algoritmo que sebasa en la multiplicación del valor de un contador por el valor de una subcadena de dos dígitosde la cadena de suma.

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

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

Finalmente el cliente entra en una etapa de suspensión de dos segundos que se otorgan alservidor 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ípicamentese solicitara la atención de un servidor SSH que escucha en el puerto 22. Este comportamientopuede 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 delsistema, 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 puedagenerar 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 deusuarios. Cabe mencionar que esta aplicación está programada en shell script, lo mismo quelas aplicaciones servidor y cliente.

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

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

28



3. Pruebas e implementación.

En las secciones siguientes se explicarán todos los pasos que deben llevarse a cabo, tanto dellado 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ágenestomadas 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 sistemaoperativo GNU/Linux Slackware 10.1. Se usaron dos computadoras como clientes y una para elservidor 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.3Tabla 3.2 Direcciones IP de las computadoras utilizadas en las pruebas

En primera instancia, deben crearse usuarios para TOCHTLI en el equipo Servidor; esto sehace 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, puesestas 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 formatohh:mm:ss.nanosegundos.

El siguiente paso, es ejecutar la aplicación servidor (tochtlid). Para este ejemplo se utilizan lospará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 TOCHTLITabla 3.4. Parámetros aceptados por tochtlid .

Para este ejemplo, también se muestran en la figura 3.2 los tiempos ocupados para llevar acabo la generación de la secuencia válida de llamados para cada uno de los usuarios, así comola 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 lospasswords (SUMAS , por ser sumas md5), los logins de los usuarios (USERS ) y las secuenciasde puertos seguros (sec_ports).

De acuerdo con el diseño de tochtlid , la siguiente fase se refiere a la inserción de las reglas deiptables para cerrar todos los puertos, proceso que tardó en la máquina Servidor 10898000nanosegundos. Al finalizar este proceso, las reglas del firewall quedaron como se muestra en lafigura 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 lospuertos 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 quehace 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 partede sus clientes. A continuación se explicará el proceso que los clientes llevan a cabo paraconectarse 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 inicialesel login para tochtlid y la dirección IP del servidor. A continuación tochtli pedirá el password paragenerar la secuencia candidata. Este proceso se muestra en las figuras 3.7 y 3.8 para Cliente1y Cliente2 respectivamente; así como el tiempo de creación de dicha secuencia y la secuenciaen 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 lafigura 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 secuenciaválida generada por tochtlid , en cambio el usuario jjimenez escribió un password erróneo, por loque 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 lafigura 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 primeraque se encuentre, lo cual podría resultar en un comportamiento no deseado de la aplicación. Uncomportamiento similar podría suceder cuando se requiriese eliminar al usuario. En este últimocaso 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á ycomparará 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 lasecuencia 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 lacomparació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 alpuerto 22, lo que sugiere que el tiempo de espera entre el envío de la secuencia candidata y elintento de conexión del cliente es quizás demasiado corto y quizás se deba incrementar almenos un segundo más. De cualquier modo, tochtlid solamente hará caso de los primeros 16llamados 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 elcliente establezca la conexión.

La figura 3.12 muestra que al transcurrir el periodo de espera se intenta la conexión por ssh lacual resulta exitosa. Esto se sabe en vista de la aparición del prompt del cliente de sshsolicitando 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 deaceptació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 medianteuna 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 quellegaron las 16 llamadas, tochtlid no pudo otorgar el acceso al sistema en virtud de que lassecuencias 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 lopermitirá. Para que pueda hacer otro intento satisfactorio, el cliente deberá esperar a quetranscurran 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 figura3.17, en la que se presenta el proceso se recepción y comparación de la secuencia candidata ysu 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 ambienteTCP/IP, basándose en el concepto de Port Knocking. Esta técnica establece los mecanismospara 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 decómputo que hace las veces de Servidor y dos equipos más que hacen el papel de Clientes. Secerraron todos los puertos TCP del equipo servidor y se diseñó un mecanismo para lageneración de secuencias de llamados (port knocking).

Nuestros experimentos fueron realizados, usando únicamente el puerto 22 como puerto deentrada. 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, elpuerto 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 comoprueba del concepto de port knocking, no se recomienda para implantación en un servidor deproducción debido a la alta carga de tráfico que debe soportar, de manera que habría queencontrar un método más rápido de hacer la lectura de los llamados de secuencia. Sobre estosería deseable desarrollar un sistema que no utilice lenguajes interpretados como el caso dellenguaje C.

En este mismo orden de ideas, sería deseable incorporar el uso de librerías especializadaspara la captura y análisis de paquetes directamente de la pila TCP/IP, como es el caso delibnet, ya que brindaría mayor velocidad al sistema, puesto que como se sabe que el acceso alsistema de archivos es más lento que a la memoria. Inclusive, si se desea continuar con eldiseño planteado en este trabajo sería recomendable que el archivo de bitácoras se encontraseen 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 ReiserFSpresenta problemas de pérdida de datos en ambientes en los que la alimentación eléctrica fallecontinuamente.

Otro problema de seguridad se presenta en virtud de que el presente trabajo solamente se basaen la dirección IP del solicitante. Esto resulta peligroso cuando alguna entidad externa falsificala identidad de la máquina original mediante una técnica llamada IP spoofing (sustitución deidentidad). Una posible solución que no resulta muy práctica es la de agregar la dirección físicade la interfaz de red a los datos almacenados en tusers, lo cual conlleva problemas demantenimiento 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 revisionescorrespondientes.

Así mismo, un aspecto importante a considerar es que por la naturaleza del port knocking, essensible a una variante del ataque DDoS (Distributed Denial of Service o negación de serviciodistribuido), en el cual se envía un número muy grande de paquetes con la opción SYN activadaen tiempos relativamente largos. Generalmente los ataques tipo DoS (Denial of Service onegación de servicio) o DDoS comunes pueden contrarrestarse activando las syn_cookies en elnúcleo del sistema, puesto que evitan el consumo excesivo de recursos del sistema a la llegadade paquetes SYN en tiempos cortos. Ante esto podría incluso plantearse la posibilidad demodificar las reglas del firewall para limitar el arribo de paquetes en un lapso de tiempodeterminado, pero esto podría incluso bloquear los intentos reales de conexión llevandonuevamente a un problema de DoS. Según el diseño presentado en este trabajo, existe otrotipo peligro puesto que se escribe un registro por cada paquete recibido, el archivo de bitácoraspuede crecer hasta alcanzar el tamaño máximo de la partición que lo contenga, causando queotras aplicaciones que hagan uso de él se encuentren imposibilitadas de hacerlo o incluso queno 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 susvariantes, 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 nocorrespondiesen con los del sistema operativo, aunque también provocaría que los usuariostuviesen que recordar dos logins y dos passwords, lo que en términos reales no es muy prácticoya que la tendencia de los usuarios es la de escribir esos datos sensibles en algún lugar pocoseguro, 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 secuenciascandidatas 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 deconexión, lo cual acarrearía una mejora en el diseño de la aplicación, en el sentido de quedeberá mejorarse los procesos de generación y comparación de secuencias válidas ycandidatas.

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 lossistemas 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 lossistemas o viceversa. El hecho es que no importa que se utilice el sistema operativo másseguro 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 TaskForce. Noviembre de 1982. [Online] http://www.ietf.org/rfc/rfc0826.txt?number=826

[4] Sun Microsystems. NFS: Network File System Protocol Specification. Internet EngineeringTask 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 NetworkManagement 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. InternetEngineering 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 TaskForce. Agosto de 1982. [Online] http://www.ietf.org/rfc/rfc0821.txt?number=821

[8] David H. Crocker. STANDARD FOR THE FORMAT OF ARPA INTERNET TEXTMESSAGES. 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 de1980. [Online] http://www.ietf.org/rfc/rfc0764.txt?number=764

[10] J. Postel, J. Reynolds.TELNET PROTOCOL SPECIFICATION. Internet ENgineering TaskForce. Mayo de 1983. [Online] http://www.ietf.org/rfc/rfc0854.txt?number=854

[11] J. Postel, J. Reynolds. FILE TRANSFER PROTOCOL (FTP). Internet Engineering TaskForce. 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. InternetEngineering 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. SANSInstitute. 2005. [Online]. http://techrepublic.com.com/5100-1009-5798871.html

[23] Maddock B. Port Knocking: An overview of Concepts, Issues and Implementations. SANSInstitute. 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

Tochtli: Una implementación de la prueba de concepto de port knocking

Documents

Transcript of Tochtli: Una implementación de la prueba de concepto de port knocking