Implementacion de Un Fire Wallas

Estudio, diseo e implementacin de
un Firewall
C ARLOS G USTAVO M ORALES T EJEDA
Septiembre 2002
Abstracto
Los firewall son los componentes ms importantes a la hora de proteger una
red de datos, ya que se encargan de filtrar los datos que pasan a travs de l. El
objetivo de este TFC es crear un firewall de filtrado de paquetes bajo un entorno Unix. La dificultad reside en la programacin a bajo nivel dentro del sistema
operativo, en la que cualquier error de programacin supone una parada del ordenador y porque toda modificacin requiere compilar el kernel de nuevo y rebotar
la mquina donde se est ejecutando el firewall
Resumen
Un firewall es el componente ms 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 travs de l. El objetivo de este proyecto es hacer
un estudio terico de los firewalls en un entorno Unix-Linux, para luego poder
disear e implementar uno. As pues, esta memoria est dividida principalmente
en dos partes: una parte terica y una prctica.
Dentro de la parte terica hay un breve estudio de los protocolos TCP/IP, que
son los protocolos que usan las redes de datos. El siguiente tema es una introcucin a los firewalls, donde se narra las caractersticas y los posibles tipos de
firewalls. Se hace un especial incapi en el filtrado de paquetes pues se le dedica
un captulo entero ya que es el tipo de firewall que se va a implementar. Los firewalls de filtrado de paquetes se basan en las cabeceras de los paquetes de datos
para decidir si deben filtrarse. En el siguiente captulo se repasa el sistema operativo Linux ya que la programacin del firewall va muy ligado con este. Hay un
resumen de sus caractersticas 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 captulo es un estudio
del diseo, para poder modelar correctamente cualquier proyecto.
La programacin dentro del sistema operativo es muy compleja, llamado hacking 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 ejecutando. El siguiente captulo aborda el diseo de la aplicacin, que comprende tanto
los esquemas del modelado como la explicacin de como se ha programado el
firewall. Despus hay un captulo llamado implementacin del firewall, donde se
explican los escenarios que se ha necesitado tanto para desarrollar como para probar los resultados finales.
Los ltimos captulos comprenden las conclusiones, las lneas de futuro que
pueden seguirse, el coste del proyecto y la bibliografa que se ha necesitado.
ndice
I Teora
1. Introduccin
2. TCP/IP
2.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1. Capas . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2. Encapsulacin . . . . . . . . . . . . . . . . . . . . . . .
2
2
4
2.2. IP: Internet Protocol . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . .
5
5
2.2.2. Cabecera IP . . . . . . . . . . . . . . . . . . . . . . . . .
2.3. UDP: User Datagram Protocol . . . . . . . . . . . . . . . . . . .
2.3.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . .
6
9
9
2.3.2. Cabecera UDP . . . . . . . . . . . . . . . . . . . . . . .

2.4. TCP: Transmisin Control Protocol . . . . . . . . . . . . . . . .
9
10
2.4.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . .
2.4.2. Cabecera TCP . . . . . . . . . . . . . . . . . . . . . . .
10
12
3. Introduccin a los firewalls

3.1. Qu es un Firewall? . . . . . . . . . . . . . . . . . . . . . . . .
15
15
3.2. Qu puede hacer . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2.1. Donde localizar las decisiones . . . . . . . . . . . . . . .
16
16
3.2.2. Refuerza polticas . . . . . . . . . . . . . . . . . . . . . .

3.2.3. Registrar la actividad . . . . . . . . . . . . . . . . . . . .
3.2.4. Limita la exposicin . . . . . . . . . . . . . . . . . . . .
16
16
16
3.3. Qu no puede hacer . . . . . . . . . . . . . . . . . . . . . . . . .

3.3.1. Dentro de la red . . . . . . . . . . . . . . . . . . . . . . .
17
17
3.3.2. Conexiones que no van a travs de l . . . . . . . . . . .

3.3.3. Virus . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4. Tipos de Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . .
17
17
18
3.4.1. Filtrado de paquetes . . . . . . . . . . . . . . . . . . . .
18
3.4.2. Servicios proxy . . . . . . . . . . . . . . . . . . . . . . .

3.4.3. Combinacin de tcnicas . . . . . . . . . . . . . . . . . .
20
21
3.5. Arquitecturas Firewall . . . . . . . . . . . . . . . . . . . . . . .

3.5.1. Dual-Homed Host . . . . . . . . . . . . . . . . . . . . .
3.5.2. Screened Host . . . . . . . . . . . . . . . . . . . . . . .
21
22
23
3.5.3. Screened Subnet . . . . . . . . . . . . . . . . . . . . . .

3.5.4. Variaciones posibles . . . . . . . . . . . . . . . . . . . .
24
26
4. Filtrado de paquetes
28
4.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2. Caractersticas . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3. Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
29
30
4.3.1. Proteger toda la red . . . . . . . . . . . . . . . . . . . . .

4.3.2. Transparencia . . . . . . . . . . . . . . . . . . . . . . . .
30
31
4.3.3. Disponibilidad . . . . . . . . . . . . . . . . . . . . . . .
4.3.4. Latencia . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4. Desventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
31
32
4.4.1. Protocolos difciles . . . . . . . . . . . . . . . . . . . . .

4.4.2. Poltcas que no pueden aplicarse . . . . . . . . . . . . .
32
33
4.4.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5. Configuracin . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.1. Bidireccionalidad . . . . . . . . . . . . . . . . . . . . . .
33
33
34
4.5.2. Inbound y Outbound . . . . . . . . . . . . . . . . . .

4.5.3. Permitir por defecto versus denegar por defecto . . . . . .
34
35
4.6. Que hacer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.6.1. Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.6.2. Paquetes ICMP . . . . . . . . . . . . . . . . . . . . . . . 37
4.7. Filtrado por direccin . . . . . . . . . . . . . . . . . . . . . . .
4.7.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . .
4.7.2. Riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
39
40
5. El Sistema Operativo Linux

5.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
42
5.1.1. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
45
5.1.3. Caractersticas . . . . . . . . . . . . . . . . . . . . . . .
5.2. El Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . .
46
50
50
5.2.2. Modos . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.3. Mdulos . . . . . . . . . . . . . . . . . . . . . . . . . .
50
51
5.2.4. Procesos . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.5. Sincronizacin . . . . . . . . . . . . . . . . . . . . . . .
5.2.6. Comunicacin entre procesos . . . . . . . . . . . . . . .
51
52
54
5.2.7. Control de la Memoria . . . . . . . . . . . . . . . . . . .

5.2.8. El cdigo . . . . . . . . . . . . . . . . . . . . . . . . . .
54
55
5.2.9. Numeracin . . . . . . . . . . . . . . . . . . . . . . . .
5.2.10. Compilacin del ncleo . . . . . . . . . . . . . . . . . .
5.3. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
59
65
5.3.1. Editores de texto . . . . . . . . . . . . . . . . . . . . . .

5.3.2. Herramientas de desarrollo . . . . . . . . . . . . . . . . .
65
68
5.3.3. Navegacin . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.4. Manipuladores . . . . . . . . . . . . . . . . . . . . . . .
5.3.5. Control de versiones . . . . . . . . . . . . . . . . . . . .
69
72
74
5.4. Netfilter en los kernels 2.4 . . . . . . . . . . . . . . . . . . . . .

5.4.1. Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
80
5.4.2. Inconvenientes . . . . . . . . . . . . . . . . . . . . . . .
5.5. Viaje de un paquete . . . . . . . . . . . . . . . . . . . . . . . . .
5.5.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . .
80
82
82
5.5.2. Tarjeta de red . . . . . . . . . . . . . . . . . . . . . . . .

5.5.3. Proceso de red . . . . . . . . . . . . . . . . . . . . . . .
5.5.4. Softirq para NET_RX . . . . . . . . . . . . . . . . . . .
82
84
85
5.5.5. Tratar los paquetes IP . . . . . . . . . . . . . . . . . . . .
85
6. Estudio del Diseo ( UML)

6.1. Introduccin al UML . . . . . . . . . . . . . . . . . . . . . . . .
88
88
6.1.1. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
6.1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.3. Participantes en UML 1.0 . . . . . . . . . . . . . . . . .
89
90
6.1.4. reas conceptuales . . . . . . . . . . . . . . . . . . . . .

6.2. Diagramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1. Diagramas estructurales . . . . . . . . . . . . . . . . . .
91
92
94
6.2.2. Diagramas de comportamiento . . . . . . . . . . . . . . .

6.3. Diagramas de Objetos . . . . . . . . . . . . . . . . . . . . . . . .
94
95
6.3.1. Oid (Object Identifier) . . . . . . . . . . . . . . . . . . .

6.3.2. Caractersticas alrededor de un objeto . . . . . . . . . . .
6.4. Diagramas de Clases . . . . . . . . . . . . . . . . . . . . . . . .
96
97
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. Envo de mensajes . . . . . . . . . . . . . . . . . . . . . 104
6.6.3. Acciones . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.7. Diagramas de actividades . . . . . . . . . . . . . . . . . . . . . . 106
6.7.1. Notacin . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.8. Diagramas de Interaccin . . . . . . . . . . . . . . . . . . . . . . 108
6.8.1. Colaboracin . . . . . . . . . . . . . . . . . . . . . . . . 109
6.8.2. Interaccin . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.8.3. Patrn . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.9. Diagramas de Componentes . . . . . . . . . . . . . . . . . . . . 110
6.9.1. Componentes . . . . . . . . . . . . . . . . . . . . . . . . 112
6.10. Diagramas de Despliegue . . . . . . . . . . . . . . . . . . . . . . 113
6.11. Los paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
II Prctica
117
7. Hacking del kernel

117
7.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
7.2. Uso del debugador . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.3. printk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

7.4. Oops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
7.5. Mquinas virtuales . . . . . . . . . . . . . . . . . . . . . . . . . 124
7.6. Debugando con dos mquinas . . . . . . . . . . . . . . . . . . . 125
8. Diseo de la aplicacin
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. Exclusin mutua . . . . . . . . . . . . . . . . . . . . . . . . . . 136
8.2.1. La importancia de los semforos . . . . . . . . . . . . . . 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. Implementacin del firewall
145
9.1. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
9.1.1. Debugar . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
9.1.2. Semforos . . . . . . . . . . . . . . . . . . . . . . . . . 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. Lneas de futuro
154
12. Coste del trabajo
155
III Anexo A sk_buff
159
IV
162
Anexo B Coding Style
1 INTRODUCCIN
Parte I
Teora
1. Introduccin
En construccin de edificios, un muro de fuego (firewall en ingls) se disea
para mantener el fuego separado de una parte de un edificio a otra. En teora, un
firewall de Internet sirve con el mismo propsito: previene de peligros de Internet
a la red interna. El firewall protege la red filtrando toda la informacin que pasa
a travs de l y decidiendo si el trfico se acepta segn las polticas de seguridad.
El firewall es el elemento ms 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 bsico.
Siguiendo la comparativa de la construccin, el firewall hace la misma funcin
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 segura, pueden haber otras amenazas como incendios, puertas traseras, etc. Pero una
buena puerta sigue siendo el elemento ms importante y un componente bsico.
El objetivo de este trabajo es construir un firewall desde cero. El firewall debe
insertarse dentro del sistema operativo, filtrar los paquetes IPv4 segn la direccin
origen y destino, segn el nmero de puerto origen y destino, segn la interfaz y
el sentido del paquete respecto esa misma interfaz.
2 TCP/IP
2. TCP/IP
2.1. Introduccin
Es fundamental explicar el conjunto de protocolos que nos sirven para comunicar varios equipos, ya que entendiendo cmo funciona sabremos qu polticas
necesitamos para disear 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 diferentes fabricantes, corriendo sistemas operativos completamente diferentes comunicarse entre ellos. Lo que empez a finales de los 1960 como un proyecto
de investigacin financiado por el gobierno en una red de ordenadores del tipo
packet switching, se ha convertido en el protocolo de red ms usado entre ordenadores. Es tal su relevancia que el firewall se construir slo 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 combinacin de diferentes protocolos
en varias capas, que normalmente se le considera un sistema de 4 capas o layers.
2 TCP/IP
2.1 Introduccin
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 fsicamente 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
travs de la red. Para el enrutado de paquetes se usa IP (Internet Protocol),
ICMP (Internet Control Message Protocol) y el IGMP (Internet Group Managment 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 (Transmisin Control Protocol) 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 tamao correcto para la capa de
red, aceptando los paquetes recibidos, marcando tiempos para asegurar que
3
2 TCP/IP
2.1 Introduccin
los paquetes de acknowledge enviados, entre otros. Al ser un flujo de datos asegurado la capa de aplicacin puede ignorar estos detalles. En cambio
UDP provee una forma mucho ms simple de comunicarse. Este simplemente enva 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 aadirse en la capa de aplicacin.
4. La ltima capa, la capa de aplicacin trata los detalles del una aplicacin 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 electrnico, etc
Cada capa tiene uno o ms 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 travs de la capa de red
usando el protocolo IP, este proceso se llama Encapsulacin y se pasa a explicar
en el siguiente punto.
2.1.2. Encapsulacin
Cuando una aplicacin enva datos usando TCP, los datos son enviados abajo
y los almacena en la pila del protocolo, y as sucesivamente a travs de cada capa,
hasta que son enviados como un conjunto de bits por la red. Cada capa o layer
aade informacin a los datos, normalmente antecediendo a los datos o a veces
aadiendo unos pocos datos al final. La unidad de datos que TCP enva a la pila
de IP se llama un segmento TCP. La unidad de datos que enva 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 aadir algn tipo de identificador en la cabecera IP que genera para
indicar a qu capa pertenece. Esto se trata guardando un valor del tamao 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 identificarse. La capa de transporte guarda un identificador en la cabecera que genera
para identificar la aplicacin. Ambos protocolos el TCP y el UDP usan nmeros
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 tambin indicar que los
frames de la capa de red que recibe el driver de la tarjeta Ethernet, tienen tambin
un campo de 16 bits para indicar que capa del protocolo gener los datos.
2.2. IP: Internet Protocol

2.2.1. Introduccin
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
conexin (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 ms 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 conexin significa que IP no mantiene ningn
estado de informacin 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 enva dos datagramas 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 diseado para ser retransmitido para ser usado en sistemas
interconectados en redes de comunicaciones packet-switched. Los hosts se identifican por una direccin 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 conexin.
5
2 TCP/IP
Las funciones bsicas del protocolo segn la especificacin RFC0791 son dos:
direccionar y fragmentar. Para direccionar se usan las direcciones que se encuentran en la cabecera. La seleccin del camino para la transmisin 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 especificacin RFC 791, publicada en septiembre del 1981 (http://www.ietf.org/rfc/rfc07

encuentra la especificacin de la cabecera del datagrama.
0
15 16
version
ip_v
header
length
type of service
ip_tos
flags and fragment offset

ip_off
identificacin
20 bytes
cabecera
time to live
ip_ttl
31
total length
ip_len
protocolo
ip_p
header chacksum
ip_sum
direccin IP origen 32 bits

ip_src
direccin IP destino 32 bits
ip_dst
opciones
(si las hay)
datos
Versin: 4 bits
El campo de versin indica el formato de la cabecera de Internet. Esta cabecera
corresponde a la versin 4.
IHL: 4 bits
Internet Header Lenght o tamao de la cabecera, es el tamao de la cabecera en
palabras de 32 bits, tras la cual empiezan los datos. El valor mnimo de la cabecera
es 5.
TOS: 8 bits
2 TCP/IP
Type Of Service o tipo de servicio indica los parmetros para la calidad de servicio
deseado. Estos parmetros suelen usarse para ser una gua del tipo de servicio que
se est retransmitiendo en el datagrama.
Tamao total: 16 bits
El tamao total es el tamao del datagrama, medido en octetos, incluyendo el tamao de la cabecera y de los datos. El tamao de 16 bits permite que el datagrama
sea hasta 65.535 octetos. El tamao de dichos datagramas es impracticable en la
mayora de redes y ordenadores. Todos los ordenadores tienen que estar preparados para aceptar datagramas de hasta 576 octetos.Si se quiere saber ms sobre la
configuracin de LILO, hay que obtener la versin ms reciente de servidor FTP
favorito y siga las instrucciones que le acompaan
Identificacin: 16 bits
Una valor de identificacin asignado por el emisor para poder ensamblar los diferentes fragmentos de un datagrama.
Flags: 3 bits
1. Bits de control:
Bit 0: reservado. Tiene que ser cero.
Bit 1: (DF) 1 = Dont 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 tamao
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
2 TCP/IP
Este campo indica el tiempo mximo 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 mdulo tiene que decrecer el valor
de TTL como mnimo por uno incluso si se ha tardado menos de un segundo en
procesar el datagrama. La intencin 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.
Direccin origen: 32 bits
Es la direccin IP origen de 32 bits.
Direccin destino: 32 bits
Es la IP del dispositivo destino, tambin de 32 bits.
Opciones: variable
Las opciones pueden o no aparecer en los datagramas. Deben ser implementados por todos los mdulos IP. Lo que es opcional es su transmisin en cualquier
datagrama, pero no su implementacin.
8
2 TCP/IP
2.3 UDP: User Datagram Protocol
2.3. UDP: User Datagram Protocol

2.3.1. Introduccin
UDP es simple, orientado a datagrama, y est encuadrado en la capa de trasporte. Cada operacin de envo por un proceso produce exactamente un datagrama
UDP, lo que causa que slo un datagrama IP sea enviado. Es diferente a un protocolo orientado a conexiones (stream-oriented protocol) como es el caso de TCP
donde la cantidad de datos enviados por una aplicacin puede tener pequeas diferencias a lo que en realidad es enviado en un datagrama IP.
En la siguiente figura se ensea la Encapsulacin de un datagrama UDP en el
datagrama IP.
La especificacin 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 conexin fiable (no reliability): enva el datagrama que la
aplicacin escribe a la capa IP, pero no garantiza que llegue a su destino, es un
protocolo que no est orientado a conexin. La falta de confianza hace pensar que
deberamos 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 pueden encontrarse en el RFC 768.
0
32
15 16
Direccin origen
Direccin destino
ceros
protocolo
UDP length
Datos
Nmero de puerto origen: 16 bits

9
2 TCP/IP
2.4 TCP: Transmisin Control Protocol
Identifica el proceso que enva el datagrama. Tanto este campo como el siguiente
nos sirven para poner reglas de filtrado en el firewall.
Nmero de puerto destino: 16 bits
Identifica de la misma manera el proceso que debe recibir el datagrama. Este campo se usa para multiplexar los datagramas que llegan a la mquina y pasarlos a la
aplicacin que se necesita. La pila de IP ya se encarga de dividir los paquetes entre los TCP y los UDP, as que es el propio UDP quien mira el puerto destino y
tambin implica que los puertos TCP y UDP son independientes entre ellos.
Tamao UDP: 16 bits
Es el tamao de la cabecera UDP y de los datos, la cantidad es en Bytes. El valor
mnimo 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 tamao que se
encuentra en la cabecera IP menos el tamao 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 aadirse un relleno para que cuadren
las palabras de 16 bits.
2.4. TCP: Transmisin Control Protocol

2.4.1. Introduccin
La especificacin original para TCP es la RFC 793, publicada por Postel en
Septiembre de 1981 para DARPA (Defense Advanced Research Projects Agency).
An 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 conexin, fiable y un servicio de flujo de bytes (byte
stream service).
10
2 TCP/IP
Por el trmino orientado a conexin se entiende que dos aplicaciones usando

TCP tienen que establecer una conexin entre ellos antes de poder intercambiar
datos. Una analoga parecida es una llamada de telfono: se marca, se espera que
la otra parte responda a la llamada, decir un hola y quien es, tras ello comienza
la conversacin.
Al decir que es fiable (reliability) se indica lo siguiente:
1. Los datos de la aplicacin se separan en lo que TCP considera que es el mejor tamao. Completamente diferente a UDP, donde cada vez que escriba
la aplicacin generaba un datagrama UDP de ese mismo tamao. La unidad
de informacin pasada por TCP a IP se llama segmento.
2. Cuando TCP enva un segmento mantiene un temporizador, esperando para
que la otra parte enve un segmento con su acuse de recibo (acknowledge). 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 conexin este enva un acuse de recibo. Que no aunque no se enva 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 errneo TCP lo descarta y no enva
ningn acuse de recibo.
5. Al encapsular TCP dentro de IP, y como los datagramas IP pueden llegar
en desorden, los segmentos pueden llegar tambin en desorden. Se encarga
tambin TCP de reordenarlos en caso de ser necesario, pasando los datos
recibidos en el orden correcto a la aplicacin.
6. Como un datagrama IP puede llegar duplicado, los segmentos TCP duplicados deben ser descartados.
7. TCP tambin mantiene un control del flujo de datos. Cada parte en la conexin TCP tiene el espacio del buffer de entrada finito. Lo que significa que
TCP solo permite que la otra parte enve los datos que tiene reservados. Esto
11
2 TCP/IP
previene de que un ordenador rpido llene todos los buffers de un ordenador

lento.
Cuando hablamos de un servicio de flujo de bytes (byte stream service) nos referimos a que TCP enva un flujo de bytes a travs de la conexin, no hay marcas
que identifiquen cuando el emisor envi los datos. Significa que si una aplicacin
enva 20 bytes, luego enva otros 35 bytes seguido por otros 25 bytes, la aplicacin de la otra parte no podr identificar los tamaos 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
conexin.
Adems, TCP no interpreta el contenido de los bytes que enva. TCP no tiene
ni idea si los datos corresponden a datos en binario, a caracteres ASCII, caracteres
EBCDIC o lo que sea. La interpretacin de los bytes retransmitidos es funcin de
la aplicacin que se encuentra en una capa superior a la de transporte de TCP.
2.4.2. Cabecera TCP
Los segmentos TCP se envan mediante datagramas IP. La cabecera TCP sigue
a la cabecera IP, aadiendo informacin especfica para el protocolo TCP.
0
32
15 16
Puerto Origen
Puerto Destino
Nmero Secuencia
Acknowledge Number
Data Off
Reserved | bits
Ventana
Opciones
Padding
Datos
Puerto de origen: 16 bits

Nmero de puerto de origen.
12
2 TCP/IP
Puerto de origen: 16 bits

Puerto destino que indica a qu aplicacin va dirigido el segmento.
Nmero de secuencia: 32 bits
El nmero de secuencia del primer octeto de datos. En el caso de estar el bit de
SYN presente el nmero de secuencia es el nmero inicial de secuencia (initial
sequence number ISN)y el primer octeto de datos es ISN+1.
Nmero de Acknowledgment: 32 bits
Si el bit de control ACK est activo este campo contiene el valor del siguiente
nmero de secuencia que se espera recibir. Y una vez se ha establecido la conexin
siempre se enva.
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 ms datos por parte del emisor.
Ventana (window): 16 bits
El nmero de octetos de datos empezando por el nmero indicado en el campo de
acknowledgment que el emisor del segmento esta esperando recibir.
13
2 TCP/IP
Checksum: 16 bits
El checksum se le aplica al cuerpo del mensaje y a parte de la cabecera, que
incluye la direccin origen, la de destino, el protocolo y el tamao del TCP.
Puntero urgente: 16 bits
Este campo indica el valor del puntero urgente como un offset positivo desde el
nmero de secuencia en este segmento. Y apunta al nmero de secuencia del octeto seguido por los datos urgentes. Este campo solo es interpretado en segmentos
con el bit de control URG activa.
14
3 INTRODUCCIN A LOS FIREWALLS
3. Introduccin a los firewalls

3.1. Qu es un Firewall?
En construccin, un firewall se disea para mantener el fuego separado de una
parte de un edificio a otra. En teora, un firewall de Internet sirve con el mismo
propsito: previene de peligros de Internet a la red interna.
Todo el trfico que proviene de Internet o que sale de tu red interna pasa a
travs del firewall. Por esa razn, el firewall tiene la oportunidad de asegurarse
que ese trfico es aceptable.
Qe significa aceptable para el firewall? Significa todo aquel trfico que
se hace y que cumple con las normas de seguridad del lugar. Las polticas son
diferentes para cada uno, algunas son muy restrictivas y otras son ms abiertas.
Lgicamente hablando, un firewall, separa, restringe y analiza. Fsicamente
hablando se puede implementar de varias maneras, la mayora de veces es un
grupo de componentes hardware - un router, un ordenador, o una combinacin
de routers, ordenadores y redes con un software apropiado. Hay varias formas de
configurar los equipos; la configuracin depender de las polticas de seguridad,
del dinero disponible y de las operaciones a realizar.
Los firewalls tienen limitaciones y puntos dbiles, entonces por qu instalar
un firewall si no es invulnerable? Porque el firewall es la manera ms efectiva de
conectar una red a Internet y proteger la propia red. Internet presenta maravillosas oportunidades. Millones de personas estn intercambiando informacin. Los
beneficios son obvios: posiblidades de publicidad, servicio a cliente mejorado e
informacin en general. Los riesgos tambin deberan ser obvios tambin: cualquiera de los millones de personas puede tener intenciones maliciosas contra tu
red.
Cmo beneficiarse de las partes buenas de Internet sin saltarse lo malo? Simplemente conectando tu red con Internet y teniendo un control exhausto de que
se intercambia. Un firewall es la herramienta para hacer eso, en la mayora de
situaciones es la herramienta ms efectiva para hacerlo.
15
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 trfico de entrada y salida tiene q pasar a travs 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 polticas
Muchos de los servicios que la gente quiere de Internet son inherentemente
inseguros. Un firewall es el policia del trfico para estos servicios. Permite solo servicios aprovados para pasar a travs de l y solo aquellos que se hayan
configurardo.
Un firewall puede reforzar las polticas de seguridad aadiendo polticas ms
complejas. Por ejemplo bloqueando una transferencia de ficheros desde una parte
de nuestra red; controlando qu usuarios tienen acceso a que sistemas. Y dependiendo de la tecnologia del firewall, este puede ser mas o menos complejo para
aadir estas polticas.
3.2.3. Registrar la actividad
Como todo el trfico pasa a travs del firewall, el firewall provee un buen lugar
para recoger una coleccin de informacin 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 exposicin
Este es uno de los usos ms relevantes de los firewalls. A veces un firewall
se usa para mantener una seccin de tu red separada de otra seccin. Haciendo
esto, se mantienen los problemas que puedan impactar en una seccin separada
del resto. En estos casos, una parte de la red puede ser ms segura que otra, en
otros casos una seccin puede ser ms sensible que otra. Cualquiera que sea lar
16
3.3 Qu no puede hacer
razn de la existencia de un firewall este limita el dao que puede hacer una red a
otra.
3.3. Qu no puede hacer

Los firewalls ofrecen una excelente proteccin, pero no son la solucin nica y completa para nuestra seguridad. Ciertos procesos estan fuera del control de
nuestro firewall. Y se necesita otras mtodos para protegerse de estos sucesos incorporando otras herramientas. Es necesario conocer cuales son los puntos dbiles
de los firewalls.
3.3.1. Dentro de la red
Un firewall puede prohibir a un usuario de enviar informacin confidencial
fuera de la red a travs de la conexin a Internet. Pero el mismo usuario puede
copiar los datos en un disco, imprimirlos y llevarselos fuera del edificio en un
maletn.
Si el atacante esta dentro de la red el firewall no puede hacer nada por ti.
Dentro los usuarios pueden robar datos, daar hardware y software, modificar
programas sin siquiera pasar a travs del firewall. Es necesario protegerse con
medidas internas de seguridad.
3.3.2. Conexiones que no van a travs de l
Un firewall puede controlar el trfico que pasa a travs de l pero no puede
hacer nada con el trfico que no pasa a travs de l. Por ejemplo, si hay otra
conexin dial-in para conectarse a los sistemas detrs 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. Muchos firewalls escanean todo el trfico entrante para determinar si este esta permitido, pero el escaneo de los datos son la mayora de veces de solo las direcciones
y puertos origen y destino, no para los detalles de los datos. Incluso los firewalls
17
3.4 Tipos de Firewalls
ms sofisticados no son muy prcticos contra los viruses. Simplemente hay muchas maneras para esconder un virus entre otros datos. Determinar que existe un
virus dado un paquete que pasa a travs del firewall es muy difcil. La forma ms
prctica de defenderse de los virus es mantener un software de proteccin 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 da. Y
esta divisin se centra en la forma de tratar los datos que pasan a travs del firewall,
una de las dos formas es menos exhaustiva, pero por eso es la solucin ms barata.
El trabajo final de carrera no trata de firewalls proxy, pero estos suficientemente importantes como para comentarlos.
3.4.1. Filtrado de paquetes
Los sistemas de filtrado de paquetes enrutan paquetes entre dos redes diferentes, pero lo hacen selectivamente. Permiten o bloquean cierto tipo de paquetes en
un sentido o en el otro sentido, siguiendo las polticas de seguridad. El tipo de
router usado en un filtrado de paquetes se conoce como screening router.
Como se discute en el captulo dedicado a TCP/IP cada paquete tiene unas

18
cabeceras con cierta informacin. En esta informacin se encuentra:

1. direccin origen IP
2. direccin 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
Adems el router dispone de ms informacin del paquete que no se reflejan en el
paquete pero son igual de importante, sino ms.
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 basndonos 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 polticas, unas seria bloquear todas las conexiones provinentes de fuera de la red excepto las conexiones
SMTP para recibir correo. Bloqueando todas las conexions de sistemas que desconfias, etc
El screening router se situa entre la red interna e Internet. Esto le da una enorme responsabilidad al screening_router. No solo se encarga del rutado de los paquetes, sino que tambin se encarga de proteger el sistema. Si falla o se cae tras
un ataque, la red interna est expuesta.
Es ms 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 pasarn indistintamente del
contenido de los paquetes, ya sea maligno o no.
19
Pero como mayor ventaja es que es un tipo de proteccin ms barata, ya que

puede tratar a ms conexiones que un proxy con el mismo equipo hardware y
adems 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 travs de otra maquina
interna. Estos programas redireccionan los requests de los servicios que piden los
usuarios (como sesiones FTP o sesiones SSH), las direccionan segn las politicas
de seguridad. Los proxies reemplazan las conexiones externas y actan de gateway
a esos servicios. Por esa razn se les conoce tambin como gateways del nivel de
aplicacin.
Los sistemas proxy, permanecen ms 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.5 Arquitecturas Firewall
La transparencia es el mayor beneficio de los servicios proxy. Para el usuario,

un proxy presenta la ilusin que esta tratando directamente con el servidor real.
Para el servidor real, el proxy presenta la ilusin de que est tratando directamente
con un usuario en el ordenador del proxy, en vez de ser el autntico usuario en otro
ordenador.
Los servicios proxy son efectivos solo cuando se usan en conjuncin con algn 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 razn alguna para tener un proxy. Un proxy es una solucin
software, deben usarse conjuntamente con un firewall.
Los servidores proxy no solo redirecciona el trfico de los usuarios a los servicios externos de Internet. Los servidores proxy controlan lo que estos hacen,
porque escucha todo lo que hacen los usuarios y segn las polticas de seguridad
dejar pasar el contenido. Por ejemplo un proxy web puede bloquear todas las
pginas 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. Combinacin de tcnicas
La buena solucin es aquella que no se basa en una nica tcnica, sino aquela
que usa cuidadosamente la combinacin de varias tcnicas 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 tcnicas
tambin dependen del dinero, tiempo y experiencia de la que dispones.
Algunas protocolos se pueden tratar mejor con filtrado de paquetes como puede 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 seccin 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 ordenador 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. An siendo capaz de enrutar
paquetes IP de una a otra red, si se implementa una aquitectura Dual-Homed Host
se restringe esta funcin 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 Internet) puede comunicarse con el Dual-Homed Host, pero estos sistemas no pueden
comunicarse entre ellos. El trfico IP est completamente bloqueado. Todo trfico
hacia fuera lo debe originar el firewall.
Esta arquitectura puede proveer un gran nivel de control. Ya que todos los paquetes se originan en el firewall. Se puede asegurar adems que cualquier paquete
dentro de la red interna que tenga la direccin origen con una IP externa es origen
de algn tipo de problema de seguridad.
La nica manera que tienen la red interna de conectarse con el exterior es
atravs de servicios proxy localizados en el firewall, y atravs de este servir de
conexin. Pero presenta un inconveniente, y es que no todos los servicios pueden
22
pasarse por Proxy y lo que indica que los usuarios deberan tener cuentas de usuario en el firewall y conectarse al exterior desde l mismo. Lo que es incmodo
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
travs del bastion host que hace la funcin de proxy.
El host bastion se sita 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 travs del bastion host.
Por ello este host debe mantener un gran nivel de seguridad.
Adems el Screened Host usando el filtraje de paquetes indicar que conexiones se permiten desde la red interna al mundo externo, siguiendo las polticas de
seguridad. Algunos de los servicios externos pueden hacerse bien directamente a
traves del Screened Host o bien a travs del bastion host mediante el proxy.
Como esta arquitectura permite pasar paquetes de fuera a dentro de la red,

puede parecer ms inseguro que una arquitectura dual-homed host, que est di23
seada para que ningn paquete externo entre a la red interna. Pero en la arquitectura Screened Host es ms fcil defender el router, que provee servicios muy
limitados, comparado con el dual-homed host. Para la mayora de propsitos, 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 esta expuesta. El router tambin representa un nico punto de fallo. Por eso mismo
la siguiente arquitectura es ms popular.
3.5.3. Screened Subnet
La arquitectura Screened Subnet aade una capa de seguridad extra a la anterior arquitectura, aadiendo una red de permetro o tambin perimeter network en
ingls, que aisla la red interna de Internet. La topologia es situar un router conectado 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
mquinas ms vulnerables de la red. A pesar de todos los esfuerzos por mantenerlas protegidas, son las mquinas 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 mquinas. 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 daar 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 ms simple de crear una arquitectura Screende Subnet es conectando dos routers a la red de permetro (perimeter net). Una entre la perimeter net
y la red interna, y otro entre la perimeter net y la conexin externa (normalmente
Internet). Para romper dentro de la red interna con este tipo de arquitectura el atacante debera pasar atravs de los dos routers. Incluso si el atacante consiguiese
romper el bastion host aun le quedara pasar el router interno.
A veces para ir ms 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 permetro. Los servicios ms 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 estn 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 mayora del filtraje de paquetes. Permite que algunos servicios 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 permitir ir al host bastion son aquellos que es mejor pasarlos por el proxy. Tambin
debe limitarse las conexiones permitidas para la red interna.
3.5.4. Variaciones posibles
Se ha visto las principales configuraciones posibles, pero dependiendo del dinero disponible, las polticas de seguridad, de los intereses y servicios a dar, debemos disponer de una flexiblidad suficiente para configurar y combinar componentes 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 configuracin. Las razones pueden ser varias, para mejorar la redundancia, para mejorar
la performance del sistema o simplemente para simplificar la administracin de
cada bastion host. Tambin puede dividirse segn 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 mayora 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 fciles de proteger, ms
que los servidores, pero igualmente no son impenetrables.
27
4 FILTRADO DE PAQUETES
4. Filtrado de paquetes
4.1. Introduccin
Como he comentado en la seccin de introduccin 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 informacin que hay en la cabecera del paquete IP. La
otra, los sistemas proxy, sube hasta en nivel de aplicacin, pues debe basar sus
decisiones en la informacin que hay en los datos del nivel ms alto. El trabajo
solo aborda el primer sistema, y es por eso que se profundiza ms 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 seccin TCP/IP para enteder correctamente este apartado.
Al transferir informacin a travs de la red, la informacin esta troceada en
pequeas piezas, cada una de ellas se enva separadamente. Rompiendo la informacin 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 travs de las redes IP se
hace en forma de paquetes.
Los equipos bsicos que interconecta redes IP se llaman routers. Un router
puede ser una pieza dedicada de hardware si otro propsito, o puede ser tambin
un software que corre en un sistema de propsito general como un PC. Los paquetes 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 decidir a dnde enviarlo basndose en el destino final del paquete. En general, un
paquete no lleva ninguna otra informacin que la IP de destino para ayudar al
router a tomar su decisin. 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 segn el idioma, como por ejemplo Routing
28
4.2 Caractersticas
Information Protocol (RIP) como uno de los ms 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 direccin de destino con las entradas que dispone
en la tabla de routing y enva el paquete a travs de la interfaz que se indica en
la misma tabla. Muchas veces no hay una ruta especfica para un destino en particular, entonces el router usa la ruta por defecto o tambin default gateway que
es como yo lo conozco, y se enva a routers que estn 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
direccin destino del paquete y se pregunta a donde debo enviar este paquete?.
pero adems se considera la pregunta debo enviar este paquete? ya que o bien
por la poltica 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 opcin se usa lo que se llama filtrado
de paquetes, para la segunda opcin 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. Caractersticas
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, an
hay que tener cuidado y preocuparse por si alguien de la organizacin instala en
una nueva mquina 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 propsito, 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 paquetes, y solo cuando se situan en ciertas localizaciones de la red. Por ejemplo, es una
29
4.3 Ventajas
buena idea parar todos los paquetes que tengan como direccin de origen una IP
que pertenece a una mquina interna, porque lo ms seguro que se est intentando
un ataque spoofing. En estos ataques, un atacante pretende suplantar a otra mquina amiga o conocida ocultando su identidad. La solucin 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 opccin
de filtrado de paquetes y que est situado en el permetro de la red. Y nicamente
un router en esa loclizacin (por permetro se entiende que conecta las dos redes a
travs 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 estratgicamente situado puede
ayudar a proteger toda un red. Si slo hay un router que conecta tu red con Internet,
30
4.3 Ventajas
se gana facilidad a la hora de proteger la red, sea cual sea el tamao de la red
interna, si se hace correctamente en ese router externo que da conexin a Internet.
4.3.2. Transparencia
Como diferencia al proxy, los sistemas con filtrado de paquetes no requieren
ningn tipo de software ni configuracin en las mquinas de los clientes, no requiere ningn tipo de enseanza ni explicacin a los usuarios. Cuando un router
con filtrado de paquetes decide lanzar un paquete, este no se distinge de otro router
normal sin esa aplicacin. Los usuarios no sabrn que existe, a no ser que intenten hacer algo que est prohibido (supuestamente por un problema de seguridad)
segn la poltica de seguridad que se le aplique al router con filtrado de paquetes.
Esta transparencia significa que un router filtrando paquetes puede hacerse
sin la cooperacin y sin el conocimiento de los usuarios a los que se les da el
servicio de conexin. 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 ensearles 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 an as no siempre funciona.
4.3.3. Disponibilidad
El filtrado de paquetes est disponible en la mayora de hardware y software de
los productos que hacen routing, ambos tanto comerciales como los distribuidos
gratuitamente. La mayora de routers tambin tienen capacidades de filtrado de
paquetes.
Es una ventaja pues tras disear una poltica 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. Adems las decisiones se
31
4.4 Desventajas
toman segn una pequea 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 caractersticas de los sistemas de filtrado de paquetes encontramos tambin desventajas, y entre todas ellas tenemos que:
4.4.1. Protocolos difciles
Aunque la implementacin de las polticas de seguridad sean perfectas, encontramos 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 conexin, los protocolos
basados en RPC como por ejemplo NFS y NIS/YP tampoco son fciles de tratar.
Ciertos protocolos, como por ejemplo FTP, H323 entre otros mantienen en sus
conexiones unas sesiones caractersticas 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 peticin el servidor enva los datos
mediante UDP saliendo del puerto 20. Estos datos lo ms 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 usara. La solucin pasa por tener unas tablas
indicando las sesiones que estn en funcionamiento, y cuando se detecte un paquete 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 conexin FTP que ha inciado
alguien dentro de la red que se est protegiendo.
32
4.5 Configuracin
4.4.2. Poltcas que no pueden aplicarse

La informacin que un paquete da al router que filtra los paquetes no es suficiente para segn que poltica de seguridad. Por ejemplo, los paquetes indican
de que ordenador provienen pero no de que usuario. Por eso, no se pueden hacer restricciones en usuarios especficos, sino que a las mquinas que estos usan
normalmente. De igual forma, los paquetes dicen a que puerto van pero no a qu
aplicacin, cuando se hacen restricciones por portocolo se hacen por el nmero
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 organizacin que tengan
control sobre sus mquinas pueden hacer cambios en este sentido de un manera
fcil.
4.4.3. Spoofing
Ya he nombrado antes los ataques spoofing, los nmeros IP del origen pueden
modificarse y para asegurarse de que el emisor es quien dices ser tiene que usarse
otras tcnicas, 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 IPs de las dos partes para crear una sesin.
4.5. Configuracin
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.5 Configuracin
y seguir un conjunto de reglas. A continuacin 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 mayora son bidireccionales; casi siempre son las dos
partes las que envan datos, una enviando un comando o una peticin, y la otra
parte enviando la respuesta del comando o retornando otros datos. Cuando se planea crear las reglas para el filtrado de paquetes es necesario recordad que los paquetes tienen doble sentido. Por ejemplo, no tienen ningn 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 conexin. 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 respuestas pueden ser predecidas, y permite a los atacantes mantener una conversacin
sin necesitar ver las respuestas. Por ejemplo, si las respuestas son predecibles, pero 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 trfico entrante, inbound, y outbound significa trfico saliente
o hacia fuera. Cuando se planea una estrategia de filtrado de paquetes, se necesita 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 servicios 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 mayora de la gente piense habitualmente en trminos de ser34
4.6 Que hacer
vicios, hay que pensar claramente en trminos de paquetes cuando se trata con el
filtrado de paquetes. Cuando se habla de filtrado de paquetes, lo ms importante
es la direccin 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 polticas de seguridad con una regla de negado por defecto (todo
aquello que no se expresa especficamente que est permitido se niega) o bien la
regla de permitir por defecto (todo aquello que no se especifica especficamente
como prohibido se permite). Desde el punto de vista de seguridad, es mucho ms
seguro tomar la actitud de que las cosas estn negadas por defecto. Y las reglas
de configuracin deben reflejarlos. Es necesario empezar por la posicin de negar
todo y despus poner las reglas que permitan solo los protocolos que se permiten,
entender las implicaciones que tiene en la seguridad es sumamente importante.
La posicin de negarlo todo por defecto es mucho ms segura y mucho ms
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 aproximacin, nunca se sabe todos los posibles problemas,
porque siempre aparece nuevos problemas y por lo tanto nunca se completa el
trabajo.
Hablando de manera prctica, la negacin de todo significa que las reglas de
filtrado deben ser una lista pequea 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 paquete, qu hacer con el paquete? Principalmente hay dos opciones siempre basndose en el las reglas de configuracin:
1. Pasar el paquete. Si el paquete pasa el criterio de filtrado, el router pasar
35
4.6 Que hacer
el paquete all donde indique la tabla de routing, que la direccin que debe
seguir, como si fuera un router normal sin el filtrado de paquetes comportndose de manera transparente.
2. Eliminar el paquete. La otra accin 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 bsicas 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 administrador que se guarde la accin 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 fcilmente se sobresaturaran los discos adems de
relentizar de manera drstica 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 conexin haca un servicio Telnet de un router
especfico, as se guarda las conexiones que se hayan realizado para una posible
configuracin. Aunque no todos las aplicaciones comerciales y no comerciales de
filtrado de paquetes dejan hacer un log a los paquetes permitidos en mi aplicacin
s se puede.
Dependiendo de la implementacin del filtrado de paquetes hay diferentes formas de hacer log. Algunos guardarn solo la informacin especfica sobre el paquete, otros en cambio guardarn el paquete entero para un posterior estudio. Generalmente, el filtrado de paqutes necesitar configurarse para hacer el log a otra
parte mediante el servicio de syslog, que es independiente a la aplicacin. Porque
es interesante no tener nicamente una copia de la provinencia de un ataque si el
firewall se ha visto comprometido, pues es fcil eliminarlo y parecer que no ha
habido tal ataque.
36
4.6 Que hacer
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 trfico de la red y algo de tiempo al usuario que le ha sido
negado el acceso, ya que al recibir un cdigo 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 cdigos ICMP a escoger:
1. Los cdigos de destino inalcanzable o destination unreachable en particular el de ordenador inalcanzable o host unreachable y el cdigo de
red inalcanzable o network unreachable segn el idioma. Los diseadores del primer grupo de cdigos de error ICMP disearon este grupo de host
unreachable y el de network unreachable, para indicar algn problema serio 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 errores en paquetes ICMP desde el router que haya descubierto el problema. Si
cualquier mquina recibe un host unreachable para un host dado, asumir 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 cdigos de destino administrativamene inalcanzable o destination administratively unreachable en particular dentro de este grupo el de ordenador administrativamente inalcanzable o en ingls host administratively
unreachable y el cdigo 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 ningn paquete debido a la configuracin del sistema y que
todo paquete a ese destino se ha bloqueado. Este segundo grupo de errores que pueden retornar un administrativamente inalcanzable se aadieron
37
4.6 Que hacer
hace unos aos al grupo de mensajes ICMP, especficamente para dar a los
sistemas de filtrado de paquetes algo que poder retornar cuando eliminaban
un paquete. Muchos sistemas pueden no reconocer estos cdigos, aunque
tampoco deben causar ningn problema, porque los sistemas que reciben
un cdigo que no entienden simplemente deben ignorarlo, que significa que
es como si no se hubiera enviado ningn mensaje. Pero que no haga caso al
mensaje es til de manera que al recibir este mensaje el sistema no se ver
afectado.
Cal 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
tcnicamente incorrecto, recordar que los hosts puede o puede que no sean alcanzables, de acuerdo con la poltica de filtrado de paquetes, dependiendo a qu host
est intentando acceder y a qu servicio. Tambin hay que recordar que este tipo
de cdigos pueden causar en muchos sistemas una reaccin excesiva, como por
ejemplo cerrando todas las conexciones que ya estn abiertas hacia ese host o red
en cuestin.
Si devolvemos un host administratively unreachable o un network administratively unreachable se advierte que el paquete que est siendo filtrado al destino
desde ese origen. Estos cdigos tericamente, no deberan de tener una respuesta
excesiva al llegar al ordenardor que intentaba originar la conexin.
Hay otras consideraciones, por ejemplo, generando y retornando cdigos de
error ICMP necesita un cierto tiempo y esfuerzo por parte del router o firewall
con el software de filtrado de paquetes. Un atacante podra montarse un ataque de
denegacin de servicio o denial of service segn se diga, saturando el router con
paquetes que debera rechazar, generando paquetes con cdigos 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 cuestin, y mientras est generando
paquetes ICMP no est tratando paquetes entrantes. Por otra parte si no se retorna
cdigos de error ICMP puede causar un exceso de trfico en la red, pues el emisor
puede intentar e intentar enviar paquetes que han sido eliminados. Este trfico no
debera de ser mucho, pues el nmero de paquetes bloqueados por el sistema de
filtrado tiende a ser una fraccin del total de paquetes procesados. En caso de no
38
4.7 Filtrado por direccin
ser as es muy posible que se est bajo un ataque de DoS o denegacin de servicio.
Por otra parte, retornando paquetes con cdigos de error ICMP para cada paquete que viola las polticas de filtrado, ests dando informacin 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 polticas de seguridad. En tales casos no se debera dar esa informacin,
porque simplifica enormemente el trabajo del atacante. El atacnte conoce que paquetes 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 informacin con los cdigos de error ICMP el atacante necesita ms tiempo
para averiguar la misma informacin, si acaso lo consigue. Devolviendo los cdigos de error ICMP se acelera los ataques, si reciben errores ICMP por algo no
tienen q esperar el timeout.
Como conclusin, lo ms seguro parece que es no retornar ningn cdigo de
error ICMP a los paquetes eliminados. Si se puede lo que es interesante es poder
retornar paqutes con cdigos de error ICMP a los sistemas internos, para que no
esperen al timeout y por otra parte no retornarlo a los sitemas externos. An 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 cdigos
de error ICMP.
4.7. Filtrado por direccin

4.7.1. Introduccin
La forma ms simple, aunque no la ms comn, es el filtrado de paquetes
filtrando segn la direccin. Filtrando de esta forma termite restringir el flujo de
paquetes basado en la direccin 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 direccin origen que sea igual a una direccin vlida dentro de la red a
proteger.
39
Por ejemplo vamos a decir que se quieren prohibir este tipo de ataques, se
debera especificar esta regla:
Direccin
Inbound
@ origen
interna
@ destino
any
Accin
deny
Donde pone que la direccin es interna se refiere a cualquier nmero IP de algn

host de dentro de la red. En el router que haya entre la red interna e Internet, se
podra 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 algn tipo de autentificacin criptogrfica entre t y el host al que se quiere
hablar, no sabes si el que te est hablando es quien dice ser u otra mquina que
pretende ser ese. Como he dicho antes hay que montarse algo usar otras tcnicas,
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 IPs de las dos partes para crear una sesin, 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 direccin 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 ms conocidos. El atacante enva paquetes que pretenden suplantar la
identidad de algn ordenador al que se le tiene algn 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 ningn paquete de la mquina
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 informacin. 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 enviarn al
ordenador suplantado y no al atacante. Tambin hay que tener una consideracin,
que el ordenador suplantado recibir paquetes de conexiones que no entiende y
de las que no participa, bogus connections como se le llama en ingls, entonces
este ordenador enva paquetes con el bit de reset activado para terminar dichas
conexiones. Lo que es malo para el atacante, pero es fcil de remediar, ya que
se puede suplantar una mquina que no exista, destrozando a la mquina real
mediante un ataque, inundando a la mquina suplantada, modificando la ruta entre
la mquina 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. Introduccin
5.1.1. Historia
A finales de los 40s el uso de computadoras estaba restringido a aquellas empresas o instituciones que podan pagar su alto precio, y no existan los sistemas
operativos. En su lugar, el programador deba tener un conocimiento y contacto
profundo con el hardware, y en el infortunado caso de que su programa fallara, deba examinar los valores de los registros y pneles de luces indicadoras del estado
de la computadora para determinar la causa del fallo y poder corregir su programa, adems 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 histricamente desde los 50s,
cuando se hizo evidente que el operar una computadora por medio de tableros
enchufables en la primera generacin y luego por medio del trabajo en lote en
la segunda generacin se poda mejorar notoriamente, pues el operador realizaba
siempre una secuencia de pasos repetitivos, lo cual es una de las caractersticas
contempladas en la definicin de lo que es un programa. Es decir, se comenz a
ver que las tareas mismas del operador podan plasmarse en un programa, el cual
a travs 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 generacin de computadoras nace uno de los
primeros sistemas operativos con la filosofa de administrar una familia de computadoras: 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 propsitos en general: el
comercial y el cientfico. As, al tratar de crear un solo sistema operativo para
computadoras que podan dedicarse a un propsito, al otro o ambos, puso en evidencia la problemtica del trabajo en equipos de anlisis, diseo e implantacin
42
5.1 Introduccin
de sistemas grandes. El resultado fue un sistema del cual uno de sus mismos diseadores patentiz su opinin en la portada de un libro: una horda de bestias
prehistricas atascadas en un foso de brea.
Surge tambin en la tercera generacin de computadoras el concepto de la
multiprogramacin, porque debido al alto costo de las computadoras era necesario
idear un esquema de trabajo que mantuviese a la unidad central de procesamiento
ms 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 generacin siguieron siendo
bsicamente sistemas de lote.
En la cuarta generacin la electrnica avanza hacia la integracin a gran escala, pudiendo crear circuitos con miles de transistores en un centmetro 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
pblico en general al uso de las computadoras como herramientas cotidianas. Se
hacen populares el MS-DOS y UNIX en estas mquinas. Tambin es comn encontrar clones de computadoras personales y una multitud de empresas pequeas
ensamblndolas por todo el mundo.
Para mediados de los 80s, 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
90s el paradigma de la programacin 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 especfica y poder ver sus resultados en
la pantalla o monitor de otra diferente (por ejemplo, ejecutar una simulacin en
una mquina con UNIX y ver los resultados en otra con DOS ). Los niveles de
interaccin se van haciendo cada vez ms profundos.
LINUX hace su aparicion a principios de la decada de los noventa, era el
ao 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 llegara este proyecto, a programar las primeras lneas de cdigo
43
5.1 Introduccin
de este sistema operativo llamado LINUX.

Aqu est el primer mensaje que Linus Torvalds mand al grupo de noticias
comp.os.minix:
From:torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)

Newsgroup: comp.os.minix
Subject: GCC-1.40 and a posix question
Message-ID: 1991Jul13, 100050.9886@klaava.Helsinki.FI
Date: 3 Jul 91 10:00:50 GMT
Hello netlanders,
Due a project Im working on (in minix), Im 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 torvalds@kruuna.helsinki.fi
Y aqu el que le sigui, este mensaje es considerado por muchos como el comienzo
de Linux:
From:torvalds@klaava.Helsinki.FI (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, 20578.9541@klaava.Helsinki.FI
Date: 25 Aug 91 20:57:08 GMT
Organization: University of Helsinki.
Hello everybody out there using minixIm doing a (free) operating system (just a hobby, wont
be big and professional like gnu) for 386(486) AT clones.
This has been brewing since april, and is starting to get ready.
Id like any feedback on things people like/dislike in minix;
as my OS resembles it somewhat (same physical layout of the
44
5.1 Introduccin
file-sytem due to practical reasons) among other things.

Ive currently ported bash (1.08) an gcc (1.40), and things seem to work.
This implies that ill get something practical within a few months,
and Id like to know what features most people want. Any suggestions are we
but I wont promise Ill implement them :-)
Linux Torvalds torvalds@kruuna.helsinki.fi
Este comienzo estuvo inspirado en MINIX, un pequeo 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 pequeo sistema Unix para usuarios de Minix que queran ms.
Linus nunca anunci la version 0.01 de Linux (agosto 1991), esta versin no
era ni siquiera ejecutable, solamente inclua los principios del ncleo del sistema,
estaba escrita en lenguaje ensamblador y asuma que uno tena acceso a un sistema
Minix para su compilacin.
El 5 de octubre de 1991, Linus anunci la primera versin "Oficial" de Linux,
-version 0.02. Con esta versin Linus pudo ejecutar Bash (GNU Bourne Again
Shell) y gcc (El compilador GNU de C) pero no funcionaba mucho ms. En este
estado de desarrollo ni se pensaba en los trminos soporte, documentacin, distribucin, etc.
Despus de la versin 0.03, Linus salt en la numeracin hasta la 0.10, ms y
ms programadores a lo largo y ancho de Internet empezaron a trabajar en el proyecto y despus de sucesivas revisiones, Linus increment el nmero de versin
hasta la 0.95 (Marzo 1992). Ms de un ao despus (diciembre 1993) el ncleo
del sistema estaba en la versin 0.99 y la versin 1.0 no lleg hasta el 14 de marzo
de 1994.
La serie actual del ncleo es la 2.4.x y sigue avanzando da a da con la meta
de perfeccionar y mejorar el sistema. En el momento de escribir este documento
la versin actual del kernel es la 2.4.19.
5.1.2. Linux
En la pgina web del kernel de Linux (www.kernel.org) se encuentra esta descripcin, que creo que explica en pocas palabras qu es Linux.
45
5.1 Introduccin
< <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, including 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). These days it also runs on (at least) the Compaq Alpha AXP, Sun SPARC and UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, IBM
S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64 and CRIS architectures.
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. Caractersticas
Esta es una lista de las principales caractersticas que tiene Linux:
1. Todo el cdigo fuente est disponible, incluyendo el ncleo completo y todos los drivers, las herramientas de desarrollo y todos los programas de
usuario; adems todo ello se puede distribuir libremente. Hay algunos programas comerciales que estn siendo ofrecidos para Linux actualmente sin
cdigo 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 preeventiva, la cual asegura que todos los programas que se estn utilizando en un
momento dado sern 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 mquina al
mismo tiempo, pero a cada uno de ellos le da la sensacin de tener la mquina para ellos nicamente.
46
5.1 Introduccin
4. Multiplataforma: Las plataformas en las que en un principio se dise utilizar Linux son 386-, 486-. pero luego vinieron toda la familia Pentium y
seguidores que pertenecen a la familia i386 que son PCs de 32 bits, Amiga
y Atari, tambin 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 ms.
5. Multiprocesador: Soporte para sistemas con ms de un procesador est disponible para Intel y SPARC.
6. Funciona en modo protegido.
7. Tiene proteccin de la memoria entre procesos, de manera que uno de ellos
no pueda colgar el sistema.
8. Carga de ejecutables por demanda: Linux slo lee del disco aquellas partes
de un programa que estn siendo usadas actualmente.
9. Poltica de copia en escritura para la comparticin de pginas entre ejecutables: esto significa que varios procesos pueden usar la misma zona de
memoria para ejecutarse. Cuando alguno intenta escribir en esa memoria,
la pgina (4Kb de memoria) se copia a otro lugar. Esta poltica de copia
en escritura tiene dos beneficios: aumenta la velocidad y reduce el uso de
memoria.
10. Memoria virtual usando paginacin (sin intercambio de procesos completos) a disco: A una particin o un archivo en el sistema de archivos, o ambos,
con la posibilidad de aadir ms reas de intercambio sobre la marcha. Un
total de 16 zonas de intercambio de 128Mb de tamao mximo pueden ser
usadas en un momento dado con un lmite terico de 2Gb para intercambio.
Este lmite se puede aumentar con el cambio de unas cuantas lneas en el
cdigo fuente, que lo est haciendo Oracle, para su distribucin.
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
5.1 Introduccin
12. Libreras compartidas de carga dinmica (como los ficheros so de Solaris o

los ficheros DLLs de windows) y libreras estticas.
13. Se realizan volcados de estado (core dumps) para posibilitar los anlisis
post-mortem, permitiendo el uso de depuradores sobre los programas no
slo en ejecucin sino tambin tras abortar stos por cualquier motivo.
14. Compatible con POSIX, System V y BSD a nivel fuente. Control de tareas
POSIX.
15. Emulacin de iBCS2, casi completamente compatible con SCO, SVR3 y
SVR4 a nivel binario.
16. Emulacin de 386 en el ncleo, de tal forma que los programas no tengan
que hacer su propia emulacin matemtica. Cualquier mquina que ejecute Linux parecer dotada de coprocesador matemtico. Por supuesto, si el
ordenador ya tiene una FPU (unidad de coma flotante), esta ser usada en
lugar de la emulacin, pudiendo incluso compilar tu propio kernel sin la
emulacin matemtica y conseguir un pequeo ahorro de memoria.
17. Soporte para muchos teclados nacionales o adaptados y es bastante fcil
aadir nuevos dinmicamente.
18. Consolas virtuales mltiples: varias sesiones de login a travs de la consola
entre las que se puede cambiar con las combinaciones adecuadas de teclas
(totalmente independiente del hardware de video). Se crean dinmicamente
y puedes tener hasta 64. Dispone tambin de Pseudo-terminales (ptys).
19. Soporte para varios sistemas de archivo comunes, incluyendo minix-1, Xenix y todos los sistemas de archivo tpicos 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 ms comunes. Acceso transparente a particiones MS-DOS (o a particiones OS/2 FAT) mediante
un sistema de archivos especial: no es necesario ningn comando especial
para usar la particin MS-DOS, esta parece un sistema de archivos normal
48
5.1 Introduccin
de Unix (excepto por algunas restricciones en los nombres de archivo y permisos). 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 ltimo solo en modo lectura, se puede hacer escrituras pero no es recomendado.
Tambin dispone de un sistema de archivos especial llamado UMSDOS que
permite que Linux sea instalado en un sistema de archivos DOS. Soporte en
slo lectura de HPFS-2 del OS/2 2. Sistema de archivos de CD-ROM que
lee todos los formatos estndar de CD-ROM.
20. Incluidas en el ncleo tenemos una gran cantidad de protocolos de red como
por ejemplo: TCP/IP tanto IPversion 4 como IPversion6. Appletalk compatible 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 (transferencia 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 Microsoft 1
con funciones de servidor como funciones de cliente.
22. Sistemas de multicomputacin. 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 comunidad de Internet y empresas como Oracle, Sun Microsystems, IBM, CompaqHP, Dell etc a parte de las propias empresas de cada distribucin 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 travs de Internet distribuidos gratuitamente o con licencias de libre distribucin. Visitando pginas web se
1 Microsoft
es marca registrada de Microsoft Corporation
49
5.2 El Kernel
pueden encontrar miles de aplicaciones que ya estn hechas y al disponer del cdigo fuente pueden mejorarlas. Tambin existe una gran comunidad que resuelve
cualquier problema que pueda surgir al kernel. Las respuestas a los problemas de
seguridad han demostrado ser ms rpidas que muchas empresas.
5.2. El Kernel
5.2.1. Introduccin
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 programacin a bajo nivel (por ejemplo tratando las interrupciones hardware).
2. Proveer un entorno a los procesos, que son las instancias en ejecucin de
los programas o threads.
Se dice que el kernel de Linux es monoltico, que es como un gran ejecutable, que
consiste de muchos componentes divididos lgicamente.
5.2.2. Modos
El Kernel puede trabajar en dos modos: usuario o kernel. La mayora de las
ejecuciones de programas de los usuarios se hacen en modo usuario o user mode
como se dice en ingls. Este modo de ejecucin 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 cuando una funcin de una libreria hace una peticin al kernel.
2. Una seal de excepcin provinente de la CPU, que son condiciones que
requieren especial atencin, por ejemplo en una divisin por cero.
50
5.2 El Kernel
3. Una interrupcin que se hace hacia la CPU provinente de algn equipo hardware indicando que requiere su atencin, como por ejemplo cada vez que
apretamos cualquier tecla desde el teclado.
El kernel se pasa la mayora del tiempo en el modo kernel ejecutndose detrs
de los procesos de usuario. Adems hay muchos threads que se estn ejecutando
detrs 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. Mdulos
El kernel es capaz de cargar dinmicamente porciones adicionales de cdigo
(mdulos) mientras se est ejecutando, para mejorar su funcionalidad. Por ejemplo, hay mdulos que pueden aadir soporte para sistemas de ficheros que no es
necesario que estn cargados siempre. Cuando la funcionalidad proveida por el
mdulo ya no se necesita ms, el mdulo puede ser descargado, liberando memoria.
5.2.4. Procesos
Un proceso es una instancia de un programa en ejecucin. Cada proceso tiene:
1. Un estado, ya sea running (ejecutndose en el procesador), sleeping (durmiendo, un proceso que est esperado que un evento se termine), runnable
o ready (listo para ser ejecutado y esperado en la cola de procesos), stopped (parado ya sea por una seal de control o porque estn 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 propsito 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 informacin relacionada con un proceso.
51
5.2 El Kernel
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 estn en la cola de procesos esperando tendrn 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 ejecutndose (una foto del estado de la CPU en ese momento)
y cargar el contexto de algn 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 porcin asignada del total de memoria disponible. Espacios de usuario (o partes de l)
pueden compartirse entre procesos si se pide, o bien automticamente si el kernel
lo cree apropiado. La separacin del espacio de direcciones hace que un proceso
no pueda interferir con una operacin de otro proceso o del sistema operativo.
Adems de los procesos normales de usuario ejecutndose en el sistema, hay
varios threads del kernel que se crean al iniciar el sistema y que corren permanentemente en modo kernel, encargandose de funciones de mantenimiento del kernel.
5.2.5. Sincronizacin
El kernel es reentrante, varios procesos pueden estar ejecutndose 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 estn bloqueados esperando en una
cola. Ejemplo: un proceso pide leer un fichero, el sistema virtual de ficheros el
Virtual File System traduce la peticin en una operacin de bajo nivel del disco
y lo pasa al controlador del disco, por detrs del proceso. En vez de esperar hasta
que la operacin de escritura a disco se haya completado, miles de ciclos de CPU
52
5.2 El Kernel
ms tarde, el proceso da voluntariamente a la CPU despus de hacer la peticin

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 operacin a disco se a
completado (sealado por una interrupcin 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 haba 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 voluntariamente la CPU, dejando las estructuras de datos en un estado consistente, de ah que se le llame al kernel non-preemptive.
2. Hay que deshabilitar las interrupciones en regiones crticas, donde el cdigo
tiene que completarse sin ninguna interrupcin, y asegurarse luego de volver
a habilitarlas.
3. El uso de spin locks y semforos de control para acceder a estructuras de
datos.
Los semforos consisten en un contador inicializado a uno, una lista de procesos
esperando para acceder a la estructura de datos y dos mtodos atmicos llamados up() y down() que incrementan y decrementean el contador respectivamente.
Cuando se accede a una estructura protegida por un semforo, se llama a la funcin down(), si el valor del contador es cero o positivo (no negativo vaya), entonces el acceso est garantizado, si no es as y el acceso esta negado significa
que est bloqueado y que el proceso se aade a la lista del semforo de procesos
esperando. De forma parecida, cuando un proceso ha terminado de tratar los datos
de la estructura, llama a la funcin 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
5.2 El Kernel
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 jams lo harn. Si se
quiere profundizar en deadlocks buscar por Internet el problema de los filsofos
que cenan o dicho en ingls The dining Philosophers Problem o en cualquier
libro de sistemas operativos.
5.2.6. Comunicacin entre procesos
Una seal es un mensaje corto, enviado entre dos procesos o entre el kernel
y un proceso. Hay dos dipos de seales que se usan para notificar eventos a del
sistema a los procesos:
Eventos asncronos. Por ejemplo SIGTERM, enviado cuando se usa el Ctrl-C del
teclado.
Errores o excepciones sncronas. Por ejemplo SIGSEGV cuando un proceso intenta acceder a una direccin ilegal.
Hay cerca de 20 seales diferentes definidas en el estandart POSIX, algunas de
ellas pueden ser ignoradas. Algunas seales no pueden ser ignoradas y no son
tratadas siquiera por el proceso mismo. Linux usa el sistema V o System V
de comunicacin entre procesos llamado en ingls Inter-Process-Comunication
(IPC).
5.2.7. Control de la Memoria
Linux usa memoria virtual, un nivel de abstraccin entre los pedidos de memoria por parte de los procesos y las direcciones fsicas 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 fsica disponible.
2. Hace posible tambin un espacio de direcciones contigua, independiente a
la organizacion de la memoria fsica.
54
5.2 El Kernel
3. Paginado, porciones de datos o cdigo que solo necesitan cargarse en memoria cuando se ejecutan o son accedidos y pueden intercambiarse a disco
cuando no son necesarios.
4. Imgenes compartidas de programas y librerias, haciendo un uso ms eficiente de la memoria.
5. Recolocacin de los programas en memoria de forma completamente transparente.
El espacio de direcciones se divide en porciones de 4kBytes llamadas pginas, las
cuales forman la unidad bsica 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 pginas disponibles se guardan en la RAM a la
vez. An as, un pgina 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 pgina puede volver a ponerse en cualquier pgina fsica, el
kernel tiene que llevar el control de donde estan las pginas usadas. Y adems
hacer la conversin de direcciones lgicas en direcciones fsicas.
En el hardware Intel x86, Linux usa dos nivels de paginacin (aunque internamete usa tres niveles para mejorar la portabilidad) para reducir la cantidad de
memoria usado pora las tablas de paginacin. Para convertir una direccin lgica
en una fsica, las tablas se consultan en este orden: Page Global Directory luego
la Page Table para conseguir el nmero de pgina y el offset de la pgina. Por eso
una direccin lgica se divide en tres partes: Directorio, Tabla y Offset. Como se
puede direccionar un espacio de 4GBytes (usando 32 bits) y se usa una pgina del
tamao de 4kB, los 10 bits ms significativos de la direccin apuntan al directorio,
los 10 siguientes bits apuntan a la tabla (de ah que se requiera identificar la pgina) y los 12 siguientes bits, los menos significativos, nos marcan el offset dentro
de la pgina.
5.2.8. El cdigo
El cdigo fuente del kernel est hecho de alrededor de dos millones de lneas
de cdigo. Puede parecer muy intimidatorio, pero es importante recordar que muy
55
5.2 El Kernel
poca gente entiende todos los subsitemas y el cdigo asociados a ellos en profundidad. Se puede mejorar la productividad simplemente sabiendo donde buscar el
cdigo especfico. Paso a comentar qu se puede encontrar en el cdigo fuente y
donde va cada cosa.
Para empezar es necesario bajarse la ltima versin del kernel de http://www.kernel.org
la versin actual es la 2.14.19. Pero es recomendable visitar la pgina 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
-rw-r--r--rw-r--r-drwxr-xr-x
1 carlosm
1 carlosm
28 carlosm
grp
grp
grp
18691 Aug 3 02:39 COPYING

79410 Aug 3 02:39 CREDITS
4096 Feb 25 19:41 Documentation/
drwxr-xr-x
drwxr-xr-x
39 carlosm
45 carlosm
grp
grp
4096 Feb 25
4096 Feb 25
drwxr-xr-x
drwxr-xr-x
drwxr-xr-x
25 carlosm
2 carlosm
2 carlosm
grp
grp
grp
4096 Aug 3 02:39 include/

4096 Feb 25 2002 init/
4096 Dec 21 2001 ipc/
drwxr-xr-x
drwxr-xr-x
-rw-r--r--
2 carlosm
2 carlosm
1 carlosm
grp
grp
grp
4096 Feb 25 2002 kernel/

4096 Nov 22 2001 lib/
41643 Aug 3 02:39 MAINTAINERS
-rw-r--r-drwxr-xr-x
1 carlosm
2 carlosm
grp
grp
18710 Aug 3 02:39 Makefile

4096 Feb 25 2002 mm/
drwxr-xr-x
-rw-r--r--rw-r--r--
28 carlosm
1 carlosm
1 carlosm
grp
grp
grp
4096 Feb 25 2002 net/

14239 Aug 3 02:39 README
2815 Apr 6 2001 REPORTING-BUGS
56
3 02:39 arch/
2002 drivers/
2002 fs/

-rw-r--r-drwxr-xr-x
1 carlosm
4 carlosm
grp
grp
5.2 El Kernel
9291 Aug
4096 Aug
3 02:39 Rules.make
3 02:39 scripts/
Todo este enjambre de ficheros est organizado lgicamente en una estructura de

directorios.
Documentation: Informacin sobre plataformas y devices especficos igual que
informacin general sobre el kernel.
arch: Cdigo especfico para cada arquitectura: i386, sparc, alpha, arm, cris, ia64,
mips, mips64, parsic, ppc (PowerPC 32bits), ppc64(PowerPC 64bits), s390,
s390x, sparc, sparc64.
drivers: Cdigo para cada device especfico: tarjeta de sonido, tarjeta ethernet,
etc
fs: Cdigo 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 funcin.
init: Todo el cdigo asociado con el proceso de arranque e inicializacin.
IPC: Cdigo de la comunicacin entre procesos o Inter Process Communication:
implementacin de la memoria compartida, etc
kernel: El cdigo del ncleo del kernel, la parte ms importante de Linux son solo 396KBytes y 31 ficheros: scheduling, seales, printk, fork, softirq, contextos, tiempo, cargador de mdulos, etc
lib: Libreras relacionadas con el kernel, por ejemplo descompresin de la imagen del kernel, funciones de lock, etc
mm: Memory Managment todos los ficheros con el cdigo de trato de memoria.
net: Todo el cdigo 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
5.2 El Kernel
El mejor lugar para empezar leyendo el cdigo 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 intencin es construir un firewall, cada uno tendr sus motivos.
Si por ejemplo, se desea escribir un driver para un hardware que todava no
est soportado, en ese caso se empieza leyendo el cdigo para los drivers ms
parecidos que ya estn implementados. Dicen los hackers del kernel que la mejor
forma de introducirse a la programacin 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 programacin dentro del kernel haced lo
que yo hice que fue probando en la inicializacin del sistema, en init/main.c, especficamente en la funcin start_kernel() o bien ojeando los ficheros que hay en
el directorio kernel.
5.2.9. Numeracin
Si se desea hacer cambios e introducir cdigo 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 nmero de versin con tericamente casi ningn
bug para ser arreglado o ninguna mejora para hacer. La mayora de distribuciones
usan estas series, y si no se quiere uno aventurar encontrando bugs y fallos es recomendable usar estas releases para trabajar. Las peores series que hay se marcan
con una extensin de -dontuse (dont use: no usar) en el nombre del fichero. Estas son por ejemplo las 2.0, 2.2.x y las 2.4.x que son nmeros pares y a medida
que van saliendo nuevas versiones se va aumentando el nmero 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 ltima versin estable del kernel de Linux es la 2.4.19, la anterior fue la 2.4.18 y la
58
5.2 El Kernel
siguiente a la actual se supone ser la 2.4.20, que hasta que salga esta van apareciendo unos prepatchs que muestra las actualizaciones, que se llaman los parches
intermedios, que normalmente se le aade -pre ms el nmero de versin del
prepatch.
Series inestables
Los kernels inestables contienen menos cdigo probado y los cambios entre
las series son ms grandes. Sirven para provar los nuevos drivers, las mejoras
experimentales y los algoritmos ms inovadores. La ltima versin 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 produccin. 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 intermedias que intentan testear un pequeo nmero de cambios a la vez. Estas releases
tienen o bien la extensin -preXX o bien la extensin -YYXX, donde XX es el
nmero de la versin incrementada y el YY son las iniciales de quien lo mantiene,
por ejemplo -ac12 indica incrementalmente la extensin de Alan Cox. Al parche
intermedio actual est numerado como 2.4.20-pre7.
5.2.10. Compilacin del ncleo
Si se va a modificar el ncleo es necesario luego compilarlo e instalarlo en
la mquina. Al hacer el firewall, cada vez que modificaba cualquier cosa tambin
tena que compilar e instalarlo, as que es una parte importante del proceso.
No es necesario compilar el ncleo en la misma mquina en la que va a correr
el kernel, yo lo que hago personalmente es que de todas las mquinas que tengo
la ms rpida es la encargada de hacer la compilacin, y luego se pasa la imagen
al ordenador.
Es recomendable descomprimir el kernel en el directorio /usr/src y tener cada
versin en su directorio de forma ordenada. por regla general se pone la versin
59
5.2 El Kernel
actual, la que va a correr en el sistema, en el directorio /usr/src/linux. Pero es solo

una recomendacin, no es necesario que sea as.
En el caso de ser una versin nueva, sin haberse compilado ninguna vez, no
es necesario hacer un make clean, para ms adelante antes de hacer nada es
recomendable hacerselo, as se elimina cdigo compilado que puede molestar.
Vayamos a la compilacin: Primero descompilar el kernel.
tar xvzf lnux-x.y.z.tar.gz
El x.y.z corresponde a la versin actual del kernel, que corresponde al fichero
bajado. En caso de tener la extensin .bz2 es necesario descomprimirlo primero y
luego hacerle un tar mediante la orden siguiente:
bz2cat linux-x.y.z.tar.bz2 | tar xvf Despus de bajarse la ltima versin 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 mdulos, 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 opcin.
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
5.2 El Kernel
o bien con un n, la primera es para aceptar esa parte de cdigo y la segunda

para no incluirlo. Puede haber en el caso de los drivers por ejemplo, una tercera
opcin m que significa module y es para compilar el mdulo pero no se incluye
directamente en el kernel, sino que como un mdulo cargable. Es como decir
quizs 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 informacin
ms detallada de cada grupo de opciones leer el Kernel-HOWTO, donde aparece
mucho ms detallado.
Cuando se termina de configurar, se preparar las dependencias en poco tiempo, a menos que su PC sea muy lento. Tambin ser necesario hacer un make
clean, para borrar todos lo ficheros objeto y otras cosas que las versiones anteriores han dejado, se recomienda hacerlo cada vez que se recompile el kernel.
make dep
make clean
Despus de preparar dependencias, puede ejecutar make zImage o make zdisk
(esta es la parte que tarda ms tiempo). make zImage compilar el ncleo y lo
dejar comprimido en arch/i386/boot/zImage junto a otros ficheros. Con make
zdisk el nuevo ncleo se copiar adems en el disquete que est puesto en la disquetera A:. zdisk es interesante para probar ncleos; si explota (o simplemente
no hace nada) se quita el disquete de la disquetera y podr arrancar el ncleo antiguo. Adems sirve para arrancar si borr accidentalmente el ncleo del disco
duro. Tambin puede usarlo para instalar nuevos sistemas simplemente volcando
el contenido de un disco en otro. Los ncleos recientes estn comprimidos, con
una z comenzando su nombre. Un ncleo comprimido se descomprime automticamente al cargarse el sistema.
make zImage
Existen ms makes, por ejemplo con make mrproper har una limpieza mucho
ms intensa. Esta suele hacer falta cuando se actualiza (parchea) el ncleo. Pero
61
5.2 El Kernel
esta opcin borra tambin su fichero de configuracin del ncleo, as que guarde
una copia del correspondiente fichero .config si cree que le interesa.
La opcin make oldconfig intentar configurar el ncleo con un fichero de
configuracin anterior. Aunque a partir del 2.0.xx no es necesario, make recuerda
la ltima configuracin. Para evitar todo el proceso del make config. Si no se
ha compilado anteriormente el ncleo o no se tiene un fichero de configuracin
anterior, no se debe elegir pues se instalar la configuracin por defecto.
Una vez que tenga un nuevo ncleo 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 ncleo ejecutando LILO, quedando listo
para rearrancar, pero esto solo funcionar si LILO est bien configurado para su
sistema: el ncleo es /vmlinuz, LILO est en /sbin y la configuracin de LILO
(/etc/lilo.conf) es coherente con lo anterior. Pero no es difcil hacerlo paso a paso,
adems se puede compilar un kernel en un ordenador ms potente y luego pasarlo
a otro sistema, en tal caso no funciona.
El fichero de configuracin ser como ste:
image = /vmlinuz
label = Linux
root = /dev/hda1
...
La lnea image = apunta al ncleo instalado actualmente. Casi siempre es /vmlinuz. label es el identificador usado para seleccionar qu sistema arrancar, y
root es el disco o particin a usar para el directorio raz.
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 versin 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 segn la distribucin,
para la configuracin del LILO.
62
5.2 El Kernel
vim /etc/lilo.conf
All aadir las lneas necesarias para la nueva versin 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 este ejemplo tenemos /dev/hda1 que corresponde a la particin 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 particin. Por eso en mi sistema tengo /dev/hda5. Pero tambin podra estar en el disco duro scsi, por lo que sera
/dev/sda5. Bueno tener cuidado porque sino pegar una petada increhible.
Tras haber incluido estas lneas en el fichero de configuracin del LILO, es
necesario ejecutarlo para que tenga efecto la nueva configuracin. Esto se hace de
la siguiente manera:
lilo
Para arrancar uno de los antiguos ncleos, se copia las lneas anteriores incluyendo image = xxx al principio del fichero de configuracin 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. Tambin es necesario cambiar label
= zzz por label = linux-backup y reejecute LILO. Puede ser que necesite poner una lnea en el fichero con delay=x donde x son las centsimas de segundo
que LILO esperar antes de arrancar con la primera opcin, de modo que pueda interrumpirse (con la tecla SHIFT) y seleccionarse qu ncleo desea arrancar
(tecleando la etiqueta (label) asignada).
63
5.2 El Kernel
La rdenes make modules; make modules_install compilarn los mdulos que

hayamos seleccionado, y los instalarn. No olvidar ejecutar depmod -a en cuanto
hayamos arrancado con dicho ncleo. En caso de que estemos compilando por segunda vez una misma versin de ncleo, y hayamos variado el nmero de mdulos
a compilar, es posible que la ejecutar make dep nos encontremos con un mensaje de error; esto se debe a que los antiguos mdulos que no hayamos compilado
ahora no son borrados. Pueden borrarse tranquilamente.
Y ya est, reiniciar el sistema y escoger la nueva versin en la lista que muestra
el lilo. Y lo lgico 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 fcilmente, aunque debamos haberlo hecho antes si es el mismo 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 raz (/)
tiene, dnde est y su tipo (por ejemplo, ext2 o minix). Tambin hay que saber
dnde estn los ficheros de /usr, en otra particin.
En nuestro ejemplo, / (el directorio raz) es /dev/hda1, y el sistema con las
fuentes del ncleo 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 instalacin o de rescate, y monte
el sistema de ficheros que contenga el ncleo 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 pero puede ser tambin un reiserfs o bien un ext2, segn el caso. Si mkdir le dice que
el directorio ya existe, no hay problema. Ahora, pase al directorio donde est el ncleo compilado. De esta forma tenemos que /mnt + /usr/src/linux/arch/i386/boot /usr = /mnt/src/linux/arch/i386/boot
64
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 ncleo 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 ncleo est en el directorio raz (por ejemplo /vmlinuz), puede usarlo para un disquete de arranque. Suponiendo las condiciones
anteriores, haramos los cambios siguientes en el ejemplo anterior: /dev/hda3 por
/dev/hda1 (el sistema raz), /mnt/src/linux por /mnt, y if=zImage por if=vmlinuz.
El resto puede ignorarse. Usar LILO con discos grandes (de ms de 1024 cilindros) puede dar problemas. Le recomendamos que lea el mini-HOWTO sobre
LILO para ms informacin.
5.3. Herramientas
Esta seccin pretende explicar las herramientas fundamentales para el desarrollo del kernel. Tenemos que son necesarios los editores de texto, programas
para desarrollo, para navegar por el cdigo 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
programacin del kernel. Entre los que est la discusin es entre el editor vim y
el emacs. Pues explicar ambos por encima, aunque yo soy de los partidarios del
vim.
65
5.3 Herramientas
vim
Como todo sistema UNIX, Linux tambin tiene el editor vi disponible, y sino
el vim (vi-improved que viene a decir el vi-mejorado) con algn contenido extra.
Las razones para usar vim en la programacin dentro del kernel son:
1. Integra de una forma limpia los ctags. Si se hacen tags en el directorio del
cdigo del kernel, se puede acceder rpidamente a las funciones y a las
definiciones de las variables usando las teclas Ctr-] mientras el cursor est
sobre la funcin o variable en cuestin.
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 mayora de nombres son bastante
largos. As que al usar esta herramienta, solo hay que escribir la primera
parte de la variable o de la funcin y apretar Ctrl+P repetidamente mientras
va buscando todos los posibles matches.
3. Es rpido de cargarse.
4. Ocupa poco y deja ms memora para la recompilacin del kernel.
5. Altamente configurable. Entre otras cosas, los comandos que se accionan
con las teclas se pueden volver a mapear fcilmente. Es muy til si se encuentra algn comando que se usa mucho y tiene una combinacin de teclas
incmoda.
6. Est integrado con el cscope. Para hacer bsquedas rpidas del cdigo.
7. Muchas veces se puede encontrar este fntastico 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 ms bsicos del vim
sea leer el vim-HOWTO que se puede encontrar en http://www.tldp.org/HOWTO/VimHOWTO.html
66
5.3 Herramientas
emacs
Como el vi, el emacs est en muchos sistemas y tiene tambin muchos fans.
Las razones para usar emacs en la programacin del kernel son varias:
1. Tiene gran cantidad de libreras para mejorar la productividad.
2. Buena integracin con los etags.
3. Tambin integra bsquedas con grep y cscope.
4. Integracin con gdb, muy til a la hora de debugar cdigo.
5. Las teclas de uso pueden ser ms intuituvas, por ejemplo no es necesario
tener que entrar en ningn 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 tambin 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 ms en cargarse en sistemas ms modestos.
4. Necesita ms 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 frecuentemente.
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 Herramientas
5.3.2. Herramientas de desarrollo

make
El programa make es fundamental y bsico. Es el que se usa para determinar
qu partes de un proyecto con muchos ficheros cdigo fuente necesitan ser reconstruidos. Solo aquellos ficheros de cdigo que hayan sido modificados sern
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 recompilarlo para incluir los cambios tarda muchsimo 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 raz. Cuando se invoca el comando make dep o make bzImage o bien
el make modules, make opera desde el nivel ms 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 configuracin.
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 programas cuando se analiza cdigo normal, con programas de menor envergadura,
pero los bugs en el kernel son ms difciles de tratar y pueden hacer aparecer problemas muy serios. Adems mientras un usuario, est ms 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 an que pierda datos.
lclint es un programa que puede ser usado para checkear el cdigo C de manera
esttica, que significa hacer checks o comprobaciones antes que se haya compilado o ejecutado. Como lint, lclint puede ser ejecutado para recoger errores comunes
de C. Sin embargo, lcint puede hacer mucho ms para ti, pero para ello hay que
aprender a como usarlo anotando en el cdigo comentarios de una manera espe-
68
5.3 Herramientas
cfica.
En resumen, lclint puede dar facilidad a la hora de comprobar errores antes de pasar el compilador. Para averiguar ms informacin buscar en la pgina
http://lclint.cs.virginia.edu/.
5.3.3. Navegacin
Una de las actividades que ms se hace cuando se empieza a programar con
el kernel es navegar arriba y abajo por todo el cdigo, al menos hasta que uno se
familiariza con la gran cantidad de cdigo fuente. Hay herramientas que facilitan
esta navegacin.
grep
grep se usa para encontrar lneas que concuerden con un patron dado. Es una
herramienta muy til para localizar de una forma rpida 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 cdigo e imprime todos los los nombre de ficheros (-H) y el nmero
de lnea (-n) donde aparece sk_buff, el resultado de la bsqueda es recomendable
volcarlo a un fichero para luego poder navegarlo.
El resultado de la bsqueda anterior es muy larga, debido a que es una estructura de los datos que recibimos por las tarjetas de red y cada driver tiene una,
adems de ser la estructura dentro del kernel de los datos que se reciben. An as
aqu pongo el resultado de unas cuantas lneas:
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
5.3 Herramientas
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 cdigo de forma parecida a como lo hace
grep, pero es ms inteligente y provee una interfaz mucho ms bonita para trabajar.
Se puede buscar por definiciones, usos, strings, etc
Antes de poder usar cscope se necesita construir un fichero ndice. Puede hacerse con el comando
cscope -b -R -k
En el directorio raz de la aplicacin. -b para construir el ndice, -R para buscar
recusrivamente a travs 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 debera construirse a partir
de un rbol limpio y recin descomprimido, as que es recomendable guardar una
copia del fichero .config y ejecutar un make mrproper en el directorio raz del
cdigo fuente.
Para empezar a trabajar con una sesin 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
5.3 Herramientas
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 bsquedas, mientras
que la torre de abajo se usa para insertar comandos; Por ejemplo, suponiendo que
se quiere encontrar la definicin de la estructura de datos _system_type. Usando
las teclas con las flechas se mueve el cursor para encontrar esta definicin global 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 secin apropiada del fichero en
cuestin.
Por ejemplo queremos encontrar la definicin de super_block. Siguiendo los
pasos comentados antes veramos 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 *,
2 udfdecl.h
3 fs.h
4 fs.h
5 udf_fs_sb.h
struct buffer_head *);

52 struct super_block;
688 struct super_block
936 struct super_block *(*read_super)
(struct super_block *, void *, int );
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
5.3 Herramientas
Change this text string:

Find this egrep pattern:
Find this file:
Find files #including this file:
Esta vez, cscope ha encontrado ms de una definicin posible. As que se ver la
lista de cada una de las definiciones en su contexto y apretando uno de los nmeros
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 direccin seleccionar una definicin. 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 documentacin para el cscope est disponible en la red en la pgina 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 opcin -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 >

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 ms inteligente y a la vez eficiente que distribuir ficheros
enteros o rboles de directorios con cdigo 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
5.3 Herramientas
Darse cuenta que generalmente se usa el direcotrio raz para generar patches por
ejemplo si se tiene el kernel descomprimido en /usr/src se tiene el directorio modificado 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 distribucin 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 programa diff, a un fichero o a un directorio de cdigo fuente. es necesario entrar por
ejemplo, si se va a pasar del kernel linux-2.4.18 al linux-2.4.19 habra 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 opcin -p1
se usa en el directorio raz de todos los nombres de ficheros que indica en el patch.
Se podra aplicar el parche desde un directorio ms abajo, pero eso significa que
se debera 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
descompresin 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 segn se cre el fichero.
Una script que est incluido en el directorio del cdigo fuente del kernel que es
muy til, se usa para generer de manera semi automtica el proceso de upgrade del
directorio aplicando sucesivos parches: linux/scripts/patch-kernel. Leer el script
para ver qu es lo que hace y cmo se usa, las instrucciones estn 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
5.3 Herramientas
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 debugacin. 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 podra volver al rebs facilmente. Una forma muy bsica
de revisin de control del sistema puede hacerse simplemente haciendo una copia
backup de un fichero antes de hacer cambios importantes, pero esta aproximacin
tiende a ser muy ineficiente rpidamente, sobre todo en el caso de estar modificando varios ficheros a la vez.
Las soluciones son varias, entre ellas tenemos RCS y CVS. El primero de ellos
el RCS es el hermano pequeo de CVS. CVS en cambio es genial para proyectos
grandes con muchos contribuidores y programadores, pero es demasiado trabajo
para proyectos pequeos 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 estn los ficheros de cdigo 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 descripcin. Por defecto, RCS borra el fichero de trabajo al hacer el check in, as que es interesante poner la opcin -u para
comprobar automticamente si existe un fichero igual, y no borrarlo automticamente. 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 cuestin, se mostrar un lista de cambios
y el nmero de versin se ver incrementado.
74
5.3 Herramientas
Suponer que se ha hecho unos cambios erroneos y se quiere volver hacia atrs,
y revertir a una versin buena que sabamos que funcionaba correctamente, por
ejemplo la versin 1.4, entonces hacer el check out del fichero usando este comando:
co -l -r1.4 some-file.c
La opcin -l hace un lock del fichero y te da permisos de escritura para modificarlo, sino solo se tiene permisos de lectura.
RCS guarda el fichero inicial y solo las diferencias que existe entre versiones, ahorrando espacio de disco. Para saber ms informacin sobre RCS, ver las
pginas man de: rcs, ci, co, rcsintro, rcsdiff, rcsclean, rcsmerge, rlog, rcsfile y el
ident. La pgina 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 pequeo nmero de ficheros, pero se convierte intil para ficheros ms grandes donde hay un
gran nmero de contribuidores donde haya ms de un desarrollador. CVS es particularmente la mejor idea, adems es el programa ms usado en la comunidad de
Internet, donde casi todos los proyectos, incluido el del kernel, se llevan usando
CVS.
CVS tiene muchos comandos que estn 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 posicin dentro de la lnea de comandos debera
ser as:
$ cvs [cvs options] sub-command [sub-command options]
Aqu paso una breve lista de los subcomandos disponibles:
add: este comando aade un nuevo fichero al control de cdigo. Es necesario
hacer un check in del fichero suando cvs ci despus de este comando ara que tenga
efecto el cambio.
75
5.3 Herramientas
ci o bien commit: ci que significa check in tiene la misma funcin que commit,
estos comandos harn el check in de los cambios que se hayan hecho a la
copia local de un fichero en cuestin. Despus de introducir este comando,
cualquier update o check out del fichero que est en el repostorio se vern
los cambios que has hecho con el ci. Se puede especificar con la opcin -m
mensaje la opcin 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 informndote 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 modificados en el directorio de trabajo, hay que ejecutar el siguiente comando
desde desde la raz 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 mdulo que estn en el servidor cvs. Primero, crear un subdirectorio
con el mismo nombre que el mdulo, entonces copiar los ficheros al subdirectorio.
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 informacin sobre el repositorio cvs. Por defecto,
este comando solo muestra informacin que te pertenece a ti. Si se usa la
opcin -a (all) mostrar la informacin de todos los usuarios. La siguiente
lnea es til para ver los cambios histricos.
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
5.3 Herramientas
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 cdigo. Si tras hacer esto
se hace un check out de un mdulo, no se encontrar copia de este fichero.
An as, si hacen un check out de una versin anterior del mdulo, se podr
recuperar esa versin anterior de ese fichero.
tag: Para hacerles un tag a los ficheros en el directorio de trabajo actual, se debe
ejecutar la siguiente lnea de comandos
cvs -q tag NombreDelTag
update: Este comando har un update de la copia local de los ficheros de un
mdulo. 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 documentos que se han modificado dentro del directorio de trabajo actual, se debe
ejecutar la siguiente orden desde la raz del directorio de trabajo:
cvs -q update
El repositorio de cvs se debe especificar usando la opcin -d en el comando cvs o
tambin se puede hacer con la variable de entorno CVSROOT. Por ejemplo de la
primera forma sera:
cvs -d pathName login
Y de la segunda manera se escribira:
export CVSROOT=pathName$ cvs login
77
5.3 Herramientas
En el caso que el repositorio estuviera en el mismo sistema, la opcin es muy

simple y solo habra que escribir el path al repositorio, por ejemplo /usr/src/cvs, y
se hara de la siguiente manera:
export CVSROOT=/usr/local/cvs
Pero en el caso que el repositorio est en otro sistema, que es lo ms normal, y
lo que sucede con el kernel de Linux, en la especificacin del repositorio debe
incluirse el mtodo de acceso, el nombre del usuario y el nombre del servidor
donde est localizado el repositorio. Cada uno de estos items, el mtodo 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, versin 2.4, debemos usar el siguiente comando. Este respositorio es una copia (mirror) que se actualiza cada 30 minutos.
export CVSROOT=:pserver:cvs@vger.samba.org:/vger$
cvs loginPassword: cvs$ cd some-directory
# Por ejemplo, /usr/local/src$ cvs -z3 co linux
Y para hacer un update del cdigo fuente hay que usar la siguiente orden:
cd some-directory/linux$ cvs -z3 update -d
Esta es solo una presentacin del CVS, que es muy extenso, para ms informacin
dirigirse a la pgina oficial del proyecto CVS: http://www.cvshome.org/
Y aqu termina la seleccin de aplicaciones para poder trabajar dentro del
kernel.
78
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
cuestin es que a la hora de disear el actual sistema de filtrado de paquetes, el
Netfilter, Rusty Russell compaginaba su trabajo con Alan Cox. Los dos se mantenan 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 estn muy relacionados. Es por eso que el proyecto se ver
influenciado por este sistema, ya que hay unos puntos concretos por donde se asegura que pasan todos los sk_buffs de entrada. Y es esa razn 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
ROUTE
IP_POST_ROUTING
IP_FORWARD
ROUTE
IP_LOCAL_IN
IP_LOCAL_OUT
Usuario
Hooks 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 promiscuo, etc), se pasan a uno de los hooks de netfitler el gancho de NF_IP_PRE_ROUTING.
Luego los datos entran en el cdigo de routing, donde se decide a dnde se enva los paquetes, si se destina a otra interfaz o si es para un proceso local. El cdigo
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 funcin 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 todava 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 lgico que este influenciado,
todos los firewalls trabajan de una forma parecida, pero tiene inconvenientes y
tambin sus ventajas.
5.4.1. Ventajas
La principal caracterstica es que tiene 5 hooks, cuando antes en los kernels
2.2 solo tena 3 hooks. Bueno entonces ellos (Rusty Russell principalmente) habrn 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, como cuando pasa por el forward y cuando sala. Ahora adems se controla cuando
los paquetes van dirigidos a algn programa del sistema o cuando lo ha generado
alguien del sistema. Eso aade control y hace que se puede poner polticas de seguridad 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 tambin 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 polticas del firewall y cada vez que se pasa por un
hook se comprueba para cada una de las polticas y las sesiones abiertas si cumple
o no, si se elimina el paquete o no. La intencin 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 aadido 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
/* Cache info */
nfmark;
__u32
nfcache;
/* Associated connection, if any */
struct nf_ct_info *nfct;
#ifdef CONFIG_NETFILTER_DEBUG
unsigned int nf_debug;
#endif
#endif /*CONFIG_NETFILTER*/
...
}
Donde aade 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 saltrselos.
Otro inconveniente de este sistema es que es una topologa 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 ningn servicio en l, tiene que ser unordenador bastin 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 definicin un firewall tiene que ser un
equipo rpido y con pocos o ningn servicio disponible.
81
5.5 Viaje de un paquete
5.5. Viaje de un paquete

5.5.1. Introduccin
Tras hacer las respectivas pruebas, tras compilar el kernel, insertadar pequeos programas dentro del kernel, despus 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 documentacin [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 documentacin [WS1] aparece
como se trata la informacin y los datos. Pero en el libro de Stevens se trata un
sistema Unix, que tericamente debe ser igual en un sistema Linux.
Se trata de averiguar como viaja un paquete cualquiera por el sistema operativo, y all donde se crea que es mejor insertar el firewall. Y la idea es coger el
paquete y pasarlo compararlo con las polticas de seguridad. Que es un paquete 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 direccin
particular, que siempre es diferente para cada una de las tarjetas de red que hay
en el mundo. Esta direccin es la MAC. La tarjeta est siempre escuchando los
paquetes que pasan por su interfaz, cuando ve un paquete cuya direccin MAC
corresponde a la suya propia, o bien un paquete con una direccin 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 peticin de interrupcin. La rutina que se encarga de servir la interrupcin y que trata la peticin
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 visin que tiene el sistema operativo de un paquete.
2. Vuelca los datos de informacin del buffer de la tarjeta de red en la nueva
estructura creada sk_buff, algunos drivers usando la DMA.
3. Llama a la funcin netif_rx(), que es la funcin que se encarga de recibir los
datos de la tarjeta de red.
4. Al terminar la funcin netif_rx(), el sistema operativo vuelve a activar las
interrupciones y termina el servicio de interrupcin.
La funcin netif_rx() prepara el kernel para el siguiente paso de la recepcin. Pone la informacin 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 interrupcin por
software que luego hablar de ellas) para que pueda ser tratada, y esto se hace
mediante la llamada a la funcin __cpu_raise_softirq( ), definida dentro del fichero 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 aadir softirqs) lo que hace que la recepcin de paquetes sea concurrente
en mquinas Multiprocesador.
Si se desea ver un driver de una Ethernet en accin, se puede mirar algn driver
sencillo como por ejemplo en el fichero drivers/net/8390.c. La rutina de servico
que trata la interrupcin se llama ei_interrupt( ), y llama a la funcin ei_recive( ),
la cual hace lo siguiente:
1. Crea una nueva estructura sk_buff mediante la funcin dev_alloc_skb( ). Y
vuelca los datos con la funcin skb_put( skb, pkt_len).
2. Lee el paquete del buffer de la tarjeta con la funcin ei_block_input( ) y
sealiza el protocolo con skb->protocol= eth_type_trans(skb,dev)
3. Llama a la funcin netif_rx( ) comentada antes.
83
4. Y vuelca todos los datos, segn el contador rx_pkt_count vuelca diez paquetes consecutivamente.
Se puede hechar una ojeada a otros ejemplos mucho ms 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 funcin 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. Acta 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 funcin en un contexto de interrupcin tiene que ser rpida y
corta. No puede hacer ningn chequeo del tamao o cualquier otra compleja funcin, ya que el sistema est potencialmente perdiendo paquetes mientras se est ejecutando el netif_rx( ). As lo que hace la funcin es basicamente seleccionar 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 estado de la cola, identificando uno de los cinco posibles estados de congestin:
NET_RX_SUCCESS (sin congestin), NET_RX_CN_LOW, NET_RX_CN_MOD,
NET_RX_CN_HIGH (baja, moderada y alta congestin, respectivamente) o bien
NET_RX_DROP (el packet se pierde debido a una congestin crtica). Es un proceso 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 condiciones normales, el paqute se inserta en la cola (__skb_queue_tail( )) y la funcin
__cpu_raise_softirq( ) se llama. La ltima funcin hace que se ejecute el softirq.
Cuando la funcin netif_rx( ) termina, retornando un valor que indica la congestin actual al driver. En este punto, el contexto de la interrupcin ha terminado
y el paquete est listo para ser enviado a los protocolos superiores. Este proceso ha
cambiado completamente en la versin del kernel 2.4 donde se basan los softirqs,
84
antes cuando los kernels eran de versin 2.2 se basaba en la mitad inferior (donde
no se poda trabajar en paralelo)
5.5.4. Softirq para NET_RX
Tras recibir el paquete se inserta en una cola para ser procesado posteriormente. Este proceso se hace llamando a la funcin net_rx_action( ). Esta funcin
desempila el primer paquete (Sk_buff) de la cola actual de la CPU y ejectua a travs de dos listas de funciones para su proceso segn el protocolo. Estas listas se
llaman ptype_all y ptype_base y contienen respectivamente, los handlers del protocolo para para paquetes genricos y para paquetes de tipo especfico. Los protocol 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 funcin dev_add_pack( ) dentro del fichero net/core/dev.c,
el cual aade una estructura de tipo del paquete (include/linux/netdevice.h) conteniendo un puntero a la funcin 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
especfico. Si la cola contiene ms de un paquete, la funcin net_rx_action( )
hace un bucle para poder tratar el mximo nmero de paquetes que hayan sido
procesados. Cuando la funcin net_rx_action( ) termina y deja una cola no vaca,
la NET_RX_SOFTIRQ se activa otra vez para permitir el proceso de los paquetes
para ms tarde.
5.5.5. Tratar los paquetes IP
Este proyecto solo se encarga de paquetes IP versin 4, en el caso de que se
hiciese para otro protocolo, como por ejemplo IPv6 se debera buscar otro tipo
de handler. Para IPv4 la funcin se llama ip_rcv( ) y se encuentra en el fichero net/ipv4/ip_input.c, este es apuntada a las listas antes comentadas cuando se
arranca el sistema, mediante la funcin 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.
tcp_input.c
igmp.c
udp.c
sk_buff
ip_input.c
tcp_output.c
sk_buff
sk_buff
ip_output.c
sk_buff
sk_buff
Driver
Tarjeta de red
Se trata mediante
netif_rx
Cable de Red
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 funcin se
encarga de hacer los chequeos iniciales al paquete IP, los cuales tratan de verificar
la integridad del mismo: IP checksum y tamao de la cabecera. Si el paquete
parece correcto, se llama a la funcin ip_rcv_finish( ). Es aqu mismo donde se
introducir la funcin 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 funcin 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 retransmitido a otra mquina o si el destino es el host actual. Es aqu donde habra que
incluir los procesos de routing. Si se enva a otra mquina se enva a la interfaz
correspondiente, y si el destino final es la propia mquina se enva a los protocolos
superiores. Todo esto se hace en la funcin ip_route_input( ), llamada al principio
de ip_rcv_finish( ), la cual determina cual es el siguiente paso.
Si el destino es la propia mquina, entonces se llama a la funcin ip_locl_deliver( ).
Esta funcin se encarga de reensamblar los diferentes paquetes IP, en el caso que el
datagrama est fragmentado, y entonces llama a la funcin ip_local_deliver_finish( ).
86
Si el destino es otra mquina el proceso entonces se enva a la funcin 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 ms 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 teora de filtrado de paquetes.
87
6 ESTUDIO DEL DISEO ( UML)
6. Estudio del Diseo ( UML)

6.1. Introduccin al UML
6.1.1. Historia
El "Unified Modelling Languaje" (UML) provee a los analistas y arquitectos
de sistemas que trabajan en el diseo y anlisis de objetos de un lenguaje consistente para especificar, visualizar, construir y documentar los artefactos de un
sistema de software, as tambin es til para hacer modelos de negocios.
Esta especificacin es la evolucin del las tres anteriores tecnologas orientadas a objetos lideres (Booch, OMT y OOSE). El UML es la unin de estos lenguajes de modelos y an mas ya que incluye expresiones adicionales para manejar
problemas de modelaje que los mtodos anteriores no cubran 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 unificar los mtodos de Booch y OMT. Debido a que los mtodos Booch y OMT
ya haban madurado independientemente y eran reconocidos como mtodos lderes en el desarrollo orientado a objetos, Booch y Rumbaugh unieron fuerzas para
forjar una unificacin completa de los dos mtodos. Una versin preliminar 0.8
de el "mtodo unificado" fue dad a conocer en octubre de 1995. Poco despus,
Ivar Jacobson y su compaa "Objectory" se unieron a Rational y a su trabajo de
unificacin, uniendo el mtodo OOSE (Object Oriented software engineering). El
Nombre de Objectory es ahora dado mayormente para describir a el Proceso que
acompaa al UML el "Rational unified process".
88
6.1 Introduccin al UML
6.1.2. Objetivos
Los objetivos de la unificacin fueron: el mantenerlo simple, el quitar elementos de los lenguajes de Booch, OMT y OOSE que no funcionaran en la prctica, el
aadir elementos de otros mtodos que fueran ms efectivos y el inventar nuevas
construcciones solamente cuando la solucin existente no estuviera disponible.
UML es un lenguaje de modelado de propsito general que pueden usar todos
los modeladores. No tiene propietario y est basado en el comn acuerdo de gran
parte de la comunidad informtica. UML no pretende ser un mtodo 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 iterativo, basado en construir una slida 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 distribucin, as como tambin
los mecanismos de la ingeniera de software, como son la encapsulacin y componentes. Debe ser un lenguaje universal, como cualquier lenguaje de propsito
general, pretende ser un estndar mundial.
Varios nuevos conceptos existen en UML, incluyendo:
1. Mecanismos de extensin (estereotipos, valores marcados y restricciones),
2. Procesos y ramas de procesamiento
3. Distribucin y concurrencia
4. Patrones y colaboracin
5. Diagramas de actividad
6. Refinamiento (para manejar las relaciones entre los niveles de abstraccin)
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 tcnicas lderes,
pero se espera que tcnicas adicionales influyan las versiones futuras del UML.
Muchas tcnicas avanzadas pueden ser definidas usando el UML como base. El
UML puede ser extendido sin redefinir su ncleo.
6.1.3. Participantes en UML 1.0
La lista de participantes incluye grandes empresas de informtica, con lo que
se consigue no slo que haya ms intercambio de ideas sino que se cumpla en
un defacto para todo el mundo. Lstima 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 DSouza)
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 esttica: Cualquier modelo preciso debe primero definir su universo, esto es, los conceptos clave de la aplicacin, sus propiedades internas, y
las relaciones entre cada una de ellas. Este conjunto de construcciones es la
estructura esttica. Los conceptos de la aplicacin son modelados como clases, cada una de las cuales describe un conjunto de objetos que almacenan
informacin y se comunican para implementar un comportamiento. La informacin que almacena es modelada como atributos; La estructura esttica
se expresa con diagramas de clases y puede usarse para generar la mayora
de las declaraciones de estructuras de datos en un programa.
Comportamiento dinmico: Hay dos formas de modelar el comportamiento,
una es la historia de la vida de un objeto y la forma como interacta con
el resto del mundo y la otra es por los patrones de comunicacin de un conjunto de objetos conectados, es decir la forma en que interactan entre s.
La visin de un objeto aislado es una maquina de estados, muestra la forma
en que el objeto responde a los eventos en funcin de su estado actual. La
visin de la interaccin 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 implementacin: Los modelos UML tienen significado para
el anlisis lgico y para la implementacin fsica. Un componente es una
parte fsica reemplazable de un sistema y es capaz de responder a las peticiones descritas por un conjunto de interfaces. Un nodo es un recurso computacional que define una localizacin durante la ejecucin de un sistema.
Puede contener componentes y objetos.
91
6.2 Diagramas
Organizacin del modelo: La informacin del modelo debe ser dividida en piezas 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 tamao modesto. Los paquetes son
unidades organizativas, jerrquicas y de propsito general de los modelos de
UML. Pueden usarse para almacenamiento, control de acceso, gestin de la
configuracin y construccin de bibliotecas que contengan fragmentos de
cdigo reutilizable.
Mecanismos de extensin: UML tiene una limitada capacidad de extensin pero
que es suficiente para la mayora de las extensiones que requiere el dia a
dia sin la necesidad de un cambio en el lenguaje bsico. 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 abstraccin de dicho sistema, considerando un cierto propsito. As, el modelo describe
completamente aquellos aspectos del sistema que son relevantes al propsito 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 inters.
El cdigo fuente del sistema es el modelo ms detallado del sistema (y adems 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 representacin grfica de una coleccin de elementos de
modelado, a menudo dibujada como un grafo conexo de arcos (relaciones) y vrtices (otros elementos del modelo). Un diagrama no es un elemento semntico, un
diagrama muestra representaciones de elementos semnticos 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
6.2 Diagramas
La mayora de los diagramas de UML y algunos smbolos complejos son grafos que contienen formas conectadas por rutas. La infomacin est sobre todo
en la topologa, no en el tamao o la colocacin de los smbolos (hay algunas
excepciones como el diagrma de secuencia con un eje mtrico de tiempo). Hay
tres clases importantes de relaciones visuales: conexin (generalmente de lneas
a formas de dos dimensiones), contencin (de smbolos por formas cerradas de
dos dimensiones), y adhesin visual (un smbolo que est "cerca" de otro en un
diagrama). Estas relaciones geomtricas se reasignan a conexiones entre nodos en
un grfico en la forma analizada de la notacin.
La notacin de UML est pensada para ser dibujada en superficies bidimensionales. Algunas formas bidimensionales son proyecciones de formas tridimensionales tales como cubos, pero todava se representan como conos en una superficie
bidimensional.
Hay cuatro clases de construcciones grficas que se usan en la notacin de
UML: conos, smbolos bidimensionales, rutas y cadenas.
Un cono es una figura grfica con un tamao y forma fijos. No se ampla para
contener a su contenido. Los iconos pueden aparecer dentro de smbolos de rea,
como terminadores en las rutas o como smbolos independientes que puedan o no
conectar con las rutas.
Los smbolos de dos dimensiones tienen altura y anchura variables, y pueden
ampliarse para permitir otras cosas tales como listas de cadenas o de otros smbolos. Muchos de ellos estn divididos en compartimientos similares o de tipos
diferentes. Las rutas se conectan con los smbolos, 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 topolgica, aunque
sus segmentos se pueden manipular grficamente. un segemento no debera existir
separado de su ruta. Las rutas siempre van conectdas en ambos extremos.
Las cadenas presentan varias clases de informacin en una forma "no analizada", UML asume que cada uso de una cadena en la notacin tiene una sintaxis
por la cual pueda ser analizada la informacin del modelo subyancente. Las cadenas pueden existir como el contenido de un compartimiento, como elementos en
las listas, como etiquetas unidas a los smbolos o a las rutas, o como elementos
93
6.2 Diagramas
independientes en un diagrama.
6.2.1. Diagramas estructurales
Se usan para visualizar, especificar, construir y documentar aspectos estticos
de un sistema. Que son el esqueleto e incluyen la existencia y ubicacin de clases,
interfaces, colaboraciones, componentes y nodos.
Diagrama de clases: Representa las clases, interfaces y colaboraciones y relaciones entre ellas.
Diagramas de objetos: Representa objetos y sus relaciones. SE usa para describir estructuras de datos.
Diagramas de componentes: Muestra el conjunto de componentes y sus relaciones. Los diagramas de componentes se relacionan con los diagramas de
clases dado que los componentes son grupo de clases, interfaces y colaboraciones.
Diagramas de despliegue: Muestra conjunto de nodos y sus relaciones. Se usan
para describir la vista de despliegue esttica de una arquitectura. Se relacionan con los diagramas de componentes porque un nodo incluye normalmente uno o ms componentes.
6.2.2. Diagramas de comportamiento
Se usa para los aspectos dinmicos de un sistema. Que son las partes mutables como el flujo de mensajes a lo largo del tiempo el movimiento fsico 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 colaboracin representan
a los diagramas de interaccin, que resalta la ordenacin temporal de los
mensajes. Representa el conjunto de objetos y los mensajes enviados y recibidos entre ellos.
94
6.3 Diagramas de Objetos
Diagramas de colaboracin: Son diagramas de interaccin que resalta la organizacin estructural de los objetos que envan y reciben sus mensajes. Representan los objetos enlazados unos con otros con sus mensajes enviados
y recibidos.
Diagramas de estado: Son mquinas de estados, con sus transiciones, eventos y
actividades. Ayudan a modelar el comportamiento.
Diagramas de actividades: Muestra el flujo de actividades. Muestran el flujo secuencial de actividades y los objetos que actan y sobre los que acta.
6.3. Diagramas de Objetos

Objeto es una entidad discreta con lmites bien definidos y con identidad, es
una unidad atmica que encapsula estado y comportamiento. La encapsulacin en
un objeto permite una alta cohesin y un bajo acoplamiento. el Objeto es reconocido tambin como una instancia de la clase a la cual pertenece.
La encapsulacin presenta tres ventajas bsicas:
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 especfico (Un objeto puede
caracterizar una entidad fsica -coche-) y como un poseedor de identidad que tiene
distintos valores a lo largo del tiempo (abstracta -ecuacin matemtica-).
Cada objeto posee su propia identidad exclusiva y se puede hacer referencia
a l mediante una denominacin exclusiva que permite accederle. El Modelado
de Objetos permite representar el ciclo de vida de los objetos a travs de sus
interacciones. En UML, un objeto se representa por un rectngulo 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 notacin de instancias consiste en utilizar el mismo smbolo geomtrico que el descriptor. En la instancia se muestran los posibles valores
pero las propiedades compartidas slo se pone de manifiesto en el descriptor. La
notacin cannica es un rectngulo 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 caractersticas:
1. Constituye un identificador nico y global para cada objeto dentro del sistema.
2. Es determinado en el momento de la creacin del objeto.
3. Es independiente de la localizacin fsica del objeto, es decir, provee completa independencia de localizacin.
96
4. Es independiente de las propiedades del objeto, lo cual implica independencia de valor y de estructura.
5. No cambia durante toda la vida del objeto. Adems, un oid no se reutiliza
aunque el objeto deje de existir.
No se tiene ningn control sobre los oids y su manipulacin resulta transparente.
Sin embargo, es preciso contar con algn medio para hacer referencia a un objeto
utilizando referencias del dominio (valores de atributos).
6.3.2. Caractersticas alrededor de un objeto
Estado: El estado evoluciona con el tiempo. Algunos atributos pueden ser constantes, 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 estmulo 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 despus reconstruirlo, es decir,
cogerlo de memoria secundaria para utilizarlo en la ejecucin (materializacin del objeto). Los lenguajes OO no proponen soporte adecuado para
la persistencia, la cual debera ser transparente, un objeto existe desde su
creacin hasta que se destruya.
Comunicacin: Un sistema informtico puede verse como un conjunto de objetos autnomos y concurrentes que trabajan de manera coordinada en la
consecucin de un fin especfico. El comportamiento global se basa pues en
la comunicacin entre los objetos que la componen.
Categoras de objetos: Pueden ser clasificado como Activos o Pasivos, como
Cliente o Servidores, o bien como Agentes.
1. Objeto Activo: Posee un hilo de ejecucin (thread) propio y puede iniciar
una actividad.
97
6.4 Diagramas de Clases
2. Objeto Pasivo: No puede iniciar una actividad pero puede enviar estmulos
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 renen las caractersticas de clientes y servidores. Son la base del mecanismo de delegacin. Introducen indireccin: un cliente puede
comunicarse con un servidor que no conoce directamente.
Mensajes: La unidad de comunicacin entre objetos se llama mensaje. El mensaje es el soporte de una comunicacin que vincula dinmicamente los objetos que fueron separados previamente en el proceso de descomposicin.
Adquiere toda su fuerza cuando se asocia al polimorfismo y al enlace dinmico. Un estmulo causar la invocacin de una operacin, la creacin
o destruccin de un objeto o la aparicin de una seal. Un mensaje es la
especificacin de un estmulo.
6.4. Diagramas de Clases

El Diagrama de Clases es el diagrama principal para el anlisis y diseo. Un
diagrama de clases presenta las clases del sistema con sus relaciones estructurales
y de herencia. La definicin de clase incluye definiciones para atributos y operaciones. El modelo de casos de uso aporta informacin para establecer las clases,
objetos, atributos y operaciones.
El mundo real puede ser visto desde abstracciones diferentes (subjetividad).
Mecanismos de abstraccin:
1. Clasificacin / Instanciacin
2. Composicin / Descomposicin
3. Agrupacin / Individualizacin
4. Especializacin / Generalizacin
98
La clasificacin es uno de los mecanismos de abstraccin ms utilizados. La clase

define el mbito de definicin de un conjunto de objetos, y cada objeto pertenece
a una clase, Los objetos se crean por instanciacin de las clases.
Cada clase se representa en un rectngulo con tres compartimientos:
nombre de la clase
atributos de la clase
operaciones de la clase
Los atributos de una clase no deberan ser manipulables directamente por el resto
de objetos. Por esta razn se crearon niveles de visibilidad para los elementos que
son:
1. (-) Privado : Es el ms fuerte. Esta parte es totalmente invisible (excepto
para clases friends en terminologa C++).
2. (#) Los atributos/operaciones protegidos estn visibles para las clases friends
y para las clases derivadas de la original.
3. (+) Los atributos/operaciones pblicos son visibles a otras clases (cuando
se trata de atributos se est transgrediendo el principio de encapsulacin).
6.4.1. Relaciones entre clases
Semnticamente todas las relaciones, incluidas la generalizacin, la asociacin
y la realizacin son tipos de dependecias. Pero tienen una semntica lo bastante
importante como para justificar que se traten como distintos tipos de relaciones
en UML. Es una decisin de diseo. 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 generalizacin, la asociacin y la realizacin en primer lugar y luego
ve las dems relaciones como tipos de dependencias.
Relacin de Dependencias: Relacin de uso. Declara que un cambio en la especificacin del elemento usado puede afectar al elemento que lo usa. Como
puede verse en la imagen, la figura usa posicion
99
Relacin de Generalizacin: Relacin "hereda_de" o bien "es_un_tipo_de". Entre una superclase o padre y una subclase o hijo. En la imagen tenemos que
Rectngulo y Crculo heredan de Figura.
Relacin de Asociacin: Relacin estructural que especifica conexin entre dos

objetos. Conexin entre dos objetos es una asociacin binaria y entre n clases es una n-aria. Dentro de este grupo de relaciones tenemos relacin de
asociacin por nombre, por rol, por multiplicidad y por agragacin.
Nombre: Describe la naturaleza de la asociacin. En la figura un empleado
trabaja para otra clase.
Rol: Rol que se juega en una asosciacin. Tenemos que una persona vista
desde la fbrica es un empleado.
100
6.5 Diagramas de Caso de Uso
Multiplicidad: Indica "cuantos" objetos en un extremo de la asociacin pertenecen. En el ejemplo tenemos que una fbrica tiene un nmero indefinido
de personas trabajando en ella.
Agregacin: Relacin "tiene_un". Relacion entre objetos del mismo nivel

pero con una relacin todo/parte, uno es "parte" del "todo".
6.5. Diagramas de Caso de Uso

Casos de Uso es una tcnica para capturar informacin de cmo un sistema
o negocio trabaja, o de cmo se desea que trabaje. No pertenece estrictamente al
enfoque orientado a objeto, es una tcnica 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 lmites del sistema y las relaciones entre el sistema y el
entorno.
101
6.5 Diagramas de Caso de Uso
Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la implementacin.
Comparacin con respecto a los Diagramas de Flujo de Datos del Enfoque
Estructurado.
Los Casos de Uso cubren la carencia existente en mtodos previos (OMT,
Booch) en cuanto a la determinacin de requisitos.
Los Casos de Uso particionan el conjunto de necesidades atendiendo a la
categora de usuarios que participan en el mismo.
Estn basados en el lenguaje natural, es decir, es accesible por los usuarios.
6.5.1. Actores
La misma persona fsica puede interpretar varios papeles como actores distintos, el nombre del actor describe el papel desempeado.
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 aplicacin y deben ser utilizados.
4. Otros sistemas: sistemas con los que el sistema interacta.
Los Casos de Uso se determinan observando y precisando, actor por actor, las
secuencias de interaccin, 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 relacin en los Diagramas de Casos de Uso. La
Comunicacin, la Inclusin, que es una instancia del Caso de Uso origen incluye
tambin el comportamiento descrito por el Caso de Uso destino. include reemplaz al denominado uses. La Extensin : el Caso de Uso origen extiende el
102
6.6 Diagramas de Estado
comportamiento del Caso de Uso destino. extend y la Herencia : el Caso de

Uso origen hereda la especificacin del Caso de Uso destino y posiblemente la
modifica y/o ampla.
6.6. Diagramas de Estado

Muestra el conjunto de estados por los cuales pasa un objeto durante su vida
en una aplicacin, junto con los cambios que permiten pasar de un estado a otro.
Los Diagramas de Estado representan autmatas de estados finitos, desde el
p.d.v. de los estados y las transiciones. Son tiles slo 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 comportamiento. Cada objeto sigue el comportamiento descrito en el Diagrama de Estados
asociado a su clase. Los Diagramas de Estados y escenarios son complementarios, los Diagramas de Estados son autmatas jerrquicos que permiten expresar
concurrencia, sincronizacin y jerarquas de objetos, son grafos dirigidos y deterministas. La transicin entre estados es instantnea y se debe a la ocurrencia de
un evento.
6.6.1. Estado
Identifica un periodo de tiempo del objeto (no instantneo) en el cual el objeto
est esperando alguna operacin, tiene cierto estado caracterstico o puede recibir
cierto tipo de estmulos. Se representa mediante un rectngulo con los bordes
redondeados, que puede tener tres compartimientos: uno para el nombre, otro para
el valor caracterstico 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 transicin de un estado a otro de un
objeto. Esta ocurrencia puede ser una de varias cosas:
103
Condicin que toma el valor de verdadero o falso

Recepcin de una seal de otro objeto en el modelo
Recepcin de un mensaje
Paso de cierto perodo de tiempo, despus 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. Envo de mensajes
Adems de mostrar y transicin de estados por medio de eventos, puede representarse el momento en el cual se envan mensajes a otros objetos. Esto se realiza
mediante una lnea punteada dirigida al diagrama de estados del objeto receptor
del mensaje.
Transicin simple
Una transicin simple es una relacin entre dos estados que indica que un
objeto en el primer estado puede entrar al segundo estado y ejecutar ciertas operaciones, cuando un evento ocurre y si ciertas condiciones son satisfechas. Se
representa como una lnea slida entre dos estados, que puede venir acompaada
de un texto con el siguiente formato:
event-signature "[" guard-condition] "/" action-expression "^"send-clause
event-signature es la descripcin del evento que da lugar la transicin, guardcondition son las condiciones adicionales al evento necesarias para que la transicin ocurra, action-expression es un mensaje al objeto o a otro objeto que se
ejecuta como resultado de la transicin y el cambio de estado y send-clause son
acciones adicionales que se ejecutan con el cambio de estado, por ejemplo, el
envo de eventos a otros paquetes o clases.
104
Transicin interna
Es una transicin 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 consecuencia de la transicin. Se puede especificar el ejecutar una accin como consecuencia
de entrar, salir, estar en un estado, o por la ocurrencia de un evento.
Generalizacin de Estados:
Podemos reducir la complejidad de estos diagramas usando la generalizacin 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 agregacin de estados es la composicin de un estado a partir de varios
estados independientes.
La composicin es concurrente por lo que el objeto estar en alguno de los estados
de cada uno de los subestados concurrentes. La destruccin de un objeto es efectiva cuando el flujo de control del autmata 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.7 Diagramas de actividades
Transaccin Compleja
Una transicin compleja relaciona tres o ms estados en una transicin de
mltiples fuentes y/o mltiples destinos. Representa la subdivisin en threads del
control del objeto o una sincronizacin. Se representa como una lnea vertical de
la cual salen o entran varias lneas de transicin de estado.
Transicin a estados anidados
Una transicin 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 subestados hacia afuera (a cualquier nivel de profundidad).
Transiciones temporizadas
Las esperas son actividades que tienen asociada cierta duracin.
La actividad de espera se interrumpe cuando el evento esperado tiene lugar.
Este evento desencadena una transicin 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 trabajo o la ejecucin de una operacin. 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 automticas. 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 ejecucin de un sistema, sin profundizar en los detalles internos
de los mensajes. Los parmetros de entrada y salida de una accin se pueden
mostrar usando las relaciones de flujo que conectan la accin y un estado de flujo
de objeto.
106
6.7 Diagramas de actividades
Un grafo de actividades contiene estados de actividad que representa la ejecucin 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 terminacin de su cmputo. Cuando la
actividad termina, entonces la ejecucin procede al siguiente estado de actividad
dentro del diagrama. una transicin de terminacin es activada en un diagrama
de actividades cuando se completa la actividad precedente. Los estados de actividad no tienen transiciones con eventos explcitos, peor pueden ser abortados por
transiciones en estados que los incluyen.
Un grafo de actividades puede contener tambin estados de accin, que son
similares a los de actividad pero son atmicos y no permiten transiciones mientras
estn activos. Los estados de accin 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 agregacin, en la cual cada objeto tiene su
propio hilo. Las actividades concurrentes se pueden realizar simultneamente o en
cualquier orden. Un diagrama de actividades es como un organigrama tradicional,
excepto que permite el control de concurrencia adems del control secuencial.
6.7.1. Notacin
Un estado de actividad se representa como una caja con los extremos redondeados que contiene una descripcin de actividad. Las transacciones simples de
terminacin se muestran como flechas. Las ramas se muestran como condiciones
de guarda en transiciones o como diamantes con mltiples flechas de salida etiquetadas. Una divisin o una unin de control se representa con mltiples flechas
que entran o salen de la barra gruesa de sincronizacin.
Cuando es necesario incluir eventos externos, la recepcin de un evento se
puede mostrar como un disparador en una transicin, o como un smbolo especial
que denota la espera de una seal.
A menudo es til organizar las actividades en un modelo segn su responsa-
107
6.8 Diagramas de Interaccin
bilidad. Esta clase de asignacin puede mostrarse organizando las actividades en

regiones distintas separads por lneas 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 lnea discontinua desde la actividad al objeto. Para un valor de entrada, se dibuja una flecha con lnea discontinua
desde el objeto a una actividad.
6.8. Diagramas de Interaccin

La vista de interaccin describe secuencias de intercambios de mensajes entre
los roles que implementan el comportamiento de un sistema. Un rol clasificador, o simplemente "un rol", es la descripcin de un objeto, que desempea un
determinado papel dentro de una interaccin, distinto de los otros objetos de la
misma clase. Esta visin proporciona una vista integral del comportamiento del
sistema, es decir, muestra el flujo de control a travs de muchos objetos. La vista
de interaccin se exhibe en dos diagramas centrados en distintos aspectos pero
complementarios: centrados en los objetos individuales y centrados en objetos
cooperantes.
Los objetos interactan para realizar colectivamente los servicios ofrecidos
por las aplicaciones. Los diagramas de interaccin muestran cmo se comunican
los objetos en una interaccin. Existen dos tipos de diagramas de interaccin: el
Diagrama de Colaboracin y el Diagrama de Secuencia.
El Diagrama de Secuencia es ms adecuado para observar la perspectiva cronolgica de las interacciones, muestra la secuencia explcita de mensajes y son
mejores para especificaciones de tiempo real y para escenarios complejos. El Diagrama de Colaboracin ofrece una mejor visin espacial mostrando los enlaces
de comunicacin entre objetos, muestra las relaciones entre objetos y son mejores
para comprender todos los efectos que tiene un objeto y para el diseo de procedimientos. El diagrama de Colaboracin puede obtenerse automticamente a partir
del correspondiente diagrama de Secuencia (o viceversa).
108
6.8 Diagramas de Interaccin
Diagramas de Secuencia
1. Muestra la secuencia de mensajes entre objetos durante un escenario concreto
2. Cada objeto viene dado por una barra vertical
3. El tiempo transcurre de arriba abajo
4. Cuando existe demora entre el envo y la atencin se puede indicar usando
una lnea oblicua
Diagramas de Colaboracin
1. Son tiles en la fase exploratoria para identificar objetos.
2. La distribucin de los objetos en el diagrama permite observar adecuadamente la interaccin de un objeto con respecto de los dems
3. La estructura esttica viene dada por los enlaces; la dinmica por el envo
de mensajes por los enlaces
6.8.1. Colaboracin
Es una descripcin de una coleccin de objetos que interactan para implementar un cierto comportamiento dentro de un contexto. Describe una sociedad
de objetos cooperantes unidos para realizar un cierto propsito. Una colaboracin
contiene ranuras que son rellenadas por los objetos y enlaces en tiempo de ejecucin. Una ranura de colaboracin se llama Rol porque describe el propsito de un
objeto o un enlace dentro de la colaboracin.
Un rol clasificador representa una descripcin de los objetos que pueden participar en una ejecucin de la colaboracin, un rol de asociacin representa una
descripcin de los enlaces que pueden participar en una ejecucin de colaboracin. Un rol de clasificador es una asociacin que est limitada por tomar parte
en la colaboracin. Las relaciones entre roles de clasificador y asociacin dentro
de una colaboracin slo tienen sentido en ese contexto. En general fuera de ese
contexto no se aplican las mismas relaciones.
109
6.9 Diagramas de Componentes
Una Colaboracin tiene un aspecto estructural y un aspecto de comportamiento. El aspecto estrucutral es similar a una vista esttica: contiene un conjunto de
roles y relaciones que definen el contexto para su comprtamiento. El comportamiento es el conjunto de mensajes intercambiados por los objetos ligados a los
roles. Tal conjunto de mensajes en una colaboracin se llama Interaccin. Una
colaboracin puede incluir una o ms interacciones.
6.8.2. Interaccin
Es el conjunto de mensajes intercambiados por los roles de clasificador a travs de los roles de asociacin. Un mensaje es una comunicain unidireccional
entre dos objetos, un flujo de objeto con la informacin de un remitente a un receptor. Un mensaje puede tener parmetros que transporten valores entre objetos.
Un mensaje puede ser una seal (comunicacin explcita entre objetos, con nombre y asncrona) o una llamada (la invocacin sncrona de una operacin con un
mecanismo para el control, que retorna posteriormente al remitente). Un patrn
de intercambios de mensajes que se realizan para lograr un propsito especfico
es lo que se denomina una interaccin.
6.8.3. Patrn
Un patrn es una colaboracin parametrizada, junto con las pautas sobre cundo utilizarlo. Un parmetro se puede sustituir por diversos valores, para producir
distintas colaboraciones. Los parmetros sealan generalmente las ranuras para
las clases. El uso de un patrn se representa como una elipse de lnea discontinua
conectada con cada una de las clases por una lnea discontinua, que se etiqueta
con el nombre del rol.
6.9. Diagramas de Componentes

Los diagramas de componentes describen los elementos fsicos del sistema y
sus relaciones. Muestran las opciones de realizacin incluyendo cdigo fuente,
binario y ejecutable. Los componentes representan todos los tipos de elementos
software que entran en la fabricacin de aplicaciones informticas. Pueden ser
110
simples archivos, paquetes de Ada, bibliotecas cargadas dinmicamente, etc. Las

relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente utiliza los servicios ofrecidos por otro componente.
Un diagrama de componentes representa las dependencias entre componentes
software, incluyendo componentes de cdigo fuente, componentes del cdigo binario, y componentes ejecutables. Un mdulo de software se puede representar
como componente. Algunos componentes existen en tiempo de compilacin, algunos en tiempo de enlace y algunos en tiempo de ejecucin, otros en varias de
stas.
Un componente de slo compilacin es aquel que es significativo nicamente
en tiempo de compilacin. Un componente ejecutable es un programa ejecutable.
Un diagrama de componentes tiene slo una versin con descriptores, no tiene
versin 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 clases definidas en ellos, y las relaciones entre ellas. Los clasificadores de componentes tambin se pueden anidar dentro de otros clasificadores de componentes
para mostrar relaciones de definicin.
Un diagrama que contiene clasificadores de componentes y de nodo se puede
utilizar para mostrar las dependencias del compilador, que se representa como flechas con lneas discontinuas (dependencias) de un componente cliente a un componente proveedor del que depende. Los tipos de dependencias son especficos
del lenguaje y se pueden representar como estereotipos de las dependencias.
El diagrama tambin puede usarse para mostrar interfaces y las dependencias
de llamada entre componentes, usando flechas con lneas discontinuas desde los
componentes a las interfaces de otros componentes.
El diagrama de componente hace parte de la vista fsica de un sistema, la
cual modela la estructura de implementacin de la aplicacin por s misma, su
organizacin en componentes y su despliegue en nodos de ejecucin. Esta vista
proporciona la oportunidad de establecer correspondecias entre las clases y los
componentes de implementacin y nodos. La vista de implementacin se representa con los diagramas de componentes.
111
6.9.1. Componentes
Es una parte fsica reemplazable de un sistema que empaqueta su implementacin y es conforme a un conjunto de interfaces a las que proporciona su realizacin.
Algunos componentes tienen identidad y pueden poseer entidades fsicas, que
incluyen objetos en tiempo de ejecucin, documentos, bases de datos, etc. Los
componentes existentes en el dominio de la implementacin son unidades fsicas
en los computadores que se pueden conectar con otros componentes, sustituir,
trasladar, archivar, etc.
Los componentes tienen dos caractersticas: Empaquetan el cdigo que implementa 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.
Cdigo:
Un componente contiene el cdigo para las clases de implementacin y otros
elementos. Un componente de cdigo fuente es un paquete para el cdigo fuente
de las clases de implementacin. Al gunos lenguajes de programacin distinguen
archivos de declaracin de los archivos de mtodo, pero todos son componentes.
Un componente de cdigo binario es un paquete para el cdigo compliado. Una
biblioteca del cdigo binario es un componente.
Cada tipo de componente contiene el cdigo para las clases de implementacin
que realizan algunas clases e interfaces lgicas. La relacin de realizacin asocia
un componente con las clases y las interfaces lgicas que implementan sus clases
de implementacin. Las interfaces de un componente describen la funcionalidad
que aporta. Cada operacin de la interfaz debe hacer referencia eventualmente a
un elemento de la implementacin disponible en el componente.
La estrucutra esttica, ejecutable de una implementacin de un sistema se puede representar como un conjunto interconectado de componentes. Las dependencias entre componentes significan que los elementos de la implementacin en un
componente requieren los serivios de los elementos de implemntacin en otros
componentes. Tal uso requiere que dichos elementos sean de visibilidad pblica.
112
6.10 Diagramas de Despliegue
Identidad:
Un componente de identidad tiene identidad y estado. Posee los objetos fsicos
que estn situados en l. Puede tener atributos, relaciones de composicin con
los objetos posedos, 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 implementacin, esto significa que el componente proporciona el cdigo para los elementos. Un componente puede tener operaciones e interfaces. Un componente de identidad es un
contenedor fsico para las entidades fsicas como bases de datos. Para proporcionar manejadores para sus elementos contenidos, puede tener atributos y asociaciones salientes, que deben ser implementadas por sus elementos de implementacin.
Este componente se representa con un rectngulo con dos rectngulos ms pequeos que sobresalen en su lado izquierdo.
Las operaciones e interfaces disponibles para los objetos exteriores se pueden
representar directamente en el smbolo de clase. Estos son su comportamiento como 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 lneas discontinuas con la punta de flecha hacia los
elementos del proveedor. S un componente es la realizacin de una interfaz, se
representa con un crculo unido al smbolo del componente por un segmento de
lnea.
6.10. Diagramas de Despliegue

Los Diagramas de Despliegue muestran la disposicin fsica de los distintos
nodos que componen un sistema y el reparto de los componentes sobre dichos
nodos. La vista de despliegue representa la disposicin de las instancias de componentes de ejecucin en instacias de nodos conectados por enlaces de comunicacin. Un nodo es un recurso de ejecucin tal como un computador, un dispositivo
113
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 distribucin y
la asignacin de recursos. Las instancias de los nodos pueden contener instancias
de ejecucin, como instancias de componentes y objetos. El modelo puede mostrar
dependencias entre las instancias y sus interfaces, y tambin modelar la migracin
de entidades entre nodos u otros contenedores.
Esta vista tiene una forma de descriptor y otra de instancia. La forma de instancia muestra la localizacin de las instancias de los componentes especficos
en instancias especficas del nodo como parte de una configuracin 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 comn que la primera.
6.11. Los paquetes

Los paquetes son elementos para organizar elementos en grupos. Imaginemos
una aplicacin 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 problema real para grandes sistemas (el acceso simple y no restringido no permite el
crecimiento). Para estas situaciones se necesita algn tipo de empaquetamiento
controlado para organizar las abstracciones.
114
6.11 Los paquetes
Anidamiento
Las abstracciones que organizan un modelo se llaman paquetes. Y los paquetes
agrupan a otros paquetes organizndolos en forma de directorios. Se recomienda
tener como lmite 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
Importacin
La importacin 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 relacin de importacin se modela como una dependencia con el
estereotipo import.
Elementos extensibilidad
Pueden aadirse valores etiquetados para aadir nuevas propiedades al paquete (como el autor, fecha creacin, etc) y estereotipos para especificar categoras.
Estos son:
1. facade: (fachada) Es un paquete que muestra solo unos objetos de otro paquete. Se usa para mostrar vistas simplificadas y diferentes que de otra forma seran vistas muy complejas, reduciendo el campo de visin segn las
funciones que vayan a usarse.
2. stub: Paquete tiene la funcin de proxy a otro paquete.
3. subsystem: Representa una parte independiente del sistema completo.
115
6.11 Los paquetes
4. system: Representa al sistema completo.
116
7 HACKING DEL KERNEL
Parte II
Prctica
7. Hacking del kernel
7.1. Introduccin
Programar en espacio del kernel ha sido siempre cosa de gurs, 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
informacin 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 ningn sistema 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 cdigo. 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 ms detalladamente. Pero, no hay
nada que pare al cdigo de sobreescribir o acceder a localizaciones de la memoria
de cualquiera dentro del espacio de direcciones del kernel. Tambin, puede colgarse algn mdulo, entonces el kernel se cuelga, tcnicamente el thread se cuelga
pero tiene las mismas repercusiones.
Estos problemas pueden sonar un poco exagerados pero se tiene que tratar con
mucho cuidado. Adems si hay un kernel panic, raramente se sabe que demonios
ha pasado, porque simplemente el sistema operativo deja de funcionar. La tpica
solucin es mirar aquellos printk que creemos han causado el error, y esperar
que podamos verlos al rebotar la mquina y no se hayan perdido. Y todo esto
117
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 mquina virtual despus de un
triste kernel panic, supongo que debido a una mala inicializacin 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 programacin en una mquina diferente, mntalo como sea, ya sea con NFS, con ftps, o con mquinas virtuales mientras
esta no acceda directamente a una particin del ordenador donde se est trabajando. Los ficheros permanecen seguros en otra mquina. An as no se ahorra uno
tiempo teniendo que hacer los e2fsck incluso para los sistemas ext3, despus de
un kernel panic.
As que, con todo esto no sorprende que poca gente haya entrado en la programacin 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:
Im afraid that Ive 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 cdigo fuente para resolver los problemas y los bugs
del kernel. Adems que resolviendo bugs mirando slo 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 cdigo.
Pero tambin 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 raz del problema observando el cdigo. 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 cdigo y pensar qu est sucediendo.
118
7.2 Uso del debugador
3. Intentar concentrasrse en las posibles causas de los sntomas que se ve en

el debugador. Entonces pensar las posibles causas hasta la raz del problema. Escibir una lista de posibilidades, ponindolas en orden de parecido
al problema y probndolas una a una. El proceso de clarificacin de ideas
escribindolas puede ser de gran ayuda.
4. Hasta que se tenga ms experiencia, se debera usar el debugador para probar algunas ideas probando valores de variables.
Por eso el debugador es una herramienta para estimular la razn, y el pensamiento
lgico para averiguar que est sucediendo en el cdigo. 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 cdigo antes de empezar a jugar con el debugador. Se es mucho
ms productivo si se tiene en mente el cdigo, 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 ms intentos, que es posible que fallen, pero tambin es posible
que no.
3. Si las presunciones son incorrectas, hay que aprender de porqu esa presuncin est mal, es importante que no se repita, porque a lo mejor la prxima
vez no nos rebentar a nosotros, sino a otros, o peor an que de un kernel
panic cuando tenemos un ordenador en produccin.
4. Descartar el debugador cuanto antes mejor. Trabajar en el cdigo.
Qu no hacer:
1. Ignorar las causas reales del problema que podamos pensar. Cuando se encuentra que algo est mal, no hacer que funcione para este o ese otro caso,
para que parezca que funciona. Un ejemplo clsico es aadir otra seccin a
un statement del switch para cubrir las posibilidades que no se hayan pensado.
119
7.3 printk
2. Resolver ciegamente un problema con el debugador. Se puede llegar a conclusiones errneas 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 funcin printk es la forma que se tiene de guardar logs del sistema y pasarlos 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 interrupcin [RU1], pero debe usarse con cuidado: si la mquina tiene su consola saturada de mensajes printk no es til. Usa un
formato muy parecido y casi compatible con la funcin printf del ANSI C, y la
concatenacin 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 autntico cuando se escribe en vez de usar printf en
un programa normal se usa printk. A mi todava no me ha pasado, todava.
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.3 printk
KERN_ALERT: Una situacin que requiere una accin inmediata.

KERN_CRIT: Condiciones crticas, normalmente relacionados con problemas
serios de hardware o software.
KERN_ERR: Usado para indicar errores de condiciones
KERN_WARNING: Warnings sobre situaciones problemticas que en s no pueden 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 informacin
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 ms pequeos representando las prioridades ms altas. [ALS].
Basndose 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 estn ejecutndose en el sistema, los mensajes del
kernel se aaden a /var/log/messages o donde se haya configurado con el syslogd.
Si el klogd no se est ejecutando, los mensajes no se mostrarn en el espacio de
usuario, a no ser que se lea /proc/kmsg. La variable console_loglevel se inicializa a DEFAULT_CONSOLE_LOGLEVEL y puede ser modificada a travs 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 fcil de usar, haces un printk y si luego
hay un kernel panic, pues se mira hasta donde ha ido. Fcil y sencillo. Adems de
poder usarse siempre, incluso dentro de una interrupcin.
121
7.4 Oops
Pero tiene varios inconvenientes. Si por ejemplo tenemos un error puetero,

como por ejemplo que cuando empezamos a leer de un device, por ejemplo, nosotros 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 haba pasado, en estos casos los printks que estaban a punto de escribirse no lo hubiesen hecho y luego uno duda si realmente los ltimos printks es
realmente lo ltimo que se ha hecho. As que es necesario usar adems del printk
otros mecanismos para debugar el cdigo y los errores.
7.4. Oops
Cuando el kernel detecta que existe una condicin de anomala seria, se dispara un oops. Un oops tiene dos funciones principalmente:
Volcar la informacin de debugging interesante que podemos usar para diagnosticar la causa del problema.
Probar y prevenir que el kernel pierda el control y que cause corrupcin en los
datos, o an peor que se cause dao al hardware, aunque es difcil que suceda, es
posible.
Al principio, un oops parece completamente incomprensible, un montn de
lneas con valores hexdecimales y con datos que parecen crpticos.
![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.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 anatoma de un oops es muy de bajo nivel, adems cada imagen del kernel
tienen un oops especfico. Por eso, se necesita hacer un post proceso para obtener
informacin de donde empezar a hacer el proceso de debugaje. La idea es compilar
123
7.5 Mquinas 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 difcil
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 opcin oops
y est ocupa espacio dentro del kernel, que a pesar de ser pequeo es importante
en proporcin al resto de kernel.
7.5. Mquinas virtuales

Cuando haban los mainframes, y la misma mquina se comparta entre varios sistemas naci la idea de mquinas virtuales. Una mquina virtual es una
encapsulacin de un ordenador a tu entera disposicin. Un programa dentro de
una mquina virtual no tiene acceso real al hardware fsico. Todo el acceso al
hardware se controla mediante la mquina virtual, que emula al ordenador. Es una
interfaz entre el programa y la mquina real.
La idea es tener un ordenador con un sistema operativo sobre el que se trabaja, donde se edita y se compila el cdigo. Tener bajo este sistema operativo
un programa que sea una mquina 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 kernel panic, o sobreescribe datos del disco, solo le afecta a la mquina virtual. Y as
mientras se reinicia el sistema se puede seguir trabajando con la misma sesin. Al
ordenador fsico no le pasa nada.
Existen dos posibilidades, de mquinas virtuales: una que es la VMware (Virtual Machine ware) y otra de libre distribucin 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 mquinas x86 y sobre ordenadores basados en chips de Motorola como los
Macintosh. La versin para Linux que se puede bajar por Internet cuesta 299$ US.
124
7.6 Debugando con dos mquinas
VMware emula una mquina x68, con alguna caracterstica, 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 opcin, es gratuito, pero tiene un inconveniente y es que no
es una mquina 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 estn protegidos, el sistema de ficheros virtual
se puede descargar, se pueden ejecutar varias mquinas en una sola, y lo mejor
es que es muy fcil usar el degubador para el kernel. No se necesita comprar
ms hardware para hacer los tests, al menos que se est programando un device
especfico.
Ejecutar el UML es fcil, hay que bajar los binarios y luego, o bien instalar un
nuevo sistema o bien bajarse uno que ya est prehecho de la pgina web. A pesar
de algunos inconvenientes del sistema UML, tiene una ventaja muy buena a la
hora de programar algn 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 versin original, as que ya no hay que hacer los
fscks.
7.6. Debugando con dos mquinas

Esta solucn pasa por tener dos mquinas 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 mquina de desarrollo y tener un terminal de consola abierto al
segundo ordenador. Hay que montar dos mquinas, mquina de trabajo y la otra
mquina te testeo, donde se ejecutarn los kernels en desarrollo.
125
Hardware
La primera mquina tiene el sistema operativo de desarrollo con una tarjeta ethernet. La segunda mquina, 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. Tambin necesita una Ethernet, aunque lo mejor es tener dos Ethernets en esta mquina y as poder pasar paquetes
a travs 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 remotamente. Los cables serial necesitan tener esta disposicin:
Solder-side pins:
\-----------------------/
\
1
\
2
6
3
7
4
8
5
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 mquina que es el servidor para conexiones del tipo ssh (Sercure SHell), con este servidor no solo se
pueden hacer conexiones de consola con una shell tambin se puede hacer transferencias de ficheros mediante conexiones seguras a modo de ftp. Que servirn
para traspasar ficheros. Configurar el sistema de tal modo que haya acceso a la
segunda mquina desde la primera. Dar permisos de lectura/escritura a /dev/ttys0
y a /dev/ttyS1que corresponden a los puertos serie. Instalar minicom en ambas
mquinas, es un programa para hacer telecomunicaciones entre sistemas UNIX y
puede encontrarse en http://www.netsonic.fi/~walker/minicom.html.
Para la preparacin del kernel se tardar ms tiempo. Es necesario bajarse
el kernel 2.4.18 y descomprimirlo en la mquina 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 aadir a la configuracin 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 mdulos, as cuando pasemos los ficheros habr que pasar solo la imagen
del kernel.
Tras esto hacer un make dep bzImage como de una compilacin del kernel
normal y corriente. Copiar la imagen a la segunda mquina, tambin 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 mquina, y desde la cuenta de root, copiar la imagen del

kernel al directorio /boot y aadir las siguientes lneas en la configuracin 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 lnea 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 adems 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 seccin de compilar el kernel la solucin.
En la mquina de desarrollo hay que crear un fichero llamado .gdbinit en el directorio raz del cdigo fuente del kernel, este fichero debe contener las siguientes
lneas:
define rmt
set remotebaud 38400
target remote /dev/ttyS0
end
Ejecutar en esta mquina 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
Lockfile Location
: /dev/ttyS1
: /var/lock
Callin Program
Callout Program
Bps/Par/Bits
:
:
: 9600 8N1
Hardware Flow Control

Software Flow Control
: No
: No
Luego guardarlo en la opcin Save setup as dfl y tras guardar la configuracin

como defecto salir. As dejar luego al minicom esperando una sesin.
Rebotar la segunda mquina y entonces aparecer en la primera por la salida
del minicom las siguientes lneas:
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,
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 configuracin a dado resultado.
En la primera mquina tenemos que arrancar el debugger apretando gdb vmlinux>(en la raz del directorio del cdigo fuente) y entonces arrancar el gdb y
mostrar una informacin sobre el programa y aparecer una lnea 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
(gdb)
if (initialized) BREAKPOINT();
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 DISEO DE LA APLICACIN
8. Diseo de la aplicacin
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 ms importantes del UML no puedan crearse. An as UML es suficientemente verstil
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 diseo de la estructura, y otro diagrama dinmico, para tener una vista
del funcionamiento.
Los siguientes puntos detallan los diferentes diagramas del proyecto: un diagrama de casos de uso, dos diagramas de actividades y otro diagrama de secuencia.
8.1.1. Casos de uso
Casos de Uso es una tcnica para capturar informacin de cmo un sistema o
negocio trabaja, o de cmo 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
Cargar
polticas
Leer
logs
Administrador
Ver
estadis.
Las cargas de polticas se producen cuando el administrador desea modificar

131
8.1 Esquemas UML
las polticas y tras cambiar el fichero de configuracin se dispone a cambiar las polticas. 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 polticas que estn 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 intentando 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 estadsticas se usa cuando el administrador desea comprobar el funcionamiento 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 estadsitcas del firewall resumidas y
actualizadas en todo momento.
La cronologa de los casos de usos tiene sentido de la siguiente manera: cargar
las polticas al principio, comprobar que funciona con la vista de las estadsticas
y cada cierto tiempo comprobar el estado de la mquina viendo los ficheros log.
8.1.2. Diagramas de actividades
Un estado de actividad representa una actividad: un paso en el flujo de trabajo o la ejecucin de una operacin. Se usan para entender el comportamiento
de una parte del programa. Muestran una vista dinmica del funcionamiento del
programa.
El primer diagrama muestra como se cargan las polticas dentro de las estructuras internas del firewall.
132
8.1 Esquemas UML
Introducir polticas
Parsear
polticas
incorrecto
Mostrar
errores
correcto
Introducir
polticas
CUIDADO!
Semforo de
escritura
Mostrar
resultados
Este esquema representa el proceso de cargado de polticas, lo primero que

se realiza es un parseado del fichero, comprobando que las reglas estn semnticamente bien escritas. Genera los datos de acuerdo con lo leido en el fichero. Si
todo este proceso fuese correcto entonces se introducen las polticas de seguridad
dentro del firewall, habiendo activado el semforo de escritura previamente. En
el caso que el proceso diera errores se mostraran los resultados sin modificar en
ningn 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
8.1 Esquemas UML
Filtrar sk_buff
Filtrado de
un sk_buff
otra bsqueda
CUIDADO!
Semforo de
lectura
Es esta
poltica?
Encontrada
Hay que
hacer log?
log
Pasa el
filtro?
bloquear
printk de
los datos
liberar
sk_buff
pasar
Retornar
sk_buff
Para cada estructura sk_buff que entra dentro del filtro se busca si hay alguna
poltica que pertenezca al sk_buff. El orden de las polticas es importante ya que la
primera poltica que de xito se pasar a la siguiente fase. Si la poltica especfica
muestra que hay que hacer log se guarda mediante el printk los datos del sk_buff
y el resultado de la operacin de filtrado. El syslog ya se encargar de marcar la
fecha y de su escritura en los ficheros de log del sistema. Despus 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
8.1 Esquemas UML
contina 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 relacin que tienen los distintos componentes 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.
Firewall
filtrar()
sk_buff
dev
Kernel
Activar
Semforo
Lectura
recurrencia
polticas
Desactivar
Semforo
Lectura
retornar
resultado
Si bloquear
kfree_skb(skb)
Se observa como interactan 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 semforo de lectura mediante las funciones que ofrece
el kernel. Busca la poltica dentro de las estructuras de datos que tiene el firewall,
y tras encontrarla le pide al kernel que libere el semforo de lectura. Retorna el
135
8.2 Exclusin mutua
firewall el resultado del filtro y si se debe bloquear pues se pide al kernel que libere el bffer correspondiente a ese paquete. Sino se contina como si no hubiera
pasado nada.
8.2. Exclusin mutua

Antes de explicar donde tratar los paquetes y como tratarlos, es importante
hacer un repaso a la teora de exclusin mutua, ya que antes de acceder a cualquier
estructura de datos dentro del kernel hay que averiguar si debe controlarse con
semforos.
8.2.1. La importancia de los semforos
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 semforos, el kernel hace un kernel panic y deja de funcionar
a la mnima. 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 operacin no
vlida y que como resultado pare el sistema. Se hace difcil que se cumplan dichas
condiciones, pero no es as, y por lo tanto hay que asegurarse de cumplir la teora
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 proteccin a los datos de sk_buff tenemos que usar la funcin br_read_lock_bh(BR_NETPROTO_LOCK) para activar el semforo y entrar
en la zona de exclusin mutua que el cdigo se debe proteger mediante semforos.
Y el br_read_unlock_bh(BR_NETPROTO_LOCK) para salir de la zona crtica. La
136
8.2 Exclusin mutua
definicin 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 haca en los anteriores kernels
para proteger zonas de exclusin mutua. El principal inconveniente es que solo
funciona para una sola CPU y por eso se usa ahora softirqs 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 semforo, 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);
..
-Regin CrticaAcceso solo lectura
..
br_read_unlock_bh(BR_NETPROTO_LOCK);
El mecanismo que nos ofrece es vastante complejo, ya que en si se usa una arquitectura i386, ia64 o una x86_64 se pueden usar operaciones atmicas, y para el
resto de casos no se usan los locks atmicos.
Estos semforos son solo para proteger los datos para lectura, cuando se desee
hacer una escritura a los datos se debe usar los semforos para protegerlos de las
escrituras. Porque cuando se protege para lectura pueden acceder muchos mecanismo, pero cuando se accede para escritura solo puede entrar uno, en esos casos
se usan los locks de escritura.
137
8.2 Exclusin mutua
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
regin crtica para hacer lecturas. Entonces para proteger los datos en las escrituras
hay que usar otros semforos. Cada vez que se quiera hacer una escritura a los
datos, como por ejemplo cuando se guarda las polticas 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 funcin protege la regin crtica de ser escrita y tambin de que no
se lea. Tiene un control total de los datos. Y la segunda operacin desprotege la
regin crtica y permite el acceso a los datos para el siguiente proceso. Como es
lgico no se puede poner una de estas funciones sin la otra, una activa el semforo
y el otro lo desactiva. Y es muy importante que el uso de este proceso sea mnimo
para no afectar al sistema haciendo que vaya ms lento, y cuando se tenga que
usar las operaciones que contenga tienen que ser pocas y rpidas.
As por ejemplo cuando se tenga que eliminar las polticas, lo que se llama
hacerle un flush de los datos, se debera de programar algo parecido a esto:
br_write_lock_bh(BR_NETPROTO_LOCK);
..
-Regin CrticaAcceso escritura
..
br_write_unlock_bh(BR_NETPROTO_LOCK);
Y dentro de la regin crtica se puede escribir a los datos porque nadie ms accede
a ellos. Hay un ejemplo de este mecanismo, se encuentra en net/core/dev.c y se usa
138
8.3 Filtrado de paquetes
para hacer una llamada a una funcin y hacer que esta sea atmica 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 funcin por parmetros, se activa el semforo para la
proteccin de escritura, se llama a la funcin y luego cuando esta termine se desactiva el semforo que asegura la exclusin mutua. Esta funcin se llama dentro
de los drivers y hace que la funcin que se le pasa como parmetro sea atmica. Es
un mecanismo que ofrece el kernel para los desarrolladores de drivers. Y se debe
reusar este cdigo, 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 semforos, seran poco portables.
8.3. Filtrado de paquetes

El objetivo es poder insertar polticas de seguridad donde se pueda distinguir
para cada paquete si entra o si sale, la interfaz y la informacin de la cabecera
IP. La solucin 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 constantes 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 aplicacin MyWall, INPUTINT o bien OUTPUTINT segn 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 informacin 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 informacin 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
despus de hacer los chequeos a la cabecera IP, all se inserta la funcin que llama
al filtro. Si el resultado de la bsqueda 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 funcin ip_rcv:
/*
* Main IP Receive routine.
*/
int ip_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *
{
...
...
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 cdigo, en caso
de compilar el kernel sin las opcciones de mi filtro (llamado mywall) el compilador extraera las lneas de cdigo 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 cdigo tal cual, apareciendo las funciones que estn incluidas dentro de la definicin.
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 paquete a la interfaz de salida. Que corresponden a las constantes MW_INTPUTINT_OUT
y para MY_OUTPUTINT_IN. Estn situados en el fichero net/ipv4/ip_forward.c,
en la funcin 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;
...
// Filtro MW_INPUTINT_OUT
...
#endif
iph = skb->nh.iph;
141
/* Route we use */
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) calculado por la tabla de routing. Antes de pasar el segundo hook debe calcularse el
TTL, operacin 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 mensajes. Esta funcin 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 capturado saliendo, as se consigue la informacin 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 informacin, se usa para
describir el movimiento de los datos de red entre las capas de los protocolos. La
definicin de la estructura de datos es muy importante, es la representacin de
todos los datos, y siempre que se quiera acceder o realizar alguna operacin a los
datos de red se debe hacer a travs de esta estructura. La definicin se encuentra
en include/linux/skbuff.h y la implementacin 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 tamao
y la mscara. 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 cuntos 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 dnde 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 haba dos
lugares donde poda 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 funcin iprcv( ) el buffer debe ser destruido con la funcin kfree_skb( )
o bien debe pasarse el buffer a la funcin 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 polticas concordaba algn
drop. En el segundo caso es porque habra llegado a un pass.
Cuando el paquete est saliendo del sistema y se ha capturado en ip_output.c
dentro de la funcin ip_fragment( ) el paquete debe ser eliminado usando la funcin kfree_skb( ) si no pasa las polticas de seguridad o bien debe enviarse a la pila
de salida mediante la funcin IP_INC_STATS( )
144
9 IMPLEMENTACIN DEL FIREWALL
9. Implementacin del firewall

En este captulo se narra los resultados conseguidos despus del desarrollo,
como los problemas y las experiencias ms importantes tanto a la hora de debugar
como a la hora de tratar con los semforos. Despus 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 escenarios que son ms dificiles de probar. Por ejemplo, tena que probar como el
firewall bloquea paquetes, no solo que le llegan a l y los bloquea cuando debe,
sino que adems tiene que enviarlos a otras interfaces correctamente cuando no
debe bloquearlos. El proceso es el siguiente: nada ms entrar el paquete tiene que
pasar, las polticas del firewall, despus ir al servicio routed, que es el demonio
encargado de dirigir los paquetes a la interfaz adecuada segn su direccin ip destino. Tras pasar por este servicio los paquetes deben pasar otra vez por el firewall
y sus polticas.
No es factible trabajar con un kernel inestable y a la vez usar el mismo para
guardar los cambios. Es necesario trabajar como mnimo con una mquina virtual, 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 mquina
virtual. Porque la mquina 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 solucin 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.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 ms inestable, as que no tenemos
ninguna garanta que llegue correctamente el paquete aunque solo sea para entrar
en la consola y ver como est trabajando el kernel recin compilado. Por lo que
hay que conectar las dos mquinas como se ha explicado en el captulo de hacking
el kernel, en el apartado de debugando con dos mquinas.
Pruebas
Desarrollo
Cable serie
Debugador + Consola
Firewall
Router
Salida
Cable Ethernet
NIC
Paquetes IP
NIC 1
NIC 2
9.1.2. Semforos
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 polticas. Al llamar a la funcin para recoger la estructura sk_buff, al principio de todo
lo que hice fue que me mostrar la informacin 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 informacin ms de poca importancia. La cuestin era averiguar
si capturaba todos los paquetes, como trabajar con las estructuras sk_buff y entonces empezar a implementar las listas y las comparaciones que haba diseado con
el UML. Este era el cdigo que pretenda implementar dentro de mi funcin:
// Imprime la info del sk_buff:
//
//
//
N. de protocolo;
IP origen : puerto origen;
IP destino : puerto destino;
//
//
tamao total; Tipo de Servicio

id; fragment offset; time to live
146
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 mquina
virtual y la arranqu con el nuevo kernel recin compilado. Cual fue mi sorpresa
que nada ms intentar hacer un login como cualquier usuario el ordenador me daba
un kernel panic y tenia que reiniciar la mquina. Era extrao 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
sesin Telnet o bien mediante una sesin 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 haca pues tena que reiniciar la mquina virtual otra
vez, luego haca un chequeo del sistema de ficheros para comprobar que estaba
correcto, tardaba mucho tiempo y no haca nada.
Por qu me daba aquel kernel panic si lo nico que estaba haciendo era mostrar por pantalla y por el sistema de ficheros de log unos simples mensajes, algo
que por separado haba funcionado perfectamente. Entonces haba que instalar el
debuggador, hacerle un trace por el kernel y averiguar qu demonios le estaba pasando. No voy a explicar como debugu el kernel, pues hay un captulo entero que
habla de ello. Pero lo que averig era que estaba dando errores cada vez que accedia a los datos del sk_buff que le estaba pasando. No haba protegido el acceso
a los datos con ningn spinlock! grave error que me haba supuesto una semana
entera de trabajo!
147
9.2 Escenario
Las conclusiones a las que llegu fueron varias: haba aprendido, a parte que
me estaba dando cuenta de donde me haba metido, primero la importancia que
tenan los semforos, tena que aprender como funcionaban y luego como los
deba 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 prohibira acceder por el mismo puerto de consola. Tercero, que
el kernel a la mnima sospecha que tiene de que se est incumpliendo la calidad de
preemptivo hace un kernel panic, antes de que se dae 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 semforo, as que siempre que se accede a datos protegidos
con semforos las operaciones tiene que ser lo ms rpido que se pueda. Estas son
las conclusiones a las que llegu, puede que estn equivocadas, pero lo dudo.
Pero me haba servido para algo: me haba dado cuenta de la importancia de los
semforos y haba aprendido a debugar el kernel.
Cuando le puse la proteccin 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 razn a la primera hiptesis: al acceder mediante consola lo hace usando TCP/IP y se enva paquetes del puerto 745 al 111. Por otra parte ahora
se poda acceder mediante SSH y mediante Telnets, funcionaba todo correctamente.
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 Escenario
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 algn 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).
Nuevo Kernel
Generador de paquetes
Firewall
Router
Salida
RedB
RedA
NIC
NIC 1
NIC 2
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 aaden las lneas
necesarias en la configuracin del lilo, y se ejecuta el lilo y se rebota la mquina.
Todos estos procesos estn correctamente explicados en la parte terica.
9.2.3. Configurar el firewall
Una vez arrancado el ordenador donde reside el nuevo kernel con el firewall, hay que editar el fichero de configuracin del firewall. Este fichero es el
/etc/mywall.conf. En este fichero se definen los comentarios con las lneas que
empiezan con un # y entonces cada lnea corresponde a una poltica del firewall.
149
9.2 Escenario
La sintaxis de las rdenes del firewall son las siguientes:

interfaz
int
ip origen
mask
puerto
puerto
entrada
salida
ip destino
todas
mask
pasar
registrar
bloquear
todas
Donde pone int, se debe poner la interfaz, luego se puede indicar si de entrada, si es de salida o si es indistinto su sentido respecto la interfaz, se muestra la
direccin IP origen con su mscara o bien any para todas las ip, despus se indica
el nmero de puerto origen, y se repite con la direccin IP destino con su respectiva mscara o bien con un any para indicar cualquier IP destino, luego viene el
nmero 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 tambin por nmero de puerto, o bien ambos
conjuntamente.
Insertar entonces en el fichero /etc/mywall.conf las siguientes lneas:
#
# nombre int
#
sentido
IPorig
interfaz eth0 entrada

todas
todas
todas
interfaz eth1
todas
IPdest
pas/bloq
10.1.0.1/32:80
pasar
10.1.0.1/32:23
pasar
todas
bloquear
todas
registrar
registrar
pasar
De esta manera solo se permitir ver la pgina web y el Telnet de la mquina

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 estn
las configuraciones.
150
9.2 Escenario
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 travs del ordenador firewall. As
que podemos poner los nmeros de red:
RedA 10.2.0.0/16
RedB 10.1.0.0/16
Primer ordenador: eth0 10.2.0.1 mscara 255.255.0.0
Segundo ordenador: eth0 10.2.0.2 mscara 255.255.0.0
eth1 10.1.0.2 mscara 255.255.0.0
Router: eth0 10.1.0.1 mscara 255.255.0.0
ruta esttica a 10.2.0.0 / 16 por 10.1.0.2
En el router se ha activado el servidor web y un servidor telnet. Tambin es recomendable que se le active algn otro servicio, que servir para comprobar como
el firewall bloquea el puerto y no se recive ningn paquete de dichos servicios, ya
que el firewall habra bloqueado la salida.
9.2.5. Resultados
Los resultado se pueden observar porque debera 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 estadsticas 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 conclusin 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 documentacin al respecto es escassima, no hay ningn documento en
castellano a parte de este trabajo. Casi todos los documentos tan solo se encuentran
en Internet, y los temas tan especficos como la creacin de un firewall solo puede
averiguarse preguntando a los desarrolladores del kernel, pero teniendo en cuenta
que es un grupo que no facilitan aquella informacin que consideran trivial, se
hace ms difcil el aprendizaje.
Otra conclusin a la que se llega es que trabajar dentro de un sistema operativo
es una tarea muy compleja. Cada vez que se efecta algn cambio por pequeo
que sea hay que recompilar todo el kernel, instalarlo y rebotar la mquina con el
nuevo sistema operativo. Tampoco se puede trabajar sobre un kernel y probarlo
a la vez sobre la misma mquina, ya que un kernel en desarrollo puede daar
los datos guardados en disco facilmente. Y como no hay ningn mecanismo que
proteja al sistema operativo de hacer operaciones ilegales cuando hace un core
dump se para toda la mquina siendo muy dificil hacer un diagnstico de lo que
ha pasado. Por todas estas razones es importante aprender como se se ejecuta un
kernel en desarrollo en una mquina virtual o en otra mquina conectada a la
desarrollo y a la vez tambin como poder debugar este kernel en desarrollo.
La programacin dentro del kernel debe hacerse con sumo cuidado. Toda estructura que se cree y que puede ser accedida por varios threads a la vez debe
protegerse con semforos. El kernel dispone de funciones para llamar a los semforos, donde se puede indicar si se desea una proteccin de lectura o de escritura.
Si no se cumplen con la teora de los semforos lo ms lgico es que de un kernel
panic y se pare el kernel cuando se est accediendo desde dos lugarles a la misma
estructura de datos. Tambin es importante tener el mnimo nmero de variables
estticas, pues ocupan un espacio vital dentro del kernel. Toda estructura debe
hacerse dinmica, y aqu el kernel tambin dispone de funciones para crear listas
dinmicas de una forma muy sencilla.
Lo ms laborioso ha sido resolver estos problemas de trabajo dentro del kernel
y hacer el montaje del escenario para hacer las pruebas. Para bloquear haba que
152
10 CONCLUSIONES
probar que ciertos paquetes pasaban las polticas y la respuesta tambin retornaba.
Para ello se ha necesitado de tres ordendores, uno emitiendo, otro haciendo de
firewall y el ltimo con algn 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 direccin IP origen y destino, por el
puerto origen y destino, y todo segn la interfaz y el sentido respecto ella.
153
11 LNEAS DE FUTURO
11. Lneas de futuro

Una vez conseguido bloquear paquetes IP segn su direccin IP origen y su
direccin IP destino se puede aadir nuevas funcionalidades que otros firewalls
ms 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 estn
mantiniendo en ese momento y con las polticas de filtrado tratar los nuevos paquetes. Ciertos protocolos, como por ejemplo FTP, H323 entre otros mantienen en
sus conexiones unas sesiones caractersticas debido a que el cliente y servidor hacen 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 telemtica
puede ser un TFC.
Muchos firewalls son los encargados de hacer NAT (Traduccin de direcciones), ya que estn situados justo en el borde de la red a proteger y otra red. Haciendo NAT la red a proteger puede tener IP privadas que no funcionan en Internet,
as se hace muy difcil hacer un ataque spoofing emulando un ordenador interno.
Para hacer NAT se debe mantener tambin informacin de todas las sesiones en
curso mediante unas tablas. Donde se guarda todas las sesiones en curso y las traducciones que se estn usando. Es un proyecto con un coste aproximado de 600
horas, y tambin puede ser un TFC.
La tercera propuesta es hacer un balanceo de carga entre firewalls. El problema de los firewalls es que la mayora no estn 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 mquinas donde se puedan comunicar de forma segura
y poder cambiar informacin de las tablas de sesiones. Esta propuesta es mucho
ms avanzada y compleja, no solo son necesarios conocimientos de sistemas operativos y de telemtica, sino que es neceario tener conocimientos de arquitecturas
avanzadas y de programacin paralela. El coste es aproximadamente de unas 1000
horas y podra hacerse en un PFC por varias personas.
154
12 COSTE DEL TRABAJO
12. Coste del trabajo

El coste del proyecto se divide en documentacin sobre firewalls, documentacin UML, documentacin sobre el kernel de linux, pruebas programando y
debugando el kernel, programacin de la aplicacin, experimentacin y pruebas
de su correcto funcionamiento y por ltimo la memoria.
Se considera documentacin sobre firewalls la bsqueda de la informacin
sobre los protocolos TCP/IP y sobre los firewalls. La documentacin UML se
basa en el estudio de la metodologia del UML. Por ltimo la documentacin del
kernel de linux se enfoc para averiguar cmo trabajar dentro del kernel.
La parte prctica comprende las pruebas programando y debugando el kernel,
donde se pona en prctica todo lo ledo referente a la programacin dentro del
kernel, de su debugado y del montaje del escenario para su funcionamiento. La
programacin de la aplicacin es el tiempo destinado a la construccin del firewall. 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 preparacin
de la memoria.
155
Teora
Prctica
Memoria
Tema
Horas
Porcentaje
Firewalls
40 h
6,2 %
UML
Kernel
60 h
140 h
9,3 %
21,6 %
Total Teora
240 h
37,1 %
Estudio del Kernel

Programar Firewall
180 h
65 h
27,9 %
10 %
Implementacin escenarios
22 h
3,4 %
Total Prctica
267 h
41,3 %
Total Memoria
140 h
21,6 %
Total
647 h
100,0 %
156
Bibliografa
[ALS] RUBINI , A LESSANDRO ; Linux Device Drivers, 2nd Edition; ORelly;
2001. ISBN: 0-59600-008-1
[DAV] F RASCONE , DAVID ; Debugging Kernel Modules with User Mode
Linux; Mayo 2002 LinuxJournal
[GI1] I NSOLVIBLE , G IANLUCA ; Inside the Linux Packet Filter; Febrero
2002 LinuxJournal
[GI2] I NSOLVIBLE , G IANLUCA ; The Linux Socket Filter: Sniffing Bytes
over the Network; Junio 2001 LinuxJournal
[GOO] G OOGLE G ROUPS; comp.os.linux.misc
[KAH] A RCOMANO , ROBETO; Kernel Analysis- HOWTO; 2002.
http://www.tldp.org/HOWTO/KernelAnalysis-HOWTO.html
[KAL] K ALE , A MIT S.; Kdbg: Linux kernel source level debugger; 2002
http://kgdb.sourceforge.net/
[KE1] K ERNEL D OCUMENTATION ; Coding Style; linux/Documentation/CodingStyle
[KRO] K ROAH -H ARTMAN , G REG; Proper Linux Kernel Coding Style; Julio 2002 LinuxJournal
[LIS] L INUX K ERNEL M AILING L IST A RCHIVES ; Desde 1997; http://www.cs.Helsinki.FI/linux/l

kernel/
[LT1] TORVALDS , L INUS ; 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] S TEVENS , W. R ICHARD; Advanced Programming in the UNIX
Environment; Addison-Wesley Ed.; 1992. ISBN: 0-201-56317-7.
[UML] RUMBAUGH , JAMES ; JACOBSON , I VAR ; B OOCH , G RADY; El Lenguaje Unificado de Modelado. Manual de Referencia; Addison Wesley Ed.
2000. ISBN: 84-7829-037-0.
[VAS] VASUDEVAN , A LAVOOR ; CVS-RCS-HOWTO Document for Linux;
http://www.tldp.org/HOWTO/CVS-RCS-HOWTO.html
[WAR] WARD , B RIAN; The Linux Kernel HOWTO;
http://www.tldp.org/HOWTO/Kernel-HOWTO.html
[WS1] W RIGHT, G ARY R.; S TEVENS , W. R ICHARD ; TCP/IP Illustrated,
Volume 1 The Protocols; Addison Wesley Ed.; 1994. ISBN: 0-201-633469.i
[WS2] W RIGHT, G ARY R.; S TEVENS , W. R ICHARD ; TCP/IP Illustrated,
Volume 2 The Implementation; Addison Wesley Ed.; 1995. ISBN: 0-20163354-X.
158
Parte III
Anexo A sk_buff
A continuacin 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
travs de <linux/skbuff.h>, est formada por:
struct sk_buff {
struct sk_buff
struct sk_buff
* next;
* prev;
struct sk_buff_head * list;

struct sock
*sk;
struct timeval stamp;
struct net_device *dev;
union {
struct tcphdr
*th;
struct udphdr
struct icmphdr
*uh;
*icmph;
struct igmphdr *igmph;

struct iphdr
*ipiph;
struct spxhdr*spxh;
unsigned char
*raw;
} h;
/* Network layer header */
union {
struct iphdr
*iph;
struct ipv6hdr
struct arphdr
*ipv6h;
*arph;
struct ipxhdr
unsigned char
*ipxh;
*raw;
} nh;
159
union {
struct ethhdr
unsigned char
} mac;
struct
*ethernet;
*raw;
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
unsigned int
len;
data_len;
unsigned int
unsigned char
csum;
__unused,
cloned,
pkt_type,
ip_summed;
__u32
atomic_t
unsigned short
priority;
users;
protocol;
unsigned short
unsigned int
security;
truesize;
unsigned char
unsigned char
*head;
*data;
unsigned char
*tail;
unsigned char
*end;
void (*destructor)(struct sk_buff *);
#ifdef CONFIG_NETFILTER
/* Can be used for communication between hooks. */
unsigned long
/* Cache info */
__u32
nfmark;
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 tamao 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 Style

Existen unas reglas bsicas, escritas y no escritas, para asegurarse que otros
usuarios del kernel. Existe unas reglas escritas en la propia documentacin de Linux [KE1] y otras reglas no escritas [KRO] pero que se supone todo programador
conoce.
Como el nmero de desarrolladores que miran el cdigo fuente del kernel de
Linux es muy grande, lo mejor es tener una gua consistente a seguir. As es ms
fcil 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 cdigo. Que
es eso de lo que se trata todo esto del cdigo abierto o open-source.
Indexacin
Todos los tabulados son ocho carcteres en blanco y ser eso el caracter <TAB>.
Hace que sea ms facil localizar donde estn los diferentes bloques de cdigo. Hay
que intentar evitar que haya ms de tres niveles de indexacin, ya que puede causar que navegar por el cdigo sea muy incmodo, pues las lneas sobrepasan el
tamao de la pantalla.
Poniendo corchetes
Los autores originales de UNIX ponan los corchetes con el corchete que abre
al final de la primera lnea y el corchete que cierra al principio de la ltima lnea:
if ( x >= 1 ) {
hacer_lo_que_sea();
}
Por eso, el kernel de Linux usa este estilo. La nica excepcin a esta regla son
las funciones, las cuales se tienen el corchete que abre al principio de la segunda
lnea:
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
cdigo fuente.
Nombrar variables y funciones
Para nombrar las variables y funciones deberan 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 deberan ser cortas. Para las variables de los bucles puede usarse i o j, mientras que contador_bucle es demasiado largo. Las
variables del tipo tmp tambin se permiten pero solo para variables con poco
tiempo de vida.
Tambin se puede encontar buenos ejemplos en el los ficheros del sistema de
ficheros en fs/*.c. Y ejemplos que son negativos tambin pueden encontrarse en
drivers/scsi/cpqfs* .
Funciones
Las funciones deben hacer solo una cosa y hacerla bien. Deberan ser cortas y
ser del tamao de uno o dos pantallas. Si se tiene una funcin que hace pequeas
cosas para muchos casos, es aceptable que sea larga. Pero si es larga y adems es
compleja hay que modificarla.
Dicen que el nmero de variables nos indica la complejidad de la funcin. As
que si se tiene un gran nmero de variables entonces es que hay q cambiarlo.
164
Comentarios
Los comentarios malos explican como trabaja el cdigo, quien escribi tal funcin en una fecha especfica y otras cosas poco tiles. Los comentarios correctos
deben explicar qu hace la funcin y porqu lo hace. Deberan incluirse al principio de la funcin y no necesariamente dentro de ella, porque hay que escribir
funciones pequeas.
Hay un estadar para los comentarios de las funciones, que es una variante del
mtodo de documentacin usada en el proyecto GNOME. Lo bueno de usar este
tipo de estilo es que luego se puede sacar informacin usando compiladores de documentacion. Que puede verse ejecutando make psdocs o bien make htmldocs
para generar un fichero postcript o html para cada caso. Para ms informacin
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 aade un contador de referencias una estructura, se evitan muchos 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 referencias 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 include/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 representaciones 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 permiten hacer conversiones automticamente, dependiendo donde se compile y de la
arquitectura usar unas funciones u otras.
Listas
Como en cualquier programa se necesitan las listas dinmicas. Para eso debe
usarse las funciones include/linux/list.h. Donde se puede encontrar una estructura: struct list_head, que deberia incluirse dentro de la estructura donde se desee
crear la lista. Entonces se podr usar las funciones de aadir, borrar o iterar sobre
las listas de manera fcil sin tener que reescribir nuevo cdigo. Algunos buenos
ejemplos que he encontrado estn en drivers/hotpluc/pci_hotplug_core.c y en drivers/ieee1934/nodemgr.c.
typdef est prohibido
Los famosos typedef no deberin usarse para llamar a ningn tipo de estructura. La mayoria de las estructuras del kernel no tienen ningn typedef. Ya que hace
ms oscuro el cdigo porque se aaden capas, y no dejan que el programador sepa
qu tipo de dato se esta usando.
Jams 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 ms fcil de conseguir un kernel panic.
El nico lugar donde los typedef son aceptables es al declarar prototipos de
funciones. Estas pueden ser difciles de escribir, asi que haciendo un typedef para
estas se convierte en una forma fcil de escribir.
166

Implementacion de Un Fire Wallas

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Implementacion de Un Fire Wallas

Cargado por

Copyright:

Formatos disponibles

Estudio, diseo e implementacin de

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

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

3. Introduccin a los firewalls

3.2. Qu puede hacer . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2.2. Refuerza polticas . . . . . . . . . . . . . . . . . . . . . .

3.3. Qu no puede hacer . . . . . . . . . . . . . . . . . . . . . . . . .

3.3.2. Conexiones que no van a travs de l . . . . . . . . . . .

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

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

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

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

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

4.4.1. Protocolos difciles . . . . . . . . . . . . . . . . . . . . .

4.5.2. Inbound y Outbound . . . . . . . . . . . . . . . . . .

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

5. El Sistema Operativo Linux

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

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

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

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

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

6. Estudio del Diseo ( UML)

6.1.4. reas conceptuales . . . . . . . . . . . . . . . . . . . . .

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

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

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

7. Hacking del kernel

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

11. Lneas de futuro

12. Coste del trabajo

III Anexo A sk_buff

Anexo B Coding Style

Cada capa tiene diferentes responsabilidades.

2.2 IP: Internet Protocol

2.2. IP: Internet Protocol

2.2 IP: Internet Protocol

Dentro de la especificacin RFC 791, publicada en septiembre del 1981 (http://www.ietf.org/rfc/rfc07

flags and fragment offset

direccin IP origen 32 bits

2.2 IP: Internet Protocol

2.2 IP: Internet Protocol

Este campo indica el tiempo mximo que se le permite a un datagrama mantenerse

2.3 UDP: User Datagram Protocol

2.3. UDP: User Datagram Protocol

Nmero de puerto origen: 16 bits

2.4 TCP: Transmisin Control Protocol

2.4. TCP: Transmisin Control Protocol

2.4 TCP: Transmisin Control Protocol

Por el trmino orientado a conexin se entiende que dos aplicaciones usando

2.4 TCP: Transmisin Control Protocol

previene de que un ordenador rpido llene todos los buffers de un ordenador

Puerto de origen: 16 bits

2.4 TCP: Transmisin Control Protocol

Puerto de origen: 16 bits

2.4 TCP: Transmisin Control Protocol

3 INTRODUCCIN A LOS FIREWALLS

3. Introduccin a los firewalls

3 INTRODUCCIN A LOS FIREWALLS

3.2 Qu puede hacer

3.2. Qu puede hacer

3 INTRODUCCIN A LOS FIREWALLS

3.3 Qu no puede hacer

3.3. Qu no puede hacer