Download Estudio, diseño e implementación de un Firewall

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

Document related concepts

Stream Control Transmission Protocol wikipedia , lookup

Ping wikipedia , lookup

Protocolo de resolución de direcciones wikipedia , lookup

Stunnel wikipedia , lookup

Netfilter/iptables wikipedia , lookup

Transcript

Estudio, diseño e implementación de
un Firewall
C ARLOS G USTAVO M ORALES T EJEDA
Septiembre 2002
Abstracto
Los firewall son los componentes más importantes a la hora de proteger una
red de datos, ya que se encargan de filtrar los datos que pasan a través de él. El
objetivo de este TFC es crear un firewall de filtrado de paquetes bajo un entorno Unix. La dificultad reside en la programación a bajo nivel dentro del sistema
operativo, en la que cualquier error de programación supone una parada del ordenador y porque toda modificación requiere compilar el kernel de nuevo y rebotar
la máquina donde se está ejecutando el firewall
Resumen
Un firewall es el componente más importante a la hora de proteger una red de
ordenadores. Es un sistema incorporado dentro del sistema operativo, encargado
de filtrar los datos que pasan a través de él. El objetivo de este proyecto es hacer
un estudio teórico de los firewalls en un entorno Unix-Linux, para luego poder
diseñar e implementar uno. Así pues, esta memoria está dividida principalmente
en dos partes: una parte teórica y una práctica.
Dentro de la parte teórica hay un breve estudio de los protocolos TCP/IP, que
son los protocolos que usan las redes de datos. El siguiente tema es una introcución a los firewalls, donde se narra las características y los posibles tipos de
firewalls. Se hace un especial incapié en el filtrado de paquetes pues se le dedica
un capítulo entero ya que es el tipo de firewall que se va a implementar. Los firewalls de filtrado de paquetes se basan en las cabeceras de los paquetes de datos
para decidir si deben filtrarse. En el siguiente capítulo se repasa el sistema operativo Linux ya que la programación del firewall va muy ligado con este. Hay un
resumen de sus características principales, de las herramientas que disponemos y
del viaje que realiza un paquete desde que se captura en la misma tarjeta de red
hasta que llega a las apliaciones de los usuarios. El último capítulo es un estudio
del diseño, para poder modelar correctamente cualquier proyecto.
La programación dentro del sistema operativo es muy compleja, llamado 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 capítulo aborda el diseño de la aplicación, que comprende tanto
los esquemas del modelado como la explicación de como se ha programado el
firewall. Después hay un capítulo llamado implementación del firewall, donde se
explican los escenarios que se ha necesitado tanto para desarrollar como para probar los resultados finales.
Los últimos capítulos comprenden las conclusiones, las líneas de futuro que
pueden seguirse, el coste del proyecto y la bibliografía que se ha necesitado.
Índice
I Teoría
1
1. Introducción
1
2. TCP/IP
2
2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1. Capas . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2. Encapsulación . . . . . . . . . . . . . . . . . . . . . . .
2
2
4
2.2. IP: Internet Protocol . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . .
5
5
2.2.2. Cabecera IP . . . . . . . . . . . . . . . . . . . . . . . . .
2.3. UDP: User Datagram Protocol . . . . . . . . . . . . . . . . . . .
2.3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . .
6
9
9
2.3.2. Cabecera UDP . . . . . . . . . . . . . . . . . . . . . . .
2.4. TCP: Transmisión Control Protocol . . . . . . . . . . . . . . . .
9
10
2.4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . .
2.4.2. Cabecera TCP . . . . . . . . . . . . . . . . . . . . . . .
10
12
3. Introducción 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 políticas . . . . . . . . . . . . . . . . . . . . . .
3.2.3. Registrar la actividad . . . . . . . . . . . . . . . . . . . .
3.2.4. Limita la exposición . . . . . . . . . . . . . . . . . . . .
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 través 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. Combinación de técnicas . . . . . . . . . . . . . . . . . .
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. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2. Características . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 difíciles . . . . . . . . . . . . . . . . . . . . .
4.4.2. Polítcas que no pueden aplicarse . . . . . . . . . . . . .
32
33
4.4.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5. Configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 dirección . . . . . . . . . . . . . . . . . . . . . . .
4.7.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . .
4.7.2. Riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
39
40
5. El Sistema Operativo Linux
5.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
42
5.1.1. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
45
5.1.3. Características . . . . . . . . . . . . . . . . . . . . . . .
5.2. El Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . .
46
50
50
5.2.2. Modos . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.3. Módulos . . . . . . . . . . . . . . . . . . . . . . . . . .
50
51
5.2.4. Procesos . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.5. Sincronización . . . . . . . . . . . . . . . . . . . . . . .
5.2.6. Comunicación entre procesos . . . . . . . . . . . . . . .
51
52
54
5.2.7. Control de la Memoria . . . . . . . . . . . . . . . . . . .
5.2.8. El código . . . . . . . . . . . . . . . . . . . . . . . . . .
54
55
5.2.9. Numeración . . . . . . . . . . . . . . . . . . . . . . . .
5.2.10. Compilación del núcleo . . . . . . . . . . . . . . . . . .
5.3. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
59
65
5.3.1. Editores de texto . . . . . . . . . . . . . . . . . . . . . .
5.3.2. Herramientas de desarrollo . . . . . . . . . . . . . . . . .
65
68
5.3.3. Navegación . . . . . . . . . . . . . . . . . . . . . . . . .
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. Introducción . . . . . . . . . . . . . . . . . . . . . . . .
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 Diseño ( UML)
6.1. Introducción 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. Características 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. Envío de mensajes . . . . . . . . . . . . . . . . . . . . . 104
6.6.3. Acciones . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.7. Diagramas de actividades . . . . . . . . . . . . . . . . . . . . . . 106
6.7.1. Notación . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.8. Diagramas de Interacción . . . . . . . . . . . . . . . . . . . . . . 108
6.8.1. Colaboración . . . . . . . . . . . . . . . . . . . . . . . . 109
6.8.2. Interacción . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.8.3. Patrón . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.9. Diagramas de Componentes . . . . . . . . . . . . . . . . . . . . 110
6.9.1. Componentes . . . . . . . . . . . . . . . . . . . . . . . . 112
6.10. Diagramas de Despliegue . . . . . . . . . . . . . . . . . . . . . . 113
6.11. Los paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
II Práctica
117
7. Hacking del kernel
117
7.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
7.2. Uso del debugador . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.3. printk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
7.4. Oops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
7.5. Máquinas virtuales . . . . . . . . . . . . . . . . . . . . . . . . . 124
7.6. Debugando con dos máquinas . . . . . . . . . . . . . . . . . . . 125
8. Diseño de la aplicación
131
8.1. Esquemas UML . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
8.1.1. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . 131
8.1.2. Diagramas de actividades . . . . . . . . . . . . . . . . . 132
8.1.3. Diagrama de secuencia . . . . . . . . . . . . . . . . . . . 135
8.2. Exclusión mutua . . . . . . . . . . . . . . . . . . . . . . . . . . 136
8.2.1. La importancia de los semáforos . . . . . . . . . . . . . . 136
8.2.2. Locks de lectura . . . . . . . . . . . . . . . . . . . . . . 136
8.2.3. Locks de escritura . . . . . . . . . . . . . . . . . . . . . 138
8.3. Filtrado de paquetes . . . . . . . . . . . . . . . . . . . . . . . . . 139
8.3.1. ip_input.c . . . . . . . . . . . . . . . . . . . . . . . . . . 140
8.3.2. ip_forward.c . . . . . . . . . . . . . . . . . . . . . . . . 141
8.3.3. ip_output.c . . . . . . . . . . . . . . . . . . . . . . . . . 142
8.3.4. El sk_buff . . . . . . . . . . . . . . . . . . . . . . . . . . 143
8.3.5. Operaciones . . . . . . . . . . . . . . . . . . . . . . . . . 144
9. Implementación del firewall
145
9.1. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
9.1.1. Debugar . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
9.1.2. Semáforos . . . . . . . . . . . . . . . . . . . . . . . . . 146
9.2. Escenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
9.2.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 149
9.2.2. Compilar kernel . . . . . . . . . . . . . . . . . . . . . . 149
9.2.3. Configurar el firewall . . . . . . . . . . . . . . . . . . . . 149
9.2.4. Configurar la red . . . . . . . . . . . . . . . . . . . . . . 151
9.2.5. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . 151
10. Conclusiones
152
11. Líneas de futuro
154
12. Coste del trabajo
155
III Anexo A sk_buff
159
IV
162
Anexo B Coding Style
1 INTRODUCCIÓN
Parte I
Teoría
1. Introducción
En construcción de edificios, un muro de fuego (firewall en inglés) se diseña
para mantener el fuego separado de una parte de un edificio a otra. En teoría, un
firewall de Internet sirve con el mismo propósito: previene de peligros de Internet
a la red interna. El firewall protege la red filtrando toda la información que pasa
a través de él y decidiendo si el tráfico se acepta según las políticas de seguridad.
El firewall es el elemento más importante a la hora de asegurar una red, no es el
único ni tampoco previene de todos los posibles ataques y peligros, pero es un
componente básico.
Siguiendo la comparativa de la construcción, el firewall hace la misma función
que la puerta de nuestra casa, que solo deja pasar a las personas que tengan una
llave que corresponda con la cerradura, al resto de personas no les dejará entrar.
Igual que en cualquier casa tener una puerta muy segura no implica que sea segura, pueden haber otras amenazas como incendios, puertas traseras, etc. Pero una
buena puerta sigue siendo el elemento más importante y un componente básico.
El objetivo de este trabajo es construir un firewall desde cero. El firewall debe
insertarse dentro del sistema operativo, filtrar los paquetes IPv4 según la dirección
origen y destino, según el número de puerto origen y destino, según la interfaz y
el sentido del paquete respecto esa misma interfaz.
1
2 TCP/IP
2. TCP/IP
2.1. Introducción
Es fundamental explicar el conjunto de protocolos que nos sirven para comunicar varios equipos, ya que entendiendo cómo funciona sabremos qué políticas
necesitamos para diseñar la seguridad en una red, bloqueando las transmisiones
no deseadas, que al fin y al cabo es lo que hace un firewall.
La suite de protocolos TCP/IP permite a ordenadores de todos los tipos, de diferentes fabricantes, corriendo sistemas operativos completamente diferentes comunicarse entre ellos. Lo que empezó a finales de los 1960 como un proyecto
de investigación financiado por el gobierno en una red de ordenadores del tipo
packet switching, se ha convertido en el protocolo de red más usado entre ordenadores. Es tal su relevancia que el firewall se construirá sólo y exclusivamente para
redes IP. Hay muchas publicaciones que hablan de esta suite. Forman las bases
para lo que es llamado la Internet mundial, o simplemente Internet, una wide area
network (WAN) de varios millones de ordenadores que envuelven literalmente el
globo.
2.1.1. Capas
Los protocolos de red se desarrollan normalmente en capas, cada una de las
capas es responsable para una faceta diferente de las comunicaciones. Una suite de
protocolos como es el caso de TCP/IP, es la combinación de diferentes protocolos
en varias capas, que normalmente se le considera un sistema de 4 capas o layers.
2
2 TCP/IP
2.1 Introducción
Cada capa tiene diferentes responsabilidades.
1. La capa link, llamada normalmente data-link layer es la interfaz de red que
incluye el driver del sistema operativo para la tarjeta de red. Juntos pueden
tratar todos los detalles del hardware e interactuar físicamente con el cable
o con el medio que se esté usando en cada caso.
2. Capa de red o Network Layer, se encarga del movimiento de paquetes a
través de la red. Para el enrutado de paquetes se usa IP (Internet Protocol),
ICMP (Internet Control Message Protocol) y el IGMP (Internet Group 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 (Transmisión 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 tamaño correcto para la capa de
red, aceptando los paquetes recibidos, marcando tiempos para asegurar que
3
2 TCP/IP
2.1 Introducción
los paquetes de acknowledge enviados, entre otros. Al ser un flujo de datos asegurado la capa de aplicación puede ignorar estos detalles. En cambio
UDP provee una forma mucho más simple de comunicarse. Este simplemente envía paquetes de datos llamados datagramas de un host a otro, pero
no esta garantizado que los datagramas lleguen a la otra parte. Cualquier
control debe añadirse en la capa de aplicación.
4. La última capa, la capa de aplicación trata los detalles del una aplicación en
particular. Podemos encontrar dentro de todas las aplicaciones: telnet para
hacer logins remotos, http para la web, ftp para transferir ficheros, smtp para
enviar correo electrónico, etc
Cada capa tiene uno o más protocolos para comunicarse con las capas vecinas
del mismo nivel entre ordenadores. Un protocolo, por ejemplo el TCP permite
comunicarse entre la parte del emisor y del receptor.
IP es el protocolo principal en la capa de red. Es usado por los protocolos
TCP y UDP. Cada dato de estos protocolos se transfiere a través de la capa de red
usando el protocolo IP, este proceso se llama Encapsulación y se pasa a explicar
en el siguiente punto.
2.1.2. Encapsulación
Cuando una aplicación envía datos usando TCP, los datos son enviados abajo
y los almacena en la pila del protocolo, y así sucesivamente a través de cada capa,
hasta que son enviados como un conjunto de bits por la red. Cada capa o layer
añade información a los datos, normalmente antecediendo a los datos o a veces
añadiendo unos pocos datos al final. La unidad de datos que TCP envía a la pila
de IP se llama un segmento TCP. La unidad de datos que envía IP en la capa 3 a la
capa 2, la de red, se llama un datagrama IP. Y por último el flujo de bits que pasan
por la red Ethernet se llaman frames.
IP debe añadir algún tipo de identificador en la cabecera IP que genera para
indicar a qué capa pertenece. Esto se trata guardando un valor del tamaño de 8
bits en su cabecera llamado campo de protocolo. Si el valor es 1 es para ICMP, si
es 2 es para IGMP, 6 indica TCP y 17 es UDP. Esto nos será muy útil a la hora de
bloquear los paquetes que no se deseen.
4
2 TCP/IP
2.2 IP: Internet Protocol
De forma similar, todas las aplicaciones que usan TCP o UDP deben identificarse. La capa de transporte guarda un identificador en la cabecera que genera
para identificar la aplicación. Ambos protocolos el TCP y el UDP usan números
de puerto de 16 bits para identificar aplicaciones. Se guarda el puerto de origen y
el de destino para identificarlos.
Aunque no sea interesante para el proyecto del firewall también indicar que los
frames de la capa de red que recibe el driver de la tarjeta Ethernet, tienen también
un campo de 16 bits para indicar que capa del protocolo generó los datos.
2.2. IP: Internet Protocol
2.2.1. Introducción
IP es la herramienta principal dentro de la suite TCP/IP. Todos los datos TCP,
UDP, ICMP e IGMP son transmitidos como datagramas IP.
Un dato importante es que el protocolo IP es un protocolo NO orientado a
conexión (conectionless) y NO asegurado.
Por no asegurado se entiende que el protocolo IP no garantiza la llegada a su
destino de los datagramas. IP provee un servicio de mejor esfuerzo (best effort).
Cuando algo va mal como por ejemplo un router no tiene más capacidad en los
buffers de entrada, IP tiene un algoritmo para tratar el error muy sencillo: no hace
caso del datagrama e intenta enviar un mensaje ICMP al origen.
Ser un protocolo no orientado a conexión significa que IP no mantiene ningún
estado de información de los datagramas consecutivos. Cada datagrama es tratado
de forma separada de todos los otros datagramas. Significa que los datagramas
pueden llegar de manera desordenada. Por ejemplo, si un equipo envía dos 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á diseñado para ser retransmitido para ser usado en sistemas
interconectados en redes de comunicaciones packet-switched. Los hosts se identifican por una dirección fija, tanto los ordenadores destinos como los ordenadores
origen, llamadas direcciones IP. Y como he comentado antes no hay mecanismos
para el proceso de conexiones de control de flujo, secuencia de paquetes y otros
mecanismos que se encuentran en protocolos orientados a conexión.
5
2 TCP/IP
2.2 IP: Internet Protocol
Las funciones básicas del protocolo según la especificación RFC0791 son dos:
direccionar y fragmentar. Para direccionar se usan las direcciones que se encuentran en la cabecera. La selección del camino para la transmisión se llama routing.
Lo que interesa de todo esto para el firewall es que el protocolo IP trata a cada
datagrama como una entidad independiente a cualquier otro datagrama. No hay
conexiones ni circuitos virtuales.
2.2.2. Cabecera IP
Dentro de la especificación RFC 791, publicada en septiembre del 1981 (http://www.ietf.org/rfc/rfc07
encuentra la especificación de la cabecera del datagrama.
0
15 16
version
ip_v
header
length
type of service
ip_tos
flags and fragment offset
ip_off
identificación
20 bytes
cabecera
time to live
ip_ttl
31
total length
ip_len
protocolo
ip_p
header chacksum
ip_sum
dirección IP origen 32 bits
ip_src
dirección IP destino 32 bits
ip_dst
opciones
(si las hay)
datos
Versión: 4 bits
El campo de versión indica el formato de la cabecera de Internet. Esta cabecera
corresponde a la versión 4.
IHL: 4 bits
Internet Header Lenght o tamaño de la cabecera, es el tamaño de la cabecera en
palabras de 32 bits, tras la cual empiezan los datos. El valor mínimo de la cabecera
es 5.
TOS: 8 bits
6
2 TCP/IP
2.2 IP: Internet Protocol
Type Of Service o tipo de servicio indica los parámetros para la calidad de servicio
deseado. Estos parámetros suelen usarse para ser una guía del tipo de servicio que
se está retransmitiendo en el datagrama.
Tamaño total: 16 bits
El tamaño total es el tamaño del datagrama, medido en octetos, incluyendo el tamaño de la cabecera y de los datos. El tamaño de 16 bits permite que el datagrama
sea hasta 65.535 octetos. El tamaño de dichos datagramas es impracticable en la
mayoría de redes y ordenadores. Todos los ordenadores tienen que estar preparados para aceptar datagramas de hasta 576 octetos.Si se quiere saber más sobre la
configuración de LILO, hay que obtener la versión más reciente de servidor FTP
favorito y siga las instrucciones que le acompañan
Identificación: 16 bits
Una valor de identificación asignado por el emisor para poder ensamblar los diferentes fragmentos de un datagrama.
Flags: 3 bits
1. Bits de control:
Bit 0: reservado. Tiene que ser cero.
Bit 1: (DF) 1 = Don’t Fragment, 0 = May Fragment.
Bit 2: (MF) 1 = More Fragments, 0 = Last Fragment.
Fragment Offset : 13 bits
Este campo indica a que parte del datagrama pertenece este fragmento. El tamaño
del fragmento se mide en unidades de 6 octetos (64 bits). Para indicar el primer
fragmento de un datagrama este campo tiene que ser cero.
Time To Live: 8 bits
7
2 TCP/IP
2.2 IP: Internet Protocol
Este campo indica el tiempo máximo que se le permite a un datagrama mantenerse
en Internet. Si este valor contiene un valor de cero, entonces el datagrama tiene que
ser destrozado. Este campo es modificado al procesar las cabeceras. Su tiempo
está medido en unidades de segundo, pero cada módulo tiene que decrecer el valor
de TTL como mínimo por uno incluso si se ha tardado menos de un segundo en
procesar el datagrama. La intención es que los datagramas que no puedan ser
entregados sean descartados.
Protocolo: 8 bits
Este campo indica el siguiente nivel del protocolo usado por el datagrama. Los
valores ya se han comentado anteriormente. Y son 1 si es para ICMP, si es 2 es
para IGMP, 6 indica TCP y 17 es UDP.
Header Checksum: 16 bits
Un checksum de solo la cabecera. Como hay campos en la cabecera que cambian
(Ej. Time to live), este valor se recalcula y verifica cada vez que es procesada la
cabecera.#howto
El resultado del algoritmo de checksum es el complemento de 16 bits a uno
con la suma de todas las palabras de 16 bits de la cabecera. Exceptuando el valor
de checksum que tiene el valor de cero.
Dirección origen: 32 bits
Es la dirección IP origen de 32 bits.
Dirección destino: 32 bits
Es la IP del dispositivo destino, también de 32 bits.
Opciones: variable
Las opciones pueden o no aparecer en los datagramas. Deben ser implementados por todos los módulos IP. Lo que es opcional es su transmisión en cualquier
datagrama, pero no su implementación.
8
2 TCP/IP
2.3 UDP: User Datagram Protocol
2.3. UDP: User Datagram Protocol
2.3.1. Introducción
UDP es simple, orientado a datagrama, y está encuadrado en la capa de trasporte. Cada operación de envío por un proceso produce exactamente un datagrama
UDP, lo que causa que sólo un datagrama IP sea enviado. Es diferente a un protocolo orientado a conexiones (stream-oriented protocol) como es el caso de TCP
donde la cantidad de datos enviados por una aplicación puede tener pequeñas diferencias a lo que en realidad es enviado en un datagrama IP.
En la siguiente figura se enseña la Encapsulación de un datagrama UDP en el
datagrama IP.
La especificación oficial de UDP es la RFC 768, publicada en Agosto del
1980, por J.Postel y se puede encontrar en (http://www.ietf.org/rfc/rfc0768.txt).
UDP no provee una conexión fiable (no reliability): envía el datagrama que la
aplicación escribe a la capa IP, pero no garantiza que llegue a su destino, es un
protocolo que no está orientado a conexión. La falta de confianza hace pensar que
deberíamos dejar de usar UDP y usar siempre el protocolo fiable como TCP. Pero
lejos de eso UDP se usa para muchos protocolos, como pueden ser DNS, TFTP,
BOOTP, SNMP y NFS entre otros.
2.3.2. Cabecera UDP
Como se ha comentado anteriormente la cabecera y su especificaciones pueden encontrarse en el RFC 768.
0
32
15 16
Dirección origen
Dirección destino
ceros
protocolo
UDP length
Datos
Número de puerto origen: 16 bits
9
2 TCP/IP
2.4 TCP: Transmisión Control Protocol
Identifica el proceso que envía el datagrama. Tanto este campo como el siguiente
nos sirven para poner reglas de filtrado en el firewall.
Número de puerto destino: 16 bits
Identifica de la misma manera el proceso que debe recibir el datagrama. Este campo se usa para multiplexar los datagramas que llegan a la máquina y pasarlos a la
aplicación que se necesita. La pila de IP ya se encarga de dividir los paquetes entre los TCP y los UDP, así que es el propio UDP quien mira el puerto destino y
también implica que los puertos TCP y UDP son independientes entre ellos.
Tamaño UDP: 16 bits
Es el tamaño de la cabecera UDP y de los datos, la cantidad es en Bytes. El valor
mínimo es 8 bytes (Como resultado de enviar los 8 bytes de la cabecera sin datos).
Aunque este valor es redundante ya que este valor es el campo de tamaño que se
encuentra en la cabecera IP menos el tamaño de la cabecera IP.
Checksum: 16 bits
Este checksum cubre tanto la cabecera UDP como sus datos. A diferencia del
checksum de IP que solo cubre la cabecera de IP y no cubre los datos que contiene
el datagrama. Tanto UDP como TCP cubren con sus checksum sus cabeceras y los
datos. Para poder hacer el checksum puede añadirse un relleno para que cuadren
las palabras de 16 bits.
2.4. TCP: Transmisión Control Protocol
2.4.1. Introducción
La especificación original para TCP es la RFC 793, publicada por Postel en
Septiembre de 1981 para DARPA (Defense Advanced Research Projects Agency).
Aún estando TCP y UDP en la misma capa de transporte y usar la misma capa
de red (IP), TCP provee un servicio completamente diferente al de UDP. TCP
es un servicio orientado a conexión, fiable y un servicio de flujo de bytes (byte
stream service).
10
2 TCP/IP
2.4 TCP: Transmisión Control Protocol
Por el término orientado a conexión se entiende que dos aplicaciones usando
TCP tienen que establecer una conexión entre ellos antes de poder intercambiar
datos. Una analogía parecida es una llamada de teléfono: se marca, se espera que
la otra parte responda a la llamada, decir un ’hola’ y quien es, tras ello comienza
la conversación.
Al decir que es fiable (reliability) se indica lo siguiente:
1. Los datos de la aplicación se separan en lo que TCP considera que es el mejor tamaño. Completamente diferente a UDP, donde cada vez que escribía
la aplicación generaba un datagrama UDP de ese mismo tamaño. La unidad
de información pasada por TCP a IP se llama segmento.
2. Cuando TCP envía un segmento mantiene un temporizador, esperando para
que la otra parte envíe un segmento con su acuse de recibo (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 conexión este envía un acuse de recibo. Que no aunque no se envía inmediatamente pues sigue una
estrategia.
4. TCP se encarga del checksum de su cabecera y de los datos. En el caso de
recibir un segmento con su checksum erróneo TCP lo descarta y no envía
ningún acuse de recibo.
5. Al encapsular TCP dentro de IP, y como los datagramas IP pueden llegar
en desorden, los segmentos pueden llegar también en desorden. Se encarga
también TCP de reordenarlos en caso de ser necesario, pasando los datos
recibidos en el orden correcto a la aplicación.
6. Como un datagrama IP puede llegar duplicado, los segmentos TCP duplicados deben ser descartados.
7. TCP también mantiene un control del flujo de datos. Cada parte en la conexión TCP tiene el espacio del buffer de entrada finito. Lo que significa que
TCP solo permite que la otra parte envíe los datos que tiene reservados. Esto
11
2 TCP/IP
2.4 TCP: Transmisión Control Protocol
previene de que un ordenador rápido llene todos los buffers de un ordenador
lento.
Cuando hablamos de un servicio de flujo de bytes (byte stream service) nos referimos a que TCP envía un flujo de bytes a través de la conexión, no hay marcas
que identifiquen cuando el emisor envió los datos. Significa que si una aplicación
envía 20 bytes, luego envía otros 35 bytes seguido por otros 25 bytes, la aplicación de la otra parte no podrá identificar los tamaños de las diferentes escrituras,
solo recibe 80 bytes en cuatro lecturas de 20 bytes, por ejemplo. Una parte pone
un flujo de bytes a la pila TCP y este mismo flujo lo recibe la otra parte de la
conexión.
Además, TCP no interpreta el contenido de los bytes que envía. TCP no tiene
ni idea si los datos corresponden a datos en binario, a caracteres ASCII, caracteres
EBCDIC o lo que sea. La interpretación de los bytes retransmitidos es función de
la aplicación que se encuentra en una capa superior a la de transporte de TCP.
2.4.2. Cabecera TCP
Los segmentos TCP se envían mediante datagramas IP. La cabecera TCP sigue
a la cabecera IP, añadiendo información específica para el protocolo TCP.
0
32
15 16
Puerto Origen
Puerto Destino
Número Secuencia
Acknowledge Number
Data Off
Reserved | bits
Ventana
Opciones
Padding
Datos
Puerto de origen: 16 bits
Número de puerto de origen.
12
2 TCP/IP
2.4 TCP: Transmisión Control Protocol
Puerto de origen: 16 bits
Puerto destino que indica a qué aplicación va dirigido el segmento.
Número de secuencia: 32 bits
El número de secuencia del primer octeto de datos. En el caso de estar el bit de
SYN presente el número de secuencia es el número inicial de secuencia (initial
sequence number ISN)y el primer octeto de datos es ISN+1.
Número de Acknowledgment: 32 bits
Si el bit de control ACK está activo este campo contiene el valor del siguiente
número de secuencia que se espera recibir. Y una vez se ha establecido la conexión
siempre se envía.
Data Offset: 6 bits
Reservado para uso futuro. Debe ser cero.
Bits de control: 6 bits (de izquierda a derecha)
1. URG: Urgent Pointer field significant.
2. ACK: Acknowledgment field significant.
3. PSH: Push Function.
4. RST: Reset the connection.
5. SYN: Synchronize sequence numbers.
6. FIN: No más datos por parte del emisor.
Ventana (window): 16 bits
El número de octetos de datos empezando por el número indicado en el campo de
acknowledgment que el emisor del segmento esta esperando recibir.
13
2 TCP/IP
2.4 TCP: Transmisión Control Protocol
Checksum: 16 bits
El checksum se le aplica al cuerpo del mensaje y a parte de la cabecera, que
incluye la dirección origen, la de destino, el protocolo y el tamaño del TCP.
Puntero urgente: 16 bits
Este campo indica el valor del puntero urgente como un offset positivo desde el
número de secuencia en este segmento. Y apunta al número de secuencia del octeto seguido por los datos urgentes. Este campo solo es interpretado en segmentos
con el bit de control URG activa.
14
3 INTRODUCCIÓN A LOS FIREWALLS
3. Introducción a los firewalls
3.1. ¿Qué es un Firewall?
En construcción, un firewall se diseña para mantener el fuego separado de una
parte de un edificio a otra. En teoría, un firewall de Internet sirve con el mismo
propósito: previene de peligros de Internet a la red interna.
Todo el tráfico que proviene de Internet o que sale de tu red interna pasa a
través del firewall. Por esa razón, el firewall tiene la oportunidad de asegurarse
que ese tráfico es aceptable.
¿Qúe significa ’aceptable’ para el firewall? Significa todo aquel tráfico que
se hace y que cumple con las normas de seguridad del lugar. Las políticas son
diferentes para cada uno, algunas son muy restrictivas y otras son más abiertas.
Lógicamente hablando, un firewall, separa, restringe y analiza. Físicamente
hablando se puede implementar de varias maneras, la mayoría de veces es un
grupo de componentes hardware - un router, un ordenador, o una combinación
de routers, ordenadores y redes con un software apropiado. Hay varias formas de
configurar los equipos; la configuración dependerá de las políticas de seguridad,
del dinero disponible y de las operaciones a realizar.
Los firewalls tienen limitaciones y puntos débiles, entonces por qué instalar
un firewall si no es invulnerable? Porque el firewall es la manera más efectiva de
conectar una red a Internet y proteger la propia red. Internet presenta maravillosas oportunidades. Millones de personas están intercambiando información. Los
beneficios son obvios: posiblidades de publicidad, servicio a cliente mejorado e
información en general. Los riesgos también deberían ser obvios también: cualquiera de los millones de personas puede tener intenciones maliciosas contra tu
red.
¿Cómo beneficiarse de las partes buenas de Internet sin saltarse lo malo? 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 mayoría de
situaciones es la herramienta más efectiva para hacerlo.
15
3 INTRODUCCIÓN A LOS FIREWALLS
3.2 Qué puede hacer
3.2. Qué puede hacer
Los Firewalls pueden hacer mucho para tu seguridad. Estas son algunas de las
ventajas:
3.2.1. Donde localizar las decisiones
Todo el tráfico de entrada y salida tiene q pasar a través de este sitio. Un
firewall concentra las medidas de seguridad en este lugar de chequeo: allá donde
tu red se conecta a Internet.
3.2.2. Refuerza políticas
Muchos de los servicios que la gente quiere de Internet son inherentemente
inseguros. Un firewall es el policia del tráfico para estos servicios. Permite solo servicios ’aprovados’ para pasar a través de él y solo aquellos que se hayan
configurardo.
Un firewall puede reforzar las políticas de seguridad añadiendo políticas más
complejas. Por ejemplo bloqueando una transferencia de ficheros desde una parte
de nuestra red; controlando qué usuarios tienen acceso a que sistemas. Y dependiendo de la tecnologia del firewall, este puede ser mas o menos complejo para
añadir estas políticas.
3.2.3. Registrar la actividad
Como todo el tráfico pasa a través del firewall, el firewall provee un buen lugar
para recoger una colección de información sobre los usos de los sistemas y redes.
Puede recopilar qué ocurre entre la zona protegida y la red externa.
3.2.4. Limita la exposición
Este es uno de los usos más relevantes de los firewalls. A veces un firewall
se usa para mantener una sección de tu red separada de otra sección. Haciendo
esto, se mantienen los problemas que puedan impactar en una sección separada
del resto. En estos casos, una parte de la red puede ser más segura que otra, en
otros casos una sección puede ser más sensible que otra. Cualquiera que sea lar
16
3 INTRODUCCIÓN A LOS FIREWALLS
3.3 Qué no puede hacer
razón de la existencia de un firewall este limita el daño que puede hacer una red a
otra.
3.3. Qué no puede hacer
Los firewalls ofrecen una excelente protección, pero no son la solución única y completa para nuestra seguridad. Ciertos procesos estan fuera del control de
nuestro firewall. Y se necesita otras métodos para protegerse de estos sucesos incorporando otras herramientas. Es necesario conocer cuales son los puntos débiles
de los firewalls.
3.3.1. Dentro de la red
Un firewall puede prohibir a un usuario de enviar información confidencial
fuera de la red a través de la conexión a Internet. Pero el mismo usuario puede
copiar los datos en un disco, imprimirlos y llevarselos fuera del edificio en un
maletín.
Si el atacante esta dentro de la red el firewall no puede hacer nada por ti.
Dentro los usuarios pueden robar datos, dañar hardware y software, modificar
programas sin siquiera pasar a través del firewall. Es necesario protegerse con
medidas internas de seguridad.
3.3.2. Conexiones que no van a través de él
Un firewall puede controlar el tráfico que pasa a través de él pero no puede
hacer nada con el tráfico que no pasa a través de él. Por ejemplo, si hay otra
conexión dial-in para conectarse a los sistemas detrás del firewall, este no tiene
ninguna forma de proteger a los intrusos que usen ese modem.
3.3.3. Virus
Los firewalls no pueden mantener a los viruses alejados de la red interna. Muchos firewalls escanean todo el tráfico entrante para determinar si este esta permitido, pero el escaneo de los datos son la mayoría de veces de solo las direcciones
y puertos origen y destino, no para los detalles de los datos. Incluso los firewalls
17
3 INTRODUCCIÓN A LOS FIREWALLS
3.4 Tipos de Firewalls
más sofisticados no son muy prácticos contra los viruses. Simplemente hay muchas maneras para esconder un virus entre otros datos. Determinar que existe un
virus dado un paquete que pasa a través del firewall es muy difícil. La forma más
práctica de defenderse de los virus es mantener un software de protección basado
en los ordenadores, y educando de los posibles peligros a los usuarios y de como
protegerse de ellos.
3.4. Tipos de Firewalls
Existen principalmente dos formas de implementar los firewalls hoy día. Y
esta división se centra en la forma de tratar los datos que pasan a través del firewall,
una de las dos formas es menos exhaustiva, pero por eso es la solución más barata.
El trabajo final de carrera no trata de firewalls proxy, pero estos 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 políticas de seguridad. El tipo de
router usado en un filtrado de paquetes se conoce como screening router.
Como se discute en el capítulo dedicado a TCP/IP cada paquete tiene unas
18
3 INTRODUCCIÓN A LOS FIREWALLS
3.4 Tipos de Firewalls
cabeceras con cierta información. En esta información se encuentra:
1. dirección origen IP
2. dirección destino IP
3. protocolo (TCP, UDP o ICMP)
4. puerto origen TCP o UDP
5. puerto destino TCP o UDP
6. tipo de mensaje ICMP
Además el router dispone de más información del paquete que no se reflejan en el
paquete pero son igual de importante, sino más.
1. La interfaz por donde llega el paquete
2. La interfaz destino del paquete
El hecho que cada uno de los servidores tenga cierto tipo de servicios nos indicará
las reglas que debamos escoger en el firewall basándonos en la IP del servidor y
del puerto, porque el puerto indica el tipo de conexciones (ej. puerto 22 TCP son
conexion SecureSHell).
Hay varias formas en las que podemos basar nuestras políticas, unas seria 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 también se encarga de proteger el sistema. Si falla o se cae tras
un ataque, la red interna está expuesta.
Es más no puede proteger de operaciones a un servicio: si un servicio tiene
operaciones inseguras. o si el servicio se provee con un servidor inseguro el filtraje
de paquetes no puede protegerlo, ya que los paquetes pasarán indistintamente del
contenido de los paquetes, ya sea maligno o no.
19
3 INTRODUCCIÓN A LOS FIREWALLS
3.4 Tipos de Firewalls
Pero como mayor ventaja es que es un tipo de protección más barata, ya que
puede tratar a más conexiones que un proxy con el mismo equipo hardware y
además el programa no es complejo de realizar, comparado con el proxy, ya que
como se ve a lo largo del trabajo final de carrera, no es un programa sencillo de
implementar.
3.4.2. Servicios proxy
Los servicios proxy son programas especializados que corren en un firewall:
ya sea un host dual-homed con una interfaz en la red interna y otra en la red
externa, o bien un host bastion que tiene acceso a Internet a través de otra maquina
interna. Estos programas redireccionan los requests de los servicios que piden los
usuarios (como sesiones FTP o sesiones SSH), las direccionan según las politicas
de seguridad. Los proxies reemplazan las conexiones externas y actúan de gateway
a esos servicios. Por esa razón se les conoce también como gateways del nivel de
aplicación.
Los sistemas proxy, permanecen más o menos de manera transparente entre el
usuario dentro de la red y el servicio fuera de la red. En vez de hablar directamente
uno con el otro cada uno de ellos habla con el proxy. Estos tratan las conexcion
entre usuarios y los servicios de una manera transparente.
20
3 INTRODUCCIÓN A LOS FIREWALLS
3.5 Arquitecturas Firewall
La transparencia es el mayor beneficio de los servicios proxy. Para el usuario,
un proxy presenta la ilusión que esta tratando directamente con el servidor real.
Para el servidor real, el proxy presenta la ilusión de que está tratando directamente
con un usuario en el ordenador del proxy, en vez de ser el auténtico usuario en otro
ordenador.
Los servicios proxy son efectivos solo cuando se usan en conjunción con algún mecanismo que restringe las comunicaciones directas entre los ordenadores
externos e internos. Si los hosts internos pueden comunicarse directamente con los
hosts externos no hay razón alguna para tener un proxy. Un proxy es una solución
software, deben usarse conjuntamente con un firewall.
Los servidores proxy no solo redirecciona el tráfico de los usuarios a los servicios externos de Internet. Los servidores proxy controlan lo que estos hacen,
porque escucha todo lo que hacen los usuarios y según las políticas de seguridad
dejará pasar el contenido. Por ejemplo un proxy web puede bloquear todas las
páginas web que contengan VBScript pues estos ejecutan programas que pueden
llegar a ser muy peligrosos. Y todo de una manera transparente al usuario.
3.4.3. Combinación de técnicas
La ’buena solución’ es aquella que no se basa en una única técnica, sino aquela
que usa cuidadosamente la combinación de varias técnicas para resolver diferentes
problemas. Los problemas que debes resolver dependen en qué servicios quieres
proveer a los usuarios y qué nivel de riesto estas dispuesto a aceptar. Y las técnicas
también dependen del dinero, tiempo y experiencia de la que dispones.
Algunas protocolos se pueden tratar mejor con filtrado de paquetes como 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 sección describe una variedad de maneras de las que podemos disponer
los firewalls, las redes de ordenadores o servidores y los routers. Dependiendo de
la funcionalidad que le queramos dar a la red se escoge una u otra arquitectura.
21
3 INTRODUCCIÓN A LOS FIREWALLS
3.5 Arquitecturas Firewall
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. Aún siendo capaz de enrutar
paquetes IP de una a otra red, si se implementa una aquitectura Dual-Homed Host
se restringe esta función de enrutaje. Lo que hace que los paquetes de una red no
se conectan directamente a la otra red. Los sistemas dentro del firewall pueden
comunicarse con el Dual-Homed Host, y los sistemas fuera del firewall (de Internet) puede comunicarse con el Dual-Homed Host, pero estos sistemas no pueden
comunicarse entre ellos. El tráfico IP está completamente bloqueado. Todo tráfico
hacia fuera lo debe originar el firewall.
Esta arquitectura puede proveer un gran nivel de control. Ya que todos los paquetes se originan en el firewall. Se puede asegurar además que cualquier paquete
dentro de la red interna que tenga la dirección origen con una IP externa es origen
de algún tipo de problema de seguridad.
La única manera que tienen la red interna de conectarse con el exterior es
através de servicios proxy localizados en el firewall, y através de este servir de
conexión. Pero presenta un inconveniente, y es que no todos los servicios pueden
22
3 INTRODUCCIÓN A LOS FIREWALLS
3.5 Arquitecturas Firewall
pasarse por Proxy y lo que indica que los usuarios deberían tener cuentas de usuario en el firewall y conectarse al exterior desde él mismo. Lo que es incómodo
para los usuarios y un posible agujero provinente de usuarios internos.
3.5.2. Screened Host
En esta aquitectura se usa un router para conectar las redes internas y externas
(Internet), pero se configura el router con filtrado de paquetes para que no se
puedan conectar directamente las redes internas y externas, a no ser que sea a
través del bastion host que hace la función de proxy.
El host bastion se sitúa en la red interna. El filtraje de paquetes se hace en el
Screened Host (router) que se configura para que el bastion host sea el único capaz
de recibir conexiones externas. Cualquier sistema externo que intente acceder al
sistema interno o a los servicios internos deberá hacerlo a través del bastion host.
Por ello este host debe mantener un gran nivel de seguridad.
Además el Screened Host usando el filtraje de paquetes indicará que conexiones se permiten desde la red interna al mundo externo, siguiendo las políticas de
seguridad. Algunos de los servicios externos pueden hacerse bien directamente a
traves del Screened Host o bien a través del bastion host mediante el proxy.
Como esta arquitectura permite pasar paquetes de fuera a dentro de la red,
puede parecer más inseguro que una arquitectura dual-homed host, que está di23
3 INTRODUCCIÓN A LOS FIREWALLS
3.5 Arquitecturas Firewall
señada para que ningún paquete externo entre a la red interna. Pero en la arquitectura Screened Host es más fácil defender el router, que provee servicios muy
limitados, comparado con el dual-homed host. Para la mayoría de propósitos, el
Screened Host provee mejor seguridad y mejor usabilidad que la Dual-Homed
host. Pero comparada con la arquitectura siguiente, hay desventajas. La mayor es
que si un atacante llega a controlar el bastion host, entonces toda la red interna esta expuesta. El router también representa un único punto de fallo. Por eso mismo
la siguiente arquitectura es más popular.
3.5.3. Screened Subnet
La arquitectura Screened Subnet añade una capa de seguridad extra a la anterior arquitectura, añadiendo una red de perímetro o también perimeter network en
inglés, que aisla la red interna de Internet. La topologia es situar un router 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
máquinas más vulnerables de la red. A pesar de todos los esfuerzos por mantenerlas protegidas, son las máquinas que se atacan principalmente, porque son ellas
las que pueden atacarse. Si, en una arquitectura screened host, esta abierta a un
ataque desde el host bastion, entonces el host bastion es un target muy jugoso,
porque no hay defensas entre este y las otras máquinas. Si alguien rompiese la
seguridad del bastion host en una arquitectura Screened Host entonces es como si
le tocase el gordo, esta dentro de la misma red interna con todos los ordenadores
indefensos. En cambio en una arquitectura Screende Subnet si penetra en el host
bastion no puede dañar al resto de ordenadores, por estar aislado, sigue siendo
peligroso porque puede instalar un snifer, pero no acceder directamente a la red
interna.
24
3 INTRODUCCIÓN A LOS FIREWALLS
3.5 Arquitecturas Firewall
La manera más simple de crear una arquitectura Screende Subnet es conectando dos routers a la red de perímetro (perimeter net). Una entre la perimeter net
y la red interna, y otro entre la perimeter net y la conexión externa (normalmente
Internet). Para romper dentro de la red interna con este tipo de arquitectura el atacante debería pasar através de los dos routers. Incluso si el atacante consiguiese
romper el bastion host aun le quedaría pasar el router interno.
A veces para ir más allá, se crean una serie de redes perimetrales entre el
mundo externo y la red interior. Dependiendo de lo seguras y confiables que son
los servicios que se ponen en cada perímetro. Los servicios más vulnerables se
ponen en las redes externas y la red interna se pone al principio. Es un fallo de
seguridad lo que voy a decir pero es tal mi confianza en esta topologia que no
me importa decir que es así como tengo configurado los sistemas que están a mi
cargo.
Red perimetral
La red perimetral es como he comentado antes, otra capa de seguridad, una red
adicional entre las redes externas y la red interna que se trata de proteger. Si un
atacante consigue romper dentro de una red perimetral puede conseguir atacar los
servicios que se trate dentro de la red. Dentro de la red perimetral pueden ponerse
25
3 INTRODUCCIÓN A LOS FIREWALLS
3.5 Arquitecturas Firewall
los servidores FTP y WWW, en caso de ser atacado y tener éxito el ataque pueden
tener el acceso al ordendor y tras ello se puede acceder a la red perimetral pero no
pasar a la red interna.
Router interno
El router interno (a veces llamado choke router en literatura inglesa) protege
la red interna de Internet y de la red perimetral.
Este router hace la mayoría del filtraje de paquetes. Permite que algunos 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. También
debe limitarse las conexiones permitidas para la red interna.
3.5.4. Variaciones posibles
Se ha visto las principales configuraciones posibles, pero dependiendo del dinero disponible, las políticas 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 configuración. Las razones pueden ser varias, para mejorar la redundancia, para mejorar
la performance del sistema o simplemente para simplificar la administración de
cada bastion host. También puede dividirse según la confianza que se tenga por
los servicios a tratar, así se puede tener especial cuidado en aquello que puedan
representar una amenza, así un servicio no puede comprometer otros.
26
3 INTRODUCCIÓN A LOS FIREWALLS
3.5 Arquitecturas Firewall
Juntar el router externo con el interno
Se pueden juntar el router interno con el externo en un único router, pero solo
si se tiene un router suficiente capaz y flexible para hacerlo, hoy dia la mayoría de
routers lo permiten. Tenemos la red perimetral conectada a una interficie del router
y la red interna conectada a la otra interficie. Dentro de la perimeter Network
podemos tener un bastion host haciendo las funciones de proxy, para tal caso
hay que configurar en el router el filtrado de paquetes convenientemente. Esta
arquitectura, igual que la screened host, hace del único router un punto vulnerable
para comprometer a toda la red. En general los routers son fáciles de proteger, más
que los servidores, pero igualmente no son impenetrables.
27
4 FILTRADO DE PAQUETES
4. Filtrado de paquetes
4.1. Introducción
Como he comentado en la sección de introducción a los firewalls, el filtrado
de paquetes es uno de los dos tipos de firewalls que existe, el otro sistema es el
firewall proxy. Cada uno sube hasta un nivel concreto de la capa OSI. Mientras el
primero solo trata hasta el nivel 3 de la capa OSI, donde se encuentran los paquetes
y basa sus decisiones en la información que hay en la cabecera del paquete IP. La
otra, los sistemas proxy, sube hasta en nivel de aplicación, pues debe basar sus
decisiones en la información que hay en los datos del nivel más alto. El trabajo
solo aborda el primer sistema, y es por eso que se profundiza más en este sistema:
el filtrado de paquetes.
El filtrado de paquetes es un mecanismo de seguridad que trabaja controlando
los datos que vienen y van por la red. Es necesario tener claro los fundamentos que
se han explicado en la sección TCP/IP para enteder correctamente este apartado.
Al transferir información a través de la red, la información esta troceada en
pequeñas piezas, cada una de ellas se envía separadamente. Rompiendo la información en partes permite a los sitemas compartir la red, enviando piezas por
turnos. En las redes IP, que son las que trato en el trabajo, estas piezas de datos
se llaman paquetes. Todos los datos que se transfieren a través de las redes IP se
hace en forma de paquetes.
Los equipos básicos que interconecta redes IP se llaman routers. Un router
puede ser una pieza dedicada de hardware si otro propósito, o puede ser también
un software que corre en un sistema de propósito general como un PC. Los 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 dónde enviarlo basándose en el destino final del paquete. En general, un
paquete no lleva ninguna otra información que la IP de destino para ayudar al
router a tomar su decisión. El paquete dice al router donde quiere ir, pero no por
donde lo debe enviar. Los routers se comunican entre ellos usando los ’protocolos
de routing’ o ’protocolos de enrutaje’ según el idioma, como por ejemplo Routing
28
4 FILTRADO DE PAQUETES
4.2 Características
Information Protocol (RIP) como uno de los más simples, o bien Open Shortest
Path First (OSPF) para construir las tablas de enrutaje o tablas de routing, con
las que determinan como enviar los paquetes a sus destinos. Cuando se enruta un
paquete, el router compara la dirección de destino con las entradas que dispone
en la tabla de routing y envía el paquete a través de la interfaz que se indica en
la misma tabla. Muchas veces no hay una ruta específica para un destino en particular, entonces el router usa la ruta por defecto o también ’default gateway’ que
es como yo lo conozco, y se envía a routers que están mejor conectados o a los
routers que se supone pueden saber el destino.
Al determinar como enviar un paquete a su destino, un router mira solo la
dirección destino del paquete y se pregunta ’¿a donde debo enviar este paquete?’.
pero además se considera la pregunta ’¿debo enviar este paquete?’ ya que o bien
por la política de seguridad programa en el router es mejor descartar el paquete
o bien porque a lo mejor el destino no es accesible y es mejor borrar el paquete
para que deje de dar vueltas. Para la primera opción se usa lo que se llama filtrado
de paquetes, para la segunda opción se trata el campo TTL (Time To Live). Nos
concentraremos en el filtrado de paquetes, que es el objetivo de este trabajo final
de carrera.
4.2. Características
La principal ventaja del filtrado de paquetes es poder proveer, en un único sitio,
protecciones para toda un red. Considerando el servicio Telnet como ejemplo. Si
se prohibe el Telnet cerrando en servicio de telnet en todos los ordenadores, aún
hay que tener cuidado y preocuparse por si alguien de la organización instala en
una nueva máquina un servidor de Telnet. Por otra parte, si es telnet se desactiva
desde el router, filtrando todos los paquetes que vayan a servir a tal propósito, se
protege a la red desde el principio, si importar si hay alguien utilizando un servidor
Telnet o no. Otra ventaja es que los routers suelen ser pocos, muchos menos que
servidores, por eso se supone que se puede aplicar un mayor control concentrando
la seguridad en ellos.
Ciertas protecciones solo pueden proveerse con routers de filtrado de paquetes, y solo cuando se situan en ciertas localizaciones de la red. Por ejemplo, es una
29
4 FILTRADO DE PAQUETES
4.3 Ventajas
buena idea parar todos los paquetes que tengan como dirección de origen una IP
que pertenece a una máquina interna, porque lo más seguro que se esté intentando
un ataque spoofing. En estos ataques, un atacante pretende suplantar a otra máquina ’amiga’ o conocida ocultando su identidad. La solución es bloquear todos
los paquetes entrantes con una IP origen que pertenezca a la red interna. Este tipo
de soluciones solo pueden hacerse con un router o firewall que tenga la opcción
de filtrado de paquetes y que esté situado en el perímetro de la red. Y únicamente
un router en esa loclización (por perímetro se entiende que conecta las dos redes a
través de él) es capaz de reconocer un paquete así, mirando las direcciones origen
de todos los paquetes que entren desde fuera de la red.
4.3. Ventajas
Ya he comentado algunas en el punto anterior, pero aquí se listan todas ellas:
4.3.1. Proteger toda la red
Como he comentado una de las claves dentro de las ventajas de un router
con filtrado de paquetes es que un router único y estratégicamente situado puede
ayudar a proteger toda un red. Si sólo hay un router que conecta tu red con Internet,
30
4 FILTRADO DE PAQUETES
4.3 Ventajas
se gana facilidad a la hora de proteger la red, sea cual sea el tamaño de la red
interna, si se hace correctamente en ese router externo que da conexión a Internet.
4.3.2. Transparencia
Como diferencia al proxy, los sistemas con filtrado de paquetes no requieren
ningún tipo de software ni configuración en las máquinas de los clientes, no requiere ningún tipo de enseñanza ni explicación a los usuarios. Cuando un router
con filtrado de paquetes decide lanzar un paquete, este no se distinge de otro router
normal sin esa aplicación. Los usuarios no sabrán que existe, a no ser que intenten hacer algo que esté prohibido (supuestamente por un problema de seguridad)
según la política de seguridad que se le aplique al router con filtrado de paquetes.
Esta transparencia significa que un router filtrando paquetes puede hacerse
sin la cooperación y sin el conocimiento de los usuarios a los que se les da el
servicio de conexión. La clave no es hacer cosas a urtadillas de los usuarios, a sus
espaldas. Sino que la clave está en que puedes hacer filtrado de paquetes sin tener
que enseñarles nada para que trabajen, y sin depender la seguridad en ellos para
que algo funcione correctamente. Recuerdo que para protegerse de los virus es
recomendable educarles, y es tedioso y aún así no siempre funciona.
4.3.3. Disponibilidad
El filtrado de paquetes está disponible en la mayoría de hardware y software de
los productos que hacen routing, ambos tanto comerciales como los distribuidos
gratuitamente. La mayoría de routers también tienen capacidades de filtrado de
paquetes.
Es una ventaja pues tras diseñar una política de seguridad es muy probable
que dispongamos de la capacidad de filtrado de paquetes por parte del router.
4.3.4. Latencia
Si comparamos el filtrado de paquetes con los sitemas proxy tenemos que con
la misma potencia en hardware se consigue menos latencia. Esto es debido a que
el filtrado de paquetes solo tiene que llegar al nivel IP. Además las decisiones se
31
4 FILTRADO DE PAQUETES
4.4 Desventajas
toman según una pequeña parte de los datos que transitan, la cabecera IP, y no es
necesario investigar todos los datos de contenido de los datos que transitan.
4.4. Desventajas
Dentro de las características de los sistemas de filtrado de paquetes encontramos también desventajas, y entre todas ellas tenemos que:
4.4.1. Protocolos difíciles
Aunque la implementación de las políticas de seguridad sean perfectas, 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 conexión, los protocolos
basados en RPC como por ejemplo NFS y NIS/YP tampoco son fáciles de tratar.
Ciertos protocolos, como por ejemplo FTP, H323 entre otros mantienen en sus
conexiones unas sesiones características debido a que el cliente y servidor hacen
los dos funciones de cliente y de servidor. Por ejemplo el File Transfer Protocol
es uno de ellos, el cliente FTP se conecta al servidor FTP mediante TCP al puerto
21 por defecto, entonces cuando hay cualquier petición el servidor envía los datos
mediante UDP saliendo del puerto 20. Estos datos lo más normal es que se hayan
bloqueado en el firewall para proteger la red interna, porque no se puede dejar
abierto ya que cualquier atacante lo usaría. La solución pasa por tener unas tablas
indicando las sesiones que están en funcionamiento, y cuando se detecte un 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 conexión FTP que ha inciado
alguien dentro de la red que se está protegiendo.
32
4 FILTRADO DE PAQUETES
4.5 Configuración
4.4.2. Polítcas que no pueden aplicarse
La información que un paquete da al router que filtra los paquetes no es suficiente para según que política de seguridad. Por ejemplo, los paquetes indican
de que ordenador provienen pero no de que usuario. Por eso, no se pueden hacer restricciones en usuarios específicos, sino que a las máquinas que estos usan
normalmente. De igual forma, los paquetes dicen a que puerto van pero no a qué
aplicación, cuando se hacen restricciones por portocolo se hacen por el número
de puerto, esperando que nadie este ejecutando el mismo servicio en un puerto
que no se le asigna por defecto. La gente de dentro de la organización que tengan
control sobre sus máquinas pueden hacer cambios en este sentido de un manera
fácil.
4.4.3. Spoofing
Ya he nombrado antes los ataques spoofing, los números IP del origen pueden
modificarse y para asegurarse de que el emisor es quien dices ser tiene que usarse
otras técnicas, en el mismo nivel de la torre OSI como por ejemplo IPSec o bien en
niveles superiores de la torre OSI, por encima del nivel de transporte, como puede
ser Secure SHell conocido como SSH, que intercambia claves de los servidores y
no se basa únicamente en las IP’s de las dos partes para crear una sesión.
4.5. Configuración
Para configurar un router con filtrado de paquetes, lo primero es decidir qué
servicios se va a permitir y qué servicios se van a prohibir, entonces se traduce
las decisiones en reglas para los paquetes. En realidad, probablemente no importa
los detalles de los paquetes. Lo importante para cada uno es hacer el trabajo bien
y que funcione. Por ejemplo, si se quiere recibir correo de Internet, al jefe no le
importa si los paquetes los tratan el fantasma del ordenador eso es irrelevante,
para él solo quiere recibir el correo. Esto puede causar que se hagan unas reglas
poco restrictivas, y así funcione el correo que tanto le interesa al jefe. Pero que
funcione no significa que esté bien hecho. Y es que traducir “quiero recibir correo
de Internet” en un grupo de reglas bien hechas requiere entender como funciona
33
4 FILTRADO DE PAQUETES
4.5 Configuración
y seguir un conjunto de reglas. A continuación paso a explicar concepto que son
necesarios tener en mente a la hora de traducir decisiones sobre los servicios en
reglas para paquetes.
4.5.1. Bidireccionalidad
Los protocolos en su mayoría son bidireccionales; casi siempre son las dos
partes las que envían datos, una enviando un comando o una petición, y la otra
parte enviando la respuesta del comando o retornando otros datos. Cuando se planea crear las reglas para el filtrado de paquetes es necesario recordad que los paquetes tienen doble sentido. Por ejemplo, no tienen ningún sentido dejar enviar los
comandos en el Telnet y permitir que los paquetes salgan, pero en cambio prohibir
que los resultados de los comandos no puedan verse prohibiendo el retorno de los
paquetes.
Por otra parte, no ayuda si se bloquea solo la mitad de la conexión. ya que
muchos ataques pueden conseguirse si el atacante puede enviar paquetes a la red,
incluso si el atacante no obtiene ninguna respuesta. Es posible porque las respuestas pueden ser predecidas, y permite a los atacantes mantener una conversación
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 tráfico entrante, inbound, y outbound significa tráfico 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 mayoría de la gente piense habitualmente en términos de ser34
4 FILTRADO DE PAQUETES
4.6 Que hacer
vicios, hay que pensar claramente en términos de paquetes cuando se trata con el
filtrado de paquetes. Cuando se habla de filtrado de paquetes, lo más importante
es la dirección de los paquetes y no de los servicios.
4.5.3. Permitir por defecto versus denegar por defecto
Este punto es epecialmente importante a la hora de configurar las reglas de
filtrado de paquetes. Se distinguen entre dos tipos de reglas, se puede escoger o
bien poner las políticas de seguridad con una regla de negado por defecto (todo
aquello que no se expresa específicamente que está permitido se niega) o bien la
regla de permitir por defecto (todo aquello que no se especifica específicamente
como prohibido se permite). Desde el punto de vista de seguridad, es mucho más
seguro tomar la actitud de que las cosas están negadas por defecto. Y las reglas
de configuración deben reflejarlos. Es necesario empezar por la posición de negar
todo y después poner las reglas que permitan solo los protocolos que se permiten,
entender las implicaciones que tiene en la seguridad es sumamente importante.
La posición de negarlo todo por defecto es mucho más segura y mucho más
efectiva que permitirlo todo por defecto, lo que indica que permitiendo todo por
defecto e intentando bloquear aquellas cosas que sabes que dan problemas. La
realidad es que con esa aproximación, nunca se sabe todos los posibles problemas,
porque siempre aparece nuevos problemas y por lo tanto nunca se completa el
trabajo.
Hablando de manera práctica, la negación de todo significa que las reglas de
filtrado deben ser una lista pequeña de las cosas que se permiten, seguido de un
negado por defecto que cubra todo el resto de paquetes. Luego pasaré a explicar
como deben ser estas reglas.
4.6. Que hacer
Una vez un PC con filtrado de paquetes haya terminado de examinar un paquete, ¿qué hacer con el paquete? Principalmente hay dos opciones siempre basándose en el las reglas de configuración:
1. Pasará el paquete. Si el paquete pasa el criterio de filtrado, el router pasará
35
4 FILTRADO DE PAQUETES
4.6 Que hacer
el paquete allá donde indique la tabla de routing, que la dirección que debe
seguir, como si fuera un router normal sin el filtrado de paquetes comportándose de manera transparente.
2. Eliminar el paquete. La otra acción obviamente es eliminar el paquete si
falla en los criterios con que se ha configurado el filtrado.
Sea unos u otros el tipo de paquetes, el filtrado de paquetes debe suministrar dos
herramientas básicas para el correcto funcionamiento, la primera es hacer un log
de los paquetes que le hayamos indicado que haga y la otra es devolver paquetes
ICMP indicando el tipo de error en caso de no dejar pasar el paquete.
4.6.1. Logging
Independientemente de si se deja pasar o no el paquete, puede querer el administrador que se guarde la acción que se acaba de tratar. Especialmente cuando
hay paquetes que se han eliminado, porque al ir en contra de las reglas de filtrado
de paquetes se puede tratar de un ataque y es necesario tener constancia de ello.
No se recomienda a su vez hacer un log de todos los paquetes que pasan por
el filtrado de paquetes, pues fácilmente se sobresaturarían los discos además de
relentizar de manera drástica el ordenador. Pero si es necesario para cierto grupo
de paquetes. Por ejemplo, puede ser interesante mantener un log de los paquetes
TCP que indiquen comienzo de conexión hacía un servicio Telnet de un router
específico, así se guarda las conexiones que se hayan realizado para una posible
configuración. Aunque no todos las aplicaciones comerciales y no comerciales de
filtrado de paquetes dejan hacer un log a los paquetes permitidos en mi aplicación
sí se puede.
Dependiendo de la implementación del filtrado de paquetes hay diferentes formas de hacer log. Algunos guardarán solo la información específica sobre el paquete, otros en cambio guardarán 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 aplicación. Porque
es interesante no tener únicamente una copia de la provinencia de un ataque si el
firewall se ha visto comprometido, pues es fácil eliminarlo y parecer que no ha
habido tal ataque.
36
4 FILTRADO DE PAQUETES
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 tráfico de la red y algo de tiempo al usuario que le ha sido
negado el acceso, ya que al recibir un código de error ICMP el host del usuario no
debe reintentar y para inmediatamente, si no recibe ninguno puede tardar varios
minutos esperando una respuesta.
Hay dos grupos relevante de códigos ICMP a escoger:
1. Los códigos de ’destino inalcanzable’ o ’destination unreachable’ en particular el de ’ordenador inalcanzable’ o ’host unreachable’ y el código de
’red inalcanzable’ o ’network unreachable’ según el idioma. Los diseñadores del primer grupo de códigos de error ICMP diseñaron este grupo de ’host
unreachable’ y el de ’network unreachable’, para indicar algún problema 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 máquina 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 códigos de ’destino administrativamene inalcanzable’ o ’destination administratively unreachable’ en particular dentro de este grupo el de ’ordenador administrativamente inalcanzable’ o en inglés ’host administratively
unreachable’ y el código de ’red administrativamente inalcanzable’ o como
se encuentra en la literatura inglesa ’network administratively unreachable’.
Indican que el destino puede ser accedido porque no ha caido pero que no
se deja pasar ningún paquete debido a la configuración del sistema y que
todo paquete a ese destino se ha bloqueado. Este segundo grupo de errores que pueden retornar un administrativamente inalcanzable se añadieron
37
4 FILTRADO DE PAQUETES
4.6 Que hacer
hace unos años al grupo de mensajes ICMP, específicamente para dar a los
sistemas de filtrado de paquetes algo que poder retornar cuando eliminaban
un paquete. Muchos sistemas pueden no reconocer estos códigos, aunque
tampoco deben causar ningún problema, porque los sistemas que reciben
un código que no entienden simplemente deben ignorarlo, que significa que
es como si no se hubiera enviado ningún mensaje. Pero que no haga caso al
mensaje es útil de manera que al recibir este mensaje el sistema no se verá
afectado.
¿Cúal es la correcta? De los dos grupos de mensajes a retornar, si retornamos
uno del primer grupo ’host unreachable’ o bien el de ’network unreachable’ es
técnicamente incorrecto, recordar que los hosts puede o puede que no sean alcanzables, de acuerdo con la política de filtrado de paquetes, dependiendo a qué host
está intentando acceder y a qué servicio. También hay que recordar que este tipo
de códigos pueden causar en muchos sistemas una reacción excesiva, como por
ejemplo cerrando todas las conexciones que ya están abiertas hacia ese host o red
en cuestión.
Si devolvemos un ’host administratively unreachable’ o un ’network administratively unreachable’ se advierte que el paquete que está siendo filtrado al destino
desde ese origen. Estos códigos teóricamente, no deberían de tener una respuesta
excesiva al llegar al ordenardor que intentaba originar la conexión.
Hay otras consideraciones, por ejemplo, generando y retornando códigos de
error ICMP necesita un cierto tiempo y esfuerzo por parte del router o firewall
con el software de filtrado de paquetes. Un atacante podría montarse un ataque de
denegación de servicio o denial of service según se diga, saturando el router con
paquetes que debería rechazar, generando paquetes con códigos de error ICMP.
Lo que se trata de proteger no es el ancho de banda de la red, sino la cantidad de
carga sobre la CPU en el router o firewall en cuestión, y mientras está generando
paquetes ICMP no está tratando paquetes entrantes. Por otra parte si no se retorna
códigos de error ICMP puede causar un exceso de tráfico en la red, pues el emisor
puede intentar e intentar enviar paquetes que han sido eliminados. Este tráfico no
debería de ser mucho, pues el número de paquetes bloqueados por el sistema de
filtrado tiende a ser una fracción del total de paquetes procesados. En caso de no
38
4 FILTRADO DE PAQUETES
4.7 Filtrado por dirección
ser así es muy posible que se esté bajo un ataque de DoS o denegación de servicio.
Por otra parte, retornando paquetes con códigos de error ICMP para cada paquete que viola las políticas de filtrado, estás dando información a un atacante y
un camino para probar el sistema de filtrado. Observando los paquetes que retorna
una respuesta ICMP, un atacante puede descubrir que tipo de paquetes violan o no
violan las políticas de seguridad. En tales casos no se debería dar esa información,
porque simplifica enormemente el trabajo del atacante. El atacnte conoce que 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 información con los códigos de error ICMP el atacante necesita más tiempo
para averiguar la misma información, si acaso lo consigue. Devolviendo los códigos de error ICMP se acelera los ataques, si reciben errores ICMP por algo no
tienen q esperar el timeout.
Como conclusión, lo más seguro parece que es no retornar ningún código de
error ICMP a los paquetes eliminados. Si se puede lo que es interesante es poder
retornar paqutes con códigos de error ICMP a los sistemas internos, para que no
esperen al timeout y por otra parte no retornarlo a los sitemas externos. Aún así si
no se ofrece tal posibilidad se debe configurar el sistema para que esté permitido
los paquetes inbound ICMP y estar prohibido los paquetes outbound con códigos
de error ICMP.
4.7. Filtrado por dirección
4.7.1. Introducción
La forma más simple, aunque no la más común, es el filtrado de paquetes
filtrando según la dirección. Filtrando de esta forma termite restringir el flujo de
paquetes basado en la dirección origen y/o destino de los paquetes, sin cosiderar el
protocolo que tratan. Este tipo de filtrado puede ser usado para permitir o no cierto
flujo entre unos hosts internos a unos hosts externos, por ejemplo, por ejemplo se
puede prever un ataque de spoofing, simplemente prohibiendo paquetes inbound
con una dirección origen que sea igual a una dirección válida dentro de la red a
proteger.
39
4 FILTRADO DE PAQUETES
4.7 Filtrado por dirección
Por ejemplo vamos a decir que se quieren prohibir este tipo de ataques, se
debería especificar esta regla:
Dirección
Inbound
@ origen
interna
@ destino
any
Acción
deny
Donde pone que la dirección es interna se refiere a cualquier número IP de algún
host de dentro de la red. En el router que haya entre la red interna e Internet, se
podría aplicar en cualquier interfaz con paquetes inbound esta regla. Cuando se
habla de inbound ser refiere a la red interna que debemos proteger.
4.7.2. Riesgos
Antes lo he comentado, no es seguro fiarse de las direcciones origen en las
cabeceras IP ya que pueden suplantarse, pueden modificarse. Solo en caso de que
se use algún tipo de autentificación criptográfica entre tú y el host al que se quiere
hablar, no sabes si el que te está hablando es quien dice ser u otra máquina que
pretende ser ese. Como he dicho antes hay que montarse algo usar otras técnicas,
ya sea en el mismo nivel de la torre OSI como por ejemplo IPSec o bien en niveles
superiores de la torre OSI, por encima del nivel de transporte, como puede ser
Secure SHell conocido como SSH, que intercambian claves de los servidores y no
se basa únicamente en las IP’s de las dos partes para crear una sesión, sino que
usan encriptado.
Hay dos tipos de ataques que se basan en esta forma de ataque de ataques
spoofing: los que se necesitan solo modificar la dirección origen y los de ’man in
the middle’, que ademas hay que mirar que se retorna.
40
4 FILTRADO DE PAQUETES
4.7 Filtrado por dirección
El primer ataque spoofing que se conoce se le atribuye a Kevin Mitnick uno de
los hackers más conocidos. El atacante envía paquetes que pretenden suplantar la
identidad de algún ordenador al que se le tiene algún tipo de confianza, esperando
que el ordenador atacante pueda usar esa confianza ataca al ordenador objetivo.
Puede ser que el atacante no le importe retornar ningún paquete de la máquina
atacada, ya que el resultado de los comandos enviados son predevibles, entonces
no necesita estar en el camino de retorno entre el ordenador atacado y el ordenador
que suplanta la información. En cambio es al contrario si se desea saber que le
retorna al ordenador suplantado, ya que habrá que situarse entre medio para que
cuando le devuelva los paquetes el ordenador atacado al suplantado se puedan
leer pero este es el segundo tipo de ataques. Ya que las respuestas se enviarán al
ordenador suplantado y no al atacante. También hay que tener una consideración,
que el ordenador suplantado recibirá paquetes de conexiones que no entiende y
de las que no participa, bogus connections como se le llama en inglés, entonces
este ordenador envía paquetes con el bit de reset activado para terminar dichas
conexiones. Lo que es malo para el atacante, pero es fácil de remediar, ya que
se puede suplantar una máquina que no exista, destrozando a la máquina real
mediante un ataque, inundando a la máquina suplantada, modificando la ruta entre
la máquina atacada y la suplantada o bien usando ataques donde no sea importante
el bit de reset.
41
5 EL SISTEMA OPERATIVO LINUX
5. El Sistema Operativo Linux
5.1. Introducción
5.1.1. Historia
A finales de los 40’s el uso de computadoras estaba restringido a aquellas empresas o instituciones que podían pagar su alto precio, y no existían los sistemas
operativos. En su lugar, el programador debía tener un conocimiento y contacto
profundo con el hardware, y en el infortunado caso de que su programa fallara, debía examinar los valores de los registros y páneles de luces indicadoras del estado
de la computadora para determinar la causa del fallo y poder corregir su programa, además de enfrentarse nuevamente a los procedimientos de apartar tiempo
del sistema y poner a punto los compiladores, ligadores, etc; para volver a correr
su programa, es decir, enfrentaba el problema del procesamiento serial ( serial
processing ).
La importancia de los sistemas operativos nace históricamente desde los 50’s,
cuando se hizo evidente que el operar una computadora por medio de tableros
enchufables en la primera generación y luego por medio del trabajo en lote en
la segunda generación se podía mejorar notoriamente, pues el operador realizaba
siempre una secuencia de pasos repetitivos, lo cual es una de las características
contempladas en la definición de lo que es un programa. Es decir, se comenzó a
ver que las tareas mismas del operador podían plasmarse en un programa, el cual
a través del tiempo y por su enorme complejidad se le llamó "Sistema Operativo".
Así, tenemos entre los primeros sistemas operativos al Fortran Monitor System (
FMS ) e IBSYS.
Posteriormente, en la tercera generación de computadoras nace uno de los
primeros sistemas operativos con la filosofía de administrar una familia de 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 propósitos en general: el
comercial y el científico. Así, al tratar de crear un solo sistema operativo para
computadoras que podían dedicarse a un propósito, al otro o ambos, puso en evidencia la problemática del trabajo en equipos de análisis, diseño e implantación
42
5 EL SISTEMA OPERATIVO LINUX
5.1 Introducción
de sistemas grandes. El resultado fue un sistema del cual uno de sus mismos diseñadores patentizó su opinión en la portada de un libro: una horda de bestias
prehistóricas atascadas en un foso de brea.
Surge también en la tercera generación de computadoras el concepto de la
multiprogramación, porque debido al alto costo de las computadoras era necesario
idear un esquema de trabajo que mantuviese a la unidad central de procesamiento
más tiempo ocupada, así como el encolado o ’spooling’ de trabajos para su lectura
hacia los lugares libres de memoria o la escritura de resultados. Sin embargo,
se puede afirmar que los sistemas durante la tercera generación siguieron siendo
básicamente sistemas de lote.
En la cuarta generación la electrónica avanza hacia la integración a gran escala, pudiendo crear circuitos con miles de transistores en un centímetro cuadrado
de silicio y ya es posible hablar de las computadoras personales y las estaciones
de trabajo. Surgen los conceptos de interfaces amigables intentando así atraer al
público en general al uso de las computadoras como herramientas cotidianas. Se
hacen populares el MS-DOS y UNIX en estas máquinas. También es común encontrar clones de computadoras personales y una multitud de empresas pequeñas
ensamblándolas por todo el mundo.
Para mediados de los 80’s, comienza el auge de las redes de computadoras
y la necesidad de sistemas operativos en red y sistemas operativos distribuidos.
La red mundial Internet se va haciendo accesible a toda clase de instituciones y
se comienzan a dar muchas soluciones ( y problemas ) al querer hacer convivir
recursos residentes en computadoras con sistemas operativos diferentes. Para los
90’s el paradigma de la programación orientada a objetos cobra auge, así como el
manejo de objetos desde los sistemas operativos. Las aplicaciones intentan crearse
para ser ejecutadas en una plataforma específica y poder ver sus resultados en
la pantalla o monitor de otra diferente (por ejemplo, ejecutar una simulación en
una máquina con UNIX y ver los resultados en otra con DOS ). Los niveles de
interacción se van haciendo cada vez más profundos.
LINUX hace su aparicion a principios de la decada de los noventa, era el
año 1991 y por aquel entonces un estudiante de informatica de la Universidad
de Helsinki, llamado Linus Torvalds empezo, -como una aficion y sin poderse
imaginar a lo que llegaría este proyecto, a programar las primeras líneas de código
43
5 EL SISTEMA OPERATIVO LINUX
5.1 Introducción
de este sistema operativo llamado LINUX.
Aquí está el primer mensaje que Linus Torvalds mandó al grupo de noticias
comp.os.minix:
From:[email protected] (Linus Benedict Torvalds)
Newsgroup: comp.os.minix
Subject: GCC-1.40 and a posix question
Message-ID: 1991Jul13, [email protected]
Date: 3 Jul 91 10:00:50 GMT
Hello netlanders,
Due a project I’m working on (in minix), I’m interested
in the posix standard definition. Could somebody please
point me to a (preferably) machine-readable format of the
latest posix rules? Ftp-sites would be nice.
Linux Torvalds [email protected]
Y aquí el que le siguió, este mensaje es considerado por muchos como el comienzo
de Linux:
From:[email protected] (Linus Benedict Torvalds)
Newsgroup: comp.os.minix
Subject: What would you like to see most in minix?
Summary: small poll for my new operating system
Message-ID: 1991Aug25, [email protected]
Date: 25 Aug 91 20:57:08 GMT
Organization: University of Helsinki.
Hello everybody out there using minixI’m doing a (free) operating system (just a hobby, won’t
be big and professional like gnu) for 386(486) AT clones.
This has been brewing since april, and is starting to get ready.
I’d like any feedback on things people like/dislike in minix;
as my OS resembles it somewhat (same physical layout of the
44
5 EL SISTEMA OPERATIVO LINUX
5.1 Introducción
file-sytem due to practical reasons) among other things.
I’ve currently ported bash (1.08) an gcc (1.40), and things seem to work.
This implies that i’ll get something practical within a few months,
and I’d like to know what features most people want. Any suggestions are we
but I won’t promise I’ll implement them :-)
Linux Torvalds [email protected]
Este comienzo estuvo inspirado en MINIX, un pequeño sistema Unix desarrollado
por Andy Tanenbaum. Las primeras discusiones sobre Linux fueron en el grupo de
noticias comp.os.minix, en estas discusiones se hablaba sobre todo del desarrollo
de un pequeño sistema Unix para usuarios de Minix que querían más.
Linus nunca anunció la version 0.01 de Linux (agosto 1991), esta versión no
era ni siquiera ejecutable, solamente incluía los principios del núcleo del sistema,
estaba escrita en lenguaje ensamblador y asumía que uno tenía acceso a un sistema
Minix para su compilación.
El 5 de octubre de 1991, Linus anunció la primera versión "Oficial" de Linux,
-version 0.02. Con esta versión Linus pudo ejecutar Bash (GNU Bourne Again
Shell) y gcc (El compilador GNU de C) pero no funcionaba mucho más. En este
estado de desarrollo ni se pensaba en los términos soporte, documentación, distribución, etc.
Después de la versión 0.03, Linus saltó en la numeración hasta la 0.10, más y
más programadores a lo largo y ancho de Internet empezaron a trabajar en el proyecto y después de sucesivas revisiones, Linus incrementó el número de versión
hasta la 0.95 (Marzo 1992). Más de un año después (diciembre 1993) el núcleo
del sistema estaba en la versión 0.99 y la versión 1.0 no llegó hasta el 14 de marzo
de 1994.
La serie actual del núcleo es la 2.4.x y sigue avanzando día a día con la meta
de perfeccionar y mejorar el sistema. En el momento de escribir este documento
la versión actual del kernel es la 2.4.19.
5.1.2. Linux
En la página web del kernel de Linux (www.kernel.org) se encuentra esta descripción, que creo que explica en pocas palabras qué es Linux.
45
5 EL SISTEMA OPERATIVO LINUX
5.1 Introducción
< <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. Características
Esta es una lista de las principales características que tiene Linux:
1. Todo el código fuente está disponible, incluyendo el núcleo completo y todos los drivers, las herramientas de desarrollo y todos los programas de
usuario; además todo ello se puede distribuir libremente. Hay algunos programas comerciales que están siendo ofrecidos para Linux actualmente sin
código fuente, pero todo lo que ha sido gratuito sigue siendo gratuito.
2. Multitarea: La palabra multitarea describe la habilidad de ejecutar varios
programas al mismo tiempo. Linux utiliza la llamada multitarea preeventiva, la cual asegura que todos los programas que se están utilizando en un
momento dado serán ejecutados, siendo el sistema operativo el encargado
de ceder tiempo de microprocesador a cada programa mediante el scheduler.
3. Multiusuario: Permite tener muchos usuarios usando la misma máquina al
mismo tiempo, pero a cada uno de ellos le da la sensación de tener la máquina para ellos únicamente.
46
5 EL SISTEMA OPERATIVO LINUX
5.1 Introducción
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 PC’s de 32 bits, Amiga
y Atari, también existen versiones para otras plataformas, como Alpha de
Compaq, ARM, MIPS, PowerPC tanto de 32 como de 64 bits, Sun SPARC,
UltraSPARC, el último procesador de Intel el IA-64, y muchos otros más.
5. Multiprocesador: Soporte para sistemas con más de un procesador está disponible para Intel y SPARC.
6. Funciona en modo protegido.
7. Tiene protección de la memoria entre procesos, de manera que uno de ellos
no pueda colgar el sistema.
8. Carga de ejecutables por demanda: Linux sólo lee del disco aquellas partes
de un programa que están siendo usadas actualmente.
9. Política de copia en escritura para la compartición de páginas entre ejecutables: esto significa que varios procesos pueden usar la misma zona de
memoria para ejecutarse. Cuando alguno intenta escribir en esa memoria,
la página (4Kb de memoria) se copia a otro lugar. Esta política de copia
en escritura tiene dos beneficios: aumenta la velocidad y reduce el uso de
memoria.
10. Memoria virtual usando paginación (sin intercambio de procesos completos) a disco: A una partición o un archivo en el sistema de archivos, o ambos,
con la posibilidad de añadir más áreas de intercambio sobre la marcha. Un
total de 16 zonas de intercambio de 128Mb de tamaño máximo pueden ser
usadas en un momento dado con un límite teórico de 2Gb para intercambio.
Este límite se puede aumentar con el cambio de unas cuantas líneas en el
código fuente, que lo está haciendo Oracle, para su distribución.
11. La memoria se gestiona como un recurso unificado para los programas de
usuario y para el caché de disco, de tal forma que toda la memoria libre
puede ser usada para caché y ésta puede a su vez ser reducida cuando se
ejecuten grandes programas.
47
5 EL SISTEMA OPERATIVO LINUX
5.1 Introducción
12. Librerías compartidas de carga dinámica (como los ficheros so de Solaris o
los ficheros DLL’s de windows) y librerías estáticas.
13. Se realizan volcados de estado (core dumps) para posibilitar los análisis
post-mortem, permitiendo el uso de depuradores sobre los programas no
sólo en ejecución sino también tras abortar éstos por cualquier motivo.
14. Compatible con POSIX, System V y BSD a nivel fuente. Control de tareas
POSIX.
15. Emulación de iBCS2, casi completamente compatible con SCO, SVR3 y
SVR4 a nivel binario.
16. Emulación de 386 en el núcleo, de tal forma que los programas no tengan
que hacer su propia emulación matemática. Cualquier máquina que ejecute Linux parecerá dotada de coprocesador matemático. Por supuesto, si el
ordenador ya tiene una FPU (unidad de coma flotante), esta será usada en
lugar de la emulación, pudiendo incluso compilar tu propio kernel sin la
emulación matemática y conseguir un pequeño ahorro de memoria.
17. Soporte para muchos teclados nacionales o adaptados y es bastante fácil
añadir nuevos dinámicamente.
18. Consolas virtuales múltiples: varias sesiones de login a través de la consola
entre las que se puede cambiar con las combinaciones adecuadas de teclas
(totalmente independiente del hardware de video). Se crean dinámicamente
y puedes tener hasta 64. Dispone también de Pseudo-terminales (pty’s).
19. Soporte para varios sistemas de archivo comunes, incluyendo minix-1, Xenix y todos los sistemas de archivo típicos de System V, y tiene un avanzado
sistema de archivos propio con una capacidad de hasta 4 Tb y nombres de
archivos de hasta 255 caracteres de longitud. Está el sistema de archivos
ext-3, ext-2 y el ReiserFS como los sitemas de archivo más comunes. Acceso transparente a particiones MS-DOS (o a particiones OS/2 FAT) mediante
un sistema de archivos especial: no es necesario ningún comando especial
para usar la partición MS-DOS, esta parece un sistema de archivos normal
48
5 EL SISTEMA OPERATIVO LINUX
5.1 Introducción
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.
También dispone de un sistema de archivos especial llamado UMSDOS que
permite que Linux sea instalado en un sistema de archivos DOS. Soporte en
sólo lectura de HPFS-2 del OS/2 2. Sistema de archivos de CD-ROM que
lee todos los formatos estándar de CD-ROM.
20. Incluidas en el núcleo tenemos una gran cantidad de protocolos de red como
por ejemplo: TCP/IP tanto IPversion 4 como IPversion6. Appletalk 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 multicomputación. Soporte para MPI y PVM, directamente o
con sistemas como Beowulf. LVS (Linux Virtual Server), etc
23. Y otras tantas virtudes de este Sistema Operativo que mantiene la comunidad de Internet y empresas como Oracle, Sun Microsystems, IBM, CompaqHP, Dell etc a parte de las propias empresas de cada distribución como Red
Hat, Debian, Suse, etc que entre todas y todos dan soporte a este sistema
operativo.
Aunque la mejor virtud son los miles de programas a través de Internet distribuidos gratuitamente o con licencias de libre distribución. Visitando páginas web se
1 Microsoft
es marca registrada de Microsoft Corporation
49
5 EL SISTEMA OPERATIVO LINUX
5.2 El Kernel
pueden encontrar miles de aplicaciones que ya están hechas y al disponer del código fuente pueden mejorarlas. También existe una gran comunidad que resuelve
cualquier problema que pueda surgir al kernel. Las respuestas a los problemas de
seguridad han demostrado ser más rápidas que muchas empresas.
5.2. El Kernel
5.2.1. Introducción
El Kernel puede verse como el corazon del sistema operativo, cargado en la
memoria RAM cuando se enciende el ordenador y permanece en funcionamiento
hasta que este se apaga. Tiene principalmente dos responsabilidades:
1. Servir a los requerimientos de programación a bajo nivel (por ejemplo tratando las interrupciones hardware).
2. Proveer un entorno a los procesos, que son las instancias en ejecución de
los programas o threads.
Se dice que el kernel de Linux es monolítico, que es como un gran ejecutable, que
consiste de muchos componentes divididos lógicamente.
5.2.2. Modos
El Kernel puede trabajar en dos modos: usuario o kernel. La mayoría de las
ejecuciones de programas de los usuarios se hacen en modo usuario o ’user mode’
como se dice en inglés. Este modo de ejecución no tiene acceso directo a las
estructuras de datos del kernel o a los equipos hardware. Puede cambiarse a modo
kernel de varias formas:
1. Un programa hace una llamada al sistema o ’system call’, por ejemplo cuando una función de una libreria hace una petición al kernel.
2. Una señal de excepción provinente de la CPU, que son condiciones que
requieren especial atención, por ejemplo en una división por cero.
50
5 EL SISTEMA OPERATIVO LINUX
5.2 El Kernel
3. Una interrupción que se hace hacia la CPU provinente de algún equipo hardware indicando que requiere su atención, como por ejemplo cada vez que
apretamos cualquier tecla desde el teclado.
El kernel se pasa la mayoría del tiempo en el modo kernel ejecutándose detrás
de los procesos de usuario. Además hay muchos threads que se están ejecutando
detrás del propio kernel en modo kernel, que se encargan de hacer las actividades
necesarias para mantener en funcionamiento al sistema operativo. Una vez que
todas las operaciones pendientes en modo kernel se han completado y tratado, el
kernel vuelve al modo usuario otra vez.
5.2.3. Módulos
El kernel es capaz de cargar dinámicamente porciones adicionales de código
(módulos) mientras se está ejecutando, para mejorar su funcionalidad. Por ejemplo, hay módulos que pueden añadir soporte para sistemas de ficheros que no es
necesario que estén cargados siempre. Cuando la funcionalidad proveida por el
módulo ya no se necesita más, el módulo puede ser descargado, liberando memoria.
5.2.4. Procesos
Un proceso es una instancia de un programa en ejecución. Cada proceso tiene:
1. Un estado, ya sea ’running’ (ejecutándose en el procesador), ’sleeping’ (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 señal de control o porque están haciendole un
trace) o zombie (zombie el proceso esta apunto de ser eliminado).
2. Un contexto, una copia con todos los registros de la CPU que indican el
estado del proceso (PC, SP, PSW, registros de propósito general, registros
de coma flotante y regsitros para el control de memoria)
3. Un descriptor de procesos, es una estructura de datos del tipo task_struct
que guarda toda la información relacionada con un proceso.
51
5 EL SISTEMA OPERATIVO LINUX
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 están en la cola de procesos esperando tendrán su oporturnidad
para ejecutarse en la CPU en turnos. El proceso que ’controla’ la CPU en un
instante de tiempo se le llama ’current’ porque es el programa que esta corriendo
en ese momento. El proceso que se encarga de decidir quien es el que pasa a estado
ready o un estado de ejecutandose es el scheduler o ’context switch’, porque se
encarga de cambiar el contexto actual. El cometido de este es guardar el contexto
actual del proceso ejecutándose (una foto del estado de la CPU en ese momento)
y cargar el contexto de algún proceso que este esperando para ser ejecutado, o
un proceso con el estado de ready. Los cambios de contexto solo pueden hacerse
cuando el kernel está en modo usuario, así que en el modo kernel no pueden
hacerse cambios de contexto inmediatamente por eso se le llama non-preemptive.
Cada proceso de usuario se ejecuta en su propio espacio de usuario, una porción asignada del total de memoria disponible. Espacios de usuario (o partes de él)
pueden compartirse entre procesos si se pide, o bien automáticamente si el kernel
lo cree apropiado. La separación del espacio de direcciones hace que un proceso
no pueda interferir con una operación de otro proceso o del sistema operativo.
Además de los procesos normales de usuario ejecutándose en el sistema, hay
varios threads del kernel que se crean al iniciar el sistema y que corren permanentemente en modo kernel, encargandose de funciones de mantenimiento del kernel.
5.2.5. Sincronización
El kernel es reentrante, varios procesos pueden estar ejecutándose en modo
kernel a la vez. Por supuesto, en un sistema con solo un procesador solo un proceso
puede ejecutarse, porque el resto de procesos están bloqueados esperando en una
cola. Ejemplo: un proceso pide leer un fichero, el sistema virtual de ficheros el
’Virtual File System’ traduce la petición en una operación de bajo nivel del disco
y lo pasa al controlador del disco, por detrás del proceso. En vez de esperar hasta
que la operación de escritura a disco se haya completado, miles de ciclos de CPU
52
5 EL SISTEMA OPERATIVO LINUX
5.2 El Kernel
más tarde, el proceso da voluntariamente a la CPU después de hacer la petición
y el kernel permite que otro proceso esperando pueda ejecutarse en la CPU y
este a su vez puede entrar en el modo kernel. Cuando una operación a disco se a
completado (señalado por una interrupción de hardware), el proceso actual da la
CPU al que trata las interrupciones (el interrupt handler) y el proceso original se
despierta, siguiendo su estado a donde lo había dejado.
Para poder implementar un kernel reentrante, hay que tener especial cuidado
para asegurar la consistencia de las estructuras de datos del kernel. Si un proceso
modifica un contador de otro proceso esperando sin que este lo sepa, el resultado
puede ser potencialmente desastroso. Hay que seguir los siguientes pasos para
preever este tipo de sucesos:
1. Un proceso solo puede reemplazar a otro en modo kernel si ha dejado 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 críticas, donde el código
tiene que completarse sin ninguna interrupción, y asegurarse luego de volver
a habilitarlas.
3. El uso de spin locks y semáforos de control para acceder a estructuras de
datos.
Los semáforos consisten en un contador inicializado a uno, una lista de procesos
esperando para acceder a la estructura de datos y dos métodos atómicos llamados up() y down() que incrementan y decrementean el contador respectivamente.
Cuando se accede a una estructura protegida por un semáforo, se llama a la función 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 añade a la lista del semáforo de procesos
esperando. De forma parecida, cuando un proceso ha terminado de tratar los datos
de la estructura, llama a la función up() y el siguiente proceso de la lista consigue
acceder.
Hay que tomar precauciones, porque hay que asegurarse que no hay deadlocks
entre varios procesos, en el caso de que controlen varios recursos. Si cada uno está
53
5 EL SISTEMA OPERATIVO LINUX
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 jamás lo harán. Si se
quiere profundizar en deadlocks buscar por Internet el problema de los filósofos
que cenan o dicho en inglés ’The dining Philosophers Problem’ o en cualquier
libro de sistemas operativos.
5.2.6. Comunicación entre procesos
Una señal es un mensaje corto, enviado entre dos procesos o entre el kernel
y un proceso. Hay dos dipos de señales que se usan para notificar eventos a del
sistema a los procesos:
Eventos asíncronos. Por ejemplo SIGTERM, enviado cuando se usa el Ctrl-C del
teclado.
Errores o excepciones síncronas. Por ejemplo SIGSEGV cuando un proceso intenta acceder a una dirección ilegal.
Hay cerca de 20 señales diferentes definidas en el estandart POSIX, algunas de
ellas pueden ser ignoradas. Algunas señales no pueden ser ignoradas y no son
tratadas siquiera por el proceso mismo. Linux usa el sistema V o ’System V’
de comunicación entre procesos llamado en inglés Inter-Process-Comunication
(IPC).
5.2.7. Control de la Memoria
Linux usa memoria virtual, un nivel de abstracción entre los pedidos de memoria por parte de los procesos y las direcciones físicas de la memoria. Así hace
posible lo siguiente:
1. Permite que muchos procesos corran incluso cuando la suma de toda la
memoria exceda la RAM física disponible.
2. Hace posible también un espacio de direcciones contigua, independiente a
la organizacioón de la memoria física.
54
5 EL SISTEMA OPERATIVO LINUX
5.2 El Kernel
3. Paginado, porciones de datos o código que solo necesitan cargarse en memoria cuando se ejecutan o son accedidos y pueden intercambiarse a disco
cuando no son necesarios.
4. Imágenes compartidas de programas y librerias, haciendo un uso más eficiente de la memoria.
5. Recolocación de los programas en memoria de forma completamente transparente.
El espacio de direcciones se divide en porciones de 4kBytes llamadas páginas, las
cuales forman la unidad básica de todas las transacciones de la memoria virtual.
Como la suma total de direcciones de memoria excede a lo que hay en la memoria
RAM, solo un grupo de todas las páginas disponibles se guardan en la RAM a la
vez. Aún así, un página tiene que estar presente en la RAM para poder acceder a
ella ya sea para leer o guardar datos como para ejecutar programas.
Como cualquier página puede volver a ponerse en cualquier página física, el
kernel tiene que llevar el control de donde estan las páginas usadas. Y además
hacer la conversión de direcciones lógicas en direcciones físicas.
En el hardware Intel x86, Linux usa dos nivels de paginación (aunque internamete usa tres niveles para mejorar la portabilidad) para reducir la cantidad de
memoria usado pora las tablas de paginación. Para convertir una dirección lógica
en una física, las tablas se consultan en este orden: Page Global Directory luego
la Page Table para conseguir el número de página y el offset de la página. Por eso
una dirección lógica se divide en tres partes: Directorio, Tabla y Offset. Como se
puede direccionar un espacio de 4GBytes (usando 32 bits) y se usa una página del
tamaño de 4kB, los 10 bits más significativos de la dirección apuntan al directorio,
los 10 siguientes bits apuntan a la tabla (de ahí que se requiera identificar la página) y los 12 siguientes bits, los menos significativos, nos marcan el offset dentro
de la página.
5.2.8. El código
El código fuente del kernel está hecho de alrededor de dos millones de líneas
de código. Puede parecer muy intimidatorio, pero es importante recordar que muy
55
5 EL SISTEMA OPERATIVO LINUX
5.2 El Kernel
poca gente entiende todos los subsitemas y el código asociados a ellos en profundidad. Se puede mejorar la productividad simplemente sabiendo donde buscar el
código específico. Paso a comentar qué se puede encontrar en el código fuente y
donde va cada cosa.
Para empezar es necesario bajarse la última versión del kernel de http://www.kernel.org
la versión actual es la 2.14.19. Pero es recomendable visitar la página web, ya que
seguro que hay nuevas actualizaciones.
(bash)$ wget http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.19.tar.gz
Tras ello se descomprime y se accede al directorio:
(bash)$tar xvzf linux-2.4.19.tar.gz
(bash)$cd linux-2.4.19
(bash)$dir
direcciones total 248
drwxr-xr-x 18 carlosm grp
4096 Aug
-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/
5 EL SISTEMA OPERATIVO LINUX
-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 lógicamente en una estructura de
directorios.
Documentation: Información sobre plataformas y devices específicos igual que
información general sobre el kernel.
arch: Código específico para cada arquitectura: i386, sparc, alpha, arm, cris, ia64,
mips, mips64, parsic, ppc (PowerPC 32bits), ppc64(PowerPC 64bits), s390,
s390x, sparc, sparc64.
drivers: Código para cada device específico: tarjeta de sonido, tarjeta ethernet,
etc
fs: Código para los sistemas de ficheros o ’Filesystems’: ext2, ext3, vfat, etc
include: Todos los ficheros de cabecera separado en subdirectorios de acuerdo
con el tipo fichero y su función.
init: Todo el código asociado con el proceso de arranque e inicialización.
IPC: Código de la comunicación entre procesos o Inter Process Communication:
implementación de la memoria compartida, etc
kernel: El código del núcleo del kernel, la parte más importante de Linux son solo 396KBytes y 31 ficheros: scheduling, señales, printk, fork, softirq, contextos, tiempo, cargador de módulos, etc
lib: Librerías relacionadas con el kernel, por ejemplo descompresión de la imagen del kernel, funciones de lock, etc
mm: Memory Managment todos los ficheros con el código de trato de memoria.
net: Todo el código relacionado con la red. Aquí es donde le meteré mano para
crear el firewall.
scripts: Scripts relacionados con el kernel, como por ejemplo el patch-kernel.
57
5 EL SISTEMA OPERATIVO LINUX
5.2 El Kernel
El mejor lugar para empezar leyendo el código depende de las motivaciones que
tenga cada uno, yo por mi parte fui directamente al directorio net, al directorio
kernel y al directorio include, el resto de directorios casi no los he visitado, pero
claro mi intención es construir un firewall, cada uno tendrá sus motivos.
Si por ejemplo, se desea escribir un driver para un hardware que todavía no
está soportado, en ese caso se empieza leyendo el código para los drivers más
parecidos que ya están implementados. Dicen los hackers del kernel que la mejor
forma de introducirse a la programación del kernel es escribiendo drivers, ahí
queda eso para los interesados.
En cambio si lo que se desea es escribir un nuevo sistema de ficheros la idea es
buscar dentro del directorio fs algo que se parezca a lo que queremos implementar.
Si en cambio se desea jugar con la programación dentro del kernel haced lo
que yo hice que fue probando en la inicialización del sistema, en init/main.c, específicamente en la función start_kernel() o bien ojeando los ficheros que hay en
el directorio kernel.
5.2.9. Numeración
Si se desea hacer cambios e introducir código en el kernel para contribuir
en el desarrollo, es importante entender el ciclo de desarrollo adoptado por la
comunidad del kernel de Linux. Paso a comentar el proceso de desarrollo:
Series estables
Las series estables tienen el número de versión con teóricamente casi ningún
bug para ser arreglado o ninguna mejora para hacer. La mayoría de distribuciones
usan estas series, y si no se quiere uno aventurar encontrando bugs y fallos es recomendable usar estas releases para trabajar. Las peores series que hay se marcan
con una extensión de ’-dontuse’ (don’t use: no usar) en el nombre del fichero. Estas son por ejemplo las 2.0, 2.2.x y las 2.4.x que son números pares y a medida
que van saliendo nuevas versiones se va aumentando el número de la serie, ahora
las últimas versiones estables para 2.0 es la 2.0.39 para la serie de kernels 2.2 se
terminó con la 2.2.22 y ahora mismo (a la hora de escribir este documento) la última versión estable del kernel de Linux es la 2.4.19, la anterior fue la 2.4.18 y la
58
5 EL SISTEMA OPERATIVO LINUX
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 añade ’-pre’ más el número de versión del
prepatch.
Series inestables
Los kernels inestables contienen menos código probado y los cambios entre
las series son más grandes. Sirven para provar los nuevos drivers, las mejoras
experimentales y los algoritmos más inovadores. La última versión beta del kernel
de Linux es la 2.5.38.
Generalmente, es muy mala idea ejecutar un kernel inestable en un sistema
que está en producción. Lo recomendado es tener un ordenador dedicado para
hacer el testing con kernels inestables.
Parches intermedios
Entre dos releases de kernels estable e inestable, hay varias releases intermedias que intentan testear un pequeño número de cambios a la vez. Estas releases
tienen o bien la extensión -preXX o bien la extensión -YYXX, donde XX es el
número de la versión incrementada y el YY son las iniciales de quien lo mantiene,
por ejemplo -ac12 indica incrementalmente la extensión de Alan Cox. Al parche
intermedio actual está numerado como 2.4.20-pre7.
5.2.10. Compilación del núcleo
Si se va a modificar el núcleo es necesario luego compilarlo e instalarlo en
la máquina. Al hacer el firewall, cada vez que modificaba cualquier cosa también
tenía que compilar e instalarlo, así que es una parte importante del proceso.
No es necesario compilar el núcleo en la misma máquina en la que va a correr
el kernel, yo lo que hago personalmente es que de todas las máquinas que tengo
la más rápida es la encargada de hacer la compilación, y luego se pasa la imagen
al ordenador.
Es recomendable descomprimir el kernel en el directorio /usr/src y tener cada
versión en su directorio de forma ordenada. por regla general se pone la versión
59
5 EL SISTEMA OPERATIVO LINUX
5.2 El Kernel
actual, la que va a correr en el sistema, en el directorio /usr/src/linux. Pero es solo
una recomendación, no es necesario que sea así.
En el caso de ser una versión nueva, sin haberse compilado ninguna vez, no
es necesario hacer un ’make clean’, para más adelante antes de hacer nada es
recomendable hacerselo, así se elimina código compilado que puede molestar.
Vayamos a la compilación: Primero descompilar el kernel.
tar xvzf lnux-x.y.z.tar.gz
El x.y.z corresponde a la versión actual del kernel, que corresponde al fichero
bajado. En caso de tener la extensión .bz2 es necesario descomprimirlo primero y
luego hacerle un tar mediante la orden siguiente:
bz2cat linux-x.y.z.tar.bz2 | tar xvf Después de bajarse la última versión del kernel y descomprimirlo es necesario
entrar dentro del mismo directorio y empezar a configurar. Entrar en el directorio
que se acaba de descompilar, y ahora es hora de configuar el kernel con todas
los módulos, drivers y opciones que queramos o necesitamos incluirle al kernel.
Dependiendo de lo que estemos usando se configurará de una manera o de otra.
Existe principalmente tres maneras de configurar el kernel:
1. make config
2. make menuconfig
3. make xconfig
Cada una de ellas dependiendo de si disponemos X windows o si solo podemos
usar un menu basado en texto con la consola. Yo uso preferiblemente las XWindos
en mi entorno de trabajo (no en los servidores), así que uso la tercera opción.
make xconfig
Aparecerá entonces un menú con todas las preguntas que debemos responder,
agrupadas por temas. A cada una de las preguntas se debe responder con un ’y’
60
5 EL SISTEMA OPERATIVO LINUX
5.2 El Kernel
o bien con un ’n’, la primera es para aceptar esa parte de código y la segunda
para no incluirlo. Puede haber en el caso de los drivers por ejemplo, una tercera
opción ’m’ que significa ’module’ y es para compilar el módulo pero no se incluye
directamente en el kernel, sino que como un módulo cargable. Es como decir
quizás lo uso. Igualmente cada una de las opciones tiene un ’si no entiede lo que
quiere decir ponga un ...’ si o no, en cada caso particular. Para hacer este paso
es necesario saber unas cuantas cosas del sistema, como por ejemplo que tipo de
tarjeta de red disponemos, que tipo de tarjeta de video, y esas cosas, porque sino
dificilmente os funcionará por ejemplo la tarjeta de red. Para una información
más detallada de cada grupo de opciones leer el Kernel-HOWTO, donde aparece
mucho más detallado.
Cuando se termina de configurar, se preparará las dependencias en poco tiempo, a menos que su PC sea muy lento. También será necesario hacer un make
clean, para borrar todos lo ficheros objeto y otras cosas que las versiones anteriores han dejado, se recomienda hacerlo cada vez que se recompile el kernel.
make dep
make clean
Después de preparar dependencias, puede ejecutar ‘make zImage’ o ‘make zdisk’
(esta es la parte que tarda más tiempo). ‘make zImage’ compilará el núcleo y lo
dejará comprimido en arch/i386/boot/zImage junto a otros ficheros. Con ‘make
zdisk’ el nuevo núcleo se copiará además en el disquete que esté puesto en la disquetera “A:”. ‘zdisk’ es interesante para probar núcleos; si explota (o simplemente
no hace nada) se quita el disquete de la disquetera y podrá arrancar el núcleo antiguo. Además sirve para arrancar si borró accidentalmente el núcleo del disco
duro. También puede usarlo para instalar nuevos sistemas simplemente volcando
el contenido de un disco en otro. Los núcleos recientes están comprimidos, con
una ‘z’ comenzando su nombre. Un núcleo comprimido se descomprime automáticamente al cargarse el sistema.
make zImage
Existen más makes, por ejemplo con ‘make mrproper’ hará una limpieza mucho
más ’intensa’. Esta suele hacer falta cuando se actualiza (parchea) el núcleo. Pero
61
5 EL SISTEMA OPERATIVO LINUX
5.2 El Kernel
esta opción borra también su fichero de configuración del núcleo, así que guarde
una copia del correspondiente fichero .config si cree que le interesa.
La opción ‘make oldconfig’ intentará configurar el núcleo con un fichero de
configuración anterior. Aunque a partir del 2.0.xx no es necesario, make recuerda
la última configuración. Para evitar todo el proceso del ‘make config’. Si no se
ha compilado anteriormente el núcleo o no se tiene un fichero de configuración
anterior, no se debe elegir pues se instalará la configuración por defecto.
Una vez que tenga un nuevo núcleo que parezca funcionar como desea, será
el momento de instalarlo. Casi todo el mundo utiliza LILO (LInux LOader) para
esto. Con ’make zlilo’ se instalará el núcleo ejecutando LILO, quedando listo
para rearrancar, pero esto solo funcionará si LILO está bien configurado para su
sistema: el núcleo es /vmlinuz, LILO está en /sbin y la configuración de LILO
(/etc/lilo.conf) es coherente con lo anterior. Pero no es difícil hacerlo paso a paso,
además se puede compilar un kernel en un ordenador más potente y luego pasarlo
a otro sistema, en tal caso no funciona.
El fichero de configuración será como éste:
image = /vmlinuz
label = Linux
root = /dev/hda1
...
La línea ’image =’ apunta al núcleo instalado actualmente. Casi siempre es /vmlinuz. ‘label’ es el identificador usado para seleccionar qué sistema arrancar, y
’root’ es el disco o partición a usar para el directorio raíz.
Ahora se copia el fichero zImage, que se ha creado antes, que normalmente
está en arch/i386/boot y se llama bzImage. Copiar el fichero este y nombrarlo de
alguna manera para reconocerlo y no confundirlo con otras versiones del kernel.
Por ejemplo vmlinuz-x.y.z, donde x.y.z es la versión actual del kernel compilado.
Copiarlo al directorio /boot, para tenerlo todo bien ordenado.
cp arch/386/boot/bzImage /boot/vmlinuz-versionactual
Y entrar en el fichero /etc/lilo/config o bien /etc/lilo.conf según la distribución,
para la configuración del LILO.
62
5 EL SISTEMA OPERATIVO LINUX
5.2 El Kernel
vim /etc/lilo.conf
Allí añadir las líneas necesarias para la nueva versión del kernel que acabamos de
compilar. Nombrar con el label al nuevo sistema.
image = /vmlinuz
label = Linux
root = /dev/hda1
...
image=/boot/bzImage-versionactual
label=miNuevoLinux
root=/dev/hda1 # Atencion!!
read-only
En donde pone /dev/hda1 hay que asegurarse de poner el nombre bien, en este ejemplo tenemos /dev/hda1 que corresponde a la partición primera del primer
disco duro. Pero no significa que sea así en todos, en mi disco duro por ejemplo
el directorio raiz corresponde a la quinta partición. Por eso en mi sistema tengo /dev/hda5. Pero también podría estar en el disco duro scsi, por lo que sería
/dev/sda5. Bueno tener cuidado porque sino pegará una petada increhible.
Tras haber incluido estas líneas en el fichero de configuración del LILO, es
necesario ejecutarlo para que tenga efecto la nueva configuración. Esto se hace de
la siguiente manera:
lilo
Para arrancar uno de los antiguos núcleos, se copia las líneas anteriores incluyendo ‘image = xxx’ al principio del fichero de configuración de LILO, y se cambia
‘image = xxx’ por ‘image = yyy’ donde ‘yyy’ es el nombre de camino completo
al fichero de la copia de seguridad guardada. También es necesario cambiar ‘label
= zzz’ por ‘label = linux-backup’ y reejecute LILO. Puede ser que necesite poner una línea en el fichero con ‘delay=x’ donde x son las centésimas de segundo
que LILO esperará antes de arrancar con la primera opción, de modo que pueda interrumpirse (con la tecla SHIFT) y seleccionarse qué núcleo desea arrancar
(tecleando la etiqueta (label) asignada).
63
5 EL SISTEMA OPERATIVO LINUX
5.2 El Kernel
La órdenes make modules; make modules_install compilarán los módulos que
hayamos seleccionado, y los instalarán. No olvidar ejecutar depmod -a en cuanto
hayamos arrancado con dicho núcleo. En caso de que estemos compilando por segunda vez una misma versión de núcleo, y hayamos variado el número de módulos
a compilar, es posible que la ejecutar make dep nos encontremos con un mensaje de error; esto se debe a que los antiguos módulos que no hayamos compilado
ahora no son borrados. Pueden borrarse tranquilamente.
Y ya está, reiniciar el sistema y escoger la nueva versión en la lista que muestra
el lilo. Y lo lógico es que todo funcione correctamente.
Pero ¿qué pasa si hay problemas? El principal problema es que no se haya
ejecutado el comando lilo. Para esos casos lo mejor que puede hacerse ahora es
arrancar con un disquete, preparar otro disquete para arrancar Linux, con ’make
zdisk’ se hace uno fácilmente, aunque debíamos haberlo hecho antes si es el 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 raíz (/)
tiene, dónde está y su tipo (por ejemplo, ext2 o minix). También hay que saber
dónde están los ficheros de /usr, en otra partición.
En nuestro ejemplo, / (el directorio raíz) es /dev/hda1, y el sistema con las
fuentes del núcleo es /dev/hda3, montado como /usr normalmente (que es donde
tenemos /usr/src que estaba el kernel compilado). Ambos son sistemas ext2. La
imagen compilada estará en el sistema de las fuentes. La idea es que si hay un
fichero zImage correcto, puede salvarse en un disquete.
En primer lugar, arranque con un disquete de instalación o de rescate, y monte
el sistema de ficheros que contenga el núcleo a usar:
mkdir /mnt
mount -t ext3 /dev/hda3 /mnt
Tener en cuenta que los sistemas de ficheros con los actuales kernels es el ext3 pero puede ser también un reiserfs o bien un ext2, según el caso. Si mkdir le dice que
el directorio ya existe, no hay problema. Ahora, pase al directorio donde está el núcleo compilado. De esta forma tenemos que /mnt + /usr/src/linux/arch/i386/boot /usr = /mnt/src/linux/arch/i386/boot
64
5 EL SISTEMA OPERATIVO LINUX
5.3 Herramientas
Ponga un disco con formato en la unidad “A:” (que no sea el disquete con el
que ha arrancado) y copie el núcleo a él:
cd /mnt/usr/src/linux/arch/i386/boot
dd if=zImage of=/dev/fd0
rdev /dev/fd0 /dev/hda1
Vaya a / y desmonte el sistema de ficheros:
cd /
umount /mnt/usr
Ahora puede rearrancar el sistema desde el disquete. ¡No olvides ejecutar LILO!
Hay otra alternativa. Si el núcleo está en el directorio raíz (por ejemplo /vmlinuz), puede usarlo para un disquete de arranque. Suponiendo las condiciones
anteriores, haríamos los cambios siguientes en el ejemplo anterior: /dev/hda3 por
/dev/hda1 (el sistema raíz), /mnt/src/linux por /mnt, y ‘if=zImage’ por ‘if=vmlinuz’.
El resto puede ignorarse. Usar LILO con discos grandes (de más de 1024 cilindros) puede dar problemas. Le recomendamos que lea el mini-HOWTO sobre
LILO para más información.
5.3. Herramientas
Esta sección pretende explicar las herramientas fundamentales para el desarrollo del kernel. Tenemos que son necesarios los editores de texto, programas
para desarrollo, para navegar por el código y para debugar. Las herramientas de
debugar se explican en el siguiente apartado.
5.3.1. Editores de texto
Hay una gran cantidad para escoger editores de texto. Cada uno es partidario
de uno, se han hecho debates para saber qué editor es el mejor para trabajar en la
programación del kernel. Entre los que está la discusión es entre el editor vim y
el emacs. Pues explicaré ambos por encima, aunque yo soy de los partidarios del
vim.
65
5 EL SISTEMA OPERATIVO LINUX
5.3 Herramientas
vim
Como todo sistema UNIX, Linux también tiene el editor vi disponible, y sino
el vim (vi-improved que viene a decir el vi-mejorado) con algún contenido extra.
Las razones para usar vim en la programación dentro del kernel son:
1. Integra de una forma limpia los ctags. Si se hacen tags en el directorio del
código del kernel, se puede acceder rápidamente a las funciones y a las
definiciones de las variables usando las teclas Ctr-] mientras el cursor está
sobre la función o variable en cuestión.
2. El auto-completado de los nombres de variables y funciones puede ahorrar
el tiempo evitando errores de deletreo. Esto es especialmente interesante
cuando se programa el kernel ya que la mayoría de nombres son bastante
largos. Así que al usar esta herramienta, solo hay que escribir la primera
parte de la variable o de la función y apretar Ctrl+P repetidamente mientras
va buscando todos los posibles matches.
3. Es rápido de cargarse.
4. Ocupa poco y deja más memora para la recompilación del kernel.
5. Altamente configurable. Entre otras cosas, los comandos que se accionan
con las teclas se pueden volver a mapear fácilmente. Es muy útil si se encuentra algún comando que se usa mucho y tiene una combinación de teclas
incómoda.
6. Está integrado con el cscope. Para hacer búsquedas rápidas del código.
7. Muchas veces se puede encontrar este fántastico programa en discos de
arranque de rescate los llamados ’rescue boot disk’.
8. Los accesos directos del teclado hace que se requiera muy poco movimiento
de manos, al menos si no se ha modificado el mapeado.
Probablemente la mejor forma de aprender los fundamentos más básicos del vim
sea leer el vim-HOWTO que se puede encontrar en http://www.tldp.org/HOWTO/VimHOWTO.html
66
5 EL SISTEMA OPERATIVO LINUX
5.3 Herramientas
emacs
Como el vi, el emacs está en muchos sistemas y tiene también muchos fans.
Las razones para usar emacs en la programación del kernel son varias:
1. Tiene gran cantidad de librerías para mejorar la productividad.
2. Buena integración con los etags.
3. También integra búsquedas con grep y cscope.
4. Integración con gdb, muy útil a la hora de debugar código.
5. Las teclas de uso pueden ser más intuituvas, por ejemplo no es necesario
tener que entrar en ningún modo para empezar a escribir inmediatamente
en un documento. Y es por eso que es el editor preferido por aquellos que
no les gusta hacer las cosas tan formales.
Los inconvenientes que tiene son también varios.
1. Se usa mucho la tecla Ctrl. Se recomienda mapear las teclasl Ctrl a otra,
como por ejemplo Caps-Lock.
2. Es un gran paquete, no es recomendable para sistemas con espacio limitado
en el disco duro.
3. Tarda más en cargarse en sistemas más modestos.
4. Necesita más memoria, así que deja menos memoria a la hora de recompilar
el kernel.
5. Dicen que los etags son inestables y que les dan core dumpeds muy 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 EL SISTEMA OPERATIVO LINUX
5.3 Herramientas
5.3.2. Herramientas de desarrollo
make
El programa make es fundamental y básico. Es el que se usa para determinar
qué partes de un proyecto con muchos ficheros código fuente necesitan ser reconstruidos. Solo aquellos ficheros de código que hayan sido modificados serán
reconstruidos antes del final de la fase lincaje. Esta propiedad es una gran mejora
para el programador del kernel, porque una vez el kernel está construido recompilarlo para incluir los cambios tarda muchísimo menos que si tuviera que hacerlo
todo. El make trabaja con un fichero makefile, es un fichero que contiene todas
las relaciones y dependencias entre ficheros fuente, entre junto con los comandos
necesarios para construirlos y compilarlos.
En cada directorio del kernel se encuentra un fichero makefile, incluyendo el
fichero raíz. Cuando se invoca el comando ’make dep’ o ’make bzImage’ o bien
el ’make modules’, make opera desde el nivel más alto y trabaja recursivamente
con todos los ficheros makefile de cada uno de los subdirectorios, dependiendo de
las opciones con que se incluyeron en el paso de configuración.
lclint
Algunos errores de programas se pueden resolver al principio del ciclo de
desarrollo, ahorrando tiempo y esfuerzo. Puede que no importe este tipo de programas cuando se analiza código normal, con programas de menor envergadura,
pero los bugs en el kernel son más difíciles de tratar y pueden hacer aparecer problemas muy serios. Además mientras un usuario, está más o menos acostumbrado
a que se pare o haga core dumps un cliente de correo por ejemplo, pero lo que
no está acostumbrado y no puede acostumbrarse es a que el sistema operativo se
congele o peor aún que pierda datos.
lclint es un programa que puede ser usado para checkear el código C de manera
estática, que significa hacer checks o comprobaciones antes que se haya compilado o ejecutado. Como lint, lclint puede ser ejecutado para recoger errores comunes
de C. Sin embargo, lcint puede hacer mucho más para ti, pero para ello hay que
aprender a como usarlo anotando en el código comentarios de una manera espe-
68
5 EL SISTEMA OPERATIVO LINUX
5.3 Herramientas
cífica.
En resumen, lclint puede dar facilidad a la hora de comprobar errores antes de pasar el compilador. Para averiguar más información buscar en la página
http://lclint.cs.virginia.edu/.
5.3.3. Navegación
Una de las actividades que más se hace cuando se empieza a programar con
el kernel es navegar arriba y abajo por todo el código, al menos hasta que uno se
familiariza con la gran cantidad de código fuente. Hay herramientas que facilitan
esta navegación.
grep
grep se usa para encontrar líneas que concuerden con un patron dado. Es una
herramienta muy útil para localizar de una forma rápida definiciones de variables
o de funciones. Por ejemplo queremos buscar todas los ficheros que contengan la
palabra sk_buff, para averiguar la estructura de datos que se guarda en los buffers
sk. Pues se ejecuta el comando siguiente:
grep -nH ’sk_buff’ -r * > fichero_salida_grep
Este comando busca recursivamente (-r) por todos los ficheros y directorios (*)
del árbol de código e imprime todos los los nombre de ficheros (-H) y el número
de línea (-n) donde aparece sk_buff, el resultado de la búsqueda es recomendable
volcarlo a un fichero para luego poder navegarlo.
El resultado de la búsqueda anterior es muy larga, debido a que es una estructura de los datos que recibimos por las tarjetas de red y cada driver tiene una,
además de ser la estructura dentro del kernel de los datos que se reciben. Aún así
aquí pongo el resultado de unas cuantas líneas:
net/bluetooth/hci_core.c:1028:int hci_send_acl(struct hci_conn *conn,
struct sk_buff *skb, __u16 flags)
net/bluetooth/hci_core.c:1031: struct sk_buff *list;
69
5 EL SISTEMA OPERATIVO LINUX
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 código de forma parecida a como lo hace
grep, pero es más inteligente y provee una interfaz mucho más bonita para trabajar.
Se puede buscar por definiciones, usos, strings, etc
Antes de poder usar cscope se necesita construir un fichero índice. Puede hacerse con el comando
cscope -b -R -k
En el directorio raíz de la aplicación. -b para construir el índice, -R para buscar
recusrivamente a través del árbol de directorios y -k para indicar que estamos
usando el kernel para navegar, esto asegura que se incluye los ficheros de forma
correcta al generar el índice. Darse cuenta que el índice debería construirse a partir
de un árbol limpio y recién descomprimido, así que es recomendable guardar una
copia del fichero .config y ejecutar un ’make mrproper’ en el directorio raíz del
código fuente.
Para empezar a trabajar con una sesión cscope, usar el comando
cscope -d
con lo que se consigue entrar en un menú parecido a este:
Cscope version 15.3
Press the ? key for help
Find this C symbol:
Find this global definition:
Find functions called by this function:
70
5 EL SISTEMA OPERATIVO LINUX
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 búsquedas, mientras
que la torre de abajo se usa para insertar comandos; Por ejemplo, suponiendo que
se quiere encontrar la definición de la estructura de datos _system_type. Usando
las teclas con las flechas se mueve el cursor para encontrar esta definición 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 seción apropiada del fichero en
cuestión.
Por ejemplo queremos encontrar la definición de super_block. Siguiendo los
pasos comentados antes veríamos la siguiente salida por pantalla:
Global definition: super_block
File
Line
0 vxfs_extern.h 44 struct super_block;
1 super.c
265 int (*test)(struct super_block *,
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 EL SISTEMA OPERATIVO LINUX
5.3 Herramientas
Change this text string:
Find this egrep pattern:
Find this file:
Find files #including this file:
Esta vez, cscope ha encontrado más de una definición posible. Así que se verá la
lista de cada una de las definiciones en su contexto y apretando uno de los números
que se mestran en la lista, o bien usando la tecla Tabulador para moverse de uno
a otro por la pantalla y con las teclas de dirección seleccionar una definición. Al
salir del editor se vuelve al cscope. Apretando otra vez el Tabulador podemos
retornar al área de comandos. Para salir del cscope apretar un simple Ctrl+d.
La documentación para el cscope está disponible en la red en la página del
cscope: http://cscope.sourceforge.net/
5.3.4. Manipuladores
diff
Diff es un programa que se usa para comparar dos ficheros y luego listar las
diferencias entre ellos. Cuando se usa en modo unified, con la opción -u, para
comparar dos ficheros, el original y el modificado, y así se crean los parches o
patchs:
diff -u linux-2.4.19/drivers/char/keyboard.c linux/drivers/char/keyboard.c >
Donde el directorio linux-2.4.19 está el original, y en el árbol del directorio linux
tenemos todos los cambios que se van haciendo. La idea de distribuir solo ideas y
modificaciones es mucho más inteligente y a la vez eficiente que distribuir ficheros
enteros o árboles de directorios con código fuente.
El proceso anterior se puede usar cuando tenemos solo un fichero modificado,
pero que pasa si tenemos muchos ficheros modificados y queremos producir un
patch. Pues es lo mismo pero ahora hay que cambiar las opcciones del programa
diff:
diff -urN linux-2.4.19 linux > my_hefty_kernel_patch
72
5 EL SISTEMA OPERATIVO LINUX
5.3 Herramientas
Darse cuenta que generalmente se usa el direcotrio raíz para generar patches por
ejemplo si se tiene el kernel descomprimido en /usr/src se tiene el directorio 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 distribución del kernel de
linux la Linux Kernel Mailing List, hay que asergurarse de seguir las instrucciones
correctamente y exactamente como dicen en el FAQ que puede encontrarse en
http://www.tux.org/lkml/.
patch
patch es un programa que se usa para aplicar parches, producidas por el programa diff, a un fichero o a un directorio de código fuente. es necesario entrar por
ejemplo, si se va a pasar del kernel linux-2.4.18 al linux-2.4.19 habría que hacer
los siguiente:
cd linux-2.4.18
patch -p1 patch-2.4.19
Esto produce un upgrade o mejora del directorio 2.4.18 al 2.4.19. La opción -p1
se usa en el directorio raíz de todos los nombres de ficheros que indica en el patch.
Se podría aplicar el parche desde un directorio más abajo, pero eso significa que
se debería tner todos los directorios nombrados de la misma manera que en el
ordenador donde se creó el patch o parche. Algunos parches se distribuyen en
ficheros comprimidos para ahorrar ancho de banda. Se puede ahorrar fichero de
descompresión del patch si se aplica de la siguiente manera:
bzip2 -dc /usr/src/patch-2.4.19.bz2 | patch -p1
Reemplazar bzip2 por tar o gzip según se creó el fichero.
Una script que está incluido en el directorio del código fuente del kernel que es
muy útil, se usa para generer de manera semi automática el proceso de upgrade del
directorio aplicando sucesivos parches: linux/scripts/patch-kernel. Leer el script
para ver qué es lo que hace y cómo se usa, las instrucciones están puestas entre
los comentarios al principio del fichero.
En el caso de querer quitar un parche que se aplicado con anterioridad es
necesario escribir la siguiente orden, con la orden de -R (remove):
73
5 EL SISTEMA OPERATIVO LINUX
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 debugación. Siempre se inenta mantener de todos los cambios
hechos en el proceso suando alguna forma de control de revisiones, así si hubiera
un cambio erroneo se podría volver al rebés facilmente. Una forma muy básica
de revisión de control del sistema puede hacerse simplemente haciendo una copia
backup de un fichero antes de hacer cambios importantes, pero esta aproximación
tiende a ser muy ineficiente rápidamente, sobre todo en el caso de estar 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 pequeño de CVS. CVS en cambio es genial para proyectos
grandes con muchos contribuidores y programadores, pero es demasiado trabajo
para proyectos pequeños donde solo hay un programador o unos pocos. Por eso
una de las ventajas que tiene RCS es la simplicidad.
Primero se debe crear un directorio llamado RCS en el mismo directorio que
donde están los ficheros de código fuente.
mkdir RCS
Luego introducir o como dicen los ingleses hacer el ’check in’ del fichero, por
ejemplo para el fichero ’some-file.c’ hacer:
ci -u some-file.c
Tras ello se pedirá insertar una breve descripción. Por defecto, RCS borra el fichero de trabajo al hacer el check in, así que es interesante poner la opción -u para
comprobar automáticamente si existe un fichero igual, y no borrarlo automáticamente. Es recomendable hacerlo así con todos los ficheros que se introduzcan.
Hacer algunos cambios en uno de los ficheros que se hayan introducido. Luego
intentar hacer el check in del fichero en cuestión, se mostrará un lista de cambios
y el número de versión se verá incrementado.
74
5 EL SISTEMA OPERATIVO LINUX
5.3 Herramientas
Suponer que se ha hecho unos cambios erroneos y se quiere volver hacia atrás,
y revertir a una versión buena que sabíamos que funcionaba correctamente, por
ejemplo la versión 1.4, entonces hacer el check out del fichero usando este comando:
co -l -r1.4 some-file.c
La opción -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 más información sobre RCS, ver las
páginas man de: rcs, ci, co, rcsintro, rcsdiff, rcsclean, rcsmerge, rlog, rcsfile y el
ident. La página web donde se puede bajar el software de forma gratuita y donde
se encuentran el tutorial está en http://www.gnu.org/software/rcs/rcs.html.
CVS
Mientras que el RCS es bueno para proyectos donde se usa un pequeño número de ficheros, pero se convierte inútil para ficheros más grandes donde hay un
gran número de contribuidores donde haya más de un desarrollador. CVS es particularmente la mejor idea, además es el programa más usado en la comunidad de
Internet, donde casi todos los proyectos, incluido el del kernel, se llevan usando
CVS.
CVS tiene muchos comandos que están incluidos en el propio cvs, estos se
llaman sub-comandos del cvs. Ambos a los comandos cvs y a los subcomandos se
les puede pasar opciones, pero la posición dentro de la línea de comandos debería
ser así:
$ cvs [cvs options] sub-command [sub-command options]
Aquí paso una breve lista de los subcomandos disponibles:
add: este comando añade un nuevo fichero al control de código. Es necesario
hacer un check in del fichero suando cvs ci después de este comando ara que tenga
efecto el cambio.
75
5 EL SISTEMA OPERATIVO LINUX
5.3 Herramientas
ci o bien commit: ci que significa check in tiene la misma función que commit,
estos comandos harán el check in de los cambios que se hayan hecho a la
copia local de un fichero en cuestión. Después de introducir este comando,
cualquier update o check out del fichero que está en el repostorio se verán
los cambios que has hecho con el ci. Se puede especificar con la opción -m
’mensaje’ la opción de proveer un mensaje describiendo el cambio. Cuando
se introducen (check in) los cambios y la copia local de los ficheros no son
actualizados, cvs mostrará un mensaje informándote de esto mismo. En este
caso, hay que hacer un update de los ficheros y entonces hacer un check in
con los cambios. Para comprobar los cambios in todos los ficheros modificados en el directorio de trabajo, hay que ejecutar el siguiente comando
desde desde la raíz del directorio de trabajo:
cvs -q ci -m ’mensaje bla bla bla’
co o bien checkout: Este comando hace una copia local de todos los ficheros en
un módulo que están en el servidor cvs. Primero, creará un subdirectorio
con el mismo nombre que el módulo, entonces copiará los ficheros al 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 información sobre el repositorio cvs. Por defecto,
este comando solo muestra información que te pertenece a ti. Si se usa la
opción -a (all) mostrará la información de todos los usuarios. La siguiente
línea es útil para ver los cambios históricos.
cvs history -a -o # Show checked out files$ cvs history -a -T
# Show all tags$ cvs history -a -e # Show all information
import: Este comando podrá un proyecto existente dentro del repositorio.
76
5 EL SISTEMA OPERATIVO LINUX
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 código. Si tras hacer esto
se hace un check out de un módulo, no se encontrará copia de este fichero.
Aún así, si hacen un check out de una versión anterior del módulo, se podrá
recuperar esa versión anterior de ese fichero.
tag: Para hacerles un tag a los ficheros en el directorio de trabajo actual, se debe
ejecutar la siguiente línea de comandos
cvs -q tag NombreDelTag
update: Este comando hará un update de la copia local de los ficheros de un
módulo. Para cualqier fichero que se le haga el update, se printa el nombre
prededido con una ’U’. Así se permite imprimir los nombres de los ficheros
que se han modificado. Por ejemplo, aquellos que son diferente de la copia
del repositorio y entonces preceden con una ’M’. Para listar los documentos que se han modificado dentro del directorio de trabajo actual, se debe
ejecutar la siguiente orden desde la raíz del directorio de trabajo:
cvs -q update
El repositorio de cvs se debe especificar usando la opción -d en el comando cvs o
también se puede hacer con la variable de entorno CVSROOT. Por ejemplo de la
primera forma sería:
cvs -d pathName login
Y de la segunda manera se escribiría:
export CVSROOT=pathName$ cvs login
77
5 EL SISTEMA OPERATIVO LINUX
5.3 Herramientas
En el caso que el repositorio estuviera en el mismo sistema, la opción es muy
simple y solo habría que escribir el path al repositorio, por ejemplo /usr/src/cvs, y
se haría de la siguiente manera:
export CVSROOT=/usr/local/cvs
Pero en el caso que el repositorio esté en otro sistema, que es lo más normal, y
lo que sucede con el kernel de Linux, en la especificación del repositorio debe
incluirse el método de acceso, el nombre del usuario y el nombre del servidor
donde está localizado el repositorio. Cada uno de estos items, el método de acceso,
el nombre del usuario y el nombre del servidor, y el path del repositorio en el
servidor, deben estar separados por dos puntos. Y entre el nombre de usuario y el
del servidor debe ir una arroba ’@’. Se hace de la siguiente manera:
export CVSROOT=:accessMethod:userName@serverName:pathName
Por ejemplo para Linux Top of Tree, versión 2.4, debemos usar el siguiente comando. Este respositorio es una copia (mirror) que se actualiza cada 30 minutos.
export CVSROOT=:pserver:[email protected]:/vger$
cvs loginPassword: cvs$ cd some-directory
# Por ejemplo, /usr/local/src$ cvs -z3 co linux
Y para hacer un update del código fuente hay que usar la siguiente orden:
cd some-directory/linux$ cvs -z3 update -d
Esta es solo una presentación del CVS, que es muy extenso, para más información
dirigirse a la página oficial del proyecto CVS: http://www.cvshome.org/
Y aquí termina la selección de aplicaciones para poder trabajar dentro del
kernel.
78
5 EL SISTEMA OPERATIVO LINUX
5.4 Netfilter en los kernels 2.4
5.4. Netfilter en los kernels 2.4
Como ya comenté un firewall está integrado dentro del sistema operativo. La
cuestión es que a la hora de diseñar el actual sistema de filtrado de paquetes, el
Netfilter, Rusty Russell compaginaba su trabajo con Alan Cox. Los dos se mantenían en contacto para realizar el nuevo sistema que hay en los kernels 2.4. Este
trabajo conjunto hace que el sistema de captura de paquetes comentado antes y
el sistema Netfilter estén muy relacionados. Es por eso que el proyecto se verá
influenciado por este sistema, ya que hay unos puntos concretos por donde se asegura que pasan todos los sk_buffs de entrada. Y es esa razón la que hace que sea
importante entender correctamente como funciona este sistema y luego decidir
donde insertar las funciones que se encargan de capturar los datos guardados en
estructuras sk_buff para hacerles luego el filtrado.
El sistema actual de filtrado de paquetes pone 5 tipos diferentes de hooks o
ganchos:
PRE_ROUTING
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 código de routing, donde se decide a dónde se envía los paquetes, si se destina a otra interfaz o si es para un proceso local. El código
de routing puede eliminar aquellos paquetes que no tengan una ruta disponible. Si
se destina para el ordenador en sí, se le llama a la función del netfilter y se marca
como que ha entrado por el hook NF_IP_LOCAL_IN. Si se destina a pasar a otra
interfaz entonces entrará dentro del netfilter y se le marcará como que ha entrado
79
5 EL SISTEMA OPERATIVO LINUX
5.4 Netfilter en los kernels 2.4
por el tercer hook, el NF_IP_FORWARD. Entonces el hook del netfilter pasa por
el cuarto hook, el NF_IP_POST_ROUTING antes de pasarse a la tarjeta de red
donde se enviará al cable. Existe todavía un quinto hook, el NF_IP_LOCAL_OUT
los datos pasan por aquí si se han creado localmente.
Esta es la forma que tiene el actual sistema para capturar los paquetes, pero ¿es
el mismo sistema que quiero utilizar yo? pues no, es lógico que este influenciado,
todos los firewalls trabajan de una forma parecida, pero tiene inconvenientes y
también sus ventajas.
5.4.1. Ventajas
La principal característica es que tiene 5 hooks, cuando antes en los kernels
2.2 solo tenía 3 hooks. Bueno entonces ellos (Rusty Russell principalmente) habrán creido que es mejor. Y es que de esta forma se controla perfectamente a un
paquete. En los firewalls anteriores se filtraba al paquete tanto cuando llega, como cuando pasa por el forward y cuando salía. Ahora además se controla cuando
los paquetes van dirigidos a algún programa del sistema o cuando lo ha generado
alguien del sistema. Eso añade control y hace que se puede poner políticas de 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 también como un problema. Y es una de las
razones por las que me propuse hacer este firewall.
5.4.2. Inconvenientes
El principal inconveniente es que un paquete pasa por muchos hooks, pasa
muchas veces por todas las políticas del firewall y cada vez que se pasa por un
hook se comprueba para cada una de las políticas y las sesiones abiertas si cumple
o no, si se elimina el paquete o no. La intención es tener un control completo de
los paquetes que pasan por el sistema, y esa es la mayor ventaja, pero se pierde en
tiempo, que un paquete pase por tres filtros o incluso si se inserta un firewall proxy
puede llegar a pasar por cuatro filtros tiene un coste en tiempo. Rusty Russell
insertó la idea de hacer una cache para los paquetes, y dentro de la estructura
sk_buff se ha añadido nuevos datos, como puede leerse en include/linux/skbuff.h:
80
5 EL SISTEMA OPERATIVO LINUX
5.4 Netfilter en los kernels 2.4
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 añade una cache para cada paquete, y así, cuando se pasa por un filtro se
marca que cosas se ha hecho en la cache y luego en los otros filtros no vuelve a
hacer los mismos chequeos. Es contradictorio poner tantos filtros para luego tener
que montar un sistema por encima para saltárselos.
Otro inconveniente de este sistema es que es una topología está pensada para
hacer funciones de firewall y a la vez de servidor. Hay tres encargados de mirar el
filtrado de paquetes para los que llegan, para los que pasan por el router y para los
que se van. Y hay los otros dos hooks que nos sirve para controlar si hay troyanos.
La idea está bien, pero un firewall tiene que ser solo eso, un firewall, no se le
debe poner ningún servicio en él, tiene que ser unordenador bastión y el único
servicio que debe tener es el de SSH para hacer conexiones remotamente y poder
administrarlo. Sin servicios en el firewall, no es necesario montar los dos hooks
restantes para controlar los troyanos. Por definición un firewall tiene que ser un
equipo rápido y con pocos o ningún servicio disponible.
81
5 EL SISTEMA OPERATIVO LINUX
5.5 Viaje de un paquete
5.5. Viaje de un paquete
5.5.1. Introducción
Tras hacer las respectivas pruebas, tras compilar el kernel, insertadar pequeños programas dentro del kernel, después de debugar para ver como funciona el
proceso de debugar y de tener los esquemas de como funcionará el firewall. Es la
hora de averiguar donde se debe poner el filtrado de paquetes dentro del kernel.
La documentación [WS1] habla de unos ficheros ip_input.c donde trata los
paquetes IP de entrada, un ip_forward.c donde se hace el forward de una interfaz
de entrada a otra de salida y del fichero ip_output.c que se encarga de tratar todos
los paquetes que salen del ordenador. En dicha documentación [WS1] aparece
como se trata la información y los datos. Pero en el libro de Stevens se trata un
sistema Unix, que teóricamente debe ser igual en un sistema Linux.
Se trata de averiguar como viaja un paquete cualquiera por el sistema operativo, y allá donde se crea que es mejor insertar el firewall. Y la idea es coger el
paquete y pasarlo compararlo con las políticas de seguridad. Que es un 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 dirección
particular, que siempre es diferente para cada una de las tarjetas de red que hay
en el mundo. Esta dirección es la MAC. La tarjeta está siempre escuchando los
paquetes que pasan por su interfaz, cuando ve un paquete cuya dirección MAC
corresponde a la suya propia, o bien un paquete con una dirección de broadcast
(FF:FF:FF:FF:FF:FF para las Ethernet) entonces empieza a leer los datos y los
carga en su memoria.
Cuando termina de leer todo el paquete, la tarjeta genera una petición de interrupción. La rutina que se encarga de servir la interrupción y que trata la petición
es parte del driver de la tarjeta, que es parte del sistema operativo en sí, el cual
82
5 EL SISTEMA OPERATIVO LINUX
5.5 Viaje de un paquete
ejecuta con las interrupciones deshabilitadas las siguientes operaciones:
1. Crear una nueva estructura sk_buff, dedinida en el fichero include/linux/skbuff.h,
la cual representa la visión que tiene el sistema operativo de un paquete.
2. Vuelca los datos de información del buffer de la tarjeta de red en la nueva
estructura creada sk_buff, algunos drivers usando la DMA.
3. Llama a la función netif_rx(), que es la función que se encarga de recibir los
datos de la tarjeta de red.
4. Al terminar la función netif_rx(), el sistema operativo vuelve a activar las
interrupciones y termina el servicio de interrupción.
La función netif_rx() prepara el kernel para el siguiente paso de la recepción. Pone la información del sk_buff dentro de lo cola de paquetes de entrada para que
la CPU pueda tratarlo y marca la NET_RX softirq (que es una interrupción por
software que luego hablaré de ellas) para que pueda ser tratada, y esto se hace
mediante la llamada a la función __cpu_raise_softirq( ), definida dentro del 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 añadir softirqs) lo que hace que la recepción de paquetes sea concurrente
en máquinas Multiprocesador.
Si se desea ver un driver de una Ethernet en acción, se puede mirar algún driver
sencillo como por ejemplo en el fichero drivers/net/8390.c. La rutina de servico
que trata la interrupción se llama ei_interrupt( ), y llama a la función ei_recive( ),
la cual hace lo siguiente:
1. Crea una nueva estructura sk_buff mediante la función dev_alloc_skb( ). Y
vuelca los datos con la función skb_put( skb, pkt_len).
2. Lee el paquete del buffer de la tarjeta con la función ei_block_input( ) y
señaliza el protocolo con skb->protocol= eth_type_trans(skb,dev)
3. Llama a la función netif_rx( ) comentada antes.
83
5 EL SISTEMA OPERATIVO LINUX
5.5 Viaje de un paquete
4. Y vuelca todos los datos, según el contador rx_pkt_count vuelca diez paquetes consecutivamente.
Se puede hechar una ojeada a otros ejemplos mucho más complejos como pueden
ser los driver de cualquier tarjeta 3COM, por ejemplo los ficheros 3c59x.c, donde
usa transferencia por DMA para mover el paquete desde la memoria de la tarjeta
al sk_buff.
5.5.3. Proceso de red
La función netif_rx( ) es muy importante, se encarga de recibir los paquetes
de una tarjeta de red mediante el driver y en cola para que pueda ser tratado por
niveles superiores de la capa OSI dentro del sistema operativo. Actúa de puente
para todos los paquetes que se recogen entre los diferentes drivers de todas las
tarjetas de red, y haciendo de entrada a los protocolos.
Al estar esta función en un contexto de interrupción tiene que ser rápida y
corta. No puede hacer ningún chequeo del tamaño o cualquier otra compleja función, ya que el sistema está potencialmente perdiendo paquetes mientras se está ejecutando el netif_rx( ). Así lo que hace la función 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 congestión:
NET_RX_SUCCESS (sin congestión), NET_RX_CN_LOW, NET_RX_CN_MOD,
NET_RX_CN_HIGH (baja, moderada y alta congestión, respectivamente) o bien
NET_RX_DROP (el packet se pierde debido a una congestión crítica). Es un 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 función
__cpu_raise_softirq( ) se llama. La última función hace que se ejecute el softirq.
Cuando la función netif_rx( ) termina, retornando un valor que indica la congestión actual al driver. En este punto, el contexto de la interrupción ha terminado
y el paquete está listo para ser enviado a los protocolos superiores. Este proceso ha
cambiado completamente en la versión del kernel 2.4 donde se basan los softirqs,
84
5 EL SISTEMA OPERATIVO LINUX
5.5 Viaje de un paquete
antes cuando los kernels eran de versión 2.2 se basaba en la mitad inferior (donde
no se podía trabajar en paralelo)
5.5.4. Softirq para NET_RX
Tras recibir el paquete se inserta en una cola para ser procesado posteriormente. Este proceso se hace llamando a la función net_rx_action( ). Esta función
desempila el primer paquete (Sk_buff) de la cola actual de la CPU y ejectua a través de dos listas de funciones para su proceso según el protocolo. Estas listas se
llaman ptype_all y ptype_base y contienen respectivamente, los handlers del protocolo para para paquetes genéricos y para paquetes de tipo específico. 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 función dev_add_pack( ) dentro del fichero net/core/dev.c,
el cual añade una estructura de tipo del paquete (include/linux/netdevice.h) conteniendo un puntero a la función será llamada cuando un paquete de ese tipo se
reciba. Tras el registro, cada estructura de un handler se pone o bien en la lista
ptype_all, para el tipo ETH_P_ALL, o bien en la lista ptype_base para otros tipos
ETH_P_*.
Así lo que hace la softirq par la NET_RX es llamar a la secuencia de funciones
registradas en las dos listas para tratar al paquete que es de un tipo de protocolo
específico. Si la cola contiene más de un paquete, la función net_rx_action( )
hace un bucle para poder tratar el máximo número de paquetes que hayan sido
procesados. Cuando la función net_rx_action( ) termina y deja una cola no vacía,
la NET_RX_SOFTIRQ se activa otra vez para permitir el proceso de los paquetes
para más tarde.
5.5.5. Tratar los paquetes IP
Este proyecto solo se encarga de paquetes IP versión 4, en el caso de que se
hiciese para otro protocolo, como por ejemplo IPv6 se debería buscar otro tipo
de handler. Para IPv4 la función se llama ip_rcv( ) y se encuentra en el fichero net/ipv4/ip_input.c, este es apuntada a las listas antes comentadas cuando se
arranca el sistema, mediante la función ip_init( ), dentro de net/ipv4/ip_output.c.
85
5 EL SISTEMA OPERATIVO LINUX
5.5 Viaje de un paquete
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 función se
encarga de hacer los chequeos iniciales al paquete IP, los cuales tratan de verificar
la integridad del mismo: IP checksum y tamaño de la cabecera. Si el paquete
parece correcto, se llama a la función ip_rcv_finish( ). Es aquí mismo donde se
introducirá la función de cualquier firewall. Hay que asegurarse de no compilar el
Netfilter cuando se compile el kernel con mi programa, sino se cae en el error de
tener dos filtrados de paquetes.
La función ip_rcv_finish( ), que se encuentra dentro de ip_input.c, se encarga
de hacer el rutado de IP. Se encarga de comprobar si el paquete debe ser retransmitido a otra máquina o si el destino es el host actual. Es aquí donde habría que
incluir los procesos de routing. Si se envía a otra máquina se envía a la interfaz
correspondiente, y si el destino final es la propia máquina se envía a los protocolos
superiores. Todo esto se hace en la función ip_route_input( ), llamada al principio
de ip_rcv_finish( ), la cual determina cual es el siguiente paso.
Si el destino es la propia máquina, entonces se llama a la función ip_locl_deliver( ).
Esta función se encarga de reensamblar los diferentes paquetes IP, en el caso que el
datagrama esté fragmentado, y entonces llama a la función ip_local_deliver_finish( ).
86
5 EL SISTEMA OPERATIVO LINUX
5.5 Viaje de un paquete
Si el destino es otra máquina el proceso entonces se envía a la función net/ipv4/ip_output.c
que será donde se pase el chequeo de todos los paquetes que salgan del ordenador.
Para diferenciar las dos llamadas a cada una de las funciones se le pasará si es de
entrada o de salida. Dependiendo de donde se llame, si es desde ip_input.c se le
marcará al paquete como de entrada, que se llama desde ip_output.c es de salida.
Se puede profundizar más dentro de los protocolos del siguiente nivel (TCP,
UDP e ICMP) pero el proyecto no trata los paquetes a tan alto nivel. Como se
explicó en las secciones de teoría de filtrado de paquetes.
87
6 ESTUDIO DEL DISEÑO ( UML)
6. Estudio del Diseño ( UML)
6.1. Introducción al UML
6.1.1. Historia
El "Unified Modelling Languaje" (UML) provee a los analistas y arquitectos
de sistemas que trabajan en el diseño y análisis de objetos de un lenguaje consistente para especificar, visualizar, construir y documentar los artefactos de un
sistema de software, así también es útil para hacer modelos de negocios.
Esta especificación es la evolución del las tres anteriores tecnologías orientadas a objetos lideres (Booch, OMT y OOSE). El UML es la unión de estos lenguajes de modelos y aún mas ya que incluye expresiones adicionales para manejar
problemas de modelaje que los métodos anteriores no cubrían plenamente.
El desarrollo de el UML empezó en octubre de 1994 cuando Grady Booch y
Jim Rumbaugh de Rational Software Corporation iniciaron su trabajo para unificar los métodos de Booch y OMT. Debido a que los métodos Booch y OMT
ya habían madurado independientemente y eran reconocidos como métodos líderes en el desarrollo orientado a objetos, Booch y Rumbaugh unieron fuerzas para
forjar una unificación completa de los dos métodos. Una versión preliminar 0.8
de el "método unificado" fue dad a conocer en octubre de 1995. Poco después,
Ivar Jacobson y su compañía "Objectory" se unieron a Rational y a su trabajo de
unificación, uniendo el método OOSE (Object Oriented software engineering). El
Nombre de Objectory es ahora dado mayormente para describir a el Proceso que
acompaña al UML el "Rational unified process".
88
6 ESTUDIO DEL DISEÑO ( UML)
6.1 Introducción al UML
6.1.2. Objetivos
Los objetivos de la unificación fueron: el mantenerlo simple, el quitar elementos de los lenguajes de Booch, OMT y OOSE que no funcionaran en la práctica, el
añadir elementos de otros métodos que fueran más efectivos y el inventar nuevas
construcciones solamente cuando la solución existente no estuviera disponible.
UML es un lenguaje de modelado de propósito general que pueden usar todos
los modeladores. No tiene propietario y está basado en el común acuerdo de gran
parte de la comunidad informática. UML no pretende ser un método de desarrollo
completo. No incluye un proceso de desarrollo paso a paso. UML incluye todos
los conceptos que se consideran necesarios para utilizar un proceso moderno iterativo, basado en construir una sólida arquitectura para resolver requisitos dirigidos
por casos de uso. Ser tan simple como sea posible pero manteniendo la capacidad
de modelar toda la gama de sistemas que se necesita construir. UML necesita ser
lo suficientemente expresivo para manejar todos los conceptos que se originan en
un sistema moderno, tales como la concurrencia y distribución, así como también
los mecanismos de la ingeniería de software, como son la encapsulación y componentes. Debe ser un lenguaje universal, como cualquier lenguaje de propósito
general, pretende ser un estándar mundial.
Varios nuevos conceptos existen en UML, incluyendo:
1. Mecanismos de extensión (estereotipos, valores marcados y restricciones),
2. Procesos y ramas de procesamiento
3. Distribución y concurrencia
4. Patrones y colaboración
5. Diagramas de actividad
6. Refinamiento (para manejar las relaciones entre los niveles de abstracción)
7. Interfaces y componentes
8. Un lenguaje para restricciones
89
6 ESTUDIO DEL DISEÑO ( UML)
6.1 Introducción al UML
Aunque el UML define un leguaje preciso, no es una barrera para el desarrollo
futuro en los conceptos de modelaje. Se han incorporado muchas técnicas líderes,
pero se espera que técnicas adicionales influyan las versiones futuras del UML.
Muchas técnicas avanzadas pueden ser definidas usando el UML como base. El
UML puede ser extendido sin redefinir su núcleo.
6.1.3. Participantes en UML 1.0
La lista de participantes incluye grandes empresas de informática, con lo que
se consigue no sólo que haya más intercambio de ideas sino que se cumpla en
un defacto para todo el mundo. Lástima que no esté incluida ninguna empresa de
Linux.
1. Rational Software (Grady Booch, Jim Rumbaugh y Ivar Jacobson)
2. Digital Equipment
3. Hewlett-Packard
4. i-Logix (David Harel)
5. IBM
6. ICON Computing (Desmond D’Souza)
7. Intellicorp and James Martin & co. (James Odell)
8. MCI Systemhouse
9. Microsoft
10. ObjecTime
11. Oracle Corporation.
12. Platinium Technology
13. Sterling Software
14. Taskon
90
6 ESTUDIO DEL DISEÑO ( UML)
6.1 Introducción al UML
15. Texas Instruments
16. Unisys
6.1.4. Áreas conceptuales
Los conceptos y modelos de UML pueden agruparse en las siguientes áreas
conceptuales:
Estructura estática: Cualquier modelo preciso debe primero definir su universo, esto es, los conceptos clave de la aplicación, sus propiedades internas, y
las relaciones entre cada una de ellas. Este conjunto de construcciones es la
estructura estática. Los conceptos de la aplicación son modelados como clases, cada una de las cuales describe un conjunto de objetos que almacenan
información y se comunican para implementar un comportamiento. La información que almacena es modelada como atributos; La estructura estática
se expresa con diagramas de clases y puede usarse para generar la mayoría
de las declaraciones de estructuras de datos en un programa.
Comportamiento dinámico: Hay dos formas de modelar el comportamiento,
una es la historia de la vida de un objeto y la forma como interactúa con
el resto del mundo y la otra es por los patrones de comunicación de un conjunto de objetos conectados, es decir la forma en que interactúan entre sí.
La visión de un objeto aislado es una maquina de estados, muestra la forma
en que el objeto responde a los eventos en función de su estado actual. La
visión de la interacción de los objetos se representa con los enlaces entre
objetos junto con el flujo de mensajes y los enlaces entre ellos. Este punto
de vista unifica la estructura de los datos, el control de flujo y el flujo de
datos.
Construcciones de implementación: Los modelos UML tienen significado para
el análisis lógico y para la implementación física. Un componente es una
parte física reemplazable de un sistema y es capaz de responder a las peticiones descritas por un conjunto de interfaces. Un nodo es un recurso computacional que define una localización durante la ejecución de un sistema.
Puede contener componentes y objetos.
91
6 ESTUDIO DEL DISEÑO ( UML)
6.2 Diagramas
Organización del modelo: La información del modelo debe ser dividida en 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 tamaño modesto. Los paquetes son
unidades organizativas, jerárquicas y de propósito general de los modelos de
UML. Pueden usarse para almacenamiento, control de acceso, gestión de la
configuración y construcción de bibliotecas que contengan fragmentos de
código reutilizable.
Mecanismos de extensión: UML tiene una limitada capacidad de extensión pero
que es suficiente para la mayoría de las extensiones que requiere el ’dia a
dia’ sin la necesidad de un cambio en el lenguaje básico. Un estereotipo es
una nueva clase de elemento de modelado con la misma estructura que un
elemento existente pero con restricciones adicionales.
6.2. Diagramas
Un Modelo captura una vista de un sistema del mundo real. Es una abstracción de dicho sistema, considerando un cierto propósito. Así, el modelo describe
completamente aquellos aspectos del sistema que son relevantes al propósito del
modelo, y a un apropiado nivel de detalle.
Un proceso de desarrollo de software debe ofrecer un conjunto de modelos
que permitan expresar el producto desde cada una de las perspectivas de interés.
El código fuente del sistema es el modelo más detallado del sistema (y además es
ejecutable). Sin embargo, se requieren otros modelos. Cada modelo es completo
desde su punto de vista del sistema, sin embargo, existen relaciones de trazabilidad
entre los diferentes modelos.
Un Diagrama es una representación gráfica de una colección de elementos de
modelado, a menudo dibujada como un grafo conexo de arcos (relaciones) y vértices (otros elementos del modelo). Un diagrama no es un elemento semántico, un
diagrama muestra representaciones de elementos semánticos del modelo, pero su
significado no se ve afectado por la forma en que son representados. Un diagrama
está contenido dentro de un paquete.
92
6 ESTUDIO DEL DISEÑO ( UML)
6.2 Diagramas
La mayoría de los diagramas de UML y algunos símbolos complejos son grafos que contienen formas conectadas por rutas. La infomación está sobre todo
en la topología, no en el tamaño o la colocación de los símbolos (hay algunas
excepciones como el diagrma de secuencia con un eje métrico de tiempo). Hay
tres clases importantes de relaciones visuales: conexión (generalmente de líneas
a formas de dos dimensiones), contención (de símbolos por formas cerradas de
dos dimensiones), y adhesión visual (un símbolo que está "cerca" de otro en un
diagrama). Estas relaciones geométricas se reasignan a conexiones entre nodos en
un gráfico en la forma analizada de la notación.
La notación de UML está pensada para ser dibujada en superficies bidimensionales. Algunas formas bidimensionales son proyecciones de formas tridimensionales tales como cubos, pero todavía se representan como íconos en una superficie
bidimensional.
Hay cuatro clases de construcciones gráficas que se usan en la notación de
UML: íconos, símbolos bidimensionales, rutas y cadenas.
Un ícono es una figura gráfica con un tamaño y forma fijos. No se amplía para
contener a su contenido. Los iconos pueden aparecer dentro de símbolos de área,
como terminadores en las rutas o como símbolos independientes que puedan o no
conectar con las rutas.
Los símbolos de dos dimensiones tienen altura y anchura variables, y pueden
ampliarse para permitir otras cosas tales como listas de cadenas o de otros símbolos. Muchos de ellos están divididos en compartimientos similares o de tipos
diferentes. Las rutas se conectan con los símbolos, el arrastrar o suprimir uno de
ellos afecta a su contenido y las rutas conectadas.
Una ruta es una secuencia de segmentos de recta o de curva que se unen en sus
puntos finales. Conceptualmente una ruta es una sola entidad topológica, aunque
sus segmentos se pueden manipular gráficamente. un segemento no debería existir
separado de su ruta. Las rutas siempre van conectdas en ambos extremos.
Las cadenas presentan varias clases de información en una forma "no analizada", UML asume que cada uso de una cadena en la notación tiene una sintaxis
por la cual pueda ser analizada la información del modelo subyancente. Las cadenas pueden existir como el contenido de un compartimiento, como elementos en
las listas, como etiquetas unidas a los símbolos o a las rutas, o como elementos
93
6 ESTUDIO DEL DISEÑO ( UML)
6.2 Diagramas
independientes en un diagrama.
6.2.1. Diagramas estructurales
Se usan para visualizar, especificar, construir y documentar aspectos estáticos
de un sistema. Que son el esqueleto e incluyen la existencia y ubicación de clases,
interfaces, colaboraciones, componentes y nodos.
Diagrama de clases: Representa las clases, interfaces y colaboraciones y 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 estática de una arquitectura. Se relacionan con los diagramas de componentes porque un nodo incluye normalmente uno o más componentes.
6.2.2. Diagramas de comportamiento
Se usa para los aspectos dinámicos de un sistema. Que son las partes mutables como el flujo de mensajes a lo largo del tiempo el movimiento físico de
componentes en una red.
Diagramas de casos de uso: representas casos de uso, actores y sus relaciones.
Diagramas de secuencia: Junto con los diagramas de colaboración representan
a los diagramas de interacción, que resalta la ordenación temporal de los
mensajes. Representa el conjunto de objetos y los mensajes enviados y recibidos entre ellos.
94
6 ESTUDIO DEL DISEÑO ( UML)
6.3 Diagramas de Objetos
Diagramas de colaboración: Son diagramas de interacción que resalta la organización estructural de los objetos que envían y reciben sus mensajes. Representan los objetos enlazados unos con otros con sus mensajes enviados
y recibidos.
Diagramas de estado: Son máquinas de estados, con sus transiciones, eventos y
actividades. Ayudan a modelar el comportamiento.
Diagramas de actividades: Muestra el flujo de actividades. Muestran el flujo secuencial de actividades y los objetos que actúan y sobre los que actúa.
6.3. Diagramas de Objetos
Objeto es una entidad discreta con límites bien definidos y con identidad, es
una unidad atómica que encapsula estado y comportamiento. La encapsulación en
un objeto permite una alta cohesión y un bajo acoplamiento. el Objeto es reconocido también como una instancia de la clase a la cual pertenece.
La encapsulación presenta tres ventajas básicas:
1. Se protegen los datos de accesos indebidos
2. El acoplamiento entre las clases se disminuye
3. Favorece la modularidad y el mantenimiento
Un objeto se puede ver desde dos perspectivas relacionadas: como una entidad de
un determinado instante de tiempo que posee un valor específico (Un objeto puede
caracterizar una entidad física -coche-) y como un poseedor de identidad que tiene
distintos valores a lo largo del tiempo (abstracta -ecuación matemática-).
Cada objeto posee su propia identidad exclusiva y se puede hacer referencia
a él mediante una denominación exclusiva que permite accederle. El Modelado
de Objetos permite representar el ciclo de vida de los objetos a través de sus
interacciones. En UML, un objeto se representa por un rectángulo con un nombre
subrayado.
1. Objeto = Identidad + Estado + Comportamiento
95
6 ESTUDIO DEL DISEÑO ( UML)
6.3 Diagramas de Objetos
2. El estado está representado por los valores de los atributos.
3. Un atributo toma un valor en un dominio concreto.
La regla general para la notación de instancias consiste en utilizar el mismo símbolo geométrico que el descriptor. En la instancia se muestran los posibles valores
pero las propiedades compartidas sólo se pone de manifiesto en el descriptor. La
notación canónica es un rectángulo con tres compartimientos. En el primero va
el nombre del objeto, en el segundo sus atributos y en el tercero sus operaciones.
Este último puede ser omitido si así se prefiere.
6.3.1. Oid (Object Identifier)
Cada objeto posee un oid. El oid establece la identidad del objeto y tiene las
siguientes características:
1. Constituye un identificador único y global para cada objeto dentro del sistema.
2. Es determinado en el momento de la creación del objeto.
3. Es independiente de la localización física del objeto, es decir, provee completa independencia de localización.
96
6 ESTUDIO DEL DISEÑO ( UML)
6.3 Diagramas de Objetos
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. Además, un oid no se reutiliza
aunque el objeto deje de existir.
No se tiene ningún control sobre los oids y su manipulación resulta transparente.
Sin embargo, es preciso contar con algún medio para hacer referencia a un objeto
utilizando referencias del dominio (valores de atributos).
6.3.2. Características alrededor de un objeto
Estado: El estado evoluciona con el tiempo. Algunos atributos pueden ser 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 estímulo externo representado como mensaje enviado
desde otro objeto.
Persistencia: La persistencia de los objetos designa la capacidad de un objeto
trascender en el espacio/tiempo, podremos después reconstruirlo, es decir,
cogerlo de memoria secundaria para utilizarlo en la ejecución (materialización del objeto). Los lenguajes OO no proponen soporte adecuado para
la persistencia, la cual debería ser transparente, un objeto existe desde su
creación hasta que se destruya.
Comunicación: Un sistema informático puede verse como un conjunto de objetos autónomos y concurrentes que trabajan de manera coordinada en la
consecución de un fin específico. El comportamiento global se basa pues en
la comunicación entre los objetos que la componen.
Categorías de objetos: Pueden ser clasificado como Activos o Pasivos, como
Cliente o Servidores, o bien como Agentes.
1. Objeto Activo: Posee un hilo de ejecución (thread) propio y puede iniciar
una actividad.
97
6 ESTUDIO DEL DISEÑO ( UML)
6.4 Diagramas de Clases
2. Objeto Pasivo: No puede iniciar una actividad pero puede enviar estímulos
una vez que se le solicita un servicio.
3. Cliente es el objeto que solicita un servicio.
4. Servidor es el objeto que provee el servicio solicitado.
5. Los agentes reúnen las características de clientes y servidores. Son la base del mecanismo de delegación. Introducen indirección: un cliente puede
comunicarse con un servidor que no conoce directamente.
Mensajes: La unidad de comunicación entre objetos se llama mensaje. El mensaje es el soporte de una comunicación que vincula dinámicamente los objetos que fueron separados previamente en el proceso de descomposición.
Adquiere toda su fuerza cuando se asocia al polimorfismo y al enlace dinámico. Un estímulo causará la invocación de una operación, la creación
o destrucción de un objeto o la aparición de una señal. Un mensaje es la
especificación de un estímulo.
6.4. Diagramas de Clases
El Diagrama de Clases es el diagrama principal para el análisis y diseño. Un
diagrama de clases presenta las clases del sistema con sus relaciones estructurales
y de herencia. La definición de clase incluye definiciones para atributos y operaciones. El modelo de casos de uso aporta información para establecer las clases,
objetos, atributos y operaciones.
El mundo real puede ser visto desde abstracciones diferentes (subjetividad).
Mecanismos de abstracción:
1. Clasificación / Instanciación
2. Composición / Descomposición
3. Agrupación / Individualización
4. Especialización / Generalización
98
6 ESTUDIO DEL DISEÑO ( UML)
6.4 Diagramas de Clases
La clasificación es uno de los mecanismos de abstracción más utilizados. La clase
define el ámbito de definición de un conjunto de objetos, y cada objeto pertenece
a una clase, Los objetos se crean por instanciación de las clases.
Cada clase se representa en un rectángulo con tres compartimientos:
nombre de la clase
atributos de la clase
operaciones de la clase
Los atributos de una clase no deberían ser manipulables directamente por el resto
de objetos. Por esta razón se crearon niveles de visibilidad para los elementos que
son:
1. (-) Privado : Es el más fuerte. Esta parte es totalmente invisible (excepto
para clases friends en terminología C++).
2. (#) Los atributos/operaciones protegidos están visibles para las clases friends
y para las clases derivadas de la original.
3. (+) Los atributos/operaciones públicos son visibles a otras clases (cuando
se trata de atributos se está transgrediendo el principio de encapsulación).
6.4.1. Relaciones entre clases
Semánticamente todas las relaciones, incluidas la generalización, la asociación
y la realización son tipos de dependecias. Pero tienen una semántica lo bastante
importante como para justificar que se traten como distintos tipos de relaciones
en UML. Es una decisión de diseño. La expericencia muestra que este enfoque
mantiene un equilibrio entre dar importancia a los tipos importantes de relaciones
y no sobrecargar al modelador con demasiadas opciones. Uno no se equivocará si
modela la generalización, la asociación y la realización en primer lugar y luego
ve las demás relaciones como tipos de dependencias.
Relación de Dependencias: Relación de uso. Declara que un cambio en la especificación del elemento usado puede afectar al elemento que lo usa. Como
puede verse en la imagen, la figura usa posicion
99
6 ESTUDIO DEL DISEÑO ( UML)
6.4 Diagramas de Clases
Relación de Generalización: Relación "hereda_de" o bien "es_un_tipo_de". Entre una superclase o padre y una subclase o hijo. En la imagen tenemos que
Rectángulo y Círculo heredan de Figura.
Relación de Asociación: Relación estructural que especifica conexión entre dos
objetos. Conexión entre dos objetos es una asociación binaria y entre n clases es una n-aria. Dentro de este grupo de relaciones tenemos relación de
asociación por nombre, por rol, por multiplicidad y por agragación.
Nombre: Describe la naturaleza de la asociación. En la figura un empleado
trabaja para otra clase.
Rol: Rol que se juega en una asosciación. Tenemos que una persona vista
desde la fábrica es un empleado.
100
6 ESTUDIO DEL DISEÑO ( UML)
6.5 Diagramas de Caso de Uso
Multiplicidad: Indica "cuantos" objetos en un extremo de la asociación pertenecen. En el ejemplo tenemos que una fábrica tiene un número indefinido
de personas trabajando en ella.
Agregación: Relación "tiene_un". Relacion entre objetos del mismo nivel
pero con una relación todo/parte, uno es "parte" del "todo".
6.5. Diagramas de Caso de Uso
Casos de Uso es una técnica para capturar información de cómo un sistema
o negocio trabaja, o de cómo se desea que trabaje. No pertenece estrictamente al
enfoque orientado a objeto, es una técnica para captura de requisitos.
Los Casos de Uso (Ivar Jacobson) describen bajo la forma de acciones y
reacciones el comportamiento de un sistema desde el p.d.v. del usuario.
Permiten definir los límites del sistema y las relaciones entre el sistema y el
entorno.
101
6 ESTUDIO DEL DISEÑO ( UML)
6.5 Diagramas de Caso de Uso
Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la implementación.
Comparación con respecto a los Diagramas de Flujo de Datos del Enfoque
Estructurado.
Los Casos de Uso cubren la carencia existente en métodos previos (OMT,
Booch) en cuanto a la determinación de requisitos.
Los Casos de Uso particionan el conjunto de necesidades atendiendo a la
categoría de usuarios que participan en el mismo.
Están basados en el lenguaje natural, es decir, es accesible por los usuarios.
6.5.1. Actores
La misma persona física puede interpretar varios papeles como actores distintos, el nombre del actor describe el papel desempeñado.
1. Principales: personas que usan el sistema.
2. Secundarios: personas que mantienen o administran el sistema.
3. Material externo: dispositivos materiales imprescindibles que forman parte
del ámbito de la aplicación y deben ser utilizados.
4. Otros sistemas: sistemas con los que el sistema interactúa.
Los Casos de Uso se determinan observando y precisando, actor por actor, las
secuencias de interacción, los escenarios, desde el punto de vista del usuario. Los
casos de uso intervienen durante todo el ciclo de vida. El proceso de desarrollo
estará dirigido por los casos de uso. Un escenario es una instancia de un caso de
uso.
UML define cuatro tipos de relación en los Diagramas de Casos de Uso. La
Comunicación, la Inclusión, que es una instancia del Caso de Uso origen incluye
también el comportamiento descrito por el Caso de Uso destino. «include» reemplazó al denominado «uses». La Extensión : el Caso de Uso origen extiende el
102
6 ESTUDIO DEL DISEÑO ( UML)
6.6 Diagramas de Estado
comportamiento del Caso de Uso destino. «extend» y la Herencia : el Caso de
Uso origen hereda la especificación del Caso de Uso destino y posiblemente la
modifica y/o amplía.
6.6. Diagramas de Estado
Muestra el conjunto de estados por los cuales pasa un objeto durante su vida
en una aplicación, junto con los cambios que permiten pasar de un estado a otro.
Los Diagramas de Estado representan autómatas de estados finitos, desde el
p.d.v. de los estados y las transiciones. Son útiles sólo para los objetos con un
comportamiento significativo. Cada objeto está en un estado en cierto instante.
El estado está caracterizado parcialmente por los valores algunos de los atributos
del objeto. El estado en el que se encuentra un objeto determina su 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 autómatas jerárquicos que permiten expresar
concurrencia, sincronización y jerarquías de objetos, son grafos dirigidos y deterministas. La transición entre estados es instantánea y se debe a la ocurrencia de
un evento.
6.6.1. Estado
Identifica un periodo de tiempo del objeto (no instantáneo) en el cual el objeto
está esperando alguna operación, tiene cierto estado característico o puede recibir
cierto tipo de estímulos. Se representa mediante un rectángulo con los bordes
redondeados, que puede tener tres compartimientos: uno para el nombre, otro para
el valor característico de los atributos del objeto en ese estado y otro para las
acciones que se realizan al entrar, salir o estar en un estado (entry, exit o do,
respectivamente).
Eventos
Es una ocurrencia que puede causar la transición de un estado a otro de un
objeto. Esta ocurrencia puede ser una de varias cosas:
103
6 ESTUDIO DEL DISEÑO ( UML)
6.6 Diagramas de Estado
Condición que toma el valor de verdadero o falso
Recepción de una señal de otro objeto en el modelo
Recepción de un mensaje
Paso de cierto período de tiempo, después de entrar al estado o de cierta
hora y fecha particular
El nombre de un evento tiene alcance dentro del paquete en el cual está definido,
no es local a la clase que lo nombre.
6.6.2. Envío de mensajes
Además de mostrar y transición de estados por medio de eventos, puede representarse el momento en el cual se envían mensajes a otros objetos. Esto se realiza
mediante una línea punteada dirigida al diagrama de estados del objeto receptor
del mensaje.
Transición simple
Una transición simple es una relación entre dos estados que indica que un
objeto en el primer estado puede entrar al segundo estado y ejecutar ciertas operaciones, cuando un evento ocurre y si ciertas condiciones son satisfechas. Se
representa como una línea sólida entre dos estados, que puede venir acompañada
de un texto con el siguiente formato:
event-signature "[" guard-condition] "/" action-expression "^"send-clause
event-signature es la descripción del evento que da lugar la transición, guardcondition son las condiciones adicionales al evento necesarias para que la transición ocurra, action-expression es un mensaje al objeto o a otro objeto que se
ejecuta como resultado de la transición y el cambio de estado y send-clause son
acciones adicionales que se ejecutan con el cambio de estado, por ejemplo, el
envío de eventos a otros paquetes o clases.
104
6 ESTUDIO DEL DISEÑO ( UML)
6.6 Diagramas de Estado
Transición interna
Es una transición que permanece en el mismo estado, en vez de involucrar dos
estados distintos. Representa un evento que no causa cambio de estado. Se denota
como una cadena adicional en el compartimiento de acciones del estado.
6.6.3. Acciones
Podemos especificar la solicitud de un servicio a otro objeto como consecuencia de la transición. Se puede especificar el ejecutar una acción como consecuencia
de entrar, salir, estar en un estado, o por la ocurrencia de un evento.
Generalización de Estados:
Podemos reducir la complejidad de estos diagramas usando la generalización de estados.
Distinguimos así entre superestado y subestados.
Un estado puede contener varios subestados disjuntos.
Los subestados heredan las variables de estado y las transiciones externas.
La agregación de estados es la composición de un estado a partir de varios
estados independientes.
La composición es concurrente por lo que el objeto estará en alguno de los estados
de cada uno de los subestados concurrentes. La destrucción de un objeto es efectiva cuando el flujo de control del autómata alcanza un estado final no anidado. La
llegada a un estado final anidado implica la subida al superestado asociado, no el
fin del objeto.
Subestados
Un estado puede descomponerse en subestados, con transiciones entre ellos y
conexiones al nivel superior. Las conexiones se ven al nivel inferior como estados
de inicio o fin, los cuales se suponen conectados a las entradas y salidas del nivel
inmediatamente superior.
105
6 ESTUDIO DEL DISEÑO ( UML)
6.7 Diagramas de actividades
Transacción Compleja
Una transición compleja relaciona tres o más estados en una transición de
múltiples fuentes y/o múltiples destinos. Representa la subdivisión en threads del
control del objeto o una sincronización. Se representa como una línea vertical de
la cual salen o entran varias líneas de transición de estado.
Transición a estados anidados
Una transición hacia un estado complejo (descrito mediante estados anidados)
significa la entrada al estado inicial del subdiagrama. Las transiciones que salen
del estado complejo se entienden como transiciones desde cada uno de los subestados hacia afuera (a cualquier nivel de profundidad).
Transiciones temporizadas
Las esperas son actividades que tienen asociada cierta duración.
La actividad de espera se interrumpe cuando el evento esperado tiene lugar.
Este evento desencadena una transición que permite salir del estado que
alberga la actividad de espera. El flujo de control se transmite entonces a
otro estado.
6.7. Diagramas de actividades
Un estado de actividad representa una actividad: un paso en el flujo de trabajo o la ejecución de una operación. Un grafo de actividades describe grupos
secuenciales y concurrentes de actividades. Los grafos de actividades se muestran
en diagramas de actividades. Las actividades se enlazan por transiciones automáticas. Cuando una actividad termina se desencadena el paso a la siguiente actividad.
Un diagrama de actividades es provechoso para entender el comportamiento
de alto nivel de la ejecución de un sistema, sin profundizar en los detalles internos
de los mensajes. Los parámetros de entrada y salida de una acción se pueden
mostrar usando las relaciones de flujo que conectan la acción y un estado de flujo
de objeto.
106
6 ESTUDIO DEL DISEÑO ( UML)
6.7 Diagramas de actividades
Un grafo de actividades contiene estados de actividad que representa la ejecución de una secuencia en un procedimiento, o el funcionamiento de una actividad
en un flujo de trabajo. En vez de esperar un evento, como en un estado de espera
normal, un estado de actividad espera la terminación de su cómputo. Cuando la
actividad termina, entonces la ejecución procede al siguiente estado de actividad
dentro del diagrama. una transición de terminación es activada en un diagrama
de actividades cuando se completa la actividad precedente. Los estados de actividad no tienen transiciones con eventos explícitos, peor pueden ser abortados por
transiciones en estados que los incluyen.
Un grafo de actividades puede contener también estados de acción, que son
similares a los de actividad pero son atómicos y no permiten transiciones mientras
están activos. Los estados de acción se deben utilizar para las operaciones cortas
de mantenimiento.
Un diagrama de actividades puede contener bifurcaciones, así como divisiones
de control en hilos concurrentes. los hilos concurrentes representan actividades
que se pueden realizar concurrentemente por los diversos objetos o personas. La
concurrencia se representa a partir de la agregación, en la cual cada objeto tiene su
propio hilo. Las actividades concurrentes se pueden realizar simultáneamente o en
cualquier orden. Un diagrama de actividades es como un organigrama tradicional,
excepto que permite el control de concurrencia además del control secuencial.
6.7.1. Notación
Un estado de actividad se representa como una caja con los extremos redondeados que contiene una descripción de actividad. Las transacciones simples de
terminación se muestran como flechas. Las ramas se muestran como condiciones
de guarda en transiciones o como diamantes con múltiples flechas de salida etiquetadas. Una división o una unión de control se representa con múltiples flechas
que entran o salen de la barra gruesa de sincronización.
Cuando es necesario incluir eventos externos, la recepción de un evento se
puede mostrar como un disparador en una transición, o como un símbolo especial
que denota la espera de una señal.
A menudo es útil organizar las actividades en un modelo según su responsa-
107
6 ESTUDIO DEL DISEÑO ( UML)
6.8 Diagramas de Interacción
bilidad. Esta clase de asignación puede mostrarse organizando las actividades en
regiones distintas separads por líneas en el diagrama. Debido a su aspecto, esto es
conocido como Calles.
Un diagrama de actividades puede mostrar el flujo de objetos como valores.
Para un valor de salida, se dibuja una flecha con línea discontinua desde la actividad al objeto. Para un valor de entrada, se dibuja una flecha con línea discontinua
desde el objeto a una actividad.
6.8. Diagramas de Interacción
La vista de interacción describe secuencias de intercambios de mensajes entre
los roles que implementan el comportamiento de un sistema. Un rol clasificador, o simplemente "un rol", es la descripción de un objeto, que desempeña un
determinado papel dentro de una interacción, distinto de los otros objetos de la
misma clase. Esta visión proporciona una vista integral del comportamiento del
sistema, es decir, muestra el flujo de control a través de muchos objetos. La vista
de interacción se exhibe en dos diagramas centrados en distintos aspectos pero
complementarios: centrados en los objetos individuales y centrados en objetos
cooperantes.
Los objetos interactúan para realizar colectivamente los servicios ofrecidos
por las aplicaciones. Los diagramas de interacción muestran cómo se comunican
los objetos en una interacción. Existen dos tipos de diagramas de interacción: el
Diagrama de Colaboración y el Diagrama de Secuencia.
El Diagrama de Secuencia es más adecuado para observar la perspectiva cronológica de las interacciones, muestra la secuencia explícita de mensajes y son
mejores para especificaciones de tiempo real y para escenarios complejos. El Diagrama de Colaboración ofrece una mejor visión espacial mostrando los enlaces
de comunicación entre objetos, muestra las relaciones entre objetos y son mejores
para comprender todos los efectos que tiene un objeto y para el diseño de procedimientos. El diagrama de Colaboración puede obtenerse automáticamente a partir
del correspondiente diagrama de Secuencia (o viceversa).
108
6 ESTUDIO DEL DISEÑO ( UML)
6.8 Diagramas de Interacción
Diagramas de Secuencia
1. Muestra la secuencia de mensajes entre objetos durante un escenario concreto
2. Cada objeto viene dado por una barra vertical
3. El tiempo transcurre de arriba abajo
4. Cuando existe demora entre el envío y la atención se puede indicar usando
una línea oblicua
Diagramas de Colaboración
1. Son útiles en la fase exploratoria para identificar objetos.
2. La distribución de los objetos en el diagrama permite observar adecuadamente la interacción de un objeto con respecto de los demás
3. La estructura estática viene dada por los enlaces; la dinámica por el envío
de mensajes por los enlaces
6.8.1. Colaboración
Es una descripción de una colección de objetos que interactúan para implementar un cierto comportamiento dentro de un contexto. Describe una sociedad
de objetos cooperantes unidos para realizar un cierto propósito. Una colaboración
contiene ranuras que son rellenadas por los objetos y enlaces en tiempo de ejecución. Una ranura de colaboración se llama Rol porque describe el propósito de un
objeto o un enlace dentro de la colaboración.
Un rol clasificador representa una descripción de los objetos que pueden participar en una ejecución de la colaboración, un rol de asociación representa una
descripción de los enlaces que pueden participar en una ejecución de colaboración. Un rol de clasificador es una asociación que está limitada por tomar parte
en la colaboración. Las relaciones entre roles de clasificador y asociación dentro
de una colaboración sólo tienen sentido en ese contexto. En general fuera de ese
contexto no se aplican las mismas relaciones.
109
6 ESTUDIO DEL DISEÑO ( UML)
6.9 Diagramas de Componentes
Una Colaboración tiene un aspecto estructural y un aspecto de comportamiento. El aspecto estrucutral es similar a una vista estática: contiene un conjunto de
roles y relaciones que definen el contexto para su comprtamiento. El comportamiento es el conjunto de mensajes intercambiados por los objetos ligados a los
roles. Tal conjunto de mensajes en una colaboración se llama Interacción. Una
colaboración puede incluir una o más interacciones.
6.8.2. Interacción
Es el conjunto de mensajes intercambiados por los roles de clasificador a través de los roles de asociación. Un mensaje es una comunicaión unidireccional
entre dos objetos, un flujo de objeto con la información de un remitente a un receptor. Un mensaje puede tener parámetros que transporten valores entre objetos.
Un mensaje puede ser una señal (comunicación explícita entre objetos, con nombre y asíncrona) o una llamada (la invocación síncrona de una operación con un
mecanismo para el control, que retorna posteriormente al remitente). Un patrón
de intercambios de mensajes que se realizan para lograr un propósito específico
es lo que se denomina una interacción.
6.8.3. Patrón
Un patrón es una colaboración parametrizada, junto con las pautas sobre cuándo utilizarlo. Un parámetro se puede sustituir por diversos valores, para producir
distintas colaboraciones. Los parámetros señalan generalmente las ranuras para
las clases. El uso de un patrón se representa como una elipse de línea discontinua
conectada con cada una de las clases por una línea discontinua, que se etiqueta
con el nombre del rol.
6.9. Diagramas de Componentes
Los diagramas de componentes describen los elementos físicos del sistema y
sus relaciones. Muestran las opciones de realización incluyendo código fuente,
binario y ejecutable. Los componentes representan todos los tipos de elementos
software que entran en la fabricación de aplicaciones informáticas. Pueden ser
110
6 ESTUDIO DEL DISEÑO ( UML)
6.9 Diagramas de Componentes
simples archivos, paquetes de Ada, bibliotecas cargadas dinámicamente, 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 código fuente, componentes del código binario, y componentes ejecutables. Un módulo de software se puede representar
como componente. Algunos componentes existen en tiempo de compilación, algunos en tiempo de enlace y algunos en tiempo de ejecución, otros en varias de
éstas.
Un componente de sólo compilación es aquel que es significativo únicamente
en tiempo de compilación. Un componente ejecutable es un programa ejecutable.
Un diagrama de componentes tiene sólo una versión con descriptores, no tiene
versión con instancias. Para mostrar las instancias de los componentes se debe usar
un diagrama de despliegue.
Un diagrama de componentes muestra clasificadores de componentes, las clases definidas en ellos, y las relaciones entre ellas. Los clasificadores de componentes también se pueden anidar dentro de otros clasificadores de componentes
para mostrar relaciones de definición.
Un diagrama que contiene clasificadores de componentes y de nodo se puede
utilizar para mostrar las dependencias del compilador, que se representa como flechas con líneas discontinuas (dependencias) de un componente cliente a un componente proveedor del que depende. Los tipos de dependencias son específicos
del lenguaje y se pueden representar como estereotipos de las dependencias.
El diagrama también puede usarse para mostrar interfaces y las dependencias
de llamada entre componentes, usando flechas con líneas discontinuas desde los
componentes a las interfaces de otros componentes.
El diagrama de componente hace parte de la vista física de un sistema, la
cual modela la estructura de implementación de la aplicación por sí misma, su
organización en componentes y su despliegue en nodos de ejecución. Esta vista
proporciona la oportunidad de establecer correspondecias entre las clases y los
componentes de implementación y nodos. La vista de implementación se representa con los diagramas de componentes.
111
6 ESTUDIO DEL DISEÑO ( UML)
6.9 Diagramas de Componentes
6.9.1. Componentes
Es una parte física reemplazable de un sistema que empaqueta su implementación y es conforme a un conjunto de interfaces a las que proporciona su realización.
Algunos componentes tienen identidad y pueden poseer entidades físicas, que
incluyen objetos en tiempo de ejecución, documentos, bases de datos, etc. Los
componentes existentes en el dominio de la implementación son unidades físicas
en los computadores que se pueden conectar con otros componentes, sustituir,
trasladar, archivar, etc.
Los componentes tienen dos características: Empaquetan el código que 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.
Código:
Un componente contiene el código para las clases de implementación y otros
elementos. Un componente de código fuente es un paquete para el código fuente
de las clases de implementación. Al gunos lenguajes de programación distinguen
archivos de declaración de los archivos de método, pero todos son componentes.
Un componente de código binario es un paquete para el código compliado. Una
biblioteca del código binario es un componente.
Cada tipo de componente contiene el código para las clases de implementación
que realizan algunas clases e interfaces lógicas. La relación de realización asocia
un componente con las clases y las interfaces lógicas que implementan sus clases
de implementación. Las interfaces de un componente describen la funcionalidad
que aporta. Cada operación de la interfaz debe hacer referencia eventualmente a
un elemento de la implementación disponible en el componente.
La estrucutra estática, ejecutable de una implementación de un sistema se puede representar como un conjunto interconectado de componentes. Las dependencias entre componentes significan que los elementos de la implementación en un
componente requieren los serivios de los elementos de implemntación en otros
componentes. Tal uso requiere que dichos elementos sean de visibilidad pública.
112
6 ESTUDIO DEL DISEÑO ( UML)
6.10 Diagramas de Despliegue
Identidad:
Un componente de identidad tiene identidad y estado. Posee los objetos físicos
que están situados en él. Puede tener atributos, relaciones de composición con
los objetos poseídos, y asociaciones con otros componentes. Desde este punto de
vista es una clase. Sin embargo la totalidad de su estado debe hacer referencia a
las instancias que contiene.
Estructura:
Un componente ofrece un conjunto de elementos de implementación, esto significa que el componente proporciona el código para los elementos. Un componente puede tener operaciones e interfaces. Un componente de identidad es un
contenedor físico para las entidades físicas 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 implementación.
Este componente se representa con un rectángulo con dos rectángulos más pequeños que sobresalen en su lado izquierdo.
Las operaciones e interfaces disponibles para los objetos exteriores se pueden
representar directamente en el símbolo de clase. Estos son su comportamiento 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 líneas discontinuas con la punta de flecha hacia los
elementos del proveedor. Sí un componente es la realización de una interfaz, se
representa con un círculo unido al símbolo del componente por un segmento de
línea.
6.10. Diagramas de Despliegue
Los Diagramas de Despliegue muestran la disposición física de los distintos
nodos que componen un sistema y el reparto de los componentes sobre dichos
nodos. La vista de despliegue representa la disposición de las instancias de componentes de ejecución en instacias de nodos conectados por enlaces de comunicación. Un nodo es un recurso de ejecución tal como un computador, un dispositivo
113
6 ESTUDIO DEL DISEÑO ( UML)
6.11 Los paquetes
o memoria. Los estereotipos permiten precisar la naturaleza del equipo:
Dispositivos
Procesadores
Memoria
Los nodos se interconectan mediante soportes bidireccionales que pueden a su vez
estereotiparse. Esta vista permite determinar las consecuencias de la distribución y
la asignación de recursos. Las instancias de los nodos pueden contener instancias
de ejecución, como instancias de componentes y objetos. El modelo puede mostrar
dependencias entre las instancias y sus interfaces, y también modelar la migración
de entidades entre nodos u otros contenedores.
Esta vista tiene una forma de descriptor y otra de instancia. La forma de instancia muestra la localización de las instancias de los componentes específicos
en instancias específicas del nodo como parte de una configuración del sistema.
La forma de descriptor muestra qué tipo de componentes pueden subsistir en qué
tipos de nodos y qué tipo de nodos se pueden conectar, de forma similar a una
diagrama de clases, esta forma es menos común que la primera.
6.11. Los paquetes
Los paquetes son elementos para organizar elementos en grupos. Imaginemos
una aplicación con cientos de clases que se ven entre todas ellas, no hay forma
de comprender una red de relaciones tan grande y desorganizado. Es un problema real para grandes sistemas (el acceso simple y no restringido no permite el
crecimiento). Para estas situaciones se necesita algún tipo de empaquetamiento
controlado para organizar las abstracciones.
114
6 ESTUDIO DEL DISEÑO ( UML)
6.11 Los paquetes
Anidamiento
Las abstracciones que organizan un modelo se llaman paquetes. Y los paquetes
agrupan a otros paquetes organizándolos en forma de directorios. Se recomienda
tener como límite dos o tres niveles de anidamiento. Al anidar un paquete (Menú)
dentro de otro paquete (Ventana) se indica con el nombre del paquete anidado
precedido por el nombre que lo contiene (Ventana::Menú). Por ejemplo el nombre
de camino para el paquete Menú puede ser API::Ventana::Menú
Importación
La importación de un paquete hace que se pueda acceder a los elementos de
ese paquete, pero el paquete importado no puede acceder a los elementos del otro.
En UML una relación de importación se modela como una dependencia con el
estereotipo import.
Elementos extensibilidad
Pueden añadirse valores etiquetados para añadir nuevas propiedades al paquete (como el autor, fecha creación, etc) y estereotipos para especificar categorías.
Estos son:
1. facade: (fachada) Es un paquete que muestra solo unos objetos de otro paquete. Se usa para mostrar vistas simplificadas y diferentes que de otra forma serían vistas muy complejas, reduciendo el campo de visión según las
funciones que vayan a usarse.
2. stub: Paquete tiene la función de proxy a otro paquete.
3. subsystem: Representa una parte independiente del sistema completo.
115
6 ESTUDIO DEL DISEÑO ( UML)
6.11 Los paquetes
4. system: Representa al sistema completo.
116
7 HACKING DEL KERNEL
Parte II
Práctica
7. Hacking del kernel
7.1. Introducción
Programar en espacio del kernel ha sido siempre cosa de gurús, o al menos
eso es lo que se piensa. Muy poca gente tiene el coraje, los conocimientos y la
paciencia para trabajar con interrupciones, devices y con el siempre temido kernel
panic.
Cuando se escribe un programa en espacio de usuario, lo peor que puede pasar
es un core dump. El programa hizo algo muy malo, así que el sistema operativo
decide que el programa debe finalizar y hace un volcado de toda la memoria y la
información del estado del proceso en forma de un fichero core. Los ficheros core
pueden ser usados luego para debugar el programa y encontrar el problema que
originó el core dumped.
Pero cuando se programa dentro del kernel la cosa cambia, no hay ningún 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 código. A veces puede sobrevivir a un kernel panic,
si lo que se ha hecho mal es relativamente benigno, este tipo de kernel panic se le
suele llamar oopses, luego lo pasaré a explicar más detalladamente. Pero, no hay
nada que pare al código de sobreescribir o acceder a localizaciones de la memoria
de cualquiera dentro del espacio de direcciones del kernel. También, puede colgarse algún módulo, entonces el kernel se cuelga, técnicamente el thread se cuelga
pero tiene las mismas repercusiones.
Estos problemas pueden sonar un poco exagerados pero se tiene que tratar con
mucho cuidado. Además si hay un kernel panic, raramente se sabe que demonios
ha pasado, porque simplemente el sistema operativo deja de funcionar. La típica
solución es mirar aquellos printk que creemos han causado el error, y esperar
que podamos verlos al rebotar la máquina y no se hayan perdido. Y todo esto
117
7 HACKING DEL KERNEL
7.2 Uso del debugador
asumiendo que no se ha corrompido el sistema de ficheros. Porque he llegado
a perder un sistema de ficheros completo de una máquina virtual después de un
triste kernel panic, supongo que debido a una mala inicialización de un puntero
que sobreescribió algunas estructuras internas del ext2.
La primera cosa que se aprende cuando se programa en dentro del kernel es
que hay que mantener una copia de toda la programación en una máquina diferente, móntalo como sea, ya sea con NFS, con ftps, o con máquinas virtuales mientras
esta no acceda directamente a una partición del ordenador donde se está trabajando. Los ficheros permanecen seguros en otra máquina. Aún así no se ahorra uno
tiempo teniendo que hacer los e2fsck incluso para los sistemas ext3, después de
un kernel panic.
Así que, con todo esto no sorprende que poca gente haya entrado en la programación real del sistema operativo.
7.2. Uso del debugador
El uso de un debugador está mal visto generalmente por gente como Linus
Torvalds. Considerando lo que él mismo ha dicho en la lista de mailing del kernel
de Linux:
“ I’m afraid that I’ve seen too many people fix bugs by looking at debugger
output, and that almost inevitably leads to fixing the symptoms rather than the
underlying problems.” Linus Torvalds
Dice que se debe usar el código fuente para resolver los problemas y los bugs
del kernel. Además que resolviendo bugs mirando sólo el debugger se peca de
arreglar los sintomas en vez de resolver el problema que está tras ellos.
El uso de un debugador solamente no es suficiente, debe mirarse el código.
Pero también hay que tener en cuenta que es necesario tener mucha experiencia
programando, y resolviendo problemas que ya han visto antes. Es necesario llegar
a la raíz del problema observando el código. Pero llegar a tener esta experiencia
programando en el kernel requiere un uso inteligente del debugador.
1. Usar el debugador para recoger las evidencias alrededor del problema.
2. Estudiar el código y pensar qué está sucediendo.
118
7 HACKING DEL KERNEL
7.2 Uso del debugador
3. Intentar concentrasrse en las posibles causas de los síntomas que se ve en
el debugador. Entonces pensar las posibles causas hasta la raíz del problema. Escibir una lista de posibilidades, poniéndolas en orden de parecido
al problema y probándolas una a una. El proceso de clarificación de ideas
escribiéndolas puede ser de gran ayuda.
4. Hasta que se tenga más experiencia, se debería usar el debugador para probar algunas ideas probando valores de variables.
Por eso el debugador es una herramienta para estimular la razón, y el pensamiento
lógico para averiguar que está sucediendo en el código. No hay que resolver los
problemas para arreglar la salida del debugador. Y aquí hay una lista de las cosas
que se deben hacer y las que no:
Qué hacer:
1. Estudiar el código antes de empezar a jugar con el debugador. Se es mucho
más productivo si se tiene en mente el código, antes de empezar a debugar.
2. Usar el debugador para probar las ideas y presunciones, los bugs vienen
normalmente como resultado de presunciones incorrectas. Pues bueno hay
que hacer más intentos, que es posible que fallen, pero también es posible
que no.
3. Si las presunciones son incorrectas, hay que aprender de porqué esa presunción está mal, es importante que no se repita, porque a lo mejor la próxima
vez no nos rebentará a nosotros, sino a otros, o peor aún que de un kernel
panic cuando tenemos un ordenador en producción.
4. Descartar el debugador cuanto antes mejor. Trabajar en el código.
Qué no hacer:
1. Ignorar las causas reales del problema que podamos pensar. Cuando se encuentra que algo está mal, no hacer que funcione para este o ese otro caso,
para que parezca que funciona. Un ejemplo clásico es añadir otra sección a
un statement del switch para cubrir las posibilidades que no se hayan pensado.
119
7 HACKING DEL KERNEL
7.3 printk
2. Resolver ciegamente un problema con el debugador. Se puede llegar a conclusiones erróneas y no se aprende mucho sobre el proceso.
Una vez entendido como debe usarse un debugador y como no debe usarse vamos
a ver las diferentes posibilidades que hay disponibles. Existen varias formas para
debugar:
7.3. printk
La función printk es la forma que se tiene de guardar logs del sistema y 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 interrupción [RU1], pero debe usarse con cuidado: si la máquina tiene su consola saturada de mensajes printk no es útil. Usa un
formato muy parecido y casi compatible con la función printf del ANSI C, y la
concatenación de strings para dar prioridades a los argumentos:
printk( KERN_INFO “i = %u\n”, i);
Es necesario ver el fichero include/linux/kernel.h para ver otros valores del KERN_.
Estos se interpretan como el nivel para el syslog. Un caso especia para imprimir
una IP en uso es de la siguiente manera:
__u32 ipaddress;
printk(KERN_INFO “mi ip: %d. %d. %d. %d\n”, NIPQUAD(ipaddress));
printk () usa internamente un buffer de 1KB y no puede pillar overruns. Así que
hay que asegurarse que el mensaje no es mayor. Dicen los gurus que se sabe que
uno es un hacker del kernel auténtico cuando se escribe en vez de usar printf en
un programa normal se usa printk. A mi todavía no me ha pasado, todavía.
Los ocho posibles tipos de nivel que se definen en la cabecera <linux/kernel.h>
son los siguientes:
KERN_EMERG: Usado para mensajes de emergencia, normalmente cuando se
va a producir un crash del sistema.
120
7 HACKING DEL KERNEL
7.3 printk
KERN_ALERT: Una situación que requiere una acción inmediata.
KERN_CRIT: Condiciones críticas, normalmente relacionados con problemas
serios de hardware o software.
KERN_ERR: Usado para indicar errores de condiciones
KERN_WARNING: Warnings sobre situaciones problemáticas que en sí no 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 información
del hardware que encuentran al arrancar y la muestran en este nivel.
KERN_DEBUG: Usado para mensajes de debugaje.
Cada string representa un entero. Que van desde 0 a 7, con los valores más pequeños representando las prioridades más altas. [ALS].
Basándose en el nivel del log, el kernel puede que muestre los mensajes en la
consola, en un terminal modo texto o en una impresora. Si la prioridad es menor
que la variable console_loglevel, entonces los mensajes se muestran por consola.
Si ambos klogd y el syslogd están ejecutándose en el sistema, los mensajes del
kernel se añaden a /var/log/messages o donde se haya configurado con el syslogd.
Si el klogd no se está ejecutando, los mensajes no se mostrarán en el espacio de
usuario, a no ser que se lea /proc/kmsg. La variable console_loglevel se inicializa a DEFAULT_CONSOLE_LOGLEVEL y puede ser modificada a través de la
llamada a sistema sys_syslog. En el kernel actual se puede hacer que todos los
mensajes se muestren por consola haciendo los siguiente desde la cuenta de root:
(bash)$ echo 8 > /proc/sys/kernel/printk
La mejor ventaja que tienen es que es fácil de usar, haces un printk y si luego
hay un kernel panic, pues se mira hasta donde ha ido. Fácil y sencillo. Además de
poder usarse siempre, incluso dentro de una interrupción.
121
7 HACKING DEL KERNEL
7.4 Oops
Pero tiene varios inconvenientes. Si por ejemplo tenemos un error puñetero,
como por ejemplo que cuando empezamos a leer de un device, por ejemplo, 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 había pasado, en estos casos los printk’s que estaban a punto de escribirse no lo hubiesen hecho y luego uno duda si realmente los últimos printk’s es
realmente lo último que se ha hecho. Así que es necesario usar además del printk
otros mecanismos para debugar el código y los errores.
7.4. Oops
Cuando el kernel detecta que existe una condición de anomalía seria, se dispara un ’oops’. Un oops tiene dos funciones principalmente:
Volcar la información de debugging interesante que podemos usar para diagnosticar la causa del problema.
Probar y prevenir que el kernel pierda el control y que cause corrupción en los
datos, o aún peor que se cause daño al hardware, aunque es difícil que suceda, es
posible.
Al principio, un oops parece completamente incomprensible, un montón de
líneas con valores hexdecimales y con datos que parecen crípticos.
![CDATA[
CPU:
0
EIP:
0010:<c011933c> Tainted: P
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010002
eax: 00000ce0
ebx: 00001000
ecx: c778a510
edx: 00000610
esi: 00000002
edi: 00000000
ebp: c02165c0
esp: c6663f58
ds: 0018
es: 0018
ss: 0018
Process pcmcia (pid: 1003, stackpage=c6663000)
Stack: 00000000 c02165a0 00000000 c02165c0 c6663fc4 c01193cf
c0116340 00000000 00000001 c02165c0 fffffffe c011616a
122
7 HACKING DEL KERNEL
7.4 Oops
c0214900 00000000 c6663fbc 00000046 c010817d 00000000
Call Trace: <c01193cf><c010ac96><c0116406><c0116340><c011616a>
Code: 89 42 04 89 10 c7 41 04 00 00 00 00 c7 01 00 00 00 00 fb 53
> > EIP; c011933c <timer_bh></timer_bh>+228/27c> =====
Trace; c01193cf <do_timer></do_timer>+3f/70>
Trace; c010ac96 <timer_interrupt></timer_interrupt>+62/110>
Trace; c0116406 <bh_action></bh_action>+1a/48>
Trace; c0116340 <tasklet_hi_action></tasklet_hi_action>+40/60>
Trace; c011616a <do_softirq></do_softirq>+5a/ac>
Trace; c010817d <do_irq></do_irq>+a1/b4>
Trace; c0109f48 <call_do_irq></call_do_irq>+5/d>
Code; c011933c <timer_bh></timer_bh>+228/27c>
00000000 <_eip>:
Code; c011933c <timer_bh></timer_bh>+228/27c> ====
0:
89 42 04
mov
%eax,0x4( %edx)
====
Code; c011933f <timer_bh></timer_bh>+22b/27c>
3:
89 10
mov
%edx,( %eax)
Code; c0119341 <timer_bh></timer_bh>+22d/27c>
5:
c7 41 04 00 00 00 00
movl
$0x0,0x4( %ecx)
Code; c0119348 <timer_bh></timer_bh>+234/27c>
c:
c7 01 00 00 00 00
movl
$0x0,( %ecx)
Code; c011934e <timer_bh></timer_bh>+23a/27c>
12:
fb
sti
Code; c011934f <timer_bh></timer_bh>+23b/27c>
13:
53
push %ebx
0>Kernel panic: Aiee, killing interrupt handler!
3 warnings issued. Results may not be reliable.
]]>
</_eip></c0109f48></c010817d></c011616a></c0116340>
La anatomía de un oops es muy de bajo nivel, además cada imagen del kernel
tienen un oops específico. Por eso, se necesita hacer un post proceso para obtener
información de donde empezar a hacer el proceso de debugaje. La idea es compilar
123
7 HACKING DEL KERNEL
7.5 Máquinas virtuales
en ensamblador allá donde creemos que está dando el error, y mirar las últimas
operaciones para saber donde nos ha dejado colgado el kernel. Esta es la única
manera de saber qué le ha pasado a un kernel que ha dado un kernel panic y ha
dejado de funcionar. Los inconvenientes son varios, para empezar es muy difícil
de entender el volcado (aunque cuando es la única ayuda disponible esta es muy
valiosa) y otro inconveniente es que hay que compilar el kernel con la opción oops
y está ocupa espacio dentro del kernel, que a pesar de ser pequeño es importante
en proporción al resto de kernel.
7.5. Máquinas virtuales
Cuando habían los mainframes, y la misma máquina se compartía entre varios sistemas nació la idea de máquinas virtuales. Una máquina virtual es una
encapsulación de un ordenador a tu entera disposición. Un programa dentro de
una máquina virtual no tiene acceso real al hardware físico. Todo el acceso al
hardware se controla mediante la máquina virtual, que emula al ordenador. Es una
interfaz entre el programa y la máquina real.
La idea es tener un ordenador con un sistema operativo sobre el que se trabaja, donde se edita y se compila el código. Tener bajo este sistema operativo
un programa que sea una máquina virtual, y sobre este programa que emula un
ordenador hacer correr el sistema operativo que está bajo desarrollo. Así de esta
manera cuando el sistema sobre el que estamos trabajando se cuelga, o da un kernel panic, o sobreescribe datos del disco, solo le afecta a la máquina virtual. Y así
mientras se reinicia el sistema se puede seguir trabajando con la misma sesión. Al
ordenador físico no le pasa nada.
Existen dos posibilidades, de máquinas virtuales: una que es la VMware (Virtual Machine ware) y otra de libre distribución llamada UML (User Mode Linux).
VMware es muy potente, permite emular cualquier sistema operativo basado
en x86, bajo Windows NT, Windows 2000, Windows XP o Linux. Y puede correr
bajo máquinas x86 y sobre ordenadores basados en chips de Motorola como los
Macintosh. La versión para Linux que se puede bajar por Internet cuesta 299$ US.
124
7 HACKING DEL KERNEL
7.6 Debugando con dos máquinas
VMware emula una máquina x68, con alguna característica, por ejemplo la
interfaz del disco duro es un scsi, la targeta de red es una AMD, etc.. A la hora
de recompilar el kernel es necesario activar el soporte para targetas de red AMD
PCnet32 PCI. Y activar el soporte SCSI igual que el soporte para discos SCSI.
UML es la segunda opción, es gratuito, pero tiene un inconveniente y es que no
es una máquina virtual completa. No emula diferentes tipos de hardware, tampoco
te da la posibilidad de ejecutar ostro sistema operativo. Pero permite ejecutar un
kernel en el espacio de usuario, y eso representa varios beneficios cuando se trata
de desarrollo: los ficheros del host están protegidos, el sistema de ficheros virtual
se puede descargar, se pueden ejecutar varias máquinas en una sola, y lo mejor
es que es muy fácil usar el degubador para el kernel. No se necesita comprar
más hardware para hacer los tests, al menos que se esté programando un device
específico.
Ejecutar el UML es fácil, hay que bajar los binarios y luego, o bien instalar un
nuevo sistema o bien bajarse uno que ya esté prehecho de la página web. A pesar
de algunos inconvenientes del sistema UML, tiene una ventaja muy buena a la
hora de programar algún sistema de ficheros, pues el resultado de las operaciones
pueden destrozar el sistema de ficheros. Cuando se trabaja con UML si hay un
kernel panic del sistema de ficheros, lo único que hay que hacer es borrar un
fichero .cow (ficheros Copy On Write), y en caso de estar corrupto el sistema de
ficheros, este se restaura a la versión original, así que ya no hay que hacer los
fsck’s.
7.6. Debugando con dos máquinas
Esta solucón pasa por tener dos máquinas en una se desarrolla el software
y en la otra se ejectua el kernel de desarrollo. Debe ser capaz de ejecutarse el
debugador en la máquina de desarrollo y tener un terminal de consola abierto al
segundo ordenador. Hay que montar dos máquinas, máquina de trabajo y la otra
máquina te testeo, donde se ejecutarán los kernels en desarrollo.
125
7 HACKING DEL KERNEL
7.6 Debugando con dos máquinas
Hardware
La primera máquina tiene el sistema operativo de desarrollo con una tarjeta ethernet. La segunda máquina, no necesita monitor, dependiendo de lo antiguo que
sea el ordenador (depende de la BIOS) necesitará un teclado para arrancar, aunque
es muy recomendable, al menos para hacerle un Ctr-Alt-Supr y otras operaciones
en el caso de no poder acceder remotamente. También necesita una Ethernet, aunque lo mejor es tener dos Ethernets en esta máquina y así poder pasar paquetes
a través de ella. Construir dos cables serial, uno servirá para ejecutar el gdb (el
debugger) y el otro para dar acceso a una consola así puede controlarse remotamente. Los cables serial necesitan tener esta disposición:
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
7 HACKING DEL KERNEL
7.6 Debugando con dos máquinas
Software
Instalar ssh en apollo, instalar sshd en la segunda máquina 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 también se puede hacer transferencias de ficheros mediante conexiones seguras a modo de ftp. Que servirán
para traspasar ficheros. Configurar el sistema de tal modo que haya acceso a la
segunda máquina desde la primera. Dar permisos de lectura/escritura a /dev/ttys0
y a /dev/ttyS1que corresponden a los puertos serie. Instalar minicom en ambas
máquinas, es un programa para hacer telecomunicaciones entre sistemas UNIX y
puede encontrarse en http://www.netsonic.fi/~walker/minicom.html.
Para la preparación del kernel se tardará más tiempo. Es necesario bajarse
el kernel 2.4.18 y descomprimirlo en la máquina apollo. No se debe instalar el
último kernel el 2.4.19 porque se necesita un parche para ejecutar el kgdb y este
solo esta disponible para 2.4.18 y anteriores. Bajarse el parche antes comentado
en http://kgdb.sourceforge.net/. Aplicarle el parche desde el bash de la siguiente
manera:
cat kgdb\_2.2.18.diff |patch -p2
Entonces compilar el kernel de manera que como se ha hecho siempre, pero en el
menú hay que añadir a la configuración usual dos nuevas opciones:
* support for console on serial port under character devices
* kernel support for gdb (new) under kernel hacking.
Y es recomendable compilar todas las opciones directamente al kernel en vez de
usar los módulos, así cuando pasemos los ficheros habrá que pasar solo la imagen
del kernel.
Tras esto hacer un ’make dep bzImage’ como de una compilación del kernel
normal y corriente. Copiar la imagen a la segunda máquina, también se puede
usar un FTP, pero no es necesario si se dispone del sshd, solo hay que escribir la
siguiente orden:
scp arch/i386/boot/bzImage segunda:bzimage-2.2.18-kgdb
127
7 HACKING DEL KERNEL
7.6 Debugando con dos máquinas
Entrar en la segunda máquina, y desde la cuenta de root, copiar la imagen del
kernel al directorio /boot y añadir las siguientes líneas en la configuración del lilo,
para crear una nueva entrada con el nuevo kernel.
image=/boot/bzImage-2.2.18-kgdb
label=kgdb
root=/dev/hda1
read-only
append=" gdb gdbttys=0 console=ttys1"
serial = 0,9600n8
La última línea nos dice que podemos controlar las opciones del lilo cuando se
arranca el ordenador desde la misma consola conectada al serial com2, se puede
usar el gdb (el debugador) por /dev/ttyS0 y además se usa la /dev/ttyS1 para usarlo
como una consola. De esta manera se pontrola todo el proceso de debugaje y con
la consola se puede acceder remotamente, con los cables por los puertos serie. Es
muy importante ejecutar lilo cuando se haya terminado de editar este fichero, en
el supuesto que pasara leer en la sección de compilar el kernel la solución.
En la máquina de desarrollo hay que crear un fichero llamado .gdbinit en el directorio raíz del código fuente del kernel, este fichero debe contener las siguientes
líneas:
define rmt
set remotebaud 38400
target remote /dev/ttyS0
end
Ejecutar en esta máquina como root la siguiente orden:
minicom -s
Y en este programa se dispone de un menú donde hay que configurar las opciones
del puerto de serie.
128
7 HACKING DEL KERNEL
7.6 Debugando con dos máquinas
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 opción ’Save setup as dfl’ y tras guardar la configuración
como defecto salir. Así dejar luego al minicom esperando una sesión.
Rebotar la segunda máquina y entonces aparecerá en la primera por la salida
del minicom las siguientes líneas:
Linux version 2.2.18serialgdb
Detected 167046 kHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 333.41 BogoMIPS
Memory: 63556k/65536k available (704k kernel code, 408k reserved, 824k data,
Dentry hash table entries: 8192 (order 4, 64k)
Buffer cache hash table entries: 65536 (order 6, 256k)
Page cache hash table entries: 16384 (order 4, 64k)
CPU: Intel Pentium 75 - 200 stepping 0c
Checking 386/387 coupling... OK, FPU using exception 16 error reporting.
Checking ’hlt’ instruction... OK.
Intel Pentium with F0 0F bug - workaround enabled.
POSIX conformance testing by UNIFIX
Trying to free free IRQ4
Waitng for connection from remote gdb on ttyS0
Entonces sabremos que la configuración a dado resultado.
En la primera máquina tenemos que arrancar el debugger apretando gdb vmlinux>(en la raíz del directorio del código fuente) y entonces arrancará el gdb y
mostrará una información sobre el programa y aparecerá una línea de comandos.
Hay que escribir rmt y entonces leerá el fichero .gdbinit, se conectará al puerto
serie y debe mostrar las lineas siguientes:
129
7 HACKING DEL KERNEL
7.6 Debugando con dos máquinas
(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 DISEÑO DE LA APLICACIÓN
8. Diseño de la aplicación
8.1. Esquemas UML
Debido a que dentro del kernel de Linux no se puede compilar en C++ no
existen objetos ni tampoco clases. Esto hace que dos de los diagramas más importantes del UML no puedan crearse. Aún así UML es suficientemente versátil
como para poder definir un proyecto sin usar estos dos diagramas. Para entender
un proyecto debemos disponer al menos de un diagrama estructural, para tener
una vista el diseño de la estructura, y otro diagrama dinámico, para tener una vista
del funcionamiento.
Los siguientes puntos detallan los diferentes diagramas del proyecto: un 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 técnica para capturar información de cómo un sistema o
negocio trabaja, o de cómo se desea que trabaje. En el diagrama casos de uso se
representa las operaciones que el Administrador puede hacer con el firewall.
Casos de Uso
Firewall
Cargar
políticas
Leer
logs
Administrador
Ver
estadis.
Las cargas de políticas se producen cuando el administrador desea modificar
131
8 DISEÑO DE LA APLICACIÓN
8.1 Esquemas UML
las políticas y tras cambiar el fichero de configuración se dispone a cambiar las políticas. Devuelve un mensaje de error indicando si el fichero está incorrectamente
tipificado, o bien un mensaje mostrando la correcta carga de los nuevos datos. El
objetivo es cambiar las políticas que están guardadas dentro de las estructuras de
datos del firewall.
Leer los logs se produce siempre que el administrador desea comprobar los
intentos de ataques que el firewall haya bloqueado para ver si se ha estado 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 estadísticas 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 estadísitcas del firewall resumidas y
actualizadas en todo momento.
La cronología de los casos de usos tiene sentido de la siguiente manera: cargar
las políticas al principio, comprobar que funciona con la vista de las estadísticas
y cada cierto tiempo comprobar el estado de la máquina viendo los ficheros log.
8.1.2. Diagramas de actividades
Un estado de actividad representa una actividad: un paso en el flujo de trabajo o la ejecución de una operación. Se usan para entender el comportamiento
de una parte del programa. Muestran una vista dinámica del funcionamiento del
programa.
El primer diagrama muestra como se cargan las políticas dentro de las estructuras internas del firewall.
132
8 DISEÑO DE LA APLICACIÓN
8.1 Esquemas UML
Introducir políticas
Parsear
políticas
incorrecto
Mostrar
errores
correcto
Introducir
políticas
CUIDADO!
Semáforo de
escritura
Mostrar
resultados
Este esquema representa el proceso de cargado de políticas, lo primero que
se realiza es un parseado del fichero, comprobando que las reglas estén semánticamente bien escritas. Genera los datos de acuerdo con lo leido en el fichero. Si
todo este proceso fuese correcto entonces se introducen las políticas de seguridad
dentro del firewall, habiendo activado el semáforo de escritura previamente. En
el caso que el proceso diera errores se mostrarían los resultados sin modificar en
ningún momento la estructura interna del firewall.
En el segundo diagrama de actividades se muestra como funciona el filtro de
un paquete, guardado en un sk_buff.
133
8 DISEÑO DE LA APLICACIÓN
8.1 Esquemas UML
Filtrar sk_buff
Filtrado de
un sk_buff
otra búsqueda
CUIDADO!
Semáforo de
lectura
Es esta
política?
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
política que pertenezca al sk_buff. El orden de las políticas es importante ya que la
primera política que de éxito se pasará a la siguiente fase. Si la política específica
muestra que hay que hacer log se guarda mediante el printk los datos del sk_buff
y el resultado de la operación de filtrado. El syslog ya se encargará de marcar la
fecha y de su escritura en los ficheros de log del sistema. Después de ello se mira
si hay que eliminar el paquete, en ese caso se libera el sk_buff, y si no es así se
134
8 DISEÑO DE LA APLICACIÓN
8.1 Esquemas UML
continúa retorna del filtrado y se continua por donde estaba trabajando el sistema
operativo.
8.1.3. Diagrama de secuencia
El diagrama de secuencia muestra la relación que tienen los distintos 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
Semáforo
Lectura
recurrencia
políticas
Desactivar
Semáforo
Lectura
retornar
resultado
Si bloquear
kfree_skb(skb)
Se observa como interactúan el firewall y el kernel a la hora de filtrar un
sk_buff. Al hacer la llamada desde cualquier hook y pedirle al firewall si pasa
el filtro o no, este activa el semáforo de lectura mediante las funciones que ofrece
el kernel. Busca la política dentro de las estructuras de datos que tiene el firewall,
y tras encontrarla le pide al kernel que libere el semáforo de lectura. Retorna el
135
8 DISEÑO DE LA APLICACIÓN
8.2 Exclusión mutua
firewall el resultado del filtro y si se debe bloquear pues se pide al kernel que libere el búffer correspondiente a ese paquete. Sino se continúa como si no hubiera
pasado nada.
8.2. Exclusión mutua
Antes de explicar donde tratar los paquetes y como tratarlos, es importante
hacer un repaso a la teoría de exclusión mutua, ya que antes de acceder a cualquier
estructura de datos dentro del kernel hay que averiguar si debe controlarse con
semáforos.
8.2.1. La importancia de los semáforos
A la hora de hablar del kernel si se accede a cualquier tipo de estructura de
datos desde dos sitios se tiene muy probablemente un bug, porque no se asegura la
cosistencia de los datos dentro del kernel. Y como me pasó a mí, si no se protegen
las estructuras con semáforos, el kernel hace un kernel panic y deja de funcionar
a la mínima. Al principio como uno no está acostumbrado a trabajar dentro de un
sistema operativo se le hace raro que se acceda a una estructura de datos desde
dos sitios diferentes y que de la casualidad que al mismo momento que se accede
a esas direcciones por una parte y que por otra parte se haga alguna operación no
válida y que como resultado pare el sistema. Se hace difícil que se cumplan dichas
condiciones, pero no es así, y por lo tanto hay que asegurarse de cumplir la teoría
siempre que se tengan datos compartidos.
8.2.2. Locks de lectura
Tenemos varios procedimientos de proteger los datos deshabilitando las IRQ.
En el fichero include/linux/brlock.h se definen las diferentes posibilidades. Lo que
hacen es hacer un #define que aunque no está recomendado simplifica mucho el
trabajo. En el caso de la protección a los datos de sk_buff tenemos que usar la función br_read_lock_bh(BR_NETPROTO_LOCK) para activar el semáforo y entrar
en la zona de exclusión mutua que el código se debe proteger mediante semáforos.
Y el br_read_unlock_bh(BR_NETPROTO_LOCK) para salir de la zona crítica. La
136
8 DISEÑO DE LA APLICACIÓN
8.2 Exclusión mutua
definición es la siguiente:
#define br_read_lock_bh(idx) \
do { local_bh_disable(); br_read_lock(idx); } while (0)
...
...
#define br_read_unlock_bh(idx) \
do { br_read_unlock(idx); local_bh_enable(); } while (0)
Como puede verse, para entrar dentro de la zona protegida se desactiva primero
los bh (botton halves) que es el mecanismo que se hacía en los anteriores kernels
para proteger zonas de exclusión mutua. El principal inconveniente es que solo
funciona para una sola CPU y por eso se usa ahora softirq’s pero lo cierto es
que cuando se llega al proceso de tratar los paquetes, estos solo se tratan en una
CPU así que nos sirve perfectamente este mecanismo. Y entonces se activa el
lock sobre la variable BR_NETPROTO_LOCK. Como puede verse en el fichero
include/linux/brlock.h solo existe dos tipos de locks para este semáforo, uno son
los BR_NETPROTO_LOCK y otro son BR_GLOBALIRQ_LOCK.
El modo de uso es parecido a esto:
br_read_lock_bh(BR_NETPROTO_LOCK);
..
-Región CríticaAcceso 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 atómicas, y para el
resto de casos no se usan los locks atómicos.
Estos semáforos son solo para proteger los datos para lectura, cuando se desee
hacer una escritura a los datos se debe usar los semáforos para protegerlos de las
escrituras. Porque cuando se protege para lectura pueden acceder muchos mecanismo, pero cuando se accede para escritura solo puede entrar uno, en esos casos
se usan los locks de escritura.
137
8 DISEÑO DE LA APLICACIÓN
8.2 Exclusión 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
región crítica para hacer lecturas. Entonces para proteger los datos en las escrituras
hay que usar otros semáforos. Cada vez que se quiera hacer una escritura a los
datos, como por ejemplo cuando se guarda las políticas del firewall dentro de la
estructura, se debe usar estas funciones:
#define br_write_lock_bh(idx) \
do { local_bh_disable(); br_write_lock(idx); } while (0)
...
...
#define br_write_unlock_bh(idx) \
do { br_write_unlock(idx); local_bh_enable(); } while (0)
La primera función protege la región crítica de ser escrita y también de que no
se lea. Tiene un control total de los datos. Y la segunda operación desprotege la
región crítica y permite el acceso a los datos para el siguiente proceso. Como es
lógico no se puede poner una de estas funciones sin la otra, una activa el semáforo
y el otro lo desactiva. Y es muy importante que el uso de este proceso sea mínimo
para no afectar al sistema haciendo que vaya más lento, y cuando se tenga que
usar las operaciones que contenga tienen que ser pocas y rápidas.
Así por ejemplo cuando se tenga que eliminar las políticas, lo que se llama
hacerle un flush de los datos, se debería de programar algo parecido a esto:
br_write_lock_bh(BR_NETPROTO_LOCK);
..
-Región CríticaAcceso escritura
..
br_write_unlock_bh(BR_NETPROTO_LOCK);
Y dentro de la región crítica se puede escribir a los datos porque nadie más accede
a ellos. Hay un ejemplo de este mecanismo, se encuentra en net/core/dev.c y se usa
138
8 DISEÑO DE LA APLICACIÓN
8.3 Filtrado de paquetes
para hacer una llamada a una función y hacer que esta sea atómica con respecto a
las capas de protocolos.
void net_call_rx_atomic(void (*fn)(void))
{
br_write_lock_bh(BR_NETPROTO_LOCK);
fn();
br_write_unlock_bh(BR_NETPROTO_LOCK);
}
Se pasa un puntero de una función por parámetros, se activa el semáforo para la
protección de escritura, se llama a la función y luego cuando esta termine se desactiva el semáforo que asegura la exclusión mutua. Esta función se llama dentro
de los drivers y hace que la función que se le pasa como parámetro sea atómica. Es
un mecanismo que ofrece el kernel para los desarrolladores de drivers. Y se debe
reusar este código, porque los desarrolladores del kernel ya se han asegurado que
sea portable dentro de cada una de las distintas arquitecturas. Y dependiendo de
la arquitectura para donde se compila el kernel , hace unas funciones u otras. En
cambio si tuviese que montarme los semáforos, serían poco portables.
8.3. Filtrado de paquetes
El objetivo es poder insertar políticas de seguridad donde se pueda distinguir
para cada paquete si entra o si sale, la interfaz y la información de la cabecera
IP. La solución planteada es poner solamente cuatro hooks: uno en la entrada a la
interfaz de entrada, otro a la salida de la interfaz de entrada, otro a la entrada de la
interfaz de salida y el último a la salida de la interfaz de salida. Cada uno de ellos
captura el sk_buff y se indica qué hook al hacer la llamada mediante las 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 aplicación MyWall, INPUTINT o bien OUTPUTINT según sea la
interfaz de entrada o la interfaz de salida, y el IN o bien el OUT indica si es de
entrada o salida respecto esa interfaz. La información de la interfaz está dentro
de la estructura sk_buff, en el apartado dev, que indica de qué interfaz se trata.
139
8 DISEÑO DE LA APLICACIÓN
8.3 Filtrado de paquetes
Que conjuntamente con la cabecera ip nos indica toda la información necesaria
para filtrar, a la cabecera IP se puede acceder mediante iphdr dentro de sk_buff (la
estructura sk_buff se encuentra detallada en el Anexo A).
8.3.1. ip_input.c
El hook de entrada el filtro tiene que estar situada allá donde todos los paquetes
pasen por ella al entrar en el sistema operativo, entonces el mejor lugar es justo
después de hacer los chequeos a la cabecera IP, allí se inserta la función que llama
al filtro. Si el resultado de la búsqueda es eliminar el paquete entonces se elimina
y sino pues se deja estar y contina el camino del skbuff.
El primer sitio donde poner el filtro es en el fichero net/ipv4/ip_input.c justo
donde se termine la función ip_rcv:
/*
* Main IP Receive routine.
*/
int ip_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *
{
...
...
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
8 DISEÑO DE LA APLICACIÓN
8.3 Filtrado de paquetes
}
#ifdef CONFIG_MYWALL
// Filtro de entrada
// MW_INPUTINT_IN
...
#endif
Las órdenes de #ifdef y de #endif se usan para proteger el resto del código, en caso
de compilar el kernel sin las opcciones de mi filtro (llamado mywall) el compilador extraería las líneas de código que hay entre las definiciones. Pero si alguien
desea incluir este firewall dentro de su kernel, entonces incluye los ficheros de
CONFIG_MYWALL y el compilador deja el código tal cual, apareciendo las funciones que estén incluidas dentro de la definición.
8.3.2. ip_forward.c
Aquí se disponen dos hooks, el primero se situa para la salida del paquete de la
interfaz de entrada al ordenador y el segundo se dispone para la entrada del paquete a la interfaz de salida. Que corresponden a las constantes MW_INTPUTINT_OUT
y para MY_OUTPUTINT_IN. Están situados en el fichero net/ipv4/ip_forward.c,
en la función ip_forward(skb). El primero antes de decidir el destino del paquete,
y el segundo hook antes de redirigirlo a la segunda interfaz.
int ip_forward(struct sk_buff *skb)
{
struct net_device *dev2; /* Output device */
struct iphdr *iph;
/* Our header */
struct rtable *rt;
...
#ifdef CONFIG_MYWALL
// Filtro MW_INPUTINT_OUT
...
#endif
iph = skb->nh.iph;
141
/* Route we use */
8 DISEÑO DE LA APLICACIÓN
8.3 Filtrado de paquetes
rt = (struct rtable*)skb->dst;
...
#ifdef CONFIG_MYWALL
// 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, operación que realiza el sistema operativo, si el TTL es menor que cero se
devuelve un ICMP indicando que el tiempo de vida del paquete ha expirado.
8.3.3. ip_output.c
Para el caso del filtro de salida el fichero donde se implementa es el net/ipv4/ip_output.c
y se debe introducir justo antes de que el mensaje sea enviado a la cola de mensajes. Esta función es la ip_build_and_send_pkt:
int ip_build_and_send_pkt(struct sk_buff *skb,
struct sock *sk, u32 saddr,
u32 daddr, struct ip_options *opt)
{
...
ip_send_check(iph);
#ifdef CONFIG_MYWALL
// Filtro de salida
// MW_OUTPUTINT_OUT
...
#endif
/* Send it out. */
return output_maybe_reroute(skb);
}
142
8 DISEÑO DE LA APLICACIÓN
8.3 Filtrado de paquetes
Cuando se envie el puntero del skbuff al filtro se marcará como que se ha capturado saliendo, así se consigue la información que se desea.
8.3.4. El sk_buff
El sk_buff es una estructra de datos donde los sistemas UNIX guardan los
datos [WS2], es la forma que tienen de encapsular la información, se usa para
describir el movimiento de los datos de red entre las capas de los protocolos. La
definición de la estructura de datos es muy importante, es la representación de
todos los datos, y siempre que se quiera acceder o realizar alguna operación a los
datos de red se debe hacer a través de esta estructura. La definición se encuentra
en include/linux/skbuff.h y la implementación de las funciones se encuentra en
net/core/skbuff.c. La estructura de datos del sk_buff se puede encontrar en el anexo
A.
Paso a describir unas cuantas funciones disponibles para tratar los sk_buff.
alloc_skb: Crea espacio para un nuevo network buffer, donde se le pasa el tamaño
y la máscara. Y retorna un puntero al nuevo buffer.
struct sk_buff *alloc_skb(unsigned int size,int gfp_mask)
kfree_skbmem: Libera un skbuff pero no quita el estado de este.
void kfree_skbmem(struct sk_buff *skb)
kfree_skb: Libera un sk_buff y libera cualquier dato adjunto al buffer. Este sí que
borra el estado del buffer.
void kfree_skb(struct sk_buff *skb)
skb_copy_bits: Vuelca algunos datos del skb a un buffer del kernel. Se indica el
offset, un puntero a donde copiar los datos y cuántos datos copiar.
int skb_copy_bits(const struct sk_buff *skb, int offset, void *to, int len)
143
8 DISEÑO DE LA APLICACIÓN
8.3 Filtrado de paquetes
8.3.5. Operaciones
Sabemos como recoger una estructura sk_buff, sabemos dónde hacerlo y como
podemos modificar los dato o acceder a ellos. Ahora falta explicar qué se hace con
dicha estructura. Como se ha planteado un sistema de solo dos hooks había dos
lugares donde podía suceder o bien que no cumpliese con las normas de seguridad
o bien que sí las cumpliese.
Cuando tenemos un paquete que está entrando y se captura en ip_input.c
en la función iprcv( ) el buffer debe ser destruido con la función kfree_skb( )
o bien debe pasarse el buffer a la función ip_rcv_finish( ) que se encuentra en
net/ipv4/ip_input.c:
static inline int ip_rcv_finish(struct skbuff * skb)
void kfree_skb(struct sk_buff *skb)
En el caso de eliminarse debe ser porque en la lista de políticas concordaba algún
drop. En el segundo caso es porque habría llegado a un pass.
Cuando el paquete está saliendo del sistema y se ha capturado en ip_output.c
dentro de la función ip_fragment( ) el paquete debe ser eliminado usando la función kfree_skb( ) si no pasa las políticas de seguridad o bien debe enviarse a la pila
de salida mediante la función IP_INC_STATS( )
void kfree_skb(struct sk_buff *skb)
144
9 IMPLEMENTACIÓN DEL FIREWALL
9. Implementación del firewall
En este capítulo se narra los resultados conseguidos después del desarrollo,
como los problemas y las experiencias más importantes tanto a la hora de debugar
como a la hora de tratar con los semáforos. Después se explica como montar
un escenario para poder probar el firewall y por último los resultados de dicho
escenario.
9.1. Desarrollo
El desarrollo de las aplicaciones dentro del kernel como ya se ha comentado es
tedioso, laborioso y un proceso largo. Este es el resultado del proceso de trabajo.
9.1.1. Debugar
Todas las formas de debugar que he mostrado son muy útiles, pero hay escenarios que son más dificiles de probar. Por ejemplo, tenía que probar como el
firewall bloquea paquetes, no solo que le llegan a él y los bloquea cuando debe,
sino que además tiene que enviarlos a otras interfaces correctamente cuando no
debe bloquearlos. El proceso es el siguiente: nada más entrar el paquete tiene que
pasar, las políticas del firewall, después ir al servicio routed, que es el demonio
encargado de dirigir los paquetes a la interfaz adecuada según su dirección ip destino. Tras pasar por este servicio los paquetes deben pasar otra vez por el firewall
y sus políticas.
No es factible trabajar con un kernel inestable y a la vez usar el mismo para
guardar los cambios. Es necesario trabajar como mínimo con una máquina 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 máquina
virtual. Porque la máquina virtual solo dispone de una interfaz ethernet, y no se
puede hacer un forward por no tiene sentido un paquete que entra y vuelve a salir
por la misma interfaz.
La solución a la que se llega es configurar otro ordenador y probar el kernel
en el otro ordenador, se edita el kernel en un ordenador y se hace las pruebas en el
otro, pero aparece otro problema: el ordenador que tenemos haciendo las pruebas
145
9 IMPLEMENTACIÓN DEL FIREWALL
9.1 Desarrollo
se conecta mediante la ethernet al primer ordenador, y precisamente esa parte del
kernel la que se está modificando y la que es más inestable, así que no tenemos
ninguna garantía que llegue correctamente el paquete aunque solo sea para entrar
en la consola y ver como está trabajando el kernel recién compilado. Por lo que
hay que conectar las dos máquinas como se ha explicado en el capítulo de hacking
el kernel, en el apartado de debugando con dos máquinas.
Pruebas
Desarrollo
Cable serie
Debugador + Consola
Firewall
Router
Salida
Cable Ethernet
NIC
Paquetes IP
NIC 1
NIC 2
9.1.2. Semáforos
Cuando se trata los paquetes por el sistema operativo dentro del net/ipv4/ip_input.c,
y tras pasar los chequeos simples sobre la cabecera para comprovar la integridad
de los datos y otros chequeos, se recoge el paquete por el filtro y se pasa las políticas. Al llamar a la función para recoger la estructura sk_buff, al principio de todo
lo que hice fue que me mostrará la información de cabecera IP del paquete que me
acaban de pasar. Algo sencillo, simplemente pasar por el printk la IP origen, la IP
destino y alguna información más de poca importancia. La cuestión era averiguar
si capturaba todos los paquetes, como trabajar con las estructuras sk_buff y entonces empezar a implementar las listas y las comparaciones que había diseñado con
el UML. Este era el código que pretendía implementar dentro de mi función:
// Imprime la info del sk_buff:
//
//
//
N. de protocolo;
IP origen : puerto origen;
IP destino : puerto destino;
//
//
tamaño total; Tipo de Servicio
id; fragment offset; time to live
146
9 IMPLEMENTACIÓN DEL FIREWALL
9.1 Desarrollo
//
y que muestre los datos del sk_buff
printk("PROTO= %d %u. %u. %u. %u: %hu %u. %u. %u. %u: %hu"
" L= %hu S=0x %2.2hX I= %hu F=0x %4.4hX T= %hu",
ip->protocol, NIPQUAD(ip->saddr),
src_port, NIPQUAD(ip->daddr),
dst_port,
ntohs(ip->tot_len), ip->tos, ntohs(ip->id),
ntohs(ip->frag_off), ip->ttl);
for (opti = 0; opti < (ip->ihl - sizeof(struct iphdr) / 4); opti++)
printk(" O=0x %8.8X", *opt++);
printk("\n");
Llegados a este caso me dispuse a compilar el kernel, lo cargue en la máquina
virtual y la arranqué con el nuevo kernel recién compilado. Cual fue mi sorpresa
que nada más intentar hacer un login como cualquier usuario el ordenador me daba
un kernel panic y tenia que reiniciar la máquina. Era extraño porque se colgaba
solo cuando hacia el login dentro de una consola. Si ni siquiera pasa por la tarjeta,
no son datos que se reciban por ip. O al menos esa es una idea que puede pensarse
erroneamente. Entonces decidí pasar a intentar entrar remotamente mediante una
sesión Telnet o bien mediante una sesión SSH, cual fue mi sorpresa que nada mas
conectarse el ordenador me mostraba por la pantalla de consola un kernel panic. Y
claro a cada kernel panic que hacía pues tenía que reiniciar la máquina virtual otra
vez, luego hacía un chequeo del sistema de ficheros para comprobar que estaba
correcto, tardaba mucho tiempo y no hacía nada.
Por qué me daba aquel kernel panic si lo único que estaba haciendo era mostrar por pantalla y por el sistema de ficheros de log unos simples mensajes, algo
que por separado había funcionado perfectamente. Entonces había que instalar el
debuggador, hacerle un trace por el kernel y averiguar qué demonios le estaba pasando. No voy a explicar como debugué el kernel, pues hay un capítulo entero que
habla de ello. Pero lo que averigüé era que estaba dando errores cada vez que accedia a los datos del sk_buff que le estaba pasando. No había protegido el acceso
a los datos con ningún spinlock! grave error que me había supuesto una semana
entera de trabajo!
147
9 IMPLEMENTACIÓN DEL FIREWALL
9.2 Escenario
Las conclusiones a las que llegué fueron varias: había aprendido, a parte que
me estaba dando cuenta de donde me había metido, primero la importancia que
tenían los semáforos, tenía que aprender como funcionaban y luego como los
debía utilizar. Segundo que cada vez que alguien se conectaba mediante la consola
de pantalla lo estaba haciendo mediante TCP/IP y que todo paquete que bloquease
en un futuro me prohibiría acceder por el mismo puerto de consola. Tercero, que
el kernel a la mínima sospecha que tiene de que se está incumpliendo la calidad de
preemptivo hace un kernel panic, antes de que se dañe cualquier aparato hardware.
Cuarto, en realidad no se mueve los datos de la estructura sk_buff, solo se copia
el puntero que apunta a ella, por lo que cada vez que llega un paquete o se trata
cualquier paquete esta estructura esta siendo accedida lo que significa que hay que
protegerla mediante un semáforo, así que siempre que se accede a datos protegidos
con semáforos las operaciones tiene que ser lo más rápido que se pueda. Estas son
las conclusiones a las que llegué, puede que estén equivocadas, pero lo dudo.
Pero me había servido para algo: me había dado cuenta de la importancia de los
semáforos y había aprendido a debugar el kernel.
Cuando le puse la protección adecuada el sistema operativo pasó a funcionar
perfectamente. Al acceder mediante consola me daba el siguiente mensaje en el
syslog:
PROTO=17 127.0.0.1:745 127.0.0.1:111 L=84 S=0x00 I=0 F=0x4000 T=64
Lo que me daba la razón a la primera hipótesis: al acceder mediante consola lo hace usando TCP/IP y se envía paquetes del puerto 745 al 111. Por otra parte ahora
se podía acceder mediante SSH y mediante Telnets, funcionaba todo 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 IMPLEMENTACIÓN DEL FIREWALL
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 algún equipo que nos retorne los paquetes. Es necesario montar
ordenador con una tarjeta Ethernet, otro ordenador con dos tarjetas de red y un
router con al menos una entrada Ethernet. Se conectan los ordenadores formando
una red (RedA) y otra red entre el segundo ordenador y el router (RedB).
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 añaden las líneas
necesarias en la configuración del lilo, y se ejecuta el lilo y se rebota la máquina.
Todos estos procesos están correctamente explicados en la parte teórica.
9.2.3. Configurar el firewall
Una vez arrancado el ordenador donde reside el nuevo kernel con el firewall, hay que editar el fichero de configuración del firewall. Este fichero es el
/etc/mywall.conf. En este fichero se definen los comentarios con las líneas que
empiezan con un ’#’ y entonces cada línea corresponde a una política del firewall.
149
9 IMPLEMENTACIÓN DEL FIREWALL
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
dirección IP origen con su máscara o bien any para todas las ip, después se indica
el número de puerto origen, y se repite con la dirección IP destino con su respectiva máscara o bien con un any para indicar cualquier IP destino, luego viene el
número de puerto destino y si se bloquea o no el paquete y al final si se hace un
log cuando se case con éxito la regla.
Esta sintaxis permite filtrar por interfaz y el sentido respecto esta. Permite
filtrar por IP destino o IP origen y también por número de puerto, o bien ambos
conjuntamente.
Insertar entonces en el fichero /etc/mywall.conf las siguientes líneas:
#
# nombre int
#
sentido
IPorig
interfaz eth0 entrada
interfaz eth0 entrada
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 página web y el Telnet de la máquina
10.1.0.2. Una vez guardada se ejecuta la orden:
mywall -F -f /etc/mywall.conf
El -F hace un flush de los datos actuales y el -f indica el fichero donde están
las configuraciones.
150
9 IMPLEMENTACIÓN DEL FIREWALL
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 través del ordenador firewall. Así
que podemos poner los números de red:
RedA 10.2.0.0/16
RedB 10.1.0.0/16
Primer ordenador: eth0 10.2.0.1 máscara 255.255.0.0
Segundo ordenador: eth0 10.2.0.2 máscara 255.255.0.0
eth1 10.1.0.2 máscara 255.255.0.0
Router: eth0 10.1.0.1 máscara 255.255.0.0
ruta estática a 10.2.0.0 / 16 por 10.1.0.2
En el router se ha activado el servidor web y un servidor telnet. También es recomendable que se le active algún otro servicio, que servirá para comprobar como
el firewall bloquea el puerto y no se recive ningún paquete de dichos servicios, ya
que el firewall habría bloqueado la salida.
9.2.5. Resultados
Los resultado se pueden observar porque debería de haber bloqueado todas las
conexiones exceptuando las dos comentadas anteriormente y porque al poner la
orden:
mywall -s
Se ve una tabla con todas las estadísticas parecida a esta:
MyWall un Firewall de Carlos Morales.
paquetes IP eliminados: 30
paquetes IP chequeados: 91
paqutes input: 51 bloqueados: 30 pasados: 21
paquetes output: 40 bloqueados: 0 pasados: 40
...
Como puede observarse, algunos de los paquetes que son input son eliminados y
otros no. Si se sigue probando los contadores deben ir aumentando de valor.
151
10 CONCLUSIONES
10. Conclusiones
La primera conclusión a la que se llega es que muy poca gente se ha atrevido
a entrar dentro del kernel y programar cualquier algoritmo dentro de él, y por lo
tanto, la documentación al respecto es escasísima, no hay ningún documento en
castellano a parte de este trabajo. Casi todos los documentos tan solo se encuentran
en Internet, y los temas tan específicos como la creación de un firewall solo puede
averiguarse preguntando a los desarrolladores del kernel, pero teniendo en cuenta
que es un grupo que no facilitan aquella información que consideran trivial, se
hace más difícil el aprendizaje.
Otra conclusión a la que se llega es que trabajar dentro de un sistema operativo
es una tarea muy compleja. Cada vez que se efectúa algún cambio por pequeño
que sea hay que recompilar todo el kernel, instalarlo y rebotar la máquina con el
nuevo sistema operativo. Tampoco se puede trabajar sobre un kernel y probarlo
a la vez sobre la misma máquina, ya que un kernel en desarrollo puede dañar
los datos guardados en disco facilmente. Y como no hay ningún mecanismo que
proteja al sistema operativo de hacer operaciones ilegales cuando hace un core
dump se para toda la máquina siendo muy dificil hacer un diagnóstico de lo que
ha pasado. Por todas estas razones es importante aprender como se se ejecuta un
kernel en desarrollo en una máquina virtual o en otra máquina conectada a la
desarrollo y a la vez también como poder debugar este kernel en desarrollo.
La programación dentro del kernel debe hacerse con sumo cuidado. Toda estructura que se cree y que puede ser accedida por varios threads a la vez debe
protegerse con semáforos. El kernel dispone de funciones para llamar a los semáforos, donde se puede indicar si se desea una protección de lectura o de escritura.
Si no se cumplen con la teoría de los semáforos lo más lógico es que de un kernel
panic y se pare el kernel cuando se está accediendo desde dos lugarles a la misma
estructura de datos. También es importante tener el mínimo número de variables
estáticas, pues ocupan un espacio vital dentro del kernel. Toda estructura debe
hacerse dinámica, y aquí el kernel también dispone de funciones para crear listas
dinámicas de una forma muy sencilla.
Lo más laborioso ha sido resolver estos problemas de trabajo dentro del kernel
y hacer el montaje del escenario para hacer las pruebas. Para bloquear había que
152
10 CONCLUSIONES
probar que ciertos paquetes pasaban las políticas y la respuesta también retornaba.
Para ello se ha necesitado de tres ordendores, uno emitiendo, otro haciendo de
firewall y el último con algún servicio generando respuestas a las peticiones del
primero.
Al final el objetivo principal se ha cumplido que era crear un firewall a partir
de cero que permitiera filtrar los paquetes por dirección IP origen y destino, por el
puerto origen y destino, y todo según la interfaz y el sentido respecto ella.
153
11 LÍNEAS DE FUTURO
11. Líneas de futuro
Una vez conseguido bloquear paquetes IP según su dirección IP origen y su
dirección IP destino se puede añadir nuevas funcionalidades que otros firewalls
más complejos tienen, estas funcionalidades son seguimiento de sesiones, NAT y
balanceo de carga entre varios firewalls.
El seguimiento de sesiones trata de guardar todas las conexiones que se están
mantiniendo en ese momento y con las políticas de filtrado tratar los nuevos paquetes. Ciertos protocolos, como por ejemplo FTP, H323 entre otros mantienen en
sus conexiones unas sesiones características debido a que el cliente y servidor hacen los dos funciones de cliente y de servidor. Tiene un coste aproximado de 500
horas y con los conocimientos necesarios de sistemas operativos y de telemática
puede ser un TFC.
Muchos firewalls son los encargados de hacer NAT (Traducción de direcciones), ya que están 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 difícil hacer un ataque spoofing emulando un ordenador interno.
Para hacer NAT se debe mantener también información de todas las sesiones en
curso mediante unas tablas. Donde se guarda todas las sesiones en curso y las traducciones que se estén usando. Es un proyecto con un coste aproximado de 600
horas, y también puede ser un TFC.
La tercera propuesta es hacer un balanceo de carga entre firewalls. El problema de los firewalls es que la mayoría no están duplicados y no hay reduntancia, y
los que disponen de ella son muy caros. La propuesta es balancear las conexiones
entre varios firewalls y para su correcto funcionamiento es necesario mantener el
seguimiento de las sesiones y NAT entre los diferentes firewalls. Hay que montar
un mecanismo entre las máquinas donde se puedan comunicar de forma segura
y poder cambiar información de las tablas de sesiones. Esta propuesta es mucho
más avanzada y compleja, no solo son necesarios conocimientos de sistemas operativos y de telemática, sino que es neceario tener conocimientos de arquitecturas
avanzadas y de programación paralela. El coste es aproximadamente de unas 1000
horas y podría hacerse en un PFC por varias personas.
154
12 COSTE DEL TRABAJO
12. Coste del trabajo
El coste del proyecto se divide en documentación sobre firewalls, documentación UML, documentación sobre el kernel de linux, pruebas programando y
debugando el kernel, programación de la aplicación, experimentación y pruebas
de su correcto funcionamiento y por último la memoria.
Se considera documentación sobre firewalls la búsqueda de la información
sobre los protocolos TCP/IP y sobre los firewalls. La documentación UML se
basa en el estudio de la metodologia del UML. Por último la documentación del
kernel de linux se enfocó para averiguar cómo trabajar dentro del kernel.
La parte práctica comprende las pruebas programando y debugando el kernel,
donde se ponía en práctica todo lo leído referente a la programación dentro del
kernel, de su debugado y del montaje del escenario para su funcionamiento. La
programación de la aplicación es el tiempo destinado a la construcción del 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 preparación
de la memoria.
155
12 COSTE DEL TRABAJO
Teoría
Práctica
Memoria
Tema
Horas
Porcentaje
Firewalls
40 h
6,2 %
UML
Kernel
60 h
140 h
9,3 %
21,6 %
Total Teoría
240 h
37,1 %
Estudio del Kernel
Programar Firewall
180 h
65 h
27,9 %
10 %
Implementación escenarios
22 h
3,4 %
Total Práctica
267 h
41,3 %
Total Memoria
140 h
21,6 %
Total
647 h
100,0 %
156
12 COSTE DEL TRABAJO
Bibliografía
[ALS] RUBINI , A LESSANDRO ; Linux Device Drivers, 2nd Edition; O’Relly;
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
12 COSTE DEL TRABAJO
[RU1] RUSSELL , PAUL; Unreliable Guide to Hacking The Linux Kernel;
http://www.netfilter.org/unreliable-guides/
[RU2] RUSSELL , PAUL; Kernel Locking Guide;
http://www.netfilter.org/unreliable-guides/
[RU3] RUSSELL , PAUL; Linux 2.4 Packet Filtering HOWTO;
http://www.netfilter.org/unreliable-guides/
[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 continuación se pasa a detallar la estructura del sk_buff. La estructura de
un socket buffer se encuentra en include/linux/skbuff.h y se puede acceder a ella a
través de <linux/skbuff.h>, está formada por:
struct sk_buff {
struct sk_buff
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 tamaño del skb.
head : puntero al principio del buffer
data : puntero al principio del dato.
tail : puntero al final del dato.
end : final del puntero
destructor : destructor de la funcion
nfcache : info de la cache interna referente a netfilter
nfct : conexion asociada al socket
162
Parte IV
Anexo B Coding Style
Existen unas reglas básicas, escritas y no escritas, para asegurarse que otros
usuarios del kernel. Existe unas reglas escritas en la propia documentación de Linux [KE1] y otras reglas no escritas [KRO] pero que se supone todo programador
conoce.
Como el número de desarrolladores que miran el código fuente del kernel de
Linux es muy grande, lo mejor es tener una guía consistente a seguir. Así es más
fácil entender para cualquiera que lea el kernel lo que se ha insertado, lo que hace
que puedan entenderlo mejor y corregir posibles fallos o mejorar el código. Que
es eso de lo que se trata todo esto del código abierto o open-source.
Indexación
Todos los tabulados son ocho carácteres en blanco y será eso el caracter <TAB>.
Hace que sea más facil localizar donde están los diferentes bloques de código. Hay
que intentar evitar que haya más de tres niveles de indexación, ya que puede causar que navegar por el código sea muy incómodo, pues las líneas sobrepasan el
tamaño de la pantalla.
Poniendo corchetes
Los autores originales de UNIX ponían los corchetes con el corchete que abre
al final de la primera línea y el corchete que cierra al principio de la última línea:
if ( x >= 1 ) {
hacer_lo_que_sea();
}
Por eso, el kernel de Linux usa este estilo. La única excepción a esta regla son
las funciones, las cuales se tienen el corchete que abre al principio de la segunda
línea:
163
int funcion_cool( int x)
{
cuerpo de la funcion
}
Un buen ejemplo a seguir son los ficheros que hay en el directorio kernel del
código fuente.
Nombrar variables y funciones
Para nombrar las variables y funciones deberían ser descriptivas y concisas. No
usar nombres largos y bonitos como por ejemplo CommandAllocationGroupSize
o por ejemplo DAC_V1_EnableMemoryMailboxInterface(), en vez de eso usar
cmp_group_size o bien enable_mem_mailbox().
Las variables globales es mejor no usarlas, solo hacerlo si es absolutamente
necesario. Las variables locales deberían ser cortas. Para las variables de los bucles puede usarse ’i’ o ’j’, mientras que ’contador_bucle’ es demasiado largo. Las
variables del tipo ’tmp’ también se permiten pero solo para variables con poco
tiempo de vida.
También se puede encontar buenos ejemplos en el los ficheros del sistema de
ficheros en fs/*.c. Y ejemplos que son negativos también pueden encontrarse en
drivers/scsi/cpqfs* .
Funciones
Las funciones deben hacer solo una cosa y hacerla bien. Deberían ser cortas y
ser del tamaño de uno o dos pantallas. Si se tiene una función que hace pequeñas
cosas para muchos casos, es aceptable que sea larga. Pero si es larga y además es
compleja hay que modificarla.
Dicen que el número de variables nos indica la complejidad de la función. Así
que si se tiene un gran número de variables entonces es que hay q cambiarlo.
164
Comentarios
Los comentarios malos explican como trabaja el código, quien escribió tal función en una fecha específica y otras cosas poco útiles. Los comentarios correctos
deben explicar qué hace la función y porqué lo hace. Deberían incluirse al principio de la función y no necesariamente dentro de ella, porque hay que escribir
funciones pequeñas.
Hay un estadar para los comentarios de las funciones, que es una variante del
método de documentación usada en el proyecto GNOME. Lo bueno de usar este
tipo de estilo es que luego se puede sacar información usando compiladores de documentacion. Que puede verse ejecutando ’make psdocs’ o bien ’make htmldocs’
para generar un fichero postcript o html para cada caso. Para más información
mirar Documentation/kernel-doc-nano-HOWTO.txt.
Tipos de estructuras de datos
Si se crea cualquier estructura de dato donde pueda accederse desde fuera por
un thread o por cualquier otro procedimiento hay que implementar un contador de
referencias. Si se añade un contador de referencias una estructura, se evitan 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 automáticamente, dependiendo donde se compile y de la
arquitectura usará unas funciones u otras.
Listas
Como en cualquier programa se necesitan las listas dinámicas. Para eso debe
usarse las funciones include/linux/list.h. Donde se puede encontrar una estructura: ’struct list_head’, que deberñia incluirse dentro de la estructura donde se desee
crear la lista. Entonces se podrá usar las funciones de añadir, borrar o iterar sobre
las listas de manera fácil sin tener que reescribir nuevo código. Algunos buenos
ejemplos que he encontrado están en drivers/hotpluc/pci_hotplug_core.c y en drivers/ieee1934/nodemgr.c.
typdef está prohibido
Los famosos typedef no deberián usarse para llamar a ningún tipo de estructura. La mayoria de las estructuras del kernel no tienen ningún typedef. Ya que hace
más oscuro el código porque se añaden capas, y no dejan que el programador sepa
qué tipo de dato se esta usando.
Jamás usar un typedef para significar un puntero a una estructura. Esto esconde
el puntero y entonces pueden aparecer muchos problemas, como por ejemplo que
no se pide memoria correctamente, que se accede a partes de la memoria donde
no se debe, y esta es la forma más fácil de conseguir un kernel panic.
El único lugar donde los typedef son aceptables es al declarar prototipos de
funciones. Estas pueden ser difíciles de escribir, asi que haciendo un typedef para
estas se convierte en una forma fácil de escribir.
166

Top subcategories

Top subcategories

Top subcategories

Top subcategories

Top subcategories

Top subcategories

Top subcategories

Download Estudio, diseño e implementación de un Firewall