Este capítulo introduce algunas de las preguntas más comunes de la lista de seguridad de Debian. Debería leerlas antes de preguntar o la gente posiblemente le diga RTFM (N.T. Read The Fucking Manual - Lea el P*to Manual).
Un sistema es sólo tan seguro como su administrador es capaz de hacerlo. La
instalación predeterminada de Debian de servicios trata de ser segura,
pero puede no ser tan paranoica como la de otros sistemas operativos que
instalan todos los servicios deshabilitados de manera predeterminada.
En cualquier caso, el administrador del sistema necesita adaptar la seguridad
del sistema a su política de seguridad local. Para ver una recopilación de
datos acerca de vulnerabilidades de seguridad de muchos sistemas operativos
mire en http://securityfocus.com/vulns/stats.shtml
.
¿Le son útiles estos datos? El servidor lista varios factores a considerar
cuando se interpretan los datos y avisa de que los datos no pueden usarse para
comparar las vulnerabilidades de un sistema operativo frente a otro.[5]Tenga también en mente que alguna
de las vulnerabilidades de BugTraq que afectan a Debian se aplican sólo a la
rama unstable.
No hay realmente muchas diferencias entre las distribuciones de Linux más allá de la instalación base y el sistema de gestión de paquetes. La mayoría de las distribuciones comparten las mismas aplicaciones con diferencias fundamentalmente en las versiones de esas aplicaciones que se distribuyen en esa distribución estable. por ejemplo, el núcleo, Bind, Apache, OpenSSH, XFree, gcc, zlib, etc, todas son comunes en las distribuciones Linux.
Por ejemplo, RedHat se distribuyó desafortunadamente cuando era actual la
versión 1.2.3 de foo en la que más tarde se encontró un agujero de seguridad.
Debian, por otro lado, tuvo la suerte de distribuir foo 1.2.4 que incorporaba
el parche al fallo. Ese fue el caso en el problema con rpc.statd
Hace
varios años.
Hay mucha colaboración entre los equipos de seguridad de las distribuciones de
Linux más grandes. Las actualizaciones de seguridad raramente se dejan sin
actualizar en una distribución. El conocimiento acerca de una vulnerabilidad
nunca se esconde a otras distribuciones así que los arreglos se suelen hacer
coordinados, o por el CERT
. Como
resultado, las actualizaciones de seguridad necesarias suelen liberarse al
mismo tiempo y la seguridad relativa entre las diferentes distribuciones es muy
similar.
Una de las mayores ventajas de Debian en relación a la seguridad es la
facilidad del sistema de actualización a través de del uso de apt
.
Aquí hay algún otro aspecto a considerar acerca de la seguridad de Debian:
gusanos Ramen o Lion
). La
instalación de Debian no está tan limitada como OpenBSD (donde no hay demonios
activados de forma predeterminada), pero es un buen compromiso. [6]
La distribución Debian contiene un gran y creciente número de paquetes de programas y probablemente más que los proporcionados por muchos sistemas operativos propietarios. Cuantos más paquetes se instalen, mayor será el riesgo potencial de tener problemas de seguridad para un sistema dado.
Más y más personas están examinando el código fuente en busca de debilidades. Hay muchos avisos acerca de auditorías del código fuente de los componentes más importantes de Debian. Cuando esas auditorías de código fuente descubren vulnerabilidades, se solucionan y se envía un aviso a las listas y a Bugtraq.
Los errores que están presentes en la distribución Debian tambien afectan habitualmente a otros fabricantes y distribuciones. Revise la sección "Debian specific: yes/no" al comienzo de cada aviso DSA).
Respuesta corta: no.
Respuesta larga: las certificaciones cuestan dinero y nadie ha dedicado los recursos para certificar a Debian GNU/Linux a ningún nivel de, por ejemplo, el "Common Criteria". Si está interesado en obtener una distribución certificada, pruebe a proporcionar los recursos para que ello sea posible.
Sí. Bastille Linux
,
originalmente orientado hacia otras distribuciones de Linux (RedHat y
Mandrake), actualmente funciona para Debian. Los pasos están siendo tomados
para integrar los cambios hechos a la versión original al paquete Debian
llamado bastille
.
Sin embargo, algunas personas creen que una herramienta de securización no elimina la necesidad de una buena administración.
Una de las mayores fortalezas de Debian es la gran variedad de elecciones posibles entre paquetes que proporcionan la misma funcionalidad (servidores de DNS, servidores de correo, servidores de FTP, servidores WEB, etc.). Eso puede resultar confuso para el administrador novel al tratar de determinar que paquete es el adecuado. La mejor opción para una situación concreta se basa en el compromiso entre su funcionalidad y los requerimientos de seguridad. Hay algunas preguntas que debe contestar antes de decidir entre paquetes similares:
Puede encontrar información en este documento acerca de cómo hacer algunos servicios (FTP, Bind) más seguros en Debian GNU/Linux. Para los servicios que no se cubran aquí, mire la documentación del programa o información general sobre Linux. La mayoría de las guías de seguridad para sistemas Unix también se aplican a Debian. En la mayoría de los casos, securizar un servicio X en Debian es como securizar ese mismo servicio en cualquier otra distribución de Linux (o Un*x).
Si no le gusta que los usuarios se conecten a su servidor POP4, por ejemplo, y
obtengan información sobre sus sitema, puede querer eliminar (o cambiar) el
mensaje que los servidores muestran a los usuarios. [7] El hacer eso depende del programa
que esté ejecutando para un servicio determinado. Por ejemplo, en
postfix
, puede configurar el mensaje de SMTP en
/etc/postfix/main.cf
:
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
Otros programas no son tan fáciles de cambiar. OpenSSH
tiene que
ser recompilado para poderse cambiar la versión que muestra. Tenga cuidado con
no eliminar la primera parte (SSH-2.0) del mensaje, que muchos
clientes usan para identificar qué protocolo(s) soporta su paquete.
El equipo de seguridad de Debian no puede analizar posiblemente todos los
paquetes incluidos en Debian en busca de vulnerabilidades potenciales porque
simplemente, no tienen recursos suficientes para auditar todo el código fuente
del proyecto. De todas formas Debian se beneficia de la auditoría de código
hecha por los desarrolladores de los proyectos originales y de otros proyectos
como Proyecto de auditoría
de seguridad del kernel de Linux
, o el Proyecto de auditoría de seguridad de
Linux
.
De todas formas un desarrollador Debian podría distribuir un troyano en un paquete y no habría forma posible de comprobarlo. Incluso si se introduce en una rama de Debian, podría ser imposible cubrir todas las posibles situaciones en las que un troyano puede ejecutarse. Esa es la razón por la que Debian tiene una cláusula de "no garantías" en su licencia.
Aun así, los usuarios de Debian tiene confianza en el hecho de que el código estable tiene una gran audiencia y la mayoría de los problemas pueden descubrirse con el uso. Instalar programas no probados no es recomendable en un sistema crítico (si no puede hacer la auditoría de código necesaria). En cualquier caso, si se introduce una vulnerabilidad de seguridad en una distribución, el proceso que se usa para incluir paquetes (usando firma digital) asegura que el problema puede seguirse hasta el desarrollador. El proyecto Debian no se ha tomado a la ligera este tema.
Por supuesto que puede cambiar los permisos predeterminados de Debian en sus sistemas. La política actual acerca de los archivos de registro y configuración es que tienen permisos de lectura para todos salvo que tengan información sensible.
Sea cuidadoso si hace cambios porque:
/etc/samba/smb.conf
, el programa smbclient
no
funcionará cuando lo ejecute un usuario normal.
ARREGLAME: Comprobar si esto está escrito en la Política. Algunos paquetes (p.e. demonios ftp) parece que usan permisos diferentes.
La mismas preguntas, de hecho, se aplican a cualquier otro usuario. Como la instalación de Debian no pone ningún archivo en ese directorio, no hay información sensible que proteger. Si piensa que esos permisos son demasiado permisivos para su sistema, considere en asegurarlos a 750. Para los usuarios lea Limitando el acceso a la información de otros usuarios, Sección 4.8.1.1.
Este hilo
de discusión
de la lista de seguridad de Debian tiene más
información acerca de ésto.
Si está recibiendo mensajes de consola y tiene configurado
/etc/syslog.conf
para enviarlos a archivos o a un TTY especial,
puede estar viendo los mensajes que se envían directamente a la consola.
El nivel de log predeterminado de la consola para cualquier núcleo es 7, lo que significa que cualquier mensaje con una prioridad menor aparecerá en la consola. Habitualmente, los cortafuegos (la regla LOG) y algunas otras herramientas de seguridad usan prioridades menores, que por lo tanto, se envían directamente a la consola.
Para reducir los mensajes que se envían a la consola puede usar la opción
dmesg
(-n, mire dmesg(8)
), que examina y
controla el anillo del buffer del kernel. Para solucionar esto en el
próximo inicio, cambie /etc/init.d/klogd
de:
KLOGD=""
a:
KLOGD="-c 4"
Use un número menor en -c si aun así los ve. Puede encontrar una
descripción de los diferentes niveles de log en
/usr/include/sys/syslog.h
:
#define LOG_EMERG 0 /* sistema no usable */ #define LOG_ALERT 1 /* se debe actuar inmediatamente */ #define LOG_CRIT 2 /* condiciones críticas */ #define LOG_ERR 3 /* condición de error */ #define LOG_WARNING 4 /* condición de aviso */ #define LOG_NOTICE 5 /* condiciones normales pero significativas */ #define LOG_INFO 6 /* informativo */ #define LOG_DEBUG 7 /* mensajes de depuración */
Si y no. Debian viene con algunos usuarios predeterminados (id de usuario
(UID) < 99 como está descrito en la Política de Debian
o
/usr/share/doc/base-passwd/README
) para facilitar la instalación
de algunos servicios que requieren que se ejecute bajo el usuario/UID adecuado.
Si no tiene intención de instalar nuevos servicios puede eliminar los usuarios
que no tengan ningún archivo en su sistema y no ejecuten ningún servicio
tranquilamente. En cualquier caso, el comportamiento predeterminado es que los
UIDs del 0 al 99 se reservan en Debian y los UIDs del 100 al 999 se crean por
los paquetes cuando se instalan (y se eliminan cuando el paquete se elimina
completamente).
Para encontrar fácilmente los usuarios que no tienen ningún archivo ejecute el comando (como root ya que un usuario común puede no tener permisos para ir por algunos directorios sensibles):
cut -f 1 -d : /etc/passwd | \ while read i; do find / -user "$i" | grep -q . && echo "$i"; done
Estos usuarios son del paquete base-passwd
. Mire en su
documentación si quiere más información acerca de cómo se gestionan estos
usuarios en Debian. La lista de usuarios predeterminados (con su grupo
correspondiente) es la siguiente:
portmap
,
atd
, y probablemente otros). Los demonios que no necesitan tener
ningún archivo corren como nobody.nogroup, algunos otros demonios más complejos
se ejecutan con usuarios dedicados. El usuario del demonio es también útil
para demonios instalados localmente.
/var/spool/cups
son del
usuario y grupo sys.
/bin/sync
. Aun así si su
contraseña se pone fácil de adivinar (como ""), cualquiera puede
sincronizar el sistema en la consola incluso si no tiene cuenta.
/var/cache/man
.
/var/mail
son del grupo mail, como se explica
en la política. El usuario y grupo se usan también con otros propósitos por
varios MTAs.
suck
) usan el usuario y grupo news de varias formas. Los archivos
en la cola news son habitualmente del usuario y grupo news. Programas como
inews
que pueden usarse para enviar noticias son típicamente
noticias con SETGID.
pdnsd
, y
squid
.
Majordomo
tiene un UID estático en sistemas Debian por
razones históricas. No se instala en sistemas nuevos.
Postgresql
son de este usuario y
grupo. Todos los archvos de /var/lib/postgresql
son de este
usuario para reforzar la seguridad.
ircd
, que hace SETUID()s de si mismo a un UID
determinado en el arranque.
Otros grupos que no tienen un usuario asociado:
/var/log
, y pueden usar xconsole. Históricamente
/var/log
eran /usr/adm
(y más tarde
/var/adm
), del mismo grupo.
ppp
, dip
,
wvdial
, etc. para comenzar una conexión. La mayoría de los
usuarios de este grupo no pueden configurar el módem, pero pueden ejecutar
programas que lo usa.
sudo
. Mire /usr/share/doc/sudo/OPTIONS
.
/usr/src
. Puede usarse para darle al usuario la capacidad de
gestionar el sistema de código fuente.
/etc/shadow
es de lectura para este grupo. Algunos
programas que necesitan acceso a este archivo tienen SETGID shadow.
/var/run/utmp
y archivos
similares. Los programas que necesitan escribir ahí tienen SETGID utmp.
/usr/local
, /home
) sin necesidad de tener
privilegios de root. Comparar con el grupo "adm", que está más
relacionado con monitorización/seguridad.
El grupo 'adm' son habitualmente administradores y los permisos de este grupo
permiten leer los archivos de registro son tener que usar su
. El
grupo 'staff' es útil en soporte, administradores junior porque les permite
trabajar en /usr/local
y crear directorios en /home
.
El comportamiento predeterminado de Debian consiste en que cada usuario tiene su grupo privado. El esquema tradicional de UN*X asigna todos los usuarios al grupo users. Los grupos adicionales se creaban y se usaban para restringir el acceso a los archivos compartidos asociados a directorios de proyectos diferentes. La gestión de archivos era difícil cuando un usuario trabajaba en múltiples proyectos porque cuando alguien creaba un archivo, este se asociaba al grupo principal al que perteneciera (ej. 'users').
El esquema de Debian soluciona este problema asignando a cada usuario su propio grupo; así que con la máscara adecuada (0002) y el bit SETGID habilitado en un directorio dado, el grupo correcto se asigna adecuadamente para los archivos creados en ese directorio. Eso hace más fácil para la gente que trabaja en múltiples proyectos porque no tienen que cambiar grupos o umasks cuando trabajan o comparten archivos.
Puede, como siempre, cambiar este comportamiento modificando
/etc/adduser.conf
. Cambiar la variable USERGROUPS a
'no', de tal forma que no se cree un grupo cuando se cree un usuario. También
poner USERS_GID al GID del grupo de usuarios al que pertenecerán los
usuarios.
Es una aproximación al problema de, por una parte la seguridad y por otra la usabilidad. Al contrario que como OpenBSD, deshabilita los servicios a no ser que los habilite el administrador, Debian GNU/Linux habilitará todos los servicios instalados a no ser que se desactiven (mire en Deshabilitar los demonios, Sección 3.6.1 para ver más información). Después de todo usted instaló el servicio ¿no es así?
Han habido muchas discusiones con las listas del correo en Debian (las dos, Debian-devel y debian-security) acerca de cual sería una mejor aproximación en la instalación predeterminada. Sin embargo, mientras se escribía este documento (marzo 2002) no se ha alcanzado un consenso.
Inetd
no es fácil de eliminar porque netbase
depende
del paquete que lo provee (netkit-inetd
). Si quiere
deshabilitarlo (mire Deshabilitar los
demonios, Sección 3.6.1 o elimine el paquete usando el paquete
equivs
).
El puerto 111 es el portmapper de sunrpc y se instala de manera predeterminada como parte del sistema base de Debian porque no se sabe cuando un programa de usuario necesitará usar RPC para funcionar correctamente. En cualquier caso, se usa mayormente en NFS. Si no lo necesita, elimínelo tal y como se explica en Desactivar los servicios RPC, Sección 5.14.
identd
(puerto 113)?
El servicio identd es un servicio de autenticación que identifica al usuario de
una conexión TCP/IP concreta al servidor remoto que acepta la conexión.
Típicamente cuando un usuario se conecta a un servidor remoto,
inetd
del servidor remoto le manda de vuelta una consulta al
puerto 113 para encontrar la información del usuario. Esto se usa
habitualmente en servidores de correo, FTP e IRC, también puede usarse para
conocer qué usuarios de sus sistema local están atacando un sistema remoto.
Han habido discusiones extensas acerca de la seguridad de identd
(mire los archivos
de las listas de correo
). Por lo general, identd
es
más útil en un sistema multi-usuario que en una estación de trabajo de un sólo
usuario. Si no tiene por qué usarlo, deshabilítelo de tal forma que no deje un
servicio abierto para el resto del mundo. Si decide cerrar con el cortafuegos
el puerto identd, por favor hágalo usando una política de rechazo
(reject) en vez de ignorar (drop) los paquetes, de otra forma la conexión al
servidor que usa identd
tendrá que expirar y se colgará hasta que
lo haga (mire rechazar
o ignorar
).
Por supuesto que puede, usted puede ir dejando los portales abiertos en su sitio de política, fortaleciendo los servicios públicos disponibles para otros sistemas. Revise si estos son abiertos por inetd (observe Deshabilitar los servicios inetd, Sección 3.6.2) o por otros paquetes instalados y tómelo en medidas apropiadas (configure inetd, remueva el paquete, anule el funcionamiento en bootup...).
/etc/services
,estoy en lo cierto?
No, /etc/services
solo suministra un mapping desde un
nombre virtual a un acceso numérico dado, removiendo nombres desde (usualmente)
donde no haya que impedir servicios al ser iniciados. Algunos demonios no
podrán funcionar si /etc/services
ha sido modificado, pero ésta no
es la norma y no es la vía recomendable para hacerlo, observe Deshabilitar los demonios, Sección 3.6.1.
Usted necesita seguir unos pasos para recuperar su password y este depende desi usted ha aplicado o no el procedimiento para limitar el acceso a Lilo y BIOS.
Si usted ha limitado a ambos. Necesita desactivar las características de BIOS (hágalo solo desde el disco duro) antes de proceder, además, si usted olvida el password de BIOS, tendrá que abrir el sistema y eliminar la batería BIOS manualmente.
Si usted tiene un bootup en la unidad de cd-rom o en un disco habilitado, usted puede:
ae
, Debian 3.0
viene con nano-tiny
, el cual es similar a vi
)
/etc/shadow
y modifique la línea:
root:asdfjl290341274075:XXXX:X:XXXX:X::: (X=cualquier número)
para:
root::XXXX:X:XXXX:X:::
Este removerá la clave del administrador. Usted puede iniciar el sistema y entrar como root desde el login: entre como root (con una clave vacía). Esto funcionará, a menos que usted haya configurado el sistema más firmemente, por ejemplo, si usted ha permitido usuarios con claves nulas y el administrador puede entrar puede entrar al sistema desde la consola.
Si usted ha introducido también estas características, usted necesitará entrar
en el modo single. LILO no necesita ser limitado si usted ha hecho esto
también, necesitará reiniciar lilo
justo después que el
administrador lo reajusta. Esto es totalmente difícil desde que su
/etc/lilo.conf
necesite ser atrapado por tener un / sistema de
archivo, que es un disco de la memoria ram y no del verdadero disco duro.
Una vez que LILO no sea restringido, usted puede:
mount -o remount,rw /
passwd
(desde que usted sea
el superusuario, no se le solicitará la clave anterior).
Lea este documento y tome las medidas necesarias descritas aquí. Si necesita asistencia, usted puede usar debian-security@lists.debian.org para solicitar consejos sobre cómo recuperar /parche y arreglar su sistema.
Observando las bitácoras (si ellas no han sido cambiadas), usando sistemas de
detección de intrusión (observe Montar
el descubrimiento de intrusión, Sección 9.1), traceroute
,
whois
y herramientas similares (incluyendo análisis forense),
usted puede encontrar un ataque a la fuente. La manera como usted debería
reaccionar frente a esta información depende, solamente del uso apropiado que
usted le de a la política de seguridad y que usted considere lo que es
un ataque. ¿Es un scanner remoto un ataque? ¿Un ataque es una prueba de
vulnerabilidad?
Tómese un momento. Primero, observe si la vulnerabilidad ha sido anunciada en
listas de correo de seguridad pública (como Bugtraq) u otros foros, el equipo
de seguridad Debian permanece actualizado con estas listas, de manera que ellos
ya pueden estar enterados del problema. No ejecute ningunas acciones remotas
si usted ya observa algún anuncio en http://security.debian.org
.
Si no observa nada de lo anteriormente nombrado, por favor envíe un correo a los paquetes afectados, XXXtan bién como una descripción de la vulnerabilidad, tan detallada como sea posible (demuestre si el concepto de código también es correcto) para security@debian.org , el cual lo accederá a un análisis con el equipo de seguridad.
En lugar de actualizar una nueva descarga, podemos fijar la seguridad en backport, a la versión que fue enviada en la descarga establecida. La razón de esto es asegurarnos que una descarga cambie posiblemente un poco algunas cosas o que se interrumpan repentinamente, como un resultado de la seguridad fija. Usted puede chequear si está corriendo una versión segura de un paquete, observando el paquete changelog o comparando su número de versión exacta (versión upstream -slash- descargar debian)el número de la versión exacta con la versión indicada en el Asesor de seguridad Debian.
Usted puede encontrar líneas en sus bitácoras como:
Apr 1 09:25:01 server su[30315]: + ??? root-nobody Apr 1 09:25:01 server PAM_unix[30315]: (su) session opened for user nobody by (uid=0)
No se preocupe tanto, revise si esto se debe a un trabajo en funcionamiento a
través de cron (usualmente con /etc/cron.daily/find
o
logrotate
):
$ grep 25 /etc/crontab 25 6 * * * root test -e /usr/sbin/anacron || run-parts --report /etc/cron.daily $ grep nobody /etc/cron.daily/* find:cd / && updatedb --localuser=nobody 2>/dev/null
Agregue DenyFilter \*.*/ a su archivo de configuración, para más
información observe http://www.proftpd.org/critbugs.html
.
Ésta es una información enviada por el equipo de seguridad Debian (observe en
la parte de abajo), informando acerca de un ajuste de una seguridad relacionada
a la vulnerabilidad disponible para el sistema operativo Debian. Los ASDs
firmados, son enviados a las listas de correo público y anunciado en la página
web de Debian (tanto en la página frontal como en el área de seguridad security area
).
Las DSA incluyen información acerca de el(los) paquete(s) afectado(s), el error descubierto y donde se pueden obtener los paquetes actualizados (y sus sumas MD5).
Probablemente este sea un problema suyo. La lista de anuncios de seguridad de Debian tiene un filtro que solamente permite el envío de mensajes con una firma correcta de uno de los miembros del equipo de seguridad.
Probablemente alguna pieza de los programas de correo de su parte, hace cambios menores en los mensajes rompiendo la firma. Asegúrese que sus programas no no hacen ninguna codificación o decodificación MIME, o haya conversión de tabuladores a espacio.
Un posible culpable es fetchmail (con la codificación MIME habilitada) y formail (de procmail 3.14 únicamente).
Una vez el equipo de seguridad recibe una notificación de un incidente , uno o mas miembros lo revisan y consideran a Debian /estable vulnerable o no. Si nuestro sistema es vulnerable este es trabajado sobre el ajuste del problema. El paquete se mantiene en buen contacto siempre y cuando no haya contacto ahora con la seguridad del equipo. Finalmente el ajuste es probado y los nuevos paquetes son preparados, los cuales entonces son compilados sobre toda la arquitectura estable y son transferidos de un computador, de la perifería al centro, después de que toda esta labor se hace el asesor de la seguridad (DAS) es enviado a los correos de lista pública.
Analizando el tiempo que tarda la seguridad del equipo Debian , al enviar un acesor y producir paquetes ajustados es mínimo. Una vez es conocida la vulnerabilidad, ésta se ajusta a la distribución estable rápidamete.
Un reporte publicado published
in the debian-security mailinglist
mostró que en el año 2001, este
tomó el equipo de seguridade Debian, un termino medio de 35 días para ajustar
la seguridad vulnerable relacionada, Sin embargo, sobre el 50% de las
vulnerabilidades fueron ajustados en 10 días y el 15% fueron ajustados
algunos díaslos avisos que fueron registrados.
Sin embargo, cuando se formula está pregunta la gente se hace estas preguntas trata de no olvidar que:
la respuesta corta es:esto no es. La prueba y lo inestable, son rápidamente movidos objetivamente, y el equipo de seguridad no tiene los medios apropiados que necesita para soportarlos, si usted quiere tener un servicio seguro (y estable), usted está motivado a trabajar con lo estable.
Sin embargo, como un hecho real lo inestable, usualmente es arreglado rápidamente,para la seguridad de datos actualizada. Algunas veces estos son usualmente obstenidos en versiones rápidas (otra versiones posteriores que se necesitan usualmente son backported).
A: el objetivo de seguridad.debian.org, es permitir actualizaciones de seguridad de la forma más rápida y fácil posible. Las réplicas añadirían complejidad extra innecesaria y pueden la causar frustraciones si no están actualizados.
A: La información de seguridad puede ser enviada a la seguridad Debian org, la cual es leída por todo el operador Debian. Si usted tiene información sensitiva , por favor use el equipo@ de seguridad Debian org, que solamente los miembros de seguridad del equipo pueden leer. Si desea correo puede ser codificado con la seguridad Debian contacte la clave (ID 363CCD95)
Cuando usted envia mensajes a la seguridad @Debian org y Debian. Estos son enviados a los reveladores de la lista de correo (Debian-privada) todos estos están suscritos a los reveladores Debian, al enviar esta lista son guardados privadamente ( i.e no son archivados en el web publico).Debian security@lists.debian.org es una lista de correos pública, a bierta para quien quiera inscribirse, y hay archivos disponibles en la página web.
WNPP
bug
y solicite al sesoftware lo que usted considera útil y no es
comúnmente proporcionado.
Linux Kernel
Security Audit Project
or the Linux Security-Audit Project
incrementa
la seguridad de Dbian GNU/linux desde contribuciones , que eventualmente
ayudarán también.
En algunos casos por favor, revise cada problema antes de reportarlo para la security@ debian org. Si usted es capaz de proporcionar parches que agilisen el proceso sabiamente. No simplemente enviar mails bugtraq, desde que ellos todavía sean recibdos. Sin embargo es una buena idea proporcionar información adicional.
Normalmente el equipo de seguridad Debian consta de cinco miembros y dos secretarios. El equipo de seguridad designa las personas para unirlas al equipo.
No, la seguridad de los equipos Debian no revisa cada paquete nuevo ni hay un chequeo automático (lintian) para detectar defectos en los paquetes nuevos, desde esas revisiones es imposible detectarlos automáticamente . Sin embargo mantenerlos es completamente responsabilidad de el software que es introducido en Debian y no en software, y no un software que nisiquiera es asiganado por un revelador autorizado.Ellos estan encargados de analizar el software y mantenerlo en la seguridad de aviso.
Infortunadamente no , la seguridad del equipo Debian no puede manejar la descarga estable de éste, (también inestable) y otras antiguas descargas . Sin embargo usted puede esperar la seguridad de la información actualizada por un periodo límite de tiempo justo , a un despues de que la distribución del nuevo Debian sea descargada.
Manual de Seguridad de Debian
Version: 2.4 (revisión de traducción 3), Mon, 16 May 2005 21:28:04 +0200jfs@debian.org