Solaris

INTRODUCCIN A LA SEGURIDAD A BAJO NIVEL SOLARIS PARA SERVIDORES y ESTACIONES SPARC

INTRODUCCIN A LA SEGURIDAD A BAJO NIVEL SOLARIS PARA SERVIDORES y ESTACIONES SPARCVersin 1.0 Junio 2002Este documento posee un Copyright perteneciente a [email protected] y slo debe ser distribuido siempre de acuerdo a las especificaciones de la licencia OPL (Open Publication License) Draft v1.0, del 8 Junio de 1999 o posteriores. La distribucin de cualquier modificacin sustancial del documento queda terminantemente prohibida sin autorizacin expresa del titular del copyright. Consulte las condiciones de la ultima revisin de la licencia OPL en http://www.opencontent.org/openpub/. Las marcas citadas tienen unos derechos de propiedad que corresponden a sus legtimos autores y que deben ser totalmente respetados.

Documentos operativos de #solaris , /server irc.redhispana.org:6667 Pgina 1


1. INTRODUCCIN El presente documento es simplemente una gua introductoria. Frecuentemente encontramos en sitios web o en la literatura de la administracin de sistemas trminos como Solaris, SPARC, seguridad a bajo nivel, servidores y estaciones de trabajo, as como otros muchos, que suscitan nuestra curiosidad. Es igual de frecuente pensar que la seguridad de los sistemas pasa exclusivamente por proteger el software sobre el cual corren nuestras aplicaciones, instalar cortafuegos y aplicar medidas de seguridad IP pero esto slo es una parte del concepto de seguridad y es a todas luces insuficiente para poder definir un sistema seguro. Muchas veces se precisan medidas de seguridad al ms bajo nivel, sobre todo en sistemas donde la actividad de los mismos es crtica y no tolera el fallo ni la posible intrusin en los mismos en ninguna de sus circunstancias. Pensemos en un sistema telemtico aeroespacial y la seguridad que requiere, o pensemos en el colapso en un sistema financiero burstil a causa de una intrusin o fallo en seguridad. No es admisible. Este documento pretende arrojar la visin de la seguridad desde el citado bajo nivel, una visin de la seguridad que escapa frecuentemente a la visin del usuario domstico por motivos obvios, pero que existe y debe ser conocida por todos los administradores de sistemas. Para ello dado lo extenso del campo que tratamos en la seguridad a bajo nivel, nos vamos a centrar en supuestos muy determinados para ilustrarlo, concretamente en procesos SPARC en entornos Solaris. 1.1 Qu es Solaris? Solaris es el entorno de trabajo Unix desarrollado por la empresa Sun Microsystems. Es un entorno muy extendido y con ndices de fiabilidad muy por encima de la mayora de entornos Unix existentes y permite, dado que trabaja sobre arquitecturas x86 desde la aparicin de la primera versin en 1990 para esta arquitectura, la instalacin en ordenadores domsticos y a nivel de usuario, pero su gran rendimiento y el actual empleo se enfocan ms al empleo de Solaris en estaciones o servidores tipo SPARC con un carcter marcadamente profesional, sobre todo en el tema de seguridad bajo Firewall-1 Solaris tiene como retos el trabajo a gran escala multiproceso en 64bit, ofreciendo al usuario grandes ndices de seguridad, compatibilidad, escalabilidad, manejabilidad y todo integrado en una magnfica plataforma de servicios que convierten a Solaris en el entorno Unix posiblemente con mejor calidad global del mercado. Podemos hacernos con Solaris OS en el site de Sun Microsystems http://wwws.sun.com/software/solaris/get.htmlDocumentos operativos de #solaris , /server irc.redhispana.org:6667 Pgina 2


1.1 Qu es SPARC? Tal y como hemos comentado, Solaris tiene un enfoque claro para el proceso en SPARC, siglas correspondientes a Scalable Processor ARChitecture, es decir, arquitectura de procesadores escalables. SPARC es una arquitectura tipo RISC (Reduced Instruction Set Computer) abierta, caracterizada por la inclusin directa en el hardware de las instrucciones mquina, en vez del frecuente uso de microprogramas, y sus empleos son muy demandados en procesos crticos, automatizacin industrial, finanzas, y por supuesto, Internet, y cualquier aplicacin donde la seguridad y la fiabilidad primen. Los procesadores SPARC antiguos funcionan en 32 bit, mientras que la denominacin de los procesadores a 64 bit modernos es frecuente encontrarla en la literatura como UltraSPARC, siendo la gama de estos procesadores bastante amplia. La evolucin de los procesadores SPARC se remonta a unos comienzos poco claros all por 1984, de la mano de Bill Joy y Dave Patterson, que empezaron a investigar el uso de RISC en un mundo dominado por las arquitecturas tradicionales. En 1986 se public la arquitectura versin 7 de SPARC y en 1987, aparece el primer procesador SPARC a la vez que Sun Microsystems lanzaba su Sun-4, y poco despus, en 1990, se publica la versin 8 de la arquitectura SPARC, que no sera sustituida hasta 1994, fecha de publicacin de la versin 9. Durante este tiempo, se han unido al proyecto SPARC empresas como Sun, Texas Instruments, ICL, Toshiba y han hecho que el xito alcanzado por la arquitectura abierta haya alcanzado cotas inimaginables. En el enlace http://www.sparc.org podemos documentarnos ampliamente sobre la tecnologa descrita 2. FUNDAMENTOS DE SEGURIDAD MULTIPROCESO SPARC EN ENTORNOS SOLARIS EN

Los mecanismos a ms bajo nivel que se permiten en Solaris bajo proceso SPARC es el uso de la eeprom del procesador. Esta memoria es de carcter no voltil y recibe el nombre de NVRAM (Non Volatile RAM) Es frecuente encontrar a esta memoria en la literatura de arquitectura de sistemas como OBP, siglas que corresponden a Open Boot Prom. La manera de acceder a esta memoria no voltil es generalmente la pulsacin de las teclas stop-a si disponemos de un teclado Sun o bien combinando las teclas ctrl y break, caso de que dispongamos de un teclado serie.



Ya sea en el teclado Sun o en un teclado serie, una vez ejecutada la secuencia accederemos a la lnea de comandos OBP. Las variables recogidas en esta memoria no voltil pueden ser consultadas y modificadas a gusto del administrador del sistema consultado /usr/sbin/eeprom. De igual manera podemos especificar una variable en esta eeprom mediante la sintaxis /usr/sbin/eeprom nombre_variable=valor El firmware Openboot permite una modalidad restringida llamada Restricted Monitor, un monitor de carcter restringido que se sealiza mediante el prompt de sistema > que permite la ejecucin del arranque (b, boot) continuar (c, continue) o bien hacer uso del modo de comandos nuevos (n, new command mode) Este modo restringido del que hablamos es el que se utiliza para implementar seguridad PROM a travs de lo que se conoce como securitymode. Las variables en PROM pueden ser establecidas mediante setenv nombre_variable valor La gestin de estas variables de seguridad slo se pueden hacer desde la cuenta root del sistema o bien desde el segundo prompt, ok> el cual comentamos a continuacin El monitor PROM, conocido en la literatura como el cuarto monitor, es un interfaz que permite control adicional mediante un intrprete de comandos que se sealiza mediante el prompt ok> que hemos citado. Dentro de este prompt de PROM es posible hacer multitud de operaciones, como por ejemplo listar los dispositivos reconocidos por el sistema, y otro tipo de controles bsicos que son ls que lista los contenidos del nodo actual cd que se emplea para cambiar la localizacin en el rbol de dispositivos pwd que permite obtener la localizacin actual dentro del rbol de dispositivos .properties que muestra las propiedades para un nodo determinado device-end que deselecciona un nodo dev ruta_del_dispositivo que permite examinar dispositivos del rbol seleccionndolos

Los nombres de los dispositivos en aras de la seguridad se encuentran encriptados pero guardan un parecido siempre con el listado del directorio /devices del sistema. Cuando la identificacin no es posible a simple ojo, podemos recurrir al alias /etc/driver_aliases como gua. Es frecuente el uso de los comandos siguientes para la localizacin de dispositivos ok>probe-scsi-all ok>probe-sbus ok>show-sbus ok>show-disks ok>show-tapesDocumentos operativos de #solaris , /server irc.redhispana.org:6667 Pgina 4


ok>show-nets ok> show-devs Los comandos probe son de sondeo y los show, para mostrar o listar Un nombre de nodo de una ruta completa de dispositivos siempre tiene esta sintaxis nombre@direccion:argumentos Por ejemplo, el boot disk de sun4m quedara representado para el slice 0 /sbus@1,f8000000/esp@0,40000/sd@3,0:a Llegados a este punto la duda que puede surgir es obvia. Si podemos acceder a esta memoria no voltil NVRAM de la manera tan sencilla pulsando la combinacin de teclas a la que nos hemos referido con anterioridad, qu mecanismos nos pueden ayudar para impedir la adulteracin del funcionamiento del entorno? El problema de la seguridad fundamental que es el ataque remoto lo hemos solventado por completo, dado que se requiere presencia en consola, con lo cual la idea de seguridad a bajo nivel expuesta ya de por s barre a la seguridad convencional en muchas aplicaciones por completo, pero, qu sucede si el atacante dispone de acceso al terminal? La posibilidad de que un usuario pueda interactuar con la EEPROM implica que cualquiera puede interrumpir y rearrancar el sistema operativo con la consiguiente toma de control. Para ello la solucin elemental es la eliminacin de la posibilidad de pulsado de teclas para acceder a la NVRAM empleando la directiva del kernel abort_enable que podemos localizar en /etc/system mediante la cual la pulsacin o bien una medida ms ingenieril y menos forzada que es proteger el acceso a la memoria desde la misma memoria. Para ello SPARC ofrece 3 niveles de seguridad que son los siguientes none-secure que como su propio nombre indica, no aporta seguridad alguna al respecto command-secure que permite habilitar una clave para poder reiniciar el sistema full-secure que es el modo de seguridad total, se obliga el uso de la clave para cualquier dispositivo, cosa que no ocurra en el caso anterior, que no la requiere si el dispositivo es el dispositivo por defecto, generalmente el disco.

La nica manera de poder modificar claves en la EEPROM es mediante el comando eeprom y se requiere calidad de root para ejecutarlo. En el modo fullsecure, los reinicios programados del sistema son imposibles, debe existir un operador del sistema que introduzca la clave en consola.



El modo de seguridad que empleemos depender de nuestros requerimientos. Unas veces el modo full es imposible de aplicar puesto que necesitamos reinicios programados y no hay posibilidad de que un operario est fsicamente presente en consola para la introduccin de la clave. Imaginemos un sistema SPARC bajo Solaris en una estacin espacial por ejemplo. Algunas veces el modo command puede ser el adecuado, ya que quizs no nos importe en exceso el que el dispositivo por defecto no precise claves y otras veces, la inaccesibilidad fsica a los terminales hacen del modo none el apropiado. El proceso de cambio es el mostrado en el que pasamos de un modo command a un modo full en una mquina Lo primero es consultar el estado actual del modo de seguridad redhispana:/# eeprom security-mode security-mode=command redhispana:/# A continuacin, requerimos a la eeprom el cambio de modo redhispana:/# eeprom security-mode=full Changing PROM password: New password: Retype new password: redhispana:/# eeprom security-mode security-mode=full redhispana:/# Otro aspecto interesante es que la clave de la NVRAM jams se muestra en pantalla redhispana:/# eeprom security-password security-password= data not available Por ultimo comentar que el comando security-#badlogins permite contar el nmero de accesos incorrectos al sistema como medida precautoria e informativa redhispana:/# eeprom security-#badlogins security-#badlogins=2 En este caso hemos contado 2 accesos incorrectos. Por ltimo comentar que las arquitecturas Intel permiten simular el comando eeprom mediante el fichero bootenv.inc, ya que al no poseer eeprom, slo podemos simular su efecto. La seguridad en este caso como en cualquier mquina Intel es el control de arranque mediante la contrasea en BIOS



3. OTROS ASPECTOS Y RECOMENDACIONES DE SEGURIDAD SISTEMAS SOLARIS

EN

Por ltimo vamos a citar puntualmente algunas recomendaciones para que la seguridad del sistema Solaris que administramos sea plena y eficiente. No es objeto de este documento su desarrollo por su carcter introductorio, luego nos limitaremos a citarlos sucintamente 3.1 Usuarios y acceso al sistema a travs de cuentas y otros daemons Es recomendable el bloqueo del acceso a la mquina de los usuarios generados en la instalacin de Solaris que se consideran parte del sistema, como por ejemplo adm o bin que realmente no tienen por qu tener acceso a la mquina. Los usuarios que se denoten por LK (locked) estarn con cuenta bloqueada en el sistema. Podemos listarlos mediante redhispana:/# passwd s a|grep LK listen LK noaccess LK . redhispana:/# Es posible asignar a los usuarios cuentas shells ficticias que no permiten la ejecucin de ordenes, como es el caso de /bin/false La principal recomendacin siempre ser evitar que no haya usuarios en el sistema sin password para lo cual redhispana:/# passwd s a y controlar los registros que se muestren carentes de clave, NP No Password Es recomendable impedir el acceso telnet a la mquina puesto que el trfico que realiza es en texto claro, luego es buena recomendacin la implantacin y la obligatoriedad de SSH Otros daemons remotos como FTP debe ser igualmente verificados como medida recomendable, pese a que uno de los puntos fuertes es que slo se puede hacer login en la mquina como root en consola y jams de un modo remoto, lo que hace que se imposibiliten gran parte de los ataques potenciales a la mquina. Para acceder como sper usuario es preciso entrar en la mquina como usuario normal y luego ejecutar la orden sper user su, lo que supone un interesante filtrado previo



3.2 Servicios de Red Respecto a los servicios de red, y de esto podramos redactar otro documento extenso, comentar que el administrador debe tener en cuenta que algunos servicios de red son potencialmente peligrosos por su interaccin con el usuario que podra en ciertas circunstancias beneficiarse de la mala configuracin o de un error puntual en los mismos. La instalacin clsica de Solaris deja por defecto numerosos servicios abiertos. Muchos son servicios clsicos que se mantienen por su uso puntual pero que se recomienda cerrar, es el caso de la conectividad va Telnet. Esto es una dificultad en Solaris puesto que a diferencia de los sistemas Unix tradicionales, existen servicios de red basados en RPC (Remote Procedure Call) muchos de los cuales estn hoy por hoy en vas de investigacin y su desarrollo dada la complejidad y el relativo poco uso que se hace de este sistema, puesto que es un sistema Unix avanzado no destinado en principio al usuario de a pie, los hacen poco propicios para su manejo y por tanto de no es fcil por cerrar servicios que muchas veces son desconocidos y que podran afectar a otros servicios del sistema. Un servicio de los comentados es el demonio CACHEFS (Cache File System) un servicio de cache que contena un importante fallo de seguridad que se comenta en http://www.cert.org/advisories/CA-2002-11.html y que pese a ser un servicio no esencial, comprometa la seguridad del sistema. Otros servicios como cmsd o sprayd deben ser analizados. El consejo para el administrador Solaris es la revisin exhaustiva de /etc/inetd.conf y que se cierren los servicios de red que no sean esenciales como medida precautoria. Podemos usar para ello grep, mediante la sintaxis redhispana:/# grep v ^\# /etc/inetd.conf Pese a todo reproducimos ahora un sample o muestra de la configuracin estndar de inetd para que podamos ver el grado de complejidad del que hablamos#ident "@(#)inetd.conf 1.27 96/09/24 SMI" /* SVr4.0 1.5 # # # # 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. # # Syntax for socket-based Internet services: # # # Syntax for TLI-based Internet services: # # tli */


INTRODUCCIN A LA SEGURIDAD A BAJO NIVEL SOLARIS PARA SERVIDORES y ESTACIONES SPARC # # Ftp and telnet are standard Internet services. # ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd # # Tnamed serves the obsolete IEN-116 name server protocol. # #name dgram udp wait root /usr/sbin/in.tnamed in.tnamed # # Shell, login, exec, comsat and talk are BSD protocols. # #shell stream tcp nowait root /usr/sbin/tcpd in.rshd #login stream tcp nowait root /usr/sbin/tcpd in.rlogind #exec stream tcp nowait root /usr/sbin/tcpd in.rexecd comsat dgram udp wait root /usr/sbin/in.comsat in.comsat #talk dgram udp wait root /usr/sbin/in.talkd in.talkd # # Must run as root (to read /etc/shadow); "-n" turns off logging in utmp/wtmp. # #uucp stream tcp nowait root /usr/sbin/in.uucpd in.uucpd # # Tftp service is provided primarily for booting. Most sites run this # only on machines acting as "boot servers." # #tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot # # Finger, systat and netstat give out user information which may be # valuable to potential "system crackers." Many sites choose to disable # some or all of these services to improve security. # #finger stream tcp nowait nobody /usr/sbin/tcpd in.fingerd #systat stream tcp nowait root /usr/bin/ps ps -ef #netstat stream tcp nowait root /usr/bin/netstat netstat -f inet # # Time service is used for clock synchronization. # time stream tcp nowait root internal time dgram udp wait root internal # # Echo, discard, daytime, and chargen are used primarily for testing. # echo stream tcp nowait root internal echo dgram udp wait root internal discard stream tcp nowait root internal discard dgram udp wait root internal daytime stream tcp nowait root internal daytime dgram udp wait root internal chargen stream tcp nowait root internal chargen dgram udp wait root internal # # # RPC services syntax: # / rpc/ \ # # # can be either "tli" or "stream" or "dgram". # For "stream" and "dgram" assume that the endpoint is a socket descriptor. # can be either a nettype or a netid or a "*". The value is # first treated as a nettype. If it is not a valid nettype then it is # treated as a netid. The "*" is a short-hand way of saying all the # transports supported by this system, ie. it equates to the "visible" # nettype. The syntax for is: # *||{[,]} # For example: # dummy/1 tli rpc/circuit_v,udp wait root /tmp/test_svc test_svc # # Solstice system and network administration class agent server 100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind #

# Rquotad supports UFS disk quotas for NFS clients


INTRODUCCIN A LA SEGURIDAD A BAJO NIVEL SOLARIS PARA SERVIDORES y ESTACIONES SPARC # #rquotad/1 tli rpc/datagram_v wait root /usr/lib/nfs/rquotad rquotad # # The rusers service gives out user information. Sites concerned # with security may choose to disable it. # #rusersd/2-3 tli rpc/datagram_v,circuit_v wait root /usr/lib/netsvc/rusers/rpc.rusersd rpc.rusersd # # The spray server is used primarily for testing. # #sprayd/1 tli rpc/datagram_v wait root /usr/lib/netsvc/spray/rpc.sprayd rpc.sprayd # # The rwall server allows others to post messages to users on this machine. # walld/1 tli rpc/datagram_v wait root /usr/lib/netsvc/rwall/rpc.rwalld rpc.rwalld # # Rstatd is used by programs such as perfmeter. # rstatd/2-4 tli rpc/datagram_v wait root /usr/lib/netsvc/rstat/rpc.rstatd rpc.rstatd # # The rexd server provides only minimal authentication and is often not run # #rexd/1 tli rpc/tcp wait root /usr/sbin/rpc.rexd rpc.rexd # # rpc.cmsd is a data base daemon which manages calendar data backed # by files in /var/spool/calendar # # # Sun ToolTalk Database Server # # # UFS-aware service daemon # #ufsd/1 tli rpc/* wait root /usr/lib/fs/ufs/ufsd ufsd -p # # Sun KCMS Profile Server # 100221/1 tli rpc/tcp wait root /usr/openwin/bin/kcms_server kcms_server # # Sun Font Server # fs stream tcp wait nobody /usr/openwin/lib/fs.auto fs 536870916/1 dgram rpc/udp wait root /opt/SUNWvts/bin/vtsk /opt/SUNWvts/bin/vtsk bootps dgram udp wait root /usr/sbin/bootpd bootpd # # POP Mailer # pop3 stream tcp nowait root /usr/local/etc/popper popper -s # # Print Protocol Adaptor - BSD listener # printer stream tcp nowait root /usr/lib/print/in.lpd in.lpd # # CacheFS Daemon # 100235/1 tli rpc/tcp wait root /usr/lib/fs/cachefs/cachefsd cachefsd # # Kerbd Daemon # #kerbd/4 tli rpc/ticlts wait root /usr/sbin/kerbd kerbd dtspc stream tcp nowait root /usr/dt/bin/dtspcd /usr/dt/bin/dtspcd #xaudio stream tcp wait root /usr/openwin/bin/Xaserver Xaserver -noauth -inetd #100068/2-5 dgram rpc/udp wait root /usr/dt/bin/rpc.cmsd rpc.cmsd #100083/1 tli rpc/tcp wait root /usr/dt/bin/rpc.ttdbserverd /usr/dt/bin/rpc.ttdbserverd



4. ENLACES BSICOS Y BIBLIOGRAFA RECOMENDADA Los enlaces bsicos a Solaris y SPARC son Solaris Operating Environment http://wwws.sun.com/software/solaris/ SPARC International Inc. http://www.sparc.com/

Y esta bibliografa es lo suficientemente amplia como para poder avanzar en este entorno y sus aplicaciones Solaris 2.X for Managers and Administrators de Curt Freeland SolarisTM Solutions for System Administrators: Time-Saving Tips, Techniques, and Workarounds de Sandra Henry-Stocker, Evan R. Marks Configuration and Capacity Planning for Solaris Servers de Brian L. Wong Sparc Architecture Assembly Language 2ND Edition by Richard P Paul SSH, The Secure Shell: The Definitive Guide de Daniel J. Barrett, Richard Silverman


Documents

Solaris