Re: Traducción del manual de seguridad al español: nota a traductores
after-install.sgml
--
Manuel Parrilla Sánchez
<!-- CVS revision of original english document "1.42" -->
<chapt>Después de la instalación
<p>Una vez concluida la instalación del sistema, aún pueden hacerse más
cosas para protegerlo; puede seguir algunos de los pasos descritos en este
capítulo. Por supuesto esto dependerá realmente de su configuración, pero para
evitar el acceso físico, debería leer <ref id="bios-boot">,<ref
id="lilo-passwd">,<ref id="kernel-root-prompt">, <ref id="floppy-boot">,
<ref id="restrict-console-login">, y <ref id="restrict-reboots">.
<p>Antes de conectarse a cualquier red, especialmente si se trata de una red
pública, debería, como mínimo, ejecutar una actualización de seguridad (vea
<ref id="security-update">). Opcionalmente, podría obtener una imagen de su
sistema (vea <ref id="snapshot">).
<sect id="debian-sec-announce">Suscribirse a la lista de correo de anuncios de
seguridad de Debian
<p>Con objeto de recibir información sobre las actualizaciones de seguridad
disponibles, debería suscribirse a la lista de correo debian-security-announce
para recibir los Avisos de Seguridad de Debian (DSAs). Vea <ref
id="debian-sec-team"> para más información sobre cómo trabaja el equipo de
seguridad de Debian. Para informarse sobre cómo suscribirse a las listas de
correo de Debian lea <url id="http://lists.debian.org";>.
<p>Los DSAs llevan las firmas del equipo de seguridad de Debian, las cuales
pueden obtenerse de <url id="http://security.debian.org";>.
<p>Debería considerar, también, suscribirse a la <url
id="http://lists.debian.org/debian-security"; name="lista de correo
debian-security"> donde se discuten temas generales sobre seguridad en el
sistema operativo Debian. Podrá contactar en la lista con otros compañeros
administradores de sistemas, así como también con desarrolladores de Debian y
desarrolladores de herramientas de seguridad que pueden responder a sus
preguntas, y ofrecer consejos.
<p>ARRÉGLEME: ¿Añadir aquí también la clave?
<sect id="security-update">Ejecutar una actualización de seguridad
<p>Tan pronto como se detecta un nuevo error de seguridad en un paquete, los
responsables de mantenimiento de Debian y los autores de los programas sacan
generalmente parches para ellos en días o incluso en horas. Tras repararse el
error, se proporciona un nuevo paquete en <url
name="http://security.debian.org"; id="http://security.debian.org";>.
<p>Si está instalando una nueva versión de Debian tiene que tener en cuenta que,
desde que se hizo dicha versión, podrían haber aparecido actualizaciones de
seguridad tras descubrirse vulnerabilidades en algún paquete. También podrían
haberse producido revisiones menores (hubo siete en la versión Debian 2.2
<em>potato</em>) incluyendo estas actualizaciones de paquetes.
<p>Deberá anotar la fecha en que se creó la copia del medio extraíble (si es
que está utilizando uno) y comprobar en el sitio de seguridad si existen
actualizaciones disponibles. Si las hay y no puede descargar los paquetes del
sitio de seguridad desde otro sistema (¿no está conectado a Internet todavía?
¿no?) antes de conectarse a la red debería considerar (si no está protegido por
un cortafuegos por ejemplo) añadir reglas de cortafuego de forma que su sistema
únicamente pueda conectarse a security.debian.org y luego ejecutar la
actualización. En <ref id="fw-security-update"> se muestra una configuración de
ejemplo.
<p><em>Nota:</em>Desde Debian woody 3.0, tras la instalación se le da la
oportunidad de añadir al sistema actualizaciones de seguridad. Si responde que
sí, el sistema de instalación seguirá los pasos apropiados para añadir la fuente
de las actualizaciones de seguridad a las fuentes de los paquetes, y su
sistema, si tiene conexión a Internet, descargará e instalará todas las
actualizaciones de seguridad que podrían haber tenido lugar tras la creación del
medio extraíble. Si está actualizando una versión previa de Debian, o pidió al
sistema de instalación que no lo hiciera, debería seguir los pasos descritos
aquí.
<p>Para actualizar el sistema de forma manual, ponga la siguiente línea en
<file>sources.list</file> y obtendrá automáticamente actualizaciones de
seguridad, siempre que actualice su sistema.
<example>
deb http://security.debian.org/ stable/updates main contrib non-free
</example>
<p>Una vez que haya hecho esto, puede utilizar <package>apt</package> o
<package>dselect</package> para actualizar:
<list>
<item>Si quiere utilizar <package>apt</package> haga simplemente (como
superusuario):
<example>
# apt-get update
# apt-get upgrade
</example>
<item>Si quiere utilizar <package>dselect</package> entonces primero [A]ctualice,
luego [I]nstale y finalmente, [C]onfigure los paquetes instalados/actualizados.
</list>
<p>Si quiere, puede añadir también las líneas deb-src a
<file>/etc/apt/sources.list</file>. Vea <manref name="apt" section="8"> para más
detalles.
<p>Nota: <em>No</em> necesita añadir la siguiente línea:
<example>
deb http://security.debian.org/debian-non-US stable/non-US main contrib non-free
</example>
<p>esto es debido a que security.debian.org está hospedado en una localización
non-US y no tiene un archivo non-US separado.
<sect1 id="lib-security-update">Actualización de seguridad de bibliotecas
<p>Una vez que haya ejecutado una actualización de seguridad, podría necesitar
reiniciar alguno de los servicios del sistema. Si no lo hace, algunos servicios
podrían ser vulnerables todavía tras una actualización de seguridad. La razón
de esto es que los demonios que estaban ejecutándose antes de una actualización,
podrían estar usando aún las bibliotecas antiguas (anteriores a la actualización)
<footnote>Incluso aunque las bibliotecas se hayan eliminado del sistema de
archivos, los inodos no se limpiarán mientras haya programas con un descriptor
de archivo abierto apuntándolos</footnote>. Con objeto de averiguar qué demonios
podrían necesitar reiniciarse, puede utilizar el programa
<prgn>checkrestart</prgn> (disponible en el paquete
<package>debian-goodies</package>) o utilizar la siguiente línea (como
superusuario):
<example>
# lsof | grep dpkg- | awk '{print $1, $8}' | sort +0
</example>
<P>Algunos paquetes (como <package>libc6</package>) harán esta comprobación en
la fase de post-instalación para un conjunto limitado de servicios, debido
especialmente a que una actualización de las bibliotecas esenciales podría detener
algunas aplicaciones (hasta que sean reiniciadas)<footnote>Esto ocurría, por
ejemplo, en la actualización de libc6 2.2.x a 2.3.x debido a temas de
autenticación NSS, vea <url
id="http://lists.debian.org/debian-glibc/2003/debian-glibc-200303/msg00276.html";>.</footnote>.
<P>Si lleva al sistema al nivel de ejecución 1 (usuario único) y luego lo
devuelve al nivel de ejecución 3 (muti-usuario) debería asegurarse de reiniciar
la mayoría (si no todos) los servicios del sistema. Pero esto no es una opción
si está ejecutando la actualización de seguridad desde una conexión remota (como
ssh) puesto que ésta se cortará.
<p>Sea cauto cuando trate con actualizaciones de seguridad, si las está haciendo
sobre una conexión remota como ssh. Un procedimiento sugerido para una
actualización de seguridad que requiera el reinicio de un servicio es reiniciar
el demonio de SSH y luego, inmediatamente, intentar una nueva conexión ssh sin
cortar la anterior. Si la conexión falla, deshaga la actualización e investigue
el asunto.
</sect1>
<sect1 id="kernel-security-update">Actualización de seguridad del núcleo
<P>Primero, asegúrese de que el núcleo está siendo gestionado a través del
sistema de paquetes. Si usted ha instalado mediante el sistema de instalación
de Debian 3.0 o versiones anteriores, su núcleo <em>no</em> está integrado en el
sistema de paquetes y podría estar desactualizado. Puede confirmarlo fácilmente
si ejecuta:
<example>
$ dpkg -S `readlink -f /vmlinuz`
kernel-image-2.4.27-2-686: /boot/vmlinuz-2.4.27-2-686
</example>
<p>Si su núcleo no está siendo gestionado, verá un mensaje diciendo que el
gestor de paquetes no encuentra el archivo asociado a ningún paquete, en lugar
del mensaje anterior que dice que <package>kernel-image-2.4.27-2-686</package>
proporciona el archivo asociado al núcleo actualmente en ejecución.
Entonces, en primer lugar necesitará instalar manualmente un paquete de la
imagen del núcleo. La imagen del núcleo exacta que necesita instalar depende de
su arquitectura y de la versión de su núcleo. Tras haber hecho esto, usted podrá
gestionar las actualizaciones de seguridad del núcleo de igual forma que las de
cualquier otro paquete. En cualquier caso, tenga en cuenta que
<em>únicamente</em> se realizarán aquellas actualizaciones del núcleo que
correspondan a la misma versión de núcleo que esté utilizando, esto es,
<prgn>apt</prgn> no actualizará automáticamente su núcleo de la versión 2.4 a la
versión 2.6 (o de la versión 2.4.26 a la versión 2.4.27<footnote>A no ser que
haya instalado un «metapaquete» del núcleo como
<package>kernel-image-2.4-686</package>, el cual siempre tomará la última
revisión menor para una versión de núcleo y una arquitectura dada</footnote>).
<p>El sistema de instalación de la versión 3.2 de Debian manipulará el núcleo
seleccionado(2.4 ó 2.6) como parte del sistema de paquetes. Puede comprobar qué
núcleo tiene instalado ejecutando:
<example>
$ COLUMNS=150 dpkg -l 'kernel-image*' | awk '$1 ~ /ii/ { print $0 }'
</example>
<p>Para ver si su núcleo necesita actualizarse ejecute:
<example>
$ kernfile=`readlink -f /vmlinuz`
$ kernel=`dpkg -S $kernfile | awk -F : '{print $1}'`
$ apt-cache policy $kernel
kernel-image-2.4.27-2-686:
Installed: 2.4.27-9
Candidate: 2.4.27-9
Version Table:
*** 2.4.27-9 0
(...)
</example>
<P>Si está haciendo una actualización de seguridad que incluya la imagen del
núcleo, <em>necesita</em> reiniciar el sistema para que la actualización de
seguridad tenga efecto. De otra forma, estará ejecutando todavía la antigua (y
vulnerable) imagen del núcleo.
<!-- ARRÉGLEME: Haga un script para comprobar lo anterior, quizás utilizando ps
-p 1 -o etime | tail -1 y obtener el tiempo de creación de `readlink -f /vmlinuz` -->
<p>Si necesita rearrancar el sistema (debido a una actualización del núcleo)
debería asegurarse de que el núcleo arrancará correctamente y de que se
restablecerá la conectividad de la red, especialmente si la actualización de
seguridad se hizo sobre una conexión remota como ssh. Para lo anterior puede
configurar su cargador de arranque para que pueda arrancar con el núcleo
original en caso de fallo (para obtener información más detallada lea
<url id="http://www.debian-administration.org/?article=70"; name="Arranque remoto
de máquinas Debian GNU/Linux">). Para lo último, tiene que introducir un script
de prueba de la conectividad de la red que compruebe si el núcleo ha arrancado
adecuadamente el subsistema de red y reinicie el sistema si esto no ha ocurrido
<footnote>En el artículo <url
id="http://www.debian-administration.org/?article=70"; name="Arranque remoto de
máquinas Debian GNU/Linux"> hay un «script» de ejemplo disponible llamado
<url id="http://www.debian-administration.org/articles/70/testnet"; name="testnet">.
También hay disponible un «script» de prueba de conectividad de red más
elaborado en el artículo <url id="http://www.debian-administration.org/?article=128";
name="Prueba de la conectividad de la red">.</footnote>. Esto debería evitar
sorpresas desagradables como actualizar el núcleo y luego darse cuenta, tras el
reinicio, que no se detecta o configura correctamente el hardware de red y tiene
que realizar un gran esfuerzo para volver a tener el sistema funcionando
correctamente. Por supuesto, teniendo la consola en serie del sistema
<footnote>Configurar una consola en serie está más allá del ámbito de este
documento. Para más información lea el
<url id="http://www.tldp.org/HOWTO/Serial-HOWTO.html"; name="CÓMO de serie">
y el <url id="http://www.tldp.org/HOWTO/Remote-Serial-Console-HOWTO/index.html";
name="CÓMO de consola en serie remota">.</footnote> conectada a un servidor de
terminal o consola debería también ayudarle a depurar de forma remota los asuntos
del rearranque.
</p>
</sect1>
<sect id="bios-boot">Cambiar la BIOS (de nuevo)
<p>¿Recuerda <ref id="bios-passwd">? Bien, entonces ahora debería, una vez que
no necesite arrancar desde un medio extraíble, cambiar la configuración
predeterminada de la BIOS de forma que <em>sólo</em> arranque desde el disco
duro. Asegúrese de que no perderá la contraseña de la BIOS, de lo contrario, en
el caso de un fallo del disco duro no podrá volver a la BIOS y cambiar la
configuración para recuperarlo utilizando, por ejemplo, un CD-ROM.
<p>Otra forma menos segura pero más conveniente es cambiar la configuración para
tener el arranque del sistema desde el disco duro y, si éste falla, intentarlo
desde un medio extraíble. De hecho, esto se hace a menudo porque la mayoría de
la gente no usa la contraseña de la BIOS con frecuencia y es fácilmente
olvidada.
<sect id="lilo-passwd">Poner una contraseña a lilo o grub
<p>
Es muy fácil acceder a un intérprete de órdenes como superusuario y cambiar las
contraseñas, simplemente tecleando
<tt><name-of-your-bootimage> init=/bin/sh</tt>. Tras cambiar las
contraseñas y reiniciar el sistema, la persona tiene acceso ilimitado (como
superusuario) y puede hacer cualquier cosa que quiera en el sistema. Después de
este procedimiento, usted no tendrá acceso a su sistema como administrador, porque no
conoce la contraseña de superusuario.
<p>
Para asegurarse de que esto no pueda suceder, debería establecer una contraseña
para el cargador de arranque. Puede escoger entre una contraseña global o una
contraseña para una cierta imagen.
<p>
Para LILO necesitará editar el archivo de configuración
<file>/etc/lilo.conf</file> y agregar una línea de <tt>password</tt> y otra con
la palabra <tt>restricted</tt> (N. del T., contraseña y restringido
respectivamente), como en el ejemplo siguiente:
<example>
image=/boot/2.2.14-vmlinuz
label=Linux
read-only
password=hackme
restricted
</example>
<p>Luego, asegúrese de quitar los derechos de lectura al archivo de
configuración, para evitar que usuarios locales puedan leer la contraseña.
Cuando haya terminado, ejecute LILO. Omitir la línea <tt>restricted</tt>
hace que LILO pida siempre una contraseña, sin considerar si se le pasaron
parámetros a LILO. Los permisos por omisión para <file>/etc/lilo.conf</file>
garantizan al superusuario derechos de lectura y escritura, y habilita acceso de
sólo lectura de <file>lilo.conf</file> para el grupo «root».
<p> Si usted usa GRUB en lugar de LILO, edite <file>/boot/grub/menu.lst</file> y
agregue las dos líneas siguientes al principio (sustituyendo, por supuesto,
<tt>hackme</tt> por la contraseña deseada). Esto evita que los usuarios puedan
editar los parámetros de arranque. <tt>timeout 3</tt> especifica un retardo de
tres segundos antes de que <prgn>grub</prgn> arranque con los parámetros por
omisión.
<example>
timeout 3
password hackme
</example>
<p>Para asegurar más la integridad de la contraseña, puede guardarla en forma
cifrada. La utilidad grub-d5-crypt genera una contraseña «hash» que es
compatible con el algoritmo de cifrado de contraseñas de grub (md5).
Para especificar en <prgn>grub</prgn> que se va a utilizar una contraseña con
formato md5, use la siguiente instrucción:
<example>
timeout 3
password --md5 $1$bw0ez$tljnxxKLfMzmnDVaQWgjP0
</example>
Se añadió el parámetro --md5 para indicar a grub que realice el proceso de
autenticación con md5. La contraseña proporcionada es la versión cifrada con
md5 de «hackme». Es preferible utilizar la contraseña cifrada con md5 que usar
su equivalente en formato de texto. Se puede encontrar más información sobre las
contraseñas de <prgn>grub</prgn> en el paquete <package>grub-doc</package>.
<sect id="kernel-root-prompt">Eliminar en el núcleo el intérprete de órdenes
para el superusuario en el arranque
<p>Nota: No es aplicable a los núcleos proporcionados para Debian 3.1.
<p>Los núcleos 2.4 de Linux proporcionan una forma de acceder como superusuario al
intérprete de órdenes durante el arranque, que será presentada justo después de
cargar el sistema de archivos «cramfs». Aparecerá un mensaje para permitir al
administrador entrar en un intérprete de órdenes con privilegios de
superusuario. Este intérprete de órdenes puede utilizarse para cargar módulos
manualmente cuando la autodetección falla. Este comportamiento es el
predeterminado para <file>linuxrc</file> de <prgn>initrd</prgn>. Aparecerá el
siguiente mensaje:
<example>
Press ENTER to obtain a shell (waits 5 seconds)
</example>
<p>(N. del T.: Pulse ENTER para obtener un intérprete de órdenes (dispone de 5
segundos)).
<p>Para eliminar este comportamiento necesita modificar
<file>/etc/mkinitrd/mkinitrd.conf</file> y poner:
<example>
# DELAY The number of seconds the linuxrc «script» should wait to
# allow the user to interrupt it before the system is brought up
DELAY=0
</example>
<p>Luego regenere su imagen de «ramdisk». Puede hacer esto, por ejemplo,
con:
<example>
# cd /boot
# mkinitrd -o initrd.img-2.4.18-k7 /lib/modules/2.4.18-k7
</example>
<p>O hacer (mejor aún):
<example>
# dpkg-reconfigure -plow kernel-image-2.4.x-yz
</example>
<p>Note que Debian 3.0 <em>woody</em> permite a los usuarios instalar núcleos
2.4 (seleccionando <em>flavors</em>), <em>sin embargo</em> el núcleo
predeterminado es el 2.2 (excepto para algunas arquitecturas, para las cuales el
núcleo 2.2 no está soportado). Si considera que esto es un fallo, vea
<url id="http://bugs.debian.org/145244"; name="Error 145244"> antes de informar
sobre ello.
<sect id="floppy-boot">Deshabilitar el arranque desde disquete
<p>
El MBR predeterminado en Debian, antes de la versión 2.2, no actuaba como un
registro principal de arranque normal y dejaba abierto un método para entrar
fácilmente en el sistema:
<list>
<item>Presione la tecla «shift» durante el arranque, y aparecerá un «prompt» de
MBR.
<item>Luego presione F, y su sistema arrancará desde un disquete. Esto puede
utilizarse para acceder al sistema como superusuario.
</list>
<p>Este comportamiento puede cambiarse introduciendo:
<example>
lilo -b /dev/hda
</example>
<p>Ahora LILO se ha puesto dentro del MBR. Esto también puede conseguirse
añadiendo <tt>boot=/dev/hda</tt> a <file>lilo.conf</file>. Hay otra solución
para deshabilitar completamente el «prompt» del MBR:
<example>
install-mbr -i n /dev/hda
</example>
<p>Por otro lado, esta «puerta trasera», de la que mucha gente no está enterada,
puede salvarle el pellejo si por cualquier razón encuentra graves problemas con
la instalación.
<p>ARRÉGLEME Compruebe si esto es realmente cierto a partir de 2.2 o era desde
2.1.
INFO: Los discos de inicio a partir de Debian 2.2 NO instalan el mbr, sino
únicamente LILO.
<sect id="restrict-console-login">Restringir el acceso a un inicio de sesión
en consola
<p>Algunas directrices de seguridad podrían forzar a los administradores a entrar
al sistema a través de la consola con su usuario/contraseña y luego convertirse
en superusuario (con <prgn>su</prgn> o <prgn>sudo</prgn>). Estas directrices están
implementadas en Debian mediante la edición del archivo
<file>/etc/login.defs</file> o <file>/etc/securetty</file> cuando se utilice
PAM. En:
<list>
<item><file>login.defs</file>, editando la variable CONSOLE, que define un
archivo o lista de terminales sobre los que está permitido el acceso al sistema
como superusuario.
<item><file>securetty</file><footnote>
<file>/etc/securetty</file> es un archivo de configuración que pertenece al
paquete <package>login</package>.
</footnote>
agregando/quitando los terminales desde los cuales estará permitido el acceso
como superusuario. Si desea permitir únicamente acceso local a consola, entonces
necesita <em>console</em>, <em>ttyX</em><footnote> o <em>ttyvX</em> en
GNU/FreeBSD, y <em>ttyE0</em> en GNU/KNetBSD.</footnote>
y <em>vc/X</em> (si utiliza dispositivos <em>devfs</em>), podría querer añadir
también <em>ttySX</em><footnote>
O <em>comX</em> en GNU/Hurd, <em>cuaaX</em> en GNU/FreeBSD,
y <em>ttyXX</em> en GNU/KNetBSD.
</footnote>
si está utilizando
una consola en serie para acceso local (donde X es un número entero, podría
querer tener múltiples instancias<footnote>
La configuración predeterminada en <em>woody</em> incluye 12 tty y consolas vc
locales, así como el dispositivo <em>console</em> pero no permite acceso
remoto. En <em>sarge</em> la configuración predeterminada proporciona 64
consolas para tty y consolas vc. Usted puede quitarlas con tranquilidad si no
las va a utilizar.
</footnote>
dependiendo del número de consolas virtuales que tenga habilitadas en
<file>/etc/inittab</file><footnote>
Busque las llamadas de <em>getty</em>.</footnote>). Para más información sobre
dispositivos de terminal, lea el
<url id="http://tldp.org/HOWTO/Text-Terminal-HOWTO-6.html";
name="CÓMO de terminal de texto">.
</list>
<p>Cuando use PAM, pueden configurarse en <file>/etc/pam.d/login</file> otros
cambios en el proceso de acceso, que pueden incluir restricciones para usuarios
y grupos durante períodos de tiempo. Una característica interesante que puede
deshabilitarse es la posibilidad de acceder con contraseñas nulas (en
blanco). Esta característica puede limitarse quitando <em>nullok</em> de la
linea:
<example>
auth required pam_unix.so nullok
</example>
<sect id="restrict-reboots">Restringir los rearranques del sistema a través de
la consola
<p>Si su sistema tiene un teclado conectado, cualquiera (sí <em>cualquiera</em>)
puede reiniciar el sistema por medio del teclado sin registrarse en el
sistema. Esto podría estar contemplado, o no, en sus directrices de
seguridad. Si quiere restringirlo, tiene que comprobar <file>/etc/inittab</file>
para que la línea que incluye <tt>ctrlaltdel</tt> llame a <prgn>shutdown</prgn>
con la opción <tt>-a</tt> (recuerde ejecutar <tt>init q</tt> después de hacer
cualquier cambio en este archivo). Por omisión, en Debian se incluye la
siguiente línea:
<example>
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
</example>
<p>Ahora, con objeto de permitir a <em>algunos</em> usuarios apagar el sistema,
como se describe en la página del manual de <manref section="8"
name="shutdown">, usted tiene que crear el archivo
<file>/etc/shutdown.allow</file> e incluir allí los nombres de los usuarios que
pueden apagar el sistema. Cuando se utilice el <em>saludo de los tres
dedos</em> (a.k.a. <em>ctrl+alt+del</em>) el programa comprobará si se trata de
alguno de los usuarios listados en el archivo. Si no es ninguno de ellos,
<prgn>shutdown</prgn> <em>no</em> reiniciará el sistema.
</sect>
<sect>Montar particiones de manera correcta
<p>
Cuando se monta una partición ext2, hay varias opciones adicionales que se
pueden utilizar en la llamada a «mount» o en el archivo <file>/etc/fstab</file>.
Por ejemplo, esta es la entrada en mi archivo fstab para la partición
<file>/tmp</file>:
<example>
/dev/hda7 /tmp ext2 defaults,nosuid,noexec,nodev 0 2
</example>
<p>
Puede verse la diferencia en las secciones de opciones. La opción
<tt>nosuid</tt> ignora completamente los bits de «setuid» y «setgid»,
mientras que <tt>noexec</tt> prohibe la ejecución de cualquier programa
en ese punto de montaje, y <tt>nodev</tt>, ignora los dispositivos. Esto suena
fenomenal, pero
<list>
<item>únicamente se aplica a sistemas de archivos ext2
<item>puede burlarse fácilmente
</list>
<p>La opción <tt>noexec</tt> impide ejecutar los binarios directamente, aunque
esto puede burlarse fácilmente:
<example>
alex@joker:/tmp# mount | grep tmp
/dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev)
alex@joker:/tmp# ./date
bash: ./date: Permission denied
alex@joker:/tmp# /lib/ld-linux.so.2 ./date
Sun Dec 3 17:49:23 CET 2000
</example>
<p>Sin embargo, muchos crackers inexpertos («script» kiddies) cuentan con
«exploits» (N. del T., código escrito con el fin de aprovecharse de algún error
de programación para obtener ciertos privilegios en el sistema) que intentan
crear y ejecutar archivos en <file>/tmp</file>. Si no tienen una clave, caerán
en la trampa. En otras palabras, no puede engañarse a un usuario para que
ejecute un troyano en <file>/tmp</file>, por ejemplo cuando casualmente añade
<file>/tmp</file> a su «PATH».
<p>También se advierte de que algún «script» podría depender de que
<file>/tmp</file> sea ejecutable. En particular, Debconf tiene (¿tenía?) algunos
asuntos relacionados con esto, para más información vea el error <url
id="http://bugs.debian.org/116448"; name="116448">.
-------------------------------------------------------------------BORRAR
<p>
El siguiente es un ejemplo más completo. Una nota, sin embargo:
<file>/var</file> podría ponerse como noexec, pero algún software
<footnote>Entre ellos se incluyen el gestor de paquetes <package>dpkg</package>,
puesto que los «scripts» de instalación (post,pre) u desinstalación (post,pre) están
en <file>/var/lib/dpkg/</file>, y Smartlist</footnote> almacena sus programas en
<file>/var</file>. Lo mismo se aplica a la opción nosuid.
<example>
/dev/sda6 /usr ext2 defaults,ro,nodev 0 2
/dev/sda12 /usr/share ext2 defaults,ro,nodev,nosuid 0 2
/dev/sda7 /var ext2 defaults,nodev,usrquota,grpquota 0 2
/dev/sda8 /tmp ext2 defaults,nodev,nosuid,noexec,usrquota,grpquota 0 2
/dev/sda9 /var/tmp ext2 defaults,nodev,nosuid,noexec,usrquota,grpquota 0 2
/dev/sda10 /var/log ext2 defaults,nodev,nosuid,noexec 0 2
/dev/sda11 /var/account ext2 defaults,nodev,nosuid,noexec 0 2
/dev/sda13 /home ext2 rw,nosuid,nodev,exec,auto,nouser,async,usrquota,grpquota 0 2
/dev/fd0 /mnt/fd0 ext2 defaults,users,nodev,nosuid,noexec 0 0
/dev/fd0 /mnt/floppy vfat defaults,users,nodev,nosuid,noexec 0 0
/dev/hda /mnt/cdrom iso9660 ro,users,nodev,nosuid,noexec 0 0
</example>
<sect1>Establecer <file>/tmp</file> como noexec
<p>
Tenga cuidado si establece <file>/tmp</file> como noexec cuando quiera instalar
nuevo software, puesto que algunos programas podrían usarlo para la
instalación. <package>apt</package> es uno de esos programas (vea
<url id="http://bugs.debian.org/116448";>) si no se configura de forma correcta
<tt>APT::ExtractTemplates::TempDir</tt> (vea
<manref name="apt-extracttemplates" section="1">).
En el archivo <file>/etc/apt/apt.conf</file>, usted puede asignarle a esta
variable otro directorio con privilegios de exec, que no sea <file>/tmp</file>.
<!-- This is a duplicate of the example a few paragraphs up -->
<p>Con respecto a noexec, por favor sea consciente de que podría no ofrecerle
tanta seguridad.
Considere esto:
<example>
$ cp /bin/date /tmp
$ /tmp/date
(no se ejecuta debido a noexec)
$/lib/ld-linux.so.2 /tmp/date
(funciona puesto que date no se ejecuta directamente)
</example>
<sect1>Establecer /usr como de sólo-lectura
<p>Si usted establece <file>/usr</file> como de sólo-lectura, no podrá instalar
nuevos paquetes en su sistema Debian GNU/Linux. Tendrá primero que volver a
montarlo con derechos de lectura y escritura, instalar los paquetes que desee y
finalmente volver a montarlo como de sólo-lectura. La última versión de
<package>apt</package> (en Debian 3.0 «woody») puede configurarse para ejecutar
órdenes antes y después de instalar paquetes, por tanto usted podría querer
configurarlo de forma correcta.
<p>Para hacer esto modifique <file>/etc/apt/apt.conf</file> y agregue:
<example>
DPkg
{
Pre-Invoke { "mount /usr -o remount,rw" };
Post-Invoke { "mount /usr -o remount,ro" };
};
</example>
<p>Observe que «Post-Invoke» puede fallar con un mensaje de error «/usr
busy». Esto pasa principalmente cuando usted esté usando archivos que resultaron
actualizados durante la actualización. Puede encontrar estos programas
ejecutando
<example>
# lsof +L1
</example>
<p>Detenga o reinicie estos programas y ejecute el «Post-Invoke» de forma
manual. <em>¡Cuidado!</em> Esto quiere decir que probablemente necesitará
reiniciar su sesión X (si está ejecutando una) cada vez que haga una
actualización importante de su sistema. Podría volver a considerar si un
directorio <file>/usr</file> de sólo-lectura es adecuado para su sistema. Vea
también esta <url
id="http://lists.debian.org/debian-devel/2001/11/threads.html#00212";
name="discusión en debian-devel sobre /usr de sólo-lectura">.
<sect>Proporcionar acceso de usuario seguro
<sect1>Autenticación de usuario: PAM
<p>PAM (N. del T., Pluggable Authentication Modules: módulos de autenticación
conectables) permite a los administradores del sistema elegir cómo las
aplicaciones autentican a los usuarios. Note que PAM no puede hacer nada a menos
que una aplicación haya sido compilada con soporte para PAM. La mayoría de las
aplicaciones suministradas con Debian 2.2 tienen este soporte
incorporado. Además, Debian no tenía soporte PAM antes de la versión 2.2. La
configuración predeterminada para cualquier servicio con PAM habilitado es
emular la autenticación de UNIX (para más información sobre cómo
<em>deberían</em> funcionar los servicios PAM en Debian lea
<file>/usr/share/doc/libpam0g/Debian-PAM-MiniPolicy.gz</file>).
<p>Cada aplicación con soporte PAM proporciona un archivo de configuración en
<file>/etc/pam.d/</file>, el cual puede utilizarse para modificar su
comportamiento:
<list>
<item>qué motor se utiliza para autenticación.
<item>qué motor se utiliza para las sesiones.
<item>cómo funciona la comprobación de contraseñas.
</list>
<p>
La siguiente descripción está lejos de ser completa, para mas información usted
podría querer leer la <url
id="http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html";
name="Guía del administrador de un sistema Linux-PAM"> (en el <url
id="http://www.kernel.org/pub/linux/libs/pam/"; name="sitio principal de
distribución de PAM">). Este documento también está disponible en el paquete
<package>libpam-doc</package> de Debian.
<p>PAM le ofrece la posibilidad de pasar de una vez por varios pasos de la
autenticación, sin que se entere el usuario. Usted podría autenticar contra una
base de datos de Berkeley y contra el archivo <file>passwd</file> normal, y el
usuario sólo accederá al sistema si se autentica de forma correcta en
ambos. Usted puede ser muy restrictivo con PAM, lo mismo que abrir muy
ampliamente las puertas de su sistema. Así que tenga cuidado. Una línea de
configuración típica tiene como segundo elemento un campo de control.
<!-- Second in mine (old Debian v2.0 though), check this! (ARRÉGLEME)
(era) --> Generalmente debe establecerse como <tt>requisite</tt>, el cual devuelve
un fallo de acceso si un módulo falla. <!-- Lots of
fields in mine are "required", please elaborate? (ARRÉGLEME) (era) -->
<p>Lo primero que me gusta hacer, es añadir soporte MD5 a las aplicaciones de
PAM, puesto que esto ayuda a proteger contra las invasiones de diccionario
(dictionary cracks) (las contraseñas pueden ser más largs si se utiliza
MD5). Las dos líneas siguientes deberían añadirse a todos los archivos en
<file>/etc/pam.d/</file> que otorguen acceso a la máquina, como
<tt>login</tt> y <tt>ssh</tt>.
<example>
# Asegúrese de instalar primero libpam-cracklib o no podrá iniciar una sesión
password required pam_cracklib.so retry=3 minlen=12 difok=3
password required pam_unix.so use_authtok nullok md5
</example>
<p>Entonces, ¿qué hace este conjuro? La primera línea carga el módulo cracklib
de PAM, el cual proporciona comprobación fuerte de contraseñas, cursores para
una nueva contraseña con una longitud mínima de 12 caracteres, una diferencia de
por lo menos 3 caracteres con la contraseña antigua, y permite 3
reintentos. Cracklib depende de un paquete de lista de palabras (como
<package>wenglish</package>, <package>wspanish</package>,
<package>wbritish</package>, ...), por tanto asegúrese de instalar uno apropiado
para su idioma o cracklib podría no serle útil en absoluto.
<footnote>
Esta dependencia no está arreglada, sin embargo, en el paquete de Debian
3.0. Por favor vea <url id="http://bugs.debian.org/112965"; name="Bug #112965">.
</footnote>
La segunda línea introduce el módulo de la autenticación estándar con las
contraseñas de MD5 y permite una contraseña de longitud cero. La directiva
use_authtok es necesaria para entregar la contraseña del módulo anterior.
<p>Para asegurarse de que el superusuario sólo puede acceder al sistema desde
terminales locales, se debería habilitar la siguiente línea en
<file>/etc/pam.d/login</file>:
<example>
auth requisite pam_securetty.so
</example>
<p>Entonces usted debería modificar la lista de terminales en los que está
permitido el acceso directo del superusuario, en
file>/etc/securetty</file>. Alternativamente, podría habilitar el módulo
<tt>pam_access</tt> y modificar <file>/etc/security/access.conf</file> que
permite un control de accesos más general y afinado, pero (desafortunadamente)
carece de mensajes de registro decentes (dentro de PAM los registros no están
estandarizados y es un problema particularmente ingrato tratar con
ellos). Volveremos a <file>access.conf</file> un poco más tarde.
Por último, pero no por eso menos importante, se debe habilitar la siguiente
línea en <file>/etc/pam.d/login</file> para configurar los límites de los
recursos de usuario.
<example>
session required pam_limits.so
</example>
<p>Esto restringe los recursos del sistema que se permiten a los
usuarios (vea más abajo en <ref id="user-limits">. Por ejemplo, usted podría
restringir el número de sesiones concurrentes (para un grupo determinado de
usuarios, o para todo el sistema) el número de procesos, el tamaño de memoria,
etc.
<p>Ahora edite <file>/etc/pam.d/passwd</file> y cambie la primera línea. Debería
añadir la opción «md5» para usar contraseñas de MD5, cambiar la longitud mínima
de las contraseñas de 4 a 6 (o más) y poner una longitud máxima, si lo desea. La
línea resultante será algo como:
<example>
password required pam_unix.so nullok obscure min=6 max=11 md5
</example>
<p>Si quiere proteger la orden <prgn>su</prgn>, para que sólo algunas personas
puedan usarla en su sistema para convertirse en superusuario, necesita añadir
un nuevo grupo «wheel» a su sistema (ésa es la manera más limpia, puesto que
ningún archivo tiene tal permiso de grupo todavía). Incluya en este grupo a
«root» y a los otros usuarios que deberían poder hacer <prgn>su</prgn> al
superusuario. Luego añada la línea siguiente en <file>/etc/pam.d/su</file>:
<example>
auth requisite pam_wheel.so group=wheel debug
</example>
<p>Esto asegura que sólo personas del grupo wheel pueden usar
<prgn>su</prgn> para convertirse en superusuario. Otros usuarios no podrán
hacerlo. De hecho ellos obtendrán un mensaje de denegación si intentan
convertirse en superusuarios.
<p>Si usted quiere que sólo ciertos usuarios autentiquen a un servicio
de PAM, esto es bastante fácil de lograr usando archivos en los que se almacenen
los usuarios que están autorizados a acceder (o no). Imagine que únicamente
quiere permitir el acceso via <prgn>ssh</prgn> al usuario «ref». Por tanto lo
pone en <file>/etc/sshusers-allowed</file> y escribe lo siguiente en
<file>/etc/pam.d/ssh</file>:
<example>
auth required pam_listfile.so item=user sense=allow file=/etc/sshusers-allowed onerr=fail
</example>
<p>Por último, pero no menos importante, cree <file>/etc/pam.d/other</file> e
introduzca las líneas siguientes:
<example>
auth required pam_securetty.so
auth required pam_unix_auth.so
auth required pam_warn.so
auth required pam_deny.so
account required pam_unix_acct.so
account required pam_warn.so
account required pam_deny.so
password required pam_unix_passwd.so
password required pam_warn.so
password required pam_deny.so
session required pam_unix_session.so
session required pam_warn.so
session required pam_deny.so
</example>
<p>Estas líneas proporcionarán una buena configuración por omisión para todas
las aplicaciones que soporten PAM (por omisión se deniega el acceso).
<sect1 id="user-limits">Limitar el uso de recursos: el archivo
<file>limits.conf</file>
<p>Debería echar un vistazo serio al interior de este archivo. Aquí puede
definir los límites de los recursos de usuario. En versiones antiguas este
archivo de configuración era <file>/etc/limits.conf</file>, pero en versiones
más actuales (con PAM) se debería usar en su lugar el archivo de configuración
<file>/etc/security/limits.conf</file>.
<p>Si usted no restringe el uso de los recursos, cualquier usuario con un
intérprete de órdenes válido en su sistema (o incluso un intruso que
comprometió el sistema por medio de un servicio o un demonio torcido)
puede consumir toda la CPU, memoria, pila, etc. que el sistema pueda
proporcionar. Este problema de <em>agotamiento de recursos</em> puede corregirse
utilizando PAM.
<p>Hay una forma de añadir límites a los recursos para algún intérprete de
órdenes (por ejemplo, <prgn>bash</prgn> tiene <prgn>ulimit</prgn>, vea <manref section="1"
name="bash">), pero puesto que no todos proporcionan los mismos límites y puesto
que el usuario puede cambiar de intérprete de órdenes (vea <manref section="1"
name="chsh">) es mejor situar los límites en los módulos de PAM, pues de esta
forma se aplicarán independientemente del intérprete de órdenes utilizado y
también se aplicarán a los módulos de PAM no orientados a intérpretes de
órdenes.
<p>Los límites de los recursos son impuestos por el núcleo, pero es necesaria su
configuración por medio del archivo <file>limits.conf</file> y la configuración
PAM de los diferentes servicios necesarios para la carga del PAM
apropiado. Puede comprobar qué servicios están haciendo cumplir límites ejecutando:
<example>
$ find /etc/pam.d/ \! -name "*.dpkg*" | xargs -- grep limits |grep -v ":#"
</example>
<P>Comúnmente, <file>login</file>, <file>ssh</file> y los gestores de sesiones
gráficas (<file>gdm</file>, <file>kdm</file> o <file>xdm</file>) deberían hacer
cumplir límites de usuario, pero usted podría querer hacer esto en otros
archivos de configuración de PAM, tal como <file>cron</file>, para evitar que
los demonios del sistema controlen todos los recursos.
<p>La configuración de límites específicos que usted podría querer hacer cumplir
depende de los recursos de su sistema, esa es una de las razones principales por
las que no se hacen cumplir límites en la instalación predeterminada.</p>
<p>Por ejemplo, en la configuración de más abajo se hace cumplir un límite de
100 procesos para todos los usuarios (para evitar bombas de desdoblamiento de
procesos: <em>fork bombs</em>) además se establecen un límite de 10 MB de memoria
por proceso y un límite de 10 inicios de sesiones simultáneos. Los usuarios del
grupo <tt>adm</tt> tienen límites superiores y pueden producir archivos de
volcado de memoria (archivos «core») si así lo desean (hay únicamente un límite
<em>soft</em>).
<p>
<example>
* soft core 0
* hard core 0
* hard rss 1000
* hard memlock 1000
* hard nproc 100
* - maxlogins 1
* hard data 102400
* hard fsize 2048
@adm hard core 100000
@adm hard rss 100000
@adm soft nproc 2000
@adm hard nproc 3000
@adm hard fsize 100000
@adm - maxlogins 10
</example>
<p>Estos serían los límites que tendría un usuario predeterminado (incluyendo
demonios del sistema):
<example>
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) 102400
file size (blocks, -f) 2048
max locked memory (kbytes, -l) 10000
max memory size (kbytes, -m) 10000
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 100
virtual memory (kbytes, -v) unlimited
</example>
<p>Y estos son los límites para un administrador:
<example>
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) 102400
file size (blocks, -f) 100000
max locked memory (kbytes, -l) 100000
max memory size (kbytes, -m) 100000
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 2000
virtual memory (kbytes, -v) unlimited
</example>
<p>Para más información lea:
<list>
<item><url
id="http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam-6.html";
name="Guía de referencia de PAM para módulos disponibles">.
<item><url
id="http://www.samag.com/documents/s=1161/sam0009a/0009a.htm";
name="Artículo de configuración de PAM">.
<item> <url
id="http://seifried.org/security/os/linux/20020324-securing-linux-step-by-step.html";
name="Proteger Linux paso a paso de Seifried"> en la sección <em>Visión general
sobre cómo limitar a los usuarios</em>.
<item><url id="http://seifried.org/lasg/users/"; name="LASG"> en la sección
<em>Limitar y supervisar a los usuarios</em>.
</list>
<sect1>Acciones del inicio de sesión de usuario: editar <file>/etc/login.defs</file>
<p>
El siguiente paso es editar la configuración básica y las acciones al iniciar sesión
de usuario. Observe que este archivo no es parte de la configuración de PAM; es
un archivo de configuración respetado por los programas <tt>login</tt> y
<tt>su</tt>, por ello no tiene sentido ajustarlo para casos en los que ninguno
de los dos programas sea llamado ni siquiera indirectamente (el programa
<prgn>getty</prgn> que forma parte de las consolas y ofrece el cursor de acceso
inicial, invoca al programa <prgn>login</prgn>
<example>
FAIL_DELAY 10
</example>
<p>Esta variable debería establecerse a un valor más alto para hacer más difícil
utilizar el terminal para acceder al sistema utilizando la fuerza bruta. Si se
teclea una contraseña incorrecta, el posible atacante (¡o el usuario normal!)
tiene que esperar 10 segundos hasta que pueda realizar un nuevo intento, lo que
es bastante tiempo cuando usted prueba contraseñas. Preste atención al hecho de
que esta configuración es inútil si se utiliza un programa distinto de
<prgn>getty</prgn>, tal como <prgn>mingetty</prgn> por ejemplo.
<example>
FAILLOG_ENAB yes
</example>
<p>Si usted habilita esta variable, los intentos de acceso fallidos quedarán
registrados. Es importante seguirles la pista para atrapar a quien intente un
ataque por fuerza bruta.
<example>
LOG_UNKFAIL_ENAB yes
</example>
<p>Si estableció la variable <var>FAILLOG_ENAB</var> a «yes», entonces también
debería establecer a «yes» esta variable. Esto registrará los nombres de usuario
desconocidos si falla el acceso. Si hace esto, asegúrese de que los registros
(N. del T., logs en inglés) tienen los permisos apropiados (640 por ejemplo, con
un grupo apropiado como adm), porque los usuarios introducen a menudo
accidentalmente sus contraseñas como el nombre de usuario y usted no quiere que
otros las vean.
<example>
SYSLOG_SU_ENAB yes
</example>
<p>Esto habilita el registro de intentos de <prgn>su</prgn> en el archivo
<file>syslog</file>. Bastante importante en máquinas serias, pero observe que
esto puede crear también cuestiones de privacidad.
<example>
SYSLOG_SG_ENAB yes
</example>
<p>Lo mismo que <var>SYSLOG_SU_ENAB</var> pero aplicado al programa
<prgn>sg</prgn>.
<example>
MD5_CRYPT_ENAB yes
</example>
<p>Como se estableció más arriba, las contraseñas MD5 reducen grandemente el
problema de los ataques de diccionario, puesto que pueden utilizar contraseñas
más largas. Si está utilizando slink, lea los documentos sobre MD5 antes de
habilitar esta opción. Aparte de eso, esto se configura en PAM.
<example>
PASS_MAX_LEN 50
</example>
<p>Si están activadas las contraseñas MD5 en su configuración de PAM, entonces
esta variable debería ponerse al mismo valor utilizado allí.
<sect1>Restringir ftp: editar <file>/etc/ftpusers</file>
<p>
El archivo <file>/etc/ftpusers</file> contiene una lista de usuarios que no
están autorizados a acceder a la máquina anfitriona mediante ftp. Utilice este
archivo únicamente si realmente quiere permitir ftp (lo que en general no es
recomendable, puesto que utiliza contraseñas en texto plano). Si su demonio
soporta PAM, puede usar eso para permitir y denegar usuarios para ciertos
servicios.
<p>ARRÉGLEME (ERROR): Es un error que el <file>ftpusers</file> predeterminado
en Debian <em>no</em> incluya todos los usuarios administradores (en
<package>base-passwd</package>).
<sect1>Utilizar su
<p>
Si usted necesita realmente que usuarios adquieran privilegios de superusuario
en su sistema, por ejemplo para instalar paquetes o añadir usuarios, puede
utilizar la orden <prgn>su</prgn> para cambiar su identidad. Debería evitar
cualquier acceso al sistema como superusuario y en su lugar utilizar
<prgn>su</prgn>. Realmente, la mejor solución es eliminar <prgn>su</prgn> y
cambiar al mecanismo de <prgn>sudo</prgn>, el cual tiene una lógica más amplia y
más características que <prgn>su</prgn>. Sin embargo, <prgn>su</prgn> es más
común ya que se usa en otros Unix.
<sect1>Utilizar sudo
<p>
<prgn>sudo</prgn> permite al usuario ejecutar órdenes bajo la identidad de otro
usuario, incluso como superusuario. Si el usuario es añadido a
<file>/etc/sudoers</file> y se autentifica correctamente, podrá ejecutar órdenes
que hayan sido definidas en <file>/etc/sudoers</file>. Las violaciones, tales
como contraseñas incorrectas o intentos de ejecutar un programa para el que no
se tiene permiso, quedan registrados y son enviados por correo al superusuario.
<sect1>Rechazar el acceso remoto de administradores
<p>Debería modificar también <file>/etc/security/access.conf</file> para
rechazar el acceso remoto a las cuentas de administradores del sistema. De esta
forma los usuarios necesitarán invocar a <prgn>su</prgn> (o <prgn>sudo</prgn>)
para tener poderes administrativos y siempre se generarán la apropiadas señales
de auditoría.
<p>Necesita añadir la siguiente línea a <file>/etc/security/access.conf</file>,
el archivo de configuración de Debian tiene una línea de muestra comentada:
<example>
-:wheel:ALL EXCEPT LOCAL
</example>
<p>Recuerde habilitar el módulo <tt>pam_access</tt> para cada servicio (o
configuración predeterminada) en <file>/etc/pam.d/</file> si quiere que sus
cambios en <file>/etc/security/access.conf</file> sean respetados.
<sect1 id="user-restrict">Restringir el acceso de usuarios
<p>Algunas veces podría pensar que necesita tener creados usuarios en su sistema
local para proporcionar un servicio dado (pop3 mail service o ftp). Antes de
hacer eso, recuerde primero que la implementación de PAM en Debian GNU/Linux le
permite validar usuarios con una amplia variedad de servicios de directorio
externos (radius, ldap, etc.) proporcionados por los paquetes de libpam.
<p>Si los usuarios necesitan ser creados y se puede acceder al sistema de forma
remota tenga en cuenta que los usuarios podrán acceder al sistema. Puede
corregir esto dando a esos usuarios un intérprete de órdenes de tipo null
(<file>/dev/null</file>)(necesitará ésta estar en la lista de
<file>/etc/shells</file>). Si quiere permitir a los usuarios el acceso al
sistema, pero limitar sus movimientos, puede utilizar <file>/bin/rbash</file>,
equivalente a añadir la opción <tt>-r</tt> en <prgn>bash</prgn> (<em>SHELL
RESTRINGIDA</em> vea <manref name="bash" section="1">). Por favor, observe que
incluso con el intérprete de órdenes restringido, un usuario que accede a un
programa interactivo (que podría permitir la ejecución de un subintérprete)
podría ser capaz de eludir las limitaciones del intérprete de órdenes.
<p>Debian proporciona actualmente en la versión «inestable» (y podría ser
incluido en las próximas versiones «estables») el módulo <file>pam_chroot</file>
(en el paquete <package>libpam-chroot</package>). Una alternativa es hacer
<prgn>chroot</prgn> al servicio que proporciona acceso remoto (<prgn>ssh</prgn>,
<prgn>telnet</prgn>).
<footnote><package>libpam-chroot</package> no ha sido aún probado
concienzudamente, funciona para <prgn>login</prgn> pero el entorno podría no ser
fácil de configurar para otros programas</footnote>
<p>Si desea restringir <em>cuándo</em> pueden los usuarios acceder al sistema,
tendrá que personalizar <file>/etc/security/access.conf</file> de acuerdo a sus
necesidades.
<p>En <ref id="chroot-ssh-env"> se describe cómo hacer <prgn>chroot</prgn> a
usuarios que acceden al sistema a través del servicio <prgn>ssh</prgn>.
<sect1>Auditar usuarios
<p>Si está verdaderamente paranoico podría querer añadir una configuración de
todo el sistema para auditar qué están haciendo los usuarios en su
sistema. Estas secciones presentan algunos consejos en el uso de distintas
utilidades que usted puede emplear.
<sect2>Auditoría de entrada y salida con «script»
<P>Puede utilizar la orden <prgn>script</prgn> para auditar tanto lo que los
usuarios ejecutan como los resultados de la ejecución. No puede configurar
<prgn>script</prgn> con un intérprete de órdenes (ni siquiera si lo añade a
<file>/etc/shells</file>). Pero puede tener el archivo de inicialización del
intérprete de órdenes ejecutando lo siguiente:
<example>
umask 077
exec script -q -a "/var/log/sessions/$USER"
</example>
<p>Por supuesto, si usted hace esto para todo el sistema significará que el
intérprete de órdenes ya no leería los archivos de inicialización personales
(puesto que el intérprete queda sobreescrito por <prgn>script</prgn>). Una
alternativa es hacer esto en los archivos de inicialización de los usuarios
(pero entonces el usuario podría eliminarlo, vea más abajo los comentarios sobre
esto)</p>
<p>También necesita configurar los archivos del directorio de auditoría (en el
ejemplo <file>/var/log/sessions/</file>) de forma que los usuarios puedan
escribir en el archivo pero no eliminarlo. Esto puede hacerse, por ejemplo,
creando por adelantado los archivos de sesión de los usuarios y configurarlos
con el indicador <em>append-only</em> mediante el uso <prgn>chattr</prgn>.
</p>
<p>Una alternativa útil para administradores del sistema, que incluye
información de fecha podría ser:
<example>
umask 077
exec script -q -a "/var/log/sessions/$USER-`date +%Y%m%d`"
</example>
<sect2>Utilizar el archivo de historial del intérprete de órdenes
<p>Si quiere revisar lo que escribió el usuario en el intérprete de órdenes
(pero no cuál fue el resultado) puede establecer un <file>/etc/profile</file>
para todo el sistema que configure el entorno de forma que todas las órdenes se
guarden en un archivo de historial. La configuración para todo el sistema
necesita establecerse de tal forma que los usuarios no puedan eliminar las
capacidades de auditoría del intérprete de órdenes. Esto es algo específico del
intérprete, por ello asegúrese de que todos los usuarios estén utilizando uno
que soporte esto.</p>
<p>Por ejemplo, para bash el archivo <file>/etc/profile</file> podría
establecerse como sigue
<footnote>
Establecer HISTSIZE a un número muy grande puede causar problemas en algunos
intérpretes de órdenes puesto que el historial se mantiene en memoria para cada
sesión de usuario. Podría estar más seguro si lo establece a un valor
suficientemente alto y hace una copia de seguridad de los archivos del historial
de los usuarios (si por alguna razón necesita todos los historiales de los
usuarios) </footnote>
<example>
HISTFILE=~/.bash_history
HISTSIZE=10000
HISTFILESIZE=999999
# Don't let the users enter commands that are ignored
# in the history file
HISTIGNORE=""
HISTCONTROL=""
readonly HISTFILE
readonly HISTSIZE
readonly HISTFILESIZE
readonly HISTIGNORE
readonly HISTCONTROL
export HISTFILE HISTSIZE HISTFILESIZE HISTIGNORE HISTCONTROL
</example>
<p>Para que esto funcione, el usuario únicamente puede añadir información al
archivo <file>.bash_history</file>. Usted necesita <em>también</em> establecer
la opción <em>append-only</em> para <file>.bash_history</file> para todos los
usuarios, utilizando el programa <prgn>chattr</prgn> .
<footnote>
Sin el indicador «append-only» los usuarios podrían vaciar los contenidos del
archivo de historial ejecutando <tt> > .bash_history</tt>
</footnote>.
<p>Observe que usted podría introducir la configuración anterior en el archivo
<file>.profile</file> del usuario. Pero entonces necesitaría configurar
adecuadamente los permisos de tal forma que evite que el usuario pueda modificar
este archivo. Esto incluye: que los directorios del usuario en «home» <em>no</em>
pertenezcan al usuario (puesto que de otra forma podría eliminar el archivo)
pero al mismo tiempo habilitarles para la lectura del archivo de configuración
<file>.profile</file> y para la escritura en el archivo
<file>.bash_history</file>. Sería bueno además establecer el indicador
<em>immutable</em> (utilizando también <prgn>chattr</prgn>) para el archivo
<file>.profile</file>, si lo hace de esta forma.
<sect2>Completar la auditoría de usuarios con utilidades de contabilidad
<p>El ejemplo anterior es una forma simple de configurar la auditoría de
usuarios, pero podría no ser útil para sistemas complejos o para aquellos en los
que los usuarios no ejecutan intérpretes de órdenes para nada (o
exclusivamente). Si este es su caso, necesita mirar en <package>acct</package>,
las utilidades de contabilidad. Estas utilidades registrarán todas las órdenes
ejecutadas en el sistema por los usuarios o los procesos, a costa de espacio de
disco.
<p>Cuando se activa la contabilidad, toda la información sobre procesos y
usuarios se mantiene bajo <file>/var/account/</file>, más específicamente en
<file>pacct</file>. El paquete de contabilidad incluye algunas herramientas
(<prgn>sa</prgn>, <prgn>ac</prgn> y <prgn>lastcomm</prgn>) para analizar estos
datos.
<sect2>Otros métodos de auditar usuarios
<p>Si usted está completamente paranoico y quiere auditar cada instrucción de
usuario, podría tomar el código fuente de <prgn>bash</prgn>, editarlo y hacerle
enviar a otro archivo todo lo que el usuario escriba. O tener a
<package>ttysnoop</package> supervisando constantemente cualquier nuevo terminal
(tty)
<footnote>Los terminales son iniciados para acceso local y acceso remoto a
través de ssh y telnet</footnote>
y vuelcan la salida en un archivo. Otro útil programa es
<package>snoopy</package>
(vea también <url id="http://sourceforge.net/projects/snoopylogger/"; name="la
página del proyecto">)
que es un programa transparente al usuario que enlaza como una biblioteca
proporcionando un envoltorio alrededor de las llamadas de <var>execve()</var>,
cualquier instrucción ejecutada es registrada en <prgn>syslogd</prgn> utilizando
las facilidades de <tt>authpriv</tt> (normalmente almacenado en
<file>/var/log/auth.log</file>).
<sect1>Revisar perfiles de usuario
<p>Si quiere <em>ver</em> lo que los usuarios están realmente haciendo cuando
acceden al sistema, puede utilizar la base de datos de <file>wtmp</file> que
incluye toda la información de los accesos. Este archivo puede procesarse con
varias utilidades, entre ellas <prgn>sac</prgn> que puede devolver un perfil de
cada usuario, mostrando en qué marco de tiempo acceden normalmente al sistema.
<p>En caso de que tenga la contabilidad activada, usted puede también utilizar
las herramientas proporcionadas por ella, para determinar cuándo acceden los
usuarios al sistema y qué ejecutan.
<sect1>Configurar «umasks» de usuarios
<p>Dependiendo de las directrices de su sistema, usted podría querer cambiar
cómo se comparte la información entre usuarios, esto es, cuáles son los permisos
predeterminados para los nuevos archivos creados por los usuarios. Este cambio
se realiza mediante la configuración apropiada de <tt>umask</tt> para todos los
usuarios. Puede cambiar la configuración de <var>UMASK</var> en
<file>/etc/limits.conf</file>, <file>/etc/profile</file>,
<file>/etc/csh.cshrc</file>, <file>/etc/csh.login</file>,
<file>/etc/zshrc</file> y probablemente algunos otros (dependiendo de los
intérpretes de órdenes que tenga instalados en su sistema). De todas estas, el
último cargado toma la precedencia. El orden es <file>limits.conf</file> de PAM,
la configuración del sistema predeterminada para el intérprete de órdenes de
usuario, el intérprete de órdenes de usuario (sus <file>~/.profile</file>,
<file>~/.bash_profile</file>...)
<p>La configuración de <tt>umask</tt> predeterminada de Debian es
<em>022</em>. Esto significa que los archivos (y directorios) pueden ser leídos
y accedidos por el grupo del usuario y por cualquier otro usuario del
sistema. Si esto es demasiado permisivo para su sistema tendrá que cambiar la
configuración de <tt>umask</tt> para todos los intérpretes de órdenes (y para
PAM). No olvide modificar los archivos bajo <file>/etc/skel/</file> puesto que
estos serán los nuevos parámetros por omisión de los usuarios cuando estos se
crean con la orden <prgn>adduser</prgn>.
<p>Observe, sin embargo que los usuarios pueden modificar sus propias
configuraciones de <tt>umask</tt> si ellos quieren, haciéndolo más permisivo o
más restrictivo.
<sect1>Limitar lo que los usuarios pueden ver/acceder
<P>ARRÉGLEME: necesita contenido. Contar las consecuencias de cambiar los
permisos de los paquetes cuando se actualicen (por cierto, cualquier
administrador tan paranoico debería encerrar a sus usuarios en un entorno
<prgn>chroot</prgn>).
<p>Si necesita garantizar el acceso de usuarios al sistema con un intérprete de
órdenes, piense en ello muy detenidamente. Un usuario puede, por omisión al
menos, en un entorno severamente restringido (como una jaula de <tt>chroot</tt>),
recuperar bastante información de su sistema, incluyendo:
<list>
<item>algunos archivos de configuración de <file>/etc</file>. Sin embargo, los
permisos predeterminados en Debian para algunos archivos sensibles (que podrían,
por ejemplo, contener contraseñas), evitarán el acceso a información
crítica. Para ver qué archivos son accesibles únicamente como superusuario
ejecute, por ejemplo, como superusuario <tt>find /etc -type f -a -perm 600 -a
-uid 0</tt>
<item>sus paquetes instalados, bien mirando en la base de datos de paquetes, en
el directorio <file>/usr/share/doc</file> o adivinándolo tras mirar los archivos
binarios y bibliotecas instaladas en su sistema.
<item>algunos archivos de registro en <file>/var/log</file>. Observe también que
algunos archivos de registro únicamente son accesibles para el superusuario y el
grupo <tt>adm</tt> (pruebe <tt>find /var/log -type f -a -perm 640</tt>) y algunos
incluso sólo están disponibles para el superusuario (pruebe <tt>find /var/log
-type f -a -perm 600 -a -uid 0</tt>).
</list>
<p>¿Qué puede ver un usuario en su sistema? Probablemente bastantes cosas,
pruebe esto (respire hondo):
<example>
find / -type f -a -perm +006 2>/dev/null
find / -type d -a -perm +007 2>/dev/null
</example>
<p>La salida es la lista de archivos que un usuario puede <em>ver</em> y los
directorios a los que tiene acceso.
<sect2 id="limit-user-perm">Limitar el acceso a la información de otros usuarios
<p>Si usted todavía concede a los usuarios acceso al intérprete de órdenes,
podría querer limitar la información que pueden ver de otros usuarios. Los
usuarios con acceso al intérprete de órdenes tienen tendencia a crear un número
considerable de archivos bajo sus directorios $HOME: buzones de correo,
documentos personales, configuración de aplicaciones de X/GNOME/KDE, ...
<p>En Debian, cada usuario se crea con un grupo asociado, y dos usuarios no
pertenecen al mismo grupo. Este es el comportamiento predeterminado: cuando se
crea una cuenta de usuario, se crea también un grupo con el mismo nombre, y el
usuario se asigna a dicho grupo. Esto evita el concepto de un grupo de
<em>usuarios</em> común, lo que podría hacer que los usuarios tuvieran más
difícil ocultar información a otros usuarios.
<p>Sin embargo, los directorios <var>$HOME</var> de los usuarios se crean con
los permisos 0755 (legibles por el grupo y legibles por todo el mundo). Los
permisos del grupo no son problema pues únicamente el usuario pertenece al
grupo, sin embargo los permisos de todo el mundo podrían (o no) ser un problema
dependiendo de sus directrices locales.
<p>Usted puede cambiar este comportamiento para que la creación de usuarios
suministre unos permisos diferentes para <var>$HOME</var>. Para cambiar el
comportamiento para <em>nuevos</em> usuarios cuando estos sean creados, cambie
<em>DIR_MODE</em> en el archivo de configuración <file>/etc/adduser.conf</file>,
estableciéndolo a 0750 (sin permitir el acceso para todo el mundo).
<p>Los usuarios pueden todavía compartir información, pero no directamente en
sus directorios <var>$HOME</var>, al menos que cambien sus permisos.
<p>Observe que deshabilitando «legible para todo el mundo» en los directorios
«home» evitará que los usuarios creen sus páginas web personales en el
directorio <file>~/public_html</file>, puesto que el servidor de web no podrá
leer un componente de la ruta (path) - concretamente su directorio
<var>$HOME</var>. Si usted quiere permitir a los usuarios publicar páginas HTML
en su <file>~/public_html</file>, entonces cambie <em>DIR_MODE</em> a 0751. Esto
permitirá al servidor web acceder al directorio final <file>public_html</file>
(que debería tener el modo 0755) y proporcionar el contenido publicado por los
usuarios. Por supuesto, aquí estamos hablando únicamente sobre una configuración
predeterminada; los usuarios pueden generalmente ajustar los modos de sus
propios archivos completamente a su gusto, o usted podría mantener el contenido
deseado para la web en una ubicación separada que no sea un subdirectorio de un
directorio <var>$HOME</var> de usuario.
<sect1 id="user-pwgen">Generar contraseñas de usuario
<p>Hay muchos casos en los que un administrador necesita crear muchas
cuentas de usuario y proporcionar contraseñas para todas ellas. Por supuesto, el
administrador podría fácilmente limitarse a poner como contraseña el nombre de
la cuenta de usuario, pero eso no sería muy sensato desde el punto de vista de
la seguridad. Un mejor enfoque es utilizar un programa generador de
contraseñas. Debian proporciona los paquetes <package>makepasswd</package>,
<package>apg</package> y <package>pwgen</package>, los cuales proporcionan
programas (el nombre es el mismo que el del paquete) que pueden utilizarse con
este propósito. <prgn>Makepasswd</prgn> generará contraseñas verdaderamente
aleatorias con énfasis en la seguridad a costa de la pronunciabilidad mientras
que <prgn>pwgen</prgn> intentará construir contraseñas sin sentido pero
pronunciables (por supuesto que esto podría depender de su lengua
materna). <prgn>Apg</prgn> tiene algoritmos para mantener ambos (hay una versión
cliente/servidor para este programa pero no está incluida en el paquete de
Debian).
<p><prgn>Passwd</prgn> no permite la asignación no interactiva de contraseñas
(puesto que usa acceso directo a terminal). Si usted quiere cambiar las
contraseñas al crear un gran número de usuarios, puede crearlas utilizando
<prgn>adduser</prgn> con la opción <tt>--disabled-login</tt> y luego usar
<prgn>usermod</prgn> o <prgn>chpasswd</prgn>
<footnote>
<prgn>Chpasswd</prgn> no puede manejar la generación de contraseñas MD5 por ello
necesita que se le dé la contraseña de forma cifrada antes de usarlo, con la
opción <tt>-e</tt>.
</footnote>
(ambos del paquete <package>passwd</package> y por tanto ya los tiene
instalados). Si usted quiere usar un archivo con toda la información para crear
los usuarios con un proceso por lotes, podría ser mejor utilizar
<prgn>newusers</prgn>.
<sect1>Comprobar contraseñas de usuario
<p>Las contraseñas de usuario pueden algunas veces convertirse en el <em>punto
más débil</em> en la seguridad de un sistema dado. Esto es debido a que algunos
usuarios eligen contraseñas débiles para sus cuentas (y mientras más haya,
mayores posibilidades habrá de que esto ocurra). Incluso si usted establece
comprobaciones con el módulo «cracklib» de PAM y límites de contraseñas como se
describe en <ref id="auth-pam"> los usuarios podrán todavía usar contraseñas
débiles. Puesto que el acceso de un usuario podría incluir acceso remoto al
intérprete de órdenes (sobre <prgn>ssh</prgn>, con un poco de suerte) es
importante hacer que las contraseñas sean tan difíciles de adivinar, por parte
de los atacantes remotos, como sea posible, especialmente si fueran capaces de
alguna forma de obtener información importante tal como los nombres de usuarios
o incluso los mismos archivos <file>passwd</file> y <file>shadow</file>.
<p>Un administrador de sistema tiene que, dado un número grande de usuarios,
comprobar si las contraseñas que estos tienen son consistentes con las
directrices de seguridad local. ¿Cómo comprobarlo? Pruebe a invadirlos como lo
haría un atacante si tuviera acceso a las contraseñas de tipo «hash» (el archivo
<file>/etc/shadow</file>).
<p>Un administrador puede usar <package>john</package> o
<package>crack</package> (ambos son «crackers» de contraseña por fuerza bruta)
junto con una lista de palabras apropiada para comprobar las contraseñas de los
usuarios y tomar las acciones oportunas cuando se detecte una contraseña débil.
Puede buscar paquetes para Debian GNU que contengan listas de palabras usando
<prgn>apt-cache search wordlist</prgn>, o visitar en Internet los sitios
clásicos de listas de palabras tales como
<url id="ftp://ftp.ox.ac.uk/pub/wordlists";> o
<url id="ftp://ftp.cerias.purdue.edu/pub/dict";>.
<sect1 id="idle-logoff">Finalizar la conexión de usuarios inactivos
<p>Los usuarios inactivos son normalmente un problema de seguridad. Un usuario
podría estar inactivo quizás porque ha salido a comer, o porque una conexión
remota se «colgó» y no se ha restablecido. Sea la razón que sea, los usuarios
inactivos podrían comprometer al sistema:
<list>
<item>porque la consola del usuario podría ser desbloqueada y dar acceso a un
intruso.
<item>porque un atacante podría ser capaz de volverse a anexionar una conexión
de red cerrada y enviar órdenes al intérprete remoto (esto es bastante fácil si
el intérprete de órdenes remoto no está cifrado, como ocurre en el caso de
<prgn>telnet</prgn>).
</list>
<p>Algunos sistemas remotos se han comprometido incluso a través de un
<prgn>screen</prgn> inactivo (y distante).
<p>La desconexión automática de usuarios inactivos es normalmente una parte de
las directrices de seguridad local que tiene que imponerse. Hay varias formas
de hacerlo:
<list>
<item>Si el intérprete de órdenes de usuario es <prgn>bash</prgn>, un
administrador del sistema puede establecer un valor por omisión para
<tt>TMOUT</tt> (vea <manref section="1" name="bash">) que hará que el intérprete
finalice automáticamente las sesiones de usuarios inactivos remotos. Observe que
tiene que ponerlo con la opción <tt>-o</tt> o los usuarios podrán cambiarlo (o
quitarlo).
<item>Instale <package>timeoutd</package> y configure <file>/etc/timeouts</file>
de acuerdo con sus directrices de seguridad local. El demonio mirará si hay
usuarios inactivos y, de haberlos, interrumpirá convenientemente sus intérpretes
de órdenes.
<!-- ARRÉGLEME : evita «screen» que timeoutd detecte tiempos inactivos como yo
pienso que lo hace, o era debido a mis trucos con ttysnoop -->
<item>Instale <package>autolog</package> y configúrelo para eliminar usuarios
inactivos.
</list>
<p>Los demonios de <prgn>timeoutd</prgn> o <prgn>autolog</prgn> son los métodos
preferidos puesto que, después de todo, los usuarios pueden cambiar su
intérprete de órdenes predeterminado o pueden, después de ejecutar su intérprete
predeterminado, cambiar a otro distinto (incontrolado).
<sect id="tcpwrappers">Utilizar «tcpwrappers»
<p>Las «tcpwrappers» fueron desarrolladas cuando no se disponía de un filtrado
real de paquetes y se necesitaba control de acceso. Sin embargo, todavía son muy
interesantes y útiles. Las «tcpwrappers» le permiten autorizar o denegar un
servicio para un ordenador de la red o un dominio y definen una regla por
omisión de autorización o denegación (todo llevado a cabo en el nivel de la
aplicación). Si quiere más información eche un vistazo a <manref
name="hosts_access" section="5">.
<p>Muchos servicios instalados en Debian son:
<list>
<item>o bien, lanzados por medio del servicio (<file>tcpd</file>) de «tcpwrapper»
<item>o bien, compilados con soporte de «libwrapper» incorporado.
</list>
<p>Por otro lado, para servicios configurados en <file>/etc/inetd.conf</file>
(entre ellos se incluyen <prgn>telnet</prgn>, <prgn>ftp</prgn>,
<prgn>netbios</prgn>, <prgn>swat</prgn> y <prgn>finger</prgn>) verá que el
archivo de configuración ejecuta primero <prgn>/usr/sbin/tcpd</prgn>. Por otro
lado, incluso si un servicio no ha sido lanzado por el superdemonio
<prgn>inetd</prgn>, el soporte para las reglas de las «tcpwrappers» puede
compilarse con él. Entre los servicios de Debian compilados con «tcpwrappers» se
incluyen <prgn>ssh</prgn>, <prgn>portmap</prgn>, <prgn>in.talk</prgn>,
<prgn>rpc.statd</prgn>, <prgn>rpc.mountd</prgn>, <prgn>gdm</prgn>,
<prgn>oaf</prgn> (el demonio activador de GNOME), <prgn>nessus</prgn> y muchos
otros.
<p>Para ver qué paquetes utilizan «tcpwrappers» pruebe:
<example>
$ apt-cache showpkg libwrap0 | egrep '^[[:space:]]' | sort -u | \
sed 's/,libwrap0$//;s/^[[:space:]]\+//'
</example>
<p>Tenga esto en cuenta cuando ejecute <prgn>tcpdchk</prgn> (una regla muy útil
para el archivo de configuración de «tcpwrapper» y comprobador de
sintaxis). Cuando añada servicios autónomos (que enlacen directamente con la
biblioteca de «wrapper») en los archivos <file>hosts.deny</file> y
<file>hosts.allow</file>, <prgn>tcpdchk</prgn> le avisará de que no es capaz de
encontrar los mencionados servicios puesto que sólo los buscará en
<file>/etc/inetd.conf</file> (la página del manual no es completamente exacta en
este punto).
<p>Ahora viene un pequeño truco, y probablemente el más pequeño sistema de
detección de intrusos posible. En general, usted debería tener, en primera
línea, unas directrices de cortafuegos decentes, y «tcpwrappers» como la segunda
línea de defensa. Un pequeño truco es configurar una orden <var>SPAWN</var>
<footnote>asegúrese de utilizar mayúsculas aquí, puesto que <em>spawn</em> no
funcionará</footnote> en <file>/etc/hosts.deny</file> que envíe un correo al
superusuario siempre que las «wrappers» provoquen una denegación de servicio:
<example>
ALL: ALL: SPAWN ( \
echo -e "\n\
TCP Wrappers\: Connection refused\n\
By\: $(uname -n)\n\
Process\: %d (pid %p)\n\
User\: %u\n\
Host\: %c\n\
Date\: $(date)\n\
" | /usr/bin/mail -s "Connection to %d blocked" root) &
</example>
<p><em>¡Cuidado!</em>: El ejemplo escrito arriba está abierto a ataques de DoS,
mediante muchas conexiones en un corto periodo de tiempo. Muchos correos
significan un montón de operaciones de E/S en archivos, enviando sólo unos pocos
de paquetes.
<!--
# Could this example be more interesting?
# It also relates to the next section (jfs)
#
# era: cf hosts_access(5) manual page,
# and why are you not using logger(1) here? (FIXME?)
#
#<example>
#ALL: ALL: SPAWN ( \
# /usr/local/sbin/send_syslog %u %c %d )
#<example>
# With send_syslog as:
##!/usr/bin/perl -w
#
#use Sys::Syslog qw(:DEFAULT setlogsock);
#
#$user=shift(@ARGV) || 'unknown';
#$host=shift(@ARGV) || 'unknown';
#$service=shift(@ARGV) || 'unknown';
#setlogsock('unix');
#openlog("alert",'', 'user');
#syslog('warning', 'Connection from %s at %s to %s blocked.', ($user, $host, $service) );
#closelog();
#
#exit 0;
-->
<sect id="log-alerts">La importancia de registros y alertas
<p>Es fácil de ver que el tratamiento de registros y alertas es una cuestión
importante en un sistema seguro. Suponga que un sistema está perfectamente
configurado y protegido al 99%. Si tiene lugar el ataque del 1%, y no existen
medidas de seguridad para, primero, detectarlo y, segundo, dar la alarma, el
sistema no es en absoluto seguro.
<p>Debian GNU/Linux proporciona algunas herramientas para efectuar análisis de
registros, en particular <package>swatch</package>, <footnote>hay un artículo
muy bueno sobre él, escrito por <url id="http://www.spitzner.net/swatch.html";
name="Lance Spitzner"></footnote> <package>logcheck</package> o
<package>log-analysis</package> (todos necesitarán alguna adaptación para
eliminar cosas innecesarias del informe). También podría ser útil, si es un
sistema cercano, tener los registros del sistema impresos en una consola
virtual. Esto es útil puesto que usted puede (desde una distancia) ver si el
sistema se está comportando adecuadamente. El archivo
<file>/etc/syslog.conf</file> de Debian viene con una configuración
predeterminada comentada; para habilitarla, descomente las líneas y reinicie
<prgn>syslogd</prgn> (<tt>/etc/init.d/syslogd restart</tt>):
<example>
daemon,mail.*;\
news.=crit;news.=err;news.=notice;\
*.=debug;*.=info;\
*.=notice;*.=warn /dev/tty8
</example>
Para colorear los registros, podría echar un vistazo a
<package>colorize</package>, <package>ccze</package> o
<package>glark</package>. Hay mucha información sobre análisis de registros que
no puede ser cubierta aquí completamente, por eso, una buena fuente de
información podría ser el sitio web <url name="Análisis de registros"
id="http://www.loganalysis.org/";>. En cualquier caso, ni siquiera las
herramientas automáticas igualan a la mejor herramienta de análisis: su cerebro.
<!-- ARRÉGLEME: Revise la información sobre SHARP, el «programa de análisis y
respuesta heurístico de syslog». El artículo está en
id="http://www.csis.gvsu.edu/sharp/";. ¿Es software libre? ¿Está empaquetado?
La URL ya no existe, pero se encuentra archivado en archive.org:
http://web.archive.org/web/20020816100838/http://www.csis.gvsu.edu/sharp/
http://web.archive.org/web/20020816100838/http://www.csis.gvsu.edu/sharp/sharp.ps
No hay disponible un lugar para descargarlo.
-->
<sect1 id="custom-logcheck">Utilizar y personalizar <prgn>logcheck</prgn>
<p>El paquete <prgn>logcheck</prgn> en Debian está dividido en tres paquetes
<package>logcheck</package> (el programa principal),
<package>logcheck-database</package> (una base de datos de expresiones regulares
para el programa) y <package>logtail</package> (imprime lineas de registro que
no se hayan leído todavía). La configuración predeterminada de Debian (en
<file>/etc/cron.d/logcheck</file>) es que <prgn>logcheck</prgn> se ejecute cada
hora y después de los rearranques.
<p>Esta herramienta puede ser muy útil si se adapta adecuadamente para alertar
al administrador de los eventos inusuales del sistema. <prgn>Logcheck</prgn>
puede personalizarse completamente para que envíe correos basados en eventos
encontrados en los registros merecedores de atención. La instalación
predeterminada incluye perfiles para eventos ignorados y violaciones de
directrices para tres configuraciones diferentes (estación de trabajo, servidor
y paranoico). El paquete de Debian incluye un archivo de configuración
<file>/etc/logcheck/logcheck.conf</file>, con fuente en el programa, que define
a qué usuarios se le envían las comprobaciones. También proporciona un camino
para los paquetes, que proporciona servicios para implementar nuevas directrices
en los directorios: <file>/etc/logcheck/cracking.d/_packagename_</file>,
<file>/etc/logcheck/violations.d/_packagename_</file>,
<file>/etc/logcheck/violations.ignore.d/_packagename_</file>,
<file>/etc/logcheck/ignore.d.paranoid/_packagename_</file>,
<file>/etc/logcheck/ignore.d.server/_packagename_</file>, y
<file>/etc/logcheck/ignore.d.workstation/_packagename_</file>. Sin embargo, no
muchos paquetes lo hacen actualmente. Si usted tiene unas directrices que puedan
ser útiles para otros usuarios, por favor envíelo como un informe de error para
el paquete apropiado (como un error de <em>wishlist</em>). Para más información
lea <file>/usr/share/doc/logcheck/README.Debian</file>.
<p>La mejor forma de configurar <prgn>logcheck</prgn> es editar, después de la
instalación, su archivo de configuración principal
<file>/etc/logcheck/logcheck.conf</file>. Cambie el usuario predeterminado
(root) al que deberían enviarse por correo los informes. Debería establecer
allí, también, el nivel de informe. <package>logcheck-database</package> tiene
tres niveles de informe con detalle creciente: «workstation», «server», y
«paranoid» (N. del T., estación de trabajo, servidor y paranoico). El nivel
predeterminado es «workstation», «paranoid» sólo está recomendado para máquinas
de alta seguridad ejecutando los mínimos servicios posibles y «workstation» para
máquinas no críticas, relativamente resguardadas. Si desea añadir nuevos
archivos de registros, añádalos sin más a
<file>/etc/logcheck/logcheck.logfiles</file>. Está ajustado para la instalación
predeterminada de syslog.
<p>Una vez que haya hecho esto podría querer comprobar los correos enviados,
para los primeros días/semanas/meses. Si comprueba que se le han enviado
mensajes que no deseaba recibir, añada las expresiones regulares (vea <manref
name="regex" section="7"> y <manref name="egrep" section="1">) que correspondan
a estos mensajes en
<file>/etc/logcheck/ignore.d.<var>reportlevel</var>/local</file>.
Intente hacer coincidir la línea de registro completa. En
<file>/usr/share/doc/logcheck-database/README.logcheck-database.gz</file> se
explican los detalles sobre cómo escribir reglas. Es un proceso de ajuste en
marcha; una vez que los mensajes enviados son siempre relevantes, puede
considerar concluido el ajuste. Observe que si <prgn>logcheck</prgn> no
encuentra nada relevante en sus sistema, no le enviará correo aunque esté
ejecutándose (por eso podría obtener únicamente un mensaje a la semana, con un
poco de suerte).
<sect1>Configurar adónde se envían las alertas
<p>La configuración estándar de <tt>syslog</tt> que se incluye en Debian (y que
puede encontrar en <file>/etc/syslog.conf</file>) registra los mensajes en los
archivos apropiados basándose en el indicador de tipo de mensaje
recibido. Debería estar familiarizado con esto; si no es así, eche un vistazo al
archivo <file>syslog.conf</file> y a la documentación. Si pretende mantener un
sistema protegido, debería darse cuenta de adónde se envían los mensajes de
registro, de forma que no pasen desapercibidos.
<p> Por ejemplo, enviar los mensajes a la consola también es una configuración
interesante, útil para muchos sistemas en nivel de producción. Pero para muchos
de esos sistemas también sería importante añadir una nueva máquina que sirva
como servidor de registros (N. del T., «loghost»), que recibiría los registros
de todo el resto del sistema.
<p>También debería considerarse el correo del superusuario; muchos controles de
seguridad (como <package>snort</package>) envían alertas al buzón del
superusuario. Este buzón apunta normalmente al primer usuario creado en el
sistema (compruebe <file>/etc/aliases</file>). Asegúrese de enviar el correo del
superusuario a algún lugar en el que pueda ser leído (bien localmente o de forma
remota).
<p>Hay otras cuentas de grupo y alias en su sistema. En un sistema pequeño,
probablemente sea lo más simple asegurarse de que todos los alias apunten a la
cuenta del superusuario, y que el correo del superusuario se reenvíe al buzón
personal del administrador del sistema.
<p>ARRÉGLEME: podría ser interesante contar cómo puede un sistema Debian
enviar/recibir «SNMP traps» relativos a problemas de seguridad (jfs). Comprobar:
<package>snmptrapfmt</package>, <package>snmp</package> y
<package>snmpd</package>.
<sect1>Utilizar un servidor de registros (N. del T., «loghost»)
<p>Un servidor de registros es un ordenador que recopila en la red, de forma
remota, datos de registros del sistema. Si una de sus máquinas ha sido invadida,
el intruso no podrá borrar sus huellas, a no ser que ataque también al servidor
de registros. por eso, el servidor de registros debería ser especialmente
seguro. Es muy simple convertir una máquina en servidor de registros. Únicamente
necesita iniciar <prgn>syslogd</prgn> con <tt>logd -r</tt> y habrá nacido un
nuevo servidor de registros. Con objeto de hacerlo permanente en Debian, edite
<file>/etc/init.d/sysklogd</file> y cambie la línea
<!-- ARRÉGLEME: Lo siguiente también podría ser interesante -->
<!-- Cómo ocultar el servidor de registros en la red, por ejemplo no dándole -->
<!-- una dirección IP y añadiendo una dirección de ARP estática en los -->
<!-- ordenadores de la red utilizando el servidor de syslog remoto -->
<!-- (únicamente si están en el mismo «hub»); si el servidor de syslog -->
<!-- remoto pudiera estar en una red separada, la puerta de enlace -->
<!-- predeterminada debería configurarse convenientemente -->
<example>
SYSLOGD=""
</example>
to
<example>
SYSLOGD="-r"
</example>
A continuación, configure las otras máquinas para enviar datos al servidor de
registros. Añada a <file>/etc/syslog.conf</file> una entrada como la siguiente:
<example>
facility.level @your_loghost
</example>
Vea la documentación para ver qué puede poner en el lugar de las palabras
<em>facility</em> y <em>level</em> (no debe escribirse de forma literal lo del
ejemplo anterior). Si usted quiere registrar de forma remota todo, escriba
únicamente:
<example>
*.* @your_loghost
</example>
en su <file>syslog.conf</file>. Registrar de forma remota además de localmente
es la mejor solución (el atacante podría suponer que ha eliminado las pistas
tras borrar los archivos de registro locales). Vea las páginas de manual de
<manref name="syslog" section="3">, <manref name="syslogd" section="8"> y <manref
name="syslog.conf" section="5"> para obtener información adicional.
<sect1>Permisos de los archivos de registros
<p>No es importante únicamente decidir cómo se utilizan las alertas, sino también
quién tiene acceso de lectura/modificación a los archivos de registros (si no se
utiliza un servidor de registros remoto). Las alertas de seguridad no tienen
mucho valor en el caso de que se produzca una intrusión, ya que el atacante
podría cambiarlas o deshabilitarlas. Además, tiene que tener en cuenta que los
archivos de registros podrían revelar mucha información a un intruso sobre su
sistema, en el caso de que consiga el acceso.
<!-- Debería explicarse por qué esto no queda ya hecho tras la instalación, jfs
-->
<p>Tras la instalación, los permisos de algunos archivos de registros no quedan
perfectos (pero por supuesto esto depende realmente de sus directrices de
seguridad local). Primero, <file>/var/log/lastlog</file> y
<file>/var/log/faillog</file> no necesitan ser leídos por los usuarios
normales. En el archivo <file>lastlog</file> usted puede ver quién ha accedido
recientemente, y en <file>faillog</file> puede ver un resumen de los intentos de
acceso fallidos. El autor recomienda <prgn>chmod 660</prgn> para ambos. Eche un
breve vistazo a sus archivos de registros y decida con mucho cuidado para cuáles
permitir la lectura/escritura de un usuario con un UID distinto de 0 y un grupo
que no sea «adm» o «root». Puede comprobar esto fácilmente en su sistema con:
<example>
# find /var/log -type f -exec ls -l {} \; | cut -c 17-35 |sort -u
(comprueba a qué usuarios pertenecen los archivos de /var/log)
# find /var/log -type f -exec ls -l {} \; | cut -c 26-34 |sort -u
(comprueba a qué grupos pertenecen los archivos de /var/log)
# find /var/log -perm +004
(archivos que son legibles por cualquier usuario)
# find /var/log \! -group root \! -group adm -exec ls -ld {} \;
(archivos que pertenecen a grupos diferentes de root o adm)
</example>
<p>Para personalizar cómo se crean los archivos de registros, probablemente tenga
que ajustar el programa que los genera. Si el archivo de registros rota, no
obstante, usted podrá personalizar el comportamiento de la creación y la
rotación.
<!-- Esto ya no es cierto, compurebe el «logrotate» de apache
<p>
Quiero enfatizar que los permisos de los archivos de registros de apache están
realmente vendidos debido al hecho de que los usuarios de apache son los
propietarios de los archivos de registros de apache. Si un usuario obtiene un
intérprete de órdenes con una puerta trasera en apache, puede fácilmente eliminar
los archivos de registros.
-->
<sect id="kernel-patches">Añadir parches del núcleo
<p>Debian GNU/Linux suministra algunos de los parches para el núcleo de Linux
que mejoran su seguridad. Estos incluyen:
<list>
<item>
<url id="http://www.lids.org"; name="Detección de intrusos en Linux">
suministrado en el paquete <package>kernel-patch-2.4-lids</package>. Este parche
del núcleo hace más fácil el proceso de fortalecimiento de su sistema Linux,
permitiéndole restringir, ocultar y proteger procesos, incluso de
superusuario. Implementa capacidades de control de acceso obligatorio.
<item><url id="http://acl.bestbits.at/"; name="Listas de control de acceso en POSIX">
(ACLs) para Linux suministradas en el paquete
<package>kernel-patch-acl</package>. Este parche del núcleo añade listas de
control de acceso, un método avanzado para restringir el acceso a archivos. Le
permite control de acceso de grano fino para archivos y directorios.
<item><url id="http://trustees.sourceforge.net/"; name="Trustees de Linux">,
suministrado en el paquete <package>trustees</package>. Este parche añade al
núcleo de Linux un sistema decente de gestión de permisos avanzado. Objetos
especiales (llamados «trustees») se ligan a cada archivo o directorio, y se
almacenan en la memoria del núcleo, lo que permite una búsqueda rápida para
todos los permisos.
<item>Linux mejorado de la NSA (N. del T., «National Security Agency») (en el
paquete <package>selinux</package> también disponible en
<url id="http://www.coker.com.au/selinux/"; name="el sitio web del
desarrollador">)
<item>El <url id="http://people.redhat.com/mingo/exec-shield/";
name="parche exec-shield"> suministrado en el paquete
<package>kernel-patch-exec-shield</package>. Este parche proporciona protección
contra algunos desbordamientos de búfer (ataques de tipo «stack-smashing»).
<item>El <url id="http://www.grsecurity.net/"; name="parche de Grsecurity">,
suministrado por los paquetes <package>kernel-patch-2.4-grsecurity</package> y
<package>kernel-patch-grsecurity2</package>
<footnote>
Observe que este parche está en conflicto con parches ya incluidos en el paquete
fuente del núcleo 2.4 de Debian. Necesitará utilizar el típico núcleo «vanilla»
(N. del T., núcleo base, sin modificar, tal como se descarga de
kernel.org). Puede hace esto con los siguientes pasos:
<example>
# apt-get install kernel-source-2.4.22 kernel-patch-debian-2.4.22
# tar xjf /usr/src/kernel-source-2.4.22.tar.bz2
# cd kernel-source-2.4.22
# /usr/src/kernel-patches/all/2.4.22/unpatch/debian
</example>
<p>Para más
información vea el <url id="http://bugs.debian.org/194225";
name="#194225">, <url id="http://bugs.debian.org/199519";
name="#199519">, <url id="http://bugs.debian.org/206458";
name="#206458">, <url id="http://bugs.debian.org/203759";
name="#203759">, <url id="http://bugs.debian.org/204424";
name="#204424">, <url id="http://bugs.debian.org/210762";
name="#210762">, <url id="http://bugs.debian.org/211213";
name="#211213">, y el <url
id="http://lists.debian.org/debian-devel/2003/debian-devel-200309/msg01133.html";
name="debate que tuvo lugar en debian-devel">
</footnote>
implementa Control de Acceso Obligatorio por medio de RBAC, proporciona
protección de desbordamiento de búfer por medio de PaX, ACLs, aleatoriedad de
red (para que sea más difícil dejar huellas) y <url
id="http://www.grsecurity.net/features.php"; name="muchas funcionalidades más">.
<item>El paquete <package>kernel-patch-adamantix</package> suministra los
parches desarrollados para <url id="http://www.adamantix.org/";
name="Adamantix">, una distribución basada en Debian. Este parche del núcleo
para las versiones 2.4.x introduce alguna característica de seguridad, como el
uso de una pila no ejecutable por medio del uso de <url
id="http://pageexec.virtualave.net/"; name="PaX"> y control de acceso obligatorio
basado en <url id="http://www.rsbac.org/"; name="RSBAC" >. Otras características
incluidas son:
<url name="el parche de PID aleatorio" id="http://www.vanheusden.com/Linux/sp/";>,
«loop device» cifrado con AES, soporte de MPPE y un «backport» de IPSEC v2.6.
<item><package>cryptoloop-source</package>. Este parche le permite utilizar las
funciones del API de cifrado del núcleo para crear sistemas de archivos cifrados
utilizando el dispositivo «loopback».
<item>Soporte de IPSEC en el núcleo (en el paquete
<package>kernel-patch-freeswan</package>). Si usted quiere utilizar con Linux el
protocolo IPsec, necesita este parche. Puede crear fácilmente redes privadas
virtuales (VPNs), incluso con máquinas Windows, ya que IPsec es un estándar
común. Las capacidades de IPsec se han añadido al núcleo de desarrollo 2.5, por
tanto, esta característica estará presente de forma predeterminada en el núcleo
2.6 de Linux. Página principal: <url id="http://www.freeswan.org";>. Nota: El uso
de FreeSwan ha sido desaconsejado en favor de OpenSwan.
<em>ARRÉGLEME</em>: Los últimos núcleos 2.4 suministrados en Debian incluyen un
«backport» del código de IPSEC desde el 2.5. Añada algún comentario sobre esto.
</list>
<p>Los siguientes parches de seguridad del núcleo están disponibles únicamente
para versiones antiguas del núcleo en «woody» y se desaconseja su uso:
<list>
<item>El parche del núcleo de Linux de <url name="Openwall"
id="http://www.openwall.com/linux/";> implementado por Solar Designer y
suministrado en el paquete <package>kernel-patch-2.2.18-openwall</package>.
Este es un conjunto útil de restricciones del núcleo, como enlaces restringidos,
FIFOs en <file>/tmp</file>, un sistema de archivos <file>/proc</file>
restringido, manipulación especial del descriptor de archivos, área de pila de
usuario no ejecutable y otras características. Nota: Este paquete se aplica a la
versión 2.2, no hay paquetes proporcionados por Solar disponibles para los
parches de la versión 2.4.
<item><package>kernel-patch-int</package>. Este parche añade también capacidades
de cifrado al núcleo de Linux, y fue útil hasta la versión Potato de Debian. No
funciona con Woody, y si usted usa Sarge o una versión más moderna, debería
utilizar un núcleo más reciente que incluya ya estas características.
</list>
<p>ARRÉGLEME: añada más contenido, explicando cómo pueden instalarse en Debian
estos parches específicos, utilizando los paquetes kernel-2.x.x-patch-XXX.
</p>
<P>ARRÉGLEME: Separe los parches aplicables únicamente a los núcleos 2.2, los
parches aplicables a núcleos 2.4 y aquellos que funcionan con ambos.
<!-- Haga las entradas coherentes: ¿deberían ser los nombres de paquete enlaces a
las páginas de los paquetes relevantes? -->
<p>Sin embargo, algunos parches no han sido todavía suministrados en Debian. Si
usted siente que alguno de estos debería estar incluido, por favor pídalo en
<url name="Paquetes en los que se necesita ayuda y en perspectiva"
id="http://www.debian.org/devel/wnpp/";>. Algunos de estos son:
<list>
<item>
<url name="Parche de HAP"
id="http://www.theaimsgroup.com/~hlein/hap-linux/";> (HAP significa
<em>Hank Approved Paranoid Linux</em>). Una colección de parches de seguridad
para los núcleos 2.2.x.
</list>
<sect>Proteger contra desbordamientos de búfer
<p><em>Desbordamiento de búfer</em> es el nombre de un común ataque al software
<footnote>Tan común, de hecho, que es la base del 20% de las vulnerabilidades de
seguridad comunicadas cada año, según se determina en <url
id="http://icat.nist.gov/icat.cfm?function=statistics"; name="Estadísticas de la
base de datos de vulnerabilidades de ICAT"></footnote> que se aprovecha de una
insuficiente comprobación de límites (un error de programación, el más común en
lenguaje C) para ejecutar código máquina a través de las entradas del
programa. Estos ataques, contra el software de servidores que escuchan
conexiones de forma remota y contra el software local que garantiza mayores
privilegios a usuarios (<tt>setuid</tt> o <tt>setgid</tt>), pueden comprometer
cualquier sistema.
<p>Hay principalmente cuatro métodos de protección contra desbordamientos de
búfer:
<list>
<item>parchear el núcleo para evitar la ejecución de pila. Usted puede usar:
Exec-shield, OpenWall o PaX (incluidos en los parches de Grsecurity y
Adamantix).
<!-- ARRÉGLEME: añada un enlace a libsafe, al sitio principal -->
<item>utilizar una biblioteca, tal como <url
id="http://www.research.avayalabs.com/project/libsafe/";
name="libsafe">, para sobreescribir funciones vulnerables e introducir
comprobaciones apropiadas (para obtener información sobre cómo instalar
<package>libsafe</package> lea <url
id="http://www.Linux-Sec.net/harden/libsafe.uhow2.txt"; name="esto">).
<item>arreglar el código fuente utilizando herramientas para encontrar aquellos
fragmentos que pudieran introducir esta vulnerabilidad.
<item>recompilar el código fuente para introducir comprobaciones apropiadas que
eviten desbordamientos, utilizando, por ejemplo, <url
id="http://www.immunix.org/stackguard.html"; name="StackGuard"> (el cual es
utilizado por <url id="http://www.immunix.org"; name="Immunix">) o el parche para
GCC <url id="http://www.research.ibm.com/trl/projects/security/ssp/"; name="Stack
Smashing Protector (SSP)"> (el cual es utilizado por <url
id="http://www.adamantix.org"; name="Adamantix">)
</list>
<p>Debian GNU/Linux, a partir de la versión 3.0, suministra software para
introducir todos estos métodos excepto para la protección en la compilación
de código fuente (aunque esto se ha solicitado en el <url
id="http://bugs.debian.org/213994"; name="Error #213994">).
<p>Observe que incluso si Debian suministrara un compilador con características
de protección de desbordamiento de búfer/pila, todos los paquetes necesitarían
ser recompilados para introducir esta característica. Esto es, de hecho, lo que
la distribución de Adamantix hace (entre otras cosas). El efecto de esta nueva
característica sobre la estabilidad del software está todavía por determinar
(algunos programas o algunas arquitecturas de procesador podrían fallar debido a
esto).
<p>En cualquier caso, sea consciente de que incluso con estas correcciones
podrían no evitarse los desbordamientos de búfer puesto que hay formas para
evitarlos, como se describió en la revista de phrack <url name="número 58"
id="http://packetstorm.linuxsecurity.com/mag/phrack/phrack58.tar.gz";>
o en la consulta de CORE
<url id="http://online.securityfocus.com/archive/1/269246";
name="Múltiples vulnerabilidades en las tecnologías de protección de «stack
smashing»" >.
<p>Si quiere probar su protección de desbordamiento de búfer una vez lo haya
implementado (sin tener en cuenta el método) podría interesarle instalar el
paquete <package>paxtest</package> y ejecutar las pruebas que vienen con él.
<sect1>Parches del núcleo para protección de desbordamientos de búfer
<p>Los parches del núcleo relativos a desbordamientos de búfer, incluido el
parche Openwall, proporcionan protección contra desbordamientos de búfer en
núcleos de Linux 2.2. Para 2.4 o núcleos más nuevos, necesita usar la
implementación Exec-shield, o la implementación PaX (suministrada en el parche
grsecurity, <package>kernel-patch-2.4-grsecurity</package>,
y en el parche Adamantix, <package>kernel-patch-adamantix</package>).
Para más información sobre la utilización de estos parches lea la sección <ref
id="kernel-patches">.
<sect1>Protección con <prgn>Libsafe</prgn>
<p>Proteger un sistema Debian GNU/Linux con <package>libsafe</package> es
bastante sencillo. Simplemente instale el paquete y conteste <em>Yes</em>, y
tendrá la biblioteca globalmente precargada. Sea cuidadoso, sin embargo, puesto
que esto podría destrozar su software (en particular, programas enlazados con la
antigua <prgn>libc5</prgn>), por ello asegúrese de leer primero los <url
id="http://bugs.debian.org/libsafe"; name="informes de error notificados"> y
probar los programas más críticos de su sistema con el programa «wrapper» de
<prgn>libsafe</prgn>.
<p><em>Nota importante</em>: la protección de <prgn>libsafe</prgn> podría no ser
efectiva comúnmente como se describe en <url id="http://bugs.debian.org/173227";
name="173227">. Considere probarlo cuidadosamente antes de utilizarlo en un
entorno productivo y no dependa exclusivamente de él para proteger su sistema.
<sect1>Probar programas por desbordamientos
<p>El uso de herramientas para detectar desbordamientos de búfer requiere, en
cualquier caso, experiencia en programación para corregir (y recompilar) el
código. Debian proporciona, por ejemplo: <package>bfbtester</package> (un
probador de desbordamientos de búfer que prueba los binarios por fuerza bruta a
través de la línea de órdenes y los desbordamientos de las variables de
entorno)<!-- ARRÉGLEME: ¿dónde está? y <package>njamd</package>-->. Otros
paquetes de interés podrían ser también <package>rats</package>,
<package>pscan</package>, <package>flawfinder</package> y
<package>splint</package>.
<sect>Transferencias seguras de archivos
<p>Durante la administración normal del sistema, habitualmente se necesitan
transferir archivos desde el sistema y hacia él. La copia de archivos de forma
segura desde un ordenador a otro puede conseguirse utilizando el paquete del
servidor de <package>ssh</package>. Otra posibilidad es el uso de
<package>ftpd-ssl</package>, un servidor de ftp que utiliza <em>Secure
Socket Layer</em> para cifrar las transmisiones.
<p>Cualesquiera de estos métodos necesitan clientes especiales. Debian
proporciona software cliente, como <prgn>scp</prgn> del paquete
<package>ssh</package>, el cual funciona como <prgn>rcp</prgn> pero está
completamente cifrado, por lo que los <em>chicos malos</em> no pueden ni
siquiera averiguar LO QUE usted copia. También está el paquete
<package>ftp-ssl</package> para el servidor equivalente. Puede encontrar
clientes de este software incluso para otros sistemas operativos (no UNIX),
<prgn>putty</prgn> y <prgn>winscp</prgn> proporcionan implementaciones de copia
segura para cualquier versión de los sistemas operativos de Microsoft.
<p>Observe que al utilizar <prgn>scp</prgn> se proporciona a los usuarios acceso
a todo el sistema de archivos, a menos que utilice <prgn>chroot</prgn> como se
describe in <ref id="ssh-chroot">. El acceso por FTP puede ser enjaulado con
<prgn>chroot</prgn>, probablemente más fácil contando con el demonio elegido,
como se describe en <ref id="ftp-secure">. Si le preocupa que los usuarios miren
en sus archivos y quiere tener la comunicación cifrada, puede utilizar un
demonio de ftp con soporte SSL o combinar ftp en modo de texto claro con una
configuración de VPN (vea <ref id="vpn">).
<sect>Límites y control del sistema de archivos
<sect1>Utilizar cuotas
<p>
Es importante tener unas buenas directrices sobre cuotas, para evitar que los
usuarios puedan llenar los discos duros.
<p>
Usted puede utilizar dos sistemas de cuotas diferentes: cuotas de usuario y
cuotas de grupo. Como probablemente imagine, las cuotas de usuario limitan la
cantidad de espacio que cada usuario puede ocupar, mientras que las cuotas de
grupo hacen lo equivalente con los grupos. Tenga esto en mente cuando esté
calculando los tamaños de las cuotas.
<p>Hay una serie de puntos importantes en los que pensar a la hora de configurar
un sistema de cuotas:
<list>
<item>Mantenga las cuotas lo suficientemente pequeñas para que los usuarios no
agoten el espacio del disco.
<item>Mantenga las cuotas lo suficientemente grandes para que los usuarios no se
quejen o sus cuotas de correo les permitan aceptar correo durante un largo
período.
<item>Utilice cuotas en todas las áreas en las que pueda escribir el usuario, en
<file>/home</file> así como también en <file>/tmp</file>.
</list>
<p>Debería tener habilitadas las cuotas para cada partición o directorio en los
cuales los usuarios tengan acceso de escritura completo. Calcule y asigne un
tamaño de cuota viable para aquellas particiones y directorios que combinen
utilizabilidad y seguridad.
<p>Así que quiere utilizar cuotas. Lo primero que necesita es comprobar si tiene
habilitado el soporte para cuotas en el núcleo. Si no lo tiene tendrá que volver
a compilarlo. Después de esto, compruebe si está instalado el paquete
<package>quota</package>. Si no lo está, tendrá que instalarlo también.
<!-- ARRÉGLEME: ¿cómo comprobar si se tiene soporte para cuotas? ¿Qué ajustar
cuando recompile? -->
<p>
Habilitar las cuotas para los respectivos sistemas de archivos es tan fácil como
modificar la configuración en el archivo <file>/etc/fstab</file>, pasando de
<tt>defaults</tt> a <tt>defaults,usrquota</tt>. Si necesita cuotas de grupo,
sustituya <tt>usrquota</tt> to <tt>grpquota</tt>. También puede utilizar
ambas. Luego cree dos archivos vacíos con los nombres quota.user y quota.group,
en la raíz del sistema de archivos en el que quiere utilizar cuotas (p.ej. <tt>touch
/home/quota.user /home/quota.group</tt> para un sistema de archivos en
<file>/home</file>).
<p>
Reinicie <prgn>quota</prgn> haciendo <tt>/etc/init.d/quota stop;/etc/init.d/quota
start</tt>. Ahora debería estar ejecutándose quota, y puede establecerse el
tamaño de las cuotas.
<p>Se pueden editar las cuotas para un usuario determinado mediante
<tt>edquota -u <user></tt>. Las cuotas de grupo pueden modificarse con
<tt>edquota -g
<group></tt>. Luego establezca las cuotas de soft y hard y/o las cuotas de
inodos como sea necesario.
<p>
Para más información sobre cuotas, lea la página de manual de «quota», y el
mini-cómo de «quota»
(<file>/usr/share/doc/HOWTO/en-html/mini/Quota.html</file>). También puede
querer mirar <file>pam_limits.so</file>.
<sect1 id="ext2attr">Los atributos específicos del sistema de archivos ext2
(chattr/lsattr) <!-- última edición de esta sección por Frédéric Schütz
<schutz@mathgen.ch> -->
<p>Además de los permisos habituales de Unix, los sistemas de archivos ext2 y
ext3 ofrecen un conjunto de atributos específicos que le dan más control sobre
los archivos del sistema. A diferencia de los permisos básicos, estos atributos
no se muestran con el habitual <prgn>ls -l</prgn> ni se cambian utilizando
<prgn>chmod</prgn>, y se necesitan otras dos utilidades, <prgn>lsattr</prgn> y
<prgn>chattr</prgn> (en el paquete <package>e2fsprogs</package>), para
gestionarlos. Observe que esto quiere decir que estos atributos no se guardarán
normalmente cuando haga una copia de seguridad del sistema, por eso si usted
cambia alguno de ellos, puede merecer la pena guardar las sucesivas órdenes
<prgn>chattr</prgn> en un «script» de forma que pueda volver a establecer los
atributos más tarde si tiene que restaurar una copia de seguridad.
<p>
Entre todos los atributos disponibles, los dos más importantes para incrementar
la seguridad se referencian con las letras «i» y «a», y únicamente pueden
establecerse (o quitarse) por el superusuario:
<list>
<item>El atributo «i» («immutable», N. del T., inmutable): un archivo con este
atributo no puede ser modificado ni eliminado ni renombrado, ni pueden crearse
enlaces a él, ni siquiera con el superusuario.
<item>El atributo «a» («append», N. del T., añadir al final): este atributo
tiene el mismo efecto que el atributo «immutable», excepto que usted puede abrir
el archivo en modo «append». Esto significa que usted puede aún añadir más
contenido al archivo, pero es imposible modificar el contenido anterior. Este
atributo es especialmente útil para los archivos de registros almacenados en
<file>/var/log/</file>, aunque debería tener en cuenta que podrían moverse
algunas veces debido a los «scripts» de rotación de registros.
</list>
<p>
Estos atributos pueden establecerse también para directorios, en cuyo caso se
deniega a todo el mundo el derecho a modificar los contenidos de una lista de
directorios (p. ej. renombrar o eliminar un archivo, ...). Cuando se aplica a un
directorio el atributo «append», únicamente está permitido la creación de
archivos.
<p>
Es fácil ver cómo mejora la seguridad el atributo «a», dando a los programas que
no están siendo ejecutados como superusuarios, la capacidad de añadir datos a un
archivo sin modificar su contenido previo. Por otro lado, el atributo «i» parece
menos interesante: después de todo, el superusuario ya puede utilizar los
permisos básicos de Unix para restringir el acceso a un archivo, y un intruso
que obtuviera acceso a la cuenta de superusuario siempre podría utilizar el
programa <prgn>chattr</prgn> para eliminar el atributo. Tal intruso podría
resultar confundido al principio cuando viera que no es capaz de eliminar un
archivo, pero usted no debería asumir que es ciego - después de todo, ¡ha
accedido a su sistema! Algunos manuales (incluyendo una versión anterior de este
documento) sugieren simplemente eliminar los programas <prgn>chattr</prgn> y
<prgn>lsattr</prgn> del sistema para incrementar la seguridad, pero ese tipo de
estrategia, también conocida como «seguridad por oscuridad», debe ser
absolutamente evitada, puesto que proporciona una falsa sensación de seguridad.
<p>
Una forma segura de resolver este problema es utilizar las capacidades del
núcleo de Linux, como se describe en <ref id="proactive">. La capacidad de
interés aquí se llama <tt>CAP_LINUX_IMMUTABLE</tt>: si usted la elimina del
conjunto delimitado de capacidades (utilizando por ejemplo la orden <tt>lcap
CAP_LINUX_IMMUTABLE</tt>) no será posible cambiar más en su sistema ningún
atributo «a» o «i», ¡ni siquiera por el superusuario! Una estrategia completa
podría ser la siguiente:
<enumlist>
<item> Establecer los atributos «a» e «i» sobre cualquier archivo que se desee;
<item> Añadir la orden <tt>lcap CAP_LINUX_IMMUTABLE</tt> (así como
<tt>lcap CAP_SYS_MODULE</tt>, como se sugiere en <ref id="proactive">) a
uno de los «scripts» de arranque;
<!-- ¿Hay alguna cosa interesante en la página siguiente?:
http://lists.debian.org/debian-security/2001/debian-security-200107/msg00024.html -->
<item> Establecer el atributo «i» sobre este «scripts» y el resto de los
archivos de arranque, así como sobre el propio binario de
<prgn>lcap</prgn>;
<item> Ejecutar manualmente la orden anterior (o reiniciar su sistema para
asegurarse de que todo funciona según lo planeado).
</enumlist>
<p>
Ahora que la capacidad ha sido eliminada del sistema, un intruso no puede
cambiar ningún atributo de los archivos protegidos, y así no puede cambiar o
eliminar los archivos. Si el fuerza un reinicio de la máquina (que es la única
forma de restaurar el conjunto delimitado de capacidades), se detectará
fácilmente, y de cualquier forma se eliminará de nuevo la capacidad tan pronto
como el sistema rearranque. La única forma de cambiar un archivo protegido sería
arrancando el sistema en el modo de usuario único (N. del T., single-user) o
utilizar otro disco de arranque, ¡dos operaciones que requieren acceso físico a
la máquina!
<!-- Añada una nota sobre el hecho de que esto no se utiliza ampliamente -->
<sect1 id="check-integ">Comprobar la integridad del sistema de archivos
<p>¿Está usted seguro de que <file>/bin/login</file> en su disco duro es todavía
el binario que instaló hace algunos meses? ¿Qué pasa si es una versión alterada,
la cual almacena la contraseña introducida en un archivo oculto o lo manda por
correo todo en versión de texto claro sobre Internet?
<p>El único método para tener alguna clase de protección es comprobar sus
archivos cada hora/día/mes (yo prefiero cada día) , comparando el md5sum actual
y el antiguo del archivo. Dos archivos no pueden tener el mismo md5sum (el MD5
está formado por 128 bits, por tanto la posibilidad de que dos archivos
diferentes tengan el mismo md5sum es aproximadamente de 1 entre 3.4e3803), por
eso puede estar seguro, a menos que alguien haya alterado también el algoritmo
que crea los md5sums en esa máquina. Esto es, también, extremadamente difícil y
muy improbable. Realmente debería considerar la auditoría de sus binarios como
algo muy importante, pues es una forma sencilla de reconocer cambios en ellos.
<p>Las herramientas comunes utilizadas para esto son
<package>sxid</package>, <package>aide</package> (Advanced Intrusion Detection
Environment. N. del T., Entorno avanzado de detección de intrusos),
<package>tripwire</package>, <package>integrit</package> y
<package>samhain</package>.
Instalar <prgn>debsums</prgn> también le ayudará a comprobar la integridad del
sistema de archivos, mediante la comparación de los md5sums de cada archivo con
los md5sums de los paquetes de Debian. Pero sea cauto: aquellos archivos pueden
ser cambiados fácilmente por un atacante y no todos los paquetes proporcionan un
listado de md5sums para los binarios que contienen. Para obtener más información
lea <ref id="periodic-integrity"> y <ref id="snapshot">.
<p>Usted podría querer utilizar <prgn>locate</prgn> para indexar todo el sistema
de archivos, si es así, considere las implicaciones que conlleva. El paquete
<package>findutils</package> de Debian contiene <prgn>locate</prgn> el cual se
ejecuta como usuario «nobody» (N. del T., nadie), y por eso sólo indexa los
archivos visibles para todo el mundo. Sin embargo, si cambia su comportamiento
hará visible las localizaciones de todos los archivos para todos los
usuarios. Si usted quiere indexar todo el sistema de archivos (no los bits que
puede ver el usuario «nobody») puede reemplazar <prgn>locate</prgn> con el
paquete <package>slocate</package>. slocate está catalogado como una versión de
GNU locate con la seguridad mejorada, pero realmente proporciona funcionalidades
adicionales de localización de archivos. Cuando utilice <prgn>slocate</prgn>, el
usuario únicamente ve aquellos archivos a los que realmente tiene acceso y usted
puede excluir cualquier archivo o directorio del sistema. El paquete
<package>slocate</package> ejecuta su proceso de actualización con mayores
privilegios que locate, e indexa todos los archivos. Los usuarios pueden luego
buscar rápidamente cualquier archivo que puedan ver. <prgn>slocate</prgn> no le
permite ver archivos nuevos; filtra la salida basándose en su UID.
<p>ARRÉGLEME: mencionar los binarios firmados usando, por ejemplo, bsign o
elfsign.
<sect1>Configurar la comprobación de setuid
El paquete <package>checksecurity</package> de Debian proporciona una tarea de
<prgn>cron</prgn> que se ejecuta diariamente en
<file>/etc/cron.daily/checksecurity</file>
<footnote>En versiones anteriores, checksecurity estaba integrado en cron y el
archivo era <file>/etc/cron.daily/standard</file></footnote>.
Esta tarea de <prgn>cron</prgn> ejecutará el «script» de
<prgn>/usr/sbin/checksecurity</prgn> que almacenará información sobre estos
cambios.
<p>El comportamiento predeterminado no envía esta información al superusuario
pero, en su lugar mantiene copias diarias de los cambios en
<file>/var/log/setuid.changes</file>. Usted debería establecer la variable
MAILTO (en <file>/etc/checksecurity.conf</file>) a «root» para que el
superusuario reciba esta información por correo. Vea <manref
name="checksecurity" section="8"> para obtener más información sobre la
configuración.
<sect id="network-secure">Proteger el acceso de red
<p>ARRÉGLEME. Necesita más contenido (específico de Debian).
<sect1 id="kernel-conf">Configurar las características de red del núcleo
<p>Muchas características del núcleo pueden modificarse mientras se ejecuta,
enviando el eco de algo al sistema de archivos <file>/proc</file> o utilizando
<prgn>sysctl</prgn>. Introduciendo <tt>/sbin/sysctl -A</tt> usted puede ver lo
que puede configurar y cuáles son las opciones, y puede modificarlo ejecutando
<tt>/sbin/sysctl -w variable=value</tt> (vea <manref section="8"
name="sysctl">). Únicamente necesita editar algo aquí en casos excepcionales,
pero puede también incrementar la seguridad de esa forma. Por ejemplo:
<!-- ARRÉGLEME: ¿Debería ser /proc/sys/ el prefijo en todos estos? era -->
<example>
net/ipv4/icmp_echo_ignore_broadcasts = 1
</example>
<p>Este es un <em>emulador de Windows</em> porque actúa como Windows con los
ping enviados en «broadcast» (N. del T., a todos los ordenadores de la red) si
esta opción está puesta a 1. Esto es, la solicitud de ICMP_ECHO enviada a la
dirección de «broadcast» será ignorada. Si no, no hará nada.
<p>Si quiere evitar que su sistema responda a las solicitudes de eco de tipo
ICMP, habilite simplemente esta opción de configuración:
<example>
net/ipv4/icmp_echo_ignore_all = 1
</example>
<p>Para registrar paquetes con direcciones imposibles (debido a rutas erróneas)
en su red utilice:
<example>
/proc/sys/net/ipv4/conf/all/log_martians = 1
</example>
<p>Para obtener más información sobre las cosas que se pueden hacer con
<file>/proc/sys/net/ipv4/*</file> lea
<file>/usr/src/linux/Documentation/filesystems/proc.txt</file>. Todas las
opciones están descritas detalladamente en
<file>/usr/src/linux/Documentation/networking/ip-sysctl.txt</file>
<footnote>En Debian los paquetes
<package>kernel-source-<var>version</var></package> copian las fuentes a
<file>/usr/src/kernel-source-<var>version</var>.tar.bz2</file>, sustituya
únicamente <var>version</var> por la versión de las fuentes del núcleo que haya
instalado </footnote>.
<sect1 id="tcp-syncookies">Configurar Syncookies
<p>Esta opción es un arma de doble filo. Por un lado protege su sistema contra
ataques de tipo «syn flood»; pero por otro viola los estándares definidos
(RFCs).
<!-- ¿Qué significa esto? (jfs)
Esta opción es bastante tonta, ya que inunda tanto el otro lado como el suyo,
por tanto el otro lado también está ocupado.
-->
<example>
net/ipv4/tcp_syncookies = 1
</example>
<p>Si quiere cambiar esta opción cada vez que el núcleo esté funcionando
necesita hacerlo en <tt>/etc/network/options</tt>, estableciendo
<tt>syncookies=yes</tt>. Esto tomará efecto siempre que se ejecute
<tt>/etc/init.d/networking</tt> (lo cual se hace típicamente en el arranque)
mientras lo siguiente tendrá efecto una sola vez hasta el reinicio:
<example>
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
</example>
<p>Esta opción sólo estará disponible si el núcleo se compiló con
<tt>CONFIG_SYNCOOKIES</tt>. Todos los núcleos Debian están compilados con esta
opción incorporada, pero puede verificarlo ejecutando:
<example>
$ sysctl -A |grep syncookies
net/ipv4/tcp_syncookies = 1
</example>
<p>Par obtener más información sobre «syncookies» de TCP lea <url
id="http://cr.yp.to/syncookies.html";>.
<sect1 id="net-harden">Proteger la red durante el arranque
<p>Cuando establezca opciones de configuración para el código de red del núcleo,
necesita configurarlo de forma que se cargue cada vez que el sistema vuelva a
arrancar. El ejemplo siguiente habilita muchas de las opciones previas así como
otras opciones útiles.
<p>Realmente hay dos formas de configurar su red durante el arranque. Puede
configurar <file>/etc/sysctl.conf</file> (vea: <manref section="5"
name="sysctl.conf">) o introducir un «script» que sea llamado al habilitarse la
interfaz. La primera opción se aplicará a todas las interfaces, mientras que la
segunda opción le permite configurar esto sobre la base de cada interfaz.
<p>Abajo se muestra un ejemplo de una configuración de
<file>/etc/sysctl.conf</file> que protegerá algunas opciones de red al nivel del
núcleo. Observe los comentarios incorporados, <file>/etc/network/options</file>
podría redefinir algunos valores si están en contradicción con los de este
archivo cuando se ejecute <file>/etc/init.d/networking</file> (lo cual ocurre
después que <file>procps</file> en la secuencia de arranque).
<example>
#
# /etc/sysctl.conf - Archivo de configuración de variables del sistema.
# Para obtener información vea sysctl.conf (5). Vea también los archivos de
# Documentation/sysctl/, Documentation/filesystems/proc.txt, y
# Documentation/networking/ip-sysctl.txt en las fuentes del núcleo
# (/usr/src/kernel-$version si tiene instalado un kernel-package)
# para obtener más información sobre los valores que pueden definirse aquí.
#
# Están avisados de que /etc/init.d/procps se ejecuta para establecer las
# siguientes variables. Sin embargo, tras esto, /etc/init.d/networking establece
# algunas opciones de red con valores incorporados. Estos valores pueden ser
# redefinidos utilizando /etc/network/options.
#
#kernel.domainname = example.com
# Ajustes adicionales - adaptado a partir del script contribución
# de Dariusz Puchala (vea más abajo)
# Ignorar broadcasts de ICMP
net/ipv4/icmp_echo_ignore_broadcasts = 1
#
# Ignorar falsos errores de ICMP
net/ipv4/icmp_ignore_bogus_error_responses = 1
#
# No aceptar redireccionamiento de ICMP (evitar ataques de tipo MITM)
net/ipv4/conf/all/accept_redirects = 0
# _o_
# Aceptar redireccionamiento de ICMP únicamente para puertas de enlace
# (gateways) listadas en nuestra lista de puertas de enlace predeterminadas
# (habilitadas por omisión)
# net/ipv4/conf/all/secure_redirects = 1
#
# No enviar redireccionamiento de ICMP (no somos un enrutador)
net/ipv4/conf/all/send_redirects = 0
#
# No redireccionar paquetes IP (no somos un enrutador)
# Nota: Asegúrese de que /etc/network/options tiene 'ip_forward=no'
net/ipv4/conf/all/forwarding = 0
#
# Habilitar TCP Syn Cookies
# Nota: Asegúrese de que /etc/network/options tiene 'syncookies=yes'
net/ipv4/tcp_syncookies = 1
#
# Registrar los paquetes marcianos
net/ipv4/conf/all/log_martians = 1
#
# Conectar la verificación de direcciones fuente (Source Address Verification)
# en todas las interfaces para evitar algunos ataques de suplantación de
# dirección.
# Nota: Asegúrese de que /etc/network/options tiene 'spoofprotect=yes'
net/ipv4/conf/all/rp_filter = 1
#
# No aceptar paquetes IP con ruta prefijada (source route packets) (no somos un
# enrutador)
net/ipv4/conf/all/accept_source_route = 0
</example>
<p>Para utilizar el «script» necesita crearlo primero, por ejemplo, en
<file>/etc/network/interface-secure</file> (el nombre se da como ejemplo) y
llamarlo desde <file>/etc/network/interfaces</file> de la siguiente forma:
<example>
auto eth0
iface eth0 inet static
address xxx.xxx.xxx.xxx
netmask 255.255.255.xxx
broadcast xxx.xxx.xxx.xxx
gateway xxx.xxx.xxx.xxx
pre-up /etc/network/interface-secure
</example>
<p>En este ejemplo, antes de habilitar la interfaz eth0, se llamará al «script»
para proteger todas las interfaces de red como se muestra más abajo.
<example>
#!/bin/sh -e
# Nombre del script: /etc/network/interface-secure
# Modifica algún comportamiento predeterminado para proteger todas las
# interfaces de ataques & suplantación TCP/IP
#
# Contribución de Dariusz Puchalak
#
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
# habilitada la protección de eco en broadcast
echo 0 > /proc/sys/net/ipv4/conf/all/forwarding
# deshabilitado el reenvío ip
echo 1 > /proc/sys/net/ipv4/tcp_syncookies # Habilitada protección TCP syn cookie
echo 1 >/proc/sys/net/ipv4/conf/all/log_martians # Registro de paquetes extraños
# (esto incluye paquetes suplantados, paquetes con ruta prefijada, paquetes
# redireccionados) pero sea cuidadoso con esto en servidores de web con
# mucha carga
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
# habilitada la protección de mensajes de error falsos
# ahora protección de suplantación de ip
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
# y finalmente algunas cosas más:
# Deshabilitar la aceptación de redireccionamiento de ICMP
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
# Deshabilitar los paquetes de ruta prefijada
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
exit 0
</example>
<p>Observe que puede realmente tener un «script» por interfaz, con lo que
habilitará opciones de red diferentes para interfaces diferentes (si tiene más
de una), únicamente cambie la línea de pre-up a:
<example>
pre-up /etc/network/interface-secure $IFACE
</example>
<p>Y utilice un «script» que únicamente aplicará cambios a una interfaz
específica, no a todas las interfaces disponibles. Observe, sin embargo, que
algunas opciones de red únicamente pueden habilitarse globalmente. Un «script»
de ejemplo es éste:
<example>
#!/bin/sh -e
# Nombre del script: /etc/network/interface-secure
# Modifica algún comportamiento predeterminado para proteger de ataques &
# suplantación TCP/IP, para una interfaz dada
#
# Contribución de Dariusz Puchalak
#
IFACE=$1
if [ -z "$IFACE" ] ; then
echo "$0: Must give an interface name as argument!"
echo "Usage: $0 <interface>"
exit 1
fi
if [ ! -e /proc/sys/net/ipv4/conf/$IFACE/ ]; then
echo "$0: Interface $IFACE does not exit (cannot find /proc/sys/net/ipv4/conf/)"
exit 1
fi
echo 0 > /proc/sys/net/ipv4/conf/$IFACE/forwarding # deshabilitado el reenvío ip
echo 1 >/proc/sys/net/ipv4/conf/$IFACE/log_martians # Registro de paquetes extraños
# (esto incluye paquetes suplantados, paquetes con ruta prefijada, paquetes
# redireccionados) pero sea cuidadoso con esto en servidores de web con
# mucha carga
# ahora protección de suplantación de ip
echo 1 > /proc/sys/net/ipv4/conf/$IFACE/rp_filter
# y finalmente algunas cosas más:
# Deshabilitar la aceptación de redireccionamiento de ICMP
echo 0 > /proc/sys/net/ipv4/conf/$IFACE/accept_redirects
echo 0 > /proc/sys/net/ipv4/conf/$IFACE/send_redirects
# Deshabilitar los paquetes de ruta prefijada
echo 0 > /proc/sys/net/ipv4/conf/$IFACE/accept_source_route
exit 0
</example>
<p>Una solución alternativa es crear un «script» de <tt>init.d</tt> y que se
ejecute en el arranque (utilizando <prgn>update-rc.d</prgn> para que se creen
los enlaces de <tt>rc.d</tt> apropiados).
<sect1 id="kernel-fw">Configurar características de cortafuegos
<p>Con objeto de tener capacidades de cortafuegos, bien para proteger el sistema
local u otros que estén <em>tras él</em>, es necesario compilar el núcleo con
capacidades de cortafuegos. El núcleo estándar de Debian 2.2 (también 2.2)
proporciona el cortafuegos <prgn>ipchains</prgn> de filtrado de paquetes; el
núcleo estándar de Debian 3.0 (núcleo 2.4) proporciona el cortafuegos
<prgn>iptables</prgn> (netfilter) de filtrado de paquetes con inspección del
<em>estado</em> de éstos. Distribuciones más antiguas de Debian necesitarían el
parche apropiado del núcleo (Debian 2.1 utiliza el núcleo 2.0.34).
<p>En cualquier caso, es bastante sencillo utilizar un núcleo diferente al
suministrado con Debian. Puede encontrar núcleos precompilados como paquetes que
puede instalar fácilmente en el sistema Debian. También puede descargar las
fuentes del núcleo utilizando el <package>kernel-source-<var>X</var></package> y
construir paquetes del núcleo personalizados usando <prgn>make-kpkg</prgn> del
paquete <package>kernel-package</package>.
<p>La configuración de cortafuegos en Debian se discute con más profundidad en
<ref id="firewall-setup">.
<sect1 id="limit-bindaddr">Deshabilitar asuntos de weak-end hosts
<!-- ARRÉGLEME: leo esto y no encuentro el sentido -->
<p>Los sistemas con más de una interfaz sobre redes diferentes pueden tener
los servicios configurados de forma que sólo estén ligados a una dirección IP
dada. Esto normalmente evita el acceso a servicios cuando son solicitados a
través de cualquier otra dirección. Sin embargo, esto no significa (aunque es un
error que incluso yo cometo) que el servicio esté ligado a una dirección
<em>hardware</em> dada (tarjeta de interfaz).
<footnote>
Para reproducir esto (ejemplo proporcionado por Felix von Leitner en la lista de
correo de bugtraq):
<example>
host a (eth0 connected to eth0 of host b):
ifconfig eth0 10.0.0.1
ifconfig eth1 23.0.0.1
tcpserver -RHl localhost 23.0.0.1 8000 echo fnord
host b:
ifconfig eth0 10.0.0.2
route add 23.0.0.1 gw 10.0.0.1
telnet 23.0.0.1 8000
</example>
<p>Parece, sin embargo, que no funciona con servicios ligados a 127.0.0.1;
podría necesitar escribir las pruebas utilizando «sockets» en modo «raw».</p>
</footnote>
<p>Esto no es un tema de ARP y no es una violación del RFC (esto es llamado
<em>weak end host</em> en
<url id="ftp://ftp.isi.edu/in-notes/rfc1122.txt"; name="RFC1122">,
sección 3.3.4.2).
Recuerde, las direcciones IP no tiene nada que ver con las interfaces físicas.
<p>En núcleos 2.2 (y anteriores) esto puede arreglarse con:
<example>
# echo 1 > /proc/sys/net/ipv4/conf/all/hidden
# echo 1 > /proc/sys/net/ipv4/conf/eth0/hidden
# echo 1 > /proc/sys/net/ipv4/conf/eth1/hidden
.....
</example>
<p>En núcleos posteriores esto puede arreglarse por alguna de las siguientes
formas:
<list>
<item>reglas de iptables.
<item>enrutado configurado de forma apropiada.
<footnote>
El hecho de que este comportamiento pueda cambiarse por medio del enrutado fue
descrito por Matthew G. Marsh en el hilo de bugtraq:
<example>
eth0 = 1.1.1.1/24
eth1 = 2.2.2.2/24
ip rule add from 1.1.1.1/32 dev lo table 1 prio 15000
ip rule add from 2.2.2.2/32 dev lo table 2 prio 16000
ip route add default dev eth0 table 1
ip route add default dev eth1 table 2
</example>
</footnote>
<item>parcheando el núcleo.
<footnote>
Hay algunos parches disponibles para este comportamiento según se describió en
un hilo de bugtraq en
<url id="http://www.linuxvirtualserver.org/~julian/#hidden";>
y <url id="http://www.fefe.de/linux-eth-forwarding.diff";>.
</footnote>
</list>
<p>A lo largo de este texto habrá muchas ocasiones en las que se mostrará cómo
configurar algunos servicios (sevidor sshd, apache, servicio de impresión...)
con objeto de tenerlos escuchando en cualquier dirección dada; el lector debería
tener en cuenta que, sin las correcciones dadas aquí, el arreglo no evitaría
accesos desde dentro de la misma red (local).
<footnote>
Un atacante podría tener muchos problemas para superar el acceso tras configurar
el enlace de la dirección IP, si no está en el mismo dominio (la misma red) que
el ordenador atacado. Si el ataque se produce a través de un enrutador podría
ser bastante difícil que las respuestas retornen a algún sitio.
</footnote>
<p>ARRÉGLEME: comentarios en bugtraq indican que hay un método específico de
Linux para enlazar con una interfaz dada.
<p>ARRÉGLEME: ¿Remitir un error contra netbase para que el arreglo del enrutado
sea un comportamiento estándar en Debian?
<sect1> Proteger contra ataques ARP
<p>Cuando usted no confíe en los otros ordenadores de su red (lo que debería
ser siempre el caso, porque es la actitud más segura) debería protegerse de los
diferentes ataques ARP existentes.
<p>Como usted sabe el protocolo ARP se utiliza para enlazar direcciones IP con
direcciones MAC. (vea <url name="RFC826"
id="ftp://ftp.isi.edu/in-notes/rfc826.txt";> para obtener todos los
detalles). Cada vez que envía un paquete a una dirección IP se hace una
resolución arp (mirando primero en la caché de ARP local y luego si la IP no
está presente en la caché, por medio de una solicitud de arp en modo
«broadcast») para encontrar la dirección hardware del destino. Todos los ataques
ARP tienen como objetivo engañar a su ordenador haciéndole creer que la
dirección IP del ordenador B está asociada a la dirección MAC del ordenador del
intruso. Luego cada paquete que usted quiera enviar a la IP asociada al
ordenador B se enviará al ordenador del intruso...
<p>
Esos ataques (envenenamiento de caché en servidores DNS, suplantación ARP...)
permiten al atacante husmear en el tráfico incluso en redes conmutadas, para
secuestrar conexiones con facilidad, desconectar cualquier ordenador de la
red... Los ataques ARP son poderosos y sencillos de implementar, y existen
varias herramientas, tales como <prgn>arpspoof</prgn> del paquete
<package>dsniff</package> o
<url name="arpoison"id="http://arpoison.sourceforge.net/";>.
<p>Sin embargo, siempre hay una solución:
<list>
<item>Utilizar una caché de arp estática. Usted puede configurar entradas
«estáticas» en su caché de arp con:
<example>
arp -s host_name hdwr_addr
</example>
<p>Estableciendo entradas estáticas para cada ordenador importante de su red,
asegura que nadie creará/modificará una entrada (falsa) para estos ordenadores
(las entradas estáticas no expiran y no pueden modificarse) y se ignorarán las
solicitudes de arp falsas.
<item>Detectar el tráfico de ARP sospechoso. Puede utilizar
<package>arpwatch</package>, <package>karpski</package> o un IDS (N. del T.,
sistema de detección de intrusos) más general, que pueda detectar tráfico arp
sospechoso (<package>snort</package>, <url name="prelude"
id="http://www.prelude-ids.org";>...).
<item>Implementar filtrado de tráfico IP validando las direcciones MAC.
</list>
<sect id="snapshot">Hacer una imagen del sistema
<p>Antes de poner el sistema en producción podría hacer una imagen del sistema
completo. Esta imagen podría utilizarse en el caso de que el sistema resultara
comprometido (vea <ref id="after-compromise">). Debería actualizarla siempre que
actualice el sistema, especialmente si actualiza a una nueva versión de Debian.
<p>Para esto puede usar un medio extraíble y escribible que pueda configurarse
como de sólo lectura, podría ser un disquete (protegido contra la escritura tras
usarlo), un CD en una unidad de CD-ROM (podría utilizar un CD-ROM reescribible
de forma que podría incluso mantener copias de seguridad de md5sums en
diferentes fechas), o un disco USB o tajeta MMC (si su sistema puede acceder a
ellos y pueden protegerse contra la escritura).
<p>El siguiente «script» crea tal imagen:
<example>
#!/bin/bash
/bin/mount /dev/fd0 /mnt/floppy
if [ ! -f /usr/bin/md5sum ] ; then
echo "Cannot find md5sum. Aborting."
exit 1
fi
/bin/cp /usr/bin/md5sum /mnt/floppy
echo "Calculating md5 database"
>/mnt/floppy/md5checksums.txt
for dir in /bin/ /sbin/ /usr/bin/ /usr/sbin/ /lib/ /usr/lib/
do
find $dir -type f | xargs /usr/bin/md5sum >>/mnt/floppy/md5checksums-lib.txt
done
echo "post installation md5 database calculated"
if [ ! -f /usr/bin/sha1sum ] ; then
echo "Cannot find sha1sum"
else
/bin/cp /usr/bin/sha1sum /mnt/floppy
echo "Calculating SHA-1 database"
>/mnt/floppy/sha1checksums.txt
for dir in /bin/ /sbin/ /usr/bin/ /usr/sbin/ /lib/ /usr/lib/
do
find $dir -type f | xargs /usr/bin/sha1sum >>/mnt/floppy/sha1checksums-lib.txt
done
echo "post installation sha1 database calculated"
fi
/bin/umount /dev/fd0
exit 0
</example>
<p>Observe que el binario de md5sum (y sha1sum, si está disponible) se sitúa en
la disquetera para que pueda utilizarse más tarde en la comprobación de binarios
del sistema (sólo en caso de tener un troyano). Sin embargo, si quiere
asegurarse de que está ejecutando un binario legítimo, podría querer compilar
una copia estática del binario de md5sum y utilizarlo (para evitar una
interferencia de la biblioteca libc con troyano, con el binario) o utilizar la
imagen de Md5sums únicamente para un entorno limpio tal como un CD-ROM de
rescate on un «Live-CD» (para evitar interferencias de un núcleo con
troyano). No me canso de insistir: si usted está en un sistema comprometido, no
puede confiar en sus salidas, vea <ref id="after-compromise">.
<p>La imagen no incluye los archivos de <file>/var/lib/dpkg/info</file> los
cuales incluyen los «hashes» md5 de los paquetes instalados (en archivos que
terminan en <file>.md5sums</file>). Usted podría copiar también esta información
conjuntamente, sin embargo debería notar:
<list>
<item>los archivos de md5sums incluyen el md5sum de todos los archivos
proporcionados por los paquetes Debian, no sólo los binarios del sistema. Como
consecuencia, la base de datos es mayor (5Mbs frente a 600 kbs en un sistema
Debian GNU/Linux con sistema gráfico y unos 2.5 Gbs de software instalado) y no
cabrá en un medio extraíble pequeño (como un disquete).
<item>no todos los paquetes de Debian proporcionan md5sums para los archivos
instalados puesto que no es (actualmente) obligatorio según las
directrices. Observe, sin embargo, que usted puede generar los md5sums para
todos los paquetes utilizando <package>debsums</package> después de que haya
finalizado la instalación del sistema:
<example>
# debsums --generate=missing,keep
</example>
</list>
<p>Una vez que haya hecho la imagen debería asegurarse de poner el medio como de
sólo lectura. Entonces puede almacenarlo como copia de seguridad o ponerlo en la
unidad y utilizarlo como referencia para programar una tarea con <prgn>cron</prgn>
que se ejecute todas las noches y compare los md5sums originales con aquellos de
la imagen.
<p>Si no quiere configurar una comprobación manual, siempre puede utilizar una
de las disponibles sobre integridad del sistema, que hará esto y más, para
obtener más información, por favor, lea <ref id="periodic-integrity">.
<sect>Otras recomendaciones
<!-- PORHACER: ¿Quitar esto? -->
<sect1>No utilizar software que dependa de svgalib
<p>
SVGAlib es muy bueno para los amantes de la consola como yo, pero en el pasado
se probó varias veces que es muy inseguro. Salieron «exploits» (N. del T.,
código escrito con el fin de aprovecharse de algún error de programación para
obtener ciertos privilegios en el sistema) contra <prgn>zgv</prgn>, y era muy
sencillo convertirse en superusuario. Intente evitar, siempre que sea posible,
la utilización de programas que dependan de SVGAlib.
<!-- ARRÉGLEME: ¿mover esto a la sección de directrices, si alguna vez hay una? -->
<!--
Traducción terminada el domingo 5 de febrero de 2006 por Manuel Parrilla Sánchez.
Empiezo con la intención de revisar el documento corregido, pero hay tantas
diferencias con la versión actual en inglés, con secciones cambiadas de sitio,
etc. que creo que no supone mucho más esfuerzo traducir el nuevo documento en inglés
completo.
-->
Reply to: