Download - Curso Admin is Trac Ion s.o. Unix

CURSO:ADMINISTRACIÓN DEL SISTEMA OPERATIVO UNIX

CURSO

ADMINISTRACIÓN DEL SISTEMA OPERATIVO UNIX

Profesores:

M. I. Samuel Pérez [email protected]

M. I. Moisés García [email protected]

FACULTAD DE INGENIERIA ELECTRICAUNIVERSIDAD MICHOACANA

Septiembre de 2003

CENTRO NACIONAL DE CAPACITACIÓN CELAYA PÁGINA 1 DE 97

DIRECCIÓN DE OPERACIÓN

mailto:[email protected]

mailto:[email protected]


CONTENIDO

INTRODUCCIÓN........................................................................................................................................................... 4

INSTALACIÓN DE UN SERVIDOR UNIX.................................................................................................................... 5

GEOMETRÍA DEL DISCO DURO.......................................................................................................................................... 5PARTICIÓN DEL DISCO DURO........................................................................................................................................... 6FORMATEO E INSTALACIÓN............................................................................................................................................. 8

CONFIGURACIÓN DE LA CONEXIÓN A INTERNET EN EL SERVIDOR...............................................................9

CONFIGURACIÓN DE LA RED............................................................................................................................................ 9Instalación y Configuración del TCP/IP..................................................................................................................... 9Configuración del dispositivo de red........................................................................................................................ 10Notas...................................................................................................................................................................... 12

DIRECCIONES INTERNET................................................................................................................................................ 12Direcciones broadcast y de red................................................................................................................................ 13Desventajas del direccionamiento Internet............................................................................................................... 14Notación decimal punteada..................................................................................................................................... 14Mapeo de direcciones Internet a direcciones físicas..................................................................................................14

MODELO DE INTERACCIÓN CLIENTE-SERVIDOR............................................................................................................... 15Ejemplos................................................................................................................................................................ 15

USO DE IFCONFIG (/ETC/IFCOFIG) PARA INSPECCIONAR UNA INTERFAZ DE RED...................................................................16Configuración de la interfaz de bucle interno de software.........................................................................................16Configuración de una interfaz de red....................................................................................................................... 16

RUTEADO DE TCP/IP................................................................................................................................................... 17Política de ruteado.................................................................................................................................................. 17

ADMINISTRACIÓN..................................................................................................................................................... 21

CREACIÓN DE CUENTAS DE USUARIOS............................................................................................................................ 21Creando una cuenta en el modo de texto: useradd y passwd......................................................................................21Eliminar una cuenta de usuario............................................................................................................................... 21

EL PROCESO EN UNIX. (COMANDOS &, PS, KILL Y TOP)...................................................................................................22PROCESOS SUBORDINADOS............................................................................................................................................ 22DESPEDIDA MIENTRAS SE EJECUTAN PROCESOS SUBORDINADOS.......................................................................................23LA ORDEN PS............................................................................................................................................................... 24LISTA DE LA ACTIVIDAD DE OTROS USUARIOS................................................................................................................. 25PROCESOS DEL SISTEMA................................................................................................................................................ 25MONITOREO DE LA ACTIVIDAD DEL USUARIO................................................................................................................. 27ELIMINACIÓN DE UN PROCESO....................................................................................................................................... 28

SEGURIDAD DEL SISTEMA....................................................................................................................................... 30

LA SEGURIDAD............................................................................................................................................................. 30Protección de los datos frente a los otros usuarios....................................................................................................31Encripción de archivos............................................................................................................................................ 33Ids de presentación y contraseñas............................................................................................................................ 34Historial de presentaciones..................................................................................................................................... 35El superusuario....................................................................................................................................................... 35El archivo de contraseñas........................................................................................................................................ 36

SHELL SEGURO............................................................................................................................................................. 37

SERVICIOS................................................................................................................................................................... 38

FTP............................................................................................................................................................................ 38NFS............................................................................................................................................................................ 40

Sistemas de archivos distribuidos............................................................................................................................. 40




Procesos cliente y servidor NFS............................................................................................................................... 41Archivos de configuración NFS............................................................................................................................... 41

DHCP......................................................................................................................................................................... 43Funcionamiento de DHCP...................................................................................................................................... 43Fases de Consesión................................................................................................................................................. 44Configuración del Servidor DHCP para UNIX.........................................................................................................45Configuración del cliente DHCP............................................................................................................................. 47

SEGURIDAD EN EL KERNEL..................................................................................................................................... 49

SCO OPENSERVER....................................................................................................................................................... 50Opciones de compilación......................................................................................................................................... 50Algunas mejoras de la seguridad............................................................................................................................. 52El súper server o inetd............................................................................................................................................. 52El inetd.conf........................................................................................................................................................... 52El tcpd.................................................................................................................................................................... 55hosts.allow y hosts.deny........................................................................................................................................... 56Misceláneas............................................................................................................................................................ 58

RESUMEN.................................................................................................................................................................... 61

ARCHIVOS IMPORTANTES....................................................................................................................................... 62

EL ARCHIVO /ETC/HOSTS............................................................................................................................................... 62CONTROL DE ACCESO................................................................................................................................................... 62EL ARCHIVO /ETC/SERVICES.......................................................................................................................................... 63EL ARCHIVO /ETC/INETD.CONF....................................................................................................................................... 64EL ARCHIVO /ETC/PROTOCOLS....................................................................................................................................... 66EL ARCHIVO /ETC/NETWORKS........................................................................................................................................ 67EL ARCHIVO /ETC/ETHERS............................................................................................................................................. 67

AUDITORÍA DEL SISTEMA........................................................................................................................................ 68

SISTEMA DE BITACORAS (LOGS) EN UNIX....................................................................................................................... 68EL DEMONIO SYSLOG.................................................................................................................................................... 69ARCHIVOS DE BITACORAS............................................................................................................................................. 73

syslog..................................................................................................................................................................... 73messages................................................................................................................................................................ 74wtmp...................................................................................................................................................................... 74utmp....................................................................................................................................................................... 75sulog...................................................................................................................................................................... 75cron....................................................................................................................................................................... 75

BITACORAS REMOTAS................................................................................................................................................... 76

FIREWALLS (CORTAFUEGOS)................................................................................................................................. 79

CARACTERÍSTICAS DE DISEÑO........................................................................................................................................ 82COMPONENTES DE UN CORTAFUEGOS............................................................................................................................. 84

Filtrado de paquetes............................................................................................................................................... 84Proxy de aplicación................................................................................................................................................ 85

MONITORIZACIÓN DE LA ACTIVIDAD.............................................................................................................................. 86ARQUITECTURAS DE CORTAFUEGOS............................................................................................................................... 87

Cortafuegos de filtrado de paquetes......................................................................................................................... 87Dual-Homed Host................................................................................................................................................... 87Screened Host......................................................................................................................................................... 88Screened net (DMZ)................................................................................................................................................ 88Otras arquitecturas................................................................................................................................................. 89

BIBLIOGRAFÍA............................................................................................................................................................. 90




INTRODUCCIÓN

Este curso presupone conocimiento elemental de los conceptos básicos acerca de redes de computadoras (desde un punto de vista de usuario final), así como práctica en el manejo de internet. Dichos conceptos incluyen el estudio de los diferentes protocolos utilizados para comunicar computadoras locales con computadoras remotas; v.g. FTP, Telnet, HTTP, etc.. También se presupone familiaridad con el manejo del servicio World Wide Web, en todas sus modalidades, e incluyendo todos sus servicios. Estos conceptos se estudian en el curso Internet Básico.

El diplomado, como su nombre lo indica, hace énfasis en las herramientas necesarias para desarrollar aplicaciones usando internet. En el primer módulo se cubren los aspectos relacionados con administradores de redes. Se comienza con la instalación de un servidor Unix. Después se revisa qué cambios se tienen que hacer en el sistema y qué programas se deben ejecutar para que una computadora conectada en red pueda ofrecer los diferentes servicios de red.

En el segundo módulo se estudia el diseño de páginas de web, utilizando el lenguaje HTML.Después se da una introducción al protocolo CGI, mediante el cual podemos ejecutar programas escritos en cualquier lenguaje desde una página de web. Esta característica es la que le da al servicio de web una capacidad interactiva total. Se estudia también el lenguaje Perl, que es el más usado en aplicaciones CGI. Finalmente se estudia el desarrollo de programas que permitan el acceso a una base de datos desde una página de web.

Finalmente, en el tercer módulo se estudia el lenguaje Java. Este lenguaje está diseñado para ser mezclado con aplicaciones web (aunque se puede usar de manera independiente, como un lenguaje de propósito general). Este lenguaje nos proporciona una mayor flexibilidad de programación. Entre las aplicaciones que podemos desarrollar son gráficas y animación.




INSTALACIÓN DE UN SERVIDOR UNIX.

Para la instalación de un servidor Unix, se requieren varios pasos:

Partición del disco duroFormateo de las diferentes particionesInstalación de los sistemas operativos seleccionadosConfiguración del servidor.

En este capítulo estudiaremos todos los pasos menos el último, cuyos detalles nos ocuparán el resto del curso. Vale la pena mencionar que las notas de este capítulo solo mencionan las ideas a groso modo; los detalles serán vistos en las sesiones de práctica, en las cuales se instalará Unix en al menos una máquina, siguiendo todos los pasos requeridos.

Generalmente deseamos instalar Unix en una computadora que actuará como servidor en un entorno de red. Los servicios que un servidor proporciona son: correo electrónico, transferencia de archivos (FTP), terminales remotas (Telnet), compartir archivos (NFS), establecer un sitio de Web (HTTP), etc. Es importante, para un buen desempeño de un sitio, que se elija una máquina con los recursos necesarios, de acuerdo al uso que vaya a tener el servidor. Un servidor, típicamente estará ejecutando al menos un proceso por cada servicio que proporciona (los llamados demonios). En algunos casos, como en el de los servidores de web, estos demonios se replican por cada requisición que el servidor atiende, de manera que se pueden llegar a tener muchos procesos corriendo a la vez en una sola computadora. Actualmente se pueden conseguir en el mercado computadoras bastante potentes por un precio accesible. Por ejemplo, una configuración de servidor puede incluir 2 procesadores, arriba de 700 MHz, 1 Gbyte de Memoria y al menos 20 Gbytes de disco duro, si no es que con un arreglo RAID, que permita tener varios cientos de Gbytes en disco duro.

Geometría del disco duro

DescripciónEl Disco Duro es uno de los elementos denominados de 'almacenamiento masivo', su función es la de guar-dar el sistema operativo, los programas y los datos al apagar la computadora. La memoria RAM no conser-va los datos que tiene al desconectar la corriente eléctrica, aunque sea sólo por un momento, perdiéndose to-dos los datos. Al arrancar de nuevo la computadora, se producirá la carga en la memoria RAM del sistema operativo y demás programas residentes desde el disco duro.

Estructura físicaLa estructura física del disco duro se compone de dos partes principales:

- La parte mecánica, compuesta por un plato circular y de un motor que lo hace girar, además las cabezas de lectura/escritura.

- La parte electrónica, que se encarga de controlar el giro del motor y el movimiento de las cabezas.

El diseño lógico del disco duro se basa en los siguientes elementos mostrados en la figura 2.1.




Figura 2.1. Organización lógica del disco duro.

Cabeza H (head): las distintas cabezas de lectura/escritura que componen el disco y que se numeran empe-zando por el cero.Cilindro C (cylinder): la supercifie del disco se divide en una serie de 'anillos circulares concéntricos' con centro en el punto de giro del mismo. Cada cilindro se numera para su identificación empezando por el cero.Sector S (sector): cada cilindro se divide en 64 sectores empezando por el uno.

Partición del disco duro

Cuando adquirimos una computadora, ésta tiene instalado el sistema operativo Windows, que es el más comercial. Versiones comoWindows 95 o 98 no están diseñadas para desarrollar los trabajos típicos de un servidor, dado que son sistemas operativos inseguros, no robustos y que no cuentan con multiproceso real. Para proporcionar los servicios que requiere un sitio donde varias computadoras se encuentran conectadas en red, se requiere de un sistema operativo más versátil, como puede ser Windows NT, Linux, o Unix.

Para comenzar, supongamos que el disco duro de nuestra computadora está ocupado totalmente por Windows 95 o 98 y deseamos utilizarla como servidor. Dependiendo del uso que se le vaya a dar a la computadora, se puede optar por teneer dos (o más) sistemas operativos disponibles en ella. Esto no quiere decir que se ejecuten al mismo tiempo; al momento de iniciar la computadora, ésta nos pregunta que sistema deseamos usar. Si la computadora estuvierá todo el tiempo destinada a la tarea de servidor, es conveniente reservar todo el espacio para un solo sistema operativo. Sin embargo, en una computadora personal, quiza haya ocasiones en que deseemos trabajar en Windows y en otras en Unix. Es importante tener en mente que un servidor es usado por más de una persona a la vez, de manera que no es conveniente sacarlo de operación en ningún momento. De hecho existen servidores que solamente se apagan para darles mantenimiento, estando en operación 24 horas al día.



http://bibliotecainformatica.iespana.es/bibliotecainformatica/hardware/disco/fig1.htm


Si nuestra decisión fue la de tener dos sistemas operativos en la misma máquina, tendremos que particionar el disco duro. Esto es necesario, dado que cada sistema operativo guarda los datos en diferentes formatos y con diferente organización. Al particionar el disco duro, cada partición se formatea con las herramientas proporcionadas por el sistema operativo que residirá en ella y ahí se instala el sistema operativo.

Para particionar el disco duro, podemos hacer uso de programas como fdisk o partition magic. Estos programas nos permiten borrar, añadir o cambiar particiones. Para dar de alta una partición, debemos indicar el tipo de sistema operativo que residirá en ella y el tamaño de la partición. Si el sistema operativo a instalar es Windows 95 o 98 el tipo de partición es FAT, para Windows NT, NTFS (NT File System), para Linux, Linux Nativa y Swap, para Unix el tipo es SCO. Acerca del tamaño, es conveniente dejar al menos 2 Gbytes de disco para cada sistema operativo. Para particiones de tipo swap, al menos el doble que la memoria RAM que tiene la máquina. En el curso se indicará el uso de programas de partición, los cuales son muy simples.

En ocasiones nos encontramos con una máquina que ya contiene información en Windows y no deseamos eliminarla. Al reparticionar el disco y formatear las particiones se borrarían los datos actuales. En este caso podemos utilizar programas como fips, que son capaces de recortar una partición sin borrar su contenido. Antes de hacer esto, se recomienda compactar el disco duro y respaldar su información.

La información de la estructura lógica del disco se encuentra en el sector de arranque maestro: MBR “Mas-ter Boot Record” que se encuentra en el inicio del disco y que se compone de una tabla con cuatro entradas, una por cada partición, indicando la posición de cada partición en el disco según la nomenclatura: cabeza H, sector S y cilindro C. De la combinación HSC se identifica un punto concreto del disco.

Nota 1: Un error bastante frecuente, es la creencia de que un disco duro sólo puede tener hasta cuatro parti-ciones primarias como máximo. No existe ningún impedimento de tipo físico o lógico para tener las que de-seemos, simplemente se trata de una convención acordada por los fabricantes a fin de coincidir en una mis-ma estructura lógica y en la forma de “ver” el disco.

En la siguiente dirección encontrarán el programa de Mikhail Ranish denominado Partition Manager que puede realizar hasta treinta particiones primarias así como otro tipo de funciones distintas. http://www.ranish.com/part/

Ejemplo 1: Instalación de los sistemas operativos SCO, Linux y Windows conviviendo en el mismo disco duro.

Soluciones

1. Usar fdisk de Linux y crear las siguientes particiones

GNU HURD (tipo 63) partición primaria, hda1, 1 GB

HPFS NTFS (TIPO 7) partición primaria, hda2, 10 GB

Linux swap (tipo 82) partición primaria, hda3, doble de la memoria RAM

Linux Native (tipo 83) partición primaria, hda4, resto del disco duro

2. Usar fdisk de Linux y crear las siguientes particiones



http://www.ranish.com/part/

http://www.ranish.com/part/


GNU HURD (tipo 63) partición primaria, hda1, 1 GB

HPFS NTFS (TIPO 7) partición primaria, hda2, 10 GB

Linux swap (tipo 82) partición extendida, hda5 doble de la memoria RAM

Linux Native (tipo 83) partición extendida, hda6 resto del disco duro

Formateo e Instalación

En el caso de instalar Windows 95, se puede dar formato a la partición adecuada usando el programa format. Windows 98 y otros sistemas operativos, incluyen el formateo como una opción del procedimiento de instalación.

Para instalar el sistema operativo, la opción más simple es tener un CD de instalación que permita arrancar desde el inicio. Muy probablemente su computadora no esté configurada para iniciar desde un CD. Esta opción se puede configurar mediante el programa setup, el cual se puede ejecutar al reiniciar la computadora (típicamente mediante la tecla Supr o F2).

El proceso de instalación es generalmente muy simple, el sistema es capaz de reconocer la mayoría de los dispositivos y automáticamente los señala, preguntando solamente si está en lo correcto. Los dispositivos que eventualmente pueden ocasionar problemas son la tarjeta de video y la de red. Antes de comenzar con la instalación asegúrese de tener los drivers adecuados y anotar el nivel de interrupción y memoria base de cada tarjeta, para poderlas instalar con éxito.

Al terminar de instalar Unix, es necesario instalar utilerías adicionales, como editores de texto, shells de sistema operativo, servidores, etc. Parte de este software se encuentra en sitios de red o proporcionados en CDs adicionales proporcionados por el fabricante.

Ejemplo. Suponiendo el caso del ejemplo 1 y la solución 1, el orden de instalación de los sistemas operativos puede ser:SCOLinuxWindows

En este caso cuando se instala SCO se escribe el sector de arranque (MBR) del disco duro permitiendo iniciar SCO. Al instalar Linux se reescribe el MBR con un cargador (LILO o GRUB) que permite agregar la opción de escoger varios sistemas operativos al encender la computadora, esto se logra especificando la partición en que reside el sistema operativo. En el caso de lilo se especifica lo siguiente:

Note que se agrega la entrada incluso antes de instalar windows. El último paso sería instalar windows, lo que también reescribe el MBR, para solucionar el problema se arranca Linux con un floppy de rescate y se ejecuta el comando lilo para escribir el MBR correcto.


Para sco Para windows

other=/dev/hda1label=scotable=/dev/hda

other=/dev/hda2label=windowstable=/dev/hda



CONFIGURACIÓN DE LA CONEXIÓN A INTERNET EN EL SERVIDOR

Configuración de la red

El soporte de redes de área local (LANs, del Inglés Local Area Networks) está muy mejorado en las versiones mas recientes del sistema operativo UNIX en comparación con versiones más antiguas. Además del soporte de rutinas de bajo nivel en el núcleo, se dispone de software simple y amistoso para conectar los dos tipos de Redes principales disponibles en el mundo para UNIX: Ethernet e Internet.

Ethernet fue originalmente desarrollada para versiones BSD del sistema UNIX, y se ha convertido en un estándar en la industria para conexión de muchas clases de máquinas con sistemas operativos diferentes.

La Internet mundial, una red de área extensa (WAN, del inglés Wide Area Network) puede conectarse fácilmente a redes Ethernet. El soporte completo de Ethernet y sus servicios sólo apareció en la versión 4 del sistema V. Esto significa que SVR4 puede ahora participar completamente en redes de máquinas que utilizan protocolos de comunicación TCP/IP, tanto si todas las máquinas son sistemas V o no.

Estas redes son todas de relativa alta velocidad, al menos 10 MegaBits y ahora con más frecuencia de 100 MB por segundo. Esto permite el uso de herramientas de software que requieren respuesta rápida y rendimiento elevado, tal como la capacidad de montar sistemas de archivos en máquinas remotas de modo que aparezcan como si estuvieran en un disco local.

Los montajes remotos pueden ser valiosos puesto que permiten menos copias de un archivo o directorio que exista en una red de máquinas, simplificando el mantenimiento de los archivos y reduciendo la posibilidad de que algunas máquinas puedan tener copias no actualizadas.

Instalación y Configuración del TCP/IP

El protocolo TCP/IP es un mecanismo que permite que dos procesos, normalmente ejecutándose en máquinas distantes, se comuniquen entre sí.

Sobre el protocolo TCP/IP (Transport Control Protocol/Internet Protocol) se puede usar el sistema de archivos por red NFS. Además el TCP/IP hace posible que se puedan usar comandos para transferencia de archivos remotos o ejecución de comandos en otros servidores en una red. Varios de estos servicios serán estudiados en este curso.

Ejemplos de comandos remotos son: rlogin, rcp, rsh, rcmd, ruptime. Para poder usar estos comandos remotos son necesarias las siguientes acciones.

Configuración del TCP/IP

Para configurar TCP/IP se deben establecer conexiones físicas (medios físicos para comunicación: cables, conectores, hubs, etc.) configurar los drivers de las interfaces de red y configurar los parámetros de TCP/IP.

Normalmente cada versión de Unix proporciona herramientas para facilitar la configuración del TCP/IP, en el caso de UNIX SCO se proporciona una opción llamada Network Configuration Manager (comando en consola netconfig). En el caso de que se quiera hacer la configuración en forma manual, se deberán usar los comandos:




- ifconfig (interface configuration) para mostar, añadir o suprimir interfaces.- route para mostrar, añadir o suprimir rutas de acceso en su red.

Configuración del dispositivo de red.

Para poder tener comunicación en una red es necesario tener una conexión física con la red. Esta conexión puede ser de diferentes tipos, por ejemplo:Tarjeta de RedPuerto SerieModem

Cualquiera que sea el medio de comunicación, deberá tener una configuración de hardware adecuada y conocida por los niveles más bajos del sistema TCP/IP. A continuación se describen algunos puntos importantes en relación a la configuración de dispositivos de red. En particular se tratan el caso de la tarjeta de red.

TARJETA DE RED

Es necesario que la tarjeta de red tenga la configuración de hardware correcta. Esta configuración está determinada por pequeños puentes eléctricos denominados "jumpers". A través de los "jumpers" se determinan normalmente los siguientes parámetros para una tarjeta de red:Interrupt Request Channel IRQ I/O Base AddressRAM Buffer Base ArdesActualmente la mayoría de las tarjetas de red ya no incluyen jumpers sino que son programadas desde el driver o mediante una aplicación especial.

Es muy importante que al realizar la instalación se cuente con el driver de la tarjeta respectivo para SCO UNIX o asegurarse que la tarjeta en cuestión es soportada por el conjunto de drivers disponibles por SCO UNIX.

Ejemplo:Cuando la tarjeta no se encuentra en la lista de dispositivos de red soportados por SCO y se tiene el driver proporcionado por el fabricante de la tarjeta o se obtuvo éste desde Internet, se realiza el siguiente procedimiento para instalar la tarjeta.

El archivo objetivo debe tener el nombre VOL.000.000, este archivo normalmente viene en el disquette del fabricante o puede ser colocado en uno desde cualquier navegador Web.

Para copiar el archivo a SCO, es necesario montar el floppy mediante el comando

mount /dev/fd0 /mnt

Después se copia el archivo al árbol de directorios de Unix para después instalar el driver.

La instalación del driver se realiza utilizando el Sofware Manager (comando en consola custom).




Se instala el dispositivo de red mediante el Network Configuration Manager eligiendo la tarjeta cuyo driver se instalo en el paso anterior.

El siguiente paso consiste en agregar los protocolos, al menos se debe agregar el protocolo TCP/IP que se utiliza para navegar en Internet, transferir archivos etc.

Parámetros de configuración de TCP/IPExisten varios parámetros que deben configurarse en este protocolo, los más importantes son:

Local Host NameEl nombre que identificará a la computadora y que debe ser único en la red en que se encuentre conectada.

Domain nameEl nombre del dominio al cual pertenece la máquina. Los nombres de dominio pueden tener desde dos hasta un máximo de 26 letras.

El siguiente párrafo es una cita de las políticas de nombres de dominios del NIC de México:

La longitud total del dominio no deberá exceder los 26 caracteres.

Los caracteres válidos son números, letras del alfabeto inglés y el guión (-).

Los nombres de dominio no deberán comenzar o terminar con el guión (-) ni llevar dos guiones (--) seguidos.

NIC-México se reserva el derecho de rechazar cualquier nombre que considere sea ofensivo o afecte los derechos de alguna institución o persona.

Los subdominios bajo .mx están clasificados de la siguiente forma:

o .edu.mx Para instituciones de educación o investigación

o .org.mx Para asociaciones no lucrativas en México

o .net.mx Para proveedores de servicios de Internet localizados en México

o .gob.mx Para instituciones gubernamentales en México

o .com.mx Para entidades comerciales y aquellas que no se incluyan en las clasificaciones an-teriores.

Dirección IP y máscara de red.

Cada computadora conectada a una red necesita estar perfectamente identificado de forma que los paquetes que la tengan como destinatario sean capaces de localizarla de forma inequívoca. Esta es la misión del protocolo IP.

Actualmente las direcciones IP están compuestas por un número único de 32 bits que se asigna a cada nodo de la red, o más exactamente, a cada interfaz, normalmente la tarjeta de red. Este número suele representarse en notación decimal para cada byte (8 bits) con un rango de 0 a 255.Desde los comienzos de Internet se clasificaron, tal vez arbitrariamente, las redes en diferentes tipos según




el número de nodos que las componían, así tenemos por ejemplo:

Redes de clase A, identificadas con el primer byte de la dirección IP. Por lo tanto, pueden albergar, cada una, 16 millones de nodos, aproximadamente.

Redes de clase B, identificadas con los dos primeros bytes de la dirección IP. Constan de unos 65.000 nodos cada una.

Redes de clase C, identificadas con los tres primeros bytes de la dirección IP, reservando el último byte para identificar el nodo, pudiendo estar formadas por 254 equipos.

Los cuatro bytes de la dirección IP de cada computadora, identifican perfectamente al equipo y a la red de la que forma parte. Para separar estos dos identificadores se usa la máscara de red. La máscara de red tiene como misión "ocultar" los bytes correspondientes a la identificación de la red y dejar "visibles" los usados para identificar el nodo. La máscara se construye con 32 bits que pueden valer uno o cero, se hace la opera-ción lógica and entre los bits de la dirección IP y la máscara de red para obtener el identificador de host.

Si las máquinas de nuestra red deben conectarse a otras redes públicamente, hemos de disponer de nuestro propio número de red asignado por el organismo regulador de la direcciones públicas de Inter-net, el NIC (Network Information Center), mientras que si no se conectan directamente a otras redes, es decir, si no disponemos de una red con direcciones públicas, podemos asignar los números de cada nodo libremente, aunque lo más adecuado es utilizar un número de red reservado para este propósito. El rango reservado para cada tipo de red es:

Tipo de red Máscara de red Dirección desde Dirección hasta

A 255.0.0.0 0.0.0.0 127.255.255.255

B 255.255.0.0 128.0.0.0 191.255.255.255

C 255.255.255.0 192.0.0.0 223.255.255.255

Notas

La versión actual es IPv4 aunque se está preparando la IPv6 donde cada equipo tendrá un número de 128 bits, aumentando exponencialmente las posibilidades de expansión de la red Internet.

Dirección Broadcast

Esta dirección de difusión se usa para enviar paquetes de datos que todos los equipos de la red pueden reci-bir. Se forma con los bits de la identificación de host y colocando 1’s en el resto de bits.

Direcciones Internet

Internet, al ser una red virtual, esta implementada enteramente en software. Así los diseñadores son libres de seleccionar los formatos de paquetes, direcciones, técnicas de entrega, etc. TCP/IP tiene un esquema de direcciones análogo al direccionamiento de una red física, en la cual a cada host en internet se le asigna una dirección entera única llamada "dirección Internet" o dirección IP. Una dirección IP codifica tanto la identificación de de la red a la cual el host está conectado, como la identificación del host. A cada host en Internet TCP/IP se le asigna una dirección Internet única de 32 bits, que es usada en todas las comunicaciones con ese host.




Los detalles de las direcciones ayudan a clarificar estas ideas abstractas. Conceptualmente, cada dirección es un par (netid, hostid), donde netid identifica una red, y hostid identifica un host en esa red. En la práctica, cada dirección IP debe tener una de las tres primeras formas mostradas en la figura 3.2.

Figura 3.2. Las cinco formas de direccionamiento Internet

Dada una dirección IP, su clase está determinada por los primeros tres bits de mayor orden, siendo suficientes los dos primeros para distinguir entre las tres clases primarias. Las direcciones de la clase A son usadas para redes muy grandes (con más de 216 o 65536 hosts), 7 bits se dedican al netid y 24 al hostid. Las direcciones de la clase B son utilizadas para redes de tamaño intermedio (entre 256 y 65536 hosts), reservando 14 bits para el netid y 16 para el hostid. Finalmente, la clase C para redes menores de 256 hosts, reserva 21 bits para el netid y 8 para el hostid. Notése que la dirección IP ha sido definida de tal forma que es posible extraer fácilmente el netid o el hostid. Para las pasarelas, que usan el enrutamiento basado en el netid, esta eficiencia es importante.

Considerando que las direcciones IP codifican una red y un host en la red, no se especifica una máquina individual, sino una conexión a la red. Así las pasarelas que conectan n redes tienen n diferentes direcciones IP, una para cada red que interconecta.

Direcciones broadcast y de red

Enseguida se mencionan algunas capacidades adicionales de direccionamiento de las direcciones Internet.

1. Las direcciones IP pueden ser usadas para referirse tanto a redes como a hosts particulares. Por convención, las direcciones de red tienen un hostid con todos los bits en 0.

2. Las direcciones IP pueden ser usadas para referirse a todas los hosts ("broadcast"). Por convención, una dirección de broadcast tiene un hostid con todos los bits en 1. Esta forma de direccionamiento a todos los hosts de una red se llama dirección broadcast dirigida.

3. Otra forma de direcciones broadcast es llamada direccionamiento broadcast local, el cual proporciona una dirección de broadcast para la red local, independientemente de su dirección IP. En este caso, la dirección consiste de treinta y dos 1s.




4. En general, el software de Internet interpreta los campos que contienen 0s como "Este". Así, un

hostid 0 se refiere a "este" host y un netid 0 se refiere a "esta" red. Por supuesto, este direccionamiento es significativo en el contexto en el que pueda interpretarse sin ambiguedad. Por ejemplo, se puede usar un netid de 0 en aquellos casos en que el host desea comunicarse sobre la red, pero todavía no sabe la dirección IP de la red (su netid).

5. Finalmente, se soporta el direccionamiento "multicast".

Desventajas del direccionamiento Internet

La más obvia desventaja es que el direccionamiento se refiere a conexiones, no a hosts. Esto es, si un host se cambia de una red a otra, su dirección IP debe cambiarse. Considérese el caso de computadoras personales portátiles que durante un viaje cambian de una red a otra; no pueden tener direcciones IP permanentes.Otra desventaja es que si una red de tipo C crece a más de 255 hosts, se debe cambiar la dirección a una de clase B. Cambiar las direcciones IP en el software de aplicación puede implicar una gran cantidad de tiempo.

Notación decimal punteada

Con el fin de que las direcciones IP sean legibles por personas, éstas se escriben como cuatro enteros decimales separados por punto, donde cada entero representa un byte. La dirección en formato de 32 bits siguiente:

10000000 00001010 00000010 00011110

Es escrita como

128.10.2.30

Mapeo de direcciones Internet a direcciones físicas

Considerando que dos máquinas pueden comunicarse solo si conocen mutuamente sus direcciones físicas de red, falta mencionar como un host o una pasarela obtienen la dirección física correcta del host destino. Recuérdese que en Ethernet la dirección física depende del hardware de interfase de red (usualmente una tarjeta) y si se cambia, también se cambia la dirección física. Este problema es conocido como el "problema de resolución de dirección".

Los diseñadores de TCP/IP encontraron una solución creativa a este problema, aprovechando la capacidad de broadcast de las redes. La solución permite que nuevas máquinas se agreguen a la red sin recompilación de código, ni mantenimiento de una base de datos centralizada. Los diseñadores escogieron un protocolo de bajo nivel llamado " Protocolo de Resolución de Direcciones (ARP, "Address Resolution Protocol") para enlazar las direcciones dinámicamente.

Como se muestra en la figura 3.3 (a), cuando el host A desea resolver la dirección Internet Ib manda un

paquete broadcast especial pidiendo al Host con esa dirección IP que responda con su dirección física. Todos los Hosts, incluyendo B, reciben la petición, pero solamente el host B reconoce su dirección IP y envia una respuesta que contiene su dirección física (figura 3.3 (b)). Cuando A recibe la respuesta, usa la dirección física para enviar el paquete Internet directamente a B.




Figura 3.3. El protocolo ARP

Modelo de interacción cliente-servidor

El patrón principal de interacción entre aplicaciones cooperativas es conocido como el paradigma cliente-servidor, el cual forma las bases de las comunicaciones por red.

El término servidor se aplica a cualquier programa que ofrece un servicio que puede ser accesado a través de la red. Los servidores aceptan solicitudes que llegan a través de la red, ejecutan su servicio, y regresan el resultado al solicitante. Para los servicios más sencillos, cada solicitud llega como un datagrama IP y el servidor también responde con un datagrama.

Un programa en ejecución llega a ser un cliente cuando envia una petición al servidor y espera la respuesta. Como el modelo cliente-servidor es extensión natural y conveniente de la comunicación entre procesos de una misma máquina, es fácil construir programas que lo usen para interactuar.

Los servidores pueden ejecutar tareas simples o complejas. Por ejemplo un servidor del tiempo-del-día regresa el tiempo actual cuando un cliente le envía un paquete. Un servidor de archivos recibe peticiones para ejecutar operaciones de guardar o recuperar información de un archivo; el servidor ejecuta la operación y regresa el resultado.

Ejemplos

El ejemplo más común de aplicaciones cliente-servidor son los sitios WEB tan populares en Internet. La computadora servidor es la que se encarga de proporcionar el servicio de páginas html, para ello ejecuta una aplicación o demonio (Por ejemplo Apache Web Server) que esta a la escucha de solicitudes de los clientes que normalmente son aplicaciones cliente corriendo en máquinas remotas (por ejemplo Internet explorer, Netscape, etc.).




Nota: En la comunicación cliente servidor no necesariamente se involucra una computadora remota, sino que ambas aplicaciones pueden estar corriendo en una misma computadora, es decir, si una computadora proporciona servicio de Web la misma computadora puede usar un cliente navegador para hacer las peticiones como cliente.

Otros ejemplos de aplicaciones son telnet, ftp, nfs, etc.

Uso de ifconfig (/etc/ifcofig) para inspeccionar una interfaz de red

Al ejecutar ifconfig con sólo un nombre de interfaz en la línea de comandos se imprime el estado de la interfaz. Al ejecutar ifconfig con el argumento -a se provoca la salida del estado de todas las interfaces de la red que conoce el kernel. El siguiente listado muestra el resultado de ifconfig:

$ ifconfig lo0

lo0: flags=4049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232inet 127.0.0.1 netmask ff000000perf. Params: recv size: 57344; send size: 57344; full-size frames: 1

Este ejemplo usa lo0, la interfaz de bucle interno de software. El usuario puede ver la dirección IP asignada "inet", máscara de red "netmask". La interfaz está activa (UP) con una unidad máxima de transferencia (MTU) de 8232. Las dos últimas líneas dan estadísticas sobre el número de paquetes recibidos y transmitidos. Configuración de la interfaz de bucle interno de software

Todos los sistemas Linux que tengan un nivel de conexión en red instalado en el kernel tienen una interfaz de bucle interno de software. Esta interfaz se usa para comprobar las aplicaciones de conexión en red y para suministrar una red para servicios TCP/IP locales cuando el sistema no está conectado a la red real. El nombre de la interfaz de red del sistema de bucle interno es “lo0”.

Si se quisiera configura la interfaz podría hacerse con lo siguiente:

$ ifconfig lo0 127.0.0.1

Esta instrucción activa la interfaz de bucle interno y le asigna la dirección 127.0.0.1, que es la dirección que se usa tradicionalmente para el bucle interno porque la red de Clase A, 127.0.0.0, nunca será asignada a nadie por el NIC. Esta acción normalmente se ejecuta en los scripts de inicialización de manera automática por el sistema (aún cuando no existan interfaces de red ethernet).

Para que el sistema de bucle interno sea totalmente operacional, el usuario ha de añadirle una ruta con el comando route, que se describe más adelante.

Configuración de una interfaz de red

La configuración de una interfaz de red Ethernet requiere un poco más de trabajo, especialmente si usa subredes. La llamada básica a ifconfig es la siguiente (supongamos que se trabaja en la máquina 192.168.1.3):




$ifconfig net0 192.168.1.3

Esto provoca que ifconfig active la interfaz Ethernet 0 y le asigne la dirección IP indicada. Al examinar la interfaz net0 en este punto se ve el siguiente código:

$ifconfig net0 net0: flags=4043<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500

inet 192.168.1.10 netmask ffffff00 broadcast 198.168.1.255perf. Params: recv size: 24576; send size: 24576; full-size frames: 1ether 00:50:df:16:1c:c4

Observe que ifconfig ajustó automáticamente la dirección de difusión y la máscara de red basándose en la dirección IP proporcionada. Si el usuario usa subredes, debe indicar explícitamente la dirección de difusión y la máscara de red. Por ejemplo, si tiene una red de clase C y usa el primer bit en la parte del sistema de la dirección para hacer dos subredes, debe indicar la dirección de emisión y la máscara de red cuando ejecute ifconfig.

$ifconfig net0 192.168.1.3 broadcast 166.82.1.127 netmask 255.255.255.128 Ruteado de TCP/IP El ruteado determina la ruta de acceso que toma cualquier paquete desde su fuente, a través de la red, hasta su destino. Esta ruta se determina comparando la dirección IP de destino con las tablas de ruteo del kernel y transmitiendo el paquete al sistema indicado, que puede o no ser el destino del paquete. La tabla de ruteo del kernel contiene información del tipo "Para ir a la red X desde el sistema Y, mande el paquete al sistema Z con un coste de 1", juntamente con los valores de tiempo de expiración y fiabilidad de esta ruta.

Política de ruteado El primer paso para instalar un ruteado en su red es decidir una política de ruteado. En el caso de redes pequeñas y no conectadas, es suficiente usar el comando route para instalar rutas estáticas en cada sistema en el momento del arranque. Las grandes redes con numerosas subredes o redes conectadas a Internet requieren el uso de un ruteado dinámico. El programa de ruteado suministra un ruteado dinámico al comunicarse con programas de ruteado de otros sistemas e instalar rutas basadas en lo que aprende sobre la topología de la red.

Una estrategia muy común combina ruteado estático y dinámico. Los sistemas de cada subred usan ruteado estático para alcanzar a sus vecinos inmediatos. La ruta predeterminada, la usada por los paquetes que no concuerdan con ninguna otra ruta de la tabla de ruteado, está definida en un sistema pasarela que realiza ruteado dinámico y que tiene información sobre el resto del mundo. De esta forma se pueden construir grandes redes, minimizando la complejidad de los archivos de configuración y el ancho de banda usado por los programas de ruteado dinámicos.

Uso del programa route (/etc/route)




El programa route manipula la tabla de ruteado del kernel y se usa para definir rutas estáticas a otras computadoras o redes a través de interfaces que han sido configuradas y activadas por ifconfig. Esto se realiza normalmente en el momento del arranque con el script /etc/rc2.d/S90iproute con el cual se pueden agregar rutas de manera automática.

Enseguida se describen los argumentos de la línea de comandos de route.

Argumentos

Descripción

flush Elimina todas las entradas gateway de la tabla de ruteodelete Este comando suprime la ruta de la dirección de destino

indicada, de la tabla de ruteado.add agrega a la tabla de ruteado una ruta a la dirección o red

indicadas.

Examen de la tabla de ruteado del kernel.

Ejecutar netstat -r provoca que se muestre la tabla de ruteado actual, como se indica a continuación:

$ netstat –rRouting tablesDestination Gateway Flags Refs Use Interfacelocalhost localhost UH 3 56 lo0224 sam UCS 0 0 net0

Esta tabla corresponde a un sistema con sólo la interfaz de bucle interno activada y la ruta para multicast (224 = BASE-ADDRESS.MCA). A continuación se muestra el significado de los campos de la salida anterior.

Campo DescripciónDestination El destino del paquete de la ruta mostradaGateway El nombre del sistema o la dirección IP de la pasarela que usa la

ruta.Flags Los indicadores de la ruta (U=arriba, H=host, G=pasarela,

S=ruta estática, M=modificada)Ref El número de otras rutas que dependen de la presencia de esta

rutaUse El número de veces que se ha usado la entrada de la tabla de

ruteadoInterface La interfaz de red a la que la ruta suministra paquetes

# netstat -rRouting tablesDestination Gateway Flags Refs Use Interfacedefault 192.168.1.254 UGS 0 45 net0localhost localhost UH 1 2 lo0192.168.1 sam UCS 0 0 net0




BASE-ADDRESS.MCA sam UCS 0 0 net0

La entrada a la tabla del bucle interno es la misma que antes y presenta dos nuevas entradas. La primera indica la pasarela por default y la tercera una ruta a la subred de la que es miembro el host.

Agregagando rutas estáticas

El usuario agrega rutas a la tabla ejecutando el programa de ruteado con el argumento add. La sintaxis de los argumentos de la línea de comandos es

$route add [-interface] [-netmask new_mask] [ -host | - net ] destination gateway

Enseguida se describen los argumentos de la línea de comandos que usa el comando route add.

Argumento Descripción-interface La ruta usa un interfaz en lugar de un gateway, el gateway

especificado (ultimo parámetro) es la dirección de este host en la red, indicando que la interfaz es utilizada para transmisión.

netmask Indica la máscara de red de la ruta que se agrega. El programa de ruteado supondrá lo que en circunstancias normales no se indique

- hots | - net Forza que el destino sea interpretado como un host o como reddestination La dirección destino de la nueva ruta. Esta puede ser una

dirección IP, un nombre de sistema o de red. Se puede usar default cuando el destino no se encuentre en las subredes a las que el host tiene conexión física, el parámetro gateway debe especificar la puerta de enlace.

gateway Indica que cualquier paquete para esta dirección sea ruteado a través de la pasarela indicada

Cuando agregue una ruta de pasarela a la tabla de ruteado, asegúrese de que la pasarela indicada es accesible. Normalmente tendrá que agregar una ruta estática para la pasarela antes de añadir la ruta que usa ésta.

A continuación se muestran algunos ejemplos, comenzando con la interfaz de bucle interno. Después de configurarlo con ifconfig, se le debe agregar una ruta como se muestra a continuación:

$route add 127.0.0.1

No se necesita más porque route compara la dirección recibida con las direcciones de las interfaces conocidas y asigna la interfaz de bucle interno a la nueva ruta (Esto normalmente lo hace el sistema de manera automática).

El siguiente ejemplo muestra cómo definir la ruta para la pasarela:

#route add default 192.168.1.254




Supresión de rutas con el comando route

Se suprimen rutas llamando a route con la opción del, indicando la dirección destino de la ruta que quiere borrar. Por ejemplo,

$ route delete –interface –net 192.168.1 192.168.1.97

suprime la ruta de la red 192.168.1.0

Información de la Red (ping, finger)

Para verificar que el hardware de red (tarjeta de red o puerto serie) este configurado correctamente, y las direcciones de las diferentes máquinas estén correctas, podemos usar el comando ping. Este comando envía paquetes a otras máquinas (concentradores, pasarelas, etc.) pidiendo una respuesta. La sintaxis es:

ping 148.216.5.1.29

ó bien utilizando los nombres de un host de la siguiente forma:

ping maquina.dominio

Si se recibe respuesta, significa que el protocolo de comunicación y por consecuencia el hardware de la trayectoria está funcionando correctamente. Al ejecutar el comando ping sobre la máquina local, se verifica si el dispositivo de la red local está bien configurado y trabajando adecuadamente. Si se usa un dirección mnemónica en lugar de numérica se debe tener configurado el cliente DNS.

La orden finger informa sobre cada usuario, que puerto de terminal está utilizando cada uno y cuándo se ha presentado en la máquina. Si se específica un id de presentación (o una lista de ids de presentación) como argumento de finger, se proporciona un informe más explicativo para esos usuarios. Para obtener información sobre usuarios en máquinas remotas se pueden utilizar estos formatos:

$ finger usuario@máquina$ finger @máquina

Configuración del cliente DNS.

Para que la computadora pueda utilizar direcciones mnemónicas (p.e. www.google.com) requiere que en algun lugar se haga la traducción de las mismas a direcciones numéricas (p.e. 216.239.51.100), esto se puede realizar configurando el cliente en el archivo /etc/resolv.conf para que contenga al menos una dirección de otra computadora que proporcione el servcio de DNS.



http://www.google.com/


El contenido del archivo /etc/resolv.conf puede ser:

nameserver 148.216.1.2nameserver 148.216.1.21




ADMINISTRACIÓN

Creación de cuentas de usuarios

Unix es un sistema opertivo con muchas características y una de estas es el estar diseñado para ser utilizado por múltiples usuarios. Aún cuando se tenga una PC con un único usuario, es importante recordar que no es conveniente realizar el trabajo diario desde la cuenta de root, misma que solo debe utilizarse para la administración del sistema.

Una cuenta de usuario contiene las restricciones necesarias para impedir que se ejecuten comandos que puedan dañar el sistema, se alteren accidentalmente la configuración del sistema, los servicos que trabajan en el trasfondo, los permisos y ubicación de los archivos y directorios de sistema, etc.

Creando una cuenta en el modo de texto: useradd y passwd

Este procedimiento puede realizarse de forma segura tanto fuera de XWindow como desde una ventana ter-minal en el entorno gráfico del que se disponga. Fue el método comúnmente utilizado antes de la aparición del Account Manager.

Lo primero: el comando useradd.

El primer paso para crear una nueva cuenta consiste en utilizar el comando useradd del siguiente modo:

# useradd [options] nombre_del_usuario

Ejemplo:# useradd –d /usr/Joel -m Joel

Lo segundo: el comando passwd.

Después de crear la nueva cuenta con useradd lo que sigue a continuación es específicar una contraseña para el usuario. Determine una que le resulte fácil de recordar, que mezcle números, mayúsculas y minúscu-las y que, preferentemente, no contenga palabras que se encontrarían fácilmente en el diccionario.

Aunque el sistema siempre tratará de prevenirlo cuando se escoja una mala contraseña, el sistema no le im-pedirá que lo haga. Específicar una nueva contraseña para un usuario, o bien cambiar la existente, se puede realizar utilizando el comando passwd del siguiente modo:

# passwd nombre_del_usuario

Ejemplo:# passwd Joel

Eliminar una cuenta de usuario.

En ocasiones un administrador necesitará eliminar una o más cuentas de usuario. Este es un procedimiento principalmente utilizado en servidores y estaciones de trabajo a los cuales acceden múltiples usuarios. Para tal fin nos valdremos del comando userdel

El comando userdel.

La síntaxis básica de este comando es la siguiente:




# userdel nombre_del_usuario

Ejemplo:

# userdel Joel

Otra forma de administrar cuentas de usuarios es utilizar el Account Manager.

El proceso en Unix. (comandos &, ps, kill y top)

Los aspectos multitarea del sistema Unix se agrupan generalmente bajo el tema del proceso. Un proceso, o tarea, es una instancia de un programa en ejecución. El shell de presentación es un proceso mientras el usuario abre una sesión, porque siempre está presente hasta que el usuario se despide. Si usted ejecuta una orden desde el prompt $, esa orden es un proceso mientras se está ejecutando. Los procesos tienen muchas propiedades y hay muchas órdenes para manipular los procesos y sus propiedades. En esta sección discutiremos cuestiones asociadas con la multitarea y consideraremos cómo se puede controlar el entorno de ejecución para que el usuario lo aproveche.

Antes de continuar examinaremos unos pocos ejemplos. La orden:

$ cat /etc/passwd

genera un proceso que subsiste hasta que la operación cat se completa. Si se crea una línea de cauce shell utilizando el operador |, cada uno de los componentes se convierte en un proceso separado. La línea de orden

$ cat /etc/passwd | wc

Genera dos procesos, uno por cada orden.

Procesos subordinados

El shell dispone del operador & (ampersand) para permitir la ejecución de órdenes en modo subordinado. Para utilizar el & se añade al final de una línea de orden, como se muestra a continucación:

$ cat /etc/passwd &

En este ejemplo la orden cat se ejecuta en modo subordinado, pero su salida sigue apareciendo en el terminal, ya que no ha sido redirigida. Cuando se ejecuta una orden utilizando &, el shell vuelve inmediatamente para solicitar la introducción de otra orden, aun cuando el proceso que acaba de ser creado sigue ejecutándose en el sistema. El shell devuelve un número de proceso o pid (por identificador de proceso), de modo que el usuario puede referirse al trabajo subordinado, y luego devuelve el indicador para pedir otra orden, como se muestra aquí:

$ cat /etc/passwd & 1536$




Generalmente la entrada y salida de las órdenes que se ejecutan en modo subordinado son redirigidas para que la sesión del terminal no se vea interrumpida por su salida:

$ cat /etc/passwd > fich.copia & 1540 $

Se puede redirigir la salida de error estándar también, de no hacerlo aparecerá en el terminal aún cuando se haya redirigido la salida estándar. Esta orden redirige tanto la salida como el error estándar: $ cat /etc/passwd > fich.copia 2>error.sal & 1544 $

por otro lado se puede desear que el error estándar aparezca en el terminal, para disponer de notifícación inmediata de los errores producidos en los procesos subordinados.

El sistema UNIX permite crear tantos trabajos subordinados como se desee, aunque el rendimiento del sistema sufre notablemente si se crean demasiados. Cuando se completa un proceso subordinado, el sistema no muestra ninguna notificación. El usuario puede vigilar el estado de los procesos subordinados con la orden ps. Si se ha redirigido la salida a un archivo, se puede examinar la salida a conveniencia.

Despedida mientras se ejecutan procesos subordinados

Si usted ha creado procesos subordinados durante una sesión, éstos serán eliminados cuando usted se despida, puesto que están asociados con el shell de presentación. El sistema UNIX proporciona una herramienta que permite que los procesos subordinados continúen ejecutándose después de la despedida. Esta es la orden nohup, que puede ser muy útil para trabajos largos que pudieran ejecutarse durante toda la noche (o toda la semana). Utilice nohup del mismo modo que utiliza nice; colóquelo al comienzo de la línea de orden, como se muestra aquí:

$ nohup cat /etc/passwd &

Este ejemplo le dice a la orden cat que ignore la despedida del usuario del sistema y continúe ejecutándose hasta su terminación. Generalmente, nohup se utiliza con órdenes subordinadas, puesto que el usuario no puede despedirse si no tiene un prompt.

Cuando se utilice nohup con una línea de cauce, se debe iniciar cada elemento de la línea de cauce con la orden nohup, como se muestra aquí:

$ nohup cat /etc/passwd | nohup wc > fich.sal &

Si no se hace así, los miembros de la línea de cauce que no lleven la orden nohup serán eliminados durante la despedida y la línea de cauce global se colapsará.

Si no se redirige la salida, nohup crea un archivo de salida por sí mismo, ya que si el usuario se despide de la máquina no habrá terminal al que dirigir la salida. Por ejemplo:




$ nohup cat /etc/passwd & 1565 Sending output to nohup.out

Aquí se obtiene el número de identificación del shell ya que se utilizó el operador &, y el mensaje «Sending output...» (Envío de la salida a nohup.out) procede de nohup como si creara un archivo de salida. El fíchero nohup.out en el directorio actual contendrá los resultados de la orden ejecutada bajo control de nohup. Tenga cuidado de manejar la salida de error estándar separadamente si no desea que aparezca en el archivo nohup.out.

La orden ps

Como se mencionó anteriormente, se pueden examinar los procesos que están actualmente vivos en la máquina con la orden ps (del Inglés process status - estado de los procesos). Esta orden muestra información acerca de los procesos que están vivos cuando se ejecuta la orden. Si se ejecuta la orden más de una vez, la salida es probable que sea diferente cada vez; es decir, ps produce una «instantánea» de la actividad de la máquina.

Si se ejecuta la orden ps sin argumentos, ésta muestra información acerca de los procesos asociados con la sesión de presentación. por ejemplo:

# ps PID TTY TIME CMD 807 ttyp1 00:02:00 ps 728 ttyp1 00:01:00 sh#

Esta salida revela que hay dos procesos en ejecución: uno para el shell, que nace cuando se hace la presentación ante el sistema, y muere con la despedida, y otro para la ejecución de la orden ps. Cada proceso listado tiene un tiempo de ejecución asociado a él - dos segundos para la orden ps en este ejemplo. Este no es tiempo transcurrido o de «reloj», sino la cantidad total de tiempo de CPU que el proceso ha utilizado desde que comenzó. Un proceso también puede tener un terminal asociado, del que lee y al que escribe, listado en una columna de la salida. Un proceso que está asociado con el shell de presentación está generalmente, pero no siempre, conectado al terminal de presentación. Algunos procesos no están asociados a ninguna terminal, en cuyo caso la columna TTY contiene un signo ? (interrogación). Finalmente, cada proceso tiene un pid único que lo identifica dentro del sistema. Los pids comienzan en 0 cuando el sistema se arranca, y cada nuevo proceso obtiene el siguiente número hasta que se alcanza el máximo, generalmente 32767. En este ejemplo el proceso ps fue el proceso 807. Cuando se alcanza el número máximo, la cuenta comienza de nuevo desde 0; sin embargo, un pid asignado a un proceso que sigue estando vivo no será reasignado a un nuevo proceso. Los hijos generalmente tienen un pid mayor que el de los padres, pero si el pid del padre está cerca del máximo, un hijo puede haberse reciclado a un número más bajo.

Realmente hay mucha más información asociada con cada proceso, y parte de esta información está disponible con la opción -f (full o completa) de ps, como se muestra aquí:

$ ps -fUID PID PPID C STIME TTY TIME CMDsteve 756 572 6 13:04:57 ttyp1 00:01:00 sh




steve 761 756 23 13:05:19 ttyp1 00:01:00 ps -f

El nombre de la orden, el tiempo de ejecución, el tty y el pid son visualizados en esta salida, y también hay disponible alguna información adicional. A la izquierda está el id del usuario, que revela el propietario del proceso, ya que cada proceso es propiedad del id de presentación que lo creó. La columna PPID lista el pid del padre de cada proceso. Puesto que el sistema creó el shell para el usuario cuando éste se presentó ante la máquina, su pid padre será un número muy bajo, el pid asociado con parte del núcleo. El padre de la mayoria de los procesos creados por el sistema es generalmente el pid 1 cuando se observan los procesos en las terminales modo texto. Cuando el usuario ejecutó la orden ps, el shell creó ese proceso, de modo que el pid padre del proceso ps es el pid del shell. Se puede trazar cadenas de padres e hijos examinando sus pid y ppid.

La siguiente columna de la salida, C, lista la cantidad de recursos de Procesador que el proceso ha utilizado recientemente. El núcleo utiliza esta información para decidir cuál de los varios procesos obtiene acceso la próxima vez al CPU. El núcleo permitirá a un proceso con un valor de C bajo que tome control del CPU antes que uno que tenga un valor más alto. La orden nice funciona modificando el algoritmo interno por el cual se calcula este número. Generalmente, esta columna no es muy útil excepto para los programadores que trabajan sobre mejoras del núcleo y sobre rutinas de entrada y salida.

Finalmente, STIME indica la hora del día en que se inició el proceso. Se puede utilizar esta información para rastrear procesos antiguos o desviados que hayan permanecido incorrectamente en el sistema durante largo tiempo.

Lista de la actividad de otros usuarios

La orden ps también puede proporcionar información acerca de lo que los otros usuarios están haciendo en la máquina en cualquier instante. Si usted sabe que un usuario específico está presente en el sistema, puede visualizar el estado de los procesos de ese usuario con

$ ps -u usuario

donde usuario es el id que representa al individuo en quien usted está interesado. En un sistema pequeño es más fácil listar la actividad de todos los usuarios de una vez. Para hacer esto, utilice la opción -af (por todos [all]) del modo siguiente:

$ ps -afUID PID PPID C STIME TTY TIME CMDroot 82 1 0 Apr 9 tty02 00:00:05 -shsteve 756 1 3 13:04:57 ttyp1 00:00:01 -shsteve 762 756 1 13:05:28 tty03 00:00:00 ps -af

Aquí hay varias cuestiones de interés. Primero, observe que hay otro usuario actualmente presente en la máquina. Su id de presentación, root, está reservado a un administrador del sistema y sólo puede iniciarse sesión desde la consola del sistema principal, como indica la columna TTY. Aparentemente el usuario root se presentó inmediatamente después de que la máquina fuese arrancada, puesto que tiene un pid relativamente bajo asociado con esa presentación. Si examina la columna STIME, puede ver algo más: el tiempo de inicio de un proceso está expresado en formato hh:mm:ss para las horas de hoy. Sin embargo,




para procesos que fueron iniciados en días anteriores, sólo se da el mes y el día. Este formato se emplea únicamente para reducir el tamaño de la salida; el sistema UNIX guarda todos los tiempos exactamente.

Procesos del sistema

Hemos examinado los procesos asociados con cada usuario, pero también existen procesos de larga duración que soportan las actividades del sistema y otros procesos transitorios que nacen y mueren cuando el sistema efectúa tareas propias independientemente de los usuarios individuales. La opción -e (por todos [every]) de ps muestra información acerca de todos los procesos activos en la máquina. La salida de ps -e es muy útil para examinar lo que la máquina está haciendo «a sus espaldas», y es vital para diagnosticar problemas. La salida exacta depende del software que haya instalado en la máquina y de qué dispositivos de E/S hardware estén conectados al sistema. Además, diferentes versiones del sistema UNIX organizan los procesos del sistema de forma muy diferente. Cuando usted pase a una nueva versión en una nueva máquina, trate de entender qué procesos son normales, para que pueda identificar problemas o errores en la salida de ps cuando las cosas vayan mal. pruebe las órdenes ps frecuentemente en su propio sistema, para tener idea de lo que es normal.

Si usted ejecuta la orden

$ ps -ef

sobre un sistema SVR4 basado en el Intel 80 x 86, esta salida podría ser típica:

$ ps -ef UID PID PPID C STIME TTY TIME CMD root 0 0 0 Mar 31 ? 0:00 sched root 1 0 0 Mar 31 ? 0:01 /sbin/init root 2 0 0 Mar 31 ? 0:00 pageout root 3 0 0 Mar 31 ? 0:00 fsflush root 4 0 0 Mar 31 ? 0:00 kmdaemon root 173 1 0 Mar 31 ? 0:00 /usr/lib/saf/sac -t 300root 245 173 0 Mar 31 ? 0:03 /usr/lib/saf/ttymon root 174 1 2 09:16:14 console 0:01 -sh root 184 174 8 09:16:48 console 0:00 ps -ef root 163 1 0 09:16:10 ? 0:00 /usr/sbin/cron

Esta salida corresponde a un sistema «básico» configurado sin muchos paquetes software adicionales.

El primer proceso ejecutado cuando se arranca la máquina es el scheduler (planificador). Esta es la clave para las características de tiempo compartido del sistema UNIX, y es responsable de la determinación de qué procesos entre los que están listos para ejecutarse obtendrán realmente acceso a los recursos de la máquina. Este proceso se denomina sched y tiene asignado el pid 0. A su vez, sched arranca init (por inicialización), el cual mantiene en ejecución los procesos permanentes del sistema. El proceso init tiene asignado el pid 1. A continuación viene pageout, que gestiona la memoria virtual de la máquina e intercambia parte de los procesos activos entre el disco y la memoria real cuando son ejecutados o apartados temporalmente. El proceso pageout es responsable de la mayor parte del trabajo administrativo que el sistema hace para gestionar los procesos en el entorno multitarea. El proceso kmdaemon (por demonio de memoria del núcleo - kernel memory demon) maneja la misma tarea para las partes del propio sistema




operativo. Los procesos sched, kmdaemon y pageout trabajan en estrecha compenetración y componen la parte medular del núcleo. El proceso pageout obtiene el pid 2 y kmdaemon el pid 4.

A continuación está fsflush (por vaciado del sistema de archivos - file system flush), que gestiona la E/S de disco en el sistema. Puesto que el sistema contiene muchos buffers de datos internos que actúan de modo semejante a un disco RAM en otros sistemas operativos, existe la posibilidad de que los datos de los buffers no coincidan con los del disco si el sistema falla inesperadamente o se cae. Para evitar esto, fsflush escribe periódicamente todos los buffers al disco provocando una operación sync. Con cuánta frecuencia esto se produzca es un parámetro dependiente del sistema, pero en máquinas pequeñas suele producirse una vez cada veinte segundos. Sólo lo que ha sido modificado se escribe al disco cada vez. El proceso fsflush tiene el pid 3.

Excepto por init, estos procesos del sistema están almacenados en disco dentro del archivo /stand/unix, que representa al núcleo. No hay archivo de disco que contenga los procesos ejecutables sched, pageout, fsflush, o kmdaemon. Estos procesos son creados cuando el sistema es arrancado, y permanecen vivos hasta que el sistema es desconectado. Por esta razón, la columna TIME de la salida ps -ef puede mostrar una gran cantidad de tiempo de CPU aparente asignado a estos procesos. Estas cifras no son siempre precisas, ya que algunas implementaciones asignan arbitrariamente todo el tiempo de CPU inactivo a sched o a otro de los procesos del núcleo. Esta no es generalmente causa de preocupación; si estos procesos del nucleo no estuvieran funcionando, el sistema probablemente ni siquiera estaría lo suficientemente sano para ejecutar ps.

Todo el resto de los procesos del sistema pueden trazar su paternidad hasta init, ya que init es el responsable del mantenimiento de los procesos del sistema según los contenidos del archivo /etc/inittab. El controlador de terminal y otros procesos se derivan de init. Mientras los procesos crecen y nacen, la cuenta de pid sigue creciendo, pero todos los procesos que no tienen padre vivo son últimamente heredados por init. Observe que el ppid de muchos procesos en el sistema es 1.

El resto de los procesos que aparecen en la salida de ps -ef pertenecen o bien a los usuarios o a aplicaciones especiales que éste está ejecutando. Por ejemplo, si se hace que el subsistema de impresión lp se esté ejecutando en el sistema, habrá una línea en la salida de ps -ef para su demonio. Un demonio es un proceso del sistema que actúa sin que un usuario lo solicite. Este puede ser o bien un proceso permanente del sistema como fsflush; un proceso de aplicación que está siempre ejecutándose, como Ipsched (y lpNet) para el subsistema lp; o un proceso que se ejecuta bajo control de los subsistemas de temporización, como uuxqt. Generalmente estos procesos planificados no viven durante mucho tiempo, pero se podría ver algunos de ellos cuando se ejecute ps, y naturalmente incrementan la cuenta de pid.

Si usted está utilizando el sistema de ventanas XWindows y el paquete de conexión en red Ethernet (TCP/IP), también tendrá presentes otros varios demonios. El proceso inetd es el proceso de atención básica para la actividad de la red, y repcbind atiende a las peticiones de llamadas a procedimierttos remotos. Los procesos rpc.walld, rpc.rusersd y rpc.sprayd soportan varias funciones a nivel de usuario en el sistema de red. Si usted está haciendo operar la máquina como servidora en un LAN tendrá presentes incluso más demonios de red.

Hay muchas más opciones para la orden ps, pero éstas son principalmente para uso de los diseñadores del sistema y creadores de aplicaciones.




Monitoreo de la actividad del usuario

Unix ofrece el comando top para monitorear continuamente el estado de todos los procesos del sistema.

Diagnóstico de problemas con procesos

Una aplicación que no esté actuando correctamente del modo que fue diseñada mostrará generalmente uno de los siguientes modos de fallo:

1. Su proceso morirá prematuramente. Si la aplicación es una orden, el sistema generalmente regresará al shell inesperadamente. Si es un demonio, init puede tratar repetidamente de generar la aplicación. En el primer caso no se encontrará ningún proceso asociado con la aplicación en la salida de ps y la aplicación parecerá ejecutarse mucho más rápidamente de lo que es normal. En el último caso, el sistema se hará sustancialmente más lento y tardará generalmente varios minutos en iniciar cualquier orden, pero el disco de la máquina estará trabajando a tiempo completo. Algunas veces un nuevo arranque del sistema reparará este tipo de problema, pero con más frecuencia habrá que desinstalar la aplicación o incluso suprimir la entrada que se refiere al programa en /etcl/inittab.

2. El proceso engendra muchos hijos. Ocasionalmente un programa fallará de tal modo que repetidamente genere más y más procesos hijos. Se puede detectar este problema si la máquina baja su tiempo de respuesta sustancialmente o si hay muchos más procesos listados en la salida de ps de lo que es normal. Generalmente estos procesos inesperados tendrán el mismo pid padre, y este padre es probablemente la causa del problema. A veces este tipo de fallo se debe a un único proceso extraviado que es creado cada vez que se ejecuta la aplicación transgresora. Cuando esto sucede, se verán varias copias del proceso extraviado, pero el padre generalmente ya no está activo, por lo que el pid padre del proceso extraviado no tendrá significado. Este caso es difícil de diagnosticar, pero se puede tratar de ejecutar el presunto culpable y ver si se produce un nuevo proceso extraviado. A veces la columna TTY o STIME de la salida ps -ef puede ayudar a determinar dónde o cuándo fue iniciado el proceso extraviado.

3. El proceso consume cantidades desmesuradas de tiempo de CPU. Ocasionalmente un único proceso se descarriará y tomará todos los recursos de CPU que la máquina pueda concederle. Se puede detectar este problema si la máquina parece lentificarse notablemente y un solo proceso en la salida ps -ef ha acumulado mucho tiempo, generalmente varios minutos o más de CPU. Si usted ejecuta repetidamente ps -ef, verá que el proceso transgresor está obteniendo la mayor parte del tiempo de CPU en un sistema que de otra manera podría estar casi inactivo. Este problema es más difícil de detectar, ya que se debe estar seguro de que no se trata de una aplicación correcta que tiene el uso legítimo de todo el tiempo de la CPU. Generalmente los procesos de tiempo compartido que se están ejecutando correctamente tardarán más en completarse si necesitan muchos recursos de CPU, pero no lentificarán notablemente la máquina.

De nuevo, la información clave para detectar problemas relacionados con procesos es una modificación notable en el tiempo de respuesta, o una actividad inusual del disco que no tenga causa aparente. Conforme usted adquiera más experiencia con la máquina, aprenderá a detectar cambios en su rendimiento, y con ps puede generalmente determinar la fuente del problema.

Se puede instalar una versión del comando top que se obtiene del siguiente sitio:

ftp://ftp2.caldera.com/pub/skunkware/osr5/vols/top-3.5beta5-VOLS.tar



ftp://ftp2.caldera.com/pub/skunkware/osr5/vols/top-3.5beta5-VOLS.tar


Eliminación de un proceso

Cuando se detecta que un proceso se ha extraviado, o simplemente se ha iniciado algún trabajo largo que se desea detener antes de que se complete, se puede desear eliminar el proceso. El sistema UNIX proporciona herramientas para eliminar procesos, y un usuario tiene permitido eliminar cualquier proceso del cual sea propietario. El superusuario puede eliminar cualquier proceso del sistema excepto los pids 0, 1, 2, 3 y 4; sin embargo, los usuarios regulares tienen prohibido eliminar ningún proceso que no sea de su propiedad. La orden kill se utiliza con la opción -9 y un pid como argumento para eliminar un proceso, como se muestra aquí:

$ kill 573

Si la eliminación tiene éxito, el proceso desaparece de la salida de ps y la orden kill vuelve silenciosamente. Desgraciadamente, muchas cosas pueden hacer que kill falle, por lo que debería siempre comprobarse la salida de ps después de eliminar un proceso para asegurarse que éste ha desaparecido realmente. Generalmente, también se deseará comprobar que el sistema no ha iniciado inmediatamente el proceso de nuevo (con un nuevo pid). Cuando se elimina un proceso, los hijos de éste pueden set heredados por init y en este caso los hijos no serán eliminados. Por tanto, antes de eliminar un proceso debería determinar si tiene hijos y eliminar todos los hijos al mismo tiempo que el padre. Se pueden especificar múltiples pids como argumentos de la orden kill del modo siguiente:

$ kill 4320 4326 4356 4356

La eliminación de procesos, especialmente cuando se ha hecho la presentación como root, puede ser peligrosa, ya que se puede estar interrumpiendo una función importante del sistema. Generalmente si usted elimina un proceso que no debería haber sido eliminado, tendrá que volver a arrancar la máquina para arreglar las cosas.

Al eliminar un proceso, realmente se está instruyendo al sistema para que envíe a ese proceso una señal. Las señales se utilizan para comunicación entre procesos y pueden enviarse muchas señales diferentes. Existen generalmente 31 señales en SVR4; la lista completa aparece en la página de manual signal(5). Estas señales se refíeren generalmente a varias condiciones de error dentro del sistema. por ejemplo, si un proceso trata de acceder a memoria del sistema fuera del área de memoria «autorizada», el sistema UNIX le enviará la señal número 11, una violación de segmentación de memoria. Otras señales se envían cuando se conecta el terminal, cuando se presiona la tecla DEL, cuando un proceso hijo muere y cuando el «reloj de alarma» interno se agota. Es misión de la aplicación responder adecuadamente a la señal, bien muriendo o tomando alguna acción de modo que la condición que condujo a la señal no vuelva a darse. Cuando se ejecuta la orden kill, por omisión el sistema envía la señal 15 al pid o pids que hayan sido especificados. Esta es una señal de terminación software que generalmente hace que el proceso muera. Sin embargo, el proceso no necesariamente acepta esta señal, por lo que hay disponible una señal de eliminación incondicional, que funcionará inmediatamente. La señal número 9 provoca una eliminación inmediata e incondicional de un proceso. Se puede especificar el número de señal para la orde kill como una opción. Por ejemplo:

$ kill -9 4367

También se puede utilizar un nombre de señal lógico como los listados en signal(5), suprimimiendo la parte SIG, tal como se muestra aquí:




$ kill -HUP 4369

De nuevo, tenga cuidado de no eliminar ningún proceso innecesariamente.




SEGURIDAD DEL SISTEMA

La seguridad

Puesto que el sistema UNIX está diseñado para soportar múltiples usuarios, dispone de muchos modos para que los usuarios accedan al sistema y muchas herramientas para comunicación entre usuarios y entre máquinas diferentes. Sin embargo, en el mundo actual hay razones para que personas no autorizadas irrumpan en el sistema de la computadora, desde la simple emoción de jugar hasta el daño malicioso o el robo comercial de datos y programas. Por lo tanto, muchas herramientas relacionadas con comunicaciones disponibles en el sistema UNIX son una bendición a medias; hay que equilibrar la facilidad de acceso para los «amigos» con la prevención del acceso para los «enemigos».

El sistema UNIX fue originalmente desarrollado para servir a pequeños grupos de personas que compartían la máquina totalmente. No existían rígidas limitaciones al acceso de un usuario a los archivos y órdenes de otros usuarios, incluso ni a los datos más sensibles destinados a mantener en operación el sistema UNIX. Cualquier usuario podía fácilmente eliminar o modificar archivos, o incluso suspender el sistema.

Con los años ha habido un desplazamiento definido en la filosofía hacia una mayor seguridad, y la versión SVR4 puede llegar a ser bastante segura. Un administrador de sistema experimentado puede controlar totalmente el acceso al sistema, y el sistema UNIX es ahora tan seguro como la mayoría de los sistemas operativos. Las versiones de SVR4 han sido certificadas en los niveles de seguridad B2 (Protección estructurada) y B3 (Seguridad de dominios) del Departamento de Defensa de los Estados Unidos. Sin embargo, las cuestiones de seguridad son complejas, debido a la existencia de tantos subsistemas, y todo debe estar correctamente ajustado para alcanzar una seguridad óptima.

Revisaremos el tema de la seguridad de la computadora y exploraremos algunas herramientas y órdenes relacionadas con ella. Conforme la dependencia del usuario crezca más y más con respecto a la máquina Unix y los archivos y datos que ésta contiene, la seguridad del sistema se convierte para él en algo más importante. Se pueden adoptar pasos para impedir acceso no autorizado, pero la tendencia natural de un sistema operativo complejo es hacia la disminución de su seguridad con el paso del tiempo; hay que estar constantemente alerta para detectar agujeros en la seguridad y defender rápidamente el sistema tapando esos agujeros.

Si la seguridad es verdaderamente una preocupación, se puede obtener el software Unix System V/MLS de AT&T, que implementa los niveles de seguridad B2 o B3.

Dentro de una máquina o red de máquinas, el administrador o grupo de usuarios en conjunto debería establecer una politica de seguridad para regular la asignación de nuevos identificadores de usuario, la cantidad de protección por contraseña requerida dentro del sistema y la cantidad de conectividad que la máquina permite a las LANs y el mundo externo. La política debería ser divulgada a los nuevos usuarios, y deberían hacerse barridas regulares del sistema de archivos para asegurar su conformidad con esta política. Si el sistema está relativamente aislado y tiene un pequeño grupo de usuarios con la misma comunidad de intereses, la politica de seguridad puede ser relativamente laxa. Por otra parte, si el sistema es grande y tiene varios grupos de usuarios, un elevado perfil público, o contiene datos especialmente sensibles o privativos, la política de seguridad debe ser más restrictiva. La responsabilidad principal del cumplimiento de las normas de seguridad corresponde a cada usuario individual, aunque los administradores del sistema pueden desarrollar un procedimiento de auditorias regulares con realimentación a la comunidad de usuarios.




Más allá de la política de seguridad, la regla más importante es la de conocer el sistema. Si el administrador y los usuarios del sistema utilizan frecuentemente las órdenes ps, who, ls y otras órdenes de información del sistema, se familiarizarán con la actividad normal día a día de la máquina y estarán alerta al estado del sistema en todo momento. Entonces las desviaciones de la norma serán rápidamente advertidas, de modo que el administrador del sistema podrá tomar acciones adecuadas para cerrar los escapes.

Las cuestiones de seguridad caen naturalmente en varias categorías generales; la primera es la protección de los archivos y datos privados de un usuario respecto del resto de usuarios; segundo, la protección de los archivos claves del sistema operativo contra daños intencionados o accidentales; tercero, la seguridad física de la máquina, y cuarto, la protección contra determinados ataques de "piratas" experimentados que pueden dañar o destruir el sistema.

Protección de los datos frente a los otros usuarios

Como se recordará la orden ls -l muestras los permisos de un archivo o directorio:

$ ls -l /etc/inittab -r--r--r-- 1 root audit 2478 Aug 21 19:49 /etc/inittab

El archivo tiene tres grupos de permisos para cada uno de los tres niveles de seguridad; es decir, tiene acceso de lectura, escritura y ejecución para el propietario, para el grupo y para todos los usuarios. Cada archivo es propiedad de un id de presentación y pertenece a un grupo. En el ejemplo anterior, el propietario del archivo es root y el grupo es audit. El archivo es legible por todos, pero no es modificable ni ejecutable por ninguno.El significado de la primer columna del comando ls –l se muestra en la figura 4.1.

Figura 4.1. Descripción de los permisos en Unix.

La siguiente tabla describe las posibilidades del primer bit que indica el tipo de archivo o dato.

- Archivo común

d Directorio

c Dispositivo de caracteres (tty o impresora)




b Dispositivo de bloque (usualmente disco rígido)

l Enlace simbólico

s Socket

La siguiente tabla es un resumen de Permisos más utilizados.

Octal Propietario Grupo Otros Completo

Número Columna1 Columna2 Columna3 Código

777 rwx rwx rwx rwxrwxrwx

755 rwx r-x r-x rwxr-xr-x

700 rwx --- --- rwx------

666 rw- rw- rw- rw-rw-rw-

Cuando se crea un nuevo archivo, el usuario que lo crea es el propietario del archivo, y su grupo se asigna como id de grupo. Se puede ceder la propiedad del archivo con la orden chown, y se puede cambiar el grupo del archivo con chgrp, pero sólo si se es propietario del archivo. Normalmente no se puede reclamar la propiedad una vez que se ha cedido, aunque si un archivo es legible se puede crear una nueva copia de él con la propiedad restaurada. Sólo el superusuario puede cambiar los permisos de cualquier archivo del sistema.

Permisos implícitos para creación de archivos

Después de crear un archivo se deben verificar sus permisos con ls -l para comprobar que son los que se desean. El sistema UNIX proporciona automáticamente al creador de un archivo la propiedad del mismo, y asigna al archivo el grupo de su creador. Aunque esto no puede ser modificado, se puede declarar una variable del sistema asociada con el id de presentación que establecerá los permisos de un archivo sin acción explícita por parte del usuario. Esta variable del sistema se denomina umask (por máscara de usuario - user mask), y es accedida con la orden umask. Se puede determinar el valor actual de umask ejecutando la orden sin argumentos del modo siguiente:

$ umask 0022

Aquí el resultado de los tres últimos dígitos octales se refieren a los permisos del propietario, el grupo y los otros, de izquierda a derecha (022). A este número se le denomina máscara ya que cada digito se resta de un permiso implícito global del sistema que todos los nuevos archivos obtienen. Normalmente este permiso global es -rw-rw-rw-, pero sistemas y programas individuales pueden diferir de este valor. Puesto que la umask del usuario se resta de este valor implícito, no se pueden activar permisos con umask que estén normalmente desactivados, pero se pueden desactivar permisos que están normalmente activados. Naturalmente se pueden activar explícitamente permisos con chmod si el usuario tiene la propiedad del archivo. Cada dígito octal de la umask contiene un bit binario que borra un permiso: un 1 borrará el permiso de ejecución, un 2 borrará el permiso de escritura y un 4 borrará el permiso de lectura. Por tanto, si un dígito es cero, se utiliza el permiso implícito; por ejemplo, la umask anterior, 000, significa que no se alteran




ninguno de los valores implícitos. El valor de umask 022 crearía archivos sin permiso de escritura para el grupo o para el resto. Por ejemplo:

$ umask000$ > def.perm$ ls -l def.perm -rw-rw-rw- 1 steve other 0 May l0 14:57 def.perm$ umask 022 $ umask 022 $ > no.escr $ ls -l no.escr -rw-r--r-- 1 steve other 0 May 10 14:58 no.escr $ umask 777$ > no.perm $ ls -l no.perm ---------- 1 steve other 0 May 10 14:58 no.perm

La umask implícita de 000 crea los archivos con los permisos implícitos. Cuando se redefine umask a 022, se crean archivos sin permiso de escritura para el resto de los usuarios. La umask de 777 desactiva todos los permisos para todos los usuarios, de modo que el último archivo no es accesible para nadie.

Para declarar la umask se utiliza la orden umask con el código octal como argumento. Esta declaración no sobrevive a una despedida, de modo que si desea modificar permanentemente la umask, hay que colocar la orden umask en el fíchero .profile.

Encripción de archivos

Se puede proteger adicionalmente los archivos que necesiten tratamiento especial encriptándolos. La mayoría de los sistemas Unix en los Estados Unidos disponen de herramientas para encriptar los archivos de acuerdo con una clave que el usuario proporciona; sólo reintroduciendo la clave correcta se puede acceder a estos archivos. El cifrado de archivos no está disponible en implementaciones vendidas fuera de los Estados Unidos.

La versión de SCO openserver 5.0.5 no contiene las utilerias de encriptación de archivos por lo que es necesario obtener el paquete Support Level Supplement (SLS) OSS425D que contiene una versión de ex/vi para edición de archivos encriptados y además de las librerias de encripción (libcrypt.a) y el comando crypt. Se puede obtener este software desde el sitio: http://wdb1.caldera.com/clbk_web/owa/dwnuser.os_select_action?f_os_osrel_id=4&f_sess_id=2119204510

Editores tales como ed, vi y emacs proporcionan la capacidad de crear y editar archivos encriptados. Se puede decir al editor que descifre un archivo cuando lo cargue y lo encripte de nuevo cuando lo escriba al disco. La opción -x especifica cifrado del modo siguiente:

$ vi -x texto Key:



http://wdb1.caldera.com/clbk_web/owa/dwnuser.os_select_action?f_os_osrel_id=4&f_sess_id=2119204510

http://wdb1.caldera.com/clbk_web/owa/dwnuser.os_select_action?f_os_osrel_id=4&f_sess_id=2119204510


Aquí el editor está solicitando la contraseña de cifrado o cIave. Introduzca la clave del mismo modo que introduce una contraseña durante la presentación. Cualquier contraseña es aceptable cuando se encripta un archivo, pero naturalmente debe utilizar la misma para descifrarlo. Como es habitual, la contraseña no produce eco. Si se introduce la contraseña correctamente, el archivo será descifrado y aparece en el editor. Cuando se escriba el archivo de nuevo, durante o después de la sesión de edición, será encriptado de nuevo. Se puede utilizar este procedimiento para crear un nuevo archivo o para editar un archivo existente.

Las versiones del sistema Unix vendidas en los Estados Unidos también facilitan un filtro para efectuar encripción y descifrado. La orden crypt lee la entrada estándar y escribe en la salida estándar. Si la entrada está en el archivo texto, la salida será cifrada. Si la entrada está cifrada, la salida será descifrada. Al igual que el procedimiento de edición, crypt solicita una contraseña, tal como se muestra aquí:

$ cat texto | crypt Enter key:

Como es habitual, la contraseña no produce eco. Desgraciadamente, el algoritmo por el cual los archivos son cifrados en el sistenia Unix es poco conocido y hay disponibles programas que pueden reventar el algoritmo de cifrado. Por tanto, no es seguro poner demasiada confianza en los archivos cifrados, especialmente en un entorno hostil. Los programas transgresores de encripción funcionan analizando las frecuencias de los caracteres en los archivos cifrados y comparándolos con las frecuencias de caracteres en el texto inglés normal.

Para vencerlos se puede modificar la frecuencia de caracteres del texto normal antes del cifrado con otro filtro tal como pack, compress, gzip o gunzip. Por ejemplo:

$ compress texto$ crypt < texto.llano.Z > fich.sal

El archivo comprimido no puede ser analizado por ningún transgresor de crypt conocido. Naturalmente, cuando se descifre el archivo hay que recordar desempaquetarlo del modo siguiente:

$ crypt < fich.sal > texto.Z $ uncompress texto.Z

Recuerde que debe comprimir antes de cifrar y descomprimir después de descifrar. Naturalmente, el esquema de proteccion de archivos de más éxito es el que implica escribir el archivo a un disco flexible o cinta magnética, suprimir el archivo de la máquina y poner a buen resguardo el medio magnético.

Ids de presentación y contraseñas

El corazón del esquema de seguridad del sistema UNIX es el id de presentación y la contraseña del usuario individual. Si los atacantes potenciales pueden ser mantenidos completamente fuera del sistema, no podrán causar daños. Desgraciadamente, en muchas máquinas la seguridad de la contraseña es tan pobre que incluso un infractor sin experiencia puede obtener un shell. Es responsabilidad de cada usuario defender su propia contraseña y cambiarla regularmente. Muchos ids de usuario de un sistema pequeño típico no tienen contraseña en absoluto, o sus contraseñas son tan similares al id de presentación que es ineficaz como seguridad. Desgraciadamente, la mayoría de los usuarios no desean recordar el tipo de contraseña que sea




muy extraña y que es requerida para la seguridad, de modo que con el tiempo las contraseñas pasan a ser detectables. Todo usuario debería ser forzado a tener una contraseña, y la contraseña debería ser envejecida de modo que el usuario estuviese forzado a cambiarla con regularidad. Puesto que la contraseña se almacena en forma encriptada, ni siquiera el administrador del sistema puede determinar cuál es. Afortunadamente, el ataque por frecuencia de letras mencionado anteriormente no es posible con una muestra de texto tan breve como una contraseña. La herramienta que permite modificar la contraseña es la orden passwd. En Ia mayoría de los sistemas Unix existen reglas que describen una contraseña aceptable, e incluso si estas reglas no son forzadas por el software del sistema, proporcionan buenas líneas de guía para crear una contraseña propia. Una buena contraseña tiene como poco seis caracteres, de los cuales al menos uno (preferiblemente dos) es un carácter no alfabético. Una mezcla de caracteres mayúsculas y minúsculas es buena, y cualquier secuencia inusual o no intuitiva de caracteres también es útil. Algunos ejemplos de contraseñas triviales no aceptables son el id de presentación, el nombre del usuario, el nornbre de su hijo, su número de habitación o teléfono, su signo astrológico, su dirección, etc.

Historial de presentaciones

Algunas versiones SVR4 proporcionan una visualización de la última vez que un id de presentación fue utilizado. La visualización aparece cuando el usuario se presenta ante la máquina, del modo siguiente:

login: rootPassword: Last successful login for root: Thu Aug 21 22:27:57 2003 on tty04Last unsuccessful login for root: Thu Aug 21 17:33:27 2003 on tty03

SCO OpenServer (TM) Release 5

(C) 1976-1998 The Santa Cruz Operation, Inc1980-1994 Microsoft CorporationAll rights reserved

For complete copyright credits,Enter “copyrights” at the command promptTerminal type is scoansi#

Esta visualización pretende alertar al usuario por si alguien más ha estado utilizando su id de presentación. Si la fecha difiere del recuerdo que tiene el usuario de su última sesión, su id de presentación está siendo mal utilizado y debería inmediatamente de tomar medidas para cambiar la contraseña.

Esta característica está mantenida por el programa login cuando éste verifica la contraseña. login mantiene un fíchero de longitud cero denominado .lastlogin en el directorio propio. La fecha y hora de la última presentación son la fecha de modificación de este archivo. El archivo .lastlogin es propiedad del sistema, no del usuario individual y sus permisos lo hacen dificil de modificar, como puede verse aqui:

$ ls -l $HOME/.lastlogin -r------ 1 root auth 0 Oct 28 15:11 .lastlogin




Esta no es una característica de seguridad enérgica, pero puede avisar al usuario de si su id de presentación ha sido comprometido.

El superusuario

Cada usuario normal está restringido a sus propios archivos y datos y a los de su grupo. Sin embargo, el id de presentación root está disponible en todas las maquinas Unix para permitir acceso completo de lectura, escritura y ejecución a todos los archivos y directorios. Este usuario es conocido como el superusuario. También puede utilizarse la orden su (por superusuario) para conmutar al estado de superusuario sin necesidad de despedirse y presentarse de nuevo como root, tal como se muestra aquí:

$ su Password:Last successful real login for root: Thu Aug 21 22:29:03 2003 on tty04Last unsuccessful real login for root: Thu Aug 21 17:33:27 2003 on tty03Terminal type is scoansi #

El archivo de contraseñas

La información crítica que controla las identificaciones de los usuarios está mantenida en un sencillo archivo de base de datos llamado /etc/passwd. Como puede verse aquí, este archivo es legible por todos los usuarios, y modificable por el propietario y el grupo, lo ideal seria que no fuese modificable.

$ ls -l /etc/passwd -rw-rw-r-- 1 bin auth 526 Apr 10 19:49 /etc/passwd

Se desearia tener los siguietnes permisos para este archivo

-r--r--r-- 1 bin auth 526 Apr 10 19:49 /etc/passwd

Estos permisos deberían ser mantenidos cuidadosamente; si el archivo /etc/passwd fuera modificable por alguien, la seguridad del sistema se quebraría fácilmente.

Cada usuario tiene una línea en el archivo de contraseñas, y también son necesarios varios ids de presentación estándar globales del sistema para el correcto funcionamiento de éste. Cada línea consta de varios campos, delimitados por : (dos puntos). El id de presentación del usuario es el primer campo de la línea, y el segundo es un emplazamiento para la contraseña del usuario. El tercero es la representación numérica del id de usuario, y el cuarto es la representación numérica del id del grupo. Estos dos campos actúan junto con los permisos del archivo para determinar quien puede acceder a cada archivo del sistema. El quinto campo es un comentario que generalmente contiene el nombre y la dirección del usuario. El penúltimo campo contiene el directorio propio del usuario, y el último campo contiene el nombre de camino completo del shell de presentación del usuario. Si el último campo falta, implicitamente señala a /sbin/sh.

En versiones más antiguas del sistema UNIX, el segundo campo contenía la contraseña real cifrada de cada usuario. Sin embargo, en SVR3 se introdujo un segundo archivo en el sistema para contener la contraseña cifrada y algunos otros datos. Este archivo es /etc/shadow, y sólo debería ser legible por root, tal como se muestra aquí:




$ ls -l /etc/shadow -rw-rw---- 1 root root 187 Apr 10 19:49 /etc/shadow

El archivo /etc/shadow contiene los ids de presentación de usuario, sus contraseñas cifradas, un código numérico que describe cuándo fue modifcada por última vez la contraseña y el número mínimo y máximo de días requerido entre cambios de contraseña.

Habrá una línea en /etc/shadow por cada línea de /etc/passwd. Cuando /etc/shadow está presente, el campo de contraseña en /etc/passwd es reemplazado por el único carácter x. En caso contrario, el segundo campo de /etc/passwd aparecerá como el segundo campo del ejemplo anterior en /etc/shadow.

El archivo /etc/shadow es creado por la orden pwconv, la cual lee en /etc/passwd la información necesaria. Cada vez que se modifique manualmente /etc/passwd, debería ejecutarse inmediatamente pwconv para asegurarse que los cambios sean actualizados en /etc/shadow. Los archivos de contraseñas y shadow no deberían ser modificables, de modo que sólo el superusuario pueda cambiarlos.

Shell seguro

Telnet es una herramienta muy poderosa, pero es vulnerable a ataques de usuarios maliciosos por que la transferencia de información a través de la red va sin codificar, y cualquiera observando el tráfico de la red podría descubrir nuestras contraseñas. Para dificultar el descubrimiento de la información privada que viaja a través de la red en este tipo de sesiones existe una herramienta de shell seguro ssh (secure shell).

La primera vez que nos conectemos con esa ip nos pregunta si estamos seguros de a quién nos estamos conectando, ya que podríamos conectarnos a la maquina de un usuario malicioso, en la que nos autentificaríamos dándole así nuestra contraseña. En principio si conocemos la máquina destino, no tendría por qué haber problemas, aceptamos y nos autentificamos con nuestra contraseña. Una vez finalizado el proceso de autentificación, entramos en un terminal con las mismas posibilidades que el de telnet, pero en modo seguro.

Instalación

Para la instalación del shell seguro para la version Openserver 5.0.5 se requieren los paquetes zlib y PRNGD. Estos paquetes se pueden obtener de:

ftp://ftp2.caldera.com/pub/skunkware/osr5/vols/zlib-1.1.4-VOLS.tarftp://ftp2.caldera.com/pub/skunkware/osr5/vols/prngd-0.9.23-VOLS.tar

Para el caso de openssh-3.1p1-VOLS.tar copiar el archivo openssh-3.1p1-VOLS.tar al directorio /tmp

# cp openssh-3.1p1-VOLS.tar /tmp

Cambiarse al directorio /tmp y descomprimir el archivo

# cd /tmp# tar xvf openssh-3.1p1-VOLS.tar



ftp://ftp2.caldera.com/pub/skunkware/osr5/vols/prngd-0.9.23-VOLS.tar

ftp://ftp2.caldera.com/pub/skunkware/osr5/vols/zlib-1.1.4-VOLS.tar


Instalar el software desde el Software Manager previamente instalados los paquetes PRNGD y zlib. Estos paquetes deberan ser instalados utilizando el mismo procedimiento.




SERVICIOS

FTP

FTP (File Transfer Protocol, puerto 21 TCP) es, como su nombre indica, un protocolo de transferencia de archivos entre sistemas. Desde un equipo cliente conectamos a un servidor para descargar ficheros desde él - lo habitual - o para enviarle nuestros propios archivos.

La configuración de este servicio se realiza desde el Internet Configuration, figura 6.1 con login admin y el password corresponde al del root.

Figura 6.1 Configuración de los servicios en Internet Configuration

En su forma más simple la configuración consiste en permitir o negar transferencias de archivos en general del sistema y escrituras o lecturas para usuarios anonimos.

A los usuarios nombrados en /etc/ftpusers no se les permite el servicio, ni a los que no tienen un shell listado en /etc/shells. Esto tipicamente restringe accesos a UUCP, etc.

Por ejemplo el contenido del archivo /etc/shells es:# cat /etc/shells# @(#) shells 59.1 96/11/15#/bin/csh/bin/sh/bin/ksh/usr/bin/scosh El contenido del archivo /etc/ftpusers es:




# cat /etc/shellsrootsam

Si deseamos permitir conecciones de ftp anónimo debe existir un usuario ftp en el archivo /etc/passwd

# cat /etc/passwd | grep ftpftp:x:20:50:anonymous ftp account:/usr/internet/ip/0.0.0.0/sco_ftp:/bin/sh

El directorio en donde se coloca el sitio ftp anónimo por default es

/usr/internet/ip/0.0.0.0/sco_ftp/pub

En la estructura de este directorio se pueden mencionar como los más importantes:/bin Contiene el programa ls para comandos list/etc Contiene passwd y group para que ls produzca nombres en lugar de numeros/pub En donde se colocan los archivos compartidos para acceso anónimo




NFS

El Sistema de Archivos de Red (NFS) es probablemente el servicio de red más prominente en el uso de RPC´s (Remote Procedure Call). Permite accesar archivos en hosts remotos en la misma manera que se accesarían los archivos locales. Una mezcla de soporte del kernel y demonios del espacio de usuario en el lado del cliente, junto con un servidor NFS en el lado del servidor, hace esto posible. Este acceso a archivos es completamente transparente al cliente como se muestra en la figura 6.2, y trabaja en una variedad de arquitecturas.

Figura 6.2. Esquema del sistema de archivos en red (NFS)

NFS ofrece un número de aspectos útiles:

Los datos accesados por el usuario pueden ser guardados en un host central, con clientes montando este directorio en el arranque,

Los datos que consumen una gran cantidad de espacio pueden colocarse en un solo host, Los datos administrativos pueden ser guardados en un solo host.

¿Cómo trabaja NFS?

Sistemas de archivos distribuidosUn sistema de archivos distribuido utiliza el modelo cliente servidor para proporcionar acceso compartido a




archivos a través de la red. Los servidores exportan (hacen accesibles) directorios de archivos que se encuentran en los medios de almacenamiento de información (discos compactos, discos duros, etc.). Los clientes pueden montar (obtener acceso) a directorios que se han exportado.

Procesos cliente y servidor NFS

Dos procesos (tambien conocidos como demonios) proveen los servicios NFS del servidor.

1. mountd. Verifica los permisos de acceso del sistema de archivo exportado y regresa un apuntador a este cuando un cliente trata de montar un sistema de archivos.

2. nfsd. Inicia el demonio servidor NFS que atiende las peticiones de sistemas de archivos de los clientes.

Estos demonios son convencionalmente iniciados por default cuando el sistema inicia en el modo multiusuario. Los scripts de inicio tipicamente se encuentran ligados al scrip /etc/rpcinit en /etc/rc2.d/S89nfs.

El siguiente es un ejemplo de un procedimiento de montaje en el cliente:

mount –f NFS 192.168.1.1:/compartido /mnt

Actividad que se realiza en el cliente:1. El comando mount utiliza la tabla de dispositivos montados en /etc/mnttab y hace una consulta que

verifica que no se haya realizado este montaje anteriormente.2. El comando mount realiza un parser de los argumentos: host 192.168.1.1 y el directorio remoto /

compartido que corresponden al sistema de archivos que se compartiran desde el host. El último ar-gumento corresponde a un directorio del sistema de archivos local o del cliente, en donde estaran disponibles los archivos o directorios que comparte el host.

3. Ahora mount llama al portmap de 192.168.1.1 para obtener el número de puerto del mountd4. El comando mount llama al mountd de 192.168.1.1 y proporciona a este la ruta /compartido.

En el lado servidor:1. mountd lee el archivo /etc/exports y busca el sistema de archivos exportado que contiene /comparti-

do2. mountd realiza una llamada al sistema nf_getfh (en SCO) para obtener la accesibilidad a /comparti-

do3. mountd regresa la aceptación al cliente

Archivos de configuración NFSEn el lado servidor, el archivo /etc/exports lista los directorios exportados por el servidor y opcionalmente los hosts remotos que tendrán acceso a los directorios, en cuyo caso el servidor requiere de algún medio para encontrar las direcciones IP de los clientes. Si las direcciones no son incluidas en el archivo /etc/exports, el servidor utilizará el DNS o las entradas en el archivo /etc/hosts.

El cliente depende del servicio DNS o las entradas en el archivo /etc/hosts para encontrar las direcciones de los servidores de los cuales quiere montar archivos.

Configuración de ejemplo




Agregar el protocolo NFS en los protocolos de red del sistema mediante el Network Configuration Manager..Editar el archivo /etc/exports y agregar las entradas bajo el siguiente formato:

<Directorio_exportar> [- opción [, opción]]

Directorio_exportar. Se refiere al nombre del directorio que deseamos compartiropción. Puede ser cualquiera de las siguientes opciones:ro. Exporta el directorio para solo lectura. Si no es especificado el directorio se exporta en el modo lectura y escritura.rw=hostnames[:hostname]. Exporta el directorio principalmente en el modo lectura, excepto para los hosts especificados por hostname que aplican para el modo lectura y escritura.

Un archivo /etc/exports básico se observa como:

# cat /etc/exports/tmp -ro,access=m02.fie.umich.mx/compartido -rw=sidold.fie.umich.mx:m02.fie.umich.mx

Notas:Previamente debe crear el directorio donde se va a montar el sistema de archivos remoto.El servicio de inicia o se detiene con /etc/nfs start | stop

Procedimiento de configuración de NFS desde la interfaz gráfica

Se llega mediante System Administration – Filesystem Manager, en el menú Export seleccionar la opción NFS – Add Export Configuration.

A continuación se agrega el directorio a exportar por ejemplo /compartido

Se decide si los clientes deben hacer solo lectura o lectura y escritura y si se desea agregar privilegios de root. Estos privilegios se pueden establecer para todos los clientes, solo para algunos seleccionados o para ninguno.Las opciones avanzadas permiten o impiden el acceso de clientes anonimos.




DHCP

El protocolo de configuración dinámica de Hosts (DHCP – Dynamic Host Configuration Protocol) puede facilitar grandemente la administración de una red TCP/IP. DHCP asigna de manera dinámica las direcciones IP de las computadoras, eliminando la necesidad de la configuración manual. Un cliente DHCP puede incluso cambiar de red sin tener que ser reconfigurado. Varios parámetros, por ejemplo los gateways, DNS, etc., pueden ser configurados automáticamente. La figura 6.3, ilustra una cofiguración típica DHCP.

Figura 6.3 Configuración típica DHCP

Funcionamiento de DHCP




Un servidor DHCP asigna direcciones IP y los clientes solicitan a los servidores que se les asigne una. El servidor mantiene grupos de direcciones IP llamados ámbitos. Cuando un cliente entra en la red, solicita una dirección y se obtiene una concesión para utilizar una dirección de un ámbito. BOOTP añade la dirección de la red de origen a cada solicitud de dirección IP. Esta información permite que el servidor asigne una dirección adecuada para la red de la que se trata. Este esquema se muestra en la figura 6.4.

Figura. 6.4.- Funcionamiento del servicio DHCP

El concepto de concesión es importante. Los clientes no obtienen una dirección permanente, sino una consesión para usar una dirección por un tiempo limitado. Cuando el tiempo expira, es necesario renegociarla. Esto asegura que las direcciones no queden bloqueadas de forma permanente.

Fases de Consesión

Las fases de negociación de una consesión se ilustran en la figura 6.5 y son las siguientes:

Un host entra en la red y difunde un mensaje de descubrimiento. El mensaje incluye la dirección MAC del cliente, de manera que el servidor le pueda contestar. Para que los mensajes de DHCP se transmitan entre redes, los routers deben usar el protocolo BOOTP, para permitir el reenvío de DHCP.

Cada servidor que recibe el mensaje de descubrimiento responde con un mensaje de oferta DHCP, que consta de una dirección IP más otros datos de configuración.

El cliente examina los mensajes de oferta y selecciona uno. El cliente envía un mensaje de solicitud DHCP al servidor seleccionado, para solicitarle la

configuración ofrecida. Como este mensaje también se difunde, los otros servidores también lo reciben y se dan cuenta que sus ofertas han sido rechazadas.

El servidor DHCP concede el paquete, enviando un mensaje de reconocimiento DHCP. El cliente aplica la configuración IP a los protocolos TCP/IP locales. La computadora puede incluso

reiniciarse antes de que su concesión expire y no tendrá que renegociar. Cuando la concesión llega al 0% de su vida, el cliente intenta renovarla. Si no es posible renovarla, el servidor envía un mensaje de reconocimiento negativo al llegar al 87.5%




de la vida de la concesión. El cliente no puede renovar e inicia el proceso para obtener una nueva dirección.

Figura 6.5. Fases de consesión en el servicio DHCP

Configuración del Servidor DHCP para UNIX

SCO UNIX requiere de dos servicios de administración para configurar el servicio DHCP: Address Allocation Manager (AAS). En él se define el rango de direcciones que estarán disponibles

para la asignación dinámica. DHCP Server Manager. Mantiene la configuración de las opciones DHCP disponibles.

Los archivos involucrados para la configuración del servidor DHCP son:




/etc/aasd.conf para el Address Allocation Manager. /etc/dhcpd.conf para el DHCP Server Manager.

Estos archivos pueden ser generados con las herramientas gráficas de configuración, AAS/DHCP managers que pueden ser accesados desde System Administration -> Networks.

El archivo /etc/aasd.conf contiene los detalles del AAS en el que se define “pool” de direcciones disponibles o rango de direcciones a asignar por el servidor DHCP. Un archivo clásico puede ser el siguiente

pool ippool:INET { 192.168.1.120-192.168.1.130

}

En este caso el pool de direcciones es llamado ippool y estará en condiciones de proporcionar direcciones IP en el rango 192.168.1.120 a 192.168.1.130.

El archivo /etc/dhcpd.conf contiene los parámetros de configuración TCP/IP utilizados para el servidor DHCP, tales como:

Mascara de red Nombre del pool de direcciones IP Puerta de enlace Servidor de nombres o DNS Dominio al que pertenece

El siguiente es un archivo dhcpd.conf para el servidor DHCP, cuando una computadora se conecta podrá obtener una dirección IP del pool de direcciones llamado ippool que fue configurado anteriormente en el AAS.

subnet 192.168.10.0 { comment Pool de direcciones generales mask 255.255.255.0 pool ippool lease_dflt 3600 lease_max infinite t1 750 t2 900 routers 192.168.1.254dns_servers 148.216.1.2 domain sid.fie.umich.mxsmtp_servers 192.168.1.1

}

Una vez establecida esta configuración las computadoras obtendrán una dirección IP y trabajarán normalmente en la red.




Una vez editados estos archivos es necesario detener los procesos aasd y dhcpd si se encuentran activos, entonces primero verificamos esto con:

# ps -ef |grep aasdroot 333 1 0 Aug-23 ? 00:00:00 /etc/aasd

# kill -9 333

El número 333 corresponde al número de proceso del aasd, realizar lo mismo con el proceso que ejecuta dhcpd.

Ejecutar el aasd en el modo depurar:

# /etc/aasd -D 2

Generalmente dhcpd se ejecuta en el inetd, cambiar la línea o agregarla si no existe con la opción para depurar de la siguiente forma:

boots dgram/i udp wait root /etc/dhpd dhcpd -D 2

Enviar la señal SIGHUP al proceso inetd para que lea la configuración nueva de estos archivos.

# ps -ef |grep inetdroot 615 1 0 Aug-23 ? 00:00:00 /etc/inetd

# kill -9 615

Reiniciar inetd

# /etc/inetd

Observar en el archivo /usr/adm/syslog los errores de sintaxis de los archivos de configuración, peticiones de los clientes y asignación de direcciones.

También se puede reiniciar el sistema para tomar los parámetros configurados.

Configuración del cliente DHCP

En un sistema Windows 2000 mediante el icono de Conexiones de Red y reacceso telefonico del Panel de control ver las propiedades de la conexión de Area local y seleccione Protocolo Internet (TCP/IP) y sus propiedades, elegir la opción Obtener una dirección IP automáticamente, como se muestra en la ventana de dialogo de la figura 6.6.

Para la configuración de un cliente SCO es necesario instalar el paquete tls711.tar.Z. Las instrucciones de instalación se encuentran en el archivo README que viene en el paquete, el cual está disponible en ftp://stage.caldera.com/TLS/tls711.tar.Z



ftp://stage.caldera.com/TLS/tls711.tar.Z


Figura 6.6 Ventana de diálogo para la configuración del cliente DHCP en Windows 2000.

Se puede utilizar la utileria ipconfig o winipcfg en los sitemas Windows para mostrar la configuración actual y la petición de la nueva dirección, una vez que se ha configurado un cliente DHCP en el sistema operativo Windows.




SEGURIDAD EN EL KERNEL

El kernel o núcleo es la parte más importante de todo sistema Unix, hasta tal punto que se considera al kernel como el sistema operativo en sí. Aunque si no lo consideramos así, y vemos al sistema operati -vo como el conjunto formado por el kernel y una serie de herramientas (editor, compilador, enlazador, shell, etc.), no se puede negar que el kernel es la parte del sistema más importante, y con una impor-tante diferencia: mientras que las aplicaciones operan en el rango del usuario, el kernel siempre trabaja en el modo privilegiado del procesador. Esto implica que no se le impone ninguna restricción a la hora de ejecutarse: utiliza todas las instrucciones del procesador, direcciona toda la memoria, accede direc-tamente al hardware (más concretamente, a los manejadores de dispositivos), etc. De esta forma, un error en la programación, o incluso en la configuración del kernel puede ser desastroso para nuestro sistema.

Por desgracia la mayoría de administradores piensan que un intruso nunca va a actuar a un nivel tan bajo, como para comprometer al sistema. Si bien es cierto que en redes normales, muchos de los ata-cantes no poseen los conocimientos necesarios, para utilizar el kernel del sistema operativo en benefi-cio propio, cualquier pirata con el suficiente nivel de experiencia puede conseguir privilegios de root y aprovecharlos para modificar el kernel o configurarlo a su gusto. Y es justamente este tipo de ataques uno de los más difíciles de detectar: cualquier administrador confía ciegamente en lo que el sistema operativo le dice, por ejemplo, si ejecuta el comando:

[root@portatil /root]# uptime 4:21pm up 5 days 1:22, 2 users, load average: 0.15, 0.07, 0.02[root@portatil /root]#

Automáticamente asume que su sistema ha permanecido más de 5 días sin reiniciarse; esto puede ser o no cierto, e independientemente de la veracidad del resultado de este comando, alguien puede haber accedido a nuestro kernel y haber comprometido su seguridad. Por ejemplo, si ha modificadoCompletamente el kernel, puede haber reprogramado la llamada sysinfo() para que devuelva un resul-tado erróneo, de forma que el administrador nunca se percate que la máquina ha sido reiniciada para cargar el kernel modificado; incluso en los Unix que soportan la carga de módulos en el kernel (como Linux, FreeBSD, Solaris) el atacante puede haber utilizado esta facilidad para modificar el kernel sin necesidad de reiniciar el servidor.

Para cualquier intruso, el ataque a un kernel, es mucho más fácil en sistemas Unix cuyo código fuente esté disponible (como Minix, Linux, o algunos BSD), aunque el ataque es posible en cualquier siste-ma. El tema de la disponibilidad del código fuente del sistema operativo suele despertar controversias en la comunidad dedicada a la seguridad informática: mientras unos argumentan que esta disponibili-dad supone un problema de seguridad, un atacante puede dedicarse a revisar el código hasta encontrar un error de programación y aprovecharlo, otros sostienen que cuanta más gente tenga acceso al códi-go, más errores se localizarán y solucionarán y por tanto a la larga se va a conseguir un sistema mucho más robusto.

Esta segunda postura es la que más fuerza está tomando desde hace algunos años y parece tambíen la más razonable: es cierto que un atacante puede dedicarse a leer código hasta encontrar un error, pero se




ha comprobado que muchos de los fallos no se suelen detectar de esta forma, sino por cualquier cir-cunstancia que genera un evento extraño, sobre el que posteriormente se investiga. Por tanto, la dispo-nibilidad del código del kernel no debe suponer una amenaza a la seguridad. Además, un administra-dor con un mínimo nivel de conocimientos de programación puede aprovechar la disponibilidad del código para detectar rápidamente problemas de seguridad: por ejemplo, si sospecha que alguien utiliza sus recursos para ejecutar cracks de contraseñas, puede modificar librerías para detectar llamadas "sospechosas" a la función crypt(), o si algun usuario ejecuta un programa que le ha establecido setuid para conseguir privilegios que no le corresponden, puede modificar la llamada al sistema setuid() para comprobar si sus sospechas son ciertas.

Con lo dicho anteriormente, parece claro que el kernel representa un pilar básico para conseguir un sis-tema seguro; es más, al ser el kernel la base del sistema operativo, no sirve de nada esforzarse en con-seguir seguridad a nivel de aplicación si el kernel es inseguro. En este capítulo se van a tratar aspectos relativos a la seguridad de los kernels de sistemas Unix, y tambíen hablaremos de aspectos que, sin pertenecer estrictamente al kernel, son de un nivel tan bajo que su funcionamiento depende de cada versión de Unix. Como cada clon del sistema operativo tiene sus métodos para configurar o recompilar el kernel y además en este trabajo no podemos tratar extensamente cada uno de ellos, es indispensable en cada caso consultar los manuales antes de modificar cualquier parámetro de los vistos en esta sec-ción.

SCO Openserver

Opciones de compilación

En SCO Openserver se puede configurar tunables, esto se realiza utilizando diversas herramientas del sistema operativo, generalmente configure, idtune, getconf o inconfig; por ejemplo, si deseamos mo-dificar el número máximo de procesos en el sistema, lo podemos hacer a través de /etc/conf/cf.d/con-figure o utilizando el ambiente gráfico de scoadmin en la opción Hardware/Kernel Manager. Esta utili-dad nos mostrará un menú con diferentes categorías de parámetros configurables; en nuestro caso de-bemos elegir MAX_PROC, disponible en la sección Table limits de Configuration Tunables. Tam-bíen podemos configurar aquí el máximo número de descriptores de archivo en uso en el sistema, mo-dificando el valor del parámetro MAX_FILE (este parámetro no controla el número máximo de ar-chivos abiertos por proceso).

Utilizando esta misma utilidad, pero ahora en la sección User and group configuration podemos defi -nir el número máximo de archivos que un proceso puede abrir simultáneamente ( nofiles), el tamaño de archivo máximo que un usuario puede crear ( ulimit), el número de procesos simultáneos bajo un mismo identificador de usuario distinto del root ( maxup), el límite de memoria virtual de un proceso sin privilegios ( maxumem) y el comportamiento del comando chown ( chown_res, donde "0", valor por defecto, indica que los usuarios no pueden modificar la propiedad de los archivos).

Si modificamos parámetros del kernel mediante configure, debemos reconstruirlo y situarlo en /etc/conf/cf.d/; ambas cosas se consiguen mediante el comando link_unix, situado en ese mismo directo-rio. Esta utilidad copiará además el kernel actual, /unix, en /unix.old, para poder arrancar con él en caso de que algo grave suceda al introducir modificaciones:




root:~# cd /etc/conf/cf.d/ root:/etc/conf/cf.d# ./link_unix

The UNIX Operating System will now be rebuilt.

This will take a few minutes. Please wait.

Root for this system build is /.

The UNIX Kernel has been rebuilt.

Do you want this kernel to boot by default? (y/n) y

Backing up /unix to /unix.old

Installing new /unix

The kernel environment includes device node files and /etc/inittab.

The new kernel may require changes to /etc/inittab or device nodes.

Do you want the kernel environment rebuilt? (y/n) y

The kernel has been successfully linked and installed.

To activate it, reboot your system.

Para configurar parámetros globales del sistema de red en SCO Openserver podemos utilizar el coman-do inconfig. Esta utilidad actualizará los datos definidos en /etc/default/inet, así como los que el ker -nel en ejecución está utilizando; de esta forma, y al contrario de lo que sucede al utilizar configure, no es necesario reiniciar el sistema para que los nuevos valores se inserten en el kernel, ya que incon-fig lo actualiza de forma dinámica (si alguno de los nuevos valores es erróneo, se mantienen los valo-res actuales para el parámetro correspondiente).

El comando inconfig recibe como argumentos el parámetro a configurar y su nuevo valor; así, si por ejemplo deseamos desactivar el IP Forwarding en nuestro servidor (aunque por defecto ya lo está), po-demos conseguirlo con un comando como la siguiente:

inconfig ipforwarding 0

Un servidor con el IP Forwarding desactivado aún reenvía paquetes source route; para evitar que esto ocurra hemos de asignar al parámetro ipnonlocalsrcroute el valor "0" (utilizado por defecto en SCO Openserver). Otro de los parámetros del sistema de red, en nuestro servidor, que nos puede interesar modificar de cara a aumentar la seguridad es el tiempo de expiración de las entradas de la tabla ARP (Adress Resolution Protocol) por defecto, establecido a veinte minutos; el parámetro de inconfig en




este caso será arpt_keep seguido del valor deseado. Además, la tabla ARP se escanea cada cinco mi-nutos en busca de entradas caducadas; podemos modificar este tiempo con el parámetro arpt_prune de inconfig.

Para prevenir ataques de IP Spoofing contra el sistema, kernel de SCO Openserver introduce un nú-mero aleatorio para generar los números de secuencia y el incremento de los mismos en los paquetes tcp; el parámetro tcp_secret es la semilla que alimenta al generador de números aleatorios, y su valor puede ser cualquiera entre 0 y 2147483647. El número de bits de tcp_secret utilizados realmente como semilla lo define el parámetro tcp_seqbits, con un valor entre 16 y 26; el valor por defecto es 21, es una buena elección para nuestra seguridad: si tcp_seqbits es demasiado bajo, aumenta la posibi-lidad de que un atacante pueda adivinar el número aleatorio que se genera, lo que le facilitará el ataque pero si es demasiado alto se reduce el intervalo entre la aparición de dos números de secuencia iguales, lo que evidentemente tambíen facilita un ataque.

Algunas mejoras de la seguridad

En esta parte se va a comentar algunos aspectos de modificaciones del kernel y o actualizaciones que se distribuyen libremente en forma de parches y que contribuyen a aumentar la seguridad de un siste-ma Unix; para obtener referencias actualizadas de estos código y otros, es recomedable consultar http://wwww.caldera.com/support/security/;

TCP wrappers

Unix SCO debe ser configurado para que sea seguro antes de conectarlo a una red, especialmente cuando nos conectamos a Internet.

Unix ejecuta un conjunto de programas denominados demonios, que proveen servicios de red, como por ejemplo servidores: ftp, smtp, telnet, etc. Estos pueden tener problemas de seguridad, que son uti-lizados por el intruso para ganar acceso a nuestra computadora.

Normalmente, luego de finalizar la instalación de UNIX, existen varios servicios de red ejecutandose que no son necesarios, debemos saber que servicios son, deshabilitar todos aquellos que no sean nece-sarios y configurar de forma segura los servicios que utilizaremos.

El súper server o inetd.Muchas veces necesitamos que una misma computadora brinde varios servicios de red, por lo tanto deberíamos tener en el sistema varios demonios ejecutandose simultáneamente. Esto nos podría producir una sobrecarga en nuestra computadora.

Para reducir la carga en el sistema, existe un "súper server" inetd, el cual se queda en espera por varios servicios de red, cuando un cliente quiere utilizar un servicio, ejecuta el servidor correspondiente y le da el control de la conexión, de esta manera solo tenemos un solo demonio ejecutandose y reducimos la carga del sistema.

Los pasos que realiza el inetd son los siguientes:



http://wwww.caldera.com/support/security/


- Al ejecutarse en el arranque de la PC o cuando lo reiniciamos, lee su archivo de configuración, /etc/inetd.conf , el cual le indica que servicios debe atender y que servidor ejecutar en caso de que se pro-duzca un intento de uso de dicho servicio.

- Queda en espera hasta que intenten conectarse.

- Cuando intentan utilizar un servicio, ejecuta el servidor correspondiente (indicado en el inetd.conf) y le entrega el control de la conexión.

- Vuelve a su estado de espera.

Veamos como esta formado su archivo de configuración.

El inetd.conf.El archivo de configuración del inetd (/etc/inetd.conf) esta compuesto por lineas, donde en cada una se indica el nombre del servicio que atenderá y su programa a ejecutar.Las lineas que comienzan con un '#' son ignoradas (están comentadas).

Veamos brevemente cada campo de una línea de este archivo:

- Nombre del servicio, (ftp, telnet, etc) - Tipo de socket. (stream, dgram, etc) - Protocolo. (tcp, udp) - wait/nowait - usuario con el que se ejecutara el servicio. (root, nobody, etc) - programa que brindara el servicio. (/usr/sbin/tcpd /usr/sbin/in.telnetd)

Ejemplo: telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd

Importante: observar que el último campo (programa que brindara el servicio) es siempre: /usr/sbin/tcpd y el path del programa correspondiente al servicio, esto se explicara mas adelante.

Veamos un fragmento del archivo inetd.conf : ----------------------------------------------------- ftp stream tcp nowait NOLUID /local/etc/tcpd ftpd

telnet stream tcp nowait NOLUID /local/etc/tcpd telnetd

shell stream tcp nowait NOLUID /local/etc/tcpd rshd

login stream tcp nowait NOLUID /local/etc/tcpd rlogind

exec stream tcp nowait NOLUID /local/etc/tcpd rexecd

finger stream tcp nowait nouser /local/etc/tcpd fingerd

#uucp stream tcp nowait NOLUID /local/etc/tcpd uucpd

#tftp dgram udp wait nouser /local/etc/tcpd tftpd




------------------------------------------------------------

Los servicios habilitados son: ftp, telnet, shell, login, exec, finger, y los deshabilitados (comentados con un '#' en el inicio) son: uucp y tftp.

Veamos brevemente la función de algunos de los servicios que maneja el inetd:

Servicios internos.

echo: Realiza un eco en la conexión, ósea todo lo que enviamos lo recibimos.

chargen:

Generador de caracteres, nos envía constantemente caracteres.

discard: Descarta, ósea no hace nada con lo que recibe y tampoco envía nada.

daytimeNos envía la fecha en formato legible por nosotros, por ejemplo: Wed Jun 14 10:32:20 2000.

timeNos envía la fecha en un formato ilegible para nosotros, pero si legible para otra computadora, es el numero de segundos transcurridos desde el primero de enero de 1900.

Nota: los cinco servicios anteriores se denominan internos, porque son atendidos por el mismo inetd, pueden ser todos desabilitados en la mayoría de los casos.

Servicios estandart.

ftp:Se utiliza para realizar a través de la red transferencias de archivos, con autentificacion mediante usuario y contraseña.

telnet:Se utiliza para obtener sesión remota, ósea una consola remota, con autentificacion mediante usuario y contraseña.

Protocolos BSD.

shell:Provee ejecución remota de comandos, con autentificacion basada en puertos privilegiados y hosts de confianza (trust).

login:Provee una sesión remota, con autentificacion basada en puertos privilegiados y hosts de confianza.

exec:Provee ejecución remota de comandos, con autentificacion basada en usuario y contraseña.

talk: Los dos siguientes se utilizan para conversar con otro usuario.

ntalk:




Servicios de información.

finger:Server que provee información remota, retorna un reporte de estado del sistema o de un usuario en particular.

ident:Escucha en determinados ports TCP y retorna el usuario que realiza la conexión.

tftpAmbos se utilizan normalmente como servidores de booteo, para PCs sin disco riguido.

bootps

Supongamos que queremos deshabilitar los siguientes servicios: shell, login, exec y finger, en el ejemplo anterior, el archivo inetd.conf nos quedara así: ------------------------------------------------------------ #:STANDARD: These are standard services. ftp stream tcp nowait NOLUID /local/etc/tcpd ftpdtelnet stream tcp nowait NOLUID /local/etc/tcpd telnetd#shell stream tcp nowait NOLUID /local/etc/tcpd rshd#login stream tcp nowait NOLUID /local/etc/tcpd rlogind#exec stream tcp nowait NOLUID /local/etc/tcpd rexecdf#inger stream tcp nowait nouser /local/etc/tcpd fingerd#uucp stream tcp nowait NOLUID /local/etc/tcpd uucpd#tftp dgram udp wait nouser /local/etc/tcpd tftpd

---------------------------------------------------------

ftp y telnet quedan habilitados para su uso.

Para que los cambios tengan efecto debemos reiniciar el inetd, para que vuelva a leer su archivo de configuración. Esto lo podemos realizar de la siguiente manera:

1- Hallamos el PID del inetd, con el siguiente comando:

# ps -ef | grep inetd

root 97 0.0 1.7 1292 536 ? S 10:54 0:00 inetd

El PID corresponde a la segunda columna, en este ejemplo es 97.

2- luego reiniciamos el inetd con el siguiente comando (con el usuario root):

# kill -9 97

Los servicios que normalmente se utilizan son : telnet y ftp.

Servicios que es recomendable deshabilidarlos (comentarlos): shell, login, exec, finger, ident, tftp, bootps.




Una vez deshabilitados los servicios que no vamos a utilizar, ahora debemos configurar de forma segu-ra los que utilizaremos.

El tcpd.Aquí se entenderá porque el ultimo campo del archivo inetd.conf es siempre /usr/sbin/tcpd seguido por el path del servidor.

La operación del inetd con el tcpd en conjunto, es la siguiente:

- Cuando inetd recibe un pedido por un servicio, en vez de ejecutar el programa servidor correspon-diente, ejecuta el tcpd y le pasa como parámetro el nombre del servidor correspondiente.

- El tcpd decide si permite el acceso o no al servicio, dependiendo de unas reglas de acceso y la direc-ción del cliente que lo solicita. Dichas reglas se encuentran en los archivos hosts.allow y hosts.deny en el directorio /etc.

- Si las reglas de acceso dicen que la computadora que solicitó el servicio no tiene acceso al mismo, re -chaza la petición. Si tiene acceso al servicio, el tcpd ejecuta el programa que brinda el servicio corres-pondiente y le entrega el control de la conexión.

- Por ultimo el programa servidor puede pedir usuario y contraseña para autentificar.

Se ve que el tcpd agrega un nivel más de seguridad mediante reglas de acceso, es intermediario entre el súper server (inetd) y el servidor correspondiente.

hosts.allow y hosts.deny.El archivo hosts.allow, indica las direcciones de las PCs o hosts que pueden acceder a un determinado servicio y hosts.deny indica las direcciones a las que se les niega el acceso a determinados servicios de red.

En cada linea de estos archivos se indica el nombre del o los programas servidores y la dirección o nombre de uno o varios hosts.

Por ejemplo: ftpd : 192.168.1.2

Si esto se encuentra en el archivo hosts.allow, le dice al tcpd que el host 192.168.1.2 puede acceder al servidor ftp. Si estuviera lo mismo en el archivo hosts.deny significa que le va a negar el acceso.

Veamos mas en detalle cada linea de estos archivos, están formadas de la siguiente manera :

daemon_list : client_list daemon_list: Lista de uno o mas nombres de procesos (daemons) sobre los cuales se aplica el acceso o no, dependiendo si esta en hosts.allow o hosts.deny. También puede ser la palabra ALL, que significa todos los procesos

Ejemplos:




ftpd telnetd ALL

client_list: Lista de uno a mas direcciones o nombres de hosts sobre los cuales se aplica el acceso o no, dependiendo si se encuentra en hosts.allow o hosts.deny. También puede ser la palabra ALL, que significa todos los hosts.

client_list puede tener alguna de las siguientes formas:

1-Una palabra que comienza con un '.' (punto). Todos los nombres de hosts que finalicen con ella, se les dejara acceder o no, depen-diendo si esta en hosts.allow o hosts.deny respectivamente.

Ejemplo .impsat.net.ar

mail.impsat.net.ar ns1.impsat.net.ar hosts12323.impsat.net.ar rdu1256.impsat.net.ar Todos estos cumplen con .impsat.net.ar

2- Una palabra que finaliza con un '.' (punto). Todas las direcciones ip que comiencen con dicha palabra, se les dejara acceder o no.

Ejemplo: 192.168.1. Regla valida para todas las IPs desde 192.168.1.0 hasta 192.168.1.255

3- Una expresión de la forma: n.n.n.n/m.m.m.m Donde n.n.n.n es la dirección de red y m.m.m.m es la mascara de red.

Ejemplo: 192.168.1.1/255.255.255.0 A todas las IPs desde 192.168.1.0 hasta 192.168.1.255 se les dejara acceder o no.

Los elementos que forman cada lista deben estar separados por espacios en blanco y/o comas.

Los pasos que realiza el tcpd con los archivos hosts.allow y hosts.deny son:

1- Lee el archivo hosts.allow y verifica si la dirección o nombre del host que trata de conectarse, tiene acceso al servicio. Si es así, ejecuta el servicio correspondiente y le da el control de la conexión, no lee el archivo hosts.deny.

2- Si en el paso anterior, no encontró el host, lee el archivo hosts.deny y busca la dirección o nombre del host. Si lo encuentra, rechaza la conexión.




3- Si en ninguno de los dos archivos encontró el nombre o dirección de host, le permite el acceso. Estos nos dice que nos conviene negar el acceso a todo en el hosts.deny y dar acceso a lo que nece-sitamos en el hosts.allow

Ejemplo 1:

Este ejemplo no tiene utilidad práctica, pero sirve para aclarar conceptos.

1- Editamos el inetd.conf y habilitamos el telnet.

2- Reiniciamos el inetd, como se indicó mas arriba.

3- Utilizamos la interfaz loopback para hacer algunas pruebas. Recordemos que esta interfaz es virtual, todo lo que enviamos por el loopback nos vuelve, en nuestro caso la utilizaremos para hacer pruebas como si estuviéramos en una red. Toda la red 127.x.x.x es el loopback, normalmente usamos la IP 127.0.0.1

Verificamos que en los archivos hosts.allow y hosts.deny no haya ninguna regla (todo comentado, o sea poner '#' al principio de las lineas).

4- Nos hacemos telnet a nosotros mismo:

# telnet 127.0.0.1

Trying 127.0.0.1...

Connected to 127.0.0.1.

Escape character is '^]'.

SCO OpenServer(TM) Release 5 (m01.fie.umich.mx) (ttyp4)

login:

Vemos que el tcpd nos dejo acceder, al servidor de telnet.

5- Editamos el hosts.deny y agregamos: ALL : ALL

Con eso negamos el acceso a todo. Hacemos telnet otra vez:

# telnet 127.0.0.1

Trying 127.0.0.1...

Connected to 127.0.0.1.

Escape character is '^]'.

Connection closed by foreign host.

Nos negó el acceso, funciona !




Ejemplo 2:

Continuamos configurando. Supongamos que nuestra PC se conecta a Internet y también tiene una tarjeta ethernet para conectarse a una red interna, con dirección 192.168.1.0 y mascara 255.255.255.0 Necesitamos que telnet y ftp estén habilitados para la red interna pero no para Internet.

Entonces los archivos nos quedan así: -Habilitamos telnet y ftp en inetd.conf: ftp stream tcp nowait NOLUID /local/etc/tcpd ftpdtelnet stream tcp nowait NOLUID /local/etc/tcpd telnetd

En hosts.deny negamos todo: ALL : ALL

En hosts.allow, damos permiso a los usuarios de la red interna para que accedan a ftp y telnet, colo-cando lo siguiente: in.ftpd, in.telnetd : 192.168.1.0/255.255.255.0

Listo !

Misceláneas.Aclaremos que no todos los servicios de red que esta brindando nuestra PC son manejados por inetd y tcpd. Por lo tanto son independientes de la configuración realizada.

Un ejemplo típico de servidores que no son manejados por inetd son: sendmail y apache, necesitaran su propia configuración para brindar su servicio en forma segura.

Para visualizar los servicios de red que están disponibles, podemos utilizar el siguiente comando:

# netstat -a | grep LISTEN tcp 0 0 *:printer *:* LISTEN tcp 0 0 *:www *:* LISTEN tcp 0 0 *:6000 *:* LISTEN tcp 0 0 *:smtp *:* LISTEN tcp 0 0 *:telnet *:* LISTEN tcp 0 0 *:sunrpc *:* LISTEN unix 1 [ ACC ] STREAM LISTENING 1808 /tmp/.X11-unix/X0 unix 1 [ ACC ] STREAM LISTENING 1293 /var/run/gpmctl unix 1 [ ACC ] STREAM LISTENING 1209 /dev/log

Los servicios de red son los que comienzan con tcp o udp.

los servicios que están disponibles, segun lo que nos dice el netstat en este ejemplo son:

printer www




6000 (Xserver) smtp telnet sunrpc

Supongamos que el servidor web (www) no es necesario para nuestro caso y lo queremos deshabilitar, lo que podemos hacer es:

- Desinstalar la aplicación que brinda el servicio (apache).

- Deshabilitar el servicio, mediante el script de arranque. En UNIX SCO existe un scipt por cada servicio que lo inicia, reinicia y detiene, ubicado en el directo-rio /etc/rc2.d

Existen directorios /etc/rcS.d, donde S es el nivel de ejecución, que contiene links simbólicos a estos scripts. Una forma de deshabilitarlos podría ser eliminando estos links simbólicos.

En los directorios /etc/rc.d/rcS.d donde S es el nivel de ejecución, se encuentran los links simbólicos a los scripts que inician o detienen servicios.

Por ejemplo, los archivos /etc/rc2.d se ejecutan en orden de acuerdo al segundo caracter del nombre. El primer carácter del nombre determina como se ejecutan los archivos al entrar al nivel 2:

K* scripts ejecutados en secuencia serie (ordenada) cuando se especifica stop a prc_sync (ADM)

S* scripts ejecutados en secuencia serie (ordenada) cuando se especifica start a prc_sync (ADM)

P* scripts que prc_sync (ADM) ejecuta en paralelo con otros scripts P* a los cuales es adyacente en orden

I* scripts interactivos para los cuales prc_sync (ADM) deberá esperar hasta que estos completen su ejecución y terminen

Los archivos que inicien con cualquier otro caracter son ignorados.

Algunos scripts importantes en /etc/rc2.d son:

P00SYSINIT corre los scripts /etc/rc.d/0* y /etc/rc.d/1*I01MOUNTFSYS monta los systemas de archivos, inicia la auditoría y ejecuta los scripts

/etc/rc.d/2* scripts P03RECOVERY ejecuta los scripts /etc/rc.d/3*P15HWDNLOAD ejecuta los scripts /etc/rc.d/5* P16KERNINIT ejecuta los scripts /etc/rc.d/6* P20sysetup genera el archivo ID del sistema (/etc/systemid) P70uucp elimina bloqueos uucp (C) , status, and archivos temporales P75cron inicia el demonio cron (C) P87USRDAEMON ejecuta los scripts /etc/rc.d/7* P88USRDEFINE ejecuta los scripts /etc/rc.d/8*



http://stage.caldera.com/cgi-bin/ssl_getmanpage?cron+C+OS5

http://stage.caldera.com/cgi-bin/ssl_getmanpage?uucp+C+OS5

http://stage.caldera.com/cgi-bin/ssl_getmanpage?prc_sync+ADM+OS5





P90RESERVED ejecuta los scripts /etc/rc.d/9*

Otra precaución fundamental es asegurarse que los servicios que necesitamos ejecutar no tengan pro-blemas de seguridad y que sean las últimas versiones.

Existen varios sitios web y listas de correo que nos alertan cuando se encuentran dichos problemas. Normalmente cada distribución UNIX o linux, en su sitio oficial publica las actualizaciones necesarias, por problemas de seguridad.

Auditd

El demonio auditd permite al administrador de un sistema Unix recibir la información de auditoría de seguridad que el kernel genera, a través del archivo /proc/audit, filtrarla y almacenarla en archivos. Esta información tiene el siguiente formato:

AUDIT CONNECT pid ruid shost sport dhost dport

Conexión desde el servidor al host remoto dhost.

AUDIT ACCEPT pid ruid shost sport dhost dport

Conexión desde el host remoto dhost al servidor.

AUDIT LISTEN pid ruid shost sport

El puerto indicado está esperando peticiones de servicio.

AUDIT OPEN pid ruid file

Se ha abierto el archivo file.

AUDIT SETUID pid old ruid ruid euid

Se ha llamado con éxito a setuid(), modificando el UID de ruid a euid.

AUDIT EXEC pid ruid file

Se ha ejecutado el archivo file.

AUDIT MODINIT pid ruid file

Se ha insertado en el kernel el módulo file. Al leer la información de /proc/audit, el demonio auditd lee las reglas de filtrado del archivo /etc/se-curity/audit.conf, comparando las flags, pid y ruid (Real User IDentifier) recibidos con cada una de las reglas del archivo de configuración, hasta encontrar la apropiada para tratar el evento. Una vez que




el demonio auditd ha encontrado el archivo donde almacenar la información recibida, la guarda en él con un formato legible. Este software se encuentra disponible en http://www.hert.org/projects/linux/auditd/.

Resumen

En este capítulo se tratado ciertos parámetros del kernel de varios sistemas Unix (Linux, HP-UX, Solaris, SCO) que pueden beneficiar (o arruinar) su seguridad, principalmente a nivel de red y de lími-tes de recursos (para prevenir ataques de negación de servicio, voluntarios o involuntarios, por parte de los usuarios). Aunque las bases de todos lo problemas suelen ser comunes a cualquier Unix, se ha particularizado la forma de evitarlos para algunos de los clones de Unix más utilizados; (se trata de información que puede cambiar entre versiones de un mismo sistema operativo), es indis-pensable consultar la documentación del sistema y asegurarse muy bien de lo que se está haciendo an-tes de reconfigurar un kernel, ya que un error puede ser fatal para el servidor. En la tabla 7.3 se presen-tan los parámetros vistos en este capítulo para los diferentes Unix; no se dan valores óptimos para cada uno de ellos, ya que el valor ideal viene dado por las características de cada sistema: cada administra-dor debe conocer lo que es habitual en sus servidores, para de esta forma detectar lo inusual y con ello los posibles problemas de seguridad que puedan existir en sus máquinas.




ARCHIVOS IMPORTANTES

El sistema de red del sistema operativo Unix se entiende como el conjunto de software que posibilita la interconexión entre diferentes computadoras (cliente-servidor o viceversa). Este software está dividido en dos partes: por un lado, tenemos el soporte de red dentro del kernel del sistema operativo, encarga-do de implementar las tareas de más bajo nivel necesarias para la comunicación entre sistemas, como la pila de protocolos tcp/ip o los controladores de tarjetas de red; por otro, en el espacio de usuario, te-nemos al conjunto de programas y archivos utilizados para configurar parámetros del sistema relacio-nados con la red, como la dirección IP, las tablas de ruteo, o el comportamiento de un servidor ante so-licitudes de servicio desde otros equipos conectados a el. En esta sección se va tratar exclusivamente del software (tanto utilidades como archivos) que de una u otra forma puede afectar a la seguridad glo-bal del servidor.

El archivo /etc/hosts

Este archivo se utiliza para obtener una relación entre un nombre de máquina y una dirección IP: en cada línea de /etc/hosts se especifica una dirección IP y el nombre de máquina que le corresponde, de forma que un usuario no tenga que recordar direcciones sino nombres de hosts. Habitualmente se sue-len incluir las direcciones, nombres y aliases de todos los equipos conectados a la red local, de forma que para comunicación dentro de la red no se tenga que recurrir a un DNS (Servidor de Nombres de Dominio) a la hora de resolver un nombre de máquina. La forma de una línea de este archivo es la si-guiente:

192.168.1.150portatil.seccion.mx portatil

Esto indica que será equivalente a la dirección 192.168.1.150 usar el nombre de la máquina, portatil. -seccion.mx, o el alias, portatil, cuando deseemos comunicarnos con este servidor:

Control de acceso

Este control de acceso a el servidor se lleva acabo a través de dos archivos localizados en /etc/ los cua-les son: hosts.deny y hosts.allow. Estos archivos contienen entradas permitiendo y negando acceso, respectivamente, para ciertos servicios y nodos. Cuando tcpd trata una peticion de un servicio como finger de un nodo cliente denominado pegasso.umich.mx, busca en hosts.allow y hosts.deny (en este orden) una entrada en la que el servicio y el nodo cliente coincidan. Si la entrada coincidente aparece en hosts.allow, se garantiza el acceso, sin importar lo que haya en hosts.deny. Si la coincidencia se en-cuentra en hosts.deny, la petición se rechazas cerrando la conexión. Si no hay coincidencia en ninguno, la petición es aceptada.

Las entradas en los archivos de acceso tienen la siguiente estructura:

lista servicios: lista nodos [:cmd_shell]

Donde:




listaservicios

Es una lista de nombres de servicios de /etc/services, o la palabra clave ALL. Para especificar todos los servicios excepto finger y tftp, usa ALL EXCEPT finger, tfp

lista nodos

Es una lista de nombres de nodos o direcciones IP, o las palabras clave ALL, LOCAL, o UNKNOWN. ALL hace coincidir todos los nodos mientras que LOCAL hace coincidir todos los nombres de nodos que no contengan un punto. UNKNOWN hace coincidir todos los nodos cuya busqueda de nombre o direccióon fallo. Un nombre comenzado por un punto incluye a todos los nodos cuyo dominio es el mismo a ese nombre. Por ejemplo, .umich.mx coincidirá con pegasso.umich.mx. Tambien hay formas de especificar direcciones de red IP y números de red. Por favor, refierase a la pagina del manual de hosts_access(5) para mas detalles.

Para negar acceso a los servicios finger y tftp a todos los nodos menos a los locales, ponga lo siguiente en /etc/hosts.deny, y deje /etc/hosts.allow vacio: in.tftpd, in.fingerd: ALL EXCEPT LOCAL, .su.dominio

cmd_shellEs un campo opcional, puede contener un comando de shell para que sea invocado cuando una busque-da coincida con la entrada. Esto es útil para establecer trampas que puedan delatar a atacantes poten-ciales:

in.ftpd: ALL EXCEPT LOCAL, .umich.mx : echo "peticion de %d@%h" ?? /var/log/finger.log; if [ %h != "pegasso.umich.mx" ]; then finger -l @%h ?? /var/log/finger.log fi

Los argumentos %h y %d son expandidos por tcpd al nombre del nodo cliente y al nombre del servi-cio, respectivamente.

El archivo /etc/servicesEL archivo services, lista de servicios de red, es un archivo ASCII que proporciona una corresponden-cia entre nombres textuales, cómodos, para los servicios de red y sus correspondientes números de puerto y tipos de protocolo yacentes. Todo programa de red debe leer este archivo para obtener el nú-mero de puerto (y protocolo) para su servicio.

En cada línea de este archivo se especifican el nombre, número de puerto, protocolo utilizado y alias, de todos los servicios de red existentes (o, si no de todos los existentes, de un conjunto lo suficiente -mente amplio para que ciertos programas de red funcionen correctamente). Por ejemplo, para especifi-




car que el servicio de smtp utilizará el puerto 25, el protocolo tcp y con un alias mail, existirá una lí-nea similar a la siguiente:

smtp 25/tcp mail

Las funciones getservent(3), getservbyname(3), getservbyport(3), setser-vent(3), y endservent(3) de la biblioteca de C permiten consultar este archivo desde un programa.

Los números de puerto son asignados por la IANA (Internet Assigned Numbers Authority: Autoridad para la Asignación de Números de Internet), y su política actual es la de asignar tanto los protocolos TCP y UDP cuando se asigna un número de puerto. Por tanto, la mayoría de las entradas tendrán dos líneas, incluso para los servicios que son exclusivos de TCP.

Los números de puerto por debajo de 1024 (los llamados "puertos de baja numeración" o puertos privi-legiados) sólo pueden ser enlazados por el superusuario. Esto es, para que los clientes que se conecten a los puertos de baja numeración y puedan confiar en que el servicio que se esta ofreciendo en el puer-to es una implementación estándar y verdadera y no un servicio falso ejecutado por algun atacante. Los números de puerto bien conocidos especificados por la IANA se localizan normalmente es este espacio exclusivo del root.

El archivo /etc/inetd.conf

Este archivo es el utilizado por el programa inetd, conocido como el demonio superservidor de red. El inetd es el encargado de ofrecer la mayoría de servicios de nuestro servidor hacia el resto de clientes, y por tanto debemos cuidar mucho su correcta configuración. En el capítulo siguiente hablaremos de có-mo restringir servicios, tanto ofrecidos por este demonio como servidos independientemente.

Cada línea (excepto las que comienza por #, que son tratadas como comentarios) del archivo /etc/ine-td.conf le indica a inetd cómo se ha de comportar cuando recibe una petición en cierto puerto; en cada una de ellas existen al menos seis campos (en algunos clones de Unix pueden ser más), cuyo significa-do es el siguiente:

Servicio

En este campo se indica el nombre del servicio; el nombre ha de existir en /etc/services para ser consi-derado correcto, o en /etc/rpc si se trata de servicios basados en el RPC (Remote Procedure Call) de Sun Microsystems. En este último caso se ha de acompañar el nombre del servicio con el número de versión RPC, separando ambos con el carácter /.

Socket

En este se indica el tipo de socket asociado a la conexión. Aunque dependiendo del clon de Unix utili -zado existen una serie de identificadores válidos, lo normal es que asociado al protocolo TCP se utili -cen sockets de tipo stream, mientras que si el protocolo es UDP (User Datagram Protocol) el tipo del socket sea dgram (datagrama).




Protocolo

Este es el campo del protocolo, debe ser un protocolo definido en /etc/protocols, generalmente TCP o UDP. Si se trata de servicios RPC, de nuevo hay que indicarlo utilizando RPC antes del nombre del protocolo, separado de él por el carácter /, al igual que sucedía con el nombre; por ejemplo, en este caso podríamos tener protocolos como rpc/tcp o rpc/udp.

Concurrencia

El campo de concurrencia sólamente es aplicable a sockets de tipo datagrama (dgram); el resto de tipos han de contener una entrada nowait en este campo. Si el servidor que ha de atender la petición es multihilo (es decir, puede atender varias peticiones simultáneamente), hemos de indicarle al sistema de red que libere el socket asociado a una conexión de forma que inetd pueda seguir aceptando peticiones en dicho socket; en este caso utilizaremos la opción nowait. Si por el contrario se trata de un servidor de un hilo (acepta peticiones de forma secuencial, hasta que no finaliza con una no puede escuchar la siguiente) especificaremos wait.

Especificar correctamente el modelo de concurrencia a seguir en un determinado servicio es muy im-portante para la seguridad del sistema, especialmente para prevenir ataques de negación de servicio (DoS). Si especificamos wait, inetd no podrá atender una petición hasta que no finalice el servicio de la actual, por lo que si este servicio es muy costoso la segunda petición no será atendida en un tiempo razonable (o incluso nunca, si inetd se queda bloqueado por cualquier motivo). Si por el contrario es-pecificamos nowait, el número de conexiones simultáneas quizás llegue a ser lo suficientemente gran-de como para degradar las prestaciones del sistema, lo que por supuesto no es conveniente para el sis-tema.

Para evitar ataques de este estilo, la mayoría de sistemas Unix actuales permiten especificar (junto a wait o nowait, separado de él por un punto) el número máximo de peticiones a un servicio durante un intervalo de tiempo (generalmente un minuto), de forma que si este número se sobrepasa inetd asume que alguien está intentando una negación de servicio contra él, por lo que deja de ofrecer ese servicio durante cierto tiempo (algunos clones de Unix incluso paran inetd, es conveniente consultar la docu-mentación en cada caso). Como evidentemente esto tambíen es una negación de servicio, algo muy común entre administradores es aprovechar las facilidades de planificación (cron) de Unix para enviar cada poco tiempo la señal sighup al demonio inetd, de forma que este vuelva a leer su archivo de con-figuración y funcione normalmente. Por ejemplo, para conseguir esto podemos agregar al archivo /usr/spool/cron/crontabs/root una línea como la siguiente:

00, 10, 20, 30, 40, 50 * * * * killall -HUP inetd

y ejecutar:

# crontab /usr/spool/cron/crontabs/root

Con esto conseguimos que inetd se reconfigure cada diez minutos.




Usuario

En este campo se indica el nombre de usuario bajo cuya identidad se ha de ejecutar el programa que atiende cada servicio; esto es así para poder lanzar servicios sin que posean los privilegios del root, con lo que un posible error en su funcionamiento no tenga consecuencias excesivamente graves. Para el grupo, se asume el grupo primario del usuario especificado, aunque se puede indicar un grupo diferen-te indicándolo junto al nombre, separado de éste por un punto.

Programa

Por último, en cada línea de /etc/inetd.conf se debe de indicar la ruta del programa encargado de servir cada petición que inetd recibe en un puerto determinado, junto a los argumentos de dicho programa. El servidor inetd es capaz de ofrecer pequeños servicios basado en TCP por sí mismo, sin necesidad de invocar a otros programas; ejemplos de este tipo de servicios son time, echo o chargen. En este caso, el valor de este campo ha de ser internal.

De esta forma, si en /etc/inetd.conf tenemos una línea como esta:

telnet stream tcp nowait root /usr/sbin/in.telnetd

inetd sabe que cuando reciba una petición al puerto telnet ha de abrir un socket tipo stream (el habi-tual para el protocolo TCP) y ejecutar fork() y exec() del programa /usr/sbin/in.telnetd, bajo laidentidad de root.

El archivo /etc/protocols

Es el archivo de definición de protocolos, el sistema de red en Unix utiliza un número especial, deno-minado número de protocolo, para identificar el protocolo de transporte específico que el servidor reci-be; esto permite al software de red decodificar correctamente la información recibida.En el archivo /etc/protocols se identifican todos los protocolos de transporte reconocidos junto a su número de protocolo y sus alias:

# /etc/protocols:# $Id: protocols,v 1.1.1.1 1999/12/27 21:11:58 chmouel Exp $## Internet (IP) protocols## from: @(#)protocols 5.1 (Berkeley) 4/17/89## Updated for NetBSD based on RFC 1340, Assigned Numbers (July 1992).

ip 0 IP # internet protocol, pseudo protocol numbericmp 1 ICMP # internet control message protocoligmp 2 IGMP # Internet Group Management




ggp 3 GGP # gateway-gateway protocolipencap 4 IP-ENCAP # IP encapsulated in IP (officially `IP'')st 5 ST # ST datagram modetcp 6 TCP # transmission control protocolegp 8 EGP # exterior gateway protocolpup 12 PUP # PARC universal packet protocoludp 17 UDP # user datagram protocolhmp 20 HMP # host monitoring protocolxns-idp 22 XNS-IDP # Xerox NS IDPrdp 27 RDP # "reliable datagram" protocoliso-tp4 29 ISO-TP4 # ISO Transport Protocol class 4xtp 36 XT P # Xpress Tranfer Protocolddp 37 DDP # Datagram Delivery Protocolidpr-cmtp 39 IDPR-CMTP # IDPR Control Message Transportipv6 41 IPv6 # IPv6ipv6-route 43 IPv6-Route # Routing Header for IPv6ipv6-frag 44 IPv6-Frag # Fragment Header for IPv6ipv6-crypt 50 IPv6-Crypt # Encryption Header for IPv6ipv6-auth 51 IPv6-Auth # Authentication Header for IPv6ipv6-icmp 58 IPv6-ICMP # ICMP for IPv6ipv6-nonxt 59 IPv6-NoNxt # No Next Header for IPv6ipv6-opts 60 IPv6-Opts # Destination Options for IPv6rspf 73 RSPF # Radio Shortest Path First.vmtp 81 VMTP # Versatile Message Transportospf 89 OSPFIGP # Open Shortest Path First IGPipip 94 IPIP # Yet Another IP encapsulationencap 98 ENCAP # Yet Another IP encapsulation

Este archivo no se debe modificar porque los cambios pueden producir paquetes IP incorrectos. Los números y nombres de los protocolos se definen en el DDN (Network Information Center). Por lo tan-to NO es recomendable que el administrador modifique este archivo; es el software de red el que lo va actualizando al ser instalado en el servidor.

El archivo /etc/networks

Este archivo, que esta cada vez más en desuso, permite asignar un nombre simbólico a las redes, de una forma similar a lo que /etc/hosts hace con los hosts. En cada línea del archivo se especifica un nombre de red, su dirección, y sus alias:

loopback 127.0.0.0 localnet 195.195.5.0




El uso de este archivo es casi exclusivo del arranque del sistema, cuando aún no dispone del servicio de un servidor de nombres; en la operación habitual del sistema no se suele utilizar, ya que ha sido des-plazado por el DNS.

El archivo /etc/ethers

Al igual que en /etc/hosts se estable una correspondencia entre nombres de hosts y sus direcciones IP, en este archivo se establece una correspondencia entre nombres de hosts y direcciones ethernet, en un formato muy similar al archivo /etc/hosts: 00:10:5A:AC:6F:89 portatil.seccon.umich.mx. En la actua-lidad el archivo /etc/ethers no se suele encontrar (aunque para el sistema sigue conservando su funcio-nalidad, es decir, si existe se tiene en cuenta) en casi ningun servidor Unix, ya que las direcciones har-dware se obtienen por ARP (Address Resolution Protocol).




AUDITORÍA DEL SISTEMA

La mayoría de las actividades realizadas en un sistema Unix son susceptibles de ser, en mayor o menor medida, monitoreadas: desde las horas de acceso de cada usuario al sistema hasta las páginas web más frecuentadas, pasando por los intentos fallidos o existosos de conexión, los programas ejecutados o in-cluso el tiempo de CPU que cada usuario consume. Obviamente esta facilidad de Unix para recoger información tiene unas ventajas inmediatas para la seguridad: es posible detectar un intento de ataque casi inmediatemente después de producirse el mismo, así como tambíen detectar usos indebidos de los recursos o actividades “'sospechosas”'; sin embargo, existen tambíen desventajas, ya que la gran canti-dad de información que potencialmente se registra puede ser aprovechada para crear negaciones de ser-vicio o más habitualmente, esa cantidad de información puede hacer difícil la detección de problemas por el volumen de datos a analizar.

Existe un punto muy interesante de los archivos log (bitacoras) en Unix, es que la mayoría de ellos son simples archivos de texto, que se pueden visualizar con un simple cat o un more. Por una parte esto es bastante cómodo para el administrador del sistema, ya que no necesita de herramientas especia-les para poder revisar los logs (aunque existen algunas utilidades para hacerlo, como swatch) e inclu-so puede programar shellscripts para generar informes de forma automática, con comandos como awk, grep o sed. No obstante, el hecho de que estos archivos sean texto plano hace que un atacante la tenga muy fácil para ocultar ciertos registros modificando los archivos con cualquier editor de textos; esto implica una cosa muy importante para un administrador: nunca ha de confiar al 100% en lo que los informes de auditoría del sistema le digan. Para minimizar estos riesgos se pueden tomar diversas medidas, desde algunas quizás demasiado complejas para entornos habituales hasta otras más sencillas pero igualmente efectivas, como utilizar una máquina fiable para registrar información del sistema o incluso enviar los registros más importantes a una impresora; más adelante se mencionan.

Sistema de bitacoras (logs) en Unix

Otra desventaja agregada al sistema de auditoría en Unix puede ser la complejidad que puede alcanzar una correcta configuración; por si la dificultad del sistema no fuera suficiente, en cada Unix el sistema de logs tiene peculiaridades que pueden propiciar la pérdida de información interesante de cara al mantenimiento de sistemas seguros. Aunque muchos de los archivos de log de los que hablaremos a continuación son comunes en cualquier sistema, su localización, o incluso su formato, pueden variar entre diferentes Unix.

Dentro de Unix hay dos grandes familias de sistemas: se trata de System V y BSD; la localización de archivos y ciertas comandos relativas a la auditoría del servidor van a ser diferentes en ellas, por lo que es muy recomendable consultar las páginas del manual antes de ponerse a configurar el sistema de au-ditoría en un equipo concreto. La principal diferencia entre ellos es el denominado process accounting o simplemente accounting, consiste en registrar todos los programas ejecutados por cada usuario; evi-dentemente, los informes generados en este proceso pueden llegar a ocupar muchísimo espacio en dis-co (dependiendo del número de usuarios en nuestro sistema) por lo que sólo es recomendable en situa-ciones muy concretas, por ejemplo para detectar actividades “'sospechosas”' en un servidor o para co-




brar por el tiempo de CPU consumido. En los sistemas System V el process accounting está desacti-vado por defecto; se puede iniciar mediante :

# /usr/lib/acct/accton /usr/adm/pacct /usr/adm/pacct es el archivo para almacenar los registros, sin este argumento el process accounting se desactiva. Para visualizar los informes se utiliza el comando acctcom.

Es un mundo aparte a la hora de generar (y analizar) informes acerca de las actividades realizadas so-bre un servidor Unix en los sistemas con el modelo de auditoría C2; mientras que con el modelo clási-co se genera un registro tras la ejecución de cada proceso, en Unix C2 se proporciona una pista de au-ditoría donde se registran los accesos y los intentos de acceso de una entidad a un objeto, así como cada cambio en el estado del objeto, por parte de la entidad o el sistema global. Esto se consigue asig-nando un identificador denominado Audit ID a cada grupo de procesos ejecutados (desde el propio login), identificador que se registra junto a la mayoría de llamadas al sistema que un proceso realiza, incluyendo algunas tan comunes como write(), open(), close() o read(). A nadie se le puede escapar la cantidad de espacio y de CPU necesarios para mantener los registros a un nivel tan preciso, por lo que en la mayoría de sistemas (especialmente en entornos habituales, como los mencionados aquí), el modelo de auditoría C2 es innecesario; y no sólo esto, sino que en muchas ocasiones tambíen se con-vierte en un monitoreo inútil, si no se dispone de mecanismos para interpretar o reducir la gran canti-dad de datos registrados: el administrador guarda tanta información que es casi imposible analizarla en busca de actividades sospechosas.

El demonio syslog

El demonio syslogd (Syslog Daemon) se lanza automáticamente al iniciar un sistema Unix, y es el en-cargado de guardar informes sobre el funcionamiento del servidor. Recibe mensajes de las diferentes partes del sistema (kernel, programas, etc.) y los envía y/o almacena en diferentes localizaciones, tanto locales como remotas, siguiendo un criterio definido en el archivo de configuración /etc/syslog.conf, donde especificamos las reglas a seguir para gestionar el almacenamiento de mensajes del sistema. Las líneas de este archivo que comienzan por “'#”' son comentarios, con lo cual son ignoradas de la misma forma que las líneas en blanco; si ocurriera un error al interpretar una de las líneas del archivo, se igno-rara la línea completa. Un ejemplo de /etc/syslog.conf es el siguiente:

# Log all kernel messages to the console.# Logging much else clutters up the screen.#kern.* /dev/console

# Log anything (except mail) of level info or higher.# Don't log private authentication messages!*.info;mail.none;news.none;authpriv.none /var/log/messages*.=info;*.=notice /var/log/messages# The authpriv file has restricted access.authpriv.* /var/log/secure




# Log all the mail messages in one place.mail.* /var/log/maillog

# Everybody gets emergency messages, plus log them on another# machine.*.emerg *

# Save mail and news errors of level err and higher in a# special file.uucp,news.crit /var/log/spooler*.=crit /var/log/critical

# Save boot messages also to boot.loglocal7.* /var/log/boot.log

# bitacora de tcpd (TCP-Wrappers)local0.info /var/log/tcpd.log

## INN#news.=crit /var/log/news/news.critnews.=err /var/log/news/news.errnews.notice /var/log/news/news.notice

Se puede ver que cada regla del archivo tiene dos campos: un campo de selección y un campo de ac-ción, separados por espacios o tabuladores. El campo de selección está formado a su vez de dos partes: una del servicio que envía el mensaje y otra de su prioridad, separadas por un punto (“'.”'); ambas son indiferentes a mayúsculas y minúsculas. La parte del servicio contiene una de las siguientes palabras clave: auth, auth-priv, cron, daemon, kern, lpr, mail, mark, news, security (equivalente a auth), sys-log, user, uucp y local0 hasta local7. Esta parte especifica el “'sistema”' que ha generado ese mensaje (por ejemplo, todos los programas relacionados con el correo generarán mensajes ligados al servicio mail).

El nivel de prioridad está compuesto de uno de los siguientes términos, en orden ascendente: debug, info, notice, warning, warn (equivalente a warning), err, error (equivalente a err), crit, alert, emerg, y panic (equivalente a emerg). La prioridad define la gravedad o importancia del mensaje almacenado. Todos los mensajes de la prioridad especificada y superiores son almacenados de acuerdo con la acción requerida.

Además de los términos mencionados hasta ahora, el demonio syslogd emplea los siguientes caracteres especiales:

* (asterisco)




Empleado como comodín para todas las prioridades y servicios anteriores, dependiendo de dónde son usados (si antes o después del carácter de separación “'.”'):

# Guardar todos los mensajes del servicio mail en /var/log/maillog# mail.* /var/log/maillog

verb''' verb' ' verb''' (blanco, espacio, nulo)

Indica que no hay prioridad definida para el servicio de la línea almacenada.

“',”' (coma)Con este carácter es posible especificar múltiples servicios con el mismo patrón de prioridad en una misma línea. Es posible enumerar cuantos servicios se quieran:

# Guardar todos los mensajes de error de mail, uucp y news y en # /var/log/spooluucp,news.crit /var/log/spooler

“';”' (punto y coma)

Es posible dirigir los mensajes de varios servicios y prioridades a un mismo destino, separándolos por este carácter:

# Guardamos los mensajes de prioridad "info" y "notice"# en el archivo /var/log/messages*.=info;*.=notice /var/log/messages

“'=“' (igual)

De este modo solo se almacenan los mensajes con la prioridad exacta especificada y no incluyendo las superiores:

# Guardar todos los mensajes criticos en /var/log/critical*.=crit /var/log/critical

“'!”' (exclamación cerrado)

Preceder el campo de prioridad con un signo de exclamación sirve para ignorar todas las prioridades, teniendo la posibilidad de escoger entre la especificada (!=prioridad) y la especificada más todas las superiores (!prioridad). Cuando se usan conjuntamente los caracteres “'=“' y “'!”', el signo de exclama-ción “'!”' debe preceder obligatoriamente al signo igual “'=“', de esta forma: !=

# Guardar mensajes del kernel de prioridad info, pero no de# prioridad err y superiores




# Guardar mensajes de mail excepto los de prioridad info kern.info;kern.!err /var/log/kernel-infomail.*;mail.!=info /var/log/mail

Por otra parte, el campo de acción describe el destino de los mensajes, que puede ser:

Un archivo plano

Normalmente los mensajes del sistema son almacenados en archivos planos. Dichos archivos han de estar especificados con la ruta de acceso completa (comenzando con “'/”').

Podemos preceder cada entrada con el signo menos, “'-”', para omitir la sincronización del archivo (va-ciado del buffer de memoria a disco). Aunque puede ocurrir que se pierda información si el sistema cae justo después de un intento de escritura en el archivo, utilizando este signo se puede conseguir una mejora importante en la velocidad, especialmente si estamos ejecutando programas que mandan mu-chos mensajes al demonio syslogd.

# Guardamos todos los mensajes de prioridad critica en "critical"*.=crit /var/log/critical

Una terminal (o la consola)

Tambíen tenemos la posibilidad de enviar los mensajes a terminales; de este modo podemos tener uno de los terminales virtuales que muchos sistemas Unix ofrecen en su consola “'dedicada”' a listar los mensajes del sistema, que podrán ser consultados con solo cambiar a esa terminal:

# Enviamos todos los mensajes a tty12 (ALT+F12 en Linux) y todos# los mensajes criticos del kernel a consola*.* /dev/tty12kern.crit /dev/console

Una tubería con nombre

Algunas versiones de syslogd permiten enviar registros a archivos de tipo pipe simplemente antepo-niendo el símbolo “'verb'|'“' al nombre del archivo; dicho archivo ha de ser creado antes de iniciar el demonio syslogd, mediante comandos como mkfifo o mknod. Esto es útil para debug y tambíen para procesar los registros utilizando cualquier aplicación de Unix, tal y como veremos al hablar de logs remotos cifrados.

Por ejemplo, la siguiente línea de /etc/syslog.conf enviaría todos los mensajes de cualquier prioridad a uno de estos archivos llamado /var/log/mififo:

# Enviamos todos los mensajes al pipe con nombre# /var/log/mififo*.* |/var/log/mififo




Un servidor remoto

Se pueden enviar los mensajes del sistema a otro servidor, de manera a que sean almacenados remota-mente. Esto es útil si tenemos un servidor seguro, en el que podemos confiar, conectado a la red, ya que de esta manera se guardaría allí una copia de los mensajes de nuestro sistema y no podrían ser mo-dificados en caso de que alguien entrase en nuestro servidor. Esto es especialmente útil para detectar usuarios ocultos en nuestro sistema (usuarios maliciosos que han conseguido los suficientes privilegios para ocultar sus procesos o su conexión):

# Enviamos los mensajes de prioridad warning y superiores al# archivo "syslog" y todos los mensajes (incluidos los# anteriores) a la maquina "pegasso-security.umich.mx"*.warn /usr/adm/syslog*.* @192.168.1.97

Los registros generados por syslog se almacenan en /var/adm/syslog de la máquina especificada.

Usuarios del sistema (si están conectados)

Se especifica la lista de usuarios que deben recibir un tipo de mensajes simplemente escribiendo su lo-gin, separados por comas:

# Enviamos los mensajes con la prioridad "alert" a root y rafael*.alert root, rafael

Todos los usuarios que estén conectados

Los errores con una prioridad de emergencia se suelen enviar a todos los usuarios que estén conectados al sistema, de manera que se den cuenta de que algo anda mal:

# Mostramos los mensajes urgentes a todos los usuarios# conectados, mediante wall*.=emerg *

Archivos de bitacoras

Dependiendo de la configuración del sistema de auditoría de cada equipoUnix los eventos que suce-dan en el servidor se registrarán en determinados archivos; aunque podemos loggear en cualquier ar-chivo (incluso a través de la red o en dispositivos, como veremos luego), existen ciertos archivos de re-gistro “'habituales”' en los que se almacena información. A continuación se explican los más comunes y la información que guardan. En La mayoría de Unix actuales (Linux, FreeBSD, OpenBSD) las bitá-coras se guardan en /var/log, pero en Unix más tradicionales (como Solaris, HP-UX, AIX) se guardan en /var/adm/




syslog

El archivo syslog (guardado en /var/adm/syslog) es quizás el archivo de log más importante del siste-ma; en él se guardan, en texto claro, mensajes relativos a la seguridad de la máquina, como los accesos o los intentos de acceso a ciertos servicios. Este archivo es escrito por syslogd, por lo que dependien-do de nuestro archivo de configuración encontraremos en el archivo una u otra información. Al estar guardado en formato texto, podemos visualizar su contenido con un simple cat o more:

Mar 19 10:51:44 pegasso snort[500]: IDS152 - PING BSD: 148.216.1.152 -¿148.216.250.2500Mar 19 13:04:16 pegasso snort[500]: IDS152 - PING BSD: 148.216.30.150 -¿148.216.250.250Mar 19 13:04:18 pegasso last message repeated 2 timesMar 19 13:07:46 pegasso snort[500]: IDS162 - PING Nmap2.36BETA:148.216.1.150 -¿ 148.216.1.90Mar 19 13:07:47 pegasso snort[500]: spp_portscan: PORTSCAN DETECTED from148.216.250.150 (THRESHOLD 4 connections exceeded in 0 seconds)Mar 19 13:07:48 pegasso snort[500]: ICMP Destination Unreachable:148.216.250.190 -¿ 148.216.1.150Mar 19 13:08:19 pegasso snort[500]: spp_portscan: portscan status from148.216.250.150: 62 connections across 1 hosts: TCP(61), UDP(1) STEALTHMar 19 13:08:19 pegasso snort[500]: ICMP Destination Unreachable:148.216.250.250 -¿ 148.216.8.78Mar 19 13:12:54 pegasso snort[500]: IDS162 - PING Nmap2.36BETA:148.216.250.150 -¿ 148.216.1.90Mar 19 13:12:55 pegasso snort[500]: spp_portscan: PORTSCAN DETECTED from148.216.250.150 (THRESHOLD 4 connections exceeded in 0 seconds)

messages

Este archivo almacena los mensajes de los servicios del sistema, utilerias y aplicaciones cuando fallan las llamadas al sistema. Para visualizar su contenido es suficiente con cat o similares:

# tail -15 /var/adm/messagesSpeed 100 Mbps%ethernet 0xDC00-0xDC1F 10 - type=2, addr=00:50:bf:16:1c:c4%cd-rom - - - type=IDE ctlr=sec cfg=mst dvr=Srom->wd%disk 0x01F0-0x01F7 14 - type=W0 unit=0 cyls=1024 hds=255 secs=63mem: total = 261184k, kernel = 13696k, user = 247488kswapdev = 1/41, swplo = 0, nswap = 96000, swapmem = 48000krootdev = 1/42, pipedev = 1/42, dumpdev = 1/41kernel: Hz = 100, i/o bufs = 6652k

Mon Aug 25 04:45:33 2003WARNING: portmapper on server 192.168.1.1 is not responding




Mon Aug 25 04:46:04 2003WARNING: portmapper on server 192.168.1.1 is not respondingMon Aug 25 04:46:35 2003WARNING: portmapper on server 192.168.1.1 is not responding

wtmp

Este es un archivo binario (no se puede leer su contenido directamente) que almacena información re-lativa a cada conexión y desconexión al sistema. Podemos ver su contenido con el comando last:

User Line Device PID Login time Elapsed Time Commentsroot p5 ttyp5 4317 Mon Aug 25 19:44 00:03 logged inroot c03 tty03 548 Mon Aug 25 19:17 00:30 logged inroot p5 ttyp5 4195 Mon Aug 25 19:13 00:28root p5 ttyp5 4008 Mon Aug 25 19:07 00:01root p5 ttyp5 3838 Mon Aug 25 18:49 00:07root p5 ttyp5 3813 Mon Aug 25 18:47 00:01root typ5 ttyp5 3779 Mon Aug 25 18:44 00:00root typ5 ttyp5 942 Mon Aug 25 05:04 00:02root typ5 ttyp5 930 Mon Aug 25 05:02 00:00root typ5 ttyp5 918 Mon Aug 25 05:01 00:00ftp ftp ftp2822 2822 Mon Aug 25 04:30 00:01root p3 ttyp3 2700 Mon Aug 25 04:15 15:32 logged inftp ftp ftp2689 2689 Mon Aug 25 04:13 00:07

utmp

El archivo utmp es tambien binario, contiene información de cada usuario que está conectado en un momento dado; el programa /bin/login genera un registro en este archivo cuando los usuarios se co-nectan, mientras que init lo elimina cuando desconecta. Aunque habitualmente este archivo está situa-do en /var/adm/, junto a otros archivos de log, es posible encontrar algunos Unix -los más antiguos- que lo situan en /etc/ Para visualizar el contenido de este archivo podemos utilizar los comandos last (indicando el nombre de archivo mediante la opción -w), w o who:

#last -w /var/adm/utmpUser Line Device PID Login time Elapsed Time Commentsroot p5 ttyp5 4317 Mon Aug 25 19:44 00:07 logged inroot p4 ttyp4 3436 Mon Aug 25 17:48 02:03 logged inroot p1 ttyp1 2134 Mon Aug 25 16:03 03:48 logged inroot p0 ttyp0 2071 Mon Aug 25 16:03 03:48 logged inroot c03 tty03 548 Mon Aug 25 19:17 00:34 logged insam co tty01 547 Mon Aug 25 19:52 00:00 logged inroot 02 tty02 1069 Mon Aug 25 16:03 03:48 logged in

sulog




Este archivo es de texto donde se registran las ejecuciones del comando su, indicando fecha, hora, usuario que ejecuta el programa y usuario cuya identidad adopta, terminal asociada y éxito (+) o fraca-so (-) de la operación, se guarda en /var/adm/sulog:

SU 12/27 07:41 + console root-rafaelSU 12/28 23:42 - vt01 rafael-rootSU 12/28 23:43 + vt01 rafael-rootSU 12/29 01:09 + vt04 rafael-root

cron

En este archivo se guardan todos los mensajes del servicio cron, el archivo se encuentra en /usr/lib/cron/log, se guarda tambien cierta información que es de utilidad como las tareas que se programaron para ser ejecutadas en determinada fecha y hora. Los archivos de las tareas que se ejecutan se encuen-tran en /usr/spool/cron/crontabs/username, un ejemplo del archivo log es el siguiente:

! *** cron started *** pid = 4509 Mon Aug 25 20:06:23 2003> CMD: /usr/lib/uucp/uudemon.hour > /dev/null> uucp 4542 c Mon Aug 25 20:09:00 2003< uucp 4542 c Mon Aug 25 20:09:00 2003! *** cron started *** pid = 286 Mon Aug 25 20:10:27 2003! *** cron started *** pid = 800 Mon Aug 25 20:19:26 2003! *** cron started *** pid = 872 Mon Aug 25 20:25:01 2003> CMD: date> root 940 c Mon Aug 25 20:30:00 2003< root 940 c Mon Aug 25 20:30:01 2003> CMD: (echo -n ' '; date; echo ) >/dev/console> sam 1020 c Mon Aug 25 20:38:00 2003< sam 1020 c Mon Aug 25 20:38:00 2003> CMD: /usr/lib/uucp/uudemon.hour > /dev/null> uucp 1038 c Mon Aug 25 20:39:00 2003> CMD: (echo -n ' '; date; echo ) >/dev/console

Bitacoras remotas

El demonio syslog permite fácilmente guardar registros en servidores remotos; de esta forma se pre-tende que, aunque la seguridad de un sistema se vea comprometida y sus logs sean modificados se puedan seguir registrando las actividades sospechosas en un servidor a priori seguro. Esto se consigue definiendo un LOGHOST en lugar de un archivo normal en el archivo /etc/syslogd.conf del servidor del que nos interesa guardar información; por ejemplo, si queremos registrar toda la información de prioridad info y notice en el servidor remoto pegasso, lo indicaremos de la siguiente forma:

*.=info;*.=notice @pegasso




Tras modificar /etc/syslogd.conf hacemos que el demonio lea su archivo de configuración enviandole la señal sighup o HUP (por ejemplo, con kill):

[root@portatil /root]# kill -HUP syslogd

Por su parte, en el host donde deseemos almacenar los logs, tenemos que definir el puerto de syslog en /etc/services y ejecutar syslogd con el parámetro -r para que acepte conexiones a través de la red:

root:~# grep syslog /etc/services syslog 514/udp root:~# ps aux | grep syslogd root 41 0.0 0.4 852 304 ? S Mar21 0:01 /usr/sbin/syslogd root:~# kill -TERM 41 root:~# syslogd -r

A partir de ese momento todos los mensajes generados en el servidor origen (portatil) se enviarán al servidor destino (pegasso) y se registrarán según las reglas de este, en un archivo o en un dispositivo (por ejemplo la cinta de respaldo; si suponemos que estas reglas, en nuestro caso, registran los mensa-jes de la prioridad especificada antes en /var/log/messages, en este archivo apareceran entradas del servidor que ha enviado la información:

root:~# tail /var/log/messages Mar 26 07:43:37 root syslogd 1.3-3: restart. Mar 26 07:43:46 rafael in.telnetd[7504]: connect from paricutin Mar 26 07:57:44 oracle in,ftpd[7606]: connect from zeus

Esto, que en muchas situaciones es muy recomendable, si no se realiza correctamente puede incluso comprometer la seguridad del servidor que guarda registros en otro equipo: por defecto, el tráfico se realiza en texto claro, por lo que cualquier atacante con un sniffer entre los dos servidores puede tener acceso a información importante que habría que mantener en secreto; imaginemos una situación muy habitual: un usuario que teclea su password cuando el sistema le pide el login. Evidentemente, esto generará un mensaje de error que syslogd registrará; este mensaje será similar a este (en Linux):

Mar 26 05:56:56 rafael login[6997]: invalid password for `UNKNOWN' on `ttyp5'from `paricutin'

Pero, ¿qué sucedería si en lugar de UNKNOWN el sistema almacenara el nombre de usuario que se ha introducido, algo que hacen muchos clones de Unix?. En esta situación el mensaje sería muy parecido al siguiente (Linux Red Hat 6.2):

Mar 23 04:59:15 pegasso login[3487]: FAILED LOGIN 1 FROM portatil FOR 5k4@b&-, User not known to the underlying authentication module

Como se puede ver se registraría una contraseña de usuario, contraseña que estamos enviando a la má-quina remota en texto claro a través de la red; evidentemente, es un riesgo que no podemos correr. -Quizás alguien pueda pensar que una clave por sí sola no representa mucho peligro, ya que el atacante




no conoce el nombre de usuario en el sistema. De ninguna forma: el atacante sólo tiene que esperar unos instantes, porque cuando el usuario teclee su login y su password correctamente (en principio, esto sucederá poco después de equivocarse, recordemos que el usuario trata de acceder a su cuenta) el sistema generará un mensaje indicando que ese usuario (con su nombre) ha entrado al sistema.

Para evitar este problema existen dos formas: una, registramos los logs en un equipo directamente co-nectado al nuestro, sin emitir tráfico al resto de la red; dos, utilizamos comunicaciones cifradas (por ejemplo con ssh) para enviar los registros a otro servidor. En el primer caso sólo necesitamos un equi-po con dos tarjetas de red, una por donde enviar el tráfico hacia la red local y la otra para conectar con la máquina donde almacenamos los logs, que sólo será accesible desde nuestro equipo y que no ha de tener usuarios ni ofrecer servicios; no es necesaria una gran potencia de cálculo: podemos aprovechar un viejo 386 o 486 con Linux o FreeBSD para esta tarea.

El segundo caso, utilizar comunicaciones cifradas para guardar registros en otro equipo de la red, re-quiere algo más de trabajo (nada del otro mundo); aquí no es estrictamente necesario que la máquina esté aislada del resto de la red, ya que la transferencia de información se va a realizar de forma cifrada, logrando que un potencial atacante no obtenga ningún dato comprometedor analizando el tráfico; evi-dentemente, aunque no esté aislado, es fundamental que el sistema donde almacenamos los logs sea seguro. Para enviar un log cifrado a una servidor remoto podemos utilizar, como hemos dicho antes, ssh unido a las facilidades que ofrece syslogd; si lo hacemos así, lo único que necesitamos es el servi -dor sshd en el servidor destino y el cliente ssh en la origen. Por ejemplo, imaginemos que queremos utilizar a portatil para almacenar una copia de los registros generados en pegasso conforme se vayan produciendo; en este caso vamos a enviar logs a una lista tipo fifo (primero en entrar, primero en salir) con nombre, desde donde los cifraremos con ssh y los enviaremos al sistema remoto a través de la red. Lo primero que necesitamos hacer es crear un archivo de tipo pipe (tubería) en el servidor ori-gen, por ejemplo con mknod o mkfifo:

pegasso:~# mknod /var/run/cifra p pegasso:~# chmod 0 /var/run/cifra pegasso:~# ls -l /var/run/cifra p--------- 1 root root 0 Apr 2 10:18 /var/run/cifra|

Este es el archivo al que enviaremos desde syslogd los registros que nos interesen, por ejemplo, los de prioridad warn; hemos de modificar /etc/syslog.conf para agregar una línea como la siguiente:

*.warn |/var/run/cifra

A continuación haremos que syslog relea su nueva configuración mediante la señal sighup:

pegasso:~# ps xua | grep syslog | grep -v grep pegasso 7877 0.0 0.2 1372 156 ? S 03:01 0:00 syslogd -m 0 pegasso:~# kill -HUP 7877

Una vez realizados estos pasos ya conseguimos que se registren los eventos que nos interesan en el ar-chivo /var/run/cifra; este archivo es una tubería con nombre, de forma que los datos que le enviamos no se graban en el disco, sino que sólo esperan a que un proceso lector los recoja. Ese proceso lector




será justamente el cliente ssh, encargado de cifrarlos y enviarlos al sistema remoto; para ello debemos ejecutar un comando como el siguiente:

cat /var/run/cifra | ssh -x portatil 'cat ¿¿/var/log/pegasso'

Si tenemos configurado ssh para que autentique sin clave podemos lanzar el proceso directamente en background; si tenemos que introducir la clave del root, una vez tecleada podemos parar el proceso y relanzarlo tambíen en segundo plano (esto es simplemente por comodidad, realmente no es necesario). Lo único que estamos haciendo con este mecanismo es cifrar lo que llega a la fifo y enviarlo de esta forma al sistema remoto, en el que se descifrará y se guardará en el archivo /var/log/pegasso. Es recomendale agregar unas líneas en los scripts de arranque de nuestro servidor para que este proce-so se lance automáticamente al iniciar el sistema; si lo hacemos así se debe de tener cuidado con la au-tenticación, ya que si ssh requiere una clave para conectar con el sistema remoto es probable que la máquina tarde más de lo normal en arrancar si un operador no está en la consola: justamente el tiempo necesario hasta que ssh produzca un timeout por no teclear el password de root en el sistema remo-to. Si al producirse el timeout el programa ssh no devuelve el control al shell, el sistema ni siquiera arrancará; de cualquier forma, si ese timeout se produce no estaremos registrando ningún evento en la otra máquina. Por supuesto, tambíen se debe prestar atención a otros problemas con la máquina destino que eviten que la conexión se produzca, con un número máximo de usuarios excedido o simplemente que ese sistema esté apagado.




FIREWALLS (CORTAFUEGOS)

Recuerde que TCP/IP está diseñado para proporcionar interconexión universal entre máquinas independientemente de las redes particulares a las cuales se conectan. La figura 10.1 muestra con detalle los procesos que ocurren cuando una máquina "Host A" y otra computadora "Host B" se comunican a través de una máquina intermedia denominada "Pasarela" o Gateway. Sin embargo el usuario ve a Internet como un red virtual única a la cual todas las máquinas están conectadas, a pesar de sus conexiones físicas. La figura 10-2 (a) muestra cómo el pensar en una internet en lugar de las redes que la constituyen (figura 10.2 (b)), simplifica los detalles y facilita al usuario la conceptualización de la comunicación. Además de las pasarelas (gateways) que interconectan redes físicas, el software de acceso a internet se necesita en cada uno de los hosts para permitir a los programas de aplicación usar internet como si fuera una red física real.

Figura 10.1. El principio de las capas cuando se utilizan pasarelas




Figura 10.2 (a) El punto de vista del usuario de una Internet TCP/IP(b) Estructura de las redes físicas y gateways que proporcionan la interconexión

Un firewall o cortafuegos es un sistema o grupo de sistemas que hace cumplir una política de control de acceso entre dos redes. De una forma más clara, podemos definir un cortafuegos como cualquier sistema (desde un simple router hasta varias redes en serie) utilizado para servicios y protocolos que desde el exterior puedan suponer una amenaza a la seguridad. El espacio protegido, denominado perí-metro de seguridad, suele ser propiedad de la misma organización, y la protección se realiza contra una red externa, no confiable, llamada zona de riesgo.

Evidentemente la forma de aislamiento más efectiva para cualquier política de seguridad consiste en el aislamiento físico, es decir, no tener conectada la máquina o la red a otros equipos o a Internet (figura 10.3 (A)). Sin embargo, en la mayoría de organizaciones. Los usuarios necesitan compartir informa-ción con otras personas situadas en muchas ocasiones a miles de kilómetros de distancia, con lo que no es posible un aislamiento total. El punto opuesto consistiría en una conectividad completa con la red (figura 10.3 (B)), lo que desde el punto de vista de la seguridad es muy problemático: cualquiera, des-de cualquier parte del mundo, puede potencialmente tener acceso a nuestros recursos. Un término me-dio entre ambas aproximaciones consiste en implementar cierta separación lógica mediante un corta-fuegos (figura 10.3 (C)).




Figura 10.3.- Esquema del cortafuegos

Antes de hablar de cortafuegos es casi obligatorio dar una serie de definiciones de partes o característi-cas de funcionamiento de un firewall; por máquina o host bastión (tambíen se denominan gates) se co-noce a un sistema especialmente asegurado, pero en principio vulnerable a todo tipo de ataques por es-tar abierto a Internet, que tiene como función ser el punto de contacto de los usuarios de la red interna de una organización con otro tipo de redes. El host bastión filtra tráfico de entrada y salida, y tambíen esconde la configuración de la red hacia fuera.

Por filtrado de paquetes entendemos la acción de denegar o permitir el flujo de tramas entre dos redes (por ejemplo la interna, protegida con el firewall, y el resto de Internet) de acuerdo a unas normas pre-definidas; aunque el filtro más elemental puede ser un simple router, trabajando en el nivel de red del protocolo OSI, esta actividad puede realizarse además en un puente o en una máquina individual. El filtrado tambíen se conoce como screening, y a los dispositivos que lo implementan se les denomina chokes; el choke puede ser la máquina bastión o un elemento diferente.

Un proxy es un programa (trabajando en el nivel de aplicación de OSI) que permite o niega el acceso a una aplicación determinada entre dos redes. Los clientes proxy se comunican sólo con los servidores proxy, que autorizan las peticiones y las envían a los servidores reales, o las deniegan y las devuelven a quien las solicitó.




Físicamente, en casi todos los cortafuegos existen al menos un choke y una máquina bastión, aunque tambíen se considera firewall a un simple router filtrando paquetes, es decir, actuando como choke; desde el punto de vista lógico, en el cortafuegos suelen existir servidores proxy para las aplicaciones que han de atravesar el sistema, y que se situan habitualmente en el host bastión. Tambíen se imple-menta en el choke un mecanismo de filtrado de paquetes, y en alguno de los dos elementos se suele si -tuar otro mecanismo para poder monitorizar y detectar la actividad sospechosa.

En esta sección hablaremos de los tipos de cortafuegos más habituales y de sus características, así como de las posibles políticas de seguridad que pueden implementar; tambíen comentaremos aspectos de dos de los cortafuegos más utilizados hoy en día: FW-1 y la herramienta de Linux ipchains. Los fi -rewalls son cada vez más necesarios en nuestras redes, pero todos los expertos recomiendan que no se usen en lugar de otras herramientas, sino junto a ellas; cualquier cortafuegos, desde el más simple al más avanzado, presenta dos gravísimos problemas de seguridad: por un lado, centralizan todas las me-didas en un único sistema, de forma que si éste se ve comprometido y el resto de nuestra red no está lo suficientemente protegido el atacante consigue amenazar a toda la red simplemente poniendo en jaque a una máquina. El segundo problema, relacionado con éste, es la falsa sensación de seguridad que un cortafuegos proporciona: generalmente un administrador que no disponga de un firewall va a preocu-parse de la integridad de todas y cada una de sus máquinas, pero en el momento en que instala el corta-fuegos y lo configura asume que toda su red es segura, por lo que se suele descuidar enormemente la seguridad de los equipos de la red interna. Esto, como acabamos de comentar, es un grave error, ya que en el momento que un pirata acceda a nuestro cortafuegos, recordemos que es un sistema muy ex-puesto a ataques externos, automáticamente va a tener la posibilidad de controlar toda nuestra red.

Además, esto ya no es un problema de los firewalls sino algo de sentido común, un cortafuegos evi-dentemente no protege contra ataques que no pasan por él: esto incluye todo tipo de ataques internos dentro del perímetro de seguridad, pero tambíen otros factores que a priori no deberían suponer un problema. El típico ejemplo de estos últimos son los usuarios que instalan sin permiso, sin conoci -miento del administrador de la red, y muchas veces sin pensar en sus consecuencias, un simple modem en sus PCs o estaciones de trabajo; esto, tan habitual en muchas organizaciones, supone la violación y la ruptura total del perímetro de seguridad, ya que posibilita accesos a la red no controlados por el cor-tafuegos. Otro problema de sentido común es la reconfiguración de los sistemas al pasarlos de una zona a otra con diferente nivel de seguridad, por ejemplo al mover un equipo que se encuentra en el área protegida a la DMZ (veremos más adelante lo que estas siglas significan); este acto, que en oca-siones no implica ni tan siquiera el movimiento físico del equipo, sino simplemente conectarlo en una toma de red diferente, puede ocasionar graves problemas de seguridad en nuestra organización, por lo que cada vez que un cambio de este estilo se produzca no sólo es necesaria la reconfiguración del siste-ma, sino la revisión de todas las políticas de seguridad aplicadas a esa máquina.

Características de diseño

Existen tres decisiones básicas en el diseño o la configuración de un cortafuegos; la primera de ellas, la más importante, hace referencia a la política de seguridad de la organización propietaria del firewall: evidentemente, la configuración y el nivel de seguridad potencial será distinto en una empresa que uti-lice un cortafuegos para bloquear todo el tráfico externo hacia el dominio de su propiedad (excepto, quizás, las consultas a su página web) frente a otra donde sólo se intente evitar que los usuarios inter-




nos pierdan el tiempo en la red, bloqueando por ejemplo todos los servicios de salida al exterior ex-cepto el correo electrónico. Sobre esta decisión influyen, aparte de motivos de seguridad, motivos ad-ministrativos de cada organismo.

La segunda decisión de diseño a tener en cuenta es el nivel de monitorización, redundancia y control deseado en la organización; una vez definida la política a seguir, hay que definir cómo implementarla en el cortafuegos indicando básicamente qué se va a permitir y qué se va a negar. Para esto existen dos aproximaciones generales: o bien se adopta una postura restrictiva (negamos todo lo que explícita-mente no se permita) o bien una permisiva (permitimos todo excepto lo explícitamente negado); evi-dentemente es la primera la más recomendable de cara a la seguridad, pero no siempre es aplicable de-bido a factores no técnicos sino humanos (esto es, los usuarios y sus protestas por no poder ejecutar tal o cual aplicación a través del firewall).

Por último, la tercera decisión a la hora de instalar un sistema de cortafuegos es meramente cómica: en función del valor estimado de lo que deseemos proteger,debemos gastar más o menos dinero, o no gastar nada. Un firewall puede no entrañar gastos extras para la organización, o suponer un desembol-so de varios miles de pesos: seguramente un departamento o laboratorio con pocos equipos en su inte-rior puede utilizar un PC con Linux, Solaris o FreeBSD a modo de cortafuegos, sin gastarse nada en él (excepto unas horas de trabajo y unas tazas de café), pero esta aproximación evidentemente no funcio-na cuando el sistema a proteger es una red de tamaño considerable; en este caso se pueden utilizar sis-temas propietarios, que suelen ser caros, o aprovechar los routers de salida de la red, algo más barato pero que requiere más tiempo de configuración que los cortafuegos sobre Unix en PC de los que he-mos hablado antes. De cualquier forma, no es recomendable a la hora de evaluar el dinero a invertir en el firewall fijarse sólo en el coste de su instalación y puesta a punto, sino tambíen en el de su manteni -miento.

Estas decisiones, aunque concernientes al diseño, eran básicamente políticas; la primera decisiónc téc-nica a la que nos vamos a enfrentar a la hora de instalar un cortafuegos es elemental: ¿dónde lo situa-mos para que cumpla eficientemente su cometido?. Evidentemente, si aprovechamos como cortafuegos un equipo ya existente en la red, por ejemplo un router, no tenemos muchas posibilidades de elección: con toda seguridad hemos de dejarlo donde ya está; si por el contrario utilizamos una máquina Unix con un cortafuegos implementado en ella, tenemos varias posibilidades para situarla con respecto a la red externa y a la interna. Sin importar donde situemos al sistema hemos de recordar siempre que los equipos que queden fuera del cortafuegos, en la zona de riesgo, serán igual de vulnerables que antes de instalar el firewall; por eso es posible que si por obligación hemos tenido que instalar un cortafuegos en un punto que no protege completamente nuestra red, pensemos en añadir cortafuegos internos den-tro de la misma, aumentando así la seguridad de las partes más importantes.

Una vez que hemos decidido dónde situar nuestro cortafuegos se debe elegir qué elemento o elemen-tos físicos utilizar como bastión; para tomar esta decisión existen dos principios básicos: mínima com-plejidad y máxima seguridad. Cuanto más simple sea el host bastión, cuanto menos servicios ofrezca, más fácil será su mantenimiento y por tanto mayor su seguridad; mantener esta máquina especialmente asegurada es algo vital para que el cortafuegos funcione correctamente, ya que va a soportar por sí sola todos los ataques que se efectúen contra nuestra red al ser elemento más accesible de ésta. Si la seguri-dad de la máquina bastión se ve comprometida, la amenaza se traslada inmediantamente a todos los equipos dentro del perímetro de seguridad. Suele ser una buena opción elegir como máquina bastión




un servidor corriendo alguna versión de Unix (desde una sparc con Solaris a un simple PC con Linux o FreeBSD), ya que aparte de la seguridad del sistema operativo tenemos la ventaja de que la mayor par-te de aplicaciones de firewalling han sido desarrolladas y comprobadas desde hace años sobre Unix. Evidentemente, a la vez que elegimos un bastión para nuestro cortafuegos hemos de decidir qué ele-mento utilizar como choke; generalmente suele ser un router con capacidad para filtrar paquetes, aun-que tambíen puede utilizarse un sistema Unís para realizar esta función. Más adelante se comentan di-ferentes arquitecturas de cortafuegos con los elementos utilizados en cada una de ellas como chokes y como bastiones.

Ya hemos decidido qué utilizar como firewall y dónde situarlo; una vez hecho esto hemos de imple-mentar sobre él los mecanismos necesarios para hacer cumplir nuestra política de seguridad. En todo cortafuegos existen tres componentes básicos para los que debemos implementar mecanismos: El fil-trado de paquetes, el proxy de aplicación y la monitorización y detección de actividad sospechosa. Va-mos a hablar a continuación de cada uno de estos componentes.

Componentes de un cortafuegos

Filtrado de paquetes

Cualquier router ip utiliza reglas de filtrado para reducir la carga de la red; por ejemplo, se descartan paquetes cuyo ttl ha llegado a cero, paquetes con un control de errores erróneos, o simplemente tramas de broadcast. Además de estas aplicaciones, el filtrado de paquetes se puede utilizar para implementar diferentes políticas de seguridad en una red; el objetivo principal de todas ellas suele ser evitar el acce-so no autorizado entre dos redes, pero manteniendo intactos los accesos autorizados. Su funcionamien-to es habitualmente muy simple: se analiza la cabecera de cada paquete, y en función de una serie de reglas establecidas de antemano la trama es bloqueada o se le permite seguir su camino; estas reglas suelen contemplar campos como el protocolo utilizado (tcp, udp, icmp, etc.), las direcciones fuente y destino, y el puerto destino. Además de la información de cabecera de lasctramas, algunas implementa-ciones de filtrado permiten especificar reglas basadas en la interfaz del router por donde se ha de reen-viar el paquete, y tambíen en la interfaz por donde ha llegado hasta nosotros.

¿Cómo se especifican tales reglas? Generalmente se expresan como una simple tabla de condiciones o acciones que se consulta en orden hasta encontrar una regla que ermita tomar una decisión sobre el bloqueo o el reenvío de la trama; adicionalmente, ciertas implementaciones permiten indicar si el blo-queo de un paquete se notificará a la máquina origen mediante un mensaje icmp. Siempre hemos de te-ner presente el orden de análisis de las tablas para poder implementar la política de seguridad de una forma correcta; cuanto más complejas sean las reglas y su orden de análisis, más difícil será para el ad-ministrador comprenderlas. Independientemente del formato, la forma de generar las tablas dependerá obviamente del sistema sobre el que trabajemos, por lo que es indispensable consultar su documenta-ción; algunos ejemplos particulares, pero aplicables a otros sistemas, pueden encontrarse en (routers NetBlazer), (routers Cisco), (TISInternet Firewall Toolkit sobre Unix) y tambíen en la obra indispen-sable al hablar de cortafuegos:(screend, NetBlazer, Livingston y Cisco).

Por ejemplo, imaginemos una hipotética tabla de reglas de filtrado de la siguiente forma:




Origen & Destino & Tipo & Puerto & Acción hline158.43.0.0 & * & * & * & Deny * & 195.53.22.0 & * & * & Deny158.42.0.0 & * & * & * & Allow * & 193.22.34.0 & * & * & Deny

Si al cortafuegos donde está definida la política anterior llegara un paquete proveniente de una máqui-na de la red 158.43.0.0 se bloquearía su paso, sin importar el destino de la trama; de la misma forma, todo el tráfico hacia la red 195.53.22.0 tambíen se detendría. Pero, ¿qué sucedería si llega un paquete de un sistema de la red 158.42.0.0 hacia 193.22.34.0?. Una de las reglas nos indica que dejemos pasar todo el tráfico proveniente de 158.42.0.0, pero la siguiente nos dice que si el destino es 193.22.34.0 lo bloqueemos sin importar el origen. En este caso depende de nuestra implementación particular y el or-den de análisis que siga: si se comprueban las reglas desde el principio, el paquete atravesaría el corta-fuegos, ya que al analizar la tercera entrada se finalizarían las comprobaciones; si operamos al revés, el paquete sebloquearía porque leemos antes la última regla. Como podemos ver, ni siquiera en nuestra tabla, muy simple, las cosas son obvias, por lo que si extendemos el ejemplo a un firewall real pode-mos hacernos una idea de hasta que punto hemos de ser cuidadosos con el orden de las entradas de nuestra tabla.

¿Qué sucedería si, con la tabla del ejemplo anterior, llega un paquete que no cumple ninguna de nues-tras reglas?. El sentido común nos dice que por seguridad se debería bloquear, pero esto no siempre su-cede así; diferentes implementaciones ejecutan diferentes acciones en este caso. Algunas deniegan el paso por defecto, otras aplican el contario de la última regla especificada (es decir, si la última entrada era un Allow se niega el paso de la trama, y si era un Deny se permite), otras dejan pasar este tipo de tramas. De cualquier forma, para evitar problemas cuando uno de estos datagramas llega al cortafue-gos, lo mejor es insertar siempre una regla por defecto al final de nuestra lista, recordemos una vez más la cuestión del orden, con la acción que deseemos realizar por defecto; si por ejemplo deseamos bloquear el resto del tráfico que llega al firewall con la tabla anterior, y suponiendo que las entradas se analizan en el orden habitual, podríamos añadir a nuestra tabla la siguiente regla:

Origen Destino Tipo Puerto Accion * * * * Deny

La especificación incorrecta de estas reglas constituye uno de los problemas de seguridad habituales en los cortafuegos de filtrado de paquetes; no obstante, el mayor problema es que un sistema de filtrado de paquetes es incapaz de analizar (y por tanto verificar) datos situados por encima del nivel de red OSI. A esto se le suma el hecho de que si utilizamos un simple router como filtro, las capacidades de registro de información del mismo suelen ser bastante limitadas, por lo que en ocasiones es difícil la detección de un ataque; se puede considerar un mecanismo de prevención más que de detección. Para intentar solucionar estas, y otras vulnerabilidades, es recomendable utilizar aplicaciones software capa-ces de filtrar las conexiones a servicios; a dichas aplicaciones se les denomina proxies de aplicación, y las vamos a comentar en el punto siguiente.

Proxy de aplicación




Además del filtrado de paquetes, es habitual que los cortafuegos utilicen aplicaciones software para reenviar o bloquear conexiones a servicios como finger, telnet o ftp; a tales aplicaciones se les denomi-na servicios proxy, mientras que a la máquina donde se ejecutan se le llama pasarela de aplicación. Los servicios proxy poseen una serie de ventajas de cara a incrementar nuestra seguridad ([WC94]); en primer lugar, permiten únicamente la utilización de servicios para los que existe un proxy, por lo que si en nuestra organización la pasarela de aplicación contiene únicamente proxies para telnet, http y ftp, el resto de servicios no estarán disponibles para nadie. Una segunda ventaja es que en la pasarela es posible filtrar protocolos basándose en algo más que la cabecera de las tramas, lo que hace posible por ejemplo tener habilitado un servicio como ftp pero con órdenes restringidas (podríamos bloquear todos los comandos put para que nadie pueda ir ficheros a un servidor). Además, los application gateways permiten un grado de ocultación de la estructura de la red protegida (por ejemplo, la pasarela es el úni-co sistema cuyo nombre está disponible hacia el exterior), facilita la autenticación y la auditoría del tráfico sospechoso antes de que alcance el host destino y, quizás más importante, simplifica enorme-mente las reglas de filtrado implementadas en el router (que como hemos dicho antes pueden conver-tirse en la fuente de muchos problemas de seguridad): sólo hemos de permitir el tráfico hacia la pasare-la, bloqueando el resto.

El principal inconveniente que encontramos a la hora de instalar una pasarela de aplicación es que cada servicio que deseemos ofrecer necesita su propio proxy; además se trata de un elemento que frecuente-mente es más caro que un simple filtro de paquetes, y su rendimiento es mucho menor (por ejemplo, puede llegar a limitar el ancho de banda efectivo de la red, si el análisis de cada trama es costoso). En el caso de protocolos cliente/servidor (como telnet) se añade la desventaja de que necesitamos dos pa-sos para conectar hacia la zona segura o hacia el resto de la red; incluso algunas implementaciones ne-cesitan clientes modificados para funcionar correctamente.

Una variante de las pasarelas de aplicación la constituyen las pasarelas de nivel de circuito (Circuit le-vel Gateways), sistemas capaces de redirigir conexiones (reenviando tramas) pero que no pueden pro-cesar o filtrar paquetes en base al protocolo utilizado; se limitan simplemente a autenticar al usuario (a su conexión) antes de establecer el circuito virtual entre sistemas. La principal ventaja de este tipo de pasarelas e s que proveen de servicios a un amplio rango de protocolos; no obstante, necesitan software especial que tenga las llamadas al sistema clásicas sustituidas por funciones de librería seguras, como socks.

Monitorización de la actividad

Monitorizar la actividad de nuestro cortafuegos es algo indispensable para la seguridad de todo el perí-metro protegido; la monitorización nos facilitará información sobre los intentos de ataque que estemos sufriendo (origen, franjas horarias, tipos de acceso, etc.), así como la existencia de tramas que aunque no supongan un ataque a priori sí que son al menos sospechosas, para hacernos una idea de que tipo de tramas `extra nas' se pueden llegar a detectar.

¿Qué información debemos registrar?. Además de los registros estándar (los que incluyen estadísticas de tipos de paquetes recibidos, frecuencias, o direcciones fuente y destino) recomienda auditar infor-mación de la conexión (origen y destino, nombre de usuario, recordemos el servicio ident, hora y dura-ción), intentos de uso de protocolos denegados, intentos de falsificación de dirección por parte de má-




quinas internas al perímetro de seguridad (paquetes que llegan desde la red externa con la dirección de un equipo interno) y tramas recibidas desde routers desconocidos.

Evidentemente, todos esos registros han de ser leidos con frecuencia, y el administrador de la red ha de tomar medidas si se detectan actividades sospechosas; si la cantidad de logs generada es considerable nos puede interesar el uso de herramientas que filtren dicha información.

Un excelente mecanismo para incrementar mucho nuestra seguridad puede ser la sustitución de servi-cios reales en el cortafuegos por programas trampa. La idea es sencilla: se trata de peque nas aplicacio-nes que simulan un determinado servicio, de forma que un posible atacante piense que dicho servicio está habilitado y prosiga su ataque, pero que realmente nos están enviando toda la información posible sobre el pirata. Este tipo de programas, una especie de troyano, suele tener una finalidad múltiple: aparte de detectar y notificar ataques, el atacante permanece entretenido intentando un ataque que cree factible, lo que por un lado nos beneficia directamente, esa persona no intenta otro ataque quizás más peligroso, y por otro nos permite entretener al pirata ante una posible traza de su conexión. Evidente-mente, nos estamos arriesgando a que nuestro atacante descubra el mecanismo y lance ataques más pe-ligrosos, pero como el nivel de conocimientos de los atacantes de redes habituales en general no es muy elevado (más bien todo lo contrario), este mecanismo nos permite descubrir posibles exploits uti-lizados por los piratas, observar a qué tipo de atacantes nos enfrentamos, e incluso divertirnos con ellos.

Arquitecturas de cortafuegos

Cortafuegos de filtrado de paquetes

Un firewall sencillo puede consistir en un dispositivo capaz de filtrar paquetes, un choke; se trata del modelo de cortafuegos más antiguo, basado simplemente en aprovechar la capacidad de algunos rou-ters para bloquear o filtrar paquetes en función de su protocolo, su servicio o su dirección IP de forma que el router actue como gateway de la red. Los accesos desde la red interna al exterior no bloqueados son directos (no hay necesidad de utilizar proxies, como sucede en los cortafuegos basados en una má-quina con dos tarjetas de red), por lo que esta arquitectura esla más simple de implementar y la más utilizada en organizaciones que no precisan grandes niveles de seguridad, como las que vemos aquí.

No obstante, elegir un cortafuegos tan sencillo puede no ser recomendable en ciertas situaciones, o para organizaciones que requieren una mayor seguridad para su red, ya que los simples chokes presen-tan más desventajas que beneficios para la red protegida. El principal problema es que no disponen de un sistema de monitorización sofisticado, por lo que muchas veces el administrador no puede determi-nar si el router está siendo atacado o si su seguridad ha sido comprometida. Además las reglas de fil-trado pueden llegar a ser complejas de establecer, y por tanto es difícil comprobar su corrección: habi-tualmente sólo se comprueba a través de pruebas directas, con los problemas de seguridad que esto puede implicar.

Si a pesar de esto decidimos utilizar un router como filtro de paquetes, es recomendable bloquear todos los servicios que no se utilicen desde el exterior (especialmente NIS, NFS, X-Window y TFTP), así




como el acceso desde máquinas no confiables hacia nuestra red; es tambíen importante para la seguri-dad bloquear los paquetes con encaminamiento en origen activado.

Dual-Homed Host

El segundo modelo de cortafuegos estaba formado por simples máquinas Unix equipadas con dos tar-jetas de red y denominadas anfitriones de dos bases, en las que una de las tarjetas se suele conectar a la red interna a proteger, y la otra a la red externa a la organización. En esta configuración el choke y el bastión coinciden en elmismo equipo: la máquina Unix.

El sistema Unix ha de ejecutar al menos un servidor proxy para cada uno de los servicios que desee-mos pasar a través del cortafuegos, y tambíen es necesario que el IP Forwarding esté deshabilitado en el equipo: aunque una máquina con dos tarjetas puede actuar como un router, para aislar el tráfico en-tre la red interna y la externa es necesario que el choke no enrute paquetes entre ellas. Todo el inter-cambio de datos entre las redes se ha de realizar a través de servidores proxy situados en el host bas-tión, o bien permitiendo a los usuarios conectar directamente al mismo (algo muy poco recomendable, ya que un usuario que consiga aumentar su nivel de privilegios en el sistema puede romper toda la pro-tección del cortafuegos, por ejemplo reactivando el IP Forwarding).

Screened Host

Un paso más en términos de seguridad de los cortafuegos es la arquitectura screened host o choke-gate, que combina un router con un host bastión, y donde el principal nivel de seguridad proviene del filtra-do de paquetes. En la máquina bastión, único sistema accesible desde el exterior, se ejecutan los pro-xies de las aplicaciones, mientras que el choke se encarga de filtrar los paquetes que se puedan consi-derar peligrosos para la seguridad de la red interna, permitiendo únicamente la comunicación con un reducido número de servicios.

Pero, ¿dónde situar el sistema bastión, en la red interna o en el exterior del router? La mayoría de auto -res recomiendan situar el router entre la red exterior y el host bastión, pero otros defienden justo lo contrario: situar el bastión en la red exterior no provoca aparentemente una degradación de la seguri-dad, y además ayuda al administrador a comprender la necesidad de un elevado nivel de fiabilidad en esta máquina, ya que está sujeta a ataques externos y no tiene por qué ser un host fiable; de cualquier forma, asumiremos la primera opción por considerarla mayoritaria entre los expertos en seguridad in-formática. De esta forma, cuando una máquina de la red interna desea comunicarse con el exterior ha de hacerlo a través de servidores proxy situados en el host bastión, y los usuarios externos sólo pueden acceder a la red interna tambíen a través de este sistema.

Screened net (DMZ)

La arquitectura Screened net, tambíen conocida como red perimétrica o De-Militarized Zone (DMZ) añade un nivel de seguridad en las arquitecturas de cortafuegos situando una red (DMZ) entre las redes externa e interna, de forma que se consiguen reducir los efectos de un ataque exitoso al host bastión: en los modelos anteriores toda la seguridad se centraba en el bastión, de forma que si la seguridad del




mismo se veía comprometida, la amenaza se extendía automáticamente al resto de la red. Como la má-quina bastión es un objetivo interesante para muchos piratas, la arquitectura DMZ intenta aislarla en una red perimétrica de forma que un intruso que accede a esta máquina no consiga un acceso total a la red protegida.

Screened net es la arquitectura más segura, pero tambíen la más compleja; se utilizan dos routers, de-nominados exterior e interior, conectados ambos a la red perimétrica como se muestra en la figura 10.4. En esta red perimétrica, que constituye el sistema cortafuegos, se incluye el host bastión y tam-bíen se podrían incluir sistemas que requieran un acceso controlado, como baterías de módems o el servidor de correo, que serán los únicos elementos visibles desde fuera de nuestra red. El router exte-rior tiene como misión bloquear el tráfico no deseado en ambos sentidos (hacia la red perimétrica y ha-cia la red externa), mientras que el interior hace lo mismo pero con el tráfico entre la red interna y l a perimétrica; de esta forma, un atacante habría de romper la seguridad de ambos routers para acceder a la red protegida. Incluso es posible si se desean mayores niveles niveles de seguridad definir varias re-des perimétricas en serie, situando los servicios que requieran de menor fiabilidad en las redes más ex-ternas; así, el atacante habrá de saltar por todas y cada una de ellas para acceder a nuestros equipos. Evidentemente, si en cada red perimétrica se siguen las mismas reglas de filtrado, niveles adicionales no proporcionan mayor seguridad. Aunque, como hemos dicho antes, la arquitectura DMZ es la que mayores niveles de seguridad puede proporcionar, no se trata de la panacea de los cortafuegos. Eviden-temente existen problemas relacionados con este modelo: por ejemplo, se puede utilizar el firewall para que los servicios fiables pasen directamente sin acceder al bastión, lo que puede dar lugar a un in-cumplimiento de la política de la organización. Un segundo problema, quizás más g rave, es que la mayor parte de la seguridad reside en los routers utilizados; como hemos dicho antes las reglas de fil -trado obre estos elementos pueden ser complicadas de configurar y comprobar, lo que puede dar lugar a errores que abran importantes brechas de seguridad en nuestro sistema.




Figura 10.4 Arquitectura Screening Net (DMZ)

Otras arquitecturas

Algo que puede incrementar en gran medida nuestra seguridad y al mismo tiempo facilitar la adminis-tración de los cortafuegos es utilizar un bastión diferente para cada protocolo o servicio en lugar de uno sólo; sin embargo, esta arquitectura presenta el grave inconveniente de la cantidad de máquinas necesarias para implementar el firewall, lo que impide que muchas organizaciones la puedan adoptar. Una variante más barata consistiría en utilizar un único bastión pero servidores proxy diferentes para cada servicio ofertado. Cada día es más habitual en todo tipo de organizaciones dividir su red en dife-rentes redes; esto es especialmente aplicable en entornos universitarios, empresas medianas, donde con frecuencia se han de conectar campus o sucursales separadas geográficamente, edificios o laboratorios diferentes, etc. En esta situación es recomendable incrementar los niveles de seguridad de las zonas más comprometidas (por ejemplo, un servidor donde se almacenen expedientes o datos administrativos del personal) insertando cortafuegos internos entre estas zonas y el resto de la red. Aparte de incremen-tar la seguridad, firewalls internos son especialmente recomendables en zonas de la red desde la que no se permite a priori la conexión con Internet, como laboratorios de prácticas: un simple PC con Linux o FreeBSD que niegue cualquier conexión con el exterior del campus va a ser suficiente para evitar que los usuarios se dediquen a conectar a páginas web o chats desde equipos no destinados a estos usos. Concretamente en el caso de redes de universidades sería muy interesante filtrar las conexiones a irc o a muds, ya sea a nivel de aulas o laboratorios o a nivel de todo el campus, denegando en el router de salida de la red hacia INet cualquier tráfico a los puertos 6667, 8888 y similares; aunque realmente esto no evitaría que todos los usuarios siguieran jugando desde los equipos de la universidad, por ejem-plo a través de un servidor que disponga de conexión en otros puertos, sí conseguiría que la mayor par-te de ellos dejara de hacerlo.




BIBLIOGRAFÍA

1 Douglas E. Commer "Internetworking with TCP/IP" Vol. 1 "Principles, Protocols and Architecture" Prentice Hall 2ª . ed., 1991

2 Jack Tackett Jr. Y David Gunter “Utilizando Linux” Prentice Hall 2ª. Ed., 1996

3 Harley Hahn “Internet Manual de referencia” Osborne McGraw-Hill , 2ª. Edición, 1997

4 Stephen Coffin "Unix Sistema V versión 4" Mc Graw Hill, 1992

5 Heywood, Drew “Redes con Microsoft TCP/IP”, Prentice Hall 2ª. Ed., 1998

6 http:// sunsite.unc.edu/LDP/

7 http://metalab.unc.edu/pub/Linux/docs/HOWTO/translations/Directory-Structure

