[ anterior ] [ Contenidos ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ siguiente ]

Manual de Seguridad de Debian
Capítulo 11 - Preguntas Frecuentes


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


11.1 La Seguridad en el Sistema Operativo Debian


11.1.1 ¿Es más seguro Debian que X?

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.


11.1.1.1 ¿Es Debian más segura que las otras distribuciones de Linux (como RedHat, SuSE...)?

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:


11.1.2 Hay muchos errores de Debian en Bugtraq. ¿Significa eso que es muy vulnerable?

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


11.1.3 ¿Tiene Debian alguna certificación relacionada con la seguridad?

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.


11.1.4 ¿Hay algún programa de securización para Debian?

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.


11.1.5 Quiero ejecutar el servicio XYZ, ¿cuál debería elegir?

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:


11.1.6 ¿Cómo puedo hacer el servicio XYZ más seguro en Debian?

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


11.1.7 ¿Cómo puedo eliminar todos los mensajes de los servidores?

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.


11.1.8 ¿Son seguros todos los paquetes de Debian?

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.


11.1.9 ¿Por qué algunos archivos de registro/configuración tienen permiso de lectura para todos? ¿No es eso inseguro?

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:

ARREGLAME: Comprobar si esto está escrito en la Política. Algunos paquetes (p.e. demonios ftp) parece que usan permisos diferentes.


11.1.10 ¿Por qué /root/ (o usuarioX) tiene permisos 755?

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.


11.1.11 ¡Tras instalar un grsec/cortafuegos he empezado a recibir muchos mensajes de consola! ¿Cómo puedo eliminarlos?

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

11.1.12 Usuarios y grupos del sistema operativo


11.1.12.1 ¿Son necesarios todos los usuarios del sistema?

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:

Otros grupos que no tienen un usuario asociado:


11.1.12.2 ¿Qué diferencia hay entre el grupo adm y el staff?

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.


11.1.13 ¿Por qué se crea un nuevo grupo cuando añado un nuevo usuario? (O ¿Por qué Debian crea un grupo para cada usuario?)

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.


11.1.14 Preguntas acerca de servicios y accesos abiertos


11.1.14.1 ¿Por qué están todos los servicios activados tras la instalación?

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.


11.1.14.2 ¿Puedo eliminar inetd?

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


11.1.14.3 ¿Por qué tengo abierto el puerto 111?

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.


11.1.14.4 ¿Cual es el uso de 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).


11.1.14.5 ¿Yo he chequeado y tengo el siguiente acceso (xyz) y puedo cerrarlo?

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


11.1.14.6 ¿He removido los servicios desde /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.


11.1.15 ¡¡He perdido mi password y no puedo tener acceso al sistema!!

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:

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:


11.2 ¡Mi sistema es vulnerable!


11.2.1 He sufrido una interrupción, ¿qué debo hacer?

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.


11.2.2 ¿Cómo puedo encontrar el origen de un ataque?

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?


11.2.3 Cualquier programa en Debian es vulnerable ¿Qué debo hacer?

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.


11.2.4 El número de versión para un paquete indica que todavía estoy corriendo una versión vulnerable

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.


11.2.5 Encontré usuarios haciendo 'su' en mis bitácoras

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

11.2.6 Software específico


11.2.6.1 Proftpd es vulnerable a un ataque en el servicio Denial.

Agregue DenyFilter \*.*/ a su archivo de configuración, para más información observe http://www.proftpd.org/critbugs.html.


11.3 Preguntas con respecto al equipo de seguridad Debian


11.3.1 Lo que es una Advertencia de Seguridad Debian (DSA).

É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).


11.3.2 La firma sobre de la advertencia de Debian no es verificada correctamente.

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


11.3.3 Como se tratan los incidentes de seguridad en Debian?

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.


11.3.4 ¿Cuánto tiempo tomará Debian para ajustar la vulnerabilidad?

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:


11.4 Cómo es manejada la seguridad para prueba y inestable?

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


11.4.1 ¿Por qué no hay réplicas oficiales de security.debian.org?

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.


11.4.2 ¿Cómo puedo buscar el equipo de seguridad?

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)


11.4.3 ¿Qué diferencia hay entre seguridad @ Debian org y la lista de seguridad Debian org?

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.


11.4.4 ¿Cómo puedo contribuir con el equipo de seguridad Debian?

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.


11.4.5 ¿Quiénes componen el equipo de seguridad debian?

Normalmente el equipo de seguridad Debian consta de cinco miembros y dos secretarios. El equipo de seguridad designa las personas para unirlas al equipo.


11.4.6 ¿La seguridad debian del equipo revisa los nuevos paquetes en debian?

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.


11.4.7 ¿Yo tengo una antigua versión sobre Debian , está soportada la seguridad?

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.


[ anterior ] [ Contenidos ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ siguiente ]

Manual de Seguridad de Debian

2.4 (revisión de traducción 3) 14 febrero 2004 Tue, 30 Apr 2002 15:41:13 +0200

Javier Fernández-Sanguino Peña jfs@computer.org