
<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 - Lea el P*to Manual).
 

<sect>La seguridad en el sistema operativo Debian

<sect1>¿Es más seguro Debian que X?
<p>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
<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://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.<footnote>Por
ejemplo, teniendo en cuenta los datos de Securityfocus, 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.</footnote>Tenga también en mente que alguna de las
vulnerabilidades de BugTraq 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>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.

<p>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 <url
id="http://www.cert.org/advisories/CA-2000-17.html" name="rpc.statd">
Hace varios 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 hacer coordinados, 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 algún otro aspecto 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 demanera predeterminada y
algunas veces, 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 OpenBSD (donde no hay
demonios activados de forma predeterminada), pero es un buen compromiso.
<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
este.

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

<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 las
listas y a Bugtraq.

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


<sect1>¿Tiene Debian alguna certificación relacionada con la seguridad?

<p>Respuesta corta: no.

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

<sect1>¿Hay algún programa de securización para Debian?

<p>Sí. <url name="Bastille Linux" id="http://www.bastille-unix.org">,
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 <package>bastille</package>.

<p>Sin embargo, algunas personas creen que una herramienta de
securizació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 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:

<list>

<item>¿Se mantiene el programa original? Cuando fué su última versión?

<item>¿Está el paquete maduro? El número de versión realmente
<em>no</em> no informa acerca de su madurez. Trate de indagar acerca de la
historia del programa.

<item>¿Está el programa libre de errores? ¿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 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).

<sect1>¿Cómo puedo eliminar todos los mensajes de los servidores?

<p>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.
<footnote>Dese cuenta que eso es 'seguridad por oscuridad', y que
probablemente no tenga un buen efecto a largo plazo.</footnote> El 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>
tiene que ser recompilado para poderse 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 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 <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 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 <em>"no garantías"</em> en su licencia.

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

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

<p>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 <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 los 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 en 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 ésto.

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

<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 del buffer 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 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 */
</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) &lt; 99 como está descrito en la <url name="Política 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
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).

<p>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):

<!-- 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 son del 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 super usuario.

<item>daemon: Algunos demonios 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 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.

<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 shell del usuario sync es <file>/bin/sync</file>. 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.

<item>games: Muchos juegos tienen SETGID 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 demonios 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 se usan también con otros propósitos
por varios MTAs.

<item>news: Varios servidores de noticias y programas asociados (como <prgn>suck</prgn>) 
usan el usuario y grupo news de varias formas. Los archivos en la cola news
son habitualmente del usuario y grupo news. Programas como <prgn>inews</prgn> 
que pueden usarse para enviar noticias son típicamente noticias con SETGID.

<item>uucp: El usuario y grupo uucp es usado por 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 demonios
(especialmente demonios 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 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 archvos 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 demonios de IRC. Un usuario determinado se necesita
únicamente por un error de <prgn>ircd</prgn>, que hace SETUID()s de si mismo
a un UID determinado en el arranque.

<item>gnats.

<item>nobody, nogroup: Los demonios 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> eran
<file>/usr/adm</file> (y más tarde <file>/var/adm</file>), del mismo 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. Mayormente equivalente al acceso de
root.

<item>kmem: /dev/kmem y archivos similares son accesibles en modo lectura
por este grupo. Esto es, mayormente, una reliquia de BSD pero algunos
programas siguen necesitando acceso directo de lectura a la memoria del sistema
que se hace 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 de ese grupo 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 usa.

<item>fax: Permite a los miembros usar el programa de fax para enviar /
recibir faxes.

<item>voice: Voicemail, usado por sistemas que usan módems como
contestadores.

<item>cdrom: Este grupo puede ser usado localmente para dar acceso al CDROM
a los usuarios.

<item>floppy: Este grupo puede ser usado localmente para dar acceso a la
disquetera a los usuarios.

<item>tape: Este grupo puede ser usado localmente para dar acceso a la
cinta a los 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 puede ser usado localmente para dar acceso a los
usuarios al dispositivo de audio.

<item>src: Este grupo tiene el código fuente incluyendo los archivos de
<file>/usr/src</file>. Puede usarse para darle al usuario la capacidad de
gestionar el sistema de código fuente.

<item>shadow: <file>/etc/shadow</file> es de lectura para 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 puede ser usado para dar a los usuarios acceso al
dispositivo de video.

<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. Comparar con el grupo "adm", que está más relacionado
con monitorización/seguridad.

<item>users: Mientras los sistemas Debian usan el sistema de usuarios
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>¿Qué diferencia hay entre el grupo adm y el staff?

<p>El grupo 'adm' son habitualmente administradores y los permisos de este
grupo permiten leer los archivos de registro son tener que usar
<prgn>su</prgn>. El grupo 'staff' es útil en soporte, administradores junior
porque 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 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, 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.

<p>Puede, como siempre, cambiar este comportamiento modificando
<file>/etc/adduser.conf</file>. Cambiar la variable <em>USERGROUPS</em> a 'no',
de tal forma que no se cree un grupo cuando se cree un usuario. También
poner <em>USERS_GID</em> al GID del grupo de usuarios al que pertenecerán
los usuarios.


<sect1>Preguntas acerca de servicios y accesos abiertos

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

<p>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 <ref id="disableserv"> para
ver más información). Después de todo usted instaló el servicio ¿no es así?

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

<sect2>¿Puedo eliminar inetd?

<p><prgn>Inetd</prgn> no es fácil de eliminar porque 
<package>netbase</package> depende del paquete que lo provee
(<package>netkit-inetd</package>). 
Si quiere deshabilitarlo (mire <ref id="disableserv"> o elimine el paquete
usando el paquete <package>equivs</package>).

<sect2>¿Por qué tengo abierto el puerto 111?

<p>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 <ref id="rpc">.

<sect2>¿Cual es el uso de <prgn>identd</prgn> (puerto 113)?

<p>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, 
<prgn>inetd</prgn> 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.

<p>Han 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 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,
<em>por favor</em> 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
<prgn>identd</prgn> tendrá que expirar y se colgará hasta que lo haga (mire
<url id="http://logi.cc/linux/reject_or_deny.php3" name="rechazar o ignorar">).

<!-- revisado por Jaime Robles hasta aquí (sólo el FAQ)-->


<sect2>¿Yo he chequeado y tengo el siguiente acceso (xyz) y puedo
cerrarlo?

<p>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 <ref id="inetd">) o por otros paquetes instalados y
tómelo en medidas apropiadas (configure inetd, remueva el paquete,
anule el funcionamiento en bootup...).

<sect2>¿He removido los servicios desde <file>/etc/services</file>,estoy en lo 
cierto?
<p><em>No</em>, <file>/etc/services</file> 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
<file>/etc/services</file> ha sido modificado, pero ésta no es la norma y
no es la vía recomendable para hacerlo, observe <ref
id="disableserv">.

<sect1>¡¡He perdido mi password y no puedo tener acceso al sistema!!

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

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

<p>Si usted tiene un bootup en la unidad de cd-rom o en un disco
habilitado, usted puede: <list>

<item>inicie desde un disco de rescate e inicie el kernel.

<item>desplácese hasta la consola virtual (Alt+F2)

<item>monte el disco duro, en donde está su /root

<item>edite (El disco de rescate Debian 2.2, viene con
<prgn>ae</prgn>, Debian 3.0 viene con <prgn>nano-tiny</prgn>, el cual
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>para:

<example>
root::XXXX:X:XXXX:X:::
</example>

</list>

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

<p>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 <prgn>lilo</prgn>
justo después que el administrador lo reajusta. Esto es totalmente
difícil desde que su <file>/etc/lilo.conf</file> necesite ser atrapado
por tener un / sistema de archivo, que es un disco de la memoria ram y
no del verdadero disco duro.

<p>Una vez que LILO no sea restringido, usted puede:

<list>

<item>Presionar Alt, shift o la tecla Control, antes que el sistema
BIOS finalice, usted debería obtener la entrada LILO.

<item>Escribir "Linux single", linux init=/bin/sh ó como "linux 1" en
la entrada.

<item>usted debería obtener una entrada a interfaz de comando en el
modo singleuser (este solicitará la clave, aunque usted ya la
conozca).

<item>vuelva a montar read/write the/ partition 
<example>
mount -o remount,rw /
</example>

<item>Cambiar la clave del superusuario con <prgn>passwd</prgn> (desde
que usted sea el superusuario, no se le solicitará la clave
anterior).

</list>

<sect id="vulnerable-system">¡Mi sistema es vulnerable!

<sect1>He sufrido una interrupción, ¿qué debo hacer?

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

<sect1>¿Cómo puedo encontrar el origen de un ataque?

<p>Observando las bitácoras (si ellas no han sido cambiadas), usando
sistemas de detección de intrusión (observe <ref
id="intrusion-detect">), <prgn>traceroute</prgn>, <prgn>whois</prgn> 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
<em>usted</em> considere lo que es un ataque. ¿Es un scanner remoto un
ataque? ¿Un ataque es una prueba de vulnerabilidad?

<sect1>Cualquier programa en Debian es vulnerable ¿Qué debo hacer?

<p>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 <url id="http://security.debian.org">.

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

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

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

<sect1>Encontré usuarios haciendo 'su' en mis bitácoras
<p>Usted puede encontrar líneas en sus bitácoras como:
<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 tanto, revise si esto se debe a un trabajo en
funcionamiento a través de cron (usualmente con
<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>Software específico


<sect2>Proftpd es vulnerable a un ataque en el servicio Denial.

<p>Agregue <tt>DenyFilter \*.*/</tt> a su archivo de configuración,
para más información observe <url
id="http://www.proftpd.org/critbugs.html">.


<sect>Preguntas con respecto al equipo de seguridad Debian

<!-- ARREGLAME: update from web page -->

<sect1>Lo que es una Advertencia de Seguridad Debian (DSA).

<p>É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 <url
id="http://www.debian.org/security/" name="security area">).

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


<sect1>La firma sobre de la advertencia de Debian no es verificada 
correctamente.
<p>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.

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

<p> Un posible culpable es fetchmail (con la codificación MIME
habilitada) y formail (de procmail 3.14 únicamente). 
 

<sect1>Como se tratan los incidentes de seguridad en Debian?

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


<sect1>¿Cuánto tiempo tomará Debian para ajustar la vulnerabilidad?

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

<p>Un reporte publicado <url
id="http://lists.debian.org/debian-security/2001/debian-security-200112/msg00257
.html"name="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 <em>algunos días</em>los avisos que
fueron registrados.

<p>Sin embargo, cuando se formula está pregunta la gente se hace estas
preguntas trata de no olvidar que: 

<list>

<item>DSAS no es enviada hasta que:

<list>

<item>los paquetes esten disponibles para <em>todas</em> las
arquitecturas soportadas por Debian (este toma algun tiempo para
paquetes, que son parte del sistema central considerando
especialmente, el numero de la arquitectura soportadas en las
publicaciones estables.

<item>Nuevos paquetes evaluados completamente para asegurar que las
imperfecciones no sean introducidas.

</list>

<item>El paquete sería obtenido antes de que el DSA sea enviado (a
lafila de entrada, o de espejos).

<item>Debian es un proyecto conformado por voluntarios.

<item>Hay una claúsula "no hay garantías" que son parte de la licensia
con la cual debian es otorgado.

</list>

<sect>¿Cómo es manejada la seguridad para <tt>prueba</tt> e
<tt>inestable</tt>? <p>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. 

<p><em>Sin embargo</em>, 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).

<sect1>¿Por qué no hay réplicas oficiales de security.debian.org?
<p>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.


<!-- ARREGLAME:
Q: I've seen DSA 100 and DSA 102, now where is DSA 101?
A: Several vendors (mostly of GNU/Linux, but also of BSD
 deriviates) coordinate security advisories for some incidents and
 agree to a particular timeline so that all vendors are able to

 advisory could be released, and hence temporarily leaving out one or
 more advisories by number.
-->

<sect1>¿Cómo puedo buscar el equipo de seguridad?

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

<sect1>¿Qué diferencia hay entre seguridad @ Debian org y la lista de
seguridad Debian org?

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


<sect1>¿Cómo puedo contribuir con el equipo de seguridad Debian?
<p>
<list>

<item>Para contribuir a este documento ajustar ARREGLAME,proporcionando
nuevos contenidos. La documentacón es importante y reduce la sobre
carga de responder asuntos comúnes. La traduccón de este documento a
otras lenguases de gran utilidad.

<item>Por las aplicaciones de empacar que son útiles para proporcionar
/revisando la seguridad en el /usando un sistema Debian . Si usted no
es un revelador, archive un <url name="WNPP bug"
id="http://www.debian.org/devel/wnpp/"> y solicite al sesoftware lo
que usted considera útil y no es comúnmente proporcionado.

<item>Auditar aplicaciones en Debian o ayudar a resolver la seguridad
de errores de programación y reportar asuntos a securiti@
debian.org.el proyecto de otros trabajos como <url name="Linux Kernel
Security Audit Project" id="http://kernel-audit.sourceforge.net/"> or
the <url name="Linux Security-Audit Project"
id="http://www.lsap.org/"> incrementa la seguridad de Dbian GNU/linux
desde contribuciones , que eventualmente ayudarán también.

</list>

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

<sect1>¿Quiénes componen el equipo de seguridad debian?

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

<sect1>¿La seguridad debian del equipo revisa los nuevos paquetes en
debian?

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

<sect1>¿Yo tengo una antigua versión sobre Debian , está soportada la 
seguridad?
<p>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.
