Guía de seguridad
Una guía para la seguridad en Fedora Linux
Johnray Fuller
John Ha
David O'Brien
Scott Radvan
Eric Christensen
Adam Ligas
Guía de seguridad
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.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States
and/or other countries.
La Guía de Seguridad en Fedora está diseñada para asistir a usuarios de Fedora en el proceso de
aprendizaje y prácticas de seguridad en estaciones de trabajo y servidores, para poder así evitar
intrusiones locales y remotas, explotaciones, y actividades maliciosas. Enfocada en Fedora Linux
pero detallando conceptos y técnicas validas para todos los sistemas Linux. La Guía de Seguridad
en Fedora detalla la planificación y describe las herramientas involucradas en la creación de un
entorno de computación seguro, para centros de datos, estaciones de trabajo, o el hogar. Con un
conocimiento administrativo apropiado, vigilancia, y herramientas, los sistemas ejecutando Linux
pueden ser funcionales y al mismo tiempo seguros, frente a los métodos de intrusión y explotación
más comunes.
Prefacio vii
1. Convenciones del Documento ........................................................................................ vii
1.1. Convenciones Tipográficas .................................................................................. vii
1.2. Convenciones del documento ............................................................................. viii
1.3. Notas y Advertencias ........................................................................................... ix
2. ¡Necesitamos sus comentarios! ....................................................................................... ix
2. Asegurando su Red 25
2.1. Seguridad de la estación de trabajo ............................................................................ 25
2.1.1. Evaluación de la seguridad de la estación de trabajo ......................................... 25
2.1.2. Seguridad en el BIOS y en el gestor de arranque .............................................. 25
2.1.3. Seguridad de contraseñas ................................................................................ 28
2.1.4. Controles administrativos ................................................................................. 33
2.1.5. Servicios de red disponibles ............................................................................. 40
2.1.6. Cortafuegos personales ................................................................................... 44
2.1.7. Herramientas de comunicación de seguridad mejorada ...................................... 44
2.2. Seguridad del servidor ................................................................................................ 45
2.2.1. Asegurando los servicios con encapsuladores TCP y xinetd ............................... 45
2.2.2. Asegurando Portmap ....................................................................................... 49
2.2.3. Asegurando NIS .............................................................................................. 49
2.2.4. Asegurando NFS ............................................................................................. 52
2.2.5. Asegurando el servidor HTTP Apache .............................................................. 53
2.2.6. Asegurando FTP ............................................................................................. 54
2.2.7. Asegurando Sendmail ...................................................................................... 57
2.2.8. Verificar qué puertos están abiertos .................................................................. 58
2.3. Identificación única (SSO, por las iniciales en inglés de Single Sign-on) ......................... 59
2.3.1. Introducción ..................................................................................................... 59
2.3.2. Empezar a utilizar su nueva tarjeta inteligente ................................................... 61
2.3.3. Como funciona la inscripción de las tarjetas inteligentes. .................................... 62
2.3.4. Cómo funciona el ingreso con tarjeta inteligente ................................................ 63
iii
Guía de seguridad
iv
2.9.3. Guardando las reglas de IPTalbes .................................................................. 150
2.9.4. Programas de control de IPTables .................................................................. 150
2.9.5. IPTables e IPv6 ............................................................................................. 153
2.9.6. Recursos adicionales ..................................................................................... 153
3. Cifrado 155
3.1. Datos en reposo ....................................................................................................... 155
3.2. Cifrado completo del disco ........................................................................................ 155
3.3. Cifrado basado en archivo ........................................................................................ 155
3.4. Datos en movimiento ................................................................................................ 156
3.5. Redes privadas virtuales (VPNs) ............................................................................... 156
3.6. Shell seguro (SSH, por las iniciales en inglés de Secure Shell) .................................... 156
3.7. Cifrado de disco LUKS (Linux Unified Key Setup-on-disk-format) ................................. 157
3.7.1. Implementación de LUKS en Fedora ............................................................... 157
3.7.2. Cifrado manual de directorios ......................................................................... 157
3.7.3. Instrucciones paso a paso .............................................................................. 158
3.7.4. Lo que acaba de realizar ............................................................................... 158
3.7.5. Enlaces de interés ......................................................................................... 159
3.8. Archivos cifrados mediante 7-Zip ............................................................................... 159
3.8.1. Instalación de 7-Zip en Fedora ....................................................................... 159
3.8.2. Instrucciones paso a paso para su instalación ................................................. 159
3.8.3. Instrucciones paso a paso para su utilización .................................................. 159
3.8.4. Elementos para prestar atención .................................................................... 160
3.9. Utilizando GNU Privacy Guard (GnuPG) .................................................................... 160
3.9.1. Generando claves GPG en GNOME ............................................................... 160
3.9.2. Generar claves GPG en KDE ......................................................................... 161
3.9.3. Generar una clave GPG mediante la línea de comandos .................................. 161
3.9.4. Usando GPG con Alpine ................................................................................ 163
3.9.5. Usando GPG con Evolution ............................................................................ 163
3.9.6. Usando GPG con Thunderbird ....................................................................... 164
3.9.7. Acerca del encriptado de la clave pública ........................................................ 165
7. Referencias 173
v
Guía de seguridad
vi
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.
1
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.
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. Por ejemplo:
El ejemplo anterior incluye un nombre de archivo, un comando de shell y una tecla clave. Todo se
presenta en negrita-monoespaciado y distinguible gracias al contexto.
Las combinaciones de teclas se pueden distinguir de las teclas claves mediante el guión que conecta
cada parte de una combinación de tecla. Por ejemplo:
La primera oración resalta la tecla clave determinada que se debe pulsar. La segunda resalta dos
conjuntos de tres teclas claves que deben ser presionadas simultáneamente.
Si se discute el código fuente, los nombres de las clase, los métodos, las funciones, los nombres de
variables y valores de retorno mencionados dentro de un párrafo serán presentados en Negrita-
monoespaciado. Por ejemplo:
Negrita proporcional
Esta denota palabras o frases encontradas en un sistema, incluyendo nombres de aplicación, texto de
cuadro de diálogo, botones etiquetados, etiquetas de cajilla de verificación y botón de radio; títulos de
menú y títulos del sub-menú. Por ejemplo:
1
https://fedorahosted.org/liberation-fonts/
vii
Prefacio
El texto anterior incluye nombres de aplicación; nombres y elementos del menú de todo el sistema;
nombres de menú de aplicaciones específicas y botones y texto hallados dentro de una interfaz
gráfica de usuario, todos presentados en negrita proporcional y distinguibles por contexto.
Ya sea negrita monoespaciado o negrita proporcional, la adición de itálicas indica texto reemplazable
o variable. Las itálicas denotan texto que usted no escribe literalmente o texto mostrado que cambia
dependiendo de la circunstancia. Por ejemplo:
Observe las palabras en itálicas- negrita sobre — nombre de usuario, domain.name, sistema de
archivo, paquete, versión y lanzamiento. Cada palabra es un marcador de posición, tanto para el texto
que usted escriba al ejecutar un comando como para el texto mostrado por el sistema.
Aparte del uso estándar para presentar el título de un trabajo, las itálicas denotan el primer uso de un
término nuevo e importante. Por ejemplo:
viii
Notas y Advertencias
Los listados de código fuente también se muestran en romano monoespaciado, pero se presentan
y resaltan de la siguiente manera:
package org.jboss.book.jca.ex1;
import javax.naming.InitialContext;
System.out.println("Created Echo");
Nota
Una nota es una sugerencia, atajo o enfoque alternativo para una tarea determinada.
Ignorar una nota no debería tener consecuencias negativas, pero podría perderse de
algunos trucos que pueden facilitarle las cosas.
Importante
Important boxes detail things that are easily missed: configuration changes that
only apply to the current session, or services that need restarting before an update
will apply. Ignoring a box labeled 'Important' won't cause data loss but may cause
irritation and frustration.
Advertencia
Las advertencias no deben ignorarse. Ignorarlas muy probablemente ocasionará
pérdida de datos.
ix
Prefacio
Para proveer 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 para esta guía.
x
Resumen acerca de la 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.
http://law.jrank.org/pages/3791/Kevin-Mitnick-Case-1999.html
http://www.livinginternet.com/i/ia_hackers_levin.htm
1
Capítulo 1. Resumen acerca de la seguridad
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.
En el año 2007, una pérdida de datos permitió la explotación de una debilidad bien conocida en el
protocolo de cifrado inalámbrico 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
3
global.
En otro incidente, los registros de facturación de 2,2 millones de pacientes, almacenados en una cinta
4
de respaldo, fueron robados del asiento de un vehículo de cadetería.
Actualmente, se estima que 1,8 mil millones de personas usan o usaron Internet alrededor del mundo
5
. Al mismo tiempo:
• 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.
• El impacto económico a nivel mundial de los virus de Internet más peligrosos de los últimos tres
años se estimó en US$ 13.2 mil millones.
http://www.theregister.co.uk/2007/05/04/txj_nonfeasance/
http://www.healthcareitnews.com/story.cms?id=9408
http://www.internetworldstats.com/stats.htm
2
¿Qué es la seguridad en computación?
6
Del informe "El Estado Global de la Seguridad de la Información" , 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
• 44% de los encuestados planean incrementar sus gastos en seguridad en el año siguiente
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.
• 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.
http://www.csoonline.com/article/454939/The_Global_State_of_Information_Security_
3
Capítulo 1. Resumen acerca de la seguridad
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.
• 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.
• Guardias de la seguridad
• IDs de Imagen
• Biometría (incluye huellas digitales, voz, cara, iris, escritura manual y otros métodos automatizados
usados para reconocer a los individuos)
• Cifrado
4
Conclusión
• Tarjetas inteligentes
• Autenticación de red
• Capacitación y conocimientos
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.
• 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
5
Capítulo 1. Resumen acerca de la seguridad
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.
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.
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 interfaces 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. 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.
6
Definiendo evaluación y pruebas
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.
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.
7
Capítulo 1. Resumen acerca de la seguridad
¿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:
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.
8
Herramientas de evaluación
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 foo.example.com
Los resultados de un análisis básico (que puede demorarse unos minutos, de acuerdo al lugar en
donde se encuentre el equipo), deberían ser similares a los siguientes:
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:
http://www.insecure.org/
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.
9
Capítulo 1. Resumen acerca de la seguridad
Nota
Tanto el servidor como el cliente Nessus se encuentran disposnibles en los
repositorios de Fedora, pero para poder utilizarlos es necesario suscribirse. Se ha
incluido en este documento como una referencia para aquellos usuarios que 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:
http://www.nessus.org/
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.
http://www.cirt.net/code/nikto.shtml
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:
http://www.bindview.com/Support/Razor/Utilities/
10
Atacantes y vulnerabilidades
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.
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.
11
Capítulo 1. Resumen acerca de la seguridad
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.
12
Amenazas a la seguridad del servidor
Una ocurrencia 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 deseados,
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”.
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.
Vaya a la Sección 1.5, “Actualizaciones de seguridad” para más información sobre cómo mantener un
sistema actualizado.
13
Capítulo 1. Resumen acerca de la seguridad
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.
http://www.sans.org/resources/errors.php
14
Amenazas a las estaciones de trabajo y seguridad en equipos hogareños
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”.
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.
15
Capítulo 1. Resumen acerca de la seguridad
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.
16
Ataques y debilidades comunes
17
Capítulo 1. Resumen acerca de la seguridad
18
Actualizaciones de seguridad
Nota
Fedora incluye un ícono en panel que muestra una alerta cada vez que exista una
actualización disponible para el sistema.
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.
19
Capítulo 1. Resumen acerca de la seguridad
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):
Para mostrar una lista de todas las claves instaladas para la verificación de RPM, ejecute el siguiente
comando:
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:
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 llave GPG se verifica exitosamente, el comando devuelve gpg OK. Sino,
asegúrese de estar utilizando la llave pública correcta de Fedora, así como la fuente del contenido.
Los paquetes que no pasan las verificaciones GPG no deberían ser instalados, ya que podrían haber
sido alterados.
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.
En el ejemplo anterior, reemplace <kernel-package> 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 <old-kernel-package>
En el ejemplo anterior, reemplace <old-kernel-package> con el nombre del RPM del kernel viejo.
20
Aplicación de los cambios
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. Visite
Sección 1.5.4, “Aplicación de los cambios” para obtener instrucciones generales
sobre la aplicación de las modificaciones realizadas por una actualización de errata.
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 comando
lsof como en el siguiente ejemplo:
21
Capítulo 1. Resumen acerca de la seguridad
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 paquete tcp_wrappers es 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, y
xinetd.
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/
service como en el ejemplo siguiente:
En 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 xinetd solo se ejecutan cuando exista una
conexión activa. Ejemplos de servicios controlados por xinetd osn Telnet, IMAP, y POP3.
Debido a que xinetd inicia nuevas instancias de estos servicios cada vez que se reciba un
nuevo pedido, las conexiones que tengan lugar luego de una actualización serán administradas
por el software actualizado. Sin embargo, si existen conexiones activas en el momento en
que el servicio controlado por xinetd es actualizado, estas conexiones seguirán funcionando
controladas por la versión anterior.
Para detener instancias antiguas de un servicio particular controlado por xinetd, actualice el
paquete para el servicio, y luego detenga todos los procesos que se encuentren en ejecución.
Para determinar si el proceso está ejecutándose, utilice el comando ps y luego los comandos
kill o killall para detener las instancias actuales del servicio.
Por ejemplo, si los paquetes errata de seguridad imap son liberados, actualice los paquetes, y
luego, como usuario root, ingrese el siguiente comando en una terminal:
Este comando devuelve todas las sesiones IMAP activas. Las sesiones individuales pueden
determinarse con el siguiente comando:
kill <PID>
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 comando ps).
22
Aplicación de los cambios
Para detener todas las sesiones IMAP activas, ingrese el siguiente comando:
killall imapd
23
24
Asegurando su Red
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.
• 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?
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 cifradas 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.
25
Capítulo 2. Asegurando su Red
1. 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.
2. 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 obtener 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.
1. 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.
2. 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.
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.
Dado que el BIOS de cada sistema es diferente de acuerdo a su fabricante, algunos podrían no tener soporte para protección
mediante contraseña de algún tipo, mientras que otros podrían solo soportar un tipo pero no otro.
26
Seguridad en el BIOS y en el gestor de arranque
/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.
2
Reemplace <password-hash> con el valor obtenido por el comando /sbin/grub-md5-crypt .
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:
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:
el GRUB también acepta contraseñas no cifradas, pero es recomendable que un hash MD5 sea utilizado para añadir
seguridad.
27
Capítulo 2. Asegurando su 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.
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.
• No utilice solo palabras o números — Nunca utilice solo números o palabras en contraseñas.
• 8675309
• juan
• hackeame
28
Seguridad de contraseñas
• martin1
• DS-9
• tevez123
• 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.
• 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:
• Su nombre
• El nombre de su mascota
• R0X4H
• nauj
• 9-DS
29
Capítulo 2. Asegurando su Red
• 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.
• 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 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.
otrattw,tghwg.
• Agregue complejidad sustituyendo números y símbolos por letras en la sigla. Por ejemplo, sustituya
7 por t el arroba (@) por a:
o7r@77w,7ghwg.
• Agregue más complejidad poniendo en mayúsculas al menos una letra, tal como la B.
o7r@77w,7gHwg.
30
Seguridad de contraseñas
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.
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.
• 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.
31
Capítulo 2. Asegurando su Red
Advertencia
Siempre obtenga una autorización por escrito antes de intentar descubrir
contraseñas dentro de una organización
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 definir que la contraseña del usuario venza en 90 días, utilice el
siguiente comando:
chage -M 90 <username>
En el comando de arriba, reemplace <username> 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 <username>
32
Controles administrativos
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.
1. Haga clic en el menú Sistema en el panel, apunte al menú Administración y luego haga clic
en Usuarios y Grupos para mostrar el Aministrador de Usuarios. Alternativamente, teclee el
comando system-config-users en un indicador de shell.
3. Haga clic en Propiedades en la barra de herramientas para mostrar el cuadro de diálogo de las
Propiedades del Usuario (o elija Propiedades en el menú Archivo).
5. Ingrese el valor requerido en el campo Días requeridos antes de cambiar y haga clic en
Aceptar.
33
Capítulo 2. Asegurando su Red
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:
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.
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.
34
Controles administrativos
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:
35
Capítulo 2. Asegurando su Red
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.
36
Controles administrativos
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.
PermitRootLogin yes
PermitRootLogin no
Para que estos cambios tengan efecto, el demonio SSH debe ser reiniciado. Esto puede realizarse
mediante el siguiente comando:
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)”.
37
Capítulo 2. Asegurando su Red
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
3
admisnitrativos absolutos en el sistema . 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:
En el comando anterior, reemplace <username> con el nombre del usuario que desee añadir al
grupo wheel .
1. Haga clic en el menú Sistema en el panel, apunte al menú Administración y luego haga clic
en Usuarios y Grupos para mostrar el Aministrador de Usuarios. Alternativamente, teclee el
comando system-config-users en un indicador de shell.
3. Haga clic en Propiedades en la barra de herramientas para mostrar el cuadro de diálogo de las
Propiedades del Usuario (o elija Propiedades en el menú Archivo).
4. Haga clic en la pestaña Grupos, seleccione la casilla para el grupo wheel, y luego haga clic en
OK. Vea la Figura 2.2, “Cómo agregar usuarios al grupo "wheel".”.
Este cambio significa que solo miembros del grupo administrativo wheel pueden usar este
programa.
Estos accesos aún están sujetos a las restricciones impuestas por SELinux, si es que se encuentra activo.
38
Controles administrativos
Nota
El usuario root es por defecto miembro del grupo wheel.
sudo <command>
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.
39
Capítulo 2. Asegurando su Red
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 de control sencillo de comprender. 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:
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:
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.
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.
40
Servicios de red disponibles
• 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.
• Ataque de denegación de servicio distribuido (DDoS, por las iniciales en inglés de Distributed
Denial of Service Attack) — Un tipo de ataque DoS que utiliza varias máquinas comprometidas
(que por lo general suelen ser varios miles) para dirigir un ataque coordinado sobre un servicio,
inundándolo con peticiones y haciendo que sea inutilizable.
• Ataques a las debilidades de los programas — Si un servidor está utilizando programas para
ejecutar acciones propias, como 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.
41
Capítulo 2. Asegurando su Red
• xinetd — Un súper servidor que controla las conexiones de un rango de servidores subordinados,
como son, por ejemplo gssftp y telnet.
• sendmail — El Agente de transporte de correo (MTA, por las iniciales en inglés de Mail Transport
Agent) de Sendmail es activado por defecto, pero solo escucha las conexiones del localhost.
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.
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”.
42
Servicios de red disponibles
Algunos protocolos de red son en sí mismos más inseguros que otros. Estos incluyen los servicios
que:
• Transmiten datos vitales sin ser cifrados sobre una red — Muchos protocolos transmiten datos
en la red sin cifrarlos. 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 cifrarla. Al
utilizar estos protocolos, queda bajo la exclusiva responsabilidad del usuario limitar la clase de
datos que se transmitan.
Otros servicios como finger y rwhod revelan información sobre usuarios del sistema.
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:
• finger
• netdump
• netdump-server
• nfs
• rwhod
• sendmail
• smb (Samba)
43
Capítulo 2. Asegurando su Red
• yppasswdd
• ypserv
• ypxfrd
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.
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 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”.
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.
44
Seguridad del servidor
• 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:
• 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 obtener
mayor 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.
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, ofrezca sólo un tipo de servicio de red por máquina.
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.
45
Capítulo 2. Asegurando su Red
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.
Este ejemplo implementa una pancarta para vsftpd. Para comenzar, cree un archivo de pancarta.
Puede ser en cualquier lugar del sistema, pero debe tener el mismo nombre que el demonio. Para
este ejemplo, el archivo es llamado /etc/banners/vsftpd y contiene la siguiente linea:
220-Hello, %c
220-All activity on ftp.example.com is logged.
220-Inappropriate use will result in your access privileges being removed.
La ficha %c proveé de una serie de 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:
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:
46
Asegurando los servicios con encapsuladores TCP y xinetd
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.
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.
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.
El primer paso para crear un SENSOR es escoger que servicio no está planeado a usarse. En este
ejemplo es utilizado telnet.
flags = SENSOR
47
Capítulo 2. Asegurando su Red
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.
disable = no
Mientras que el uso de SENSOR es una buena idea para detectar y detener conexiones desde equipos
indeseables, tiene dos características en contra:
• Un atacante que sabe que un SENSOR esta 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.
Usar estas directivas puede ayudar a prevenir cualquier servicio xinetd de abrumar el sistema,
resultando en una denegación de servicio.
48
Asegurando Portmap
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.
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.
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.
Nota
Diríjase a la Sección 2.8, “Cortafuegos” para obtener mayor información acerca de
implementar cortafuegos con comandos de iptables.
Un servidor NIS está compuesto por diversas aplicaciones. Entre ellas podemos encontrar:
49
Capítulo 2. Asegurando su Red
• /usr/sbin/yppush — Esta aplicación se encarga de distribuir las bases de datos NIS que han
sido modificadas hacia diferentes servidores 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 cifrada,
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.
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:
Nota
Si se utiliza Kerberos, el archivo /etc/shadow no se encuentra almacenado dentro
de un mapa NIS.
50
Asegurando 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.
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.
Las siguientes reglas iptables pueden ser utilizadas para fortalecer la red que el servidor está
escuchando con estos puertos:
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 obtener mayor información acerca de
implementar cortafuegos con comandos de iptables.
51
Capítulo 2. Asegurando su Red
Debido a que Kerberos utiliza cifrados 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”.
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 ofrece autenticación Kerberos para grupos y usuarios, como
parte del módulo del kernel RPCSEC_GSS. Sigue existinedo información incluida
acerca de portmap, ya que Fedora tiene soporte para NFSv2 y NFSv3, y ambos
utilizan portmap.
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/ bob.example.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.
52
Asegurando el servidor HTTP Apache
showmount -e <hostname>
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.
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.
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:
53
Capítulo 2. Asegurando su Red
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 UserDir se encuentra deshabilitada por defecto, debido a que puede confirmar la
presencia de una cuenta de usuario en el sistema. Para permitir que se examinen directorios de
usuario en el servidor, utilice las siguientes directivas:
UserDir enabled
UserDir disabled root
Estas directivas activan la posibilidad de analizar directorios de usuario para todos los directorios
de usuarios que no sean /root/. Para añadir usuarios a la lista de las cuentas desactivadas,
añada a esos usuarios en una lista separada por espacios en la línea UserDir 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.
• gssftpd — Un demonio basado en xinetd con 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.
Los siguientes lineamientos de seguridad sirven para configurar el servicio FTP vsftpd.
54
Asegurando FTP
Para modificar la imagen de bienvenida para vsftpd, agregue la siguiente directiva en el archivo /
etc/vsftpd/vsftpd.conf:
ftpd_banner=<insert_greeting_here>
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:
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
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.
Advertencia
Si se habilita la posibilidad de acceso anónimo a un servidor FTP, tenga cuidado de
donde almacenar los datos importantes.
55
Capítulo 2. Asegurando su Red
mkdir /var/ftp/pub/upload
A continuación, modifique los permisos de modo que los usuarios anónimos no puedan conocer el
contenido del directorio:
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.
anon_upload_enable=YES
Para deshabilitar todas las cuentas de usuario en vsftpd, agregue la siguiente directiva en /etc/
vsftpd/vsftpd.conf:
local_enable=NO
Para deshabilitar cuentas de usuario específicas en vsftpd, agregue el nombre del usuario en /
etc/vsftpd.ftpusers
56
Asegurando Sendmail
Es recomendable que todos aquellos que estén planeando implementar un servidor Sendmail, tengan
en cuenta los siguientes inconvenientes.
• 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.
Debido a que NFSv2 y NFSv3 no tienen control sobre usuarios ni sobre 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.
57
Capítulo 2. Asegurando su Red
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:
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:
58
Identificación única (SSO, por las iniciales en inglés de Single Sign-on)
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:
El comando lsof muestra información similar a netstat, ya que también es capaz de enlazar
puertos con servicios:
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.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.
59
Capítulo 2. Asegurando su Red
• Entrada
• Salvapantallas
• Firefox y Thunderbird
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.
• Ofrece una sola instancia compartida de las bibliotecas de encriptación NSS en cada sistema
operativo.
• Incluye el Sistema de Certificado del Cliente de Seguridad Empresarial (ESC, por las iniciales
en inglés de Enterprise Security Client) 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 utilizada 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 registrada.
60
Empezar a utilizar su nueva tarjeta inteligente
• 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.)
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.
3. Descargue e instale sus certificados corporativos específicos de usuario root. Utilice el siguiente
comando para instalar el certificado root CA:
4. Verifique que tenga los siguientes RPMs instalados en su sistema: esc, pam_pkcs11, coolkey, ifd-
egate, ccid, gdm, authconfig, and authconfig-gtk.
e. Haga clic en el botón Configurar tarjeta inteligente... 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:
61
Capítulo 2. Asegurando su Red
6. 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.conf y
ubique la siguiente línea:
enable_ocsp = false;
enable_ocsp = true;
8. Si además está utilizando una tarjeta CAC, tendrá que realizar los siguientes pasos:
9. Salida
depurador pklogin_finder
2. 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.
62
Cómo funciona el ingreso con tarjeta inteligente
1. 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.
2. El sistema entonces intenta encontrar los certificados vigentes del usuario y verifica su validez. El
certificado entonces es mapeado en el UID del usuario.
63
Capítulo 2. Asegurando su Red
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)”.
1. En la barra de direcciones de Firefox, escriba about:config para ver una lista actualizada de
las opciones de configuración disponibles.
64
Configurar Firefox para la utilización de Kerberos como SSO
4. Ingrese el nombre del dominio en el cual desea autenticarse, por ejemplo, .ejemplo.com.
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.
[user@host ~] $ kinit
Password for user@EXAMPLE.COM:
[user@host ~] $ klist
Ticket cache: FILE:/tmp/krb5cc_10920
Default principal: user@EXAMPLE.COM
65
Capítulo 2. Asegurando su Red
export NSPR_LOG_MODULES=negotiateauth:5
export NSPR_LOG_FILE=/tmp/moz.log
3. Reinicie Firefox desde esa terminal, y visite el sitio web al que no podía autenticarse
anteriormente. La información será registrada en /tmp/moz.log, y podría darle alguna pista
hacerca del problema. Por ejemplo:
Esto significa que usted no tiene tickets Kerberos, y que necesita ejecutar el comando kinit.
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:
.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.
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).
66
Ventajas de 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, diríjase a la
Sección 2.4.3, “Formato del archivo de configuración de PAM”.
• un esquema de autenticación común que se puede usar en una amplia variedad de aplicaciones.
• una única biblioteca bien documentada que permite a los desarrolladores escribir programas sin
tener que crear sus propios esquemas de autenticación.
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.
• 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.
67
Capítulo 2. Asegurando su Red
• 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 realizar las tareas adicionales que sean necesarias para permitir
accesos, tales como el montaje del directorio personal del usuario y hacer que su casilla de correo
se encuentre disponible.
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:
Esto instruye a PAM para que utilice la interfaz auth del módulo pam_unix.so.
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:
68
Formato del archivo de configuración de PAM
• 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ódulo required o requisite.
• optional — El resultado del módulo se ignora. Un módulo marcado como optional só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.
69
Capítulo 2. Asegurando su Red
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.
#%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
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.
70
Creación de los módulos PAM
Nota
En este ejemplo, los tres módulos auth se encuentran verificados, aún si falló el
primer módulo auth. 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.
• El argumento retry=3 indica 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 interfaz password del
módulo pam_unix.so.
• El argumento shadow le indica al módulo la creación de contraseñas ocultas cada vez que
actualice la contraseña del usuario.
• 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 de pam_cracklib.so para 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ódulo
pam_unix.so que administre la sesión. Este módulo registra el nombre de usuario y el tipo de
servicio en /var/log/secure al 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.
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.
71
Capítulo 2. Asegurando su Red
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.
Con respecto al archivo de registro de tiempo de PAM, debe prestarle atención a lo siguiente:
72
PAM y la propiedad de los dispositivos
• 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 Olvidar Autenticación
del ícono), utilice el siguiente comando:
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.
Vea la Sección 2.8.9.1, “Documentación instalada del cortafuego” para obtener mayor información
acerca del control del módulo pam_timestamp.so.
Los dispositivos afectados incluyen, pero no se limitan a, las placas de sonido, disqueteras, lectoras
de CD-ROM.
73
Capítulo 2. Asegurando su Red
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.perms) y luego ingresar las
modificaciones requeridas. El nombre del nuevo archivo modelo debe comenzar con un número
superior a 50 (por ejemplo 51-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:
Esto evita que los usuarios ganen acceso a dispositivos y aplicaciones restringidas
en la máquina.
<console>=tty[0-9][0-9]* vc/[0-9][0-9]*
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:
74
Recursos adicionales
• /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.
Diríjase a la Sección 2.8.9.1, “Documentación instalada del cortafuego” para obtener mayor
información.
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.conf como 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.
• /usr/share/doc/pam-<version-number>/txts/README.pam_timestamp — Contiene
información relacionada con el módulo PAM pam_timestamp.so, donde <version-number> es
el número de versión de PAM.
75
Capítulo 2. Asegurando su Red
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.
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.
76
Encapsuladores TCP
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”.
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.
77
Capítulo 2. Asegurando su Red
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:
• 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.
• /etc/hosts.allow
• /etc/hosts.deny
78
Archivos de configuración de los encapsuladores TCP
Cuando un servicio encapsulado por TCP recibe una petición de un cliente, realiza los siguientes
pasos:
Las siguientes son cuestiones importantes para considerar cuando se utilice encapsuladores TCP
para proteger servicios de red:
• Debido a que primero se aplican las reglas de acceso contenidas en hosts.allow, dejan un
precedente sobre las reglas especificadas en hosts.deny. De este modo, si el acceso a un
servicio es permitido en hosts.allow, será ignorada una regla negando el acceso al mismo
servicio del archivo hosts.deny.
• Las reglas de cada archivo son 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.
• Los servicios encapsulados por TCP no conservan las reglas desde los archivos de acceso de los
equipos, de modo que cualquier cambio en hosts.allow o hosts.deny, tienen efecto inmediato,
sin necesidad de reiniciar los servicios de red.
Advertencia
Si la última 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:
Cada regla utiliza el siguiente formato básico para controlar el acceso a los servicios de red:
79
Capítulo 2. Asegurando su Red
• <daemon list> — Una lista separada por comas de nombres de procesos (y no el nombre
de los servicios), o el comodín ALL. 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.
• <option> — 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:
vsftpd : .example.com
Esta regla está indicando a los encapsuladores TCP que observen las conexiones del demonio
FTP (vsftpd) desde cualquier equipo en el dominio ejemplo.com. Si esta regla aparece en
hosts.allow, la 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:
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 ejemplo.com, sea ejecutado el comando echo para añadir
dicho intento en un archivo especial de registro, 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.
80
Archivos de configuración de los encapsuladores TCP
• 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 : .example.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.0
hasta 192.168.1.255:
ALL : 192.168.0.0/255.255.254.0
81
Capítulo 2. Asegurando su Red
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:: hasta
3ffe:505:2:1:ffff:ffff:ffff:ffff:
ALL : [3ffe:505:2:1::]/64
• El asterisco (*) — Los asteriscos pueden ser utilizados para hacer concordar grupos enteros de
nombres de equipos o direcciones IP, siempre y cuando no 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 : *.example.com
• La barra (/) — Si una lista de cliente comienza con una barra, será tratada como un nombre
de archivo. Esto es útil si se necesitan reglas especificando grandes cantidades de equipos. El
siguiente ejemplo referencia encapsuladores TCP al archivo /etc/telnet.hosts para todas las
conexiones Telnet.
in.telnetd : /etc/telnet.hosts
Existen otros patrones menos utilizados que 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.
Los cambios en las reglas de control de acceso de portmap podrían no tener efecto inmediatamente.
Tal vez necesite reiniciar el servicio portmap.
82
Archivos de configuración de los encapsuladores TCP
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 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:
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.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:
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:
83
Capítulo 2. Asegurando su Red
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.
Por ejemplo, las dos reglas siguientes permiten conexions SSH desde client-1.example.com,
pero niegan conexiones de client-2.example.com:
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.
• spawn — Inicia un comando de terminal como un proceso hijo. Esta directiva puede realizar tareas
como ser la utilización de /usr/sbin/safe_finger para 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 comando echo.
En el siguiente ejemplo, los clientes del dominio ejemplo.com que intentan acceder a servicios
Telnet, son registrados silenciosamente en un archivo especial:
in.telnetd : .example.com \
: spawn /bin/echo `/bin/date` from %h>>/var/log/telnet.log \
: allow
• twist — 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 clientes que estén conectándose. La directiva
twist debe 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 dominio
ejemplo.com, se les envía un mensaje utilizando el comando echo.
vsftpd : .example.com \
84
Archivos de configuración de los encapsuladores TCP
: 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.
• %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.
• %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 del servidor. Si no está disponible, se muestra unknown. Si el
nombre del equipo del servidor y la dirección no concuerdan, se muestra paranoid.
• %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.
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 : .example.com \
: spawn /bin/echo `/bin/date` access denied to %h>>/var/log/sshd.log \
: deny
De manera similar, las expansiones pueden ser utilizadas para personalizar mensajes enviados al
cliente. En el siguiente ejemplo, a los clientes que intentan acceder a servicios FTP desde el dominio
ejemplo.com, se les informa que han sido eliminados del servidor:
vsftpd : .example.com \
85
Capítulo 2. Asegurando su Red
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.
• /etc/xinetd.d/ — El directorio continente de todos los archivos específicos para cada servicio.
defaults
{
instances = 60
log_type = SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST
cps = 25 30
}
includedir /etc/xinetd.d
86
Archivos de configuración de xinetd
• instances — Indica el número máximo de peticiones simultáneas que puede procesar xinetd.
• log_type — Configura xinetd para utilizar la herramienta de registro authpriv, que guarda
entradas de registro en el archivo /var/log/secure. Agregar una directiva como FILE /var/
log/xinetdlog podría crear un archivo de registro modificado denominado xinetdlog en el
directorio /var/log/.
• log_on_success — Configura xinetd para 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.
• cps — Configura xinetd para 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.
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”.
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
87
Capítulo 2. Asegurando su Red
user = root
server = /usr/kerberos/sbin/telnetd
log_on_failure += USERID
disable = yes
}
• service — Especifica el nombre del servicio, generalmente uno de aquellos listados en el archivo
/etc/services
• flags — Establece alguno de los atributos para la conexión. REUSE le indica a xinetd que vuelva
a utilizar el socket para una conexión Telnet.
Nota
La marca REUSE es obsoleta. Todos los servicios hoy en día utilizan la marca
REUSE.
• 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).
• 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.
• DURATION — Registra el período de tiempo total en que ha sido utilizado el servicio por un sistema
remoto (log_on_success).
88
Archivos de configuración de xinetd
• 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_failure ylog_on_success).
Para obtener una lista completa de opciones de registro, consulte la página man de xinetd.conf.
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.
El control de acceso de los equipos con xinetd difiere del método utilizado por los 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/.
• 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
{
89
Capítulo 2. Asegurando su Red
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:
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:
1. El demonio xinetd obtiene las reglas de acceso de los equipos con encapsuladores TCP,
utilizando una llamada de biblioteca libwrap.a. Si una regla de 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 a xinetd.
2. El demonio xinetd verifica sus propias reglas de control de acceso tanto para el servicio
xinetd, como para el servicio solicitado. Si una regla de negación concuerda con el cliente,
se abandona la conexión. De lo contrario, xinetd inicia 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.
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
90
Archivos de configuración de xinetd
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.
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
91
Capítulo 2. Asegurando su Red
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.
• 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 en xinetd.conf
como en el archivo de configuración específico del servicio en cuestión del directorio xinetd.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
que xinetd debe esperar antes de reactivar el servicio. Acepta solo enteros como argumentos
y puede ser utilizado tanto en el archivo xinetd.conf, como el los archivos de configuración
propios de cada servicio en el directorio xinetd.d/.
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 comandos uptime, who, y procinfo
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.
92
Kerberos
• 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 y
xinetd. Las siguientes con algunas de las más importantes:
Aplicaciones de servidor
• man xinetd — La página man para xinetd.
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 para 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.
Un sistema donde tanto el cliente como el servidor comparten una clave común que es utilizada para encriptar y desencriptar
comunicaciones a través de una red.
93
Capítulo 2. Asegurando su 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.
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.
• 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/passwd o /etc/shadow hacia 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:
6
http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html
• 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. Diríjase a la Sección 2.6.4,
“Kerberos y PAM” para obtener mayor 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.
94
Terminología de Kerberos
• 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.
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.
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.
95
Capítulo 2. Asegurando su Red
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 los datos de otras maneras para poder producir un valor hash.
llave
Los datos usados cuando se encriptan o desencriptan otros datos. Los datos encriptados no
pueden ser desencriptados sin una clave apropiada o una extrema buena suerte de parte del
craqueador.
kinit
El comando kinit permite 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 de kinit para más información.
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.
96
Como Funciona Kerberos
contraseña no encriptada
Una contraseña en texto plano, legible al humano.
Entonces el KDC verifica que exista el principal en su base de datos. Si el principal es encontrado, el
KDC crea un TGT, que es cifrado utilizando la llave del usuario, y le es devuelto a ese usuario.
El registro, o programa kinit en el cliente, se encarga de descifrar el TGT utilizando la llave del
usuario, que se analiza desde la contraseña del usuario. La llave del usuario es utilizada sólo en la
máquina cliente y no se transmite en la red.
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.
Esta es solamente una presentación general acerca de cómo funciona la autenticación de Kerberos.
Diríjase a la Sección 2.6.10, “Recursos adicionales” para conocer otros enlaces hacia información
más detallada.
97
Capítulo 2. Asegurando su Red
Nota
Kerberos depende de los siguientes servicios de red para funcionar correctamente.
• Sincronización de reloj aproximado entre las máquinas de la red.
Debe asegurarse que las entradas DNS y los equipos en la red se encuentren
todos configurados adecuadamente. Diríjase a la Guía de Kerberos V5 para los
administradores de sistemas en /usr/share/doc/krb5-server-<version-
number> para obtener más información, (donde <version-number> es el
número de versión del paquete krb5-server instalado en su sistema).
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.
1. 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
98
Configurando un servidor Kerberos 5
/usr/kerberos/sbin/kdb5_util create -s
El comando create genera la base de datos que almacena las clves para el reinado de
Kerberos. El interruptor -s obliga 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.
*/admin@EXAMPLE.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 ejercer un poder completo sobre el reinado de la base de datos
de Kerberos.
Después de que se inicie kadmind en el servidor, cualquier usuario puede acceder sus servicios
ejecutando kadmin en cualquier cliente o servidores en el reino. Sin embargo, sólo los usuarios
listados en el archivo kadm5.acl pueden modificar la base de datos de ninguna forma, excepto
para cambiar sus propias contraseñas.
99
Capítulo 2. Asegurando su Red
Nota
La herramienta kadmin permite la comunicación con el servidor kadmind
a 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 comando kadmin.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 siguiente kadmin.local en la terminal KDC para crear el primer principal:
7. Agregue principales para los usuarios mediante el comando addprinc dentro de kadmin.
kadmin y kadmin.local son interfaces de líneas de comando al KDC. Como este, existen
disponibles otros comandos — como por ejemplo addprinc — luego de iniciar el programa
kadmin. Para obtener mas información, consulte la página man de kadmin.
8. Verifique que KDC está emitiendo tiques. Primero, corra kinit para obtener un tique y guardarlo
en un archivo cache de credencial. Luego, use klist para ver la lista de credenciales en el
caché y use kdestroy para destruir el caché y las credenciales que contiene.
Nota
Por defecto, kinit intenta 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, kinit
envía un mensaje de error. Si eso sucede, indiquele a kinit el 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.
100
Configuración de un Cliente Kerberos 5
1. Asegúrese que la sincronización de tiempo entre el cliente Kerberos y KDC exista y sea la
adecuada. Diríjase a Sección 2.6.5, “Configurando un servidor Kerberos 5” para obtener mayors
información. Además, verifique que el DNS está funcionando apropiadamente en el cliente
Kerberos antes de configurar con los programas cliente de Kerberos.
2. Instale los paquetes krb5-libs y krb5-workstation en todas las máquinas clientes. Provea
un archivo /etc/krb5.conf válido para cada cliente (normalmente este puede ser el mismo
archivo krb5.conf usado por el KDC).
3. Antes que una estación de trabajo del reinado pueda utilizar a Kerberos para autenticar los
usuarios que se conectan mediante ssh, o mediante los rsh o rlogin Kerberizados, debe tener
su propio equipo principal en la base de datos de Kerberos. Los programas de servidor sshd,
kshd, y klogind, necesitan todos acceder a las llaves para los servicios del equipo principal.
Además, para poder utilizar los servicios kerberizados rsh y rlogin, esa estación de trabajo
debe tener el paquete xinetd instalado.
Ahora que se ha creado el principal, las claves se pueden extraer para la estación trabajo
ejecutando kadmin en la misma estación de trabajo y usando el comando ktadd dentro de
kadmin:
4. 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 utiliza GSS-API para autenticar a los usuarios en los servidores, si la
configuración del cliente y del servidor tienen ambas GSSAPIAuthentication habilitado.
Si el cliente tiene también GSSAPIDelegateCredentials habilitado, las credenciales del
usuario se hacen disponibles en el sistema remoto.
• rsh y rlogin — Para usar las versiones kerberizadas de rsh y rlogin, habilite klogin,
eklogin y kshell.
• 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
habilite gssftp.
• IMAP — Para utilizar un servidor kerberizado IMAP, el paquete cyrus-imap utilizará Kerberos
5, si también se encuentra instalado el paquete cyrus-sasl-gssapi. El paquete cyrus-
sasl-gssapi contiene el complemento Cyrus SASL que tiene soporte para autenticación
GSS-API. Cyrus IMAP debería funcionar correctamente con Kerberos siempre y cuando el
usuario cyrus sea capaz de encontrar la clave correspondiente en /etc/krb5.keytab, y
que la raíz para el principal esté definida para imap (creada con kadmin).
101
Capítulo 2. Asegurando su Red
• CVS — Para usar un servidor CVS kerberizado, gserver usa un principal con una raíz de cvs
y por lo demás es idéntico al servidor CVS pserver.
Por defecto, el nombre del territorio se toma como el nombre de dominio DNS del servidor, en
mayúsculas.
foo.example.org → EXAMPLE.ORG
foo.example.com → EXAMPLE.COM
foo.hq.example.com → HQ.EXAMPLE.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]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
En la configuración anterior se especifican dos mapeos. El primero indica que cualquier sistema
en el dominio de DNS "ejemplo.com" pertenecen al reinado EJEMPLO.COM. El segundo, 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.
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
102
Configurando KDCs secundarios
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.COM
Entry for principal host/masterkdc.example.com with kvno 3, encryption type Triple DES cbc
mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/masterkdc.example.com with kvno 3, encryption type ArcFour with HMAC/
md5 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/masterkdc.example.com with kvno 3, encryption type DES with HMAC/sha1
added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/masterkdc.example.com with kvno 3, encryption type DES cbc mode with
RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab.
kadmin: quit
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.
Entry for principal host/slavekdc.example.com with kvno 3, encryption type Triple DES cbc mode
with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/slavekdc.example.com with kvno 3, encryption type ArcFour with HMAC/
md5 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/slavekdc.example.com with kvno 3, encryption type DES with HMAC/sha1
added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/slavekdc.example.com with kvno 3, encryption type DES cbc mode with
RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab.
kadmin: quit
103
Capítulo 2. Asegurando su Red
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.
Una vez que el KDC esclavo haya obtenido una copia de la base de datos, necesitará también la
llave maestra que ha sido utilizada para cifrarlo. 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 permita al KDC maestro contactarlo utilizando el puerto
754 con TCP (krb5_prop), e inicie el servicio kprop. Luego, vuelva a verificar si el servicio kadmin se
encuentra 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.
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.
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.
104
Configurando la autenticación cruzada de reinados
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.
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.example.com@EXAMPLE.COM
En el ejemplo siguiente, el servicio es generalmente, o bien el nombre del protocolo en uso (otros
valores comunes pueden ser ldap, imap, cvs, y HTTP), o bien equipo. server.ejemplo.com es el
nombre del dominio del sistema completamente calificado que ejecuta el servicio, y EJEMPLO.COM es
el nombre del reinado.
105
Capítulo 2. Asegurando su Red
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.
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 reinado como uno podría tratar un nombre DNS.
Reiteradamente va quitando los componentes de su propio nombre de reinado para generar los
nombres de los reinados 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 como otro "salto".
Otro ejemplo, esta vez utilizando nombres de reinados que no compartan sufijos comunes
(DEVEL.EJEMPLO.COM y PROD.EJEMPLO.ORG DEVEL.EJEMPLO.COM → EJEMPLO.COM → COM →
ORG → EJEMPLO.ORG → PROD.EJEMPLO.ORG
• DEVEL.EJEMPLO.COM y EJEMPLO.COM comparten una clave para krbtgt/
EJEMPLO.COM@DEVEL.EJEMPLO.COM
106
Configurando la autenticación cruzada de reinados
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.
[capaths]
A.EXAMPLE.COM = {
B.EXAMPLE.COM = .
C.EXAMPLE.COM = B.EXAMPLE.COM
D.EXAMPLE.COM = B.EXAMPLE.COM
D.EXAMPLE.COM = C.EXAMPLE.COM
}
Nota
Sin una entrada que indique lo contrario, Kerberos asume que las relaciones de
confianza de reinados cruzados forman una jerarquía.
107
Capítulo 2. Asegurando su Red
• 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-<version-number>/ (donde
<version-number> es el número de versión del paquete krb5-workstation instalado 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.
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.
108
Redes privadas virtuales (VPNs, por las iniciales en inglés de Virtual Private Networks)
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.
109
Capítulo 2. Asegurando su Red
de software, trabajan como enrutadores especializados que existen entre la conexión IP desde una
oficina hacia otra.
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.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.
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.
110
Instalación de 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.
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”.
111
Capítulo 2. Asegurando su Red
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.
2. En la pestaña de IPsec, haga clic en Nuevo para iniciar el asistente de configuración de IPsec.
3. haga clic en Siguiente para iniciar la configuración de una conexión IPsec de equipo-a-equipo.
4. 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
Siguiente para continuar.
5. Seleccione Encriptado de equipo a equipo como el tipo de conexión, y luego haga clic en
Siguiente.
Si selecciona encriptado manual, deberá indicar más adelante una clave de encriptado. Si
selecciona encriptado automático, el demonio racoon se encarga de administrar la clave del
encriptado. El paquete ipsec-tools debe estar instalado si quiere utilizar la encriptación
automática.
Para determinar la dirección IP del equipo remoto, utilice el siguiente comando en el equipo
remoto:
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):
112
Configuración de IPsec equipo-a-equipo
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.
a. Indique una clave de autenticación o haga clic en Generar para generar una. Puede ser una
combinación de números y letras.
9. Verifique la información en la página IPsec — Resumen, y luego haga clic en el botón Aplicar.
Tal vez necesite reiniciar la red para que los cambios tengan efecto. Para reiniciar la red, utilice el
siguiente comando:
12. 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á.
113
Capítulo 2. Asegurando su Red
• /etc/sysconfig/network-scripts/ifcfg-<nickname>
• /etc/sysconfig/network-scripts/keys-<nickname>
• /etc/racoon/<remote-ip>.conf
• /etc/racoon/psk.txt
• Un nombre único, por ejemplo, ipsec1. Esto es utilizado para identificar la conexión IPsec y poder
identificarla de otros dispositivos o conexiones.
114
Configuración de IPsec equipo-a-equipo
Por ejemplo, suponga que la estación de trabajo A y la estación de trabajo B quieren conectarse entre
ellas mediante de un túnel IPsec. Quieren conectarse utilizando una clave pre-compartida con el
valor de Key_Value01, y los usuarios acuerdan la utilización de racoon para generar y compartir
una clave de autenticación entre cada equipo. Los usuarios de ambos equipos deciden referirse a su
conexión como ipsec1..
Nota
Debería elegir una PSK (clave pre-compartida) que utilice una mezcla de caracteres
en mayúscula y en minúscula, números y signos de puntuación. Una PSK fácil de
adivinar constituye un riesgo de seguridad.
DST=X.X.X.XTYPE=IPSEC
ONBOOT=no
IKE_METHOD=PSK
IKE_PSK=Key_Value01
Importante
Para modificar el archivo keys-ipsec1 de modo que solo el usuario root pueda
leerlo o editarlo, utilice el siguiente comando luego de haberlo creado:
115
Capítulo 2. Asegurando su Red
remote X.X.X.X{
exchange_mode aggressive, main;
my_identifier address;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2 ;
}
}
El archivo de configuración de la etapa 1 que se ha creado por defecto cuando se inicia una conexión
IPsec, contiene las siguientes directivas utilizadas por la implementación de IPsec de Fedora:
remote X.X.X.X
Indica que las siguientes líneas en este archivo de configuración se aplican solo al nodo remoto
identificado por la dirección IP X.X.X.X.
exchange_mode aggressive
La configuración establecida por defecto en Fedora para IPsec utiliza un método de autenticación
agresivo, que disminuye los excedentes de la conexión, permitiendo la configuración de varias
conexiones IPsec con múltiples equipos.
my_identifier address
Indica el método de identificación a ser utilizado cuando se autentican nodos. Fedora utiliza
direcciones IP para identificar nodos.
encryption_algorithm 3des
Especifica el cifrador de encriptación utilizado durante la autenticación. Por defecto, se usa
el Estándar de Encriptación de Datos Triple (3DES, por las iniciales en inglés de Triple Data
Encryption Standard).
hash_algorithm sha1;
Indica el algoritmo hash utilizado durante la negociación entre los nodos de la etapa 1. Por
defecto, se utiliza un algoritmo de hash seguro (SHA, por las iniciales en inglés de Secure Hash
Algorithm).
authentication_method pre_shared_key
Indica el método de autenticación utilizado durante la negociación del nodo. Por defecto, Fedora
utiliza una clave pre-compartida para la autenticación.
dh_group 2
Indica el número de grupo Diffie-Hellman para establecer claves de sesiones generadas
dinámicamente. Por defecto, se utiliza modp1024 (segundo grupo).
116
Configuración de IPsec equipo-a-equipo
sainfo anonymous
{
pfs_group 2;
lifetime time 1 hour ;
encryption_algorithm 3des, blowfish 448, rijndael ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}
include "/etc/racoon/X.X.X.X.conf";
Este archivo racoon.conf establecido por defecto incluye caminos definidos para la configuración
de IPsec, claves pre-compartidas y certificados. Los campos de sainfo anonymous describen
la etapa SA 2 entre los nodos IPsec — el tipo de conexión IPsec (incluyendo los algoritmos de
encriptación utilizados soportados), y el método de intercambio de claves. La siguiente lista define los
campos de la estapa 2:
sainfo anonymous
Indica que SA puede iniciarse anónimamente con cualquier par ofrecido que se corresponda con
las credenciales de IPsec.
pfs_group 2
Define el protocolo de intercambio de claves Diffie-Hellman, que determina el método por el cual
los nodos IPsec establecen una clave de sesión mutua y temporal para la segunda etapa de
la conectividad IPsec. Por defecto, la implementación en Fedora de IPsec utiliza el segundo (o
modp1024) de los grupos Diffie-Hellman de intercambio de claves criptográficas. EL segundo
grupo utiliza una exponenciación modular de 1024 bits que evita que los atacantes puedan
decriptar transmisiones IPsec, aún si una de las claves privadas ha sido vulnerada.
117
Capítulo 2. Asegurando su Red
compression_algorithm deflate
Indica el algoritmo de compresión Deflate para el soporte de IP Payload Compression (IPCOMP),
que potencialmente permite transmisiones más rápidas de datagramas IP sobre conexiones más
lentas.
Para iniciar una conexión, utilice el siguiente comando en cada uno de los equipos:
Para verificar la conexión IPsec, ejecute la herramienta tcpdump para conocer los paquetes de red
que están siendo transferidos entre los equipos, y verifique que están encriptados mediante IPsec. El
paquete debería incluir un encabezado AH y debería mostrarse como un paquete ESP. ESP significa
que está encriptado. Por ejemplo:
El siguiente diagrama muestra dos LANs diferentes separadas por Internet. Estas LANs utilizan
enrutadores IPsec para autenticar e iniciar una conexión utilizando un túnel seguro a través de
Internet. Los paquetes en tránsito entre estas dos LANs que sean interceptados, necesitarían un
método de decriptado de tipo fuerza bruta para poder atravesar la protección que poseen. El proceso
de comunicación de un nodo en el rango IP 192.168.1.0/24, con otro del rango IP 192.168.1.0/24 es
completamente transparente a los nodos, al igual que el proceso, encriptado, decriptado, y enrutado
de los paquetes IPsec, es completamente manipulado por el enrutador IPsec.
118
Configuración IPsec red-a-red
• Los rangos de dirección de red de LAN/WAN ofrecidos por los enrutadores IPsec (como por
ejemplo, 192.168.1.0/24 or 10.0.1.0/24)
• Las direcciones IP de los dispositivos de las puertas de enlace que enrutan los datos desde los
nodos de red hacia Interne
• Un nombre único, por ejemplo, ipsec1. Esto es utilizado para identificar la conexión IPsec y poder
identificarla de otros dispositivos o conexiones.
Por ejemplo, como se muestra en la Figura 2.12, “IPsec red-a-red”, si la red privada 192.168.1.0/24
envía tráfico hacia la red privada 192.168.2.0/24, los paquetes van a través de la puerta-de-enlace-0,
al ipsec0, a través de internet, hacia ipsec1, a la puerta-de-enlace-1, y hacia la subred 192.168.2.0/24
Los enrutadores IPsec necesitan direcciones IP públicas capaces de recibir paquetes, y un segundo
dispositivo Ethernet conectado a sus respectivas redes privadas. El tráfico sólo viaja a través de un
enrutador IPsec si su destinatario es otro enrutador IPsec con el cual ha establecido una conexión
encriptada.
Utilice el siguiente procedimiento para configurar una conexión IPsec de tipo red-a-red:
119
Capítulo 2. Asegurando su Red
2. En la pestaña de IPsec, haga clic en Nuevo para iniciar el asistente de configuración de IPsec.
3. Haga clic en Siguiente para empezar a configurar una conexión IPsec de tipp red-a-red.
4. Ingrese un nombre de usuario único para la conexión, por ejemplo, ipsec0. Si lo necesita, tilde
la casilla para que automáticamente se active la conexión cuando se inicie el equipo. Haga clic en
Siguiente para continuar.
5. Seleccione Encriptado de red a red (VPN) como el tipo de conexión, y luego haga clic en
Siguiente.
Si selecciona encriptado manual, deberá indicar más adelante una clave de encriptado. Si
selecciona encriptado automático, el demonio racoon se encarga de administrar la clave del
encriptado. El paquete ipsec-tools debe estar instalado si quiere utilizar la encriptación
automática.
120
Configuración IPsec red-a-red
• Remote IP Address — La dirección IP pública capaz de recibir tráfico del enrutador IPsec para
la otra red privada. En nuestro ejemplo, para ipsec0, ingrese la dirección IP pública capaz de
recibir tráfico de upsec1, y viceversa.
• Remote Network Address — La dirección de red de la subred privada detrás del otro
enrutador IPsec. En nuestro ejemplo, ingrese 192.168.1.0 si está configurando ipsec1, e
ingrese 192.168.2.0 si está configurando ipsec0.
Especifique una clave de autenticación o haga clic en Generar para crear una. Esta clave
puede ser cualquier combinación de números y letras.
121
Capítulo 2. Asegurando su Red
9. Verifique la información en la página IPsec — Resumen, y luego haga clic en el botón Aplicar.
11. Seleccione la conexión IPsec de la lista, y luego haga clic en Activar para activar la conexión.
El programa de red para activar la conexión IPsec automáticamente crea rutas de red para enviar
paquetes a través del enrutador IPsec, si es necesario.
122
Configuración IPsec red-a-red
desde el exterior que tiene acceso a Internet, mientras eth1 actúa como un punto de enrutamiento
para procesar y transmitir los paquetes LAN de un nodo de red a otro.
La conexión IPsec entre cada red utiliza una clave pre-compartida con el valor de r3dh4tl1nux,
y los administradores de A y B están de acuerdo en permitir que racoon genere automáticamente
y comparta una clave de autenticación entre cada enrutador IPsec. El administrador de LAN A
decide identificar a la conexión IPsec como ipsec0, mientras que el administrador de LAN B decide
identificarla como ipsec1.
El siguiente ejemplo muestra los contenidos del archivo ifcfg para una conexión IPsec de tipo red-
a-red para LAN A. El único nombre para identificar la conexión en este ejemplo es ipsec0, de modo
que el archivo resultante es /etc/sysconfig/network-scripts/ifcfg-ipsec0.
TYPE=IPSEC
ONBOOT=yes
IKE_METHOD=PSK
SRCGW=192.168.1.254
DSTGW=192.168.2.254
SRCNET=192.168.1.0/24
DSTNET=192.168.2.0/24
DST=X.X.X.X
TYPE=IPSEC
Especifica el tipo de conexión.
ONBOOT=yes
Indica que la conexión debería iniciarse en el arranque.
IKE_METHOD=PSK
Indica que la conexión utiliza el método de clave pre-compartida para su autenticación.
SRCGW=192.168.1.254
La dirección IP de la puerta de enlace origen. Para LAN A, es la puerta de enlace de LAN A, y
para LAN B, la puerta de enlace LAN B.
DSTGW=192.168.2.254
La dirección IP de la puerta de enlace destino. Para LAN A, es la puerta de enlace de LAN B, y
para LAN B, la puerta de enlace de LAN A.
SRCNET=192.168.1.0/24
Indica la red de origen para la conexión IPsec, que en nuestro ejemplo es el rango de red para
LAN A.
DSTNET=192.168.2.0/24
Indica la red destino para la conexión IPsec, que en nuestro ejemplo, es el rango de red para LAN
B.
DST=X.X.X.X
La dirección IP accesible desde el exterior de LAN B.
123
Capítulo 2. Asegurando su Red
utilizan ambas redes para autenticarse entre ellas. Los contenidos de este archivo deberían ser
idénticos y solo el usuario root debería ser capaz de leer o escribir sobre este archivo.
IKE_PSK=r3dh4tl1nux
Importante
Para modificar el arhivo keys-ipsecX de modo que solo el usuario root pueda
leerlo o editarlo, utilice el siguiente comando luego de haberlo creado:
sainfo anonymous
{
pfs_group 2;
lifetime time 1 hour ;
encryption_algorithm 3des, blowfish 448, rijndael ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}
include "/etc/racoon/X.X.X.X.conf"
remote X.X.X.X{
exchange_mode aggressive, main;
my_identifier address;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2 ;
}
}
Antes de empezar la conexión IPsec, debería ser habilitado el reenvío de IP en el kernel. Para
hacerlo:
124
Iniciar y detener una conexión IPsec
Las conexiones están activas, y tanto LAN A como LAN B son capaces de comunicarse entre
ellas. Las rutas fueron creadas automáticamente mediante la inicialización de un programa que fue
activado al ejecutarse ifup en la conexión IPsec. Para mostrar una lista de rutas para la red, utilice el
siguiente comando:
El paquete debería incluir un encabezado AH y debería mostrarse como paquetes ESP. ESP significa
que está encriptado. Por ejemplo (las líneas invertidas indican que la línea continúa):
Para iniciar la conexión, utilice el siguiente comando en cada uno de los equipos para una IPsec de
tipo equipo-a-equipo, o en cada uno de los enrutadores IPsec para una IPsec de tipo red-a-red:
2.8. Cortafuegos
La seguridad de la información es comúnmente entendida como un proceso, y no como un producto.
Sin embargo, generalmente las implementaciones estándar de seguridad utilizan alguna forma
de mecanismo específico para controlar los accesos privilegiados y restringir los recursos de red
a usuarios que estén debidamente autorizados para ello, y al mismo tiempo poder identificarlos
125
Capítulo 2. Asegurando su Red
y rastrearlos. Fedora incluye diferentes herramientas para ayudar a los administradores y a los
ingenieros en seguridad, con los diferentes problemas que puedan surgir al controlar los accesos
jerarquizados a la red.
Los cortafuegos son uno de los componentes fundamentales para la implementación de la seguridad
en una red. Diversos proveedores ofrecen herramientas para cortafuegos para todos los niveles
del mercado: desde usuarios hogareños protegiendo los datos de su PC, hasta herramientas para
centros de datos que permitan proteger los datos vitales de una empresa. Los cortafuegos pueden
ser herramientas para un sólo equipo físico, como las aplicaciones de cortafuego que ofrecen Cisco,
Nokia y Sonicwall. Proveedores como Checkpoint, McAfee y Symantec también han desarrollado
herramientas de cortafuegos de código propietario, tanto para el hogar como para los segmentos
comerciales del mercado.
Además de las diferencias entre los cortafuegos basados en hardware o en software, existen
también diferencias en la manera en que el cortafuego funciona, separando una herramienta de otra.
Tabla 2.2, “Tipos de cortafuegos” describe tres tipos comunes de cortafuegos, y cómo funcionan cada
uno de ellos:
126
Netfilter e IPTables
Esta sección ofrece un resumen acerca de iptables. Para obtener información más detallada,
diríjase a la Sección 2.9, “IPTables”.
127
Capítulo 2. Asegurando su Red
En una instalación por defecto de Fedora existe un cortafuegos entre su computadora o red,
y cualquier otra red considerada como no segura, como por ejemplo lo es Internet. Determina
qué servicios en su computadora pueden ser accedidos por usuarios remotos. Un cortafuegos
correctamente configurado puede incrementar enormemente la seguridad de su sistema. Se
recomienda que configure un cortafuegos para cualquier sistema Fedora que tenga una conexión a
Internet.
Una vez finalizada la instalación, puede modificar las opciones elegidas mediante la utilización de la
Herramienta de configuración de cortafuegos.
[root@myServer ~] # system-config-firewall
Nota
Firewall Configuration Tool solo configura un cortafuego básico. Si el sistema
necesita reglas más complejas, diríjase a la Sección 2.9, “IPTables” para conocer
más detalles sobre la configuración de reglas específicas de iptables.
128
Configuración básica de un cortafuego
Advertencia
Las configuraciones del cortafuego y cualquier reglas de cortafuegos
personalizadas se almacenan en el archivo /etc/sysconfig/iptables. Si
elije Deshabilitado y hace clic en Aceptar, estas configuraciones y reglas del
cortafuego se perderán.
• Habilitado — Esta opción configura el sistema para rechazar conexiones entrantes que no una
respuesta a peticiones que han sido realizadas, tales como respuestas DNS o peticiones DHCP.
Si se necesita el acceso a servicios de esta máquina, puede elegir habilitar servicios específicos a
través del cortafuego.
Si está conectando su sistema a Internet, pero no planea hacerlo funcionar como servidor, esta es
la opción más segura.
WWW (HTTP)
El protocolo HTTP es utilizado por Apache (y por otros servidores Web) para ofrecer páginas
web. Si tiene pensado hacer que su servidor web esté disponible al público en general, tilde esta
casilla. Esta opción no es requerida para ver páginas en forma local, o para desarrollar páginas
web. Este servicio requiere que el paquete httpd esté disponible.
Habilitando WWW (HTTP) no abrirá el puerto de HTTPS, la versión SSL de HTTP. Si se necesita
este servicio, Elija la casilla WWW Seguro (HTTPS).
FTP
El protocolo FTP se usa para transferir archivos entre máquinas de una red. Si planea hacer su
servidor FTP disponible públicamente, marque este casillero. Este servicio requiere que se instale
el paquete vsftpd.
SSH
Secure Shell (SSH) es una suite de herramientas para registrarse en un equipo remoto y poder
ejecutar comandos en él. Para permitir acceso remoto a una máquina utilizando ssh, tilde esta
casilla. Este servicio requiere que el paquete openssh-server se encuentre instalado.
Telnet
Telnet es un protocolo que permite registrarse en equipos remotos. Las comunicaciones a través
de Telnet no están encriptadas y no ofrece protección ante posibles espías que se encuentren en
la red. No se recomienda permitir el acceso a través de Telnet. Para permitirlo, tilde esta casilla.
Este servicio requiere que el paquete telnet-server se encuentre instalado.
129
Capítulo 2. Asegurando su Red
Mail (SMTP)
SMTP es un protocolo que permite que equipos remotos puedan conectarse directamente con su
máquina para enviar correos electrónicos. No necesita activar este servicio si obtiene su correo
electrónico a través de su servidor ISP, utilizando POP3 o IMAP, o si utiliza una herramienta como
fetchmail. Para permitir el envío de correos electrónico hacia su máquina, seleccione esta
casilla. Tenga en cuenta que una configuración incorrecta de un servidor SMTP puede permitir
que otros equipos utilicen su servidor para enviar correo basura.
NFS4
El Sistema de Archivos de Red (NFS, por las siglas en inglés de Network File System), es un
protocolo para compartir archivos comúnmente utilizado en sistemas *NIX. La versión 4 de este
protocolo es más segura que sus predecesoras. Si quiere compartir archivos y directorios de su
sistema con otros en red, tilde esta casilla.
Samba
Samba es una implementación del protocolo de red SMB de código propietario de Microsoft. Si
necesita compartir archivos, directorios o impresoras conectadas localmente con computadoras
con Microsoft Windows, tilde esta casilla.
194:tcp,631:tcp
130
Uso de IPTables
Para asegurarse de que iptables se inicie cuando el sistema arranque, use el siguiente comando:
Nota
El servicio ip6tables puede ser desactivado si usted intenta utilizar solamente
el servicio iptables. Si desactiva el servicio ip6tables, recuerde también
desactivar la red IPv6. Nunca deje un dispositivo de red activo sin su correspondiente
cortafuegos.
Para forzar a iptables para que se inicie por defecto cuando el sistema arranque, use el siguiente
comando:
Esto fuerza a iptables a que se inicie cuando el sistema arranque en los niveles de ejecución 3, 4 o
5.
La opción -A especifica que la regla se agregará a la <cadena>. Cada cadena se compone de una o
más reglas, por lo que se conoce también como un conjunto de reglas.
Las tres cadenas predefinidas son INPUT, OUTPUT, y FORWARD. Estas cadenas son permanentes y
no se pueden borrar. La cadena especifica el punto en el que el paquete es manipulado.
La opción -j <destino> especifica el destino de la regla; es decir, qué hacer si un paquete coincide
con la regla. Ejemplos de destinos predeterminados son ACCEPT, DROP, y REJECT.
Vaya a la página man de iptables para más información sobre las cadenas, opciones y destinos
disponibles.
Cada cadena de iptables se compone de una política predeterminada, y cero o más reglas que
funcionan en conjunto con la política predeterminada para definir el conjunto de reglas del cortafuego.
131
Capítulo 2. Asegurando su Red
La política establecida por defecto para una cadena puede ser DROP o ACCEPT. Los
administradores de sistemas orientados por la seguridad implementan una política por defecto de
DROP, y solo permiten unos pocos paquetes específicos, luego de ser analizados uno por uno. Por
ejemplo, las siguientes políticas bloquean todos los paquetes que lleguen a o que partan desde una
puerta de enlace:
Es también algo recomendado que a cualquier paquete reenviado — tráfico de red que es enrutado
desde el cortafuegos hacia su nodo de destino — también le sea negada la entrada, para poder así
restringir las posibles exposiciones inadvertidas de clientes internos a Internet. Para hacerlo, utilice la
siguiente regla:
Cuando haya establecido las políticas por defecto para cada cadena, puede crear y guardar las reglas
siguientes para su red y requerimientos de seguridad particulares.
Las siguientes secciones describen cómo guardar las reglas iptables y delinea algunas de las reglas
que puede implementar cuando construya su cortafuego con iptables.
Sin embargo, con una política por defecto de bloquear todos los paquetes entrantes, salientes y
reenviados, es imposible que los usuarios del cortafuego/puerta de enlace y los usuarios internos de
la LAN puedan comunicarse entre ellos, o con recursos externos.
Para permitir que los usuarios realicen funciones relacionadas con la red y de que puedan usar
aplicaciones de red, los administradores deben abrir ciertos puertos para la comunicación.
Por ejemplo, para permitir el acceso al puerto 80 en el cortafuego, agregar la siguiente regla:
Esto permite a los usuarios navegar sitios que se comunican usando el puerto estándar 80. Para
permitir el acceso a sitios web seguros (por ejemplo, https://www.ejemplo.com/), también necesita
proveer el acceso al puerto 443, como sigue:
132
Reglas FORWARD y NAT
Importante
Cuando se crea un conjunto de reglas de iptables, el orden es importante.
La regla para permitir los paquetes de 192.168.100.13 debe estar antes de la que
elimina los restantes de la subred.
Para insertar una regla en una ubicación específica en una cadena existente, use la
opción -I. Por ejemplo:
Esta regla es insertada como la primera regla en la cadena INPUT para permitir el
tráfico en el dispositivo loopback local.
Pueden suceder que en determinadas oportunidades se necesite un acceso remoto a la LAN. Los
servicios seguros, por ejemplo SSH, se pueden utilizar para encriptar la conexión remota a los
servicios de la LAN.
Administradores con recursos basados en PPP, o accesos de tipo dial-up (como bancos de módems,
o cuentas masivas de ISP), pueden ser utilizados para sortear con éxito las barreras del cortafuegos.
Debido a que son conexiones directas, las conexiones de módems se encuentran típicamente detrás
de un cortafuegos/puerta de enlace.
Sin embargo, pueden hacerse excepciones para los usuarios remotos con conexiones de banda
ancha. Usted puede configurar iptables para aceptar conexiones de clientes remotos SSH. Por
ejemplo, las siguientes reglas permiten acceso remoto SSH:
Estas reglas permiten ingreso y egreso para un sistema individual, como una PC directamente
conectada a Internet, o a un cortafuegos/puerta de enlace. Sin embrago, no permiten a los nodos
detrás de un cortafuegos/puerta de enlace que tengan acceso a estos servicios. Para permitir
acceso LAN a estos servicios, puede utilizar Network Address Translation (NAT) con reglas de filtro
iptables.
Los administradores deben, por lo tanto, encontrar formas alternativas de compartir el acceso a
los servicios de Internet, sin darle por ello una dirección IP pública a cada nodo de la LAN. Utilizar
direcciones IP privadas es la manera más común de permitirle a todos los nodos de una LAN que
tengan un acceso correcto, tanto interno como externo, a los servicios de red.
133
Capítulo 2. Asegurando su Red
Los enrutadores de borde (como los cortafuegos) pueden recibir transmisiones entrantes desde
Internet y enrutar los paquetes hacia el nodo LAN correspondiente. Al mismo tiempo, los cortafuegos/
puertas de enlace pueden enrutar peticiones salientes de un nodo de la LAN hacia el servicio de
Internet remoto.
Este reenvío de trafico de red puede algunas veces convertirse en algo peligroso, especialmente con
la disponibilidad de herramientas de crackeo modernas que pueden espiar direcciones IP internas y
hacer que el el equipo del atacante remoto actúe como un nodo de su LAN.
Para impedir esto, iptables provee políticas de ruteado y reenvío que se pueden implementar para
prevenir el uso anormal de los recursos de red.
La cadena FORWARD permite a un administrador controlar hacia dónde se pueden rutear los
paquetes dentro de la LAN. Por ejemplo, para permitir el reenvío para toda la LAN (asumiendo que
el cortafuego/puerta de enlace tiene asignado una dirección IP interna en eth1), use las siguientes
reglas:
Esta regla le da a los sistemas detrás del cortafuego/puerta de enlace el acceso a la red interna. La
puerta de enlace rutea los paquetes desde un nodo de la LAN a su nodo destino deseado, pasando
todos los paquetes a través del dispositivo eth1.
Nota
Por defecto, la política IPv4 en kernels de Fedora deshabilita el soporte para reenvío
de IP. Esto evita que máquinas que corran Fedora funcionen como un ruteador
dedicado. Para habilitar el reenvío de IP, use el siguiente comando:
net.ipv4.ip_forward = 0
net.ipv4.ip_forward = 1
134
Reglas FORWARD y NAT
Para permitir que los nodos de una LAN con direcciones IP privadas puedan comunicarse con redes
públicas externas, configure su cortafuegos para que realice enmascaramiento de IP, que enmascara
las peticiones desde los nodos LAN con la dirección IP del cortafuegos del dispositivo externo (en
este caso, eth0):
Esta regla utiliza la tabla de comparación de paquetes NAT (-t nat) y especifica la cadena
predefinida POSTROUTING para NAT (-A POSTROUTING) en el dispositivo externo del cortafuegos
(-o eth0).
POSTROUTING permite que los paquetes puedan ser alterados mientras están abandonando el
dispositivo externo del cortafuegos.
2.8.5.2. Preruteo
Si usted posee un servidor en su red interna que quiere que esté disponible desde el exterior, puede
utilizar -j DNAT, objetivo de la cadena PREROUTING de NAT para especificar una IP de destino,
y un puerto donde los paquetes recibidos que pidan una conexión a su servicio interno, puedan ser
reenviados.
Por ejemplo, si quiere reenviar pedidos HTTP entrantes a su servidor HTTP Apache dedicado en
172.31.0.23, use el siguiente comando:
Esta regla especifica que la tabla nat usa la cadena predefinida PREROUTING para enviar pedidos
HTTP entrantes exclusivamente al la dirección IP destino listado 172.31.0.23.
Nota
Si tiene una política predeterminada de DROP en su cadena FORWARD, debe
agregar una regla para reenviar todos los pedidos HTTP entrantes para que sea
posible el ruteo NAT destino. Para hacerlo, use el siguiente comando:
Esta regla reenvía todos los pedidos HTTP entrantes desde el cortafuego al destino
pretendido; el Servidor HTTP APache detrás del cortafuego.
135
Capítulo 2. Asegurando su Red
Por ejemplo, para establecer una regla para enrutar peticiones HTTP entrantes a un servidor
dedicado HTTP en 10-0-4-2 (fuera del rango 192.168.1.0/24 de la LAN), NAT utiliza la tabla
PREROUTING para reenviar los paquetes a la dirección apropiada:
Con este comando, todas las conexiones HTTP al puerto 80 provenientes desde fuera de la LAN
son encaminadas al servidor HTTP en la red separada del resto de la red interna. Esta forma de
segmentación de red puede proveer seguridad permitiendo conexiones HTTP a máquinas en la red.
Si el servidor HTTP está configurado para aceptar conexiones seguras, entonces el puerto 443 debe
ser reenviado también.
Por ejemplo, algunos troyanos examinan redes para ver los servicios en los puertos 31337 a 31340
(llamados los puertos elite en la terminología de craqueo).
Dado que no hay servicios legítimos que se comunican vía estos puertos no estándares, su bloqueo
puede disminuir efectivamente las posibilidades de que nodos infectados en su red se comuniquen
con sus servidores maestros remotos.
Las siguientes reglas eliminan todo el tráfico TCP que intenta usar el puerto 31337:
[root@myServer ~ ] # iptables -A OUTPUT -o eth0 -p tcp --dport 31337 --sport 31337 -j DROP
[root@myServer ~ ] # iptables -A FORWARD -o eth0 -p tcp --dport 31337 --sport 31337 -j DROP
También se puede bloquear conexiones salientes que intenten suplantar los rangos de direcciones IP
privadas para infiltrarse en su LAN.
Por ejemplo, si su red usa el rango 192.168.1.0/24, se puede diseñar una regla que instruya al
dispositivo de red del lado de Internet (por ejemplo, eth0) para que descarte cualquier paquete en ese
dispositivo con una dirección en el rango IP de su red local.
Dado que se recomienda rechazar paquetes reenviados como una política predeterminada, cualquier
otra dirección IP mentida al dispositivo del lado externo (eth0) se rechaza automáticamente.
136
IPTables y el seguimiento de la conexión
Nota
Existe una distinción entre los destinos DROP y REJECT cuando se trabaja con reglas
agregadas.
Los administradores pueden usar su propia discreción cuando usen estos destinos.
Sin embargo, para evitar la confusión del usuario e intentos de continuar conectando,
el destino REJECT es recomendado.
• NEW — Un paquete que pide una nueva conexión, tal como un pedido HTTP.
• RELATED — Un paquete que está pidiendo una nueva conexión, pero que es parte de una
existente. Por ejemplo, FTP usa el puerto 21 para establecer una conexión, pero los datos se
transfieren en un puerto diferente (normalmente el puerto 20).
Puede utilizar toda la funcionalidad del rastreo de conexión iptables con cualquier protocolo, aún
si él mismo se encuentra inactivo (como por ejemplo un protocolo UDP). EL siguiente ejemplo le
muestra una regla que utiliza rastreo de conexión para reenviar solamente los paquetes que están
asociados con una conexión establecida:
2.8.8. IPv6
La introducción de la siguiente generación del Protocolo de Internet, llamado IPv6, expande más allá
de los límites de las direcciones de 32-bit de IPv4 (o IP). IPv6 soporta direcciones de 128-bit, y las
redes transportadoras que pueden soportar IPv6 son por lo tanto capaces de manejar un número más
grande de direcciones ruteables que el IPv4.
Fedora soporta reglas de cortafuego para IPv6 utilizando el subsistema Netfilter 6 y el comando
ip6tables. En Fedora 12, los servicios de IPv4 e IPv6 están habilitados por defecto.
La sintaxis del comando ip6tables es idéntica a iptables en todos los aspectos menos en que
soporta direcciones de 128-bit. Por ejemplo, use el siguiente comando para habilitar conexiones SSH
en un servidor de red para IPv6:
137
Capítulo 2. Asegurando su Red
Para más información acerca de redes IPv6, vaya a la Página de Información sobre IPv6 en http://
www.ipv6.org/.
• Linux Firewalls, por Robert Ziegler; New Riders Press — contiene gran cantidad de información
para poder levantar cortafuegos utilizando tanto ipchains de un kernel 2.2, como Netfilter o
iptables. También son tratados otros temas relacionados con la seguridad, como problemas con
el acceso remoto, o detección de intrusos en el sistema.
2.9. IPTables
Con Fedora están incluidas herramientas avanzadas para el filtrado de paquetes — el proceso dentro
de kernel que permite controlar a los paquetes de red mientras están ingresando a nuestro entorno,
mientras lo están recorriendo y cuando lo abandonan. Las versiones del kernel anteriores a la 2.4,
dependían de ipchains para el filtrado de paquetes, y utilizaban listas de reglas aplicadas a los
paquetes en cada paso del proceso de filtrado. El kernel 2.4 introdujo la utilización de iptables
(también llamado netfilter), que si bien es similar a ipchains, expande enormemente el rango y la
posibilidad de control disponible para filtrar los paquetes de red.
138
Filtrado de Paquete
El siguiente capítulo se dedica a los conceptos básicos del filtrado de paquetes, explica las diferentes
opciones disponibles con los comandos de iptables, y explica como las reglas de filtrado pueden
ser preservadas entre los reinicios del sistema.
Diríjase a la Sección 2.9.6, “Recursos adicionales” para obtener instrucciones sobre cómo construir
reglas de iptables y configurar un cortafuego basado en ellas.
Importante
El mecanismo de un cortafuegos establecido por defecto con un kernel 2.4 o superior
es iptables, pero iptables no puede ser utilizado si ipchains se encuentra en
ejecución. Si ipchains está presente en el momento del arranque, el kernel envía
un mensaje de error y no puede iniciar iptables.
• nat — Se usa para alterar paquetes que crean una nueva conexión y para Network Address
Translation (NAT).
Cada tabla tiene un grupo de cadenas predefinidas, que corresponden a las acciones realizadas por
netfilter sobre el paquete.
• OUTPUT — Altera los paquetes de la red generados localmente antes de que se envíen.
• OUTPUT — Altera los paquetes de la red generados localmente antes de que se envíen.
139
Capítulo 2. Asegurando su Red
• PREROUTING — Altera los paquetes que vienen de la red antes de ser ruteados.
Cada paquete de red recibido por, o enviado con un sistema Linux es sujeto de (o por) al menos
una tabla. Sin embargo, un paquete puede ser sujeto por varias reglas pertenecientes a cada tabla,
antes de poder emerger al final de la cadena. La estructura y el propósito de estas reglas pueden
variar, pero por lo general lo que buscan es un paquete yendo o viniendo desde una dirección IP
determinada (o conjunto de direcciones), cada vez que se utilice un protocolo y un servicio de red
determinados.
Nota
Por defecto, las reglas del cortafuego se graban en los archivos /etc/sysconfig/
iptables o /etc/sysconfig/ip6tables.
Dejando de lado el destino que tengan, cuando los paquetes se correspondan con alguna regla
particular de alguna de estas tablas, un destino o acción es aplicada a ellos. Si la regla especifica
una acción ACCEPT para un paquete que se corresponde con ella, ese paquete se saltea el resto
de la regla y le es permitido continuar hacia su destino. Si una regla especifica una acción DROP, a
ese paquete se le niega acceso al sistema y nada es devuelto al equipo que lo envió. Si una regla
especifica la acción QUEUE, el paquete es colocado en un espacio de usuario. Si una regla especifica
la acción optativa REJECT, el paquete es abandonado, pero un paquete de error es a la vez enviado a
quien lo originó.
Cada cadena posee una política por defecto para las acciones de ACCEPT, DROP, REJECT, o QUEUE.
Si ninguna de estas reglas en la cadena se aplica al paquete, entonces el paquete es tratado de
acuerdo a la política establecida por defecto.
El comando iptables configura estas tablas, así como crea algunas nuevas si es necesario.
• Fuente/Destino del Paquete — Especifica qué paquete se filtra basado en el fuente/destino del
paquete.
• Destino — Especifica qué acción se toma sobre los paquetes que coinciden con el criterio de más
arriba.
Para obtener más información acerca de opciones específicas acerca de estos aspectos de
los paquetes, por favor vea la Sección 2.9.2.4, “Opciones de coincidencia de IPTables” y la
Sección 2.9.2.5, “Opciones de destino”.
140
Opciones de la línea de comandos de IPTables
Las opciones utilizadas con reglas específicas de iptables, para que puedan ser válidas, deben ser
agrupadas lógicamente, fundamentadas en el propósito y las condiciones de la regla en su totalidad.
En el recordatorio de esta sección se explican opciones comúnmente utilizadas para el comando
iptables.
<table-name> — Especifica a qué tabla se aplica la regla. Si se omite, se usa la tabla filter.
<command> — Especifica la acción a realizar, tal como agregar o eliminar una regla.
<parameter>-<option> pairs — Los parámetros y las opciones asociadas que especifican cómo
se procesa el paquete que coincide con una regla.
Por ejemplo, un comando para eliminar una regla de una cadena puede ser muy corto:
En contraste, un comando que añada una regla que filtre los paquetes provenientes de una subred
determinada, utilizando una variedad de parámetros y opciones específicas, podría ser bastante
extenso. Cuando construya comandos iptables, es importante recordar que algunos parámetros
y opciones requieren de otros parámetros y de otras opciones para poder constituir una regla válida.
Esto puede producir un efecto cascada, con los futuros parámetros pidiendo otros nuevos. La regla no
será válida hasta que no se satisfagan cada parámetro y cada opción que requiera otro conjunto de
opciones y parámetros.
Con iptables -h se puede ver una lista comprensiva de la estructura de los comandos de
iptables.
• -C — Verifica una regla determinada antes de añadirla a la cadena especificada por el usuario.
Este comando puede ayudarle a construir reglas complejas de iptables al solicitarle parámetros y
opciones adicionales.
141
Capítulo 2. Asegurando su Red
• -D <integer> | <rule> — Elimina una regla de una cadena determinada por su número
(como por ejemplo 5 para la quinta regla de una cadena), o por su especificación. La especificación
de la regla debe coincidir exactamente con la regla existente.
• -E — Renombra una cadena definida por el usuario. Una cadena definida por el usuario es
cualquier cadena que no sea una de las ya existentes, establecidas por defecto. (Vea más abajo la
opción -N para obtener información acerca de como crear cadenas definidas por el usuario). Este
es un cambio de tipo estético y no afecta la estructura de la tabla.
Nota
Si intenta renombrar alguna de las cadenas predeterminadas, el sistema informará
un error de Coincidencia no encontrada. No puede renombrar las cadenas
predeterminadas.
• -h — Provee una lista de estructuras de comando, así como un resumen rápido de los parámetros
y opciones de los comandos.
Importante
Como se mencionó arriba, el orden de las reglas en una cadena determina cuáles
reglas se aplican a qué paquetes. Esto es importante para recordar cuando se
agreguen reglas que usen la opción -A o -I.
• -L — Muestra todas las reglas en la cadena especificada luego del comando. Para listar todas las
reglas de todas las cadenas en la tabla de filtro establecida por defecto, no especifique ni una
cadena ni una tabla. De lo contrario, la siguiente sintaxis debería ser utilizada para listar las reglas
de una cadena determinada, en una tabla determinada:
Las opciones adicionales para la opción -L del comando, que proveen el número de regla y
permiten descripciones de reglas más detalladas se describen en la Sección 2.9.2.6, “Opciones de
listado”.
• -N — Crea una nueva cadena con un nombre dado por el usuario. El nombre debe ser único, sino
se mostrará un mensaje de error.
142
Opciones de la línea de comandos de IPTables
• -P — Pone la política predeterminada para la cadena especificada, para que cuando los paquetes
atraviesen toda la cadena sin encontrar una regla con la que coincidan, se los envía al destino
especificado, sea ACCEPT o DROP.
• -X — Borra una cadena definida por el usuario. No se puede borrar una cadena predefinida.
• -Z — Pone los contadores de bytes y de paquetes a 0 en todas las cadenas de una tabla.
• -c — Reinicia los contadores de una regla particular. Este parámetro acepta las opciones PKTS y
BYTES para especificar qué contadores resetear.
• -d — Pone el destino por nombre, dirección IP o red para un paquete que coincide con la regla.
Cuando se especifique una red, los siguientes formatos de dirección de IP /máscara de red son
soportados:
Puede usar el signo de exclamación (!) después de este parámetro para especificar que solamente
se aceptan paquetes desfragmentados.
Nota
La distinción entre paquetes fragmentados y defragmentados es deseable, sin
importar que los paquetes fragmentados sean una parte estándar del protocolo IP.
Originalmente diseñada para permitir que los paquetes IP viajen a través de redes
con marcos de diferentes tamaños, hoy en día la fragmentación es comúnmente
utilizada para generar ataques DoS, mediante paquetes mal formados. En este
aspecto, vale la pena saber que IPv6 no permita en absoluto la fragmentación.
• -i — Establece la interfaz de red entrante, como ser por ejemplo, eth0 o ppp0. Con iptables,
este parámetro opcional solo puede ser utilizado con las cadenas de INPUT y FORWARD, cuando
sean utilizadas con la tabla de filter, y la cadena PREROUTING con las tablas nat y mangle.
• El signo de exclamación (!) — Revierte la directiva, significando que las interfaces especificadas
de excluyen de esta regla.
143
Capítulo 2. Asegurando su Red
• Signo de suma (+) — Un carácter comodín utilizado para relacionar a todas las interfaces que se
correspondan con una cadena determinada. Por ejemplo, el parámetro -i eth+ aplicaría esta
regla a cualquier interfaz Ethernet, pero excluiría el resto de las interfases, como por ejemplo,
ppp0.
Si el parámetro -i se usa pero no se especifica una interfaz, entonces todas las interfases son
afectadas por esta regla.
Existen también a disposición algunas opciones extendidas, a través de módulos cargados por
defecto con el paquete RPM iptables de Fedora. Algunas de las acciones válidas de ese módulo
son LOG, MARK, y REJECT, entre otras. Para obtener mayor información acerca de estas y de otras
acciones, consulte la página man de iptables.
Esta opción también puede usarse para dirigir el paquete coincidente a una regla particular en
una cadena del usuario fuera de la cadena actual, para que se le puedan aplicar otras reglas al
paquete.
Si no se especifica un destino, el paquete se mueve a la regla siguiente sin hacer nada. El contador
de esta regla, sin embargo, se incrementa por uno.
• -o — Establece la interfaz de red saliente para una regla. Esta opción sólo es válida para las
cadenas OUTPUT y FORWARD en la tabla filter, y para la cadena POSTROUTING en las
tablas nat y mangle tables. Este parámetro acepta las mismas opciones que el parámetro para la
interfaz de red entrante (-i).
• -p <protocol> — Establece el protocolo IP afectado por la regla. Este puede ser icmp, tcp,
udp, o all, o también puede ser un valor numérico, representando alguno de estos protocolos, o
alguno diferente. También puede utilizar cualquiera de los protocolos listados en el archivo /etc/
protocols.
El protocolo "all" significa que esta regla se aplica a todos los protocolos soportados. Si no se lista
ningún protocolo con esta regla, por defecto se asume "all".
• -s — Pone el fuente de un paquete particular usando la misma sintaxis del parámetro de destino (-
d).
144
Opciones de la línea de comandos de IPTables
Las definiciones de los servicios son provistas en el archivo /etc/services. Para una mejor
lectura, es recomendable que se utilice el nombre de los servicios, en lugar de los números de
puertos.
Advertencia
Asegure el archivo /etc/services de manera de poder evitar que sea editado por
usuarios no autorizados. Si este archivo es editable, los crackers pueden utilizarlo
para habilitar puertos en su equipo que de otra manera permanecerían cerrados.
Para segurar este archivo, ingrese los siguiente comandos siendo usuario root:
Para configurar esta opción, use un nombre de servicio de red (tal como www o smtp); o un número
de puerto; o un rango de números de puerto.
Para especificar un rango de números de puerto, separe los dos números con dos puntos (:). Por
ejemplo: -p tcp --dport 3000:3200. El rango más grande aceptable es 0:65535.
Use el signo de exclamación (!) después de la opción --dport para que seleccione todos los
paquetes que no usen ese servicio de red o puerto.
Para navegar por los nombres o alias de servicios de red y sus números de puerto, vea el archivo /
etc/services.
• --sport — Pone el puerto de origen del paquete y usa las mismas opciones que --dport. La
opción --source-port es sinónimo de --sport.
• --syn — Se aplica a todos los paquetes TCP diseñados para iniciar una comunicación,
comúnmente llamados paquetes SYN. Cualquier paquete que lleve datos no se toca.
Use un signo de exclamación (!) después de --syn para que seleccione los paquetes no-SYN.
• --tcp-flags <tested flag list> <set flag list> — Permite paquetes TCP que
tengan ciertos bits (banderas) específicos puestos, para que coincidan con la regla.
145
Capítulo 2. Asegurando su Red
• ACK
• FIN
• PSH
• RST
• SYN
• URG
• ALL
• NONE
Por ejemplo, una regla iptables que contenga las siguientes especificaciones solo se
corresponderá con paquetes TCP que tengan definida la marca SYN, y que no tengan definidas las
marcas ACK ni FIN:
Use el signo de exclamación (!) después de --tcp-flags para revertir el efecto de coincidencia
de la opción.
• --dport — Especifica el puerto de destino del paquete UDP, utilizando el nombre del servicio,
el número de puerto, o rango de números de puerto. La opción de correspondencia --
destination-port es equivalente.
• --sport — Especifica el puerto de origen del paquete UDP, utilizando el nombre del servicio, el
número de puerto, o rango de números de puertos. La opción de correspondencia --source-
port es equivalente.
Con las opciones --dport y --sport, para especificar un rango válido de puertos, separe ambos
números del rango con dos puntos (:). Por ejemplo: -p tcp --dport 3000:3200. El rango válido
más extenso que puede aceptarse es 0:65535.
• --icmp-type — Establece el nombre y número del tipo de ICMP a corresponderse con la regla.
Puede obtenerse una lista de nombres ICMP válidos al ingresar el comando iptables -p icmp
-h.
146
Opciones de la línea de comandos de IPTables
Para utilizar un módulo de comparación, cargue el módulo por su nombre con -m <module-name>,
donde <module-name> es el nombre del módulo.
Por defecto hay disponibles muchos módulos. También puede crear módulos para proveer
funcionalidad adicional.
• Módulo limit — Pone límites sobre cuántos paquetes se toman para una regla particular.
Cuando se usa junto con el destino LOG, el módulo limit puede prevenir una inundación de
paquetes coincidentes que pudieran sobrecargar al sistema de log con mensajes repetitivos o
acabar los recursos del sistema.
Diríjase a la Sección 2.9.2.5, “Opciones de destino” para obtener mayor información sobre LOG.
• --limit-burst — Pone un límite en el número de paquetes que pueden coincidir con la regla
en cada momento.
Esta opción se especifica como un entero y no se debe usar junto con la opción --limit.
• NEW — El paquete chequeado es para crear una conexión nueva o es parte de una conexión
de doble vía que no fue vista previamente. Necesita aceptar este estado si quiere permitir
conexiones nuevas a un servicio.
• RELATED — El paquete coincidente está iniciando una conexión relacionada de alguna manera
a otra existente. Un ejemplo de esto es FTP, que usa una conexión para el control del tráfico
(puerto 21) y una conexión separada para la transferencia de datos (puerto 20).
147
Capítulo 2. Asegurando su Red
Estos estados de conexión pueden ser utilizados combinados con otros, si se los separa con
comas, como por ejemplo -m state --state INVALID,NEW.
• --mac-source — Hace corresponder una dirección MAC de la tarjeta de interfaz de red que
haya enviado el paquete. Para excluir una dirección MAC de la regla, coloque un signo de
admiración (!) luego de la opción de correspondencia --mac-source.
Vea en la página man de iptables para más opciones de comparación disponibles a través de
módulos.
• <user-defined-chain> — Una cadena definida por el usuario dentro de la tabla. Los nombres
de las cadenas definidas por el usuario deben ser únicos. Esta acción pasa el paquete a la cadena
especificada.
• DROP — Descarta el paquete sin responder. El sistema que mandó el paquete no es notificado de la
falla.
• QUEUE — El paquete es encolado para su manejo por una aplicación en el espacio del usuario.
• RETURN — Detiene el chequeo del paquete contra las reglas restantes de la cadena. Si el paquete
con un destino RETURN coincide con una regla en una cadena llamada por otra cadena, el paquete
es devuelto a la primera cadena y continúa el chequeo donde quedó antes de saltar. Si la regla
RETURN se usa en una cadena predefinida y el paquete no se puede mover a una cadena previa,
se usa el destino predeterminado para la cadena.
Además, existen a disposición diversos complementos que permiten especificar otros destinos. Estos
complementos son llamados módulos de destino o módulos de opción de concordancia y muchos
de ellos sólo se aplican a tablas y situaciones específicas. Para obtener más información acerca de
los módulos de opción de concordancia, diríjase a la Sección 2.9.2.4.4, “Módulos adicionales para
opciones de coincidencia”.
Existen numerosos módulos de destino extendidos, muchos de los cuales solo se aplican a ciertas
tablas o situaciones. Algunos de los más populares incluidos por defecto en Fedora son:
• LOG — Registra todos los paquetes que se correspondan con esta regla. Debido a que los
paquetes son registrados por el kernel, el archivo /etc/syslog.conf determina donde son
escritas estas entradas de registro. Por defecto, son ubicadas en el archivo /var/log/messages.
148
Opciones de la línea de comandos de IPTables
Hay opciones adicionales que se pueden usar después del destino LOG para especificar la forma en
que se realiza el log:
• --log-prefix — Pone una cadena de hasta 29 caracteres antes de la línea de registro cuando
se escribe. Esto es útil cuando se escribe filtros syslog para usar junto con el registrado de
paquetes.
Nota
Debido a una cuestión con esta opción, se debe agregar un espacio al final del
valor log-prefix.
• REJECT — Envía un paquete de error como respuesta al sistema remoto y descarta el paquete.
Otras extensiones de acción, incluidas aquellas que son útiles para el enmascaramiento de IP
utilizando la tabla nat, o mediante alteración de paquete utilizando la tabla mangle, pueden ser
encontradas en la página man de iptables.
• -v — Muestra información adicional, como por ejemplo la cantidad de paquetes y los bytes que ha
procesado cada cadena, la cantidad de paquetes y los bytes que se ha correspondido con cada
regla, y qué interfases se aplican a una regla determinada.
• -x — Expande los números a sus valores exactos. En un sistema activo, el número de los
paquetes y la cantidad de bytes procesados por una cadena o regla determinada puede estar
abreviado en Kilobytes, Megabytes (Megabytes) o Gigabytes. Esta opción obliga a ser
mostrado el número entero.
• -n — Muestra las direcciones IP y los números de puerto en su formato numérico, en vez del
formato predeterminado de nombre de equipo y nombre de servicio.
149
Capítulo 2. Asegurando su Red
• --line-numbers — Muestra las reglas en cada cadena junto a su orden numérico en dicha
cadena. Esta opción es útil si se intenta eliminar una regla específica de una cadena, o para saber
dónde insertar una regla dentro de una cadena.
• -t <table-name> — Especifica el nombre de una tabla. Si se omite, se usa filter como nombre
de tabla.
Esto ejecuta el programa init de iptables, que a su vez ejecuta el programa /sbin/iptables-
save y escribe la configuración actual de iptables a /etc/sysconfig/iptables. El archivo
existente /etc/sysconfig/iptables es guardado como /etc/sysconfig/iptables.save.
La próxima vez que el sistema se reinicie, el programa init de iptables aplica nuevamente las
reglas guardadas en /etc/sysconfig/iptables utilizando el comando /sbin/iptables-
restore.
Si bien siempre es una buena idea probar una nueva regla iptables antes de incluirla en el archivo
/etc/sysconfig/iptables, es posible copiar reglas iptables a este archivo, desde la misma
versión de un sistema diferente del mismo archivo. Esto permite una rápida distribución de los
conjuntos de reglas iptables en diversas máquinas.
También puede grabar las reglas de iptables a un archivo separado para distribuir, respaldar u otros
propósitos. Para guardar sus reglas de iptables, ingrese el siguiente comando como root:
Importante
Si va a distribuir el archivo /etc/sysconfig/iptables a otras máquinas, debe
teclear /sbin/service iptables restart para que las nuevas reglas tengan
efecto.
Nota
Fíjese la diferencia entre el comando iptables (/sbin/iptables), que es
utilizado para manipular las tablas y cadenas que constituyen las funcionalidades de
iptables, y el servicio iptables (/sbin/iptables service), que es utilizado
para activar y desactivar el servicio de iptables en sí.
150
Programas de control de IPTables
Si este comando no muestra salida, significa que no está cargado. Si es necesario, use el
comando /sbin/rmmod para eliminar el módulo.
• stop — Si el cortafuego está ejecutándose, las reglas del cortafuego en la memoria son
limpiadas y todos los módulos y ayudantes de iptables son descargados.
• status — Muestra el estado del cortafuego y lista todas las reglas activas
La configuración establecida por defecto para esta opción muestra direcciones IP en cada
regla. Para mostrar dominios y nombres de equipos, edite el archivo /etc/sysconfig/
iptables-config y modifique el valor de IPTABLES_STATUS_NUMERIC a no. Para obtener
más información acerca del archivo iptables-config, consulte la Sección 2.9.4.1, “Archivo de
Configuración de los Scripts de Control de IPTables” .
• panic — Limpia todas las reglas del cortafuego. Se configura como política para todas las tablas
a DROP.
Esta opción puede ser útil si se sabe que un servidor está comprometido. En vez de
desconectarlo físicamente de la red o apagarlo, puede usar esta opción para detener todo tráfico
posterior, pero dejando a la computadora lista para un análisis forense.
151
Capítulo 2. Asegurando su Red
Nota
Para utilizar los mismos comandos de initscript para controlar a netfilter para IPv6,
sustituya ip6tables por iptables en los comandos /sbin/service listados
en esta sección. Para obtener mayor información acerca de IPv6 o netfilter, vea
Sección 2.9.5, “IPTables e IPv6”.
• IPTABLES_MODULES — Especifica una lista separada por comas de los módulos iptables
adicionales a cargar cuando se active el cortafuego. Estos pueden incluir el rastreo de conexión y
ayudantes NAT.
• yes — El valor por defecto. Esta opción debe ser puesta para conseguir un estado correcto de
un reinicio o detenida de un cortafuego.
• no — Esta opción debe ser puesta sólo si hay problemas al descargar los módulos de netfilter.
• no — El valor por defecto. No guarda las reglas existentes cuando el cortafuego es detenido.
152
IPTables e IPv6
• yes — El valor predeterminado. Solo devuelve la dirección IP dentro de una salida de estado.
La mayoría de las directivas para este comando son idénticas a aquellas utilizadas para iptables,
excepto que la tabla nat no es aún soportada. Esto significa que aún no es posible realizar tareas
de traslados sobre direcciones de redes IPv6, como ser, por ejemplo, enmascaramiento y reenvío de
puertos.
Las opciones de configuración para el programa init ip6tables son almacenadas en /etc/
sysconfig/ip6tables-config, y los nombres para cada directiva varían significativamente de los
correspondientes en iptables.
• Sección 2.8, “Cortafuegos” — Contiene un capítulo acerca de la función de los cortafuegos dentro
de una estrategia de seguridad general, así como las estrategias para construir las reglas del
mismo.
153
154
Cifrado
Existen dos clases principales de datos que deben ser protegidos: datos en reposo y datos en
movimiento. Estas clases de datos son protegidas en forma similar utilizando tecnología similar, pero
la forma en que se implementa esta protección puede ser completamente diferente en un caso y en
otro. Por sí solo, ningún modo de protección puede prevenir nuestro sistema de todos los posibles
métodos en que puede llegar a ser dañado, ya que la misma información puede estar en descanso y
en movimiento en diferentes lugares y al mismo tiempo.
Desde la liberación de Fedora 9, ésta y cualquier versión posterior tiene soporte nativo para Cifrado
LUKS. LUKS (por las iniciales en inglés de Linux Unified Key Setup-on-disk-format) va a cifrar las
particiones de su disco duro de modo que cuando su computadora se encuentre apagada, sus datos
estarán protegidos. Esto también protegerá los datos de su computadora de atacantes que intenten
ingresar a su equipo en el modo de usuario único, o que hubieran conseguido el acceso de otra
forma.
Las herramientas de cifrado total del disco duro, como LUKS, solo protegen sus datos cuando
su computadora se encuentra apagada. Una vez que la computadora se encienda, y LUKS haya
descifrado el disco, los archivos en ese disco quedarán disponibles para cualquiera que pueda
acceder normalmente a ellos. Para proteger sus archivos cuando su computadora esté encendida,
utilice la herramienta de cifrado total del disco combinada con alguna otra, como ser por ejemplo, el
cifrado de archivos. Recuerde también bloquear su computadora siempre que se encuentre lejos de
ella. Una frase de acceso protegiendo el salvapantallas, establecida para que se active a los pocos
minutos de inactividad del equipo, es una buena forma de mantener a los intrusos alejados de él.
155
Capítulo 3. Cifrado
El cifrado de archivos está orientado para proteger un archivo luego que éste haya abandonado
su computadora, como cuando, por ejemplo, envía un CD a través del correo postal. Algunas
herramientas para cifrar archivos pueden dejar rastros de aquellos archivos que cifran, rastros que
podrían ser recuperados en algunas circunstancias por atacantes que tengan acceso físico a su
equipo. Para proteger de este tipo de ataques a los contenidos de los archivos, utilice la herramienta
de cifrado de archivos combinada con alguna otra, como ser por ejemplo, el cifrado total del disco.
Los datos en movimiento son particularmente vulnerables a los atacantes, ya que ellos no necesitan
estar cerca de la computadora en donde estos datos son almacenados: simplemente necesitan estar
en algún punto del camino que esos datos están recorriendo. Los túneles de cifrado pueden proteger
los datos a lo largo del camino de las comunicaciones.
SSH es muy fácil de activar. Simplemente iniciando el servicio SSH, el sistema comenzará a aceptar
conexiones y les permitirá acceder al sistema sólo a aquellas que, durante el proceso de conexión,
indiquen correctamente tanto un nombre de usuario como una contraseña. El TCP estándar para las
conexiones SSH es 22, sin embargo esto puede cambiarse modificando el archivo de configuración
/etc/ssh/sshd_config, y reiniciando el servicio. Este archivo también contiene otras opciones de
configuración para SSH.
SSH también ofrece la posibilidad de túneles cifrados entre computadoras, pero utilizando solamente
1
un puerto. El reenvío de puertos puede ser realizado sobre un túnel SSH , pero la utilización del
reenvío de puertos no es tan fluido como una VPN.
1
http://www.redhatmagazine.com/2007/11/27/advanced-ssh-configuration-and-tunneling-we-dont-need-no-stinking-vpn-software
156
Cifrado de disco LUKS (Linux Unified Key Setup-on-disk-format)
La implementación de LUKS por defecto de Fedora es AES 128 con un hashing SHA256. Los
cifradores disponibles son:
2
• AES - Advanced Encryption Standard - FIPS PUB 197
• Serpent
3
• cast5 - RFC 2144
4
• cast6 - RFC 2612
Advertencia
Al seguir este procedimiento se eliminarán todos los datos de la partición que está
cifrando. ¡Perderá toda la información! ¡Asegúrese de hacer un respaldo de sus
datos en una fuente externa antes de comenzar!
Si está corriendo una versión de Fedora anterior a la 9 y quiere cifrar una partición, o si quiere cifrar
una partición después de la instalación de la versión actual de Fedora, las siguientes instrucciones
son para Ud. El ejemplo que ofrecemos más abajo muestra elcifrado de una partición /home pero
puede utilizarse sobre cualquier partición.
El siguiente procedimiento borrará todos los datos existentes, de modo que es conveniente
asegurarse de haber hecho un respaldo antes de comenzar. También es necesario tener una
partición separada para /home (en nuestro caso es /dev/VG00/LV_home). Todo lo que se muestra
a continuación debe ser realizado como usuario root. Cualquiera de las etapas en este método no
puede realizarse a no ser que la anterior haya sido exitosa.
157
Capítulo 3. Cifrado
3. Si falla, use fuser para identificar y eliminar los procesos que retienen a /home: fuser -mvk /
home
Importante
El proceso, sin embargo, es fundamental para obtener una buena protección
contra los intentos de descifrado. Sólo déjelo correr toda la noche.
13. Edite su /etc/fstab, elimine la antigua entrada de /home, y agregue /dev/mapper/home /home
ext3 defaults 1 2
17. La entrada en /etc/crypttab hace que su computadora le pida su frase de acceso luks al arrancar
158
Enlaces de interés
• COMO: Generando un volumen físico (PV) cifrado, utilizando otro disco duro, pvmove, y un CD o
6
DVD vivo de Fedora
• Instale 7-Zip con permisos de usuario sudo: sudo yum install p7zip
• Abra una terminal: Haga clic sobre ''Aplicaciones'' -> ''Herramientas del
sistema '' -> ''Terminal''
• Comprima y cifre: (ingrese una contraseña cuando le sea pedido) 7za a -mhe=on -ms=on -p
Documentos.7z Documentos/
159
Capítulo 3. Cifrado
GPG también puede ser utilizado para firmar y/o cifrar archivos almacenados en su computadora, o
en un disco de red. Esto puede agregar protección adicional al prevenir que un archivo sea alterado o
leído por personas que no hayan sido autorizadas para hacerlo.
Para utilizar GPG para autenticar o cifrar correos electrónicos, primero debe generar sus llaves
públicas y privadas. Luego de haberlo hecho, debe cpnfigurar su cliente de correo electrónico para
que las pueda utilizar.
Para crear una llave, desde el menú ''Aplicaciones > Accessorios'' elija ''Contraseñas y llaves de
cifrado'', que inicia la aplicación Seahorse. Luego, desde el menú ''Llave'', elija ''Generar nueva
llave...'', luego ''Llave PGP '', y luego haga clic en ''Continuar''. Ingrese su nombre completo, dirección
de correo electrónico, y un comentario adicional optativo que explique quién es usted (por ejemplo:
Juan Pérez, jperez@ejemplo.com, El Grande). Haga clic en ''Crear''. Se mostrará un diálogo
8
http://www.7-zip.org/download.html
160
Generar claves GPG en KDE
pidiéndole una frase de acceso para la llave. Elija una frase de acceso poderosa, pero que también le
sea fácil de recordar. Haga clic en ''OK'' y la llave será creada.
Advertencia
Si se olvida su frase de acceso, la clave no podrá ser utilizada y cualquier dato
encriptado por ella será perdido.
Para encontrar su ID de llave GPG, busque en la columna ''ID de llave'' junto a la llave creada recién.
En la mayoría de los casos, si se le solicita el ID de la llave, debería añadir "0x" al ID de la llave, como
por ejemplo "0x6789ABCD". Debería realizar un respaldo de su llave privada y almacenarla en algún
sitio seguro.
Advertencia
Si se olvida su frase de acceso, la clave no podrá ser utilizada y cualquier dato
encriptado por ella será perdido.
Para encontrar su ID de llave GPG, busque en la columna ''ID de llave'' junto a la llave creada recién.
En la mayoría de los casos, si se le solicita el ID de la llave, debería añadir "0x" al ID de la llave, como
por ejemplo "0x6789ABCD". Debería realizar un respaldo de su llave privada y almacenarla en algún
sitio seguro.
El siguiente comando genera un par de claves consistentes en una clave pública y otra privada. El
resto de las personas utilizan su clave pública para autenticar y/o decriptar sus comunicaciones.
Distribuya su clave pública lo mayor que pueda, especialmente a todos aquellos que quieran recibir
comunicaciones auténticas por parte suya, como ser por ejemplo una lista de correo. El proyecto de
documentación de Fedora, por ejemplo, le pide a sus participantes que incluyan su llave pública GPG
en su correo introductorio.
Una serie de mensajes lo dirigen a lo largo del proceso. Presione la tecla Enter para indicar el
valor establecido por defecto si así lo desea. El primer mensaje le pide que elija el tipo de clave que
prefiere:
Por favor elija qué tipo de clave desea: (1) DSA y ElGamal (por defecto) (2) DSA (sólo firma) (4)
RSA (sólo firma) ¿Su elección? En la mayoría de los casos, la establecida por defecto es la elección
161
Capítulo 3. Cifrado
correcta. Una clave DSA/ElGamal le permite no solo firmar documentos, sino también encriptar
archivos.
A continuación, elija el tamaño de la clave: el mínimo es de 768 bits, el establecido por defecto es de
1024 bits, el mayor tamaño sugerido es de 2048 bits. ¿Qué tamaño prefiere? (1024). Nuevamente,
el establecido por defecto es suficiente para la mayoría de los usuarios, y representa un nivel de
seguridad ''extremadamente'' poderoso.
A continuación, elija cuándo expiará la clave. Es una buena idea elegir una fecha de expiración en
lugar de elegir la opción establecida por defecto, que es ''ninguna.''. Si, por ejemplo, la dirección de
correo electrónico de la clave deja de ser válida, una fecha de expiración le recordará a los demás
que dejen de utilizar esa clave pública.
Por favor indique por cuánto tiempo la clave debe ser válida. 0 = la calve no expira, d = la clave expira
en n días, w = la clave expira en n semanas, m = la clave expira en n meses, y = la clave expira en n
años. ¿La clave es válida por? (0)
Ingresar un valor de 1y, por ejemplo, hace que la clave sea válida durante un año. (Puede modificar
esta fecha de expiración luego que la clave haya sido generada, si cambió de parecer.)
Antes que el programa gpg> le pida información para la firma, aparece el siguiente mensaje: ¿Es
correcto (s/n)?. Ingrese scode> para finalizar el proceso.
A continuación, ingrese su nombre y dirección de correo electrónico. Recuerde que este proceso se
trata de autenticarlo a usted como un individuo real. Por esta razón, incluya su verdadero nombre. No
utilice apodos o alias, ya que esto oscurece o disimula su identidad.
Ingrese su dirección de correo electrónico real para su clave GPG. Si elige una falsa o inexistente,
será más difícil para los demás encontrar su clave pública. Esto hace que autenticar sus
comunicaciones sea más difícil. Si está utilizando esta clave GPG para presentarse en una lista de
correo, por ejemplo, ingrese la dirección de correo electrónico que usted utiliza con esa lista.
Utilice el campo de comentario para incluir un apodo o cualquier otra información. (Algunas personas
utilizan diferentes llaves para diferentes propósitos, e identifican cada llave con un comentario, como
por ejemplo "Oficina", o "Proyectos de código abierto".)
En el mensaje de confirmación, ingrese la letra O para continuar si todas las opciones son correctas,
o utilice las opciones propuestas para solucionar cualquier problema. Ingrese una frase de acceso
para su clave secreta. El programa GPG le pide que ingrese dos veces su frase de acceso para
asegurarse que no haya cometido errores de tipeo.
Por último, gpg genera datos aleatorios para hacer que su clave sea lo más auténtica posible. Mueva
su ratón, presione teclas de manera azarosa, o realice alguna otra tarea en el sistema durante este
paso para acelerar el proceso. Una vez ha finalizado, sus claves están completas y listas para ser
utilizadas:
La huella digital de la clave es una "firma" abreviada de su clave. Le permite confirmar a otros que
han recibido su clave pública actual sin haber sido alterada. No necesita anotar esta huella. Para verla
siempre que lo desee, utilice el siguiente comando, sustituyendo su dirección de correo electrónico:
gpg --fingerprint jperez@ejemplo.com
162
Usando GPG con Alpine
Advertencia
Si se olvida su frase de acceso, la clave no podrá ser utilizada y cualquier dato
encriptado por ella será perdido.
1. /home/username/bin debe ser reemplazado con la ruta de instalación que usted especificó
2. En dos lugares, el gpg-identifier luego de _RECIPIENTS_ debería ser reemplazado por su propio
identificador de llave pública GPG. La razón por la que debe hacerlo es por que, si le envía un
mensaje cifrado a "Alicia", ese mensaje también pueda ser cifrado con su llave pública -- si no
hace esto, entonces no podrá abrir ese mensaje en su carpeta de correos enviados, y recordar lo
que le ha escrito.
# This variable takes a list of programs that message text is piped into
# after MIME decoding, prior to display.
display-filters=_LEADING("-----BEGIN PGP")_ /home/max/bin/ez-pine-gpg-incoming
# This defines a program that message text is piped into before MIME
# encoding, prior to sending
sending-filters=/home/max/bin/ez-pine-gpg-sign _INCLUDEALLHDRS_,
/home/username/bin/ez-pine-gpg-encrypt _RECIPIENTS_ gpg-identifier,
/home/username/bin/ez-pine-gpg-sign-and-encrypt _INCLUDEALLHDRS_ _RECIPIENTS_ gpg-
identifier
En el campo llave PGP/GPG, ingrese el ID de la llave GPG que coincida con esta dirección de correo
electónico. Si no está seguro de cuál sea su ID, utilice el siguiente comando: gpg --fingerprint
EMAIL_ADDRESS. El ID de la llave es el mismo que los últimos ocho caracteres (4 bytes) de la huella
digital de la llave. Es una buena idea hacer clic sobre la opción Siempre cifrarme a mí mismo cuando
163
Capítulo 3. Cifrado
sea enviado correo cifrado. Tal vez también quiera seleccionar Siempre firmar mensajes salientes
cuando sea utilizada esta cuenta.
Nota
Si no identifica las llaves públicas como confiables en su administrador de llaves, no
podrá cifrar correos electrónicos a sus dueños, a menos que elija la opción Siempre
confiar en las llaves de mi administrador de llaves cuando se realicen los cifrados. En
su lugar recibirá un diálogo indicando que ha fallado una verificación de confianza
Mientras esté redactando su correo, elija el menú Seguridad, y luego seleccione Firma PGP para
firmar su mensaje. Para cifrar su mensaje, seleccione Cifrado PGP. También puede firmar un mensaje
cifrado, lo que es una sana costumbre. Cuando envía un mensaje, Evolution le pedirá que ingrese
su frase de acceso de llave GPG (luego de tres intentos fallidos, Evolution genera un error). Si
selecciona la opción Recordar la contraseña por el resto de esta sesión, no necesitará utilizar su frase
de acceso nuevamente para firmar o descifrar, a menos que finalice y reinicie Evolution.
Los productos Mozilla tienen soporte para extensiones, que son diferentes complementos que le
agregan nuevas características a la aplicación principal. Las extensiones Enigmail ofrecen soporte
GPG para productos de correo electrónico de Mozilla. Existen versiones de Enigmail tanto para
Mozilla Thunderbird como para Seamonkey de Mozilla Suite. El software Netscape de AOL está
basado en productos Mozilla, y podrían también utilizar esta extensión.
164
Acerca del encriptado de la clave pública
Para poder instalar Enigmail en sistemas Fedora, siga las instrucciones dadas a continuación.
Enigmail utiliza el término OpenPGP en elementos del menú y en las opciones. GPG es una
implementación de OpenPGP, y estos términos pueden entenderse como siendo equivalentes.
En esta página se pueden apreciar capturas de pantalla de Enigmail y GPG en acción: http://
enigmail.mozdev.org/screenshots.html.
165
166
Principios Generales sobre la
Seguridad de la Información
Los siguientes principios generales ofrecen una visión panorámica de algunas buenas actitudes para
adoptar relacionadas con la seguridad:
• encriptar todos los datos transmitidos por la red para ayudar a prevenir ataques de tipo hombre-
en-el-medio, o escuchas. Es importante encriptar de la información de autenticación, como ser
contraseñas.
• si es posible, corra cada servicio de red en un servidor separado para minimizar el riesgo de que
una debilidad en uno de los servicios, se utilice para comprometer a los demás.
• mantenga las cuentas de usuario: genere y aplique una política firme de contraseñas; borre las
cuentas de usuarios que no son utilizadas.
• periódicamente consulte los archivos de registros del sistema y de las diferentes aplicaciones que
utilice. Por defecto, los archivos de registros del sistema que sean pertinentes para la seguridad
del equipo, son almacenados en /var/log/secure y /var/log/audit/audit.log. Nota:
enviar archivos de registros hacia un servidor dedicado ayuda a prevenir que los atacantes puedan
modificar fácilmente los archivos de registros locales, y de este modo evitar ser detectados.
• nunca ingrese como root directamente, a menos de que sea absolutamente necesario. Los
administradores deben usar sudo para ejecutar comandos como root cuando sea necesario. Las
cuentas capaces de usar sudo se especifican en /etc/sudoers, que se edita con el utilitario
visudo.
La Agencia de Defensa de Información de Sistemas (DISA, por las siglas en inglés de Defense
4
Information Systems Agency) ofrece documentación, evaluaciones, y listas con ítems a ser
1
www.nsa.gov
4
http://www.disa.mil/
167
Capítulo 4. Principios Generales sobre la Seguridad de la Información
5
http://iase.disa.mil/index2.html
6
http://iase.disa.mil/stigs/stig/unix-stig-v5r1.pdf
7
http://iase.disa.mil/stigs/checklist/unix_checklist_v5r1-16_20090215.ZIP
8
http://iase.disa.mil/stigs/SRR/unix.html
168
Instalación segura
La seguridad comienza con la primera vez que introduce un CD o DVD para instalar Fedora.
Configurar su sistema en forma segura desde un principio, hace que sea más fácil implementar
configuraciones de seguridad adicional más adelante.
/boot - Esta partición es la primera partición que se lee durante el arranque. El cargador de arranque
y las imágenes del kernel que se usan para arrancar su sistema Fedora se almacenan en esta
partición. Esta partición no debe ser encriptada. Si esta partición se incluye en / y la misma es
encriptada o de alguna forma se vuelve no disponible, entonces su sistema no podrá arrancar.
/home - Cuando los datos del usuario (/home) se almacenan en / en vez de una partición separada,
la partición se puede llenar haciendo que el sistema operativo se vuelva inestable. También, cuando
se actualice su sistema a la siguiente versión de Fedora, poder mantener sus datos en una partición /
home hace que el proceso sea mucho más sencillo, dado que no será sobrescrita durante la
instalación. Si la partición raíz (/) se corrompe, sus datos se perderán para siempre. Usando una
partición separada hay un poco más de protección contra la pérdida de datos. También se puede
elegir esa partición para los respaldos frecuentes.
/tmp y /var/tmp - Ambos directorios /tmp y /var/tmp se usan para almacenar datos que no se necesitan
guardar por mucho tiempo. Sin embargo, si una gran cantidad de datos inundan uno de estos
directorios, puede consumir todo el espacio libre. Si esto pasa y estos directorios se almacenan en /,
entonces su sistema se puede volver inestable y caerse. Por esta razón, es una buena idea la de
trasladar estos directorios a sus propias particiones.
1
http://fedoraproject.org/wiki/Security_Guide/9/LUKSDiskEncryption
169
170
Mantenimiento de Software
Una manutención adecuada del software es extremadamente importante a la hora de asegurar un
sistema. Es fundamental enmendar software que presenta un fallo en el momento inmediato a la
aparición de la solución, de modo de evitar que atacantes que conocen ese fallo, lo aprovechen y se
infiltren en su sistema.
Para usuarios hogareños, las actualizaciones de seguridad deberían ser instaladas lo antes posible.
Configurar instalaciones automáticas de ellas es una manera de evitar el tener que recordar
constantemente hacerlo, pero podría traer aparejado el pequeño riesgo de que un determinado
paquete entre en conflicto con la configuración de su sistema, o con otro software de su equipo.
Para los comercios o para los usuarios hogareños avanzados, las actualizaciones de seguridad
deberían ser probadas y planeadas para ser instaladas. Será necesario utilizar controles adicionales
para proteger el sistema durante el lapso de tiempo existente entre el lanzamiento del parche y su
instalación definitiva. Estos controles dependen de la debilidad en cuestión, pero pueden incluir reglas
de cortafuegos adicionales, o el uso de cortafuegos externos, o cambios en las configuraciones del
sistema.
En Gnome, puede encontrar controles para sus actualizaciones en System -> Preferencias
-> Actualizaciones de software. En KDE, esta herramienta se encuentra ubicada en:
Aplicaciones -> Configuración -> Actualizaciones de software.
171
Capítulo 6. Mantenimiento de Software
tecnología de llave pública para confirmar que un paquete publicado por un repositorio, no haya sido
alterado desde que la identificación fue aplicada. Esto ofrece cierta protección para evitar instalar
software que podría haber sido alterado maliciosamente luego de haber sido creado, pero antes que
usted lo haya descargado.
Si se utilizan demasiados repositorios, o que no sean confiables, o que alojen paquetes sin
identificación, se corre un gran riesgo de introducción de códigos maliciosos o que pueden llegar a
debilitar su sistema. Sea precavido al agregar repositorios para actualizar su sistema.
172
Referencias
Las siguientes referencias tienen como objetivo orientar la búsqueda de información adicional
relacionada con SELinux y Fedora pero están más allá del alcance de esta guía. Tenga en cuenta
que debido al veloz desarrollo de SELinux, algunos de estos materiales podrían utilizarse sólo en
versiones específicas de Fedora.
Libros
SELinux en Ejemplos
Mayer, MacMillan y Caplan
Tutoriales y asistencia
Entendiendo y personalizando la política de SELinux para HTTP de Apache
http://fedora.redhat.com/docs/selinux-apache-fc3/
Información general
Sitio web principal de SELinux de la NSA
1
http://www.nsa.gov/selinux/
Tecnología
Un repaso de las clases de objetos y permisos
http://www.tresys.com/selinux/obj_perms_help.html
Integración del soporte flexible para las Políticas de Seguridad dentro del Sistema Operativo Linux
(una historia de la implementación de Flask en Linux)
http://www.nsa.gov/research/_files/selinux/papers/selsymp2005.pdf
1
http://www.nsa.gov/research/selinux/index.shtml
2
http://www.nsa.gov/research/selinux/faqs.shtml
173
Capítulo 7. Referencias
Comunidad
Guía del Usuario de SELinux de Fedora
http://docs.fedoraproject.org/selinux-user-guide/
IRC
irc.freenode.net, #selinux, #fedora-selinux, #security
Historia
Historia breve de Flask
http://www.cs.utah.edu/flux/fluke/html/flask.html
174
Apéndice A. Estándares de cifrado
A.1. Cifrado sincronizado
El cifrado Rijndael fue desarrollado por dos criptógrafos Belgas, Joan Daemen y Vincent Rijmen,
quienes lo enviaron al proceso de selección de AES. Rijndael (pronunciado [r�inda�l]) es una
3
contracción de los nombres de los dos inventores.
"Estándar de cifrado avanzado". Wikipedia (en inglés). 14 de noviembre del 2009 http://en.wikipedia.org/wiki/
Advanced_Encryption_Standard
"Estándar de cifrado avanzado". Wikipedia (en inglés). 14 de noviembre del 2009 http://en.wikipedia.org/wiki/
Advanced_Encryption_Standard
"Estándar de cifrado avanzado". Wikipedia (en inglés). 14 de noviembre del 2009 http://en.wikipedia.org/wiki/
Advanced_Encryption_Standard
175
Apéndice A. Estándares de cifrado
escrutinios académicos que motivaron la comprensión moderna de los cifradores de bloque y sus
4
criptoanálisis.
En algunos documentos, se hace una distinción entre DES como estándar y DES como el algoritmo
al que se hace referencia como el Algoritmo de cifrado de datos (DEA, por las iniciales en inglés de
Data Encryption Algorithm). Fonéticamente, "DES" es pronunciado o bien como una abreviatura (/�di�
6
�i���s/), o bien como una sigla de una sílaba (/�d�z/).
La criptografía de llave pública es una tecnología fundamental, muy utilizada en todo el planeta, y es
la propuesta subyacente a ciertos estándares de Internet, como ser por ejemplo TLS (Transport Layer
8
Security, sucesor de SSL), PGP y GPG.
"Estándar de cifrado de datos." Wikipedia (en inglés). 14 de noviembre del 2009 http://en.wikipedia.org/wiki/
Data_Encryption_Standard
"Estándar de cifrado de datos." Wikipedia (en inglés). 14 de noviembre del 2009 http://en.wikipedia.org/wiki/
Data_Encryption_Standard
"Estándar de cifrado de datos." Wikipedia (en inglés). 14 de noviembre del 2009 http://en.wikipedia.org/wiki/
Data_Encryption_Standard
"Cifrado de llave pública." Wikipedia (en inglés). 14 de noviembre del 2009 http://en.wikipedia.org/wiki/Public-key_cryptography
"Cifrado de llave pública." Wikipedia (en inglés). 14 de noviembre del 2009 http://en.wikipedia.org/wiki/Public-key_cryptography
"Cifrado de llave pública." Wikipedia (en inglés). 14 de noviembre del 2009 http://en.wikipedia.org/wiki/Public-key_cryptography
176
Diffie-Hellman
Por el contrario, los algoritmos de llaves simétricas, cuyas variaciones fueron utilizadas durante miles
de años, utilizan un sola llave secreta compartida tanto por el remitente como por el destinatario
(y que también debe ser mantenida en privado, lo que explica la ambigüedad de la terminología
común), tanto para el cifrado como para el descifrado. Para utilizar un esquema de cifrado simétrico,
10
el remitente y el destinatario deben compartir de antemano una llave de manera segura.
Debido a que los algoritmos de llaves simétricas son casi siempre de menor intensidad de cómputo,
es común el hecho de intercambiar una llave utilizando un algoritmo de intercambio de llaves, y
transmitir datos utilizando esa llave y un algoritmo de llaves simétricas. Por ejemplo, esto es lo que
hacen PGP y la familia de esquemas SSL/TLS, y en consecuencia son denominados criptosistemas
11
híbridos.
A.2.1. Diffie-Hellman
El intercambio de llaves Diffie-Hellman (D–H) es un protocolo criptográfico que permite que dos
elementos que no tenían previo conocimiento de la existencia uno del otro, puedan establecer
conjuntamente una llave secreta compartida a través de un canal de comunicación no seguro. Esta
llave puede ser utilizada para cifrar comunicaciones subsecuentes mediante la utilización de un
12
cifrador de llaves simétricas.
A.2.2. RSA
En criptografía, RSA (las iniciales en inglés correspondientes a Rivest, Shamir y Adleman, quienes la
describieron públicamente por primera vez; ver más abajo), es un algoritmo para criptografía de llave
pública. Es el primer algoritmo conocido que funciona tanto para firmar como para cifrar, y fue uno de
los primeros avances importantes en criptografía de llave pública. RSA es muy utilizado en protocolos
de comercio electrónico, y se lo considera seguro si se lo establece con llaves adecuadamente
16
extensas, y si se lo utiliza con implementaciones actualizadas.
"Cifrado de llave pública." Wikipedia (en inglés). 14 de noviembre del 2009 http://en.wikipedia.org/wiki/Public-key_cryptography
"Cifrado de llave pública." Wikipedia (en inglés). 14 de noviembre del 2009 http://en.wikipedia.org/wiki/Public-key_cryptography
"Diffie-Hellman." Wikipedia (en inglés). 14 de noviembre del 2009 http://en.wikipedia.org/wiki/Diffie-Hellman
"Diffie-Hellman." Wikipedia (en inglés). 14 de noviembre 2009 http://en.wikipedia.org/wiki/Diffie-Hellman
"Diffie-Hellman." Wikipedia (en inglés). 14 de noviembre del 2009 http://en.wikipedia.org/wiki/Diffie-Hellman
"Diffie-Hellman." Wikipedia (en inglés). 14 de noviembre del 2009 http://en.wikipedia.org/wiki/Diffie-Hellman
"RSA" Wikipedia (en inglés) 14 de abril del 2010 http://en.wikipedia.org/wiki/RSA
177
Apéndice A. Estándares de cifrado
A.2.3. DSA
El Algoritmo de firma digital (DSA, por las iniciales en inglés de Digital Signature Algorithm), es un
estándar del Gobierno federal de los Estados Unidos (o FIPS) para firmas digitales. Fue propuesto
en agosto de 1991 por el Instituto nacional norteamericano de tecnología y estándares (NIST, por las
iniciales en inglés de National Institute of Standards and Technology), para ser utilizado en su propio
Estándar de firmas digitales (DSS, por las iniciales en inglés de Digital Signature Standard), indicado
en FIPS 186, y adoptado en 1993. Una revisión menor fue emitida en 1996 como FIPS 186-1. El
estándar ha sido luego expandido en el año 2000 como FIPS 186-2, y por último, en el año 2009,
17
como FIPS 186-3.
A.2.4. SSL/TLS
TLS (Transport Layer Security) y su predecesor, SSL (Secure Socket Layer), son protocolos de
criptografía que ofrecen seguridad a las comunicaciones establecidas sobre redes como Internet.
TLS y SSL cifran los segmentos en toda la capa de transporte de las conexiones de red. Diferentes
versiones de los protocolos están siendo ampliamente utilizadas en diferentes aplicaciones:
navegadores web, correo electrónico, envío de faxes por Internet, mensajerías instantáneas y VoIP
(voz sobre IP) TLS es un protocolo de rastreo estándar IETF, actualizado en RFC 5246, y está basado
en las anteriores especificaciones SSL, desarrolladas por la corporación Netscape.
El protocolo TLS permite que aplicaciones de cliente/servidor puedan comunicarse sobre una red
de una manera diseñada para prevenir escuchas o manipulaciones. TLS pfrece autenticación final y
confidencialidad de las comunicaciones sobre Internet utilizando criptografía. TLS ofrece seguridad
RSA con potencia de 1024 y de 2048 bits.
TLS también ofrece soporte para un modo de conexión bilateral más seguro (generalmente utilizado
en una aplicación comercial), en donde ambos extremos de la "conversación" pueden asegurarse
acerca de con quién están comunicándose (ofreciendo la posibilidad de conocer la información del
certificado de la otra parte). Esto es conocido como autenticación mutua, o 2SSL. Una autenticación
mutua necesita que la parte cliente de TLS también posea un certificado (lo que generalmente no
sucede en un escenario de usuario final/navegador). A menos que se utilice TLS-PSK, el protocolo
de Contraseña remota segura (SRP, por las iniciales en inglés de Secure Remote Password), o que
cualquier otro protocolo sea utilizado para ofrecer una autenticación mutua poderosa en la ausencia
de certificados.
Generalmente, la información de la llave y los certificados necesarios para TLS son manipulados bajo
la forma de certificados X.509, que define los campos requeridos y el formato de los datos.
SSL trabaja de forma modular. Ha sido diseñado para ser extensible, con soporte para ser compatible
18
con versiones anteriores y posteriores, y para poder realizar negociaciones entre pares
"Algoritmo de firma digital" Wikipedia (en inglés) 14 de abril del 2010 http://en.wikipedia.org/wiki/Digital_Signature_Algorithm
"Seguridad en la etapa del transporte" Wikipedia (en inglés) 14 de abril del 2010 http://en.wikipedia.org/wiki/
Transport_Layer_Security
178
Cifrado ElGamal
179
180
Apéndice B. Historial de revisiones
Revisión Wed Jun 9 2010 Eric Christensen
13.0-8 sparks@fedoraproject.org
Removed FireGPG text as that project has been retired.
181
Apéndice B. Historial de revisiones
Actualizada a la última versión (una vez más) la sección "Usuarios locales pueden instalar
paquetes que no sean confiables".
182
Remove more rhel specifics, major review and remove draft, ready for push
183
184