Es muy fácil entrar a una shell con el usuario root y cambiar las contraseñas simplemente tecleando "<name-of-your-bootimage> init=/bin/sh". Luego de cambiar las contraseñas y reingresar al sistema, la persona ha tiene acceso ilimitado (como root) y puede hacer cualquier cosa que el/ella quiera en el sistema. Después de este procedimiento, usted no tendrá acceso a su sistema, porque usted no conoce la contraseña de root.
Asegúrese que esto no pueda suceder, usted debería colocar una contraseña para el cargador de linux. Usted puede escoger entre una contraseña global y una contraseña para una imagen.
Para LILO usted necesita editar el archivo /etc/lilo.conf
y
agregar una contraseña y restringirlo como en el siguiente ejemplo:
image=/boot/2.2.14-vmlinuz label=Linux read-only password=hackme restricted
Cuando haya terminado, ejecute LILO. Omitir la línea restricted
produce que LILO siempre pida una contraseña, aun si no se le pasan parámetros
a LILO.Los permisos defectuosos de /etc/lilo.conf
para que el gran
root lea yescriba, y se habilite el acceso de solo lectura para el
grupolilo.conf's de root.
Si usted usa GRUB en lugar de LILO, edite /boot/grub/menu.lst
y
agregue las siguientes dos líneas al inicio (sustituyendo, por supuesto
'hackme' con la contraseña deseada). Esto previene a los usuarios de editar
los ítems de entrada. 'timeout3' especifica tres segundos antes del arranque
del sistema por defecto.
timeout 3 password hackme
Para asegurar mas la integridad de la contraseña, usted podría guardarla una forma encriptada. La utilidad de grub-d5-crypt es que genera una contraseña la cual es compatible con el algorítmo (md5) de encripción de grub. Para especificar en GRUB que el formato de la contraseña md5 será usado, use la siguiente instrucción:
timeout 3 password --md5 $1$bw0ez$tljnxxKLfMzmnDVaQWgjP0
El parámetro --md5 fue agregado para instruir a grub a realizar el proceso de autenticación. La contraseña proporcionada es la versión encriptada en md5 de "hackme". Usar el método de encripción md5 es preferible a su contraparte en solo texto. Mas información acera de la contraseña GRUB puede ser encontrada en el paquete de grub-doc.
Los núcleos de Linux 2.4 proporcionan una forma para tener acceso a la línea de comandos del administrador que será presentada justo después de cargar el sistema de archivos cramfs. Un mensaje aparecerá para permitir al administrador entrar en una línea de comandos con permisos de root, esta línea de comandos puede ser usada manualmente para cargar módulos cuando la autodetección falla. Este comportamiento es el predeterminado para initrd's linuxrc. El siguiente mensaje aparecerá:
Press ENTER to obtain a shell (waits 5 seconds)
Para eliminar este comportamiento usted necesita cambiar
/etc/mkinitrd/mkinitrd.conf
y colocar:
# 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
Luego regenera su imagen del disco RAM. Usted puede hacer esto por ejemplo con:
º # cd /boot # mkinitrd -o initrd.img-2.4.18-k7 /lib/modules/2.4.18-k7
O hacer (preferir):
# dpkg-reconfigure kernel-image-2.4.x-yz
Note que DEBIAN 3.0 WOODY permite a los usuarios instalar 2.4 kernels
(seleccionandoflavors), sin embargo el defecto de kernel es
de 2.2 (salvo para algunos artífices, para los cuales Kernel 2.2 no estaba en
la entrada). Si usted considera esto un BUG considere el Bug 145244
antes de enviar
este.
El MBR defectuoso en Debian antes de la versión 2.2 no actúa como un registro dominante en la entrada y deja abierto un método para quebrar fácilmente el sistema:
Este comportamiento puede ser cambiado totalmente por:
lilo -b /dev/hda
Ahora LILO es puesto dentro del MBR. Este también puede ser archivado agregando "boot=/dev/hda" para lilo.conf. Hay otra solución la cual inhabilita rápidamente el MBR, completamente:
install-mbr -i n /dev/hda
De otra forma, esta "puerta trasera" desde la cual mucha gente no está enterada, puede salvar su pellejo si usted esta en aprietos con su instalación por cualquier razón.
ARREGLAMEcheck whether this really is true as of 2.2 or was it 2.1? INFO: Thebootdisks as of Debian 2.2 do NOT install the mbr, but only LILO
Algunas políticas de seguridad quieren forzar a los administradores para
registrarse en el sistema a través de la consola con su usuario/contraseña y
luego llegar a ser un superusuario (consu
o sudo
).
Esta política es implementada en Debian al editar el archivo
/etc/login.defs
o /etc/securetty
cuando se usa PAM.
En:
login.defs
, edite el la variable CONSOLE , que define un archivo o
lista de terminales sobre las cuales la entrada de root es permitida.
securetty
agregando/removiendo las terminales desde las cuales el
acceso a root es permitido.
Cuando use PAM se hacen otros cambios para el proceso de registro, los cuales
pueden incluir restricciones para usuarios y grupos a tiempos dados, puede ser
configurado en /etc/pam.d/login
. Una interesante característica
que puede ser incapacitada es la posibilidad de registrar con contraseñas sin
efecto (nulas). Esta característica puede ser limitada removiendo el
nullok de la linea:
auth required pam_unix.so nullok
cuando se monta una partición ext2, usted tiene varias opciones adicionales
para aplicar a el llamado montaje o a /etc/fstab
. Por ejemplo,
este fstab entra por la partición /tmp
: /dev/hda 7 /tmp ext2
defaults .nosuid.noexec.nodev 0 2
/dev/hda7 /tmp ext2 defaults,nosuid,noexec,nodev 0 2
usted ve la diferencia a las secciones de opciones . La opción nosuid ignora los bits setuid y setgid completamente , mientras que noexec prohibe la ejecución de programas en ese punto de montaje, y nodev, ignora los dispositivos.Esto suena grandioso , pero esto
La opción noexec previene los binarios de ejecutarse directamente, pero se engaña fácilmente:
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
Sin embargo, muchos "script kiddies" cuentan con "xploits"
que intentan crear y ejecutar los archivos en /tmp
.Si ellos no
tienen una pista, ellos entrarán en esta trampa. En otros términos, un usuario
no puede engañarse en ejecutar un binario troyanizado en /tmp
e.g.
por ejemplo cuando él agrega a propósito /tmp
dentro de su PATH.
También se previene de algún programa que podría depender en que
/tmp
sea ejecutable. Más notablemente, Debconf tiene (¿tenía?)
algunos problemas que consideran esto, para más información vea Bug 116448
.
Lo siguiente es un ejemplo más completo. Una nota, sin embargo:
/var
podrían ponerse en noexec, pero algún software como Smartlist
contiene sus programas en / var. El mismo aplicado a la opción nosuid.
/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
Tenga cuidado si esta poniendo /tmp
y usted quiere instalar el
nuevo software, desde que alguno podría usarlo para la instalación. Apt es uno
de esos programas (vea http://bugs.debian.org/116448
)
si no configuró propiamente APT::ExtractTemplates::TempDir (vea
apt-extracttemplates(1)
). Usted puede poner esta variable en
/etc/apt/apt.conf
a otro directorio con privilegios exec que no
sea /tmp
Con respecto al noexec, por favor sea consciente que no podría ofrecerle tanta seguridad.Considere esto:
$ cp /bin/date /tmp $ /tmp/date (does not execute due to noexec) $/lib/ld-linux.so.2 /tmp/date (works since date is not executed directly)
Si usted pusiera /usr
leer - únicamente usted no podrá instalar
los nuevos paquetes en su Debian GNU / sistema Linux. Usted tendrá, primero
que remontar leer -escribir, instale los paquetes y entonces remóntelo
leer-únicamente. La última versión apt (en Debian 3.0´woody´) puede
configurarse para ejecutar las órdenes antes y después de instalar los
paquetes, para que usted pueda propiamente querer configurarlo.
Hacer esto modifica /etc/apt/apt.conf
y agrega:
DPkg { Pre-Invoke { "mount /usr -o remount,rw" }; Post-Invoke { "mount /usr -o remount,ro" }; };
Note que el Post-invoke puede fallar con un "/usr busy" error en el mensaje. Esto pasa principalmente cuando usted está usando los archivos durante la actualización en que se puso al día. Incomodando pero no realmente una cantidad grande. Sólo hacerlo seguro que ésto ya no se use y ejecute Post - Invoke manualmente.
En cuanto generalmente se revelen los nuevos bugs de seguridad en los paquetes,
mantenedoras de debian y autores upstream generalmente dentro de días o incluso
en horas. Después de que el bug es fijo, un nuevo paquete se proporciona en
http://security.debian.org
.Ponga
la línea siguiente en sus fuentes. la lista y usted conseguirá la seguridad
que se pone al día automáticamente, siempre que usted ponga al día su sistema.
deb http://security.debian.org/debian-security stable/updates main contrib non-free
La mayoría de las personas que no viven en un país que prohibe la importación o usa la criptografía fuerte, debe agregar esta línea también:
deb http://security.debian.org/debian-non-US stable/non-US main contrib non-free
Si le gusta, usted puede agregar las líneas del deb-src también a apt. Vea
apt(8)
para detalles extensos.
Usted debe dirigir la seguridad frecuentemente que se pone al día, la inmensa
mayoría de resultado de explotaciones de vulnerabilidades conocidas que no se
han remendado a tiempo, cuando un nombre de http://www.cs.umd.edu/~waa/vulnerability.html
name="papel por Bill Arbaugh"> (presentó en el 2001 Simposio de
IEEE en Seguridad y Retiro) explica.
ARREGLAME:Añade info cómo la firma de paquetes que se hace para que esto pueda hacerse automáticamente a través de un trabajo del cron (engaña grandemente :DNS).
PAM (modulos de autenticación de enchufes ) permiten a los administradores de
sistema elegir como usar la aplicaciones autenticadas . Note que PAM puede
hacer nada a menos que una aplicación es compilada con soporte para PAM . La
mayor parte de las aplicaciones que son enviadas con Debian 2.2 tienen este
soporte construido . Ademas , Debian no tiene soporte PAM antes del 2.2. Cada
aplicación con soporte PAM provee un archivo de configuración en
/etc/pam.d/
el cual puede ser usado para modificar este
comportamiento. La siguiente descripción está lejos para completarla, para mas
información usted podria querer leer la guia de el sistema administrador Linux
-PAM http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html
(en la principal distribución ubicada de PAM http://www.kernel.org/pub/linux/libs/pam/
)
PAM le ofrece a usted la posibilidad a ir por varios pasos de autenticación una vez, sin el uso de conocimientos .Usted puede autenticar de nuevo una base de datos Berkeley y de nuevo el archivo de password normal y el uso únicamente de registros en si correctamente autenticos en ambos. Usted puede limitar a muchos con PAM , así como usted puede abrir sus puertas del sistema muy extensamente. Así que tenga cuidado. Una línea de la típica configuración tiene un campo de mando como su segundo elemento. Generalmente debe ponerse a " requisito", el cual devuelve un fracaso del login si hay una falta en el módulo.
La primera cosa que me gusta hacer, es agregar soporte MD5 a las aplicaciones
de PAM, desde que esto ayuda, protege contra los cracks (passwords del
diccionario que puede ser más largo usando MD5). Lo siguiente debe agregarse
dos líneas a todos los archivos en /etc/pam.d/
ese acceso de
concesión a la máquina, como login and ssh.
# Be sure to install libpam-cracklib first or you will not be able to log in password required pam_cracklib.so retry=3 minlen=12 difok=3 password required pam_unix.so use_authtok nullok md5
¿Así, qué hace esta maravilla? Las primeras cargas de la línea en el cracklib módulo de PAM que proporciona la contraseña strenght-checking (fuerza-verificando) las sugerencias para una nueva contraseña con una longitud mínima de 12 carácteres, una diferencia de por lo menos 3 carácteres de la contraseña vieja, y permite 3 reintentos. La segunda línea introduce el módulo de la autenticación normal con las contraseñas de MD5 y permite una cera de contraseña de longitud. El director use_authtok es necesario para entregar la contraseña del módulo anterior.
Para asegurarse que el root (administrador de Linux) del usuario sólo puede
anotarse en el sistema de los términos locales, la línea siguiente debe
habilitarse en /etc/pam.d/login
:
auth requisite pam_securetty.so
Entonces usted debe agregar los términos que el root del usuario puede anotar
en el sistema en /etc/security/access.conf
. Último pero no menor
a la línea siguiente debe ser los anabled si usted quiere preparar los límites
del usuario.
session required pam_limits.so
Esto restringe los recursos del sistema que se permiten a los usuarios (vea en la siguiente pagina Los límites de el archivo.conf, Sección 4.7.2. Por ejemplo, usted podría restringir el número de logins coexistente (de un grupo dado de usuarios, o sistema-ancho) usted puede tener, el número de procesos, el tamaño de memoria......
Ahora revise /etc/pam.d/passwd
y cambie la primera línea. Usted
debe agregar el "md5" de la opción para usar las contraseñas de MD5,
cambie el lenght mínimo de contraseñas de 4 a 6 (o más) y ponga un legth
máximo, si usted desea. La línea resultante mirará algo como:
password required pam_unix.so nullok obscure min=6 max=11 md5
Si usted quiere proteger su (un comando), para que sólo algunas personas puedan
usarlo para volverse a root en su sistema, usted necesita agregar uno nuevo
para agregar un nuevo "wheel" de grupo a su sistema (ésa es la manera
más limpia, desde que ningún archivo tiene tal un permiso de grupo todavía).
Agregue el root y los otros usuarios que deberian ser capaces de ejecutar
su a el usuario de root a este grupo. Entonces agregue la línea
siguiente a /etc/pam.d/su
:
auth requisite pam_wheel.so group=wheel debug
Esto asegura que sólo personas de el grupo wheel pueden usar su
para volverse root. Otros usuarios no seran capaces de volverse root. De
hecho ellos conseguirán un mensaje negado si ellos intentan volverse volverse
root.
Si usted quiere que sólo ciertos usuarios autentiquen a un servicio de PAM,
esto es bastante fácil de lograr usando los archivos dónde los usuarios que son
permitidos al login (o no) se guarden. Sólo imagine que usted quiere
permitirle el login de ´ref´to al usuario vía ssh. Así que usted lo pone en
/etc/sshusers-allowed
y le escribe lo siguiente en
/etc/pam.d/ssh
:
auth required pam_listfile.so item=user sense=allow file=/etc/sshusers-allowed onerr=fail
Por último, pero no menos importante, cree /etc/pam.d/other
y
coloque las líneas siguientes:
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
Estas líneas mantendrán una buena configuración predefinida en todas las aplicaciones que apoyan PAM (se niega el acceso por el valor predeterminado).
Usted realmente debe hacer una mirada seria en este archivo. Aquí usted puede
definir los límites de recurso del usuario. Si usted usa PAM, el archivo
/etc/limits.conf
se ignora y usted debe usar en cambio
/etc/security/limits.conf
.
ARREGLAME: Adquirir unos buenos limites.conf concluidos aquí.
El próximo paso es revisar la configuración básica y acción en el login del usuario.
FAIL_DELAY 10
Esta variable debe ponerse a un valor más alto, para hacerlo más difícil usar el término para anotar usando la fuerza bruta. Si una contraseña mala se teclea en, el posible asaltador (o el usuario normal!) tiene que esperar por 10 segundos para conseguir un nuevo login que incite realmente el tiempo que se consume cuando usted prueba las contraseñas.Preste atención al hecho que esta escena es inútil si se usa el programa de otra manera que el getty, como el mingetty por ejemplo.
FAILLOG_ENAB yes
Si usted habilita esta variable, se anotarán los logins fallados. Es importante guardar huella de ellos para coger a alguien que pruebe un ataque de fuerza bruta.
LOG_UNKFAIL_ENAB yes
Si usted pusiera la variable "FAILLOG_ENAB" asi, entonces usted también deberia poner esta variable a sí. Esto grabará el usernames desconocido si los login fallaron. Si usted hace esto, asegúrese de que los logs tienen por ejemplo permisiones (640 por ejemplo, con una escena de grupo apropiada como el adm), porque los usuarios entran en su contraseña a menudo accidentalmente como el username y usted no quiere otro para verlo.
SYSLOG_SU_ENAB yes
Este uno habilita el logging de la pueba su a syslog. Bastante importante en serias maquinas pero note que esto puede crear el retiro de los resultados a medida que esten bien.
SYSLOG_SG_ENAB yes
Igual que SYSLOG_SU_ENAB pero lo aplica al programa sg
.
MD5_CRYPT_ENAB yes
Como lo expuesto anteriormente, MD5 suma grandemente las contraseñas que reducen el problema de ataques del diccionario, desde que usted puede usar las contraseñas más largas. Si usted está usando slink, lea los documentos sobre MD5 antes de habilitar esta opción.Por otra parte esto esta fijo en PAM.
PASS_MAX_LEN 50
Si se activan las contraseñas de MD5 en su configuración PAM, Entonces esta variable debería ser ajustada al mismo valor que se uso allí.
Si usted realmente necesita que los usuarios se vuelvan el super usuario en su
sistema,e.g. por instalar los paquetes o agregar usuarios, usted puede usar el
comando su
para cambiar su identidad. Usted debe intentar evitar
cualquier login como root del usuario y en cambio usar su
.
Realmente, la mejor solución es quitar su y cambiar a sudo
, como
él tiene más rasgos que su
. Sin embargo,su
es más
común como se usa en muchos otro Unixes.
sudo
le permite al usuario ejecutar los comandos definidos bajo la
identidad de otro usuario, así como root. Si el usuario agrega a
/etc/sudoers
y se autentica correctamente, él es capaz de avanzar
comandos en que se ha definido /etc/sudoers
. Las Violaciones,
como las contraseñas incorrectas o intentos de ejecutar un programa usted no
tienen permiso para ser anotado y mandado por correo a root.
A veces usted podría pensar que necesita tener los usuarios creados en su sistema local para proporcionar un servicio (pop3 manda por correo el servicio o ftp). Antes de hacer eso, primero recuerde que la aplicación de PAM en Debian GNU/Linux le permite validar a los usuarios con una variedad ancha de el servicio de directorio externo (el radio, el ldap, etc.) con tal de que por el ,el libpam sea empacado.
Si los usuarios necesitan ser creados y el sistema puede ser remotamente de
acceso tome en cuenta que los usuarios sean capaces al login al sistema. Usted
puede arreglar esto dando a los usuarios una nula (/dev/null
)
interfaz de comandos (él necesitaría ser listada en /etc/shells
).
Si usted quiere permítales a los usuarios acceder a el sistema pero limitar sus
movimientos, usted puede usar el /bin/rbash
, equivalente a agregar
la opción -r en bash (RESTICTED SHELL ver
bash(1)
). Por favor note que incluso con la interfaz de comandos
restringido, un usuario que entra en acceso a un programa interactivo (eso
podría permitirle la ejecución de un subshell) podría poder desviar los límites
de el shell.
Debian no es proporcionado actualmente (pero puede serlo en el futuro) el
módulo del pam_chroot
. Una alternativa a este chroot es el
servicio que proporciona el logging remoto (ssh, telnet).
Si usted desea restringirlo when los usuarios pueden acceder a el
sistema que usted quiere tener personalizado
/etc/security/access.conf
para sus necesidades.
Los sshd de Debian no le permitirán restringir el movimiento del usuario a
través del servidor desde que le falte la función de Chroot que el anuncio
(sshd2) el programa tiene (uso de 'ChrootGroups' o 'ChrootUsers', vea
sshd2_config(5)
). Sin embargo,hay un parche disponible eso le
permitirá hacer esto, el parche, puede recuperarse del informe Bug report 139047
o http://www.cag.lcs.mit.edu/~raoul/
(y podría aplicarse en el paquete de OpenSSH en el futuro). Emmanuel Lacour
tiene los paquetes del ssh con este rasgo a http://debian.home-dn.net/woody/ssh/
,
yendo a través de el paso de la recopilación se recomienda, sin embargo. Una
descripción de todos los pasos necesitados puede encontrarse en http://mail.incredimail.com/howto/openssh/
(casi todos son aplicables a Debian aun cuando habla sobre RedHat 7.2).
Después de aplicar el parche simplemente usted modifica lo que necesita el
/etc/passwd
cambiando el camino de la casa de los usuarios (con la
especial ficha /./):
joeuser:x:1099:1099:Joe Random User:/home/joe/./:/bin/bash
Esto restringirá both accesos de el interfaz de comandos remoto así como la copia remota a través del canal ssh.
Asegúrese para tener todos los binarios necesitados y bibliotecas en el el camino del chrooted para los usuarios. Estos archivos deben poseer por root evitar ser manoseados por el usuario (para terminar el chrooted encarcelado). Una muestra podría incluir:
./bin: total 660 drwxr-xr-x 2 root root 4096 Mar 18 13:36 . drwxr-xr-x 8 guest guest 4096 Mar 15 16:53 .. -r-xr-xr-x 1 root root 531160 Feb 6 22:36 bash -r-xr-xr-x 1 root root 43916 Nov 29 13:19 ls -r-xr-xr-x 1 root root 16684 Nov 29 13:19 mkdir -rwxr-xr-x 1 root root 23960 Mar 18 13:36 more -r-xr-xr-x 1 root root 9916 Jul 26 2001 pwd -r-xr-xr-x 1 root root 24780 Nov 29 13:19 rm lrwxrwxrwx 1 root root 4 Mar 30 16:29 sh -> bash ./etc: total 24 drwxr-xr-x 2 root root 4096 Mar 15 16:13 . drwxr-xr-x 8 guest guest 4096 Mar 15 16:53 .. -rw-r--r-- 1 root root 54 Mar 15 13:23 group -rw-r--r-- 1 root root 428 Mar 15 15:56 hosts -rw-r--r-- 1 root root 44 Mar 15 15:53 passwd -rw-r--r-- 1 root root 52 Mar 15 13:23 shells ./lib: total 1848 drwxr-xr-x 2 root root 4096 Mar 18 13:37 . drwxr-xr-x 8 guest guest 4096 Mar 15 16:53 .. -rwxr-xr-x 1 root root 92511 Mar 15 12:49 ld-linux.so.2 -rwxr-xr-x 1 root root 1170812 Mar 15 12:49 libc.so.6 -rw-r--r-- 1 root root 20900 Mar 15 13:01 libcrypt.so.1 -rw-r--r-- 1 root root 9436 Mar 15 12:49 libdl.so.2 -rw-r--r-- 1 root root 248132 Mar 15 12:48 libncurses.so.5 -rw-r--r-- 1 root root 71332 Mar 15 13:00 libnsl.so.1 -rw-r--r-- 1 root root 34144 Mar 15 16:10 libnss_files.so.2 -rw-r--r-- 1 root root 29420 Mar 15 12:57 libpam.so.0 -rw-r--r-- 1 root root 105498 Mar 15 12:51 libpthread.so.0 -rw-r--r-- 1 root root 25596 Mar 15 12:51 librt.so.1 -rw-r--r-- 1 root root 7760 Mar 15 12:59 libutil.so.1 -rw-r--r-- 1 root root 24328 Mar 15 12:57 libwrap.so.0 ./usr: total 16 drwxr-xr-x 4 root root 4096 Mar 15 13:00 . drwxr-xr-x 8 guest guest 4096 Mar 15 16:53 .. drwxr-xr-x 2 root root 4096 Mar 15 15:55 bin drwxr-xr-x 2 root root 4096 Mar 15 15:37 lib ./usr/bin: total 340 drwxr-xr-x 2 root root 4096 Mar 15 15:55 . drwxr-xr-x 4 root root 4096 Mar 15 13:00 .. -rwxr-xr-x 1 root root 10332 Mar 15 15:55 env -rwxr-xr-x 1 root root 13052 Mar 15 13:13 id -r-xr-xr-x 1 root root 25432 Mar 15 12:40 scp -rwxr-xr-x 1 root root 43768 Mar 15 15:15 sftp -r-sr-xr-x 1 root root 218456 Mar 15 12:40 ssh -rwxr-xr-x 1 root root 9692 Mar 15 13:17 tty ./usr/lib: total 852 drwxr-xr-x 2 root root 4096 Mar 15 15:37 . drwxr-xr-x 4 root root 4096 Mar 15 13:00 .. -rw-r--r-- 1 root root 771088 Mar 15 13:01 libcrypto.so.0.9.6 -rw-r--r-- 1 root root 54548 Mar 15 13:00 libz.so.1 -rwxr-xr-x 1 root root 23096 Mar 15 15:37 sftp-server
Si usted es paranoico usted podría querer agregar a los usuarios una definición
.profile
que pone el ambiente en cierto modo tal que ellos no
pueden retirar las capacidades de la auditoría de la interfaz de comandos (los
comandos son descargas a $HISTFILE. El .profile
podría ponerse como sigue:
HISTFILE=/home/_user_/.bash_history HISTSIZE=100000000000000000 HISTFILESIZE=10000000000000000 set -o HISTFILE set -o HISTSIZE set -o HISTFILESIZE export HISTFILE HISTSIZE HISTFILESIZE
Note: el - o atribuye colocar una variable leer-únicamente en bash.
Para trabajar esto el usuario no pueden modificar el .profile
o
.bash_history
pero debe poder primero leer uno y escribe uno en el
segundo. Usted puede hacer esto fácilmente cambiando éstos archivos y el
directorio dónde ellos residen para ser poseídos por otro usuario (root), y da
escritura a los permisos del grupo de usuarios a la historia del archivo. Otra
opción está terminando el uso del programa chattr
.
Si usted es completamente paranoico y quiere intervenir en el comando de cada
usuario,usted podría tomar bash a el código de la fuente, revise este y haga
envío a todos de que el usuario tecleó en otro archivo. O tiene
ttysnoop
constantemente algun nuevo monitor ttys y dump en el
rendimiento en un archivo. Otro programa útil es Snoopy
el cual
es un programa usuario-transparente que engancha como en una
bibliotecaproporcionando una envoltura alrededor del execve llamadas (),
cualquier comando ejecuta el estar anotado a syslogd usando la facilidad del
authpriv facility (usualmente storead a
/var/log/auth.log
.
Note que usted no puede usar el comando script
por esto desde que
este no funcionará como una interfaz de comandos (aun si usted agrega esto a
/etc/shells
.
El ejemplo anterior es una manera simple de configurar el usuario interviniendo
el cual no podría ser útil para los sistemas complejos. Si éste es su caso,
usted necesita mirar a acct
, la contabilidad de utilidades. Éstos
anotarán todos los comandos corridos por usuarios o procesos en el sistema, al
gasto de espacio del disco.
Al activar la contabilidad, toda la información sobre los procesos y el usuario
se guarda bajo /var/account/
, más específicamente en el
pacct
. El paquete de contabilidad incluye algunas herramientas
(sa
y ac
) para analizar estos datos.
Si usted quiere normalmente see a los usuarios qué están haciendo,
cuando esten ellos conectándos usted pueden usar la base de datos de
wtmp
que incluye toda la información del login. Este archivo
puede procesarse con varias utilidades, entre ellos sac
el cual
puede hacer un profile en cada usuario que muestra en que estructura de tiempo
ellos normalmente anotan adelante en el sistema.
En caso de que usted tiene la contabilidad activada, usted también puede usar las herramientas con tal de que por esto en el comando determine cuando los usuarios acceden a el sistema y qué ellos ejecuten.
Las envolturas de TCP se desarrollaron cuando no había ningún filtro del
paquete real disponible y el control de acceso fue necesitado. Las envolturas
de TCP permiten permitir o negar un servicio para un organizador o un dominio y
defina un valor permitido o niegue la regla. Si usted quiere que más
informaciones de una mirada a hosts_access(5)
.
Muchos servicios instalados en Debian son cualquiera de estos dos:
tcpd
)
En la primera mano, de servicios son configurados en
/etc/inetd.conf
, esto incluye telnet,ftp,netbios,swat and finger
(usted verá que el archivo de la configuración se ejecute primero
/usr/sbin/tcpd
. Por otro lado, aun cuando un servicio no se lanza
por el superdemonio del inetd
,en cualquier caso,sujetó las reglas
de envolturas de tcp compilando su soporte en él. Los servicios compilados con
las envolturas del tcp en Debian incluyen ssh,portmap, in.talk, rpc.statd,
rpc.mountd,gdm,oaf (el demonio activador de GNOME), Nessus y muchos otros.
Tenga en cuenta esto cuando el tcpchk
está avanzando. Usted puede
agregar servicios en que se unen a la biblioteca de la envoltura de los
archivos host.deny
y hosts.allow
pero los
tcpchk
advertirá que este no puede encontrar esos servicios desde
que parece para ellos en /etc/inetd.conf
(el manpage no es
totalmente exacto aquí).
Ahora, aquí viene un truco pequeño, y probablemente la intrusión más pequeña del sistema de descubrimiento disponible. En general, usted debe tener una política decente del cortafuego como una primera línea, y envolturas del tcp como la segunda línea de defensa. Un truco pequeño es poner un comando SPAWN [1]en /etc/hosts.deny que envía correos a root siempre que hay un servicio negado en las envolturas de los gatillos:
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) &
Beware(tenga cuidado): El ejemplo anterior impreso puede fácilmente ser DoSed por estar haciendo las muchas conexiones en un período corto de tiempo. Muchos correos electrónicos significan mucho del archivo I/O para enviar únicamente unos correos.
Cómo las bitácoras y alarmas son tratadas es un problema importante en un sistema seguro. Es fácil ver que, aun cuando el sistema está perfectamente configurado y, supuestamente, 99% asegurado. Si el 1% sucede, y no hay seguridad midiendo en tales situaciones, primero, descubra esto y, segundo, las alarmas del aumento, el sistema no está en absoluto seguro.
Debian GNU/Linux proporciona algunas herramientas para hacer el análisis de
bitácoras, la mayoría, notablemente el logcheck
. Sin embargo,
allí se está considerando mucho análisis del log que no puede cubrirse
totalmente aquí, un recurso bueno para la información es Couterpane's Log Analysis
Resources
.
Debian viene con una configuración de syslog estándard dentro de
(etc/syslog.conf)que anota mensajes para apropiar archivos dependiendo de la
facilidad del sistema. Usted debería familiarizarse con ésto, debe mirar el
archivo syslog.conf
o sino la documentación. Si usted pretende
mantener un sistema seguro usted podrá estar precavido de a dónde se mandan los
mensajes de registro de manera que no pasen inadvertidos.
Por ejemplo, enviar mensajes a la consola es una configuración interesante ya que es útil para muchos sistemas de nivel de producción. Pero para muchos sistemas también es importante añadir una nueva máquina que podría servir como servidor de registro (i.e. esto recibe los registros desde todos los otros sistemas).
El correo de Root también deberia ser considerado, muchos controles de
seguridad como snort
) envían alarmas al buzón de Root. Este buzón
normalmente apunta al primer usuario que se creó en el sistema (compruebe
/etc/aliases
). Tenga cuidado de enviar correo de root a cualquier
lugar donde pueda ser leído (ya sea local ó remotamente)
Hay otros informes y alianzas en su sistema. En un pequeño sistema, ésto probablemente lo más simple para asegurarse de que todas las alianzas apunten hacia la cuenta de root, y que el correo para root este dispuesto para el sistema de buzón personal del administrador.
ARREGLAME: it would be interesting to tell how a Debian system can send/receive
SNMP traps related to security problems (jfs). Check:
snmptraglogd
, snmp
and snmpd
.
Un servidor de regiastro es un servidor que recoge remotamente datos syslog de
la red. Si una de sus máquinas es craqueada, el intruso no puede cubrir sus
huellas, a menos de que también altere el servidor de registro. Así el
servidor de registro deberá ser especialmente seguro. Convertir una máquina en
servidor de registro es simple. Simplemente lance syslogd con 'syslogd -r' y
nace un nuevo servidor de registro. Seguidamente, congifure las otras máquinas
para que envíen datos al servidor de registro, Para hacer ésto permanentemente
en Debian edite /etc/init.d/sysklogd
y cambie la línea:
SYSLOGD=""
to
SYSLOGD="-r"
Luego, configure las otras máquinas al enviar los datos al servidor de
registro. Agrege una entrada como la siguiente /etc/syslog.conf
:
facility.level @your_loghost
Mire la documentación para saber que usar en lugar de facility y level (ellos no deben ser introducirse de forma literal como se hace aquí). Si usted quiere registrar todo remotamente, escriba:
*.* @your_loghost
dentro de su syslog.conf. Registrar tanto remota como localmente es la mejor
solución (el atacante creerá haber cubierto sus pasos después de eliminar los
archivos locales de registro). Para información adicional consulte el manual
de paginas syslog(3)
, syslogd(8)
y
syslog.conf(5)
.
No sólo es importante decidir como son usadas las alertas, sino también quienes tiene acceso a éstas, i.e. puede leer o modificar los archivos de registro (si no se está usando un servidor remoto de registros). Las alertas de seguridad que el atacante pueda cambiar o inhabilitar no son de mucho valor en el momento de la invasión.
Algunos permisos para el achivo de registro no son perfectos despúes de la
instalación. Primero /var/log/lastlog
y
/var/log/faillog
no necesitan tener un permiso de lectura para un
usuario normal. En el archivo lastlog usted puede ver quien entró
recientemente y en faillog usted mira un resumen de las entradas fallidas. El
autor recomienda cambiar permisos a 660.Haga una breve revisión en sus archivos
de registro y decida muy cuidadosamente cuales logfile deben tener permiso de
lectura y escritura para un usuario con UID distinto a 0 y un grupo aparte de
'adm' o 'root'.
Quiero enfatizar que los permisos del archivo de registro apache son realmente malos debido al hecho de que el usuario apache tiene los registros del archivo apache. Si un ususario obtiene un interfaz de comandos con una puerta trasera de apache, ellos pueden eliminar fácilmente los archivos de registro.
chroot
es una de las posibilidades más poderosas para restringir
un demonio, un ususario u otro servicio. Sólo imagine una cárcel alrededor de
su objetivo, del cual no puede escapar (normalmente, hay sin embargo muchas
condiciones que permiten un escape fuera de su cárcel). Si usted no confía en
un usuario, puede crear un cambio en el ambiente. Ésto puede usar un pequeño
espacio adicional de disco, puesto que se necesita copiar todos los ejecutables
necesarios, así como las biblioteca dentro de la cárcel. Aún si el usuario
hace algo malicioso, el alcance de un daño es limitado al aseguramiento.
Un buen ejemplo de este caso,es,si usted no autentica en contra de
/etc/passwd
puede usar LDAP o MySQL. Así que su demonio ftp
únicamente necesita un binario y quizá un poco de biblioteca. Un cambio de
directorio raíz seria un excelente seguro del mejoramiento de condiciones
externas; si una nueva vulneración es conocida para este demonio ftp, entonces
solamente el atacante puede vulnerar el UID del usuario de demonio ftp y nada
más.
Por supuesto, muchos otros demonio también podrán beneficiarse desde este modo de arranque.
Sin embargo, esté prevenido que el seguro chroot
puede estar
dañado si el usuario entra en éste es el superusuario. Así que usted necesita
que el servicio corra como un usuario no privilegiado. Límitando su ambien
usted está límitando la palabra leíbles que el servicio de archivos ejecutables
puede acceder, así, usted límita las posibilidades de una subida del privilegio
por el uso de vulnerabilidades de seguridad de los sistemas locales. Incluso
en ésta situación usted no puede estar copmpletamente seguro de que no hay
ninguna manera para que un atacante hábil se escape de algún modo del
aseguramiento. Usando solamente un servidor de programa, el cual tiene una
reputación de medida de aseguramiento que es buena. Incluso la cavidad
minusiosa de archivos manuales puede ser abierta por un atacante hábil
interrumpiendo el sistema por dentro. Despues de todo, chroot
no
fue diseñado como una herramienta de comprobación.
Como una nota adicional, Demonios omite BIND (Internet nombra el servicio) esto no viene con un cambio de directorio raíz, de hecho demonios no viene con un cambio de directorio raíz. Éste debe cambiar en el woody (3.0) release.
También hay algún software (no actualmente en Demonios pero el cual podría
estar disponible en el futuro) que puede ayudar al arreglo del ambiente del
cambio de directorio raíz. Por ejemplo, makejail
puede crear y
poner al día un aseguramiento del cambio de directorio raíz con la
canfiguración de pequeños archivos. También intenta suponer e instalar dentro
del aseguramiento todos los archivos requeridos por demonios. Más información
en http://www.floc.net/makejail/
Jailer
. Es una herramienta similar la cual puede ser cobrada
desde http://www.balabit.hu/downloads/jailer/
.
ARREGLAME: Content missing
Muchas características de kernel pueden ser modificadas ya que actualmente se
repiten algunas cosas dentro del sistema del arhivo /proc
o usando
el sistema ctl. Pra ingresar a sysctl -A puede mirar que debe
configurar y que otras opciones hay. Solamente en algunas cosas usted necesita
editar algunas cosas aquí, pero usted puede aumentar la seguridad que es un
buen camino.
net/ipv4/icmp_echo_ignore_broadcasts = 1
Este es un 'emulador de windows' porque éste funciona como windows para que emita el sonido si uno de estos es establecido para 1. De otro modo, ésto no hace nada.
net/ipv4/icmp_echo_ignore_all = 0
Si usted no quiere bloquear ICMP sobre su cortafuego, permira ésto.
net/ipv4/tcp_syncookies = 1
Ésta opción es una espada de doble filo. Por otra parte su sistema está protegido contra la inundación de syn; por otra parte viola las normas definidas (RFCs). Esta opción es totalmente muda, como cuando usted inunda otro lado que está iniudado, así que el otro lado también está ocopado. Si usted quiere cambiar está opción usted también puede cambiar ésto dentro de /etc/network/options para colocar syncookies=yes.
/proc/sys/net/ipv4/conf/all/log_martians = 1
Los paquetes con direcciones imposibles (debido a las rutas incorectas) sobre el registro que obtuvo su red.
Este es un ejemplo del ajuste en otro material útil. Usted debería añadir ésta
información dentro de la escritura de
/etc/network/interface-secure
(el nombre dado como un ejemplo) y
es llamado desde /etc/network/interfaces
como éste:
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
# Script-name: /etc/network/interface-secure # Modifies some default behaviour in order to secure against # some TCP/IP spoofing & attacks # # Contributed by Dariusz Puchalak # echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts # broadcast echo protection enabled echo 0 > /proc/sys/net/ipv4/ip_forward # ip forwarding disabled echo 1 > /proc/sys/net/ipv4/tcp_syncookies # TCP syn cookie protection enabled echo 1 >/proc/sys/net/ipv4/conf/all/log_martians # Log packets with impossible addresses # but be careful with this on heavy loaded web serversecho 1 > /proc/sys/net/ipv4/ip_always_defrag # defragging protection always enabledecho 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses # bad error message protection enabled # now ip spoofing protection for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f done # and finally some more things: # Disable ICMP Redirect Acceptance for f in /proc/sys/net/ipv4/conf/*/accept_redirects; do echo 0 > $f done for f in /proc/sys/net/ipv4/conf/*/send_redirects; do echo 0 > $f done # Disable Source Routed Packets for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do echo 0 > $f done # Log Spoofed Packets, Source Routed Packets, Redirect Packets for f in /proc/sys/net/ipv4/conf/*/log_martians; do echo 1 > $f done
Para tener la capacidad del cortafuego, para proteger el sistema local u otros
detrás de este, el kernel necesita estar compidalo con las capacidades
del cortefuego. El Debian normal 2.2 kernel (también 2.2) susmistra el paquete
de filtro del cortafuego ipchains
, el kernel normal de Debian 3.0
(kernel 2.4) suministra el poderoso paquete de filtros de cortafuegos
iptables
(filtro de la red). Las distribucines más viejas de
Debian necesitan el parche apropiado del kernel (Debian 2.1 usa el kernel
2.0.34).
En todo caso, es bastante fácil usar un kernel diferente al suministrado por
Debian. Usted puede encontrar paquetes de kernel pre-compilados que puede
instalar fácilmente en el sistemas de Debian. Usted tambiém puede obtener las
fuentes del kernel usando kernel-source-X
y armar paquetes de
kernel personalizados con make-kpkg
.
Configurando los cortafuegos en Debian se discute más a fondo en Añadir capacidades al cortafuegos, Sección 5.15.
Debian GNU/Linux suministra algunos de los parches para el kernel de Linux que aumentan su aseguramiento. Estos incluyen:
lids-2.2.19
)
lcap
)
trustees
)
selinux
también
disponible desde the
developer's website
)
kernel-patch-2.2.19-harden
lcap
kernel-patch-freeswan
)
kernel-patch-int
Copiar los archivos de una manera segura desde un computador a otros puede ser logrados usando 'scp' que está incluido en el paquete ssh. Esto funciona como rcp pero es completamente encriptado, así los tipos malos ni siquiera pueden averiguar QUE copia usted.
Tener una buena política de quotas es importante, esto abstiene a los usuarios de llenar el disco duro.
Usted puede usar dos sistemas diferentes de quotas: quota de usuario y quota de grupo. Como usted provablemente dedujo, la quota del usuario límita la cantidad de espacio del que un usuario puede disponer, la quota del grupo hace lo equivalente para los grupos. Tenga en cuenta ésto cuando esté organizando el tamaño de quotas.
Hay algunos puntos importantes para considerar acerca de la configuración del sistema de quotas:
/home
como también en /tmp
.
Cada partición/directorio al que los usuarios tienen acceso completo de escritura deberían permitir el uso de quotas. Encuentre esas divisiones y directorios y calcule un tamaño de quota trabajable, que combine el uso y la seguridad.
Ahora que usted quiere usar quotas. Primero que todo usted necesita revisar que habilito el uso de quotas en el kernel. Si no, usted necesitará recompilarla. Después de ésto dése cuenta que el paquete 'quota' esté instalado. Si no está usted necesitará este.
Habilitar la quota para los respectivos sistemas de archivos es tan fácil como
modificar la configuración inicial ajustándola a
defaults,usrquota en su archivo /etc/fstab
. Si
usted necesita un quota para grupos, sustituya usrquota por
grpquota. Puede usar ambos. Luego cree unos archivos quota.user
y quota.group vacios en la raíz de los sistemas de archivos en los que usted
quiera usar quotas (Ej. con touch /home/quota.user
/home/quota.group para el sistema de archivos /home
).
Reinicie la quota haciendo /etc/init.d/quota stop;/etc/init.d/quota start. Ahora la quota debería estar ejecuténdose, y los tamaños de las quoatas pueden establecerse.
Modificar quotas para un usuario específico (digamos 'ref') puede hacerse con edquota -u ref. Los grupos de quotas se pueden modificar con edquota -g <group>. Después establezca el límite suave y duro para las quotas y/o quotas de i-nodos cuando sea necesario.
Para más información acerca de las quotas, lea el manual de páginas sobre las
quotas, y el mini-howto
(/usr/share/doc/HOWTO/en-html/mini/Quota.html
).
Usted puede o no gustar de lshell
, el cual viola el FHS. También
debe tener un cuenta que pam_limits. puede suministrar la misma funcionalidad
que lshell
el cual es huérfano actualmente. orphaned
Estos dos comandos son muy útiles, pero solo funcionan con el sistema de archivos ext2. Con 'lsattr' puede listar los atributos de un campo, y con 'chattr' puede cambiarlos. Note que los atributos no son l amisma cosa que los permisos. Hay muchos atributos, pero solamente menciono los más importantes para incrementar la seguridad. Hay dos flags los cuales solamente los puede establecer el superusuario.
En primer lugar está flag 'a'. Si se establece un archivo, este archivo puede
ser abierto solamente para añadir. Este atributo es útil para algunos archivos
en /var/log/
,aunque se podría considerar que fuesen quitados
algunas veces debido a la rotación de scripts de registro.
La segunda flag es 'i', en corto immutable. Si se establece un archivo, no puede ser modificado ni borrado o renombrado y no se creará ningún link hacia él. Si no quiere que los usuarios miren en sus archivos la configuración puede establecer este flag y quitar el permiso de lectura. Más aun, ésto puede darle un poco más de seguridad contra los atacantes, porque el cracker puede confundirse al no ser capaz de borrar un un archivo. De todos modos, nunca debería asumir que el cracker es ciego. Despeés de toso ha entrado en su sistema.
Note que lsattr y chattr estan disponibles solamente en los sistemas de archivos ext2.
¿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 archivo oculto o
la envía por un correo claro pro todoel internet?
El único método para tener alguna protección es comprobar sus archivos cada
día/hora/mes (yo prefiero cada día) comparando la vieja md5sum y la actual.
Dos archivos no pueden tener la misma md5sum, de modo que anda sobre seguro
aquí, excepto alquien que hackeó el algoroitmo para crear md5sums un la
máquina. Esto es bueno, extremadamente difícil y muy improbable. Realmente
usted debería considerar que auditar sus binarios es muy importante, ya que es
un modo fácil para reconocer los cambios en sus binarios. Las herramientas que
comúnmente se uaan para ésto son sXid
, AIDE
(Ambientación Avanzada de Detección de Intrusos), TripWire
(no es
libre; la nueva versió será GPL), integrit
y samhain
.
Instalando debsums ayudará a revisar la integración de los archivos del sistema para comparar el md5sums de todos los archivos en contra de md5sums usado en el paquete del archivo Debian. Tenga cuidado con algunos archivos porque pueden ser fácilmente cambiados.
Además puede reemplazar locate
por slocate
. slocate
es una versión mejorada para la seguridad de local de GNU. Cuando usa slocate
el usuario solomante ve los archivos a los que el tiene acceso y puede excluir
cualquier archivo o directorio del sistema.
Debian sumunistra un trabajo cron que diariamente corre en
/etc/cron.daily/standard
. Este trabajo cron ejecutará el script
/usr/sbin/checksecurity
que almacenará la información de estos
cambios.
Para que este chequeo sea hecho usted debe colocar
CHECKSECURITY_DISABLE="FALSE" dentro de
/etc/checksecurity.conf
. Note, que este es el predeterminado, a
menos de que usted haya cambiado algo, esta opción será colocada como
"FALSE".
El comportamiento por defecto no manda la información al superusuario, pero en
cambio guarda diariamente copias de los cambios dentro de
/var/log/setuid.changes
. Usted debe colocar el
CHECKSECURITY_EMAIL (dentro de /etc/checksecurity.conf
) a 'root'.
Mire checksecurity(8)
para mas información de configuración.
SVGAlib es muy bueno para los amantes de la consola como yo, pero durante mucho
tiempo se ha comprobado que esto ha sido muy inseguro. Han sido liberadas
fallas en contra de zgv
y era sencillo convertirse en root.
Intente evitar el uso de programas que usen SVGAlib siempre que sea posible.
Manual de Seguridad de Debian
Version: 2.4 (revisión de traducción 3), Mon, 16 May 2005 21:28:04 +0200jfs@debian.org