Linux Security HOWTO

Kevin Fenzi, kevin@scrye.com y Dave Wreski, dave@nic.com

v1.0.2, 25 Abril 1999

Este documento es una vista general sobre asuntos relativos a la seguridad a los que
tiene que enfrentarse un administrador de sistemas Linux. Cubre algo de filosofia
generica sobre seguridad asi como ejemplos especificos de como hacer que su
sistema Linux sea mas seguro frente a los intrusos. Tambien se incluyen punteros a
documentacion y programas relacionados con la seguridad. Las mejoras, criticas
constructivas, aportaciones y correcciones son aceptadas con agrado. Si desea
ponerse en contacto con los autores, puede hacerlo mediante correo electronico,
poniendo la frase “Security HOWTO” en el asunto del mensaje.
Resumen del Contenido
1. Introduccion
1.1 Nuevas versiones de este documento
1.2 Contacto con los autores
1.3 Garantia
1.4 Informacion de copyright

2. Vista preliminar
2.1 ¿Por que se necesita seguridad?
2.2 ¿Que tan seguro es “seguro”?
2.3 ¿Que es lo que se intenta proteger?
2.4 Desarrollando una politica de seguridad
2.5 Formas de asegurar su sistema
2.5.1 Seguridad basada en la maquina
2.5.2 Seguridad de red
2.5.3 Seguridad a traves de la oscuridad
2.6 Organizacion de este documento

3. Seguridad fisica
3.1 La “cerradura” de los ordenadores
3.2 La seguridad del BIOS
3.3 Seguridad del gestor de arranque
3.4 xlock y vlock
3.5 Detectando compromisos en la seguridad fisica

4. Seguridad local
4.1 Creando nuevas cuentas
4.2 La seguridad de Root

5. Archivos y sistemas de archivos

5.1 Configuracion de “umask”
5.2 Permisos de los archivos
5.3 Chequeando la integridad con Tripwire
5.4 Caballos de Troya

6. Contraseñas y encriptacion
6.1 El PGP y la criptografia de llave publica
6.2 SSL, S-HTTP, HTTPS y S/MIME
6.3 Implementaciones IPSEC para Linux
6.4 SSH (secure shell) y stelnet
6.5 PAM - modulos de autentificacion
6.6 Encapsulacion criptografica del protocolo IP (CIPE)
6.7 Kerberos
6.8 Shadow Passwords.
6.9 “Crack” y “John the Ripper”
6.10 CFS - Cryptographic File System y TCFS - Transparent Cryptographic File
System
6.11 X11, SVGA y la seguridad de la pantalla
6.11.1 X11
6.11.2 SVGA
 6.11.3 GGI (Generic Graphics Interface project)

7. Seguridad en el Kernel
7.1 Opciones de compilado para kernels 2.0.x
7.2 Opciones de compilado para kernels 2.2.x
7.3 Dispositivos del Kernel

8. Seguridad de red
8.1 “Packet Sniffers”
8.2 Servicios del sistema y los “tcp_wrappers”
8.3 Verifique su informacion DNS
8.4 Identd
8.5 SATAN, ISS y otros Scanners de red
8.5.1 Detectando un escaneo de puertos
8.6 Sendmail, qmail y los MTA’s
8.7 Ataques de denegacion de servicio
8.8 Seguridad NFS (Network File System)
8.9 NIS (Network Information Service) (antiguamente YP).
8.10Cortafuegos (firewalls)
8.11 IP Chains - Cortafuegos de los kernels de Linux 2.2.x
8.12VPN’s - Virtual Private Networks

9. Preparacion de la seguridad (antes de conectar la

maquina a la red)
9.1 Haga una copia de seguridad completa de su maquina
9.2 Planificando una buena politica de copias de seguridad
9.3 Haga una copia de la base de datos RPM o Debian
9.4 Este pendiente de la informacion de registro del sistema
9.5 Aplique todas las actualizaciones del sistema que le sea posible

10. Que hacer durante y despues de una intrusion

10.1 Compromisos de la seguridad en curso
10.2 El compromiso de seguridad ya ha sucedido
10.2.1 Cerrando el agujero
10.2.2 Evaluando los daños
10.2.3 Copias de seguridad, copias de seguridad, copias de seguridad!
10.2.4 Rastreando al intruso

11. Recursos de seguridad

11.1 Sitios FTP
11.2Sitios Web
11.3Listas de correo
11.4Libros - material de lectura impreso
12. Glosario

13. Preguntas realizadas con frecuencia (FAQ’s)

14. Conclusion

15. Agradecimientos

1. Introduccion
Este documento aborda algunos de los principales temas que afectan a la seguridad
bajo Linux. Se tratan temas de seguridad genericos asi como recursos nacidos de la
propia red Internet.
Otros HOWTOW’s tratan tambien algunos temas relativos a la seguridad, y se le
remitira a ellos cuando sea apropiado.
Este documento no pretende ser un listado de “exploits” de actualidad. En el se
trataran algunos metodos genericos que le haran menos vulnerable a dichos “exploits”,
asi como se mencionaran otras fuentes de informacion donde podra encontrar tales
listas de “exploits” de actualidad.

1.1. Nuevas versiones de este documento

Las nuevas versiones de este documento seran enviadas periodicamente a

comp.os.linux.answers. Tambien seran incluidas en los distintos sitios de FTP anonimo
que almacenan esta informacion, incluyendo:
ftp://metalab.unc.edu/pub/Linux/docs/HOWTO
Ademas, generalmente podra encontrar este documento la pagina “home” de Linux
World Widw Web en:
http://metalab.unc.edu/mdw/linux.html
Finalmente, la version mas reciente de este documento deberia estar tambien
disponible en varios formatos en:
http://scrye.com/~kevin/lsh/

1.2. Contacto con los autores

Todos los comentarios, informes de errores, informacion adicional y criticas de

cualquier tipo deberian dirigirse a:
kevin@scrye.com
y
dave@nic.com
Nota: Por favor envie lo que sea a AMBOS autores. Asegurese de incluir las palabras
“Linux”, “security” o “HOWTO” en el asunto del mensaje para evitar que sea eliminado
por los filtros “anti-spam”.

1.3. Garantia

No se responde de la veracidad del contenido de este documento. Utilice los

conceptos, ejemplos y demas contenido bajo su propia responsabilidad. Ademas, esta
es una version inmadura del documento, y posiblemente tiene incorrecciones o
errores.
Un gran numero de los ejemplos y descripciones siguen la estructura de un sistema
Linux con la distribucion RedHat. Su caso puede ser diferente.

Por lo que sabemos, los programas mencionados en este documento pueden

utilizarse libremente para uso personal bajo ciertos terminos. La mayoria
de los programas estan disponibles, incluyendo el codigo fuente, bajo la
licencia GNU <http://www.gnu.org/copyleft/gpl.html>

1.4. Informacion de Copyright

(N. del T: mis conocimientos legales no llegan para poder traducir esto)
This document is copyrighted ©1998,1999 Kevin Fenzi and Dave Wreski, and
distributed under the following terms:

• Linux HOWTO documents may be reproduced and distributed in whole or in part, in

any medium, physical or electronic, as long as this copyright notice is retained on
all copies. Commercial redistribution is allowed and encouraged; however, the
authors would like to be notified of any such distributions.
• All translations, derivative works, or aggregate works incorporating any Linux
HOWTO documents must be covered under this copyright notice. That is, you may
not produce a derivative work from a HOWTO and impose additional restrictions on
its distribution. Exceptions to these rules may be granted under certain conditions;
please contact the Linux HOWTO coordinator at the address given below.
• If you have questions, please contact Tim Bynum, the Linux HOWTO coordinator,
at

tjbynum@metalab.unc.edu

2. Vista preliminar
Este documento tratara de explicar algunos procedimientos y software comunmente
utilizado para ayudar a que su sistema Linux sea mas seguro. Es importante discutir
primero algunos conceptos basicos, y tener claros los fundamentos antes de continuar.

2.1. ¿Por que se necesita seguridad?

En el mundo siempre cambiante de las comunicaciones globales, conexiones baratas

a Internet y desarrollo rapido de software, la seguridad es un asunto que cada vez
cobra mayor importancia. La seguridad es ahora un requisito basico ya que las
comunicaciones globales son inherentemente inseguras. Cuando la informacion va de
un punto A a otro punto B en Internet esta atravesando multitud de otros sistemas
donde otros usuarios pueden interceptarla e incluso alterarla. Incluso en su propio
sistema, un usuario malicioso puede transformar sus datos en algo diferente. El
acceso no autorizado a su sistema puede ser perpetrado por intrusos, tambien
conocidos como “crackers”, quienes utilizan sus conocimientos avanzados para
suplantarle, robarle informacion, e incluso impedirle el acceso a sus propios recursos.
Si se esta preguntando cual es la diferencia entre un “cracker” y un “hacker”, vea el
documento de Eric Raymond titulado “Como llegar a ser un Hacker”, disponible en:
http://sagan.earthspace.net/~esr/faqs/hacker-howto.html

2.2. ¿Que tan seguro es “seguro”?

En primer lugar, tenga siempre en mente que ningun sistema informatico puede ser
“completamente seguro”. Todo lo que se puede hacer es ir incrementando la dificultad
con la que un intruso puede comprometer su sistema. Para el usuario domestico
medio de Linux, no se necesita demasiado para mantener a raya a los crackers
casuales. Los usuarios de sistemas Linux orientados a negocio (bancos, compañias de
telecomunicaciones, etc) tendran mucho mas trabajo.
Otro factor que debe tener en consideracion es que cuanto mas seguro sea su
sistema, mas intrusiva sera su seguridad. Debe decidir el punto de equilibrio entre la
facilidad de uso y la seguridad que necesita. Por ejemplo, puede hacer que para que
alguien pueda establecer una conexion remota sea su sistema el que les llame a casa,
pero si alguien no esta alli no podra conectarse. Tambien puede configurar su sistema
Linux para que no realize ninguna conexion a Internet, pero esto limitaria su utilidad.

Si su sistema es mediano o grande, deberia establecer una politica de seguridad

teniendo en cuenta cuanta seguridad se necesita y como se chequeara esa seguridad.
Puede encontrar un ejemplo de politica de seguridad bien conocida en el documento:
http://ds.internic.net/rfc/rfc2196.txt
Ha sido actualizado recientemente, y contiene el armazon para construir
una muy buena politica de seguridad para su empresa

2.3. ¿Que es lo que se intenta proteger?

Antes de intentar proteger su sistema, deberia determinar el nivel de las amenazas
contra las que debe protegerse, que riesgos puede o no correr, y como de vulnerable
quedaria su sistema. Deberia analizar sus maquinas para saber que es lo que se va a
proteger, por que va a protegerlo, que importancia tiene, y quien es el responsable de
sus datos y otros valores.
Siempre existe la posibilidad de que un intruso tenga exito en su intento de acceder a
su ordenador. ¿Puede un intruso leer o escribir archivos, o ejecutar programas
susceptibles de causar daños? ¿puede borrar datos vitales? ¿puede impedir a su
empresa la realizacion de trabajos importantes? no lo olvide: alguien que consiga
acceso a su cuenta, o a su sistema, puede incluso suplantarle.
Ademas, el tener una sola cuenta insegura en su sistema puede hacer que toda su red
al completo se vea comprometida. Si permite que un solo usuario haga uso remoto de
su cuenta usando un archivo .rhosts, o utilice un servicio inseguro, como tftp, corre el
riesgo de que un intruso “ponga el pie en la rendija de la puerta”. Una vez que el
intruso tiene una cuenta de usuario en su sistema puede usarla para obtener acceso a
otros sistemas, o a otras cuentas.
El peligro viene siempre de alguien con un motivo para obtener acceso no autorizado a
su red u ordenador. Debe usted decidir en quien confia lo suficiente como para
permitirle acceso a su sistema, y que amenaza podria representar.
Existen distintos tipos de intrusos, y conviene que tenga en mente sus diferentes
caracteristicas a la hora de proteger sus sistemas:

El Curioso - Este tipo de intruso esta interesado basicamente en averiguar el tipo de

sistema y la informacion que usted posee.
El Malvado - Este otro tipo persigue echar abajo sus sistemas, o deformar su pagina
web, o de cualquier otro modo forzarle a gastar tiempo y dinero recuperandose del
daño que ha causado.
El Intruso de Alto Nivel - Este tipo de intruso intenta usar su sistema para ganar fama
dentro de la comunidad ‘cracker’. Si su sistema tiene una gran reputacion, intentara
introducirse en el para dar a conocer sus grandes “habilidades”.
La Competencia - Estos estan interesados en los datos que tiene en su sistema.
Puede tratarse de alguien que piensa que usted tiene algo que podria beneficiarle,
economicamente o de cualquier otro modo.
Los Parasitos - Este tipo de intrusos estan interesados en utilizar los recursos de su
maquina en su propio beneficio. Normalmente ejecutaran servidores de chat o irc,
servidores de archivos porno, o incluso servidores DNS.
La Rana Saltarina - Este intruso esta interesado unicamente en usar su sistema para
acceder a otros sistemas. Si su sistema esta bien conectado o es una “pasarela” a
otras maquinas en una red interna, puede encontrarse facilmente con uno de estos
intrusos intentando comprometer su sistema.

La vulnerabilidad determina como de bien protegido esta su sistema, y las

posibilidades de que alguien consiga acceso no autorizado.
¿Que es lo que se veria en peligro si alguien se introdujese en su sistema? por
supuesto, no es lo mismo un sistema domestico conectado esporadicamente a Internet
via PPP que un sistema o red local de una empresa.
¿Cuanto tiempo costaria recuperar datos perdidos? Una inversion inicial de tiempo
puede ahorrarle diez veces el tiempo invertido si tiene que recuperar datos perdidos.
¿Ha comprobado su sistema de backups, y comprobado sus datos ultimamente?

2.4. Desarrollando una Politica de Seguridad

Cree una politica simple y generica para su sistema, de forma que sus usuarios
puedan entenderla y seguirla con facilidad. Esta politica deberia proteger los datos y
tambien la privacidad de los usuarios. Algunas cosas que debe considerar son: ¿quien
tiene acceso al sistema? (¿puede un amigo usar mi cuenta?), ¿a quien le esta
permitido instalar software en el sistema? ¿quien es el responsable de que datos, de
recuperar la maquina de un desastre, o de que el sistema sea utilizado
apropiadamente?
Una politica de seguridad generalmente aceptada se resume con la frase:

Todo lo que no esta expresamente permitido esta prohibido

Esto significa que a menos que usted deliberadamente proporcione a un usuario

acceso a un servicio, ese usuario no deberia poder usar ese servicio. Asegurese de
que las politicas de seguridad funcionan desde una cuenta de usuario ordinaria.
Decirse “Ah, no consigo dar con este problema de permisos, lo hare como root” puede
conducir a agujeros de seguridad muy obvios, e incluso a algunos no tanto que no han
sido explotados todavia.
rfc1244 es un documento que describe como crear su propia politica de seguridad de
red.
rfc1281 es un documento que muestra un ejemplo de politica de seguridad con una
descripcion detallada de cada paso.
Finalmente, tal vez quiera echar un vistazo al archivo COAST de politica de seguridad
en ftp://coast.cs.purdue.edu/pub/doc/policy para ver el aspecto de algunas politicas de
seguridad de la vida real.

2.5. Medios para Proteger Sus Sistemas

Este documento tratara varios metodos con los cuales puede usted proteger los
recursos por los que ha trabajado tan duro: su maquina local, sus datos, sus usuarios,
su red e incluso su reputacion: ¿que le pasaria a su reputacion si un intruso borrase
los datos de uno de sus usuarios, o deformase su pagina web, o hiciese publicos los
planes comerciales de su compañia para el proximo semestre? Si esta planeando
instalar una red, hay muchos factores que debe tener en cuenta antes incluso de
instalar la primera maquina.
El que solo tenga una conexion PPP a una cuenta, o un sistema pequeño, no significa
que los intrusos no vayan a estar interesados en usted. Las maquinas grandes y
conocidas no son el unico objetivo: muchos intrusos simplemente desean introducirse
en el mayor numero posible de sistemas, independientemente de su tamaño. Ademas,
pueden usar un agujero de seguridad en su sistema para conseguir acceso a otros a
los que este usted conectado.
Los intrusos tienen un monton de tiempo en sus manos, y pueden evitar el tener que
averiguar como ha protegido usted su sistema simplemente probando todas las
posibilidades. Hay tambien una serie de razones por las que un intruso podria estar
interesado en sus sistemas, que seran expuestas mas tarde.

2.5.1. Seguridad Basada en La Maquina

Tal vez el area de la seguridad en la que mas concentran sus esfuerzos los
administradores es la seguridad basada en la maquina (“host-based security” en el
documento original). Esto normalmente implica asegurarse de que nuestro propio
sistema es seguro, y confiar en que el resto de los administradores de las maquinas de
nuestra red hagan lo mismo. Elegir buenas contraseñas, asegurar los servicios locales
de red de nuestra maquina, mantener un buen registro de la actividad del sistema y
actualizar los programas que tengan agujeros de seguridad conocidos son algunas de
las responsabilidades del administrador local encargado de la seguridad. Aunque esto
es absolutamente necesario, puede convertirse en una tarea excesivamente laboriosa
a medida que su red crezca y deje de estar compuesta por unas pocas maquinas.

2.5.2. Seguridad de Red

La seguridad de red es tan necesaria como la seguridad de las maquinas. Con

cientos, miles, o mas ordenadores en la misma red, no se puede esperar que todos y
cada uno de esos sistemas sea seguro. Asegurarse de que solo los usuarios
autorizados pueden usar su red, construir “cortafuegos” o firewalls, usar una fuerte
encriptacion, y asegurarse de que no haya maquinas “osadas” (esto es, inseguras) en
su red son todas tareas del administrador de seguridad de la red.
Este documento tratara algunas de las tecnicas utilizadas en la proteccion de
sistemas, y con un poco de suerte le mostrara algunas de las formas de evitar que un
intruso consiga acceso a aquello que esta usted tratando de proteger.

2.5.3. Seguridad A Traves De La Oscuridad (“Security Through Obscurity”)

Una forma de seguridad que debe ser discutida es la “seguridad a traves de la

oscuridad”. Esto significa, por ejemplo, mover un servicio con agujeros de seguridad
conocidos a un puerto no estandar con la esperanza de que los posibles atacantes no
se den cuenta de que esta ahi y por lo consiguiente no puedan explotarlo. Tenga por
seguro que pueden averiguar que esta ahi y lo explotaran. La seguridad a traves de la
oscuridad no es en absoluto segura. El que usted pueda tener un sistema pequeño, o
relativamente poco conocido, no significa que un intruso no vaya a estar interesado en
lo que usted tiene. Discutiremos que es lo que se va a proteger en las proximas
secciones.

2.6. Como Esta Organizado Este Documento

Este documento ha sido dividido en varias secciones. Estas secciones cubren la

mayor parte de los temas relacionados con la seguridad. La primera, “Seguridad
Fisica”, trata el como proteger fisicamente los sistemas contra los intentos de
manipulacion. La segunda, “Seguridad Local”, describe como proteger su sistema
contra abusos por parte de los usuarios locales. La tercera, “Archivos y Sistemas de
Archivos” nos muestra como configurar sus sistemas de archivos y los permisos de los
archivos mismos. La siguiente, “Contraseñas y Encriptacion”, trata el uso de la
criptografia para asegurar mejor su maquina y su red. “Seguridad del Kernel” discute
que opciones del kernel deberia usted usar o conocer para disponer de un sistema
mas seguro. “Seguridad de Red” muestra como protegerse contra ataques
procedentes de la red. “Preparacion de la Seguridad” toca el tema de como preparar
sus maquinas antes de conectarlas a la red. La siguiente seccion, “Que hacer durante
y despues de una intrusion”, trata el que hacer cuando usted detecta una intrusion en
curso o una ocurrida recientemente. En “Recursos Para la Seguridad” se enumeran
algunos recursos basicos para la seguridad. La seccion “Preguntas Mas Corrientes”
contesta a algunas de las dudas mas comunes. Y, finalmente, tenemos la seccion
“Conclusion”.
Las dos cosas mas importantes que debe tener en cuenta mientras lee este
documento son:

1- Este pendiente de su sistema. Examine los registros, como el archivo

/var/log/messages y mantenga siempre un ojo en su sistema.
2- Mantenga actualizado su sistema asegurandose de instalar las versiones mas
recientes del software y estando atento a las alertas de seguridad (news, listas de
correo, foros de debate, etc.). Simplemente haciendo esto estara haciendo que su
sistema sea notablemente mas seguro.

3. Seguridad Fisica
El primer nivel de seguridad que debe ser tenido en cuenta es la seguridad fisica de
sus sistemas informaticos. ¿Quienes tienen acceso fisico a su maquina? ¿deberian
tenerlo? ¿puede proteger las maquinas de sus manipulaciones? ¿deberia hacerlo?
La cantidad de seguridad fisica que necesita para su sistema depende en gran medida
de su situacion y/o de sus medios.
Si es usted un usuario domestico, posiblemente no necesite demasiado (aunque
podria necesitar proteger su maquina contra la manipulacion por parte de niños y
similares). Si se trata de un laboratorio, usted seguramente necesite una seguridad
fisica considerablemente mayor, pero sus usuarios deberan poder seguir haciendo su
trabajo con las maquinas. Muchas de las secciones siguientes pueden ayudar. Si esta
usted en una oficina, puede o no necesitar asegurar su maquina fuera de horas o
mientras usted esta ausente. En algunas empresas, abandonar su puesto sin asegurar
la consola (hacer log-out o ejecutar un protector de pantalla que pida una contraseña)
es causa de despido.
Metodos obvios de seguridad fisica tales como cerraduras en las puertas, cabinas
cerradas, y video-vigilancia son buenas ideas, pero se escapan del objeto de este
documento.

3.1. La “Cerradura” de los Ordenadores

La mayoria de las carcasas de PC modernas incluyen una opcion de bloqueo.

Normalmente se trata de una pequeña cerradura en el frontal de la carcasa que
permite introducir una llave y girarla a una de las dos posiciones posibles, bloqueado o
desbloqueado. El bloqueo de la carcasa puede ayudar a prevenir que alguien robe su
PC, o abra la carcasa y directamente manipule o robe algun componente hardware.
Tambien puede servir para impedir que alguien reinicie su ordenador arrancando
desde su propio disquete u otro hardware.
Estos bloqueos de carcasa hacen cosas diferentes dependiendo del soporte que
proporcione la placa madre y de como este construida la carcasa. En la mayoria de
los PC’s hacen que sea necesario romper la carcasa para abrirla. En otras, sirve para
imposibilitar la conexion de teclados o ratones. Compruebe los manuales de su placa
madre y de su carcasa para mas informacion. A veces pueden ser utiles, aunque las
cerraduras suelen ser de de muy mala calidad y pueden ser facilmente burladas
mediante el uso de ganzuas.
Algunas carcasas (principalmente las de los SPARCs y los Macintosh) poseen unos
agujeros en la parte trasera que permiten atravesar un cable de forma que los
atacantes tienen que cortarlo o romper la carcasa para acceder al interior de la
maquina. Un candado o similar tambien puede ser un elemento que disuada a alguien
de robar su maquina.

3.2. La Seguridad del BIOS

El BIOS es el software que manipula o configura su hardware x86 al mas bajo nivel.
LILO y los demas metodos de arrancar Linux acceden al BIOS para determinar como
arrancar su sistema Linux. Otros tipos de hardware soportado por Linux poseen algun
sofware similar (el OpenFirmware de los Macintosh y las maquinas SUN man
recientes, las PROM de arranque de SUN, etc). Usted puede usar su BIOS para
prevenir que algun atacante pueda reiniciar su maquina y manipular su sistema Linux.
Muchos BIOS de PC permiten establecer una contraseña de arranque. Esto no
proporciona una excesiva seguridad ( el BIOS puede resetearse, o eliminarse si
alguien puede acceder al interior de la carcasa), pero puede ayudar (por ejemplo,
llevaria tiempo y quedarian rastros de la manipulacion). De forma similar, en S/Linux
(Linux para maquinas con procesadores SPARC), su EEPROM puede ser configurada
para pedir una contraseña al arrancar. Esto podria retrasar a los atacantes.
Muchos bios de PC permiten tambien especificar algunas otras opciones buenas para
la seguridad. Consulte el manual de su BIOS o echele un vistazo la proxima vez que
arranque el sistema. Por ejemplo, algunos BIOS permiten deshabilitar el arranque
desde disquete o pedir una contraseña para acceder a algunas opciones del BIOS.
Nota: Si posee usted un servidor, y establece una contraseña para el arranque, su
maquina no arrancara adecuadamente estando desatendida.
Recuerde que sera mecesario acceder fisicamente a la maquina y suministrar
la contraseña en el caso de un fallo del suministro electrico. ;(
(N. del T: Si pretende habilitar la proteccion mediante password que impida acceder al
propio programa de configuracion del BIOS, asegurese primero de que sabe cual es el
“jumper” para borrar la memoria no-volatil o escriba el “password” en un lugar seguro,
ya que si lo olvida, tendra graves problemas cuando desee modificar la configuracion
del “hardware”).

3.3. Seguridad del Gestor de Arranque

Los multiples gestores de arranque de Linux tambien permiten habilitar una contraseña
de arranque. LILO, por ejemplo, posee una opcion de contraseña y otra para restringir
los modos de arranque. La opcion de contraseña hace que siempre sea necesario
teclearla al arrancar Linux. La opcion de restriccion solicita una contraseña de
arranque unicamente en el caso de que se suministre un determinado parametro
(como “single”) en el “prompt” de LILO.
Tenga en mente cuando establezca contraseñas que es necesario recordarlas
despues. Tambien sea consciente de que estas peticiones de contraseñas
simplemente retrasaran a los posibles atacantes. No impediran que alguien arranque
su maquina desde un floppy, y monte su particion raiz. Si habilita la seguridad en el
gestor de arranque, deberia tambien desabilitar el arranque desde floppy en el BIOS y
proteger el acceso al BIOS mismo con un password.
Si alguien tiene informacion relacionada con la seguridad en algun gestor de arranque
distinto de LILO, nos gustaria mucho saber de ella. (Grub, silo, milo, linload, etc).
Nota: Si posee usted un servidor, y establece una contraseña para el arranque, su
maquina no arrancara adecuadamente estando desatendida.
Recuerde que sera mecesario acceder fisicamente a la maquina y suministrar
la contraseña en el caso de un fallo del suministro electrico. ;(

3.4. xlock y vlock

Si usted abandona su maquina con frecuencia, es conveniente poder “bloquear” la

consola para que nadie pueda ver o manipular su trabajo. Hay al menos dos
programas que sirven para esto: xlock y vlock.
xlock es un programa que permite bloquear una consola X-windows. Deberia estar
incluido en cualquier distribucion de Linux que soporte X. Consulte la pagina de
manual para conocer sus opciones, pero basicamente se puede ejecutar xlock desde
cualquier terminal X y esto bloqueara la consola y pedira una contraseña para poder
desbloquearla.
vlock es un pequeño y sencillo programa que permite bloquear algunas o todas las
consolas virtuales de su maquina Linux. Puede bloquear unicamente la consola en la
que este usted trabajando, o todas ellas. Si solo bloquea una, otras personas pueden
usar las demas, pero no podra utilizarse la que usted haya bloqueado hasta que no la
libere suministrando una contraseña. vlock esta incluido en la distribucion RedHat,
pero probablemente en la suya tambien.
Por supuesto, bloquear la consola impedira que alguien manipule su trabajo, pero no
que reinicie la maquina o de alguna otra forma perturbe su trabajo. Tampoco evitara
que alguien acceda desde otra maquina de la red y cause problemas.
Mas importante todavia, el bloquear su terminal-X no impedira que alguien cambie del
entorno grafico a una consola virtual normal (usando <Ctrl+Alt+Fn>), o a la consola
virtual desde la que se inicio el entorno grafico, cerrandolo y saliendo a una linea de
comandos con sus privilegios. Por esta razon, deberia considerar usarlo unicamente
bajo el control de xdm.

(N. del T: Precauciones basicas a tomar son evitar escribir los passwords en lugares
visibles y protegerse del viejo “vistazo por encima del hombro” que permite a una
persona con acceso fisico a nuestro lugar de trabajo ver como tecleamos la
contraseña. Tampoco debe olvidarse que los equipos informaticos en funcionamiento
emiten señales radioelectricas que pueden llegar hasta varios cientos de metros: ojo
con las furgonetas con antena grande aparcadas durante dias en la acera de enfrente
:-) .

3.5. Detectando Compromisos en la Seguridad Fisica

La primera cosa a la que debe usted estar atento es cuando ha sido reiniciada su
maquina. Como Linux es un sistema operativo robusto y estable, solamente es
necesario reiniciarlo para cambiar el kernel u otro software vital, modificar la
configuracion del hardware, etc. Si su maquina ha sido reiniciada sin su conocimiento,
esto puede ser un signo de que un intruso ha estado alli. Muchos de los
procedimientos por los cuales su maquina puede verse comprometida requieren que el
intruso la apague o la reinicie.
Busque signos de manipulacion en la carcasa y alrededor del ordenador. Aunque
muchos intrusos eliminan los rastros de su presencia de los archivos de registro, es
una buena idea revisarlos y detectar cualquier discrepancia.
Tambien es una buena idea guardar los datos de registro en un lugar seguro, como un
servidor dedicado en su bien protegida red. Una vez que una maquina ha sido
comprometida, los registros locales son de poca utilidad ya que lo mas seguro es que
hayan sido modificados por el intruso.
El demonio syslogd puede configurarse para que envie automaticamente la
informacion de registro (“logs”) a un servidor syslog centralizado, pero normalmente
estos envios se hacen en un formato de texto puro, lo que permite que un intruso
pueda visualizar esta informacion a medida que es transmitida. Esto podria revelar
informacion sensible acerca de su red que en principio no deberia ser publica. Existen
a su disposicion demonios syslog modificados que encriptan esta informacion antes de
enviarla.
Este tambien prevenido de que falsear mensajes de syslog es facil (mediante un
programa que circula por ahi). Syslog incluso acepta entradas de registro
aparentemente procedentes de la maquina local pero que pueden proceder de
cualquier otro sitio.
Algunas cosas a comprobar en sus archivos de registro:
• Registros cortos o incompletos.
• Registros con fecha extraña o incorrecta.
• Registros con permisos o propietario incorrectos
• Registros de reinicios de la maquina o de servicios
• Registros perdidos
• Entradas “su” o accesos remotos desde lugares extraños

Discutiremos acerca de la informacion de los archivos de registro mas adelante en

este HOWTO.

4. Seguridad Local
Lo siguiente a comprobar es el nivel de seguridad de su sistema contra el posible
ataque de usuarios locales. ¿He dicho usuarios locales? Si!
Conseguir acceso a una cuenta de usuario local es una de las primeras cosas que los
intrusos intentaran en su camino de explotar la cuenta de “root”. Con una seguridad
local baja, podran “actualizar” su cuenta de usuario ordinario a la cuenta de “root”
usando “bugs” de los programas o servicios locales mal configurados. Si usted se
asegura de que su seguridad local es alta, entonces los intrusos tendran un obstaculo
mas a superar.
Los usuarios locales pueden tambien causar daño en su sistema incluso si son
realmente quienes dicen ser. Proporcionar cuentas de usuario a gente que no conoce
o de la que no tiene informacion de contacto es una idea muy mala.

4.1. Creando Nuevas Cuentas

Deberia asegurarse de proporcionar a sus cuentas de usuario solo los privilegios

imprescindibles para la tarea que necesiten realizar. Si crea usted una cuenta para su
hijo de diez años, seguramente solo debera tener acceso a un procesador de texto o
programa de dibujo, pero debera ser incapaz de borrar datos que no sean suyos.
Algunas reglas de oro que debe respetar cuando permita a otros acceso legitimo a su
maquina Linux:

• Deles solo el minimo posible de privilegios que necesiten.

• Este pendiente de cuando y desde donde acceden, o deberian acceder.
• Asegurese de eliminar las cuentas de usuario que no se utilicen.
• El uso de un mismo user-ID para la misma persona en todos los ordenadores de
una red facilita el mantenimiento de las cuentas, asi como permite un mas sencillo
analisis de los archivos “log”.
• La creacion de user-IDs de grupo deberia estar absolutamente prohibida. Las
cuentas de usuario permiten contabilidad, y esto no es posible con las cuentas de
grupo.

Muchas cuentas locales de usuario que se han usado para atacar un sistema tienen
en comun que no habian sido usadas durante meses o años. Como nadie las usaba,
eran el vehiculo ideal para un ataque.

4.2. La Seguridad de Root

La cuenta mas deseada de su maquina es la de “root” (el super-usuario). Esta cuenta

tiene potestad total sobre la maquina entera, lo que puede incluir autoridad sobre otras
maquinas de la red. Recuerde que solo debe usar la cuenta de “root” para tareas muy
cortas y especificas, usando la mayor parte del tiempo una cuenta de usuario
ordinaria. Incluso un pequeño error mientras se trabaja con la cuenta de “root” puede
causar graves problemas. Cuanto menos tiempo acceda a la maquina como “root”,
menos peligro correra de cometer un error de consecuencias desastrosas.
Algunos trucos para evitar daños a su sistema cuando trabaje como “root”:
• Cuando vaya a ejecutar alguna orden compleja, hagalo primero de una forma no
destructiva... especialmente cuando emplee simbolos comodin o comandos
recursivos. Por ejemplo, si quiere hacer “rm foo*.bak”, primero pruebe con “ls
foo*.bak” y asegurese de que va a eliminar los archivos que realmente desea
 eliminar. Sustituir el comando destructivo por “echo” tambien puede ser util a
veces.
• Proporcione a sus usuarios un alias por defecto para el comando “rm” que pida
confirmacion antes de eliminar archivos.
• Acceda como “root” solo cuando vaya a realizar una tarea concreta que lo haga
necesario. Si esta pensando como hacer algo, vuelva a una cuenta de usuario
ordinario hasta que este seguro de que y como va a hacerlo.
• La variable de entorno “PATH” para el usuario “root” es muy importante.
La ruta o “path” determina los directorios en los que el shell o interprete de
comandos (normalmente “bash”) busca los archivos ejecutables, es decir, los
programas. Intente limitar al maximo la ruta o “path” (que podemos visualizar en
cualquier momento con el comando “echo $PATH”) para el usuario “root”, y nunca
incluya un punto (.), ya que esto significa añadir el directorio actual al “path”. Debe
evitar a toda costa que en el “path” de “root” haya directorios que tengan habilitado
el permiso de escritura para todo el mundo, ya que un atacante podria modificar sus
archivos ejecutables o colocar otros nuevos en la ruta de “root”, que serian
ejecutados por usted inadvertidamente y con privilegios de superusuario.
• Nunca utilice el juego de herramientas conocido como “las utilidades r” (rlogin-rsh-
rexec) como “root”. Son vulnerables a muchos tipos de ataque, y por lo tanto es
muy peligroso ejecutarlas como “root”. Nunca cree un archivo “.rhosts” para “root”.

• El archivo /etc/securetty contiene una lista de terminales desde los cuales le esta
permitido a “root” hacer “logging” en el sistema. En Red Hat, la configuracion
predeterminada es permitir tales accesos unicamente desde las consolas virtuales
de la maquina local. Sea cuidadoso con lo que agrega a este archivo. El metodo a
utilizar deberia ser establecer un acceso remoto como un usuario ordinario, y hacer
luego un “su” para trabajar como root, todo esto a traves de un canal seguro
usando “ssh” u otro metodo de encriptacion. De esta forma no es necesario entrar
en el sistema directamente como “root”.

• Cuando trabaje como “root” piense siempre las cosas dos veces antes de hacerlas.
Sus acciones pueden afectar al funcionamiento de un monton de cosas. Revise lo
que ha tecleado antes de pulsar “intro”.

Si esta seguro de que no tiene mas remedio que permitir a alguien (esperemos que
muy de fiar) acceso a su maquina con privilegios de root, hay algunas herramientas
que pueden ayudarle. El comando “sudo” permite a usuarios ordinarios el uso de un
mumero limitado de ordenes con privilegios de “root”. Esto hace posible, por ejemplo,
que un usuario ordinario cambie y monte unidades de almacenamiento removibles
(floppys, cd-roms, etc.) en su maquina Linux sin disponer de ningun otro privilegio de
“root”. “Sudo” mantiene tambien un registro de todos los intentos, fallidos o no, de usar
uno de estos comandos privilegiados, haciendo posible saber quien ha usado que
comando y para que. Por esta razon “sudo” es ideal incluso en entornos donde varias
personas tienen acceso como “root”, ya que es facil mantener el control de los
cambios realizados en el sistema, incluyendo quien los ha realizado.
Aunque “sudo” puede usarse para dar a usuarios especificos privilegios especificos
para la realizacion de labores concretas, tiene muchos inconvenientes. Deberia ser
usado unicamente para un conjunto de tareas muy concretas y limitadas, como
reiniciar un servidor o agregar nuevos usuarios. Cualquier programa que permita un
escape al shell puede proporcionar acceso de “root” a un usuario ordinario que lo
invoque via “sudo”. Esto incluye, por ejemplo, a la mayoria de los editores de texto.
Igualmente, un programa tan inofensivo como /bin/cat puede usarse para sobreescribir
archivos, lo que puede conducir a que la cuenta de “root” sea explotada. Considere a
“sudo” como una forma mas de llevar un registro de la actividad en el sistema, pero no
espere poder sustituir de forma segura el uso de la cuenta de “root” por el uso de
“sudo”.

5. Archivos y Sistemas de Archivos.

Unos pocos minutos de preparacion y planificacion antes de conectar una maquina a
la red pueden ayudarle a proteger el equipo asi como a los datos almacenados en el.
• Nunca debe permitir que un usuario ordinario pueda ejecutar programas
SUID/SGID que residan en su directorio “home”. Utilice la opcion “nosuid” para
montar particiones donde otros usuarios que no sean “root” tengan permiso de
escritura. Tambien puede que desee usar las opciones “nodev” y “noexec” al
montar particiones que alberguen directorios “home”, asi como tambien la particion
que monte en “/var”, ya que de esa forma impedira la ejecucion de programas que
residan en estas particiones, y la creacion de archivos especiales de dispositivos
de bloque o caracter, lo que no deberia ser necesario en ningun caso.
• Si exporta directorios con NFS, asegurese de configurar /etc/exports de la forma
mas restrictiva posible. Esto significa no usar simbolos comodin, no permitir acceso
a root via NFS, y exportar como solo lectura siempre que sea posible.
• Configure la mascara de creacion de archivos (umask) de sus usuarios de la forma
mas restrictiva posible. Vease “configuracion de umask”.
• Si usted monta sistemas de archivos remotos exportados con NFS, asegurese de
configurar /etc/exports de forma restrictiva. El uso de los parametros “nodev”,
“nosuid”, y tal vez “noexec” puede ser muy conveniente.

• Establezca limites de utilizacion de los recursos para los usuarios, en lugar de

permitir uso ilimitado, que es lo predeterminado. Puede controlar los limites por
usuario usando el modulo de limitacion de uso de recursos PAM, configurando el
archivo /etc/pam.d/limits.conf. Por ejemplo, la configuracion de los limites para el
grupo “users” podria facilmente tener este aspecto:

@users hard core 0

@users hard nproc 50
@users hard rss 5000

Esta configuracion impide la creacion the archivos “core”, limita el numero de procesos
por usuario a 50 y el uso de la memoria a 5MB.

• Los archivos /var/log/wtmp y /var/run/utmp contienen un registro de todos los

accesos (loggins) de todos los usuarios del sistema. Debe comprobarse
periodicamente su integridad, ya que pueden ser utilizados para determinar
cuando y desde donde un usuario (o un posible intruso) ha entrado en el sistema.
Estos archivos deberian tener unos permisos de 644 (u+rw, go+r), lo que no
afectara al normal funcionamiento del sistema.
• El bit “inmutable” puede usarse para prevenir la sobreescritura o el borrado
accidental de un archivo que deba ser protegido. Tambien evita que alguien pueda
crear un vinculo simbolico al archivo (este truco ha sido utilizado en ataques que
incluian la eliminacion de /etc/passwd o /etc/shadow). Vea la pagina “man” del
comando “chattr”(1) para obtener informacion acerca del uso del bit “inmutable”.

• Los archivos SUID y SGID son un riesgo potencial para la seguridad, y su uso
deberia ser cuidadosamente monitorizado. Como estos programas proporcionan
privilegios especiales a los usuarios que los ejecutan, es necesario asegurarse de
que no tenemos instalados programas SUID o SGID inseguros. Uno de los trucos
favoritos de los “crackers” es explotar un programa SUID-root y dejar luego otro
programa SUID como puerta trasera para poder volver a colarse, incluso si el
agujero original es detectado y corregido.

Localice todos los programas SUID/SGID de su sistema, y lleve un registro de lo

que son, de forma que pueda detectar cualquier cambio que indique la presencia de
un potencial intruso. Utilice la orden siguiente para encontrar todos los programas
SUID/SGID de su sistema:

root# find / -type f \( -perm -04000 -o -perm -02000 \)

La distribucion Debian ejecuta cada noche una tarea programada que localiza todos
los archivos SUID existentes. Despues los compara con el listado del dia anterior, y
genera un informe de las posibles diferencias en /var/log/suid*.
Se pueden eliminar los permisos SUID o SGID de un programa sospechoso utilizando
el comando “chmod”, y volverlos a dar despues si se comprueba que es necesario
hacerlo.

• Los archivos de publica escritura, en especial archivos de sistema, pueden

constituir un agujero de seguridad si un cracker consigue acceder a su sistema y
los modifica. Los directorios de publica escritura son tambien peligrosos, ya que
permiten que un intruso cree o elimine archivos a su antojo. Para localizar todos
los archivos de publica escritura de su sistema, ejecute la orden:

root# find / -perm -2 ! -type l -ls

y asegurese de que sabe por que todos estos archivos son de publica escritura. En un
sistema normal, varios archivos son de publica escritura, incluyendo a algunos del
directorio “/dev”, y algunos vinculos simbolicos, asi que el “! -type l” los excluye del
comando “find” mostrado anteriormente.

• Los archivos sin propietario tambien pueden indicar que un intruso ha accedido a
su sistema. Puede localizar los archivos sin propietario, y a los que no pertenecen
a ningun grupo con la orden:

root# find / -nouser -o -nogroup -print

• Encontrar archivos “.rhosts” deberia estar entre las labores habituales del
administrador del sistema, ya que estos archivos no deben estar permitidos.
Recuerde, un cracker solo necesita una cuenta insegura para conseguir acceso
completo a toda su red. Puede localizar todos los archivos “.rhosts” de su sistema
con el comando:

root# find /home -name .rhosts -print

• Finalmente, antes de cambiar los permisos de ningun archivo de sistema,

asegurese de que sabe lo que esta haciendo. Nunca cambie los permisos de un
archivo solo por que parezca la forma mas sencilla de solucionar un problema.
Determine siempre por que el archivo tiene esos permisos antes de cambiarlos.

5.1. Configuracion de “umask”

El comando “umask” puede utilizarse para determinar los permisos predeterminados

que tendran los archivos de nueva creacion. Si se crean nuevos archivos sin tener en
cuenta sus permisos, el usuario podria estar proporcionando de forma inadvertida
permiso de escritura o de lectura a alguien que no deberia tenerlo. Las mascaras
“umask” mas tipicas son 022, 027 y 077 (la mas restrictiva). Normalmente, la mascara
“umask” se define en el archivo “/etc/profile”, de forma que se aplique a todos los
usuarios del sistema. La mascara de permisos que tendran los archivos de nueva
creacion puede calcularse restando a 777 el valor “umask” definido. Por ejemplo, un
valor “umask” de 777 hara que los archivos recien creados no tengan activo ninguno
de los permisos para nadie. Un valor “umask” de 666 haria que los nuevos archivos
tuviesen una mascara de permisos de 111. La linea del /etc/profile a la que nos
referimos tendria este aspecto:

# Establecer la mascara “umask” por defecto

umask 033

Asegurese de hacer que el valor “umask” para root sea 077, lo que desabilitara los
permisos de lectura, escritura y ejecucion para los demas usuarios, a menos que se
cambien de forma explicita con el comando “chmod”. En el ejemplo anterior, los
directorios de nueva creacion tendran como permisos 744, el resultado de restar a 777
el valor “umask” definido (033). Los archivos de nueva creacion tendran permisos de
644.
Si esta usando Red Hat, y utiliza su sistema de creacion de ID de usuario y grupo
(User Private Groups), solo es necesario usar 002 como “umask”. Esto se debe a que
la configuracion por defecto es un usuario por grupo.

5.2. Permisos de los Archivos

Es importante asegurarse de que los archivos de sistema no pueden ser editados por
usuarios o grupos que no deberian realizar tales labores de mantenimiento.
Unix separa el control de acceso a archivos y directorios en tres apartados:
“propietario”, “grupo” y “otros”. Siempre existen exactamente un propietario, cualquier
numero de miembros del grupo, y todos los demas.
Una explicacion rapida de los permisos en Unix:
Propiedad - Que usuario(s) y grupo(s) tienen control sobre el archivo o directorio
Permisos - Bits que pueden ser activados o desactivados para permitir diferentes
tipos de acceso al archivo o directorio. Los permisos para los directorios pueden tener
un significado diferente que para los archivos.

Lectura:
• Poder visualizar los contenidos de un archivo
• Poder leer un directorio

Escritura:
• Poder borrar o modificar un archivo
• Poder borrar o mover archivos en un directorio

Ejecucion:
• Poder ejecutar un binario o script de shell
• Poder buscar en un directorio, conbinado con el permiso de lectura.

“Sticky bit”: (para directorios)

El “sticky bit” tiene significados distintos dependiendo de que se aplique a un
archivo o a un directorio. Cuando se aplica a un directorio, hace que los usuarios
solo puedan eliminar los archivos contenidos en el mismo que sean de su
propiedad, o sobre los que tenga explicitamente permiso de escritura, incluso si se
tiene permiso de escritura sobre el directorio. Esto esta pensado para directorios
como /tmp, que son de publica escritura, pero donde no es conveniente que un
usuario pueda borrar archivos a su antojo. El “sticky bit” aparece como una letra “t”
en el campo de los permisos al hacer un “ls -l”.
Permiso SUID: (para archivos)
Este permiso habilita el “set-user-id” para el archivo. Si un archivo es ejecutable, y
tiene este permiso activo, los procesos que lo ejecuten tendran los privilegios del
dueño del archivo, y no los del usuario que creo el proceso. Este es el medio para
muchos ataques del tipo “buffer overflow”.

Permiso SGID: (para archivos)

Si el permiso “s” se activa en los permisos de grupo en lugar de en los de
propietario, el funcionamiento es igual al de los archivos SUID, salvo que los
privilegios afectados son los de grupo. EL archivo debe ser ejecutable para que
este permiso tenga algun efecto.

Permiso SGID: (para directorios)

Si activa el permiso SGID a un directorio (con “chmod g+s”), los archivos creados
en este directorio tendran como grupo propietario al mismo grupo propietario del
directorio.
 Usted - EL propietario del archivo

Grupo - El grupo de usuarios al que usted pertenece

Todos - Cualquiera que no sea el propietario o un miembro del grupo.

Archivo de Ejemplo:

• rw-r—r-- 1 kevin users 114 Aug 28 1997 .zlogin

st
1 bit - directorio? (no)
2nd bit - legible por el dueño? (si, por kevin)
3rd bit - “escribible” por el dueño? (si,, por kevin)
4th bit - ejecutable por el dueño? (no)
5th bit - legible por el grupo? (si, por users)
6th bit - “escribible” por el grupo? (no)
7th bit - ejecutable por el grupo? (no)
8th bit - legible por todos? (si, por todos)
9th bit - “escribible” por todos? (no)
10th bit - ejecutable por todos? (no)

Las lineas siguientes son un ejemplo del juego de permisos minimo que se necesita
para poder realizar el acceso descrito:
• r-------- Permite al propietario acceso de lectura al archivo
• w------- Permite al propietario modificar o borrar el archivo (tengase en cuenta
que cualquiera que tenga permiso de escritura sobre el directorio que lo
contiene puede sobreescribirlo e incluso eliminarlo.
---x------ El propietario puede ejecutar este programa, a menos que
se trate de un script de shell, en cuyo caso necesitaria
tambien el permiso de lectura
---s------ Se ejecuta con el “user ID” efectivo del propietario
--------s- Se ejecuta con el “group ID” efectivo del grupo
• rw------T No se actualiza la fecha de ultima modificacion.
Normalmente se usa con los archivos de intercambio (swap).
---t------ Sin efecto (antiguamente, “sticky bit”).

Directorio de Ejemplo:

drwxr-xr-x 3 kevin users 512 Sep 19 13:47 .public_html/

1st bit - directorio? (si, contiene muchos archivos)
2nd bit - legible por el dueño? (si, por kevin)
3rd bit - “escribible” por el dueño? (si, por kevin)
4th bit - ejecutable por el dueño? (si, por kevin)
5th bit - legible por el grupo? (si, por users)
 6th bit - “escribible” por el grupo? (no)
7th bit - ejecutable por el grupo? (si, por users)
8th bit - legible por todos? (si, por todos)
9th bit - “escribible” por todos? (no)
10th bit - ejecutable por todos? (si, por todos)

Las lineas siguientes son un ejemplo del juego de permisos minimo que se necesita
para poder realizar el acceso descrito:

dr-------- Los contenidos pueden listarse, pero no pueden leerse los atributos
de los archivos
d—x------ Se puede entrar en el directorio, y puede usarse en las variables
“PATH”.
dr-x------ Los atributos de los archivos pueden ser leidos por el propietario del
directorio
d-wx------ Files can be created/deleted, even if the directory isn’t the current
one
d-wx------ El propietario del directorio puede crear/eliminar archivos, incluso si
el directorio no es el directorio actual.
d------x-t El “sticky bit” (“t”) impide que los usuarios con permiso de escritura
sobre el directorio borren archivos que no sean suyos. Se usa en “/tmp”.
d---s—s-- Sin efecto

Los archivos de configuracion del sistema (normalmente en “/etc”) suelen tener una
mascara de permisos 640 (-rw-r-----) y son propiedad de “root”. Esto puede cambiarse
dependiendo de los requerimientos de seguridad de su entorno. Nunca permita que un
archivo de sistema tenga activos los permisos de escritura para grupo o para todo el
mundo. Algunos archivos de configuracion, incluyendo /etc/shadow, deberian ser solo
legibles por “root”, y los directorios bajo /etc no deberian ser de publico acceso.

Scripts de Shell SUID

El permiso SUID activo en un script de shell es un serio riesgo para la seguridad, y
por esta razon el kernel no lo tendra en cuenta. Independientemente de lo seguro
que crea que es el script, puede ser explotado por un cracker para conseguir una
linea de comandos con privilegios de “root”.

5.3. Chequeando la integridad con Tripwire

Otro buen metodo de detectar ataques locales o de red a su sistema es ejecutar un

chequeador de integridad como Tripwire. Tripwire hace varios chequeos de todos los
binarios y archivos de configuracion y compara el resultado con el obtenido en
ejecuciones anteriores, detectando cualquier cambio en los archivos.
es una buena idea instalar Tripwire en un disquete, y luego protegerlo contra escritura.
De esta forma, los intrusos no podran manipular el binario de Tripwire ni modificar la
base de datos de los archivos. Una vez configurado Tripwire, es conveniente ejecutarlo
periodicamente como parte de las tareas rutinarias de administracion para ver si algo
ha cambiado.
Se puede incluso hacer que “cron” ejecute Tripwire desde el disquete cada noche y le
envie el resultado por correo electronico por la mañana. Algo como:
# establece a que usuario se envian los resultados
MAILTO=kevin
# ejecutar Tripwire
15 05 * * * root /usr/local/adm/tcheck/tripwire

enviara al usuario kevin un informe por correo cada mañana a las 5:15.
Tripwire puede ser “mano de santo” para detectar intrusiones antes de que sea posible
detectarlas por cualquier otro medio. Como hay un monton de archivos que cambian
continuamente durante un uso normal del sistema, hay que tener cuidado para no
confundir cambios hechos por usted con la actividad de un cracker.
Puede conseguir Tripwire en http://www.tripwiresecurity.com sin coste alguno. Puede
conseguir mediante pago manuales y soporte tecnico.

5.4. Caballos de Troya

Los “Caballos de Troya” toman su nombre de “La Iliada”, de Homero. La idea es que
un cracker distribuye un binario o programa cuyo nombre suena fabuloso, y anima a
otra gente a descargarlo y ejecutarlo como “root”. El programa posee una
funcionalidad oculta que compromete la seguridad del sistema de forma inadvertida.
(N. del T: Un ejemplo podria ser modificar un juego para que ademas de su
funcionamiento normal tambien mande por correo electronico al cracker el archivo
/etc/passwd del sistema en el que se ejecuta.)
Deberia tener cuidado con los programas que instala en su maquina. RedHat
suministra “checksums” (o sumas de control) MD5 y firmas PGP de sus archivos RPM
de forma que el usuario pueda verificar que instala el paquete original y no una version
alterada por un cracker. Otras distribuciones utilizan metodos similares. Nunca deberia
ejecutar ningun binario de procedencia dudosa, y del que no posea el codigo fuente,
como “root”. Pocos crackers estan dispuestos a distribuir codigo fuente para el
escrutinio publico.
Aunque puede ser complicado, asegurese de conseguir el codigo fuente de los
programas de su punto de procedencia original. Si el programa va a ser ejecutado con
privilegios de “root”, entonces usted o alguien de su confianza debe revisar el codigo
fuente.

6. Contraseñas y Encriptacion
Una de las opciones de seguridad mas importantes que se usan hoy dia son las
contraseñas o “passwords”. Es importante que tanto usted como todos sus usuarios
utilicen contraseñas seguras, que no sean faciles de adivinar. La mayor parte de las
distribuciones de Linux mas recientes incluyen programas de gestion de contraseñas
(normalmente el comando “passwd”) que no permiten establecer contraseñas faciles
de adivinar. Asegurese de que su sistema cumple este requisito.
Un debate en profundidad sobre la encriptacion esta fuera del alcance de este
documento, pero una introduccion estaria bien. La encriptacion es muy util,
posiblemente incluso necesaria en los tiempos que corren. Existen multitud de
metodos para encriptar datos, cada uno con sus propias caracteristicas.
La mayoria de los sistemas operativos UNIX (y Linux no es una excepcion) utilizan
principalmente un algoritmo de encriptacion de un solo sentido llamado DES (Data
Encription Standard) para encriptar las contraseñas. Las contraseñas encriptadas se
guardan normalmente en el archivo /etc/passwd, o bien en /etc/shadow. Cuando usted
intenta hacer “login” la contraseña que escribe es encriptada y comparada con la que
hay en el archivo que almacena las contraseñas encriptadas. Si coinciden, la
contraseña es correcta y se le permite acceder al sistema. Aunque el DES es un
algoritmo de encriptacion de doble sentido (se puede encriptar una informacion y luego
desencriptarla si se posee la llave correcta), la variante que usan la mayoria de los
sistemas UNIX es de un solo sentido. Esto significa que no es posible invertir el
proceso de encriptado para conseguir las contraseñas a partir del contenido de
/etc/passwd (o /etc/shadow).
Los ataques mediante “fuerza bruta”, como los programas “Crack” o “John the Ripper”
pueden averiguar las contraseñas a menos que sean lo suficientemente aleatorias.
Los modulos PAM (ver mas adelante) le permiten utilizar una rutina de encriptado
diferente (MD5 o similares) para sus contraseñas. Tambien puede usar el programa
“Crack” en su propio beneficio. Puede usarlo periodicamente en su sistema para
detectar contraseñas que sean inseguras, y luego contactar con los usuarios afectados
para pedirles que las cambien.
En la URL http://consult.cern.ch/writeup/security/security_3.html puede obtener
informacion sobre como elegir una buena contraseña.

6.1. El PGP y la Criptografia de Llave Publica

La criptografia de llave publica, como la que usa PGP, utiliza una llave para la
encriptacion y otra llave diferente para la desencriptacion. La criptografia tradicional,
por el contrario, usa la misma llave para las dos operaciones. Esta llave debe ser
conocida por ambas partes, y por lo tanto transmitida al menos una vez de uno a otro
mediante algun medio seguro.
Para eliminar la necesidad de transmitir de forma segura la llave de encriptacion, la
encriptacion de llave publica utiliza dos llaves diferentes, una publica y la otra privada.
La llave publica de cada persona esta disponible para que cualquiera pueda usarla
para hacer la encriptacion, mientras que la llave privada, que es la que se usa para
desencriptar, solo la conoce el usuario.
Tanto la criptografia de llave publica como la de llave privada tienen sus ventajas y sus
inconvenientes. Puede conocerlas leyendo el documento FAQ de la criptografia RSA
<http://www.rsa.com/rsalabs/newfaq/>, mencionado al final de esta seccion.
El PGP (Pretty Good Privacy) esta bien soportado por Linux. Las versiones
2.6.2 y 5.0 estan probadas y se sabe que funcionan bien. Para un primer
contacto con el PGP y como usarlo, eche un vistazo al PGP FAQ:
http://www.pgp.com/service/export/faq/55faq.cgi
Asegurese de utilizar una version cuyo uso este autorizado en su pais. Debido a las
restricciones de exportacion del gobierno de USA, el software de encriptacion “fuerte”
no puede ser transmitido en formato electronico fuera del pais.
El control de exportaciones de USA es ahora gestionado por la EAR (Export
Administration Regulations), dejando de estarlo por el ITAR (???).
(N. del T: La legislacion estadounidense no solo limita la exportacion del software de
encriptacion potente, sino que tambien restringe su uso por parte de sus propios
ciudadanos. Por ejemplo, el paquete de acceso remoto “ssh” permite el uso de un
algoritmo de encriptacion de 128 bits llamado “Blowfish” cuya utilizacion es ilegal en
USA. En Francia tambien es ilegal el uso de este tipo de encriptacion).
Existe tambien una guia de configuracion paso-a-paso para configurar PGP con linux
en:
http://mercury.chem.pitt.edu/~angel/LinuxFocus/English/November1997/article7.html
Puede que necesite un parche para algunas de las ultimas versiones de Linux.
El parche esta disponible en:
ftp://metalab.unc.edu/pub/Linux/apps/crypto

Hay un proyecto en marcha para crear una implementacion libre de PGP con codigo
abierto. GnuPG es un sustituto libre y completo de PGP. Como no utiliza IDEA ni RSA
se puede usar sin ninguna restriccion. GnuPG casi cumple todos los requisitos del
documento RFC2440 (OpenPGP). Visite la pagina “web” de la Proteccion de la
Privacidad GNU para mas informacion:
http://www.gpg.org/
Se puede obtener mas informacion sobre la criptografia el el FAQ de RSA, disponible
en:
http://www.rsa.com/rsalabs/newfaq/
Alli encontrara informacion sobre terminos como “Diffie-Hellman”, “criptografia de llave
publica”, “certificados digitales”, etc.

6.2. SSL, S-HTTP, HTTPS y S/MIME

A menudo los usuarios preguntan la diferencia entre los multiples protocolos de

encriptacion y seguridad existentes, y como utilizarlos. Aunque este no es un
documento sobre encriptacion, no seria mala idea explicar brevemente en que
consisten estos protocolos, y donde conseguir mas informacion.
• SSL: el SSL (Secure Sockets Layer) es un metodo de encriptacion desarrollado
por Netscape para proporcionar seguridad en Internet. Soporta varios protocolos
de encriptacion diferentes, y permite que tanto el servidor como el cliente se
autentifiquen. SSL opera en la capa de transporte, creando un canal seguro de
datos encriptados, y puede encriptar de forma transparente datos de muchos tipos.
Usted esta utilizando este protocolo cuando consulta una pagina “web” segura con
Netscape Communicator, y constituye la base de todas las comunicaciones
seguras con este programa. Puede encontrar mas informacion en:

http://www.consensus.com/security/ssl-talk-faq.html
 Tambien tiene a su disposicion informacion sobre otras implementaciones de
seguridad de Netscape en:
http://home.netscape.com/info/security-doc.html

• S-HTTP: el S-HTTP es otro protocolo que proporciona servicios seguros a traves

de Internet. Fue diseñado para dar confidencialidad, autentificacion e integridad a
la vez que soporta mecanismos de manejo de multiples llaves y algoritmos
criptograficos mediante negociacion entre las partes involucradas en cada
transaccion. El S-HTTP esta limitado al software que lo implementa de forma
especifica, y encripta cada mensaje individualmente. ( Del FAQ de Criptografia de
RSA, pagina 138).

• S/MIME: el S/MIME (Secure Multipurpose Internet Mail Extension) es un estandar

de encriptacion que se utiliza para proteger el correo electronico y otras formas de
comunicacion a traves de Internet. Es un estandar abierto desarrollado por el
RSA, asi que seguramente en un dia no muy lejano lo veremos implementado en
Linux. Puede encontrar mas informacion sobre el S/MIME en:

http://home.netscape.com/assist/security/smime/overview.html

6.3. Implementaciones IPSEC para Linux

Ademas de CIPE, y de otros metodos de encriptacion de datos, hay tambien otras

implementaciones de IPSEC para Linux. IPSEC es un esfuerzo del IETF (Internet
Engineer Task Force) para crear comunicaciones seguras mediante el uso de
criptografia al nivel del protocolo de red IP, y proporcionar autentificacion, integridad,
control de acceso y confidencialidad.
Puede encontrar informacion sobre IPSEC en:
http://www.ietf.org/html.charters/ipsec-charter.html
Tambien encontrara alli enlaces a paginas sobre otros protocolos que implican el
manejo de llaves, y una lista de correo sobre IPSEC.
La implementacion de x-kernel para Linux, que esta siendo desarrollada en la
Universidad de Arizona, utiliza una estructura basada en objetos para la
implementacion de protocolos de red llamada x-kernel, y puede encontrarse en:
http://www.cs.arizona.edu/xkernel/hpcc-blue/linux.html
Explicado de forma mas sencilla, el x-kernel es un metodo para pasar mensajes a nivel
del kernel, lo que facilita la implementacion.
Otra implementacion de IPSEC libre es el Linux FreeS/WAN IPSEC. Segun su pagina
“web”:
“Estos servicios le permiten construir tuneles seguros a traves de redes inseguras.
Todo lo que pasa por la red insegura es previamente encriptado por la maquina
IPSEC y desencriptado en el otro extremo. El resultado es una red privada virtual
(VPN). Esta red privada es segura incluso si las maquinas que la forman estan
todas interconectadas a traves de Internet, que es una red insegura.”
Esta disponible para su descarga en la direccion:
http://www.xs4all.nl/~freeswan/
y en el momento de redactar este documento, la ultima version es la 1.0.
Al igual que otras formas de criptografia, no se distribuye por defecto con el kernel a
causa de las restricciones de exportacion.

6.4. ssh (Secure Shell) y stelnet

ssh y stelnet son programas que le permiten acceder a una linea de comandos en una
cuenta en una maquina remota de forma que la conexion se realiza sobre un canal
encriptado.
ssh es una “suite” de programas que se usa como un sustituto seguro para rlogin, rsh
y rcp. Utiliza criptografia de llave publica para encriptar las comunicaciones entre dos
maquinas, asi como para autentificar a los usuarios. Puede utilizarse para hacer “login”
de forma segura en una maquina remota, o para copiar datos entre maquinas,
imposibilitando los ataques “man-in-the-middle” (secuestros de sesion) y el “DNS
spoofing”. Realiza compresion de los datos en las conexiones, y tambien permite
sesiones X11 seguras entre maquinas. La pagina “hogar” de ssh se encuentra en:
http://www.cs.hut.fi/ssh/
(N. del T: Los ataques “man in the middle” son aquellos en los que el intruso intercepta
el canal de comunicacion. El “DNS spoofing” es algo mas elaborado: en primer lugar,
el cracker deja fuera de servicio a nuestro servidor DNS, con alguno de los muchos
medios existentes. A continuacion pone en funcionamiento un servidor DNS falso con
la misma direccion IP que el nuestro. Todos nuestros intentos de conectar con
maquinas remotas usando el nombre completo de dominio haran que nos conectemos
a las maquinas que el cracker desee, sin que seamos conscientes de ello. Utilice
siempre la direccion IP numerica de las maquinas a las que quiera conectar, y
obtendra una minima seguridad extra.)
Tambien puede usar ssh desde una maquina win95 o NT para conectarse a su
servidor Linux. Hay varios clientes ssh gratuitos para windows, incluyendo:
http://guardian.htu.tuwien.ac.at/therapy/ssh/
tambien los hay comerciales, como el de DataFellows, en:
http://www.datafellows.com
(N. del T: este ultimo no puede conseguirse si no vive en USA.)
Tambien hay un proyecto de codigo abierto para re-implementar ssh llamado “psst...”.
Para mas informacion, visite:
http://www.net.lut.ac.uk/psst/
SSLeay es una implementacion libre del protocolo Secure Sockets Layer de Netscape,
desarrollado por Eric Young. Incluye multiples aplicaciones, como un telnet seguro, un
modulo para el servidor “web” Apache, varias bases de datos, asi como numerosos
algoritmos incluyendo DES, IDEA y Blowfish.
Utilizando esta libreria se ha creado un sustituto seguro para telnet, que encripta la
conexion. A diferencia de SSH, stelnet usa SSL, el protocolo desarrollado por
Netscape. Se pueden encontrar el telnet seguro y el FTP seguro empezando por el
FAQ de SSLeay, disponible en:
 http://www.psy.uq.oz.au/~ftp/Crypto/
SRP es otra implementacion de telnet/ftp seguros. Segun su pagina “web”:
“El proyecto SRP esta desarrollando software para el uso seguro de Internet de uso
libre a nivel mundial. Empezando con unas distribuciones de Telnet y FTP seguros,
esperamos reemplazar sistemas de autentificacion de red debiles por sustitutos
seguros que no sacrifiquen la sencillez de uso a cambio de la seguridad. La
seguridad deberia ser el estandar, no una opcion.”

Para mas informacion, visite:

http://srp.stanford.edu/srp

6.5. PAM - Modulos de Autentificacion

Las versiones mas modernas de Red Hat Linux (N. del T: tambien las de Suse)
incluyen un metodo de autentificacion unificado llamado “PAM”. PAM permite cambiar
los metodos de autentificacion “en caliente” y encapsular todos los metodos de
autentificacion locales sin tener que recompilar ningun binario. La configuracion de
PAM esta fuera del alcance de este documento, pero asegurese de echar un vistazo a
la pagina “web” de PAM si desea obtener mas informacion:
http://www.kernel.org/pub/linux/libs/pam/index.html

Algunas cosas que pueden hacerse con PAM:

• Utilizar algoritmos diferentes a DES para las contraseñas. (Esto las hace mas
dificiles de obtener mediante “fuerza bruta”.
• Establecer limites de utilizacion de los recursos a los usuarios, de forma que no
puedan realizar ataques del tipo “denial-of-service”. Los recursos que pueden
limitarse son numero de procesos, cantidad de memoria, y algunos mas.
• Habilitar el uso de “shadow passwords” (ver mas adelante) en “caliente”.
• Hacer que determinados usuarios solo puedan conectarse a unas horas
determinadas desde un lugar (direccion IP) determinado.

Invirtiendo unas pocas horas en instalar y configurar PAM en su sistema, puede

prevenir muchos tipos de ataque antes de que ocurran. Por ejemplo, puede
deshabilitar el uso de los archivos .rhosts en los directorios “home” de los usuarios
agregando estas lineas a /etc/pam.d/rlogin:

#
# Deshabilita rsh/rlogin/rexec
#
login auth required pam_rhosts_auth.so no_rhosts

6.6. Encapsulacion Criptografica del protocolo IP (CIPE)

El principal objetivo de este software es proporcionar una interconexion segura de
subredes (contra analisis del trafico, inyeccion de mensajes falsos, etc) a traves de
una red de paquetes insegura, como Internet.
CIPE encripta la informacion al nivel de red. Los paquetes que fluyen entre las
maquinas de la red estan encriptados. El motor de encriptado se encuentra cerca del
controlador que envia y recibe los paquetes.
Esta filosofia es distinta a la de SSH, que encripta los datos por conexion, a un nivel
mas alto. Lo que SSH encripta es una conexion logica entre dos programas que se
ejecutan en maquinas diferentes.
CIPE puede usarse para el “tunnelling”, con el objetivo de crear una Red Privada
Virtual. La encriptacion a bajo nivel tiene la ventaja de que puede hacerse funcionar de
forma transparente entre las dos redes conectadas por la VPN, sin que sea necesario
realizar ningun cambio en los programas de aplicacion.
Resumen procedente de la documentacion de CIPE:

Los estandars IPSEC definen un conjunto de protocolos que pueden usarse (entre
otras cosas) para construir VPN encriptadas. En cualquier caso, IPSEC es un
“peso pesado” dentro de los protocolos de seguridad, complicado y con un monton
de opciones. Las implementaciones del protocolo al completo son raramente
usadas todavia, y algunos temas (como el manejo de llaves) aun no estan
totalmente resueltos. CIPE utiliza una filosofia mas sencilla, en la cual muchas
opciones que pueden ser configuradas (como la eleccion del algoritmo de
encriptacion a utilizar) lo son de forma permanente en el momento de la instalacion.
Esto limita la flexibilidad, pero permite una implementacion sencilla, eficiente, y facil
de depurar en busca de errores.

Puede encontrar mas informacion en:

http://www.inka.de/~bigred/devel/cipe.html
Al igual que otras formas de criptografia, CIPE no se distribuye por defecto con el
kernel de Linux a causa de las limitaciones de exportacion.

6.7. Kerberos

Kerberos es un sistema de autentificacion desarrollado por el Proyecto Athena, en el

MIT (Instituto de Tecnologia de Massachusets). Cuando un usuario entra en el
sistema, Kerberos le autentifica (usando una contraseña) y proporciona a este usuario
una forma de demostrar su identidad a otras maquinas distribuidas por la red.
Esta autentificacion es luego utilizada por programas como rlogin para permitir al
usuario acceder a otras maquinas sin usar ninguna contraseña (en lugar del archivo
.rhosts). Este metodo de autentificacion puede usarse tambien en el sistema de correo
para garantizar que es entregado a la persona correcta, asi como que el remitente es
quien dice ser.
Kerberos y los demas programas que vienen con el impiden que un usuario pueda
hacer creer al sistema que es alguien diferente (spoofing). Desgraciadamente la
instalacion de Kerberos es muy intrusiva, y requiere que se sustituyan o modifiquen
gran cantidad de programas en el sistema.
Puede encontrar mas informacion sobre Kerberos en el FAQ correspondiente, y el
codigo puede encontrarse en:
http://nii.isi.edu/info/kerberos/.
(De: Stein, Jennifer G,. Clifford Neuman, y Jeffrey L. Schiller.
“Kerberos: Un Servicio de Autentificacion para Sistemas de red Abiertos.”
Conferencia sobre procedimientos de USENIX, Dallas, Texas, invierno 1998.)
Kerberos no deberia ser su primer paso hacia mejorar la seguridad de su sistema. Su
uso es algo enrevesado, y no esta tan difundido como, por ejemplo, SSH.

6.8. “Shadow Passwords”

El uso de “shadow passwords” (“contraseñas en la sombra”) es un metodo para

proporcionar seguridad adicional a su sistema. Sirve para mantener las contraseñas
encriptadas fuera del alcance de los usuarios ordinarios. Normalmente, estas
contraseñas encriptadas estan almacenadas en el archivo /etc/passwd, que puede ser
leido por todo el mundo. Cualquiera puede usar un programa de “fuerza bruta” para
intentar descubrir las contraseñas. Si utiliza “shadow passwords”, las contraseñas
encriptadas se almacenan en el archivo /etc/shadow, que solo puede ser leido por
usuarios privilegiados. Para poder utilizar “shadow passwords” debe asegurarse de
que todos los programas de su sistema que necesiten acceder a las contraseñas estan
compilados con soporte para esta opcion. Usando PAM puede insertar un modulo para
“shadow passwords” que le permitira usar este sistema sin tener que modificar ningun
ejecutable. Si necesita mas informacion, puede encontrar el Shadow-Password
HOWTO en:
http://metalab.unc.edu/LDP/HOWTO/Shadow-Password-HOWTO.html

6.9. “Crack” y “John the Ripper”

Si por alguna razon su comando “passwd” no impide que sus usuarios puedan
establecer contraseñas debiles, tal vez quiera utilizar un programa de “fuerza bruta”
para asegurarse de que las contraseñas de sus usuarios son seguras.
Los programas de “crackeo” de contraseñas mediante “fuerza bruta” se basan para su
funcionamiento en una idea muy simple: encriptan todas las palabras del diccionario (y
variaciones de ellas), comparando el resultado con las contraseñas encriptadas en
/etc/passwd. Si al encriptar alguna palabra encuentran que la cadena resultante es
igual a alguna de las contraseñas encriptadas de /etc/passwd, entonces esa palabra
es una contraseña valida en el sistema.
Hay muchos programas de este tipo circulando por ahi. Los dos mas famosos son
“Crack” y “John the Ripper” (“Juan el Destripador”):
http://www.false.com/security/john/index.html
Consumen un monton de tiempo de proceso (“cpu-time”), pero podra saber si un
atacante podria utilizarlo con exito usandolo usted primero e informando a los usuarios
de las posibles contraseñas debiles. Tenga en cuenta que el intruso debe obtener
acceso primero al archivo /etc/passwd usando algun otro agujero de seguridad
existente, pero estos agujeros son mas corrientes de lo que se imagina.
Como la seguridad global de un sistema es solo tan fuerte como lo sea la de la
maquina mas insegura, no es necesario decir que si tiene maquinas Windows en su
red deberia conseguir L0phtCrack, una implementacion del programa Crack para
Windows. Esta disponible en:
http://www.l0pht.com

6.10. CFS - Cryptographic File System y TCFS - Transparent

Cryptographic
File System
El CFS es una forma de encriptar todo un arbol de directorios y permitir a los usuarios
almacenar archivos encriptados en esos directorios. Utiliza un servidor NFS que se
ejecuta en la maquina local. Puede encontrar este software en formato RPM en:
http://www.replay.com/redhat/
Tambien puede obtener mas informacion sobre su funcionamiento en:
ftp://ftp.research.att.com/dist/mab/
El TCFS es una mejora del CFS, ya que permite una mayor integracion en el sistema
de archivos, de forma que para los usuarios la encriptacion es totalmente transparente.
Si desea mas informacion, visite:
http://edu-gw.dia.unisa.it/tcfs/
Tambien permite ser usado para encriptar arboles de directorios que no sean un
“filesystem” o sistema de archivos completo.

6.11. X11, SVGA y la Seguridad de la Pantalla

6.11.1. X11

Es importante para usted que asegure su pantalla grafica para evitar que un posible
atacante vea sus contraseñas cuando las teclea, lea documentos o informacion que
pueda usted estar leyendo en pantalla, e incluso que utilice un agujero para conseguir
acceso como “root”. Ejecutar aplicaciones X remotas a traves de una red puede ser
peligroso, ya que con la ayuda de un programa de los llamados “sniffers” un cracker
puede ver todas sus interacciones con el sistema remoto.
X tiene varios mecanismos de control de acceso. El mas simple de ellos es “basado-
en-la-maquina” (“host-based” en el original): mediante el uso de xhost se especifica
que maquinas tienen permitido acceso a la pantalla grafica. Esto no es demasiado
seguro, ya que si alguien tiene acceso a su maquina puede xhost + a su propia
maquina y de esa forma conseguir acceso facilmente. Ademas, si por alguna razon
tiene que permitir acceso desde una maquina insegura, cualquiera puede
comprometer su pantalla grafica.

Mediante el uso de xdm (X Display Manager) se obtiene un metodo de control de

accesos mucho mejor: el MIT-MAGIC-COOKIE-1. Una “cookie” (galleta, pequeño
paquete de datos) de 128 bits es generado y guardado en su archivo .Xauthority. Si
necesita permitir que una maquina remota acceda a su pantalla grafica, puede usar el
comando xauth y la informacion de su archivo .Xauthority para permitir acceso solo a
esa conexion. Para mas informacion, consulte el Remote-X-Apps mini-howto,
disponible en la direccion:

http://metalab.unc.edu/LDP/HOWTO/mini/Remote-X-Apps.html
Tambien se puede usar ssh para permitir conexiones X seguras. Este metodo tiene la
ventaja de ser transparente para el usuario, ademas de que no hay ninguna
informacion que circule por la red sin encriptar.
Eche un vistazo a la pagina de manual de Xsecurity si desea mas informacion
relacionada con la seguridad en el entorno X. La apuesta mas segura es usar xdm
para acceder a su consola y despues usar ssh para conectarse a las maquinas
remotas en las que se quieren ejecutar programas X.

6.11.2. SVGA

Los programas que usan SVGAlib son normalmente SUID-root para poder acceder a
la totalidad del hardware de video. Esto los hace muy peligrosos. Si se cuelgan,
normalmente tendra que reiniciar el equipo para que el hardware de video funcione
nuevamente. Asegurese de que los programas SVGA que ejecute son autenticos, y
que puede uno fiarse de ellos hasta cierto punto. Mucho mejor, no ejecute ninguno.

6.11.3. GGI (Generic Graphics Interface project)

EL proyecto GGI Linux esta intentando resolver muchos de los problemas con los
interfaces de video en Linux. GGI movera un pequeño trozo del codigo de gestion de
video al interior del kernel de Linux, de forma que sea el kernel quien gestione
directamente el video. Esto significa que GGI permitira que el sistema de video se
recupere del cuelgue de una aplicacion. Tambien proporcionara seguridad adicional,
ya que no sera posible que un caballo de troya camuflado como programa de control
de “login” se ejecute en la consola. Para mas informacion:
http://synergy.caltech.edu/~ggi/

7. Seguridad en el Kernel
Lo que sigue es una descripcion de las opciones de configuracion del kernel de Linux
relativas a la seguridad, y una explicacion de para que sirven y como se usan.
Como el kernel controla todas las comunicaciones en red de su sistema, es importante
que sea lo mas seguro posible. Para estar protegido contra los ultimos ataques contra
redes, deberia intentar mantener siempre actualizada su version del kernel. Puede
encontrar nuevos kernels en:
ftp://ftp.kernel.org
y tambien en las distribuciones mas recientes.

Existe tambien un grupo internacional que provee un parche unificado de criptografia

para los kernels de uso general. Este parche proporciona soporte para varios
subsistemas criptograficos y algunas cosas mas que no pueden ser incluidas en las
distribuciones ordinarias del kernel debido a restricciones de exportacion. Para mas
informacion, visite:
http://www.kerneli.org

7.1. Opciones de Compilado para Kernels 2.0.x

Para los kernels de la serie 2.0.x, las siguientes opciones afectan a la seguridad.
Deberia verlas durante el proceso de configuracion del kernel. Muchos de los
comentarios proceden del archivo Configure.help, que se encuentra en
/usr/src/linux/Documentation.
(N. del T: todos los mensajes de ayuda que es posible visualizar durante la etapa
“make config” de la configuracion del kernel proceden tambien de ese archivo).

• Network Firewalls (CONFIG_FIREWALL)

Esta opcion deberia activarse si se pretende usar algun tipo de cortafuegos o el IP-
Masquerading en su maquina Linux. Si la maquina va a ser utilizada como un
cliente normal puede prescindirse de activar esta opcion.

• IP: forwarding/gatewaying (CONFIG_IP_FORWARD)

Si activa el IP-Forwarding, su maquina Linux se convierte en un router. Si su

maquina esta conectada en red, puede utilizarse para pasar informacion de una red
a otra (suponiendo que la maquina Linux esta conectada a las dos redes), tal vez
dejando sin efecto a una maquina cortafuegos puesta en la red para evitar que esto
ocurra. Una maquina cliente ordinaria no deberia usar esta opcion, y para otros
casos deben analizarse las implicaciones de seguridad que tiene el activarla. Las
maquinas que vayan a usarse como cortafuegos deben activarla, y usarla en
conjuncion con el software de cortafuegos.
Aunque compile esta opcion en el kernel, se encuentra inactiva por defecto hasta
que se habilite de forma dinamica con el comando:

root# echo 1 > /proc/sys/net/ipv4/ip_forward

y tambien puede deshabilitarla con el comando:

root# echo 0 > /proc/sys/net/ipv4/ip_forward

• IP: syn cookies (CONFIG_SYN_COOKIES)

Un “SYN Attack” es un ataque de “denegacion-de-servicio” (“denial of service”, o

“DoS”) que consume todos los recursos de una maquina, obligando a reiniciarla. No
se nos ocurre ninguna razon por la que no se deba habilitar esta opcion
normalmente. Como en el caso anterior, no basta con compilar soporte para esta
opcion en el kernel, si no que hay que activarla expresamente con el comando:
 root# echo 1 > /proc/sys/net/ipv4/tcp_syncookies <P>

• IP: Firewalling (CONFIG_IP_FIREWALL)

Esta opcion es necesaria si va a configurar su maquina para actuar como

cortafuegos, va a usar IP Masquerading, o desea proteger su maquina conectada
via modem contra intrusiones a traves de su interfaz de red PPP.

• IP: firewall packet logging (CONFIG_IP_FIREWALL_VERBOSE)

Esta opcion le permite obtener informacion acerca de los paquetes que recibe su
maquina cortafuegos, como origen, destino, puerto, etc.

• IP: Drop source routed frames (CONFIG_IP_NOSR)

Esta opcion deberia ser habilitada siempre. Los “Source routed frames” son
paquetes que contienen la ruta completa a seguir para alcanzar su destino. Esto
significa que los routers a traves de los cuales pasan estos paquetes no necesitan
inspeccionarlos, y simplemente les dejan seguir su camino. Esto puede conducir a
que su sistema sea explotado.

• IP: masquerading (CONFIG_IP_MASQUERADE) Si una de las maquinas de su red

local (para las que su maquina Linux actua como cortafuegos) quiere enviar algo al
exterior, la maquina Linux puede “enmascararla”, es decir, hacer de intermediario
transparente entre la maquina cliente de su red local y la maquina del exterior, de
forma que para la maquina del exterior es la maquina Linux la unica visible. Para
mas informacion:

http://www.indyramp.com/masq

• IP: ICMP masquerading (CONFIG_IP_MASQUERADE_ICMP) Esta opcion

complementa a la anterior, proporcionando soporte para “enmascarar” paquetes
ICMP. Si no la habilita, solo podra “enmascarar” paquetes TCP y UDP.

• IP: transparent proxy support (CONFIG_IP_TRANSPARENT_PROXY) Esta opcion

permite que su cortafuegos Linux redirija de forma transparente cualquier trafico
con origen en la red local y con destino a una maquina remota a un servidor local,
llamado “servidor proxy transparente” de forma que las maquinas de la red local
piensan que estan accediendo a una maquina remota cuando en realidad lo estan
haciendo al servidor proxy local. Vea el IP-Masquerading HOWTO si desea mas
informacion.

http://www.indyramp.com/masq

• IP: always defragment (CONFIG_IP_ALWAYS_DEFRAG)

 Normalmente esta opcion esta deshabilitada, pero si esta preparando una maquina
para hacer de cortafuegos o servir IP-Masquerading, querra habilitarla. Cuando
circula informacion entre dos maquinas, no siempre lo hace en un unico paquete, si
no que los paquetes son normalmente divididos en porciones mas pequeñas
(fragmentos). El problema es que la direccion del puerto de destino solo figura en el
primer fragmento. Esto significa que alguien puede insertar informacion en los
fragmentos restantes que no deberia estar ahi. Esta opcion tambien protege contra
el “teardrop attack” a las maquinas Linux que aun no esten “parcheadas”.

• Packet Signatures (CONFIG_NCPFS_PACKET_SIGNING)

Esta opcion esta disponible en los kernel mas modernos ( >=2.1.x ) y marca los
paquetes NCP para una mayor seguridad. Normalmente no hara falta habilitarla,
pero esta ahi por si se necesita.

• IP: Firewall packet netlink device (CONFIG_IP_FIREWALL_NETLINK)

Esta opcion le permite analizar los primeros 128 bytes de los paquetes desde un
programa de usuario, para determinar si se desea aceptarlos o rechazarlos en
funcion de su validez.

7.2. Opciones de compilado para kernels 2.2.x

La mayoria de las opciones enumeradas anteriormente son aplicables a los kernels

2.2.x, ademas de algunas nuevas que han sido desarrolladas despues. Muchos de los
comentarios proceden del archivo Configure.help, que se encuentra en
/usr/src/linux/Documentation. Todos los mensajes de ayuda que es posible visualizar
durante la etapa “make config” de la configuracion del kernel proceden tambien de
este archivo. A continuacion se mencionan solo las nuevas opciones. El cambio mas
significativo en los kernels de la serie 2.2.x se ha producido en el codigo que gestiona
el cortafuegos IP. Ahora se utiliza una utilidad llamada ipchains para administrarlo, en
lugar del programa ipfwadm, que era el que se usaba con los kernels 2.0.x.

• Socket Filtering (CONFIG_FILTER)

Para la mayoria de la gente, es correcto decir que no a esta opcion. Sirve para
“conectar” un filtro mediante el uso de un programa de usuario a cualquier “socket”
y determinar si un paquete debe ser aceptado o rechazado. A menos de que tenga
una necesidad muy especifica y sea capaz de programar usted mismo dicho filtro,
deberia decir que no. Tenga en cuenta tambien que en el momento de redactar
este documento, todos los protocolos estan soportados excepto el TCP.

• Port Forwarding: el “port forwarding” es un complemento al IP Masquerading que

permite redirigir paquetes del exterior a maquinas protegidas tras el cortafuegos a
puertos especificados. Esto puede ser util si, por ejemplo, quiere ejecutar un
servidor de paginas “web” en una maquina protegida por el cortafuegos Linux y
desea que dicho servidor pueda accederse desde el mundo exterior. Un cliente del
 exterior manda una peticion al puerto 80 de la maquina cortafuegos, el cortafuegos
redirige esta peticion a la maquina que corre el servidor “web”, y el servidor
procesa la peticion y envia la pagina solicitada al cliente original a traves del
cortafuegos. Cara al cliente, es la propia maquina cortafuegos la que parece estar
ejecutando el servidor “web”. Tambien puede utilizarse para repartir la carga entre
varios servidores “web” identicos protegidos tras el cortafuegos.

Puede obtener informacion sobre esta caracteristica en las URL’s:

http://www.monmouth.demon.co.uk/ipsubs/portforwarding.html
ftp://ftp.compsoc.net/users/steve/ipportfw/linux21/

• Socket Filtering (CONFIG_FILTER): Si habilita esta opcion, un programa de

usuario puede habilitar un filtro en cualquier “socket” y de esta forma decir al kernel
si debe o no permitir que determinado tipo de datos pasen a traves de el. El filtrado
de “sockets” de Linux funciona con todos excepto con los del tipo TCP por ahora.
Vea el archivo de texto /usr/src/linux/Documentation/networking/filter.txt para mas
informacion.

• IP Masquerading: el IP-Masquerading en los kernels 2.2.x ha sido mejorado. Ahora

tiene soporte adicional para protocolos especiales, etc. Asegurese de leer el IP-
Chains HOWTO para mas informacion.

7.3. Dispositivos del Kernel

Hay algunos dispositivos de bloque y de caracter disponibles en Linux que tambien le

ayudaran a aumentar la seguridad.
Los dos dispositivos /dev/random y /dev/urandom se suministran con el kernel a fin de
proporcionar datos aleatorios en cualquier momento.
Tanto /dev/random como /dev/urandom deberian ser lo suficientemente seguros para
usarse en la generacion de llaves PGP, desafios SSH, y en otras aplicaciones donde
se requieran numeros aleatorios seguros. Los atacantes deberian ser incapaces de
predecir el siguiente numero aleatorio que sera generado por estos dispositivos aun
disponiendo de una secuencia inicial de ellos. Se ha puesto mucho esfuerzo en
asegurarse de que los numeros que se obtienen de estos dispositivos son aleatorios
en todos los sentidos de la palabra.
La unica diferencia entre ellos es que /dev/random puede quedarse sin bytes
aleatorios y hacerle esperar hasta que se acumulen algunos nuevos. Tengase en
cuenta que en algunos sistemas esto puede hacer que la maquina detenga su
actividad durante mucho tiempo a la espera de que el usuario produzca actividad que
pueda ser usada para generar nuevos numeros aleatorios. Por eso debe ser
cuidadoso al utilizar /dev/random. (Tal vez la mejor forma de hacerlo sea usarlo solo
cuando necesite generar informacion sensible, como contraseñas, etc, haciendo que el
usuario tenga que teclear continuamente hasta recibir un mensaje del tipo “ok, ya es
suficiente...”)
/dev/random posee una entropia de alta calidad, generada a partir de la medicion del
tiempo entre interrupciones, etc, pero se bloquea hasta que se acumulan suficientes
bits de datos aleatorios.
/dev/urandom es similar, pero cuando el montante de entropia baja, devuelve una
cadena que es producto de encriptar fuertemente los datos aleatorios de los que se
dispone todavia. Esto no es tan seguro como el metodo usado por /dev/random, pero
es suficiente para la mayoria de las aplicaciones.
Se puede leer de estos dispositivos con una orden como:

root# head -c 6 /dev/urandom | mmencode

Esto mostrara en la consola seis caracteres aleatorios, susceptibles de ser utilizados

en la generacion de una contraseña. Puede encontrarse el programa mmencode en el
paquete “metamail”.
Si desea ver una descripcion del algoritmo, puede encontrarla en el archivo
/usr/src/linux/drivers/char/random.c
Gracias a Theodore Y. Ts’o, Jon Lewis, y a otra gente del Linux-kernel por ayudarme
(Dave) con esto.

8. Seguridad de Red
La seguridad de red se esta volviendo mas y mas importante a medida que la gente
pasa cada vez mas tiempo conectada. Los ataques contra la seguridad de red son casi
siempre mas faciles de realizar que aquellos contra la seguridad fisica o local, y son
mucho mas frecuentes.
Existen buenas herramientas para ayudar a mejorar la seguridad de red, y un numero
de ellas cada vez mayor esta siendo incluido en las distribuciones de Linux.

8.1. “Packet Sniffers”

Una de las formas mas comunes mediante la que los intrusos ganan acceso a mas
sistemas en su red es empleando un “sniffer” de paquetes en una maquina que ya
haya sido comprometida. El “sniffer” simplemente “escucha” a traves del dispositivo
ethernet a la espera de capturar paquetes que contengan cadenas como “login” o
“passwd”. De esta forma, un intruso puede conseguir acceso a sistemas en los que ni
siquiera intentaba introducirse. Las contraseñas sin encriptar son muy vulnerables a
este tipo de ataque.
Ejemplo: la maquina A ha sido comprometida. El atacante instala un “sniffer”. El
“sniffer” detecta el acceso remoto de un administrador accediendo a la maquina B
desde la maquina C. Despues, ese administrador hace un “su” para arreglar un
problema. El atacante ya tiene la contraseña de “root” de la maquina B. Mas tarde el
administrador permite que alguien conecte mediante telnet a su cuenta en una
maquina remota que llamaremos Z. El atacante tambien obtiene un login/password
valido en la maquina Z.
En los tiempos que corren, el atacante ni siquiera necesita comprometer una primera
maquina para instalar el “sniffer”: podria introducirse en un edificio con un ordenador
portatil y conectarlo directamente a uno de los “hub” de la red que desea atacar.
El uso de SSH o cualquier otro metodo que haga circular las contraseñas encriptadas
puede evitar este tipo de ataques. Tambien es interesante el uso de APOP para
cuentas POP de correo (los accesos POP normales son muy vulnerables a esto, como
todas las comunicaciones que envien a traves de la red contraseñas sin encriptar).

8.2. Servicios de Sistema y los “tcp_wrappers”

Antes de conectar su sistema Linux a NINGUNA red lo primero que debe ver es que
servicios necesita ofrecer. Los servicios innecesarios deberian deshabilitarse de forma
que tenga usted una cosa menos de la que preocuparse, y los atacantes un lugar
menos donde buscar un agujero.
Existen varias formas de deshabilitar servicios en Linux. Se puede mirar en el archivo
/etc/inetd.conf y ver que servicios estan siendo ofrecidos por inetd. Desactive lo que no
necesite poniendo un “#” delante de la linea correspondiente, y enviando luego un
SIGHUP al proceso inetd.
N. del T: para enviar señales a un proceso, primero debe averiguar el numero
asignado a dicho proceso (“man ps”) y despues enviarle la señal deseada (“man kill”).
El comando “kill” no solo sirve para acabar con un proceso, como parece sugerir su
nombre.

Tambien se pueden quitar (o comentar con “#”) servicios en el archivo /etc/services.

Esto significara tambien que los clientes locales no podran encontrar el servicio (por
ejemplo, si elimina el ftp e intenta hacer ftp a una maquina remota, el comando fallara
dando un mensaje de error “unknown service”). Normalmente no merece la pena hacer
esto, ya que no proporciona seguridad adicional. Se puede decir al programa de ftp
que utilice el puerto FTP habitual, y funcionara aunque el servicio no figure en
/etc/services.
Algunos de los servicios que puede que desee dejar activos son:

• ftp
• telnet (o ssh)
• correo, como pop-3 o imap
• identd

Si sabe que no va a utilizar un determinado paquete (ftpd, httpd, etc) puede eliminarlo
totalmente de su sistema. El metodo para hacerlo dependera en gran medida de la
distribucion que utilice.

Sin duda se deben deshabilitar las utilidades rsh/rlogin/rcp, incluyendo login (usado por
rlogin), shell (usado por rcp), y exec (usado por rsh) eliminando o comentando (#) las
lineas adecuadas en /etc/inetd.conf. Estos protocolos son EXTREMADAMENTE
INSEGUROS y han sido ampliamente explotados en el pasado.
Deberia comprobar el archivo /etc/rc.d/rcN.d (donde N es el “run-level” en el que corre
normalmente su sistema) y ver si alguno de los servicios iniciados desde ese directorio
no es necesario. Los archivos que residen en /etc/rc.d/rcN.d son en realidad vinculos
simbolicos al directorio /etc/rc.d/init.d. Renombrar los archivos en el directorio init.d
tiene como efecto el deshabilitar los vinculos simbolicos en /etc/rc.d/rcN.d. Si desea
deshabilitar un servicio unicamente para un “run-level” en particular, renombre el
archivo apropiado cambiando la “S” mayuscula por una “s” minuscula, tal que:

root# cd /etc/rc6.d
 root# mv S45dhcpd s45dhcpd

Si sus archivos rc son del estilo BSD, debera comprobar /etc/rc* en lugar de los
mencionados anteriormente (que son estilo System V) ya que es desde estos archivos
desde donde se lanzan los servicios.

La mayoria de las distribuciones de Linux incluyen “tcp_wrappers”. Un “tcp_wrapper”

(tcpd) es invocado por inetd en lugar del servidor real. El tcpd comprueba que maquina
solicita el servicio y ejecuta el programa servidor del servicio especificado, o bien
deniega el acceso si la maquina solicitante no esta autorizada. El tcpd le permite
restringir el acceso a sus servicios TCP. Para ello deberia crear un archivo
/etc/hosts.allow y poner en el a aquellos sistemas que deban tener acceso a los
servicios de su maquina.
Si es usted un usuario que se conecta desde casa via modem, le sugerimos que
deniege el acceso a sus servicios a todo el mundo. El tcpd ademas mantiene un
registro (log) de todos los intentos fallidos de acceder a los servicios, proporcionando
una forma de averiguar que se esta siendo objeto de un ataque. Si añade nuevos
servicios a su maquina, deberia asegurarse de que utilizan “tcp_wrappers” si estan
basados en TCP. Por ejemplo, un usuario normal que se conecte via modem puede
prevenir que un intruso se conecte a su maquina, y seguir siendo capaz de recoger el
correo de una cuenta remota, o realizar cualquier otro tipo de conexion a Internet. Para
esto, podria poner lo suiguiente en /etc/host.allow:

ALL: 127.
y, por supuesto, /etc/hosts.deny contendria:

ALL: ALL
con lo cual evitara que se realicen conexiones desde el exterior a su maquina,
mientras sigue siendo posible conectarse a servidores remotos en Internet.
Recuerde que el uso de los “tcp_wrappers” solo protege a los servicios que son
ejecutados por inetd, y unos pocos mas. Es muy probable que su maquina ofrezca
otros servicios. Puede usar la orden “netstat -ta” para obtener una lista de todos los
servicios que ofrece su maquina.

8.3. Verifique su Informacion DNS

Mantener actualizada la informacion DNS de todas las maquinas de su red puede

ayudarle a incrementar la seguridad. Si una maquina no autorizada llegase a
conectarse a su red, podria reconocerla por su falta de una entrada en el servidor
DNS. Muchos servicios pueden ser configurados para no aceptar conexiones
procedentes de maquinas que no tengan una entrada DNS valida.

8.4. identd

Identd es un pequeño programa que habitualmente es ejecutado por el servidor inetd.

Sirve para mantener un registro de que usuario esta usando que servicio TCP, y
facilitar esta informacion a cualquiera que lo solicite.
Mucha gente entiende mal la utilidad de identd, y por ello lo deshabilitan o bloquean
las peticiones dirigidas a el. Identd no esta ahi para ayudar a las maquinas remotas.
No existe ninguna forma de saber si la informacion que se obtiene de un identd remoto
es correcta o no. No se realiza ningun tipo de autentificacion en las peticiones a identd.
¿Por que querria usted ejecutar identd entonces? porque le ayuda, y es una fuente
mas de informacion util. Si su identd no ha sido comprometido, entonces sabe que
esta informando a maquinas remotas del nombre de los usuarios locales que esten
usando servicios TCP. Si el administrador de una maquina remota le dice que uno de
sus usuarios esta intentando entrar ilegalmente en su sistema, puede usted facilmente
tomar medidas contra este usuario. Si no ejecuta identd tendra que examinar un
inmenso volumen de archivos de registro y perder un monton de tiempo para dar con
el usuario en cuestion.
El identd que viene con la mayoria de las distribuciones es mas configurable de lo que
mucha gente cree. Se puede deshabilitar para usuarios especificos (mediante el uso
de un archivo .noident), se puede mantener un registro de todas las peticiones identd
recibidas por su maquina (esto es lo que se recomienda),puede hacer incluso que
identd devuelva un UID numerico en lugar del nombre del usuario, etc.

8.5. SATAN, ISS, y Otros Scanners de Red

Hay varios paquetes de software circulando por ahi que sirven para escanear las
maquinas de una red y determinar que puertos ofrecen algun servicio. SATAN, ISS,
SAINT y Nessus son algunos de los mas conocidos. Estos programas se conectan a
la maquina objetivo (o a todas las maquinas de una red) a todos los puertos que
pueden, e intentan determinar que servicio esta ejecutandose en cada puerto. A partir
de esta informacion se puede deducir si una maquina podria ser vulnerable a algun
“exploit” contenido en los ejecutables que proporcionan dichos servicios.
SATAN (Herramienta de Seguridad del Administrador para Analizar Redes) es un
escaneador de puertos con un interfaz “web”. Puede configurarse para que realice
chequeos “ligeros”, “medios” o “fuertes” a una maquina o a una red. No es mala idea
conseguir el programa SATAN y escanear su propia maquina o red, para corregir
despues los problemas que se encuentren. Asegurese de conseguir su copia de
SATAN o bien de metalab
http://metalab.unc.edu/pub/packages/security/Satan-for-Linux/
o bien de algun otro sitio fiable. Habia una copia “caballo de troya” de SATAN
circulando por Internet.
http://www.trouble.org/~zen/satan/satan.html
Tengase en cuenta que SATAN no ha sido actualizado desde hace tiempo, y algunas
de las herramientas mencionadas a continuacion podrian hacer mejor el trabajo.

ISS (Escaner de Seguridad en Internet) es otro escaneador de puertos. Es mas rapido

que SATAN, y por lo tanto podria ser mejor para redes grandes. En cualquier caso,
SATAN suele proporcionar mas informacion.
Abacus es un conjunto de herramientas que proporcionan seguridad basada en la
maquina (“host-based”) y deteccion de intrusos. Si desea mas informacion, puede
visitar su pagina “web” en la direccion:
http://www.psionic.com/abacus/
SAINT es una version actualizada de SATAN. Tambien posee un interfaz “web” y tiene
muchos “tests” mas actualizados que los de SATAN. Puede averiguar mas sobre esta
herramienta en la direccion:
http://www.wwdsi.com/~saint

Nessus es un escaner de seguridad libre. Tiene un interfaz grafico GTK para facilitar
su utilizacion. Tambien esta diseñado con una interesante funcion de adicion de
nuevos “tests” (“plugins”). Para mas informacion, eche un vistazo en la direccion:
http://www.nessus.org

8.5.1.Detectando un Escaneo de Puertos

Existen algunas herramientas diseñadas para alertarle si su sistema es objeto de un

escaneo por parte de SATAN, ISS y otros programas de funcion similar. En cualquier
caso, usando adecuadamente los “tcp_wrappers” y asegurandose de echar un ojo a
sus archivos “log” regularmente, deberia ser capaz de detectar dichas actividades sin
necesidad de software adicional. Incluso con el modo mas “suave” de funcionamiento,
SATAN todavia deja rastro en los archivos de registro de un sistema RedHat
convencional.
Existen tambien escaneadores de puertos “sigilosos”. Un paquete con el bit TCP ACK
activado (como los que se usan para establecer conexiones) podria pasar a traves de
un cortafuegos por filtrado de paquetes. El paquete RST devuelto desde un puerto que
“_had no established session_” (???) puede considerarse una prueba de que existe
actividad en ese puerto. No creo que los “TCP wrappers” detecten esto.

8.6. sendmail , qmail y los MTA’s

Uno de los mas importantes servicios que puede usted proporcionar es un servidor de
correo. Desafortunadamente, es tambien uno de los mas vulnerables a los ataques,
sencillamente a causa del numero de tareas que debe realizar y de los privilegios que
normalmente necesita.
Si utiliza usted sendmail es muy importante mantenerse siempre actualizado a las
ultimas versiones. Sendmail tiene una MUY larga historia de agujeros de seguridad.
Asegurese siempre de que esta utilizando la version mas reciente, que puede obtener
en la direccion:
http://www.sendmail.org
Recuerde que para enviar correo no es necesario que ejecute sendmail. Si es usted
un usuario domestico, puede deshabilitar sendmail y utilizar sencillamente el programa
cliente de correo para enviarlo. Puede que tambien desee eliminar el modificador “-bd”
del archivo de inicializacion de sendmail, lo que desabilita el que se atiendan
peticiones de correo procedentes del exterior. En otras palabras, se puede ejecutar
sendmail desde uno de los “scripts” de inicializacion usando:

# /usr/lib/sendmail -q15m
Esto hara que sendmail vacie la cola de correo cada quince minutos en busca de
mensajes que no hayan podido ser enviados con exito en el primer intento.
Muchos administradores prefieren no usar sendmail, y en su lugar eligen alguno de los
demas agentes de transporte de correo (MTA’s). Puede que le resultase interesante
cambiarse a qmail. Qmail fue diseñado con la seguridad en mente desde el principio.
Es rapido, estable y seguro.
Puede encontrar el programa qmail en la direccion:
http://www.qmail.org
En competicion directa con qmail esta “postfix”, escrito por Wietse Venema, el autor de
varios “tcp_wrappers” y de otras herramientas de seguridad. Antiguamente llamado
vmailer, y patrocinado por IBM, este agente de transporte de correo tambien esta
diseñado pensando en la seguridad desde un principio. Puede encontrar mas
informacion sobre vmailer en la direccion:
http://www.postfix.org

8.7. Ataques de Denegacion de Servicio

Un ataque de denegacion de servicio (“denial of service”, “DoS”) es aquel en el que el

atacante intenta hacer que un determinado recurso este tan ocupado que no pueda
atender peticiones de usuario legitimas, incluso impidiendo a los usuarios legitimos el
acceso a la maquina.
Los ataques de denegacion de servicio se han incrementado enormemente en los
ultimos años. Algunos de los mas populares y recientes se listan a continuacion. Tenga
en cuenta que continuamente aparecen nuevas formas de realizar un ataque de este
tipo, por lo que la lista siguiente no es mas que un ejemplo. Lea las listas de correo
sobre seguridad en Linux y demas documentacion relacionada para mantenerse al
corriente de la aparicion de nuevos tipos de ataque.

• “SYN Flooding” - Este es un ataque de denegacion de servicio de red.

Se aprovecha de un “bucle-agujero” en la forma en que se crean las conexiones
TCP. Los kernels de Linux mas modernos (2.0.30 y siguientes) poseen varias
opciones de configuracion para prevenir este tipo de ataques. Vea la seccion
“Seguridad del Kernel” para conocer estas opciones de proteccion.

• El “bug F00F” del Pentium - Ha sido descubierto recientemente que el envio de

una determinada secuencia de instrucciones en codigo maquina a un procesador
Intel Pentium genuino hace que la maquina se reinicie. Este problema afecta a
todos los ordenadores que tengan un procesador Intel Pentium (no a los Cyrix,
AMD, Pentium Pro ni Pentium II) independientemente del sistema operativo que
ejecuten. Los kernels de Linux a partir del 2.0.32 contienen una porcion de codigo
que evita este problema. Si posee un procesador Pentium, deberia actualizar su
kernel a una de estas versiones inmediatamente.

• “Ping Flooding” - Este es un simple ataque por fuerza bruta. El atacante

“bombardea” la maquina victima con un flujo continuado de paquetes ICMP. Si la
maquina atacante posee un ancho de banda mayor, la maquina victima no podra
enviar nada a la red. Una variante de este ataque, llamada “smurfing”, envia los
 paquetes ICMP con la direccion IP de retorno modificada, haciendo mas dificil
determinar el origen real del ataque. Puede encontrar mas informacion sobre el
ataque “smurf” en la direccion:

http://www.quadrunner.com/~chuegen/smurf.txt
Si alguna vez sufre un ataque “ping flood”, utilice una herramienta como tcpdump
para determinar de donde vienen los paquetes (o de donde parecen venir), y
suministre esa informacion a su proveedor. Estos ataques pueden ser facilmente
prevenidos a nivel del “router” o bien mediante el uso de un cortafuegos.
(N. del T: El comando “ping” suministrado en la mayoria de las distribuciones de
Linux admite el parametro “-f” para generar un flujo masivo de paquetes ICMP. Por
supuesto, esta opcion solo puede ser utilizada por el superusuario.)

• El “Ping de la Muerte” - Este ataque envia paquetes ICMP ECHO REQUEST (ping)
que son demasiado grandes para caber en las estructuras de datos del kernel
donde se almacenan. Como la recepcion de un unico paquete “ping” de 65510
bytes hace que muchos sistemas se bloqueen, este problema recibio rapidamente
el sobrenombre de “ping de la muerte”. Hace tiempo que este problema ha sido
corregido, de manera que no hay que preocuparse por el.

• “Teardrop”/”New Tear” - Una de las formas de ataque mas recientes se aprovecha

de un “bug” en el codigo que maneja la fragmentacion IP en plataformas Windows
y Linux. Ha sido corregido en la version 2.0.33 del kernel, y no es necesario
seleccionar ninguna opcion de compilado para utilizar esta mejora. Aparentemente
Linux es inmune al ataque “New Tear”.

Puede encontrar el codigo de la mayoria de los “exploits” y una descripcion mas

profunda de como trabajan usando el motor de busqueda disponible en la direccion:
http://www.rootshell.com

8.8. Seguridad NFS (Network File System).

El NFS es un protocolo de uso compartido de archivos ampliamente utilizado. Permite

que un servidor que ejecute nfsd y mountd “exporte” sistemas de archivos a otras
maquinas que tengan soporte cliente NFS en el kernel (o algun otro tipo de software
cliente si no se trata de maquinas Linux). Mountd mantiene un registro de los sistemas
de archivos montados en /etc/mtab, que puede ser visualizado mediante el uso del
comando showmount.
Muchos sistemas usan NFS para servir los directorios “home” de los usuarios, de
manera que independientemente de la maquina de la red mediante la que accedan
siempre tienen acceso a sus archivos personales.
Hay pocas opciones de seguridad a la hora de exportar archivos con NFS.
Si esta obligado a usar NFS, asegurese de exportar permitiendo acceso solo a las
maquinas que realmente lo necesiten. Nunca exporte el directorio raiz de un sistema.
Exporte solo los directorios que se necesiten.
Para mas informacion, vea el NFS-HOWTO disponible en la direccion:
http://metalab.unc.edu/mdw/HOWTO/NFS-HOWTO.html

8.9. NIS (Network Information Service) (antiguamente YP).

El Servicio De Informacion de Red es un metodo para distribuir informacion a un grupo

de maquinas. El servidor NIS maestro contiene las tablas de informacion y las
convierte en archivos NIS mapeados. Estos “mapas” son despues servidos a la red,
permitiendo que las maquinas cliente obtengan toda la informacion contenida en un
archivo /etc/passwd estandar (login, password, directorio “home”, “shell” para el
usuario, etc). Esto permite, por ejemplo, que un usuario cambie su contraseña solo
una vez y que este cambio tenga efecto en todas las maquinas del dominio NIS.
El NIS no es para nada seguro, ni nunca pretendio serlo. Fue diseñado para ser util y
manejable. Cualquiera que pueda averiguar el nombre de un dominio NIS (en
cualquier sitio de la red) puede conseguir una copia del archivo passwd y utilizar
“crack” o “John the Ripper” para obtener contraseñas validas. Tambien es posible
“spoofear” al servidor NIS y realizar toda clase de trucos perversos. Si esta obligado a
usar NIS, asegurese de que conoce los peligros que implica.
Existe un sustituto para NIS mucho mas seguro, llamado NIS+. Para mas informacion,
lea el NIS-HOWTO, disponible en:
http://metalab.unc.edu/mdw/HOWTO/NIS-HOWTO.html

8.10. Cortafuegos (firewalls)

Un cortafuegos es una forma de controlar que informacion puede salir o entrar en una
red. Tipicamente, la maquina cortafuegos esta conectada a Internet y tambien a la red
local, de forma que el unico camino posible para los paquetes de la red local con
destino a Internet sea a traves de la maquina cortafuegos. De esta forma, el
cortafuegos puede controlar todo el trafico que fluye de la red local a Internet y
viceversa.
Hay varios tipos de cortafuegos y metodos para configurarlos. Las maquinas Linux
constituyen un cortafuegos bastante bueno. El codigo de cortafuegos se puede
compilar en los kernels 2.0 y superiores. Las herramientas de usuario (ipfwadm para
kernels 2.0.x, ipchains para 2.2.x) permiten cambiar “en caliente” los tipos de trafico de
red permitidos. Tambien permiten mantener un registro de un determinado tipo de
trafico de red.
Los cortafuegos constituyen una util e importante tecnica para proteger su red. No
obstante, nunca piense que por el hecho de tener un cortafuegos no necesita proteger
las maquinas que se encuentran tras de el. Este es un error fatal. Para mas
informacion sobre Linux y los cortafuegos, le remitimos al magnifico documento
Firewall-HOWTO, disponible en:
http://metalab.unc.edu/mdw/HOWTO/Firewall-HOWTO.html
Tambien encontrara informacion interesante en el IP-Masquerade mini-howto:
http://metalab.unc.edu/mdw/HOWTO/mini/IP-Masquerade.html
Si desea ampliar su conocimiento de ipfwadm (la herramienta de usuario para
gestionar el cortafuegos de los kernels 2.0.x) visite:
http://www.xos.nl/linux/ipfwadm/
Si no tiene ninguna experiencia con cortafuegos, y planea configurar uno para algo
mas que una politica de seguridad sencilla, el libro “Firewalls” de O’Reilly y Asociados,
asi como alguna otra documentacion sobre cortafuegos serian de obligada lectura.
Visite para mas informacion:
http://www.ora.com
El Instituto Nacional de Estandars y Tecnologia posee tambien un excelente
documento sobre cortafuegos. Aunque data de 1995, todavia sigue vigente.
Puede encontrarlo en la direccion siguiente:
http://csrc.nist.gov/nistpubs/800-10/main.html

Otras fuentes interesantes de informacion relacionada con los cortafuegos son las
siguientes:

• El Proyecto Freefire - contiene una lista de herramientas de cortafuegos de libre

distribucion, y la direccion es:

http://sites.inka.de/sites/lina/freefire-l/index_en.html

• Diseño de Cortafuegos SunWorld - escrito por los autores del libro de O’Reilly
mencionado anteriormente, proporciona una introduccion a los diferentes tipos de
cortafuegos. Puede encontrarlo en:

http://www.sunworld.com/swol-01-1996/swol-01-firewall.html

8.11. IP Chains - Cortafuegos de los kernel de Linux 2.2.x

El “Linux IP Firewalling Chains” es una actualizacion del codigo de cortafuegos de los

kernels 2.0.x para los de la serie 2.2.x. Proporciona muchas mas opciones que las
implementaciones anteriores, incluyendo:
• Una manipulacion mas flexible de los paquetes.
• Una contabilidad (registro) mas compleja.
• Posibilita realizar facilmente cambios simples en la politica.
• Los fragmentos de paquetes pueden ser explicitamente bloqueados, etc.
• Es posible generar un registro (log) de los paquetes “sospechosos”.
• Puede manejar otros protocolos ademas de ICMP/TCP/UDP.

Si usted usa actualmente ipfwadm con su kernel 2.0.x, existen “scripts” a su

disposicion que le permiten cambiar el formato de las ordenes de ipfwadm al utilizado
por ipchains. Asegurese de leer el IP-Chains HOWTO si desea mas informacion.
Puede encontrarlo en la direccion:
http://www.rustcorp.com/linux/ipchains/HOWTO.html
8.12. VPN’s - “Virtual Private Networks” o Redes Privadas
Virtuales.

Las VPN’s son una forma de crear una red “virtual” sobre otra red ya existente. Esta
red virtual a menudo usa algun sistema de encriptado y unicamente permite el trafico
entre algunas maquinas bien conocidas que se unen a esta red virtual. Las VPN’s se
utilizan habitualmente para conectar la maquina de alguien que trabaja desde casa
con la red interna de su empresa usando una red virtual encriptada que corre sobre
otra red publica, normalmente Internet.
Si esta usando un cortafuegos Linux con “masquerading” y necesita dejar pasar
paquetes MS PPTP (un producto VPN punto a punto de Micro$oft), existe un parche
para el kernel de Linux que permite justamente esto. Vease: ip-masq-vpn.
Existen varias soluciones VPN para Linux disponibles:
• vpnd. Visite:

http://www.crosswinds.net/nuremberg/~anstein/unix/vpnd.html.

• Free S/Wan, disponible en:

http://www.xs4all.nl/~freeswan/

• Puede utilizarse SSH para construir una VPN. Vea el VPN mini-HOWTO para mas
informacion.

• vps (virtual private server) disponible en:

http://www.strongcrypto.com.

Vease tambien la seccion sobre IPSEC para obtener mas direcciones donde obtener
mas informacion sobre este tema.

9. Preparacion de la Seguridad (antes de

conectar la maquina a la red).
Bien, ya ha chequeado su sistema y ha determinado que es lo mas seguro posible.
Ahora ya esta listo para conectarlo a la red. Hay algunas cosas que deberia hacer
ahora con el fin de estar preparado contra una posible intrusion, de manera que
pueda rapidamente deshacerse del intruso, y volver a dejar el sistema listo para
seguir trabajando normalmente.
9.1. Haga una Copia de Seguridad Completa de su Maquina

La discusion de los metodos de copia de seguridad y almacenaje de las mismas va

mas alla del alcance de este documento, pero ahi van algunas palabras acerca de las
copias de seguridad:
Si tiene menos de 650MB de datos en cada particion, una copia a CD-ROM es
bastante interesante (ya que una copia de seguridad en CD es dificil de manipular, y si
se guarda de forma adecuada puede durar mucho tiempo). Las cintas magneticas y
otros soportes re-grabables deben protegerse contra escritura nada mas finalizar el
proceso de copia de seguridad, y deben verificarse despues para asegurarse que no
han sido modificados. Asegurese de almacenar las copias de seguridad en un lugar
seguro. Una buena copia de seguridad le proporciona un buen punto de partida desde
el que restaurar un sistema totalmente destruido.
(N. del T: Cierta vez escuche una historia acerca de como una empresa quedo
totalmente desvalida al sufrir un incendio que acabo tanto con sus ordenadores como
con sus copias de seguridad, realizadas regularmente de forma impecable pero que se
almacenaban en el mismo edificio que los ordenadores. La moraleja es que se deben
guardar las copias de seguridad en un lugar diferente a donde residen fisicamente las
maquinas).

9.2. Planificando una buena politica de copias de seguridad

Un ciclo de seis cintas es facil de mantener. Esto incluye cuatro cintas para los dias de
la semana de lunes a jueves, una cinta para los viernes pares y otra para los viernes
impares. Realice una copia incremental los dias ordinarios, y una copia de seguridad
completa todos los viernes a la cinta que corresponda. Si en algun momento realiza
cambios particularmente importantes en el sistema, una copia completa no estara de
mas.

9.3. Haga una copia de la base de datos RPM o Debian

En el caso de sufrir una intrusion, puede utilizar la base de datos RPM de archivos
instalados en el sistema tal y como utilizaria tripwire, pero solo si sabe a ciencia cierta
que dicha base de datos no ha sido modificada por el intruso. Deberia copiar la base
de datos RPM a un disquete, y mantener este disquete a buen recaudo. La distribucion
Debian utiliza un sistema similar a la base de datos RPM.
Los archivos /var/lib/rpm/fileindex.rpm y /var/lib/rpm/packages.rpm (la base de datos
RPM) posiblemente no caben en un disquete, pero una vez comprimidos deberian
caber cada uno de ellos en un disquete.
Asi, si su sistema se ve comprometido, puede usar el comando:

root# rpm -Va

para verificar cada archivo del sistema. Vea la pagina de manual del comando rpm, ya
que hay algunas otras opciones que pueden incluirse para hacer que el comando
proporcione menos informacion (???). Tenga en cuenta que debe estar seguro de que
el binario RPM no ha sido comprometido.
Esto significa que cada vez que instale un nuevo paquete RPM en el sistema debera
volver a hacer una copia de seguridad de la base de datos RPM. Tendra que evaluar
usted mismo las ventajas y los inconvenientes de este sistema.

9.4. Este pendiente de la informacion de registro del sistema

Es muy importante que la informacion procedente del syslog no sea comprometida.

Hacer que los archivos del directorio /var/log tengan permisos de escritura y lectura
solo para un numero de usuarios limitado es un buen comienzo.
Asegurese de saber que es lo que se va a escribir en esos archivos, especialmente
por el servicio auth. Varios intentos fallidos de hacer “login” por parte de un usuario,
por ejemplo, pueden indicar un intento de penetracion en el sistema.
El lugar donde debe buscar los archivos de registro del sistema depende de la
distribucion de Linux que utilice. En un sistema que cumpla el “estandar de sistema de
archivos de Linux”, como RedHat, los encontrara en /var/log con los nombres
messages, mail.log, etc.
Puede averiguar donde pone su distribucion los mensajes del syslog examinando el
archivo /etc/syslog.conf, ya que este archivo es el que determina donde deben
escribirse los distintos mensajes del sistema.
Puede que desee tambien configurar un sistema que ponga a salvo los archivos de
registro hasta que disponga de tiempo para examinarlos. La distribucion RedHat
incluye un paquete llamado “logrotate” que sirve para esto. Es muy posible que otras
distribuciones incluyan paquetes de funcionalidad similar.
Si sus archivos de registro han sido manipulados, vea si puede determinar a partir de
donde estan manipulados, y que tipo de cosas parecen haber sido modificadas o
borradas. ¿Hay grandes periodos de tiempo durante los cuales no se realizo ningun
registro? mirar en las cintas de copia de seguridad (si es que se dispone de alguna) en
busca de archivos de registro sin manipular es una buena idea.
Los archivos de registro son habitualmente modificados por los intrusos para eliminar
cualquier rastro de su intrusion, pero en cualquier caso deben ser examinados en
busca de eventos “extraños”. Puede que descubra a un intruso intentando obtener
acceso, o aprovecharse de un fallo en un programa para obtener acceso como “root”.
Es posible que encuentre entradas en los archivos de registro antes de que el intruso
tenga tiempo de modificarlos.
Deberia asegurarse tambien de separar los registros generados por el servicio auth del
resto de la informacion de registro, incluyendo los intentos de utilizacion del comando
su, intentos de “login”, etc.
Si es posible, configure el syslog para que envie una copia de la informacion de
registro mas importante a un sistema seguro. Esto evitara que un intruso borre su
rastro de los archivos de registro. Vea la pagina de manual de syslog, concretamente
la opcion “@”.
Hay por ahi programas syslog mas avanzados. Visite la direccion:
http://www.core-sdi.com/ssyslog/
para obtener informacion sobre el Secure Syslog. Este programa le permite encriptar
la informacion de registro y asegurarse de que nadie la manipule.
Otro demonio syslog con mas opciones es syslog-ng. Le permite una gran flexibilidad
en los registros y tambien se pueden enviar a maquinas remotas para prevenir su
manipulacion.
Para terminar, decir que los archivos de registro son inutiles si nadie los lee. Dedique
periodicamente algun tiempo a examinarlos, y familiaricese con el aspecto que
presentan en un uso normal de la maquina. Saber esto puede ayudarle a detectar
eventos poco usuales.

9.5. Aplique todas las actualizaciones del sistema que le sea

posible.

La mayoria de los usuarios de Linux lo instalan desde un CD-ROM. Debido a la

rapidez con la que aparecen los parches de seguridad, es casi seguro que para
cualquier distribucion en CD-ROM que pretendamos instalar existen parches de
seguridad. Antes de conectar la maquina a la red, es una buena idea visitar la pagina
“web” de la distribucion en busca de los posibles parches pertinentes. Deberia
descargarlos e instalarlos.

10. Que hacer durante y despues de una

intrusion
¿Asi que ha seguido algunos de los consejos de este documento (o de cualquier otra
parte) y ha detectado una intrusion en su sistema? La primera cosa que debe hacer
es mantener la calma. Las acciones precipitadas pueden causar mas daño que el
propio intruso.

10.1. Compromisos de la seguridad en curso.

Descubrir un compromiso de seguridad en curso puede ser el comienzo de una tarea

estresante. El como se reaccione puede tener grandes consecuencias.
Si el compromiso de seguridad que se esta viendo es contra la seguridad fisica,
posiblemente se trate de que ha visto a alguien introduciendose ilegalmente en su
casa, oficina o laboratorio. Deberia avisar a las autoridades locales. En un laboratorio,
puede que haya visto a alguien intentando abrir una carcasa o reiniciar una maquina.
Dependiendo de la autoridad que se ostente, y de cual sea el procedimiento habitual a
seguir en estos casos, puede que deba usted pedir al intruso que deje de hacerlo, o
contactar con el personal de seguridad de su empresa.
Si ha detectado a un usuario local intentando comprometer la seguridad de su sistema,
lo primero que debe hacer es comprobar que se trata en realidad de la persona que
usted cree. Compruebe desde donde se esta conectando. ¿Es desde normalmente lo
hace? ¿no? entonces utilice alguna forma no electronica para ponerse en contacto con
el. Por ejemplo, llamele por telefono o vaya a su casa/oficina y hable con el. Si le
confirma que era el quien estaba conectado, puede entonces pedirle que le explique
que es lo que estaba haciendo o decirle que deje de hacerlo. Si no estaba conectado,
o no sabe de que le esta usted hablando, es muy posible que el incidente necesite una
investigacion mas profunda. Recopile toda la informacion que le sea posible antes de
hacer ninguna acusacion.
Si ha detectado un compromiso en la seguridad de red, lo primero que debe hacer (si
es posible) es desconectarse de la red. Si el intruso esta accediendo via modem,
desenchufe el cable del modem. Si es via ethernet, desconecte el cable de la tarjeta
de red. Esto impedira que el intruso haga mas daño del que ya haya hecho, y para el
esto parecera mas un problema de red que una deteccion.
Si no puede desconectarse de la red (porque se trate de una maquina que ofrece
algun servicio crucial, o por que no se tenga acceso fisico a la maquina) lo siguiente
que puede intentar es utilizar algo como un “tcp_wrapper” o el cortafuegos del kernel
(ipchains, ipfwadm) para impedir el acceso desde la maquina del atacante.
Si no puede denegar el acceso a todos los usuarios de la maquina desde la que se
esta produciendo el ataque, bloquear la cuenta del intruso puede funcionar. Recuerde
que bloquear una cuenta no es cosa facil. Debe tener en cuenta los archivos .rhosts,
el acceso FTP y todo un ejercito de posibles puertas traseras.
Despues de tomar alguna de las medidas anteriores (desconectar de la red, denegar
el acceso desde la maquina atacante y/o deshabilitar su cuenta) sera necesario que
“mate” todos los procesos de ese usuario.
Deberia monitorizar cuidadosamente su sistema durante los minutos siguientes, ya
que es muy posible que el atacante vuelva a intentarlo, tal vez usando una cuenta de
usuario diferente e incluso una direccion IP distinta.

10.2. El compromiso de seguridad ya ha sucedido

Ha detectado usted un compromiso de seguridad que ya ha terminado, o bien ha

detectado uno en curso y lo ha abortado siguiendo los consejos anteriores. ¿Y ahora
que?

10.2.1. Cerrando el Agujero

Si puede determinar que metodo ha usado el intruso para acceder a su sistema,

deberia intentar cerrar ese agujero. Por ejemplo, tal vez descubra varios accesos FTP
justo antes de que el intruso entrase. Desabilite el servicio FTP e intente conseguir
una version actualizada.
Compruebe todos sus archivos de registro, y haga una visita a sus paginas “web” de
seguridad favoritas para ver si existe algun nuevo agujero que pueda usted tapar.
Puede encontrar los parches de seguridad de Caldera en:
http://www.caldera.com/tech-ref/security/
Red Hat todavia no ha separado sus parches de seguridad de los parches ordinarios
de correccion de errores, pero la lista de fallos de sus distribuciones estan disponibles
en la direccion:
http://www.redhat.com/errata
Debian mantiene una lista de correo y una pagina “web” relativas a la seguridad. Para
mas informacion, visite:
http://www.debian.com/security/
Es muy posible que si un distribuidor de Linux suministra actualizaciones de seguridad,
los demas tambien lo hagan.
Hay un proyecto de auditoria de seguridad para Linux. Estan verificando
sistematicamente todos los programas de usuario en busca de posibles agujeros de
seguridad. Extraido del documento donde se dan a conocer:

“Estamos realizando una auditoria sistematica de los codigos fuente de Linux con
vistas a hacerlo tan seguro como el OpenBSD.
Ya hemos descubierto (y corregido) algunos problemas, pero
cualquier ayuda es bienvenida. Nuestra lista de correo es una
fuente util de informacion general sobre seguridad. La direccion
es security-audit@ferret.lmh.ox.ac.uk, y para suscribirse debe
enviar un “e-mail” a: security-audit-subscribe@ferret.lmh.ox.ac.uk”

Si no tapa el agujero que ha usado el atacante, probablemente volvera.

No necesariamente a la misma maquina, sino a cualquier otra de su red. Si el intruso
ejecuto un “sniffer” de paquetes, es casi seguro que dispone de acceso a otras
maquinas de su red.

10.2.2. Evaluando los daños.

Es importante realizar una evaluacion del daño causado por el intruso. ¿Que es lo que
se ha visto comprometido? si dispone de un verificador de integridad como Tripwire,
puede usarlo para realizar una comprobacion. Si no, tendra que revisar usted mismo
toda la informacion importante.
Como los sistemas Linux se estan volviendo cada vez mas faciles de instalar, puede
considerar la opcion de salvar sus archivos de configuracion y borrar totalmente el
contenido de los discos duros para volver a instalar todo. Despues solo tendria que
restaurar los archivos de configuracion y los datos de usuario. Esto le daria la
seguridad de tener un nuevo sistema totalmente “limpio”. Si conserva alguna copia de
seguridad del sistema que se ha visto comprometido, sea especialmente cuidadoso
con los ejecutables que restaura, ya que puede que haya algun “caballo de troya”
dejado por el intruso.
Una reinstalacion de este tipo deberia ser obligatoria si se ha detectado una intrusion
en la que el atacante haya conseguido privilegios de “root”. Tambien puede que usted
desee conservar cualquier evidencia de la intrusion, de manera que no estaria de mas
reinstalar en un disco duro diferente y conservar el antiguo tal y como quedo despues
del ataque.
Despues debe averiguar cuanto tiempo hace que sucedio el ataque, y si las copias de
seguridad contienen informacion ya alterada por el intruso. Hablaremos de nuevo
sobre las copias de seguridad mas adelante.

10.2.3. Copias de seguridad, copias de seguridad, copias de seguridad!

Realizar copias de seguridad periodicamente es un mandato divino por motivos de

seguridad. Si su sistema se ve comprometido, puede restaurar la informacion que
necesite de las copias de seguridad. Por supuesto, puede que alguna informacion
tenga valor tambien para el atacante, que no solo la destruira si no que la robara y
tendra su propia copia, pero al menos usted todavia dispondra de ella.
Deberia verificar las copias de seguridad mas recientes antes de restaurar
desde ellas algun archivo que haya sido eliminado o modificado por un
intruso. Puede que el ataque se perpetrara hace tiempo, con lo cual las copias de
seguridad mas recientes no serian de utilidad por contener archivos ya manipulados.

Por supuesto, hay mucho mas que decir con respecto a las copias de seguridad.
Asegurese de almacenarlas en un lugar seguro. Sepa quien tiene acceso a ellas. Si un
intruso consigue una de sus copias de seguridad, tendra acceso a toda su informacion
sin que usted jamas se entere.

10.2.4. Rastreando al intruso.

Bueno, ya ha expulsado al intruso, tapado el agujero y restaurado su sistema, pero

todavia no esta todo hecho. Aunque en la mayoria de los casos no existen muchas
posibilidades de echar el guante al atacante, deberia informar del ataque.
Deberia informar de los hechos al administrador del sistema desde el que el ataque
fue perpetrado. Puede averiguar con quien debe contactar mediante el uso del servicio
whois o consultando la base de datos Internic. Podria enviarles un correo electronico
adjuntando la informacion referente al ataque que haya encontrado en los archivos de
registro. Seria buena idea contactar tambien por telefono. Con la informacion facilitada
por usted, ese administrador puede rastrear al intruso y averiguar desde que sistema
se conecto con ellos, repitiendo la operacion con el otro administrador, y asi
sucesivamente.
Los “crackers” competentes casi siempre utilizan multiples sistemas intermediarios
hasta llegar a su maquina, algunos (o muchos) de los cuales ni siquiera saben que han
sido utilizados para ello. Intentar rastrear a un intruso hasta su casa puede ser dificil.
Ser educado con los administradores con los que trate puede ser conveniente si desea
conseguir que le ayuden. Si forma parte de alguna organizacion relacionada con la
seguridad (CERT <http://www.cert.org/> o similar) deberia informarles tambien, asi
como al suministrador de su sistema Linux.

11. Recursos de Seguridad

Existen multitud de lugares donde encontrar informacion relativa a la seguridad de los
sistemas Unix en general y tambien especifica de Linux. Es muy importante
suscribirse a algunas listas de correo sobre seguridad y mantenerse al corriente de los
nuevos parches de seguridad. La mayoria de estas listas generan un volumen de
mensajes muy bajo, y son muy instructivas.

11.1. Sitios FTP

El CERT (Computer Emergency Response Team) es el Equipo de Respuesta a
Emergencias Informaticas. Frecuentemente alertan de ataques de actualidad y
proporcionan parches de seguridad. Para mas informacion, visite:
ftp://ftp.cert.org
el sitio “web” Replay (http://www.replay.com) permite la descarga de muchos
programas de seguridad. Como esta fuera de los EE.UU. no necesita obedecer las
restricciones en materia de encriptacion.
Matt Blaze es el autor del CFS (Cryptographic File System) y es un gran “consejero”
de seguridad. Para mas informacion:
<ftp://ftp.research.att.com/pub/mab>
tue.nl es un gran sitio FTP de seguridad ubicado en Holanda.
ftp.win.tue.nl

11.2. Sitios Web

• “The Hacker FAQ” es un FAQ sobre hackers (N. del T: no se dice donde encontrar
este documento).
• El archivo COAST tiene un gran numero de programas de seguridad para Unix y
tambien informacion.

• La Pagina de Seguridad de SuSe:

http://www.suse.de/security/

• Rootshell.com es un lugar muy bueno para ver los “exploits” que estan siendo
utilizados actualmente por los “crackers”:

http://www.rootshell.com/
• BUGTRAQ realiza informes sobre temas de seguridad
• Dan Farmer es el autor de SATAN y muchas otras herramientas de seguridad. Su
“web” contiene tanto herramientas como documentacion.

http://www.trouble.org
• “Linux Security” es un buen lugar para conseguir informacion relativa a la
seguridad con Linux: Linux Security WWW
• Infilsec dispone de una base de datos con un motor de busqueda que permite
consultar vulnerabilidades que afecten a una plataforma especifica. Su direccion
es:

http://www.infilsec.com/vulnerabilities/
• CIAC realiza publicaciones periodicas relativas a “exploits” comunes:

http://ciac.llnl.gov/cgi-bin/index/bulletins
• Un buen lugar donde iniciarse en el uso de los modulos PAM es:

http://www.kernel.org/pub/linux/libs/pam/
• El proyecto Debian tiene una pagina “web” con sus parches de seguridad y
tambien informacion. La direccion es:
 http://www.debian.com/security/
• El FAQ de Seguridad WWW, escrito por Lincoln Stein, es una gran fuente de
informacion de seguridad relativa al servicio WWW:

http://www.w3.org/Security/Faq/www-security-faq.html

11.3. Listas de Correo

Bugtraq: para suscribirse a bugtraq, envie correo a listserv@netspace.org poniendo

en el cuerpo del mensaje la frase “subscribe bugtraq”.
CIAC: envie correo a majordomo@tholia.llnl.gov poniendo en el cuerpo del mensaje la
frase “subscribe ciac-bulletin”.
Red Hat posee varias listas de correo, de las cuales la mas importante es la lista
“redhat-announce”. A traves de ella se suministran los ultimos parches y correcciones,
entre ellos los de seguridad. Si desea suscribirse, envie correo a
majordomo@redhat.com con la frase “subscribe redhat-announce”.
El proyecto Debian mantiene una lista de correo sobre seguridad que cubre todo lo
referente a sus actualizaciones y parches en esta materia.
Para mas informacion puede visitar la direccion:
http://www.debian.com/security/

11.4. Libros - Material de Lectura Impreso

Existen por ahi numerosos libros muy buenos sobre seguridad. Esta seccion hace
referencia a algunos de ellos. Ademas de los libros especificos sobre seguridad, este
tema tambien es tratado es otros libros cuyo tema central es la administracion de
sistemas.

Building Internet Firewalls por D. Brent Chapman & Elizabeth D. Zwicky

1ª Edicion Septiembre 1995
ISBN: 1-56592-124-0
Practical UNIX & Internet Security, 2¦ Edicion por Simson Garfinkel &
Gene Spafford
2ª Edicion Abril 1996
ISBN: 1-56592-148-8
Computer Security Basics por Deborah Russell & G.T. Gangemi, Sr.
1ª Edicion Julio 1991
ISBN: 0-937175-71-4

Linux Network Administrator’s Guide por Olaf Kirch

1ª Edicion Enero 1995
ISBN: 1-56592-087-2

PGP: Pretty Good Privacy por Simson Garfinkel

1ª Edicion Diciembre 1994
ISBN: 1-56592-098-8
Computer Crime A Crimefighter’s Handbook por David Icove, Karl Seger & William
VonStorch (Consulting Editor Eugene H. Spafford)
1ª Edicion Agosto 1995
ISBN: 1-56592-086-4

12. Glosario

• authentication (autentificacion): Es la propiedad de saber que la informacion

recibida es la misma que la que fue enviada, y que el remitente real es quien se
supone que es.

• bastion host (maquina bastion): Es un sistema que tiene que estar altamente
protegido porque es susceptible de ser atacado, normalmente porque esta
expuesto a Internet y es el punto de contacto principal entre los usuarios de la red
interna. Recibe su nombre de las paredes exteriores de las antiguos castillos
medievales, altamente fortificados. Los bastiones vigilaban puntos criticos
defensivos, y normalmente constituian un lugar para poner tropas “extra”, arrojar
aceite hirviendo a los atacantes, etc. (N. del T: estas practicas estan totalmente en
desuso hoy dia, habiendo sido sustituidas ventajosamente por la ubicacion
estrategica de un vendedor de la revista “La Farola”).

• buffer overflow (desbordamiento de buffer): La forma habitual de programar hoy dia

incluye el no asignar nunca “buffers” lo suficientemente grandes, y no comprobar si
se desbordan. Cuando un “buffer” se desborda, el programa en ejecucion (por
ejemplo, un demonio o un programa SUID) puede ser “engañado” para que haga
algo diferente a lo previsto. Esto se consigue generalmente sobreescribiendo la
direccion de retorno de una funcion en la pila con una direccion diferente (donde
esta el codigo del “cracker”).

• denial of service (denegacion de servicio): Consiste en un ataque en el que los

recursos del sistema (memoria, espacio en disco, etc) son consumidos por un
proceso hostil haciendo imposible que puedan ser utilizados por los usuarios
legitimos.

(N. del T: un ejemplo sencillo de esta tecnica seria enviar a una cuenta de correo de
la maquina objetivo un mensaje cuyo tamaño sea mayor que el espacio libre
disponible en la particion que aloja al directorio /var/spool/mail. Si el administrador
cometio la imprudencia de dejar ese directorio en la particion que alberga el sistema
de archivos raiz (/) y ademas no establecio una politica de limitacion de espacio en
disco (cuotas) entonces su maquina se quedara sin espacio en disco, viendose
afectados todos los servicios que ofrezca).
• dual-homed host (maquina con hogar dual): Es un ordenador de proposito general
que posee al menos dos interfaces de red.

• firewall (cortafuegos): Es el componente o conjunto de componentes que controla y

restringe las comunicaciones entre una red protegida e Internet, o entre cualquier
otro conjunto de redes.

• host (maquina, equipo): Es un ordenador conectado a una red.

• IP spoofing (usurpacion de direccion IP): Este es un ataque tecnicamente complejo

que utiliza multiples componentes. Basicamente consiste en introducirse en un
entorno donde existen maquinas que se comunican entre si en base a una
“relacion de confianza” y hacer creer a una de estas maquinas que somos una de
sus “amigas”. Existe un documento que trata intensivamente este tema escrito por
daemon9, route e infinity en el Volumen Siete, numero cuarenta y ocho, de la
revista “Phrack”.

• non-repudiation (imposibilidad de negar la autoria): Esta seria la habilidad que

tendria alguien capaz de demostrar que un determinado remitente ha enviado una
determinada informacion incluso en el caso de que este remitente niegue
posteriormente el haberlo hecho.
• packet (paquete): Es la unidad fundamental de comunicacion en Internet

• packet filtering (filtrado de paquetes): Es la accion mediante la que un dispositivo

realiza un control selectivo del flujo de paquetes hacia y desde una red. Los filtros
bloquean los paquetes o los dejan pasar, normalmente mientras son enrutados de
una red a otra (la nayoria de las veces entre Internet y una red interna). Para que
el filtro funcione, se dictan reglas que determinan que tipo de paquetes pueden
pasar y cuales son bloqueados.

• perimeter network (red envolvente): Es una red que separa a una red protegida de
otra red externa, con el fin de proporcionar una capa adicional de seguridad. A
veces se les llama DMZ.

• proxy server (servidor proxy): Es un programa que hace de intermediario entre un

servidor externo y un cliente interno. Los clientes proxy se comunican con el
servidor proxy, el cual remite los accesos que se consideren autorizados al servidor
real, devolviendo tambien las respuestas del servidor al cliente correspondiente.

• superuser (super-usuario): Es un nombre informal para el usuario “root”.

13. Preguntas realizadas con frecuencia (FAQ’s)

1. ¿Es mas seguro compilar el soporte para los dispositivos directamente en

el kernel que la utilizacion de modulos?

Respuesta: alguna gente piensa que es mejor desabilitar la capacidad del kernel de
cargar modulos adicionales, ya que un intruso podria cargar un modulo troyano o
uno para alterar la seguridad del sistema.
En cualquier caso, para poder cargar modulos se necesitan privilegios de “root”. Los
archivos objeto de los modulos tampoco pueden ser modificados por nadie salvo el
superusuario. De esto se deduce que un intruso necesita acceso de “root” para
poder cargar modulos. Si un intruso obtiene acceso de “root” hay cosas mas serias
de las que preocuparse que de si carga un modulo.
Los modulos son para permitir la carga dinamica del soporte para un dispositivo que
no se usa frecuentemente. En maquinas servidor, como un cortafuegos por
ejemplo, es muy raro que esto sea necesario. Por esta razon, es mas logico
compilar directamente en el kernel el soporte para los dispositivos que esa maquina
servidor vaya a utilizar. Ademas, los modulos son mas lentos que el soporte directo
en el kernel.

2. ¿Por que no se puede hacer “login” como “root” desde una maquina
remota?

Respuesta: vease “seguridad de root”. Esto sucede de forma intencional para evitar
que se pueda intentar conectar via telnet como “root”, lo que es un riesgo
importante para la seguridad. No lo olvide: los intrusos potenciales tienen al tiempo
de su parte, y pueden ejecutar programas automatizados de busqueda de
contraseñas.

3. ¿Como habilito el uso de “shadow passwords” en mi Red Hat 4.2, 5.x,

etc?

Respuesta: el “shadow password” es un mecanismo que permite almacenar las

contraseñas en otro archivo que no sea el tipico /etc/passwd. Esto proporciona
varias ventajas. La primera es que dicho archivo solo es legible por “root”, a
diferencia de /etc/passwd, que debe ser de publica lectura. La otra ventaja es que el
administrador puede habilitar y deshabilitar cuentas sin que todo el mundo pueda
saber el estado de estas.

El archivo /etc/passwd es utilizado para almacenar los nombres de los usuarios y

los grupos, utilizados por programas como /bin/ls para mapear los ID de usuario con
los nombres correspondientes al mostrar el contenido de un directorio.
El archivo /etc/shadow solo contiene el nombre del usuario y su contraseña
encriptada, y tal vez informacion de contabilidad, como la fecha de expiracion de la
cuenta, etc.
 Para habilitar el uso del “shadow password”, ejecute “pwconv” como “root”,
asegurandose antes de que no existe /etc/shadow ni esta siendo utilizado por
ninguna aplicacion. Si utiliza RedHat 4.2 o superior, los modulos PAM se adaptaran
automaticamente a este cambio sin ninguna otra modificacion.
Si esta interesado en hacer que sus contraseñas sean mas seguras, tal vez desee
generar unas buenas contraseñas con las que empezar. Para esto puede usar el
modulo pam_cracklib, que forma parte del paquete PAM. Este modulo realiza un
intento de “crackear” sus contraseñas para ayudarle a decidir si son facilmente
obtenibles para los programas de busqueda de contraseñas.

4. ¿Como puedo habilitar las extensiones SSL de Apache?

Respuesta:
1.Consiga SSLeay 0.8.0 o superior de
<ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL>

2.Compile, pruebe e instale

3.Consiga los fuentes de Apache 1.2.5 (o superior)
4.Consiga las extensiones SSLeay de Apache en
<ftp://ftp.ox.ac.uk/pub/crypto/SSL/apache_1.2.5+ssl_1.13.tar.gz>
5.Desempaquete en el directorio de los fuentes de Apache y parchee
tal y como se explica en el archivo README
6.Configure y compile

Puede tambien visitar el sitio “web” de Replay Associates, donde puede encontrar
muchos paquetes precompilados, y ademas estan fuera de los Estados Unidos.

5. ¿Como puedo manipular las cuentas de usuario manteniendo la

seguridad?

Respuesta: la distribucion RedHat contiene un gran numero de herramientas para

modificar las propiedades de las cuentas de usuario.

• Los programas pwconv y unpwconv pueden utilizarse para habilitar o deshabilitar

el uso de “shadow password”.
• Los programas pwck y grpck pueden usarse para verificar que los archivos passwd
y group esten correctamente organizados.
• Los programas useradd, usermod y userdel permiten agregar, eliminar y modificar
cuentas de usuario. Los comandos groupadd, groupmod y groupdel hacen lo
mismo con los grupos.
• Las contraseñas de grupo pueden crearse con el comando gpasswd

Todos estos programas son lo suficientemente “inteligentes” como para saber si el

sistema usa o no “shadow password” y adaptarse a esta contingencia.
Consulte las paginas de manual correspondientes si desea ampliar su informacion
sobre estos comandos.
6. ¿Como puedo proteger con contraseña documentos HTML especificos
usando Apache?

Apuesto a que no conoce http://www.apacheweek.org, ¿a que no?

Puede encontrar informacion sobre la autentificacion de usuarios en:
http://www.apacheweek.com/features/userauth
Asi como algunos otros consejos de seguridad en:
http://www.apache.org/docs/misc/security_tips.html

14. Conclusion

Solo con suscribirse a las listas de correo de alertas de seguridad y manteniendo

actualizados los programas, ya estara dando un gran paso hacia el objetivo de hacer
que su sistema sea seguro. Si examina atentamente los archivos de registro con cierta
periodicidad y ejecuta algo como tripwire regularmente, estara haciendo mucho mas.
Un nivel de seguridad razonable no es dificil de mantener en una maquina domestica.
Para un sistema en un entorno de negocio se requiere mas esfuerzo, pero Linux
puede ser una plataforma bastante segura. Debido a la naturaleza del desarrollo de
Linux, los parches de seguridad son creados con mayor rapidez que en otros entornos,
haciendo que Linux sea una plataforma ideal cuando la seguridad sea un requisito
indispensable.

15. Agradecimientos:
(N. del T: como suele ser mi costumbre, esta seccion permanece en el idioma original)
Information here is collected from many sources. Thanks to the following that either
indirectly or directly have contributed: following who either indirectly or directly have
contributed:
Rob Riggs rob@DevilsThumb.com
S. Coffin scoffin@netcom.com
Viktor Przebinda viktor@CRYSTAL.MATH.ou.edu
Roelof Osinga roelof@eboa.com
Kyle Hasselbacher kyle@carefree.quux.soltc.net
David S. Jackson dsj@dsj.net
Todd G. Ruskell ruskell@boulder.nist.gov
Rogier Wolff R.E.Wolff@BitWizard.nl
Antonomasia ant@notatla.demon.co.uk
Nic Bellamy sky@wibble.net
Eric Hanchrow offby1@blarg.net
 Robert J. Bergerrberger@ibd.com
Ulrich Alpers lurchi@cdrom.uni-stuttgart.de
David Noha dave@c-c-s.com

The following have translated this HOWTO into various other languages!
A special thank you to all of them for help spreading the linux word...
Polish: Ziemek Borowski ziembor@FAQ-bot.ZiemBor.Waw.PL
Japanese: FUJIWARA Teruyoshi fjwr@mtj.biglobe.ne.jp
Indonesian: Tedi Heriyanto 22941219@students.ukdw.ac.id

Traducido al castellano por Juan Carlos Fernandez <piwiman@aebius.com>

del equipo de “Aebius. Centro de Linux” <aebius@aebius.com>
entre Septiembre y Octubre de 1999