SEGURIDAD
PREG>
Es cierto que cualquiera puede hacerse root usando el
SuperProbe. O mirando el archivo /var/adm/message. NO debería ser
legible por cualquiera !!!. Parece ser que en Linux los directorios exportados
para NFS, por ahi tambien se pueden hacer root, INCLUSO sin tener cuenta.
RESP>
Existen distintos problemas de seguridad en un sistema
multiusuario, entre ellos la posibilidad de que un usuario local obtenga
privilegios de superusuario. !Ojo! Utilizo usuario local como "aquel que
puede ejecutar programas en la maquina". No simplemente un usuario que
tiene un buzón de correo al que accede mediante POP. Si el usuario
no puede ejecutar programas en la maquina, el escenario es similar al de
un "invasor" proveniente de cualquier parte de la red. Para que un usuario
local se haga root, tiene que explotar un fallo de seguridad o de configuración
en algún programa que se ejecute con la personalidad de root (suid
root). Cualquier programa suid root es un peligro potencial, pero lo es
más que el administrador tenga mal configurado su sistema. (O que
venga mal configurado en su distribución). Asi, de tus ejemplos,
el SuperProbe, cuyo problema no es mas peligroso que cualquier otro, sino
a la inversa, no tiene porque ser suid root. A fin de cuentas,
ese programa solo sirve para hacer un chequeo del sistema de video cuando
queremos instalar las X, y se supone que eso sslo tiene razsnes para hacerlo
el superusuario. Si el SuperProbe no esta instalado suid root, no
es peligroso (En Debian no viene instalado suid root). En cuanto al /var/adm/messages
, estamos en las mismas. ?Por que no debe ser legible por cualquiera? Dependerá
de la información que según nuestro /etc/syslog.conf deba
ir a ese fichero. En particular es una situación bastante común
que cuando un usuario introduce su password en lugar de su login, aparezca
el típico mensaje "Login incorrect", y el usuario introduzca bien
su login y su password, entrando en su cuenta con normalidad. El problema
está en que si nuestro syslogd esta configurado para mandar los
errores de autentificación al /var/adm/messages, ahora tendremos
una hermosa linea tal como: .... Apr 15 16:05:15 remoto login: 1 LOGIN
FAILURE ON tty1, ConTraSeqa .... !Hop! basta comprobar quién se
conectó en tty1 a las 16:05:15 + unos pocos segundos y ya tenemos
su contraseña. Así que lo correcto es desviar toda la información
"sensible" a un fichero que solo pueda leer root, no es necesario ocultar
toda la información del /var/adm/messages . (En Debian, la
información "sensible" va a parar a /var/adm/auth.log , permisos
-rw-r----- root.adm) Como ves, en ambos casos se trata de un error de configuración,
facilmente subsanable. Es distinto el caso de los programas que si tienen
que correr suid root (como el mount) en los cuales el programador tiene
que poner especial cuidado para no cometer errores. Si además el
programa es un servidor que recibe información del exterior (sendmail,
ftp, ...) un error de seguridad es una puerta abierta a los "invasores".
Como ningun programador es perfecto, a veces existen esos errores, (en
todos los sistemas, no solo en Linux, e incluso en algunos supuestamente
C2) La mayor ventaja de los programas para Linux en ese terreno proviene
de que las fuentes están a disposición de todos, con lo que
es mucho más facil detectar y corregir esos errores, tardandose
usualmente unas pocas horas entre que se detecta el fallo y se corrige.
Además las fuentes suelen ser comunes con otros sistemas Unix, con
lo que han sido revisadas durante mucho tiempo por mucha gente. Las distribuciones
serias de Linux suelen corregir los problemas de seguridad en menos de
una semana, como sabe cualquiera que reciba las listas linux-security o
linux-alert (En Debian, las correciones de agujeros de seguridad se incorporan
inmediatamente a la versión "stable" de la distribución)
Queda en manos del administrador mantener su sistema seguro actualizando
los programas, libre y gratuitamente. De todos modos, teniendo
en cuenta el volumen de ambas listas, es facil comprobar que los errores
de seguridad en programas bajo Linux no son tantos. (Vale la pena comparar
revisando los archivos de Bugtraq, por ejemplo.) También puede ocurrir
que el problema provenga de un error de diseño en un protocolo,
bien por descuido, bien por que el protocolo se diseña teniendo
en cuenta un escenario y luego se aplica a otro. Este es el caso de los
SYN-Floods o de alguna de las debilidades del NFS. Aquí el peligro
también esta en los "ataques" desde el exterior. Pero el problema
es común a todas las implementaciones del protocolo, independientemente
del sistema operativo. Para resolverlo hay que acudir a complementar el
protocolo o redefinirlo. La ventaja para nosotros radica en que los protocolos
que se usan actualmente en la Internet han vivido durante años un
proceso de desarrollo y discusión en un entorno abierto, que ha
ido eliminando sus puntos dibiles, aprovechando para cada versión
la experiencia adquirida con las versiones anteriores. Y utilizando sistemas
Unix para las implementaciones, con la disponibilidad para Linux es practicamente
inmediata. Por todo lo cual, creo que la gente con ISPs bajo Linux puede
estar tranquila. Una distribucisn moderna de Linux es de los sistemas más
seguros tal cual sale del CD-ROM, y con los programas adecuados, sin lugar
a dudas sera más seguro como servidor en Internet que otras opciones
con mejor marketing. Si sirve de ejempo, Deja-News funciona bajo Linux,
y no es precisamente un servidor con pocos accesos. (Hace bastante tiempo
encontré una encuesta realizada a ISPs en EEUU en la que se daban
las proporciones de uso de sistemas operativos, dando como ganador absoluto
a Sun, y muy buenos resultados para Linux. Si alguien sabe de alguna encuesta
reciente sería interesante conocerla). Por supuesto, es recomendable
que el administrador del sistema no se duerma en los laureles y conozca
algo de seguridad en redes, pero eso es igual para todos, y cualquier libro
de seguridad en sistemas Unix (hay cientos) puede servir de guía.
Debian cuenta entre sus desarrolladores con varios expertos en seguridad,
que examinan el sistema intensivamente. No sólo se corrigen los
problemas que se descubren, sino que se trabaja para minimizar el riesgo
en caso de que existan problemas (por ejemplo recomendando el uso de smail,
en vez de sendmail). A falta de una comparación rigurosa entre distribuciones,
Debian tiene el prestigio de ser una distribución especialmente
segura, y no se ha dudado en retrasar el lanzamiento de una versión
de la distribución para incorporar las últimas correcciones
de seguridad que habían aparecido pocos días antes. Por cierto,
hay informacisn sobre seguridad en Debian en sus paginas web (http://www.debian.org
o su mirror en España, http://www.es.debian.org )