estudio, diseño e implementación de un...

Estudio, diseño e implementación deun Firewall

CARLOS GUSTAVO MORALES TEJEDA

Septiembre 2002

Abstracto

Los firewall son los componentes más importantes a la hora de proteger una

red de datos, ya que se encargan de filtrar los datos que pasan a través de él. El

objetivo de este TFC es crear un firewall de filtrado de paquetes bajo un entor-

no Unix. La dificultad reside en la programación a bajo nivel dentro del sistema

operativo, en la que cualquier error de programación supone una parada del orde-

nador y porque toda modificación requiere compilar el kernel de nuevo y rebotar

la máquina donde se está ejecutando el firewall

Resumen

Un firewall es el componente más importante a la hora de proteger una red de

ordenadores. Es un sistema incorporado dentro del sistema operativo, encargado

de filtrar los datos que pasan a través de él. El objetivo de este proyecto es hacer

un estudio teórico de los firewalls en un entorno Unix-Linux, para luego poder

diseñar e implementar uno. Así pues, esta memoria está dividida principalmente

en dos partes: una parte teórica y una práctica.

Dentro de la parte teórica hay un breve estudio de los protocolos TCP/IP, que

son los protocolos que usan las redes de datos. El siguiente tema es una intro-

cución a los firewalls, donde se narra las características y los posibles tipos de

firewalls. Se hace un especial incapié en el filtrado de paquetes pues se le dedica

un capítulo entero ya que es el tipo de firewall que se va a implementar. Los fire-

walls de filtrado de paquetes se basan en las cabeceras de los paquetes de datos

para decidir si deben filtrarse. En el siguiente capítulo se repasa el sistema ope-

rativo Linux ya que la programación del firewall va muy ligado con este. Hay un

resumen de sus características principales, de las herramientas que disponemos y

del viaje que realiza un paquete desde que se captura en la misma tarjeta de red

hasta que llega a las apliaciones de los usuarios. El último capítulo es un estudio

del diseño, para poder modelar correctamente cualquier proyecto.

La programación dentro del sistema operativo es muy compleja, llamado hac-

king del kernel, ya que es la parte que se encarga de controlar el ordenador, y

cualquier fallo significa la parada absoluta del mismo, por eso se hace necesario

poder averiguar que hace en todo momento el kernel mientras se está ejecutan-

do. El siguiente capítulo aborda el diseño de la aplicación, que comprende tanto

los esquemas del modelado como la explicación de como se ha programado el

firewall. Después hay un capítulo llamado implementación del firewall, donde se

explican los escenarios que se ha necesitado tanto para desarrollar como para pro-

bar los resultados finales.

Los últimos capítulos comprenden las conclusiones, las líneas de futuro que

pueden seguirse, el coste del proyecto y la bibliografía que se ha necesitado.

Índice

I Teoría 1

1. Introducción 1

2. TCP/IP 2

2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1.1. Capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1.2. Encapsulación . . . . . . . . . . . . . . . . . . . . . . . 4

2.2. IP: Internet Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.2. Cabecera IP . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3. UDP: User Datagram Protocol . . . . . . . . . . . . . . . . . . . 9

2.3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.2. Cabecera UDP . . . . . . . . . . . . . . . . . . . . . . . 9

2.4. TCP: Transmisión Control Protocol . . . . . . . . . . . . . . . . 10

2.4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4.2. Cabecera TCP . . . . . . . . . . . . . . . . . . . . . . . 12

3. Introducción a los firewalls 15

3.1. ¿Qué es un Firewall? . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2. Qué puede hacer . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.1. Donde localizar las decisiones . . . . . . . . . . . . . . . 16

3.2.2. Refuerza políticas . . . . . . . . . . . . . . . . . . . . . . 16

3.2.3. Registrar la actividad . . . . . . . . . . . . . . . . . . . . 16

3.2.4. Limita la exposición . . . . . . . . . . . . . . . . . . . . 16

3.3. Qué no puede hacer . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3.1. Dentro de la red . . . . . . . . . . . . . . . . . . . . . . . 17

3.3.2. Conexiones que no van a través de él . . . . . . . . . . . 17

3.3.3. Virus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.4. Tipos de Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4.1. Filtrado de paquetes . . . . . . . . . . . . . . . . . . . . 18

3.4.2. Servicios proxy . . . . . . . . . . . . . . . . . . . . . . . 20

3.4.3. Combinación de técnicas . . . . . . . . . . . . . . . . . . 21

3.5. Arquitecturas Firewall . . . . . . . . . . . . . . . . . . . . . . . 21

3.5.1. Dual-Homed Host . . . . . . . . . . . . . . . . . . . . . 22

3.5.2. Screened Host . . . . . . . . . . . . . . . . . . . . . . . 23

3.5.3. Screened Subnet . . . . . . . . . . . . . . . . . . . . . . 24

3.5.4. Variaciones posibles . . . . . . . . . . . . . . . . . . . . 26

4. Filtrado de paquetes 28

4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2. Características . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3. Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3.1. Proteger toda la red . . . . . . . . . . . . . . . . . . . . . 30

4.3.2. Transparencia . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3.3. Disponibilidad . . . . . . . . . . . . . . . . . . . . . . . 31

4.3.4. Latencia . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.4. Desventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.4.1. Protocolos difíciles . . . . . . . . . . . . . . . . . . . . . 32

4.4.2. Polítcas que no pueden aplicarse . . . . . . . . . . . . . 33

4.4.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.5. Configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.5.1. Bidireccionalidad . . . . . . . . . . . . . . . . . . . . . . 34

4.5.2. ’Inbound’ y ’Outbound’ . . . . . . . . . . . . . . . . . . 34

4.5.3. Permitir por defecto versus denegar por defecto . . . . . . 35

4.6. Que hacer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.6.1. Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.6.2. Paquetes ICMP . . . . . . . . . . . . . . . . . . . . . . . 37

4.7. Filtrado por dirección . . . . . . . . . . . . . . . . . . . . . . . 39

4.7.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . 39

4.7.2. Riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5. El Sistema Operativo Linux 42

5.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1.1. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1.3. Características . . . . . . . . . . . . . . . . . . . . . . . 46

5.2. El Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . 50

5.2.2. Modos . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.2.3. Módulos . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.2.4. Procesos . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.2.5. Sincronización . . . . . . . . . . . . . . . . . . . . . . . 52

5.2.6. Comunicación entre procesos . . . . . . . . . . . . . . . 54

5.2.7. Control de la Memoria . . . . . . . . . . . . . . . . . . . 54

5.2.8. El código . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.2.9. Numeración . . . . . . . . . . . . . . . . . . . . . . . . 58

5.2.10. Compilación del núcleo . . . . . . . . . . . . . . . . . . 59

5.3. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.3.1. Editores de texto . . . . . . . . . . . . . . . . . . . . . . 65

5.3.2. Herramientas de desarrollo . . . . . . . . . . . . . . . . . 68

5.3.3. Navegación . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.3.4. Manipuladores . . . . . . . . . . . . . . . . . . . . . . . 72

5.3.5. Control de versiones . . . . . . . . . . . . . . . . . . . . 74

5.4. Netfilter en los kernels 2.4 . . . . . . . . . . . . . . . . . . . . . 79

5.4.1. Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.4.2. Inconvenientes . . . . . . . . . . . . . . . . . . . . . . . 80

5.5. Viaje de un paquete . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.5.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . 82

5.5.2. Tarjeta de red . . . . . . . . . . . . . . . . . . . . . . . . 82

5.5.3. Proceso de red . . . . . . . . . . . . . . . . . . . . . . . 84

5.5.4. Softirq para NET_RX . . . . . . . . . . . . . . . . . . . 85

5.5.5. Tratar los paquetes IP . . . . . . . . . . . . . . . . . . . . 85

6. Estudio del Diseño ( UML) 88

6.1. Introducción al UML . . . . . . . . . . . . . . . . . . . . . . . . 88

6.1.1. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.1.3. Participantes en UML 1.0 . . . . . . . . . . . . . . . . . 90

6.1.4. Áreas conceptuales . . . . . . . . . . . . . . . . . . . . . 91

6.2. Diagramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6.2.1. Diagramas estructurales . . . . . . . . . . . . . . . . . . 94

6.2.2. Diagramas de comportamiento . . . . . . . . . . . . . . . 94

6.3. Diagramas de Objetos . . . . . . . . . . . . . . . . . . . . . . . . 95

6.3.1. Oid (Object Identifier) . . . . . . . . . . . . . . . . . . . 96

6.3.2. Características alrededor de un objeto . . . . . . . . . . . 97

6.4. Diagramas de Clases . . . . . . . . . . . . . . . . . . . . . . . . 98

6.4.1. Relaciones entre clases . . . . . . . . . . . . . . . . . . . 99

6.5. Diagramas de Caso de Uso . . . . . . . . . . . . . . . . . . . . . 101

6.5.1. Actores . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

6.6. Diagramas de Estado . . . . . . . . . . . . . . . . . . . . . . . . 103

6.6.1. Estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

6.6.2. Envío de mensajes . . . . . . . . . . . . . . . . . . . . . 104

6.6.3. Acciones . . . . . . . . . . . . . . . . . . . . . . . . . . 105

6.7. Diagramas de actividades . . . . . . . . . . . . . . . . . . . . . . 106

6.7.1. Notación . . . . . . . . . . . . . . . . . . . . . . . . . . 107

6.8. Diagramas de Interacción . . . . . . . . . . . . . . . . . . . . . . 108

6.8.1. Colaboración . . . . . . . . . . . . . . . . . . . . . . . . 109

6.8.2. Interacción . . . . . . . . . . . . . . . . . . . . . . . . . 110

6.8.3. Patrón . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

6.9. Diagramas de Componentes . . . . . . . . . . . . . . . . . . . . 110

6.9.1. Componentes . . . . . . . . . . . . . . . . . . . . . . . . 112

6.10. Diagramas de Despliegue . . . . . . . . . . . . . . . . . . . . . . 113

6.11. Los paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

II Práctica 117

7. Hacking del kernel 117

7.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

7.2. Uso del debugador . . . . . . . . . . . . . . . . . . . . . . . . . 118

7.3. printk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

7.4. Oops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

7.5. Máquinas virtuales . . . . . . . . . . . . . . . . . . . . . . . . . 124

7.6. Debugando con dos máquinas . . . . . . . . . . . . . . . . . . . 125

8. Diseño de la aplicación 131

8.1. Esquemas UML . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

8.1.1. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . 131

8.1.2. Diagramas de actividades . . . . . . . . . . . . . . . . . 132

8.1.3. Diagrama de secuencia . . . . . . . . . . . . . . . . . . . 135

8.2. Exclusión mutua . . . . . . . . . . . . . . . . . . . . . . . . . . 136

8.2.1. La importancia de los semáforos . . . . . . . . . . . . . . 136

8.2.2. Locks de lectura . . . . . . . . . . . . . . . . . . . . . . 136

8.2.3. Locks de escritura . . . . . . . . . . . . . . . . . . . . . 138

8.3. Filtrado de paquetes . . . . . . . . . . . . . . . . . . . . . . . . . 139

8.3.1. ip_input.c . . . . . . . . . . . . . . . . . . . . . . . . . . 140

8.3.2. ip_forward.c . . . . . . . . . . . . . . . . . . . . . . . . 141

8.3.3. ip_output.c . . . . . . . . . . . . . . . . . . . . . . . . . 142

8.3.4. El sk_buff . . . . . . . . . . . . . . . . . . . . . . . . . . 143

8.3.5. Operaciones . . . . . . . . . . . . . . . . . . . . . . . . . 144

9. Implementación del firewall 145

9.1. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

9.1.1. Debugar . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

9.1.2. Semáforos . . . . . . . . . . . . . . . . . . . . . . . . . 146

9.2. Escenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

9.2.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 149

9.2.2. Compilar kernel . . . . . . . . . . . . . . . . . . . . . . 149

9.2.3. Configurar el firewall . . . . . . . . . . . . . . . . . . . . 149

9.2.4. Configurar la red . . . . . . . . . . . . . . . . . . . . . . 151

9.2.5. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . 151

10. Conclusiones 152

11. Líneas de futuro 154

12. Coste del trabajo 155

III Anexo A sk_buff 159

IV Anexo B Coding Style 162

1 INTRODUCCIÓN

Parte I

Teoría

1. Introducción

En construcción de edificios, un muro de fuego (firewall en inglés) se diseña

para mantener el fuego separado de una parte de un edificio a otra. En teoría, un

firewall de Internet sirve con el mismo propósito: previene de peligros de Internet

a la red interna. El firewall protege la red filtrando toda la información que pasa

a través de él y decidiendo si el tráfico se acepta según las políticas de seguridad.

El firewall es el elemento más importante a la hora de asegurar una red, no es el

único ni tampoco previene de todos los posibles ataques y peligros, pero es un

componente básico.

Siguiendo la comparativa de la construcción, el firewall hace la misma función

que la puerta de nuestra casa, que solo deja pasar a las personas que tengan una

llave que corresponda con la cerradura, al resto de personas no les dejará entrar.

Igual que en cualquier casa tener una puerta muy segura no implica que sea segu-

ra, pueden haber otras amenazas como incendios, puertas traseras, etc. Pero una

buena puerta sigue siendo el elemento más importante y un componente básico.

El objetivo de este trabajo es construir un firewall desde cero. El firewall debe

insertarse dentro del sistema operativo, filtrar los paquetes IPv4 según la dirección

origen y destino, según el número de puerto origen y destino, según la interfaz y

el sentido del paquete respecto esa misma interfaz.

1

2 TCP/IP

2. TCP/IP

2.1. Introducción

Es fundamental explicar el conjunto de protocolos que nos sirven para comu-

nicar varios equipos, ya que entendiendo cómo funciona sabremos qué políticas

necesitamos para diseñar la seguridad en una red, bloqueando las transmisiones

no deseadas, que al fin y al cabo es lo que hace un firewall.

La suite de protocolos TCP/IP permite a ordenadores de todos los tipos, de di-

ferentes fabricantes, corriendo sistemas operativos completamente diferentes co-

municarse entre ellos. Lo que empezó a finales de los 1960 como un proyecto

de investigación financiado por el gobierno en una red de ordenadores del tipo

packet switching, se ha convertido en el protocolo de red más usado entre ordena-

dores. Es tal su relevancia que el firewall se construirá sólo y exclusivamente para

redes IP. Hay muchas publicaciones que hablan de esta suite. Forman las bases

para lo que es llamado la Internet mundial, o simplemente Internet, una wide area

network (WAN) de varios millones de ordenadores que envuelven literalmente el

globo.

2.1.1. Capas

Los protocolos de red se desarrollan normalmente en capas, cada una de las

capas es responsable para una faceta diferente de las comunicaciones. Una suite de

protocolos como es el caso de TCP/IP, es la combinación de diferentes protocolos

en varias capas, que normalmente se le considera un sistema de 4 capas o layers.

2

2 TCP/IP 2.1 Introducción

Cada capa tiene diferentes responsabilidades.

1. La capa link, llamada normalmente data-link layer es la interfaz de red que

incluye el driver del sistema operativo para la tarjeta de red. Juntos pueden

tratar todos los detalles del hardware e interactuar físicamente con el cable

o con el medio que se esté usando en cada caso.

2. Capa de red o Network Layer, se encarga del movimiento de paquetes a

través de la red. Para el enrutado de paquetes se usa IP (Internet Protocol),

ICMP (Internet Control Message Protocol) y el IGMP (Internet Group Ma-

nagment Protocol).

3. La capa de transporte se encarga del flujo de datos entre dos ordenadores,

para la capa de aplicaciones. En la suite de TCP/IP hay dos protocolos muy

diferentes entre sí en la capa de transporte: TCP (Transmisión Control Pro-

tocol) y UDP (User Datagram Protocol). Para el caso de TCP este provee

un flujo asegurado entre dos ordenadores. Se encarga de dividir los datos

pasados desde las aplicaciones en trozos de tamaño correcto para la capa de

red, aceptando los paquetes recibidos, marcando tiempos para asegurar que

3

2 TCP/IP 2.1 Introducción

los paquetes de acknowledge enviados, entre otros. Al ser un flujo de da-

tos asegurado la capa de aplicación puede ignorar estos detalles. En cambio

UDP provee una forma mucho más simple de comunicarse. Este simple-

mente envía paquetes de datos llamados datagramas de un host a otro, pero

no esta garantizado que los datagramas lleguen a la otra parte. Cualquier

control debe añadirse en la capa de aplicación.

4. La última capa, la capa de aplicación trata los detalles del una aplicación en

particular. Podemos encontrar dentro de todas las aplicaciones: telnet para

hacer logins remotos, http para la web, ftp para transferir ficheros, smtp para

enviar correo electrónico, etc

Cada capa tiene uno o más protocolos para comunicarse con las capas vecinas

del mismo nivel entre ordenadores. Un protocolo, por ejemplo el TCP permite

comunicarse entre la parte del emisor y del receptor.

IP es el protocolo principal en la capa de red. Es usado por los protocolos

TCP y UDP. Cada dato de estos protocolos se transfiere a través de la capa de red

usando el protocolo IP, este proceso se llama Encapsulación y se pasa a explicar

en el siguiente punto.

2.1.2. Encapsulación

Cuando una aplicación envía datos usando TCP, los datos son enviados abajo

y los almacena en la pila del protocolo, y así sucesivamente a través de cada capa,

hasta que son enviados como un conjunto de bits por la red. Cada capa o layer

añade información a los datos, normalmente antecediendo a los datos o a veces

añadiendo unos pocos datos al final. La unidad de datos que TCP envía a la pila

de IP se llama un segmento TCP. La unidad de datos que envía IP en la capa 3 a la

capa 2, la de red, se llama un datagrama IP. Y por último el flujo de bits que pasan

por la red Ethernet se llaman frames.

IP debe añadir algún tipo de identificador en la cabecera IP que genera para

indicar a qué capa pertenece. Esto se trata guardando un valor del tamaño de 8

bits en su cabecera llamado campo de protocolo. Si el valor es 1 es para ICMP, si

es 2 es para IGMP, 6 indica TCP y 17 es UDP. Esto nos será muy útil a la hora de

bloquear los paquetes que no se deseen.

4

2 TCP/IP 2.2 IP: Internet Protocol

De forma similar, todas las aplicaciones que usan TCP o UDP deben identi-

ficarse. La capa de transporte guarda un identificador en la cabecera que genera

para identificar la aplicación. Ambos protocolos el TCP y el UDP usan números

de puerto de 16 bits para identificar aplicaciones. Se guarda el puerto de origen y

el de destino para identificarlos.

Aunque no sea interesante para el proyecto del firewall también indicar que los

frames de la capa de red que recibe el driver de la tarjeta Ethernet, tienen también

un campo de 16 bits para indicar que capa del protocolo generó los datos.

2.2. IP: Internet Protocol

2.2.1. Introducción

IP es la herramienta principal dentro de la suite TCP/IP. Todos los datos TCP,

UDP, ICMP e IGMP son transmitidos como datagramas IP.

Un dato importante es que el protocolo IP es un protocolo NO orientado a

conexión (conectionless) y NO asegurado.

Por no asegurado se entiende que el protocolo IP no garantiza la llegada a su

destino de los datagramas. IP provee un servicio de mejor esfuerzo (best effort).

Cuando algo va mal como por ejemplo un router no tiene más capacidad en los

buffers de entrada, IP tiene un algoritmo para tratar el error muy sencillo: no hace

caso del datagrama e intenta enviar un mensaje ICMP al origen.

Ser un protocolo no orientado a conexión significa que IP no mantiene ningún

estado de información de los datagramas consecutivos. Cada datagrama es tratado

de forma separada de todos los otros datagramas. Significa que los datagramas

pueden llegar de manera desordenada. Por ejemplo, si un equipo envía dos da-

tagramas consecutivos al mismo destino, y cada uno va por un camino diferente

pueden llegar en un orden distinto al de salida.

El protocolo IP está diseñado para ser retransmitido para ser usado en sistemas

interconectados en redes de comunicaciones packet-switched. Los hosts se identi-

fican por una dirección fija, tanto los ordenadores destinos como los ordenadores

origen, llamadas direcciones IP. Y como he comentado antes no hay mecanismos

para el proceso de conexiones de control de flujo, secuencia de paquetes y otros

mecanismos que se encuentran en protocolos orientados a conexión.

5


Las funciones básicas del protocolo según la especificación RFC0791 son dos:

direccionar y fragmentar. Para direccionar se usan las direcciones que se encuen-

tran en la cabecera. La selección del camino para la transmisión se llama routing.

Lo que interesa de todo esto para el firewall es que el protocolo IP trata a cada

datagrama como una entidad independiente a cualquier otro datagrama. No hay

conexiones ni circuitos virtuales.

2.2.2. Cabecera IP

Dentro de la especificación RFC 791, publicada en septiembre del 1981 (http://www.ietf.org/rfc/rfc0791.txt), se

encuentra la especificación de la cabecera del datagrama.

version ip_v

header length

type of serviceip_tos

identificación

total lengthip_len

flags and fragment offsetip_off

header chacksumip_sum

time to liveip_ttl

protocoloip_p

dirección IP origen 32 bitsip_src

dirección IP destino 32 bitsip_dst

opciones (si las hay)

datos

0 15 16 31

20 bytescabecera

Versión: 4 bits

El campo de versión indica el formato de la cabecera de Internet. Esta cabecera

corresponde a la versión 4.

IHL: 4 bits

Internet Header Lenght o tamaño de la cabecera, es el tamaño de la cabecera en

palabras de 32 bits, tras la cual empiezan los datos. El valor mínimo de la cabecera

es 5.

TOS: 8 bits

6


Type Of Service o tipo de servicio indica los parámetros para la calidad de servicio

deseado. Estos parámetros suelen usarse para ser una guía del tipo de servicio que

se está retransmitiendo en el datagrama.

Tamaño total: 16 bits

El tamaño total es el tamaño del datagrama, medido en octetos, incluyendo el ta-

maño de la cabecera y de los datos. El tamaño de 16 bits permite que el datagrama

sea hasta 65.535 octetos. El tamaño de dichos datagramas es impracticable en la

mayoría de redes y ordenadores. Todos los ordenadores tienen que estar prepara-

dos para aceptar datagramas de hasta 576 octetos.Si se quiere saber más sobre la

configuración de LILO, hay que obtener la versión más reciente de servidor FTP

favorito y siga las instrucciones que le acompañan

Identificación: 16 bits

Una valor de identificación asignado por el emisor para poder ensamblar los dife-

rentes fragmentos de un datagrama.

Flags: 3 bits

1. Bits de control:

Bit 0: reservado. Tiene que ser cero.

Bit 1: (DF) 1 = Don’t Fragment, 0 = May Fragment.

Bit 2: (MF) 1 = More Fragments, 0 = Last Fragment.

Fragment Offset : 13 bits

Este campo indica a que parte del datagrama pertenece este fragmento. El tamaño

del fragmento se mide en unidades de 6 octetos (64 bits). Para indicar el primer

fragmento de un datagrama este campo tiene que ser cero.

Time To Live: 8 bits

7


Este campo indica el tiempo máximo que se le permite a un datagrama mantenerse

en Internet. Si este valor contiene un valor de cero, entonces el datagrama tiene que

ser destrozado. Este campo es modificado al procesar las cabeceras. Su tiempo

está medido en unidades de segundo, pero cada módulo tiene que decrecer el valor

de TTL como mínimo por uno incluso si se ha tardado menos de un segundo en

procesar el datagrama. La intención es que los datagramas que no puedan ser

entregados sean descartados.

Protocolo: 8 bits

Este campo indica el siguiente nivel del protocolo usado por el datagrama. Los

valores ya se han comentado anteriormente. Y son 1 si es para ICMP, si es 2 es

para IGMP, 6 indica TCP y 17 es UDP.

Header Checksum: 16 bits

Un checksum de solo la cabecera. Como hay campos en la cabecera que cambian

(Ej. Time to live), este valor se recalcula y verifica cada vez que es procesada la

cabecera.#howto

El resultado del algoritmo de checksum es el complemento de 16 bits a uno

con la suma de todas las palabras de 16 bits de la cabecera. Exceptuando el valor

de checksum que tiene el valor de cero.

Dirección origen: 32 bits

Es la dirección IP origen de 32 bits.

Dirección destino: 32 bits

Es la IP del dispositivo destino, también de 32 bits.

Opciones: variable

Las opciones pueden o no aparecer en los datagramas. Deben ser implementa-

dos por todos los módulos IP. Lo que es opcional es su transmisión en cualquier

datagrama, pero no su implementación.

8

2 TCP/IP 2.3 UDP: User Datagram Protocol

2.3. UDP: User Datagram Protocol


UDP es simple, orientado a datagrama, y está encuadrado en la capa de tras-

porte. Cada operación de envío por un proceso produce exactamente un datagrama

UDP, lo que causa que sólo un datagrama IP sea enviado. Es diferente a un pro-

tocolo orientado a conexiones (stream-oriented protocol) como es el caso de TCP

donde la cantidad de datos enviados por una aplicación puede tener pequeñas di-

ferencias a lo que en realidad es enviado en un datagrama IP.

En la siguiente figura se enseña la Encapsulación de un datagrama UDP en el

datagrama IP.

La especificación oficial de UDP es la RFC 768, publicada en Agosto del

1980, por J.Postel y se puede encontrar en (http://www.ietf.org/rfc/rfc0768.txt).

UDP no provee una conexión fiable (no reliability): envía el datagrama que la

aplicación escribe a la capa IP, pero no garantiza que llegue a su destino, es un

protocolo que no está orientado a conexión. La falta de confianza hace pensar que

deberíamos dejar de usar UDP y usar siempre el protocolo fiable como TCP. Pero

lejos de eso UDP se usa para muchos protocolos, como pueden ser DNS, TFTP,

BOOTP, SNMP y NFS entre otros.

2.3.2. Cabecera UDP

Como se ha comentado anteriormente la cabecera y su especificaciones pue-

den encontrarse en el RFC 768.

Dirección origen

ceros protocolo UDP length

Datos

0 15 16 32

Dirección destino

Número de puerto origen: 16 bits

9

2 TCP/IP 2.4 TCP: Transmisión Control Protocol

Identifica el proceso que envía el datagrama. Tanto este campo como el siguiente

nos sirven para poner reglas de filtrado en el firewall.

Número de puerto destino: 16 bits

Identifica de la misma manera el proceso que debe recibir el datagrama. Este cam-

po se usa para multiplexar los datagramas que llegan a la máquina y pasarlos a la

aplicación que se necesita. La pila de IP ya se encarga de dividir los paquetes en-

tre los TCP y los UDP, así que es el propio UDP quien mira el puerto destino y

también implica que los puertos TCP y UDP son independientes entre ellos.

Tamaño UDP: 16 bits

Es el tamaño de la cabecera UDP y de los datos, la cantidad es en Bytes. El valor

mínimo es 8 bytes (Como resultado de enviar los 8 bytes de la cabecera sin datos).

Aunque este valor es redundante ya que este valor es el campo de tamaño que se

encuentra en la cabecera IP menos el tamaño de la cabecera IP.

Checksum: 16 bits

Este checksum cubre tanto la cabecera UDP como sus datos. A diferencia del

checksum de IP que solo cubre la cabecera de IP y no cubre los datos que contiene

el datagrama. Tanto UDP como TCP cubren con sus checksum sus cabeceras y los

datos. Para poder hacer el checksum puede añadirse un relleno para que cuadren

las palabras de 16 bits.

2.4. TCP: Transmisión Control Protocol


La especificación original para TCP es la RFC 793, publicada por Postel en

Septiembre de 1981 para DARPA (Defense Advanced Research Projects Agency).

Aún estando TCP y UDP en la misma capa de transporte y usar la misma capa

de red (IP), TCP provee un servicio completamente diferente al de UDP. TCP

es un servicio orientado a conexión, fiable y un servicio de flujo de bytes (byte

stream service).

10


Por el término orientado a conexión se entiende que dos aplicaciones usando

TCP tienen que establecer una conexión entre ellos antes de poder intercambiar

datos. Una analogía parecida es una llamada de teléfono: se marca, se espera que

la otra parte responda a la llamada, decir un ’hola’ y quien es, tras ello comienza

la conversación.

Al decir que es fiable (reliability) se indica lo siguiente:

1. Los datos de la aplicación se separan en lo que TCP considera que es el me-

jor tamaño. Completamente diferente a UDP, donde cada vez que escribía

la aplicación generaba un datagrama UDP de ese mismo tamaño. La unidad

de información pasada por TCP a IP se llama segmento.

2. Cuando TCP envía un segmento mantiene un temporizador, esperando para

que la otra parte envíe un segmento con su acuse de recibo (acknowled-

ge). Si no se recibe el acuse de recibo tras esperar un rato, el segmento es

retransmitido.

3. Cuando TCP recibe datos de la otra parte de la conexión este envía un acu-

se de recibo. Que no aunque no se envía inmediatamente pues sigue una

estrategia.

4. TCP se encarga del checksum de su cabecera y de los datos. En el caso de

recibir un segmento con su checksum erróneo TCP lo descarta y no envía

ningún acuse de recibo.

5. Al encapsular TCP dentro de IP, y como los datagramas IP pueden llegar

en desorden, los segmentos pueden llegar también en desorden. Se encarga

también TCP de reordenarlos en caso de ser necesario, pasando los datos

recibidos en el orden correcto a la aplicación.

6. Como un datagrama IP puede llegar duplicado, los segmentos TCP dupli-

cados deben ser descartados.

7. TCP también mantiene un control del flujo de datos. Cada parte en la cone-

xión TCP tiene el espacio del buffer de entrada finito. Lo que significa que

TCP solo permite que la otra parte envíe los datos que tiene reservados. Esto

11


previene de que un ordenador rápido llene todos los buffers de un ordenador

lento.

Cuando hablamos de un servicio de flujo de bytes (byte stream service) nos refe-

rimos a que TCP envía un flujo de bytes a través de la conexión, no hay marcas

que identifiquen cuando el emisor envió los datos. Significa que si una aplicación

envía 20 bytes, luego envía otros 35 bytes seguido por otros 25 bytes, la aplica-

ción de la otra parte no podrá identificar los tamaños de las diferentes escrituras,

solo recibe 80 bytes en cuatro lecturas de 20 bytes, por ejemplo. Una parte pone

un flujo de bytes a la pila TCP y este mismo flujo lo recibe la otra parte de la

conexión.

Además, TCP no interpreta el contenido de los bytes que envía. TCP no tiene

ni idea si los datos corresponden a datos en binario, a caracteres ASCII, caracteres

EBCDIC o lo que sea. La interpretación de los bytes retransmitidos es función de

la aplicación que se encuentra en una capa superior a la de transporte de TCP.

2.4.2. Cabecera TCP

Los segmentos TCP se envían mediante datagramas IP. La cabecera TCP sigue

a la cabecera IP, añadiendo información específica para el protocolo TCP.

Puerto Origen Puerto Destino

Número Secuencia

Acknowledge Number

Data Off Reserved | bits Ventana

Opciones Padding

Datos

0 15 16 32

Puerto de origen: 16 bits

Número de puerto de origen.

12


Puerto de origen: 16 bits

Puerto destino que indica a qué aplicación va dirigido el segmento.

Número de secuencia: 32 bits

El número de secuencia del primer octeto de datos. En el caso de estar el bit de

SYN presente el número de secuencia es el número inicial de secuencia (initial

sequence number ISN)y el primer octeto de datos es ISN+1.

Número de Acknowledgment: 32 bits

Si el bit de control ACK está activo este campo contiene el valor del siguiente

número de secuencia que se espera recibir. Y una vez se ha establecido la conexión

siempre se envía.

Data Offset: 6 bits

Reservado para uso futuro. Debe ser cero.

Bits de control: 6 bits (de izquierda a derecha)

1. URG: Urgent Pointer field significant.

2. ACK: Acknowledgment field significant.

3. PSH: Push Function.

4. RST: Reset the connection.

5. SYN: Synchronize sequence numbers.

6. FIN: No más datos por parte del emisor.

Ventana (window): 16 bits

El número de octetos de datos empezando por el número indicado en el campo de

acknowledgment que el emisor del segmento esta esperando recibir.

13


Checksum: 16 bits

El checksum se le aplica al cuerpo del mensaje y a parte de la cabecera, que

incluye la dirección origen, la de destino, el protocolo y el tamaño del TCP.

Puntero urgente: 16 bits

Este campo indica el valor del puntero urgente como un offset positivo desde el

número de secuencia en este segmento. Y apunta al número de secuencia del oc-

teto seguido por los datos urgentes. Este campo solo es interpretado en segmentos

con el bit de control URG activa.

14

3 INTRODUCCIÓN A LOS FIREWALLS

3. Introducción a los firewalls

3.1. ¿Qué es un Firewall?

En construcción, un firewall se diseña para mantener el fuego separado de una

parte de un edificio a otra. En teoría, un firewall de Internet sirve con el mismo

propósito: previene de peligros de Internet a la red interna.

Todo el tráfico que proviene de Internet o que sale de tu red interna pasa a

través del firewall. Por esa razón, el firewall tiene la oportunidad de asegurarse

que ese tráfico es aceptable.

¿Qúe significa ’aceptable’ para el firewall? Significa todo aquel tráfico que

se hace y que cumple con las normas de seguridad del lugar. Las políticas son

diferentes para cada uno, algunas son muy restrictivas y otras son más abiertas.

Lógicamente hablando, un firewall, separa, restringe y analiza. Físicamente

hablando se puede implementar de varias maneras, la mayoría de veces es un

grupo de componentes hardware - un router, un ordenador, o una combinación

de routers, ordenadores y redes con un software apropiado. Hay varias formas de

configurar los equipos; la configuración dependerá de las políticas de seguridad,

del dinero disponible y de las operaciones a realizar.

Los firewalls tienen limitaciones y puntos débiles, entonces por qué instalar

un firewall si no es invulnerable? Porque el firewall es la manera más efectiva de

conectar una red a Internet y proteger la propia red. Internet presenta maravillo-

sas oportunidades. Millones de personas están intercambiando información. Los

beneficios son obvios: posiblidades de publicidad, servicio a cliente mejorado e

información en general. Los riesgos también deberían ser obvios también: cual-

quiera de los millones de personas puede tener intenciones maliciosas contra tu

red.

¿Cómo beneficiarse de las partes buenas de Internet sin saltarse lo malo? Sim-

plemente conectando tu red con Internet y teniendo un control exhausto de que

se intercambia. Un firewall es la herramienta para hacer eso, en la mayoría de

situaciones es la herramienta más efectiva para hacerlo.

15

3 INTRODUCCIÓN A LOS FIREWALLS 3.2 Qué puede hacer

3.2. Qué puede hacer

Los Firewalls pueden hacer mucho para tu seguridad. Estas son algunas de las

ventajas:

3.2.1. Donde localizar las decisiones

Todo el tráfico de entrada y salida tiene q pasar a través de este sitio. Un

firewall concentra las medidas de seguridad en este lugar de chequeo: allá donde

tu red se conecta a Internet.

3.2.2. Refuerza políticas

Muchos de los servicios que la gente quiere de Internet son inherentemente

inseguros. Un firewall es el policia del tráfico para estos servicios. Permite so-

lo servicios ’aprovados’ para pasar a través de él y solo aquellos que se hayan

configurardo.

Un firewall puede reforzar las políticas de seguridad añadiendo políticas más

complejas. Por ejemplo bloqueando una transferencia de ficheros desde una parte

de nuestra red; controlando qué usuarios tienen acceso a que sistemas. Y depen-

diendo de la tecnologia del firewall, este puede ser mas o menos complejo para

añadir estas políticas.

3.2.3. Registrar la actividad

Como todo el tráfico pasa a través del firewall, el firewall provee un buen lugar

para recoger una colección de información sobre los usos de los sistemas y redes.

Puede recopilar qué ocurre entre la zona protegida y la red externa.

3.2.4. Limita la exposición

Este es uno de los usos más relevantes de los firewalls. A veces un firewall

se usa para mantener una sección de tu red separada de otra sección. Haciendo

esto, se mantienen los problemas que puedan impactar en una sección separada

del resto. En estos casos, una parte de la red puede ser más segura que otra, en

otros casos una sección puede ser más sensible que otra. Cualquiera que sea lar

16

3 INTRODUCCIÓN A LOS FIREWALLS 3.3 Qué no puede hacer

razón de la existencia de un firewall este limita el daño que puede hacer una red a

otra.

3.3. Qué no puede hacer

Los firewalls ofrecen una excelente protección, pero no son la solución úni-

ca y completa para nuestra seguridad. Ciertos procesos estan fuera del control de

nuestro firewall. Y se necesita otras métodos para protegerse de estos sucesos in-

corporando otras herramientas. Es necesario conocer cuales son los puntos débiles

de los firewalls.

3.3.1. Dentro de la red

Un firewall puede prohibir a un usuario de enviar información confidencial

fuera de la red a través de la conexión a Internet. Pero el mismo usuario puede

copiar los datos en un disco, imprimirlos y llevarselos fuera del edificio en un

maletín.

Si el atacante esta dentro de la red el firewall no puede hacer nada por ti.

Dentro los usuarios pueden robar datos, dañar hardware y software, modificar

programas sin siquiera pasar a través del firewall. Es necesario protegerse con

medidas internas de seguridad.

3.3.2. Conexiones que no van a través de él

Un firewall puede controlar el tráfico que pasa a través de él pero no puede

hacer nada con el tráfico que no pasa a través de él. Por ejemplo, si hay otra

conexión dial-in para conectarse a los sistemas detrás del firewall, este no tiene

ninguna forma de proteger a los intrusos que usen ese modem.

3.3.3. Virus

Los firewalls no pueden mantener a los viruses alejados de la red interna. Mu-

chos firewalls escanean todo el tráfico entrante para determinar si este esta permi-

tido, pero el escaneo de los datos son la mayoría de veces de solo las direcciones

y puertos origen y destino, no para los detalles de los datos. Incluso los firewalls

17

3 INTRODUCCIÓN A LOS FIREWALLS 3.4 Tipos de Firewalls

más sofisticados no son muy prácticos contra los viruses. Simplemente hay mu-

chas maneras para esconder un virus entre otros datos. Determinar que existe un

virus dado un paquete que pasa a través del firewall es muy difícil. La forma más

práctica de defenderse de los virus es mantener un software de protección basado

en los ordenadores, y educando de los posibles peligros a los usuarios y de como

protegerse de ellos.

3.4. Tipos de Firewalls

Existen principalmente dos formas de implementar los firewalls hoy día. Y

esta división se centra en la forma de tratar los datos que pasan a través del firewall,

una de las dos formas es menos exhaustiva, pero por eso es la solución más barata.

El trabajo final de carrera no trata de firewalls proxy, pero estos suficientemen-

te importantes como para comentarlos.

3.4.1. Filtrado de paquetes

Los sistemas de filtrado de paquetes enrutan paquetes entre dos redes diferen-

tes, pero lo hacen selectivamente. Permiten o bloquean cierto tipo de paquetes en

un sentido o en el otro sentido, siguiendo las políticas de seguridad. El tipo de

router usado en un filtrado de paquetes se conoce como screening router.

Como se discute en el capítulo dedicado a TCP/IP cada paquete tiene unas

18


cabeceras con cierta información. En esta información se encuentra:

1. dirección origen IP

2. dirección destino IP

3. protocolo (TCP, UDP o ICMP)

4. puerto origen TCP o UDP

5. puerto destino TCP o UDP

6. tipo de mensaje ICMP

Además el router dispone de más información del paquete que no se reflejan en el

paquete pero son igual de importante, sino más.

1. La interfaz por donde llega el paquete

2. La interfaz destino del paquete

El hecho que cada uno de los servidores tenga cierto tipo de servicios nos indicará

las reglas que debamos escoger en el firewall basándonos en la IP del servidor y

del puerto, porque el puerto indica el tipo de conexciones (ej. puerto 22 TCP son

conexion SecureSHell).

Hay varias formas en las que podemos basar nuestras políticas, unas seria blo-

quear todas las conexiones provinentes de fuera de la red excepto las conexiones

SMTP para recibir correo. Bloqueando todas las conexions de sistemas que des-

confias, etc

El screening router se situa entre la red interna e Internet. Esto le da una enor-

me responsabilidad al screening_router. No solo se encarga del rutado de los pa-

quetes, sino que también se encarga de proteger el sistema. Si falla o se cae tras

un ataque, la red interna está expuesta.

Es más no puede proteger de operaciones a un servicio: si un servicio tiene

operaciones inseguras. o si el servicio se provee con un servidor inseguro el filtraje

de paquetes no puede protegerlo, ya que los paquetes pasarán indistintamente del

contenido de los paquetes, ya sea maligno o no.

19


Pero como mayor ventaja es que es un tipo de protección más barata, ya que

puede tratar a más conexiones que un proxy con el mismo equipo hardware y

además el programa no es complejo de realizar, comparado con el proxy, ya que

como se ve a lo largo del trabajo final de carrera, no es un programa sencillo de

implementar.

3.4.2. Servicios proxy

Los servicios proxy son programas especializados que corren en un firewall:

ya sea un host dual-homed con una interfaz en la red interna y otra en la red

externa, o bien un host bastion que tiene acceso a Internet a través de otra maquina

interna. Estos programas redireccionan los requests de los servicios que piden los

usuarios (como sesiones FTP o sesiones SSH), las direccionan según las politicas

de seguridad. Los proxies reemplazan las conexiones externas y actúan de gateway

a esos servicios. Por esa razón se les conoce también como gateways del nivel de

aplicación.

Los sistemas proxy, permanecen más o menos de manera transparente entre el

usuario dentro de la red y el servicio fuera de la red. En vez de hablar directamente

uno con el otro cada uno de ellos habla con el proxy. Estos tratan las conexcion

entre usuarios y los servicios de una manera transparente.

20

3 INTRODUCCIÓN A LOS FIREWALLS 3.5 Arquitecturas Firewall

La transparencia es el mayor beneficio de los servicios proxy. Para el usuario,

un proxy presenta la ilusión que esta tratando directamente con el servidor real.

Para el servidor real, el proxy presenta la ilusión de que está tratando directamente

con un usuario en el ordenador del proxy, en vez de ser el auténtico usuario en otro

ordenador.

Los servicios proxy son efectivos solo cuando se usan en conjunción con al-

gún mecanismo que restringe las comunicaciones directas entre los ordenadores

externos e internos. Si los hosts internos pueden comunicarse directamente con los

hosts externos no hay razón alguna para tener un proxy. Un proxy es una solución

software, deben usarse conjuntamente con un firewall.

Los servidores proxy no solo redirecciona el tráfico de los usuarios a los ser-

vicios externos de Internet. Los servidores proxy controlan lo que estos hacen,

porque escucha todo lo que hacen los usuarios y según las políticas de seguridad

dejará pasar el contenido. Por ejemplo un proxy web puede bloquear todas las

páginas web que contengan VBScript pues estos ejecutan programas que pueden

llegar a ser muy peligrosos. Y todo de una manera transparente al usuario.

3.4.3. Combinación de técnicas

La ’buena solución’ es aquella que no se basa en una única técnica, sino aquela

que usa cuidadosamente la combinación de varias técnicas para resolver diferentes

problemas. Los problemas que debes resolver dependen en qué servicios quieres

proveer a los usuarios y qué nivel de riesto estas dispuesto a aceptar. Y las técnicas

también dependen del dinero, tiempo y experiencia de la que dispones.

Algunas protocolos se pueden tratar mejor con filtrado de paquetes como pue-

de ser SMTP y SSH. Y otros servicios se tratan mejor con proxies como puede

ser los servicios FTP, Gopher y HTTP.

3.5. Arquitecturas Firewall

Esta sección describe una variedad de maneras de las que podemos disponer

los firewalls, las redes de ordenadores o servidores y los routers. Dependiendo de

la funcionalidad que le queramos dar a la red se escoge una u otra arquitectura.

21


3.5.1. Dual-Homed Host

La arquitectura para un firewall Dual-Homed Host es muy simple: el ordena-

dor Dual-Homed Host se situa antes de la red a proteger, conectado directamente,

entre la red interna e Internet.

Esta arquitectura se construye alrededor del ordenador dual-homed host, es un

ordenador que tiene al menos dos interfaces de red. Aún siendo capaz de enrutar

paquetes IP de una a otra red, si se implementa una aquitectura Dual-Homed Host

se restringe esta función de enrutaje. Lo que hace que los paquetes de una red no

se conectan directamente a la otra red. Los sistemas dentro del firewall pueden

comunicarse con el Dual-Homed Host, y los sistemas fuera del firewall (de Inter-

net) puede comunicarse con el Dual-Homed Host, pero estos sistemas no pueden

comunicarse entre ellos. El tráfico IP está completamente bloqueado. Todo tráfico

hacia fuera lo debe originar el firewall.

Esta arquitectura puede proveer un gran nivel de control. Ya que todos los pa-

quetes se originan en el firewall. Se puede asegurar además que cualquier paquete

dentro de la red interna que tenga la dirección origen con una IP externa es origen

de algún tipo de problema de seguridad.

La única manera que tienen la red interna de conectarse con el exterior es

através de servicios proxy localizados en el firewall, y através de este servir de

conexión. Pero presenta un inconveniente, y es que no todos los servicios pueden

22


pasarse por Proxy y lo que indica que los usuarios deberían tener cuentas de usua-

rio en el firewall y conectarse al exterior desde él mismo. Lo que es incómodo

para los usuarios y un posible agujero provinente de usuarios internos.

3.5.2. Screened Host

En esta aquitectura se usa un router para conectar las redes internas y externas

(Internet), pero se configura el router con filtrado de paquetes para que no se

puedan conectar directamente las redes internas y externas, a no ser que sea a

través del bastion host que hace la función de proxy.

El host bastion se sitúa en la red interna. El filtraje de paquetes se hace en el

Screened Host (router) que se configura para que el bastion host sea el único capaz

de recibir conexiones externas. Cualquier sistema externo que intente acceder al

sistema interno o a los servicios internos deberá hacerlo a través del bastion host.

Por ello este host debe mantener un gran nivel de seguridad.

Además el Screened Host usando el filtraje de paquetes indicará que conexio-

nes se permiten desde la red interna al mundo externo, siguiendo las políticas de

seguridad. Algunos de los servicios externos pueden hacerse bien directamente a

traves del Screened Host o bien a través del bastion host mediante el proxy.

Como esta arquitectura permite pasar paquetes de fuera a dentro de la red,

puede parecer más inseguro que una arquitectura dual-homed host, que está di-

23


señada para que ningún paquete externo entre a la red interna. Pero en la arqui-

tectura Screened Host es más fácil defender el router, que provee servicios muy

limitados, comparado con el dual-homed host. Para la mayoría de propósitos, el

Screened Host provee mejor seguridad y mejor usabilidad que la Dual-Homed

host. Pero comparada con la arquitectura siguiente, hay desventajas. La mayor es

que si un atacante llega a controlar el bastion host, entonces toda la red interna es-

ta expuesta. El router también representa un único punto de fallo. Por eso mismo

la siguiente arquitectura es más popular.

3.5.3. Screened Subnet

La arquitectura Screened Subnet añade una capa de seguridad extra a la ante-

rior arquitectura, añadiendo una red de perímetro o también perimeter network en

inglés, que aisla la red interna de Internet. La topologia es situar un router conec-

tado a Internet, tras el router una red con un host bastion haciendo las funciones

proxy y conectado a la perimeter network, y en esa misma red se conecta otro

router que da acceso a la red interna.

¿Por qué hacer esto? Por su propia naturaleza, los ordenadores bastion son las

máquinas más vulnerables de la red. A pesar de todos los esfuerzos por mantener-

las protegidas, son las máquinas que se atacan principalmente, porque son ellas

las que pueden atacarse. Si, en una arquitectura screened host, esta abierta a un

ataque desde el host bastion, entonces el host bastion es un target muy jugoso,

porque no hay defensas entre este y las otras máquinas. Si alguien rompiese la

seguridad del bastion host en una arquitectura Screened Host entonces es como si

le tocase el gordo, esta dentro de la misma red interna con todos los ordenadores

indefensos. En cambio en una arquitectura Screende Subnet si penetra en el host

bastion no puede dañar al resto de ordenadores, por estar aislado, sigue siendo

peligroso porque puede instalar un snifer, pero no acceder directamente a la red

interna.

24


La manera más simple de crear una arquitectura Screende Subnet es conec-

tando dos routers a la red de perímetro (perimeter net). Una entre la perimeter net

y la red interna, y otro entre la perimeter net y la conexión externa (normalmente

Internet). Para romper dentro de la red interna con este tipo de arquitectura el ata-

cante debería pasar através de los dos routers. Incluso si el atacante consiguiese

romper el bastion host aun le quedaría pasar el router interno.

A veces para ir más allá, se crean una serie de redes perimetrales entre el

mundo externo y la red interior. Dependiendo de lo seguras y confiables que son

los servicios que se ponen en cada perímetro. Los servicios más vulnerables se

ponen en las redes externas y la red interna se pone al principio. Es un fallo de

seguridad lo que voy a decir pero es tal mi confianza en esta topologia que no

me importa decir que es así como tengo configurado los sistemas que están a mi

cargo.

Red perimetral

La red perimetral es como he comentado antes, otra capa de seguridad, una red

adicional entre las redes externas y la red interna que se trata de proteger. Si un

atacante consigue romper dentro de una red perimetral puede conseguir atacar los

servicios que se trate dentro de la red. Dentro de la red perimetral pueden ponerse

25


los servidores FTP y WWW, en caso de ser atacado y tener éxito el ataque pueden

tener el acceso al ordendor y tras ello se puede acceder a la red perimetral pero no

pasar a la red interna.

Router interno

El router interno (a veces llamado choke router en literatura inglesa) protege

la red interna de Internet y de la red perimetral.

Este router hace la mayoría del filtraje de paquetes. Permite que algunos ser-

vicios salir de la red interna a Internet. Estos servicios son los servicios que son

mejor usar filtrado de paquetes que los proxies. Y los servicios que solo debe per-

mitir ir al host bastion son aquellos que es mejor pasarlos por el proxy. También

debe limitarse las conexiones permitidas para la red interna.

3.5.4. Variaciones posibles

Se ha visto las principales configuraciones posibles, pero dependiendo del di-

nero disponible, las políticas de seguridad, de los intereses y servicios a dar, de-

bemos disponer de una flexiblidad suficiente para configurar y combinar compo-

nentes firewall. Estas son las posibles variaciones, algunas las he usado y otras no

he podido, debido principalmente al dinero.

Varios hosts bastion

Solo se ha hablado de un bastion host que sirviese para concentrar todos los

servicios. Es una buena idea usar varios host en vez de uno, en nuestra configu-

ración. Las razones pueden ser varias, para mejorar la redundancia, para mejorar

la performance del sistema o simplemente para simplificar la administración de

cada bastion host. También puede dividirse según la confianza que se tenga por

los servicios a tratar, así se puede tener especial cuidado en aquello que puedan

representar una amenza, así un servicio no puede comprometer otros.

26


Juntar el router externo con el interno

Se pueden juntar el router interno con el externo en un único router, pero solo

si se tiene un router suficiente capaz y flexible para hacerlo, hoy dia la mayoría de

routers lo permiten. Tenemos la red perimetral conectada a una interficie del router

y la red interna conectada a la otra interficie. Dentro de la perimeter Network

podemos tener un bastion host haciendo las funciones de proxy, para tal caso

hay que configurar en el router el filtrado de paquetes convenientemente. Esta

arquitectura, igual que la screened host, hace del único router un punto vulnerable

para comprometer a toda la red. En general los routers son fáciles de proteger, más

que los servidores, pero igualmente no son impenetrables.

27

4 FILTRADO DE PAQUETES

4. Filtrado de paquetes

4.1. Introducción

Como he comentado en la sección de introducción a los firewalls, el filtrado

de paquetes es uno de los dos tipos de firewalls que existe, el otro sistema es el

firewall proxy. Cada uno sube hasta un nivel concreto de la capa OSI. Mientras el

primero solo trata hasta el nivel 3 de la capa OSI, donde se encuentran los paquetes

y basa sus decisiones en la información que hay en la cabecera del paquete IP. La

otra, los sistemas proxy, sube hasta en nivel de aplicación, pues debe basar sus

decisiones en la información que hay en los datos del nivel más alto. El trabajo

solo aborda el primer sistema, y es por eso que se profundiza más en este sistema:

el filtrado de paquetes.

El filtrado de paquetes es un mecanismo de seguridad que trabaja controlando

los datos que vienen y van por la red. Es necesario tener claro los fundamentos que

se han explicado en la sección TCP/IP para enteder correctamente este apartado.

Al transferir información a través de la red, la información esta troceada en

pequeñas piezas, cada una de ellas se envía separadamente. Rompiendo la in-

formación en partes permite a los sitemas compartir la red, enviando piezas por

turnos. En las redes IP, que son las que trato en el trabajo, estas piezas de datos

se llaman paquetes. Todos los datos que se transfieren a través de las redes IP se

hace en forma de paquetes.

Los equipos básicos que interconecta redes IP se llaman routers. Un router

puede ser una pieza dedicada de hardware si otro propósito, o puede ser también

un software que corre en un sistema de propósito general como un PC. Los paque-

tes atravesando una red viajan de un router a otro hasta llegar a su destino. Internet

es en sí misma un red de redes.

Los routers deciden el destino para cada paquete que reciven, tienen que de-

cidir a dónde enviarlo basándose en el destino final del paquete. En general, un

paquete no lleva ninguna otra información que la IP de destino para ayudar al

router a tomar su decisión. El paquete dice al router donde quiere ir, pero no por

donde lo debe enviar. Los routers se comunican entre ellos usando los ’protocolos

de routing’ o ’protocolos de enrutaje’ según el idioma, como por ejemplo Routing

28

4 FILTRADO DE PAQUETES 4.2 Características

Information Protocol (RIP) como uno de los más simples, o bien Open Shortest

Path First (OSPF) para construir las tablas de enrutaje o tablas de routing, con

las que determinan como enviar los paquetes a sus destinos. Cuando se enruta un

paquete, el router compara la dirección de destino con las entradas que dispone

en la tabla de routing y envía el paquete a través de la interfaz que se indica en

la misma tabla. Muchas veces no hay una ruta específica para un destino en par-

ticular, entonces el router usa la ruta por defecto o también ’default gateway’ que

es como yo lo conozco, y se envía a routers que están mejor conectados o a los

routers que se supone pueden saber el destino.

Al determinar como enviar un paquete a su destino, un router mira solo la

dirección destino del paquete y se pregunta ’¿a donde debo enviar este paquete?’.

pero además se considera la pregunta ’¿debo enviar este paquete?’ ya que o bien

por la política de seguridad programa en el router es mejor descartar el paquete

o bien porque a lo mejor el destino no es accesible y es mejor borrar el paquete

para que deje de dar vueltas. Para la primera opción se usa lo que se llama filtrado

de paquetes, para la segunda opción se trata el campo TTL (Time To Live). Nos

concentraremos en el filtrado de paquetes, que es el objetivo de este trabajo final

de carrera.

4.2. Características

La principal ventaja del filtrado de paquetes es poder proveer, en un único sitio,

protecciones para toda un red. Considerando el servicio Telnet como ejemplo. Si

se prohibe el Telnet cerrando en servicio de telnet en todos los ordenadores, aún

hay que tener cuidado y preocuparse por si alguien de la organización instala en

una nueva máquina un servidor de Telnet. Por otra parte, si es telnet se desactiva

desde el router, filtrando todos los paquetes que vayan a servir a tal propósito, se

protege a la red desde el principio, si importar si hay alguien utilizando un servidor

Telnet o no. Otra ventaja es que los routers suelen ser pocos, muchos menos que

servidores, por eso se supone que se puede aplicar un mayor control concentrando

la seguridad en ellos.

Ciertas protecciones solo pueden proveerse con routers de filtrado de paque-

tes, y solo cuando se situan en ciertas localizaciones de la red. Por ejemplo, es una

29

4 FILTRADO DE PAQUETES 4.3 Ventajas

buena idea parar todos los paquetes que tengan como dirección de origen una IP

que pertenece a una máquina interna, porque lo más seguro que se esté intentando

un ataque spoofing. En estos ataques, un atacante pretende suplantar a otra má-

quina ’amiga’ o conocida ocultando su identidad. La solución es bloquear todos

los paquetes entrantes con una IP origen que pertenezca a la red interna. Este tipo

de soluciones solo pueden hacerse con un router o firewall que tenga la opcción

de filtrado de paquetes y que esté situado en el perímetro de la red. Y únicamente

un router en esa loclización (por perímetro se entiende que conecta las dos redes a

través de él) es capaz de reconocer un paquete así, mirando las direcciones origen

de todos los paquetes que entren desde fuera de la red.

4.3. Ventajas

Ya he comentado algunas en el punto anterior, pero aquí se listan todas ellas:

4.3.1. Proteger toda la red

Como he comentado una de las claves dentro de las ventajas de un router

con filtrado de paquetes es que un router único y estratégicamente situado puede

ayudar a proteger toda un red. Si sólo hay un router que conecta tu red con Internet,

30

4 FILTRADO DE PAQUETES 4.3 Ventajas

se gana facilidad a la hora de proteger la red, sea cual sea el tamaño de la red

interna, si se hace correctamente en ese router externo que da conexión a Internet.

4.3.2. Transparencia

Como diferencia al proxy, los sistemas con filtrado de paquetes no requieren

ningún tipo de software ni configuración en las máquinas de los clientes, no re-

quiere ningún tipo de enseñanza ni explicación a los usuarios. Cuando un router

con filtrado de paquetes decide lanzar un paquete, este no se distinge de otro router

normal sin esa aplicación. Los usuarios no sabrán que existe, a no ser que inten-

ten hacer algo que esté prohibido (supuestamente por un problema de seguridad)

según la política de seguridad que se le aplique al router con filtrado de paquetes.

Esta transparencia significa que un router filtrando paquetes puede hacerse

sin la cooperación y sin el conocimiento de los usuarios a los que se les da el

servicio de conexión. La clave no es hacer cosas a urtadillas de los usuarios, a sus

espaldas. Sino que la clave está en que puedes hacer filtrado de paquetes sin tener

que enseñarles nada para que trabajen, y sin depender la seguridad en ellos para

que algo funcione correctamente. Recuerdo que para protegerse de los virus es

recomendable educarles, y es tedioso y aún así no siempre funciona.

4.3.3. Disponibilidad

El filtrado de paquetes está disponible en la mayoría de hardware y software de

los productos que hacen routing, ambos tanto comerciales como los distribuidos

gratuitamente. La mayoría de routers también tienen capacidades de filtrado de

paquetes.

Es una ventaja pues tras diseñar una política de seguridad es muy probable

que dispongamos de la capacidad de filtrado de paquetes por parte del router.

4.3.4. Latencia

Si comparamos el filtrado de paquetes con los sitemas proxy tenemos que con

la misma potencia en hardware se consigue menos latencia. Esto es debido a que

el filtrado de paquetes solo tiene que llegar al nivel IP. Además las decisiones se

31

4 FILTRADO DE PAQUETES 4.4 Desventajas

toman según una pequeña parte de los datos que transitan, la cabecera IP, y no es

necesario investigar todos los datos de contenido de los datos que transitan.

4.4. Desventajas

Dentro de las características de los sistemas de filtrado de paquetes encontra-

mos también desventajas, y entre todas ellas tenemos que:

4.4.1. Protocolos difíciles

Aunque la implementación de las políticas de seguridad sean perfectas, encon-

tramos que hay ciertos protocolos que simplemente no se pueden tratar facilmente

usando este tipo de sistemas, las razones pueden ser varias, como por ejemplo la

forma de establecer las sesiones FTP o en las sesiones de teleconferencia que

usan el protocolo H.323 pues hay varios origenes de la conexión, los protocolos

basados en RPC como por ejemplo NFS y NIS/YP tampoco son fáciles de tratar.

Ciertos protocolos, como por ejemplo FTP, H323 entre otros mantienen en sus

conexiones unas sesiones características debido a que el cliente y servidor hacen

los dos funciones de cliente y de servidor. Por ejemplo el File Transfer Protocol

es uno de ellos, el cliente FTP se conecta al servidor FTP mediante TCP al puerto

21 por defecto, entonces cuando hay cualquier petición el servidor envía los datos

mediante UDP saliendo del puerto 20. Estos datos lo más normal es que se hayan

bloqueado en el firewall para proteger la red interna, porque no se puede dejar

abierto ya que cualquier atacante lo usaría. La solución pasa por tener unas tablas

indicando las sesiones que están en funcionamiento, y cuando se detecte un pa-

quete con el bit de reset activado entonces quitar la sesion de las tablas. Entonces

si el firewall ve que le llegan datos UDP de fuera hacia dentro comprueba que

exista esa IP dentro de la tabla de sesiones y que el puerto origen sea el 20. En

tal caso deja pasar los datos porque se trata de una conexión FTP que ha inciado

alguien dentro de la red que se está protegiendo.

32

4 FILTRADO DE PAQUETES 4.5 Configuración

4.4.2. Polítcas que no pueden aplicarse

La información que un paquete da al router que filtra los paquetes no es su-

ficiente para según que política de seguridad. Por ejemplo, los paquetes indican

de que ordenador provienen pero no de que usuario. Por eso, no se pueden ha-

cer restricciones en usuarios específicos, sino que a las máquinas que estos usan

normalmente. De igual forma, los paquetes dicen a que puerto van pero no a qué

aplicación, cuando se hacen restricciones por portocolo se hacen por el número

de puerto, esperando que nadie este ejecutando el mismo servicio en un puerto

que no se le asigna por defecto. La gente de dentro de la organización que tengan

control sobre sus máquinas pueden hacer cambios en este sentido de un manera

fácil.

4.4.3. Spoofing

Ya he nombrado antes los ataques spoofing, los números IP del origen pueden

modificarse y para asegurarse de que el emisor es quien dices ser tiene que usarse

otras técnicas, en el mismo nivel de la torre OSI como por ejemplo IPSec o bien en

niveles superiores de la torre OSI, por encima del nivel de transporte, como puede

ser Secure SHell conocido como SSH, que intercambia claves de los servidores y

no se basa únicamente en las IP’s de las dos partes para crear una sesión.

4.5. Configuración

Para configurar un router con filtrado de paquetes, lo primero es decidir qué

servicios se va a permitir y qué servicios se van a prohibir, entonces se traduce

las decisiones en reglas para los paquetes. En realidad, probablemente no importa

los detalles de los paquetes. Lo importante para cada uno es hacer el trabajo bien

y que funcione. Por ejemplo, si se quiere recibir correo de Internet, al jefe no le

importa si los paquetes los tratan el fantasma del ordenador eso es irrelevante,

para él solo quiere recibir el correo. Esto puede causar que se hagan unas reglas

poco restrictivas, y así funcione el correo que tanto le interesa al jefe. Pero que

funcione no significa que esté bien hecho. Y es que traducir “quiero recibir correo

de Internet” en un grupo de reglas bien hechas requiere entender como funciona

33

4 FILTRADO DE PAQUETES 4.5 Configuración

y seguir un conjunto de reglas. A continuación paso a explicar concepto que son

necesarios tener en mente a la hora de traducir decisiones sobre los servicios en

reglas para paquetes.

4.5.1. Bidireccionalidad

Los protocolos en su mayoría son bidireccionales; casi siempre son las dos

partes las que envían datos, una enviando un comando o una petición, y la otra

parte enviando la respuesta del comando o retornando otros datos. Cuando se pla-

nea crear las reglas para el filtrado de paquetes es necesario recordad que los pa-

quetes tienen doble sentido. Por ejemplo, no tienen ningún sentido dejar enviar los

comandos en el Telnet y permitir que los paquetes salgan, pero en cambio prohibir

que los resultados de los comandos no puedan verse prohibiendo el retorno de los

paquetes.

Por otra parte, no ayuda si se bloquea solo la mitad de la conexión. ya que

muchos ataques pueden conseguirse si el atacante puede enviar paquetes a la red,

incluso si el atacante no obtiene ninguna respuesta. Es posible porque las respues-

tas pueden ser predecidas, y permite a los atacantes mantener una conversación

sin necesitar ver las respuestas. Por ejemplo, si las respuestas son predecibles, pe-

ro no pueden ver las respuestas porque no se permite retornar los datos, puede que

no se permita conseguir datos directamente, por ejemplo cuando no pueden ver el

fichero de /etc/passwd directamente, pero pueden mandar un comando para enviar

un email a ellos mismos con una copia del mismo fichero.

4.5.2. ’Inbound’ y ’Outbound’

Una significa tráfico entrante, inbound, y outbound significa tráfico saliente

o hacia fuera. Cuando se planea una estrategia de filtrado de paquetes, se nece-

sita tener especial cuidado por que se entiende por ’inbound’ y ’outbound’. Hay

que distinguir claramente que se entiende por paquetes entrantes ’inbound’ y los

paquetes salientes ’outbound’, y por otroa parte los servicios inbound y los servi-

cios outbound. Un servicio outbound o saliente (por ejemplo un servicio Telnet)

tiene paquetes salientes (los comandos) y paquetes entrantes (las respuestas de la

pantalla). Aunque la mayoría de la gente piense habitualmente en términos de ser-

34

4 FILTRADO DE PAQUETES 4.6 Que hacer

vicios, hay que pensar claramente en términos de paquetes cuando se trata con el

filtrado de paquetes. Cuando se habla de filtrado de paquetes, lo más importante

es la dirección de los paquetes y no de los servicios.

4.5.3. Permitir por defecto versus denegar por defecto

Este punto es epecialmente importante a la hora de configurar las reglas de

filtrado de paquetes. Se distinguen entre dos tipos de reglas, se puede escoger o

bien poner las políticas de seguridad con una regla de negado por defecto (todo

aquello que no se expresa específicamente que está permitido se niega) o bien la

regla de permitir por defecto (todo aquello que no se especifica específicamente

como prohibido se permite). Desde el punto de vista de seguridad, es mucho más

seguro tomar la actitud de que las cosas están negadas por defecto. Y las reglas

de configuración deben reflejarlos. Es necesario empezar por la posición de negar

todo y después poner las reglas que permitan solo los protocolos que se permiten,

entender las implicaciones que tiene en la seguridad es sumamente importante.

La posición de negarlo todo por defecto es mucho más segura y mucho más

efectiva que permitirlo todo por defecto, lo que indica que permitiendo todo por

defecto e intentando bloquear aquellas cosas que sabes que dan problemas. La

realidad es que con esa aproximación, nunca se sabe todos los posibles problemas,

porque siempre aparece nuevos problemas y por lo tanto nunca se completa el

trabajo.

Hablando de manera práctica, la negación de todo significa que las reglas de

filtrado deben ser una lista pequeña de las cosas que se permiten, seguido de un

negado por defecto que cubra todo el resto de paquetes. Luego pasaré a explicar

como deben ser estas reglas.

4.6. Que hacer

Una vez un PC con filtrado de paquetes haya terminado de examinar un pa-

quete, ¿qué hacer con el paquete? Principalmente hay dos opciones siempre ba-

sándose en el las reglas de configuración:

1. Pasará el paquete. Si el paquete pasa el criterio de filtrado, el router pasará

35


el paquete allá donde indique la tabla de routing, que la dirección que debe

seguir, como si fuera un router normal sin el filtrado de paquetes compor-

tándose de manera transparente.

2. Eliminar el paquete. La otra acción obviamente es eliminar el paquete si

falla en los criterios con que se ha configurado el filtrado.

Sea unos u otros el tipo de paquetes, el filtrado de paquetes debe suministrar dos

herramientas básicas para el correcto funcionamiento, la primera es hacer un log

de los paquetes que le hayamos indicado que haga y la otra es devolver paquetes

ICMP indicando el tipo de error en caso de no dejar pasar el paquete.

4.6.1. Logging

Independientemente de si se deja pasar o no el paquete, puede querer el ad-

ministrador que se guarde la acción que se acaba de tratar. Especialmente cuando

hay paquetes que se han eliminado, porque al ir en contra de las reglas de filtrado

de paquetes se puede tratar de un ataque y es necesario tener constancia de ello.

No se recomienda a su vez hacer un log de todos los paquetes que pasan por

el filtrado de paquetes, pues fácilmente se sobresaturarían los discos además de

relentizar de manera drástica el ordenador. Pero si es necesario para cierto grupo

de paquetes. Por ejemplo, puede ser interesante mantener un log de los paquetes

TCP que indiquen comienzo de conexión hacía un servicio Telnet de un router

específico, así se guarda las conexiones que se hayan realizado para una posible

configuración. Aunque no todos las aplicaciones comerciales y no comerciales de

filtrado de paquetes dejan hacer un log a los paquetes permitidos en mi aplicación

sí se puede.

Dependiendo de la implementación del filtrado de paquetes hay diferentes for-

mas de hacer log. Algunos guardarán solo la información específica sobre el pa-

quete, otros en cambio guardarán el paquete entero para un posterior estudio. Ge-

neralmente, el filtrado de paqutes necesitará configurarse para hacer el log a otra

parte mediante el servicio de syslog, que es independiente a la aplicación. Porque

es interesante no tener únicamente una copia de la provinencia de un ataque si el

firewall se ha visto comprometido, pues es fácil eliminarlo y parecer que no ha

habido tal ataque.

36


4.6.2. Paquetes ICMP

Si un paquete es eliminado, el router debe o no enviar un paquete ICMP de

error indicando qué ha pasado. Enviando un paquete ICMP de error tiene un efecto

en el equipo emisor para indicarle que no vuelva a enviar otro paquete, lo que

ahorra algo en el tráfico de la red y algo de tiempo al usuario que le ha sido

negado el acceso, ya que al recibir un código de error ICMP el host del usuario no

debe reintentar y para inmediatamente, si no recibe ninguno puede tardar varios

minutos esperando una respuesta.

Hay dos grupos relevante de códigos ICMP a escoger:

1. Los códigos de ’destino inalcanzable’ o ’destination unreachable’ en par-

ticular el de ’ordenador inalcanzable’ o ’host unreachable’ y el código de

’red inalcanzable’ o ’network unreachable’ según el idioma. Los diseñado-

res del primer grupo de códigos de error ICMP diseñaron este grupo de ’host

unreachable’ y el de ’network unreachable’, para indicar algún problema se-

rio en la red: el host o red destino ha caido o algo que en el único camino al

host o red ha caido. Estos errores se tratan devolviendo uno de estos erro-

res en paquetes ICMP desde el router que haya descubierto el problema. Si

cualquier máquina recibe un ’host unreachable’ para un host dado, asumi-

rá que el host se encuentra completamente inalcanzable y cerrará todas las

conexiones hacia él, incluso si las otras conexiones se permitireron por el

filtrado de paquetes. Por eso hay que tener cuidado a la hora de enviar este

tipo de errores.

2. Los códigos de ’destino administrativamene inalcanzable’ o ’destination ad-

ministratively unreachable’ en particular dentro de este grupo el de ’orde-

nador administrativamente inalcanzable’ o en inglés ’host administratively

unreachable’ y el código de ’red administrativamente inalcanzable’ o como

se encuentra en la literatura inglesa ’network administratively unreachable’.

Indican que el destino puede ser accedido porque no ha caido pero que no

se deja pasar ningún paquete debido a la configuración del sistema y que

todo paquete a ese destino se ha bloqueado. Este segundo grupo de erro-

res que pueden retornar un administrativamente inalcanzable se añadieron

37


hace unos años al grupo de mensajes ICMP, específicamente para dar a los

sistemas de filtrado de paquetes algo que poder retornar cuando eliminaban

un paquete. Muchos sistemas pueden no reconocer estos códigos, aunque

tampoco deben causar ningún problema, porque los sistemas que reciben

un código que no entienden simplemente deben ignorarlo, que significa que

es como si no se hubiera enviado ningún mensaje. Pero que no haga caso al

mensaje es útil de manera que al recibir este mensaje el sistema no se verá

afectado.

¿Cúal es la correcta? De los dos grupos de mensajes a retornar, si retornamos

uno del primer grupo ’host unreachable’ o bien el de ’network unreachable’ es

técnicamente incorrecto, recordar que los hosts puede o puede que no sean alcan-

zables, de acuerdo con la política de filtrado de paquetes, dependiendo a qué host

está intentando acceder y a qué servicio. También hay que recordar que este tipo

de códigos pueden causar en muchos sistemas una reacción excesiva, como por

ejemplo cerrando todas las conexciones que ya están abiertas hacia ese host o red

en cuestión.

Si devolvemos un ’host administratively unreachable’ o un ’network adminis-

tratively unreachable’ se advierte que el paquete que está siendo filtrado al destino

desde ese origen. Estos códigos teóricamente, no deberían de tener una respuesta

excesiva al llegar al ordenardor que intentaba originar la conexión.

Hay otras consideraciones, por ejemplo, generando y retornando códigos de

error ICMP necesita un cierto tiempo y esfuerzo por parte del router o firewall

con el software de filtrado de paquetes. Un atacante podría montarse un ataque de

denegación de servicio o denial of service según se diga, saturando el router con

paquetes que debería rechazar, generando paquetes con códigos de error ICMP.

Lo que se trata de proteger no es el ancho de banda de la red, sino la cantidad de

carga sobre la CPU en el router o firewall en cuestión, y mientras está generando

paquetes ICMP no está tratando paquetes entrantes. Por otra parte si no se retorna

códigos de error ICMP puede causar un exceso de tráfico en la red, pues el emisor

puede intentar e intentar enviar paquetes que han sido eliminados. Este tráfico no

debería de ser mucho, pues el número de paquetes bloqueados por el sistema de

filtrado tiende a ser una fracción del total de paquetes procesados. En caso de no

38

4 FILTRADO DE PAQUETES 4.7 Filtrado por dirección

ser así es muy posible que se esté bajo un ataque de DoS o denegación de servicio.

Por otra parte, retornando paquetes con códigos de error ICMP para cada pa-

quete que viola las políticas de filtrado, estás dando información a un atacante y

un camino para probar el sistema de filtrado. Observando los paquetes que retorna

una respuesta ICMP, un atacante puede descubrir que tipo de paquetes violan o no

violan las políticas de seguridad. En tales casos no se debería dar esa información,

porque simplifica enormemente el trabajo del atacante. El atacnte conoce que pa-

quetes no genera errores ICMP van a alguna parte, y puede concentrarse en esos

servicios para empezar a atacar, donde muy posiblemente haya vulnerabilidades,

a no ser que esté todo bien configurado y actualizado. En cambio si no se retorna

esa información con los códigos de error ICMP el atacante necesita más tiempo

para averiguar la misma información, si acaso lo consigue. Devolviendo los có-

digos de error ICMP se acelera los ataques, si reciben errores ICMP por algo no

tienen q esperar el timeout.

Como conclusión, lo más seguro parece que es no retornar ningún código de

error ICMP a los paquetes eliminados. Si se puede lo que es interesante es poder

retornar paqutes con códigos de error ICMP a los sistemas internos, para que no

esperen al timeout y por otra parte no retornarlo a los sitemas externos. Aún así si

no se ofrece tal posibilidad se debe configurar el sistema para que esté permitido

los paquetes inbound ICMP y estar prohibido los paquetes outbound con códigos

de error ICMP.

4.7. Filtrado por dirección


La forma más simple, aunque no la más común, es el filtrado de paquetes

filtrando según la dirección. Filtrando de esta forma termite restringir el flujo de

paquetes basado en la dirección origen y/o destino de los paquetes, sin cosiderar el

protocolo que tratan. Este tipo de filtrado puede ser usado para permitir o no cierto

flujo entre unos hosts internos a unos hosts externos, por ejemplo, por ejemplo se

puede prever un ataque de spoofing, simplemente prohibiendo paquetes inbound

con una dirección origen que sea igual a una dirección válida dentro de la red a

proteger.

39


Por ejemplo vamos a decir que se quieren prohibir este tipo de ataques, se

debería especificar esta regla:

Dirección @ origen @ destino Acción

Inbound interna any deny

Donde pone que la dirección es interna se refiere a cualquier número IP de algún

host de dentro de la red. En el router que haya entre la red interna e Internet, se

podría aplicar en cualquier interfaz con paquetes inbound esta regla. Cuando se

habla de inbound ser refiere a la red interna que debemos proteger.

4.7.2. Riesgos

Antes lo he comentado, no es seguro fiarse de las direcciones origen en las

cabeceras IP ya que pueden suplantarse, pueden modificarse. Solo en caso de que

se use algún tipo de autentificación criptográfica entre tú y el host al que se quiere

hablar, no sabes si el que te está hablando es quien dice ser u otra máquina que

pretende ser ese. Como he dicho antes hay que montarse algo usar otras técnicas,

ya sea en el mismo nivel de la torre OSI como por ejemplo IPSec o bien en niveles

superiores de la torre OSI, por encima del nivel de transporte, como puede ser

Secure SHell conocido como SSH, que intercambian claves de los servidores y no

se basa únicamente en las IP’s de las dos partes para crear una sesión, sino que

usan encriptado.

Hay dos tipos de ataques que se basan en esta forma de ataque de ataques

spoofing: los que se necesitan solo modificar la dirección origen y los de ’man in

the middle’, que ademas hay que mirar que se retorna.

40


El primer ataque spoofing que se conoce se le atribuye a Kevin Mitnick uno de

los hackers más conocidos. El atacante envía paquetes que pretenden suplantar la

identidad de algún ordenador al que se le tiene algún tipo de confianza, esperando

que el ordenador atacante pueda usar esa confianza ataca al ordenador objetivo.

Puede ser que el atacante no le importe retornar ningún paquete de la máquina

atacada, ya que el resultado de los comandos enviados son predevibles, entonces

no necesita estar en el camino de retorno entre el ordenador atacado y el ordenador

que suplanta la información. En cambio es al contrario si se desea saber que le

retorna al ordenador suplantado, ya que habrá que situarse entre medio para que

cuando le devuelva los paquetes el ordenador atacado al suplantado se puedan

leer pero este es el segundo tipo de ataques. Ya que las respuestas se enviarán al

ordenador suplantado y no al atacante. También hay que tener una consideración,

que el ordenador suplantado recibirá paquetes de conexiones que no entiende y

de las que no participa, bogus connections como se le llama en inglés, entonces

este ordenador envía paquetes con el bit de reset activado para terminar dichas

conexiones. Lo que es malo para el atacante, pero es fácil de remediar, ya que

se puede suplantar una máquina que no exista, destrozando a la máquina real

mediante un ataque, inundando a la máquina suplantada, modificando la ruta entre

la máquina atacada y la suplantada o bien usando ataques donde no sea importante

el bit de reset.

41

5 EL SISTEMA OPERATIVO LINUX

5. El Sistema Operativo Linux

5.1. Introducción

5.1.1. Historia

A finales de los 40’s el uso de computadoras estaba restringido a aquellas em-

presas o instituciones que podían pagar su alto precio, y no existían los sistemas

operativos. En su lugar, el programador debía tener un conocimiento y contacto

profundo con el hardware, y en el infortunado caso de que su programa fallara, de-

bía examinar los valores de los registros y páneles de luces indicadoras del estado

de la computadora para determinar la causa del fallo y poder corregir su progra-

ma, además de enfrentarse nuevamente a los procedimientos de apartar tiempo

del sistema y poner a punto los compiladores, ligadores, etc; para volver a correr

su programa, es decir, enfrentaba el problema del procesamiento serial ( serial

processing ).

La importancia de los sistemas operativos nace históricamente desde los 50’s,

cuando se hizo evidente que el operar una computadora por medio de tableros

enchufables en la primera generación y luego por medio del trabajo en lote en

la segunda generación se podía mejorar notoriamente, pues el operador realizaba

siempre una secuencia de pasos repetitivos, lo cual es una de las características

contempladas en la definición de lo que es un programa. Es decir, se comenzó a

ver que las tareas mismas del operador podían plasmarse en un programa, el cual

a través del tiempo y por su enorme complejidad se le llamó "Sistema Operativo".

Así, tenemos entre los primeros sistemas operativos al Fortran Monitor System (

FMS ) e IBSYS.

Posteriormente, en la tercera generación de computadoras nace uno de los

primeros sistemas operativos con la filosofía de administrar una familia de com-

putadoras: el OS/360 de IBM. Fue este un proyecto tan novedoso y ambicioso

que enfrentó por primera vez una serie de problemas conflictivos debido a que

anteriormente las computadoras eran creadas para dos propósitos en general: el

comercial y el científico. Así, al tratar de crear un solo sistema operativo para

computadoras que podían dedicarse a un propósito, al otro o ambos, puso en evi-

dencia la problemática del trabajo en equipos de análisis, diseño e implantación

42

5 EL SISTEMA OPERATIVO LINUX 5.1 Introducción

de sistemas grandes. El resultado fue un sistema del cual uno de sus mismos di-

señadores patentizó su opinión en la portada de un libro: una horda de bestias

prehistóricas atascadas en un foso de brea.

Surge también en la tercera generación de computadoras el concepto de la

multiprogramación, porque debido al alto costo de las computadoras era necesario

idear un esquema de trabajo que mantuviese a la unidad central de procesamiento

más tiempo ocupada, así como el encolado o ’spooling’ de trabajos para su lectura

hacia los lugares libres de memoria o la escritura de resultados. Sin embargo,

se puede afirmar que los sistemas durante la tercera generación siguieron siendo

básicamente sistemas de lote.

En la cuarta generación la electrónica avanza hacia la integración a gran esca-

la, pudiendo crear circuitos con miles de transistores en un centímetro cuadrado

de silicio y ya es posible hablar de las computadoras personales y las estaciones

de trabajo. Surgen los conceptos de interfaces amigables intentando así atraer al

público en general al uso de las computadoras como herramientas cotidianas. Se

hacen populares el MS-DOS y UNIX en estas máquinas. También es común en-

contrar clones de computadoras personales y una multitud de empresas pequeñas

ensamblándolas por todo el mundo.

Para mediados de los 80’s, comienza el auge de las redes de computadoras

y la necesidad de sistemas operativos en red y sistemas operativos distribuidos.

La red mundial Internet se va haciendo accesible a toda clase de instituciones y

se comienzan a dar muchas soluciones ( y problemas ) al querer hacer convivir

recursos residentes en computadoras con sistemas operativos diferentes. Para los

90’s el paradigma de la programación orientada a objetos cobra auge, así como el

manejo de objetos desde los sistemas operativos. Las aplicaciones intentan crearse

para ser ejecutadas en una plataforma específica y poder ver sus resultados en

la pantalla o monitor de otra diferente (por ejemplo, ejecutar una simulación en

una máquina con UNIX y ver los resultados en otra con DOS ). Los niveles de

interacción se van haciendo cada vez más profundos.

LINUX hace su aparicion a principios de la decada de los noventa, era el

año 1991 y por aquel entonces un estudiante de informatica de la Universidad

de Helsinki, llamado Linus Torvalds empezo, -como una aficion y sin poderse

imaginar a lo que llegaría este proyecto, a programar las primeras líneas de código

43


de este sistema operativo llamado LINUX.

Aquí está el primer mensaje que Linus Torvalds mandó al grupo de noticias

comp.os.minix:

From:[email protected] (Linus Benedict Torvalds)

Newsgroup: comp.os.minix

Subject: GCC-1.40 and a posix question

Message-ID: 1991Jul13, [email protected]

Date: 3 Jul 91 10:00:50 GMT

Hello netlanders,

Due a project I’m working on (in minix), I’m interested

in the posix standard definition. Could somebody please

point me to a (preferably) machine-readable format of the

latest posix rules? Ftp-sites would be nice.

Linux Torvalds [email protected]

Y aquí el que le siguió, este mensaje es considerado por muchos como el comienzo

de Linux:

From:[email protected] (Linus Benedict Torvalds)

Newsgroup: comp.os.minix

Subject: What would you like to see most in minix?

Summary: small poll for my new operating system

Message-ID: 1991Aug25, [email protected]

Date: 25 Aug 91 20:57:08 GMT

Organization: University of Helsinki.

Hello everybody out there using minix-

I’m doing a (free) operating system (just a hobby, won’t

be big and professional like gnu) for 386(486) AT clones.

This has been brewing since april, and is starting to get ready.

I’d like any feedback on things people like/dislike in minix;

as my OS resembles it somewhat (same physical layout of the

44


file-sytem due to practical reasons) among other things.

I’ve currently ported bash (1.08) an gcc (1.40), and things seem to work.

This implies that i’ll get something practical within a few months,

and I’d like to know what features most people want. Any suggestions are welcome,

but I won’t promise I’ll implement them :-)

Linux Torvalds [email protected]

Este comienzo estuvo inspirado en MINIX, un pequeño sistema Unix desarrollado

por Andy Tanenbaum. Las primeras discusiones sobre Linux fueron en el grupo de

noticias comp.os.minix, en estas discusiones se hablaba sobre todo del desarrollo

de un pequeño sistema Unix para usuarios de Minix que querían más.

Linus nunca anunció la version 0.01 de Linux (agosto 1991), esta versión no

era ni siquiera ejecutable, solamente incluía los principios del núcleo del sistema,

estaba escrita en lenguaje ensamblador y asumía que uno tenía acceso a un sistema

Minix para su compilación.

El 5 de octubre de 1991, Linus anunció la primera versión "Oficial" de Linux,

-version 0.02. Con esta versión Linus pudo ejecutar Bash (GNU Bourne Again

Shell) y gcc (El compilador GNU de C) pero no funcionaba mucho más. En este

estado de desarrollo ni se pensaba en los términos soporte, documentación, distri-

bución, etc.

Después de la versión 0.03, Linus saltó en la numeración hasta la 0.10, más y

más programadores a lo largo y ancho de Internet empezaron a trabajar en el pro-

yecto y después de sucesivas revisiones, Linus incrementó el número de versión

hasta la 0.95 (Marzo 1992). Más de un año después (diciembre 1993) el núcleo

del sistema estaba en la versión 0.99 y la versión 1.0 no llegó hasta el 14 de marzo

de 1994.

La serie actual del núcleo es la 2.4.x y sigue avanzando día a día con la meta

de perfeccionar y mejorar el sistema. En el momento de escribir este documento

la versión actual del kernel es la 2.4.19.

5.1.2. Linux

En la página web del kernel de Linux (www.kernel.org) se encuentra esta des-

cripción, que creo que explica en pocas palabras qué es Linux.

45


< <Linux is a clone of the operating system Unix, written from scratch by

Linus Torvalds with assistance from a loosely-knit team of hackers across the

Net. It aims towards POSIX and Single UNIX Specification compliance.

It has all the features you would expect in a modern fully-fledged Unix, inclu-

ding true multitasking, virtual memory, shared libraries, demand loading, shared

copy-on-write executables, proper memory management, and TCP/IP networking.

Linux was first developed for 32-bit x86-based PCs (386 or higher). The-

se days it also runs on (at least) the Compaq Alpha AXP, Sun SPARC and Ul-

traSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, IBM

S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64 and CRIS ar-

chitectures.

Linux is easily portable to most general-purpose 32- or 64-bit architectures as

long as they have a paged memory management unit (PMMU) and a port of the

GNU C compiler (gcc). > >[LT1]

5.1.3. Características

Esta es una lista de las principales características que tiene Linux:

1. Todo el código fuente está disponible, incluyendo el núcleo completo y to-

dos los drivers, las herramientas de desarrollo y todos los programas de

usuario; además todo ello se puede distribuir libremente. Hay algunos pro-

gramas comerciales que están siendo ofrecidos para Linux actualmente sin

código fuente, pero todo lo que ha sido gratuito sigue siendo gratuito.

2. Multitarea: La palabra multitarea describe la habilidad de ejecutar varios

programas al mismo tiempo. Linux utiliza la llamada multitarea preeventi-

va, la cual asegura que todos los programas que se están utilizando en un

momento dado serán ejecutados, siendo el sistema operativo el encargado

de ceder tiempo de microprocesador a cada programa mediante el scheduler.

3. Multiusuario: Permite tener muchos usuarios usando la misma máquina al

mismo tiempo, pero a cada uno de ellos le da la sensación de tener la má-

quina para ellos únicamente.

46


4. Multiplataforma: Las plataformas en las que en un principio se diseñó uti-

lizar Linux son 386-, 486-. pero luego vinieron toda la familia Pentium y

seguidores que pertenecen a la familia i386 que son PC’s de 32 bits, Amiga

y Atari, también existen versiones para otras plataformas, como Alpha de

Compaq, ARM, MIPS, PowerPC tanto de 32 como de 64 bits, Sun SPARC,

UltraSPARC, el último procesador de Intel el IA-64, y muchos otros más.

5. Multiprocesador: Soporte para sistemas con más de un procesador está dis-

ponible para Intel y SPARC.

6. Funciona en modo protegido.

7. Tiene protección de la memoria entre procesos, de manera que uno de ellos

no pueda colgar el sistema.

8. Carga de ejecutables por demanda: Linux sólo lee del disco aquellas partes

de un programa que están siendo usadas actualmente.

9. Política de copia en escritura para la compartición de páginas entre eje-

cutables: esto significa que varios procesos pueden usar la misma zona de

memoria para ejecutarse. Cuando alguno intenta escribir en esa memoria,

la página (4Kb de memoria) se copia a otro lugar. Esta política de copia

en escritura tiene dos beneficios: aumenta la velocidad y reduce el uso de

memoria.

10. Memoria virtual usando paginación (sin intercambio de procesos comple-

tos) a disco: A una partición o un archivo en el sistema de archivos, o ambos,

con la posibilidad de añadir más áreas de intercambio sobre la marcha. Un

total de 16 zonas de intercambio de 128Mb de tamaño máximo pueden ser

usadas en un momento dado con un límite teórico de 2Gb para intercambio.

Este límite se puede aumentar con el cambio de unas cuantas líneas en el

código fuente, que lo está haciendo Oracle, para su distribución.

11. La memoria se gestiona como un recurso unificado para los programas de

usuario y para el caché de disco, de tal forma que toda la memoria libre

puede ser usada para caché y ésta puede a su vez ser reducida cuando se

ejecuten grandes programas.

47


12. Librerías compartidas de carga dinámica (como los ficheros so de Solaris o

los ficheros DLL’s de windows) y librerías estáticas.

13. Se realizan volcados de estado (core dumps) para posibilitar los análisis

post-mortem, permitiendo el uso de depuradores sobre los programas no

sólo en ejecución sino también tras abortar éstos por cualquier motivo.

14. Compatible con POSIX, System V y BSD a nivel fuente. Control de tareas

POSIX.

15. Emulación de iBCS2, casi completamente compatible con SCO, SVR3 y

SVR4 a nivel binario.

16. Emulación de 386 en el núcleo, de tal forma que los programas no tengan

que hacer su propia emulación matemática. Cualquier máquina que ejecu-

te Linux parecerá dotada de coprocesador matemático. Por supuesto, si el

ordenador ya tiene una FPU (unidad de coma flotante), esta será usada en

lugar de la emulación, pudiendo incluso compilar tu propio kernel sin la

emulación matemática y conseguir un pequeño ahorro de memoria.

17. Soporte para muchos teclados nacionales o adaptados y es bastante fácil

añadir nuevos dinámicamente.

18. Consolas virtuales múltiples: varias sesiones de login a través de la consola

entre las que se puede cambiar con las combinaciones adecuadas de teclas

(totalmente independiente del hardware de video). Se crean dinámicamente

y puedes tener hasta 64. Dispone también de Pseudo-terminales (pty’s).

19. Soporte para varios sistemas de archivo comunes, incluyendo minix-1, Xe-

nix y todos los sistemas de archivo típicos de System V, y tiene un avanzado

sistema de archivos propio con una capacidad de hasta 4 Tb y nombres de

archivos de hasta 255 caracteres de longitud. Está el sistema de archivos

ext-3, ext-2 y el ReiserFS como los sitemas de archivo más comunes. Acce-

so transparente a particiones MS-DOS (o a particiones OS/2 FAT) mediante

un sistema de archivos especial: no es necesario ningún comando especial

para usar la partición MS-DOS, esta parece un sistema de archivos normal

48


de Unix (excepto por algunas restricciones en los nombres de archivo y per-

misos). Las particiones comprimidas de MS-DOS 6 no son accesibles en

este momento, y no se espera que lo sean en el futuro. JFS o Journalist File

System para Linux, hecho por IBM. El soporte para VFAT, FAT32 (WinNT,

Windows 95/98/ME) se encuentra soportado desde la version 2.0 del nucleo

y el NTFS de WinNT / Win2000 / WinXP desde la version 2.2. Este últi-

mo solo en modo lectura, se puede hacer escrituras pero no es recomendado.

También dispone de un sistema de archivos especial llamado UMSDOS que

permite que Linux sea instalado en un sistema de archivos DOS. Soporte en

sólo lectura de HPFS-2 del OS/2 2. Sistema de archivos de CD-ROM que

lee todos los formatos estándar de CD-ROM.

20. Incluidas en el núcleo tenemos una gran cantidad de protocolos de red como

por ejemplo: TCP/IP tanto IPversion 4 como IPversion6. Appletalk compa-

tible con redes Apple. Software cliente y servidor Netware. IPX, AX.25,

X.25, DDP, Netrom, etc.

21. Dispone de servidores para protocolos HTTP (Apache Web Server, khttpd,

etc), FTP (transferencia de ficheros: wu-ftpd, proftpd, etc), SMTP (trans-

ferencia de correo: Postfix, Sendmail, Qmail, etc), NFS, SMB entre otros

muchos. Lan Manager / Windows Native (SMB) es un software cliente y

servidor, para poder compartir ficheros e impresoras en redes Microsoft1

con funciones de servidor como funciones de cliente.

22. Sistemas de multicomputación. Soporte para MPI y PVM, directamente o

con sistemas como Beowulf. LVS (Linux Virtual Server), etc

23. Y otras tantas virtudes de este Sistema Operativo que mantiene la comuni-

dad de Internet y empresas como Oracle, Sun Microsystems, IBM, Compaq-

HP, Dell etc a parte de las propias empresas de cada distribución como Red

Hat, Debian, Suse, etc que entre todas y todos dan soporte a este sistema

operativo.

Aunque la mejor virtud son los miles de programas a través de Internet distribui-

dos gratuitamente o con licencias de libre distribución. Visitando páginas web se1Microsoft es marca registrada de Microsoft Corporation

49

5 EL SISTEMA OPERATIVO LINUX 5.2 El Kernel

pueden encontrar miles de aplicaciones que ya están hechas y al disponer del có-

digo fuente pueden mejorarlas. También existe una gran comunidad que resuelve

cualquier problema que pueda surgir al kernel. Las respuestas a los problemas de

seguridad han demostrado ser más rápidas que muchas empresas.

5.2. El Kernel


El Kernel puede verse como el corazon del sistema operativo, cargado en la

memoria RAM cuando se enciende el ordenador y permanece en funcionamiento

hasta que este se apaga. Tiene principalmente dos responsabilidades:

1. Servir a los requerimientos de programación a bajo nivel (por ejemplo tra-

tando las interrupciones hardware).

2. Proveer un entorno a los procesos, que son las instancias en ejecución de

los programas o threads.

Se dice que el kernel de Linux es monolítico, que es como un gran ejecutable, que

consiste de muchos componentes divididos lógicamente.

5.2.2. Modos

El Kernel puede trabajar en dos modos: usuario o kernel. La mayoría de las

ejecuciones de programas de los usuarios se hacen en modo usuario o ’user mode’

como se dice en inglés. Este modo de ejecución no tiene acceso directo a las

estructuras de datos del kernel o a los equipos hardware. Puede cambiarse a modo

kernel de varias formas:

1. Un programa hace una llamada al sistema o ’system call’, por ejemplo cuan-

do una función de una libreria hace una petición al kernel.

2. Una señal de excepción provinente de la CPU, que son condiciones que

requieren especial atención, por ejemplo en una división por cero.

50


3. Una interrupción que se hace hacia la CPU provinente de algún equipo hard-

ware indicando que requiere su atención, como por ejemplo cada vez que

apretamos cualquier tecla desde el teclado.

El kernel se pasa la mayoría del tiempo en el modo kernel ejecutándose detrás

de los procesos de usuario. Además hay muchos threads que se están ejecutando

detrás del propio kernel en modo kernel, que se encargan de hacer las actividades

necesarias para mantener en funcionamiento al sistema operativo. Una vez que

todas las operaciones pendientes en modo kernel se han completado y tratado, el

kernel vuelve al modo usuario otra vez.

5.2.3. Módulos

El kernel es capaz de cargar dinámicamente porciones adicionales de código

(módulos) mientras se está ejecutando, para mejorar su funcionalidad. Por ejem-

plo, hay módulos que pueden añadir soporte para sistemas de ficheros que no es

necesario que estén cargados siempre. Cuando la funcionalidad proveida por el

módulo ya no se necesita más, el módulo puede ser descargado, liberando memo-

ria.

5.2.4. Procesos

Un proceso es una instancia de un programa en ejecución. Cada proceso tiene:

1. Un estado, ya sea ’running’ (ejecutándose en el procesador), ’sleeping’ (dur-

miendo, un proceso que está esperado que un evento se termine), ’runnable’

o ’ready’ (listo para ser ejecutado y esperado en la cola de procesos), ’stop-

ped’ (parado ya sea por una señal de control o porque están haciendole un

trace) o zombie (zombie el proceso esta apunto de ser eliminado).

2. Un contexto, una copia con todos los registros de la CPU que indican el

estado del proceso (PC, SP, PSW, registros de propósito general, registros

de coma flotante y regsitros para el control de memoria)

3. Un descriptor de procesos, es una estructura de datos del tipo task_struct

que guarda toda la información relacionada con un proceso.

51


El kernel se encarga de poner un entorno multiprogramable, lo que indica que se

puede tener muchos procesos activos a la misma vez. Cada proceso dispone de los

recursos hardware disponibles para él, y es el kernel el encargado de controlar que

los recursos se comparten correctamente. Multiprogramming implica que todos

los procesos que están en la cola de procesos esperando tendrán su oporturnidad

para ejecutarse en la CPU en turnos. El proceso que ’controla’ la CPU en un

instante de tiempo se le llama ’current’ porque es el programa que esta corriendo

en ese momento. El proceso que se encarga de decidir quien es el que pasa a estado

ready o un estado de ejecutandose es el scheduler o ’context switch’, porque se

encarga de cambiar el contexto actual. El cometido de este es guardar el contexto

actual del proceso ejecutándose (una foto del estado de la CPU en ese momento)

y cargar el contexto de algún proceso que este esperando para ser ejecutado, o

un proceso con el estado de ready. Los cambios de contexto solo pueden hacerse

cuando el kernel está en modo usuario, así que en el modo kernel no pueden

hacerse cambios de contexto inmediatamente por eso se le llama non-preemptive.

Cada proceso de usuario se ejecuta en su propio espacio de usuario, una por-

ción asignada del total de memoria disponible. Espacios de usuario (o partes de él)

pueden compartirse entre procesos si se pide, o bien automáticamente si el kernel

lo cree apropiado. La separación del espacio de direcciones hace que un proceso

no pueda interferir con una operación de otro proceso o del sistema operativo.

Además de los procesos normales de usuario ejecutándose en el sistema, hay

varios threads del kernel que se crean al iniciar el sistema y que corren permanen-

temente en modo kernel, encargandose de funciones de mantenimiento del kernel.

5.2.5. Sincronización

El kernel es reentrante, varios procesos pueden estar ejecutándose en modo

kernel a la vez. Por supuesto, en un sistema con solo un procesador solo un proceso

puede ejecutarse, porque el resto de procesos están bloqueados esperando en una

cola. Ejemplo: un proceso pide leer un fichero, el sistema virtual de ficheros el

’Virtual File System’ traduce la petición en una operación de bajo nivel del disco

y lo pasa al controlador del disco, por detrás del proceso. En vez de esperar hasta

que la operación de escritura a disco se haya completado, miles de ciclos de CPU

52


más tarde, el proceso da voluntariamente a la CPU después de hacer la petición

y el kernel permite que otro proceso esperando pueda ejecutarse en la CPU y

este a su vez puede entrar en el modo kernel. Cuando una operación a disco se a

completado (señalado por una interrupción de hardware), el proceso actual da la

CPU al que trata las interrupciones (el interrupt handler) y el proceso original se

despierta, siguiendo su estado a donde lo había dejado.

Para poder implementar un kernel reentrante, hay que tener especial cuidado

para asegurar la consistencia de las estructuras de datos del kernel. Si un proceso

modifica un contador de otro proceso esperando sin que este lo sepa, el resultado

puede ser potencialmente desastroso. Hay que seguir los siguientes pasos para

preever este tipo de sucesos:

1. Un proceso solo puede reemplazar a otro en modo kernel si ha dejado vo-

luntariamente la CPU, dejando las estructuras de datos en un estado consis-

tente, de ahí que se le llame al kernel ’non-preemptive’.

2. Hay que deshabilitar las interrupciones en regiones críticas, donde el código

tiene que completarse sin ninguna interrupción, y asegurarse luego de volver

a habilitarlas.

3. El uso de spin locks y semáforos de control para acceder a estructuras de

datos.

Los semáforos consisten en un contador inicializado a uno, una lista de procesos

esperando para acceder a la estructura de datos y dos métodos atómicos llama-

dos up() y down() que incrementan y decrementean el contador respectivamente.

Cuando se accede a una estructura protegida por un semáforo, se llama a la fun-

ción down(), si el valor del contador es cero o positivo (no negativo vaya), en-

tonces el acceso está garantizado, si no es así y el acceso esta negado significa

que está bloqueado y que el proceso se añade a la lista del semáforo de procesos

esperando. De forma parecida, cuando un proceso ha terminado de tratar los datos

de la estructura, llama a la función up() y el siguiente proceso de la lista consigue

acceder.

Hay que tomar precauciones, porque hay que asegurarse que no hay deadlocks

entre varios procesos, en el caso de que controlen varios recursos. Si cada uno está

53


esperado un recurso controlado por otro proceso y este a su vez esta esperando un

recurso controlado por el primer proceso se dice que existe un deadlock o ’abrazo

de la muerte’ porque se esperan infinitamente hasta que uno de los dos deje el

otro recurso, pero al estar los dos en un estado de espera jamás lo harán. Si se

quiere profundizar en deadlocks buscar por Internet el problema de los filósofos

que cenan o dicho en inglés ’The dining Philosophers Problem’ o en cualquier

libro de sistemas operativos.

5.2.6. Comunicación entre procesos

Una señal es un mensaje corto, enviado entre dos procesos o entre el kernel

y un proceso. Hay dos dipos de señales que se usan para notificar eventos a del

sistema a los procesos:

Eventos asíncronos. Por ejemplo SIGTERM, enviado cuando se usa el Ctrl-C del

teclado.

Errores o excepciones síncronas. Por ejemplo SIGSEGV cuando un proceso in-

tenta acceder a una dirección ilegal.

Hay cerca de 20 señales diferentes definidas en el estandart POSIX, algunas de

ellas pueden ser ignoradas. Algunas señales no pueden ser ignoradas y no son

tratadas siquiera por el proceso mismo. Linux usa el sistema V o ’System V’

de comunicación entre procesos llamado en inglés Inter-Process-Comunication

(IPC).

5.2.7. Control de la Memoria

Linux usa memoria virtual, un nivel de abstracción entre los pedidos de me-

moria por parte de los procesos y las direcciones físicas de la memoria. Así hace

posible lo siguiente:

1. Permite que muchos procesos corran incluso cuando la suma de toda la

memoria exceda la RAM física disponible.

2. Hace posible también un espacio de direcciones contigua, independiente a

la organizacioón de la memoria física.

54


3. Paginado, porciones de datos o código que solo necesitan cargarse en me-

moria cuando se ejecutan o son accedidos y pueden intercambiarse a disco

cuando no son necesarios.

4. Imágenes compartidas de programas y librerias, haciendo un uso más efi-

ciente de la memoria.

5. Recolocación de los programas en memoria de forma completamente trans-

parente.

El espacio de direcciones se divide en porciones de 4kBytes llamadas páginas, las

cuales forman la unidad básica de todas las transacciones de la memoria virtual.

Como la suma total de direcciones de memoria excede a lo que hay en la memoria

RAM, solo un grupo de todas las páginas disponibles se guardan en la RAM a la

vez. Aún así, un página tiene que estar presente en la RAM para poder acceder a

ella ya sea para leer o guardar datos como para ejecutar programas.

Como cualquier página puede volver a ponerse en cualquier página física, el

kernel tiene que llevar el control de donde estan las páginas usadas. Y además

hacer la conversión de direcciones lógicas en direcciones físicas.

En el hardware Intel x86, Linux usa dos nivels de paginación (aunque inter-

namete usa tres niveles para mejorar la portabilidad) para reducir la cantidad de

memoria usado pora las tablas de paginación. Para convertir una dirección lógica

en una física, las tablas se consultan en este orden: Page Global Directory luego

la Page Table para conseguir el número de página y el offset de la página. Por eso

una dirección lógica se divide en tres partes: Directorio, Tabla y Offset. Como se

puede direccionar un espacio de 4GBytes (usando 32 bits) y se usa una página del

tamaño de 4kB, los 10 bits más significativos de la dirección apuntan al directorio,

los 10 siguientes bits apuntan a la tabla (de ahí que se requiera identificar la pági-

na) y los 12 siguientes bits, los menos significativos, nos marcan el offset dentro

de la página.

5.2.8. El código

El código fuente del kernel está hecho de alrededor de dos millones de líneas

de código. Puede parecer muy intimidatorio, pero es importante recordar que muy

55


poca gente entiende todos los subsitemas y el código asociados a ellos en profun-

didad. Se puede mejorar la productividad simplemente sabiendo donde buscar el

código específico. Paso a comentar qué se puede encontrar en el código fuente y

donde va cada cosa.

Para empezar es necesario bajarse la última versión del kernel de http://www.kernel.org

la versión actual es la 2.14.19. Pero es recomendable visitar la página web, ya que

seguro que hay nuevas actualizaciones.

(bash)$ wget http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.19.tar.gz

Tras ello se descomprime y se accede al directorio:

(bash)$tar xvzf linux-2.4.19.tar.gz

(bash)$cd linux-2.4.19

(bash)$dir

direcciones total 248

drwxr-xr-x 18 carlosm grp 4096 Aug 3 02:39 arch/

-rw-r--r-- 1 carlosm grp 18691 Aug 3 02:39 COPYING

-rw-r--r-- 1 carlosm grp 79410 Aug 3 02:39 CREDITS

drwxr-xr-x 28 carlosm grp 4096 Feb 25 19:41 Documentation/

drwxr-xr-x 39 carlosm grp 4096 Feb 25 2002 drivers/

drwxr-xr-x 45 carlosm grp 4096 Feb 25 2002 fs/

drwxr-xr-x 25 carlosm grp 4096 Aug 3 02:39 include/

drwxr-xr-x 2 carlosm grp 4096 Feb 25 2002 init/

drwxr-xr-x 2 carlosm grp 4096 Dec 21 2001 ipc/

drwxr-xr-x 2 carlosm grp 4096 Feb 25 2002 kernel/

drwxr-xr-x 2 carlosm grp 4096 Nov 22 2001 lib/

-rw-r--r-- 1 carlosm grp 41643 Aug 3 02:39 MAINTAINERS

-rw-r--r-- 1 carlosm grp 18710 Aug 3 02:39 Makefile

drwxr-xr-x 2 carlosm grp 4096 Feb 25 2002 mm/

drwxr-xr-x 28 carlosm grp 4096 Feb 25 2002 net/

-rw-r--r-- 1 carlosm grp 14239 Aug 3 02:39 README

-rw-r--r-- 1 carlosm grp 2815 Apr 6 2001 REPORTING-BUGS

56


-rw-r--r-- 1 carlosm grp 9291 Aug 3 02:39 Rules.make

drwxr-xr-x 4 carlosm grp 4096 Aug 3 02:39 scripts/

Todo este enjambre de ficheros está organizado lógicamente en una estructura de

directorios.

Documentation: Información sobre plataformas y devices específicos igual que

información general sobre el kernel.

arch: Código específico para cada arquitectura: i386, sparc, alpha, arm, cris, ia64,

mips, mips64, parsic, ppc (PowerPC 32bits), ppc64(PowerPC 64bits), s390,

s390x, sparc, sparc64.

drivers: Código para cada device específico: tarjeta de sonido, tarjeta ethernet,

etc

fs: Código para los sistemas de ficheros o ’Filesystems’: ext2, ext3, vfat, etc

include: Todos los ficheros de cabecera separado en subdirectorios de acuerdo

con el tipo fichero y su función.

init: Todo el código asociado con el proceso de arranque e inicialización.

IPC: Código de la comunicación entre procesos o Inter Process Communication:

implementación de la memoria compartida, etc

kernel: El código del núcleo del kernel, la parte más importante de Linux son so-

lo 396KBytes y 31 ficheros: scheduling, señales, printk, fork, softirq, con-

textos, tiempo, cargador de módulos, etc

lib: Librerías relacionadas con el kernel, por ejemplo descompresión de la ima-

gen del kernel, funciones de lock, etc

mm: Memory Managment todos los ficheros con el código de trato de memoria.

net: Todo el código relacionado con la red. Aquí es donde le meteré mano para

crear el firewall.

scripts: Scripts relacionados con el kernel, como por ejemplo el patch-kernel.

57


El mejor lugar para empezar leyendo el código depende de las motivaciones que

tenga cada uno, yo por mi parte fui directamente al directorio net, al directorio

kernel y al directorio include, el resto de directorios casi no los he visitado, pero

claro mi intención es construir un firewall, cada uno tendrá sus motivos.

Si por ejemplo, se desea escribir un driver para un hardware que todavía no

está soportado, en ese caso se empieza leyendo el código para los drivers más

parecidos que ya están implementados. Dicen los hackers del kernel que la mejor

forma de introducirse a la programación del kernel es escribiendo drivers, ahí

queda eso para los interesados.

En cambio si lo que se desea es escribir un nuevo sistema de ficheros la idea es

buscar dentro del directorio fs algo que se parezca a lo que queremos implementar.

Si en cambio se desea jugar con la programación dentro del kernel haced lo

que yo hice que fue probando en la inicialización del sistema, en init/main.c, es-

pecíficamente en la función start_kernel() o bien ojeando los ficheros que hay en

el directorio kernel.

5.2.9. Numeración

Si se desea hacer cambios e introducir código en el kernel para contribuir

en el desarrollo, es importante entender el ciclo de desarrollo adoptado por la

comunidad del kernel de Linux. Paso a comentar el proceso de desarrollo:

Series estables

Las series estables tienen el número de versión con teóricamente casi ningún

bug para ser arreglado o ninguna mejora para hacer. La mayoría de distribuciones

usan estas series, y si no se quiere uno aventurar encontrando bugs y fallos es re-

comendable usar estas releases para trabajar. Las peores series que hay se marcan

con una extensión de ’-dontuse’ (don’t use: no usar) en el nombre del fichero. Es-

tas son por ejemplo las 2.0, 2.2.x y las 2.4.x que son números pares y a medida

que van saliendo nuevas versiones se va aumentando el número de la serie, ahora

las últimas versiones estables para 2.0 es la 2.0.39 para la serie de kernels 2.2 se

terminó con la 2.2.22 y ahora mismo (a la hora de escribir este documento) la úl-

tima versión estable del kernel de Linux es la 2.4.19, la anterior fue la 2.4.18 y la

58


siguiente a la actual se supone será la 2.4.20, que hasta que salga esta van apare-

ciendo unos prepatchs que muestra las actualizaciones, que se llaman los parches

intermedios, que normalmente se le añade ’-pre’ más el número de versión del

prepatch.

Series inestables

Los kernels inestables contienen menos código probado y los cambios entre

las series son más grandes. Sirven para provar los nuevos drivers, las mejoras

experimentales y los algoritmos más inovadores. La última versión beta del kernel

de Linux es la 2.5.38.

Generalmente, es muy mala idea ejecutar un kernel inestable en un sistema

que está en producción. Lo recomendado es tener un ordenador dedicado para

hacer el testing con kernels inestables.

Parches intermedios

Entre dos releases de kernels estable e inestable, hay varias releases interme-

dias que intentan testear un pequeño número de cambios a la vez. Estas releases

tienen o bien la extensión -preXX o bien la extensión -YYXX, donde XX es el

número de la versión incrementada y el YY son las iniciales de quien lo mantiene,

por ejemplo -ac12 indica incrementalmente la extensión de Alan Cox. Al parche

intermedio actual está numerado como 2.4.20-pre7.

5.2.10. Compilación del núcleo

Si se va a modificar el núcleo es necesario luego compilarlo e instalarlo en

la máquina. Al hacer el firewall, cada vez que modificaba cualquier cosa también

tenía que compilar e instalarlo, así que es una parte importante del proceso.

No es necesario compilar el núcleo en la misma máquina en la que va a correr

el kernel, yo lo que hago personalmente es que de todas las máquinas que tengo

la más rápida es la encargada de hacer la compilación, y luego se pasa la imagen

al ordenador.

Es recomendable descomprimir el kernel en el directorio /usr/src y tener cada

versión en su directorio de forma ordenada. por regla general se pone la versión

59


actual, la que va a correr en el sistema, en el directorio /usr/src/linux. Pero es solo

una recomendación, no es necesario que sea así.

En el caso de ser una versión nueva, sin haberse compilado ninguna vez, no

es necesario hacer un ’make clean’, para más adelante antes de hacer nada es

recomendable hacerselo, así se elimina código compilado que puede molestar.

Vayamos a la compilación: Primero descompilar el kernel.

tar xvzf lnux-x.y.z.tar.gz

El x.y.z corresponde a la versión actual del kernel, que corresponde al fichero

bajado. En caso de tener la extensión .bz2 es necesario descomprimirlo primero y

luego hacerle un tar mediante la orden siguiente:

bz2cat linux-x.y.z.tar.bz2 | tar xvf -

Después de bajarse la última versión del kernel y descomprimirlo es necesario

entrar dentro del mismo directorio y empezar a configurar. Entrar en el directorio

que se acaba de descompilar, y ahora es hora de configuar el kernel con todas

los módulos, drivers y opciones que queramos o necesitamos incluirle al kernel.

Dependiendo de lo que estemos usando se configurará de una manera o de otra.

Existe principalmente tres maneras de configurar el kernel:

1. make config

2. make menuconfig

3. make xconfig

Cada una de ellas dependiendo de si disponemos X windows o si solo podemos

usar un menu basado en texto con la consola. Yo uso preferiblemente las XWindos

en mi entorno de trabajo (no en los servidores), así que uso la tercera opción.

make xconfig

Aparecerá entonces un menú con todas las preguntas que debemos responder,

agrupadas por temas. A cada una de las preguntas se debe responder con un ’y’

60


o bien con un ’n’, la primera es para aceptar esa parte de código y la segunda

para no incluirlo. Puede haber en el caso de los drivers por ejemplo, una tercera

opción ’m’ que significa ’module’ y es para compilar el módulo pero no se incluye

directamente en el kernel, sino que como un módulo cargable. Es como decir

quizás lo uso. Igualmente cada una de las opciones tiene un ’si no entiede lo que

quiere decir ponga un ...’ si o no, en cada caso particular. Para hacer este paso

es necesario saber unas cuantas cosas del sistema, como por ejemplo que tipo de

tarjeta de red disponemos, que tipo de tarjeta de video, y esas cosas, porque sino

dificilmente os funcionará por ejemplo la tarjeta de red. Para una información

más detallada de cada grupo de opciones leer el Kernel-HOWTO, donde aparece

mucho más detallado.

Cuando se termina de configurar, se preparará las dependencias en poco tiem-

po, a menos que su PC sea muy lento. También será necesario hacer un make

clean, para borrar todos lo ficheros objeto y otras cosas que las versiones anterio-

res han dejado, se recomienda hacerlo cada vez que se recompile el kernel.

make dep

make clean

Después de preparar dependencias, puede ejecutar ‘make zImage’ o ‘make zdisk’

(esta es la parte que tarda más tiempo). ‘make zImage’ compilará el núcleo y lo

dejará comprimido en arch/i386/boot/zImage junto a otros ficheros. Con ‘make

zdisk’ el nuevo núcleo se copiará además en el disquete que esté puesto en la dis-

quetera “A:”. ‘zdisk’ es interesante para probar núcleos; si explota (o simplemente

no hace nada) se quita el disquete de la disquetera y podrá arrancar el núcleo an-

tiguo. Además sirve para arrancar si borró accidentalmente el núcleo del disco

duro. También puede usarlo para instalar nuevos sistemas simplemente volcando

el contenido de un disco en otro. Los núcleos recientes están comprimidos, con

una ‘z’ comenzando su nombre. Un núcleo comprimido se descomprime automá-

ticamente al cargarse el sistema.

make zImage

Existen más makes, por ejemplo con ‘make mrproper’ hará una limpieza mucho

más ’intensa’. Esta suele hacer falta cuando se actualiza (parchea) el núcleo. Pero

61


esta opción borra también su fichero de configuración del núcleo, así que guarde

una copia del correspondiente fichero .config si cree que le interesa.

La opción ‘make oldconfig’ intentará configurar el núcleo con un fichero de

configuración anterior. Aunque a partir del 2.0.xx no es necesario, make recuerda

la última configuración. Para evitar todo el proceso del ‘make config’. Si no se

ha compilado anteriormente el núcleo o no se tiene un fichero de configuración

anterior, no se debe elegir pues se instalará la configuración por defecto.

Una vez que tenga un nuevo núcleo que parezca funcionar como desea, será

el momento de instalarlo. Casi todo el mundo utiliza LILO (LInux LOader) para

esto. Con ’make zlilo’ se instalará el núcleo ejecutando LILO, quedando listo

para rearrancar, pero esto solo funcionará si LILO está bien configurado para su

sistema: el núcleo es /vmlinuz, LILO está en /sbin y la configuración de LILO

(/etc/lilo.conf) es coherente con lo anterior. Pero no es difícil hacerlo paso a paso,

además se puede compilar un kernel en un ordenador más potente y luego pasarlo

a otro sistema, en tal caso no funciona.

El fichero de configuración será como éste:

image = /vmlinuz

label = Linux

root = /dev/hda1

...

La línea ’image =’ apunta al núcleo instalado actualmente. Casi siempre es /vm-

linuz. ‘label’ es el identificador usado para seleccionar qué sistema arrancar, y

’root’ es el disco o partición a usar para el directorio raíz.

Ahora se copia el fichero zImage, que se ha creado antes, que normalmente

está en arch/i386/boot y se llama bzImage. Copiar el fichero este y nombrarlo de

alguna manera para reconocerlo y no confundirlo con otras versiones del kernel.

Por ejemplo vmlinuz-x.y.z, donde x.y.z es la versión actual del kernel compilado.

Copiarlo al directorio /boot, para tenerlo todo bien ordenado.

cp arch/386/boot/bzImage /boot/vmlinuz-versionactual

Y entrar en el fichero /etc/lilo/config o bien /etc/lilo.conf según la distribución,

para la configuración del LILO.

62


vim /etc/lilo.conf

Allí añadir las líneas necesarias para la nueva versión del kernel que acabamos de

compilar. Nombrar con el label al nuevo sistema.

image = /vmlinuz

label = Linux

root = /dev/hda1

...

image=/boot/bzImage-versionactual

label=miNuevoLinux

root=/dev/hda1 # Atencion!!

read-only

En donde pone /dev/hda1 hay que asegurarse de poner el nombre bien, en es-

te ejemplo tenemos /dev/hda1 que corresponde a la partición primera del primer

disco duro. Pero no significa que sea así en todos, en mi disco duro por ejemplo

el directorio raiz corresponde a la quinta partición. Por eso en mi sistema ten-

go /dev/hda5. Pero también podría estar en el disco duro scsi, por lo que sería

/dev/sda5. Bueno tener cuidado porque sino pegará una petada increhible.

Tras haber incluido estas líneas en el fichero de configuración del LILO, es

necesario ejecutarlo para que tenga efecto la nueva configuración. Esto se hace de

la siguiente manera:

lilo

Para arrancar uno de los antiguos núcleos, se copia las líneas anteriores incluyen-

do ‘image = xxx’ al principio del fichero de configuración de LILO, y se cambia

‘image = xxx’ por ‘image = yyy’ donde ‘yyy’ es el nombre de camino completo

al fichero de la copia de seguridad guardada. También es necesario cambiar ‘label

= zzz’ por ‘label = linux-backup’ y reejecute LILO. Puede ser que necesite po-

ner una línea en el fichero con ‘delay=x’ donde x son las centésimas de segundo

que LILO esperará antes de arrancar con la primera opción, de modo que pue-

da interrumpirse (con la tecla SHIFT) y seleccionarse qué núcleo desea arrancar

(tecleando la etiqueta (label) asignada).

63


La órdenes make modules; make modules_install compilarán los módulos que

hayamos seleccionado, y los instalarán. No olvidar ejecutar depmod -a en cuanto

hayamos arrancado con dicho núcleo. En caso de que estemos compilando por se-

gunda vez una misma versión de núcleo, y hayamos variado el número de módulos

a compilar, es posible que la ejecutar make dep nos encontremos con un mensa-

je de error; esto se debe a que los antiguos módulos que no hayamos compilado

ahora no son borrados. Pueden borrarse tranquilamente.

Y ya está, reiniciar el sistema y escoger la nueva versión en la lista que muestra

el lilo. Y lo lógico es que todo funcione correctamente.

Pero ¿qué pasa si hay problemas? El principal problema es que no se haya

ejecutado el comando lilo. Para esos casos lo mejor que puede hacerse ahora es

arrancar con un disquete, preparar otro disquete para arrancar Linux, con ’make

zdisk’ se hace uno fácilmente, aunque debíamos haberlo hecho antes si es el mis-

mo sistema con el que compilamos el kernel y el que nos da el problema (mucho

cuidado en esos casos, en serio). Necesita saberse qué sistema de ficheros raíz (/)

tiene, dónde está y su tipo (por ejemplo, ext2 o minix). También hay que saber

dónde están los ficheros de /usr, en otra partición.

En nuestro ejemplo, / (el directorio raíz) es /dev/hda1, y el sistema con las

fuentes del núcleo es /dev/hda3, montado como /usr normalmente (que es donde

tenemos /usr/src que estaba el kernel compilado). Ambos son sistemas ext2. La

imagen compilada estará en el sistema de las fuentes. La idea es que si hay un

fichero zImage correcto, puede salvarse en un disquete.

En primer lugar, arranque con un disquete de instalación o de rescate, y monte

el sistema de ficheros que contenga el núcleo a usar:

mkdir /mnt

mount -t ext3 /dev/hda3 /mnt

Tener en cuenta que los sistemas de ficheros con los actuales kernels es el ext3 pe-

ro puede ser también un reiserfs o bien un ext2, según el caso. Si mkdir le dice que

el directorio ya existe, no hay problema. Ahora, pase al directorio donde está el nú-

cleo compilado. De esta forma tenemos que /mnt + /usr/src/linux/arch/i386/boot -

/usr = /mnt/src/linux/arch/i386/boot

64

5 EL SISTEMA OPERATIVO LINUX 5.3 Herramientas

Ponga un disco con formato en la unidad “A:” (que no sea el disquete con el

que ha arrancado) y copie el núcleo a él:

cd /mnt/usr/src/linux/arch/i386/boot

dd if=zImage of=/dev/fd0

rdev /dev/fd0 /dev/hda1

Vaya a / y desmonte el sistema de ficheros:

cd /

umount /mnt/usr

Ahora puede rearrancar el sistema desde el disquete. ¡No olvides ejecutar LILO!

Hay otra alternativa. Si el núcleo está en el directorio raíz (por ejemplo /vm-

linuz), puede usarlo para un disquete de arranque. Suponiendo las condiciones

anteriores, haríamos los cambios siguientes en el ejemplo anterior: /dev/hda3 por

/dev/hda1 (el sistema raíz), /mnt/src/linux por /mnt, y ‘if=zImage’ por ‘if=vmlinuz’.

El resto puede ignorarse. Usar LILO con discos grandes (de más de 1024 cilin-

dros) puede dar problemas. Le recomendamos que lea el mini-HOWTO sobre

LILO para más información.

5.3. Herramientas

Esta sección pretende explicar las herramientas fundamentales para el desa-

rrollo del kernel. Tenemos que son necesarios los editores de texto, programas

para desarrollo, para navegar por el código y para debugar. Las herramientas de

debugar se explican en el siguiente apartado.

5.3.1. Editores de texto

Hay una gran cantidad para escoger editores de texto. Cada uno es partidario

de uno, se han hecho debates para saber qué editor es el mejor para trabajar en la

programación del kernel. Entre los que está la discusión es entre el editor vim y

el emacs. Pues explicaré ambos por encima, aunque yo soy de los partidarios del

vim.

65


vim

Como todo sistema UNIX, Linux también tiene el editor vi disponible, y sino

el vim (vi-improved que viene a decir el vi-mejorado) con algún contenido extra.

Las razones para usar vim en la programación dentro del kernel son:

1. Integra de una forma limpia los ctags. Si se hacen tags en el directorio del

código del kernel, se puede acceder rápidamente a las funciones y a las

definiciones de las variables usando las teclas Ctr-] mientras el cursor está

sobre la función o variable en cuestión.

2. El auto-completado de los nombres de variables y funciones puede ahorrar

el tiempo evitando errores de deletreo. Esto es especialmente interesante

cuando se programa el kernel ya que la mayoría de nombres son bastante

largos. Así que al usar esta herramienta, solo hay que escribir la primera

parte de la variable o de la función y apretar Ctrl+P repetidamente mientras

va buscando todos los posibles matches.

3. Es rápido de cargarse.

4. Ocupa poco y deja más memora para la recompilación del kernel.

5. Altamente configurable. Entre otras cosas, los comandos que se accionan

con las teclas se pueden volver a mapear fácilmente. Es muy útil si se en-

cuentra algún comando que se usa mucho y tiene una combinación de teclas

incómoda.

6. Está integrado con el cscope. Para hacer búsquedas rápidas del código.

7. Muchas veces se puede encontrar este fántastico programa en discos de

arranque de rescate los llamados ’rescue boot disk’.

8. Los accesos directos del teclado hace que se requiera muy poco movimiento

de manos, al menos si no se ha modificado el mapeado.

Probablemente la mejor forma de aprender los fundamentos más básicos del vim

sea leer el vim-HOWTO que se puede encontrar en http://www.tldp.org/HOWTO/Vim-

HOWTO.html

66


emacs

Como el vi, el emacs está en muchos sistemas y tiene también muchos fans.

Las razones para usar emacs en la programación del kernel son varias:

1. Tiene gran cantidad de librerías para mejorar la productividad.

2. Buena integración con los etags.

3. También integra búsquedas con grep y cscope.

4. Integración con gdb, muy útil a la hora de debugar código.

5. Las teclas de uso pueden ser más intuituvas, por ejemplo no es necesario

tener que entrar en ningún modo para empezar a escribir inmediatamente

en un documento. Y es por eso que es el editor preferido por aquellos que

no les gusta hacer las cosas tan formales.

Los inconvenientes que tiene son también varios.

1. Se usa mucho la tecla Ctrl. Se recomienda mapear las teclasl Ctrl a otra,

como por ejemplo Caps-Lock.

2. Es un gran paquete, no es recomendable para sistemas con espacio limitado

en el disco duro.

3. Tarda más en cargarse en sistemas más modestos.

4. Necesita más memoria, así que deja menos memoria a la hora de recompilar

el kernel.

5. Dicen que los etags son inestables y que les dan core dumpeds muy frecuen-

temente.

La mejor manera de trabajar con el emacs es trabajando con el tutorial, el cual

puede accederse accediendo al emacs y apretando las teclas Ctr+h y luego t.

67


5.3.2. Herramientas de desarrollo

make

El programa make es fundamental y básico. Es el que se usa para determinar

qué partes de un proyecto con muchos ficheros código fuente necesitan ser re-

construidos. Solo aquellos ficheros de código que hayan sido modificados serán

reconstruidos antes del final de la fase lincaje. Esta propiedad es una gran mejora

para el programador del kernel, porque una vez el kernel está construido recompi-

larlo para incluir los cambios tarda muchísimo menos que si tuviera que hacerlo

todo. El make trabaja con un fichero makefile, es un fichero que contiene todas

las relaciones y dependencias entre ficheros fuente, entre junto con los comandos

necesarios para construirlos y compilarlos.

En cada directorio del kernel se encuentra un fichero makefile, incluyendo el

fichero raíz. Cuando se invoca el comando ’make dep’ o ’make bzImage’ o bien

el ’make modules’, make opera desde el nivel más alto y trabaja recursivamente

con todos los ficheros makefile de cada uno de los subdirectorios, dependiendo de

las opciones con que se incluyeron en el paso de configuración.

lclint

Algunos errores de programas se pueden resolver al principio del ciclo de

desarrollo, ahorrando tiempo y esfuerzo. Puede que no importe este tipo de pro-

gramas cuando se analiza código normal, con programas de menor envergadura,

pero los bugs en el kernel son más difíciles de tratar y pueden hacer aparecer pro-

blemas muy serios. Además mientras un usuario, está más o menos acostumbrado

a que se pare o haga core dumps un cliente de correo por ejemplo, pero lo que

no está acostumbrado y no puede acostumbrarse es a que el sistema operativo se

congele o peor aún que pierda datos.

lclint es un programa que puede ser usado para checkear el código C de manera

estática, que significa hacer checks o comprobaciones antes que se haya compila-

do o ejecutado. Como lint, lclint puede ser ejecutado para recoger errores comunes

de C. Sin embargo, lcint puede hacer mucho más para ti, pero para ello hay que

aprender a como usarlo anotando en el código comentarios de una manera espe-

68


cífica.

En resumen, lclint puede dar facilidad a la hora de comprobar errores an-

tes de pasar el compilador. Para averiguar más información buscar en la página

http://lclint.cs.virginia.edu/.

5.3.3. Navegación

Una de las actividades que más se hace cuando se empieza a programar con

el kernel es navegar arriba y abajo por todo el código, al menos hasta que uno se

familiariza con la gran cantidad de código fuente. Hay herramientas que facilitan

esta navegación.

grep

grep se usa para encontrar líneas que concuerden con un patron dado. Es una

herramienta muy útil para localizar de una forma rápida definiciones de variables

o de funciones. Por ejemplo queremos buscar todas los ficheros que contengan la

palabra sk_buff, para averiguar la estructura de datos que se guarda en los buffers

sk. Pues se ejecuta el comando siguiente:

grep -nH ’sk_buff’ -r * > fichero_salida_grep

Este comando busca recursivamente (-r) por todos los ficheros y directorios (*)

del árbol de código e imprime todos los los nombre de ficheros (-H) y el número

de línea (-n) donde aparece sk_buff, el resultado de la búsqueda es recomendable

volcarlo a un fichero para luego poder navegarlo.

El resultado de la búsqueda anterior es muy larga, debido a que es una es-

tructura de los datos que recibimos por las tarjetas de red y cada driver tiene una,

además de ser la estructura dentro del kernel de los datos que se reciben. Aún así

aquí pongo el resultado de unas cuantas líneas:

net/bluetooth/hci_core.c:1028:int hci_send_acl(struct hci_conn *conn,

struct sk_buff *skb, __u16 flags)

net/bluetooth/hci_core.c:1031: struct sk_buff *list;

69


net/bluetooth/hci_core.c:1074:int hci_send_sco(struct hci_conn *conn,

struct sk_buff *skb)

net/bluetooth/hci_core.c:1140: struct sk_buff *skb;

net/bluetooth/hci_core.c:1168: struct sk_buff *skb;

cscope

cscope permite navegar por por el código de forma parecida a como lo hace

grep, pero es más inteligente y provee una interfaz mucho más bonita para trabajar.

Se puede buscar por definiciones, usos, strings, etc

Antes de poder usar cscope se necesita construir un fichero índice. Puede ha-

cerse con el comando

cscope -b -R -k

En el directorio raíz de la aplicación. -b para construir el índice, -R para buscar

recusrivamente a través del árbol de directorios y -k para indicar que estamos

usando el kernel para navegar, esto asegura que se incluye los ficheros de forma

correcta al generar el índice. Darse cuenta que el índice debería construirse a partir

de un árbol limpio y recién descomprimido, así que es recomendable guardar una

copia del fichero .config y ejecutar un ’make mrproper’ en el directorio raíz del

código fuente.

Para empezar a trabajar con una sesión cscope, usar el comando

cscope -d

con lo que se consigue entrar en un menú parecido a este:

Cscope version 15.3 Press the ? key for help

Find this C symbol:

Find this global definition:

Find functions called by this function:

70


Find functions calling this function:

Find this text string:

Change this text string:

Find this egrep pattern:

Find this file:

Find files #including this file

Arriba de la pantalla se usa para mostrar los resultados de las búsquedas, mientras

que la torre de abajo se usa para insertar comandos; Por ejemplo, suponiendo que

se quiere encontrar la definición de la estructura de datos _system_type. Usando

las teclas con las flechas se mueve el cursor para encontrar esta definición glo-

bal en ’Find this global definition’: escribir la estructura de datos que queremos

buscar. Si todo funciona correctamente cscope abre el editor configurado, usando

la variable de entorno EDITOR, y se mostrará la seción apropiada del fichero en

cuestión.

Por ejemplo queremos encontrar la definición de super_block. Siguiendo los

pasos comentados antes veríamos la siguiente salida por pantalla:

Global definition: super_block

File Line

0 vxfs_extern.h 44 struct super_block;

1 super.c 265 int (*test)(struct super_block *,

struct buffer_head *);

2 udfdecl.h 52 struct super_block;

3 fs.h 688 struct super_block

4 fs.h 936 struct super_block *(*read_super)

(struct super_block *, void *, int );

5 udf_fs_sb.h 71 __u32 (*s_partition_func)(struct

super_block *, __u32, __u16, __u32);

Find this C symbol:

Find this global definition:

Find functions called by this function:

Find functions calling this function:

Find this text string:

71


Change this text string:

Find this egrep pattern:

Find this file:

Find files #including this file:

Esta vez, cscope ha encontrado más de una definición posible. Así que se verá la

lista de cada una de las definiciones en su contexto y apretando uno de los números

que se mestran en la lista, o bien usando la tecla Tabulador para moverse de uno

a otro por la pantalla y con las teclas de dirección seleccionar una definición. Al

salir del editor se vuelve al cscope. Apretando otra vez el Tabulador podemos

retornar al área de comandos. Para salir del cscope apretar un simple Ctrl+d.

La documentación para el cscope está disponible en la red en la página del

cscope: http://cscope.sourceforge.net/

5.3.4. Manipuladores

diff

Diff es un programa que se usa para comparar dos ficheros y luego listar las

diferencias entre ellos. Cuando se usa en modo unified, con la opción -u, para

comparar dos ficheros, el original y el modificado, y así se crean los parches o

patchs:

diff -u linux-2.4.19/drivers/char/keyboard.c linux/drivers/char/keyboard.c > my_keyboard_patch

Donde el directorio linux-2.4.19 está el original, y en el árbol del directorio linux

tenemos todos los cambios que se van haciendo. La idea de distribuir solo ideas y

modificaciones es mucho más inteligente y a la vez eficiente que distribuir ficheros

enteros o árboles de directorios con código fuente.

El proceso anterior se puede usar cuando tenemos solo un fichero modificado,

pero que pasa si tenemos muchos ficheros modificados y queremos producir un

patch. Pues es lo mismo pero ahora hay que cambiar las opcciones del programa

diff:

diff -urN linux-2.4.19 linux > my_hefty_kernel_patch

72


Darse cuenta que generalmente se usa el direcotrio raíz para generar patches por

ejemplo si se tiene el kernel descomprimido en /usr/src se tiene el directorio modi-

ficado en el /usr/src/linux y el limpio, sin modificaciones, en /usr/src/linux-2.4.19.

Si se quiere generar un patch y enviarlo a la liasta de distribución del kernel de

linux la Linux Kernel Mailing List, hay que asergurarse de seguir las instrucciones

correctamente y exactamente como dicen en el FAQ que puede encontrarse en

http://www.tux.org/lkml/.

patch

patch es un programa que se usa para aplicar parches, producidas por el pro-

grama diff, a un fichero o a un directorio de código fuente. es necesario entrar por

ejemplo, si se va a pasar del kernel linux-2.4.18 al linux-2.4.19 habría que hacer

los siguiente:

cd linux-2.4.18

patch -p1 patch-2.4.19

Esto produce un upgrade o mejora del directorio 2.4.18 al 2.4.19. La opción -p1

se usa en el directorio raíz de todos los nombres de ficheros que indica en el patch.

Se podría aplicar el parche desde un directorio más abajo, pero eso significa que

se debería tner todos los directorios nombrados de la misma manera que en el

ordenador donde se creó el patch o parche. Algunos parches se distribuyen en

ficheros comprimidos para ahorrar ancho de banda. Se puede ahorrar fichero de

descompresión del patch si se aplica de la siguiente manera:

bzip2 -dc /usr/src/patch-2.4.19.bz2 | patch -p1

Reemplazar bzip2 por tar o gzip según se creó el fichero.

Una script que está incluido en el directorio del código fuente del kernel que es

muy útil, se usa para generer de manera semi automática el proceso de upgrade del

directorio aplicando sucesivos parches: linux/scripts/patch-kernel. Leer el script

para ver qué es lo que hace y cómo se usa, las instrucciones están puestas entre

los comentarios al principio del fichero.

En el caso de querer quitar un parche que se aplicado con anterioridad es

necesario escribir la siguiente orden, con la orden de -R (remove):

73


bzip2 -dc /usr/src/patch-2.4.19.bz2 | patch -R -p1

5.3.5. Control de versiones

RCS

Cualquier desarrollo del trabajo es un proceso incremental, particularmente si

se está en la fase de debugación. Siempre se inenta mantener de todos los cambios

hechos en el proceso suando alguna forma de control de revisiones, así si hubiera

un cambio erroneo se podría volver al rebés facilmente. Una forma muy básica

de revisión de control del sistema puede hacerse simplemente haciendo una copia

backup de un fichero antes de hacer cambios importantes, pero esta aproximación

tiende a ser muy ineficiente rápidamente, sobre todo en el caso de estar modifi-

cando varios ficheros a la vez.

Las soluciones son varias, entre ellas tenemos RCS y CVS. El primero de ellos

el RCS es el hermano pequeño de CVS. CVS en cambio es genial para proyectos

grandes con muchos contribuidores y programadores, pero es demasiado trabajo

para proyectos pequeños donde solo hay un programador o unos pocos. Por eso

una de las ventajas que tiene RCS es la simplicidad.

Primero se debe crear un directorio llamado RCS en el mismo directorio que

donde están los ficheros de código fuente.

mkdir RCS

Luego introducir o como dicen los ingleses hacer el ’check in’ del fichero, por

ejemplo para el fichero ’some-file.c’ hacer:

ci -u some-file.c

Tras ello se pedirá insertar una breve descripción. Por defecto, RCS borra el fiche-

ro de trabajo al hacer el check in, así que es interesante poner la opción -u para

comprobar automáticamente si existe un fichero igual, y no borrarlo automática-

mente. Es recomendable hacerlo así con todos los ficheros que se introduzcan.

Hacer algunos cambios en uno de los ficheros que se hayan introducido. Luego

intentar hacer el check in del fichero en cuestión, se mostrará un lista de cambios

y el número de versión se verá incrementado.

74


Suponer que se ha hecho unos cambios erroneos y se quiere volver hacia atrás,

y revertir a una versión buena que sabíamos que funcionaba correctamente, por

ejemplo la versión 1.4, entonces hacer el check out del fichero usando este co-

mando:

co -l -r1.4 some-file.c

La opción -l hace un lock del fichero y te da permisos de escritura para modificar-

lo, sino solo se tiene permisos de lectura.

RCS guarda el fichero inicial y solo las diferencias que existe entre versio-

nes, ahorrando espacio de disco. Para saber más información sobre RCS, ver las

páginas man de: rcs, ci, co, rcsintro, rcsdiff, rcsclean, rcsmerge, rlog, rcsfile y el

ident. La página web donde se puede bajar el software de forma gratuita y donde

se encuentran el tutorial está en http://www.gnu.org/software/rcs/rcs.html.

CVS

Mientras que el RCS es bueno para proyectos donde se usa un pequeño nú-

mero de ficheros, pero se convierte inútil para ficheros más grandes donde hay un

gran número de contribuidores donde haya más de un desarrollador. CVS es par-

ticularmente la mejor idea, además es el programa más usado en la comunidad de

Internet, donde casi todos los proyectos, incluido el del kernel, se llevan usando

CVS.

CVS tiene muchos comandos que están incluidos en el propio cvs, estos se

llaman sub-comandos del cvs. Ambos a los comandos cvs y a los subcomandos se

les puede pasar opciones, pero la posición dentro de la línea de comandos debería

ser así:

$ cvs [cvs options] sub-command [sub-command options]

Aquí paso una breve lista de los subcomandos disponibles:

add: este comando añade un nuevo fichero al control de código. Es necesario

hacer un check in del fichero suando cvs ci después de este comando ara que tenga

efecto el cambio.

75


ci o bien commit: ci que significa check in tiene la misma función que commit,

estos comandos harán el check in de los cambios que se hayan hecho a la

copia local de un fichero en cuestión. Después de introducir este comando,

cualquier update o check out del fichero que está en el repostorio se verán

los cambios que has hecho con el ci. Se puede especificar con la opción -m

’mensaje’ la opción de proveer un mensaje describiendo el cambio. Cuando

se introducen (check in) los cambios y la copia local de los ficheros no son

actualizados, cvs mostrará un mensaje informándote de esto mismo. En este

caso, hay que hacer un update de los ficheros y entonces hacer un check in

con los cambios. Para comprobar los cambios in todos los ficheros modi-

ficados en el directorio de trabajo, hay que ejecutar el siguiente comando

desde desde la raíz del directorio de trabajo:

cvs -q ci -m ’mensaje bla bla bla’

co o bien checkout: Este comando hace una copia local de todos los ficheros en

un módulo que están en el servidor cvs. Primero, creará un subdirectorio

con el mismo nombre que el módulo, entonces copiará los ficheros al sub-

directorio.

diff: Este comando mostrará las diferencias entre la copia local y el fichero que

nos hemos bajado anteriormente del repositorio. Antes he hablado de como

usar este comando.

history: Este comando printa la información sobre el repositorio cvs. Por defecto,

este comando solo muestra información que te pertenece a ti. Si se usa la

opción -a (all) mostrará la información de todos los usuarios. La siguiente

línea es útil para ver los cambios históricos.

cvs history -a -o # Show checked out files$ cvs history -a -T

# Show all tags$ cvs history -a -e # Show all information

import: Este comando podrá un proyecto existente dentro del repositorio.

76


cvs import -m "blah blah ..." directory vendorTag releaseTag

log: Este comando printará los mensajes que se especificaroon en cada uno de los

ficheros que se introdujeron (check in).

remove: Este comando borrará un fichero del control de código. Si tras hacer esto

se hace un check out de un módulo, no se encontrará copia de este fichero.

Aún así, si hacen un check out de una versión anterior del módulo, se podrá

recuperar esa versión anterior de ese fichero.

tag: Para hacerles un tag a los ficheros en el directorio de trabajo actual, se debe

ejecutar la siguiente línea de comandos

cvs -q tag NombreDelTag

update: Este comando hará un update de la copia local de los ficheros de un

módulo. Para cualqier fichero que se le haga el update, se printa el nombre

prededido con una ’U’. Así se permite imprimir los nombres de los ficheros

que se han modificado. Por ejemplo, aquellos que son diferente de la copia

del repositorio y entonces preceden con una ’M’. Para listar los documen-

tos que se han modificado dentro del directorio de trabajo actual, se debe

ejecutar la siguiente orden desde la raíz del directorio de trabajo:

cvs -q update

El repositorio de cvs se debe especificar usando la opción -d en el comando cvs o

también se puede hacer con la variable de entorno CVSROOT. Por ejemplo de la

primera forma sería:

cvs -d pathName login

Y de la segunda manera se escribiría:

export CVSROOT=pathName$ cvs login

77


En el caso que el repositorio estuviera en el mismo sistema, la opción es muy

simple y solo habría que escribir el path al repositorio, por ejemplo /usr/src/cvs, y

se haría de la siguiente manera:

export CVSROOT=/usr/local/cvs

Pero en el caso que el repositorio esté en otro sistema, que es lo más normal, y

lo que sucede con el kernel de Linux, en la especificación del repositorio debe

incluirse el método de acceso, el nombre del usuario y el nombre del servidor

donde está localizado el repositorio. Cada uno de estos items, el método de acceso,

el nombre del usuario y el nombre del servidor, y el path del repositorio en el

servidor, deben estar separados por dos puntos. Y entre el nombre de usuario y el

del servidor debe ir una arroba ’@’. Se hace de la siguiente manera:

export CVSROOT=:accessMethod:userName@serverName:pathName

Por ejemplo para Linux Top of Tree, versión 2.4, debemos usar el siguiente co-

mando. Este respositorio es una copia (mirror) que se actualiza cada 30 minutos.

export CVSROOT=:pserver:[email protected]:/vger$

cvs loginPassword: cvs$ cd some-directory

# Por ejemplo, /usr/local/src$ cvs -z3 co linux

Y para hacer un update del código fuente hay que usar la siguiente orden:

cd some-directory/linux$ cvs -z3 update -d

Esta es solo una presentación del CVS, que es muy extenso, para más información

dirigirse a la página oficial del proyecto CVS: http://www.cvshome.org/

Y aquí termina la selección de aplicaciones para poder trabajar dentro del

kernel.

78

5 EL SISTEMA OPERATIVO LINUX 5.4 Netfilter en los kernels 2.4

5.4. Netfilter en los kernels 2.4

Como ya comenté un firewall está integrado dentro del sistema operativo. La

cuestión es que a la hora de diseñar el actual sistema de filtrado de paquetes, el

Netfilter, Rusty Russell compaginaba su trabajo con Alan Cox. Los dos se man-

tenían en contacto para realizar el nuevo sistema que hay en los kernels 2.4. Este

trabajo conjunto hace que el sistema de captura de paquetes comentado antes y

el sistema Netfilter estén muy relacionados. Es por eso que el proyecto se verá

influenciado por este sistema, ya que hay unos puntos concretos por donde se ase-

gura que pasan todos los sk_buffs de entrada. Y es esa razón la que hace que sea

importante entender correctamente como funciona este sistema y luego decidir

donde insertar las funciones que se encargan de capturar los datos guardados en

estructuras sk_buff para hacerles luego el filtrado.

El sistema actual de filtrado de paquetes pone 5 tipos diferentes de hooks o

ganchos:

PRE_ROUTING IP_FORWARD IP_POST_ROUTINGROUTE

IP_LOCAL_IN IP_LOCAL_OUT

ROUTE

UsuarioHooks del sistema anterior

A la izquierda es donde los paquetes llegan, tras pasar por unos chequeos de

sanidad (no truncado, IP checksum correcto, no se ha recivido en modo promis-

cuo, etc), se pasan a uno de los hooks de netfitler el gancho de NF_IP_PRE_ROUTING.

Luego los datos entran en el código de routing, donde se decide a dónde se en-

vía los paquetes, si se destina a otra interfaz o si es para un proceso local. El código

de routing puede eliminar aquellos paquetes que no tengan una ruta disponible. Si

se destina para el ordenador en sí, se le llama a la función del netfilter y se marca

como que ha entrado por el hook NF_IP_LOCAL_IN. Si se destina a pasar a otra

interfaz entonces entrará dentro del netfilter y se le marcará como que ha entrado

79


por el tercer hook, el NF_IP_FORWARD. Entonces el hook del netfilter pasa por

el cuarto hook, el NF_IP_POST_ROUTING antes de pasarse a la tarjeta de red

donde se enviará al cable. Existe todavía un quinto hook, el NF_IP_LOCAL_OUT

los datos pasan por aquí si se han creado localmente.

Esta es la forma que tiene el actual sistema para capturar los paquetes, pero ¿es

el mismo sistema que quiero utilizar yo? pues no, es lógico que este influenciado,

todos los firewalls trabajan de una forma parecida, pero tiene inconvenientes y

también sus ventajas.

5.4.1. Ventajas

La principal característica es que tiene 5 hooks, cuando antes en los kernels

2.2 solo tenía 3 hooks. Bueno entonces ellos (Rusty Russell principalmente) ha-

brán creido que es mejor. Y es que de esta forma se controla perfectamente a un

paquete. En los firewalls anteriores se filtraba al paquete tanto cuando llega, co-

mo cuando pasa por el forward y cuando salía. Ahora además se controla cuando

los paquetes van dirigidos a algún programa del sistema o cuando lo ha generado

alguien del sistema. Eso añade control y hace que se puede poner políticas de se-

guridad para controlar caballos de troya o rootkits que se puedan instalar dentro

del sistema. Es una mejora sustancial respecto a los antiguos kernels. Pero esta

mejora de control se puede plantear también como un problema. Y es una de las

razones por las que me propuse hacer este firewall.

5.4.2. Inconvenientes

El principal inconveniente es que un paquete pasa por muchos hooks, pasa

muchas veces por todas las políticas del firewall y cada vez que se pasa por un

hook se comprueba para cada una de las políticas y las sesiones abiertas si cumple

o no, si se elimina el paquete o no. La intención es tener un control completo de

los paquetes que pasan por el sistema, y esa es la mayor ventaja, pero se pierde en

tiempo, que un paquete pase por tres filtros o incluso si se inserta un firewall proxy

puede llegar a pasar por cuatro filtros tiene un coste en tiempo. Rusty Russell

insertó la idea de hacer una cache para los paquetes, y dentro de la estructura

sk_buff se ha añadido nuevos datos, como puede leerse en include/linux/skbuff.h:

80


struct sk_buff {

...

...

#ifdef CONFIG_NETFILTER

/* Can be used for communication between hooks. */

unsigned long nfmark;

/* Cache info */

__u32 nfcache;

/* Associated connection, if any */

struct nf_ct_info *nfct;

#ifdef CONFIG_NETFILTER_DEBUG

unsigned int nf_debug;

#endif

#endif /*CONFIG_NETFILTER*/

...

}

Donde añade una cache para cada paquete, y así, cuando se pasa por un filtro se

marca que cosas se ha hecho en la cache y luego en los otros filtros no vuelve a

hacer los mismos chequeos. Es contradictorio poner tantos filtros para luego tener

que montar un sistema por encima para saltárselos.

Otro inconveniente de este sistema es que es una topología está pensada para

hacer funciones de firewall y a la vez de servidor. Hay tres encargados de mirar el

filtrado de paquetes para los que llegan, para los que pasan por el router y para los

que se van. Y hay los otros dos hooks que nos sirve para controlar si hay troyanos.

La idea está bien, pero un firewall tiene que ser solo eso, un firewall, no se le

debe poner ningún servicio en él, tiene que ser unordenador bastión y el único

servicio que debe tener es el de SSH para hacer conexiones remotamente y poder

administrarlo. Sin servicios en el firewall, no es necesario montar los dos hooks

restantes para controlar los troyanos. Por definición un firewall tiene que ser un

equipo rápido y con pocos o ningún servicio disponible.

81

5 EL SISTEMA OPERATIVO LINUX 5.5 Viaje de un paquete

5.5. Viaje de un paquete


Tras hacer las respectivas pruebas, tras compilar el kernel, insertadar peque-

ños programas dentro del kernel, después de debugar para ver como funciona el

proceso de debugar y de tener los esquemas de como funcionará el firewall. Es la

hora de averiguar donde se debe poner el filtrado de paquetes dentro del kernel.

La documentación [WS1] habla de unos ficheros ip_input.c donde trata los

paquetes IP de entrada, un ip_forward.c donde se hace el forward de una interfaz

de entrada a otra de salida y del fichero ip_output.c que se encarga de tratar todos

los paquetes que salen del ordenador. En dicha documentación [WS1] aparece

como se trata la información y los datos. Pero en el libro de Stevens se trata un

sistema Unix, que teóricamente debe ser igual en un sistema Linux.

Se trata de averiguar como viaja un paquete cualquiera por el sistema opera-

tivo, y allá donde se crea que es mejor insertar el firewall. Y la idea es coger el

paquete y pasarlo compararlo con las políticas de seguridad. Que es un paque-

te bueno, pues se deja donde estaba y que continue su viaje por la capa OSI del

sistema operativo. Que es malo, entonces se borra, dar cuenta de ello al sistema

operativo y hacer un log si el usuario lo cree conveniente.

5.5.2. Tarjeta de red

La tarjeta ethernet es un dispositivo hardware del nivel 1 y 2 de la capa OSI, es

una tarjeta con sus chips, circuitos y microcontroladores. Esta tiene una dirección

particular, que siempre es diferente para cada una de las tarjetas de red que hay

en el mundo. Esta dirección es la MAC. La tarjeta está siempre escuchando los

paquetes que pasan por su interfaz, cuando ve un paquete cuya dirección MAC

corresponde a la suya propia, o bien un paquete con una dirección de broadcast

(FF:FF:FF:FF:FF:FF para las Ethernet) entonces empieza a leer los datos y los

carga en su memoria.

Cuando termina de leer todo el paquete, la tarjeta genera una petición de inte-

rrupción. La rutina que se encarga de servir la interrupción y que trata la petición

es parte del driver de la tarjeta, que es parte del sistema operativo en sí, el cual

82


ejecuta con las interrupciones deshabilitadas las siguientes operaciones:

1. Crear una nueva estructura sk_buff, dedinida en el fichero include/linux/skbuff.h,

la cual representa la visión que tiene el sistema operativo de un paquete.

2. Vuelca los datos de información del buffer de la tarjeta de red en la nueva

estructura creada sk_buff, algunos drivers usando la DMA.

3. Llama a la función netif_rx(), que es la función que se encarga de recibir los

datos de la tarjeta de red.

4. Al terminar la función netif_rx(), el sistema operativo vuelve a activar las

interrupciones y termina el servicio de interrupción.

La función netif_rx() prepara el kernel para el siguiente paso de la recepción. Po-

ne la información del sk_buff dentro de lo cola de paquetes de entrada para que

la CPU pueda tratarlo y marca la NET_RX softirq (que es una interrupción por

software que luego hablaré de ellas) para que pueda ser tratada, y esto se hace

mediante la llamada a la función __cpu_raise_softirq( ), definida dentro del fiche-

ro include/linux/interrupt.h. En el caso de que la cola este llena de paquetes este

último paquete se descarta y se pierde. Luego si tenemos una cola para cada CPU,

ambos procesadores pueden procesar los datos (es una de las mejoras del nuevo

kernel al añadir softirqs) lo que hace que la recepción de paquetes sea concurrente

en máquinas Multiprocesador.

Si se desea ver un driver de una Ethernet en acción, se puede mirar algún driver

sencillo como por ejemplo en el fichero drivers/net/8390.c. La rutina de servico

que trata la interrupción se llama ei_interrupt( ), y llama a la función ei_recive( ),

la cual hace lo siguiente:

1. Crea una nueva estructura sk_buff mediante la función dev_alloc_skb( ). Y

vuelca los datos con la función skb_put( skb, pkt_len).

2. Lee el paquete del buffer de la tarjeta con la función ei_block_input( ) y

señaliza el protocolo con skb->protocol= eth_type_trans(skb,dev)

3. Llama a la función netif_rx( ) comentada antes.

83


4. Y vuelca todos los datos, según el contador rx_pkt_count vuelca diez pa-

quetes consecutivamente.

Se puede hechar una ojeada a otros ejemplos mucho más complejos como pueden

ser los driver de cualquier tarjeta 3COM, por ejemplo los ficheros 3c59x.c, donde

usa transferencia por DMA para mover el paquete desde la memoria de la tarjeta

al sk_buff.

5.5.3. Proceso de red

La función netif_rx( ) es muy importante, se encarga de recibir los paquetes

de una tarjeta de red mediante el driver y en cola para que pueda ser tratado por

niveles superiores de la capa OSI dentro del sistema operativo. Actúa de puente

para todos los paquetes que se recogen entre los diferentes drivers de todas las

tarjetas de red, y haciendo de entrada a los protocolos.

Al estar esta función en un contexto de interrupción tiene que ser rápida y

corta. No puede hacer ningún chequeo del tamaño o cualquier otra compleja fun-

ción, ya que el sistema está potencialmente perdiendo paquetes mientras se es-

tá ejecutando el netif_rx( ). Así lo que hace la función es basicamente seleccio-

nar la cola del paquete de un array llamando a softnet_data, el índice del cual

se basa en la CPU donde se está ejecutando. Enconces luego comprueba el es-

tado de la cola, identificando uno de los cinco posibles estados de congestión:

NET_RX_SUCCESS (sin congestión), NET_RX_CN_LOW, NET_RX_CN_MOD,

NET_RX_CN_HIGH (baja, moderada y alta congestión, respectivamente) o bien

NET_RX_DROP (el packet se pierde debido a una congestión crítica). Es un pro-

ceso para defenderse de los ataques DoS, donde una sobrecarga de los paquetes

puede llegar a cargar el kernel de tal manera que no funcione. Aunque bajo condi-

ciones normales, el paqute se inserta en la cola (__skb_queue_tail( )) y la función

__cpu_raise_softirq( ) se llama. La última función hace que se ejecute el softirq.

Cuando la función netif_rx( ) termina, retornando un valor que indica la con-

gestión actual al driver. En este punto, el contexto de la interrupción ha terminado

y el paquete está listo para ser enviado a los protocolos superiores. Este proceso ha

cambiado completamente en la versión del kernel 2.4 donde se basan los softirqs,

84


antes cuando los kernels eran de versión 2.2 se basaba en la mitad inferior (donde

no se podía trabajar en paralelo)

5.5.4. Softirq para NET_RX

Tras recibir el paquete se inserta en una cola para ser procesado posterior-

mente. Este proceso se hace llamando a la función net_rx_action( ). Esta función

desempila el primer paquete (Sk_buff) de la cola actual de la CPU y ejectua a tra-

vés de dos listas de funciones para su proceso según el protocolo. Estas listas se

llaman ptype_all y ptype_base y contienen respectivamente, los handlers del pro-

tocolo para para paquetes genéricos y para paquetes de tipo específico. Los ’proto-

col handlers’ se registran ellos mismos, o bien al iniciarse el kernel o bien cuando

un tipo de socket es creado, declarando qué tipo de protocolo pueden tratar. Para

hacer esto se llama a la función dev_add_pack( ) dentro del fichero net/core/dev.c,

el cual añade una estructura de tipo del paquete (include/linux/netdevice.h) con-

teniendo un puntero a la función será llamada cuando un paquete de ese tipo se

reciba. Tras el registro, cada estructura de un handler se pone o bien en la lista

ptype_all, para el tipo ETH_P_ALL, o bien en la lista ptype_base para otros tipos

ETH_P_*.

Así lo que hace la softirq par la NET_RX es llamar a la secuencia de funciones

registradas en las dos listas para tratar al paquete que es de un tipo de protocolo

específico. Si la cola contiene más de un paquete, la función net_rx_action( )

hace un bucle para poder tratar el máximo número de paquetes que hayan sido

procesados. Cuando la función net_rx_action( ) termina y deja una cola no vacía,

la NET_RX_SOFTIRQ se activa otra vez para permitir el proceso de los paquetes

para más tarde.

5.5.5. Tratar los paquetes IP

Este proyecto solo se encarga de paquetes IP versión 4, en el caso de que se

hiciese para otro protocolo, como por ejemplo IPv6 se debería buscar otro tipo

de handler. Para IPv4 la función se llama ip_rcv( ) y se encuentra en el fiche-

ro net/ipv4/ip_input.c, este es apuntada a las listas antes comentadas cuando se

arranca el sistema, mediante la función ip_init( ), dentro de net/ipv4/ip_output.c.

85


Obviamente, como era de esperar el tipo de protocolo registrado para IP es el

ETH_P_IP.

Cable de Red

Driver

sk_buff

Se trata mediantenetif_rx

ip_input.c ip_output.csk_buff

sk_buff

tcp_input.c udp.cigmp.c

Tarjeta de red

sk_buff

tcp_output.c

sk_buff

Por eso, ip_rcv( ) se llama dentro de net_rx_action( ) durante el proceso de

un softirq, cuando un paquete del tipo ETH_P_IP se desempila. Esta función se

encarga de hacer los chequeos iniciales al paquete IP, los cuales tratan de verificar

la integridad del mismo: IP checksum y tamaño de la cabecera. Si el paquete

parece correcto, se llama a la función ip_rcv_finish( ). Es aquí mismo donde se

introducirá la función de cualquier firewall. Hay que asegurarse de no compilar el

Netfilter cuando se compile el kernel con mi programa, sino se cae en el error de

tener dos filtrados de paquetes.

La función ip_rcv_finish( ), que se encuentra dentro de ip_input.c, se encarga

de hacer el rutado de IP. Se encarga de comprobar si el paquete debe ser retrans-

mitido a otra máquina o si el destino es el host actual. Es aquí donde habría que

incluir los procesos de routing. Si se envía a otra máquina se envía a la interfaz

correspondiente, y si el destino final es la propia máquina se envía a los protocolos

superiores. Todo esto se hace en la función ip_route_input( ), llamada al principio

de ip_rcv_finish( ), la cual determina cual es el siguiente paso.

Si el destino es la propia máquina, entonces se llama a la función ip_locl_deliver( ).

Esta función se encarga de reensamblar los diferentes paquetes IP, en el caso que el

datagrama esté fragmentado, y entonces llama a la función ip_local_deliver_finish( ).

86


Si el destino es otra máquina el proceso entonces se envía a la función net/ipv4/ip_output.c

que será donde se pase el chequeo de todos los paquetes que salgan del ordenador.

Para diferenciar las dos llamadas a cada una de las funciones se le pasará si es de

entrada o de salida. Dependiendo de donde se llame, si es desde ip_input.c se le

marcará al paquete como de entrada, que se llama desde ip_output.c es de salida.

Se puede profundizar más dentro de los protocolos del siguiente nivel (TCP,

UDP e ICMP) pero el proyecto no trata los paquetes a tan alto nivel. Como se

explicó en las secciones de teoría de filtrado de paquetes.

87

6 ESTUDIO DEL DISEÑO ( UML)

6. Estudio del Diseño ( UML)

6.1. Introducción al UML

6.1.1. Historia

El "Unified Modelling Languaje" (UML) provee a los analistas y arquitectos

de sistemas que trabajan en el diseño y análisis de objetos de un lenguaje con-

sistente para especificar, visualizar, construir y documentar los artefactos de un

sistema de software, así también es útil para hacer modelos de negocios.

Esta especificación es la evolución del las tres anteriores tecnologías orienta-

das a objetos lideres (Booch, OMT y OOSE). El UML es la unión de estos len-

guajes de modelos y aún mas ya que incluye expresiones adicionales para manejar

problemas de modelaje que los métodos anteriores no cubrían plenamente.

El desarrollo de el UML empezó en octubre de 1994 cuando Grady Booch y

Jim Rumbaugh de Rational Software Corporation iniciaron su trabajo para uni-

ficar los métodos de Booch y OMT. Debido a que los métodos Booch y OMT

ya habían madurado independientemente y eran reconocidos como métodos líde-

res en el desarrollo orientado a objetos, Booch y Rumbaugh unieron fuerzas para

forjar una unificación completa de los dos métodos. Una versión preliminar 0.8

de el "método unificado" fue dad a conocer en octubre de 1995. Poco después,

Ivar Jacobson y su compañía "Objectory" se unieron a Rational y a su trabajo de

unificación, uniendo el método OOSE (Object Oriented software engineering). El

Nombre de Objectory es ahora dado mayormente para describir a el Proceso que

acompaña al UML el "Rational unified process".

88

6 ESTUDIO DEL DISEÑO ( UML) 6.1 Introducción al UML

6.1.2. Objetivos

Los objetivos de la unificación fueron: el mantenerlo simple, el quitar elemen-

tos de los lenguajes de Booch, OMT y OOSE que no funcionaran en la práctica, el

añadir elementos de otros métodos que fueran más efectivos y el inventar nuevas

construcciones solamente cuando la solución existente no estuviera disponible.

UML es un lenguaje de modelado de propósito general que pueden usar todos

los modeladores. No tiene propietario y está basado en el común acuerdo de gran

parte de la comunidad informática. UML no pretende ser un método de desarrollo

completo. No incluye un proceso de desarrollo paso a paso. UML incluye todos

los conceptos que se consideran necesarios para utilizar un proceso moderno itera-

tivo, basado en construir una sólida arquitectura para resolver requisitos dirigidos

por casos de uso. Ser tan simple como sea posible pero manteniendo la capacidad

de modelar toda la gama de sistemas que se necesita construir. UML necesita ser

lo suficientemente expresivo para manejar todos los conceptos que se originan en

un sistema moderno, tales como la concurrencia y distribución, así como también

los mecanismos de la ingeniería de software, como son la encapsulación y com-

ponentes. Debe ser un lenguaje universal, como cualquier lenguaje de propósito

general, pretende ser un estándar mundial.

Varios nuevos conceptos existen en UML, incluyendo:

1. Mecanismos de extensión (estereotipos, valores marcados y restricciones),

2. Procesos y ramas de procesamiento

3. Distribución y concurrencia

4. Patrones y colaboración

5. Diagramas de actividad

6. Refinamiento (para manejar las relaciones entre los niveles de abstracción)

7. Interfaces y componentes

8. Un lenguaje para restricciones

89


Aunque el UML define un leguaje preciso, no es una barrera para el desarrollo

futuro en los conceptos de modelaje. Se han incorporado muchas técnicas líderes,

pero se espera que técnicas adicionales influyan las versiones futuras del UML.

Muchas técnicas avanzadas pueden ser definidas usando el UML como base. El

UML puede ser extendido sin redefinir su núcleo.

6.1.3. Participantes en UML 1.0

La lista de participantes incluye grandes empresas de informática, con lo que

se consigue no sólo que haya más intercambio de ideas sino que se cumpla en

un defacto para todo el mundo. Lástima que no esté incluida ninguna empresa de

Linux.

1. Rational Software (Grady Booch, Jim Rumbaugh y Ivar Jacobson)

2. Digital Equipment

3. Hewlett-Packard

4. i-Logix (David Harel)

5. IBM

6. ICON Computing (Desmond D’Souza)

7. Intellicorp and James Martin & co. (James Odell)

8. MCI Systemhouse

9. Microsoft

10. ObjecTime

11. Oracle Corporation.

12. Platinium Technology

13. Sterling Software

14. Taskon

90


15. Texas Instruments

16. Unisys

6.1.4. Áreas conceptuales

Los conceptos y modelos de UML pueden agruparse en las siguientes áreas

conceptuales:

Estructura estática: Cualquier modelo preciso debe primero definir su univer-

so, esto es, los conceptos clave de la aplicación, sus propiedades internas, y

las relaciones entre cada una de ellas. Este conjunto de construcciones es la

estructura estática. Los conceptos de la aplicación son modelados como cla-

ses, cada una de las cuales describe un conjunto de objetos que almacenan

información y se comunican para implementar un comportamiento. La in-

formación que almacena es modelada como atributos; La estructura estática

se expresa con diagramas de clases y puede usarse para generar la mayoría

de las declaraciones de estructuras de datos en un programa.

Comportamiento dinámico: Hay dos formas de modelar el comportamiento,

una es la historia de la vida de un objeto y la forma como interactúa con

el resto del mundo y la otra es por los patrones de comunicación de un con-

junto de objetos conectados, es decir la forma en que interactúan entre sí.

La visión de un objeto aislado es una maquina de estados, muestra la forma

en que el objeto responde a los eventos en función de su estado actual. La

visión de la interacción de los objetos se representa con los enlaces entre

objetos junto con el flujo de mensajes y los enlaces entre ellos. Este punto

de vista unifica la estructura de los datos, el control de flujo y el flujo de

datos.

Construcciones de implementación: Los modelos UML tienen significado para

el análisis lógico y para la implementación física. Un componente es una

parte física reemplazable de un sistema y es capaz de responder a las peti-

ciones descritas por un conjunto de interfaces. Un nodo es un recurso com-

putacional que define una localización durante la ejecución de un sistema.

Puede contener componentes y objetos.

91

6 ESTUDIO DEL DISEÑO ( UML) 6.2 Diagramas

Organización del modelo: La información del modelo debe ser dividida en pie-

zas coherentes, para que los equipos puedan trabajar en las diferentes partes

de forma concurrente. El conocimiento humano requiere que se organice

el contenido del modelo en paquetes de tamaño modesto. Los paquetes son

unidades organizativas, jerárquicas y de propósito general de los modelos de

UML. Pueden usarse para almacenamiento, control de acceso, gestión de la

configuración y construcción de bibliotecas que contengan fragmentos de

código reutilizable.

Mecanismos de extensión: UML tiene una limitada capacidad de extensión pero

que es suficiente para la mayoría de las extensiones que requiere el ’dia a

dia’ sin la necesidad de un cambio en el lenguaje básico. Un estereotipo es

una nueva clase de elemento de modelado con la misma estructura que un

elemento existente pero con restricciones adicionales.

6.2. Diagramas

Un Modelo captura una vista de un sistema del mundo real. Es una abstrac-

ción de dicho sistema, considerando un cierto propósito. Así, el modelo describe

completamente aquellos aspectos del sistema que son relevantes al propósito del

modelo, y a un apropiado nivel de detalle.

Un proceso de desarrollo de software debe ofrecer un conjunto de modelos

que permitan expresar el producto desde cada una de las perspectivas de interés.

El código fuente del sistema es el modelo más detallado del sistema (y además es

ejecutable). Sin embargo, se requieren otros modelos. Cada modelo es completo

desde su punto de vista del sistema, sin embargo, existen relaciones de trazabilidad

entre los diferentes modelos.

Un Diagrama es una representación gráfica de una colección de elementos de

modelado, a menudo dibujada como un grafo conexo de arcos (relaciones) y vér-

tices (otros elementos del modelo). Un diagrama no es un elemento semántico, un

diagrama muestra representaciones de elementos semánticos del modelo, pero su

significado no se ve afectado por la forma en que son representados. Un diagrama

está contenido dentro de un paquete.

92


La mayoría de los diagramas de UML y algunos símbolos complejos son gra-

fos que contienen formas conectadas por rutas. La infomación está sobre todo

en la topología, no en el tamaño o la colocación de los símbolos (hay algunas

excepciones como el diagrma de secuencia con un eje métrico de tiempo). Hay

tres clases importantes de relaciones visuales: conexión (generalmente de líneas

a formas de dos dimensiones), contención (de símbolos por formas cerradas de

dos dimensiones), y adhesión visual (un símbolo que está "cerca" de otro en un

diagrama). Estas relaciones geométricas se reasignan a conexiones entre nodos en

un gráfico en la forma analizada de la notación.

La notación de UML está pensada para ser dibujada en superficies bidimensio-

nales. Algunas formas bidimensionales son proyecciones de formas tridimensio-

nales tales como cubos, pero todavía se representan como íconos en una superficie

bidimensional.

Hay cuatro clases de construcciones gráficas que se usan en la notación de

UML: íconos, símbolos bidimensionales, rutas y cadenas.

Un ícono es una figura gráfica con un tamaño y forma fijos. No se amplía para

contener a su contenido. Los iconos pueden aparecer dentro de símbolos de área,

como terminadores en las rutas o como símbolos independientes que puedan o no

conectar con las rutas.

Los símbolos de dos dimensiones tienen altura y anchura variables, y pueden

ampliarse para permitir otras cosas tales como listas de cadenas o de otros sím-

bolos. Muchos de ellos están divididos en compartimientos similares o de tipos

diferentes. Las rutas se conectan con los símbolos, el arrastrar o suprimir uno de

ellos afecta a su contenido y las rutas conectadas.

Una ruta es una secuencia de segmentos de recta o de curva que se unen en sus

puntos finales. Conceptualmente una ruta es una sola entidad topológica, aunque

sus segmentos se pueden manipular gráficamente. un segemento no debería existir

separado de su ruta. Las rutas siempre van conectdas en ambos extremos.

Las cadenas presentan varias clases de información en una forma "no anali-

zada", UML asume que cada uso de una cadena en la notación tiene una sintaxis

por la cual pueda ser analizada la información del modelo subyancente. Las cade-

nas pueden existir como el contenido de un compartimiento, como elementos en

las listas, como etiquetas unidas a los símbolos o a las rutas, o como elementos

93


independientes en un diagrama.

6.2.1. Diagramas estructurales

Se usan para visualizar, especificar, construir y documentar aspectos estáticos

de un sistema. Que son el esqueleto e incluyen la existencia y ubicación de clases,

interfaces, colaboraciones, componentes y nodos.

Diagrama de clases: Representa las clases, interfaces y colaboraciones y rela-

ciones entre ellas.

Diagramas de objetos: Representa objetos y sus relaciones. SE usa para descri-

bir estructuras de datos.

Diagramas de componentes: Muestra el conjunto de componentes y sus rela-

ciones. Los diagramas de componentes se relacionan con los diagramas de

clases dado que los componentes son grupo de clases, interfaces y colabo-

raciones.

Diagramas de despliegue: Muestra conjunto de nodos y sus relaciones. Se usan

para describir la vista de despliegue estática de una arquitectura. Se rela-

cionan con los diagramas de componentes porque un nodo incluye normal-

mente uno o más componentes.

6.2.2. Diagramas de comportamiento

Se usa para los aspectos dinámicos de un sistema. Que son las partes muta-

bles como el flujo de mensajes a lo largo del tiempo el movimiento físico de

componentes en una red.

Diagramas de casos de uso: representas casos de uso, actores y sus relaciones.

Diagramas de secuencia: Junto con los diagramas de colaboración representan

a los diagramas de interacción, que resalta la ordenación temporal de los

mensajes. Representa el conjunto de objetos y los mensajes enviados y re-

cibidos entre ellos.

94

6 ESTUDIO DEL DISEÑO ( UML) 6.3 Diagramas de Objetos

Diagramas de colaboración: Son diagramas de interacción que resalta la orga-

nización estructural de los objetos que envían y reciben sus mensajes. Re-

presentan los objetos enlazados unos con otros con sus mensajes enviados

y recibidos.

Diagramas de estado: Son máquinas de estados, con sus transiciones, eventos y

actividades. Ayudan a modelar el comportamiento.

Diagramas de actividades: Muestra el flujo de actividades. Muestran el flujo se-

cuencial de actividades y los objetos que actúan y sobre los que actúa.

6.3. Diagramas de Objetos

Objeto es una entidad discreta con límites bien definidos y con identidad, es

una unidad atómica que encapsula estado y comportamiento. La encapsulación en

un objeto permite una alta cohesión y un bajo acoplamiento. el Objeto es recono-

cido también como una instancia de la clase a la cual pertenece.

La encapsulación presenta tres ventajas básicas:

1. Se protegen los datos de accesos indebidos

2. El acoplamiento entre las clases se disminuye

3. Favorece la modularidad y el mantenimiento

Un objeto se puede ver desde dos perspectivas relacionadas: como una entidad de

un determinado instante de tiempo que posee un valor específico (Un objeto puede

caracterizar una entidad física -coche-) y como un poseedor de identidad que tiene

distintos valores a lo largo del tiempo (abstracta -ecuación matemática-).

Cada objeto posee su propia identidad exclusiva y se puede hacer referencia

a él mediante una denominación exclusiva que permite accederle. El Modelado

de Objetos permite representar el ciclo de vida de los objetos a través de sus

interacciones. En UML, un objeto se representa por un rectángulo con un nombre

subrayado.

1. Objeto = Identidad + Estado + Comportamiento

95


2. El estado está representado por los valores de los atributos.

3. Un atributo toma un valor en un dominio concreto.

La regla general para la notación de instancias consiste en utilizar el mismo sím-

bolo geométrico que el descriptor. En la instancia se muestran los posibles valores

pero las propiedades compartidas sólo se pone de manifiesto en el descriptor. La

notación canónica es un rectángulo con tres compartimientos. En el primero va

el nombre del objeto, en el segundo sus atributos y en el tercero sus operaciones.

Este último puede ser omitido si así se prefiere.

6.3.1. Oid (Object Identifier)

Cada objeto posee un oid. El oid establece la identidad del objeto y tiene las

siguientes características:

1. Constituye un identificador único y global para cada objeto dentro del sis-

tema.

2. Es determinado en el momento de la creación del objeto.

3. Es independiente de la localización física del objeto, es decir, provee com-

pleta independencia de localización.

96


4. Es independiente de las propiedades del objeto, lo cual implica independen-

cia de valor y de estructura.

5. No cambia durante toda la vida del objeto. Además, un oid no se reutiliza

aunque el objeto deje de existir.

No se tiene ningún control sobre los oids y su manipulación resulta transparente.

Sin embargo, es preciso contar con algún medio para hacer referencia a un objeto

utilizando referencias del dominio (valores de atributos).

6.3.2. Características alrededor de un objeto

Estado: El estado evoluciona con el tiempo. Algunos atributos pueden ser cons-

tantes, el comportamiento agrupa las competencias de un objeto y describe

las acciones y reacciones de ese objeto. Las operaciones de un objeto son

consecuencia de un estímulo externo representado como mensaje enviado

desde otro objeto.

Persistencia: La persistencia de los objetos designa la capacidad de un objeto

trascender en el espacio/tiempo, podremos después reconstruirlo, es decir,

cogerlo de memoria secundaria para utilizarlo en la ejecución (materiali-

zación del objeto). Los lenguajes OO no proponen soporte adecuado para

la persistencia, la cual debería ser transparente, un objeto existe desde su

creación hasta que se destruya.

Comunicación: Un sistema informático puede verse como un conjunto de ob-

jetos autónomos y concurrentes que trabajan de manera coordinada en la

consecución de un fin específico. El comportamiento global se basa pues en

la comunicación entre los objetos que la componen.

Categorías de objetos: Pueden ser clasificado como Activos o Pasivos, como

Cliente o Servidores, o bien como Agentes.

1. Objeto Activo: Posee un hilo de ejecución (thread) propio y puede iniciar

una actividad.

97

6 ESTUDIO DEL DISEÑO ( UML) 6.4 Diagramas de Clases

2. Objeto Pasivo: No puede iniciar una actividad pero puede enviar estímulos

una vez que se le solicita un servicio.

3. Cliente es el objeto que solicita un servicio.

4. Servidor es el objeto que provee el servicio solicitado.

5. Los agentes reúnen las características de clientes y servidores. Son la ba-

se del mecanismo de delegación. Introducen indirección: un cliente puede

comunicarse con un servidor que no conoce directamente.

Mensajes: La unidad de comunicación entre objetos se llama mensaje. El men-

saje es el soporte de una comunicación que vincula dinámicamente los ob-

jetos que fueron separados previamente en el proceso de descomposición.

Adquiere toda su fuerza cuando se asocia al polimorfismo y al enlace di-

námico. Un estímulo causará la invocación de una operación, la creación

o destrucción de un objeto o la aparición de una señal. Un mensaje es la

especificación de un estímulo.

6.4. Diagramas de Clases

El Diagrama de Clases es el diagrama principal para el análisis y diseño. Un

diagrama de clases presenta las clases del sistema con sus relaciones estructurales

y de herencia. La definición de clase incluye definiciones para atributos y opera-

ciones. El modelo de casos de uso aporta información para establecer las clases,

objetos, atributos y operaciones.

El mundo real puede ser visto desde abstracciones diferentes (subjetividad).

Mecanismos de abstracción:

1. Clasificación / Instanciación

2. Composición / Descomposición

3. Agrupación / Individualización

4. Especialización / Generalización

98


La clasificación es uno de los mecanismos de abstracción más utilizados. La clase

define el ámbito de definición de un conjunto de objetos, y cada objeto pertenece

a una clase, Los objetos se crean por instanciación de las clases.

Cada clase se representa en un rectángulo con tres compartimientos:

nombre de la clase

atributos de la clase

operaciones de la clase

Los atributos de una clase no deberían ser manipulables directamente por el resto

de objetos. Por esta razón se crearon niveles de visibilidad para los elementos que

son:

1. (-) Privado : Es el más fuerte. Esta parte es totalmente invisible (excepto

para clases friends en terminología C++).

2. (#) Los atributos/operaciones protegidos están visibles para las clases friends

y para las clases derivadas de la original.

3. (+) Los atributos/operaciones públicos son visibles a otras clases (cuando

se trata de atributos se está transgrediendo el principio de encapsulación).

6.4.1. Relaciones entre clases

Semánticamente todas las relaciones, incluidas la generalización, la asociación

y la realización son tipos de dependecias. Pero tienen una semántica lo bastante

importante como para justificar que se traten como distintos tipos de relaciones

en UML. Es una decisión de diseño. La expericencia muestra que este enfoque

mantiene un equilibrio entre dar importancia a los tipos importantes de relaciones

y no sobrecargar al modelador con demasiadas opciones. Uno no se equivocará si

modela la generalización, la asociación y la realización en primer lugar y luego

ve las demás relaciones como tipos de dependencias.

Relación de Dependencias: Relación de uso. Declara que un cambio en la espe-

cificación del elemento usado puede afectar al elemento que lo usa. Como

puede verse en la imagen, la figura usa posicion

99


Relación de Generalización: Relación "hereda_de" o bien "es_un_tipo_de". En-

tre una superclase o padre y una subclase o hijo. En la imagen tenemos que

Rectángulo y Círculo heredan de Figura.

Relación de Asociación: Relación estructural que especifica conexión entre dos

objetos. Conexión entre dos objetos es una asociación binaria y entre n cla-

ses es una n-aria. Dentro de este grupo de relaciones tenemos relación de

asociación por nombre, por rol, por multiplicidad y por agragación.

Nombre: Describe la naturaleza de la asociación. En la figura un empleado

trabaja para otra clase.

Rol: Rol que se juega en una asosciación. Tenemos que una persona vista

desde la fábrica es un empleado.

100

6 ESTUDIO DEL DISEÑO ( UML) 6.5 Diagramas de Caso de Uso

Multiplicidad: Indica "cuantos" objetos en un extremo de la asociación per-

tenecen. En el ejemplo tenemos que una fábrica tiene un número indefinido

de personas trabajando en ella.

Agregación: Relación "tiene_un". Relacion entre objetos del mismo nivel

pero con una relación todo/parte, uno es "parte" del "todo".

6.5. Diagramas de Caso de Uso

Casos de Uso es una técnica para capturar información de cómo un sistema

o negocio trabaja, o de cómo se desea que trabaje. No pertenece estrictamente al

enfoque orientado a objeto, es una técnica para captura de requisitos.

Los Casos de Uso (Ivar Jacobson) describen bajo la forma de acciones y

reacciones el comportamiento de un sistema desde el p.d.v. del usuario.

Permiten definir los límites del sistema y las relaciones entre el sistema y el

entorno.

101

6 ESTUDIO DEL DISEÑO ( UML) 6.5 Diagramas de Caso de Uso

Los Casos de Uso son descripciones de la funcionalidad del sistema inde-

pendientes de la implementación.

Comparación con respecto a los Diagramas de Flujo de Datos del Enfoque

Estructurado.

Los Casos de Uso cubren la carencia existente en métodos previos (OMT,

Booch) en cuanto a la determinación de requisitos.

Los Casos de Uso particionan el conjunto de necesidades atendiendo a la

categoría de usuarios que participan en el mismo.

Están basados en el lenguaje natural, es decir, es accesible por los usuarios.

6.5.1. Actores

La misma persona física puede interpretar varios papeles como actores distin-

tos, el nombre del actor describe el papel desempeñado.

1. Principales: personas que usan el sistema.

2. Secundarios: personas que mantienen o administran el sistema.

3. Material externo: dispositivos materiales imprescindibles que forman parte

del ámbito de la aplicación y deben ser utilizados.

4. Otros sistemas: sistemas con los que el sistema interactúa.

Los Casos de Uso se determinan observando y precisando, actor por actor, las

secuencias de interacción, los escenarios, desde el punto de vista del usuario. Los

casos de uso intervienen durante todo el ciclo de vida. El proceso de desarrollo

estará dirigido por los casos de uso. Un escenario es una instancia de un caso de

uso.

UML define cuatro tipos de relación en los Diagramas de Casos de Uso. La

Comunicación, la Inclusión, que es una instancia del Caso de Uso origen incluye

también el comportamiento descrito por el Caso de Uso destino. «include» reem-

plazó al denominado «uses». La Extensión : el Caso de Uso origen extiende el

102

6 ESTUDIO DEL DISEÑO ( UML) 6.6 Diagramas de Estado

comportamiento del Caso de Uso destino. «extend» y la Herencia : el Caso de

Uso origen hereda la especificación del Caso de Uso destino y posiblemente la

modifica y/o amplía.

6.6. Diagramas de Estado

Muestra el conjunto de estados por los cuales pasa un objeto durante su vida

en una aplicación, junto con los cambios que permiten pasar de un estado a otro.

Los Diagramas de Estado representan autómatas de estados finitos, desde el

p.d.v. de los estados y las transiciones. Son útiles sólo para los objetos con un

comportamiento significativo. Cada objeto está en un estado en cierto instante.

El estado está caracterizado parcialmente por los valores algunos de los atributos

del objeto. El estado en el que se encuentra un objeto determina su comporta-

miento. Cada objeto sigue el comportamiento descrito en el Diagrama de Estados

asociado a su clase. Los Diagramas de Estados y escenarios son complementa-

rios, los Diagramas de Estados son autómatas jerárquicos que permiten expresar

concurrencia, sincronización y jerarquías de objetos, son grafos dirigidos y deter-

ministas. La transición entre estados es instantánea y se debe a la ocurrencia de

un evento.

6.6.1. Estado

Identifica un periodo de tiempo del objeto (no instantáneo) en el cual el objeto

está esperando alguna operación, tiene cierto estado característico o puede recibir

cierto tipo de estímulos. Se representa mediante un rectángulo con los bordes

redondeados, que puede tener tres compartimientos: uno para el nombre, otro para

el valor característico de los atributos del objeto en ese estado y otro para las

acciones que se realizan al entrar, salir o estar en un estado (entry, exit o do,

respectivamente).

Eventos

Es una ocurrencia que puede causar la transición de un estado a otro de un

objeto. Esta ocurrencia puede ser una de varias cosas:

103


Condición que toma el valor de verdadero o falso

Recepción de una señal de otro objeto en el modelo

Recepción de un mensaje

Paso de cierto período de tiempo, después de entrar al estado o de cierta

hora y fecha particular

El nombre de un evento tiene alcance dentro del paquete en el cual está definido,

no es local a la clase que lo nombre.

6.6.2. Envío de mensajes

Además de mostrar y transición de estados por medio de eventos, puede repre-

sentarse el momento en el cual se envían mensajes a otros objetos. Esto se realiza

mediante una línea punteada dirigida al diagrama de estados del objeto receptor

del mensaje.

Transición simple

Una transición simple es una relación entre dos estados que indica que un

objeto en el primer estado puede entrar al segundo estado y ejecutar ciertas ope-

raciones, cuando un evento ocurre y si ciertas condiciones son satisfechas. Se

representa como una línea sólida entre dos estados, que puede venir acompañada

de un texto con el siguiente formato:

event-signature "[" guard-condition] "/" action-expression "^"send-clause

event-signature es la descripción del evento que da lugar la transición, guard-

condition son las condiciones adicionales al evento necesarias para que la tran-

sición ocurra, action-expression es un mensaje al objeto o a otro objeto que se

ejecuta como resultado de la transición y el cambio de estado y send-clause son

acciones adicionales que se ejecutan con el cambio de estado, por ejemplo, el

envío de eventos a otros paquetes o clases.

104


Transición interna

Es una transición que permanece en el mismo estado, en vez de involucrar dos

estados distintos. Representa un evento que no causa cambio de estado. Se denota

como una cadena adicional en el compartimiento de acciones del estado.

6.6.3. Acciones

Podemos especificar la solicitud de un servicio a otro objeto como consecuen-

cia de la transición. Se puede especificar el ejecutar una acción como consecuencia

de entrar, salir, estar en un estado, o por la ocurrencia de un evento.

Generalización de Estados:

Podemos reducir la complejidad de estos diagramas usando la generaliza-

ción de estados.

Distinguimos así entre superestado y subestados.

Un estado puede contener varios subestados disjuntos.

Los subestados heredan las variables de estado y las transiciones externas.

La agregación de estados es la composición de un estado a partir de varios

estados independientes.

La composición es concurrente por lo que el objeto estará en alguno de los estados

de cada uno de los subestados concurrentes. La destrucción de un objeto es efecti-

va cuando el flujo de control del autómata alcanza un estado final no anidado. La

llegada a un estado final anidado implica la subida al superestado asociado, no el

fin del objeto.

Subestados

Un estado puede descomponerse en subestados, con transiciones entre ellos y

conexiones al nivel superior. Las conexiones se ven al nivel inferior como estados

de inicio o fin, los cuales se suponen conectados a las entradas y salidas del nivel

inmediatamente superior.

105

6 ESTUDIO DEL DISEÑO ( UML) 6.7 Diagramas de actividades

Transacción Compleja

Una transición compleja relaciona tres o más estados en una transición de

múltiples fuentes y/o múltiples destinos. Representa la subdivisión en threads del

control del objeto o una sincronización. Se representa como una línea vertical de

la cual salen o entran varias líneas de transición de estado.

Transición a estados anidados

Una transición hacia un estado complejo (descrito mediante estados anidados)

significa la entrada al estado inicial del subdiagrama. Las transiciones que salen

del estado complejo se entienden como transiciones desde cada uno de los subes-

tados hacia afuera (a cualquier nivel de profundidad).

Transiciones temporizadas

Las esperas son actividades que tienen asociada cierta duración.

La actividad de espera se interrumpe cuando el evento esperado tiene lugar.

Este evento desencadena una transición que permite salir del estado que

alberga la actividad de espera. El flujo de control se transmite entonces a

otro estado.

6.7. Diagramas de actividades

Un estado de actividad representa una actividad: un paso en el flujo de tra-

bajo o la ejecución de una operación. Un grafo de actividades describe grupos

secuenciales y concurrentes de actividades. Los grafos de actividades se muestran

en diagramas de actividades. Las actividades se enlazan por transiciones automáti-

cas. Cuando una actividad termina se desencadena el paso a la siguiente actividad.

Un diagrama de actividades es provechoso para entender el comportamiento

de alto nivel de la ejecución de un sistema, sin profundizar en los detalles internos

de los mensajes. Los parámetros de entrada y salida de una acción se pueden

mostrar usando las relaciones de flujo que conectan la acción y un estado de flujo

de objeto.

106

6 ESTUDIO DEL DISEÑO ( UML) 6.7 Diagramas de actividades

Un grafo de actividades contiene estados de actividad que representa la ejecu-

ción de una secuencia en un procedimiento, o el funcionamiento de una actividad

en un flujo de trabajo. En vez de esperar un evento, como en un estado de espera

normal, un estado de actividad espera la terminación de su cómputo. Cuando la

actividad termina, entonces la ejecución procede al siguiente estado de actividad

dentro del diagrama. una transición de terminación es activada en un diagrama

de actividades cuando se completa la actividad precedente. Los estados de activi-

dad no tienen transiciones con eventos explícitos, peor pueden ser abortados por

transiciones en estados que los incluyen.

Un grafo de actividades puede contener también estados de acción, que son

similares a los de actividad pero son atómicos y no permiten transiciones mientras

están activos. Los estados de acción se deben utilizar para las operaciones cortas

de mantenimiento.

Un diagrama de actividades puede contener bifurcaciones, así como divisiones

de control en hilos concurrentes. los hilos concurrentes representan actividades

que se pueden realizar concurrentemente por los diversos objetos o personas. La

concurrencia se representa a partir de la agregación, en la cual cada objeto tiene su

propio hilo. Las actividades concurrentes se pueden realizar simultáneamente o en

cualquier orden. Un diagrama de actividades es como un organigrama tradicional,

excepto que permite el control de concurrencia además del control secuencial.

6.7.1. Notación

Un estado de actividad se representa como una caja con los extremos redon-

deados que contiene una descripción de actividad. Las transacciones simples de

terminación se muestran como flechas. Las ramas se muestran como condiciones

de guarda en transiciones o como diamantes con múltiples flechas de salida eti-

quetadas. Una división o una unión de control se representa con múltiples flechas

que entran o salen de la barra gruesa de sincronización.

Cuando es necesario incluir eventos externos, la recepción de un evento se

puede mostrar como un disparador en una transición, o como un símbolo especial

que denota la espera de una señal.

A menudo es útil organizar las actividades en un modelo según su responsa-

107

6 ESTUDIO DEL DISEÑO ( UML) 6.8 Diagramas de Interacción

bilidad. Esta clase de asignación puede mostrarse organizando las actividades en

regiones distintas separads por líneas en el diagrama. Debido a su aspecto, esto es

conocido como Calles.

Un diagrama de actividades puede mostrar el flujo de objetos como valores.

Para un valor de salida, se dibuja una flecha con línea discontinua desde la activi-

dad al objeto. Para un valor de entrada, se dibuja una flecha con línea discontinua

desde el objeto a una actividad.

6.8. Diagramas de Interacción

La vista de interacción describe secuencias de intercambios de mensajes entre

los roles que implementan el comportamiento de un sistema. Un rol clasifica-

dor, o simplemente "un rol", es la descripción de un objeto, que desempeña un

determinado papel dentro de una interacción, distinto de los otros objetos de la

misma clase. Esta visión proporciona una vista integral del comportamiento del

sistema, es decir, muestra el flujo de control a través de muchos objetos. La vista

de interacción se exhibe en dos diagramas centrados en distintos aspectos pero

complementarios: centrados en los objetos individuales y centrados en objetos

cooperantes.

Los objetos interactúan para realizar colectivamente los servicios ofrecidos

por las aplicaciones. Los diagramas de interacción muestran cómo se comunican

los objetos en una interacción. Existen dos tipos de diagramas de interacción: el

Diagrama de Colaboración y el Diagrama de Secuencia.

El Diagrama de Secuencia es más adecuado para observar la perspectiva cro-

nológica de las interacciones, muestra la secuencia explícita de mensajes y son

mejores para especificaciones de tiempo real y para escenarios complejos. El Dia-

grama de Colaboración ofrece una mejor visión espacial mostrando los enlaces

de comunicación entre objetos, muestra las relaciones entre objetos y son mejores

para comprender todos los efectos que tiene un objeto y para el diseño de procedi-

mientos. El diagrama de Colaboración puede obtenerse automáticamente a partir

del correspondiente diagrama de Secuencia (o viceversa).

108

6 ESTUDIO DEL DISEÑO ( UML) 6.8 Diagramas de Interacción

Diagramas de Secuencia

1. Muestra la secuencia de mensajes entre objetos durante un escenario con-

creto

2. Cada objeto viene dado por una barra vertical

3. El tiempo transcurre de arriba abajo

4. Cuando existe demora entre el envío y la atención se puede indicar usando

una línea oblicua

Diagramas de Colaboración

1. Son útiles en la fase exploratoria para identificar objetos.

2. La distribución de los objetos en el diagrama permite observar adecuada-

mente la interacción de un objeto con respecto de los demás

3. La estructura estática viene dada por los enlaces; la dinámica por el envío

de mensajes por los enlaces

6.8.1. Colaboración

Es una descripción de una colección de objetos que interactúan para imple-

mentar un cierto comportamiento dentro de un contexto. Describe una sociedad

de objetos cooperantes unidos para realizar un cierto propósito. Una colaboración

contiene ranuras que son rellenadas por los objetos y enlaces en tiempo de ejecu-

ción. Una ranura de colaboración se llama Rol porque describe el propósito de un

objeto o un enlace dentro de la colaboración.

Un rol clasificador representa una descripción de los objetos que pueden par-

ticipar en una ejecución de la colaboración, un rol de asociación representa una

descripción de los enlaces que pueden participar en una ejecución de colabora-

ción. Un rol de clasificador es una asociación que está limitada por tomar parte

en la colaboración. Las relaciones entre roles de clasificador y asociación dentro

de una colaboración sólo tienen sentido en ese contexto. En general fuera de ese

contexto no se aplican las mismas relaciones.

109

6 ESTUDIO DEL DISEÑO ( UML) 6.9 Diagramas de Componentes

Una Colaboración tiene un aspecto estructural y un aspecto de comportamien-

to. El aspecto estrucutral es similar a una vista estática: contiene un conjunto de

roles y relaciones que definen el contexto para su comprtamiento. El comporta-

miento es el conjunto de mensajes intercambiados por los objetos ligados a los

roles. Tal conjunto de mensajes en una colaboración se llama Interacción. Una

colaboración puede incluir una o más interacciones.

6.8.2. Interacción

Es el conjunto de mensajes intercambiados por los roles de clasificador a tra-

vés de los roles de asociación. Un mensaje es una comunicaión unidireccional

entre dos objetos, un flujo de objeto con la información de un remitente a un re-

ceptor. Un mensaje puede tener parámetros que transporten valores entre objetos.

Un mensaje puede ser una señal (comunicación explícita entre objetos, con nom-

bre y asíncrona) o una llamada (la invocación síncrona de una operación con un

mecanismo para el control, que retorna posteriormente al remitente). Un patrón

de intercambios de mensajes que se realizan para lograr un propósito específico

es lo que se denomina una interacción.

6.8.3. Patrón

Un patrón es una colaboración parametrizada, junto con las pautas sobre cuán-

do utilizarlo. Un parámetro se puede sustituir por diversos valores, para producir

distintas colaboraciones. Los parámetros señalan generalmente las ranuras para

las clases. El uso de un patrón se representa como una elipse de línea discontinua

conectada con cada una de las clases por una línea discontinua, que se etiqueta

con el nombre del rol.

6.9. Diagramas de Componentes

Los diagramas de componentes describen los elementos físicos del sistema y

sus relaciones. Muestran las opciones de realización incluyendo código fuente,

binario y ejecutable. Los componentes representan todos los tipos de elementos

software que entran en la fabricación de aplicaciones informáticas. Pueden ser

110


simples archivos, paquetes de Ada, bibliotecas cargadas dinámicamente, etc. Las

relaciones de dependencia se utilizan en los diagramas de componentes para indi-

car que un componente utiliza los servicios ofrecidos por otro componente.

Un diagrama de componentes representa las dependencias entre componentes

software, incluyendo componentes de código fuente, componentes del código bi-

nario, y componentes ejecutables. Un módulo de software se puede representar

como componente. Algunos componentes existen en tiempo de compilación, al-

gunos en tiempo de enlace y algunos en tiempo de ejecución, otros en varias de

éstas.

Un componente de sólo compilación es aquel que es significativo únicamente

en tiempo de compilación. Un componente ejecutable es un programa ejecutable.

Un diagrama de componentes tiene sólo una versión con descriptores, no tiene

versión con instancias. Para mostrar las instancias de los componentes se debe usar

un diagrama de despliegue.

Un diagrama de componentes muestra clasificadores de componentes, las cla-

ses definidas en ellos, y las relaciones entre ellas. Los clasificadores de compo-

nentes también se pueden anidar dentro de otros clasificadores de componentes

para mostrar relaciones de definición.

Un diagrama que contiene clasificadores de componentes y de nodo se puede

utilizar para mostrar las dependencias del compilador, que se representa como fle-

chas con líneas discontinuas (dependencias) de un componente cliente a un com-

ponente proveedor del que depende. Los tipos de dependencias son específicos

del lenguaje y se pueden representar como estereotipos de las dependencias.

El diagrama también puede usarse para mostrar interfaces y las dependencias

de llamada entre componentes, usando flechas con líneas discontinuas desde los

componentes a las interfaces de otros componentes.

El diagrama de componente hace parte de la vista física de un sistema, la

cual modela la estructura de implementación de la aplicación por sí misma, su

organización en componentes y su despliegue en nodos de ejecución. Esta vista

proporciona la oportunidad de establecer correspondecias entre las clases y los

componentes de implementación y nodos. La vista de implementación se repre-

senta con los diagramas de componentes.

111


6.9.1. Componentes

Es una parte física reemplazable de un sistema que empaqueta su implemen-

tación y es conforme a un conjunto de interfaces a las que proporciona su realiza-

ción.

Algunos componentes tienen identidad y pueden poseer entidades físicas, que

incluyen objetos en tiempo de ejecución, documentos, bases de datos, etc. Los

componentes existentes en el dominio de la implementación son unidades físicas

en los computadores que se pueden conectar con otros componentes, sustituir,

trasladar, archivar, etc.

Los componentes tienen dos características: Empaquetan el código que im-

plementa la funcionalidad de un sistema, y algunas de sus propias instancias de

objetos que contituyen el estado del sistema. Los llamados últimos componentes

de la identidad, porque sus instancias poseen identidad y estado.

Código:

Un componente contiene el código para las clases de implementación y otros

elementos. Un componente de código fuente es un paquete para el código fuente

de las clases de implementación. Al gunos lenguajes de programación distinguen

archivos de declaración de los archivos de método, pero todos son componentes.

Un componente de código binario es un paquete para el código compliado. Una

biblioteca del código binario es un componente.

Cada tipo de componente contiene el código para las clases de implementación

que realizan algunas clases e interfaces lógicas. La relación de realización asocia

un componente con las clases y las interfaces lógicas que implementan sus clases

de implementación. Las interfaces de un componente describen la funcionalidad

que aporta. Cada operación de la interfaz debe hacer referencia eventualmente a

un elemento de la implementación disponible en el componente.

La estrucutra estática, ejecutable de una implementación de un sistema se pue-

de representar como un conjunto interconectado de componentes. Las dependen-

cias entre componentes significan que los elementos de la implementación en un

componente requieren los serivios de los elementos de implemntación en otros

componentes. Tal uso requiere que dichos elementos sean de visibilidad pública.

112

6 ESTUDIO DEL DISEÑO ( UML) 6.10 Diagramas de Despliegue

Identidad:

Un componente de identidad tiene identidad y estado. Posee los objetos físicos

que están situados en él. Puede tener atributos, relaciones de composición con

los objetos poseídos, y asociaciones con otros componentes. Desde este punto de

vista es una clase. Sin embargo la totalidad de su estado debe hacer referencia a

las instancias que contiene.

Estructura:

Un componente ofrece un conjunto de elementos de implementación, esto sig-

nifica que el componente proporciona el código para los elementos. Un compo-

nente puede tener operaciones e interfaces. Un componente de identidad es un

contenedor físico para las entidades físicas como bases de datos. Para proporcio-

nar manejadores para sus elementos contenidos, puede tener atributos y asociacio-

nes salientes, que deben ser implementadas por sus elementos de implementación.

Este componente se representa con un rectángulo con dos rectángulos más peque-

ños que sobresalen en su lado izquierdo.

Las operaciones e interfaces disponibles para los objetos exteriores se pueden

representar directamente en el símbolo de clase. Estos son su comportamiento co-

mo clase. Los contenidos del subsistema se representan en un diagrama separado.

Las dependencias de un componente con otros componentes o elementos del

modelo se representan usando líneas discontinuas con la punta de flecha hacia los

elementos del proveedor. Sí un componente es la realización de una interfaz, se

representa con un círculo unido al símbolo del componente por un segmento de

línea.

6.10. Diagramas de Despliegue

Los Diagramas de Despliegue muestran la disposición física de los distintos

nodos que componen un sistema y el reparto de los componentes sobre dichos

nodos. La vista de despliegue representa la disposición de las instancias de com-

ponentes de ejecución en instacias de nodos conectados por enlaces de comunica-

ción. Un nodo es un recurso de ejecución tal como un computador, un dispositivo

113

6 ESTUDIO DEL DISEÑO ( UML) 6.11 Los paquetes

o memoria. Los estereotipos permiten precisar la naturaleza del equipo:

Dispositivos

Procesadores

Memoria

Los nodos se interconectan mediante soportes bidireccionales que pueden a su vez

estereotiparse. Esta vista permite determinar las consecuencias de la distribución y

la asignación de recursos. Las instancias de los nodos pueden contener instancias

de ejecución, como instancias de componentes y objetos. El modelo puede mostrar

dependencias entre las instancias y sus interfaces, y también modelar la migración

de entidades entre nodos u otros contenedores.

Esta vista tiene una forma de descriptor y otra de instancia. La forma de ins-

tancia muestra la localización de las instancias de los componentes específicos

en instancias específicas del nodo como parte de una configuración del sistema.

La forma de descriptor muestra qué tipo de componentes pueden subsistir en qué

tipos de nodos y qué tipo de nodos se pueden conectar, de forma similar a una

diagrama de clases, esta forma es menos común que la primera.

6.11. Los paquetes

Los paquetes son elementos para organizar elementos en grupos. Imaginemos

una aplicación con cientos de clases que se ven entre todas ellas, no hay forma

de comprender una red de relaciones tan grande y desorganizado. Es un proble-

ma real para grandes sistemas (el acceso simple y no restringido no permite el

crecimiento). Para estas situaciones se necesita algún tipo de empaquetamiento

controlado para organizar las abstracciones.

114


Anidamiento

Las abstracciones que organizan un modelo se llaman paquetes. Y los paquetes

agrupan a otros paquetes organizándolos en forma de directorios. Se recomienda

tener como límite dos o tres niveles de anidamiento. Al anidar un paquete (Menú)

dentro de otro paquete (Ventana) se indica con el nombre del paquete anidado

precedido por el nombre que lo contiene (Ventana::Menú). Por ejemplo el nombre

de camino para el paquete Menú puede ser API::Ventana::Menú

Importación

La importación de un paquete hace que se pueda acceder a los elementos de

ese paquete, pero el paquete importado no puede acceder a los elementos del otro.

En UML una relación de importación se modela como una dependencia con el

estereotipo import.

Elementos extensibilidad

Pueden añadirse valores etiquetados para añadir nuevas propiedades al paque-

te (como el autor, fecha creación, etc) y estereotipos para especificar categorías.

Estos son:

1. facade: (fachada) Es un paquete que muestra solo unos objetos de otro pa-

quete. Se usa para mostrar vistas simplificadas y diferentes que de otra for-

ma serían vistas muy complejas, reduciendo el campo de visión según las

funciones que vayan a usarse.

2. stub: Paquete tiene la función de proxy a otro paquete.

3. subsystem: Representa una parte independiente del sistema completo.

115


4. system: Representa al sistema completo.

116

7 HACKING DEL KERNEL

Parte II

Práctica

7. Hacking del kernel

7.1. Introducción

Programar en espacio del kernel ha sido siempre cosa de gurús, o al menos

eso es lo que se piensa. Muy poca gente tiene el coraje, los conocimientos y la

paciencia para trabajar con interrupciones, devices y con el siempre temido kernel

panic.

Cuando se escribe un programa en espacio de usuario, lo peor que puede pasar

es un core dump. El programa hizo algo muy malo, así que el sistema operativo

decide que el programa debe finalizar y hace un volcado de toda la memoria y la

información del estado del proceso en forma de un fichero core. Los ficheros core

pueden ser usados luego para debugar el programa y encontrar el problema que

originó el core dumped.

Pero cuando se programa dentro del kernel la cosa cambia, no hay ningún sis-

tema operativo que pueda pararte de manera controlada, y decirte luego qué era lo

que ha funcionado mal. Se supone que el kernel de Linux funciona correctamente

y no debe controlar su propio código. A veces puede sobrevivir a un kernel panic,

si lo que se ha hecho mal es relativamente benigno, este tipo de kernel panic se le

suele llamar oopses, luego lo pasaré a explicar más detalladamente. Pero, no hay

nada que pare al código de sobreescribir o acceder a localizaciones de la memoria

de cualquiera dentro del espacio de direcciones del kernel. También, puede col-

garse algún módulo, entonces el kernel se cuelga, técnicamente el thread se cuelga

pero tiene las mismas repercusiones.

Estos problemas pueden sonar un poco exagerados pero se tiene que tratar con

mucho cuidado. Además si hay un kernel panic, raramente se sabe que demonios

ha pasado, porque simplemente el sistema operativo deja de funcionar. La típica

solución es mirar aquellos printk que creemos han causado el error, y esperar

que podamos verlos al rebotar la máquina y no se hayan perdido. Y todo esto

117

7 HACKING DEL KERNEL 7.2 Uso del debugador

asumiendo que no se ha corrompido el sistema de ficheros. Porque he llegado

a perder un sistema de ficheros completo de una máquina virtual después de un

triste kernel panic, supongo que debido a una mala inicialización de un puntero

que sobreescribió algunas estructuras internas del ext2.

La primera cosa que se aprende cuando se programa en dentro del kernel es

que hay que mantener una copia de toda la programación en una máquina diferen-

te, móntalo como sea, ya sea con NFS, con ftps, o con máquinas virtuales mientras

esta no acceda directamente a una partición del ordenador donde se está trabajan-

do. Los ficheros permanecen seguros en otra máquina. Aún así no se ahorra uno

tiempo teniendo que hacer los e2fsck incluso para los sistemas ext3, después de

un kernel panic.

Así que, con todo esto no sorprende que poca gente haya entrado en la progra-

mación real del sistema operativo.

7.2. Uso del debugador

El uso de un debugador está mal visto generalmente por gente como Linus

Torvalds. Considerando lo que él mismo ha dicho en la lista de mailing del kernel

de Linux:

“ I’m afraid that I’ve seen too many people fix bugs by looking at debugger

output, and that almost inevitably leads to fixing the symptoms rather than the

underlying problems.” Linus Torvalds

Dice que se debe usar el código fuente para resolver los problemas y los bugs

del kernel. Además que resolviendo bugs mirando sólo el debugger se peca de

arreglar los sintomas en vez de resolver el problema que está tras ellos.

El uso de un debugador solamente no es suficiente, debe mirarse el código.

Pero también hay que tener en cuenta que es necesario tener mucha experiencia

programando, y resolviendo problemas que ya han visto antes. Es necesario llegar

a la raíz del problema observando el código. Pero llegar a tener esta experiencia

programando en el kernel requiere un uso inteligente del debugador.

1. Usar el debugador para recoger las evidencias alrededor del problema.

2. Estudiar el código y pensar qué está sucediendo.

118

7 HACKING DEL KERNEL 7.2 Uso del debugador

3. Intentar concentrasrse en las posibles causas de los síntomas que se ve en

el debugador. Entonces pensar las posibles causas hasta la raíz del proble-

ma. Escibir una lista de posibilidades, poniéndolas en orden de parecido

al problema y probándolas una a una. El proceso de clarificación de ideas

escribiéndolas puede ser de gran ayuda.

4. Hasta que se tenga más experiencia, se debería usar el debugador para pro-

bar algunas ideas probando valores de variables.

Por eso el debugador es una herramienta para estimular la razón, y el pensamiento

lógico para averiguar que está sucediendo en el código. No hay que resolver los

problemas para arreglar la salida del debugador. Y aquí hay una lista de las cosas

que se deben hacer y las que no:

Qué hacer:

1. Estudiar el código antes de empezar a jugar con el debugador. Se es mucho

más productivo si se tiene en mente el código, antes de empezar a debugar.

2. Usar el debugador para probar las ideas y presunciones, los bugs vienen

normalmente como resultado de presunciones incorrectas. Pues bueno hay

que hacer más intentos, que es posible que fallen, pero también es posible

que no.

3. Si las presunciones son incorrectas, hay que aprender de porqué esa presun-

ción está mal, es importante que no se repita, porque a lo mejor la próxima

vez no nos rebentará a nosotros, sino a otros, o peor aún que de un kernel

panic cuando tenemos un ordenador en producción.

4. Descartar el debugador cuanto antes mejor. Trabajar en el código.

Qué no hacer:

1. Ignorar las causas reales del problema que podamos pensar. Cuando se en-

cuentra que algo está mal, no hacer que funcione para este o ese otro caso,

para que parezca que funciona. Un ejemplo clásico es añadir otra sección a

un statement del switch para cubrir las posibilidades que no se hayan pen-

sado.

119

7 HACKING DEL KERNEL 7.3 printk

2. Resolver ciegamente un problema con el debugador. Se puede llegar a con-

clusiones erróneas y no se aprende mucho sobre el proceso.

Una vez entendido como debe usarse un debugador y como no debe usarse vamos

a ver las diferentes posibilidades que hay disponibles. Existen varias formas para

debugar:

7.3. printk

La función printk es la forma que se tiene de guardar logs del sistema y pasar-

los al syslog. printk() pasa mensajes del kernel a la consola, al dmesg y al demonio

syslog. Es útil si se esta debugando y haciendo reports de errores, y puede usarse

dentro de un contexto de una interrupción [RU1], pero debe usarse con cuida-

do: si la máquina tiene su consola saturada de mensajes printk no es útil. Usa un

formato muy parecido y casi compatible con la función printf del ANSI C, y la

concatenación de strings para dar prioridades a los argumentos:

printk( KERN_INFO “i = %u\n”, i);

Es necesario ver el fichero include/linux/kernel.h para ver otros valores del KERN_.

Estos se interpretan como el nivel para el syslog. Un caso especia para imprimir

una IP en uso es de la siguiente manera:

__u32 ipaddress;

printk(KERN_INFO “mi ip: %d. %d. %d. %d\n”, NIPQUAD(ipaddress));

printk () usa internamente un buffer de 1KB y no puede pillar overruns. Así que

hay que asegurarse que el mensaje no es mayor. Dicen los gurus que se sabe que

uno es un hacker del kernel auténtico cuando se escribe en vez de usar printf en

un programa normal se usa printk. A mi todavía no me ha pasado, todavía.

Los ocho posibles tipos de nivel que se definen en la cabecera <linux/kernel.h>

son los siguientes:

KERN_EMERG: Usado para mensajes de emergencia, normalmente cuando se

va a producir un crash del sistema.

120

7 HACKING DEL KERNEL 7.3 printk

KERN_ALERT: Una situación que requiere una acción inmediata.

KERN_CRIT: Condiciones críticas, normalmente relacionados con problemas

serios de hardware o software.

KERN_ERR: Usado para indicar errores de condiciones

KERN_WARNING: Warnings sobre situaciones problemáticas que en sí no pue-

den crear problemas serios al sistema.

KERN_NOTICE: Situacioens que son normales, pero que se quieren anotar. Las

condiciones relacionadas con la seguridad se reportan a este nivel.

KERN_INFO: Mensajes informativos. Muchos drivers muestran información

del hardware que encuentran al arrancar y la muestran en este nivel.

KERN_DEBUG: Usado para mensajes de debugaje.

Cada string representa un entero. Que van desde 0 a 7, con los valores más peque-

ños representando las prioridades más altas. [ALS].

Basándose en el nivel del log, el kernel puede que muestre los mensajes en la

consola, en un terminal modo texto o en una impresora. Si la prioridad es menor

que la variable console_loglevel, entonces los mensajes se muestran por consola.

Si ambos klogd y el syslogd están ejecutándose en el sistema, los mensajes del

kernel se añaden a /var/log/messages o donde se haya configurado con el syslogd.

Si el klogd no se está ejecutando, los mensajes no se mostrarán en el espacio de

usuario, a no ser que se lea /proc/kmsg. La variable console_loglevel se iniciali-

za a DEFAULT_CONSOLE_LOGLEVEL y puede ser modificada a través de la

llamada a sistema sys_syslog. En el kernel actual se puede hacer que todos los

mensajes se muestren por consola haciendo los siguiente desde la cuenta de root:

(bash)$ echo 8 > /proc/sys/kernel/printk

La mejor ventaja que tienen es que es fácil de usar, haces un printk y si luego

hay un kernel panic, pues se mira hasta donde ha ido. Fácil y sencillo. Además de

poder usarse siempre, incluso dentro de una interrupción.

121

7 HACKING DEL KERNEL 7.4 Oops

Pero tiene varios inconvenientes. Si por ejemplo tenemos un error puñetero,

como por ejemplo que cuando empezamos a leer de un device, por ejemplo, noso-

tros sobreescribimos toda la memoria. Los errores de sobreescritura de memoria

son muy comunes en los programas hechos en C, pero aquí nadie nos protege de

escribir en donde no debamos, porque estamos dentro del kernel mode. En este

tipo de casos muchas veces el kernel puede hacer un reboot instantaneo y no saber

qué demonios había pasado, en estos casos los printk’s que estaban a punto de es-

cribirse no lo hubiesen hecho y luego uno duda si realmente los últimos printk’s es

realmente lo último que se ha hecho. Así que es necesario usar además del printk

otros mecanismos para debugar el código y los errores.

7.4. Oops

Cuando el kernel detecta que existe una condición de anomalía seria, se dis-

para un ’oops’. Un oops tiene dos funciones principalmente:

Volcar la información de debugging interesante que podemos usar para diag-

nosticar la causa del problema.

Probar y prevenir que el kernel pierda el control y que cause corrupción en los

datos, o aún peor que se cause daño al hardware, aunque es difícil que suceda, es

posible.

Al principio, un oops parece completamente incomprensible, un montón de

líneas con valores hexdecimales y con datos que parecen crípticos.

![CDATA[

CPU: 0

EIP: 0010:<c011933c> Tainted: P

Using defaults from ksymoops -t elf32-i386 -a i386

EFLAGS: 00010002

eax: 00000ce0 ebx: 00001000 ecx: c778a510 edx: 00000610

esi: 00000002 edi: 00000000 ebp: c02165c0 esp: c6663f58

ds: 0018 es: 0018 ss: 0018

Process pcmcia (pid: 1003, stackpage=c6663000)

Stack: 00000000 c02165a0 00000000 c02165c0 c6663fc4 c01193cf

c0116340 00000000 00000001 c02165c0 fffffffe c011616a

122

7 HACKING DEL KERNEL 7.4 Oops

c0214900 00000000 c6663fbc 00000046 c010817d 00000000

Call Trace: <c01193cf><c010ac96><c0116406><c0116340><c011616a>

Code: 89 42 04 89 10 c7 41 04 00 00 00 00 c7 01 00 00 00 00 fb 53

> > EIP; c011933c <timer_bh></timer_bh>+228/27c> =====

Trace; c01193cf <do_timer></do_timer>+3f/70>

Trace; c010ac96 <timer_interrupt></timer_interrupt>+62/110>

Trace; c0116406 <bh_action></bh_action>+1a/48>

Trace; c0116340 <tasklet_hi_action></tasklet_hi_action>+40/60>

Trace; c011616a <do_softirq></do_softirq>+5a/ac>

Trace; c010817d <do_irq></do_irq>+a1/b4>

Trace; c0109f48 <call_do_irq></call_do_irq>+5/d>

Code; c011933c <timer_bh></timer_bh>+228/27c>

00000000 <_eip>:

Code; c011933c <timer_bh></timer_bh>+228/27c> ====

0: 89 42 04 mov %eax,0x4(%edx) ====

Code; c011933f <timer_bh></timer_bh>+22b/27c>

3: 89 10 mov %edx,(%eax)

Code; c0119341 <timer_bh></timer_bh>+22d/27c>

5: c7 41 04 00 00 00 00 movl $0x0,0x4(%ecx)

Code; c0119348 <timer_bh></timer_bh>+234/27c>

c: c7 01 00 00 00 00 movl $0x0,(%ecx)

Code; c011934e <timer_bh></timer_bh>+23a/27c>

12: fb sti

Code; c011934f <timer_bh></timer_bh>+23b/27c>

13: 53 push %ebx

0>Kernel panic: Aiee, killing interrupt handler!

3 warnings issued. Results may not be reliable.

]]>

</_eip></c0109f48></c010817d></c011616a></c0116340>

La anatomía de un oops es muy de bajo nivel, además cada imagen del kernel

tienen un oops específico. Por eso, se necesita hacer un post proceso para obtener

información de donde empezar a hacer el proceso de debugaje. La idea es compilar

123

7 HACKING DEL KERNEL 7.5 Máquinas virtuales

en ensamblador allá donde creemos que está dando el error, y mirar las últimas

operaciones para saber donde nos ha dejado colgado el kernel. Esta es la única

manera de saber qué le ha pasado a un kernel que ha dado un kernel panic y ha

dejado de funcionar. Los inconvenientes son varios, para empezar es muy difícil

de entender el volcado (aunque cuando es la única ayuda disponible esta es muy

valiosa) y otro inconveniente es que hay que compilar el kernel con la opción oops

y está ocupa espacio dentro del kernel, que a pesar de ser pequeño es importante

en proporción al resto de kernel.

7.5. Máquinas virtuales

Cuando habían los mainframes, y la misma máquina se compartía entre va-

rios sistemas nació la idea de máquinas virtuales. Una máquina virtual es una

encapsulación de un ordenador a tu entera disposición. Un programa dentro de

una máquina virtual no tiene acceso real al hardware físico. Todo el acceso al

hardware se controla mediante la máquina virtual, que emula al ordenador. Es una

interfaz entre el programa y la máquina real.

La idea es tener un ordenador con un sistema operativo sobre el que se tra-

baja, donde se edita y se compila el código. Tener bajo este sistema operativo

un programa que sea una máquina virtual, y sobre este programa que emula un

ordenador hacer correr el sistema operativo que está bajo desarrollo. Así de esta

manera cuando el sistema sobre el que estamos trabajando se cuelga, o da un ker-

nel panic, o sobreescribe datos del disco, solo le afecta a la máquina virtual. Y así

mientras se reinicia el sistema se puede seguir trabajando con la misma sesión. Al

ordenador físico no le pasa nada.

Existen dos posibilidades, de máquinas virtuales: una que es la VMware (Vir-

tual Machine ware) y otra de libre distribución llamada UML (User Mode Linux).

VMware es muy potente, permite emular cualquier sistema operativo basado

en x86, bajo Windows NT, Windows 2000, Windows XP o Linux. Y puede correr

bajo máquinas x86 y sobre ordenadores basados en chips de Motorola como los

Macintosh. La versión para Linux que se puede bajar por Internet cuesta 299$ US.

124

7 HACKING DEL KERNEL 7.6 Debugando con dos máquinas

VMware emula una máquina x68, con alguna característica, por ejemplo la

interfaz del disco duro es un scsi, la targeta de red es una AMD, etc.. A la hora

de recompilar el kernel es necesario activar el soporte para targetas de red AMD

PCnet32 PCI. Y activar el soporte SCSI igual que el soporte para discos SCSI.

UML es la segunda opción, es gratuito, pero tiene un inconveniente y es que no

es una máquina virtual completa. No emula diferentes tipos de hardware, tampoco

te da la posibilidad de ejecutar ostro sistema operativo. Pero permite ejecutar un

kernel en el espacio de usuario, y eso representa varios beneficios cuando se trata

de desarrollo: los ficheros del host están protegidos, el sistema de ficheros virtual

se puede descargar, se pueden ejecutar varias máquinas en una sola, y lo mejor

es que es muy fácil usar el degubador para el kernel. No se necesita comprar

más hardware para hacer los tests, al menos que se esté programando un device

específico.

Ejecutar el UML es fácil, hay que bajar los binarios y luego, o bien instalar un

nuevo sistema o bien bajarse uno que ya esté prehecho de la página web. A pesar

de algunos inconvenientes del sistema UML, tiene una ventaja muy buena a la

hora de programar algún sistema de ficheros, pues el resultado de las operaciones

pueden destrozar el sistema de ficheros. Cuando se trabaja con UML si hay un

kernel panic del sistema de ficheros, lo único que hay que hacer es borrar un

fichero .cow (ficheros Copy On Write), y en caso de estar corrupto el sistema de

ficheros, este se restaura a la versión original, así que ya no hay que hacer los

fsck’s.

7.6. Debugando con dos máquinas

Esta solucón pasa por tener dos máquinas en una se desarrolla el software

y en la otra se ejectua el kernel de desarrollo. Debe ser capaz de ejecutarse el

debugador en la máquina de desarrollo y tener un terminal de consola abierto al

segundo ordenador. Hay que montar dos máquinas, máquina de trabajo y la otra

máquina te testeo, donde se ejecutarán los kernels en desarrollo.

125


Hardware

La primera máquina tiene el sistema operativo de desarrollo con una tarjeta et-

hernet. La segunda máquina, no necesita monitor, dependiendo de lo antiguo que

sea el ordenador (depende de la BIOS) necesitará un teclado para arrancar, aunque

es muy recomendable, al menos para hacerle un Ctr-Alt-Supr y otras operaciones

en el caso de no poder acceder remotamente. También necesita una Ethernet, aun-

que lo mejor es tener dos Ethernets en esta máquina y así poder pasar paquetes

a través de ella. Construir dos cables serial, uno servirá para ejecutar el gdb (el

debugger) y el otro para dar acceso a una consola así puede controlarse remota-

mente. Los cables serial necesitan tener esta disposición:

Solder-side pins:

\-----------------------/

\ 1 2 3 4 5 /

\ 6 7 8 9 /

\-----------------/

Wiring: (use 7 or 10 wire foil screened cable)

1

|

6---------------4

2---------------3

3---------------2

4---------------6

|

1

5---------------5

7---------------8

8---------------7

Necesitan estar conectados cada uno entre los puertos serie respectivos de cada

uno de los ordenadores. com1 al com1 y com2 al com2.

126


Software

Instalar ssh en apollo, instalar sshd en la segunda máquina que es el servi-

dor para conexiones del tipo ssh (Sercure SHell), con este servidor no solo se

pueden hacer conexiones de consola con una shell también se puede hacer trans-

ferencias de ficheros mediante conexiones seguras a modo de ftp. Que servirán

para traspasar ficheros. Configurar el sistema de tal modo que haya acceso a la

segunda máquina desde la primera. Dar permisos de lectura/escritura a /dev/ttys0

y a /dev/ttyS1que corresponden a los puertos serie. Instalar minicom en ambas

máquinas, es un programa para hacer telecomunicaciones entre sistemas UNIX y

puede encontrarse en http://www.netsonic.fi/~walker/minicom.html.

Para la preparación del kernel se tardará más tiempo. Es necesario bajarse

el kernel 2.4.18 y descomprimirlo en la máquina apollo. No se debe instalar el

último kernel el 2.4.19 porque se necesita un parche para ejecutar el kgdb y este

solo esta disponible para 2.4.18 y anteriores. Bajarse el parche antes comentado

en http://kgdb.sourceforge.net/. Aplicarle el parche desde el bash de la siguiente

manera:

cat kgdb\_2.2.18.diff |patch -p2

Entonces compilar el kernel de manera que como se ha hecho siempre, pero en el

menú hay que añadir a la configuración usual dos nuevas opciones:

* support for console on serial port under character devices

* kernel support for gdb (new) under kernel hacking.

Y es recomendable compilar todas las opciones directamente al kernel en vez de

usar los módulos, así cuando pasemos los ficheros habrá que pasar solo la imagen

del kernel.

Tras esto hacer un ’make dep bzImage’ como de una compilación del kernel

normal y corriente. Copiar la imagen a la segunda máquina, también se puede

usar un FTP, pero no es necesario si se dispone del sshd, solo hay que escribir la

siguiente orden:

scp arch/i386/boot/bzImage segunda:bzimage-2.2.18-kgdb

127


Entrar en la segunda máquina, y desde la cuenta de root, copiar la imagen del

kernel al directorio /boot y añadir las siguientes líneas en la configuración del lilo,

para crear una nueva entrada con el nuevo kernel.

image=/boot/bzImage-2.2.18-kgdb

label=kgdb

root=/dev/hda1

read-only

append=" gdb gdbttys=0 console=ttys1"

serial = 0,9600n8

La última línea nos dice que podemos controlar las opciones del lilo cuando se

arranca el ordenador desde la misma consola conectada al serial com2, se puede

usar el gdb (el debugador) por /dev/ttyS0 y además se usa la /dev/ttyS1 para usarlo

como una consola. De esta manera se pontrola todo el proceso de debugaje y con

la consola se puede acceder remotamente, con los cables por los puertos serie. Es

muy importante ejecutar lilo cuando se haya terminado de editar este fichero, en

el supuesto que pasara leer en la sección de compilar el kernel la solución.

En la máquina de desarrollo hay que crear un fichero llamado .gdbinit en el di-

rectorio raíz del código fuente del kernel, este fichero debe contener las siguientes

líneas:

define rmt

set remotebaud 38400

target remote /dev/ttyS0

end

Ejecutar en esta máquina como root la siguiente orden:

minicom -s

Y en este programa se dispone de un menú donde hay que configurar las opciones

del puerto de serie.

128


Serial Device : /dev/ttyS1

Lockfile Location : /var/lock

Callin Program :

Callout Program :

Bps/Par/Bits : 9600 8N1

Hardware Flow Control : No

Software Flow Control : No

Luego guardarlo en la opción ’Save setup as dfl’ y tras guardar la configuración

como defecto salir. Así dejar luego al minicom esperando una sesión.

Rebotar la segunda máquina y entonces aparecerá en la primera por la salida

del minicom las siguientes líneas:

Linux version 2.2.18serialgdb

Detected 167046 kHz processor.

Console: colour VGA+ 80x25

Calibrating delay loop... 333.41 BogoMIPS

Memory: 63556k/65536k available (704k kernel code, 408k reserved, 824k data, 44k init)

Dentry hash table entries: 8192 (order 4, 64k)

Buffer cache hash table entries: 65536 (order 6, 256k)

Page cache hash table entries: 16384 (order 4, 64k)

CPU: Intel Pentium 75 - 200 stepping 0c

Checking 386/387 coupling... OK, FPU using exception 16 error reporting.

Checking ’hlt’ instruction... OK.

Intel Pentium with F0 0F bug - workaround enabled.

POSIX conformance testing by UNIFIX

Trying to free free IRQ4

Waitng for connection from remote gdb on ttyS0

Entonces sabremos que la configuración a dado resultado.

En la primera máquina tenemos que arrancar el debugger apretando gdb vm-

linux>(en la raíz del directorio del código fuente) y entonces arrancará el gdb y

mostrará una información sobre el programa y aparecerá una línea de comandos.

Hay que escribir rmt y entonces leerá el fichero .gdbinit, se conectará al puerto

serie y debe mostrar las lineas siguientes:

129


(gdb) rmt

0xc010da29 in breakpoint () at gdb.c:701

701 if (initialized) BREAKPOINT();

(gdb)

Se puede continuar y pasar por los breackpoints con el comando de continuar del

gdb que es el ’c’. De esta manera se puede debugar el kernel y saber en todo

momento qué es lo que hace y allá donde nos da problemas poder averiguar y

probar posibles soluciones.

130

8 DISEÑO DE LA APLICACIÓN

8. Diseño de la aplicación

8.1. Esquemas UML

Debido a que dentro del kernel de Linux no se puede compilar en C++ no

existen objetos ni tampoco clases. Esto hace que dos de los diagramas más im-

portantes del UML no puedan crearse. Aún así UML es suficientemente versátil

como para poder definir un proyecto sin usar estos dos diagramas. Para entender

un proyecto debemos disponer al menos de un diagrama estructural, para tener

una vista el diseño de la estructura, y otro diagrama dinámico, para tener una vista

del funcionamiento.

Los siguientes puntos detallan los diferentes diagramas del proyecto: un dia-

grama de casos de uso, dos diagramas de actividades y otro diagrama de secuencia.

8.1.1. Casos de uso

Casos de Uso es una técnica para capturar información de cómo un sistema o

negocio trabaja, o de cómo se desea que trabaje. En el diagrama casos de uso se

representa las operaciones que el Administrador puede hacer con el firewall.

Casos de Uso

Firewall

Cargarpolíticas

Leerlogs

Verestadis.

Administrador

Las cargas de políticas se producen cuando el administrador desea modificar

131

8 DISEÑO DE LA APLICACIÓN 8.1 Esquemas UML

las políticas y tras cambiar el fichero de configuración se dispone a cambiar las po-

líticas. Devuelve un mensaje de error indicando si el fichero está incorrectamente

tipificado, o bien un mensaje mostrando la correcta carga de los nuevos datos. El

objetivo es cambiar las políticas que están guardadas dentro de las estructuras de

datos del firewall.

Leer los logs se produce siempre que el administrador desea comprobar los

intentos de ataques que el firewall haya bloqueado para ver si se ha estado in-

tentando un ataque desde alguna ip remota. El valor que devuelve es una lista

con todos los logs. El objetivo es mantener unos registros del funcionamiento del

firewall.

Ver las estadísticas se usa cuando el administrador desea comprobar el funcio-

namiento actual del firewall, así como la suma total de las operaciones que haya

ejecutado. Devuelve la suma de todos los paquetes que se hayan chequeado, como

los bloqueados. El objetivo es poder ver unas estadísitcas del firewall resumidas y

actualizadas en todo momento.

La cronología de los casos de usos tiene sentido de la siguiente manera: cargar

las políticas al principio, comprobar que funciona con la vista de las estadísticas

y cada cierto tiempo comprobar el estado de la máquina viendo los ficheros log.

8.1.2. Diagramas de actividades

Un estado de actividad representa una actividad: un paso en el flujo de tra-

bajo o la ejecución de una operación. Se usan para entender el comportamiento

de una parte del programa. Muestran una vista dinámica del funcionamiento del

programa.

El primer diagrama muestra como se cargan las políticas dentro de las estruc-

turas internas del firewall.

132


Introducir políticas

Parsearpolíticas

incorrecto

correcto

Mostrarerrores

Introducirpolíticas

CUIDADO!Semáforo de escritura

Mostrarresultados

Este esquema representa el proceso de cargado de políticas, lo primero que

se realiza es un parseado del fichero, comprobando que las reglas estén semánti-

camente bien escritas. Genera los datos de acuerdo con lo leido en el fichero. Si

todo este proceso fuese correcto entonces se introducen las políticas de seguridad

dentro del firewall, habiendo activado el semáforo de escritura previamente. En

el caso que el proceso diera errores se mostrarían los resultados sin modificar en

ningún momento la estructura interna del firewall.

En el segundo diagrama de actividades se muestra como funciona el filtro de

un paquete, guardado en un sk_buff.

133


Filtrar sk_buff

Filtrado de un sk_buff

log printk delos datos

CUIDADO!Semáforo de lectura

Retornarsk_buff

otra búsqueda

Es estapolítica?

Encontrada

Hay quehacer log?

bloquear

pasar

liberarsk_buff

Pasa elfiltro?

Para cada estructura sk_buff que entra dentro del filtro se busca si hay alguna

política que pertenezca al sk_buff. El orden de las políticas es importante ya que la

primera política que de éxito se pasará a la siguiente fase. Si la política específica

muestra que hay que hacer log se guarda mediante el printk los datos del sk_buff

y el resultado de la operación de filtrado. El syslog ya se encargará de marcar la

fecha y de su escritura en los ficheros de log del sistema. Después de ello se mira

si hay que eliminar el paquete, en ese caso se libera el sk_buff, y si no es así se

134


continúa retorna del filtrado y se continua por donde estaba trabajando el sistema

operativo.

8.1.3. Diagrama de secuencia

El diagrama de secuencia muestra la relación que tienen los distintos com-

ponentes del sistema a lo largo del tiempo. El tiempo transcurre de arriba abajo.

En este caso se muestra el diagrama de secuencia del proceso de filtrado de un

paquete.

KernelFirewall

filtrar()

sk_buffdev

ActivarSemáforoLectura

recurrenciapolíticas

DesactivarSemáforoLectura

resultado

retornar

Si bloquear kfree_skb(skb)

Se observa como interactúan el firewall y el kernel a la hora de filtrar un

sk_buff. Al hacer la llamada desde cualquier hook y pedirle al firewall si pasa

el filtro o no, este activa el semáforo de lectura mediante las funciones que ofrece

el kernel. Busca la política dentro de las estructuras de datos que tiene el firewall,

y tras encontrarla le pide al kernel que libere el semáforo de lectura. Retorna el

135

8 DISEÑO DE LA APLICACIÓN 8.2 Exclusión mutua

firewall el resultado del filtro y si se debe bloquear pues se pide al kernel que li-

bere el búffer correspondiente a ese paquete. Sino se continúa como si no hubiera

pasado nada.

8.2. Exclusión mutua

Antes de explicar donde tratar los paquetes y como tratarlos, es importante

hacer un repaso a la teoría de exclusión mutua, ya que antes de acceder a cualquier

estructura de datos dentro del kernel hay que averiguar si debe controlarse con

semáforos.

8.2.1. La importancia de los semáforos

A la hora de hablar del kernel si se accede a cualquier tipo de estructura de

datos desde dos sitios se tiene muy probablemente un bug, porque no se asegura la

cosistencia de los datos dentro del kernel. Y como me pasó a mí, si no se protegen

las estructuras con semáforos, el kernel hace un kernel panic y deja de funcionar

a la mínima. Al principio como uno no está acostumbrado a trabajar dentro de un

sistema operativo se le hace raro que se acceda a una estructura de datos desde

dos sitios diferentes y que de la casualidad que al mismo momento que se accede

a esas direcciones por una parte y que por otra parte se haga alguna operación no

válida y que como resultado pare el sistema. Se hace difícil que se cumplan dichas

condiciones, pero no es así, y por lo tanto hay que asegurarse de cumplir la teoría

siempre que se tengan datos compartidos.

8.2.2. Locks de lectura

Tenemos varios procedimientos de proteger los datos deshabilitando las IRQ.

En el fichero include/linux/brlock.h se definen las diferentes posibilidades. Lo que

hacen es hacer un #define que aunque no está recomendado simplifica mucho el

trabajo. En el caso de la protección a los datos de sk_buff tenemos que usar la fun-

ción br_read_lock_bh(BR_NETPROTO_LOCK) para activar el semáforo y entrar

en la zona de exclusión mutua que el código se debe proteger mediante semáforos.

Y el br_read_unlock_bh(BR_NETPROTO_LOCK) para salir de la zona crítica. La

136


definición es la siguiente:

#define br_read_lock_bh(idx) \

do { local_bh_disable(); br_read_lock(idx); } while (0)

...

...

#define br_read_unlock_bh(idx) \

do { br_read_unlock(idx); local_bh_enable(); } while (0)

Como puede verse, para entrar dentro de la zona protegida se desactiva primero

los bh (botton halves) que es el mecanismo que se hacía en los anteriores kernels

para proteger zonas de exclusión mutua. El principal inconveniente es que solo

funciona para una sola CPU y por eso se usa ahora softirq’s pero lo cierto es

que cuando se llega al proceso de tratar los paquetes, estos solo se tratan en una

CPU así que nos sirve perfectamente este mecanismo. Y entonces se activa el

lock sobre la variable BR_NETPROTO_LOCK. Como puede verse en el fichero

include/linux/brlock.h solo existe dos tipos de locks para este semáforo, uno son

los BR_NETPROTO_LOCK y otro son BR_GLOBALIRQ_LOCK.

El modo de uso es parecido a esto:

br_read_lock_bh(BR_NETPROTO_LOCK);

..

-Región Crítica-

Acceso solo lectura

..

br_read_unlock_bh(BR_NETPROTO_LOCK);

El mecanismo que nos ofrece es vastante complejo, ya que en si se usa una arqui-

tectura i386, ia64 o una x86_64 se pueden usar operaciones atómicas, y para el

resto de casos no se usan los locks atómicos.

Estos semáforos son solo para proteger los datos para lectura, cuando se desee

hacer una escritura a los datos se debe usar los semáforos para protegerlos de las

escrituras. Porque cuando se protege para lectura pueden acceder muchos meca-

nismo, pero cuando se accede para escritura solo puede entrar uno, en esos casos

se usan los locks de escritura.

137


8.2.3. Locks de escritura

Como he comentado los locks anteriores protegen los datos para que no se

pueda hacer escritura sobre ellos, pero permite que otros procesos entren en la

región crítica para hacer lecturas. Entonces para proteger los datos en las escrituras

hay que usar otros semáforos. Cada vez que se quiera hacer una escritura a los

datos, como por ejemplo cuando se guarda las políticas del firewall dentro de la

estructura, se debe usar estas funciones:

#define br_write_lock_bh(idx) \

do { local_bh_disable(); br_write_lock(idx); } while (0)

...

...

#define br_write_unlock_bh(idx) \

do { br_write_unlock(idx); local_bh_enable(); } while (0)

La primera función protege la región crítica de ser escrita y también de que no

se lea. Tiene un control total de los datos. Y la segunda operación desprotege la

región crítica y permite el acceso a los datos para el siguiente proceso. Como es

lógico no se puede poner una de estas funciones sin la otra, una activa el semáforo

y el otro lo desactiva. Y es muy importante que el uso de este proceso sea mínimo

para no afectar al sistema haciendo que vaya más lento, y cuando se tenga que

usar las operaciones que contenga tienen que ser pocas y rápidas.

Así por ejemplo cuando se tenga que eliminar las políticas, lo que se llama

hacerle un flush de los datos, se debería de programar algo parecido a esto:

br_write_lock_bh(BR_NETPROTO_LOCK);

..

-Región Crítica-

Acceso escritura

..

br_write_unlock_bh(BR_NETPROTO_LOCK);

Y dentro de la región crítica se puede escribir a los datos porque nadie más accede

a ellos. Hay un ejemplo de este mecanismo, se encuentra en net/core/dev.c y se usa

138

8 DISEÑO DE LA APLICACIÓN 8.3 Filtrado de paquetes

para hacer una llamada a una función y hacer que esta sea atómica con respecto a

las capas de protocolos.

void net_call_rx_atomic(void (*fn)(void))

{

br_write_lock_bh(BR_NETPROTO_LOCK);

fn();

br_write_unlock_bh(BR_NETPROTO_LOCK);

}

Se pasa un puntero de una función por parámetros, se activa el semáforo para la

protección de escritura, se llama a la función y luego cuando esta termine se de-

sactiva el semáforo que asegura la exclusión mutua. Esta función se llama dentro

de los drivers y hace que la función que se le pasa como parámetro sea atómica. Es

un mecanismo que ofrece el kernel para los desarrolladores de drivers. Y se debe

reusar este código, porque los desarrolladores del kernel ya se han asegurado que

sea portable dentro de cada una de las distintas arquitecturas. Y dependiendo de

la arquitectura para donde se compila el kernel , hace unas funciones u otras. En

cambio si tuviese que montarme los semáforos, serían poco portables.

8.3. Filtrado de paquetes

El objetivo es poder insertar políticas de seguridad donde se pueda distinguir

para cada paquete si entra o si sale, la interfaz y la información de la cabecera

IP. La solución planteada es poner solamente cuatro hooks: uno en la entrada a la

interfaz de entrada, otro a la salida de la interfaz de entrada, otro a la entrada de la

interfaz de salida y el último a la salida de la interfaz de salida. Cada uno de ellos

captura el sk_buff y se indica qué hook al hacer la llamada mediante las cons-

tantes MW_INPUTINT_IN, MW_INPUTINT_OUT, MW_OUTPUTINT_IN y

MW_OUTPUTINT_OUT, se puede leer de la siguiente manera: MY como una

cosntante de la aplicación MyWall, INPUTINT o bien OUTPUTINT según sea la

interfaz de entrada o la interfaz de salida, y el IN o bien el OUT indica si es de

entrada o salida respecto esa interfaz. La información de la interfaz está dentro

de la estructura sk_buff, en el apartado dev, que indica de qué interfaz se trata.

139


Que conjuntamente con la cabecera ip nos indica toda la información necesaria

para filtrar, a la cabecera IP se puede acceder mediante iphdr dentro de sk_buff (la

estructura sk_buff se encuentra detallada en el Anexo A).

8.3.1. ip_input.c

El hook de entrada el filtro tiene que estar situada allá donde todos los paquetes

pasen por ella al entrar en el sistema operativo, entonces el mejor lugar es justo

después de hacer los chequeos a la cabecera IP, allí se inserta la función que llama

al filtro. Si el resultado de la búsqueda es eliminar el paquete entonces se elimina

y sino pues se deja estar y contina el camino del skbuff.

El primer sitio donde poner el filtro es en el fichero net/ipv4/ip_input.c justo

donde se termine la función ip_rcv:

/*

* Main IP Receive routine.

*/

int ip_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt)

{

...

...

iph = skb->nh.iph;

if (ip_fast_csum((u8 *)iph, iph->ihl) != 0)

goto inhdr_error;

{

__u32 len = ntohs(iph->tot_len);

if (skb->len < len || len < (iph->ihl<<2))

goto inhdr_error;

if (skb->len > len) {

__pskb_trim(skb, len);

if (skb->ip_summed == CHECKSUM_HW)

skb->ip_summed = CHECKSUM_NONE;

}

140


}

#ifdef CONFIG_MYWALL

// Filtro de entrada

// MW_INPUTINT_IN

...

#endif

Las órdenes de #ifdef y de #endif se usan para proteger el resto del código, en caso

de compilar el kernel sin las opcciones de mi filtro (llamado mywall) el compila-

dor extraería las líneas de código que hay entre las definiciones. Pero si alguien

desea incluir este firewall dentro de su kernel, entonces incluye los ficheros de

CONFIG_MYWALL y el compilador deja el código tal cual, apareciendo las fun-

ciones que estén incluidas dentro de la definición.

8.3.2. ip_forward.c

Aquí se disponen dos hooks, el primero se situa para la salida del paquete de la

interfaz de entrada al ordenador y el segundo se dispone para la entrada del paque-

te a la interfaz de salida. Que corresponden a las constantes MW_INTPUTINT_OUT

y para MY_OUTPUTINT_IN. Están situados en el fichero net/ipv4/ip_forward.c,

en la función ip_forward(skb). El primero antes de decidir el destino del paquete,

y el segundo hook antes de redirigirlo a la segunda interfaz.

int ip_forward(struct sk_buff *skb)

{

struct net_device *dev2; /* Output device */

struct iphdr *iph; /* Our header */

struct rtable *rt; /* Route we use */

...


// Filtro MW_INPUTINT_OUT

...

#endif

iph = skb->nh.iph;

141


rt = (struct rtable*)skb->dst;

...


// Filtro MW_OUTPUTINT_IN

...

#endif

return ip_forward_finish(skb);

En la segunda llamada al filtro se le debe pasar el nuevo device (interfaz) calcu-

lado por la tabla de routing. Antes de pasar el segundo hook debe calcularse el

TTL, operación que realiza el sistema operativo, si el TTL es menor que cero se

devuelve un ICMP indicando que el tiempo de vida del paquete ha expirado.

8.3.3. ip_output.c

Para el caso del filtro de salida el fichero donde se implementa es el net/ipv4/ip_output.c

y se debe introducir justo antes de que el mensaje sea enviado a la cola de mensa-

jes. Esta función es la ip_build_and_send_pkt:

int ip_build_and_send_pkt(struct sk_buff *skb,

struct sock *sk, u32 saddr,

u32 daddr, struct ip_options *opt)

{

...

ip_send_check(iph);


// Filtro de salida

// MW_OUTPUTINT_OUT

...

#endif

/* Send it out. */

return output_maybe_reroute(skb);

}

142


Cuando se envie el puntero del skbuff al filtro se marcará como que se ha captu-

rado saliendo, así se consigue la información que se desea.

8.3.4. El sk_buff

El sk_buff es una estructra de datos donde los sistemas UNIX guardan los

datos [WS2], es la forma que tienen de encapsular la información, se usa para

describir el movimiento de los datos de red entre las capas de los protocolos. La

definición de la estructura de datos es muy importante, es la representación de

todos los datos, y siempre que se quiera acceder o realizar alguna operación a los

datos de red se debe hacer a través de esta estructura. La definición se encuentra

en include/linux/skbuff.h y la implementación de las funciones se encuentra en

net/core/skbuff.c. La estructura de datos del sk_buff se puede encontrar en el anexo

A.

Paso a describir unas cuantas funciones disponibles para tratar los sk_buff.

alloc_skb: Crea espacio para un nuevo network buffer, donde se le pasa el tamaño

y la máscara. Y retorna un puntero al nuevo buffer.

struct sk_buff *alloc_skb(unsigned int size,int gfp_mask)

kfree_skbmem: Libera un skbuff pero no quita el estado de este.

void kfree_skbmem(struct sk_buff *skb)

kfree_skb: Libera un sk_buff y libera cualquier dato adjunto al buffer. Este sí que

borra el estado del buffer.

void kfree_skb(struct sk_buff *skb)

skb_copy_bits: Vuelca algunos datos del skb a un buffer del kernel. Se indica el

offset, un puntero a donde copiar los datos y cuántos datos copiar.

int skb_copy_bits(const struct sk_buff *skb, int offset, void *to, int len)

143


8.3.5. Operaciones

Sabemos como recoger una estructura sk_buff, sabemos dónde hacerlo y como

podemos modificar los dato o acceder a ellos. Ahora falta explicar qué se hace con

dicha estructura. Como se ha planteado un sistema de solo dos hooks había dos

lugares donde podía suceder o bien que no cumpliese con las normas de seguridad

o bien que sí las cumpliese.

Cuando tenemos un paquete que está entrando y se captura en ip_input.c

en la función iprcv( ) el buffer debe ser destruido con la función kfree_skb( )

o bien debe pasarse el buffer a la función ip_rcv_finish( ) que se encuentra en

net/ipv4/ip_input.c:

static inline int ip_rcv_finish(struct skbuff * skb)


En el caso de eliminarse debe ser porque en la lista de políticas concordaba algún

drop. En el segundo caso es porque habría llegado a un pass.

Cuando el paquete está saliendo del sistema y se ha capturado en ip_output.c

dentro de la función ip_fragment( ) el paquete debe ser eliminado usando la fun-

ción kfree_skb( ) si no pasa las políticas de seguridad o bien debe enviarse a la pila

de salida mediante la función IP_INC_STATS( )


144

9 IMPLEMENTACIÓN DEL FIREWALL

9. Implementación del firewall

En este capítulo se narra los resultados conseguidos después del desarrollo,

como los problemas y las experiencias más importantes tanto a la hora de debugar

como a la hora de tratar con los semáforos. Después se explica como montar

un escenario para poder probar el firewall y por último los resultados de dicho

escenario.

9.1. Desarrollo

El desarrollo de las aplicaciones dentro del kernel como ya se ha comentado es

tedioso, laborioso y un proceso largo. Este es el resultado del proceso de trabajo.

9.1.1. Debugar

Todas las formas de debugar que he mostrado son muy útiles, pero hay es-

cenarios que son más dificiles de probar. Por ejemplo, tenía que probar como el

firewall bloquea paquetes, no solo que le llegan a él y los bloquea cuando debe,

sino que además tiene que enviarlos a otras interfaces correctamente cuando no

debe bloquearlos. El proceso es el siguiente: nada más entrar el paquete tiene que

pasar, las políticas del firewall, después ir al servicio routed, que es el demonio

encargado de dirigir los paquetes a la interfaz adecuada según su dirección ip des-

tino. Tras pasar por este servicio los paquetes deben pasar otra vez por el firewall

y sus políticas.

No es factible trabajar con un kernel inestable y a la vez usar el mismo para

guardar los cambios. Es necesario trabajar como mínimo con una máquina vir-

tual, ya sea con VMware o con UML. Pero no es posible probar como pasan los

paquetes por el servicio routed y salen otra vez por otra interfaz en una máquina

virtual. Porque la máquina virtual solo dispone de una interfaz ethernet, y no se

puede hacer un forward por no tiene sentido un paquete que entra y vuelve a salir

por la misma interfaz.

La solución a la que se llega es configurar otro ordenador y probar el kernel

en el otro ordenador, se edita el kernel en un ordenador y se hace las pruebas en el

otro, pero aparece otro problema: el ordenador que tenemos haciendo las pruebas

145

9 IMPLEMENTACIÓN DEL FIREWALL 9.1 Desarrollo

se conecta mediante la ethernet al primer ordenador, y precisamente esa parte del

kernel la que se está modificando y la que es más inestable, así que no tenemos

ninguna garantía que llegue correctamente el paquete aunque solo sea para entrar

en la consola y ver como está trabajando el kernel recién compilado. Por lo que

hay que conectar las dos máquinas como se ha explicado en el capítulo de hacking

el kernel, en el apartado de debugando con dos máquinas.

Desarrollo

Pruebas

NIC 1 NIC 2NIC

Cable serie

Cable Ethernet

Debugador + Consola

Paquetes IP

Firewall

RouterSalida

9.1.2. Semáforos

Cuando se trata los paquetes por el sistema operativo dentro del net/ipv4/ip_input.c,

y tras pasar los chequeos simples sobre la cabecera para comprovar la integridad

de los datos y otros chequeos, se recoge el paquete por el filtro y se pasa las políti-

cas. Al llamar a la función para recoger la estructura sk_buff, al principio de todo

lo que hice fue que me mostrará la información de cabecera IP del paquete que me

acaban de pasar. Algo sencillo, simplemente pasar por el printk la IP origen, la IP

destino y alguna información más de poca importancia. La cuestión era averiguar

si capturaba todos los paquetes, como trabajar con las estructuras sk_buff y enton-

ces empezar a implementar las listas y las comparaciones que había diseñado con

el UML. Este era el código que pretendía implementar dentro de mi función:

// Imprime la info del sk_buff:

// N. de protocolo;

// IP origen : puerto origen;

// IP destino : puerto destino;

// tamaño total; Tipo de Servicio

// id; fragment offset; time to live

146

9 IMPLEMENTACIÓN DEL FIREWALL 9.1 Desarrollo

// y que muestre los datos del sk_buff

printk("PROTO=%d %u. %u. %u. %u: %hu %u. %u. %u. %u: %hu"

" L= %hu S=0x %2.2hX I= %hu F=0x %4.4hX T= %hu",

ip->protocol, NIPQUAD(ip->saddr),

src_port, NIPQUAD(ip->daddr),

dst_port,

ntohs(ip->tot_len), ip->tos, ntohs(ip->id),

ntohs(ip->frag_off), ip->ttl);

for (opti = 0; opti < (ip->ihl - sizeof(struct iphdr) / 4); opti++)

printk(" O=0x %8.8X", *opt++);

printk("\n");

Llegados a este caso me dispuse a compilar el kernel, lo cargue en la máquina

virtual y la arranqué con el nuevo kernel recién compilado. Cual fue mi sorpresa

que nada más intentar hacer un login como cualquier usuario el ordenador me daba

un kernel panic y tenia que reiniciar la máquina. Era extraño porque se colgaba

solo cuando hacia el login dentro de una consola. Si ni siquiera pasa por la tarjeta,

no son datos que se reciban por ip. O al menos esa es una idea que puede pensarse

erroneamente. Entonces decidí pasar a intentar entrar remotamente mediante una

sesión Telnet o bien mediante una sesión SSH, cual fue mi sorpresa que nada mas

conectarse el ordenador me mostraba por la pantalla de consola un kernel panic. Y

claro a cada kernel panic que hacía pues tenía que reiniciar la máquina virtual otra

vez, luego hacía un chequeo del sistema de ficheros para comprobar que estaba

correcto, tardaba mucho tiempo y no hacía nada.

Por qué me daba aquel kernel panic si lo único que estaba haciendo era mos-

trar por pantalla y por el sistema de ficheros de log unos simples mensajes, algo

que por separado había funcionado perfectamente. Entonces había que instalar el

debuggador, hacerle un trace por el kernel y averiguar qué demonios le estaba pa-

sando. No voy a explicar como debugué el kernel, pues hay un capítulo entero que

habla de ello. Pero lo que averigüé era que estaba dando errores cada vez que ac-

cedia a los datos del sk_buff que le estaba pasando. No había protegido el acceso

a los datos con ningún spinlock! grave error que me había supuesto una semana

entera de trabajo!

147

9 IMPLEMENTACIÓN DEL FIREWALL 9.2 Escenario

Las conclusiones a las que llegué fueron varias: había aprendido, a parte que

me estaba dando cuenta de donde me había metido, primero la importancia que

tenían los semáforos, tenía que aprender como funcionaban y luego como los

debía utilizar. Segundo que cada vez que alguien se conectaba mediante la consola

de pantalla lo estaba haciendo mediante TCP/IP y que todo paquete que bloquease

en un futuro me prohibiría acceder por el mismo puerto de consola. Tercero, que

el kernel a la mínima sospecha que tiene de que se está incumpliendo la calidad de

preemptivo hace un kernel panic, antes de que se dañe cualquier aparato hardware.

Cuarto, en realidad no se mueve los datos de la estructura sk_buff, solo se copia

el puntero que apunta a ella, por lo que cada vez que llega un paquete o se trata

cualquier paquete esta estructura esta siendo accedida lo que significa que hay que

protegerla mediante un semáforo, así que siempre que se accede a datos protegidos

con semáforos las operaciones tiene que ser lo más rápido que se pueda. Estas son

las conclusiones a las que llegué, puede que estén equivocadas, pero lo dudo.

Pero me había servido para algo: me había dado cuenta de la importancia de los

semáforos y había aprendido a debugar el kernel.

Cuando le puse la protección adecuada el sistema operativo pasó a funcionar

perfectamente. Al acceder mediante consola me daba el siguiente mensaje en el

syslog:

PROTO=17 127.0.0.1:745 127.0.0.1:111 L=84 S=0x00 I=0 F=0x4000 T=64

Lo que me daba la razón a la primera hipótesis: al acceder mediante consola lo ha-

ce usando TCP/IP y se envía paquetes del puerto 745 al 111. Por otra parte ahora

se podía acceder mediante SSH y mediante Telnets, funcionaba todo correctamen-

te.

9.2. Escenario

Para poder ver los resultados es necesario montar el escenario que se compone

de unos equipos hardware, el kernel compilado con el firewall nuevo y configurar

el firewall y los otros equipos.

148


9.2.1. Hardware

El escenario para probar el correcto funcionamiento del firewall es parecido

al escenario de debugar. Pero existe una diferencia y es que ahora es imperioso

tener un router o algún equipo que nos retorne los paquetes. Es necesario montar

ordenador con una tarjeta Ethernet, otro ordenador con dos tarjetas de red y un

router con al menos una entrada Ethernet. Se conectan los ordenadores formando

una red (RedA) y otra red entre el segundo ordenador y el router (RedB).

Generador de paquetes

Nuevo Kernel

NIC 1 NIC 2NIC

Firewall

RouterSalida

RedA RedB

loopback

9.2.2. Compilar kernel

En el segundo ordenador donde se instala el firewall hay que instalar un kernel

nuevo con el firewall incluido. Para ello es necesario bajarse un kernel nuevo

del www.kernel.org descompilarlo y aplicarle el patch de nuestro firewall. Así

se elimina el firewall de Netfilter que está en todos los kernels 2.4 y se instala

el nuevo firewall. Para ello hay que compilar el kernel y crear una imagen del

kernel. Con esta imagen se traspasa al ordenador del firewall, se añaden las líneas

necesarias en la configuración del lilo, y se ejecuta el lilo y se rebota la máquina.

Todos estos procesos están correctamente explicados en la parte teórica.

9.2.3. Configurar el firewall

Una vez arrancado el ordenador donde reside el nuevo kernel con el fire-

wall, hay que editar el fichero de configuración del firewall. Este fichero es el

/etc/mywall.conf. En este fichero se definen los comentarios con las líneas que

empiezan con un ’#’ y entonces cada línea corresponde a una política del firewall.

149


La sintaxis de las órdenes del firewall son las siguientes:

intinterfaz

salida

entrada

ip origen

todas

/ mask : puerto

ip destino

todas

/ mask : puerto pasar

bloquear

registrar

Donde pone int, se debe poner la interfaz, luego se puede indicar si de entra-

da, si es de salida o si es indistinto su sentido respecto la interfaz, se muestra la

dirección IP origen con su máscara o bien any para todas las ip, después se indica

el número de puerto origen, y se repite con la dirección IP destino con su respec-

tiva máscara o bien con un any para indicar cualquier IP destino, luego viene el

número de puerto destino y si se bloquea o no el paquete y al final si se hace un

log cuando se case con éxito la regla.

Esta sintaxis permite filtrar por interfaz y el sentido respecto esta. Permite

filtrar por IP destino o IP origen y también por número de puerto, o bien ambos

conjuntamente.

Insertar entonces en el fichero /etc/mywall.conf las siguientes líneas:

#

# nombre int sentido IPorig IPdest pas/bloq registrar

#

interfaz eth0 entrada todas 10.1.0.1/32:80 pasar

interfaz eth0 entrada todas 10.1.0.1/32:23 pasar

interfaz eth0 entrada todas todas bloquear registrar

interfaz eth1 todas todas pasar

De esta manera solo se permitirá ver la página web y el Telnet de la máquina

10.1.0.2. Una vez guardada se ejecuta la orden:

mywall -F -f /etc/mywall.conf

El -F hace un flush de los datos actuales y el -f indica el fichero donde están

las configuraciones.

150


9.2.4. Configurar la red

Para que los paquetes nos retornen hay que configurar el router para de manera

estatica y decirle que la redA está disponible a través del ordenador firewall. Así

que podemos poner los números de red:

RedA 10.2.0.0/16

RedB 10.1.0.0/16

Primer ordenador: eth0 10.2.0.1 máscara 255.255.0.0

Segundo ordenador: eth0 10.2.0.2 máscara 255.255.0.0

eth1 10.1.0.2 máscara 255.255.0.0

Router: eth0 10.1.0.1 máscara 255.255.0.0

ruta estática a 10.2.0.0 / 16 por 10.1.0.2

En el router se ha activado el servidor web y un servidor telnet. También es reco-

mendable que se le active algún otro servicio, que servirá para comprobar como

el firewall bloquea el puerto y no se recive ningún paquete de dichos servicios, ya

que el firewall habría bloqueado la salida.

9.2.5. Resultados

Los resultado se pueden observar porque debería de haber bloqueado todas las

conexiones exceptuando las dos comentadas anteriormente y porque al poner la

orden:

mywall -s

Se ve una tabla con todas las estadísticas parecida a esta:

MyWall un Firewall de Carlos Morales.

paquetes IP eliminados: 30

paquetes IP chequeados: 91

paqutes input: 51 bloqueados: 30 pasados: 21

paquetes output: 40 bloqueados: 0 pasados: 40

...

Como puede observarse, algunos de los paquetes que son input son eliminados y

otros no. Si se sigue probando los contadores deben ir aumentando de valor.

151

10 CONCLUSIONES

10. Conclusiones

La primera conclusión a la que se llega es que muy poca gente se ha atrevido

a entrar dentro del kernel y programar cualquier algoritmo dentro de él, y por lo

tanto, la documentación al respecto es escasísima, no hay ningún documento en

castellano a parte de este trabajo. Casi todos los documentos tan solo se encuentran

en Internet, y los temas tan específicos como la creación de un firewall solo puede

averiguarse preguntando a los desarrolladores del kernel, pero teniendo en cuenta

que es un grupo que no facilitan aquella información que consideran trivial, se

hace más difícil el aprendizaje.

Otra conclusión a la que se llega es que trabajar dentro de un sistema operativo

es una tarea muy compleja. Cada vez que se efectúa algún cambio por pequeño

que sea hay que recompilar todo el kernel, instalarlo y rebotar la máquina con el

nuevo sistema operativo. Tampoco se puede trabajar sobre un kernel y probarlo

a la vez sobre la misma máquina, ya que un kernel en desarrollo puede dañar

los datos guardados en disco facilmente. Y como no hay ningún mecanismo que

proteja al sistema operativo de hacer operaciones ilegales cuando hace un core

dump se para toda la máquina siendo muy dificil hacer un diagnóstico de lo que

ha pasado. Por todas estas razones es importante aprender como se se ejecuta un

kernel en desarrollo en una máquina virtual o en otra máquina conectada a la

desarrollo y a la vez también como poder debugar este kernel en desarrollo.

La programación dentro del kernel debe hacerse con sumo cuidado. Toda es-

tructura que se cree y que puede ser accedida por varios threads a la vez debe

protegerse con semáforos. El kernel dispone de funciones para llamar a los semá-

foros, donde se puede indicar si se desea una protección de lectura o de escritura.

Si no se cumplen con la teoría de los semáforos lo más lógico es que de un kernel

panic y se pare el kernel cuando se está accediendo desde dos lugarles a la misma

estructura de datos. También es importante tener el mínimo número de variables

estáticas, pues ocupan un espacio vital dentro del kernel. Toda estructura debe

hacerse dinámica, y aquí el kernel también dispone de funciones para crear listas

dinámicas de una forma muy sencilla.

Lo más laborioso ha sido resolver estos problemas de trabajo dentro del kernel

y hacer el montaje del escenario para hacer las pruebas. Para bloquear había que

152

10 CONCLUSIONES

probar que ciertos paquetes pasaban las políticas y la respuesta también retornaba.

Para ello se ha necesitado de tres ordendores, uno emitiendo, otro haciendo de

firewall y el último con algún servicio generando respuestas a las peticiones del

primero.

Al final el objetivo principal se ha cumplido que era crear un firewall a partir

de cero que permitiera filtrar los paquetes por dirección IP origen y destino, por el

puerto origen y destino, y todo según la interfaz y el sentido respecto ella.

153

11 LÍNEAS DE FUTURO

11. Líneas de futuro

Una vez conseguido bloquear paquetes IP según su dirección IP origen y su

dirección IP destino se puede añadir nuevas funcionalidades que otros firewalls

más complejos tienen, estas funcionalidades son seguimiento de sesiones, NAT y

balanceo de carga entre varios firewalls.

El seguimiento de sesiones trata de guardar todas las conexiones que se están

mantiniendo en ese momento y con las políticas de filtrado tratar los nuevos pa-

quetes. Ciertos protocolos, como por ejemplo FTP, H323 entre otros mantienen en

sus conexiones unas sesiones características debido a que el cliente y servidor ha-

cen los dos funciones de cliente y de servidor. Tiene un coste aproximado de 500

horas y con los conocimientos necesarios de sistemas operativos y de telemática

puede ser un TFC.

Muchos firewalls son los encargados de hacer NAT (Traducción de direccio-

nes), ya que están situados justo en el borde de la red a proteger y otra red. Hacien-

do NAT la red a proteger puede tener IP privadas que no funcionan en Internet,

así se hace muy difícil hacer un ataque spoofing emulando un ordenador interno.

Para hacer NAT se debe mantener también información de todas las sesiones en

curso mediante unas tablas. Donde se guarda todas las sesiones en curso y las tra-

ducciones que se estén usando. Es un proyecto con un coste aproximado de 600

horas, y también puede ser un TFC.

La tercera propuesta es hacer un balanceo de carga entre firewalls. El proble-

ma de los firewalls es que la mayoría no están duplicados y no hay reduntancia, y

los que disponen de ella son muy caros. La propuesta es balancear las conexiones

entre varios firewalls y para su correcto funcionamiento es necesario mantener el

seguimiento de las sesiones y NAT entre los diferentes firewalls. Hay que montar

un mecanismo entre las máquinas donde se puedan comunicar de forma segura

y poder cambiar información de las tablas de sesiones. Esta propuesta es mucho

más avanzada y compleja, no solo son necesarios conocimientos de sistemas ope-

rativos y de telemática, sino que es neceario tener conocimientos de arquitecturas

avanzadas y de programación paralela. El coste es aproximadamente de unas 1000

horas y podría hacerse en un PFC por varias personas.

154

12 COSTE DEL TRABAJO

12. Coste del trabajo

El coste del proyecto se divide en documentación sobre firewalls, documen-

tación UML, documentación sobre el kernel de linux, pruebas programando y

debugando el kernel, programación de la aplicación, experimentación y pruebas

de su correcto funcionamiento y por último la memoria.

Se considera documentación sobre firewalls la búsqueda de la información

sobre los protocolos TCP/IP y sobre los firewalls. La documentación UML se

basa en el estudio de la metodologia del UML. Por último la documentación del

kernel de linux se enfocó para averiguar cómo trabajar dentro del kernel.

La parte práctica comprende las pruebas programando y debugando el kernel,

donde se ponía en práctica todo lo leído referente a la programación dentro del

kernel, de su debugado y del montaje del escenario para su funcionamiento. La

programación de la aplicación es el tiempo destinado a la construcción del fire-

wall. En las pruebas se montó un escenario de pruebas y se comprobó que filtraba

correctamente.

Y la tercera parte es la memoria, donde se especifica el tiempo de preparación

de la memoria.

155


Tema Horas Porcentaje

Teoría Firewalls 40 h 6,2 %

UML 60 h 9,3 %

Kernel 140 h 21,6 %

Total Teoría 240 h 37,1 %

Práctica Estudio del Kernel 180 h 27,9 %

Programar Firewall 65 h 10 %

Implementación escenarios 22 h 3,4 %

Total Práctica 267 h 41,3 %

Memoria Total Memoria 140 h 21,6 %

Total 647 h 100,0 %

156


Bibliografía

[ALS] RUBINI, ALESSANDRO; Linux Device Drivers, 2nd Edition; O’Relly;

2001. ISBN: 0-59600-008-1

[DAV] FRASCONE, DAVID; Debugging Kernel Modules with User Mode

Linux; Mayo 2002 LinuxJournal

[GI1] INSOLVIBLE, GIANLUCA; Inside the Linux Packet Filter; Febrero

2002 LinuxJournal

[GI2] INSOLVIBLE, GIANLUCA; The Linux Socket Filter: Sniffing Bytes

over the Network; Junio 2001 LinuxJournal

[GOO] GOOGLE GROUPS; comp.os.linux.misc

[KAH] ARCOMANO, ROBETO; Kernel Analysis- HOWTO; 2002.

http://www.tldp.org/HOWTO/KernelAnalysis-HOWTO.html

[KAL] KALE, AMIT S.; Kdbg: Linux kernel source level debugger; 2002

http://kgdb.sourceforge.net/

[KE1] KERNEL DOCUMENTATION; Coding Style; linux/Documentation/CodingStyle

[KRO] KROAH-HARTMAN, GREG; Proper Linux Kernel Coding Style; Ju-

lio 2002 LinuxJournal

[LIS] LINUX KERNEL MAILING LIST ARCHIVES; Desde 1997; http://www.cs.Helsinki.FI/linux/linux-

kernel/

[LT1] TORVALDS, LINUS; The Linux Kernel Archives; http://www.kernel.org

[RF1] RFC 768; The User Datagram Protocol; DARPA 1980 http://www.ietf.org/rfc/rfc0768.txt

[RF2] RFC 791; Internet Protocol; DARPA 1981

http://www.ietf.org/rfc/rfc0791.txt

[RF3] RFC 793; The Transmission Control Protocol; DARPA 1981

http://www.ietf.org/rfc/rfc0793.txt

157


[RU1] RUSSELL, PAUL; Unreliable Guide to Hacking The Linux Kernel;

http://www.netfilter.org/unreliable-guides/

[RU2] RUSSELL, PAUL; Kernel Locking Guide;


[RU3] RUSSELL, PAUL; Linux 2.4 Packet Filtering HOWTO;


[STV1] STEVENS, W. RICHARD; Advanced Programming in the UNIX

Environment; Addison-Wesley Ed.; 1992. ISBN: 0-201-56317-7.

[UML] RUMBAUGH, JAMES; JACOBSON, IVAR; BOOCH, GRADY; El Len-

guaje Unificado de Modelado. Manual de Referencia; Addison Wesley Ed.

2000. ISBN: 84-7829-037-0.

[VAS] VASUDEVAN, ALAVOOR; CVS-RCS-HOWTO Document for Li-

nux;

http://www.tldp.org/HOWTO/CVS-RCS-HOWTO.html

[WAR] WARD, BRIAN; The Linux Kernel HOWTO;

http://www.tldp.org/HOWTO/Kernel-HOWTO.html

[WS1] WRIGHT, GARY R.; STEVENS, W. RICHARD; TCP/IP Illustrated,

Volume 1 The Protocols; Addison Wesley Ed.; 1994. ISBN: 0-201-63346-

9.i

[WS2] WRIGHT, GARY R.; STEVENS, W. RICHARD; TCP/IP Illustrated,

Volume 2 The Implementation; Addison Wesley Ed.; 1995. ISBN: 0-201-

63354-X.

158

Parte III

Anexo A sk_buffA continuación se pasa a detallar la estructura del sk_buff. La estructura de

un socket buffer se encuentra en include/linux/skbuff.h y se puede acceder a ella a

través de <linux/skbuff.h>, está formada por:

struct sk_buff {

struct sk_buff * next;

struct sk_buff * prev;

struct sk_buff_head * list;

struct sock *sk;

struct timeval stamp;

struct net_device *dev;

union {

struct tcphdr *th;

struct udphdr *uh;

struct icmphdr *icmph;

struct igmphdr *igmph;

struct iphdr *ipiph;

struct spxhdr*spxh;

unsigned char *raw;

} h;

/* Network layer header */

union {

struct iphdr *iph;

struct ipv6hdr *ipv6h;

struct arphdr *arph;

struct ipxhdr *ipxh;

unsigned char *raw;

} nh;

159

union {

struct ethhdr *ethernet;

unsigned char *raw;

} mac;

struct dst_entry *dst;

/*

* This is the control buffer. It is free to use for every

* layer. Please put your private variables there.

*/

char cb[48];

unsigned int len;

unsigned int data_len;

unsigned int csum;

unsigned char __unused,

cloned,

pkt_type,

ip_summed;

__u32 priority;

atomic_t users;

unsigned short protocol;

unsigned short security;

unsigned int truesize;

unsigned char *head;

unsigned char *data;

unsigned char *tail;

unsigned char *end;

void (*destructor)(struct sk_buff *);

#ifdef CONFIG_NETFILTER

/* Can be used for communication between hooks. */

unsigned long nfmark;

/* Cache info */

__u32 nfcache;

160

/* Associated connection, if any */

struct nf_ct_info *nfct;

#if defined(CONFIG_HIPPI)

union{

__u32 ifield;

} private;

#endif

#ifdef CONFIG_NET_SCHED

__u32 tc_index;

#endif

};

Bueno aquí teneis entera la estructura sk_buff, y aquí hay una lista con cada uno

de los campos:

next : es el siguiente skb en la lista

prev : es el anterior skb en la lista

list : lista en la que nos encontramos.

sk : es el socket que estamos utilizando

stamp : valor tiempo en el que nos llego

dev : dispositivo que nosotros estamos dejando

rx_dev : desde el dispositivo que nos llegó

h : cabecera de la capa de transporte (tcp, udp, icmp, igmp, spx, raw)

nh : cabecera de la capa de red (ip, ipv6, arp, ipx, raw)

mac : cabecera del nivel de enlace

dst

cb : buffer de control

161

len : longitud del dato

csum : checksum

used : ¿estamos siendo en uso?

is_clone : es una copia sk_buff

cloned : la cabecera se puede copiar

pkt_type : el tipo de paquete

ip_summed : el driver nos suministra un checksum IP

priority : prioridad del paquete dentro de la cola de paquetes

protocol : protocolo del paquete

security : nivel de seguridad del paquete

truesize : verdadero tamaño del skb.

head : puntero al principio del buffer

data : puntero al principio del dato.

tail : puntero al final del dato.

end : final del puntero

destructor : destructor de la funcion

nfcache : info de la cache interna referente a netfilter

nfct : conexion asociada al socket

162

Parte IV

Anexo B Coding StyleExisten unas reglas básicas, escritas y no escritas, para asegurarse que otros

usuarios del kernel. Existe unas reglas escritas en la propia documentación de Li-

nux [KE1] y otras reglas no escritas [KRO] pero que se supone todo programador

conoce.

Como el número de desarrolladores que miran el código fuente del kernel de

Linux es muy grande, lo mejor es tener una guía consistente a seguir. Así es más

fácil entender para cualquiera que lea el kernel lo que se ha insertado, lo que hace

que puedan entenderlo mejor y corregir posibles fallos o mejorar el código. Que

es eso de lo que se trata todo esto del código abierto o open-source.

Indexación

Todos los tabulados son ocho carácteres en blanco y será eso el caracter <TAB>.

Hace que sea más facil localizar donde están los diferentes bloques de código. Hay

que intentar evitar que haya más de tres niveles de indexación, ya que puede cau-

sar que navegar por el código sea muy incómodo, pues las líneas sobrepasan el

tamaño de la pantalla.

Poniendo corchetes

Los autores originales de UNIX ponían los corchetes con el corchete que abre

al final de la primera línea y el corchete que cierra al principio de la última línea:

if ( x >= 1 ) {

hacer_lo_que_sea();

}

Por eso, el kernel de Linux usa este estilo. La única excepción a esta regla son

las funciones, las cuales se tienen el corchete que abre al principio de la segunda

línea:

163

int funcion_cool( int x)

{

cuerpo de la funcion

}

Un buen ejemplo a seguir son los ficheros que hay en el directorio kernel del

código fuente.

Nombrar variables y funciones

Para nombrar las variables y funciones deberían ser descriptivas y concisas. No

usar nombres largos y bonitos como por ejemplo CommandAllocationGroupSize

o por ejemplo DAC_V1_EnableMemoryMailboxInterface(), en vez de eso usar

cmp_group_size o bien enable_mem_mailbox().

Las variables globales es mejor no usarlas, solo hacerlo si es absolutamente

necesario. Las variables locales deberían ser cortas. Para las variables de los bu-

cles puede usarse ’i’ o ’j’, mientras que ’contador_bucle’ es demasiado largo. Las

variables del tipo ’tmp’ también se permiten pero solo para variables con poco

tiempo de vida.

También se puede encontar buenos ejemplos en el los ficheros del sistema de

ficheros en fs/*.c. Y ejemplos que son negativos también pueden encontrarse en

drivers/scsi/cpqfs* .

Funciones

Las funciones deben hacer solo una cosa y hacerla bien. Deberían ser cortas y

ser del tamaño de uno o dos pantallas. Si se tiene una función que hace pequeñas

cosas para muchos casos, es aceptable que sea larga. Pero si es larga y además es

compleja hay que modificarla.

Dicen que el número de variables nos indica la complejidad de la función. Así

que si se tiene un gran número de variables entonces es que hay q cambiarlo.

164

Comentarios

Los comentarios malos explican como trabaja el código, quien escribió tal fun-

ción en una fecha específica y otras cosas poco útiles. Los comentarios correctos

deben explicar qué hace la función y porqué lo hace. Deberían incluirse al prin-

cipio de la función y no necesariamente dentro de ella, porque hay que escribir

funciones pequeñas.

Hay un estadar para los comentarios de las funciones, que es una variante del

método de documentación usada en el proyecto GNOME. Lo bueno de usar este

tipo de estilo es que luego se puede sacar información usando compiladores de do-

cumentacion. Que puede verse ejecutando ’make psdocs’ o bien ’make htmldocs’

para generar un fichero postcript o html para cada caso. Para más información

mirar Documentation/kernel-doc-nano-HOWTO.txt.

Tipos de estructuras de datos

Si se crea cualquier estructura de dato donde pueda accederse desde fuera por

un thread o por cualquier otro procedimiento hay que implementar un contador de

referencias. Si se añade un contador de referencias una estructura, se evitan mu-

chos problemas con race conditions. Y seguro que si hay otro thread que puede

encontrar y acceder a tu estructura de datos y no se tiene un contador de referen-

cias seguro que tenemos un bug.

Funciones para los strings

En el fichero include/linux/string.h, hay muchas funciones para tratar strings.

Así que si se intenta trabajar con strings dentro del kernel, hay que usar estas

funciones y no intentar reescribirlas de manera accidentada. En el fichero inclu-

de/linux/string.h y por include/linux/kernel.h se encuentran todas las funciones,

así se ahorra uno muchos problemas.

Orden de los bytes

Tampoco hay que reescribir las funciones para tratar las diferentes represen-

taciones endian. En el fichero include/asm/byteorder.h donde asm es el tipo de

165

arquitectura del procesador, contiene una gran cantidad de funciones que permi-

ten hacer conversiones automáticamente, dependiendo donde se compile y de la

arquitectura usará unas funciones u otras.

Listas

Como en cualquier programa se necesitan las listas dinámicas. Para eso debe

usarse las funciones include/linux/list.h. Donde se puede encontrar una estructu-

ra: ’struct list_head’, que deberñia incluirse dentro de la estructura donde se desee

crear la lista. Entonces se podrá usar las funciones de añadir, borrar o iterar sobre

las listas de manera fácil sin tener que reescribir nuevo código. Algunos buenos

ejemplos que he encontrado están en drivers/hotpluc/pci_hotplug_core.c y en dri-

vers/ieee1934/nodemgr.c.

typdef está prohibido

Los famosos typedef no deberián usarse para llamar a ningún tipo de estructu-

ra. La mayoria de las estructuras del kernel no tienen ningún typedef. Ya que hace

más oscuro el código porque se añaden capas, y no dejan que el programador sepa

qué tipo de dato se esta usando.

Jamás usar un typedef para significar un puntero a una estructura. Esto esconde

el puntero y entonces pueden aparecer muchos problemas, como por ejemplo que

no se pide memoria correctamente, que se accede a partes de la memoria donde

no se debe, y esta es la forma más fácil de conseguir un kernel panic.

El único lugar donde los typedef son aceptables es al declarar prototipos de

funciones. Estas pueden ser difíciles de escribir, asi que haciendo un typedef para

estas se convierte en una forma fácil de escribir.

166

estudio, diseño e implementación de un...

Documents