1.4 - Manejo de los demonios no deseados

Afine más su sistema deshabilitando todos los demonios no deseados y no utilizados para evitar que se ejecuten en el sistema. Puede hacer esto editando el archivo /etc/inetd.conf y los archivos o directorios rc.

Versiones: AT&T, BSD

Modifique el archivo /etc/inetd.conf y deshabilite los demonios innecesarios que se ejecutan en el sistema.

# vi /etc/inetd.conf
#
# Configuration file for inetd(1M).  See inetd.conf(4).
#
# To re-configure the running inetd process, edit this file, then
# send the inetd process a SIGHUP.        kill -HUP [PID]
#
#ftp    stream tcp  nowait root   /usr/sbin/in.ftpd    in.ftpd -l
#telnet stream tcp  nowait root   /usr/sbin/in.telnetd in.telnetd
#talk   dgram  udp  wait   root   /usr/sbin/in.talkd   in.talkd
#ntalk  dgram  udp  wait   root   /usr/sbin/in.ntalkd  in.ntalkd
#uucp   stream tcp  nowait root   /usr/sbin/in.uucpd   in.uucpd
#
#finger stream tcp  nowait nobody /usr/sbin/in.fingerd in.fingerd
#tftp   dgram  udp  wait   root   /usr/sbin/in.tftpd   in.tftpd
#bootps dgram  udp  wait   root   /usr/sbin/in.bootpd  in.bootpd
#talk   dgram  udp  wait   root   /usr/sbin/tcpd       in.talkd

Una vez que haya modificado el archivo /etc/inetd.conf y deshabilitado los demonios, encuentre la identificación (PID) del demonio inetd que se está ejecutando y reinícielo con el comando kill -HUP

Versiones: AT&T

# ps -ef | grep inetd
root 124   1     ?       S 30:57 /usr/sbin/inetd -s
ugu  10377 10378 pts/4    S  0:00 grep inetd

# kill -HUP 124

Versión: BSD

# ps -ax | grep inetd
124   ?        S 30:57 /usr/sbin/inetd -s
10377 pts/4    S  0:00 grep inetd

# kill -HUP 124

Si la contabilidad está activada, puede verificar los archivos de registro del sistema (/var/adm/messages o /var/adm/SYSLOG) para verificar que el demonio inetd ha reiniciado. Si vuelve a verificar la tabla de procesos, verá que el PID nunca cambió. No se supone que deba hacerlo. Un comando kill -HUP no termina el proceso, sino que envía una señal de corta (hangup). Muchos demonios, entre ellos inetd, al recibir esta señal vuelven a leer su archivo de configuración y siguen ejecutándose.

Si el proceso no se reinició y aún puede conectarse con los demonios, es posible (aunque no aconsejable) finalizar la ejecución del demonio inetd y reiniciarlo de forma manual. Si es posible, esto deberá hacerse en una sola línea de comando:

# kill 124; /usr/etc/inetd

Luego revise la tabla de procesos (ps -ef o ps -ax) para verificar que el demonio se está ejecutando. Esta vez tendrá un nuevo PID.

Veriones: BSD

Otra área que inicia los demonios controlados por el sistema o las aplicaciones son los archivos y directorios rc. Dependiendo de la versión, el área de inicio puede existir en la forma de archivos rc, o como una serie de archivos en un directorio rc.#. Los archivos rc, o los archivos dentro de los directorios rc.#, son scripts que realizan tareas de mantenimiento en los sistemas de archivos e inician demonios del sistema, que juntos ponen en funcionamiento al sistema operativo UNIX.

Ésta es una área muy peligrosa. Es aconsejable que sepa exactamente lo que sea deshabilitar antes de hacerlo. Si evita que un demonio o proceo se ejecute desde esta área, podría congelar inadvertidamente el sistema durante el inicio o evitar que el sistema entre en funcionamiento. Si esto le sucediera y ni siquiera puede iniciar en un estado de un solo usuario, se verá forzado a iniciar miniroot desde disquetes o CD-ROM. Le recomiendo hacer un respaldo de todos los archivos rc antes de modificarlos.

Después de modificar los archivos rc requeridos, es necesario reiniciar para verificar que los cambios surtirán efecto. Algunos administradores terminan los procesos asociados con los demonios en los archivos rc, esperan un par de horas y reincian cuando los usuarios se van a comer o a sus casas al final del día. Eso está bien, siempre y cuando no se le olvide hacerlo.

Hay ocaciones en las que un administrador se distrae en otro problema y se olvida de las modificaciones que efectuó en los archivos y directorios rc. ¿Qué pasa después? Puede imaginárselo. Unos días o una semana después, por una u otra razón, el sistema se reinciará o caerá. Luego, cuando el sistema comienza su proceso de incio, por algún error o mala suerte, esos cambios sin verificar no permiten que el sistema entre en funcionamiento. Acaba de agregar un nuevo problema a su lista de pendientes. Peor aún, usted podría no estar cerca en ese momento y su administrador suplente tendrá que resolver el problema sin imaginarse siquiera los cambios que usted afectó.

La mayoría de los fabricantes entregan las computadoras nuevas cargadas y equipadas con todo lo que pueden ofrecerle. Si recontruye el sistema desde cero, la instalación predeterminada instalá (la mayoría de los casos) más software del que en realidad necesita su sistema. Dado que en el mundo hay mas sistemas que administradores, a los fabricantes les interesa facilitarles las cosas al usuario tanto como sea posible. Por lo tanto ofrecen al usuario casi todo.

Las dos principales razones para efectuar estas modificaciones son seguridad y desempeño. Al deshabilitar los demonios innecesarios, bloquea posibles huecos, reduce el número de funciones del ssitema que tiene que administrar, libera espacio en la memoria y dedica menos tiempo de la CPU en la ejecución de procesos innecesarios.

Si no planea usar algún servicio, deshabilítelo. Debe evaluar cada sistema individualmente. Los sistemas de alto riesgo, los sistemas seguros y los independientes no necesitan aceptar peticiones de tftp, talkd o fingerd, y tal vez nunca necesiten aceptar ftp o incluso telnet. Desactívelos. Los usuarios de sistemas independientes que no se encuentran en una red o estén aislados, deberán deshabilitar bind, YP/NIS, bootpd, sendmail, routed y otros servicios de red; ya que no son necesarios.

En un mundo perfecto, los programadores e ingeniero no tratarán de compilar localmente en los servidores de archivos y absorberán todo el tiempo de la CPU. La única manera de evitar que esto suceda es deshabilitando telnetd, rshd y rlogind. La desventaja es que la administración del sistema sólo podrá realizarse localmente. Pero siempre hay que hacer sacrificios. Se han hecho cosas similares por razones de seguridad en los sistemas de firewall. En uno de estos sistemas, encontrará que hay muchos servicios deshabilitados además de éstos.