<!doctype debiandoc system>

<!--
# TODO list:
# - Pointers to other security-related documents, jfs
# - There was a 'useful software section' why was it removed? jfs
# - A checklist to hardening the Debian system (summarising all
#   this info in a page), there were many good ideas in the
#   debian-security's Nov/Dec 2000 threads
# - Information on debian firewalling and what/how does it change
#   from other distributions
-->

<book>

<titlepag>
<!-- Title information -->
<title>COMO-Asegurar-Debian
<author>
<name>Alexander Reelsen. Traducción: Antonio Álvarez Platero</name>
<email>ar@rhwd.net (Alexander Reelsen)</email>

<version>v1.1
<date>Thu,  7 Dec 2000 19:10:13 +0100

<abstract>
Este documento describe el proceso de asegurar y fortalecer la instalación que Debian deja por defecto
</abstract>

<copyright> 
<copyrightsummary>Copyright (c) 2000 Alexander Reelsen, distribuido bajo los términos de la licencia de documentación libre de GNU. Este documento se distribuye con la esperanza de que pueda ser útil, pero SIN NINGUNA GARANTÍA.
</copyrightsummary>

</titlepag>

<!-- Table of contents -->
<toc>

<!-- Begin the document -->

<chapt>Introducción
<p>
Una de las cosas más dificultosas a la hora de escribir documentos sobre seguridad es que cada caaso es único. Dos cosas a las que deberá prestar atención son el entorno de amenaza y las necesidades de seguridad del sitio individual, del servidor o de la red. Por ejemplo, las necesidades de seguridad de un usuario doméstico son totalmente distintas a las de la red de un banco. Mientras que la primera amenaza a la que necesita enfrentarse un usuario doméstico es a la de un cráker del tipo script kiddie, la red de un banco tiene que preocuparse de ataques directos. Además, el banco tiene que proteger los datos de sus clientes con precisión aritmética. En resumidas cuentas, cada usuario tiene que sopesar el equilibrio entre usabilidad y seguridad/paranoya.
<p>
Note que este COMO solamente cubre temas relacionados con software. El mejor software del mundo no es capaz de darle protección si cualquiera puede acceder físicamente a la máquina. Puede colocarla bajo su mesa, o puede colocarla en un bunker acorazado con un ejército delante. Sin embargo, el ordenador de sobremesa puede ser mucho más seguro (desde el punto de vista del software) que uno protegico físicamente si el de sobremesa está correctamente configurado y el software de la máquina protegida está repleto de agujeros de seguridad. Obviamente, debe considerar los dos aspectos. # Además, este documento símplemente le da una visión general de lo que puede usted hacer para acrecentar la seguridad de su intalación de Debian GNU/Linux. Muchas partes de este COMO se pueden aplicar a otras distribuciones.

# Además, este documento símplemente le da una visión general 
#de lo que puede usted hacer para acrecentar la seguridad de 
#su intalación de Debian GNU/Linux. Muchas partes de este COMO
# se pueden aplicar a otras distribuciones.


<p>
Si tiene algún comentario, sugerencia o añadido, mándelo al <url
name="the author" id="mailto:ar@rhwd.net">y se incorporarán a este COMO. 
<sect>Bajarse el COMO
<p>Puede descargar o ver la última versión del COMO Asegurar Debian en los siguientes formatos:
###ESTO NO FUNCIONARÁ HASTA QUE NO TENGA SITIO DONDE PONERLO
<list>
<item><url name="Solotexto" id="http://joker.rhwd.de/doc/Securing-Debian-HOWTO/Securing-Debian-HOWTO.txt">
<item><url name="HTML" id="http://joker.rhwd.de/doc/Securing-Debian-HOWTO/Securing-Debian-HOWTO.html">
<item><url name="HTML, tarred and gzipped" id="http://joker.rhwd.de/doc/Securing-Debian-HOWTO/Securing-Debian-HOWTO.tar.gz">
<item><url name="SGML" id="http://joker.rhwd.de/doc/Securing-Debian-HOWTO/Securing-Debian-HOWTO.sgml">
</list>

<sect>Notas sobre organización/comentarios
<p>
Ahora la parte oficial. Hasta ahora, he escrito la mayoría de los párrafos de este COMO, pero en mi opinión esto no debería ser así por siempre. Crecí y vivo con el software libre, es parte de mis usos cotidianos y me imagino que de los suyos también. Animo a todo el mundo a enviarme opiniones, ideas, añadidos y cualquier otra sugerencia que puedan tener. 

Si cree que puede mantener una sección o párrafos mejor que yo, escríbamelo y le daré las gracias por ello. Sobre todo si encuentra una sección marcado como ARRÉGLAME, lo que significa que no he tenido tiempo aún de hacerlo yo, o que no poseo los conocimientos necesarios sobre el tema; en este caso envíeme un mensaje electrónico inmediatamente.

El tema de este COMO deja claro que es importante mantenerlo al día, y que usted puede ayudar a mantener la calidad de este COMO, así que no dude en hacerlo.

<sect>Conocimientos previos
<p>
La instalación de Debian GNU/Linux no es difícil y usted debería de haber podido realizarla. Si posee usted conocimientos sobre Linux u otros Unices y está usted un poco familiarizado con apectos de seguridad básica, entender este COMO le será más fácil ya que no puedo explicar cada detalle de cada característica (si así lo fuese esto sería un libro en vez de un COMO).

<sect>Por hacer
<p>
<list>
<item>suidmanager/dpkg-statoverrides
<item>lpr y lprng
<item>Desactivar las cosas IP de gnome
<item>LKM, linux kernel modules, los malos y los buenos
</list>


<sect>Reconocimientos
<p>
<list>
<item>Alexander Reelsen escribió el documento original
<item>Robert van der Meulen con los párrafos sobre quotas y muchas buenas ideas
<item>Ethan Benson corrigió el párrafo de PAM y dio buenas ideas
<item>Todos los que me animaron a escribir este COMO
<item>Todo el proyecto Debian
</list>



<chapt>Capítulo 2. Antes y durante la instalación

<sect>Escoja una contraseña para la BIOS
<p>
Antes de instalar cualquier sistema operativo en su ordenador, establezca una contraseña en la BIOS y cambie la secuencia de arranque de manera que deshabilite el arranque desde un disco flexible. De otra forma un cracker sólamente necesitará un disco de arranque para acceder a su sistema completo.
<p>
Desabilitar el arranque sin contraseña es una idea aún mejor. Ésto puede ser muy efectivo si tiene un servidor, puesto que no se rearrancan muy a menudo. El punto negativo de esta última táctica está en el hecho de que reiniciar requiere intervención humana, lo caul puede causar problemas si la máquina no está fácilmente accesible.

<sect>Escoja un esquema inteligente de particiones
<p>
Un esquema inteligente de particiones depende de cómo se use la máquina. Una regla fija es la de ser bastante liberal con sus particiones y prestar atención a los siguientes factores:

<list>
<item>Toda partición en la que el usuario tenga permisos de escritura debería ser una partición separada, por ejemplo, /home y /tmp. Esto reduce el riesgo de un ataque por denegación de servicio al llenar su punto de montaje"/" y hacer el sistema inutilizable. (Nota: Esto no es estríctamente verdadero ya que hay un espacio reservado para root que un usuario normal no puede rellenar).

<item>Cualquier partición que pueda fluctuar, por ejemplo, /var (sobre todo /var/log). En un contexto Debian debería crear /var un poco más grande de lo normal porque los paquetes que descargue (la caché de apt) se guardan en /var/apt/cache/archives.

<item>Cualquier partición en la que quiera instalar software que no sea de la distribución.
Según la File Hierarchy Standard esto se encuentra en /opt o en /usr/local. Si estas particiones están separadas, no se borrarán si reinstala.
</list>


<sect>Establezca una contraseña para el usuario root
<p>
La morma más básica para tener un sistema seguro es establecer una buena contraseña para root.


<sect>Active las shadow passwords y las MD5 passwords
<p>
Al final de la instalación, se le preguntará si se debe habilitar shadow passwords. Conteste sí a la pregunta, y las contraseñas se guardarán en el fichero /etc/shadow. Solamente el usuario root y el grupo shadow tienen permiso de lectura para este fichero, de manera que ningún usuario podrá obtener una copia de este fichero con la intención de aplicarle un programa de forzado de contraseñas. Puede cambiar entre shadow passwords y contraseñas normales en cualquier momento usando 'shadowconfig'. Además, durante la instalación, se le pregunta si quiere usar MD5 passwords. Generalmente es una muy buena idea ya que permite contraseñas más largas y un mejor cifrado.


<sect>Ejecute el número mínimo de servicios necesarios
<p>
No debería instalar servicios que no sean necesarios. Cada servicio instalado introduce agujeros de seguridad nuevos y, quizás, no obvios, en la máquina. Si realmente quiere tener algunos servicios que usa con poca frecuencia utilice los update.commands, por ejemplo, 'update-inetd' para quitarlos del proceso de inicio.

# Esta sección necesita una lista de servicios y qué hacen y el riesgo que conllevan, ya que los principiantes no tienen ni idea.



<chapt>Postinstalación

<sect>Establezca una contraseña para LILO o GRUB
<p>
Cualquiera puede conseguir con facilidad una root-shell y cambiar sus contraseñas al introducir "(nombre-de-imagen-de-arranque) init=/bin/sh" en el prompt de inicio. Tras cambiar las contraseñas e reiniciar el sistema, esa persona tiene acceso ilimitado como root y puede hacer lo que quiera con el sistema. Después de ésto, usted ya no tendrá acceso como root al sistema, puesto que no conoce la contraseña.
<p>
Para asegurarse que ésto no pueda ocurrir, debería establecer una contraseña para el cargador del sistema operativo. 

Puede elegir entre una contraseña global o una contraseña para una imagen en concreto.
<p>
Para LILO necesita modificar el fichero de configuración /etc/lilo.conf y añadir las líneas "password" y "restricted", como en el ejemplo siguiente.
<example>
image=/boot/2.2.14-vmlinuz
   label=Linux
   read-only
   password=hackme
   restricted
</example>

<p>
Una vez hecho, vuelva a ejecutar lilo. La omisión de la línea "restricted" hace que lilo pida siempre una contraseña, sin importar si se le han pasado parámetros. Cuando añada una contraseña, asegúrese de que solamente el usuario root pueda leer el fichero de configuración de lilo, es decir, chmod 600 /etc/lilo.conf 
### comentario: si esto es así por omisión en Debian dílo o quita esto, jfs
<p>
Si usa GRUB en vez de LILO, modifique el fichero /boot/grub/menu.lst y añada las dos líneas siguientes al comienzo. Esto establecerá una contraseña de arranque y arrancará la opción por omisión después de tres segundos:

<example>
timeout 3
password hackme
</example>


<sect>No permita el arranque desde disco flexible
<p>
El MBR por omisión en Debián antes de la versión 2.2 no actuaba como un master boot record corriente y dejaba abierto un método para forzar con facilidad la entrada al sistema:
<list>
<item>Pulse Mayúsculas en el arranque y aparece un prompt MBR
<item>Después, pulse F y su sistema arrancará desde un disco flexible. Lo cual puede usarse para obtener acceso como root al sistema.
</list>

Este comportamiento se puede cambiar introduciendo:

<tt>lilo -b /dev/hda</tt>

Ahora LILO se pone en el MBR. También se puede conseguir esto añadiendo
"boot=/dev/hda" a lilo.conf. Hay otra solución que desabilitará el prompt del mbr completamente:

<tt>install-mbr -i n</tt>
# ¿es ésta  install-mbr /dev/hda? jfs

# # comprueba que realmente esto es cierto para 2.2 o ¿era 2.1?
INFO: los discos de arranque de Debian 2.2 NO instalan mbr sino sólo LILO.

<sect>Monte las particiones adecuadamente
<p>
Cuando monta una partición ext2 tiene algunas opciones adicionales a aplicar a la llamada de montaje o a /etc/fstab. Por ejemplo, esta es mi entrada en fstab para una partición /tmp:
<example>/dev/hda7    /tmp    ext2    defaults,nosuid,noexec,nodev    0    2</example>
<p>
Se puede ver la diferencia en la sección de opciones. La opción <tt>nosuid</tt> ignora los bits <tt>setuid</tt> y <tt>setgid</tt>, mientras que <tt>noexec</tt> prohibe la ejecución de cualquier programa en ese punto de montaje, y <tt>nodev</tt> ignora los dispositivos. Suena genial, pero
<list>
<item>solamente es aplicable a sistema de ficheros ext2
<item>se puede saltar fácilmente
</list>
La opción <tt>noexec</tt> evita que los binarios puedan ser ejecutados directamente, pero se puede saltar 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 script kiddies tienen exploits que intentan crear y ejecutar ficheros en /tmp. Si no tienen idea no saldrán de aquí.

<sect>PAM - Pluggable Authentication Modules
<p>
PAM permite a los administradores de sistemas elegir cómo las aplicaciones autentifican al usuario. Observe que PAM no hace nada a menos que una aplicación haya sido compilada con soporte para PAM. La mayoría de las aplicaciones que se entregan con Debian 2.2 tienen este soporte incorporado. Observe, también, que Debian no tenía soporte de PAM antes de la versión 2.2. Hay un fichero de configuración en /etc/pam.d para cada aplicación. PAM le ofrece la posibilidad de pasar varias etapas de autentificación de una vez sin que el usuario lo sepa. Puede autentificar contra una base de datos Berkeley y la contraseña  y el usuario solamente entra si se autentifica correctamente dos veces. 
<p>Con PAM, puede restringir muchas cosas, de la misma manera que puede abrir las puertas de su sistema. Así que tenga cuidado. La línea típica de conficuración tiene como tercer elemento un campo de control. Generalmente debería establecerse como "requisite", que devuelve un fallo de login si un módulo falla. La primera cosa que me gusta hacer es añadir soporte MD5 para las aplicaciones PAM, ya que esto ayuda a protegerse contra los ataques de diccionario. Las siguientes dos líneas deberían añadirse a todos los ficheros en /etc/pam.d/ que garantizan el acceso a la máquina, como 'login' y 'ssh'.

<example>
password   required     pam_cracklib.so retry=3 minlen=12 difok=3
password   required     pam_unix.so use_authtok nullok md5
</example>

Entonces, ¿qué función tiene este mito? La primera línea carga el módulo PAM cracklib, que proporciona fuerza de chequeo a las contraseñas, pide una nueva contraseña con una longitud mínima de 12 caracteres, una diferencia de al menos 3 caracteres con la antigua contraseña, y permite tres intentos. La segunda línea introduce el módulo de autentificación estándar con contraseñas md5 y permite una contraseña de longitud cero. La directiva use_authtok es necesaria para transmitir la contraseña desde el módulo anterior.

Para asegurarse de que el usuario root puede entrar en el sistema solamente desde terminales locales, se debería habilitar la siguiente línea en /etc/pam.d/login: 
<tt>auth reguisite pam_securetty.so</tt>. 

Después debería añadir las terminales desde las que el usuario root puede acceder al sistema en el fichero /etc/security/access.conf. En último lugar, pero no por ello menos importante, debería habilitar la siguiente línea, si quiere establecer límites a los usuarios:
<tt>session required pam_limits.so</tt>.

Esto restringe los recursos del sistema a los usuarios autorizados. Por ejemplo, podría restringir el número de login concurrentes que pueden tener los usuarios.

Modifique, ahora, el fichero /etc/pam.d/passwd y cambie la primera línea. Debería añadir la opción "md5" para usar contraseñas md5, cambiar la longitud mínima de 4 a 6 (o más) y establecer una longitud máxima, si lo desea. La línea resultante se parecería a esta: 
<tt>password required pam_unix.so nullok obscure min=6 max=11 md5</tt>.

 Si queremos proteger "su" de manera que solo alguna gente pueda usarlo para convertirse en root en su sistema, necesitamos añadir un grupo "wheel" nuevo al sistema (que es el método más limpio, ya que ningún fichero tiene todavía ese permiso de grupo). Añada root a este grupo y los otros usuarios que podrán hacer "su" al usuario root. Luego, añada la siguiente línea a /etc/pam.d/su: 

<tt>auth requisite pam_wheel.so group=wheel debug</tt>. 

Esto asegura que solamente los miembros del grupo wheel pueden usar su para convertirse en root. Si otros lo intentan, obtendrán un mensaje diciéndoles que el acceso está prohibido.

Por último, cree /etc/pam.d/other e introduzca las siguientes líneas:

<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>

Estas líneas le darán una buena configuración por defecto para todas las aplicaciones que soportan PAM (el acceso se niega por defecto)

<sect>El fichero limits.conf
<p>
Realmente debería echar una mirada seria a este fichero. Aquí puede definir los límites de recursos para usuarios. Si usa PAM, este fichero no es válido y debería usar /etc/security/limits.conf.
<tt>ARRÉGLAME: Get a good limits.conf up here</tt>

<sect>Personalize /etc/inetd.conf
<p>
Debería parar todos los servicios que no sean necesarios en su sistema, como echo, discard, daytime, time, talk, ntalk y los servicios r- (rsh, rlogin y rcp), considerados ALTAMENTE inseguros (utilice ssh). Tras desabilitar los anteriores, debería comprobar que realmente necesita el demonio inetd. Mucha gente prefiere usar demonios en vez de llamar a los servicios via inetd. Existen posibilidades de Denegación de Servicios contra inetd, lo cual puede incrementar enormemente la carga de la máquina. Si aún quiere hacer correr algún tipo de servicio inetd, cámbiese a un demonio inet más configurable, como xinetd o rlinetd.
<p>
Puede conseguir ésto modificando inetd.conf directamente, aunque Debian ofrece una alternativa: <tt>update-inetd</tt>. Puede quitar el demonio telnet haciendo:
<example>
# /usr/sbin/update-inetd --disable telnet
# /etc/init.d/inetd restart
</example>


<sect>Modifique /etc/login.defs
<p>
El siguiente paso es modificar la configuración y acción básicas sobre el login de usuarios.

<tt>FAIL_DELAY          10</tt>

Esta variable debería establecerse con un valor más alto para hacerla más dura al usar la terminal para entrar al sistema usando la fuerza bruta. Si se teclea una contraseña errónea, tiene que esperar 10 segundos para obtener una nuevo prompt de login, que es un consumo bastante grande de tiempo si está probando contraseñas. Preste atención al hecho de que ésto es inútil si se usa un programa que no sea getty, como puede ser mingetty.

<tt>FAILLOG_ENAB        yes</tt>

Si habilita esta variable, los login fallidos quedarán registrados. Es importante seguirles la pista para coger a alguien que intenta un ataque de fuerza bruta.

<tt>LOG_UNKFAIL_ENAB    yes</tt>

Si establece la variable FAILLOG_ENAB a yes, también debería darle el valor de yes a esta variable. Registrará los nombres de usuario desconocidos si el login falla. Si hace ésto asegúrese de tener los permisos adecuados (por ejemplo 640, con un grupo apropiado como adm), porque los usuarios a menudo introducen accidentalmente su contraseña como nombre de usuario y no queremos que otros lo vean.

<tt>SYSLOG_SU_ENAB      yes</tt>

Ésto habilita el registro de los intentos de su en syslog. Bastante importante en máquinas serias, pero tenga en cuenta que tambin puede originar conflictos de privacidad.

<tt>SYSLOG_SG_ENAB      yes</tt>

Lo mismo que SYSLOG_SU_ENAB, pero aplicable a la llamada sg.

<tt>MD5_CRYPT_ENAB      yes</tt>

Como ya fue expuesto antes, las contraseñas md5 sum reducen en gran medida el problema de los ataques con diccionarios, porque es muy difícil realizar un crack contra contraseñas MD5. Al menos es difícil hacerlo con éxito. Si usa usted slink, lea los documentos sobre MD5 antes de habilitar esta opción. Si no lo hace estará establecido en PAM.

<tt>PASS_MAX_LEN        50</tt>

Si se han activado las contraseñas MD5 en su configuración PAM, entonces esta variable debería tener el mismo valor que se usó en aquella.


<sect>Modifique /etc/ftpusers
<p>
Este fichero contiene una lista de los usuarios a los que no les está permitido entrar en el servidor usando ftp. Use solamente este fichero en el caso de que realmente quiera permitir ftp (lo cual no es recomendable en general, porque usa contraseñas en claro). Si su demonio soporta PAM, puede usarlo para permitir o negar ciertos servicios a los usuarios.

<sect>Uso de tcp wrappers
<p>
Los TCP wrappers fueron desarrollados cuando no había filtros de paquetes y era necesario tener control de acceso. Los TCP wrappers le dan la posibilidad de permitir o denegar un servicio para un host o para un dominio y define unas reglas de permiso y denegación por defecto. 

Si quiere más información, consulte la página del manual de hosts_access(5).

Ahora, aquí tiene un pequeño truco, probablemente el sistema más pequeño de detección de intrusiones disponible. En general debería tener una política de cortafuegos decente como primera línea de defensa y tcp wrappers como segunda línea. Un pequeño truco es establecer una orden spawn en /etc/hosts.deny que envíe un mensaje a root siempre que un servicio denegado dispare los wrappers:

<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\
" | /bin/mail -s "Connection to %d blocked" root)
</example>

<em>Precaución</em>: El ejemplo de arriba se puede adaptar para usar como DoS (Denegación de Servicio) haciendo muchas conexiones en un período corto de tiempo. Muchos mensajes electrónicos implican mucha Entrada/Salida de ficheros mandando solamente unos cuantos paquetes.

#¿Podría este ejemplo ser más interesante?
#Se relaciona también con la sección siguiente  jfs

#<example>
#ALL: ALL: spawn ( \
#  /usr/local/sbin/send_syslog %u %c %d )
#</example>
#  Whit send_syslog as:
##!/usr/bin/perl -w
#
#use Sys::Syslog qw(:DEFAULT setlogsock);
#
#$user=shift(@ARGV) || 'unkown';
#$host=shift(@ARGV) || 'unkown';
#$service=shift(@ARGV) || 'unkown';
#setlogsock('unix');
#openlog("alert",'', 'user');
#syslog('warning', 'Connection from %s at %s to %s blocked.', ($user, $host, $service) );
#closelog();
#
#exit 0;

<sect>La importacia de los registros y las alertas
<p>Un tema importante en un sistema seguro es cómo se tratan los registros y las alertas. Es muy fácil ver que, incluso si un sistema está perfectamente configurado y supuestamente es seguro al 99%, si ese 1% llega a ocurrir y no hay establecidas medidas de seguridad para, en primer lugar, detectarlo y, en segundo lugar, lanzar alarmas, el sistema no es en absoluto seguro.

<sect1>Configurar dónde se mandan las alertas
<p>Debian viene con una configuración de syslog estándar (en /etc/syslog.conf) que registra los mensajes en los ficheros adecuados dependiendo del sistema. Si tiene la intención de mantener un sistema seguro debería ser precavido de a dónde se mandan estos mensajes de manera que no pasen inadvertidos.
<p>Por ejemplo, mandar mensajes a la consola es una configuración interesante para muchos sistemas en producción. Pero para muchos de esos sistemas es también importante añadir una nueva máquina que sirva de almacén de registros (recibe registros de todas las demás máquinas).

<p>Se debería considerar también el correo de root; muchos controles de seguridad (como <tt>snort</tt> mandan alertas al buzón de root. Este buzón normalmente apunta al primer usuario que se creó en el sistema (compruebe <tt>/etc/aliases</tt>). Asegúrese de mandar el correo de root a algún lugar donde se pueda leer (tanto local como remótamente). 

#Nota: Sería interesante contar como manda un sistema Debian tramas SNMP 
#relacionado con problemas de seguridad jfs #
comprueba: snmptraglogd, snmp y snmpd

<sect1>Usar un host para registro
<p>Un host de registro es un host que recoge datos syslog remotamente de la red. Si una de sus máquinas es craqueada, el intruso no puede cubrir sus huellas, a menos que hackee el host de registro también. Así, el host de registro debería ser especialmente seguro. Convertir una máquina en host de registro es simple. Simplemente lance syslodg con 'syslogd -r' y nace un nuevo host de registro. Seguidamente, configure las otras máquinas para que envíen datos al host de registro. Añada una entrada como ésta a <tt>/etc/syslog.conf</tt>
<p>

<example>facility.level            @your_loghost</example>

facility debería ser uno de estos: authpriv, cron, daemon, kern, lpr, mail, news,
syslog, user, uucp y local1 hasta local7. level debería ser alert, crit, err,
warning, notice, info debug. Si quiere registrar todo en remoto, simplemente escriba:

<example>*.*                       @your_loghost</example>

en su syslog.conf.  Hacer registros tanto remota como localmente es la mejor solución (el atacante puede asumir que ha cubierto sus huellas tras borrar los ficheros de registro locales). Vea la página del manual de syslog(3), syslogd(8) y syslog.conf(5) si quiere información adicional.

<sect1>Permisos de los ficheros de registro
<p>
No sólo es importante decidir cómo se usarán las alertas, sino que también quién tiene acceso a ellas, ésto es, quién puede leer o modificar los ficheros de registro (si no usamos un host de registro remoto). Así pues, en el caso de una intrusión, incluso con las alertas de seguridad en su sitio, si un atacante es capaz también de cambiarlas, la seguridad se reduce a la nada.

<p>
#Se debería explicar porqué tras la instalación esto no queda ya hecho, jfs

Algunos permisos de ficheros de registro no quedan perfectos tras la instalación. En primer lugar,  no es necesario que los usuarios normales puedan leer /var/log/faillog y /var/log/lastlog. En el fichero de lastlog podemos ver quién entró en el sistema por última vez y en faillog vemos un sumario de los logins fallidos. El autor recomienda hacer chmod 660 a ambos. Eche una breve mirada a sus ficheros de registro y decida con mucho cuidado qué ficheros de registro hace legíbles/escribibles para un usuario con un UID diferente a 0 o un grupo que no sea 'adm' o 'root'.

<p>
Quisiera enfatizar que los permisos de los ficheros de registro de apache son realmente deficientes debido al hecho de que el usuario apache es el propietario de los ficheros de registro de apache. Si un usuario consigue una shell con una puerta trasera en apache, puede quitar los ficheros de registro con facilidad. 
#Esto es bastante personal, EMHO, ya que se debe al hecho de que los 
#privilegios de root caen al arranque. Prefiero que un hacker borre los 
#ficheros de registro de un servicio a que borre todos los registros del 
#sistema. De todas maneras, esto se puede mejorar cambiando los permisos
# de usuario después de rotar.

<sect>Establecer una comprobación de setuid
<p>
Debian tiene un proceso cron que corre diariamente en <tt>/etc/cron.daily/standard</tt>. Este proceso ejecutará el script <tt>/usr/bin/chechsecurity</tt>, que guardará la información sobre estos cambios. 

# Qué hay por defecto para ésto en el paquete cron? jfs

<p>Para realizar esta comprobación debe establecer en <tt>/etc/checksecurity.conf</tt>
<example>
CHECKSECURITY_DISABLE="FALSE"
</example>


# ¿Se envía ésto a root? jfs

<sect>Uso de su
<p>
Si realmente necesita convertirse en el superusuario de su sistema, por ejemplo para instalar paquetes o para añadir usuarios, puede usar la orden <tt>su</tt> para cambiar su identidad. Debería intentar evitar cualquier login como usuario root y usar en su lugar su. Realmente la mejor solución es quitar su y cambiarse a sudo, ya que tiene más características que su. Sin embargo, su es mucho más usado en muchos otros Unixes.

<sect>Uso de sudo
<p>sudo permite al usuario ejecutar órdenes definidas bajo la identidad de otro usuario, incluso como root. Si el usuario se añade a /etc/sudoers y se autentifica correctamente, puede ejecutar órdenes que se han definido en /etc/sudoers. Las violaciones, tales como contraseñas incorrectas o intentos de ejecutar un programa para el que no tiene permisos, se registran y se envían por correo a root.

<sect>Uso de chroot
<p>
chroot es una de las posibilidades más potentes para restringir un demonio o un usuario u otro servicio. Simplemente imagine una cárcel alrededor de su objetivo, de la que el objetivo no puede escapar (en teoría, pero existen aún muchas condiciones que le permiten a uno escapar de esa cárcel). Si no confía en un usuario, puede crear un cambio de entorno de root para él. Ésto puede utilizar bastante espacio ya que necesita copiar todos los ejecutables que le sean necesarios, así como las librerías, dentro de la cárcel. Incluso si el usuario hace algo malicioso, el alcance del daño está limitado a la cárcel. Un buen ejemplo de este caso es si no se autentifica contra /etc/passwd, sino contra LDAP o MySQL. Así, su demonio ftp necesita un binario y quizás unas cuantas librerías. Un entorno chroot será una excelente mejora de seguridad si se conoce un nuevo exploit para este demonio ftp. Solamente será posible usar el exploit contra el UID del usuario del demonio ftp y nada más. Por supuesto, muchos otros demonios se pueden beneficiar también de ésto.

<p>
Una nota adicional, el BIND (el servicio de nombres) por defecto de Debian no viene con chroot, de hecho ningún demonio viene con chroot. Espero que esto cambie con la salida de woody.

<sect>Configuración de algunas características del núcleo
<p>
<tt>ARRÉGLAME - Content missing</tt>
Muchas características del núcleo se pueden modificar mientras están ejecutándose haciendo echo a algo en el sitema de ficheros /proc o usando sysctl. Al introducir <tt>sysctl -A</tt> puede ver lo que puede configurar y qué opciones hay. Solamente en casos extraños necesitará modificar algo aquí, pero puede incrementar la seguridad de esa manera también.

<tt>net/ipv4/icmp_echo_ignore_broadcasts = 0</tt>

Esto es un emulador de windows, porque actúa como windows cuando emite ping con el valor de 1. De otra manera, no hace nada.

<tt>net/ipv4/icmp_echo_ignore_all = 0</tt>

Si no quiere bloquear ICMP en su cortafuegos, habilite ésto.

<sect>No use software que dependa de svgalib
<p>
SVGAlib es muy bonito para los amantes de la consola como yo, pero se ha probado ya varias veces que es muy inseguro. Han salido exploits contra zgv, y era simple convertirse en root. Intente evitar el uso de programas SVGAlib siempre que sea posible.

<sect>Transferencias seguras de ficheros
<p>
Se pueden copiar ficheros de una manera segura de un host a otro usando 'scp', que se incluye en el paquete ssh. Funciona como rcp, pero está completamente cifrado, así que los chicos malos no pueden ni siquiera averiguar qué copia usted.

<sect>Uso de cuotas
<p>
Tener una buena política de cuotas es importante, ya que evita que los usuarios llenen el/los disco/s duro/s.
<p>
Puede usar dos sistemas diferentes de cuotas -cuotas de usuario y cuotas de grupo. Como probablemente habrá adivinado, las cuotas de usuario limitan la cantidad de espacio que un usuario puede utilizar; las cuotas de grupo hacen el equivalente con los grupos. Tenga esto en mente cuando decida el tamaño de las cuotas.

<p>
Hay unos cuantos puntos a considerar cuando se establece un sistema de cuotas:

<list>
<item>Mantenga las cuotas lo suficientemente pequeñas, de manera que los usuarios no acaparen su espacio de disco.
<item>Mantenga las cuotas lo suficientemente grandes, de forma que los usuarios no se quejen o que su cuota de correo les imposibilite la recepción de correo por un período largo de tiempo.
<item>Use cuotas para todas las áreas con permisos de escritura para los usuarios, tanto en /home,  como en /tmp.
</list>
<p>
Cada partición/directorio al que los usuarios tienen acceso con permiso de escritura debería tener cuotas establecidas. Así que busque esas particiones y directorios y calcule un tamaño de cuota adecuado. 

En primer lugar necesita comprobar si ha habilitado soporte de cuotas en el núcleo. Si no es así, necesitará recomplilarlo. Tras ésto, controle si el paquete 'quota' está instalado. Si no lo está, lo necesitará también.

Establecer cuotas para los respectivos sistemas de ficheros es tan fácil como modificar la configuración 'defaults' por 'defaults,usrquota' en su fichero /etc/fstab. Si necesita cuotas de grupo, sustituya 'usrquota' por 'grpquota'. También puede usar ambos. Luego cree ficheros vacíos quota.user y quota.group en las raíces de los sistemas de ficheros en los que quiere usar quota (por ejemplo, <tt>touch /home/quota.user</tt>,<tt> touch /home/quota.group</tt> para un sistema de ficheros /home). 

Reinicie quota haciendo <tt>/etc/init.d/quota stop;/etc/init.d/quota start</tt>. Ahora quota debería estár ejecutándose, y los tamaños de quota se pueden establecer.

Modificar cuotas para un usuario específico (digamos 'ref') se puede hacer con <tt>edquota -u ref</tt>. Las cuotas de grupo se pueden modificar con <tt>edquota -g (grupo)</tt>. 

Después establezca la cuota de software y de hardware según sus necesidades. 

Para obtener más información sobre cuotas, lea la página del manual sobre quota y el mini-howto de quota.

<sect>chattr/lsattr
<p>
Estas dos órdenes son muy útiles, pero funcionan solo con el sistema de ficheros ext2. Con 'lsattr' puede listar los atributos de un campo, y con 'chattr' puede cambiarlos. Note que los atributos no son la misma cosa que los permisos. Hay muchos atributos, pero aquí se mencionarán solo los más importantes para incrementar la seguridad. Hay dos flags que solamente las puede establecer el superusuario.

En primer lugar está la flag 'a'. Si se establece para un fichero, este fichero puede ser abierto solamente para añadir. Este atributo es útil para algunos ficheros en /var/log/, aunque podría considerar que fuesen quitados algunas veces debido la la rotación de scripts de registro. 

La segunda flag es 'i', en corto immutable. Si se establece en un fichero, no puede ser modificado o borrado o renombrado y no se creará ningún link hacia él. 

Si no quiere que los usuarios puedan mirar en sus ficheros de configuración puede establecer esta flag y quitar el permiso de lectura. Más aun, ésto puede darle un poco más de seguridad contra intrusos, porque el cracker puede confundirse al no ser capaz de borrar un fichero. De todas maneras, nunca debería asumir que el crácker es ciego. Después de todo, entró en su sistema.

<sect>Integridad de su sistema de ficheros
<p>
¿Está usted seguro de que el /bin/login en su disco duro es todavía el binario que instaló allí hace unos meses? ¿Qué pasaría si es una versión hackeada, que guarda la contraseña introducida en un fichero oculto o la envía por correo en claro por toda internet? 

El único método para tener alguna protección es comprobar sus ficheros cada día/hora/mes (yo prefiero cada día) comparando la vieja md5sum y la actual. Dos ficheros no pueden tener la misma md5.sum, de modo que anda sobre seguro aquí, excepto s alguien hackeó el algoritmo para crear md5sums en esa máquina; lo cual es, bueno, pegajoso. Realmente debería considerar que auditar sus binarios es muy importante, ya que es un modo fácil de reconocer los cambios en sus binarios. Las herramientas que comúnmente se usan para ésto son sXid, AIDE (Advanced Intrusion Detection Environment) y TripWire (no es libre, la nueva versión será GPL).

<p>
Más aún, puede intercambiar su paquete 'locate' con 'slocate'. slocate es una versión mejorada para seguridad de GNU locate. Cuando usa slocate, el usuario solamente ve los ficheros a los que él tiene acceso y puede excluir cualquier fichero o directorio del sistema.

<chapt>Asegurar los servicios que corren en su sistema

<sect>Asegurar ssh
<p>
Si todavía usa telnet en vez de ssh, debería dejar descansar este manual y hacer este cambio. Ssh se debería usar para logins remotos en vez de telnet. En una época en la que es fácil husmear el tráfico en internet y obtener contraseñas en claro, debería utilizar solamente protocolos que hagan uso de cifrado. Así que realize un <tt>apt-get install ssh</tt> en su sistema ahora mismo. Apremie a todos los usuarios del sistema a utilizar ssh en vez de telnet, o mejor incluso, desinstale telnet. Además debería evitar entrar al sistema utilizanso ssh como root y utilizar métodos alternativos de convertirse en root, como <tt>su</tt> o <tt>sudo</tt>. Finalmente, también debería modificarse el fichero de configuración de ssh, /etc/ssh/ssh_config, para incrementar la seguridad: 

<tt>PermitRootLogin No</tt>. 

Intente no permitir Root Login siempre que sea posible. Si alguien quiere convertirse en root vía ssh, ahora se necesitarán dos login y la contraseña de root no podrá obtenerse usando fuerza bruta vía SSH. 

<tt>Listen 666</tt> 

Cambie el puerto de escucha de manera que el intruso no pueda estar completamente seguro de si está corriendo un demonio sshd. 

<tt>PermitEmptyPasswords no</tt> 

Las contraseñas en blanco convierten en broma la seguridad de un sistema.

<tt>AllowUsers alex ref</tt>

Permita que solamente ciertos usuarios tengan acceso vía ssh a esta máquina. 

<tt>AllowGroups wheel admin</tt> 

Permita que solamente los miembros de ciertos grupos tengan acceso vía ssh a esta máquina. AllowGroups y Allow Users tienen directivas equivalentes para denegar el acceso a una máquina. Predeciblemente, se llaman "DenyUsers" y "DenyGroups".

<tt>PasswordAuthentication yes</tt> 

Queda completamente a su elección lo que usted quiera hacer. Es más seguro permitir el acceso a la máquina solamente a usuarios con claves ssh en el fichero ~/.ssh/authorized_keys. Si así lo quiere, déle el valor "no". 

Como nota final, asegúrese que estas directivas son de un fichero de configuración de OpenSSH. Ahora mismo hay tres demonios SSH usados habitualmente, ssh1, ssh2 y el OpenSSH de la gente de OpenBSD. Ssh1 fue el primer demonio ssh y sigue siendo el más usado (hay rumores de que existe incluso un port a windows). Ssh2 tiene muchas ventajas sobre ssh1, pero no se distribuye con una licencia de código abierto. OpenSSH es un demonio complétamente libre que soporta tanto ssh1 como ssh2. La versión instalada en Debian cuando se escoge el paquete 'ssh' es OpenSSH.

<sect>Dése cuenta de la inseguridad de X en red
<p>
Hoy día más y más empresas usan las terminales-X cuando necesitan un servidor para muchas estaciones de trabajo. Ésto puede ser peligroso, porque necesita permitir que un servidor de ficheros conecte con los clientes (el servidor X, desde el punto de vista de X. X intercambia la definición de cliente y servidor). Si sigue la (muy mala) sugerencia de muchos documentos, teclea <tt>xhost +</tt> en su máquina. Esto permite conectar con su sistema a cualquier cliente X. Para tener una seguridad ligeramente mejor, puede usar la orden <tt>xhost +hostname</tt> en vez de la anterior para permitir accesos desde hosts específicos. 

Una solución mucho más segura es usar ssh para hacer de túnel para X y cifrar la sesión completa. Ésto se hace automáticamente cuando se hace ssh a otra máquina. Por supuesto, incluso ésto se puede desabilitar en el fichero /etc/ssh/ssh_config. 

Para una mejor seguridad, si no necesita acceso a X desde otras máquinas, desabilite el enlace con tcp puerto 6000 tecleando simplemente:

<tt>startx -- -nolisten tcp</tt>

<sect>El asunto lpd y lprng
<p>
Imagine que llega al trabajo y la impresora está escupiendo montones sin fin de papeles porque alguien esta provocando Denegación de Servicio en su demonio de impresión en línea. Desagradable, ¿verdad? Así que mantenga los servidores de impresión especialmente seguros.

<tt> ARRÉGLAME. Content missing (sin experiencia en lpr)</tt>

<sect>Usar el correo con seguridad
<p>
La lectura/escritura de correo es el protocolo más común de transmisión de datos en claro. Si usa POP3 o IMAP para obtener su correo manda su contraseña en claro a lo largo y ancho de la red, así que cualquiera puede leer su correo a partir de ahora. En su lugar, use SSL (Secure Socket Layer, Capa de Socket Segura) para recibir su correo. La otra alternativa es ssh, si tiene una cuenta shell en su máquina. 

Aquí tiene un fetchmailrc básico:

<example>
poll my-imap-mailserver.org via "localhost"
  with proto IMAP port 1236
      user "ref" there with password "hackme" is alex here warnings 3600
    folders
      .Mail/debian
    preconnect 'ssh -f -P -C -L 1236:my-imap-mailserver.org:143 -l ref
     my-imap-mailserver.org sleep 15 &lt;/dev/null &gt; /dev/null'
</example>

La línea importante es la de preconnect. Lanza una sesión ssh y crea el túnel necesario, que reenvía conexiones al puerto 1236 del servidor imap, pero cifradas. Otra posibilidad sería usar fetchmail con la característica ssl.

<p>
Si quiere dar servicios de correo electrónico cifrado como POP e IMAP, haga <tt>apt-get install stunnel</tt> e inicie sus demónios de esta manera: 

<tt>stunnel -p /etc/ssl/certs/stunnel.pem -d pop3s -l /usr/sbin/popd</tt>
Esta orden envuelve el demonio (-l) al puerto (-d) y usa el cert ssl especificado (-p).

<sect>Asegurar BIND
<p>
En una instalación Debian estándar, el demonio de servicio de nombres, BIND, se ejecuta como usuario root y como grupo root. Es bastante fácil hacer correr BIND bajo otra identidad (UID). Sin embargo, si otro usuario que no sea root hace correr BIND, éste no puede detectar nuevas interfaces automáticamente. Por ejemplo, si pone una tarjeta PCMCIA en su portátil. Compruebe el fichero README.Debian en su directorio de documentación de named para más información. 
Recientemente ha habido muchos problemas de seguridad con respecto a BIND, de modo que cambiar el usuario es útil siempre que sea posible.

<p>
Para hacer correr BIND bajo un usuario diferente, en primer lugar cree un usuario y un grupo separados para él (no es una buena idea usar nobody o nogroup para cada servicio que no se hace correr bajo root). En este ejemplo, se van a usar el usuario y el grupo 'named'. Puede conseguirlo haciendo lo siguiente:

<example>
# addgroup named
# adduser --system --ingroup named named
</example>
<p>
Ahora modifique <tt>/etc/init.d/bind</tt> con su editor favorito y cambie la línea que empieza por
<p>
<tt>start-stop-daemon --start</tt>

por

<tt>start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u
named</tt>
<p>
Todo lo que necesita hacer ahora es reiniciar bind vía <tt>/etc/init.d/bind restart</tt>, y después comprobar que en su syslog aparecen dos entradas como estas:
<p>
<example>
Sep  4 15:11:08 nexus named[13439]: group = named
Sep  4 15:11:08 nexus named[13439]: user = named
</example>
<p>
¡Voilà! Su named no corre ahora como root. Para conseguir la máxima seguridad en BIND, construya una jaula chroot (vea 3.13) sobre su demonio. 

#No estoy seguro acerca de esto: ¿no se debería cambiar de 
#propietario.grupo (chown) a los ficheros de bind a los grupos 
#creados. Se debería especificar ésto. jfs

<chapt>Antes del compromiso

<sect>Siga las actualizaciones de seguridad de Debian
<p>
Tan pronto como se revelan nuevos bugs de seguridad en los paquetes, los mantenedores de debian y los autores generalmente los parchean en días o incluso en horas. Después de que el bug se ha solucionado, se publica un nuevo paquete en <url name="http://security.debian.org" id="http://security.debian.org">. Ponga la siguiente línea en su fichero sources.list y tendrá actualizaciones de seguridad automáticas, siempre que actualice su sitema.

<p>
<tt>deb http://security.debian.org/debian-security potato/updates main contrib 
non-free</tt>

La mayoría de la gente, que no vive en un país que prohibe la importación o el uso de cifrado fuerte, debería añadir esta línea también:

<tt>deb http://security.debian.org/debian-non-US stable/non-US main contrib non
-free</tt>

Si quiere, puede añadir también las líneas deb-src a apt. Vea la página del manual de apt para más detalles.

<sect>Intercambio de software
<p>
Debería evitar cualquier servicio de red que envíe y reciba contraseñas en claro sobre una red como FTP/Telnet/NIS/RPC. El autor recomienda el uso de ssh en vez de telnet y ftp. 

Tampoco debería usar NIS, Network Information Service, si ello es posible, porque permite compartir contraseñas. Esto puede ser altamente inseguro si se rompe su configuración. 

En último lugar, y no menos importante, desactive RPC siempre que sea posible. Se conocen muchos agujeros de seguridad para este servicio y se pueden explotar con facilidad. Por otro lado, los servicios NFS son bastante importantes en algunas redes, así que busque un equilibrio entre usabilidad y seguridad. La mayoría de los ataques DDoS (distributed denial of service -denegación de servicio distribuida) usan exploits rpc para acceder al sistema y actuar como uno de los llamados agentes/manipuladores. 

La desactivación de portmap es bastante simple. Hay métodos distintos; el más simple en un sistema Debian es hacer <tt>update-rc.d portmap remove</tt>. De hecho, esto elimina todos los enlaces simbólicos que tengan relación con portmap en /etc/rc${runlevel}.d/ (podría hacerlo manualmente). 
Podría también hacer <tt>chmod 644 /etc/init.d/portmap</tt>, pero da un mensaje de error en el arranque. También puede eliminar la parte "start-stop-daemon" en el guión de shell <tt>/etc/init.d/portmap</tt>. 

Considere que migrar de telnet a ssh y usar otros protocolos de transmisión en claro de NINGUNA manera incrementa su seguridad. Lo mejor sería eliminar ftp, telnet, pop, imap, http y reemplazarlos por sus respectivos servicios cifrados. También puede considerar mudarse de estos servicios a sus versiones SSL, ftp-ssl, telnet-ssl, pop-ssl, https... 

La mayoría de los consejos arriba indicados se pueden aplicar a todos los sistemas Unix.

<sect>Parches del núcleo útiles
<p>
Existen algunos parches para el núcleo que mejoran considerablemente la seguridad del sistema. Aquí hay unos cuantos:
<p>
<list>
<item>OpenWall, parche de Solar Designer. 
Es un conjunto útil de resctricciones al núcleo, tales como enlaces restringidos, FIFOs en /tmp, /proc restringido, manejadores de descripción de ficheros especiales, área de pila de usuario no ejecutable y algunos más. Homepage: <url name="http://www.openwall.com/linux/" id="http://www.openwall.com/linux/">

<item><em>LIDS - Linux intrusion detection system by Huagang Xie &amp; Philippe
 Biondi</em>.
Este parcehe facilita el proceso de crear un sistema linux fuerte. Puede restringir todos los procesos, otorgar derechos de escritura o lectura de ficheros, o eliminar, por defecto, la posibilidad de leer ficheros. Más aún, puede también establecer las capacidades para ciertos procesos. Incluso aún estando en fase beta es algo obligado para el administrador de sistemas paranoico. Homepage: <url name="http://www.lids.org" id="http://www.lids.org">

<item><em>POSIX Access Control Lists (ACLs) for Linux</em>.
This patch adds access control lists, an advanced method for restricting access
to files, to the linux kernel.
Homepage: <url name="http://acl.bestbits.at/" id="http://acl.bestbits.at/">

<item><em>Linux trustees</em>.
Este parche añade listas de control de acceso al núcleo Linux, un método avanzado para restringir accesos a ficheros. Homepage: <url name="http://acl.bestbits.at" id="http://acl.bestbits.at">

<item><em>International kernel patch</em>.
Éste es un parche orientado al cifrado, por lo tanto tiene que prestar especial atención a las leyes locales sobre el uso del cifrado. Básicamente añade el uso de sitemas de ficheros cifrados. Homepage: <url name="http://www.kerneli.org" id="http://www.kerneli.org">

<item><em>SubDomain</em>.
Una extensión del núcleo para crear un entorno chroot más seguro y fácil de configurar. Puede especificar manualmente los ficheros a los que se necesita hacer chroot y no tener que compilar los servicios estáticamente. Homepage: <url name="http://www.immunix.org/subdomain.html" id="http://www.immunix.org/subdomain.html">

<item><em>UserIPAcct</em>.
Éste no es realmente un parche relacionado con la seguridad, pero le permite crear cuotas por usuario para el tráfico en su servidor. Y puede recoger las estadísticas del tráfico de usuarios. Homepage: <url name="http://ramses.smeyers.be/useripacct" id="http://ramses.smeyers.be/useripacct">
</list>


<sect>Ideas de genio/paranoico, lo que podría hacer
<p>
Probablemente ésta es la sección más inestable y divertida, ya que espero que alguna de estas ideas "descabellas" puedan ponerse en práctica. Siguiendo con el tema, aquí encontrará ideas -bueno, depende del punto de vista, puede llamarlas de genio, paranoicas, locas o seguras- para incrementar su seguridad rápidamente, pero no saldrá ileso de ellas.

<list>
<item>Jugar con PAM. 
Como se dijo en el artículo phrack 56 PAM, lo mejor de PAM es que "solamente estás limitado por lo que puedas imaginar". Es cierto. Imagine que el login de root sea posible solamente por medio de huellas dactilares o por escaneo de iris o por tarjeta cifrada (hmm, ¿por qué he usado la conjuncion O y no Y?).

<item>Registro fascista. 
Yo diría de todo lo que hemos hablado arriba que es registro blando. Si realmente quiere aplicar registro real, coja una impresora de papel contínuo y regístrelo todo imprimiéndolo. Suena simplón, pero es fiable y no se puede eliminar.

<item>Distribución en CD. 
Esta idea es muy fácil de llevar a la práctica y extremadamente segura. Cree una distribución Debian fuertemente asegurada, un cortafuegos diabólicamente bueno, haga una imagen ISO y tuéstela en un CD. Hágalo arrancable. La gran ventaja de todo esto es una distribución completa de solo lectura con unos 600 MB de espacio para servicios y el hecho de que es imposible para los intrusos tener acceso de lectura/escritura en este sistema. Asegúrese de que todos los datos que deberían ser escritos lo son sobre los cables. De todas maneras, el intruso no puede cambiar las reglas del cortafuegos, las entradas de encaminamiento o iniciar sus propios demonios (realmente puede, pero reinicie y tiene que meterse en su sistema otra vez para cambiarlos).

<item>Desactive la capacidad de carga de módulos. 
Cuando desabilita el uso de módulos del núcleo al tiempo de compilar dicho núcleo es imposible implementar muchas de las puertas traseras del núcleo, ya que la mayoría de ellas se basan en la instalación de módulos del núcleo.
</list>


<chapt>Después del compromiso

<sect>Comportamiento general
<p>
Si realmente quiere limpiar residuos, debería eliminar el host comprometido de su red y reinstalar el sistema operativo desde el principio. Esto podría no valer de nada si no sabe cómo consiguió ser root el intruso. En este caso, debe comprobar todo: cortafuegos/integración de ficheros/host de registro/ficheros de registro, etc.
</book>

