Re: Traducción del manual de seguridad al español: nota a traductores
Javier Fernández-Sanguino Peña wrote:
¿Me podría alguien enviar las últimas versiones de los ficheros SGML para que
los ponga en el CVS?
Yo en su día le envié el fichero faq.sgml actualizado y corregido a
David (ender).
Vuelvo a enviar el fichero por si no está subido al cvs. La mala
notica es que desde que lo actualicé hasta ahora mi disco duro decidió
auto inmolarse y este fichero lo he recuperado del backup.
Existe una mínima posibilidad de que no sea exactamente la misma
revisión que envié en su día.
<chapt>Preguntas Frecuentes
<p>
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 - Lee el puto Manual).
<sect>La seguridad en el sistema operativo Debian
<sect1>¿Es más seguro Debian que X?
<p>Un sistema es tan seguro como su administrador sea capaz de hacerlo.
La instalación predeterminada de servicios en Debian trata de ser
<em>segura</em>,
pero puede no ser tan paranoica como la de otros sistemas operativos que
instalan todos los servicios <em>deshabilitados de manera
predeterminada</em>. 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
<url id="http://www.cert.org/stats/cert_stats.html"; name="estadísticas de US-CERT"> o
generar estadísticas usando la <url id="http://nvd.nist.gov/statistics.cfm"; name="National Vulnerability Database">(antes conocida como ICAT).
¿Son útiles estos datos?
La página 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.<footnote>Por
ejemplo, teniendo en cuenta algunos datos, puede parecer que
Windows NT es más seguro que Linux, lo que es una afirmación cuestionable.
Después de todo, las distribuciones de Linux proporcionan habitualmente
muchas más aplicaciones comparadas con Windows NT de Microsoft. En
<url id="http://www.dwheeler.com/oss_fs_why.html#security"; name="Why Open Source Software / Free Software (OSS/FS)? Look at the Numbers!"> David A. Wheeler describe cuestiones acerca del <em>recuento de vulnerabilidades</em>.
</footnote> Tenga también en mente que alguna de las vulnerabilidades
que afectan a Debian se aplican sólo a la rama
<em>«unstable»</em>.
<sect2>¿Es Debian más segura que las otras distribuciones de Linux (como RedHat, SuSE...)?
<p>En realidad no hay 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 de Linux.
<p>Por ejemplo, RedHat tuvo la mala suerte de distribuirse 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
ya incorporaba el parche al fallo. Ésto es lo que sucedió con el problema en <url
id="http://www.cert.org/advisories/CA-2000-17.html"; name="rpc.statd">
hace unos años.
<p>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 coordinar por el desarrollador original o por el
<url id="http://cert.org"; name="CERT">.
Como resultado, las actualizaciones de seguridad necesarias suelen liberarse
al mismo tiempo y la seguridad relativa entre las diferentes distribuciones
es muy similar.
<p>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 <prgn>apt</prgn>.
Aquí hay algunos otros aspectos a considerar acerca de la seguridad de Debian:
<list>
<item>Debian proporciona más herramientas de seguridad que otras
distribuciones, mire en <ref id="sec-tools">.
<item>La instalación estándar de Debian es más pequeña (con menos
funcionalidad) y por lo tanto más segura. Otras distribuciones, en favor de
la usabilidad, tienden a instalar muchos servicios de manera predeterminada y,
algunas veces, éstos no están bien configurados (recuerde los
<url id="http://www.sans.org/y2k/lion.htm"; name="gusanos Ramen o Lion">).
La instalación de Debian no está tan limitada como la de OpenBSD (donde no hay
servicios activados de forma predeterminada), pero es un buen término medio.
<footnote>Sin descontar el hecho de que algunas distribuciones como RedHat o
Mandrake, están tomando en serio la seguridad de sus instalaciones
predeterminadas haciendo que el usuario seleccione <em>perfiles de
seguridad</em>, o mediante asistentes para ayudar en la configuración de
<em>cortafuegos personales</em>.</footnote>
<item>Debian documenta las mejores prácticas de seguridad en documentos como
éste.
</list>
<sect1>Hay muchos errores de Debian en Bugtraq. ¿Significa eso que es muy vulnerable?
<p>La distribución Debian contiene un gran y creciente número de paquetes de
software, 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.
<p>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
listas como Bugtraq.
<p>Los fallos que están presentes en la distribución Debian también afectan
habitualmente a otros fabricantes y distribuciones. Revise la sección
"Debian specific: yes/no" al comienzo de cada aviso DSA).
<sect1>¿Tiene Debian alguna certificación relacionada con la seguridad?
<p>Respuesta corta: no.
<p>Respuesta larga: las certificaciones cuestan dinero (especialmente una certificación
de seguridad <em>seria</em>) y nadie ha dedicado los recursos para certificar a
Debian GNU/Linux a ningún nivel de, por ejemplo, <url id="http://niap.nist.gov/cc-scheme/st/"; name="Common Criteria">.
Si está interesado en obtener una distribución certificada, trate de proporcionar los recursos para que ello
sea posible.
<p>Hay al menos dos distribuciones de Linux certificadas a distintos niveles
<url id="http://en.wikipedia.org/wiki/Evaluation_Assurance_Level"; name="EAL">
Tenga en cuenta que algunas de las pruebas «CC» se están integrando en el proyecto
<url id="http://ltp.sourceforge.net"; name="Linux Testing Project"> que está disponible en
Debian en el paquete <package>ltp</package>.
<sect1>¿Hay algún programa de aseguración para Debian?
<p>Sí. <url name="Bastille Linux" id="http://www.bastille-linux.org";>,
originalmente orientado hacia otras distribuciones de Linux (RedHat
y Mandrake), actualmente funciona para Debian. Se están dando pasos
para integrar los cambios hechos a la versión original en el
paquete Debian llamado <package>bastille</package>.
<p>Sin embargo, algunas personas creen que una herramienta de
aseguración no elimina la necesidad de una buena administración.
<sect1>Quiero ejecutar el servicio XYZ, ¿cuál debería elegir?
<p>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 FTP, servidores WEB, etc.). Eso
puede resultar confuso para el administrador novel al tratar de determinar
qué paquete es el adecuado. La mejor opción para una situación concreta se
basa en el equilibrio entre su funcionalidad y los requerimientos de
seguridad. Hay algunas preguntas que debería hacerse antes de decidir entre
paquetes similares:
<list>
<item>¿Se mantiene el programa original? ¿Cuando fue su última publicación?
<item>¿Está el paquete maduro? El número de versión
<em>no</em> informa realmente acerca de su madurez. Trate de indagar acerca de la
historia del programa.
<item>¿Está el programa libre de fallos? ¿Han salido avisos de seguridad
relacionados con él?
<item>¿Proporciona el programa todas las funcionalidades que necesita?
¿Proporciona más de lo que realmente necesita?
</list>
<sect1>¿Cómo puedo hacer el servicio XYZ más seguro en Debian?
<!-- Changed to XYZ in order to avoid confusion :) jfs -->
<p>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 son aplicables a Debian. En la mayoría de los casos,
asegurar un servicio X en Debian es como asegurar ese mismo servicio en
cualquier otra distribución de Linux (o Un*x).
<sect1>¿Cómo puedo eliminar todos los mensajes de cabecera de los servidores?
<p>Si no le gusta que los usuarios se conecten a su servidor POP3, por
ejemplo, y obtengan información sobre su sistema, puede querer eliminar (o
cambiar) el mensaje que los servidores muestran a los usuarios.
<footnote>Tenga en cuenta que eso es «seguridad por oscuridad», y que
probablemente no sea efectivo a largo plazo.</footnote> La forma de hacer eso
depende del programa que esté ejecutando para un servicio determinado. Por
ejemplo, en
<prgn>postfix</prgn>, puede configurar el mensaje de SMTP en
<file>/etc/postfix/main.cf</file>:
<example>
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
</example>
<p>Otros programas no son tan fáciles de cambiar. <package>OpenSSH</package>
se tiene que recompilar para cambiar la versión que muestra.
Tenga cuidado con no eliminar la primera parte (<tt>SSH-2.0</tt>) del mensaje, que muchos clientes usan para identificar qué protocolo(s) soporta su paquete.
<sect1>¿Son seguros todos los paquetes de Debian?
<p>El equipo de seguridad de Debian posiblemente no pueda analizar 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.
<!-- FIXME kernel-audit doesn't exist on sourceforge:
y de otros
proyectos como <url name="Proyecto de auditoría de seguridad del kernel de Linux" id="http://kernel-audit.sourceforge.net/";>,
o el <url name="Proyecto de auditoría de seguridad de Linux" id="http://www.lsap.org/";>.
-->
<p>De hecho, un desarrollador de Debian podría distribuir un troyano en
un paquete y no habría forma posible de comprobarlo. Incluso si se introdujera
en una rama de Debian, sería imposible cubrir todas las posibles
situaciones en las que un troyano podría ejecutarse. Esa es la razón por la
que Debian tiene una cláusula de <em>«no garantías»</em> en su licencia.
<p>Aun así, los usuarios de Debian tienen 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. No es recomendable instalar programas no probados en
un sistema crítico (si no puede hacer la auditoría de código necesaria). En
cualquier caso, si se introdujera 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 este tema a la ligera.
<sect1>¿Por qué algunos archivos de registro/configuración tienen permiso de
lectura para todos? ¿No es eso inseguro?
<p>Por supuesto 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 <em>salvo</em>
que tengan información sensible.
<p>Sea cuidadoso si hace cambios porque:
<list>
<item>Los procesos pueden no ser capaces de escribir en los archivos de
registro si restringe sus permisos.
<item>Algunas aplicaciones pueden no funcionar si no pueden leer el archivo
de configuración. Por ejemplo, si elimina los permisos de lectura para todos
de <file>/etc/samba/smb.conf</file>, el programa <prgn>smbclient</prgn> no
funcionará cuando lo ejecute un usuario normal.
</list>
<p>ARREGLAME: Comprobar si esto está escrito en la Política. Algunos
paquetes (p.e. demonios ftp) parece que usan permisos diferentes.
<sect1>¿Por qué /root/ (o usuarioX) tiene permisos 755?
<p>La mismas preguntas, de hecho, se aplican a cualquier otro usuario. Como
la instalación de Debian no pone <em>ningún</em> archivo en ese directorio,
no hay información sensible que proteger. Si piensa que esos permisos son
demasiado permisivos para su sistema, considere la posibilidad de asegurarlos a 750. Para
los usuarios lea <ref id="limit-user-perm">.
<p>Este <url
id="http://lists.debian.org/debian-devel/2000/debian-devel-200011/msg00783.html";
name= "hilo de discusión"> de la lista de seguridad de Debian tiene más
información acerca de este tema.
<sect1>¡Tras instalar un grsec/cortafuegos he empezado a recibir muchos
mensajes de consola! ¿Cómo puedo eliminarlos?
<p>Si está recibiendo mensajes de consola y tiene configurado
<file>/etc/syslog.conf</file> para enviarlos a archivos o a un TTY especial,
puede estar viendo los mensajes que se envían directamente a la consola.
<p>El nivel de registro 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.
<p>Para reducir los mensajes que se envían a la consola puede usar
la opción <prgn>dmesg</prgn> (<tt>-n</tt>, mire <manref section="8"
name="dmesg">), que examina y <em>controla</em> el anillo de memoria intermedia del
kernel. Para solucionar esto en el próximo inicio, cambie
<file>/etc/init.d/klogd</file> de:
<example>
KLOGD=""
</example>
<p>a:
<example>
KLOGD="-c 4"
</example>
<p>Use un número menor en <tt>-c</tt> si aun así los ve. Puede encontrar una
descripción de los diferentes niveles de log en <file>/usr/include/sys/syslog.h</file>:
<example>
#define LOG_EMERG 0 /* sistema inutilizable */
#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 */
</example>
<sect1>Usuarios y grupos del sistema operativo
<sect2>¿Son necesarios todos los usuarios del sistema?
<p>Si y no. Debian viene con algunos usuarios predeterminados (id de usuario
(UID) < 99 como se describe en las <url name="Directrices de Debian"
id="http://www.debian.org/doc/debian-policy/";> o <file>/usr/share/doc/base-passwd/README</file>)
para facilitar la instalación de algunos servicios que requieren que se
ejecuten bajo el usuario/UID adecuado. Si no tiene intención de instalar
nuevos servicios puede eliminar tranquilamente los usuarios que no tengan ningún archivo
en su sistema y no ejecuten ningún servicio. En cualquier
caso, el comportamiento predeterminado en Debian es que los UIDs del 0 al 99 se
reservan y los UIDs del 100 al 999 se crean por los paquetes
cuando se instalan (y se eliminan cuando el paquete se elimina
completamente).
<p>Para encontrar fácilmente los usuarios que no tienen ningún archivo
ejecute la orden (como root, ya que un usuario común puede no tener
permisos para ir por algunos directorios sensibles):
<!-- Tómese la libertad de hacer más seguro este script ... >:^) // era -->
<example>
cut -f 1 -d : /etc/passwd | \
while read i; do find / -user "$i" | grep -q . && echo "$i"; done
</example>
<p>Estos usuarios los crea el paquete <package>base-passwd</package>. 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:
<list>
<item>root: Root es (típicamente) el súper usuario.
<item>daemon: Algunos servicios sin privilegios que necesitan escribir en
archivos del del disco se ejecutan como daemon.daemon (p.e., <prgn>portmap</prgn>,
<prgn>atd</prgn>, y probablemente otros). Los servicios que no necesitan
tener ningún archivo pueden correr como nobody.nogroup, algunos otros servicios más
complejos se ejecutan con usuarios dedicados. El usuario daemon es
también útil para servicios instalados localmente.
<item>bin: mantenido por razones históricas.
<item>sys: igual que bin. Aun así, /dev/vcs* y
<file>/var/spool/cups</file> son del usuario y grupo sys.
<item>sync: La consola del usuario sync es <file>/bin/sync</file>. Así que si se pone una
contraseña fácil de adivinar (como ""), cualquiera puede sincronizar
el sistema en la consola incluso si no tiene cuenta.
<item>games: Muchos juegos tienen SETGID a games, de manera que puedan escribir sus
propios archivos de puntuación más alta. Se explica en la política.
<item>man: El programa man (a veces) se ejecuta con el usuario man, para que
pueda escribir páginas en <file>/var/cache/man</file>.
<item>lp: Usado por los servicios de impresión.
<item>mail: los buzones de <file>/var/mail</file> son del grupo mail, como
se explica en la política. El usuario y grupo los usan también con otros propósitos
varios MTAs.
<item>news: Varios servidores de noticias y programas asociados (como <prgn>suck</prgn>)
utilizan el usuario y grupo news de varias formas. Los archivos en la cola de noticias
normalmente son del usuario y grupo news. Programas como <prgn>inews</prgn>
que pueden usarse para enviar noticias tienen normalmente SETGID para el grupo news.
<item>uucp: El usuario y grupo uucp lo usa el subsistema UUCP. Tiene
su propia cola y archivos de configuración. Los usuarios en el grupo uucp
pueden ejecutar uucico.
<item>proxy: Como daemon, este usuario y grupo lo usan algunos servicios
(especialmente servicios de proxy) que no tienen usuarios dedicados y
necesitan tener archivos. Por ejemplo el grupo proxy lo usan
<prgn>pdnsd</prgn>, y <prgn>squid</prgn>.
<item>majordom: <prgn>Majordomo</prgn> tiene un UID estático en los sistemas
Debian por razones históricas. No se instala en sistemas nuevos.
<item>postgres: Las bases de datos de <prgn>Postgresql</prgn> son de este
usuario y grupo. Todos los archivos de <file>/var/lib/postgresql</file> son
de este usuario para reforzar la seguridad.
<item>www-data: Algunos servidores web corren como www-data. El contenido
*no* debe ser de este usuario o un servidor comprometido podría reescribir
el web. Los datos escritos por el servidor web incluyendo los archivos de
registro, deben ser de www-data.
<item>backup: Muchas funciones de copia/restauración pueden ser delegadas a
alguien sin privilegios completos de root.
<item>operator: Operator es históricamente (y prácticamente) el único
«usuario» que puede acceder al sistema de forma remota y no depende de
NIS/NFS.
<item>list: Los archivos de listas de correo y sus datos son de este usuario
y grupo. Algunos programas de listas de correo pueden ejecutarse también con
este usuario.
<item>irc: Usado por servicios de IRC. Se necesita un usuario estático
únicamente por un error de <prgn>ircd</prgn>, que hace SETUID() de si mismo
a un UID determinado en el arranque.
<item>gnats.
<item>nobody, nogroup: Los servicios que no necesitan ningún archivo se
ejecutan con el usuario nobody y grupo nogroup. Así que no debería existir
ningún archivo de este usuario o grupo en el sistema.
</list>
<p>Otros grupos que no tienen un usuario asociado:
<list>
<item>adm: El grupo adm se usa para tareas de monitorización del sistema.
Los miembros de este grupo pueden leer muchos de los archivos de <file>/var/log</file>,
y pueden usar xconsole. Históricamente <file>/var/log</file> era
<file>/usr/adm</file> (y más tarde <file>/var/adm</file>), de ahí el nombre del grupo.
<item>tty: Los dispositivos TTY son de este grupo. Lo usan
write y wall para escribir en los TTYs de otras personas.
<item>disk: Acceso directo a disco. Prácticamente equivalente al acceso de
root.
<item>kmem: Este grupo tiene acceso de lectura a /dev/kmem y archivos similares.
Esto es, prácticamente, una reliquia de BSD pero algunos programas que siguen necesitando
acceso directo de lectura a la memoria del sistema lo hacen con SETGID kmem.
<item>dialout: Acceso directo y completo a los puertos serie. Los miembros
de este grupo pueden reconfigurar el módem, llamar a cualquier parte, etc.
<item>dip: El nombre del grupo viene de «Dial-up IP», y ser miembro de dip le
permite usar herramientas como <prgn>ppp</prgn>, <prgn>dip</prgn>,
<prgn>wvdial</prgn>, 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 usan.
<item>fax: Permite a sus miembros usar el programa de fax para enviar /
recibir faxes.
<item>voice: Voicemail, útil para sistemas que usan módems como
contestadores.
<item>cdrom: Este grupo se puede usar localmente para dar acceso al CDROM
a un conjunto de usuarios.
<item>floppy: Este grupo se puede usar localmente para dar acceso a la
disquetera a un conjunto de usuarios.
<item>tape: Este grupo se puede usar localmente para dar acceso a la
unidad de cinta a un conjunto de usuarios.
<item>sudo: Los miembros de este grupo no necesitan teclear la contraseña
cuando usen el programa <prgn>sudo</prgn>. Mire
<file>/usr/share/doc/sudo/OPTIONS</file>.
<item>audio: Este grupo se puede usar localmente para dar acceso
al dispositivo de audio a un conjunto de usuarios.
<item>src: Este grupo tiene el código fuente, incluyendo los archivos en
<file>/usr/src</file>. Puede usarse para darle a un usuario la capacidad de
gestionar el código fuente del sistema.
<item>shadow: <file>/etc/shadow</file> es legible por este grupo.
Algunos programas que necesitan acceso a este archivo tienen SETGID shadow.
<item>utmp: Este grupo puede escribir en <file>/var/run/utmp</file> y
archivos similares. Los programas que necesitan escribir ahí tienen SETGID utmp.
<item>video: Este grupo se puede usar localmente para dar acceso al dispositivo de video
a un conjunto de usuarios.
<item>staff: Permite a los usuarios añadir modificaciones locales al sistema
(<file>/usr/local</file>, <file>/home</file>) sin necesidad de tener
privilegios de root. Le distingue del grupo «adm» que éste está más relacionado
con monitorización/seguridad.
<item>users: Mientras que los sistemas Debian usan grupos de usuario
privados de forma predeterminada (cada usuario tiene su propio grupo), algunos
prefieren un sistema de grupos más tradicional, en el que cada usuario es
miembro de este grupo.
</list>
<sect2>¡He borrado un usuario de sistema! ¿Cómo puedo recuperarlo?
<p>Si ha borrado un usuario de sistema y no ha hecho una copia de seguridad de sus archivos
<file>password</file> y <file>group</file> puede intentar remediar esta situación usando
<prgn>update-passwd</prgn> (consulte
<manref name="update-passwd" section="8">).
<sect2>¿Qué diferencia hay entre los grupos adm y staff?
<p>Al grupo «adm» pertenecen habitualmente administradores y los permisos de este
grupo permiten leer los archivos de registro sin tener que usar
<prgn>su</prgn>. El grupo «staff» es habitualmente personal de soporte a usuarios o
administradores junior a los que se les permite trabajar en <file>/usr/local</file>
y crear directorios en <file>/home</file>.
<sect1>¿Por qué se crea un nuevo grupo cuando añado un nuevo usuario? (O ¿Por
qué Debian crea un grupo para cada usuario?)
<p>El comportamiento predeterminado de Debian consiste en que cada usuario
tiene su propio grupo privado. El esquema tradicional de UN*X asigna todos los
usuarios al grupo <em>users</em>. 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»).
<p>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, a los archivos creados en ese directorio
se les asigna automáticamente el grupo correcto. Eso facilita las cosas a la
gente que trabaja en múltiples proyectos porque no tienen que cambiar grupos
o umasks cuando usan o comparten archivos.
<p>Puede, sin embargo, cambiar este comportamiento modificando
<file>/etc/adduser.conf</file>. Cambie la variable <em>USERGROUPS</em> a «no»,
para que no se cree un grupo cuando se cree un usuario. Cambie también
<em>USERS_GID</em> al GID del grupo de usuarios al que pertenecerán
los usuarios.
<sect1>Preguntas acerca de servicios y puertos abiertos
<sect2>¿Por qué están todos los servicios activados tras la instalación?
<p>Es una aproximación al problema de ser, por un lado conscientes de la seguridad
y por otro lado amigables para el usuario.
Al contrario que OpenBSD, que deshabilita los servicios a no ser que los
active el administrador, Debian GNU/Linux habilitará todos los servicios
instalados a no ser que se desactiven (mire en <ref id="disableserv"> para
ver más información). Después de todo usted instaló el servicio ¿no es así?
<p>Ha habido muchas discusiones en las listas de correo de Debian
(en ambas, debian-devel y debian-security) acerca de cual sería la mejor
aproximación en una instalación predeterminada. Sin embargo, mientras se
escribía este documento (marzo 2002) no se ha alcanzado aún un consenso.
<sect2>¿Puedo eliminar inetd?
<p><prgn>Inetd</prgn> no es fácil de eliminar porque
<package>netbase</package> depende del paquete que lo proporciona
(<package>netkit-inetd</package>).
Si quiere deshabilitarlo (mire <ref id="disableserv"> o elimínelo
usando el paquete <package>equivs</package>).
<sect2>¿Por qué tengo abierto el puerto 111?
<p>El puerto 111 es el mapeador de puertos de sunrpc, se instala de manera
predeterminada como parte del sistema base de Debian porque no se sabe
cuándo un programa necesitará usar RPC para funcionar correctamente.
En cualquier caso, se usa principalmente en NFS. Si no lo
necesita, elimínelo tal y como se explica en <ref id="rpc">.
<p>En versiones del paquete <package>portmap</package> superiores a la 5-5
puede tener el mapeador de puertos instalado pero escuchando sólo en el equipo local. (modificando
<file>/etc/default/portmap</file>)
<sect2>¿Para qué se usa <prgn>identd</prgn> (puerto 113)?
<p>El servicio identd es un servicio de autenticación que identifica al
propietario 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,
el <prgn>inetd</prgn> de dicho servidor le devuelve una consulta al
puerto 113 para encontrar la información del propietario. 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.
<p>Ha habido discusiones extensas acerca de la seguridad de
<prgn>identd</prgn> (mire los <url
id="http://lists.debian.org/debian-security/2001/debian-security-200108/msg00297.html";
name="archivos de las listas de correo">).
Por lo general, <prgn>identd</prgn> es más útil en un sistema multiusuario
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 hacia el exterior.
Si decide cerrar el puerto identd con el cortafuegos,
<em>por favor</em>, hágalo usando una política de rechazo (reject) en vez de
ignorar (drop) los paquetes, de lo contrario la conexión al servidor que usa
<prgn>identd</prgn> se quedará «colgada» hasta que expire un contador (consulte
<url id="http://logi.cc/linux/reject_or_deny.php3"; name=" acerca de rechazar o ignorar">).
<sect2>Tengo servicios usando los puertos 1 y 6, ¿qué son y cómo puedo quitarlos?
<p>Si ejecuta la orden <tt>netstat -an</tt> y obtiene:
<example>
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
PID/Program name
raw 0 0 0.0.0.0:1 0.0.0.0:* 7
-
raw 0 0 0.0.0.0:6 0.0.0.0:* 7
-
</example>
<p><em>No</em> está viendo procesos escuchando en los puertos TCP/UDP 1 y 6.
En realidad está viendo un proceso que escucha en un «socket» en modo <em>raw</em>
para los protocolos 1 (ICMP) y 6 (TCP). Este comportamiento es común tanto en troyanos
como en algunos sistemas de detección de intrusiones como
<package>iplogger</package> y
<package>portsentry</package>. Si tiene instalados esos paquetes simplemente elimínelos.
Si no, pruebe la opción <tt>-p</tt> (proceso) de netstat para ver cuál es el proceso que está escuchando.
<sect2>He encontrado el puerto XYZ abierto, ¿puedo cerrarlo?
<p>Por supuesto que puede. Los puertos que deje abiertos deben acogerse
a su política de seguridad acerca de servicios disponibles públicamente desde
otras redes. Compruebe si los abre <prgn>inetd</prgn>
(vea <ref id="inetd">) o algún otro paquete instalado y
tome las medidas oportunas (p.e, configure inetd, desinstale el paquete, deshabilite que se arranque en el inicio).
<sect2>¿Ayudará a asegurar mi equipo si borro los servicios de <file>/etc/services</file>?
<p><em>No</em>, <file>/etc/services</file> sólo suministra una correspondencia
entre el nombre virtual y un determinado número de puerto. Borrar los nombres de
este archivo no evitará (normalmente) que los servicios se inicien.
Algunos servicios podrían no funcionar si se modifica <file>/etc/services</file>,
pero no es lo normal. Para deshabilitar correctamente el servicio consulte
<ref id="disableserv">.
<sect1>Cuestiones habituales de seguridad
<sect2>¡He perdido mi contraseña y no puedo acceder al sistema!
<p>Los pasos que necesita dar para solventar esta situación dependen de si ha aplicado o no
el procedimiento recomendado para limitar el acceso a <prgn>lilo</prgn> y el BIOS de su sistema.
<p>Si lo ha hecho en ambos casos, necesitará deshabilitar la opción del BIOS que permite arrancar sólo
desde el disco duro antes de continuar. Si también ha olvidado la contraseña del BIOS, tendrá que restaurar
su BIOS abriendo su equipo y quitando manualmente la pila del BIOS.
<p>Una vez que ha habilitado el arranque desde un CD-ROM o disquete, intente lo siguiente:
<list>
<item>Arranque desde un disco de arranque e inicie el núcleo.
<item>Vaya a una consola virtual (Alt+F2)
<item>Monte el disco duro donde está su /root
<item>Edite (el disco de rescate Debian 2.2 incluye el editor
<prgn>ae</prgn>, Debian 3.0 incluye <prgn>nano-tiny</prgn>, que
es similar a <prgn>vi</prgn>) <file>/etc/shadow</file> y modifique la
línea:
<example>
root:asdfjl290341274075:XXXX:X:XXXX:X::: (X=cualquier número)
</example>
<p>quedando así:
<example>
root::XXXX:X:XXXX:X:::
</example>
</list>
<p>Ésto borrará la contraseña de root, contenida en el primer campo separado por dos puntos
después del nombre de usuario. Guarde el archivo, reinicie el sistema y entre con el usuario root
sin usar contraseña. Recuerde restaurar la contraseña. Ésto funcionará a menos que haya configurado
el sistema de forma más restrictiva, p.e. no permitiendo a los usuarios tener contraseñas en blanco
o no permitiendo a root acceder desde la consola.
<p>Si ha introducido éstas características, tendrá que entrar necesariamente en modo monousuario.
Si ha restringido LILO, necesitará volver a ejecutar <prgn>lilo</prgn> justo después de restaurar la
contraseña de root por el procedimiento anterior. Ésto es un poco problemático
ya que, al ser la partición raíz (/) un «ramdisk» en lugar del disco duro real,
necesitará falsear su <file>/etc/lilo.conf</file>.
<p>Una vez que haya desprotegido LILO intente lo siguientes:
<list>
<item>Presione Alt, shift o la tecla Control, antes de termine el arranque del BIOS,
debería obtener el símbolo del sistema de LILO.
<item>Teclee <tt>linux single</tt>, <tt>linux init=/bin/sh</tt> o
<tt>linux 1</tt>.
<item>Debería obtener una consola en modo monousuario (le pedirá una contraseña, pero ya la sabe).
<item>Vuelva a montar la partición raíz (/) para lectura y escritura, usando la orden mount.
<example>
#mount -o remount,rw /
</example>
<item>Cambie la contraseña del superusuario con <prgn>passwd</prgn> (como ya es superusuario no le
preguntará por la contraseña anterior).
</list>
<sect1>¿Cómo puedo configurar un servicio para mis usuarios sin tener que crearles una cuenta en el sistema?
<p> Si quiere, por ejemplo, configurar un servicio POP, no necesita crear una cuenta para cada usuario que quiera
acceder. Es mejor configurar autenticación basada en directorios a través de un servicio externo (como Radius,
LDAP o una base de datos SQL.) Simplemente instale la biblioteca PAM adecuada (<package>libpam-radius-auth</package>,
<package>libpam-ldap</package>, <package>libpam-pgsql</package> o <package>libpam-mysql</package>), lea la documentación
(los principiantes pueden consultar <ref id="auth-pam"> ) y configure el servicio que tenga PAM habilitado para que use
la biblioteca adecuada. Ésto se hace editando los archivos relativos a este servicio en <file>/etc/pam.d/</file>
y cambiando
<example>
auth required pam_unix_auth.so shadow nullok use_first_pass
</example>
a, por ejemplo, para ldap:
<example>
auth required pam_ldap.so
</example>
<p> En el caso de los directorios LDAP, algunos servicios proporcionan esquemas LDAP
que debe incluir en su directorio para usar autenticación LDAP. Si usa una base de datos
relacional, un truco útil es usar la cláusula <em>where</em> cuando configure los módulos
PAM. Por ejemplo, si tiene una base de datos con los siguientes atributos de tabla:
<example>
(user_id, user_name, realname, shell, password, UID, GID, homedir, sys, pop, imap, ftp)
</example>
<p> Si define los atributos de los servicios como campos booleanos podrá usarlos para habilitar o deshabilitar
el acceso a los diferentes servicios con sólo insertar las líneas apropiadas en los siguiente archivos:
<list>
<item><file>/etc/pam.d/imap</file>:<tt>where=imap=1</tt>.
<item><file>/etc/pam.d/qpopper</file>:<tt>where=pop=1</tt>.
<item><file>/etc/nss-mysql*.conf</file>:<tt>users.where_clause = user.sys = 1;</tt>.
<item><file>/etc/proftpd.conf</file>:<tt> SQLWhereClause "ftp=1"</tt>.
</list>
<sect id="vulnerable-system">¡Mi sistema es vulnerable! (¿Está seguro?)
<sect1 id="vulnasses-false-positive">!El escáner de vulnerabilidades X
dice que mi sistema es vulnerable¡
<p>Muchos escáneres de vulnerabilidades dan falsos positivos en sistemas Debian
debido a que, para determinar si un programa es vulnerable, sólo comprueban el número de versión,
pero no analizan el fallo de seguridad en sí mismo. Como Debian no cambia la versión de un programa
cuando se se arregla un paquete (muchas veces la solución para versiones modernas se incluye también en las
versiones anteriores), algunas herramientas tienden a pensar que un sistema Debian actualizado es vulnerable,
cuando en realidad no lo es.
<p>Si piensa que su sistema está al día respecto a los parches de seguridad, puede que le interese
usar las referencias cruzadas a bases de datos de fallos de seguridad publicadas con las DSAs
(N.T. Debian Security Advisories - Avisos de seguridad de Debian) (lea <ref id="dsa">) para descartar
falsos positivos si la herramienta que utiliza incluye referencias CVE.
<sect1>He visto un ataque en mis archivos de registro. ¿Está comprometido mi sistema?
<p> La huella de un ataque no siempre significa que se haya comprometido su sistema, debería dar los pasos
habituales para determinar si el sistema ha sido realmente comprometido (mire <ref id="after-compromise">).
Fíjese también en que el hecho de que vea los ataques en el archivo de registro puede significar que su sistema
sigue siendo vulnerable (no obstante un atacante decidido puede haber aprovechado alguna otra vulnerabilidad aparte de la que
usted ha detectado).
<sect1>He encontrado extrañas lineas «MARK» en mis archivos de registro: ¿Estoy comprometido?
<p>Puede que haya encontrado unas líneas como éstas en sus archivos de registro:
<example>
Dec 30 07:33:36 debian -- MARK --
Dec 30 07:53:36 debian -- MARK --
Dec 30 08:13:36 debian -- MARK --
</example>
<p>Ésto no indica ningún tipo de compromiso, los usuarios que cambien de una versión de Debian a otra
pueden encontrarlo extraño. Si su sistema no tiene una carga excesiva (o demasiados servicios activos),
pueden aparecer estas líneas en sus registros. Son una indicación de que su servicio <prgn>syslogd</prgn>
está funcionando correctamente. Extraído de <manref section="8" name="syslogd">:
<example>
-m intervalo
Syslogd registra regularmente una marca de tiempo.
El intervalo predeterminado entre dos líneas -- MARK --
es de 20 minutos. Ésto se puede cambiar con esta opción.
Poniendo el intervalo a cero se desactiva por completo.
</example>
<sect1>He encontrado en mis archivos de registro que los usuarios están usando «su»: ¿Estoy comprometido?
<p>Puede que se encuentre líneas como éstas en sus registros:
<example>
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)
</example>
<p>No se preocupe demasiado, compruebe si estas entradas se deben a tareas programadas por
<prgn>cron</prgn> (normalmente <file>/etc/cron.daily/find</file> o <prgn>logrotate</prgn>):
<example>
$ 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
</example>
<sect1>He encontrado «possible SYN flooding» en mis archivos de registro: ¿Me están atacando?
<p>Si ve entradas como éstas en sus archivos de registro:
<example>
May 1 12:35:25 linux kernel: possible SYN flooding on port X. Sending cookies.
May 1 12:36:25 linux kernel: possible SYN flooding on port X. Sending cookies.
May 1 12:37:25 linux kernel: possible SYN flooding on port X. Sending cookies.
May 1 13:43:11 linux kernel: possible SYN flooding on port X. Sending cookies.
</example>
<p>Compruebe si hay un exceso de conexiones al servidor usando
<prgn>netstat</prgn>, por ejemplo así:
<example>
linux:~# netstat -ant | grep SYN_RECV | wc -l
9000
</example>
<p>Ésto es un indicio de un ataque de denegación de servicio (DoS) contra el puerto X de su sistema
(lo más probable es que se dirija contra un servicio accesible públicamente, como un servidor web o de correo).
Debería activar la opción «TCP syncookies» en su núcleo, mire <ref id="tcp-syncookies">. Fíjese, sin embargo, en que un
ataque DoS puede inundar su red incluso si consigue evitar que su sistema se cuelgue (el equipo puede dejar de responder hasta que caduquen las conexiones TCP si se llegan a agotar los descriptores de ficheros). El único método efectivo
para detener este ataque es ponerse en contacto con su proveedor de servicios de red.
<sect1>He visto extrañas sesiones de root en mis archivos de registro: ¿Estoy comprometido?
<p> Puede que haya visto este tipo de entradas en su archivo
<file>/var/log/auth.log</file>:
<example>
May 2 11:55:02 linux PAM_unix[1477]: (cron) session closed for user root
May 2 11:55:02 linux PAM_unix[1476]: (cron) session closed for user root
May 2 12:00:01 linux PAM_unix[1536]: (cron) session opened for user root by
(UID=0)
May 2 12:00:02 linux PAM_unix[1536]: (cron) session closed for user root
</example>
<p>Éstas se deben a una tarea ejecutada por <prgn>cron</prgn> (en este caso
cada cinco minutos). Para determinar qué programa es el responsable de esas tareas
revise las lineas de:
<file>/etc/crontab</file>, <file>/etc/cron.d</file>,
<file>/etc/crond.daily</file> y el <file>crontab</file> de root en
<file>/var/spool/cron/crontabs</file>.
<sect1>He sufrido una intrusión. ¿Qué debo hacer?
<p> En caso de sufrir una intrusión debe seguir varios pasos:
<list>
<item> Asegúrese de que su sistema está actualizado con los parches de seguridad
adecuados para las vulnerabilidades publicadas. Si su sistema es vulnerable, las
probabilidades de que esté comprometido aumentan. Las probabilidades aumentan más
si la vulnerabilidad es conocida desde hace tiempo, ya que suele haber más actividad
relativa a vulnerabilidades antiguas. Aquí tiene un enlace a
<url id="http://www.sans.org/top20/"; name="SANS Top 20 Security Vulnerabilities">.
<item>Lea este documento, especialmente la sección <ref id="after-compromise">.
<item>Pida ayuda. Puede usar la lista de de correo «debian-security» y
pedir consejo sobre cómo recuperar/parchear su sistema.
<item>Informe a su <url id="http://www.cert.org"; name="CERT"> local (si existe,
de otro modo puede informar directamente al CERT). Ésto puede no serle de mucha ayuda
pero, al menos, mantendrá informado al CERT sobre ataques en curso.
Esta información es muy valiosa para determinar qué herramientas y ataques está usando
la comunidad <em>cracker</em>.
</list>
<sect1>¿Cómo puedo rastrear un ataque?
<p>Mirando los archivos de registro (si no se han modificado), usando sistemas de
detección de intrusos (mire ref id="intrusion-detect">),
<prgn>traceroute</prgn>, <prgn>whois</prgn> y herramientas similares (incluyendo
análisis forense), debería ser capaz de rastrear el origen de un ataque. Su reacción
ante esta información depende solamente de su política de seguridad, y de lo que usted considere
que es un ataque. ¿Un escaneo remoto es un ataque? ¿Una comprobación de una vulnerabilidad es un ataque?
<sect1>El programa X en Debian es vulnerable. ¿Qué hago?
<p> Lo primero, dedicar un tiempo a comprobar si se ha anunciado la vulnerabilidad
en listas públicas de seguridad (como Bugtraq) u otros foros.
El equipo de seguridad de Debian se mantiene al día de lo publicado en esas listas,
así que seguramente estén advertidos del problema. Si ve un anuncio en
<url id="http://security.debian.org";> no hace falta que haga nada más.
<p> Si no parece que se haya publicado ninguna información al respecto, por favor,
envíe un correo electrónico a <url id="mailto:team@security.debian.org"; name="team@security.debian.org">
indicando el paquete o paquetes afectados, así como una descripción detallada de la vulnerabilidad
(también es buena idea enviar el código de una prueba de concepto).
Ésto le pondrá en contacto con el equipo de seguridad de Debian.
<sect1>¡El número de versión de un paquete indica que todavía soy vulnerable!
<p>En vez de actualizar a una nueva versión, Debian incluye los parches de seguridad en
la versión que se publicó en la distribución estable. El motivo es asegurarse de que
la distribución estable se modifique lo menos posible, para que nada cambie o se rompa
por culpa de un parche de seguridad. Puede comprobar si está ejecutando una versión
segura de un paquete mirando su fichero de registro de cambios, o comparando su versión
exacta (versión original -guión- versión en Debian) con la versión indicada en el
aviso de seguridad de Debian.
<sect1>Software específico
<sect2><package>Proftpd</package> es vulnerable a un ataque de denegación de servicio.
<p>Añada <tt>DenyFilter \*.*/</tt> a su archivo de configuración,
para más información consulte
<url id="http://www.proftpd.org/critbugs.html";>.
<sect2> Tras instalar <package>portsentry</package> hay muchos puertos abiertos.
<p>Así es como funciona <prgn>portsentry</prgn>. Abre unos veinte puertos libres para intentar detectar escaneos
de puertos.
<sect id="debian-sec-team-faq">Preguntas acerca del equipo de seguridad de Debian
<p>Esta información está basada en el documento
<url id="http://www.debian.org/security/faq"; name="Debian Security FAQ">.
Incluye la información a partir del 19 de Noviembre y alguna
otra pregunta frecuente en la lista de correo debian.
<sect1>¿Qué es un aviso de seguridad de Debian (DSA)?
<p>Es una nota informativa enviada por el equipo de seguridad de Debian
(ver más abajo), respecto al descubrimiento y solución de una vulnerabilidad de
seguridad de un paquete disponible en Debian GNU/Linux. Los DSAs firmados se envían
a listas de correo públicas (debian-security-announce) y se publican en la página
web de Debian (tanto en la portada como en la <url
id="http://www.debian.org/security/"; name="sección de seguridad">).
<p>Los DSAs incluyen información acerca de el(los) paquete(s)
afectado(s), el fallo descubierto, y desde dónde se pueden obtener los
paquetes actualizados (y sus sumas MD5).
<sect1>¡La firma de los avisos de Debian no se verifica correctamente!
<p>Seguramente el problema sea suyo. La lista de avisos 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.
<p> Probablemente alguno de sus programas de correo modifican ligeramente
el mensaje, corrompiendo la firma. Asegúrese de que sus programas
no hacen ninguna codificación o decodificación MIME, ni haga ninguna conversión
entre espacios y tabuladores.
<p> Un posible culpable es fetchmail (con la codificación MIME
habilitada), formail (de procmail 3.14 únicamente) y evolution.
<sect1>¿Cómo se maneja la seguridad en Debian?
<p>Una vez que el equipo de seguridad recibe la notificación de un
incidente, uno o más miembros lo revisan y valoran su impacto en la
distribución estable de Debian (p.e. si es vulnerable o no). Si la
distribución es vulnerable trabajamos en una solución para el problema.
También se avisa al responsable del paquete, si no se ha puesto ya en contacto
con el equipo de seguridad. Finalmente se prueba la solución y se preparan paquetes nuevos,
que se compilan en todas las arquitecturas de la distribución estable, y después se envían al repositorio.
Cuando todo ésto está terminado, se publica el aviso de seguridad.
<sect1>¿Por qué perdéis el tiempo con una versión tan antigua de ese paquete?
<p> La directriz más importante a la hora de generar un nuevo paquete que arregle un fallo
de seguridad es hacer los mínimos cambios posibles. Nuestros usuarios y desarrolladores
esperan que la nueva versión tenga exactamente el mismo comportamiento que la anterior,
así que cualquier cambio que se haga puede provocar fallos en el funcionamiento de algún
sistema. Ésto es especialmente cierto para las bibliotecas: asegúrese de que nunca cambia
la Interfaz de Programación de Aplicaciones (API) ni la Interfaz Binaria de Aplicación (ABI),
por pequeño que sea el cambio.
<p>Ésto significa que actualizar a una versión nueva del programa original no
es una buena solución, en su lugar se deben introducir las modificaciones relevantes
en las versiones anteriores. Normalmente los desarrolladores originales están dispuestos
a ayudar si es necesario, en caso contrario, el equipo de seguridad de Debian puede ser de ayuda.
<p>En algunos casos no es posible introducir los arreglos de seguridad en las versiones anteriores
de los paquetes, por ejemplo cuando se necesita modificar o reescribir grandes cantidades de código.
Si sucede ésto puede que sea necesario actualizar a una versión más nueva del programa, pero tiene
que coordinarse de antemano con el equipo de seguridad de Debian.
<sect1>¿Cuál es la norma para que un paquete arreglado aparezca en security.debian.org?
<p>Un fallo de seguridad en la distribución estable garantiza un paquete en security.debian.org.
Cualquier otra cosa no lo hace. La cuestión aquí no es la gravedad del fallo. Normalmente
el equipo de seguridad prepara los paquetes en colaboración con el responsable del mismo.
Se designa a alguien (de confianza) que hace un seguimiento al problema, compila y envía
al equipo de seguridad todos los paquetes compilados necesarios, incluso los problemas de seguridad más
triviales pasarán por security.debian.org. Mire a continuación.
<sect1>¡El número de versión de un paquete indica que todavía estoy usando una versión vulnerable!
<p> En lugar de actualizar a una nueva versión, incluimos los arreglos de seguridad en la versión que
se incluyó en a distribución estable. La razón para hacerlo es para estar seguros de que los cambios introducidos
en él son tan mínimos que no provoquen el mal funcionamiento o cambios inesperados a consecuencia del arreglo de seguridad.
Puede comprobar si está ejecutando una versión segura de un paquete mirando su fichero de registro de cambios, o comparando
su número exacto de versión con la versión indicada en el aviso de seguridad de Debian.
<sect1 id="sec-unstable">¿Cómo se maneja la seguridad en <tt>«en pruebas»</tt> e <tt>«inestable»</tt>?
<p>La respuesta corta es: de ninguna manera. «En pruebas» e «inestable» cambian muy rápidamente y el equipo de seguridad
no dispone de los recursos necesarios para dar un soporte adecuado. Si quiere tener un servidor seguro (y estable) le
recomendamos encarecidamente que continué en «estable». Sin embargo, los secretarios del equipo de seguridad intentarán
solucionar los fallos en «en pruebas» e «inestable» una vez que estén solucionados en la distribución estable.
<p>Aún así, en algunos casos, las soluciones a los fallos de seguridad se incluyen rápidamente la rama inestable, porque esos arreglos suelen proporcionarlos rápidamente los autores originales (otras versiones, como las que están en la rama estable,
suelen necesitar que se trabaje en la adaptación).
<sect1 id="sec-older">Soy usuario de una versión antigua de Debian. ¿Proporciona soporte para ella el equipo de seguridad de Debian?
<p>No. Lamentablemente el equipo de seguridad de Debian no puede hacerse cargo de la distribución estable (extraoficialmente
también de «inestable») y además de otras versiones anteriores. De todos modos, puede confiar en que se publicarán actualizaciones de seguridad en un periodo limitado de tiempo (normalmente varios meses) inmediatamente después de la publicación de una nueva distribución de Debian.
<sect1>¿Por qué no hay réplicas oficiales para security.debian.org?
<p> El objetivo de security.debian.org es que las actualizaciones de seguridad estén disponibles a la mayor brevedad posible.
Las réplicas añaden una complejidad adicional que no es necesaria y pueden causar frustración si no están actualizadas.
<sect1>He visto DSA 100 y DSA 102. ¿Qué pasa con DSA 101?
<p> Muchos distribuidores (mayoritariamente de GNU/Linux, pero también de derivados de BSD) coordinan los avisos de seguridad
para algunos incidentes y consensúan un margen concreto de tiempo para que todos puedan lanzar el aviso a la vez.
Ésto se decidió para no discriminar a los distribuidores que necesitan más tiempo (p.e. cuando el distribuidor tiene que pasar los paquetes por largos procesos de garantía de calidad o tiene que dar soporte a varias arquitecturas o distribuciones binarias).
Nuestro propio equipo de seguridad también prepara los avisos con antelación. De vez en cuando tienen que tratarse otros temas de seguridad antes de que se pueda publicar el aviso «aparcado», y por lo tanto se saltan temporalmente uno o más números de aviso.
<sect1>¿Cómo puedo contactar con el equipo de seguridad?
<p> La información sobre seguridad se puede enviar a <url id="mailto:security@debian.org"; name="security@debian.org">,
donde la leerán todos los desarrolladores de Debian. Si tiene información sensible, por favor hágalo a <url id="mailto:team@security.debian.org"; name="team@security.debian.org">, donde sólo la leerán los miembros del equipo de seguridad.
Si quiere, puede enviar correos cifrados con la clave de contacto de seguridad de Debian (identificador de clave <url id="http://pgpkeys.pca.dfn.de:11371/pks/lookup?search=0x363CCD95&op=vindex"; name="0x363CCD95">).
<sect1> ¿Qué diferencia hay entre security@debian.org y debian-security@lists.debian.org?
<p>Cuando envía mensajes a security@debian.org, se envían a la lista de correo de desarrolladores (debian-private).
Todos los desarrolladores están suscritos a esta lista y los mensajes se mantienen en privado (p.e. no se archivan en el sitio web público). La lista de correo pública, debian-security@lists.debian.org está abierta a todo el mundo que quiera <url
id="http://www.debian.org/MailingLists/"; name="suscribirse">, y está disponible la búsqueda en el archivo histórico <url id="http://lists.debian.org/search.html"; name="aquí">.
<sect1> ¿Cómo puedo colaborar con el equipo de seguridad de Debian?
<p>
<list>
<item> Contribuyendo a este documento, arreglando «ARREGLAMEs» o proporcionando nuevo contenido.
La documentación es importante y reduce la sobrecarga de contestar temas repetitivos. La traducción del documento a otros idiomas
también es de gran ayuda.
<item> Empaquetando aplicaciones que sean útiles para comprobar o mejorar la seguridad en un sistema Debian GNU/Linux.
Si no es usted desarrollador, rellene un <url name="informe de fallo WNPP"
id="http://www.debian.org/devel/wnpp/";> y pida software que piense que puede ser útil pero aún no está incluido.
<item>Audite aplicaciones en Debian o ayude a solucionar fallos de seguridad y
comunique los problemas a security@debian.org. El trabajo de otros proyectos como
<url name="Linux Kernel Security Audit Project" id="http://kernel-audit.sourceforge.net/";> o
<url name="Linux Security-Audit Project" id="http://www.lsap.org/";> aumentan la seguridad de Debian GNU/Linux, así que
la contribución a ellos ayudará finalmente aquí también.
</list>
<p>En todos los casos, por favor revise cada problema antes de informar a security@debian.org.
Si es capaz de proporcionar parches ésto aceleraría el proceso. No reenvíe simplemente los correos de Bugtraq,
éstos ya se reciben. Sin embargo, siempre es buena idea proporcionar información adicional.
<sect1>¿Quién compone el equipo de seguridad de Debian?
<p> El equipo de seguridad de Debian actualmente consta de cinco miembros y dos secretarios.
El propio equipo de seguridad designa la gente que se une al equipo.
<sect1>¿El equipo de seguridad comprueba cada paquete en Debian?
<p>No, el equipo de seguridad de Debian no comprueba cada paquete nuevo y no hay comprobaciones automáticas
(lintian) para detectar paquetes nuevos maliciosos, porque esas comprobaciones son prácticamente imposibles de automatizar.
Los desarrolladores, sin embargo, son totalmente responsables de los paquetes que introducen en Debian, y todos los paquetes
se firman primero por un desarrollador(es) autorizado(s). El desarrollador se encarga de analizar la seguridad de todos los paquetes que mantiene.
<sect1> ¿Cuanto tardará Debian en arreglar la vulnerabilidad XXXX?
<p>El equipo de seguridad de Debian trabaja rápido para enviar los avisos y producir los paquetes arreglados para la rama estable
una vez que se descubre una vulnerabilidad. Un informe
<url id="http://lists.debian.org/debian-security/2001/debian-security-200112/msg00257.html"; name="publicado en la lista de correo de seguridad de Debian"> muestra que en el año 2001, el equipo de seguridad de Debian tardó una media de 35 días en arreglar vulnerabilidades relativas a la seguridad. Sin embargo, sobre el 50% de las vulnerabilidades se solucionaron en un margen de 10 días, y sobre el 15% de ellas se arreglaron <em>el mismo día</em> que se publicó el aviso.
<p>Sin embargo, cuando se hace esta pregunta, la gente tiende a olvidar que:
<list>
<item>Los DSAs no se envían hasta que:
<list>
<item> Están disponibles los paquetes para <em>todas</em> las arquitecturas soportadas por Debian
(lo que lleva un tiempo para paquetes que son parte esencial del sistema, especialmente teniendo en cuenta el número
de arquitecturas que soporta la distribución estable.)
<item>Los paquetes nuevos se revisan minuciosamente para asegurar que no se introducen nuevos fallos.
</list>
<item>Los paquetes deberían estar disponibles antes de que se envíe el DSA (en la cola de paquetes entrantes o en las réplicas).
<item>Debian es un proyecto basado en el voluntariado.
<item>La licencia de Debian incluye una clausula de «no garantía».
</list>
<p> Si quiere un análisis más en profundidad sobre el tiempo que invierte el equipo de seguridad
en trabajar en vulnerabilidades, debería tener en cuenta que los DSAs nuevos (mire <ref id="dsa">) publicados
en el <url id="http://security.debian.org"; name="sitio web de seguridad">, y los metadatos usados para generarlos
incluyen enlaces a las bases de datos de vulnerabilidades. Podría descargarse las fuentes desde el servidor web
(desde el <url id="http://cvs.debian.org"; name="CVS">) o usar las páginas HTML para determinar el tiempo que tarda Debian en arreglar
vulnerabilidades y correlacionar estos datos con las bases de datos públicas.
Reply to: