Los contenidos pueden estar desactualizados con respecto al original
HP-UX
Siguiente: Seguridad de la subred Subir: Algunos sistemas Unix Anterior: AIX Índice General
Subsecciones
- Introducción
- Seguridad física en PA-RISC
- Usuarios y accesos al sistema
- El sistema de parcheado
- Extensiones de la seguridad
- El subsistema de red
- El núcleo de HP-UX
HP-UX
Introducción
HP-UX es la versión de Unix desarrollada y mantenida por Hewlett-Packard desde 1983, ejecutable típicamente sobre procesadores HP PA RISC y en sus última versiones sobre Intel Itanium (arquitectura Intel de 64 bits); a pesar de estar basada ampliamente en System V incorpora importantes características BSD. En la actualidad la última versión del operativo es la 11.11, aunque existen numerosas instalaciones de sistemas más antiguos, especialmente HP-UX 10.x o incluso 9.x.HP-UX es, como la mayor parte de Unices comerciales, un entorno de trabajo flexible, potente y estable, que soporta un abanico de aplicaciones que van desde simples editores de texto a complicados programas de diseño gráfico o cálculo científico, pasando por sistemas de control industrial que incluyen planificaciones de tiempo real.
Durante los últimos años Hewlett-Packard, como muchos otros fabricantes, parece haberse interesado bastante por la seguridad en general, y en concreto por los sistemas de protección para sus sistemas; prueba de ello es la gama de productos relacionados con este campo desarrollados para HP-UX, como el sistema de detección de intrusos IDS/9000 para HP-UX 11.x corriendo sobre máquinas HP-9000 o la utilidad Security Patch Check, similar al PatchDiag de Sun Microsystems. También es importante destacar las grandes mejoras en cuanto a seguridad del sistema se refiere entre HP-UX 9.x, HP-UX 10.x y muy especialmente HP-UX 11.x.
En este capítulo, como hemos hecho antes con Solaris, Linux y AIX, hablaremos de aspectos de la seguridad particulares de HP-UX, teniendo siempre presente que el resto de capítulos del documento también son aplicables a este operativo. Para conocer más HP-UX podemos consultar [Reh00] o [PP01], y si nos interesa especialmente su seguridad una obra obligatoria es [Won01]. Aparte de documentación impresa, a través de Internet podemos acceder a numerosa documentación técnica de HP-UX, en la URL http://docs.hp.com/; por supuesto, también son básicas para una correcta administración las páginas de manual que se instalan con el producto.
Seguridad física en PA-RISC
Los sistemas de las series HP9000 incluyen un firmware muy similar a la OpenBoot PROM de las estaciones y servidores SPARC que se denomina PDC (Processor Dependent Code) y que implementa las funcionalidades dependientes del procesador; su función básica es, en el arranque de la máquina, inicializar el procesador y comprobar que su estado es correcto mediante unas pruebas llamadas POST (Power On Self Test). Si todo es satisfactorio el PDC carga el ISL (Initial System Loader) o IPL (Initial Program Loader) y le transfiere el control para que este pueda arrancar el sistema operativo.Como en cualquier dispositivo hardware existen formas de interrumpir el proceso de arranque habitual para modificar su comportamiento; en concreto, en la familia HP9000 suele existir un intervalo de 10 segundos antes de cargar el ISL en el que sin más que pulsar la tecla ESC13.1 se puede acceder al menú de arranque del equipo y, desde este, definir dispositivos de arranque alternativos o interactuar con el ISL, por ejemplo para pasar un parámetro al kernel de HP-UX antes de cargarlo; decimos `suele existir' porque el intervalo durante el cual se puede interrumpir el autoarranque se respeta sólo si las variables autoboot y autosearch del ISL están activadas, ya que en caso contrario el sistema automáticamente accede al menú de arranque y no se inicia hasta que un operador no interactua con el mismo.
Si al interrumpir el proceso de arranque elegimos interactuar con el ISL llegamos a un prompt sencillo en el que podemos comenzar a introducir órdenes desde el cargador hpux, como `hpux -v', que muestra la versión del ISL o `hpux -iS', que inicia el operativo en modo monousuario:
Hard booted. ISL Revision A.00.09 March 27, 1990 ISL> hpux -v Secondary Loader 9000/700 Revision 1.1 @(#) Revision 1.1 Wed Dec 10 17:24:28 PST 1986 ISL>Antes de acceder a este prompt podemos activar o resetar una variable denominada secure, que indica el modo de arranque seguro del equipo; si está activada no se podrá interactuar con el arranque del sistema, lo cual implica una protección relativa: un atacante situado delante del equipo lo tendrá más difícil para arrancar el sistema desde un dispositivo que no sea el estándar, o para iniciarlo en modo monousuario. El hecho de que esta protección sea relativa es lógico: si no fuera reversible, nunca nadie más podría modificar la secuencia de arranque del equipo; si aunque el modo de arranque seguro esté activado queremos o necesitamos interrumpir el arranque, no tenemos más que desconectar todos los dispositivos arrancables del equipo (discos, red, unidad de CD-ROM...), de forma que el arranque falle y se acceda al menú para poder resetear la variable secure.
Usuarios y accesos al sistema
Como sucede en Linux, el acceso root remoto a una máquina HP-UX se puede y debe limitar desde el archivo /etc/securetty, donde se listan las terminales desde las que el superusuario del sistema puede acceder al mismo; si queremos que el root sólo pueda conectar desde la consola física de la máquina este archivo debe ser creado de la forma siguiente:marta:/# echo console > /etc/securetty marta:/# chown root:sys /etc/securetty marta:/# chmod 644 /etc/securetty marta:/#De nuevo, al igual que sucedía en Linux, esto no evita que se pueda ejecutar `su' desde cualquier sesión para conseguir privilegios de administrador, ni deshabilita el acceso remoto vía SSH o X Window. En el primer caso debemos vetar el acceso desde el archivo de configuración de sshd, mientras que en el segundo podemos hacerlo de la forma siguiente:
marta:/# cp -p /usr/dt/config/Xstartup /etc/dt/config/Xstartup
marta:/# print "[[ ${USER} = root ]] && exit 1" >>/etc/dt/config/Xstartup
marta:/#
Muchos de los parámetros que controlan el acceso de los usuarios a un sistema
HP-UX se definen en el archivo /etc/default/security, que ha de tener
permiso de escritura para root y de lectura para todos los usuarios; si
este fichero no existe, el administrador puede - y debe - crearlo. Esta
feature del operativo fue introducida de forma no documentada en HP-UX
11.0, y se incluye también en HP-UX 11i, ya documentada en la página de
manual de `security'. Un ejemplo de este archivo puede ser el siguiente:marta:/# cat /etc/default/security ABORT_LOGIN_ON_MISSING_HOMEDIR=1 MIN_PASSWORD_LENGTH=8 NOLOGIN=1 NUMBER_OF_LOGINS_ALLOWED=3 PASSWORD_HISTORY_DEPTH=2 SU_ROOT_GROUP=admins #SU_DEFAULT_PATH= marta:/#Seguramente los parámetros más importantes que podemos encontrar en este archivo son los referentes a las claves de usuario; tenemos en primer lugar MIN/SMALL>_PASSWORD/SMALL>_LENGTH, que como su nombre indica define la longitud mínima de las contraseñas en el sistema; mientras que en un HP-UX normal no afecta al root, en Trusted HP-UX sí que lo hace. Puede adoptar cualquier valor entre 6 (el mínimo por defecto) y 8 en los entornos normales, y entre 6 y 80 en Trusted HP-UX. El otro parámetro referente a las contraseñas es PASSWORD/SMALL>_HISTORY/SMALL>_DEPTH, que marca los passwords antiguos contra los que se compara uno nuevo: si su valor es N, cuando un usuario cambia su clave no podrá utilizar ninguna de sus N anteriores contraseñas. El valor de esta variable puede ser cualquier número entre 1 (valor por defecto) y 10, el valor máximo; si su valor es 2, evitamos que un usuario alterne constantemente dos contraseñas en el sistema.
Otro grupo de directivas es el formado por aquellas que afectan a la entrada de usuarios en el sistema; tenemos en primer lugar ABORT/SMALL>_LOGIN/SMALL>_ON/SMALL>_MISSING/SMALL>_HOMEDIR, que define cómo ha de comportarse el operativo cuando un usuario se autentica correctamente pero su directorio $HOME no existe. Si su valor es 0, el acceso se autorizará y el usuario entrará directamente al directorio `/'; si es 1, el login será rechazado a pesar de que la autenticación haya sido correcta.La segunda directiva de este grupo es NOLOGIN: si su valor es 1 y el fichero /etc/nologin existe, cuando un usuario diferente del root se autentique para entrar al sistema se le mostrará el contenido del archivo y se le cerrará la conexión (lo habitual en todos los Unices); por contra, si el valor de esta variable es 0, el archivo /etc/nologin simplemente será ignorado. Finalmente, la directiva NUMBER/SMALL>_OF/SMALL>_LOGINS/SMALL>_ALLOWED delimita el número máximo de conexiones simultáneas que los usuarios diferentes de `root' pueden poseer en el sistema; si su valor es 0, este número es ilimitado.
Vamos a ver por último un par de directivas que afectan a la ejecución de la orden `su' en el sistema. En primer lugar tenemos SU/SMALL>_ROOT/SMALL>_GROUP, que indica qué grupo de usuarios puede ejecutar la orden para convertirse - tecleando la contraseña, evidentemente - en administrador del sistema. Si este parámetro no está definido, cualquier usuario que conozca la clave puede convertirse en root, mientras que si lo está sólo los usuarios pertenecientes al grupo indicado pueden hacerlo.
Aparte del anterior parámetro, en HP-UX 11i se introdujo una nueva directiva en el fichero /etc/default/security; se trata de SU/SMALL>_DEFAULT/SMALL>_PATH, que marca el valor de la variable $PATH cuando alguien cambia su identificador de usuario mediante `su' sin la opción `-' (esto es, sin emular un login real).
Acabamos de ver que en el archivo /etc/default/security se pueden configurar diferentes aspectos relativos a las políticas de contraseñas a seguir en un sistema HP-UX; no obstante, algunos de los puntos más importantes de cualquier política están, como ocurre en Solaris, integrados dentro de la propia orden passwd: entre ellos algunos tan decisivos como la longitud mínima de una contraseña. Un esquema de este tipo resulta algo pobre actualmente, y como ya dijimos, cualquier Unix moderno debería incluir `de serie' la posibilidad de ofrecer una granularidad más adecuada en todo lo respectivo a las claves de los usuarios. Sea como sea, el esquema seguido en HP-UX es muy similar al de Solaris en cuanto a los requisitos mínimos para un password: al menos seis caracteres, dos de los cuales han de ser letras y uno numérico o especial, diferencias con la contraseña anterior en al menos tres caracteres - considerando equivalentes a mayúsculas y minúsculas para este propósito -, clave diferente del nombre de usuario y cualquier rotación del mismo, etc.
Ya para finalizar este punto, y relacionado también con la gestión de usuarios en HP-UX (aunque no explícitamente con el acceso de los mismos al sistema), es necesario hablar brevemente de los privilegios de grupo; este mecanismo, introducido en HP-UX 9.0, permite asignar a un grupo ciertos privilegios de administración, distribuyendo en cierta forma el `poder' del superusuario y rompiendo la aproximación al reparto de privilegios clásico de Unix (todo o nada). En la tabla 12.1 se muestran los privilegios de grupo soportados en HP-UX junto a la versión del operativo en la que fueron introducidos ([Spr01]).
Para asignar privilegios a un determinado grupo se utiliza la orden setprivgrp desde línea de comandos, y para que las modificaciones sean permanentes en el arranque de la máquina se lee el archivo /etc/privgroup (si existe) desde /etc/rc en HP-UX 9.x o de /etc/init.d/set_prvgrp en versiones superiores; en este fichero se indican (uno por línea) los privilegios a otorgar o eliminar a cada grupo:
marta:/# cat /etc/privgroup -n CHOWN admins CHOWN admins SETRUGID marta:/#En el anterior ejemplo se limita de forma global el permiso para ejecutar chown a todos los usuarios, y a continuación se habilita ese mismo permiso, junto a la capacidad para utilizar setuid() y setgid(), a los miembros del grupo admins. Al menos la primera entrada debería encontrarse siempre en HP-UX, ya que por defecto el operativo presenta un comportamiento de chown basado en System V, lo que permite que un usuario pueda cambiar la propiedad de sus archivos asignándolos al resto de usuarios - incluido el root -, lo que claramente puede llegar a suponer un problema de seguridad; es mucho más recomendable una aproximación basada en BSD, que limita la ejecución de chown al root.
Como en otros sistemas Unix, cuando en HP-UX un usuario quiere cambiar de grupo puede ejecutar la orden newgrp; sin embargo, se introduce una característica adicional: en el fichero /etc/logingroup, de formato similar a /etc/group (de hecho puede ser un enlace a este por cuestiones de simplicidad), se define la lista inicial de grupos a los que un usuario pertenece, es decir, aquellos sobre los cuales no tiene que ejecutar `newgrp' para convertirse en miembro de los mismos. Si este archivo no existe o está vacío, el usuario ha de ejecutar `newgrp' siempre que quiera acceder a un grupo secundario, y evidentemente conocer la clave de grupo (como en cualquier Unix, si no está definido un password para el grupo, ningún usuario puede pertenecer a él si no es como grupo primario); en cualquier caso, la relación de grupos secudarios para un usuario ha de definirse en /etc/logingroup, ya que si sólo lo está en /etc/group se ignorará y el usuario deberá ejecutar `newgrp' para acceder a los grupos secundarios no definidos.
La orden `groups' nos indicará a qué grupos pertenece de forma directa - sin tener que teclear ninguna contraseña - un cierto usuario, basándose para ello en la información almacenada en /etc/passwd, /etc/group y /etc/logingroup:
marta:/# groups root adm bin daemon lmadmin lp mail other root sys users marta:/#
El sistema de parcheado
En los sistemas HP-UX la gestión de software, tanto paquetes como parches, se puede llevar a cabo de una forma sencilla mediante la familia de comandos sw: swinstall, swlist, swremove...; a este sistema de gestión se le denomina SD-UX (Software Distributor HP-UX), y a pesar de estar basado en una tecnología distribuida cliente-servidor permite únicamente la gestión en la máquina local. Para obtener más información sobre el funcionamiento de SD-UX es recomendable consultar [HP96].Igual que sucedía en AIX, HP-UX posee una terminología propia para referirse a los diferentes objetos del Software Distributor. El objeto más pequeño manejado por SD-UX es el fileset, que no es más que un subconjunto de los diferentes ficheros que forman un producto, que a su vez es un conjunto de filesets estructurado de cierta forma, en el que se incluyen scripts de control para facilitar su manejo como un único objeto. HP-UX suele manejar sus parches a nivel de producto: un parche es un producto que puede estar formado por diferentes filesets, aunque lo más normal es que lo esté por uno solo; si no fuera así, y descargáramos un parche formado por varios filesets, es recomendable instalar todos como un único producto: aunque SD-UX permite el manejo de parches a nivel de filesets individuales, aplicar sólo algunos de ellos puede provocar que la vulnerabilidad que el parche ha de solucionar permanezca en el sistema ([HP00a].
El siguiente nivel de software es el bundle, un objeto manejado por SD-UX que agrupa diferentes productos y filesets relacionados entre sí, consiguiendo de esta forma una gestión de software más cómoda: por ejemplo, podemos utilizar bundles de parches para actualizar nuestro sistema, sin necesidad de descargar e instalar cada uno de esos parches de forma individual. Por último, en SD-UX se introduce el concepto de depot, un almacén de software en forma de directorio, cinta, CD-ROM o fichero único, que permite la instalación local o remota de sus contenidos: por ejemplo, el directorio /var/adm/sw/products/ puede ser considerado un depot, que a su vez contiene productos en forma de subdirectorios, que a su vez contienen filesets también en forma de subdirectorio, como veremos en el próximo ejemplo; mediante la orden swcopy podemos crear nuestros propios depots, que nos facilitarán la tarea de gestionar el software de diferentes sistemas.
Todo el software instalado en una máquina queda registrado en un catálogo denominado IPD (Installed Products Database), que se encuentra en el directorio /var/adm/sw/products/. Por ejemplo, para obtener un listado de los filesets instalados en la máquina relacionados con el producto accounting, junto a la versión de los mismos podemos utilizar la orden swlist o simplemente consultar la IPD con comandos como ls o cat (por supuesto, la primera forma es la recomendable):
marta:/# swlist -l fileset Accounting # Initializing... # Contacting target "marta"... # # Target: marta:/ # # Accounting B.10.20 Accounting Accounting.ACCOUNTNG B.10.20 Accounting.ACCT-ENG-A-MAN B.10.20 marta:/# cd /var/adm/sw/products/Accounting marta:/var/adm/sw/products/Accounting/# ls ACCOUNTNG ACCT-ENG-A-MAN pfiles marta:/var/adm/sw/products/Accounting/# grep ^revision ACC*/INDEX ACCOUNTNG/INDEX:revision B.10.20 ACCT-ENG-A-MAN/INDEX:revision B.10.20 marta:/var/adm/sw/products/Accounting/#Como hemos dicho, también mediante la orden swlist podemos obtener un listado de los parches aplicados a nuestro sistema HP-UX a nivel de aplicación; de nuevo, podríamos conseguir esta información accediendo directamente a /var/adm/sw/products/:
marta:/# swlist -l fileset -a patch_state |grep PH|grep -v ^\#|head -3 PHCO_10124.PHCO_10124 PHCO_10175.PHCO_10175 PHCO_10272.PHCO_10272 marta:/#Para obtener los parches aplicados al núcleo del sistema operativo podemos utilizar la orden `what' sobre el kernel de HP-UX:
marta:/# what /stand/vmunix|grep PH |head -2
PATCH_10.20: tty_pty.o 1.13.112.5 98/01/13 PHNE_13800
PATCH_10.20: mux2.o 1.8.112.5 98/01/13 PHNE_13800
marta:/#
Todos los parches oficiales de HP-UX (tanto a nivel de núcleo como de
aplicación) se identifican por cuatro letras que definen el tipo de parche,
seguidas de un número y
separados ambos por un subrayado: por ejemplo, como acabamos de ver,
el nombre de un parche puede ser PHNE/SMALL>_13800. Actualmente existen
cuatro tipos de parches definidos por Hewlett-Packard: comandos y
librerías (PHCO), kernel (PHKL), red (PHNE) y
subsistemas (PHSS); todos los parches comienzan con la denominación
común PH (patch HP-UX), y el número que los identifica es
único, independientemente del tipo de parche.
Hewlett-Packard distribuye cada cuatro meses sus parches oficiales en CDROMs o cintas, denominados Support Plus; también a través de Internet podemos descargar actualizaciones y parches en la dirección http://www.itrc.hp.com/, que nos indicará la URL adecuada a la que debemos dirigirnos en función de nuestra ubicación geográfica (Europa, América...). A diferencia de lo que sucede con otros fabricantes, en el caso de Hewlett-Packard es necesario estar registrado para acceder a sus parches, pero este registro es completamente gratuito.
Cuando descargamos un parche para HP-UX obtenemos un único fichero que no es más que un shellscript, y para instalarlo evidentemente lo primero que tenemos que hacer es ejecutar dicho archivo; esto generará un par de ficheros con el nombre del parche correspondiente y extensiones .text y .depot respectivamente13.2: el primero de ellos contiene información sobre el parche (nombre, plataformas, instrucciones de instalación...), mientras que el segundo es un archivo con formato TAR que podremos instalar mediante la orden swinstall. Si por ejemplo queremos instalar el parche PHNE/SMALL>_12492 ejecutaremos una orden similar a la siguiente:
marta:/# swinstall -x autoreboot=true -x match_target=true \ -s ./PHNE_12492.depot 2>&1 >/dev/null marta:/#La opción que más nos interesa de swinstall es sin duda `-s', que especifica la ubicación del archivo .depot en el sistema de ficheros; la opción `-x autoreboot=true' no indica obligatoriamente un reinicio del sistema, sino que simplemente lo permite: cada parche de HP-UX `sabe' si para instalarse correctamente es necesario reiniciar el operativo (nosotros lo podemos saber simplemente leyendo el fichero .text que hemos generado anteriormente), y si el reboot es necesario con esta opción indicamos que se lleve a cabo automáticamente, algo útil en instalaciones automáticas pero que puede ser crítico en algunas ocasiones.
Una vez instalado el parche correspondiente es recomendable ejecutar swverify; esta orden verifica que la información registrada en la IPD de HP-UX (dependencias, integridad de archivos...) se corresponde con la que se encuentra en los ficheros y directorios del sistema. Podemos verificar todos los registros de software (productos y parches) mediante el comodín `', o bien únicamente el parche que acabamos de instalar; aparte de mostrarse en la consola o terminal desde la que se ejecute, el resultado de la ejecución de esta orden se guardará en el fichero de log correspondiente, dentro del directorio /var/adm/sw/:
marta:/# swverify PHNE_12492
======= 12/11/01 03:23:34 MET BEGIN swverify SESSION
(non-interactive)
* Session started for user "root@marta".
* Beginning Selection
* Target connection succeeded for "marta:/".
* Software selections:
PHNE_12492.PHNE_12492,l=/,r=B.10.00.00.AA,\
a=HP-UX_B.10.20_700/800,v=HP:/
* Selection succeeded.
* Beginning Analysis
* Session selections have been saved in the file
"/.sw/sessions/swverify.last".
* The analysis phase succeeded for "marta:/".
* Verification succeeded.
NOTE: More information may be found in the agent logfile (location
is marta:/var/adm/sw/swagent.log).
======= 12/11/01 03:23:40 MET END swverify SESSION (non-interactive)
marta:/#
Antes de finalizar este punto es necesario recordar que siempre, antes de
cualquier actualización del sistema o de la aplicación de cualquier tipo de
parche, es imprescindible hacer una copia de seguridad completa de todos
los sistemas de ficheros; esto es algo que se recomienda en todos los
procedimientos de instalación de parches oficiales de Hewlett-Packard, y que
nos puede ayudar a devolver al sistema a un estado operativo ante cualquier
mínimo problema durante una actualización.
Extensiones de la seguridad
Product Description Files
HP-UX (tanto en su versión Trusted como en la habitual) posee un interesante mecanismo que nos permite verificar si ciertos ficheros han sido o no modificados: se trata de PDF (aquí no significa Portable Document Format sino Product Description File), que no es más que un repositorio de información acerca de todos y cada uno de los archivos que un determinado fileset instala en una máquina. Aunque el uso de los PDFs está desfasado desde la versión 10.20 del operativo (ha sido sustituido por el Software Distributor), la información que contienen es bastante interesante desde el punto de vista de la seguridad, ya que incluye características como el grupo, el propietario, los permisos, el tamaño o un checksum de cada archivo.En el directorio /system/ de un sistema HP-UX encontramos un subdirectorio por cada fileset instalado en la máquina; dentro de cada uno de estos subdirectorios existe - o ha de existir - un fichero denominado pdf, que contiene justamente la información de la que estamos hablando:
marta:/system/UX-CORE# pwd /system/UX-CORE marta:/system/UX-CORE# ls -l pdf -r--r--r-- 1 bin bin 36199 Jan 10 1995 pdf marta:/system/UX-CORE# head pdf % Product Description File % UX-CORE fileset, Release 9.05 /bin/alias:bin:bin:-r-xr-xr-x:160:1:70.2:4285122165: /bin/basename:bin:bin:-r-xr-xr-x:16384:1:70.5:3822935702: /bin/bg:bin:bin:-r-xr-xr-x:151:1:70.2:735613650: /bin/cat:bin:bin:-r-xr-xr-x:16384:1:70.2:1679699346: /bin/cd:bin:bin:-r-xr-xr-x:151:1:70.2:525751009: /bin/chgrp:bin:bin:-r-xr-xr-x:20480:1:70.2:203825783: /bin/chmod:bin:bin:-r-xr-xr-x:24576:1:70.6:1826477440: /bin/chown:bin:bin:-r-xr-xr-x:20480:1:70.2:1796648176: marta:/system/UX-CORE#Como vemos, cada línea de este fichero (excepto las que comienzan con el carácter `%') es la entrada correspondiente a un cierto archivo que el fileset instala en la máquina; su formato es el siguiente:
- pathname: Ruta absoluta del fichero.Para comprobar que los archivos de un determinado fileset no han sufrido modificaciones que afecten a alguno de los campos anteriores podemos programar un sencillo shellscript que utilizando la salida de órdenes como `ls -l', `what', `ident' o `cksum' compruebe el resultado de las mismas con la información almacenada en el PDF correspondiente:
- owner: Propietario (nombre o UID) del archivo.
- group: Grupo (nombre o GID) al que pertenece.
- mode: Tipo y permisos (en formato `ls -l').
- size: Tamaño del fichero en bytes.
- links: Número total de enlaces en el filesystem.
- version: Versión del archivo.
- checksum: Comprobación de errores según el algoritmo IEEE 802.3 CRC.
- linked_to: Nombres adicionales del fichero (enlaces duros o simbólicos).
marta:/# grep ^/bin/cat /system/UX-CORE/pdf
/bin/cat:bin:bin:-r-xr-xr-x:16384:1:70.2:1679699346:
marta:/# ls -l /bin/cat
-r-xr-xr-x 1 bin bin 16384 Jan 10 1995 /bin/cat
marta:/# what /bin/cat
/bin/cat:
$Revision: 70.2 $
marta:/# cksum /bin/cat
1679699346 16384 /bin/cat
marta:/#
De la misma forma, podemos ejecutar la orden `pdfck', que nos informará
de cualquier cambio detectado en los ficheros de un fileset:marta:/# pdfck /system/UX-CORE/pdf /etc/eisa/HWP0C70.CFG: deleted /etc/eisa/HWP0C80.CFG: deleted /etc/eisa/HWP1850.CFG: deleted /etc/eisa/HWP2051.CFG: deleted /etc/eisa/HWPC000.CFG: deleted /etc/eisa/HWPC010.CFG: deleted /etc/eisa/HWPC051.CFG: deleted /etc/newconfig/905RelNotes/hpuxsystem: deleted /etc/newconfig/inittab: size(848 -> 952), checksum(214913737 -> 2198533832) /usr/lib/nls/POSIX: owner(bin -> root), group(bin -> sys) marta:/#La aproximación a los verificadores de integridad que ofrece HP-UX es interesante, pero tiene también importantes carencias; en primer lugar, los algoritmos de CRC están pensados para realizar una comprobación de errores pura, especialmente en el tránsito de datos a través de una red (de hecho, el utilizado por los PDFs es el mismo que el definido por el estándar IEEE 802.3 para redes Ethernet), no para detectar cambios en el contenido de un archivo. Así, es factible - y no difícil - que un atacante consiga modificar sustancialmente un fichero sin afectar a su CRC global, con lo cual este hecho no sería detectado; si realmente queremos verificar que dos archivos son iguales hemos de recurrir a funciones hash como MD5. Por si esto fuera poco, pdfck es incapaz de detectar la presencia de nuevos ficheros en un directorio, con lo que algo tan simple como la aparición de un archivo setuidado en el sistema no sería notificado por esta utilidad; incluso ciertos cambios sobre los archivos de los cuales sí tiene constancia pasan desapercibidos para ella, como la modificación de listas de control de acceso en los ficheros:
marta:/# lsacl /bin/ps (bin.%,r-x)(%.sys,r-x)(%.%,r-x) /bin/ps marta:/# chacl "toni.users+rwx" /bin/ps marta:/# lsacl /bin/ps (toni.users,rwx)(bin.%,r-x)(%.sys,r-x)(%.%,r-x) /bin/ps marta:/#Como vemos, la orden anterior está otorgando a un usuario un control total sobre el archivo /bin/ps, con todo lo que esto implica; evidentemente, si esto lo ha realizado un atacante, estamos ante una violación muy grave de nuestra seguridad. Sin embargo, pdfck ejecutado sobre el PDF correspondiente no reportaría ninguna anomalía, con lo que la intrusió pasaría completamente desapercibida para el administrador.
A la vista de estos problemas, parece evidente que si necesitamos un verificador de integridad `de verdad' no podemos limitarnos a utilizar las facilidades proporcionadas por los PDFs de HP-UX; no obstante, ya que este mecanismo viene `de serie' con el sistema, no está de más usarlo, pero sin basarnos ciegamente en sus resultados. Siempre hemos de tener en cuenta que la información de cada fichero registrada en los archivos /system//pdf se almacena igual que se está almacenando el propio archivo, en un cierto directorio de la máquina donde evidentemente el administrador puede escribir sin poblemas. Por tanto, a nadie se le escapa que si un atacante consigue el privilegio suficiente para modificar una herramienta de base (por ejemplo, /bin/ls) y troyanizarla, no tendrá muchos problemas en modificar también el archivo donde se ha guardado la información asociada a la misma, de forma que limitándonos a comparar ambas no nos daremos cuenta de la intrusión. Así, es una buena idea guardar, nada más instalar el sistema, una copia del directorio /system/, donde están los PDFs, en una unidad de sólo lectura; cuando lleguemos al tema dedicado a la detección de intrusos hablaremos con más detalle de los verificadores de integridad y la importancia de esa primera copia, sobre un sistema limpio, de toda la información que posteriormente vamos a verificar.
inetd.sec(4)
Desde hace más de diez años, HP-UX incorpora en todas sus releases un mecanismo de control de acceso a los servicios que el sistema ofrece a través de inetd; se trata de un esquema muy similar al ofrecido por TCP Wrappers, esto es, basado en la dirección IP de la máquina o red solicitante del servicio, y procesado antes de ejecutar el demonio que va a servir la petición correspondiente. De esta forma, se establece un nivel de seguridad adicional al ofrecido por cada uno de estos demonios.Evidentemente, este esquema basa su configuración en un determinado archivo; el equivalente ahora a los ficheros /etc/hosts.allow y /etc/hosts.deny de TCP Wrappers es /usr/adm/inetd.sec (si no existe, el sistema funciona de la forma habitual, sin ningún nivel de protección adicional). El formato de cada línea del mismo es muy simple:
servicio allowdeny direccion
La directiva `servicio' indica el nombre del servicio a proteger tal y
como aparece en el archivo /etc/services (esto es una diferencia con
respecto a TCP
Wrappers, que se guía por el nombre concreto del demonio y no por el del
servicio); `allow' o `deny' (opcionales, si no se indica este campo
se asume un `allow') definen si vamos a permitir o denegar
el acceso, respectivamente, y por último en el campo `direccion' podemos
indicar (también es un campo opcional) la dirección IP de uno o más hosts o redes, así como los
nombres de los mismos. Si para un mismo servicio existe más de una entrada,
sólo se aplica la última de ellas; aunque a primera vista esto nos pueda
parecer una limitación importante, no lo es: si definimos una entrada `allow', a todos los sistemas no contemplados en ella se les negará el
acceso, si definimos una `deny' se le permitirá a todo el mundo excepto
a los explícitamente indicados, y si para un servicio no existe una entrada
en el fichero, no se establece ningún tipo de control.
Imaginemos que el contenido de /usr/adm/inetd.sec es el siguiente:
marta:/# grep -v ^\# /usr/adm/inetd.sec finger allow localhost 158.42.* ssh allow localhost 158.42.* 192.168.0.* pop allow marta:/#En este caso lo que estamos haciendo es permitir el acceso al servicio finger a todas las máquinas cuya dirección comience por 158.42., así como a la máquina local, y negarlo al resto, permitir acceso a ssh además de a estas a las que tengan una dirección 192.169.0., y dejar que cualquier sistema (no definimos el tercer campo) pueda consultar nuestro servicio POP3 (la entrada mostrada sería equivalente a un indicar únicamente el nombre del servicio, o a no definir una entrada para el mismo). Así, en el momento que un sistema trate de acceder a un servicio para el que no tiene autorización obtendrá una respuesta similar a la ofrecida por TCP Wrappers (esto es, el cierre de la conexión):
luisa:~# telnet 158.42.2.1 79 Trying 158.42.2.1... Connected to 158.42.2.1. Escape character is '^]'. Connection closed by foreign host. luisa:~#Como vemos, se trata de un mecanismo sencillo que, aunque no ofrezca el mismo nivel de protección que un buen cortafuegos (nos podemos fijar que la conexión se establece y luego se corta, en lugar de denegarse directamente como haría un firewall), y aunque no sea tan parametrizable - ni conocido - como TCP Wrappers, puede ahorrar más de un problema a los administradores de una máquina HP-UX; y ya que existe, no cuesta nada utilizarlo junto a cualquier otra medida de seguridad adicional que se nos ocurra (recordemos que en el mundo de la seguridad hay muy pocos mecanismos excluyentes, casi todos son complementarios). Para obtener más información acerca de este, podemos consultar la página de manual de inetd.sec(4).
El subsistema de red
Igual que al hablar de Solaris o AIX hemos hecho referencia a órdenes como como ndd o no, en HP-UX es obligatorio comentar la orden nettune, que permite examinar y modificar diferentes parámetros del subsistema de red del operativo en HP-UX 10.x (en versiones anteriores era necesario utilizar comandos como adb, y en HP-UX 11 se introduce la orden ndd, como veremos más adelante, muy similar a la existente en Solaris); por ejemplo, una consulta típica puede ser la siguiente:marta:/# /usr/contrib/bin/nettune -l arp_killcomplete = 1200 default = 1200 min = 60 max = 3600 units = seconds arp_killincomplete = 600 default = 600 min = 30 max = 3600 units = seconds arp_unicast = 300 default = 300 min = 60 max = 3600 units = seconds arp_rebroadcast = 60 default = 60 min = 30 max = 3600 units = seconds icmp_mask_agent = 0 default = 0 min = 0 max = 1 ip_check_subnet_addr = 1 default = 1 min = 0 max = 1 ip_defaultttl = 255 default = 255 min = 0 max = 255 units = hops ip_forwarding = 1 default = 1 min = 0 max = 1 ip_intrqmax = 50 default = 50 min = 10 max = 1000 units = entries pmtu_defaulttime = 20 default = 20 min = 10 max = 32768 tcp_localsubnets = 1 default = 1 min = 0 max = 1 tcp_receive = 32768 default = 32768 min = 256 max = 262144 units = bytes tcp_send = 32768 default = 32768 min = 256 max = 262144 units = bytes tcp_defaultttl = 64 default = 64 min = 0 max = 255 units = hops tcp_keepstart = 7200 default = 7200 min = 5 max = 12000 units = seconds tcp_keepfreq = 75 default = 75 min = 5 max = 2000 units = seconds tcp_keepstop = 600 default = 600 min = 10 max = 4000 units = seconds tcp_maxretrans = 12 default = 12 min = 4 max = 12 tcp_urgent_data_ptr = 0 default = 0 min = 0 max = 1 udp_cksum = 1 default = 1 min = 0 max = 1 udp_defaultttl = 64 default = 64 min = 0 max = 255 units = hops udp_newbcastenable = 1 default = 1 min = 0 max = 1 udp_pmtu = 0 default = 0 min = 0 max = 1 tcp_pmtu = 1 default = 1 min = 0 max = 1 tcp_random_seq = 0 default = 0 min = 0 max = 2 so_qlimit_max = 4096 default = 4096 min = 1 max = 8192 sb_max = 262144 default = 262144 min = 10240 max = 4294967295 hp_syn_protect = 0 default = 0 min = 0 max = 1 so_qlimit_min = 500 default = 500 min = 0 max = 8192 high_port_enable = 0 default = 0 min = 0 max = 1 high_port_max = 65535 default = 65535 min = 49153 max = 65535 ip_forward_directed_broadcasts = 1 default = 1 min = 0 max = 1 marta:/#Podemos ver que simplemente por el nombre de estos parámetros el valor de algunos de ellos parece importante (y lo es) para la seguridad del sistema; este es el caso de ip_forwarding o tcp_random_seq, por poner unos ejemplos. Podremos modificar el valor de todos aquellos parámetros que nos interese también mediante la orden nettune:
marta:/# /usr/contrib/bin/nettune -l ip_forwarding ip_forwarding = 1 default = 1 min = 0 max = 1 marta:/# /usr/contrib/bin/nettune -s ip_forwarding 0 marta:/# /usr/contrib/bin/nettune -l ip_forwarding ip_forwarding = 0 default = 1 min = 0 max = 1 marta:/#Quizás son dos los parámetros de los que más nos interesa estar pendientes para reforzar nuestra seguridad; el primero de ellos lo acabamos de ver, y es ip_forwarding. Como su nombre indica, esta directiva indica si la máquina ha de reenviar paquetes (si su valor es 1, el establecido por defecto) o si no ha de hacerlo (valor 0); como ya sabemos, lo más probable es que no nos interese este tipo de comportamiento en nuestro sistema HP-UX, por lo que debemos establecerle un valor `0' tal y como hemos visto en el ejemplo anterior.
El segundo parámetro al que debemos estar atentos para incrementar la robustez de un sistema HP-UX es tcp_random_seq, que es equivalente al TCP/SMALL>_STRONG/SMALL>_ISS de Solaris: si su valor es 0 (por defecto es así), la generación de números iniciales de secuencia TCP es bastante débil, si es 1 es algo más robusta, y si es 2 (el valor recomendado) se adapta al esquema definido en [Bel96], que como ya sabemos es más robusto que los anteriores.
Aparte de los dos anteriores, existe otro parámetro configurable vía nettune que es interesante para nuestra seguridad: hp_syn_protect, introducido en HP-UX 10.x, y que protege a una máquina de ataques SYN Flood si su valor es `1' (por defecto está a 0, desactivado), algo con un objetivo similar a las SYN Cookies del núcleo de Linux:
marta:/# /usr/contrib/bin/nettune -l hp_syn_protect hp_syn_protect = 0 default = 0 min = 0 max = 1 marta:/# /usr/contrib/bin/nettune -s hp_syn_protect 1 marta:/# /usr/contrib/bin/nettune -l hp_syn_protect hp_syn_protect = 0 default = 0 min = 0 max = 1 marta:/#No todos los parámetros importantes para la seguridad del subsistema de red de HP-UX son accesibles a través de nettune; un buen ejemplo es ip_block_source_routed, que como su nombre indica bloquea las tramas source routed que llegan a los interfaces de red cuando su valor es verdadero (`1'), enviando ante la recepción de una de ellas un paquete ICMP de destino inalcanzable hacia el origen de la misma ([Ste98b]). Otro ejemplo interesante es lanc_outbound_promisc_flag, que permite a las aplicaciones que utilizan el modo promiscuo de un interfaz capturar tanto los paquetes inbound (los `vistos' por el sistema) como los outbound (los transmitidos por el propio sistema); por defecto el valor de este parámetro es `0', lo que provoca que aplicaciones como tcpdump puedan no funcionar correctamente al ver sólo el tráfico no generado por el propio host. Para asignarle el valor true a ambos parámetros no podemos utilizar nettune, sino que tenemos que escribir directamente sobre el núcleo en ejecución:
marta:/# echo 'ip_block_source_routed/W1'|adb -w /stand/vmunix /dev/kmem marta:/# echo 'lanc_outbound_promisc_flag/W1'|adb -w /stand/vmunix /dev/kmem marta:/#Como hemos dicho al principio de este punto, en HP-UX 11 se introduce un comando ndd, similar al que existe en Solaris, que facilita enormemente el ajuste de parámetros de la seguridad del subsistema de red. Para obtener un listado de cada parámetro configurable a través de este interfaz podemos ejecutar `ndd -h', y para hacernos una idea de cuales de estos parámetros son los más importantes para nuestra seguridad una excelente referencia es [Ste00]; en cualquier caso, el nombre de los mismos, así como la sintaxis de la orden, es muy similar a la que existe en Solaris.
Como siempre, nos va a interesar deshabilitar diferentes tipos de forwarding en nuestro sistema: el IP Forwarding, el reenvío de paquetes con opciones de source routing, y los broadcasts; para conseguirlo podemos ejecutar `ndd -set':
marta11:/# ndd -set /dev/ip ip_forwarding 0 marta11:/# ndd -set /dev/ip ip_forward_src_routed 0 marta11:/# ndd -set /dev/ip ip_forward_directed_broadcasts 0 marta11:/#Como ya sabemos, el protocolo ICMP puede ser fuente de diferentes problemas de seguridad en el sistema, por lo que en ocasiones conviene modificar algunos de sus parámetros; es importante no responder a broadcasts de tramas ICMP/SMALL>_ECHO/SMALL>_REQUEST, ICMP/SMALL>_ADDRESS/SMALL>_MASK/SMALL>_REQUEST o ICMP/SMALL>_TIMESTAMP/SMALL>_REQUEST, así como tampoco hacerlo a peticiones ICMP/SMALL>_TIMESTAMP/SMALL>_REQUEST dirigidas directamente a la máquina (no en broadcast). En este orden, los parámetros del interfaz ndd son los siguientes:
marta11:/# ndd -set /dev/ip ip_respond_to_echo_broadcast 0 marta11:/# ndd -set /dev/ip ip_respond_to_address_mask_broadcast 0 marta11:/# ndd -set /dev/ip ip_respond_to_timestamp_broadcast 0 marta11:/# ndd -set /dev/ip ip_respond_to_timestamp 0 marta11:/#El envio de tramas ICMP/SMALL>_REDIRECT e ICMP/SMALL>_SOURCE/SMALL>_QUENCH se puede evitar también mediante ndd, así como la activación de la defensa contra el SYN flood que proporciona HP-UX:
marta11:/# ndd -set /dev/ip ip_send_redirects 0 marta11:/# ndd -set /dev/ip ip_send_source_quench 0 marta11:/# ndd -set /dev/tcp tcp_syn_rcvd_max 500 marta11:/#Al igual que sucedía en Solaris (o en AIX con la orden no), los cambios efectuados por ndd tienen efecto sólo mientras no se reinicia el sistema, por lo que si queremos hacerlos permanentes hemos de ejecutarlos automáticamente en el arranque de la máquina. HP-UX ejecuta en uno de sus scripts de arranque la orden `ndd -c', que inicializa los valores por defecto de cada parámetro, para lo que lee el archivo /etc/rc.config.d/nddconf. En este fichero (de texto), podemos definir las entradas correspondientes a los valores de cada parámetro que nos interesen, de forma que en cada reinicio del sistema se asignen automáticamente; no se trata de un simple shellscript, sino de un fichero de configuración con tres entradas por parámetro a configurar, que definen el componente sobre el que se aplica (tcp, ip, arp...), el nombre del parámetro, y el valor que queremos darle. Es conveniente, tras modificar el fichero, que comprobemos que efectivamente todo ha funcionado como habíamos definido tras un reinicio del sistema (es decir, que cada uno de los parámetros tiene el valor que nosotros queremos), ya que, como se cita en [Ste00], existen algunos problemas relacionados con esta forma de trabajar; si no fuera así, en la misma obra se explica una sencilla modificación del sistema que hará que todo funcione correctamente.
El núcleo de HP-UX
Generalmente se recomienda utilizar la herramienta SAM (System Administration Manager) en los sistemas HP-UX, que además de las tareas clásicas de administración permite modificar parámetros de un núcleo, reconstruirlo e instalarlo en el sistema de una forma sencilla, guardando una copia del kernel actual en /SYSBACKUP (algo muy útil, ya que recordemos que un núcleo mal configurado puede hacer que la máquina no arranque). Por tanto, desde SAM hemos de entrar en el menú `Kernel Configuration' y desde ahí elegir los parámetros que deseamos modificar para construir el nuevo kernel; como en el caso de Solaris, podemos fijar el parámetro maxusers (también con un significado similar al que esta variable posee en Solaris) y también el número máximo de procesos por usuario (parámetro maxuprc).Si deseamos modificar y reconstruir el nuevo núcleo a mano, el proceso difiere entre HP-UX 9.x, HP-UX 10.x y HP-UX 11.x. Los pasos en cada caso son los siguientes:
- HP-UX 9.x
# cd /etc/conf # cp dfile dfile.old # vi dfile # config dfile # make -f config.mk # mv /hp-ux /hp-ux.old # mv /etc/conf/hp-ux /hp-ux # cd / ; shutdown -ry 0
- HP-UX 10.x
# cd /stand/build # /usr/lbin/sysadm/system_prep -s system # vi system # mk_kernel -s system # mv /stand/system /stand/system.prev # mv /stand/build/system /stand/system # mv /stand/vmunix /stand/vmunix.prev # mv /stand/build/vmunix_test /stand/vmunix # cd / ; shutdown -ry 0
- HP-UX 11.x
# cd /stand/build # /usr/lbin/sysadm/system_prep -s system # vi system # /usr/sbin/mk_kernel -s /stand/build/system # mv /stand/system /stand/system.prev # mv /stand/vmunix /stand/vmunix.prev # mv system .. # /usr/sbin/kmupdate # cd / ; shutdown -ry 0
maxuprc 60 maxusers 100Otros parámetros a tener en cuenta relacionados con la gestión de procesos son nproc (número máximo de procesos en el sistema), nkthread (número máximo de hilos simultáneos en el núcleo) o max_thread_proc (número máximo de hilos en un proceso).
Igual que en Solaris - y en cualquier Unix en general - también nos puede interesar limitar algunos parámetros relacionados con el sistema de ficheros, de cara a evitar posibles consumos excesivos de recursos que puedan comprometer nuestra seguridad. Por ejemplo, maxfiles indica un límite soft a los ficheros abiertos por un proceso y maxfiles_lim un límite hard (que obviamente ha de ser mayor que el anterior); nfile indica el número máximo de ficheros abiertos en el sistema y ninode el número de inodos (se recomienda que ambos coincidan). Por último, nflocks indica el número máximo de ficheros abiertos y bloqueados en la máquina.
En el núcleo de HP-UX 11i se ha introducido un nuevo parámetro que puede resultar muy interesante para incrementar nuestra seguridad; se trata de executable_stack, que permite evitar que los programas ejecuten código de su pila, previniendo así desbordamientos ([HP00b]). Por motivos de compatibilidad su valor es 1 (esto es, está habilitado y los programas pueden ejecutar código de su pila), pero desde SAM podemos cambiar este valor a 0; si lo hacemos así y un programa concreto necesita que su pila sea ejecutable, podemos darle ese privilegio mediante la orden chatr:
marta:/# chatr +es enable /usr/local/bin/check marta:/#
Siguiente: Seguridad de la subred Subir: Algunos sistemas Unix Anterior: AIX Índice General 2002-07-15
