TFC Is06200

Estudio, diseo e implementacin de un Firewall
C ARLOS G USTAVO M ORALES T EJEDA

Septiembre 2002
Abstracto
Los rewall son los componentes ms importantes a la hora de proteger una red de datos, ya que se encargan de ltrar los datos que pasan a travs de l. El objetivo de este TFC es crear un rewall de ltrado de paquetes bajo un entorno Unix. La dicultad reside en la programacin a bajo nivel dentro del sistema operativo, en la que cualquier error de programacin supone una parada del ordenador y porque toda modicacin requiere compilar el kernel de nuevo y rebotar la mquina donde se est ejecutando el rewall
Resumen
Un rewall es el componente ms importante a la hora de proteger una red de ordenadores. Es un sistema incorporado dentro del sistema operativo, encargado de ltrar los datos que pasan a travs de l. El objetivo de este proyecto es hacer un estudio terico de los rewalls en un entorno Unix-Linux, para luego poder disear e implementar uno. As pues, esta memoria est dividida principalmente en dos partes: una parte terica y una prctica. Dentro de la parte terica hay un breve estudio de los protocolos TCP/IP, que son los protocolos que usan las redes de datos. El siguiente tema es una introcucin a los rewalls, donde se narra las caractersticas y los posibles tipos de rewalls. Se hace un especial incapi en el ltrado de paquetes pues se le dedica un captulo entero ya que es el tipo de rewall que se va a implementar. Los rewalls de ltrado de paquetes se basan en las cabeceras de los paquetes de datos para decidir si deben ltrarse. En el siguiente captulo se repasa el sistema operativo Linux ya que la programacin del rewall va muy ligado con este. Hay un resumen de sus caractersticas principales, de las herramientas que disponemos y del viaje que realiza un paquete desde que se captura en la misma tarjeta de red hasta que llega a las apliaciones de los usuarios. El ltimo captulo es un estudio del diseo, para poder modelar correctamente cualquier proyecto. La programacin dentro del sistema operativo es muy compleja, llamado hacking del kernel, ya que es la parte que se encarga de controlar el ordenador, y cualquier fallo signica la parada absoluta del mismo, por eso se hace necesario poder averiguar que hace en todo momento el kernel mientras se est ejecutando. El siguiente captulo aborda el diseo de la aplicacin, que comprende tanto los esquemas del modelado como la explicacin de como se ha programado el rewall. Despus hay un captulo llamado implementacin del rewall, donde se explican los escenarios que se ha necesitado tanto para desarrollar como para probar los resultados nales. Los ltimos captulos comprenden las conclusiones, las lneas de futuro que pueden seguirse, el coste del proyecto y la bibliografa que se ha necesitado.
ndice
I Teora
1. Introduccin 2. TCP/IP 2.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1. Capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2. Encapsulacin . . . . . . . . . . . . . . . . . . . . . . . 2.2. IP: Internet Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2. Cabecera IP . . . . . . . . . . . . . . . . . . . . . . . . . 2.3. UDP: User Datagram Protocol . . . . . . . . . . . . . . . . . . . 2.3.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2. Cabecera UDP . . . . . . . . . . . . . . . . . . . . . . . 2.4. TCP: Transmisin Control Protocol . . . . . . . . . . . . . . . . 2.4.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2. Cabecera TCP . . . . . . . . . . . . . . . . . . . . . . . 3. Introduccin a los rewalls 3.1. Qu es un Firewall? . . . . . . . . . . . . . . . . . . . . . . . . 3.2. Qu puede hacer . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1. Donde localizar las decisiones . . . . . . . . . . . . . . . 3.2.2. Refuerza polticas . . . . . . . . . . . . . . . . . . . . . . 3.2.3. Registrar la actividad . . . . . . . . . . . . . . . . . . . . 3.2.4. Limita la exposicin . . . . . . . . . . . . . . . . . . . . 3.3. Qu no puede hacer . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1. Dentro de la red . . . . . . . . . . . . . . . . . . . . . . . 3.3.2. Conexiones que no van a travs de l . . . . . . . . . . . 3.3.3. Virus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4. Tipos de Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1. Filtrado de paquetes . . . . . . . . . . . . . . . . . . . .
1
1 2 2 2 4 5 5 6 9 9 9 10 10 12 15 15 16 16 16 16 16 17 17 17 17 18 18
3.4.2. Servicios proxy . . . . . . . . . . . . . . . . . . . . . . . 3.4.3. Combinacin de tcnicas . . . . . . . . . . . . . . . . . . 3.5. Arquitecturas Firewall . . . . . . . . . . . . . . . . . . . . . . . 3.5.1. Dual-Homed Host . . . . . . . . . . . . . . . . . . . . . 3.5.2. Screened Host . . . . . . . . . . . . . . . . . . . . . . . 3.5.3. Screened Subnet . . . . . . . . . . . . . . . . . . . . . . 3.5.4. Variaciones posibles . . . . . . . . . . . . . . . . . . . . 4. Filtrado de paquetes 4.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2. Caractersticas . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3. Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1. Proteger toda la red . . . . . . . . . . . . . . . . . . . . . 4.3.2. Transparencia . . . . . . . . . . . . . . . . . . . . . . . . 4.3.3. Disponibilidad . . . . . . . . . . . . . . . . . . . . . . . 4.3.4. Latencia . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4. Desventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1. Protocolos difciles . . . . . . . . . . . . . . . . . . . . . 4.4.2. Poltcas que no pueden aplicarse . . . . . . . . . . . . . 4.4.3. Spoong . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5. Conguracin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1. Bidireccionalidad . . . . . . . . . . . . . . . . . . . . . . 4.5.2. Inbound y Outbound . . . . . . . . . . . . . . . . . . 4.5.3. Permitir por defecto versus denegar por defecto . . . . . .
20 21 21 22 23 24 26 28 28 29 30 30 31 31 31 32 32 33 33 33 34 34 35
4.6. Que hacer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.6.1. Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.6.2. Paquetes ICMP . . . . . . . . . . . . . . . . . . . . . . . 37 4.7. Filtrado por direccin . . . . . . . . . . . . . . . . . . . . . . . 4.7.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . 4.7.2. Riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. El Sistema Operativo Linux 5.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 39 40 42 42
5.1.1. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.3. Caractersticas . . . . . . . . . . . . . . . . . . . . . . . 5.2. El Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . 5.2.2. Modos . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.3. Mdulos . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.4. Procesos . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.5. Sincronizacin . . . . . . . . . . . . . . . . . . . . . . . 5.2.6. Comunicacin entre procesos . . . . . . . . . . . . . . . 5.2.7. Control de la Memoria . . . . . . . . . . . . . . . . . . . 5.2.8. El cdigo . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.9. Numeracin . . . . . . . . . . . . . . . . . . . . . . . . 5.2.10. Compilacin del ncleo . . . . . . . . . . . . . . . . . . 5.3. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1. Editores de texto . . . . . . . . . . . . . . . . . . . . . . 5.3.2. Herramientas de desarrollo . . . . . . . . . . . . . . . . . 5.3.3. Navegacin . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.4. Manipuladores . . . . . . . . . . . . . . . . . . . . . . . 5.3.5. Control de versiones . . . . . . . . . . . . . . . . . . . . 5.4. Netlter en los kernels 2.4 . . . . . . . . . . . . . . . . . . . . . 5.4.1. Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.2. Inconvenientes . . . . . . . . . . . . . . . . . . . . . . . 5.5. Viaje de un paquete . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . 5.5.2. Tarjeta de red . . . . . . . . . . . . . . . . . . . . . . . . 5.5.3. Proceso de red . . . . . . . . . . . . . . . . . . . . . . . 5.5.4. Softirq para NET_RX . . . . . . . . . . . . . . . . . . . 5.5.5. Tratar los paquetes IP . . . . . . . . . . . . . . . . . . . . 6. Estudio del Diseo ( UML) 6.1. Introduccin al UML . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . .
42 45 46 50 50 50 51 51 52 54 54 55 58 59 65 65 68 69 72 74 79 80 80 82 82 82 84 85 85 88 88 88
6.1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.3. Participantes en UML 1.0 . . . . . . . . . . . . . . . . . 6.1.4. reas conceptuales . . . . . . . . . . . . . . . . . . . . . 6.2. Diagramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1. Diagramas estructurales . . . . . . . . . . . . . . . . . . 6.2.2. Diagramas de comportamiento . . . . . . . . . . . . . . . 6.3. Diagramas de Objetos . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1. Oid (Object Identier) . . . . . . . . . . . . . . . . . . . 6.3.2. Caractersticas alrededor de un objeto . . . . . . . . . . . 6.4. Diagramas de Clases . . . . . . . . . . . . . . . . . . . . . . . .
89 90 91 92 94 94 95 96 97 98
6.4.1. Relaciones entre clases . . . . . . . . . . . . . . . . . . . 99 6.5. Diagramas de Caso de Uso . . . . . . . . . . . . . . . . . . . . . 101 6.5.1. Actores . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 6.6. Diagramas de Estado . . . . . . . . . . . . . . . . . . . . . . . . 103 6.6.1. Estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 6.6.2. Envo de mensajes . . . . . . . . . . . . . . . . . . . . . 104 6.6.3. Acciones . . . . . . . . . . . . . . . . . . . . . . . . . . 105 6.7. Diagramas de actividades . . . . . . . . . . . . . . . . . . . . . . 106 6.7.1. Notacin . . . . . . . . . . . . . . . . . . . . . . . . . . 107 6.8. Diagramas de Interaccin . . . . . . . . . . . . . . . . . . . . . . 108 6.8.1. Colaboracin . . . . . . . . . . . . . . . . . . . . . . . . 109 6.8.2. Interaccin . . . . . . . . . . . . . . . . . . . . . . . . . 110 6.8.3. Patrn . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 6.9. Diagramas de Componentes . . . . . . . . . . . . . . . . . . . . 110 6.9.1. Componentes . . . . . . . . . . . . . . . . . . . . . . . . 112 6.10. Diagramas de Despliegue . . . . . . . . . . . . . . . . . . . . . . 113 6.11. Los paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
II Prctica
117
7. Hacking del kernel 117 7.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 7.2. Uso del debugador . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.3. printk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 7.4. Oops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 7.5. Mquinas virtuales . . . . . . . . . . . . . . . . . . . . . . . . . 124 7.6. Debugando con dos mquinas . . . . . . . . . . . . . . . . . . . 125 8. Diseo de la aplicacin 131 8.1. Esquemas UML . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 8.1.1. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . 131 8.1.2. Diagramas de actividades . . . . . . . . . . . . . . . . . 132 8.1.3. Diagrama de secuencia . . . . . . . . . . . . . . . . . . . 135 8.2. Exclusin mutua . . . . . . . . . . . . . . . . . . . . . . . . . . 136 8.2.1. La importancia de los semforos . . . . . . . . . . . . . . 136 8.2.2. Locks de lectura . . . . . . . . . . . . . . . . . . . . . . 136 8.2.3. Locks de escritura . . . . . . . . . . . . . . . . . . . . . 138 8.3. Filtrado de paquetes . . . . . . . . . . . . . . . . . . . . . . . . . 139 8.3.1. ip_input.c . . . . . . . . . . . . . . . . . . . . . . . . . . 140 8.3.2. ip_forward.c . . . . . . . . . . . . . . . . . . . . . . . . 141 8.3.3. ip_output.c . . . . . . . . . . . . . . . . . . . . . . . . . 142 8.3.4. El sk_buff . . . . . . . . . . . . . . . . . . . . . . . . . . 143 8.3.5. Operaciones . . . . . . . . . . . . . . . . . . . . . . . . . 144 9. Implementacin del rewall 145 9.1. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 9.1.1. Debugar . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 9.1.2. Semforos . . . . . . . . . . . . . . . . . . . . . . . . . 146 9.2. Escenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 9.2.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 149 9.2.2. Compilar kernel . . . . . . . . . . . . . . . . . . . . . . 149 9.2.3. Congurar el rewall . . . . . . . . . . . . . . . . . . . . 149 9.2.4. Congurar la red . . . . . . . . . . . . . . . . . . . . . . 151 9.2.5. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . 151 10. Conclusiones 152
11. Lneas de futuro 12. Coste del trabajo
154 155
III Anexo A sk_buff IV Anexo B Coding Style
159 162
1 INTRODUCCIN
Parte I
Teora
1. Introduccin
En construccin de edicios, un muro de fuego (rewall en ingls) se disea para mantener el fuego separado de una parte de un edicio a otra. En teora, un rewall de Internet sirve con el mismo propsito: previene de peligros de Internet a la red interna. El rewall protege la red ltrando toda la informacin que pasa a travs de l y decidiendo si el trco se acepta segn las polticas de seguridad. El rewall es el elemento ms importante a la hora de asegurar una red, no es el nico ni tampoco previene de todos los posibles ataques y peligros, pero es un componente bsico. Siguiendo la comparativa de la construccin, el rewall hace la misma funcin que la puerta de nuestra casa, que solo deja pasar a las personas que tengan una llave que corresponda con la cerradura, al resto de personas no les dejar entrar. Igual que en cualquier casa tener una puerta muy segura no implica que sea segura, pueden haber otras amenazas como incendios, puertas traseras, etc. Pero una buena puerta sigue siendo el elemento ms importante y un componente bsico. El objetivo de este trabajo es construir un rewall desde cero. El rewall debe insertarse dentro del sistema operativo, ltrar los paquetes IPv4 segn la direccin origen y destino, segn el nmero de puerto origen y destino, segn la interfaz y el sentido del paquete respecto esa misma interfaz.
2 TCP/IP
2. TCP/IP
2.1. Introduccin
Es fundamental explicar el conjunto de protocolos que nos sirven para comunicar varios equipos, ya que entendiendo cmo funciona sabremos qu polticas necesitamos para disear la seguridad en una red, bloqueando las transmisiones no deseadas, que al n y al cabo es lo que hace un rewall. 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 nales de los 1960 como un proyecto de investigacin nanciado por el gobierno en una red de ordenadores del tipo packet switching, se ha convertido en el protocolo de red ms usado entre ordenadores. Es tal su relevancia que el rewall se construir slo y exclusivamente para redes IP. Hay muchas publicaciones que hablan de esta suite. Forman las bases para lo que es llamado la Internet mundial, o simplemente Internet, una wide area network (WAN) de varios millones de ordenadores que envuelven literalmente el globo. 2.1.1. Capas Los protocolos de red se desarrollan normalmente en capas, cada una de las capas es responsable para una faceta diferente de las comunicaciones. Una suite de protocolos como es el caso de TCP/IP, es la combinacin de diferentes protocolos en varias capas, que normalmente se le considera un sistema de 4 capas o layers.
2 TCP/IP
2.1 Introduccin
Cada capa tiene diferentes responsabilidades. 1. La capa link, llamada normalmente data-link layer es la interfaz de red que incluye el driver del sistema operativo para la tarjeta de red. Juntos pueden tratar todos los detalles del hardware e interactuar fsicamente con el cable o con el medio que se est usando en cada caso. 2. Capa de red o Network Layer, se encarga del movimiento de paquetes a travs de la red. Para el enrutado de paquetes se usa IP (Internet Protocol), ICMP (Internet Control Message Protocol) y el IGMP (Internet Group Managment Protocol). 3. La capa de transporte se encarga del ujo de datos entre dos ordenadores, para la capa de aplicaciones. En la suite de TCP/IP hay dos protocolos muy diferentes entre s en la capa de transporte: TCP (Transmisin Control Protocol) y UDP (User Datagram Protocol). Para el caso de TCP este provee un ujo asegurado entre dos ordenadores. Se encarga de dividir los datos pasados desde las aplicaciones en trozos de tamao correcto para la capa de red, aceptando los paquetes recibidos, marcando tiempos para asegurar que 3
2 TCP/IP
2.1 Introduccin
los paquetes de acknowledge enviados, entre otros. Al ser un ujo de datos asegurado la capa de aplicacin puede ignorar estos detalles. En cambio UDP provee una forma mucho ms simple de comunicarse. Este simplemente enva paquetes de datos llamados datagramas de un host a otro, pero no esta garantizado que los datagramas lleguen a la otra parte. Cualquier control debe aadirse en la capa de aplicacin. 4. La ltima capa, la capa de aplicacin trata los detalles del una aplicacin en particular. Podemos encontrar dentro de todas las aplicaciones: telnet para hacer logins remotos, http para la web, ftp para transferir cheros, smtp para enviar correo electrnico, etc Cada capa tiene uno o ms protocolos para comunicarse con las capas vecinas del mismo nivel entre ordenadores. Un protocolo, por ejemplo el TCP permite comunicarse entre la parte del emisor y del receptor. IP es el protocolo principal en la capa de red. Es usado por los protocolos TCP y UDP. Cada dato de estos protocolos se transere a travs de la capa de red usando el protocolo IP, este proceso se llama Encapsulacin y se pasa a explicar en el siguiente punto. 2.1.2. Encapsulacin Cuando una aplicacin enva datos usando TCP, los datos son enviados abajo y los almacena en la pila del protocolo, y as sucesivamente a travs de cada capa, hasta que son enviados como un conjunto de bits por la red. Cada capa o layer aade informacin a los datos, normalmente antecediendo a los datos o a veces aadiendo unos pocos datos al nal. La unidad de datos que TCP enva a la pila de IP se llama un segmento TCP. La unidad de datos que enva IP en la capa 3 a la capa 2, la de red, se llama un datagrama IP. Y por ltimo el ujo de bits que pasan por la red Ethernet se llaman frames. IP debe aadir algn tipo de identicador en la cabecera IP que genera para indicar a qu capa pertenece. Esto se trata guardando un valor del tamao de 8 bits en su cabecera llamado campo de protocolo. Si el valor es 1 es para ICMP, si es 2 es para IGMP, 6 indica TCP y 17 es UDP. Esto nos ser muy til a la hora de bloquear los paquetes que no se deseen. 4
2 TCP/IP
2.2 IP: Internet Protocol
De forma similar, todas las aplicaciones que usan TCP o UDP deben identicarse. La capa de transporte guarda un identicador en la cabecera que genera para identicar la aplicacin. Ambos protocolos el TCP y el UDP usan nmeros de puerto de 16 bits para identicar aplicaciones. Se guarda el puerto de origen y el de destino para identicarlos. Aunque no sea interesante para el proyecto del rewall tambin indicar que los frames de la capa de red que recibe el driver de la tarjeta Ethernet, tienen tambin un campo de 16 bits para indicar que capa del protocolo gener los datos.
2.2. IP: Internet Protocol

2.2.1. Introduccin IP es la herramienta principal dentro de la suite TCP/IP. Todos los datos TCP, UDP, ICMP e IGMP son transmitidos como datagramas IP. Un dato importante es que el protocolo IP es un protocolo NO orientado a conexin (conectionless) y NO asegurado. Por no asegurado se entiende que el protocolo IP no garantiza la llegada a su destino de los datagramas. IP provee un servicio de mejor esfuerzo (best effort). Cuando algo va mal como por ejemplo un router no tiene ms capacidad en los buffers de entrada, IP tiene un algoritmo para tratar el error muy sencillo: no hace caso del datagrama e intenta enviar un mensaje ICMP al origen. Ser un protocolo no orientado a conexin signica que IP no mantiene ningn estado de informacin de los datagramas consecutivos. Cada datagrama es tratado de forma separada de todos los otros datagramas. Signica que los datagramas pueden llegar de manera desordenada. Por ejemplo, si un equipo enva dos datagramas consecutivos al mismo destino, y cada uno va por un camino diferente pueden llegar en un orden distinto al de salida. El protocolo IP est diseado para ser retransmitido para ser usado en sistemas interconectados en redes de comunicaciones packet-switched. Los hosts se identican por una direccin ja, 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 ujo, secuencia de paquetes y otros mecanismos que se encuentran en protocolos orientados a conexin. 5
2 TCP/IP
Las funciones bsicas del protocolo segn la especicacin RFC0791 son dos: direccionar y fragmentar. Para direccionar se usan las direcciones que se encuentran en la cabecera. La seleccin del camino para la transmisin se llama routing. Lo que interesa de todo esto para el rewall 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 especicacin RFC 791, publicada en septiembre del 1981 (http://www.ietf.org/rfc/rfc07 encuentra la especicacin de la cabecera del datagrama.
0 version ip_v header length type of service ip_tos 15 16 total length ip_len flags and fragment offset ip_off protocolo ip_p direccin IP origen 32 bits ip_src direccin IP destino 32 bits ip_dst opciones (si las hay) header chacksum ip_sum 31
identificacin 20 bytes cabecera time to live ip_ttl
datos
Versin: 4 bits El campo de versin indica el formato de la cabecera de Internet. Esta cabecera corresponde a la versin 4. IHL: 4 bits Internet Header Lenght o tamao de la cabecera, es el tamao de la cabecera en palabras de 32 bits, tras la cual empiezan los datos. El valor mnimo de la cabecera es 5. TOS: 8 bits
2 TCP/IP
Type Of Service o tipo de servicio indica los parmetros para la calidad de servicio deseado. Estos parmetros suelen usarse para ser una gua del tipo de servicio que se est retransmitiendo en el datagrama. Tamao total: 16 bits El tamao total es el tamao del datagrama, medido en octetos, incluyendo el tamao de la cabecera y de los datos. El tamao de 16 bits permite que el datagrama sea hasta 65.535 octetos. El tamao de dichos datagramas es impracticable en la mayora de redes y ordenadores. Todos los ordenadores tienen que estar preparados para aceptar datagramas de hasta 576 octetos.Si se quiere saber ms sobre la conguracin de LILO, hay que obtener la versin ms reciente de servidor FTP favorito y siga las instrucciones que le acompaan Identicacin: 16 bits Una valor de identicacin asignado por el emisor para poder ensamblar los diferentes fragmentos de un datagrama. Flags: 3 bits 1. Bits de control: Bit 0: reservado. Tiene que ser cero. Bit 1: (DF) 1 = Dont Fragment, 0 = May Fragment. Bit 2: (MF) 1 = More Fragments, 0 = Last Fragment. Fragment Offset : 13 bits Este campo indica a que parte del datagrama pertenece este fragmento. El tamao del fragmento se mide en unidades de 6 octetos (64 bits). Para indicar el primer fragmento de un datagrama este campo tiene que ser cero. Time To Live: 8 bits
2 TCP/IP
Este campo indica el tiempo mximo que se le permite a un datagrama mantenerse en Internet. Si este valor contiene un valor de cero, entonces el datagrama tiene que ser destrozado. Este campo es modicado al procesar las cabeceras. Su tiempo est medido en unidades de segundo, pero cada mdulo tiene que decrecer el valor de TTL como mnimo por uno incluso si se ha tardado menos de un segundo en procesar el datagrama. La intencin es que los datagramas que no puedan ser entregados sean descartados. Protocolo: 8 bits Este campo indica el siguiente nivel del protocolo usado por el datagrama. Los valores ya se han comentado anteriormente. Y son 1 si es para ICMP, si es 2 es para IGMP, 6 indica TCP y 17 es UDP. Header Checksum: 16 bits Un checksum de solo la cabecera. Como hay campos en la cabecera que cambian (Ej. Time to live), este valor se recalcula y verica cada vez que es procesada la cabecera.#howto El resultado del algoritmo de checksum es el complemento de 16 bits a uno con la suma de todas las palabras de 16 bits de la cabecera. Exceptuando el valor de checksum que tiene el valor de cero. Direccin origen: 32 bits Es la direccin IP origen de 32 bits. Direccin destino: 32 bits Es la IP del dispositivo destino, tambin de 32 bits. Opciones: variable Las opciones pueden o no aparecer en los datagramas. Deben ser implementados por todos los mdulos IP. Lo que es opcional es su transmisin en cualquier datagrama, pero no su implementacin. 8
2 TCP/IP
2.3 UDP: User Datagram Protocol
2.3. UDP: User Datagram Protocol

2.3.1. Introduccin UDP es simple, orientado a datagrama, y est encuadrado en la capa de trasporte. Cada operacin de envo por un proceso produce exactamente un datagrama UDP, lo que causa que slo un datagrama IP sea enviado. Es diferente a un protocolo orientado a conexiones (stream-oriented protocol) como es el caso de TCP donde la cantidad de datos enviados por una aplicacin puede tener pequeas diferencias a lo que en realidad es enviado en un datagrama IP. En la siguiente gura se ensea la Encapsulacin de un datagrama UDP en el datagrama IP. La especicacin ocial de UDP es la RFC 768, publicada en Agosto del 1980, por J.Postel y se puede encontrar en (http://www.ietf.org/rfc/rfc0768.txt). UDP no provee una conexin able (no reliability): enva el datagrama que la aplicacin escribe a la capa IP, pero no garantiza que llegue a su destino, es un protocolo que no est orientado a conexin. La falta de conanza hace pensar que deberamos dejar de usar UDP y usar siempre el protocolo able 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 especicaciones pueden encontrarse en el RFC 768.
0 15 16 Direccin origen Direccin destino ceros protocolo UDP length 32
Datos
Nmero de puerto origen: 16 bits 9
2 TCP/IP
2.4 TCP: Transmisin Control Protocol
Identica el proceso que enva el datagrama. Tanto este campo como el siguiente nos sirven para poner reglas de ltrado en el rewall. Nmero de puerto destino: 16 bits Identica de la misma manera el proceso que debe recibir el datagrama. Este campo se usa para multiplexar los datagramas que llegan a la mquina y pasarlos a la aplicacin que se necesita. La pila de IP ya se encarga de dividir los paquetes entre los TCP y los UDP, as que es el propio UDP quien mira el puerto destino y tambin implica que los puertos TCP y UDP son independientes entre ellos. Tamao UDP: 16 bits Es el tamao de la cabecera UDP y de los datos, la cantidad es en Bytes. El valor mnimo es 8 bytes (Como resultado de enviar los 8 bytes de la cabecera sin datos). Aunque este valor es redundante ya que este valor es el campo de tamao que se encuentra en la cabecera IP menos el tamao de la cabecera IP. Checksum: 16 bits Este checksum cubre tanto la cabecera UDP como sus datos. A diferencia del checksum de IP que solo cubre la cabecera de IP y no cubre los datos que contiene el datagrama. Tanto UDP como TCP cubren con sus checksum sus cabeceras y los datos. Para poder hacer el checksum puede aadirse un relleno para que cuadren las palabras de 16 bits.
2.4. TCP: Transmisin Control Protocol

2.4.1. Introduccin La especicacin original para TCP es la RFC 793, publicada por Postel en Septiembre de 1981 para DARPA (Defense Advanced Research Projects Agency). An estando TCP y UDP en la misma capa de transporte y usar la misma capa de red (IP), TCP provee un servicio completamente diferente al de UDP. TCP es un servicio orientado a conexin, able y un servicio de ujo de bytes (byte stream service). 10
2 TCP/IP
Por el trmino orientado a conexin se entiende que dos aplicaciones usando TCP tienen que establecer una conexin entre ellos antes de poder intercambiar datos. Una analoga parecida es una llamada de telfono: se marca, se espera que la otra parte responda a la llamada, decir un hola y quien es, tras ello comienza la conversacin. Al decir que es able (reliability) se indica lo siguiente: 1. Los datos de la aplicacin se separan en lo que TCP considera que es el mejor tamao. Completamente diferente a UDP, donde cada vez que escriba la aplicacin generaba un datagrama UDP de ese mismo tamao. La unidad de informacin pasada por TCP a IP se llama segmento. 2. Cuando TCP enva un segmento mantiene un temporizador, esperando para que la otra parte enve un segmento con su acuse de recibo (acknowledge). Si no se recibe el acuse de recibo tras esperar un rato, el segmento es retransmitido. 3. Cuando TCP recibe datos de la otra parte de la conexin este enva un acuse de recibo. Que no aunque no se enva inmediatamente pues sigue una estrategia. 4. TCP se encarga del checksum de su cabecera y de los datos. En el caso de recibir un segmento con su checksum errneo TCP lo descarta y no enva ningn acuse de recibo. 5. Al encapsular TCP dentro de IP, y como los datagramas IP pueden llegar en desorden, los segmentos pueden llegar tambin en desorden. Se encarga tambin TCP de reordenarlos en caso de ser necesario, pasando los datos recibidos en el orden correcto a la aplicacin. 6. Como un datagrama IP puede llegar duplicado, los segmentos TCP duplicados deben ser descartados. 7. TCP tambin mantiene un control del ujo de datos. Cada parte en la conexin TCP tiene el espacio del buffer de entrada nito. Lo que signica que TCP solo permite que la otra parte enve los datos que tiene reservados. Esto 11
2 TCP/IP
previene de que un ordenador rpido llene todos los buffers de un ordenador lento. Cuando hablamos de un servicio de ujo de bytes (byte stream service) nos referimos a que TCP enva un ujo de bytes a travs de la conexin, no hay marcas que identiquen cuando el emisor envi los datos. Signica que si una aplicacin enva 20 bytes, luego enva otros 35 bytes seguido por otros 25 bytes, la aplicacin de la otra parte no podr identicar los tamaos de las diferentes escrituras, solo recibe 80 bytes en cuatro lecturas de 20 bytes, por ejemplo. Una parte pone un ujo de bytes a la pila TCP y este mismo ujo lo recibe la otra parte de la conexin. Adems, TCP no interpreta el contenido de los bytes que enva. TCP no tiene ni idea si los datos corresponden a datos en binario, a caracteres ASCII, caracteres EBCDIC o lo que sea. La interpretacin de los bytes retransmitidos es funcin de la aplicacin que se encuentra en una capa superior a la de transporte de TCP. 2.4.2. Cabecera TCP Los segmentos TCP se envan mediante datagramas IP. La cabecera TCP sigue a la cabecera IP, aadiendo informacin especca para el protocolo TCP.
0 Puerto Origen Nmero Secuencia Acknowledge Number Data Off Reserved | bits Opciones Ventana Padding 15 16 Puerto Destino 32
Datos
Puerto de origen: 16 bits Nmero de puerto de origen. 12
2 TCP/IP
Puerto de origen: 16 bits
Puerto destino que indica a qu aplicacin va dirigido el segmento. Nmero de secuencia: 32 bits El nmero de secuencia del primer octeto de datos. En el caso de estar el bit de SYN presente el nmero de secuencia es el nmero inicial de secuencia (initial sequence number ISN)y el primer octeto de datos es ISN+1. Nmero de Acknowledgment: 32 bits Si el bit de control ACK est activo este campo contiene el valor del siguiente nmero de secuencia que se espera recibir. Y una vez se ha establecido la conexin siempre se enva. Data Offset: 6 bits Reservado para uso futuro. Debe ser cero. Bits de control: 6 bits (de izquierda a derecha) 1. URG: Urgent Pointer eld signicant. 2. ACK: Acknowledgment eld signicant. 3. PSH: Push Function. 4. RST: Reset the connection. 5. SYN: Synchronize sequence numbers. 6. FIN: No ms datos por parte del emisor. Ventana (window): 16 bits El nmero de octetos de datos empezando por el nmero indicado en el campo de acknowledgment que el emisor del segmento esta esperando recibir. 13
2 TCP/IP
Checksum: 16 bits
El checksum se le aplica al cuerpo del mensaje y a parte de la cabecera, que incluye la direccin origen, la de destino, el protocolo y el tamao del TCP. Puntero urgente: 16 bits Este campo indica el valor del puntero urgente como un offset positivo desde el nmero de secuencia en este segmento. Y apunta al nmero de secuencia del octeto seguido por los datos urgentes. Este campo solo es interpretado en segmentos con el bit de control URG activa.
14
3 INTRODUCCIN A LOS FIREWALLS
3. Introduccin a los rewalls

3.1. Qu es un Firewall?
En construccin, un rewall se disea para mantener el fuego separado de una parte de un edicio a otra. En teora, un rewall de Internet sirve con el mismo propsito: previene de peligros de Internet a la red interna. Todo el trco que proviene de Internet o que sale de tu red interna pasa a travs del rewall. Por esa razn, el rewall tiene la oportunidad de asegurarse que ese trco es aceptable. Qe signica aceptable para el rewall? Signica todo aquel trco que se hace y que cumple con las normas de seguridad del lugar. Las polticas son diferentes para cada uno, algunas son muy restrictivas y otras son ms abiertas. Lgicamente hablando, un rewall, separa, restringe y analiza. Fsicamente hablando se puede implementar de varias maneras, la mayora de veces es un grupo de componentes hardware - un router, un ordenador, o una combinacin de routers, ordenadores y redes con un software apropiado. Hay varias formas de congurar los equipos; la conguracin depender de las polticas de seguridad, del dinero disponible y de las operaciones a realizar. Los rewalls tienen limitaciones y puntos dbiles, entonces por qu instalar un rewall si no es invulnerable? Porque el rewall es la manera ms efectiva de conectar una red a Internet y proteger la propia red. Internet presenta maravillosas oportunidades. Millones de personas estn intercambiando informacin. Los benecios son obvios: posiblidades de publicidad, servicio a cliente mejorado e informacin en general. Los riesgos tambin deberan ser obvios tambin: cualquiera de los millones de personas puede tener intenciones maliciosas contra tu red. Cmo beneciarse 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 rewall es la herramienta para hacer eso, en la mayora de situaciones es la herramienta ms efectiva para hacerlo.
15
3.2 Qu puede hacer
3.2. Qu puede hacer

Los Firewalls pueden hacer mucho para tu seguridad. Estas son algunas de las ventajas: 3.2.1. Donde localizar las decisiones Todo el trco de entrada y salida tiene q pasar a travs de este sitio. Un rewall concentra las medidas de seguridad en este lugar de chequeo: all donde tu red se conecta a Internet. 3.2.2. Refuerza polticas Muchos de los servicios que la gente quiere de Internet son inherentemente inseguros. Un rewall es el policia del trco para estos servicios. Permite solo servicios aprovados para pasar a travs de l y solo aquellos que se hayan congurardo. Un rewall puede reforzar las polticas de seguridad aadiendo polticas ms complejas. Por ejemplo bloqueando una transferencia de cheros desde una parte de nuestra red; controlando qu usuarios tienen acceso a que sistemas. Y dependiendo de la tecnologia del rewall, este puede ser mas o menos complejo para aadir estas polticas. 3.2.3. Registrar la actividad Como todo el trco pasa a travs del rewall, el rewall provee un buen lugar para recoger una coleccin de informacin sobre los usos de los sistemas y redes. Puede recopilar qu ocurre entre la zona protegida y la red externa. 3.2.4. Limita la exposicin Este es uno de los usos ms relevantes de los rewalls. A veces un rewall se usa para mantener una seccin de tu red separada de otra seccin. Haciendo esto, se mantienen los problemas que puedan impactar en una seccin separada del resto. En estos casos, una parte de la red puede ser ms segura que otra, en otros casos una seccin puede ser ms sensible que otra. Cualquiera que sea lar 16
3.3 Qu no puede hacer
razn de la existencia de un rewall este limita el dao que puede hacer una red a otra.
3.3. Qu no puede hacer

Los rewalls ofrecen una excelente proteccin, pero no son la solucin nica y completa para nuestra seguridad. Ciertos procesos estan fuera del control de nuestro rewall. Y se necesita otras mtodos para protegerse de estos sucesos incorporando otras herramientas. Es necesario conocer cuales son los puntos dbiles de los rewalls. 3.3.1. Dentro de la red Un rewall puede prohibir a un usuario de enviar informacin condencial fuera de la red a travs de la conexin a Internet. Pero el mismo usuario puede copiar los datos en un disco, imprimirlos y llevarselos fuera del edicio en un maletn. Si el atacante esta dentro de la red el rewall no puede hacer nada por ti. Dentro los usuarios pueden robar datos, daar hardware y software, modicar programas sin siquiera pasar a travs del rewall. Es necesario protegerse con medidas internas de seguridad. 3.3.2. Conexiones que no van a travs de l Un rewall puede controlar el trco que pasa a travs de l pero no puede hacer nada con el trco que no pasa a travs de l. Por ejemplo, si hay otra conexin dial-in para conectarse a los sistemas detrs del rewall, este no tiene ninguna forma de proteger a los intrusos que usen ese modem. 3.3.3. Virus Los rewalls no pueden mantener a los viruses alejados de la red interna. Muchos rewalls escanean todo el trco entrante para determinar si este esta permitido, pero el escaneo de los datos son la mayora de veces de solo las direcciones y puertos origen y destino, no para los detalles de los datos. Incluso los rewalls 17
3.4 Tipos de Firewalls
ms sosticados no son muy prcticos contra los viruses. Simplemente hay muchas maneras para esconder un virus entre otros datos. Determinar que existe un virus dado un paquete que pasa a travs del rewall es muy difcil. La forma ms prctica de defenderse de los virus es mantener un software de proteccin basado en los ordenadores, y educando de los posibles peligros a los usuarios y de como protegerse de ellos.
3.4. Tipos de Firewalls

Existen principalmente dos formas de implementar los rewalls hoy da. Y esta divisin se centra en la forma de tratar los datos que pasan a travs del rewall, una de las dos formas es menos exhaustiva, pero por eso es la solucin ms barata. El trabajo nal de carrera no trata de rewalls proxy, pero estos sucientemente importantes como para comentarlos. 3.4.1. Filtrado de paquetes Los sistemas de ltrado de paquetes enrutan paquetes entre dos redes diferentes, pero lo hacen selectivamente. Permiten o bloquean cierto tipo de paquetes en un sentido o en el otro sentido, siguiendo las polticas de seguridad. El tipo de router usado en un ltrado de paquetes se conoce como screening router.
Como se discute en el captulo dedicado a TCP/IP cada paquete tiene unas 18
cabeceras con cierta informacin. En esta informacin se encuentra: 1. direccin origen IP 2. direccin destino IP 3. protocolo (TCP, UDP o ICMP) 4. puerto origen TCP o UDP 5. puerto destino TCP o UDP 6. tipo de mensaje ICMP Adems el router dispone de ms informacin del paquete que no se reejan en el paquete pero son igual de importante, sino ms. 1. La interfaz por donde llega el paquete 2. La interfaz destino del paquete El hecho que cada uno de los servidores tenga cierto tipo de servicios nos indicar las reglas que debamos escoger en el rewall basndonos en la IP del servidor y del puerto, porque el puerto indica el tipo de conexciones (ej. puerto 22 TCP son conexion SecureSHell). Hay varias formas en las que podemos basar nuestras polticas, unas seria bloquear todas las conexiones provinentes de fuera de la red excepto las conexiones SMTP para recibir correo. Bloqueando todas las conexions de sistemas que desconas, etc El screening router se situa entre la red interna e Internet. Esto le da una enorme responsabilidad al screening_router. No solo se encarga del rutado de los paquetes, sino que tambin se encarga de proteger el sistema. Si falla o se cae tras un ataque, la red interna est expuesta. Es ms no puede proteger de operaciones a un servicio: si un servicio tiene operaciones inseguras. o si el servicio se provee con un servidor inseguro el ltraje de paquetes no puede protegerlo, ya que los paquetes pasarn indistintamente del contenido de los paquetes, ya sea maligno o no. 19
Pero como mayor ventaja es que es un tipo de proteccin ms barata, ya que puede tratar a ms conexiones que un proxy con el mismo equipo hardware y adems el programa no es complejo de realizar, comparado con el proxy, ya que como se ve a lo largo del trabajo nal de carrera, no es un programa sencillo de implementar. 3.4.2. Servicios proxy Los servicios proxy son programas especializados que corren en un rewall: ya sea un host dual-homed con una interfaz en la red interna y otra en la red externa, o bien un host bastion que tiene acceso a Internet a travs de otra maquina interna. Estos programas redireccionan los requests de los servicios que piden los usuarios (como sesiones FTP o sesiones SSH), las direccionan segn las politicas de seguridad. Los proxies reemplazan las conexiones externas y actan de gateway a esos servicios. Por esa razn se les conoce tambin como gateways del nivel de aplicacin.
Los sistemas proxy, permanecen ms o menos de manera transparente entre el usuario dentro de la red y el servicio fuera de la red. En vez de hablar directamente uno con el otro cada uno de ellos habla con el proxy. Estos tratan las conexcion entre usuarios y los servicios de una manera transparente. 20
3.5 Arquitecturas Firewall
La transparencia es el mayor benecio de los servicios proxy. Para el usuario, un proxy presenta la ilusin que esta tratando directamente con el servidor real. Para el servidor real, el proxy presenta la ilusin de que est tratando directamente con un usuario en el ordenador del proxy, en vez de ser el autntico usuario en otro ordenador. Los servicios proxy son efectivos solo cuando se usan en conjuncin con algn mecanismo que restringe las comunicaciones directas entre los ordenadores externos e internos. Si los hosts internos pueden comunicarse directamente con los hosts externos no hay razn alguna para tener un proxy. Un proxy es una solucin software, deben usarse conjuntamente con un rewall. Los servidores proxy no solo redirecciona el trco de los usuarios a los servicios externos de Internet. Los servidores proxy controlan lo que estos hacen, porque escucha todo lo que hacen los usuarios y segn las polticas de seguridad dejar pasar el contenido. Por ejemplo un proxy web puede bloquear todas las pginas web que contengan VBScript pues estos ejecutan programas que pueden llegar a ser muy peligrosos. Y todo de una manera transparente al usuario. 3.4.3. Combinacin de tcnicas La buena solucin es aquella que no se basa en una nica tcnica, sino aquela que usa cuidadosamente la combinacin de varias tcnicas para resolver diferentes problemas. Los problemas que debes resolver dependen en qu servicios quieres proveer a los usuarios y qu nivel de riesto estas dispuesto a aceptar. Y las tcnicas tambin dependen del dinero, tiempo y experiencia de la que dispones. Algunas protocolos se pueden tratar mejor con ltrado de paquetes como puede ser SMTP y SSH. Y otros servicios se tratan mejor con proxies como puede ser los servicios FTP, Gopher y HTTP.
3.5. Arquitecturas Firewall

Esta seccin describe una variedad de maneras de las que podemos disponer los rewalls, las redes de ordenadores o servidores y los routers. Dependiendo de la funcionalidad que le queramos dar a la red se escoge una u otra arquitectura.
21

3.5.1. Dual-Homed Host
La arquitectura para un rewall Dual-Homed Host es muy simple: el ordenador Dual-Homed Host se situa antes de la red a proteger, conectado directamente, entre la red interna e Internet. Esta arquitectura se construye alrededor del ordenador dual-homed host, es un ordenador que tiene al menos dos interfaces de red. An siendo capaz de enrutar paquetes IP de una a otra red, si se implementa una aquitectura Dual-Homed Host se restringe esta funcin de enrutaje. Lo que hace que los paquetes de una red no se conectan directamente a la otra red. Los sistemas dentro del rewall pueden comunicarse con el Dual-Homed Host, y los sistemas fuera del rewall (de Internet) puede comunicarse con el Dual-Homed Host, pero estos sistemas no pueden comunicarse entre ellos. El trco IP est completamente bloqueado. Todo trco hacia fuera lo debe originar el rewall.
Esta arquitectura puede proveer un gran nivel de control. Ya que todos los paquetes se originan en el rewall. Se puede asegurar adems que cualquier paquete dentro de la red interna que tenga la direccin origen con una IP externa es origen de algn tipo de problema de seguridad. La nica manera que tienen la red interna de conectarse con el exterior es atravs de servicios proxy localizados en el rewall, y atravs de este servir de conexin. Pero presenta un inconveniente, y es que no todos los servicios pueden 22
pasarse por Proxy y lo que indica que los usuarios deberan tener cuentas de usuario en el rewall y conectarse al exterior desde l mismo. Lo que es incmodo para los usuarios y un posible agujero provinente de usuarios internos. 3.5.2. Screened Host En esta aquitectura se usa un router para conectar las redes internas y externas (Internet), pero se congura el router con ltrado de paquetes para que no se puedan conectar directamente las redes internas y externas, a no ser que sea a travs del bastion host que hace la funcin de proxy. El host bastion se sita en la red interna. El ltraje de paquetes se hace en el Screened Host (router) que se congura para que el bastion host sea el nico capaz de recibir conexiones externas. Cualquier sistema externo que intente acceder al sistema interno o a los servicios internos deber hacerlo a travs del bastion host. Por ello este host debe mantener un gran nivel de seguridad. Adems el Screened Host usando el ltraje de paquetes indicar que conexiones se permiten desde la red interna al mundo externo, siguiendo las polticas de seguridad. Algunos de los servicios externos pueden hacerse bien directamente a traves del Screened Host o bien a travs del bastion host mediante el proxy.
Como esta arquitectura permite pasar paquetes de fuera a dentro de la red, puede parecer ms inseguro que una arquitectura dual-homed host, que est di23
seada para que ningn paquete externo entre a la red interna. Pero en la arquitectura Screened Host es ms fcil defender el router, que provee servicios muy limitados, comparado con el dual-homed host. Para la mayora de propsitos, el Screened Host provee mejor seguridad y mejor usabilidad que la Dual-Homed host. Pero comparada con la arquitectura siguiente, hay desventajas. La mayor es que si un atacante llega a controlar el bastion host, entonces toda la red interna esta expuesta. El router tambin representa un nico punto de fallo. Por eso mismo la siguiente arquitectura es ms popular. 3.5.3. Screened Subnet La arquitectura Screened Subnet aade una capa de seguridad extra a la anterior arquitectura, aadiendo una red de permetro o tambin perimeter network en ingls, que aisla la red interna de Internet. La topologia es situar un router conectado a Internet, tras el router una red con un host bastion haciendo las funciones proxy y conectado a la perimeter network, y en esa misma red se conecta otro router que da acceso a la red interna. Por qu hacer esto? Por su propia naturaleza, los ordenadores bastion son las mquinas ms vulnerables de la red. A pesar de todos los esfuerzos por mantenerlas protegidas, son las mquinas que se atacan principalmente, porque son ellas las que pueden atacarse. Si, en una arquitectura screened host, esta abierta a un ataque desde el host bastion, entonces el host bastion es un target muy jugoso, porque no hay defensas entre este y las otras mquinas. Si alguien rompiese la seguridad del bastion host en una arquitectura Screened Host entonces es como si le tocase el gordo, esta dentro de la misma red interna con todos los ordenadores indefensos. En cambio en una arquitectura Screende Subnet si penetra en el host bastion no puede daar al resto de ordenadores, por estar aislado, sigue siendo peligroso porque puede instalar un snifer, pero no acceder directamente a la red interna.
24
La manera ms simple de crear una arquitectura Screende Subnet es conectando dos routers a la red de permetro (perimeter net). Una entre la perimeter net y la red interna, y otro entre la perimeter net y la conexin externa (normalmente Internet). Para romper dentro de la red interna con este tipo de arquitectura el atacante debera pasar atravs de los dos routers. Incluso si el atacante consiguiese romper el bastion host aun le quedara pasar el router interno. A veces para ir ms all, se crean una serie de redes perimetrales entre el mundo externo y la red interior. Dependiendo de lo seguras y conables que son los servicios que se ponen en cada permetro. Los servicios ms vulnerables se ponen en las redes externas y la red interna se pone al principio. Es un fallo de seguridad lo que voy a decir pero es tal mi conanza en esta topologia que no me importa decir que es as como tengo congurado los sistemas que estn a mi cargo. Red perimetral La red perimetral es como he comentado antes, otra capa de seguridad, una red adicional entre las redes externas y la red interna que se trata de proteger. Si un atacante consigue romper dentro de una red perimetral puede conseguir atacar los servicios que se trate dentro de la red. Dentro de la red perimetral pueden ponerse 25
los servidores FTP y WWW, en caso de ser atacado y tener xito el ataque pueden tener el acceso al ordendor y tras ello se puede acceder a la red perimetral pero no pasar a la red interna. Router interno El router interno (a veces llamado choke router en literatura inglesa) protege la red interna de Internet y de la red perimetral. Este router hace la mayora del ltraje de paquetes. Permite que algunos servicios salir de la red interna a Internet. Estos servicios son los servicios que son mejor usar ltrado de paquetes que los proxies. Y los servicios que solo debe permitir ir al host bastion son aquellos que es mejor pasarlos por el proxy. Tambin debe limitarse las conexiones permitidas para la red interna. 3.5.4. Variaciones posibles Se ha visto las principales conguraciones posibles, pero dependiendo del dinero disponible, las polticas de seguridad, de los intereses y servicios a dar, debemos disponer de una exiblidad suciente para congurar y combinar componentes rewall. 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 conguracin. Las razones pueden ser varias, para mejorar la redundancia, para mejorar la performance del sistema o simplemente para simplicar la administracin de cada bastion host. Tambin puede dividirse segn la conanza que se tenga por los servicios a tratar, as se puede tener especial cuidado en aquello que puedan representar una amenza, as un servicio no puede comprometer otros.
26

Juntar el router externo con el interno
Se pueden juntar el router interno con el externo en un nico router, pero solo si se tiene un router suciente capaz y exible para hacerlo, hoy dia la mayora de routers lo permiten. Tenemos la red perimetral conectada a una intercie del router y la red interna conectada a la otra intercie. Dentro de la perimeter Network podemos tener un bastion host haciendo las funciones de proxy, para tal caso hay que congurar en el router el ltrado de paquetes convenientemente. Esta arquitectura, igual que la screened host, hace del nico router un punto vulnerable para comprometer a toda la red. En general los routers son fciles de proteger, ms que los servidores, pero igualmente no son impenetrables.
27
4 FILTRADO DE PAQUETES
4. Filtrado de paquetes
4.1. Introduccin
Como he comentado en la seccin de introduccin a los rewalls, el ltrado de paquetes es uno de los dos tipos de rewalls que existe, el otro sistema es el rewall proxy. Cada uno sube hasta un nivel concreto de la capa OSI. Mientras el primero solo trata hasta el nivel 3 de la capa OSI, donde se encuentran los paquetes y basa sus decisiones en la informacin que hay en la cabecera del paquete IP. La otra, los sistemas proxy, sube hasta en nivel de aplicacin, pues debe basar sus decisiones en la informacin que hay en los datos del nivel ms alto. El trabajo solo aborda el primer sistema, y es por eso que se profundiza ms en este sistema: el ltrado de paquetes. El ltrado de paquetes es un mecanismo de seguridad que trabaja controlando los datos que vienen y van por la red. Es necesario tener claro los fundamentos que se han explicado en la seccin TCP/IP para enteder correctamente este apartado. Al transferir informacin a travs de la red, la informacin esta troceada en pequeas piezas, cada una de ellas se enva separadamente. Rompiendo la informacin en partes permite a los sitemas compartir la red, enviando piezas por turnos. En las redes IP, que son las que trato en el trabajo, estas piezas de datos se llaman paquetes. Todos los datos que se transeren a travs de las redes IP se hace en forma de paquetes. Los equipos bsicos que interconecta redes IP se llaman routers. Un router puede ser una pieza dedicada de hardware si otro propsito, o puede ser tambin un software que corre en un sistema de propsito general como un PC. Los paquetes atravesando una red viajan de un router a otro hasta llegar a su destino. Internet es en s misma un red de redes. Los routers deciden el destino para cada paquete que reciven, tienen que decidir a dnde enviarlo basndose en el destino nal del paquete. En general, un paquete no lleva ninguna otra informacin que la IP de destino para ayudar al router a tomar su decisin. El paquete dice al router donde quiere ir, pero no por donde lo debe enviar. Los routers se comunican entre ellos usando los protocolos de routing o protocolos de enrutaje segn el idioma, como por ejemplo Routing
28
4.2 Caractersticas
Information Protocol (RIP) como uno de los ms simples, o bien Open Shortest Path First (OSPF) para construir las tablas de enrutaje o tablas de routing, con las que determinan como enviar los paquetes a sus destinos. Cuando se enruta un paquete, el router compara la direccin de destino con las entradas que dispone en la tabla de routing y enva el paquete a travs de la interfaz que se indica en la misma tabla. Muchas veces no hay una ruta especca para un destino en particular, entonces el router usa la ruta por defecto o tambin default gateway que es como yo lo conozco, y se enva a routers que estn mejor conectados o a los routers que se supone pueden saber el destino. Al determinar como enviar un paquete a su destino, un router mira solo la direccin destino del paquete y se pregunta a donde debo enviar este paquete?. pero adems se considera la pregunta debo enviar este paquete? ya que o bien por la poltica de seguridad programa en el router es mejor descartar el paquete o bien porque a lo mejor el destino no es accesible y es mejor borrar el paquete para que deje de dar vueltas. Para la primera opcin se usa lo que se llama ltrado de paquetes, para la segunda opcin se trata el campo TTL (Time To Live). Nos concentraremos en el ltrado de paquetes, que es el objetivo de este trabajo nal de carrera.
4.2. Caractersticas
La principal ventaja del ltrado de paquetes es poder proveer, en un nico sitio, protecciones para toda un red. Considerando el servicio Telnet como ejemplo. Si se prohibe el Telnet cerrando en servicio de telnet en todos los ordenadores, an hay que tener cuidado y preocuparse por si alguien de la organizacin instala en una nueva mquina un servidor de Telnet. Por otra parte, si es telnet se desactiva desde el router, ltrando todos los paquetes que vayan a servir a tal propsito, se protege a la red desde el principio, si importar si hay alguien utilizando un servidor Telnet o no. Otra ventaja es que los routers suelen ser pocos, muchos menos que servidores, por eso se supone que se puede aplicar un mayor control concentrando la seguridad en ellos. Ciertas protecciones solo pueden proveerse con routers de ltrado de paquetes, y solo cuando se situan en ciertas localizaciones de la red. Por ejemplo, es una 29
4.3 Ventajas
buena idea parar todos los paquetes que tengan como direccin de origen una IP que pertenece a una mquina interna, porque lo ms seguro que se est intentando un ataque spoong. En estos ataques, un atacante pretende suplantar a otra mquina amiga o conocida ocultando su identidad. La solucin es bloquear todos los paquetes entrantes con una IP origen que pertenezca a la red interna. Este tipo de soluciones solo pueden hacerse con un router o rewall que tenga la opccin de ltrado de paquetes y que est situado en el permetro de la red. Y nicamente un router en esa loclizacin (por permetro se entiende que conecta las dos redes a travs de l) es capaz de reconocer un paquete as, mirando las direcciones origen de todos los paquetes que entren desde fuera de la red.
4.3. Ventajas
Ya he comentado algunas en el punto anterior, pero aqu se listan todas ellas: 4.3.1. Proteger toda la red Como he comentado una de las claves dentro de las ventajas de un router con ltrado de paquetes es que un router nico y estratgicamente situado puede ayudar a proteger toda un red. Si slo hay un router que conecta tu red con Internet,
30
4.3 Ventajas
se gana facilidad a la hora de proteger la red, sea cual sea el tamao de la red interna, si se hace correctamente en ese router externo que da conexin a Internet. 4.3.2. Transparencia Como diferencia al proxy, los sistemas con ltrado de paquetes no requieren ningn tipo de software ni conguracin en las mquinas de los clientes, no requiere ningn tipo de enseanza ni explicacin a los usuarios. Cuando un router con ltrado de paquetes decide lanzar un paquete, este no se distinge de otro router normal sin esa aplicacin. Los usuarios no sabrn que existe, a no ser que intenten hacer algo que est prohibido (supuestamente por un problema de seguridad) segn la poltica de seguridad que se le aplique al router con ltrado de paquetes. Esta transparencia signica que un router ltrando paquetes puede hacerse sin la cooperacin y sin el conocimiento de los usuarios a los que se les da el servicio de conexin. La clave no es hacer cosas a urtadillas de los usuarios, a sus espaldas. Sino que la clave est en que puedes hacer ltrado de paquetes sin tener que ensearles nada para que trabajen, y sin depender la seguridad en ellos para que algo funcione correctamente. Recuerdo que para protegerse de los virus es recomendable educarles, y es tedioso y an as no siempre funciona. 4.3.3. Disponibilidad El ltrado de paquetes est disponible en la mayora de hardware y software de los productos que hacen routing, ambos tanto comerciales como los distribuidos gratuitamente. La mayora de routers tambin tienen capacidades de ltrado de paquetes. Es una ventaja pues tras disear una poltica de seguridad es muy probable que dispongamos de la capacidad de ltrado de paquetes por parte del router. 4.3.4. Latencia Si comparamos el ltrado de paquetes con los sitemas proxy tenemos que con la misma potencia en hardware se consigue menos latencia. Esto es debido a que el ltrado de paquetes solo tiene que llegar al nivel IP. Adems las decisiones se
31
4.4 Desventajas
toman segn una pequea parte de los datos que transitan, la cabecera IP, y no es necesario investigar todos los datos de contenido de los datos que transitan.
4.4. Desventajas
Dentro de las caractersticas de los sistemas de ltrado de paquetes encontramos tambin desventajas, y entre todas ellas tenemos que: 4.4.1. Protocolos difciles Aunque la implementacin de las polticas de seguridad sean perfectas, encontramos que hay ciertos protocolos que simplemente no se pueden tratar facilmente usando este tipo de sistemas, las razones pueden ser varias, como por ejemplo la forma de establecer las sesiones FTP o en las sesiones de teleconferencia que usan el protocolo H.323 pues hay varios origenes de la conexin, los protocolos basados en RPC como por ejemplo NFS y NIS/YP tampoco son fciles de tratar. Ciertos protocolos, como por ejemplo FTP, H323 entre otros mantienen en sus conexiones unas sesiones caractersticas debido a que el cliente y servidor hacen los dos funciones de cliente y de servidor. Por ejemplo el File Transfer Protocol es uno de ellos, el cliente FTP se conecta al servidor FTP mediante TCP al puerto 21 por defecto, entonces cuando hay cualquier peticin el servidor enva los datos mediante UDP saliendo del puerto 20. Estos datos lo ms normal es que se hayan bloqueado en el rewall para proteger la red interna, porque no se puede dejar abierto ya que cualquier atacante lo usara. La solucin pasa por tener unas tablas indicando las sesiones que estn en funcionamiento, y cuando se detecte un paquete con el bit de reset activado entonces quitar la sesion de las tablas. Entonces si el rewall ve que le llegan datos UDP de fuera hacia dentro comprueba que exista esa IP dentro de la tabla de sesiones y que el puerto origen sea el 20. En tal caso deja pasar los datos porque se trata de una conexin FTP que ha inciado alguien dentro de la red que se est protegiendo.
32
4.4.2. Poltcas que no pueden aplicarse
4.5 Conguracin
La informacin que un paquete da al router que ltra los paquetes no es suciente para segn que poltica de seguridad. Por ejemplo, los paquetes indican de que ordenador provienen pero no de que usuario. Por eso, no se pueden hacer restricciones en usuarios especcos, sino que a las mquinas que estos usan normalmente. De igual forma, los paquetes dicen a que puerto van pero no a qu aplicacin, cuando se hacen restricciones por portocolo se hacen por el nmero de puerto, esperando que nadie este ejecutando el mismo servicio en un puerto que no se le asigna por defecto. La gente de dentro de la organizacin que tengan control sobre sus mquinas pueden hacer cambios en este sentido de un manera fcil. 4.4.3. Spoong Ya he nombrado antes los ataques spoong, los nmeros IP del origen pueden modicarse y para asegurarse de que el emisor es quien dices ser tiene que usarse otras tcnicas, en el mismo nivel de la torre OSI como por ejemplo IPSec o bien en niveles superiores de la torre OSI, por encima del nivel de transporte, como puede ser Secure SHell conocido como SSH, que intercambia claves de los servidores y no se basa nicamente en las IPs de las dos partes para crear una sesin.
4.5. Conguracin
Para congurar un router con ltrado 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 signica que est bien hecho. Y es que traducir quiero recibir correo de Internet en un grupo de reglas bien hechas requiere entender como funciona
33
4.5 Conguracin
y seguir un conjunto de reglas. A continuacin paso a explicar concepto que son necesarios tener en mente a la hora de traducir decisiones sobre los servicios en reglas para paquetes. 4.5.1. Bidireccionalidad Los protocolos en su mayora son bidireccionales; casi siempre son las dos partes las que envan datos, una enviando un comando o una peticin, y la otra parte enviando la respuesta del comando o retornando otros datos. Cuando se planea crear las reglas para el ltrado de paquetes es necesario recordad que los paquetes tienen doble sentido. Por ejemplo, no tienen ningn sentido dejar enviar los comandos en el Telnet y permitir que los paquetes salgan, pero en cambio prohibir que los resultados de los comandos no puedan verse prohibiendo el retorno de los paquetes. Por otra parte, no ayuda si se bloquea solo la mitad de la conexin. ya que muchos ataques pueden conseguirse si el atacante puede enviar paquetes a la red, incluso si el atacante no obtiene ninguna respuesta. Es posible porque las respuestas pueden ser predecidas, y permite a los atacantes mantener una conversacin sin necesitar ver las respuestas. Por ejemplo, si las respuestas son predecibles, pero no pueden ver las respuestas porque no se permite retornar los datos, puede que no se permita conseguir datos directamente, por ejemplo cuando no pueden ver el chero de /etc/passwd directamente, pero pueden mandar un comando para enviar un email a ellos mismos con una copia del mismo chero. 4.5.2. Inbound y Outbound Una signica trco entrante, inbound, y outbound signica trco saliente o hacia fuera. Cuando se planea una estrategia de ltrado de paquetes, se necesita tener especial cuidado por que se entiende por inbound y outbound. Hay que distinguir claramente que se entiende por paquetes entrantes inbound y los paquetes salientes outbound, y por otroa parte los servicios inbound y los servicios outbound. Un servicio outbound o saliente (por ejemplo un servicio Telnet) tiene paquetes salientes (los comandos) y paquetes entrantes (las respuestas de la pantalla). Aunque la mayora de la gente piense habitualmente en trminos de ser34
4.6 Que hacer
vicios, hay que pensar claramente en trminos de paquetes cuando se trata con el ltrado de paquetes. Cuando se habla de ltrado de paquetes, lo ms importante es la direccin de los paquetes y no de los servicios. 4.5.3. Permitir por defecto versus denegar por defecto Este punto es epecialmente importante a la hora de congurar las reglas de ltrado de paquetes. Se distinguen entre dos tipos de reglas, se puede escoger o bien poner las polticas de seguridad con una regla de negado por defecto (todo aquello que no se expresa especcamente que est permitido se niega) o bien la regla de permitir por defecto (todo aquello que no se especica especcamente como prohibido se permite). Desde el punto de vista de seguridad, es mucho ms seguro tomar la actitud de que las cosas estn negadas por defecto. Y las reglas de conguracin deben reejarlos. Es necesario empezar por la posicin de negar todo y despus poner las reglas que permitan solo los protocolos que se permiten, entender las implicaciones que tiene en la seguridad es sumamente importante. La posicin de negarlo todo por defecto es mucho ms segura y mucho ms efectiva que permitirlo todo por defecto, lo que indica que permitiendo todo por defecto e intentando bloquear aquellas cosas que sabes que dan problemas. La realidad es que con esa aproximacin, nunca se sabe todos los posibles problemas, porque siempre aparece nuevos problemas y por lo tanto nunca se completa el trabajo. Hablando de manera prctica, la negacin de todo signica que las reglas de ltrado deben ser una lista pequea de las cosas que se permiten, seguido de un negado por defecto que cubra todo el resto de paquetes. Luego pasar a explicar como deben ser estas reglas.
4.6. Que hacer

Una vez un PC con ltrado de paquetes haya terminado de examinar un paquete, qu hacer con el paquete? Principalmente hay dos opciones siempre basndose en el las reglas de conguracin: 1. Pasar el paquete. Si el paquete pasa el criterio de ltrado, el router pasar 35
4.6 Que hacer
el paquete all donde indique la tabla de routing, que la direccin que debe seguir, como si fuera un router normal sin el ltrado de paquetes comportndose de manera transparente. 2. Eliminar el paquete. La otra accin obviamente es eliminar el paquete si falla en los criterios con que se ha congurado el ltrado. Sea unos u otros el tipo de paquetes, el ltrado de paquetes debe suministrar dos herramientas bsicas para el correcto funcionamiento, la primera es hacer un log de los paquetes que le hayamos indicado que haga y la otra es devolver paquetes ICMP indicando el tipo de error en caso de no dejar pasar el paquete. 4.6.1. Logging Independientemente de si se deja pasar o no el paquete, puede querer el administrador que se guarde la accin que se acaba de tratar. Especialmente cuando hay paquetes que se han eliminado, porque al ir en contra de las reglas de ltrado 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 ltrado de paquetes, pues fcilmente se sobresaturaran los discos adems de relentizar de manera drstica el ordenador. Pero si es necesario para cierto grupo de paquetes. Por ejemplo, puede ser interesante mantener un log de los paquetes TCP que indiquen comienzo de conexin haca un servicio Telnet de un router especco, as se guarda las conexiones que se hayan realizado para una posible conguracin. Aunque no todos las aplicaciones comerciales y no comerciales de ltrado de paquetes dejan hacer un log a los paquetes permitidos en mi aplicacin s se puede. Dependiendo de la implementacin del ltrado de paquetes hay diferentes formas de hacer log. Algunos guardarn solo la informacin especca sobre el paquete, otros en cambio guardarn el paquete entero para un posterior estudio. Generalmente, el ltrado de paqutes necesitar congurarse para hacer el log a otra parte mediante el servicio de syslog, que es independiente a la aplicacin. Porque es interesante no tener nicamente una copia de la provinencia de un ataque si el rewall se ha visto comprometido, pues es fcil eliminarlo y parecer que no ha habido tal ataque. 36
4.6.2. Paquetes ICMP
4.6 Que hacer
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 trco de la red y algo de tiempo al usuario que le ha sido negado el acceso, ya que al recibir un cdigo de error ICMP el host del usuario no debe reintentar y para inmediatamente, si no recibe ninguno puede tardar varios minutos esperando una respuesta. Hay dos grupos relevante de cdigos ICMP a escoger: 1. Los cdigos de destino inalcanzable o destination unreachable en particular el de ordenador inalcanzable o host unreachable y el cdigo de red inalcanzable o network unreachable segn el idioma. Los diseadores del primer grupo de cdigos de error ICMP disearon este grupo de host unreachable y el de network unreachable, para indicar algn problema serio en la red: el host o red destino ha caido o algo que en el nico camino al host o red ha caido. Estos errores se tratan devolviendo uno de estos errores en paquetes ICMP desde el router que haya descubierto el problema. Si cualquier mquina recibe un host unreachable para un host dado, asumir que el host se encuentra completamente inalcanzable y cerrar todas las conexiones hacia l, incluso si las otras conexiones se permitireron por el ltrado de paquetes. Por eso hay que tener cuidado a la hora de enviar este tipo de errores. 2. Los cdigos de destino administrativamene inalcanzable o destination administratively unreachable en particular dentro de este grupo el de ordenador administrativamente inalcanzable o en ingls host administratively unreachable y el cdigo de red administrativamente inalcanzable o como se encuentra en la literatura inglesa network administratively unreachable. Indican que el destino puede ser accedido porque no ha caido pero que no se deja pasar ningn paquete debido a la conguracin del sistema y que todo paquete a ese destino se ha bloqueado. Este segundo grupo de errores que pueden retornar un administrativamente inalcanzable se aadieron 37
4.6 Que hacer
hace unos aos al grupo de mensajes ICMP, especcamente para dar a los sistemas de ltrado de paquetes algo que poder retornar cuando eliminaban un paquete. Muchos sistemas pueden no reconocer estos cdigos, aunque tampoco deben causar ningn problema, porque los sistemas que reciben un cdigo que no entienden simplemente deben ignorarlo, que signica que es como si no se hubiera enviado ningn mensaje. Pero que no haga caso al mensaje es til de manera que al recibir este mensaje el sistema no se ver afectado. Cal es la correcta? De los dos grupos de mensajes a retornar, si retornamos uno del primer grupo host unreachable o bien el de network unreachable es tcnicamente incorrecto, recordar que los hosts puede o puede que no sean alcanzables, de acuerdo con la poltica de ltrado de paquetes, dependiendo a qu host est intentando acceder y a qu servicio. Tambin hay que recordar que este tipo de cdigos pueden causar en muchos sistemas una reaccin excesiva, como por ejemplo cerrando todas las conexciones que ya estn abiertas hacia ese host o red en cuestin. Si devolvemos un host administratively unreachable o un network administratively unreachable se advierte que el paquete que est siendo ltrado al destino desde ese origen. Estos cdigos tericamente, no deberan de tener una respuesta excesiva al llegar al ordenardor que intentaba originar la conexin. Hay otras consideraciones, por ejemplo, generando y retornando cdigos de error ICMP necesita un cierto tiempo y esfuerzo por parte del router o rewall con el software de ltrado de paquetes. Un atacante podra montarse un ataque de denegacin de servicio o denial of service segn se diga, saturando el router con paquetes que debera rechazar, generando paquetes con cdigos de error ICMP. Lo que se trata de proteger no es el ancho de banda de la red, sino la cantidad de carga sobre la CPU en el router o rewall en cuestin, y mientras est generando paquetes ICMP no est tratando paquetes entrantes. Por otra parte si no se retorna cdigos de error ICMP puede causar un exceso de trco en la red, pues el emisor puede intentar e intentar enviar paquetes que han sido eliminados. Este trco no debera de ser mucho, pues el nmero de paquetes bloqueados por el sistema de ltrado tiende a ser una fraccin del total de paquetes procesados. En caso de no 38
4.7 Filtrado por direccin
ser as es muy posible que se est bajo un ataque de DoS o denegacin de servicio. Por otra parte, retornando paquetes con cdigos de error ICMP para cada paquete que viola las polticas de ltrado, ests dando informacin a un atacante y un camino para probar el sistema de ltrado. Observando los paquetes que retorna una respuesta ICMP, un atacante puede descubrir que tipo de paquetes violan o no violan las polticas de seguridad. En tales casos no se debera dar esa informacin, porque simplica 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 congurado y actualizado. En cambio si no se retorna esa informacin con los cdigos de error ICMP el atacante necesita ms tiempo para averiguar la misma informacin, si acaso lo consigue. Devolviendo los cdigos de error ICMP se acelera los ataques, si reciben errores ICMP por algo no tienen q esperar el timeout. Como conclusin, lo ms seguro parece que es no retornar ningn cdigo de error ICMP a los paquetes eliminados. Si se puede lo que es interesante es poder retornar paqutes con cdigos de error ICMP a los sistemas internos, para que no esperen al timeout y por otra parte no retornarlo a los sitemas externos. An as si no se ofrece tal posibilidad se debe congurar el sistema para que est permitido los paquetes inbound ICMP y estar prohibido los paquetes outbound con cdigos de error ICMP.
4.7. Filtrado por direccin

4.7.1. Introduccin La forma ms simple, aunque no la ms comn, es el ltrado de paquetes ltrando segn la direccin. Filtrando de esta forma termite restringir el ujo de paquetes basado en la direccin origen y/o destino de los paquetes, sin cosiderar el protocolo que tratan. Este tipo de ltrado puede ser usado para permitir o no cierto ujo entre unos hosts internos a unos hosts externos, por ejemplo, por ejemplo se puede prever un ataque de spoong, simplemente prohibiendo paquetes inbound con una direccin origen que sea igual a una direccin vlida dentro de la red a proteger. 39
Por ejemplo vamos a decir que se quieren prohibir este tipo de ataques, se debera especicar esta regla: Direccin Inbound @ origen interna @ destino any Accin deny
Donde pone que la direccin es interna se reere a cualquier nmero IP de algn host de dentro de la red. En el router que haya entre la red interna e Internet, se podra aplicar en cualquier interfaz con paquetes inbound esta regla. Cuando se habla de inbound ser reere a la red interna que debemos proteger. 4.7.2. Riesgos Antes lo he comentado, no es seguro arse de las direcciones origen en las cabeceras IP ya que pueden suplantarse, pueden modicarse. Solo en caso de que se use algn tipo de autenticacin criptogrca entre t y el host al que se quiere hablar, no sabes si el que te est hablando es quien dice ser u otra mquina que pretende ser ese. Como he dicho antes hay que montarse algo usar otras tcnicas, ya sea en el mismo nivel de la torre OSI como por ejemplo IPSec o bien en niveles superiores de la torre OSI, por encima del nivel de transporte, como puede ser Secure SHell conocido como SSH, que intercambian claves de los servidores y no se basa nicamente en las IPs de las dos partes para crear una sesin, sino que usan encriptado. Hay dos tipos de ataques que se basan en esta forma de ataque de ataques spoong: los que se necesitan solo modicar la direccin origen y los de man in the middle, que ademas hay que mirar que se retorna.
40
El primer ataque spoong que se conoce se le atribuye a Kevin Mitnick uno de los hackers ms conocidos. El atacante enva paquetes que pretenden suplantar la identidad de algn ordenador al que se le tiene algn tipo de conanza, esperando que el ordenador atacante pueda usar esa conanza ataca al ordenador objetivo. Puede ser que el atacante no le importe retornar ningn paquete de la mquina atacada, ya que el resultado de los comandos enviados son predevibles, entonces no necesita estar en el camino de retorno entre el ordenador atacado y el ordenador que suplanta la informacin. En cambio es al contrario si se desea saber que le retorna al ordenador suplantado, ya que habr que situarse entre medio para que cuando le devuelva los paquetes el ordenador atacado al suplantado se puedan leer pero este es el segundo tipo de ataques. Ya que las respuestas se enviarn al ordenador suplantado y no al atacante. Tambin hay que tener una consideracin, que el ordenador suplantado recibir paquetes de conexiones que no entiende y de las que no participa, bogus connections como se le llama en ingls, entonces este ordenador enva paquetes con el bit de reset activado para terminar dichas conexiones. Lo que es malo para el atacante, pero es fcil de remediar, ya que se puede suplantar una mquina que no exista, destrozando a la mquina real mediante un ataque, inundando a la mquina suplantada, modicando la ruta entre la mquina atacada y la suplantada o bien usando ataques donde no sea importante el bit de reset. 41
5 EL SISTEMA OPERATIVO LINUX
5. El Sistema Operativo Linux

5.1. Introduccin
5.1.1. Historia A nales de los 40s el uso de computadoras estaba restringido a aquellas empresas o instituciones que podan pagar su alto precio, y no existan los sistemas operativos. En su lugar, el programador deba tener un conocimiento y contacto profundo con el hardware, y en el infortunado caso de que su programa fallara, deba examinar los valores de los registros y pneles de luces indicadoras del estado de la computadora para determinar la causa del fallo y poder corregir su programa, adems de enfrentarse nuevamente a los procedimientos de apartar tiempo del sistema y poner a punto los compiladores, ligadores, etc; para volver a correr su programa, es decir, enfrentaba el problema del procesamiento serial ( serial processing ). La importancia de los sistemas operativos nace histricamente desde los 50s, cuando se hizo evidente que el operar una computadora por medio de tableros enchufables en la primera generacin y luego por medio del trabajo en lote en la segunda generacin se poda mejorar notoriamente, pues el operador realizaba siempre una secuencia de pasos repetitivos, lo cual es una de las caractersticas contempladas en la denicin de lo que es un programa. Es decir, se comenz a ver que las tareas mismas del operador podan plasmarse en un programa, el cual a travs del tiempo y por su enorme complejidad se le llam "Sistema Operativo". As, tenemos entre los primeros sistemas operativos al Fortran Monitor System ( FMS ) e IBSYS. Posteriormente, en la tercera generacin de computadoras nace uno de los primeros sistemas operativos con la losofa 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 conictivos debido a que anteriormente las computadoras eran creadas para dos propsitos en general: el comercial y el cientco. As, al tratar de crear un solo sistema operativo para computadoras que podan dedicarse a un propsito, al otro o ambos, puso en evidencia la problemtica del trabajo en equipos de anlisis, diseo e implantacin 42
5.1 Introduccin
de sistemas grandes. El resultado fue un sistema del cual uno de sus mismos diseadores patentiz su opinin en la portada de un libro: una horda de bestias prehistricas atascadas en un foso de brea. Surge tambin en la tercera generacin de computadoras el concepto de la multiprogramacin, porque debido al alto costo de las computadoras era necesario idear un esquema de trabajo que mantuviese a la unidad central de procesamiento ms tiempo ocupada, as como el encolado o spooling de trabajos para su lectura hacia los lugares libres de memoria o la escritura de resultados. Sin embargo, se puede armar que los sistemas durante la tercera generacin siguieron siendo bsicamente sistemas de lote. En la cuarta generacin la electrnica avanza hacia la integracin a gran escala, pudiendo crear circuitos con miles de transistores en un centmetro cuadrado de silicio y ya es posible hablar de las computadoras personales y las estaciones de trabajo. Surgen los conceptos de interfaces amigables intentando as atraer al pblico en general al uso de las computadoras como herramientas cotidianas. Se hacen populares el MS-DOS y UNIX en estas mquinas. Tambin es comn encontrar clones de computadoras personales y una multitud de empresas pequeas ensamblndolas por todo el mundo. Para mediados de los 80s, comienza el auge de las redes de computadoras y la necesidad de sistemas operativos en red y sistemas operativos distribuidos. La red mundial Internet se va haciendo accesible a toda clase de instituciones y se comienzan a dar muchas soluciones ( y problemas ) al querer hacer convivir recursos residentes en computadoras con sistemas operativos diferentes. Para los 90s el paradigma de la programacin orientada a objetos cobra auge, as como el manejo de objetos desde los sistemas operativos. Las aplicaciones intentan crearse para ser ejecutadas en una plataforma especca y poder ver sus resultados en la pantalla o monitor de otra diferente (por ejemplo, ejecutar una simulacin en una mquina con UNIX y ver los resultados en otra con DOS ). Los niveles de interaccin se van haciendo cada vez ms profundos. LINUX hace su aparicion a principios de la decada de los noventa, era el ao 1991 y por aquel entonces un estudiante de informatica de la Universidad de Helsinki, llamado Linus Torvalds empezo, -como una acion y sin poderse imaginar a lo que llegara este proyecto, a programar las primeras lneas de cdigo 43
5.1 Introduccin
de este sistema operativo llamado LINUX. Aqu est el primer mensaje que Linus Torvalds mand al grupo de noticias comp.os.minix:
From:torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroup: comp.os.minix Subject: GCC-1.40 and a posix question Message-ID: 1991Jul13, 100050.9886@klaava.Helsinki.FI Date: 3 Jul 91 10:00:50 GMT Hello netlanders, Due a project Im working on (in minix), Im interested in the posix standard definition. Could somebody please point me to a (preferably) machine-readable format of the latest posix rules? Ftp-sites would be nice. Linux Torvalds torvalds@kruuna.helsinki.fi Y aqu el que le sigui, este mensaje es considerado por muchos como el comienzo de Linux:
From:torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroup: comp.os.minix Subject: What would you like to see most in minix? Summary: small poll for my new operating system Message-ID: 1991Aug25, 20578.9541@klaava.Helsinki.FI Date: 25 Aug 91 20:57:08 GMT Organization: University of Helsinki. Hello everybody out there using minixIm doing a (free) operating system (just a hobby, wont be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. Id like any feedback on things people like/dislike in minix; as my OS resembles it somewhat (same physical layout of the 44
5.1 Introduccin
file-sytem due to practical reasons) among other things. Ive currently ported bash (1.08) an gcc (1.40), and things seem to work.
This implies that ill get something practical within a few months, and Id like to know what features most people want. Any suggestions are we but I wont promise Ill implement them :-) Linux Torvalds torvalds@kruuna.helsinki.fi Este comienzo estuvo inspirado en MINIX, un pequeo sistema Unix desarrollado por Andy Tanenbaum. Las primeras discusiones sobre Linux fueron en el grupo de noticias comp.os.minix, en estas discusiones se hablaba sobre todo del desarrollo de un pequeo sistema Unix para usuarios de Minix que queran ms. Linus nunca anunci la version 0.01 de Linux (agosto 1991), esta versin no era ni siquiera ejecutable, solamente inclua los principios del ncleo del sistema, estaba escrita en lenguaje ensamblador y asuma que uno tena acceso a un sistema Minix para su compilacin. El 5 de octubre de 1991, Linus anunci la primera versin "Ocial" de Linux, -version 0.02. Con esta versin Linus pudo ejecutar Bash (GNU Bourne Again Shell) y gcc (El compilador GNU de C) pero no funcionaba mucho ms. En este estado de desarrollo ni se pensaba en los trminos soporte, documentacin, distribucin, etc. Despus de la versin 0.03, Linus salt en la numeracin hasta la 0.10, ms y ms programadores a lo largo y ancho de Internet empezaron a trabajar en el proyecto y despus de sucesivas revisiones, Linus increment el nmero de versin hasta la 0.95 (Marzo 1992). Ms de un ao despus (diciembre 1993) el ncleo del sistema estaba en la versin 0.99 y la versin 1.0 no lleg hasta el 14 de marzo de 1994. La serie actual del ncleo es la 2.4.x y sigue avanzando da a da con la meta de perfeccionar y mejorar el sistema. En el momento de escribir este documento la versin actual del kernel es la 2.4.19. 5.1.2. Linux En la pgina web del kernel de Linux (www.kernel.org) se encuentra esta descripcin, que creo que explica en pocas palabras qu es Linux. 45
5.1 Introduccin
< <Linux is a clone of the operating system Unix, written from scratch by Linus Torvalds with assistance from a loosely-knit team of hackers across the Net. It aims towards POSIX and Single UNIX Specication compliance. It has all the features you would expect in a modern fully-edged Unix, including true multitasking, virtual memory, shared libraries, demand loading, shared copy-on-write executables, proper memory management, and TCP/IP networking. Linux was rst developed for 32-bit x86-based PCs (386 or higher). These days it also runs on (at least) the Compaq Alpha AXP, Sun SPARC and UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64 and CRIS architectures. Linux is easily portable to most general-purpose 32- or 64-bit architectures as long as they have a paged memory management unit (PMMU) and a port of the GNU C compiler (gcc). > >[LT1] 5.1.3. Caractersticas Esta es una lista de las principales caractersticas que tiene Linux: 1. Todo el cdigo fuente est disponible, incluyendo el ncleo completo y todos los drivers, las herramientas de desarrollo y todos los programas de usuario; adems todo ello se puede distribuir libremente. Hay algunos programas comerciales que estn siendo ofrecidos para Linux actualmente sin cdigo fuente, pero todo lo que ha sido gratuito sigue siendo gratuito. 2. Multitarea: La palabra multitarea describe la habilidad de ejecutar varios programas al mismo tiempo. Linux utiliza la llamada multitarea preeventiva, la cual asegura que todos los programas que se estn utilizando en un momento dado sern ejecutados, siendo el sistema operativo el encargado de ceder tiempo de microprocesador a cada programa mediante el scheduler. 3. Multiusuario: Permite tener muchos usuarios usando la misma mquina al mismo tiempo, pero a cada uno de ellos le da la sensacin de tener la mquina para ellos nicamente.
46
5.1 Introduccin
4. Multiplataforma: Las plataformas en las que en un principio se dise utilizar Linux son 386-, 486-. pero luego vinieron toda la familia Pentium y seguidores que pertenecen a la familia i386 que son PCs de 32 bits, Amiga y Atari, tambin existen versiones para otras plataformas, como Alpha de Compaq, ARM, MIPS, PowerPC tanto de 32 como de 64 bits, Sun SPARC, UltraSPARC, el ltimo procesador de Intel el IA-64, y muchos otros ms. 5. Multiprocesador: Soporte para sistemas con ms de un procesador est disponible para Intel y SPARC. 6. Funciona en modo protegido. 7. Tiene proteccin de la memoria entre procesos, de manera que uno de ellos no pueda colgar el sistema. 8. Carga de ejecutables por demanda: Linux slo lee del disco aquellas partes de un programa que estn siendo usadas actualmente. 9. Poltica de copia en escritura para la comparticin de pginas entre ejecutables: esto signica que varios procesos pueden usar la misma zona de memoria para ejecutarse. Cuando alguno intenta escribir en esa memoria, la pgina (4Kb de memoria) se copia a otro lugar. Esta poltica de copia en escritura tiene dos benecios: aumenta la velocidad y reduce el uso de memoria. 10. Memoria virtual usando paginacin (sin intercambio de procesos completos) a disco: A una particin o un archivo en el sistema de archivos, o ambos, con la posibilidad de aadir ms reas de intercambio sobre la marcha. Un total de 16 zonas de intercambio de 128Mb de tamao mximo pueden ser usadas en un momento dado con un lmite terico de 2Gb para intercambio. Este lmite se puede aumentar con el cambio de unas cuantas lneas en el cdigo fuente, que lo est haciendo Oracle, para su distribucin. 11. La memoria se gestiona como un recurso unicado para los programas de usuario y para el cach de disco, de tal forma que toda la memoria libre puede ser usada para cach y sta puede a su vez ser reducida cuando se ejecuten grandes programas. 47
5.1 Introduccin
12. Libreras compartidas de carga dinmica (como los cheros so de Solaris o los cheros DLLs de windows) y libreras estticas. 13. Se realizan volcados de estado (core dumps) para posibilitar los anlisis post-mortem, permitiendo el uso de depuradores sobre los programas no slo en ejecucin sino tambin tras abortar stos por cualquier motivo. 14. Compatible con POSIX, System V y BSD a nivel fuente. Control de tareas POSIX. 15. Emulacin de iBCS2, casi completamente compatible con SCO, SVR3 y SVR4 a nivel binario. 16. Emulacin de 386 en el ncleo, de tal forma que los programas no tengan que hacer su propia emulacin matemtica. Cualquier mquina que ejecute Linux parecer dotada de coprocesador matemtico. Por supuesto, si el ordenador ya tiene una FPU (unidad de coma otante), esta ser usada en lugar de la emulacin, pudiendo incluso compilar tu propio kernel sin la emulacin matemtica y conseguir un pequeo ahorro de memoria. 17. Soporte para muchos teclados nacionales o adaptados y es bastante fcil aadir nuevos dinmicamente. 18. Consolas virtuales mltiples: varias sesiones de login a travs de la consola entre las que se puede cambiar con las combinaciones adecuadas de teclas (totalmente independiente del hardware de video). Se crean dinmicamente y puedes tener hasta 64. Dispone tambin de Pseudo-terminales (ptys). 19. Soporte para varios sistemas de archivo comunes, incluyendo minix-1, Xenix y todos los sistemas de archivo tpicos de System V, y tiene un avanzado sistema de archivos propio con una capacidad de hasta 4 Tb y nombres de archivos de hasta 255 caracteres de longitud. Est el sistema de archivos ext-3, ext-2 y el ReiserFS como los sitemas de archivo ms comunes. Acceso transparente a particiones MS-DOS (o a particiones OS/2 FAT) mediante un sistema de archivos especial: no es necesario ningn comando especial para usar la particin MS-DOS, esta parece un sistema de archivos normal 48
5.1 Introduccin
de Unix (excepto por algunas restricciones en los nombres de archivo y permisos). Las particiones comprimidas de MS-DOS 6 no son accesibles en este momento, y no se espera que lo sean en el futuro. JFS o Journalist File System para Linux, hecho por IBM. El soporte para VFAT, FAT32 (WinNT, Windows 95/98/ME) se encuentra soportado desde la version 2.0 del nucleo y el NTFS de WinNT / Win2000 / WinXP desde la version 2.2. Este ltimo solo en modo lectura, se puede hacer escrituras pero no es recomendado. Tambin dispone de un sistema de archivos especial llamado UMSDOS que permite que Linux sea instalado en un sistema de archivos DOS. Soporte en slo lectura de HPFS-2 del OS/2 2. Sistema de archivos de CD-ROM que lee todos los formatos estndar de CD-ROM. 20. Incluidas en el ncleo tenemos una gran cantidad de protocolos de red como por ejemplo: TCP/IP tanto IPversion 4 como IPversion6. Appletalk compatible con redes Apple. Software cliente y servidor Netware. IPX, AX.25, X.25, DDP, Netrom, etc. 21. Dispone de servidores para protocolos HTTP (Apache Web Server, khttpd, etc), FTP (transferencia de cheros: wu-ftpd, proftpd, etc), SMTP (transferencia de correo: Postx, Sendmail, Qmail, etc), NFS, SMB entre otros muchos. Lan Manager / Windows Native (SMB) es un software cliente y servidor, para poder compartir cheros e impresoras en redes Microsoft 1 con funciones de servidor como funciones de cliente. 22. Sistemas de multicomputacin. Soporte para MPI y PVM, directamente o con sistemas como Beowulf. LVS (Linux Virtual Server), etc 23. Y otras tantas virtudes de este Sistema Operativo que mantiene la comunidad de Internet y empresas como Oracle, Sun Microsystems, IBM, CompaqHP, Dell etc a parte de las propias empresas de cada distribucin como Red Hat, Debian, Suse, etc que entre todas y todos dan soporte a este sistema operativo. Aunque la mejor virtud son los miles de programas a travs de Internet distribuidos gratuitamente o con licencias de libre distribucin. Visitando pginas web se
1 Microsoft
es marca registrada de Microsoft Corporation
49
5.2 El Kernel
pueden encontrar miles de aplicaciones que ya estn hechas y al disponer del cdigo fuente pueden mejorarlas. Tambin existe una gran comunidad que resuelve cualquier problema que pueda surgir al kernel. Las respuestas a los problemas de seguridad han demostrado ser ms rpidas que muchas empresas.
5.2. El Kernel
5.2.1. Introduccin El Kernel puede verse como el corazon del sistema operativo, cargado en la memoria RAM cuando se enciende el ordenador y permanece en funcionamiento hasta que este se apaga. Tiene principalmente dos responsabilidades: 1. Servir a los requerimientos de programacin a bajo nivel (por ejemplo tratando las interrupciones hardware). 2. Proveer un entorno a los procesos, que son las instancias en ejecucin de los programas o threads. Se dice que el kernel de Linux es monoltico, que es como un gran ejecutable, que consiste de muchos componentes divididos lgicamente. 5.2.2. Modos El Kernel puede trabajar en dos modos: usuario o kernel. La mayora de las ejecuciones de programas de los usuarios se hacen en modo usuario o user mode como se dice en ingls. Este modo de ejecucin no tiene acceso directo a las estructuras de datos del kernel o a los equipos hardware. Puede cambiarse a modo kernel de varias formas: 1. Un programa hace una llamada al sistema o system call, por ejemplo cuando una funcin de una libreria hace una peticin al kernel. 2. Una seal de excepcin provinente de la CPU, que son condiciones que requieren especial atencin, por ejemplo en una divisin por cero.
50
5.2 El Kernel
3. Una interrupcin que se hace hacia la CPU provinente de algn equipo hardware indicando que requiere su atencin, como por ejemplo cada vez que apretamos cualquier tecla desde el teclado. El kernel se pasa la mayora del tiempo en el modo kernel ejecutndose detrs de los procesos de usuario. Adems hay muchos threads que se estn ejecutando detrs del propio kernel en modo kernel, que se encargan de hacer las actividades necesarias para mantener en funcionamiento al sistema operativo. Una vez que todas las operaciones pendientes en modo kernel se han completado y tratado, el kernel vuelve al modo usuario otra vez. 5.2.3. Mdulos El kernel es capaz de cargar dinmicamente porciones adicionales de cdigo (mdulos) mientras se est ejecutando, para mejorar su funcionalidad. Por ejemplo, hay mdulos que pueden aadir soporte para sistemas de cheros que no es necesario que estn cargados siempre. Cuando la funcionalidad proveida por el mdulo ya no se necesita ms, el mdulo puede ser descargado, liberando memoria. 5.2.4. Procesos Un proceso es una instancia de un programa en ejecucin. Cada proceso tiene: 1. Un estado, ya sea running (ejecutndose en el procesador), sleeping (durmiendo, un proceso que est esperado que un evento se termine), runnable o ready (listo para ser ejecutado y esperado en la cola de procesos), stopped (parado ya sea por una seal de control o porque estn haciendole un trace) o zombie (zombie el proceso esta apunto de ser eliminado). 2. Un contexto, una copia con todos los registros de la CPU que indican el estado del proceso (PC, SP, PSW, registros de propsito general, registros de coma otante y regsitros para el control de memoria) 3. Un descriptor de procesos, es una estructura de datos del tipo task_struct que guarda toda la informacin relacionada con un proceso. 51
5.2 El Kernel
El kernel se encarga de poner un entorno multiprogramable, lo que indica que se puede tener muchos procesos activos a la misma vez. Cada proceso dispone de los recursos hardware disponibles para l, y es el kernel el encargado de controlar que los recursos se comparten correctamente. Multiprogramming implica que todos los procesos que estn en la cola de procesos esperando tendrn su oporturnidad para ejecutarse en la CPU en turnos. El proceso que controla la CPU en un instante de tiempo se le llama current porque es el programa que esta corriendo en ese momento. El proceso que se encarga de decidir quien es el que pasa a estado ready o un estado de ejecutandose es el scheduler o context switch, porque se encarga de cambiar el contexto actual. El cometido de este es guardar el contexto actual del proceso ejecutndose (una foto del estado de la CPU en ese momento) y cargar el contexto de algn proceso que este esperando para ser ejecutado, o un proceso con el estado de ready. Los cambios de contexto solo pueden hacerse cuando el kernel est en modo usuario, as que en el modo kernel no pueden hacerse cambios de contexto inmediatamente por eso se le llama non-preemptive. Cada proceso de usuario se ejecuta en su propio espacio de usuario, una porcin asignada del total de memoria disponible. Espacios de usuario (o partes de l) pueden compartirse entre procesos si se pide, o bien automticamente si el kernel lo cree apropiado. La separacin del espacio de direcciones hace que un proceso no pueda interferir con una operacin de otro proceso o del sistema operativo. Adems de los procesos normales de usuario ejecutndose en el sistema, hay varios threads del kernel que se crean al iniciar el sistema y que corren permanentemente en modo kernel, encargandose de funciones de mantenimiento del kernel. 5.2.5. Sincronizacin El kernel es reentrante, varios procesos pueden estar ejecutndose en modo kernel a la vez. Por supuesto, en un sistema con solo un procesador solo un proceso puede ejecutarse, porque el resto de procesos estn bloqueados esperando en una cola. Ejemplo: un proceso pide leer un chero, el sistema virtual de cheros el Virtual File System traduce la peticin en una operacin de bajo nivel del disco y lo pasa al controlador del disco, por detrs del proceso. En vez de esperar hasta que la operacin de escritura a disco se haya completado, miles de ciclos de CPU
52
5.2 El Kernel
ms tarde, el proceso da voluntariamente a la CPU despus de hacer la peticin y el kernel permite que otro proceso esperando pueda ejecutarse en la CPU y este a su vez puede entrar en el modo kernel. Cuando una operacin a disco se a completado (sealado por una interrupcin de hardware), el proceso actual da la CPU al que trata las interrupciones (el interrupt handler) y el proceso original se despierta, siguiendo su estado a donde lo haba dejado. Para poder implementar un kernel reentrante, hay que tener especial cuidado para asegurar la consistencia de las estructuras de datos del kernel. Si un proceso modica un contador de otro proceso esperando sin que este lo sepa, el resultado puede ser potencialmente desastroso. Hay que seguir los siguientes pasos para preever este tipo de sucesos: 1. Un proceso solo puede reemplazar a otro en modo kernel si ha dejado voluntariamente la CPU, dejando las estructuras de datos en un estado consistente, de ah que se le llame al kernel non-preemptive. 2. Hay que deshabilitar las interrupciones en regiones crticas, donde el cdigo tiene que completarse sin ninguna interrupcin, y asegurarse luego de volver a habilitarlas. 3. El uso de spin locks y semforos de control para acceder a estructuras de datos. Los semforos consisten en un contador inicializado a uno, una lista de procesos esperando para acceder a la estructura de datos y dos mtodos atmicos llamados up() y down() que incrementan y decrementean el contador respectivamente. Cuando se accede a una estructura protegida por un semforo, se llama a la funcin down(), si el valor del contador es cero o positivo (no negativo vaya), entonces el acceso est garantizado, si no es as y el acceso esta negado signica que est bloqueado y que el proceso se aade a la lista del semforo de procesos esperando. De forma parecida, cuando un proceso ha terminado de tratar los datos de la estructura, llama a la funcin up() y el siguiente proceso de la lista consigue acceder. Hay que tomar precauciones, porque hay que asegurarse que no hay deadlocks entre varios procesos, en el caso de que controlen varios recursos. Si cada uno est 53
5.2 El Kernel
esperado un recurso controlado por otro proceso y este a su vez esta esperando un recurso controlado por el primer proceso se dice que existe un deadlock o abrazo de la muerte porque se esperan innitamente hasta que uno de los dos deje el otro recurso, pero al estar los dos en un estado de espera jams lo harn. Si se quiere profundizar en deadlocks buscar por Internet el problema de los lsofos que cenan o dicho en ingls The dining Philosophers Problem o en cualquier libro de sistemas operativos. 5.2.6. Comunicacin entre procesos Una seal es un mensaje corto, enviado entre dos procesos o entre el kernel y un proceso. Hay dos dipos de seales que se usan para noticar eventos a del sistema a los procesos: Eventos asncronos. Por ejemplo SIGTERM, enviado cuando se usa el Ctrl-C del teclado. Errores o excepciones sncronas. Por ejemplo SIGSEGV cuando un proceso intenta acceder a una direccin ilegal. Hay cerca de 20 seales diferentes denidas en el estandart POSIX, algunas de ellas pueden ser ignoradas. Algunas seales no pueden ser ignoradas y no son tratadas siquiera por el proceso mismo. Linux usa el sistema V o System V de comunicacin entre procesos llamado en ingls Inter-Process-Comunication (IPC). 5.2.7. Control de la Memoria Linux usa memoria virtual, un nivel de abstraccin entre los pedidos de memoria por parte de los procesos y las direcciones fsicas de la memoria. As hace posible lo siguiente: 1. Permite que muchos procesos corran incluso cuando la suma de toda la memoria exceda la RAM fsica disponible. 2. Hace posible tambin un espacio de direcciones contigua, independiente a la organizacion de la memoria fsica. 54
5.2 El Kernel
3. Paginado, porciones de datos o cdigo que solo necesitan cargarse en memoria cuando se ejecutan o son accedidos y pueden intercambiarse a disco cuando no son necesarios. 4. Imgenes compartidas de programas y librerias, haciendo un uso ms eciente de la memoria. 5. Recolocacin de los programas en memoria de forma completamente transparente. El espacio de direcciones se divide en porciones de 4kBytes llamadas pginas, las cuales forman la unidad bsica de todas las transacciones de la memoria virtual. Como la suma total de direcciones de memoria excede a lo que hay en la memoria RAM, solo un grupo de todas las pginas disponibles se guardan en la RAM a la vez. An as, un pgina tiene que estar presente en la RAM para poder acceder a ella ya sea para leer o guardar datos como para ejecutar programas. Como cualquier pgina puede volver a ponerse en cualquier pgina fsica, el kernel tiene que llevar el control de donde estan las pginas usadas. Y adems hacer la conversin de direcciones lgicas en direcciones fsicas. En el hardware Intel x86, Linux usa dos nivels de paginacin (aunque internamete usa tres niveles para mejorar la portabilidad) para reducir la cantidad de memoria usado pora las tablas de paginacin. Para convertir una direccin lgica en una fsica, las tablas se consultan en este orden: Page Global Directory luego la Page Table para conseguir el nmero de pgina y el offset de la pgina. Por eso una direccin lgica se divide en tres partes: Directorio, Tabla y Offset. Como se puede direccionar un espacio de 4GBytes (usando 32 bits) y se usa una pgina del tamao de 4kB, los 10 bits ms signicativos de la direccin apuntan al directorio, los 10 siguientes bits apuntan a la tabla (de ah que se requiera identicar la pgina) y los 12 siguientes bits, los menos signicativos, nos marcan el offset dentro de la pgina. 5.2.8. El cdigo El cdigo fuente del kernel est hecho de alrededor de dos millones de lneas de cdigo. Puede parecer muy intimidatorio, pero es importante recordar que muy 55
5.2 El Kernel
poca gente entiende todos los subsitemas y el cdigo asociados a ellos en profundidad. Se puede mejorar la productividad simplemente sabiendo donde buscar el cdigo especco. Paso a comentar qu se puede encontrar en el cdigo fuente y donde va cada cosa. Para empezar es necesario bajarse la ltima versin del kernel de http://www.kernel.org la versin actual es la 2.14.19. Pero es recomendable visitar la pgina web, ya que seguro que hay nuevas actualizaciones.
(bash)$ wget http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.19.tar.gz Tras ello se descomprime y se accede al directorio: (bash)$tar xvzf linux-2.4.19.tar.gz (bash)$cd linux-2.4.19 (bash)$dir direcciones total 248 drwxr-xr-x 18 carlosm grp -rw-r--r--rw-r--r-drwxr-xr-x drwxr-xr-x drwxr-xr-x drwxr-xr-x drwxr-xr-x drwxr-xr-x drwxr-xr-x drwxr-xr-x -rw-r--r--rw-r--r-drwxr-xr-x drwxr-xr-x -rw-r--r--rw-r--r-1 carlosm 1 carlosm 28 carlosm 39 carlosm 45 carlosm 25 carlosm 2 carlosm 2 carlosm 2 carlosm 2 carlosm 1 carlosm 1 carlosm 2 carlosm 28 carlosm 1 carlosm 1 carlosm grp grp grp grp grp grp grp grp grp grp grp grp grp grp grp grp 56 4096 Aug 3 02:39 arch/
18691 Aug 3 02:39 COPYING 79410 Aug 3 02:39 CREDITS 4096 Feb 25 19:41 Documentation/ 4096 Feb 25 4096 Feb 25 2002 drivers/ 2002 fs/
4096 Aug 3 02:39 include/ 4096 Feb 25 2002 init/ 4096 Dec 21 2001 ipc/ 4096 Feb 25 2002 kernel/ 4096 Nov 22 2001 lib/ 41643 Aug 3 02:39 MAINTAINERS 18710 Aug 3 02:39 Makefile 4096 Feb 25 2002 mm/ 4096 Feb 25 2002 net/ 14239 Aug 3 02:39 README 2815 Apr 6 2001 REPORTING-BUGS

-rw-r--r-drwxr-xr-x 1 carlosm 4 carlosm grp grp 9291 Aug 4096 Aug
5.2 El Kernel
3 02:39 Rules.make 3 02:39 scripts/
Todo este enjambre de cheros est organizado lgicamente en una estructura de directorios. Documentation: Informacin sobre plataformas y devices especcos igual que informacin general sobre el kernel. arch: Cdigo especco para cada arquitectura: i386, sparc, alpha, arm, cris, ia64, mips, mips64, parsic, ppc (PowerPC 32bits), ppc64(PowerPC 64bits), s390, s390x, sparc, sparc64. drivers: Cdigo para cada device especco: tarjeta de sonido, tarjeta ethernet, etc fs: Cdigo para los sistemas de cheros o Filesystems: ext2, ext3, vfat, etc include: Todos los cheros de cabecera separado en subdirectorios de acuerdo con el tipo chero y su funcin. init: Todo el cdigo asociado con el proceso de arranque e inicializacin. IPC: Cdigo de la comunicacin entre procesos o Inter Process Communication: implementacin de la memoria compartida, etc kernel: El cdigo del ncleo del kernel, la parte ms importante de Linux son solo 396KBytes y 31 cheros: scheduling, seales, printk, fork, softirq, contextos, tiempo, cargador de mdulos, etc lib: Libreras relacionadas con el kernel, por ejemplo descompresin de la imagen del kernel, funciones de lock, etc mm: Memory Managment todos los cheros con el cdigo de trato de memoria. net: Todo el cdigo relacionado con la red. Aqu es donde le meter mano para crear el rewall. scripts: Scripts relacionados con el kernel, como por ejemplo el patch-kernel. 57
5.2 El Kernel
El mejor lugar para empezar leyendo el cdigo depende de las motivaciones que tenga cada uno, yo por mi parte fui directamente al directorio net, al directorio kernel y al directorio include, el resto de directorios casi no los he visitado, pero claro mi intencin es construir un rewall, cada uno tendr sus motivos. Si por ejemplo, se desea escribir un driver para un hardware que todava no est soportado, en ese caso se empieza leyendo el cdigo para los drivers ms parecidos que ya estn implementados. Dicen los hackers del kernel que la mejor forma de introducirse a la programacin del kernel es escribiendo drivers, ah queda eso para los interesados. En cambio si lo que se desea es escribir un nuevo sistema de cheros la idea es buscar dentro del directorio fs algo que se parezca a lo que queremos implementar. Si en cambio se desea jugar con la programacin dentro del kernel haced lo que yo hice que fue probando en la inicializacin del sistema, en init/main.c, especcamente en la funcin start_kernel() o bien ojeando los cheros que hay en el directorio kernel. 5.2.9. Numeracin Si se desea hacer cambios e introducir cdigo en el kernel para contribuir en el desarrollo, es importante entender el ciclo de desarrollo adoptado por la comunidad del kernel de Linux. Paso a comentar el proceso de desarrollo: Series estables Las series estables tienen el nmero de versin con tericamente casi ningn bug para ser arreglado o ninguna mejora para hacer. La mayora de distribuciones usan estas series, y si no se quiere uno aventurar encontrando bugs y fallos es recomendable usar estas releases para trabajar. Las peores series que hay se marcan con una extensin de -dontuse (dont use: no usar) en el nombre del chero. Estas son por ejemplo las 2.0, 2.2.x y las 2.4.x que son nmeros pares y a medida que van saliendo nuevas versiones se va aumentando el nmero de la serie, ahora las ltimas versiones estables para 2.0 es la 2.0.39 para la serie de kernels 2.2 se termin con la 2.2.22 y ahora mismo (a la hora de escribir este documento) la ltima versin estable del kernel de Linux es la 2.4.19, la anterior fue la 2.4.18 y la 58
5.2 El Kernel
siguiente a la actual se supone ser la 2.4.20, que hasta que salga esta van apareciendo unos prepatchs que muestra las actualizaciones, que se llaman los parches intermedios, que normalmente se le aade -pre ms el nmero de versin del prepatch. Series inestables Los kernels inestables contienen menos cdigo probado y los cambios entre las series son ms grandes. Sirven para provar los nuevos drivers, las mejoras experimentales y los algoritmos ms inovadores. La ltima versin beta del kernel de Linux es la 2.5.38. Generalmente, es muy mala idea ejecutar un kernel inestable en un sistema que est en produccin. Lo recomendado es tener un ordenador dedicado para hacer el testing con kernels inestables. Parches intermedios Entre dos releases de kernels estable e inestable, hay varias releases intermedias que intentan testear un pequeo nmero de cambios a la vez. Estas releases tienen o bien la extensin -preXX o bien la extensin -YYXX, donde XX es el nmero de la versin incrementada y el YY son las iniciales de quien lo mantiene, por ejemplo -ac12 indica incrementalmente la extensin de Alan Cox. Al parche intermedio actual est numerado como 2.4.20-pre7. 5.2.10. Compilacin del ncleo Si se va a modicar el ncleo es necesario luego compilarlo e instalarlo en la mquina. Al hacer el rewall, cada vez que modicaba cualquier cosa tambin tena que compilar e instalarlo, as que es una parte importante del proceso. No es necesario compilar el ncleo en la misma mquina en la que va a correr el kernel, yo lo que hago personalmente es que de todas las mquinas que tengo la ms rpida es la encargada de hacer la compilacin, y luego se pasa la imagen al ordenador. Es recomendable descomprimir el kernel en el directorio /usr/src y tener cada versin en su directorio de forma ordenada. por regla general se pone la versin 59
5.2 El Kernel
actual, la que va a correr en el sistema, en el directorio /usr/src/linux. Pero es solo una recomendacin, no es necesario que sea as. En el caso de ser una versin nueva, sin haberse compilado ninguna vez, no es necesario hacer un make clean, para ms adelante antes de hacer nada es recomendable hacerselo, as se elimina cdigo compilado que puede molestar. Vayamos a la compilacin: Primero descompilar el kernel. tar xvzf lnux-x.y.z.tar.gz El x.y.z corresponde a la versin actual del kernel, que corresponde al chero bajado. En caso de tener la extensin .bz2 es necesario descomprimirlo primero y luego hacerle un tar mediante la orden siguiente: bz2cat linux-x.y.z.tar.bz2 | tar xvf Despus de bajarse la ltima versin del kernel y descomprimirlo es necesario entrar dentro del mismo directorio y empezar a congurar. Entrar en el directorio que se acaba de descompilar, y ahora es hora de conguar el kernel con todas los mdulos, drivers y opciones que queramos o necesitamos incluirle al kernel. Dependiendo de lo que estemos usando se congurar de una manera o de otra. Existe principalmente tres maneras de congurar el kernel: 1. make cong 2. make menucong 3. make xcong Cada una de ellas dependiendo de si disponemos X windows o si solo podemos usar un menu basado en texto con la consola. Yo uso preferiblemente las XWindos en mi entorno de trabajo (no en los servidores), as que uso la tercera opcin. make xconfig Aparecer entonces un men con todas las preguntas que debemos responder, agrupadas por temas. A cada una de las preguntas se debe responder con un y 60
5.2 El Kernel
o bien con un n, la primera es para aceptar esa parte de cdigo y la segunda para no incluirlo. Puede haber en el caso de los drivers por ejemplo, una tercera opcin m que signica module y es para compilar el mdulo pero no se incluye directamente en el kernel, sino que como un mdulo cargable. Es como decir quizs lo uso. Igualmente cada una de las opciones tiene un si no entiede lo que quiere decir ponga un ... si o no, en cada caso particular. Para hacer este paso es necesario saber unas cuantas cosas del sistema, como por ejemplo que tipo de tarjeta de red disponemos, que tipo de tarjeta de video, y esas cosas, porque sino dicilmente os funcionar por ejemplo la tarjeta de red. Para una informacin ms detallada de cada grupo de opciones leer el Kernel-HOWTO, donde aparece mucho ms detallado. Cuando se termina de congurar, se preparar las dependencias en poco tiempo, a menos que su PC sea muy lento. Tambin ser necesario hacer un make clean, para borrar todos lo cheros objeto y otras cosas que las versiones anteriores han dejado, se recomienda hacerlo cada vez que se recompile el kernel. make dep make clean Despus de preparar dependencias, puede ejecutar make zImage o make zdisk (esta es la parte que tarda ms tiempo). make zImage compilar el ncleo y lo dejar comprimido en arch/i386/boot/zImage junto a otros cheros. Con make zdisk el nuevo ncleo se copiar adems en el disquete que est puesto en la disquetera A:. zdisk es interesante para probar ncleos; si explota (o simplemente no hace nada) se quita el disquete de la disquetera y podr arrancar el ncleo antiguo. Adems sirve para arrancar si borr accidentalmente el ncleo del disco duro. Tambin puede usarlo para instalar nuevos sistemas simplemente volcando el contenido de un disco en otro. Los ncleos recientes estn comprimidos, con una z comenzando su nombre. Un ncleo comprimido se descomprime automticamente al cargarse el sistema. make zImage Existen ms makes, por ejemplo con make mrproper har una limpieza mucho ms intensa. Esta suele hacer falta cuando se actualiza (parchea) el ncleo. Pero 61
5.2 El Kernel
esta opcin borra tambin su chero de conguracin del ncleo, as que guarde una copia del correspondiente chero .cong si cree que le interesa. La opcin make oldcong intentar congurar el ncleo con un chero de conguracin anterior. Aunque a partir del 2.0.xx no es necesario, make recuerda la ltima conguracin. Para evitar todo el proceso del make cong. Si no se ha compilado anteriormente el ncleo o no se tiene un chero de conguracin anterior, no se debe elegir pues se instalar la conguracin por defecto. Una vez que tenga un nuevo ncleo que parezca funcionar como desea, ser el momento de instalarlo. Casi todo el mundo utiliza LILO (LInux LOader) para esto. Con make zlilo se instalar el ncleo ejecutando LILO, quedando listo para rearrancar, pero esto solo funcionar si LILO est bien congurado para su sistema: el ncleo es /vmlinuz, LILO est en /sbin y la conguracin de LILO (/etc/lilo.conf) es coherente con lo anterior. Pero no es difcil hacerlo paso a paso, adems se puede compilar un kernel en un ordenador ms potente y luego pasarlo a otro sistema, en tal caso no funciona. El chero de conguracin ser como ste: image = /vmlinuz label = Linux root = /dev/hda1 ... La lnea image = apunta al ncleo instalado actualmente. Casi siempre es /vmlinuz. label es el identicador usado para seleccionar qu sistema arrancar, y root es el disco o particin a usar para el directorio raz. Ahora se copia el chero zImage, que se ha creado antes, que normalmente est en arch/i386/boot y se llama bzImage. Copiar el chero este y nombrarlo de alguna manera para reconocerlo y no confundirlo con otras versiones del kernel. Por ejemplo vmlinuz-x.y.z, donde x.y.z es la versin actual del kernel compilado. Copiarlo al directorio /boot, para tenerlo todo bien ordenado. cp arch/386/boot/bzImage /boot/vmlinuz-versionactual Y entrar en el chero /etc/lilo/cong o bien /etc/lilo.conf segn la distribucin, para la conguracin del LILO. 62

vim /etc/lilo.conf
5.2 El Kernel
All aadir las lneas necesarias para la nueva versin del kernel que acabamos de compilar. Nombrar con el label al nuevo sistema. image = /vmlinuz label = Linux root = /dev/hda1 ... image=/boot/bzImage-versionactual label=miNuevoLinux root=/dev/hda1 # Atencion!! read-only En donde pone /dev/hda1 hay que asegurarse de poner el nombre bien, en este ejemplo tenemos /dev/hda1 que corresponde a la particin primera del primer disco duro. Pero no signica que sea as en todos, en mi disco duro por ejemplo el directorio raiz corresponde a la quinta particin. Por eso en mi sistema tengo /dev/hda5. Pero tambin podra estar en el disco duro scsi, por lo que sera /dev/sda5. Bueno tener cuidado porque sino pegar una petada increhible. Tras haber incluido estas lneas en el chero de conguracin del LILO, es necesario ejecutarlo para que tenga efecto la nueva conguracin. Esto se hace de la siguiente manera: lilo Para arrancar uno de los antiguos ncleos, se copia las lneas anteriores incluyendo image = xxx al principio del chero de conguracin de LILO, y se cambia image = xxx por image = yyy donde yyy es el nombre de camino completo al chero de la copia de seguridad guardada. Tambin es necesario cambiar label = zzz por label = linux-backup y reejecute LILO. Puede ser que necesite poner una lnea en el chero con delay=x donde x son las centsimas de segundo que LILO esperar antes de arrancar con la primera opcin, de modo que pueda interrumpirse (con la tecla SHIFT) y seleccionarse qu ncleo desea arrancar (tecleando la etiqueta (label) asignada). 63
5.2 El Kernel
La rdenes make modules; make modules_install compilarn los mdulos que hayamos seleccionado, y los instalarn. No olvidar ejecutar depmod -a en cuanto hayamos arrancado con dicho ncleo. En caso de que estemos compilando por segunda vez una misma versin de ncleo, y hayamos variado el nmero de mdulos a compilar, es posible que la ejecutar make dep nos encontremos con un mensaje de error; esto se debe a que los antiguos mdulos que no hayamos compilado ahora no son borrados. Pueden borrarse tranquilamente. Y ya est, reiniciar el sistema y escoger la nueva versin en la lista que muestra el lilo. Y lo lgico es que todo funcione correctamente. Pero qu pasa si hay problemas? El principal problema es que no se haya ejecutado el comando lilo. Para esos casos lo mejor que puede hacerse ahora es arrancar con un disquete, preparar otro disquete para arrancar Linux, con make zdisk se hace uno fcilmente, aunque debamos haberlo hecho antes si es el mismo sistema con el que compilamos el kernel y el que nos da el problema (mucho cuidado en esos casos, en serio). Necesita saberse qu sistema de cheros raz (/) tiene, dnde est y su tipo (por ejemplo, ext2 o minix). Tambin hay que saber dnde estn los cheros de /usr, en otra particin. En nuestro ejemplo, / (el directorio raz) es /dev/hda1, y el sistema con las fuentes del ncleo es /dev/hda3, montado como /usr normalmente (que es donde tenemos /usr/src que estaba el kernel compilado). Ambos son sistemas ext2. La imagen compilada estar en el sistema de las fuentes. La idea es que si hay un chero zImage correcto, puede salvarse en un disquete. En primer lugar, arranque con un disquete de instalacin o de rescate, y monte el sistema de cheros que contenga el ncleo a usar: mkdir /mnt mount -t ext3 /dev/hda3 /mnt Tener en cuenta que los sistemas de cheros con los actuales kernels es el ext3 pero puede ser tambin un reiserfs o bien un ext2, segn el caso. Si mkdir le dice que el directorio ya existe, no hay problema. Ahora, pase al directorio donde est el ncleo compilado. De esta forma tenemos que /mnt + /usr/src/linux/arch/i386/boot /usr = /mnt/src/linux/arch/i386/boot
64
5.3 Herramientas
Ponga un disco con formato en la unidad A: (que no sea el disquete con el que ha arrancado) y copie el ncleo a l: cd /mnt/usr/src/linux/arch/i386/boot dd if=zImage of=/dev/fd0 rdev /dev/fd0 /dev/hda1 Vaya a / y desmonte el sistema de cheros: cd / umount /mnt/usr Ahora puede rearrancar el sistema desde el disquete. No olvides ejecutar LILO! Hay otra alternativa. Si el ncleo est en el directorio raz (por ejemplo /vmlinuz), puede usarlo para un disquete de arranque. Suponiendo las condiciones anteriores, haramos los cambios siguientes en el ejemplo anterior: /dev/hda3 por /dev/hda1 (el sistema raz), /mnt/src/linux por /mnt, y if=zImage por if=vmlinuz. El resto puede ignorarse. Usar LILO con discos grandes (de ms de 1024 cilindros) puede dar problemas. Le recomendamos que lea el mini-HOWTO sobre LILO para ms informacin.
5.3. Herramientas
Esta seccin pretende explicar las herramientas fundamentales para el desarrollo del kernel. Tenemos que son necesarios los editores de texto, programas para desarrollo, para navegar por el cdigo y para debugar. Las herramientas de debugar se explican en el siguiente apartado. 5.3.1. Editores de texto Hay una gran cantidad para escoger editores de texto. Cada uno es partidario de uno, se han hecho debates para saber qu editor es el mejor para trabajar en la programacin del kernel. Entre los que est la discusin es entre el editor vim y el emacs. Pues explicar ambos por encima, aunque yo soy de los partidarios del vim. 65

vim
5.3 Herramientas
Como todo sistema UNIX, Linux tambin tiene el editor vi disponible, y sino el vim (vi-improved que viene a decir el vi-mejorado) con algn contenido extra. Las razones para usar vim en la programacin dentro del kernel son: 1. Integra de una forma limpia los ctags. Si se hacen tags en el directorio del cdigo del kernel, se puede acceder rpidamente a las funciones y a las deniciones de las variables usando las teclas Ctr-] mientras el cursor est sobre la funcin o variable en cuestin. 2. El auto-completado de los nombres de variables y funciones puede ahorrar el tiempo evitando errores de deletreo. Esto es especialmente interesante cuando se programa el kernel ya que la mayora de nombres son bastante largos. As que al usar esta herramienta, solo hay que escribir la primera parte de la variable o de la funcin y apretar Ctrl+P repetidamente mientras va buscando todos los posibles matches. 3. Es rpido de cargarse. 4. Ocupa poco y deja ms memora para la recompilacin del kernel. 5. Altamente congurable. Entre otras cosas, los comandos que se accionan con las teclas se pueden volver a mapear fcilmente. Es muy til si se encuentra algn comando que se usa mucho y tiene una combinacin de teclas incmoda. 6. Est integrado con el cscope. Para hacer bsquedas rpidas del cdigo. 7. Muchas veces se puede encontrar este fntastico programa en discos de arranque de rescate los llamados rescue boot disk. 8. Los accesos directos del teclado hace que se requiera muy poco movimiento de manos, al menos si no se ha modicado el mapeado. Probablemente la mejor forma de aprender los fundamentos ms bsicos del vim sea leer el vim-HOWTO que se puede encontrar en http://www.tldp.org/HOWTO/VimHOWTO.html 66

emacs
5.3 Herramientas
Como el vi, el emacs est en muchos sistemas y tiene tambin muchos fans. Las razones para usar emacs en la programacin del kernel son varias: 1. Tiene gran cantidad de libreras para mejorar la productividad. 2. Buena integracin con los etags. 3. Tambin integra bsquedas con grep y cscope. 4. Integracin con gdb, muy til a la hora de debugar cdigo. 5. Las teclas de uso pueden ser ms intuituvas, por ejemplo no es necesario tener que entrar en ningn modo para empezar a escribir inmediatamente en un documento. Y es por eso que es el editor preferido por aquellos que no les gusta hacer las cosas tan formales. Los inconvenientes que tiene son tambin varios. 1. Se usa mucho la tecla Ctrl. Se recomienda mapear las teclasl Ctrl a otra, como por ejemplo Caps-Lock. 2. Es un gran paquete, no es recomendable para sistemas con espacio limitado en el disco duro. 3. Tarda ms en cargarse en sistemas ms modestos. 4. Necesita ms memoria, as que deja menos memoria a la hora de recompilar el kernel. 5. Dicen que los etags son inestables y que les dan core dumpeds muy frecuentemente. La mejor manera de trabajar con el emacs es trabajando con el tutorial, el cual puede accederse accediendo al emacs y apretando las teclas Ctr+h y luego t.
67

5.3.2. Herramientas de desarrollo make
5.3 Herramientas
El programa make es fundamental y bsico. Es el que se usa para determinar qu partes de un proyecto con muchos cheros cdigo fuente necesitan ser reconstruidos. Solo aquellos cheros de cdigo que hayan sido modicados sern reconstruidos antes del nal de la fase lincaje. Esta propiedad es una gran mejora para el programador del kernel, porque una vez el kernel est construido recompilarlo para incluir los cambios tarda muchsimo menos que si tuviera que hacerlo todo. El make trabaja con un chero makele, es un chero que contiene todas las relaciones y dependencias entre cheros fuente, entre junto con los comandos necesarios para construirlos y compilarlos. En cada directorio del kernel se encuentra un chero makele, incluyendo el chero raz. Cuando se invoca el comando make dep o make bzImage o bien el make modules, make opera desde el nivel ms alto y trabaja recursivamente con todos los cheros makele de cada uno de los subdirectorios, dependiendo de las opciones con que se incluyeron en el paso de conguracin. lclint Algunos errores de programas se pueden resolver al principio del ciclo de desarrollo, ahorrando tiempo y esfuerzo. Puede que no importe este tipo de programas cuando se analiza cdigo normal, con programas de menor envergadura, pero los bugs en el kernel son ms difciles de tratar y pueden hacer aparecer problemas muy serios. Adems mientras un usuario, est ms o menos acostumbrado a que se pare o haga core dumps un cliente de correo por ejemplo, pero lo que no est acostumbrado y no puede acostumbrarse es a que el sistema operativo se congele o peor an que pierda datos. lclint es un programa que puede ser usado para checkear el cdigo C de manera esttica, que signica hacer checks o comprobaciones antes que se haya compilado o ejecutado. Como lint, lclint puede ser ejecutado para recoger errores comunes de C. Sin embargo, lcint puede hacer mucho ms para ti, pero para ello hay que aprender a como usarlo anotando en el cdigo comentarios de una manera espe-
68
5.3 Herramientas
cca. En resumen, lclint puede dar facilidad a la hora de comprobar errores antes de pasar el compilador. Para averiguar ms informacin buscar en la pgina http://lclint.cs.virginia.edu/. 5.3.3. Navegacin Una de las actividades que ms se hace cuando se empieza a programar con el kernel es navegar arriba y abajo por todo el cdigo, al menos hasta que uno se familiariza con la gran cantidad de cdigo fuente. Hay herramientas que facilitan esta navegacin. grep grep se usa para encontrar lneas que concuerden con un patron dado. Es una herramienta muy til para localizar de una forma rpida deniciones de variables o de funciones. Por ejemplo queremos buscar todas los cheros 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 cheros y directorios (*) del rbol de cdigo e imprime todos los los nombre de cheros (-H) y el nmero de lnea (-n) donde aparece sk_buff, el resultado de la bsqueda es recomendable volcarlo a un chero para luego poder navegarlo. El resultado de la bsqueda anterior es muy larga, debido a que es una estructura de los datos que recibimos por las tarjetas de red y cada driver tiene una, adems de ser la estructura dentro del kernel de los datos que se reciben. An as aqu pongo el resultado de unas cuantas lneas:
net/bluetooth/hci_core.c:1028:int hci_send_acl(struct hci_conn *conn, struct sk_buff *skb, __u16 flags) net/bluetooth/hci_core.c:1031: struct sk_buff *list; 69
5.3 Herramientas
net/bluetooth/hci_core.c:1074:int hci_send_sco(struct hci_conn *conn, struct sk_buff *skb) net/bluetooth/hci_core.c:1140: struct sk_buff *skb; net/bluetooth/hci_core.c:1168: struct sk_buff *skb; cscope cscope permite navegar por por el cdigo de forma parecida a como lo hace grep, pero es ms inteligente y provee una interfaz mucho ms bonita para trabajar. Se puede buscar por deniciones, usos, strings, etc Antes de poder usar cscope se necesita construir un chero ndice. Puede hacerse con el comando cscope -b -R -k En el directorio raz de la aplicacin. -b para construir el ndice, -R para buscar recusrivamente a travs del rbol de directorios y -k para indicar que estamos usando el kernel para navegar, esto asegura que se incluye los cheros de forma correcta al generar el ndice. Darse cuenta que el ndice debera construirse a partir de un rbol limpio y recin descomprimido, as que es recomendable guardar una copia del chero .cong y ejecutar un make mrproper en el directorio raz del cdigo fuente. Para empezar a trabajar con una sesin cscope, usar el comando cscope -d con lo que se consigue entrar en un men parecido a este:
Cscope version 15.3
Press the ? key for help
Find this C symbol: Find this global definition: Find functions called by this function: 70

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
5.3 Herramientas
Arriba de la pantalla se usa para mostrar los resultados de las bsquedas, mientras que la torre de abajo se usa para insertar comandos; Por ejemplo, suponiendo que se quiere encontrar la denicin de la estructura de datos _system_type. Usando las teclas con las echas se mueve el cursor para encontrar esta denicin global en Find this global denition: escribir la estructura de datos que queremos buscar. Si todo funciona correctamente cscope abre el editor congurado, usando la variable de entorno EDITOR, y se mostrar la secin apropiada del chero en cuestin. Por ejemplo queremos encontrar la denicin de super_block. Siguiendo los pasos comentados antes veramos la siguiente salida por pantalla: Global definition: super_block File Line 0 vxfs_extern.h 44 struct super_block; 1 super.c 265 int (*test)(struct super_block *, 2 udfdecl.h 3 fs.h 4 fs.h 5 udf_fs_sb.h struct buffer_head *); 52 struct super_block; 688 struct super_block 936 struct super_block *(*read_super) (struct super_block *, void *, int ); 71 __u32 (*s_partition_func)(struct super_block *, __u32, __u16, __u32);
Find this C symbol: Find this global definition: Find functions called by this function: Find functions calling this function: Find this text string: 71

Change this text string: Find this egrep pattern: Find this file: Find files #including this file:
5.3 Herramientas
Esta vez, cscope ha encontrado ms de una denicin posible. As que se ver la lista de cada una de las deniciones en su contexto y apretando uno de los nmeros que se mestran en la lista, o bien usando la tecla Tabulador para moverse de uno a otro por la pantalla y con las teclas de direccin seleccionar una denicin. Al salir del editor se vuelve al cscope. Apretando otra vez el Tabulador podemos retornar al rea de comandos. Para salir del cscope apretar un simple Ctrl+d. La documentacin para el cscope est disponible en la red en la pgina del cscope: http://cscope.sourceforge.net/ 5.3.4. Manipuladores diff Diff es un programa que se usa para comparar dos cheros y luego listar las diferencias entre ellos. Cuando se usa en modo unied, con la opcin -u, para comparar dos cheros, el original y el modicado, 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 modicaciones es mucho ms inteligente y a la vez eciente que distribuir cheros enteros o rboles de directorios con cdigo fuente. El proceso anterior se puede usar cuando tenemos solo un chero modicado, pero que pasa si tenemos muchos cheros modicados y queremos producir un patch. Pues es lo mismo pero ahora hay que cambiar las opcciones del programa diff: diff -urN linux-2.4.19 linux > my_hefty_kernel_patch 72
5.3 Herramientas
Darse cuenta que generalmente se usa el direcotrio raz para generar patches por ejemplo si se tiene el kernel descomprimido en /usr/src se tiene el directorio modicado en el /usr/src/linux y el limpio, sin modicaciones, en /usr/src/linux-2.4.19. Si se quiere generar un patch y enviarlo a la liasta de distribucin del kernel de linux la Linux Kernel Mailing List, hay que asergurarse de seguir las instrucciones correctamente y exactamente como dicen en el FAQ que puede encontrarse en http://www.tux.org/lkml/. patch patch es un programa que se usa para aplicar parches, producidas por el programa diff, a un chero o a un directorio de cdigo fuente. es necesario entrar por ejemplo, si se va a pasar del kernel linux-2.4.18 al linux-2.4.19 habra que hacer los siguiente: cd linux-2.4.18 patch -p1 patch-2.4.19 Esto produce un upgrade o mejora del directorio 2.4.18 al 2.4.19. La opcin -p1 se usa en el directorio raz de todos los nombres de cheros que indica en el patch. Se podra aplicar el parche desde un directorio ms abajo, pero eso signica que se debera tner todos los directorios nombrados de la misma manera que en el ordenador donde se cre el patch o parche. Algunos parches se distribuyen en cheros comprimidos para ahorrar ancho de banda. Se puede ahorrar chero de descompresin del patch si se aplica de la siguiente manera: bzip2 -dc /usr/src/patch-2.4.19.bz2 | patch -p1 Reemplazar bzip2 por tar o gzip segn se cre el chero. Una script que est incluido en el directorio del cdigo fuente del kernel que es muy til, se usa para generer de manera semi automtica el proceso de upgrade del directorio aplicando sucesivos parches: linux/scripts/patch-kernel. Leer el script para ver qu es lo que hace y cmo se usa, las instrucciones estn puestas entre los comentarios al principio del chero. En el caso de querer quitar un parche que se aplicado con anterioridad es necesario escribir la siguiente orden, con la orden de -R (remove): 73
5.3 Herramientas
bzip2 -dc /usr/src/patch-2.4.19.bz2 | patch -R -p1 5.3.5. Control de versiones RCS Cualquier desarrollo del trabajo es un proceso incremental, particularmente si se est en la fase de debugacin. Siempre se inenta mantener de todos los cambios hechos en el proceso suando alguna forma de control de revisiones, as si hubiera un cambio erroneo se podra volver al rebs facilmente. Una forma muy bsica de revisin de control del sistema puede hacerse simplemente haciendo una copia backup de un chero antes de hacer cambios importantes, pero esta aproximacin tiende a ser muy ineciente rpidamente, sobre todo en el caso de estar modicando varios cheros a la vez. Las soluciones son varias, entre ellas tenemos RCS y CVS. El primero de ellos el RCS es el hermano pequeo de CVS. CVS en cambio es genial para proyectos grandes con muchos contribuidores y programadores, pero es demasiado trabajo para proyectos pequeos donde solo hay un programador o unos pocos. Por eso una de las ventajas que tiene RCS es la simplicidad. Primero se debe crear un directorio llamado RCS en el mismo directorio que donde estn los cheros de cdigo fuente. mkdir RCS Luego introducir o como dicen los ingleses hacer el check in del chero, por ejemplo para el chero some-le.c hacer: ci -u some-file.c Tras ello se pedir insertar una breve descripcin. Por defecto, RCS borra el chero de trabajo al hacer el check in, as que es interesante poner la opcin -u para comprobar automticamente si existe un chero igual, y no borrarlo automticamente. Es recomendable hacerlo as con todos los cheros que se introduzcan. Hacer algunos cambios en uno de los cheros que se hayan introducido. Luego intentar hacer el check in del chero en cuestin, se mostrar un lista de cambios y el nmero de versin se ver incrementado. 74
5.3 Herramientas
Suponer que se ha hecho unos cambios erroneos y se quiere volver hacia atrs, y revertir a una versin buena que sabamos que funcionaba correctamente, por ejemplo la versin 1.4, entonces hacer el check out del chero usando este comando: co -l -r1.4 some-file.c La opcin -l hace un lock del chero y te da permisos de escritura para modicarlo, sino solo se tiene permisos de lectura. RCS guarda el chero inicial y solo las diferencias que existe entre versiones, ahorrando espacio de disco. Para saber ms informacin sobre RCS, ver las pginas man de: rcs, ci, co, rcsintro, rcsdiff, rcsclean, rcsmerge, rlog, rcsle y el ident. La pgina web donde se puede bajar el software de forma gratuita y donde se encuentran el tutorial est en http://www.gnu.org/software/rcs/rcs.html. CVS Mientras que el RCS es bueno para proyectos donde se usa un pequeo nmero de cheros, pero se convierte intil para cheros ms grandes donde hay un gran nmero de contribuidores donde haya ms de un desarrollador. CVS es particularmente la mejor idea, adems es el programa ms usado en la comunidad de Internet, donde casi todos los proyectos, incluido el del kernel, se llevan usando CVS. CVS tiene muchos comandos que estn incluidos en el propio cvs, estos se llaman sub-comandos del cvs. Ambos a los comandos cvs y a los subcomandos se les puede pasar opciones, pero la posicin dentro de la lnea de comandos debera ser as: $ cvs [cvs options] sub-command [sub-command options] Aqu paso una breve lista de los subcomandos disponibles: add: este comando aade un nuevo chero al control de cdigo. Es necesario hacer un check in del chero suando cvs ci despus de este comando ara que tenga efecto el cambio.
75
5.3 Herramientas
ci o bien commit: ci que signica check in tiene la misma funcin que commit, estos comandos harn el check in de los cambios que se hayan hecho a la copia local de un chero en cuestin. Despus de introducir este comando, cualquier update o check out del chero que est en el repostorio se vern los cambios que has hecho con el ci. Se puede especicar con la opcin -m mensaje la opcin de proveer un mensaje describiendo el cambio. Cuando se introducen (check in) los cambios y la copia local de los cheros no son actualizados, cvs mostrar un mensaje informndote de esto mismo. En este caso, hay que hacer un update de los cheros y entonces hacer un check in con los cambios. Para comprobar los cambios in todos los cheros modicados en el directorio de trabajo, hay que ejecutar el siguiente comando desde desde la raz del directorio de trabajo: cvs -q ci -m mensaje bla bla bla co o bien checkout: Este comando hace una copia local de todos los cheros en un mdulo que estn en el servidor cvs. Primero, crear un subdirectorio con el mismo nombre que el mdulo, entonces copiar los cheros al subdirectorio. diff: Este comando mostrar las diferencias entre la copia local y el chero que nos hemos bajado anteriormente del repositorio. Antes he hablado de como usar este comando. history: Este comando printa la informacin sobre el repositorio cvs. Por defecto, este comando solo muestra informacin que te pertenece a ti. Si se usa la opcin -a (all) mostrar la informacin de todos los usuarios. La siguiente lnea es til para ver los cambios histricos.
cvs history -a -o # Show checked out files$ cvs history -a -T # Show all tags$ cvs history -a -e # Show all information import: Este comando podr un proyecto existente dentro del repositorio.
76
5.3 Herramientas
cvs import -m "blah blah ..." directory vendorTag releaseTag log: Este comando printar los mensajes que se especicaroon en cada uno de los cheros que se introdujeron (check in). remove: Este comando borrar un chero del control de cdigo. Si tras hacer esto se hace un check out de un mdulo, no se encontrar copia de este chero. An as, si hacen un check out de una versin anterior del mdulo, se podr recuperar esa versin anterior de ese chero. tag: Para hacerles un tag a los cheros en el directorio de trabajo actual, se debe ejecutar la siguiente lnea de comandos cvs -q tag NombreDelTag update: Este comando har un update de la copia local de los cheros de un mdulo. Para cualqier chero que se le haga el update, se printa el nombre prededido con una U. As se permite imprimir los nombres de los cheros que se han modicado. Por ejemplo, aquellos que son diferente de la copia del repositorio y entonces preceden con una M. Para listar los documentos que se han modicado dentro del directorio de trabajo actual, se debe ejecutar la siguiente orden desde la raz del directorio de trabajo: cvs -q update El repositorio de cvs se debe especicar usando la opcin -d en el comando cvs o tambin se puede hacer con la variable de entorno CVSROOT. Por ejemplo de la primera forma sera: cvs -d pathName login Y de la segunda manera se escribira: export CVSROOT=pathName$ cvs login
77
5.3 Herramientas
En el caso que el repositorio estuviera en el mismo sistema, la opcin es muy simple y solo habra que escribir el path al repositorio, por ejemplo /usr/src/cvs, y se hara de la siguiente manera: export CVSROOT=/usr/local/cvs Pero en el caso que el repositorio est en otro sistema, que es lo ms normal, y lo que sucede con el kernel de Linux, en la especicacin del repositorio debe incluirse el mtodo de acceso, el nombre del usuario y el nombre del servidor donde est localizado el repositorio. Cada uno de estos items, el mtodo de acceso, el nombre del usuario y el nombre del servidor, y el path del repositorio en el servidor, deben estar separados por dos puntos. Y entre el nombre de usuario y el del servidor debe ir una arroba @. Se hace de la siguiente manera:
export CVSROOT=:accessMethod:userName@serverName:pathName Por ejemplo para Linux Top of Tree, versin 2.4, debemos usar el siguiente comando. Este respositorio es una copia (mirror) que se actualiza cada 30 minutos. export CVSROOT=:pserver:cvs@vger.samba.org:/vger$ cvs loginPassword: cvs$ cd some-directory # Por ejemplo, /usr/local/src$ cvs -z3 co linux Y para hacer un update del cdigo fuente hay que usar la siguiente orden: cd some-directory/linux$ cvs -z3 update -d Esta es solo una presentacin del CVS, que es muy extenso, para ms informacin dirigirse a la pgina ocial del proyecto CVS: http://www.cvshome.org/ Y aqu termina la seleccin de aplicaciones para poder trabajar dentro del kernel.
78
5.4 Netlter en los kernels 2.4
5.4. Netlter en los kernels 2.4

Como ya coment un rewall est integrado dentro del sistema operativo. La cuestin es que a la hora de disear el actual sistema de ltrado de paquetes, el Netlter, Rusty Russell compaginaba su trabajo con Alan Cox. Los dos se mantenan en contacto para realizar el nuevo sistema que hay en los kernels 2.4. Este trabajo conjunto hace que el sistema de captura de paquetes comentado antes y el sistema Netlter estn muy relacionados. Es por eso que el proyecto se ver inuenciado por este sistema, ya que hay unos puntos concretos por donde se asegura que pasan todos los sk_buffs de entrada. Y es esa razn la que hace que sea importante entender correctamente como funciona este sistema y luego decidir donde insertar las funciones que se encargan de capturar los datos guardados en estructuras sk_buff para hacerles luego el ltrado. El sistema actual de ltrado de paquetes pone 5 tipos diferentes de hooks o ganchos:
PRE_ROUTING ROUTE IP_FORWARD ROUTE IP_POST_ROUTING
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 nettler el gancho de NF_IP_PRE_ROUTING. Luego los datos entran en el cdigo de routing, donde se decide a dnde se enva los paquetes, si se destina a otra interfaz o si es para un proceso local. El cdigo de routing puede eliminar aquellos paquetes que no tengan una ruta disponible. Si se destina para el ordenador en s, se le llama a la funcin del netlter 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 netlter y se le marcar como que ha entrado
79
por el tercer hook, el NF_IP_FORWARD. Entonces el hook del netlter pasa por el cuarto hook, el NF_IP_POST_ROUTING antes de pasarse a la tarjeta de red donde se enviar al cable. Existe todava un quinto hook, el NF_IP_LOCAL_OUT los datos pasan por aqu si se han creado localmente. Esta es la forma que tiene el actual sistema para capturar los paquetes, pero es el mismo sistema que quiero utilizar yo? pues no, es lgico que este inuenciado, todos los rewalls trabajan de una forma parecida, pero tiene inconvenientes y tambin sus ventajas. 5.4.1. Ventajas La principal caracterstica es que tiene 5 hooks, cuando antes en los kernels 2.2 solo tena 3 hooks. Bueno entonces ellos (Rusty Russell principalmente) habrn creido que es mejor. Y es que de esta forma se controla perfectamente a un paquete. En los rewalls anteriores se ltraba al paquete tanto cuando llega, como cuando pasa por el forward y cuando sala. Ahora adems se controla cuando los paquetes van dirigidos a algn programa del sistema o cuando lo ha generado alguien del sistema. Eso aade control y hace que se puede poner polticas de seguridad para controlar caballos de troya o rootkits que se puedan instalar dentro del sistema. Es una mejora sustancial respecto a los antiguos kernels. Pero esta mejora de control se puede plantear tambin como un problema. Y es una de las razones por las que me propuse hacer este rewall. 5.4.2. Inconvenientes El principal inconveniente es que un paquete pasa por muchos hooks, pasa muchas veces por todas las polticas del rewall y cada vez que se pasa por un hook se comprueba para cada una de las polticas y las sesiones abiertas si cumple o no, si se elimina el paquete o no. La intencin es tener un control completo de los paquetes que pasan por el sistema, y esa es la mayor ventaja, pero se pierde en tiempo, que un paquete pase por tres ltros o incluso si se inserta un rewall proxy puede llegar a pasar por cuatro ltros tiene un coste en tiempo. Rusty Russell insert la idea de hacer una cache para los paquetes, y dentro de la estructura sk_buff se ha aadido nuevos datos, como puede leerse en include/linux/skbuff.h: 80

struct sk_buff { ...
... #ifdef CONFIG_NETFILTER /* Can be used for communication between hooks. */ unsigned long /* Cache info */ nfmark;
__u32 nfcache; /* Associated connection, if any */ struct nf_ct_info *nfct; #ifdef CONFIG_NETFILTER_DEBUG unsigned int nf_debug; #endif #endif /*CONFIG_NETFILTER*/ ... } Donde aade una cache para cada paquete, y as, cuando se pasa por un ltro se marca que cosas se ha hecho en la cache y luego en los otros ltros no vuelve a hacer los mismos chequeos. Es contradictorio poner tantos ltros para luego tener que montar un sistema por encima para saltrselos. Otro inconveniente de este sistema es que es una topologa est pensada para hacer funciones de rewall y a la vez de servidor. Hay tres encargados de mirar el ltrado 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 rewall tiene que ser solo eso, un rewall, no se le debe poner ningn servicio en l, tiene que ser unordenador bastin y el nico servicio que debe tener es el de SSH para hacer conexiones remotamente y poder administrarlo. Sin servicios en el rewall, no es necesario montar los dos hooks restantes para controlar los troyanos. Por denicin un rewall tiene que ser un equipo rpido y con pocos o ningn servicio disponible.
81
5.5 Viaje de un paquete
5.5. Viaje de un paquete

5.5.1. Introduccin Tras hacer las respectivas pruebas, tras compilar el kernel, insertadar pequeos programas dentro del kernel, despus de debugar para ver como funciona el proceso de debugar y de tener los esquemas de como funcionar el rewall. Es la hora de averiguar donde se debe poner el ltrado de paquetes dentro del kernel. La documentacin [WS1] habla de unos cheros 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 chero ip_output.c que se encarga de tratar todos los paquetes que salen del ordenador. En dicha documentacin [WS1] aparece como se trata la informacin y los datos. Pero en el libro de Stevens se trata un sistema Unix, que tericamente debe ser igual en un sistema Linux. Se trata de averiguar como viaja un paquete cualquiera por el sistema operativo, y all donde se crea que es mejor insertar el rewall. Y la idea es coger el paquete y pasarlo compararlo con las polticas de seguridad. Que es un paquete bueno, pues se deja donde estaba y que continue su viaje por la capa OSI del sistema operativo. Que es malo, entonces se borra, dar cuenta de ello al sistema operativo y hacer un log si el usuario lo cree conveniente. 5.5.2. Tarjeta de red La tarjeta ethernet es un dispositivo hardware del nivel 1 y 2 de la capa OSI, es una tarjeta con sus chips, circuitos y microcontroladores. Esta tiene una direccin particular, que siempre es diferente para cada una de las tarjetas de red que hay en el mundo. Esta direccin es la MAC. La tarjeta est siempre escuchando los paquetes que pasan por su interfaz, cuando ve un paquete cuya direccin MAC corresponde a la suya propia, o bien un paquete con una direccin de broadcast (FF:FF:FF:FF:FF:FF para las Ethernet) entonces empieza a leer los datos y los carga en su memoria. Cuando termina de leer todo el paquete, la tarjeta genera una peticin de interrupcin. La rutina que se encarga de servir la interrupcin y que trata la peticin es parte del driver de la tarjeta, que es parte del sistema operativo en s, el cual
82
ejecuta con las interrupciones deshabilitadas las siguientes operaciones: 1. Crear una nueva estructura sk_buff, dedinida en el chero include/linux/skbuff.h, la cual representa la visin que tiene el sistema operativo de un paquete. 2. Vuelca los datos de informacin del buffer de la tarjeta de red en la nueva estructura creada sk_buff, algunos drivers usando la DMA. 3. Llama a la funcin netif_rx(), que es la funcin que se encarga de recibir los datos de la tarjeta de red. 4. Al terminar la funcin netif_rx(), el sistema operativo vuelve a activar las interrupciones y termina el servicio de interrupcin. La funcin netif_rx() prepara el kernel para el siguiente paso de la recepcin. Pone la informacin del sk_buff dentro de lo cola de paquetes de entrada para que la CPU pueda tratarlo y marca la NET_RX softirq (que es una interrupcin por software que luego hablar de ellas) para que pueda ser tratada, y esto se hace mediante la llamada a la funcin __cpu_raise_softirq( ), denida dentro del chero include/linux/interrupt.h. En el caso de que la cola este llena de paquetes este ltimo paquete se descarta y se pierde. Luego si tenemos una cola para cada CPU, ambos procesadores pueden procesar los datos (es una de las mejoras del nuevo kernel al aadir softirqs) lo que hace que la recepcin de paquetes sea concurrente en mquinas Multiprocesador. Si se desea ver un driver de una Ethernet en accin, se puede mirar algn driver sencillo como por ejemplo en el chero drivers/net/8390.c. La rutina de servico que trata la interrupcin se llama ei_interrupt( ), y llama a la funcin ei_recive( ), la cual hace lo siguiente: 1. Crea una nueva estructura sk_buff mediante la funcin dev_alloc_skb( ). Y vuelca los datos con la funcin skb_put( skb, pkt_len). 2. Lee el paquete del buffer de la tarjeta con la funcin ei_block_input( ) y sealiza el protocolo con skb->protocol= eth_type_trans(skb,dev) 3. Llama a la funcin netif_rx( ) comentada antes. 83
4. Y vuelca todos los datos, segn el contador rx_pkt_count vuelca diez paquetes consecutivamente. Se puede hechar una ojeada a otros ejemplos mucho ms complejos como pueden ser los driver de cualquier tarjeta 3COM, por ejemplo los cheros 3c59x.c, donde usa transferencia por DMA para mover el paquete desde la memoria de la tarjeta al sk_buff. 5.5.3. Proceso de red La funcin netif_rx( ) es muy importante, se encarga de recibir los paquetes de una tarjeta de red mediante el driver y en cola para que pueda ser tratado por niveles superiores de la capa OSI dentro del sistema operativo. Acta de puente para todos los paquetes que se recogen entre los diferentes drivers de todas las tarjetas de red, y haciendo de entrada a los protocolos. Al estar esta funcin en un contexto de interrupcin tiene que ser rpida y corta. No puede hacer ningn chequeo del tamao o cualquier otra compleja funcin, ya que el sistema est potencialmente perdiendo paquetes mientras se est ejecutando el netif_rx( ). As lo que hace la funcin es basicamente seleccionar la cola del paquete de un array llamando a softnet_data, el ndice del cual se basa en la CPU donde se est ejecutando. Enconces luego comprueba el estado de la cola, identicando uno de los cinco posibles estados de congestin: NET_RX_SUCCESS (sin congestin), NET_RX_CN_LOW, NET_RX_CN_MOD, NET_RX_CN_HIGH (baja, moderada y alta congestin, respectivamente) o bien NET_RX_DROP (el packet se pierde debido a una congestin crtica). Es un proceso para defenderse de los ataques DoS, donde una sobrecarga de los paquetes puede llegar a cargar el kernel de tal manera que no funcione. Aunque bajo condiciones normales, el paqute se inserta en la cola (__skb_queue_tail( )) y la funcin __cpu_raise_softirq( ) se llama. La ltima funcin hace que se ejecute el softirq. Cuando la funcin netif_rx( ) termina, retornando un valor que indica la congestin actual al driver. En este punto, el contexto de la interrupcin ha terminado y el paquete est listo para ser enviado a los protocolos superiores. Este proceso ha cambiado completamente en la versin del kernel 2.4 donde se basan los softirqs,
84
antes cuando los kernels eran de versin 2.2 se basaba en la mitad inferior (donde no se poda trabajar en paralelo) 5.5.4. Softirq para NET_RX Tras recibir el paquete se inserta en una cola para ser procesado posteriormente. Este proceso se hace llamando a la funcin net_rx_action( ). Esta funcin desempila el primer paquete (Sk_buff) de la cola actual de la CPU y ejectua a travs de dos listas de funciones para su proceso segn el protocolo. Estas listas se llaman ptype_all y ptype_base y contienen respectivamente, los handlers del protocolo para para paquetes genricos y para paquetes de tipo especco. Los protocol handlers se registran ellos mismos, o bien al iniciarse el kernel o bien cuando un tipo de socket es creado, declarando qu tipo de protocolo pueden tratar. Para hacer esto se llama a la funcin dev_add_pack( ) dentro del chero net/core/dev.c, el cual aade una estructura de tipo del paquete (include/linux/netdevice.h) conteniendo un puntero a la funcin ser llamada cuando un paquete de ese tipo se reciba. Tras el registro, cada estructura de un handler se pone o bien en la lista ptype_all, para el tipo ETH_P_ALL, o bien en la lista ptype_base para otros tipos ETH_P_*. As lo que hace la softirq par la NET_RX es llamar a la secuencia de funciones registradas en las dos listas para tratar al paquete que es de un tipo de protocolo especco. Si la cola contiene ms de un paquete, la funcin net_rx_action( ) hace un bucle para poder tratar el mximo nmero de paquetes que hayan sido procesados. Cuando la funcin net_rx_action( ) termina y deja una cola no vaca, la NET_RX_SOFTIRQ se activa otra vez para permitir el proceso de los paquetes para ms tarde. 5.5.5. Tratar los paquetes IP Este proyecto solo se encarga de paquetes IP versin 4, en el caso de que se hiciese para otro protocolo, como por ejemplo IPv6 se debera buscar otro tipo de handler. Para IPv4 la funcin se llama ip_rcv( ) y se encuentra en el chero net/ipv4/ip_input.c, este es apuntada a las listas antes comentadas cuando se arranca el sistema, mediante la funcin ip_init( ), dentro de net/ipv4/ip_output.c. 85
Obviamente, como era de esperar el tipo de protocolo registrado para IP es el ETH_P_IP.

tcp_input.c igmp.c udp.c tcp_output.c
sk_buff
sk_buff
ip_input.c
sk_buff
ip_output.c
sk_buff sk_buff Driver Tarjeta de red Se trata mediante netif_rx
Cable de Red
Por eso, ip_rcv( ) se llama dentro de net_rx_action( ) durante el proceso de un softirq, cuando un paquete del tipo ETH_P_IP se desempila. Esta funcin se encarga de hacer los chequeos iniciales al paquete IP, los cuales tratan de vericar la integridad del mismo: IP checksum y tamao de la cabecera. Si el paquete parece correcto, se llama a la funcin ip_rcv_nish( ). Es aqu mismo donde se introducir la funcin de cualquier rewall. Hay que asegurarse de no compilar el Netlter cuando se compile el kernel con mi programa, sino se cae en el error de tener dos ltrados de paquetes. La funcin ip_rcv_nish( ), que se encuentra dentro de ip_input.c, se encarga de hacer el rutado de IP. Se encarga de comprobar si el paquete debe ser retransmitido a otra mquina o si el destino es el host actual. Es aqu donde habra que incluir los procesos de routing. Si se enva a otra mquina se enva a la interfaz correspondiente, y si el destino nal es la propia mquina se enva a los protocolos superiores. Todo esto se hace en la funcin ip_route_input( ), llamada al principio de ip_rcv_nish( ), la cual determina cual es el siguiente paso. Si el destino es la propia mquina, entonces se llama a la funcin ip_locl_deliver( ). Esta funcin se encarga de reensamblar los diferentes paquetes IP, en el caso que el datagrama est fragmentado, y entonces llama a la funcin ip_local_deliver_nish( ). 86
Si el destino es otra mquina el proceso entonces se enva a la funcin net/ipv4/ip_output.c que ser donde se pase el chequeo de todos los paquetes que salgan del ordenador. Para diferenciar las dos llamadas a cada una de las funciones se le pasar si es de entrada o de salida. Dependiendo de donde se llame, si es desde ip_input.c se le marcar al paquete como de entrada, que se llama desde ip_output.c es de salida. Se puede profundizar ms dentro de los protocolos del siguiente nivel (TCP, UDP e ICMP) pero el proyecto no trata los paquetes a tan alto nivel. Como se explic en las secciones de teora de ltrado de paquetes.
87
6 ESTUDIO DEL DISEO ( UML)
6. Estudio del Diseo ( UML)

6.1. Introduccin al UML
6.1.1. Historia El "Unied Modelling Languaje" (UML) provee a los analistas y arquitectos de sistemas que trabajan en el diseo y anlisis de objetos de un lenguaje consistente para especicar, visualizar, construir y documentar los artefactos de un sistema de software, as tambin es til para hacer modelos de negocios. Esta especicacin es la evolucin del las tres anteriores tecnologas orientadas a objetos lideres (Booch, OMT y OOSE). El UML es la unin de estos lenguajes de modelos y an mas ya que incluye expresiones adicionales para manejar problemas de modelaje que los mtodos anteriores no cubran plenamente. El desarrollo de el UML empez en octubre de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software Corporation iniciaron su trabajo para unicar los mtodos de Booch y OMT. Debido a que los mtodos Booch y OMT ya haban madurado independientemente y eran reconocidos como mtodos lderes en el desarrollo orientado a objetos, Booch y Rumbaugh unieron fuerzas para forjar una unicacin completa de los dos mtodos. Una versin preliminar 0.8 de el "mtodo unicado" fue dad a conocer en octubre de 1995. Poco despus, Ivar Jacobson y su compaa "Objectory" se unieron a Rational y a su trabajo de unicacin, uniendo el mtodo OOSE (Object Oriented software engineering). El Nombre de Objectory es ahora dado mayormente para describir a el Proceso que acompaa al UML el "Rational unied process".
88

6.1.2. Objetivos
6.1 Introduccin al UML
Los objetivos de la unicacin fueron: el mantenerlo simple, el quitar elementos de los lenguajes de Booch, OMT y OOSE que no funcionaran en la prctica, el aadir elementos de otros mtodos que fueran ms efectivos y el inventar nuevas construcciones solamente cuando la solucin existente no estuviera disponible. UML es un lenguaje de modelado de propsito general que pueden usar todos los modeladores. No tiene propietario y est basado en el comn acuerdo de gran parte de la comunidad informtica. UML no pretende ser un mtodo de desarrollo completo. No incluye un proceso de desarrollo paso a paso. UML incluye todos los conceptos que se consideran necesarios para utilizar un proceso moderno iterativo, basado en construir una slida arquitectura para resolver requisitos dirigidos por casos de uso. Ser tan simple como sea posible pero manteniendo la capacidad de modelar toda la gama de sistemas que se necesita construir. UML necesita ser lo sucientemente expresivo para manejar todos los conceptos que se originan en un sistema moderno, tales como la concurrencia y distribucin, as como tambin los mecanismos de la ingeniera de software, como son la encapsulacin y componentes. Debe ser un lenguaje universal, como cualquier lenguaje de propsito general, pretende ser un estndar mundial. Varios nuevos conceptos existen en UML, incluyendo: 1. Mecanismos de extensin (estereotipos, valores marcados y restricciones), 2. Procesos y ramas de procesamiento 3. Distribucin y concurrencia 4. Patrones y colaboracin 5. Diagramas de actividad 6. Renamiento (para manejar las relaciones entre los niveles de abstraccin) 7. Interfaces y componentes 8. Un lenguaje para restricciones
89
Aunque el UML dene un leguaje preciso, no es una barrera para el desarrollo futuro en los conceptos de modelaje. Se han incorporado muchas tcnicas lderes, pero se espera que tcnicas adicionales inuyan las versiones futuras del UML. Muchas tcnicas avanzadas pueden ser denidas usando el UML como base. El UML puede ser extendido sin redenir su ncleo. 6.1.3. Participantes en UML 1.0 La lista de participantes incluye grandes empresas de informtica, con lo que se consigue no slo que haya ms intercambio de ideas sino que se cumpla en un defacto para todo el mundo. Lstima que no est incluida ninguna empresa de Linux. 1. Rational Software (Grady Booch, Jim Rumbaugh y Ivar Jacobson) 2. Digital Equipment 3. Hewlett-Packard 4. i-Logix (David Harel) 5. IBM 6. ICON Computing (Desmond DSouza) 7. Intellicorp and James Martin & co. (James Odell) 8. MCI Systemhouse 9. Microsoft 10. ObjecTime 11. Oracle Corporation. 12. Platinium Technology 13. Sterling Software 14. Taskon 90

15. Texas Instruments 16. Unisys 6.1.4. reas conceptuales
Los conceptos y modelos de UML pueden agruparse en las siguientes reas conceptuales: Estructura esttica: Cualquier modelo preciso debe primero denir su universo, esto es, los conceptos clave de la aplicacin, sus propiedades internas, y las relaciones entre cada una de ellas. Este conjunto de construcciones es la estructura esttica. Los conceptos de la aplicacin son modelados como clases, cada una de las cuales describe un conjunto de objetos que almacenan informacin y se comunican para implementar un comportamiento. La informacin que almacena es modelada como atributos; La estructura esttica se expresa con diagramas de clases y puede usarse para generar la mayora de las declaraciones de estructuras de datos en un programa. Comportamiento dinmico: Hay dos formas de modelar el comportamiento, una es la historia de la vida de un objeto y la forma como interacta con el resto del mundo y la otra es por los patrones de comunicacin de un conjunto de objetos conectados, es decir la forma en que interactan entre s. La visin de un objeto aislado es una maquina de estados, muestra la forma en que el objeto responde a los eventos en funcin de su estado actual. La visin de la interaccin de los objetos se representa con los enlaces entre objetos junto con el ujo de mensajes y los enlaces entre ellos. Este punto de vista unica la estructura de los datos, el control de ujo y el ujo de datos. Construcciones de implementacin: Los modelos UML tienen signicado para el anlisis lgico y para la implementacin fsica. Un componente es una parte fsica reemplazable de un sistema y es capaz de responder a las peticiones descritas por un conjunto de interfaces. Un nodo es un recurso computacional que dene una localizacin durante la ejecucin de un sistema. Puede contener componentes y objetos. 91
6.2 Diagramas
Organizacin del modelo: La informacin del modelo debe ser dividida en piezas coherentes, para que los equipos puedan trabajar en las diferentes partes de forma concurrente. El conocimiento humano requiere que se organice el contenido del modelo en paquetes de tamao modesto. Los paquetes son unidades organizativas, jerrquicas y de propsito general de los modelos de UML. Pueden usarse para almacenamiento, control de acceso, gestin de la conguracin y construccin de bibliotecas que contengan fragmentos de cdigo reutilizable. Mecanismos de extensin: UML tiene una limitada capacidad de extensin pero que es suciente para la mayora de las extensiones que requiere el dia a dia sin la necesidad de un cambio en el lenguaje bsico. Un estereotipo es una nueva clase de elemento de modelado con la misma estructura que un elemento existente pero con restricciones adicionales.
6.2. Diagramas
Un Modelo captura una vista de un sistema del mundo real. Es una abstraccin de dicho sistema, considerando un cierto propsito. As, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propsito del modelo, y a un apropiado nivel de detalle. Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de inters. El cdigo fuente del sistema es el modelo ms detallado del sistema (y adems es ejecutable). Sin embargo, se requieren otros modelos. Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de trazabilidad entre los diferentes modelos. Un Diagrama es una representacin grca de una coleccin de elementos de modelado, a menudo dibujada como un grafo conexo de arcos (relaciones) y vrtices (otros elementos del modelo). Un diagrama no es un elemento semntico, un diagrama muestra representaciones de elementos semnticos del modelo, pero su signicado no se ve afectado por la forma en que son representados. Un diagrama est contenido dentro de un paquete.
92
6.2 Diagramas
La mayora de los diagramas de UML y algunos smbolos complejos son grafos que contienen formas conectadas por rutas. La infomacin est sobre todo en la topologa, no en el tamao o la colocacin de los smbolos (hay algunas excepciones como el diagrma de secuencia con un eje mtrico de tiempo). Hay tres clases importantes de relaciones visuales: conexin (generalmente de lneas a formas de dos dimensiones), contencin (de smbolos por formas cerradas de dos dimensiones), y adhesin visual (un smbolo que est "cerca" de otro en un diagrama). Estas relaciones geomtricas se reasignan a conexiones entre nodos en un grco en la forma analizada de la notacin. La notacin de UML est pensada para ser dibujada en supercies bidimensionales. Algunas formas bidimensionales son proyecciones de formas tridimensionales tales como cubos, pero todava se representan como conos en una supercie bidimensional. Hay cuatro clases de construcciones grcas que se usan en la notacin de UML: conos, smbolos bidimensionales, rutas y cadenas. Un cono es una gura grca con un tamao y forma jos. No se ampla para contener a su contenido. Los iconos pueden aparecer dentro de smbolos de rea, como terminadores en las rutas o como smbolos independientes que puedan o no conectar con las rutas. Los smbolos de dos dimensiones tienen altura y anchura variables, y pueden ampliarse para permitir otras cosas tales como listas de cadenas o de otros smbolos. Muchos de ellos estn divididos en compartimientos similares o de tipos diferentes. Las rutas se conectan con los smbolos, el arrastrar o suprimir uno de ellos afecta a su contenido y las rutas conectadas. Una ruta es una secuencia de segmentos de recta o de curva que se unen en sus puntos nales. Conceptualmente una ruta es una sola entidad topolgica, aunque sus segmentos se pueden manipular grcamente. un segemento no debera existir separado de su ruta. Las rutas siempre van conectdas en ambos extremos. Las cadenas presentan varias clases de informacin en una forma "no analizada", UML asume que cada uso de una cadena en la notacin tiene una sintaxis por la cual pueda ser analizada la informacin del modelo subyancente. Las cadenas pueden existir como el contenido de un compartimiento, como elementos en las listas, como etiquetas unidas a los smbolos o a las rutas, o como elementos 93

independientes en un diagrama. 6.2.1. Diagramas estructurales
6.2 Diagramas
Se usan para visualizar, especicar, construir y documentar aspectos estticos de un sistema. Que son el esqueleto e incluyen la existencia y ubicacin de clases, interfaces, colaboraciones, componentes y nodos. Diagrama de clases: Representa las clases, interfaces y colaboraciones y relaciones entre ellas. Diagramas de objetos: Representa objetos y sus relaciones. SE usa para describir estructuras de datos. Diagramas de componentes: Muestra el conjunto de componentes y sus relaciones. Los diagramas de componentes se relacionan con los diagramas de clases dado que los componentes son grupo de clases, interfaces y colaboraciones. Diagramas de despliegue: Muestra conjunto de nodos y sus relaciones. Se usan para describir la vista de despliegue esttica de una arquitectura. Se relacionan con los diagramas de componentes porque un nodo incluye normalmente uno o ms componentes. 6.2.2. Diagramas de comportamiento Se usa para los aspectos dinmicos de un sistema. Que son las partes mutables como el ujo de mensajes a lo largo del tiempo el movimiento fsico de componentes en una red. Diagramas de casos de uso: representas casos de uso, actores y sus relaciones. Diagramas de secuencia: Junto con los diagramas de colaboracin representan a los diagramas de interaccin, que resalta la ordenacin temporal de los mensajes. Representa el conjunto de objetos y los mensajes enviados y recibidos entre ellos.
94
6.3 Diagramas de Objetos
Diagramas de colaboracin: Son diagramas de interaccin que resalta la organizacin estructural de los objetos que envan y reciben sus mensajes. Representan los objetos enlazados unos con otros con sus mensajes enviados y recibidos. Diagramas de estado: Son mquinas de estados, con sus transiciones, eventos y actividades. Ayudan a modelar el comportamiento. Diagramas de actividades: Muestra el ujo de actividades. Muestran el ujo secuencial de actividades y los objetos que actan y sobre los que acta.
6.3. Diagramas de Objetos

Objeto es una entidad discreta con lmites bien denidos y con identidad, es una unidad atmica que encapsula estado y comportamiento. La encapsulacin en un objeto permite una alta cohesin y un bajo acoplamiento. el Objeto es reconocido tambin como una instancia de la clase a la cual pertenece. La encapsulacin presenta tres ventajas bsicas: 1. Se protegen los datos de accesos indebidos 2. El acoplamiento entre las clases se disminuye 3. Favorece la modularidad y el mantenimiento Un objeto se puede ver desde dos perspectivas relacionadas: como una entidad de un determinado instante de tiempo que posee un valor especco (Un objeto puede caracterizar una entidad fsica -coche-) y como un poseedor de identidad que tiene distintos valores a lo largo del tiempo (abstracta -ecuacin matemtica-). Cada objeto posee su propia identidad exclusiva y se puede hacer referencia a l mediante una denominacin exclusiva que permite accederle. El Modelado de Objetos permite representar el ciclo de vida de los objetos a travs de sus interacciones. En UML, un objeto se representa por un rectngulo con un nombre subrayado. 1. Objeto = Identidad + Estado + Comportamiento 95
2. El estado est representado por los valores de los atributos. 3. Un atributo toma un valor en un dominio concreto. La regla general para la notacin de instancias consiste en utilizar el mismo smbolo geomtrico que el descriptor. En la instancia se muestran los posibles valores pero las propiedades compartidas slo se pone de maniesto en el descriptor. La notacin cannica es un rectngulo con tres compartimientos. En el primero va el nombre del objeto, en el segundo sus atributos y en el tercero sus operaciones. Este ltimo puede ser omitido si as se preere.
6.3.1. Oid (Object Identier) Cada objeto posee un oid. El oid establece la identidad del objeto y tiene las siguientes caractersticas: 1. Constituye un identicador nico y global para cada objeto dentro del sistema. 2. Es determinado en el momento de la creacin del objeto. 3. Es independiente de la localizacin fsica del objeto, es decir, provee completa independencia de localizacin. 96
4. Es independiente de las propiedades del objeto, lo cual implica independencia de valor y de estructura. 5. No cambia durante toda la vida del objeto. Adems, un oid no se reutiliza aunque el objeto deje de existir. No se tiene ningn control sobre los oids y su manipulacin resulta transparente. Sin embargo, es preciso contar con algn medio para hacer referencia a un objeto utilizando referencias del dominio (valores de atributos). 6.3.2. Caractersticas alrededor de un objeto Estado: El estado evoluciona con el tiempo. Algunos atributos pueden ser constantes, el comportamiento agrupa las competencias de un objeto y describe las acciones y reacciones de ese objeto. Las operaciones de un objeto son consecuencia de un estmulo externo representado como mensaje enviado desde otro objeto. Persistencia: La persistencia de los objetos designa la capacidad de un objeto trascender en el espacio/tiempo, podremos despus reconstruirlo, es decir, cogerlo de memoria secundaria para utilizarlo en la ejecucin (materializacin del objeto). Los lenguajes OO no proponen soporte adecuado para la persistencia, la cual debera ser transparente, un objeto existe desde su creacin hasta que se destruya. Comunicacin: Un sistema informtico puede verse como un conjunto de objetos autnomos y concurrentes que trabajan de manera coordinada en la consecucin de un n especco. El comportamiento global se basa pues en la comunicacin entre los objetos que la componen. Categoras de objetos: Pueden ser clasicado como Activos o Pasivos, como Cliente o Servidores, o bien como Agentes. 1. Objeto Activo: Posee un hilo de ejecucin (thread) propio y puede iniciar una actividad.
97
6.4 Diagramas de Clases
2. Objeto Pasivo: No puede iniciar una actividad pero puede enviar estmulos una vez que se le solicita un servicio. 3. Cliente es el objeto que solicita un servicio. 4. Servidor es el objeto que provee el servicio solicitado. 5. Los agentes renen las caractersticas de clientes y servidores. Son la base del mecanismo de delegacin. Introducen indireccin: un cliente puede comunicarse con un servidor que no conoce directamente. Mensajes: La unidad de comunicacin entre objetos se llama mensaje. El mensaje es el soporte de una comunicacin que vincula dinmicamente los objetos que fueron separados previamente en el proceso de descomposicin. Adquiere toda su fuerza cuando se asocia al polimorsmo y al enlace dinmico. Un estmulo causar la invocacin de una operacin, la creacin o destruccin de un objeto o la aparicin de una seal. Un mensaje es la especicacin de un estmulo.
6.4. Diagramas de Clases

El Diagrama de Clases es el diagrama principal para el anlisis y diseo. Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia. La denicin de clase incluye deniciones para atributos y operaciones. El modelo de casos de uso aporta informacin para establecer las clases, objetos, atributos y operaciones. El mundo real puede ser visto desde abstracciones diferentes (subjetividad). Mecanismos de abstraccin: 1. Clasicacin / Instanciacin 2. Composicin / Descomposicin 3. Agrupacin / Individualizacin 4. Especializacin / Generalizacin
98
La clasicacin es uno de los mecanismos de abstraccin ms utilizados. La clase dene el mbito de denicin de un conjunto de objetos, y cada objeto pertenece a una clase, Los objetos se crean por instanciacin de las clases. Cada clase se representa en un rectngulo con tres compartimientos: nombre de la clase atributos de la clase operaciones de la clase Los atributos de una clase no deberan ser manipulables directamente por el resto de objetos. Por esta razn se crearon niveles de visibilidad para los elementos que son: 1. (-) Privado : Es el ms fuerte. Esta parte es totalmente invisible (excepto para clases friends en terminologa C++). 2. (#) Los atributos/operaciones protegidos estn visibles para las clases friends y para las clases derivadas de la original. 3. (+) Los atributos/operaciones pblicos son visibles a otras clases (cuando se trata de atributos se est transgrediendo el principio de encapsulacin). 6.4.1. Relaciones entre clases Semnticamente todas las relaciones, incluidas la generalizacin, la asociacin y la realizacin son tipos de dependecias. Pero tienen una semntica lo bastante importante como para justicar que se traten como distintos tipos de relaciones en UML. Es una decisin de diseo. La expericencia muestra que este enfoque mantiene un equilibrio entre dar importancia a los tipos importantes de relaciones y no sobrecargar al modelador con demasiadas opciones. Uno no se equivocar si modela la generalizacin, la asociacin y la realizacin en primer lugar y luego ve las dems relaciones como tipos de dependencias. Relacin de Dependencias: Relacin de uso. Declara que un cambio en la especicacin del elemento usado puede afectar al elemento que lo usa. Como puede verse en la imagen, la gura usa posicion 99
Relacin de Generalizacin: Relacin "hereda_de" o bien "es_un_tipo_de". Entre una superclase o padre y una subclase o hijo. En la imagen tenemos que Rectngulo y Crculo heredan de Figura.
Relacin de Asociacin: Relacin estructural que especica conexin entre dos objetos. Conexin entre dos objetos es una asociacin binaria y entre n clases es una n-aria. Dentro de este grupo de relaciones tenemos relacin de asociacin por nombre, por rol, por multiplicidad y por agragacin. Nombre: Describe la naturaleza de la asociacin. En la gura un empleado trabaja para otra clase.
Rol: Rol que se juega en una asosciacin. Tenemos que una persona vista desde la fbrica es un empleado.
100
6.5 Diagramas de Caso de Uso
Multiplicidad: Indica "cuantos" objetos en un extremo de la asociacin pertenecen. En el ejemplo tenemos que una fbrica tiene un nmero indenido de personas trabajando en ella.
Agregacin: Relacin "tiene_un". Relacion entre objetos del mismo nivel pero con una relacin todo/parte, uno es "parte" del "todo".
6.5. Diagramas de Caso de Uso

Casos de Uso es una tcnica para capturar informacin de cmo un sistema o negocio trabaja, o de cmo se desea que trabaje. No pertenece estrictamente al enfoque orientado a objeto, es una tcnica para captura de requisitos. Los Casos de Uso (Ivar Jacobson) describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el p.d.v. del usuario. Permiten denir los lmites del sistema y las relaciones entre el sistema y el entorno.
101
6.5 Diagramas de Caso de Uso
Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la implementacin. Comparacin con respecto a los Diagramas de Flujo de Datos del Enfoque Estructurado. Los Casos de Uso cubren la carencia existente en mtodos previos (OMT, Booch) en cuanto a la determinacin de requisitos. Los Casos de Uso particionan el conjunto de necesidades atendiendo a la categora de usuarios que participan en el mismo. Estn basados en el lenguaje natural, es decir, es accesible por los usuarios. 6.5.1. Actores La misma persona fsica puede interpretar varios papeles como actores distintos, el nombre del actor describe el papel desempeado. 1. Principales: personas que usan el sistema. 2. Secundarios: personas que mantienen o administran el sistema. 3. Material externo: dispositivos materiales imprescindibles que forman parte del mbito de la aplicacin y deben ser utilizados. 4. Otros sistemas: sistemas con los que el sistema interacta. Los Casos de Uso se determinan observando y precisando, actor por actor, las secuencias de interaccin, los escenarios, desde el punto de vista del usuario. Los casos de uso intervienen durante todo el ciclo de vida. El proceso de desarrollo estar dirigido por los casos de uso. Un escenario es una instancia de un caso de uso. UML dene cuatro tipos de relacin en los Diagramas de Casos de Uso. La Comunicacin, la Inclusin, que es una instancia del Caso de Uso origen incluye tambin el comportamiento descrito por el Caso de Uso destino. include reemplaz al denominado uses. La Extensin : el Caso de Uso origen extiende el 102
6.6 Diagramas de Estado
comportamiento del Caso de Uso destino. extend y la Herencia : el Caso de Uso origen hereda la especicacin del Caso de Uso destino y posiblemente la modica y/o ampla.
6.6. Diagramas de Estado

Muestra el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicacin, junto con los cambios que permiten pasar de un estado a otro. Los Diagramas de Estado representan autmatas de estados nitos, desde el p.d.v. de los estados y las transiciones. Son tiles slo para los objetos con un comportamiento signicativo. Cada objeto est en un estado en cierto instante. El estado est caracterizado parcialmente por los valores algunos de los atributos del objeto. El estado en el que se encuentra un objeto determina su comportamiento. Cada objeto sigue el comportamiento descrito en el Diagrama de Estados asociado a su clase. Los Diagramas de Estados y escenarios son complementarios, los Diagramas de Estados son autmatas jerrquicos que permiten expresar concurrencia, sincronizacin y jerarquas de objetos, son grafos dirigidos y deterministas. La transicin entre estados es instantnea y se debe a la ocurrencia de un evento. 6.6.1. Estado Identica un periodo de tiempo del objeto (no instantneo) en el cual el objeto est esperando alguna operacin, tiene cierto estado caracterstico o puede recibir cierto tipo de estmulos. Se representa mediante un rectngulo con los bordes redondeados, que puede tener tres compartimientos: uno para el nombre, otro para el valor caracterstico de los atributos del objeto en ese estado y otro para las acciones que se realizan al entrar, salir o estar en un estado (entry, exit o do, respectivamente). Eventos Es una ocurrencia que puede causar la transicin de un estado a otro de un objeto. Esta ocurrencia puede ser una de varias cosas:
103
Condicin que toma el valor de verdadero o falso Recepcin de una seal de otro objeto en el modelo Recepcin de un mensaje Paso de cierto perodo de tiempo, despus de entrar al estado o de cierta hora y fecha particular El nombre de un evento tiene alcance dentro del paquete en el cual est denido, no es local a la clase que lo nombre. 6.6.2. Envo de mensajes Adems de mostrar y transicin de estados por medio de eventos, puede representarse el momento en el cual se envan mensajes a otros objetos. Esto se realiza mediante una lnea punteada dirigida al diagrama de estados del objeto receptor del mensaje. Transicin simple Una transicin simple es una relacin entre dos estados que indica que un objeto en el primer estado puede entrar al segundo estado y ejecutar ciertas operaciones, cuando un evento ocurre y si ciertas condiciones son satisfechas. Se representa como una lnea slida entre dos estados, que puede venir acompaada de un texto con el siguiente formato: event-signature "[" guard-condition] "/" action-expression "^"send-clause event-signature es la descripcin del evento que da lugar la transicin, guardcondition son las condiciones adicionales al evento necesarias para que la transicin ocurra, action-expression es un mensaje al objeto o a otro objeto que se ejecuta como resultado de la transicin y el cambio de estado y send-clause son acciones adicionales que se ejecutan con el cambio de estado, por ejemplo, el envo de eventos a otros paquetes o clases.
104

Transicin interna
Es una transicin que permanece en el mismo estado, en vez de involucrar dos estados distintos. Representa un evento que no causa cambio de estado. Se denota como una cadena adicional en el compartimiento de acciones del estado. 6.6.3. Acciones Podemos especicar la solicitud de un servicio a otro objeto como consecuencia de la transicin. Se puede especicar el ejecutar una accin como consecuencia de entrar, salir, estar en un estado, o por la ocurrencia de un evento. Generalizacin de Estados: Podemos reducir la complejidad de estos diagramas usando la generalizacin de estados. Distinguimos as entre superestado y subestados. Un estado puede contener varios subestados disjuntos. Los subestados heredan las variables de estado y las transiciones externas. La agregacin de estados es la composicin de un estado a partir de varios estados independientes. La composicin es concurrente por lo que el objeto estar en alguno de los estados de cada uno de los subestados concurrentes. La destruccin de un objeto es efectiva cuando el ujo de control del autmata alcanza un estado nal no anidado. La llegada a un estado nal anidado implica la subida al superestado asociado, no el n 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 n, los cuales se suponen conectados a las entradas y salidas del nivel inmediatamente superior. 105

Transaccin Compleja
6.7 Diagramas de actividades
Una transicin compleja relaciona tres o ms estados en una transicin de mltiples fuentes y/o mltiples destinos. Representa la subdivisin en threads del control del objeto o una sincronizacin. Se representa como una lnea vertical de la cual salen o entran varias lneas de transicin de estado. Transicin a estados anidados Una transicin hacia un estado complejo (descrito mediante estados anidados) signica la entrada al estado inicial del subdiagrama. Las transiciones que salen del estado complejo se entienden como transiciones desde cada uno de los subestados hacia afuera (a cualquier nivel de profundidad). Transiciones temporizadas Las esperas son actividades que tienen asociada cierta duracin. La actividad de espera se interrumpe cuando el evento esperado tiene lugar. Este evento desencadena una transicin que permite salir del estado que alberga la actividad de espera. El ujo de control se transmite entonces a otro estado.
6.7. Diagramas de actividades

Un estado de actividad representa una actividad: un paso en el ujo de trabajo o la ejecucin de una operacin. Un grafo de actividades describe grupos secuenciales y concurrentes de actividades. Los grafos de actividades se muestran en diagramas de actividades. Las actividades se enlazan por transiciones automticas. Cuando una actividad termina se desencadena el paso a la siguiente actividad. Un diagrama de actividades es provechoso para entender el comportamiento de alto nivel de la ejecucin de un sistema, sin profundizar en los detalles internos de los mensajes. Los parmetros de entrada y salida de una accin se pueden mostrar usando las relaciones de ujo que conectan la accin y un estado de ujo de objeto. 106
6.7 Diagramas de actividades
Un grafo de actividades contiene estados de actividad que representa la ejecucin de una secuencia en un procedimiento, o el funcionamiento de una actividad en un ujo de trabajo. En vez de esperar un evento, como en un estado de espera normal, un estado de actividad espera la terminacin de su cmputo. Cuando la actividad termina, entonces la ejecucin procede al siguiente estado de actividad dentro del diagrama. una transicin de terminacin es activada en un diagrama de actividades cuando se completa la actividad precedente. Los estados de actividad no tienen transiciones con eventos explcitos, peor pueden ser abortados por transiciones en estados que los incluyen. Un grafo de actividades puede contener tambin estados de accin, que son similares a los de actividad pero son atmicos y no permiten transiciones mientras estn activos. Los estados de accin se deben utilizar para las operaciones cortas de mantenimiento. Un diagrama de actividades puede contener bifurcaciones, as como divisiones de control en hilos concurrentes. los hilos concurrentes representan actividades que se pueden realizar concurrentemente por los diversos objetos o personas. La concurrencia se representa a partir de la agregacin, en la cual cada objeto tiene su propio hilo. Las actividades concurrentes se pueden realizar simultneamente o en cualquier orden. Un diagrama de actividades es como un organigrama tradicional, excepto que permite el control de concurrencia adems del control secuencial. 6.7.1. Notacin Un estado de actividad se representa como una caja con los extremos redondeados que contiene una descripcin de actividad. Las transacciones simples de terminacin se muestran como echas. Las ramas se muestran como condiciones de guarda en transiciones o como diamantes con mltiples echas de salida etiquetadas. Una divisin o una unin de control se representa con mltiples echas que entran o salen de la barra gruesa de sincronizacin. Cuando es necesario incluir eventos externos, la recepcin de un evento se puede mostrar como un disparador en una transicin, o como un smbolo especial que denota la espera de una seal. A menudo es til organizar las actividades en un modelo segn su responsa-
107
6.8 Diagramas de Interaccin
bilidad. Esta clase de asignacin puede mostrarse organizando las actividades en regiones distintas separads por lneas en el diagrama. Debido a su aspecto, esto es conocido como Calles. Un diagrama de actividades puede mostrar el ujo de objetos como valores. Para un valor de salida, se dibuja una echa con lnea discontinua desde la actividad al objeto. Para un valor de entrada, se dibuja una echa con lnea discontinua desde el objeto a una actividad.
6.8. Diagramas de Interaccin

La vista de interaccin describe secuencias de intercambios de mensajes entre los roles que implementan el comportamiento de un sistema. Un rol clasicador, o simplemente "un rol", es la descripcin de un objeto, que desempea un determinado papel dentro de una interaccin, distinto de los otros objetos de la misma clase. Esta visin proporciona una vista integral del comportamiento del sistema, es decir, muestra el ujo de control a travs de muchos objetos. La vista de interaccin se exhibe en dos diagramas centrados en distintos aspectos pero complementarios: centrados en los objetos individuales y centrados en objetos cooperantes. Los objetos interactan para realizar colectivamente los servicios ofrecidos por las aplicaciones. Los diagramas de interaccin muestran cmo se comunican los objetos en una interaccin. Existen dos tipos de diagramas de interaccin: el Diagrama de Colaboracin y el Diagrama de Secuencia. El Diagrama de Secuencia es ms adecuado para observar la perspectiva cronolgica de las interacciones, muestra la secuencia explcita de mensajes y son mejores para especicaciones de tiempo real y para escenarios complejos. El Diagrama de Colaboracin ofrece una mejor visin espacial mostrando los enlaces de comunicacin entre objetos, muestra las relaciones entre objetos y son mejores para comprender todos los efectos que tiene un objeto y para el diseo de procedimientos. El diagrama de Colaboracin puede obtenerse automticamente a partir del correspondiente diagrama de Secuencia (o viceversa).
108

Diagramas de Secuencia
6.8 Diagramas de Interaccin
1. Muestra la secuencia de mensajes entre objetos durante un escenario concreto 2. Cada objeto viene dado por una barra vertical 3. El tiempo transcurre de arriba abajo 4. Cuando existe demora entre el envo y la atencin se puede indicar usando una lnea oblicua Diagramas de Colaboracin 1. Son tiles en la fase exploratoria para identicar objetos. 2. La distribucin de los objetos en el diagrama permite observar adecuadamente la interaccin de un objeto con respecto de los dems 3. La estructura esttica viene dada por los enlaces; la dinmica por el envo de mensajes por los enlaces 6.8.1. Colaboracin Es una descripcin de una coleccin de objetos que interactan para implementar un cierto comportamiento dentro de un contexto. Describe una sociedad de objetos cooperantes unidos para realizar un cierto propsito. Una colaboracin contiene ranuras que son rellenadas por los objetos y enlaces en tiempo de ejecucin. Una ranura de colaboracin se llama Rol porque describe el propsito de un objeto o un enlace dentro de la colaboracin. Un rol clasicador representa una descripcin de los objetos que pueden participar en una ejecucin de la colaboracin, un rol de asociacin representa una descripcin de los enlaces que pueden participar en una ejecucin de colaboracin. Un rol de clasicador es una asociacin que est limitada por tomar parte en la colaboracin. Las relaciones entre roles de clasicador y asociacin dentro de una colaboracin slo tienen sentido en ese contexto. En general fuera de ese contexto no se aplican las mismas relaciones. 109
6.9 Diagramas de Componentes
Una Colaboracin tiene un aspecto estructural y un aspecto de comportamiento. El aspecto estrucutral es similar a una vista esttica: contiene un conjunto de roles y relaciones que denen el contexto para su comprtamiento. El comportamiento es el conjunto de mensajes intercambiados por los objetos ligados a los roles. Tal conjunto de mensajes en una colaboracin se llama Interaccin. Una colaboracin puede incluir una o ms interacciones. 6.8.2. Interaccin Es el conjunto de mensajes intercambiados por los roles de clasicador a travs de los roles de asociacin. Un mensaje es una comunicain unidireccional entre dos objetos, un ujo de objeto con la informacin de un remitente a un receptor. Un mensaje puede tener parmetros que transporten valores entre objetos. Un mensaje puede ser una seal (comunicacin explcita entre objetos, con nombre y asncrona) o una llamada (la invocacin sncrona de una operacin con un mecanismo para el control, que retorna posteriormente al remitente). Un patrn de intercambios de mensajes que se realizan para lograr un propsito especco es lo que se denomina una interaccin. 6.8.3. Patrn Un patrn es una colaboracin parametrizada, junto con las pautas sobre cundo utilizarlo. Un parmetro se puede sustituir por diversos valores, para producir distintas colaboraciones. Los parmetros sealan generalmente las ranuras para las clases. El uso de un patrn se representa como una elipse de lnea discontinua conectada con cada una de las clases por una lnea discontinua, que se etiqueta con el nombre del rol.
6.9. Diagramas de Componentes

Los diagramas de componentes describen los elementos fsicos del sistema y sus relaciones. Muestran las opciones de realizacin incluyendo cdigo fuente, binario y ejecutable. Los componentes representan todos los tipos de elementos software que entran en la fabricacin de aplicaciones informticas. Pueden ser
110
simples archivos, paquetes de Ada, bibliotecas cargadas dinmicamente, etc. Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente utiliza los servicios ofrecidos por otro componente. Un diagrama de componentes representa las dependencias entre componentes software, incluyendo componentes de cdigo fuente, componentes del cdigo binario, y componentes ejecutables. Un mdulo de software se puede representar como componente. Algunos componentes existen en tiempo de compilacin, algunos en tiempo de enlace y algunos en tiempo de ejecucin, otros en varias de stas. Un componente de slo compilacin es aquel que es signicativo nicamente en tiempo de compilacin. Un componente ejecutable es un programa ejecutable. Un diagrama de componentes tiene slo una versin con descriptores, no tiene versin con instancias. Para mostrar las instancias de los componentes se debe usar un diagrama de despliegue. Un diagrama de componentes muestra clasicadores de componentes, las clases denidas en ellos, y las relaciones entre ellas. Los clasicadores de componentes tambin se pueden anidar dentro de otros clasicadores de componentes para mostrar relaciones de denicin. Un diagrama que contiene clasicadores de componentes y de nodo se puede utilizar para mostrar las dependencias del compilador, que se representa como echas con lneas discontinuas (dependencias) de un componente cliente a un componente proveedor del que depende. Los tipos de dependencias son especcos del lenguaje y se pueden representar como estereotipos de las dependencias. El diagrama tambin puede usarse para mostrar interfaces y las dependencias de llamada entre componentes, usando echas con lneas discontinuas desde los componentes a las interfaces de otros componentes. El diagrama de componente hace parte de la vista fsica de un sistema, la cual modela la estructura de implementacin de la aplicacin por s misma, su organizacin en componentes y su despliegue en nodos de ejecucin. Esta vista proporciona la oportunidad de establecer correspondecias entre las clases y los componentes de implementacin y nodos. La vista de implementacin se representa con los diagramas de componentes.
111

6.9.1. Componentes
Es una parte fsica reemplazable de un sistema que empaqueta su implementacin y es conforme a un conjunto de interfaces a las que proporciona su realizacin. Algunos componentes tienen identidad y pueden poseer entidades fsicas, que incluyen objetos en tiempo de ejecucin, documentos, bases de datos, etc. Los componentes existentes en el dominio de la implementacin son unidades fsicas en los computadores que se pueden conectar con otros componentes, sustituir, trasladar, archivar, etc. Los componentes tienen dos caractersticas: Empaquetan el cdigo que implementa la funcionalidad de un sistema, y algunas de sus propias instancias de objetos que contituyen el estado del sistema. Los llamados ltimos componentes de la identidad, porque sus instancias poseen identidad y estado. Cdigo: Un componente contiene el cdigo para las clases de implementacin y otros elementos. Un componente de cdigo fuente es un paquete para el cdigo fuente de las clases de implementacin. Al gunos lenguajes de programacin distinguen archivos de declaracin de los archivos de mtodo, pero todos son componentes. Un componente de cdigo binario es un paquete para el cdigo compliado. Una biblioteca del cdigo binario es un componente. Cada tipo de componente contiene el cdigo para las clases de implementacin que realizan algunas clases e interfaces lgicas. La relacin de realizacin asocia un componente con las clases y las interfaces lgicas que implementan sus clases de implementacin. Las interfaces de un componente describen la funcionalidad que aporta. Cada operacin de la interfaz debe hacer referencia eventualmente a un elemento de la implementacin disponible en el componente. La estrucutra esttica, ejecutable de una implementacin de un sistema se puede representar como un conjunto interconectado de componentes. Las dependencias entre componentes signican que los elementos de la implementacin en un componente requieren los serivios de los elementos de implemntacin en otros componentes. Tal uso requiere que dichos elementos sean de visibilidad pblica. 112

Identidad:
6.10 Diagramas de Despliegue
Un componente de identidad tiene identidad y estado. Posee los objetos fsicos que estn situados en l. Puede tener atributos, relaciones de composicin con los objetos posedos, y asociaciones con otros componentes. Desde este punto de vista es una clase. Sin embargo la totalidad de su estado debe hacer referencia a las instancias que contiene. Estructura: Un componente ofrece un conjunto de elementos de implementacin, esto signica que el componente proporciona el cdigo para los elementos. Un componente puede tener operaciones e interfaces. Un componente de identidad es un contenedor fsico para las entidades fsicas como bases de datos. Para proporcionar manejadores para sus elementos contenidos, puede tener atributos y asociaciones salientes, que deben ser implementadas por sus elementos de implementacin. Este componente se representa con un rectngulo con dos rectngulos ms pequeos que sobresalen en su lado izquierdo. Las operaciones e interfaces disponibles para los objetos exteriores se pueden representar directamente en el smbolo de clase. Estos son su comportamiento como clase. Los contenidos del subsistema se representan en un diagrama separado. Las dependencias de un componente con otros componentes o elementos del modelo se representan usando lneas discontinuas con la punta de echa hacia los elementos del proveedor. S un componente es la realizacin de una interfaz, se representa con un crculo unido al smbolo del componente por un segmento de lnea.
6.10. Diagramas de Despliegue

Los Diagramas de Despliegue muestran la disposicin fsica de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos. La vista de despliegue representa la disposicin de las instancias de componentes de ejecucin en instacias de nodos conectados por enlaces de comunicacin. Un nodo es un recurso de ejecucin tal como un computador, un dispositivo
113
6.11 Los paquetes
o memoria. Los estereotipos permiten precisar la naturaleza del equipo: Dispositivos Procesadores Memoria Los nodos se interconectan mediante soportes bidireccionales que pueden a su vez estereotiparse. Esta vista permite determinar las consecuencias de la distribucin y la asignacin de recursos. Las instancias de los nodos pueden contener instancias de ejecucin, como instancias de componentes y objetos. El modelo puede mostrar dependencias entre las instancias y sus interfaces, y tambin modelar la migracin de entidades entre nodos u otros contenedores. Esta vista tiene una forma de descriptor y otra de instancia. La forma de instancia muestra la localizacin de las instancias de los componentes especcos en instancias especcas del nodo como parte de una conguracin del sistema. La forma de descriptor muestra qu tipo de componentes pueden subsistir en qu tipos de nodos y qu tipo de nodos se pueden conectar, de forma similar a una diagrama de clases, esta forma es menos comn que la primera.
6.11. Los paquetes

Los paquetes son elementos para organizar elementos en grupos. Imaginemos una aplicacin con cientos de clases que se ven entre todas ellas, no hay forma de comprender una red de relaciones tan grande y desorganizado. Es un problema real para grandes sistemas (el acceso simple y no restringido no permite el crecimiento). Para estas situaciones se necesita algn tipo de empaquetamiento controlado para organizar las abstracciones.
114

Anidamiento
6.11 Los paquetes
Las abstracciones que organizan un modelo se llaman paquetes. Y los paquetes agrupan a otros paquetes organizndolos en forma de directorios. Se recomienda tener como lmite dos o tres niveles de anidamiento. Al anidar un paquete (Men) dentro de otro paquete (Ventana) se indica con el nombre del paquete anidado precedido por el nombre que lo contiene (Ventana::Men). Por ejemplo el nombre de camino para el paquete Men puede ser API::Ventana::Men Importacin La importacin de un paquete hace que se pueda acceder a los elementos de ese paquete, pero el paquete importado no puede acceder a los elementos del otro. En UML una relacin de importacin se modela como una dependencia con el estereotipo import.
Elementos extensibilidad Pueden aadirse valores etiquetados para aadir nuevas propiedades al paquete (como el autor, fecha creacin, etc) y estereotipos para especicar categoras. Estos son: 1. facade: (fachada) Es un paquete que muestra solo unos objetos de otro paquete. Se usa para mostrar vistas simplicadas y diferentes que de otra forma seran vistas muy complejas, reduciendo el campo de visin segn las funciones que vayan a usarse. 2. stub: Paquete tiene la funcin de proxy a otro paquete. 3. subsystem: Representa una parte independiente del sistema completo. 115

4. system: Representa al sistema completo.
6.11 Los paquetes
116
7 HACKING DEL KERNEL
Parte II
Prctica
7. Hacking del kernel
7.1. Introduccin
Programar en espacio del kernel ha sido siempre cosa de gurs, o al menos eso es lo que se piensa. Muy poca gente tiene el coraje, los conocimientos y la paciencia para trabajar con interrupciones, devices y con el siempre temido kernel panic. Cuando se escribe un programa en espacio de usuario, lo peor que puede pasar es un core dump. El programa hizo algo muy malo, as que el sistema operativo decide que el programa debe nalizar y hace un volcado de toda la memoria y la informacin del estado del proceso en forma de un chero core. Los cheros core pueden ser usados luego para debugar el programa y encontrar el problema que origin el core dumped. Pero cuando se programa dentro del kernel la cosa cambia, no hay ningn sistema operativo que pueda pararte de manera controlada, y decirte luego qu era lo que ha funcionado mal. Se supone que el kernel de Linux funciona correctamente y no debe controlar su propio cdigo. A veces puede sobrevivir a un kernel panic, si lo que se ha hecho mal es relativamente benigno, este tipo de kernel panic se le suele llamar oopses, luego lo pasar a explicar ms detalladamente. Pero, no hay nada que pare al cdigo de sobreescribir o acceder a localizaciones de la memoria de cualquiera dentro del espacio de direcciones del kernel. Tambin, puede colgarse algn mdulo, entonces el kernel se cuelga, tcnicamente el thread se cuelga pero tiene las mismas repercusiones. Estos problemas pueden sonar un poco exagerados pero se tiene que tratar con mucho cuidado. Adems si hay un kernel panic, raramente se sabe que demonios ha pasado, porque simplemente el sistema operativo deja de funcionar. La tpica solucin es mirar aquellos printk que creemos han causado el error, y esperar que podamos verlos al rebotar la mquina y no se hayan perdido. Y todo esto 117
7.2 Uso del debugador
asumiendo que no se ha corrompido el sistema de cheros. Porque he llegado a perder un sistema de cheros completo de una mquina virtual despus de un triste kernel panic, supongo que debido a una mala inicializacin de un puntero que sobreescribi algunas estructuras internas del ext2. La primera cosa que se aprende cuando se programa en dentro del kernel es que hay que mantener una copia de toda la programacin en una mquina diferente, mntalo como sea, ya sea con NFS, con ftps, o con mquinas virtuales mientras esta no acceda directamente a una particin del ordenador donde se est trabajando. Los cheros permanecen seguros en otra mquina. An as no se ahorra uno tiempo teniendo que hacer los e2fsck incluso para los sistemas ext3, despus de un kernel panic. As que, con todo esto no sorprende que poca gente haya entrado en la programacin real del sistema operativo.
7.2. Uso del debugador

El uso de un debugador est mal visto generalmente por gente como Linus Torvalds. Considerando lo que l mismo ha dicho en la lista de mailing del kernel de Linux: Im afraid that Ive seen too many people x bugs by looking at debugger output, and that almost inevitably leads to xing the symptoms rather than the underlying problems. Linus Torvalds Dice que se debe usar el cdigo fuente para resolver los problemas y los bugs del kernel. Adems que resolviendo bugs mirando slo el debugger se peca de arreglar los sintomas en vez de resolver el problema que est tras ellos. El uso de un debugador solamente no es suciente, debe mirarse el cdigo. Pero tambin hay que tener en cuenta que es necesario tener mucha experiencia programando, y resolviendo problemas que ya han visto antes. Es necesario llegar a la raz del problema observando el cdigo. Pero llegar a tener esta experiencia programando en el kernel requiere un uso inteligente del debugador. 1. Usar el debugador para recoger las evidencias alrededor del problema. 2. Estudiar el cdigo y pensar qu est sucediendo. 118
7.2 Uso del debugador
3. Intentar concentrasrse en las posibles causas de los sntomas que se ve en el debugador. Entonces pensar las posibles causas hasta la raz del problema. Escibir una lista de posibilidades, ponindolas en orden de parecido al problema y probndolas una a una. El proceso de claricacin de ideas escribindolas puede ser de gran ayuda. 4. Hasta que se tenga ms experiencia, se debera usar el debugador para probar algunas ideas probando valores de variables. Por eso el debugador es una herramienta para estimular la razn, y el pensamiento lgico para averiguar que est sucediendo en el cdigo. No hay que resolver los problemas para arreglar la salida del debugador. Y aqu hay una lista de las cosas que se deben hacer y las que no: Qu hacer: 1. Estudiar el cdigo antes de empezar a jugar con el debugador. Se es mucho ms productivo si se tiene en mente el cdigo, antes de empezar a debugar. 2. Usar el debugador para probar las ideas y presunciones, los bugs vienen normalmente como resultado de presunciones incorrectas. Pues bueno hay que hacer ms intentos, que es posible que fallen, pero tambin es posible que no. 3. Si las presunciones son incorrectas, hay que aprender de porqu esa presuncin est mal, es importante que no se repita, porque a lo mejor la prxima vez no nos rebentar a nosotros, sino a otros, o peor an que de un kernel panic cuando tenemos un ordenador en produccin. 4. Descartar el debugador cuanto antes mejor. Trabajar en el cdigo. Qu no hacer: 1. Ignorar las causas reales del problema que podamos pensar. Cuando se encuentra que algo est mal, no hacer que funcione para este o ese otro caso, para que parezca que funciona. Un ejemplo clsico es aadir otra seccin a un statement del switch para cubrir las posibilidades que no se hayan pensado. 119
7.3 printk
2. Resolver ciegamente un problema con el debugador. Se puede llegar a conclusiones errneas y no se aprende mucho sobre el proceso. Una vez entendido como debe usarse un debugador y como no debe usarse vamos a ver las diferentes posibilidades que hay disponibles. Existen varias formas para debugar:
7.3. printk
La funcin printk es la forma que se tiene de guardar logs del sistema y pasarlos al syslog. printk() pasa mensajes del kernel a la consola, al dmesg y al demonio syslog. Es til si se esta debugando y haciendo reports de errores, y puede usarse dentro de un contexto de una interrupcin [RU1], pero debe usarse con cuidado: si la mquina tiene su consola saturada de mensajes printk no es til. Usa un formato muy parecido y casi compatible con la funcin printf del ANSI C, y la concatenacin de strings para dar prioridades a los argumentos: printk( KERN_INFO i = %u\n, i); Es necesario ver el chero include/linux/kernel.h para ver otros valores del KERN_. Estos se interpretan como el nivel para el syslog. Un caso especia para imprimir una IP en uso es de la siguiente manera: __u32 ipaddress; printk(KERN_INFO mi ip: %d. %d. %d. %d\n, NIPQUAD(ipaddress)); printk () usa internamente un buffer de 1KB y no puede pillar overruns. As que hay que asegurarse que el mensaje no es mayor. Dicen los gurus que se sabe que uno es un hacker del kernel autntico cuando se escribe en vez de usar printf en un programa normal se usa printk. A mi todava no me ha pasado, todava. Los ocho posibles tipos de nivel que se denen 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

KERN_ALERT: Una situacin que requiere una accin inmediata.
7.3 printk
KERN_CRIT: Condiciones crticas, normalmente relacionados con problemas serios de hardware o software. KERN_ERR: Usado para indicar errores de condiciones KERN_WARNING: Warnings sobre situaciones problemticas que en s no pueden crear problemas serios al sistema. KERN_NOTICE: Situacioens que son normales, pero que se quieren anotar. Las condiciones relacionadas con la seguridad se reportan a este nivel. KERN_INFO: Mensajes informativos. Muchos drivers muestran informacin del hardware que encuentran al arrancar y la muestran en este nivel. KERN_DEBUG: Usado para mensajes de debugaje. Cada string representa un entero. Que van desde 0 a 7, con los valores ms pequeos representando las prioridades ms altas. [ALS]. Basndose en el nivel del log, el kernel puede que muestre los mensajes en la consola, en un terminal modo texto o en una impresora. Si la prioridad es menor que la variable console_loglevel, entonces los mensajes se muestran por consola. Si ambos klogd y el syslogd estn ejecutndose en el sistema, los mensajes del kernel se aaden a /var/log/messages o donde se haya congurado con el syslogd. Si el klogd no se est ejecutando, los mensajes no se mostrarn en el espacio de usuario, a no ser que se lea /proc/kmsg. La variable console_loglevel se inicializa a DEFAULT_CONSOLE_LOGLEVEL y puede ser modicada a travs de la llamada a sistema sys_syslog. En el kernel actual se puede hacer que todos los mensajes se muestren por consola haciendo los siguiente desde la cuenta de root: (bash)$ echo 8 > /proc/sys/kernel/printk La mejor ventaja que tienen es que es fcil de usar, haces un printk y si luego hay un kernel panic, pues se mira hasta donde ha ido. Fcil y sencillo. Adems de poder usarse siempre, incluso dentro de una interrupcin.
121
7.4 Oops
Pero tiene varios inconvenientes. Si por ejemplo tenemos un error puetero, como por ejemplo que cuando empezamos a leer de un device, por ejemplo, nosotros sobreescribimos toda la memoria. Los errores de sobreescritura de memoria son muy comunes en los programas hechos en C, pero aqu nadie nos protege de escribir en donde no debamos, porque estamos dentro del kernel mode. En este tipo de casos muchas veces el kernel puede hacer un reboot instantaneo y no saber qu demonios haba pasado, en estos casos los printks que estaban a punto de escribirse no lo hubiesen hecho y luego uno duda si realmente los ltimos printks es realmente lo ltimo que se ha hecho. As que es necesario usar adems del printk otros mecanismos para debugar el cdigo y los errores.
7.4. Oops
Cuando el kernel detecta que existe una condicin de anomala seria, se dispara un oops. Un oops tiene dos funciones principalmente: Volcar la informacin de debugging interesante que podemos usar para diagnosticar la causa del problema. Probar y prevenir que el kernel pierda el control y que cause corrupcin en los datos, o an peor que se cause dao al hardware, aunque es difcil que suceda, es posible. Al principio, un oops parece completamente incomprensible, un montn de lneas con valores hexdecimales y con datos que parecen crpticos. ![CDATA[ CPU: 0 EIP: 0010:<c011933c> Tainted: P Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010002 eax: 00000ce0 ebx: 00001000 ecx: c778a510 edx: 00000610
esi: 00000002 edi: 00000000 ebp: c02165c0 esp: c6663f58 ds: 0018 es: 0018 ss: 0018 Process pcmcia (pid: 1003, stackpage=c6663000) Stack: 00000000 c02165a0 00000000 c02165c0 c6663fc4 c01193cf c0116340 00000000 00000001 c02165c0 fffffffe c011616a 122
7.4 Oops
c0214900 00000000 c6663fbc 00000046 c010817d 00000000 Call Trace: <c01193cf><c010ac96><c0116406><c0116340><c011616a> Code: 89 42 04 89 10 c7 41 04 00 00 00 00 c7 01 00 00 00 00 fb 53 > > EIP; c011933c <timer_bh></timer_bh>+228/27c> ===== Trace; c01193cf <do_timer></do_timer>+3f/70> Trace; c010ac96 <timer_interrupt></timer_interrupt>+62/110> Trace; c0116406 <bh_action></bh_action>+1a/48> Trace; c0116340 <tasklet_hi_action></tasklet_hi_action>+40/60> Trace; c011616a <do_softirq></do_softirq>+5a/ac> Trace; c010817d <do_irq></do_irq>+a1/b4> Trace; c0109f48 <call_do_irq></call_do_irq>+5/d> Code; c011933c <timer_bh></timer_bh>+228/27c> 00000000 <_eip>: Code; c011933c <timer_bh></timer_bh>+228/27c> ==== 0: 89 42 04 mov %eax,0x4( %edx) Code; c011933f <timer_bh></timer_bh>+22b/27c> 3: 89 10 mov %edx,( %eax) Code; c0119341 <timer_bh></timer_bh>+22d/27c> 5: c7 41 04 00 00 00 00 movl $0x0,0x4( %ecx) Code; c0119348 <timer_bh></timer_bh>+234/27c> c: c7 01 00 00 00 00 movl $0x0,( %ecx) Code; c011934e <timer_bh></timer_bh>+23a/27c> 12: fb sti Code; c011934f <timer_bh></timer_bh>+23b/27c> 13: 53 push %ebx 0>Kernel panic: Aiee, killing interrupt handler! 3 warnings issued. Results may not be reliable. ]]> </_eip></c0109f48></c010817d></c011616a></c0116340> La anatoma de un oops es muy de bajo nivel, adems cada imagen del kernel tienen un oops especco. Por eso, se necesita hacer un post proceso para obtener informacin de donde empezar a hacer el proceso de debugaje. La idea es compilar 123
====
7.5 Mquinas virtuales
en ensamblador all donde creemos que est dando el error, y mirar las ltimas operaciones para saber donde nos ha dejado colgado el kernel. Esta es la nica manera de saber qu le ha pasado a un kernel que ha dado un kernel panic y ha dejado de funcionar. Los inconvenientes son varios, para empezar es muy difcil de entender el volcado (aunque cuando es la nica ayuda disponible esta es muy valiosa) y otro inconveniente es que hay que compilar el kernel con la opcin oops y est ocupa espacio dentro del kernel, que a pesar de ser pequeo es importante en proporcin al resto de kernel.
7.5. Mquinas virtuales

Cuando haban los mainframes, y la misma mquina se comparta entre varios sistemas naci la idea de mquinas virtuales. Una mquina virtual es una encapsulacin de un ordenador a tu entera disposicin. Un programa dentro de una mquina virtual no tiene acceso real al hardware fsico. Todo el acceso al hardware se controla mediante la mquina virtual, que emula al ordenador. Es una interfaz entre el programa y la mquina real. La idea es tener un ordenador con un sistema operativo sobre el que se trabaja, donde se edita y se compila el cdigo. Tener bajo este sistema operativo un programa que sea una mquina virtual, y sobre este programa que emula un ordenador hacer correr el sistema operativo que est bajo desarrollo. As de esta manera cuando el sistema sobre el que estamos trabajando se cuelga, o da un kernel panic, o sobreescribe datos del disco, solo le afecta a la mquina virtual. Y as mientras se reinicia el sistema se puede seguir trabajando con la misma sesin. Al ordenador fsico no le pasa nada. Existen dos posibilidades, de mquinas virtuales: una que es la VMware (Virtual Machine ware) y otra de libre distribucin llamada UML (User Mode Linux). VMware es muy potente, permite emular cualquier sistema operativo basado en x86, bajo Windows NT, Windows 2000, Windows XP o Linux. Y puede correr bajo mquinas x86 y sobre ordenadores basados en chips de Motorola como los Macintosh. La versin para Linux que se puede bajar por Internet cuesta 299$ US.
124
7.6 Debugando con dos mquinas
VMware emula una mquina x68, con alguna caracterstica, por ejemplo la interfaz del disco duro es un scsi, la targeta de red es una AMD, etc.. A la hora de recompilar el kernel es necesario activar el soporte para targetas de red AMD PCnet32 PCI. Y activar el soporte SCSI igual que el soporte para discos SCSI. UML es la segunda opcin, es gratuito, pero tiene un inconveniente y es que no es una mquina virtual completa. No emula diferentes tipos de hardware, tampoco te da la posibilidad de ejecutar ostro sistema operativo. Pero permite ejecutar un kernel en el espacio de usuario, y eso representa varios benecios cuando se trata de desarrollo: los cheros del host estn protegidos, el sistema de cheros virtual se puede descargar, se pueden ejecutar varias mquinas en una sola, y lo mejor es que es muy fcil usar el degubador para el kernel. No se necesita comprar ms hardware para hacer los tests, al menos que se est programando un device especco. Ejecutar el UML es fcil, hay que bajar los binarios y luego, o bien instalar un nuevo sistema o bien bajarse uno que ya est prehecho de la pgina web. A pesar de algunos inconvenientes del sistema UML, tiene una ventaja muy buena a la hora de programar algn sistema de cheros, pues el resultado de las operaciones pueden destrozar el sistema de cheros. Cuando se trabaja con UML si hay un kernel panic del sistema de cheros, lo nico que hay que hacer es borrar un chero .cow (cheros Copy On Write), y en caso de estar corrupto el sistema de cheros, este se restaura a la versin original, as que ya no hay que hacer los fscks.
7.6. Debugando con dos mquinas

Esta solucn pasa por tener dos mquinas en una se desarrolla el software y en la otra se ejectua el kernel de desarrollo. Debe ser capaz de ejecutarse el debugador en la mquina de desarrollo y tener un terminal de consola abierto al segundo ordenador. Hay que montar dos mquinas, mquina de trabajo y la otra mquina te testeo, donde se ejecutarn los kernels en desarrollo.
125

Hardware
La primera mquina tiene el sistema operativo de desarrollo con una tarjeta ethernet. La segunda mquina, no necesita monitor, dependiendo de lo antiguo que sea el ordenador (depende de la BIOS) necesitar un teclado para arrancar, aunque es muy recomendable, al menos para hacerle un Ctr-Alt-Supr y otras operaciones en el caso de no poder acceder remotamente. Tambin necesita una Ethernet, aunque lo mejor es tener dos Ethernets en esta mquina y as poder pasar paquetes a travs de ella. Construir dos cables serial, uno servir para ejecutar el gdb (el debugger) y el otro para dar acceso a una consola as puede controlarse remotamente. Los cables serial necesitan tener esta disposicin: Solder-side pins: \-----------------------/ \ \ 1 6 2 7 3 8 4 9 5 / /
\-----------------/ Wiring: (use 7 or 10 wire foil screened cable) 1 | 6---------------4 2---------------3 3---------------2 4---------------6 | 1 5---------------5 7---------------8 8---------------7 Necesitan estar conectados cada uno entre los puertos serie respectivos de cada uno de los ordenadores. com1 al com1 y com2 al com2.
126

Software
Instalar ssh en apollo, instalar sshd en la segunda mquina que es el servidor para conexiones del tipo ssh (Sercure SHell), con este servidor no solo se pueden hacer conexiones de consola con una shell tambin se puede hacer transferencias de cheros mediante conexiones seguras a modo de ftp. Que servirn para traspasar cheros. Congurar el sistema de tal modo que haya acceso a la segunda mquina desde la primera. Dar permisos de lectura/escritura a /dev/ttys0 y a /dev/ttyS1que corresponden a los puertos serie. Instalar minicom en ambas mquinas, es un programa para hacer telecomunicaciones entre sistemas UNIX y puede encontrarse en http://www.netsonic./~walker/minicom.html. Para la preparacin del kernel se tardar ms tiempo. Es necesario bajarse el kernel 2.4.18 y descomprimirlo en la mquina apollo. No se debe instalar el ltimo kernel el 2.4.19 porque se necesita un parche para ejecutar el kgdb y este solo esta disponible para 2.4.18 y anteriores. Bajarse el parche antes comentado en http://kgdb.sourceforge.net/. Aplicarle el parche desde el bash de la siguiente manera: cat kgdb\_2.2.18.diff |patch -p2 Entonces compilar el kernel de manera que como se ha hecho siempre, pero en el men hay que aadir a la conguracin usual dos nuevas opciones:
* support for console on serial port under character devices * kernel support for gdb (new) under kernel hacking. Y es recomendable compilar todas las opciones directamente al kernel en vez de usar los mdulos, as cuando pasemos los cheros habr que pasar solo la imagen del kernel. Tras esto hacer un make dep bzImage como de una compilacin del kernel normal y corriente. Copiar la imagen a la segunda mquina, tambin se puede usar un FTP, pero no es necesario si se dispone del sshd, solo hay que escribir la siguiente orden: scp arch/i386/boot/bzImage segunda:bzimage-2.2.18-kgdb 127
Entrar en la segunda mquina, y desde la cuenta de root, copiar la imagen del kernel al directorio /boot y aadir las siguientes lneas en la conguracin del lilo, para crear una nueva entrada con el nuevo kernel. image=/boot/bzImage-2.2.18-kgdb label=kgdb root=/dev/hda1 read-only append=" gdb gdbttys=0 console=ttys1" serial = 0,9600n8 La ltima lnea nos dice que podemos controlar las opciones del lilo cuando se arranca el ordenador desde la misma consola conectada al serial com2, se puede usar el gdb (el debugador) por /dev/ttyS0 y adems se usa la /dev/ttyS1 para usarlo como una consola. De esta manera se pontrola todo el proceso de debugaje y con la consola se puede acceder remotamente, con los cables por los puertos serie. Es muy importante ejecutar lilo cuando se haya terminado de editar este chero, en el supuesto que pasara leer en la seccin de compilar el kernel la solucin. En la mquina de desarrollo hay que crear un chero llamado .gdbinit en el directorio raz del cdigo fuente del kernel, este chero debe contener las siguientes lneas: define rmt set remotebaud 38400 target remote /dev/ttyS0 end Ejecutar en esta mquina como root la siguiente orden: minicom -s Y en este programa se dispone de un men donde hay que congurar las opciones del puerto de serie.
128

Serial Device Lockfile Location Callin Program Callout Program Bps/Par/Bits Hardware Flow Control Software Flow Control

: /dev/ttyS1 : /var/lock : : : 9600 8N1 : No : No
Luego guardarlo en la opcin Save setup as d y tras guardar la conguracin como defecto salir. As dejar luego al minicom esperando una sesin. Rebotar la segunda mquina y entonces aparecer en la primera por la salida del minicom las siguientes lneas: Linux version 2.2.18serialgdb Detected 167046 kHz processor.
Console: colour VGA+ 80x25 Calibrating delay loop... 333.41 BogoMIPS Memory: 63556k/65536k available (704k kernel code, 408k reserved, 824k data, Dentry hash table entries: 8192 (order 4, 64k) Buffer cache hash table entries: 65536 (order 6, 256k) Page cache hash table entries: 16384 (order 4, 64k) CPU: Intel Pentium 75 - 200 stepping 0c Checking 386/387 coupling... OK, FPU using exception 16 error reporting. Checking hlt instruction... OK. Intel Pentium with F0 0F bug - workaround enabled. POSIX conformance testing by UNIFIX Trying to free free IRQ4 Waitng for connection from remote gdb on ttyS0 Entonces sabremos que la conguracin a dado resultado. En la primera mquina tenemos que arrancar el debugger apretando gdb vmlinux>(en la raz del directorio del cdigo fuente) y entonces arrancar el gdb y mostrar una informacin sobre el programa y aparecer una lnea de comandos. Hay que escribir rmt y entonces leer el chero .gdbinit, se conectar al puerto serie y debe mostrar las lineas siguientes: 129
(gdb) rmt 0xc010da29 in breakpoint () at gdb.c:701 701 (gdb) if (initialized) BREAKPOINT();
Se puede continuar y pasar por los breackpoints con el comando de continuar del gdb que es el c. De esta manera se puede debugar el kernel y saber en todo momento qu es lo que hace y all donde nos da problemas poder averiguar y probar posibles soluciones.
130
8 DISEO DE LA APLICACIN
8. Diseo de la aplicacin
8.1. Esquemas UML
Debido a que dentro del kernel de Linux no se puede compilar en C++ no existen objetos ni tampoco clases. Esto hace que dos de los diagramas ms importantes del UML no puedan crearse. An as UML es sucientemente verstil como para poder denir un proyecto sin usar estos dos diagramas. Para entender un proyecto debemos disponer al menos de un diagrama estructural, para tener una vista el diseo de la estructura, y otro diagrama dinmico, para tener una vista del funcionamiento. Los siguientes puntos detallan los diferentes diagramas del proyecto: un diagrama de casos de uso, dos diagramas de actividades y otro diagrama de secuencia. 8.1.1. Casos de uso Casos de Uso es una tcnica para capturar informacin de cmo un sistema o negocio trabaja, o de cmo se desea que trabaje. En el diagrama casos de uso se representa las operaciones que el Administrador puede hacer con el rewall.
Casos de Uso
Firewall Cargar polticas
Leer logs Administrador Ver estadis.
Las cargas de polticas se producen cuando el administrador desea modicar 131
8.1 Esquemas UML
las polticas y tras cambiar el chero de conguracin se dispone a cambiar las polticas. Devuelve un mensaje de error indicando si el chero est incorrectamente tipicado, o bien un mensaje mostrando la correcta carga de los nuevos datos. El objetivo es cambiar las polticas que estn guardadas dentro de las estructuras de datos del rewall. Leer los logs se produce siempre que el administrador desea comprobar los intentos de ataques que el rewall 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 rewall. Ver las estadsticas se usa cuando el administrador desea comprobar el funcionamiento actual del rewall, as como la suma total de las operaciones que haya ejecutado. Devuelve la suma de todos los paquetes que se hayan chequeado, como los bloqueados. El objetivo es poder ver unas estadsitcas del rewall resumidas y actualizadas en todo momento. La cronologa de los casos de usos tiene sentido de la siguiente manera: cargar las polticas al principio, comprobar que funciona con la vista de las estadsticas y cada cierto tiempo comprobar el estado de la mquina viendo los cheros log. 8.1.2. Diagramas de actividades Un estado de actividad representa una actividad: un paso en el ujo de trabajo o la ejecucin de una operacin. Se usan para entender el comportamiento de una parte del programa. Muestran una vista dinmica del funcionamiento del programa. El primer diagrama muestra como se cargan las polticas dentro de las estructuras internas del rewall.
132
Introducir polticas
8.1 Esquemas UML
Parsear polticas
incorrecto correcto
Mostrar errores
Introducir polticas CUIDADO! Semforo de escritura
Mostrar resultados
Este esquema representa el proceso de cargado de polticas, lo primero que se realiza es un parseado del chero, comprobando que las reglas estn semnticamente bien escritas. Genera los datos de acuerdo con lo leido en el chero. Si todo este proceso fuese correcto entonces se introducen las polticas de seguridad dentro del rewall, habiendo activado el semforo de escritura previamente. En el caso que el proceso diera errores se mostraran los resultados sin modicar en ningn momento la estructura interna del rewall. En el segundo diagrama de actividades se muestra como funciona el ltro de un paquete, guardado en un sk_buff.
133
Filtrar sk_buff
8.1 Esquemas UML
Filtrado de un sk_buff
CUIDADO! Semforo de lectura Es esta poltica?
otra bsqueda
Encontrada Hay que hacer log? log
printk de los datos
Pasa el filtro? pasar
bloquear
liberar sk_buff
Retornar sk_buff
Para cada estructura sk_buff que entra dentro del ltro se busca si hay alguna poltica que pertenezca al sk_buff. El orden de las polticas es importante ya que la primera poltica que de xito se pasar a la siguiente fase. Si la poltica especca muestra que hay que hacer log se guarda mediante el printk los datos del sk_buff y el resultado de la operacin de ltrado. El syslog ya se encargar de marcar la fecha y de su escritura en los cheros de log del sistema. Despus de ello se mira si hay que eliminar el paquete, en ese caso se libera el sk_buff, y si no es as se 134
8.1 Esquemas UML
contina retorna del ltrado y se continua por donde estaba trabajando el sistema operativo. 8.1.3. Diagrama de secuencia El diagrama de secuencia muestra la relacin que tienen los distintos componentes del sistema a lo largo del tiempo. El tiempo transcurre de arriba abajo. En este caso se muestra el diagrama de secuencia del proceso de ltrado de un paquete.
Firewall Kernel
filtrar() sk_buff dev
Activar Semforo Lectura
recurrencia polticas
retornar resultado Si bloquear kfree_skb(skb)
Desactivar Semforo Lectura
Se observa como interactan el rewall y el kernel a la hora de ltrar un sk_buff. Al hacer la llamada desde cualquier hook y pedirle al rewall si pasa el ltro o no, este activa el semforo de lectura mediante las funciones que ofrece el kernel. Busca la poltica dentro de las estructuras de datos que tiene el rewall, y tras encontrarla le pide al kernel que libere el semforo de lectura. Retorna el
135
8.2 Exclusin mutua
rewall el resultado del ltro y si se debe bloquear pues se pide al kernel que libere el bffer correspondiente a ese paquete. Sino se contina como si no hubiera pasado nada.
8.2. Exclusin mutua

Antes de explicar donde tratar los paquetes y como tratarlos, es importante hacer un repaso a la teora de exclusin mutua, ya que antes de acceder a cualquier estructura de datos dentro del kernel hay que averiguar si debe controlarse con semforos. 8.2.1. La importancia de los semforos A la hora de hablar del kernel si se accede a cualquier tipo de estructura de datos desde dos sitios se tiene muy probablemente un bug, porque no se asegura la cosistencia de los datos dentro del kernel. Y como me pas a m, si no se protegen las estructuras con semforos, el kernel hace un kernel panic y deja de funcionar a la mnima. Al principio como uno no est acostumbrado a trabajar dentro de un sistema operativo se le hace raro que se acceda a una estructura de datos desde dos sitios diferentes y que de la casualidad que al mismo momento que se accede a esas direcciones por una parte y que por otra parte se haga alguna operacin no vlida y que como resultado pare el sistema. Se hace difcil que se cumplan dichas condiciones, pero no es as, y por lo tanto hay que asegurarse de cumplir la teora siempre que se tengan datos compartidos. 8.2.2. Locks de lectura Tenemos varios procedimientos de proteger los datos deshabilitando las IRQ. En el chero include/linux/brlock.h se denen las diferentes posibilidades. Lo que hacen es hacer un #dene que aunque no est recomendado simplica mucho el trabajo. En el caso de la proteccin a los datos de sk_buff tenemos que usar la funcin br_read_lock_bh(BR_NETPROTO_LOCK) para activar el semforo y entrar en la zona de exclusin mutua que el cdigo se debe proteger mediante semforos. Y el br_read_unlock_bh(BR_NETPROTO_LOCK) para salir de la zona crtica. La
136
denicin es la siguiente:
8.2 Exclusin mutua
#define br_read_lock_bh(idx) \ do { local_bh_disable(); br_read_lock(idx); } while (0) ... ... #define br_read_unlock_bh(idx) \ do { br_read_unlock(idx); local_bh_enable(); } while (0) Como puede verse, para entrar dentro de la zona protegida se desactiva primero los bh (botton halves) que es el mecanismo que se haca en los anteriores kernels para proteger zonas de exclusin mutua. El principal inconveniente es que solo funciona para una sola CPU y por eso se usa ahora softirqs pero lo cierto es que cuando se llega al proceso de tratar los paquetes, estos solo se tratan en una CPU as que nos sirve perfectamente este mecanismo. Y entonces se activa el lock sobre la variable BR_NETPROTO_LOCK. Como puede verse en el chero include/linux/brlock.h solo existe dos tipos de locks para este semforo, uno son los BR_NETPROTO_LOCK y otro son BR_GLOBALIRQ_LOCK. El modo de uso es parecido a esto: br_read_lock_bh(BR_NETPROTO_LOCK); .. -Regin CrticaAcceso solo lectura .. br_read_unlock_bh(BR_NETPROTO_LOCK); El mecanismo que nos ofrece es vastante complejo, ya que en si se usa una arquitectura i386, ia64 o una x86_64 se pueden usar operaciones atmicas, y para el resto de casos no se usan los locks atmicos. Estos semforos son solo para proteger los datos para lectura, cuando se desee hacer una escritura a los datos se debe usar los semforos para protegerlos de las escrituras. Porque cuando se protege para lectura pueden acceder muchos mecanismo, pero cuando se accede para escritura solo puede entrar uno, en esos casos se usan los locks de escritura. 137
8.2.3. Locks de escritura
8.2 Exclusin mutua
Como he comentado los locks anteriores protegen los datos para que no se pueda hacer escritura sobre ellos, pero permite que otros procesos entren en la regin crtica para hacer lecturas. Entonces para proteger los datos en las escrituras hay que usar otros semforos. Cada vez que se quiera hacer una escritura a los datos, como por ejemplo cuando se guarda las polticas del rewall dentro de la estructura, se debe usar estas funciones: #define br_write_lock_bh(idx) \ do { local_bh_disable(); br_write_lock(idx); } while (0) ... ... #define br_write_unlock_bh(idx) \ do { br_write_unlock(idx); local_bh_enable(); } while (0) La primera funcin protege la regin crtica de ser escrita y tambin de que no se lea. Tiene un control total de los datos. Y la segunda operacin desprotege la regin crtica y permite el acceso a los datos para el siguiente proceso. Como es lgico no se puede poner una de estas funciones sin la otra, una activa el semforo y el otro lo desactiva. Y es muy importante que el uso de este proceso sea mnimo para no afectar al sistema haciendo que vaya ms lento, y cuando se tenga que usar las operaciones que contenga tienen que ser pocas y rpidas. As por ejemplo cuando se tenga que eliminar las polticas, lo que se llama hacerle un ush de los datos, se debera de programar algo parecido a esto: br_write_lock_bh(BR_NETPROTO_LOCK); .. -Regin CrticaAcceso escritura .. br_write_unlock_bh(BR_NETPROTO_LOCK); Y dentro de la regin crtica se puede escribir a los datos porque nadie ms accede a ellos. Hay un ejemplo de este mecanismo, se encuentra en net/core/dev.c y se usa 138
8.3 Filtrado de paquetes
para hacer una llamada a una funcin y hacer que esta sea atmica con respecto a las capas de protocolos. void net_call_rx_atomic(void (*fn)(void)) { br_write_lock_bh(BR_NETPROTO_LOCK); fn(); br_write_unlock_bh(BR_NETPROTO_LOCK); } Se pasa un puntero de una funcin por parmetros, se activa el semforo para la proteccin de escritura, se llama a la funcin y luego cuando esta termine se desactiva el semforo que asegura la exclusin mutua. Esta funcin se llama dentro de los drivers y hace que la funcin que se le pasa como parmetro sea atmica. Es un mecanismo que ofrece el kernel para los desarrolladores de drivers. Y se debe reusar este cdigo, porque los desarrolladores del kernel ya se han asegurado que sea portable dentro de cada una de las distintas arquitecturas. Y dependiendo de la arquitectura para donde se compila el kernel , hace unas funciones u otras. En cambio si tuviese que montarme los semforos, seran poco portables.
8.3. Filtrado de paquetes

El objetivo es poder insertar polticas de seguridad donde se pueda distinguir para cada paquete si entra o si sale, la interfaz y la informacin de la cabecera IP. La solucin planteada es poner solamente cuatro hooks: uno en la entrada a la interfaz de entrada, otro a la salida de la interfaz de entrada, otro a la entrada de la interfaz de salida y el ltimo a la salida de la interfaz de salida. Cada uno de ellos captura el sk_buff y se indica qu hook al hacer la llamada mediante las constantes MW_INPUTINT_IN, MW_INPUTINT_OUT, MW_OUTPUTINT_IN y MW_OUTPUTINT_OUT, se puede leer de la siguiente manera: MY como una cosntante de la aplicacin MyWall, INPUTINT o bien OUTPUTINT segn sea la interfaz de entrada o la interfaz de salida, y el IN o bien el OUT indica si es de entrada o salida respecto esa interfaz. La informacin de la interfaz est dentro de la estructura sk_buff, en el apartado dev, que indica de qu interfaz se trata. 139
Que conjuntamente con la cabecera ip nos indica toda la informacin necesaria para ltrar, 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 ltro tiene que estar situada all donde todos los paquetes pasen por ella al entrar en el sistema operativo, entonces el mejor lugar es justo despus de hacer los chequeos a la cabecera IP, all se inserta la funcin que llama al ltro. Si el resultado de la bsqueda es eliminar el paquete entonces se elimina y sino pues se deja estar y contina el camino del skbuff. El primer sitio donde poner el ltro es en el chero net/ipv4/ip_input.c justo donde se termine la funcin ip_rcv: /* * Main IP Receive routine.
*/ int ip_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type * { ... ... iph = skb->nh.iph; if (ip_fast_csum((u8 *)iph, iph->ihl) != 0) goto inhdr_error; { __u32 len = ntohs(iph->tot_len); if (skb->len < len || len < (iph->ihl< <2)) goto inhdr_error; if (skb->len > len) { __pskb_trim(skb, len); if (skb->ip_summed == CHECKSUM_HW) skb->ip_summed = CHECKSUM_NONE; } 140
} #ifdef CONFIG_MYWALL // Filtro de entrada // MW_INPUTINT_IN ... #endif
Las rdenes de #ifdef y de #endif se usan para proteger el resto del cdigo, en caso de compilar el kernel sin las opcciones de mi ltro (llamado mywall) el compilador extraera las lneas de cdigo que hay entre las deniciones. Pero si alguien desea incluir este rewall dentro de su kernel, entonces incluye los cheros de CONFIG_MYWALL y el compilador deja el cdigo tal cual, apareciendo las funciones que estn incluidas dentro de la denicin. 8.3.2. ip_forward.c Aqu se disponen dos hooks, el primero se situa para la salida del paquete de la interfaz de entrada al ordenador y el segundo se dispone para la entrada del paquete a la interfaz de salida. Que corresponden a las constantes MW_INTPUTINT_OUT y para MY_OUTPUTINT_IN. Estn situados en el chero net/ipv4/ip_forward.c, en la funcin ip_forward(skb). El primero antes de decidir el destino del paquete, y el segundo hook antes de redirigirlo a la segunda interfaz. int ip_forward(struct sk_buff *skb) { struct net_device *dev2; /* Output device */ struct iphdr *iph; /* Our header */ struct rtable *rt; ... #ifdef CONFIG_MYWALL // Filtro MW_INPUTINT_OUT ... #endif iph = skb->nh.iph; 141 /* Route we use */
rt = (struct rtable*)skb->dst; ... #ifdef CONFIG_MYWALL // Filtro MW_OUTPUTINT_IN ... #endif return ip_forward_finish(skb);
En la segunda llamada al ltro se le debe pasar el nuevo device (interfaz) calculado por la tabla de routing. Antes de pasar el segundo hook debe calcularse el TTL, operacin que realiza el sistema operativo, si el TTL es menor que cero se devuelve un ICMP indicando que el tiempo de vida del paquete ha expirado. 8.3.3. ip_output.c Para el caso del ltro de salida el chero donde se implementa es el net/ipv4/ip_output.c y se debe introducir justo antes de que el mensaje sea enviado a la cola de mensajes. Esta funcin es la ip_build_and_send_pkt: int ip_build_and_send_pkt(struct sk_buff *skb, struct sock *sk, u32 saddr, u32 daddr, struct ip_options *opt) { ... ip_send_check(iph); #ifdef CONFIG_MYWALL // Filtro de salida // MW_OUTPUTINT_OUT ... #endif /* Send it out. */ return output_maybe_reroute(skb); }
142
Cuando se envie el puntero del skbuff al ltro se marcar como que se ha capturado saliendo, as se consigue la informacin que se desea. 8.3.4. El sk_buff El sk_buff es una estructra de datos donde los sistemas UNIX guardan los datos [WS2], es la forma que tienen de encapsular la informacin, se usa para describir el movimiento de los datos de red entre las capas de los protocolos. La denicin de la estructura de datos es muy importante, es la representacin de todos los datos, y siempre que se quiera acceder o realizar alguna operacin a los datos de red se debe hacer a travs de esta estructura. La denicin se encuentra en include/linux/skbuff.h y la implementacin de las funciones se encuentra en net/core/skbuff.c. La estructura de datos del sk_buff se puede encontrar en el anexo A. Paso a describir unas cuantas funciones disponibles para tratar los sk_buff. alloc_skb: Crea espacio para un nuevo network buffer, donde se le pasa el tamao y la mscara. Y retorna un puntero al nuevo buffer.
struct sk_buff *alloc_skb(unsigned int size,int gfp_mask) kfree_skbmem: Libera un skbuff pero no quita el estado de este. void kfree_skbmem(struct sk_buff *skb) kfree_skb: Libera un sk_buff y libera cualquier dato adjunto al buffer. Este s que borra el estado del buffer. void kfree_skb(struct sk_buff *skb) skb_copy_bits: Vuelca algunos datos del skb a un buffer del kernel. Se indica el offset, un puntero a donde copiar los datos y cuntos datos copiar.
int skb_copy_bits(const struct sk_buff *skb, int offset, void *to, int len) 143
8.3.5. Operaciones
Sabemos como recoger una estructura sk_buff, sabemos dnde hacerlo y como podemos modicar los dato o acceder a ellos. Ahora falta explicar qu se hace con dicha estructura. Como se ha planteado un sistema de solo dos hooks haba dos lugares donde poda suceder o bien que no cumpliese con las normas de seguridad o bien que s las cumpliese. Cuando tenemos un paquete que est entrando y se captura en ip_input.c en la funcin iprcv( ) el buffer debe ser destruido con la funcin kfree_skb( ) o bien debe pasarse el buffer a la funcin ip_rcv_nish( ) 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 polticas concordaba algn drop. En el segundo caso es porque habra llegado a un pass. Cuando el paquete est saliendo del sistema y se ha capturado en ip_output.c dentro de la funcin ip_fragment( ) el paquete debe ser eliminado usando la funcin kfree_skb( ) si no pasa las polticas de seguridad o bien debe enviarse a la pila de salida mediante la funcin IP_INC_STATS( ) void kfree_skb(struct sk_buff *skb)
144
9 IMPLEMENTACIN DEL FIREWALL
9. Implementacin del rewall

En este captulo se narra los resultados conseguidos despus del desarrollo, como los problemas y las experiencias ms importantes tanto a la hora de debugar como a la hora de tratar con los semforos. Despus se explica como montar un escenario para poder probar el rewall y por ltimo los resultados de dicho escenario.
9.1. Desarrollo
El desarrollo de las aplicaciones dentro del kernel como ya se ha comentado es tedioso, laborioso y un proceso largo. Este es el resultado del proceso de trabajo. 9.1.1. Debugar Todas las formas de debugar que he mostrado son muy tiles, pero hay escenarios que son ms diciles de probar. Por ejemplo, tena que probar como el rewall bloquea paquetes, no solo que le llegan a l y los bloquea cuando debe, sino que adems tiene que enviarlos a otras interfaces correctamente cuando no debe bloquearlos. El proceso es el siguiente: nada ms entrar el paquete tiene que pasar, las polticas del rewall, despus ir al servicio routed, que es el demonio encargado de dirigir los paquetes a la interfaz adecuada segn su direccin ip destino. Tras pasar por este servicio los paquetes deben pasar otra vez por el rewall y sus polticas. No es factible trabajar con un kernel inestable y a la vez usar el mismo para guardar los cambios. Es necesario trabajar como mnimo con una mquina virtual, ya sea con VMware o con UML. Pero no es posible probar como pasan los paquetes por el servicio routed y salen otra vez por otra interfaz en una mquina virtual. Porque la mquina virtual solo dispone de una interfaz ethernet, y no se puede hacer un forward por no tiene sentido un paquete que entra y vuelve a salir por la misma interfaz. La solucin a la que se llega es congurar otro ordenador y probar el kernel en el otro ordenador, se edita el kernel en un ordenador y se hace las pruebas en el otro, pero aparece otro problema: el ordenador que tenemos haciendo las pruebas 145
9.1 Desarrollo
se conecta mediante la ethernet al primer ordenador, y precisamente esa parte del kernel la que se est modicando y la que es ms inestable, as que no tenemos ninguna garanta que llegue correctamente el paquete aunque solo sea para entrar en la consola y ver como est trabajando el kernel recin compilado. Por lo que hay que conectar las dos mquinas como se ha explicado en el captulo de hacking el kernel, en el apartado de debugando con dos mquinas.
Pruebas Desarrollo
Cable serie Debugador + Consola Firewall Router Salida Cable Ethernet NIC Paquetes IP NIC 1 NIC 2
9.1.2. Semforos Cuando se trata los paquetes por el sistema operativo dentro del net/ipv4/ip_input.c, y tras pasar los chequeos simples sobre la cabecera para comprovar la integridad de los datos y otros chequeos, se recoge el paquete por el ltro y se pasa las polticas. Al llamar a la funcin para recoger la estructura sk_buff, al principio de todo lo que hice fue que me mostrar la informacin de cabecera IP del paquete que me acaban de pasar. Algo sencillo, simplemente pasar por el printk la IP origen, la IP destino y alguna informacin ms de poca importancia. La cuestin era averiguar si capturaba todos los paquetes, como trabajar con las estructuras sk_buff y entonces empezar a implementar las listas y las comparaciones que haba diseado con el UML. Este era el cdigo que pretenda implementar dentro de mi funcin: // Imprime la info del sk_buff: // // // // // N. de protocolo; IP origen : puerto origen; IP destino : puerto destino; tamao total; Tipo de Servicio id; fragment offset; time to live 146
9.1 Desarrollo
// y que muestre los datos del sk_buff printk("PROTO= %d %u. %u. %u. %u: %hu %u. %u. %u. %u: %hu" " L= %hu S=0x %2.2hX I= %hu F=0x %4.4hX T= %hu", ip->protocol, NIPQUAD(ip->saddr), src_port, NIPQUAD(ip->daddr), dst_port, ntohs(ip->tot_len), ip->tos, ntohs(ip->id), ntohs(ip->frag_off), ip->ttl); for (opti = 0; opti < (ip->ihl - sizeof(struct iphdr) / 4); opti++) printk(" O=0x %8.8X", *opt++); printk("\n"); Llegados a este caso me dispuse a compilar el kernel, lo cargue en la mquina virtual y la arranqu con el nuevo kernel recin compilado. Cual fue mi sorpresa que nada ms intentar hacer un login como cualquier usuario el ordenador me daba un kernel panic y tenia que reiniciar la mquina. Era extrao porque se colgaba solo cuando hacia el login dentro de una consola. Si ni siquiera pasa por la tarjeta, no son datos que se reciban por ip. O al menos esa es una idea que puede pensarse erroneamente. Entonces decid pasar a intentar entrar remotamente mediante una sesin Telnet o bien mediante una sesin SSH, cual fue mi sorpresa que nada mas conectarse el ordenador me mostraba por la pantalla de consola un kernel panic. Y claro a cada kernel panic que haca pues tena que reiniciar la mquina virtual otra vez, luego haca un chequeo del sistema de cheros para comprobar que estaba correcto, tardaba mucho tiempo y no haca nada. Por qu me daba aquel kernel panic si lo nico que estaba haciendo era mostrar por pantalla y por el sistema de cheros de log unos simples mensajes, algo que por separado haba funcionado perfectamente. Entonces haba que instalar el debuggador, hacerle un trace por el kernel y averiguar qu demonios le estaba pasando. No voy a explicar como debugu el kernel, pues hay un captulo entero que habla de ello. Pero lo que averig era que estaba dando errores cada vez que accedia a los datos del sk_buff que le estaba pasando. No haba protegido el acceso a los datos con ningn spinlock! grave error que me haba supuesto una semana entera de trabajo! 147
9.2 Escenario
Las conclusiones a las que llegu fueron varias: haba aprendido, a parte que me estaba dando cuenta de donde me haba metido, primero la importancia que tenan los semforos, tena que aprender como funcionaban y luego como los deba utilizar. Segundo que cada vez que alguien se conectaba mediante la consola de pantalla lo estaba haciendo mediante TCP/IP y que todo paquete que bloquease en un futuro me prohibira acceder por el mismo puerto de consola. Tercero, que el kernel a la mnima sospecha que tiene de que se est incumpliendo la calidad de preemptivo hace un kernel panic, antes de que se dae cualquier aparato hardware. Cuarto, en realidad no se mueve los datos de la estructura sk_buff, solo se copia el puntero que apunta a ella, por lo que cada vez que llega un paquete o se trata cualquier paquete esta estructura esta siendo accedida lo que signica que hay que protegerla mediante un semforo, as que siempre que se accede a datos protegidos con semforos las operaciones tiene que ser lo ms rpido que se pueda. Estas son las conclusiones a las que llegu, puede que estn equivocadas, pero lo dudo. Pero me haba servido para algo: me haba dado cuenta de la importancia de los semforos y haba aprendido a debugar el kernel. Cuando le puse la proteccin adecuada el sistema operativo pas a funcionar perfectamente. Al acceder mediante consola me daba el siguiente mensaje en el syslog:
PROTO=17 127.0.0.1:745 127.0.0.1:111 L=84 S=0x00 I=0 F=0x4000 T=64 Lo que me daba la razn a la primera hiptesis: al acceder mediante consola lo hace usando TCP/IP y se enva paquetes del puerto 745 al 111. Por otra parte ahora se poda acceder mediante SSH y mediante Telnets, funcionaba todo correctamente.
9.2. Escenario
Para poder ver los resultados es necesario montar el escenario que se compone de unos equipos hardware, el kernel compilado con el rewall nuevo y congurar el rewall y los otros equipos.
148

9.2.1. Hardware
9.2 Escenario
El escenario para probar el correcto funcionamiento del rewall es parecido al escenario de debugar. Pero existe una diferencia y es que ahora es imperioso tener un router o algn equipo que nos retorne los paquetes. Es necesario montar ordenador con una tarjeta Ethernet, otro ordenador con dos tarjetas de red y un router con al menos una entrada Ethernet. Se conectan los ordenadores formando una red (RedA) y otra red entre el segundo ordenador y el router (RedB).
Nuevo Kernel Generador de paquetes
Firewall Router Salida RedA NIC NIC 1 NIC 2 RedB
loopback
9.2.2. Compilar kernel En el segundo ordenador donde se instala el rewall hay que instalar un kernel nuevo con el rewall incluido. Para ello es necesario bajarse un kernel nuevo del www.kernel.org descompilarlo y aplicarle el patch de nuestro rewall. As se elimina el rewall de Netlter que est en todos los kernels 2.4 y se instala el nuevo rewall. Para ello hay que compilar el kernel y crear una imagen del kernel. Con esta imagen se traspasa al ordenador del rewall, se aaden las lneas necesarias en la conguracin del lilo, y se ejecuta el lilo y se rebota la mquina. Todos estos procesos estn correctamente explicados en la parte terica. 9.2.3. Congurar el rewall Una vez arrancado el ordenador donde reside el nuevo kernel con el rewall, hay que editar el chero de conguracin del rewall. Este chero es el /etc/mywall.conf. En este chero se denen los comentarios con las lneas que empiezan con un # y entonces cada lnea corresponde a una poltica del rewall. 149

La sintaxis de las rdenes del rewall son las siguientes:
interfaz int entrada salida todas ip origen / mask : puerto
9.2 Escenario
ip destino
mask
puerto
pasar
registrar
todas
bloquear
Donde pone int, se debe poner la interfaz, luego se puede indicar si de entrada, si es de salida o si es indistinto su sentido respecto la interfaz, se muestra la direccin IP origen con su mscara o bien any para todas las ip, despus se indica el nmero de puerto origen, y se repite con la direccin IP destino con su respectiva mscara o bien con un any para indicar cualquier IP destino, luego viene el nmero de puerto destino y si se bloquea o no el paquete y al nal si se hace un log cuando se case con xito la regla. Esta sintaxis permite ltrar por interfaz y el sentido respecto esta. Permite ltrar por IP destino o IP origen y tambin por nmero de puerto, o bien ambos conjuntamente. Insertar entonces en el chero /etc/mywall.conf las siguientes lneas: # # nombre int # sentido IPorig todas todas todas todas IPdest pas/bloq registrar
interfaz eth0 entrada interfaz eth0 entrada interfaz eth0 entrada interfaz eth1
10.1.0.1/32:80 pasar 10.1.0.1/32:23 pasar todas bloquear todas pasar
registrar
De esta manera solo se permitir ver la pgina web y el Telnet de la mquina 10.1.0.2. Una vez guardada se ejecuta la orden: mywall -F -f /etc/mywall.conf El -F hace un ush de los datos actuales y el -f indica el chero donde estn las conguraciones.
150

9.2.4. Congurar la red
9.2 Escenario
Para que los paquetes nos retornen hay que congurar el router para de manera estatica y decirle que la redA est disponible a travs del ordenador rewall. As que podemos poner los nmeros de red: RedA 10.2.0.0/16 RedB 10.1.0.0/16 Primer ordenador: eth0 10.2.0.1 mscara 255.255.0.0 Segundo ordenador: eth0 10.2.0.2 mscara 255.255.0.0 eth1 10.1.0.2 mscara 255.255.0.0 Router: eth0 10.1.0.1 mscara 255.255.0.0 ruta esttica a 10.2.0.0 / 16 por 10.1.0.2 En el router se ha activado el servidor web y un servidor telnet. Tambin es recomendable que se le active algn otro servicio, que servir para comprobar como el rewall bloquea el puerto y no se recive ningn paquete de dichos servicios, ya que el rewall habra bloqueado la salida. 9.2.5. Resultados Los resultado se pueden observar porque debera de haber bloqueado todas las conexiones exceptuando las dos comentadas anteriormente y porque al poner la orden: mywall -s Se ve una tabla con todas las estadsticas parecida a esta: MyWall un Firewall de Carlos Morales. paquetes IP eliminados: 30 paquetes IP chequeados: 91 paqutes input: 51 bloqueados: 30 pasados: 21 paquetes output: 40 bloqueados: 0 pasados: 40 ... Como puede observarse, algunos de los paquetes que son input son eliminados y otros no. Si se sigue probando los contadores deben ir aumentando de valor. 151
10 CONCLUSIONES
10. Conclusiones
La primera conclusin a la que se llega es que muy poca gente se ha atrevido a entrar dentro del kernel y programar cualquier algoritmo dentro de l, y por lo tanto, la documentacin al respecto es escassima, no hay ningn documento en castellano a parte de este trabajo. Casi todos los documentos tan solo se encuentran en Internet, y los temas tan especcos como la creacin de un rewall solo puede averiguarse preguntando a los desarrolladores del kernel, pero teniendo en cuenta que es un grupo que no facilitan aquella informacin que consideran trivial, se hace ms difcil el aprendizaje. Otra conclusin a la que se llega es que trabajar dentro de un sistema operativo es una tarea muy compleja. Cada vez que se efecta algn cambio por pequeo que sea hay que recompilar todo el kernel, instalarlo y rebotar la mquina con el nuevo sistema operativo. Tampoco se puede trabajar sobre un kernel y probarlo a la vez sobre la misma mquina, ya que un kernel en desarrollo puede daar los datos guardados en disco facilmente. Y como no hay ningn mecanismo que proteja al sistema operativo de hacer operaciones ilegales cuando hace un core dump se para toda la mquina siendo muy dicil hacer un diagnstico de lo que ha pasado. Por todas estas razones es importante aprender como se se ejecuta un kernel en desarrollo en una mquina virtual o en otra mquina conectada a la desarrollo y a la vez tambin como poder debugar este kernel en desarrollo. La programacin dentro del kernel debe hacerse con sumo cuidado. Toda estructura que se cree y que puede ser accedida por varios threads a la vez debe protegerse con semforos. El kernel dispone de funciones para llamar a los semforos, donde se puede indicar si se desea una proteccin de lectura o de escritura. Si no se cumplen con la teora de los semforos lo ms lgico es que de un kernel panic y se pare el kernel cuando se est accediendo desde dos lugarles a la misma estructura de datos. Tambin es importante tener el mnimo nmero de variables estticas, pues ocupan un espacio vital dentro del kernel. Toda estructura debe hacerse dinmica, y aqu el kernel tambin dispone de funciones para crear listas dinmicas de una forma muy sencilla. Lo ms laborioso ha sido resolver estos problemas de trabajo dentro del kernel y hacer el montaje del escenario para hacer las pruebas. Para bloquear haba que 152
10 CONCLUSIONES
probar que ciertos paquetes pasaban las polticas y la respuesta tambin retornaba. Para ello se ha necesitado de tres ordendores, uno emitiendo, otro haciendo de rewall y el ltimo con algn servicio generando respuestas a las peticiones del primero. Al nal el objetivo principal se ha cumplido que era crear un rewall a partir de cero que permitiera ltrar los paquetes por direccin IP origen y destino, por el puerto origen y destino, y todo segn la interfaz y el sentido respecto ella.
153
11 LNEAS DE FUTURO
11. Lneas de futuro

Una vez conseguido bloquear paquetes IP segn su direccin IP origen y su direccin IP destino se puede aadir nuevas funcionalidades que otros rewalls ms complejos tienen, estas funcionalidades son seguimiento de sesiones, NAT y balanceo de carga entre varios rewalls. El seguimiento de sesiones trata de guardar todas las conexiones que se estn mantiniendo en ese momento y con las polticas de ltrado tratar los nuevos paquetes. Ciertos protocolos, como por ejemplo FTP, H323 entre otros mantienen en sus conexiones unas sesiones caractersticas debido a que el cliente y servidor hacen los dos funciones de cliente y de servidor. Tiene un coste aproximado de 500 horas y con los conocimientos necesarios de sistemas operativos y de telemtica puede ser un TFC. Muchos rewalls son los encargados de hacer NAT (Traduccin de direcciones), ya que estn situados justo en el borde de la red a proteger y otra red. Haciendo NAT la red a proteger puede tener IP privadas que no funcionan en Internet, as se hace muy difcil hacer un ataque spoong emulando un ordenador interno. Para hacer NAT se debe mantener tambin informacin de todas las sesiones en curso mediante unas tablas. Donde se guarda todas las sesiones en curso y las traducciones que se estn usando. Es un proyecto con un coste aproximado de 600 horas, y tambin puede ser un TFC. La tercera propuesta es hacer un balanceo de carga entre rewalls. El problema de los rewalls es que la mayora no estn duplicados y no hay reduntancia, y los que disponen de ella son muy caros. La propuesta es balancear las conexiones entre varios rewalls y para su correcto funcionamiento es necesario mantener el seguimiento de las sesiones y NAT entre los diferentes rewalls. Hay que montar un mecanismo entre las mquinas donde se puedan comunicar de forma segura y poder cambiar informacin de las tablas de sesiones. Esta propuesta es mucho ms avanzada y compleja, no solo son necesarios conocimientos de sistemas operativos y de telemtica, sino que es neceario tener conocimientos de arquitecturas avanzadas y de programacin paralela. El coste es aproximadamente de unas 1000 horas y podra hacerse en un PFC por varias personas.
154
12 COSTE DEL TRABAJO
12. Coste del trabajo

El coste del proyecto se divide en documentacin sobre rewalls, documentacin UML, documentacin sobre el kernel de linux, pruebas programando y debugando el kernel, programacin de la aplicacin, experimentacin y pruebas de su correcto funcionamiento y por ltimo la memoria. Se considera documentacin sobre rewalls la bsqueda de la informacin sobre los protocolos TCP/IP y sobre los rewalls. La documentacin UML se basa en el estudio de la metodologia del UML. Por ltimo la documentacin del kernel de linux se enfoc para averiguar cmo trabajar dentro del kernel. La parte prctica comprende las pruebas programando y debugando el kernel, donde se pona en prctica todo lo ledo referente a la programacin dentro del kernel, de su debugado y del montaje del escenario para su funcionamiento. La programacin de la aplicacin es el tiempo destinado a la construccin del rewall. En las pruebas se mont un escenario de pruebas y se comprob que ltraba correctamente. Y la tercera parte es la memoria, donde se especica el tiempo de preparacin de la memoria.
155

Tema Teora Firewalls UML Kernel Total Teora Prctica Estudio del Kernel Programar Firewall Implementacin escenarios Total Prctica Memoria Total Memoria Total Horas 40 h 60 h 140 h 240 h 180 h 65 h 22 h 267 h 140 h 647 h Porcentaje 6,2 % 9,3 % 21,6 % 37,1 % 27,9 % 10 % 3,4 % 41,3 % 21,6 % 100,0 %
156
Bibliografa
[ALS] RUBINI , A LESSANDRO ; Linux Device Drivers, 2nd Edition; ORelly; 2001. ISBN: 0-59600-008-1 [DAV] F RASCONE , DAVID ; Debugging Kernel Modules with User Mode Linux; Mayo 2002 LinuxJournal [GI1] I NSOLVIBLE , G IANLUCA ; Inside the Linux Packet Filter; Febrero 2002 LinuxJournal [GI2] I NSOLVIBLE , G IANLUCA ; The Linux Socket Filter: Snifng Bytes over the Network; Junio 2001 LinuxJournal [GOO] G OOGLE G ROUPS; comp.os.linux.misc [KAH] A RCOMANO , ROBETO; Kernel Analysis- HOWTO; 2002. http://www.tldp.org/HOWTO/KernelAnalysis-HOWTO.html [KAL] K ALE , A MIT S.; Kdbg: Linux kernel source level debugger; 2002 http://kgdb.sourceforge.net/ [KE1] K ERNEL D OCUMENTATION ; Coding Style; linux/Documentation/CodingStyle [KRO] K ROAH -H ARTMAN , G REG; Proper Linux Kernel Coding Style; Julio 2002 LinuxJournal
[LIS] L INUX K ERNEL M AILING L IST A RCHIVES ; Desde 1997; http://www.cs.Helsinki.FI/linux/l kernel/ [LT1] TORVALDS , L INUS ; The Linux Kernel Archives; http://www.kernel.org [RF1] RFC 768; The User Datagram Protocol; DARPA 1980 http://www.ietf.org/rfc/rfc0768.txt [RF2] RFC 791; Internet Protocol; DARPA 1981 http://www.ietf.org/rfc/rfc0791.txt [RF3] RFC 793; The Transmission Control Protocol; DARPA 1981 http://www.ietf.org/rfc/rfc0793.txt 157

[RU1] RUSSELL , PAUL; Unreliable Guide to Hacking The Linux Kernel; http://www.netlter.org/unreliable-guides/ [RU2] RUSSELL , PAUL; Kernel Locking Guide; http://www.netlter.org/unreliable-guides/ [RU3] RUSSELL , PAUL; Linux 2.4 Packet Filtering HOWTO; http://www.netlter.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 Unicado de Modelado. Manual de Referencia; Addison Wesley Ed. 2000. ISBN: 84-7829-037-0. [VAS] VASUDEVAN , A LAVOOR ; CVS-RCS-HOWTO Document for Linux; http://www.tldp.org/HOWTO/CVS-RCS-HOWTO.html [WAR] WARD , B RIAN; The Linux Kernel HOWTO; http://www.tldp.org/HOWTO/Kernel-HOWTO.html [WS1] W RIGHT, G ARY R.; S TEVENS , W. R ICHARD ; TCP/IP Illustrated, Volume 1 The Protocols; Addison Wesley Ed.; 1994. ISBN: 0-201-633469.i [WS2] W RIGHT, G ARY R.; S TEVENS , W. R ICHARD ; TCP/IP Illustrated, Volume 2 The Implementation; Addison Wesley Ed.; 1995. ISBN: 0-20163354-X.
158
Parte III
Anexo A sk_buff
A continuacin se pasa a detallar la estructura del sk_buff. La estructura de un socket buffer se encuentra en include/linux/skbuff.h y se puede acceder a ella a travs de <linux/skbuff.h>, est formada por:
struct sk_buff { struct sk_buff struct sk_buff * next; * prev;
struct sk_buff_head * list; struct sock *sk; struct timeval stamp; struct net_device *dev; union { struct tcphdr *th; struct udphdr struct icmphdr *uh; *icmph;
struct igmphdr *igmph; struct iphdr *ipiph; struct spxhdr*spxh; unsigned char } h; /* Network layer header */ union { struct iphdr *iph; struct ipv6hdr struct arphdr struct ipxhdr unsigned char } nh; 159 *ipv6h; *arph; *ipxh; *raw; *raw;
union { struct ethhdr unsigned char } mac; struct dst_entry *dst;
*ethernet; *raw;
/* * 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 unsigned int unsigned char len; data_len; csum; __unused, cloned, pkt_type, ip_summed; __u32 atomic_t unsigned short unsigned short unsigned int unsigned char unsigned char priority; users; protocol; security; truesize; *head; *data;
unsigned char *tail; unsigned char *end; void (*destructor)(struct sk_buff *); #ifdef CONFIG_NETFILTER /* Can be used for communication between hooks. */ unsigned long /* Cache info */ __u32 nfmark; nfcache; 160
/* Associated connection, if any */ struct nf_ct_info *nfct; #if defined(CONFIG_HIPPI) union{ __u32 ifield; } private; #endif #ifdef CONFIG_NET_SCHED __u32 tc_index; #endif };
Bueno aqu teneis entera la estructura sk_buff, y aqu hay una lista con cada uno de los campos: next : es el siguiente skb en la lista prev : es el anterior skb en la lista list : lista en la que nos encontramos. sk : es el socket que estamos utilizando stamp : valor tiempo en el que nos llego dev : dispositivo que nosotros estamos dejando rx_dev : desde el dispositivo que nos lleg h : cabecera de la capa de transporte (tcp, udp, icmp, igmp, spx, raw) nh : cabecera de la capa de red (ip, ipv6, arp, ipx, raw) mac : cabecera del nivel de enlace dst cb : buffer de control 161
len : longitud del dato csum : checksum used : estamos siendo en uso? is_clone : es una copia sk_buff cloned : la cabecera se puede copiar pkt_type : el tipo de paquete ip_summed : el driver nos suministra un checksum IP priority : prioridad del paquete dentro de la cola de paquetes protocol : protocolo del paquete security : nivel de seguridad del paquete truesize : verdadero tamao del skb. head : puntero al principio del buffer data : puntero al principio del dato. tail : puntero al nal del dato. end : nal del puntero destructor : destructor de la funcion nfcache : info de la cache interna referente a netlter nfct : conexion asociada al socket
162
Parte IV
Anexo B Coding Style

Existen unas reglas bsicas, escritas y no escritas, para asegurarse que otros usuarios del kernel. Existe unas reglas escritas en la propia documentacin de Linux [KE1] y otras reglas no escritas [KRO] pero que se supone todo programador conoce. Como el nmero de desarrolladores que miran el cdigo fuente del kernel de Linux es muy grande, lo mejor es tener una gua consistente a seguir. As es ms fcil entender para cualquiera que lea el kernel lo que se ha insertado, lo que hace que puedan entenderlo mejor y corregir posibles fallos o mejorar el cdigo. Que es eso de lo que se trata todo esto del cdigo abierto o open-source. Indexacin Todos los tabulados son ocho carcteres en blanco y ser eso el caracter <TAB>. Hace que sea ms facil localizar donde estn los diferentes bloques de cdigo. Hay que intentar evitar que haya ms de tres niveles de indexacin, ya que puede causar que navegar por el cdigo sea muy incmodo, pues las lneas sobrepasan el tamao de la pantalla. Poniendo corchetes Los autores originales de UNIX ponan los corchetes con el corchete que abre al nal de la primera lnea y el corchete que cierra al principio de la ltima lnea: if ( x >= 1 ) { hacer_lo_que_sea(); } Por eso, el kernel de Linux usa este estilo. La nica excepcin a esta regla son las funciones, las cuales se tienen el corchete que abre al principio de la segunda lnea:
163
int funcion_cool( int x) { cuerpo de la funcion } Un buen ejemplo a seguir son los cheros que hay en el directorio kernel del cdigo fuente. Nombrar variables y funciones Para nombrar las variables y funciones deberan ser descriptivas y concisas. No usar nombres largos y bonitos como por ejemplo CommandAllocationGroupSize o por ejemplo DAC_V1_EnableMemoryMailboxInterface(), en vez de eso usar cmp_group_size o bien enable_mem_mailbox(). Las variables globales es mejor no usarlas, solo hacerlo si es absolutamente necesario. Las variables locales deberan ser cortas. Para las variables de los bucles puede usarse i o j, mientras que contador_bucle es demasiado largo. Las variables del tipo tmp tambin se permiten pero solo para variables con poco tiempo de vida. Tambin se puede encontar buenos ejemplos en el los cheros del sistema de cheros en fs/*.c. Y ejemplos que son negativos tambin pueden encontrarse en drivers/scsi/cpqfs* . Funciones Las funciones deben hacer solo una cosa y hacerla bien. Deberan ser cortas y ser del tamao de uno o dos pantallas. Si se tiene una funcin que hace pequeas cosas para muchos casos, es aceptable que sea larga. Pero si es larga y adems es compleja hay que modicarla. Dicen que el nmero de variables nos indica la complejidad de la funcin. As que si se tiene un gran nmero de variables entonces es que hay q cambiarlo.
164
Comentarios Los comentarios malos explican como trabaja el cdigo, quien escribi tal funcin en una fecha especca y otras cosas poco tiles. Los comentarios correctos deben explicar qu hace la funcin y porqu lo hace. Deberan incluirse al principio de la funcin y no necesariamente dentro de ella, porque hay que escribir funciones pequeas. Hay un estadar para los comentarios de las funciones, que es una variante del mtodo de documentacin usada en el proyecto GNOME. Lo bueno de usar este tipo de estilo es que luego se puede sacar informacin usando compiladores de documentacion. Que puede verse ejecutando make psdocs o bien make htmldocs para generar un chero postcript o html para cada caso. Para ms informacin mirar Documentation/kernel-doc-nano-HOWTO.txt. Tipos de estructuras de datos Si se crea cualquier estructura de dato donde pueda accederse desde fuera por un thread o por cualquier otro procedimiento hay que implementar un contador de referencias. Si se aade un contador de referencias una estructura, se evitan muchos problemas con race conditions. Y seguro que si hay otro thread que puede encontrar y acceder a tu estructura de datos y no se tiene un contador de referencias seguro que tenemos un bug. Funciones para los strings En el chero 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 chero 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 chero include/asm/byteorder.h donde asm es el tipo de 165
arquitectura del procesador, contiene una gran cantidad de funciones que permiten hacer conversiones automticamente, dependiendo donde se compile y de la arquitectura usar unas funciones u otras. Listas Como en cualquier programa se necesitan las listas dinmicas. Para eso debe usarse las funciones include/linux/list.h. Donde se puede encontrar una estructura: struct list_head, que deberia incluirse dentro de la estructura donde se desee crear la lista. Entonces se podr usar las funciones de aadir, borrar o iterar sobre las listas de manera fcil sin tener que reescribir nuevo cdigo. Algunos buenos ejemplos que he encontrado estn en drivers/hotpluc/pci_hotplug_core.c y en drivers/ieee1934/nodemgr.c. typdef est prohibido Los famosos typedef no deberin usarse para llamar a ningn tipo de estructura. La mayoria de las estructuras del kernel no tienen ningn typedef. Ya que hace ms oscuro el cdigo porque se aaden capas, y no dejan que el programador sepa qu tipo de dato se esta usando. Jams usar un typedef para signicar un puntero a una estructura. Esto esconde el puntero y entonces pueden aparecer muchos problemas, como por ejemplo que no se pide memoria correctamente, que se accede a partes de la memoria donde no se debe, y esta es la forma ms fcil de conseguir un kernel panic. El nico lugar donde los typedef son aceptables es al declarar prototipos de funciones. Estas pueden ser difciles de escribir, asi que haciendo un typedef para estas se convierte en una forma fcil de escribir.
166

TFC Is06200

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TFC Is06200

Enviado por

Direitos autorais:

Formatos disponíveis

Estudio, diseo e implementacin de un Firewall

C ARLOS G USTAVO M ORALES T EJEDA

11. Lneas de futuro 12. Coste del trabajo

III Anexo A sk_buff IV Anexo B Coding Style

2.2 IP: Internet Protocol

2.2. IP: Internet Protocol

2.2 IP: Internet Protocol

identificacin 20 bytes cabecera time to live ip_ttl

2.2 IP: Internet Protocol

2.2 IP: Internet Protocol

2.3 UDP: User Datagram Protocol

2.3. UDP: User Datagram Protocol

Nmero de puerto origen: 16 bits 9

2.4 TCP: Transmisin Control Protocol

2.4. TCP: Transmisin Control Protocol

2.4 TCP: Transmisin Control Protocol

2.4 TCP: Transmisin Control Protocol

Puerto de origen: 16 bits Nmero de puerto de origen. 12

2.4 TCP: Transmisin Control Protocol

2.4 TCP: Transmisin Control Protocol

3 INTRODUCCIN A LOS FIREWALLS

3. Introduccin a los rewalls

3 INTRODUCCIN A LOS FIREWALLS

3.2 Qu puede hacer

3.2. Qu puede hacer

3 INTRODUCCIN A LOS FIREWALLS

3.3 Qu no puede hacer

3.3. Qu no puede hacer

3 INTRODUCCIN A LOS FIREWALLS

3.4 Tipos de Firewalls

3.4. Tipos de Firewalls

Como se discute en el captulo dedicado a TCP/IP cada paquete tiene unas 18

3 INTRODUCCIN A LOS FIREWALLS

3.4 Tipos de Firewalls

3 INTRODUCCIN A LOS FIREWALLS

3.4 Tipos de Firewalls

3 INTRODUCCIN A LOS FIREWALLS

3.5 Arquitecturas Firewall

3.5. Arquitecturas Firewall

3 INTRODUCCIN A LOS FIREWALLS

3.5 Arquitecturas Firewall

3 INTRODUCCIN A LOS FIREWALLS

3.5 Arquitecturas Firewall

3 INTRODUCCIN A LOS FIREWALLS

3.5 Arquitecturas Firewall

3 INTRODUCCIN A LOS FIREWALLS

3.5 Arquitecturas Firewall

3 INTRODUCCIN A LOS FIREWALLS

3.5 Arquitecturas Firewall

3 INTRODUCCIN A LOS FIREWALLS

3.5 Arquitecturas Firewall

4.6 Que hacer

4.6. Que hacer

4.6 Que hacer

4.6 Que hacer

4.6 Que hacer

4.7 Filtrado por direccin

4.7. Filtrado por direccin

4.7 Filtrado por direccin

4.7 Filtrado por direccin

5 EL SISTEMA OPERATIVO LINUX

5. El Sistema Operativo Linux

5 EL SISTEMA OPERATIVO LINUX