Curso Admin Is Trac Ion S.O. Unix

DIRECCIÓN DE OPERACIÓN CURSO:
ADMINISTRACIÓN DEL SISTEMA OPERATIVO UNIX
CURSO
ADMINISTRACIÓN DEL SISTEMA

OPERATIVO UNIX
Profesores:
M. I. Samuel Pérez Aguilar

sperez@zeus.umich.mx
M. I. Moisés García Villanueva

moises@scfie.fie.umich.mx
FACULTAD DE INGENIERIA ELECTRICA

UNIVERSIDAD MICHOACANA
Septiembre de 2003
CENTRO NACIONAL DE CAPACITACIÓN CELAYA PÁGINA 1 DE 92

CONTENIDO
INTRODUCCIÓN.....................................................................................................................................................................4
INSTALACIÓN DE UN SERVIDOR UNIX...........................................................................................................................5

GEOMETRÍA DEL DISCO DURO................................................................................................................................................5
PARTICIÓN DEL DISCO DURO.................................................................................................................................................6
FORMATEO E INSTALACIÓN..................................................................................................................................................8
CONFIGURACIÓN DE LA CONEXIÓN A INTERNET EN EL SERVIDOR...................................................................9
CONFIGURACIÓN DE LA RED..................................................................................................................................................9
Instalación y Configuración del TCP/IP...........................................................................................................................9
Configuración del dispositivo de red. .............................................................................................................................10
Notas...............................................................................................................................................................................12
DIRECCIONES INTERNET.....................................................................................................................................................12
Direcciones broadcast y de red.......................................................................................................................................13
Desventajas del direccionamiento Internet......................................................................................................................14
Notación decimal punteada.............................................................................................................................................14
Mapeo de direcciones Internet a direcciones físicas.......................................................................................................14
MODELO DE INTERACCIÓN CLIENTE-SERVIDOR.........................................................................................................................15
Ejemplos .........................................................................................................................................................................15
USO DE IFCONFIG (/ETC/IFCOFIG) PARA INSPECCIONAR UNA INTERFAZ DE RED..................................................................................16
Configuración de la interfaz de bucle interno de software..............................................................................................16
Configuración de una interfaz de red..............................................................................................................................16
RUTEADO DE TCP/IP......................................................................................................................................................17
Política de ruteado..........................................................................................................................................................17
ADMINISTRACIÓN...............................................................................................................................................................21
CREACIÓN DE CUENTAS DE USUARIOS....................................................................................................................................21
Creando una cuenta en el modo de texto: useradd y passwd...........................................................................................21
Eliminar una cuenta de usuario.......................................................................................................................................21
EL PROCESO EN UNIX. (COMANDOS &, PS, KILL Y TOP)............................................................................................................22
PROCESOS SUBORDINADOS .................................................................................................................................................22
DESPEDIDA MIENTRAS SE EJECUTAN PROCESOS SUBORDINADOS ...................................................................................................23
LA ORDEN PS .................................................................................................................................................................24
LISTA DE LA ACTIVIDAD DE OTROS USUARIOS .........................................................................................................................25
PROCESOS DEL SISTEMA ....................................................................................................................................................25
MONITOREO DE LA ACTIVIDAD DEL USUARIO...........................................................................................................................27
ELIMINACIÓN DE UN PROCESO ............................................................................................................................................28
SEGURIDAD DEL SISTEMA...............................................................................................................................................30
LA SEGURIDAD................................................................................................................................................................30
Protección de los datos frente a los otros usuarios..........................................................................................................31
Encripción de archivos....................................................................................................................................................33
Ids de presentación y contraseñas ..................................................................................................................................34
Historial de presentaciones ............................................................................................................................................35
El superusuario ..............................................................................................................................................................35
El archivo de contraseñas ..............................................................................................................................................36
SHELL SEGURO................................................................................................................................................................37
SERVICIOS ............................................................................................................................................................................38
FTP.............................................................................................................................................................................38
NFS............................................................................................................................................................................40
Sistemas de archivos distribuidos....................................................................................................................................40
Procesos cliente y servidor NFS......................................................................................................................................41
Archivos de configuración NFS.......................................................................................................................................41
DHCP.........................................................................................................................................................................43

Funcionamiento de DHCP..............................................................................................................................................43
Fases de Consesión.........................................................................................................................................................44
Configuración del Servidor DHCP para UNIX...............................................................................................................45
Configuración del cliente DHCP.....................................................................................................................................47
SEGURIDAD EN EL KERNEL.............................................................................................................................................49
SCO OPENSERVER..........................................................................................................................................................50
Opciones de compilación.................................................................................................................................................50
Algunas mejoras de la seguridad.....................................................................................................................................52
El súper server o inetd.....................................................................................................................................................52
El inetd.conf....................................................................................................................................................................53
El tcpd.............................................................................................................................................................................55
hosts.allow y hosts.deny...................................................................................................................................................56
Misceláneas.....................................................................................................................................................................59
RESUMEN......................................................................................................................................................................61
ARCHIVOS IMPORTANTES...............................................................................................................................................62
EL ARCHIVO /ETC/HOSTS....................................................................................................................................................62
CONTROL DE ACCESO........................................................................................................................................................62
EL ARCHIVO /ETC/SERVICES................................................................................................................................................63
EL ARCHIVO /ETC/INETD.CONF.............................................................................................................................................64
EL ARCHIVO /ETC/PROTOCOLS.............................................................................................................................................66
EL ARCHIVO /ETC/NETWORKS..............................................................................................................................................67
EL ARCHIVO /ETC/ETHERS..................................................................................................................................................67
AUDITORÍA DEL SISTEMA................................................................................................................................................68
SISTEMA DE BITACORAS (LOGS) EN UNIX...............................................................................................................................68
EL DEMONIO SYSLOG........................................................................................................................................................69
ARCHIVOS DE BITACORAS..................................................................................................................................................73
syslog...............................................................................................................................................................................73
messages..........................................................................................................................................................................74
wtmp................................................................................................................................................................................74
utmp.................................................................................................................................................................................75
sulog................................................................................................................................................................................75
cron.................................................................................................................................................................................75
BITACORAS REMOTAS .......................................................................................................................................................76
FIREWALLS (CORTAFUEGOS).........................................................................................................................................80
CARACTERÍSTICAS DE DISEÑO..............................................................................................................................................83
COMPONENTES DE UN CORTAFUEGOS.....................................................................................................................................85
Filtrado de paquetes........................................................................................................................................................85
Proxy de aplicación.........................................................................................................................................................86
MONITORIZACIÓN DE LA ACTIVIDAD......................................................................................................................................87
ARQUITECTURAS DE CORTAFUEGOS.......................................................................................................................................88
Cortafuegos de filtrado de paquetes................................................................................................................................88
Dual-Homed Host............................................................................................................................................................88
Screened Host..................................................................................................................................................................89
Screened net (DMZ)........................................................................................................................................................89
Otras arquitecturas..........................................................................................................................................................90
BIBLIOGRAFÍA.....................................................................................................................................................................92

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 duro

Formateo de las diferentes particiones
Instalación de los sistemas operativos seleccionados
Configuració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ón
El Disco Duro es uno de los elementos denominados de 'almacenamiento masivo', su función es la de
guardar el sistema operativo, los programas y los datos al apagar la computadora. La memoria RAM no
conserva los datos que tiene al desconectar la corriente eléctrica, aunque sea sólo por un momento,
perdiéndose todos 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ísica
La 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
empezando 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.
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
“Master 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
particiones primarias como máximo. No existe ningún impedimento de tipo físico o lógico para tener las
que deseemos, simplemente se trata de una convención acordada por los fabricantes a fin de coincidir en
una misma 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
• 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:
SCO
Linux
Windows
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:
Para sco Para windows

other=/dev/hda1 other=/dev/hda2
label=sco label=windows
table=/dev/hda table=/dev/hda
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.

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 Red
Puerto Serie
Modem
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 Address
RAM Buffer Base Ardes
Actualmente 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/IP

Existen varios parámetros que deben configurarse en este protocolo, los más importantes son:
Local Host Name

El nombre que identificará a la computadora y que debe ser único en la red en que se encuentre conectada.
Domain name
El 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

anteriores.
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
operació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 Internet, 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
recibir. 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 8232

inet 127.0.0.1 netmask ff000000
perf. 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.255
perf. Params: recv size: 24576; send size: 24576; full-size frames: 1
ether 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.

Argumento Descripción
s
flush Elimina todas las entradas gateway de la tabla de ruteo
delete 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 –r
Routing tables
Destination Gateway Flags Refs Use Interface
localhost localhost UH 3 56 lo0
224 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ón
Destination El destino del paquete de la ruta mostrada
Gateway 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
ruta
Use El número de veces que se ha usado la entrada de la tabla de
ruteado
Interface La interfaz de red a la que la ruta suministra paquetes
# netstat -r
Routing tables
Destination Gateway Flags Refs Use Interface
default 192.168.1.254 UGS 0 45 net0
localhost localhost UH 1 2 lo0
192.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 red
destination 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.
El contenido del archivo /etc/resolv.conf puede ser:
nameserver 148.216.1.2
nameserver 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
terminal 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úsculas 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
impedirá 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 -f
UID PID PPID C STIME TTY TIME CMD
steve 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 -af
root 82 1 0 Apr 9 tty02 00:00:05 -sh
steve 756 1 3 13:04:57 ttyp1 00:00:01 -sh
steve 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
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 300
root 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
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:
$ umask
000
$ > 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:
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: root
Password:
Last successful login for root: Thu Aug 21 22:27:57 2003 on tty04
Last 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, Inc

1980-1994 Microsoft Corporation
All rights reserved
For complete copyright credits,

Enter “copyrights” at the command prompt
Terminal 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 tty04
Last unsuccessful real login for root: Thu Aug 21 17:33:27 2003 on tty03
Terminal 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.tar
ftp://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
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/shells

root
sam
Si deseamos permitir conecciones de ftp anónimo debe existir un usuario ftp en el archivo /etc/passwd
# cat /etc/passwd | grep ftp

ftp: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 distribuidos

Un 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
argumento 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 mountd
4. 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
/compartido
2. mountd realiza una llamada al sistema nf_getfh (en SCO) para obtener la accesibilidad a
/compartido
3. mountd regresa la aceptación al cliente
Archivos de configuración NFS

En 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 compartir

opció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.254
dns_servers 148.216.1.2
domain sid.fie.umich.mx
smtp_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 aasd

root 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 inetd

root 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

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
operativo 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 importante 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 directamente 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
atacantes no poseen los conocimientos necesarios, para utilizar el kernel del sistema operativo en
beneficio 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 modificado
Completamente el kernel, puede haber reprogramado la llamada sysinfo() para que devuelva un
resultado 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
sistema. 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
disponibilidad 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ódigo, 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
circunstancia que genera un evento extraño, sobre el que posteriormente se investiga. Por tanto, la

disponibilidad del código del kernel no debe suponer una amenaza a la seguridad. Además, un
administrador 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
sistema seguro; es más, al ser el kernel la base del sistema operativo, no sirve de nada esforzarse en
conseguir 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 secció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
modificar el número máximo de procesos en el sistema, lo podemos hacer a través de
/etc/conf/cf.d/configure o utilizando el ambiente gráfico de scoadmin en la opción Hardware/Kernel
Manager. Esta utilidad nos mostrará un menú con diferentes categorías de parámetros configurables;
en nuestro caso debemos elegir MAX_PROC, disponible en la sección Table limits de Configuration
Tunables. Tambíen podemos configurar aquí el máximo número de descriptores de archivo en uso en
el sistema, modificando el valor del parámetro MAX_FILE (este parámetro no controla el número
máximo de archivos abiertos por proceso).
Utilizando esta misma utilidad, pero ahora en la sección User and group configuration podemos
definir 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
directorio. 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
comando inconfig. Esta utilidad actualizará los datos definidos en /etc/default/inet, así como los que
el kernel 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 inconfig lo actualiza de forma dinámica (si alguno de los nuevos valores es erróneo, se mantienen
los valores 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á),
podemos 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
minutos 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
posibilidad 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
sistema 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
utilizados 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
necesarios 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:
- 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
produzca 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.
Nos envía la fecha en formato legible por nosotros, por ejemplo: Wed Jun
daytime
14 10:32:20 2000.
Nos envía la fecha en un formato ilegible para nosotros, pero si legible para
time 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.
Se utiliza para realizar a través de la red transferencias de archivos, con
ftp:
autentificacion mediante usuario y contraseña.
Se utiliza para obtener sesión remota, ósea una consola remota, con
telnet:
autentificacion mediante usuario y contraseña.
Protocolos BSD.
Provee ejecución remota de comandos, con autentificacion basada en
shell:
puertos privilegiados y hosts de confianza (trust).
Provee una sesión remota, con autentificacion basada en puertos
login:
privilegiados y hosts de confianza.
Provee ejecución remota de comandos, con autentificacion basada en
exec:
usuario y contraseña.
talk: Los dos siguientes se utilizan para conversar con otro usuario.
ntalk:
Servicios de información.
Server que provee información remota, retorna un reporte de estado del
finger:
sistema o de un usuario en particular.
Escucha en determinados ports TCP y retorna el usuario que realiza la
ident:
conexión.

Ambos se utilizan normalmente como servidores de booteo, para PCs sin

tftp
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.
#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
f#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
segura 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
correspondiente, 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

direcció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,
rechaza la petición. Si tiene acceso al servicio, el tcpd ejecuta el programa que brinda el servicio
correspondiente 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,
dependiendo 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
necesitamos 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:
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,
colocando 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
directorio /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*
P90RESERVED ejecuta los scripts /etc/rc.d/9*
Otra precaución fundamental es asegurarse que los servicios que necesitamos ejecutar no tengan
problemas 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/security/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ímites 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
indispensable consultar la documentación del sistema y asegurarse muy bien de lo que se está haciendo
antes de reconfigurar un kernel, ya que un error puede ser fatal para el servidor. En la tabla 7.3 se
presentan 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
administrador 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,
encargado 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, tenemos al conjunto de programas y archivos utilizados para configurar parámetros del
sistema relacionados con la red, como la dirección IP, las tablas de ruteo, o el comportamiento de un
servidor ante solicitudes 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 global 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
suelen 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 siguiente:
192.168.1.150 portatil.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
cuales 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
encuentra 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_shell
Es un campo opcional, puede contener un comando de shell para que sea invocado cuando una
busqueda coincida con la entrada. Esto es útil para establecer trampas que puedan delatar a atacantes
potenciales:
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
servicio, respectivamente.
El archivo /etc/services
EL archivo services, lista de servicios de red, es un archivo ASCII que proporciona una
correspondencia 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
suficientemente amplio para que ciertos programas de red funcionen correctamente). Por ejemplo, para
especificar 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
privilegiados) 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 puerto 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/inetd.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
significado es el siguiente:
Servicio
En este campo se indica el nombre del servicio; el nombre ha de existir en /etc/services para ser
considerado 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
utilizado existen una serie de identificadores válidos, lo normal es que asociado al protocolo TCP se
utilicen 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

importante 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
especificamos nowait, el número de conexiones simultáneas quizás llegue a ser lo suficientemente
grande como para degradar las prestaciones del sistema, lo que por supuesto no es conveniente para el
sistema.
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
documentació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 configuració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
diferente 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
habitual para el protocolo TCP) y ejecutar fork() y exec() del programa /usr/sbin/in.telnetd, bajo la
identidad 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,
denominado número de protocolo, para identificar el protocolo de transporte específico que el servidor
recibe; 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 number

icmp 1 ICMP # internet control message protocol
igmp 2 IGMP # Internet Group Management
ggp 3 GGP # gateway-gateway protocol
ipencap 4 IP-ENCAP # IP encapsulated in IP (officially ÌP'')
st 5 ST # ST datagram mode
tcp 6 TCP # transmission control protocol
egp 8 EGP # exterior gateway protocol
pup 12 PUP # PARC universal packet protocol
udp 17 UDP # user datagram protocol
hmp 20 HMP # host monitoring protocol
xns-idp 22 XNS-IDP # Xerox NS IDP
rdp 27 RDP # "reliable datagram" protocol

iso-tp4 29 ISO-TP4 # ISO Transport Protocol class 4

xtp 36 XT P # Xpress Tranfer Protocol
ddp 37 DDP # Datagram Delivery Protocol
idpr-cmtp 39 IDPR-CMTP # IDPR Control Message Transport
ipv6 41 IPv6 # IPv6
ipv6-route 43 IPv6-Route # Routing Header for IPv6
ipv6-frag 44 IPv6-Frag # Fragment Header for IPv6
ipv6-crypt 50 IPv6-Crypt # Encryption Header for IPv6
ipv6-auth 51 IPv6-Auth # Authentication Header for IPv6
ipv6-icmp 58 IPv6-ICMP # ICMP for IPv6
ipv6-nonxt 59 IPv6-NoNxt # No Next Header for IPv6
ipv6-opts 60 IPv6-Opts # Destination Options for IPv6
rspf 73 RSPF # Radio Shortest Path First.
vmtp 81 VMTP # Versatile Message Transport
ospf 89 OSPFIGP # Open Shortest Path First IGP
ipip 94 IPIP # Yet Another IP encapsulation
encap 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
tanto 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
desplazado 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
actualidad el archivo /etc/ethers no se suele encontrar (aunque para el sistema sigue conservando su
funcionalidad, es decir, si existe se tiene en cuenta) en casi ningun servidor Unix, ya que las
direcciones hardware 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
incluso 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
cantidad de información que potencialmente se registra puede ser aprovechada para crear negaciones
de servicio 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
especiales para poder revisar los logs (aunque existen algunas utilidades para hacerlo, como swatch)
e incluso 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
auditorí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; evidentemente, los informes generados en este proceso pueden llegar a ocupar muchísimo
espacio en disco (dependiendo del número de usuarios en nuestro sistema) por lo que sólo es
recomendable en situaciones muy concretas, por ejemplo para detectar actividades “'sospechosas”' en
un servidor o para cobrar por el tiempo de CPU consumido. En los sistemas System V el process
accounting está desactivado 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
sobre un servidor Unix en los sistemas con el modelo de auditoría C2; mientras que con el modelo
clásico se genera un registro tras la ejecución de cada proceso, en Unix C2 se proporciona una pista de
auditorí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
asignando 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 convierte en un monitoreo inútil, si no se dispone de mecanismos para interpretar o reducir la gran
cantidad 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
encargado 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
ignorara 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.log

local7.* /var/log/boot.log
# bitacora de tcpd (TCP-Wrappers)

local0.info /var/log/tcpd.log
#
# INN
#
news.=crit /var/log/news/news.crit
news.=err /var/log/news/news.err
news.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
acció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), syslog, 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/spool
uucp,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

“'!”' (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
exclamació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-info
mail.*;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
(vaciado 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 muchos mensajes al demonio syslogd.
# Guardamos todos los mensajes de prioridad critica en "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/tty12
kern.crit /dev/console
Una tubería con nombre
Algunas versiones de syslogd permiten enviar registros a archivos de tipo pipe simplemente
anteponiendo 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
remotamente. 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 modificados 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
login, 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
sucedan en el servidor se registrarán en determinados archivos; aunque podemos loggear en cualquier
archivo (incluso a través de la red o en dispositivos, como veremos luego), existen ciertos archivos de
registro “'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
sistema; 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
dependiendo 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.2500
Mar 19 13:04:16 pegasso snort[500]: IDS152 - PING BSD: 148.216.30.150 -¿
148.216.250.250

Mar 19 13:04:18 pegasso last message repeated 2 times

Mar 19 13:07:46 pegasso snort[500]: IDS162 - PING Nmap2.36BETA:
148.216.1.150 -¿ 148.216.1.90
Mar 19 13:07:47 pegasso snort[500]: spp_portscan: PORTSCAN DETECTED from
148.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.150
Mar 19 13:08:19 pegasso snort[500]: spp_portscan: portscan status from
148.216.250.150: 62 connect
ions across 1 hosts: TCP(61), UDP(1) STEALTH
Mar 19 13:08:19 pegasso snort[500]: ICMP Destination Unreachable:
148.216.250.250 -¿ 148.216.8.78
Mar 19 13:12:54 pegasso snort[500]: IDS162 - PING Nmap2.36BETA:
148.216.250.150 -¿ 148.216.1.90
Mar 19 13:12:55 pegasso snort[500]: spp_portscan: PORTSCAN DETECTED from
148.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/messages

Speed 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=63
mem: total = 261184k, kernel = 13696k, user = 247488k
swapdev = 1/41, swplo = 0, nswap = 96000, swapmem = 48000k
rootdev = 1/42, pipedev = 1/42, dumpdev = 1/41
kernel: Hz = 100, i/o bufs = 6652k
Mon Aug 25 04:45:33 2003

WARNING: portmapper on server 192.168.1.1 is not responding
Mon Aug 25 04:46:04 2003
Mon Aug 25 04:46:35 2003
wtmp
Este es un archivo binario (no se puede leer su contenido directamente) que almacena información
relativa 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 Comments

root p5 ttyp5 4317 Mon Aug 25 19:44 00:03 logged in
root c03 tty03 548 Mon Aug 25 19:17 00:30 logged in

root p5 ttyp5 4195 Mon Aug 25 19:13 00:28

root typ5 ttyp5 3779 Mon Aug 25 18:44 00:00
ftp ftp ftp2822 2822 Mon Aug 25 04:30 00:01
ftp 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
conectan, mientras que init lo elimina cuando desconecta. Aunque habitualmente este archivo está
situado 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/utmp
User Line Device PID Login time Elapsed Time Comments
root c03 tty03 548 Mon Aug 25 19:17 00:34 logged in
sam co tty01 547 Mon Aug 25 19:52 00:00 logged in
root 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
fracaso (-) de la operación, se guarda en /var/adm/sulog:
SU 12/27 07:41 + console root-rafael

SU 12/28 23:42 - vt01 rafael-root
SU 12/28 23:43 + vt01 rafael-root
SU 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 encuentran 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
> 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
pretende 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
mensajes 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 ÙNKNOWN' 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
conectado 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
equipo 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,
requiere 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;
evidentemente, 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
servidor 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 origen, 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
archivo /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
proceso se lance automáticamente al iniciar el sistema; si lo hacemos así se debe de tener cuidado con
la autenticació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

remoto. 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
informació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, desde cualquier parte del mundo, puede potencialmente tener acceso a nuestros recursos.
Un término medio entre ambas aproximaciones consiste en implementar cierta separación lógica
mediante un cortafuegos (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ísticas de funcionamiento de un firewall; por máquina o host bastión (tambíen se denominan
gates) se conoce a un sistema especialmente asegurado, pero en principio vulnerable a todo tipo de
ataques por estar 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
predefinidas; 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
implementa en el choke un mecanismo de filtrado de paquetes, y en alguno de los dos elementos se
suele situar 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
firewalls 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
medidas 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
preocuparse de la integridad de todas y cada una de sus máquinas, pero en el momento en que instala
el cortafuegos 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 expuesto 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
evidentemente 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
conocimiento 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 cortafuegos. 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 ocasiones 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 sistema, 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
utilice 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

internos pierdan el tiempo en la red, bloqueando por ejemplo todos los servicios de salida al exterior
excepto el correo electrónico. Sobre esta decisión influyen, aparte de motivos de seguridad, motivos
administrativos 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ícitamente no se permita) o bien una permisiva (permitimos todo excepto lo explícitamente
negado); evidentemente es la primera la más recomendable de cara a la seguridad, pero no siempre es
aplicable debido 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
desembolso de varios miles de pesos: seguramente un departamento o laboratorio con pocos equipos
en su interior 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 funciona cuando el sistema a proteger es una red de tamaño considerable; en este caso se pueden
utilizar sistemas 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 hemos 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 mantenimiento.
Estas decisiones, aunque concernientes al diseño, eran básicamente políticas; la primera decisiónc
técnica a la que nos vamos a enfrentar a la hora de instalar un cortafuegos es elemental: ¿dónde lo
situamos 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 dentro 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
elementos físicos utilizar como bastión; para tomar esta decisión existen dos principios básicos:
mínima complejidad 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 seguridad 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 parte 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é elemento utilizar como choke; generalmente suele ser un
router con capacidad para filtrar paquetes, aunque tambíen puede utilizarse un sistema Unís para
realizar esta función. Más adelante se comentan diferentes 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
implementar 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
filtrado de paquetes, el proxy de aplicación y la monitorización y detección de actividad sospechosa.
Vamos 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
acceso no autorizado entre dos redes, pero manteniendo intactos los accesos autorizados. Su
funcionamiento 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 implementaciones de filtrado permiten especificar reglas basadas en la interfaz del router por
donde se ha de reenviar 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
bloqueo de un paquete se notificará a la máquina origen mediante un mensaje icmp. Siempre hemos de
tener 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
administrador 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
documentació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
indispensable 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 hline
158.43.0.0 & * &* &* & Deny

* & 195.53.22.0 & * &* & Deny

158.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áquina 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 orden de análisis que siga: si se comprueban las reglas desde el principio, el paquete
atravesaría el cortafuegos, 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 podemos 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
nuestras reglas?. El sentido común nos dice que por seguridad se debería bloquear, pero esto no
siempre sucede 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 cortafuegos, 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
capaces 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
denomina 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 único 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 enormemente las reglas de filtrado implementadas en el router (que como
hemos dicho antes pueden convertirse en la fuente de muchos problemas de seguridad): sólo hemos de
permitir el tráfico hacia la pasarela, 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
frecuentemente 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 pasos para conectar hacia la zona segura o hacia el resto de la red; incluso algunas
implementaciones necesitan clientes modificados para funcionar correctamente.
Una variante de las pasarelas de aplicación la constituyen las pasarelas de nivel de circuito (Circuit
level Gateways), sistemas capaces de redirigir conexiones (reenviando tramas) pero que no pueden
procesar 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 èxtra 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
información de la conexión (origen y destino, nombre de usuario, recordemos el servicio ident, hora y
duració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
servicios reales en el cortafuegos por programas trampa. La idea es sencilla: se trata de peque nas
aplicaciones 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.
Evidentemente, nos estamos arriesgando a que nuestro atacante descubra el mecanismo y lance ataques
más peligrosos, 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
utilizados 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
routers 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
presentan 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 determinar si el router está siendo atacado o si su seguridad ha sido comprometida. Además las
reglas de filtrado pueden llegar a ser complejas de establecer, y por tanto es difícil comprobar su
corrección: habitualmente 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
seguridad 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
tarjetas 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
deseemos 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 entre la red interna y la externa es necesario que el choke no enrute paquetes entre
ellas. Todo el intercambio de datos entre las redes se ha de realizar a través de servidores proxy
situados en el host bastió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 protecció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
filtrado de paquetes. En la máquina bastión, único sistema accesible desde el exterior, se ejecutan los
proxies de las aplicaciones, mientras que el choke se encarga de filtrar los paquetes que se puedan
considerar 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
autores 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
seguridad, 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 informá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,
denominados 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
tambí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
exterior tiene como misión bloquear el tráfico no deseado en ambos sentidos (hacia la red perimétrica
y hacia 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 redes perimétricas en serie, situando los servicios que requieran de menor fiabilidad en las redes
más externas; 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. Evidentemente 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 incumplimiento 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 filtrado 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
administració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 diferentes 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 incrementar 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 ejemplo a través de un servidor que disponga de conexión en otros puertos, sí
conseguiría que la mayor parte 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

Curso Admin Is Trac Ion S.O. Unix

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Curso Admin Is Trac Ion S.O. Unix

Hochgeladen von

Copyright:

Verfügbare Formate

DIRECCIÓN DE OPERACIÓN CURSO:

ADMINISTRACIÓN DEL SISTEMA OPERATIVO UNIX

ADMINISTRACIÓN DEL SISTEMA

M. I. Samuel Pérez Aguilar

M. I. Moisés García Villanueva

FACULTAD DE INGENIERIA ELECTRICA

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

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

CENTRO NACIONAL DE CAPACITACIÓN CELAYA PÁGINA 2 DE 92

CENTRO NACIONAL DE CAPACITACIÓN CELAYA PÁGINA 3 DE 92

En el segundo módulo se estudia el diseño de páginas de web, utilizando el lenguaje HTML.

CENTRO NACIONAL DE CAPACITACIÓN CELAYA PÁGINA 4 DE 92

INSTALACIÓN DE UN SERVIDOR UNIX.

Partición del disco duro

Geometría del disco duro

CENTRO NACIONAL DE CAPACITACIÓN CELAYA PÁGINA 5 DE 92

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

Partición del disco duro

CENTRO NACIONAL DE CAPACITACIÓN CELAYA PÁGINA 6 DE 92

Para sco Para windows

CENTRO NACIONAL DE CAPACITACIÓN CELAYA PÁGINA 8 DE 92

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

Instalación y Configuración del TCP/IP

Configuración del TCP/IP

- ifconfig (interface configuration) para mostar, añadir o suprimir interfaces.

CENTRO NACIONAL DE CAPACITACIÓN CELAYA PÁGINA 9 DE 92

- route para mostrar, añadir o suprimir rutas de acceso en su red.

Configuración del dispositivo de red.

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

mount /dev/fd0 /mnt

CENTRO NACIONAL DE CAPACITACIÓN CELAYA PÁGINA 10 DE 92

utiliza para navegar en Internet, transferir archivos etc.

Parámetros de configuración de TCP/IP

Local Host Name

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

Dirección IP y máscara de red.

CENTRO NACIONAL DE CAPACITACIÓN CELAYA PÁGINA 11 DE 92

CENTRO NACIONAL DE CAPACITACIÓN CELAYA PÁGINA 12 DE 92

Figura 3.2. Las cinco formas de direccionamiento Internet

Direcciones broadcast y de red

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

CENTRO NACIONAL DE CAPACITACIÓN CELAYA PÁGINA 13 DE 92

Desventajas del direccionamiento Internet

Notación decimal punteada

10000000 00001010 00000010 00011110

Mapeo de direcciones Internet a direcciones físicas

CENTRO NACIONAL DE CAPACITACIÓN CELAYA PÁGINA 14 DE 92

Figura 3.3. El protocolo ARP

Modelo de interacción cliente-servidor

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

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

lo0: flags=4049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232

Configuración de la interfaz de bucle interno de software

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

$ ifconfig lo0 127.0.0.1

Configuración de una interfaz de red

$ifconfig net0 192.168.1.3

CENTRO NACIONAL DE CAPACITACIÓN CELAYA PÁGINA 16 DE 92

$ifconfig net0 192.168.1.3 broadcast 166.82.1.127 netmask 255.255.255.128

Uso del programa route (/etc/route)