Este documento se encuentra disponible tambi�n en formato PDF

Recomendaciones en nivel de sistema

Las configuraciones establecidas por defecto en muchos sistemas operativos no son las mÃ¡s adecuadas desde el punto de vista de seguridad. AdemÃ¡s, el desconocimiento y la desinformaciÃ³n de los responsables de estos equipos es motivo frecuente de problemas de seguridad. En este apartado vamos a comentar diversas medidas que se deberÃan adoptar en los sistemas para evitar gran parte de estos problemas.

ConfiguraciÃ³n de equipos Unix

ActualizaciÃ³n y control de fallos

Los ataques con mÃ¡s Ã©xito en los sistemas informÃ¡ticos se basan en aprovechar vulnerabilidades en el software que no ha sido actualizado a la Ãºltima versiÃ³n facilitada por el fabricante, o que no ha sido parcheado convenientemente. Esto afecta tanto al software de red de grandes mÃ¡quinas y sistemas operativos, como al software de PC de usuarios.

Esta tarea es laboriosa porque supone mantenerse al dÃa de la evoluciÃ³n de los productos, asÃ como conocerlos a fondo para poder configurarlos correctamente. La mayorÃa de los vendedores mantienen listas con los parches recomendados (Sun, IRIX, etc...). A la hora de instalar un parche, se recomienda comprobar la firma digital, si existiera, y el checksum para verificar que se trata de una copia vÃ¡lida. El MD5 comprueba la integridad y la no alteraciÃ³n del paquete, y la firma PGP la autenticidad de su autor.

Es muy importante estar al dÃa y revisar el software que se utiliza, especialmente aquel que tenga que ver con la conectividad a Internet, administraciÃ³n de servicios de red, etc... y actualizarlo o parchearlo con las Ãºltimas actualizaciones disponibles. A menudo no resulta buena idea utilizar la Ãºltima versiÃ³n disponible, sino la penÃºltima, ya que al ritmo al que se lanzan nuevas versiones de productos, la Ãºltima, con casi toda seguridad, no habrÃ¡ sido puesta a prueba en su fase de diseÃ±o ni ha sido suficientemente validada por los usuarios. A veces, merece la pena esperar un perÃodo de tiempo, aunque eso sÃ, no con la primera versiÃ³n del producto.

Por Ãºltimo, comentar que no es suficiente con instalar la Ãºltima versiÃ³n o actualizaciÃ³n disponible, sino que es necesario configurarla convenientemente, de manera que se cierren los resquicios que puedan dejar las instalaciones por defecto. Esta correcciÃ³n es importante no sÃ³lo en los sistemas operativos, sino tambiÃ©n en el software en general.

Directivas generales

En esta secciÃ³n, daremos algunas ideas a los administradores sobre la configuraciÃ³n de los equipos Unix. Algunas de las directivas generales a la hora de configurar un sistema teniendo en cuenta la seguridad se pueden sintetizar en los siguientes puntos:

La presencia de archivos .rhosts y /etc/hosts.equiv merece especial cuidado, pues garantizan el acceso a la mÃ¡quina sin necesidad de autenticaciÃ³n. Si no es necesario el uso de comandos r (aconsejado en capÃtulos anteriores, e insistentemente por IRIS-CERT), no se necesita la presencia de estos archivos al no ser una alternativa segura a telnet. Se recomienda usar clientes ssh, ampliamente descritos ya en este documento.
Se puede establecer quÃ© terminales son seguros, y por lo tanto desde quÃ© terminales se puede conectar el usuario root. En los terminales declarados como no seguros el usuario antes de llegar a ser root, necesitarÃ¡ conectarse utilizando una cuenta sin privilegios en el sistema y despuÃ©s utilizar el comando "su" para cambiar a root, lo que aÃ±ade un nivel extra de seguridad.
Desactivar IP forwarding y source routing. Es especialmente importante en el caso de estar usando una Sun como host bastiÃ³n o como "dual-homed".
Es importante deshabilitar la posibilidad de ejecuciÃ³n de cÃ³digo en pila de usuario, lo que evitarÃ¡ algunos problemas de "buffer-overflow" (pero no todos). En el caso de mÃ¡quinas Solaris lo podemos hacer incluyendo en el fichero de especificaciÃ³n del sistema "/etc/system" las lÃneas:
```
set noexec_user_stack=1
set noexec_user_stack_log=1
```
y reiniciando a continuaciÃ³n.
Evitar que el correo del root se almacene sin que nadie lo lea. Para ello establezca un archivo ".forward" en el home del root para redirigir el correo a una cuenta real en el sistema. AsÃ mismo, serÃa necesario asegurarse que estos archivos, si existen en los directorios home de los usuarios, no ejecuten ningÃºn comando.
Desactivar la ejecuciÃ³n de comandos en los dispositivos montables por los usuarios.
Separar las mÃ¡quinas de los usuarios de aquellas que ofrecen algÃºn servicio a la comunidad (servidores), y restringir en la medida de lo posible el acceso a las mismas.
El administrador debe prevenir posibles escuchas en la red. Un "sniffer" escucha todo lo que pasa por una puerta ethernet, incluyendo contraseÃ±as de cuentas de usuario, de superusuario, claves de POP, etc.. Para evitarlo, se recomienda el uso de Shell Seguro (ssh) (http://www.ssh.org/) u otros mÃ©todos de cifrado de contraseÃ±as.
Revisar el path de la cuenta root en los ficheros de inicio (.login, .cshrc, .profile, ...). El comando path o la variable de entorno PATH definen los directorios de bÃºsqueda de los ejecutables. El directorio ".", es decir, el actual, nunca debe aparecer en el path del root.

Seguridad en sistemas de archivos

El aspecto mÃ¡s vulnerable en la protecciÃ³n de archivos son los modos de acceso SUID y SGID. Se aconseja realizar frecuentemente una auditorÃa de los mismos, monitorizando los cambios, puesto que son ficheros especialmente explotados por intrusos potenciales. Algunas sugerencias son:

Los sistemas Unix/Linux proporcionan otras maneras de limitar el acceso a varios recursos del sistema a usuarios que no sean el usuario root, como las cuotas de disco, la limitaciÃ³n de los recursos del sistema por proceso y/o usuario, y la protecciÃ³n para los subsistemas restringiendo el acceso a las colas de procesos batch y de impresiÃ³n para los usuarios no autorizados.
Si no hay mas remedio que usar NFS, se debe configurar de la forma mÃ¡s restrictiva posible. En el fichero /etc/exports se especifica a quiÃ©n se exporta y cÃ³mo se exporta un sistema de ficheros (de sÃ³lo lectura, sin permiso de escritura al root, etc.). El comando "showmount" permite verificar que el fichero de configuraciÃ³n /etc/exports es correcto.
Establecer en el /etc/profile una umask para los usuarios lo mÃ¡s restrictiva posible (022, 033 Ã³ incluso 077). La mÃ¡scara del root debe ser 077.
No usar Samba en la medida de lo posible. Si es necesaria su utilizaciÃ³n, se debe configurar muy restrictivamente el fichero /etc/smb.conf.
AsegÃºrese de que todos los ficheros que cuelgan del directorio /dev son ficheros especiales y que del mismo modo no existen archivos de dispositivo fuera de la estructura de /dev.
Considere eliminar el acceso a lectura de todos aquellos archivos que no necesiten tener dicho acceso. TambiÃ©n es aconsejable revisar los ficheros y directorios escribibles por todo el mundo.
AsegÃºrese de que el usuario root es el propietario de los directorios /etc, /usr/etc, /bin, /usr/bin, /sbin, /usr/sbin, /tmp y /var/tmp. AdemÃ¡s, los directorios /tmp y /var/tmp deben tener el sticky bit establecido.
AUSCERT recomienda que todos los archivos ejecutados por el usuario root deben ser propiedad de dicho usuario, no ser escribibles ni por el grupo ni por otros (es decir, con modo 755 o mejor) y localizados en un directorio donde cada directorio en el path sea propiedad del usuario root. En este sentido, una prÃ¡ctica general consistirÃa en examinar la protecciÃ³n de los ficheros y directorios antes y despuÃ©s de instalar software o de ejecutar utilidades de verificaciÃ³n.
Es recomendable comparar las versiones de programas en el sistema con una copia vÃ¡lida de las mismas (por ejemplo del CD-ROM). Hay que tener especial cuidado con las copias de seguridad, pues pueden contener ficheros alterados o Caballos de Troya.
Los Caballos de Troya pueden tener el mismo "standard checksum" y timestamp que la versiÃ³n original. Por esto, el comando de UNIX sum(1) y el timestamp asociado a los programas no es suficiente para determinar si estos han sido alterados o reemplazados. El uso de cmp(1), MD5, Tripwire y otras utilidades para generar un checksum criptogrÃ¡fico son necesarios para detectar estos caballos de troya.

Filtrado de servicios en equipos Unix

Para evitar riesgos innecesarios, se deben configurar TODAS las mÃ¡quinas de una organizaciÃ³n para que ofrezcan Ãºnicamente los servicios que se tenga en mente ofrecer y no otros. Esto disminuirÃ¡ considerablemente el riesgo de que estas mÃ¡quinas sean atacadas aprovechando servicios completamente descuidados y que en muchas ocasiones no se es consciente que se estÃ¡n ofreciendo.

Es necesario asegurarse de que no existen debilidades en los archivos de configuraciÃ³n de los servicios ofrecidos y que los servicios se ofrezcan sÃ³lo al conjunto de usuarios para los cuales se diseÃ±Ã³.

Servicios dependientes de inetd

El archivo inetd.conf contiene una lista con todos los servicios que el demonio inetd^4.1 invoca cuando recibe una peticiÃ³n sobre un socket.

Por defecto, a la hora de instalar el sistema operativo, se establece un archivo inetd.conf con gran cantidad de servicios activados por defecto, que en la grandÃsima mayorÃa de los casos no son necesarios. Es completamente necesario revisar este archivo con el fin de comentar las lÃneas de todos aquellos servicios que no sean necesarios explÃcitamente, y que en muchas ocasiones son causa de ataques y vulnerabilidades.

Nuestra recomendaciÃ³n es comentar todos los servicios que se lanzan desde el inetd.conf anteponiendo un carÃ¡cter ¨#äl principio de cada una de las lÃneas. Una vez hecho esto, se pueden descomentar (quitando el carÃ¡cter "#") aquellos servicios que sean necesarios en esa mÃ¡quina en concreto.

Para que los cambios realizados en este archivo de configuraciÃ³n tengan efecto, recuerde reiniciar el proceso inetd.

Puesto que en muchos casos, cuando se ofrece un servicio, Ã©ste estÃ¡ dirigido a un sector de la comunidad de Internet, es muy Ãºtil contar con algÃºn mecanismo que permita rechazar conexiones dependiendo de su origen y/o de su ident, y que proporcione ademÃ¡s, una monitorizaciÃ³n del acceso. En este contexto, recomendamos la instalaciÃ³n de tcp_wrapper (http://www.rediris.es/cert/doc/docu_rediris/wrappers.es.html), que se puede descargar en el FTP de RedIRIS. El tcp_wrapper (tcpd) actÃºa de intermediario transparente en las conexiones TCP, aÃ±adiendo un nivel extra de registro de conexiones, control de acceso y acciones configurables por conexiÃ³n.^4.2

Servicios dependientes de RPC

En general, los clientes de los servicios dependientes de RPC (Remote Procedure Control) hacen una llamada al gestor de RPC (rpcbind en Solaris, portmap en Linux, pero siempre el puerto 111/tcp), para averiguar donde estÃ¡n los servicios de cada procedimiento.

Esta informaciÃ³n se puede ver como usuario, con el comando "rpcinfo -p", que implementa una llamada al procedimiento remoto 'dump'. Si alguno de los servicios que aparecen al ejecutar este comando no son necesarios, serÃ¡ imprescindible desactivarlos en los scripts de inicializaciÃ³n del sistema, lugar desde donde son lanzados.

En cuanto al tcp_wrapper, no puede usarse para controlar el acceso a estos servicios, pero si se puede usar para controlar y registrar el acceso al gestor RPC. Para hacerlo, es necesario tratar rpcinfo/portmap como un servidor independiente que implementa un servicio en el puerto 111. En Linux, portmap ya estÃ¡ compilado de esta manera, por lo que el acceso se puede controlar directamente con los archivos hosts.allow y hosts.deny. En Solaris, se requiere compilar una versiÃ³n especial del rpcbind y enlazarlo con la biblioteca libwrap.a (Solaris: /usr/local/lib/libwrap.a, Linux: /usr/lib/libwrap.a).

Servicios arrancados en los scripts de inicio del sistema operativo

Aparte de los servicios dependientes de RPC y de los dependientes de inetd, comentados con anterioridad, en el proceso de instalaciÃ³n del sistema operativo en una mÃ¡quina se activan una serie de servicios por defecto que se ejecutan desde el /etc/rc* correspondiente (por ejemplo el smtp, o el domain) que en la mayorÃa de los casos no son necesarios. Si Ã©ste es el caso, recomendamos que sean desactivados y que se modifiquen los scripts de inicio para que en subsiguientes arranques de la mÃ¡quina no se vuelvan a lanzar.

PolÃtica de contraseÃ±as

Sin duda, uno de los mÃ©todos mÃ¡s habituales usados por los hackers para comprometer un sistema es el robo de contraseÃ±as. Robando un nombre de usuario y su contraseÃ±a correspondiente, un intruso puede, reduciendo las probabilidades de ser detectado, ganar acceso a un sistema, modificarlo, y usarlo como lanzadera para atacar a otros sistemas. La mayorÃa de los sistemas no tienen ningÃºn mecanismo de control de las contraseÃ±as que utilizan sus usuarios y en la mayorÃa de los casos existe por lo menos una contraseÃ±a en el sistema que puede ser fÃ¡cil de descubrir, comprometiendo la seguridad del sistema completo.

La protecciÃ³n de las contraseÃ±as es uno de los principios mÃ¡s importantes en seguridad, por lo que es necesario que las organizaciones posean una polÃtica de contraseÃ±as bien definida.

Las tÃ©cnicas utilizadas por los crackers para obtener contraseÃ±as ajenas son muy variadas (desde aprovechar vulnerabilidades en ciertas aplicaciones hasta utilizar "Caballos de Troya", usualmente enmascarados en el programa /bin/login). Si un intruso obtiene un fichero passwd de una mÃ¡quina ajena, normalmente realiza una copia del mismo a otra mÃ¡quina y ejecuta programas crackeadores contra Ã©l, que son relativamente rÃ¡pidos y que realizan ataques de fuerza bruta, de diccionario o hÃbridos sobre las contraseÃ±as robadas.

A continuaciÃ³n daremos algunas directivas a tener en cuenta por los administradores de sistemas o responsables de seguridad para implementar una polÃtica de contraseÃ±as adecuada en sus organizaciones.

ContraseÃ±as dÃ©biles

La primera directiva, y en nuestra opiniÃ³n la mÃ¡s importante, es desarrollar una guÃas que ayuden a los usuarios a la hora de escoger contraseÃ±as lo suficientemente robustas para que no sean vulnerables a los ataques de diccionario o de fuerza bruta que suelen realizar la mayorÃa de las utilidades diseÃ±adas para romper contraseÃ±as. Estas medidas vienen ampliamente descritas en multitud de documentos por lo que no creemos necesario que sean repetidas aquÃ, pero a modo de ejemplo: no se deben escoger palabras del diccionario, palabras de estÃ©n relacionadas con el usuario (nombre de la mujer o marido, domicilio, fecha de nacimiento, etc...), utilizar contraseÃ±as con una longitud mÃnima de 8 caracteres, no usar el nombre de usuario o una variante, como el nombre de usuario al revÃ©s, etc.
Informar a los usuarios de que no almacenen informaciÃ³n sobre su cuenta/contraseÃ±a en archivos de texto en ningÃºn sistema.
Si se tiene mÃ¡s de una cuenta en distintos sistemas no es aconsejable utilizar la misma contraseÃ±a en todas, pues si la contraseÃ±a quedara comprometida en una mÃ¡quina, lo quedarÃa igualmente en el resto.
Cuando se utiliza el servicio de finger (puerto 79 tcp/udp) para interrogar a un servidor, a menudo Ã©ste revela mÃ¡s informaciÃ³n sobre sÃ mismo y sus usuarios de la que serÃa deseable (el shell que estÃ¡ utilizando cada usuario, su directorio personal, el grupo al que pertenece, y lo que en este caso es mÃ¡s importante, el nombre del usuario en la mÃ¡quina, con lo que el atacante ya poseerÃa la mitad de la informaciÃ³n que necesita para entrar en un sistema). Debido a que ademÃ¡s suele proporcionar informaciÃ³n sobre la hora del Ãºltimo login, un atacante podrÃa confeccionar patrones de trabajo de los distintos usuarios. En definitiva, se trata de informaciÃ³n demasiado valiosa para distribuirla sin control, por lo que es aconsejable eliminar este servicio de las mÃ¡quinas si no es estrictamente necesario su uso.
Utilizar con cierta frecuencia programas tipo crack para chequear la robustez de las contraseÃ±as del sistema y de esta forma encontrar claves dÃ©biles forzando el cambio de las mismas. Es mejor que nosotros conozcamos antes que el atacante la debilidad de nuestras contraseÃ±as.
Establecer un polÃtica de cambios periÃ³dicos de contraseÃ±as (sobre todo en las mÃ¡quinas mÃ¡s importantes y las de cuentas privilegiadas). AdemÃ¡s es aconsejable no reutilizar contraseÃ±as antiguas.

Cuentas sin contraseÃ±a o contraseÃ±as por defecto.

Cambiar todos las contraseÃ±as instalados por defecto en el proceso de instalaciÃ³n del sistema operativo.
Escanear el fichero de contraseÃ±as (/etc/shadow o /etc/passwd) periÃ³dicamente en busca de cuentas con UID igual a 0 (reservada para el usuario root).
Revisar el fichero de contraseÃ±as en busca de cuentas nuevas de las que no se tiene conocimiento y que en la mayorÃa de los casos son indicativo de intrusiÃ³n.
No permitir la existencia de cuentas sin contraseÃ±a.
Eliminar cuentas de usuarios que se hayan dado de baja en la organizaciÃ³n o que no se estÃ©n utilizando.
Es aconsejable el uso de programas como "noshell"
(ftp://ftp.rediris.es/mirror/coast/tools/unix/noshell) que permiten al administrador obtener informaciÃ³n adicional sobre intentos de conexiÃ³n a cuentas canceladas o bloqueadas en una mÃ¡quina. Utilizando este mecanismo, cada intento de conexiÃ³n queda registrada, mediante correo electrÃ³nico o syslogd, dando informaciÃ³n sobre el usuario remoto, la direcciÃ³n IP, el dÃa y la hora del intento de login y el tty utilizado en la conexiÃ³n.

ContraseÃ±as reutilizables

Reducir o eliminar la transmisiÃ³n de contraseÃ±as reutilizables en texto claro sobre la red. De esta forma se evitarÃ¡ que las contraseÃ±as sean capturadas por lo que se denomina "packet sniffers"^4.3.
Utilice contraseÃ±as de un sÃ³lo uso (one-time passwords)(S/Key, Secure Net Key, Secure ID, etc...) para el acceso autenticado desde redes externas o para acceder a recursos sensibles como routers, servidores de nombres, etc.
Si se trata de sistemas UNIX, recomendamos el uso del fichero /etc/shadow, o lo que es igual, un segundo fichero que contiene las contraseÃ±as cifradas y es sÃ³lo accesible por el usuario root, quedando el /etc/passwd con una "x" en el lugar donde deberÃan aparecer las contraseÃ±as cifradas. La mayorÃa de sistemas Linux, por ejemplo, vienen con PAM configurado. PAM (Pluggable Authentication Modules) es un mÃ©todo mucho mÃ¡s potente de gestiÃ³n de seguridad y contraseÃ±as que se adapta perfectamente a cualquier entorno UNIX.
Si su sistema tiene la posibilidad de aplicar una serie de reglas en la introducciÃ³n de palabras clave, es aconsejable que lo utilice. Por ejemplo, en el caso de un sistema Solaris, en el archivo /etc/default/passwd, o en un sistema con PAM, en el fichero /etc/pam.conf, se pueden establecer algunos valores por defecto, como son el nÃºmero mÃnimo de caracteres que debe tener un contraseÃ±a, el mÃ¡ximo perÃodo de tiempo en el cual es vÃ¡lida, el mÃnimo perÃodo antes de que la contraseÃ±a pueda cambiarse, etc.

PolÃtica de cuentas

Desde el punto de vista de la seguridad, el fichero /etc/passwd tiene una importancia vital. Si tiene acceso a este archivo, lo puede alterar para cambiar el contraseÃ±a de cualquier usuario, o incluso tener privilegios de superusuario cambiando su UID a 0.

Entre las recomendaciones que podemos dar para establecer una polÃtica adecuada de cuentas y grupos en un sistema podemos destacar:

AdministraciÃ³n

Del mismo modo que alentamos a las organizaciones para que posean una polÃtica de contraseÃ±as bien definida, es necesario que tambiÃ©n dispongan de un formulario para el registro de usuarios bien definido, donde se incluya una secciÃ³n, que deberÃ¡ ser firmada por el beneficiario, aceptando las condiciones y responsabilidades que supone tener una cuenta en el sistema. Se deberÃ¡ contemplar tambiÃ©n la posibilidad de acreditaciÃ³n por parte de los mismos.
Asegurarse de que existen copias de seguridad del Ã¡rea de disco de usuarios siempre que esto sea posible y se dispongan de los medios para hacerlo.
Considere el agrupar los directorios de los usuarios de una forma lÃ³gica, especialmente si espera tener muchos usuarios en el sistema.
Monitorice los registros en busca de intentos "su" no autorizados o fallidos.
Compruebe frecuentemente los intentos de conexiÃ³n no autorizados.
Establezca una polÃtica de asignaciÃ³n de cuotas de disco a usuarios y grupos, asÃ como la preparaciÃ³n de procedimientos de comprobaciÃ³n de los mismos con el fin de controlar que ningÃºn usuario sobrepase el lÃmite de espacio asignado.

Cuentas especiales

Evitar la existencia de cuentas compartidas.
Evitar la existencia de cuentas "guest" o de invitados. En este sentido, como varios sistemas instalan cuentas para invitados por defecto, serÃ¡ pues necesario desactivar o eliminar del sistema este tipo de cuentas.
Usar grupos especÃficos para restringir quÃ© usuarios pueden utilizar el comando "su".
Comprobar el archivo de contraseÃ±as del sistema una vez haya terminado el proceso de instalaciÃ³n del sistema operativo a fin de asegurarse de que todas las cuentas predeterminadas tienen contraseÃ±as invÃ¡lidas o han sido desactivadas o eliminadas.
Eliminar todas las cuentas que permiten Ãºnicamente la ejecuciÃ³n de un comando (por ejemplo "sync"). Si se permiten este tipo de cuentas, el administrador deberÃ¡ cerciorarse de que ninguno de los comandos que ejecutan acepta entradas de lÃnea de comandos y de que no permiten ningÃºn tipo de escape al shell que pueda permitir acceder a un shell de forma externa.

Usuario root

La contraseÃ±a de root ha de ser especial, por lo que es necesario seleccionarla con cuidado, guardarla en lugar seguro y modificarla a menudo.
Restringir el nÃºmero de usuarios en el sistema que tienen acceso a esta cuenta.
Evitar la existencia de archivos .rhosts en el directorio base del usuario root (normalmente /, o en Linux, /root/).
Evitar la existencia del "." en el path de bÃºsqueda del usuario root y de los administradores.
Hacer uso de rutas completas para ejecutar Ã³rdenes como root.
Evitar entrar por telnet como root a las mÃ¡quinas, para asÃ evitar la intercepciÃ³n del contraseÃ±a en texto en claro, que darÃa a un intruso acceso total al sistema. Queda entonces doblemente marcado como importante el uso de ssh como herramienta indispensable para entrar en las mÃ¡quinas remotamente.

ConfiguraciÃ³n de servicios mÃ¡s usuales

En este apartado vamos a comentar la configuraciÃ³n de algunos de los servicios mÃ¡s usuales que son ofrecidos por las organizaciones, sin entrar en detalle, pues estos temas ya se tratan en los Grupos de Trabajo correspondientes.

ConfiguraciÃ³n del sistema de correo

El servicio de correo es uno de los mÃ¡s fÃ¡ciles de configurar en la actualidad, aunque paradÃ³jicamente sigue siendo uno de los mÃ¡s problemÃ¡ticos en lo que a seguridad se refiere. En principio podemos clasificar los equipos en funciÃ³n de su papel en la transferencia del correo, en:

Equipos de usuario

: Sistemas que leen y almacenan localmente el correo de uno o varios usuarios. Estos equipos suelen ejecutar un ``lector de correo'' o agente de usuario para obtener los correos. Suelen ser Pc's con Eudora, Outlook, Netscape o sistemas multiusuarios Unix con mh, pine, mutt, etc. En cualquier caso, para la lectura y almacenamiento de los correos en equipos Unix no es necesario que exista un proceso escuchando en el puerto 25 (SMTP), ni en los puertos de lectura de correo (110 (POP3) o 141(IMAP)).

Equipos de almacenamiento de correo

: Equipos en los que se almacena el correo a la espera de ser leÃdo desde los equipos de usuario. Para ello suelen emplear el protocolo pop3 (puerto 110), y en algunos casos emplean imap (141). Para la recepciÃ³n de correo suelen ejecutar el programa sendmail en el puerto 25, aunque tambiÃ©n es posible emplear otros programas, como smap/smapd del fwtk (firewall-toolkit), para no tener que ejecutar sendmail.

Equipos de intercambio de correo

: Son los encargados de transferir el correo entre Internet y las organizaciones. Estos equipos deben tener un registro MX en el DNS, y tener establecido su direccionamiento inverso. AdemÃ¡s en el router se debe filtrar el trÃ¡fico de la organizaciÃ³n para que sÃ³lamente se produzcan accesos al puerto 25 de las servidores que estÃ¡n definidos en el DNS como MX (Mail eXchanger). Deben ejecutar sendmail, Postfix o un programa similar escuchando continuamente en el puerto 25.

La configuraciÃ³n de este servidor es crucial para el buen funcionamiento del servicio de correo. Se debe instalar la versiÃ³n mÃ¡s actual del programa sendmail (el suministrado en muchos S.O., salvo Linux o FreeBSD, suele ser bastante antiguo) y configurarlo adecuadamente para que no pueda ser empleado para la distribuciÃ³n de correo basura (SPAM).

Consulte http://www.rediris.es/mail para mÃ¡s informaciÃ³n sobre como configurar el servicio de correo en las organizaciones afiliadas a RedIRIS.

En los equipos de almacenamiento, procure que las cuentas de correo no estÃ©n vinculadas directamente a una cuenta del sistema, o que Ã©sta estÃ© bloqueada salvo que sea necesaria. Evite la circulaciÃ³n de las claves en claro mediante el uso de APOP, desactive las cuentas de los usuarios que han dejado de pertenecer a la organizaciÃ³n, sustituyendo las cuentas por alias a sus nuevas direcciones de correo.

ConfiguraciÃ³n del DNS

El servicio de DNS es crucial para la conexiÃ³n a Internet. Sin embargo en muchas organizaciones no estÃ¡ configurado adecuadamente. Como en el correo, la configuraciÃ³n de este servicio ha sido explicada en el Grupo de Trabajo correspondiente, pero sin embargo creemos que se debe destacar:

1.

Tener una versiÃ³n actualizada del servidor de nombres: Es conveniente actualizar a una versiÃ³n moderna del servidor. Las Ãºltimas versiones son mÃ¡s seguras y permiten establecer filtros y limitaciones en las transferencias de zonas, actualizaciones no solicitadas de datos, etc.

2.

Tener configurado el direccionamiento inverso: Muchas instituciones no tienen establecido el direccionamiento inverso para los equipos, lo que dificulta muchas veces el acceso a determinados servicios o la monitorizaciÃ³n en los registros.

3.

Denegar el acceso a las zonas a otros servidores: Es conveniente que los servidores DNS estÃ©n configurados para permitir las transferencias de zona solamente a los servidores que estÃ©n definidos como secundarios; asÃ se evita el que se pueda obtener informaciÃ³n sobre la topologÃa y configuraciÃ³n de la red desde el exterior.

4.

No poner configuraciones de equipos en el DNS: Es posible indicar en los registros de DNS quÃ© sistema operativo, arquitectura hardware, e incluso quÃ© servicios se estÃ¡n ejecutando en la mÃ¡quina. Esta informaciÃ³n se puede emplear para atacar desde fuera de la organizaciÃ³n.

5.

ConfiguraciÃ³n en los clientes: En los filtrados de puertos (con tcp_wrapper) o en listas de acceso (en ficheros hosts.allow y hosts.deny), emplear nombres cualificados por completo y no sÃ³lo el nombre del equipo, para evitar que un equipo de otra organizaciÃ³n que se llama igual pueda tener acceso al sistema.

6.

Aspectos generales de configuraciÃ³n: Como norma general, se debe cumplir que:

No se deben configurar los servidores de DNS para que reenvÃen las peticiones (hagan ``forward'') a equipos de RedIRIS.
No se deben configurar DNS como secundarios de otra organizaciÃ³n, salvo autorizaciÃ³n explÃcita de la otra parte.
A ser posible se deben tener dos servidores, primario y secundario, en una misma organizaciÃ³n, y por tanto tener especificados ambos equipos como servidores de nombres en la configuraciÃ³n de todos los equipos.

ConfiguraciÃ³n de los servidores WWW

Los equipos servidores WWW son susceptibles a varios tipos de ataques. Algunas medidas para evitarlos:

1.: Dimensione el equipo adecuadamente, para evitar que se produzcan ataques de denegaciÃ³n de servicio (DoS).
2.: Instale una versiÃ³n actualizada del servidor WWW.
3.: Salvo que sea necesario, deniegue el uso de CGI's que no sean los empleados por los administradores, elimine los CGI's de prueba, que suelen tener vulnerabilidades de seguridad, y desactive las extensiones del servidor (PHP, Server-Side Includes, servlets de java, etc.) salvo que sean necesarios.
4.: En caso de que los usuarios deban programar CGI's, adviÃ©rtales de los fallos mÃ¡s comunes que pueden existir y como solucionarlos
(ftp://ftp.cert.org/pub/techtips/cgimetacharacters).
5.: No comparta las pÃ¡ginas de los servidores mediante un sistema de ficheros; emplee un sistema de replicaciÃ³n (wget, mirror, etc.) para realizar el intercambio de las pÃ¡ginas.

ConfiguraciÃ³n de los servidores FTP

Lo servidores de FTP se han empleado en muchas ocasiones para el almacenamiento de software ilegal, propiciando el abuso de este servicio y muchas veces la sobrecarga de procesamiento de los servidores. Unas recomendaciones generales sobre este servicio son:

1.: Instalar una versiÃ³n del servidor actualizada, y fiable: Las versiones del servidor FTP que vienen con los sistemas operativos comerciales suelen tener pocos parÃ¡metros de configuraciÃ³n, y tambiÃ©n varios fallos de seguridad. AÃºn en el caso de que no se vaya a emplear el equipo como servidor de FTP, instale una versiÃ³n actual de ProFTPd o wuFTPD, que proporcionan bastantes opciones a la hora de configurar el nÃºmero mÃ¡ximo de conexiones, orÃgenes de la conexiÃ³n,etc.
2.: En caso de que no se emplee el servicio de FTP anÃ³nimo, deshabilitarlo. En caso de que se emplee, salvo que sea necesario no permitir que el usuario FTP tenga permisos de escritura en ningÃºn directorio, y en caso de que tenga que escribir, mantener este directorio en otro sistema de ficheros y evitar que el usuario tenga permisos de lectura y/o creaciÃ³n de directorios, para evitar la creaciÃ³n de repositorios de programas pirateados (http://www.rediris.es/cert/doc/docu_rediris/ftpconfig.es.html).
3.: No emplear el servicio de FTP para la transmisiÃ³n de documentos o ficheros importantes entre equipos, pues las claves de conexiÃ³n se transmiten en claro. Use en su lugar scp, un reemplazo de rcp que viene con el paquete ssh.

Servidores de ficheros

Hace algunos aÃ±os era frecuente el empleo de servidores de ficheros en los sistema Unix para la comparticiÃ³n de software entre las diversas estaciones de trabajo. En la actualidad es frecuente encontrar sistemas de ficheros en red, de los que el mÃ¡s conocido es el soporte de NetBios sobre IP (Windows 3.11/9x/ME/NT/2000 principalmente, pero tambiÃ©n Unix con Samba). Su incorporaciÃ³n a la red se debe hacer tomando algunas medidas de seguridad.

Servidores NFS

El acceso NFS es frecuente en entornos Unix puros, aunque existen clientes y servidores para Windows 9x/NT/2000 y Novell Netware. Algunos puntos que hay que comprobar a la hora de configurar un servidor NFS deben ser:

1.: Emplear servidores/clientes de NFS recientes. Inicialmente los servidores de NFS empleaban UDP como protocolo de transporte, pudiendo alterarse fÃ¡cilmente las conexiones y realizar ataques simulando ser tanto el origen como el destino de las conexiones. La versiÃ³n 3 del protocolo NFS permite usar TCP y emplea claves criptogrÃ¡ficas para evitar la suplantaciÃ³n de los equipos.
2.: No exportar directorios con permisos de escritura. Salvo que sea estrictamente necesario, exportar los sistemas de ficheros con permisos de sÃ³lo lectura, de forma que no se pueda escribir en ellos. En caso de que se tengan que exportar sistemas de ficheros con permisos de escritura (directorios personales de usuarios, por ejemplo), no exporte jerarquÃas de directorios que contengan binarios. En las estaciones clientes evitar montar sistemas de ficheros con permiso de ejecuciÃ³n.
3.: Restringir los accesos. No exportar ficheros de configuraciÃ³n, indicar en las opciones de exportaciÃ³n quÃ© equipos son los que pueden montar los recursos, y emplear para ello las direcciones IP o los nombres DNS **COMPLETOS**, para evitar suplantaciones de los equipos.

Servidores NetBios

NetBios se puede emplear sobre diversos protocolos de transporte. Su utilizaciÃ³n original empleaba un protocolo denominado NetBEUI, que no permite el enrutado de los paquetes. Sin embargo, ahora mismo NetBios se emplea sobre TCP/IP, en servidores Windows y Unix. Algunos problemas de seguridad que tiene este protocolo son:

Recomendamos, con toda rotundidad, que Windows 9x/ME se considere comprometido desde el mismo momento en que se arranca. Ninguna versiÃ³n de Windows 9x/ME deberÃa ser jamÃ¡s utilizada en cualquier ordenador de una red donde algÃºn recurso necesite ser asegurado.
En sistemas NT/2000 es preciso tener instaladas las Ãºltimas versiones de los parches existentes (Service Packs), ya que las primeras implementaciones de los servidores tienen diversos problemas que abren la puerta a ataques de denegaciÃ³n de servicio (DoS).
Evitar la exportaciÃ³n de sistemas de ficheros que contengan ejecutables con permisos de escritura, tanto para evitar la suplantaciÃ³n de los binarios como para evitar la proliferaciÃ³n de virus.
En los servidores NT/2000 tener restringido y especificado siempre el acceso al grupo Todos y despuÃ©s permitir los accesos en funciÃ³n de los grupos de usuario. Hay que tener en cuenta que si estos servicios estÃ¡n abiertos a todo el mundo es posible acceder a ellos desde cualquier direcciÃ³n IP.
En servidores NT/2000 emplear como sistema de ficheros NTFS, ya que permite especificar derechos individuales a los usuarios. Por ello recomendamos no emplear FAT.
En el caso de exportar directorios particulares de usuarios, emplear un sistema de cuotas en el servidor, ya sea mediante la instalaciÃ³n del parche correspondiente (Service Pack 4 o superior en NT), empleando las utilidades de Windows 2000, o empleando un equipo Unix con Samba y cuotas de disco, para evitar que un usuario pueda llenar la particiÃ³n.
Si se emplea Samba, procurar que las claves de acceso no sean las mismas que las de las cuentas de usuarios en los equipos. Emplear, si es posible, un servidor de autenticaciÃ³n externo (PDC) para evitar que las claves puedan ser obtenidas mediante un sniffer de red o por alguno de los virus y troyanos que estÃ©n apareciendo cada vez con mÃ¡s frecuencia en entornos Windows.

MonitorizaciÃ³n de archivos de registro

En Unix existen diversos mecanismos para que quede constancia de toda la actividad de un proceso. El mÃ¡s simple de estos mecanismos es que el proceso en cuestiÃ³n vaya escribiendo una especie de registro de todo lo que hace en un fichero (lo normal es llamar a estos registros "logs", aunque hay palabras en castellano de sobra, como "registros" o "histÃ³ricos").

Este mÃ©todo tendrÃa sus limitaciones:

si dos procesos escriben sus informes simultÃ¡neamente al mismo fichero el resultado final puede ser confuso.
no nos sirve de mucho si queremos almacenar, a medida que se producen, copias de estos informes en otra mÃ¡quina distinta.
en algunos casos no nos basta con llevar un registro: hay situaciones de emergencia que deben avisarse inmediatamente.
lo ideal es que estos ficheros no puedan ser modificados por cualquiera (o poco valor tendrÃan como registro fiable), pero interesa que cualquier programa tenga capacidad de generarlos, lo cual es una contradicciÃ³n.

Para solucionar estas limitaciones se creÃ³ el sistema 'syslog' de Unix. EstÃ¡ compuesto por lo siguiente:

Un proceso privilegiado (syslogd), capaz de generar ficheros de log y avisos bassÃ¡ndose en determinadas configuraciones hechas por el administrador.
Un servicio TCP/IP (514/udp), que permite enviar mensajes syslog de una mÃ¡quina a otra.
Un fichero de configuraciÃ³n (/etc/syslog.conf).

ConfiguraciÃ³n

El fichero /etc/syslog.conf permite especificar quÃ© acciones se llevan a cabo cuando un determinado programa solicita registrar una actividad. Syslog clasifica las actividades a registrar segÃºn dos parÃ¡metros: subsistema (facility) y severidad.

El subsistema depende de quiÃ©n ha generado el informe: el nÃºcleo, sistema de correo, news, etc. La severidad indica la prioridad que se le asigna a cada uno de los mensajes, desde los de depuraciÃ³n (debug) hasta los de emergencia y/o pÃ¡nico. Consulte la pÃ¡gina de manual de ``syslogd.conf'' para mÃ¡s informaciÃ³n.

El fichero de configuraciÃ³n permite asignar acciones por subsistema y severidad. Por ejemplo:

		mail.info			/var/log/mail
		mail.err			/var/log/mail-errores
		kern.crit			root
		kern.emerg			*
		auth.info			/var/log/auth
		auth.info			@otramaquina

Esto significa:

Los informes relacionados con correo, que tengan severidad ``informativa'' o mayor se almacenan en el fichero /var/log/mail.
Si tienen severidad ``error'' o mayor, se almacenan en otro fichero
/var/log/mail-errores.
Si se produce un mensaje crÃtico del sistema, no esperamos a almacenarlo en ningÃºn sitio; se escribe inmediatamente un mensaje a `root' donde quiera que estÃ©, para que sepa lo que pasa.
Si ese mensaje es ademÃ¡s del tipo ``emergencia'', no sÃ³lo avisaremos a root sino a todos los usuarios (es lo que pasa cuando se hace un shutdown, por ejemplo).
Los informes de seguridad, de severidad ``info'' o mayor, no sÃ³lo se guardan en el fichero /var/log/auth sino que ademÃ¡s se mandan a la mÃ¡quina ``otramaquina'' (Ã©sto asume que hay un syslog corriendo en ``otramaquina'', que el puerto 514/udp de la misma estÃ¡ accesible y que ese syslog estÃ¡ a su vez configurado).

Particularidades

Se deben utilizar tabuladores y no espacios en el fichero /etc/syslog.conf.
El valor de severidad 'notice' no se puede combinar con otros, debe aparecer solo en una lÃnea.
El comodÃn * equivale a todos los subsistemas excepto `mark'.

Uso desde programas

Los programas en C usan llamadas al sistema para acceder a syslog. Sin embargo, los scripts tambiÃ©n pueden hacerlo. Si son en Perl, la forma mÃ¡s fÃ¡cil es usar el mÃ³dulo Perl Sys::Syslog (man Sys::Syslog).

Tanto en Perl como desde el shell se puede usar el programa logger:

		logger -p mail.err Error entregando mensaje.

que enviarÃ¡ dicho informe como subsistema 'mail' y severidad 'err'.

Existen otras opciones (ver man logger).

RotaciÃ³n de ficheros de registro

El problema de almacenar registros histÃ³ricos o logs es que Ã©stos crecen, y tarde o temprano llenan el disco. Para evitar esto, se recurre a la rotaciÃ³n de logs.

Ejemplo de fichero rotado mensualmente:

1.

Antes de empezar:

/var/log/milog se crea vacÃo.

2.

Al primer mes:

/var/log/milog se renombra como /var/log/milog.1

3.

Al segundo mes:

/var/log/milog.1 se renombra como /var/log/milog.2
/var/log/milog se renombra como /var/log/milog.1
/var/log/milog se "vacÃa" de nuevo.

Por supuesto, almacenaremos un nÃºmero limitado de meses (o semanas, o dÃas), o Ã©sto no servirÃa de nada. AdemÃ¡s, los registros de meses (semanas, dÃas) anteriores se pueden comprimir.

Hacer esto tiene su truco. No se puede borrar impunemente un fichero que estÃ¡ abierto por un proceso (syslogd, en este caso), mejor dicho, no se debe, ya que los resultados no serÃ¡n los que nos imaginamos.

La manera correcta de vaciar un fichero abierto es:

		cp /dev/null <fichero>

Otros aspectos relacionados

Algo mÃ¡s sobre los aspectos de seguridad: cuando se almacenan registros con finalidad informativa (estadÃsticas, etc) suele bastar con almacenarlos en la misma mÃ¡quina donde se generan. Cuando se almacenan por motivos de seguridad, sin embargo, nos interesa preservar una copia en otra mÃ¡quina. El motivo es que si hay una intrusiÃ³n en la primera mÃ¡quina podrÃ¡n borrar o modificar los registros, pero esas mismas actividades quedarÃ¡n registradas en la segunda, avisando asÃ a los operadores.

Normalmente, la mÃ¡quina que reciba los logs (loghost) no debe recibir otra cosa (para no ser susceptible de ataques) ni debe poder recibir logs desde fuera de la red local (para evitar ataques por saturaciÃ³n). Para evitar consultas al DNS cada vez que se genere un informe, la direcciÃ³n IP de esta mÃ¡quina debe estar en el fichero /etc/hosts de las mÃ¡quinas que manden informes.

ComprobaciÃ³n de integridad

Una vez que se ha accedido a un sistema es frecuente modificar los binarios de algunos servicios y programas del sistema operativo para permitir su acceso posterior. AsÃ mismo se pueden modificar los ficheros de configuraciÃ³n de los servicios para hacerlos mÃ¡s vulnerables. Para evitar esto se suele emplear herramientas de comprobaciÃ³n de integridad. Estos programas funcionan en dos fases; primero se crea la base de datos de integridad, empleando varios algoritmos criptogrÃ¡ficos para obtener una ``huella dactilar'' de cada uno de los ficheros. En una fase posterior se comprueban periÃ³dicamente los ficheros existentes en el sistema de ficheros con las firmas que ha generado este programa, pudiendo asÃ averiguar si se ha producido alguna modificaciÃ³n en los mismos.

Existen varias herramientas que permiten realizar esta comprobaciÃ³n de integridad. La mÃ¡s conocida es quizÃ¡ Tripwire. Este programa permite emplear varios algoritmos criptogrÃ¡ficos a la hora de generar la base de datos (MD2, MD4, MD5, SHA, Snefru, CRC-32), para evitar que un atacante pueda modificar los ficheros. La ultima versiÃ³n de Tripwire disponible de uso general es la versiÃ³n 1.3, disponible en el servidor FTP de Rediris. Desde el aÃ±o pasado la Universidad de Purdue transfiriÃ³ la licencia a la empresa Tripwire Security System, que ha desarrollado una nueva versiÃ³n, la 2.0 disponible tambiÃ©n para entornos Windows NT. Sin embargo, y dado que las diferencias son mÃnimas con respecto a la versiÃ³n 1.3, emplearemos Ã©sta como referencia.

InstalaciÃ³n de Tripwire

Tripwire estÃ¡ disponible en el repositorio de programas de seguridad de RedIRIS (ftp.rediris.es/soft/rediris/cert) en cÃ³digo fuente para los sistemas Unix. AsÃ mismo estÃ¡ compilado en formato de paquete para algunas distribuciones Linux. La compilaciÃ³n no suele dar problemas y una vez instalado se emplea el fichero de configuraciÃ³n /usr/local/bin/tw/tw.config para indicar quÃ© ficheros se deben comprobar.

ConfiguraciÃ³n de Tripwire

Un ejemplo serÃa:

/root                   R
/                       R
/vmlinuz                R
/boot                   R
/etc                    R
/etc/inetd.conf         R
/etc/rc.d               R
/etc/exports            R
/etc/mtab               L
/etc/motd               L
/etc/group              R     
/etc/passwd             L
/usr                    R
/usr/local              R
/dev                    L-am
/usr/etc                R
=/home                  R
/var/spool              L
/var/log                L
/var/spool/cron         L
/var/spool/mqueue       L
/var/spool/mail         L
/sbin                   R
=/proc                  E
=/tmp
=/cdrom

Como se ve, cada una de las entradas estÃ¡ formada por un identificador del directorio o fichero que se debe monitorizar y despues una serie de flags. Tripwire por defecto viene con una serie de identificadores predefinidos (R, L, E, etc.) para indicar distintas situaciones, como por ejemplo el que los ficheros sean de sÃ³lo lectura (R), ficheros de log (L), o ficheros que se deben excluir (E), etc. Consulte la pÃ¡gina del manual para ver las distintas opciones de Tripwire.

Una vez definido el fichero de configuraciÃ³n se debe ejecutar el comando tripwire con la opciÃ³n de crear la base de datos (tripwire -initialize). De esta forma Tripwire calcularÃ¡ los hash (las huellas) de cada uno de los ficheros y almacenarÃ¡ la informaciÃ³n en los ficheros de la base de datos. Una vez generada la base de datos se debe almacenar en un dispositivo de sÃ³lo lectura (como un CD-ROM) o copiada a otro equipo para evitar que un intruso pueda modificarla. En sistemas con dispositivos removibles donde se pueda bloquear fÃsicamente la escritura (disquetes), se puede copiar ahÃ la base de datos y despuÃ©s protegerlos contra escritura (en las unidades ZIP el bloqueo se realiza a nivel software, por lo que esta medida no es vÃ¡lida).

De esta forma es posible lanzar un proceso periÃ³dicamente que compruebe la integridad de los ficheros para evitar modificaciones, y actualizar manualmente la base de datos cuando se actualice el sistema operativo o se apliquen parches a Ã©ste.

Seguimiento de procesos

En gran parte de los sistemas Unix es posible ejecutar procesos de ``accounting'' o ``contabilidad'' para ir registrando el uso de los recursos de los equipos por parte de los usuarios y los procesos. La forma de configurar el sistema para que realize estos mÃ©todos de ``accounting'' suele depender mucho del sistema operativo del equipo, ya que suele realizarlo el nÃºcleo (kernel) de Ã©ste, volcÃ¡ndose a ficheros cada cierto perÃodo de tiempo y realizando un procesamiento estadÃstico de estos datos. Antiguamente los procesos de accounting solÃan requerir bastante tiempo de procesamiento y eran difÃciles de configurar y administrar. Sin embargo en la actualidad, la activaciÃ³n del accounting se suele realizar por la ejecuciÃ³n de un script en el arranque del sistema y la utilizaciÃ³n de otro script para realizar las estadÃsticas durante la noche.

Las principales ventajas que tiene este sistema es poder analizar quÃ© procesos se estÃ¡n ejecutando en el sistema, asÃ como los usuarios que los realizan, pudiendo ver si algÃºn usuario estÃ¡ ejecutando algÃºn proceso en segundo plano o se ha producido algÃºn ataque de saturaciÃ³n contra un servidor. Consulte la documentaciÃ³n del sistema operativo para ver cÃ³mo activar estos procesos de ``accounting''.

Actualizaciones de software

SerÃa conveniente dar algunas recomendaciones que permitan a los administradores disponer de un sistema automatizado para la recogida, instalaciÃ³n y notificaciÃ³n de parches. Algunas de estas recomendaciones se pueden resumir en los siguientes puntos:

ActualizaciÃ³n de los sistemas, tan pronto sea posible, a la Ãºltima versiÃ³n facilitada por el fabricante.
AplicaciÃ³n de todos los parches ``recomendados'' hasta el momento para esa versiÃ³n del sistema operativo. SerÃa aconsejable la utilizaciÃ³n de un script que se conectase al servidor FTP del fabricante concreto y aplicase los parches necesarios de forma automÃ¡tica.
Mantenga correctamente parcheados los sistemas utilizando algunos de los siguientes mÃ©todos:

1.
Parcheado incremental. UtilizaciÃ³n de un script que periÃ³dicamente aplique los parches necesarios desde la Ãºltima aplicaciÃ³n, sin intervenciÃ³n humana y con notificaciÃ³n al administrador.
2.
Obtener una lista de parches necesarios (incremental), despuÃ©s decidir quÃ© parches son realmente necesarios para el sistema concreto y aplicarlos. Hay parches que aunque se recomiendan para una versiÃ³n de un sistema operativo concreto, si no se posee un determinado software o paquete instalado, no es necesario aplicarlo. TambiÃ©n ocurre al contrario, hay parches necesarios para una determinada versiÃ³n de software instalado que no se incluyen en los parches recomendados para esa versiÃ³n del S.O.

Para aquellos administradores que dispongan de mÃ¡quinas Solaris, se puede obtener un sistema de recogida automÃ¡tica de parches en:

http://www.um.es/alfonso/

Footnotes

... inetd ^4.1: El proceso inetd es un ``superservidor configurable'', empleado para escuchar en varios puertos simultÃ¡neamente y lanzar el programa adecuado para cada servicio. Para mÃ¡s informaciÃ³n, consulte las pÃ¡ginas de manual de este comando.
... conexiÃ³n.^4.2: En servidores que generan una carga elevada y que tienen su propio sistema de control de acceso y de histÃ³ricos no es necesario el empleo de tcp_wrapper.
... sniffers"^4.3: Herramientas de monitorizaciÃ³n y de red que permiten leer toda la informaciÃ³n que circula por un segmento de la red, pudiendo asÃ obtener las claves de acceso a las sesiones de terminal(telnet), ftp, http y servicios mÃ¡s comunes

IRIS CERT