Subseccion

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:

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:

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 inetd4.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

Cuentas sin contraseña o contraseñas por defecto.

Contraseñas reutilizables

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

Cuentas especiales

Usuario root

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:

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:

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:

Para solucionar estas limitaciones se creó el sistema 'syslog' de Unix. Está compuesto por lo siguiente:

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:

Particularidades

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:
2.
Al primer mes:
3.
Al segundo mes:
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:

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

... inetd4.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