next up previous contents
Siguiente: Usuarios y accesos al Subir: Solaris Anterior: Seguridad física en SPARC   Índice General

Servicios de red

Probablemente el primer aspecto relacionado con la seguridad al que debemos prestar atención en un sistema Solaris es a los servicios ofrecidos desde inetd; con la instalación out of the box el número de puertos a la escucha es realmente elevado, y muchos de ellos son servidos desde inetd (después hablaremos de los servicios que se inician al arrancar el sistema). Aparte de los servicios clásicos (telnet, finger...) que - como en el resto de Unices - es imprescindible deshabilitar, en Solaris encontramos algunas entradas de /etc/inetd.conf algo más extrañas, que en muchos casos no sabemos si podemos eliminar (o comentar) si que ello afecte al funcionamiento de la máquina: se trata de ciertos servicios basados en RPC, como cmsd o sprayd. En casi todos los servidores podemos deshabilitar estos servicios sin mayores problemas, pero evidentemente tomando ciertas precauciones: es necesario conocer cuál es la función y las implicaciones de seguridad de cada uno de ellos; en [Fly00a] (especialmente en la segunda parte del artículo) se puede encontrar una referencia rápida de la función de algunos de estos servicios `extraños', así como notas con respecto a su seguridad.

Realmente, de todos los servicios ofrecidos por inetd ninguno es estrictamente necesario, aunque por supuesto alguno de ellos nos puede resultar muy útil: lo normal es que al menos telnet y ftp se dejen abiertos para efectuar administración remota. No obstante, algo muy recomendable es sustituir ambos por SSH, que permite tanto la terminal remota como la transferencia de archivos de forma cifrada; si nos limitamos a este servicio y lo ofrecemos desde inetd, esta será la única entrada no comentada en /etc/inetd.conf:
anita:/# grep -v ^\# /etc/inetd.conf
ssh     stream  tcp     nowait  root    /usr/local/sbin/sshd    sshd -i
anita:/#
Otros de los servicios que Solaris ofrece tras su instalación son servidos por demonios independientes que se lanzan en el arranque del sistema desde scripts situados en /etc/init.d/ y enlazados desde /etc/rc2.d/ y /etc/rc3.d/; al igual que sucedía con los servidos desde inetd, muchos de estos servicios no son necesarios para un correcto funcionamiento del sistema, y algunos de ellos históricamente han presentado - y siguen presentando - graves problemas de seguridad. No vamos a entrar aquí en cuáles de estos servicios son necesarios y cuáles no, ya que eso depende por completo del tipo de sistema sobre el que estemos trabajando; es necesario conocer las implicaciones de seguridad que algunos de los demonios lanzados en el arranque presentan, y para ello una buena introducción es [Fly00b].

Al arrancar una máquina Solaris, por defecto el proceso init situa al sistema en su runlevel 3, lo cual implica que - entre otras acciones - se invoca a /sbin/rc2 y /sbin/rc3; estos dos shellscripts se encargan de recorrer los directorios /etc/rc2.d/ y /etc/rc3.d/, ejecutando cualquier fichero cuyo nombre comience por `S'. De esta forma, para evitar que un determinado script se ejecute automáticamente al arrancar una máquina lo más recomendable es ir directamente a /etc/rc2.d/ o /etc/rc3.d/ y sustituir la `S' inicial de su nombre por otro carácter; esta práctica suele ser más habitual que eliminar el fichero directamente, ya que así conseguimos que si es necesario lanzar de nuevo el script al arrancar Solaris no tengamos más que cambiarle de nuevo el nombre. Por ejemplo, si queremos que el demonio sendmail no se lance en el arranque, no tenemos más que ir al directorio correspondiente y renombrar el script que lo invoca; aparte de eso, es probable que nos interese detenerlo en ese momento, sin esperar al próximo reinicio del sistema:
anita:/# cd /etc/rc2.d/
anita:/etc/rc2.d# mv S88sendmail disabled.S88sendmail
anita:/etc/rc2.d# ./disabled.S88sendmail stop
anita:/etc/rc2.d#
Podemos ver que para detener el demonio hemos invocado al mismo fichero que lo arranca, pero pasándole como parámetro `stop'; si quisiéramos relanzar sendmail, no tendríamos más que volver a ejecutar el script pero pasándole como argumento `start'.
next up previous contents
Siguiente: Usuarios y accesos al Subir: Solaris Anterior: Seguridad física en SPARC   Índice General
2003-08-08