Capítulo 5. DISCUSIÓN
5.1 Conclusiones
ndd -set /dev/tcp tcp_strong_iss 2 #
anita:~# chmod 744 /etc/init.d/nddconf anita:~# chown root:sys /etc/init.d/nddconf
anita:~# ln /etc/init.d/nddconf /etc/rc2.d/S70nddconf anita:~#
Si queremos conocer mejor la configuraci´on de seguridad del subsistema de red de Solaris una
excelenteobra que no deber´ıa faltar en la mesa de ning´un administrador de sistemas es [NW99]; todo este punto est´a basado ampliamente en ella. Incluye, adem´as de explicaciones claras sobre el porqu´e del valor de cada par´ametro para prevenir posibles ataques, unshellscriptpara planificar en el inicio del sistema, much´ısimo m´as completo que el presentado aqu´ı, y aplicable a varias versiones de Solaris (incluyendo la 8); en sistemas en los que la seguridad es un factor a tener en cuenta (¿todos?) es casi obligatorio utilizar esta planificaci´on.
9.8
Par´ametros del n´ucleo
En el archivo /etc/system el administrador de un equipo Solaris puede definir variables para el n´ucleo del sistema operativo, como el n´umero m´aximo de ficheros abiertos por un proceso o el uso de memoria compartida, sem´aforos y mensajes para intercomunicaci´on entre procesos. En este aparta- do vamos a comentar algunos de estos par´ametros que pueden afectar a la seguridad; hablaremos especialmente de aquellos que pueden y deben ser limitados para evitar diversos tipos de negaciones de servicio, ataques que recordemos afectan a la disponibilidad de nuestros recursos.
Si deseamos ver el valor de alguno de los par´ametros en el kernel que se est´a ejecutando en este momento, lo podemos hacer con la orden adb(n´otese que no ofrece ning´unprompt, hemos de es- cribir directamente el par´ametro a visualizar, con un‘/D’al final para que nos muestre el valor en decimal):
anita:~# adb -k /dev/ksyms /dev/mem physmem 38da maxusers/D maxusers: maxusers: 56 maxuprc/D maxuprc: maxuprc: 901 ^d anita:~#
Una negaci´on de servicio muy t´ıpica en Unix es el consumo excesivo de recursos por parte de usuarios que lanzan – voluntaria o involuntariamente – demasiados procesos; esto es especialmente com´un en sistemas de I+D, donde muchos usuarios se dedican a programar, y un peque˜no error en el c´odigo (a veces denominado‘runaway fork’) puede hacer que el sistema se vea parado por un exceso de procesos activos en la tabla. La gravedad del problema aumenta si pensamos que tambi´en es muy habitual que los usuarios lancen simulaciones que tardan en ejecutarse varios d´ıas (o varias semanas), de forma que una parada inesperada puede causar la p´erdida de muchas horas de trabajo. Por tanto, parece obvio que es recomendable limitar el n´umero de procesos simult´aneos por usuario; en Solaris este n´umero est´a ilimitado por defecto, por lo que si deseamos asignar un valor m´aximo hemos de editar el fichero/etc/system e incluir una l´ınea como la siguiente:
set maxuprc=60
De esta forma limitamos el n´umero de procesos por usuario a 60 (un n´umero aceptable en la may- or´ıa de sistemas7), consiguiendo as´ı que un error en un programa no sea capaz de detener la m´aquina.
158 CAP´ITULO 9. SOLARIS Un par´ametro del sistema operativo especialmente importante, y que quiz´as nos interese modi- ficar (sobre todo en m´aquinas con pocos recursos) es maxusers. Al contrario de lo que mucha gente cree, maxusers no hace referencia al n´umero m´aximo de usuarios que pueden conectar si- mult´aneamente al sistema, sino que es un valor que escala a otros par´ametros del n´ucleo (como
max nproc, n´umero m´aximo de procesos en la tabla) omaxuprc. Para modificarlo, podemos incluir en/etc/systemuna l´ınea con el valor deseado, generalmente el tama˜no en MB de la memoria f´ısica de nuestra m´aquina ([Dik99]):
set maxusers=128
Tambi´en puede ser conveniente limitar par´ametros del sistema operativo relativos al sistema de ficheros, ya que tambi´en se pueden producir negaciones de servicio relacionadas con ellos. Por ejem- plo, es interesante poder limitar el n´umero m´aximo de ficheros abiertos mediante los par´ametros
rlim fd max (l´ımite hard) y rlim fd cur (l´ımite soft) o evitar que los usuarios puedan utilizar
chown() en sus ficheros, especificando un valor 1 para la variable rstchown (este es el compor- tamiento por defecto; si no lo seguimos, aparte de comprometer la seguridad los usuarios sin privi- legios podr´ıan ignorar el sistema dequotas).
Dejando ya de lado los l´ımites que se pueden imponer a los recursos consumidos por los usuar- ios del sistema, existe otra serie de par´ametros del n´ucleo interesantes para aumentar la seguridad de un sistema Solaris. Por ejemplo, en algunas arquitecturas SPARC (concretamente en sun4u,
sun4d y sun4m) es posible, desde Solaris 2.6, establecer una protecci´on hardware para prevenir ataques debuffer overflow. Esta protecci´on consiste en impedir que los programas puedan ejecutar c´odigo en su pila, recibiendo la se˜nalsigsegvsi tratan de hacerlo: para ello, en/etc/systemhemos de incluir una l´ınea como
set noexec_user_stack=1
Y si adem´as queremos monitorizar los intentos de ataque de este tipo (como mensajes del n´ucleo de Solaris, con priority ‘kern’ y nivel ‘notice’, por defecto en /var/adm/messages), podemos incluir en el archivo la l´ınea
set noexec_user_stack_log=1
Si administramos un servidornfsy deseamos que ignore las peticiones de clientes que no provengan de puertos privilegiados (es decir, que no hayan sido solicitadas por un usuario privilegiado de la m´aquina cliente) podemos definir la variable nfs portmon en/etc/system; si usamos versiones de Solaris anteriores a la 2.5, debemos incluir una l´ınea como
set nfs:nfs_portmon = 1
mientras que en Solaris 2.5 y posteriores utilizaremos
set nfssrv:nfs_portmon = 1
Por ´ultimo, como ya comentamos en el punto dedicado a la seguridadeeprom, podemos deshabilitar
el acceso que se consigue a la misma al pulsar la combinaci´on de teclas‘Stop–A’en un teclado Sun; para ello es necesario a˜nadir en el fichero/etc/systemuna entrada como
set abort_enable=0
Antes de finalizar este punto, es necesario tener en cuenta que los cambios que se realicen en
/etc/system no tendr´an efecto hasta que la m´aquina se reinicie, y que un peque˜no error en los contenidos de este archivo puede provocar que un sistema no arranque, por lo que es siempre recomendable guardar una copia antes de realizar cualquier modificaci´on del fichero.
Cap´ıtulo 10
Linux
10.1
Introducci´on
A mediados de 1991 un estudiante finland´es llamado Linus Torvalds trabajaba en el dise˜no de un sistema operativo similar a Minix, que pudiera ejecutarse sobre plataformas Intel y compatibles, y sobre todo que fuera peque˜no y barato; a ra´ız de un mensaje de este estudiante encomp.os.minix, algunas personas comenzaron a interesarse por el proyecto, y finalmente el 5 de octubre de ese a˜no Linus Torvals hizo p´ublica la versi´on 0.02 – la primera funcional – de lo que ya se denominaba Linux (Linus´ Unix). En esa versi´on, que aproximadamente utilizaron un centenar de usuarios, apenas se ofrec´ıa soporte ahardware(excepto el que Linus ten´ıa en su ordenador), no dispon´ıa de subsistema de red ni de sistema de ficheros propio, y las utilidades de espacio de usuario se pod´ıan contar con los dedos de las manos (unshell, un compilador, y poco m´as). Sin embargo, y a pesar de las duras cr´ıticas de pesos pesados en el mundo de los sistemas operativos como Andrew Tanenbaum, el proyecto era muy interesante, y poco a poco programadores de todo el mundo fueron aportando mejoras a este nuevo sistema.
A principios de 1994 apareci´o Linux 1.0, considerada la primera versi´on del operativo utilizable no s´olo porhackersy programadores, sino por usuarios ‘normales’; de las aproximadamente 10000 l´ıneas de la versi´on inicial se hab´ıa pasado a unas 170000, y el centenar de usuarios se hab´ıa mul- tiplicado por mil. Linux 1.0 incorporaba subsistema de red (sin duda uno de los cambios que m´as ha contribuido a la expansi´on del operativo), entorno gr´afico (arrastrado de versiones anteriores) y soporte a una gama de hardware relativamente amplia. La popularidad del operativo crec´ıa mes a mes – especialmente en entornos universitarios y de investigaci´on – gracias sobre todo a su filosof´ıa: cualquiera pod´ıa (y puede) modificar una parte del n´ucleo, adaptarla, mejorarla, o incorpo- rar nuevas l´ıneas, con la ´unica obligaci´on de compartir el nuevo c´odigo fuente con el resto del mundo. Sin embargo, no fu´e hasta 1996, con la aparici´on de Linux 2.0 (que incorporaba casi medio mill´on de l´ıneas de c´odigo), cuando se produjo el gran boom de Linux que perdura hasta la actualidad. Esta nueva versi´on convert´ıa a Linux en un sistema libre que, en algunos aspectos, no ten´ıa nada que envidiar a entornos Unix comerciales; m´as de un mill´on de usuarios contribu´ıan sin descanso a mejorar el sistema, y quiz´as por primera vez la arquitectura PC no era un mercado reservado casi en exclusiva a Microsoft. Muchas personas vieron que Linux pod´ıa llegar a ser rentable (a pesar de su filosof´ıa free), y se comenz´o a trabajar mucho en la facilidad de instalaci´on y manejo para usuarios sin elevados conocimientos de inform´atica; incluso llegaba a desbancar en muchas ocasiones al inamovible Minix a la hora de estudiar dise˜no de sistemas operativos en las universidades (algo poco comprensible, por otra parte, ya que cualquiera que le haya pegado un vistazo al c´odigo del
kernel de Linux podr´a comprobar que a diferencia de Minix no est´a dise˜nado para ser legible y did´actico, sino para ser r´apido).
En la actualidad Linux cuenta con varios millones de usuarios, y se ha convertido en el Unix m´as
user–friendlyde todos los existentes, ya que no hacen falta conocimientos avanzados para instalarlo y manejarlo m´ınimamente; reconoce multitud de hardware(algo que siempre ayuda en el mercado de los ordenadores de sobremesa), y se puede utilizar para funciones tan diversas como servidores
160 CAP´ITULO 10. LINUX
web, de bases de datos, de correo electr´onico, o como una sencillaworkstation. En muchas empresas medianas y peque˜nas ha desplazado por completo a los sistemas Unix comerciales (caros y que gen- eralmente corren sobrehardwareque tampoco es barato), e incluso en grandes servidores se utiliza Linux como sistema operativo; aunque – y esto es una cr´ıtica, por si no queda claro – en algunas ocasiones se echan de menos mecanismos de seguridad que s´ı est´an disponibles en otros Unices, podemos decir que Linux proporciona un nivel de seguridad, fiabilidad y estabilidad adecuado a la mayor parte de aplicaciones gen´ericas que nos podamos imaginar (es decir, no es un operativo apto para controlar una central nuclear, pero s´ı para cualquier aplicaci´on de criticidad baja o media que podamos utilizar d´ıa a d´ıa).
Al igual que hemos hecho en el cap´ıtulo anterior con Solaris, vamos a hablar en este de aspec- tos de seguridad espec´ıficos de Linux, aunque como siempre lo que hemos comentado para Unix en general es casi siempre aplicable a este clon. Sobre temas propios de Linux podemos obtener infor- maci´on adicional y gratuita a trav´es de Internet, en cualquier documento del proyecto LDP (Linux Documentation Project); tambi´en existen numerosos libros sobre aspectos espec´ıficos de este opera- tivo, desde la implementaci´on de su n´ucleo ([BBD+96], [CDM97]. . . ) hasta su seguridad ([Tox00],
[Ano01]. . . ), pasando por supuesto por temas de administraci´on gen´erica ([HN+99], [BPB00]. . . ).