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'.
© 2002 Antonio Villalón Huerta
