Guía de seguridad - Fedora Documentation

Transcripción

Fedora 18
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
Fedora 18 Guía de seguridad
Una guía para la seguridad en Fedora Linux
Edición 18.0.1
Autor
Autor
Autor
Autor
Autor
Autor
Johnray Fuller
John Ha
David O'Brien
Scott Radvan
Eric Christensen
Adam Ligas
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
Copyright © 2007-2012 Fedora Project Contributors.
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.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States
and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other
countries.
All other trademarks are the property of their respective owners.
La 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! ........................................................................................ x
1. Resumen acerca de la seguridad
1
1.1. Introducción a la Seguridad .......................................................................................... 1
1.1.1. ¿Qué es la seguridad en computación? .............................................................. 1
1.1.2. SELinux ............................................................................................................ 3
1.1.3. Controles de seguridad ...................................................................................... 4
1.1.4. Conclusión ........................................................................................................ 5
1.2. Atacantes y vulnerabilidades ......................................................................................... 5
1.2.1. Una breve reseña acerca de los hackers ............................................................ 5
1.2.2. Amenazas a la seguridad de la red .................................................................... 6
1.2.3. Amenazas a la seguridad del servidor ................................................................ 7
1.2.4. Amenazas a las estaciones de trabajo y seguridad en equipos hogareños ............. 9
1.3. Evaluación de debilidades ............................................................................................ 9
1.3.1. Pensando como el enemigo ............................................................................. 10
1.3.2. Definiendo evaluación y pruebas ...................................................................... 10
1.3.3. Herramientas de evaluación ............................................................................. 12
1.4. Ataques y debilidades comunes .................................................................................. 15
1.5. Actualizaciones de seguridad ...................................................................................... 18
1.5.1. Actualización de paquetes ................................................................................ 18
1.5.2. Verificación de paquetes firmados .................................................................... 18
1.5.3. Instalación de paquetes firmados ..................................................................... 19
1.5.4. Aplicación de los cambios ................................................................................ 20
2. Guía Básica para reforzar la seguridad.
2.1. Principios Generales ...................................................................................................
2.2. ¿Porque esto es importante? ......................................................................................
2.3. Seguridad Física ........................................................................................................
2.4. ¿Porque esto es importante? ......................................................................................
2.5. ¿Que mas podemos hacer? ........................................................................................
2.6. Networking .................................................................................................................
2.6.1. iptables ...........................................................................................................
2.6.2. IPv6 ................................................................................................................
2.7. Keeping software up to date .......................................................................................
2.8. Services .....................................................................................................................
2.9. NTP ...........................................................................................................................
23
23
23
23
24
24
24
24
24
25
25
25
3. Asegurando su Red
3.1. Seguridad de la estación de trabajo ............................................................................
3.1.1. Evaluación de la seguridad de la estación de trabajo .........................................
3.1.2. Seguridad en el BIOS y en el gestor de arranque ..............................................
3.1.3. Seguridad de contraseñas ................................................................................
3.1.4. Controles administrativos .................................................................................
3.1.5. Servicios de red disponibles .............................................................................
3.1.6. Cortafuegos personales ...................................................................................
3.1.7. Herramientas de comunicación de seguridad mejorada ......................................
3.2. Seguridad del servidor ................................................................................................
3.2.1. Asegurando los servicios con encapsuladores TCP y xinetd ...............................
3.2.2. Asegurando Portmap .......................................................................................
3.2.3. Asegurando NIS ..............................................................................................
27
27
27
27
29
35
41
45
45
46
46
50
50
iii
Guía de seguridad
3.2.4. Asegurando NFS ............................................................................................. 53
3.2.5. Asegurando el servidor HTTP Apache .............................................................. 54
3.2.6. Asegurando FTP ............................................................................................. 55
3.2.7. Asegurando Sendmail ...................................................................................... 58
3.2.8. Verificar qué puertos están abiertos .................................................................. 59
3.3. Single Sign-on (SSO) ................................................................................................. 60
3.3.1. Introducción ..................................................................................................... 60
3.3.2. Empezar a utilizar su nueva tarjeta inteligente ................................................... 62
3.3.3. Como funciona la inscripción de las tarjetas inteligentes. .................................... 63
3.3.4. Cómo funciona el ingreso con tarjeta inteligente ................................................ 64
3.3.5. Configurar Firefox para la utilización de Kerberos como SSO ............................. 65
3.4. Yubikey ...................................................................................................................... 67
3.4.1. Using Yubikey with a centralized server ............................................................ 68
3.4.2. Authenticating to websites with your Yubikey ..................................................... 68
3.5. Módulos de autenticación conectables (PAM, por las iniciales en inglés de Pluggable
Authentication Modules) .................................................................................................... 68
3.5.1. Ventajas de PAM ............................................................................................. 69
3.5.2. Archivos de configuración de PAM .................................................................... 69
3.5.3. Formato del archivo de configuración de PAM ................................................... 69
3.5.4. Ejemplos de archivos de configuración de PAM ................................................. 72
3.5.5. Creación de los módulos PAM ......................................................................... 73
3.5.6. PAM y el cacheo de la credencial administrativa ................................................ 74
3.5.7. PAM y la propiedad de los dispositivos ............................................................. 75
3.5.8. Recursos adicionales ....................................................................................... 77
3.6. Encapsuladores TCP y xinetd ..................................................................................... 78
3.6.1. Encapsuladores TCP ....................................................................................... 79
3.6.2. Archivos de configuración de los encapsuladores TCP ....................................... 80
3.6.3. xinetd .............................................................................................................. 88
3.6.4. Archivos de configuración de xinetd .................................................................. 88
3.6.5. Recursos adicionales ....................................................................................... 94
3.7. Kerberos .................................................................................................................... 95
3.7.1. ¿Qué es Kerberos? ......................................................................................... 95
3.7.2. Terminología de Kerberos ................................................................................ 96
3.7.3. Como Funciona Kerberos ................................................................................ 98
3.7.4. Kerberos y PAM ............................................................................................ 100
3.7.5. Configurando un servidor Kerberos 5 .............................................................. 100
3.7.6. Configuración de un Cliente Kerberos 5 .......................................................... 102
3.7.7. Mapeo dominio-a-reinado ............................................................................... 104
3.7.8. Configurando KDCs secundarios .................................................................... 104
3.7.9. Configurando la autenticación cruzada de reinados .......................................... 106
3.7.10. Recursos adicionales ................................................................................... 109
3.8. Cortafuegos .............................................................................................................. 111
3.8.1. Netfilter e IPTables ........................................................................................ 112
3.8.2. Configuración básica de un cortafuego ............................................................ 113
3.8.3. Uso de IPTables ............................................................................................ 116
3.8.4. Filtrado común de IPTables ............................................................................ 117
3.8.5. Reglas FORWARD y NAT ................................................................................. 118
3.8.6. Software malicioso y suplantación de direcciones IP ........................................ 121
3.8.7. IPTables y el seguimiento de la conexión ........................................................ 122
3.8.8. IPv6 .............................................................................................................. 123
3.8.9. Recursos adicionales ..................................................................................... 123
3.9. IPTables ................................................................................................................... 124
3.9.1. Filtrado de Paquete ....................................................................................... 124
3.9.2. Opciones de la línea de comandos de IPTables ............................................... 126
iv
3.9.3.
3.9.4.
3.9.5.
3.9.6.
Guardando las reglas de IPTalbes ..................................................................
Programas de control de IPTables ..................................................................
IPTables e IPv6 .............................................................................................
Recursos adicionales .....................................................................................
135
136
138
138
4. Cifrado
4.1. Datos en reposo .......................................................................................................
4.1.1. Cifrado completo del disco .............................................................................
4.1.2. Cifrado basado en archivo .............................................................................
4.2. Datos en movimiento ................................................................................................
4.2.1. Redes privadas virtuales (VPNs, por las iniciales en inglés de Virtual Private
Networks) ...............................................................................................................
4.2.2. Shell seguro (SSH, por las iniciales en inglés de Secure Shell) .........................
4.2.3. Cifrado de disco LUKS (Linux Unified Key Setup-on-disk-format) .......................
4.2.4. Archivos cifrados mediante 7-Zip ....................................................................
4.2.5. Utilizando GNU Privacy Guard (GnuPG) .........................................................
141
141
141
141
142
142
157
158
161
162
5. Principios Generales sobre la Seguridad de la Información
169
5.1. Consejos, Guías y Herramientas ............................................................................... 169
6. Instalación segura
171
6.1. Particiones del disco ................................................................................................. 171
6.2. Utilice encriptado de particiones mediante LUKS ........................................................ 171
7. Mantenimiento de Software
7.1. Instale el software mínimo ........................................................................................
7.2. Planifique y configure actualizaciones de seguridad ....................................................
7.3. Ajustando las actualizaciones automáticas .................................................................
7.4. Instale paquetes identificados desde repositorios conocidos ........................................
173
173
173
173
173
8. Debilidades y exposiciones comunes
175
8.1. Complemento de Yum .............................................................................................. 175
8.2. Cómo utilizar yum-plugin-security .............................................................................. 175
9. Referencias
177
A. Estándares de cifrado
A.1. Cifrado sincronizado .................................................................................................
A.1.1. Advanced Encription Standard - AES ..............................................................
A.1.2. Data Encryption Standard - DES ....................................................................
A.2. Cifrado de llave pública ............................................................................................
A.2.1. Diffie-Hellman ................................................................................................
A.2.2. RSA ..............................................................................................................
A.2.3. DSA ..............................................................................................................
A.2.4. SSL/TLS .......................................................................................................
A.2.5. Criptosistema de Cramer-Shoup .....................................................................
A.2.6. Cifrado ElGamal ............................................................................................
179
179
179
179
180
180
181
181
181
182
182
B. Historial de revisiones
183
v
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.
1.1. Convenciones Tipográficas
Se utilizan cuatro convenciones tipográficas para llamar la atención sobre palabras o frases
específicas. Dichas convenciones y las circunstancias en que se aplican son las siguientes:
Negrita monoespaciado
Utilizada para resaltar la entrada del sistema, incluyendo comandos de shell, nombres de archivo y
rutas. También se utiliza para resaltar teclas claves y combinaciones de teclas. Por ejemplo:
Para ver el contenido del archivo my_next_bestselling_novel en su directorio
actual de trabajo, escriba el comando cat my_next_bestselling_novel en el
intérprete de comandos de shell y pulse Enter para ejecutar el comando.
El ejemplo anterior incluye un nombre de archivo, un comando de shell y una tecla clave. Todo se
presenta en negrita-monoespaciado y distinguible gracias al contexto.
Las combinaciones de teclas se pueden distinguir de las teclas claves mediante el guión que conecta
cada parte de una combinación de tecla. Por ejemplo:
Pulse Enter para ejecutar el comando.
Pulse Control+Alt+F2 para cambiar a la primera terminal virtual. Pulse
Control+Alt+F1 para volver a su sesión de Ventanas-X.
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 Negritamonoespaciado. Por ejemplo:
Las clases de archivo relacionadas incluyen filename para sistema de archivos,
file para archivos y dir para directorios. Cada clase tiene su propio conjunto
asociado de permisos.
Negrita proporcional
Esta denota palabras o frases encontradas en un sistema, incluyendo nombres de 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
Seleccionar Sistema�� Preferencias�� Ratón desde la barra del menú
principal para lanzar Preferencias de Ratón. En la pestaña de Botones, haga clic en
la cajilla ratón de mano izquierda y luego haga clic en Cerrar para cambiar el botón
principal del ratón de la izquierda a la derecha (adecuando el ratón para la mano
izquierda).
Para insertar un caracter especial en un archivo de gedit, seleccione desde la barra
del menú principal Aplicaciones�� Accessories�� Mapa de caracteres.
Luego, desde la barra de menúes de mapa de caracteres elija Búsqueda��
Hallar…, teclee el nombre del caracter en el campo Búsqueda y haga clic en
Siguiente. El caracter buscado se resaltará en la Tabla de caracteres. Haga doble
clic en este caracter resaltado para colocarlo en el campo de Texto para copiar y
luego haga clic en el botón de Copiar. Ahora regrese a su documento y elija Editar
�� Pegar desde la barra de menú de gedit.
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.
Itálicas-negrita monoespaciado o Itálicas-negrita proporcional
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:
Para conectar a una máquina remota utilizando ssh, teclee ssh
[email protected] en un intérprete de comandos de shell. Si la
máquina remota es example.com y su nombre de usuario en esa máquina es john,
teclee ssh [email protected].
El comando mount -o remount file-system remonta el sistema de archivo
llamado. Por ejemplo, para volver a montar el sistema de archivo /home, el comando
es mount -o remount /home.
Para ver la versión de un paquete actualmente instalado, utilice el comando rpm -q
paquete. Éste entregará el resultado siguiente: paquete-versión-lanzamiento.
Observe las palabras en itálicas y 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:
Publican es un sistema de publicación de DocBook.
1.2. Convenciones del documento
Los mensajes de salida de la terminal o fragmentos de código fuente se distinguen visualmente del
texto circundante.
Los mensajes de salida enviados a una terminal se muestran en romano monoespaciado y se
presentan así:
books
books_tests
viii
Desktop
Desktop1
documentation
downloads
drafts
images
mss
notes
photos
scripts
stuff
svgs
svn
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;
public class ExClient
{
public static void main(String args[])
throws Exception
{
InitialContext iniCtx = new InitialContext();
Object
ref
= iniCtx.lookup("EchoBean");
EchoHome
home
= (EchoHome) ref;
Echo
echo
= home.create();
System.out.println("Created Echo");
System.out.println("Echo.echo('Hello') = " + echo.echo("Hello"));
}
}
1.3. Notas y Advertencias
Finalmente, utilizamos tres estilos visuales para llamar la atención sobre la información que de otro
modo se podría pasar por alto.
Nota
Una nota es una sugerencia, atajo o enfoque alternativo 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
Los cuadros con el título de importante dan detalles de cosas que se pueden pasar por alto
fácilmente: cambios de configuración únicamente aplicables a la sesión actual, o servicios
que necesitan reiniciarse antes de que se aplique una actualización. Ignorar estos cuadros no
ocasionará pérdida de datos, pero puede causar enfado y frustración.
Advertencia
Las advertencias no deben ignorarse. Ignorarlas muy probablemente ocasionará pérdida de
datos.
ix
Prefacio
2. ¡Necesitamos sus comentarios!
Si encuentra un error tipográfico en este manual o si sabe de alguna manera de mejorarlo,
nos gustaría escuchar sus sugerencias. Por favor complete un reporte en Bugzilla: http://
bugzilla.redhat.com/bugzilla/ usando el producto Fedora.
Cuando envíe un reporte de error no olvide mencionar el identificador del manual: security-guide
Si tiene una sugerencia para mejorar la documentación, intente ser tan específico como sea posible
cuando describa su sugerencia. Si ha encontrado un error, por favor incluya el número de sección y
parte del texto que rodea el error para que podamos encontrarlo más fácilmente.
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.
Desafortunadamente, muchas de las organizaciones (y muchos usuarios individuales), luego de
pensarlo dos veces, deciden relegar el aspecto de la seguridad a un plano inferior, dándole prioridad
a otras áreas de sus emprendimientos, como ser producción, presupuesto, o infraestructura. Y
frecuentemente, una implementación adecuada de la seguridad es adoptada postmortem — después
que un acceso no autorizado haya ocurrido. Los expertos en seguridad concuerdan en que adoptar
las medidas correctas antes de conectar un sitio a una red insegura, como lo es Internet, es una
manera efectivo de prevenir la mayoría de los intentos de intrusión.
1.1. Introducción a la Seguridad
1.1.1. ¿Qué es la seguridad en computación?
La noción de seguridad en computación es un concepto general que cubre un área muy extensa
dentro del ámbito de la computación y del procesamiento de la información. Las industrias que
dependen tanto de redes como de sistemas de computación para poder realizar cotidianamente
operaciones comerciales, o para acceder a diverso tipo de información vital, entienden que sus datos
son una parte importante de sus activos. Han ingresado a nuestro vocabulario cotidiano diversos
términos y unidades de medición pertenecientes al ámbito comercial, como ser por ejemplo, el
coste total de propiedad (TCO, por las iniciales en inglés de Total Cost of Ownership), o servicio de
calidad (QoS, por las iniciales en inglés de Quality of Service). Al utilizar estas unidades, las industrias
pueden calcular aspectos tales como ser la integridad de los datos, o el tipo de disponibilidad que
tienen, y poder considerarlos parte de los costos de planeamiento y administración de procesos.
En algunas industrias, como la del comercio electrónico por ejemplo, el tipo de disponibilidad y la
confiabilidad de los datos puede ser un elemento determinante para el éxito o el fracaso.
1.1.1.1. ¿De dónde viene la idea de seguridad en computación?
La seguridad en la información ha evolucionado con el correr de los años debido al aumento en la
utilización de redes públicas y el consecuente riesgo de exposición que en ellas tienen los datos
1
privados, confidenciales o financieros. Existen numerosos antecedentes, como el caso Mitnick o
2
Vladimir Levin , que sugieren a todas las organizaciones de cualquier tipo de industria, replantearse
la forma en que tienen organizado el manejo de su propia información, o de la manera en que es
transmitida y revelada. La popularidad que tiene Internet es uno de los motivos fundamentales gracias
al cual se han intensificado los esfuerzos relacionados con la seguridad en los datos.
Un número creciente de personas está utilizando sus computadoras personales para obtener acceso
a los recursos que ofrece Internet. Desde investigación y obtención de información hasta el correo
1
2
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
electrónico y transacciones comerciales, Internet es considerada como uno de los desarrollos más
importantes del siglo 20.
Sin embargo, Internet y sus primeros protocolos fueron desarrollados como un sistema basado
en la confianza. Esto significa que el Protocolo de Internet no fue diseñado para ser seguro en sí
mismo. No existen estándares de seguridad aprobados dentro del bloque de comunicaciones TCP/
IP, dejándolo indefenso ante usuarios o procesos de la red potencialmente dañinos. Desarrollos
modernos han hecho de las comunicaciones en Internet algo más seguro, pero todavía existen
varios incidentes que acaparan la atención mundial, y nos recuerdan el hecho de que nada es
completamente seguro.
1.1.1.2. La seguridad hoy
En febrero del año 2000 un ataque de denegación de servicio distribuido (DDoS, por las iniciales
en inglés de Distributed Denial of Service) fue liberado sobre varios de los sitios de Internet que
tenían más tráfico. Este ataque afectó a yahoo.com, cnn.com, amazon.com, fbi.gov y algunos
otros sitios que son completamente inaccesibles para los usuarios normales, dejando a los
enrutadores bloqueados durante varias horas con transferencias de grandes paquetes ICMP, o
también denominado un ping de la muerte. El ataque fue llevado a cabo por asaltantes desconocidos
utilizando programas especialmente creados (y que están a disposición de cualquiera), que buscan
servidores de red vulnerables, instalan en esos servidores aplicaciones de cliente denominadas
troyanos, y sincronizando un ataque con cada servidor infectado, inundando los sitios elegidos y
dejándolos inutilizables. Muchos adjudican el éxito del ataque a fallas fundamentales en la forma en
que están estructurados los enrutadores y los protocolos que utilizan. Estas fallas tienen que ver con
la manera en que se aceptan los datos entrantes, sin importar desde dónde provengan, o con qué
propósito los paquetes hayan sido enviados.
En el año 2007, una pérdida de datos permitió la explotación de una debilidad bien conocida en el
protocolo de 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 un incidente separado, los registros de facturación de más de 2,2 millones de pacientes
almacenados en una cinta de respaldo fueron robados desde el asiento delantero de un auto de
4
mensajería.
Actualmente, se estima que 1,8 mil millones de personas usan o usaron Internet alrededor del mundo
5
. Al mismo tiempo:
• En cualquier día, hay aproximadamente 225 incidentes principales de fallas de seguridad
informados al Centro de Coordinación CERT en la Universidad de Carnegie Mellon.
• 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.
From a 2008 global survey of business and technology executives "The Global State of Information
6
Security" , undertaken by CIO Magazine, some points are:
3
http://www.theregister.co.uk/2007/05/04/txj_nonfeasance/
http://www.healthcareitnews.com/story.cms?id=9408
5
http://www.internetworldstats.com/stats.htm
6
http://www.csoonline.com/article/454939/The_Global_State_of_Information_Security_
4
2
SELinux
• Sólo el 43% de los encuestados audita o monitorea el cumplimiento de las políticas de seguridad de
sus usuarios
• Sólo el 22% mantiene un inventario de las compañías externas que utilizan sus datos
• El origen de casi la mitad de los incidentes de seguridad fueron marcados como "Desconocido".
• 44% de los encuestados planean incrementar sus gastos en seguridad en el año siguiente
• 59% tiene una estrategia de seguridad de la información
Estos resultados refuerzan la realidad de que la seguridad de computadoras se ha vuelto un gasto
cuantificable y justificable en los presupuestos de TI. Las organizaciones que necesitan tanto la
integridad como la rápida disponibilidad de sus datos, lo obtienen gracias a la habilidad que los
administradores de sistema, desarrolladores e ingenierospara tienen para asegurar la disponibilidad
de sus sistemas, servicios y datos, durante las 24 horas de los 365 días del año. Ser víctima
de usuarios maliciosos, procesos o ataques coordinados es una amenaza directa al éxito de la
organización.
Desafortunadamente, la seguridad de sistemas y de la red puede ser una proposición difícil, que
requiere un conocimiento intrincado de cómo una organización expresa, usa, manipula y transmite
su información. El entendimiento de la forma en que una organización (y la gente que la compone)
conduce el negocio es primordial para implementar un plan de seguridad apropiado.
1.1.1.3. Estandarizando la seguridad
Las empresas de todas las industrias confían en las regulaciones y en las reglas que son puestas
por las personas que construyen estándares tales como la Asociación Médica Americana (AMA,
por las iniciales en inglés de American Medical Association) o el Instituto de Ingenieros Eléctricos
y Electrónicos (IEEE, Institute of Electrical and Electronics Engineers). Los mismos ideales se
aplican a la seguridad de la información. Muchos consultores y fabricantes se ponen de acuerdo
en el modelo de seguridad estándar conocido como CIA (Confidentiality, Integrity and Availability),
o Confidencialidad, Integridad y Disponibilidad. Este modelo de 3 capas es un componente
generalmente aceptado para averiguar los riesgos de la información vital y del establecimiento de la
política de seguridad. A continuación se describe el modelo CIA en más detalle:
• Confidentiality — Sensitive information must be available only to a set of pre-defined individuals.
Unauthorized transmission and usage of information should be restricted. For example,
confidentiality of information ensures that a customer's personal or financial information is not
obtained by an unauthorized individual for malicious purposes such as identity theft or credit fraud.
• Integridad — La información no debe alterarse de manera tal que se torne incompleta o incorrecta.
Los usuarios no autorizados deben ser restringidos de la habilidad de modificar o destruir
información vital.
• Disponibilidad — La información debe ser accesible a usuarios autorizados en cualquier momento
en el que sea necesario. La disponibilidad es una garantía de que la información se puede obtener
en una frecuencia y duración preestablecida. Esto se mide a menudo en términos de porcentajes
y se deja sentado formalmente en Acuerdos de Disponibilidad del Servicio (SLAs, por las iniciales
en inglés de Service Level Agreements) con los proveedores de servicios de red y sus clientes
empresariales.
1.1.2. SELinux
Fedora incluye una mejora al kernel de Linux que se llama SELinux, que implementa la arquitectura
de Control de Acceso Obligatorio (MAC), que provee un nivel más fino de control sobre los archivos,
3
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 9, Referencias.
1.1.3. Controles de seguridad
La seguridad de computadoras es a menudo dividida en tres categorías principales distintas,
comúnmente referidas como controles:
• Físico
• Técnico
• Asministrativo
Estas tres amplias categorías definen los objetivos principales de una implementación de seguridad
apropiada. Dentro de estos controles existen subcategorías que ofrecen mayores características, o
brindan información acerca de su correcta implementación.
1.1.3.1. Control físico
El control físico es la implementación de medidas de seguridad en una estructura definida, utilizado
para determinar o evitar el acceso no autorizado a material sensible. Ejemplos de controles físicos
son:
• Circuito cerrado de cámaras de vigilancia
• Sistemas de alarma de movimientos, o termales
• Guardias de la seguridad
• IDs de Imagen
• Puertas de acero bloqueadas y selladas
• Biometría (incluye huellas digitales, voz, cara, iris, escritura manual y otros métodos automatizados
usados para reconocer a los individuos)
1.1.3.2. Técnicas de control
Los controles técnicos usan la tecnología como una base para el control del acceso y del uso de
datos sensibles a través de una estructura física y sobre una red. Los controles técnicos son de largo
alcance y abarcan tecnologías como:
• Cifrado
• Tarjetas inteligentes
• Autenticación de red
• Listas de control de acceso (ACLs)
• Software para auditar la integridad de archivos
4
Conclusión
1.1.3.3. Controles administrativos
Los controles administrativos definen los factores humanos de la seguridad. Involucran todos los
niveles del personal dentro de una organización y determinan qué usuarios tienen acceso a qué
recursos y la información por tales medios como:
• Capacitación y conocimientos
• Preparación para desastres y planes de recuperación
• Reclutamiento de personal y estrategias de separación
• Registración y control del personal
1.1.4. Conclusión
Ahora que ya conoce los orígenes, las razones y los aspectos de la seguridad, encontrará más
fácil determinar el rumbo apropiado con respecto a Fedora. Es importante conocer qué factores y
condiciones hacen a la seguridad para planear e implementar una estrategia apropiada. Con esta
información en mente, el proceso se puede formalizar y los caminos a seguir se hacen más claros a
medida que profundiza en los detalles del proceso de seguridad.
1.2. Atacantes y vulnerabilidades
Para poder planificar e implementar una buena estrategia de seguridad, tenga en cuenta primero
algunos de los problemas que son aprovechados por los atacantes para poder vulnerar los sistemas.
Sin embargo, antes de detallar estos problemas, tenemos que definir la terminología utilizada a la
hora de identificar a un atacante.
1.2.1. Una breve reseña acerca de los hackers
El significado moderno del término hacker tiene sus orígenes en la década del '60, en el Tech
Model Railroad Club del Instituto de Tecnología de Massachusetts (MIT, por las siglas en inglés de
Massachusetts Institute of Technology), en donde se diseñaban modelos de trenes a gran escala y
con detalles muy específicos. "Hacker" era el nombre con el que se identificaba a los miembros del
club capaces de sortear las dificultades que presentaba un determinado problema, o que descubría
algún truco útil.
Desde entonces el término "hacker" se ha utilizado para referirse o bien a un aficionado en
computadoras, o bien a un programador talentoso, o bien para todo lo que se encuentre entre
ellos. Una característica compartida entre cualquier tipo de "hacker" es la voluntad de investigar
detalladamente cómo funciona un sistema de computadoras, o una red, con poca o ninguna
motivación ulterior además del mero hecho de investigar. Los desarrolladores de software de código
abierto, a menudo se consideran así mismos y a sus colegas como "hackers", y utilizan esta palabra
como un signo de respeto.
Generalmente, los hackers siguen un código de conducta establecido en la etica del hacker, que
establece que la búsqueda de información y la excelencia son esenciales, y que el hecho de
compartir los conocimientos adquiridos es un deber que el hacker tiene para con la comunidad. A
lo largo de esta búsqueda del conocimiento, algunos hackers disfrutan de los desafíos académicos
que representan el hecho de sortear los controles de seguridad en los sistemas computarizados. Por
este motivo, generalmente el periodismo utiliza el término hacker para referirse a quienes acceden
ilegalmente y con fines criminales, malintencionados o inescrupulosos, a redes o sistemas de
computación. La forma más adecuada para referirse a este tipo de hackers es atacante — un término
creado por los hackers a mediados de la década del '80, para diferenciar ambas comunidades.
5
1.2.1.1. Zonas grises
Within the community of individuals who find and exploit vulnerabilities in systems and networks are
several distinct groups. These groups are often described by the shade of hat that they "wear" when
performing their security investigations and this shade is indicative of their intent.
El hacker de sombrero blanco es quien examina los sistemas y las redes para conocer sus
capacidades y poder determinar qué tan vulnerables son ante una posible intrusión. Generalmente,
este tipo de hackers vulnera su propio sistema, o los sistemas de algún cliente suyo que lo ha
contratado específicamente con el propósito de controlar su seguridad. Investigadores académicos y
consultores profesionales en el área de seguridad son ejemplos de hackers de sombrero blanco.
Un hacker de sombrero negro es sinónimo de atacante. Generalmente, los atacantes están
menos interesados en la programación o en el aspecto académico a la hora de vulnerar sistemas.
Usualmente utilizan una serie de programas desarrollados exclusivamente para atacar y vulnerar los
aspectos de un sistema que de antemano se sabe que pueden llegar a fallar, y los utilizan para dejar
al descubierto información valiosa en tales sistemas o redes, o para obtener un beneficio personal, o
simplemente para causar daño.
Por otro lado, un hacker de sombrero gris tiene la habilidad de un hacker de sombrero blanco, y en
la mayoría de los casos también sus intenciones, pero en algunas ocasiones utiliza su conocimiento
para propósitos no tan nobles. Puede pensarse en un hacker de sombrero gris como un hacker de
sombrero blanco, que a veces utiliza un sombrero negro para cumplir con objetivos personales.
Generalmente los hackers de sombrero gris se rigen por una norma diferente de la ética del hacker,
que establece que es aceptable vulnerar sistemas, siempre y cuando el hacker no cometa ningún
delito ni haga público aquello que es considerado privado. Sin embargo, alguien podría argumentar,
que el acto de vulnerar un sistema es en sí mismo un acto no ético.
Sin importar la intención del intruso, es importante conocer la debilidad que un atacante puede
intentar explotar. El resto del capítulo se centra en estas cuestiones.
1.2.2. Amenazas a la seguridad de la red
Malas prácticas cuando se configuran los siguientes aspectos de una red pueden aumentar el riesgo
de un ataque.
1.2.2.1. Arquitecturas inseguras
Una red mal configurada es el principal punto de ingreso para usuarios no autorizados. Dejar una red
local, a cuyos usuarios conocemos, abierta y vulnerable a la gran inseguridad que representa Internet
es casi como dejar una puerta entornada en un barrio de criminales. Tal vez no suceda nada en un
determinado período de tiempo, pero en algún momento, alguien va a aprovechar esa oportunidad
1.2.2.1.1. Redes emisoras
Los administradores de sistemas muchas veces no se dan cuenta de la importancia que tiene el
hardware de red que utilizan a la hora de realizar los esquemas de seguridad. El hardware que
se considera sencillo, como son los enrutadores y los concentradores, dependen del principio de
transmisión o principio de no interrupción; esto es, siempre que un nodo transmisor envíe datos sobre
una red hacia un nodo receptor, el concentrador o enrutador envía una transmisión del paquete de
datos hasta que el nodo receptor recibe y procesa los datos. Este método es el más vulnerable para
enviar resolución de protocolo (arp) o control de acceso de contenidos (MAC), ya que esta forma de
envío es accesible tanto por intrusos fuera del equipo, como por usuarios no autorizados dentro de él.
6
Amenazas a la seguridad del servidor
1.2.2.1.2. Servidores centralizados
Otro error posible de cometer dentro de una red, es el uso de computación centralizada. Una medida
común adoptada por muchos comercios a la hora de reducir su presupuesto, es la de concentrar
todos los servicios en una única máquina, relativamente poderosa. Esto puede ser conveniente ya
que hace más sencillas las tareas administrativas, y el costo es económicamente inferior al de realizar
configuraciones sobre varios servidores. Sin embargo, un servidor centralizado representa el único
punto de acceso a la red. Si el servidor central es vulnerado, puede inutilizar completamente a la red,
o peor aún, puede hacer que los datos sean fácilmente manipulados, o directamente sustraídos. En
estas situaciones, un servidor central se convierte en una puerta abierta que permite el acceso a la
red en su totalidad.
1.2.3. Amenazas a la seguridad del servidor
Server security is as important as network security because servers often hold a great deal of an
organization's vital information. If a server is compromised, all of its contents may become available for
the cracker to steal or manipulate at will. The following sections detail some of the main issues.
1.2.3.1. Servicios no usados y puertos abiertos
Una instalación completa de Fedora contiene más de 1000 aplicaciones y bibliotecas de paquetes.
Sin embargo, muchos administradores de servidores eligen no instalar todos los paquetes de la
distribución, y prefieren en su lugar realizar una instalación de los paquetes básicos, incluyendo
algunas aplicaciones de servidor.
Una 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 3.2, “Seguridad del servidor”.
1.2.3.2. Servicios no parchados
La mayoría de las aplicaciones de servidor que se incluyen en una instalación por defecto son
piezas de software sólidas y completamente comprobadas. Habiendo sido utilizadas en entornos de
producción durante muchos años, el código de ellas ha sido totalmente refinado y muchos de sus
errores han sido encontrados y corregidos.
Sin embargo, no existe algo así como el software perfecto y existe siempre un margen para futuras
mejoras. Es más, por lo general el software más reciente no ha sido probado con el rigor que uno
podría esperar, debido a su reciente aparición en los entornos de producción, o debido a que no es
tan popular como otros.
Los desarrolladores y los administradores de sistemas encuentran a menudo, en algunas aplicaciones
de servidor, errores que podrían ser aprovechados para vulnerar el sistema, y publican la información
de tal error en un sitio web relacionado con el tema, como ser por ejemplo, la lista de correo Bugtraq
(http://www.securityfocus.com) o el Equipo de Respuesta de Emergencias de Computación (CERT,
por las iniciales en inglés de Computer Emergency Response Team), cuyo sitio web es (http://
www.cert.org). Si bien estos mecanismos son una forma efectiva de advertir a la comunidad acerca
de problemas en la seguridad, queda en manos de los administradores del sistema enmendar sus
sistemas. Esto es realmente verdadero ya que los atacantes tienen acceso a estos mismos sitios y
podrán utilizar la información para vulnerar sistemas que aún no han sido enmendados. Ser un buen
7
administrador de sistemas implica ser vigilante, estar atento permanentemente a los errores y a sus
soluciones, y ser capaz de realizar una manutención adecuada del sistema para asegurar un entorno
de computación seguro.
Vaya a la Sección 1.5, “Actualizaciones de seguridad” para más información sobre cómo mantener un
sistema actualizado.
1.2.3.3. Administración desatendida
Administrators who fail to patch their systems are one of the greatest threats to server security.
According to the SysAdmin, Audit, Network, Security Institute (SANS), the primary cause of computer
security vulnerability is to "assign untrained people to maintain security and provide neither the training
7
nor the time to make it possible to do the job." This applies as much to inexperienced administrators
as it does to overconfident or amotivated administrators.
Alguno administradores no pueden enmendar sus servidores o estaciones de trabajo, y otros no
le prestan atención a los mensajes de registro enviados desde el kernel del sistema, o generados
por el tráfico en la red. Otro error común se produce al no modificar las contraseñas o claves
establecidas por defecto para los servicios. Por ejemplo, algunas bases de datos tienen contraseñas
administrativas generadas por defecto, debido a que los desarrolladores de las bases de datos
presuponen que el administrador del sistema las modificará inmediatamente después de haberla
instalado en su sistema. Si un administrador de una base de datos no cambia la contraseña, incluso
un atacante sin demasiada experiencia puede utilizar una amplia gama de contraseñas que se
sabe le pueden otorgar privilegios de administrador en esa base de datos. Estos son sólo algunos
ejemplos que ilustran de qué manera una administración débil puede ocasionar la vulnerabilidad de
los servidores.
1.2.3.4. Servicios inseguros en sí mismos
Incluso la organización más precavida puede ser víctima de sus puntos débiles, si elige utilizar
servicios de red inseguros. Por ejemplo, existen numerosos servicios desarrollados presuponiendo
que serán utilizados en redes que se consideran confiables. Sin embargo, este presupuesto deja de
funcionar ni bien el servicio se utiliza en Internet — que es considerada una red insegura.
Una categoría de servicios de red no seguros son aquellos que en el momento de la autenticación,
piden nombres de usuario y contraseñas que no estén encriptados. Telnet y FTP son dos ejemplos de
este tipo de servicios. Si algún software diseñado para sustraer información se encuentre vigilando el
tráfico entre el usuario remoto y un servicio con estas características, tanto los nombres de usuario
como las contraseñas pueden ser interceptadas fácilmente.
Inherently, such services can also more easily fall prey to what the security industry terms the man-inthe-middle attack. In this type of attack, a cracker redirects network traffic by tricking a cracked name
server on the network to point to his machine instead of the intended server. Once someone opens
a remote session to the server, the attacker's machine acts as an invisible conduit, sitting quietly
between the remote service and the unsuspecting user capturing information. In this way a cracker
can gather administrative passwords and raw data without the server or the user realizing it.
Another category of insecure services include network file systems and information services such as
NFS or NIS, which are developed explicitly for LAN usage but are, unfortunately, extended to include
WANs (for remote users). NFS does not, by default, have any authentication or security mechanisms
configured to prevent a cracker from mounting the NFS share and accessing anything contained
7
http://www.sans.org/resources/errors.php
8
Amenazas a las estaciones de trabajo y seguridad en equipos hogareños
therein. NIS, as well, has vital information that must be known by every computer on a network,
including passwords and file permissions, within a plain text ASCII or DBM (ASCII-derived) database.
A cracker who gains access to this database can then access every user account on a network,
including the administrator's account.
Por defecto, Fedora es liberada con todos estos servicios apagados. Sin embargo, dado que
los administradores a menudo se encuentran obligados a utilizarlos, es muy importante realizar
cuidadosamente la configuración de ellos. Para obtener mayor información acerca de cómo configurar
los servicios en forma segura, vea Sección 3.2, “Seguridad del servidor”.
1.2.4. Amenazas a las estaciones de trabajo y seguridad en equipos
hogareños
Workstations and home PCs may not be as prone to attack as networks or servers, but since they
often contain sensitive data, such as credit card information, they are targeted by system crackers.
Workstations can also be co-opted without the user's knowledge and used by attackers as "slave"
machines in coordinated attacks. For these reasons, knowing the vulnerabilities of a workstation can
save users the headache of reinstalling the operating system, or worse, recovering from data theft.
1.2.4.1. Malas contraseñas
Las malas contraseñas son una de las formas más fáciles para que un atacante obtenga el acceso
a un sistema. Para información sobre cómo evitar los errores comunes, vaya a Sección 3.1.3,
“Seguridad de contraseñas”.
1.2.4.2. Aplicaciones de tipo cliente vulnerables
Although an administrator may have a fully secure and patched server, that does not mean remote
users are secure when accessing it. For instance, if the server offers Telnet or FTP services over a
public network, an attacker can capture the plain text usernames and passwords as they pass over the
network, and then use the account information to access the remote user's workstation.
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 3.1, “Seguridad de la estación de trabajo” discute más en detalle los pasos que los
administradores y usuarios hogareños deben tomar para limitar la vulnerabilidad de las computadoras
estaciones de trabajo.
1.3. Evaluación de debilidades
Dependiendo del tiempo, de los recursos y de la motivación, un atacante puede ingresar
prácticamente en cualquier sistema. En términos absolutos, ninguna tecnología o proceso en
seguridad actualmente disponible, puede garantizar que un sistema determinado sea completamente
invulnerable. Los enrutadores contribuyen a la seguridad de las puertas de enlace frente a Internet.
Los cortafuegos contribuyen a la seguridad de las redes internas. Las redes virtuales privadas envían
datos en forma segura mediante un flujo encriptado. Sistemas para la detección de extraños le
avisan en caso de encontrar actividad malintencionada. Sin embargo, el éxito de cada una de estas
tecnologías depende de una numerosa cantidad de variables, entre las cuales podemos encontrar:
9
• La experiencia del equipo responsable de la configuración, monitoreo y manutención de esas
tecnologías.
• La habilidad para enmendar y actualizar servicios y servidores en forma veloz y eficiente.
• La habilidad de quienes son responsables de mantener sobre la red una vigilancia permanente.
Debido a las características dinámicas de los sistemas de datos y de las tecnologías, asegurar
los recursos corporativos puede llegar a ser algo bastante complejo. Debido a esta complejidad, a
menudo es difícil encontrar herramientas experimentadas para todos sus sistemas. Si bien es posible
contar con personal cuyos conocimientos abarquen numerosos aspectos de los niveles generales
de la seguridad en la información, es difícil conservar a quienes puedan considerarse expertos en
los diferentes aspectos de una misma área. Principalmente esto sucede debido a que cada aspecto
de cada área de la seguridad en la información necesita atención y concentración constante. La
seguridad en la información nunca permanece inmóvil.
1.3.1. Pensando como el enemigo
Suppose that you administer an enterprise network. Such networks are commonly comprised of
operating systems, applications, servers, network monitors, firewalls, intrusion detection systems,
and more. Now imagine trying to keep current with each of these. Given the complexity of today's
software and networking environments, exploits and bugs are a certainty. Keeping current with
patches and updates for an entire network can prove to be a daunting task in a large organization with
heterogeneous systems.
Combine la experiencia que habría que necesitarse, con las tareas a realizar para mantenerse
actualizado, y serán inevitables la presencia de incidentes, de sistemas vulnerados, de datos
alterados, y de servicios interrumpidos.
Para incrementar las tecnologías en seguridad y ayudar a proteger los sistemas, redes y datos,
debería pensar del mismo modo en que lo hace un atacante, y desde este punto de vista
comprobar la seguridad de su sistema verificando sus debilidades. Realizar evaluaciones de
seguridad preventivas de su sistema y recursos de red, pueden enseñarle potenciales problemas, y
solucionarlos, antes que sean aprovechados por un atacante.
Una evaluación de debilidades es una auditoría interna de su red y de su sistema de seguridad,
cuyo resultado indica la confidencialidad, integridad y disponibilidad de su red (como es explicado
en Sección 1.1.1.3, “Estandarizando la seguridad”). Por lo general, una evaluación de debilidades se
inicia con una etapa de reconocimiento, durante la cual se obtienen datos importantes relacionados
con los sistemas y los recursos involucrados. En la etapa siguiente se verifica el sistema en busca de
debilidades conocidas, y culmina con una etapa de informe, en donde todo lo que se ha encontrado
es clasificado entre las categorías de riesgo alto, medio y bajo. En esta última etapa, además, se
proponen métodos para mejorar la seguridad (o eliminar el riego) del sistema analizado.
Si usted tuviera que realizar una evaluación de las debilidades de su hogar, seguramente verificaría
que cada una de las puertas se encuentre cerrada con llave. También confirmaría que cada
una de las ventanas esté cerrada, y trabada con el pestillo. El mismo concepto se aplica a los
sistemas, redes y datos electrónicos. Los usuarios malintencionados son los ladrones de sus datos.
Concéntrese en las herramientas que utilizan, en su forma de pensar y en sus motivaciones, y
entonces será capaz de poder anticiparse a sus acciones.
1.3.2. Definiendo evaluación y pruebas
Las evaluaciones de debilidades pueden ser catalogadas en dos grandes tipos: De afuera hacia
adentro y de adentro hacia afuera.
10
Definiendo evaluación y pruebas
When performing an outside looking in vulnerability assessment, you are attempting to compromise
your systems from the outside. Being external to your company provides you with the cracker's
viewpoint. You see what a cracker sees — publicly-routable IP addresses, systems on your DMZ,
external interfaces of your firewall, and more. DMZ stands for "demilitarized zone", which corresponds
to a computer or small subnetwork that sits between a trusted internal network, such as a corporate
private LAN, and an untrusted external network, such as the public Internet. Typically, the DMZ
contains devices accessible to Internet traffic, such as Web (HTTP) servers, FTP servers, SMTP (email) servers and DNS servers.
Cuando realice una evaluación de debilidades desde adentro hacia afuera, usted tiene una especie
de ventaja ya que, al estar en una ubicación interna, su estado es el de ser alguien confiable, y por
lo tanto, superior. Este es el punto de vista adquieren usted y sus compañeros de trabajo, cada vez
que se registran en el sistema. Puede ver servidores de impresión, servidores de archivos, bases de
datos, y demás recursos.
Existen notables distinciones entre estos dos tipos de evaluaciones. Desde el interior de la compañía
se tienen privilegios superiores a los que se obtendrían desde el exterior. Aún hoy, en muchas
organizaciones, la seguridad es configurada de tal manera para evitar que ingresen intrusos desde
el exterior, y muy poco se hace para asegurar los elementos internos de la organización (como
ser cortafuegos departamentales, controles de acceso de niveles de usuarios, procedimientos de
autenticaciones para recursos internos, etc.). Por lo general, existen muchos más recursos si se
busca dentro de una compañía, ya que la mayoría de los sistemas son internos a ella. Una vez que se
encuentre fuera de la compañía, inmediatamente será identificado como un elemento no seguro. Los
sistemas y las herramientas disponibles para utilizar desde fuera son, generalmente, muy limitadas.
Considere la diferencia existente entre evaluaciones de debilidades y pruebas de penetración. Piense
en una evaluación de debilidades como el primer paso de una prueba de penetración. La información
obtenida en la evaluación es utilizada para la prueba. Cualesquiera sean las áreas o los lugares
que el resultado de la evaluación haya sugerido verificar en búsqueda de agujeros o debilidades
potenciales, serán esos mismos lugares los que la prueba de penetración intentará utilizar para
aprovechar esas debilidades e ingresar al sistema.
Acceder a la infraestructura de la red es un proceso dinámico. La seguridad es dinámica, tanto la
física como la de la información. Realizar una evaluación determina una visión general, que puede
arrojar resultados falsos, tanto para bien como para mal.
La eficacia de los administradores de seguridad es directamente proporcional a las herramientas
que utilizan y al conocimiento que poseen. Elija cualquiera de las herramientas de evaluación que se
encuentren disponibles actualmente, ejecútelas en su sistema, y es casi una garantía que algunos
resultados serán erróneos. Ya sea por una falla del programa, o por un error del usuario, el resultado
será el mismo. La herramienta puede llegar a encontrar debilidades que en realidad no existen (falsos
positivos); o , peor aún, la herramienta puede no encontrar debilidades que efectivamente existen
(falsos negativos).
Ahora que ha sido definida la diferencia entre una evaluación de debilidades y una prueba de
penetración, como parte de una mejor aplicación de los métodos, revise cuidadosamente los datos
arrojados por la evaluación antes de realizar una prueba de penetración.
Advertencia
Intentar aprovechar las debilidades de los recursos de producción, puede tener efectos adversos
en la productividad y eficiencia de sus sistemas y redes.
11
En la lista siguiente se examinan algunos de los beneficios de llevar a cabo evaluaciones de
vulnerabilidad.
• Crea un enfoque pro-activo sobre la seguridad de la información
• Encuentra potenciales debilidades antes que las encuentren los atacantes
• Funciona en sistemas que se mantiene actualizados y enmendados
• Promueve el crecimiento y la asistencia en el desarrollo de la especialización del personal
• Reduce las pérdidas económicas y la publicidad negativa
1.3.2.1. Estableciendo una metodología
Para ayudar en la selección de las herramientas para realizar una evaluación de debilidades, es útil
establecer un método. Desafortunadamente, por el momento no existe una metodología previamente
definida, sin embargo, el sentido común y el hecho de adoptar buenas costumbres en materia de
seguridad pueden actuar como una guía eficiente.
¿Cuál es el objetivo? ¿Estamos observando un servidor, o la totalidad de una red y todo lo que en ella
existe? ¿Estamos fuera o dentro de la compañía? Las respuestas a estas preguntas son importantes
debido a que ayudan a determinar, no solo las herramientas que tendremos que utilizar, sino también
la forma en que vamos a hacerlo.
Para aprender más acerca del establecimiento de metodologías, visite los siguientes sitios web:
• http://www.isecom.org/osstmm/ El manual de metodología de prueba de seguridad de código
abierto (OSSTMM, por las iniciales en inglés de The Open Source Security Testing Methodology
Manual)
• http://www.owasp.org/ El proyecto de seguridad de aplicaciones de red abierta (OWASP, por las
iniciales en inglés de The Open Web Application Security Project)
1.3.3. Herramientas de evaluación
Una evaluación puede iniciarse utilizando algún tipo de herramienta que permita reunir información.
Cuando se acceda a la totalidad de la red, primero haga un mapeo del diagrama para encontrar
los equipos que se encuentren en ejecución. Una vez localizados, examine a cada uno de ellos de
manera individual. Para concentrarse en estos equipos se necesita otro conjunto de herramientas.
Conocer qué herramientas utilizar puede ser la etapa más importante del proceso para poder
encontrar debilidades.
Al igual que con cualquier aspecto de nuestra vida cotidiana, existen numerosas herramientas
diferentes que son capaces de realizar el mismo trabajo. Este concepto también se aplica a la
realización de evaluaciones de debilidades. Existen herramientas específicas para los sistemas
operativos, para las aplicaciones, incluso para las redes (de acuerdo a los protocolos utilizados).
Algunas herramientas son gratuitas, otras no. Algunas herramientas son intuitivas y sencillas de
utilizar, mientras que otras son crípticas y poco documentadas, pero que tienen capacidades que
otras no poseen.
Encontrar las herramientas apropiadas puede ser una tarea intimidante, y la experiencia es un
elemento importante para poder hacerlo. Si es posible, establezca un laboratorio de pruebas y utilice
la mayor cantidad de herramientas que pueda, anotando las debilidades y fortalezas de cada una
de ellas. Adicionalmente, busque mayor información en Internet mayor información, como ser por
ejemplo artículos, guías de tipo paso-a-paso, o incluso listas de correo de una herramienta específica.
12
Herramientas de evaluación
Las herramientas detalladas a continuación son sólo un pequeño ejemplo de las que se encuentran
disponibles.
1.3.3.1. Analizando equipos con Nmap
Nmap es una herramienta muy conocida incluida en Fedora que puede ser utilizada para determinar
el diagrama de una red. Nmap ha estado disponible desde hace muchos años, y probablemente sea
la herramienta más utilizada para reunir información de red. Incluye una página man excelente con
información detallada de sus usos y opciones. Los administradores pueden utilizar Nmap sobre una
red para encontrar sistemas de equipos y puertos abiertos en esos sistemas.
Nmap es un primer paso muy efectivo en la realización de evaluaciones de debilidades. Puede
mapear todos los equipos dentro de su red, e incluso indicar una opción que permite a Nmap
intentar identificar el sistema operativo ejecutándose en un equipo determinado. Nmap es un buen
fundamento sobre el que establecer una política de utilización de servicios seguros, y detener
servicios no seguros.
1.3.3.1.1. Usando Nmap
Nmap puede ejecutarse desde una terminal ingresando el comando nmap, seguido por el nombre del
equipo o dirección IP de la máquina a analizar.
nmap foo.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:
Starting Nmap 4.68 ( http://nmap.org )
Interesting ports on foo.example.com:
Not shown: 1710 filtered ports
PORT
STATE SERVICE
22/tcp open
ssh
53/tcp open
domain
70/tcp closed gopher
80/tcp open
http
113/tcp closed auth
Nmap verifica los puertos de comunicaciones de red 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.3.3.2. Nessus
Nessus es un examinador de seguridad para cualquier tipo de servicios. La arquitectura de tipo
complementos de Nessus permite a los usuarios personalizarlo de acuerdo a los requerimientos
de sus sistemas o redes. Como cualquier otro examinador, la eficiencia de Nessus es directamente
proporcional a la base de datos de la que depende. Afortunadamente, Nessus es actualizado
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.
13
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.3.3.3. Nikto
Nikto es un excelente examinador de programas de interfaz común de puerta de enlace (CGI, por las
iniciales en inglés de Common Gateway Interface). Nikto no sólo verifica debilidades CGI, sino que lo
hace de una forma evasiva, de modo de poder evitar sistemas de detección de intrusiones. Se ofrece
con información detallada que debería ser cuidadosamente leída antes de ejecutar el programa. Si
usted posee servidores Web ofreciendo programas CGI, Nikto puede ser una herramienta excelente
para verificar la seguridad de estos servidores.
Más información sobre Nikto se puede encontrar en la siguiente URL:
http://www.cirt.net/code/nikto.shtml
1.3.3.4. VLAD el escáner
VLAD es un examinador de debilidades desarrollado por el equipo RAZOR de Bindview, Inc., que
verifica en la lista SANS de los diez problemas de seguridad más comunes (problemas SNMP,
problemas por compartir archivos, etc.). Si bien no es tan completo como Nessus, vale la pena
investigar VLAD.
Nota
VLAD no se incluye con Fedora y no está soportado. Se ha incluido en este documento como
una referencia para aquellos usuarios que podrían estar interesados en utilizar esta conocida
aplicación.
Más información sobre VLAD se puede encontrar el sitio web del equipo RAZOR en la siguiente URL:
http://www.bindview.com/Support/Razor/Utilities/
1.3.3.5. Anticipando sus necesidades futuras
Depending upon your target and resources, there are many tools available. There are tools for
wireless networks, Novell networks, Windows systems, Linux systems, and more. Another essential
part of performing assessments may include reviewing physical security, personnel screening, or
voice/PBX network assessment. New concepts, such as war walking, which involves scanning the
perimeter of your enterprise's physical structures for wireless network vulnerabilities, are some
14
Ataques y debilidades comunes
emerging concepts that you can investigate and, if needed, incorporate into your assessments.
Imagination and exposure are the only limits of planning and conducting vulnerability assessments.
1.4. Ataques y debilidades comunes
Tabla 1.1, “Debilidades comunes” describe algunas de las debilidades y los puntos de ingreso más
utilizados por intrusos, que pretenden acceder a los recursos de organización de diferentes redes. La
clave para defender estos puntos son las explicaciones acerca de cómo se desarrollan, y cómo los
administradores pueden salvaguardar adecuadamente sus redes contra tales ataques.
Tabla 1.1. Debilidades comunes
Debilidades
Descripción
Notas
Contraseñas
nulas o
predeterminadas
Dejando las contraseñas
administrativas en blanco, o utilizando
la contraseña predeterminada puesta
por el vendedor. Esto es lo más
común en hardware como ruteadores
y cortafuegos, por lo que algunos
servicios que corren en Linux pueden
contener contraseñas administrativas
predeterminadas (aunque Fedora 12
no viene con ellas).
Asociados comúnmente a equipos
de red como ruteadores, cortafuegos,
VPNs y aparatos de almacenamiento
conectados a la red (NAS).
Común en muchos sistemas
operativos viejos, especialmente los
SOs que agrupan servicios (como
UNIX y Windows.)
Los administradores, a veces crean
apresuradamente cuentas de usuarios
privilegiados, y dejan la contraseña
en blanco, creando un punto de
entrada perfecto para usuarios
malintencionados han descubierto la
cuenta.
Claves
compartidas
predeterminadas
Los servicios de seguridad algunas
veces empaquetan claves de
seguridad establecidas por defecto,
ya sea para su desarrollo, o para
comprobar su desempeño. Si estas
claves se mantienen inalteradas y se
colocan en un entorno de producción
en Internet todos los usuarios con
las misma sclaves establecidas por
defecto tendrán acceso a ese recurso
de clave compartida, y a cualquier tipo
de información que en él se guarde.
Los puntos de acceso inalámbricos
y aparatos servidores seguros
preconfigurados más comunes.
Imitación de IP
Una máquina remota actúa como
un nodo en su red local, busca
debilidades en sus servidores, e
instala un programa de puerta trasera
o troyano para ganar el control de los
recursos de la red.
La suplantación de identidad es tan
difícil porque involucra la necesidad
del atacante de tener que predecir los
números de secuencia de TCP/IP para
coordinar una conexión a los sistemas
remotos, pero hay varias herramientas
disponibles para asistir a los atacantes
a realizar esa tarea.
Depende del tipo de servicios que
se estén ejecutando en el sistema
de destino (como por ejemplo rsh,
telnet, FTP y demás), si es que
utilizan técnicas de autenticación
basadas en la fuente, no son
15
Debilidades
Descripción
Notas
recomendadas si se las compara con
PKI, o con otras formas de autenticar
encriptaciones utilizadas en ssh, o
SSL/TLS.
Escuchas
La escucha se realiza para la
recolección de datos que pasan entre
dos nodos activos en una red.
Este tipo de ataque funciona
principalmente con protocolos de
transmisión de texto plano tales como
las transferencias Telnet, FTP y HTTP.
El atacante remoto debe tener acceso
a un sistema comprometido en una
LAN para poder realizar el ataque;
usualmente el atacante usó un ataque
activo (tal como la suplantación de
IP o la del hombre en el medio) para
comprometer un sistema en la LAN.
Las medidas preventivas incluyen
servicios con cambio de claves
criptográficas, contraseñas de un
solo uso, o autenticación encriptada
para prevenir la adivinación de
contraseñas; una fuerte encriptación
durante la transmisión también es
recomendada.
Debilidades de
servicios
Un atacante encuentra una brecha
o hueco en un servicio que corre
a través de Internet; a través de
esta vulnerabilidad, el atacante
compromete el sistema entero y
cualquier dato que pueda contener,
y puede posiblemente comprometer
otros sistemas en la red.
HTTP-based services such as CGI
are vulnerable to remote command
execution and even interactive shell
access. Even if the HTTP service
runs as a non-privileged user such
as "nobody", information such as
configuration files and network maps
can be read, or the attacker can
start a denial of service attack which
drains system resources or renders it
unavailable to other users.
Services sometimes can have
vulnerabilities that go unnoticed
during development and testing;
these vulnerabilities (such as buffer
overflows, where attackers crash a
service using arbitrary values that fill
the memory buffer of an application,
giving the attacker an interactive
command prompt from which they may
execute arbitrary commands) can give
complete administrative control to an
attacker.
Los administradores se deben
asegurar que los servicios no corren
como el usuario root, y deben vigilar
los parches y actualizaciones de errata
de las aplicaciones de vendedores u
16
Ataques y debilidades comunes
Debilidades
Descripción
Notas
organizaciones de seguridad como
CERT y CVE.
Debilidades de
aplicaciones
Los atacantes encuentran fallas en las
aplicaciones de un equipo de escritorio
o de una estación de trabajo (como
ser por ejemplo un cliente de correo
electrónico), y ejecutan un código
cualquiera, colocan caballos troyanos
para futuros daños, o simplemente
destruyen el sistema. Pueden ocurrir
futuras catástrofes si la estación de
trabajo vulnerada posee privilegios
administrativos sobre el resto de la
red.
Las estaciones de trabajo y los
equipos personales son ideales
para ser vulnerados dado que sus
usuarios no tienen ni la experiencia
ni el conocimiento para prevenir o
detectar irregularidades. Es de suma
importancia informar a los individuos
del riesgo que corren cada vez que
instalan software no autorizado, o
cuando abren archivos adjuntos de
correos electrónicos no solicitados.
Pueden ser implementados
"salvavidas" tales como configurar
al cliente de correo electrónico que
se esté utilizando de modo tal que
no abra ni ejecute archivos adjuntos
en forma automática. Además,
la actualización automática de la
estación de trabajo a través de la
red de Red Hat, o mediante algún
otro servicio de administración de
sistemas, es una forma de aliviar la
tarea de las descargas de seguridad
de tipo multi usuario.
Ataques de
Negación de
Servicio (DoS)
Attacker or group of attackers
coordinate against an organization's
network or server resources by
sending unauthorized packets to the
target host (either server, router, or
workstation). This forces the resource
to become unavailable to legitimate
users.
El caso DoS más informado en los
Estados Unidos ocurrió en el año
2000. Diferentes sitios comerciales y
gubernamentales con alta densidad
de tráfico quedaron incapacitados
por un ataque coordinado de flujo
de ping, utilizando diversos sistemas
con conexiones de banda ancha
previamente vulnerados, que actuaban
como zombies, o que redireccionaban
nodos de transmisión.
Los paquetes fuentes son usualmente
moldeados (así como reenviados),
investigando sobre la verdadera fuente
del ataque.
Los avances en el filtrado de la
entrada (IETF rfc2267) con iptables
y con sistemas detección de
intrusos como snort ayudan a los
administradores a rastrear y prevenir
ataques de DoS distribuido.
17
1.5. Actualizaciones de seguridad
A medida que las deficiencias en la seguridad se van descubriendo, el software involucrado debe
ser actualizado, y limitar así cualquier tipo de potencial riesgo. Si el software es parte de un paquete
contenido en la distribución Fedora entonces soportada, Fedora está comprometida a liberar lo antes
posible las actualizaciones necesarias para solucionar las deficiencias del paquete en cuestión. A
menudo, los anuncios sobre alguna imperfección en algún aspecto de la seguridad son acompañados
de un parche (o código fuente que solucione el problema). Este parche es entonces aplicado al
paquete de Fedora, probado y liberado como una actualización considerada de tipo errata. Sin
embargo, si algún anuncio no incluye un parche, el desarrollador trabaja primero con el encargado del
software para poder solucionar el problema. Una vez que el problema haya sido resuelto, el paquete
es probado y liberado como una actualización de tipo errata.
Si se lanza una errata de actualización del software de su sistema, es altamente recomendado
actualizar los paquetes involucrados tan pronto como sea posible para minimizar la cantidad de
tiempo en que el sistema es potencialmente vulnerable.
1.5.1. Actualización de paquetes
Cuando se actualiza el software de un sistema, es importante descargar la actualización desde
una fuente confiable. Un atacante fácilmente puede recompilar un paquete con el mismo número
de versión que el que supuestamente debería solucionar el problema, pero con una nueva falla, y
liberarlo en Internet. Si esto sucede, utilizar medidas de seguridad como archivos verificadores contra
el RPM original, tampoco va a detectar la nueva falla. Sin embargo, es muy importante descargar
RPMs solo desde fuentes confiables, como por ejemplo desde Fedora, y verificar la firma del paquete
para confirmar su integridad.
Nota
Fedora incluye un ícono en panel que muestra una alerta cada vez que exista una actualización
disponible para el sistema.
1.5.2. Verificación de paquetes firmados
Todos los paquetes de Fedora están firmados con la clave GPG de Fedora. GPG viene de GNU
Privacy Guard (guardia de la privacidad de GNU), o GnuPG, un paquete de software libre que se usa
para asegurar la autenticidad de archivos a distribuir. Por ejemplo, una clave privada (clave secreta)
bloquea el paquete mientras que la clave pública desbloquea y verifica el paquete. Si la clave pública
distribuida por Fedora no coincide con la clave privada durante la verificación del RPM, el paquete
puede haber sido alterado y por lo tanto no es confiable.
La utilidad RPM de Fedora intenta verificar automáticamente la firma GPG de un paquete RPM antes
de instalarlo. Si la clave GPG no está instalada, se debe instalar desde una ubicación estática y
segura, como el CD-ROM o DVD de instalación de Fedora.
Asumiendo que el disco está montado en /mnt/cdrom, use el siguiente comando para importarla
dentro del administrador de claves (keyring, una base de datos de claves confiables en el sistema):
rpm --import /mnt/cdrom/RPM-GPG-KEY
Para mostrar una lista de todas las claves instaladas para la verificación de RPM, ejecute el siguiente
comando:
18
Instalación de paquetes firmados
rpm -qa gpg-pubkey*
La salida será similar a la siguiente:
gpg-pubkey-db42a60e-37ea5438
Para mostrar los detalles de alguna clave en particular, use el comando rpm -qi seguido de la salida
del comando previo, como en este ejemplo:
rpm -qi gpg-pubkey-db42a60e-37ea5438
Es extremadamente importante verificar la firma de los archivos RPM antes de instalarlos para
asegurar que no hayan sido alterados desde la fuente original de los paquetes. Para verificar todos
los paquetes descargados de una vez, emita el siguiente comando:
rpm -K /tmp/updates/*.rpm
Para cada paquete, sí la llave GPG es verificada en forma exitosa, el comando retorna gpg OK. Si
no lo hace, asegúrese de que está utilizando la llave pública de Fedora correcta, así como verificar la
fuente del contenido. Los paquetes que no pasan las verificaciones GPG no deben ser instalados, ya
que pueden haber sido alterados por un tercero.
Después de verificar la clave GPG y de descargar todos los paquetes asociados con el informe de
errata, instale los paquetes como root en el indicador de la terminal.
1.5.3. Instalación de paquetes firmados
La instalación de la mayoría de los paquetes se puede hacer en forma segura (excepto para los
paquetes del kernel) emitiendo el siguiente comando:
rpm -Uvh /tmp/updates/*.rpm
Para paquetes del kernel, use el siguiente comando:
rpm -ivh /tmp/updates/<kernel-package>
Reemplace <kernel-package> en el ejemplo previo con el nombre del RPM del kernel.
Una vez que la máquina ha sido iniciada sin problema usando el nuevo kernel, el kernel viejo se
puede eliminar usando el siguiente comando:
rpm -e <old-kernel-package>
Reemplace <old-kernel-package> en el ejemplo previo con el nombre del RPM del kernel
antiguo.
Nota
No es necesario que el último kernel sea eliminado. El cargador de arranque por defecto, GRUB,
permite tener varios kernels instalados, luego elija uno desde el menú de arranque al iniciar.
19
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.
1.5.4. Aplicación de los cambios
Después de descargar e instalar las erratas de seguridad y actualizaciones, es importante dejar de
usar el software viejo y comenzar a usar el nuevo. Cómo se hace esto depende del tipo de software
que se haya actualizado. La siguiente lista muestran los items de la categoría general de software
y provee instrucciones para usar las versiones actualizadas después de cada actualización de
paquetes.
Nota
En general, reiniciar el sistema es la mejor forma de asegurarse que la última versión de un
paquete de software esté en uso; sin embargo, esta opción no es siempre necesaria, o está
disponible sólo para el administrador del sistema.
Aplicaciones
Las aplicaciones del espacio del usuario son todos los programas que se pueden usar por el
usuario común. Típicamente, tales aplicaciones se usan solamente cuando un usuario, programa
o tarea automatizada los inicia, y no están activas por períodos largos de tiempo.
Una vez que la aplicación del espacio del usuario es actualizado, detenga cualquier instancia de
la aplicación en el sistema y lance el programa de nuevo para usar la versión actualizada.
Kernel
El kernel es el componente de software principal del sistema operativo Fedora. Maneja el acceso
a la memoria, al procesador y a los periféricos, así como la planificación de todas las tareas.
Dado a su rol central, el kernel no se puede reiniciar sin detener la computadora. Por lo tanto, una
versión actualizada del kernel no se puede usar hasta que la computadora no sea reiniciada.
Bibliotecas compartidas
Las bibliotecas compartidas son unidades de códigos, como glibc, que se usan por un número
de aplicaciones y servicios. Las aplicaciones que usan una biblioteca compartida normalmente
cargan el código compartido cuando la aplicación se inicia, por lo que todas las aplicaciones que
usen la versión actualizada de la biblioteca se deben detener y reiniciar.
Para determinar qué aplicaciones en ejecución usan una biblioteca particular, use el comando
lsof como en el siguiente ejemplo:
lsof /lib/libwrap.so*
20
Aplicación de los cambios
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:
/sbin/service <service-name> restart
En el ejemplo anterior, reemplace <service-name> con el nombre del servicio, como sshd.
Servicios xinetd
Los servicios controlados por el 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:
ps -aux | grep imap
Este comando devuelve todas las sesiones IMAP activas. Las sesiones individuales pueden
determinarse con el siguiente comando:
kill <PID>
Si esto falla a terminar la sesión, use el siguiente comando en su lugar:
kill -9 <PID>
En el ejemplo anterior, reemplace <PID> con el número de identificación de proceso (se
encuentra en la segunda columna del comando ps) para una sesión IMAP.
Para detener todas las sesiones IMAP activas, ingrese el siguiente comando:
killall imapd
21
22
Guía Básica para reforzar la seguridad.
1
The US National Security Agency (NSA) has developed two guides for hardening a default installation
of Red Hat Enterprise Linux 5. Many of the tips provided in these guides are also valid for installations
of Fedora. This Basic Hardening Guide will cover portions of the NSA's Hardening Tips and will
explain why implementing these tips are important. This document does not represent the full NSA
Hardening Guide.
Como cualquier cambio en un sistema el mismo puede causar resultados inesperados. Los cambios
deben ser evaluados apropiadamente antes de ser implementados en sus sistemas.
2.1. Principios Generales
Encrypt all data transmitted over the network. Encrypting authentication information (such as
passwords) is particularly important.
Minimize the amount of software installed and running in order to minimize vulnerability.
Use security-enhancing software and tools whenever available (e.g. SELinux and IPTables).
Run each network service on a separate server whenever possible. This minimizes the risk that a
compromise of one service could lead to a compromise of others.
Maintain user accounts. Create a good password policy and enforce its use. Delete unused user
accounts.
Review system and application logs on a routine basis. Send logs to a dedicated log server. This
prevents intruders from easily avoiding detection by modifying the local logs.
Never log in directly as root, unless absolutely necessary. Administrators should use sudo to execute
commands as root when required. The accounts capable of using sudo are specified in /etc/
sudoers, which is edited with the visudo utility. By default, relevant logs are written to /var/log/
secure.
2.2. ¿Porque esto es importante?
The general principles from the NSA represent a best practices overview of security. There are items
in the above list that probably won't be used by everyone and there are items missing that should be
stressed as a best practice. Additional information on these ideas and others will be explained below.
2.3. Seguridad Física
Physical security of the system is of utmost importance. Many of the suggestions given here won't
protect your system if the attacker has physical access to the system.
Importante
This section contains information regarding GRUB Legacy and not the current release of GRUB
(also known as GRUB2). Fedora 16 does not use GRUB Legacy so many of the commands
below will not function in Fedora 16 or later versions.
Configure the BIOS to disable booting from CDs/DVDs, floppies, and external devices, and set a
password to protect these settings. Next, set a password for the GRUB bootloader. Generate a
1
http://www.nsa.gov
23
Capítulo 2. Guía Básica para reforzar la seguridad.
password hash using the command /sbin/grub-md5-crypt. Add the hash to the first line of /etc/
grub.conf using password --md5 'passwordhash'. This prevents users from entering single
user mode or changing settings at boot time.
2.4. ¿Porque esto es importante?
Un atacante puede tomar control absoluto de su sistema al arrancar de una fuente externa. Al
arrancar de una fuente externa (Ejemplo un CD vivo de Linux) mucha de las configuraciones de
seguridad puede ser anuladas. Si un atacante puede modificar la configuración del GRUB pueden
arrancar el sistema en modo simple lo que permite acceso administrativo al mismo.
2.5. ¿Que mas podemos hacer?
Ever since Fedora 9, LUKS encryption has been natively supported to protect data stored in a LUKS
encrypted partition. When you install Fedora 9, check the box to encrypt your file system when you
setup your file system. By encrypting your root partition and your /home partition (or the single /
partition if you accept the default file system) attackers using an external source or booting into single
user mode. Of course you use a strong passphrase to protect your data.
2.6. Networking
The computer's network connection is the gateway to your system. Your files and processor time
could be available to anyone who successfully connects to your system via this network connection if
other safeguards have not been implemented. One of the primary ways to keep you in control of your
system is to prevent the attackers from gaining access to your system in the first place.
2.6.1. iptables
iptables is the most widely used firewall software on Linux systems today. This program intercepts
packets coming into your computer via the network connection and filters them according to rules you
have specified. Additional information can be found in Sección 3.9, “IPTables”.
2.6.2. IPv6
IPv6 is the latest Internet protocol which aims to solve the address quantity shortfall inherent to IPv4.
And while there are no security risks directly associated with the new protocol there are a few things to
understand before utilizing this new technology.
Most system administrators are familiar with IPv4 and the work-arounds that were put in place to make
IPv4 work. One of these work-arounds is network address translation, or NAT. NAT is traditionally
used to keep the number of needed public IP addresses to a minimum when setting up a local area
network. Systems on these networks do not all require public IP addresses and valuable address
space can be saved by implementing this technology. There are some security features that were side
effects to NAT; the biggest being that outside traffic cannot make it inside the network unless a port is
forwarded across the router. Because IPv6 solves the addressing problem there is no longer a need
to use NAT. Everything can have a public IP address and, by extension, everything is not publically
routable across the Internet when physical and logical connections are made.
Another thing to worry about is how security software deals with this new protocol. iptables does not
know or understand IPv6 and so it ignores those packets altogether. That means if your network is
utilizing IPv6 and you have not activated ip6tables then you have just left the door to your system
open to the world.
Using IPv6 is not dangerous as long as you know and understand the changes that your system's
software went through to make it possible to use this new network protocol.
24
Keeping software up to date
2.7. Keeping software up to date
Software gets patched everyday. Some of these updates fix security problems that were identified by
the developers. When these patches become available it is important that they are applied to your
system as soon as possible. One of the easier ways to manage updates for your system is using yum.
A special plugin is available to allow only security updates to be installed while ignoring bugfixes and
enhancements. This plugin is explained better at Sección 8.1, “Complemento de Yum”.
2.8. Services
Services in Linux are programs that run as daemons in the background. It is important to audit these
programs regularly to determine if they need to be running. Many daemons open network ports in
order to listen for calls. Having unnecessary ports open can harm the overall security of the system.
An unknown security flaw in a piece of software can allow a hacker into a system for no good reason.
2.9. NTP
Network Time Protocol, or NTP, keeps the time on your systems accurate. Time is a very important
piece of the security puzzle and should be maintained as precisely as possible. Time is used in log
files, timestamps, and in encryption. If someone is able to control the time settings on one of your
systems then they are able to make the recreation of a break-in that much more difficult.
25
26
Asegurando su Red
3.1. Seguridad de la 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.
3.1.1. Evaluación de la seguridad de la estación de trabajo
Cuando se evalúa la seguridad de una estación de trabajo Fedora, considere los siguientes aspectos:
• Seguridad del BIOS y del gestor de arranque — ¿Puede un usuario no autorizado tener acceso a la
máquina e iniciarla como usuario único, o en modo de rescate, sin ninguna contraseña?
• Seguridad de la contraseña — ¿Qué tan seguras son las contraseñas de usuario en la máquina?
• Controles administrativos — ¿Quién posee una cuenta en el sistema y cuánto control administrativo
posee?
• Servicios de red disponibles — ¿Qué servicios están escuchando peticiones activas de la red?
¿Deberían estar ejecutándose?
• Cortafuegos personals — En caso de necesitarse alguno, ¿qué tipo de cortafuegos son
necesarios?
• Herramientas de seguridad en la comunicación mejoradas — ¿Qué herramientas deberían
utilizarse para comunicarse entre estaciones de trabajo, y cuáles deberían evitarse?
3.1.2. Seguridad en el BIOS y en el gestor de arranque
Una protección del BIOS (o de su equivalente) y del gestor de arranque mediante una contraseña,
puede prevenir que el sistema sea iniciado mediante la utilización de medios removibles, o que se
obtengan privilegios de usuario root, por cualquier usuario no autorizado que tenga acceso físico al
él. Las medidas de seguridad que debería adoptar para protegerse de este tipo de ataques depende
tanto de la calidad de la información de la estación de trabajo, como de la ubicación de la máquina.
For example, if a machine is used in a secure location where only trusted people have access and
the computer contains no sensitive information, then it may not be critical to prevent such attacks.
However, if an employee's laptop with private, unencrypted SSH keys for the corporate network is left
unattended at a trade show, it could lead to a major security breach with ramifications for the entire
company.
3.1.2.1. Contraseña BIOS
Las dos razones fundamentales para proteger con una contraseña el BIOS de una computadora son
1
:
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
1
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.
27
Capítulo 3. Asegurando su Red
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.
Because the methods for setting a BIOS password vary between computer manufacturers, consult the
computer's manual for specific instructions.
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.
3.1.2.1.1. Asegurando plataformas que no sean de tipo x86
Otras arquitecturas utilizan diferentes programas para realizar tareas de bajo nivel, apenas
equivalentes a las que realiza el BIOS en sistemas x86. Por ejemplo, las computadoras Intel®
Itanium™ utilizan el shell Interfaz de firmware extensible (EFI, por las iniciales en inglés de Extensible
Firmware Interface).
For instructions on password protecting BIOS-like programs on other architectures, refer to the
manufacturer's instructions.
3.1.2.2. Contraseñas del gestor de arranque
Las principales razones por las que proteger un gestor de arranque de Linux son las siguientes:
1. Prevenir el ingreso en modo de único usuario — Si los atacantes pueden iniciar el sistema en
modo de usuario único, 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.
3. Prevenir el acceso a sistemas operativos no seguros — Si el sistema en cuestión es de arranque
dual, un atacante puede seleccionar uno de los sistemas en el momento del inicio (por ejemplo,
DOS), que ignora controles de acceso y permisos de archivo.
Fedora por defecto instala el gestor de arranque GRUB en la plataforma x86. Para una exposición
detallada del GRUB, consulte la Guía de Instalación de Fedora.
3.1.2.2.1. Protección de GRUB con contraseña
Puede configurar el GRUB para prevenir los dos primeros problemas descritos en la Sección 3.1.2.2,
“Contraseñas del gestor de arranque”, añadiendo una directiva de contraseña a su archivo de
configuración. Para hacerlo, primero elija una contraseña poderosa, abra una terminal, regístrese
como usuario root, e ingrese el siguiente comando:
/sbin/grub-md5-crypt
Cuando se le solicite, ingrese la contraseña del GRUB y presione la tecla Intro. Con esto obtendrá
un hash MD5 de la contraseña.
28
Seguridad de contraseñas
A continuación, edite el archivo de configuración del GRUB /boot/grub/grub.conf. Abra el
archivo y debajo de la línea timeout en la sección principal del documento, añada la siguiente:
password --md5 <password-hash>
2
Replace <password-hash> with the value returned by /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:
title DOS lock
Advertencia
Una línea password debe estar presente en la sección principal del archivo /boot/grub/
grub.conf para el correcto funcionamiento de este método. De lo contrario, un atacante puede
acceder a la interfaz del editor del GRUB y eliminar la línea de bloqueo.
Para crear una contraseña diferente para un kernel particular o sistema operativo, añada la línea
lock a las presentes seguida de una línea de contraseña.
Cada porción de líneas protegidas con una contraseña única deberían empezar de manera similar al
siguiente ejemplo:
title DOS lock password --md5 <password-hash>
3.1.3. Seguridad de contraseñas
Passwords are the primary method that Fedora uses to verify a user's identity. This is why password
security is so important for protection of the user, the workstation, and the network.
Por motivos de seguridad, el programa de instalación configura el sistema para utilizar MessageDigest 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
2
GRUB also accepts unencrypted passwords, but it is recommended that an MD5 hash be used for added security.
29
alfanuméricos (deshabilitando los signos de puntuación y otros caracteres especiales), y proveyendo
un modesto nivel de encriptado de 56 bits.
Si durante la instalación se deselecciona el ocultamiento de contraseñas, todas las contraseñas son
almacenadas en un hash unidireccional en el archivo de lectura pública /etc/passwd, lo que hace
que el sistema sea vulnerable a los ataques de descubrimiento de contraseñas fuera de línea. Si
un intruso puede obtener acceso a la máquina como un usuario regular, puede copiar el archivo /
etc/passwd a su propio equipo, y ejecutar cualquier cantidad de programas de descubrimiento de
contraseñas sobre él. Si existe una contraseña no segura en el archivo, es sólo cuestión de tiempo
antes que el atacante la encuentre.
El ocultamiento de contraseñas elimina este tipo de ataques almacenando el hash de contraseña en
el archivo /etc/shadow, que solo puede ser leído por el usuario root.
Esto obliga a los potenciales atacantes a intentar descubrir las contraseñas remotamente,
registrándose en un servicio de red en la máquina, como por ejemplo SSH o FTP. Esta clase de
ataque de tipo fuerza bruta es mucho más lento y deja un rastro obvio, consistente en los cientos de
intentos fallidos de registro almacenados en los archivos del sistema. Por supuesto, si el atacante
inicia un ataque en medio de la noche en un sistema con contraseñas débiles, podría obtener acceso
antes del amanecer y editar los archivos de registro para eliminar sus huellas.
Además del las cuestiones acerca del formato y del almacenamiento, está el problema de los
contenidos. La única cosa realmente importante que un usuario puede hacer para proteger su cuenta
de ataques para descubrir su contraseña, es crear una contraseña poderosa.
3.1.3.1. Creando contraseñas poderosas
Para crear una contraseña segura, es una buena idea seguir las siguientes indicaciones:
• No utilice solo palabras o números — Nunca utilice solo números o palabras en contraseñas.
Algunos ejemplos inseguros incluyen los siguientes:
• 8675309
• juan
• hackeame
• No use palabras reconocibles — Palabras como nombres propios, palabras de diccionario,
o incluso términos de shows de televisión, o de novelas, deberían ser evitados. Aún si están
complementadas con números.
• martin1
• DS-9
• tevez123
• No utilice palabras de otros idiomas — Los programas de descubrimiento de contraseñas a menudo
verifican sobre listas de palabras que incluyen diccionarios de muchos idiomas. Confiar en idiomas
extranjeros para establecer contraseñas seguras, no es algo aconsejable.
• cheguevara
30
• 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
• El nombre de un miembro de la familia
• Cualquier fecha de cumpleaños
• Su número de teléfono o su código postal
• No invierta palabras reconocibles — Los buenos verificadores de contraseña siempre invierten
palabras comunes, por lo que la inversión de un mala contraseña no la hace más segura.
• R0X4H
• nauj
• 9-DS
• No escriba su contraseña — Nunca guarde su contraseña en papel. Es más seguro memorizarla.
• No use la misma contraseña para todas las computadoras — es importante crear contraseñas
distintas para cada máquina. De esta forma, si un sistema está comprometido, todas sus
computadoras no estarán inmediatamente en riesgo.
Los siguientes consejos le ayudarán a crear una contraseña fuerte:
• La contraseña debe tener al menos 8 caracteres de largo — Cuanto más larga la contraseña,
mejor. Si usa contraseñas MD5, deben ser de 15 caracteres o más. Con contraseñas DES, use la
longitud máxima (ocho caracteres).
• Mezcle letras en mayúsculas y minúsculas — Fedora diferencia entre mayúsculas y minúsculas,
por lo que su mezcla mejora la fortaleza de la contraseña.
• Mezcle letras con números — Agregar números a la contraseña mejora la fortaleza de la misma,
especialmente cuando se los agrega en el medio (no al principio ni al final).
31
• Include Non-Alphanumeric Characters — Special characters such as &, $, and > can greatly
improve the strength of a password (this is not possible if using DES passwords).
• Elija una 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.
3.1.3.1.1. Metodología para la creación de una contraseña segura
Hay muchos métodos que se pueden usar para crear contraseñas seguras. Uno de los más populares
involucra las siglas. Por ejemplo:
• Piense en una frase fácil de recordar, tal como:
"over the river and through the woods, to grandmother's house we go."
• Luego, conviértala en una sigla (incluyendo la puntuación).
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.
• Finalmente, no use nunca la contraseña ejemplo anterior para ningún sistema.
La creación de contraseñas seguras es imperativo, y su apropiada administración es igual de
importante, especialmente para administradores de sistemas dentro de organizaciones grandes.
La siguiente sección detalla las buenas prácticas para crear y administrar las contraseñas de los
usuarios dentro de una organización.
3.1.3.2. Creación de contraseñas de usuarios dentro de una organización
Si una organización tiene un gran número de usuarios, los administradores de sistema tienen dos
opciones básicas disponibles para obligar al uso de contraseñas buenas. Pueden crear contraseñas
para los usuarios, o permitirles crear sus propias contraseñas, pero verificando que sean de una
calidad aceptable.
La creación de contraseñas para usuarios asegura que las contraseñas sean buenas, pero se vuelve
una tarea intimidante a medida que la organización crece. También aumenta el riesgo de que los
usuarios escriban sus contraseñas.
Por estas razones, la mayoría de los administradores de sistema prefieren que sus usuarios creen
sus propias contraseñas, pero verificar activamente que sean buenas y, en algunos casos, forzarlos a
cambiarlas periódicamente mediante el establecimiento de un período determinado de validez.
32
3.1.3.2.1. Obligando a usar contraseñas poderosas
Para proteger la red de intrusos, es una buena idea que los administradores del sistema comprueben
que las contraseñas utilizadas dentro de una organización sean buenas y potentes. Cuando se les
pida a los usuarios crear o modificar una contraseña, pueden utilizar la herramienta de línea de
comando passwd, que es compatible con el Administrador de módulos de autenticación conectables
(PAM, por las iniciales en inglés de Pluggable Authentication Manager), y por lo tanto verifica si la
contraseña es demasiado corta o demasaido fácil de descubrir. Esta comprobación es realizada
utilizando el módulo PAM pam_cracklib.so. Ya que PAM es personalizable, es posible añadir más
verificadores de la integridad de las contraseñas, como ser por ejemplo, pam_passwdqc (disponible
en http://www.openwall.com/passwdqc/), o escribir un módulo nuevo. Para conocer una lista de
módulos PAM disponibles, vea http://www.kernel.org/pub/linux/libs/pam/modules.html. Para obtener
mayor información acerca de PAM, vaya a la Sección 3.5, “Módulos de autenticación conectables
(PAM, por las iniciales en inglés de Pluggable Authentication Modules)”.
La verificación de la contraseña que se realiza al momento de su creación, no permite saber con tanta
certeza si una contraseña es débil, cosa que sí se puede verificar exactamente con la ejecución sobre
ellas de un programa de descubrimiento de contraseñas.
Muchos programas de descubrimiento de contraseñas están disponibles para ejecutarse en Fedora,
aunque ninguno viene con el sistema operativo. A continuación ofrecemos una pequeña lista con
algunos de los programas de descubrimiento de contraseñas más populares:
• John The Ripper — Un programa de descubrimiento de contraseña rápido y flexible. Permite el
uso de múltiples listas de palabras y puede descubrir contraseñas por fuerza bruta. Está disponible
en línea en http://www.openwall.com/john/.
• Crack — Tal vez el software de descubrimiento de contraseñas más conocido, Crack es también
muy rápido, aunque no tan fácil de usar como John The Ripper. Se lo puede encontrar en línea en
http://www.crypticide.com/alecm/security/c50-faq.html.
• Slurpie — Slurpie es similar a John The Ripper y a Crack, pero se diseñó para correr en varias
computadoras a la vez, creando un ataque de descubrimiento de contraseñas distribuido. Se
puede encontrar junto con un número de otras herramientas de evaluación de seguridad al ataque
distribuído, en línea en http://www.ussrback.com/distributed.htm.
Advertencia
Siempre obtenga una autorización por escrito antes de intentar descubrir contraseñas dentro de
una organización
3.1.3.2.2. Frases de acceso
Passphrases and passwords are the cornerstone to security in most of today's systems. Unfortunately,
techniques such as biometrics and two-factor authentication have not yet become mainstream in many
systems. If passwords are going to be used to secure a system, then the use of passphrases should
be considered. Passphrases are longer than passwords and provide better protection than a password
even when implemented with non-standard characters such as numbers and symbols.
3.1.3.2.3. Edad de las contraseñas
El envejecimiento de las claves es otra técnica usada por los administradores del sistema para
defenderlo de malas contraseñas dentro de una organización. El envejecimiento de la contraseña
significa que después de un período especificado (normalmente 90 días), el usuario debe crear
33
una nueva contraseña. La idea detrás de este método es que si el usuario es forzado a cambiar
su contraseña periódicamente, una contraseña descubierta sería útil para un intruso por un tiempo
limitado. La contra del envejecimiento es que los usuarios, seguramente, anotarán en un papel sus
contraseñas.
Hay dos programas principales usados para especificar el envejecimiento de contraseñas bajo
Fedora: el comando chage o la aplicación gráfica Administración -> Usuarios y Grupos (systemconfig-users).
The -M option of the chage command specifies the maximum number of days the password is valid.
For example, to set a user's password to expire in 90 days, use the following command:
chage -M 90 <username>
In the above command, replace <username> with the name of the user. To disable password
expiration, it is traditional to use a value of 99999 after the -M option (this equates to a little over 273
years).
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>
El siguiente es un ejemplo de la sesión interactiva usando este comando:
[root@myServer ~]# chage davido
Changing the aging information for davido
Enter the new value, or press ENTER for the default
Minimum Password Age [0]: 10
Maximum Password Age [99999]: 90
Last Password Change (YYYY-MM-DD) [2006-08-18]:
Password Expiration Warning [7]:
Password Inactive [-1]:
Account Expiration Date (YYYY-MM-DD) [1969-12-31]:
[root@myServer ~]#
Vaya a la 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.
2.
Haga clic en la pestaña Usuarios y seleccione el usuario requerido de la lista de usuarios.
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 Información de la Contraseña, y seleccione la casilla de Activar
expiración de contraseña.
5.
Ingrese el valor requerido en el campo Días requeridos antes de cambiar y haga clic en
Aceptar.
34
Controles administrativos
Figura 3.1. Especificación de las opciones de edad de las contraseñas
3.1.4. Controles administrativos
When administering a home machine, the user must perform some tasks as the root user or by
acquiring effective root privileges via a setuid program, such as sudo or su. A setuid program is
one that operates with the user ID (UID) of the program's owner rather than the user operating the
program. Such programs are denoted by an s in the owner section of a long format listing, as in the
following example:
-rwsr-xr-x 1 root root 47324 May 1 08:09 /bin/su
Nota
La s puede figurar en 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 3.5, “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.
35
Como resultado, los administradores del sistema deben decidir cuánto acceso deben otorgarle a los
usuarios de la red.
3.1.4.1. Permitiendo accesos root
Si los usuarios de una organización son confiables y conocen acerca de computadoras, permitirles
acceso root no debería ser un problema. Esto significa que actividades menores, como añadir
dispositivos o configurar interfases de red podrían ser realizadas por los usuarios individuales,
quedando los administradores del sistema liberados y poder realizar tareas más importantes
relacionadas, por ejemplo, con la red o con la seguridad.
Por otro lado, darle accesos de root a usuarios individuales podría generar los siguientes
inconvenientes:
• Configuración errónea del equipo — Los usuarios con acceso root pueden desconfigurar sus
máquinas y necesitar asistencia para resolver problemas. O peor aún, podrían abrir agujeros en la
seguridad del sistema sin saberlo.
• Ejecutar servicios no seguros — Usuarios con acceso root podrían ejecutar servidores no seguros
en su máquina, como por ejemplo Telnet o FTP, poniendo en riesgo en forma potencial nombres de
usuarios o contraseñas. Estos servicios transmiten la información sobre la red en formato de texto
simple.
• Ejecutar archivos adjuntos de correos como usuarios root — Si bien son excepcionales, existen
virus de correo electrónico que afectan a los sistemas Linux. Sin embargo, el único momento en
que se convierten en una amenaza, es cuando son ejecutados por el usuario root.
3.1.4.2. Anulación del acceso como root
Si un administrador no se encuentra cómodo al permitir que los usuarios se registren como usuarios
root por estas razones, o por otras, la contraseña de usuario root debería ser mantenida en secreto, y
el acceso al nivel de ejecución 1, o al modo de usuario único, debería ser desactivado mediante una
protección del gestor de arranque a través de una contraseña (para obtener mayor información en
este aspecto, vea la Sección 3.1.2.2, “Contraseñas del gestor de arranque”).
Tabla 3.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:
Tabla 3.1. Métodos para deshabilitar la cuenta root
Método
Descripción
Efectos
No afecta
Cambio
del shell
para root.
Edite el archivo /etc/
passwd y cambie la
terminal de /bin/bash a
/sbin/nologin.
Previene acceso a la
terminal root y registra
cualquiera de tales
intentos.
Los siguientes programas
están prevenidos al intentar
ingresar a la cuenta de
usuario root:
· login
· gdm
· kdm
· xdm
· su
· ssh
· scp
Programas que no
necesiten de una terminal,
como por ejemplo, clientes
FTP, clientes de correo, y
muchos programas de tipo
setuid.
no están prevenidos al
intentar acceder a la
cuenta root:
· sudo
· Clientes de FTP
· Clientes de correo
36
Método
Descripción
Efectos
No afecta
· sftp
1
Deshabilitar Un archivo /etc/
el acceso securetty vacío
root
previene los intentos de
mediante accesos root a cualquier
cualquier dispositivo asociado con la
dispositivo computadora.
de
consola
(tty)
Previene accesos a la
cuenta root mediante
la consola o la red. Los
siguientes programas
son prevenidos al intentar
acceder a la cuenta root:
· login
· gdm
· kdm
· xdm
· Otros servicios de red que
abran una tty
Deshabilitación
Edite el archivo /etc/
de las
ssh/sshd_config y
opciones establezca el parámetro
de
PermitRootLogin en no.
ingreso
como root
por SSH.
Prevenga el acceso root
Esto sólo previene el
utilizando el conjunto de
acceso root al conjunto de
herramientas de OpenSSH. herramientas de OpenSSH.
acceder a a cuenta root:
· ssh
· scp
· sftp
Utilice
PAM para
limitar el
acceso
root a los
servicios.
Previene el acceso root a
los servicios de red que
son compatibles com PAM.
Los siguientes servcicios
acceder a la cuenta de
root:
· Clientes de FTP
· Clientes de correo
· login
· gdm
· kdm
· xdm
· ssh
· scp
· sftp
· Cualquier servicio PAM
Edite el archivo para el
servicio en cuestión en el
directorio /etc/pam.d/.
Asegúrese que el archivo
pam_listfile.so
sea requerido para
1
autenticación.
Programas que no se
registran como root,
pero que realizan tareas
administrativas mediante
programas de tipo
setuid, o mediante otros
mecanismos.
no están prevenidos al
intentar acceder a la
cuenta root:
· su
· sudo
· ssh
· scp
· sftp
Programas y servicios que
no son compatibles con
PAM.
Para obtener más detalles, diríjase a la Sección 3.1.4.2.4, “Deshabilitando root usando PAM”.
3.1.4.2.1. Deshabilitando la cuenta shell de root
To prevent users from logging in directly as root, the system administrator can set the root account's
shell to /sbin/nologin in the /etc/passwd file. This prevents access to the root account through
commands that require a shell, such as the su and the ssh commands.
37
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.
3.1.4.2.2. Deshabilitando conexiones como root
To further limit access to the root account, administrators can disable root logins at the console by
editing the /etc/securetty file. This file lists all devices the root user is allowed to log into. If the
file does not exist at all, the root user can log in through any communication device on the system,
whether via the console or a raw network interface. This is dangerous, because a user can log in to
his machine as root via Telnet, which transmits the password in plain text over the network. By default,
Fedora's /etc/securetty file only allows the root user to log in at the console physically attached
to the machine. To prevent root from logging in, remove the contents of this file by typing the following
command:
echo > /etc/securetty
Advertencia
Un archivo /etc/securetty 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.
3.1.4.2.3. Deshabilitando conexiones SSH como root
Root logins via the SSH protocol are disabled by default in Fedora; however, if this option has been
enabled, it can be disabled again by editing the SSH daemon's configuration file (/etc/ssh/
sshd_config). Change the line that reads:
PermitRootLogin yes
leer como sigue:
PermitRootLogin no
Para que estos cambios tengan efecto, el demonio SSH debe ser reiniciado. Esto puede realizarse
mediante el siguiente comando:
kill -HUP `cat /var/run/sshd.pid`
3.1.4.2.4. Deshabilitando root usando PAM
PAM, a través del módulo /lib/security/pam_listfile.so, permite gran flexibilidad a la hora
de denegar cuentas específicas. El administrador puede utilizar este módulo para hacer referencia a
una lista de usuarios que no tienen permitido registrarse. Más abajo mostramos un ejemplo acerca
de cómo el módulo es utilizado por el servidor FTP vsftpd en el archivo de configuración de PAM
38
/etc/pam.d/vsftpd (el caracter \ al final de la primera línea en el ejemplo no es necesario si la
directiva se encuentra en una sola línea):
auth required /lib/security/pam_listfile.so item=user \
sense=deny file=/etc/vsftpd.ftpusers onerr=succeed
Esto le indica a PAM que consulte el archivo /etc/vsftpd.ftpusers y que niegue el acceso
al servicio al usuario listado. El administrador puede modificar el nombre en este archivo, y puede
tener diferentes listas para cada servicio, o utilizar una lista principal para negar el acceso a múltiples
servicios.
Si el administrador quiere negar el acceso a múltiples servicios, una línea similar puede ser añadida a
los archivos de configuración PAM, como por ejemplo, /etc/pam.d/pop y /etc/pam.d/imap para
clientes e correo, o /etc/pam.d/ssh para clientes SSH.
Para obtener mayor información acerca de PAM, vea la Sección 3.5, “Módulos de autenticación
conectables (PAM, por las iniciales en inglés de Pluggable Authentication Modules)”.
3.1.4.3. Limitando acceso como root
En lugar de negarle acceso completamente al usuario root, el admisnitrador podría querer permitirle el
acceso sólo mediante la utilización de programas de tipo setuid, como ser por ejemplo su o sudo.
3.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:
usermod -G wheel <username>
In the previous command, replace <username> with the username you want to add to the wheel
group.
También puede utilizar de la siguiente manera el Administrador de usuarios para modificar
las pertenencias a los grupos. Nota: necesita privilegios de administrador para realizar este
procedimiento:
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.
2.
Haga clic en la pestaña Usuarios y seleccione el usuario requerido de la lista de usuarios.
3
Estos accesos aún están sujetos a las restricciones impuestas por SELinux, si es que se encuentra activo.
39
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 3.2, “Adding users to the "wheel" group.”.
5.
Abra el archivo de configuración PAM para el comando su (/etc/pam.d/su) en un editor de
textos, y elimine el comentario # de la siguiente línea:
auth
required /lib/security/$ISA/pam_wheel.so use_uid
Este cambio significa que solo miembros del grupo administrativo wheel pueden usar este
programa.
Figura 3.2. Adding users to the "wheel" group.
Nota
El usuario root es por defecto miembro del grupo wheel.
3.1.4.3.2. El comando sudo
El comando sudo ofrece un nuevo punto de vista a la cuestión acerca de si otorgarle o no accesos
administrativos a los usuarios. Cuando un usuario confiable le anteponga el comando sudo a un
comando administrativo, le será pedida su propia contraseña. Entonces, cuando sea autenticado y
asumiendo que el comando le sea permitido, el comando administrativo en cuestión será ejecutado
como si este usuario fuera el usuario root.
40
Servicios de red disponibles
Los formatos básicos del comando sudo son los siguientes:
sudo <command>
In the above example, <command> would be replaced by a command normally reserved for the root
user, such as mount.
Importante
Los usuarios del comando sudo 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.
The sudo command allows for a high degree of flexibility. For instance, only users listed in the /etc/
sudoers configuration file are allowed to use the sudo command and the command is executed in
the user's shell, not a root shell. This means the root shell can be completely disabled, as shown in
Sección 3.1.4.2.1, “Deshabilitando la cuenta shell de root”.
The sudo command also provides a comprehensive audit trail. Each successful authentication is
logged to the file /var/log/messages and the command issued along with the issuer's user name is
logged to the file /var/log/secure.
Otra ventaja del comando sudo es que un administrador puede permitir a diferentes usuarios acceder
a comandos específicos de acuerdo a sus necesidades.
Los administradores que quieran editar /etc/sudoers, el archivo de configuración del comando
sudo, deberían utilizar el comando visudo.
Para otrogarle a un usario todos los privilegios admisnitrativos, ingrese visudo, y agregue una línea
similar a la siguiente en la sección de especificaciones de los privilegios del usuario:
juan ALL=(ALL) ALL
Este ejemplo indica que el usuario juan, puede utilizar el comando sudo desde cualquier equipo y
ejecutar cualquier comando.
El ejemplo que damos a continuación ilustra pequeños detalles posibles al configurar sudo:
%users localhost=/sbin/shutdown -h now
Este ejemplo indica que cualquier usuario puede ejecutar el comando /sbin/shutdown -h now,
siempre y cuando lo haga desde una consola.
La página man del archivo sudoers contiene una lista detallada de opciones.
3.1.5. Servicios de red disponibles
Si bien el acceso de los usuarios a controles administrativos es un problema importante para los
administradores del sistema dentro de una organización, controlar qué servicios de red son los que se
encuentran activos, es de importancia suprema para cualquiera que opere un sistema Linux.
41
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.
3.1.5.1. Riesgos a servicios
Los servicios de red puede plantear numerosos riesgos para sistemas Linux. A continuación
mostramos una lista con algunas de las cuestiones principales:
• Ataques de denegación de servicio (DoS, por las iniciales en inglés de Denial of Service Attacks )
— Al inundar un servicio con peticiones, un ataque de denegación de servicio puede dejar
inutilizable a un sistema, ya que este trata de registrar y de responder a cada petición.
• 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.
42
Servicios de red disponibles
Importante
Para limitar la exposición a ataques en la red, todos los servicios que no son utilizados deben ser
apagados.
3.1.5.2. Identificando y configurando servicios
Para mejorar la seguridad, muchos de los servicios de red instalados con Fedora están apagados por
defecto. Hay, de todas formas, algunas notables excepciones:
• cupsd — El servidor de impresión por defecto para Fedora.
• lpd — Un servidor de impresión alternativo.
• xinetd — Un súper servidor que controla las conexiones de un rango de servidores subordinados,
como son, por 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.
• sshd — El servidor OpenSSH, es un reemplazo seguro para Telnet.
Cuando se intenta conocer cuándo dejar estos servicios en ejecución, lo mejor es utilizar el sentido
común y adoptar un punto de vista basado en la precaución. Por ejemplo, si una impresora no está
disponible, no deje el servicio cupsd prendido. Lo mismo vale para portmap. Si usted no monta
volumenes NFSv3, o utiliza NIS (el servicio ypbind), entonces portmap debería deshabilitarse.
Figura 3.3. Herramienta de Configuración de Servicios
43
Si no está seguro de los propósitos de un servicio particular, la Herrameinta de configuración de
servicios tiene un campo descriptivo, que se detalla en Figura 3.3, “Herramienta de Configuración
de Servicios”, y que ofrece información adicional.
Verificar qué servicios de red se encuentran disponibles para iniciarse en el momento del arranque
del sistema, es sólo una parte de esta historia. Debería verificar también qué puertos están abiertos y
escuchando. Para más información, vea la Sección 3.2.8, “Verificar qué puertos están abiertos”.
3.1.5.3. Servicios inseguros
Cualquier servicio de red es potencialmente inseguro. Es por esto que es tan importante apagar
los servicios que no se utilicen. Las debilidades de los servicios son cotidianamente descubiertas y
enmendadas, haciendo que sea muy importante actualizar los paquetes relacionados con cualquiera
de los servicios de red. Para obtener más información, vea la Sección 1.5, “Actualizaciones de
seguridad”.
Algunos protocolos de red son en sí mismos más inseguros que otros. Estos incluyen los servicios
que:
• Transmiten sin encriptar nombres de usuarios y contraseñas en la red — Muchos protocolos
antiguos, como por ejemplo Telnet y FTP, no encriptan las autenticaciones de las sesiones, y
siempre que sea posible, deberían ser evitados.
• Transmit Sensitive Data Over a Network Unencrypted — Many protocols transmit data over the
network unencrypted. These protocols include Telnet, FTP, HTTP, and SMTP. Many network file
systems, such as NFS and SMB, also transmit information over the network unencrypted. It is the
user's responsibility when using these protocols to limit what type of data is transmitted.
Servicios de volcado de memoria remoto, como netdump, transmiten el contenido de la memoria
sobre una red sin encriptar . Los volcados de memoria pueden contener contraseñas o, peor aún,
entradas a base de datos o información sensible.
Otros servicios como finger y rwhod revelan información sobre usuarios del sistema.
Ejemplos de servicios inherentemente inseguros incluyen rlogin, rsh, telnet, y vsftpd.
Todos los programas de ingreso remoto de consola (rlogin, rsh, y telnet) deberían ser
evitados en favor de la utilización de SSH. Para obtener mayor información acerca de sshd, vea la
Sección 3.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 3.2.6, “Asegurando
FTP”.
Entre los ervicios que deberían ser cuidadosamente implementados, y colocarse detrás de un
cortafuegos, podemos encontrar a:
• finger
• authd (antes llamado identd en versiones anteriores de Fedora.)
• netdump
• netdump-server
• nfs
• rwhod
44
Cortafuegos personales
• sendmail
• smb (Samba)
• yppasswdd
• ypserv
• ypxfrd
Mayor información acerca de cómo asegurar servicios de red puede encontrarse en la Sección 3.2,
“Seguridad del servidor”.
La siguiente sección discute las herramientas disponibles para crear un cortafuegos sencillo.
3.1.6. Cortafuegos personales
Luego de haberse configurado los servicios de red necesarios, es importante la implementación de un
cortafuegos.
Importante
Debería configurar los servicios necesarios e implementar un cortafuegos antes de conectarse a
Internet, o a cualquier otra red en la que usted no confíe.
Firewalls prevent network packets from accessing the system's network interface. If a request is made
to a port that is blocked by a firewall, the request is ignored. If a service is listening on one of these
blocked ports, it does not receive the packets and is effectively disabled. For this reason, care should
be taken when configuring a firewall to block access to ports not in use, while not blocking access to
ports used by configured services.
Para la mayoría de los usuarios, la mejor herramienta para configurar un cortafuegos es mediante
la interfaz gráfica de configuración de cortafuegos que viene con Fedora: la Herramienta de
administración de coftafuegos (system-config-firewall). Esta herramienta genera reglas
amplias de iptables para un cortafuegos de propósitos generales, utilizando una interfaz de panel
de control.
Para obtener mayor información acerca del uso de esta aplicación y sus opciones disponibles, vea la
Sección 3.8.2, “Configuración básica de un cortafuego”.
Para usuarios avanzados y administradores de servidores, es una mejor opción la de configurar
manualmente el cortafuegos utilizando iptables. Para obtener mayor información, vea la
Sección 3.8, “Cortafuegos”. Para una guía detallada de la utilización del comando iptables, vea la
Sección 3.9, “IPTables”.
3.1.7. Herramientas de comunicación de seguridad mejorada
Así como han crecido el tamaño y la popularidad de Internet, también han aumentado los peligros de
la interceptación de las comunicaciones. Con el correr de los años, se han desarrollado herramientas
para encriptar las comunicaciones mientras están siendo transferidas sobre la red.
Fedora viene con dos herramientas básicas, que usan algoritmos de encriptación de alto nivel de
clave pública, para proteger la información mientras viaja por la red:
45
• OpenSSH — Una implementación libre del protocolo SSH para encriptar comunicaciones de red.
• Protección de Privacidad Gnu (GPG, por las iniciales en inglés de Gnu Privacy Guard) — Una
implementación libre para proteger los datos de la aplicación para encriptado PGP (por las iniciales
en inglés de Pretty Good Privacy).
OpenSSH es la forma más segura de acceder a equipos remotos y reemplazar servicios antiguos
y no encriptados como telnet y rsh. Open SSH ofrece un servicio de red llamado sshd y tres
aplicaciones de cliente mediante la línea de comandos:
• ssh — Un cliente seguro para acceso a consola remota.
• scp — Un comando de copia remota segura.
• sftp — Un pseudo cliente ftp seguro que permite sesiones interactivas de transferencias de
archivos.
Vaya a la Sección 4.2.2, “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.
3.2. Seguridad del servidor
Cuando un sistema es utilizado como servidor en una red pública, se convierte en el objetivo de los
ataques. Por lo tanto, robustecer el sistema y desconectar los servicios es de importancia suprema
para el administrador del sistema.
Antes de profundizar en problemas específicos, recuerde los siguientes consejos generales para
fortalecer la seguridad de los servidores:
• Mantenga todos los servicios actualizados, para protegerse contra las últimas amenazas.
• Siempre que sea posible, utilice protocolos seguros.
• Siempre que sea posible, ofrezca sólo un tipo de servicio de red por máquina.
• Observe cuidadosamente a todos los servidores en busca de actividad sospechosa.
3.2.1. Asegurando los servicios con encapsuladores TCP y xinetd
Los encapsuladores TCP ofrecen control de acceso para una variedad de servicios. Muchos de los
servicios de red modernos, como SSH, Telnet, y FTP, utilizan encapsuladores TCP, quienes hacen de
guardianes entre la petición entrante y el servicio solicitado.
46
Asegurando los servicios con encapsuladores TCP y xinetd
Los beneficios que ofrecen los encapsuladores TCP se potencian si se utilizan junto a xinetd, un
super servidor que ofrece acceso adicional, registrado, vinculación, redireccionamiento y control de la
utilización de los recursos.
Nota
Es una buena idea utilizar reglas de cortafuego iptables junto con los encapsuladores TCP y
xinetd, para generar redundancia dentro de los controles de acceso al servicio. Para obtener
más información acerca de la implementación de cortafuegos con comandos iptable, vea la
Sección 3.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.
3.2.1.1. Mejorando la seguridad utilizando encapsuladores TCP
Los encapsuladores TCP son capaces de mucho más que denegar el acceso a servicios. Esta
sección ilustra como se pueden usar para enviar pancartas de conexión, alertar de ataques de
nodos en particular y aumentar la funcionalidad de registro. Refiérase a la página del manual
hosts_options para obtener información acerca de la funcionalidad de los encapsuladores TCP y
el lenguaje de control.
3.2.1.1.1. Encapsuladores TCP y pancartas de conexión
Desplegar una pancarta apropiada cuando los usuarios se conectan a un servicio es una buena
manera de hacerle saber a los posibles atacantes que el administrador del sistema está vigilando.
Usted puede también controlar qué información acerca del sistema es presentada a los usuarios.
Para implementar una pancarta por medio de encapsuladores TCP para un servicio, use la opción
banner.
Este ejemplo implementa una pancarta para vsftpd. Para comenzar, cree un archivo de pancarta.
Puede ser en cualquier lugar del sistema, pero debe tener el mismo nombre que el demonio. Para
este ejemplo, el archivo es llamado /etc/banners/vsftpd y contiene la siguiente linea:
220-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:
vsftpd : ALL : banners /etc/banners/
3.2.1.1.2. Encapsuladores TCP y alertas de ataque
Si un huésped o red en particular han sido detectados atacando el servidor, los encapsuladores
TCP pueden ser usados para alertar al administrador de ataques subsecuentes provenientes de ese
huésped o red usando la directiva spawn.
47
En este ejemplo, asumamos que un atacante de la red 206.182.68.0/24 ha sido detectado tratando
de atacar el servidor. Agregue la siguiente linea en el archivo /etc/hosts.deny para denegar
cualquier intento de conexión desde esa red, y para registrar los intentos a un archivo en especial:
ALL : 206.182.68.0 : spawn /bin/ 'date' %c %d >> /var/log/intruder_alert
La ficha %d proveé el nombre del servicio al que el atacante está tratando de acceder.
Para permitir una conexión y registrarla, use la directiva spawn en el archivo /etc/hosts.allow.
Nota
Ya que la directiva spawn ejecuta cualquier comando, es una buena idea crear un programa
especial para notificar al administrador o ejecutar una cadena de comandos en el evento de un
cliente en particular tratando de conectarse al servidor.
3.2.1.1.3. Encapsuladores TCP y registro avanzado
Si ciertos tipos de conexión son más preocupantes que otros, el nivel de registro puede ser elevado
para ese servicio usando la opción severity.
Para este ejemplo, asumamos que cualquiera que intente conectarse al puerto 23 (el puerto de
Telnet) en un servidor FTP está tratando de romper el sistema. Para denotar esto, use la bandera
emerg en los archivos de registro en lugar de la bandera por defecto info y deniegue la conexión.
Para hacer esto, ponga la siguiente linea en el archivo /etc/hosts.deny:
in.telnetd : ALL : severity emerg
Esto usa la facilidad de registro por defecto authpriv, pero eleva la prioridad del valor por defecto
info a emerg, lo cual escribe los mensajes de registro directamente a la consola.
3.2.1.2. Aumentando la seguridad con xinetd
Esta sección se concentra en el uso de xinetd para crear un servicio de trampa y usarlo para
controlar los niveles de recurso disponibles para cualquier servicio xinetd. Crear límites de recursos
para los servicios puede ayudar a frustrar ataques de denegación de servicio (Denial of Service,
DoS). Refiérase a las páginas del manual para xinetd y xinetd.conf para una lista de opciones
disponibles.
3.2.1.2.1. Poniendo una trampa
Una característica importante de xinetd es su habilidad para agregar equipos a una lista
no_access global. Los equipos en esta lista no pueden crear conexiones subsecuentes a servicios
manejados por xinetd por un periodo específico de tiempo, o hasta que xinetd sea reiniciado.
Usted puede hacer esto usando el atributo SENSOR. Esta es una manera fácil de bloquear equipos
que intentan explorar puertos en el servidor.
El primer paso para crear un SENSOR es escoger que servicio no está planeado a usarse. En este
ejemplo es utilizado telnet.
Edite el archivo /etc/xinetd.d/telnet y cambie la linea flags a:
48
Asegurando los servicios con encapsuladores TCP y xinetd
flags
= SENSOR
Agregue la siguiente línea:
deny_time
= 30
Esto deniega cualquier intento de conexión a este puerto para ese equipo por 30 minutos. Otros
valores aceptables para el atributo deny_time son FOREVER, el cual mantiene el veto en efecto
hasta que xinetd es reiniciado y NEVER, el cual permite la conexión y la registra.
Finalmente, la última linea debe ser:
disable
= no
Esto habilita la trampa.
Mientras que el uso de SENSOR es una buena idea para detectar y detener conexiones desde equipos
indeseables, tiene dos características en contra:
• No funciona contra exploraciones sigilosas (stealth)
• Un atacante que sabe que un 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.
3.2.1.2.2. Control de los recursos del servidor
Otra característica importante de xinetd es su habilidad de declarar límites de recursos para los
servicios bajo su control.
Lo hace usando las siguientes directivas
• cps = <number_of_connections> <wait_period> — Limita la tasa de conexiones
entrantes. Ésta toma dos argumentos:
• <number_of_connections> — El número de conexiones por segundo para gestionar. Si la
tasa de conexiones entrantes es mayor que ésta, el servicio es temporalmente deshabilitado. El
valor predeterminado es cincuenta (50).
• <wait_period> — El número de segundos para esperar antes de rehabilitar el servicio
después que éste ha sido deshabilitado. El intervalo predeterminado es diez (10) segundos.
• instances = <number_of_connections> — Specifies the total number of connections
allowed to a service. This directive accepts either an integer value or UNLIMITED.
• per_source = <number_of_connections> — Specifies the number of connections allowed to
a service by each host. This directive accepts either an integer value or UNLIMITED.
• rlimit_as = <number[K|M]> — Specifies the amount of memory address space the service
can occupy in kilobytes or megabytes. This directive accepts either an integer value or UNLIMITED.
• rlimit_cpu = <number_of_seconds> — Specifies the amount of time in seconds that a
service may occupy the CPU. This directive accepts either an integer value or UNLIMITED.
Usar estas directivas puede ayudar a prevenir cualquier servicio xinetd de abrumar el sistema,
resultando en una denegación de servicio.
49
3.2.2. Asegurando Portmap
El servicio portmap es un demonio de asignación dinámica de puertos para servicios RPC como NIS
y NFS. Tiene mecanismos débiles de autenticación y tiene la habilidad de asignar un amplio rango de
puertos para los servicios que controla. Por estas razones, es difícil de asegurar.
Nota
Asegurar portmap solo afecta a las implementaciones NFSv2 y NFSv3, ya que desde NFSv4 ya
no es requerido. Si usted planea implementar un servidor NFSv2 o NFSv3, entonces portmap
es requerido, y la siguiente sección aplica.
Si corre servicios RPC, obedezca estas reglas básicas.
3.2.2.1. Proteja portmap con encapsuladores TCP
Es importante usar encapsuladores TCP para limitar qué redes o equipos tienen acceso al servicio
portmap dado que no tiene una forma propia de autenticación.
Además, use solamente direcciones IP cuando limite el acceso al servicio. Evite usar nombres de
equipos, ya que pueden ser forjados por envenenamiento de DNS y otros métodos.
3.2.2.2. Proteja portmap con iptables
Para restringir aún más el acceso al servicio portmap, es una buena idea agregar reglas de iptables
al servidor y restringir el acceso a redes específicas.
Abajo hay dos ejemplos de comandos iptables. El primero permite conexiones TCP al puerto 111
(usado por el servicio portmap) desde la red 192.168.0.0/24. El segundo permite conexiones TCP al
mismo puerto localmente. Esto es necesario para el servicio sgi_fam usado por Nautilus. Todos los
demás paquetes son ignorados.
iptables -A INPUT -p tcp -s! 192.168.0.0/24 --dport 111 -j DROP
iptables -A INPUT -p tcp -s 127.0.0.1 --dport 111 -j ACCEPT
Para limitar el tráfico UDP de manera similar, use el siguiente comando.
iptables -A INPUT -p udp -s! 192.168.0.0/24
--dport 111 -j DROP
Nota
Diríjase a la Sección 3.8, “Cortafuegos” para obtener mayor información acerca de implementar
cortafuegos con comandos de iptables.
3.2.3. Asegurando NIS
El servicio de información de red (Network Information Service, NIS) es un servicio RPC, llamado
ypserv, el cual es usado en conjunto con portmap y otros servicios relacionados para distribuir
50
Asegurando NIS
mapas de nombres de usuario, contraseñas y otros tipos de información sensible dentro de su propio
dominio.
Un servidor NIS está compuesto por diversas aplicaciones. Entre ellas podemos encontrar:
• /usr/sbin/rpc.yppasswdd — También denominado servicio yppasswdd. Este demonio
permite que los usuarios modifiquen sus contraseñas NIS.
• /usr/sbin/rpc.ypxfrd — También denominado servicio ypxfrd. Este demonio es el
responsable de las transferencias de mapas NIS sobre la red.
• /usr/sbin/yppush — Esta aplicación se encarga de distribuir las bases de datos NIS que han
sido modificadas hacia diferentes servidores NIS.
• /usr/sbin/ypserv — Este es el demonio del servidor NIS.
NIS is somewhat insecure by today's standards. It has no host authentication mechanisms and
transmits all of its information over the network unencrypted, including password hashes. As a result,
extreme care must be taken when setting up a network that uses NIS. This is further complicated by
the fact that the default configuration of NIS is inherently insecure.
Se recomienda a todo aquel que tenga intenciones de implementar un servidor NIS, que primero
asegure el servicio portmap (como se puede observar en la Sección 3.2.2, “Asegurando Portmap”), y
que luego continúe con los siguientes eventos, como la planificación de la red.
3.2.3.1. Planeamiento cuidadoso de la red
Debido a que NIS transmite sin encriptar información clave a través de la red, es importante que el
servicio sea ejecutado detrás de un cortafuegos y sobre una porción de la red definida y considerada
segura. Existen riegos de intercepción cada vez que se transmite información NIS sobre una red que
no es segura. Un cuidadoso diseño de la red puede ayudar a prevenir importantes intrusiones en la
seguridad.
3.2.3.2. Utilización de nombres de dominio y de equipo NIS, de modo
similar a una contraseña
Cualquier máquina dentro de un dominio NIS puede usar comandos para extraer información desde el
servidor sin autenticación, siempre y cuando el usuario sepa el nombre de equipo del servidor NIS y
el nombre de dominio NIS.
Por ejemplo, si alguien conecta una laptop en la red, o si irrumpe en ella desde el exterior (y se las
ingenia para obtener una dirección IP interna), los siguientes comandos muestran el mapa de /etc/
passwd:
ypcat -d <NIS_domain> -h <DNS_hostname> passwd
Si el atacante es un usuario root, puede obtener el archivo /etc/shadow ingresando el siguiente
comando:
ypcat -d <NIS_domain> -h <DNS_hostname> shadow
51
Nota
Si se utiliza Kerberos, el archivo /etc/shadow no se encuentra almacenado dentro de un mapa
NIS.
Para hacer más complicado a los atacantes el acceso a los mapas NIS, genere una cadena aleatoria
para el nombre del equipo DNS, como por ejemplo o7hfawtgmhwg.domain.com. De manera
similar, genere aleatoriamente un nombre de dominio NIS distinto. Esto hace que para un atacante
sea mucho más dificil ingresar en el servidor NIS.
3.2.3.3. Editar el archivo /var/yp/securenets
Si el archivo /var/yp/securenets está vacío o no existe (como es el caso luego de una instalación
por defecto), NIS escucha a todos los puertos. Una de las primeras cosas a realizar es ingresar
pares máscara de red/red (netmask/network) en el archivo de modo que ypserv solo responda a las
peticiones de una red adecuada.
A continuación se muestra una entrada de ejemplo del archivo /var/yp/securenets:
255.255.255.0
192.168.0.0
Advertencia
Nunca inicie un servidor NIS por vez primera sin haber antes creado el archivo /var/yp/
securenets.
Esta técnica no ofrece protección contra ataques de simulación de identidad, pero al menos establece
límites sobre las redes en las que el servidor NIS está funcionando.
3.2.3.4. Asigne puertos estáticos y utilice reglas de iptables
A todos los servidores relacionados con NIS se les puede asignar un puerto específico, excepto
rpc.yppasswdd — el demonio que permite a los usuarios modificar sus contraseñas de logueo.
Asignar puertos a rpc.ypxfrd y ypserv, los restantes demonios de servidores NIS, permite la
creación de reglas de cortafuegos, y de esta manera poder proteger a los demonios de futuras
intrusiones.
Para hacerlo, agregue las siguientes líneas en /etc/sysconfig/network:
YPSERV_ARGS="-p 834" YPXFRD_ARGS="-p 835"
Las siguientes reglas iptables pueden ser utilizadas para fortalecer la red que el servidor está
escuchando con estos puertos:
iptables -A INPUT -p ALL -s! 192.168.0.0/24
iptables -A INPUT -p ALL -s! 192.168.0.0/24
52
--dport 834 -j DROP
--dport 835 -j DROP
Asegurando NFS
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 3.8, “Cortafuegos” para obtener mayor información acerca de implementar
cortafuegos con comandos de iptables.
3.2.3.5. Use autenticación con Kerberos
Uno de los problemas a ser considerados si se utiliza NIS para una autenticación, es que cada vez
que un usuario ingresa en una máquina, se envía un hash del mapa /etc/shadow por la red. Si un
intruso obtiene acceso a un dominio NIS y observa el tráfico en la red, puede recolectar los hashes
de nombres de usuarios y contraseñas. Con el tiempo suficiente, un programa de descifrado de
contraseñas puede adivinar aquellas que son débiles, y el atacante puede obtener acceso a una
cuenta válida en esa red.
Debido a que Kerberos utiliza 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 3.7, “Kerberos”.
3.2.4. Asegurando NFS
Importante
La versión de NFS incluida en Fedora, NFSv4, ya no necesita el servicio portmap como se lo
indica en la Sección 3.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.
3.2.4.1. Planeamiento cuidadoso de la red
Ahora que NFSv4 tiene la capacidad de enviar toda la información en la red encriptada utilizando
Kerberos, es importante que el servicio sea configurado correctamente, si es que se encuentra detrás
de un cortafuegos o en una red segmentada. Todavía NFSv3 envía los datos de manera no segura, y
esto debería ser tendido en cuenta. Un diseño de redes que preste atención a todos estos aspectos
puede prevenir fallas en la seguridad.
3.2.4.2. Cuidado con los errores de sintaxis
El servidor NFS determina qué sistemas de archivos exportar y hacia qué equipos hacerlo al consultar
el archivo /etc/exports. Tenga cuidado de no agregar espacios extraños cuando edite este
archivo.
Por ejemplo, la siguiente línea en el archivo /etc/exports comparte el directorio /tmp/nfs/ con el
equipo juan.ejemplo.com con permisos de lectura y escritura.
53
/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.
/tmp/nfs/
bob.example.com (rw)
Es una buena costumbre la de confirmar cualquier configuración de elementos compartidos NFS,
utilizar para ello el comando showmount y verificar qué es lo que está siendo compartido:
showmount -e <hostname>
3.2.4.3. No utilice la opción no_root_squash
Por defecto, al utilizarse para compartir elementos, NFS cambia el usuario root al usuario
nfsnobody, una cuenta de usuario sin privilegios. Esto modifica la pertenencia de todos los archivos
creados por el usuario root, y se los otorga a nfsnobody, evitando de esta forma la carga de
programas definidos con bit de tipo setuid.
Si se utiliza no_root_squash, los usuarios root remotos tienen la posibilidad de modificar cualquier
archivo en el sistema de archivos compartido, y dejar aplicaciones infectadas con troyanos para que
otros usuarios las ejecuten sin saberlo.
3.2.4.4. Configuración del cortafuego de NFS
Los puertos utilizados por NFS están dinámicamente asignados por rpcbind, y esto puede causar
problemas en el momento de crear reglas de cortafuegos. Para simplificar este proceso, utilice el
archivo /etc/sysconfig/nfs para especificar qué puertos deben ser utilizados:
• MOUNTD_PORT — puerto TCP y UDP para mountd (rpc.mountd)
• STATD_PORT — puerto TCP y UDP para status (rpc.statd)
• LOCKD_TCPPORT — puerto TCP para nlockmgr (rpc.lockd)
• LOCKD_UDPPORT — UDP port nlockmgr (rpc.lockd)
Los números de puerto especificados no deben ser utilizados por ningún otro servicio. Configure su
cortafuegos para permitir los números de puerto especificados, del mismo modo que el puerto TCP y
UDP 2049 (NFS).
Ejecute el comando rpcinfo -p sobre el servidor NFS para conocer qué programas RPC y qué
puertos están siendo utilizados.
3.2.5. Asegurando el servidor HTTP Apache
El servidor HTTP Apache es uno de los servicios más seguros y estables que son empaquetados con
Fedora. Una extensa variedad de opciones y técnicas están disponibles para asegurar el servidor
HTTP Apache — demasiado numerosas para analizarlas en profundidad aquí. La sección siguiente
explica brevemente algunas buenas costumbres al ejecutar el servidor HTTP Apache.
Siempre verifique que funcione correctamente cualquier programa que tenga intención de utilizar en el
sistema antes de ponerlo en producción. Además, asegúrese que solo el usuario root tenga permisos
54
Asegurando FTP
de escritura sobre cualquier directorio que contenga programas o CGIs. Para hacer esto, ejecute los
siguientes comandos como usuario root:
1.
2.
chown root <directory_name>
chmod 755 <directory_name>
Los administradores de sistemas deben ser cuidadosos al utilizar las siguientes opciones de
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.
3.2.6. Asegurando FTP
El Protocolo de Transferencia de Archivos (FTP, por las iniciales en inglés de File Transfer Protocol),
es un viejo protocolo TCP diseñado para transferir archivos sobre una red. Puesto que todas las
transacciones con el servidor no son encriptadas, incluyendo las autenticaciones de usuario, es
considerado un protocolo no seguro y debería ser configurado cuidadosamente.
Fedora provee tres servidores FTP.
• gssftpd — Un demonio basado 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.
55
• vsftpd — Una implementación orientada a la seguridad del servicio FTP.
Los siguientes lineamientos de seguridad sirven para configurar el servicio FTP vsftpd.
3.2.6.1. Mensaje de bienvenida de FTP
Antes de enviar un nombre de usuario y una contraseña, todos los usuarios son recibidos con una
imagen de bienvenida. Por defecto, esta imagen incluye la información de la versión que se está
utilizando, información que sirve a los atacantes para poder identificar debilidades en el sistema.
Para modificar la imagen de bienvenida para vsftpd, agregue la siguiente directiva en el archivo /
etc/vsftpd/vsftpd.conf:
ftpd_banner=<insert_greeting_here>
Reemplace <insert_greeting_here> en la directriz de arriba con el texto del mensaje de
bienvenida.
Para imágenes con varias líneas, lo mejor es utilizar un archivo de imagen. Para simplificar la
administración de múltiples imágenes, coloquelas a todas ellas en un nuevo directorio llamado /etc/
banners/. En nuestro ejemplo, el archivo de imagen para conexiones FTP es /etc/banners/
ftp.msg. A continuación se puede observar cómo puede llegar a lucir un archivo con esstas
características:
######### # Hello, all activity on ftp.example.com is logged. #########
Nota
No es necesario empezar cada línea del archivo con 220, como se lo indica en la
Sección 3.2.1.1.1, “Encapsuladores TCP y pancartas de conexión”.
Para tener una referencia de esta imagen de bienvenida en vsftpd, añada la siguiente directiva en el
archivo /etc/vsftpd/vsftpd.conf:
banner_file=/etc/banners/ftp.msg
También es posible enviar imágenes adicionales a conexiones entrantes utilizando encapsuladores
TCP como se explica en la Sección 3.2.1.1.1, “Encapsuladores TCP y pancartas de conexión”.
3.2.6.2. Acceso anónimo
La presencia del directorio /var/ftp/ activa la cuenta anónima.
La forma más sencilla de crear este directorio es instalando el paquete vsftpd. Este paquete
establece un árbol de directorios para usuarios anónimos y configura los permisos de manera tal que
estos usuarios sólo puedan leer sus contenidos.
Por defecto, el usuario anónimo no puede escribir en ningún directorio.
56
Asegurando FTP
Advertencia
Si se habilita la posibilidad de acceso anónimo a un servidor FTP, tenga cuidado de donde
almacenar los datos importantes.
3.2.6.2.1. Subida anónima
Para permitir que los usuarios anónimos suban archivos, es recomendable la creación de un
directorio dentro de /var/ftp/pub/, con permisos de escritura solamente.
Para hacerlo, ingrese el siguiente comando:
mkdir /var/ftp/pub/upload
A continuación, modifique los permisos de modo que los usuarios anónimos no puedan conocer el
contenido del directorio:
chmod 730 /var/ftp/pub/upload
Un listado de manera extendida del directorio, debería ser semejante a esto:
drwx-wx---
2 root
ftp
4096 Feb 13 20:05 upload
Advertencia
Los administradores que permiten que usuarios anónimos sean capaces de leer y de escribir
sobre los directorios, a menudo se encuentran con que sus servidores se han convertido en
repositorios de software robado.
Adicionalmente, bajo vsftpd, añada la siguiente línea en el archivo /etc/vsftpd/vsftpd.conf:
anon_upload_enable=YES
3.2.6.3. Cuentas de usuario
Debido a que FTP transmite para su autenticación nombres de usuario y contraseñas sin encriptarse
sobre redes no seguras, es una buena idea la de negar a los usuarios del sistema el acceso al
servidor desde sus cuentas de usuario.
Para deshabilitar todas las cuentas de usuario en vsftpd, agregue la siguiente directiva en /etc/
vsftpd/vsftpd.conf:
local_enable=NO
57
3.2.6.3.1. Restringiendo cuentas de usuario
Para deshabilitar acceso FTP para una cuenta específica, o un grupo de cuentas específico, como
ser por ejemplo el usuario root y todos aquellos con privilegios sudo, la manera más sencilla de
hacerlo es utilizar un archivo de lista PAM como se explica en la Sección 3.1.4.2.4, “Deshabilitando
root usando PAM”. El archivo de configuración PAM para vsftpd es /etc/pam.d/vsftpd.
También es posible deshabilitar cuentas de usuario directamente dentro de cada servicio.
Para deshabilitar cuentas de usuario específicas en vsftpd, agregue el nombre del usuario en /
etc/vsftpd.ftpusers
3.2.6.4. Utilice encapsuladores TCP para el control de acceso
Utilice encapsuladores TCP para controlar el acceso al demonio FTP como se indica en la
Sección 3.2.1.1, “Mejorando la seguridad utilizando encapsuladores TCP”.
3.2.7. Asegurando Sendmail
Sendmail es un agente de transferencia de correos (MTA, por las iniciales en inglés de Mail Transfer
Agent), que utiliza protocolo simple de transferencia de correo (SMTP, Simple Mail Transfer Protocol)
para enviar mensajes electrónicos entre otros MTAs, o hacia otros clientes de correo, o agentes de
entrega. Si bien muchos MTAs son capaces de encriptar el tráfico entre uno y otro, algunos no lo
hacen, de modo que enviar correos electrónicos en una red pública es considerado una forma de
comunicación no segura.
Es recomendable que todos aquellos que estén planeando implementar un servidor Sendmail, tengan
en cuenta los siguientes inconvenientes.
3.2.7.1. Limitar un ataque de denegación de servicio
Debido a la naturaleza del correo electrónico, un atacante determinado puede inundar de manera
relativamente sencilla el servidor con correos, y provocar la denegación del servicio. Al establecer
límites a las siguientes directivas en /etc/mail/sendmail.mc, la efectividad de ataques de ese
tipo se ve disminuida.
• confCONNECTION_RATE_THROTTLE — El número de conexiones que el servidor puede recibir
por segundo. Por defecto, Sendmail no limita el número de conexiones. Si se alcanza un límite
previamente establecido, las siguientes conexiones son demoradas.
• confMAX_DAEMON_CHILDREN — El máximo número de procesos hijo que pueden ser generados
por el servidor. Por defecto, Sedmail no atribuye un límite a la cantidad de estos procesos. Si se
alcanza un límite previamente establecido, las siguientes conexiones serán demoradas.
• confMIN_FREE_BLOCKS — El número mínimo de bloques libres que deben estar disponibles para
que el servidor acepte correos. La cantidad establecida por defecto es de 100 bloques.
• confMAX_HEADERS_LENGTH — El tamaño máximo aceptable (en bytes) para un encabezado de
mensaje.
• confMAX_MESSAGE_SIZE — El tamaño máximo aceptable (en bytes) para un solo mensaje.
3.2.7.2. NFS y Sendmail
Nunca coloque el directorio mail spool, /var/spool/mail/, en un volumen NFS compartido.
Debido a que NFSv2 y NFSv3 no mantienen control sobre los IDs de usuario y grupo, dos o más
usuarios pueden tener el mismo UID y recibir y leer los correos de los otros.
58
Verificar qué puertos están abiertos
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.
3.2.7.3. Usuarios de sólo correo
Para ayudar a prevenir que explote a los usuarios locales para usar el servidor Sendmail, lo mejor es
que solamente ingresen al servidor Sendmail usando un cliente de correos electrónicos. Las cuentas
de consola en el servidor de correo no deberían ser permitidas y todos los usuarios de consola en
el archivo /etc/passwd deberían definirse como /sbin/nologin (con la posible excepción del
usuario root).
3.2.8. Verificar qué puertos están abiertos
After configuring network services, it is important to pay attention to which ports are actually listening
on the system's network interfaces. Any open ports can be evidence of an intrusion.
Existen dos maneras fundamentales para listar los puertos que están abiertos en la red. La menos
confiable consiste en consultar los paquetes en la red utilizando comandos como netstat -an
o lsof -i. Este método es menos confiable debido a que estos programas no se conectan a la
máquina desde la red, sino que verifican qué es lo que se está ejecutando en el sistema. Por esta
razón, estas aplicaciones frecuentemente son reemplazadas por atacantes. Alguien que quiera
ocultar el rastro que está dejando al ingresar, o al abrir sin autorización los puertos de un sistema,
intentará reemplazar netstat y lsof, con sus versiones personales y modificadas.
Una forma más confiable de verificar los puertos que están escuchando en una red, es mediante la
utilización de un escáner de puertos como nmap.
El siguiente comando ejecutado desde una terminal, especifica los puertos que se encuentran
abiertos a conexiones TCP desde la red:
nmap -sT -O localhost
La salida de este comando es la siguiente:
Starting Nmap 4.68 ( http://nmap.org ) at 2009-03-06 12:08 EST
Interesting ports on localhost.localdomain (127.0.0.1):
Not shown: 1711 closed ports
PORT
STATE SERVICE
22/tcp
open ssh
25/tcp
open smtp
111/tcp
open rpcbind
113/tcp
open auth
631/tcp
open ipp
834/tcp
open unknown
2601/tcp open zebra
32774/tcp open sometimes-rpc11
Device type: general purpose
Running: Linux 2.6.X
OS details: Linux 2.6.17 - 2.6.24
Uptime: 4.122 days (since Mon Mar 2 09:12:31 2009)
59
Network Distance: 0 hops
OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 1.420 seconds
Esta salida muestra que el sistema está ejecutando portmap debido a la presencia del servicio
sunrpc. Sin embargo, existe además un servicio misterioso en el puerto 834. Para verificar si el
puerto está asociado con la lista oficial de servicios conocidos, ingrese:
cat /etc/services | grep 834
Este comando no devuelve ninguna información. Lo que está indicando es que si bien el puerto se
encuentra dentro del rango reservado (es decir, entre 0 y 1023), y que no necesita privilegios de
usuario root para abrirse, sin embargo no está asociado con ningún servicio conocido.
A continuación, verifique si existe información acerca del puerto utilizando netstat o lsof. Para
verificar el puerto 834 utilizando netstat, ingrese el siguiente comando:
netstat -anp | grep 834
El comando devuelve la siguiente salida:
tcp
0
0 0.0.0.0:834
0.0.0.0:*
LISTEN
653/ypbind
La presencia de un puerto abierto en netstat es un reaseguro, ya que si un atacante ha abierto
un puerto en un sistema en el que no está autorizado a ingresar, seguramente no permitirá que sea
detectada su presencia mediante este comando. Además, la opción [p] revela el proceso ID (PID)
del servicio que ha abierto el puerto. En este caso, el puerto abierto pertenece a ypbind (NIS), que
es un servicio RPC administrado conjuntamente con el servicio portmap.
El comando lsof muestra información similar a netstat, ya que también es capaz de enlazar
puertos con servicios:
lsof -i | grep 834
La sección que nos interesa de la salida de este comando es la siguiente:
ypbind
ypbind
ypbind
ypbind
653
655
656
657
0
0
0
0
7u
7u
7u
7u
IPv4
IPv4
IPv4
IPv4
1319
1319
1319
1319
TCP
TCP
TCP
TCP
*:834
*:834
*:834
*:834
(LISTEN)
(LISTEN)
(LISTEN)
(LISTEN)
Estas herramientas nos dicen mucho acerca del estado en que se encuentran los servicios en
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.
3.3. Single Sign-on (SSO)
3.3.1. Introducción
Si es necesario, ingrese la contraseña de usuario root de su equipo.
60
Introducción
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.
3.3.1.1. Aplicaciones soportadas
Las siguientes aplicaciones están actualmente soportadas por el esquema de registro unificado en
Fedora:
• Entrada
• Salvapantallas
• Firefox y Thunderbird
3.3.1.2. Mecanismos de autenticación soportados
Actualmente Fedora tiene soporte para los siguientes mecanismos de autenticación:
• Ingreso de nombre/contraseña Kerberos
• Ingreso por Tarjeta Inteligente/PIN
3.3.1.3. Tarjetas Inteligentes soportadas
Fedora ha sido probada con una tarjeta y un lector Cyberflex e-gate, pero cualquier tarjeta que
cumpla tanto con las especificaciones de tarjetas Java 2.1.1, y las especificaciones Global Platform
2.0.1, debería poder funcionar correctamente, del mismo modo que cualquier lector que sea
soportado por PCSC-lite.
Fedora también ha sido probada con tarjetas de acceso común (CAC, por las iniciales en inglés de
Common Access Cards). El lector soportado para CAC es el lector USB SCM SCR 331.
En cuanto a Fedora 5.2, ya tienen soporte las tarjetas inteligentes Gemalto (Cyberflex Access 64k
v2, standard con valor DER SHA1 configurado del mismo modo que en PKCSI v2.1). Estas tarjetas
ahora utilizan lectores compatibles con dispositivos de interfaces de tarjetas (CCID, por las iniciales
en inglés de Smart Card Interface Devices) de tipo Chip/Smart.
3.3.1.4. Ventajas de SSO en Fedora
Numerosos mecanismos de seguridad existentes hoy en día utilizan una gran cantidad de protocolos
y credenciales. Algunos ejemplos de ellos son SSL, SSH, IPsec y Kerberos. La idea de SSO en
Fedora es la de unificar estos esquemas para dar soporte a los requerimientos mencionados
recién. Esto no significa que haya que reemplazar Kerberos con certificados X.509x3, sino que se
unifican para poder reducir el peso que tienen que soportar tanto los usuarios del sistema, como sus
administradores.
Fedora, para cumplir este objetivo:
• Ofrece una sola instancia compartida de las bibliotecas de encriptación NSS en cada sistema
operativo.
• Ships the Certificate System's Enterprise Security Client (ESC) with the base operating system. The
ESC application monitors smart card insertion events. If it detects that the user has inserted a smart
card that was designed to be used with the Fedora Certificate System server product, it displays a
user interface instructing the user how to enroll that smart card.
61
• 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.)
3.3.2. Empezar a utilizar su nueva tarjeta inteligente
Antes de poder utilizar una tarjeta inteligente en sus sistema, y poder aprovechar las grandes ventajas
en las opciones de seguridad que esta tecnología ofrece, necesita realizar en un determinado orden
algunas instalaciones mínimas. Más abajo se explica en qué consisten.
Nota
Esta sección ofrece una explicación general para poder empezar a utilizar su tarjeta inteligente.
Información más específica puede encontrarse en la Guía del Cliente del Cliente de Seguridad
Empresarial del Sistema de Certificado de Red Hat.
1.
Ingrese con su nombre de usuario y contraseña Kerberos.
2.
Asegúrese de tener instalado el paquete nss-tools.
3.
Descargue e instale sus certificados corporativos específicos de usuario root. Utilice el siguiente
comando para instalar el certificado root CA:
certutil -A -d /etc/pki/nssdb -n "root ca cert" -t "CT,C,C" -i ./
ca_cert_in_base64_format.crt
4.
Verifique que tenga los siguientes RPMs instalados en su sistema: esc, pam_pkcs11, coolkey, ifdegate, ccid, gdm, authconfig, and authconfig-gtk.
5.
Habilite el soporte de ingreso por Tarjeta Inteligente.
a.
On the Gnome Title Bar, select System->Administration->Authentication.
b.
Type your machine's root password if necessary.
c.
En el diálogo de configuración de autenticación, haga clic sobre la pestaña Autenticación.
d.
Tilde la casilla Activar soporte para tarjeta inteligente.
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:
• Bloquear — Si se retira la tarjeta se bloquea la pantalla X.
• Ignorar — No sucede nada cuando se retira la tarjeta.
62
Como funciona la inscripción de las tarjetas inteligentes.
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;
Modifique su valor a "true", del siguiente modo:
enable_ocsp = true;
7.
Enrole su tarjeta inteligente.
8.
Si además está utilizando una tarjeta CAC, tendrá que realizar los siguientes pasos:
a.
Conviértase en usuario root y genere un archivo llamado /etc/pam_pkcs11/cn_map.
b.
Añada la siguiente entrada al archivo cn_map:
MY.CAC_CN.123454 -> myloginid
donde MY.CAC_CN.123454 es el nombre común en su CAC y myloginid es su ID de
logueo UNIX.
9.
Salida
3.3.2.1. Solución de problemas
Si se encuentra con algún inconveniente para lograr que su tarjeta inteligente funcione, intente utilizar
el siguiente comando para ubicar el origen del problema.
depurador pklogin_finder
Si ejecuta la herramienta pklogin_finder en modo de depuración, mientras una tarjeta inteligente
registrada se encuentre conectada, intentará mostrar información acerca de los certificados válidos, y
si tiene éxito, intentará mapear un ID de registro desde los certificados que existan en la tarjeta.
3.3.3. Como funciona la inscripción de las tarjetas inteligentes.
Las tarjetas inteligentes se dice que son inscriptas cuando han recibido un certificado adecuado
identificado con un Certificado de Autoridad válido (CA, por las iniciales en inglés de Certificate
Authority). Esto implica una serie de pasos, que se describen a continuación:
1. El usuario inserta su tarjeta inteligente en el lector de tarjetas de su estación de trabajo. Este
evento es reconocido por el Cliente de Seguridad Corporativo (ESC, por las iniciales en inglés de
Entreprise Security Client).
2. The enrollment page is displayed on the user's desktop. The user completes the required details
and the user's system then connects to the Token Processing System (TPS) and the CA.
3. El TPS inscribe a la tarjeta inteligente utilizando un certificado firmado por CA.
63
Figura 3.4. Como funciona la inscripción de las tarjetas inteligentes.
3.3.4. Cómo funciona el ingreso con tarjeta inteligente
En la siguiente sección se ofrece una breve descripción general del proceso de registro utilizando una
tarjeta inteligente.
1. When the user inserts their smart card into the smart card reader, this event is recognized by the
PAM facility, which prompts for the user's PIN.
2. The system then looks up the user's current certificates and verifies their validity. The certificate is
then mapped to the user's UID.
3. Esto es validado en el KDC (centro de distribución de claves de Kerberos) y el registro es
autorizado.
64
Configurar Firefox para la utilización de Kerberos como SSO
Figura 3.5. Cómo funciona el ingreso con tarjeta inteligente
Nota
No puede registrarse con una tarjeta que no haya sido inscripta, ni siquiera aunque haya sido
formateada. Necesita registrarse con una tarjeta formateada e inscripta, o no utilizar ninguna que
no haya sido inscripta.
Para obtener mayor información acerca de Kerberos y PAM, vea la Sección 3.7, “Kerberos” y
Sección 3.5, “Módulos de autenticación conectables (PAM, por las iniciales en inglés de Pluggable
Authentication Modules)”.
3.3.5. Configurar Firefox para la utilización de Kerberos como SSO
Puede configurar Firefox para utilizar Kerberos para la identificación única SSO. Para que esta
herramienta pueda funcionar correctamente, necesita configurar su navegador web para que pueda
enviar sus credenciales Kerberos al KDC adecuado. En la siguiente sección se describen las
modificaciones a realizar en la configuración, y otros requerimientos necesarios para poder utilizar
correctamente esta funcionalidad.
1. En la barra de direcciones de Firefox, escriba about:config para ver una lista actualizada de
las opciones de configuración disponibles.
2. En el campo Filtro, ingrese negotiate para restringir la lista de opciones.
65
3. Haga un doble clic en la entrada network.negotiate-auth.trusted-uris para mostrar el cuadro de
diálogo Ingrese valor de cadena.
4. Ingrese el nombre del dominio en el cual desea autenticarse, por ejemplo, .ejemplo.com.
5. Repita el procedimiento recién descrito para la entrada network.negotiate-auth.delegation-uris,
utilizando el mismo dominio.
Nota
Puede dejar este valor vacío, ya que permite a Kerberos enviar tickets, lo que no es
necesario.
Si no puede ver estas dos opciones de configuración listadas, tal vez la versión de Firefox
que está utilizando sea demasiado antigua para soportar negociados de autenticación, y
debería considerar actualizarla.
Figura 3.6. Configurar Firefox para SSO con Kerberos
Necesita asegurarse de poseer tickets Kerberos. En una terminal, ingrese kinit para obtenerlos.
Para mostrar la lista de los tickets disponibles, ingrese klist. A continuación se muestra un ejemplo
del resultado de estos comandos:
[user@host ~] $ kinit
Password for [email protected]:
[user@host ~] $ klist
Ticket cache: FILE:/tmp/krb5cc_10920
Default principal: [email protected]
Valid starting
Expires
Service principal
10/26/06 23:47:54 10/27/06 09:47:54 krbtgt/[email protected]
renew until 10/26/06 23:47:54
Kerberos 4 ticket cache: /tmp/tkt10920
66
Yubikey
klist: You have no tickets cached
3.3.5.1. Solución de problemas
Si ha seguido las etapas de configuración recién indicadas, y la negociación de la autenticación
no funciona, puede activar la posibilidad de obtener información más detallada del proceso de
autenticación. Esto podría ayudarle a encontrar la causa del problema. Para obtener más detalles del
proceso de autenticación, utilice el siguiente procedimiento:
1. Cerrar todas las instancias de Firefox.
2. Abra una terminal, e ingrese los siguientes comandos:
export NSPR_LOG_MODULES=negotiateauth:5
export NSPR_LOG_FILE=/tmp/moz.log
3. Reinicie Firefox desde esa terminal, y visite el sitio web al que no podía autenticarse
anteriormente. La información será registrada en /tmp/moz.log, y podría darle alguna pista
hacerca del problema. Por ejemplo:
-1208550944[90039d0]: entering nsNegotiateAuth::GetNextToken()
-1208550944[90039d0]: gss_init_sec_context() failed: Miscellaneous failure
No credentials cache found
Esto significa que usted no tiene tickets Kerberos, y que necesita ejecutar el 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:
-1208994096[8d683d8]: entering nsAuthGSSAPI::GetNextToken()
-1208994096[8d683d8]: gss_init_sec_context() failed: Miscellaneous failure
Server not found in Kerberos database
Generalmente esto significa que existe un problema de configuración de Kerberos. Asegúrese
de tener las entradas correctas en la sección [domain_realm] del archivo /etc/krb5.conf. Por
ejemplo:
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
Si no aparece nada en el archivo de registro, es posible que usted se encuentre detrás de un proxy,
y que ese proxy esté eliminando los encabezados HTTP necesarios para negociar la autenticación.
Una posible solución a esto es intentar conectarse al servidor utilizando HTTPS, que permite a las
peticiones atravesar el proxy sin modificarlas. Luego proceda a depurar utilizando el archivo de
registro, como se ha explicado antes.
3.4. Yubikey
Yubikey is a hardware authentication token that utilizes open source software to operate. This token
is a simple USB device that appears as a keyboard to your computer. The single touch button on the
token provides a one time password (OTP) with each push that can be used to authenticate a user.
Currently there are several different implementations of this solution of which we'll cover here.
67
3.4.1. Using Yubikey with a centralized server
A PAM module already exists in the Fedora repositories that allow authentication of computers
that can contact an authentication server. The server can either be setup at the domain level or the
Yubico's servers can be utilized. This method of authentication is a great enterprise solution where
multiple users may need access to multiple computers on the domain. The steps below describe this
setup.
1.
Install pam_yubico
2.
For two factor authentication open /etc/pam.d/gdm-password and locate the following line:
auth substack password-auth
In a new line after this add:
auth sufficient pam_yubico.so id=16
3.
To simple use the yubikey token without your password remove the first line from the step above
and replace it with the second.
4.
Locate the yubikey token for the first yubikey you will be adding. This can be done by looking at
the first 12 characters of any OTP or visit http://radius.yubico.com/demo/Modhex_Calculator.php
and copy the Modhex encoded string after you enter an OTP into the textbox on the page.
5.
Add user's yubikeys to the config file. This can be done either globally in /etc/
yubikey_mapping or by individual user in ~/.yubico/authorized_yubikeys. The following
is the syntax:
username:yubikey_token:another_yubikey_token
6.
Logout, when you attempt to log back in you should either be prompted to enter both your
password and your yubikey OTP or both depending on how you configured your system.
Nota
A connection to the authentication server is required or proper authentication will not occur. This
can be detrimental to systems that do not have constant network connectivity.
3.4.2. Authenticating to websites with your Yubikey
While outside the scope of this guide Yubikey allows you to authenticate to websites supporting this
authentication method. These websites typically support Yubico's authentication servers but some can
be setup similar to the above centralized authentication. Yubico also provides OpenID services that
can be utilized with certain websites.
3.5. Módulos de autenticación conectables (PAM, por las
iniciales en inglés de Pluggable Authentication Modules)
Programs that grant users access to a system use authentication to verify each other's identity (that is,
to establish that a user is who they say they are).
Históricamente, cada programa tenía su propia forma de autenticar los usuarios. En Fedora, muchos
programas se configuran para utilizar un mecanismo de autenticación centralizado denominado
68
Ventajas de PAM
Módulos de Autenticación Conectables (PAM, por las iniciales en inglés de Pluggable Authentication
Modules).
PAM usa una arquitectura modular, con complementos, que le da al administrador del sistema un
buen grado de flexibilidad en la 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 3.5.3, “Formato del archivo de configuración de PAM”.
3.5.1. Ventajas de PAM
PAM ofrece las siguientes ventajas;
• un esquema de autenticación común que se puede usar en una amplia variedad de aplicaciones.
• flexibilidad significativa y control sobre la autenticación para administradores del sistema y
desarrolladores de aplicaciones.
• una única biblioteca bien documentada que permite a los desarrolladores escribir programas sin
tener que crear sus propios esquemas de autenticación.
3.5.2. Archivos de configuración de PAM
El directorio /etc/pam.d/ contiene los archivos de configuración de PAM para cada aplicación que
utilice PAM. En versiones anteriores de PAM, se usaba el archivo /etc/pam.conf, pero este archivo
se dejado de usar y sólo se utilizará si el directorio /etc/pam.d/ no existe.
3.5.2.1. Archivos del servicio PAM
Cada aplicación con capacidades PAM o servicio tiene un archivo en el directorio /etc/pam.d/.
Cada archivo en este directorio tiene el mismo nombre del servicio al que controla el acceso.
El programa que usa PAM es responsable por definir su nombre de servicio e instalar su propio
archivo de configuración PAM en el directorio /etc/pam.d/. Por ejemplo, el programa login define
su nombre de servicio como login e instala el archivo de configuración PAM /etc/pam.d/login.
3.5.3. Formato del archivo de configuración de PAM
Cada archivo de configuración PAM contiene un grupo de directivas formateadas como sigue:
<module interface>
<control flag>
<module name>
<module arguments>
Cada uno de estos elementos se explica en las secciones siguientes.
3.5.3.1. Interfaz del Módulo
Hay disponibles cuatro tipos de interfases de módulos PAM. Cada uno corresponde a distintos
aspectos del proceso de autorización:
• auth — Esta interfaz de módulo autentica el uso. Por ejemplo, pide y verifica la validez de una
contraseña. Los módulos con esta interfaz también pueden poner credenciales, como membresías
de grupo o tickets Kerberos.
69
• 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 — This module interface configures and manages user sessions. Modules with this
interface can also perform additional tasks that are needed to allow access, like mounting a user's
home directory and making the user's mailbox available.
Nota
Un módulo individual puede proveer cualquiera o todas las interfases de módulo. Por ejemplo
pam_unix.so provee las cuatro interfaces de módulo.
En un archivo de configuración PAM, la interfaz de módulo es el primer campo definido. Por ejemplo,
una línea típica en una configuración puede verse como sigue:
auth required pam_unix.so
This instructs PAM to use the pam_unix.so module's auth interface.
3.5.3.1.1. Interfases de módulos apilables
Module interface directives can be stacked, or placed upon one another, so that multiple modules are
used together for one purpose. If a module's control flag uses the "sufficient" or "requisite" value (refer
to Sección 3.5.3.2, “Bandera de control” for more information on these flags), then the order in which
the modules are listed is important to the authentication process.
El apilado hace fácil para un administrador pedir que se den ciertas condiciones específicas antes
de permitir al usuario autenticar. Por ejemplo, el comando reboot normalmente usa varios módulos
apilados, como se ve en su archivo de configuración PAM:
[root@MyServer ~]# cat /etc/pam.d/reboot
#%PAM-1.0
auth sufficient pam_rootok.so
auth required pam_console.so
#auth include system-auth
account required pam_permit.so
• La primera línea es un comentario y no se procesa.
• auth sufficient pam_rootok.so — Esta línea usa el módulo pam_rootok.so para
verificaar si el usuario actual es root, confirmandoo que su UID sea 0. Si esto tiene éxito, no se
consulta ningún otro módulo y el comando se ejecuta. Si esto falla, se consulta el módulo siguiente.
• auth required pam_console.so — Esta línea utiliza el módulo pam_console.so
para intentar autenticar al usuario. Si este usuario ya se encuentra dentro de la consola,
pam_console.so verifica si dentro del directorio /etc/security/console.apps/ hay un
archivo con el mismo nombre que el del servicio (reboot). Si existe ese archivo, la autenticación es
existosa y el control es pasado al siguiente módulo.
• #auth include system-auth — Esta línea es comentada y no se procesa.
70
Formato del archivo de configuración de PAM
• account required pam_permit.so — Esta línea usa el módulo pam_permit.so para
permitir al usuario root o cualquier otro que haya ingresado en la consola reiniciar el sistema.
3.5.3.2. Bandera de control
Todos los módulos PAM generan un resultado de éxito o fracaso cuando son llamados. Las banderas
de control le dicen a PAM qué hacer con el resultado. Los módulos se pueden apilar en un orden
particular, y las banderas de control determinan cuán importante es el éxito o el fracaso de un módulo
particular para el objetivo general de autenticación del usuario con el servicio.
Hay cuatro banderas de control predefinidas:
• required — El resultado del módulo debe ser exitoso para que pueda continuar la autenticación.
Si la prueba falla en este punto, el usuario no se notifica hasta que se completan con los resultados
de todas las pruebas de los módulos que referencian a esa interfaz.
• requisite — El resultado del módulo debe ser exitoso para que continúe la autenticación. Sin
embargo, si una prueba falla en este punto, el usuario se notifica inmediatamente con un mensaje
que muestra el primer fallo del módulo required o requisite.
• sufficient — El resultado del módulo es ignorado si falla. Sin embargo, si el resultado de
un módulo marcado con bandera sufficient tiene éxito y no hay módulos previos marcados
con required que hayan fallado, entonces no se necesitan otros resultados y el usuario es
autenticado con el servicio.
• optional — El resultado del 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.
The pam.d man page, and the PAM documentation, located in the /usr/share/doc/
pam-<version-number>/ directory, where <version-number> is the version number for PAM on
your system, describe this newer syntax in detail.
3.5.3.3. Nombre de módulo
El nombre del módulo ofrece a PAM el nombre del módulo conectable que contiene la interfaz del
módulo especificada. En versiones anteriores de Fedora la dirección completa al módulo era provista
en el archivo de configuración de PAM. Sin embargo, desde la aparición de los sistemas multilib, que
almacenan modulos PAM de 64 bits en el directorio /lib64/security/, el nombre del directorio es
omitido dado que la aplicación está enlazada con la versión correcta de libpam, que puede encontrar
la versión correcta del módulo.
71
3.5.3.4. Argumentos del módulo
Para algunos módulos, PAM utiliza argumentos para pasar información a un módulo conectable
durante la autenticación.
Por ejemplo, el módulo pam_userdb.so utiliza información almacenada en un archivo de base de
datos Berkeley para autenticar al usuario. Berkeley es una base de datos de código abierto que se
encuentra en muchas otras aplicaciones. El módulo toma un argumento db de modo que Berkeley
sepa qué base de datos utilizar para el servicio solicitado.
The following is a typical pam_userdb.so line in a PAM configuration. The <path-to-file> is the
full path to the Berkeley DB database file:
auth required pam_userdb.so db=<path-to-file>
Los argumentos 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.
3.5.4. Ejemplos de archivos de configuración de PAM
La siguiente es una muestra del archivo de configuración PAM de una aplicación:
#%PAM-1.0
auth required pam_securetty.so
auth required pam_unix.so nullok
auth required pam_nologin.so
account required pam_unix.so
password required pam_cracklib.so retry=3
password required pam_unix.so shadow nullok use_authtok
session required pam_unix.so
• La primera línea es un comentario, indicado por el numeral (#) al comienzo de la línea.
• Las líneas 2 a la 4 apila tres módulos para la autenticación de ingreso.
auth required pam_securetty.so — Este módulo asegura que si el usuario intenta
ingresar como root, el tty donde el usuario está ingresando debe estar listado en el archivo /etc/
securetty, si ese archivo existe.
Si el tty no está listado en el archivo, cualquier intento de loguearse como usuario root será erróneo
con el siguiente mensaje: Login incorrect.
auth required pam_unix.so nullok — Este módulo pide una contraseña al usuario, que
luego confirma utilizando la información almacenada en /etc/passwd, y /etc/shadow, si es que
existe.
• El argumento nullok le indica al módulo pam_unix.so que permita el ingreso de una
contraseña vacía.
• auth required pam_nologin.so — Este es el último momento de la autenticación. Confirma
que exista y en qué lugar, el archivo /etc/nologin. Si existe, pero el usuario no es root, la
autenticación falla.
72
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.
• account required pam_unix.so — Este módulo realiza cualquier tipo de verificación de
cuenta que sea necesario. Por ejemplo, si se ha activado el enmascaramiento de contraseñas, la
interfaz de la cuenta del módulo pam_unix.so verifica que la cuenta no haya expirado, o que el
usuario no haya modificado la contraseña dentro del período permitido.
• password required pam_cracklib.so retry=3 — Si una contraseña ha expirado, el
componente contraseña del módulo pam_cracklib.so solicita una nueva. En seguida confirma
que la nueva contraseña pueda o no ser fácilmente revelada por un programa de obtención de
contraseñas basado en diccionarios.
• El argumento retry=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 — This line specifies
that if the program changes the user's password, it should use the password interface of the
pam_unix.so module to do so.
• The argument shadow instructs the module to create shadow passwords when updating a user's
password.
• El argumento nullok le indica al módulo que le permita al usuario modificar su contraseña
desde una contraseña en blanco. De lo contrario, una contraseña vacía será tratada como un
bloqueo de cuenta.
• El argumento final de esta línea, use_authtok, ofrece un buen ejemplo de la importancia que
tiene el orden en que se "apilen" los modulos PAM. Este argumento le indica al módulo que no le
solicite al usuario una nueva contraseña, y que en su lugar acepte cualquier contraseña que haya
sido almacenada por un módulo anterior. De esta manera, todas las nuevas contraseñas deben
pasar la prueba 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.
3.5.5. Creación de los módulos PAM
Puede crear o añadir en cualquier momento nuevos módulos PAM, para utilizarlos con cualquier
aplicación con tengan este soporte.
Por ejemplo, un desarrollador puede crear un método para generar contraseñas que sean utilizadas
sólo una vez, y escribir un módulo PAM que pueda soportarlo. Los programas que tengan soporte
para PAM podrán utilizar inmediatamente este módulo, y el método de contraseña, sin por ello tener
que ser recompilados o modificados en alguna manera.
73
Esto permite a los desarrolladores y a los administradores de sistema mezclar, y al mismo
tiempo verificar, diferentes métodos de autenticación para diferentes programas sin necesidad de
recompilarlos.
Documentation on writing modules is included in the /usr/share/doc/pam-<version-number>/
directory, where <version-number> is the version number for PAM on your system.
3.5.6. PAM y el cacheo de la credencial administrativa
Una cantidad de herramientas administrativas gráficas en Fedora le ofrecen a los usuarios un elevado
grado de privilegio, durante un período de tiempo de hasta cinco minutos, utilizando el módulo
pam_timestamp.so. Es importante entender como funciona este mecanismo, ya que si algún
usuario abandona la terminal mientras continue vigente pam_timestamp.so, dejará a ese equipo
libre para ser manipulado por quienquiera que tenga acceso físico a la consola.
En el esquema del registro del tiempo de PAM, cuando es iniciada la aplicación administrativa
gráfica, solicita al usuario la contraseña de root. Cuando el usuario ha sido autenticado, el módulo
pam_timestamp.so crea un archivo de registro de tiempo. Por defecto, es creado en el directorio
/var/run/sudo/. Si el archivo ya existe, los programas administrativos gráficos no solicitarán una
contraseña. En su lugar, el módulo pam_timestamp.so actualizará el archivo de registro de tiempo,
reservando cinco minutos extra de acceso administrativo sin contraseñas al usuario.
You can verify the actual state of the timestamp file by inspecting the /var/run/sudo/<user> file.
For the desktop, the relevant file is unknown:root. If it is present and its timestamp is less than five
minutes old, the credentials are valid.
La existencia del archivo de registro de tiempo se indica mediante un ícono de autenticación, que
aparece en el área de notificación del panel.
Figura 3.7. El Ícono de autenticación
3.5.6.1. Borrando el archivo de registro de tiempo
Antes de abandonar la consola donde se encuentra activo el registro de tiempo de PAM, es
recomendable destruir el archivo correspondiente. Para hacerlo desde un entorno gráfico, haga clic
sobre el ícono de autenticación del panel. Esto hace que se abra un cuadro de diálogo. Haga clic
sobre el botón Olvidar Autenticación para destruir el archivo de registro de tiempo activo.
Figura 3.8. Diálogo de olvidar autenticación
Con respecto al archivo de registro de tiempo de PAM, debe prestarle atención a lo siguiente:
• Si ha ingresado en el sistema remotamente, utilizando el comando ssh, utilice el comando /sbin/
pam_timestamp_check -k root para destruir el archivo de registro de tiempo.
74
PAM y la propiedad de los dispositivos
• Será necesario que ejecute el comando /sbin/pam_timestamp_check -k root desde la
misma ventana de la terminal desde la que inició la aplicación con este privilegio.
• Debe estar registrado como el usuario que originalmente invocó el módulo pam_timestamp.so,
de modo de poder utilizar el comando /sbin/pam_timestamp_check -k. No se registre como
usuario root para utilizarlo.
• Si quiere abandonar las credenciales en el escritorio (sin utilizar la acción Olvidar Autenticación
del ícono), utilice el siguiente comando:
/sbin/pam_timestamp_check -k root </dev/null >/dev/null 2>/dev/null
Una falla al utilizar este comando hará que solo sean eliminadas las credenciales (en el caso que
las hubiera) del pty desde donde ejecutó el comando.
Consulte la página man pam_timestamp_check para obtener más información acerca del uso de
pam_timestamp_check para destruir el archivo de registro de tiempo.
3.5.6.2. Directivas comunes de pam_timestamp_check
El módulo pam_timestamp.so acepta varias indicaciones. Las siguientes dos opciones son algunas
de las más utilizadas:
• timestamp_timeout — Especifica el periodo (en segundos) durante el cual el archivo de registro
de tiempo es válido. El valor establecido por defecto es 300 (cinco minutos).
• timestampdir — Indica el directorio en donde el archivo de registro de tiempo será almacenado.
El valor establecido por defecto es /var/run/sudo/.
Vea la Sección 3.8.9.1, “Documentación instalada del cortafuego” para obtener mayor información
acerca del control del módulo pam_timestamp.so.
3.5.7. PAM y la propiedad de los dispositivos
En Fedora, el primer usuario que se registra en la consola física de la máquina, puede manipular
ciertos dispositivos y realizar ciertas tareas que por lo general son reservadas al usuario root. Esto es
controlado por un módulo PAM denominado pam_console.so.
3.5.7.1. Propiedad de los dispositivos
Cuando un usuario se registra en un sistema Fedora, el módulo pam_console.so es llamado
mediante el comando login, o mediante algunos de los programa gráficos de registro, como ser
gdm, kdm, y xdm. Si este usuario es el primero en registrarse en la consola física — denominada
consola del usuario — el modulo le asegura al usuario el dominio de una gran variedad de
dispositivos que normalmente le pertenecen al usuario root. Estos dispositivos le pertenecen a la
consola del usuario hasta que finalice su última sesión local. Una vez que este usuario haya finalizado
su sesión, la pertenencia de los dispositivos vuelve a ser del usuario root.
Los dispositivos afectados incluyen, pero no se limitan a, las placas de sonido, disqueteras, lectoras
de CD-ROM.
Esta instalación permite al usuario local manipular estos dispositivos sin obtener el acceso de root,
por lo que se simplifican las tareas comunes para el usuario de consola.
Puede modificar la lista de dispositivos controlados por pam_console.so editando los siguientes
archivos:
• /etc/security/console.perms
75
• /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 50default.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 50default.perms.
Advertencia
If the gdm, kdm, or xdm display manager configuration file has been altered to allow remote
users to log in and the host is configured to run at runlevel 5, it is advisable to change the
<console> and <xconsole> directives in the /etc/security/console.perms to the
following values:
<console>=tty[0-9][0-9]* vc/[0-9][0-9]* :0\.[0-9] :0
<xconsole>=:0\.[0-9] :0
Esto evita que los usuarios ganen acceso a dispositivos y aplicaciones restringidas en la
máquina.
If the gdm, kdm, or xdm display manager configuration file has been altered to allow remote
users to log in and the host is configured to run at any multiple user runlevel other than 5, it is
advisable to remove the <xconsole> directive entirely and change the <console> directive to
the following value:
<console>=tty[0-9][0-9]* vc/[0-9][0-9]*
3.5.7.2. Acceso a aplicaciones
El usuario de la consola también tiene el acceso a ciertos programas configurados para usar el
directorio /etc/security/console.apps/.
Este directorio contiene los archivos de configuración que habilitan al usuario de la consola correr
ciertas aplicaciones de /sbin y /usr/sbin.
Estos archivos de configuración tienen el mismo nombre de las aplicaciones que configuran.
Un grupo notable de aplicaciones a los que el usuario de consola tiene acceso son tres programas
que apagan o reinician el sistema:
• /sbin/halt
• /sbin/reboot
• /sbin/poweroff
Debido a que estas aplicaciones utilizan PAM, llaman al módulo pam_console.so como un requisito
para usarlas.
Diríjase a la Sección 3.8.9.1, “Documentación instalada del cortafuego” para obtener mayor
información.
76
Recursos adicionales
3.5.8. Recursos adicionales
Los siguientes recursos explican más detalladamente los métodos para usar y configurar PAM.
Además de estos recursos, lea los archivos de configuración de PAM en el sistema para entender
mejor cómo están estructurados.
3.5.8.1. Documentación de PAM instalada
• Las páginas man relacionadas con PAM — Hay varias páginas man para las distintas aplicaciones
y archivos de configuración involucrados con PAM. La siguiente es un alista de alguna de las
páginas man más importantes.
Archivos de configuración
• pam — Buena información de presentación de PAM, que incluye la estructura y propósito de
los archivos de configuración de PAM.
Tenga en cuenta 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.
• pam_console — Describe el propósito del módulo pam_console.so. También describe la
sintaxis apropiada para una entrada dentro del archivo de configuración de PAM.
• console.apps — Describe el formato del archivo de configuración /etc/security/
console.apps, que define qué aplicaciones son accesibles por el usuario de consola
asignado por PAM.
• console.perms — Describe el formato del archivo de configuración /etc/security/
console.perms, que especifica los permisos del usuario de consola asignados por PAM.
• pam_timestamp — Describe el módulo pam_timestamp.so.
• /usr/share/doc/pam-<version-number> — Contains a System Administrators' Guide, a
Module Writers' Manual, and the Application Developers' Manual, as well as a copy of the PAM
standard, DCE-RFC 86.0, where <version-number> is the version number of PAM.
• /usr/share/doc/pam-<version-number>/txts/README.pam_timestamp — Contains
information about the pam_timestamp.so PAM module, where <version-number> is the
version number of PAM.
3.5.8.2. Sitios web útiles sobre PAM
• http://www.kernel.org/pub/linux/libs/pam/ — El sitio web principal de distribución del proyecto LinuxPAM, que contiene información relacionada con varios módulos PAM, una sección con respuestas
a las preguntas más usuales (FAQ, por las siglas en inglés de Frequently Asked Questions), y
documentación adicional acerca de PAM.
77
Nota
La documentación en el sitio web recién mencionado corresponde a la última versión de
desarrollo lanzada de PAM y puede no ser 100% precisa para la versión de PAM incluida en
Fedora.
3.6. Encapsuladores TCP y xinetd
Controlling access to network services is one of the most important security tasks facing a server
administrator. Fedora provides several tools for this purpose. For example, an iptables-based
firewall filters out unwelcome network packets within the kernel's network stack. For network services
that utilize it, TCP Wrappers add an additional layer of protection by defining which hosts are or are
not allowed to connect to "wrapped" network services. One such wrapped network service is the
xinetd super server. This service is called a super server because it controls connections to a subset
of network services and further refines access control.
Figura 3.9, “Control de acceso a servicios de red” es una ilustración básica acerca de cómo estas
herramientas trabajan conjuntamente para proteger los servicios de red.
78
Encapsuladores TCP
Figura 3.9. Control de acceso a servicios de red
El siguiente 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 3.9, “IPTables”.
3.6.1. Encapsuladores TCP
El paquete de los encapsuladores TCP (tcp_wrappers) se encuentra instalado por defecto y ofrece
control de acceso a los servicios de red basado en los equipos. El componente más importante
de este paquete es la biblioteca /usr/lib/libwrap.a. En términos generales, un servicio
encapsulado por TCP es un servicio que ha sido compilado con la biblioteca libwrap.a.
When a connection attempt is made to a TCP-wrapped service, the service first references the host's
access files (/etc/hosts.allow and /etc/hosts.deny) to determine whether or not the client is
allowed to connect. In most cases, it then uses the syslog daemon (syslogd) to write the name of the
requesting client and the requested service to /var/log/secure or /var/log/messages.
Si un cliente tiene permitida la conexión, los encapsuladores TCP liberan el control de la conexión al
servicio solicitado, y abandonan el proceso de comunicación entre el cliente y el servidor.
Además del control de acceso y registro, los encapsuladores TCP pueden ejecutar comandos para
interactuar con el cliente antes que sea negado el control de la conexión, o antes de abandonar el
proceso de conexión al servicio de red solicitado.
79
Because TCP Wrappers are a valuable addition to any server administrator's arsenal of security tools,
most network services within Fedora are linked to the libwrap.a library. Some such applications
include /usr/sbin/sshd, /usr/sbin/sendmail, and /usr/sbin/xinetd.
Nota
Para determinar si un servicio de red ejecutable está enlazado con libwrap.a, ingrese el
siguiente comando como usuario root:
ldd <binary-name> | grep libwrap
Replace <binary-name> with the name of the network service binary.
Si el comando no le devuelve ninguna información, entonces el servicio de red no se encuentra
enlazado con libwrap.a.
El siguiente ejemplo inidica que /usr/sbin/sshd se encuentra enlazado con libwrap.a:
[root@myServer ~]# ldd /usr/sbin/sshd | grep libwrap
libwrap.so.0 => /lib/libwrap.so.0 (0x00655000)
[root@myServer ~]#
3.6.1.1. Ventajas de los Encapsuladores TCP
Los encapsuladores TCP ofrecen las siguientes ventajas en comparación con otras técnicas para el
control de servicios de red:
• Transparencia tanto para el cliente como para el servicio de red encapuslado — Tanto el cliente que
está conectándose como el servicio de red, no tienen conocimiento de que los encapsuladores TCP
están siendo utilizados. Los usuarios legítimos se registran y conectan a los servicios solicitados,
mientras que no se realizan las conexiones pedidas por clientes no autorizados.
• Administración centralizada de múltiples protocolos — los encapsuladores TCP operan en forma
separada de los servicios de red que protegen, permitiendo así que varias aplicaciones de servidor
compartan un conjunto común de archivos de configuración de control de acceso, haciendo posible
que la administración sea más sencilla.
3.6.2. Archivos de configuración de los encapsuladores TCP
Para determinar si a un cliente le es permitido conectarse a un servidor, los encapsuladores TCP
consultan los dos archivos siguientes, comúnmente denominados archivos de acceso de equipos:
• /etc/hosts.allow
• /etc/hosts.deny
Cuando un servicio encapsulado por TCP recibe una petición de un cliente, realiza los siguientes
pasos:
1. Consulta con /etc/hosts.allow. — El servicio encapsulado por TCP analiza secuencialmente
el archivo /etc/hosts.allow y aplica la primera regla especificada para ese servicio. Si
encuentra una regla concordante, permite la conexión. Si no, avanza al siguiente paso.
80
Archivos de configuración de los encapsuladores TCP
2. Consulta con /etc/hosts.deny. — El servicio encapsulado por TCP analiza secuencialmente
el archivo /etc/hosts.deny. Si encuentra una regla concordante, niega la conexión. Si no,
permite el acceso al servicio.
Las siguientes son cuestiones importantes para considerar cuando se utilice encapsuladores TCP
para proteger servicios de red:
• Debido a que primero se aplican las reglas de acceso contenidas en hosts.allow, dejan un
precedente sobre las reglas especificadas 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.
• Si no se encuentran reglas para el servicio en el archivo, o el archivo no existe, el acceso al servicio
es permitido.
• Los servicios encapsulados por TCP no conservan las reglas desde los archivos de acceso de los
equipos, de modo que cualquier cambio en hosts.allow o hosts.deny, tienen efecto inmediato,
sin necesidad de reiniciar los servicios de red.
Advertencia
Si la última línea del archivo de acceso de un equipo no es un caracter de tipo nueva línea
(creado al presionar la tecla Enter key), la última regla del archivo fallará y un error será
registrado o bien en /var/log/messages, o bien en /var/log/secure. Este es el mismo
caso de una regla que abarca líneas múltiples sin utilizar el carcater de línea invertida. El
siguiente ejemplo muestra la sección que nos interesa del fracaso de una regla debido a alguna
de las circunstancias recién descritas:
warning: /etc/hosts.allow, line 20: missing newline or line too long
3.6.2.1. Formateo de las reglas de acceso
El formato tanto de /etc/hosts.allow como de /etc/hosts.deny es el mismo. Cada regla
debe estar en su propia línea. Líneas vacías o líneas que empiezan con el símbolo numeral (#) son
ignoradas.
Cada regla utiliza el siguiente formato básico para controlar el acceso a los servicios de red:
<daemon list>: <client list> [: <option>: <option>: ...]
• <daemon list> — A comma-separated list of process names (not service names) or the ALL
wildcard. The daemon list also accepts operators (refer to Sección 3.6.2.1.4, “Operadores”) to allow
greater flexibility.
• <client list> — A comma-separated list of hostnames, host IP addresses, special patterns, or
wildcards which identify the hosts affected by the rule. The client list also accepts operators listed in
Sección 3.6.2.1.4, “Operadores” to allow greater flexibility.
81
• <option> — An optional action or colon-separated list of actions performed when the rule is
triggered. Option fields support expansions, launch shell commands, allow or deny access, and alter
logging behavior.
Nota
Puede encontrarse mayor información acerca de los términos recién vistos en otras partes de
esta Guía:
• Sección 3.6.2.1.1, “Comodines”
• Sección 3.6.2.1.2, “Patrones”
• Sección 3.6.2.2.4, “Expansiones”
• Sección 3.6.2.2, “Campos de opción”
A continuación se muestra el ejemplo de una regla básica de acceso de equipos:
vsftpd : .example.com
Esta regla está indicando a los encapsuladores TCP que observen las conexiones del demonio
FTP (vsftpd) desde cualquier equipo en el dominio ejemplo.com. Si esta regla aparece en
hosts.allow, la conexión es aceptada. Si esta regla figura en hosts.deny, la conexión es negada.
El siguiente ejemplo de regla de acceso de equipos es más compleja y utiliza dos campos de
opciones:
sshd : .example.com
deny
\ : spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \ :
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 3.6.2.2, “Campos de opción”.
3.6.2.1.1. Comodines
Los comodines le permiten a los encapsuladores TCP poder corresponderse más fácilmente con
grupos de demonios de equipos. Son más frecuentemente utilizados en el campo lista de cliente de
las reglas de acceso.
Los siguientes comodines están disponibles:
• ALL — Se corresponde con todo. Puede ser utilizado tanto para la lista del demonio como con la
lista del cliente.
• LOCAL — Se corresponde con cualquier equipo que no contenga un punto (.), como por ejemplo el
equipo local.
82
• 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.
3.6.2.1.2. Patrones
Pueden utilizarse patrones en el campo cliente de las reglas de acceso para especificar grupos de
equipos de clientes en forma 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
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.
83
• [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.
3.6.2.1.3. Portmap y encapsuladores TCP
Portmap's implementation of TCP Wrappers does not support host look-ups, which means
portmap can not use hostnames to identify hosts. Consequently, access control rules for portmap in
hosts.allow or hosts.deny must use IP addresses, or the keyword ALL, for specifying hosts.
Los cambios en las reglas de control de acceso de portmap podrían no tener efecto inmediatamente.
Tal vez necesite reiniciar el servicio portmap.
Servicios muy utilizados, como NIS o NFS, dependen de portmap para funcionar, de modo que
tenga en cuenta estas limitaciones.
3.6.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.
84
En el siguiente ejemplo de un archivo hosts.allow, todos los equipos ejemplo.com tienen
permitido conectarse a todos los servicios, exepcto cracker.ejemplo.com:
ALL: .example.com EXCEPT cracker.example.com
En otro ejemplo de un archivo hosts.allow, los clientes de la red 192.168.0.x pueden utilizar
todos los servicios con excepción de FTP:
ALL EXCEPT vsftpd: 192.168.0.
Nota
En términos de organización, generalmente es más sencillo evitar la utilización de operadores
EXCEPT. Esto permite que otros administradores analicen rápidamente los archivos apropiados
para ver a qué equipos se les permite o se les niega el acceso a los servicios, sin tener que
organizar los operadores EXCEPT.
3.6.2.2. Campos de opción
Además de las reglas básicas que permiten o que niegan el acceso, la implementación de
encapsuladores TCP de Fedora soporta extensiones al lenguaje de control de acceso a través
de campos de opción. Al utilizar los campos de opción en reglas de acceso de equipos, los
administradores pueden realizar una variedad de tareas, como por ejemplo, modificar el
comportamiento de los registros, consolidar control de acceso e iniciar comandos de terminal.
3.6.2.2.1. Registro
Los campos de opción permiten que los administradores modifiquen fácilmente la herramienta de
registro y el nivel de prioridad para una regla, utilizando la directiva severity.
En el siguiente ejemplo, las conexiones con el demonio SSH desde cualquier equipo del dominio
ejemplo.com son registradas en la herramienta authpriv syslog establecida por defecto (debido
a que ningún valor de la herramienta es especificado) con una prioridad de emerg:
sshd : .example.com : severity emerg
Es también posible especificar una herramienta utilizando la opción severity. El siguiente ejemplo
registra cualquier intento de conexión SSH realizada por equipos del dominio ejemplo.com a la
herramienta local0, con una prioridad de alert:
sshd : .example.com : severity local0.alert
85
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.
3.6.2.2.2. Control de acceso
Los campos de opción también le permiten a los administradores permitir o negar explícitamente
equipos mediante una sola regla, añadiéndole la directiva allow o deny como la opción final.
Por ejemplo, las dos reglas siguientes permiten conexions SSH desde client-1.example.com,
pero niegan conexiones de client-2.example.com:
sshd : client-1.example.com : allow
sshd : client-2.example.com : deny
Al permitir control de acceso sobre un fundamento de reglas, el campo de opción permite que los
administradores consoliden todas los reglas de acceso en un solo archivo: o bien hosts.allow, o
bien hosts.deny. Algunos administradores consideran a esto como una forma sencilla de organizar
las reglas de acceso.
3.6.2.2.3. Comandos de la consola
Los campos de opción permiten reglas de acceso para iniciar comandos de consola mediante las dos
directivas siguientes:
• spawn — Inicia un comando de terminal como un proceso hijo. Esta directiva puede realizar tareas
como ser la utilización de /usr/sbin/safe_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 — Replaces the requested service with the specified command. This directive is often used
to set up traps for intruders (also called "honey pots"). It can also be used to send messages to
connecting clients. The twist directive must occur at the end of the rule line.
En el ejemplo siguiente, a los clientes que intentan acceder a los servicios FTP desde el dominio
ejemplo.com, se les envía un mensaje utilizando el comando echo.
vsftpd : .example.com \
: twist /bin/echo "421 This domain has been black-listed. Access denied!"
Para obtener mayor información acerca de las opciones de comandos de terminal, vea la página man
de hosts_options.
86
3.6.2.2.4. Expansiones
Cuando se utilizan junto a las directivas spawn y twist, las expansiones proveen información acerca
del cliente, servidor, y los procesos involucrados.
La siguiente es una lista de expansiones soportadas:
• %a — Returns the client's IP address.
• %A — Returns the server's IP address.
• %c — Informa una gran cantidad de datos del cliente, como ser por ejemplo, el nombre de usuario y
el nombre del equipo, o el nombre de usuario y la dirección IP.
• %d — Informa el nombre del demonio encargado del proceso.
• %h — Returns the client's hostname (or IP address, if the hostname is unavailable).
• %H — Returns the server's hostname (or IP address, if the hostname is unavailable).
• %n — Returns the client's hostname. If unavailable, unknown is printed. If the client's hostname and
host address do not match, paranoid is printed.
• %N — Returns the server's hostname. If unavailable, unknown is printed. If the server's hostname
and host address do not match, paranoid is printed.
• %p — Returns the daemon's process ID.
• %s — Informa diferentes tipos de datos acerca del servidor, como ser por ejemplo, si el proceso del
demonio y la dirección del equipo o dirección IP del servidor.
• %u — Returns the client's username. If unavailable, unknown is printed.
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 \
: twist /bin/echo "421 %h has been banned from this server!"
Para obtener una explicación completa de las expansiones disponibles, y al mismo tiempo conocer
opciones adicionales de control de acceso, vea la sección 5 de las páginas man de hosts_access
(man 5 hosts_access), y la página man de hosts_options.
Para obtener mayor información acerca de los encapsuladores TCP, vea la Sección 3.6.5, “Recursos
adicionales”.
87
3.6.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.
3.6.4. Archivos de configuración de xinetd
Los archivos de configuración para xinetd son los siguientes:
• /etc/xinetd.conf — El archivo de configuración general de xinetd.
• /etc/xinetd.d/ — El directorio continente de todos los archivos específicos para cada servicio.
3.6.4.1. El archivo /etc/xinetd.conf
The /etc/xinetd.conf file contains general configuration settings which affect every service under
xinetd's control. It is read when the xinetd service is first started, so for configuration changes to
take effect, you need to restart the xinetd service. The following is a sample /etc/xinetd.conf
file:
defaults
{
instances
log_type
log_on_success
log_on_failure
cps
}
includedir /etc/xinetd.d
=
=
=
=
=
60
SYSLOG authpriv
HOST PID
HOST
25 30
Estas lineas controlan los siguientes aspectos de xinetd:
• instances — Indica el 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 — Configures xinetd to log successful connection attempts. By default, the
remote host's IP address and the process ID of the server processing the request are recorded.
• log_on_failure — Configura xinetd para registrar intentos de conexión fallidos, o casos en
que la conexión fue negada.
88
Archivos de configuración de xinetd
• 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.
• includedir /etc/xinetd.d/ — Incluye opciones declaradas en los archivos de configuración
propios de cada servicio, ubicados en el directorio /etc/xinetd.d/. Para obtener mayor
infirmación, consulte Sección 3.6.4.2, “El directorio /etc/xinetd.d/”.
Nota
Often, both the log_on_success and log_on_failure settings in /etc/xinetd.conf
are further modified in the service-specific configuration files. More information may therefore
appear in a given service's log file than the /etc/xinetd.conf file may indicate. Refer to
Sección 3.6.4.3.1, “Opciones para registrado” for further information.
3.6.4.2. El directorio /etc/xinetd.d/
El directorio /etc/xinetd.d/ contiene los archivos de configuración para cada servicio
administrado por xinetd, y los nombres de los archivos correspondientes al servicio. Del mismo
modo que con xinetd.conf, este directorio es de solo lectura cuando el servicio xinetd es
iniciado. Para que cualquier cambio pueda tener efecto, el administrador debe reiniciar el servicio
xinetd.
El formato de los archivos en el directorio /etc/xinetd.d/ utiliza las mismas convenciones que /
etc/xinetd.conf. La principal razón por la que la configuración de cada servicio sea almacenada
en un archivo diferente, es para hacer más sencilla la personalización, y menos propensa a modificar
otros servicios.
Para adquirir una mejor comprensión acerca de cómo están estructurados estos archivos, prestele
atención al archivo /etc/xinetd.d/krb5-telnet:
service telnet
{
flags
socket_type
wait
user
server
log_on_failure
disable
}
= REUSE
= stream
= no
= root
= /usr/kerberos/sbin/telnetd
+= USERID
= yes
Estas líneas controlan numerosos aspectos del servicio telnet:
• service — Especifica el nombre del servicio, generalmente uno de aquellos listados en el archivo
/etc/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.
89
Nota
La marca REUSE es obsoleta. Todos los servicios hoy en día utilizan la marca REUSE.
• socket_type — Establece el tipo de socket de red a stream.
• wait — Especifica cuando el servicio es tratado como de uno solo hilo de ejecución (yes) o como
de múltiples hilos de ejecución (no).
• user — Especifica bajo qué ID de usuario se está ejecutando el proceso.
• server — Especifica el binario ejecutable a ser lanzado.
• log_on_failure — Especifica parámetros de registro para log_on_failure, además de los
que ya están definidos en xinetd.conf.
• disable — Especifica cuándo el servicio debe ser desactivado (yes), o activado (no).
Para obtener mayor información sobre estas opciones y su uso, consulte la página man de
xinetd.conf.
3.6.4.3. Alteración de los archivos de configuración de xinetd
Existen disponibles una variedad de directivas protegidas por xinetd. En esta sección se detallan
algunas de las opciones más comunmente utilizadas.
3.6.4.3.1. Opciones para registrado
Las siguientes opciones de registro se encuentran disponibles tanto para /etc/xinetd.conf como
para los archivos de configuración del servicio específico en el directorio /etc/xinetd.d/.
La siguiente es una lista de las opciones de registro más utilizadas:
• ATTEMPT — Registra el hecho de haberse realizado un intento fallido (log_on_failure).
• DURATION — Registra el período de tiempo total en que ha sido utilizado el servicio por un sistema
remoto (log_on_success).
• EXIT — Registra el estado de salida, o la señal de finalización del servicio (log_on_success).
• HOST — Logs the remote host's IP address (log_on_failure and log_on_success).
• PID — Registra el ID de los procesos del servidor que recibe el pedido (log_on_success).
• USERID — Registra a los usuarios remotos que utilizan el 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.
3.6.4.3.2. Opciones para el control de acceso
Los usuarios de los servicios xinetd pueden elegir entre utilizar las reglas de acceso de los equipos
con encapsuladores TCP, o proveer control de acceso mediante los archivos de configuración de
90
xinetd, o una mezcla de ambos. Para obtener mayor información acerca del control de acceso de
los equipos con encapsuladores TCP, consulte la Sección 3.6.2, “Archivos de configuración de los
encapsuladores TCP”.
En esta sección se desarrolla la utilización de xinetd para controlar el acceso a los servicios.
Nota
Al contrario que con los encapsuladores TCP, las modificaciones al control de acceso sólo tienen
efecto si el administrador de xinetd reinicia el servicio xinetd.
De manera similar, al contrario que los encapsuladores TCP, el control de acceso mediante
xinetd solo afecta a los servicios controlados por xinetd.
The xinetd hosts access control differs from the method used by TCP Wrappers. While TCP
Wrappers places all of the access configuration within two files, /etc/hosts.allow and /etc/
hosts.deny, xinetd's access control is found in each service's configuration file in the /etc/
xinetd.d/ directory.
Las siguientes opciones de acceso de equipos están soportadas por xinetd:
• only_from — Permite la utilización del servicio sólo a los equipos especificados.
• no_access — Impide la utilización del servicio a los equipos indicados.
• access_times — Establece el período de tiempo en que un servicio particular puede ser utilizado.
Este período debe ser indicado con notaciones en formato de 24 horas, HH:MM-HH:MM.
Las opciones only_from y no_access pueden utilizar una lista de direcciones IP o nombres
de archivo, o pueden especificar una red entera. Del mismo modo que los encapsuladores TCP,
combinar el control de acceso de xinetd con la configuración mejorada de registro puede aumentar
la seguridad evitando las peticiones de los equipos bloqueados, al mismo tiempo que se registra cada
intento de conexión.
Por ejemplo, el siguiente archivo /etc/xinetd.d/telnet puede utilizarse para bloquear accesos
Telnet desde un grupo de determinado, y restringir el tiempo total en que pueden registrarse incluso
los usuarios autorizados:
service telnet
{
disable
flags
socket_type
wait
user
server
log_on_failure
no_access
log_on_success
access_times
}
= no
= REUSE
= stream
= no
= root
+= USERID
= 172.16.45.0/24
+= PID HOST EXIT
= 09:45-16:15
En este ejemplo, cuando un sistema de cliente de la red 172.16.45.0/24, como por
ejemplo172.16.45.2, intente acceder al servicio Telnet, recibe el siguiente mensaje:
91
Connection closed by foreign host.
Además, sus intentos de registro son almacenados en /var/log/messages de la manera siguiente:
Sep
Sep
Sep
7 14:58:33 localhost xinetd[5285]: FAIL: telnet address from=172.16.45.107
7 14:58:33 localhost xinetd[5283]: START: telnet pid=5285 from=172.16.45.107
7 14:58:33 localhost xinetd[5283]: EXIT: telnet status=0 pid=5285 duration=0(sec)
Al utilizar encapsuladores TCP junto con control de acceso xinetd, es importante comprender la
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.
3.6.4.3.3. Opciones de unión y redirección
Los archivos de configuración del servicio xinetd tienen soporte para asociar el servicio con una
dirección IP, y redireccionar las peticiones entrantes para ese servicio hacia otra dirección IP, nombre
de equipo, o puerto.
Esta asociación es controlada con la opción bind en el archivo de configuración específico de cada
servicio, y enlaza ese servicio con una dirección IP en el sistema. Cuando esto es configurado, la
opción bind sólo acepta peticiones para acceder al servicio de la dirección IP correcta. Puede utilizar
este método para asociar diferentes servicios con diferentes interfases de acuerdo a sus propias
necesidades.
Esto es especialmente útil para los sistemas con adaptadores de red múltiples, o con múltiples
direcciones IP. En tales sistemas, los servicios no seguros (Telnet, por ejemplo), pueden ser
configurados para que sólo escuchen en una interfaz conectada con una red privada y no con una
interfaz conectada a Internet.
La opción redirect acepta una dirección IP o nombre de equipo seguido por un número de puerto.
Configura el servicio de modo tal de poder redireccionar cualquier petición para este servicio hacia
el equipo y número de puerto indicado. Esta herramienta puede ser utilizada para dirigirse hacia otro
número de puerto en el mismo sistema, redireccionar la petición hacia una dirección IP diferente en
la misma máquina, intercambiar la petición con un sistema y número de puerto totalmente diferente,
o combinar entre ellas cualesquiera de estas opciones. Un usuario conectándose con un servicio
92
determinado de un sistema, por lo tanto puede ser reruteado hacia otro sistema sin sufrir ningún tipo
de interrupción.
El demonio xinetd es capaz de lograr este redireccionamiento extendiendo un proceso activo
durante todo el tiempo que dure la conexión, entre la máquina del cliente que realiza la petición y el
equipo que efectivamente está proveyendo el servicio, transfiriendo los datos entre ambos sistemas.
Las ventajas de bind y redirect se hacen más evidentes cuando se utilizan de manera conjunta.
Al asociar un servicio con una dirección IP determinada de un sistema, y luego redireccionar las
peticiones para este servicio hacia una segunda máquina que sólo pueda ser vista por la primera,
puede entonces utilizarse un sistema interno que ofrezca servicios para una red comopletamente
diferente. Alternativamente, estas opciones pueden ser utilizadas para limitar la exposición de
un servicio determinado en una máquina hacia una dirección IP conocida, al mismo tiempo que
redirecciona cualquier petición para ese servicio hacia otra máquina configurada para ese propósito.
Por ejemplo, piense en un sistema que es utilizado como un cortafuegos con la siguiente
configuración para su servicio Telnet:
service telnet
{
socket_type = stream
wait
= no
server
log_on_success += DURATION USERID
log_on_failure += USERID
bind
= 123.123.123.123
redirect
= 10.0.1.13 23
}
Las opciones bind y redirect de este archivo aseguran que el servicio Telnet en la máquina está
unido a la dirección IP externa (123.123.123.123), por medio de la cual se conecta a Internet.
Además, cualquier petición para el servicio Telnet enviada a 123.123.123.123, es redireccionada
hacia una dirección IP interna mediante un segundo adaptador de red (10.0.1.13) a la que
solo el cortafuegos y los sistemas internos pueden acceder. El cortafuegos entonces envía la
comunicacién entre ambos sistemas, y el sistema que está conectándose piensa que lo ha hecho con
123.123.123.123, cuando en realidad está conectado con una máquina diferente.
Esta herramienta es especialmente útil para usuarios con conexiones de banda ancha que sólo
posean una dirección IP fija. Si utilizan Traductores de Direcciones de Red (NAT por las iniciales
en inglés de Network Adress Translations), los sistemas detrás de la máquina que hace de puerta
de enlace, que están utilizando direcciones IP sólo internas, no están disponibles desde fuera del
sistema de puerta de enlace. Sin embargo, cuando ciertos servicios controlados por xinetd son
configurados con las opciones bind y redirect, la máquina que hace de puerta de enlace puede
actuar como un proxy entre los sistemas externos y una máquina interna determinada que haya
sido configurada para ofrecer el servicio. Además, las diferentes opciones de registro y de control de
acceso de xinetd, están disponibles para establecer protección adicional.
3.6.4.3.4. Opciones de administración de recursos
El demonio xinetd puede ofrecer un nivel de protección básico para los ataques de Denegación de
Servicio (DoS, por las iniciales en inglés de Denial of Service). La siguiente es una lista de directivas
que pueden ayudar a disminuir la efectividad de tales ataques:
• per_source — Establece el número máximo de instancias para un servicio desde cada dirección
IP. Acepta solo valores enteros como argumentos y puede ser utilizada tanto en xinetd.conf
como en el archivo de configuración específico del servicio en cuestión del directorio xinetd.d/.
93
• 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/.
• max_load — Define la utilización del CPU o el umbral de carga de utilización promedio de un
servicio. Acepta un número de punto flotante como argumento.
La carga promedio es una medida aproximada que indica la forma en que algunos procesos están
activos en un determinado período de tiempo. Para obtener mayor información acerca de la carga
promedio, vea los 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.
Mayor información acerca de los encapsuladores TCP y xinetd se encuentra disponible en Internet
y en la documentación del sistema.
3.6.5.1. Documentación instalada acerca de los encapsuladores TCP
La documentación de su sistema es un buen lugar en donde empezar a buscar opciones adicionales
de configuración para los encapsuladores TCP, xinetd, y control de acceso.
• /usr/share/doc/tcp_wrappers-<version>/ — This directory contains a README file that
discusses how TCP Wrappers work and the various hostname and host address spoofing risks that
exist.
• /usr/share/doc/xinetd-<version>/ — This directory contains a README file that discusses
aspects of access control and a sample.conf file with various ideas for modifying service-specific
configuration files in the /etc/xinetd.d/ directory.
• 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.
• 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.
4
http://www.xinetd.org
94
Kerberos
3.6.5.2. Sitios web útiles relacionados con encapsuladores TCP
4
• http://www.xinetd.org/ — El sitio principal de xinetd, que contiene archivos de configuración
a modo de ejemplo, lista completa de herramientas, y una sección informativa de preguntas
frecuentes (FAQ, por las iniciales en inglés de Frecuently Asked Questions).
• http://www.docstoc.com/docs/2133633/An-Unofficial-Xinetd-Tutorial — Un tutorial en el que se
explican diferentes formas de optimizar los archivos de configuración de xinetd establecidos por
defecto, de manera de poder alcanzar objetivos de seguridad específicos.
3.6.5.3. Libros relacionados
• Hacking Linux Exposed por Brian Hatch, James Lee, y George Kurtz; Osbourne/McGraw-Hill
— Una herramienta de seguridad excelente con información acerca de encapsuladores TCP y
xinetd.
3.7. Kerberos
La seguridad e integridad del sistema dentro de la red puede ser complejo. Puede necesitarse
el tiempo de varios administradores solo para poder conocer qué servicios son los que 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.
3.7.1. ¿Qué es Kerberos?
Kerberos es un protocolo de autenticación de red creado por el MIT (Massachusetts Institute of
5
Technology), y utiliza una criptografía de llave simétrica para autenticar a los usuarios de los
servicios de red, lo que en pocas palabras significa que las contraseñas nunca son enviadas a través
de la red.
Consecuentemente, cuando los usuarios se autentican con servicios de red usando Kerberos, los
usuarios no autorizados que intenten averiguar las contraseñas monitoreando el tráfico de red son
efectivamente bloqueados.
3.7.1.1. Ventajas de Kerberos
La mayoría de los servicios convencionales de red utilizan esquemas de autenticación basados
en contraseñas. Estos esquemas piden que los usuarios se identifiquen en un servidor de red
determinado mediante su nombre y contraseña. Desafortunadamente, la transmisión de los datos
para la autenticación de muchos servicios no es encriptada. Para que este tipo de esquemas sean
seguros, la red tiene que permanecer inaccesible a los usuarios extraños a ella, y todos los equipos y
todos los usuarios pertenecientes deben ser considerados confiables.
Aún si este es el caso, una red que se encuentre conectada a Internet no puede ser concebida como
una red segura. Cualquier atacante que obtenga acceso a la red puede utilizar un simple analizador
5
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.
95
de paquetes, también conocido como "rastreador" de paquetes, para interceptar nombres de usuario
y contraseñas, comprometiendo las cuentas de usuario y la integridad de toda la infraestructura de
seguridad.
El objetivo primario del diseño de Kerberos es eliminar la transmisión de contraseñas encriptadas en
la red. Si se usa apropiadamente, Kerberos elimina efectivamente la amenaza de los husmeadores
(sniffers) de paquetes en la red.
3.7.1.2. Desventajas de Kerberos
Aunque Kerberos elimina una amenaza de seguridad común y severa, puede ser difícil de
implementar por una variedad de razones:
• Puede ser algo muy tedioso migrar las contraseñas de los usuarios de una base de datos UNIX
estándar, como ser por ejemplo /etc/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 3.7.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.
• 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.
3.7.2. Terminología de Kerberos
Kerberos tiene su propia terminología para definir varios aspectos del servicio. Antes de aprender
cómo funciona Kerberos, es importante conocer algunos de los siguientes términos:
6
http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html#pwconvert
96
Terminología de Kerberos
Servidor de autenticación (SA)
Un servidor que envía comprobantes (o tickets) para un servicio determinado, comprobantes
que en su momento serán enviados a los usuarios para que puedan acceder a ese servicio. El
AS responde con una petición a las solicitudes de los clientes que, o no tienen o no han enviado
sus credenciales de autenticación. Generalmente, para tener acceso al servidor que emite las
garantías de los comprobantes (TGS, por las siglas en inglés de Ticket-Granting Server), se envía
un comprobante de obtención de garantía de comprobante (TGT, Ticket-Granting Ticket). Por
último, el AS generalmente se ejecuta en el mismo equipo que el centro de distribución de claves
(KDC, Key Distribution Center).
ciphertext
Datos encriptados.
cliente
Una entidad en la red (un usuario, equipo o aplicación) que puede recibir tickets desde Kerberos.
credenciales
Un conjunto de credenciales electrónicas temporales que verifican la identidad de un cliente para
un servicio particular. También llamado ticket.
caché de credenciales o archivo de ticket
Un archivo que contiene las claves para encriptar las comunicaciones entre un usuario y varios
servicios de red. Kerberos 5 soporta un marco de trabajo para el uso de otros tipos de cache,
tales como memoria compartida, pero los archivos son los más completamente soportados.
hash de encriptado
Un hash de una vuelta se usa para autenticar los usuarios. Estos son más seguros que usar
datos no encriptados, pero todavía son relativamente fáciles de desencriptar para craqueadores
experimentados.
GSS-API
La Interfaz del Programa de la Aplicación de Servicios Generales de Seguridad (API, por las
siglas en inglés de Generic Security Service Application Program Interfaz), es un conjunto de
funciones que proveen servicios de seguridad, definida en RFC-2743, publicada por el Equipo
de Tareas de Ingeniería de Internet. La API es utilizada por servicios y clientes para autenticarse
mutuamente sin que sus programas posean conocimientos específicos de los mecanismos
subyacentes. Si un servicio de red (como por ejemplo cyrus-IMAP) utiliza GSS-API, entonces
puede autenticarse mediante Kerberos.
hash
También conocido como valor hash. Un valor generado por el paso de una cadena a través de
una función hash. Estos valores son típicamente usados para asegurar que los datos transmitidos
no fueron interceptados y modificados.
función hash
A way of generating a digital "fingerprint" from input data. These functions rearrange, transpose or
otherwise alter data to produce a hash value.
llave
Los datos usados cuando se encriptan o desencriptan otros datos. Los datos encriptados no
pueden ser desencriptados sin una clave apropiada o una extrema buena suerte de parte del
craqueador.
97
centro de distribución de claves (KDC)
Un servicio que emite tickets de Kerberos, y que usualmente corre en el mismo equipo que el
servidor de garantía de ticket (TGS).
tabla de clave (keytab)
Un archivo que incluye una lista no encriptada de principales con sus respectivas claves. Los
servidores obtienen las claves que necesitan desde los archivos keytab en lugar de utilizar
kinit. El archivo keytab establecido por defecto es /etc/krb5.keytab. El servidor que
administra el KDC /usr/kerberos/sbin/kadmind, es el único servicio que utiliza cualquier
otro archivo (utiliza /var/kerberos/krb5kdc/kadm5.keytab).
kinit
El comando 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.
principal (o nombre principal)
The principal is the unique name of a user or service allowed to authenticate using Kerberos. A
principal follows the form root[/instance]@REALM. For a typical user, the root is the same as
their login ID. The instance is optional. If the principal has an instance, it is separated from the
root with a forward slash ("/"). An empty string ("") is considered a valid instance (which differs
from the default NULL instance), but using it can be confusing. All principals in a realm have their
own key, which for users is derived from a password or is randomly set for services.
reinado
Una red que use Kerberos, compuesta de uno o más servidores llamados KDCs y un número
potencialmente grande de clientes.
servicio
Un programa accedido por la red.
ticket
Un conjunto temporal de credenciales electrónicas que verifican la identidad de un cliente para un
servicio particular. También llamados credenciales o comprobantes.
servidor de garantías de tickets (TGS)
Un servidor que emite tickets para un servicio deseado que son a su vez dados a los usuarios
para acceder al servicio. El TGS corre normalmente en el mismo equipo que el KDC.
ticket de garantía de ticket (TGT)
Un ticket especial que permite al cliente obtener tickets adicionales sin aplicar nuevamente en el
KDC.
contraseña no encriptada
Una contraseña en texto plano, legible al humano.
3.7.3. Como Funciona Kerberos
Kerberos differs from username/password authentication methods. Instead of authenticating each
user to each network service, Kerberos uses symmetric encryption and a trusted third party (a KDC),
to authenticate users to a suite of network services. When a user authenticates to the KDC, the
KDC sends a ticket specific to that session back to the user's machine, and any Kerberos-aware
services look for the ticket on the user's machine rather than requiring the user to authenticate using a
password.
98
Como Funciona Kerberos
Cuando un usuario kerberizado de una red se loguea en su estación de trabajo, su principal es
enviado al KDC como parte de un pedido para un TGT del servidor de Autenticación. Este pedido
puede ser enviado por el programa de logueo de modo que sea transparente para el usuario, o puede
ser enviado por el programa kinit luego que el usuario se haya logueado.
The KDC then checks for the principal in its database. If the principal is found, the KDC creates a TGT,
which is encrypted using the user's key and returned to that user.
The login or kinit program on the client then decrypts the TGT using the user's key, which it
computes from the user's password. The user's key is used only on the client machine and is not
transmitted over the network.
The TGT is set to expire after a certain period of time (usually ten to twenty-four hours) and is stored in
the client machine's credentials cache. An expiration time is set so that a compromised TGT is of use
to an attacker for only a short period of time. After the TGT has been issued, the user does not have to
re-enter their password until the TGT expires or until they log out and log in again.
Siempre que el usuario necesite acceso a un servicio de red, el software del cliente utiliza el TGT para
pedirle al TGS un nuevo comprobante 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 3.7.10, “Recursos adicionales” para conocer otros enlaces hacia información
más detallada.
99
Nota
Kerberos depende de los siguientes servicios de red para funcionar correctamente.
• Sincronización de reloj aproximado entre las máquinas de la red.
A clock synchronization program should be set up for the network, such as ntpd. Refer to /
usr/share/doc/ntp-<version-number>/index.html for details on setting up Network
Time Protocol servers (where <version-number> is the version number of the ntp package
installed on your system).
• Servicio de Nombre de Dominio (DNS).
You should ensure that the DNS entries and hosts on the network are all properly configured.
Refer to the Kerberos V5 System Administrator's Guide in /usr/share/doc/krb5server-<version-number> for more information (where <version-number> is the
version number of the krb5-server package installed on your system).
3.7.4. Kerberos y PAM
Los servicios kerberizados actualmente no utilizan módulos de autenticación conectables (PAM, por
las siglas en inglés de Pluggable Authentication Modules) — estos servicios evitan completamente
a PAM. Sin embargo, las aplicaciones que utilicen PAM pueden utilizar a Kerberos para autenticarse
si el módulo pam_krb5 (provisto en el paquete pam_krb5) se encuentra instalado. El paquete
pam_krb5 contiene archivos de ejemplos de configuración que permiten que servicios como login
o gdm puedan autenticar usuarios al mismo tiempo que obtienen credenciales de inicio utilizando
sus contraseñas. Si el acceso a los servicios de red es siempre realizado utilizando servicios
kerberizados, o servicios que utilicen GSS-API como por ejemplo lo es IMAP, entonces puede
considerarse a la red como razonablemente segura.
Importante
Los administradores deben tener la precaución de no permitir que los usuarios se autentiquen
a determinados servicios de red, utilizando contraseñas Kerberos. Muchos protocolos
utilizados por estos servicios no encriptan las contraseñas antes de enviarlas a través de la
red, destruyendo los beneficios del sistema Kerberos. Por ejemplo, los usuarios no deberían
tener permitido autenticarse a servicios Telnet con la misma contraseña que utilizan para la
autenticación en Kerberos.
3.7.5. Configurando un servidor Kerberos 5
Cuando se configure Kerberos, primero instale el KDC. Si es necesario configurar servidores
esclavos, instale el maestro primero.
Para configurar el primer KDC de Kerberos, siga estos pasos:
1.
100
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
Configurando un servidor Kerberos 5
no podrán autenticarse en el servidor. Esta sincronización es necesaria para prevenir que un
atacante utilice un comprobante antiguo de Kerberos enmascarado como el de un usuario válido.
It is advisable to set up a Network Time Protocol (NTP) compatible client/server network even if
Kerberos is not being used. Fedora includes the ntp package for this purpose. Refer to /usr/
share/doc/ntp-<version-number>/index.html (where <version-number> is the
version number of the ntp package installed on your system) for details about how to set up
Network Time Protocol servers, and http://www.ntp.org for more information about NTP.
2.
Instale los paquetes krb5-libs, krb5-server y krb5-workstation en la máquina dedicada
que correrá KDC. Esta máquina necesita ser muy segura — si es posible, no debe correr ningún
otro servicio más que KDC.
3.
Edite los archivos de configuración /etc/krb5.conf y /var/kerberos/krb5kdc/kdc.conf
para reflejar el nombre del reinado y los mapeos dominio-a-reinado. Un reinado simple puede
ser construido reemplazando instancias de EJEMPLO.COM y ejemplo.com con el nombre
correcto del dominio — siendo seguro mantener la forma correcta de los nombres en mayúscula
y en mínuscula — y cambiando el KDC de kerberos.elemplo.com al nombre del servidor
kerberos. Por convención, todos los nombres de reinados se escriben en mayúsculas, y todos
los nombres de equipos y de dominios DNS en minúsculas. Para obtener información detallada
acerca de los formatos de estos archivos de configuración, consulte sus respectivas páginas
man.
4.
Genere la base de datos usando el utilitario kdb5_util desde una terminal:
/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.
5.
Edite el archivo /var/kerberos/krb5kdc/kadm5.acl. Este archivo es usado por kadmind
para determinar qué principales tienen acceso administrativo a la base de datos de Kerberos y
sus niveles de acceso. La mayoría de las organizaciones pueden obtenerlo por una única línea:
*/[email protected]
*
Most users are represented in the database by a single principal (with a NULL, or empty,
instance, such as [email protected]). In this configuration, users with a second principal with
an instance of admin (for example, joe/[email protected]) are able to wield full power over
the realm's Kerberos database.
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.
101
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:
/usr/kerberos/sbin/kadmin.local -q "addprinc username/admin"
6.
Inicie Kerberos usando los siguientes comandos:
/sbin/service krb5kdc start
/sbin/service kadmin start
/sbin/service krb524 start
7.
Agregue principales para los usuarios mediante el comando addprinc dentro de kadmin.
kadmin y kadmin.local son interfaces de 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
By default, kinit attempts to authenticate using the same system login username (not
the Kerberos server). If that username does not correspond to a principal in the Kerberos
database, kinit issues an error message. If that happens, supply kinit with the name of
the correct principal as an argument on the command line (kinit <principal>).
Una vez que estos pasos sean completados, el servidor Kerberos ya debería estar listo y
ejecutándose.
3.7.6. Configuración de un Cliente Kerberos 5
Configurar un cliente de Kerberos 5 es menos complicado que configurar un servidor. Como mínimo,
instale los paquetes del cliente y otórguele a cada cliente un archivo de configuración krb5.conf
válido. Mientras que ssh y slogin son los métodos preferidos para loguearse remotamente en
sistemas cliente, las versiones Kerberizadas de rsh y rlogin siguen estando disponibles, aunque
para habilitarlas es necesario realizar algunos cambios adicionales en la configuración.
102
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 3.7.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.
Before a workstation in the realm can use Kerberos to authenticate users who connect using ssh
or Kerberized rsh or rlogin, it must have its own host principal in the Kerberos database. The
sshd, kshd, and klogind server programs all need access to the keys for the host service's
principal. Additionally, in order to use the kerberized rsh and rlogin services, that workstation
must have the xinetd package installed.
Using kadmin, add a host principal for the workstation on the KDC. The instance in this case
is the hostname of the workstation. Use the -randkey option for the kadmin's addprinc
command to create the principal and assign it a random key:
addprinc -randkey host/blah.example.com
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:
ktadd -k /etc/krb5.keytab host/blah.example.com
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 uses GSS-API to authenticate users to servers if the client's and
server's configuration both have GSSAPIAuthentication enabled. If the client also has
GSSAPIDelegateCredentials enabled, the user's credentials are made available on the
remote system.
• rsh y rlogin — Para usar las versiones kerberizadas de rsh y rlogin, habilite klogin,
eklogin y kshell.
• Telnet — Para usar Telnet kerberizado, debe habilitar krb5-telnet.
• FTP — Para proveer acceso FTP, crear y extraer una clave para el principal con una 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 cyrussasl-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).
Una alternativa a cyrus-imap se puede encontrar en el paquete dovecot, que también
se ofrece con Fedora. Este paquete contiene un servidor IMAP pero por el momento no da
soporte ni a GSS-API ni a Kerberos.
103
• 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.
3.7.7. Mapeo dominio-a-reinado
Cuando un cliente intenta acceder a un servicio que corre en un servidor particular, sabe el nombre
del (equipo) del servicio y el nombre del servidor (foo.ejemplo.com), pero como se pueden desplegar
más de un reinado en su red, debe averiguar el nombre del reinado en el que reside el servicio.
Por defecto, el nombre del territorio se toma como el nombre de dominio DNS del servidor, en
mayúsculas.
foo.example.org → EXAMPLE.ORG
foo.example.com → EXAMPLE.COM
foo.hq.example.com → HQ.EXAMPLE.COM
In some configurations, this will be sufficient, but in others, the realm name which is derived will be the
name of a non-existant realm. In these cases, the mapping from the server's DNS domain name to the
name of its realm must be specified in the domain_realm section of the client system's krb5.conf.
For example:
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
The above configuration specifies two mappings. The first mapping specifies that any system in the
"example.com" DNS domain belongs to the EXAMPLE.COM realm. The second specifies that a
system with the exact name "example.com" is also in the realm. (The distinction between a domain
and a specific host is marked by the presence or lack of an initial ".".) The mapping can also be stored
directly in DNS.
3.7.8. Configurando KDCs secundarios
For a number of reasons, you may choose to run multiple KDCs for a given realm. In this scenario,
one KDC (the master KDC) keeps a writable copy of the realm database and runs kadmind (it is
also your realm's admin server), and one or more KDCs (slave KDCs) keep read-only copies of the
database and run kpropd.
El procedimiento de propagación maestro-esclavo requiere que el KDC maestro vuelque su base de
datos a un archivo de volcado temporal y luego transmita ese archivo a cada uno de sus esclavos,
que luego sobreescriben sus copias sólo lectura de la base de datos recibidas antes, con el contenido
del archivo de volcado.
To set up a slave KDC, first ensure that the master KDC's krb5.conf and kdc.conf files are copied
to the slave KDC.
Start kadmin.local from a root shell on the master KDC and use its add_principal command
to create a new entry for the master KDC's host service, and then use its ktadd command to
simultaneously set a random key for the service and store the random key in the master's default
keytab file. This key will be used by the kprop command to authenticate to the slave servers. You will
only need to do this once, regardless of how many slave servers you install.
# kadmin.local -r EXAMPLE.COM
Authenticating as principal root/[email protected] with password.
104
Configurando KDCs secundarios
kadmin: add_principal -randkey host/masterkdc.example.com
Principal "host/host/[email protected]" created.
kadmin: ktadd host/masterkdc.example.com
Entry for principal host/masterkdc.example.com with kvno 3, encryption type Triple DES cbc
mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/masterkdc.example.com with kvno 3, encryption type ArcFour with
HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/masterkdc.example.com with kvno 3, encryption type DES with HMAC/
sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/masterkdc.example.com with kvno 3, encryption type DES cbc mode with
RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab.
kadmin: quit
Start kadmin from a root shell on the slave KDC and use its add_principal command to
create a new entry for the slave KDC's host service, and then use kadmin's ktadd command to
simultaneously set a random key for the service and store the random key in the slave's default keytab
file. This key is used by the kpropd service when authenticating clients.
# kadmin -p jimbo/[email protected] -r EXAMPLE.COM
Authenticating as principal jimbo/[email protected] with password.
Password for jimbo/[email protected]:
kadmin: add_principal -randkey host/slavekdc.example.com
Principal "host/[email protected]" created.
kadmin: ktadd host/[email protected]
Entry for principal host/slavekdc.example.com with kvno 3, encryption type Triple DES cbc
mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/slavekdc.example.com with kvno 3, encryption type ArcFour with HMAC/
md5 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/slavekdc.example.com with kvno 3, encryption type DES with HMAC/sha1
added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/slavekdc.example.com with kvno 3, encryption type DES cbc mode with
RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab.
kadmin: quit
With its service key, the slave KDC could authenticate any client which would connect to it. Obviously,
not all of them should be allowed to provide the slave's kprop service with a new realm database.
To restrict access, the kprop service on the slave KDC will only accept updates from clients whose
principal names are listed in /var/kerberos/krb5kdc/kpropd.acl. Add the master KDC's host
service's name to that file.
# echo host/[email protected] > /var/kerberos/krb5kdc/kpropd.acl
Once the slave KDC has obtained a copy of the database, it will also need the master key which was
used to encrypt it. If your KDC database's master key is stored in a stash file on the master KDC
105
(typically named /var/kerberos/krb5kdc/.k5.REALM, either copy it to the slave KDC using any
available secure method, or create a dummy database and identical stash file on the slave KDC by
running kdb5_util create -s (the dummy database will be overwritten by the first successful
database propagation) and supplying the same password.
Ensure that the slave KDC's firewall allows the master KDC to contact it using TCP on port 754
(krb5_prop), and start the kprop service. Then, double-check that the kadmin service is disabled.
Ahora realice una prueba manual de propagación de la base de datos volcando la base de datos del
reinado, en el KDC maestro, al archivo de datos predeterminado desde donde el comando kprop
leerá (/var/kerberos/krb5kdc/slave_datatrans) y luego use el comando kprop para
transmitir su contenido al KDC esclavo.
# /usr/kerberos/sbin/kdb5_util dump /var/kerberos/krb5kdc/slave_datatrans# kprop
slavekdc.example.com
Usando kinit, verifique que un sistema cliente cuyo krb5.conf liste sólo el KDC esclavo en su
lista de KDCs para su reinado, pueda ahora obtener correctamente las credenciales iniciales del KDC
esclavo.
Hecho esto, simplemente cree un script que vuelque la base de datos del reinado y ejecute el
comando kprop para transmitir la base de datos a cada KDC esclavo por vez, y configure el servicio
cron para correr el script periódicamente.
3.7.9. Configurando la autenticación cruzada de reinados
La autenticación cruzada de reinado es el término usado para describir situaciones en que los clientes
(normalmente usuarios) de un reinado utilizan Kerberos para autenticarse con servicios (típicamente
procesos servidor corriendo en un sistema servidor particular) que pertenecen a otro reinado distinto
al propio.
Para el caso más simple, para que un cliente de un reinado con nombre A.EJEMPLO.COM acceda
a un servicio en el reinado B.EJEMPLO.COM, ambos reinados deben compartir una clave para el
principal con nombre krbtgt/[email protected], y ambas claves deben tener el
mismo número de versión de clave asociadas a ellas.
Para hacer esto, debe seleccionar una contraseña o frase de acceso muy fuerte y crear una entrada
para el principal de ambos reinados usando kadmin.
# kadmin -r A.EXAMPLE.COM kadmin: add_principal krbtgt/[email protected]
Enter password for principal "krbtgt/[email protected]": Re-enter
password for principal "krbtgt/[email protected]": Principal
"krbtgt/[email protected]" created. quit # kadmin -r B.EXAMPLE.COM
kadmin: add_principal krbtgt/[email protected] Enter password for principal
"krbtgt/[email protected]": Re-enter password for principal "krbtgt/
[email protected]": Principal "krbtgt/[email protected]" created. quit
Use el comando get_principal para verificar que ambas entradas tienen un número de versión de
claves (valores kvno) y tipos de encriptados coincidentes.
106
Configurando la autenticación cruzada de reinados
Dumping the Database Doesn't Do It
Security-conscious administrators may attempt to use the add_principal command's randkey option to assign a random key instead of a password, dump the new entry from the
database of the first realm, and import it into the second. This will not work unless the master
keys for the realm databases are identical, as the keys contained in a database dump are
themselves encrypted using the master key.
Los clientes en el reinado A.EJEMPLO.COM son capaces ahora de autenticarse en los servicios del
reinado B.EJEMPLO.COM. Dicho de otra manera, el reinado B.EJEMPLO.COM ahora 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/[email protected] (tome
nota de la forma invertida de acuerdo a los dos reinados comparados en el ejemplo anterior).
If direct trust relationships were the only method for providing trust between realms, networks which
contain multiple realms would be very difficult to set up. Luckily, cross-realm trust is transitive. If
clients from A.EXAMPLE.COM can authenticate to services in B.EXAMPLE.COM, and clients from
B.EXAMPLE.COM can authenticate to services in C.EXAMPLE.COM, then clients in A.EXAMPLE.COM
can also authenticate to services in C.EXAMPLE.COM, even if C.EXAMPLE.COM doesn't directly trust
A.EXAMPLE.COM. This means that, on a network with multiple realms which all need to trust each
other, making good choices about which trust relationships to set up can greatly reduce the amount of
effort required.
Now you face the more conventional problems: the client's system must be configured so that it can
properly deduce the realm to which a particular service belongs, and it must be able to determine how
to obtain credentials for services in that realm.
Vayamos en orden: el nombre del principal para un servicio provisto desde un sistema servidor
específico en un reinado dado normalmente es parecido a:
service/[email protected]
En el ejemplo siguiente, el servicio es generalmente, o bien el nombre del protocolo en uso (otros
valores comunes pueden ser ldap, imap, cvs, y HTTP), o bien equipo. server.ejemplo.com es el
nombre del dominio del sistema completamente calificado que ejecuta el servicio, y EJEMPLO.COM es
el nombre del reinado.
Para deducir el dominio al que el servicio pertenece, los clientes por lo general consultan el DNS o
la sección domain_realm del archivo /etc/krb5.conf para mapear ya sea el nombre del equipo
(server.ejemplo.com) o el nombre del dominio DNS (.ejemplo.com) hacia el nombre del reinado
(EJEMPLO.COM).
Habiendo determinado a qué reinado pertenece el servicio, un cliente tiene que determinar luego el
conjunto de reinados que debe contactar y en qué orden debe hacerlo, para obtener las credenciales
a usar en la autenticación con el servicio.
107
Esto se puede hacer de una o dos formas.
El método establecido por defecto, que no requiere una configuración explícita, es dar a los
reinados nombres dentro de una jerarquía compartida. Como ejemplo, suponer los reinados
llamados A.EJEMPLO.COM, B.EJEMPLO.COM, and EJEMPLO.COM. Cuando un cliente del reinado
A.EJEMPLO.COM intente autenticarse en un servicio del reinado B.EJEMPLO.COM, por defecto, lo
primero que hará será intentar obtener credenciales para el reinado EJEMPLO.COM, y luego utilizar
esas credenciales para obtener unas nuevas para poder utilizarlas en el reinado B.EJEMPLO.COM.
The client in this scenario treats the realm name as one might treat a DNS name. It repeatedly strips
off the components of its own realm's name to generate the names of realms which are "above" it in
the hierarchy until it reaches a point which is also "above" the service's realm. At that point it begins
prepending components of the service's realm name until it reaches the service's realm. Each realm
which is involved in the process is another "hop".
Por ejemplo, el uso de credenciales en A.EJEMPLO.COM, autenticando a un servicio en
B.EJEMPLO.COMA.EJEMPLO.COM → EJEMPLO.COM → B.EJEMPLO.COM
• A.EJEMPLO.COM y EJEMPLO.COM comparten una clave para krbtgt/
[email protected]
• EJEMPLO.COM y B.EJEMPLO.COM comparten una clave krbtgt/
[email protected]
Otro ejemplo, usando credenciales en SITIO1.VENTAS.EJEMPLO.COM, para autenticar a un servicio
en CUALQUIERLUGAR.EJEMPLO.COMSITIO1.VENTAS.EJEMPLO.COM → VENTAS.EJEMPLO.COM
→ EJEMPLO.COM → CUALQUIERLUGAR.EJEMPLO.COM
• SITIO1.VENTAS.EJEMPLO.COM y VENTAS.EJEMPLO.COM comparten una clave para krbtgt/
[email protected]
• VENTAS.EJEMPLO.COM y EJEMPLO.COM comparten una clave para krbtgt/
[email protected]
• EJEMPLO.COM y CUALQUIERLUGAR.EJEMPO.COM comparten una clave para krbtgt/
[email protected]
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/
[email protected]
• EJEMPLO.COM y COM comparten una clave para krbtgt/[email protected]
• COM y ORG comparten una clave para krbtgt/ORG@COM
• ORG y EJEMPLO.ORG comparten una clave para krbtgt/EJEMPLO.ORG@ORG
• EJEMPLO.ORG y PROD.EJEMPLO.ORG comparten una clave para krbtgt/
[email protected]
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.
The format of the capaths section is relatively straightforward: each entry in the section is named
after a realm in which a client might exist. Inside of that subsection, the set of intermediate realms from
108
which the client must obtain credentials is listed as values of the key which corresponds to the realm in
which a service might reside. If there are no intermediate realms, the value "." is used.
Here's an example:
[capaths]
A.EXAMPLE.COM = {
B.EXAMPLE.COM = .
C.EXAMPLE.COM = B.EXAMPLE.COM
D.EXAMPLE.COM = B.EXAMPLE.COM
D.EXAMPLE.COM = C.EXAMPLE.COM
}
En este ejemplo, los clientes en el reinado A.EJEMPLO.COM pueden obtener credenciales de
reinados cruzados para B.EJEMPLO.COM directamente del KDC de A.EJEMPLO.COM.
Si esos clientes desean contactar un servicio en el reinado C.EJEMPLO.COM, necesitarán
obtener primero credenciales necesarias del reinado B.EJEMPLO.COM (esto requiere que
krbtgt/[email protected] exista), y entonces utilizar esas credenciales
para obtener otras para ser utilizadas en el reinado C.EJEMPLO.COM (utilizando krbtgt/
[email protected]).
Si esos clientes desean contactar un servicio en el reinado D.EJEMPLO.COM, necesitarán obtener
primero las credenciales necesarias del reinado B.EJEMPLO.COM, y luego las credenciales del
reinado C.EJEMPLO.COM, antes de obtener, finalmente, las credenciales necesarias para utilizar con
el reinado D.EJEMPLO.COM.
Nota
Sin una entrada que indique lo contrario, Kerberos asume que las relaciones de confianza de
reinados cruzados forman una jerarquía.
Clients in the A.EXAMPLE.COM realm can obtain cross-realm credentials from B.EXAMPLE.COM
realm directly. Without the "." indicating this, the client would instead attempt to use a hierarchical
path, in this case:
A.EXAMPLE.COM → EXAMPLE.COM → B.EXAMPLE.COM
Para más información sobre Kerberos, consulte las fuentes que indicamos a continuación.
3.7.10.1. Documentación Instalada de Kerberos
• The Kerberos V5 Installation Guide and the Kerberos V5 System Administrator's Guide in PostScript
and HTML formats. These can be found in the /usr/share/doc/krb5-server-<versionnumber>/ directory (where <version-number> is the version number of the krb5-server
package installed on your system).
• The Kerberos V5 UNIX User's Guide in PostScript and HTML formats. These can be found in the
/usr/share/doc/krb5-workstation-<version-number>/ directory (where <versionnumber> is the version number of the krb5-workstation package installed on your system).
109
• Páginas man de Kerberos — Hay un número de páginas man para las varias aplicaciones y
archivos de configuración involucrados con una implementación de Kerberos. La siguiente es una
lista de algunas de las páginas man más importantes.
Aplicaciones cliente
• man kerberos — Una introducción al sistema Kerberos que describe cómo funcionan las
credenciales y provee recomendaciones para obtener y destruir tickets de Kerberos. Al final
de la página man hay referencias hacia otras páginas man relacionadas con el tema.
• man kinit — Describe cómo usar este comando para obtener y hacer caché de un ticket
de garantía de tickets.
• man kdestroy — Describe cómo usar este comando para destruir las credenciales de
Kerberos.
• man klist — Describe cómo usar este comando para listar las credenciales cacheadas de
Kerberos.
Aplicaciones administrativas
• man kadmin — Describe cómo usar este comando para administrar con la base de datos de
Kerberos V5.
• man kdb5_util — Describe cómo usar este comando para crear y realizar funciones
administrativas de bajo nivel en la base de datos de Kerberos V5.
Aplicaciones de servidor
• man krb5kdc — Describe las opciones de la línea de comando del KDC de Kerberos V5.
• man kadmind — Describe las opciones de la línea de comando para el servidor de
administración de Kerberos V5.
• 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.
3.7.10.2. Páginas web útiles sobre Kerberos
• http://web.mit.edu/kerberos/www/ — Kerberos: El Protocolo de Autenticación de Red del MIT.
• http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html — Las Preguntas Frecuentes de
Kerberos (FAQ).
• ftp://athena-dist.mit.edu/pub/kerberos/doc/usenix.PS — La versión PostScript de Kerberos: Un
Servicio de Untenticación para Sistemas de Red Abierta por Jennifer G. Steiner, Clifford Neuman,
y Jeffrey I. Schiller. Este documento es el impreso original que describe el funcionamiento de
Kerberos.
• http://web.mit.edu/kerberos/www/dialogue.html — Designing an Authentication System: a Dialogue
in Four Scenes originally by Bill Bryant in 1988, modified by Theodore Ts'o in 1997. This document
is a conversation between two developers who are thinking through the creation of a Kerberos-style
authentication system. The conversational style of the discussion make this a good starting place for
people who are completely unfamiliar with Kerberos.
110
Cortafuegos
• http://www.ornl.gov/~jar/HowToKerb.html — Cómo Kerberizar su sitio es una buena referencia para
kerberizar su red.
• http://www.networkcomputing.com/netdesign/kerb1.html — Manual de Diseño de Red con Kerberos
es un repaso extenso sobre el sistema Kerberos.
3.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, al mismo tiempo que poder identificarlos
y rastrearlos. Fedora ofrece diferentes herramientas para ayudar a los administradores y a los
ingenieros en seguridad, con los diferentes problemas que puedan surgir al controlar los accesos
jerarquizados a la red.
Los cortafuegos son uno de los componentes fundamentales para la 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 3.2, “Tipos de cortafuegos” describe tres tipos comunes de cortafuegos, y cómo funcionan cada
uno de ellos:
Tabla 3.2. Tipos de cortafuegos
Método Descripción
NAT
Network Address
Translation (NAT), coloca
direcciones IP de subredes
privadas, detrás de
un pequeño grupo de
direcciones IP públicas,
enmascarando todas
las peticiones hacia un
recurso, en lugar de varios.
El kernel de Linux tiene
una funcionalidad NAT
predefinida, mediante el
subsistema del kernel
Netfilter.
Filtros
Un cortafuegos de filtro
de
de paquete lee cada uno
Paquete de los datos que viajan a
través de una LAN. Puede
leer y procesar paquetes
según la información de
sus encabezados, y filtrar
el paquete basándose
Ventajas
Desventajas
· Se puede configurar
transparentemente para
máquinas en una LAN.
· La protección de muchas
máquinas y servicios detrás
de una o más direcciones
IP externas simplifica las
tareas de administración.
· La restricción del acceso a
usuarios dentro y fuera de
la LAN se puede configurar
abriendo o cerrando puertos
en el cortafuego/puerta de
enlace NAT.
· No se puede prevenir la
actividad maliciosa una
vez que los usuarios se
conecten a un servicio fuera
del cortafuegos.
· Personalizable a través del
utilitario iptables.
· No necesita cualquier
personalización del lado del
cliente, dado que toda la
actividad de red se filtra en
el nivel del ruteador en vez
de a nivel de aplicación.
· No se pueden filtrar
paquetes para contenidos
como en los cortafuegos
proxy.
· Procesa los paquetes en la
capa del protocolo, pero no
los puede filtrar en la capa
de una aplicación.
111
Método Descripción
Proxy
Ventajas
Desventajas
en un conjunto de
reglas programables
implementadas por
el administrador del
cortafuegos. El kernel
de Linux tiene una
funcionalidad de filtro de
paquetes predefinida,
mediante el subsistema del
kernel Netfilter.
· Debido a que los paquetes
no se transmiten a través de
un proxy, el rendimiento de
la red es más rápida debido
a la conexión directa entre
el cliente y el equipo remoto.
· Las arquitecturas de red
complejas pueden complicar
el armado de las reglas
de filtrado de paquetes,
especialmente si se lo
hace con el enmascarado
de IP o con subredes
locales y redes de zonas
desmilitarizadas.
El cortafuegos proxy filtra
todas las peticiones de
los clientes LAN de un
determinado protocolo, o
tipo, hacia una máquina
proxy, la que luego realiza
esas mismas peticiones
a Internet, en nombre del
cliente local. Una máquina
proxy actúa como un búfer
entre usuarios remotos
maliciosos y la red interna
de máquinas clientes.
· Le da a los
administradores el control
sobre qué aplicaciones y
protocolos funcionan fuera
de la LAN.
· Algunos servidores
proxy, pueden hacer
cache de datos accedidos
frecuentemente en vez de
tener que usar la conexión a
Internet para bajarlos. Esto
ayuda a reducir el consumo
de ancho de banda.
· Los servicios de proxy
pueden ser registrados y
monitoreados más de cerca,
lo que permite un control
más estricto sobre el uso de
los recursos de la red.
· Los proxies son a menudo
específicos a una aplicación
(HTTP, Telnet, etc.), o
restringidos a un protocolo
(la mayoría de los proxies
funcionan sólo con servicios
que usan conexiones TCP).
· Los servicios de aplicación
no se pueden ejecutar
detrás de un proxy, por
lo que sus servidores de
aplicación deben usar
una forma separada de
seguridad de red.
· Los proxies se pueden
volver cuellos de botellas,
dado que todos los pedidos
y transmisiones son
pasados a través de una
fuente, en vez de hacerlo
directamente desde el
cliente al servicio remoto.
3.8.1. Netfilter e IPTables
El kernel de Linux posee un poderoso subsistema de red denominado Netfilter. El subsistema Netfilter
ofrece filtro total o parcial de paquetes, así como servicios de enmascaramiento NAT e IP. Netfilter
también tiene la habilidad de transformar la información de los encabezados IP para enrutamiento
avanzado y administración del estado de la conexión. Netfilter es controlado mediante la utilización de
la herramienta iptables.
3.8.1.1. Introducción a IPTables
El poder y la flexibilidad de Netfilter se implementa utilizando iptables, una herramienta de
administración de línea de comando con sintaxis similar a la de su predecesor, ipchains, la cual
Netfilter/iptables ha reemplazado a partir del kernel LInux 2.4.
iptables utiliza el subsistema Netfilter para incrementar la conexión, inspección y procesamiento
de la red. iptables ofrece registro avanzado, acciones pre y post enrutamiento, traducción de
direcciones de red y reenvío de puerto, todo en una interfaz de línea de comandos.
Esta sección ofrece un resumen acerca de iptables. Para obtener información más detallada,
diríjase a la Sección 3.9, “IPTables”.
112
Configuración básica de un cortafuego
3.8.2. Configuración básica de un cortafuego
Del mismo modo que el extintor de incendios en un edificio intenta prevenir que se propague un
incendio, en una computadora, un cortafuegos intenta prevenir que algún tipo de software malicioso
se propague en su equipo. También ayuda a prevenir que usuarios no autorizados accedan a su
computadora.
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. Este cortafuegos
determina qué servicios en su computadora pueden ser accedidos por usuarios remotos. Un
cortafuegos correctamente configurado puede incrementar enormemente la seguridad de su sistema.
Se recomienda que configure un cortafuegos para cualquier sistema Fedora que tenga una conexión
a Internet.
3.8.2.1. Herramienta de administración de cortafuegos
En el proceso de instalación de Fedora, en la pantalla de Configuración del cortafuego, se le
ofreció la oportunidad de habilitar un cortafuego básico, así como la posibilidad de utilizar ciertos
dispositivos, servicios entrantes y puertos.
Una vez finalizada la instalación, puede modificar las opciones elegidas mediante la utilización de la
Herramienta de administración de cortafuegos.
Para iniciar esta aplicación, use el siguiente comando:
[root@myServer ~] # system-config-firewall
Figura 3.10. Herramienta de administración de cortafuegos
113
Nota
La Herramienta de administración de cortafuegos solo configura un cortafuego básico. Si el
sistema necesita reglas más complejas, diríjase a laSección 3.9, “IPTables” para conocer más
detalles sobre la configuración de reglas específicas de iptables.
3.8.2.2. Habilitando y deshabilitando el cortafuego
Seleccione una de las opciones siguientes para el cortafuego:
• Deshabilitado — Deshabilitar el cortafuegos proporciona un acceso completo a su sistema y no
se realiza ninguna verificación de seguridad. Esto debe ser seleccionado sólo si está ejecutando
una red segura (no Internet), o necesite configurar un cortafuego personalizado utilizando la
herramienta de la línea de comandos iptables.
Advertencia
Las configuraciones del cortafuego y cualquier reglas de cortafuegos personalizadas se
almacenan en el archivo /etc/sysconfig/iptables. Si elije Deshabilitado y hace clic en
Aceptar, estas configuraciones y reglas del cortafuego se 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.
3.8.2.3. Servicios confiables
Habilitando opciones en la lista de Servicios confiables le permite al servicio especificado pasar a
través del cortafuego.
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.
114
Configuración básica de un cortafuego
SSH
Secure Shell (SSH) es una suite de herramientas para registrarse en un equipo remoto y poder
ejecutar comandos en él. Para permitir acceso remoto a una 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.
Mail (SMTP)
SMTP es un protocolo que permite a otras máquinas conectarse directamente con su máquina
para entregar correo. Usted no necesita habilitar este servicio si usted recolecta sus correos
desde el servidor del ISP usando POP3, IMAP o algún otra herramienta como fetchmail. Para
permitir la entrega de correo a su máquina, seleccione esta casilla de verificación. Tenga en
cuenta que un servidor SMTP mal configurado puede permitir a máquinas usar 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 propietario de Microsoft SMB. Si usted
necesita compartir archivos, directorios o impresoras conectadas localmente con máquinas
Microsoft Windows, selecciones esta casilla de verificación.
3.8.2.4. Otros Puertos
La Herramienta de configuración de cortafuegos incluye una sección de Otros puertos para
especificar puertos IP personalizados de modo tal de considerarlos como seguros por iptables.
Por ejemplo, para permitir que protocolos IRC, o de impresión a través de Internet (IPP, por las siglas
en inglés de Internet Printing Protocol) pasen a través del cortafuegos, añada la siguiente línea a la
sección de Other ports:
194:tcp,631:tcp
3.8.2.5. Guardando la configuración
Haga clic en OK para guardar los cambios y activar o desactivar el cortafuegos. Si fue seleccionado
Activar cortafuegos, las opciones seleccionadas serán trasladadas a los comandos iptables y
escritos en el archivo /etc/sysconfig/iptables. El servicio iptables es también iniciado de
modo que el cortafuegos sea activado inmediatamente luego de guardar las opciones seleccionadas.
Si fue seleccionado Desactivar cortafuegos, el archivo /etc/sysconfig/iptables es eliminado
y el servicio iptables es inmediatamente detenido.
Las opciones seleccionadas son también escritas al archivo /etc/sysconfig/system-configsecuritylevel para que la configuración pueda restaurarse la próxima vez que se inicie la
aplicación. No edite este archivo a mano.
Aun si el cortafuegos es activado inmediatamente, el servicio iptables no está configurado para
que se inicie automáticamente durante el arranque del equipo. Vea la Sección 3.8.2.6, “Activando el
servicio IPTables” para obtener más información.
115
3.8.2.6. Activando el servicio IPTables
Las reglas del cortafuego están solamente activas si el servicio iptables se está ejecutando. Para
iniciar manualmente el servicio, use el siguiente comando:
[root@myServer ~] # service iptables restart
Para asegurarse de que iptables se inicie cuando el sistema arranque, use el siguiente comando:
[root@myServer ~] # chkconfig --level 345 iptables on
3.8.3. Uso de IPTables
El primer paso en el uso de iptables es iniciar el servicio iptables. Use el siguiente comando
para iniciar el servicio iptables:
[root@myServer ~] # service iptables start
Nota
El servicio ip6tables puede ser desactivado si usted intenta utilizar solamente el servicio
iptables. Si desactiva el servicio ip6tables, recuerde 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:
[root@myServer ~] # chkconfig --level 345 iptables on
Esto fuerza a iptables a que se inicie cuando el sistema arranque en los niveles de ejecución 3, 4 o
5.
3.8.3.1. Sintaxis de comando de IPTables
El siguiente comando iptables ilustra la sintaxis básica de comandos:
[root@myServer ~ ] # iptables -A <chain> -j <target>
The -A option specifies that the rule be appended to <chain>. Each chain is comprised of one or more
rules, and is therefore also known as a ruleset.
Las tres cadenas predefinidas son INPUT, OUTPUT, y FORWARD. Estas cadenas son permanentes y
no se pueden borrar. La cadena especifica el punto en el que el paquete es manipulado.
The -j <target> option specifies the target of the rule; i.e., what to do if the packet matches the
rule. Examples of built-in targets are ACCEPT, DROP, and REJECT.
Vaya a la página man de iptables para más información sobre las cadenas, opciones y destinos
disponibles.
116
Filtrado común de IPTables
3.8.3.2. Políticas básicas del cortafuego
El establecimiento de políticas básicas de cortafuego crea la base para construir reglas más
detalladas definidas por el usuario.
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.
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:
[root@myServer ~ ] # iptables -P INPUT DROP
[root@myServer ~ ] # iptables -P OUTPUT DROP
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:
[root@myServer ~ ] # iptables -P FORWARD DROP
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.
3.8.3.3. Guardando y restaurando las reglas de IPTables
Los cambios en iptables son transitorios; si el sistema es reiniciado o si el servicio de iptables
es reiniciado, las reglas son automáticamente eliminadas y reiniciadas. Para guardar las reglas de
modo que sean cargadas cuando el servicio iptables sea iniciado, utilice el siguiente comando:
[root@myServer ~ ] # service iptables save
Las reglas se guardan en el archivo /etc/sysconfig/iptables y se aplican cada vez que el
servicio o la computadora se reinician.
3.8.4. Filtrado común de IPTables
La prevención del acceso a la red de atacantes remotos es uno de los aspectos más importantes de
la seguridad de la red. La integridad de la LAN debe protegerse de los usuarios remotos maliciosos a
través del uso de las reglas estrictas de cortafuego.
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:
[root@myServer ~ ] # iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
117
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:
[root@myServer ~ ] # iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
Importante
Cuando se crea un conjunto de reglas de iptables, el orden es importante.
Si una regla especifica que cualquier paquete desde la subred 192.168.100.0/24 debe ignorarse,
y esto es seguido por una regla que permite los paquetes de 192.168.100.13 (que está dentro de
la subred ignorada), la segunda regla se ignora.
La regla para permitir los paquetes de 192.168.100.13 debe estar antes de la que elimina los
restantes de la subred.
Para insertar una regla en una ubicación específica en una cadena existente, use la opción -I.
Por ejemplo:
[root@myServer ~ ] # iptables -I INPUT 1 -i lo -p all -j ACCEPT
Esta regla es insertada como la primera regla en la cadena INPUT para permitir el 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:
[root@myServer ~ ] # iptables -A INPUT -p tcp --dport 22 -j ACCEPT
[root@myServer ~ ] # iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT
Estas reglas permiten ingreso y egreso para un sistema individual, como una PC directamente
conectada a Internet, o a un cortafuegos/puerta de enlace. Sin embrago, no permiten a los nodos
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.
3.8.5. Reglas FORWARD y NAT
La mayoría de los ISPs proveen sólo un número limitado de direcciones IP disponibles públicamente
para sus clientes.
118
Reglas FORWARD y NAT
Los administradores deben, por lo tanto, encontrar formas alternativas de compartir el acceso a
los servicios de Internet, sin darle por ello una 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.
Los enrutadores de borde (como los cortafuegos) pueden recibir transmisiones entrantes desde
Internet y enrutar los paquetes hacia el nodo LAN correspondiente. Al mismo tiempo, los cortafuegos/
puertas de enlace pueden enrutar peticiones salientes de un nodo de la LAN hacia el servicio de
Internet remoto.
This forwarding of network traffic can become dangerous at times, especially with the availability of
modern cracking tools that can spoof internal IP addresses and make the remote attacker's machine
act as a node on your LAN.
Para impedir esto, iptables provee 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:
[root@myServer ~ ] # iptables -A FORWARD -i eth1 -j ACCEPT
[root@myServer ~ ] # iptables -A FORWARD -o eth1 -j ACCEPT
Esta regla le da a los sistemas 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.
119
Nota
Por defecto, la política IPv4 en kernels de Fedora deshabilita el soporte para reenvío de IP. Esto
evita que las máquinas que utilicen Fedora funcionen como un enrutador dedicado. Para habilitar
el reenvío de IP, use el siguiente comando:
[root@myServer ~ ] # sysctl -w net.ipv4.ip_forward=1
Este cambio en la configuración sólo es válido para la sesión actual; no persiste luego de
un reinicio de equipo o del servicio de red. Para poner el reenvío de IP permanente, edite el
archivo/etc/sysctl.conf como sigue:
Ubique la siguiente línea:
net.ipv4.ip_forward = 0
Y edítela para que se lea:
net.ipv4.ip_forward = 1
Use el siguiente comando para habilitar el cambio en el archivo sysctl.conf:
[root@myServer ~ ] # sysctl -p /etc/sysctl.conf
3.8.5.1. Postruteado y enmascarado de IP
Accepting forwarded packets via the firewall's internal IP device allows LAN nodes to communicate
with each other; however they still cannot communicate externally to the Internet.
To allow LAN nodes with private IP addresses to communicate with external public networks, configure
the firewall for IP masquerading, which masks requests from LAN nodes with the IP address of the
firewall's external device (in this case, eth0):
[root@myServer ~ ] # iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
This rule uses the NAT packet matching table (-t nat) and specifies the built-in POSTROUTING
chain for NAT (-A POSTROUTING) on the firewall's external networking device (-o eth0).
POSTROUTING permite que los paquetes sean alterados cuando están dejando el dispositivo
externo del cortafuegos.
El destino -j MASQUERADE se especifica para enmascarar la dirección IP privada de un nodo con la
dirección IP externa del cortafuego/puerta de enlace.
3.8.5.2. Preruteo
Si usted posee un servidor en su red interna que quiere que esté disponible desde el exterior, puede
utilizar -j DNAT, objetivo de la cadena PREROUTING de NAT para especificar una IP de destino,
y un puerto donde los paquetes recibidos que pidan una conexión a su servicio interno, puedan ser
reenviados.
120
Software malicioso y suplantación de direcciones IP
Por ejemplo, si quiere reenviar pedidos HTTP entrantes a su servidor HTTP Apache dedicado en
172.31.0.23, use el siguiente comando:
[root@myServer ~ ] # iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to
172.31.0.23:80
Esta regla especifica que la tabla nat usa la cadena predefinida PREROUTING para enviar pedidos
HTTP entrantes exclusivamente al la 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:
[root@myServer ~ ] # iptables -A FORWARD -i eth0 -p tcp --dport 80 -d 172.31.0.23 -j
ACCEPT
Esta regla reenvía todos los pedidos HTTP entrantes desde el cortafuego al destino pretendido;
el Servidor HTTP APache detrás del cortafuego.
3.8.5.3. IPTables y las ZDM
Puede crear reglas de iptables para enrutar tráfico a ciertos equipos, como por ejemplo un servidor
HTTP o FTP dedicado, en una zona desmilitarizada (DMZ, por las iniciales en inglés de DeMilitarized
Zone). Un DMZ es una subred local especial dedicada a proveer servicios en un transporte público,
como lo es Internet.
Por ejemplo, para establecer una regla para enrutar peticiones HTTP entrantes a un servidor
dedicado HTTP en 10-0-4-2 (fuera del rango 192.168.1.0/24 de la LAN), NAT utiliza la tabla
PREROUTING para reenviar los paquetes a la dirección apropiada:
[root@myServer ~ ] # iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --todestination 10.0.4.2:80
Con este comando, todas las conexiones HTTP al puerto 80 provenientes desde fuera de la LAN
son encaminadas al servidor HTTP en la red separada del resto de la red interna. Esta forma de
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.
3.8.6. Software malicioso y suplantación de direcciones IP
Reglas más elaboradas pueden ser creadas para que controlen el acceso a subredes específicas,
o incluso para nodos específicos, dentro de la LAN. Puede también restringir ciertas aplicaciones o
programas de carácter dudoso como troyanos, gusanos, y demás virus cliente/servidor, y evitar que
entren en contacto con sus servidores.
Por ejemplo, algunos troyanos examinan redes para ver los servicios en los puertos 31337 a 31340
(llamados los puertos elite en la terminología de craqueo).
121
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.
[root@myServer ~ ] # iptables -A FORWARD -s 192.168.1.0/24 -i eth0 -j DROP
Nota
Existe una distinción entre los destinos DROP y REJECT cuando se trabaja con reglas agregadas.
El destino RECHAZAR niega acceso y regresa un error de conexión denegada a los usuarios
que intenten conectarse al servicio. El destino ABANDONAR, como su nombre lo indica, abandona
el paquete sin previo aviso.
Los administradores pueden usar su propia 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.
3.8.7. IPTables y el seguimiento de la conexión
Puede inspeccionar y restringir conexiones a servicios basados en sus estados de conexión. Un
módulo dentro de iptables utiliza un método denominado rastreo de conexión para almacenar
datos acerca de las conexiones recibidas. Puede permitir o negar acceso basándose en los siguientes
estados de conexión:
• NEW — Un paquete que pide una nueva conexión, tal como un pedido HTTP.
• ESTABLISHED — Un paquete que es parte de una conexión existente.
• 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).
• INVALID — Un paquete que no es parte de ninguna conexión en la tabla de seguimiento de
conexiones.
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
122
IPv6
muestra una regla que utiliza rastreo de conexión para reenviar solamente los paquetes que están
asociados con una conexión establecida:
[root@myServer ~ ] # iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
3.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 14, 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:
[root@myServer ~ ] # ip6tables -A INPUT -i eth0 -p tcp -s 3ffe:ffff:100::1/128 --dport 22 -j
ACCEPT
Para más información acerca de redes IPv6, vaya a la Página de Información sobre IPv6 en http://
www.ipv6.org/.
Hay varios aspectos de cortafuegos y del subsistema Netfilter de Linux que no pueden ser cubiertos
en este capítulo. Para más información consulte las referencias que ofrecemos a continuación.
3.8.9.1. Documentación instalada del cortafuego
• Diríjase a la Sección 3.9, “IPTables” para obtener información más detallada del comando
iptables, incluyendo definiciones de muchas opciones de comando.
• La página man de iptables contiene un resumen de las opciones.
3.8.9.2. Sitios web útiles de cortafuego
• http://www.netfilter.org/ — La página oficial del proyecto Netfilter e iptables.
• http://www.tldp.org/ — El Proyecto de Documentación de Linux contiene varias guías útiles sobre la
creación y administración de cortafuegos.
• http://www.iana.org/assignments/port-numbers — La lista oficial de puertos de servicios comunes y
registrados, según fueron asignados por IANA (Internet Assigned Numbers Authority).
3.8.9.3. Documentación relacionada
• Red Hat Linux Firewalls, por Bill McCarty; Red Hat Press — un manual de referencia completo para
poder levantar cortafuegos de red o de servidores, utilizando tecnología de código abierto para
filtrado de paquetes, como por ejemplo Netfilter o iptables. Los temas que se tratan van desde
el análisis de logs de cortafuegos, desarrollo de reglas de cortafuegos, y diferentes métodos de
personalización del cortafuegos utilizando numerosas herramientas gráficas.
123
• 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.
3.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.
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 3.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.
La funcionalidad de ipchains no es afectada por estos errores.
3.9.1. Filtrado de Paquete
El kernel de Linux utiliza la herramienta Netfilter para filtrar los paquetes, permitiendo que alguno de
ellos sean recibidos por el sistema (o que pasen a través de él), y evitando que lo hagan otros. Esta
herramienta está predefinida en el kernel, y posee tres tablas o listas de reglas predeterminadas de la
forma siguiente:
• filter — La tabla predeterminada para el manejo de paquetes de red.
• nat — Se usa para alterar paquetes que crean una nueva conexión y para Network Address
Translation (NAT).
• mangle — Usada para tipos específicos de alteraciones de paquetes.
Cada tabla tiene un grupo de cadenas predefinidas, que corresponden a las acciones realizadas por
netfilter sobre el paquete.
Las cadenas predefinidas para la tabla filter son las siguientes:
• INPUT — Se aplica a paquetes de red que son destinados a este equipo.
• OUTPUT — Se aplica a paquetes de red generados localmente.
124
Filtrado de Paquete
• FORWARD — Se aplica a paquetes de la red ruteados a través de este equipo.
Las cadenas predeterminadas para la tabla nat son las siguientes:
• PREROUTING — Altera los paquetes de la red cuando llegan.
• OUTPUT — Altera los paquetes de la red generados localmente antes de que se envíen.
• POSTROUTING — Altera los paquetes de la red antes de ser enviados.
Las cadenas predeterminadas para la tabla mangle son:
• INPUT — Altera los paquetes de red destinados a este equipo.
• OUTPUT — Altera los paquetes de la red generados localmente antes de que se envíen.
• FORWARD — Altera los paquetes de red ruteados a través de este equipo.
• PREROUTING — Altera los paquetes que vienen de la red antes de ser ruteados.
• POSTROUTING — Altera los paquetes de la red antes de ser enviados.
Cada paquete de red recibido por, o enviado con un sistema Linux es sujeto de (o por) al menos
una tabla. Sin embargo, un paquete puede ser sujeto por varias reglas pertenecientes a cada tabla,
antes de poder emerger al final de la cadena. La estructura y el 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.
El servicio iptables se activa antes que cualquier otro servicio relacionado con DNS, cuando
el sistema Linux es iniciado. Esto significa que las reglas de cortafuegos pueden sólo hacer
referencia a direcciones IP numéricas (como por ejemplo, 192.168.0.1). En este tipo de reglas,
los nombres del dominio (por ejemplo, host.example.com) producen errores.
Regardless of their destination, when packets match a particular rule in one of the tables, a target
or action is applied to them. If the rule specifies an ACCEPT target for a matching packet, the packet
skips the rest of the rule checks and is allowed to continue to its destination. If a rule specifies a DROP
target, that packet is refused access to the system and nothing is sent back to the host that sent the
packet. If a rule specifies a QUEUE target, the packet is passed to user-space. If a rule specifies the
optional REJECT target, the packet is dropped, but an error packet is sent to the packet's originator.
Cada cadena posee una 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.
125
3.9.2. Opciones de la línea de comandos de IPTables
Las reglas para el filtrado de paquetes se crean usando el comando iptables. Los aspectos
siguientes del paquete son los más usados como criterios:
• Tipo de Paquete — Especifica el tipo de paquete que filtra el comando.
• Fuente/Destino del Paquete — Especifica qué paquete se filtra basado en el fuente/destino del
paquete.
• Destino — Especifica qué 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 3.9.2.4, “Opciones de coincidencia de IPTables” y la
Sección 3.9.2.5, “Opciones de destino”.
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.
3.9.2.1. Estructura de las opciones de comandos de IPTables
Muchos comandos iptables tienen la siguiente estructura:
iptables [-t <table-name>] <command> <chain-name> \ <parameter-1> <option-1> \ <parametern> <option-n>
<table-name> — Especifica la tabla donde la regla aplica. Si es omitida, la tabla filter es usada.
<command> — Especifica la acción a efectuar, tal como agregar o eliminar una regla.
<chain-name> — Especifica la cadena a editar, crear o eliminar.
<parameter>-<option> pairs — Parameters and associated options that specify how to process a
packet that matches the rule.
La longitud y complejidad de un comando iptables puede cambiar significativamente, basado en su
propósito.
Por ejemplo, un comando para eliminar una regla de una cadena puede ser muy corto:
iptables -D <chain-name> <line-number>
En contraste, un comando que 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.
126
Opciones de la línea de comandos de IPTables
3.9.2.2. Opciones de comandos
Las opciones de comando dan instrucciones a iptables para que realice una acción específica.
Solo una opción de comando es permitida para cada comando iptables. Con la excepción del
comando help, todos los demás deben ser escritos con caracteres mayúsculos.
Los comandos de iptables son los siguientes:
• -A — Agregan una regla al final de la cadena especificada. A diferencia de la opción -I descripta
más abajo, No toma un entero como argumento. Siempre agrega la regla al final de la cadena
especificada.
• -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.
• -D <integer> | <rule> — Deletes a rule in a particular chain by number (such as 5 for the fifth
rule in a chain), or by rule specification. The rule specification must exactly match an existing rule.
• -E — Renombra una cadena definida por el usuario. Una cadena definida por el usuario es
cualquier cadena que no sea una de las ya existentes, establecidas por defecto. (Vea 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.
• -F — Limpia la cadena seleccionada, lo que efectivamente borra cada regla en la cadena. Si no se
especifica una cadena, limpia todas las reglas de cada cadena.
• -h — Provee una lista de estructuras de comando, así como un resumen rápido de los parámetros
y opciones de los comandos.
• -I [<integer>] — Inserts the rule in the specified chain at a point specified by a user-defined
integer argument. If no argument is specified, the rule is inserted at the top of the chain.
Importante
Como se mencionó arriba, el orden de las reglas en una cadena determina 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.
Esto es especialmente importante cuando se agregan reglas utilizando la opción -I con un
argumento entero. Si especifica un número existente cuando agregue una regla a una cadena,
iptables añade la nueva regla antes que (o sobre) la regla existente.
127
• -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:
iptables -L <chain-name> -t <table-name>
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 3.9.2.6, “Opciones de
listado”.
• -N — Crea una nueva cadena con un nombre dado por el usuario. El nombre debe ser único, sino
se mostrará un mensaje de error.
• -P — Pone la 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.
• -R — Replaces a rule in the specified chain. The rule's number must be specified after the chain's
name. The first rule in a chain corresponds to rule number one.
• -X — Borra una cadena definida por el usuario. No se puede borrar una cadena predefinida.
• -Z — Pone los contadores de bytes y de paquetes a 0 en todas las cadenas de una tabla.
3.9.2.3. Opciones de parámetros de IPTables
Ciertos comandos de iptables, incluyen aquellos para agregar, adjuntar, borrar, insertar o borrar
reglas dentro de una cadena particular, que requieren varios parámetros para construir una regla de
filtrado de paquetes.
• -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:
• N.N.N.N/M.M.M.M — Donde N.N.N.N es el rango de direcciones IP y M.M.M.M es la máscara
de red.
• N.N.N.N/M — Donde N.N.N.N es el rango de direcciones IP y M son los bits de máscara.
• -f — Aplica esta regla sólo a paquetes fragmentados.
Puede usar el signo de exclamación (!) después de este parámetro para especificar que solamente
se aceptan paquetes desfragmentados.
128
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.
Originally designed to allow IP packets to travel over networks with differing frame sizes,
these days fragmentation is more commonly used to generate DoS attacks using mal-formed
packets. It's also worth noting that IPv6 disallows fragmentation entirely.
• -i — Establece la interfaz de red entrante, como ser por ejemplo, eth0 o ppp0. Con iptables,
este 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.
Este parámetro también da soporte a todas las siguientes opciones especiales:
• El signo de exclamación (!) — Revierte la directiva, significando que las interfaces especificadas
de excluyen de esta regla.
• 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.
• -j — Salta al destino especificado si un paquete coincide con una regla en particular.
Los destinos estándares son ACCEPT, DROP, QUEUE, y RETURN.
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> — Sets the IP protocol affected by the rule. This can be either icmp, tcp, udp, or
all, or it can be a numeric value, representing one of these or a different protocol. You can also use
any protocols listed in the /etc/protocols file.
129
The "all" protocol means the rule applies to every supported protocol. If no protocol is listed with
this rule, it defaults to "all".
• -s — Pone el fuente de un paquete particular usando la misma sintaxis del parámetro de destino (d).
3.9.2.4. Opciones de coincidencia de IPTables
Different network protocols provide specialized matching options which can be configured to match a
particular packet using that protocol. However, the protocol must first be specified in the iptables
command. For example, -p <protocol-name> enables options for the specified protocol. Note that
you can also use the protocol ID, instead of the protocol name. Refer to the following examples, each
of which have the same effect:
iptables -A INPUT -p icmp --icmp-type any -j ACCEPT
iptables -A INPUT -p 5813 --icmp-type any -j ACCEPT
Las definiciones de los servicios son provistas en el archivo /etc/services. Para una mejor
lectura, es recomendable que se utilice el nombre de los servicios, en lugar de los 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:
[root@myServer ~]# chown root.root /etc/services
[root@myServer ~]# chmod 0644 /etc/services
[root@myServer ~]# chattr +i /etc/services
Esto previene que se pueda renombrar, borrar o crear enlaces al archivo.
3.9.2.4.1. Protocolo TCP
Estas opciones de comparación están disponibles para el protocolo TCP (-p tcp):
• --dport — Pone el puerto destino del paquete.
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.
130
Para navegar por los nombres o alias de servicios de red y sus números de puerto, vea el archivo /
etc/services.
La opción --destination-port es sinónimo de --dport.
• --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> — Allows TCP packets that have
specific bits (flags) set, to match a rule.
La opción de correspondencia --tcp-flags acepta dos parámetros. El primero es la máscara;
una lista separada por comas de las marcas a ser examinadas en el paquete. El segundo
parámetro es una lista separada por comas de las marcas que deben ser definidas en la regla con
la que se pretende concordar.
Las posibles banderas son:
• ACK
• FIN
• PSH
• RST
• SYN
• URG
• ALL
• NONE
Por ejemplo, una regla iptables que contenga las siguientes especificaciones solo se
corresponderá con paquetes TCP que tengan definida la marca SYN, y que no tengan definidas las
marcas ACK ni FIN:
--tcp-flags ACK,FIN,SYN SYN
Use el signo de exclamación (!) después de --tcp-flags para revertir el efecto de coincidencia
de la opción.
• --tcp-option — Intenta corresponderse con opciones específicas de TCP que puedan
establecerse dentro de un paquete determinado. Esta opción de correspondencia puede también
revertirse con el signo de exclamación (!).
3.9.2.4.2. Protocolo UDP
Estas opciones de coincidencias están disponibles para el protocolo UDP (-p udp):
131
• --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 --sourceport 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.
3.9.2.4.3. Protocolo ICMP
Las siguientes opciones de coincidencias están disponibles en el Protocolo de Mensajes de Control
de Internet (ICMP) (-p icmp):
• --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.
3.9.2.4.4. Módulos adicionales para opciones de coincidencia
Opciones de coincidencias adicionales están disponibles a través de los módulos cargados por el
comando iptables.
To use a match option module, load the module by name using the -m <module-name>, where
<module-name> is the name of the module.
Por defecto hay disponibles muchos módulos. También puede crear módulos para proveer
funcionalidad adicional.
La siguiente es una lista parcial de los módulos más comúnmente usados:
• 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 3.9.2.5, “Opciones de destino” para obtener mayor información sobre LOG.
El módulo limit habilita las siguientes opciones:
• --limit — Sets the maximum number of matches for a particular time period, specified as a
<value>/<period> pair. For example, using --limit 5/hour allows five rule matches per
hour.
Los períodos se pueden especificar en segundos, minutos, horas o días.
Si no se utiliza un número o modificador de tiempo, se asume el valor predeterminado de 3/
hora.
• --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.
132
Si no se especifica un valor, el valor predeterminado cinco (5) es asumido.
• Módulo state — Habilita el chequeo del estado.
El módulo state habilita las siguientes opciones:
• --state — chequea a un paquete con los siguientes estados de conexión:
• ESTABLISHED — El paquete está asociado a otros paquetes en una conexión establecida.
Necesita aceptar este estado si quiere mantener una conexión entre un cliente y un servidor.
• INVALID — El paquete es chequeado no está asociado a una conexión conocida.
• 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).
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.
• Módulo mac — Habilita el chequeo de la dirección MAC de hardware.
El módulo mac habilita la siguiente opción:
• --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.
3.9.2.5. Opciones de destino
Cuando un paquete concuerde con una regla en particular, la regla puede dirigir el paquete hacia un
número de destinos diferentes determinados por la acción apropiada. Cada cadena tiene un objetivo
establecido por defecto, que será utilizado si ninguna de las reglas en esa cadena concuerdan con un
paquete, o si ninguna de las reglas que concuerdan con el paquete especifica un destino.
Los siguientes son los destinos estándares:
• <user-defined-chain> — A user-defined chain within the table. User-defined chain names must
be unique. This target passes the packet to the specified chain.
• ACCEPT — Permite pasar al paquete a su destino o a otra cadena.
• DROP — Descarta el paquete sin responder. El sistema que mandó el paquete no es notificado de la
falla.
• QUEUE — El paquete es encolado para su manejo por una 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
133
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 3.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.
Hay opciones adicionales que se pueden usar después del destino LOG para especificar la forma en
que se realiza el log:
• --log-level — Pone la prioridad de registrado del evento. Vaya a la página man de
syslog.conf para una lista de los niveles de prioridad.
• --log-ip-options — Registra todas las opciones puestas en la cabecera de un paquete IP.
• --log-prefix — Pone una cadena de hasta 29 caracteres antes de la 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 logprefix.
• --log-tcp-options — Registra todas las opciones puestas en la cabecera de un paquete
TCP.
• --log-tcp-sequence — Escribe el número de secuencia de un paquete en el log.
• REJECT — Envía un paquete de error como respuesta al sistema remoto y descarta el paquete.
The REJECT target accepts --reject-with <type> (where <type> is the rejection type)
allowing more detailed information to be returned with the error packet. The message portunreachable is the default error type given if no other option is used. Refer to the iptables man
page for a full list of <type> options.
Otras extensiones de 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.
3.9.2.6. Opciones de listado
The default list command, iptables -L [<chain-name>], provides a very basic overview of the
default filter table's current chains. Additional options provide more information:
134
Guardando las reglas de IPTalbes
• -v — Muestra 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.
• --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 la tabla. Si es omitida, se predetermina la tabla
filter,
3.9.3. Guardando las reglas de IPTalbes
Las reglas creadas con el comando iptables son almacenadas en la memoria. Si el sistema es
reiniciado antes de guardar el conjunto de reglas de iptables, estas reglas se perderán. Para que
las reglas de netfilter sigan vigentes luego de reiniciar el sistema, necesitan ser guardadas. Para
salvar reglas de netfilter, ingrese el siguiente comando como usuario root:
/usr/libexec/iptables.init save
Esto ejecuta el programa init de iptables, que a su vez ejecuta el programa /sbin/iptablessave y escribe la 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/iptablesrestore.
While it is always a good idea to test a new iptables rule before committing it to the /etc/
sysconfig/iptables file, it is possible to copy iptables rules into this file from another system's
version of this file. This provides a quick way to distribute sets of iptables rules to multiple
machines.
Importante
Si va a distribuir el archivo /etc/sysconfig/iptables a otras máquinas, debe teclear /
sbin/service iptables restart para que las nuevas reglas tengan efecto.
135
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í.
3.9.4. Programas de control de IPTables
Hay dos métodos básicos de controlar iptables en Fedora:
• Firewall Administration Tool (system-config-firewall) — A graphical interface for creating,
activating, and saving basic firewall rules. Refer to Sección 3.8.2, “Configuración básica de un
cortafuego” for more information.
• /sbin/service iptables <option> — Used to manipulate various functions of iptables
using its initscript. The following options are available:
• start — Si el cortafuego está configurado (es decir, /etc/sysconfig/iptables existe), se
detienen todos los iptables completamente y se los vuelve a iniciar con el comando /sbin/
iptables-restore. Esta opción funciona solamente si el módulo de kernel ipchains no es
cargado. Para chequear si este módulo está cargado, teclee el siguiente comando como root:
[root@MyServer ~]# lsmod | grep ipchains
Si este comando no muestra salida, significa que no está cargado. Si es necesario, use el
comando /sbin/rmmod para eliminar el 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.
Si la directiva IPTABLES_SAVE_ON_STOP del archivo de configuración /etc/sysconfig/
iptables-config es alterada de su valor original a yes, las reglas actuales serán guardadas
en /etc/sysconfig/iptables y todas las reglas existentes serán trasladadas a /etc/
sysconfig/iptables.save.
Diríjase a la Sección 3.9.4.1, “Archivo de Configuración de los Scripts de Control de IPTables”
para obtener mayor información sobre el archivo iptables-config.
• restart — Si un cortafuegos está ejecutándose, sus reglas en la memoria serán eliminadas,
y el cortafuegos es iniciado nuevamente si es que está configurado en /etc/sysconfig/
iptables. Esta opción solo funciona si el módulo ipchains del kernel no está cargado.
Si la directiva IPTABLES_SAVE_ON_RESTART en el archivo de configuración /etc/
sysconfig/iptables-config es alterada de su valor original a yes, las reglas actuales
serán guardadas en /etc/sysconfig/iptables y cualquier otra regla existente será
trasladada a /etc/sysconfig/iptables.save.
Diríjase a la Sección 3.9.4.1, “Archivo de Configuración de los Scripts de Control de IPTables”
para obtener mayor información sobre el archivo iptables-config.
• status — Muestra el estado del cortafuego y lista todas las reglas activas
136
Programas de control de IPTables
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 3.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.
• save — Guarda las reglas del cortafuego en /etc/sysconfig/iptables utilizando
iptables-save. Vea en la Sección 3.9.3, “Guardando las reglas de IPTalbes” más información.
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 3.9.5, “IPTables e IPv6”.
3.9.4.1. Archivo de Configuración de los Scripts de Control de IPTables
El comportamiento de los scripts de inicio de iptables se controlan por el archivo de configuración /
etc/sysconfig/iptables-config. La siguiente es una lista de las directivas contenidas en este
archivo:
• IPTABLES_MODULES — Especifica una lista separada por comas de los módulos iptables
adicionales a cargar cuando se active el cortafuego. Estos pueden incluir el rastreo de conexión y
ayudantes NAT.
• IPTABLES_MODULES_UNLOAD — Descarga los módulos al reiniciar y detener. Esta directiva acepta
los siguientes valores:
• 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.
• IPTABLES_SAVE_ON_STOP — Guarda las reglas actuales en /etc/sysconfig/iptables
cuando el cortafuego es detenido. Esta directiva acepta los siguientes valores:
• yes — Guarda las reglas existentes en /etc/sysconfig/iptables cuando se detiene el
cortafuego, moviendo la versión previa al archivo /etc/sysconfig/iptables.save.
• no — El valor por defecto. No guarda las reglas existentes cuando el cortafuego es detenido.
• IPTABLES_SAVE_ON_RESTART — Guarda las reglas actuales del cortafuego cuando es reiniciado.
Esta directiva acepta los siguientes valores:
• yes — Guarda las reglas existentes en /etc/sysconfig/iptables cuando el cortafuego es
reiniciado, moviendo la versión previa al archivo /etc/sysconfig/iptables.save.
137
• no — El valor predeterminado. No guarda las reglas existentes cuando se reinicia el cortafuego.
• IPTABLES_SAVE_COUNTER — Guarda y restaura todos los contadores de paquetes y de bytes en
todas las cadenas y reglas. Esta directiva acepta los siguientes valores:
• yes — Guarda los valores de los contadores.
• no — El valor predeterminado. No guarda los valores de los contadores.
• IPTABLES_STATUS_NUMERIC — Muestra las direcciones IP en formato numérico en vez de
dominios y nombres de equipo. Esta directiva acepta los siguientes valores:
• yes — El valor predeterminado. Solo devuelve la dirección IP dentro de una salida de estado.
• no — Devuelve el dominio o nombres de equipos en una salida de estado.
3.9.5. IPTables e IPv6
El paquete iptables incluye soporte para el protocolo de Internet de próxima generación IPv6. El
comando empleado para manipular el netfilter de IPv6 es ip6tables.
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 reglas de ip6tables se guardan en el archivo /etc/sysconfig/ip6tables. Las reglas
previas guardadas antes por los scripts de inicio de ip6tables se guardan en el archivo /etc/
sysconfig/ip6tables.save.
Las opciones de 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.
Por ejemplo, la directiva IPTABLES_MODULES de iptables-config: el equivalente en el archivo
ip6tables-config es IP6TABLES_MODULES.
Consulte las siguientes referencias para obtener información adicional sobre el filtrado de paquetes
con iptables.
• Sección 3.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.
3.9.6.1. Documentación instalada de IPTables
• man iptables — Contiene la descripción de iptables así como una lista comprensiva de los
destinos, opciones y extensiones de comparación.
3.9.6.2. Sitios web útiles sobre IPTables
• http://www.netfilter.org/ — El hogar del proyecto netfilter/iptables. Contiene información ordenada
acerca de iptables, incluyendo un FAQ que describe problemas específicos, y varias guías
útiles realizadas por Rusty Russell, el encargado del cortafuegos para IP de Linux. Los diferentes
138
tutoriales del sitio abarcan diferentes temas, como ser por ejemplo, una descripción de los
conceptos básicos de trabajo en redes, filtros de paquetes del kernel y configuraciones NAT.
139
140
Cifrado
Existen dos clases principales de datos que deben ser protegidos: datos en reposo y datos en
movimiento. Estas clases de datos son protegidas en forma similar utilizando 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.
4.1. Datos en reposo
Data at rest is data that is stored on a hard drive, tape, CD, DVD, disk, or other media. This
information's biggest threat comes from being physically stolen. Laptops in airports, CDs going
through the mail, and backup tapes that get left in the wrong places are all examples of events where
data can be compromised through theft. If the data was encrypted on the media then you wouldn't
have to worry as much about the data being compromised.
4.1.1. Cifrado completo del disco
El cifrado de la partición o del disco completo es una de las mejores formas de proteger sus datos. No
solo está protegido cada archivo, sino que también el almacenamiento temporal que podría contener
parte de estos archivos protegidos. El cifrado de disco completo protegerá todos sus archivos, así que
no tendrá que preocuparse de seleccionar qué archivos proteger y posiblemente olvidando alguno.
Desde la 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.
4.1.2. Cifrado basado en archivo
GnuPG (GPG) es una versión de código abierto de PGP, que le permite firmar y/o cifrar un archivo
o mensaje de correo electrónico. Esto es útil para mantener la integridad del mensaje o del archivo,
y también protege la confidencialidad de la información contenida. En el caso del correo electrónico,
GPG brinda una protección doble. No solo puede proveer protección para los datos en reposo, sino
también para los datos en movimiento, luego que el mensaje ha sido enviado a través de la red.
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.
141
Capítulo 4. Cifrado
4.2. Datos en movimiento
Los datos en movimiento son datos que están siendo transmitidos en una red. La mayor amenaza a
este tipo de datos son las intercepciones y alteraciones que puedan sufrir. Los datos de su nombre de
usuario y contraseña nunca deberían ser transmitidos en una red sin que viajen protegidos, ya que
podrían ser interceptados, y de este modo permitir que alguien se haga pasar por usted, o que pueda
obtener acceso a información importante. Otro tipo de información privada, como son por ejemplo
los datos de una cuenta bancaria, deberían también ser protegidos cada vez que sean transmitidos
a través de una red. Si lo que se cifra es la sesión entera de red iniciada, entonces no tiene que
preocuparse acerca de posibles ataques a los datos que se transmitan en ella.
Los datos en movimiento son particularmente vulnerables a los atacantes, ya que ellos no necesitan
estar cerca de la computadora en donde estos datos son almacenados: simplemente necesitan estar
en 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.
4.2.1. Redes privadas virtuales (VPNs, por las iniciales en inglés de
Virtual Private Networks)
Las organizaciones con diferentes oficinas satélites, a menudo se conectan entre ellas mediante
líneas constituidas específicamente para proteger los datos vitales y asegurar la eficacia en su
transferencia. Por ejemplo, muchos comercios utilizan líneas de frame relay o Modo de Transferencia
no Sincronizada (ATM, por las iniciales en inglés de Asynchronous Transfer Mode) como una
herramienta de comunicaciones de tipo punto-a-punto para enlazar una oficina con el resto. Este
puede llegar a ser un recurso algo costoso, especialmente para pequeñas o medianas empresas,
que quieren expandirse sin tener que pagar los altos costos que involucra la utilización de circuitos
digitales a medida, generalmente utilizados por empresas de mayor poder adquisitivo.
Para poder cubrir estas necesidades, se han desarrollado las Redes Privadas Virtuales (VPNs).
Utilizando los mismos principios de funcionamiento que los circuitos a medida, las VPNs permiten
comunicaciones digitales seguras entre dos elementos (o redes), creando una Red de Area Global
(WAN, por las iniciales en inglés de Wide Area Network) a partir de Redes de Area Local (LANs, Local
Area Networks) existentes. La diferencia entre frame relay o ATM reside en el medio de transporte
que se utiliza. Las VPNs transmiten sobre IP mediante la utilización de datagramas como su medio de
transporte, convirtiéndolas en un conducto seguro a través de Internet hacia un destino específico. La
mayoría de las implementaciones VPN de software libre incorporan estándares abiertos de métodos
de encriptación para, posteriormente, enmascarar los datos en tránsito.
Algunas organizaciones utilizan herramientas VPN de hardware para incrementar la seguridad,
mientras que otras utilizan software, o implementaciones derivadas en protocolos. Muchos
proveedores ofrecen herramientas VPN de hardware, como Cisco, Nortel, IBM y Checkpoint. Existe
una herramienta gratuita de software VPN para Linux denominada FreeS/Wan que utiliza una
implementación estandarizada del Protocolo de Seguridad de Internet (IPsec, por las iniciales en
inglés de Internet Protocol Security). Estas herramientas VPN, ya sean derivadas de hardware o
de software, trabajan como enrutadores especializados que existen entre la conexión IP desde una
oficina hacia otra.
4.2.1.1. ¿Cómo funciona una VPN?
Cuando un paquete se transmite desde un cliente, se envía a través del enrutador o puerta de enlace
VPN, que le añade un Encabezado de autenticación (AH, por las iniciales en inglés de Authentication
Header) para su enrutamiento y autenticación. Los datos son entonces encriptados y, por último,
empaquetados con una Carga Util de Seguridad por Encapsulado (ESP, por las inicales en inglés de
Encapsulating Security Payload). Esto, más adelante, constituye las instrucciones de desencriptado y
entrega.
142
Redes privadas virtuales (VPNs, por las iniciales en inglés de Virtual Private Networks)
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.
4.2.1.2. VPNs y Fedora
Fedora ofrece varias opciones en términos de implementar herramientas de software para conectarse
de manera segura en una WAN. La utilización de Protocolos de Seguridad de Internet (IPsec), es la
herramienta VPN que para ello se utiliza en Fedora, y cubre adecuadamente las necesidades de las
organizaciones que posean oficinas sucursales, o usuarios remotos.
4.2.1.3. IPsec
Fedora ofrece soporte de IPsec para conectar equipos remotos y redes entre sí, utilizando un 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 reda-red (una LAN/WAN con otra).
La utilización de IPsec en Fedora utiliza Intercambio de llave 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.
4.2.1.4. Creando una conexión IPsec
Una conexión IPsec está dividida en dos fases lógicas. En la fase 1, un nodo IPsec inicializa la
conexión con una red o nodo remoto. La red o nodo remoto verifica las credenciales del modo
solicitante y ambas partes negocian el método de autenticación para la conexión.
En sistemas fedora, una conexión IPsec utiliza un método de llave pre-compartida para la
autenticación del nodo IPsec. En una conexión IPsec de este tipo, ambos equipos deben utilizar la
misma clave para poder avanzar hacia la segunda etapa de la conexión IPsec.
La segunda etapa de la conexión IPsec consiste en la creación de una Asociación de seguridad (SA,
por las iniciales en inglés de Security Association) entre los nodos IPsec. Esta etapa genera una
base de datos SA con información de configuración, como el método de encriptado, los parámetros
de intercambio de clave para la sesión secreta, y demás informaciones necesarias. Esta etapa
administra la conexión IPsec actual entre los nodos remotos y las redes.
La implementación de IPsec en Fedora utiliza IKE para compartir llaves entre equipos a través de
Internet. El demonio para llaves racoon administra la distribución y el intercambio de llave IKE. Para
obtener mayor información acerca de este demonio, vea la página man de racoon.
4.2.1.5. Instalación de IPsec
La implementación de IPsec necesita tener instalado el paquete RPM ipsec-tools en todos los
equipos IPsec (si es que se está utilizando una configuración de tipo equipo-a-equipo), o enrutadores
143
(si es es que se está utilizando una configuración de tipo red-a-red). El paquete RPM contiene
bibliotecas esenciales, demonios, y archivos de configuración para establecer la conexión IPsec,
como por ejemplo:
• /sbin/setkey — manipula la administración de clave y los atributos de seguridad para IPsec en
el kernel. Este ejecutable es controlado por el demonio de administración de clave racoon. Para
obtener mayor información, consulte la página man número 8 de setkey.
• /usr/sbin/racoon — el demonio de administración de clave IKE, utilizado para administrar y
controlar las asociaciones de seguridad y el compartido de clave entre los sistemas conectados con
IPsec.
• /etc/racoon/racoon.conf — el archivo de configuración del demonio racoon utilizado para
configurar varios aspectos de la conexión IPsec, incluyendo los métodos de autenticación y los
algoritmos de encriptado utilizados en ella. Para conocer una lista con todas las directivas, consulte
la página man número 5 de racoon.conf.
Para configurar IPsec en Fedora, puede utilizar la Herramienta de 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 4.2.1.6, “Configuración de IPsec
equipo-a-equipo”.
• Para conectar una LAN/WAN con otra utilizando IPsec, vea la Sección 4.2.1.7, “Configuración IPsec
red-a-red”.
4.2.1.6. Configuración de IPsec equipo-a-equipo
IPsec puede configurarse para conectar un equipo de escritorio o estación de trabajo con otro
mediante una conexión de tipo equipo-a-equipo. Este tipo de conexión utiliza la red a la que cada uno
de los equipos se conecta para crear un túnel seguro entre cada equipo. Los requerimientos de una
conexión de equipo-a-equipo son mínimos, al igual que la configuración de IPsec. El equipo necesita
solo una conexión dedicada a una red que haga de medio de transporte (como lo es Internet), y
Fedora para crear la conexión IPsec.
4.2.1.6.1. Conexión equipo-a-equipo
Una conexión de tipo equipo-a-equipo es una conexión encriptada entre dos sistemas, ambos
utilizando IPsec con la misma clave de autenticación. Con la conexión IPsec activa, cualquier tráfico
de red entre los dos equipos es encriptada.
Para configurar una conexión IPsec de tipo equipo-a-equipo, siga los siguientes pasos para cada
equipo:
Nota
Debería realizar los siguientes procedimientos en la máquina actual que está configurando. Evite
intentar establecer o configurar conexiones IPsec remotamente.
1. En una terminal, ingrese system-config-network para iniciar la Herramienta de
administración de red.
2. En la pestaña de IPsec, haga clic en Nuevo para iniciar el asistente de configuración de IPsec.
144
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.
6. Seleccione el tipo de método de encriptado a utilizarse: manual o automático.
Si selecciona encriptado manual, deberá indicar más adelante una clave de encriptado. Si
selecciona encriptado automático, el demonio racoon se encarga de administrar la clave del
encriptado. El paquete ipsec-tools debe estar instalado si quiere utilizar la encriptación
automática.
Haga clic en Siguiente para continuar.
7. Ingrese la dirección IP de equipo remoto.
Para determinar la dirección IP del equipo remoto, utilice el siguiente comando en el equipo
remoto:
[root@myServer ~] # /sbin/ifconfig <device>
donde <device> es el dispositivo Ethernet que será usado para la conexión VPN.
Si solo existe una tarjeta Ethernet en el sistema, el nombre del dispositivo seguramente será eth0.
El siguiente ejemplo muestra la información pertinente de este comando (recuerde que ese es
sólo un ejemplo):
eth0
Link encap:Ethernet HWaddr 00:0C:6E:E8:98:1D
inet addr:172.16.44.192 Bcast:172.16.45.255 Mask:255.255.254.0
La dirección IP es el número siguiente a la etiqueta inet addr:.
Nota
Para conexiones de tipo equipo-a-equipo, los dos equipos deberían tener una dirección
pública enrutable. Alternativamente, los dos equipos pueden tener una dirección privada
no enrutable (por ejemplo, entre los rangos 10.x.x.x o 192.168.x.x) siempre y cuando se
encuentren en la misma LAN.
Si los equipos se encuentran en diferentes LANs, o uno de ellos tiene una dirección pública y
el otro una dirección privada, vea la Sección 4.2.1.7, “Configuración IPsec red-a-red”.
8. Si en el paso 6 se ha seleccionado un cifrado manual, especifique la clave de cifrado a ser
utilizada, o haga clic en Generar para crear una.
a. Indique una clave de autenticación o haga clic en Generar para generar una. Puede ser una
combinación de números y letras.
145
b. Haga clic en Siguiente para continuar.
9. Verifique la información en la página IPsec — Resumen, y luego haga clic en el botón Aplicar.
10. Clic en Archivo => Guardar para guardar la configuración.
Tal vez necesite reiniciar la red para que los cambios tengan efecto. Para reiniciar la red, utilice el
siguiente comando:
[root@myServer ~]# service network restart
11. Seleccione la conexión IPsec de la lista y haga clic en el botón de Activar.
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á.
Luego de configurar la conexión IPsec, aparecerá en la lista IPsec como se lo indica en la Figura 4.1,
“Conexión IPsec”.
Figura 4.1. Conexión IPsec
Los siguientes archivos son creados cuando la conexión IPsec es configurada:
• /etc/sysconfig/network-scripts/ifcfg-<nickname>
• /etc/sysconfig/network-scripts/keys-<nickname>
• /etc/racoon/<remote-ip>.conf
• /etc/racoon/psk.txt
146
Si se elige encriptación automática, entonces también se crea el archivo /etc/racoon/
racoon.conf.
Cuando la interfaz se encuentra arriba, /etc/racoon/racoon.conf es modificado para incluir
<remote-ip>.conf.
4.2.1.6.2. Configuración manual de una conexión IPsec de tipo equipo-a-equipo
El primer paso para crear una conexión es obtener información tanto del sistema como de la red para
cada estación de trabajo. Para una conexión de tipo equipo-a-equipo, se necesita lo siguiente:
• La dirección IP de cada equipo
• Un nombre único, por ejemplo, ipsec1. Esto es utilizado para identificar la conexión IPsec y poder
identificarla de otros dispositivos o conexiones.
• Una clave de encriptado manual, o automáticamente generada por racoon.
• Una clave de autenticación pre-compartida que es utilizada a lo largo de la etapa inicial de la
conexión, y que también será utilizada luego para intercambiar claves de encriptado durante de la
sesión.
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.
No es necesario utilizar el mismo nombre de conexión para cada equipo. Debería elegir un
nombre que sea conveniente y que tenga sentido para su instalación.
A continuación mostramos un archivo de configuración IPsec en la estación de trabajo A para una
conexión IPsec de tipo equipo-a-equipo con la estación de trabajo B. El nombre único para identificar
la conexión en este ejemplo es ipsec1, de modo que el archivo resultante es denominado /etc/
sysconfig/network-scripts/ifcfg-ipsec1.
DST=X.X.X.XTYPE=IPSEC
ONBOOT=no
IKE_METHOD=PSK
Para la estación de trabajo A, X.X.X.X es la dirección IP de la estación de trabajo B. Para la
estación de trabajo B, X.X.X.X es la dirección IP de la estación de trabajo A. Esta conexión no
está configurada para iniciarse con el arranque del equipo (ONBOOT=no) y utiliza el método de
autenticación de clave pre-compartida (IKE_METHOD=PSK).
El siguiente es el contenido del archivo de clave pre-compartida (denominado /etc/sysconfig/
network-scripts/keys-ipsec1) que las dos estaciones de trabajo necesitan para poder
147
autenticarse entre ellas. El contenido de este archivo debe ser idéntico en ambas estaciones de
trabajo, y solo el usuario root debería ser capaz de leer o escribir en este archivo.
IKE_PSK=Key_Value01
Importante
Para modificar el archivo keys-ipsec1 de modo que solo el usuario root pueda leerlo o editarlo,
utilice el siguiente comando luego de haberlo creado:
[root@myServer ~] # chmod 600 /etc/sysconfig/network-scripts/keys-ipsec1
Para modificar la clave de autenticación en cualquier momento, edite el archivo keys-ipsec1 en
ambas estaciones de trabajo. Las dos claves de autenticación deben ser idénticas para una conexión
correcta.
El siguiente ejemplo muestra la configuración específica de la primera fase de la conexión con el
equipo remoto. El archivo es denominado X.X.X.X.conf, donde X.X.X.X es la dirección IP del
equipo IPsec remoto. Fijese que este archivo es generado automáticamente cuando el túnel IPsec es
activado y no debería ser editado directamente.
remote X.X.X.X{
exchange_mode aggressive, main;
my_identifier address;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2 ;
}
}
El archivo de 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).
148
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 llave 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).
4.2.1.6.2.1. El Archivo de configuración Racoon
The /etc/racoon/racoon.conf files should be identical on all IPsec nodes except for the
include "/etc/racoon/X.X.X.X.conf" statement. This statement (and the file it references)
is generated when the IPsec tunnel is activated. For Workstation A, the X.X.X.X in the include
statement is Workstation B's IP address. The opposite is true of Workstation B. The following shows a
typical racoon.conf file when the IPsec connection is activated.
# Racoon IKE daemon configuration file.
# See 'man racoon.conf' for a description of the format and entries.
path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";
sainfo anonymous
{
pfs_group 2;
lifetime time 1 hour ;
encryption_algorithm 3des, blowfish 448, rijndael ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}
include "/etc/racoon/X.X.X.X.conf";
Este archivo racoon.conf establecido por defecto incluye caminos definidos para la 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 llaves Diffie-Hellman, que determina el método por el cual
los nodos IPsec establecen una llave 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 llaves criptográficas. El segundo
grupo utiliza una exponenciación modular de 1024 bits que evita que los atacantes puedan
descifrar transmisiones IPsec, aún si una de las claves privadas ha sido vulnerada.
149
lifetime time 1 hour
Este parámetro indica el período de vida de una SA y puede ser medido o bien en unidades
de tiempo, o bien con datos. La implementación en Fedora establecida por defecto de IPsec
especifica un tiempo de vida de una hora.
encryption_algorithm 3des, blowfish 448, rijndael
Indica la cifra de cifrado soportada para la etapa 2. Fedora soporta 3DES, Blowfish de 448 bits, y
Rijndael (la cifra utilizada en el Estándard avanzado de cifrado, o AES, por las iniciales en inglés
de Advanced Encryption Standard).
authentication_algorithm hmac_sha1, hmac_md5
Muestra los algoritmos hash soportados para la autenticación. Los módulos soportados son los
códigos de autenticación de mensajes de hash sha1 y md5 (HMAC).
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:
[root@myServer ~]# /sbin/ifup <nickname>
donde <nickname> es el nombre que usted indicó para la conexión IPsec.
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:
[root@myServer ~]# tcpdump -n -i eth0 host <targetSystem>
IP 172.16.45.107 > 172.16.44.192: AH(spi=0x0954ccb6,seq=0xbb): ESP(spi=0x0c9f2164,seq=0xbb)
4.2.1.7. Configuración IPsec red-a-red
IPsec también puede ser configurado para conectar totalmente a una red (como por ejemplo una LAN
o WAN) con otra red remota utilizando una conexión de tipo red-a-red. Este tipo de conexión requiere
la configuración de enrutadores IPsec en cada lado de las redes que se quieren conectar para hacer
el proceso transparente y enrutar información de un nodo en una LAN, hacia un nodo en una LAN
remota. Figura 4.2, “Una conexión por túnel IPsec de tipo red-a-red” muestra un túnel de conexión
IPsec de tipo red-a-red.
Figura 4.2. Una conexión por túnel IPsec de tipo red-a-red
150
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.
La información necesaria para una conexión de tipo red-a-red incluye:
• La dirección IP externamente accesible del enrutador dedicado IPsec
• 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.
• Una clave de encriptado generada manualmente, o automáticamente mediante la utilización de
racoon
• Una clave de autenticación pre-compartida que es utilizada a lo largo de la etapa inicial de la
conexión, y que también será utilizada luego para intercambiar claves de encriptado durante de la
sesión.
4.2.1.7.1. Conexión red-a-red (VPN)
Una conexión IPsec de tipo red-a-red utiliza dos enrutadores IPsec, uno para cada red, a través de
los cuales es enrutado el tráfico de red para las subredes privadas.
Por ejemplo, como se muestra en la Figura 4.3, “IPsec red-a-red”, si la red privada 192.168.1.0/24
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.
Figura 4.3. IPsec red-a-red
Opciones alternativas para la configuración de red pueden establecer un cortafuegos entre Internet
y cada enrutador IP, y un cortafuegos de intranet entre el enrutador IPsec y la puerta de enlace de
151
la subred. En enrutador IPsec y la puerta de enlace para la subred puede ser un sistema con dos
dispositivos Ethernet: uno con una dirección IP pública que actúa como un enrutador IPsec; y otro con
una dirección Ip privada que actúa como la puerta de enlace para la subred privada. Cada enrutador
IPsec puede utilizar la puerta de enlace para sus redes privadas, o una puerta de enlace pública para
enviar los paquetes al otro enrutador IPsec.
Utilice el siguiente procedimiento para configurar una conexión IPsec de tipo red-a-red:
1. En una terminal, ingrese system-config-network para iniciar la Herramienta de
administración de 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.
6. Seleccione el tipo de método de encriptado a utilizarse: manual o automático.
Si selecciona encriptado manual, deberá indicar más adelante una clave de encriptado. Si
selecciona encriptado automático, el demonio racoon se encarga de administrar la clave del
encriptado. El paquete ipsec-tools debe estar instalado si quiere utilizar la encriptación
automática.
7. En la página Red local, ingrese la siguiente información:
• Local Network Address — La direción IP del dispositivo en el enrutador IPsec conectado a la
red privada.
• Local Subnet Mask — La máscara de subred de la dirección IP de la red local.
• Local Network Gateway — La puerta de enlace para la subred privada.
152
Figura 4.4. Información de red local
8. En la página de Red remota, ingrese la siguiente información:
• 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.
• Remote Subnet Mask — La máscara de subred de la dirección IP remota.
• Remote Network Gateway — La dirección Ip de la puerta de enlace para la dirección de red
remota.
• Si en la etapa 6 se ha seleccionado cifrado manual, especifique la clave de cifrado a ser
utilizada, o haga clic en Generar para crear una.
Especifique una clave de autenticación o haga clic en Generar para crear una. Esta clave
puede ser cualquier combinación de números y letras.
153
Figura 4.5. Información de red remota
9. Verifique la información en la página IPsec — Resumen, y luego haga clic en el botón Aplicar.
10. Seleccione Archivo => Guardar para guardar la configuración.
11. Seleccione la conexión IPsec de la lista, y luego haga clic en Activar para activar la conexión.
12. Habilitando reenvío IP:
a. Edite el archivo /etc/sysctl.conf y establezca net.ipv4.ip_forward a 1.
b. Use el siguiente comando para habilitar los cambios:
[root@myServer ~]# /sbin/sysctl -p /etc/sysctl.conf
El programa de red para activar la conexión IPsec automáticamente crea rutas de red para enviar
paquetes a través del enrutador IPsec, si es necesario.
4.2.1.7.2. Configuración manual de una conexión IPsec de tipo red-a-red.
Suponga que LAN A (lana.ejemplo.com) y LAN B (lanb.ejemplo.com) quieren conectarse entre ellas
mediante un túnel IPsec. La dirección de red para LAN A está en el rango 192.168.1.0/24. mientras
qye LAN B utiliza el rango 192.168.2.0/24. La dirección IP de la puerta de enlace es 192.1686.1.254
para LAN A y 192.168.2.254 para LAN B. Los enrutadores IPsec están separados de cada puerta de
enlace LAN y utilizan dos dispositivos de red: eth0 está asignado a una dirección IP estática accesible
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.
154
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 reda-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
La siguiente lista describe los contenidos de este archivo:
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.
El siguiente ejemplo es el contenido del archivo de clave pre-compartida denominado /etc/
sysconfig/network-scripts/keys-ipsecX (donde X es 0 para LAN A, y 1 para LAN B), que
utilizan ambas redes para autenticarse entre ellas. Los contenidos de este archivo deberían ser
idénticos y solo el usuario root debería ser capaz de leer o escribir sobre este archivo.
IKE_PSK=r3dh4tl1nux
155
Importante
Para modificar el arhivo keys-ipsecX de modo que solo el usuario root pueda leerlo o editarlo,
utilice el siguiente comando luego de haberlo creado:
chmod 600 /etc/sysconfig/network-scripts/keys-ipsec1
Para modificar la clave de autenticación en cualquier momento, edite el archivo keys-ipsecX en
ambos enrutadores IPsec. Ambas claves deben ser idénticas para una conexión correcta.
En el siguiente ejemplo se muestran los contenidos del archivo de configuración /etc/racoon/
racoon.conf para la conexión IPsec. Fíjese que la línea include al final del archivo es generada
automáticamente y solo aparece si el tunel IPsec está ejecutándose.
# Racoon IKE daemon configuration file.
# See 'man racoon.conf' for a description of the format and entries.
path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";
sainfo anonymous
{
pfs_group 2;
lifetime time 1 hour ;
encryption_algorithm 3des, blowfish 448, rijndael ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}
include "/etc/racoon/X.X.X.X.conf"
La siguiente es la configuración específica para la conexión con la red remota. El archivo es
denominado X.X.X.X.conf (donde X.X.X.X es la dirección IP del enrutador IPsec remoto). Fíjese
que este archivo es automáticamente generado cuando el túnel IPsec es activado y no debería ser
editado directamente.
remote X.X.X.X{
exchange_mode aggressive, main;
my_identifier address;
proposal {
encryption_algorithm 3des;
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:
1. Edite el archivo /etc/sysctl.conf y establezca net.ipv4.ip_forward a 1.
2. Use el siguiente comando para habilitar los cambios:
[root@myServer ~] # sysctl -p /etc/sysctl.conf
156
Shell seguro (SSH, por las iniciales en inglés de Secure Shell)
Para iniciar la conexión IPsec, utilice el siguiente comando en cada enrutador:
[root@myServer ~] # /sbin/ifup ipsec0
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:
[root@myServer ~] # /sbin/ip route list
Para verificar la conexión IPsec, ejecute la herramienta tcpdump en el dispositivo enrutable
externamente (en nuestro ejemplo, eth0) para ver los paquetes de red que están siendo transferidos
entre los equipos (o redes) y verifique que estén encriptados mediante IPsec. Por ejemplo, para
verificar la conectividad IPsec de LAN A, utilice el siguiente comando:
[root@myServer ~] # tcpdump -n -i eth0 host lana.example.com
El paquete 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):
12:24:26.155529 lanb.example.com > lana.example.com: AH(spi=0x021c9834,seq=0x358): \
lanb.example.com > lana.example.com: ESP(spi=0x00c887ad,seq=0x358) (DF) \
(ipip-proto-4)
4.2.1.8. Iniciar y detener una conexión IPsec
Si la conexión IPsec no fue configurada para activarse durante el arranque del equipo, puede
controlarla desde la línea de comandos.
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:
[root@myServer ~] # /sbin/ifup <nickname>
where <nickname> is the nickname configured earlier, such as ipsec0.
Para detener la conexión, use el siguiente comando:
[root@myServer ~] # /sbin/ifdown <nickname>
4.2.2. Shell seguro (SSH, por las iniciales en inglés de Secure Shell)
Shell seguro (SSH) es un protocolo de red muy poderoso que se utiliza para comunicarse con otros
sistemas operativos a través de un canal seguro. Las transmisiones realizadas con SSH están
cifradas y protegidas de cualquier tipo de intercepción. Pueden utilizarse también registros de tipo
criptográfico para proveer un mejor método de autenticación además del tradicional nombre de
usuario y contraseña.
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.
157
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.
4.2.2.1. Cryptographic Logon
SSH supports the use of cryptographic keys to login to a computer. This is much more secure than
using a password and if setup properly could be considered multifactor authentication.
A configuration change must occur before cryptographic logon can occur. In the file /etc/ssh/
sshd_config uncomment and modify the following lines so that appear as such:
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
The first line tells the SSH program to allow public key authentication. The second line points to a file
in the home directory where the public key of authorized key pairs exists on the system.
The next thing to do is to generate the ssh key pairs on the client you will use to connect to the
system. The command ssh-keygen will generate an RSA 2048-bit key set for logging into the
system. The keys are stored, by default, in the ~/.ssh directory. You can utilize the switch -b to
modify the bit-strength of the key. 2048-bits is probably okay but you can go up to, and possibly
beyond, 8192-bit keys.
In your ~/.ssh directory you should see the two keys you just created. If you accepted the defaults
when running the ssh-keygen then your keys are named id_rsa and id_rsa.pub, the private and
public keys. You should always protect the private key from exposure. The public key, however, needs
to be transfered over to the system you are going to login to. Once you have it on your system the
easiest way to add the key to the approved list is by:
$ cat id_rsa.pub >> ~/.ssh/authorized_keys
This will append the public key to the authorized_key file. The SSH application will check this file when
you attempt to login to the computer.
Similarly to passwords and any other authentication mechanism, you should change your SSH keys
regularly. When you do make sure you clean out any unused key from the authorized_key file.
4.2.3. Cifrado de disco LUKS (Linux Unified Key Setup-on-diskformat)
La Configuración de Clave Unificada de Linux en el formato de disco (o LUKS por sus iniciales en
inglés) le permite cifrar particiones en su computadora Linux. Esto es particularmente importante
cuando se trata de computadores móviles y de medios removibles. LUKS le permite claves múltiples
de usuario para descifrar una clave maestra que se usa para el cifrado de la partición.
4.2.3.1. Implementación de LUKS en Fedora
Fedora 9 y posterior utiliza LUKS para realizar cifrado del sistema de archivos. En forma
predeterminada, la opción de cifrar el sistema de archivos está desmarcada durante la instalación.
Si usted selecciona la opción de cifrar su disco duro, se le pedirá una contraseña que será solicitada
1
http://www.redhatmagazine.com/2007/11/27/advanced-ssh-configuration-and-tunneling-we-dont-need-no-stinking-vpnsoftware
158
Cifrado de disco LUKS (Linux Unified Key Setup-on-disk-format)
cada vez que inicie su computador. Esta contraseña "desbloquea" la llave de cifrado que es usada
para descifrar su partición. Si usted elije modificar la tabla de particiones predeterminada, podrá elegir
las particiones que desee cifrar.\nEsto es definido en la configuración de la tabla de particiones.
La implementación predeterminada de LUKS en Fedora es AES 128 con hash SHA256. Los cifrados
disponibles son:
2
• AES - Advanced Encryption Standard - FIPS PUB 197
• Twofish (A 128-bit Block Cipher)
• Serpent
3
• cast5 - RFC 2144
4
• cast6 - RFC 2612
4.2.3.2. Cifrado manual de directorios
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!
Nota
Este procedimiento usa scrub para destruir los datos existentes en la partición y entregar una
base aleatoria para que LUKS use. Esta base aleatoria es importante para prevenir ataques
contra la criptografía.\nScrub no está instalado en forma predeterminada y antes de usarlo
deberá instalarlo. Alternativamente, podrá usar otro generador de números aleatorios para hacer
lo mismo.
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.
2
http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
http://www.ietf.org/rfc/rfc2144.txt
4
http://www.ietf.org/rfc/rfc2612.txt
3
159
4.2.3.3. Instrucciones paso a paso
1. Ingrese a nivel de ejecución 1: telinit 1
2. Llene su partición con datos aleatorios: scrub -p random /home
3. Desmonte su /home actual: umount /home
4. Si falla, use fuser para identificar y eliminar los procesos que retienen a /home: fuser -mvk /
home
5. Verifique que /home ya no esté montado: cat /proc/mounts | grep home
6. Inicie su partición: cryptsetup --verbose --verify-passphrase luksFormat /dev/
VG00/LV_home
7. Abra el dispositivo nuevo cifrado: cryptsetup luksOpen /dev/VG00/LV_home home
8. Compruebe que está allí: ls -l /dev/mapper | grep home
9. Genere un sistema de archivos: mkfs.ext3 /dev/mapper/home
10. Móntelo: mount /dev/mapper/home /home
11. Compruebe que es visible: df -h | grep home
12. Agregue lo siguiente a /etc/crypttab: home /dev/VG00/LV_home none
13. Edite su /etc/fstab, elimine la antigua entrada de /home, y agregue /dev/mapper/home /home
ext3 defaults 1 2
14. Verifique su entrada fstab: mount /home
15. Restaure los contextos de seguridad de SELinux: /sbin/restorecon -v -R /home
16. Reinicie: shutdown -r now
17. La entrada en /etc/crypttab hace que su computadora le pida su frase de acceso luks al arrancar
18. Ingrese como root y restaure su respaldo
4.2.3.4. Lo que acaba de realizar
Felicitaciones, ahora tiene una partición cifrada para que todos sus datos reposen en forma segura
cuando su equipo se encuentre apagado.
4.2.3.5. Enlaces de interés
Para información adicional sobre LUKS, o sobre el cifrado de discos duros bajo Fedora, por favor
visite alguno de los siguientes enlaces:
5
• LUKS - Linux Unified Key Setup
• COMO: Generando un volumen físico (PV) cifrado, utilizando otro disco duro, pvmove, y un CD o
6
DVD vivo de Fedora
5
6
https://code.google.com/p/cryptsetup/
https://bugzilla.redhat.com/attachment.cgi?id=161912
160
Archivos cifrados mediante 7-Zip
4.2.4. Archivos cifrados mediante 7-Zip
7
7-Zip es una nueva herramienta de compresión multiplataforma que también puede realizar
poderosos cifrados (AES-256) para proteger los contenidos de un archivo. Esto es muy útil cuando
necesite trasladar datos entre diferentes computadoras que utilicen distintos sistemas operativos, y
quiera utilizar para ello una herramienta de cifrado portátil (por ejemplo, Linux en el hogar, Windows
en el trabajo).
4.2.4.1. Instalación de 7-Zip en Fedora
7-Zip no es un paquete que venga instalado por defecto con Fedora, pero se encuentra disponible
para descargarlo desde el repositorio. Una vez instalado, el paquete se irá actualizando cada vez que
sea necesario, del mismo modo que el resto del software en su sistema, sin necesitar para ello ningún
tipo de atención especial.
4.2.4.2. Instrucciones paso a paso para su instalación
• Open a Terminal: Click Applications -> System Tools -> Terminal or in GNOME 3:
Activities -> Applications -> Terminal
• Instale 7-Zip con permisos de usuario sudo: sudo yum install p7zip
• Cierre la terminal: exit
4.2.4.3. Instrucciones paso a paso para su utilización
By following these instructions you are going to compress and encrypt your "Documents" directory.
Your original "Documents" directory will remain unaltered. This technique can be applied to any
directory or file you have access to on the filesystem.
• Open a Terminal:Click Applications -> System Tools -> Terminal
• Comprima y cifre: (ingrese una contraseña cuando le sea pedido) 7za a -mhe=on -ms=on -p
Documentos.7z Documentos/
The "Documents" directory is now compressed and encrypted. The following instructions will move the
encrypted archive somewhere new and then extract it.
• Cree un directorio nuevo: mkdir lugarnuevo
• Traslade el archivo cifrado: mv Documentos.7z lugarnuevo
• Posiciónese en el nuevo directorio: cd lugarnuevo
• Descomprima el archivo: (ingrese la contraseña cuando se le pida) 7za x Documentos.7z
El archivo ya ha sido descomprimido en el nuevo directorio. Las instrucciones siguientes van a
deshacer los pasos realizados y devolverán a su computadora el estado anterior en el que se
encontraba.
• Diríjase al directorio superior inmediato: cd ..
• Borre el archivo de prueba creado y sus contenidos extraídos: rm -r lugarnuevo
• Cierre la terminal: exit
7
http://www.7-zip.org/
161
4.2.4.4. Creating a Secure 7-Zip Archive via the GUI
7-Zip archives can be extracted just like any other archive via the GUI, but creating a secure 7-Zip
archive requires a few additional steps.
By following these instructions you are going to compress and encrypt your "Documents" directory.
Your original "Documents" directory will remain unaltered. This technique can be applied to any
directory or file you have access to on the filesystem.
• Open the file browser: Click Activities -> Files
• Right-Click on the "Documents" folder
• Select the "Compress" option
• Select ".7z" as the file extension
• Expand "Other Options"
• Check "Encrypt the file list too"
• Enter a password into the password field
• Click the "Create" button
You will now see a "Documents.7z" file appear in your home directory. If you try to open the file, you
will be asked for the archive password before being shown the contents of the archive. The file will
open once the correct password is supplied, and the archive can then be manipulated as usual.
Deleting the "Documents.7z" file will conclude this exercise and return your computer to its previous
state.
4.2.4.5. Elementos para prestar atención
7-Zip no se encuentra instalado por defecto en los sistemas operativos Microsoft Windows o Mac OS
X. Si necesita utilizar sus archivos 7-Zip en alguna de estas plataformas, necesitará instalar la versión
8
apropiada de 7-Zip en los equipos correspondientes. Vea la página de descargas .
4.2.5. Utilizando GNU Privacy Guard (GnuPG)
GnuPG (GPG) is used to identify yourself and authenticate your communications, including those
with people you don't know. GPG allows anyone reading a GPG-signed email to verify its authenticity.
In other words, GPG allows someone to be reasonably certain that communications signed by you
actually are from you. GPG is useful because it helps prevent third parties from altering code or
intercepting conversations and altering the message.
GPG 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.
To utilize GPG for authentication or encryption of email you must first generate your public and private
keys. After generating the keys you will have to setup your email client to utilize them.
8
http://www.7-zip.org/download.html
162
Utilizando GNU Privacy Guard (GnuPG)
4.2.5.1. Generando claves GPG en GNOME
The Seahorse utility makes GPG key management easier. You can install Seahorse at the command
line with the command su -c "yum install seahorse" or in the GUI using Add/Remove
Software.
To create a key select Passwords and Keys, which starts the application Seahorse. From the
File menu select New then PGP Key then select Continue. Type your full name, email address,
and an optional comment describing who are you (e.g.: John C. Smith, [email protected], The
Man). Select Create. A dialog is displayed asking for a passphrase for the key. Choose a strong
passphrase but also easy to remember. Click OK and the key is created.
Advertencia
Si se olvida su frase de acceso, la clave no podrá ser utilizada y cualquier dato encriptado por
ella será perdido.
To find your GPG key ID, look in the Key ID column next to the newly created key. In most cases, if
you are asked for the key ID, you should prepend "0x" to the key ID, as in "0x6789ABCD". You should
make a backup of your private key and store it somewhere secure.
4.2.5.2. Generar claves GPG en KDE
Start the KGpg program from the main menu by selecting Applications > Utilities > Encryption Tool. If
you have never used KGpg before, the program walks you through the process of creating your own
GPG keypair. A dialog box appears prompting you to create a new key pair. Enter your name, email
address, and an optional comment. You can also choose an expiration time for your key, as well as the
key strength (number of bits) and algorithms. The next dialog box prompts you for your passphrase. At
this point, your key appears in the main KGpg window.
Advertencia
ella será perdido.
To find your GPG key ID, look in the Key ID column next to the newly created key. In most cases, if
you are asked for the key ID, you should prepend "0x" to the key ID, as in "0x6789ABCD". You should
make a backup of your private key and store it somewhere secure.
4.2.5.3. Generar una clave GPG mediante la línea de comandos
Use el siguiente comando: gpg --gen-key
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.
163
Una serie de mensajes lo dirigen a lo largo del proceso. Presione la tecla Enter para indicar el
valor establecido por defecto si así lo desea. El primer mensaje le pide que elija el tipo de clave que
prefiere:
Por favor, seleccione qué tipo de llave desea:
(1) RSA y RSA (predeterminado)
(2) DSA y Elgamal
(3) DSA (sólo firmar)
(4) RSA (sólo firmar)
¿Su selección?
En la mayoría de los casos, el predeterminado es la elección correcta. Una llave RSA le permite no
sólo firmar comunicaciones, sino que también cifrar archivos.
Luego, elija el tamaño de llave:
El largo de las llaves RSA pueden estar entre 1024 y 4096 bits. ¿Qué tamaño de llave desea?
(2048)
Nuevamente, el predeterminado es suficiente para la mayoría de los usuarios y representa un fuerte
nivel de seguridad.
Next, choose when the key will expire. It is a good idea to choose an expiration date instead of using
the default, which is none. If, for example, the email address on the key becomes invalid, an expiration
date will remind others to stop using that public key.
Por favor
0 =
d =
w =
m =
y =
¿La
indique por cuánto su llave debe ser válida.
la llave no expira.
la llave expira en n días
la llave expira en n semanas
la llave expira en n meses
la llave expira en n años
llave 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.)
Before the gpgcode> program asks for signature information, the following prompt appears: Is this
correct (y/n)? Enter ycode> to finish the process.
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.
Use the comment field to include aliases or other information. (Some people use different keys for
different purposes and identify each key with a comment, such as "Office" or "Open Source Projects.")
En el mensaje de 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.
164
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:
pub 1024D/1B2AFA1C 2005-03-31 John Q. Doe (Fedora Docs Project) <[email protected]>
Key fingerprint = 117C FE83 22EA B843 3E86 6486 4320 545E 1B2A FA1C
sub 1024g/CEA4B22E 2005-03-31 [expires: 2006-03-31]
The key fingerprint is a shorthand "signature" for your key. It allows you to confirm to others that they
have received your actual public key without any tampering. You do not need to write this fingerprint
down. To display the fingerprint at any time, use this command, substituting your email address: gpg
--fingerprint [email protected]
Your "GPG key ID" consists of 8 hex digits identifying the public key. In the example above, the GPG
key ID is 1B2AFA1C. In most cases, if you are asked for the key ID, you should prepend "0x" to the
key ID, as in "0x1B2AFA1C".
Advertencia
ella será perdido.
4.2.5.4. Usando GPG con Alpine
Si está utilizando el cliente de correo electrónico Alpine o Pine, entonces también necesitará
descargar e instalar el paquete ez-pine-gpg. Este software actualmente se encuentra disponible en
http://business-php.com/opensource/ez-pine-gpg/. Una vez que haya instalado ez-pine-gpg, tendrá
que modificar su archivo ~/.pinerc. Necesita:
1. /home/username/bin debe ser reemplazado con la ruta de instalación que usted especificó
2. In two places, the gpg-identifier after _RECIPIENTS_ should be replaced with your GPG public
key's identifier. The reason you include your own GPG identifier here is so that if you send an
encrypted message to "Alice", that message is also encrypted with your public key -- if you don't
do this, then you will not be able to open that message in your sent-mail folder and remind yourself
of what you wrote.
Debe verse algo similar a esto:
# This variable takes a list of programs that message text is piped into
# after MIME decoding, prior to display.
display-filters=_LEADING("-----BEGIN PGP")_ /home/max/bin/ez-pine-gpg-incoming
# This defines a program that message text is piped into before MIME
# encoding, prior to sending
sending-filters=/home/max/bin/ez-pine-gpg-sign _INCLUDEALLHDRS_,
/home/username/bin/ez-pine-gpg-encrypt _RECIPIENTS_ gpg-identifier,
/home/username/bin/ez-pine-gpg-sign-and-encrypt _INCLUDEALLHDRS_ _RECIPIENTS_ gpgidentifier
165
4.2.5.5. Usando GPG con Evolution
4.2.5.5.1. Configurando GPG para usar con Evolution
Para configurar GPG para ser utilizado en Evolution, elija Herramientas, Configuraciones... en
el menú principal de Evolution. En el panel izquierdo, seleccione Cuentas de correo. En el panel
derecho, seleccione la cuenta de correo que utiliza para la correspondencia con el Proyecto Fedora.
Luego haga clic sobre el botón Editar. Aparece el diálogo de edición de cuentas de Evolution.
Seleccione la pestaña de Seguridad.
In the PGP/GPG Key ID field, enter the GPG key ID matching this account's email address. If you are
not sure what your key ID is, use this command: gpg --fingerprint EMAIL_ADDRESS. The key
ID is the same as the last eight characters (4 bytes) of the key fingerprint. It is a good idea to click the
option Always encrypt to myself when sending encrypted mail. You may also want to select Always
sign outgoing messages when using this account.
Nota
Si no identifica las llaves 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
4.2.5.5.2. Verificando correos electrónicos con Evolution
Evolution will automatically check any incoming GPG-signed messages for validity. If Evolution cannot
GPG verify a message due to a missing public key (or tampering), it will end with a red banner. If the
message is verified but you have not signed the key either locally or globally, the banner will be yellow.
If the message is verified and you have signed the key, the banner will be green. When you click the
seal icon, Evolution displays a dialog with more security information about the signature. To add a
public key to your keyring, use the search function along with the key owner's email address: gpg -keyserver pgp.mit.edu --search email address. To import the correct key, you may need
to match the key ID with the information provided by Evolution.
4.2.5.5.3. Firmando y cifrando correos electrónicos con Evolution
El hecho de firmar los correos electrónicos permite que sus destinatarios verifiquen que ese correo
realmente proviene de usted. El Proyecto de Documentación de Fedora (y todo el resto del proyecto
Fedora) fomentan la utilización de correos firmados entre sus participantes, incluyendo los correos
enviados a las diferentes listas. Cifrar un correo electrónico hace que solamente sus destinatarios
puedan leerlo. Por favor, no envíe correos cifrados a las listas de correo de Fedora, ya que casi nadie
va a poder leerlos.
Mientras esté redactando su correo, elija el menú Seguridad, y luego seleccione Firma PGP para
firmar su mensaje. Para cifrar su mensaje, seleccione Cifrado PGP. 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.
166
4.2.5.6. Usando GPG con Thunderbird
Fedora Core includes Mozilla Thunderbird in the thunderbird package, and the mozilla-mail package
for the Mozilla Suite email application. Thunderbird is the recommended Mozilla email application. This
appears on your desktop as Applications > Internet > Thunderbird Email.
Los productos Mozilla tienen soporte para extensiones, que son diferentes complementos que le
agregan nuevas 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.
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.
La pagina principal de Enigmail es: http://enigmail.mozdev.org/download.html.
En esta página se pueden apreciar capturas de pantalla de Enigmail y GPG en acción: http://
enigmail.mozdev.org/screenshots.html.
4.2.5.6.1. Instalando Enigmail
Enigmail is now available in fedora repository. It can be installed by typing: yum install
thunderbird-enigmail at a command line. Alternatively, you can install thunderbird-enigmail using
by going to System -> Administration -> Add/Remove Software.
4.2.5.7. Acerca del encriptado de la clave pública
1. Wikipedia - Criptografía de la llave pública (en inglés)
2. HowStuffWorks - Encryption
9
9
10
http://en.wikipedia.org/wiki/Public-key_cryptography
http://computer.howstuffworks.com/encryption.htm
10
167
168
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 hombreen-el-medio, o escuchas. Es importante encriptar de la información de autenticación, como ser
contraseñas.
• minimice la cantidad de software instalado y de servicios en ejecución.
• utilice herramientas y software destinadas a mejorar la seguridad de su equipo. Por ejemplo,
Security-Enhanced Linux (SELinux) para Control de Acceso Obligatorio (MAC, por las siglas en
inglés de Mandatory Acces Control), Netfilter iptables para filtrar paquetes (cortafuegos), y la
Protección de Privacidad GNU (GnuPG, por las siglas en inglés de GNU Privacy Guard) para los
archivos encriptados.
• si es posible, corra cada servicio de red en un servidor separado para minimizar el riesgo de que
una debilidad en uno de los servicios, se utilice para comprometer a los 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.
5.1. Consejos, Guías y Herramientas
1
La Agencia de Seguridad Nacional (NSA) de los Estado Unidos proporciona guías y consejos para
muchos sistemas operativos, para ayudar a agencias del gobierno, empresas y personas a asegurar
y endurecer sus sistemas contra ataques. Las siguientes guías (en formato PDF) proveen consejos
para Red Hat Enterprise Linux 5:
• Consejos para asegurar un sistema Linux 5 para empresas de Red Hat (en ingllés)
2
• Guía para la configuración segura de un sistema Linux 5 para empresas de Red Hat (en inglés)
3
La Agencia de Defensa de Información de Sistemas (DISA, por las iniciales en inglés de Defense
4
Information Systems Agency) ofrece documentación, evaluaciones, y listas con ítems a ser
verificados, que le ayudarán a asegurar su sistema (Soporte para un Entorno Seguro de la
1
http://www.nsa.gov/
http://www.nsa.gov/ia/_files/os/redhat/rhel5-pamphlet-i731.pdf
3
http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf
4
http://www.disa.mil/
2
169
Capítulo 5. Principios Generales sobre la Seguridad de la Información
5
6
Información ). La Guía de implementación t{ecnicade seguridad UNIX (PDF) es una guía muy
específica para la seguridad en sistemas UNIX - antes de leerla, se recomienda poseer un
conocimiento avanzado tanto de UNIX como de Linux.
7
La Lista de Items a verificarse para la Seguridad de UNIX Version 5, Release 1.26 de DISA ofrece
diferentes documentos y listas de verificación, abarcando aspectos que van desde el correcto
establecimiento de la pertenencia de los archivos del sistema, hasta el control de parches.
8
Al mismo tiempo, DISA ha puesto a disposición diferentesprogramas de UNIX SPR que permiten a
los administradores verificar configuraciones específicas en sus sistemas. Estos programas ofrecen
reportes en formato XML, en los que muestran todas las configuraciones vulnerables conocidas.
5
http://iase.disa.mil/index2.html
http://iase.disa.mil/stigs/stig/unix-stig-v5r1.pdf
7
http://iase.disa.mil/stigs/downloads/zip/unclassified_unix_checklist_v5r1-26_20100827.zip
8
http://iase.disa.mil/stigs/SRR/unix.html
6
170
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.
6.1. Particiones del disco
La NSA recomienda crear particiones separadas para /boot, /, /home, /tmp y /var/tmp. Las razones
son diferentes y se tratará por separado para cada partición.
/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 and /var/tmp - Both the /tmp and the /var/tmp directories are used to store data that doesn't need
to be stored for a long period of time. However if a lot of data floods one of these directories it can
consume all of your storage space. If this happens and these directories are stored within / then your
system could become unstable and crash. For this reason, moving these directories into their own
partitions is a good idea.
6.2. Utilice encriptado de particiones mediante LUKS
1
Since Fedora 9, implementation of Linux Unified Key Setup-on-disk-format (LUKS) encryption
has become a lot easier. During the installation process an option to encrypt your partitions will be
presented to the user. The user must supply a passphrase that will be the key to unlock the bulk
encryption key that will be used to secure the partition's data.
1
http://fedoraproject.org/wiki/Security_Guide/9/LUKSDiskEncryption
171
172
Mantenimiento de Software
Una 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.
7.1. Instale el software mínimo
La mejor forma de proceder es instalando solo los paquetes que se van a utilizar, ya que cada
pieza de software en su computadora posiblemente pueda contener algún tipo de debilidad. Si
está realizando una instalación desde un DVD, dese la oportunidad de elegir exactamente qué
paquetes quiere instalar en este proceso. Si se da cuenta que necesita otro paquete, siempre puede
agregárselo luego al sistema.
7.2. Planifique y configure actualizaciones de seguridad
Todo software contiene errores. A menudo, estos errores pueden transformarse en una debilidad que
podría dejar a su sistema expuesto a usuarios maliciosos. Sistemas no enmendados son una causa
frecuente de intrusiones en las computadoras. Debería tener planificada la instalación de parches de
seguridad en una forma sincronizada de manera tal de poder anular esas debilidades, y evitar así que
sean aprovechadas.
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.
7.3. Ajustando las actualizaciones automáticas
Fedora is configured to apply all updates on a daily schedule. If you want to change the how your
system installs updates you must do so via Software Update Preferences. You can change the
schedule, the type of updates to apply or to notify you of available updates.
In Gnome, you can find controls for your updates at: System -> Preferences -> Software
Updates. In KDE it is located at: Applications -> Settings -> Software Updates.
7.4. Instale paquetes identificados desde repositorios
conocidos
Los paquetes de software son publicados a través de repositorios. Todos los repositorios más
conocidos tienen soporte para poder identificar sus paquetes. La identificación de los paquetes utiliza
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.
173
Capítulo 7. Mantenimiento de Software
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.
174
Debilidades y exposiciones comunes
El sistema de Debilidades y exposiciones comunes (CVE por las iniciales en inglés de Common
Vulnerabilities and Exposures) ofrece un método de referencia que contiene las debilidades y las
exposiciones más conocidas relacionadas con la seguridad de la información. Este sistema es
mantenido por la Corporación ITRE, con fondos provistos por la División de seguridad cibernética del
Departamento de seguridad doméstica de los Estados Unidos.
La Corporación MITRE asigna un identificador CVE para cada debilidad o exposición. El CVE es
utilizado para rastrear una debilidad determinada a través de diferentes partes de software, ya que un
mismo CVE puede afectar diversos paquetes de software y múltiples proveedores.
8.1. Complemento de Yum
El paquete yum-plugin-security es una característica de Fedora. Si se lo instala, el módulo yum
cargado por este paquete puede ser utilizado para hacer que yum solo obtenga actualizaciones
relacionadas con la seguridad. Puede también ser utilizado para ofrecer información acerca de
advertencias ofrecidas por Red Hat, o para saber cuál es el bug correspondiente en la base de datos
Bugzilla de Red Hat, o cuál es el número de CVE en el directorio MITRE que contiene un paquete
determinado
Para habilitar estas características sólo es necesario ejecutar el comando yum install yumplugin-security.
8.2. Cómo utilizar yum-plugin-security
El primer subcomando que esto agrega es yum list-sec. Funciona de manera similar a yum
check-update, con la diferencia que además ofrece una lista con el número de identificación de las
advertencias de Red Hat, y la clasificación de cada actualización en términos de "mejora", "solución
de error", o "seguridad":
RHSA-2007:1128-6 security autofs - 1:5.0.1-0.rc2.55.el5.1.i386
RHSA-2007:1078-3 security cairo - 1.2.4-3.el5_1.i386
RHSA-2007:1021-3 security cups - 1:1.2.4-11.14.el5_1.3.i386
RHSA-2007:1021-3 security cups-libs - 1:1.2.4-11.14.el5_1.3.i386
Si se utiliza yum list-sec cves, el ID de la advertencia de Red Hat es reemplazado por el (o
los) ID de CVE indicado en la actualización; si en cambio se utiliza yum list-sec bzs, el ID de la
advertencia es reemplazado por los de Bugzilla de Red Hat ofrecidos en el paquete. Si un paquete
ofrece varios errores en Bugzilla, o IDs de CVE, el paquete puede ser listado varias veces
Un ejemplo del resultado del comando yum list-sec bzs:
410031 security autofs - 1:5.0.1-0.rc2.55.el5.1.i386
387431 security cairo - 1.2.4-3.el5_1.i386
345101 security cups - 1:1.2.4-11.14.el5_1.3.i386
345101 security cups-libs - 1:1.2.4-11.14.el5_1.3.i386
Un ejemplo del resultado del comando yum list-sec cves:
CVE-2007-5964 security autofs - 1:5.0.1-0.rc2.55.el5.1.i386
CVE-2007-5503 security cairo - 1.2.4-3.el5_1.i386
175
Capítulo 8. Debilidades y exposiciones comunes
CVE-2007-5393 security cups - 1:1.2.4-11.14.el5_1.3.i386
CVE-2007-5393 security cups-libs - 1:1.2.4-11.14.el5_1.3.i386
El segundo nuevo subcomando agregado por el paquete yum-plugin-security es info-sec. Este
subcomando utiliza como argumento un número de advertencia, ya sea de CVE o de Bugzilla, y
ofrece información detallada sobre tal advertencia, incluyendo un texto introductorio relacionado con
la naturaleza del o los problemas tratados en dicha advertencia
Además de estos dos nuevos subcomandos de yum, se ofrecen nuevas opciones al comando
yum update para poder instalar actualizaciones relacionadas exclusivamente con aspectos de la
seguridad, o exclusivamente relacionadas con algún error o advertencia
Para instalar exclusivamente todas las actualizaciones relacionadas con la seguridad:
yum update --security
Para instalar exclusivamente todas las actualizaciones relacionadas con el error bugzilla 410101:
yum update --bz 410101
Para instalar exclusivamente todas las actualizaciones relacionadas con el ID CVE-2007-5707 de
CVE, y aquellas relacioandas con el ID de advertencia de Red Hat RHSA-2007:1082-5:
yum update --cve CVE-2007-5707 --advisory RHSA-2007:1082-5
More information about these new capabilities is documented in the yum-plugin-security(8) man page.
Para obtener mayor información relacionada con actualizaciones de seguridad en Fedora, por favor
visite la página de seguridad de Fedora en https://fedoraproject.org/wiki/Security (en inglés).
176
Referencias
Las siguientes referencias tienen como objetivo orientar la búsqueda de información adicional
relacionada con SELinux y con 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
Prentice Hall, 2007
Tutoriales y asistencia
Entendiendo y personalizando la política de SELinux para HTTP de Apache
http://fedora.redhat.com/docs/selinux-apache-fc3/
Tutoriales y charlas de Russell Coker
http://www.coker.com.au/selinux/talks/ibmtu-2004/
Tutorial genérico para escritura de Políticas de SELinux
http://www.lurking-grue.org/writingselinuxpolicyHOWTO.html
Base de Conocimientos de Red Hat
http://kbase.redhat.com/
Información general
Sitio web principal de SELinux de la NSA
1
http://www.nsa.gov/selinux/
NSA SELinux FAQ
2
http://www.nsa.gov/selinux/info/faq.cfm
Fedora SELinux FAQ
http://fedora.redhat.com/docs/selinux-faq-fc3/
SELinux NSA's Open Source Security Enhanced Linux
http://www.oreilly.com/catalog/selinux/
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
Implemenetación de SELinux como un módulo de seguridad de linux
http://www.nsa.gov/research/_files/publications/implementing_selinux.pdf
1
2
http://www.nsa.gov/research/selinux/index.shtml
http://www.nsa.gov/research/selinux/faqs.shtml
177
Capítulo 9. Referencias
Una Configuración de Política de Seguridad para el Linux de Seguridad Mejorada
http://www.nsa.gov/research/_files/selinux/papers/policy/policy.shtml
Comunidad
Guía del Usuario de SELinux de Fedora
http://docs.fedoraproject.org/selinux-user-guide/
Guía de administración de servicios confinados de SELinux de Fedora
http://docs.fedoraproject.org/selinux-managing-confined-services-guide/
Página comunitaria de SELinux
http://selinux.sourceforge.net
IRC
irc.freenode.net, #selinux, #fedora-selinux, #security
Historia
Historia breve de Flask
http://www.cs.utah.edu/flux/fluke/html/flask.html
Antecedentes completos sobre Fluke
http://www.cs.utah.edu/flux/fluke/html/index.html
178
Apéndice A. Estándares de cifrado
A.1. Cifrado sincronizado
A.1.1. Advanced Encription Standard - AES
In cryptography, the Advanced Encryption Standard (AES) is an encryption standard adopted by the
U.S. government. The standard comprises three block ciphers, AES-128, AES-192 and AES-256,
adopted from a larger collection originally published as Rijndael. Each AES cipher has a 128-bit block
size, with key sizes of 128, 192 and 256 bits, respectively. The AES ciphers have been analyzed
extensively and are now used worldwide, as was the case with its predecessor, the Data Encryption
1
Standard (DES).
A.1.1.1. Usos de AES
A.1.1.2. Historia de AES
AES was announced by National Institute of Standards and Technology (NIST) as U.S. FIPS PUB 197
(FIPS 197) on November 26, 2001 after a 5-year standardization process in which fifteen competing
designs were presented and evaluated before Rijndael was selected as the most suitable (see
Advanced Encryption Standard process for more details). It became effective as a standard May 26,
2002. It is available in many different encryption packages. AES is the first publicly accessible and
2
open cipher approved by the NSA for top secret information (see Security of AES, below).
The Rijndael cipher was developed by two Belgian cryptographers, Joan Daemen and Vincent
Rijmen, and submitted by them to the AES selection process. Rijndael (pronounced [r#inda#l]) is a
3
portmanteau of the names of the two inventors.
A.1.2. Data Encryption Standard - DES
The Data Encryption Standard (DES) is a block cipher (a form of shared secret encryption) that
was selected by the National Bureau of Standards as an official Federal Information Processing
Standard (FIPS) for the United States in 1976 and which has subsequently enjoyed widespread use
internationally. It is based on a symmetric-key algorithm that uses a 56-bit key. The algorithm was
initially controversial with classified design elements, a relatively short key length, and suspicions
about a National Security Agency (NSA) backdoor. DES consequently came under intense academic
4
scrutiny which motivated the modern understanding of block ciphers and their cryptanalysis.
A.1.2.1. Usos de DES
A.1.2.2. Historia de DES
DES is now considered to be insecure for many applications. This is chiefly due to the 56-bit key
size being too small; in January, 1999, distributed.net and the Electronic Frontier Foundation
1
"Advanced Encryption Standard." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Advanced_Encryption_Standard
3
4
"Data Encryption Standard." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Data_Encryption_Standard
2
179
collaborated to publicly break a DES key in 22 hours and 15 minutes (see chronology). There are also
some analytical results which demonstrate theoretical weaknesses in the cipher, although they are
unfeasible to mount in practice. The algorithm is believed to be practically secure in the form of Triple
DES, although there are theoretical attacks. In recent years, the cipher has been superseded by the
5
Advanced Encryption Standard (AES).
In some documentation, a distinction is made between DES as a standard and DES the algorithm
which is referred to as the DEA (the Data Encryption Algorithm). When spoken, "DES" is either spelled
6
out as an abbreviation (/#di##i###s/), or pronounced as a one-syllable acronym (/#d#z/).
A.2. Cifrado de llave pública
Public-key cryptography is a cryptographic approach, employed by many cryptographic algorithms
and cryptosystems, whose distinguishing characteristic is the use of asymmetric key algorithms
instead of or in addition to symmetric key algorithms. Using the techniques of public key-private key
cryptography, many methods of protecting communications or authenticating messages formerly
unknown have become practical. They do not require a secure initial exchange of one or more
secret keys as is required when using symmetric key algorithms. It can also be used to create digital
7
signatures.
Public key cryptography is a fundamental and widely used technology around the world, and is the
approach which underlies such Internet standards as Transport Layer Security (TLS) (successor to
8
SSL), PGP and GPG.
The distinguishing technique used in public key cryptography is the use of asymmetric key algorithms,
where the key used to encrypt a message is not the same as the key used to decrypt it. Each user has
a pair of cryptographic keys — a public key and a private key. The private key is kept secret, whilst
the public key may be widely distributed. Messages are encrypted with the recipient's public key and
can only be decrypted with the corresponding private key. The keys are related mathematically, but the
private key cannot be feasibly (ie, in actual or projected practice) derived from the public key. It was
the discovery of such algorithms which revolutionized the practice of cryptography beginning in the
9
middle 1970s.
In contrast, Symmetric-key algorithms, variations of which have been used for some thousands of
years, use a single secret key shared by sender and receiver (which must also be kept private, thus
accounting for the ambiguity of the common terminology) for both encryption and decryption. To use a
10
symmetric encryption scheme, the sender and receiver must securely share a key in advance.
Because symmetric key algorithms are nearly always much less computationally intensive, it is
common to exchange a key using a key-exchange algorithm and transmit data using that key and
a symmetric key algorithm. PGP, and the SSL/TLS family of schemes do this, for instance, and are
11
called hybrid cryptosystems in consequence.
A.2.1. Diffie-Hellman
Diffie–Hellman key exchange (D–H) is a cryptographic protocol that allows two parties that
have no prior knowledge of each other to jointly establish a shared secret key over an insecure
5
7
"Public-key Encryption." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Public-key_cryptography
8
9
10
11
6
180
RSA
communications channel. This key can then be used to encrypt subsequent communications using a
12
symmetric key cipher.
A.2.1.1. La historia de Diffie-Hellman
The scheme was first published by Whitfield Diffie and Martin Hellman in 1976, although it later
emerged that it had been separately invented a few years earlier within GCHQ, the British signals
intelligence agency, by Malcolm J. Williamson but was kept classified. In 2002, Hellman suggested the
algorithm be called Diffie–Hellman–Merkle key exchange in recognition of Ralph Merkle's contribution
13
to the invention of public-key cryptography (Hellman, 2002).
Although Diffie–Hellman key agreement itself is an anonymous (non-authenticated) key-agreement
protocol, it provides the basis for a variety of authenticated protocols, and is used to provide perfect
forward secrecy in Transport Layer Security's ephemeral modes (referred to as EDH or DHE
14
depending on the cipher suite).
U.S. Patent 4,200,770, now expired, describes the algorithm and credits Hellman, Diffie, and Merkle
15
as inventors.
A.2.2. RSA
In cryptography, RSA (which stands for Rivest, Shamir and Adleman who first publicly described it;
see below) is an algorithm for public-key cryptography. It is the first algorithm known to be suitable for
signing as well as encryption, and was one of the first great advances in public key cryptography. RSA
is widely used in electronic commerce protocols, and is believed to be secure given sufficiently long
16
keys and the use of up-to-date implementations.
A.2.3. DSA
The Digital Signature Algorithm (DSA) is a United States Federal Government standard or FIPS for
digital signatures. It was proposed by the National Institute of Standards and Technology (NIST) in
August 1991 for use in their Digital Signature Standard (DSS), specified in FIPS 186, adopted in 1993.
A minor revision was issued in 1996 as FIPS 186-1. The standard was expanded further in 2000 as
17
FIPS 186-2 and again in 2009 as FIPS 186-3.
A.2.4. SSL/TLS
TLS (Transport Layer Security) y su predecesor, SSL (Secure Socket Layer), son protocolos de
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
12
"Diffie-Hellman." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Diffie-Hellman
14
15
16
"RSA" Wikipedia 14 April 2010 http://en.wikipedia.org/wiki/RSA
17
"Digital Signature Algorithm" Wikipedia 14 April 2010 http://en.wikipedia.org/wiki/Digital_Signature_Algorithm
13
181
confidencialidad de las comunicaciones sobre Internet utilizando criptografía. TLS ofrece seguridad
RSA con potencia de 1024 y de 2048 bits.
In typical end-user/browser usage, TLS authentication is unilateral: only the server is authenticated
(the client knows the server's identity), but not vice versa (the client remains unauthenticated or
anonymous).
TLS also supports the more secure bilateral connection mode (typically used in enterprise
applications), in which both ends of the "conversation" can be assured with whom they are
communicating (provided they diligently scrutinize the identity information in the other party's
certificate). This is known as mutual authentication, or 2SSL. Mutual authentication requires that the
TLS client-side also hold a certificate (which is not usually the case in the end-user/browser scenario).
Unless, that is, TLS-PSK, the Secure Remote Password (SRP) protocol, or some other protocol is
used that can provide strong mutual authentication in the absence of certificates.
Generalmente, la 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 operates in modular fashion. It is extensible by design, with support for forward and backward
18
compatibility and negotiation between peers.
A.2.5. Criptosistema de Cramer-Shoup
The Cramer–Shoup system is an asymmetric key encryption algorithm, and was the first efficient
scheme proven to be secure against adaptive chosen ciphertext attack using standard cryptographic
assumptions. Its security is based on the computational intractability (widely assumed, but not proved)
of the decisional Diffie–Hellman assumption. Developed by Ronald Cramer and Victor Shoup in 1998,
it is an extension of the Elgamal cryptosystem. In contrast to Elgamal, which is extremely malleable,
Cramer–Shoup adds additional elements to ensure non-malleability even against a resourceful
attacker. This non-malleability is achieved through the use of a collision-resistant hash function and
19
additional computations, resulting in a ciphertext which is twice as large as in Elgamal.
A.2.6. Cifrado ElGamal
In cryptography, the ElGamal encryption system is an asymmetric key encryption algorithm for publickey cryptography which is based on the Diffie-Hellman key agreement. It was described by Taher
Elgamal in 1985.[1] ElGamal encryption is used in the free GNU Privacy Guard software, recent
versions of PGP, and other cryptosystems. The Digital Signature Algorithm is a variant of the ElGamal
20
signature scheme, which should not be confused with ElGamal encryption.
18
"Transport Layer Security" Wikipedia 14 April 2010 http://en.wikipedia.org/wiki/Transport_Layer_Security
"Cramer–Shoup cryptosystem" Wikipedia 14 April 2010 http://en.wikipedia.org/wiki/Cramer-Shoup_cryptosystem
20
"ElGamal encryption" Wikipedia 14 April 2010 http://en.wikipedia.org/wiki/ElGamal_encryption
19
182
Apéndice B. Historial de revisiones
Revisión
Sat October 6 2012
Eric Christensen
18.0-1
[email protected]
Fixed Basic Hardening chapter (BZ 841825 and 693620).
Fixed broken LUKS link (BZ 846299).
Added GUI section to 7 Zip chapter (BZ 854781).
Fixed yum-plugin-security chapter (BZ 723282).
Fixed GPG CLI command screen (BZ 590493).
Improved Yubikey section (BZ 644238).
Fixed typos (BZ 863636).
Removed wiki markup found in some chapters.
Updated the Seahorse instructions.
Revisión
Tue January 24 2012
17.0-1
Branched for Fedora 17.
Eric Christensen
[email protected]
Revisión
Fri September 09 2011
16.0-1
Branched for Fedora 16.
Eric Christensen
[email protected]
Revisión
Sat Apr 02 2011
Eric Christensen
14.3-1
[email protected]
Moved VPN text to the Encryption chapter and reformated.
Revisión
Wed Oct 20 2010
Zach Oglesby
14.2-1
[email protected]
Added text for using Yubikey on Fedora with local authentication. (BZ 644999)
Revisión
Fri Oct 6 2010
Eric Christensen
14.2-0
[email protected]
Eliminadas todas las variantes de la fuente del documento.
Revisión
Fri Oct 1 2010
Eric Christensen
14.1-2
[email protected]
Corregido y actualizado el enlace a la Lista de verificación Unix de DISA.
Revisión
Wed Jul 8 2010
14.1-1
Agregado el capítulo relacionado con CVE.
Eric Christensen
[email protected]
183
Revisión
Fri May 28 2010
14.0-1
Agregado en la rama Fedora 14.
Eric Christensen
[email protected]
Revisión
Fri May 14 2010
Eric Christensen
13.0-7
[email protected]
Removed "bug" text from 7-Zip chapter per bug 591980.
Revisión
Wed Apr 14 2010
Eric Christensen
13.0-6
[email protected]
Completado el apéndice sobre estándares de cifrado.
Revisión
Fri Apr 09 2010
13.0-5
Added "Using GPG with Alpine".
Added "Using GPG with Evolution".
Eric Christensen
[email protected]
Revisión
Tue Apr 06 2010
Eric Christensen
13.0-4
[email protected]
Solucionados problemas relacionados con textos imposibles de traducir en para.
Revisión
Tue Apr 06 2010
Eric Christensen
13.0-3
[email protected]
Eliminado el texto de la vulnerabilidad de PackageKit en Fedora 12.
Revisión
13.0-2
Fri Nov 20 2009
Eric Christensen
[email protected]
Agregado el Historial de revisiones al final del documento.
Agregado el apéndice Estándares de cifrado
Revisión
Fri Nov 20 2009
13.0-1
Rama de Fedora 13.
Eric Christensen
[email protected]
Revisión
Thu Nov 19 2009
Eric Christensen
1.0-23
[email protected]
Updated the section "Local users may install trusted packages" to the latest fix, again.
Revisión
1.0-22
184
Thu Nov 19 2009
Eric Christensen
[email protected]
Updated the section "Local users may install trusted packages" to the latest fix.
Revisión
Wed Nov 18 2009
Eric Christensen
1.0-21
[email protected]
Added section "Local users may install trusted packages".
Revisión
Sat Nov 14 2009
Eric Christensen
1.0-20
[email protected]
Agregada información desde Wikipedia al apéndice Estándares de cifrado
Agregado Adam Ligas a la página de autores por su rol en el desarrollo de las porciones de 7-Zip.
Revisión
Mon Oct 26 2009
1.0-19
Actualizada la licencia a CC-BY-SA
Eric Christensen
[email protected]
Revisión
Wed Aug 05 2009
Eric Christensen
1.0-18
[email protected]
Solucinados los inconvenientes relacionados con el Bug 515043
Revisión
Mon Jul 27 2009
Eric Christensen
1.0-17
[email protected]
Información del proveedor en SPEC reparada.
Revisión
Fri Jul 24 2009
Fedora Ingeniería de lanzamiento
1.0-16
[email protected]
Recompilación para https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
Revisión
Tue Jul 14 2009
Eric Christensen
1.0-15
[email protected]
Added "desktop-file-utils" to BUILDREQUIRES on the spec
Revisión
Tue Mar 10 2009
Scott Radvan [email protected]
1.0-14
Remove more rhel specifics, major review and remove draft, ready for push
Revisión
Mon Mar 2 2009
1.0-13
Muchas correcciones menores
Revisión
1.0-12
Wed Feb 11 2009
185
nuevos pantallazos de F11 que reemplazan las anteriores/más viejas
Revisión
Tue Feb 03 2009
1.0-11
LUKS específico a Fedora 9 modificado para incluir las versiones posteriores también.
Corrección de los errores 404 en la sección de referencias, principalmente por enlaces incorrectos
a NSA.
cambios de formatos menores.
Revisión
Wed Jan 27 2009
Eric Christensen
1.0-10
[email protected]
Se corrigió la falta de un pantallazo de la configuración del cortafuego.
Revisión 1.0-9 Wed Jan 27 2009
Eric Christensen
[email protected]
Se repararon items que estaban incorrectos durante la validación. Muchas referencias de Red Hat
se cambiaron a referencias de Fedora.
186

Guía de seguridad - Fedora Documentation

Transcripción

Documentos relacionados

Enunciado del proyecto - Departamento de Ingeniería de Sistemas

recomendado para niños de 8 años en adelante