Security Sp2
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
More details
- Words: 23,077
- Pages: 59
Kevin Fenzi, [email protected] y Dave Wreski, [email protected] 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 1.2 1.3 1.4
2.
Nuevas versiones de este documento Contacto con los autores Garantia Informacion de copyright
Vista preliminar 2.1 2.2 2.3 2.4 2.5 2.5.1 2.5.2 2.5.3 2.6
3.
Seguridad fisica 3.1 3.2 3.3 3.4 3.5
4.
La “cerradura” de los ordenadores La seguridad del BIOS Seguridad del gestor de arranque xlock y vlock Detectando compromisos en la seguridad fisica
Seguridad local 4.1 4.2
5.
¿Por que se necesita seguridad? ¿Que tan seguro es “seguro”? ¿Que es lo que se intenta proteger? Desarrollando una politica de seguridad Formas de asegurar su sistema Seguridad basada en la maquina Seguridad de red Seguridad a traves de la oscuridad Organizacion de este documento
Creando nuevas cuentas La seguridad de Root
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
7.
GGI (Generic Graphics Interface project)
Seguridad en el Kernel 7.1 7.2 7.3
8.
Opciones de compilado para kernels 2.0.x Opciones de compilado para kernels 2.2.x Dispositivos del Kernel
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 9.2 9.3 9.4 9.5
10.
Haga una copia de seguridad completa de su maquina Planificando una buena politica de copias de seguridad Haga una copia de la base de datos RPM o Debian Este pendiente de la informacion de registro del sistema Aplique todas las actualizaciones del sistema que le sea posible
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:
[email protected] y [email protected] 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
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
[email protected]
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
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-rshrexec) 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 @users @users
hard core 0 hard nproc 50 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 informacion sobre como elegir una buena contraseña.
puede
obtener
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
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 “basadoen-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 IPMasquerading 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
•
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 IPChains 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 [email protected], y para suscribirse debe enviar un “e-mail” a: [email protected]” 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
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:
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 [email protected] poniendo en el cuerpo del mensaje la frase “subscribe bugtraq”. CIAC: envie correo a [email protected] 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 [email protected] 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. etc?
¿Como habilito el uso de “shadow passwords” en mi Red Hat 4.2, 5.x,
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
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 [email protected] S. Coffin [email protected] Viktor Przebinda [email protected] Roelof Osinga [email protected] Kyle Hasselbacher [email protected] David S. Jackson [email protected] Todd G. Ruskell [email protected] Rogier Wolff [email protected] Antonomasia [email protected] Nic Bellamy [email protected] Eric Hanchrow [email protected]
Robert J. [email protected] Ulrich Alpers [email protected] David Noha [email protected]
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 [email protected] Japanese: FUJIWARA Teruyoshi [email protected] Indonesian: Tedi Heriyanto [email protected] Traducido al castellano por Juan Carlos Fernandez
Related Documents
Security Sp2
November 2019 12
Sp2 Fix.docx
December 2019 17
Sp2-cover
October 2019 12
Cbse Sp2 Scmcq
November 2019 19
Key Winxp Sp2
November 2019 12