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
INTRODUCCIN A LA SEGURIDAD A BAJO NIVEL SOLARIS PARA SERVIDORES
y ESTACIONES SPARC
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
INTRODUCCIN A LA SEGURIDAD A BAJO NIVEL SOLARIS PARA SERVIDORES
y ESTACIONES SPARC
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.
Documentos operativos de #solaris , /server
irc.redhispana.org:6667 Pgina 3
INTRODUCCIN A LA SEGURIDAD A BAJO NIVEL SOLARIS PARA SERVIDORES
y ESTACIONES SPARC
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
INTRODUCCIN A LA SEGURIDAD A BAJO NIVEL SOLARIS PARA SERVIDORES
y ESTACIONES SPARC
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.
Documentos operativos de #solaris , /server
irc.redhispana.org:6667 Pgina 5
INTRODUCCIN A LA SEGURIDAD A BAJO NIVEL SOLARIS PARA SERVIDORES
y ESTACIONES SPARC
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
Documentos operativos de #solaris , /server
irc.redhispana.org:6667 Pgina 6
INTRODUCCIN A LA SEGURIDAD A BAJO NIVEL SOLARIS PARA SERVIDORES
y ESTACIONES SPARC
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
Documentos operativos de #solaris , /server
irc.redhispana.org:6667 Pgina 7
INTRODUCCIN A LA SEGURIDAD A BAJO NIVEL SOLARIS PARA SERVIDORES
y ESTACIONES SPARC
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
*/
Documentos operativos de #solaris , /server
irc.redhispana.org:6667 Pgina 8
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
Documentos operativos de #solaris , /server
irc.redhispana.org:6667 Pgina 9
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
Documentos operativos de #solaris , /server
irc.redhispana.org:6667 Pgina 10
INTRODUCCIN A LA SEGURIDAD A BAJO NIVEL SOLARIS PARA SERVIDORES
y ESTACIONES SPARC
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
Documentos operativos de #solaris , /server
irc.redhispana.org:6667 Pgina 11
