BENEMÉRITA UNIVERSIDAD AUTÓNOMA DE PUEBLA

FACULTAD DE CIENCIAS DE LA COMPUTACIÓN

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

TESIS QUE PARA OBTENER EL TÍTULO DE LICENCIADO EN CIENCIAS DE LA COMPUTACIÓN

PRESENTA: ALFREDO CAMPOS ENRÍQUEZ DIRECTOR: MC DAVID EDUARDO PINTO AVENDAÑO

Puebla, 2005

Agradecimientos
A mi asesor MC David Eduardo Pinto Avendaño, por todo el apoyo brindado durante el desarrollo de este trabajo y por su valiosa contribución para su realización. A mis jurados: MC Hilda Castillo Zacatelco y Dr Manuel Martín Ortiz, por sus contribuciones efectivas a este trabajo y por su gran disposición. Y a todos aquellos que lo consideren necesario.

Dedicatorias
A mi mamá.

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

I

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

IV

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

IV

Introducción
En el presente trabajo de tesis se presenta un sistema experimental a manera de prueba de concepto de Port Knocking que hace las veces de mecanismo para el filtrado de accesos no deseados en un ambiente TCP/IP. El método más común entre las organizaciones es la

instalación de un firewall, ya sea de hardware o software. Lamentablemente aún no poseen medidas de protección contra el tráfico no deseado como los virus, los troyanos y los hackers. Los firewalls realizan filtrado de datos a nivel de protocolos como TCP, UDP e ICMP (entre otros), imposibilitando la autenticación a nivel de usuario, ya que esa es responsabilidad de la aplicación en sí. Antes de que una conexión sea establecida, los puertos se abren mediante una secuencia de knocks o llamados a los puertos. Dicho llamado es una serie de intentos de conexión a puertos cerrados que un cliente remoto genera y envía a fin de manipular las reglas del firewall del servidor para abrir uno o más puertos específicos. El análisis realizado sobre el escenario anterior sugirió el diseño de tres aplicaciones: una para servidor, otra para cliente y una más que sirve para generar usuarios para este sistema. Finalmente se hace una revisión detallada de las pruebas realizadas, así como de los resultados arrojados.

IV

1. Marco teórico
1.2.Visión general de la red Internet 1.1.1 ¿Qué es Internet? Internet es una enorme red de comunicaciones de ámbito mundial que permite la interconexión de sistemas informáticos, independientemente de su tipo y situación [1]. Está físicamente compuesta por computadoras de diversos tipos, marca y sistema operativo y ruteadores que están distribuidos por todo el mundo y unidos a través de enlaces de comunicaciones muy diversos. Sobre éstos, aprovechando los servicios de comunicaciones de la red, se ejecutan diversos tipos de aplicaciones, que permiten realizar intercambios de información. La interconexión física se alcanza mediante una red heterogénea: redes de área local (normalmente Ethernet), MAN, enlaces nacionales, enlaces internacionales y redes telefónicas. Sobre esta red física es necesario que las computadoras tengan un software de comunicaciones, que permitan el intercambio de información entre los diferentes puntos. Para que los diferentes sistemas puedan entenderse es necesario tener un lenguaje común que sea independiente del tipo de sistema operativo. Esta diversidad provoca numerosos problemas de entendimiento, que se resuelven con el empleo de diferentes protocolos de comunicaciones. 1.1.2 ARPANET Las redes de comunicaciones entre computadores y autopistas de la información han evolucionado desde la red ARPANET hasta la actual Internet. A finales de los 60, los científicos de la empresa RAND, quienes realizaban una investigación para el Departamento de Defensa de los Estados Unidos, propusieron la tecnología de conmutación de paquetes. Esta tecnología fue originalmente concebida para asegurar el funcionamiento de la red en la fase del ataque nuclear. Así la agencia de proyectos de investigación avanzados del Departamento de Defensa (DoD), construyó en 1969 Arpanet, la primera red de datos del mundo. El primer nodo se creó en la Universidad de California (Los Ángeles). A pesar de que la red fue originalmente diseñada para soportar computadores centrales de tiempo compartido, posteriormente los usuarios comenzaron a disfrutar de otras aplicaciones como el correo electrónico, la transferencia de archivos y la posibilidad de trabajar con archivos compartidos. Esta red era de conmutación de paquetes y estaba basada en un conjunto de pequeños dispositivos interconectados llamados procesadores de mensajes con interfaz (IMPs). Estos IMP’s, los precursores de los modernos ruteadores, ofrecieron encaminamiento y almacenamiento. El éxito de Arpanet fue el ser el catalizador para la investigación en la red dando como resultado un protocolo de emergencia: el TCP/IP, el cual se estableció firmemente en 1980. Arpanet completó su transición al TCP/IP en 1983, y en 1990 dejó de ser la espina dorsal (backbone) de la red Internet. 1.1.3 INTERNET En 1986, la National Science Foundation de Estados Unidos, comenzó el desarrollo de una espina dorsal de alta velocidad llamada NSFnet, para conectar los centros de súper cómputo de la nación. A medida que fue creciendo la demanda del ancho de banda de esta espina dorsal, la NSF dio origen a Merit en una muy productiva unión con MCI e IBM, para desarrollar una espina dorsal de 1.5 Mbps. NSFnet, que enlazó los sitios de súper cómputo, comenzó a servir como el mayor soporte entre redes, dando origen a la red Internet, que por supuesto reemplazó a la red Arpanet. Fuera de la Merit, surgió una nueva corporación sin ánimo de lucro para redes avanzadas y servicios: la ANS. Esta corporación, fue inicialmente responsable del desarrollo de la espina dorsal de redes y servicios de la NSF a 45 Mbps, la red TCP/IP mas veloz del mundo. La red Internet, nació en los años 1990, creciendo desde mas o menos 500.000 hosts hasta mas de 10 millones que había en 1996 [1]. Actualmente el número de nodos es mucho mayor

1

cada día. La World Wide Web, desarrollada por el CERN [1] (Laboratorio Europeo de Física Nuclear), ha sido la mayor fuerza cercana al exponencial crecimiento de la red Internet. 1.2 Modelo de referencia TCP/IP TCP/IP es el nombre que normalmente se da al conjunto de protocolos que se utilizan para la comunicación a través de Internet. Fue el primer conjunto de protocolos desarrollados para ser usados en Internet. Estos protocolos se definen en base a RFCs (Request For Comment) que se encuentran disponibles públicamente en la misma Internet [2]. 1.2.1 Historia del TCP/IP Los trabajos en TCP/IP empezaron en la década de los 70 [2], aproximadamente al mismo tiempo que se empezaban a desarrollar las redes de área local. El ejercito americano gracias al proyecto ARPA (Advanced Research Projects Agency) invirtió muchos recursos en investigar el TCP/IP y en la interconexión de redes. Fueron unas de las primeras organizaciones que tuvo varias redes y por lo tanto de las primeras que se encontraron con la necesidad de tener servicios universales. La capacidad de conectar entre sí múltiples redes de manera transparente fue uno de los primeros objetivos de diseño. 1.2.2 Consideraciones de diseño Debido a la preocupación del Departamento de Defensa por que alguno de sus costosos nodos de la red pudiera ser objeto de un atentado en cualquier momento, otro de los objetivos principales fue que la red fuera capaz de seguir funcionando sin que las comunicaciones existentes se interrumpieran si algunos de los dispositivos de hardware fallaba. La idea era que las comunicaciones permanecieran intactas mientras las máquinas origen y destino estuvieran funcionando, aunque algunas de las máquinas o de las líneas de transmisión en el trayecto dejara de funcionar de forma repentina. Por otra parte, debido a que se estaban pensando en aplicaciones que tuvieran diferentes requerimientos, se necesitaba que la arquitectura fuera flexible. 1.2.3 Características del TCP/IP Las características principales del protocolo TCP/IP son:

-

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

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

2

1.2.4.1 Capa de Internet Aunque algunas capas del modelo de referencia TCP/IP se corresponden con capas del modelo de referencia OSI descrito en un tema anterior, el esquema de capas OSI no tiene ninguna capa que corresponda con la capa internet del modelo TCP/IP. Esto se debe a que el modelo OSI se definió antes de que se inventara el internetworking, por lo que este modelo no contiene ninguna capa para los protocolos internet. 1.2.4.2 Capa de Sesión Además, el modelo OSI dedica una capa completa para los protocolos de sesión, que han perdido mucha importancia a medida que las computadoras han cambiado desde sistemas de tiempo compartido a estaciones de trabajo. Por este motivo, los investigadores que diseñaron TCP/IP inventaron un nuevo modelo de capas. 1.2.4.3 Comunicación orientada y no orientada a la conexión Otra diferencia se encuentra en el área de comunicación no orientada a la conexión frente a la orientada a la conexión. El modelo OSI considera ambos tipos, pero en la capa de transporte donde es más importante (porque el servicio de transporte es visible al usuario) lo hace únicamente con la comunicación orientada a la conexión. El modelo TCP/IP en la capa de red sólo tiene el modo sin conexión pero considera ambos modos en la capa de transporte, ofreciendo una alternativa a los usuarios. Esta elección es importante sobre todo para los protocolos simples de petición y respuesta. 1.2.5 Problemas del modelo TCP/IP El modelo TCP/IP tiene algunos problemas que se mencionan a continuación: Como ya se ha comentado anteriormente, este modelo no distingue con claridad los conceptos de servicio, interfaz y protocolo. En el modelo TCP/IP no se hace una diferenciación entre las especificaciones y la implementación, y por lo tanto no es un buen ejemplo para construir redes nuevas. Otra limitación del modelo es que no es general y no se puede utilizar para describir otra pila de protocolos. La capa de acceso a la red no es una capa en el sentido estricto sino que es una interfaz entre la red y la capa de enlace de datos. En este modelo, no se distingue entre la capa física (que tiene que ver con las características de transmisión en el alambre de cobre, la fibra óptica y la comunicación inalámbrica) y la capa de enlace de datos (encargada de delimitar el inicio y el fin de los marcos y transferirlos de un lado a otro con el grado deseado de confiabilidad) cuando en realidad son completamente diferentes y por lo tanto ambas capas deberían aparecer separadas en un modelo bien diseñado. Aunque los protocolos IP y TCP se diseñaron cuidadosamente, las implementaciones de otros grupos de investigación se distribuían gratuitamente, como la de BSD o POSIX que se utilizan mucho y por lo tanto son difíciles reemplazar aunque tuvieran problemas de diseño.

-

-

1.2.6Aplicación del modelo de referencia TCP/IP tiene una implantación mayor aplicación que el modelo OSI (el cual nunca se ha desarrollado totalmente). Por las siguientes razones: TCP/IP se desarrolló antes que el protocolo OSI, por lo que las empresas implantaron TCP/IP mientras esperaban el protocolo OSI. La demanda de productos por parte del Departamento de Defensa de EEUU creó un mercado real muy importante (hay que tener en cuenta que es el primer consumidor de software del mundo). Internet utiliza TCP/IP. Algunos de los protocolos TCP/IP se han usado como la base para los estándares ISO. Además, como todas las especificaciones asociadas a los

3

protocolos TCP/IP son de dominio público han sido usados extensivamente por autoridades comerciales y públicos para crear entornos de redes abiertos. 1.2.7 Capas del modelo de referencia TCP/IP En este apartado se define brevemente este nuevo modelo para posteriormente explicar con detalle los protocolos de cada una de las capas. Hay que tener en cuenta que no hay un modelo oficial de referencia TCP/IP. Basándose en los protocolos que se han desarrollado, todas las tareas involucradas en la comunicación se pueden organizar en cinco capas relativamente independientes. Un modelo de capas es una forma común de dividir un conjunto de protocolos. Ethernet se corresponde con el nivel 1 y parte del nivel 2, siendo independiente de TCP/IP, que es un conjunto de protocolos que también funciona sobre otros tipos de redes. Las capas físicas y de acceso a la red proporcionan la interacción entre el sistema final y la red, mientras que las capas de aplicación y transporte albergan los protocolos denominados punto a punto, ya que facilitan la interacción entre los dos sistemas finales. La capa internet tiene algo de las dos aproximaciones anteriores. En esta capa, los sistemas origen y destino proporcionan a la red la información necesaria para realizar el encaminamiento, pero a la vez, deben proporcionar algunas funciones adicionales de intercambio entre los dos sistemas finales. El modelo de referencia TCP/IP consta principalmente de tres protocolos: IP, UDP y TCP. El protocolo básico es IP y permite enviar mensajes entre dos sistemas. UDP y TCP utilizan los mensajes del nivel IP para construir un diálogo más complejo entre las computadoras. En el modelo TCP/IP el uso de todas las capas no es obligatorio, por ejemplo, hay algunos protocolos de la capa de aplicación que operan directamente sobre IP. 1.2.8 Protocolos del modelo de referencia Una vez visto como se estructura esta pila de protocolos, se describirán brevemente los más importantes de cada una de las capas empezando por los niveles inferiores. 1.2.9 Protocolos de acceso a la red 1.2.9.1 Protocolo ARP El protocolo ARP (Address Resolution Protocol) definido en el RFC 826 [3], indica que las redes físicas tienen sus propios esquemas de direccionamiento y hay tantos esquemas de direccionamiento como redes físicas. Se conoce la dirección Ethernet, sin embargo para enviar el paquete se debe conocer la dirección IP, pues la red física no entiende las direcciones IP. El protocolo ARP realiza dos funciones: la primera es dada una dirección IP obtener una dirección física cuando se envía un paquete y la segunda función consiste en contestar peticiones realizadas por otras máquinas. 1.2.9.2 Protocolo RARP Cada máquina, además de su dirección física que está en la tarjeta de red, debe tener guardada en algún dispositivo la dirección IP que le corresponde. ¿Pero cómo una máquina que no disponga de disco duro puede determinar su dirección IP?. El problema es crítico para aquellas estaciones de trabajo que almacenan todos sus archivos en un servidor remoto ya que ellas deben utilizar los protocolos de transferencia TCP/IP para obtener su imagen de arranque inicial.

1.2.9.3 El protocolo de Internet IP 1.2.9.3.1 Servicios básicos En el nivel IP hay dos primitivas de servicio en la interfaz con la capa superior como se muestra en la figura 1.1

4

Send (o envío) se utiliza para solicitar la transmisión de una unidad de datos.

Deliver (o entrega) la utiliza IP para avisar a un usuario la llegada de una unidad de datos.

Figura 1.1. Primitivas de servicio en la interfaz de IP. En la primitiva Deliver, los parámetros identificador, indicador de no fragmentación y tiempo de vida no se encuentran presentes por proporcionar instrucciones IP que no deben ser utilizadas por el receptor. El emisor puede incluir el campo tipo de servicio para solicitar una calidad de servicio particular. La tabla 1.1 muestra las opciones que hay de calidad de servicio Una medida de la importancia relativa del datagrama. Se utilizan ocho PRECEDENCIA niveles de precedencia. IP tratará de proporcionar un tratamiento preferencial a los datagramas con precedencias superiores. Se puede especificar uno de dos niveles: normal o alta. Un valor alto indica SEGURIDAD una petición para que se intente minimizar la probabilidad de que este datagrama se pierda o resulte dañado. Se puede especificar uno de dos niveles: normal o bajo. Un valor bajo indica RETARDO una petición para minimizar el retardo que experimentará este datagrama. Se puede especificar uno de dos niveles: normal o alto. Un valor alto indica RENDIMIENTO una petición para maximizar el rendimiento para este datagrama. Tabla 1.1. Opciones de calidad de servicio. Los parámetros de opciones permiten ampliaciones futuras y la inclusión de parámetros que normalmente no se utilizan. Actualmente están definidas las siguientes opciones:
– – – – –

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

1.2.9.3.2 Datagramas IP El formato de los datagramas IP consiste en una parte de cabecera y en una parte de datos cuyo tamaño es variable. 1.2.9.3.2.1 Cabecera En la cabecera hay una parte fija de 20 bytes y una parte opcional de longitud variable. En la figura 1.2 se puede ver el formato de la cabecera IP.

5

Figura 1.2. Formato de la cabecera IP 1.2.9.3.3 Direcciones IP Cada computadora y cada dispositivo de encaminamiento tendrán una dirección única cuya longitud será de 32 bits, que será utilizada en los campos dirección origen y dirección destino de la cabecera. Esta dirección consta de un identificador de red y de un identificador de computador. La dirección, como puede verse en la figura 1.3 , está codificada para permitir una asignación variable de los bits utilizados al especificar la red y el computador. Este formato de direcciones permite mezclar las tres clases de direcciones en el mismo conjunto de redes. La dirección IP más pequeña es la 0.0.0.0 y la mayor es 255.255.255.255. Existen tres clases de redes que se pueden clasificar teniendo en cuenta la longitud del campo de red y del campo de la computadora. La clase a la que pertenece una dirección puede ser determinada por la posición del primer 0 en los cuatro primeros bits. Las direcciones están codificadas para permitir una asignación variable de bits para especificar la red y la computadora.
– – – –

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

6

Figura 1.3. Dirección IP codificada La tabla 1.2 muestra el número de redes y de computadoras por red en cada una de las tres clases primarias de direcciones IP: CLASE BITS EN EL PREFIJO A 7 B 14 C 21 MAXIMO BITS EN EL MAXIMO Nº DE Nº DE REDES SUFIJO CLIENTES POR RED 128 24 16777216 16384 16 65536 2097152 8 256 Tabla 1.2. Número de redes y hosts por clase.

Normalmente las direcciones se suelen escribir en notación decimal con puntos. Por ejemplo, la dirección 82CE7C0D (1000 0010 1100 1110 0111 1100 0000 1101 que es de clase B) se escribe como 130.206.124.13. Observando la tabla 1.2 puede verse que no todas las direcciones han sido asignadas a una clase en concreto. Algunas de estas direcciones se utilizan como direcciones especiales (ver figura 1.4):

– – – –

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

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

7

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

Figura 1.5. Esquema de interconexión de diferentes clases de redes. El que la dirección de la red esté guardada en la dirección Internet tiene algunos inconvenientes:

Si la dirección IP identifica la red a la que se conecta el sistema, no al cliente que está conectado, no es posible asignarle una dirección IP permanente. Por lo tanto, si se mueve físicamente una computadora de una red a otra su dirección IP debe cambiar. – Como el número de máquinas asignadas a la clase C (255) puede resultar insuficiente en muchos casos y que la transición a la clase B no es fácil debido a que muchos programas no permiten que una red física tenga múltiples direcciones, no se pueden introducir nuevas direcciones poco a poco y es necesario reconfigurar toda la red para la nueva clase. – Como existe la facilidad de que una máquina pueda estar conectada a dos redes y por lo tanto tenga dos direcciones diferentes, y que el encaminamiento se hace teniendo en cuenta la dirección IP, el comportamiento de los paquetes puede ser totalmente diferente dependiendo de la dirección que se esté utilizando. Esto puede resultar sorprendente para los usuarios. – En algunos casos, el conocer una dirección IP puede resultar insuficiente para alcanzar la máquina que utiliza esta dirección 1.2.9.3.4 Encaminamiento Cuando un paquete llega a un dispositivo de encaminamiento se debe determinar cual es la dirección del siguiente dispositivo de encaminamiento teniendo en cuenta la dirección IP destino que hay almacenada en el campo correspondiente del paquete y de la información que hay almacenada en las tablas de encaminamiento. Hay que tener en cuenta que es necesario realizar una conversión entre la dirección IP y la dirección MAC (cuando el enlace entre los dos dispositivos de encaminamiento sea una LAN) que se efectúa de manera automática mediante el protocolo ARP. Esta tabla puede ser estática o dinámica. En el primer caso puede contener rutas alternativas que serán utilizadas cuando algún dispositivo de encaminamiento no esté disponible. Las tablas dinámicas son más flexibles cuando aparecen errores o congestión en la red. Estas tablas también pueden proporcionar servicios de seguridad y de prioridad, por ejemplo, para asegurarse que a ciertos datos no se les permita pasar por determinadas redes.

8

Otra técnica de encaminamiento es el encaminamiento en la fuente. En este caso, como ya se comentó, el sistema origen incluye en la cabecera del paquete la dirección de los dispositivos de encaminamiento que debe utilizar el paquete. 1.2.9.3.5 Subredes El que todos los clientes de una red deban tener el mismo número de red puede causar problemas. A medida que aumenta la utilización de las redes locales puede ser interesante considerar que un conjunto de computadoras forman una red independientes, pero que externamente se vea a todas como una sola red. La manera de hacerlo consiste en subdividir el campo correspondiente a la identificación de la máquina en dos subcampos, uno para la subred (por ejemplo de 6 bits) y otro para los sistemas (que deberá tener 10 bits). 1.2.9.3.6 Resolución de direcciones Dos computadoras de una red física sólo pueden comunicarse si cada uno de ellas conoce la dirección física de la otra. Cuando se envía un paquete IP entre estas dos máquinas sólo se indica la dirección IP. Por lo tanto es necesario tener un mecanismo que proporcione la correspondencia entre la dirección IP y la dirección física. El problema de traducir las direcciones de alto nivel en direcciones físicas recibe el nombre de “address resolution”. Existen tres mecanismos para hacerlo: El primero utiliza una tabla en cada máquina para almacenar, para cada dirección IP, la correspondiente dirección física. Cada entrada de la tabla contiene una dirección IP y una dirección física. Como existe una tabla para cada red física, todas las direcciones IP tienen el mismo prefijo. La principal ventaja de este mecanismo es su generalidad. Cuando se quiere obtener una dirección, si el número de entradas de la tabla es pequeño la búsqueda se puede hacer secuencialmente, si es gran se pueden utilizar técnicas de hashing o de indexación directa. Esta última sólo es posible si el rango de direcciones es compacto pues en otro caso se desaprovecharían muchas posiciones de memoria. El segundo realiza la traducción mediante una función matemática. Aunque muchas tecnologías utilizan direcciones físicas estáticas, algunas usan direccionamiento configurable, es decir, el administrador de la red elige tanto la dirección física como la dirección IP. En este caso, los valores pueden ser elegidos para que la traslación sea trivial. El tercero es el más interesante pues usa una computación distribuida en la que los dos sistemas intercambian mensajes dinámicamente. Existen dos posibles diseños: En el primero hay uno o más servidores que se encargan de enviar las respuestas. La principal ventaja de este diseño es que es centralizado y por lo tanto fácil de configurar, gestionar y controlar. En el segundo diseño, se hace un broadcast de la petición y todas las computadoras participan en la resolución de la dirección, en concreto responde el que tiene la dirección pedida. La principal ventaja de este diseño es que el cálculo es distribuido. Una de las ventajas de este método sobre tener unos archivos de configuración es su sencillez. El propio protocolo se encarga de construir las tablas en lugar de tener que hacerlo el administrador del sistema. 1.2.10 Los protocolos de transporte Los protocolos de transporte tienen la función de actuar de interfaz entre los niveles orientados a la aplicación y los niveles orientados a la red dentro de la jerarquía de protocolos TCP/IP. Se encargan de ocultar a los niveles altos del sistema el tipo de tecnología a la que se estén conectando las computadoras. En la jerarquía de TCP/IP se definen dos protocolos de transporte: el UDP y el TCP. El UDP es

9

un protocolo no orientado a la conexión mientras que el TCP es orientado a la conexión. Se definen dos direcciones para relacionar el nivel de transporte con los niveles superior e inferior: La dirección IP y el puerto. La dirección IP es la dirección que identifica un dispositivo dentro de una red. El puerto es un número de 16 bits que se coloca en cada paquete y sirve para identificar la aplicación que requiere la comunicación. La utilidad de los puertos es que permite multiplexar aplicaciones sobre protocolos del nivel de transporte. Es decir, un mismo protocolo de transporte puede llevar información de diferentes aplicaciones y éstas son identificadas por el puerto. Para establecer una comunicación entre dos máquinas, se ha de utilizar uno de los protocolos de transporte (TCP o UDP) y es necesario conocer tanto el puerto que identifica la aplicación destino como la dirección IP que identifica el terminal o el servidor dentro del conjunto de redes. Los datos que se envían durante la comunicación son empaquetados por los protocolos del nivel de transporte. Los bytes que se transmiten en el TCP reciben el nombre de segmento TCP y los que se transmiten en el UDP el de datagrama UDP. Para establecer una comunicación se utiliza el modelo cliente/servidor. En este caso, el cliente inicia la comunicación y para hacerlo necesita conocer la dirección IP asignada a la computadora, al servidor y al puerto de la aplicación que identifica la aplicación que se quiere utilizar. El cliente conoce su dirección IP (dirección origen), la dirección del servidor (dirección destino) y el puerto que identifica su aplicación cliente. Para que pueda saber el puerto destino que identifica la aplicación deseada, se utilizan los llamados puertos conocidos, que consisten en un número de puerto reservado para identificar una aplicación determinada. El servidor responderá a las peticiones de cualquier cliente. Como el cliente envía en el datagrama UDP y en el segmento TCP tanto el puerto origen como el destino, el servidor conoce el puerto origen una vez que ha recibido una petición. 1.2.10.1 El protocolo UDP Este protocolo es no orientado a la conexión, y por lo tanto no proporciona ningún tipo de control de errores ni de flujo, aunque sí utiliza mecanismos de detección de errores. Cuando se detecta un error en un datagrama en lugar de entregarlo a la aplicación se descarta. Como el protocolo es no orientado a la conexión cada datagrama UDP existe independientemente del resto de datagramas UDP. El protocolo UDP es muy sencillo y tiene utilidad para las aplicaciones que requieren pocos retardos o para ser utilizado en sistemas sencillos que no pueden implementar el protocolo TCP. Las características del protocolo UDP son las siguientes: No garantiza la fiabilidad. No es posible asegurar que cada datagrama UDP transmitido llegue a su destino. Es un protocolo del tipo best-effort porque hace lo que puede para transmitir los datagramas hacia la aplicación, pero no puede garantizar que la aplicación los reciban. No preserva la secuencia de la información que proporciona la aplicación. La información se puede recibir desordenada (como ocurría en IP) y la aplicación debe estar preparada por si se pierden datagramas, llegan con retardo o llegan desordenados.

-

1.2.10.2 Cabecera TCP La unidad de datos de este protocolo recibe el nombre de segmento TCP. Como la cabecera debe implementar todos los mecanismos del protocolo su tamaño es bastante grande, como mínimo 20 bytes. En la figura 1.6 se puede ver el formato de la cabecera TCP.

10

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

-

-

1.2.10.3.2 Protocolos que usan TCP

-

-

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

11

-

-

-

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

Hasta este punto se han comentado los aspectos básicos de la comunicación en Internet. Un aspecto avanzado sobre este tema es el de la seguridad de las redes. Si bien existen varias propuestas al respecto, una herramienta que se ha popularizado ampliamente es el firewall que se comentará a continuación. 1.3 Firewalls 1.3.1. ¿Qué es un firewall? Un firewall es un dispositivo que filtra el tráfico entre redes, como mínimo dos [15]. El firewall puede ser un dispositivo físico o un software sobre un sistema operativo. En general se debe ver como una caja con dos o más interfaces de red en la que se establecen una reglas de

12

filtrado con las que se decide si una conexión determinada puede establecerse o no. Incluso puede ir más allá y realizar modificaciones sobre las comunicaciones, como el NAT. Esa sería la definición genérica, hoy en día un firewall es un hardware específico con un sistema operativo que filtra el y decide si un paquete pasa, se modifica, se convierte o se descarta.

Figura 1.7. Topología clásica de un firewall En la figura 1.7 se muestra la tipología clásica de un firewall en donde se esquematiza su uso para proteger una red local conectada a internet a través de un dispositivo encaminador. El firewall debe colocarse entre el ruteador (con un único cable) y la red local (conectado al switch o al hub de la LAN). Dependiendo de las necesidades de cada red, puede ponerse uno o más firewalls para establecer distintos perímetros de seguridad en torno a un sistema. Es frecuente también que se necesite exponer algún servidor a Internet (como es el caso de un servidor web, un servidor de correo, etc.), y en esos casos obviamente en principio se debe aceptar cualquier conexión a ellos. Lo que se recomienda en esa situación es situar ese servidor en un lugar aparte de la red, el que se denomina DMZ o zona desmilitarizada. El firewall tiene entonces tres entradas (ver figura 1.8):

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

13

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

Figura 1.10. Esquema de un ISP. Sea el tipo de firewall que sea, generalmente no tendrá mas que un conjunto de reglas en las que se examina el origen y destino de los paquetes del protocolo TCP/IP. En cuanto a protocolos es probable que sean capaces de filtrar muchos tipos de ellos, no solo los TCP, también los UDP, los ICMP y otros protocolos vinculados a VPNs. Este podría ser (en pseudolenguaje) un el conjunto de reglas de un firewall de la figura 1.7: Politica por defecto ACEPTAR. Todo lo que venga de la red local al firewall ACEPTAR Todo lo que venga de la ip de mi casa al puerto tcp 22 ACEPTAR Todo lo que venga de la ip de casa del jefe al puerto tcp 1723 ACEPTAR Todo lo que venga de hora.rediris.es al puerto udo 123 ACEPTAR Todo lo que venga de la red local y vaya al exterior ENMASCARAR Todo lo que venga del exterior al puerto tcp 1 al 1024 DENEGAR

14

Todo lo que venga del exterior al puerto tcp 3389 DENEGAR Todo lo que venga del exterior al puerto udp 1 al 1024 DENEGAR En definitiva lo que se hace es: - Habilitar el acceso a puertos de administración a determinadas IPs privilegiadas. - Enmascarar el trafico de la red local hacia el exterior (NAT, una petición de una computadora de la LAN sale al exterior con la IP pública), para poder salir a Internet - Negar el acceso desde el exterior a puertos de administración y a todo lo que este entre los puertos 1 y 1024. 1.3.2 Implementación Política por defecto ACEPTAR: en principio todo lo que entra y sale por el firewall se acepta y solo se denegará lo que se diga explícitamente. Política por defecto DENEGAR: todo esta denegado, y solo se permitirá pasar por el firewall aquellos que se permitan explícitamente.

Como es obvio imaginar, la primera política facilita mucho la gestión del firewall, ya que simplemente debe preocuparse de proteger aquellos puertos o direcciones que se sabe sond e interés; el resto no importa tanto y se deja pasar. Por ejemplo, si se desea proteger una máquina Linux, podemos hacer un netstat -ln (o netstat -an, o netstat -aptu | grep LISTEN), saber que puertos están abiertos, poner reglas para proteger esos puertos y ya está. El único problema que se puede tener es que no se controle qué es lo que esta abierto, o que en un momento dado se instale un software nuevo que abra un puerto determinado, o que no se conozca que determinados paquetes ICMP son peligrosos. Si la política por defecto es ACEPTAR y no se protege explícitamente, puede resultar peligroso. En cambio, si la política por defecto es DENEGAR, a no ser que se permita explícitamente, el firewall se convierte en un auténtico muro infranqueable. El problema es que es mucho más difícil preparar un firewall así, y hay que tener muy claro como funciona el sistema (sea iptables o el que sea) y que es lo que se tiene que abrir sin caer en la tentación de empezar a insertar reglas super-permisivas. Esta configuración de firewall es la recomendada, aunque no es aconsejable usarla si no se domina el sistema. Uno de los objetos principales de este documento es mostrar la forma de crear este tipo de firewalls. El orden en el que se ponen las reglas de firewall es determinante. Normalmente cuando hay que decidir que se hace con un paquete, se va comparando con cada regla del firewall hasta que se encuentra una que le afecta (match), y se hace lo que dicte esta regla (aceptar o denegar); después de eso no se buscarán más reglas para ese paquete. En peligro consiste en colocar reglas muy permisivas entre las primeras del firewall, lo cual puede ocasionar que las siguientes no se apliquen y no sirvan de nada. En el presente trabajo de tesis se utilizó un firewall llamado IPTables que viene incluido dentro del sistema operativo GNU/Linux que se describirá en la siguiente sección. 1.4 IPTables IPtables es un sistema de firewall vinculado al kernel de linux que se ha extendido enormemente a partir del kernel 2.4 de este sistema operativo [15]. Al igual que el anterior sistema ipchains, un firewall de iptables no es como un servidor que se inicie o que se pueda caer por un error de programación, puesto que iptables al estar integrado con el kernel, es parte del sistema operativo. Para ponerlo en funcionamiento basta aplicar reglas. Para ello se ejecuta el comando iptables, con el que se añaden, borran o modifican reglas. Por ello un firewall de iptables no es sino un script de shell en el que se van ejecutando las reglas de firewall.

15

1.4.1 Características - Filtrado de paquetes sin estado para IPv4 e IPv6. - Filtrado de paquetes con estado para IPv4 - Traducción de puertos y direcciones de red de todo tipo. - Infraestructura flexible y extensible. - Capas múltiples de API’s y extensiones de terceras partes. - Un gran número de módulos adicionales 1.4.2 Filtrado de paquetes Un filtro de paquetes es un software que examina la cabecera de los paquetes según van pasando, y decide la suerte del paquete completo. Podría decidirse descartarlo (DROP) (esto es, como si nunca lo hubiera recibido), aceptarlo (ACCEPT) (dejar que pase), o cosas más complicadas. Con el filtrado de paquetes se gana:

-

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

De lo que se desprende que IPTables es una herramienta adecuada para construir firewalls para Internet basados en filtrado de paquetes con o sin estado, implementar NAT para compartir accesos a Internet o para implementar proxys transparentes y hasta crear encaminadores que soporten políticas de QoS (Calidad de servicio). Para mayor información sobre IPTables consulte [16] y sobre los conceptos de filtrado de paquetes véase [17]. Finalmente, como se mencionó anteriormente, el proceso de arranque de IPTables es sencillo y basta con crear un script de shell que introduzca las reglas deseadas. Es por ello que a continuación se discutirá brevemente lo que es el shell scripting. 1.5 Scripts de Shell 1.5.1 Intérprete de comandos Un intérprete de comandos se define como la parte fundamental de un sistema operativo encargada de ejecutar las órdenes básicas para el manejo del sistema. También denominado shell. Suelen incorporar características tales como control de procesos, redirección de entrada/salida y un lenguaje de órdenes para escribir programas por lotes o scripts. 1.5.2 Programas de procesamiento por lotes o scripts Los lenguajes interpretados forman un subconjunto de los lenguajes de programación.

A diferencia de los lenguajes compilados, en los lenguajes interpretados el código no necesita ser preprocesado mediante un compilador, eso significa que el ordenador es capaz de ejecutar la sucesión de instrucciones dadas por el programador sin necesidad de leer y traducir exhaustivamente todo el código.

16

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

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

La principal ventaja de un lenguaje interpretado es que es independiente de la máquina y del sistema operativo, ya que no contiene instrucciones propias de un procesador sino que contiene llamadas a funciones que el intérprete deberá reconocer. Basta que exista un intérprete de un lenguaje para dicho sistema y todos los programas escritos en ese lenguaje podrán ejecutarse en ese sistema.

Además, un lenguaje interpretado permite modificar en tiempo de ejecución el código que se está ejecutando así como añadirle algo nuevo que resulta práctico cuando se desea hacer pequeñas modificaciones en una aplicación y no es deseable tener que recompilarla toda cada vez.

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

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

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

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

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

17

Bash se distribuye bajo los términos de la Licencia General GNU. Está disponible para ser descargado desde muchos sitios en Internet, incluyendo el sitio FTP del proyecto GNU. Una referencia más detallada de bash se puede encontrar en [18]. Así mismo, pueden encontrarse tutoriales muy buenos sobre la programación de shell scripts en bash en [19] y [20].

18

2 Análisis y diseño
2.1 Planteamiento del problema. Los firewalls son hasta ahora una medida de seguridad para que las organizaciones aíslen sus redes del acceso desde Internet. Ya sea que se trate de un firewall de hardware o software, aún no poseen medidas de protección contra el tráfico no deseado como los virus, los troyanos y los hackers. De cualquier modo, sirven como una capa extra de seguridad que frecuentemente inhibe la administración adecuada de un sistema o un dispositivo de red. [21] Lamentablemente, el garantizar estos accesos causa conflictos con las políticas de seguridad establecidas por las organizaciones en cuestión por lo que muchos administradores simplemente niegan todo acceso a los servicios del sistema de cómputo por medio del firewall. Esta práctica es frecuentemente más simple que establecer las reglas necesarias o efectuar cambios frecuentes sobre las políticas de seguridad o los límites sobre las cuentas de los usuarios. Otro escenario se presenta cuando un host debe conectarse a Internet, como es el caso de los firewalls basados en sistemas Unix, en virtud de que el propio host hace las veces de firewall. Una manera de mejorar la seguridad en dichos servidores es la de establecer un esquema en el que se habiliten ciertos servicios después de establecer algún método de identificación. El problema radica en que la función básica de un firewall, como se explicó en el primer capítulo, es la de filtrar tráfico. Dicho filtrado se hace a nivel de protocolos como TCP, UDP e ICMP (entre otros), lo cual hace prácticamente imposible la autenticación a nivel de usuario, ya que esa es responsabilidad de la aplicación en sí y no del protocolo; y establecer este tipo de autenticación resultaría altamente costoso puesto que entonces el firewall debería ser capaz de desensamblar los paquetes e indagar en su contenido, lo cual sería una falta a la privacidad de la información. La idea es no exponer servicios específicos como accesos remotos por SSH o incluso sistemas de administración remota basados en web hasta que alguna persona autorizada gane el acceso y se permita una entrada temporal a la dirección IP de la cual proviene la conexión. Para resolver este problema se propone la implementación de una técnica llamada “Port Knocking”. [22] Una definición propuesta por Martin Krzywinsky es: “Port knocking es un método de establecer una conexión a una computadora en red que no tiene puertos abiertos”. [23] Antes de que la conexión sea establecida, los puertos se abren mediante una secuencia de knocks o llamados a los puertos. Dicho llamado es una serie de intentos de conexión a puertos cerrados que un cliente remoto genera y envía a fin de manipular las reglas del firewall del servidor para abrir uno o más puertos específicos. Estos intentos de conexión son detectados por un demonio que el servidor ejecuta y que monitorea al firewall, a fin de traducirlos en secuencias de llamados de autenticación. Una vez que los puertos deseados se abren, el cliente remoto puede establecer la conexión y comenzar una sesión. La definición de una secuencia de llamadas es arbitraria y se deja a criterio del implementador. 2.2. Análisis de requerimientos. En virtud de la naturaleza inherente del port knocknig, se plantea la necesidad de dividir el sistema en un servidor y uno o varios clientes. Por tanto, el sistema operativo en el que se lleve a cabo la implementación deberá tener las capacidades de trabajar en red y de soportar múltiples usuarios.

19

2.2.1 Consideraciones en el lado del servidor Siguiendo la definición de port knocking se debe partir de un sistema que tenga incorporado un firewall mediante el cual se tengan cerrados los 65535 puertos admisibles y que sea lo suficientemente flexible como para permitir la modificación de las reglas en cualquier momento. Como se explicó en el apartado anterior, se desea construir un sistema que sea capaz de monitorear el firewall en la búsqueda de ciertas secuencias de intentos de conexión, de manera que lo más simple es buscar esos intentos de manera interactiva en el archivo de bitácoras del sistema. Por tanto, el sistema operativo deberá proveer de las facilidades para que el firewall escriba a un archivo de bitácora y que permita la lectura filtrada e interactiva del texto. Una vez encontrada una secuencia, el sistema debe ser capaz de compararla contra una serie de secuencias válidas dependiendo del usuario que desee conectarse. Por consecuencia el sistema debe soportar el manejo de múltiples usuarios, cada uno con su respectiva contraseña (secuencia de knocks). De lo se desprende la necesidad de un subsistema para otorgar secuencias válidas para los usuarios del sistema. Cabe destacar que los usuarios necesariamente deberán concordar con los usuarios propios del sistema operativo en cuanto al nombre del usuario (login), pero no para la contraseña. En virtud de lo cual, el sistema operativo deberá proveer de los métodos necesarios para la encriptación de cadenas a fin de obtener las secuencias (passwords) fuera del alcance de los usuarios internos. Al encontrar la secuencia válida para un usuario determinado, el sistema deberá modificar las reglas del firewall, de manera que permita la conexión a la dirección IP de la cual proviene la secuencia válida. Este proceso se deberá llevar a cabo insertando una regla que permita lo anterior. La autenticación posterior la llevará a cabo la aplicación que esté escuchando en el puerto indicado. En este trabajo de tesis se trabajó preferentemente con los accesos al puerto TCP 22 de SSH. Por consiguiente, el sistema operativo deberá soportar la incorporación de un servidor de SSH. Finalizado el periodo válido de conexión el sistema deberá eliminar la regla que permita el acceso independientemente de que la conexión se lleve a cabo o no eliminando la regla que garantiza la entrada. Con lo cual se evitará la necesidad de diseñar un sistema que monitoree la finalización de las sesiones. La ejecución de los pasos anteriores no deberá afectar en modo alguno las conexiones establecidas previamente (en caso de existir alguna) por lo que es deseable establecer una regla inmutable que permita el tráfico que haya establecido. 2.2.2 Consideraciones del lado del cliente Por parte del cliente de la aplicación, se requiere un sistema operativo que permita el trabajo en red. La aplicación cliente deberá ser capaz de solicitar al usuario su login y password de manera interactiva, así como la dirección IP del servidor y el puerto del servicio al cual se desea conectar. De esto se desprende que el sistema operativo del cliente deberá permitir la ejecución de programas interactivos, al menos en modo de línea de comandos. Una vez alimentado con estos datos, el cliente deberá generar la secuencia de llamados (knocking secuence) y enviarla al servidor de manera ordenada mediante alguna aplicación propia del sistema como sería el caso de telnet o netcat. De aquí que el sistema operativo deberá tener presentes estos programas así como una facilidad para generar la secuencia de llamadas. Después de enviar la secuencia, el cliente deberá esperar un periodo razonable de tiempo a fin de que el servidor procese los datos, y en su caso abra el puerto solicitado, para que posteriormente se lleva a cabo el intento de establecimiento de conexión.

20

En caso de que la autenticación del cliente haya sido exitosa, el proceso de garantizar el acceso al sistema correrá totalmente a cargo de la aplicación que se encuentre a la escucha del puerto deseado, en este caso SSH. Por lo que resulta claro mencionar que el sistema operativo deberá contar también con este comando. El mismo criterio del párrafo anterior se deberá aplicar al trabajo en la sesión establecida, que quedará a cargo del propio sistema operativo anfitrión; por lo que tanto este proceso como el de desconexión no serán de interés alguno para el servidor. 2.3 Diseño de la aplicación. A fin de cumplir con los requerimientos anteriores se propone que como sistema operativo base tanto del servidor como del cliente se utilice GNU/Linux por sus bien conocidas capacidades inherentes al trabajo en red, soporte multiusuario, multitarea y de multiprocesamiento, así como de su soporte para firewalls mediante iptables. [24] El firewall de elección es iptables puesto que: 2. 3. 4. 5. 6. Viene incorporado por defecto dentro del núcleo de GNU/Linux Puede modificar, dar de alta y baja reglas de manera flexible. Tiene la capacidad de modificar sus comportamiento sin necesidad de ser reiniciado Puede escribir en archivos de bitácoras mediante syslogd Puede marcar sus entradas en los archivos de bitácoras, es decir, sea posible distinguir las secuencias de llamados sin necesidad de hacer un exhaustivo filtrado de texto.

Por tanto, la elección natural es iptables [15] y [16]. Como lenguaje de programación se propone un lenguaje interpretado como Shell Script, en específico de bash en virtud de sus capacidades [19] y [20]: 2. 3. 4. 5. 6. 7. Incluido por defecto en el sistema operativo GNU/Linux Monitoreo interactivo y filtrado de archivos de texto con los comandos watch, tail y grep Pseudo encriptación de la información mediante las sumas md5 (md5sum). Acceso transparente al firewall mediante los comandos propios de iptables. Sencillez de implantación en cualquier sistema operativo que tenga incorporado bash. Acceso transparente a todos los comandos del sistema

Finalmente, la arquitectura de la propuesta se basa en el paradigma cliente-servidor. Además de una aplicación auxiliar para el servidor que generará la base de datos de los usuarios registrados. 2.3.1 Diseño del servidor El servidor, desde ahora conocido como tochtlid, divide su actividad en dos fases distintivas, a saber:
– –

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

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

Fase de inicialización

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

Busca los argumentos si es que alguno se insertó desde la línea de comando. Establece las reglas del firewall Carga en memoria las contraseñas de los usuarios y calculo de secuencias de llamado. Inicializa sus variables.

21

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

Figura 2.1. Fase de lectura de argumentos

Establecimiento de las reglas del firewall.

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

Carga en memoria las contraseñas de los usuarios.

A continuación el sistema deberá leer el archivo de base de datos de contraseñas de los usuarios de TOCHTLI, a fin de cargar en memoria tanto los nombres de usuario, como las
1

Para mayores referencias sobre los comandos de bash refiérase a Learning shell: http://www.linuxcommand.org/learning_the_shell.php

22

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

Figura 2.2. Esquema de la carga en memoria de las contraseñas de usuarios El algoritmo que se utiliza en el servidor para generar las secuencias válidas para cada usuario se observa en la figura 2.3:

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

23

2.3.1.1.4Inicialización de variables Finalmente se inician ciertas variables que el programa utilizará durante su ejecución, como por ejemplo: Periodo válido de conexión. IP asignado a la interfaz que se va a escuchar. Periodo de tiempo en el cual no se permite la conexión desde un IP que estableció conexión con anterioridad.

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

Figura 2.4. Fase de inicialización de TOCHTLI

Fase de Monitoreo

Quizás la parte más importante del servidor (tochtlid) es la fase del monitoreo, la cual es la encargada de: Monitorear el archivo de bitácora Seleccionar de las cadenas concordantes Descomponer de los registros de entrada. Verificar la validez para el IP Comparar las secuencias entrantes con las almacenadas en memoria Garantizar el acceso al servidor Cerrar el acceso una vez transcurrido el periodo válido de conexión

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

24

Figura 2.5. Fase de monitoreo. A continuación se describirán cada uno de estos procesos: 2.3.1.2.1 Monitoreo del archivo de bitácora Se comienza el proceso mediante la ejecución del comando watch con algunas opciones que permitan llevar a cabo la lectura de las líneas del archivo de bitácora, conforme se agregan al mismo. Estas opciones son follow y retry. A continuación el sistema entra en un ciclo infinito en el cual se llevan a cabo las funciones restantes. 2.3.1.2.2 Selección de las cadenas concordantes En virtud de que los resultados devueltos por el comando watch pudieran no ser relevantes para TOCHTLI, es necesario hacer un filtrado de selección de los datos de interés, es decir, se necesita buscar la cadena de identificación, que como se mencionó en secciones anteriores es, por defecto “TOCHTLI”. Las líneas de texto que se van agregando al archivo de bitácoras que contengan esta cadena de identificación serán aquellas registradas por el firewall, por lo tanto, son los únicos sujetos de interés para el sistema. Este filtrado se lleva a cabo por medio del comando grep. 2.3.1.2.3 Descomposición de las cadenas de entrada. Después de identificar las cadenas de interés, el sistema obtendrá los datos de relevancia como son el IP fuente y el puerto destino. Es decir, la dirección IP de la cual provienen los intentos de conexión y el puerto al cual intentan acceder. La importancia de estos datos radica en el hecho de que en base a ellos se detecta la secuencia de llamados realizada por un IP específico, lo cual es el concepto fundamental del port knocking.

25

2.3.1.2.4 Verificación de validez para el IP Para cada uno de los llamados que componen las secuencias se debe verificar que su arribo en un periodo de tiempo válido, es decir, no deben transcurrir más allá de dos segundos entre la recepción de cada uno de los llamados. En el caso de que el periodo de validez sea rebasado, el sistema regresará al inicio del ciclo de lectura. Esta no es la única verificación que se lleva a cabo, pues tiene lugar una segunda en la que TOCHTLI revisa que no exista un procesamiento simultáneo de la misma dirección IP. Si resulta que el IP ya está siendo procesado simplemente se omitirá esta nueva secuencia. En caso contrario, se procederá al siguiente paso que es la comparación de las secuencias entrantes con las almacenadas en memoria. 2.3.1.2.5 Comparación de las secuencias entrantes con las almacenadas en memoria Una secuencia válida para el sistema se compone de al menos 16 llamados provenientes de la misma dirección IP. Como se describió con anterioridad, la validez de una secuencia se deja totalmente a criterio del implementador. Al recibir al menos 16 llamados, el sistema tendrá una secuencia candidata que deberá comparar con cada una de las secuencias válidas generadas en la etapa de inicialización del sistema. Si se comparan todas las secuencias válidas sin encontrar una coincidencia plena entonces simplemente se desecharán y el proceso continuará nuevamente desde el principio del ciclo de lectura. En caso de encontrar una coincidencia plena con alguna de las secuencias, el sistema se encargará de garantizar el acceso al servidor. 2.3.1.2.6 Otorgamiento del acceso al sistema Este paso es simple y se realiza en dos pasos: 1. Se elimina la regla para cerrar el puerto 22, y 2. Se crea una nueva regla para permitir la entrada a los paquetes con bandera SYN activada dentro de la cabecera TCP desde la dirección IP de la cual proviene la secuencia validada. Con una regla de este tipo se garantiza que únicamente pase tráfico para establecer una nueva conexión. Hecho lo cual, TOCHTLI entrará en una etapa de suspensión de 10 segundos que es tiempo suficiente para que el usuario establezca una conexión. 2.3.1.2.7 Cerrado del puerto Al transcurrir este periodo de conexión, TOCHTLI eliminará la regla que permitió el acceso de tráfico de solicitud de conexión y restablecerá la regla mediante la cual el puerto 22 se cierra a todo tipo de tráfico. La permanencia de esta nueva sesión así como de las ya establecidas se garantiza por medio de la regla que permite el tráfico tipo “establecido”. Por tanto, este proceso será totalmente transparente para la nueva conexión así como para las establecidas con anterioridad. En virtud de que los cuatro procesos que se han explicado con anterioridad mantienen una relación muy estrecha, en la figura 2.6 se muestran:

26

Figura 2.6. Fase de monitoreo detallado. 2.3.2 Diseño del cliente La aplicación cliente es mucho más simple puesto que solamente se encarga de recibir parámetros de entrada tales como el nombre de usuario (login), la dirección IP del servidor, el password y el puerto al que se desea acceder para generar la secuencia de llamados al servidor, ejecutarlos y en su caso establecer la conexión. El proceso realizado por el cliente puede dividirse en tres fases: Solicitud de datos del usuario Generación y envío de la secuencia de llamados. Establecimiento de la conexión.

2.3.2.1 Solicitud de datos del usuario Esta es propiamente la fase de inicialización de la aplicación cliente, puesto que se establecen el valor del periodo de espera entre el envío de la secuencia y el intento de establecimiento de sesión con el servidor. Una parte de los datos se le proporcionan desde la línea de comandos (login y dirección IP del servidor). El resto (password y puerto de conexión), se solicitan de forma interactiva mediante el comando read. La última parte del proceso consiste en la creación de una cadena que se usará como semilla para la generación de la secuencia de llamados. Esta cadena se obtiene del resultado de la suma md5 de la concatenación del nombre de usuario y el password.

27

2.3.2.2 Generación y envío de la secuencia de llamados Una vez que se tiene la suma indicada en la sección anterior, se procede a obtener los 16 números de puerto que conforman la secuencia de llamados mediante un algoritmo que se basa en la multiplicación del valor de un contador por el valor de una subcadena de dos dígitos de la cadena de suma. Este mismo algoritmo se utiliza en la aplicación servidor para obtener las secuencias válidas para cada uno de los usuarios de TOCHTLI. Después se utiliza el programa definido para realizar los intentos de conexión para hacer los llamados a los puertos indicados. Finalmente el cliente entra en una etapa de suspensión de dos segundos que se otorgan al servidor para procesar los datos. Este proceso se muestra en la figura 2.7:

Figura 2.7. Generación de secuencia candidata 2.3.2.3 Establecimiento de la conexión Al transcurrir este tiempo, el cliente intentará realizar la conexión al puerto deseado, típicamente se solicitara la atención de un servidor SSH que escucha en el puerto 22. Este comportamiento puede variar de acuerdo a la implementación. 2.3.3 Diseño de la aplicación auxiliar generadora de usuarios Una característica interesante de la propuesta es que los usuarios que pueden hacer uso del sistema, no necesariamente deben concordar con los usuarios registrados en el sistema operativo del servidor, por lo que es necesario contar con una aplicación auxiliar que pueda generar la base de datos de usuarios propia para almacenar a los usuarios de TOCHTLI. Esta aplicación se llama tpasswd y tiene las funciones de alta, modificación y eliminación de usuarios. Cabe mencionar que esta aplicación está programada en shell script, lo mismo que las aplicaciones servidor y cliente. Del funcionamiento de la aplicación vale la pena mencionar el método para la generación de los passwords del usuario, que no es más que el resultado de la suma md5 de la concatenación del login y el password. Resta mencionar que el archivo en el que se guardan los logins y passwords es por defecto tusers.

28

3. Pruebas e implementación.
En las secciones siguientes se explicarán todos los pasos que deben llevarse a cabo, tanto del lado del servidor como del cliente a fin de establecer una conexión exitosa. Cabe mencionar que algunas de las imágenes de ventanas tienen un color de fondo un poco más oscuro que otras, esto se hizo a propósito para que el lector distinga aquellas imágenes tomadas desde el servidor (fondo más oscuro) que aquellas de los clientes (fondo blanco). Las pruebas realizadas se llevaron a cabo en tres máquinas, todas ellas con un sistema operativo GNU/Linux Slackware 10.1. Se usaron dos computadoras como clientes y una para el servidor con las características señaladas en la tabla 3.1: Procesador AMD Athlon XP 2000 a 1.6 GHz Intel celeron a 700 MHz RAM 512 Mb 512 Mb Nombre Cliente1 Cliente2 Kernel 2.6.11.6 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 Servidor Cliente1 Cliente2 192.168.1.10 192.168.1.5 192.168.1.3 Tabla 3.2 Direcciones IP de las computadoras utilizadas en las pruebas Dirección IP

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

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

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

29

Figura 3.1. Generación de usuarios de tpasswd Otro dato relevante mostrado por la figura 3.1, es el tiempo de creación de cada usuario, medido usando el comando date +%k:%M:%S.%N, que muestra el formato hh:mm:ss.nanosegundos. El siguiente paso, es ejecutar la aplicación servidor (tochtlid). Para este ejemplo se utilizan los parámetros. Estos se muestran en la tabla 3.4. Parámetro -p -P -s -l -i -w TOCHTLI /var/log/mesages eth0 Valor por defecto Significado 1 Puerto límite inferior de escucha 65535 Puerto límite superior de escucha Marca de las entradas del firewall Archivo de bitácora Nombre de la interfaz

Tusers Archivo de usuarios de TOCHTLI Tabla 3.4. Parámetros aceptados por tochtlid.

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

30

Figura 3.2. Inicio de tochtlid, tiempo de generación de secuencias y enumeración. Este proceso corresponde con la fase de carga en memoria de las contraseñas de los usuarios. El código responsable de realizar esta fase se muestra en la figura 3.3

Figura 3.3. Código de generación de secuencias válidas En la figura 3.3 también se muestran las declaraciones de los arreglos para guardar los passwords (SUMAS, por ser sumas md5), los logins de los usuarios (USERS) y las secuencias de puertos seguros (sec_ports). De acuerdo con el diseño de tochtlid, la siguiente fase se refiere a la inserción de las reglas de iptables para cerrar todos los puertos, proceso que tardó en la máquina Servidor 10898000 nanosegundos. Al finalizar este proceso, las reglas del firewall quedaron como se muestra en la figura 3.4:

31

Figura 3.4. Reglas del firewall después de ser cargadas en el núcleo. Una ejecución de un escáner de puertos como nmap muestra que absolutamente todos los puertos están cerrados. Véase figura 3.5

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

32

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

Figura 3.6. Código de monitoreo al archivo de bitácoras. A partir de este momento tochtlid quedará a la espera de cualquier intento de conexión de parte de sus clientes. A continuación se explicará el proceso que los clientes llevan a cabo para conectarse al servidor. Lo primero que un usuario debe hacer a fin de intentar la conexión con el Servidor, es la invocación del programa cliente (tochtli). Este programa debe llevar como argumentos iniciales el login para tochtlid y la dirección IP del servidor. A continuación tochtli pedirá el password para generar la secuencia candidata. Este proceso se muestra en las figuras 3.7 y 3.8 para Cliente1 y Cliente2 respectivamente; así como el tiempo de creación de dicha secuencia y la secuencia en sí.

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

33

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

Figura 3.9. Código para la generación de las secuencias candidatas. Por otro lado, el código que se encarga de lanzar la secuencia de llamados se puede ver en la figura 3.10.

34

Figura 3.10. Código para enviar la secuencia candidata al Servidor. Es conveniente hacer notar la posibilidad de la aplicación auxiliar tpasswd, la cual pudiera crear dos entradas diferentes para un mismo usuario (el mismo usuario con dos o más passwords). Así, cuando se deseara modificar alguna de las contraseñas, siempre se modificaría la primera que se encuentre, lo cual podría resultar en un comportamiento no deseado de la aplicación. Un comportamiento similar podría suceder cuando se requiriese eliminar al usuario. En este último caso bastará con ejecutar el comando tantas veces como sea necesario. En este punto, los clientes han enviado ya la secuencia de llamados y tochtlid los recibirá y comparará con las secuencias válidas almacenadas en memoria. Para el caso del usuario acampos, en la figura 3.11 se muestra el proceso de recepción de la secuencia de llamados.

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

35

En la figura 3.11 también se puede observar el tiempo que le toma a tochtlid hacer la comparación con la primera secuencia válida almacenada, que resulta ser también la correcta. Es de recalcar que en la última línea que muestra la secuencia candidata, existe un llamado al puerto 22, lo que sugiere que el tiempo de espera entre el envío de la secuencia candidata y el intento de conexión del cliente es quizás demasiado corto y quizás se deba incrementar al menos un segundo más. De cualquier modo, tochtlid solamente hará caso de los primeros 16 llamados de la secuencia, por lo que hará caso omiso de los llamados posteriores. Finalmente se ve que tochtlid entra en un periodo de suspensión de 10 segundos a fin de que el cliente establezca la conexión. La figura 3.12 muestra que al transcurrir el periodo de espera se intenta la conexión por ssh la cual resulta exitosa. Esto se sabe en vista de la aparición del prompt del cliente de ssh solicitando la contraseña local del usuario acampos y su posterior ingreso al servidor.

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

36

Figura 3.13. Inserción de la regla para permitir el acceso desde 192.168.1.3 En la figura 3.14 se muestra también el estado de las conexiones TCP del servidor mediante una ejecución del comando netstat.

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

37

Figura 3.15. Recepción y verificación de la secuencia candidata del usuario jjimenez. De tal manera, aunque el cliente de ssh trate de establecer la conexión, el Servidor no lo permitirá. Para que pueda hacer otro intento satisfactorio, el cliente deberá esperar a que transcurran al menos 20 minutos. En la figura 3.16 se muestra el reintento del cliente, esta vez, con una conexión exitosa.

Figura 3.16 Conexión exitosa para el usuario jjimenez.

38

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

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

39

4. Conclusiones
Se ha desarrollado un mecanismo para el filtrado de accesos no deseados en una ambiente TCP/IP, basándose en el concepto de Port Knocking. Esta técnica establece los mecanismos para abrir y cerrar puertos de un equipo Servidor, mediante una secuencia de llamados (knocks) a diversos puertos TCP (Ports). En nuestro caso, hemos considerado un ambiente de experimentación, con un equipo de cómputo que hace las veces de Servidor y dos equipos más que hacen el papel de Clientes. Se cerraron todos los puertos TCP del equipo servidor y se diseñó un mecanismo para la generación de secuencias de llamados (port knocking). Nuestros experimentos fueron realizados, usando únicamente el puerto 22 como puerto de entrada. Así, si alguno de los clientes envía una secuencia válida hacia el Servidor, éste abrirá este puerto para su acceso exclusivo a dicho cliente y 10 segundos después de la conexión, el puerto se cerrará automáticamente. Se realizaron diversas pruebas para determinar el comportamiento del mecanismo implantado, y se observó que éste funciona correctamente, aunque es posible mejorarlo a futuro. Al ser el presente trabajo de tesis una implantación de carácter experimental que sirva como prueba del concepto de port knocking, no se recomienda para implantación en un servidor de producción debido a la alta carga de tráfico que debe soportar, de manera que habría que encontrar un método más rápido de hacer la lectura de los llamados de secuencia. Sobre esto sería deseable desarrollar un sistema que no utilice lenguajes interpretados como el caso del lenguaje C. En este mismo orden de ideas, sería deseable incorporar el uso de librerías especializadas para la captura y análisis de paquetes directamente de la pila TCP/IP, como es el caso de libnet, ya que brindaría mayor velocidad al sistema, puesto que como se sabe que el acceso al sistema de archivos es más lento que a la memoria. Inclusive, si se desea continuar con el diseño planteado en este trabajo sería recomendable que el archivo de bitácoras se encontrase en una partición con ReiserFS, que por su diseño es más veloz que ext3, el cual es el sistema de archivos por defecto de varias distribuciones de GNU/Linux. Lamentablemente ReiserFS presenta problemas de pérdida de datos en ambientes en los que la alimentación eléctrica falle continuamente. Otro problema de seguridad se presenta en virtud de que el presente trabajo solamente se basa en la dirección IP del solicitante. Esto resulta peligroso cuando alguna entidad externa falsifica la identidad de la máquina original mediante una técnica llamada IP spoofing (sustitución de identidad). Una posible solución que no resulta muy práctica es la de agregar la dirección física de la interfaz de red a los datos almacenados en tusers, lo cual conlleva problemas de mantenimiento del sistema. Por otro lado, una solución más viable es la activación del filtro rp (rp_filter), con lo cual el propio sistema operativo se encargaría de hacer las revisiones correspondientes. Así mismo, un aspecto importante a considerar es que por la naturaleza del port knocking, es sensible a una variante del ataque DDoS (Distributed Denial of Service o negación de servicio distribuido), en el cual se envía un número muy grande de paquetes con la opción SYN activada en tiempos relativamente largos. Generalmente los ataques tipo DoS (Denial of Service o negación de servicio) o DDoS comunes pueden contrarrestarse activando las syn_cookies en el núcleo del sistema, puesto que evitan el consumo excesivo de recursos del sistema a la llegada de paquetes SYN en tiempos cortos. Ante esto podría incluso plantearse la posibilidad de modificar las reglas del firewall para limitar el arribo de paquetes en un lapso de tiempo determinado, pero esto podría incluso bloquear los intentos reales de conexión llevando nuevamente a un problema de DoS. Según el diseño presentado en este trabajo, existe otro tipo peligro puesto que se escribe un registro por cada paquete recibido, el archivo de bitácoras puede crecer hasta alcanzar el tamaño máximo de la partición que lo contenga, causando que otras aplicaciones que hagan uso de él se encuentren imposibilitadas de hacerlo o incluso que no se pueda escribir nada más en el disco duro (dependiendo del esquema de particionamiento utilizado).

40

Digno de mención es el hecho de que este tipo de ataques (DoS y DDoS), junto con todas sus variantes, no tienen aún un antídoto que los contrarreste Otra mejora substancial al sistema sería el de hacer que los logins de usuario no correspondiesen con los del sistema operativo, aunque también provocaría que los usuarios tuviesen que recordar dos logins y dos passwords, lo que en términos reales no es muy práctico ya que la tendencia de los usuarios es la de escribir esos datos sensibles en algún lugar poco seguro, dado lo cual algún usuario mal intencionado podría hacer mal uso de ellos. Un último punto a considerar es que en la implementación aquí presentada, las secuencias candidatas son siempre las mismas y son susceptibles a ser capturadas mediante un sniffer, por lo que sería deseable que en futuras propuestas se incluyese algún método para crear secuencias candidatas que presentaran variaciones cada vez que se presente un intento de conexión, lo cual acarrearía una mejora en el diseño de la aplicación, en el sentido de que deberá mejorarse los procesos de generación y comparación de secuencias válidas y candidatas. Para terminar, port knocking no es el mejor sistema de seguridad, lo mismo que los firewalls, pero sirve como una línea más de defensa ante intentos de accesos no deseados a los sistemas de cómputo. En la medida en la que el ingenio humano encuentra nuevas formas de ganar accesos no autorizados, se encuentran también medidas ingeniosas para defender los sistemas o viceversa. El hecho es que no importa que se utilice el sistema operativo más seguro del mundo, siempre existirá una aplicación vulnerable a algún tipo de ataque.

41

5. Referencias
[1] Internet. Wikipedia en Español. [Online] http://es.wikipedia.org/wiki/Internet [2] TCP/IP. Wikipedia en Español. [Online] http://es.wikipedia.org/wiki/TCP/IP [3] David C. Plummer. An Ethernet Address Resolution Protocol. Internet Engineering Task Force. Noviembre de 1982. [Online] http://www.ietf.org/rfc/rfc0826.txt?number=826 [4] Sun Microsystems. NFS: Network File System Protocol Specification. Internet Engineering Task Force. Marzo de 1989. [Online] http://www.ietf.org/rfc/rfc1094.txt?number=1094 [5] J. Case, K. McCloghire, M. Rose. Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2). Internet Engineering Task Force. Abril de 1993. [Online] http://www.ietf.org/rfc/rfc1448.txt?number=1448 [6] P. Mockapetris. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. Internet Engineering Task Force. Noviembre de 1987. [Online] http://www.ietf.org/rfc/rfc1035.txt?number=1035 [7] Jonathan B. Postel. SIMPLE MAIL TRANSFER PROTOCOL. Internet Engineering Task Force. Agosto de 1982. [Online] http://www.ietf.org/rfc/rfc0821.txt?number=821 [8] David H. Crocker. STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES. Internet Engineering Task Force. Agosto de 1982. [Online] http://www.ietf.org/rfc/rfc0822.txt?number=822 [9] J. Postel. TELNET PROTOCOL SPECIFICATION. Internet Engineering Task Force. Junio de 1980. [Online] http://www.ietf.org/rfc/rfc0764.txt?number=764 [10] J. Postel, J. Reynolds.TELNET PROTOCOL SPECIFICATION. Internet ENgineering Task Force. Mayo de 1983. [Online] http://www.ietf.org/rfc/rfc0854.txt?number=854 [11] J. Postel, J. Reynolds. FILE TRANSFER PROTOCOL (FTP). Internet Engineering Task Force. Octubre de 1985. [Online] http://www.ietf.org/rfc/rfc0959.txt?number=959 [12] HTTP. Wikipedia en Español. [Online] http://es.wikipedia.org/wiki/HTTP [13] T. Berners-Lee, R. Fielding, H. Frystyk. Hypertext Transfer Protocol -- HTTP/1.0. Internet Engineering Task Force. Mayo de 1996. [Online] http://www.ietf.org/rfc/rfc1945.txt?number=1945 [14] SSH. Wikipedia en Español. [Online] http://es.wikipedia.org/wiki/SSH [15] IPTables manual práctico. Pello Xabier Altadill Izura. [Online] http://www.pello.info/filez/firewall/iptables.html [16] Netfilter/IPTables Home page. [Online] http://www.netfilter.org/ [17] Rusty Russell. Packet filtering HOWTO. Enero de 2002. [Online] http://www.netfilter.org/documentation/HOWTO/es/packet-filtering-HOWTO.html [18] Página manual de BASH. [Online] http://www.linuxcommand.org/man_pages/bash1.html [19] Mike G. BASH Programming Introduction HOWTO. [Online] http://www.tldp.org/HOWTO/Bash-Prog-Intro-HOWTO.html [20] Mendel Cooper. Advanced Bash-Scripting Guide. Junio de 2005. [Online] http://www.tldp.org/LDP/abs/html/index.html [21]Firewalls Linux, Guía Avanzada. Roert L. Ziegler. Prentice Hall. España 2003

42

[22] J Yarden. Use port knocking to bypass firewall rules and keep security intact. SANS Institute. 2005. [Online]. http://techrepublic.com.com/5100-1009-5798871.html [23] Maddock B. Port Knocking: An overview of Concepts, Issues and Implementations. SANS Institute. 2004 [Online] http://www.giac.org/practical/GSEC/Ben_Maddock_GSEC.pdf [24] Matt Welsh. Guía de instalación de Linux y primeros pasos. 1992. [Online]. http://es.tldp.org/Manuales-LuCAS/LIPP2/lipp-2.0-beta-html

43

Sign up to vote on this title
UsefulNot useful