fedora 11
guía de seguridad
Una guía para la seguridad en fedora
Edición 1.0
aviso legal
Copyright © 2008 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share 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.
All other trademarks are the property of their respective owners.
Resumen
La Guía de Seguridad Linux está diseñada para asistir a usuarios de
Linux en el proceso de aprendizaje y en la realización de prácticas
de seguridad en estaciones de trabajo y servidores, para poder así
evitar intrusiones locales y remotas, explotaciones, y actividades
maliciosas. La Guía de Seguridad Linux detalla la planificación y
describe las herramientas involucradas en la creación de un entorno
de computación seguro, ya sea 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 métodos de
intrusión y explotación mas comunes.
- Prefacio
- 1. Repaso sobre seguridad
- 2. Asegurando su Red
- 2.1. Seguridad de la estación de trabajo
- 2.2. Seguridad del servidor
- 2.3. Identificación única (SSO, por las iniciales en inglés de Single Sign-on)
- 2.4. Módulos de autenticación conectables (PAM, por las iniciales en inglés de Pluggable Authentication Modules)
- 2.4.1. Ventajas de PAM
- 2.4.2. Archivos de configuración de PAM
- 2.4.3. Formato del archivo de configuración de PAM
- 2.4.4. Ejemplos de archivos de configuración de PAM
- 2.4.5. Creación de los módulos PAM
- 2.4.6. PAM y el cacheo de la credencial administrativa
- 2.4.7. PAM y la propiedad de los dispositivos
- 2.4.8. Recursos adicionales
- 2.5. Encapsuladores TCP y xinetd
- 2.6. Kerberos
- 2.6.1. ¿Qué es Kerberos?
- 2.6.2. Terminología de Kerberos
- 2.6.3. Como Funciona Kerberos
- 2.6.4. Kerberos y PAM
- 2.6.5. Configurando un servidor Kerberos 5
- 2.6.6. Configuración de un Cliente Kerberos 5
- 2.6.7. Mapeo dominio-a-reinado
- 2.6.8. Configurando KDCs secundarios
- 2.6.9. Configurando la autenticación cruzada de reinados
- 2.6.10. Recursos adicionales
- 2.7. Redes privadas virtuales (VPNs, por las iniciales en inglés de Virtual Private Networks)
- 2.8. Cortafuegos
- 2.9. IPTables
- 3. Encriptación
- 3.1. Datos en reposo
- 3.2. Encriptación completa del disco
- 3.3. Encriptación basada en archivo
- 3.4. Datos en movimiento
- 3.5. Redes privadas virtuales (VPNs)
- 3.6. Shell seguro (SSH, por las iniciales en inglés de Secure Shell)
- 3.7. Encriptación de disco LUKS (Linux Unified Key Setup-on-disk-format)
- 3.8. Archivos Encriptados 7-Zip
- 3.9. Utilizando GNU Privacy Guard (GnuPG)
- 4. Principios Generales sobre la Seguridad de la Información
- 5. Instalación segura
- 6. Mantenimiento de Software
- 7. Referencias
Prefacio
1. Convenciones del documento
Este manual utiliza varias convenciones para resaltar algunas palabras y frases y llamar la atención sobre ciertas partes específicas de información.
En ediciones PDF y de papel, este manual utiliza tipos de letra procedentes de Liberation Fonts. Liberation Fonts también se utilizan en ediciones de HTML si están instalados en su sistema. Si no, se muestran tipografías alternativas pero equivalentes. Nota: Red Hat Enterprise Linux 5 y siguientes incluyen Liberation Fonts predeterminadas.
1.1. Convenciones tipográficas
Se utilizan cuatro convenciones tipográficas para llamar la atención sobre palabras o frases específicas. 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. También se utiliza para resaltar teclas claves y combinaciones de teclas.
To see the contents of the filemy_next_bestselling_novelin your current working directory, enter thecat my_next_bestselling_novelcommand at the shell prompt and press Enter to execute the command.
The above includes a file name, a shell command and a key cap, all presented in Mono-spaced Bold and all distinguishable thanks to context.
Key-combinations can be distinguished from key caps by the hyphen connecting each part of a key-combination. For example:
Press Enter to execute the command.Press Ctrl+Alt+F1 to switch to the first virtual terminal. Press Ctrl+Alt+F7 to return to your X-Windows session.
The first sentence highlights the particular key cap to press. The second highlights two sets of three key caps, each set pressed simultaneously.
If source code is discussed, class names, methods, functions, variable names and returned values mentioned within a paragraph will be presented as above, in
Mono-spaced Bold. For example:
File-related classes includefilesystemfor file systems,filefor files, anddirfor directories. Each class has its own associated set of permissions.
Proportional Bold
This denotes words or phrases encountered on a system, including application names; dialogue box text; labelled buttons; check-box and radio button labels; menu titles and sub-menu titles. For example:
Choose from the main menu bar to launch Mouse Preferences. In the Buttons tab, click the Left-handed mouse check box and click to switch the primary mouse button from the left to the right (making the mouse suitable for use in the left hand).To insert a special character into a gedit file, choose from the main menu bar. Next, choose from the Character Map menu bar, type the name of the character in the Search field and click . The character you sought will be highlighted in the Character Table. Double-click this highlighted character to place it in the Text to copy field and then click the button. Now switch back to your document and choose from the gedit menu bar.
The above text includes application names; system-wide menu names and items; application-specific menu names; and buttons and text found within a GUI interface, all presented in Proportional Bold and all distinguishable by context.
Note the shorthand used to indicate traversal through a menu and its sub-menus. This is to avoid the difficult-to-follow 'Select from the sub-menu in the menu of the main menu bar' approach.
Mono-spaced Bold ItalicProportional Bold Italic
Whether Mono-spaced Bold or Proportional Bold, the addition of Italics indicates replaceable or variable text. Italics denotes text you do not input literally or displayed text that changes depending on circumstance. For example:
To connect to a remote machine using ssh, typesshat a shell prompt. If the remote machine isusername@domain.nameexample.comand your username on that machine is john, typessh john@example.com.Themount -o remountcommand remounts the named file system. For example, to remount thefile-system/homefile system, the command ismount -o remount /home.To see the version of a currently installed package, use therpm -qcommand. It will return a result as follows:package.package-version-release
Note the words in bold italics above — username, domain.name, file-system, package, version and release. Each word is a placeholder, either for text you enter when issuing a command or for text displayed by the system.
Aside from standard usage for presenting the title of a work, italics denotes the first use of a new and important term. For example:
When the Apache HTTP Server accepts requests, it dispatches child processes or threads to handle them. This group of child processes or threads is known as a server-pool. Under Apache HTTP Server 2.0, the responsibility for creating and maintaining these server-pools has been abstracted to a group of modules called Multi-Processing Modules (MPMs). Unlike other modules, only one module from the MPM group can be loaded by the Apache HTTP Server.
1.2. Convenciones del documento
Dos, usualmente de varias líneas, los tipos de datos se distinguen visualmente del texto circundante.
Salida enviada a una terminal está establecida en tipo
romano monoespaciado y presentada así:
libros Escritorio documentación borradores mss fotos cosas svn libros_tests Escritorio1 descargas imágenes notas scripts svgs
Los listados de código fuente también se establecen 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 atención sobre la información que de otro modo se podría pasar por alto.
Nota
Una nota es una sugerencia, atajo o enfoque alternativo que se tiene a mano para la tarea. Ignorar una nota no debería tener consecuencias negativas, pero podría perderse de algunos trucos que pueden facilitarle las cosas.
Importante
Los cuadros de importante dan detalles de cosas que se pueden pasar por alto fácilmente: cambios de configuración únicamente aplicables a la sesión actual, o servicios que necesitan reiniciarse antes de que se aplique una actualización. Ignorar estos cuadros de importante no ocasionará pérdida de datos, pero puede causar enfado y frustración.
Advertencia
Las advertencias no deben ignorarse. Ignorarlas muy probablemente ocasionará pérdida de datos.
2. ¡Necesitamos sus comentarios!
Más información acerca del proyecto Guía de Seguridad de Linux puede encontrarse en https://fedorahosted.org/securityguide
Para entregar una retroalimentación de la Guía de Seguridad, por favor envíe un error a https://bugzilla.redhat.com/enter_bug.cgi?component=security-guide&product=Fedora%20Documentation. Por favor seleccione el componente adecuado en el menú desplegable, que debería ser el nombre de la página.
Capítulo 1. Repaso sobre seguridad
Debido a la creciente necesidad de utilización de poderosas computadoras conectadas en red para poder mantener una empresa en funcionamiento, y para poder realizar seguimientos de nuestra información personal, se han desarrollado industrias enteras dedicadas a la práctica 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 diseñen soluciones adecuadas a los requerimientos operativos de la organización. Debido a la naturaleza dinámica de muchas de estas organizaciones, donde los trabajadores deben tener acceso a los recursos informáticos, ya sea en forma local o remota, la necesidad de entornos de computación seguros se ha hecho más 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, dándole prioridad a otras áreas de sus emprendimientos, como ser producción, presupuesto, o infraestructura. Y frecuentemente, una implementación adecuada de la seguridad es adoptada postmortem — luego 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 mayoría de los intentos de intrusión.
1.1. Introducción a la Seguridad
1.1.1. ¿Qué es la seguridad en computación?
La noción de seguridad en computación es un concepto general que cubre un área muy extensa dentro del ámbito de la computación y del procesamiento de la información. Las industrias que dependen tanto de redes como de sistemas de computación para poder realizar cotidianamente operaciones comerciales, o para acceder a diverso tipo de información vital, entienden que sus datos son una parte importante de sus activos. Han ingresado a nuestro vocabulario cotidiano diversos términos y unidades de medición pertenecientes al ámbito comercial, como ser por ejemplo, el coste total de propiedad (TCO, por las iniciales en inglés de Total Cost of Ownership), o servicio de calidad (QoS, por las iniciales en inglés 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 administración de procesos. En algunas industrias, como la del comercio electrónico 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 dónde viene la idea de seguridad en computación?
La seguridad en la información ha evolucionado con el correr de los años debido al aumento en la utilización de redes públicas y el consecuente riesgo de exposición que en ellas tienen los datos privados, confidenciales o financieros. Existen numerosos antecedentes, como el caso Mitnick [1] o Vladimir Levin [2], que sugieren a todas las organizaciones de cualquier tipo de industria, replantearse la forma en que tienen organizado el manejo de su propia información, 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 número creciente de personas está utilizando sus computadoras personales para obtener acceso a los recursos que ofrece Internet. Desde investigación y obtención de información hasta el correo electrónico y transacciones comerciales, Internet es considerada como uno de los desarrollos más 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 diseñado para ser seguro en sí mismo. No existen estándares de seguridad aprobados dentro del bloque de comunicaciones TCP/IP, dejándolo indefenso ante usuarios o procesos de la red potencialmente dañinos. Desarrollos modernos han hecho de las comunicaciones en Internet algo más seguro, pero todavía existen varios incidentes que acaparan la atención mundial, y nos recuerdan el hecho de que nada es completamente seguro.
1.1.1.2. La seguridad hoy
En febrero del año 2000 un ataque de denegación de servicio distribuido (DDoS, por las iniciales en inglés de Distributed Denial of Service) fue liberado sobre varios de los sitios de Internet que tenían más tráfico. 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 también denominado un ping de la muerte. El ataque fue llevado a cabo por asaltantes desconocidos utilizando programas especialmente creados (y que están a disposición 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 dejándolos inutilizables. Muchos adjudican el éxito del ataque a fallas fundamentales en la forma en que están 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 dónde provengan, o con qué propósito los paquetes hayan sido enviados.
En el año 2007, una pérdida de datos permitió la explotación de una debilidad bien conocida en el protocolo de encriptación inalámbrica WEP (por las iniciales en inglés de Wired Equivalent Privacy), que resultó en el robo de 45 millones de números de tarjetas de créditos de una institución financiera global.[3]
En otro incidente, los registros de facturación de 2,2 millones de pacientes fueron robados del asiento de un vehículo de cadetería, al encontrarse almacenados en una cinta de respaldo. [4]
Actualmente, se estima que 1,4 mil millones de personas usan o usaron Internet alrededor del mundo [5]. Al mismo tiempo:
- En cualquier día, hay aproximadamente 225 incidentes principales de brechas de seguridad informados al Centro de Coordinación CERT en la Universidad de Carnegie Mellon.[6]
- En el año 2003, el número de incidencias CERT informadas ascendió a 137.529 de los 82.094 informados en el año 2002, y de los 52.658 en el 2001.[7]
- El impacto económico a nivel mundial de los virus de Internet más peligrosos de los últimos tres años se estimó en U$S 13,2 mil millones.[8]
Del informe global "El Estado Global de la Seguridad de la Información"[9], realizado por CIO Magazine en el año 2008 sobre diferentes negocios y ejecutivos en tecnologías, se extrae lo siguiente:
- Sólo el 43% de los encuestados audita o monitorea el cumplimiento de las políticas de seguridad de sus usuarios
- Sólo el 22% mantiene un inventario de las compañías externas que utilizan sus datos
- El orígen de casi la mitad de los incidentes de seguridad se marcaron como "Desconocidos"
- 44% de los encuestados planean incrementar sus gastos en seguridad en el año siguiente
- 59% tiene una estrategia de seguridad de la información
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 rápida 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 días del año. Ser víctima de usuarios maliciosos, procesos o ataques coordinados es una amenaza directa al éxito de la organización.
Desafortunadamente, la seguridad de sistemas y de la red puede ser una proposición difícil, que requiere un conocimiento intrincado de cómo una organización expresa, usa, manipula y transmite su información. El entendimiento de la forma en que una organización (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 confían en las regulaciones y en las reglas que son puestas por las personas que construyen estándares tales como la Asociación Médica Americana (AMA, por las iniciales en inglés de American Medical Association) o el Instituto de Ingenieros Eléctricos y Electrónicos (IEEE, Institute of Electrical and Electronics Engineers). Los mismos ideales se aplican a la seguridad de la información. Muchos consultores y fabricantes se ponen de acuerdo en el modelo de seguridad estándar 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 información vital y del establecimiento de la política de seguridad. A continuación se describe el modelo CIA en más detalle:
- Confidencialidad — La información vital debe estar disponible sólo para un conjunto de individuos predefinido. La transmisión no autorizada y el uso de la información se debe restringir. Por ejemplo, la confidencialidad de la información asegura que la información personal o financiera de un cliente no pueda ser obtenida por un individuo no autorizado para propósitos maléficos tales como el robo de identidad, o fraude crediticio.
- Integridad — La información 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 información vital.
- Disponibilidad — La información debe ser accesible a usuarios autorizados en cualquier momento en el que sea necesario. La disponibilidad es una garantía de que la información se puede obtener en una frecuencia y duración preestablecida. Esto se mide a menudo en términos de porcentajes y se deja sentado formalmente en Acuerdos de Disponibilidad del Servicio (SLAs, por las iniciales en inglés 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 más fino de control sobre los archivos, procesos, usuarios y aplicaciones en el sistema. La discusión detallada sobre SELinux está más allá del alcance de este documento; sin embargo, para más información sobre SELinux y su uso en Fedora, vaya a la Guía del Usuario de SELinux de Fedora disponible en http://docs.fedoraproject.org/selinux-user-guide/. Hay otros recursos de SELinux listados en Capítulo 7, Referencias.
1.1.3. Controles de seguridad
La seguridad de computadoras es a menudo dividida en tres categorías principales distintas, comúnmente referidas como controles:
- Físico
- Técnico
- Asministrativo
Estas tres amplias categorías definen los objetivos principales de una implementación de seguridad apropiada. Dentro de estos controles existen subcategorías que ofrecen mayores características, o brindan información acerca de su correcta implementación.
1.1.3.1. Control físico
El control físico es la implementación de medidas de seguridad en una estructura definida, utilizado para determinar o evitar el acceso no autorizado a material sensible. Ejemplos de controles físicos son:
- Circuito cerrado de cámaras de vigilancia
- Sistemas de alarma de movimientos, o termales
- Guardias de la seguridad
- IDs de Imagen
- Puertas de acero bloqueadas y selladas
- Biometría (incluye huellas digitales, voz, cara, iris, escritura manual y otros métodos automatizados usados para reconocer a los individuos)
1.1.3.2. Técnicas de control
Los controles técnicos usan la tecnología como una base para el control del acceso y del uso de datos sensibles a través de una estructura física y sobre una red. Los controles técnicos son de largo alcance y abarcan tecnologías como:
- Encriptación
- Tarjetas inteligentes
- Autenticación de red
- Listas de control de acceso (ACLs)
- Software para auditar la integridad de archivos
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 organización y determinan qué usuarios tienen acceso a qué recursos y la información por tales medios como:
- Capacitación y conocimientos
- Preparación para desastres y planes de recuperación
- Reclutamiento de personal y estrategias de separación
- Registración y control del personal
1.1.4. Conclusión
Ahora que ya conoce los orígenes, las razones y los aspectos de la seguridad, encontrará más fácil 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 información en mente, el proceso se puede formalizar y los caminos a seguir se hacen más claros a medida que profundiza en los detalles del proceso de seguridad.
1.2. Evaluación de debilidades
Dependiendo del tiempo, de los recursos y de la motivación, un atacante puede ingresar prácticamente en cualquier sistema. En términos absolutos, ninguna tecnología 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 envían datos en forma segura mediante un flujo encriptado. Sistemas para la detección de extraños le avisan en caso de encontrar actividad malintencionada. Sin embargo, el éxito de cada una de estas tecnologías depende de una numerosa cantidad de variables, entre las cuales podemos encontrar:
- La experiencia del equipo responsable de la configuración, monitoreo y manutención de esas tecnologías.
- 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 características dinámicas de los sistemas de datos y de las tecnologías, asegurar los recursos corporativos puede llegar a ser algo bastante complejo. Debido a esta complejidad, a menudo es difícil 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 información, es difícil 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 información necesita atención y concentración constante. La seguridad en la información nunca permanece inmóvil.
1.2.1. Pensando como el enemigo
Imagine que usted administra la red de una empresa. Por lo general tales redes están compuestas de sistemas operativos, aplicaciones, servidores, monitores de red, cortafuegos, sistemas para la detección de intrusos, y mucho más. Ahora imagínese tratando de mantenerse actualizado en todos esos aspectos. Dada la complejidad del software y de los entornos de red que existe hoy en día, los errores y los puntos débiles son permanentes. Mantenerse al día con los parches y las actualizaciones, para la totalidad de la red de una gran organización con sistemas heterogéneos, puede convertirse en una tarea intimidante.
Combine la experiencia que habría que necesitarse, con las tareas a realizar para mantenerse actualizado, y serán inevitables la presencia de incidentes, de sistemas vulnerados, de datos alterados, y de servicios interrumpidos.
Para incrementar las tecnologías en seguridad y ayudar a proteger los sistemas, redes y datos, debería 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 enseñarle potenciales problemas, y solucionarlos, antes que sean aprovechados por un atacante.
Una evaluación de debilidades es una auditoría 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 Sección 1.1.1.3, “Estandarizando la seguridad”). Por lo general, una evaluación 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 categorías de riesgo alto, medio y bajo. En esta última etapa, además, se proponen métodos para mejorar la seguridad (o eliminar el riego) del sistema analizado.
Si usted tuviera que realizar una evaluación de las debilidades de su hogar, seguramente verificaría que cada una de las puertas se encuentre cerrada con llave. También confirmaría que cada una de las ventanas esté cerrada, y trabada con el pestillo. El mismo concepto se aplica a los sistemas, redes y datos electrónicos. Los usuarios malintencionados son los ladrones de sus datos. Concéntrese 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.2.2. Definiendo evaluación y pruebas
Las evaluaciones de debilidades pueden ser catalogadas en dos grandes tipos: De afuera hacia adentro y de adentro hacia afuera.
Cuando se realice una evaluación de debilidades desde afuera hacia adentro, estará intentando comprometer su sistema desde el exterior. El punto de vista del atacante lo obtiene al considerarse fuera de su compañía. Usted ve lo que el atacante ve — direcciones IP públicas y capaces de ser enrutadas, sistemas en las interfases externas DMZ de su cortafuegos, y más. DMZ significa "zona desmilitarizada" (por las iniciales en inglés de Demilitarized Zone), y hace referencia a una computadora o red pequeña ubicada entre una red interna confiable, como por ejemplo una red LAN corporativa privada, y una red externa no confiable, como por ejemplo lo es Internet pública. Por lo general, DMZ contiene dispositivos accesibles al tráfico de Internet, como son los servidores de red (HTTP), servidores FTP, servidores SMTP (correo electrónico) y servidores DNS.
Cuando realice una evaluación de debilidades desde adentro hacia afuera, usted tiene una especie de ventaja ya que, al estar en una ubicación interna, su estado es el de ser alguien confiable, y por lo tanto, superior. Este es el punto de vista adquieren usted y sus compañeros de trabajo, cada vez que se registran en el sistema. Puede ver servidores de impresión, servidores de archivos, bases de datos, y demás recursos.
Existen notables distinciones entre estos dos tipos de evaluaciones. Desde el interior de la compañía se tienen privilegios superiores a los que se obtendrían desde el exterior. Aún 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 organización (como ser cortafuegos departamentales, controles de acceso de niveles de usuarios, procedimientos de autenticaciones para recursos internos, etc.). Por lo general, existen muchos más recursos si se busca dentro de una compañía, ya que la mayoría de los sistemas son internos a ella. Una vez que se encuentre fuera de la compañía, 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 penetración. Piense en una evaluación de debilidades como el primer paso de una prueba de penetración. La información obtenida en la evaluación es utilizada para la prueba. Cualesquiera sean las áreas o los lugares que el resultado de la evaluación haya sugerido verificar en búsqueda de agujeros o debilidades potenciales, serán esos mismos lugares los que la prueba de penetración intentará utilizar para aprovechar esas debilidades e ingresar al sistema.
Acceder a la infraestructura de la red es un proceso dinámico. La seguridad es dinámica, tanto la física como la de la información. Realizar una evaluación determina una visión 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 evaluación que se encuentren disponibles actualmente, ejecútelas en su sistema, y es casi una garantía que algunos resultados serán erróneos. 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 aún, la herramienta puede no encontrar debilidades que efectivamente existen (falsos negativos).
Ahora que ha sido definida la diferencia entre una evaluación de debilidades y una prueba de penetración, como parte de una mejor aplicación de los métodos, revise cuidadosamente los datos arrojados por la evaluación antes de realizar una prueba de penetración.
Advertencia
Intentar aprovechar las debilidades de los recursos de producción, puede tener efectos adversos en la productividad y eficiencia de sus sistemas y redes.
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 información
- 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 especialización del personal
- Reduce las pérdidas económicas y la publicidad negativa
1.2.2.1. Estableciendo una metodología
Para ayudar en la selección de las herramientas para realizar una evaluación de debilidades, es útil establecer un método. Desafortunadamente, por el momento no existe una metodología previamente definida, sin embargo, el sentido común y el hecho de adoptar buenas costumbres en materia de seguridad pueden actuar como una guía eficiente.
¿Cuál 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 compañía? Las respuestas a estas preguntas son importantes debido a que ayudan a determinar, no solo las herramientas que tendremos que utilizar, sino también la forma en que vamos a hacerlo.
Para aprender más acerca del establecimiento de metodologías, visite los siguientes sitios web:
- http://www.isecom.org/osstmm/ El manual de metodología de prueba de seguridad de código abierto (OSSTMM, por las iniciales en inglés 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 inglés de The Open Web Application Security Project)
1.2.3. Herramientas de evaluación
Una evaluación puede iniciarse utilizando algún tipo de herramienta que permita reunir información. Cuando se acceda a la totalidad de la red, primero haga un mapeo del diagrama para encontrar los equipos que se encuentren en ejecución. 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 más 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 también se aplica a la realización de evaluaciones de debilidades. Existen herramientas específicas 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 crípticas 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 información en Internet mayor información, como ser por ejemplo artículos, guías de tipo paso-a-paso, o incluso listas de correo de una herramienta específica.
Las herramientas detalladas a continuación son sólo un pequeño ejemplo de las que se encuentran disponibles.
1.2.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 años, y probablemente sea la herramienta más utilizada para reunir información de red. Incluye una página man excelente con información 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 realización de evaluaciones de debilidades. Puede mapear todos los equipos dentro de su red, e incluso indicar una opción que permite a Nmap intentar identificar el sistema operativo ejecutándose en un equipo determinado. Nmap es un buen fundamento sobre el que establecer una política de utilización de servicios seguros, y detener servicios no seguros.
1.2.3.1.1. Usando Nmap
Nmap puede ejecutarse desde una terminal ingresando el comando
nmap, seguido por el nombre del equipo o dirección IP de la máquina a analizar.
nmap foo.ejemplo.com
Los resultados del análisis (que puede demorarse unos minutos, de acuerdo al lugar en donde se encuentre el equipo), deberían ser similares a los siguientes:
Starting Nmap 4.68 ( http://nmap.org ) Interesting ports on foo.ejemplo.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 más 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 información acerca de la utilización de Nmap, visite la página oficial en la siguiente URL:
1.2.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 periódicamente y entre sus recursos se encuentran el de ofrecer informes completos, análisis de equipos, y búsqueda de debilidades en tiempo real. Recuerde que siempre pueden existir resultados falsos, aún en herramientas tan poderosas y tan frecuentemente actualizadas como Nessus.
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 podrían estar interesados en utilizar esta conocida herramienta.
Para obtener mayor información acerca de Nessus, visite el sitio web oficial en la siguiente URL:
1.2.3.3. Nikto
Nikto es un excelente examinador de programas de interfaz común de puerta de enlace (CGI, por las iniciales en inglés de Common Gateway Interface). Nikto no sólo verifica debilidades CGI, sino que lo hace de una forma evasiva, de modo de poder evitar sistemas de detección de intrusiones. Se ofrece con información detallada que debería ser cuidadosamente leída 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.
Más información sobre Nikto se puede encontrar en la siguiente URL:
1.2.3.4. VLAD el escáner
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 más 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 podrían estar interesados en utilizar esta conocida aplicación.
Más información sobre VLAD se puede encontrar el sitio web del equipo RAZOR en la siguiente URL:
1.2.3.5. Anticipando sus necesidades futuras
De acuerdo a sus intenciones y a sus herramientas, existen muchas otras herramientas disponibles. Estas son herramientas para redes inalámbricas, redes Novell, sistemas Windows, sistemas Linux, y más. Otro componente fundamental a la hora de realizar evaluaciones puede incluir la revisión de la seguridad física, visualización personal o evaluaciones de redes de tipo voz/PBX. Conceptos novedosos como caminata de guerra, que implica analizar el perímetro de la estructura física de su empresa en busca de debilidades en la red inalámbrica, son algunos de los conceptos recientes que podría investigar y, de ser necesario, incorporarlos a sus evaluaciones. La imaginación y la exposición son los únicos límites a la hora de planificar y llevar a cabo evaluaciones de seguridad.
1.3. 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 terminología utilizada a la hora de identificar a un atacante.
1.3.1. Una breve reseña acerca de los hackers
El significado moderno del término hacker tiene sus orígenes en la década del '60, en el Tech Model Railroad Club del Instituto de Tecnología de Massachusetts (MIT, por las siglas en inglés de Massachusetts Institute of Technology), en donde se diseñaban modelos de trenes a gran escala y con detalles muy específicos. "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 descubría algún truco útil.
Desde entonces el término "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 característica compartida entre cualquier tipo de "hacker" es la voluntad de investigar detalladamente cómo funciona un sistema de computadoras, o una red, con poca o ninguna motivación ulterior además del mero hecho de investigar. Los desarrolladores de software de código 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 código de conducta establecido en la etica del hacker, que establece que la búsqueda de información 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 búsqueda del conocimiento, algunos hackers disfrutan de los desafíos académicos que representan el hecho de sortear los controles de seguridad en los sistemas computarizados. Por este motivo, generalmente el periodismo utiliza el término hacker para referirse a quienes acceden ilegalmente y con fines criminales, malintencionados o inescrupulosos, a redes o sistemas de computación. La forma más adecuada para referirse a este tipo de hackers es atacante — un término creado por los hackers a mediados de la década del '80, para diferenciar ambas comunidades.
1.3.1.1. Zonas grises
Existen diferentes grupos dentro de la comunidad de individuos que se dedica a encontrar y utilizar con un determinado fin las diversas vulnerabilidades en sistemas y redes. Estos grupos comúnmente son descritos en función de los rastros que dejan las herramientas que utilizan para realizar sus investigaciones, rastros que al mismo tiempo sirven para poder identificar sus intenciones.
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 intrusión. Generalmente, este tipo de hackers vulnera su propio sistema, o los sistemas de algún cliente suyo que lo ha contratado específicamente con el propósito de controlar su seguridad. Investigadores académicos y consultores profesionales en el área de seguridad son ejemplos de hackers de sombrero blanco.
Un hacker de sombrero negro es sinónimo de atacante. Generalmente, los atacantes están menos interesados en la programación o en el aspecto académico 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 información valiosa en tales sistemas o redes, o para obtener un beneficio personal, o simplemente para causar daño.
Por otro lado, un hacker de sombrero gris tiene la habilidad de un hacker de sombrero blanco, y en la mayoría de los casos también sus intenciones, pero en algunas ocasiones utiliza su conocimiento para propósitos 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 ningún delito ni haga público aquello que es considerado privado. Sin embargo, alguien podría argumentar, que el acto de vulnerar un sistema es en sí mismo un acto no ético.
Sin importar la intención del intruso, es importante conocer la debilidad que un atacante puede intentar explotar. El resto del capítulo se centra en estas cuestiones.
1.3.2. Amenazas a la seguridad de la red
Malas prácticas cuando se configuran los siguientes aspectos de una red pueden aumentar el riesgo de un ataque.
1.3.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 período de tiempo, pero en algún momento, alguien va a aprovechar esa oportunidad
1.3.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 transmisión o principio de no interrupción; esto es, siempre que un nodo transmisor envíe datos sobre una red hacia un nodo receptor, el concentrador o enrutador envía una transmisión del paquete de datos hasta que el nodo receptor recibe y procesa los datos. Este método es el más vulnerable para enviar resolución de protocolo (arp) o control de acceso de contenidos (MAC), ya que esta forma de envío es accesible tanto por intrusos fuera del equipo, como por usuarios no autorizados dentro de él.
1.3.2.1.2. Servidores centralizados
Otro error posible de cometer dentro de una red, es el uso de computación centralizada. Una medida común adoptada por muchos comercios a la hora de reducir su presupuesto, es la de concentrar todos los servicios en una única máquina, relativamente poderosa. Esto puede ser conveniente ya que hace más sencillas las tareas administrativas, y el costo es económicamente 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 aún, puede hacer que los datos sean fácilmente manipulados, o directamente sustraídos. En estas situaciones, un servidor central se convierte en una puerta abierta que permite el acceso a la red en su totalidad.
1.3.3. Amenazas a la seguridad del servidor
La seguridad del servidor es tan importante como la seguridad de la red, ya que los servidores con frecuencia retienen gran parte de la información vital de una determianda organización. Si el servidor es vulnerado, todos sus contenidos pueden quedar a disposición del atacante para ser sustraídos o manipulados en su totalidad. Las secciones siguientes hacen referencia a los problemas principales.
1.3.3.1. Servicios no usados y puertos abiertos
Una instalación completa de Fedora contiene más de 1000 aplicaciones y bibliotecas de paquetes. Sin embargo, muchos administradores de servidores eligen no instalar todos los paquetes de la distribución, y prefieren en su lugar realizar una instalación de los paquetes básicos, incluyendo algunas aplicaciones de servidor.
Una actitud típica entre los administradores de servidores es la de instalar el sistema operativo sin prestar atención a los programas que efectivamente se están instalando. Esto puede llegar a ser problemático debido a que podrían instalarse servicios innecesarios, configurarse con los parámetros establecidos por defecto, y posiblemente iniciarse. Esto puede causar que servicios no queridos, como Telnet, DHCP o DNS se ejecuten en un servidor o estación de trabajo sin que el administrador lo sepa, lo que a su vez puede generar tráfico no solicitado hacia el servidor, o incluso un posible camino de acceso al sistema para los atacantes. Para obtener mayor información acerca del cierre de puertos y desconexión de servicios que no se utilicen, vea Sección 2.2, “Seguridad del servidor”.
1.3.3.2. Servicios no parchados
La mayoría de las aplicaciones de servidor que se incluyen en una instalación por defecto son piezas de software sólidas y completamente comprobadas. Habiendo sido utilizadas en entornos de producción durante muchos años, el código 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 más, por lo general el software más reciente no ha sido probado con el rigor que uno podría esperar, debido a su reciente aparición en los entornos de producción, 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 podrían ser aprovechados para vulnerar el sistema, y publican la información 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 Computación (CERT, por las iniciales en inglés 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 podrán utilizar la información para vulnerar sistemas que aún no han sido enmendados. Ser un buen administrador de sistemas implica ser vigilante, estar atento permanentemente a los errores y a sus soluciones, y ser capaz de realizar una manutención adecuada del sistema para asegurar un entorno de computación seguro.
Vaya a la Sección 1.5, “Actualizaciones de seguridad” para más información sobre cómo mantener un sistema actualizado.
1.3.3.3. Administración desatendida
Los administradores que no pueden enmendar sus sistemas son una de las mayores amenazas a la seguridad del servidor. De acuerdo con el Instituto de administradores de sistemas, auditoría, red y seguridad (SANS, por las iniciales en inglés de SysAdmin, Audit, Network, Security Institute), la principal causa de la vulnerabilidad de la seguridad en computación es "asignar personal no entrenado para encargarse de la seguridad, y no ofrecerles ni el entrenamiento ni el tiempo necesario para permitirles realizar su trabajo" [10]. Esto funciona tanto para los administradores sin experiencia, como para aquellos con excesiva confianza en sí mismos, o aquellos que no están del todo motivados en sus tareas.
Alguno administradores no pueden enmendar sus servidores o estaciones de trabajo, y otros no le prestan atención a los mensajes de registro enviados desde el kernel del sistema, o generados por el tráfico en la red. Otro error común se produce al no modificar las contraseñas o claves establecidas por defecto para los servicios. Por ejemplo, algunas bases de datos tienen contraseñas administrativas generadas por defecto, debido a que los desarrolladores de las bases de datos presuponen que el administrador del sistema las modificará inmediatamente después de haberla instalado en su sistema. Si un administrador de una base de datos no cambia la contraseña, incluso un atacante sin demasiada experiencia puede utilizar una amplia gama de contraseñas que se sabe le pueden otorgar privilegios de administrador en esa base de datos. Estos son sólo algunos ejemplos que ilustran de qué manera una administración débil puede ocasionar la vulnerabilidad de los servidores.
1.3.3.4. Servicios inseguros en sí mismos
Incluso la organización más precavida puede ser víctima de sus puntos débiles, si elige utilizar servicios de red inseguros. Por ejemplo, existen numerosos servicios desarrollados presuponiendo que serán 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 categoría de servicios de red no seguros son aquellos que en el momento de la autenticación, piden nombres de usuario y contraseñas que no estén encriptados. Telnet y FTP son dos ejemplos de este tipo de servicios. Si algún software diseñado para sustraer información se encuentre vigilando el tráfico entre el usuario remoto y un servicio con estas características, tanto los nombres de usuario como las contraseñas pueden ser interceptadas fácilmente.
En consecuencia, tales servicios pueden rápidamente fracasar gracias al ataque de lo que en la industria de la seguridad se denomina el-hombre-en-el-medio. En este tipo de ataques, el agresor redirige el tráfico de red a su máquina, simulando el nombre del servidor original hacia donde los paquetes fueron enviados. Una vez que alguien inicie una sesión remota hacia el servidor, la máquina del atacante actúa como un conducto invisible, ubicada silenciosamente entre el servicio remoto y el desprevenido usuario, capturando toda la información que este envíe. De esta manera el atacante puede recopilar contraseñas administrativas y datos crudos sin que el servidor ni el usuario puedan darse cuenta de ello.
Otra categoría de servicios no seguros incluyen sistemas de archivos de red, y servicios de información tales como NFS o NIS, que se desarrollan específicamente para una utilización LAN, pero que desafortunadamente se extienden para incluir WANs (para usuarios remotos). NFS, por defecto, no tiene configurados mecanismos ni de autenticación ni de seguridad de modo de prevenir que un atacante pueda montar la porción compartida de NFS y acceda a cualquiera sea la información que ella contenga. De manera parecida, NIS posee información vital en una base de datos con formato ASCII o DBM (derivado de ASCII), que debe ser accedida por cualquiera de los equipos en la red, incluyendo contraseñas y permisos de archivo. Un atacante que obtenga acceso a esta base de datos, tendrá acceso a cualquier cuenta de los usuario de la red, incluyendo la del administrador.
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 configuración de ellos. Para obtener mayor información acerca de cómo configurar los servicios en forma segura, vea Sección 2.2, “Seguridad del servidor”.
1.3.4. Amenazas a las estaciones de trabajo y seguridad en equipos hogareños
Las estaciones de trabajo y las PCs hogareñas no son tan propensas a los ataques como lo son los servidores o las redes, pero también son objeto de atacantes de sistemas, debido a que generalmente contienen datos importantes, como ser por ejemplo, información de tarjetas de crédito. Las estaciones de trabajo también puede ser intervenidas sin que el usuario tenga conocimiento de ello, y en el caso de un ataque coordinado, ser utilizada por los atacantes como una máquina "esclava". Por estas razones, conocer los puntos débiles de una estación de trabajo puede evitarle a los usuarios el dolor de cabeza que implica tener que instalar nuevamente el sistema operativo, o peor aún, recuperarse luego del robo de sus datos.
1.3.4.1. Malas contraseñas
Las malas contraseñas son una de las formas más fáciles para que un atacante obtenga el acceso a un sistema. Para información sobre cómo evitar los errores comunes, vaya a Sección 2.1.3, “Seguridad de contraseñas”.
1.3.4.2. Aplicaciones de tipo cliente vulnerables
Si bien un administrador puede tener un servidor completamente seguro y enmendado, esto no significa que los usuarios remotos se encuentren a salvo en el momento de acceder a él. Por ejemplo, si el servidor ofrece servicios Telnet o FTP sobre una red pública, un atacante puede capturar los nombres de usuario y contraseñas que son enviados a través de la red con un formato de texto simple, y luego utilizar la información de la cuenta para poder ingresar en la estación de trabajo del usuario remoto.
Aún 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 reenvío de X que provenga de servidores maliciosos. Una vez conectado al servidor, el atacante puede capturar silenciosamente cualquier presión de teclas o pulsación del ratón 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 débiles, y actualizarlas cuando sea necesario.
Sección 2.1, “Seguridad de la estación de trabajo” discute más en detalle los pasos que los administradores y usuarios hogareños deben tomar para limitar la vulnerabilidad de las computadoras estaciones de trabajo.
1.4. Ataques y debilidades comunes
Tabla 1.1, “Debilidades comunes” : detalles acerca de las debilidades y los puntos de ingreso más utilizados por intrusos, que pretenden acceder a los recursos de diferentes redes. La clave para defender estos puntos son las explicaciones acerca de cómo se desarrollan, y cómo los administradores pueden salvaguardar adecuadamente sus redes contra tales ataques.
| Debilidades | Descripción | Notas | |||
|---|---|---|---|---|---|
| Contraseñas nulas o predeterminadas | Dejando las contraseñas administrativas en blanco o el uso de una contraseña predeterminada puesta por el vendedor. Esto es lo más común en hardware como ruteadores y cortafuegos, por lo que algunos servicios que corren en Linux pueden contener contraseñas administrativas predeterminadas (aunque Fedora 11 no viene con ellas). |
| |||
| 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 desempeño. Si estas claves se mantienen inalteradas y se colocan en un entorno de producción en Internet todos los usuarios con las misma sclaves establecidas por defecto tendrán acceso a ese recurso de clave compartida, y a cualquier tipo de información que en él se guarde. |
| |||
| Imitación de IP | Una máquina remota actúa 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. |
| |||
| Escuchas | La escucha se realiza para la recolección de datos que pasan entre dos nodos activos en una red. |
| |||
| Debilidades de servicios | Un atacante encuentra una brecha o hueco en un servicio que corre a través de Internet; a través de esta vulnerabilidad, el atacante compromete el sistema entero y cualquier dato que pueda contener, y puede posiblemente comprometer otros sistemas en la red. |
| |||
| Debilidades de aplicaciones | Los atacantes encuentran fallas en las aplicaciones de un equipo de escritorio o de una estación de trabajo (como ser por ejemplo un cliente de correo electrónico), y ejecutan un código cualquiera, colocan caballos troyanos para futuros daños, o simplemente destruyen el sistema. Pueden ocurrir futuras catástrofes si la estación de trabajo vulnerada posee privilegios administrativos sobre el resto de la red. |
| |||
| Ataques de Negación de Servicio (DoS) | Un atacante, o un grupo de atacantes coordinados contra la red o los recursos de red de alguna organización, enviando paquetes no autorizados al equipo elegido (ya sea un servidor, un enrutador o una estación de trabajo). Esto obliga al recurso atacado a quedar inhabilitado para ser utilizado por los usuarios legítimos. |
|
Tabla 1.1. Debilidades comunes
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 distribución Fedora entonces soportada, Fedora está comprometida a liberar lo antes posible las actualizaciones necesarias para solucionar las deficiencias del paquete en cuestión. A menudo, los anuncios sobre alguna imperfección en algún aspecto de la seguridad son acompañados de un parche (o código fuente que solucione el problema). Este parche es entonces aplicado al paquete de Fedora, probado y liberado como una actualización considerada de tipo errata. Sin embargo, si algún 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 actualización de tipo errata.
Si se lanza una errata de actualización 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. Actualización de paquetes
Cuando se actualiza el software de un sistema, es importante descargar la actualización desde una fuente confiable. Un atacante fácilmente puede recompilar un paquete con el mismo número de versión que el que supuestamente debería 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 actualización disponible para el sistema.
1.5.2. Verificación de paquetes firmados
Todos los paquetes de Fedora están 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 pública desbloquea y verifica el paquete. Si la clave pública distribuida por Fedora no coincide con la clave privada durante la verificación del RPM, el paquete puede haber sido alterado y por lo tanto no es confiable.
La utilidad RPM de Fedora intenta verificar automáticamente la firma GPG de un paquete RPM antes de instalarlo. Si la clave GPG no está instalada, se debe instalar desde una ubicación estática y segura, como el CD-ROM o DVD de instalación 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 verificación de RPM, ejecute el siguiente comando:
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, si la clave GPG se verifica exitosamente, el comando devuelve
gpg OK. Sino, asegúrese que está usando la clave pública de Fedora correcta, así como la fuente del contenido. Los paquetes que no pasan las verificaciones GPG no se deben instalar, porque pueden haber sido alterados por alguien.
Después 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. Instalación de paquetes firmados
La instalación de la mayoría 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/<paquete-de-kernel>
Reemplace
<paquete-del-kernel> en el ejemplo previo con el nombre del RPM del kernel.
Una vez que la máquina ha sido iniciada sin problema usando el nuevo kernel, el kernel viejo se puede eliminar usando el siguiente comando:
rpm -e <paquete-del-kernel-viejo>
Reemplace el
<paquete-del-kernel-viejo> en el ejemplo previo con el nombre del RPM del kernel viejo.
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.
Importante
Antes de instalar cualquier errata de seguridad, asegúrese de leer las instrucciones especiales contenidas en el informe de errata y ejecútelas apropiadamente. Vaya a la Sección 1.5.4, “Aplicación de los cambios” para instrucciones generales sobre la aplicación de cambios hechos por una actualización de errata.
1.5.4. Aplicación de los cambios
Después de descargar e instalar las erratas de seguridad y actualizaciones, es importante dejar de usar el software viejo y comenzar a usar el nuevo. Cómo se hace esto depende del tipo de software que se haya actualizado. La siguiente lista muestran los items de la categoría general de software y provee instrucciones para usar las versiones actualizadas después de cada actualización de paquetes.
Nota
En general, reiniciar el sistema es la mejor forma de asegurarse que la última versión de un paquete de software esté en uso; sin embargo, esta opción no es siempre necesaria, o está disponible sólo para el administrador del sistema.
- Aplicaciones
- Las aplicaciones del espacio del usuario son todos los programas que se pueden usar por el usuario común. Típicamente, tales aplicaciones se usan solamente cuando un usuario, programa o tarea automatizada los inicia, y no están activas por períodos largos de tiempo.Una vez que la aplicación del espacio del usuario es actualizado, detenga cualquier instancia de la aplicación en el sistema y lance el programa de nuevo para usar la versión 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 periféricos, así como la planificación de todas las tareas.Dado a su rol central, el kernel no se puede reiniciar sin detener la computadora. Por lo tanto, una versión actualizada del kernel no se puede usar hasta que la computadora no sea reiniciada.
- Bibliotecas compartidas
- Las bibliotecas compartidas son unidades de códigos, como
glibc, que se usan por un número de aplicaciones y servicios. Las aplicaciones que usan una biblioteca compartida normalmente cargan el código compartido cuando la aplicación se inicia, por lo que todas las aplicaciones que usen la versión actualizada de la biblioteca se deben detener y reiniciar.Para determinar qué aplicaciones en ejecución usan una biblioteca particular, use el comandolsofcomo en el siguiente ejemplo:lsof /lib/libwrap.so*Este comando devuelve una lista con todos los programas en ejecución que utilizan encapsuladores TCP para control de acceso del equipo. Por lo tanto, cualquier programa listado debe ser detenido y reiniciado si el paquetetcp_wrapperses actualizado. - Servicios SysV
- Los servicios SysV son programas de servidor persistentes lanzados en algún momento del proceso de inicialización del equipo. Algunos ejemplos de servicios SysV son
sshd,vsftpd, yxinetd.Debido a que estos programas generalmente continúan 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 configuración de servicios, o logueandose como usuario root en una consola y ejecutando el comando/sbin/servicecomo en el ejemplo siguiente:/sbin/service<nombre-servicio>restartEn el ejemplo anterior, reemplace<service-name>con el nombre del servicio, como ser por ejemplo,sshd. - Servicios
xinetd - Los servicios controlados por el súper servicio
xinetdsolo se ejecutan cuando exista una conexión activa. Ejemplos de servicios controlados porxinetdosn Telnet, IMAP, y POP3.Debido a quexinetdinicia nuevas instancias de estos servicios cada vez que se reciba un nuevo pedido, las conexiones que tengan lugar luego de una actualización serán administradas por el software actualizado. Sin embargo, si existen conexiones activas en el momento en que el servicio controlado porxinetdes actualizado, estas conexiones seguirán funcionando controladas por la versión anterior.Para detener instancias antiguas de un servicio particular controlado porxinetd, actualice el paquete para el servicio, y luego detenga todos los procesos que se encuentren en ejecución. Para determinar si el proceso está ejecutándose, utilice el comandopsy luego los comandoskillokillallpara detener las instancias actuales del servicio.Por ejemplo, si los paquetes errata de seguridadimapson liberados, actualice los paquetes, y luego, como usuario root, ingrese el siguiente comando en una terminal:ps -aux | grep imapEste comando devuelve todas las sesiones IMAP activas. Las sesiones individuales pueden determinarse con el siguiente comando:kill<PID>Si esto falla a terminar la sesión, use el siguiente comando en su lugar:kill -9<PID>En los ejemplos anteriores, para una sesión IMAP reemplace<PID>con el número de identificación del proceso (que puede encontrarlo en la segunda columna del comandops).Para detener todas las sesiones IMAP activas, ingrese el siguiente comando:killall imapd
[1] http://law.jrank.org/pages/3791/Kevin-Mitnick-Case-1999.html
[2] http://www.livinginternet.com/i/ia_hackers_levin.htm
[3] http://www.theregister.co.uk/2007/05/04/txj_nonfeasance/
[4] http://www.healthcareitnews.com/story.cms?id=9408
[5] http://www.internetworldstats.com/stats.htm
[6] http://www.cert.org
[7] http://www.cert.org/stats/fullstats.html
[8] http://www.newsfactor.com/perl/story/16407.html
[9] http://www.csoonline.com/article/454939/The_Global_State_of_Information_Security_
[10] http://www.sans.org/resources/errors.php
Capítulo 2. Asegurando su Red
- 2.1. Seguridad de la estación de trabajo
- 2.2. Seguridad del servidor
- 2.3. Identificación única (SSO, por las iniciales en inglés de Single Sign-on)
- 2.4. Módulos de autenticación conectables (PAM, por las iniciales en inglés de Pluggable Authentication Modules)
- 2.4.1. Ventajas de PAM
- 2.4.2. Archivos de configuración de PAM
- 2.4.3. Formato del archivo de configuración de PAM
- 2.4.4. Ejemplos de archivos de configuración de PAM
- 2.4.5. Creación de los módulos PAM
- 2.4.6. PAM y el cacheo de la credencial administrativa
- 2.4.7. PAM y la propiedad de los dispositivos
- 2.4.8. Recursos adicionales
- 2.5. Encapsuladores TCP y xinetd
- 2.6. Kerberos
- 2.6.1. ¿Qué es Kerberos?
- 2.6.2. Terminología de Kerberos
- 2.6.3. Como Funciona Kerberos
- 2.6.4. Kerberos y PAM
- 2.6.5. Configurando un servidor Kerberos 5
- 2.6.6. Configuración de un Cliente Kerberos 5
- 2.6.7. Mapeo dominio-a-reinado
- 2.6.8. Configurando KDCs secundarios
- 2.6.9. Configurando la autenticación cruzada de reinados
- 2.6.10. Recursos adicionales
- 2.7. Redes privadas virtuales (VPNs, por las iniciales en inglés de Virtual Private Networks)
- 2.8. Cortafuegos
- 2.9. IPTables
2.1. Seguridad de la estación de trabajo
Asegurar un entorno Linux comienza con la estación de trabajo. Ya sea bloqueando una máquina personal, o asegurando un sistema corporativo, cualquier política de seguridad empieza con la computadora individual. La seguridad de una red de computadoras es la misma que la de su nodo más débil.
2.1.1. Evaluación de la seguridad de la estación de trabajo
Cuando se evalúa la seguridad de una estación de trabajo Fedora, considere los siguientes aspectos:
- Seguridad del BIOS y del gestor de arranque — ¿Puede un usuario no autorizado tener acceso a la máquina e iniciarla como usuario único, o en modo de rescate, sin ninguna contraseña?
- Seguridad de la contraseña — ¿Qué tan seguras son las contraseñas de usuario en la máquina?
- Controles administrativos — ¿Quién posee una cuenta en el sistema y cuánto control administrativo posee?
- Servicios de red disponibles — ¿Qué servicios están escuchando peticiones activas de la red? ¿Deberían estar ejecutándose?
- Cortafuegos personals — En caso de necesitarse alguno, ¿qué tipo de cortafuegos son necesarios?
- Herramientas de seguridad en la comunicación mejoradas — ¿Qué herramientas deberían utilizarse para comunicarse entre estaciones de trabajo, y cuáles deberían evitarse?
2.1.2. Seguridad en el BIOS y en el gestor de arranque
Una protección del BIOS (o de su equivalente) y del gestor de arranque mediante una contraseña, puede prevenir que el sistema sea iniciado mediante la utilización de medios removibles, o que se obtengan privilegios de usuario root, por cualquier usuario no autorizado que tenga acceso físico al él. Las medidas de seguridad que debería adoptar para protegerse de este tipo de ataques depende tanto de la calidad de la información de la estación de trabajo, como de la ubicación de la máquina.
Por ejemplo, si una máquina es utilizada en algún tipo de evento, y no contiene ninguna clase de información importante, entonces no sería prioritario prevenir tales ataques. Sin embargo, si la laptop de algún empleado con claves SSH privadas y no encriptadas de la red de la compañía es descuidada en el mismo evento anterior, podría permitir una falla importante en la seguridad, con consecuencias para la compañía entera.
Por otro lado, si la estación de trabajo se encuentra ubicada en un lugar al cuál tienen acceso solo personas autorizadas o de confianza, en ese caso asegurar el BIOS o el gestor de arranque podría no ser necesario.
2.1.2.1. Contraseña BIOS
Las dos razones fundamentales para proteger con una contraseña el BIOS de una computadora son [11]:
- Evitar modificaciones a la configuración 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 ingresar en modo rescate o en modo de único usuario, lo que a su vez permite que inicie procesos a elección en el sistema, o que pueda copiar información importante.
- Evitar el inicio del sistema — Algunas BIOS permiten protección mediante contraseñas del proceso de arranque. Cuando es activado, el atacante se ve obligado a ingresar una contraseña antes que el BIOS ejecute el gestor de arranque.
Debido a que los métodos para establecer una contraseña de BIOS son diferentes de acuerdo a cada fabricante, consulte el manual de la computadora para instrucciones específicas.
Si no recuerda la contraseña del BIOS, puede ser reseteada o bien mediante jumpers en la placa madre, o bien desconectando la batería del CMOS. Por esta razón, 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 batería del CMOS.
2.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 inglés de Extensible Firmware Interface).
Para instrucciones acerca de la protección mediante contraseñas de programas similares al BIOS, consulte las instrucciones del fabricante.
2.1.2.2. Contraseñas del gestor de arranque
Las principales razones por las que proteger un gestor de arranque de Linux son las siguientes:
- Prevenir el ingreso en modo de único usuario — Si los atacantes pueden iniciar el sistema en modo de usuario único, automáticamente se registran como usuarios root sin que para ello se les solicite una contraseña de usuario root.
- Prevenir el acceso a la consola del GRUB — Si la máquina en cuestión 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 información utilizando el comando
cat. - Prevenir el acceso a sistemas operativos no seguros — Si el sistema en cuestión 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 exposición detallada del GRUB, consulte la Guía de Instalación de Fedora.
2.1.2.2.1. Protección de GRUB con contraseña
Puede configurar el GRUB para prevenir los dos primeros problemas descritos en la Sección 2.1.2.2, “Contraseñas del gestor de arranque”, añadiendo una directiva de contraseña a su archivo de configuración. Para hacerlo, primero elija una contraseña poderosa, abra una terminal, regístrese como usuario root, e ingrese el siguiente comando:
/sbin/grub-md5-crypt
Cuando se le solicite, ingrese la contraseña del GRUB y presione la tecla Intro. Con esto obtendrá un hash MD5 de la contraseña.
A continuación, edite el archivo de configuración del GRUB
/boot/grub/grub.conf. Abra el archivo y debajo de la línea timeout en la sección principal del documento, añada la siguiente:
password --md5 <hash-de-contraseña>
La próxima 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 contraseña del GRUB
Desafortunadamente, esta solución 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 línea
title del sistema operativo que desea asegurar, y añada otra línea con la directiva lock inmediatamente debajo de ella.
Para un sistema DOS, el bloque de líneas pertinente debería empezar de manera similar a la siguiente:
title DOS lock
Advertencia
Una línea
password debe estar presente en la sección principal del archivo /boot/grub/grub.conf para el correcto funcionamiento de este método. De lo contrario, un atacante puede acceder a la interfaz del editor del GRUB y eliminar la línea de bloqueo.
Para crear una contraseña diferente para un kernel particular o sistema operativo, añada la línea
lock a las presentes seguida de una línea de contraseña.
Cada porción de líneas protegidas con una contraseña única deberían empezar de manera similar al siguiente ejemplo:
title DOS lock password --md5 <password-hash>
2.1.3. Seguridad de contraseñas
Las contraseñas son el método primario que Fedora utiliza para verificar la identidad de los usuarios. Este es el motivo por el que la seguridad de la contraseña es tan importante para la protección del usuario, la estación de trabajo y la red.
Por motivos de seguridad, el programa de instalación configura el sistema para utilizar Message-Digest Algorithm (MD5) y ocultar las contraseñas. Es muy recomendable que no modifique estas configuraciones.
Si las contraseñas MD5 son deseleccionadas durante la instalación, el antiguo formato Data Encryption Standard (DES) es utilizado. Este formato limita las contraseña a ocho caracteres alfanuméricos (deshabilitando los signos de puntuación y otros caracteres especiales), y proveyendo un modesto nivel de encriptado de 56 bits.
Si durante la instalación se deselecciona el ocultamiento de contraseñas, todas las contraseñas son almacenadas en un hash unidireccional en el archivo de lectura pública
/etc/passwd, lo que hace que el sistema sea vulnerable a los ataques de descubrimiento de contraseñas fuera de línea. Si un intruso puede obtener acceso a la máquina como un usuario regular, puede copiar el archivo /etc/passwd a su propio equipo, y ejecutar cualquier cantidad de programas de descubrimiento de contraseñas sobre él. Si existe una contraseña no segura en el archivo, es sólo cuestión de tiempo antes que el atacante la encuentre.
El ocultamiento de contraseñas elimina este tipo de ataques almacenando el hash de contraseña en el archivo
/etc/shadow, que solo puede ser leído por el usuario root.
Esto obliga a los potenciales atacantes a intentar descubrir las contraseñas remotamente, registrándose en un servicio de red en la máquina, como por ejemplo SSH o FTP. Esta clase de ataque de tipo fuerza bruta es mucho más 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 contraseñas débiles, podría obtener acceso antes del amanecer y editar los archivos de registro para eliminar sus huellas.
Además 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 contraseña, es crear una contraseña poderosa.
2.1.3.1. Creando contraseñas poderosas
Para crear una contraseña segura, es una buena idea seguir las siguientes indicaciones:
- No utilice solo palabras o números — Nunca utilice solo números o palabras en contraseñas.Algunos ejemplos inseguros incluyen los siguientes:
- 8675309
- juan
- hackeame
- No use palabras reconocibles — Palabras como nombres propios, palabras de diccionario, o incluso términos de shows de televisión, o de novelas, deberían ser evitados. Aún si están complementadas con números.Algunos ejemplos inseguros incluyen los siguientes:
- martin1
- DS-9
- tevez123
- No utilice palabras de otros idiomas — Los programas de descubrimiento de contraseñas a menudo verifican sobre listas de palabras que incluyen diccionarios de muchos idiomas. Confiar en idiomas extranjeros para establecer contraseñas seguras, no es algo aconsejable.Algunos ejemplos inseguros incluyen los siguientes:
- cheguevara
- bienvenido1
- 1dumbKopf
- No utilice terminología hacker — Si usted piensa que es intocable porque utiliza terminología hacker — también denominada lengua l337 (LEET) — en su contraseña, piénselo dos veces, Muchas listas de palabras incluyen lengua LEET.Algunos ejemplos inseguros incluyen los siguientes:
- H4X0R
- 1337
- No use Información Personal — Evite usar cualquier tipo de información personal en sus contraseñas. Si el atacante conoce su identidad, la tarea de deducir su contraseña se vuelve más fácil. La siguiente es una lista de los tipos de información a evitar cuando se crea una contraseña:Algunos ejemplos inseguros incluyen los siguientes:
- Su nombre
- El nombre de su mascota
- El nombre de un miembro de la familia
- Cualquier fecha de cumpleaños
- Su número de teléfono o su código postal
- No invierta palabras reconocibles — Los buenos verificadores de contraseña siempre invierten palabras comunes, por lo que la inversión de un mala contraseña no la hace más segura.Algunos ejemplos inseguros incluyen los siguientes:
- R0X4H
- nauj
- 9-DS
- No escriba su contraseña — Nunca guarde su contraseña en papel. Es más seguro memorizarla.
- No use la misma contraseña para todas las computadoras — es importante crear contraseñas distintas para cada máquina. De esta forma, si un sistema está comprometido, todas sus computadoras no estarán inmediatamente en riesgo.
Los siguientes consejos le ayudarán a crear una contraseña fuerte:
- La contraseña debe tener al menos 8 caracteres de largo — Cuanto más larga la contraseña, mejor. Si usa contraseñas MD5, deben ser de 15 caracteres o más. Con contraseñas DES, use la longitud máxima (ocho caracteres).
- Mezcle letras en mayúsculas y minúsculas — Fedora diferencia entre mayúsculas y minúsculas, por lo que su mezcla mejora la fortaleza de la contraseña.
- Mezcle letras con números — Agregar números a la contraseña mejora la fortaleza de la misma, especialmente cuando se los agrega en el medio (no al principio ni al final).
- Incluya caracteres no alfanuméricos — Caracteres especiales como &, $, y > pueden mejorar mucho la fortaleza de la contraseña (esto no es posible cuando se utilicen contraseñas DES).
- Elija una contraseña que pueda recordar — La mejor contraseña del mundo no mejora nada si no la puede recordar; use siglas u otros dispositivos memotécnicos para ayudarle a recordar las contraseñas.
Con todas estas reglas, puede parecer difícil crear una contraseña que cumpla al mismo tiempo con todos los criterios pedidos para una buena contraseña, y que evite la creación de una mala. Afortunadamente, hay algunos pasos que se pueden tomar para generar una contraseña segura y fácil de recordar.
2.1.3.1.1. Metodología para la creación de una contraseña segura
Hay muchos métodos que se pueden usar para crear contraseñas seguras. Uno de los más populares involucra las siglas. Por ejemplo:
- Piense en una frase fácil de recordar, tal como:"por el río y a través del bosque, vamos a la casa de la abuela."
- Luego, conviértala en una sigla (incluyendo la puntuación).
peryatdb,valcdla. - Agregue complejidad sustituyendo números y símbolos por letras en la sigla. Por ejemplo, sustituya
7portel arroba (@) pora:pery@7db,v@lcdl@. - Agregue más complejidad poniendo en mayúsculas al menos una letra, tal como la
B.pery@7dB,v@lcdl@. - Finalmente, no use nunca la contraseña ejemplo anterior para ningún sistema.
La creación de contraseñas seguras es imperativo, y su apropiada administración es igual de importante, especialmente para administradores de sistemas dentro de organizaciones grandes. La siguiente sección detalla las buenas prácticas para crear y administrar las contraseñas de los usuarios dentro de una organización.
2.1.3.2. Creación de contraseñas de usuarios dentro de una organización
Si una organización tiene un gran número de usuarios, los administradores de sistema tienen dos opciones básicas disponibles para obligar al uso de contraseñas buenas. Pueden crear contraseñas para los usuarios, o permitirles crear sus propias contraseñas, pero verificando que sean de una calidad aceptable.
La creación de contraseñas para usuarios asegura que las contraseñas sean buenas, pero se vuelve una tarea intimidante a medida que la organización crece. También aumenta el riesgo de que los usuarios escriban sus contraseñas.
Por estas razones, la mayoría de los administradores de sistema prefieren que sus usuarios creen sus propias contraseñas, pero verificar activamente que sean buenas y, en algunos casos, forzarlos a cambiarlas periódicamente mediante el establecimiento de un período determinado de validez.
2.1.3.2.1. Obligando a usar contraseñas poderosas
Para proteger la red de intrusos, es una buena idea que los administradores del sistema comprueben que las contraseñas utilizadas dentro de una organización sean buenas y potentes. Cuando se les pida a los usuarios crear o modificar una contraseña, pueden utilizar la herramienta de línea de comando
passwd, que es compatible con el Administrador de módulos de autenticación conectables (PAM, por las iniciales en inglés de Pluggable Authentication Manager), y por lo tanto verifica si la contraseña es demasiado corta o demasaido fácil de descubrir. Esta comprobación es realizada utilizando el módulo PAM pam_cracklib.so. Ya que PAM es personalizable, es posible añadir más verificadores de la integridad de las contraseñas, como ser por ejemplo, pam_passwdqc (disponible en http://www.openwall.com/passwdqc/), o escribir un módulo nuevo. Para conocer una lista de módulos PAM disponibles, vea http://www.kernel.org/pub/linux/libs/pam/modules.html. Para obtener mayor información acerca de PAM, vaya a la Sección 2.4, “Módulos de autenticación conectables (PAM, por las iniciales en inglés de Pluggable Authentication Modules)”.
La verificación de la contraseña que se realiza al momento de su creación, no permite saber con tanta certeza si una contraseña es débil, cosa que sí se puede verificar exactamente con la ejecución sobre ellas de un programa de descubrimiento de contraseñas.
Muchos programas de descubrimiento de contraseñas están disponibles para ejecutarse en Fedora, aunque ninguno viene con el sistema operativo. A continuación ofrecemos una pequeña lista con algunos de los programas de descubrimiento de contraseñas más populares:
- John The Ripper — Un programa de descubrimiento de contraseña rápido y flexible. Permite el uso de múltiples listas de palabras y puede descubrir contraseñas por fuerza bruta. Está disponible en línea en http://www.openwall.com/john/.
- Crack — Tal vez el software de descubrimiento de contraseñas más conocido, Crack es también muy rápido, aunque no tan fácil de usar como John The Ripper. Se lo puede encontrar en línea 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 contraseñas distribuido. Se puede encontrar junto con un número de otras herramientas de evaluación de seguridad al ataque distribuído, en línea en http://www.ussrback.com/distributed.htm.
Advertencia
Siempre obtenga una autorización por escrito antes de intentar descubrir contraseñas dentro de una organización
2.1.3.2.2. Frases de acceso
Las frases de acceso y las contraseñas son la piedra angular de la seguridad en la mayoría de los sistemas de hoy. Desafortunadamente, las técnicas como la biometría y la autenticación de tipo dos-factores no se han vuelto principales en la mayoría de los sistemas, algo que se convirtió en un problema fundamental. Si las contraseñas van a ser utilizadas para asegurar un sistema, entonces el uso de frases de acceso debe ser considerado. Las frases de acceso son más largas que las contraseñas y proveen una mejor protección, aún cuando se implementan con caracteres no estándares como los números y los símbolos.
2.1.3.2.3. Edad de las contraseñas
El envejecimiento de las claves es otra técnica usada por los administradores del sistema para defenderlo de malas contraseñas dentro de una organización. El envejecimiento de la contraseña significa que después de un período especificado (normalmente 90 días), el usuario debe crear una nueva contraseña. La idea detrás de este método es que si el usuario es forzado a cambiar su contraseña periódicamente, una contraseña descubierta sería útil para un intruso por un tiempo limitado. La contra del envejecimiento es que los usuarios, seguramente, anotarán en un papel sus contraseñas.
Hay dos programas principales usados para especificar el envejecimiento de contraseñas bajo Fedora: el comando
chage o la aplicación gráfica Administración -> Usuarios y Grupos (system-config-users).
La opción
-M del comando chage especifica el número máximo de días en los cuales será válida la contraseña. Por ejemplo, para poner la contraseña del usuario para que venza en 90 días, use el siguiente comando:
chage -M 90 <nombre-de-usuario>
En el comando de arriba, reemplace
<nombre-de-usuario> con el nombre del usuario. Para deshabilitar el vencimiento de la contraseña, es tradicional usar el valor 99999 espués de la opción -M (esto es cerca de 273 años).
También puede usar el comando
chage en modo interactivo para modificar el envejecimiento de varias contraseñas y detalles de cuenta. Use el siguiente comando para ingresar en modo interactivo:
chage <nombre-de-usuario>
El siguiente es un ejemplo de la sesión interactiva usando este comando:
[root@interch-dev1 ~]# chage davido Cambiando la información de envejecimiento de davido Ingrese el valor nuevo o presione INTRO para el predeterminado Edad Mínima de la Contraseeña [0]: 10 Edad Máxima de la Contraseña [99999]: 90 Último Cambio de la Contraseña (YYYY-MM-DD) [2009-08-18]: Advertencia de Vencimiento de la Contraseña [7]: Contraseña Inactiva [-1]: Fecha de Vencimiento de la Cuenta (YYYY-MM-DD) [1969-12-31]: [root@interch-dev1 ~]#
Vaya a la página man de chage para más información sobre las opciones disponibles.
También se puede usar la aplicación Usuarios y Grupos para crear políticas de envejecimiento de contraseñas, como sigue. Nota: necesita los privilegios de administrador para realizar este procedimiento.
- Haga clic en el menú en el panel, apunte al menú y luego haga clic en para mostrar el Aministrador de Usuarios. Alternativamente, teclee el comando
system-config-usersen un indicador de shell. - Haga clic en la pestaña Usuarios y seleccione el usuario requerido de la lista de usuarios.
- Haga clic en en la barra de herramientas para mostrar el cuadro de diálogo de las Propiedades del Usuario (o elija en el menú ).
- Haga clic en la pestaña Información de la Contraseña, y seleccione la casilla de Activar expiración de contraseña.
- Ingrese el valor requerido en el campo Días requeridos antes de cambiar y haga clic en .
Ilustración del panel Información de la Contraseña.
Figura 2.1. Especificación de las opciones de edad de las contraseñas
2.1.4. Controles administrativos
Cuando se administra una máquina personal, el usuario debe realizar algunas tareas como usuario root, o mediante la adquisisción de privilegios de usuario root, a través de un programa de tipo setuid, como lo son por ejemplo
sudo o su. Se denomina un programa de tipo setuid a aquel que opera con el ID de usuario (UID) del dueño del programa, en lugar del ID de usuario de quien sea que esté utilizando el programa. Tales programas son identificados con una s en la sección de pertenencia del listado de formato extenso, como se muestra en el siguiente ejemplo:
-rwsr-xr-x 1 root root 47324 May 1 08:09 /bin/su
Nota
La
s puede figurar en mayúscula o en minúscula. Si aparece en mayúscula, significa que el bit de los permisos subyacentes no ha sido definido.
Sin embargo, para el administrador del sistema de una organización, las elecciones deben ser realizadas tomando en cuenta el tipo de acceso adminsitrativo que los usuarios dentro de la organización deberían tener a su máquina. A través del módulo 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 física (para obtener mayor información acerca del módulo pam_console.so, vaya a la Sección 2.4, “Módulos de autenticación conectables (PAM, por las iniciales en inglés de Pluggable Authentication Modules)”. Sin embargo, otras tareas importantes en el sistema, como ser modificar parámetros de red, configurar un nuevo ratón, o montar dispositivos de red, no será posible realizarlas sin privilegios administrativos. Como resultado, los administradores del sistema deben decidir cuánto acceso deben otorgarle a los usuarios de la red.
2.1.4.1. Permitiendo accesos root
Si los usuarios de una organización son confiables y conocen acerca de computadoras, permitirles acceso root no debería ser un problema. Esto significa que actividades menores, como añadir dispositivos o configurar interfases de red podrían ser realizadas por los usuarios individuales, quedando los administradores del sistema liberados y poder realizar tareas más importantes relacionadas, por ejemplo, con la red o con la seguridad.
Por otro lado, darle accesos de root a usuarios individuales podría generar los siguientes inconvenientes:
- Configuración errónea del equipo — Los usuarios con acceso root pueden desconfigurar sus máquinas y necesitar asistencia para resolver problemas. O peor aún, podrían abrir agujeros en la seguridad del sistema sin saberlo.
- Ejecutar servicios no seguros — Usuarios con acceso root podrían ejecutar servidores no seguros en su máquina, como por ejemplo Telnet o FTP, poniendo en riesgo en forma potencial nombres de usuarios o contraseñas. Estos servicios transmiten la información sobre la red en formato de texto simple.
- Ejecutar archivos adjuntos de correos como usuarios root — Si bien son excepcionales, existen virus de correo electrónico 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.
2.1.4.2. Anulación del acceso como root
Si un administrador no se encuentra cómodo al permitir que los usuarios se registren como usuarios root por estas razones, o por otras, la contraseña de usuario root debería ser mantenida en secreto, y el acceso al nivel de ejecución 1, o al modo de usuario único, debería ser desactivado mediante una protección del gestor de arranque a través de una contraseña (para obtener mayor información en este aspecto, vea la Sección 2.1.2.2, “Contraseñas del gestor de arranque”).
Tabla 2.1, “Métodos para deshabilitar la cuenta root” : describe las formas en que un administrador puede asegurarse que no sean permitidos los ingresos como root:
| Método | Descripción | Efectos | No afecta | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Cambio del shell para root. |
Edite el archivo /etc/passwd y cambie la terminal de /bin/bash a /sbin/nologin.
|
|
| |||||||||||||||
| Deshabilitar el acceso root mediante cualquier dispositivo de consola (tty) |
Un archivo /etc/securetty vacío previene los intentos de accesos root a cualquier dispositivo asociado con la computadora.
|
|
| |||||||||||||||
| Deshabilitación de las opciones de ingreso como root por SSH. |
Edite el archivo /etc/ssh/sshd_config y establezca el parámetro PermitRootLogin en no.
|
|
| |||||||||||||||
| Utilice PAM para limitar el acceso root a los servicios. |
Edite el archivo para el servicio en cuestión en el directorio /etc/pam.d/. Asegúrese que el archivo pam_listfile.so sea requerido para autenticación.[a]
|
|
| |||||||||||||||
[a] Para concer más detalles, vea la Sección 2.1.4.2.4, “Deshabilitando root usando PAM”. | ||||||||||||||||||
Tabla 2.1. Métodos para deshabilitar la cuenta root
2.1.4.2.1. Deshabilitando la cuenta shell de root
Para prevenir que los usuarios se resgistren directamente como usuarios root, el administrador del sistema puede establecer la consola de la cuenta de root como
/sbin/nologin en el archivo /etc/passwd. Esto previene el acceso a la cuenta root mediante comandos que necesiten una terminal, como por ejemplo el comando su y los comandos ssh.
Importante
Los programas que no necesitan acceso a la consola, como son por ejemplo los clientes de correo electrónico, o el comando
sudo, pueden todavía tener acceso a la cuenta root.
2.1.4.2.2. Deshabilitando conexiones como root
Para en el futuro limitar el acceso a la cuenta root, los administradores pueden deshabilitar la posibilidad de registrarse como usuarios root editando el archivo
/etc/securetty. Este archivo muestra todos los dispositivos a los que el usuario root puede registrarse. Si el archivo no existiese, el usuario root puede registrarse a través de cualquier dispositivo de comunicación en el sistema, ya sea mediante la utilización de la consola, o mediante una interfaz de red. Esto es peligroso ya que un usuario puede registrarse en su máquina como usuario root mediante Telnet, que transmite en la red la contraseña en formato de texto simple. Por defecto, el archivo /etc/securetty de Fedora sólo permite que el usuario root se registre en la consola asociada físicamente en la máquina. Para prevenir al usuario root que se registre, elimine los contenidos de este archivo con la utilización del siguiente comando:
echo > /etc/securetty
Advertencia
Un archivo
/etc/securetty vacío 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 autenticación.
2.1.4.2.3. Deshabilitando conexiones SSH como root
Los ingresos root mediante el protocolo SSH están deshabilitados por defecto en Fedora; sin embargo, si esta opción ha sido activada, puede deshabilitarse nuevamente editando el archivo de configuración del demonio SSH (
/etc/ssh/sshd_config). Cambie la línea en la que se lee:
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`
2.1.4.2.4. Deshabilitando root usando PAM
PAM, a través del módulo
/lib/security/pam_listfile.so, permite gran flexibilidad a la hora de denegar cuentas específicas. El administrador puede utilizar este módulo para hacer referencia a una lista de usuarios que no tienen permitido registrarse. Más abajo mostramos un ejemplo acerca de cómo el módulo es utilizado por el servidor FTP vsftpd en el archivo de configuración de PAM /etc/pam.d/vsftpd (el caracter \ al final de la primera línea en el ejemplo no es necesario si la directiva se encuentra en una sola línea):
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 múltiples servicios.
Si el administrador quiere negar el acceso a múltiples servicios, una línea similar puede ser añadida a los archivos de configuración 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 información acerca de PAM, vea la Sección 2.4, “Módulos de autenticación conectables (PAM, por las iniciales en inglés de Pluggable Authentication Modules)”.
2.1.4.3. Limitando acceso como root
En lugar de negarle acceso completamente al usuario root, el admisnitrador podría querer permitirle el acceso sólo mediante la utilización de programas de tipo setuid, como ser por ejemplo
su o sudo.
2.1.4.3.1. El comando su
Cuando un usuario ejecuta el comando
su, se le solicita la contraseña de root y, luego de la autenticación, 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 admisnitrativos absolutos en el sistema [13]. Además, una vez que el usuario se ha convertido en root, es posible la utilización del comando su para convertirse en cualquier otro usuario en el sistema sin que por eso se le pida ningún tipo de contraseña.
Debido a la potencia de este programa, los administradores de una organización podrían desear limitar a quiénes tienen acceso a este comando.
Una de las maneras más sencillas de hacer esto es añadiendo usuarios al grupo administrativo especial denominado wheel. Para hacerlo, ingrese el siguiente comando como usuario root:
usermod -G wheel <nombreusuario>
En el comando anterior, reemplace
<username> con el nombre del usuario que desee añadir al grupo wheel .
También 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:
- Haga clic en el menú en el panel, apunte al menú y luego haga clic en para mostrar el Aministrador de Usuarios. Alternativamente, teclee el comando
system-config-usersen un indicador de shell. - Haga clic en la pestaña Usuarios y seleccione el usuario requerido de la lista de usuarios.
- Haga clic en en la barra de herramientas para mostrar el cuadro de diálogo de las Propiedades del Usuario (o elija en el menú ).
- Haga clic en la pestaña Grupos, seleccione la casilla para el grupo wheel, y luego haga clic en . Vea la Figura 2.2, “Añadiendo usuarios al grupo "wheel"”.
- Abra el archivo de configuración PAM para el comando
su(/etc/pam.d/su) en un editor de textos, y elimine el comentario # de la siguiente línea:auth required /lib/security/$ISA/pam_wheel.so use_uid
Este cambio significa que solo miembros del grupo administrativowheelpueden usar este programa.
Ilustración del panel Grupos
Figura 2.2. Añadiendo usuarios al grupo "wheel"
Nota
El usuario root es por defecto miembro del grupo
wheel.
2.1.4.3.2. El comando sudo
El comando
sudo ofrece un nuevo punto de vista a la cuestión 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 contraseña. Entonces, cuando sea autenticado y asumiendo que el comando le sea permitido, el comando administrativo en cuestión será ejecutado como si este usuario fuera el usuario root.
Los formatos básicos del comando
sudo son los siguientes:
sudo <comando>
En el ejemplo anterior,
<command> debería ser reemplazado por un comando que por lo general esté reservado al usuario root, como ser por ejemplo, mount.
Importante
Los usuarios del comando
sudo deberían tener mucho cuidado y cancelar esta herramienta antes de abandonar sus equipos, ya que en un período de tiempo de cinco minutos, los usuarios sudo pueden utilizar el comando nuevamente sin que por ello les sea pedida una contraseña. Esta configuración puede modificarse desde el archivo de configuración /etc/sudoers.
El comando
sudo permite un alto grado de flexibilidad. Por ejemplo, solo a los usuarios listados en el archivo de configuración /etc/sudoers les es permitido utilizar el comando sudo, y el comando es ejecutado en la terminal del usuario, no en una consola de usuario root. Esto significa que la consola del usuario root puede ser completamente deshabilitada, como se indicó en Sección 2.1.4.2.1, “Deshabilitando la cuenta shell de root”.
El comando
sudo también ofrece un método fácil de entender para su control. Cada autenticación exitosa es registrada en el archivo /var/log/messages, y el comando ingresado, junto con el nombre del usuario que lo ingresó, se registran en el archivo /var/log/secure.
Otra ventaja del comando
sudo es que un administrador puede permitir a diferentes usuarios acceder a comandos específicos de acuerdo a sus necesidades.
Los administradores que quieran editar
/etc/sudoers, el archivo de configuración del comando sudo, deberían utilizar el comando visudo.
Para otrogarle a un usario todos los privilegios admisnitrativos, ingrese
visudo, y agregue una línea similar a la siguiente en la sección 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 continuación ilustra pequeños 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 página man del archivo
sudoers contiene una lista detallada de opciones.
2.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 organización, controlar qué servicios de red son los que se encuentran activos, es de importancia suprema para cualquiera que opere un sistema Linux.
Muchos servicios bajo Fedora se comportan como servidores de red. Si un servicio de red está ejecutándose en una máquina, una aplicación de servidor (denominada demonio), está escuchando las conexiones de uno o más puertos de red. Cada uno de estos servidores debería ser tratado como una potencial vía de ingreso de atacantes.
2.1.5.1. Riesgos a servicios
Los servicios de red puede plantear numerosos riesgos para sistemas Linux. A continuación mostramos una lista con algunas de las cuestiones principales:
- Ataques de denegación de servicio (DoS, por las iniciales en inglés de Denial of Service Attacks ) — Al inundar un servicio con peticiones, un ataque de denegación de servicio puede dejar inutilizable a un sistema, ya que este trata de registrar y de responder a cada petición.
- Ataques a las debilidades de los programas — Si un servidor está utilizando programas para ejecutar acciones propias, como comúnmente 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 condición de desbordamiento del búfer, o permitir que los atacantes modifiquen archivos en el sistema.
- Ataques de desbordamiento del búfer — Los servicios que se conectan al rango de puertos que va entre 0 y 1023, deben ser ejecutados como usuario administrativo. Si una aplicación puede provocar un desbordamiento del búfer, un atacante puede obtener acceso al sistema como el usuario que ejecuta el demonio. Debido a que los desbordamientos del búfer 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 búfer desbordado es mitigada en Fedora mediante la utilización de ExecShield, un programa de ejecución de segmentación de la memoria y protección de la tecnología, con soporte para kernels de sistemas compatibles x86 de uno o más procesadores. ExecShield reduce el riesgo de un desbordamiento del búfer al clasificar la memoria virtual en segmentos ejecutables y no ejecutables. Cualquier código de programa que intente ejecutarse fuera de los segmentos ejecutables (como por ejemplo codigo maliciosos introducido desde un búfer desbordado que ha sido aprovechado), dispara una falla de segmentación y finaliza.
Execshield también ofrece soporte para las tencologías No ejecutar (NX, por las iniciales en inglés de No eXecute) de las plataformas AMD64, y para las tecnologías Deshabilitar ejecutar (XD, por las iniciales en inglés de eXecute Disable) de las las plataformas Itanium y sistemas Intel® 64. Estas tecnologías trabajan junto a ExecShield para prevenir que sea ejecutado código malicioso en la porción ejecutable de la memoria virtual, con una precisión de 4KB de código ejecutable, disminuyendo el riego de un ataque a la debilidad de un búfer desbordado.
Importante
Para limitar la exposición a ataques en la red, todos los servicios que no son utilizados deben ser apagados.
2.1.5.2. Identificando y configurando servicios
Para mejorar la seguridad, muchos de los servicios de red instalados con Fedora están apagados por defecto. Hay, de todas formas, algunas notables excepciones:
cupsd— El servidor de impresión por defecto para Fedora.lpd— Un servidor de impresión alternativo.xinetd— Un súper servidor que controla las conexiones de un rango de servidores subordinados, como son, por ejemplogssftpytelnet.sendmail— El Agente de transporte de correo (MTA, por las iniciales en inglés 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 cuándo dejar estos servicios en ejecución, lo mejor es utilizar el sentido común y adoptar un punto de vista basado en la precaución. 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 debería deshabilitarse.
Ilustración Herramienta de Configuración de Servicios
Figura 2.3. Herramienta de configuración de servicios
Si no está seguro de los propósitos de un servicio particular, la Herrameinta de configuración de servicios tiene un campo descriptivo, que se detalla en Figura 2.3, “Herramienta de configuración de servicios”, y que ofrece información adicional.
Verificar qué servicios de red se encuentran disponibles para iniciarse en el momento del arranque del sistema, es sólo una parte de esta historia. Debería verificar también qué puertos están abiertos y escuchando. Para más información, vea la Sección 2.2.8, “Verificar qué puertos están abiertos”.
2.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 más información, vea la Sección 1.5, “Actualizaciones de seguridad”.
Algunos protocolos de red son en sí mismos más inseguros que otros. Estos incluyen los servicios que:
- Transmiten sin encriptar nombres de usuarios y contraseñas en la red — Muchos protocolos antiguos, como por ejemplo Telnet y FTP, no encriptan las autenticaciones de las sesiones, y siempre que sea posible, deberían ser evitados.
- Transmiten datos vitales sin encriptarse sobre una red — Muchos protocolos transmiten datos en la red sin encriptarlos. Estos protocolos incluyen Telnet, FTP, HTTP y SMTP. Muchos sistemas de archivos de red, como NFS y SMB, también transmiten información sobre internet sin encriptarla. Al utilizar estos protocolos, queda bajo la exclusiva responsabilidad del usuario limitar la clase de datos que se transmitan.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 contraseñas o, peor aún, entradas a base de datos o información sensible.Otros servicios comofingeryrwhodrevelan información 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) deberían ser evitados en favor de la utilización de SSH. Para obtener mayor información acerca de sshd, vea la Sección 2.1.7, “Herramientas de comunicación 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 información acerca cómo asegurar servidores FTP, vea la Sección 2.2.6, “Asegurando FTP”.
Entre los ervicios que deberían ser cuidadosamente implementados, y colocarse detrás de un cortafuegos, podemos encontrar a:
fingerauthd(antes llamadoidentden versiones anteriores de Fedora.)netdumpnetdump-servernfsrwhodsendmailsmb(Samba)yppasswddypservypxfrd
Mayor información acerca de cómo asegurar servicios de red puede encontrarse en la Sección 2.2, “Seguridad del servidor”.
La siguiente sección discute las herramientas disponibles para crear un cortafuegos sencillo.
2.1.6. Cortafuegos personales
Luego de haberse configurado los servicios de red necesarios, es importante la implementación de un cortafuegos.
Importante
Debería configurar los servicios necesarios e implementar un cortafuegos antes de conectarse a Internet, o a cualquier otra red en la que usted no confíe.
Los cortafuegos previenen que los paquetes de red ingresen a la interfaz de red del sistema. Si una petición es realizada a un puerto bloqueado por un cortafuegos, la petición será ignorada. Si un servicio está escuchando uno de estos puertos bloqueados, no recibe los paquetes y es efectivamente deshabilitado. Por esta razón, debe tenerse cuidado cuando se configure un cortafuegos para bloquear el acceso a puertos que no estén en uso, y se ponga atención al proceso para que no sea bloqueado el acceso a puertos utilizados por otros servicios configurados.
Para la mayoría de los usuarios, la mejor herramienta para configurar un cortafuegos es la herramienta de configuración gráfica de cortafuegos que viene con Fedora: Firewall Configuration Tool (
system-config-firewall). Esta herramienta genera reglas amplias de iptables para un cortafuegos de propósitos generales, utilizando una interfaz de panel de control.
Para obtener mayor información acerca del uso de esta aplicación y sus opciones disponibles, vea la Sección 2.8.2, “Configuración básica de un cortafuego”.
Para usuarios avanzados y administradores de servidores, es una mejor opción la de configurar manualmente el cortafuegos utilizando
iptables. Para obtener mayor información, vea la Sección 2.8, “Cortafuegos”. Para una guía detallada de la utilización del comando iptables, vea la Sección 2.9, “IPTables”.
2.1.7. Herramientas de comunicación de seguridad mejorada
Así como han crecido el tamaño y la popularidad de Internet, también han aumentado los peligros de la interceptación de las comunicaciones. Con el correr de los años, se han desarrollado herramientas para encriptar las comunicaciones mientras están siendo transferidas sobre la red.
Fedora viene con dos herramientas básicas, que usan algoritmos de encriptación de alto nivel de clave pública, para proteger la información mientras viaja por la red:
- OpenSSH — Una implementación libre del protocolo SSH para encriptar comunicaciones de red.
- Protección de Privacidad Gnu (GPG, por las iniciales en inglés de Gnu Privacy Guard) — Una implementación libre para proteger los datos de la aplicación para encriptado PGP (por las iniciales en inglés de Pretty Good Privacy).
OpenSSH es la forma más 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 línea 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 Sección 3.6, “Shell seguro (SSH, por las iniciales en inglés de Secure Shell)” para más información 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 información, vea la Sección 1.5, “Actualizaciones de seguridad”.
GPG es una manera de asegurar la privacidad en la comunicación de correo. Puede ser utilizado tanto para enviar datos sensibles sobre las redes públicas como para proteger datos sensibles en discos duros.
2.2. Seguridad del servidor
Cuando un sistema es utilizado como servidor en una red pública, 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 específicos, 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 sólo un tipo de servicio de red por máquina.
- Observe cuidadosamente a todos los servidores en busca de actividad sospechosa.
2.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 petición entrante y el servicio solicitado.
Los beneficios que ofrecen los encapsuladores TCP se potencian si se utilizan junto a
xinetd, un super servidor que ofrece acceso adicional, registrado, vinculación, redireccionamiento y control de la utilización 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 más información acerca de la implementación de cortafuegos con comandos iptable, vea la Sección 2.8, “Cortafuegos”.
Las siguientes subsecciones presuponen un conocimiento básico de cada uno de los temas, y se concentran en opciones de seguridad específicas.
2.2.1.1. Mejorando la seguridad utilizando encapsuladores TCP
Los encapsuladores TCP son capaces de mucho más que denegar el acceso a servicios. Esta sección ilustra como se pueden usar para enviar pancartas de conexión, alertar de ataques de nodos en particular y aumentar la funcionalidad de registro. Refiérase a la página del manual
hosts_options para obtener información acerca de la funcionalidad de los encapsuladores TCP y el lenguaje de control.
2.2.1.1.1. Encapsuladores TCP y pancartas de conexión
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 también controlar qué información acerca del sistema es presentada a los usuarios. Para implementar una pancarta por medio de encapsuladores TCP para un servicio, use la opción
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-Hola, %c 220-Toda actividad en ftp.ejemplo.com es registrada. 220-El uso inapropiado resultará en la remoción de los privilegios de acceso.
La ficha
%c proveé de una serie de información del cliente, como el nombre de usuario y el nombre de huésped o el nombre de usuario y la dirección IP para hacerlo más 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/
2.2.1.1.2. Encapsuladores TCP y alertas de ataque
Si un huésped 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 huésped o red usando la directiva
spawn.
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 conexión 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 conexión 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.
2.2.1.1.3. Encapsuladores TCP y registro avanzado
Si ciertos tipos de conexión son más preocupantes que otros, el nivel de registro puede ser elevado para ese servicio usando la opción
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 conexión.
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.
2.2.1.2. Aumentando la seguridad con xinetd
Esta sección 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 límites de recursos para los servicios puede ayudar a frustrar ataques de denegación de servicio (Denial of Service, DoS). Refiérase a las páginas del manual para xinetd y xinetd.conf para una lista de opciones disponibles.
2.2.1.2.1. Poniendo una trampa
Una característica 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 específico de tiempo, o hasta que xinetd sea reiniciado. Usted puede hacer esto usando el atributo SENSOR. Esta es una manera fácil 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:
flags = SENSOR
Agregue la siguiente línea:
deny_time = 30
Esto deniega cualquier intento de conexión 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 conexión 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 características en contra:
- No funciona contra exploraciones sigilosas (stealth)
- Un atacante que sabe que un
SENSOResta corriendo puede montar un ataque de denegación de servicio contra un servidor en particular al forjar su dirección IP y conectarse al puerto prohibido.
2.2.1.2.2. Control de los recursos del servidor
Otra característica importante de
xinetd es su habilidad de declarar límites de recursos para los servicios bajo su control.
Lo hace usando las siguientes directivas
cps = <number_of_connections> <wait_period>— Limita el ritmo de las conexiones entrantes. Esta directiva toma dos argumentos:<number_of_connections>— El número de conexiones por segundo a manejar. Si el ritmo de conexiones es más alto que esto, el servicio se deshabilita temporalmente. El valor por defecto es cincuenta (50).<wait_period>— El número de segundos a esperar antes de rehabilitar el servicio después de que ha sido deshabilitado. El valor por defecto es diez (10) segundos.
instances = <number_of_connections>— Especifica el número total de conexiones permitidas a un servicio. Esta directiva acepta ya sea un valor entero oUNLIMITED.per_source = <number_of_connections>— Especifica el número de conexiones permitidas a un servicio para cada huésped. Esta directiva acepta ya sea un número entero oUNLIMITED.rlimit_as = <number[K|M]>— Especifica el monto de espacio de dirección de memoria que el servicio puede ocupar en kilobytes o megabytes. Esta directiva acepta ya sea un número entero oUNLIMITED.rlimit_cpu = <number_of_seconds>— Especifica el monto de tiempo en segundos que un servicio puede ocupar del CPU. Esta directiva acepta un valor entero oUNLIMITED.
Usar estas directivas puede ayudar a prevenir cualquier servicio
xinetd de abrumar el sistema, resultando en una denegación de servicio.
2.2.2. Asegurando Portmap
El servicio
portmap es un demonio de asignación dinámica de puertos para servicios RPC como NIS y NFS. Tiene mecanismos débiles de autenticación y tiene la habilidad de asignar un amplio rango de puertos para los servicios que controla. Por estas razones, es difícil 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 sección aplica.
Si corre servicios RPC, obedezca estas reglas básicas.
2.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 autenticación.
Además, 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 métodos.
2.2.2.2. Proteja portmap con iptables
Para restringir aún más el acceso al servicio
portmap, es una buena idea agregar reglas de iptables al servidor y restringir el acceso a redes específicas.
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 demás 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 tráfico UDP de manera similar, use el siguiente comando.
iptables -A INPUT -p udp -s! 192.168.0.0/24 --dport 111 -j DROP
Nota
Diríjase a la Sección 2.8, “Cortafuegos” para más información acerca de implementar cortafuegos con comandos de iptables.
2.2.3. Asegurando NIS
El servicio de información 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 mapas de nombres de usuario, contraseñas y otros tipos de información sensible dentro de su propio dominio.
Un servidor NIS está compuesto por diversas aplicaciones. Entre ellas podemos encontrar:
/usr/sbin/rpc.yppasswdd— También denominado servicioyppasswdd. Este demonio permite que los usuarios modifiquen sus contraseñas NIS./usr/sbin/rpc.ypxfrd— También denominado servicioypxfrd. Este demonio es el responsable de las transferencias de mapas NIS sobre la red./usr/sbin/yppush— Esta aplicación 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.
De acuerdo a los estándares actuales, NIS está considerado como un método inseguro. No tiene mecanismos de autenticación y toda la información que transmite por la red viaja sin ser encriptada, incluyendo los hashes de las contraseñas. Es por esto que hay que tomar todas las precauciones posibles cuando se configure una red que utilice NIS. Esto se complica aún más por el hecho que la configuración establecida por defecto de NIS es en si misma insegura.
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 Sección 2.2.2, “Asegurando Portmap”), y que luego continúe con los siguientes eventos, como la planificación de la red.
2.2.3.1. Planeamiento cuidadoso de la red
Debido a que NIS transmite sin encriptar información clave a través de la red, es importante que el servicio sea ejecutado detrás de un cortafuegos y sobre una porción de la red definida y considerada segura. Existen riegos de intercepción cada vez que se transmite información NIS sobre una red que no es segura. Un cuidadoso diseño de la red puede ayudar a prevenir importantes intrusiones en la seguridad.
2.2.3.2. Utilización de nombres de dominio y de equipo NIS, de modo similar a una contraseña
Cualquier equipo dentro de un dominio NIS puede utilizar comandos para obtener información del servidor sin tener que autenticarse, siempre y cuando el usuario conozca tanto el nombre del equipo del servidor DNS y el nombre del dominio DNS.
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 dirección 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
Nota
Si se utiliza Kerberos, el archivo
/etc/shadow no se encuentra almacenado dentro de un mapa NIS.
Para hacer más 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 más dificil ingresar en el servidor NIS.
2.2.3.3. Editar el archivo /var/yp/securenets
Si el archivo
/var/yp/securenets está vacío o no existe (como es el caso luego de una instalación por defecto), NIS escucha a todos los puertos. Una de las primeras cosas a realizar es ingresar pares máscara de red/red (netmask/network) en el archivo de modo que ypserv solo responda a las peticiones de una red adecuada.
A continuación 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 técnica no ofrece protección contra ataques de simulación de identidad, pero al menos establece límites sobre las redes en las que el servidor NIS está funcionando.
2.2.3.4. Asigne puertos estáticos y utilice reglas de iptables
A todos los servidores relacionados con NIS se les puede asignar un puerto específico, excepto
rpc.yppasswdd — el demonio que permite a los usuarios modificar sus contraseñas de logueo. Asignar puertos a rpc.ypxfrd y ypserv, los restantes demonios de servidores NIS, permite la creación de reglas de cortafuegos, y de esta manera poder proteger a los demonios de futuras intrusiones.
Para hacerlo, agregue las siguientes líneas 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 --dport 834 -j DROP iptables -A INPUT -p ALL -s! 192.168.0.0/24 --dport 835 -j DROP
Esto significa que el servidor solo permite conexiones a los puertos 834 y 835, si es que la petición proviene desde la red 192.168.0.0/24, y sin importar qué protocolo se esté utilizando.
Nota
Diríjase a la Sección 2.8, “Cortafuegos” para más información acerca de implementar cortafuegos con comandos de iptables.
2.2.3.5. Use autenticación con Kerberos
Uno de los problemas a ser considerados si se utiliza NIS para una autenticación, es que cada vez que un usuario ingresa en una máquina, se envía un hash del mapa
/etc/shadow por la red. Si un intruso obtiene acceso a un dominio NIS y observa el tráfico en la red, puede recolectar los hashes de nombres de usuarios y contraseñas. Con el tiempo suficiente, un programa de descifrado de contraseñas puede adivinar aquellas que son débiles, y el atacante puede obtener acceso a una cuenta válida en esa red.
Debido a que Kerberos utiliza encriptados con una clave secreta, nunca se envían hashes de contraseñas sobre la red, haciendo que el sistema sea más seguro. Para obtener mayor información acerca de Kerberos, vea la Sección 2.6, “Kerberos”.
2.2.4. Asegurando NFS
Importante
La versión de NFS incluida en Fedora, NFSv4, ya no necesita el servicio
portmap como se lo indica en la Sección 2.2.2, “Asegurando Portmap”. El tráfico NFS, en lugar de UDP ahora utiliza TCP para todas sus versiones, y lo solicita al utilizar NFSv4. NFSv4 ahora incluye autenticación Kerberos para grupos y usuarios, como parte del módulo del kernel RPCSEC_GSS. Sigue existinedo información incluida acerca de portmap, desde que Fedora tiene soporte para NFSv2 y NFSv3, ya que ambos utilizan portmap.
2.2.4.1. Planeamiento cuidadoso de la red
Ahora que NFSv4 tiene la capacidad de enviar toda la información en la red encriptada utilizando Kerberos, es importante que el servicio sea configurado correctamente, si es que se encuentra detrás de un cortafuegos o en una red segmentada. Todavía NFSv3 envía los datos de manera no segura, y esto debería ser tendido en cuenta. Un diseño de redes que preste atención a todos estos aspectos puede prevenir fallas en la seguridad.
2.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 extraños cuando edite este archivo.
Por ejemplo, la siguiente línea en el archivo
/etc/exports comparte el directorio /tmp/nfs/ con el equipo juan.ejemplo.com con permisos de lectura y escritura.
/tmp/nfs/ juan.ejemplo.com(rw)
Por otro lado, la siguiente línea en el archivo
/etc/exports comparte el mismo directorio con el equipo juan.ejemplo.com, sólo con permisos de lectura, y además 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/ juan.ejemplo.com (rw)
Es una buena costumbre la de confirmar cualquier configuración de elementos compartidos NFS, utilizar para ello el comando
showmount y verificar qué es lo que está siendo compartido:
showmount -e <hostname>
2.2.4.3. No utilice la opción 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.
2.2.4.4. Configuración del cortafuego de NFS
Los puertos utilizados por NFS están dinámicamente 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 números de puerto especificados no deben ser utilizados por ningún otro servicio. Configure su cortafuegos para permitir los números 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 están siendo utilizados.
2.2.5. Asegurando el servidor HTTP Apache
El servidor HTTP Apache es uno de los servicios más seguros y estables que son empaquetados con Fedora. Una extensa variedad de opciones y técnicas están disponibles para asegurar el servidor HTTP Apache — demasiado numerosas para analizarlas en profundidad aquí. La sección siguiente explica brevemente algunas buenas costumbres al ejecutar el servidor HTTP Apache.
Siempre verifique que funcione correctamente cualquier programa que tenga intención de utilizar en el sistema antes de ponerlo en producción. Además, asegúrese que solo el usuario root tenga permisos de escritura sobre cualquier directorio que contenga programas o CGIs. Para hacer esto, ejecute los siguientes comandos como usuario root:
chown root
<nombre_de_directorio>chmod 755
<nombre_de_directorio>
Los administradores de sistemas deben ser cuidadosos al utilizar las siguientes opciones de configuración (definidas en
/etc/httpd/conf/httpd.conf):
FollowSymLinks- Esta directiva se encuentra activa por defecto, de modo que tenga cuidado al crear enlaces simbólicos al documento raíz del servidor Web. Por ejemplo, es una mala idea la de adjudicarle un enlace simbólico a
/. Indexes- Esta directiva está activa por defecto, pero puede no ser deseada. Elimínela si quiere evitar que los visitantes puedan examinar los archivos del servidor.
UserDir- La directiva
UserDirse 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 añadir usuarios a la lista de las cuentas desactivadas, añada a esos usuarios en una lista separada por espacios en la líneaUserDir disabled.
Importante
No elimine la directiva
IncludesNoExec. Por defecto, el módulo Server-Side Includes (SSI) no puede ejecutar comandos. Se recomienda no cambiar estas configuraciones a no ser que sea absolutamente necesario, ya que potencialmente podría permitir que un atacante ejecute comandos en el sistema.
2.2.6. Asegurando FTP
El Protocolo de Transferencia de Archivos (FTP, por las iniciales en inglés de File Transfer Protocol), es un viejo protocolo TCP diseñado 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 debería ser configurado cuidadosamente.
Fedora provee tres servidores FTP.
gssftpd— Un demonio basado enxinetdcon soporte para Kerberos que no transmite informaciones de autenticación sobre la red.- Acelerador de Contenido de Red Hat (
tux) — Un servidor web en el espacio del kernel con capacidades FTP. vsftpd— Una implementación orientada a la seguridad del servicio FTP.
Los siguientes lineamientos de seguridad sirven para configurar el servicio FTP
vsftpd.
2.2.6.1. Mensaje de bienvenida de FTP
Antes de enviar un nombre de usuario y una contraseña, todos los usuarios son recibidos con una imagen de bienvenida. Por defecto, esta imagen incluye la información de la versión que se está utilizando, información 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>
En la directiva indicada recién, sustituya
<insert_greeting_here> con el texto del mensaje de bienvenida.
Para imágenes con varias líneas, lo mejor es utilizar un archivo de imagen. Para simplificar la administración de múltiples imágenes, 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 continuación se puede observar cómo puede llegar a lucir un archivo con esstas características:
######### # Hola, cualquier tipo de actividad dentro de ftp.ejemplo.com es registrada. #########
Nota
No es necesario empezar cada línea del archivo con
220, como se lo indica en la Sección 2.2.1.1.1, “Encapsuladores TCP y pancartas de conexión”.
Para tener una referencia de esta imagen de bienvenida en
vsftpd, añada la siguiente directiva en el archivo /etc/vsftpd/vsftpd.conf:
banner_file=/etc/banners/ftp.msg
También es posible enviar imágenes adicionales a conexiones entrantes utilizando encapsuladores TCP como se explica en la Sección 2.2.1.1.1, “Encapsuladores TCP y pancartas de conexión”.
2.2.6.2. Acceso anónimo
La presencia del directorio
/var/ftp/ activa la cuenta anónima.
La forma más sencilla de crear este directorio es instalando el paquete
vsftpd. Este paquete establece un árbol de directorios para usuarios anónimos y configura los permisos de manera tal que estos usuarios sólo puedan leer sus contenidos.
Por defecto, el usuario anónimo no puede escribir en ningún directorio.
Advertencia
Si se habilita la posibilidad de acceso anónimo a un servidor FTP, tenga cuidado de donde almacenar los datos importantes.
2.2.6.2.1. Subida anónima
Para permitir que los usuarios anónimos suban archivos, es recomendable la creación de un directorio dentro de
/var/ftp/pub/, con permisos de escritura solamente.
Para hacerlo, ingrese el siguiente comando:
mkdir /var/ftp/pub/subidas
A continuación, modifique los permisos de modo que los usuarios anónimos no puedan conocer el contenido del directorio:
chmod 730 /var/ftp/pub/subidas
Un listado de manera extendida del directorio, debería ser semejante a esto:
drwx-wx--- 2 root ftp 4096 Feb 13 20:05 subidas
Advertencia
Los administradores que permiten que usuarios anónimos 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, añada la siguiente línea en el archivo /etc/vsftpd/vsftpd.conf:
anon_upload_enable=YES
2.2.6.3. Cuentas de usuario
Debido a que FTP transmite para su autenticación nombres de usuario y contraseñas 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
2.2.6.3.1. Restringiendo cuentas de usuario
Para deshabilitar acceso FTP para una cuenta específica, o un grupo de cuentas específico, como ser por ejemplo el usuario root y todos aquellos con privilegios
sudo, la manera más sencilla de hacerlo es utilizar un archivo de lista PAM como se explica en la Sección 2.1.4.2.4, “Deshabilitando root usando PAM”. El archivo de configuración PAM para vsftpd es /etc/pam.d/vsftpd.
También es posible deshabilitar cuentas de usuario directamente dentro de cada servicio.
Para deshabilitar cuentas de usuario específicas en
vsftpd, agregue el nombre del usuario en /etc/vsftpd.ftpusers
2.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 Sección 2.2.1.1, “Mejorando la seguridad utilizando encapsuladores TCP”.
2.2.7. Asegurando Sendmail
Sendmail es un agente de transferencia de correos (MTA, por las iniciales en inglés de Mail Transfer Agent), que utiliza protocolo simple de transferencia de correo (SMTP, Simple Mail Transfer Protocol) para enviar mensajes electrónicos entre otros MTAs, o hacia otros clientes de correo, o agentes de entrega. Si bien muchos MTAs son capaces de encriptar el tráfico entre uno y otro, algunos no lo hacen, de modo que enviar correos electrónicos en una red pública es considerado una forma de comunicación no segura.
Es recomendable que todos aquellos que estén planeando implementar un servidor Sendmail, tengan en cuenta los siguientes inconvenientes.
2.2.7.1. Limitar un ataque de denegación de servicio
Debido a la naturaleza del correo electrónico, un atacante determinado puede inundar de manera relativamente sencilla el servidor con correos, y provocar la denegación del servicio. Al establecer límites a las siguientes directivas en
/etc/mail/sendmail.mc, la efectividad de ataques de ese tipo se ve disminuida.
confCONNECTION_RATE_THROTTLE— El número de conexiones que el servidor puede recibir por segundo. Por defecto, Sendmail no limita el número de conexiones. Si se alcanza un límite previamente establecido, las siguientes conexiones son demoradas.confMAX_DAEMON_CHILDREN— El máximo número de procesos hijo que pueden ser generados por el servidor. Por defecto, Sedmail no atribuye un límite a la cantidad de estos procesos. Si se alcanza un límite previamente establecido, las siguientes conexiones serán demoradas.confMIN_FREE_BLOCKS— El número mínimo 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 tamaño máximo aceptable (en bytes) para un encabezado de mensaje.confMAX_MESSAGE_SIZE— El tamaño máximo aceptable (en bytes) para un solo mensaje.
2.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 tienen control sobre usuarios ni IDs de grupos, dos o más usuarios pueden tener el mismo UID, y recibir y leer cada uno correos electrónicos del otro.
Nota
Con NFSv4 utilizando Kerberos este no es el caso, ya que el módulo del kernel
SECRPC_GSS no utiliza autenticaciones basadas en UID. Sin embargo, todavía hoy es considerada una buena costumbre la de no colocar el directorio mail spool en volúmenes NFS compartidos.
2.2.7.3. Usuarios de sólo 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 electrónicos. Las cuentas de consola en el servidor de correo no deberían ser permitidas y todos los usuarios de consola en el archivo
/etc/passwd deberían definirse como /sbin/nologin (con la posible excepción del usuario root).
2.2.8. Verificar qué puertos están abiertos
Luego de configurar los servicios de red, es importante prestarle atención a los puertos que actualmente están escuchando en las interfases de red del sistema. Cualquier puerto abierto puede ser la evidencia de una intrusión.
Existen dos maneras fundamentales para listar los puertos que están abiertos en la red. La menos confiable consiste en consultar los paquetes en la red utilizando comandos como
netstat -an o lsof -i. Este método es menos confiable debido a que estos programas no se conectan a la máquina desde la red, sino que verifican qué es lo que se está ejecutando en el sistema. Por esta razón, estas aplicaciones frecuentemente son reemplazadas por atacantes. Alguien que quiera ocultar el rastro que está dejando al ingresar, o al abrir sin autorización los puertos de un sistema, intentará reemplazar netstat y lsof, con sus versiones personales y modificadas.
Una forma más confiable de verificar los puertos que están escuchando en una red, es mediante la utilización de un escáner 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) 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 además 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 información. 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 ningún servicio conocido.
A continuación, verifique si existe información 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. Además, la opción [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 información similar a netstat, ya que también es capaz de enlazar puertos con servicios:
lsof -i | grep 834
La sección que nos interesa de la salida de este comando es la siguiente:
ypbind 653 0 7u IPv4 1319 TCP *:834 (LISTEN) ypbind 655 0 7u IPv4 1319 TCP *:834 (LISTEN) ypbind 656 0 7u IPv4 1319 TCP *:834 (LISTEN) ypbind 657 0 7u IPv4 1319 TCP *:834 (LISTEN)
Estas herramientas nos dicen mucho acerca del estado en que se encuentran los servicios en ejecución de una máquina. Estas herramientas son flexibles y pueden ofrecer una importante cantidad de información acerca de los servicios de red y sus configuraciones. Para obtener más informacuión, vea las páginas man de
lsof, netstat, nmap, y services.
2.3. Identificación única (SSO, por las iniciales en inglés de Single Sign-on)
2.3.1. Introducción
La funcionalidad de SSO de Fedora reduce el número de veces que los usuarios de escritorio de Fedora deben ingresar sus contraseñas. Varias de las aplicaciones más importantes utilizan los mismos mecanismos subyacentes de autenticación y autorización, de modo que los usuarios pueden identificarse desde la pantalla de registro en Fedora y luego no necesitar reingresar sus contraseñas. Estas aplicaciones se describen más abajo.
Además, los usuarios pueden registrarse en sus máquinas aún cuando no exista una red (modo desconexión), o cuando la conectividad no sea confiable, como por ejemplo, los accesos inalámbricos. En este último caso, los servicios serán notablemente disminuidos.
2.3.1.1. Aplicaciones soportadas
Las siguientes aplicaciones están actualmente soportadas por el esquema de registro unificado en Fedora:
- Entrada
- Salvapantallas
- Firefox y Thunderbird
2.3.1.2. Mecanismos de autenticación soportados
Fedora actualmente tiene soporte para los siguientes mecanismos de autenticación:
- Ingreso de nombre/contraseña Kerberos
- ingreso por Tarjeta Inteligente/PIN
2.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, debería poder funcionar correctamente, del mismo modo que cualquier lector que sea soportado por PCSC-lite.
Fedora también ha sido probada con tarjetas de acceso común (CAC, por las iniciales en inglés 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 interfases de tarjetas (CCID, por las iniciales en inglés de Smart Card Interface Devices) de tipo Chip/Smart.
2.3.1.4. Ventajas de SSO de Fedora
Numerosos mecanismos de seguridad existentes hoy en día 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 recién. 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.
Para cumplir este objetivo, Fedora:
- Ofrece una sola instancia compartida de las bibliotecas de encriptación NSS en cada sistema operativo.
- Incluye el Cliente de Seguridad Empresarial (ESC en inglés) del Sistema de Certificado dentro del sistema operativo base. La aplicación ESC se encarga de controlar los eventos relacionados con la inserción de tarjetas inteligentes. Si detecta que el usuario ha insertado una tarjeta que fue diseñada para ser usada con el Certificado del Sistema del servidor de producto de Fedora, muestra una interfaz de usuario con instrucciones para que la tarjeta en cuestión pueda ser enrolada.
- Unifica Kerberos y NSS de modo que los usuarios que se registren en el sistema operativo utilizando una tarjeta inteligente, también puedan obtener credenciales de Kerberos (lo que les permite registrarse en los servidores, etc.)
2.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 tecnología ofrece, necesita realizar en un determinado orden algunas instalaciones mínimas. Más abajo se explica en qué consisten.
Nota
Esta sección ofrece una explicación general para poder empezar a utilizar su tarjeta inteligente. Información más específica puede encontrarse en la Guía del Cliente del Cliente de Seguridad Empresarial del Sistema de Certificado de Red Hat.
- Ingrese con su nombre de usuario y contraseña Kerberos.
- Asegúrese de tener instalado el paquete
nss-tools. - Descargue e instale sus certificados corporativos específicos 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
- Verifique que tenga los siguientes RPMs instalados en su sistema: esc, pam_pkcs11, coolkey, ifd-egate, ccid, gdm, authconfig, and authconfig-gtk.
- Habilite el soporte de ingreso por Tarjeta Inteligente.
- En la barra de menú superior de Gnome, elija Systema->Administración->Autenticación.
- Si es necesario, ingrese la contraseña de usuario root de su equipo.
- En el diálogo de configuración de autenticación, haga clic sobre la pestaña Autenticación.
- Tilde la casilla Activar soporte para tarjeta inteligente.
- Haga clic en el botón para ver el diálogo de configuración 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 opción para prevenir que otros usuarios ingresen a él sin una tarjeta inteligente.
- Acción 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.
- Si necesita activar el Certificado de Estado de Protocolo Online (OCSP, por las siglas en inglés de Online Certificate Status Protocol), abra el archivo
/etc/pam_pkcs11/pam_pkcs11.confy ubique la siguiente línea:enable_ocsp = false;Modifique su valor a "true", del siguiente modo:enable_ocsp = true; - Enrole su tarjeta inteligente.
- Si además está utilizando una tarjeta CAC, tendrá que realizar los siguientes pasos:
- Conviértase en usuario root y genere un archivo llamado
/etc/pam_pkcs11/cn_map. - Añada la siguiente entrada al archivo
cn_map:MY.CAC_CN.123454->myloginiddondeMY.CAC_CN.123454es el nombre común en su CAC ymyloginides su ID de logueo UNIX.
- Salida
2.3.2.1. Solución de problemas
Si se encuentra con algún inconveniente para lograr que su tarjeta inteligente funcione, intente utilizar el siguiente comando para ubicar el origen del problema.
pklogin_finder debug
Si ejecuta la herramienta
pklogin_finder en modo de depuración, mientras una tarjeta inteligente registrada se encuentre conectada, intentará mostrar información acerca de los certificados válidos, y si tiene éxito, intentará mapear un ID de registro desde los certificados que existan en la tarjeta.
2.3.3. Como funciona la inscripción de las tarjetas inteligentes.
Las tarjetas inteligentes se dice que son inscriptas cuando han recibido un certificado adecuado identificado con un Certificado de Autoridad válido (CA, por las iniciales en inglés de Certificate Authority). Esto implica una serie de pasos, que se describen a continuación:
- El usuario inserta su tarjeta inteligente en el lector de tarjetas de su estación de trabajo. Este evento es reconocido por el Cliente de Seguridad Corporativo (ESC, por las iniciales en inglés de Entreprise Security Client).
- La página de inscripción se muestra en en escritorio del usuario. El usuario completa los detalles solicitados y entonces recién su sistema se conecta con el Sistema de Procesamiento de Fichas (TPS, por las iniciales en inglés de Token Processing System) y con el CA.
- El TPS inscribe a la tarjeta inteligente utilizando un certificado firmado por CA.
Como funciona la inscripción de las tarjetas inteligentes.
Figura 2.4. Como funciona la inscripción de las tarjetas inteligentes.
2.3.4. Cómo funciona el ingreso con tarjeta inteligente
En la siguiente sección se ofrece una breve descripción general del proceso de registro utilizando una tarjeta inteligente.
- Cuando el usuario inserta su tarjeta inteligente en el lector de tarjetas, este evento es reconocido por la herramienta PAM, quien solicita al usuario su PIN.
- El sistema entonces intenta encontrar los certificados vigentes del usuario y verifica su validez. El certificado entonces es mapeado en el UID del usuario.
- Esto es validado en el KDC (centro de distribución de claves de Kerberos) y el registro es autorizado.
Cómo funciona el ingreso con tarjeta inteligente.
Figura 2.5. Cómo 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 información acerca de Kerberos y PAM, vea la Sección 2.6, “Kerberos” y Sección 2.4, “Módulos de autenticación conectables (PAM, por las iniciales en inglés de Pluggable Authentication Modules)”.
2.3.5. Configurar Firefox para la utilización de Kerberos como SSO
Puede configurar Firefox para utilizar Kerberos para la identificación ú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 sección se describen las modificaciones a realizar en la configuración, y otros requerimientos necesarios para poder utilizar correctamente esta funcionalidad.
- En la barra de direcciones de Firefox, escriba
about:configpara ver una lista actualizada de las opciones de configuración disponibles. - En el campo Filtro, ingrese
negotiatepara restringir la lista de opciones. - Haga un doble clic en la entrada network.negotiate-auth.trusted-uris para mostrar el cuadro de diálogo Ingrese valor de cadena.
- Ingrese el nombre del dominio en el cual desea autenticarse, por ejemplo,
.ejemplo.com. - Repita el procedimiento recién descrito para la entrada network.negotiate-auth.delegation-uris, utilizando el mismo dominio.
Nota
Puede dejar este valor vacío, ya que permite a Kerberos enviar tickets, lo que no es necesario.Si no puede ver estas dos opciones de configuración listadas, tal vez la versión de Firefox que está utilizando sea demasiado antigua para soportar negociados de autenticación, y debería considerar actualizarla.
Configurar Firefox para que utilice Kerberos para SSO.
Figura 2.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 continuación 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
klist: You have no tickets cached
2.3.5.1. Solución de problemas
Si ha seguido las etapas de configuración recién indicadas, y la negociación de la autenticación no funciona, puede activar la posibilidad de obtener información más detallada del proceso de autenticación. Esto podría ayudarle a encontrar la causa del problema. Para obtener más detalles del proceso de autenticación, utilice el siguiente procedimiento:
- Cerrar todas las instancias de Firefox.
- Abra una terminal, e ingrese los siguientes comandos:
export NSPR_LOG_MODULES=negotiateauth:5 export NSPR_LOG_FILE=/tmp/moz.log
- Reinicie Firefox desde esa terminal, y visite el sitio web al que no podía autenticarse anteriormente. La información será registrada en
/tmp/moz.log, y podría 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 comandokinit.
Si puede ejecutar
kinit exitosamente desde su máquina pero no puede autenticarse, debería 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 configuración de Kerberos. Asegúrese de tener las entradas correctas en la sección [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 detrás de un proxy, y que ese proxy esté eliminando los encabezados HTTP necesarios para negociar la autenticación. Una posible solución 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.
2.4. Módulos de autenticación conectables (PAM, por las iniciales en inglés de Pluggable Authentication Modules)
Los programas que permiten el acceso del usuario a un sistema usan la autenticación para verificar la identidad de cada uno (es decir, para establecer que el usuario es quien dice ser).
Históricamente, cada programa tenía su propia forma de autenticar los usuarios. En Fedora, muchos programas se configuran para usar el mecanismo de autenticación centralizado llamado Módulos de Autenticación Conectables (PAM).
PAM usa una arquitectura modular, con complementos, que le da al administrador del sistema un buen grado de flexibilidad en la configuración de las políticas de autenticación para el sistema.
En la mayoría de las situaciones, la configuración establecida por defecto del archivo PAM será suficiente para una aplicación que tenga soporte de PAM. Sin embargo, algunas veces, es necesario editar un archivo de configuración de PAM. Dado que una configuración errónea 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 modificación. Para obtener más información, vea la Sección 2.4.3, “Formato del archivo de configuración de PAM”.
2.4.1. Ventajas de PAM
PAM ofrece las siguientes ventajas;
- un esquema de autenticación común que se puede usar en una amplia variedad de aplicaciones.
- flexibilidad significativa y control sobre la autenticación 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 autenticación.
2.4.2. Archivos de configuración de PAM
El directorio
/etc/pam.d/ contiene los archivos de configuración de PAM para cada aplicación que utilice PAM. En versiones anteriores de PAM, se usaba el archivo /etc/pam.conf, pero este archivo se dejado de usar y sólo se utilizará si el directorio /etc/pam.d/ no existe.
2.4.2.1. Archivos del servicio PAM
Cada aplicación 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 configuración PAM en el directorio
/etc/pam.d/. Por ejemplo, el programa login define su nombre de servicio como login e instala el archivo de configuración PAM /etc/pam.d/login.
2.4.3. Formato del archivo de configuración de PAM
Cada archivo de configuración PAM contiene un grupo de directivas formateadas como sigue:
<interfase del módulo><bandera de control><nombre de módulo><argumentos del módulo>
Cada uno de estos elementos se explica en las secciones siguientes.
2.4.3.1. Interfaz del Módulo
Hay disponibles cuatro tipos de interfases de módulos PAM. Cada uno corresponde a distintos aspectos del proceso de autorización:
auth— Esta interfaz de módulo autentica el uso. Por ejemplo, pide y verifica la validez de una contraseña. Los módulos con esta interfaz también pueden poner credenciales, como membresías de grupo o tickets Kerberos.account— Esta interfaz de módulo 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 día.password— Esta interfaz de módulo se usa para cambiar contraseñas del usuario.session— Esta interfaz de módulo configura y administra sesiones del usuario. Los módulos con esta interfaz pueden también permitir tareas adicionales que necesitan permitir accesos, tales como el montaje del directorio de inicio del usuario y poner disponible la casilla de correo del usuario.
Nota
Un módulo individual puede proveer cualquiera o todas las interfases de módulo. Por ejemplo
pam_unix.so provee las cuatro interfaces de módulo.
En un archivo de configuración PAM, la interfaz de módulo es el primer campo definido. Por ejemplo, una línea típica en una configuración puede verse como sigue:
auth required pam_unix.so
Esto instruye a PAM a que use la interfase
auth del módulo pam_unix.so.
2.4.3.1.1. Interfases de módulos apilables
Las directivas de la interfaz modular pueden ser apiladas, o colocadas unas sobre otras, de modo que varios módulos puedan ser utilizados al mismo tiempo para el mismo propósito. Si la marca de control de un módulo utiliza el valor "sufficient" o "requisite" (vea la Sección 2.4.3.2, “Bandera de control” para obtener mayor información acerca de estas marcas), entonces el orden en que los modulos sean listados, será importante para el proceso de autenticación.
El apilado hace fácil para un administrador pedir que se den ciertas condiciones específicas antes de permitir al usuario autenticar. Por ejemplo, el comando
reboot normalmente usa varios módulos apilados, como se ve en su archivo de configuración PAM:
[root@MiServidor ~]# 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 línea es un comentario y no se procesa.
auth sufficient pam_rootok.so— Esta línea usa el módulopam_rootok.sopara verificaar si el usuario actual es root, confirmandoo que su UID sea 0. Si esto tiene éxito, no se consulta ningún otro módulo y el comando se ejecuta. Si esto falla, se consulta el módulo siguiente.auth required pam_console.so— Esta línea utiliza el módulopam_console.sopara intentar autenticar al usuario. Si este usuario ya se encuentra dentro de la consola,pam_console.soverifica 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 autenticación es existosa y el control es pasado al siguiente módulo.#auth include system-auth— Esta línea es comentada y no se procesa.account required pam_permit.so— Esta línea usa el módulopam_permit.sopara permitir al usuario root o cualquier otro que haya ingresado en la consola reiniciar el sistema.
2.4.3.2. Bandera de control
Todos los módulos 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 módulos se pueden apilar en un orden particular, y las banderas de control determinan cuán importante es el éxito o el fracaso de un módulo particular para el objetivo general de autenticación del usuario con el servicio.
Hay cuatro banderas de control predefinidas:
required— El resultado del módulo debe ser exitoso para que pueda continuar la autenticación. 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 módulos que referencian a esa interfaz.requisite— El resultado del módulo debe ser exitoso para que continúe la autenticación. Sin embargo, si una prueba falla en este punto, el usuario se notifica inmediatamente con un mensaje que muestra el primer fallo del módulorequiredorequisite.sufficient— El resultado del módulo es ignorado si falla. Sin embargo, si el resultado de un módulo marcado con banderasufficienttiene éxito y no hay módulos previos marcados conrequiredque hayan fallado, entonces no se necesitan otros resultados y el usuario es autenticado con el servicio.optional— El resultado del módulo se ignora. Un módulo marcado comooptionalsólo se vuelve necesario para una autenticación exitosa cuando no hay otros módulos referenciados en la interfaz.
Importante
El orden en el que los módulos
required se llaman no es crítico. Sólo 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 más preciso.
La página man
pam.d, y la documentación de PAM, ubicada en el directorio /usr/share/doc/pam-<version-number>/, donde <version-number> es el número de versión PAM en su sistema, explica esta nueva sintaxis en detalle.
2.4.3.3. Nombre de módulo
El nombre del módulo ofrece a PAM el nombre del módulo conectable que contiene la interfaz del módulo especificada. En versiones anteriores de Fedora la dirección completa al módulo era provista en el archivo de configuración de PAM. Sin embargo, desde la aparición de los sistemas multilib, que almacenan modulos PAM de 64-bit en el directorio
/lib64/security/, el nombre del directorio es omitido dado que la aplicación está enlazada con la versión correcta de libpam, que puede encontrar la versión correcta del módulo.
2.4.3.4. Argumentos del módulo
Para algunos módulos, PAM utiliza argumentos para pasar información a un módulo conectable durante la autenticación.
Por ejemplo, el módulo
pam_userdb.so utiliza información almacenada en un archivo de base de datos Berkeley para autenticar al usuario. Berkeley es una base de datos de código abierto que se encuentra en muchas otras aplicaciones. El módulo toma un argumento db de modo que Berkeley sepa qué base de datos utilizar para el servicio solicitado.
La siguiente es una línea típica
pam_userdb.so en una configuración de PAM. El <direccion-del-archivo> es la dirección completa del archivo base de datos DB de Berkeley:
auth required pam_userdb.so db=<direccion-del-archivo>
Los argumentos inválidos generalmente son ignorados y de esta manera no afectan ni el éxito ni el fracaso del módulo PAM. Algunos módulos, sin embargo, pueden fracasar con argumentos inválidos. La mayoría de los módulos reportan sus errores en el archivo
/var/log/secure.
2.4.4. Ejemplos de archivos de configuración de PAM
La siguiente es una muestra del archivo de configuración PAM de una aplicación:
#%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 línea es un comentario, indicado por el numeral (
#) al comienzo de la línea. - Las líneas 2 a la 4 apila tres módulos para la autenticación de ingreso.
auth required pam_securetty.so— Este módulo 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á erróneo con el siguiente mensaje:Login incorrect.auth required pam_unix.so nullok— Este módulo pide una contraseña al usuario, que luego confirma utilizando la información almacenada en/etc/passwd, y/etc/shadow, si es que existe.- El argumento
nullokle indica al módulopam_unix.soque permita el ingreso de una contraseña vacía.
auth required pam_nologin.so— Este es el último momento de la autenticación. Confirma que exista y en qué lugar, el archivo/etc/nologin. Si existe, pero el usuario no es root, la autenticación falla.Nota
En este ejemplo, los tres módulosauthse encuentran verificados, aún si falló el primer móduloauth. Esto evita que los usuarios conozcan el momento exacto en que su autenticación falló. En manos de un atacante, el conocimiento de ese dato podría permitirle deducir más fácilmente cómo vulnerar el sistema.account required pam_unix.so— Este módulo realiza cualquier tipo de verificación de cuenta que sea necesario. Por ejemplo, si se ha activado el enmascaramiento de contraseñas, la interfaz de la cuenta del módulopam_unix.soverifica que la cuenta no haya expirado, o que el usuario no haya modificado la contraseña dentro del período permitido.password required pam_cracklib.so retry=3— Si una contraseña ha expirado, el componente contraseña del módulopam_cracklib.sosolicita una nueva. En seguida confirma que la nueva contraseña pueda o no ser fácilmente revelada por un programa de obtención de contraseñas basado en diccionarios.- El argumento
retry=3indica que si esta prueba falla la primera vez, el usuario tiene dos oportunidades más para crear una contraseña más poderosa.
password required pam_unix.so shadow nullok use_authtok— Esta línea indica que si el programa modifica la contraseña del usuario, debería utilizar para ello la interfazpassworddel módulopam_unix.so.- El argumento
shadowle indica al módulo la creación de contraseñas ocultas cada vez que actualice la contraseña del usuario. - El argumento
nullokle indica al módulo que le permita al usuario modificar su contraseña desde una contraseña en blanco. De lo contrario, una contraseña vacía será tratada como un bloqueo de cuenta. - El argumento final de esta línea,
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 módulo que no le solicite al usuario una nueva contraseña, y que en su lugar acepte cualquier contraseña que haya sido almacenada por un módulo anterior. De esta manera, todas las nuevas contraseñas deben pasar la prueba depam_cracklib.sopara confirmar que sean seguras antes de ser aceptadas
session required pam_unix.so— La línea final le indica a la interfaz de sesión del módulopam_unix.soque administre la sesión. Este módulo registra el nombre de usuario y el tipo de servicio en/var/log/secureal comienzo y al final de cada sesión. Este módulo puede ser suplementado si se lo "apila" con otros módulos de sesión y poder así agregarle funcionalidades.
2.4.5. Creación de los módulos PAM
Puede crear o añadir en cualquier momento nuevos módulos PAM, para utilizarlos con cualquier aplicación con tengan este soporte.
Por ejemplo, un desarrollador puede crear un método para generar contraseñas que sean utilizadas sólo una vez, y escribir un módulo PAM que pueda soportarlo. Los programas que tengan soporte para PAM podrán utilizar inmediatamente este módulo, y el método de contraseña, sin por ello tener que ser recompilados o modificados en alguna manera.
Esto permite a los desarrolladores y a los administradores de sistema mezclar, y al mismo tiempo verificar, diferentes métodos de autenticación para diferentes programas sin necesidad de recompilarlos.
Se ha incluido documentación para escribir módulos en el directorio
/usr/share/doc/pam-<version-number>/, donde <version-number> es el número de versión PAM de su sistema.
2.4.6. PAM y el cacheo de la credencial administrativa
Una cantidad de herramientas administrativas gráficas en Fedora le ofrecen a los usuarios un elevado grado de privilegio, durante un período de tiempo de hasta cinco minutos, utilizando el módulo
pam_timestamp.so. Es importante entender como funciona este mecanismo, ya que si algún usuario abandona la terminal mientras continue vigente pam_timestamp.so, dejará a ese equipo libre para ser manipulado por quienquiera que tenga acceso físico a la consola.
En el esquema del registro del tiempo de PAM, cuando es iniciada la aplicación administrativa gráfica, solicita al usuario la contraseña de root. Cuando el usuario ha sido autenticado, el módulo
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 gráficos no solicitarán una contraseña. En su lugar, el módulo pam_timestamp.so actualizará el archivo de registro de tiempo, reservando cinco minutos extra de acceso administrativo sin contraseñas al usuario.
Puede verificar el estado actual del archivo de registro de tiempo, consultando el archivo
/var/run/sudo/<usuario>. Para el escritorio, el archivo importante es unknown:root. Si se encuentra presente y su registro de tiempo es menor a cinco minutos de antigüedad, las credenciales son válidas.
La existencia del archivo de registro de tiempo se indica mediante un ícono de autenticación, que aparece en el área de notificación del panel.
Ilustración del ícono de autenticación.
Figura 2.7. El Ícono de autenticación
2.4.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 gráfico, haga clic sobre el ícono de autenticación del panel. Esto hace que se abra un cuadro de diálogo. Haga clic sobre el botón para destruir el archivo de registro de tiempo activo.
Ilustración del cuadro de diálogo de olvido de la autenticación.
Figura 2.8. Diálogo de olvidar autenticación
Con respecto al archivo de registro de tiempo de PAM, debe prestarle atención a lo siguiente:
- Si ha ingresado en el sistema remotamente, utilizando el comando
ssh, utilice el comando/sbin/pam_timestamp_check -k rootpara destruir el archivo de registro de tiempo. - Será necesario que ejecute el comando
/sbin/pam_timestamp_check -k rootdesde la misma ventana de la terminal desde la que inició la aplicación con este privilegio. - Debe estar registrado como el usuario que originalmente invocó el módulo
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 acción 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 página man
pam_timestamp_check para obtener más información acerca del uso de pam_timestamp_check para destruir el archivo de registro de tiempo.
2.4.6.2. Directivas comunes de pam_timestamp_check
El módulo
pam_timestamp.so acepta varias indicaciones. Las siguientes dos opciones son algunas de las más utilizadas:
timestamp_timeout— Especifica el periodo (en segundos) durante el cual el archivo de registro de tiempo es válido. 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 Sección 2.8.9.1, “Documentación instalada del cortafuego” para obtener mayor información acerca de la utilización del módulo
pam_timestamp.so.
2.4.7. PAM y la propiedad de los dispositivos
En Fedora, el primer usuario que se registra en la consola física de la máquina, puede manipular ciertos dispositivos y realizar ciertas tareas que por lo general son reservadas al usuario root. Esto es controlado por un módulo PAM denominado
pam_console.so.
2.4.7.1. Propiedad de los dispositivos
Cuando un usuario se registra en un sistema Fedora, el módulo
pam_console.so es llamado mediante el comando login, o mediante algunos de los programa gráficos de logueo, como ser gdm, kdm, y xdm. Si este usuario es el primero en loguearse en la consola física — 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 sesión local. Una vez que este usuario haya finalizado su sesión, 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 instalación 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/etc/security/console.perms.d/50-default.perms
Puede cambiar los permisos de los otros dispositivos diferentes, además de los que se han mostrado antes, o modificar los especificados por defecto. En lugar de modificar el archivo
50-default.perms, debería crear uno nuevo (por ejemplo xx-name.perms51-default.perms). Esto va a sustituir lo indicado en el archivo 50-default.perms.
Advertencia
Si el archivo de configuración del administrador de gdm, kdm, o xdm ha sido alterado de manera tal que permita que usuarios remotos puedan ingresar y si el equipo está configurado para ejecutarse en el nivel de ejecución 5, es aconsejable modificar las directivas
<console> y <xconsole> del archivo /etc/security/console.perms con los siguientes valores:
<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 máquina.
Si el archivo de configuración del administrador de gdm, kdm, o xdm ha sido modificado de modo que permita que usuarios remotos puedan ingresar, y si el equipo está configurado para ejecutarse en cualquier nivel de ejecución multiusuario además del nivel de ejecución 5, es aconsejable eliminar completamente la directiva
<xconsole>, al mismo tiempo que modificar la directiva <console> con el valor siguiente:
<console>=tty[0-9][0-9]* vc/[0-9][0-9]*
2.4.7.2. Acceso a aplicaciones
El usuario de la consola también tiene el acceso a ciertos programas configurados para usar el directorio
/etc/security/console.apps/.
Este directorio contiene los archivos de configuración que habilitan al usuario de la consola correr ciertas aplicaciones de
/sbin y /usr/sbin.
Estos archivos de configuración 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 módulo
pam_console.so como un requisito para usarlas.
Vaya a la Sección 2.8.9.1, “Documentación instalada del cortafuego” para más información.
2.4.8. Recursos adicionales
Los siguientes recursos explican más detalladamente los métodos para usar y configurar PAM. Además de estos recursos, lea los archivos de configuración de PAM en el sistema para entender mejor cómo están estructurados.
2.4.8.1. Documentación de PAM instalada
- Las páginas man relacionadas con PAM — Hay varias páginas man para las distintas aplicaciones y archivos de configuración involucrados con PAM. La siguiente es un alista de alguna de las páginas man más importantes.
- Archivos de configuración
pam— Buena información de presentación de PAM, que incluye la estructura y propósito de los archivos de configuración de PAM.Fíjese que en esta página man se hace referencia tanto al archivo/etc/pam.confcomo a los archivos de configuración individuales del directorio/etc/pam.d/. Por defecto, Fedora utiliza los archivos de configuración individual del directorio, ignorando el archivo/etc/pam.conf, aún si efectivamente existe.pam_console— Describe el propósito del módulopam_console.so. También describe la sintaxis apropiada para una entrada dentro del archivo de configuración de PAM.console.apps— Describe el formato del archivo de configuración/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 configuración/etc/security/console.perms, que especifica los permisos del usuario de consola asignados por PAM.pam_timestamp— Describe el módulopam_timestamp.so.
/usr/share/doc/pam-— Contiene una Guía de administradores de sistema, un Manual para escritores de módulos, y el Manual para desarrolladores de aplicación, y al mismo tiempo, una copia del stándard PAM DCE-RFC 86.0, donde<version-number><version-number>es el número de la versión de PAM./usr/share/doc/pam-— Contiene información relacionada con el módulo PAM<version-number>/txts/README.pam_timestamppam_timestamp.so, donde<version-number>es el número de versión de PAM.
2.4.8.2. Sitios web útiles sobre PAM
- http://www.kernel.org/pub/linux/libs/pam/ — El sitio web principal de distribución del proyecto Linux-PAM, que contiene información relacionada con varios módulos PAM, una sección con respuestas a las preguntas más usuales (FAQ, por las siglas en inglés de Frequently Asked Questions), y documentación adicional acerca de PAM.
Nota
La documentación en el sitio web de arriba es para la última versión de desarrollo lanzada de PAM y puede no ser 100% precisa para la versión de PAM incluida en Fedora.
2.5. Encapsuladores TCP y xinetd
Controlar el acceso a los servicios de red es una de las tareas más importantes que deben realizar los administradores de servidor relacionadas con la seguridad. Fedora ofrece diferentes herramientas para este propósito. Por ejemplo, filtros de cortafuegos basados en
iptables, no permiten el ingreso a la configuración del kernel a todos aquellos paquetes que no hayan sido solicitados. Para los servicios de red que lo utilizan, los Encapsuladores TCP añaden una capa de protección adicional al definir los equipos que tienen o no permitida la conexión a los servicios de red "encapsulados". Tal servicio de red encapsulado es el súper servidor xinetd. Este servicio es llamado un súper servidor debido a que controla las conexiones de una serie de subservicios de red y posteriormente refina el control de acceso.
Figura 2.9, “Control de acceso a servicios de red” es una ilustración básica acerca de cómo estas herramientas trabajan conjuntamente para proteger los servicios de red.
A: Control de acceso al flujo de datos de los servicios de red
Figura 2.9. Control de acceso a servicios de red
El siguiente capítulo 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 administración de su utilización. Para obtener mayor información utilizando cortafuegos con iptables, vea la Sección 2.9, “IPTables”.
2.5.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 más importante de este paquete es la biblioteca /usr/lib/libwrap.a. En términos generales, un servicio encapsulado por TCP es un servicio que ha sido compilado con la biblioteca libwrap.a.
Cuando se realiza un intento de conexión a un servicio encapsulado por TCP, el servicio primero consulta los archivos de acceso del equipo (
/etc/hosts.allow y /etc/hosts.deny) para determinar en qué casos el equipo tiene permitida la conexión. Generalmente, luego utiliza al demonio syslog (syslogd) para escribir el nombre del cliente solicitante y del servicio solicitado en los archivos /var/log/secure o /var/log/messages.
Si un cliente tiene permitida la conexión, los encapsuladores TCP liberan el control de la conexión al servicio solicitado, y abandonan el proceso de comunicación entre el cliente y el servidor.
Además 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 conexión, o antes de abandonar el proceso de conexión al servicio de red solicitado.
Debido a que los encapsuladores TCP son un valioso agregado al equipo de herramientas de seguridad que cualquier administrador de servidor posee, muchos servicios de red dentro de Fedora se encuentran enlazados con la biblioteca
libwrap.a. Algunas de estas aplicaciones son /usr/sbin/sshd, /usr/sbin/sendmail, y /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 <nombre-binario> | grep libwrap
Reemplace
<binary-name> con el nombre del servicio de red ejecutable.
Si el comando no le devuelve ninguna información, 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 ~]#
2.5.1.1. Ventajas de los Encapsuladores TCP
Los encapsuladores TCP ofrecen las siguientes ventajas en comparación con otras técnicas para el control de servicios de red:
- Transparencia tanto para el cliente como para el servicio de red encapuslado — Tanto el cliente que está conectándose como el servicio de red, no tienen conocimiento de que los encapsuladores TCP están siendo utilizados. Los usuarios legítimos se registran y conectan a los servicios solicitados, mientras que no se realizan las conexiones pedidas por clientes no autorizados.
- Administración centralizada de múltiples 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 común de archivos de configuración de control de acceso, haciendo posible que la administración sea más sencilla.
2.5.2. Archivos de configuración 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, comúnmente denominados archivos de acceso de equipos:
/etc/hosts.allow/etc/hosts.deny
Cuando un servicio encapsulado por TCP recibe una petición de un cliente, realiza los siguientes pasos:
- Consulta con
/etc/hosts.allow. — El servicio encapsulado por TCP analiza secuencialmente el archivo/etc/hosts.allowy aplica la primera regla especificada para ese servicio. Si encuentra una regla concordante, permite la conexión. Si no, avanza al siguiente paso. - Consulta con
/etc/hosts.deny. — El servicio encapsulado por TCP analiza secuencialmente el archivo/etc/hosts.deny. Si encuentra una regla concordante, niega la conexión. 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 enhosts.deny. De este modo, si el acceso a un servicio es permitido enhosts.allow, será ignorada una regla negando el acceso al mismo servicio del archivohosts.deny. - Las reglas de cada archivo son leídas 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.allowohosts.deny, tienen efecto inmediato, sin necesidad de reiniciar los servicios de red.
Advertencia
Si la última línea del archivo de acceso de un equipo no es un caracter de tipo nueva línea (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 líneas múltiples sin utilizar el carcater de línea invertida. El siguiente ejemplo muestra la sección que nos interesa del fracaso de una regla debido a alguna de las circunstancias recién descritas:
warning: /etc/hosts.allow, line 20: missing newline or line too long
2.5.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 línea. Líneas vacías o líneas que empiezan con el símbolo numeral (#) son ignoradas.
Cada regla utiliza el siguiente formato básico para controlar el acceso a los servicios de red:
<daemon list>:<client list>[:<option>:<option>: ...]
<daemon list>— Una lista separadas por comas de nombres de procesos (y no el nombre de los servicios), o la opciónALL. La lista del demonio también acepta operadores (vea la Sección 2.5.2.1.4, “Operadores”) para permitir mayor flexibilidad.<client list>— Una lista separada por comas de nombres de equipos, direcciones IP de los equipos, patrones especiales o comodines que identifican a los equipos afectados por la regla. La lista de cliente también acepta los operadores mostrados en la Sección 2.5.2.1.4, “Operadores” para permitir mayor flexibilidad.<opcion>— Una acción, o una lista de acciones optativas separadas por puntos y comas, a realizarse cuando la regla sea disparada. Los campos de opción tienen soporte para expansiones, comandos de apertura de terminales, permitir o negar acceso, y modificar la conducta de registro.
Nota
Puede encontrarse mayor información acerca de los términos recién vistos en otras partes de esta Guía:
A continuación se muestra el ejemplo de una regla básica de acceso de equipos:
vsftpd : .ejemplo.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 conexión es aceptada. Si esta regla figura en hosts.deny, la conexión es negada.
El siguiente ejemplo de regla de acceso de equipos es más compleja y utiliza dos campos de opciones:
sshd : .example.com \ : spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \ : deny
Fíjese que cada campo de opción es precedido por la barra invertida (\). La utilización de esta barra previene el fallo de la regla debido a su longitud.
Esta regla de ejemplo establece que si se intenta establecer una conexión con el demonio SSH (
sshd) desde algún equipo del dominio example.com, ejecute el comando echo para añadir el intento en un archivo de log especial, y negar la conexión. Debido a que la directiva opcional deny es utilizada, esta línea niega el acceso aún si figura en el archivo hosts.allow. Para conocer en detalle otras opciones disponibles, vea la Sección 2.5.2.2, “Campos de opción”.
2.5.2.1.1. Comodines
Los comodines le permiten a los encapsuladores TCP poder corresponderse más fácilmente con grupos de demonios de equipos. Son más frecuentemente utilizados en el campo lista de cliente de las reglas de acceso.
Los siguientes comodines están 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.KNOWN— Se corresponde con cualquier equipo cuyo nombre y la dirección sean conocidas o donde el usuario sea conocido.UNKNOWN— Se corresponde con cualquier equipo cuyo nombre o dirección sean desconocidos, o donde el usuario sea desconocido.PARANOID— Se corresponde con cualquier equipo cuyo nombre no concuerde con su dirección.
Importante
Los comodines
KNOWN, UNKNOWN, y PARANOID deben ser utilizados con cuidado, ya que dependen del servidor DNS que se esté utilizando para su operación correcta. Cualquier interrupción de la resolución de nombres podría causar que se les niegue acceso al servicio a los usuarios legítimos.
2.5.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 más precisa.
A continuación 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 : .ejemplo.com
- Dirección IP que finaliza con un punto (.) — Colocar un punto al finalizar una dirección IP hace que se correspondan todos los equipos que comparten los grupos numéricos iniciales de una dirección IP. El siguiente ejemplo se aplica a cualquier equipo dentro de la red
192.168.x.x:ALL : 192.168.
- Dirección IP/par de máscara de red — Las expresiones de máscaras de red también pueden utilizarse como un patrón 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.0hasta192.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 dirección/prefijo (prefixlen) en las declaraciones (notación CIDR) no están soportadas. Solo las reglas IPv6 pueden utilizar este formato. - [direcciones IPv6]/par prefixlen — los pares [red]/prefixlen también pueden ser utilizados como un patrón 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::hasta3ffe: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 estén 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 : *.ejemplo.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.hostspara todas las conexiones Telnet.in.telnetd : /etc/telnet.hosts
Existen otros patrones menos utilizados que también aceptan los encapsuladores TCP. Para obtener mayor información, vea la página 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. Además, la interrupción del servicio DNS impide la utilización de los servicios de red incluso a los usuarios autorizados. De modo que, lo mejor es utilizar direcciones IP siempre que sea posible.
2.5.2.1.3. Portmap y encapsuladores TCP
La implementación de
Portmap de los encapsuladores TCP no tiene soporte para búsqueda de equipos, lo que significa que Portmap no puede utilizar los nombres de los equipos para identificarlos. Por lo tanto, las reglas de control de acceso para portmap en hosts.allow o hosts.deny, deben ser direcciones IP, o la palabra clave ALL para especificar equipos.
Los cambios en las reglas de control de acceso de
portmap podrían 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.
2.5.2.1.4. Operadores
Hoy en día, 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 específicas para ampliar las correspondencias dentro de una misma regla.
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: .ejemplo.com EXCEPT cracker.ejemplo.com
En otro ejemplo de un archivo
hosts.allow, los clientes de la red 192.168.0.x pueden utilizar todos los servicios con excepción de FTP:
ALL EXCEPT vsftpd: 192.168.0.
Nota
En términos de organización, generalmente es más sencillo evitar la utilización de operadores
EXCEPT. Esto permite que otros administradores analicen rápidamente 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.
2.5.2.2. Campos de opción
Además de las reglas básicas que permiten o que niegan el acceso, la implementación de encapsuladores TCP de Fedora soporta extensiones al lenguaje de control de acceso a través de campos de opción. Al utilizar los campos de opción 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.
2.5.2.2.1. Registro
Los campos de opción permiten que los administradores modifiquen fácilmente 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 ningún valor de la herramienta es especificado) con una prioridad de emerg:
sshd : .example.com : severity emerg
Es también posible especificar una herramienta utilizando la opción
severity. El siguiente ejemplo registra cualquier intento de conexión SSH realizada por equipos del dominio ejemplo.com a la herramienta local0, con una prioridad de alert:
sshd : .ejemplo.com : severity local0.alert
Nota
En la práctica, este ejemplo no funciona hasta que el demonio syslog (
syslogd) sea configurado para registrarse en la herramienta local0. Para obtener mayor información acerca de cómo configurar herramientas de registro establecidas por defecto, vea la página man de syslog.conf.
2.5.2.2.2. Control de acceso
Los campos de opción también le permiten a los administradores permitir o negar explícitamente equipos mediante una sola regla, añadiéndole la directiva
allow o deny como la opción 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 opción 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.
2.5.2.2.3. Comandos de la consola
Los campos de opción 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 utilización de/usr/sbin/safe_fingerpara obtener mayor información acerca del cliente que está realizando una determinada petición, o crear archivos de registro especiales mediante la utilización del comandoecho.En el siguiente ejemplo, los clientes del dominioejemplo.comque intentan acceder a servicios Telnet, son registrados silenciosamente en un archivo especial:in.telnetd : .ejemplo.com \ : spawn /bin/echo `/bin/date` from %h>>/var/log/telnet.log \ : allowtwist— Reemplaza el servicio solicitado con el comando indicado. Esta directiva es a menudo utilizada para establecer trampas a los intrusos (también denominadas "tacitas de miel"). Puede también ser utilizada para enviar mensajes a los cllientes que estén conectándose. La directivatwistdebe tener lugar al final de la línea de la regla.En el ejemplo siguiente, a los clientes que intentan acceder a los servicios FTP desde el dominioejemplo.com, se les envía un mensaje utilizando el comandoecho.vsftpd : .ejemplo.com \ : twist /bin/echo "421 This domain has been black-listed. Access denied!"
Para obtener mayor información acerca de las opciones de comandos de terminal, vea la página man de
hosts_options.
2.5.2.2.4. Expansiones
Cuando se utilizan junto a las directivas
spawn y twist, las expansiones proveen información acerca del cliente, servidor, y los procesos involucrados.
La siguiente es una lista de expansiones soportadas:
%a— Informa la dirección IP del cliente.%A— Informa la dirección IP del servidor.%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 dirección IP.%d— Informa el nombre del demonio encargado del proceso.%h— Informa el nombre del equipo del cliente (o la dirección IP, si es que el nombre del equipo no está disponible).%H— Informa el nombre del equipo del servidor (o su dirección IP, en caso que el nombre no esté disponible).%n— Informa el nombre del equipo cliente. Si no está disponible, se muestraunknown. Si el nombre del equipo y la dirección del cliente no concuerdan, se muestraparanoid.%N— Informa el nombre del equipo del servidor. Si no está disponible, se muestraunknown. Si el nombre del equipo del servidor y la dirección no concuerdan, se muestraparanoid.%p— Informa el ID del proceso del demonio.%s— Informa diferentes tipos de datos acerca del servidor, como ser por ejemplo, si el proceso del demonio y la dirección del equipo o dirección IP del servidor.%u— Informa el nombre de usuario del cliente. Si no está disponible, se muestraunknown.
La siguiente regla de ejemplo utiliza una expansión 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 expanción %h).
sshd : .ejemplo.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 : .ejemplo.com \ : twist /bin/echo "421 %h has been banned from this server!"
Para obtener una explicación completa de las expansiones disponibles, y al mismo tiempo conocer opciones adicionales de control de acceso, vea la sección 5 de las páginas man de
hosts_access (man 5 hosts_access), y la página man de hosts_options.
Para obtener mayor información acerca de los encapsuladores TCP, vea la Sección 2.5.5, “Recursos adicionales”.
2.5.3. xinetd
El demonio
xinetd es un súper servicio encapsulado por TCP, que controla el acceso a un subconjunto de servicios de red muy utilizados, como por ejemplo FTP, IMAP y Telnet. También ofrece opciones de configuración de servicio específicas para control de acceso, registros mejorados, uniones, redirecciones y control de la utilización de los recursos.
Cuando un cliente intenta conectarse a un servicio de red controlado por
xinetd, el súper servicio recibe la petición y verifica la existencia de reglas de control de acceso para encapsuladores TCP.
Si el acceso es permitido,
xinetd verifica que la conexión sea permitida bajo sus propias reglas de acceso para ese servicio. También verifica que el servicio pueda tener más recursos disponibles, y que no esté en contradicción 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 límite de sus recursos; y el servicio no entra en colisión con ninguna otra regla definida), entonces
xinetd inicia una instancia del servicio solicitado y le pasa el control de la conexión. Luego que la conexión haya sido establecida, xinetd deja de formar parte en la comunicación entre el cliente y el servidor.
2.5.4. Archivos de configuración de xinetd
Los archivos de configuración para
xinetd son los siguientes:
/etc/xinetd.conf— El archivo de configuración general de/etc/xinetd.conf./etc/xinetd.d/— El directorio continente de todos los archivos específicos para cada servicio.
2.5.4.1. El archivo /etc/xinetd.conf
El archivo
/etc/xinetd.conf contiene parámetros de configuraciones generales que afectan cada servicio controlado por xinetd. Es leido cuando el servicio xinetd es iniciado por primera vez, de modo que para que los cambios en la configuración tengan efecto, habrá que reiniciar el servicio xinetd. El siguiente es un ejemplo del archivo /etc/xinetd.conf.
defaults
{
instances = 60
log_type = SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST
cps = 25 30
}
includedir /etc/xinetd.d
Estas lineas controlan los siguientes aspectos de
xinetd:
instances— Indica el número máximo de peticiones simultáneas que puede procesarxinetd.log_type— Configuraxinetdpara utilizar la herramienta de registroauthpriv, que guarda entradas de registro en el archivo/var/log/secure. Agregar una directiva comoFILE /var/log/xinetdlogpodría crear un archivo de registro modificado denominadoxinetdlogen el directorio/var/log/.log_on_success— configuraxinetdpara registrar intentos de conexión exitosos. Por defecto, son registradas la dirección IP del equipo remoto y los ID de los procesos del servidor que está procesando la petición.log_on_failure— Configuraxinetdpara registrar intentos de conexión fallidos, o casos en que la conexión fue negada.cps— Configuraxinetdpara permitir más de 25 conexiones por segundo hacia cualquier servicio dado. Si el límite es superado, el servicio se retira durante 30 segundos.includedir/etc/xinetd.d/— Incluye opciones declaradas en los archivos de configuración propios de cada servicio, ubicados en el directorio/etc/xinetd.d/. Para obtener mayor infirmación, consulte Sección 2.5.4.2, “El directorio /etc/xinetd.d/”.
Nota
A menudo, tanto las configuraciones
log_on_success como log_on_failure establecidas en /etc/xinetd.conf son modificadas posteriormente en los archivos de configuración propios de cada servicio. Por lo tanto existirá mayor información en el archivo de registro de un servicio dado, que la que pueda indicar el archivo /etc/xinetd.conf. Para mayor información, vea la Sección 2.5.4.3.1, “Opciones para registrado”.
2.5.4.2. El directorio /etc/xinetd.d/
El directorio
/etc/xinetd.d/ contiene los archivos de configuración 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 razón por la que la configuración de cada servicio sea almacenada en un archivo diferente, es para hacer más sencilla la personalización, y menos propensa a modificar otros servicios.
Para adquirir una mejor comprensión acerca de cómo están estructurados estos archivos, prestele atención al archivo
/etc/xinetd.d/krb5-telnet:
service telnet
{
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/kerberos/sbin/telnetd
log_on_failure += USERID
disable = yes
}
Estas líneas controlan numerosos aspectos del servicio
telnet:
service— Especifica el nombre del servicio, generalmente uno de aquellos listados en el archivo/etc/servicesflags— Establece alguno de los atributos para la conexión.REUSEle indica axinetdque vuelva a utilizar el socket para una conexión Telnet.Nota
La marcaREUSEes obsoleta. Todos los servicios hoy en día utilizan la marcaREUSE.socket_type— Establece el tipo de socket de red astream.wait— Especifica cuando el servicio es tratado como de uno solo hilo de ejecución (yes) o como de múltiples hilos de ejecución (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 parámetros de registro paralog_on_failure, además de los que ya están definidos enxinetd.conf.disable— Especifica cuándo el servicio debe ser desactivado (yes), o activado (no).
Para obtener mayor información sobre estas opciones y su uso, consulte la página man de
xinetd.conf.
2.5.4.3. Alteración de los archivos de configuración de xinetd
Existen disponibles una variedad de directivas protegidas por
xinetd. En esta sección se detallan algunas de las opciones más comunmente utilizadas.
2.5.4.3.1. Opciones para registrado
Las siguientes opciones de registro se encuentran disponibles tanto para
/etc/xinetd.conf como para los archivos de configuración del servicio específico en el directorio /etc/xinetd.d/.
La siguiente es una lista de las opciones de registro más utilizadas:
ATTEMPT— Registra el hecho de haberse realizado un intento fallido (log_on_failure).DURATION— Registra el período 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 señal de finalización del servicio (log_on_success).HOST— Registra la dirección IP del equipo remoto (log_on_failureylog_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 método definido en RFC 1413 para todos los servicios stream de aspectos múltiples (log_on_failureylog_on_success).
Para obtener una lista completa de opciones de registro, consulte la página man de
xinetd.conf.
2.5.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 configuración de xinetd, o una mezcla de ambos. Para obtener mayor información acerca del control de acceso de los equipos con encapsuladores TCP, consulte la Sección 2.5.2, “Archivos de configuración de los encapsuladores TCP”.
En esta sección se desarrolla la utilización de
xinetd para controlar el acceso a los servicios.
Nota
Al contrario que con los encapsuladores TCP, las modificaciones al control de acceso sólo 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.
El control de acceso de los equipos con
xinetd difiere del método utilizado por encapsuladores TCP. Mientras que los encapsuladores TCP colocan todas las configuraciones de acceso en dos archivos, /etc/hosts.allow y /etc/hosts.deny, el control de acceso de xinetd se encuentra en cada uno de los archivos de configuración de los servicios dentro del directorio /etc/xinetd.d/.
Las siguientes opciones de acceso de equipos están soportadas por
xinetd:
only_from— Permite la utilización del servicio sólo a los equipos especificados.no_access— Impide la utilización del servicio a los equipos indicados.access_times— Establece el período de tiempo en que un servicio particular puede ser utilizado. Este período 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 configuración mejorada de registro puede aumentar la seguridad evitando las peticiones de los equipos bloqueados, al mismo tiempo que se registra cada intento de conexión.
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 = no
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/kerberos/sbin/telnetd
log_on_failure += USERID
no_access = 172.16.45.0/24
log_on_success += PID HOST EXIT
access_times = 09:45-16:15
}
En este ejemplo, cuando un sistema de cliente de la red
10.0.1.0/24, como por ejemplo 10.0.1.2 intenta acceder al servicio Telnet, recibe el siguiente mensaje:
Conexión cerrada por el equipo remoto.
Además, sus intentos de registro son almacenados en
/var/log/messages de la manera siguiente:
Sep 7 14:58:33 localhost xinetd[5285]: FAIL: telnet address from=172.16.45.107 Sep 7 14:58:33 localhost xinetd[5283]: START: telnet pid=5285 from=172.16.45.107 Sep 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 relación entre ambos mecanismos de control de acceso.
La siguiente es la secuencia de eventos que realiza
xinetd cada vez que un cliente solicite una conexión:
- El demonio
xinetdobtiene las reglas de acceso de los equipos con encapsuladores TCP, utilizando una llamada de bibliotecalibwrap.a. Si una regla de negación concuerda con el cliente, se abandona la conexión. Si una regla de conexión concuerda con el cliente, la conexión es entregada axinetd. - El demonio
xinetdverifica sus propias reglas de control de acceso tanto para el servicioxinetd, como para el servicio solicitado. Si una regla de negación concuerda con el cliente, se abandona la conexión. De lo contrario,xinetdinicia una instancia del servicio solicitado y entrega el control de la conexión 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 configuración puede causar efectos no deseados.
2.5.4.3.3. Opciones de unión y redirección
Los archivos de configuración del servicio
xinetd tienen soporte para asociar el servicio con una dirección IP, y redireccionar las peticiones entrantes para ese servicio hacia otra dirección IP, nombre de equipo, o puerto.
Esta asociación es controlada con la opción
bind en el archivo de configuración específico de cada servicio, y enlaza ese servicio con una dirección IP en el sistema. Cuando esto es configurado, la opción bind sólo acepta peticiones para acceder al servicio de la dirección IP correcta. Puede utilizar este método para asociar diferentes servicios con diferentes interfases de acuerdo a sus propias necesidades.
Esto es especialmente útil para los sistemas con adaptadores de red múltiples, o con múltiples direcciones IP. En tales sistemas, los servicios no seguros (Telnet, por ejemplo), pueden ser configurados para que sólo escuchen en una interfaz conectada con una red privada y no con una interfaz conectada a Internet.
La opción
redirect acepta una dirección IP o nombre de equipo seguido por un número de puerto. Configura el servicio de modo tal de poder redireccionar cualquier petición para este servicio hacia el equipo y número de puerto indicado. Esta herramienta puede ser utilizada para dirigirse hacia otro número de puerto en el mismo sistema, redireccionar la petición hacia una dirección IP diferente en la misma máquina, intercambiar la petición con un sistema y número de puerto totalmente diferente, o combinar entre ellas cualesquiera de estas opciones. Un usuario conectándose con un servicio determinado de un sistema, por lo tanto puede ser reruteado hacia otro sistema sin sufrir ningún tipo de interrupción.
El demonio
xinetd es capaz de lograr este redireccionamiento extendiendo un proceso activo durante todo el tiempo que dure la conexión, entre la máquina del cliente que realiza la petición y el equipo que efectivamente está proveyendo el servicio, transfiriendo los datos entre ambos sistemas.
Las ventajas de
bind y redirect se hacen más evidentes cuando se utilizan de manera conjunta. Al asociar un servicio con una dirección IP determinada de un sistema, y luego redireccionar las peticiones para este servicio hacia una segunda máquina que sólo 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 exposición de un servicio determinado en una máquina hacia una dirección IP conocida, al mismo tiempo que redirecciona cualquier petición para ese servicio hacia otra máquina configurada para ese propósito.
Por ejemplo, piense en un sistema que es utilizado como un cortafuegos con la siguiente configuración 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 máquina está unido a la dirección IP externa (123.123.123.123), por medio de la cual se conecta a Internet. Además, cualquier petición para el servicio Telnet enviada a 123.123.123.123, es redireccionada hacia una dirección 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 envía la comunicacién entre ambos sistemas, y el sistema que está conectándose piensa que lo ha hecho con 123.123.123.123, cuando en realidad está conectado con una máquina diferente.
Esta herramienta es especialmente útil para usuarios con conexiones de banda ancha que sólo posean una dirección IP fija. Si utilizan Traductores de Direcciones de Red (NAT por las iniciales en inglés de Network Adress Translations), los sistemas detrás de la máquina que hace de puerta de enlace, que están utilizando direcciones IP sólo internas, no están 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 máquina que hace de puerta de enlace puede actuar como un proxy entre los sistemas externos y una máquina interna determinada que haya sido configurada para ofrecer el servicio. Además, las diferentes opciones de registro y de control de acceso de xinetd, están disponibles para establecer protección adicional.
2.5.4.3.4. Opciones de administración de recursos
El demonio
xinetd puede ofrecer un nivel de protección básico para los ataques de Denegación de Servicio (DoS, por las iniciales en inglés 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 número máximo de instancias para un servicio desde cada dirección IP. Acepta solo valores enteros como argumentos y puede ser utilizada tanto enxinetd.confcomo en el archivo de configuración específico del servicio en cuestión del directorioxinetd.d/.cps— Establece el numero máximo de conexiones por segundo. Esta directiva necesita de dos argumentos enteros separados por un espacio. El primer argumento es el número máximo de conexiones permitidas por segundo al servicio. El segundo argumento es la cantidad de segundos quexinetddebe esperar antes de reactivar el servicio. Acepta solo enteros como argumentos y puede ser utilizado tanto en el archivoxinetd.conf, como el los archivos de configuración propios de cada servicio en el directorioxinetd.d/.max_load— Define la utilización del CPU o el umbral de carga de utilización promedio de un servicio. Acepta un número de punto flotante como argumento.La carga promedio es una medida aproximada que indica la forma en que algunos procesos están activos en un determinado período de tiempo. Para obtener mayor información acerca de la carga promedio, vea los comandosuptime,who, yprocinfo
Existen otras opciones disponibles para la administración de los recursos para
xinetd. Para obtener mayor información, consulte la página man de xinetd.conf.
2.5.5. Recursos adicionales
Mayor información acerca de los encapsuladores TCP y
xinetd se encuentra disponible en Internet y en la documentación del sistema.
2.5.5.1. Documentación instalada acerca de los encapsuladores TCP
La documentación de su sistema es un buen lugar en donde empezar a buscar opciones adicionales de configuración para los encapsuladores TCP,
xinetd, y control de acceso.
/usr/share/doc/tcp_wrappers-— Este directorio contiene un archivo<version>/READMEen el que se explica cómo funcionan los encapsuladores TCP, y algunos de los muchos riesgos de suplantación de identidad que existen para los nombres de los equipos y sus direcciones./usr/share/doc/xinetd-— Este directorio contiene un archivo<version>/READMEen el que se detallan aspectos relacionados con el control de acceso, y un archivosample.conf, con varias ideas para modificar los archivos de configuración propios para cada servicio que se encuentran en el directorio/etc/xinetd.d/.- Páginas man relacionadas con encapsuladores TCP y
xinetd— Existen una cantidad de páginas man para varias aplicaciones y archivos de configuración relacionadas con encapsuladores TCP yxinetd. Las siguientes con algunas de las más importantes:- Aplicaciones de servidor
man xinetd— La página man paraxinetd.
- Archivos de configuración
man 5 hosts_access— La página man para los archivos de control de acceso de equipos con encapsuladores TCP.man hosts_options— La página man para los campos de opción de los encapsuladores TCP.man xinetd.conf— La página man que ofrece opciones de configuración paraxinetd.
2.5.5.2. Sitios web útiles relacionados con encapsuladores TCP
- http://www.xinetd.org/ — El sitio principal de
xinetd, que contiene archivos de configuración a modo de ejemplo, lista completa de herramientas, y una sección informativa de preguntas frecuentes (FAQ, por las iniciales en inglés 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 configuración de
xinetdestablecidos por defecto, de manera de poder alcanzar objetivos de seguridad específicos.
2.5.5.3. Libros relacionados
- Hacking Linux Exposed por Brian Hatch, James Lee, y George Kurtz; Osbourne/McGraw-Hill — Una herramienta de seguridad excelente con información acerca de encapsuladores TCP y
xinetd.
2.6. 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 están ejecutándose en una red, y la manera en que están siendo utilizados.
Y más aún, la autenticación de usuarios en los servicios de red pueden ser peligrosa cuando los métodos usados por el protocolo sean inherentemente inseguros, como lo demuestran los protocolos tradicionales FTP y Telnet, que transfieren contraseñas no encriptadas sobre la red.
Kerberos es una forma de eliminar la necesidad de protocolos que permitan métodos inseguros de autenticación, por lo que mejora la seguridad general de la red.
2.6.1. ¿Qué es Kerberos?
Kerberos es un protocolo de autenticación de red creado por el MIT (Massachusetts Institute of Technology), y utiliza una criptografía de llave simétrica [14] para autenticar a los usuarios de los servicios de red, lo que en pocas palabras significa que las contraseñas nunca son enviadas a través de la red.
Consecuentemente, cuando los usuarios se autentican con servicios de red usando Kerberos, los usuarios no autorizados que intenten averiguar las contraseñas monitoreando el tráfico de red son efectivamente bloqueados.
2.6.1.1. Ventajas de Kerberos
La mayoría de los servicios convencionales de red utilizan esquemas de autenticación basados en contraseñas. Estos esquemas piden que los usuarios se identifiquen en un servidor de red determinado mediante su nombre y contraseña. Desafortunadamente, la transmisión de los datos para la autenticación de muchos servicios no es encriptada. Para que este tipo de esquemas sean seguros, la red tiene que permanecer inaccesible a los usuarios extraños a ella, y todos los equipos y todos los usuarios pertenecientes deben ser considerados confiables.
Aún 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 de paquetes, también conocido como "rastreador" de paquetes, para interceptar nombres de usuario y contraseñas, comprometiendo las cuentas de usuario y la integridad de toda la infraestructura de seguridad.
El objetivo primario del diseño de Kerberos es eliminar la transmisión de contraseñas encriptadas en la red. Si se usa apropiadamente, Kerberos elimina efectivamente la amenaza de los husmeadores (sniffers) de paquetes en la red.
2.6.1.2. Desventajas de Kerberos
Aunque Kerberos elimina una amenaza de seguridad común y severa, puede ser difícil de implementar por una variedad de razones:
- Puede ser algo muy tedioso migrar las contraseñas de los usuarios de una base de datos UNIX estándar, como ser por ejemplo
/etc/passwdo/etc/shadowhacia una base de datos para contraseñas Kerberos, ya que no hay ningún mecanismo automatizado para realizar esta tarea. Consulte la pregunta 2.23 en el FAQ en línea de Kerberos: - Kerberos sólo tiene compatibilidad parcial con el sistema PAM de módulos de autenticación conectables, utilizado por la mayoría de los servidores Fedora. Vaya a la Sección 2.6.4, “Kerberos y PAM” para más información 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 transmisión en la red de contraseñas no encriptadas. Sin embargo, si alguien más tiene acceso al único equipo que envía los comprobantes utilizados para la autenticación — denominado el centro de distribución de claves (KDC, por las siglas en inglés de Key Distribution Center) —, además del usuario correspondiente, entonces todo el sistema de autenticación Kerberos está corriendo riesgo.
- Para que una aplicación 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 problemático debido al tamaño de la aplicación o debido a su diseño. 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 programación extensa. Las aplicaciones de código propietario que no tienen soporte para Kerberos por defecto, son por lo general las más problemáticas.
- Kerberos es una herramienta de tipo "todo o nada". Si Kerberos es utilizado en la red, cualquier contraseña 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 contraseñas no encriptadas, o que no utilicen ninguna de este tipo de aplicaciones.
2.6.2. Terminología de Kerberos
Kerberos tiene su propia terminología para definir varios aspectos del servicio. Antes de aprender cómo funciona Kerberos, es importante conocer algunos de los siguientes términos:
- Servidor de autenticación (SA)
- Un servidor que envía comprobantes (o tickets) para un servicio determinado, comprobantes que en su momento serán enviados a los usuarios para que puedan acceder a ese servicio. El AS responde con una petición a las solicitudes de los clientes que, o no tienen o no han enviado sus credenciales de autenticación. Generalmente, para tener acceso al servidor que emite las garantías de los comprobantes (TGS, por las siglas en inglés de Ticket-Granting Server), se envía un comprobante de obtención de garantía de comprobante (TGT, Ticket-Granting Ticket). Por último, el AS generalmente se ejecuta en el mismo equipo que el centro de distribución de claves (KDC, Key Distribution Center).
- ciphertext
- Datos encriptados.
- cliente
- Una entidad en la red (un usuario, equipo o aplicación) que puede recibir tickets desde Kerberos.
- credenciales
- Un conjunto de credenciales electrónicas temporales que verifican la identidad de un cliente para un servicio particular. También 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 más completamente soportados.
- hash de encriptado
- Un hash de una vuelta se usa para autenticar los usuarios. Estos son más seguros que usar datos no encriptados, pero todavía son relativamente fáciles de desencriptar para craqueadores experimentados.
- GSS-API
- La Interfaz del Programa de la Aplicación de Servicios Generales de Seguridad (API, por las siglas en inglés 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 Ingeniería de Internet. La API es utilizada por servicios y clientes para autenticarse mutuamente sin que sus programas posean conocimientos específicos de los mecanismos subyacentes. Si un servicio de red (como por ejemplo cyrus-IMAP) utiliza GSS-API, entonces puede autenticarse mediante Kerberos.
- hash
- También conocido como valor hash. Un valor generado por el paso de una cadena a través de una función hash. Estos valores son típicamente usados para asegurar que los datos transmitidos no fueron interceptados y modificados.
- función hash
- Una forma de generar una "huella digital" desde los datos de entrada. Estas funciones reordenan, trasponen o alteran de otras formas para producir un valor hash.
- clave
- 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.
- centro de distribución de claves (KDC)
- Un servicio que emite tickets de Kerberos, y que usualmente corre en el mismo equipo que el servidor de garantía 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
kinitpermite a un principal que ya ingresó obtener y hacer caché del ticket inicial de garantía de tickets (TGT). Vaya a la página man dekinitpara más información. - principal (o nombre principal)
- El principal es el nombre único de un servicio o de un usuario al que le es permitido autenticarse mediante Kerberos. El principal tiene la forma de
root[/instance]@REALM. Para un usuario típico, el root es el mismo que su ID de inicio de sesión. Lainstancees opcional. Si el principal tiene una instancia, será diferenciada del root con una barra invertida ("/"). Una cadena vacía ("") es considerada una instancia válida (que difiere de la instanciaNULLestablecida por defecto), pero utilizarla puede llegar a ser confuso. Todos los principales de un dominio poseen su propia clave, que para los usuarios es derivada desde una contraseña, o es un conjunto de servicios aleatorios. - reinado
- Una red que use Kerberos, compuesta de uno o más servidores llamados KDCs y un número potencialmente grande de clientes.
- servicio
- Un programa accedido por la red.
- ticket
- Un conjunto temporal de credenciales electrónicas que verifican la identidad de un cliente para un servicio particular. También llamados credenciales o comprobantes.
- servidor de garantías 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 garantía de ticket (TGT)
- Un ticket especial que permite al cliente obtener tickets adicionales sin aplicar nuevamente en el KDC.
- contraseña no encriptada
- Una contraseña en texto plano, legible al humano.
2.6.3. Como Funciona Kerberos
Kerberos se diferencia de los métodos de autenticación de tipo nombre de usuario/contraseña. En lugar de autenticar cada usuario en cada servicio de red, Kerberos utiliza encriptaciones simétricas y un servicio adicional confiable (un KDC), para autenticar usuarios en conjunto de servicios de red. Cuando un usuario se autentica en el KDC, el KDC devuelve a la máquina del usuario en cuestión un comprobante específico para esa sesión, y cualquier servicio kerberizado busca el comprobante en la máquina del usuario, en lugar de pedir que el usuario se autentique utilizando una contraseña.
Cuando un usuario kerberizado de una red se loguea en su estación de trabajo, su principal es enviado al KDC como parte de un pedido para un TGT del servidor de Autenticación. 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.
El KDC entonces verifica con el principal en su base de datos. Si el principal es encontrado, el KDC crea un TGT, que se encripta usando la clave del usuario y se lo devuelve a ese usuario.
El login, o programa
kinit en el cliente, se encarga de desencriptar el TGT utilizando la clave del usuario, que se analiza desde la contraseña del usuario. La clave del usuario es utilizada sólo en la máquina cliente y no se transmite en la red.
El TGT es configurado para que caduque en un determinado período de tiempo (generalmente de diez a veinticuatro horas), y es almacenado en el caché de credenciales en la máquina del cliente. Un tiempo de expiración es definido para que, en el supuesto caso que exista un TGT vulnerado, pueda ser utilizado por un atacante sólo durante un breve período de tiempo. Luego que se ha emitido un TGT, el usuario no necesita reingresar su contraseña hasta que este no expire, o hasta que haya finalizado su sesión, y haya vuelto a iniciarla.
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 específicamente para ese servicio. El comprobante del servicio es entonces utilizado para autenticar de manera transparente al usuario frente al servicio en cuestión.
Advertencia
El sistema Kerberos puede ser vulnerado si un usuario en la red se autentica frente a un servicio no kerberizado transmitiendo una contraseña con formato de texto simple. La utilización de servicios no kerberizados es altamente desalentada. Entre tales servicios se encuentra Telnet y FTP. Es preferible la utilización de otros protocolos encriptados, como servicios asegurados mediante SSH o SSL, aunque no es lo ideal.
Este es solamente una presentación general de cómo funciona la autenticación de Kerberos. Vaya a la Sección 2.6.10, “Recursos adicionales” para conocer otros enlaces hacia información más detallada.
Nota
Kerberos depende de los siguientes servicios de red para funcionar correctamente.
- Sincronización de reloj aproximado entre las máquinas de la red.Un programa de sincronización de relojes debería ser configurado para la red, como por ejemplo
ntpd. Consulte/usr/share/doc/ntp-para obtener más detalles acerca de cómo definir servidores de Protocolos de Horarios de Red (donde<version-number>/index.html<version-number>) es el número de versión del paquetentpinstalado en su sistema). - Servicio de Nombre de Dominio (DNS).Debe asegurarse que las entradas DNS y los equipos en la red se encuentren todos configurados adecuadamente. Vea Kerberos V5 System Administrator's Guide en
/usr/share/doc/krb5-server-para obtener más información, (donde<version-number><version-number>es el número de versión del paquetekrb5-serverinstalado en su sistema).
2.6.4. Kerberos y PAM
Los servicios kerberizados actualmente no utilizan módulos de autenticación conectables (PAM, por las siglas en inglés 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 módulo
pam_krb5 (provisto en el paquete pam_krb5) se encuentra instalado. El paquete pam_krb5 contiene archivos de ejemplos de configuración que permiten que servicios como login o gdm puedan autenticar usuarios al mismo tiempo que obtienen credenciales de inicio utilizando sus contraseñas. 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 precaución de no permitir que los usuarios se autentiquen a determinados servicios de red, utilizando contraseñas Kerberos. Muchos protocolos utilizados por estos servicios no encriptan las contraseñas antes de enviarlas a través de la red, destruyendo los beneficios del sistema Kerberos. Por ejemplo, los usuarios no deberían tener permitido autenticarse a servicios Telnet con la misma contraseña que utilizan para la autenticación en Kerberos.
2.6.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:
- Asegúrese que la sincronización de hora y DNS estén funcionando correctamente en todos los clientes y máquinas del servidor antes de continuar Kerberos. Preste una atención especial a la sincronización 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 no podrán autenticarse en el servidor. Esta sincronización es necesaria para prevenir que un atacante utilice un comprobante antiguo de Kerberos enmascarado como el de un usuario válido.Es recomendable configurar una red cliente/servidor compatible con el Protocolo de Horario de Red (NTP, por las siglas en inglés de Network Time Protocol), aún cuando no se esté utilizando Kerberos. Fedora incluye el paquete
ntppara este propósito. Consulte/usr/share/doc/ntp-(donde<version-number>/index.html<version-number>es el número de versión del paquetentpinstalado en su sistema) para conocer detalles acerca de cómo configurar servidores con Protocolos de Horario de Red, o http://www.ntp.org, para obtener más información acerca de NTP. - Instale los paquetes
krb5-libs,krb5-serverykrb5-workstationen la máquina dedicada que correrá KDC. Esta máquina necesita ser muy segura — si es posible, no debe correr ningún otro servicio más que KDC. - Edite los archivos de configuración
/etc/krb5.confy/var/kerberos/krb5kdc/kdc.confpara reflejar el nombre del reinado y los mapeos dominio-a-reinado. Un reinado simple puede ser construido reemplazando instancias deEJEMPLO.COMyejemplo.comcon el nombre correcto del dominio — siendo seguro mantener la forma correcta de los nombres en mayúscula y en mínuscula — y cambiando el KDC dekerberos.elemplo.comal nombre del servidor kerberos. Por convención, todos los nombres de reinados se escriben en mayúsculas, y todos los nombres de equipos y de dominios DNS en minúsculas. Para obtener información detallada acerca de los formatos de estos archivos de configuración, consulte sus respectivas páginas man. - Genere la base de datos usando el utilitario
kdb5_utildesde una terminal:/usr/kerberos/sbin/kdb5_util create -s
El comandocreategenera la base de datos que almacena las clves para el reinado de Kerberos. El interruptor-sobliga a la creación 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 contraseña principal del servidor (que puede ser utilizada para generar nuevamente la clave) cada vez que se inicie. - Edite el archivo
/var/kerberos/krb5kdc/kadm5.acl. Este archivo es usado porkadmindpara determinar qué principales tienen acceso administrativo a la base de datos de Kerberos y sus niveles de acceso. La mayoría de las organizaciones pueden obtenerlo por una única línea:*/admin@EJEMPLO.COM *
La mayoría de los usuarios se representan en la base de datos por un principal único (con una instancia NULL, o vacía, tal como juan@EJEMPLO.COM). En esta configuración, los usuarios con un segundo principal con una instancia de admin (por ejemplo, juan/admin@EJEMPLO.COM) pueden manejar con poder completo sobre el reinado de la base de datos de Kerberos.Después de que se iniciekadminden el servidor, cualquier usuario puede acceder sus servicios ejecutandokadminen cualquier cliente o servidores en el reino. Sin embargo, sólo los usuarios listados en el archivokadm5.aclpueden modificar la base de datos de ninguna forma, excepto para cambiar sus propias contraseñas.Nota
La herramientakadminpermite la comunicación con el servidorkadminda través de la red, y utiliza kerberos para manipular la autenticación. Consecuentemente, el primer principal debe existir previamente antes de intentar conectarse con el servidor a través de la red para administrarlo. Genere el primer principal con el comandokadmin.local, que ha sido específicamente diseñado para ser utilizado en el mismo equipo en el que funciona el KDC, y no utiliza Kerberos para su autenticación.Ingrese el comando siguientekadmin.localen la terminal KDC para crear el primer principal:/usr/kerberos/sbin/kadmin.local -q "addprinc
nombreusuario/admin" - Inicie Kerberos usando los siguientes comandos:
/sbin/service krb5kdc start /sbin/service kadmin start /sbin/service krb524 start
- Agregue principales para los usuarios mediante el comando
addprincdentro dekadmin.kadminykadmin.localson interfaces de líneas de comando al KDC. Como este, existen disponibles otros comandos — como por ejemploaddprinc— luego de iniciar el programakadmin. Para obtener mas información, consulte la página man dekadmin. - Verifique que KDC está emitiendo tiques. Primero, corra
kinitpara obtener un tique y guardarlo en un archivo cache de credencial. Luego, useklistpara ver la lista de credenciales en el caché y usekdestroypara destruir el caché y las credenciales que contiene.Nota
Por defecto,kinitintenta autenticarse utilizando el mismo nombre de usuario del de inicio de sesión (no el del servidor Kerberos). Si ese nombre de usuario no se corresponde con un principal en la base de datos de Kerberos,kinitenvía un mensaje de error. Si eso sucede, indiquele akinitel nombre del principal correcto, como un argumento en la línea de comando (kinit).<principal>
Una vez que estos pasos sean completados, el servidor Kerberos ya debería estar listo y ejecutándose.
2.6.6. Configuración de un Cliente Kerberos 5
Configurar un cliente de Kerberos 5 es menos complicado que configurar un servidor. Como mínimo, instale los paquetes del cliente y otórguele a cada cliente un archivo de configuración
krb5.conf válido. Mientras que ssh y slogin son los métodos 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 configuración.
- Asegúrese que la sincronización del tiempo existe entre el cliente Kerberos y KDC. Vaya a Sección 2.6.5, “Configurando un servidor Kerberos 5” para más información. Además, verifique que el DNS está funcionando apropiadamente en el cliente Kerberos antes de continuar con los programas cliente de Kerberos.
- Instale los paquetes
krb5-libsykrb5-workstationen todas las máquinas clientes. Provea un archivo/etc/krb5.confválido para cada cliente (normalmente este puede ser el mismo archivokrb5.confusado por el KDC). - Antes que una estación de trabajo del reinado pueda utilizar a Kerberos para autenticar los usuarios que se conectan mediante
ssh, o mediante losrshorloginKerberizados, debe tener su propio equipo principal en la base de datos de Kerberos. Los programas de servidorsshd,kshd, yklogind, necesitan todos acceder a las llaves para los servicios del host principal. Además, para poder utilizar los servicios kerberizadosrshyrlogin, esa estación de trabajo debe tener el paquetexinetdinstalado.Al utilizarkadminse agrega un principal de equipo para la estación de trabajo en el KDC. En este caso, la instancia es el nombre del equipo de la estación de trabajo. Utilice la opción-randkeypara el comandoaddprincdekadmin, para crear el principal y asignarle una llave en forma azarosa:addprinc -randkey host/
bla.ejemplo.comAhora que se ha creado el principal, las claves se pueden extraer para la estación trabajo ejecutandokadminen la misma estación de trabajo y usando el comandoktadddentro dekadmin:ktadd -k /etc/krb5.keytab host/
bla.ejemplo.com - Para usar otros servicios de red kerberizados, primero deben iniciarse. A continuación mostramos una lista de los servicios kerberizados comunes y las instrucciones acerca de cómo habilitarlos:
ssh— OpenSSH usa GSS-API para autenticar los usuarios en los servidores si la configuración del cliente y del servidor tienen ambasGSSAPIAuthenticationhabilitado. Si el cliente tiene tambiénGSSAPIDelegateCredentialshabilitado, las credenciales del usuario se hacen disponibles en el sistema remoto.rshyrlogin— Para usar las versiones kerberizadas dershyrlogin, habiliteklogin,ekloginykshell.- Telnet — Para usar Telnet kerberizado, debe habilitar
krb5-telnet. - FTP — Para proveer acceso FTP, crear y extraer una clave para el principal con una raíz de
ftp. Asegúrese de poner la instancia al nombre de equipo completo del servidor FTP, luego habilitegssftp. - IMAP — Para utilizar un servidor kerberizado IMAP, el paquete
cyrus-imaputilizará Kerberos 5, si también se encuentra instalado el paquetecyrus-sasl-gssapi. El paquetecyrus-sasl-gssapicontiene el complemento Cyrus SASL que tiene soporte para autenticación GSS-API. Cyrus IMAP debería funcionar correctamente con Kerberos siempre y cuando el usuariocyrussea capaz de encontrar la clave correspondiente en/etc/krb5.keytab, y que la raíz para el principal esté definida paraimap(creada conkadmin).Una alternativa acyrus-imapse puede encontrar en el paquetedovecot, que también se incluye en Fedora. Este paquete contiene un servidor IMAP pero no da soporte a GSS-API y Kerberos por el momento. - CVS — Para usar un servidor CVS kerberizado,
gserverusa un principal con una raíz decvsy por lo demás es idéntico al servidor CVSpserver.
2.6.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 más 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 mayúsculas.
foo.ejemplo.org → EJEMPLO.ORG
foo.ejemplo.com → EJEMPLO.COM
foo.hq.ejemplo.com → HQ.EJEMPLO.COM
En algunas configuraciones esto será suficiente, pero en otras, el nombre del reinado derivado será el nombre de un reinado no existente. En estos casos, el mapeo desde el nombre del dominio DNS del servidor, hacia su reinado, debe estar especificado en la sección domain_realm del sistema
krb5.conf del cliente. Por ejemplo:
[domain_realm] .ejemplo.com = EJEMPLO.COM ejemplo.com = EJEMPLO.COM
En la configuración de arriba se especifica dos mapeos. El primero especifica que cualquier sistema en el dominio de DNS "ejemplo.com" pertenecen al reinado EJEMPLO.COM. El segundo especifica que el nombre exacto "ejemplo.com" está también en el reinado. (La distinción entre el dominio y un equipo específico se marca por la presencia o ausencia del "." inicial.) El mapeo también se puede almacenar directamente en el DNS.
2.6.8. Configurando KDCs secundarios
Por diversas razones, usted puede elegir ejecutar varios KDCs para un reinado dado. En este escenario, un KDC (el KDC maestro) conserva una copia modificable de la base de datos del reinado, y ejecuta
kadmind (que también es el admin server de su reinado), y uno o más KDCs (esclavos) conservan copias de solo lectura de la base de datos, y ejecutan kpropd.
El procedimiento de propagación 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 sólo lectura de la base de datos recibidas antes, con el contenido del archivo de volcado.
Para configurar un KDC esclavo, primero asegúrese que los archivos
krb5.conf y kdc.conf del KDC maestro fueron copiados al KDC esclavo.
Inicie
kadmin.local desde una consola raíz en el KDC maestro, y utilice su comando add_principal para crear una nueva entrada para el servicio host del KDC maestro, y luego utilice su comando ktadd para definir una llave aleatoria para el servicio, y al mismo tiempo almacenarla en el archivo keytab establecido por defecto. Esta llave será utilizada por el comando kprop para autenticarse a los servidores esclavos. Usted necesitará hacer esto sólo una vez, sin importar la cantidad de servidores esclavos que tenga instalados.
#kadmin.local -r EXAMPLE.COMAuthenticating as principal root/admin@EXAMPLE.COM with password.kadmin:add_principal -randkey host/masterkdc.example.comPrincipal "host/host/masterkdc.example.com@EXAMPLE.COM" created.kadmin:ktadd host/masterkdc.example.comEntry 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
Inicie
kadmin como usuario root desde una terminal en el KDC esclavo, y utilice el comando add_principal para crear una nueva entrada para su servicio host. Luego utilice el comando ktadd, de kadmin, para establecer (y al mismo tiempo almacenar) en el archivo keytab del esclavo, una llave aleatoria para el servicio. Esta llave es utilizada por el servicio kpropd cuando se necesite autenticar a los clientes.
#kadmin -p jimbo/admin@EXAMPLE.COM -r EXAMPLE.COMAuthenticating as principal jimbo/admin@EXAMPLE.COM with password.Password for jimbo/admin@EXAMPLE.COM:kadmin:add_principal -randkey host/slavekdc.example.comPrincipal "host/slavekdc.example.com@EXAMPLE.COM" created.kadmin:ktadd host/slavekdc.example.com@EXAMPLE.COMEntry 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
Con la clave de este servicio, el KDC esclavo puede autenticar a cualquier cliente que intente conectarse a él. Obviamente, no a todos ellos debería permitírsele proveer el servicio esclavo
kprop con una nueva base de datos del reinado. Para restringir el acceso, el servicio kprop en el KDC esclavo solo aceptará actualizaciones de clientes cuyos nombre de principal estén listados en /var/kerberos/krb5kdc/kpropd.acl. Agregue el nombre del equipo KDC maestro a esa lista.
# echo equipo/kdcmaestro.ejemplo.com@EJEMPLO.COM > /var/kerberos/krb5kdc/kpropd.acl
Una vez que el KDC esclavo haya obtenido una copia de la base de datos, necesitará también la clave maestra que ha sido utilizada para encriptarlo. Si la llave maestra de su base de datos KDC ha sido almacenada en un archivo stash del KDC maestro (generalmente denominada
/var/kerberos/krb5kdc/.k5.REALM), cópiela en el KDC esclavo utilizando cualquier método disponible que sea seguro, o cree una base de datos y un archivo escondite falsos en el KDC esclavo ejecutando kdb5_util create -s (la base de datos falsa será sobreescrita con la primera propagación de base de datos que sea exitosa), e indicando la misma contraseña.
Asegúrese que el cortafuego del KDC esclavo permite al KDC maestro contactarlo usando el puerto 754 con TCP (krb5_prop), e inicie el servicio
kprop. Luego, vuelva a chequear si el servicio kadmin está deshabilitado.
Ahora realice una prueba manual de propagación 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 sólo 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 periódicamente.
2.6.9. Configurando la autenticación cruzada de reinados
La autenticación cruzada de reinado es el término usado para describir situaciones en que los clientes (normalmente usuarios) de un reinado utilizan Kerberos para autenticarse con servicios (típicamente procesos servidor corriendo en un sistema servidor particular) que pertenecen a otro reinado distinto al propio.
Para el caso más 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 número de versión de clave asociadas a ellas.
Para hacer esto, debe seleccionar una contraseña o frase de acceso muy fuerte y crear una entrada para el principal de ambos reinados usando kadmin.
# kadmin -r A.EXAMPLE.COMkadmin: add_principal krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COMEnter 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.COMkadmin: add_principal krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COMEnter 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 número de versión de claves (valores kvno) y tipos de encriptados coincidentes.
El volcado de la base de datos no lo hace
Los administradores conscientes de los procesos de seguridad, podrían intentar utilizar la opción
-randkey del comando add_principal, para asignar una clave aleatoria en lugar de una contraseña, descargar la nueva entrada desde una base de datos del primer reinado, e importarla al segundo. Esto no va a funcionar a menos que las claves maestras de la base de datos del reinado sean idénticas, ya que las claves contenidas en una base de datos descargada, son encriptadas utilizando la clave maestra.
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 confía en el reinado A.EJEMPLO.COM, o, más sencillo aún, ahora B.EJEMPLO.COM confía 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 podría confiar en clientes del reinado A.EJEMPLO.COM para autenticarse en sus servicios, pero este hecho no significa que el reinado A.EJEMPLO.COM confíe 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).
Si las relaciones de confianza directa fueran la única manera de hacer que dos reinados confíen entre sí, sería bastante complicado configurar redes con gran cantidad de ellos. Afortunadamente, la confianza generada entre reinados es transitiva. Si los clientes del reinado
A.EJEMPLO.COM pueden autenticarse en servicios del reinado B.EJEMPLO.COM, y los clientes del reinado B.EJEMPLO.COM pueden autenticarse en servicios del reinado C.EJEMPLO.COM, entonces los clientes de A.EJEMPLO.COM pueden también autenticarse en los servicios del reinado C.EJEMPLO.COM, aún cuando C.EJEMPLO.COM no confíe directamente en los clientes del reinado A.EJEMPLO.COM. Esto significa que lo ideal para poder reducir la cantidad de esfuerzo al configurar una red con múltiples reinados, que necesiten confiar unos en otros, será realizar las elecciones correctas a la hora de definir las relaciones de confianza entre ellos.
Ahora se enfrenta a problemas más convencionales: el sistema cliente debe ser configurado para que pueda deducir apropiadamente el reinado al que un servicio particular pertenece, y debe poder determinar cómo obtener las credenciales en ese reinado.
Vayamos en orden: el nombre del principal para un servicio provisto desde un sistema servidor específico en un reinado dado normalmente es parecido a:
service/server.ejemplo.com@EJEMPLO.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 sección
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 autenticación con el servicio.
Esto se puede hacer de una o dos formas.
El método establecido por defecto, que no requiere una configuración explícita, es dar a los reinados nombres dentro de una jerarquía 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.
En este escenario el cliente trata el nombre del dominio como uno podría tratar un nombre DNS. Reiteradamente va quitando los componentes de su propio nombre de reinado para generar los nombres del reinado que se encuentre jerárquicamente "por encima del suyo", hasta que llegue a un punto que incluso sea jerárquicamente superior al reinado del servicio. En ese punto empieza a analizar los componentes del nombre del servicio del reinado, hasta que obtiene el servicio del reinado. Cada reinado que se encuentre involucrado en el proceso, es considerado otro "salto".
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.COMyEJEMPLO.COMcomparten una clave parakrbtgt/EJEMPLO.COM@A.EJEMPLO.COMEJEMPLO.COMyB.EJEMPLO.COMcomparten una clavekrbtgt/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.COMyVENTAS.EJEMPLO.COMcomparten una clave parakrbtgt/VENTAS.EJEMPLO.COM@SITIO1.VENTAS.EJEMPLO.COMVENTAS.EJEMPLO.COMyEJEMPLO.COMcomparten una clave parakrbtgt/EJEMPLO.COM@VENTAS.EJEMPLO.COMEJEMPLO.COMyCUALQUIERLUGAR.EJEMPO.COMcomparten una clave parakrbtgt/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.COMyEJEMPLO.COMcomparten una clave parakrbtgt/EJEMPLO.COM@DEVEL.EJEMPLO.COMEJEMPLO.COMyCOMcomparten una clave parakrbtgt/COM@EJEMPLO.COMCOMyORGcomparten una clave parakrbtgt/ORG@COMORGyEJEMPLO.ORGcomparten una clave parakrbtgt/EJEMPLO.ORG@ORGEJEMPLO.ORGyPROD.EJEMPLO.ORGcomparten una clave parakrbtgt/PROD.EJEMPLO.ORG@EJEMPLO.ORG
El método más complicado, pero que al mismo tiempo es el más flexible, reside en configurar la sección
capaths del archivo /etc/krb5.conf, de modo que los clientes que tengan credenciales para un reinado específico, deberán buscar qué reinado es el que le sigue en la cadena y que, eventualmente, será quien permita su autenticación con los servidores.
El formato de la sección
capaths es relativamente sencillo: cada entrada en la sección tiene el mismo nombre que el reinado en el que pudiera existir el cliente. Dentro de cada subsección, el conjunto de los reinados intermedios desde donde el cliente tiene que obtener las credenciales, se muestran como los valores de la llave que se corresponde con el reinado en el que puede residir el servicio. Si no existen reinados intermedios, será utilizado el valor ".".
Aquí hay un ejemplo:
[capaths]
A.EJEMPLO.COM = {
B.EJEMPLO.COM = .
C.EJEMPLO.COM = B.EJEMPLO.COM
D.EJEMPLO.COM = B.EJEMPLO.COM
D.EJEMPLO.COM = C.EJEMPLO.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, necesitarán 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, necesitarán 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 jerarquía.
Los clientes en el reinado
A.EJEMPLO.COM pueden obtener credenciales cruzadas del reinado B.EJEMPLO.COM directamente. Sin el "." indicando esto, el cliente intentaría sino usar un camino jerárquico, en este caso:
A.EXAMPLE.COM → EXAMPLE.COM → B.EXAMPLE.COM
2.6.10. Recursos adicionales
Para más información sobre Kerberos, consulte las fuentes que indicamos a continuación.
2.6.10.1. Documentación Instalada de Kerberos
- La Guía de Instalación de Kerberos V5 y la Guía del Administrador del Sistema Kerberos V5 en formatos PostScript y HTML. Pueden ser encontradas en el directorio
/usr/share/doc/krb5-server-(donde<version-number>/<version-number>es el número de versión del paquetekrb5-serverinstalado en su sistema). - La Guía del Usuario UNIX de Kerberos V5 en formatos PostScript y HTML. Pueden ser encontradas en el directorio
/usr/share/doc/krb5-workstation-(donde<version-number>/<version-number>es el número de versión del paquetekrb5-workstationinstalado en su sistema). - Páginas man de Kerberos — Hay un número de páginas man para las varias aplicaciones y archivos de configuración involucrados con una implementación de Kerberos. La siguiente es una lista de algunas de las páginas man más importantes.
- Aplicaciones cliente
man kerberos— Una introducción al sistema Kerberos que describe cómo funcionan las credenciales y provee recomendaciones para obtener y destruir tickets de Kerberos. Al final de la página man hay referencias hacia otras páginas man relacionadas con el tema.man kinit— Describe cómo usar este comando para obtener y hacer caché de un ticket de garantía de tickets.man kdestroy— Describe cómo usar este comando para destruir las credenciales de Kerberos.man klist— Describe cómo usar este comando para listar las credenciales cacheadas de Kerberos.
- Aplicaciones administrativas
man kadmin— Describe cómo usar este comando para administrar con la base de datos de Kerberos V5.man kdb5_util— Describe cómo 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 línea de comando del KDC de Kerberos V5.man kadmind— Describe las opciones de la línea de comando para el servidor de administración de Kerberos V5.
- Archivos de configuración
man krb5.conf— Describe el formato y las opciones disponibles dentro del archivo de configuración para la biblioteca de Kerberos V5.man kdc.conf— Describe el formato y las opciones disponibles dentro del archivo de configuración del AS y el KDC de Kerberos V5.
2.6.10.2. Páginas web útiles sobre Kerberos
- http://web.mit.edu/kerberos/www/ — Kerberos: El Protocolo de Autenticación 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 versión PostScript de Kerberos: Un Servicio de Untenticación 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 — Construyendo un sistema de Autenticación: Diálogo en Cuatro Escenas originalmente realizado por Bill Bryant en 1988, modificado por Theodore Ts'o en 1997. Este documento es una conversación entre dos desarrolladores que están pensando en la creación de un sistema de autenticación, con un estilo similar al de Kerberos. El estilo de diálogo con el que se muestra la discusión lo convierte en un excelente punto de partida para aquellos que no conozcan absolutamente nada acerca de Kerberos.
- http://www.ornl.gov/~jar/HowToKerb.html — Cómo Kerberizar su sitio es una buena referencia para kerberizar su red.
- http://www.networkcomputing.com/netdesign/kerb1.html — Manual de Diseño de Red con Kerberos es un repaso extenso sobre el sistema Kerberos.
2.7. Redes privadas virtuales (VPNs, por las iniciales en inglés de Virtual Private Networks)
Las organizaciones con diferentes oficinas satélites, a menudo se conectan entre ellas mediante líneas constituidas específicamente para proteger los datos vitales y asegurar la eficacia en su transferencia. Por ejemplo, muchos comercios utilizan líneas de frame relay o Modo de Transferencia no Sincronizada (ATM, por las iniciales en inglés 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 pequeñas o medianas empresas, que quieren expandirse sin tener que pagar los altos costos que involucra la utilización 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 inglés 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 utilización de datagramas como su medio de transporte, convirtiéndolas en un conducto seguro a través de Internet hacia un destino específico. La mayoría de las implementaciones VPN de software libre incorporan estándares abiertos de métodos de encriptación para, posteriormente, enmascarar los datos en tránsito.
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 implementación estandarizada del Protocolo de Seguridad de Internet (IPsec, por las iniciales en inglés de Internet Protocol Security). Estas herramientas VPN, ya sean derivadas de hardware o de software, trabajan como enrutadores especializados que existen entre la conexión IP desde una oficina hacia otra.
2.7.1. ¿Cómo funciona una VPN?
Cuando un paquete se transmite desde un cliente, se envía a través del enrutador o puerta de enlace VPN, que le añade un Encabezado de autenticación (AH, por las iniciales en inglés de Authentication Header) para su enrutamiento y autenticación. Los datos son entonces encriptados y, por último, empaquetados con una Carga Util de Seguridad por Encapsulado (ESP, por las inicales en inglés de Encapsulating Security Payload). Esto, más adelante, constituye las instrucciones de desencriptado y entrega.
El enrutador VPN que recibe los paquetes, quita la información de los cabezales, decripta los datos y los envía a su destinatario (ya sea una estación de trabajo u otro nodo en la red). Utilizando una conexión 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 conexión 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 además tiene que decriptarlo. Los intrusos que utilizan ataques de tipo intermediario entre un servidor y el cliente, deben tener también acceso a, como mínimo, una de las claves privadas para autenticar sesiones. debido a que se utilizan diferentes capas en el proceso de encriptación y decriptación, las VPNs son medios seguros y efectivos de conectar múltiples nodos remotos y poder actuar como una intranet unificada.
2.7.2. VPNs y Fedora
Fedora ofrece varias opciones en términos de implementar herramientas de software para conectarse de manera segura en una WAN. La utilización de Protocolos de Seguridad de Internet (IPsec), es la herramienta VPN para Fedora, y cubre adecuadamente las necesidades de las organizaciones que posean oficinas sucursales, o usuarios remotos
2.7.3. IPsec
Fedora ofrece soporte de IPsec para conectar equipos remotos y redes entre sí, utilizando un túnel seguro en un medio de transporte de red común, como lo es Internet. IPsec puede ser implementado utilizando una configuración de tipo equipo-a-equipo (una estación de trabajo con otra), o de tipo red-a-red (una LAN/WAN con otra).
La utilización de IPsec en Fedora utiliza Intercambio de Clave de Internet (IKE, por las iniciales en inglés de Internet Key Exchange), un protocolo implementado por el Equipo de Tareas de Ingeniería de Internet (IETF, por las iniciales en inglés de Internet Engineering Task Force), utilizado para autenticación mutua y asociaciones seguras entre sistemas conectados.
2.7.4. Creando una conexión IPsec
Una conexión IPsec está separada en dos etapas lógicas. En la primera etapa, un nodo IPsec inicia la conexión con el nodo remoto o la red. El nodo remoto o la red verifica las credenciales del nodo que hace la petición y ambas partes establecen un método de autenticación para la conexión.
En sistemas Fedora, una conexión IPsec utiliza un método de clave pre-compartida para la autenticación del nodo IPsec. En una conexión IPsec de este tipo, ambos equipos deben utilizar la misma clave para poder avanzar hacia la segunda etapa de la conexión IPsec.
La segunda etapa de la conexión IPsec consiste en la creación de una Asociación de seguridad (SA, por las iniciales en inglés de Security Association) entre los nodos IPsec. Esta etapa genera una base de datos SA con información de configuración, como el método de encriptado, los parámetros de intercambio de clave para la sesión secreta, y demás informaciones necesarias. Esta etapa administra la conexión IPsec actual entre los nodos remotos y las redes.
La implementación de IPsec en Fedora utiliza IKE para compartir claves entre equipos a través de Internet. El demonio para claves
racoon administra la distribución y el intercambio de clave IKE. Para obtener mayor información acerca de este demonio, vea la página man de racoon.
2.7.5. Instalación de IPsec
La implementación de IPsec necesita tener instalado el paquete RPM
ipsec-tools en todos los equipos IPsec (si es que se está utilizando una configuración de tipo equipo-a-equipo), o enrutadores (si es es que se está utilizando una configuración de tipo red-a-red). El paquete RPM contiene bibliotecas esenciales, demonios, y archivos de configuración para establecer la conexión IPsec, como por ejemplo:
/sbin/setkey— manipula la administración de clave y los atributos de seguridad para IPsec en el kernel. Este ejecutable es controlado por el demonio de administración de claveracoon. Para obtener mayor información, consulte la página man número 8 desetkey./usr/sbin/racoon— el demonio de administración 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 configuración del demonioracoonutilizado para configurar varios aspectos de la conexión IPsec, incluyendo los métodos de autenticación y los algoritmos de encriptado utilizados en ella. Para conocer una lista con todas las directivas, consulte la página man número 5 deracoon.conf.
Para configurar IPsec en Fedora, puede utilizar la Herramienta Administración de Red, o editar manualmente la red y los archivos de configuración de IPsec.
- Para conectar dos equipos en red utilizando IPsec, vea la Sección 2.7.6, “Configuración de IPsec equipo-a-equipo”.
- Para conectar una LAN/WAN con otra utilizando IPsec, vea la Sección 2.7.7, “Configuración IPsec red-a-red”.
2.7.6. Configuración de IPsec equipo-a-equipo
IPsec puede configurarse para conectar un equipo de escritorio o estación de trabajo con otro mediante una conexión de tipo equipo-a-equipo. Este tipo de conexión utiliza la red a la que cada uno de los equipos se conecta para crear un túnel seguro entre cada equipo. Los requerimientos de una conexión de equipo-a-equipo son mínimos, al igual que la configuración de IPsec. El equipo necesita solo una conexión dedicada a una red que haga de medio de transporte (como lo es Internet) y Fedora para crear la conexión IPsec.
2.7.6.1. Conexión equipo-a-equipo
Una conexión de tipo equipo-a-equipo es una conexión encriptada entre dos sistemas, ambos utilizando IPsec con la misma clave de autenticación. Con la conexión IPsec activa, cualquier tráfico de red entre los dos equipos es encriptada.
Para configurar una conexión IPsec de tipo equipo-a-equipo, siga los siguientes pasos para cada equipo:
Nota
Debería realizar los siguientes procedimientos en la máquina actual que está configurando. Evite intentar establecer o configurar conexiones IPsec remotamente.
- En una terminal, ingrese
system-config-networkpara iniciar la Herramienta de administración de red. - En la pestaña de IPsec, haga clic en para iniciar el asistente de configuración de IPsec.
- haga clic en para iniciar la configuración de una conexión IPsec de equipo-a-equipo.
- Ingrese un nombre único para la conexión, por ejemplo,
ipsec0. Si lo necesita, tilde la casilla para activar automáticamente la conexión cada vez que encienda el equipo. Haga clic en para continuar. - Seleccione Encriptado de equipo a equipo como el tipo de conexión, y luego haga clic en .
- Seleccione el tipo de método de encriptado a utilizarse: manual o automático.Si selecciona encriptado manual, deberá indicar más adelante una clave de encriptado. Si selecciona encriptado automático, el demonio
racoonse encarga de administrar la clave del encriptado. El paqueteipsec-toolsdebe estar instalado si quiere utilizar la encriptación automática.Haga clic en para continuar. - Ingrese la dirección IP de equipo remoto.Para determinar la dirección IP del equipo remoto, utilice el siguiente comando en el equipo remoto:
[root@myServer ~] # /sbin/ifconfig
<device>donde<device>es el dispositivo Ethernet que quiere utilizar para la conexión VPN.Si solo existe una tarjeta Ethernet en el sistema, el nombre del dispositivo seguramente será eth0. El siguiente ejemplo muestra la información pertinente de este comando (recuerde que ese es sólo 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.0La dirección IP es el número siguiente a la etiquetainet addr:.Nota
Para conexiones de tipo equipo-a-equipo, los dos equipos deberían tener una dirección pública enrutable. Alternativamente, los dos equipos pueden tener una dirección 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 dirección pública y el otro una dirección privada, vea la Sección 2.7.7, “Configuración IPsec red-a-red”.Haga clic en para continuar. - Si en el paso 6 se ha seleccionado una encriptación manual, especifique la clave de encriptado a ser utilizada, o haga clic en para generar una.
- Indique una clave de autenticación o haga clic en para generar una. Puede ser una combinación de números y letras.
- Haga clic en para continuar.
- Verifique la información en la página IPsec — Resumen, y luego haga clic en el botón .
- Haga clic en => para guardar la configuración.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
- Seleccione la conexión IPsec de la lista y haga clic en el botón de .
- Repita el procedimiento entero para el otro equipo. Es fundamental que se utilice la misma clave del paso 8 en los demás equipos. De lo contrario, IPsec no funcionará.
Luego de configurar la conexión IPsec, aparecerá en la lista IPsec como se lo indica en la Figura 2.10, “Conexión IPsec”.
Conexión IPsec
Figura 2.10. Conexión IPsec
Los siguientes archivos son creados cuando la conexión IPsec es configurada:
/etc/sysconfig/network-scripts/ifcfg-<nickname>/etc/sysconfig/network-scripts/keys-<nickname>/etc/racoon/<ip-remota>.conf/etc/racoon/psk.txt
Si se elige encriptación automática, entonces también se crea el archivo
/etc/racoon/racoon.conf.
Cuando la interfaz esté funcionando, el archivo
/etc/racoon/racoon.conf se modifica para que pueda inlcuir a <remote-ip>.conf2.7.6.2. Configuración manual de una conexión IPsec de tipo equipo-a-equipo
El primer paso para crear una conexión es obtener información tanto del sistema como de la red para cada estación de trabajo. Para una conexión de tipo equipo-a-equipo, se necesita lo siguiente:
- La dirección IP de cada equipo
- Un nombre único, por ejemplo,
ipsec1. Esto es utilizado para identificar la conexión IP