You are on page 1of 196

Fedora 18 Gua de seguridad

Una gua para la seguridad en Fedora Linux

Johnray Fuller John Ha David O'Brien Scott Radvan Eric Christensen Adam Ligas

Gua de seguridad

Fedora 18 Gua de seguridad Una gua para la seguridad en Fedora Linux Edicin 18.0.1
Autor Autor Autor Autor Autor Autor Johnray Fuller John Ha David O'Brien Scott Radvan Eric Christensen Adam Ligas jrfuller@redhat.com jha@redhat.com daobrien@redhat.com sradvan@redhat.com sparks@fedoraproject.org gent86@fedoraproject.org

Copyright 2007-2012 Fedora Project Contributors. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons AttributionShare Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. The original authors of this document, and Red Hat, designate the Fedora Project as the "Attribution Party" for purposes of CC-BY-SA. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. For guidelines on the permitted uses of the Fedora trademarks, refer to https://fedoraproject.org/wiki/ Legal:Trademark_guidelines. Linux is the registered trademark of Linus Torvalds in the United States and other countries. Java is a registered trademark of Oracle and/or its affiliates. XFS is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL is a registered trademark of MySQL AB in the United States, the European Union and other countries. All other trademarks are the property of their respective owners.

La Gua de Seguridad en Fedora est diseada para asistir a usuarios de Fedora en el proceso de aprendizaje y prcticas de seguridad en estaciones de trabajo y servidores, para poder as evitar intrusiones locales y remotas, explotaciones, y actividades maliciosas. Enfocada en Fedora Linux pero detallando conceptos y tcnicas validas para todos los sistemas Linux. La Gua de Seguridad en Fedora detalla la planificacin y describe las herramientas involucradas en la creacin de un entorno de computacin seguro, para centros de datos, estaciones de trabajo, o el hogar. Con un conocimiento administrativo apropiado, vigilancia, y herramientas, los sistemas ejecutando Linux pueden ser funcionales y al mismo tiempo seguros, frente a los mtodos de intrusin y explotacin ms comunes.

Prefacio vii 1. Convenciones del Documento ........................................................................................ vii 1.1. Convenciones Tipogrficas .................................................................................. vii 1.2. Convenciones del documento ............................................................................. viii 1.3. Notas y Advertencias ........................................................................................... ix 2. Necesitamos sus comentarios! ........................................................................................ x 1. Resumen acerca de la seguridad 1 1.1. Introduccin a la Seguridad .......................................................................................... 1 1.1.1. Qu es la seguridad en computacin? .............................................................. 1 1.1.2. SELinux ............................................................................................................ 3 1.1.3. Controles de seguridad ...................................................................................... 4 1.1.4. Conclusin ........................................................................................................ 5 1.2. Atacantes y vulnerabilidades ......................................................................................... 5 1.2.1. Una breve resea acerca de los hackers ............................................................ 5 1.2.2. Amenazas a la seguridad de la red .................................................................... 6 1.2.3. Amenazas a la seguridad del servidor ................................................................ 7 1.2.4. Amenazas a las estaciones de trabajo y seguridad en equipos hogareos ............. 9 1.3. Evaluacin de debilidades ............................................................................................ 9 1.3.1. Pensando como el enemigo ............................................................................. 10 1.3.2. Definiendo evaluacin y pruebas ...................................................................... 10 1.3.3. Herramientas de evaluacin ............................................................................. 12 1.4. Ataques y debilidades comunes .................................................................................. 15 1.5. Actualizaciones de seguridad ...................................................................................... 18 1.5.1. Actualizacin de paquetes ................................................................................ 18 1.5.2. Verificacin de paquetes firmados .................................................................... 18 1.5.3. Instalacin de paquetes firmados ..................................................................... 19 1.5.4. Aplicacin de los cambios ................................................................................ 20 2. Gua Bsica para reforzar la seguridad. 2.1. Principios Generales ................................................................................................... 2.2. Porque esto es importante? ...................................................................................... 2.3. Seguridad Fsica ........................................................................................................ 2.4. Porque esto es importante? ...................................................................................... 2.5. Que mas podemos hacer? ........................................................................................ 2.6. Networking ................................................................................................................. 2.6.1. iptables ........................................................................................................... 2.6.2. IPv6 ................................................................................................................ 2.7. Keeping software up to date ....................................................................................... 2.8. Services ..................................................................................................................... 2.9. NTP ........................................................................................................................... 3. Asegurando su Red 3.1. Seguridad de la estacin de trabajo ............................................................................ 3.1.1. Evaluacin de la seguridad de la estacin de trabajo ......................................... 3.1.2. Seguridad en el BIOS y en el gestor de arranque .............................................. 3.1.3. Seguridad de contraseas ................................................................................ 3.1.4. Controles administrativos ................................................................................. 3.1.5. Servicios de red disponibles ............................................................................. 3.1.6. Cortafuegos personales ................................................................................... 3.1.7. Herramientas de comunicacin de seguridad mejorada ...................................... 3.2. Seguridad del servidor ................................................................................................ 3.2.1. Asegurando los servicios con encapsuladores TCP y xinetd ............................... 3.2.2. Asegurando Portmap ....................................................................................... 3.2.3. Asegurando NIS .............................................................................................. 23 23 23 23 24 24 24 24 24 25 25 25 27 27 27 27 29 35 41 45 45 46 46 50 50 iii

Gua de seguridad 3.2.4. Asegurando NFS ............................................................................................. 53 3.2.5. Asegurando el servidor HTTP Apache .............................................................. 54 3.2.6. Asegurando FTP ............................................................................................. 55 3.2.7. Asegurando Sendmail ...................................................................................... 58 3.2.8. Verificar qu puertos estn abiertos .................................................................. 59 3.3. Single Sign-on (SSO) ................................................................................................. 60 3.3.1. Introduccin ..................................................................................................... 60 3.3.2. Empezar a utilizar su nueva tarjeta inteligente ................................................... 62 3.3.3. Como funciona la inscripcin de las tarjetas inteligentes. .................................... 63 3.3.4. Cmo funciona el ingreso con tarjeta inteligente ................................................ 64 3.3.5. Configurar Firefox para la utilizacin de Kerberos como SSO ............................. 65 3.4. Yubikey ...................................................................................................................... 67 3.4.1. Using Yubikey with a centralized server ............................................................ 68 3.4.2. Authenticating to websites with your Yubikey ..................................................... 68 3.5. Mdulos de autenticacin conectables (PAM, por las iniciales en ingls de Pluggable Authentication Modules) .................................................................................................... 68 3.5.1. Ventajas de PAM ............................................................................................. 69 3.5.2. Archivos de configuracin de PAM .................................................................... 69 3.5.3. Formato del archivo de configuracin de PAM ................................................... 69 3.5.4. Ejemplos de archivos de configuracin de PAM ................................................. 72 3.5.5. Creacin de los mdulos PAM ......................................................................... 73 3.5.6. PAM y el cacheo de la credencial administrativa ................................................ 74 3.5.7. PAM y la propiedad de los dispositivos ............................................................. 75 3.5.8. Recursos adicionales ....................................................................................... 77 3.6. Encapsuladores TCP y xinetd ..................................................................................... 78 3.6.1. Encapsuladores TCP ....................................................................................... 79 3.6.2. Archivos de configuracin de los encapsuladores TCP ....................................... 80 3.6.3. xinetd .............................................................................................................. 88 3.6.4. Archivos de configuracin de xinetd .................................................................. 88 3.6.5. Recursos adicionales ....................................................................................... 94 3.7. Kerberos .................................................................................................................... 95 3.7.1. Qu es Kerberos? ......................................................................................... 95 3.7.2. Terminologa de Kerberos ................................................................................ 96 3.7.3. Como Funciona Kerberos ................................................................................ 98 3.7.4. Kerberos y PAM ............................................................................................ 100 3.7.5. Configurando un servidor Kerberos 5 .............................................................. 100 3.7.6. Configuracin de un Cliente Kerberos 5 .......................................................... 102 3.7.7. Mapeo dominio-a-reinado ............................................................................... 104 3.7.8. Configurando KDCs secundarios .................................................................... 104 3.7.9. Configurando la autenticacin cruzada de reinados .......................................... 106 3.7.10. Recursos adicionales ................................................................................... 109 3.8. Cortafuegos .............................................................................................................. 111 3.8.1. Netfilter e IPTables ........................................................................................ 112 3.8.2. Configuracin bsica de un cortafuego ............................................................ 113 3.8.3. Uso de IPTables ............................................................................................ 116 3.8.4. Filtrado comn de IPTables ............................................................................ 117 3.8.5. Reglas FORWARD y NAT ................................................................................. 118 3.8.6. Software malicioso y suplantacin de direcciones IP ........................................ 121 3.8.7. IPTables y el seguimiento de la conexin ........................................................ 122 3.8.8. IPv6 .............................................................................................................. 123 3.8.9. Recursos adicionales ..................................................................................... 123 3.9. IPTables ................................................................................................................... 124 3.9.1. Filtrado de Paquete ....................................................................................... 124 3.9.2. Opciones de la lnea de comandos de IPTables ............................................... 126 iv

3.9.3. 3.9.4. 3.9.5. 3.9.6.

Guardando las reglas de IPTalbes .................................................................. Programas de control de IPTables .................................................................. IPTables e IPv6 ............................................................................................. Recursos adicionales .....................................................................................

135 136 138 138 141 141 141 141 142 142 157 158 161 162

4. Cifrado 4.1. Datos en reposo ....................................................................................................... 4.1.1. Cifrado completo del disco ............................................................................. 4.1.2. Cifrado basado en archivo ............................................................................. 4.2. Datos en movimiento ................................................................................................ 4.2.1. Redes privadas virtuales (VPNs, por las iniciales en ingls de Virtual Private Networks) ............................................................................................................... 4.2.2. Shell seguro (SSH, por las iniciales en ingls de Secure Shell) ......................... 4.2.3. Cifrado de disco LUKS (Linux Unified Key Setup-on-disk-format) ....................... 4.2.4. Archivos cifrados mediante 7-Zip .................................................................... 4.2.5. Utilizando GNU Privacy Guard (GnuPG) .........................................................

5. Principios Generales sobre la Seguridad de la Informacin 169 5.1. Consejos, Guas y Herramientas ............................................................................... 169 6. Instalacin segura 171 6.1. Particiones del disco ................................................................................................. 171 6.2. Utilice encriptado de particiones mediante LUKS ........................................................ 171 7. Mantenimiento de Software 7.1. Instale el software mnimo ........................................................................................ 7.2. Planifique y configure actualizaciones de seguridad .................................................... 7.3. Ajustando las actualizaciones automticas ................................................................. 7.4. Instale paquetes identificados desde repositorios conocidos ........................................ 173 173 173 173 173

8. Debilidades y exposiciones comunes 175 8.1. Complemento de Yum .............................................................................................. 175 8.2. Cmo utilizar yum-plugin-security .............................................................................. 175 9. Referencias A. Estndares de cifrado A.1. Cifrado sincronizado ................................................................................................. A.1.1. Advanced Encription Standard - AES .............................................................. A.1.2. Data Encryption Standard - DES .................................................................... A.2. Cifrado de llave pblica ............................................................................................ A.2.1. Diffie-Hellman ................................................................................................ A.2.2. RSA .............................................................................................................. A.2.3. DSA .............................................................................................................. A.2.4. SSL/TLS ....................................................................................................... A.2.5. Criptosistema de Cramer-Shoup ..................................................................... A.2.6. Cifrado ElGamal ............................................................................................ B. Historial de revisiones 177 179 179 179 179 180 180 181 181 181 182 182 183

vi

Prefacio
1. Convenciones del Documento
Este manual utiliza varias convenciones para resaltar algunas palabras y frases y llamar la atencin sobre ciertas partes especficas de informacin. En ediciones PDF y de papel, este manual utiliza tipos de letra procedentes de Liberation Fonts . Liberation Fonts tambin se utilizan en ediciones de HTML si estn instalados en su sistema. Si no, se muestran tipografas alternativas pero equivalentes. Nota: Red Hat Enterprise Linux 5 y siguientes incluyen Liberation Fonts predeterminadas.
1

1.1. Convenciones Tipogrficas


Se utilizan cuatro convenciones tipogrficas para llamar la atencin sobre palabras o frases especficas. Dichas convenciones y las circunstancias en que se aplican son las siguientes: Negrita monoespaciado Utilizada para resaltar la entrada del sistema, incluyendo comandos de shell, nombres de archivo y rutas. Tambin se utiliza para resaltar teclas claves y combinaciones de teclas. Por ejemplo: Para ver el contenido del archivo my_next_bestselling_novel en su directorio actual de trabajo, escriba el comando cat my_next_bestselling_novel en el intrprete de comandos de shell y pulse Enter para ejecutar el comando. El ejemplo anterior incluye un nombre de archivo, un comando de shell y una tecla clave. Todo se presenta en negrita-monoespaciado y distinguible gracias al contexto. Las combinaciones de teclas se pueden distinguir de las teclas claves mediante el guin que conecta cada parte de una combinacin de tecla. Por ejemplo: Pulse Enter para ejecutar el comando. Pulse Control+Alt+F2 para cambiar a la primera terminal virtual. Pulse Control+Alt+F1 para volver a su sesin de Ventanas-X. La primera oracin resalta la tecla clave determinada que se debe pulsar. La segunda resalta dos conjuntos de tres teclas claves que deben ser presionadas simultneamente. Si se discute el cdigo fuente, los nombres de las clase, los mtodos, las funciones, los nombres de variables y valores de retorno mencionados dentro de un prrafo sern presentados en Negritamonoespaciado. Por ejemplo: Las clases de archivo relacionadas incluyen filename para sistema de archivos, file para archivos y dir para directorios. Cada clase tiene su propio conjunto asociado de permisos. Negrita proporcional Esta denota palabras o frases encontradas en un sistema, incluyendo nombres de aplicacin, texto de cuadro de dilogo, botones etiquetados, etiquetas de cajilla de verificacin y botn de radio; ttulos de men y ttulos del sub-men. Por ejemplo:

https://fedorahosted.org/liberation-fonts/

vii

Prefacio Seleccionar Sistema Preferencias Ratn desde la barra del men principal para lanzar Preferencias de Ratn. En la pestaa de Botones, haga clic en la cajilla ratn de mano izquierda y luego haga clic en Cerrar para cambiar el botn principal del ratn de la izquierda a la derecha (adecuando el ratn para la mano izquierda). Para insertar un caracter especial en un archivo de gedit, seleccione desde la barra del men principal Aplicaciones Accessories Mapa de caracteres. Luego, desde la barra de menes de mapa de caracteres elija Bsqueda Hallar, teclee el nombre del caracter en el campo Bsqueda y haga clic en Siguiente. El caracter buscado se resaltar en la Tabla de caracteres. Haga doble clic en este caracter resaltado para colocarlo en el campo de Texto para copiar y luego haga clic en el botn de Copiar. Ahora regrese a su documento y elija Editar Pegar desde la barra de men de gedit. El texto anterior incluye nombres de aplicacin; nombres y elementos del men de todo el sistema; nombres de men de aplicaciones especficas y botones y texto hallados dentro de una interfaz grfica de usuario, todos presentados en negrita proporcional y distinguibles por contexto. Itlicas-negrita monoespaciado o Itlicas-negrita proporcional Ya sea negrita monoespaciado o negrita proporcional, la adicin de itlicas indica texto reemplazable o variable. Las itlicas denotan texto que usted no escribe literalmente o texto mostrado que cambia dependiendo de la circunstancia. Por ejemplo: Para conectar a una mquina remota utilizando ssh, teclee ssh nombredeusuario@dominio.nombre en un intrprete de comandos de shell. Si la mquina remota es example.com y su nombre de usuario en esa mquina es john, teclee ssh john@example.com. El comando mount -o remount file-system remonta el sistema de archivo llamado. Por ejemplo, para volver a montar el sistema de archivo /home, el comando es mount -o remount /home. Para ver la versin de un paquete actualmente instalado, utilice el comando rpm -q paquete. ste entregar el resultado siguiente: paquete-versin-lanzamiento. Observe las palabras en itlicas y negrita sobre nombre de usuario, domain.name, sistema de archivo, paquete, versin y lanzamiento. Cada palabra es un marcador de posicin, tanto para el texto que usted escriba al ejecutar un comando como para el texto mostrado por el sistema. Aparte del uso estndar para presentar el ttulo de un trabajo, las itlicas denotan el primer uso de un trmino nuevo e importante. Por ejemplo: Publican es un sistema de publicacin de DocBook.

1.2. Convenciones del documento


Los mensajes de salida de la terminal o fragmentos de cdigo fuente se distinguen visualmente del texto circundante. Los mensajes de salida enviados a una terminal se muestran en romano monoespaciado y se presentan as:
books books_tests Desktop Desktop1 documentation downloads drafts images mss notes photos scripts stuff svgs svn

viii

Notas y Advertencias Los listados de cdigo fuente tambin se muestran en romano monoespaciado, pero se presentan y resaltan de la siguiente manera:
package org.jboss.book.jca.ex1; import javax.naming.InitialContext; public class ExClient { public static void main(String args[]) throws Exception { InitialContext iniCtx = new InitialContext(); Object ref = iniCtx.lookup("EchoBean"); EchoHome home = (EchoHome) ref; Echo echo = home.create(); System.out.println("Created Echo"); System.out.println("Echo.echo('Hello') = " + echo.echo("Hello")); } }

1.3. Notas y Advertencias


Finalmente, utilizamos tres estilos visuales para llamar la atencin sobre la informacin que de otro modo se podra pasar por alto.

Nota
Una nota es una sugerencia, atajo o enfoque alternativo para una tarea determinada. Ignorar una nota no debera tener consecuencias negativas, pero podra perderse de algunos trucos que pueden facilitarle las cosas.

Importante
Los cuadros con el ttulo de importante dan detalles de cosas que se pueden pasar por alto fcilmente: cambios de configuracin nicamente aplicables a la sesin actual, o servicios que necesitan reiniciarse antes de que se aplique una actualizacin. Ignorar estos cuadros no ocasionar prdida de datos, pero puede causar enfado y frustracin.

Advertencia
Las advertencias no deben ignorarse. Ignorarlas muy probablemente ocasionar prdida de datos.

ix

Prefacio

2. Necesitamos sus comentarios!


Si encuentra un error tipogrfico en este manual o si sabe de alguna manera de mejorarlo, nos gustara escuchar sus sugerencias. Por favor complete un reporte en Bugzilla: http:// bugzilla.redhat.com/bugzilla/ usando el producto Fedora. Cuando enve un reporte de error no olvide mencionar el identificador del manual: security-guide Si tiene una sugerencia para mejorar la documentacin, intente ser tan especfico como sea posible cuando describa su sugerencia. Si ha encontrado un error, por favor incluya el nmero de seccin y parte del texto que rodea el error para que podamos encontrarlo ms fcilmente.

Resumen acerca de la seguridad


Debido a la creciente necesidad de utilizacin de poderosas computadoras conectadas en red para poder mantener una empresa en funcionamiento, y para poder realizar seguimientos de nuestra informacin personal, se han desarrollado industrias enteras dedicadas a la prctica de la seguridad de redes y computadoras. Numerosas empresas han solicitado la pericia y el conocimiento de expertos en seguridad para poder controlar correctamente sus sistemas, y para que diseen soluciones adecuadas a los requerimientos operativos de la organizacin. Debido a la naturaleza dinmica de muchas de estas organizaciones, donde los trabajadores deben tener acceso a los recursos informticos, ya sea en forma local o remota, la necesidad de entornos de computacin seguros se ha hecho ms pronunciada. Desafortunadamente, muchas de las organizaciones (y muchos usuarios individuales), luego de pensarlo dos veces, deciden relegar el aspecto de la seguridad a un plano inferior, dndole prioridad a otras reas de sus emprendimientos, como ser produccin, presupuesto, o infraestructura. Y frecuentemente, una implementacin adecuada de la seguridad es adoptada postmortem despus que un acceso no autorizado haya ocurrido. Los expertos en seguridad concuerdan en que adoptar las medidas correctas antes de conectar un sitio a una red insegura, como lo es Internet, es una manera efectivo de prevenir la mayora de los intentos de intrusin.

1.1. Introduccin a la Seguridad


1.1.1. Qu es la seguridad en computacin?
La nocin de seguridad en computacin es un concepto general que cubre un rea muy extensa dentro del mbito de la computacin y del procesamiento de la informacin. Las industrias que dependen tanto de redes como de sistemas de computacin para poder realizar cotidianamente operaciones comerciales, o para acceder a diverso tipo de informacin vital, entienden que sus datos son una parte importante de sus activos. Han ingresado a nuestro vocabulario cotidiano diversos trminos y unidades de medicin pertenecientes al mbito comercial, como ser por ejemplo, el coste total de propiedad (TCO, por las iniciales en ingls de Total Cost of Ownership), o servicio de calidad (QoS, por las iniciales en ingls de Quality of Service). Al utilizar estas unidades, las industrias pueden calcular aspectos tales como ser la integridad de los datos, o el tipo de disponibilidad que tienen, y poder considerarlos parte de los costos de planeamiento y administracin de procesos. En algunas industrias, como la del comercio electrnico por ejemplo, el tipo de disponibilidad y la confiabilidad de los datos puede ser un elemento determinante para el xito o el fracaso.

1.1.1.1. De dnde viene la idea de seguridad en computacin?


La seguridad en la informacin ha evolucionado con el correr de los aos debido al aumento en la utilizacin de redes pblicas y el consecuente riesgo de exposicin que en ellas tienen los datos 1 privados, confidenciales o financieros. Existen numerosos antecedentes, como el caso Mitnick o 2 Vladimir Levin , que sugieren a todas las organizaciones de cualquier tipo de industria, replantearse la forma en que tienen organizado el manejo de su propia informacin, o de la manera en que es transmitida y revelada. La popularidad que tiene Internet es uno de los motivos fundamentales gracias al cual se han intensificado los esfuerzos relacionados con la seguridad en los datos. Un nmero creciente de personas est utilizando sus computadoras personales para obtener acceso a los recursos que ofrece Internet. Desde investigacin y obtencin de informacin hasta el correo

1 2

http://law.jrank.org/pages/3791/Kevin-Mitnick-Case-1999.html http://www.livinginternet.com/i/ia_hackers_levin.htm

Captulo 1. Resumen acerca de la seguridad electrnico y transacciones comerciales, Internet es considerada como uno de los desarrollos ms importantes del siglo 20. Sin embargo, Internet y sus primeros protocolos fueron desarrollados como un sistema basado en la confianza. Esto significa que el Protocolo de Internet no fue diseado para ser seguro en s mismo. No existen estndares de seguridad aprobados dentro del bloque de comunicaciones TCP/ IP, dejndolo indefenso ante usuarios o procesos de la red potencialmente dainos. Desarrollos modernos han hecho de las comunicaciones en Internet algo ms seguro, pero todava existen varios incidentes que acaparan la atencin mundial, y nos recuerdan el hecho de que nada es completamente seguro.

1.1.1.2. La seguridad hoy


En febrero del ao 2000 un ataque de denegacin de servicio distribuido (DDoS, por las iniciales en ingls de Distributed Denial of Service) fue liberado sobre varios de los sitios de Internet que tenan ms trfico. Este ataque afect a yahoo.com, cnn.com, amazon.com, fbi.gov y algunos otros sitios que son completamente inaccesibles para los usuarios normales, dejando a los enrutadores bloqueados durante varias horas con transferencias de grandes paquetes ICMP, o tambin denominado un ping de la muerte. El ataque fue llevado a cabo por asaltantes desconocidos utilizando programas especialmente creados (y que estn a disposicin de cualquiera), que buscan servidores de red vulnerables, instalan en esos servidores aplicaciones de cliente denominadas troyanos, y sincronizando un ataque con cada servidor infectado, inundando los sitios elegidos y dejndolos inutilizables. Muchos adjudican el xito del ataque a fallas fundamentales en la forma en que estn estructurados los enrutadores y los protocolos que utilizan. Estas fallas tienen que ver con la manera en que se aceptan los datos entrantes, sin importar desde dnde provengan, o con qu propsito los paquetes hayan sido enviados. En el ao 2007, una prdida de datos permiti la explotacin de una debilidad bien conocida en el protocolo de cifrado inalmbrico WEP (por las iniciales en ingls de Wired Equivalent Privacy), que result en el robo de 45 millones de nmeros de tarjetas de crditos de una institucin financiera 3 global. En un incidente separado, los registros de facturacin de ms de 2,2 millones de pacientes almacenados en una cinta de respaldo fueron robados desde el asiento delantero de un auto de 4 mensajera. Actualmente, se estima que 1,8 mil millones de personas usan o usaron Internet alrededor del mundo 5 . Al mismo tiempo: En cualquier da, hay aproximadamente 225 incidentes principales de fallas de seguridad informados al Centro de Coordinacin CERT en la Universidad de Carnegie Mellon. En el ao 2003, el nmero de incidencias CERT informadas ascendi a 137,529 de los 82,094 informados en el ao 2002, y de los 52,658 en el 2001. El impacto econmico a nivel mundial de los virus de Internet ms peligrosos de los ltimos tres aos se estim en US$ 13.2 mil millones. From a 2008 global survey of business and technology executives "The Global State of Information 6 Security" , undertaken by CIO Magazine, some points are:

3 4

http://www.theregister.co.uk/2007/05/04/txj_nonfeasance/ http://www.healthcareitnews.com/story.cms?id=9408 5 http://www.internetworldstats.com/stats.htm 6 http://www.csoonline.com/article/454939/The_Global_State_of_Information_Security_

SELinux Slo el 43% de los encuestados audita o monitorea el cumplimiento de las polticas de seguridad de sus usuarios Slo el 22% mantiene un inventario de las compaas externas que utilizan sus datos El origen de casi la mitad de los incidentes de seguridad fueron marcados como "Desconocido". 44% de los encuestados planean incrementar sus gastos en seguridad en el ao siguiente 59% tiene una estrategia de seguridad de la informacin Estos resultados refuerzan la realidad de que la seguridad de computadoras se ha vuelto un gasto cuantificable y justificable en los presupuestos de TI. Las organizaciones que necesitan tanto la integridad como la rpida disponibilidad de sus datos, lo obtienen gracias a la habilidad que los administradores de sistema, desarrolladores e ingenierospara tienen para asegurar la disponibilidad de sus sistemas, servicios y datos, durante las 24 horas de los 365 das del ao. Ser vctima de usuarios maliciosos, procesos o ataques coordinados es una amenaza directa al xito de la organizacin. Desafortunadamente, la seguridad de sistemas y de la red puede ser una proposicin difcil, que requiere un conocimiento intrincado de cmo una organizacin expresa, usa, manipula y transmite su informacin. El entendimiento de la forma en que una organizacin (y la gente que la compone) conduce el negocio es primordial para implementar un plan de seguridad apropiado.

1.1.1.3. Estandarizando la seguridad


Las empresas de todas las industrias confan en las regulaciones y en las reglas que son puestas por las personas que construyen estndares tales como la Asociacin Mdica Americana (AMA, por las iniciales en ingls de American Medical Association) o el Instituto de Ingenieros Elctricos y Electrnicos (IEEE, Institute of Electrical and Electronics Engineers). Los mismos ideales se aplican a la seguridad de la informacin. Muchos consultores y fabricantes se ponen de acuerdo en el modelo de seguridad estndar conocido como CIA (Confidentiality, Integrity and Availability), o Confidencialidad, Integridad y Disponibilidad. Este modelo de 3 capas es un componente generalmente aceptado para averiguar los riesgos de la informacin vital y del establecimiento de la poltica de seguridad. A continuacin se describe el modelo CIA en ms detalle: Confidentiality Sensitive information must be available only to a set of pre-defined individuals. Unauthorized transmission and usage of information should be restricted. For example, confidentiality of information ensures that a customer's personal or financial information is not obtained by an unauthorized individual for malicious purposes such as identity theft or credit fraud. Integridad La informacin no debe alterarse de manera tal que se torne incompleta o incorrecta. Los usuarios no autorizados deben ser restringidos de la habilidad de modificar o destruir informacin vital. Disponibilidad La informacin debe ser accesible a usuarios autorizados en cualquier momento en el que sea necesario. La disponibilidad es una garanta de que la informacin se puede obtener en una frecuencia y duracin preestablecida. Esto se mide a menudo en trminos de porcentajes y se deja sentado formalmente en Acuerdos de Disponibilidad del Servicio (SLAs, por las iniciales en ingls de Service Level Agreements) con los proveedores de servicios de red y sus clientes empresariales.

1.1.2. SELinux
Fedora incluye una mejora al kernel de Linux que se llama SELinux, que implementa la arquitectura de Control de Acceso Obligatorio (MAC), que provee un nivel ms fino de control sobre los archivos, 3

Captulo 1. Resumen acerca de la seguridad procesos, usuarios y aplicaciones en el sistema. La discusin detallada sobre SELinux est ms all del alcance de este documento; sin embargo, para ms informacin sobre SELinux y su uso en Fedora, vaya a la Gua del Usuario de SELinux de Fedora disponible en http://docs.fedoraproject.org/ selinux-user-guide/. Hay otros recursos de SELinux listados en Captulo 9, Referencias.

1.1.3. Controles de seguridad


La seguridad de computadoras es a menudo dividida en tres categoras principales distintas, comnmente referidas como controles: Fsico Tcnico Asministrativo Estas tres amplias categoras definen los objetivos principales de una implementacin de seguridad apropiada. Dentro de estos controles existen subcategoras que ofrecen mayores caractersticas, o brindan informacin acerca de su correcta implementacin.

1.1.3.1. Control fsico


El control fsico es la implementacin de medidas de seguridad en una estructura definida, utilizado para determinar o evitar el acceso no autorizado a material sensible. Ejemplos de controles fsicos son: Circuito cerrado de cmaras de vigilancia Sistemas de alarma de movimientos, o termales Guardias de la seguridad IDs de Imagen Puertas de acero bloqueadas y selladas Biometra (incluye huellas digitales, voz, cara, iris, escritura manual y otros mtodos automatizados usados para reconocer a los individuos)

1.1.3.2. Tcnicas de control


Los controles tcnicos usan la tecnologa como una base para el control del acceso y del uso de datos sensibles a travs de una estructura fsica y sobre una red. Los controles tcnicos son de largo alcance y abarcan tecnologas como: Cifrado Tarjetas inteligentes Autenticacin de red Listas de control de acceso (ACLs) Software para auditar la integridad de archivos

Conclusin

1.1.3.3. Controles administrativos


Los controles administrativos definen los factores humanos de la seguridad. Involucran todos los niveles del personal dentro de una organizacin y determinan qu usuarios tienen acceso a qu recursos y la informacin por tales medios como: Capacitacin y conocimientos Preparacin para desastres y planes de recuperacin Reclutamiento de personal y estrategias de separacin Registracin y control del personal

1.1.4. Conclusin
Ahora que ya conoce los orgenes, las razones y los aspectos de la seguridad, encontrar ms fcil determinar el rumbo apropiado con respecto a Fedora. Es importante conocer qu factores y condiciones hacen a la seguridad para planear e implementar una estrategia apropiada. Con esta informacin en mente, el proceso se puede formalizar y los caminos a seguir se hacen ms claros a medida que profundiza en los detalles del proceso de seguridad.

1.2. Atacantes y vulnerabilidades


Para poder planificar e implementar una buena estrategia de seguridad, tenga en cuenta primero algunos de los problemas que son aprovechados por los atacantes para poder vulnerar los sistemas. Sin embargo, antes de detallar estos problemas, tenemos que definir la terminologa utilizada a la hora de identificar a un atacante.

1.2.1. Una breve resea acerca de los hackers


El significado moderno del trmino hacker tiene sus orgenes en la dcada del '60, en el Tech Model Railroad Club del Instituto de Tecnologa de Massachusetts (MIT, por las siglas en ingls de Massachusetts Institute of Technology), en donde se diseaban modelos de trenes a gran escala y con detalles muy especficos. "Hacker" era el nombre con el que se identificaba a los miembros del club capaces de sortear las dificultades que presentaba un determinado problema, o que descubra algn truco til. Desde entonces el trmino "hacker" se ha utilizado para referirse o bien a un aficionado en computadoras, o bien a un programador talentoso, o bien para todo lo que se encuentre entre ellos. Una caracterstica compartida entre cualquier tipo de "hacker" es la voluntad de investigar detalladamente cmo funciona un sistema de computadoras, o una red, con poca o ninguna motivacin ulterior adems del mero hecho de investigar. Los desarrolladores de software de cdigo abierto, a menudo se consideran as mismos y a sus colegas como "hackers", y utilizan esta palabra como un signo de respeto. Generalmente, los hackers siguen un cdigo de conducta establecido en la etica del hacker, que establece que la bsqueda de informacin y la excelencia son esenciales, y que el hecho de compartir los conocimientos adquiridos es un deber que el hacker tiene para con la comunidad. A lo largo de esta bsqueda del conocimiento, algunos hackers disfrutan de los desafos acadmicos que representan el hecho de sortear los controles de seguridad en los sistemas computarizados. Por este motivo, generalmente el periodismo utiliza el trmino hacker para referirse a quienes acceden ilegalmente y con fines criminales, malintencionados o inescrupulosos, a redes o sistemas de computacin. La forma ms adecuada para referirse a este tipo de hackers es atacante un trmino creado por los hackers a mediados de la dcada del '80, para diferenciar ambas comunidades. 5

Captulo 1. Resumen acerca de la seguridad

1.2.1.1. Zonas grises


Within the community of individuals who find and exploit vulnerabilities in systems and networks are several distinct groups. These groups are often described by the shade of hat that they "wear" when performing their security investigations and this shade is indicative of their intent. El hacker de sombrero blanco es quien examina los sistemas y las redes para conocer sus capacidades y poder determinar qu tan vulnerables son ante una posible intrusin. Generalmente, este tipo de hackers vulnera su propio sistema, o los sistemas de algn cliente suyo que lo ha contratado especficamente con el propsito de controlar su seguridad. Investigadores acadmicos y consultores profesionales en el rea de seguridad son ejemplos de hackers de sombrero blanco. Un hacker de sombrero negro es sinnimo de atacante. Generalmente, los atacantes estn menos interesados en la programacin o en el aspecto acadmico a la hora de vulnerar sistemas. Usualmente utilizan una serie de programas desarrollados exclusivamente para atacar y vulnerar los aspectos de un sistema que de antemano se sabe que pueden llegar a fallar, y los utilizan para dejar al descubierto informacin valiosa en tales sistemas o redes, o para obtener un beneficio personal, o simplemente para causar dao. Por otro lado, un hacker de sombrero gris tiene la habilidad de un hacker de sombrero blanco, y en la mayora de los casos tambin sus intenciones, pero en algunas ocasiones utiliza su conocimiento para propsitos no tan nobles. Puede pensarse en un hacker de sombrero gris como un hacker de sombrero blanco, que a veces utiliza un sombrero negro para cumplir con objetivos personales. Generalmente los hackers de sombrero gris se rigen por una norma diferente de la tica del hacker, que establece que es aceptable vulnerar sistemas, siempre y cuando el hacker no cometa ningn delito ni haga pblico aquello que es considerado privado. Sin embargo, alguien podra argumentar, que el acto de vulnerar un sistema es en s mismo un acto no tico. Sin importar la intencin del intruso, es importante conocer la debilidad que un atacante puede intentar explotar. El resto del captulo se centra en estas cuestiones.

1.2.2. Amenazas a la seguridad de la red


Malas prcticas cuando se configuran los siguientes aspectos de una red pueden aumentar el riesgo de un ataque.

1.2.2.1. Arquitecturas inseguras


Una red mal configurada es el principal punto de ingreso para usuarios no autorizados. Dejar una red local, a cuyos usuarios conocemos, abierta y vulnerable a la gran inseguridad que representa Internet es casi como dejar una puerta entornada en un barrio de criminales. Tal vez no suceda nada en un determinado perodo de tiempo, pero en algn momento, alguien va a aprovechar esa oportunidad

1.2.2.1.1. Redes emisoras


Los administradores de sistemas muchas veces no se dan cuenta de la importancia que tiene el hardware de red que utilizan a la hora de realizar los esquemas de seguridad. El hardware que se considera sencillo, como son los enrutadores y los concentradores, dependen del principio de transmisin o principio de no interrupcin; esto es, siempre que un nodo transmisor enve datos sobre una red hacia un nodo receptor, el concentrador o enrutador enva una transmisin del paquete de datos hasta que el nodo receptor recibe y procesa los datos. Este mtodo es el ms vulnerable para enviar resolucin de protocolo (arp) o control de acceso de contenidos (MAC), ya que esta forma de envo es accesible tanto por intrusos fuera del equipo, como por usuarios no autorizados dentro de l. 6

Amenazas a la seguridad del servidor

1.2.2.1.2. Servidores centralizados


Otro error posible de cometer dentro de una red, es el uso de computacin centralizada. Una medida comn adoptada por muchos comercios a la hora de reducir su presupuesto, es la de concentrar todos los servicios en una nica mquina, relativamente poderosa. Esto puede ser conveniente ya que hace ms sencillas las tareas administrativas, y el costo es econmicamente inferior al de realizar configuraciones sobre varios servidores. Sin embargo, un servidor centralizado representa el nico punto de acceso a la red. Si el servidor central es vulnerado, puede inutilizar completamente a la red, o peor an, puede hacer que los datos sean fcilmente manipulados, o directamente sustrados. En estas situaciones, un servidor central se convierte en una puerta abierta que permite el acceso a la red en su totalidad.

1.2.3. Amenazas a la seguridad del servidor


Server security is as important as network security because servers often hold a great deal of an organization's vital information. If a server is compromised, all of its contents may become available for the cracker to steal or manipulate at will. The following sections detail some of the main issues.

1.2.3.1. Servicios no usados y puertos abiertos


Una instalacin completa de Fedora contiene ms de 1000 aplicaciones y bibliotecas de paquetes. Sin embargo, muchos administradores de servidores eligen no instalar todos los paquetes de la distribucin, y prefieren en su lugar realizar una instalacin de los paquetes bsicos, incluyendo algunas aplicaciones de servidor. Una ocurrencia tpica entre los administradores de servidores es la de instalar el sistema operativo sin prestar atencin a los programas que efectivamente se estn instalando. Esto puede llegar a ser problemtico debido a que podran instalarse servicios innecesarios, configurarse con los parmetros establecidos por defecto, y posiblemente iniciarse. Esto puede causar que servicios no deseados, como Telnet, DHCP o DNS se ejecuten en un servidor o estacin de trabajo sin que el administrador lo sepa, lo que a su vez puede generar trfico no solicitado hacia el servidor, o incluso un posible camino de acceso al sistema para los atacantes. Para obtener mayor informacin acerca del cierre de puertos y desconexin de servicios que no se utilicen, vea Seccin 3.2, Seguridad del servidor.

1.2.3.2. Servicios no parchados


La mayora de las aplicaciones de servidor que se incluyen en una instalacin por defecto son piezas de software slidas y completamente comprobadas. Habiendo sido utilizadas en entornos de produccin durante muchos aos, el cdigo de ellas ha sido totalmente refinado y muchos de sus errores han sido encontrados y corregidos. Sin embargo, no existe algo as como el software perfecto y existe siempre un margen para futuras mejoras. Es ms, por lo general el software ms reciente no ha sido probado con el rigor que uno podra esperar, debido a su reciente aparicin en los entornos de produccin, o debido a que no es tan popular como otros. Los desarrolladores y los administradores de sistemas encuentran a menudo, en algunas aplicaciones de servidor, errores que podran ser aprovechados para vulnerar el sistema, y publican la informacin de tal error en un sitio web relacionado con el tema, como ser por ejemplo, la lista de correo Bugtraq (http://www.securityfocus.com) o el Equipo de Respuesta de Emergencias de Computacin (CERT, por las iniciales en ingls de Computer Emergency Response Team), cuyo sitio web es (http:// www.cert.org). Si bien estos mecanismos son una forma efectiva de advertir a la comunidad acerca de problemas en la seguridad, queda en manos de los administradores del sistema enmendar sus sistemas. Esto es realmente verdadero ya que los atacantes tienen acceso a estos mismos sitios y podrn utilizar la informacin para vulnerar sistemas que an no han sido enmendados. Ser un buen 7

Captulo 1. Resumen acerca de la seguridad administrador de sistemas implica ser vigilante, estar atento permanentemente a los errores y a sus soluciones, y ser capaz de realizar una manutencin adecuada del sistema para asegurar un entorno de computacin seguro. Vaya a la Seccin 1.5, Actualizaciones de seguridad para ms informacin sobre cmo mantener un sistema actualizado.

1.2.3.3. Administracin desatendida


Administrators who fail to patch their systems are one of the greatest threats to server security. According to the SysAdmin, Audit, Network, Security Institute (SANS), the primary cause of computer security vulnerability is to "assign untrained people to maintain security and provide neither the training 7 nor the time to make it possible to do the job." This applies as much to inexperienced administrators as it does to overconfident or amotivated administrators. Alguno administradores no pueden enmendar sus servidores o estaciones de trabajo, y otros no le prestan atencin a los mensajes de registro enviados desde el kernel del sistema, o generados por el trfico en la red. Otro error comn se produce al no modificar las contraseas o claves establecidas por defecto para los servicios. Por ejemplo, algunas bases de datos tienen contraseas administrativas generadas por defecto, debido a que los desarrolladores de las bases de datos presuponen que el administrador del sistema las modificar inmediatamente despus de haberla instalado en su sistema. Si un administrador de una base de datos no cambia la contrasea, incluso un atacante sin demasiada experiencia puede utilizar una amplia gama de contraseas que se sabe le pueden otorgar privilegios de administrador en esa base de datos. Estos son slo algunos ejemplos que ilustran de qu manera una administracin dbil puede ocasionar la vulnerabilidad de los servidores.

1.2.3.4. Servicios inseguros en s mismos


Incluso la organizacin ms precavida puede ser vctima de sus puntos dbiles, si elige utilizar servicios de red inseguros. Por ejemplo, existen numerosos servicios desarrollados presuponiendo que sern utilizados en redes que se consideran confiables. Sin embargo, este presupuesto deja de funcionar ni bien el servicio se utiliza en Internet que es considerada una red insegura. Una categora de servicios de red no seguros son aquellos que en el momento de la autenticacin, piden nombres de usuario y contraseas que no estn encriptados. Telnet y FTP son dos ejemplos de este tipo de servicios. Si algn software diseado para sustraer informacin se encuentre vigilando el trfico entre el usuario remoto y un servicio con estas caractersticas, tanto los nombres de usuario como las contraseas pueden ser interceptadas fcilmente. Inherently, such services can also more easily fall prey to what the security industry terms the man-inthe-middle attack. In this type of attack, a cracker redirects network traffic by tricking a cracked name server on the network to point to his machine instead of the intended server. Once someone opens a remote session to the server, the attacker's machine acts as an invisible conduit, sitting quietly between the remote service and the unsuspecting user capturing information. In this way a cracker can gather administrative passwords and raw data without the server or the user realizing it. Another category of insecure services include network file systems and information services such as NFS or NIS, which are developed explicitly for LAN usage but are, unfortunately, extended to include WANs (for remote users). NFS does not, by default, have any authentication or security mechanisms configured to prevent a cracker from mounting the NFS share and accessing anything contained

http://www.sans.org/resources/errors.php

Amenazas a las estaciones de trabajo y seguridad en equipos hogareos therein. NIS, as well, has vital information that must be known by every computer on a network, including passwords and file permissions, within a plain text ASCII or DBM (ASCII-derived) database. A cracker who gains access to this database can then access every user account on a network, including the administrator's account. Por defecto, Fedora es liberada con todos estos servicios apagados. Sin embargo, dado que los administradores a menudo se encuentran obligados a utilizarlos, es muy importante realizar cuidadosamente la configuracin de ellos. Para obtener mayor informacin acerca de cmo configurar los servicios en forma segura, vea Seccin 3.2, Seguridad del servidor.

1.2.4. Amenazas a las estaciones de trabajo y seguridad en equipos hogareos


Workstations and home PCs may not be as prone to attack as networks or servers, but since they often contain sensitive data, such as credit card information, they are targeted by system crackers. Workstations can also be co-opted without the user's knowledge and used by attackers as "slave" machines in coordinated attacks. For these reasons, knowing the vulnerabilities of a workstation can save users the headache of reinstalling the operating system, or worse, recovering from data theft.

1.2.4.1. Malas contraseas


Las malas contraseas son una de las formas ms fciles para que un atacante obtenga el acceso a un sistema. Para informacin sobre cmo evitar los errores comunes, vaya a Seccin 3.1.3, Seguridad de contraseas.

1.2.4.2. Aplicaciones de tipo cliente vulnerables


Although an administrator may have a fully secure and patched server, that does not mean remote users are secure when accessing it. For instance, if the server offers Telnet or FTP services over a public network, an attacker can capture the plain text usernames and passwords as they pass over the network, and then use the account information to access the remote user's workstation. An cuando se utilicen protocolos seguros, como SSH, un usuario remoto puede ser vulnerable a ciertos ataques si no mantiene actualizadas sus aplicaciones de cliente. Por ejemplo, los clientes de SSH v.1 son vulnerables a un ataque de reenvo de X que provenga de servidores maliciosos. Una vez conectado al servidor, el atacante puede capturar silenciosamente cualquier presin de teclas o pulsacin del ratn que el cliente haya hecho sobre la red. Este problema fue solucionado con el protocolo SSH v.2, pero queda en manos del usuario conocer qu aplicaciones tienen puntos dbiles, y actualizarlas cuando sea necesario. Seccin 3.1, Seguridad de la estacin de trabajo discute ms en detalle los pasos que los administradores y usuarios hogareos deben tomar para limitar la vulnerabilidad de las computadoras estaciones de trabajo.

1.3. Evaluacin de debilidades


Dependiendo del tiempo, de los recursos y de la motivacin, un atacante puede ingresar prcticamente en cualquier sistema. En trminos absolutos, ninguna tecnologa o proceso en seguridad actualmente disponible, puede garantizar que un sistema determinado sea completamente invulnerable. Los enrutadores contribuyen a la seguridad de las puertas de enlace frente a Internet. Los cortafuegos contribuyen a la seguridad de las redes internas. Las redes virtuales privadas envan datos en forma segura mediante un flujo encriptado. Sistemas para la deteccin de extraos le avisan en caso de encontrar actividad malintencionada. Sin embargo, el xito de cada una de estas tecnologas depende de una numerosa cantidad de variables, entre las cuales podemos encontrar: 9

Captulo 1. Resumen acerca de la seguridad La experiencia del equipo responsable de la configuracin, monitoreo y manutencin de esas tecnologas. La habilidad para enmendar y actualizar servicios y servidores en forma veloz y eficiente. La habilidad de quienes son responsables de mantener sobre la red una vigilancia permanente. Debido a las caractersticas dinmicas de los sistemas de datos y de las tecnologas, asegurar los recursos corporativos puede llegar a ser algo bastante complejo. Debido a esta complejidad, a menudo es difcil encontrar herramientas experimentadas para todos sus sistemas. Si bien es posible contar con personal cuyos conocimientos abarquen numerosos aspectos de los niveles generales de la seguridad en la informacin, es difcil conservar a quienes puedan considerarse expertos en los diferentes aspectos de una misma rea. Principalmente esto sucede debido a que cada aspecto de cada rea de la seguridad en la informacin necesita atencin y concentracin constante. La seguridad en la informacin nunca permanece inmvil.

1.3.1. Pensando como el enemigo


Suppose that you administer an enterprise network. Such networks are commonly comprised of operating systems, applications, servers, network monitors, firewalls, intrusion detection systems, and more. Now imagine trying to keep current with each of these. Given the complexity of today's software and networking environments, exploits and bugs are a certainty. Keeping current with patches and updates for an entire network can prove to be a daunting task in a large organization with heterogeneous systems. Combine la experiencia que habra que necesitarse, con las tareas a realizar para mantenerse actualizado, y sern inevitables la presencia de incidentes, de sistemas vulnerados, de datos alterados, y de servicios interrumpidos. Para incrementar las tecnologas en seguridad y ayudar a proteger los sistemas, redes y datos, debera pensar del mismo modo en que lo hace un atacante, y desde este punto de vista comprobar la seguridad de su sistema verificando sus debilidades. Realizar evaluaciones de seguridad preventivas de su sistema y recursos de red, pueden ensearle potenciales problemas, y solucionarlos, antes que sean aprovechados por un atacante. Una evaluacin de debilidades es una auditora interna de su red y de su sistema de seguridad, cuyo resultado indica la confidencialidad, integridad y disponibilidad de su red (como es explicado en Seccin 1.1.1.3, Estandarizando la seguridad). Por lo general, una evaluacin de debilidades se inicia con una etapa de reconocimiento, durante la cual se obtienen datos importantes relacionados con los sistemas y los recursos involucrados. En la etapa siguiente se verifica el sistema en busca de debilidades conocidas, y culmina con una etapa de informe, en donde todo lo que se ha encontrado es clasificado entre las categoras de riesgo alto, medio y bajo. En esta ltima etapa, adems, se proponen mtodos para mejorar la seguridad (o eliminar el riego) del sistema analizado. Si usted tuviera que realizar una evaluacin de las debilidades de su hogar, seguramente verificara que cada una de las puertas se encuentre cerrada con llave. Tambin confirmara que cada una de las ventanas est cerrada, y trabada con el pestillo. El mismo concepto se aplica a los sistemas, redes y datos electrnicos. Los usuarios malintencionados son los ladrones de sus datos. Concntrese en las herramientas que utilizan, en su forma de pensar y en sus motivaciones, y entonces ser capaz de poder anticiparse a sus acciones.

1.3.2. Definiendo evaluacin y pruebas


Las evaluaciones de debilidades pueden ser catalogadas en dos grandes tipos: De afuera hacia adentro y de adentro hacia afuera. 10

Definiendo evaluacin y pruebas When performing an outside looking in vulnerability assessment, you are attempting to compromise your systems from the outside. Being external to your company provides you with the cracker's viewpoint. You see what a cracker sees publicly-routable IP addresses, systems on your DMZ, external interfaces of your firewall, and more. DMZ stands for "demilitarized zone", which corresponds to a computer or small subnetwork that sits between a trusted internal network, such as a corporate private LAN, and an untrusted external network, such as the public Internet. Typically, the DMZ contains devices accessible to Internet traffic, such as Web (HTTP) servers, FTP servers, SMTP (email) servers and DNS servers. Cuando realice una evaluacin de debilidades desde adentro hacia afuera, usted tiene una especie de ventaja ya que, al estar en una ubicacin interna, su estado es el de ser alguien confiable, y por lo tanto, superior. Este es el punto de vista adquieren usted y sus compaeros de trabajo, cada vez que se registran en el sistema. Puede ver servidores de impresin, servidores de archivos, bases de datos, y dems recursos. Existen notables distinciones entre estos dos tipos de evaluaciones. Desde el interior de la compaa se tienen privilegios superiores a los que se obtendran desde el exterior. An hoy, en muchas organizaciones, la seguridad es configurada de tal manera para evitar que ingresen intrusos desde el exterior, y muy poco se hace para asegurar los elementos internos de la organizacin (como ser cortafuegos departamentales, controles de acceso de niveles de usuarios, procedimientos de autenticaciones para recursos internos, etc.). Por lo general, existen muchos ms recursos si se busca dentro de una compaa, ya que la mayora de los sistemas son internos a ella. Una vez que se encuentre fuera de la compaa, inmediatamente ser identificado como un elemento no seguro. Los sistemas y las herramientas disponibles para utilizar desde fuera son, generalmente, muy limitadas. Considere la diferencia existente entre evaluaciones de debilidades y pruebas de penetracin. Piense en una evaluacin de debilidades como el primer paso de una prueba de penetracin. La informacin obtenida en la evaluacin es utilizada para la prueba. Cualesquiera sean las reas o los lugares que el resultado de la evaluacin haya sugerido verificar en bsqueda de agujeros o debilidades potenciales, sern esos mismos lugares los que la prueba de penetracin intentar utilizar para aprovechar esas debilidades e ingresar al sistema. Acceder a la infraestructura de la red es un proceso dinmico. La seguridad es dinmica, tanto la fsica como la de la informacin. Realizar una evaluacin determina una visin general, que puede arrojar resultados falsos, tanto para bien como para mal. La eficacia de los administradores de seguridad es directamente proporcional a las herramientas que utilizan y al conocimiento que poseen. Elija cualquiera de las herramientas de evaluacin que se encuentren disponibles actualmente, ejectelas en su sistema, y es casi una garanta que algunos resultados sern errneos. Ya sea por una falla del programa, o por un error del usuario, el resultado ser el mismo. La herramienta puede llegar a encontrar debilidades que en realidad no existen (falsos positivos); o , peor an, la herramienta puede no encontrar debilidades que efectivamente existen (falsos negativos). Ahora que ha sido definida la diferencia entre una evaluacin de debilidades y una prueba de penetracin, como parte de una mejor aplicacin de los mtodos, revise cuidadosamente los datos arrojados por la evaluacin antes de realizar una prueba de penetracin.

Advertencia
Intentar aprovechar las debilidades de los recursos de produccin, puede tener efectos adversos en la productividad y eficiencia de sus sistemas y redes.

11

Captulo 1. Resumen acerca de la seguridad En la lista siguiente se examinan algunos de los beneficios de llevar a cabo evaluaciones de vulnerabilidad. Crea un enfoque pro-activo sobre la seguridad de la informacin Encuentra potenciales debilidades antes que las encuentren los atacantes Funciona en sistemas que se mantiene actualizados y enmendados Promueve el crecimiento y la asistencia en el desarrollo de la especializacin del personal Reduce las prdidas econmicas y la publicidad negativa

1.3.2.1. Estableciendo una metodologa


Para ayudar en la seleccin de las herramientas para realizar una evaluacin de debilidades, es til establecer un mtodo. Desafortunadamente, por el momento no existe una metodologa previamente definida, sin embargo, el sentido comn y el hecho de adoptar buenas costumbres en materia de seguridad pueden actuar como una gua eficiente. Cul es el objetivo? Estamos observando un servidor, o la totalidad de una red y todo lo que en ella existe? Estamos fuera o dentro de la compaa? Las respuestas a estas preguntas son importantes debido a que ayudan a determinar, no solo las herramientas que tendremos que utilizar, sino tambin la forma en que vamos a hacerlo. Para aprender ms acerca del establecimiento de metodologas, visite los siguientes sitios web: http://www.isecom.org/osstmm/ El manual de metodologa de prueba de seguridad de cdigo abierto (OSSTMM, por las iniciales en ingls de The Open Source Security Testing Methodology Manual) http://www.owasp.org/ El proyecto de seguridad de aplicaciones de red abierta (OWASP, por las iniciales en ingls de The Open Web Application Security Project)

1.3.3. Herramientas de evaluacin


Una evaluacin puede iniciarse utilizando algn tipo de herramienta que permita reunir informacin. Cuando se acceda a la totalidad de la red, primero haga un mapeo del diagrama para encontrar los equipos que se encuentren en ejecucin. Una vez localizados, examine a cada uno de ellos de manera individual. Para concentrarse en estos equipos se necesita otro conjunto de herramientas. Conocer qu herramientas utilizar puede ser la etapa ms importante del proceso para poder encontrar debilidades. Al igual que con cualquier aspecto de nuestra vida cotidiana, existen numerosas herramientas diferentes que son capaces de realizar el mismo trabajo. Este concepto tambin se aplica a la realizacin de evaluaciones de debilidades. Existen herramientas especficas para los sistemas operativos, para las aplicaciones, incluso para las redes (de acuerdo a los protocolos utilizados). Algunas herramientas son gratuitas, otras no. Algunas herramientas son intuitivas y sencillas de utilizar, mientras que otras son crpticas y poco documentadas, pero que tienen capacidades que otras no poseen. Encontrar las herramientas apropiadas puede ser una tarea intimidante, y la experiencia es un elemento importante para poder hacerlo. Si es posible, establezca un laboratorio de pruebas y utilice la mayor cantidad de herramientas que pueda, anotando las debilidades y fortalezas de cada una de ellas. Adicionalmente, busque mayor informacin en Internet mayor informacin, como ser por ejemplo artculos, guas de tipo paso-a-paso, o incluso listas de correo de una herramienta especfica. 12

Herramientas de evaluacin Las herramientas detalladas a continuacin son slo un pequeo ejemplo de las que se encuentran disponibles.

1.3.3.1. Analizando equipos con Nmap


Nmap es una herramienta muy conocida incluida en Fedora que puede ser utilizada para determinar el diagrama de una red. Nmap ha estado disponible desde hace muchos aos, y probablemente sea la herramienta ms utilizada para reunir informacin de red. Incluye una pgina man excelente con informacin detallada de sus usos y opciones. Los administradores pueden utilizar Nmap sobre una red para encontrar sistemas de equipos y puertos abiertos en esos sistemas. Nmap es un primer paso muy efectivo en la realizacin de evaluaciones de debilidades. Puede mapear todos los equipos dentro de su red, e incluso indicar una opcin que permite a Nmap intentar identificar el sistema operativo ejecutndose en un equipo determinado. Nmap es un buen fundamento sobre el que establecer una poltica de utilizacin de servicios seguros, y detener servicios no seguros.

1.3.3.1.1. Usando Nmap


Nmap puede ejecutarse desde una terminal ingresando el comando nmap, seguido por el nombre del equipo o direccin IP de la mquina a analizar.
nmap foo.example.com

Los resultados de un anlisis bsico (que puede demorarse unos minutos, de acuerdo al lugar en donde se encuentre el equipo), deberan ser similares a los siguientes:

Starting Nmap 4.68 ( http://nmap.org ) Interesting ports on foo.example.com: Not shown: 1710 filtered ports PORT STATE SERVICE 22/tcp open ssh 53/tcp open domain 70/tcp closed gopher 80/tcp open http 113/tcp closed auth

Nmap verifica los puertos de comunicaciones de red ms comunes, en busca de servicios que se encuentren escuchando o esperando. Este conocimiento puede servirle a un administrador que quiere cerrar servicios innecesarios o que no sean utilizados. Para obtener mayor informacin acerca de la utilizacin de Nmap, visite la pgina oficial en la siguiente URL: http://www.insecure.org/

1.3.3.2. Nessus
Nessus es un examinador de seguridad para cualquier tipo de servicios. La arquitectura de tipo complementos de Nessus permite a los usuarios personalizarlo de acuerdo a los requerimientos de sus sistemas o redes. Como cualquier otro examinador, la eficiencia de Nessus es directamente proporcional a la base de datos de la que depende. Afortunadamente, Nessus es actualizado peridicamente y entre sus recursos se encuentran el de ofrecer informes completos, anlisis de equipos, y bsqueda de debilidades en tiempo real. Recuerde que siempre pueden existir resultados falsos, an en herramientas tan poderosas y tan frecuentemente actualizadas como Nessus. 13

Captulo 1. Resumen acerca de la seguridad

Nota
Tanto el servidor como el cliente Nessus se encuentran disposnibles en los repositorios de Fedora, pero para poder utilizarlos es necesario suscribirse. Se ha incluido en este documento como una referencia para aquellos usuarios que podran estar interesados en utilizar esta conocida herramienta. Para obtener mayor informacin acerca de Nessus, visite el sitio web oficial en la siguiente URL: http://www.nessus.org/

1.3.3.3. Nikto
Nikto es un excelente examinador de programas de interfaz comn de puerta de enlace (CGI, por las iniciales en ingls de Common Gateway Interface). Nikto no slo verifica debilidades CGI, sino que lo hace de una forma evasiva, de modo de poder evitar sistemas de deteccin de intrusiones. Se ofrece con informacin detallada que debera ser cuidadosamente leda antes de ejecutar el programa. Si usted posee servidores Web ofreciendo programas CGI, Nikto puede ser una herramienta excelente para verificar la seguridad de estos servidores. Ms informacin sobre Nikto se puede encontrar en la siguiente URL: http://www.cirt.net/code/nikto.shtml

1.3.3.4. VLAD el escner


VLAD es un examinador de debilidades desarrollado por el equipo RAZOR de Bindview, Inc., que verifica en la lista SANS de los diez problemas de seguridad ms comunes (problemas SNMP, problemas por compartir archivos, etc.). Si bien no es tan completo como Nessus, vale la pena investigar VLAD.

Nota
VLAD no se incluye con Fedora y no est soportado. Se ha incluido en este documento como una referencia para aquellos usuarios que podran estar interesados en utilizar esta conocida aplicacin. Ms informacin sobre VLAD se puede encontrar el sitio web del equipo RAZOR en la siguiente URL: http://www.bindview.com/Support/Razor/Utilities/

1.3.3.5. Anticipando sus necesidades futuras


Depending upon your target and resources, there are many tools available. There are tools for wireless networks, Novell networks, Windows systems, Linux systems, and more. Another essential part of performing assessments may include reviewing physical security, personnel screening, or voice/PBX network assessment. New concepts, such as war walking, which involves scanning the perimeter of your enterprise's physical structures for wireless network vulnerabilities, are some

14

Ataques y debilidades comunes emerging concepts that you can investigate and, if needed, incorporate into your assessments. Imagination and exposure are the only limits of planning and conducting vulnerability assessments.

1.4. Ataques y debilidades comunes


Tabla 1.1, Debilidades comunes describe algunas de las debilidades y los puntos de ingreso ms utilizados por intrusos, que pretenden acceder a los recursos de organizacin de diferentes redes. La clave para defender estos puntos son las explicaciones acerca de cmo se desarrollan, y cmo los administradores pueden salvaguardar adecuadamente sus redes contra tales ataques. Tabla 1.1. Debilidades comunes Debilidades Contraseas nulas o predeterminadas Descripcin Dejando las contraseas administrativas en blanco, o utilizando la contrasea predeterminada puesta por el vendedor. Esto es lo ms comn en hardware como ruteadores y cortafuegos, por lo que algunos servicios que corren en Linux pueden contener contraseas administrativas predeterminadas (aunque Fedora 12 no viene con ellas). Notas Asociados comnmente a equipos de red como ruteadores, cortafuegos, VPNs y aparatos de almacenamiento conectados a la red (NAS). Comn en muchos sistemas operativos viejos, especialmente los SOs que agrupan servicios (como UNIX y Windows.) Los administradores, a veces crean apresuradamente cuentas de usuarios privilegiados, y dejan la contrasea en blanco, creando un punto de entrada perfecto para usuarios malintencionados han descubierto la cuenta. Los puntos de acceso inalmbricos y aparatos servidores seguros preconfigurados ms comunes.

Claves compartidas predeterminadas

Los servicios de seguridad algunas veces empaquetan claves de seguridad establecidas por defecto, ya sea para su desarrollo, o para comprobar su desempeo. Si estas claves se mantienen inalteradas y se colocan en un entorno de produccin en Internet todos los usuarios con las misma sclaves establecidas por defecto tendrn acceso a ese recurso de clave compartida, y a cualquier tipo de informacin que en l se guarde. Una mquina remota acta como un nodo en su red local, busca debilidades en sus servidores, e instala un programa de puerta trasera o troyano para ganar el control de los recursos de la red.

Imitacin de IP

La suplantacin de identidad es tan difcil porque involucra la necesidad del atacante de tener que predecir los nmeros de secuencia de TCP/IP para coordinar una conexin a los sistemas remotos, pero hay varias herramientas disponibles para asistir a los atacantes a realizar esa tarea. Depende del tipo de servicios que se estn ejecutando en el sistema de destino (como por ejemplo rsh, telnet, FTP y dems), si es que utilizan tcnicas de autenticacin basadas en la fuente, no son 15

Captulo 1. Resumen acerca de la seguridad Debilidades Descripcin Notas recomendadas si se las compara con PKI, o con otras formas de autenticar encriptaciones utilizadas en ssh, o SSL/TLS. Escuchas La escucha se realiza para la recoleccin de datos que pasan entre dos nodos activos en una red. Este tipo de ataque funciona principalmente con protocolos de transmisin de texto plano tales como las transferencias Telnet, FTP y HTTP. El atacante remoto debe tener acceso a un sistema comprometido en una LAN para poder realizar el ataque; usualmente el atacante us un ataque activo (tal como la suplantacin de IP o la del hombre en el medio) para comprometer un sistema en la LAN. Las medidas preventivas incluyen servicios con cambio de claves criptogrficas, contraseas de un solo uso, o autenticacin encriptada para prevenir la adivinacin de contraseas; una fuerte encriptacin durante la transmisin tambin es recomendada. HTTP-based services such as CGI are vulnerable to remote command execution and even interactive shell access. Even if the HTTP service runs as a non-privileged user such as "nobody", information such as configuration files and network maps can be read, or the attacker can start a denial of service attack which drains system resources or renders it unavailable to other users. Services sometimes can have vulnerabilities that go unnoticed during development and testing; these vulnerabilities (such as buffer overflows, where attackers crash a service using arbitrary values that fill the memory buffer of an application, giving the attacker an interactive command prompt from which they may execute arbitrary commands) can give complete administrative control to an attacker. Los administradores se deben asegurar que los servicios no corren como el usuario root, y deben vigilar los parches y actualizaciones de errata de las aplicaciones de vendedores u

Debilidades de servicios

Un atacante encuentra una brecha o hueco en un servicio que corre a travs de Internet; a travs de esta vulnerabilidad, el atacante compromete el sistema entero y cualquier dato que pueda contener, y puede posiblemente comprometer otros sistemas en la red.

16

Ataques y debilidades comunes Debilidades Descripcin Notas organizaciones de seguridad como CERT y CVE. Debilidades de aplicaciones Los atacantes encuentran fallas en las aplicaciones de un equipo de escritorio o de una estacin de trabajo (como ser por ejemplo un cliente de correo electrnico), y ejecutan un cdigo cualquiera, colocan caballos troyanos para futuros daos, o simplemente destruyen el sistema. Pueden ocurrir futuras catstrofes si la estacin de trabajo vulnerada posee privilegios administrativos sobre el resto de la red. Las estaciones de trabajo y los equipos personales son ideales para ser vulnerados dado que sus usuarios no tienen ni la experiencia ni el conocimiento para prevenir o detectar irregularidades. Es de suma importancia informar a los individuos del riesgo que corren cada vez que instalan software no autorizado, o cuando abren archivos adjuntos de correos electrnicos no solicitados. Pueden ser implementados "salvavidas" tales como configurar al cliente de correo electrnico que se est utilizando de modo tal que no abra ni ejecute archivos adjuntos en forma automtica. Adems, la actualizacin automtica de la estacin de trabajo a travs de la red de Red Hat, o mediante algn otro servicio de administracin de sistemas, es una forma de aliviar la tarea de las descargas de seguridad de tipo multi usuario. El caso DoS ms informado en los Estados Unidos ocurri en el ao 2000. Diferentes sitios comerciales y gubernamentales con alta densidad de trfico quedaron incapacitados por un ataque coordinado de flujo de ping, utilizando diversos sistemas con conexiones de banda ancha previamente vulnerados, que actuaban como zombies, o que redireccionaban nodos de transmisin. Los paquetes fuentes son usualmente moldeados (as como reenviados), investigando sobre la verdadera fuente del ataque. Los avances en el filtrado de la entrada (IETF rfc2267) con iptables y con sistemas deteccin de intrusos como snort ayudan a los administradores a rastrear y prevenir ataques de DoS distribuido.

Ataques de Negacin de Servicio (DoS)

Attacker or group of attackers coordinate against an organization's network or server resources by sending unauthorized packets to the target host (either server, router, or workstation). This forces the resource to become unavailable to legitimate users.

17

Captulo 1. Resumen acerca de la seguridad

1.5. Actualizaciones de seguridad


A medida que las deficiencias en la seguridad se van descubriendo, el software involucrado debe ser actualizado, y limitar as cualquier tipo de potencial riesgo. Si el software es parte de un paquete contenido en la distribucin Fedora entonces soportada, Fedora est comprometida a liberar lo antes posible las actualizaciones necesarias para solucionar las deficiencias del paquete en cuestin. A menudo, los anuncios sobre alguna imperfeccin en algn aspecto de la seguridad son acompaados de un parche (o cdigo fuente que solucione el problema). Este parche es entonces aplicado al paquete de Fedora, probado y liberado como una actualizacin considerada de tipo errata. Sin embargo, si algn anuncio no incluye un parche, el desarrollador trabaja primero con el encargado del software para poder solucionar el problema. Una vez que el problema haya sido resuelto, el paquete es probado y liberado como una actualizacin de tipo errata. Si se lanza una errata de actualizacin del software de su sistema, es altamente recomendado actualizar los paquetes involucrados tan pronto como sea posible para minimizar la cantidad de tiempo en que el sistema es potencialmente vulnerable.

1.5.1. Actualizacin de paquetes


Cuando se actualiza el software de un sistema, es importante descargar la actualizacin desde una fuente confiable. Un atacante fcilmente puede recompilar un paquete con el mismo nmero de versin que el que supuestamente debera solucionar el problema, pero con una nueva falla, y liberarlo en Internet. Si esto sucede, utilizar medidas de seguridad como archivos verificadores contra el RPM original, tampoco va a detectar la nueva falla. Sin embargo, es muy importante descargar RPMs solo desde fuentes confiables, como por ejemplo desde Fedora, y verificar la firma del paquete para confirmar su integridad.

Nota
Fedora incluye un cono en panel que muestra una alerta cada vez que exista una actualizacin disponible para el sistema.

1.5.2. Verificacin de paquetes firmados


Todos los paquetes de Fedora estn firmados con la clave GPG de Fedora. GPG viene de GNU Privacy Guard (guardia de la privacidad de GNU), o GnuPG, un paquete de software libre que se usa para asegurar la autenticidad de archivos a distribuir. Por ejemplo, una clave privada (clave secreta) bloquea el paquete mientras que la clave pblica desbloquea y verifica el paquete. Si la clave pblica distribuida por Fedora no coincide con la clave privada durante la verificacin del RPM, el paquete puede haber sido alterado y por lo tanto no es confiable. La utilidad RPM de Fedora intenta verificar automticamente la firma GPG de un paquete RPM antes de instalarlo. Si la clave GPG no est instalada, se debe instalar desde una ubicacin esttica y segura, como el CD-ROM o DVD de instalacin de Fedora. Asumiendo que el disco est montado en /mnt/cdrom, use el siguiente comando para importarla dentro del administrador de claves (keyring, una base de datos de claves confiables en el sistema):
rpm --import /mnt/cdrom/RPM-GPG-KEY

Para mostrar una lista de todas las claves instaladas para la verificacin de RPM, ejecute el siguiente comando:

18

Instalacin de paquetes firmados

rpm -qa gpg-pubkey*

La salida ser similar a la siguiente:


gpg-pubkey-db42a60e-37ea5438

Para mostrar los detalles de alguna clave en particular, use el comando rpm -qi seguido de la salida del comando previo, como en este ejemplo:
rpm -qi gpg-pubkey-db42a60e-37ea5438

Es extremadamente importante verificar la firma de los archivos RPM antes de instalarlos para asegurar que no hayan sido alterados desde la fuente original de los paquetes. Para verificar todos los paquetes descargados de una vez, emita el siguiente comando:
rpm -K /tmp/updates/*.rpm

Para cada paquete, s la llave GPG es verificada en forma exitosa, el comando retorna gpg OK. Si no lo hace, asegrese de que est utilizando la llave pblica de Fedora correcta, as como verificar la fuente del contenido. Los paquetes que no pasan las verificaciones GPG no deben ser instalados, ya que pueden haber sido alterados por un tercero. Despus de verificar la clave GPG y de descargar todos los paquetes asociados con el informe de errata, instale los paquetes como root en el indicador de la terminal.

1.5.3. Instalacin de paquetes firmados


La instalacin de la mayora de los paquetes se puede hacer en forma segura (excepto para los paquetes del kernel) emitiendo el siguiente comando:
rpm -Uvh /tmp/updates/*.rpm

Para paquetes del kernel, use el siguiente comando:


rpm -ivh /tmp/updates/<kernel-package>

Reemplace <kernel-package> en el ejemplo previo con el nombre del RPM del kernel. Una vez que la mquina ha sido iniciada sin problema usando el nuevo kernel, el kernel viejo se puede eliminar usando el siguiente comando:
rpm -e <old-kernel-package>

Reemplace <old-kernel-package> en el ejemplo previo con el nombre del RPM del kernel antiguo.

Nota
No es necesario que el ltimo kernel sea eliminado. El cargador de arranque por defecto, GRUB, permite tener varios kernels instalados, luego elija uno desde el men de arranque al iniciar.

19

Captulo 1. Resumen acerca de la seguridad

Importante
Antes de instalar cualquier errata de seguridad, asegrese de leer las instrucciones especiales contenidas en el informe de errata, y ejectelas apropiadamente. Visite Seccin 1.5.4, Aplicacin de los cambios para obtener instrucciones generales sobre la aplicacin de las modificaciones realizadas por una actualizacin de errata.

1.5.4. Aplicacin de los cambios


Despus de descargar e instalar las erratas de seguridad y actualizaciones, es importante dejar de usar el software viejo y comenzar a usar el nuevo. Cmo se hace esto depende del tipo de software que se haya actualizado. La siguiente lista muestran los items de la categora general de software y provee instrucciones para usar las versiones actualizadas despus de cada actualizacin de paquetes.

Nota
En general, reiniciar el sistema es la mejor forma de asegurarse que la ltima versin de un paquete de software est en uso; sin embargo, esta opcin no es siempre necesaria, o est disponible slo para el administrador del sistema. Aplicaciones Las aplicaciones del espacio del usuario son todos los programas que se pueden usar por el usuario comn. Tpicamente, tales aplicaciones se usan solamente cuando un usuario, programa o tarea automatizada los inicia, y no estn activas por perodos largos de tiempo. Una vez que la aplicacin del espacio del usuario es actualizado, detenga cualquier instancia de la aplicacin en el sistema y lance el programa de nuevo para usar la versin actualizada. Kernel El kernel es el componente de software principal del sistema operativo Fedora. Maneja el acceso a la memoria, al procesador y a los perifricos, as como la planificacin de todas las tareas. Dado a su rol central, el kernel no se puede reiniciar sin detener la computadora. Por lo tanto, una versin actualizada del kernel no se puede usar hasta que la computadora no sea reiniciada. Bibliotecas compartidas Las bibliotecas compartidas son unidades de cdigos, como glibc, que se usan por un nmero de aplicaciones y servicios. Las aplicaciones que usan una biblioteca compartida normalmente cargan el cdigo compartido cuando la aplicacin se inicia, por lo que todas las aplicaciones que usen la versin actualizada de la biblioteca se deben detener y reiniciar. Para determinar qu aplicaciones en ejecucin usan una biblioteca particular, use el comando lsof como en el siguiente ejemplo:
lsof /lib/libwrap.so*

20

Aplicacin de los cambios Este comando devuelve una lista con todos los programas en ejecucin que utilizan encapsuladores TCP para control de acceso del equipo. Por lo tanto, cualquier programa listado debe ser detenido y reiniciado si el paquete tcp_wrappers es actualizado. Servicios SysV Los servicios SysV son programas de servidor persistentes lanzados en algn momento del proceso de inicializacin del equipo. Algunos ejemplos de servicios SysV son sshd, vsftpd, y xinetd. Debido a que estos programas generalmente continan en la memoria todo el tiempo en que el sistema se est ejecutando, cada servicio SysV actualizado debe ser detenido luego que el paquete haya sido renovado. Esto puede hacerse utilizando la Herramienta de configuracin de servicios, o logueandose como usuario root en una consola y ejecutando el comando /sbin/ service como en el ejemplo siguiente:
/sbin/service <service-name> restart

En el ejemplo anterior, reemplace <service-name> con el nombre del servicio, como sshd. Servicios xinetd Los servicios controlados por el sper servicio xinetd solo se ejecutan cuando exista una conexin activa. Ejemplos de servicios controlados por xinetd osn Telnet, IMAP, y POP3. Debido a que xinetd inicia nuevas instancias de estos servicios cada vez que se reciba un nuevo pedido, las conexiones que tengan lugar luego de una actualizacin sern administradas por el software actualizado. Sin embargo, si existen conexiones activas en el momento en que el servicio controlado por xinetd es actualizado, estas conexiones seguirn funcionando controladas por la versin anterior. Para detener instancias antiguas de un servicio particular controlado por xinetd, actualice el paquete para el servicio, y luego detenga todos los procesos que se encuentren en ejecucin. Para determinar si el proceso est ejecutndose, utilice el comando ps y luego los comandos kill o killall para detener las instancias actuales del servicio. Por ejemplo, si los paquetes errata de seguridad imap son liberados, actualice los paquetes, y luego, como usuario root, ingrese el siguiente comando en una terminal:
ps -aux | grep imap

Este comando devuelve todas las sesiones IMAP activas. Las sesiones individuales pueden determinarse con el siguiente comando:
kill <PID>

Si esto falla a terminar la sesin, use el siguiente comando en su lugar:


kill -9 <PID>

En el ejemplo anterior, reemplace <PID> con el nmero de identificacin de proceso (se encuentra en la segunda columna del comando ps) para una sesin IMAP. Para detener todas las sesiones IMAP activas, ingrese el siguiente comando:
killall imapd

21

22

Gua Bsica para reforzar la seguridad.


The US National Security Agency (NSA) has developed two guides for hardening a default installation of Red Hat Enterprise Linux 5. Many of the tips provided in these guides are also valid for installations of Fedora. This Basic Hardening Guide will cover portions of the NSA's Hardening Tips and will explain why implementing these tips are important. This document does not represent the full NSA Hardening Guide. Como cualquier cambio en un sistema el mismo puede causar resultados inesperados. Los cambios deben ser evaluados apropiadamente antes de ser implementados en sus sistemas.
1

2.1. Principios Generales


Encrypt all data transmitted over the network. Encrypting authentication information (such as passwords) is particularly important. Minimize the amount of software installed and running in order to minimize vulnerability. Use security-enhancing software and tools whenever available (e.g. SELinux and IPTables). Run each network service on a separate server whenever possible. This minimizes the risk that a compromise of one service could lead to a compromise of others. Maintain user accounts. Create a good password policy and enforce its use. Delete unused user accounts. Review system and application logs on a routine basis. Send logs to a dedicated log server. This prevents intruders from easily avoiding detection by modifying the local logs. Never log in directly as root, unless absolutely necessary. Administrators should use sudo to execute commands as root when required. The accounts capable of using sudo are specified in /etc/ sudoers, which is edited with the visudo utility. By default, relevant logs are written to /var/log/ secure.

2.2. Porque esto es importante?


The general principles from the NSA represent a best practices overview of security. There are items in the above list that probably won't be used by everyone and there are items missing that should be stressed as a best practice. Additional information on these ideas and others will be explained below.

2.3. Seguridad Fsica


Physical security of the system is of utmost importance. Many of the suggestions given here won't protect your system if the attacker has physical access to the system.

Importante
This section contains information regarding GRUB Legacy and not the current release of GRUB (also known as GRUB2). Fedora 16 does not use GRUB Legacy so many of the commands below will not function in Fedora 16 or later versions. Configure the BIOS to disable booting from CDs/DVDs, floppies, and external devices, and set a password to protect these settings. Next, set a password for the GRUB bootloader. Generate a

http://www.nsa.gov

23

Captulo 2. Gua Bsica para reforzar la seguridad. password hash using the command /sbin/grub-md5-crypt. Add the hash to the first line of /etc/ grub.conf using password --md5 'passwordhash'. This prevents users from entering single user mode or changing settings at boot time.

2.4. Porque esto es importante?


Un atacante puede tomar control absoluto de su sistema al arrancar de una fuente externa. Al arrancar de una fuente externa (Ejemplo un CD vivo de Linux) mucha de las configuraciones de seguridad puede ser anuladas. Si un atacante puede modificar la configuracin del GRUB pueden arrancar el sistema en modo simple lo que permite acceso administrativo al mismo.

2.5. Que mas podemos hacer?


Ever since Fedora 9, LUKS encryption has been natively supported to protect data stored in a LUKS encrypted partition. When you install Fedora 9, check the box to encrypt your file system when you setup your file system. By encrypting your root partition and your /home partition (or the single / partition if you accept the default file system) attackers using an external source or booting into single user mode. Of course you use a strong passphrase to protect your data.

2.6. Networking
The computer's network connection is the gateway to your system. Your files and processor time could be available to anyone who successfully connects to your system via this network connection if other safeguards have not been implemented. One of the primary ways to keep you in control of your system is to prevent the attackers from gaining access to your system in the first place.

2.6.1. iptables
iptables is the most widely used firewall software on Linux systems today. This program intercepts packets coming into your computer via the network connection and filters them according to rules you have specified. Additional information can be found in Seccin 3.9, IPTables.

2.6.2. IPv6
IPv6 is the latest Internet protocol which aims to solve the address quantity shortfall inherent to IPv4. And while there are no security risks directly associated with the new protocol there are a few things to understand before utilizing this new technology. Most system administrators are familiar with IPv4 and the work-arounds that were put in place to make IPv4 work. One of these work-arounds is network address translation, or NAT. NAT is traditionally used to keep the number of needed public IP addresses to a minimum when setting up a local area network. Systems on these networks do not all require public IP addresses and valuable address space can be saved by implementing this technology. There are some security features that were side effects to NAT; the biggest being that outside traffic cannot make it inside the network unless a port is forwarded across the router. Because IPv6 solves the addressing problem there is no longer a need to use NAT. Everything can have a public IP address and, by extension, everything is not publically routable across the Internet when physical and logical connections are made. Another thing to worry about is how security software deals with this new protocol. iptables does not know or understand IPv6 and so it ignores those packets altogether. That means if your network is utilizing IPv6 and you have not activated ip6tables then you have just left the door to your system open to the world. Using IPv6 is not dangerous as long as you know and understand the changes that your system's software went through to make it possible to use this new network protocol. 24

Keeping software up to date

2.7. Keeping software up to date


Software gets patched everyday. Some of these updates fix security problems that were identified by the developers. When these patches become available it is important that they are applied to your system as soon as possible. One of the easier ways to manage updates for your system is using yum. A special plugin is available to allow only security updates to be installed while ignoring bugfixes and enhancements. This plugin is explained better at Seccin 8.1, Complemento de Yum.

2.8. Services
Services in Linux are programs that run as daemons in the background. It is important to audit these programs regularly to determine if they need to be running. Many daemons open network ports in order to listen for calls. Having unnecessary ports open can harm the overall security of the system. An unknown security flaw in a piece of software can allow a hacker into a system for no good reason.

2.9. NTP
Network Time Protocol, or NTP, keeps the time on your systems accurate. Time is a very important piece of the security puzzle and should be maintained as precisely as possible. Time is used in log files, timestamps, and in encryption. If someone is able to control the time settings on one of your systems then they are able to make the recreation of a break-in that much more difficult.

25

26

Asegurando su Red
3.1. Seguridad de la estacin de trabajo
Asegurar un entorno Linux comienza con la estacin de trabajo. Ya sea bloqueando una mquina personal, o asegurando un sistema corporativo, cualquier poltica de seguridad empieza con la computadora individual. La seguridad de una red de computadoras es la misma que la de su nodo ms dbil.

3.1.1. Evaluacin de la seguridad de la estacin de trabajo


Cuando se evala la seguridad de una estacin de trabajo Fedora, considere los siguientes aspectos: Seguridad del BIOS y del gestor de arranque Puede un usuario no autorizado tener acceso a la mquina e iniciarla como usuario nico, o en modo de rescate, sin ninguna contrasea? Seguridad de la contrasea Qu tan seguras son las contraseas de usuario en la mquina? Controles administrativos Quin posee una cuenta en el sistema y cunto control administrativo posee? Servicios de red disponibles Qu servicios estn escuchando peticiones activas de la red? Deberan estar ejecutndose? Cortafuegos personals En caso de necesitarse alguno, qu tipo de cortafuegos son necesarios? Herramientas de seguridad en la comunicacin mejoradas Qu herramientas deberan utilizarse para comunicarse entre estaciones de trabajo, y cules deberan evitarse?

3.1.2. Seguridad en el BIOS y en el gestor de arranque


Una proteccin del BIOS (o de su equivalente) y del gestor de arranque mediante una contrasea, puede prevenir que el sistema sea iniciado mediante la utilizacin de medios removibles, o que se obtengan privilegios de usuario root, por cualquier usuario no autorizado que tenga acceso fsico al l. Las medidas de seguridad que debera adoptar para protegerse de este tipo de ataques depende tanto de la calidad de la informacin de la estacin de trabajo, como de la ubicacin de la mquina. For example, if a machine is used in a secure location where only trusted people have access and the computer contains no sensitive information, then it may not be critical to prevent such attacks. However, if an employee's laptop with private, unencrypted SSH keys for the corporate network is left unattended at a trade show, it could lead to a major security breach with ramifications for the entire company.

3.1.2.1. Contrasea BIOS


Las dos razones fundamentales para proteger con una contrasea el BIOS de una computadora son 1 : 1. Evitar modificaciones a la configuracin del BIOS Si un intruso tiene acceso al BIOS, puede configurarlo para iniciarse desde un diskette o CD-ROM. Esto hace que sea posible para l

Dado que el BIOS de cada sistema es diferente de acuerdo a su fabricante, algunos podran no tener soporte para proteccin mediante contrasea de algn tipo, mientras que otros podran solo soportar un tipo pero no otro.

27

Captulo 3. Asegurando su Red ingresar en modo rescate o en modo de nico usuario, lo que a su vez permite que inicie procesos a eleccin en el sistema, o que pueda copiar informacin importante. 2. Evitar el inicio del sistema Algunas BIOS permiten proteccin mediante contraseas del proceso de arranque. Cuando es activado, el atacante se ve obligado a ingresar una contrasea antes que el BIOS ejecute el gestor de arranque. Because the methods for setting a BIOS password vary between computer manufacturers, consult the computer's manual for specific instructions. Si no recuerda la contrasea del BIOS, puede ser reseteada o bien mediante jumpers en la placa madre, o bien desconectando la batera del CMOS. Por esta razn, es una buena costumbre bloquear el gabinete de la computadora siempre que sea posible. Sin embargo, consulte el manual de la computadora o de la placa madre antes de intentar desconectar la batera del CMOS.

3.1.2.1.1. Asegurando plataformas que no sean de tipo x86


Otras arquitecturas utilizan diferentes programas para realizar tareas de bajo nivel, apenas equivalentes a las que realiza el BIOS en sistemas x86. Por ejemplo, las computadoras Intel Itanium utilizan el shell Interfaz de firmware extensible (EFI, por las iniciales en ingls de Extensible Firmware Interface). For instructions on password protecting BIOS-like programs on other architectures, refer to the manufacturer's instructions.

3.1.2.2. Contraseas del gestor de arranque


Las principales razones por las que proteger un gestor de arranque de Linux son las siguientes: 1. Prevenir el ingreso en modo de nico usuario Si los atacantes pueden iniciar el sistema en modo de usuario nico, automticamente se registran como usuarios root sin que para ello se les solicite una contrasea de usuario root. 2. Prevenir el acceso a la consola del GRUB Si la mquina en cuestin utiliza el GRUB como su gestor de arranque, un atacante puede utilizar la interfaz del editor del GRUB para modificar sus configuraciones, o para reunir informacin utilizando el comando cat. 3. Prevenir el acceso a sistemas operativos no seguros Si el sistema en cuestin es de arranque dual, un atacante puede seleccionar uno de los sistemas en el momento del inicio (por ejemplo, DOS), que ignora controles de acceso y permisos de archivo. Fedora por defecto instala el gestor de arranque GRUB en la plataforma x86. Para una exposicin detallada del GRUB, consulte la Gua de Instalacin de Fedora.

3.1.2.2.1. Proteccin de GRUB con contrasea


Puede configurar el GRUB para prevenir los dos primeros problemas descritos en la Seccin 3.1.2.2, Contraseas del gestor de arranque, aadiendo una directiva de contrasea a su archivo de configuracin. Para hacerlo, primero elija una contrasea poderosa, abra una terminal, regstrese como usuario root, e ingrese el siguiente comando:
/sbin/grub-md5-crypt

Cuando se le solicite, ingrese la contrasea del GRUB y presione la tecla Intro. Con esto obtendr un hash MD5 de la contrasea. 28

Seguridad de contraseas A continuacin, edite el archivo de configuracin del GRUB /boot/grub/grub.conf. Abra el archivo y debajo de la lnea timeout en la seccin principal del documento, aada la siguiente:
password --md5 <password-hash>

Replace <password-hash> with the value returned by /sbin/grub-md5-crypt . La prxima vez que el sistema sea iniciado, el men del GRUB evitar que se ingrese al editor, o a la interfaz de comandos, sin haber presionado primero la tecla p, seguida de la contrasea del GRUB Desafortunadamente, esta solucin no previene que un atacante inicie el equipo con un sistema operativo no seguro, si es que existe un entorno de arranque dual. Para esto, debe ser editada una parte diferente del archivo /boot/grub/grub.conf. Ubique la lnea title del sistema operativo que desea asegurar, y aada otra lnea con la directiva lock inmediatamente debajo de ella. Para un sistema DOS, el bloque de lneas pertinente debera empezar de manera similar a la siguiente:
title DOS lock

Advertencia
Una lnea password debe estar presente en la seccin principal del archivo /boot/grub/ grub.conf para el correcto funcionamiento de este mtodo. De lo contrario, un atacante puede acceder a la interfaz del editor del GRUB y eliminar la lnea de bloqueo. Para crear una contrasea diferente para un kernel particular o sistema operativo, aada la lnea lock a las presentes seguida de una lnea de contrasea. Cada porcin de lneas protegidas con una contrasea nica deberan empezar de manera similar al siguiente ejemplo:
title DOS lock password --md5 <password-hash>

3.1.3. Seguridad de contraseas


Passwords are the primary method that Fedora uses to verify a user's identity. This is why password security is so important for protection of the user, the workstation, and the network. Por motivos de seguridad, el programa de instalacin configura el sistema para utilizar MessageDigest Algorithm (MD5) y ocultar las contraseas. Es muy recomendable que no modifique estas configuraciones. Si las contraseas MD5 son deseleccionadas durante la instalacin, el antiguo formato Data Encryption Standard (DES) es utilizado. Este formato limita las contrasea a ocho caracteres

GRUB also accepts unencrypted passwords, but it is recommended that an MD5 hash be used for added security.

29

Captulo 3. Asegurando su Red alfanumricos (deshabilitando los signos de puntuacin y otros caracteres especiales), y proveyendo un modesto nivel de encriptado de 56 bits. Si durante la instalacin se deselecciona el ocultamiento de contraseas, todas las contraseas son almacenadas en un hash unidireccional en el archivo de lectura pblica /etc/passwd, lo que hace que el sistema sea vulnerable a los ataques de descubrimiento de contraseas fuera de lnea. Si un intruso puede obtener acceso a la mquina como un usuario regular, puede copiar el archivo / etc/passwd a su propio equipo, y ejecutar cualquier cantidad de programas de descubrimiento de contraseas sobre l. Si existe una contrasea no segura en el archivo, es slo cuestin de tiempo antes que el atacante la encuentre. El ocultamiento de contraseas elimina este tipo de ataques almacenando el hash de contrasea en el archivo /etc/shadow, que solo puede ser ledo por el usuario root. Esto obliga a los potenciales atacantes a intentar descubrir las contraseas remotamente, registrndose en un servicio de red en la mquina, como por ejemplo SSH o FTP. Esta clase de ataque de tipo fuerza bruta es mucho ms lento y deja un rastro obvio, consistente en los cientos de intentos fallidos de registro almacenados en los archivos del sistema. Por supuesto, si el atacante inicia un ataque en medio de la noche en un sistema con contraseas dbiles, podra obtener acceso antes del amanecer y editar los archivos de registro para eliminar sus huellas. Adems del las cuestiones acerca del formato y del almacenamiento, est el problema de los contenidos. La nica cosa realmente importante que un usuario puede hacer para proteger su cuenta de ataques para descubrir su contrasea, es crear una contrasea poderosa.

3.1.3.1. Creando contraseas poderosas


Para crear una contrasea segura, es una buena idea seguir las siguientes indicaciones: No utilice solo palabras o nmeros Nunca utilice solo nmeros o palabras en contraseas. Algunos ejemplos inseguros incluyen los siguientes: 8675309 juan hackeame No use palabras reconocibles Palabras como nombres propios, palabras de diccionario, o incluso trminos de shows de televisin, o de novelas, deberan ser evitados. An si estn complementadas con nmeros. Algunos ejemplos inseguros incluyen los siguientes: martin1 DS-9 tevez123 No utilice palabras de otros idiomas Los programas de descubrimiento de contraseas a menudo verifican sobre listas de palabras que incluyen diccionarios de muchos idiomas. Confiar en idiomas extranjeros para establecer contraseas seguras, no es algo aconsejable. Algunos ejemplos inseguros incluyen los siguientes: cheguevara 30

Seguridad de contraseas bienvenido1 1dumbKopf No utilice terminologa hacker Si usted piensa que es intocable porque utiliza terminologa hacker tambin denominada lengua l337 (LEET) en su contrasea, pinselo dos veces, Muchas listas de palabras incluyen lengua LEET. Algunos ejemplos inseguros incluyen los siguientes: H4X0R 1337 No use Informacin Personal Evite usar cualquier tipo de informacin personal en sus contraseas. Si el atacante conoce su identidad, la tarea de deducir su contrasea se vuelve ms fcil. La siguiente es una lista de los tipos de informacin a evitar cuando se crea una contrasea: Algunos ejemplos inseguros incluyen los siguientes: Su nombre El nombre de su mascota El nombre de un miembro de la familia Cualquier fecha de cumpleaos Su nmero de telfono o su cdigo postal No invierta palabras reconocibles Los buenos verificadores de contrasea siempre invierten palabras comunes, por lo que la inversin de un mala contrasea no la hace ms segura. Algunos ejemplos inseguros incluyen los siguientes: R0X4H nauj 9-DS No escriba su contrasea Nunca guarde su contrasea en papel. Es ms seguro memorizarla. No use la misma contrasea para todas las computadoras es importante crear contraseas distintas para cada mquina. De esta forma, si un sistema est comprometido, todas sus computadoras no estarn inmediatamente en riesgo. Los siguientes consejos le ayudarn a crear una contrasea fuerte: La contrasea debe tener al menos 8 caracteres de largo Cuanto ms larga la contrasea, mejor. Si usa contraseas MD5, deben ser de 15 caracteres o ms. Con contraseas DES, use la longitud mxima (ocho caracteres). Mezcle letras en maysculas y minsculas Fedora diferencia entre maysculas y minsculas, por lo que su mezcla mejora la fortaleza de la contrasea. Mezcle letras con nmeros Agregar nmeros a la contrasea mejora la fortaleza de la misma, especialmente cuando se los agrega en el medio (no al principio ni al final). 31

Captulo 3. Asegurando su Red Include Non-Alphanumeric Characters Special characters such as &, $, and > can greatly improve the strength of a password (this is not possible if using DES passwords). Elija una contrasea que pueda recordar La mejor contrasea del mundo no mejora nada si no la puede recordar; use siglas u otros dispositivos memotcnicos para ayudarle a recordar las contraseas. Con todas estas reglas, puede parecer difcil crear una contrasea que cumpla al mismo tiempo con todos los criterios pedidos para una buena contrasea, y que evite la creacin de una mala. Afortunadamente, hay algunos pasos que se pueden tomar para generar una contrasea segura y fcil de recordar.

3.1.3.1.1. Metodologa para la creacin de una contrasea segura


Hay muchos mtodos que se pueden usar para crear contraseas seguras. Uno de los ms populares involucra las siglas. Por ejemplo: Piense en una frase fcil de recordar, tal como: "over the river and through the woods, to grandmother's house we go." Luego, convirtala en una sigla (incluyendo la puntuacin). otrattw,tghwg. Agregue complejidad sustituyendo nmeros y smbolos por letras en la sigla. Por ejemplo, sustituya 7 por t el arroba (@) por a: o7r@77w,7ghwg. Agregue ms complejidad poniendo en maysculas al menos una letra, tal como la B. o7r@77w,7gHwg. Finalmente, no use nunca la contrasea ejemplo anterior para ningn sistema. La creacin de contraseas seguras es imperativo, y su apropiada administracin es igual de importante, especialmente para administradores de sistemas dentro de organizaciones grandes. La siguiente seccin detalla las buenas prcticas para crear y administrar las contraseas de los usuarios dentro de una organizacin.

3.1.3.2. Creacin de contraseas de usuarios dentro de una organizacin


Si una organizacin tiene un gran nmero de usuarios, los administradores de sistema tienen dos opciones bsicas disponibles para obligar al uso de contraseas buenas. Pueden crear contraseas para los usuarios, o permitirles crear sus propias contraseas, pero verificando que sean de una calidad aceptable. La creacin de contraseas para usuarios asegura que las contraseas sean buenas, pero se vuelve una tarea intimidante a medida que la organizacin crece. Tambin aumenta el riesgo de que los usuarios escriban sus contraseas. Por estas razones, la mayora de los administradores de sistema prefieren que sus usuarios creen sus propias contraseas, pero verificar activamente que sean buenas y, en algunos casos, forzarlos a cambiarlas peridicamente mediante el establecimiento de un perodo determinado de validez.

32

Seguridad de contraseas

3.1.3.2.1. Obligando a usar contraseas poderosas


Para proteger la red de intrusos, es una buena idea que los administradores del sistema comprueben que las contraseas utilizadas dentro de una organizacin sean buenas y potentes. Cuando se les pida a los usuarios crear o modificar una contrasea, pueden utilizar la herramienta de lnea de comando passwd, que es compatible con el Administrador de mdulos de autenticacin conectables (PAM, por las iniciales en ingls de Pluggable Authentication Manager), y por lo tanto verifica si la contrasea es demasiado corta o demasaido fcil de descubrir. Esta comprobacin es realizada utilizando el mdulo PAM pam_cracklib.so. Ya que PAM es personalizable, es posible aadir ms verificadores de la integridad de las contraseas, como ser por ejemplo, pam_passwdqc (disponible en http://www.openwall.com/passwdqc/), o escribir un mdulo nuevo. Para conocer una lista de mdulos PAM disponibles, vea http://www.kernel.org/pub/linux/libs/pam/modules.html. Para obtener mayor informacin acerca de PAM, vaya a la Seccin 3.5, Mdulos de autenticacin conectables (PAM, por las iniciales en ingls de Pluggable Authentication Modules). La verificacin de la contrasea que se realiza al momento de su creacin, no permite saber con tanta certeza si una contrasea es dbil, cosa que s se puede verificar exactamente con la ejecucin sobre ellas de un programa de descubrimiento de contraseas. Muchos programas de descubrimiento de contraseas estn disponibles para ejecutarse en Fedora, aunque ninguno viene con el sistema operativo. A continuacin ofrecemos una pequea lista con algunos de los programas de descubrimiento de contraseas ms populares: John The Ripper Un programa de descubrimiento de contrasea rpido y flexible. Permite el uso de mltiples listas de palabras y puede descubrir contraseas por fuerza bruta. Est disponible en lnea en http://www.openwall.com/john/. Crack Tal vez el software de descubrimiento de contraseas ms conocido, Crack es tambin muy rpido, aunque no tan fcil de usar como John The Ripper. Se lo puede encontrar en lnea en http://www.crypticide.com/alecm/security/c50-faq.html. Slurpie Slurpie es similar a John The Ripper y a Crack, pero se dise para correr en varias computadoras a la vez, creando un ataque de descubrimiento de contraseas distribuido. Se puede encontrar junto con un nmero de otras herramientas de evaluacin de seguridad al ataque distribudo, en lnea en http://www.ussrback.com/distributed.htm.

Advertencia
Siempre obtenga una autorizacin por escrito antes de intentar descubrir contraseas dentro de una organizacin

3.1.3.2.2. Frases de acceso


Passphrases and passwords are the cornerstone to security in most of today's systems. Unfortunately, techniques such as biometrics and two-factor authentication have not yet become mainstream in many systems. If passwords are going to be used to secure a system, then the use of passphrases should be considered. Passphrases are longer than passwords and provide better protection than a password even when implemented with non-standard characters such as numbers and symbols.

3.1.3.2.3. Edad de las contraseas


El envejecimiento de las claves es otra tcnica usada por los administradores del sistema para defenderlo de malas contraseas dentro de una organizacin. El envejecimiento de la contrasea significa que despus de un perodo especificado (normalmente 90 das), el usuario debe crear

33

Captulo 3. Asegurando su Red una nueva contrasea. La idea detrs de este mtodo es que si el usuario es forzado a cambiar su contrasea peridicamente, una contrasea descubierta sera til para un intruso por un tiempo limitado. La contra del envejecimiento es que los usuarios, seguramente, anotarn en un papel sus contraseas. Hay dos programas principales usados para especificar el envejecimiento de contraseas bajo Fedora: el comando chage o la aplicacin grfica Administracin -> Usuarios y Grupos (systemconfig-users). The -M option of the chage command specifies the maximum number of days the password is valid. For example, to set a user's password to expire in 90 days, use the following command:
chage -M 90 <username>

In the above command, replace <username> with the name of the user. To disable password expiration, it is traditional to use a value of 99999 after the -M option (this equates to a little over 273 years). Tambin puede usar el comando chage en modo interactivo para modificar el envejecimiento de varias contraseas y detalles de cuenta. Use el siguiente comando para ingresar en modo interactivo:
chage <username>

El siguiente es un ejemplo de la sesin interactiva usando este comando:


[root@myServer ~]# chage davido Changing the aging information for davido Enter the new value, or press ENTER for the default Minimum Password Age [0]: 10 Maximum Password Age [99999]: 90 Last Password Change (YYYY-MM-DD) [2006-08-18]: Password Expiration Warning [7]: Password Inactive [-1]: Account Expiration Date (YYYY-MM-DD) [1969-12-31]: [root@myServer ~]#

Vaya a la pgina man de chage para ms informacin sobre las opciones disponibles. Tambin se puede usar la aplicacin Usuarios y Grupos para crear polticas de envejecimiento de contraseas, como sigue. Nota: necesita los privilegios de administrador para realizar este procedimiento. 1. Haga clic en el men Sistema en el panel, apunte al men Administracin y luego haga clic en Usuarios y Grupos para mostrar el Aministrador de Usuarios. Alternativamente, teclee el comando system-config-users en un indicador de shell. Haga clic en la pestaa Usuarios y seleccione el usuario requerido de la lista de usuarios. Haga clic en Propiedades en la barra de herramientas para mostrar el cuadro de dilogo de las Propiedades del Usuario (o elija Propiedades en el men Archivo). Haga clic en la pestaa Informacin de la Contrasea, y seleccione la casilla de Activar expiracin de contrasea. Ingrese el valor requerido en el campo Das requeridos antes de cambiar y haga clic en Aceptar.

2. 3. 4. 5. 34

Controles administrativos

Figura 3.1. Especificacin de las opciones de edad de las contraseas

3.1.4. Controles administrativos


When administering a home machine, the user must perform some tasks as the root user or by acquiring effective root privileges via a setuid program, such as sudo or su. A setuid program is one that operates with the user ID (UID) of the program's owner rather than the user operating the program. Such programs are denoted by an s in the owner section of a long format listing, as in the following example:
-rwsr-xr-x 1 root root 47324 May 1 08:09 /bin/su

Nota
La s puede figurar en mayscula o en minscula. Si aparece en mayscula, significa que el bit de los permisos subyacentes no ha sido definido. Sin embargo, para el administrador del sistema de una organizacin, las elecciones deben ser realizadas tomando en cuenta el tipo de acceso adminsitrativo que los usuarios dentro de la organizacin deberan tener a su mquina. A travs del mdulo PAM denominado pam_console.so, algunas actividades normalmente reservadas solo para el usuario root, como ser reiniciar o montar medios removibles, son permitidas para el primer usuario que se registre en la consola fsica (para obtener mayor informacin acerca del mdulo pam_console.so, vaya a la Seccin 3.5, Mdulos de autenticacin conectables (PAM, por las iniciales en ingls de Pluggable Authentication Modules). Sin embargo, otras tareas importantes en el sistema, como ser modificar parmetros de red, configurar un nuevo ratn, o montar dispositivos de red, no ser posible realizarlas sin privilegios administrativos.

35

Captulo 3. Asegurando su Red Como resultado, los administradores del sistema deben decidir cunto acceso deben otorgarle a los usuarios de la red.

3.1.4.1. Permitiendo accesos root


Si los usuarios de una organizacin son confiables y conocen acerca de computadoras, permitirles acceso root no debera ser un problema. Esto significa que actividades menores, como aadir dispositivos o configurar interfases de red podran ser realizadas por los usuarios individuales, quedando los administradores del sistema liberados y poder realizar tareas ms importantes relacionadas, por ejemplo, con la red o con la seguridad. Por otro lado, darle accesos de root a usuarios individuales podra generar los siguientes inconvenientes: Configuracin errnea del equipo Los usuarios con acceso root pueden desconfigurar sus mquinas y necesitar asistencia para resolver problemas. O peor an, podran abrir agujeros en la seguridad del sistema sin saberlo. Ejecutar servicios no seguros Usuarios con acceso root podran ejecutar servidores no seguros en su mquina, como por ejemplo Telnet o FTP, poniendo en riesgo en forma potencial nombres de usuarios o contraseas. Estos servicios transmiten la informacin sobre la red en formato de texto simple. Ejecutar archivos adjuntos de correos como usuarios root Si bien son excepcionales, existen virus de correo electrnico que afectan a los sistemas Linux. Sin embargo, el nico momento en que se convierten en una amenaza, es cuando son ejecutados por el usuario root.

3.1.4.2. Anulacin del acceso como root


Si un administrador no se encuentra cmodo al permitir que los usuarios se registren como usuarios root por estas razones, o por otras, la contrasea de usuario root debera ser mantenida en secreto, y el acceso al nivel de ejecucin 1, o al modo de usuario nico, debera ser desactivado mediante una proteccin del gestor de arranque a travs de una contrasea (para obtener mayor informacin en este aspecto, vea la Seccin 3.1.2.2, Contraseas del gestor de arranque). Tabla 3.1, Mtodos para deshabilitar la cuenta root describe las formas en que un administrador puede asegurarse que no sean permitidos los ingresos como root: Tabla 3.1. Mtodos para deshabilitar la cuenta root Mtodo Cambio del shell para root. Descripcin Edite el archivo /etc/ passwd y cambie la terminal de /bin/bash a /sbin/nologin. Efectos Previene acceso a la terminal root y registra cualquiera de tales intentos. Los siguientes programas estn prevenidos al intentar ingresar a la cuenta de usuario root: login gdm kdm xdm su ssh scp No afecta Programas que no necesiten de una terminal, como por ejemplo, clientes FTP, clientes de correo, y muchos programas de tipo setuid. Los siguientes programas no estn prevenidos al intentar acceder a la cuenta root: sudo Clientes de FTP Clientes de correo

36

Controles administrativos Mtodo Descripcin Efectos sftp Deshabilitar Un archivo /etc/ el acceso securetty vaco root previene los intentos de mediante accesos root a cualquier cualquier dispositivo asociado con la dispositivo computadora. de consola (tty) Previene accesos a la cuenta root mediante la consola o la red. Los siguientes programas son prevenidos al intentar acceder a la cuenta root: login gdm kdm xdm Otros servicios de red que abran una tty Programas que no se registran como root, pero que realizan tareas administrativas mediante programas de tipo setuid, o mediante otros mecanismos. Los siguientes programas no estn prevenidos al intentar acceder a la cuenta root: su sudo ssh scp sftp No afecta

Deshabilitacin Edite el archivo /etc/ de las ssh/sshd_config y opciones establezca el parmetro de PermitRootLogin en no. ingreso como root por SSH.

Prevenga el acceso root Esto slo previene el utilizando el conjunto de acceso root al conjunto de herramientas de OpenSSH. herramientas de OpenSSH. Los siguientes programas son prevenidos al intentar acceder a a cuenta root: ssh scp sftp Previene el acceso root a los servicios de red que son compatibles com PAM. Los siguientes servcicios son prevenidos al intentar acceder a la cuenta de root: Clientes de FTP Clientes de correo login gdm kdm xdm ssh scp sftp Cualquier servicio PAM Programas y servicios que no son compatibles con PAM.

Utilice PAM para limitar el acceso root a los servicios.

Edite el archivo para el servicio en cuestin en el directorio /etc/pam.d/. Asegrese que el archivo pam_listfile.so sea requerido para 1 autenticacin.

Para obtener ms detalles, dirjase a la Seccin 3.1.4.2.4, Deshabilitando root usando PAM.

3.1.4.2.1. Deshabilitando la cuenta shell de root


To prevent users from logging in directly as root, the system administrator can set the root account's shell to /sbin/nologin in the /etc/passwd file. This prevents access to the root account through commands that require a shell, such as the su and the ssh commands.

37

Captulo 3. Asegurando su Red

Importante
Los programas que no necesitan acceso a la consola, como son por ejemplo los clientes de correo electrnico, o el comando sudo, pueden todava tener acceso a la cuenta root.

3.1.4.2.2. Deshabilitando conexiones como root


To further limit access to the root account, administrators can disable root logins at the console by editing the /etc/securetty file. This file lists all devices the root user is allowed to log into. If the file does not exist at all, the root user can log in through any communication device on the system, whether via the console or a raw network interface. This is dangerous, because a user can log in to his machine as root via Telnet, which transmits the password in plain text over the network. By default, Fedora's /etc/securetty file only allows the root user to log in at the console physically attached to the machine. To prevent root from logging in, remove the contents of this file by typing the following command:
echo > /etc/securetty

Advertencia
Un archivo /etc/securetty vaco no evita que el usuario root se registre remotamente en el sistema utilizando el conjunto de herramientas OpenSSH, ya que la consola no se inicia hasta luego de la autenticacin.

3.1.4.2.3. Deshabilitando conexiones SSH como root


Root logins via the SSH protocol are disabled by default in Fedora; however, if this option has been enabled, it can be disabled again by editing the SSH daemon's configuration file (/etc/ssh/ sshd_config). Change the line that reads:
PermitRootLogin yes

leer como sigue:


PermitRootLogin no

Para que estos cambios tengan efecto, el demonio SSH debe ser reiniciado. Esto puede realizarse mediante el siguiente comando:
kill -HUP `cat /var/run/sshd.pid`

3.1.4.2.4. Deshabilitando root usando PAM


PAM, a travs del mdulo /lib/security/pam_listfile.so, permite gran flexibilidad a la hora de denegar cuentas especficas. El administrador puede utilizar este mdulo para hacer referencia a una lista de usuarios que no tienen permitido registrarse. Ms abajo mostramos un ejemplo acerca de cmo el mdulo es utilizado por el servidor FTP vsftpd en el archivo de configuracin de PAM

38

Controles administrativos /etc/pam.d/vsftpd (el caracter \ al final de la primera lnea en el ejemplo no es necesario si la directiva se encuentra en una sola lnea):
auth required /lib/security/pam_listfile.so item=user \ sense=deny file=/etc/vsftpd.ftpusers onerr=succeed

Esto le indica a PAM que consulte el archivo /etc/vsftpd.ftpusers y que niegue el acceso al servicio al usuario listado. El administrador puede modificar el nombre en este archivo, y puede tener diferentes listas para cada servicio, o utilizar una lista principal para negar el acceso a mltiples servicios. Si el administrador quiere negar el acceso a mltiples servicios, una lnea similar puede ser aadida a los archivos de configuracin PAM, como por ejemplo, /etc/pam.d/pop y /etc/pam.d/imap para clientes e correo, o /etc/pam.d/ssh para clientes SSH. Para obtener mayor informacin acerca de PAM, vea la Seccin 3.5, Mdulos de autenticacin conectables (PAM, por las iniciales en ingls de Pluggable Authentication Modules).

3.1.4.3. Limitando acceso como root


En lugar de negarle acceso completamente al usuario root, el admisnitrador podra querer permitirle el acceso slo mediante la utilizacin de programas de tipo setuid, como ser por ejemplo su o sudo.

3.1.4.3.1. El comando su
Cuando un usuario ejecuta el comando su, se le solicita la contrasea de root y, luego de la autenticacin, le es dado un indicador de consola. Una vez que se registra mediante el comando su, el usuario es el usuario root y tiene accesos 3 admisnitrativos absolutos en el sistema . Adems, una vez que el usuario se ha convertido en root, es posible la utilizacin del comando su para convertirse en cualquier otro usuario en el sistema sin que por eso se le pida ningn tipo de contrasea. Debido a la potencia de este programa, los administradores de una organizacin podran desear limitar a quines tienen acceso a este comando. Una de las maneras ms sencillas de hacer esto es aadiendo usuarios al grupo administrativo especial denominado wheel. Para hacerlo, ingrese el siguiente comando como usuario root:
usermod -G wheel <username>

In the previous command, replace <username> with the username you want to add to the wheel group. Tambin puede utilizar de la siguiente manera el Administrador de usuarios para modificar las pertenencias a los grupos. Nota: necesita privilegios de administrador para realizar este procedimiento: 1. Haga clic en el men Sistema en el panel, apunte al men Administracin y luego haga clic en Usuarios y Grupos para mostrar el Aministrador de Usuarios. Alternativamente, teclee el comando system-config-users en un indicador de shell. Haga clic en la pestaa Usuarios y seleccione el usuario requerido de la lista de usuarios.

2.

Estos accesos an estn sujetos a las restricciones impuestas por SELinux, si es que se encuentra activo.

39

Captulo 3. Asegurando su Red 3. 4. 5. Haga clic en Propiedades en la barra de herramientas para mostrar el cuadro de dilogo de las Propiedades del Usuario (o elija Propiedades en el men Archivo). Haga clic en la pestaa Grupos, seleccione la casilla para el grupo wheel, y luego haga clic en OK. Vea la Figura 3.2, Adding users to the "wheel" group.. Abra el archivo de configuracin PAM para el comando su (/etc/pam.d/su) en un editor de textos, y elimine el comentario # de la siguiente lnea:
auth required /lib/security/$ISA/pam_wheel.so use_uid

Este cambio significa que solo miembros del grupo administrativo wheel pueden usar este programa.

Figura 3.2. Adding users to the "wheel" group.

Nota
El usuario root es por defecto miembro del grupo wheel.

3.1.4.3.2. El comando sudo


El comando sudo ofrece un nuevo punto de vista a la cuestin acerca de si otorgarle o no accesos administrativos a los usuarios. Cuando un usuario confiable le anteponga el comando sudo a un comando administrativo, le ser pedida su propia contrasea. Entonces, cuando sea autenticado y asumiendo que el comando le sea permitido, el comando administrativo en cuestin ser ejecutado como si este usuario fuera el usuario root.

40

Servicios de red disponibles Los formatos bsicos del comando sudo son los siguientes:
sudo <command>

In the above example, <command> would be replaced by a command normally reserved for the root user, such as mount.

Importante
Los usuarios del comando sudo deberan tener mucho cuidado y cancelar esta herramienta antes de abandonar sus equipos, ya que en un perodo de tiempo de cinco minutos, los usuarios sudo pueden utilizar el comando nuevamente sin que por ello les sea pedida una contrasea. Esta configuracin puede modificarse desde el archivo de configuracin /etc/sudoers. The sudo command allows for a high degree of flexibility. For instance, only users listed in the /etc/ sudoers configuration file are allowed to use the sudo command and the command is executed in the user's shell, not a root shell. This means the root shell can be completely disabled, as shown in Seccin 3.1.4.2.1, Deshabilitando la cuenta shell de root. The sudo command also provides a comprehensive audit trail. Each successful authentication is logged to the file /var/log/messages and the command issued along with the issuer's user name is logged to the file /var/log/secure. Otra ventaja del comando sudo es que un administrador puede permitir a diferentes usuarios acceder a comandos especficos de acuerdo a sus necesidades. Los administradores que quieran editar /etc/sudoers, el archivo de configuracin del comando sudo, deberan utilizar el comando visudo. Para otrogarle a un usario todos los privilegios admisnitrativos, ingrese visudo, y agregue una lnea similar a la siguiente en la seccin de especificaciones de los privilegios del usuario:
juan ALL=(ALL) ALL

Este ejemplo indica que el usuario juan, puede utilizar el comando sudo desde cualquier equipo y ejecutar cualquier comando. El ejemplo que damos a continuacin ilustra pequeos detalles posibles al configurar sudo:
%users localhost=/sbin/shutdown -h now

Este ejemplo indica que cualquier usuario puede ejecutar el comando /sbin/shutdown -h now, siempre y cuando lo haga desde una consola. La pgina man del archivo sudoers contiene una lista detallada de opciones.

3.1.5. Servicios de red disponibles


Si bien el acceso de los usuarios a controles administrativos es un problema importante para los administradores del sistema dentro de una organizacin, controlar qu servicios de red son los que se encuentran activos, es de importancia suprema para cualquiera que opere un sistema Linux.

41

Captulo 3. Asegurando su Red Muchos servicios bajo Fedora se comportan como servidores de red. Si un servicio de red est ejecutndose en una mquina, una aplicacin de servidor (denominada demonio), est escuchando las conexiones de uno o ms puertos de red. Cada uno de estos servidores debera ser tratado como una potencial va de ingreso de atacantes.

3.1.5.1. Riesgos a servicios


Los servicios de red puede plantear numerosos riesgos para sistemas Linux. A continuacin mostramos una lista con algunas de las cuestiones principales: Ataques de denegacin de servicio (DoS, por las iniciales en ingls de Denial of Service Attacks ) Al inundar un servicio con peticiones, un ataque de denegacin de servicio puede dejar inutilizable a un sistema, ya que este trata de registrar y de responder a cada peticin. Ataque de denegacin de servicio distribuido (DDoS, por las iniciales en ingls de Distributed Denial of Service Attack) Un tipo de ataque DoS que utiliza varias mquinas comprometidas (que por lo general suelen ser varios miles) para dirigir un ataque coordinado sobre un servicio, inundndolo con peticiones y haciendo que sea inutilizable. Ataques a las debilidades de los programas Si un servidor est utilizando programas para ejecutar acciones propias, como comnmente lo hacen los servidores Web, un atacante puede concentrarse en los scripts mal escritos. Este ataque a las debilidades de los programas puede llevar a una condicin de desbordamiento del bfer, o permitir que los atacantes modifiquen archivos en el sistema. Ataques de desbordamiento del bfer Los servicios que se conectan al rango de puertos que va entre 0 y 1023, deben ser ejecutados como usuario administrativo. Si una aplicacin puede provocar un desbordamiento del bfer, un atacante puede obtener acceso al sistema como el usuario que ejecuta el demonio. Debido a que los desbordamientos del bfer existen, los atacantes utilizan herramientas automatizadas para identificar sistemas con debilidades, y una vez obtenido el acceso, usan rootkits automatizados para mantener ese acceso al sistema.

Nota
La amenaza que representa la debilidad de un bfer desbordado es mitigada en Fedora mediante la utilizacin de ExecShield, un programa de ejecucin de segmentacin de la memoria y proteccin de la tecnologa, con soporte para kernels de sistemas compatibles x86 de uno o ms procesadores. ExecShield reduce el riesgo de un desbordamiento del bfer al clasificar la memoria virtual en segmentos ejecutables y no ejecutables. Cualquier cdigo de programa que intente ejecutarse fuera de los segmentos ejecutables (como por ejemplo codigo maliciosos introducido desde un bfer desbordado que ha sido aprovechado), dispara una falla de segmentacin y finaliza. Execshield tambin ofrece soporte para las tencologas No ejecutar (NX, por las iniciales en ingls de No eXecute) de las plataformas AMD64, y para las tecnologas Deshabilitar ejecutar (XD, por las iniciales en ingls de eXecute Disable) de las las plataformas Itanium y sistemas Intel 64. Estas tecnologas trabajan junto a ExecShield para prevenir que sea ejecutado cdigo malicioso en la porcin ejecutable de la memoria virtual, con una precisin de 4KB de cdigo ejecutable, disminuyendo el riego de un ataque a la debilidad de un bfer desbordado.

42

Servicios de red disponibles

Importante
Para limitar la exposicin a ataques en la red, todos los servicios que no son utilizados deben ser apagados.

3.1.5.2. Identificando y configurando servicios


Para mejorar la seguridad, muchos de los servicios de red instalados con Fedora estn apagados por defecto. Hay, de todas formas, algunas notables excepciones: cupsd El servidor de impresin por defecto para Fedora. lpd Un servidor de impresin alternativo. xinetd Un sper servidor que controla las conexiones de un rango de servidores subordinados, como son, por ejemplo gssftp y telnet. sendmail El Agente de transporte de correo (MTA, por las iniciales en ingls de Mail Transport Agent) de Sendmail es activado por defecto, pero solo escucha las conexiones del localhost. sshd El servidor OpenSSH, es un reemplazo seguro para Telnet. Cuando se intenta conocer cundo dejar estos servicios en ejecucin, lo mejor es utilizar el sentido comn y adoptar un punto de vista basado en la precaucin. Por ejemplo, si una impresora no est disponible, no deje el servicio cupsd prendido. Lo mismo vale para portmap. Si usted no monta volumenes NFSv3, o utiliza NIS (el servicio ypbind), entonces portmap debera deshabilitarse.

Figura 3.3. Herramienta de Configuracin de Servicios

43

Captulo 3. Asegurando su Red Si no est seguro de los propsitos de un servicio particular, la Herrameinta de configuracin de servicios tiene un campo descriptivo, que se detalla en Figura 3.3, Herramienta de Configuracin de Servicios, y que ofrece informacin adicional. Verificar qu servicios de red se encuentran disponibles para iniciarse en el momento del arranque del sistema, es slo una parte de esta historia. Debera verificar tambin qu puertos estn abiertos y escuchando. Para ms informacin, vea la Seccin 3.2.8, Verificar qu puertos estn abiertos.

3.1.5.3. Servicios inseguros


Cualquier servicio de red es potencialmente inseguro. Es por esto que es tan importante apagar los servicios que no se utilicen. Las debilidades de los servicios son cotidianamente descubiertas y enmendadas, haciendo que sea muy importante actualizar los paquetes relacionados con cualquiera de los servicios de red. Para obtener ms informacin, vea la Seccin 1.5, Actualizaciones de seguridad. Algunos protocolos de red son en s mismos ms inseguros que otros. Estos incluyen los servicios que: Transmiten sin encriptar nombres de usuarios y contraseas en la red Muchos protocolos antiguos, como por ejemplo Telnet y FTP, no encriptan las autenticaciones de las sesiones, y siempre que sea posible, deberan ser evitados. Transmit Sensitive Data Over a Network Unencrypted Many protocols transmit data over the network unencrypted. These protocols include Telnet, FTP, HTTP, and SMTP. Many network file systems, such as NFS and SMB, also transmit information over the network unencrypted. It is the user's responsibility when using these protocols to limit what type of data is transmitted. Servicios de volcado de memoria remoto, como netdump, transmiten el contenido de la memoria sobre una red sin encriptar . Los volcados de memoria pueden contener contraseas o, peor an, entradas a base de datos o informacin sensible. Otros servicios como finger y rwhod revelan informacin sobre usuarios del sistema. Ejemplos de servicios inherentemente inseguros incluyen rlogin, rsh, telnet, y vsftpd. Todos los programas de ingreso remoto de consola (rlogin, rsh, y telnet) deberan ser evitados en favor de la utilizacin de SSH. Para obtener mayor informacin acerca de sshd, vea la Seccin 3.1.7, Herramientas de comunicacin de seguridad mejorada. FTP no es en s mismo tan peligroso para la seguridad del sistema como las consolas remotas, pero los servidores FTP deben ser cuidadosamente configurados y vigilados para evitar probelmas. Para obtener mayor informacin acerca cmo asegurar servidores FTP, vea la Seccin 3.2.6, Asegurando FTP. Entre los ervicios que deberan ser cuidadosamente implementados, y colocarse detrs de un cortafuegos, podemos encontrar a: finger authd (antes llamado identd en versiones anteriores de Fedora.) netdump netdump-server nfs rwhod 44

Cortafuegos personales sendmail smb (Samba) yppasswdd ypserv ypxfrd Mayor informacin acerca de cmo asegurar servicios de red puede encontrarse en la Seccin 3.2, Seguridad del servidor. La siguiente seccin discute las herramientas disponibles para crear un cortafuegos sencillo.

3.1.6. Cortafuegos personales


Luego de haberse configurado los servicios de red necesarios, es importante la implementacin de un cortafuegos.

Importante
Debera configurar los servicios necesarios e implementar un cortafuegos antes de conectarse a Internet, o a cualquier otra red en la que usted no confe. Firewalls prevent network packets from accessing the system's network interface. If a request is made to a port that is blocked by a firewall, the request is ignored. If a service is listening on one of these blocked ports, it does not receive the packets and is effectively disabled. For this reason, care should be taken when configuring a firewall to block access to ports not in use, while not blocking access to ports used by configured services. Para la mayora de los usuarios, la mejor herramienta para configurar un cortafuegos es mediante la interfaz grfica de configuracin de cortafuegos que viene con Fedora: la Herramienta de administracin de coftafuegos (system-config-firewall). Esta herramienta genera reglas amplias de iptables para un cortafuegos de propsitos generales, utilizando una interfaz de panel de control. Para obtener mayor informacin acerca del uso de esta aplicacin y sus opciones disponibles, vea la Seccin 3.8.2, Configuracin bsica de un cortafuego. Para usuarios avanzados y administradores de servidores, es una mejor opcin la de configurar manualmente el cortafuegos utilizando iptables. Para obtener mayor informacin, vea la Seccin 3.8, Cortafuegos. Para una gua detallada de la utilizacin del comando iptables, vea la Seccin 3.9, IPTables.

3.1.7. Herramientas de comunicacin de seguridad mejorada


As como han crecido el tamao y la popularidad de Internet, tambin han aumentado los peligros de la interceptacin de las comunicaciones. Con el correr de los aos, se han desarrollado herramientas para encriptar las comunicaciones mientras estn siendo transferidas sobre la red. Fedora viene con dos herramientas bsicas, que usan algoritmos de encriptacin de alto nivel de clave pblica, para proteger la informacin mientras viaja por la red:

45

Captulo 3. Asegurando su Red OpenSSH Una implementacin libre del protocolo SSH para encriptar comunicaciones de red. Proteccin de Privacidad Gnu (GPG, por las iniciales en ingls de Gnu Privacy Guard) Una implementacin libre para proteger los datos de la aplicacin para encriptado PGP (por las iniciales en ingls de Pretty Good Privacy). OpenSSH es la forma ms segura de acceder a equipos remotos y reemplazar servicios antiguos y no encriptados como telnet y rsh. Open SSH ofrece un servicio de red llamado sshd y tres aplicaciones de cliente mediante la lnea de comandos: ssh Un cliente seguro para acceso a consola remota. scp Un comando de copia remota segura. sftp Un pseudo cliente ftp seguro que permite sesiones interactivas de transferencias de archivos. Vaya a la Seccin 4.2.2, Shell seguro (SSH, por las iniciales en ingls de Secure Shell) para obtener mayor informacin sobre OpenSSH.

Importante
Si bien el servicio sshd es en s mismo seguro, el servicio debe mantenerse actualizado para prevenir amenazas a la seguridad. Para obtener mayor informacin, vea la Seccin 1.5, Actualizaciones de seguridad. GPG es una manera de asegurar la privacidad en la comunicacin de correo. Puede ser utilizado tanto para enviar datos sensibles sobre las redes pblicas como para proteger datos sensibles en discos duros.

3.2. Seguridad del servidor


Cuando un sistema es utilizado como servidor en una red pblica, se convierte en el objetivo de los ataques. Por lo tanto, robustecer el sistema y desconectar los servicios es de importancia suprema para el administrador del sistema. Antes de profundizar en problemas especficos, recuerde los siguientes consejos generales para fortalecer la seguridad de los servidores: Mantenga todos los servicios actualizados, para protegerse contra las ltimas amenazas. Siempre que sea posible, utilice protocolos seguros. Siempre que sea posible, ofrezca slo un tipo de servicio de red por mquina. Observe cuidadosamente a todos los servidores en busca de actividad sospechosa.

3.2.1. Asegurando los servicios con encapsuladores TCP y xinetd


Los encapsuladores TCP ofrecen control de acceso para una variedad de servicios. Muchos de los servicios de red modernos, como SSH, Telnet, y FTP, utilizan encapsuladores TCP, quienes hacen de guardianes entre la peticin entrante y el servicio solicitado.

46

Asegurando los servicios con encapsuladores TCP y xinetd Los beneficios que ofrecen los encapsuladores TCP se potencian si se utilizan junto a xinetd, un super servidor que ofrece acceso adicional, registrado, vinculacin, redireccionamiento y control de la utilizacin de los recursos.

Nota
Es una buena idea utilizar reglas de cortafuego iptables junto con los encapsuladores TCP y xinetd, para generar redundancia dentro de los controles de acceso al servicio. Para obtener ms informacin acerca de la implementacin de cortafuegos con comandos iptable, vea la Seccin 3.8, Cortafuegos. Las siguientes subsecciones presuponen un conocimiento bsico de cada uno de los temas, y se concentran en opciones de seguridad especficas.

3.2.1.1. Mejorando la seguridad utilizando encapsuladores TCP


Los encapsuladores TCP son capaces de mucho ms que denegar el acceso a servicios. Esta seccin ilustra como se pueden usar para enviar pancartas de conexin, alertar de ataques de nodos en particular y aumentar la funcionalidad de registro. Refirase a la pgina del manual hosts_options para obtener informacin acerca de la funcionalidad de los encapsuladores TCP y el lenguaje de control.

3.2.1.1.1. Encapsuladores TCP y pancartas de conexin


Desplegar una pancarta apropiada cuando los usuarios se conectan a un servicio es una buena manera de hacerle saber a los posibles atacantes que el administrador del sistema est vigilando. Usted puede tambin controlar qu informacin acerca del sistema es presentada a los usuarios. Para implementar una pancarta por medio de encapsuladores TCP para un servicio, use la opcin banner. Este ejemplo implementa una pancarta para vsftpd. Para comenzar, cree un archivo de pancarta. Puede ser en cualquier lugar del sistema, pero debe tener el mismo nombre que el demonio. Para este ejemplo, el archivo es llamado /etc/banners/vsftpd y contiene la siguiente linea:
220-Hello, %c 220-All activity on ftp.example.com is logged. 220-Inappropriate use will result in your access privileges being removed.

La ficha %c prove de una serie de informacin del cliente, como el nombre de usuario y el nombre de husped o el nombre de usuario y la direccin IP para hacerlo ms intimidante. Para que esta pancarta sea desplegada en todas la conexiones entrantes, hay que agregar la siguiente linea en el archivo/etc/hosts.allow:
vsftpd : ALL : banners /etc/banners/

3.2.1.1.2. Encapsuladores TCP y alertas de ataque


Si un husped o red en particular han sido detectados atacando el servidor, los encapsuladores TCP pueden ser usados para alertar al administrador de ataques subsecuentes provenientes de ese husped o red usando la directiva spawn.

47

Captulo 3. Asegurando su Red En este ejemplo, asumamos que un atacante de la red 206.182.68.0/24 ha sido detectado tratando de atacar el servidor. Agregue la siguiente linea en el archivo /etc/hosts.deny para denegar cualquier intento de conexin desde esa red, y para registrar los intentos a un archivo en especial:
ALL : 206.182.68.0 : spawn /bin/ 'date' %c %d >> /var/log/intruder_alert

La ficha %d prove el nombre del servicio al que el atacante est tratando de acceder. Para permitir una conexin y registrarla, use la directiva spawn en el archivo /etc/hosts.allow.

Nota
Ya que la directiva spawn ejecuta cualquier comando, es una buena idea crear un programa especial para notificar al administrador o ejecutar una cadena de comandos en el evento de un cliente en particular tratando de conectarse al servidor.

3.2.1.1.3. Encapsuladores TCP y registro avanzado


Si ciertos tipos de conexin son ms preocupantes que otros, el nivel de registro puede ser elevado para ese servicio usando la opcin severity. Para este ejemplo, asumamos que cualquiera que intente conectarse al puerto 23 (el puerto de Telnet) en un servidor FTP est tratando de romper el sistema. Para denotar esto, use la bandera emerg en los archivos de registro en lugar de la bandera por defecto info y deniegue la conexin. Para hacer esto, ponga la siguiente linea en el archivo /etc/hosts.deny:
in.telnetd : ALL : severity emerg

Esto usa la facilidad de registro por defecto authpriv, pero eleva la prioridad del valor por defecto info a emerg, lo cual escribe los mensajes de registro directamente a la consola.

3.2.1.2. Aumentando la seguridad con xinetd


Esta seccin se concentra en el uso de xinetd para crear un servicio de trampa y usarlo para controlar los niveles de recurso disponibles para cualquier servicio xinetd. Crear lmites de recursos para los servicios puede ayudar a frustrar ataques de denegacin de servicio (Denial of Service, DoS). Refirase a las pginas del manual para xinetd y xinetd.conf para una lista de opciones disponibles.

3.2.1.2.1. Poniendo una trampa


Una caracterstica importante de xinetd es su habilidad para agregar equipos a una lista no_access global. Los equipos en esta lista no pueden crear conexiones subsecuentes a servicios manejados por xinetd por un periodo especfico de tiempo, o hasta que xinetd sea reiniciado. Usted puede hacer esto usando el atributo SENSOR. Esta es una manera fcil de bloquear equipos que intentan explorar puertos en el servidor. El primer paso para crear un SENSOR es escoger que servicio no est planeado a usarse. En este ejemplo es utilizado telnet. Edite el archivo /etc/xinetd.d/telnet y cambie la linea flags a:

48

Asegurando los servicios con encapsuladores TCP y xinetd

flags

= SENSOR

Agregue la siguiente lnea:


deny_time = 30

Esto deniega cualquier intento de conexin a este puerto para ese equipo por 30 minutos. Otros valores aceptables para el atributo deny_time son FOREVER, el cual mantiene el veto en efecto hasta que xinetd es reiniciado y NEVER, el cual permite la conexin y la registra. Finalmente, la ltima linea debe ser:
disable = no

Esto habilita la trampa. Mientras que el uso de SENSOR es una buena idea para detectar y detener conexiones desde equipos indeseables, tiene dos caractersticas en contra: No funciona contra exploraciones sigilosas (stealth) Un atacante que sabe que un SENSOR esta corriendo puede montar un ataque de denegacin de servicio contra un servidor en particular al forjar su direccin IP y conectarse al puerto prohibido.

3.2.1.2.2. Control de los recursos del servidor


Otra caracterstica importante de xinetd es su habilidad de declarar lmites de recursos para los servicios bajo su control. Lo hace usando las siguientes directivas cps = <number_of_connections> <wait_period> Limita la tasa de conexiones entrantes. sta toma dos argumentos: <number_of_connections> El nmero de conexiones por segundo para gestionar. Si la tasa de conexiones entrantes es mayor que sta, el servicio es temporalmente deshabilitado. El valor predeterminado es cincuenta (50). <wait_period> El nmero de segundos para esperar antes de rehabilitar el servicio despus que ste ha sido deshabilitado. El intervalo predeterminado es diez (10) segundos. instances = <number_of_connections> Specifies the total number of connections allowed to a service. This directive accepts either an integer value or UNLIMITED. per_source = <number_of_connections> Specifies the number of connections allowed to a service by each host. This directive accepts either an integer value or UNLIMITED. rlimit_as = <number[K|M]> Specifies the amount of memory address space the service can occupy in kilobytes or megabytes. This directive accepts either an integer value or UNLIMITED. rlimit_cpu = <number_of_seconds> Specifies the amount of time in seconds that a service may occupy the CPU. This directive accepts either an integer value or UNLIMITED. Usar estas directivas puede ayudar a prevenir cualquier servicio xinetd de abrumar el sistema, resultando en una denegacin de servicio. 49

Captulo 3. Asegurando su Red

3.2.2. Asegurando Portmap


El servicio portmap es un demonio de asignacin dinmica de puertos para servicios RPC como NIS y NFS. Tiene mecanismos dbiles de autenticacin y tiene la habilidad de asignar un amplio rango de puertos para los servicios que controla. Por estas razones, es difcil de asegurar.

Nota
Asegurar portmap solo afecta a las implementaciones NFSv2 y NFSv3, ya que desde NFSv4 ya no es requerido. Si usted planea implementar un servidor NFSv2 o NFSv3, entonces portmap es requerido, y la siguiente seccin aplica. Si corre servicios RPC, obedezca estas reglas bsicas.

3.2.2.1. Proteja portmap con encapsuladores TCP


Es importante usar encapsuladores TCP para limitar qu redes o equipos tienen acceso al servicio portmap dado que no tiene una forma propia de autenticacin. Adems, use solamente direcciones IP cuando limite el acceso al servicio. Evite usar nombres de equipos, ya que pueden ser forjados por envenenamiento de DNS y otros mtodos.

3.2.2.2. Proteja portmap con iptables


Para restringir an ms el acceso al servicio portmap, es una buena idea agregar reglas de iptables al servidor y restringir el acceso a redes especficas. Abajo hay dos ejemplos de comandos iptables. El primero permite conexiones TCP al puerto 111 (usado por el servicio portmap) desde la red 192.168.0.0/24. El segundo permite conexiones TCP al mismo puerto localmente. Esto es necesario para el servicio sgi_fam usado por Nautilus. Todos los dems paquetes son ignorados.
iptables -A INPUT -p tcp -s! 192.168.0.0/24 --dport 111 -j DROP iptables -A INPUT -p tcp -s 127.0.0.1 --dport 111 -j ACCEPT

Para limitar el trfico UDP de manera similar, use el siguiente comando.


iptables -A INPUT -p udp -s! 192.168.0.0/24 --dport 111 -j DROP

Nota
Dirjase a la Seccin 3.8, Cortafuegos para obtener mayor informacin acerca de implementar cortafuegos con comandos de iptables.

3.2.3. Asegurando NIS


El servicio de informacin de red (Network Information Service, NIS) es un servicio RPC, llamado ypserv, el cual es usado en conjunto con portmap y otros servicios relacionados para distribuir

50

Asegurando NIS mapas de nombres de usuario, contraseas y otros tipos de informacin sensible dentro de su propio dominio. Un servidor NIS est compuesto por diversas aplicaciones. Entre ellas podemos encontrar: /usr/sbin/rpc.yppasswdd Tambin denominado servicio yppasswdd. Este demonio permite que los usuarios modifiquen sus contraseas NIS. /usr/sbin/rpc.ypxfrd Tambin denominado servicio ypxfrd. Este demonio es el responsable de las transferencias de mapas NIS sobre la red. /usr/sbin/yppush Esta aplicacin se encarga de distribuir las bases de datos NIS que han sido modificadas hacia diferentes servidores NIS. /usr/sbin/ypserv Este es el demonio del servidor NIS. NIS is somewhat insecure by today's standards. It has no host authentication mechanisms and transmits all of its information over the network unencrypted, including password hashes. As a result, extreme care must be taken when setting up a network that uses NIS. This is further complicated by the fact that the default configuration of NIS is inherently insecure. Se recomienda a todo aquel que tenga intenciones de implementar un servidor NIS, que primero asegure el servicio portmap (como se puede observar en la Seccin 3.2.2, Asegurando Portmap), y que luego contine con los siguientes eventos, como la planificacin de la red.

3.2.3.1. Planeamiento cuidadoso de la red


Debido a que NIS transmite sin encriptar informacin clave a travs de la red, es importante que el servicio sea ejecutado detrs de un cortafuegos y sobre una porcin de la red definida y considerada segura. Existen riegos de intercepcin cada vez que se transmite informacin NIS sobre una red que no es segura. Un cuidadoso diseo de la red puede ayudar a prevenir importantes intrusiones en la seguridad.

3.2.3.2. Utilizacin de nombres de dominio y de equipo NIS, de modo similar a una contrasea
Cualquier mquina dentro de un dominio NIS puede usar comandos para extraer informacin desde el servidor sin autenticacin, siempre y cuando el usuario sepa el nombre de equipo del servidor NIS y el nombre de dominio NIS. Por ejemplo, si alguien conecta una laptop en la red, o si irrumpe en ella desde el exterior (y se las ingenia para obtener una direccin IP interna), los siguientes comandos muestran el mapa de /etc/ passwd:
ypcat -d <NIS_domain> -h <DNS_hostname> passwd

Si el atacante es un usuario root, puede obtener el archivo /etc/shadow ingresando el siguiente comando:
ypcat -d <NIS_domain> -h <DNS_hostname> shadow

51

Captulo 3. Asegurando su Red

Nota
Si se utiliza Kerberos, el archivo /etc/shadow no se encuentra almacenado dentro de un mapa NIS. Para hacer ms complicado a los atacantes el acceso a los mapas NIS, genere una cadena aleatoria para el nombre del equipo DNS, como por ejemplo o7hfawtgmhwg.domain.com. De manera similar, genere aleatoriamente un nombre de dominio NIS distinto. Esto hace que para un atacante sea mucho ms dificil ingresar en el servidor NIS.

3.2.3.3. Editar el archivo /var/yp/securenets


Si el archivo /var/yp/securenets est vaco o no existe (como es el caso luego de una instalacin por defecto), NIS escucha a todos los puertos. Una de las primeras cosas a realizar es ingresar pares mscara de red/red (netmask/network) en el archivo de modo que ypserv solo responda a las peticiones de una red adecuada. A continuacin se muestra una entrada de ejemplo del archivo /var/yp/securenets:
255.255.255.0 192.168.0.0

Advertencia
Nunca inicie un servidor NIS por vez primera sin haber antes creado el archivo /var/yp/ securenets. Esta tcnica no ofrece proteccin contra ataques de simulacin de identidad, pero al menos establece lmites sobre las redes en las que el servidor NIS est funcionando.

3.2.3.4. Asigne puertos estticos y utilice reglas de iptables


A todos los servidores relacionados con NIS se les puede asignar un puerto especfico, excepto rpc.yppasswdd el demonio que permite a los usuarios modificar sus contraseas de logueo. Asignar puertos a rpc.ypxfrd y ypserv, los restantes demonios de servidores NIS, permite la creacin de reglas de cortafuegos, y de esta manera poder proteger a los demonios de futuras intrusiones. Para hacerlo, agregue las siguientes lneas en /etc/sysconfig/network:
YPSERV_ARGS="-p 834" YPXFRD_ARGS="-p 835"

Las siguientes reglas iptables pueden ser utilizadas para fortalecer la red que el servidor est escuchando con estos puertos:
iptables -A INPUT -p ALL -s! 192.168.0.0/24 iptables -A INPUT -p ALL -s! 192.168.0.0/24 --dport 834 -j DROP --dport 835 -j DROP

52

Asegurando NFS Esto significa que el servidor solo permite conexiones a los puertos 834 y 835, si es que la peticin proviene desde la red 192.168.0.0/24, y sin importar qu protocolo se est utilizando.

Nota
Dirjase a la Seccin 3.8, Cortafuegos para obtener mayor informacin acerca de implementar cortafuegos con comandos de iptables.

3.2.3.5. Use autenticacin con Kerberos


Uno de los problemas a ser considerados si se utiliza NIS para una autenticacin, es que cada vez que un usuario ingresa en una mquina, se enva un hash del mapa /etc/shadow por la red. Si un intruso obtiene acceso a un dominio NIS y observa el trfico en la red, puede recolectar los hashes de nombres de usuarios y contraseas. Con el tiempo suficiente, un programa de descifrado de contraseas puede adivinar aquellas que son dbiles, y el atacante puede obtener acceso a una cuenta vlida en esa red. Debido a que Kerberos utiliza cifrados con una clave secreta, nunca se envan hashes de contraseas sobre la red, haciendo que el sistema sea ms seguro. Para obtener mayor informacin acerca de Kerberos, vea la Seccin 3.7, Kerberos.

3.2.4. Asegurando NFS


Importante
La versin de NFS incluida en Fedora, NFSv4, ya no necesita el servicio portmap como se lo indica en la Seccin 3.2.2, Asegurando Portmap. El trfico NFS, en lugar de UDP ahora utiliza TCP para todas sus versiones, y lo solicita al utilizar NFSv4. NFSv4 ahora ofrece autenticacin Kerberos para grupos y usuarios, como parte del mdulo del kernel RPCSEC_GSS. Sigue existinedo informacin incluida acerca de portmap, ya que Fedora tiene soporte para NFSv2 y NFSv3, y ambos utilizan portmap.

3.2.4.1. Planeamiento cuidadoso de la red


Ahora que NFSv4 tiene la capacidad de enviar toda la informacin en la red encriptada utilizando Kerberos, es importante que el servicio sea configurado correctamente, si es que se encuentra detrs de un cortafuegos o en una red segmentada. Todava NFSv3 enva los datos de manera no segura, y esto debera ser tendido en cuenta. Un diseo de redes que preste atencin a todos estos aspectos puede prevenir fallas en la seguridad.

3.2.4.2. Cuidado con los errores de sintaxis


El servidor NFS determina qu sistemas de archivos exportar y hacia qu equipos hacerlo al consultar el archivo /etc/exports. Tenga cuidado de no agregar espacios extraos cuando edite este archivo. Por ejemplo, la siguiente lnea en el archivo /etc/exports comparte el directorio /tmp/nfs/ con el equipo juan.ejemplo.com con permisos de lectura y escritura.

53

Captulo 3. Asegurando su Red

/tmp/nfs/

bob.example.com(rw)

Por otro lado, la siguiente lnea en el archivo /etc/exports comparte el mismo directorio con el equipo juan.ejemplo.com, slo con permisos de lectura, y adems lo comparte con el mundo con permisos de lectura y de escritura, debido a un simple espacio en blanco dejado luego del nombre del equipo.
/tmp/nfs/ bob.example.com (rw)

Es una buena costumbre la de confirmar cualquier configuracin de elementos compartidos NFS, utilizar para ello el comando showmount y verificar qu es lo que est siendo compartido:
showmount -e <hostname>

3.2.4.3. No utilice la opcin no_root_squash


Por defecto, al utilizarse para compartir elementos, NFS cambia el usuario root al usuario nfsnobody, una cuenta de usuario sin privilegios. Esto modifica la pertenencia de todos los archivos creados por el usuario root, y se los otorga a nfsnobody, evitando de esta forma la carga de programas definidos con bit de tipo setuid. Si se utiliza no_root_squash, los usuarios root remotos tienen la posibilidad de modificar cualquier archivo en el sistema de archivos compartido, y dejar aplicaciones infectadas con troyanos para que otros usuarios las ejecuten sin saberlo.

3.2.4.4. Configuracin del cortafuego de NFS


Los puertos utilizados por NFS estn dinmicamente asignados por rpcbind, y esto puede causar problemas en el momento de crear reglas de cortafuegos. Para simplificar este proceso, utilice el archivo /etc/sysconfig/nfs para especificar qu puertos deben ser utilizados: MOUNTD_PORT puerto TCP y UDP para mountd (rpc.mountd) STATD_PORT puerto TCP y UDP para status (rpc.statd) LOCKD_TCPPORT puerto TCP para nlockmgr (rpc.lockd) LOCKD_UDPPORT UDP port nlockmgr (rpc.lockd) Los nmeros de puerto especificados no deben ser utilizados por ningn otro servicio. Configure su cortafuegos para permitir los nmeros de puerto especificados, del mismo modo que el puerto TCP y UDP 2049 (NFS). Ejecute el comando rpcinfo -p sobre el servidor NFS para conocer qu programas RPC y qu puertos estn siendo utilizados.

3.2.5. Asegurando el servidor HTTP Apache


El servidor HTTP Apache es uno de los servicios ms seguros y estables que son empaquetados con Fedora. Una extensa variedad de opciones y tcnicas estn disponibles para asegurar el servidor HTTP Apache demasiado numerosas para analizarlas en profundidad aqu. La seccin siguiente explica brevemente algunas buenas costumbres al ejecutar el servidor HTTP Apache. Siempre verifique que funcione correctamente cualquier programa que tenga intencin de utilizar en el sistema antes de ponerlo en produccin. Adems, asegrese que solo el usuario root tenga permisos 54

Asegurando FTP de escritura sobre cualquier directorio que contenga programas o CGIs. Para hacer esto, ejecute los siguientes comandos como usuario root: 1. 2.
chown root <directory_name>

chmod 755 <directory_name>

Los administradores de sistemas deben ser cuidadosos al utilizar las siguientes opciones de configuracin (definidas en /etc/httpd/conf/httpd.conf): FollowSymLinks Esta directiva se encuentra activa por defecto, de modo que tenga cuidado al crear enlaces simblicos al documento raz del servidor Web. Por ejemplo, es una mala idea la de adjudicarle un enlace simblico a /. Indexes Esta directiva est activa por defecto, pero puede no ser deseada. Elimnela si quiere evitar que los visitantes puedan examinar los archivos del servidor. UserDir La directiva UserDir se encuentra deshabilitada por defecto, debido a que puede confirmar la presencia de una cuenta de usuario en el sistema. Para permitir que se examinen directorios de usuario en el servidor, utilice las siguientes directivas:
UserDir enabled UserDir disabled root

Estas directivas activan la posibilidad de analizar directorios de usuario para todos los directorios de usuarios que no sean /root/. Para aadir usuarios a la lista de las cuentas desactivadas, aada a esos usuarios en una lista separada por espacios en la lnea UserDir disabled.

Importante
No elimine la directiva IncludesNoExec. Por defecto, el mdulo Server-Side Includes (SSI) no puede ejecutar comandos. Se recomienda no cambiar estas configuraciones a no ser que sea absolutamente necesario, ya que potencialmente podra permitir que un atacante ejecute comandos en el sistema.

3.2.6. Asegurando FTP


El Protocolo de Transferencia de Archivos (FTP, por las iniciales en ingls de File Transfer Protocol), es un viejo protocolo TCP diseado para transferir archivos sobre una red. Puesto que todas las transacciones con el servidor no son encriptadas, incluyendo las autenticaciones de usuario, es considerado un protocolo no seguro y debera ser configurado cuidadosamente. Fedora provee tres servidores FTP. gssftpd Un demonio basado en xinetd con soporte para Kerberos que no transmite informaciones de autenticacin sobre la red. Acelerador de Contenido de Red Hat (tux) Un servidor web en el espacio del kernel con capacidades FTP.

55

Captulo 3. Asegurando su Red vsftpd Una implementacin orientada a la seguridad del servicio FTP. Los siguientes lineamientos de seguridad sirven para configurar el servicio FTP vsftpd.

3.2.6.1. Mensaje de bienvenida de FTP


Antes de enviar un nombre de usuario y una contrasea, todos los usuarios son recibidos con una imagen de bienvenida. Por defecto, esta imagen incluye la informacin de la versin que se est utilizando, informacin que sirve a los atacantes para poder identificar debilidades en el sistema. Para modificar la imagen de bienvenida para vsftpd, agregue la siguiente directiva en el archivo / etc/vsftpd/vsftpd.conf:
ftpd_banner=<insert_greeting_here>

Reemplace <insert_greeting_here> en la directriz de arriba con el texto del mensaje de bienvenida. Para imgenes con varias lneas, lo mejor es utilizar un archivo de imagen. Para simplificar la administracin de mltiples imgenes, coloquelas a todas ellas en un nuevo directorio llamado /etc/ banners/. En nuestro ejemplo, el archivo de imagen para conexiones FTP es /etc/banners/ ftp.msg. A continuacin se puede observar cmo puede llegar a lucir un archivo con esstas caractersticas:
######### # Hello, all activity on ftp.example.com is logged. #########

Nota
No es necesario empezar cada lnea del archivo con 220, como se lo indica en la Seccin 3.2.1.1.1, Encapsuladores TCP y pancartas de conexin. Para tener una referencia de esta imagen de bienvenida en vsftpd, aada la siguiente directiva en el archivo /etc/vsftpd/vsftpd.conf:
banner_file=/etc/banners/ftp.msg

Tambin es posible enviar imgenes adicionales a conexiones entrantes utilizando encapsuladores TCP como se explica en la Seccin 3.2.1.1.1, Encapsuladores TCP y pancartas de conexin.

3.2.6.2. Acceso annimo


La presencia del directorio /var/ftp/ activa la cuenta annima. La forma ms sencilla de crear este directorio es instalando el paquete vsftpd. Este paquete establece un rbol de directorios para usuarios annimos y configura los permisos de manera tal que estos usuarios slo puedan leer sus contenidos. Por defecto, el usuario annimo no puede escribir en ningn directorio.

56

Asegurando FTP

Advertencia
Si se habilita la posibilidad de acceso annimo a un servidor FTP, tenga cuidado de donde almacenar los datos importantes.

3.2.6.2.1. Subida annima


Para permitir que los usuarios annimos suban archivos, es recomendable la creacin de un directorio dentro de /var/ftp/pub/, con permisos de escritura solamente. Para hacerlo, ingrese el siguiente comando:
mkdir /var/ftp/pub/upload

A continuacin, modifique los permisos de modo que los usuarios annimos no puedan conocer el contenido del directorio:
chmod 730 /var/ftp/pub/upload

Un listado de manera extendida del directorio, debera ser semejante a esto:


drwx-wx--2 root ftp 4096 Feb 13 20:05 upload

Advertencia
Los administradores que permiten que usuarios annimos sean capaces de leer y de escribir sobre los directorios, a menudo se encuentran con que sus servidores se han convertido en repositorios de software robado. Adicionalmente, bajo vsftpd, aada la siguiente lnea en el archivo /etc/vsftpd/vsftpd.conf:
anon_upload_enable=YES

3.2.6.3. Cuentas de usuario


Debido a que FTP transmite para su autenticacin nombres de usuario y contraseas sin encriptarse sobre redes no seguras, es una buena idea la de negar a los usuarios del sistema el acceso al servidor desde sus cuentas de usuario. Para deshabilitar todas las cuentas de usuario en vsftpd, agregue la siguiente directiva en /etc/ vsftpd/vsftpd.conf:
local_enable=NO

57

Captulo 3. Asegurando su Red

3.2.6.3.1. Restringiendo cuentas de usuario


Para deshabilitar acceso FTP para una cuenta especfica, o un grupo de cuentas especfico, como ser por ejemplo el usuario root y todos aquellos con privilegios sudo, la manera ms sencilla de hacerlo es utilizar un archivo de lista PAM como se explica en la Seccin 3.1.4.2.4, Deshabilitando root usando PAM. El archivo de configuracin PAM para vsftpd es /etc/pam.d/vsftpd. Tambin es posible deshabilitar cuentas de usuario directamente dentro de cada servicio. Para deshabilitar cuentas de usuario especficas en vsftpd, agregue el nombre del usuario en / etc/vsftpd.ftpusers

3.2.6.4. Utilice encapsuladores TCP para el control de acceso


Utilice encapsuladores TCP para controlar el acceso al demonio FTP como se indica en la Seccin 3.2.1.1, Mejorando la seguridad utilizando encapsuladores TCP.

3.2.7. Asegurando Sendmail


Sendmail es un agente de transferencia de correos (MTA, por las iniciales en ingls de Mail Transfer Agent), que utiliza protocolo simple de transferencia de correo (SMTP, Simple Mail Transfer Protocol) para enviar mensajes electrnicos entre otros MTAs, o hacia otros clientes de correo, o agentes de entrega. Si bien muchos MTAs son capaces de encriptar el trfico entre uno y otro, algunos no lo hacen, de modo que enviar correos electrnicos en una red pblica es considerado una forma de comunicacin no segura. Es recomendable que todos aquellos que estn planeando implementar un servidor Sendmail, tengan en cuenta los siguientes inconvenientes.

3.2.7.1. Limitar un ataque de denegacin de servicio


Debido a la naturaleza del correo electrnico, un atacante determinado puede inundar de manera relativamente sencilla el servidor con correos, y provocar la denegacin del servicio. Al establecer lmites a las siguientes directivas en /etc/mail/sendmail.mc, la efectividad de ataques de ese tipo se ve disminuida. confCONNECTION_RATE_THROTTLE El nmero de conexiones que el servidor puede recibir por segundo. Por defecto, Sendmail no limita el nmero de conexiones. Si se alcanza un lmite previamente establecido, las siguientes conexiones son demoradas. confMAX_DAEMON_CHILDREN El mximo nmero de procesos hijo que pueden ser generados por el servidor. Por defecto, Sedmail no atribuye un lmite a la cantidad de estos procesos. Si se alcanza un lmite previamente establecido, las siguientes conexiones sern demoradas. confMIN_FREE_BLOCKS El nmero mnimo de bloques libres que deben estar disponibles para que el servidor acepte correos. La cantidad establecida por defecto es de 100 bloques. confMAX_HEADERS_LENGTH El tamao mximo aceptable (en bytes) para un encabezado de mensaje. confMAX_MESSAGE_SIZE El tamao mximo aceptable (en bytes) para un solo mensaje.

3.2.7.2. NFS y Sendmail


Nunca coloque el directorio mail spool, /var/spool/mail/, en un volumen NFS compartido. Debido a que NFSv2 y NFSv3 no mantienen control sobre los IDs de usuario y grupo, dos o ms usuarios pueden tener el mismo UID y recibir y leer los correos de los otros. 58

Verificar qu puertos estn abiertos

Nota
Con NFSv4 utilizando Kerberos este no es el caso, ya que el mdulo del kernel SECRPC_GSS no utiliza autenticaciones basadas en UID. Sin embargo, todava hoy es considerada una buena costumbre la de no colocar el directorio mail spool en volmenes NFS compartidos.

3.2.7.3. Usuarios de slo correo


Para ayudar a prevenir que explote a los usuarios locales para usar el servidor Sendmail, lo mejor es que solamente ingresen al servidor Sendmail usando un cliente de correos electrnicos. Las cuentas de consola en el servidor de correo no deberan ser permitidas y todos los usuarios de consola en el archivo /etc/passwd deberan definirse como /sbin/nologin (con la posible excepcin del usuario root).

3.2.8. Verificar qu puertos estn abiertos


After configuring network services, it is important to pay attention to which ports are actually listening on the system's network interfaces. Any open ports can be evidence of an intrusion. Existen dos maneras fundamentales para listar los puertos que estn abiertos en la red. La menos confiable consiste en consultar los paquetes en la red utilizando comandos como netstat -an o lsof -i. Este mtodo es menos confiable debido a que estos programas no se conectan a la mquina desde la red, sino que verifican qu es lo que se est ejecutando en el sistema. Por esta razn, estas aplicaciones frecuentemente son reemplazadas por atacantes. Alguien que quiera ocultar el rastro que est dejando al ingresar, o al abrir sin autorizacin los puertos de un sistema, intentar reemplazar netstat y lsof, con sus versiones personales y modificadas. Una forma ms confiable de verificar los puertos que estn escuchando en una red, es mediante la utilizacin de un escner de puertos como nmap. El siguiente comando ejecutado desde una terminal, especifica los puertos que se encuentran abiertos a conexiones TCP desde la red:
nmap -sT -O localhost

La salida de este comando es la siguiente:


Starting Nmap 4.68 ( http://nmap.org ) at 2009-03-06 12:08 EST Interesting ports on localhost.localdomain (127.0.0.1): Not shown: 1711 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 111/tcp open rpcbind 113/tcp open auth 631/tcp open ipp 834/tcp open unknown 2601/tcp open zebra 32774/tcp open sometimes-rpc11 Device type: general purpose Running: Linux 2.6.X OS details: Linux 2.6.17 - 2.6.24 Uptime: 4.122 days (since Mon Mar 2 09:12:31 2009)

59

Captulo 3. Asegurando su Red


Network Distance: 0 hops OS detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 1.420 seconds

Esta salida muestra que el sistema est ejecutando portmap debido a la presencia del servicio sunrpc. Sin embargo, existe adems un servicio misterioso en el puerto 834. Para verificar si el puerto est asociado con la lista oficial de servicios conocidos, ingrese:
cat /etc/services | grep 834

Este comando no devuelve ninguna informacin. Lo que est indicando es que si bien el puerto se encuentra dentro del rango reservado (es decir, entre 0 y 1023), y que no necesita privilegios de usuario root para abrirse, sin embargo no est asociado con ningn servicio conocido. A continuacin, verifique si existe informacin acerca del puerto utilizando netstat o lsof. Para verificar el puerto 834 utilizando netstat, ingrese el siguiente comando:
netstat -anp | grep 834

El comando devuelve la siguiente salida:


tcp 0 0 0.0.0.0:834 0.0.0.0:* LISTEN 653/ypbind

La presencia de un puerto abierto en netstat es un reaseguro, ya que si un atacante ha abierto un puerto en un sistema en el que no est autorizado a ingresar, seguramente no permitir que sea detectada su presencia mediante este comando. Adems, la opcin [p] revela el proceso ID (PID) del servicio que ha abierto el puerto. En este caso, el puerto abierto pertenece a ypbind (NIS), que es un servicio RPC administrado conjuntamente con el servicio portmap. El comando lsof muestra informacin similar a netstat, ya que tambin es capaz de enlazar puertos con servicios:
lsof -i | grep 834

La seccin que nos interesa de la salida de este comando es la siguiente:


ypbind ypbind ypbind ypbind 653 655 656 657 0 0 0 0 7u 7u 7u 7u IPv4 IPv4 IPv4 IPv4 1319 1319 1319 1319 TCP TCP TCP TCP *:834 *:834 *:834 *:834 (LISTEN) (LISTEN) (LISTEN) (LISTEN)

Estas herramientas nos dicen mucho acerca del estado en que se encuentran los servicios en ejecucin de una mquina. Estas herramientas son flexibles y pueden ofrecer una importante cantidad de informacin acerca de los servicios de red y sus configuraciones. Para obtener ms informacuin, vea las pginas man de lsof, netstat, nmap, y services.

3.3. Single Sign-on (SSO)


3.3.1. Introduccin
Si es necesario, ingrese la contrasea de usuario root de su equipo. 60

Introduccin Adems, los usuarios pueden registrarse en sus mquinas an cuando no exista una red (modo desconexin), o cuando la conectividad no sea confiable, como por ejemplo, los accesos inalmbricos. En este ltimo caso, los servicios sern notablemente disminuidos.

3.3.1.1. Aplicaciones soportadas


Las siguientes aplicaciones estn actualmente soportadas por el esquema de registro unificado en Fedora: Entrada Salvapantallas Firefox y Thunderbird

3.3.1.2. Mecanismos de autenticacin soportados


Actualmente Fedora tiene soporte para los siguientes mecanismos de autenticacin: Ingreso de nombre/contrasea Kerberos Ingreso por Tarjeta Inteligente/PIN

3.3.1.3. Tarjetas Inteligentes soportadas


Fedora ha sido probada con una tarjeta y un lector Cyberflex e-gate, pero cualquier tarjeta que cumpla tanto con las especificaciones de tarjetas Java 2.1.1, y las especificaciones Global Platform 2.0.1, debera poder funcionar correctamente, del mismo modo que cualquier lector que sea soportado por PCSC-lite. Fedora tambin ha sido probada con tarjetas de acceso comn (CAC, por las iniciales en ingls de Common Access Cards). El lector soportado para CAC es el lector USB SCM SCR 331. En cuanto a Fedora 5.2, ya tienen soporte las tarjetas inteligentes Gemalto (Cyberflex Access 64k v2, standard con valor DER SHA1 configurado del mismo modo que en PKCSI v2.1). Estas tarjetas ahora utilizan lectores compatibles con dispositivos de interfaces de tarjetas (CCID, por las iniciales en ingls de Smart Card Interface Devices) de tipo Chip/Smart.

3.3.1.4. Ventajas de SSO en Fedora


Numerosos mecanismos de seguridad existentes hoy en da utilizan una gran cantidad de protocolos y credenciales. Algunos ejemplos de ellos son SSL, SSH, IPsec y Kerberos. La idea de SSO en Fedora es la de unificar estos esquemas para dar soporte a los requerimientos mencionados recin. Esto no significa que haya que reemplazar Kerberos con certificados X.509x3, sino que se unifican para poder reducir el peso que tienen que soportar tanto los usuarios del sistema, como sus administradores. Fedora, para cumplir este objetivo: Ofrece una sola instancia compartida de las bibliotecas de encriptacin NSS en cada sistema operativo. Ships the Certificate System's Enterprise Security Client (ESC) with the base operating system. The ESC application monitors smart card insertion events. If it detects that the user has inserted a smart card that was designed to be used with the Fedora Certificate System server product, it displays a user interface instructing the user how to enroll that smart card. 61

Captulo 3. Asegurando su Red Unifica Kerberos y NSS de modo que los usuarios que se registren en el sistema operativo utilizando una tarjeta inteligente, tambin puedan obtener credenciales de Kerberos (lo que les permite registrarse en los servidores, etc.)

3.3.2. Empezar a utilizar su nueva tarjeta inteligente


Antes de poder utilizar una tarjeta inteligente en sus sistema, y poder aprovechar las grandes ventajas en las opciones de seguridad que esta tecnologa ofrece, necesita realizar en un determinado orden algunas instalaciones mnimas. Ms abajo se explica en qu consisten.

Nota
Esta seccin ofrece una explicacin general para poder empezar a utilizar su tarjeta inteligente. Informacin ms especfica puede encontrarse en la Gua del Cliente del Cliente de Seguridad Empresarial del Sistema de Certificado de Red Hat. 1. 2. 3. Ingrese con su nombre de usuario y contrasea Kerberos. Asegrese de tener instalado el paquete nss-tools. Descargue e instale sus certificados corporativos especficos de usuario root. Utilice el siguiente comando para instalar el certificado root CA:
certutil -A -d /etc/pki/nssdb -n "root ca cert" -t "CT,C,C" -i ./ ca_cert_in_base64_format.crt

4. 5.

Verifique que tenga los siguientes RPMs instalados en su sistema: esc, pam_pkcs11, coolkey, ifdegate, ccid, gdm, authconfig, and authconfig-gtk. Habilite el soporte de ingreso por Tarjeta Inteligente. a. b. c. d. e. On the Gnome Title Bar, select System->Administration->Authentication. Type your machine's root password if necessary. En el dilogo de configuracin de autenticacin, haga clic sobre la pestaa Autenticacin. Tilde la casilla Activar soporte para tarjeta inteligente. Haga clic en el botn Configurar tarjeta inteligente... para ver el dilogo de configuracin de Smartcard, e indique las opciones requeridas: Requiere tarjeta inteligente para ingresar Destilde esta casilla. Luego de haberse ingresado exitosamente en su sistema con la tarjeta inteligente puede elegir esta opcin para prevenir que otros usuarios ingresen a l sin una tarjeta inteligente. Accin de Retiro de Tarjeta Esto controla qu es lo que sucede cuando usted retire la tarjeta luego de haberse registrado. Las opciones disponibles son: Bloquear Si se retira la tarjeta se bloquea la pantalla X. Ignorar No sucede nada cuando se retira la tarjeta.

62

Como funciona la inscripcin de las tarjetas inteligentes. 6. Si necesita activar el Certificado de Estado de Protocolo Online (OCSP, por las siglas en ingls de Online Certificate Status Protocol), abra el archivo /etc/pam_pkcs11/pam_pkcs11.conf y ubique la siguiente lnea: enable_ocsp = false; Modifique su valor a "true", del siguiente modo: enable_ocsp = true; 7. 8. Enrole su tarjeta inteligente. Si adems est utilizando una tarjeta CAC, tendr que realizar los siguientes pasos: a. b. Convirtase en usuario root y genere un archivo llamado /etc/pam_pkcs11/cn_map. Aada la siguiente entrada al archivo cn_map: MY.CAC_CN.123454 -> myloginid donde MY.CAC_CN.123454 es el nombre comn en su CAC y myloginid es su ID de logueo UNIX. 9. Salida

3.3.2.1. Solucin de problemas


Si se encuentra con algn inconveniente para lograr que su tarjeta inteligente funcione, intente utilizar el siguiente comando para ubicar el origen del problema.
depurador pklogin_finder

Si ejecuta la herramienta pklogin_finder en modo de depuracin, mientras una tarjeta inteligente registrada se encuentre conectada, intentar mostrar informacin acerca de los certificados vlidos, y si tiene xito, intentar mapear un ID de registro desde los certificados que existan en la tarjeta.

3.3.3. Como funciona la inscripcin de las tarjetas inteligentes.


Las tarjetas inteligentes se dice que son inscriptas cuando han recibido un certificado adecuado identificado con un Certificado de Autoridad vlido (CA, por las iniciales en ingls de Certificate Authority). Esto implica una serie de pasos, que se describen a continuacin: 1. El usuario inserta su tarjeta inteligente en el lector de tarjetas de su estacin de trabajo. Este evento es reconocido por el Cliente de Seguridad Corporativo (ESC, por las iniciales en ingls de Entreprise Security Client). 2. The enrollment page is displayed on the user's desktop. The user completes the required details and the user's system then connects to the Token Processing System (TPS) and the CA. 3. El TPS inscribe a la tarjeta inteligente utilizando un certificado firmado por CA.

63

Captulo 3. Asegurando su Red

Figura 3.4. Como funciona la inscripcin de las tarjetas inteligentes.

3.3.4. Cmo funciona el ingreso con tarjeta inteligente


En la siguiente seccin se ofrece una breve descripcin general del proceso de registro utilizando una tarjeta inteligente. 1. When the user inserts their smart card into the smart card reader, this event is recognized by the PAM facility, which prompts for the user's PIN. 2. The system then looks up the user's current certificates and verifies their validity. The certificate is then mapped to the user's UID. 3. Esto es validado en el KDC (centro de distribucin de claves de Kerberos) y el registro es autorizado.

64

Configurar Firefox para la utilizacin de Kerberos como SSO

Figura 3.5. Cmo funciona el ingreso con tarjeta inteligente

Nota
No puede registrarse con una tarjeta que no haya sido inscripta, ni siquiera aunque haya sido formateada. Necesita registrarse con una tarjeta formateada e inscripta, o no utilizar ninguna que no haya sido inscripta. Para obtener mayor informacin acerca de Kerberos y PAM, vea la Seccin 3.7, Kerberos y Seccin 3.5, Mdulos de autenticacin conectables (PAM, por las iniciales en ingls de Pluggable Authentication Modules).

3.3.5. Configurar Firefox para la utilizacin de Kerberos como SSO


Puede configurar Firefox para utilizar Kerberos para la identificacin nica SSO. Para que esta herramienta pueda funcionar correctamente, necesita configurar su navegador web para que pueda enviar sus credenciales Kerberos al KDC adecuado. En la siguiente seccin se describen las modificaciones a realizar en la configuracin, y otros requerimientos necesarios para poder utilizar correctamente esta funcionalidad. 1. En la barra de direcciones de Firefox, escriba about:config para ver una lista actualizada de las opciones de configuracin disponibles. 2. En el campo Filtro, ingrese negotiate para restringir la lista de opciones.

65

Captulo 3. Asegurando su Red 3. Haga un doble clic en la entrada network.negotiate-auth.trusted-uris para mostrar el cuadro de dilogo Ingrese valor de cadena. 4. Ingrese el nombre del dominio en el cual desea autenticarse, por ejemplo, .ejemplo.com. 5. Repita el procedimiento recin descrito para la entrada network.negotiate-auth.delegation-uris, utilizando el mismo dominio.

Nota
Puede dejar este valor vaco, ya que permite a Kerberos enviar tickets, lo que no es necesario. Si no puede ver estas dos opciones de configuracin listadas, tal vez la versin de Firefox que est utilizando sea demasiado antigua para soportar negociados de autenticacin, y debera considerar actualizarla.

Figura 3.6. Configurar Firefox para SSO con Kerberos Necesita asegurarse de poseer tickets Kerberos. En una terminal, ingrese kinit para obtenerlos. Para mostrar la lista de los tickets disponibles, ingrese klist. A continuacin se muestra un ejemplo del resultado de estos comandos:
[user@host ~] $ kinit Password for user@EXAMPLE.COM: [user@host ~] $ klist Ticket cache: FILE:/tmp/krb5cc_10920 Default principal: user@EXAMPLE.COM Valid starting Expires Service principal 10/26/06 23:47:54 10/27/06 09:47:54 krbtgt/USER.COM@USER.COM renew until 10/26/06 23:47:54 Kerberos 4 ticket cache: /tmp/tkt10920

66

Yubikey
klist: You have no tickets cached

3.3.5.1. Solucin de problemas


Si ha seguido las etapas de configuracin recin indicadas, y la negociacin de la autenticacin no funciona, puede activar la posibilidad de obtener informacin ms detallada del proceso de autenticacin. Esto podra ayudarle a encontrar la causa del problema. Para obtener ms detalles del proceso de autenticacin, utilice el siguiente procedimiento: 1. Cerrar todas las instancias de Firefox. 2. Abra una terminal, e ingrese los siguientes comandos:
export NSPR_LOG_MODULES=negotiateauth:5 export NSPR_LOG_FILE=/tmp/moz.log

3. Reinicie Firefox desde esa terminal, y visite el sitio web al que no poda autenticarse anteriormente. La informacin ser registrada en /tmp/moz.log, y podra darle alguna pista hacerca del problema. Por ejemplo:
-1208550944[90039d0]: entering nsNegotiateAuth::GetNextToken() -1208550944[90039d0]: gss_init_sec_context() failed: Miscellaneous failure No credentials cache found

Esto significa que usted no tiene tickets Kerberos, y que necesita ejecutar el comando kinit. Si puede ejecutar kinit exitosamente desde su mquina pero no puede autenticarse, debera ver algo similar a lo siguiente en el archivo log:
-1208994096[8d683d8]: entering nsAuthGSSAPI::GetNextToken() -1208994096[8d683d8]: gss_init_sec_context() failed: Miscellaneous failure Server not found in Kerberos database

Generalmente esto significa que existe un problema de configuracin de Kerberos. Asegrese de tener las entradas correctas en la seccin [domain_realm] del archivo /etc/krb5.conf. Por ejemplo:
.example.com = EXAMPLE.COM example.com = EXAMPLE.COM

Si no aparece nada en el archivo de registro, es posible que usted se encuentre detrs de un proxy, y que ese proxy est eliminando los encabezados HTTP necesarios para negociar la autenticacin. Una posible solucin a esto es intentar conectarse al servidor utilizando HTTPS, que permite a las peticiones atravesar el proxy sin modificarlas. Luego proceda a depurar utilizando el archivo de registro, como se ha explicado antes.

3.4. Yubikey
Yubikey is a hardware authentication token that utilizes open source software to operate. This token is a simple USB device that appears as a keyboard to your computer. The single touch button on the token provides a one time password (OTP) with each push that can be used to authenticate a user. Currently there are several different implementations of this solution of which we'll cover here.

67

Captulo 3. Asegurando su Red

3.4.1. Using Yubikey with a centralized server


A PAM module already exists in the Fedora repositories that allow authentication of computers that can contact an authentication server. The server can either be setup at the domain level or the Yubico's servers can be utilized. This method of authentication is a great enterprise solution where multiple users may need access to multiple computers on the domain. The steps below describe this setup. 1. 2. Install pam_yubico For two factor authentication open /etc/pam.d/gdm-password and locate the following line: auth substack password-auth In a new line after this add: auth sufficient pam_yubico.so id=16 3. 4. To simple use the yubikey token without your password remove the first line from the step above and replace it with the second. Locate the yubikey token for the first yubikey you will be adding. This can be done by looking at the first 12 characters of any OTP or visit http://radius.yubico.com/demo/Modhex_Calculator.php and copy the Modhex encoded string after you enter an OTP into the textbox on the page. Add user's yubikeys to the config file. This can be done either globally in /etc/ yubikey_mapping or by individual user in ~/.yubico/authorized_yubikeys. The following is the syntax: username:yubikey_token:another_yubikey_token 6. Logout, when you attempt to log back in you should either be prompted to enter both your password and your yubikey OTP or both depending on how you configured your system.

5.

Nota
A connection to the authentication server is required or proper authentication will not occur. This can be detrimental to systems that do not have constant network connectivity.

3.4.2. Authenticating to websites with your Yubikey


While outside the scope of this guide Yubikey allows you to authenticate to websites supporting this authentication method. These websites typically support Yubico's authentication servers but some can be setup similar to the above centralized authentication. Yubico also provides OpenID services that can be utilized with certain websites.

3.5. Mdulos de autenticacin conectables (PAM, por las iniciales en ingls de Pluggable Authentication Modules)
Programs that grant users access to a system use authentication to verify each other's identity (that is, to establish that a user is who they say they are). Histricamente, cada programa tena su propia forma de autenticar los usuarios. En Fedora, muchos programas se configuran para utilizar un mecanismo de autenticacin centralizado denominado

68

Ventajas de PAM Mdulos de Autenticacin Conectables (PAM, por las iniciales en ingls de Pluggable Authentication Modules). PAM usa una arquitectura modular, con complementos, que le da al administrador del sistema un buen grado de flexibilidad en la configuracin de las polticas de autenticacin para el sistema. En la mayora de las situaciones, la configuracin establecida por defecto del archivo PAM ser suficiente para una aplicacin que tenga soporte de PAM. Sin embargo, algunas veces, es necesario editar un archivo de configuracin de PAM. Dado que una configuracin errnea de PAM puede llegar a poner en riesgo la seguridad del sistema, es importante comprender la estructura de estos archivos antes de realizar cualquier tipo de modificacin. Para obtener ms informacin, dirjase a la Seccin 3.5.3, Formato del archivo de configuracin de PAM.

3.5.1. Ventajas de PAM


PAM ofrece las siguientes ventajas; un esquema de autenticacin comn que se puede usar en una amplia variedad de aplicaciones. flexibilidad significativa y control sobre la autenticacin para administradores del sistema y desarrolladores de aplicaciones. una nica biblioteca bien documentada que permite a los desarrolladores escribir programas sin tener que crear sus propios esquemas de autenticacin.

3.5.2. Archivos de configuracin de PAM


El directorio /etc/pam.d/ contiene los archivos de configuracin de PAM para cada aplicacin que utilice PAM. En versiones anteriores de PAM, se usaba el archivo /etc/pam.conf, pero este archivo se dejado de usar y slo se utilizar si el directorio /etc/pam.d/ no existe.

3.5.2.1. Archivos del servicio PAM


Cada aplicacin con capacidades PAM o servicio tiene un archivo en el directorio /etc/pam.d/. Cada archivo en este directorio tiene el mismo nombre del servicio al que controla el acceso. El programa que usa PAM es responsable por definir su nombre de servicio e instalar su propio archivo de configuracin PAM en el directorio /etc/pam.d/. Por ejemplo, el programa login define su nombre de servicio como login e instala el archivo de configuracin PAM /etc/pam.d/login.

3.5.3. Formato del archivo de configuracin de PAM


Cada archivo de configuracin PAM contiene un grupo de directivas formateadas como sigue:
<module interface> <control flag> <module name> <module arguments>

Cada uno de estos elementos se explica en las secciones siguientes.

3.5.3.1. Interfaz del Mdulo


Hay disponibles cuatro tipos de interfases de mdulos PAM. Cada uno corresponde a distintos aspectos del proceso de autorizacin: auth Esta interfaz de mdulo autentica el uso. Por ejemplo, pide y verifica la validez de una contrasea. Los mdulos con esta interfaz tambin pueden poner credenciales, como membresas de grupo o tickets Kerberos. 69

Captulo 3. Asegurando su Red account Esta interfaz de mdulo verifica que el acceso est permitido. Por ejemplo, puede chequear si una cuenta a vencido o si un usuario puede ingresar en una hora particular del da. password Esta interfaz de mdulo se usa para cambiar contraseas del usuario. session This module interface configures and manages user sessions. Modules with this interface can also perform additional tasks that are needed to allow access, like mounting a user's home directory and making the user's mailbox available.

Nota
Un mdulo individual puede proveer cualquiera o todas las interfases de mdulo. Por ejemplo pam_unix.so provee las cuatro interfaces de mdulo. En un archivo de configuracin PAM, la interfaz de mdulo es el primer campo definido. Por ejemplo, una lnea tpica en una configuracin puede verse como sigue:
auth required pam_unix.so

This instructs PAM to use the pam_unix.so module's auth interface.

3.5.3.1.1. Interfases de mdulos apilables


Module interface directives can be stacked, or placed upon one another, so that multiple modules are used together for one purpose. If a module's control flag uses the "sufficient" or "requisite" value (refer to Seccin 3.5.3.2, Bandera de control for more information on these flags), then the order in which the modules are listed is important to the authentication process. El apilado hace fcil para un administrador pedir que se den ciertas condiciones especficas antes de permitir al usuario autenticar. Por ejemplo, el comando reboot normalmente usa varios mdulos apilados, como se ve en su archivo de configuracin PAM:
[root@MyServer ~]# cat /etc/pam.d/reboot #%PAM-1.0 auth sufficient pam_rootok.so auth required pam_console.so #auth include system-auth account required pam_permit.so

La primera lnea es un comentario y no se procesa. auth sufficient pam_rootok.so Esta lnea usa el mdulo pam_rootok.so para verificaar si el usuario actual es root, confirmandoo que su UID sea 0. Si esto tiene xito, no se consulta ningn otro mdulo y el comando se ejecuta. Si esto falla, se consulta el mdulo siguiente. auth required pam_console.so Esta lnea utiliza el mdulo pam_console.so para intentar autenticar al usuario. Si este usuario ya se encuentra dentro de la consola, pam_console.so verifica si dentro del directorio /etc/security/console.apps/ hay un archivo con el mismo nombre que el del servicio (reboot). Si existe ese archivo, la autenticacin es existosa y el control es pasado al siguiente mdulo. #auth include system-auth Esta lnea es comentada y no se procesa.

70

Formato del archivo de configuracin de PAM account required pam_permit.so Esta lnea usa el mdulo pam_permit.so para permitir al usuario root o cualquier otro que haya ingresado en la consola reiniciar el sistema.

3.5.3.2. Bandera de control


Todos los mdulos PAM generan un resultado de xito o fracaso cuando son llamados. Las banderas de control le dicen a PAM qu hacer con el resultado. Los mdulos se pueden apilar en un orden particular, y las banderas de control determinan cun importante es el xito o el fracaso de un mdulo particular para el objetivo general de autenticacin del usuario con el servicio. Hay cuatro banderas de control predefinidas: required El resultado del mdulo debe ser exitoso para que pueda continuar la autenticacin. Si la prueba falla en este punto, el usuario no se notifica hasta que se completan con los resultados de todas las pruebas de los mdulos que referencian a esa interfaz. requisite El resultado del mdulo debe ser exitoso para que contine la autenticacin. Sin embargo, si una prueba falla en este punto, el usuario se notifica inmediatamente con un mensaje que muestra el primer fallo del mdulo required o requisite. sufficient El resultado del mdulo es ignorado si falla. Sin embargo, si el resultado de un mdulo marcado con bandera sufficient tiene xito y no hay mdulos previos marcados con required que hayan fallado, entonces no se necesitan otros resultados y el usuario es autenticado con el servicio. optional El resultado del mdulo se ignora. Un mdulo marcado como optional slo se vuelve necesario para una autenticacin exitosa cuando no hay otros mdulos referenciados en la interfaz.

Importante
El orden en el que los mdulos required se llaman no es crtico. Slo las banderas sufficient y requisite hacen que el orden se haga importante. Existe disponible ra PAM una nueva sintaxis de bandera de control, que permite un control ms preciso. The pam.d man page, and the PAM documentation, located in the /usr/share/doc/ pam-<version-number>/ directory, where <version-number> is the version number for PAM on your system, describe this newer syntax in detail.

3.5.3.3. Nombre de mdulo


El nombre del mdulo ofrece a PAM el nombre del mdulo conectable que contiene la interfaz del mdulo especificada. En versiones anteriores de Fedora la direccin completa al mdulo era provista en el archivo de configuracin de PAM. Sin embargo, desde la aparicin de los sistemas multilib, que almacenan modulos PAM de 64 bits en el directorio /lib64/security/, el nombre del directorio es omitido dado que la aplicacin est enlazada con la versin correcta de libpam, que puede encontrar la versin correcta del mdulo.

71

Captulo 3. Asegurando su Red

3.5.3.4. Argumentos del mdulo


Para algunos mdulos, PAM utiliza argumentos para pasar informacin a un mdulo conectable durante la autenticacin. Por ejemplo, el mdulo pam_userdb.so utiliza informacin almacenada en un archivo de base de datos Berkeley para autenticar al usuario. Berkeley es una base de datos de cdigo abierto que se encuentra en muchas otras aplicaciones. El mdulo toma un argumento db de modo que Berkeley sepa qu base de datos utilizar para el servicio solicitado. The following is a typical pam_userdb.so line in a PAM configuration. The <path-to-file> is the full path to the Berkeley DB database file:
auth required pam_userdb.so db=<path-to-file>

Los argumentos invlidos generalmente son ignorados y de esta manera no afectan ni el xito ni el fracaso del mdulo PAM. Algunos mdulos, sin embargo, pueden fracasar con argumentos invlidos. La mayora de los mdulos reportan sus errores en el archivo /var/log/secure.

3.5.4. Ejemplos de archivos de configuracin de PAM


La siguiente es una muestra del archivo de configuracin PAM de una aplicacin:
#%PAM-1.0 auth required pam_securetty.so auth required pam_unix.so nullok auth required pam_nologin.so account required pam_unix.so password required pam_cracklib.so retry=3 password required pam_unix.so shadow nullok use_authtok session required pam_unix.so

La primera lnea es un comentario, indicado por el numeral (#) al comienzo de la lnea. Las lneas 2 a la 4 apila tres mdulos para la autenticacin de ingreso. auth required pam_securetty.so Este mdulo asegura que si el usuario intenta ingresar como root, el tty donde el usuario est ingresando debe estar listado en el archivo /etc/ securetty, si ese archivo existe. Si el tty no est listado en el archivo, cualquier intento de loguearse como usuario root ser errneo con el siguiente mensaje: Login incorrect. auth required pam_unix.so nullok Este mdulo pide una contrasea al usuario, que luego confirma utilizando la informacin almacenada en /etc/passwd, y /etc/shadow, si es que existe. El argumento nullok le indica al mdulo pam_unix.so que permita el ingreso de una contrasea vaca. auth required pam_nologin.so Este es el ltimo momento de la autenticacin. Confirma que exista y en qu lugar, el archivo /etc/nologin. Si existe, pero el usuario no es root, la autenticacin falla.

72

Creacin de los mdulos PAM

Nota
En este ejemplo, los tres mdulos auth se encuentran verificados, an si fall el primer mdulo auth. Esto evita que los usuarios conozcan el momento exacto en que su autenticacin fall. En manos de un atacante, el conocimiento de ese dato podra permitirle deducir ms fcilmente cmo vulnerar el sistema.

account required pam_unix.so Este mdulo realiza cualquier tipo de verificacin de cuenta que sea necesario. Por ejemplo, si se ha activado el enmascaramiento de contraseas, la interfaz de la cuenta del mdulo pam_unix.so verifica que la cuenta no haya expirado, o que el usuario no haya modificado la contrasea dentro del perodo permitido. password required pam_cracklib.so retry=3 Si una contrasea ha expirado, el componente contrasea del mdulo pam_cracklib.so solicita una nueva. En seguida confirma que la nueva contrasea pueda o no ser fcilmente revelada por un programa de obtencin de contraseas basado en diccionarios. El argumento retry=3 indica que si esta prueba falla la primera vez, el usuario tiene dos oportunidades ms para crear una contrasea ms poderosa. password required pam_unix.so shadow nullok use_authtok This line specifies that if the program changes the user's password, it should use the password interface of the pam_unix.so module to do so. The argument shadow instructs the module to create shadow passwords when updating a user's password. El argumento nullok le indica al mdulo que le permita al usuario modificar su contrasea desde una contrasea en blanco. De lo contrario, una contrasea vaca ser tratada como un bloqueo de cuenta. El argumento final de esta lnea, use_authtok, ofrece un buen ejemplo de la importancia que tiene el orden en que se "apilen" los modulos PAM. Este argumento le indica al mdulo que no le solicite al usuario una nueva contrasea, y que en su lugar acepte cualquier contrasea que haya sido almacenada por un mdulo anterior. De esta manera, todas las nuevas contraseas deben pasar la prueba de pam_cracklib.so para confirmar que sean seguras antes de ser aceptadas session required pam_unix.so La lnea final le indica a la interfaz de sesin del mdulo pam_unix.so que administre la sesin. Este mdulo registra el nombre de usuario y el tipo de servicio en /var/log/secure al comienzo y al final de cada sesin. Este mdulo puede ser suplementado si se lo "apila" con otros mdulos de sesin y poder as agregarle funcionalidades.

3.5.5. Creacin de los mdulos PAM


Puede crear o aadir en cualquier momento nuevos mdulos PAM, para utilizarlos con cualquier aplicacin con tengan este soporte. Por ejemplo, un desarrollador puede crear un mtodo para generar contraseas que sean utilizadas slo una vez, y escribir un mdulo PAM que pueda soportarlo. Los programas que tengan soporte para PAM podrn utilizar inmediatamente este mdulo, y el mtodo de contrasea, sin por ello tener que ser recompilados o modificados en alguna manera.

73

Captulo 3. Asegurando su Red Esto permite a los desarrolladores y a los administradores de sistema mezclar, y al mismo tiempo verificar, diferentes mtodos de autenticacin para diferentes programas sin necesidad de recompilarlos. Documentation on writing modules is included in the /usr/share/doc/pam-<version-number>/ directory, where <version-number> is the version number for PAM on your system.

3.5.6. PAM y el cacheo de la credencial administrativa


Una cantidad de herramientas administrativas grficas en Fedora le ofrecen a los usuarios un elevado grado de privilegio, durante un perodo de tiempo de hasta cinco minutos, utilizando el mdulo pam_timestamp.so. Es importante entender como funciona este mecanismo, ya que si algn usuario abandona la terminal mientras continue vigente pam_timestamp.so, dejar a ese equipo libre para ser manipulado por quienquiera que tenga acceso fsico a la consola. En el esquema del registro del tiempo de PAM, cuando es iniciada la aplicacin administrativa grfica, solicita al usuario la contrasea de root. Cuando el usuario ha sido autenticado, el mdulo pam_timestamp.so crea un archivo de registro de tiempo. Por defecto, es creado en el directorio /var/run/sudo/. Si el archivo ya existe, los programas administrativos grficos no solicitarn una contrasea. En su lugar, el mdulo pam_timestamp.so actualizar el archivo de registro de tiempo, reservando cinco minutos extra de acceso administrativo sin contraseas al usuario. You can verify the actual state of the timestamp file by inspecting the /var/run/sudo/<user> file. For the desktop, the relevant file is unknown:root. If it is present and its timestamp is less than five minutes old, the credentials are valid. La existencia del archivo de registro de tiempo se indica mediante un cono de autenticacin, que aparece en el rea de notificacin del panel.

Figura 3.7. El cono de autenticacin

3.5.6.1. Borrando el archivo de registro de tiempo


Antes de abandonar la consola donde se encuentra activo el registro de tiempo de PAM, es recomendable destruir el archivo correspondiente. Para hacerlo desde un entorno grfico, haga clic sobre el cono de autenticacin del panel. Esto hace que se abra un cuadro de dilogo. Haga clic sobre el botn Olvidar Autenticacin para destruir el archivo de registro de tiempo activo.

Figura 3.8. Dilogo de olvidar autenticacin Con respecto al archivo de registro de tiempo de PAM, debe prestarle atencin a lo siguiente: Si ha ingresado en el sistema remotamente, utilizando el comando ssh, utilice el comando /sbin/ pam_timestamp_check -k root para destruir el archivo de registro de tiempo. 74

PAM y la propiedad de los dispositivos Ser necesario que ejecute el comando /sbin/pam_timestamp_check -k root desde la misma ventana de la terminal desde la que inici la aplicacin con este privilegio. Debe estar registrado como el usuario que originalmente invoc el mdulo pam_timestamp.so, de modo de poder utilizar el comando /sbin/pam_timestamp_check -k. No se registre como usuario root para utilizarlo. Si quiere abandonar las credenciales en el escritorio (sin utilizar la accin Olvidar Autenticacin del cono), utilice el siguiente comando:
/sbin/pam_timestamp_check -k root </dev/null >/dev/null 2>/dev/null

Una falla al utilizar este comando har que solo sean eliminadas las credenciales (en el caso que las hubiera) del pty desde donde ejecut el comando. Consulte la pgina man pam_timestamp_check para obtener ms informacin acerca del uso de pam_timestamp_check para destruir el archivo de registro de tiempo.

3.5.6.2. Directivas comunes de pam_timestamp_check


El mdulo pam_timestamp.so acepta varias indicaciones. Las siguientes dos opciones son algunas de las ms utilizadas: timestamp_timeout Especifica el periodo (en segundos) durante el cual el archivo de registro de tiempo es vlido. El valor establecido por defecto es 300 (cinco minutos). timestampdir Indica el directorio en donde el archivo de registro de tiempo ser almacenado. El valor establecido por defecto es /var/run/sudo/. Vea la Seccin 3.8.9.1, Documentacin instalada del cortafuego para obtener mayor informacin acerca del control del mdulo pam_timestamp.so.

3.5.7. PAM y la propiedad de los dispositivos


En Fedora, el primer usuario que se registra en la consola fsica de la mquina, puede manipular ciertos dispositivos y realizar ciertas tareas que por lo general son reservadas al usuario root. Esto es controlado por un mdulo PAM denominado pam_console.so.

3.5.7.1. Propiedad de los dispositivos


Cuando un usuario se registra en un sistema Fedora, el mdulo pam_console.so es llamado mediante el comando login, o mediante algunos de los programa grficos de registro, como ser gdm, kdm, y xdm. Si este usuario es el primero en registrarse en la consola fsica denominada consola del usuario el modulo le asegura al usuario el dominio de una gran variedad de dispositivos que normalmente le pertenecen al usuario root. Estos dispositivos le pertenecen a la consola del usuario hasta que finalice su ltima sesin local. Una vez que este usuario haya finalizado su sesin, la pertenencia de los dispositivos vuelve a ser del usuario root. Los dispositivos afectados incluyen, pero no se limitan a, las placas de sonido, disqueteras, lectoras de CD-ROM. Esta instalacin permite al usuario local manipular estos dispositivos sin obtener el acceso de root, por lo que se simplifican las tareas comunes para el usuario de consola. Puede modificar la lista de dispositivos controlados por pam_console.so editando los siguientes archivos: /etc/security/console.perms 75

Captulo 3. Asegurando su Red /etc/security/console.perms.d/50-default.perms Puede cambiar los permisos de los otros dispositivos diferentes, adems de los que se han mostrado antes, o modificar los especificados por defecto. En lugar de modificar el archivo 50default.perms, debera crear uno nuevo (por ejemplo xx-name.perms) y luego ingresar las modificaciones requeridas. El nombre del nuevo archivo modelo debe comenzar con un nmero superior a 50 (por ejemplo 51-default.perms). Esto va a sustituir lo indicado en el archivo 50default.perms.

Advertencia
If the gdm, kdm, or xdm display manager configuration file has been altered to allow remote users to log in and the host is configured to run at runlevel 5, it is advisable to change the <console> and <xconsole> directives in the /etc/security/console.perms to the following values:
<console>=tty[0-9][0-9]* vc/[0-9][0-9]* :0\.[0-9] :0 <xconsole>=:0\.[0-9] :0

Esto evita que los usuarios ganen acceso a dispositivos y aplicaciones restringidas en la mquina. If the gdm, kdm, or xdm display manager configuration file has been altered to allow remote users to log in and the host is configured to run at any multiple user runlevel other than 5, it is advisable to remove the <xconsole> directive entirely and change the <console> directive to the following value:
<console>=tty[0-9][0-9]* vc/[0-9][0-9]*

3.5.7.2. Acceso a aplicaciones


El usuario de la consola tambin tiene el acceso a ciertos programas configurados para usar el directorio /etc/security/console.apps/. Este directorio contiene los archivos de configuracin que habilitan al usuario de la consola correr ciertas aplicaciones de /sbin y /usr/sbin. Estos archivos de configuracin tienen el mismo nombre de las aplicaciones que configuran. Un grupo notable de aplicaciones a los que el usuario de consola tiene acceso son tres programas que apagan o reinician el sistema: /sbin/halt /sbin/reboot /sbin/poweroff Debido a que estas aplicaciones utilizan PAM, llaman al mdulo pam_console.so como un requisito para usarlas. Dirjase a la Seccin 3.8.9.1, Documentacin instalada del cortafuego para obtener mayor informacin.

76

Recursos adicionales

3.5.8. Recursos adicionales


Los siguientes recursos explican ms detalladamente los mtodos para usar y configurar PAM. Adems de estos recursos, lea los archivos de configuracin de PAM en el sistema para entender mejor cmo estn estructurados.

3.5.8.1. Documentacin de PAM instalada


Las pginas man relacionadas con PAM Hay varias pginas man para las distintas aplicaciones y archivos de configuracin involucrados con PAM. La siguiente es un alista de alguna de las pginas man ms importantes. Archivos de configuracin pam Buena informacin de presentacin de PAM, que incluye la estructura y propsito de los archivos de configuracin de PAM. Tenga en cuenta que en esta pgina man se hace referencia tanto al archivo /etc/ pam.conf como a los archivos de configuracin individuales del directorio /etc/pam.d/. Por defecto, Fedora utiliza los archivos de configuracin individual del directorio, ignorando el archivo /etc/pam.conf, an si efectivamente existe. pam_console Describe el propsito del mdulo pam_console.so. Tambin describe la sintaxis apropiada para una entrada dentro del archivo de configuracin de PAM. console.apps Describe el formato del archivo de configuracin /etc/security/ console.apps, que define qu aplicaciones son accesibles por el usuario de consola asignado por PAM. console.perms Describe el formato del archivo de configuracin /etc/security/ console.perms, que especifica los permisos del usuario de consola asignados por PAM. pam_timestamp Describe el mdulo pam_timestamp.so. /usr/share/doc/pam-<version-number> Contains a System Administrators' Guide, a Module Writers' Manual, and the Application Developers' Manual, as well as a copy of the PAM standard, DCE-RFC 86.0, where <version-number> is the version number of PAM. /usr/share/doc/pam-<version-number>/txts/README.pam_timestamp Contains information about the pam_timestamp.so PAM module, where <version-number> is the version number of PAM.

3.5.8.2. Sitios web tiles sobre PAM


http://www.kernel.org/pub/linux/libs/pam/ El sitio web principal de distribucin del proyecto LinuxPAM, que contiene informacin relacionada con varios mdulos PAM, una seccin con respuestas a las preguntas ms usuales (FAQ, por las siglas en ingls de Frequently Asked Questions), y documentacin adicional acerca de PAM.

77

Captulo 3. Asegurando su Red

Nota
La documentacin en el sitio web recin mencionado corresponde a la ltima versin de desarrollo lanzada de PAM y puede no ser 100% precisa para la versin de PAM incluida en Fedora.

3.6. Encapsuladores TCP y xinetd


Controlling access to network services is one of the most important security tasks facing a server administrator. Fedora provides several tools for this purpose. For example, an iptables-based firewall filters out unwelcome network packets within the kernel's network stack. For network services that utilize it, TCP Wrappers add an additional layer of protection by defining which hosts are or are not allowed to connect to "wrapped" network services. One such wrapped network service is the xinetd super server. This service is called a super server because it controls connections to a subset of network services and further refines access control. Figura 3.9, Control de acceso a servicios de red es una ilustracin bsica acerca de cmo estas herramientas trabajan conjuntamente para proteger los servicios de red.

78

Encapsuladores TCP

Figura 3.9. Control de acceso a servicios de red El siguiente captulo se concentra en el papel que tienen de los encapsuladores TCP y xinetd al controlar acceso a los servicios de red, y analiza de qu manera estas herramientas pueden ser utilizadas para mejorar tanto el registro como la administracin de su utilizacin. Para obtener mayor informacin utilizando cortafuegos con iptables, vea la Seccin 3.9, IPTables.

3.6.1. Encapsuladores TCP


El paquete de los encapsuladores TCP (tcp_wrappers) se encuentra instalado por defecto y ofrece control de acceso a los servicios de red basado en los equipos. El componente ms importante de este paquete es la biblioteca /usr/lib/libwrap.a. En trminos generales, un servicio encapsulado por TCP es un servicio que ha sido compilado con la biblioteca libwrap.a. When a connection attempt is made to a TCP-wrapped service, the service first references the host's access files (/etc/hosts.allow and /etc/hosts.deny) to determine whether or not the client is allowed to connect. In most cases, it then uses the syslog daemon (syslogd) to write the name of the requesting client and the requested service to /var/log/secure or /var/log/messages. Si un cliente tiene permitida la conexin, los encapsuladores TCP liberan el control de la conexin al servicio solicitado, y abandonan el proceso de comunicacin entre el cliente y el servidor. Adems del control de acceso y registro, los encapsuladores TCP pueden ejecutar comandos para interactuar con el cliente antes que sea negado el control de la conexin, o antes de abandonar el proceso de conexin al servicio de red solicitado. 79

Captulo 3. Asegurando su Red Because TCP Wrappers are a valuable addition to any server administrator's arsenal of security tools, most network services within Fedora are linked to the libwrap.a library. Some such applications include /usr/sbin/sshd, /usr/sbin/sendmail, and /usr/sbin/xinetd.

Nota
Para determinar si un servicio de red ejecutable est enlazado con libwrap.a, ingrese el siguiente comando como usuario root:
ldd <binary-name> | grep libwrap

Replace <binary-name> with the name of the network service binary. Si el comando no le devuelve ninguna informacin, entonces el servicio de red no se encuentra enlazado con libwrap.a. El siguiente ejemplo inidica que /usr/sbin/sshd se encuentra enlazado con libwrap.a:
[root@myServer ~]# ldd /usr/sbin/sshd | grep libwrap libwrap.so.0 => /lib/libwrap.so.0 (0x00655000) [root@myServer ~]#

3.6.1.1. Ventajas de los Encapsuladores TCP


Los encapsuladores TCP ofrecen las siguientes ventajas en comparacin con otras tcnicas para el control de servicios de red: Transparencia tanto para el cliente como para el servicio de red encapuslado Tanto el cliente que est conectndose como el servicio de red, no tienen conocimiento de que los encapsuladores TCP estn siendo utilizados. Los usuarios legtimos se registran y conectan a los servicios solicitados, mientras que no se realizan las conexiones pedidas por clientes no autorizados. Administracin centralizada de mltiples protocolos los encapsuladores TCP operan en forma separada de los servicios de red que protegen, permitiendo as que varias aplicaciones de servidor compartan un conjunto comn de archivos de configuracin de control de acceso, haciendo posible que la administracin sea ms sencilla.

3.6.2. Archivos de configuracin de los encapsuladores TCP


Para determinar si a un cliente le es permitido conectarse a un servidor, los encapsuladores TCP consultan los dos archivos siguientes, comnmente denominados archivos de acceso de equipos: /etc/hosts.allow /etc/hosts.deny Cuando un servicio encapsulado por TCP recibe una peticin de un cliente, realiza los siguientes pasos: 1. Consulta con /etc/hosts.allow. El servicio encapsulado por TCP analiza secuencialmente el archivo /etc/hosts.allow y aplica la primera regla especificada para ese servicio. Si encuentra una regla concordante, permite la conexin. Si no, avanza al siguiente paso.

80

Archivos de configuracin de los encapsuladores TCP 2. Consulta con /etc/hosts.deny. El servicio encapsulado por TCP analiza secuencialmente el archivo /etc/hosts.deny. Si encuentra una regla concordante, niega la conexin. Si no, permite el acceso al servicio. Las siguientes son cuestiones importantes para considerar cuando se utilice encapsuladores TCP para proteger servicios de red: Debido a que primero se aplican las reglas de acceso contenidas en hosts.allow, dejan un precedente sobre las reglas especificadas en hosts.deny. De este modo, si el acceso a un servicio es permitido en hosts.allow, ser ignorada una regla negando el acceso al mismo servicio del archivo hosts.deny. Las reglas de cada archivo son ledas desde arriba hacia abajo, y la primera regla concordante para un servicio dado es la nica que ser aplicada. El orden de las reglas es extremadamente importante. Si no se encuentran reglas para el servicio en el archivo, o el archivo no existe, el acceso al servicio es permitido. Los servicios encapsulados por TCP no conservan las reglas desde los archivos de acceso de los equipos, de modo que cualquier cambio en hosts.allow o hosts.deny, tienen efecto inmediato, sin necesidad de reiniciar los servicios de red.

Advertencia
Si la ltima lnea del archivo de acceso de un equipo no es un caracter de tipo nueva lnea (creado al presionar la tecla Enter key), la ltima regla del archivo fallar y un error ser registrado o bien en /var/log/messages, o bien en /var/log/secure. Este es el mismo caso de una regla que abarca lneas mltiples sin utilizar el carcater de lnea invertida. El siguiente ejemplo muestra la seccin que nos interesa del fracaso de una regla debido a alguna de las circunstancias recin descritas:
warning: /etc/hosts.allow, line 20: missing newline or line too long

3.6.2.1. Formateo de las reglas de acceso


El formato tanto de /etc/hosts.allow como de /etc/hosts.deny es el mismo. Cada regla debe estar en su propia lnea. Lneas vacas o lneas que empiezan con el smbolo numeral (#) son ignoradas. Cada regla utiliza el siguiente formato bsico para controlar el acceso a los servicios de red:
<daemon list>: <client list> [: <option>: <option>: ...]

<daemon list> A comma-separated list of process names (not service names) or the ALL wildcard. The daemon list also accepts operators (refer to Seccin 3.6.2.1.4, Operadores) to allow greater flexibility. <client list> A comma-separated list of hostnames, host IP addresses, special patterns, or wildcards which identify the hosts affected by the rule. The client list also accepts operators listed in Seccin 3.6.2.1.4, Operadores to allow greater flexibility.

81

Captulo 3. Asegurando su Red <option> An optional action or colon-separated list of actions performed when the rule is triggered. Option fields support expansions, launch shell commands, allow or deny access, and alter logging behavior.

Nota
Puede encontrarse mayor informacin acerca de los trminos recin vistos en otras partes de esta Gua: Seccin 3.6.2.1.1, Comodines Seccin 3.6.2.1.2, Patrones Seccin 3.6.2.2.4, Expansiones Seccin 3.6.2.2, Campos de opcin A continuacin se muestra el ejemplo de una regla bsica de acceso de equipos:
vsftpd : .example.com

Esta regla est indicando a los encapsuladores TCP que observen las conexiones del demonio FTP (vsftpd) desde cualquier equipo en el dominio ejemplo.com. Si esta regla aparece en hosts.allow, la conexin es aceptada. Si esta regla figura en hosts.deny, la conexin es negada. El siguiente ejemplo de regla de acceso de equipos es ms compleja y utiliza dos campos de opciones:
sshd : .example.com deny \ : spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \ :

Fjese que cada campo de opcin es precedido por la barra invertida (\). La utilizacin de esta barra previene el fallo de la regla debido a su longitud. Esta regla de ejemplo establece que si se intenta establecer una conexin con el demonio SSH (sshd) desde algn equipo del dominio ejemplo.com, sea ejecutado el comando echo para aadir dicho intento en un archivo especial de registro, y negar la conexin. Debido a que la directiva opcional deny es utilizada, esta lnea niega el acceso an si figura en el archivo hosts.allow. Para conocer en detalle otras opciones disponibles, vea la Seccin 3.6.2.2, Campos de opcin.

3.6.2.1.1. Comodines
Los comodines le permiten a los encapsuladores TCP poder corresponderse ms fcilmente con grupos de demonios de equipos. Son ms frecuentemente utilizados en el campo lista de cliente de las reglas de acceso. Los siguientes comodines estn disponibles: ALL Se corresponde con todo. Puede ser utilizado tanto para la lista del demonio como con la lista del cliente. LOCAL Se corresponde con cualquier equipo que no contenga un punto (.), como por ejemplo el equipo local.

82

Archivos de configuracin de los encapsuladores TCP KNOWN Se corresponde con cualquier equipo cuyo nombre y la direccin sean conocidas o donde el usuario sea conocido. UNKNOWN Se corresponde con cualquier equipo cuyo nombre o direccin sean desconocidos, o donde el usuario sea desconocido. PARANOID Se corresponde con cualquier equipo cuyo nombre no concuerde con su direccin.

Importante
Los comodines KNOWN, UNKNOWN, y PARANOID deben ser utilizados con cuidado, ya que dependen del servidor DNS que se est utilizando para su operacin correcta. Cualquier interrupcin de la resolucin de nombres podra causar que se les niegue acceso al servicio a los usuarios legtimos.

3.6.2.1.2. Patrones
Pueden utilizarse patrones en el campo cliente de las reglas de acceso para especificar grupos de equipos de clientes en forma ms precisa. A continuacin mostramos una lista con patrones comunes para entradas en el campo cliente: Nombre de equipo empezando con un punto (.) Colocar un punto al comienzo del nombre de un equipo hace que se correspondan todos los equipos que comparten los componentes del nombre en la lista. El siguiente ejemplo se aplica a cualquier equipo dentro del dominio ejemplo.com:
ALL : .example.com

Direccin IP que finaliza con un punto (.) Colocar un punto al finalizar una direccin IP hace que se correspondan todos los equipos que comparten los grupos numricos iniciales de una direccin IP. El siguiente ejemplo se aplica a cualquier equipo dentro de la red 192.168.x.x:
ALL : 192.168.

Direccin IP/par de mscara de red Las expresiones de mscaras de red tambin pueden utilizarse como un patrn para controlar el acceso de un grupo determinado de direcciones IP. El siguiente ejemplo se aplica a cualquier equipo con un rango de direcciones desde 192.168.0.0 hasta 192.168.1.255:
ALL : 192.168.0.0/255.255.254.0

Importante
Cuando se est trabajando en el espacio de direcciones IPv4, la longitud del par direccin/ prefijo (prefixlen) en las declaraciones (notacin CIDR) no estn soportadas. Solo las reglas IPv6 pueden utilizar este formato.

83

Captulo 3. Asegurando su Red [direcciones IPv6]/par prefixlen los pares [red]/prefixlen tambin pueden ser utilizados como un patrn para controlar el acceso de un grupo determinado de direcciones IPv6. El siguiente ejemplo se aplica a cualquier equipo en un rango de 3ffe:505:2:1:: hasta 3ffe:505:2:1:ffff:ffff:ffff:ffff:
ALL : [3ffe:505:2:1::]/64

El asterisco (*) Los asteriscos pueden ser utilizados para hacer concordar grupos enteros de nombres de equipos o direcciones IP, siempre y cuando no estn mezclados en listas de clientes que contengan otro tipo de patrones. El siguiente ejemplo se puede aplicar a cualquier equipo dentro del dominio ejemplo.com:
ALL : *.example.com

La barra (/) Si una lista de cliente comienza con una barra, ser tratada como un nombre de archivo. Esto es til si se necesitan reglas especificando grandes cantidades de equipos. El siguiente ejemplo referencia encapsuladores TCP al archivo /etc/telnet.hosts para todas las conexiones Telnet.
in.telnetd : /etc/telnet.hosts

Existen otros patrones menos utilizados que tambin aceptan los encapsuladores TCP. Para obtener mayor informacin, vea la pgina man 5 de hosts_access.

Advertencia
Sea muy cuidadoso al utilizar nombres de equipos y de dominios. Los atacantes pueden utilizar una gran variedad de trucos para sortear dificultades y obtener resoluciones de nombres adecuadas. Adems, la interrupcin del servicio DNS impide la utilizacin de los servicios de red incluso a los usuarios autorizados. De modo que, lo mejor es utilizar direcciones IP siempre que sea posible.

3.6.2.1.3. Portmap y encapsuladores TCP


Portmap's implementation of TCP Wrappers does not support host look-ups, which means portmap can not use hostnames to identify hosts. Consequently, access control rules for portmap in hosts.allow or hosts.deny must use IP addresses, or the keyword ALL, for specifying hosts. Los cambios en las reglas de control de acceso de portmap podran no tener efecto inmediatamente. Tal vez necesite reiniciar el servicio portmap. Servicios muy utilizados, como NIS o NFS, dependen de portmap para funcionar, de modo que tenga en cuenta estas limitaciones.

3.6.2.1.4. Operadores
Hoy en da, las reglas de control de acceso aceptan un operador, EXCEPT. Puede ser utilizado tanto en la lista de demonio como en la lista cliente de una regla. El operador EXCEPT permite excepciones especficas para ampliar las correspondencias dentro de una misma regla.

84

Archivos de configuracin de los encapsuladores TCP En el siguiente ejemplo de un archivo hosts.allow, todos los equipos ejemplo.com tienen permitido conectarse a todos los servicios, exepcto cracker.ejemplo.com:
ALL: .example.com EXCEPT cracker.example.com

En otro ejemplo de un archivo hosts.allow, los clientes de la red 192.168.0.x pueden utilizar todos los servicios con excepcin de FTP:
ALL EXCEPT vsftpd: 192.168.0.

Nota
En trminos de organizacin, generalmente es ms sencillo evitar la utilizacin de operadores EXCEPT. Esto permite que otros administradores analicen rpidamente los archivos apropiados para ver a qu equipos se les permite o se les niega el acceso a los servicios, sin tener que organizar los operadores EXCEPT.

3.6.2.2. Campos de opcin


Adems de las reglas bsicas que permiten o que niegan el acceso, la implementacin de encapsuladores TCP de Fedora soporta extensiones al lenguaje de control de acceso a travs de campos de opcin. Al utilizar los campos de opcin en reglas de acceso de equipos, los administradores pueden realizar una variedad de tareas, como por ejemplo, modificar el comportamiento de los registros, consolidar control de acceso e iniciar comandos de terminal.

3.6.2.2.1. Registro
Los campos de opcin permiten que los administradores modifiquen fcilmente la herramienta de registro y el nivel de prioridad para una regla, utilizando la directiva severity. En el siguiente ejemplo, las conexiones con el demonio SSH desde cualquier equipo del dominio ejemplo.com son registradas en la herramienta authpriv syslog establecida por defecto (debido a que ningn valor de la herramienta es especificado) con una prioridad de emerg:
sshd : .example.com : severity emerg

Es tambin posible especificar una herramienta utilizando la opcin severity. El siguiente ejemplo registra cualquier intento de conexin SSH realizada por equipos del dominio ejemplo.com a la herramienta local0, con una prioridad de alert:
sshd : .example.com : severity local0.alert

85

Captulo 3. Asegurando su Red

Nota
En la prctica, este ejemplo no funciona hasta que el demonio syslog (syslogd) sea configurado para registrarse en la herramienta local0. Para obtener mayor informacin acerca de cmo configurar herramientas de registro establecidas por defecto, vea la pgina man de syslog.conf.

3.6.2.2.2. Control de acceso


Los campos de opcin tambin le permiten a los administradores permitir o negar explcitamente equipos mediante una sola regla, aadindole la directiva allow o deny como la opcin final. Por ejemplo, las dos reglas siguientes permiten conexions SSH desde client-1.example.com, pero niegan conexiones de client-2.example.com:
sshd : client-1.example.com : allow sshd : client-2.example.com : deny

Al permitir control de acceso sobre un fundamento de reglas, el campo de opcin permite que los administradores consoliden todas los reglas de acceso en un solo archivo: o bien hosts.allow, o bien hosts.deny. Algunos administradores consideran a esto como una forma sencilla de organizar las reglas de acceso.

3.6.2.2.3. Comandos de la consola


Los campos de opcin permiten reglas de acceso para iniciar comandos de consola mediante las dos directivas siguientes: spawn Inicia un comando de terminal como un proceso hijo. Esta directiva puede realizar tareas como ser la utilizacin de /usr/sbin/safe_finger para obtener mayor informacin acerca del cliente que est realizando una determinada peticin, o crear archivos de registro especiales mediante la utilizacin del comando echo. En el siguiente ejemplo, los clientes del dominio ejemplo.com que intentan acceder a servicios Telnet, son registrados silenciosamente en un archivo especial:
in.telnetd : .example.com \ : spawn /bin/echo `/bin/date` from %h>>/var/log/telnet.log \ : allow

twist Replaces the requested service with the specified command. This directive is often used to set up traps for intruders (also called "honey pots"). It can also be used to send messages to connecting clients. The twist directive must occur at the end of the rule line. En el ejemplo siguiente, a los clientes que intentan acceder a los servicios FTP desde el dominio ejemplo.com, se les enva un mensaje utilizando el comando echo.
vsftpd : .example.com \ : twist /bin/echo "421 This domain has been black-listed. Access denied!"

Para obtener mayor informacin acerca de las opciones de comandos de terminal, vea la pgina man de hosts_options.

86

Archivos de configuracin de los encapsuladores TCP

3.6.2.2.4. Expansiones
Cuando se utilizan junto a las directivas spawn y twist, las expansiones proveen informacin acerca del cliente, servidor, y los procesos involucrados. La siguiente es una lista de expansiones soportadas: %a Returns the client's IP address. %A Returns the server's IP address. %c Informa una gran cantidad de datos del cliente, como ser por ejemplo, el nombre de usuario y el nombre del equipo, o el nombre de usuario y la direccin IP. %d Informa el nombre del demonio encargado del proceso. %h Returns the client's hostname (or IP address, if the hostname is unavailable). %H Returns the server's hostname (or IP address, if the hostname is unavailable). %n Returns the client's hostname. If unavailable, unknown is printed. If the client's hostname and host address do not match, paranoid is printed. %N Returns the server's hostname. If unavailable, unknown is printed. If the server's hostname and host address do not match, paranoid is printed. %p Returns the daemon's process ID. %s Informa diferentes tipos de datos acerca del servidor, como ser por ejemplo, si el proceso del demonio y la direccin del equipo o direccin IP del servidor. %u Returns the client's username. If unavailable, unknown is printed. La siguiente regla de ejemplo utiliza una expansin junto con el comando spawn para identificar el equipo del cliente en un archivo de registro modificado. Cuando se intenten establecer conexiones al demonio SSH (sshd) desde un equipo del dominio ejemplo.com, ejecute el comando echo para registrar el intento en un archivo especial, incluyendo el nombre del cliente (utilizando la expancin %h).
sshd : .example.com \ : spawn /bin/echo `/bin/date` access denied to %h>>/var/log/sshd.log \ : deny

De manera similar, las expansiones pueden ser utilizadas para personalizar mensajes enviados al cliente. En el siguiente ejemplo, a los clientes que intentan acceder a servicios FTP desde el dominio ejemplo.com, se les informa que han sido eliminados del servidor:
vsftpd : .example.com \ : twist /bin/echo "421 %h has been banned from this server!"

Para obtener una explicacin completa de las expansiones disponibles, y al mismo tiempo conocer opciones adicionales de control de acceso, vea la seccin 5 de las pginas man de hosts_access (man 5 hosts_access), y la pgina man de hosts_options. Para obtener mayor informacin acerca de los encapsuladores TCP, vea la Seccin 3.6.5, Recursos adicionales. 87

Captulo 3. Asegurando su Red

3.6.3. xinetd
El demonio xinetd es un sper servicio encapsulado por TCP, que controla el acceso a un subconjunto de servicios de red muy utilizados, como por ejemplo FTP, IMAP y Telnet. Tambin ofrece opciones de configuracin de servicio especficas para control de acceso, registros mejorados, uniones, redirecciones y control de la utilizacin de los recursos. Cuando un cliente intenta conectarse a un servicio de red controlado por xinetd, el sper servicio recibe la peticin y verifica la existencia de reglas de control de acceso para encapsuladores TCP. Si el acceso es permitido, xinetd verifica que la conexin sea permitida bajo sus propias reglas de acceso para ese servicio. Tambin verifica que el servicio pueda tener ms recursos disponibles, y que no est en contradiccin con ninguna otra regla definida. Si todas estas condiciones se cumplen (es decir, el acceso al servicio es permitido; el servicio no ha alcanzado el lmite de sus recursos; y el servicio no entra en colisin con ninguna otra regla definida), entonces xinetd inicia una instancia del servicio solicitado y le pasa el control de la conexin. Luego que la conexin haya sido establecida, xinetd deja de formar parte en la comunicacin entre el cliente y el servidor.

3.6.4. Archivos de configuracin de xinetd


Los archivos de configuracin para xinetd son los siguientes: /etc/xinetd.conf El archivo de configuracin general de xinetd. /etc/xinetd.d/ El directorio continente de todos los archivos especficos para cada servicio.

3.6.4.1. El archivo /etc/xinetd.conf


The /etc/xinetd.conf file contains general configuration settings which affect every service under xinetd's control. It is read when the xinetd service is first started, so for configuration changes to take effect, you need to restart the xinetd service. The following is a sample /etc/xinetd.conf file:
defaults { instances log_type log_on_success log_on_failure cps } includedir /etc/xinetd.d

= = = = =

60 SYSLOG authpriv HOST PID HOST 25 30

Estas lineas controlan los siguientes aspectos de xinetd: instances Indica el nmero mximo de peticiones simultneas que puede procesar xinetd. log_type Configura xinetd para utilizar la herramienta de registro authpriv, que guarda entradas de registro en el archivo /var/log/secure. Agregar una directiva como FILE /var/ log/xinetdlog podra crear un archivo de registro modificado denominado xinetdlog en el directorio /var/log/. log_on_success Configures xinetd to log successful connection attempts. By default, the remote host's IP address and the process ID of the server processing the request are recorded. log_on_failure Configura xinetd para registrar intentos de conexin fallidos, o casos en que la conexin fue negada. 88

Archivos de configuracin de xinetd cps Configura xinetd para permitir ms de 25 conexiones por segundo hacia cualquier servicio dado. Si el lmite es superado, el servicio se retira durante 30 segundos. includedir /etc/xinetd.d/ Incluye opciones declaradas en los archivos de configuracin propios de cada servicio, ubicados en el directorio /etc/xinetd.d/. Para obtener mayor infirmacin, consulte Seccin 3.6.4.2, El directorio /etc/xinetd.d/.

Nota
Often, both the log_on_success and log_on_failure settings in /etc/xinetd.conf are further modified in the service-specific configuration files. More information may therefore appear in a given service's log file than the /etc/xinetd.conf file may indicate. Refer to Seccin 3.6.4.3.1, Opciones para registrado for further information.

3.6.4.2. El directorio /etc/xinetd.d/


El directorio /etc/xinetd.d/ contiene los archivos de configuracin para cada servicio administrado por xinetd, y los nombres de los archivos correspondientes al servicio. Del mismo modo que con xinetd.conf, este directorio es de solo lectura cuando el servicio xinetd es iniciado. Para que cualquier cambio pueda tener efecto, el administrador debe reiniciar el servicio xinetd. El formato de los archivos en el directorio /etc/xinetd.d/ utiliza las mismas convenciones que / etc/xinetd.conf. La principal razn por la que la configuracin de cada servicio sea almacenada en un archivo diferente, es para hacer ms sencilla la personalizacin, y menos propensa a modificar otros servicios. Para adquirir una mejor comprensin acerca de cmo estn estructurados estos archivos, prestele atencin al archivo /etc/xinetd.d/krb5-telnet:
service telnet { flags socket_type wait user server log_on_failure disable }

= REUSE = stream = no = root = /usr/kerberos/sbin/telnetd += USERID = yes

Estas lneas controlan numerosos aspectos del servicio telnet: service Especifica el nombre del servicio, generalmente uno de aquellos listados en el archivo /etc/services flags Establece alguno de los atributos para la conexin. REUSE le indica a xinetd que vuelva a utilizar el socket para una conexin Telnet.

89

Captulo 3. Asegurando su Red

Nota
La marca REUSE es obsoleta. Todos los servicios hoy en da utilizan la marca REUSE.

socket_type Establece el tipo de socket de red a stream. wait Especifica cuando el servicio es tratado como de uno solo hilo de ejecucin (yes) o como de mltiples hilos de ejecucin (no). user Especifica bajo qu ID de usuario se est ejecutando el proceso. server Especifica el binario ejecutable a ser lanzado. log_on_failure Especifica parmetros de registro para log_on_failure, adems de los que ya estn definidos en xinetd.conf. disable Especifica cundo el servicio debe ser desactivado (yes), o activado (no). Para obtener mayor informacin sobre estas opciones y su uso, consulte la pgina man de xinetd.conf.

3.6.4.3. Alteracin de los archivos de configuracin de xinetd


Existen disponibles una variedad de directivas protegidas por xinetd. En esta seccin se detallan algunas de las opciones ms comunmente utilizadas.

3.6.4.3.1. Opciones para registrado


Las siguientes opciones de registro se encuentran disponibles tanto para /etc/xinetd.conf como para los archivos de configuracin del servicio especfico en el directorio /etc/xinetd.d/. La siguiente es una lista de las opciones de registro ms utilizadas: ATTEMPT Registra el hecho de haberse realizado un intento fallido (log_on_failure). DURATION Registra el perodo de tiempo total en que ha sido utilizado el servicio por un sistema remoto (log_on_success). EXIT Registra el estado de salida, o la seal de finalizacin del servicio (log_on_success). HOST Logs the remote host's IP address (log_on_failure and log_on_success). PID Registra el ID de los procesos del servidor que recibe el pedido (log_on_success). USERID Registra a los usuarios remotos que utilizan el mtodo definido en RFC 1413 para todos los servicios stream de aspectos mltiples (log_on_failure ylog_on_success). Para obtener una lista completa de opciones de registro, consulte la pgina man de xinetd.conf.

3.6.4.3.2. Opciones para el control de acceso


Los usuarios de los servicios xinetd pueden elegir entre utilizar las reglas de acceso de los equipos con encapsuladores TCP, o proveer control de acceso mediante los archivos de configuracin de

90

Archivos de configuracin de xinetd xinetd, o una mezcla de ambos. Para obtener mayor informacin acerca del control de acceso de los equipos con encapsuladores TCP, consulte la Seccin 3.6.2, Archivos de configuracin de los encapsuladores TCP. En esta seccin se desarrolla la utilizacin de xinetd para controlar el acceso a los servicios.

Nota
Al contrario que con los encapsuladores TCP, las modificaciones al control de acceso slo tienen efecto si el administrador de xinetd reinicia el servicio xinetd. De manera similar, al contrario que los encapsuladores TCP, el control de acceso mediante xinetd solo afecta a los servicios controlados por xinetd. The xinetd hosts access control differs from the method used by TCP Wrappers. While TCP Wrappers places all of the access configuration within two files, /etc/hosts.allow and /etc/ hosts.deny, xinetd's access control is found in each service's configuration file in the /etc/ xinetd.d/ directory. Las siguientes opciones de acceso de equipos estn soportadas por xinetd: only_from Permite la utilizacin del servicio slo a los equipos especificados. no_access Impide la utilizacin del servicio a los equipos indicados. access_times Establece el perodo de tiempo en que un servicio particular puede ser utilizado. Este perodo debe ser indicado con notaciones en formato de 24 horas, HH:MM-HH:MM. Las opciones only_from y no_access pueden utilizar una lista de direcciones IP o nombres de archivo, o pueden especificar una red entera. Del mismo modo que los encapsuladores TCP, combinar el control de acceso de xinetd con la configuracin mejorada de registro puede aumentar la seguridad evitando las peticiones de los equipos bloqueados, al mismo tiempo que se registra cada intento de conexin. Por ejemplo, el siguiente archivo /etc/xinetd.d/telnet puede utilizarse para bloquear accesos Telnet desde un grupo de determinado, y restringir el tiempo total en que pueden registrarse incluso los usuarios autorizados:
service telnet { disable flags socket_type wait user server log_on_failure no_access log_on_success access_times }

= no = REUSE = stream = no = root = /usr/kerberos/sbin/telnetd += USERID = 172.16.45.0/24 += PID HOST EXIT = 09:45-16:15

En este ejemplo, cuando un sistema de cliente de la red 172.16.45.0/24, como por ejemplo172.16.45.2, intente acceder al servicio Telnet, recibe el siguiente mensaje:

91

Captulo 3. Asegurando su Red

Connection closed by foreign host.

Adems, sus intentos de registro son almacenados en /var/log/messages de la manera siguiente:


Sep Sep Sep 7 14:58:33 localhost xinetd[5285]: FAIL: telnet address from=172.16.45.107 7 14:58:33 localhost xinetd[5283]: START: telnet pid=5285 from=172.16.45.107 7 14:58:33 localhost xinetd[5283]: EXIT: telnet status=0 pid=5285 duration=0(sec)

Al utilizar encapsuladores TCP junto con control de acceso xinetd, es importante comprender la relacin entre ambos mecanismos de control de acceso. La siguiente es la secuencia de eventos que realiza xinetd cada vez que un cliente solicite una conexin: 1. El demonio xinetd obtiene las reglas de acceso de los equipos con encapsuladores TCP, utilizando una llamada de biblioteca libwrap.a. Si una regla de negacin concuerda con el cliente, se abandona la conexin. Si una regla de conexin concuerda con el cliente, la conexin es entregada a xinetd. 2. El demonio xinetd verifica sus propias reglas de control de acceso tanto para el servicio xinetd, como para el servicio solicitado. Si una regla de negacin concuerda con el cliente, se abandona la conexin. De lo contrario, xinetd inicia una instancia del servicio solicitado y entrega el control de la conexin a ese servicio.

Importante
Hay que tener cuidado al utilizar controles de acceso con encapsuladores TCP, junto con controles de acceso de xinetd. Un error de configuracin puede causar efectos no deseados.

3.6.4.3.3. Opciones de unin y redireccin


Los archivos de configuracin del servicio xinetd tienen soporte para asociar el servicio con una direccin IP, y redireccionar las peticiones entrantes para ese servicio hacia otra direccin IP, nombre de equipo, o puerto. Esta asociacin es controlada con la opcin bind en el archivo de configuracin especfico de cada servicio, y enlaza ese servicio con una direccin IP en el sistema. Cuando esto es configurado, la opcin bind slo acepta peticiones para acceder al servicio de la direccin IP correcta. Puede utilizar este mtodo para asociar diferentes servicios con diferentes interfases de acuerdo a sus propias necesidades. Esto es especialmente til para los sistemas con adaptadores de red mltiples, o con mltiples direcciones IP. En tales sistemas, los servicios no seguros (Telnet, por ejemplo), pueden ser configurados para que slo escuchen en una interfaz conectada con una red privada y no con una interfaz conectada a Internet. La opcin redirect acepta una direccin IP o nombre de equipo seguido por un nmero de puerto. Configura el servicio de modo tal de poder redireccionar cualquier peticin para este servicio hacia el equipo y nmero de puerto indicado. Esta herramienta puede ser utilizada para dirigirse hacia otro nmero de puerto en el mismo sistema, redireccionar la peticin hacia una direccin IP diferente en la misma mquina, intercambiar la peticin con un sistema y nmero de puerto totalmente diferente, o combinar entre ellas cualesquiera de estas opciones. Un usuario conectndose con un servicio

92

Archivos de configuracin de xinetd determinado de un sistema, por lo tanto puede ser reruteado hacia otro sistema sin sufrir ningn tipo de interrupcin. El demonio xinetd es capaz de lograr este redireccionamiento extendiendo un proceso activo durante todo el tiempo que dure la conexin, entre la mquina del cliente que realiza la peticin y el equipo que efectivamente est proveyendo el servicio, transfiriendo los datos entre ambos sistemas. Las ventajas de bind y redirect se hacen ms evidentes cuando se utilizan de manera conjunta. Al asociar un servicio con una direccin IP determinada de un sistema, y luego redireccionar las peticiones para este servicio hacia una segunda mquina que slo pueda ser vista por la primera, puede entonces utilizarse un sistema interno que ofrezca servicios para una red comopletamente diferente. Alternativamente, estas opciones pueden ser utilizadas para limitar la exposicin de un servicio determinado en una mquina hacia una direccin IP conocida, al mismo tiempo que redirecciona cualquier peticin para ese servicio hacia otra mquina configurada para ese propsito. Por ejemplo, piense en un sistema que es utilizado como un cortafuegos con la siguiente configuracin para su servicio Telnet:
service telnet { socket_type = stream wait = no server = /usr/kerberos/sbin/telnetd log_on_success += DURATION USERID log_on_failure += USERID bind = 123.123.123.123 redirect = 10.0.1.13 23 }

Las opciones bind y redirect de este archivo aseguran que el servicio Telnet en la mquina est unido a la direccin IP externa (123.123.123.123), por medio de la cual se conecta a Internet. Adems, cualquier peticin para el servicio Telnet enviada a 123.123.123.123, es redireccionada hacia una direccin IP interna mediante un segundo adaptador de red (10.0.1.13) a la que solo el cortafuegos y los sistemas internos pueden acceder. El cortafuegos entonces enva la comunicacin entre ambos sistemas, y el sistema que est conectndose piensa que lo ha hecho con 123.123.123.123, cuando en realidad est conectado con una mquina diferente. Esta herramienta es especialmente til para usuarios con conexiones de banda ancha que slo posean una direccin IP fija. Si utilizan Traductores de Direcciones de Red (NAT por las iniciales en ingls de Network Adress Translations), los sistemas detrs de la mquina que hace de puerta de enlace, que estn utilizando direcciones IP slo internas, no estn disponibles desde fuera del sistema de puerta de enlace. Sin embargo, cuando ciertos servicios controlados por xinetd son configurados con las opciones bind y redirect, la mquina que hace de puerta de enlace puede actuar como un proxy entre los sistemas externos y una mquina interna determinada que haya sido configurada para ofrecer el servicio. Adems, las diferentes opciones de registro y de control de acceso de xinetd, estn disponibles para establecer proteccin adicional.

3.6.4.3.4. Opciones de administracin de recursos


El demonio xinetd puede ofrecer un nivel de proteccin bsico para los ataques de Denegacin de Servicio (DoS, por las iniciales en ingls de Denial of Service). La siguiente es una lista de directivas que pueden ayudar a disminuir la efectividad de tales ataques: per_source Establece el nmero mximo de instancias para un servicio desde cada direccin IP. Acepta solo valores enteros como argumentos y puede ser utilizada tanto en xinetd.conf como en el archivo de configuracin especfico del servicio en cuestin del directorio xinetd.d/. 93

Captulo 3. Asegurando su Red cps Establece el numero mximo de conexiones por segundo. Esta directiva necesita de dos argumentos enteros separados por un espacio. El primer argumento es el nmero mximo de conexiones permitidas por segundo al servicio. El segundo argumento es la cantidad de segundos que xinetd debe esperar antes de reactivar el servicio. Acepta solo enteros como argumentos y puede ser utilizado tanto en el archivo xinetd.conf, como el los archivos de configuracin propios de cada servicio en el directorio xinetd.d/. max_load Define la utilizacin del CPU o el umbral de carga de utilizacin promedio de un servicio. Acepta un nmero de punto flotante como argumento. La carga promedio es una medida aproximada que indica la forma en que algunos procesos estn activos en un determinado perodo de tiempo. Para obtener mayor informacin acerca de la carga promedio, vea los comandos uptime, who, y procinfo Existen otras opciones disponibles para la administracin de los recursos para xinetd. Para obtener mayor informacin, consulte la pgina man de xinetd.conf.

3.6.5. Recursos adicionales


Mayor informacin acerca de los encapsuladores TCP y xinetd se encuentra disponible en Internet y en la documentacin del sistema.

3.6.5.1. Documentacin instalada acerca de los encapsuladores TCP


La documentacin de su sistema es un buen lugar en donde empezar a buscar opciones adicionales de configuracin para los encapsuladores TCP, xinetd, y control de acceso. /usr/share/doc/tcp_wrappers-<version>/ This directory contains a README file that discusses how TCP Wrappers work and the various hostname and host address spoofing risks that exist. /usr/share/doc/xinetd-<version>/ This directory contains a README file that discusses aspects of access control and a sample.conf file with various ideas for modifying service-specific configuration files in the /etc/xinetd.d/ directory. Pginas man relacionadas con encapsuladores TCP y xinetd Existen una cantidad de pginas man para varias aplicaciones y archivos de configuracin relacionadas con encapsuladores TCP y xinetd. Las siguientes con algunas de las ms importantes: Aplicaciones de servidor man xinetd La pgina man para xinetd. Archivos de configuracin man 5 hosts_access La pgina man para los archivos de control de acceso de equipos con encapsuladores TCP. man hosts_options La pgina man para los campos de opcin de los encapsuladores TCP. man xinetd.conf La pgina man que ofrece opciones de configuracin para xinetd.

http://www.xinetd.org

94

Kerberos

3.6.5.2. Sitios web tiles relacionados con encapsuladores TCP


http://www.xinetd.org/ El sitio principal de xinetd, que contiene archivos de configuracin a modo de ejemplo, lista completa de herramientas, y una seccin informativa de preguntas frecuentes (FAQ, por las iniciales en ingls de Frecuently Asked Questions). http://www.docstoc.com/docs/2133633/An-Unofficial-Xinetd-Tutorial Un tutorial en el que se explican diferentes formas de optimizar los archivos de configuracin de xinetd establecidos por defecto, de manera de poder alcanzar objetivos de seguridad especficos.
4

3.6.5.3. Libros relacionados


Hacking Linux Exposed por Brian Hatch, James Lee, y George Kurtz; Osbourne/McGraw-Hill Una herramienta de seguridad excelente con informacin acerca de encapsuladores TCP y xinetd.

3.7. Kerberos
La seguridad e integridad del sistema dentro de la red puede ser complejo. Puede necesitarse el tiempo de varios administradores solo para poder conocer qu servicios son los que estn ejecutndose en una red, y la manera en que estn siendo utilizados. Y ms an, la autenticacin de usuarios en los servicios de red pueden ser peligrosa cuando los mtodos usados por el protocolo sean inherentemente inseguros, como lo demuestran los protocolos tradicionales FTP y Telnet, que transfieren contraseas no encriptadas sobre la red. Kerberos es una forma de eliminar la necesidad de protocolos que permitan mtodos inseguros de autenticacin, por lo que mejora la seguridad general de la red.

3.7.1. Qu es Kerberos?
Kerberos es un protocolo de autenticacin de red creado por el MIT (Massachusetts Institute of 5 Technology), y utiliza una criptografa de llave simtrica para autenticar a los usuarios de los servicios de red, lo que en pocas palabras significa que las contraseas nunca son enviadas a travs de la red. Consecuentemente, cuando los usuarios se autentican con servicios de red usando Kerberos, los usuarios no autorizados que intenten averiguar las contraseas monitoreando el trfico de red son efectivamente bloqueados.

3.7.1.1. Ventajas de Kerberos


La mayora de los servicios convencionales de red utilizan esquemas de autenticacin basados en contraseas. Estos esquemas piden que los usuarios se identifiquen en un servidor de red determinado mediante su nombre y contrasea. Desafortunadamente, la transmisin de los datos para la autenticacin de muchos servicios no es encriptada. Para que este tipo de esquemas sean seguros, la red tiene que permanecer inaccesible a los usuarios extraos a ella, y todos los equipos y todos los usuarios pertenecientes deben ser considerados confiables. An si este es el caso, una red que se encuentre conectada a Internet no puede ser concebida como una red segura. Cualquier atacante que obtenga acceso a la red puede utilizar un simple analizador

Un sistema donde tanto el cliente como el servidor comparten una clave comn que es utilizada para encriptar y desencriptar comunicaciones a travs de una red.

95

Captulo 3. Asegurando su Red de paquetes, tambin conocido como "rastreador" de paquetes, para interceptar nombres de usuario y contraseas, comprometiendo las cuentas de usuario y la integridad de toda la infraestructura de seguridad. El objetivo primario del diseo de Kerberos es eliminar la transmisin de contraseas encriptadas en la red. Si se usa apropiadamente, Kerberos elimina efectivamente la amenaza de los husmeadores (sniffers) de paquetes en la red.

3.7.1.2. Desventajas de Kerberos


Aunque Kerberos elimina una amenaza de seguridad comn y severa, puede ser difcil de implementar por una variedad de razones: Puede ser algo muy tedioso migrar las contraseas de los usuarios de una base de datos UNIX estndar, como ser por ejemplo /etc/passwd o /etc/shadow hacia una base de datos para contraseas Kerberos, ya que no hay ningn mecanismo automatizado para realizar esta tarea. Consulte la pregunta 2.23 en el FAQ en lnea de Kerberos: http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html
6

Kerberos slo tiene compatibilidad parcial con el sistema PAM de mdulos de autenticacin conectables, utilizado por la mayora de los servidores Fedora. Dirjase a la Seccin 3.7.4, Kerberos y PAM para obtener mayor informacin al respecto. Kerberos presupone que cada usuario es confiable, pero que est utilizando un equipo o una red que no lo es. Su objetivo principal es prevenir la transmisin en la red de contraseas no encriptadas. Sin embargo, si alguien ms tiene acceso al nico equipo que enva los comprobantes utilizados para la autenticacin denominado el centro de distribucin de claves (KDC, por las siglas en ingls de Key Distribution Center) , adems del usuario correspondiente, entonces todo el sistema de autenticacin Kerberos est corriendo riesgo. Para que una aplicacin utilice Kerberos, su origen debe ser modificado para que puede realizar las llamadas apropiadas a las bibliotecas de Kerberos. Las aplicaciones as modificadas son consideradas como compatibles con Kerberos, o kerberizadas. Para algunas, esto puede ser bastante problemtico debido al tamao de la aplicacin o debido a su diseo. Para otras aplicaciones incompatibles, los cambios deben ser hechos de manera tal de permitir que el cliente y el servidor puedan comunicarse. De nuevo, esto puede necesitar una programacin extensa. Las aplicaciones de cdigo propietario que no tienen soporte para Kerberos por defecto, son por lo general las ms problemticas. Kerberos es una herramienta de tipo "todo o nada". Si Kerberos es utilizado en la red, cualquier contrasea no encriptada transferida a un servicio no compatible con Kerberos (o no Kerberizado), se encuentra en riesgo. Por lo tanto, la red no obtiene beneficio alguno al utilizarlo. Para asegurar una red con Kerberos, se debe utilizar versiones kerberizadas de todas las aplicaciones de tipo servidor/cliente que transmitan contraseas no encriptadas, o que no utilicen ninguna de este tipo de aplicaciones.

3.7.2. Terminologa de Kerberos


Kerberos tiene su propia terminologa para definir varios aspectos del servicio. Antes de aprender cmo funciona Kerberos, es importante conocer algunos de los siguientes trminos:

http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html#pwconvert

96

Terminologa de Kerberos Servidor de autenticacin (SA) Un servidor que enva comprobantes (o tickets) para un servicio determinado, comprobantes que en su momento sern enviados a los usuarios para que puedan acceder a ese servicio. El AS responde con una peticin a las solicitudes de los clientes que, o no tienen o no han enviado sus credenciales de autenticacin. Generalmente, para tener acceso al servidor que emite las garantas de los comprobantes (TGS, por las siglas en ingls de Ticket-Granting Server), se enva un comprobante de obtencin de garanta de comprobante (TGT, Ticket-Granting Ticket). Por ltimo, el AS generalmente se ejecuta en el mismo equipo que el centro de distribucin de claves (KDC, Key Distribution Center). ciphertext Datos encriptados. cliente Una entidad en la red (un usuario, equipo o aplicacin) que puede recibir tickets desde Kerberos. credenciales Un conjunto de credenciales electrnicas temporales que verifican la identidad de un cliente para un servicio particular. Tambin llamado ticket. cach de credenciales o archivo de ticket Un archivo que contiene las claves para encriptar las comunicaciones entre un usuario y varios servicios de red. Kerberos 5 soporta un marco de trabajo para el uso de otros tipos de cache, tales como memoria compartida, pero los archivos son los ms completamente soportados. hash de encriptado Un hash de una vuelta se usa para autenticar los usuarios. Estos son ms seguros que usar datos no encriptados, pero todava son relativamente fciles de desencriptar para craqueadores experimentados. GSS-API La Interfaz del Programa de la Aplicacin de Servicios Generales de Seguridad (API, por las siglas en ingls de Generic Security Service Application Program Interfaz), es un conjunto de funciones que proveen servicios de seguridad, definida en RFC-2743, publicada por el Equipo de Tareas de Ingeniera de Internet. La API es utilizada por servicios y clientes para autenticarse mutuamente sin que sus programas posean conocimientos especficos de los mecanismos subyacentes. Si un servicio de red (como por ejemplo cyrus-IMAP) utiliza GSS-API, entonces puede autenticarse mediante Kerberos. hash Tambin conocido como valor hash. Un valor generado por el paso de una cadena a travs de una funcin hash. Estos valores son tpicamente usados para asegurar que los datos transmitidos no fueron interceptados y modificados. funcin hash A way of generating a digital "fingerprint" from input data. These functions rearrange, transpose or otherwise alter data to produce a hash value. llave Los datos usados cuando se encriptan o desencriptan otros datos. Los datos encriptados no pueden ser desencriptados sin una clave apropiada o una extrema buena suerte de parte del craqueador.

97

Captulo 3. Asegurando su Red centro de distribucin de claves (KDC) Un servicio que emite tickets de Kerberos, y que usualmente corre en el mismo equipo que el servidor de garanta de ticket (TGS). tabla de clave (keytab) Un archivo que incluye una lista no encriptada de principales con sus respectivas claves. Los servidores obtienen las claves que necesitan desde los archivos keytab en lugar de utilizar kinit. El archivo keytab establecido por defecto es /etc/krb5.keytab. El servidor que administra el KDC /usr/kerberos/sbin/kadmind, es el nico servicio que utiliza cualquier otro archivo (utiliza /var/kerberos/krb5kdc/kadm5.keytab). kinit El comando kinit permite a un principal que ya ingres obtener y hacer cach del ticket inicial de garanta de tickets (TGT). Vaya a la pgina man de kinit para ms informacin. principal (o nombre principal) The principal is the unique name of a user or service allowed to authenticate using Kerberos. A principal follows the form root[/instance]@REALM. For a typical user, the root is the same as their login ID. The instance is optional. If the principal has an instance, it is separated from the root with a forward slash ("/"). An empty string ("") is considered a valid instance (which differs from the default NULL instance), but using it can be confusing. All principals in a realm have their own key, which for users is derived from a password or is randomly set for services. reinado Una red que use Kerberos, compuesta de uno o ms servidores llamados KDCs y un nmero potencialmente grande de clientes. servicio Un programa accedido por la red. ticket Un conjunto temporal de credenciales electrnicas que verifican la identidad de un cliente para un servicio particular. Tambin llamados credenciales o comprobantes. servidor de garantas de tickets (TGS) Un servidor que emite tickets para un servicio deseado que son a su vez dados a los usuarios para acceder al servicio. El TGS corre normalmente en el mismo equipo que el KDC. ticket de garanta de ticket (TGT) Un ticket especial que permite al cliente obtener tickets adicionales sin aplicar nuevamente en el KDC. contrasea no encriptada Una contrasea en texto plano, legible al humano.

3.7.3. Como Funciona Kerberos


Kerberos differs from username/password authentication methods. Instead of authenticating each user to each network service, Kerberos uses symmetric encryption and a trusted third party (a KDC), to authenticate users to a suite of network services. When a user authenticates to the KDC, the KDC sends a ticket specific to that session back to the user's machine, and any Kerberos-aware services look for the ticket on the user's machine rather than requiring the user to authenticate using a password.

98

Como Funciona Kerberos Cuando un usuario kerberizado de una red se loguea en su estacin de trabajo, su principal es enviado al KDC como parte de un pedido para un TGT del servidor de Autenticacin. Este pedido puede ser enviado por el programa de logueo de modo que sea transparente para el usuario, o puede ser enviado por el programa kinit luego que el usuario se haya logueado. The KDC then checks for the principal in its database. If the principal is found, the KDC creates a TGT, which is encrypted using the user's key and returned to that user. The login or kinit program on the client then decrypts the TGT using the user's key, which it computes from the user's password. The user's key is used only on the client machine and is not transmitted over the network. The TGT is set to expire after a certain period of time (usually ten to twenty-four hours) and is stored in the client machine's credentials cache. An expiration time is set so that a compromised TGT is of use to an attacker for only a short period of time. After the TGT has been issued, the user does not have to re-enter their password until the TGT expires or until they log out and log in again. Siempre que el usuario necesite acceso a un servicio de red, el software del cliente utiliza el TGT para pedirle al TGS un nuevo comprobante especficamente para ese servicio. El comprobante del servicio es entonces utilizado para autenticar de manera transparente al usuario frente al servicio en cuestin.

Advertencia
El sistema Kerberos puede ser vulnerado si un usuario en la red se autentica frente a un servicio no kerberizado transmitiendo una contrasea con formato de texto simple. La utilizacin de servicios no kerberizados es altamente desalentada. Entre tales servicios se encuentra Telnet y FTP. Es preferible la utilizacin de otros protocolos encriptados, como servicios asegurados mediante SSH o SSL, aunque no es lo ideal. Esta es solamente una presentacin general acerca de cmo funciona la autenticacin de Kerberos. Dirjase a la Seccin 3.7.10, Recursos adicionales para conocer otros enlaces hacia informacin ms detallada.

99

Captulo 3. Asegurando su Red

Nota
Kerberos depende de los siguientes servicios de red para funcionar correctamente. Sincronizacin de reloj aproximado entre las mquinas de la red. A clock synchronization program should be set up for the network, such as ntpd. Refer to / usr/share/doc/ntp-<version-number>/index.html for details on setting up Network Time Protocol servers (where <version-number> is the version number of the ntp package installed on your system). Servicio de Nombre de Dominio (DNS). You should ensure that the DNS entries and hosts on the network are all properly configured. Refer to the Kerberos V5 System Administrator's Guide in /usr/share/doc/krb5server-<version-number> for more information (where <version-number> is the version number of the krb5-server package installed on your system).

3.7.4. Kerberos y PAM


Los servicios kerberizados actualmente no utilizan mdulos de autenticacin conectables (PAM, por las siglas en ingls de Pluggable Authentication Modules) estos servicios evitan completamente a PAM. Sin embargo, las aplicaciones que utilicen PAM pueden utilizar a Kerberos para autenticarse si el mdulo pam_krb5 (provisto en el paquete pam_krb5) se encuentra instalado. El paquete pam_krb5 contiene archivos de ejemplos de configuracin que permiten que servicios como login o gdm puedan autenticar usuarios al mismo tiempo que obtienen credenciales de inicio utilizando sus contraseas. Si el acceso a los servicios de red es siempre realizado utilizando servicios kerberizados, o servicios que utilicen GSS-API como por ejemplo lo es IMAP, entonces puede considerarse a la red como razonablemente segura.

Importante
Los administradores deben tener la precaucin de no permitir que los usuarios se autentiquen a determinados servicios de red, utilizando contraseas Kerberos. Muchos protocolos utilizados por estos servicios no encriptan las contraseas antes de enviarlas a travs de la red, destruyendo los beneficios del sistema Kerberos. Por ejemplo, los usuarios no deberan tener permitido autenticarse a servicios Telnet con la misma contrasea que utilizan para la autenticacin en Kerberos.

3.7.5. Configurando un servidor Kerberos 5


Cuando se configure Kerberos, primero instale el KDC. Si es necesario configurar servidores esclavos, instale el maestro primero. Para configurar el primer KDC de Kerberos, siga estos pasos: 1. Asegrese que la sincronizacin de hora y DNS estn funcionando correctamente en todos los clientes y mquinas del servidor antes de continuar Kerberos. Preste una atencin especial a la sincronizacin entre el servidor Kerberos y sus clientes. Si la diferencia horaria entre el servidor y el cliente es mayor a cinco minutos (esto es configurable en Kerberos 5), los clientes de Kerberos

100

Configurando un servidor Kerberos 5 no podrn autenticarse en el servidor. Esta sincronizacin es necesaria para prevenir que un atacante utilice un comprobante antiguo de Kerberos enmascarado como el de un usuario vlido. It is advisable to set up a Network Time Protocol (NTP) compatible client/server network even if Kerberos is not being used. Fedora includes the ntp package for this purpose. Refer to /usr/ share/doc/ntp-<version-number>/index.html (where <version-number> is the version number of the ntp package installed on your system) for details about how to set up Network Time Protocol servers, and http://www.ntp.org for more information about NTP. 2. Instale los paquetes krb5-libs, krb5-server y krb5-workstation en la mquina dedicada que correr KDC. Esta mquina necesita ser muy segura si es posible, no debe correr ningn otro servicio ms que KDC. Edite los archivos de configuracin /etc/krb5.conf y /var/kerberos/krb5kdc/kdc.conf para reflejar el nombre del reinado y los mapeos dominio-a-reinado. Un reinado simple puede ser construido reemplazando instancias de EJEMPLO.COM y ejemplo.com con el nombre correcto del dominio siendo seguro mantener la forma correcta de los nombres en mayscula y en mnuscula y cambiando el KDC de kerberos.elemplo.com al nombre del servidor kerberos. Por convencin, todos los nombres de reinados se escriben en maysculas, y todos los nombres de equipos y de dominios DNS en minsculas. Para obtener informacin detallada acerca de los formatos de estos archivos de configuracin, consulte sus respectivas pginas man. Genere la base de datos usando el utilitario kdb5_util desde una terminal:
/usr/kerberos/sbin/kdb5_util create -s

3.

4.

El comando create genera la base de datos que almacena las clves para el reinado de Kerberos. El interruptor -s obliga a la creacin de un archivo stash en el cual la clave del servidor principal es almacenada. Si no existe un archivo stash desde donde poder leer la clave, el servidor kerberos (krb5kdc) le pedir al usuario que ingrese la contrasea principal del servidor (que puede ser utilizada para generar nuevamente la clave) cada vez que se inicie. 5. Edite el archivo /var/kerberos/krb5kdc/kadm5.acl. Este archivo es usado por kadmind para determinar qu principales tienen acceso administrativo a la base de datos de Kerberos y sus niveles de acceso. La mayora de las organizaciones pueden obtenerlo por una nica lnea:
*/admin@EXAMPLE.COM *

Most users are represented in the database by a single principal (with a NULL, or empty, instance, such as joe@EXAMPLE.COM). In this configuration, users with a second principal with an instance of admin (for example, joe/admin@EXAMPLE.COM) are able to wield full power over the realm's Kerberos database. Despus de que se inicie kadmind en el servidor, cualquier usuario puede acceder sus servicios ejecutando kadmin en cualquier cliente o servidores en el reino. Sin embargo, slo los usuarios listados en el archivo kadm5.acl pueden modificar la base de datos de ninguna forma, excepto para cambiar sus propias contraseas.

101

Captulo 3. Asegurando su Red

Nota
La herramienta kadmin permite la comunicacin con el servidor kadmind a travs de la red, y utiliza kerberos para manipular la autenticacin. Consecuentemente, el primer principal debe existir previamente antes de intentar conectarse con el servidor a travs de la red para administrarlo. Genere el primer principal con el comando kadmin.local, que ha sido especficamente diseado para ser utilizado en el mismo equipo en el que funciona el KDC, y no utiliza Kerberos para su autenticacin. Ingrese el comando siguiente kadmin.local en la terminal KDC para crear el primer principal:
/usr/kerberos/sbin/kadmin.local -q "addprinc username/admin"

6.

Inicie Kerberos usando los siguientes comandos:


/sbin/service krb5kdc start /sbin/service kadmin start /sbin/service krb524 start

7.

Agregue principales para los usuarios mediante el comando addprinc dentro de kadmin. kadmin y kadmin.local son interfaces de lneas de comando al KDC. Como este, existen disponibles otros comandos como por ejemplo addprinc luego de iniciar el programa kadmin. Para obtener mas informacin, consulte la pgina man de kadmin. Verifique que KDC est emitiendo tiques. Primero, corra kinit para obtener un tique y guardarlo en un archivo cache de credencial. Luego, use klist para ver la lista de credenciales en el cach y use kdestroy para destruir el cach y las credenciales que contiene.

8.

Nota
By default, kinit attempts to authenticate using the same system login username (not the Kerberos server). If that username does not correspond to a principal in the Kerberos database, kinit issues an error message. If that happens, supply kinit with the name of the correct principal as an argument on the command line (kinit <principal>).

Una vez que estos pasos sean completados, el servidor Kerberos ya debera estar listo y ejecutndose.

3.7.6. Configuracin de un Cliente Kerberos 5


Configurar un cliente de Kerberos 5 es menos complicado que configurar un servidor. Como mnimo, instale los paquetes del cliente y otrguele a cada cliente un archivo de configuracin krb5.conf vlido. Mientras que ssh y slogin son los mtodos preferidos para loguearse remotamente en sistemas cliente, las versiones Kerberizadas de rsh y rlogin siguen estando disponibles, aunque para habilitarlas es necesario realizar algunos cambios adicionales en la configuracin.

102

Configuracin de un Cliente Kerberos 5 1. Asegrese que la sincronizacin de tiempo entre el cliente Kerberos y KDC exista y sea la adecuada. Dirjase a Seccin 3.7.5, Configurando un servidor Kerberos 5 para obtener mayors informacin. Adems, verifique que el DNS est funcionando apropiadamente en el cliente Kerberos antes de configurar con los programas cliente de Kerberos. Instale los paquetes krb5-libs y krb5-workstation en todas las mquinas clientes. Provea un archivo /etc/krb5.conf vlido para cada cliente (normalmente este puede ser el mismo archivo krb5.conf usado por el KDC). Before a workstation in the realm can use Kerberos to authenticate users who connect using ssh or Kerberized rsh or rlogin, it must have its own host principal in the Kerberos database. The sshd, kshd, and klogind server programs all need access to the keys for the host service's principal. Additionally, in order to use the kerberized rsh and rlogin services, that workstation must have the xinetd package installed. Using kadmin, add a host principal for the workstation on the KDC. The instance in this case is the hostname of the workstation. Use the -randkey option for the kadmin's addprinc command to create the principal and assign it a random key:
addprinc -randkey host/blah.example.com

2.

3.

Ahora que se ha creado el principal, las claves se pueden extraer para la estacin trabajo ejecutando kadmin en la misma estacin de trabajo y usando el comando ktadd dentro de kadmin:
ktadd -k /etc/krb5.keytab host/blah.example.com

4.

Para usar otros servicios de red kerberizados, primero deben iniciarse. A continuacin mostramos una lista de los servicios kerberizados comunes y las instrucciones acerca de cmo habilitarlos: ssh OpenSSH uses GSS-API to authenticate users to servers if the client's and server's configuration both have GSSAPIAuthentication enabled. If the client also has GSSAPIDelegateCredentials enabled, the user's credentials are made available on the remote system. rsh y rlogin Para usar las versiones kerberizadas de rsh y rlogin, habilite klogin, eklogin y kshell. Telnet Para usar Telnet kerberizado, debe habilitar krb5-telnet. FTP Para proveer acceso FTP, crear y extraer una clave para el principal con una raz de ftp. Asegrese de poner la instancia al nombre de equipo completo del servidor FTP, luego habilite gssftp. IMAP Para utilizar un servidor kerberizado IMAP, el paquete cyrus-imap utilizar Kerberos 5, si tambin se encuentra instalado el paquete cyrus-sasl-gssapi. El paquete cyrussasl-gssapi contiene el complemento Cyrus SASL que tiene soporte para autenticacin GSS-API. Cyrus IMAP debera funcionar correctamente con Kerberos siempre y cuando el usuario cyrus sea capaz de encontrar la clave correspondiente en /etc/krb5.keytab, y que la raz para el principal est definida para imap (creada con kadmin). Una alternativa a cyrus-imap se puede encontrar en el paquete dovecot, que tambin se ofrece con Fedora. Este paquete contiene un servidor IMAP pero por el momento no da soporte ni a GSS-API ni a Kerberos. 103

Captulo 3. Asegurando su Red CVS Para usar un servidor CVS kerberizado, gserver usa un principal con una raz de cvs y por lo dems es idntico al servidor CVS pserver.

3.7.7. Mapeo dominio-a-reinado


Cuando un cliente intenta acceder a un servicio que corre en un servidor particular, sabe el nombre del (equipo) del servicio y el nombre del servidor (foo.ejemplo.com), pero como se pueden desplegar ms de un reinado en su red, debe averiguar el nombre del reinado en el que reside el servicio. Por defecto, el nombre del territorio se toma como el nombre de dominio DNS del servidor, en maysculas.
foo.example.org EXAMPLE.ORG foo.example.com EXAMPLE.COM foo.hq.example.com HQ.EXAMPLE.COM

In some configurations, this will be sufficient, but in others, the realm name which is derived will be the name of a non-existant realm. In these cases, the mapping from the server's DNS domain name to the name of its realm must be specified in the domain_realm section of the client system's krb5.conf. For example:
[domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM

The above configuration specifies two mappings. The first mapping specifies that any system in the "example.com" DNS domain belongs to the EXAMPLE.COM realm. The second specifies that a system with the exact name "example.com" is also in the realm. (The distinction between a domain and a specific host is marked by the presence or lack of an initial ".".) The mapping can also be stored directly in DNS.

3.7.8. Configurando KDCs secundarios


For a number of reasons, you may choose to run multiple KDCs for a given realm. In this scenario, one KDC (the master KDC) keeps a writable copy of the realm database and runs kadmind (it is also your realm's admin server), and one or more KDCs (slave KDCs) keep read-only copies of the database and run kpropd. El procedimiento de propagacin maestro-esclavo requiere que el KDC maestro vuelque su base de datos a un archivo de volcado temporal y luego transmita ese archivo a cada uno de sus esclavos, que luego sobreescriben sus copias slo lectura de la base de datos recibidas antes, con el contenido del archivo de volcado. To set up a slave KDC, first ensure that the master KDC's krb5.conf and kdc.conf files are copied to the slave KDC. Start kadmin.local from a root shell on the master KDC and use its add_principal command to create a new entry for the master KDC's host service, and then use its ktadd command to simultaneously set a random key for the service and store the random key in the master's default keytab file. This key will be used by the kprop command to authenticate to the slave servers. You will only need to do this once, regardless of how many slave servers you install.
# kadmin.local -r EXAMPLE.COM Authenticating as principal root/admin@EXAMPLE.COM with password.

104

Configurando KDCs secundarios

kadmin: add_principal -randkey host/masterkdc.example.com Principal "host/host/masterkdc.example.com@EXAMPLE.COM" created. kadmin: ktadd host/masterkdc.example.com Entry for principal host/masterkdc.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/masterkdc.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/masterkdc.example.com with kvno 3, encryption type DES with HMAC/ sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/masterkdc.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab. kadmin: quit

Start kadmin from a root shell on the slave KDC and use its add_principal command to create a new entry for the slave KDC's host service, and then use kadmin's ktadd command to simultaneously set a random key for the service and store the random key in the slave's default keytab file. This key is used by the kpropd service when authenticating clients.
# kadmin -p jimbo/admin@EXAMPLE.COM -r EXAMPLE.COM Authenticating as principal jimbo/admin@EXAMPLE.COM with password. Password for jimbo/admin@EXAMPLE.COM: kadmin: add_principal -randkey host/slavekdc.example.com Principal "host/slavekdc.example.com@EXAMPLE.COM" created. kadmin: ktadd host/slavekdc.example.com@EXAMPLE.COM Entry for principal host/slavekdc.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/slavekdc.example.com with kvno 3, encryption type ArcFour with HMAC/ md5 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/slavekdc.example.com with kvno 3, encryption type DES with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/slavekdc.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab. kadmin: quit

With its service key, the slave KDC could authenticate any client which would connect to it. Obviously, not all of them should be allowed to provide the slave's kprop service with a new realm database. To restrict access, the kprop service on the slave KDC will only accept updates from clients whose principal names are listed in /var/kerberos/krb5kdc/kpropd.acl. Add the master KDC's host service's name to that file.
# echo host/masterkdc.example.com@EXAMPLE.COM > /var/kerberos/krb5kdc/kpropd.acl

Once the slave KDC has obtained a copy of the database, it will also need the master key which was used to encrypt it. If your KDC database's master key is stored in a stash file on the master KDC 105

Captulo 3. Asegurando su Red (typically named /var/kerberos/krb5kdc/.k5.REALM, either copy it to the slave KDC using any available secure method, or create a dummy database and identical stash file on the slave KDC by running kdb5_util create -s (the dummy database will be overwritten by the first successful database propagation) and supplying the same password. Ensure that the slave KDC's firewall allows the master KDC to contact it using TCP on port 754 (krb5_prop), and start the kprop service. Then, double-check that the kadmin service is disabled. Ahora realice una prueba manual de propagacin de la base de datos volcando la base de datos del reinado, en el KDC maestro, al archivo de datos predeterminado desde donde el comando kprop leer (/var/kerberos/krb5kdc/slave_datatrans) y luego use el comando kprop para transmitir su contenido al KDC esclavo.
# /usr/kerberos/sbin/kdb5_util dump /var/kerberos/krb5kdc/slave_datatrans# kprop slavekdc.example.com

Usando kinit, verifique que un sistema cliente cuyo krb5.conf liste slo el KDC esclavo en su lista de KDCs para su reinado, pueda ahora obtener correctamente las credenciales iniciales del KDC esclavo. Hecho esto, simplemente cree un script que vuelque la base de datos del reinado y ejecute el comando kprop para transmitir la base de datos a cada KDC esclavo por vez, y configure el servicio cron para correr el script peridicamente.

3.7.9. Configurando la autenticacin cruzada de reinados


La autenticacin cruzada de reinado es el trmino usado para describir situaciones en que los clientes (normalmente usuarios) de un reinado utilizan Kerberos para autenticarse con servicios (tpicamente procesos servidor corriendo en un sistema servidor particular) que pertenecen a otro reinado distinto al propio. Para el caso ms simple, para que un cliente de un reinado con nombre A.EJEMPLO.COM acceda a un servicio en el reinado B.EJEMPLO.COM, ambos reinados deben compartir una clave para el principal con nombre krbtgt/B.EJEMPLO.COM@A.EJEMPLO.COM, y ambas claves deben tener el mismo nmero de versin de clave asociadas a ellas. Para hacer esto, debe seleccionar una contrasea o frase de acceso muy fuerte y crear una entrada para el principal de ambos reinados usando kadmin.
# kadmin -r A.EXAMPLE.COM kadmin: add_principal krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM Enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM": Re-enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM": Principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" created. quit # kadmin -r B.EXAMPLE.COM kadmin: add_principal krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM Enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM": Re-enter password for principal "krbtgt/ B.EXAMPLE.COM@A.EXAMPLE.COM": Principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" created. quit

Use el comando get_principal para verificar que ambas entradas tienen un nmero de versin de claves (valores kvno) y tipos de encriptados coincidentes.

106

Configurando la autenticacin cruzada de reinados

Dumping the Database Doesn't Do It


Security-conscious administrators may attempt to use the add_principal command's randkey option to assign a random key instead of a password, dump the new entry from the database of the first realm, and import it into the second. This will not work unless the master keys for the realm databases are identical, as the keys contained in a database dump are themselves encrypted using the master key. Los clientes en el reinado A.EJEMPLO.COM son capaces ahora de autenticarse en los servicios del reinado B.EJEMPLO.COM. Dicho de otra manera, el reinado B.EJEMPLO.COM ahora confa en el reinado A.EJEMPLO.COM, o, ms sencillo an, ahora B.EJEMPLO.COM confa en A.EJEMPLO.COM. Esto nos lleva a un punto importante: la confianza generada entre los reinados es, por defecto, unidireccional. El KDC para el reinado B.EJEMPLO.COM podra confiar en clientes del reinado A.EJEMPLO.COM para autenticarse en sus servicios, pero este hecho no significa que el reinado A.EJEMPLO.COM confe en los clientes del reinado B.EJEMPLO.COM cuando estos intenten autenticarse en sus servicios. Para establecer una confianza bidireccional entre dos reinados, ambos van a necesitar compartir claves para el servicio krbtgt/A.EJEMPLO.COM@B.EJEMPLO.COM (tome nota de la forma invertida de acuerdo a los dos reinados comparados en el ejemplo anterior). If direct trust relationships were the only method for providing trust between realms, networks which contain multiple realms would be very difficult to set up. Luckily, cross-realm trust is transitive. If clients from A.EXAMPLE.COM can authenticate to services in B.EXAMPLE.COM, and clients from B.EXAMPLE.COM can authenticate to services in C.EXAMPLE.COM, then clients in A.EXAMPLE.COM can also authenticate to services in C.EXAMPLE.COM, even if C.EXAMPLE.COM doesn't directly trust A.EXAMPLE.COM. This means that, on a network with multiple realms which all need to trust each other, making good choices about which trust relationships to set up can greatly reduce the amount of effort required. Now you face the more conventional problems: the client's system must be configured so that it can properly deduce the realm to which a particular service belongs, and it must be able to determine how to obtain credentials for services in that realm. Vayamos en orden: el nombre del principal para un servicio provisto desde un sistema servidor especfico en un reinado dado normalmente es parecido a:
service/server.example.com@EXAMPLE.COM

En el ejemplo siguiente, el servicio es generalmente, o bien el nombre del protocolo en uso (otros valores comunes pueden ser ldap, imap, cvs, y HTTP), o bien equipo. server.ejemplo.com es el nombre del dominio del sistema completamente calificado que ejecuta el servicio, y EJEMPLO.COM es el nombre del reinado. Para deducir el dominio al que el servicio pertenece, los clientes por lo general consultan el DNS o la seccin domain_realm del archivo /etc/krb5.conf para mapear ya sea el nombre del equipo (server.ejemplo.com) o el nombre del dominio DNS (.ejemplo.com) hacia el nombre del reinado (EJEMPLO.COM). Habiendo determinado a qu reinado pertenece el servicio, un cliente tiene que determinar luego el conjunto de reinados que debe contactar y en qu orden debe hacerlo, para obtener las credenciales a usar en la autenticacin con el servicio.

107

Captulo 3. Asegurando su Red Esto se puede hacer de una o dos formas. El mtodo establecido por defecto, que no requiere una configuracin explcita, es dar a los reinados nombres dentro de una jerarqua compartida. Como ejemplo, suponer los reinados llamados A.EJEMPLO.COM, B.EJEMPLO.COM, and EJEMPLO.COM. Cuando un cliente del reinado A.EJEMPLO.COM intente autenticarse en un servicio del reinado B.EJEMPLO.COM, por defecto, lo primero que har ser intentar obtener credenciales para el reinado EJEMPLO.COM, y luego utilizar esas credenciales para obtener unas nuevas para poder utilizarlas en el reinado B.EJEMPLO.COM. The client in this scenario treats the realm name as one might treat a DNS name. It repeatedly strips off the components of its own realm's name to generate the names of realms which are "above" it in the hierarchy until it reaches a point which is also "above" the service's realm. At that point it begins prepending components of the service's realm name until it reaches the service's realm. Each realm which is involved in the process is another "hop". Por ejemplo, el uso de credenciales en A.EJEMPLO.COM, autenticando a un servicio en B.EJEMPLO.COMA.EJEMPLO.COM EJEMPLO.COM B.EJEMPLO.COM A.EJEMPLO.COM y EJEMPLO.COM comparten una clave para krbtgt/ EJEMPLO.COM@A.EJEMPLO.COM EJEMPLO.COM y B.EJEMPLO.COM comparten una clave krbtgt/ B.EJEMPLO.COM@EJEMPLO.COM Otro ejemplo, usando credenciales en SITIO1.VENTAS.EJEMPLO.COM, para autenticar a un servicio en CUALQUIERLUGAR.EJEMPLO.COMSITIO1.VENTAS.EJEMPLO.COM VENTAS.EJEMPLO.COM EJEMPLO.COM CUALQUIERLUGAR.EJEMPLO.COM SITIO1.VENTAS.EJEMPLO.COM y VENTAS.EJEMPLO.COM comparten una clave para krbtgt/ VENTAS.EJEMPLO.COM@SITIO1.VENTAS.EJEMPLO.COM VENTAS.EJEMPLO.COM y EJEMPLO.COM comparten una clave para krbtgt/ EJEMPLO.COM@VENTAS.EJEMPLO.COM EJEMPLO.COM y CUALQUIERLUGAR.EJEMPO.COM comparten una clave para krbtgt/ CUALQUIERLUGAR.EJEMPLO.COM@EJEMPLO.COM Otro ejemplo, esta vez utilizando nombres de reinados que no compartan sufijos comunes (DEVEL.EJEMPLO.COM y PROD.EJEMPLO.ORG DEVEL.EJEMPLO.COM EJEMPLO.COM COM ORG EJEMPLO.ORG PROD.EJEMPLO.ORG DEVEL.EJEMPLO.COM y EJEMPLO.COM comparten una clave para krbtgt/ EJEMPLO.COM@DEVEL.EJEMPLO.COM EJEMPLO.COM y COM comparten una clave para krbtgt/COM@EJEMPLO.COM COM y ORG comparten una clave para krbtgt/ORG@COM ORG y EJEMPLO.ORG comparten una clave para krbtgt/EJEMPLO.ORG@ORG EJEMPLO.ORG y PROD.EJEMPLO.ORG comparten una clave para krbtgt/ PROD.EJEMPLO.ORG@EJEMPLO.ORG El mtodo ms complicado, pero que al mismo tiempo es el ms flexible, reside en configurar la seccin capaths del archivo /etc/krb5.conf, de modo que los clientes que tengan credenciales para un reinado especfico, debern buscar qu reinado es el que le sigue en la cadena y que, eventualmente, ser quien permita su autenticacin con los servidores. The format of the capaths section is relatively straightforward: each entry in the section is named after a realm in which a client might exist. Inside of that subsection, the set of intermediate realms from 108

Recursos adicionales which the client must obtain credentials is listed as values of the key which corresponds to the realm in which a service might reside. If there are no intermediate realms, the value "." is used. Here's an example:
[capaths] A.EXAMPLE.COM = { B.EXAMPLE.COM = . C.EXAMPLE.COM = B.EXAMPLE.COM D.EXAMPLE.COM = B.EXAMPLE.COM D.EXAMPLE.COM = C.EXAMPLE.COM }

En este ejemplo, los clientes en el reinado A.EJEMPLO.COM pueden obtener credenciales de reinados cruzados para B.EJEMPLO.COM directamente del KDC de A.EJEMPLO.COM. Si esos clientes desean contactar un servicio en el reinado C.EJEMPLO.COM, necesitarn obtener primero credenciales necesarias del reinado B.EJEMPLO.COM (esto requiere que krbtgt/B.EJEMPLO.COM@A.EJEMPLO.COM exista), y entonces utilizar esas credenciales para obtener otras para ser utilizadas en el reinado C.EJEMPLO.COM (utilizando krbtgt/ C.EJEMPLO.COM@B.EJEMPLO.COM). Si esos clientes desean contactar un servicio en el reinado D.EJEMPLO.COM, necesitarn obtener primero las credenciales necesarias del reinado B.EJEMPLO.COM, y luego las credenciales del reinado C.EJEMPLO.COM, antes de obtener, finalmente, las credenciales necesarias para utilizar con el reinado D.EJEMPLO.COM.

Nota
Sin una entrada que indique lo contrario, Kerberos asume que las relaciones de confianza de reinados cruzados forman una jerarqua. Clients in the A.EXAMPLE.COM realm can obtain cross-realm credentials from B.EXAMPLE.COM realm directly. Without the "." indicating this, the client would instead attempt to use a hierarchical path, in this case:
A.EXAMPLE.COM EXAMPLE.COM B.EXAMPLE.COM

3.7.10. Recursos adicionales


Para ms informacin sobre Kerberos, consulte las fuentes que indicamos a continuacin.

3.7.10.1. Documentacin Instalada de Kerberos


The Kerberos V5 Installation Guide and the Kerberos V5 System Administrator's Guide in PostScript and HTML formats. These can be found in the /usr/share/doc/krb5-server-<versionnumber>/ directory (where <version-number> is the version number of the krb5-server package installed on your system). The Kerberos V5 UNIX User's Guide in PostScript and HTML formats. These can be found in the /usr/share/doc/krb5-workstation-<version-number>/ directory (where <versionnumber> is the version number of the krb5-workstation package installed on your system).

109

Captulo 3. Asegurando su Red Pginas man de Kerberos Hay un nmero de pginas man para las varias aplicaciones y archivos de configuracin involucrados con una implementacin de Kerberos. La siguiente es una lista de algunas de las pginas man ms importantes. Aplicaciones cliente man kerberos Una introduccin al sistema Kerberos que describe cmo funcionan las credenciales y provee recomendaciones para obtener y destruir tickets de Kerberos. Al final de la pgina man hay referencias hacia otras pginas man relacionadas con el tema. man kinit Describe cmo usar este comando para obtener y hacer cach de un ticket de garanta de tickets. man kdestroy Describe cmo usar este comando para destruir las credenciales de Kerberos. man klist Describe cmo usar este comando para listar las credenciales cacheadas de Kerberos. Aplicaciones administrativas man kadmin Describe cmo usar este comando para administrar con la base de datos de Kerberos V5. man kdb5_util Describe cmo usar este comando para crear y realizar funciones administrativas de bajo nivel en la base de datos de Kerberos V5. Aplicaciones de servidor man krb5kdc Describe las opciones de la lnea de comando del KDC de Kerberos V5. man kadmind Describe las opciones de la lnea de comando para el servidor de administracin de Kerberos V5. Archivos de configuracin man krb5.conf Describe el formato y las opciones disponibles dentro del archivo de configuracin para la biblioteca de Kerberos V5. man kdc.conf Describe el formato y las opciones disponibles dentro del archivo de configuracin del AS y el KDC de Kerberos V5.

3.7.10.2. Pginas web tiles sobre Kerberos


http://web.mit.edu/kerberos/www/ Kerberos: El Protocolo de Autenticacin de Red del MIT. http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html Las Preguntas Frecuentes de Kerberos (FAQ). ftp://athena-dist.mit.edu/pub/kerberos/doc/usenix.PS La versin PostScript de Kerberos: Un Servicio de Untenticacin para Sistemas de Red Abierta por Jennifer G. Steiner, Clifford Neuman, y Jeffrey I. Schiller. Este documento es el impreso original que describe el funcionamiento de Kerberos. http://web.mit.edu/kerberos/www/dialogue.html Designing an Authentication System: a Dialogue in Four Scenes originally by Bill Bryant in 1988, modified by Theodore Ts'o in 1997. This document is a conversation between two developers who are thinking through the creation of a Kerberos-style authentication system. The conversational style of the discussion make this a good starting place for people who are completely unfamiliar with Kerberos.

110

Cortafuegos http://www.ornl.gov/~jar/HowToKerb.html Cmo Kerberizar su sitio es una buena referencia para kerberizar su red. http://www.networkcomputing.com/netdesign/kerb1.html Manual de Diseo de Red con Kerberos es un repaso extenso sobre el sistema Kerberos.

3.8. Cortafuegos
La seguridad de la informacin es comnmente entendida como un proceso, y no como un producto. Sin embargo, generalmente las implementaciones estndar de seguridad utilizan alguna forma de mecanismo especfico para controlar los accesos privilegiados, y restringir los recursos de red a usuarios que estn debidamente autorizados para ello, al mismo tiempo que poder identificarlos y rastrearlos. Fedora ofrece diferentes herramientas para ayudar a los administradores y a los ingenieros en seguridad, con los diferentes problemas que puedan surgir al controlar los accesos jerarquizados a la red. Los cortafuegos son uno de los componentes fundamentales para la implementacin de la seguridad en una red. Diversos proveedores ofrecen herramientas para cortafuegos para todos los niveles del mercado: desde usuarios hogareos protegiendo los datos de su PC, hasta herramientas para centros de datos que permitan proteger los datos vitales de una empresa. Los cortafuegos pueden ser herramientas para un slo equipo fsico, como las aplicaciones de cortafuego que ofrecen Cisco, Nokia y Sonicwall. Proveedores como Checkpoint, McAfee y Symantec tambin han desarrollado herramientas de cortafuegos de cdigo propietario, tanto para el hogar como para los segmentos comerciales del mercado. Adems de las diferencias entre los cortafuegos basados en hardware o en software, existen tambin diferencias en la manera en que el cortafuego funciona, separando una herramienta de otra. Tabla 3.2, Tipos de cortafuegos describe tres tipos comunes de cortafuegos, y cmo funcionan cada uno de ellos: Tabla 3.2. Tipos de cortafuegos Mtodo Descripcin NAT Network Address Translation (NAT), coloca direcciones IP de subredes privadas, detrs de un pequeo grupo de direcciones IP pblicas, enmascarando todas las peticiones hacia un recurso, en lugar de varios. El kernel de Linux tiene una funcionalidad NAT predefinida, mediante el subsistema del kernel Netfilter. Ventajas Se puede configurar transparentemente para mquinas en una LAN. La proteccin de muchas mquinas y servicios detrs de una o ms direcciones IP externas simplifica las tareas de administracin. La restriccin del acceso a usuarios dentro y fuera de la LAN se puede configurar abriendo o cerrando puertos en el cortafuego/puerta de enlace NAT. Personalizable a travs del utilitario iptables. No necesita cualquier personalizacin del lado del cliente, dado que toda la actividad de red se filtra en el nivel del ruteador en vez de a nivel de aplicacin. Desventajas No se puede prevenir la actividad maliciosa una vez que los usuarios se conecten a un servicio fuera del cortafuegos.

Filtros Un cortafuegos de filtro de de paquete lee cada uno Paquete de los datos que viajan a travs de una LAN. Puede leer y procesar paquetes segn la informacin de sus encabezados, y filtrar el paquete basndose

No se pueden filtrar paquetes para contenidos como en los cortafuegos proxy. Procesa los paquetes en la capa del protocolo, pero no los puede filtrar en la capa de una aplicacin. 111

Captulo 3. Asegurando su Red Mtodo Descripcin en un conjunto de reglas programables implementadas por el administrador del cortafuegos. El kernel de Linux tiene una funcionalidad de filtro de paquetes predefinida, mediante el subsistema del kernel Netfilter. Proxy El cortafuegos proxy filtra todas las peticiones de los clientes LAN de un determinado protocolo, o tipo, hacia una mquina proxy, la que luego realiza esas mismas peticiones a Internet, en nombre del cliente local. Una mquina proxy acta como un bfer entre usuarios remotos maliciosos y la red interna de mquinas clientes. Ventajas Debido a que los paquetes no se transmiten a travs de un proxy, el rendimiento de la red es ms rpida debido a la conexin directa entre el cliente y el equipo remoto. Desventajas Las arquitecturas de red complejas pueden complicar el armado de las reglas de filtrado de paquetes, especialmente si se lo hace con el enmascarado de IP o con subredes locales y redes de zonas desmilitarizadas. Los proxies son a menudo especficos a una aplicacin (HTTP, Telnet, etc.), o restringidos a un protocolo (la mayora de los proxies funcionan slo con servicios que usan conexiones TCP). Los servicios de aplicacin no se pueden ejecutar detrs de un proxy, por lo que sus servidores de aplicacin deben usar una forma separada de seguridad de red. Los proxies se pueden volver cuellos de botellas, dado que todos los pedidos y transmisiones son pasados a travs de una fuente, en vez de hacerlo directamente desde el cliente al servicio remoto.

Le da a los administradores el control sobre qu aplicaciones y protocolos funcionan fuera de la LAN. Algunos servidores proxy, pueden hacer cache de datos accedidos frecuentemente en vez de tener que usar la conexin a Internet para bajarlos. Esto ayuda a reducir el consumo de ancho de banda. Los servicios de proxy pueden ser registrados y monitoreados ms de cerca, lo que permite un control ms estricto sobre el uso de los recursos de la red.

3.8.1. Netfilter e IPTables


El kernel de Linux posee un poderoso subsistema de red denominado Netfilter. El subsistema Netfilter ofrece filtro total o parcial de paquetes, as como servicios de enmascaramiento NAT e IP. Netfilter tambin tiene la habilidad de transformar la informacin de los encabezados IP para enrutamiento avanzado y administracin del estado de la conexin. Netfilter es controlado mediante la utilizacin de la herramienta iptables.

3.8.1.1. Introduccin a IPTables


El poder y la flexibilidad de Netfilter se implementa utilizando iptables, una herramienta de administracin de lnea de comando con sintaxis similar a la de su predecesor, ipchains, la cual Netfilter/iptables ha reemplazado a partir del kernel LInux 2.4. iptables utiliza el subsistema Netfilter para incrementar la conexin, inspeccin y procesamiento de la red. iptables ofrece registro avanzado, acciones pre y post enrutamiento, traduccin de direcciones de red y reenvo de puerto, todo en una interfaz de lnea de comandos. Esta seccin ofrece un resumen acerca de iptables. Para obtener informacin ms detallada, dirjase a la Seccin 3.9, IPTables. 112

Configuracin bsica de un cortafuego

3.8.2. Configuracin bsica de un cortafuego


Del mismo modo que el extintor de incendios en un edificio intenta prevenir que se propague un incendio, en una computadora, un cortafuegos intenta prevenir que algn tipo de software malicioso se propague en su equipo. Tambin ayuda a prevenir que usuarios no autorizados accedan a su computadora. En una instalacin por defecto de Fedora existe un cortafuegos entre su computadora o red, y cualquier otra red considerada como no segura, como por ejemplo lo es Internet. Este cortafuegos determina qu servicios en su computadora pueden ser accedidos por usuarios remotos. Un cortafuegos correctamente configurado puede incrementar enormemente la seguridad de su sistema. Se recomienda que configure un cortafuegos para cualquier sistema Fedora que tenga una conexin a Internet.

3.8.2.1. Herramienta de administracin de cortafuegos


En el proceso de instalacin de Fedora, en la pantalla de Configuracin del cortafuego, se le ofreci la oportunidad de habilitar un cortafuego bsico, as como la posibilidad de utilizar ciertos dispositivos, servicios entrantes y puertos. Una vez finalizada la instalacin, puede modificar las opciones elegidas mediante la utilizacin de la Herramienta de administracin de cortafuegos. Para iniciar esta aplicacin, use el siguiente comando:
[root@myServer ~] # system-config-firewall

Figura 3.10. Herramienta de administracin de cortafuegos

113

Captulo 3. Asegurando su Red

Nota
La Herramienta de administracin de cortafuegos solo configura un cortafuego bsico. Si el sistema necesita reglas ms complejas, dirjase a laSeccin 3.9, IPTables para conocer ms detalles sobre la configuracin de reglas especficas de iptables.

3.8.2.2. Habilitando y deshabilitando el cortafuego


Seleccione una de las opciones siguientes para el cortafuego: Deshabilitado Deshabilitar el cortafuegos proporciona un acceso completo a su sistema y no se realiza ninguna verificacin de seguridad. Esto debe ser seleccionado slo si est ejecutando una red segura (no Internet), o necesite configurar un cortafuego personalizado utilizando la herramienta de la lnea de comandos iptables.

Advertencia
Las configuraciones del cortafuego y cualquier reglas de cortafuegos personalizadas se almacenan en el archivo /etc/sysconfig/iptables. Si elije Deshabilitado y hace clic en Aceptar, estas configuraciones y reglas del cortafuego se perdern.

Habilitado Esta opcin configura el sistema para rechazar conexiones entrantes que no una respuesta a peticiones que han sido realizadas, tales como respuestas DNS o peticiones DHCP. Si se necesita el acceso a servicios de esta mquina, puede elegir habilitar servicios especficos a travs del cortafuego. Si est conectando su sistema a Internet, pero no planea hacerlo funcionar como servidor, esta es la opcin ms segura.

3.8.2.3. Servicios confiables


Habilitando opciones en la lista de Servicios confiables le permite al servicio especificado pasar a travs del cortafuego. WWW (HTTP) El protocolo HTTP es utilizado por Apache (y por otros servidores Web) para ofrecer pginas web. Si tiene pensado hacer que su servidor web est disponible al pblico en general, tilde esta casilla. Esta opcin no es requerida para ver pginas en forma local, o para desarrollar pginas web. Este servicio requiere que el paquete httpd est disponible. Habilitando WWW (HTTP) no abrir el puerto de HTTPS, la versin SSL de HTTP. Si se necesita este servicio, Elija la casilla WWW Seguro (HTTPS). FTP El protocolo FTP se usa para transferir archivos entre mquinas de una red. Si planea hacer su servidor FTP disponible pblicamente, marque este casillero. Este servicio requiere que se instale el paquete vsftpd.

114

Configuracin bsica de un cortafuego SSH Secure Shell (SSH) es una suite de herramientas para registrarse en un equipo remoto y poder ejecutar comandos en l. Para permitir acceso remoto a una mquina utilizando ssh, tilde esta casilla. Este servicio requiere que el paquete openssh-server se encuentre instalado. Telnet Telnet es un protocolo que permite registrarse en equipos remotos. Las comunicaciones a travs de Telnet no estn encriptadas y no ofrece proteccin ante posibles espas que se encuentren en la red. No se recomienda permitir el acceso a travs de Telnet. Para permitirlo, tilde esta casilla. Este servicio requiere que el paquete telnet-server se encuentre instalado. Mail (SMTP) SMTP es un protocolo que permite a otras mquinas conectarse directamente con su mquina para entregar correo. Usted no necesita habilitar este servicio si usted recolecta sus correos desde el servidor del ISP usando POP3, IMAP o algn otra herramienta como fetchmail. Para permitir la entrega de correo a su mquina, seleccione esta casilla de verificacin. Tenga en cuenta que un servidor SMTP mal configurado puede permitir a mquinas usar su servidor para enviar correo basura. NFS4 El Sistema de Archivos de Red (NFS, por las siglas en ingls de Network File System), es un protocolo para compartir archivos comnmente utilizado en sistemas *NIX. La versin 4 de este protocolo es ms segura que sus predecesoras. Si quiere compartir archivos y directorios de su sistema con otros en red, tilde esta casilla. Samba Samba es una implementacin del protocolo de red propietario de Microsoft SMB. Si usted necesita compartir archivos, directorios o impresoras conectadas localmente con mquinas Microsoft Windows, selecciones esta casilla de verificacin.

3.8.2.4. Otros Puertos


La Herramienta de configuracin de cortafuegos incluye una seccin de Otros puertos para especificar puertos IP personalizados de modo tal de considerarlos como seguros por iptables. Por ejemplo, para permitir que protocolos IRC, o de impresin a travs de Internet (IPP, por las siglas en ingls de Internet Printing Protocol) pasen a travs del cortafuegos, aada la siguiente lnea a la seccin de Other ports: 194:tcp,631:tcp

3.8.2.5. Guardando la configuracin


Haga clic en OK para guardar los cambios y activar o desactivar el cortafuegos. Si fue seleccionado Activar cortafuegos, las opciones seleccionadas sern trasladadas a los comandos iptables y escritos en el archivo /etc/sysconfig/iptables. El servicio iptables es tambin iniciado de modo que el cortafuegos sea activado inmediatamente luego de guardar las opciones seleccionadas. Si fue seleccionado Desactivar cortafuegos, el archivo /etc/sysconfig/iptables es eliminado y el servicio iptables es inmediatamente detenido. Las opciones seleccionadas son tambin escritas al archivo /etc/sysconfig/system-configsecuritylevel para que la configuracin pueda restaurarse la prxima vez que se inicie la aplicacin. No edite este archivo a mano. Aun si el cortafuegos es activado inmediatamente, el servicio iptables no est configurado para que se inicie automticamente durante el arranque del equipo. Vea la Seccin 3.8.2.6, Activando el servicio IPTables para obtener ms informacin. 115

Captulo 3. Asegurando su Red

3.8.2.6. Activando el servicio IPTables


Las reglas del cortafuego estn solamente activas si el servicio iptables se est ejecutando. Para iniciar manualmente el servicio, use el siguiente comando:
[root@myServer ~] # service iptables restart

Para asegurarse de que iptables se inicie cuando el sistema arranque, use el siguiente comando:
[root@myServer ~] # chkconfig --level 345 iptables on

3.8.3. Uso de IPTables


El primer paso en el uso de iptables es iniciar el servicio iptables. Use el siguiente comando para iniciar el servicio iptables:
[root@myServer ~] # service iptables start

Nota
El servicio ip6tables puede ser desactivado si usted intenta utilizar solamente el servicio iptables. Si desactiva el servicio ip6tables, recuerde tambin desactivar la red IPv6. Nunca deje un dispositivo de red activo sin su correspondiente cortafuegos. Para forzar a iptables para que se inicie por defecto cuando el sistema arranque, use el siguiente comando:
[root@myServer ~] # chkconfig --level 345 iptables on

Esto fuerza a iptables a que se inicie cuando el sistema arranque en los niveles de ejecucin 3, 4 o 5.

3.8.3.1. Sintaxis de comando de IPTables


El siguiente comando iptables ilustra la sintaxis bsica de comandos:
[root@myServer ~ ] # iptables -A <chain> -j <target>

The -A option specifies that the rule be appended to <chain>. Each chain is comprised of one or more rules, and is therefore also known as a ruleset. Las tres cadenas predefinidas son INPUT, OUTPUT, y FORWARD. Estas cadenas son permanentes y no se pueden borrar. La cadena especifica el punto en el que el paquete es manipulado. The -j <target> option specifies the target of the rule; i.e., what to do if the packet matches the rule. Examples of built-in targets are ACCEPT, DROP, and REJECT. Vaya a la pgina man de iptables para ms informacin sobre las cadenas, opciones y destinos disponibles.

116

Filtrado comn de IPTables

3.8.3.2. Polticas bsicas del cortafuego


El establecimiento de polticas bsicas de cortafuego crea la base para construir reglas ms detalladas definidas por el usuario. Cada cadena de iptables se compone de una poltica predeterminada, y cero o ms reglas que funcionan en conjunto con la poltica predeterminada para definir el conjunto de reglas del cortafuego. La poltica establecida por defecto para una cadena puede ser DROP o ACCEPT. Los administradores de sistemas orientados por la seguridad implementan una poltica por defecto de DROP, y solo permiten unos pocos paquetes especficos, luego de ser analizados uno por uno. Por ejemplo, las siguientes polticas bloquean todos los paquetes que lleguen a o que partan desde una puerta de enlace:
[root@myServer ~ ] # iptables -P INPUT DROP [root@myServer ~ ] # iptables -P OUTPUT DROP

Es tambin algo recomendado que a cualquier paquete reenviado trfico de red que es enrutado desde el cortafuegos hacia su nodo de destino tambin le sea negada la entrada, para poder as restringir las posibles exposiciones inadvertidas de clientes internos a Internet. Para hacerlo, utilice la siguiente regla:
[root@myServer ~ ] # iptables -P FORWARD DROP

Cuando haya establecido las polticas por defecto para cada cadena, puede crear y guardar las reglas siguientes para su red y requerimientos de seguridad particulares. Las siguientes secciones describen cmo guardar las reglas iptables y delinea algunas de las reglas que puede implementar cuando construya su cortafuego con iptables.

3.8.3.3. Guardando y restaurando las reglas de IPTables


Los cambios en iptables son transitorios; si el sistema es reiniciado o si el servicio de iptables es reiniciado, las reglas son automticamente eliminadas y reiniciadas. Para guardar las reglas de modo que sean cargadas cuando el servicio iptables sea iniciado, utilice el siguiente comando:
[root@myServer ~ ] # service iptables save

Las reglas se guardan en el archivo /etc/sysconfig/iptables y se aplican cada vez que el servicio o la computadora se reinician.

3.8.4. Filtrado comn de IPTables


La prevencin del acceso a la red de atacantes remotos es uno de los aspectos ms importantes de la seguridad de la red. La integridad de la LAN debe protegerse de los usuarios remotos maliciosos a travs del uso de las reglas estrictas de cortafuego. Sin embargo, con una poltica por defecto de bloquear todos los paquetes entrantes, salientes y reenviados, es imposible que los usuarios del cortafuego/puerta de enlace y los usuarios internos de la LAN puedan comunicarse entre ellos, o con recursos externos. Para permitir que los usuarios realicen funciones relacionadas con la red y de que puedan usar aplicaciones de red, los administradores deben abrir ciertos puertos para la comunicacin. Por ejemplo, para permitir el acceso al puerto 80 en el cortafuego, agregar la siguiente regla:
[root@myServer ~ ] # iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

117

Captulo 3. Asegurando su Red Esto permite a los usuarios navegar sitios que se comunican usando el puerto estndar 80. Para permitir el acceso a sitios web seguros (por ejemplo, https://www.ejemplo.com/), tambin necesita proveer el acceso al puerto 443, como sigue:
[root@myServer ~ ] # iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

Importante
Cuando se crea un conjunto de reglas de iptables, el orden es importante. Si una regla especifica que cualquier paquete desde la subred 192.168.100.0/24 debe ignorarse, y esto es seguido por una regla que permite los paquetes de 192.168.100.13 (que est dentro de la subred ignorada), la segunda regla se ignora. La regla para permitir los paquetes de 192.168.100.13 debe estar antes de la que elimina los restantes de la subred. Para insertar una regla en una ubicacin especfica en una cadena existente, use la opcin -I. Por ejemplo:
[root@myServer ~ ] # iptables -I INPUT 1 -i lo -p all -j ACCEPT

Esta regla es insertada como la primera regla en la cadena INPUT para permitir el trfico en el dispositivo loopback local. Pueden suceder que en determinadas oportunidades se necesite un acceso remoto a la LAN. Los servicios seguros, por ejemplo SSH, se pueden utilizar para encriptar la conexin remota a los servicios de la LAN. Administradores con recursos basados en PPP, o accesos de tipo dial-up (como bancos de mdems, o cuentas masivas de ISP), pueden ser utilizados para sortear con xito las barreras del cortafuegos. Debido a que son conexiones directas, las conexiones de mdems se encuentran tpicamente detrs de un cortafuegos/puerta de enlace. Sin embargo, pueden hacerse excepciones para los usuarios remotos con conexiones de banda ancha. Usted puede configurar iptables para aceptar conexiones de clientes remotos SSH. Por ejemplo, las siguientes reglas permiten acceso remoto SSH:
[root@myServer ~ ] # iptables -A INPUT -p tcp --dport 22 -j ACCEPT [root@myServer ~ ] # iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT

Estas reglas permiten ingreso y egreso para un sistema individual, como una PC directamente conectada a Internet, o a un cortafuegos/puerta de enlace. Sin embrago, no permiten a los nodos detrs de un cortafuegos/puerta de enlace que tengan acceso a estos servicios. Para permitir acceso LAN a estos servicios, puede utilizar Network Address Translation (NAT) con reglas de filtro iptables.

3.8.5. Reglas FORWARD y NAT


La mayora de los ISPs proveen slo un nmero limitado de direcciones IP disponibles pblicamente para sus clientes.

118

Reglas FORWARD y NAT Los administradores deben, por lo tanto, encontrar formas alternativas de compartir el acceso a los servicios de Internet, sin darle por ello una direccin IP pblica a cada nodo de la LAN. Utilizar direcciones IP privadas es la manera ms comn de permitirle a todos los nodos de una LAN que tengan un acceso correcto, tanto interno como externo, a los servicios de red. Los enrutadores de borde (como los cortafuegos) pueden recibir transmisiones entrantes desde Internet y enrutar los paquetes hacia el nodo LAN correspondiente. Al mismo tiempo, los cortafuegos/ puertas de enlace pueden enrutar peticiones salientes de un nodo de la LAN hacia el servicio de Internet remoto. This forwarding of network traffic can become dangerous at times, especially with the availability of modern cracking tools that can spoof internal IP addresses and make the remote attacker's machine act as a node on your LAN. Para impedir esto, iptables provee polticas de ruteado y reenvo que se pueden implementar para prevenir el uso anormal de los recursos de red. La cadena FORWARD permite a un administrador controlar hacia dnde se pueden rutear los paquetes dentro de la LAN. Por ejemplo, para permitir el reenvo para toda la LAN (asumiendo que el cortafuego/puerta de enlace tiene asignado una direccin IP interna en eth1), use las siguientes reglas:
[root@myServer ~ ] # iptables -A FORWARD -i eth1 -j ACCEPT [root@myServer ~ ] # iptables -A FORWARD -o eth1 -j ACCEPT

Esta regla le da a los sistemas detrs del cortafuego/puerta de enlace el acceso a la red interna. La puerta de enlace rutea los paquetes desde un nodo de la LAN a su nodo destino deseado, pasando todos los paquetes a travs del dispositivo eth1.

119

Captulo 3. Asegurando su Red

Nota
Por defecto, la poltica IPv4 en kernels de Fedora deshabilita el soporte para reenvo de IP. Esto evita que las mquinas que utilicen Fedora funcionen como un enrutador dedicado. Para habilitar el reenvo de IP, use el siguiente comando:
[root@myServer ~ ] # sysctl -w net.ipv4.ip_forward=1

Este cambio en la configuracin slo es vlido para la sesin actual; no persiste luego de un reinicio de equipo o del servicio de red. Para poner el reenvo de IP permanente, edite el archivo/etc/sysctl.conf como sigue: Ubique la siguiente lnea:
net.ipv4.ip_forward = 0

Y edtela para que se lea:


net.ipv4.ip_forward = 1

Use el siguiente comando para habilitar el cambio en el archivo sysctl.conf:


[root@myServer ~ ] # sysctl -p /etc/sysctl.conf

3.8.5.1. Postruteado y enmascarado de IP


Accepting forwarded packets via the firewall's internal IP device allows LAN nodes to communicate with each other; however they still cannot communicate externally to the Internet. To allow LAN nodes with private IP addresses to communicate with external public networks, configure the firewall for IP masquerading, which masks requests from LAN nodes with the IP address of the firewall's external device (in this case, eth0):
[root@myServer ~ ] # iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

This rule uses the NAT packet matching table (-t nat) and specifies the built-in POSTROUTING chain for NAT (-A POSTROUTING) on the firewall's external networking device (-o eth0). POSTROUTING permite que los paquetes sean alterados cuando estn dejando el dispositivo externo del cortafuegos. El destino -j MASQUERADE se especifica para enmascarar la direccin IP privada de un nodo con la direccin IP externa del cortafuego/puerta de enlace.

3.8.5.2. Preruteo
Si usted posee un servidor en su red interna que quiere que est disponible desde el exterior, puede utilizar -j DNAT, objetivo de la cadena PREROUTING de NAT para especificar una IP de destino, y un puerto donde los paquetes recibidos que pidan una conexin a su servicio interno, puedan ser reenviados.

120

Software malicioso y suplantacin de direcciones IP Por ejemplo, si quiere reenviar pedidos HTTP entrantes a su servidor HTTP Apache dedicado en 172.31.0.23, use el siguiente comando:
[root@myServer ~ ] # iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 172.31.0.23:80

Esta regla especifica que la tabla nat usa la cadena predefinida PREROUTING para enviar pedidos HTTP entrantes exclusivamente al la direccin IP destino listado 172.31.0.23.

Nota
Si tiene una poltica predeterminada de DROP en su cadena FORWARD, debe agregar una regla para reenviar todos los pedidos HTTP entrantes para que sea posible el ruteo NAT destino. Para hacerlo, use el siguiente comando:
[root@myServer ~ ] # iptables -A FORWARD -i eth0 -p tcp --dport 80 -d 172.31.0.23 -j ACCEPT

Esta regla reenva todos los pedidos HTTP entrantes desde el cortafuego al destino pretendido; el Servidor HTTP APache detrs del cortafuego.

3.8.5.3. IPTables y las ZDM


Puede crear reglas de iptables para enrutar trfico a ciertos equipos, como por ejemplo un servidor HTTP o FTP dedicado, en una zona desmilitarizada (DMZ, por las iniciales en ingls de DeMilitarized Zone). Un DMZ es una subred local especial dedicada a proveer servicios en un transporte pblico, como lo es Internet. Por ejemplo, para establecer una regla para enrutar peticiones HTTP entrantes a un servidor dedicado HTTP en 10-0-4-2 (fuera del rango 192.168.1.0/24 de la LAN), NAT utiliza la tabla PREROUTING para reenviar los paquetes a la direccin apropiada:
[root@myServer ~ ] # iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --todestination 10.0.4.2:80

Con este comando, todas las conexiones HTTP al puerto 80 provenientes desde fuera de la LAN son encaminadas al servidor HTTP en la red separada del resto de la red interna. Esta forma de segmentacin de red puede proveer seguridad permitiendo conexiones HTTP a mquinas en la red. Si el servidor HTTP est configurado para aceptar conexiones seguras, entonces el puerto 443 debe ser reenviado tambin.

3.8.6. Software malicioso y suplantacin de direcciones IP


Reglas ms elaboradas pueden ser creadas para que controlen el acceso a subredes especficas, o incluso para nodos especficos, dentro de la LAN. Puede tambin restringir ciertas aplicaciones o programas de carcter dudoso como troyanos, gusanos, y dems virus cliente/servidor, y evitar que entren en contacto con sus servidores. Por ejemplo, algunos troyanos examinan redes para ver los servicios en los puertos 31337 a 31340 (llamados los puertos elite en la terminologa de craqueo).

121

Captulo 3. Asegurando su Red Dado que no hay servicios legtimos que se comunican va estos puertos no estndares, su bloqueo puede disminuir efectivamente las posibilidades de que nodos infectados en su red se comuniquen con sus servidores maestros remotos. Las siguientes reglas eliminan todo el trfico TCP que intenta usar el puerto 31337:
[root@myServer ~ ] # iptables -A OUTPUT -o eth0 -p tcp --dport 31337 --sport 31337 -j DROP [root@myServer ~ ] # iptables -A FORWARD -o eth0 -p tcp --dport 31337 --sport 31337 -j DROP

Tambin se puede bloquear conexiones salientes que intenten suplantar los rangos de direcciones IP privadas para infiltrarse en su LAN. Por ejemplo, si su red usa el rango 192.168.1.0/24, se puede disear una regla que instruya al dispositivo de red del lado de Internet (por ejemplo, eth0) para que descarte cualquier paquete en ese dispositivo con una direccin en el rango IP de su red local. Dado que se recomienda rechazar paquetes reenviados como una poltica predeterminada, cualquier otra direccin IP mentida al dispositivo del lado externo (eth0) se rechaza automticamente.
[root@myServer ~ ] # iptables -A FORWARD -s 192.168.1.0/24 -i eth0 -j DROP

Nota
Existe una distincin entre los destinos DROP y REJECT cuando se trabaja con reglas agregadas. El destino RECHAZAR niega acceso y regresa un error de conexin denegada a los usuarios que intenten conectarse al servicio. El destino ABANDONAR, como su nombre lo indica, abandona el paquete sin previo aviso. Los administradores pueden usar su propia discrecin cuando usen estos destinos. Sin embargo, para evitar la confusin del usuario e intentos de continuar conectando, el destino REJECT es recomendado.

3.8.7. IPTables y el seguimiento de la conexin


Puede inspeccionar y restringir conexiones a servicios basados en sus estados de conexin. Un mdulo dentro de iptables utiliza un mtodo denominado rastreo de conexin para almacenar datos acerca de las conexiones recibidas. Puede permitir o negar acceso basndose en los siguientes estados de conexin: NEW Un paquete que pide una nueva conexin, tal como un pedido HTTP. ESTABLISHED Un paquete que es parte de una conexin existente. RELATED Un paquete que est pidiendo una nueva conexin, pero que es parte de una existente. Por ejemplo, FTP usa el puerto 21 para establecer una conexin, pero los datos se transfieren en un puerto diferente (normalmente el puerto 20). INVALID Un paquete que no es parte de ninguna conexin en la tabla de seguimiento de conexiones. Puede utilizar toda la funcionalidad del rastreo de conexin iptables con cualquier protocolo, an si l mismo se encuentra inactivo (como por ejemplo un protocolo UDP). EL siguiente ejemplo le

122

IPv6 muestra una regla que utiliza rastreo de conexin para reenviar solamente los paquetes que estn asociados con una conexin establecida:
[root@myServer ~ ] # iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

3.8.8. IPv6
La introduccin de la siguiente generacin del Protocolo de Internet, llamado IPv6, expande ms all de los lmites de las direcciones de 32-bit de IPv4 (o IP). IPv6 soporta direcciones de 128-bit, y las redes transportadoras que pueden soportar IPv6 son por lo tanto capaces de manejar un nmero ms grande de direcciones ruteables que el IPv4. Fedora soporta reglas de cortafuego para IPv6 utilizando el subsistema Netfilter 6 y el comando ip6tables. En Fedora 14, los servicios de IPv4 e IPv6 estn habilitados por defecto. La sintaxis del comando ip6tables es idntica a iptables en todos los aspectos menos en que soporta direcciones de 128-bit. Por ejemplo, use el siguiente comando para habilitar conexiones SSH en un servidor de red para IPv6:
[root@myServer ~ ] # ip6tables -A INPUT -i eth0 -p tcp -s 3ffe:ffff:100::1/128 --dport 22 -j ACCEPT

Para ms informacin acerca de redes IPv6, vaya a la Pgina de Informacin sobre IPv6 en http:// www.ipv6.org/.

3.8.9. Recursos adicionales


Hay varios aspectos de cortafuegos y del subsistema Netfilter de Linux que no pueden ser cubiertos en este captulo. Para ms informacin consulte las referencias que ofrecemos a continuacin.

3.8.9.1. Documentacin instalada del cortafuego


Dirjase a la Seccin 3.9, IPTables para obtener informacin ms detallada del comando iptables, incluyendo definiciones de muchas opciones de comando. La pgina man de iptables contiene un resumen de las opciones.

3.8.9.2. Sitios web tiles de cortafuego


http://www.netfilter.org/ La pgina oficial del proyecto Netfilter e iptables. http://www.tldp.org/ El Proyecto de Documentacin de Linux contiene varias guas tiles sobre la creacin y administracin de cortafuegos. http://www.iana.org/assignments/port-numbers La lista oficial de puertos de servicios comunes y registrados, segn fueron asignados por IANA (Internet Assigned Numbers Authority).

3.8.9.3. Documentacin relacionada


Red Hat Linux Firewalls, por Bill McCarty; Red Hat Press un manual de referencia completo para poder levantar cortafuegos de red o de servidores, utilizando tecnologa de cdigo abierto para filtrado de paquetes, como por ejemplo Netfilter o iptables. Los temas que se tratan van desde el anlisis de logs de cortafuegos, desarrollo de reglas de cortafuegos, y diferentes mtodos de personalizacin del cortafuegos utilizando numerosas herramientas grficas. 123

Captulo 3. Asegurando su Red Linux Firewalls, por Robert Ziegler; New Riders Press contiene gran cantidad de informacin para poder levantar cortafuegos utilizando tanto ipchains de un kernel 2.2, como Netfilter o iptables. Tambin son tratados otros temas relacionados con la seguridad, como problemas con el acceso remoto, o deteccin de intrusos en el sistema.

3.9. IPTables
Con Fedora estn incluidas herramientas avanzadas para el filtrado de paquetes el proceso dentro de kernel que permite controlar a los paquetes de red mientras estn ingresando a nuestro entorno, mientras lo estn recorriendo y cuando lo abandonan. Las versiones del kernel anteriores a la 2.4, dependan de ipchains para el filtrado de paquetes, y utilizaban listas de reglas aplicadas a los paquetes en cada paso del proceso de filtrado. El kernel 2.4 introdujo la utilizacin de iptables (tambin llamado netfilter), que si bien es similar a ipchains, expande enormemente el rango y la posibilidad de control disponible para filtrar los paquetes de red. El siguiente captulo se dedica a los conceptos bsicos del filtrado de paquetes, explica las diferentes opciones disponibles con los comandos de iptables, y explica como las reglas de filtrado pueden ser preservadas entre los reinicios del sistema. Dirjase a la Seccin 3.9.6, Recursos adicionales para obtener instrucciones sobre cmo construir reglas de iptables y configurar un cortafuego basado en ellas.

Importante
El mecanismo de un cortafuegos establecido por defecto con un kernel 2.4 o superior es iptables, pero iptables no puede ser utilizado si ipchains se encuentra en ejecucin. Si ipchains est presente en el momento del arranque, el kernel enva un mensaje de error y no puede iniciar iptables. La funcionalidad de ipchains no es afectada por estos errores.

3.9.1. Filtrado de Paquete


El kernel de Linux utiliza la herramienta Netfilter para filtrar los paquetes, permitiendo que alguno de ellos sean recibidos por el sistema (o que pasen a travs de l), y evitando que lo hagan otros. Esta herramienta est predefinida en el kernel, y posee tres tablas o listas de reglas predeterminadas de la forma siguiente: filter La tabla predeterminada para el manejo de paquetes de red. nat Se usa para alterar paquetes que crean una nueva conexin y para Network Address Translation (NAT). mangle Usada para tipos especficos de alteraciones de paquetes. Cada tabla tiene un grupo de cadenas predefinidas, que corresponden a las acciones realizadas por netfilter sobre el paquete. Las cadenas predefinidas para la tabla filter son las siguientes: INPUT Se aplica a paquetes de red que son destinados a este equipo. OUTPUT Se aplica a paquetes de red generados localmente.

124

Filtrado de Paquete FORWARD Se aplica a paquetes de la red ruteados a travs de este equipo. Las cadenas predeterminadas para la tabla nat son las siguientes: PREROUTING Altera los paquetes de la red cuando llegan. OUTPUT Altera los paquetes de la red generados localmente antes de que se enven. POSTROUTING Altera los paquetes de la red antes de ser enviados. Las cadenas predeterminadas para la tabla mangle son: INPUT Altera los paquetes de red destinados a este equipo. OUTPUT Altera los paquetes de la red generados localmente antes de que se enven. FORWARD Altera los paquetes de red ruteados a travs de este equipo. PREROUTING Altera los paquetes que vienen de la red antes de ser ruteados. POSTROUTING Altera los paquetes de la red antes de ser enviados. Cada paquete de red recibido por, o enviado con un sistema Linux es sujeto de (o por) al menos una tabla. Sin embargo, un paquete puede ser sujeto por varias reglas pertenecientes a cada tabla, antes de poder emerger al final de la cadena. La estructura y el propsito de estas reglas pueden variar, pero por lo general lo que buscan es un paquete yendo o viniendo desde una direccin IP determinada (o conjunto de direcciones), cada vez que se utilice un protocolo y un servicio de red determinados.

Nota
Por defecto, las reglas del cortafuego se graban en los archivos /etc/sysconfig/iptables o /etc/sysconfig/ip6tables. El servicio iptables se activa antes que cualquier otro servicio relacionado con DNS, cuando el sistema Linux es iniciado. Esto significa que las reglas de cortafuegos pueden slo hacer referencia a direcciones IP numricas (como por ejemplo, 192.168.0.1). En este tipo de reglas, los nombres del dominio (por ejemplo, host.example.com) producen errores. Regardless of their destination, when packets match a particular rule in one of the tables, a target or action is applied to them. If the rule specifies an ACCEPT target for a matching packet, the packet skips the rest of the rule checks and is allowed to continue to its destination. If a rule specifies a DROP target, that packet is refused access to the system and nothing is sent back to the host that sent the packet. If a rule specifies a QUEUE target, the packet is passed to user-space. If a rule specifies the optional REJECT target, the packet is dropped, but an error packet is sent to the packet's originator. Cada cadena posee una poltica por defecto para las acciones de ACCEPT, DROP, REJECT, o QUEUE. Si ninguna de estas reglas en la cadena se aplica al paquete, entonces el paquete es tratado de acuerdo a la poltica establecida por defecto. El comando iptables configura estas tablas, as como crea algunas nuevas si es necesario.

125

Captulo 3. Asegurando su Red

3.9.2. Opciones de la lnea de comandos de IPTables


Las reglas para el filtrado de paquetes se crean usando el comando iptables. Los aspectos siguientes del paquete son los ms usados como criterios: Tipo de Paquete Especifica el tipo de paquete que filtra el comando. Fuente/Destino del Paquete Especifica qu paquete se filtra basado en el fuente/destino del paquete. Destino Especifica qu accin se toma sobre los paquetes que coinciden con el criterio de ms arriba. Para obtener ms informacin acerca de opciones especficas acerca de estos aspectos de los paquetes, por favor vea la Seccin 3.9.2.4, Opciones de coincidencia de IPTables y la Seccin 3.9.2.5, Opciones de destino. Las opciones utilizadas con reglas especficas de iptables, para que puedan ser vlidas, deben ser agrupadas lgicamente, fundamentadas en el propsito y las condiciones de la regla en su totalidad. En el recordatorio de esta seccin se explican opciones comnmente utilizadas para el comando iptables.

3.9.2.1. Estructura de las opciones de comandos de IPTables


Muchos comandos iptables tienen la siguiente estructura:
iptables [-t <table-name>] <command> <chain-name> \ <parameter-1> <option-1> \ <parametern> <option-n>

<table-name> Especifica la tabla donde la regla aplica. Si es omitida, la tabla filter es usada. <command> Especifica la accin a efectuar, tal como agregar o eliminar una regla. <chain-name> Especifica la cadena a editar, crear o eliminar. <parameter>-<option> pairs Parameters and associated options that specify how to process a packet that matches the rule. La longitud y complejidad de un comando iptables puede cambiar significativamente, basado en su propsito. Por ejemplo, un comando para eliminar una regla de una cadena puede ser muy corto: iptables -D <chain-name> <line-number> En contraste, un comando que aada una regla que filtre los paquetes provenientes de una subred determinada, utilizando una variedad de parmetros y opciones especficas, podra ser bastante extenso. Cuando construya comandos iptables, es importante recordar que algunos parmetros y opciones requieren de otros parmetros y de otras opciones para poder constituir una regla vlida. Esto puede producir un efecto cascada, con los futuros parmetros pidiendo otros nuevos. La regla no ser vlida hasta que no se satisfagan cada parmetro y cada opcin que requiera otro conjunto de opciones y parmetros. Con iptables -h se puede ver una lista comprensiva de la estructura de los comandos de iptables. 126

Opciones de la lnea de comandos de IPTables

3.9.2.2. Opciones de comandos


Las opciones de comando dan instrucciones a iptables para que realice una accin especfica. Solo una opcin de comando es permitida para cada comando iptables. Con la excepcin del comando help, todos los dems deben ser escritos con caracteres maysculos. Los comandos de iptables son los siguientes: -A Agregan una regla al final de la cadena especificada. A diferencia de la opcin -I descripta ms abajo, No toma un entero como argumento. Siempre agrega la regla al final de la cadena especificada. -C Verifica una regla determinada antes de aadirla a la cadena especificada por el usuario. Este comando puede ayudarle a construir reglas complejas de iptables al solicitarle parmetros y opciones adicionales. -D <integer> | <rule> Deletes a rule in a particular chain by number (such as 5 for the fifth rule in a chain), or by rule specification. The rule specification must exactly match an existing rule. -E Renombra una cadena definida por el usuario. Una cadena definida por el usuario es cualquier cadena que no sea una de las ya existentes, establecidas por defecto. (Vea ms abajo la opcin -N para obtener informacin acerca de como crear cadenas definidas por el usuario). Este es un cambio de tipo esttico y no afecta la estructura de la tabla.

Nota
Si intenta renombrar alguna de las cadenas predeterminadas, el sistema informar un error de Coincidencia no encontrada. No puede renombrar las cadenas predeterminadas.

-F Limpia la cadena seleccionada, lo que efectivamente borra cada regla en la cadena. Si no se especifica una cadena, limpia todas las reglas de cada cadena. -h Provee una lista de estructuras de comando, as como un resumen rpido de los parmetros y opciones de los comandos. -I [<integer>] Inserts the rule in the specified chain at a point specified by a user-defined integer argument. If no argument is specified, the rule is inserted at the top of the chain.

Importante
Como se mencion arriba, el orden de las reglas en una cadena determina cules reglas se aplican a qu paquetes. Esto es importante para recordar cuando se agreguen reglas que usen la opcin -A o -I. Esto es especialmente importante cuando se agregan reglas utilizando la opcin -I con un argumento entero. Si especifica un nmero existente cuando agregue una regla a una cadena, iptables aade la nueva regla antes que (o sobre) la regla existente.

127

Captulo 3. Asegurando su Red -L Muestra todas las reglas en la cadena especificada luego del comando. Para listar todas las reglas de todas las cadenas en la tabla de filtro establecida por defecto, no especifique ni una cadena ni una tabla. De lo contrario, la siguiente sintaxis debera ser utilizada para listar las reglas de una cadena determinada, en una tabla determinada:
iptables -L <chain-name> -t <table-name>

Las opciones adicionales para la opcin -L del comando, que proveen el nmero de regla y permiten descripciones de reglas ms detalladas se describen en la Seccin 3.9.2.6, Opciones de listado. -N Crea una nueva cadena con un nombre dado por el usuario. El nombre debe ser nico, sino se mostrar un mensaje de error. -P Pone la poltica predeterminada para la cadena especificada, para que cuando los paquetes atraviesen toda la cadena sin encontrar una regla con la que coincidan, se los enva al destino especificado, sea ACCEPT o DROP. -R Replaces a rule in the specified chain. The rule's number must be specified after the chain's name. The first rule in a chain corresponds to rule number one. -X Borra una cadena definida por el usuario. No se puede borrar una cadena predefinida. -Z Pone los contadores de bytes y de paquetes a 0 en todas las cadenas de una tabla.

3.9.2.3. Opciones de parmetros de IPTables


Ciertos comandos de iptables, incluyen aquellos para agregar, adjuntar, borrar, insertar o borrar reglas dentro de una cadena particular, que requieren varios parmetros para construir una regla de filtrado de paquetes. -c Reinicia los contadores de una regla particular. Este parmetro acepta las opciones PKTS y BYTES para especificar qu contadores resetear. -d Pone el destino por nombre, direccin IP o red para un paquete que coincide con la regla. Cuando se especifique una red, los siguientes formatos de direccin de IP /mscara de red son soportados: N.N.N.N/M.M.M.M Donde N.N.N.N es el rango de direcciones IP y M.M.M.M es la mscara de red. N.N.N.N/M Donde N.N.N.N es el rango de direcciones IP y M son los bits de mscara. -f Aplica esta regla slo a paquetes fragmentados. Puede usar el signo de exclamacin (!) despus de este parmetro para especificar que solamente se aceptan paquetes desfragmentados.

128

Opciones de la lnea de comandos de IPTables

Nota
La distincin entre paquetes fragmentados y defragmentados es deseable, sin importar que los paquetes fragmentados sean una parte estndar del protocolo IP. Originally designed to allow IP packets to travel over networks with differing frame sizes, these days fragmentation is more commonly used to generate DoS attacks using mal-formed packets. It's also worth noting that IPv6 disallows fragmentation entirely.

-i Establece la interfaz de red entrante, como ser por ejemplo, eth0 o ppp0. Con iptables, este parmetro opcional solo puede ser utilizado con las cadenas de INPUT y FORWARD, cuando sean utilizadas con la tabla de filter, y la cadena PREROUTING con las tablas nat y mangle. Este parmetro tambin da soporte a todas las siguientes opciones especiales: El signo de exclamacin (!) Revierte la directiva, significando que las interfaces especificadas de excluyen de esta regla. Signo de suma (+) Un carcter comodn utilizado para relacionar a todas las interfaces que se correspondan con una cadena determinada. Por ejemplo, el parmetro -i eth+ aplicara esta regla a cualquier interfaz Ethernet, pero excluira el resto de las interfases, como por ejemplo, ppp0. Si el parmetro -i se usa pero no se especifica una interfaz, entonces todas las interfases son afectadas por esta regla. -j Salta al destino especificado si un paquete coincide con una regla en particular. Los destinos estndares son ACCEPT, DROP, QUEUE, y RETURN. Existen tambin a disposicin algunas opciones extendidas, a travs de mdulos cargados por defecto con el paquete RPM iptables de Fedora. Algunas de las acciones vlidas de ese mdulo son LOG, MARK, y REJECT, entre otras. Para obtener mayor informacin acerca de estas y de otras acciones, consulte la pgina man de iptables. Esta opcin tambin puede usarse para dirigir el paquete coincidente a una regla particular en una cadena del usuario fuera de la cadena actual, para que se le puedan aplicar otras reglas al paquete. Si no se especifica un destino, el paquete se mueve a la regla siguiente sin hacer nada. El contador de esta regla, sin embargo, se incrementa por uno. -o Establece la interfaz de red saliente para una regla. Esta opcin slo es vlida para las cadenas OUTPUT y FORWARD en la tabla filter, y para la cadena POSTROUTING en las tablas nat y mangle tables. Este parmetro acepta las mismas opciones que el parmetro para la interfaz de red entrante (-i). -p <protocol> Sets the IP protocol affected by the rule. This can be either icmp, tcp, udp, or all, or it can be a numeric value, representing one of these or a different protocol. You can also use any protocols listed in the /etc/protocols file.

129

Captulo 3. Asegurando su Red The "all" protocol means the rule applies to every supported protocol. If no protocol is listed with this rule, it defaults to "all". -s Pone el fuente de un paquete particular usando la misma sintaxis del parmetro de destino (d).

3.9.2.4. Opciones de coincidencia de IPTables


Different network protocols provide specialized matching options which can be configured to match a particular packet using that protocol. However, the protocol must first be specified in the iptables command. For example, -p <protocol-name> enables options for the specified protocol. Note that you can also use the protocol ID, instead of the protocol name. Refer to the following examples, each of which have the same effect:
iptables -A INPUT -p icmp --icmp-type any -j ACCEPT

iptables -A INPUT -p 5813 --icmp-type any -j ACCEPT

Las definiciones de los servicios son provistas en el archivo /etc/services. Para una mejor lectura, es recomendable que se utilice el nombre de los servicios, en lugar de los nmeros de puertos.

Advertencia
Asegure el archivo /etc/services de manera de poder evitar que sea editado por usuarios no autorizados. Si este archivo es editable, los crackers pueden utilizarlo para habilitar puertos en su equipo que de otra manera permaneceran cerrados. Para segurar este archivo, ingrese los siguiente comandos siendo usuario root:

[root@myServer ~]# chown root.root /etc/services [root@myServer ~]# chmod 0644 /etc/services [root@myServer ~]# chattr +i /etc/services

Esto previene que se pueda renombrar, borrar o crear enlaces al archivo.

3.9.2.4.1. Protocolo TCP


Estas opciones de comparacin estn disponibles para el protocolo TCP (-p tcp): --dport Pone el puerto destino del paquete. Para configurar esta opcin, use un nombre de servicio de red (tal como www o smtp); o un nmero de puerto; o un rango de nmeros de puerto. Para especificar un rango de nmeros de puerto, separe los dos nmeros con dos puntos (:). Por ejemplo: -p tcp --dport 3000:3200. El rango ms grande aceptable es 0:65535. Use el signo de exclamacin (!) despus de la opcin --dport para que seleccione todos los paquetes que no usen ese servicio de red o puerto.

130

Opciones de la lnea de comandos de IPTables Para navegar por los nombres o alias de servicios de red y sus nmeros de puerto, vea el archivo / etc/services. La opcin --destination-port es sinnimo de --dport. --sport Pone el puerto de origen del paquete y usa las mismas opciones que --dport. La opcin --source-port es sinnimo de --sport. --syn Se aplica a todos los paquetes TCP diseados para iniciar una comunicacin, comnmente llamados paquetes SYN. Cualquier paquete que lleve datos no se toca. Use un signo de exclamacin (!) despus de --syn para que seleccione los paquetes no-SYN. --tcp-flags <tested flag list> <set flag list> Allows TCP packets that have specific bits (flags) set, to match a rule. La opcin de correspondencia --tcp-flags acepta dos parmetros. El primero es la mscara; una lista separada por comas de las marcas a ser examinadas en el paquete. El segundo parmetro es una lista separada por comas de las marcas que deben ser definidas en la regla con la que se pretende concordar. Las posibles banderas son: ACK FIN PSH RST SYN URG ALL NONE Por ejemplo, una regla iptables que contenga las siguientes especificaciones solo se corresponder con paquetes TCP que tengan definida la marca SYN, y que no tengan definidas las marcas ACK ni FIN: --tcp-flags ACK,FIN,SYN SYN Use el signo de exclamacin (!) despus de --tcp-flags para revertir el efecto de coincidencia de la opcin. --tcp-option Intenta corresponderse con opciones especficas de TCP que puedan establecerse dentro de un paquete determinado. Esta opcin de correspondencia puede tambin revertirse con el signo de exclamacin (!).

3.9.2.4.2. Protocolo UDP


Estas opciones de coincidencias estn disponibles para el protocolo UDP (-p udp):

131

Captulo 3. Asegurando su Red --dport Especifica el puerto de destino del paquete UDP, utilizando el nombre del servicio, el nmero de puerto, o rango de nmeros de puerto. La opcin de correspondencia -destination-port es equivalente. --sport Especifica el puerto de origen del paquete UDP, utilizando el nombre del servicio, el nmero de puerto, o rango de nmeros de puertos. La opcin de correspondencia --sourceport es equivalente. Con las opciones --dport y --sport, para especificar un rango vlido de puertos, separe ambos nmeros del rango con dos puntos (:). Por ejemplo: -p tcp --dport 3000:3200. El rango vlido ms extenso que puede aceptarse es 0:65535.

3.9.2.4.3. Protocolo ICMP


Las siguientes opciones de coincidencias estn disponibles en el Protocolo de Mensajes de Control de Internet (ICMP) (-p icmp): --icmp-type Establece el nombre y nmero del tipo de ICMP a corresponderse con la regla. Puede obtenerse una lista de nombres ICMP vlidos al ingresar el comando iptables -p icmp -h.

3.9.2.4.4. Mdulos adicionales para opciones de coincidencia


Opciones de coincidencias adicionales estn disponibles a travs de los mdulos cargados por el comando iptables. To use a match option module, load the module by name using the -m <module-name>, where <module-name> is the name of the module. Por defecto hay disponibles muchos mdulos. Tambin puede crear mdulos para proveer funcionalidad adicional. La siguiente es una lista parcial de los mdulos ms comnmente usados: Mdulo limit Pone lmites sobre cuntos paquetes se toman para una regla particular. Cuando se usa junto con el destino LOG, el mdulo limit puede prevenir una inundacin de paquetes coincidentes que pudieran sobrecargar al sistema de log con mensajes repetitivos o acabar los recursos del sistema. Dirjase a la Seccin 3.9.2.5, Opciones de destino para obtener mayor informacin sobre LOG. El mdulo limit habilita las siguientes opciones: --limit Sets the maximum number of matches for a particular time period, specified as a <value>/<period> pair. For example, using --limit 5/hour allows five rule matches per hour. Los perodos se pueden especificar en segundos, minutos, horas o das. Si no se utiliza un nmero o modificador de tiempo, se asume el valor predeterminado de 3/ hora. --limit-burst Pone un lmite en el nmero de paquetes que pueden coincidir con la regla en cada momento. Esta opcin se especifica como un entero y no se debe usar junto con la opcin --limit. 132

Opciones de la lnea de comandos de IPTables Si no se especifica un valor, el valor predeterminado cinco (5) es asumido. Mdulo state Habilita el chequeo del estado. El mdulo state habilita las siguientes opciones: --state chequea a un paquete con los siguientes estados de conexin: ESTABLISHED El paquete est asociado a otros paquetes en una conexin establecida. Necesita aceptar este estado si quiere mantener una conexin entre un cliente y un servidor. INVALID El paquete es chequeado no est asociado a una conexin conocida. NEW El paquete chequeado es para crear una conexin nueva o es parte de una conexin de doble va que no fue vista previamente. Necesita aceptar este estado si quiere permitir conexiones nuevas a un servicio. RELATED El paquete coincidente est iniciando una conexin relacionada de alguna manera a otra existente. Un ejemplo de esto es FTP, que usa una conexin para el control del trfico (puerto 21) y una conexin separada para la transferencia de datos (puerto 20). Estos estados de conexin pueden ser utilizados combinados con otros, si se los separa con comas, como por ejemplo -m state --state INVALID,NEW. Mdulo mac Habilita el chequeo de la direccin MAC de hardware. El mdulo mac habilita la siguiente opcin: --mac-source Hace corresponder una direccin MAC de la tarjeta de interfaz de red que haya enviado el paquete. Para excluir una direccin MAC de la regla, coloque un signo de admiracin (!) luego de la opcin de correspondencia --mac-source. Vea en la pgina man de iptables para ms opciones de comparacin disponibles a travs de mdulos.

3.9.2.5. Opciones de destino


Cuando un paquete concuerde con una regla en particular, la regla puede dirigir el paquete hacia un nmero de destinos diferentes determinados por la accin apropiada. Cada cadena tiene un objetivo establecido por defecto, que ser utilizado si ninguna de las reglas en esa cadena concuerdan con un paquete, o si ninguna de las reglas que concuerdan con el paquete especifica un destino. Los siguientes son los destinos estndares: <user-defined-chain> A user-defined chain within the table. User-defined chain names must be unique. This target passes the packet to the specified chain. ACCEPT Permite pasar al paquete a su destino o a otra cadena. DROP Descarta el paquete sin responder. El sistema que mand el paquete no es notificado de la falla. QUEUE El paquete es encolado para su manejo por una aplicacin en el espacio del usuario. RETURN Detiene el chequeo del paquete contra las reglas restantes de la cadena. Si el paquete con un destino RETURN coincide con una regla en una cadena llamada por otra cadena, el paquete es devuelto a la primera cadena y contina el chequeo donde qued antes de saltar. Si la regla 133

Captulo 3. Asegurando su Red RETURN se usa en una cadena predefinida y el paquete no se puede mover a una cadena previa, se usa el destino predeterminado para la cadena. Adems, existen a disposicin diversos complementos que permiten especificar otros destinos. Estos complementos son llamados mdulos de destino o mdulos de opcin de concordancia y muchos de ellos slo se aplican a tablas y situaciones especficas. Para obtener ms informacin acerca de los mdulos de opcin de concordancia, dirjase a la Seccin 3.9.2.4.4, Mdulos adicionales para opciones de coincidencia. Existen numerosos mdulos de destino extendidos, muchos de los cuales solo se aplican a ciertas tablas o situaciones. Algunos de los ms populares incluidos por defecto en Fedora son: LOG Registra todos los paquetes que se correspondan con esta regla. Debido a que los paquetes son registrados por el kernel, el archivo /etc/syslog.conf determina donde son escritas estas entradas de registro. Por defecto, son ubicadas en el archivo /var/log/messages. Hay opciones adicionales que se pueden usar despus del destino LOG para especificar la forma en que se realiza el log: --log-level Pone la prioridad de registrado del evento. Vaya a la pgina man de syslog.conf para una lista de los niveles de prioridad. --log-ip-options Registra todas las opciones puestas en la cabecera de un paquete IP. --log-prefix Pone una cadena de hasta 29 caracteres antes de la lnea de registro cuando se escribe. Esto es til cuando se escribe filtros syslog para usar junto con el registrado de paquetes.

Nota
Debido a una cuestin con esta opcin, se debe agregar un espacio al final del valor logprefix.

--log-tcp-options Registra todas las opciones puestas en la cabecera de un paquete TCP. --log-tcp-sequence Escribe el nmero de secuencia de un paquete en el log. REJECT Enva un paquete de error como respuesta al sistema remoto y descarta el paquete. The REJECT target accepts --reject-with <type> (where <type> is the rejection type) allowing more detailed information to be returned with the error packet. The message portunreachable is the default error type given if no other option is used. Refer to the iptables man page for a full list of <type> options. Otras extensiones de accin, incluidas aquellas que son tiles para el enmascaramiento de IP utilizando la tabla nat, o mediante alteracin de paquete utilizando la tabla mangle, pueden ser encontradas en la pgina man de iptables.

3.9.2.6. Opciones de listado


The default list command, iptables -L [<chain-name>], provides a very basic overview of the default filter table's current chains. Additional options provide more information:

134

Guardando las reglas de IPTalbes -v Muestra informacin adicional, como por ejemplo la cantidad de paquetes y los bytes que ha procesado cada cadena, la cantidad de paquetes y los bytes que se ha correspondido con cada regla, y qu interfases se aplican a una regla determinada. -x Expande los nmeros a sus valores exactos. En un sistema activo, el nmero de los paquetes y la cantidad de bytes procesados por una cadena o regla determinada puede estar abreviado en Kilobytes, Megabytes (Megabytes) o Gigabytes. Esta opcin obliga a ser mostrado el nmero entero. -n Muestra las direcciones IP y los nmeros de puerto en su formato numrico, en vez del formato predeterminado de nombre de equipo y nombre de servicio. --line-numbers Muestra las reglas en cada cadena junto a su orden numrico en dicha cadena. Esta opcin es til si se intenta eliminar una regla especfica de una cadena, o para saber dnde insertar una regla dentro de una cadena. -t <table-name> Especifica el nombre de la tabla. Si es omitida, se predetermina la tabla filter,

3.9.3. Guardando las reglas de IPTalbes


Las reglas creadas con el comando iptables son almacenadas en la memoria. Si el sistema es reiniciado antes de guardar el conjunto de reglas de iptables, estas reglas se perdern. Para que las reglas de netfilter sigan vigentes luego de reiniciar el sistema, necesitan ser guardadas. Para salvar reglas de netfilter, ingrese el siguiente comando como usuario root:
/usr/libexec/iptables.init save

Esto ejecuta el programa init de iptables, que a su vez ejecuta el programa /sbin/iptablessave y escribe la configuracin actual de iptables a /etc/sysconfig/iptables. El archivo existente /etc/sysconfig/iptables es guardado como /etc/sysconfig/iptables.save. La prxima vez que el sistema se reinicie, el programa init de iptables aplica nuevamente las reglas guardadas en /etc/sysconfig/iptables utilizando el comando /sbin/iptablesrestore. While it is always a good idea to test a new iptables rule before committing it to the /etc/ sysconfig/iptables file, it is possible to copy iptables rules into this file from another system's version of this file. This provides a quick way to distribute sets of iptables rules to multiple machines.

Importante
Si va a distribuir el archivo /etc/sysconfig/iptables a otras mquinas, debe teclear / sbin/service iptables restart para que las nuevas reglas tengan efecto.

135

Captulo 3. Asegurando su Red

Nota
Fjese la diferencia entre el comando iptables (/sbin/iptables), que es utilizado para manipular las tablas y cadenas que constituyen las funcionalidades de iptables, y el servicio iptables (/sbin/iptables service), que es utilizado para activar y desactivar el servicio de iptables en s.

3.9.4. Programas de control de IPTables


Hay dos mtodos bsicos de controlar iptables en Fedora: Firewall Administration Tool (system-config-firewall) A graphical interface for creating, activating, and saving basic firewall rules. Refer to Seccin 3.8.2, Configuracin bsica de un cortafuego for more information. /sbin/service iptables <option> Used to manipulate various functions of iptables using its initscript. The following options are available: start Si el cortafuego est configurado (es decir, /etc/sysconfig/iptables existe), se detienen todos los iptables completamente y se los vuelve a iniciar con el comando /sbin/ iptables-restore. Esta opcin funciona solamente si el mdulo de kernel ipchains no es cargado. Para chequear si este mdulo est cargado, teclee el siguiente comando como root:
[root@MyServer ~]# lsmod | grep ipchains

Si este comando no muestra salida, significa que no est cargado. Si es necesario, use el comando /sbin/rmmod para eliminar el mdulo. stop Si el cortafuego est ejecutndose, las reglas del cortafuego en la memoria son limpiadas y todos los mdulos y ayudantes de iptables son descargados. Si la directiva IPTABLES_SAVE_ON_STOP del archivo de configuracin /etc/sysconfig/ iptables-config es alterada de su valor original a yes, las reglas actuales sern guardadas en /etc/sysconfig/iptables y todas las reglas existentes sern trasladadas a /etc/ sysconfig/iptables.save. Dirjase a la Seccin 3.9.4.1, Archivo de Configuracin de los Scripts de Control de IPTables para obtener mayor informacin sobre el archivo iptables-config. restart Si un cortafuegos est ejecutndose, sus reglas en la memoria sern eliminadas, y el cortafuegos es iniciado nuevamente si es que est configurado en /etc/sysconfig/ iptables. Esta opcin solo funciona si el mdulo ipchains del kernel no est cargado. Si la directiva IPTABLES_SAVE_ON_RESTART en el archivo de configuracin /etc/ sysconfig/iptables-config es alterada de su valor original a yes, las reglas actuales sern guardadas en /etc/sysconfig/iptables y cualquier otra regla existente ser trasladada a /etc/sysconfig/iptables.save. Dirjase a la Seccin 3.9.4.1, Archivo de Configuracin de los Scripts de Control de IPTables para obtener mayor informacin sobre el archivo iptables-config. status Muestra el estado del cortafuego y lista todas las reglas activas

136

Programas de control de IPTables La configuracin establecida por defecto para esta opcin muestra direcciones IP en cada regla. Para mostrar dominios y nombres de equipos, edite el archivo /etc/sysconfig/ iptables-config y modifique el valor de IPTABLES_STATUS_NUMERIC a no. Para obtener ms informacin acerca del archivo iptables-config, consulte la Seccin 3.9.4.1, Archivo de Configuracin de los Scripts de Control de IPTables . panic Limpia todas las reglas del cortafuego. Se configura como poltica para todas las tablas a DROP. Esta opcin puede ser til si se sabe que un servidor est comprometido. En vez de desconectarlo fsicamente de la red o apagarlo, puede usar esta opcin para detener todo trfico posterior, pero dejando a la computadora lista para un anlisis forense. save Guarda las reglas del cortafuego en /etc/sysconfig/iptables utilizando iptables-save. Vea en la Seccin 3.9.3, Guardando las reglas de IPTalbes ms informacin.

Nota
Para utilizar los mismos comandos de initscript para controlar a netfilter para IPv6, sustituya ip6tables por iptables en los comandos /sbin/service listados en esta seccin. Para obtener mayor informacin acerca de IPv6 o netfilter, vea Seccin 3.9.5, IPTables e IPv6.

3.9.4.1. Archivo de Configuracin de los Scripts de Control de IPTables


El comportamiento de los scripts de inicio de iptables se controlan por el archivo de configuracin / etc/sysconfig/iptables-config. La siguiente es una lista de las directivas contenidas en este archivo: IPTABLES_MODULES Especifica una lista separada por comas de los mdulos iptables adicionales a cargar cuando se active el cortafuego. Estos pueden incluir el rastreo de conexin y ayudantes NAT. IPTABLES_MODULES_UNLOAD Descarga los mdulos al reiniciar y detener. Esta directiva acepta los siguientes valores: yes El valor por defecto. Esta opcin debe ser puesta para conseguir un estado correcto de un reinicio o detenida de un cortafuego. no Esta opcin debe ser puesta slo si hay problemas al descargar los mdulos de netfilter. IPTABLES_SAVE_ON_STOP Guarda las reglas actuales en /etc/sysconfig/iptables cuando el cortafuego es detenido. Esta directiva acepta los siguientes valores: yes Guarda las reglas existentes en /etc/sysconfig/iptables cuando se detiene el cortafuego, moviendo la versin previa al archivo /etc/sysconfig/iptables.save. no El valor por defecto. No guarda las reglas existentes cuando el cortafuego es detenido. IPTABLES_SAVE_ON_RESTART Guarda las reglas actuales del cortafuego cuando es reiniciado. Esta directiva acepta los siguientes valores: yes Guarda las reglas existentes en /etc/sysconfig/iptables cuando el cortafuego es reiniciado, moviendo la versin previa al archivo /etc/sysconfig/iptables.save.

137

Captulo 3. Asegurando su Red no El valor predeterminado. No guarda las reglas existentes cuando se reinicia el cortafuego. IPTABLES_SAVE_COUNTER Guarda y restaura todos los contadores de paquetes y de bytes en todas las cadenas y reglas. Esta directiva acepta los siguientes valores: yes Guarda los valores de los contadores. no El valor predeterminado. No guarda los valores de los contadores. IPTABLES_STATUS_NUMERIC Muestra las direcciones IP en formato numrico en vez de dominios y nombres de equipo. Esta directiva acepta los siguientes valores: yes El valor predeterminado. Solo devuelve la direccin IP dentro de una salida de estado. no Devuelve el dominio o nombres de equipos en una salida de estado.

3.9.5. IPTables e IPv6


El paquete iptables incluye soporte para el protocolo de Internet de prxima generacin IPv6. El comando empleado para manipular el netfilter de IPv6 es ip6tables. La mayora de las directivas para este comando son idnticas a aquellas utilizadas para iptables, excepto que la tabla nat no es an soportada. Esto significa que an no es posible realizar tareas de traslados sobre direcciones de redes IPv6, como ser, por ejemplo, enmascaramiento y reenvo de puertos. Las reglas de ip6tables se guardan en el archivo /etc/sysconfig/ip6tables. Las reglas previas guardadas antes por los scripts de inicio de ip6tables se guardan en el archivo /etc/ sysconfig/ip6tables.save. Las opciones de configuracin para el programa init ip6tables son almacenadas en /etc/ sysconfig/ip6tables-config, y los nombres para cada directiva varan significativamente de los correspondientes en iptables. Por ejemplo, la directiva IPTABLES_MODULES de iptables-config: el equivalente en el archivo ip6tables-config es IP6TABLES_MODULES.

3.9.6. Recursos adicionales


Consulte las siguientes referencias para obtener informacin adicional sobre el filtrado de paquetes con iptables. Seccin 3.8, Cortafuegos Contiene un captulo acerca de la funcin de los cortafuegos dentro de una estrategia de seguridad general, as como las estrategias para construir las reglas del mismo.

3.9.6.1. Documentacin instalada de IPTables


man iptables Contiene la descripcin de iptables as como una lista comprensiva de los destinos, opciones y extensiones de comparacin.

3.9.6.2. Sitios web tiles sobre IPTables


http://www.netfilter.org/ El hogar del proyecto netfilter/iptables. Contiene informacin ordenada acerca de iptables, incluyendo un FAQ que describe problemas especficos, y varias guas tiles realizadas por Rusty Russell, el encargado del cortafuegos para IP de Linux. Los diferentes 138

Recursos adicionales tutoriales del sitio abarcan diferentes temas, como ser por ejemplo, una descripcin de los conceptos bsicos de trabajo en redes, filtros de paquetes del kernel y configuraciones NAT.

139

140

Cifrado
Existen dos clases principales de datos que deben ser protegidos: datos en reposo y datos en movimiento. Estas clases de datos son protegidas en forma similar utilizando tecnologa similar, pero la forma en que se implementa esta proteccin puede ser completamente diferente en un caso y en otro. Por s solo, ningn modo de proteccin puede prevenir nuestro sistema de todos los posibles mtodos en que puede llegar a ser daado, ya que la misma informacin puede estar en descanso y en movimiento en diferentes lugares y al mismo tiempo.

4.1. Datos en reposo


Data at rest is data that is stored on a hard drive, tape, CD, DVD, disk, or other media. This information's biggest threat comes from being physically stolen. Laptops in airports, CDs going through the mail, and backup tapes that get left in the wrong places are all examples of events where data can be compromised through theft. If the data was encrypted on the media then you wouldn't have to worry as much about the data being compromised.

4.1.1. Cifrado completo del disco


El cifrado de la particin o del disco completo es una de las mejores formas de proteger sus datos. No solo est protegido cada archivo, sino que tambin el almacenamiento temporal que podra contener parte de estos archivos protegidos. El cifrado de disco completo proteger todos sus archivos, as que no tendr que preocuparse de seleccionar qu archivos proteger y posiblemente olvidando alguno. Desde la liberacin de Fedora 9, sta y cualquier versin posterior tiene soporte nativo para Cifrado LUKS. LUKS (por las iniciales en ingls de Linux Unified Key Setup-on-disk-format) va a cifrar las particiones de su disco duro de modo que cuando su computadora se encuentre apagada, sus datos estarn protegidos. Esto tambin proteger los datos de su computadora de atacantes que intenten ingresar a su equipo en el modo de usuario nico, o que hubieran conseguido el acceso de otra forma. Las herramientas de cifrado total del disco duro, como LUKS, solo protegen sus datos cuando su computadora se encuentra apagada. Una vez que la computadora se encienda, y LUKS haya descifrado el disco, los archivos en ese disco quedarn disponibles para cualquiera que pueda acceder normalmente a ellos. Para proteger sus archivos cuando su computadora est encendida, utilice la herramienta de cifrado total del disco combinada con alguna otra, como ser por ejemplo, el cifrado de archivos. Recuerde tambin bloquear su computadora siempre que se encuentre lejos de ella. Una frase de acceso protegiendo el salvapantallas, establecida para que se active a los pocos minutos de inactividad del equipo, es una buena forma de mantener a los intrusos alejados de l.

4.1.2. Cifrado basado en archivo


GnuPG (GPG) es una versin de cdigo abierto de PGP, que le permite firmar y/o cifrar un archivo o mensaje de correo electrnico. Esto es til para mantener la integridad del mensaje o del archivo, y tambin protege la confidencialidad de la informacin contenida. En el caso del correo electrnico, GPG brinda una proteccin doble. No solo puede proveer proteccin para los datos en reposo, sino tambin para los datos en movimiento, luego que el mensaje ha sido enviado a travs de la red. El cifrado de archivos est orientado para proteger un archivo luego que ste haya abandonado su computadora, como cuando, por ejemplo, enva un CD a travs del correo postal. Algunas herramientas para cifrar archivos pueden dejar rastros de aquellos archivos que cifran, rastros que podran ser recuperados en algunas circunstancias por atacantes que tengan acceso fsico a su equipo. Para proteger de este tipo de ataques a los contenidos de los archivos, utilice la herramienta de cifrado de archivos combinada con alguna otra, como ser por ejemplo, el cifrado total del disco. 141

Captulo 4. Cifrado

4.2. Datos en movimiento


Los datos en movimiento son datos que estn siendo transmitidos en una red. La mayor amenaza a este tipo de datos son las intercepciones y alteraciones que puedan sufrir. Los datos de su nombre de usuario y contrasea nunca deberan ser transmitidos en una red sin que viajen protegidos, ya que podran ser interceptados, y de este modo permitir que alguien se haga pasar por usted, o que pueda obtener acceso a informacin importante. Otro tipo de informacin privada, como son por ejemplo los datos de una cuenta bancaria, deberan tambin ser protegidos cada vez que sean transmitidos a travs de una red. Si lo que se cifra es la sesin entera de red iniciada, entonces no tiene que preocuparse acerca de posibles ataques a los datos que se transmitan en ella. Los datos en movimiento son particularmente vulnerables a los atacantes, ya que ellos no necesitan estar cerca de la computadora en donde estos datos son almacenados: simplemente necesitan estar en algn punto del camino que esos datos estn recorriendo. Los tneles de cifrado pueden proteger los datos a lo largo del camino de las comunicaciones.

4.2.1. Redes privadas virtuales (VPNs, por las iniciales en ingls de Virtual Private Networks)
Las organizaciones con diferentes oficinas satlites, a menudo se conectan entre ellas mediante lneas constituidas especficamente para proteger los datos vitales y asegurar la eficacia en su transferencia. Por ejemplo, muchos comercios utilizan lneas de frame relay o Modo de Transferencia no Sincronizada (ATM, por las iniciales en ingls de Asynchronous Transfer Mode) como una herramienta de comunicaciones de tipo punto-a-punto para enlazar una oficina con el resto. Este puede llegar a ser un recurso algo costoso, especialmente para pequeas o medianas empresas, que quieren expandirse sin tener que pagar los altos costos que involucra la utilizacin de circuitos digitales a medida, generalmente utilizados por empresas de mayor poder adquisitivo. Para poder cubrir estas necesidades, se han desarrollado las Redes Privadas Virtuales (VPNs). Utilizando los mismos principios de funcionamiento que los circuitos a medida, las VPNs permiten comunicaciones digitales seguras entre dos elementos (o redes), creando una Red de Area Global (WAN, por las iniciales en ingls de Wide Area Network) a partir de Redes de Area Local (LANs, Local Area Networks) existentes. La diferencia entre frame relay o ATM reside en el medio de transporte que se utiliza. Las VPNs transmiten sobre IP mediante la utilizacin de datagramas como su medio de transporte, convirtindolas en un conducto seguro a travs de Internet hacia un destino especfico. La mayora de las implementaciones VPN de software libre incorporan estndares abiertos de mtodos de encriptacin para, posteriormente, enmascarar los datos en trnsito. Algunas organizaciones utilizan herramientas VPN de hardware para incrementar la seguridad, mientras que otras utilizan software, o implementaciones derivadas en protocolos. Muchos proveedores ofrecen herramientas VPN de hardware, como Cisco, Nortel, IBM y Checkpoint. Existe una herramienta gratuita de software VPN para Linux denominada FreeS/Wan que utiliza una implementacin estandarizada del Protocolo de Seguridad de Internet (IPsec, por las iniciales en ingls de Internet Protocol Security). Estas herramientas VPN, ya sean derivadas de hardware o de software, trabajan como enrutadores especializados que existen entre la conexin IP desde una oficina hacia otra.

4.2.1.1. Cmo funciona una VPN?


Cuando un paquete se transmite desde un cliente, se enva a travs del enrutador o puerta de enlace VPN, que le aade un Encabezado de autenticacin (AH, por las iniciales en ingls de Authentication Header) para su enrutamiento y autenticacin. Los datos son entonces encriptados y, por ltimo, empaquetados con una Carga Util de Seguridad por Encapsulado (ESP, por las inicales en ingls de Encapsulating Security Payload). Esto, ms adelante, constituye las instrucciones de desencriptado y entrega. 142

Redes privadas virtuales (VPNs, por las iniciales en ingls de Virtual Private Networks) El enrutador VPN que recibe los paquetes, quita la informacin de los cabezales, decripta los datos y los enva a su destinatario (ya sea una estacin de trabajo u otro nodo en la red). Utilizando una conexin de tipo red-a-red, el nodo receptor en la red local recibe los paquetes ya decriptados y listos para su procesamiento. El proceso de encriptado/decriptado en una conexin VPN de tipo red-a-red es transparente al nodo local. Con tal alto nivel de seguridad, un atacante no solo debe tener que poder interceptar el paquete, sino que adems tiene que decriptarlo. Los intrusos que utilizan ataques de tipo intermediario entre un servidor y el cliente, deben tener tambin acceso a, como mnimo, una de las claves privadas para autenticar sesiones. debido a que se utilizan diferentes capas en el proceso de encriptacin y decriptacin, las VPNs son medios seguros y efectivos de conectar mltiples nodos remotos y poder actuar como una intranet unificada.

4.2.1.2. VPNs y Fedora


Fedora ofrece varias opciones en trminos de implementar herramientas de software para conectarse de manera segura en una WAN. La utilizacin de Protocolos de Seguridad de Internet (IPsec), es la herramienta VPN que para ello se utiliza en Fedora, y cubre adecuadamente las necesidades de las organizaciones que posean oficinas sucursales, o usuarios remotos.

4.2.1.3. IPsec
Fedora ofrece soporte de IPsec para conectar equipos remotos y redes entre s, utilizando un tnel seguro en un medio de transporte de red comn, como lo es Internet. IPsec puede ser implementado utilizando una configuracin de tipo equipo-a-equipo (una estacin de trabajo con otra), o de tipo reda-red (una LAN/WAN con otra). La utilizacin de IPsec en Fedora utiliza Intercambio de llave de Internet (IKE, por las iniciales en ingls de Internet Key Exchange), un protocolo implementado por el Equipo de Tareas de Ingeniera de Internet (IETF, por las iniciales en ingls de Internet Engineering Task Force), utilizado para autenticacin mutua y asociaciones seguras entre sistemas conectados.

4.2.1.4. Creando una conexin IPsec


Una conexin IPsec est dividida en dos fases lgicas. En la fase 1, un nodo IPsec inicializa la conexin con una red o nodo remoto. La red o nodo remoto verifica las credenciales del modo solicitante y ambas partes negocian el mtodo de autenticacin para la conexin. En sistemas fedora, una conexin IPsec utiliza un mtodo de llave pre-compartida para la autenticacin del nodo IPsec. En una conexin IPsec de este tipo, ambos equipos deben utilizar la misma clave para poder avanzar hacia la segunda etapa de la conexin IPsec. La segunda etapa de la conexin IPsec consiste en la creacin de una Asociacin de seguridad (SA, por las iniciales en ingls de Security Association) entre los nodos IPsec. Esta etapa genera una base de datos SA con informacin de configuracin, como el mtodo de encriptado, los parmetros de intercambio de clave para la sesin secreta, y dems informaciones necesarias. Esta etapa administra la conexin IPsec actual entre los nodos remotos y las redes. La implementacin de IPsec en Fedora utiliza IKE para compartir llaves entre equipos a travs de Internet. El demonio para llaves racoon administra la distribucin y el intercambio de llave IKE. Para obtener mayor informacin acerca de este demonio, vea la pgina man de racoon.

4.2.1.5. Instalacin de IPsec


La implementacin de IPsec necesita tener instalado el paquete RPM ipsec-tools en todos los equipos IPsec (si es que se est utilizando una configuracin de tipo equipo-a-equipo), o enrutadores 143

Captulo 4. Cifrado (si es es que se est utilizando una configuracin de tipo red-a-red). El paquete RPM contiene bibliotecas esenciales, demonios, y archivos de configuracin para establecer la conexin IPsec, como por ejemplo: /sbin/setkey manipula la administracin de clave y los atributos de seguridad para IPsec en el kernel. Este ejecutable es controlado por el demonio de administracin de clave racoon. Para obtener mayor informacin, consulte la pgina man nmero 8 de setkey. /usr/sbin/racoon el demonio de administracin de clave IKE, utilizado para administrar y controlar las asociaciones de seguridad y el compartido de clave entre los sistemas conectados con IPsec. /etc/racoon/racoon.conf el archivo de configuracin del demonio racoon utilizado para configurar varios aspectos de la conexin IPsec, incluyendo los mtodos de autenticacin y los algoritmos de encriptado utilizados en ella. Para conocer una lista con todas las directivas, consulte la pgina man nmero 5 de racoon.conf. Para configurar IPsec en Fedora, puede utilizar la Herramienta de administracin de red, o editar manualmente la red y los archivos de configuracin de IPsec. Para conectar dos equipos en red utilizando IPsec, vea la Seccin 4.2.1.6, Configuracin de IPsec equipo-a-equipo. Para conectar una LAN/WAN con otra utilizando IPsec, vea la Seccin 4.2.1.7, Configuracin IPsec red-a-red.

4.2.1.6. Configuracin de IPsec equipo-a-equipo


IPsec puede configurarse para conectar un equipo de escritorio o estacin de trabajo con otro mediante una conexin de tipo equipo-a-equipo. Este tipo de conexin utiliza la red a la que cada uno de los equipos se conecta para crear un tnel seguro entre cada equipo. Los requerimientos de una conexin de equipo-a-equipo son mnimos, al igual que la configuracin de IPsec. El equipo necesita solo una conexin dedicada a una red que haga de medio de transporte (como lo es Internet), y Fedora para crear la conexin IPsec.

4.2.1.6.1. Conexin equipo-a-equipo


Una conexin de tipo equipo-a-equipo es una conexin encriptada entre dos sistemas, ambos utilizando IPsec con la misma clave de autenticacin. Con la conexin IPsec activa, cualquier trfico de red entre los dos equipos es encriptada. Para configurar una conexin IPsec de tipo equipo-a-equipo, siga los siguientes pasos para cada equipo:

Nota
Debera realizar los siguientes procedimientos en la mquina actual que est configurando. Evite intentar establecer o configurar conexiones IPsec remotamente. 1. En una terminal, ingrese system-config-network para iniciar la Herramienta de administracin de red. 2. En la pestaa de IPsec, haga clic en Nuevo para iniciar el asistente de configuracin de IPsec.

144

Redes privadas virtuales (VPNs, por las iniciales en ingls de Virtual Private Networks) 3. haga clic en Siguiente para iniciar la configuracin de una conexin IPsec de equipo-a-equipo. 4. Ingrese un nombre nico para la conexin, por ejemplo, ipsec0. Si lo necesita, tilde la casilla para activar automticamente la conexin cada vez que encienda el equipo. Haga clic en Siguiente para continuar. 5. Seleccione Encriptado de equipo a equipo como el tipo de conexin, y luego haga clic en Siguiente. 6. Seleccione el tipo de mtodo de encriptado a utilizarse: manual o automtico. Si selecciona encriptado manual, deber indicar ms adelante una clave de encriptado. Si selecciona encriptado automtico, el demonio racoon se encarga de administrar la clave del encriptado. El paquete ipsec-tools debe estar instalado si quiere utilizar la encriptacin automtica. Haga clic en Siguiente para continuar. 7. Ingrese la direccin IP de equipo remoto. Para determinar la direccin IP del equipo remoto, utilice el siguiente comando en el equipo remoto:
[root@myServer ~] # /sbin/ifconfig <device>

donde <device> es el dispositivo Ethernet que ser usado para la conexin VPN. Si solo existe una tarjeta Ethernet en el sistema, el nombre del dispositivo seguramente ser eth0. El siguiente ejemplo muestra la informacin pertinente de este comando (recuerde que ese es slo un ejemplo):
eth0 Link encap:Ethernet HWaddr 00:0C:6E:E8:98:1D inet addr:172.16.44.192 Bcast:172.16.45.255 Mask:255.255.254.0

La direccin IP es el nmero siguiente a la etiqueta inet addr:.

Nota
Para conexiones de tipo equipo-a-equipo, los dos equipos deberan tener una direccin pblica enrutable. Alternativamente, los dos equipos pueden tener una direccin privada no enrutable (por ejemplo, entre los rangos 10.x.x.x o 192.168.x.x) siempre y cuando se encuentren en la misma LAN. Si los equipos se encuentran en diferentes LANs, o uno de ellos tiene una direccin pblica y el otro una direccin privada, vea la Seccin 4.2.1.7, Configuracin IPsec red-a-red. Haga clic en Siguiente para continuar. 8. Si en el paso 6 se ha seleccionado un cifrado manual, especifique la clave de cifrado a ser utilizada, o haga clic en Generar para crear una. a. Indique una clave de autenticacin o haga clic en Generar para generar una. Puede ser una combinacin de nmeros y letras.

145

Captulo 4. Cifrado b. Haga clic en Siguiente para continuar. 9. Verifique la informacin en la pgina IPsec Resumen, y luego haga clic en el botn Aplicar. 10. Clic en Archivo => Guardar para guardar la configuracin. Tal vez necesite reiniciar la red para que los cambios tengan efecto. Para reiniciar la red, utilice el siguiente comando:
[root@myServer ~]# service network restart

11. Seleccione la conexin IPsec de la lista y haga clic en el botn de Activar. 12. Repita el procedimiento entero para el otro equipo. Es fundamental que se utilice la misma clave del paso 8 en los dems equipos. De lo contrario, IPsec no funcionar. Luego de configurar la conexin IPsec, aparecer en la lista IPsec como se lo indica en la Figura 4.1, Conexin IPsec.

Figura 4.1. Conexin IPsec Los siguientes archivos son creados cuando la conexin IPsec es configurada: /etc/sysconfig/network-scripts/ifcfg-<nickname> /etc/sysconfig/network-scripts/keys-<nickname> /etc/racoon/<remote-ip>.conf /etc/racoon/psk.txt 146

Redes privadas virtuales (VPNs, por las iniciales en ingls de Virtual Private Networks) Si se elige encriptacin automtica, entonces tambin se crea el archivo /etc/racoon/ racoon.conf. Cuando la interfaz se encuentra arriba, /etc/racoon/racoon.conf es modificado para incluir <remote-ip>.conf.

4.2.1.6.2. Configuracin manual de una conexin IPsec de tipo equipo-a-equipo


El primer paso para crear una conexin es obtener informacin tanto del sistema como de la red para cada estacin de trabajo. Para una conexin de tipo equipo-a-equipo, se necesita lo siguiente: La direccin IP de cada equipo Un nombre nico, por ejemplo, ipsec1. Esto es utilizado para identificar la conexin IPsec y poder identificarla de otros dispositivos o conexiones. Una clave de encriptado manual, o automticamente generada por racoon. Una clave de autenticacin pre-compartida que es utilizada a lo largo de la etapa inicial de la conexin, y que tambin ser utilizada luego para intercambiar claves de encriptado durante de la sesin. Por ejemplo, suponga que la estacin de trabajo A y la estacin de trabajo B quieren conectarse entre ellas mediante de un tnel IPsec. Quieren conectarse utilizando una clave pre-compartida con el valor de Key_Value01, y los usuarios acuerdan la utilizacin de racoon para generar y compartir una clave de autenticacin entre cada equipo. Los usuarios de ambos equipos deciden referirse a su conexin como ipsec1..

Nota
Debera elegir una PSK (clave pre-compartida) que utilice una mezcla de caracteres en mayscula y en minscula, nmeros y signos de puntuacin. Una PSK fcil de adivinar constituye un riesgo de seguridad. No es necesario utilizar el mismo nombre de conexin para cada equipo. Debera elegir un nombre que sea conveniente y que tenga sentido para su instalacin. A continuacin mostramos un archivo de configuracin IPsec en la estacin de trabajo A para una conexin IPsec de tipo equipo-a-equipo con la estacin de trabajo B. El nombre nico para identificar la conexin en este ejemplo es ipsec1, de modo que el archivo resultante es denominado /etc/ sysconfig/network-scripts/ifcfg-ipsec1.
DST=X.X.X.XTYPE=IPSEC ONBOOT=no IKE_METHOD=PSK

Para la estacin de trabajo A, X.X.X.X es la direccin IP de la estacin de trabajo B. Para la estacin de trabajo B, X.X.X.X es la direccin IP de la estacin de trabajo A. Esta conexin no est configurada para iniciarse con el arranque del equipo (ONBOOT=no) y utiliza el mtodo de autenticacin de clave pre-compartida (IKE_METHOD=PSK). El siguiente es el contenido del archivo de clave pre-compartida (denominado /etc/sysconfig/ network-scripts/keys-ipsec1) que las dos estaciones de trabajo necesitan para poder

147

Captulo 4. Cifrado autenticarse entre ellas. El contenido de este archivo debe ser idntico en ambas estaciones de trabajo, y solo el usuario root debera ser capaz de leer o escribir en este archivo.
IKE_PSK=Key_Value01

Importante
Para modificar el archivo keys-ipsec1 de modo que solo el usuario root pueda leerlo o editarlo, utilice el siguiente comando luego de haberlo creado:
[root@myServer ~] # chmod 600 /etc/sysconfig/network-scripts/keys-ipsec1

Para modificar la clave de autenticacin en cualquier momento, edite el archivo keys-ipsec1 en ambas estaciones de trabajo. Las dos claves de autenticacin deben ser idnticas para una conexin correcta. El siguiente ejemplo muestra la configuracin especfica de la primera fase de la conexin con el equipo remoto. El archivo es denominado X.X.X.X.conf, donde X.X.X.X es la direccin IP del equipo IPsec remoto. Fijese que este archivo es generado automticamente cuando el tnel IPsec es activado y no debera ser editado directamente.
remote X.X.X.X{ exchange_mode aggressive, main; my_identifier address; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 2 ; } }

El archivo de configuracin de la etapa 1 que se ha creado por defecto cuando se inicia una conexin IPsec, contiene las siguientes directivas utilizadas por la implementacin de IPsec de Fedora: remote X.X.X.X Indica que las siguientes lneas en este archivo de configuracin se aplican solo al nodo remoto identificado por la direccin IP X.X.X.X. exchange_mode aggressive La configuracin establecida por defecto en Fedora para IPsec utiliza un mtodo de autenticacin agresivo, que disminuye los excedentes de la conexin, permitiendo la configuracin de varias conexiones IPsec con mltiples equipos. my_identifier address Indica el mtodo de identificacin a ser utilizado cuando se autentican nodos. Fedora utiliza direcciones IP para identificar nodos. encryption_algorithm 3des Especifica el cifrador de encriptacin utilizado durante la autenticacin. Por defecto, se usa el Estndar de Encriptacin de Datos Triple (3DES, por las iniciales en ingls de Triple Data Encryption Standard).

148

Redes privadas virtuales (VPNs, por las iniciales en ingls de Virtual Private Networks) hash_algorithm sha1; Indica el algoritmo hash utilizado durante la negociacin entre los nodos de la etapa 1. Por defecto, se utiliza un algoritmo de hash seguro (SHA, por las iniciales en ingls de Secure Hash Algorithm). authentication_method pre_shared_key Indica el mtodo de autenticacin utilizado durante la negociacin del nodo. Por defecto, Fedora utiliza una llave pre-compartida para la autenticacin. dh_group 2 Indica el nmero de grupo Diffie-Hellman para establecer claves de sesiones generadas dinmicamente. Por defecto, se utiliza modp1024 (segundo grupo).

4.2.1.6.2.1. El Archivo de configuracin Racoon


The /etc/racoon/racoon.conf files should be identical on all IPsec nodes except for the include "/etc/racoon/X.X.X.X.conf" statement. This statement (and the file it references) is generated when the IPsec tunnel is activated. For Workstation A, the X.X.X.X in the include statement is Workstation B's IP address. The opposite is true of Workstation B. The following shows a typical racoon.conf file when the IPsec connection is activated.
# Racoon IKE daemon configuration file. # See 'man racoon.conf' for a description of the format and entries. path include "/etc/racoon"; path pre_shared_key "/etc/racoon/psk.txt"; path certificate "/etc/racoon/certs"; sainfo anonymous { pfs_group 2; lifetime time 1 hour ; encryption_algorithm 3des, blowfish 448, rijndael ; authentication_algorithm hmac_sha1, hmac_md5 ; compression_algorithm deflate ; } include "/etc/racoon/X.X.X.X.conf";

Este archivo racoon.conf establecido por defecto incluye caminos definidos para la configuracin de IPsec, claves pre-compartidas y certificados. Los campos de sainfo anonymous describen la etapa SA 2 entre los nodos IPsec el tipo de conexin IPsec (incluyendo los algoritmos de encriptacin utilizados soportados), y el mtodo de intercambio de claves. La siguiente lista define los campos de la estapa 2: sainfo anonymous Indica que SA puede iniciarse annimamente con cualquier par ofrecido que se corresponda con las credenciales de IPsec. pfs_group 2 Define el protocolo de intercambio de llaves Diffie-Hellman, que determina el mtodo por el cual los nodos IPsec establecen una llave de sesin mutua y temporal para la segunda etapa de la conectividad IPsec. Por defecto, la implementacin en Fedora de IPsec utiliza el segundo (o modp1024) de los grupos Diffie-Hellman de intercambio de llaves criptogrficas. El segundo grupo utiliza una exponenciacin modular de 1024 bits que evita que los atacantes puedan descifrar transmisiones IPsec, an si una de las claves privadas ha sido vulnerada.

149

Captulo 4. Cifrado lifetime time 1 hour Este parmetro indica el perodo de vida de una SA y puede ser medido o bien en unidades de tiempo, o bien con datos. La implementacin en Fedora establecida por defecto de IPsec especifica un tiempo de vida de una hora. encryption_algorithm 3des, blowfish 448, rijndael Indica la cifra de cifrado soportada para la etapa 2. Fedora soporta 3DES, Blowfish de 448 bits, y Rijndael (la cifra utilizada en el Estndard avanzado de cifrado, o AES, por las iniciales en ingls de Advanced Encryption Standard). authentication_algorithm hmac_sha1, hmac_md5 Muestra los algoritmos hash soportados para la autenticacin. Los mdulos soportados son los cdigos de autenticacin de mensajes de hash sha1 y md5 (HMAC). compression_algorithm deflate Indica el algoritmo de compresin Deflate para el soporte de IP Payload Compression (IPCOMP), que potencialmente permite transmisiones ms rpidas de datagramas IP sobre conexiones ms lentas. Para iniciar una conexin, utilice el siguiente comando en cada uno de los equipos:
[root@myServer ~]# /sbin/ifup <nickname>

donde <nickname> es el nombre que usted indic para la conexin IPsec. Para verificar la conexin IPsec, ejecute la herramienta tcpdump para conocer los paquetes de red que estn siendo transferidos entre los equipos, y verifique que estn encriptados mediante IPsec. El paquete debera incluir un encabezado AH y debera mostrarse como un paquete ESP. ESP significa que est encriptado. Por ejemplo:
[root@myServer ~]# tcpdump -n -i eth0 host <targetSystem> IP 172.16.45.107 > 172.16.44.192: AH(spi=0x0954ccb6,seq=0xbb): ESP(spi=0x0c9f2164,seq=0xbb)

4.2.1.7. Configuracin IPsec red-a-red


IPsec tambin puede ser configurado para conectar totalmente a una red (como por ejemplo una LAN o WAN) con otra red remota utilizando una conexin de tipo red-a-red. Este tipo de conexin requiere la configuracin de enrutadores IPsec en cada lado de las redes que se quieren conectar para hacer el proceso transparente y enrutar informacin de un nodo en una LAN, hacia un nodo en una LAN remota. Figura 4.2, Una conexin por tnel IPsec de tipo red-a-red muestra un tnel de conexin IPsec de tipo red-a-red.

Figura 4.2. Una conexin por tnel IPsec de tipo red-a-red 150

Redes privadas virtuales (VPNs, por las iniciales en ingls de Virtual Private Networks) El siguiente diagrama muestra dos LANs diferentes separadas por Internet. Estas LANs utilizan enrutadores IPsec para autenticar e iniciar una conexin utilizando un tnel seguro a travs de Internet. Los paquetes en trnsito entre estas dos LANs que sean interceptados, necesitaran un mtodo de decriptado de tipo fuerza bruta para poder atravesar la proteccin que poseen. El proceso de comunicacin de un nodo en el rango IP 192.168.1.0/24, con otro del rango IP 192.168.1.0/24 es completamente transparente a los nodos, al igual que el proceso, encriptado, decriptado, y enrutado de los paquetes IPsec, es completamente manipulado por el enrutador IPsec. La informacin necesaria para una conexin de tipo red-a-red incluye: La direccin IP externamente accesible del enrutador dedicado IPsec Los rangos de direccin de red de LAN/WAN ofrecidos por los enrutadores IPsec (como por ejemplo, 192.168.1.0/24 or 10.0.1.0/24) Las direcciones IP de los dispositivos de las puertas de enlace que enrutan los datos desde los nodos de red hacia Interne Un nombre nico, por ejemplo, ipsec1. Esto es utilizado para identificar la conexin IPsec y poder identificarla de otros dispositivos o conexiones. Una clave de encriptado generada manualmente, o automticamente mediante la utilizacin de racoon Una clave de autenticacin pre-compartida que es utilizada a lo largo de la etapa inicial de la conexin, y que tambin ser utilizada luego para intercambiar claves de encriptado durante de la sesin.

4.2.1.7.1. Conexin red-a-red (VPN)


Una conexin IPsec de tipo red-a-red utiliza dos enrutadores IPsec, uno para cada red, a travs de los cuales es enrutado el trfico de red para las subredes privadas. Por ejemplo, como se muestra en la Figura 4.3, IPsec red-a-red, si la red privada 192.168.1.0/24 enva trfico hacia la red privada 192.168.2.0/24, los paquetes van a travs de la puerta-de-enlace-0, al ipsec0, a travs de internet, hacia ipsec1, a la puerta-de-enlace-1, y hacia la subred 192.168.2.0/24 Los enrutadores IPsec necesitan direcciones IP pblicas capaces de recibir paquetes, y un segundo dispositivo Ethernet conectado a sus respectivas redes privadas. El trfico slo viaja a travs de un enrutador IPsec si su destinatario es otro enrutador IPsec con el cual ha establecido una conexin encriptada.

Figura 4.3. IPsec red-a-red Opciones alternativas para la configuracin de red pueden establecer un cortafuegos entre Internet y cada enrutador IP, y un cortafuegos de intranet entre el enrutador IPsec y la puerta de enlace de 151

Captulo 4. Cifrado la subred. En enrutador IPsec y la puerta de enlace para la subred puede ser un sistema con dos dispositivos Ethernet: uno con una direccin IP pblica que acta como un enrutador IPsec; y otro con una direccin Ip privada que acta como la puerta de enlace para la subred privada. Cada enrutador IPsec puede utilizar la puerta de enlace para sus redes privadas, o una puerta de enlace pblica para enviar los paquetes al otro enrutador IPsec. Utilice el siguiente procedimiento para configurar una conexin IPsec de tipo red-a-red: 1. En una terminal, ingrese system-config-network para iniciar la Herramienta de administracin de red. 2. En la pestaa de IPsec, haga clic en Nuevo para iniciar el asistente de configuracin de IPsec. 3. Haga clic en Siguiente para empezar a configurar una conexin IPsec de tipp red-a-red. 4. Ingrese un nombre de usuario nico para la conexin, por ejemplo, ipsec0. Si lo necesita, tilde la casilla para que automticamente se active la conexin cuando se inicie el equipo. Haga clic en Siguiente para continuar. 5. Seleccione Encriptado de red a red (VPN) como el tipo de conexin, y luego haga clic en Siguiente. 6. Seleccione el tipo de mtodo de encriptado a utilizarse: manual o automtico. Si selecciona encriptado manual, deber indicar ms adelante una clave de encriptado. Si selecciona encriptado automtico, el demonio racoon se encarga de administrar la clave del encriptado. El paquete ipsec-tools debe estar instalado si quiere utilizar la encriptacin automtica. Haga clic en Siguiente para continuar. 7. En la pgina Red local, ingrese la siguiente informacin: Local Network Address La direcin IP del dispositivo en el enrutador IPsec conectado a la red privada. Local Subnet Mask La mscara de subred de la direccin IP de la red local. Local Network Gateway La puerta de enlace para la subred privada. Haga clic en Siguiente para continuar.

152

Redes privadas virtuales (VPNs, por las iniciales en ingls de Virtual Private Networks)

Figura 4.4. Informacin de red local 8. En la pgina de Red remota, ingrese la siguiente informacin: Remote IP Address La direccin IP pblica capaz de recibir trfico del enrutador IPsec para la otra red privada. En nuestro ejemplo, para ipsec0, ingrese la direccin IP pblica capaz de recibir trfico de upsec1, y viceversa. Remote Network Address La direccin de red de la subred privada detrs del otro enrutador IPsec. En nuestro ejemplo, ingrese 192.168.1.0 si est configurando ipsec1, e ingrese 192.168.2.0 si est configurando ipsec0. Remote Subnet Mask La mscara de subred de la direccin IP remota. Remote Network Gateway La direccin Ip de la puerta de enlace para la direccin de red remota. Si en la etapa 6 se ha seleccionado cifrado manual, especifique la clave de cifrado a ser utilizada, o haga clic en Generar para crear una. Especifique una clave de autenticacin o haga clic en Generar para crear una. Esta clave puede ser cualquier combinacin de nmeros y letras. Haga clic en Siguiente para continuar.

153

Captulo 4. Cifrado

Figura 4.5. Informacin de red remota 9. Verifique la informacin en la pgina IPsec Resumen, y luego haga clic en el botn Aplicar. 10. Seleccione Archivo => Guardar para guardar la configuracin. 11. Seleccione la conexin IPsec de la lista, y luego haga clic en Activar para activar la conexin. 12. Habilitando reenvo IP: a. Edite el archivo /etc/sysctl.conf y establezca net.ipv4.ip_forward a 1. b. Use el siguiente comando para habilitar los cambios:
[root@myServer ~]# /sbin/sysctl -p /etc/sysctl.conf

El programa de red para activar la conexin IPsec automticamente crea rutas de red para enviar paquetes a travs del enrutador IPsec, si es necesario.

4.2.1.7.2. Configuracin manual de una conexin IPsec de tipo red-a-red.


Suponga que LAN A (lana.ejemplo.com) y LAN B (lanb.ejemplo.com) quieren conectarse entre ellas mediante un tnel IPsec. La direccin de red para LAN A est en el rango 192.168.1.0/24. mientras qye LAN B utiliza el rango 192.168.2.0/24. La direccin IP de la puerta de enlace es 192.1686.1.254 para LAN A y 192.168.2.254 para LAN B. Los enrutadores IPsec estn separados de cada puerta de enlace LAN y utilizan dos dispositivos de red: eth0 est asignado a una direccin IP esttica accesible desde el exterior que tiene acceso a Internet, mientras eth1 acta como un punto de enrutamiento para procesar y transmitir los paquetes LAN de un nodo de red a otro.

154

Redes privadas virtuales (VPNs, por las iniciales en ingls de Virtual Private Networks) La conexin IPsec entre cada red utiliza una clave pre-compartida con el valor de r3dh4tl1nux, y los administradores de A y B estn de acuerdo en permitir que racoon genere automticamente y comparta una clave de autenticacin entre cada enrutador IPsec. El administrador de LAN A decide identificar a la conexin IPsec como ipsec0, mientras que el administrador de LAN B decide identificarla como ipsec1. El siguiente ejemplo muestra los contenidos del archivo ifcfg para una conexin IPsec de tipo reda-red para LAN A. El nico nombre para identificar la conexin en este ejemplo es ipsec0, de modo que el archivo resultante es /etc/sysconfig/network-scripts/ifcfg-ipsec0.
TYPE=IPSEC ONBOOT=yes IKE_METHOD=PSK SRCGW=192.168.1.254 DSTGW=192.168.2.254 SRCNET=192.168.1.0/24 DSTNET=192.168.2.0/24 DST=X.X.X.X

La siguiente lista describe los contenidos de este archivo: TYPE=IPSEC Especifica el tipo de conexin. ONBOOT=yes Indica que la conexin debera iniciarse en el arranque. IKE_METHOD=PSK Indica que la conexin utiliza el mtodo de clave pre-compartida para su autenticacin. SRCGW=192.168.1.254 La direccin IP de la puerta de enlace origen. Para LAN A, es la puerta de enlace de LAN A, y para LAN B, la puerta de enlace LAN B. DSTGW=192.168.2.254 La direccin IP de la puerta de enlace destino. Para LAN A, es la puerta de enlace de LAN B, y para LAN B, la puerta de enlace de LAN A. SRCNET=192.168.1.0/24 Indica la red de origen para la conexin IPsec, que en nuestro ejemplo es el rango de red para LAN A. DSTNET=192.168.2.0/24 Indica la red destino para la conexin IPsec, que en nuestro ejemplo, es el rango de red para LAN B. DST=X.X.X.X La direccin IP accesible desde el exterior de LAN B. El siguiente ejemplo es el contenido del archivo de clave pre-compartida denominado /etc/ sysconfig/network-scripts/keys-ipsecX (donde X es 0 para LAN A, y 1 para LAN B), que utilizan ambas redes para autenticarse entre ellas. Los contenidos de este archivo deberan ser idnticos y solo el usuario root debera ser capaz de leer o escribir sobre este archivo.
IKE_PSK=r3dh4tl1nux

155

Captulo 4. Cifrado

Importante
Para modificar el arhivo keys-ipsecX de modo que solo el usuario root pueda leerlo o editarlo, utilice el siguiente comando luego de haberlo creado:
chmod 600 /etc/sysconfig/network-scripts/keys-ipsec1

Para modificar la clave de autenticacin en cualquier momento, edite el archivo keys-ipsecX en ambos enrutadores IPsec. Ambas claves deben ser idnticas para una conexin correcta. En el siguiente ejemplo se muestran los contenidos del archivo de configuracin /etc/racoon/ racoon.conf para la conexin IPsec. Fjese que la lnea include al final del archivo es generada automticamente y solo aparece si el tunel IPsec est ejecutndose.
# Racoon IKE daemon configuration file. # See 'man racoon.conf' for a description of the format and entries. path include "/etc/racoon"; path pre_shared_key "/etc/racoon/psk.txt"; path certificate "/etc/racoon/certs"; sainfo anonymous { pfs_group 2; lifetime time 1 hour ; encryption_algorithm 3des, blowfish 448, rijndael ; authentication_algorithm hmac_sha1, hmac_md5 ; compression_algorithm deflate ; } include "/etc/racoon/X.X.X.X.conf"

La siguiente es la configuracin especfica para la conexin con la red remota. El archivo es denominado X.X.X.X.conf (donde X.X.X.X es la direccin IP del enrutador IPsec remoto). Fjese que este archivo es automticamente generado cuando el tnel IPsec es activado y no debera ser editado directamente.
remote X.X.X.X{ exchange_mode aggressive, main; my_identifier address; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 2 ; } }

Antes de empezar la conexin IPsec, debera ser habilitado el reenvo de IP en el kernel. Para hacerlo: 1. Edite el archivo /etc/sysctl.conf y establezca net.ipv4.ip_forward a 1. 2. Use el siguiente comando para habilitar los cambios:
[root@myServer ~] # sysctl -p /etc/sysctl.conf

156

Shell seguro (SSH, por las iniciales en ingls de Secure Shell) Para iniciar la conexin IPsec, utilice el siguiente comando en cada enrutador:
[root@myServer ~] # /sbin/ifup ipsec0

Las conexiones estn activas, y tanto LAN A como LAN B son capaces de comunicarse entre ellas. Las rutas fueron creadas automticamente mediante la inicializacin de un programa que fue activado al ejecutarse ifup en la conexin IPsec. Para mostrar una lista de rutas para la red, utilice el siguiente comando:
[root@myServer ~] # /sbin/ip route list

Para verificar la conexin IPsec, ejecute la herramienta tcpdump en el dispositivo enrutable externamente (en nuestro ejemplo, eth0) para ver los paquetes de red que estn siendo transferidos entre los equipos (o redes) y verifique que estn encriptados mediante IPsec. Por ejemplo, para verificar la conectividad IPsec de LAN A, utilice el siguiente comando:
[root@myServer ~] # tcpdump -n -i eth0 host lana.example.com

El paquete debera incluir un encabezado AH y debera mostrarse como paquetes ESP. ESP significa que est encriptado. Por ejemplo (las lneas invertidas indican que la lnea contina):
12:24:26.155529 lanb.example.com > lana.example.com: AH(spi=0x021c9834,seq=0x358): \ lanb.example.com > lana.example.com: ESP(spi=0x00c887ad,seq=0x358) (DF) \ (ipip-proto-4)

4.2.1.8. Iniciar y detener una conexin IPsec


Si la conexin IPsec no fue configurada para activarse durante el arranque del equipo, puede controlarla desde la lnea de comandos. Para iniciar la conexin, utilice el siguiente comando en cada uno de los equipos para una IPsec de tipo equipo-a-equipo, o en cada uno de los enrutadores IPsec para una IPsec de tipo red-a-red:
[root@myServer ~] # /sbin/ifup <nickname>

where <nickname> is the nickname configured earlier, such as ipsec0. Para detener la conexin, use el siguiente comando:
[root@myServer ~] # /sbin/ifdown <nickname>

4.2.2. Shell seguro (SSH, por las iniciales en ingls de Secure Shell)
Shell seguro (SSH) es un protocolo de red muy poderoso que se utiliza para comunicarse con otros sistemas operativos a travs de un canal seguro. Las transmisiones realizadas con SSH estn cifradas y protegidas de cualquier tipo de intercepcin. Pueden utilizarse tambin registros de tipo criptogrfico para proveer un mejor mtodo de autenticacin adems del tradicional nombre de usuario y contrasea. SSH es muy fcil de activar. Simplemente iniciando el servicio SSH, el sistema comenzar a aceptar conexiones y les permitir acceder al sistema slo a aquellas que, durante el proceso de conexin, indiquen correctamente tanto un nombre de usuario como una contrasea. El TCP estndar para las conexiones SSH es 22, sin embargo esto puede cambiarse modificando el archivo de configuracin /etc/ssh/sshd_config, y reiniciando el servicio. Este archivo tambin contiene otras opciones de configuracin para SSH. 157

Captulo 4. Cifrado SSH tambin ofrece la posibilidad de tneles cifrados entre computadoras, pero utilizando solamente 1 un puerto. El reenvo de puertos puede ser realizado sobre un tnel SSH , pero la utilizacin del reenvo de puertos no es tan fluido como una VPN.

4.2.2.1. Cryptographic Logon


SSH supports the use of cryptographic keys to login to a computer. This is much more secure than using a password and if setup properly could be considered multifactor authentication. A configuration change must occur before cryptographic logon can occur. In the file /etc/ssh/ sshd_config uncomment and modify the following lines so that appear as such:
PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys

The first line tells the SSH program to allow public key authentication. The second line points to a file in the home directory where the public key of authorized key pairs exists on the system. The next thing to do is to generate the ssh key pairs on the client you will use to connect to the system. The command ssh-keygen will generate an RSA 2048-bit key set for logging into the system. The keys are stored, by default, in the ~/.ssh directory. You can utilize the switch -b to modify the bit-strength of the key. 2048-bits is probably okay but you can go up to, and possibly beyond, 8192-bit keys. In your ~/.ssh directory you should see the two keys you just created. If you accepted the defaults when running the ssh-keygen then your keys are named id_rsa and id_rsa.pub, the private and public keys. You should always protect the private key from exposure. The public key, however, needs to be transfered over to the system you are going to login to. Once you have it on your system the easiest way to add the key to the approved list is by:
$ cat id_rsa.pub >> ~/.ssh/authorized_keys

This will append the public key to the authorized_key file. The SSH application will check this file when you attempt to login to the computer. Similarly to passwords and any other authentication mechanism, you should change your SSH keys regularly. When you do make sure you clean out any unused key from the authorized_key file.

4.2.3. Cifrado de disco LUKS (Linux Unified Key Setup-on-diskformat)


La Configuracin de Clave Unificada de Linux en el formato de disco (o LUKS por sus iniciales en ingls) le permite cifrar particiones en su computadora Linux. Esto es particularmente importante cuando se trata de computadores mviles y de medios removibles. LUKS le permite claves mltiples de usuario para descifrar una clave maestra que se usa para el cifrado de la particin.

4.2.3.1. Implementacin de LUKS en Fedora


Fedora 9 y posterior utiliza LUKS para realizar cifrado del sistema de archivos. En forma predeterminada, la opcin de cifrar el sistema de archivos est desmarcada durante la instalacin. Si usted selecciona la opcin de cifrar su disco duro, se le pedir una contrasea que ser solicitada

http://www.redhatmagazine.com/2007/11/27/advanced-ssh-configuration-and-tunneling-we-dont-need-no-stinking-vpnsoftware

158

Cifrado de disco LUKS (Linux Unified Key Setup-on-disk-format) cada vez que inicie su computador. Esta contrasea "desbloquea" la llave de cifrado que es usada para descifrar su particin. Si usted elije modificar la tabla de particiones predeterminada, podr elegir las particiones que desee cifrar.\nEsto es definido en la configuracin de la tabla de particiones. La implementacin predeterminada de LUKS en Fedora es AES 128 con hash SHA256. Los cifrados disponibles son: AES - Advanced Encryption Standard - FIPS PUB 197 Twofish (A 128-bit Block Cipher) Serpent cast5 - RFC 2144 cast6 - RFC 2612
3 4 2

4.2.3.2. Cifrado manual de directorios Advertencia


Al seguir este procedimiento se eliminarn todos los datos de la particin que est cifrando. Perder toda la informacin! Asegrese de hacer un respaldo de sus datos en una fuente externa antes de comenzar!

Nota
Este procedimiento usa scrub para destruir los datos existentes en la particin y entregar una base aleatoria para que LUKS use. Esta base aleatoria es importante para prevenir ataques contra la criptografa.\nScrub no est instalado en forma predeterminada y antes de usarlo deber instalarlo. Alternativamente, podr usar otro generador de nmeros aleatorios para hacer lo mismo. Si est corriendo una versin de Fedora anterior a la 9 y quiere cifrar una particin, o si quiere cifrar una particin despus de la instalacin de la versin actual de Fedora, las siguientes instrucciones son para Ud. El ejemplo que ofrecemos ms abajo muestra elcifrado de una particin /home pero puede utilizarse sobre cualquier particin. El siguiente procedimiento borrar todos los datos existentes, de modo que es conveniente asegurarse de haber hecho un respaldo antes de comenzar. Tambin es necesario tener una particin separada para /home (en nuestro caso es /dev/VG00/LV_home). Todo lo que se muestra a continuacin debe ser realizado como usuario root. Cualquiera de las etapas en este mtodo no puede realizarse a no ser que la anterior haya sido exitosa.

2 3

http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf http://www.ietf.org/rfc/rfc2144.txt 4 http://www.ietf.org/rfc/rfc2612.txt

159

Captulo 4. Cifrado

4.2.3.3. Instrucciones paso a paso


1. Ingrese a nivel de ejecucin 1: telinit 1 2. Llene su particin con datos aleatorios: scrub -p random /home 3. Desmonte su /home actual: umount /home 4. Si falla, use fuser para identificar y eliminar los procesos que retienen a /home: fuser -mvk / home 5. Verifique que /home ya no est montado: cat /proc/mounts | grep home 6. Inicie su particin: cryptsetup --verbose --verify-passphrase luksFormat /dev/ VG00/LV_home 7. Abra el dispositivo nuevo cifrado: cryptsetup luksOpen /dev/VG00/LV_home home 8. Compruebe que est all: ls -l /dev/mapper | grep home 9. Genere un sistema de archivos: mkfs.ext3 /dev/mapper/home 10. Mntelo: mount /dev/mapper/home /home 11. Compruebe que es visible: df -h | grep home 12. Agregue lo siguiente a /etc/crypttab: home /dev/VG00/LV_home none 13. Edite su /etc/fstab, elimine la antigua entrada de /home, y agregue /dev/mapper/home /home ext3 defaults 1 2 14. Verifique su entrada fstab: mount /home 15. Restaure los contextos de seguridad de SELinux: /sbin/restorecon -v -R /home 16. Reinicie: shutdown -r now 17. La entrada en /etc/crypttab hace que su computadora le pida su frase de acceso luks al arrancar 18. Ingrese como root y restaure su respaldo

4.2.3.4. Lo que acaba de realizar


Felicitaciones, ahora tiene una particin cifrada para que todos sus datos reposen en forma segura cuando su equipo se encuentre apagado.

4.2.3.5. Enlaces de inters


Para informacin adicional sobre LUKS, o sobre el cifrado de discos duros bajo Fedora, por favor visite alguno de los siguientes enlaces: LUKS - Linux Unified Key Setup
5

COMO: Generando un volumen fsico (PV) cifrado, utilizando otro disco duro, pvmove, y un CD o 6 DVD vivo de Fedora

5 6

https://code.google.com/p/cryptsetup/ https://bugzilla.redhat.com/attachment.cgi?id=161912

160

Archivos cifrados mediante 7-Zip

4.2.4. Archivos cifrados mediante 7-Zip


7-Zip es una nueva herramienta de compresin multiplataforma que tambin puede realizar poderosos cifrados (AES-256) para proteger los contenidos de un archivo. Esto es muy til cuando necesite trasladar datos entre diferentes computadoras que utilicen distintos sistemas operativos, y quiera utilizar para ello una herramienta de cifrado porttil (por ejemplo, Linux en el hogar, Windows en el trabajo).
7

4.2.4.1. Instalacin de 7-Zip en Fedora


7-Zip no es un paquete que venga instalado por defecto con Fedora, pero se encuentra disponible para descargarlo desde el repositorio. Una vez instalado, el paquete se ir actualizando cada vez que sea necesario, del mismo modo que el resto del software en su sistema, sin necesitar para ello ningn tipo de atencin especial.

4.2.4.2. Instrucciones paso a paso para su instalacin


Open a Terminal: Click Applications -> System Tools -> Terminal or in GNOME 3: Activities -> Applications -> Terminal Instale 7-Zip con permisos de usuario sudo: sudo yum install p7zip Cierre la terminal: exit

4.2.4.3. Instrucciones paso a paso para su utilizacin


By following these instructions you are going to compress and encrypt your "Documents" directory. Your original "Documents" directory will remain unaltered. This technique can be applied to any directory or file you have access to on the filesystem. Open a Terminal:Click Applications -> System Tools -> Terminal Comprima y cifre: (ingrese una contrasea cuando le sea pedido) 7za a -mhe=on -ms=on -p Documentos.7z Documentos/ The "Documents" directory is now compressed and encrypted. The following instructions will move the encrypted archive somewhere new and then extract it. Cree un directorio nuevo: mkdir lugarnuevo Traslade el archivo cifrado: mv Documentos.7z lugarnuevo Posicinese en el nuevo directorio: cd lugarnuevo Descomprima el archivo: (ingrese la contrasea cuando se le pida) 7za x Documentos.7z El archivo ya ha sido descomprimido en el nuevo directorio. Las instrucciones siguientes van a deshacer los pasos realizados y devolvern a su computadora el estado anterior en el que se encontraba. Dirjase al directorio superior inmediato: cd .. Borre el archivo de prueba creado y sus contenidos extrados: rm -r lugarnuevo Cierre la terminal: exit

http://www.7-zip.org/

161

Captulo 4. Cifrado

4.2.4.4. Creating a Secure 7-Zip Archive via the GUI


7-Zip archives can be extracted just like any other archive via the GUI, but creating a secure 7-Zip archive requires a few additional steps. By following these instructions you are going to compress and encrypt your "Documents" directory. Your original "Documents" directory will remain unaltered. This technique can be applied to any directory or file you have access to on the filesystem. Open the file browser: Click Activities -> Files Right-Click on the "Documents" folder Select the "Compress" option Select ".7z" as the file extension Expand "Other Options" Check "Encrypt the file list too" Enter a password into the password field Click the "Create" button You will now see a "Documents.7z" file appear in your home directory. If you try to open the file, you will be asked for the archive password before being shown the contents of the archive. The file will open once the correct password is supplied, and the archive can then be manipulated as usual. Deleting the "Documents.7z" file will conclude this exercise and return your computer to its previous state.

4.2.4.5. Elementos para prestar atencin


7-Zip no se encuentra instalado por defecto en los sistemas operativos Microsoft Windows o Mac OS X. Si necesita utilizar sus archivos 7-Zip en alguna de estas plataformas, necesitar instalar la versin 8 apropiada de 7-Zip en los equipos correspondientes. Vea la pgina de descargas .

4.2.5. Utilizando GNU Privacy Guard (GnuPG)


GnuPG (GPG) is used to identify yourself and authenticate your communications, including those with people you don't know. GPG allows anyone reading a GPG-signed email to verify its authenticity. In other words, GPG allows someone to be reasonably certain that communications signed by you actually are from you. GPG is useful because it helps prevent third parties from altering code or intercepting conversations and altering the message. GPG tambin puede ser utilizado para firmar y/o cifrar archivos almacenados en su computadora, o en un disco de red. Esto puede agregar proteccin adicional al prevenir que un archivo sea alterado o ledo por personas que no hayan sido autorizadas para hacerlo. To utilize GPG for authentication or encryption of email you must first generate your public and private keys. After generating the keys you will have to setup your email client to utilize them.

http://www.7-zip.org/download.html

162

Utilizando GNU Privacy Guard (GnuPG)

4.2.5.1. Generando claves GPG en GNOME


The Seahorse utility makes GPG key management easier. You can install Seahorse at the command line with the command su -c "yum install seahorse" or in the GUI using Add/Remove Software. To create a key select Passwords and Keys, which starts the application Seahorse. From the File menu select New then PGP Key then select Continue. Type your full name, email address, and an optional comment describing who are you (e.g.: John C. Smith, jsmith@example.com, The Man). Select Create. A dialog is displayed asking for a passphrase for the key. Choose a strong passphrase but also easy to remember. Click OK and the key is created.

Advertencia
Si se olvida su frase de acceso, la clave no podr ser utilizada y cualquier dato encriptado por ella ser perdido. To find your GPG key ID, look in the Key ID column next to the newly created key. In most cases, if you are asked for the key ID, you should prepend "0x" to the key ID, as in "0x6789ABCD". You should make a backup of your private key and store it somewhere secure.

4.2.5.2. Generar claves GPG en KDE


Start the KGpg program from the main menu by selecting Applications > Utilities > Encryption Tool. If you have never used KGpg before, the program walks you through the process of creating your own GPG keypair. A dialog box appears prompting you to create a new key pair. Enter your name, email address, and an optional comment. You can also choose an expiration time for your key, as well as the key strength (number of bits) and algorithms. The next dialog box prompts you for your passphrase. At this point, your key appears in the main KGpg window.

Advertencia
Si se olvida su frase de acceso, la clave no podr ser utilizada y cualquier dato encriptado por ella ser perdido. To find your GPG key ID, look in the Key ID column next to the newly created key. In most cases, if you are asked for the key ID, you should prepend "0x" to the key ID, as in "0x6789ABCD". You should make a backup of your private key and store it somewhere secure.

4.2.5.3. Generar una clave GPG mediante la lnea de comandos


Use el siguiente comando: gpg --gen-key El siguiente comando genera un par de claves consistentes en una clave pblica y otra privada. El resto de las personas utilizan su clave pblica para autenticar y/o decriptar sus comunicaciones. Distribuya su clave pblica lo mayor que pueda, especialmente a todos aquellos que quieran recibir comunicaciones autnticas por parte suya, como ser por ejemplo una lista de correo. El proyecto de documentacin de Fedora, por ejemplo, le pide a sus participantes que incluyan su llave pblica GPG en su correo introductorio.

163

Captulo 4. Cifrado Una serie de mensajes lo dirigen a lo largo del proceso. Presione la tecla Enter para indicar el valor establecido por defecto si as lo desea. El primer mensaje le pide que elija el tipo de clave que prefiere:
Por favor, seleccione qu tipo de llave desea: (1) RSA y RSA (predeterminado) (2) DSA y Elgamal (3) DSA (slo firmar) (4) RSA (slo firmar) Su seleccin?

En la mayora de los casos, el predeterminado es la eleccin correcta. Una llave RSA le permite no slo firmar comunicaciones, sino que tambin cifrar archivos. Luego, elija el tamao de llave:
El largo de las llaves RSA pueden estar entre 1024 y 4096 bits. Qu tamao de llave desea? (2048)

Nuevamente, el predeterminado es suficiente para la mayora de los usuarios y representa un fuerte nivel de seguridad. Next, choose when the key will expire. It is a good idea to choose an expiration date instead of using the default, which is none. If, for example, the email address on the key becomes invalid, an expiration date will remind others to stop using that public key.
Por favor 0 = d = w = m = y = La indique por cunto su llave debe ser vlida. la llave no expira. la llave expira en n das la llave expira en n semanas la llave expira en n meses la llave expira en n aos llave es vlida por? (0)

Ingresar un valor de 1y, por ejemplo, hace que la clave sea vlida durante un ao. (Puede modificar esta fecha de expiracin luego que la clave haya sido generada, si cambi de parecer.) Before the gpgcode> program asks for signature information, the following prompt appears: Is this correct (y/n)? Enter ycode> to finish the process. A continuacin, ingrese su nombre y direccin de correo electrnico. Recuerde que este proceso se trata de autenticarlo a usted como un individuo real. Por esta razn, incluya su verdadero nombre. No utilice apodos o alias, ya que esto oscurece o disimula su identidad. Ingrese su direccin de correo electrnico real para su clave GPG. Si elige una falsa o inexistente, ser ms difcil para los dems encontrar su clave pblica. Esto hace que autenticar sus comunicaciones sea ms difcil. Si est utilizando esta clave GPG para presentarse en una lista de correo, por ejemplo, ingrese la direccin de correo electrnico que usted utiliza con esa lista. Use the comment field to include aliases or other information. (Some people use different keys for different purposes and identify each key with a comment, such as "Office" or "Open Source Projects.") En el mensaje de confirmacin, ingrese la letra O para continuar si todas las opciones son correctas, o utilice las opciones propuestas para solucionar cualquier problema. Ingrese una frase de acceso para su clave secreta. El programa GPG le pide que ingrese dos veces su frase de acceso para asegurarse que no haya cometido errores de tipeo. 164

Utilizando GNU Privacy Guard (GnuPG) Por ltimo, gpg genera datos aleatorios para hacer que su clave sea lo ms autntica posible. Mueva su ratn, presione teclas de manera azarosa, o realice alguna otra tarea en el sistema durante este paso para acelerar el proceso. Una vez ha finalizado, sus claves estn completas y listas para ser utilizadas:

pub 1024D/1B2AFA1C 2005-03-31 John Q. Doe (Fedora Docs Project) <jqdoe@example.com> Key fingerprint = 117C FE83 22EA B843 3E86 6486 4320 545E 1B2A FA1C sub 1024g/CEA4B22E 2005-03-31 [expires: 2006-03-31]

The key fingerprint is a shorthand "signature" for your key. It allows you to confirm to others that they have received your actual public key without any tampering. You do not need to write this fingerprint down. To display the fingerprint at any time, use this command, substituting your email address: gpg --fingerprint jqdoe@example.com Your "GPG key ID" consists of 8 hex digits identifying the public key. In the example above, the GPG key ID is 1B2AFA1C. In most cases, if you are asked for the key ID, you should prepend "0x" to the key ID, as in "0x1B2AFA1C".

Advertencia
Si se olvida su frase de acceso, la clave no podr ser utilizada y cualquier dato encriptado por ella ser perdido.

4.2.5.4. Usando GPG con Alpine


Si est utilizando el cliente de correo electrnico Alpine o Pine, entonces tambin necesitar descargar e instalar el paquete ez-pine-gpg. Este software actualmente se encuentra disponible en http://business-php.com/opensource/ez-pine-gpg/. Una vez que haya instalado ez-pine-gpg, tendr que modificar su archivo ~/.pinerc. Necesita: 1. /home/username/bin debe ser reemplazado con la ruta de instalacin que usted especific 2. In two places, the gpg-identifier after _RECIPIENTS_ should be replaced with your GPG public key's identifier. The reason you include your own GPG identifier here is so that if you send an encrypted message to "Alice", that message is also encrypted with your public key -- if you don't do this, then you will not be able to open that message in your sent-mail folder and remind yourself of what you wrote. Debe verse algo similar a esto:

# This variable takes a list of programs that message text is piped into # after MIME decoding, prior to display. display-filters=_LEADING("-----BEGIN PGP")_ /home/max/bin/ez-pine-gpg-incoming # This defines a program that message text is piped into before MIME # encoding, prior to sending sending-filters=/home/max/bin/ez-pine-gpg-sign _INCLUDEALLHDRS_, /home/username/bin/ez-pine-gpg-encrypt _RECIPIENTS_ gpg-identifier, /home/username/bin/ez-pine-gpg-sign-and-encrypt _INCLUDEALLHDRS_ _RECIPIENTS_ gpgidentifier

165

Captulo 4. Cifrado

4.2.5.5. Usando GPG con Evolution


4.2.5.5.1. Configurando GPG para usar con Evolution
Para configurar GPG para ser utilizado en Evolution, elija Herramientas, Configuraciones... en el men principal de Evolution. En el panel izquierdo, seleccione Cuentas de correo. En el panel derecho, seleccione la cuenta de correo que utiliza para la correspondencia con el Proyecto Fedora. Luego haga clic sobre el botn Editar. Aparece el dilogo de edicin de cuentas de Evolution. Seleccione la pestaa de Seguridad. In the PGP/GPG Key ID field, enter the GPG key ID matching this account's email address. If you are not sure what your key ID is, use this command: gpg --fingerprint EMAIL_ADDRESS. The key ID is the same as the last eight characters (4 bytes) of the key fingerprint. It is a good idea to click the option Always encrypt to myself when sending encrypted mail. You may also want to select Always sign outgoing messages when using this account.

Nota
Si no identifica las llaves pblicas como confiables en su administrador de llaves, no podr cifrar correos electrnicos a sus dueos, a menos que elija la opcin Siempre confiar en las llaves de mi administrador de llaves cuando se realicen los cifrados. En su lugar recibir un dilogo indicando que ha fallado una verificacin de confianza

4.2.5.5.2. Verificando correos electrnicos con Evolution


Evolution will automatically check any incoming GPG-signed messages for validity. If Evolution cannot GPG verify a message due to a missing public key (or tampering), it will end with a red banner. If the message is verified but you have not signed the key either locally or globally, the banner will be yellow. If the message is verified and you have signed the key, the banner will be green. When you click the seal icon, Evolution displays a dialog with more security information about the signature. To add a public key to your keyring, use the search function along with the key owner's email address: gpg -keyserver pgp.mit.edu --search email address. To import the correct key, you may need to match the key ID with the information provided by Evolution.

4.2.5.5.3. Firmando y cifrando correos electrnicos con Evolution


El hecho de firmar los correos electrnicos permite que sus destinatarios verifiquen que ese correo realmente proviene de usted. El Proyecto de Documentacin de Fedora (y todo el resto del proyecto Fedora) fomentan la utilizacin de correos firmados entre sus participantes, incluyendo los correos enviados a las diferentes listas. Cifrar un correo electrnico hace que solamente sus destinatarios puedan leerlo. Por favor, no enve correos cifrados a las listas de correo de Fedora, ya que casi nadie va a poder leerlos. Mientras est redactando su correo, elija el men Seguridad, y luego seleccione Firma PGP para firmar su mensaje. Para cifrar su mensaje, seleccione Cifrado PGP. Tambin puede firmar un mensaje cifrado, lo que es una sana costumbre. Cuando enva un mensaje, Evolution le pedir que ingrese su frase de acceso de llave GPG (luego de tres intentos fallidos, Evolution genera un error). Si selecciona la opcin Recordar la contrasea por el resto de esta sesin, no necesitar utilizar su frase de acceso nuevamente para firmar o descifrar, a menos que finalice y reinicie Evolution.

166

Utilizando GNU Privacy Guard (GnuPG)

4.2.5.6. Usando GPG con Thunderbird


Fedora Core includes Mozilla Thunderbird in the thunderbird package, and the mozilla-mail package for the Mozilla Suite email application. Thunderbird is the recommended Mozilla email application. This appears on your desktop as Applications > Internet > Thunderbird Email. Los productos Mozilla tienen soporte para extensiones, que son diferentes complementos que le agregan nuevas caractersticas a la aplicacin principal. Las extensiones Enigmail ofrecen soporte GPG para productos de correo electrnico de Mozilla. Existen versiones de Enigmail tanto para Mozilla Thunderbird como para Seamonkey de Mozilla Suite. El software Netscape de AOL est basado en productos Mozilla, y podran tambin utilizar esta extensin. Para poder instalar Enigmail en sistemas Fedora, siga las instrucciones dadas a continuacin. Enigmail utiliza el trmino OpenPGP en elementos del men y en las opciones. GPG es una implementacin de OpenPGP, y estos trminos pueden entenderse como siendo equivalentes. La pagina principal de Enigmail es: http://enigmail.mozdev.org/download.html. En esta pgina se pueden apreciar capturas de pantalla de Enigmail y GPG en accin: http:// enigmail.mozdev.org/screenshots.html.

4.2.5.6.1. Instalando Enigmail


Enigmail is now available in fedora repository. It can be installed by typing: yum install thunderbird-enigmail at a command line. Alternatively, you can install thunderbird-enigmail using by going to System -> Administration -> Add/Remove Software.

4.2.5.7. Acerca del encriptado de la clave pblica


1. Wikipedia - Criptografa de la llave pblica (en ingls) 2. HowStuffWorks - Encryption
10 9

10

http://en.wikipedia.org/wiki/Public-key_cryptography http://computer.howstuffworks.com/encryption.htm

167

168

Principios Generales sobre la Seguridad de la Informacin


Los siguientes principios generales ofrecen una visin panormica de algunas buenas actitudes para adoptar relacionadas con la seguridad: encriptar todos los datos transmitidos por la red para ayudar a prevenir ataques de tipo hombreen-el-medio, o escuchas. Es importante encriptar de la informacin de autenticacin, como ser contraseas. minimice la cantidad de software instalado y de servicios en ejecucin. utilice herramientas y software destinadas a mejorar la seguridad de su equipo. Por ejemplo, Security-Enhanced Linux (SELinux) para Control de Acceso Obligatorio (MAC, por las siglas en ingls de Mandatory Acces Control), Netfilter iptables para filtrar paquetes (cortafuegos), y la Proteccin de Privacidad GNU (GnuPG, por las siglas en ingls de GNU Privacy Guard) para los archivos encriptados. si es posible, corra cada servicio de red en un servidor separado para minimizar el riesgo de que una debilidad en uno de los servicios, se utilice para comprometer a los dems. mantenga las cuentas de usuario: genere y aplique una poltica firme de contraseas; borre las cuentas de usuarios que no son utilizadas. peridicamente consulte los archivos de registros del sistema y de las diferentes aplicaciones que utilice. Por defecto, los archivos de registros del sistema que sean pertinentes para la seguridad del equipo, son almacenados en /var/log/secure y /var/log/audit/audit.log. Nota: enviar archivos de registros hacia un servidor dedicado ayuda a prevenir que los atacantes puedan modificar fcilmente los archivos de registros locales, y de este modo evitar ser detectados. nunca ingrese como root directamente, a menos de que sea absolutamente necesario. Los administradores deben usar sudo para ejecutar comandos como root cuando sea necesario. Las cuentas capaces de usar sudo se especifican en /etc/sudoers, que se edita con el utilitario visudo.

5.1. Consejos, Guas y Herramientas


La Agencia de Seguridad Nacional (NSA) de los Estado Unidos proporciona guas y consejos para muchos sistemas operativos, para ayudar a agencias del gobierno, empresas y personas a asegurar y endurecer sus sistemas contra ataques. Las siguientes guas (en formato PDF) proveen consejos para Red Hat Enterprise Linux 5: Consejos para asegurar un sistema Linux 5 para empresas de Red Hat (en inglls)
2 3 1

Gua para la configuracin segura de un sistema Linux 5 para empresas de Red Hat (en ingls) La Agencia de Defensa de Informacin de Sistemas (DISA, por las iniciales en ingls de Defense 4 Information Systems Agency) ofrece documentacin, evaluaciones, y listas con tems a ser verificados, que le ayudarn a asegurar su sistema (Soporte para un Entorno Seguro de la

1 2

http://www.nsa.gov/ http://www.nsa.gov/ia/_files/os/redhat/rhel5-pamphlet-i731.pdf 3 http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf 4 http://www.disa.mil/

169

Captulo 5. Principios Generales sobre la Seguridad de la Informacin Informacin ). La Gua de implementacin t{ecnicade seguridad UNIX (PDF) es una gua muy especfica para la seguridad en sistemas UNIX - antes de leerla, se recomienda poseer un conocimiento avanzado tanto de UNIX como de Linux. La Lista de Items a verificarse para la Seguridad de UNIX Version 5, Release 1.26 de DISA ofrece diferentes documentos y listas de verificacin, abarcando aspectos que van desde el correcto establecimiento de la pertenencia de los archivos del sistema, hasta el control de parches. Al mismo tiempo, DISA ha puesto a disposicin diferentesprogramas de UNIX SPR que permiten a los administradores verificar configuraciones especficas en sus sistemas. Estos programas ofrecen reportes en formato XML, en los que muestran todas las configuraciones vulnerables conocidas.
8 7 5 6

5 6

http://iase.disa.mil/index2.html http://iase.disa.mil/stigs/stig/unix-stig-v5r1.pdf 7 http://iase.disa.mil/stigs/downloads/zip/unclassified_unix_checklist_v5r1-26_20100827.zip 8 http://iase.disa.mil/stigs/SRR/unix.html

170

Instalacin segura
La seguridad comienza con la primera vez que introduce un CD o DVD para instalar Fedora. Configurar su sistema en forma segura desde un principio, hace que sea ms fcil implementar configuraciones de seguridad adicional ms adelante.

6.1. Particiones del disco


La NSA recomienda crear particiones separadas para /boot, /, /home, /tmp y /var/tmp. Las razones son diferentes y se tratar por separado para cada particin. /boot - Esta particin es la primera particin que se lee durante el arranque. El cargador de arranque y las imgenes del kernel que se usan para arrancar su sistema Fedora se almacenan en esta particin. Esta particin no debe ser encriptada. Si esta particin se incluye en / y la misma es encriptada o de alguna forma se vuelve no disponible, entonces su sistema no podr arrancar. /home - Cuando los datos del usuario (/home) se almacenan en / en vez de una particin separada, la particin se puede llenar haciendo que el sistema operativo se vuelva inestable. Tambin, cuando se actualice su sistema a la siguiente versin de Fedora, poder mantener sus datos en una particin / home hace que el proceso sea mucho ms sencillo, dado que no ser sobrescrita durante la instalacin. Si la particin raz (/) se corrompe, sus datos se perdern para siempre. Usando una particin separada hay un poco ms de proteccin contra la prdida de datos. Tambin se puede elegir esa particin para los respaldos frecuentes. /tmp and /var/tmp - Both the /tmp and the /var/tmp directories are used to store data that doesn't need to be stored for a long period of time. However if a lot of data floods one of these directories it can consume all of your storage space. If this happens and these directories are stored within / then your system could become unstable and crash. For this reason, moving these directories into their own partitions is a good idea.

6.2. Utilice encriptado de particiones mediante LUKS


Since Fedora 9, implementation of Linux Unified Key Setup-on-disk-format (LUKS) encryption has become a lot easier. During the installation process an option to encrypt your partitions will be presented to the user. The user must supply a passphrase that will be the key to unlock the bulk encryption key that will be used to secure the partition's data.
1

http://fedoraproject.org/wiki/Security_Guide/9/LUKSDiskEncryption

171

172

Mantenimiento de Software
Una manutencin adecuada del software es extremadamente importante a la hora de asegurar un sistema. Es fundamental enmendar software que presenta un fallo en el momento inmediato a la aparicin de la solucin, de modo de evitar que atacantes que conocen ese fallo, lo aprovechen y se infiltren en su sistema.

7.1. Instale el software mnimo


La mejor forma de proceder es instalando solo los paquetes que se van a utilizar, ya que cada pieza de software en su computadora posiblemente pueda contener algn tipo de debilidad. Si est realizando una instalacin desde un DVD, dese la oportunidad de elegir exactamente qu paquetes quiere instalar en este proceso. Si se da cuenta que necesita otro paquete, siempre puede agregrselo luego al sistema.

7.2. Planifique y configure actualizaciones de seguridad


Todo software contiene errores. A menudo, estos errores pueden transformarse en una debilidad que podra dejar a su sistema expuesto a usuarios maliciosos. Sistemas no enmendados son una causa frecuente de intrusiones en las computadoras. Debera tener planificada la instalacin de parches de seguridad en una forma sincronizada de manera tal de poder anular esas debilidades, y evitar as que sean aprovechadas. Para usuarios hogareos, las actualizaciones de seguridad deberan ser instaladas lo antes posible. Configurar instalaciones automticas de ellas es una manera de evitar el tener que recordar constantemente hacerlo, pero podra traer aparejado el pequeo riesgo de que un determinado paquete entre en conflicto con la configuracin de su sistema, o con otro software de su equipo. Para los comercios o para los usuarios hogareos avanzados, las actualizaciones de seguridad deberan ser probadas y planeadas para ser instaladas. Ser necesario utilizar controles adicionales para proteger el sistema durante el lapso de tiempo existente entre el lanzamiento del parche y su instalacin definitiva. Estos controles dependen de la debilidad en cuestin, pero pueden incluir reglas de cortafuegos adicionales, o el uso de cortafuegos externos, o cambios en las configuraciones del sistema.

7.3. Ajustando las actualizaciones automticas


Fedora is configured to apply all updates on a daily schedule. If you want to change the how your system installs updates you must do so via Software Update Preferences. You can change the schedule, the type of updates to apply or to notify you of available updates. In Gnome, you can find controls for your updates at: System -> Preferences -> Software Updates. In KDE it is located at: Applications -> Settings -> Software Updates.

7.4. Instale paquetes identificados desde repositorios conocidos


Los paquetes de software son publicados a travs de repositorios. Todos los repositorios ms conocidos tienen soporte para poder identificar sus paquetes. La identificacin de los paquetes utiliza tecnologa de llave pblica para confirmar que un paquete publicado por un repositorio, no haya sido alterado desde que la identificacin fue aplicada. Esto ofrece cierta proteccin para evitar instalar software que podra haber sido alterado maliciosamente luego de haber sido creado, pero antes que usted lo haya descargado. 173

Captulo 7. Mantenimiento de Software Si se utilizan demasiados repositorios, o que no sean confiables, o que alojen paquetes sin identificacin, se corre un gran riesgo de introduccin de cdigos maliciosos o que pueden llegar a debilitar su sistema. Sea precavido al agregar repositorios para actualizar su sistema.

174

Debilidades y exposiciones comunes


El sistema de Debilidades y exposiciones comunes (CVE por las iniciales en ingls de Common Vulnerabilities and Exposures) ofrece un mtodo de referencia que contiene las debilidades y las exposiciones ms conocidas relacionadas con la seguridad de la informacin. Este sistema es mantenido por la Corporacin ITRE, con fondos provistos por la Divisin de seguridad ciberntica del Departamento de seguridad domstica de los Estados Unidos. La Corporacin MITRE asigna un identificador CVE para cada debilidad o exposicin. El CVE es utilizado para rastrear una debilidad determinada a travs de diferentes partes de software, ya que un mismo CVE puede afectar diversos paquetes de software y mltiples proveedores.

8.1. Complemento de Yum


El paquete yum-plugin-security es una caracterstica de Fedora. Si se lo instala, el mdulo yum cargado por este paquete puede ser utilizado para hacer que yum solo obtenga actualizaciones relacionadas con la seguridad. Puede tambin ser utilizado para ofrecer informacin acerca de advertencias ofrecidas por Red Hat, o para saber cul es el bug correspondiente en la base de datos Bugzilla de Red Hat, o cul es el nmero de CVE en el directorio MITRE que contiene un paquete determinado Para habilitar estas caractersticas slo es necesario ejecutar el comando yum install yumplugin-security.

8.2. Cmo utilizar yum-plugin-security


El primer subcomando que esto agrega es yum list-sec. Funciona de manera similar a yum check-update, con la diferencia que adems ofrece una lista con el nmero de identificacin de las advertencias de Red Hat, y la clasificacin de cada actualizacin en trminos de "mejora", "solucin de error", o "seguridad": RHSA-2007:1128-6 security autofs - 1:5.0.1-0.rc2.55.el5.1.i386 RHSA-2007:1078-3 security cairo - 1.2.4-3.el5_1.i386 RHSA-2007:1021-3 security cups - 1:1.2.4-11.14.el5_1.3.i386 RHSA-2007:1021-3 security cups-libs - 1:1.2.4-11.14.el5_1.3.i386 Si se utiliza yum list-sec cves, el ID de la advertencia de Red Hat es reemplazado por el (o los) ID de CVE indicado en la actualizacin; si en cambio se utiliza yum list-sec bzs, el ID de la advertencia es reemplazado por los de Bugzilla de Red Hat ofrecidos en el paquete. Si un paquete ofrece varios errores en Bugzilla, o IDs de CVE, el paquete puede ser listado varias veces Un ejemplo del resultado del comando yum list-sec bzs: 410031 security autofs - 1:5.0.1-0.rc2.55.el5.1.i386 387431 security cairo - 1.2.4-3.el5_1.i386 345101 security cups - 1:1.2.4-11.14.el5_1.3.i386 345111 security cups - 1:1.2.4-11.14.el5_1.3.i386 345121 security cups - 1:1.2.4-11.14.el5_1.3.i386 345101 security cups-libs - 1:1.2.4-11.14.el5_1.3.i386 345111 security cups-libs - 1:1.2.4-11.14.el5_1.3.i386 345121 security cups-libs - 1:1.2.4-11.14.el5_1.3.i386 Un ejemplo del resultado del comando yum list-sec cves: CVE-2007-5964 security autofs - 1:5.0.1-0.rc2.55.el5.1.i386 CVE-2007-5503 security cairo - 1.2.4-3.el5_1.i386 175

Captulo 8. Debilidades y exposiciones comunes CVE-2007-5393 security cups - 1:1.2.4-11.14.el5_1.3.i386 CVE-2007-5392 security cups - 1:1.2.4-11.14.el5_1.3.i386 CVE-2007-4352 security cups - 1:1.2.4-11.14.el5_1.3.i386 CVE-2007-5393 security cups-libs - 1:1.2.4-11.14.el5_1.3.i386 CVE-2007-5392 security cups-libs - 1:1.2.4-11.14.el5_1.3.i386 CVE-2007-4352 security cups-libs - 1:1.2.4-11.14.el5_1.3.i386 El segundo nuevo subcomando agregado por el paquete yum-plugin-security es info-sec. Este subcomando utiliza como argumento un nmero de advertencia, ya sea de CVE o de Bugzilla, y ofrece informacin detallada sobre tal advertencia, incluyendo un texto introductorio relacionado con la naturaleza del o los problemas tratados en dicha advertencia Adems de estos dos nuevos subcomandos de yum, se ofrecen nuevas opciones al comando yum update para poder instalar actualizaciones relacionadas exclusivamente con aspectos de la seguridad, o exclusivamente relacionadas con algn error o advertencia Para instalar exclusivamente todas las actualizaciones relacionadas con la seguridad: yum update --security Para instalar exclusivamente todas las actualizaciones relacionadas con el error bugzilla 410101: yum update --bz 410101 Para instalar exclusivamente todas las actualizaciones relacionadas con el ID CVE-2007-5707 de CVE, y aquellas relacioandas con el ID de advertencia de Red Hat RHSA-2007:1082-5: yum update --cve CVE-2007-5707 --advisory RHSA-2007:1082-5 More information about these new capabilities is documented in the yum-plugin-security(8) man page. Para obtener mayor informacin relacionada con actualizaciones de seguridad en Fedora, por favor visite la pgina de seguridad de Fedora en https://fedoraproject.org/wiki/Security (en ingls).

176

Referencias
Las siguientes referencias tienen como objetivo orientar la bsqueda de informacin adicional relacionada con SELinux y con Fedora pero estn ms all del alcance de esta gua. Tenga en cuenta que debido al veloz desarrollo de SELinux, algunos de estos materiales podran utilizarse slo en versiones especficas de Fedora. Libros SELinux en Ejemplos Mayer, MacMillan y Caplan Prentice Hall, 2007 Tutoriales y asistencia Entendiendo y personalizando la poltica de SELinux para HTTP de Apache http://fedora.redhat.com/docs/selinux-apache-fc3/ Tutoriales y charlas de Russell Coker http://www.coker.com.au/selinux/talks/ibmtu-2004/ Tutorial genrico para escritura de Polticas de SELinux http://www.lurking-grue.org/writingselinuxpolicyHOWTO.html Base de Conocimientos de Red Hat http://kbase.redhat.com/ Informacin general Sitio web principal de SELinux de la NSA 1 http://www.nsa.gov/selinux/ NSA SELinux FAQ 2 http://www.nsa.gov/selinux/info/faq.cfm Fedora SELinux FAQ http://fedora.redhat.com/docs/selinux-faq-fc3/ SELinux NSA's Open Source Security Enhanced Linux http://www.oreilly.com/catalog/selinux/ Tecnologa Un repaso de las clases de objetos y permisos http://www.tresys.com/selinux/obj_perms_help.html Integracin del soporte flexible para las Polticas de Seguridad dentro del Sistema Operativo Linux (una historia de la implementacin de Flask en Linux) http://www.nsa.gov/research/_files/selinux/papers/selsymp2005.pdf Implemenetacin de SELinux como un mdulo de seguridad de linux http://www.nsa.gov/research/_files/publications/implementing_selinux.pdf

1 2

http://www.nsa.gov/research/selinux/index.shtml http://www.nsa.gov/research/selinux/faqs.shtml

177

Captulo 9. Referencias Una Configuracin de Poltica de Seguridad para el Linux de Seguridad Mejorada http://www.nsa.gov/research/_files/selinux/papers/policy/policy.shtml Comunidad Gua del Usuario de SELinux de Fedora http://docs.fedoraproject.org/selinux-user-guide/ Gua de administracin de servicios confinados de SELinux de Fedora http://docs.fedoraproject.org/selinux-managing-confined-services-guide/ Pgina comunitaria de SELinux http://selinux.sourceforge.net IRC irc.freenode.net, #selinux, #fedora-selinux, #security Historia Historia breve de Flask http://www.cs.utah.edu/flux/fluke/html/flask.html Antecedentes completos sobre Fluke http://www.cs.utah.edu/flux/fluke/html/index.html

178

Apndice A. Estndares de cifrado


A.1. Cifrado sincronizado
A.1.1. Advanced Encription Standard - AES
In cryptography, the Advanced Encryption Standard (AES) is an encryption standard adopted by the U.S. government. The standard comprises three block ciphers, AES-128, AES-192 and AES-256, adopted from a larger collection originally published as Rijndael. Each AES cipher has a 128-bit block size, with key sizes of 128, 192 and 256 bits, respectively. The AES ciphers have been analyzed extensively and are now used worldwide, as was the case with its predecessor, the Data Encryption 1 Standard (DES).

A.1.1.1. Usos de AES A.1.1.2. Historia de AES


AES was announced by National Institute of Standards and Technology (NIST) as U.S. FIPS PUB 197 (FIPS 197) on November 26, 2001 after a 5-year standardization process in which fifteen competing designs were presented and evaluated before Rijndael was selected as the most suitable (see Advanced Encryption Standard process for more details). It became effective as a standard May 26, 2002. It is available in many different encryption packages. AES is the first publicly accessible and 2 open cipher approved by the NSA for top secret information (see Security of AES, below). The Rijndael cipher was developed by two Belgian cryptographers, Joan Daemen and Vincent Rijmen, and submitted by them to the AES selection process. Rijndael (pronounced [r#inda#l]) is a 3 portmanteau of the names of the two inventors.

A.1.2. Data Encryption Standard - DES


The Data Encryption Standard (DES) is a block cipher (a form of shared secret encryption) that was selected by the National Bureau of Standards as an official Federal Information Processing Standard (FIPS) for the United States in 1976 and which has subsequently enjoyed widespread use internationally. It is based on a symmetric-key algorithm that uses a 56-bit key. The algorithm was initially controversial with classified design elements, a relatively short key length, and suspicions about a National Security Agency (NSA) backdoor. DES consequently came under intense academic 4 scrutiny which motivated the modern understanding of block ciphers and their cryptanalysis.

A.1.2.1. Usos de DES A.1.2.2. Historia de DES


DES is now considered to be insecure for many applications. This is chiefly due to the 56-bit key size being too small; in January, 1999, distributed.net and the Electronic Frontier Foundation

1 2

"Advanced Encryption Standard." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Advanced_Encryption_Standard "Advanced Encryption Standard." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Advanced_Encryption_Standard 3 "Advanced Encryption Standard." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Advanced_Encryption_Standard 4 "Data Encryption Standard." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Data_Encryption_Standard

179

Apndice A. Estndares de cifrado collaborated to publicly break a DES key in 22 hours and 15 minutes (see chronology). There are also some analytical results which demonstrate theoretical weaknesses in the cipher, although they are unfeasible to mount in practice. The algorithm is believed to be practically secure in the form of Triple DES, although there are theoretical attacks. In recent years, the cipher has been superseded by the 5 Advanced Encryption Standard (AES). In some documentation, a distinction is made between DES as a standard and DES the algorithm which is referred to as the DEA (the Data Encryption Algorithm). When spoken, "DES" is either spelled 6 out as an abbreviation (/#di##i###s/), or pronounced as a one-syllable acronym (/#d#z/).

A.2. Cifrado de llave pblica


Public-key cryptography is a cryptographic approach, employed by many cryptographic algorithms and cryptosystems, whose distinguishing characteristic is the use of asymmetric key algorithms instead of or in addition to symmetric key algorithms. Using the techniques of public key-private key cryptography, many methods of protecting communications or authenticating messages formerly unknown have become practical. They do not require a secure initial exchange of one or more secret keys as is required when using symmetric key algorithms. It can also be used to create digital 7 signatures. Public key cryptography is a fundamental and widely used technology around the world, and is the approach which underlies such Internet standards as Transport Layer Security (TLS) (successor to 8 SSL), PGP and GPG. The distinguishing technique used in public key cryptography is the use of asymmetric key algorithms, where the key used to encrypt a message is not the same as the key used to decrypt it. Each user has a pair of cryptographic keys a public key and a private key. The private key is kept secret, whilst the public key may be widely distributed. Messages are encrypted with the recipient's public key and can only be decrypted with the corresponding private key. The keys are related mathematically, but the private key cannot be feasibly (ie, in actual or projected practice) derived from the public key. It was the discovery of such algorithms which revolutionized the practice of cryptography beginning in the 9 middle 1970s. In contrast, Symmetric-key algorithms, variations of which have been used for some thousands of years, use a single secret key shared by sender and receiver (which must also be kept private, thus accounting for the ambiguity of the common terminology) for both encryption and decryption. To use a 10 symmetric encryption scheme, the sender and receiver must securely share a key in advance. Because symmetric key algorithms are nearly always much less computationally intensive, it is common to exchange a key using a key-exchange algorithm and transmit data using that key and a symmetric key algorithm. PGP, and the SSL/TLS family of schemes do this, for instance, and are 11 called hybrid cryptosystems in consequence.

A.2.1. Diffie-Hellman
DiffieHellman key exchange (DH) is a cryptographic protocol that allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure

5 6

"Data Encryption Standard." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Data_Encryption_Standard "Data Encryption Standard." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Data_Encryption_Standard 7 "Public-key Encryption." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Public-key_cryptography 8 "Public-key Encryption." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Public-key_cryptography 9 "Public-key Encryption." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Public-key_cryptography 10 "Public-key Encryption." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Public-key_cryptography 11 "Public-key Encryption." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Public-key_cryptography

180

RSA communications channel. This key can then be used to encrypt subsequent communications using a 12 symmetric key cipher.

A.2.1.1. La historia de Diffie-Hellman


The scheme was first published by Whitfield Diffie and Martin Hellman in 1976, although it later emerged that it had been separately invented a few years earlier within GCHQ, the British signals intelligence agency, by Malcolm J. Williamson but was kept classified. In 2002, Hellman suggested the algorithm be called DiffieHellmanMerkle key exchange in recognition of Ralph Merkle's contribution 13 to the invention of public-key cryptography (Hellman, 2002). Although DiffieHellman key agreement itself is an anonymous (non-authenticated) key-agreement protocol, it provides the basis for a variety of authenticated protocols, and is used to provide perfect forward secrecy in Transport Layer Security's ephemeral modes (referred to as EDH or DHE 14 depending on the cipher suite). U.S. Patent 4,200,770, now expired, describes the algorithm and credits Hellman, Diffie, and Merkle 15 as inventors.

A.2.2. RSA
In cryptography, RSA (which stands for Rivest, Shamir and Adleman who first publicly described it; see below) is an algorithm for public-key cryptography. It is the first algorithm known to be suitable for signing as well as encryption, and was one of the first great advances in public key cryptography. RSA is widely used in electronic commerce protocols, and is believed to be secure given sufficiently long 16 keys and the use of up-to-date implementations.

A.2.3. DSA
The Digital Signature Algorithm (DSA) is a United States Federal Government standard or FIPS for digital signatures. It was proposed by the National Institute of Standards and Technology (NIST) in August 1991 for use in their Digital Signature Standard (DSS), specified in FIPS 186, adopted in 1993. A minor revision was issued in 1996 as FIPS 186-1. The standard was expanded further in 2000 as 17 FIPS 186-2 and again in 2009 as FIPS 186-3.

A.2.4. SSL/TLS
TLS (Transport Layer Security) y su predecesor, SSL (Secure Socket Layer), son protocolos de criptografa que ofrecen seguridad a las comunicaciones establecidas sobre redes como Internet. TLS y SSL cifran los segmentos en toda la capa de transporte de las conexiones de red. Diferentes versiones de los protocolos estn siendo ampliamente utilizadas en diferentes aplicaciones: navegadores web, correo electrnico, envo de faxes por Internet, mensajeras instantneas y VoIP (voz sobre IP) TLS es un protocolo de rastreo estndar IETF, actualizado en RFC 5246, y est basado en las anteriores especificaciones SSL, desarrolladas por la corporacin Netscape. El protocolo TLS permite que aplicaciones de cliente/servidor puedan comunicarse sobre una red de una manera diseada para prevenir escuchas o manipulaciones. TLS pfrece autenticacin final y

12 13

"Diffie-Hellman." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Diffie-Hellman "Diffie-Hellman." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Diffie-Hellman 14 "Diffie-Hellman." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Diffie-Hellman 15 "Diffie-Hellman." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Diffie-Hellman 16 "RSA" Wikipedia 14 April 2010 http://en.wikipedia.org/wiki/RSA 17 "Digital Signature Algorithm" Wikipedia 14 April 2010 http://en.wikipedia.org/wiki/Digital_Signature_Algorithm

181

Apndice A. Estndares de cifrado confidencialidad de las comunicaciones sobre Internet utilizando criptografa. TLS ofrece seguridad RSA con potencia de 1024 y de 2048 bits. In typical end-user/browser usage, TLS authentication is unilateral: only the server is authenticated (the client knows the server's identity), but not vice versa (the client remains unauthenticated or anonymous). TLS also supports the more secure bilateral connection mode (typically used in enterprise applications), in which both ends of the "conversation" can be assured with whom they are communicating (provided they diligently scrutinize the identity information in the other party's certificate). This is known as mutual authentication, or 2SSL. Mutual authentication requires that the TLS client-side also hold a certificate (which is not usually the case in the end-user/browser scenario). Unless, that is, TLS-PSK, the Secure Remote Password (SRP) protocol, or some other protocol is used that can provide strong mutual authentication in the absence of certificates. Generalmente, la informacin de la llave y los certificados necesarios para TLS son manipulados bajo la forma de certificados X.509, que define los campos requeridos y el formato de los datos. SSL operates in modular fashion. It is extensible by design, with support for forward and backward 18 compatibility and negotiation between peers.

A.2.5. Criptosistema de Cramer-Shoup


The CramerShoup system is an asymmetric key encryption algorithm, and was the first efficient scheme proven to be secure against adaptive chosen ciphertext attack using standard cryptographic assumptions. Its security is based on the computational intractability (widely assumed, but not proved) of the decisional DiffieHellman assumption. Developed by Ronald Cramer and Victor Shoup in 1998, it is an extension of the Elgamal cryptosystem. In contrast to Elgamal, which is extremely malleable, CramerShoup adds additional elements to ensure non-malleability even against a resourceful attacker. This non-malleability is achieved through the use of a collision-resistant hash function and 19 additional computations, resulting in a ciphertext which is twice as large as in Elgamal.

A.2.6. Cifrado ElGamal


In cryptography, the ElGamal encryption system is an asymmetric key encryption algorithm for publickey cryptography which is based on the Diffie-Hellman key agreement. It was described by Taher Elgamal in 1985.[1] ElGamal encryption is used in the free GNU Privacy Guard software, recent versions of PGP, and other cryptosystems. The Digital Signature Algorithm is a variant of the ElGamal 20 signature scheme, which should not be confused with ElGamal encryption.

18 19

"Transport Layer Security" Wikipedia 14 April 2010 http://en.wikipedia.org/wiki/Transport_Layer_Security "CramerShoup cryptosystem" Wikipedia 14 April 2010 http://en.wikipedia.org/wiki/Cramer-Shoup_cryptosystem 20 "ElGamal encryption" Wikipedia 14 April 2010 http://en.wikipedia.org/wiki/ElGamal_encryption

182

Apndice B. Historial de revisiones


Revisin Sat October 6 2012 Eric Christensen 18.0-1 sparks@fedoraproject.org Fixed Basic Hardening chapter (BZ 841825 and 693620). Fixed broken LUKS link (BZ 846299). Added GUI section to 7 Zip chapter (BZ 854781). Fixed yum-plugin-security chapter (BZ 723282). Fixed GPG CLI command screen (BZ 590493). Improved Yubikey section (BZ 644238). Fixed typos (BZ 863636). Removed wiki markup found in some chapters. Updated the Seahorse instructions.

Revisin Tue January 24 2012 17.0-1 Branched for Fedora 17.

Eric Christensen sparks@fedoraproject.org

Revisin Fri September 09 2011 16.0-1 Branched for Fedora 16.

Eric Christensen sparks@fedoraproject.org

Revisin Sat Apr 02 2011 Eric Christensen 14.3-1 sparks@fedoraproject.org Moved VPN text to the Encryption chapter and reformated.

Revisin Wed Oct 20 2010 Zach Oglesby 14.2-1 zoglesby@fedoraproject.org Added text for using Yubikey on Fedora with local authentication. (BZ 644999)

Revisin Fri Oct 6 2010 Eric Christensen 14.2-0 sparks@fedoraproject.org Eliminadas todas las variantes de la fuente del documento.

Revisin Fri Oct 1 2010 Eric Christensen 14.1-2 sparks@fedoraproject.org Corregido y actualizado el enlace a la Lista de verificacin Unix de DISA.

Revisin Wed Jul 8 2010 14.1-1 Agregado el captulo relacionado con CVE.

Eric Christensen sparks@fedoraproject.org

183

Apndice B. Historial de revisiones Revisin Fri May 28 2010 14.0-1 Agregado en la rama Fedora 14. Eric Christensen sparks@fedoraproject.org

Revisin Fri May 14 2010 Eric Christensen 13.0-7 sparks@fedoraproject.org Removed "bug" text from 7-Zip chapter per bug 591980.

Revisin Wed Apr 14 2010 Eric Christensen 13.0-6 sparks@fedoraproject.org Completado el apndice sobre estndares de cifrado.

Revisin Fri Apr 09 2010 13.0-5 Added "Using GPG with Alpine". Added "Using GPG with Evolution".

Eric Christensen sparks@fedoraproject.org

Revisin Tue Apr 06 2010 Eric Christensen 13.0-4 sparks@fedoraproject.org Solucionados problemas relacionados con textos imposibles de traducir en para.

Revisin Tue Apr 06 2010 Eric Christensen 13.0-3 sparks@fedoraproject.org Eliminado el texto de la vulnerabilidad de PackageKit en Fedora 12.

Revisin 13.0-2

Fri Nov 20 2009

Eric Christensen sparks@fedoraproject.org

Agregado el Historial de revisiones al final del documento. Agregado el apndice Estndares de cifrado

Revisin Fri Nov 20 2009 13.0-1 Rama de Fedora 13.

Eric Christensen sparks@fedoraproject.org

Revisin Thu Nov 19 2009 Eric Christensen 1.0-23 sparks@fedoraproject.org Updated the section "Local users may install trusted packages" to the latest fix, again.

Revisin 1.0-22

Thu Nov 19 2009

Eric Christensen sparks@fedoraproject.org

184

Updated the section "Local users may install trusted packages" to the latest fix.

Revisin Wed Nov 18 2009 Eric Christensen 1.0-21 sparks@fedoraproject.org Added section "Local users may install trusted packages".

Revisin Sat Nov 14 2009 Eric Christensen 1.0-20 sparks@fedoraproject.org Agregada informacin desde Wikipedia al apndice Estndares de cifrado Agregado Adam Ligas a la pgina de autores por su rol en el desarrollo de las porciones de 7-Zip.

Revisin Mon Oct 26 2009 1.0-19 Actualizada la licencia a CC-BY-SA

Eric Christensen sparks@fedoraproject.org

Revisin Wed Aug 05 2009 Eric Christensen 1.0-18 sparks@fedoraproject.org Solucinados los inconvenientes relacionados con el Bug 515043

Revisin Mon Jul 27 2009 Eric Christensen 1.0-17 sparks@fedoraproject.org Informacin del proveedor en SPEC reparada.

Revisin Fri Jul 24 2009 Fedora Ingeniera de lanzamiento 1.0-16 rel-eng@lists.fedoraproject.org Recompilacin para https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild

Revisin Tue Jul 14 2009 Eric Christensen 1.0-15 sparks@fedoraproject.org Added "desktop-file-utils" to BUILDREQUIRES on the spec

Revisin Tue Mar 10 2009 Scott Radvan sradvan@redhat.com 1.0-14 Remove more rhel specifics, major review and remove draft, ready for push

Revisin Mon Mar 2 2009 1.0-13 Muchas correcciones menores

Scott Radvan sradvan@redhat.com

Revisin 1.0-12

Wed Feb 11 2009

Scott Radvan sradvan@redhat.com

185

Apndice B. Historial de revisiones nuevos pantallazos de F11 que reemplazan las anteriores/ms viejas

Revisin Tue Feb 03 2009 Scott Radvan sradvan@redhat.com 1.0-11 LUKS especfico a Fedora 9 modificado para incluir las versiones posteriores tambin. Correccin de los errores 404 en la seccin de referencias, principalmente por enlaces incorrectos a NSA. cambios de formatos menores.

Revisin Wed Jan 27 2009 Eric Christensen 1.0-10 sparks@fedoraproject.org Se corrigi la falta de un pantallazo de la configuracin del cortafuego.

Revisin 1.0-9 Wed Jan 27 2009

Eric Christensen sparks@fedoraproject.org Se repararon items que estaban incorrectos durante la validacin. Muchas referencias de Red Hat se cambiaron a referencias de Fedora.

186