LE301 Seguridad 1 - Seguridad Local v2-10

LE-301 Seguridad 1 - Seguridad local

Índice de contenido

Introducción a la seguridad computacional..........................................................................9Definición de Seguridad computacional...............................................................................10Estandarizar la seguridad.....................................................................................................10Controles de seguridad.........................................................................................................10

Controles físicos...............................................................................................................11Controles técnicos............................................................................................................11Controles administrativos.................................................................................................12

Una breve historia sobre los hackers...................................................................................12Amenazas de seguridad de servidores................................................................................12Encriptación de datos...........................................................................................................13

Criptografía simétrica.......................................................................................................14Algoritmos simétricos...................................................................................................15

Criptografía asimétrica.....................................................................................................17Algoritmos asimétricos.................................................................................................18

Algoritmos Hash...............................................................................................................19Fuentes de Seguridad..........................................................................................................21

Actualizaciones de seguridad...............................................................................................22Introducción..........................................................................................................................23Portal de Clientes, Red Hat Network y RHN Classic...........................................................23

Utilización del Red Hat Network.......................................................................................26Utilización de RHN Classic...............................................................................................29

Yellow Dog Updater, Modified (YUM)...................................................................................31Consideraciones especiales cuando actualiza el sistema...................................................33Utilización del sitio web de seguridad de Red Hat...............................................................34Seguridad de los paquetes RPM..........................................................................................35

Paquetes firmados digitalmente.......................................................................................35Verificar paquetes firmados.........................................................................................35Instalación de paquetes firmados................................................................................36

Verificación de paquetes rpm...........................................................................................37Seguridad de inicio, contraseñas y la cuenta root..............................................................39

Seguridad del BIOS y del gestor de arranque.....................................................................40 Contraseñas del BIOS.....................................................................................................40 Contraseñas del gestor de arranque...............................................................................40Protegiendo GRUB con contraseñas...............................................................................41

Seguridad de contraseñas....................................................................................................41Creación de contraseñas robustas..................................................................................42Metodología para la creación de contraseñas seguras...................................................43Envejecimiento de las contraseñas..................................................................................43

Forzar el cambio de contraseñas.....................................................................................44Desactivación del acceso root..............................................................................................44

Deshabilitar el shell de root..............................................................................................44Deshabilitar las conexiones root......................................................................................44Deshabilitar conexiones root SSH...................................................................................45Limitar el acceso root.......................................................................................................45El comando su..................................................................................................................45

Super User DO (Sudo).........................................................................................................46El fichero /etc/sudoers......................................................................................................46Estructura del archivo sudoers.........................................................................................46Definiciones de alias........................................................................................................47Ajuste de opciones...........................................................................................................47Reglas de acceso.............................................................................................................48Consideraciones de seguridad.........................................................................................50Funcionalidades que no se han comentado....................................................................50

Pluggable Authentication Module.........................................................................................52Introducción a PAM..............................................................................................................53Archivos de configuración de PAM......................................................................................53Sintaxis del archivo de configuración...................................................................................54Los archivos *-auth...............................................................................................................55Política por defecto...............................................................................................................56Módulos PAM........................................................................................................................57

Módulo pam_access........................................................................................................57Grupos de gestión........................................................................................................57Dependencias..............................................................................................................57Argumentos reconocidos.............................................................................................58Ejemplos/uso sugerido.................................................................................................58

Módulo pam_cracklib.......................................................................................................59Grupos de gestión........................................................................................................59Dependencias..............................................................................................................59Argumentos reconocidos.............................................................................................59Ejemplos/uso sugerido.................................................................................................60

Modulo pam_limits............................................................................................................60Grupos de gestión........................................................................................................60Dependencias..............................................................................................................60Argumentos..................................................................................................................62Ejemplos/uso sugerido.................................................................................................62

Módulo pam_deny............................................................................................................62Grupos administrativos................................................................................................63Ejemplos/uso sugerido.................................................................................................63

Módulo pam_lastlog.........................................................................................................63

Grupos administrativos................................................................................................63Dependencias del sistema...........................................................................................63Argumentos..................................................................................................................64Ejemplos/uso sugerido.................................................................................................64

Módulo pam_listfile...........................................................................................................64Grupos de gestión........................................................................................................64Argumentos..................................................................................................................64Ejemplos/uso sugerido.................................................................................................65

Módulo pam_mail.............................................................................................................65Dependencias del sistema...........................................................................................65Grupos administrativos................................................................................................65Argumentos..................................................................................................................65Ejemplos/uso sugerido.................................................................................................66

Modulo pam_mkhomedir..................................................................................................66Grupos administrativos................................................................................................66Argumentos..................................................................................................................66Ejemplos/uso sugerido.................................................................................................66

Módulo pam_nologin........................................................................................................67Grupos de gestión........................................................................................................67Ejemplos/uso sugerido.................................................................................................67

Módulo pam_permit..........................................................................................................67Grupos de gestión........................................................................................................67Ejemplos/uso sugerido.................................................................................................67

Módulo pam_rootok..........................................................................................................68Grupos de gestión........................................................................................................68Ejemplos/uso sugerido.................................................................................................68

Módulo pam_securetty.....................................................................................................68Grupos de gestión........................................................................................................68Ejemplos/uso sugerido.................................................................................................68

Módulo pam_tally2...........................................................................................................68Grupos de gestión........................................................................................................69Dependencias..............................................................................................................69Argumentos .................................................................................................................69Componente authentication.........................................................................................69Componente account...................................................................................................70Ejemplos/uso sugerido.................................................................................................70

Módulo pam_time.............................................................................................................70Grupos de gestión........................................................................................................71Dependencias..............................................................................................................71Ejemplos/uso sugerido.................................................................................................72

Módulo pam_unix.............................................................................................................72

Grupos de gestión........................................................................................................72Componente account...................................................................................................73Componente authentication.........................................................................................73Componente password................................................................................................73Componente session...................................................................................................74

Modulo pam_warn............................................................................................................75Grupos de gestión........................................................................................................75Ejemplos/uso sugerido.................................................................................................75

Módulo pam_wheel..........................................................................................................75Grupos de gestión........................................................................................................75Argumentos..................................................................................................................75Ejemplo/uso sugerido...................................................................................................76

Módulo pam_ldap.............................................................................................................76Grupos de gestión........................................................................................................76Dependencias..............................................................................................................76Argumentos..................................................................................................................76Ejemplo/uso sugerido...................................................................................................77

Módulo pam_smb_auth....................................................................................................77Grupos de gestión........................................................................................................77Argumentos..................................................................................................................77Ejemplo/uso sugerido...................................................................................................78

Auditoria del sistema..............................................................................................................79Introducción..........................................................................................................................80Uso del subsistema de auditoria..........................................................................................80Selección de eventos a ser auditados..................................................................................81Reglas de auditoria...............................................................................................................81Leyendo y buscando registros de auditoria..........................................................................83Almacenamiento de los registros de auditoria.....................................................................86Visor de auditoría..................................................................................................................88Almacenamiento remoto de los registros de auditoria.........................................................91

AIDE..........................................................................................................................................92Introducción..........................................................................................................................93Instalación de AIDE..............................................................................................................93Configuración de AIDE.........................................................................................................93

Líneas macro....................................................................................................................94Líneas de configuración...................................................................................................94Lineas de selección..........................................................................................................95

Utilización de AIDE...............................................................................................................98GnuPG....................................................................................................................................100

Introducción........................................................................................................................101Generar un nuevo par de claves........................................................................................102

Generar un certificado de revocación................................................................................104Intercambiar claves.............................................................................................................105

Exportar una clave pública.............................................................................................105Importar una clave pública.............................................................................................106

Cifrar y descifrar documentos.............................................................................................107Firmar y verificar firmas......................................................................................................107

Documentos con firmas ASCII.......................................................................................108Firmas acompañantes....................................................................................................108

Incorporación de gpg al cliente de correo electrónico.......................................................109Incorporando gpg a Mozilla Thunderbird.......................................................................109Incorporando gpg a Evolution........................................................................................112

Recuperación ante desastres..............................................................................................115Introducción........................................................................................................................116La herramienta de reporte del sistema cfg2html................................................................116

Instalación y configuración de cfg2html.........................................................................117Ejecución de cfg2html....................................................................................................117

Mondo Rescue....................................................................................................................117Mindi....................................................................................................................................118Instalación de Mondo.........................................................................................................118Respaldando datos con Mondo..........................................................................................118Restaurando datos con Mondo..........................................................................................122

Security Enhanced Linux.....................................................................................................123Introducción........................................................................................................................124Contextos de seguridad......................................................................................................126

Examinando los contextos de seguridad.......................................................................126Modelo de seguridad basado en dominios........................................................................126Control de acceso TE.........................................................................................................127

Ejemplo de TE................................................................................................................127Transición de dominios.......................................................................................................128

Transición de dominio por defecto.................................................................................130La función de los roles........................................................................................................130 Contexto de seguridad del sistema de archivos...............................................................131

Copiar o mover archivos................................................................................................131Re-etiquetar un archivo o directorio ..............................................................................132Haciendo los cambios de contexto de seguridad permanente......................................133

Política SELinux Targeted..................................................................................................133Administración de SELinux.................................................................................................134

Verificación del estado de SELinux...............................................................................134Modificando el modo de operación de SELinux............................................................134Booleans.........................................................................................................................135Dominios permisivos......................................................................................................135

Habilitar o deshabilitar SELinux.....................................................................................136Realizando copias de seguridad de atributos extendidos.............................................136Entendiendo un mensaje avc: denied............................................................................137Setroubleshoot...............................................................................................................138Realizando personalizaciones menores a una política existente..................................138

Utilizando audit2allow Red Hat/CentOS Enterprise 5 o superior .............................138SELinux y los servicios de red.......................................................................................140

NIS y SELinux............................................................................................................140NFS y SELinux...........................................................................................................140Samba y SELinux ......................................................................................................141Apache y SELinux......................................................................................................142FTP y SELinux...........................................................................................................142

Seguridad del sistema de archivos.....................................................................................143Opciones de montado de sistema de archivos..................................................................144Permisos por defecto de los archivos................................................................................145Grupos de usuario privado.................................................................................................146

Directorios de grupos.....................................................................................................147Archivos SUID y SGID........................................................................................................148Directorios Sticky................................................................................................................148Permisos de escritura global..............................................................................................148Archivos huérfanos.............................................................................................................149Archivos peligrosos.............................................................................................................149Archivos extraños...............................................................................................................149El comando chattr...............................................................................................................150Listas de acceso con ACL..................................................................................................151

Modificando las listas de acceso....................................................................................152ACLs por defecto............................................................................................................153Deshaciendo los cambios de las listas de acceso.........................................................153Copias de seguridad de archivos con ACLs..................................................................153

Borrado de datos del disco de forma segura.....................................................................153Implementación de cuotas de disco...................................................................................154

Configuración de cuotas de disco..................................................................................155Volver a montar un sistema de archivos........................................................................155Creación de archivos de cuotas.....................................................................................155Asignación de cuotas por usuario..................................................................................156Asignación de cuotas por grupo.....................................................................................158Establecimiento del periodo de gracia por defecto........................................................158Informe de cuotas de disco............................................................................................158Mantenimiento de la precisión de las cuotas.................................................................158Activación y desactivación de cuotas.............................................................................159

Técnicas para mantener la seguridad del sistema...........................................................160

El shell restringido .............................................................................................................161Configuración de un shell restringido bash....................................................................162

Administración de los registros de eventos........................................................................162Servidor de registro de eventos.....................................................................................163

Configuración del servidor central syslog .................................................................163Configuración de syslog para el envío a un sistema remoto.....................................163

Logwatch........................................................................................................................164La herramienta swatch...................................................................................................164Archivo de registro de sesiones de usuarios.................................................................166

El archivo utmp, wtmp y btmp....................................................................................166El archivo lastlog........................................................................................................166El archivo faillog.........................................................................................................166

Configuración del acceso de consola.................................................................................167Deshabilitar el apagado a través de Ctrl-Alt-Supr..........................................................167Deshabilitar el acceso desde la consola a programas..................................................168

Deshabilitar el apagado del sistema desde GDM..............................................................168Herramientas de integridad de archivos.............................................................................169Cifrado de información en disco.........................................................................................169

El Device Mapper y DM-Crypt........................................................................................169Linux Unified Key Setup (LUKS)....................................................................................170Encriptación de un disco................................................................................................170Montado de un disco encriptado durante el inicio del sistema......................................173

The Center for Internet Security – CIS Benchmark...........................................................174

1Introducción a la seguridad computacional

Introducción a la seguridad computacional

Definición de Seguridad computacional

La seguridad de computación es un término general que cubre una gran área de computación y procesamiento de la información. Las industrias que dependen de sistemas computarizados y redes para ejecutar sus operaciones y transacciones de negocios diarias, consideran sus datos como una parte importante de sus activos generales. Muchos términos y medidas se han incorporado a nuestro vocabulario diario en los negocios, tales como costo total de propiedad (total cost of ownership, TCO) y calidad de servicios (QoS). Con estas medidas, las industrias calculan aspectos tales como integridad de los datos y alta disponibilidad como parte de los costos de planificación y administración de procesos. En algunas industrias, como el comercio electrónico, la disponibilidad y confianza de los datos pueden hacer la diferencia entre el éxito y el fracaso.

Estandarizar la seguridad

Muchos consultores de seguridad y fabricantes acuerdan con el modelo de seguridad estándar conocido como CIA, o Confidentiality, Integrity, and Availability, esto es: Confidencialidad, Integridad y Disponibilidad. Este modelo de tres niveles es un componente aceptado en general para asesorar riesgos a la información confidencial y para establecer políticas de seguridad. Lo siguiente describe el modelo de CIA en mayor detalle:

● Confidencialidad - La información confidencial sólo debería estar disponible a un conjunto de individuos predefinido. Las transmisiones no autorizadas y el uso de información debería ser restringido. Por ejemplo, la confidencialidad de la información asegura que la información personal o financiera de un cliente no sea obtenida por individuos no autorizados para propósitos maliciosos, tales como robo de identidad o fraude con tarjetas de crédito.

● Integridad - La información no debería ser alterada en formas que la hagan incompleta o incorrecta. Los usuarios no autorizados deberían ser restringidos de la habilidad de modificar o destruir información confidencial.

● Disponibilidad - La información debería estar disponible para los usuarios autorizados en cualquier momento que estos la requieran. La disponibilidad es una garantía de que la información pueda ser obtenida con la frecuencia acordada y en el momento previsto. Esto es medido a menudo en términos de porcentajes y acordado de manera formal en los Acuerdos de nivel de servicio (SLAs) usados por los proveedores de servicios de red y sus clientes corporativos.

Controles de seguridad

La seguridad computacional a menudo se divide en tres categorías maestras

Ing. Ivan Ferreira 10


distintas, comúnmente llamadas controles:

● Físico

● Técnico

● Administrativo

Estas tres amplias categorías definen los objetivos principales de una implementación de seguridad apropiada. Dentro de estos controles hay sub-categorías que detallan aún más los controles y como estos se implementan.

Controles físicos

El control físico es la implementación de medidas de seguridad en una estructura definida usada para prevenir o detener el acceso no autorizado a material confidencial. Ejemplos de los controles físicos son:

● Cámaras de circuito cerrado

● Sistemas de alarmas térmicos o de movimiento

● Guardias de seguridad

● Identificación con fotos

● Puertas de acero con seguros especiales

● Biométrica (incluye huellas digitales, voz, rostro, iris, escritura a mano y otros métodos automatizados utilizados para reconocer individuos)

Controles técnicos

Los controles técnicos utilizan la tecnología como una base para controlar el acceso y uso de datos confidenciales a través de una estructura física y sobre la red. Los controles técnicos son mucho más extensos en su ámbito e incluyen tecnologías tales como:

● Encriptación

● Tarjetas inteligentes

● Autenticación a nivel de la red

● Listas de control de acceso (ACLs)

● Software de auditoria de integridad de archivos

11 Red Hat Certified Engineer


Controles administrativos

Los controles administrativos definen los factores humanos de la seguridad. Incluye todos los niveles del personal dentro de la organización y determina cuáles usuarios tienen acceso a qué recursos e información usando medios tales como:

● Entrenamiento y conocimiento

● Planes de recuperación y preparación para desastres

● Estrategias de selección de personal y separación

● Registro y contabilidad de personal

Una breve historia sobre los hackers

El significado moderno del término hacker tiene sus origenes en los años 60 y en el Club de Modelaje de Trenes del Instituto de Tecnología de Massachusetts (MIT), que diseñaban conjuntos de trenes de gran escala y detalle. Hacker fue el nombre usado para nombrar aquellos miembros del club que descubrían un truco brillante o que resolvían un problema muy complicado.

Desde ese momento el término hacker se ha utilizado para describir cualquier cosa desde un aficionado a las computadoras hasta un programador virtuoso. Un rasgo característico de un hacker es su disposición de explorar en detalle cómo funcionan los sistemas de computación con poca o ninguna motivación externa. Los desarrolladores de software de la comunidad de Código Abierto (Open Source), a menudo se consideran a ellos mismos y a sus colegas como hackers, como una forma de respeto.

Típicamente, los hackers siguen una forma de ética de hackers que dicta que la búsqueda de información y experiencia es esencial y que compartir ese conocimiento es el compromiso de todo hacker con la comunidad. Durante esa búsqueda de conocimiento, algunos hackers disfrutan los retos académicos de burlar los controles de seguridad en sistemas de computación. Por esta razón, la prensa usualmente utiliza este término para describir aquellos que accesan sistemas y redes ilegalmente sin escrúpulos, con intenciones maliciosas o criminales. El término más adecuado para este tipo de hacker de computadoras es cracker o maleante informático (también se les conoce como pirata informático, ciberpirata, etc.)— un término creado por los hackers en la mitad de los 80 para diferenciar a las dos comunidades.

Amenazas de seguridad de servidores

Una de las amenazas más grandes a la seguridad de los servidores son los administradores distraídos que olvidan parchar sus sistemas. De acuerdo al Instituto



de Seguridad y Administración de Sistemas de Redes (System Administration Network and Security Institute, SANS), la causa primaria de la vulnerabilidad de seguridad de los sistemas es “asignar personal poco entrenado para mantener la seguridad y no proporcionar ni el entrenamiento ni el tiempo para permitir que ejecuten su trabajo” Esto aplica tanto a los administradores nuevos como a aquellos demasiado confiados o poco motivados.

Algunos administradores fallan en parchar sus servidores y estaciones de trabajo, mientras que otros fallan en leer los mensajes del registro de eventos del kernel del sistema o tráfico de la red. Otro error común es dejar las contraseñas o llaves a servicios sin modificar. Por ejemplo, algunas bases de datos tienen contraseñas administrativas por defecto porque sus desarrolladores asumen que el administrador de sistemas cambiará estas contraseñas inmediatamente luego de la instalación. Si un administrador de bases de datos no cambia las contraseñas, hasta un cracker sin mucha experiencia puede utilizar una contraseña conocida por todo el mundo para ganar acceso con privilegios administrativos a la bases de datos. Estos son sólo unos ejemplos de como una administración descuidada puede llevar a servidores comprometidos.

Es muy común entre los administradores de sistemas realizar una instalación del sistema operativo sin prestar atención a qué programas están siendo realmente instalados. Esto puede ser problemático puesto que se pueden instalar servicios innecesarios, configurados con sus valores por defecto y, posiblemente activados por defecto.

Además, las malas contraseñas son una de las formas más fáciles para que un atacante obtenga el acceso a un sistema.

El robo de información corporativa es altamente peligroso. El robo de unos pocos archivos puede destruir, de la noche a la mañana, la reputación que tanto esfuerzo costó construir (imagine un banco que pierde un archivo con el monto de depósitos de cada uno de sus clientes). En otros casos, la filtración de datos confidenciales puede revelar decisiones estratégicas a la competencia y hasta generar problemas legales.

Encriptación de datos

Existen distintos tipos de algoritmos de encriptación, pero algo que no se ha mencionado hasta ahora son los “algoritmos” que se cree que encriptan, pero que no hacen nada más que transformar texto (o información). El objetivo de hacer esta distinción es mostrar algunas malas prácticas que se cometen, pensando que cualquier algoritmo que cambia de cierta forma un texto, está realizando encriptación de datos. Estos algoritmos podremos llamarlos simplemente "Transformaciones".

Antes de revisar los escenarios, se debe aclarar el concepto de llave. La llave de



encriptación es una serie de carácteres, de determinado largo, que se utiliza para encriptar y desencriptar la información que se quiere proteger. El largo de la llave depende del algoritmo. Existen llaves privadas y públicas, que serán detalladas más adelante. Veamos los siguientes escenarios.

● Escenario 1: Necesito almacenar información crítica que deberá poder descifrarse, y seré yo el único que haga todo el proceso. Nadie más tendrá acceso a la llave con que se encriptará y desencriptará la información.

● Escenario 2: Necesito que me envíen información crítica que yo desencriptaré posteriormente, pero necesito que las personas que me van a enviar información pueden encriptarla libremente, pero no desencriptarla. En este caso, se deja disponible una llave pública para que ellos encripten y yo tendré mi llave privada de encriptación en forma segura.

● Escenario 3: Necesito almacenar o enviar información crítica de forma segura, pero que no requerirá ser desencriptada para su validación, o que es extremadamente importante verificar que no haya sido modificada en el camino.

Estos son los tres escenarios más comunes. Los tres escenarios calzan con los algoritmos listados a continuación:

● Escenario 1: Encriptación simétrica

● Escenario 2: Encriptación asimétrica

● Escenario 3: Hash de información

Criptografía simétrica

Cuando hablamos de encriptación y no de transformación, ya estamos adentrándonos en temas de mayor protección, de algoritmos conocidos y seguridad real. El proceso de realizar una encriptación es complejo para ser entendido por nosotros mismos, pero no es limitante para conocer cuáles son los pasos para utilizarlos y qué errores no se deben cometer.

Utiliza una clave para la encriptación y desencriptación del mensaje. Esta clave se debe intercambiar entre los equipos por medio de un canal seguro. Ambos extremos deben tener la misma clave para cumplir con le proceso.



Las principales desventajas de los métodos simétricos son la distribución de las claves, el peligro de que muchas personas deban conocer una misma clave y la dificultad de almacenar y proteger muchas claves diferentes.

Algoritmos simétricos

Dentro de los algoritmos de encriptación simétrica podemos encontrar los siguientes, algunos más seguros que otros.

● DES (Digital Encryption Standard) Creado en 1975 con ayuda de la NSA (National Security Agency); en 1982 se convirtió en un estándar. En el cifrado DES, se usa una clave de 64 bits para cifrar los bloques, aunque en realidad sólo se usan 56 bits. Los 8 bits restantes de la clave son usados para comprobar la paridad y después son descartados. En 1999 logró ser quebrado (violado) en menos de 24 horas por un servidor dedicado a eso. Esto lo calificó como un algoritmo inseguro y con falencias reconocidas.

● 3DES (Three DES o Triple DES) Antes de ser quebrado el DES, ya se trabajaba en un nuevo algoritmo basado en el anterior. Este funciona aplicando tres veces el proceso con tres llaves diferentes de 56 bits. La importancia de esto es que si alguien puede descifrar una llave, es casi imposible poder descifrar las tres y utilizarlas en el orden adecuado. Hoy en día es uno de los algoritmos simétricos más seguros.

● IDEA (International Data Encryption Algorithm) Más conocido como un componente de PGP, trabaja con llaves de 128 bits. Realiza procesos de intercambio, copiado y pegado de los 128 bits, dejando un total de 52 sub



llaves de 16 bits cada una. La principal razón por la que IDEA no reemplazó a DES es simplemente porque esta patentado y debe ser licenciado para su uso comercial.

● AES (Advanced Encryption Standard) Este fue el ganador del primer concurso de algoritmos de encriptación realizado por la NIST (National Institute of Standards and Technology) en 1997. Después de 3 años de estudio y habiendo descartado a 14 candidatos, este algoritmo, también conocido como Rijndael por Vincent Rijmen y Joan Daemen, fue elegido como ganador. Desde 2006, el AES es uno de los algoritmos más populares usados en criptografía simétrica.

El algoritmo más seguro hoy el AES, aunque 3DES también es muy seguro. Este último se utiliza cuando hay necesidad de compatibilidad. AES 128 es aproximadamente 15% más rápido que DES, y AES 256 sigue siendo más rápido que DES.

Cualquiera de estos algoritmos utiliza los siguientes dos elementos; ninguno de los dos debe pasarse por alto ni subestimar su importancia:

● IV (Vector de inicialización) Esta cadena se utiliza para empezar cada proceso de encriptación. Esto permite que textos planos idénticos resulten en textos cifrados completamente diferentes.

● Key (llave) Esta es la principal información para encriptar y desencriptar en los algoritmos simétricos. Toda la seguridad del sistema depende de dónde esté esta llave, cómo esté compuesta y quién tiene acceso. El número de posibles llaves que cada algoritmo puede soportar depende del número de bits en la llave. Por ejemplo, una llave de 8 bits sólo permite 2^8=256 posibles combinaciones numéricas, cada una de las cuales también es llamada llave. Entre mayor sea el número de posibles llaves, más difícil será descifrar un mensaje encriptado. El nivel de dificultad depende, por lo tanto, de la longitud de la llave. Una computadora no necesita mucho tiempo para probar secuencialmente cada una de las 256 llaves posibles (menos de un milisegundo) y desencriptar el mensaje para ver si éste cobra sentido. Sin embargo, si se usara una llave de 100 bits (que equivale a examinar 2^100 llaves), una computadora que pruebe un millón de llaves cada segundo podría tardar muchos siglos en descubrir la llave correcta.

La forma más antigua de criptografía basada en llave se denomina "llave secreta" o "encriptamiento simétrico". En este esquema, el emisor y el receptor poseen la misma llave, lo que significa que ambas partes pueden encriptar y desencriptar datos con la llave.



Algoritmo Longitud (bits)DES 64TripleDES (3DES) 192IDEA 128AES 256

Criptografía asimétrica

La encriptación asimétrica permite que dos personas puedan enviarse información encriptada, sin necesidad de compartir la llave de encriptación. Se utiliza una llave pública para encriptar el texto y una llave privada para desencriptar. A pesar de que puede sonar extraño que se encripte con la llave pública y desencripte con la privada, el motivo para hacerlo es el siguiente: si alguien necesita que le envíen la información encriptada, deja disponible la llave pública para que quienes le desean enviar algo lo encripten. Nadie puede desencriptar algo con la misma llave pública. El único que puede desencriptar es quien posea la llave privada, quien justamente es el que recibe la información encriptada.



Algoritmos asimétricos

Los algoritmos de encriptación asimétrica más conocidos son RSA, DSA, DH y ECC.

● Diffie-Hellman (& Merkle) El algoritmo Diffie-Hellman permite que dos partes, comunicándose mediante un canal no cifrado, se pongan de acuerdo en un valor numérico sin que un tercero, que tiene acceso completo a la conversación, pueda conocerlo o calcularlo, al menos en un tiempo práctico.

● RSA (Rivest, Shamir, Adleman) Creado en 1978, hoy es el algoritmo de mayor uso en encriptación asimétrica. El sistema criptográfico con clave pública RSA es un algoritmo asimétrico cifrador de bloques, que utiliza una clave pública, la cual se distribuye (en forma autenticada preferentemente), y otra privada, la cual es guardada en secreto por su propietario. Cuando se quiere enviar un mensaje, el emisor busca la clave pública de cifrado del receptor, cifra su mensaje con esa clave, y una vez que el mensaje cifrado llega al receptor, éste se ocupa de descifrarlo usando su clave oculta. RSA puede además ser utilizado para autenticación de la información a través de firmas digitales, aunque resulta más útil a la hora de implementar la confidencialidad el uso de sistemas simétricos, por ser más rápidos.

● DSA (Digital Signature Algorithm o Algoritmo de Firma digital) es un algoritmo creado por el NIST (National Institute of Standards and Technology o Instituto Nacional de Normas y Tecnología de EE.UU.), publicado el 30 de agosto de 1991, como propuesta para el proceso de firmas digitales. Este algoritmo como su nombre lo indica, sirve para firmar y no para cifrar información. Una desventaja de este algoritmo es que requiere mucho más tiempo de cómputo que RSA.

● Elgamal El algoritmo ElGamal es un algoritmo para criptografía asimétrica el cual está basado en Diffie-Hellman. Fue descripto por Taher Elgamal en 1984. El algoritmo de ElGamal puede ser utilizado tanto para generar firmas digitales como para cifrar o descifrar.

● ECC (Elliptical Curve Cryptography) ECC es un algoritmo de encriptación de claves públicas basado en la teoría de curva elíptica que puede ser utilizada para crear claves de criptografía más pequeñas, rápidas y eficientes. ECC genera curvas por medio de las propiedades de la ecuación de la curva elíptica en lugar del método tradicional de generación como el producto de números primos grandes. De acuerdo con algunos investigadores, ECC puede proporcionar un nivel de seguridad equivalente a 1024 bits de otros sistemas con simplemente 164 bits.

El tamaño de la llave es el siguiente:



Algoritmo Longitud (bits)RSA 1024 - 4096DSA 1024Elgamal 1024-4096DH 1024ECC 512

Mientras más larga sea la llave, más seguro será. La relación con los algoritmos simétricos no es directa. En este caso, una llave de 1024 bits de RSA es equivalente en seguridad a una de 75 bits de un algoritmo simétrico.

Algoritmos Hash

Por último, existen los algoritmos de tipo Hash. Estos son algoritmos del tipo de los que se conocen como de sólo ida, ya que no es posible desencriptar lo que se ha encriptado. Puede ser que a primera vista no se le vea la utilidad, pero en los siguientes dos escenarios éste es el tipo de algoritmo necesario para realizar el proceso. El primero de ellos está dirigido a proteger información muy valiosa encriptando el contenido; y el segundo busca validar que no se modifique la información que se está enviando desde un lugar a otro.

● Escenario 1: Almacenar contraseñas de un sistema. Las contraseñas de cualquier sistema serio jamás debieran poder desencriptarse. El motivo es simple. Si se pueden desencriptar, el riesgo de que alguien conozca la llave y tenga acceso a todo el sistema con todos los usuarios es muy grande. Entonces, si no puedo desencriptar una contraseña, ¿Cómo puedo saber entonces si una contraseña entregada es válida? La respuesta es muy simple. Se encripta la contraseña entregada y se compara el resultado de la encriptación con la contraseña previamente almacenada.

● Escenario 2: Validar que cierta información no se haya modificado. Si se desea enviar un bloque de datos y se quiere estar seguro de que nadie lo ha modificado durante el camino, lo que se hace es enviar el bloque de información sin encriptar y además se envía un Hash/Digest de este mismo bloque de datos. Entonces, nuestro receptor al tener la información sin encriptar, le aplica un Hash y con el mismo criterio del Escenario 1, determina si ambos bloques son iguales. Si lo son, el bloque que no está con Hash es el original. ¿Porqué no usar un algoritmo de encriptación reversible? Porque éste podría ser desencriptado, modificado y vuelto a encriptar y el receptor jamás sabría que fue modificado en el camino. Como el Hash no es reversible, esto último no podrá suceder jamás.

Los algoritmos para hacer Hash mas conocidos son los siguientes:



Algoritmo Longitud del hash (bits)MD5 128SHA-1 160SHA-256 256SHA-384 384SHA-512 512

La robustez de un algoritmo de Hash es comparable a la mitad del largo del resultado en bits. Entonces, pensar que con MD5 se está seguro puede ser un error. SHA-256 es el indicado para obtener seguridad de 128 bits.

Pero a pesar de parecer muy efectivo, existe un problema con el Hash para cada uno de los escenarios indicados anteriormente.

● Problemas Escenario 1: Si bien el problema no está tan relacionado con el Hash, debido a la utilización de contraseñas de escasa dificultad, haciendo un ataque de fuerza bruta o por diccionario se podrían encontrar valores de Hash que coinciden con el Hash de las contraseñas almacenadas. Para esto se pueden ejecutar dos planes de acción independientes, pero obteniéndose el mejor resultado con la utilización de ambos.

La Solución 1 consiste en realizar varias pasadas de Hash sobre los datos, aplicándole el Hash al resultado del Hash anterior.

La Solución 2 requiere agregar un texto adicional a la contraseña. Esto se conoce como Salt. Entonces, cada vez que un usuario cambie o esté validando una contraseña, hay que concatenarle a la contraseña este Salt y de ahí generar el Hash. De esta forma le agrega variación a las contraseñas pobremente definidas.

● Problemas Escenario 2: Si alguien puede ejecutar un Hash sobre un conjunto de datos y obtener el resultado, ¿Porqué no podría modificar el contenido del documento que estamos enviando y generar el Hash nuevamente, reemplazando el contenido del Hash anterior? ¿Cómo se puede diferenciar mi proceso de Hash del proceso de Hash impostor? No es posible a menos que haya alguna llave de por medio.

Debido a lo anterior, se han inventado los siguientes algoritmos de Hash, que utilizan llaves para realizar el proceso. En este caso, si el resultado se sobrescribe, al obtener el Hash con la llave, el resultado jamás coincidirá con el que viene en el mensaje. Entre estos algoritmos se encuentran HMAC-SHA1, HMAC-MD5 y MAC-3DES-CBC.



Fuentes de Seguridad

Existe una gran cantidad de sitios buenos sobre la seguridad de Unix en general y la seguridad de Linux en particular. Es muy importante suscribirse a una (o más) de las listas de correo sobre seguridad y mantenerse al día en mejoras de seguridad. La mayoría de estas listas son de muy bajo volumen y muy informativas.

Algunas listas de correo son:

● Listas de Red Hat - Red Hat proporciona varias listas de correo a las cuales puede suscribirse. Entre la mas importante se encuentra la lista de seguridad Enterprise-watch-list. La dirección de la página web de las listas disponibles es:

http://www.redhat.com/mailman/listinfo

● Bugtraq - Sin duda la mejor lista de seguridad informática que existe en la actualidad. Es imprescindible suscribirse a ella, especialmente en el caso de administradores de sistemas Linux/Unix. Para suscribirse, envíe un mensaje a [email protected]. El contenido del asunto o el mensaje no importa. Recibirá una solicitud de confirmación a la cual deberá responder.

Algunos sitios web útiles donde puede encontrar amplia información relacionada a seguridad son:

● http://www.linuxsecurity.com - El sitio web de Linux-Specific Security (Seguridad específica) tiene una colección de enlaces Linux relacionados con la seguridad, la documentación y mucho más.

● http://www.cert.org - El sitio web de CERT ofrece una lista actualizada de incidentes y vulneralibilidades de seguridad de gran impacto, además de información detallada sobre cada aviso de seguridad y sobre cómo restablecer un sistema después de que haya sido comprometido.

● http://www.sans.org - El sitio web del Instituto de Seguridad, Redes y Administración de Sistemas (SANS) proporciona alertas de seguridad en forma de resumen, e incluye enlaces convenientes hacia RPMs actualizados (cuando están disponibles).


2Actualizaciones de seguridad

Actualizaciones de seguridad

Introducción

A medida que se descubren fallas de seguridad en el software, este se debe actualizar para sellar cualquier posible riesgo de seguridad. Si el paquete es parte de una distribución de Red Hat Enterprise Linux actualmente soportada, Red Hat, Inc. está obligado a producir los paquetes de actualización que reparen las vulnerabilidades, tan pronto como sea posible.

Los productos de Red Hat están disponibles a través de suscripciones, las cuales definen los servicios que proporcionarán (tales como envío de contenido, actualizaciones, base de conocimientos y niveles de soporte) para esos productos. Las suscripciones son otorgadas a servidores individuales y esto les da derecho a recibir soporte.

Dos términos relacionados: suscripción y derechos. Ambos términos se refieren al producto de software (y todos sus servicios asociados) que están disponibles para el sistema. La diferencia está en la perspectiva. Una suscripción es lo que se compra de Red Hat. Esta suscripción define el producto, las arquitecturas soportadas, los mecanismos de envío de contenido, los niveles de soporte, y las cantidades. Cuando se asigna una suscripción a un sistema, se está autorizado a usar ese sistema o se tiene un derecho. Un derecho, es una suscripción asignada.

Portal de Clientes, Red Hat Network y RHN Classic

Alguna vez ha leído acerca de una nueva versión de un paquete, deseo instalarlo y no pudo encontrarlo?

Alguna vez encontró un paquete RPM por medio de un motor de búsqueda de Internet que lo derivó a un sitio desconocido?

Alguna vez intentó encontrar un RPM, sin embargo únicamente encontró archivos que debe compilarlo usted mismo?

Alguna vez ha pasado horas o días visitando diferentes sitios para saber si los últimos paquetes están instalados en su sistema, sabiendo que pronto tendrá que volver a hacerlo?

El Portal de Clientes y Red Hat Network proporcionan la solución a todas las necesidades de administración de software. Estos servicios determinan cuáles paquetes RPM son necesarios para el sistema, los descarga desde repositorios seguros, verifica la firma del RPM para asegurarse de que no han sido dañados y los actualiza. La instalación del paquete puede ocurrir de inmediato o puede ser planificada durante un cierto período de tiempo.

Red Hat Enterprise Linux 5.7 introdujo una nueva administración de suscripciones.



El administrador de suscripciones Subscription Manager, le permite registrar sistemas y gestionar suscripciones usando certificados digitales. Subscription Manager está totalmente integrado con el Portal de Clientes.

El Portal de Clientes habilita a los clientes con suscripciones desde una única ubicación acceder a servicios como:

● Descargas actualizaciones y productos de evaluación

● Herramientas de gestión de cuentas y suscripciones

● Sistema de reportes de errores y apertura de tickets

● Soluciones, preguntas frecuentes y documentación oficial del producto

● Contenido educacional valioso, incluyendo whitepapers, presentaciones multimedia, etc.

RHN Classic, servicio predecesor del Portal de Clientes, también proporciona actualizaciones, sin embargo, el Portal de Clientes proporciona mayor facilidad de uso y funcionalidades integradas.

Para acceder al portal de clientes utilizando el navegador web conéctese al siguiente sitio web:

https://access.redhat.com/



Para acceder a RHN Classic utilizando el navegador web, conéctese al siguiente sitio web:

https://rhn.redhat.com

Durante el proceso firstboot, existen dos opciones para el servidor de contenido: Red Hat Network y RHN Classic. Estos sistemas son mutuamente excluyentes, sin embargo ambos manejan el contenido de software y actualizaciones, así como las suscripciones y el inventario del sistema.

Red Hat Network utiliza un modelo de suscripción baseado en productos, mientras que RHN Classic utiliza un modelo basado en canales.

Para utilizar Red Hat Network o RHN Classic, debe contar con una subscripción. Las subscripciones pueden ser adquiridas por periodos de 1 a 3 años. Existen distintos niveles de subscripción, variando en cada uno el nivel de soporte y el precio:

● Self-support Subscription: Acceso al Portal de Clientes y actualizaciones. No es posible realizar apertura de casos de soporte.

● Standard Subscription: Soporte soporte web y telefónico en horarios de oficina, incidentes ilimitados. Tiempo de respuesta de indidentes:

○ Severidad 1: 1 hora (en horarios de oficina)



○ Severidad 2: 4 horas (en horarios de oficina)

○ Severidad 3: 1 día (en horarios de oficina)

○ Severidad 4: 2 días (en horarios de oficina)

● Premium Subscription: Soporte soporte web y telefónico 7x24, incidentes ilimitados. Tiempo de respuesta de indidentes:

○ Severidad 1: 1 hora

○ Severidad 2: 2 horas



Las suscripciones son vendidas por par de sockets. Esto quiere decir que necesitará adquirir una suscripción por cada 2 procesadores físicos instalados en el equipo.

Además, si usted desea utilizar máquinas virtuales, existen suscripciones según la cantidad de guests que serán creados en el equipo:

● Suscripción para 1 guest

● Suscipción para 4 guests

● Suscripción para guests ilimitados

Por tanto, en base a la necesidad de su negocio, usted podría seleccionar adquirir una suscripción Red Hat Enterprise Linux Standard para guests ilimitados. Deberá adquirir una suscripción de este tipo por cada 2 procesadores físicos (sockets) que tendrá el servidor.

Utilización del Red Hat Network

Para utilizar Red Hat Network, primero debe activar una suscripción. Para iniciar el asistente de suscripciones ejecute en la línea de comandos:

# suscription-manager-gui

La ventana principal de Red Hat Subscription Manager aparece.



Red Hat Subscription Manager tiene tres áreas principales para administrar productos y subscripciones:

● Mis suscripciones: Muestra todos los sistemas actualmente registrados.

● Todas las suscripciones: Muestra las suscripciones disponibles para el sistema.

● Mi software instalado: Muestra los productos instalados actualmente en el sistema, junto con el estado de la suscripcion.

Si el sistema aún no fue registrado, aparecerá el botón Registrar el sistema.

Al presionar el botón Registrar el sistema, ingrese el usario y la contraseña para el servicio de suscripción. El usuario y contraseña es el utilizado para acceder al Portal de Clientes.



En caso de requerir de la configuración de un servidor proxy para acceder a internet, presione el botón Configuración de Proxy e ingrese el nombre de host y puerto del servidor proxy:

Para suscribir el sistema directamente desde la línea de comandos, ejecute:

# subscription-manager register --username admin-example --password secret

Puede además indicar las opciones --proxy=, --proxyuser= y --proxypass= para utilizar un servidor proxy desde la línea de comandos.

Una vez registrado el sistema, puede utilizar el comando yum para instalar y actualizar los paquetes de software.



Utilización de RHN Classic

Red Hat Enterprise Linux proporciona una aplicación llamada rhn_register. Esta aplicación es utilizada para registrar el sistema en RHN Classic.

Para registrar el sistema en RHN Classic, ejecute el siguiente comando:

# rhn_register

Puede además indicar las opciones --proxy=, --proxyUser= y --proxyPassword= para utilizar un servidor proxy desde la línea de comandos.

La pantalla inicial de rhn_register aparece, haga clic en Adelante.

Seleccione la fuente de actualización. Si obtendrá las actualizaciones directamente de RHN Classic, seleccione Me gustaría recibir actualizaciones desde la Red de Red Hat.



Introduzca el nombre de usuario y contraseña para acceso a RHN Classic:

Finalmente en la página Crear perfil del sistema, puede activar el envío de información de software y hardware a RHN. Esto es recomendado para que RHN pueda suscribir el sistema automáticamente en base a los canales apropiados para el sitema.



Para suscribir el sistema directamente desde la línea de comandos, ejecute:

# rhn_register –nox

Puede además indicar las opciones --proxy=, --proxyUser= y --proxyPassword= para utilizar un servidor proxy desde la línea de comandos.

Una vez registrado el sistema, puede utilizar el comando yum para instalar y actualizar los paquetes de software.

Yellow Dog Updater, Modified (YUM)

Yum es un programa automático para instalar y desinstalar los paquetes del sistema. Una característica muy interesante es que obtiene automáticamente dependencias. Además actualiza el sistema aplicando los más recientes parches de seguridad y correctivos al sistema operativo de una manera simple y solo requiere de un buen ancho de banda (conexión a internet) o bien muchísima paciencia. Con Yum no hay muchas más excusas para no aplicar los parches de seguridad y correctivos al sistema.

Antes de utilizar yum, deberá importar la clave pública para verificar la firma de los paquetes:

# rpm --import /media/cdrom/RPM-GPG-KEY*

Si utiliza un servidor proxy para el acceso a Internet, deberá configurar la información del servidor en el archivo /etc/yum.conf:

proxy=http://host:puerto

La utilización del comando yum es sencilla, para instalar un paquete ejecute:

# yum install <paquete>

Para eliminar un paquete ejcute:

# yum remove <paquete>

Para ver qué actualizaciones hay disponibles, ejecute:

# yum check-update

Para obtener información acerca de un paquete ejecute:

# yum info <paquete>

Para actualizar algún software, ejecute:

# yum update <paquete>



Para actualizar todo el sistema, ejecute:

# yum update

Si desea excluir algún paquete en la actualización del sistema, por ejemplo el kernel, ejecute:

# yum update -x kernel*

Puede listar paquetes de software cuyo nombre concuerda con un patrón de texto, por ejemplo:

# yum list kernel*

Si desea buscar un paquete en base a su nombre, descripción o resumen, puede utilizar la opción search, por ejemplo:

# yum search kernel

Yum deja como resultado de su uso cabeceras y paquetes RPM almacenados en el interior del directorio localizado en la ruta /var/cache/yum/. Particularmente los paquetes RPM que se han instalado pueden ocupar mucho espacio y es por tal motivo conviene eliminarlos una vez que ya no tienen utilidad. Igualmente conviene hacer lo mismo con las cabeceras viejas de paquetes que ya no se encuentran en la base de datos. A fin de realizar la limpieza correspondiente, puede ejecutarse lo siguiente:

# yum clean all

Si desea descargar un paquete sin instalarlo, debe tener instalado el paquete yum-downloadonly. Para instalar el paquete ejecute:

# yum install yum-downloadonly

Asegúrese que este plugin esté habilitado verificando el archivo /etc/yum/pluginconf.d/downloadonly.conf [main]

enabled=1

Para descargar un paquete sin instalarlo, ejecute:

# yum install --downloadonly <paquete>

Los paquetes por defecto son almacenados en el directorio /var/cache/yum/packages. Puede indicar una ubicación alternativa con la opción –downloaddir, por ejemplo:

# yum install --downloadonly --downloaddir=/tmp <paquete>



Es además posible indicar a yum que instale únicamente los paquetes de seguridad (no instalar los paquetes de mejoras o correcciones de errores). Para ello, necesita el plugin yum-security:

# yum install yum-security

Luego de instalar el paquete yum-security, ejecute el siguiente comando para descargar e instalar las actualizaciones de seguridad de RHN:

# yum update --security

Para visualizar las actualizaciones de seguridad sin instalarlos ejecute:

# yum list-security

Si desea una información detallada de cada paquete ejecute:

# yum info-sec

Con yum puede además bloquear la actualización de paquetes específicos en el sistema, evitando así que se modifiquen las versiones de los mismos. Esto podría ser necesario en caso de tener alguna aplicación que tiene una dependencia de una versión específica de un paquete. Para lograr esto, necesita el plugin yum-versionlock:

# yum install yum-plugin-versionlock

Luego de instalar el paquete yum-plugin-versionlock, ejecute el siguiente comando para obtener información detallada de los paquetes instalados:

# rpm -qa --queryformat "%{NAME}-%{VERSION}-%{RELEASE}\n"

Luego edite el archivo /etc/yum/pluginconf.d/versionlock.list y agregue los paquetes que no desea que se actualicen, por ejemplo, para evitar la actualización del kernel agregue las siguientes líneas y asegúrese que la versión coincide con el resultado del comando anterior:

kernel-2.6.18-164.9.1.el5kernel-headers-2.6.18-164.9.1.el5

Consideraciones especiales cuando actualiza el sistema

Cuando se actualiza un sistema deberá tomar algunas precauciones clave:

● Asegúrese de tener un buen respaldo del sistema: Puede realizar una copia de seguridad del sistema utilizando la herramienta Mondo.

● Verifique los archivos de configuración en conflicto: Durante la actualización del sistema, es posible que archivos de configuración



personalizados sean reemplazados por versiones nuevas, esto ocurre cuando existe cambios mayores en los paquetes que hacen que los archivos de configuración no sean compatibles.

Los archivos de configuración personalizados serán renombrados y se agregará .rpmsave al nombre del archivo, y será instalado una nueva versión del archivo de configuración con valores por defecto.

Debe asegurarse de encontrar y revisar todos los archivos .rpmsave que puedieran haber sido generados y adaptar la nueva configuración según sea necesario.

Para encontrar los archivos puede utilizar el comando find. También es recomendado que redireccione la salida del comando yum a un archivo de log para luego utilizar el comando grep para obtener la lista de archivos .rpmsave que pudieran haberse generado durante la actualización.

# yum update > /var/log/yum_update.log 2>&1# egrep "rpmnew|rpmsave" /var/log/yum_update.log

Verifique y elimine los archivos .rpmnew y .rpmsave antes y después de la actualización.

● Configuraciones de SELinux: Durante la actualización del sistema, es posible que existan cambios en los booleans de SELinux. Asegúrese de guardar una lista de los booleans y sus valores antes de realizar la actualización del sistema y compárelos posteriormente.

● Actualización del Kernel: Existen algunos módulos de kernel y drivers que son requeridos e instalados por programas de otros fabricantes, como HP o IBM. Luego de una actualización del kernel, si el nuevo kernel no incluye el driver o módulo, deberá reinstalar el programa o sus drivers y módulos para esa versión específica del Kernel.

● Zona horaria: Mantenga siempre actualizado el paquete tzdata, el cual contiene la información de cuando inicia y finaliza el horario de verano.

● Aplique primero las actualizaciones en un equipo de pruebas: Se recomienda que tenga un entorno de pruebas o pre-producción, con la misma configuración de software que el equipo de producción, y aplique las actualizaciones primero en este equipo y realice pruebas funcionales de los servicios. Si los servicios se encuentran operando correctamente, aplique la actualización al equipo de producción.

Utilización del sitio web de seguridad de Red Hat

El Portal de Clientes de Red Hat proporciona acceso a una sección específica de



seguridad.

En esta sección puede obtener información acerca de las vulnerabilidades que afectan a los productos de Red Hat.

Además, puede hacer clic en el enlace Notificaciones & Avisos, para configurar una cuenta de correo donde serán enviadas las alertas de seguridad.

Seguridad de los paquetes RPM

Paquetes firmados digitalmente

Todos los paquetes de Red Hat/CentOS Linux están firmados con la llave GPG. GPG viene de GNU Privacy Guard, o GnuPG, un paquete de software libre utilizado para asegurarse de la autenticidad de los paquetes distribuidos. Por ejemplo, una llave privada (llave secreta) bloquea el paquete mientras que la llave pública desbloquea y verifica el paquete. Si la llave pública distribuida no coincide con la llave privada durante la verificación de RPM, puede que el paquete haya sido alterado y por lo tanto no se puede confiar en el.

Verificar paquetes firmados

La utilidad de RPM trata automáticamente de verificar la firma GPG de un paquete



RPM antes de instalarlo. Si no tiene la llave GPG instalada, instálela desde una ubicación segura y estática tal como un CD-ROM de instalación de la distribución Linux.

Asumiendo que el CD-ROM se encuentra montado en /media/cdrom, utilice el siguiente comando para importarla a su llavero (una base de datos de llaves confiables en el sistema):

# rpm --import /media/cdrom/RPM-GPG-KEY*

Para desplegar una lista de todas las llaves instaladas para ser verificadas por RPM, ejecute el comando:

# rpm -qa gpg-pubkey*

La salida incluirá lo siguiente:

gpg-pubkey-db42a60e-37ea5438

Para desplegar detalles sobre una llave específica, utilice el comando rpm -qi seguido de la salida del comando anterior, como se muestra en este ejemplo:

# rpm -qi gpg-pubkey-db42a60e-37ea5438

Es extremadamente importante que verifique la firma de sus archivos RPM antes de instalarlos para asegurarse de que no fueron alterados. Para verificar todos los paquetes descargados de una vez, escriba el comando siguiente:

# rpm -K /tmp/updates/*.rpm

Para cada paquete, si se verifica exitosamente la llave GPG, el comando devuelve gpg OK. Si no es así, asegúrese de estar utilizando la llave pública correcta, así como también verificar la fuente del contenido. No se deberían instalar paquetes que no pasan las verificaciones de GPG pues pueden haber sido alterados por terceros.

Después de verificar la llave GPG y descargar todos los paquetes asociados con el informe de errores, instálelos como usuario root.

Instalación de paquetes firmados

La instalación para la mayoría de los paquetes se puede hacer sin percances (excepto para los paquetes kernel), con el comando siguiente:

# rpm -Uvh /tmp/updates/*.rpm

Para los paquetes del kernel, nunca utilice la opción -U porque eliminará cualquier versión anterior del kernel existente. Utilice el comando con la opción -i como sigue:

# rpm -ivh /tmp/updates/kernel-*rpm



Verificación de paquetes rpm

La verificación de un paquete tiene que ver con comparar la información sobre archivos instalados de un paquete con la misma información del paquete original. Entre otras cosas, la verificación compara el tamaño, la suma MD5, los permisos, el tipo, el dueño y el grupo de cada archivo.

El comando rpm -V verifica un paquete. Usted puede utilizar cualquiera de las Opciones de selección de paquete de la lista para pedir que se especifiquen los paquetes que desea verificar. Un modo sencillo de verificar es rpm -V foo, que verifica si todos los archivos en el paquete foo se encuentran en el mismo estado en que estaban cuando originalmente fueron instalados. Por ejemplo:

Para verificar un paquete que contiene un determinado archivo:

# rpm -Vf /bin/vi

Para verificar todos los paquetes instalados:

# rpm -Va

Para verificar un paquete instalado contra un archivo de paquete RPM

# rpm -Vp foo-1.0-1.i386.rpm

Este comando puede ser útil si sospecha que sus bases de datos de RPM están dañadas.

Si todo fue verificado correctamente, no habrá salida. Si se encuentran discrepancias, serán mostradas. El formato de la salida es una cadena de ocho caracteres (una c identifica un archivo de configuración) seguido por el nombre del archivo. Cada uno de los ocho caracteres señala el resultado de una comparación entre un atributo del archivo al valor de ese atributo escrito en la base de datos de RPM. Un sólo . (punto) significa que ha pasado la prueba. Los siguientes caracteres señalan que ciertas pruebas no han sido pasadas:

Prueba Descripción5 MD5 suma de verificaciónS Tamaño del archivoL Enlace simbólicoT Hora de modificación de archivoD Dispositivo U Usuario propietario



Prueba DescripciónG Grupo propietarioM Modo? Archivo que no se puede leer

Si ve alguna salida, use su buen juicio para determinar si debería quitar o reinstalar el paquete o resolver el problema de otra manera.


3Seguridad de inicio, contraseñas y la cuenta root

Seguridad de inicio, contraseñas y la cuenta root

Seguridad del BIOS y del gestor de arranque

La protección con contraseñas para el BIOS (o equivalentes al BIOS) y el gestor de arranque, pueden ayudar a prevenir que usuarios no autorizados que tengan acceso físico a sus sistemas, arranquen desde medios removibles u obtengan acceso como root a través del modo monousuario. Pero las medidas de seguridad que uno debería tomar para protegerse contra tales ataques dependen tanto de la confidencialidad de la información que las estaciones tengan como de la ubicación de la máquina.

Contraseñas del BIOS

Las siguientes son las dos razones básicas por las que proteger la BIOS de una computadora con una contraseña:

● Prevenir cambios a las configuraciones del BIOS — Si un intruso tiene acceso a la BIOS, puede configurarlo para que arranque desde un disquete, USB, o CD-ROM. Esto les permite entrar en modo de rescate o monousuario, lo que a su vez les permite plantar programas dañinos en el sistema o copiar datos confidenciales.

● Prevenir el arranque del sistema — Algunas BIOSes le permiten proteger el proceso de arranque con una contraseña. Cuando está funcionalidad está activada, un atacante esta forzado a introducir una contraseña antes de que el BIOS lance el gestor de arranque.

Debido a que los métodos para colocar contraseñas del BIOS varían entre fabricantes de equipos, consulte el manual de su computador para ver las instrucciones específicas.

Si olvida su contraseña del BIOS, usualmente esta se puede reconfigurar bien sea a través de los jumpers en la tarjeta madre o desconectando la batería CMOS. Por esta razón, es una buena idea bloquear el chasis del computador si es posible. Sin embargo, consulte el manual del computador o tarjeta madre antes de proceder a desconectar la batería CMOS.

Contraseñas del gestor de arranque

A continuación se muestran las razones principales por las cuales proteger el gestor de arranque Linux:

● Previene el acceso en modo monousuario — Si un atacante puede arrancar en modo monousuario, se convierte en el superusuario de forma automática sin que se le solicite la contraseña de acceso.

● Previene el acceso a la consola de GRUB — Si la máquina utiliza GRUB



como el gestor de arranque, un atacante puede usar la interfaz del editor para cambiar su configuración o para reunir información usando el comando cat.

Protegiendo GRUB con contraseñas

Puede configurar GRUB para solucionar los problemas listados anteriormente añadiendo una directiva de contraseña a su archivo de configuración. Para hacer esto, primero seleccione una contraseña, luego abra un indicador de comandos del shell, conéctese como root y escriba:

# /sbin/grub-md5-crypt

Cuando se le pida, escriba la contraseña GRUB y presione [Enter]. Esto retornará un hash MD5 para la contraseña.

Luego, modifique el archivo de configuración 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 línea:

password --md5 <password-hash>

Reemplace <password-hash> con el valor retornado por /sbin/grub-md5-crypt.

La próxima vez que el sistema arranque, el menú de GRUB no le permitirá acceder el editor o la interfaz de comandos sin primero presionar la tecla p seguido por la contraseña de GRUB.

Seguridad de contraseñas

Las contraseñas son el método principal que Red Hat Enterprise Linux utiliza para verificar la identidad de los usuarios. Por esta razón la seguridad de las contraseñas es de suma importancia para la protección del usuario, la estación de trabajo y la red.

Para propósitos de seguridad, el programa de instalación configura el sistema para usar el algoritmo Secure Hash 512 (SHA512) y contraseñas shadow. Se recomienda que no cambie estas configuraciones.

Si no se utilizara contraseñas shadow, todas las contraseñas serían almacenadas como hash de una sola vía en el archivo /etc/passwd, lo que hace al sistema vulnerable a ataques de piratas fuera de línea. Si un intruso puede obtener acceso a la máquina como un usuario regular, puede también copiar el archivo /etc/passwd a su propia máquina y ejecutar cualquier cantidad de programas de descifrado de contraseñas contra el. Si hay una contraseña insegura en el archivo, es sólo una cosa de tiempo antes de que el maleante informático la descubra.



Las contraseñas shadow eliminan este tipo de ataques almacenando los hash de las contraseñas en el archivo /etc/shadow, el cual sólo es leído por el usuario root.

Esto obliga al atacante potencial a intentar descubrir la contraseña remotamente mediante la conexión a un servicio de la red en la máquina, tal como SSH o FTP. Este tipo de ataques de fuerza bruta son mucho más lentos y dejan rastros obvios, pues los intentos fallidos de conexión son registrados a los archivos del sistema. Por supuesto, si el maleante o cracker comienza un ataque durante la noche y usted tiene contraseñas débiles, éste podría obtener acceso antes del amanecer y editar el archivo de registro para borrar sus rastros.

Más allá de los detalles sobre el formato y almacenamiento, está el problema del contenido. La cosa más importante que un usuario puede hacer para proteger su cuenta contra un ataque de piratas, es crear una contraseña robusta.

Creación de contraseñas robustas

Cuando se cree una contraseña segura, es una buena idea seguir las siguientes pautas:

● Cree contraseñas de al menos ocho caracteres – Mientras más larga sea la contraseña, mejor.

● Mezcle letras mayúsculas y minúsculas – Linux es sensitivo a las mayúsculas y minúsculas, por la tanto mezcle las letras para reenforzar su contraseña.

● Mezcle letras y números – Agregando números a las contraseñas, especialmente cuando se añaden en el medio (no solamente al comienzo o al final), puede mejorar la fortaleza de su contraseña.

● Incluya caracteres no alfanuméricos – Los caracteres especiales tales como &, $, y > pueden mejorar considerablemente su contraseña (esto no es posible si esta usando contraseñas DES).

● No utilice palabras reconocibles – Como nombres propios, palabras que existen en el diccionario o términos comunes.

● No utilice palabras reconocibles de otros lenguajes – Programas que realizan ataques de contraseñas pueden utilizar diccionarios en cualquier lenguaje.

● No utilice información personal – Evite utilizar información personal como nombres de familiares, de mascotas, fechas de cumpleaños o números de teléfono y documentos.

● Nunca escriba su contraseña – Memoricela.

Seleccione una contraseña que pueda recordar – La mejor contraseña en el mundo



será de poca utilidad si usted no puede recordarla. Por lo tanto utilice acrónimos u otros dispositivos nemónicos que lo ayuden a memorizar las contraseñas.

Metodología para la creación de contraseñas seguras

Hay muchos métodos que la gente utiliza para crear contraseñas seguras. Uno de los métodos más populares incluyen acrónimos. Por ejemplo:

Piense en una frase memorable, tal como:

"Es más fácil creer que pensar con espíritu crítico."

Luego, cámbielo a un acrónimo (incluyendo la puntuación).

emfcqpcec.

Añada un poco de complejidad sustituyendo números y símbolos por letras en el acrónimo. Por ejemplo, sustituya 7 por e y el símbolo arroba (@) por c:

7mf@qp@7@.

Añada un poco más de complejidad colocando mayúscula al menos una letra, tal como M.

7Mf@qp@7@.

Mientras que la creación de contraseñas seguras es imperativo, manejarlas adecuadamente es también importante, especialmente para los administradores de sistemas dentro de grandes organizaciones. La próxima sección detalla buenos hábitos en la creación y manejo de contraseñas de usuarios dentro de una organización.

Envejecimiento de las contraseñas

El envejecimiento de contraseñas es una técnica utilizada por los administradores de sistemas para defenderse de las malas contraseñas dentro de la organización. El envejecimiento de contraseñas significa que luego de un tiempo determinado (usualmente 90 días) se le pide al usuario que cree una nueva contraseña. La teoría detrás de esto es que si un usuario es forzado a cambiar su contraseña periódicamente, una contraseña que ha sido descifrada por un cracker sólo le es útil por un tiempo determinado. La desventaja del envejecimiento de contraseñas, es que los usuarios tienden a escribir sus contraseñas.

Existen dos programas principales usados para especificar la caducidad de contraseñas bajo Red Hat/CentOS Linux: el comando chage o la aplicación gráfica Administrador de usuarios system-config-users.



La opción -M del comando chage especifica el número de días máximo en que la contraseña será válida. Por lo tanto, si desea que la contraseña de un usuario expire en 90 días, escriba el comando siguiente:

# chage -M 90 <username>En el comando anterior, reemplace <username> con el nombre del usuario. Para desactivar la expiración de contraseñas, es común utilizar un valor de 99999 después de la opción -M (esto equivale a un poco más de 273 años).

Forzar el cambio de contraseñas

El comando chage puede ser utilizado para forzar el cambio de la contraseña al siguiente inicio de sesión. Esto es muy utilizado cuando la contraseña debió ser restablecida por el administrador, de tal modo a que el usuario esté obligado a cambiarla al iniciar sesión con la nueva contraseña.

Para forzar el cambio de contraseña al siguiente inicio de sesión ejecute:

# chage -d 0 <usuario>

Desactivación del acceso root

Si un administrador no está cómodo con permitir a los usuarios tener acceso como root, entonces la contraseña de root debería mantenerse en secreto y deshabilitar el acceso a nivel uno o en modo monousuario a través de la protección con contraseñas del gestor de arranque

Deshabilitar el shell de root

Para prevenir a los usuarios de conectarse directamente como root, el administrador del sistema puede configurar el shell de la cuenta root a /sbin/nologin en el archivo /etc/passwd. Esto impedirá el acceso a la cuenta root a través de comandos que requieren un shell.

Deshabilitar las conexiones root

Para limitar aún más el acceso a la cuenta root, los administradores pueden desactivar las conexiones root en la consola, editando el archivo /etc/securetty. Este archivo lista todos los dispositivos a los cuales el usuario root puede conectarse. Si el archivo no existe, el usuario puede conectarse a través de cualquier dispositivo de comunicación en el sistema, bien sea a través de la consola o una interfaz de red sin configurar. Por defecto, el archivo de Red Hat/CentOS Linux, /etc/securetty, sólo permite que el usuario root se conecte en la consola conectada físicamente a la máquina. Para prevenir que el usuario root se conecte,



elimine los contenidos de este archivo escribiendo el comando siguiente:

# echo > /etc/securetty

Deshabilitar conexiones root SSH

Para prevenir las conexiones de root a través del protocolo SSH, modifique el archivo de configuración del demonio SSH /etc/ssh/sshd_config. Cambie la línea que dice:

# PermitRootLogin yes

Para que diga lo siguiente:

PermitRootLogin no

Limitar el acceso root

En vez de negar completamente el acceso al superusuario, el administrador puede desear permitir el acceso solamente a través de programas setuid, tales como su o sudo.

El comando su

Después de escribir el comando su, se le solicita al usuario la contraseña de root y, luego de la autenticación, se le presenta un indicador de comandos del shell.

Una vez conectado a través de su, el usuario se convierte en el superusuario y tiene acceso administrativo absoluto al sistema. Además, una vez que el usuario obtiene acceso root, es posible, en algunos casos, usar el comando su para cambiarse a cualquier otro usuario en el sistema sin que se le solicite una contraseña.

Debido a que este programa es tan poderoso, los administradores dentro de la organización pueden desear limitar el acceso a este comando.

Una de las formas más fáciles de hacer esto es añadir usuarios al grupo administrativo especial llamado wheel. Para hacer esto escriba el siguiente comando como root:

# usermod -G wheel <usuario>

En el comando anterior, cambie <usuario> con el nombre del usuario que desea añadir al grupo wheel.

Luego, deberá modificar el archivo /etc/pam.d/su para activar la verificación del grupo al ejecutar el comando su:



# Uncomment the following line to require a user to be in the "wheel" group.auth required /lib/security/$ISA/pam_wheel.so use_uid

Descomente la línea que corresponde con el módulo pam_weel.so. Para mas información acerca de PAM, consulte el capítulo Pluggable Authentication Module.

Super User DO (Sudo)

El principal fin de sudo es reemplazar a su. En algunas circunstancias puede utilizarse como reemplazo del SUID. La ventaja principal es que no es necesario dar a conocer la contraseña de root o de algún otro usuario privilegiado, pudiendo ejecutar comandos como tales usuarios.

El fichero /etc/sudoers

Desde este fichero lo controlamos todo. A continuación una lista de las posibilidades que nos ofrece:

● Podemos crear alias de comandos, usuarios, usuarios privilegiados y hosts.

● Podemos establecer opciones de comportamiento globales, por usuario, por usuario privilegiado y por host.

La sintaxis del /etc/sudoers está pensada para entornos distribuidos; de forma que podemos gestionar toda una red con un único fichero. Y, cómo no, flexibilidad absoluta a la hora de crear reglas de acceso.

Cuando nos referimos a usuarios y a usuarios privilegiados también es posible referirnos a UIDs, grupos o GIDs, netgroups o alias de usuario. Para ello basta anteponer el símbolo # para los UIDs (#1003), el símbolo % para los grupos (%seguridad).

Para editar /etc/sudoers debemos utilizar el comando visudo puesto que aparte de lanzar nuestro editor favorito realiza otras tareas adicionales como bloquear el fichero para evitar edición concurrente y comprobar la sintaxis antes de guardar los cambios.

Estructura del archivo sudoers

El /etc/sudoers se divide en tres grandes secciones:

## Definiciones de alias### Ajuste de opciones por defecto#



## Reglas de acceso#

Todas son opcionales. Obviamente, la más necesaria es la última ya que sin ésta el uso de sudo no tiene sentido. Como se puede observar, los comentarios se insertan igual que en los scripts del shell.

Definiciones de alias

Los alias son abreviaciones para cualquier tipo de elemento: comandos, usuarios, usuarios privilegiados y hosts. Éstos alias pueden ser utilizados en cualquier lugar donde se espere un comando, un usuario privilegiado o un host respectivamente. Insisto, cualquier lugar; incluida la definición de un alias.

Veamos la sintaxis general:

Tipo_Alias NOMBRE_ALIAS = elemento1, elemento2, elemento3Donde Tipo_Alias puede ser uno de los siguientes:

● Cmnd_Alias para comandos

● User_Alias para usuarios

● Runas_Alias para ejecutar en nombre de estos usuarios

● Host_Alias para hosts

El siguiente parámetro, NOMBRE_ALIAS es el nombre del alias. Debe empezar por letra mayúscula y sólo se permiten letras mayúsculas y números.

El resto son los elementos o listas de elementos por los cuales NOMBRE_ALIAS será expandido.

Existe un alias especial, ALL, que se utiliza para englobar a todos los comandos, usuarios, usuarios privilegiados o hosts.

Ajuste de opciones

Como ya hemos dicho podemos definir opciones globalmente, por usuario, por usuario privilegiado y por host. La sintaxis es la siguiente:

Defaults lista_opciones

Defaults:usuario lista_opciones

Defaults>usuario_privilegiado lista_opciones



Defaults@host lista_opciones

La lista_opciones es una lista de opciones separadas por comas. Existen cuatro tipos de opciones:

● Booleanos: Que se activan con sólo escribir el nombre de la opción y se desactivan con el símbolo ! delante.

● Enteros: De la forma nombre_opcion = valor

● Strings: Igual que los enteros nombre_opcion = "valor"

● Listas: Que pueden ser de la forma nombre_opcion = "valor1 valor2". Éstas opciones también pueden utilizar += y -= en lugar de = para añadir elementos y quitar elementos respectivamente.

Por ejemplo, por defecto sudo solicita la contraseña del usuario para identificarse usando su propia contraseña. Una vez que la contraseña ha sido introducida sudo la recuerda por 5 minutos. Utilizando la siguiente entrada Default se puede modificar este comportamiento:

Defaults timestamp_timeout=0

Estableciendo un valor a 0, se indica que la contraseña no sea recordada. Si se establece a -1 la contraseña es recordada permanentemente.

Podría establecer también la cantidad de veces que puede intentarse introducir la contraseña con la opción passwd_tries, por ejemplo:

Defaults timestamp_timeout=0,passwd_tries=1

Podemos indicar que utilice un archivo de registro independiente en lugar de syslog para las notificaciones:

Defaults log_year, logfile=/var/log/sudo.log

Se puede establecer también que ciertos grupos de usuarios no requieran autenticación para la ejecución de comandos a través de sudo, por ejemplo:

Defaults:SERVICES !authenticate

En este caso, SERVICES es una alias a usuarios de servicios los cuales no requieren autenticarse para ejecutar comandos como usuarios privilegiados.

Para conocer la lista de opciones ejecute man sudoers.

Reglas de acceso

Ahora toca definir los usuarios a los que permitimos utilizar sudo, los comandos



que pueden ejecutar, bajo qué usuarios privilegiados ejecutarán los comandos y en qué hosts pueden hacerlo.

usuario host = (usuario_privilegiado) comando

Hay que decir que cada elemento puede ser tanto un alias como una lista de elementos. La mención del usuario_privilegiado o la lista de ellos es opcional y por defecto se toma el root. En los ejemplos comentaremos algunos detalles aclaratorios de la sintaxis.

Existe una última posibilidad, y es poder eliminar la petición de contraseña para ejecutar uno o varios comandos. Se trata de las etiquetas NOPASSWD y PASSWD. Son opcionales y por defecto se asume PASSWD. Recuerde que la contraseña que debe introducir es la del usuario que está utilizando actualmente.

usuario host = (usuario_privilegiado) NOPASSWD: comando

Ejemplos:

## User alias specificationUser_Alias SOPORTE_UA = jperez, pegomez, rlopez, %soporteUser_Alias ADMIN_UA = hvera, ivaldez, omedinaUser_Alias DBA_UA = mvazquez, gmendez, %dba## Runas alias specificationRunas_Alias ORACLE_RA = oracle, oracle10## Host alias specificationHost_Alias PROD_HA = mercurio, venus, tierra, marte :\ DESA_HA = sol, luna Host_Alias DMZ_HA = mail, www, ns## Cmnd alias specificationCmnd_Alias BACKUP_CA = /usr/bin/mt, /usr/sbin/star, /bin/tarCmnd_Alias KILL_CA = /usr/bin/kill, /usr/bin/killallCmnd_Alias INIT_CA = /usr/sbin/shutdown, /usr/sbin/halt, /usr/sbin/init, \

/usr/sbin/reboot## Override built in defaultsDefaults syslog=authDefaults>root !set_lognameDefaults:SOPORTE !lectureDefaults:ADMIN !authenticateDefaults@PROD log_year, logfile=/var/log/sudo.log# Permite a root y cualquier usuario en el grupo wheel ejecutar cualquier # comando en cualquier host como cualquier usuario #root ALL = (ALL) ALL



%wheel ALL = (ALL) ALL## Administradores de tiempo completo pueden ejecutar cualquier comando # en cualquier host sin autenticarse.#ADMIN_UA ALL = ALL## Los usuarios listados en el alias SOPORTE_UA puede ejecutar comandos # limitados a simples mantenimientos sin autenticarse.#SOPORTE_UA ALL = NOPASSWD: BACKUP_CA## Los usuarios listados en el alias SOPORTE_UA puede ejecutar comandos # de mantenimientos avanzados autenticándose en los equipos de la DMZ#SOPORTE_UA DMZ_HA = KILL_CA, INIT_CA## El usuario jbritos sólo puede hacer su a usuario reportes#jbritos ALL = /usr/bin/su - reportes## Los usuarios de SOPORTE_UA pueden cambiar la contraseña de cualquier usuario # excepto root en los equipos del alias PROD_HA#SOPORTE_UA PROD_HA = /usr/bin/passwd [A-z]*, !/usr/bin/passwd root## Los usuarios de DBA puede ejecutar cualquier comando como los usuarios # listados en el Runas_Alias ORACLE_RA ( oracle, oracle10) en los equipos del # alias PROD_HA y DESA_HA#DBA_UA PROD_HA = (ORACLE_RA) ALL : DESA_HA = (ORACLE_RA) ALL

Consideraciones de seguridad

En /etc/sudoers cuando se especifique un comando siempre se debe poner la ruta completa al ejecutable. Cuando ejecutamos sudo no es necesario, es decir, no necesito escribir sudo /usr/bin/su, basta con sudo su.

El uso del alias ALL para especificar comandos es altamente peligroso.

Funcionalidades que no se han comentado

Hay un varios detalles que no he mencionado. El primero es que en lugar de ejecutables se pueden indicar rutas a directorios para indicar que cualquier binario de dicho directorio se incluye en la regla de acceso; basta con finalizar la ruta en / y se entenderá como un directorio.

El segundo es que para los comandos podemos utilizar caracteres comodín.



Además, es posible controlar qué parámetros le podemos pasar a los comandos también mediante caracteres comodín.


4Pluggable Authentication Module

Pluggable Authentication Module

Introducción a PAM

Para entender como funciona PAM, iniciaremos con un ejemplo. Tomamos una aplicación que otorga algún servicio a los usuarios, login es uno de esos programas. El programa login hace dos cosas, primero establece si el usuario es quien realmente dice ser y luego le provee el servicio solicitado: en el caso de login el servicio es un shell ejecutándose con la identidad del usuario.

Tradicionalmente esto era logrado por la aplicación login solicitando al usuario una contraseña y verificando que concuerda con la que se encuentra en el sistema, comprobando que el usuario es quién dice ser. Esta tarea anteriormente estaba codificada en el programa login, actualmente la tarea de autenticar el usuario es delegada a PAM.

Para la perspectiva del programador de aplicaciones, PAM toma el control de las tareas de autenticación, verificando la identidad del usuario.

La flexibilidad de PAM es que usted como administrador del sistema, tiene la libertad de estipular qué esquema de autenticación será usado. Tiene la libertad de configurar el esquema a cualquiera o todas las aplicaciones que son conscientes de PAM. Esto es, puede autenticar desde archivos locales, servicios de directorio tales como LDAP, NIS, NIS+, Microsoft Active Directory e incluso bases de datos como MySQL.

PAM trabaja con cuatro tipos separados de tareas de gestión. Estas son:

● Gestión de la autenticación (auth)

● Gestión de las cuentas (account)

● Gestión de sesión (session)

● Gestión de contraseñas (password)

La asociación del esquema preferido de gestión con el comportamiento de una aplicación es hecho con entradas relevantes en los archivos de configuración de PAM. Las tareas de gestión son realizadas por módulos especificados en el archivo de configuración.

Archivos de configuración de PAM

PAM está diseñado para proveer al administrador del sistema una gran flexibilidad para trabajar con la configuración de las aplicaciones con respecto a la entrega de privilegios. La configuración local de estos aspectos de la seguridad del sistema está controlado por PAM en uno de dos lugares: o en un único archivo de configuración,



/etc/pam.conf, o en el directorio /etc/pam.d.

Por defecto, Red Hat/CentOS Linux utilizan el directorio de configuración /etc/pam.d, donde encontrará un archivo por cada servicio que soporta PAM. Este método es mas sencillo y eficiente.

Sintaxis del archivo de configuración

Una línea de configuración general tiene el siguiente formato:

tipo-modulo banderas-de-control ruta-modulo argumentos● Tipo-modulo - Uno de los cuatro tipos de módulos que pueden ser:

○ auth - Este módulo provee dos aspectos de autenticación para el usuario. Primero establece si el usuario es quien dice ser, instruyendo a la aplicación que solicite una contraseña para el usuario o algún método similar. Segundo, el módulo otorga la membresía de grupo (independientemente del archivo /etc/groups) u otros privilegios a través de sus propiedades de otorgación de credenciales.

○ account - este módulo realiza gestiones de la cuenta no relacionados con la autenticación. Es usado típicamente para permitir o restringir el acceso basado en la hora, recursos del sistema (máximo número de usuarios) o la ubicación del usuario (root sólo desde la consola).

○ session - primero, a este módulo es asociado las tareas que necesitan ser hechas para el usuario antes que se pueda otorgar el servicio. Estas cosas incluyen el registro de información relacionada al inicio o cierre de la sesión, montar o crear directorios, etc.

○ password - Este último módulo es requerido para actualizar la autenticación asociada con un usuario. Típicamente, existe un módulo para cada módulo de autenticación (auth) basada en “desafío/respuesta”.

● bandera-de-control - Es utilizada para indicar cómo la biblioteca PAM reaccionará a el éxito o fallo del módulo asociado. Debido a que los módulos pueden ser apilados (stacked), donde los módulos del mismo tipo se ejecutan en serie, uno luego de otro, la bandera de control determina la importancia relativa de cada módulo. La forma simple de sintaxis para la bandera de control es una sola palabra clave que indica la severidad respecto al éxito o fallo del módulo específico. Existen cuatro palabras claves:

○ required - Esto indica que el éxito del módulo es requerido para el tipo-modulo. La falla de este módulo no se presentará al usuario hasta que todos los módulos restantes del mismo tipo hayan sido ejecutados.



○ requisite - Como requerido, sin embargo, en el caso que el módulo retorne fallo, el control es directamente retornado a la aplicación y no se continúa la ejecución de los demás módulos.

○ sufficient - El éxito del módulo se considera suficiente para satisfacer a la biblioteca PAM que este tipo-modulo ha sido satisfactorio y ningún otro módulo de la pila es invocado.

○ optional - Como el nombre sugiere, esta bandera de control marca el módulo como no critico para el éxito o fallo de la aplicación. En general, PAM ignora este módulo cuando determina si una pila de módulos será exitosa o fallará. Sin embargo, en la ausencia de cualquier éxito o fallo de los módulos previos o sucesivos, este módulo determinará la naturaleza de la respuesta de la aplicación. Un caso es cuando los otros módulos retornan PAM_IGNORE.

● ruta-modulo - La ruta del objeto dinámicamente cargable, el módulo PAM en sí. Si el primer carácter del módulo es “/”, se asume una ruta completa, si no, la ruta se agrega a la ruta por defecto /lib/security.

● argumentos - Son una lista de campos que son pasados al módulo cuando es invocado. Muy parecidos a argumentos de los comandos unix. Generalmente, los argumentos válidos son opcionales y específicos a un módulo dado. Los argumentos inválidos son ignorados por el módulo, sin embargo cuando se encuentran un argumento inválido, el módulo escribe un error a syslog.

Cada archivo en el directorio /etc/pam.d representa un servicio.

Los archivos *-auth

Se debe tener en cuenta los archivos system-auth, password-auth, smartcard-auth y fingerprint-auth. Estos archivos engloban políticas comunes a muchos otros servicios que lo incluyen en su configuración. La ventaja de este esquema es que, en caso de querer cambiar el comportamiento común de varios servicios, tan solo es necesario modificar el archivo correspondiente con el método de autenticación utilizado.

Algunos servicios incluyen al archivo system-auth, mientras que otros servicios incluyen a los archivos relacionados al método de autenticación, como password-auth según la autenticación sea local o remota. Por tanto es recomendado realizar los cambios tanto en el archivo system-auth como en el archivo que corresponde con el método de autenticación utilizado.

Si no se utiliza autenticación con tarjetas inteligentes o lectores de huellas digitales,



puede incluir el archivo system-auth en el archivo password-auth y de esta forma solo tendrá que actualizar un archivo.

El archivos /etc/pam.d/*-auth son en realidad enlaces simbólicos los archivo /etc/pam.d/*-auth-ac, el cual es modificado y los valores modificados cada vez que ejecuta la herramienta system-config-authentication o authconfig.

Para definir una configuración personalizada que no se sobrescriba automáticamente, modifique el enlace simbólico para que apunte a un archivo personalizado, por ejemplo *-auth-local:

# ln -sf /etc/pam.d/system-auth-local /etc/pam.d/system-auth# ln -sf /etc/pam.d/password-auth-local /etc/pam.d/password-auth

Si no desea mantener los archivos por separado, edite el archivo password-auth e incluya al módulo system-auth:

# vi /etc/pam.d/password-authauth include system-authauth required pam_env.soauth sufficient pam_unix.so nullok try_first_passauth requisite pam_succeed_if.so uid >= 500 quietauth required pam_deny.so

account include system-authaccount required pam_unix.soaccount sufficient pam_localuser.soaccount sufficient pam_succeed_if.so uid < 500 quietaccount required pam_permit.so

password include system-authpassword requisite pam_cracklib.so try_first_pass retry=3 type=password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtokpassword required pam_deny.so

session include system-authsession optional pam_keyinit.so revokesession required pam_limits.sosession [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uidsession required pam_unix.so

De esta forma, solo deberá realizar los cambios en el archivo system-auth.

Política por defecto

Si el sistema será considerado seguro, es necesario tener una entrada other



razonablemente segura. La entrada other será utilizada si la aplicación es consciente de PAM y no existe una entrada para esta aplicación.

El siguiente es el valor por defecto:

# cat /etc/pam.d/otherauth required /lib/security/pam_deny.soaccount required /lib/security/pam_deny.sopassword required /lib/security/pam_deny.sosession required /lib/security/pam_deny.so

Módulos PAM

Los parámetros de cada módulo pam pueden variar de acuerdo a la versión de PAM. Es importante consultar la documentación que acompaña al paquete para obtener la información más actualizada. La documentación de PAM se encuentra en el directorio /usr/share/doc/pam-*/txts.

Módulo pam_access

Provee control de acceso basado en nombre de usuario, nombre de host, dirección IP o nombre de terminales.

Grupos de gestión

El módulo puede ser utilizado en los siguientes grupos de gestión:

● account

Dependencias

Requiere un archivo de configuración, por defecto /etc/security/access.conf. El formato del archivo es:

permiso:usuarios:origenes

Los valores para cada campo son:

Campo Descripciónpermiso Debe ser + (acceso otorgado) o – (acceso

denegado).



Campo Descripciónusuarios Una lista de usuarios, grupos, o ALL (todos). Un

patrón del formato usuario@host concuerda cuando usuario concuerda con la parte de usuario y host concuerda con la nombre de la máquina local.

origenes Lista de uno o mas nombres tty, nombres de host, nombres de dominio, direcciones IP, ALL, NONE, LOCAL.

Argumentos reconocidos

Argumento Descripciónaccessfile=</ruta/a/archivo> Indica un archivo de configuración

alternativo.filedsep=<separador> Modifica el separador de campo que

pam_access reconocerá cuando lee el archivo de configuración.

Ejemplos/uso sugerido

Es recomendado para máquinas como servidores LDAP, NIS, NIS+, y de correo, donde necesita muchas cuentas de usuarios pero no desea que inicien sesión interactiva.

Agregue la siguiente línea al archivos /etc/pam.d/system-auth:

account required pam_access.so

Un ejemplo del archivo access.conf se encuentra en el directorio /etc/security.

# Disallow console logins to all but a few accounts.##-:ALL EXCEPT wheel shutdown sync:LOCAL# Disallow non-local logins to privileged accounts (group wheel).##-:wheel:ALL EXCEPT LOCAL## Some accounts are not allowed to login from anywhere:##-:wsbscaro wsbsecr wsbspac wsbsym wscosor wstaiwde:ALL



Módulo pam_cracklib

Este módulo puede ser agregado a la pila de password para proveer una verificación de seguridad de contraseñas.

Se realizan las siguientes verificaciones:

● Palindromo: es la nueva contraseña un palindromo de la anterior.

● Cambio de capitalización: es la misma contraseña con cambio de capitalización (Mayusculas/Minusculas).

● Similar: Se parece la nueva contraseña a la anterior. Es controlado por el argumento difok el cual es el número de caracteres que deben diferir de la contraseña anterior. Por defecto ½ número de caracteres deben ser diferentes.

● Rotado: Es la contraseña una rotación de una contraseña anterior.

● Utilizado: Ya fue usada anteriormente. Las contraseñas anteriores de guardan en /etc/security/opasswd.

Grupos de gestión


● password

Dependencias

Requiere la biblioteca del sistema libcrack y el diccionario del sistema /usr/lib/cracklib_dict*.

Argumentos reconocidos

Argumento Descripcióntype=<XXX> Reemplaza la frase “New UNIX password:” con “New XXX

password”retry=<N> Numero de intentos para introducir la nueva contraseña.difok=<N> Número de caracteres diferentes de la contraseña anterior.minlen=<N> Tamaño mínimo de la contraseña. dcredit=<N> El máximo crédito por tener dígitos en la contraseña.ucredit=<N> El máximo crédito por tener mayúsculas en la contraseña.



Argumento Descripciónlcredit=<N> El máximo crédito por tener minúsculas en la contraseña.ocredit=<N> El máximo crédito por tener otros caracteres contraseña.remember=<N> La cantidad de contraseñas previas a recordar

El argumento minlen es la longitud mínima para una contraseña que está toda en minúsculas, pero los usuarios pueden obtener créditos de longitud usando una combinación de mayúsculas, minúsculas, números y caracteres especiales. Por defecto, normalmente puede obtener un máximo de 1 crédito para cada caracter. Si desea indicar que el carácter es requerido y no otorgar ningún crédito por él, indique el valor -1

De tal forma que si el administrador establece minlen=12, un usuario podría tener una contraseña de 8 caracteres si ha utilizado los 4 tipos de caracteres.


Para requerir contraseñas seguras, agregue/modifique la siguiente línea en el archivo /etc/pam.d/system-auth:

password required pam_cracklib.so retry=3 minlen=11 difok=3 lcredit=0 ucredit=1 dcredit=1 ocredit=1

En el ejemplo anterior la contraseña debe tener al menos 11 caracteres y debe tener 3 caracteres diferentes a la contraseña anterior. Para cada combinación de caracteres obtiene un crédito excepto por utilizar minúsculas. Si combina mayúsculas, minúsculas y caracteres especiales, la contraseña podría tener 8 caracteres.

Modulo pam_limits

Por medio del contenido del archivo de configuración /etc/security/limits.conf, límites de recursos son establecidos a las sesiones de los usuarios. UID 0 no es afectado por esta restricción.

Grupos de gestión


● session

Dependencias

Requiere un kernel que soporte límites de recursos y del archivo de configuración /etc/security/limits.conf.



Debe crear un archivo solo leíble por root que por defecto es /etc/security/limits.conf. Este archivo describe los límites de recursos a imponer a usuarios o grupos. Cada línea describe un límite para un usuario de la forma:

<domain> <type> <item> <value>El campo <domain> puede ser:

● Un usuario

● Un grupo

● El comodín *, como la entrada por defecto

● El comodín %, para límites de inicios de sesión solamente.

El campo <type> puede ser:

● hard - El usuario no puede pasar los requerimientos por encima de este valor.

● soft - Valores que el usuario puede sobrepasar hasta un rango permitido por una entrada hard. Serían los valores por defecto.

El campo <item> puede ser:

● core - limita el tamaño del archivo core (KB)

● data - tamaño máximo de dato (KB)

● fsize - tamaño máximo de archivo (KB)

● memlock - máximo espacio de memoria que podría estar bloqueado (KB)

● nofile - máximo número de archivos abiertos

● rss - tamaño máximo “resident set” (KB)

● stack - tamño máximo del “stack” (KB)

● cpu - Tiempo máximo de CPU (MIN)

● nproc - Número máximo de procesos

● as - Límite del espacio de direcciones o “address space”

● maxlogins - máximo número de inicios de sesión para el usuario



● maxsyslogins - máximo número de inicios de sesión en el sistema

● priority - la prioridad para ejecutar procesos

● locks - número máximo de archivos llaveados

Argumentos

Argumento Descripcióndebug Mayor información registrada en syslog.conf=<archivo> Un archivo de configuración alternativo al

/etc/security/limits.conf.


Asegúrese que el archivo /etc/pam.d/system-auth contiene la línea:

session required pam_limits.so

Para la instalación de una base de datos Oracle por ejemplo, se requiere que se modifiquen los parámetros para el usuario oracle como sigue:

# <domain> <type> <item> <value>oracle soft nproc 2047oracle hard nproc 16384oracle soft nofile 1024oracle hard nofile 65536

Los comodines * y % tienen el siguiente significado con maxlogins siendo “*” cada usuario y “%” el total de los usuarios.

# <domain> <type> <item> <value># Cada usuario puede tener dos sesiones como máximo* - maxlogins 2# El sistema soporta como máximo 30 usuarios concurrents% - maxlogins 30# Los miembros del grupo soporte pueden iniciar 4 sesiones como máximo%soporte - maxlogins 4

El archivo /etc/security/limits.conf contiene ejemplos de utilización.

Módulo pam_deny

Este módulo puede ser utilizado para denegar acceso. Siempre indica fallo a la aplicación a través de la infraestructura PAM. Este modulo es apropiado para las entradas por defecto (other).



Grupos administrativos


● account

● authentication

● password

● session


Apilando este modulo con el tipo account no permitirá al usuario obtener acceso al sistema. Es normalmente utilizado como el último módulo de la pila en el archivo system-auth para denegar el acceso si el usuario no puede ser autenticado.

auth required pam_env.soauth sufficient pam_unix.so nullok try_first_passauth requisite pam_succeed_if.so uid >= 500 quietauth required pam_deny.so

También es utilizado como política por defecto en el archivo /etc/pam.d/otherauth required pam_deny.soaccount required pam_deny.sopassword required pam_deny.sosession required pam_deny.so

Módulo pam_lastlog

Este modulo módulo puede desplegar información acerca del último inicio de sesión del usuario como el siguiente:

Ultimo inicio de sesión: jue feb 15 12:21:44 PYST 2007 en pts/3

Este módulo además actualiza el archivo /var/log/lastlog.



● authentication

Dependencias del sistema

El módulo depende del archivo /var/log/lastlog.



Argumentos

Argumento Descripcióndebug Mayor información registrada en syslog.nodate No muestra la fecha del último inicio de sesión.noterm No muestra la terminal del último inicio de sesión.nohost No muestra el host del último inicio de sesión.


Para que todos los servicios que utilizan PAM registren el inicio de sesión del usuario, agregue la siguiente línea al archivo /etc/pam.d/system-authsession optional pam_lastlog.so

Módulo pam_listfile

Este módulo permite o deniega el acceso al servicio basándose en una lista de usuarios obtenida de un archivo arbitrario.

Grupos de gestión


● authentication

Argumentos

Argumento Descripciónsense=<allow|deny> Si sense=allow entonces se retorna PAM_SUCESS

siendo la autenticación satisfactoria. Si sense=deny PAM_AUTH_ERR es retornado, haciendo que la autorización falle.

file=filename Indica el nombre del archivo del cual obtener la lista de usuarios.

item=<user|tty|rhost|ruser|group|shell>

Identifica el ítem especificado, user es el nombre del usuario (PAM_USER), tty especifica el nombre de la terminal remota (PAM_TTY), rhost especifica el nombre del host remoto (PAM_RHOST) y ruser identifica el nombre del usuario remoto (PAM_RUSER), y busca la instancia del ítem en el archivo especificado.



Argumento Descripciónonerr=<succeed|fail> Si un error ocurre, por ejemplo el archivo no existe,

entonces onerr=succeed permitirá la autenticación, de otro modo, si onerr=fail, se denegará la autenticación.

apply=user|@group Un argumento adicional, apply=, puede ser utilizado para restringir a un usuario específico o un grupo específico de la forma apply=usuario o apply=@grupo.


El clásico archivo ftpusers es utilizado para denegar acceso ftp a las cuentas listadas en el archivo. La configuración del archivo /etc/pam.d/vsftpd es como sigue:

auth required pam_listfile.so item=user sense=deny file=/etc/vsftpd/ftpusers onerr=fail

Usuarios listados en el archivo /etc/ftpusers no se permite el acceso por ftp (sense=deny). Si ocurre un error, el acceso será denegado.

Módulo pam_mail

Este módulo verifica el directorio de correo del usuario e indica si existe algún correo en él.

Dependencias del sistema

El directorio /var/spool/mail/



● session

Argumentos

Argumento Descripcióndebug Escribe información a syslog.dir=<ruta> Verifica el correo del usuario en un directorio alternativo.empty Indica que el directorio de mail está vacío si es el caso.



Argumento Descripciónhash=<cantidad> Profundidad del directorio mail hash. Si cuenta es 2 entonces

el archivo de correo sería /var/spool/mail/u/s/user.quiet Solo reporta cuando existe un correo nuevo.


Este módulo puede usarse para indicar al usuario si tiene correo nuevo cuando ingresa al sistema. Por ejemplo, el archivo /etc/pam.d/login podría contener una línea como la siguiente:

session optional pam_mail.so

Modulo pam_mkhomedir

Crea directorios home para los usuarios autenticados.



● session

Argumentos

Argumento Descripcióndebug Escribe información a syslogskel=<directorio> El directorio skeleton a utilizar para copiar los archivos

predeterminados al directorioumask El valor octal el cual define los permisos por defecto del

directorio


Este módulo es útil cuando se utiliza un sistema de autenticación basada en directorio, como NIS, NIS+ o LDAP, de tal forma que cuando el usuario inicia sesión en cualquier sistema, si el directorio HOME no existe es automáticamente creado.

Para lograr esto edite el archivo /etc/pam.d/system-auth y agregue una línea como la siguiente:

session required pam_mkhomedir.so skel=/etc/skel/ umask=0022



Módulo pam_nologin

Si el archivo /etc/nologin existe, solamente se permite el inicio de sesión al usuario root, otros usuarios no pueden iniciar sesión y se despliega el contenido del archivo /etc/nologin.

El administrador puede configurar el archivo nologin con el argumento file=ruta.

Grupos de gestión


● authentication


El siguiente es un ejemplo de un archivo /etc/pam.d/login por defecto.

auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.soauth include system-authaccount required pam_nologin.so

Módulo pam_permit

Este módulo es muy peligroso. Debe usarse con extrema precaución. Su función es permitir acceso.

Grupos de gestión


● account

● authentication

● password

● session


Si un administrador desea desactivar la autenticación para el uso de una estación de trabajo puede configurar el archivo /etc/pam.d/login como sigue:

account required pam_permit.so



Módulo pam_rootok

Este módulo es para utilizar en situaciones donde el superusuario desea obtener acceso a un servicio sin necesidad de una contraseña.

Grupos de gestión


● authentication


En el caso de la aplicación su, se permite al root adoptar la identidad de cualquier usuario sin especificar una contraseña. El archivo /etc/pam.d/su contiene una línea como la siguiente:

auth sufficient pam_rootok.soauth include system-auth

Módulo pam_securetty

Provee una verificación estándar de Unix securetty, donde provoca que la autenticación para root falle a menos que la terminal esté listada en el archivo /etc/securetty.

Grupos de gestión


● authentication


El archivo /etc/pam.d/login por defecto contiene una línea como la siguiente:

auth required pam_securetty.so

Módulo pam_tally2

Este módulo mantiene una cuenta de los intentos de acceso, puede acerar el contador en éxito, puede denegar el acceso si se fallan muchos intentos.



Grupos de gestión


● authentication

● account

Dependencias

El módulo depende del archivo /var/log/tallylog.

Argumentos

Los argumentos generales del módulo son:

Argumento Descripciónonerr=succeed|fail Si ocurre un error, cómo el módulo debe reaccionar.file=<ruta/al/archivo> Especifica el archivo para mantener la cuenta de

inicio de sesión. Por defecto el /var/log/tallylog.

audit Si el usuario no es encontrado mostrara el nombre en syslog

Componente authentication

Verifica si el acceso al usuario debe ser denegado e incrementa el contador de inicios de sesión.

Los argumentos para el componente authentication son:

Argumento Descripcióndeny=n Denegar acceso cuando los intentos fallidos son n.lock_time=n Denegar durante n segundosunlock_time=n Permite el acceso transcurrido de n segundos luego

del último inicio de sesión inválido.magic_root Indica que si el modulo es invocado por un usuario

con uid=0, entonces no se incrementa el contador. Para servicios lanzados por el usuario, como el su el argumento debe ser utilizado.

even_deny_root Tiene la posibilidad de bloquear la cuenta root.



Argumento Descripciónroot_unlock_time=n Igual a unlock_time pero solo afecta a la cuenta

root.

Para acerar manualmente el contador puede utilizar el comando pam_tally2, la sintaxis del comando es como sigue:

pam_tally2 [--file rooted-filename] [-u usuario] [-r] [--reset[=n]] [--quiet]

Componente account

El componente account es opcional y reinicia los contadores. Además, verifica que el archivo existe y no es escribible por todos.

Los argumentos para el componente account son:

Argumento Descripciónmagic_root Indica que si el modulo es invocado por un usuario

con uid=0, entonces no se incrementa el contador. Para servicios lanzados por el usuario, como el su el argumento debe ser utilizado.

no_reset No reinicia el contador luego de un inicio de sesión correcto, lo decrementa.


Para denegar el acceso luego de 5 intentos de inicio de sesión inválidos configure el archivo /etc/pam.d/system-auth como sigue:

auth required pam_tally2.so onerr=fail deny=5

Si un usuario se ha equivocado la contraseña mas de cinco veces, la cuenta es bloqueada y en el archivo /var/log/secure podrá encontrar una línea como la siguiente:

Aug 4 17:33:42 serv1 pam_tally[31348]: user jperez (1241) tally 6, deny 5

Para desbloquear la cuenta del usuario debe reiniciar a 0 la cantidad de intentos erróneos para la cuenta con el siguiente comando:

# pam_tally2 -u jperez -r

Módulo pam_time

Este módulo ofrece control de tiempo para el acceso a servicios ofrecidos por un sistema. Este módulo puede ser configurado para denegar el acceso a usuarios



basados en su nombre, hora del día o día de la semana y terminal que solicita el servicio.

Grupos de gestión


● account

Dependencias

Requiere de un archivo de configuración /etc/security/time.conf. Cada regla del archivo tiene la siguiente forma:

servicios;ttys;usuarios;tiemposEn palabras, cada línea es una regla. Consta de cuatro campos separados por punto y coma, “;”, Los campos son:

● servicios - Lista de servicios afectados por esta regla.

● ttys - Lista de terminales afectadas por la regla

● usuarios - Lista de usuarios a los cuales se aplica la regla.

La lista no puede contener más de un comodín y opcionalmente, el operador de negación al principio “!”. Cada secuencia es concatenada por el operador AND & o el operador OR | . Por ejemplo:

!morgan&!root Indica que la regla no se aplica a morgan o root

tty*&!ttyp*Indica que la regla se aplica solamente a terminales consola, no a pseudo terminales.

● tiempos - Lista de tiempos que se aplica esta regla. Cada elemento es un rango de día/tiempo. Los días son especificados por una secuencia de dos caracteres, por ejemplo:

MoTuSaIndica Lunes, Miércoles, Viernes.

Días repetidos son eliminados, por ejemplo:



MoTuMoIndica solamente Miércoles.

Los días aceptados son:

Mo Tu We Th Fr Sa Su Wk Wd AlSiendo los tres últimos, toda días entre semana, los fines de semana y toda la semana respectivamente.

Un rango de horas es un par de horas en formato 24 H, HHMM separado por un guión. Por ejemplo:

Mo1800-0300Indica los lunes desde las 18 hasta las 3 AM del día siguiente.


El archivo /etc/pam.d/system-auth podría configurarse como sigue:

account required pam_time.soEl archivo /etc/security/time.conf puede ser:

login;*;!root;Al0800-1800ssh;*;!root;Al0800-1800Todos los usuarios, excepto root, se permite el inicio de sesión desde las 08:00 hasta las 18:00. Fuera de ese horario, el inicio de sesión será denegado.

Módulo pam_unix

Es el módulo estándar de autenticación unix. Utiliza llamadas estándar de las bibliotecas del sistema para obtener y establecer la información de cuenta como autenticación. Usualmente es obtenido del archivo /etc/passwd y el archivo /etc/shadow.

Grupos de gestión


● account

● authentication

● password



● session

Componente account

Basado en los elementos del shadow: expire, last_change, max_change, min_change y warn_change el módulo realiza las tareas de establecer el estado de la cuenta de un usuario y su contraseña. Puede avisar al usuario que su contraseña debería ser cambiada.

Por ejemplo, la siguiente línea del archivo /etc/pam.d/system-auth verifica que la cuenta y la contraseña están aún activas

account required pam_unix.so broken_shadowEl argumento broken_shadow ignora errores en la lectura de la información shadow.

Componente authentication

Este componente autentica al usuario.

Los argumentos válidos para el componente authentication son:

Argumento Descripcióndebug Envía información adicional a syslog.nullok Permite contraseñas en blancouse_fist_pass Este módulo no pregunta por la contraseña del usuario, en

lugar de ello, debería utilizar la contraseña previamente digitada para el módulo anterior. Si no funciona el usuario no será autenticado.

try_first_pass El módulo debería intentar una autenticación con la contraseña previa, si no funciona, se solicita al usuario una contraseña.

nodelay Evita la espera de un segundo entre intentos de autenticación.

Por ejemplo, la siguiente línea del archivo /etc/pam.d/system-auth autentica al usuario:

auth sufficient pam_unix.so nullok try_first_pass

Componente password

Esta parte del módulo actualiza la contraseña del usuario.



Los argumentos válidos para el componente password son:

Argumento Descripciónmd5 En el caso de una base de datos de usuario convencional de

usuarios del unix, el argumento md5 es utilizado para utilizar el método de encriptación md5 en oposición al tracicional crypt. Esto permite contraseñas mayores a 8 caracteres.

nullok Permite el cambio de contraseñas que están en blanco, de otro modo se considera una cuenta con contraseña en blanco como bloqueada.

use_fist_pass Este módulo no pregunta por la contraseña del usuario, en lugar de ello, debería utilizar la contraseña previamente digitada para el módulo anterior. Si no funciona el usuario no será autenticado.


use_authok Es utilizado para forzar al módulo a establecer la contraseña a la proveída por el módulo anterior.

remember=n El número de contraseñas más recientes a guardar para cada usuario. El archivo en el que son almacenadas las contraseñas anteriores es /etc/security/opasswd.

Por ejemplo, las siguientes líneas del archivo /etc/pam.d/system-auth indican al módulo pam_unix que utilice la contraseña proporcionada por el módulo pam_cracklib, permita el cambio de contraseñas en blanco, utilice md5 para la encriptación contraseñas y que recuerde 6 contraseñas anteriores.

passwd password required pam_cracklib.so retry=3 minlen=6 difok=3passwd password required pam_unix.so use_authtok nullok md5 remember=6

Componente session

No se reconoce argumentos en este componente. Su función es simplemente registrar el usuario y el tipo de servicio a syslog. Los mensajes son registrados al al final de una sesión.

Por ejemplo, el valor por defecto del archivo /etc/pam.d/system-auth es el siguiente:

session required pam_unix.so



Modulo pam_warn

Este módulo existe principalmente para registrar información acerca de una autenticación o solicitud de actualización de contraseña. Registra el servicio, la terminal, el usuario, el usuario remoto y el host remoto.

Grupos de gestión


● authentication

● password


Cada servicio que no tiene configurado un fichero en /etc/pam.d utilizará las reglas de /etc/pam.d/other. Por defecto, se establece deny para mayor seguridad. Sin embargo, es util agregar mayor información a ser registrada:

auth required pam_deny.soauth required pam_warn.soaccount required pam_deny.soaccount required pam_warn.sopassword required pam_deny.so password required pam_warn.so session required pam_deny.so session required pam_warn.so

Módulo pam_wheel

Permite el acceso como root solamente a usuarios miembros del grupo wheel.

Grupos de gestión


● authentication

Argumentos

Argumento Descripcióndebug Envía información adicional a syslog.



Argumento Descripcióndeny Utilizado para revertir la lógica del módulo. Si el usuario

tratando de obtener uid=0 pertenece al grupo weel, el acceso es denegado.

group=<nombre> En lugar de verificar el grupo wheel, utiliza el groupo <nombre> para la autenticación.

root_only Verifica si es miembro del grupo wheel solamente si el UID de la cuenta solicitada es 0.

use_uid La verificación de membresía de grupo se realizará en base al usuario actual en lugar del original (por ejemplo cuando utiliza su para cambiarse de una cuenta a otra).

Ejemplo/uso sugerido

Para restringir el acceso a root solo a miembros del grupo wheel, descomente la siguiente entrada del archivo /etc/pam.d/su:

auth sufficient pam_wheel.so trust use_uid

Módulo pam_ldap

El módulo pam_ldap proporciona autenticación, autorización y cambio de contraseñas en cuentas almacenadas en un servidor LDAP.

Grupos de gestión


● authentication

● password

● session

Dependencias

El módulo requiere del archivo /etc/ldap.conf y /etc/openldap/ldap.conf.

Argumentos




Argumento Descripciónuse_fist_pass Este módulo no pregunta por la contraseña del

usuario, en lugar de ello, debería utilizar la contraseña previamente digitada para el módulo anterior. Si no funciona el usuario no será autenticado.


ignore_unknown_user Permite configurar el módulo de tal forma a requerir la autenticación de cuentas que existan en LDAP, pero permitir la autenticación de cuentas que no existen usando otro módulo, por ejemplo pam_unix.

ignore_authinfo_unavail Indica que el módulo no debe retornar error en caso de no poder contactar con el servidor LDAP.

use_authok Análogo a use_first_pass pero sólo para el grupo de gestión password.


El módulo es utilizado para autenticar usuarios Linux contra un controlador de directorio LDAP. Puede configurar la autenticación LDAP usando authconfig o system-config-authentication.

Módulo pam_smb_auth

El módulo pam_smb_auth permite la autenticación de de servidores Linux usando un servidor Windows.

Grupos de gestión


● authentication

Argumentos




Argumento Descripciónuse_fist_pass ste módulo no pregunta por la contraseña del usuario, en

lugar de ello, debería utilizar la contraseña previamente digitada para el módulo anterior. Si no funciona el usuario no será autenticado.

nolocal Permite la autenticación de usuarios que no se encuentran en el archivo local de contraseñas.


El módulo es utilizado para autenticar usuarios Linux contra un controlador de dominio Windows. Puede configurar la autenticación SAMBA usando authconfig o system-config-authentication.


5Auditoria del sistema

Auditoria del sistema

Introducción

El subsistema de auditoria implementa una solución de monitoreo centralizado para mantener registro de todos los eventos de seguridad relevantes, tales como cambios o intentos de cambio en archivos de seguridad críticos del sistema.

Esto es realizado a través de dos mecanismos separados. Todas las llamadas de sistema son interceptadas y el kernel escribe los parámetros y el valor de retorno al registro de auditoria para aquellas llamadas que fueron marcadas como relevantes en el archivo de configuración basado en filtros.

Uso del subsistema de auditoria

El Perfil de Protección de Acceso Controlado (Controlled Access Protection Profile – CAPP) especifica los requerimientos de auditoria que el sistema debe soportar. La configuración evaluada descrita aquí esta basada en estos requerimientos.

Un sistema CAPP es aquel que ha sido diseñado y configurado para cumplir el CAPP para la evaluación de seguridad de acuerdo al Criterio Común (Common Criteria). El CAPP especifica los requerimientos funcionales del sistema, similar al anterior TSEC C2 estándar (también conocido como el libro naranja).

Algunos requerimientos CAPP pueden conflictuar con los requerimientos específicos de su sistema. Por ejemplo, un sistema que cumple con CAPP debe deshabilitar los inicios de sesión si el sistema de auditoria no está funcionando.

CAPP es diseñado para un sistema multiusuario, con múltiples usuarios únicos que mantienen recursos compartidos y privados. Es menos útil para un servidor de aplicaciones o que no cuenta con usuarios interactivos.

Tenga en cuenta que cuando el subsistema de auditoria es activado, provoca cierta degradación de rendimiento para las aplicaciones en el servidor. El impacto depende de que está realizando la aplicación y cómo es configurado el subsistema de auditoria. Como regla general, las aplicaciones que abren un gran número de archivos son los más afectados, mientras que programas CPU intensivo no deberían ser notablemente afectados.

Para utilizar el subsistema de auditoria el paquete audit debe estar instalado, para verificar si el paquete esta instalado ejecute el comando:

# rpm -qi audit

Si no esta instalado instale el subsistema de auditoria con el comando:

# rpm -Uvh audit-<version>.rpm audit-libs-<version>.rpm



Selección de eventos a ser auditados

Es posible realizar cambios al conjunto de llamadas del sistema y eventos que serán auditados. CAPP requiere que el sistema tenga la capacidad de auditar eventos relativos a la seguridad, pero depende de usted seleccionar como utilizar estas capacidades.

El paquete audit proporciona una configuración sugerida para sistemas CAPP en el archivo /usr/share/doc/audit-*/capp.rules. Este archivo contiene una configuración sugerida para un sistema multiusuario, todos los accesos de seguridad relevantes son auditados, además de otros eventos relevantes de seguridad como la reconfiguración del sistema. Podría copiar este archivo a /etc/audit/audit.rules y modificar la configuración de acuerdo a sus requerimientos locales.

Podría selectivamente habilitar y deshabilitar la auditoria para eventos o usuarios específicos modificando el archivo audit.rules. Es recomendado que siempre reconfigure el sistema de auditoria modificando el archivo /etc/audit/audit.rules y luego ejecutar el siguiente comando para recargar las reglas:

# auditctl -R /etc/audit/audit.rules

Note que recargar las reglas involucra borrar todas las reglas, y por un corto periodo de tiempo, el sistema estará operando sin reglas o con reglas parciales de auditoria.

Reglas de auditoria

El archivo audit.rules contiene las reglas de auditoria para el sistema auditd. El archivo audit.rules utiliza como reglas cualquier opción que pueda ser especificada al comando auditclt.El comando auditclt permite crear o borrar reglas del sistema de auditoria, establecer el comportamiento del sistema en caso de fallos.

Las reglas del sistema están compuestas de un elemento a monitorear (watch) y una clave de filtro (key) para identificar los registros generados por el monitoreo. La clave de filtro puede ser usada para buscar en los registros de auditoria los eventos relacionados a ese monitoreo.

Por ejemplo, para definir un monitoreo sobre el archivo /etc/hosts, utilice el siguiente comando:

# auditctl -w /etc/hosts -p war -k CFG_hosts

En este ejemplo, un monitoreo es ubicado sobre el archivo /etc/hosts (-w



/etc/hosts) para cualquier llamada del sistema que realizaría una escritura, lectura o cambio de atributo (-p war). Esto es registrado con la clave CFG_hosts (-k CFG_hosts). Esta clave puede ser usada para buscar en los registros usando el comando ausearch.Las opciones mas comunes del comando auditctl son:

Opción Descripción-e [0|1] Habilita o deshabilita la auditoria.-f [0..2] Especifica el comportamiento ante un fallo, siendo

0=silent, 1=printk 2=panico.-k Indica una clave de filtro para la regla de auditoria.-p [r|w|x|a] Establece el filtro de permisos para el monitoreo siendo

r=read, w=write, x=execute, a=attribute change.-R <archivo> Lee las reglas del archivo.-s Reporta el estado.-D Borra todas las reglas y monitoreos.-w <ruta> Inserta un monitoreo para un objeto del sistema de

archivos. Si desea monitorear un directorio, es recomendado que defina un monitoreo para cada archivo del directorio.

-a <lista,accion> Agrega la regla al final de la lista con la acción indicada. Las listas comúnmente utilizadas son entry y exit. Las acciones pueden ser never, always. Para mas información consulte la página de man de auditctl.

-S [syscall|all] El nombre de la llamada al sistema a monitorear.-F Construye un campo de regla: nombre, operación, valor.-l Lista las reglas

Algunas de las llamadas del sistema podrían ser:

Syscall Descripciónopen, creat Abre y posiblemente crea un archivo o dispositivo.execve Ejecutar un programa.exit Termina el proceso actual.mkdir Crea un directorio.unlink Borra un nombre y posiblemente el archivo al que refiere.mknod Crea un directorio, archivo especial o regular.



Syscall Descripciónrmdir Borra un directoriochown, lchown Cambia el propietario de un archivochmod Cambia los permisos de un archivosymlink, link Crea un nuevo nombre a un archivorename Cambia el nombre o la ubicación de un archivotruncate Trunca un archivo al tamaño especificadochroot Cambia el directorio rootsetuid Estableder la identidad de un usuariosetreuid Estableder el ID real o efectivo de un usuariosetresuid Estableder el ID real o efectivo de un usuariosetgid Establecer la identidad de gruposetregid Establecer el ID de grupo real/efectivosocketcall Funciones de red, incluyendo connect y accept

Para consultar las llamadas al sistema definidas y el número que corresponde con cada una, consulte el archivo /usr/include/asm*/unistd.h.

A continuación se ven algunos ejemplos del comando auditctl:

Para ver todas las llamadas del sistema hecha por un programa:

# auditctl -a exit,always -S all -F pid=1005

Para ver todos los archivos abiertos por un usuario específico:

# auditctl -a exit,always -S open -F auid=510

Para ver llamadas open no exitosas:

# auditctl -a exit,always -S open -F success!=0

Si se auditan las llamadas al sistema al momento de entrada, se almacenan información tales como el número de syscall y marcas de tiempo, pero no los argumentos. Si se auditan las llamadas al sistema al momento de salida, se incluye información tal como nombre de archivo y número de inodo (si esta disponible).

Leyendo y buscando registros de auditoria

Use la herramienta ausearch para obtener información de los registros de auditoria. La información disponible para obtener depende de la configuración del



filtro. La sintaxis general del comando es:

ausearch [opciones]

Las opciones mas comunes son:

Opción Descripción-a <id de evento> Busca un evento basado en el ID.-f <archivo> Busca un evento basándose en el nombre de un archivo.-gi <GID> Busca un evento basándose en el GID.-if <archivo> Utilice el archivo especificado en lugar de los logs.-k <clave> Busca un evento basándose en la clave.-p <PID> Buscan un evento basándose en el PID.-sc Busca un evento que concuerde con la llamada del sistema

especificada.-sv <yes|no> Busca un evento que concuerde con el valor de éxito.-te [fecha] [hora] Busca eventos con marcas de tiempo igual o anteriores al

especificado.-ts [fecha] [hora] Busca eventos con marcas de tiempo igual o posteriores al

especificado.-ui <UID> Busca un evento basándose en el UID.-ul <login> Busca un evento basándose en el login ID del usuario.-x <ejecutable> Busca un evento que concuerde con el nombre del

ejecutable.

Por ejemplo, suponga un archivo de reglas para el sistema de auditoria con una regla como la siguiente:

-w /etc/shadow -p war -k security-file

Una vez iniciado el demonio auditd, podrá ver las reglas con el comando auditctl -l:

# service auditd start

Iniciando auditd: [ OK ]

# auditctl -l

LIST_RULES: exit,always watch=/etc/passwd perm=rwa key=security-file

Con la regla indicada se monitoreará todo intento de acceso al archivo /etc/shadow.



Suponga que un usuario intenta editar el archivo /etc/shadow con el comando vim, para listar los eventos registrados utilice el comando ausearch como sigue:

# ausearch -f /etc/shadow----time->Mon Feb 19 06:25:38 2007type=PATH msg=audit(1171877138.275:112): item=0 name="/etc/shadow" inode=620370 dev=fd:00 mode=0100400 ouid=0 ogid=0 rdev=00:00type=CWD msg=audit(1171877138.275:112): cwd="/home/iferreira"type=SYSCALL msg=audit(1171877138.275:112): arch=40000003 syscall=5 success=no exit=-13 a0=90e5b08 a1=8000 a2=0 a3=8000 items=1 ppid=6699 pid=6717 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts3 comm="vim" exe="/usr/bin/vim" key="security-file"

De este comando puede ver que el usuario con uid=500 ejecuto la syscall=5 (open) sin éxito sucess=no a través del comando vim (comm=vim).

Otros métodos para obtener la misma información serían podrían ser:

# ausearch -ui 500

Obtener la información del usuario con UID=500.

# ausearch -k security-file

Obtener la información usando el filtro security-file# ausearch -x vim

Obtener la información de los eventos que fueron generados por el programa vim.# ausearch -x vim -ui 500

Obtener información de los eventos que fueron generados por el programa vim ejecutados por el usuario con UID 500.

# ausearch -x vim -ui 500 -sv no

Obtener información de los eventos que fueron generados por el programa vim ejecutados por el usuario con UID 500 y el acceso fue denegado.

La herramienta aureport produce un resumen de auditoría. La sintaxis del comando es:

aureport [opciones]

Las opciones mas comunes son:

Opción Descripción-c Reporta cambios de configuración.



Opción Descripción-f Reporta acerca de archivos.-l Reporta acerca de logins.-p Reporta acerca de procesos.-u Reporta acerca de usuarios.-s Reporta llamadas del sistema.-te [fecha] [hora] Reporta eventos con marcas de tiempo igual o anteriores

al especificado.-ts [fecha] [hora] Reporta eventos con marcas de tiempo igual o

posteriores al especificado.

Almacenamiento de los registros de auditoria

La configuración del sistema de auditoria es realizada a través del archivo /etc/audit/auditd.conf. En este archivo se especifican los valores de almacenamiento del los registros de auditoria. Entre las opciones del archivo de configuración se encuentran:

Opción Descripciónlog_file=<archivo> La ruta completa al archivo de registro.log_format=<raw|nolog> El formato de registro. Por defecto se utiliza raw, si

se indica nolog el sistema descarta los eventos.max_log_file=<tamaño MB> El tamaño máximo del archivo en MB. Cuando se

alcanza el límite, se iniciará una acción configurable.max_log_file_action=<accion> La acción a tomar cuando se alcanza el tamaño

máximo del registro, puede ser ignore, syslog, suspend, rotate, keep_logs.

num_logs=<n> Especifica el número de archivos de registro a mantener si rotate ha sido dado como max_log_file_action. El número debe ser menor a 99.

space_left=<tamaño MB> Cuando el espacio disponible en disco alcanza el valor especificado el demonio de auditoria ejecuta una acción.

space_left_action=<tamaño MB> Indica la acción a ejecutar cuando el espacio el espacio disponible del disco alcanza el límite establecido. Las acciones son ignore, syslog, email, suspend, single, halt.



Opción Descripciónadmin_space_left=<tamaño MB> Cuando el espacio disponible en disco alcanza el

valor especificado el demonio de auditoria ejecuta una acción.

admin_space_left_action Indica la acción a ejecutar cuando el espacio el espacio disponible del disco alcanza el límite establecido. Las acciones son ignore, syslog, email, suspend, single, halt.

disk_full_action Este parámetro indica al sistema la acción a tomar cuando el sistema detecta que el sistema de archivos donde se registran los eventos está lleno. Las acciones son ignore, syslog, email, suspend, single, halt.

disk_error_action Este parámetro indica al sistema la acción a tomar cuando el sistema detecta un error durante la escritura de los eventos o rotación de logs. Las acciones son ignore, syslog, email, suspend, single, halt.

El valor por defecto del archivo de configuración /etc/audit/auditd.conf es el siguiente:

## This file controls the configuration of the audit daemon#

log_file = /var/log/audit/audit.loglog_format = RAWpriority_boost = 3flush = INCREMENTALfreq = 20num_logs = 4dispatcher = /sbin/audispddisp_qos = lossymax_log_file = 5max_log_file_action = ROTATEspace_left = 75space_left_action = SYSLOGaction_mail_acct = rootadmin_space_left = 50admin_space_left_action = SUSPENDdisk_full_action = SUSPENDdisk_error_action = SUSPEND



Visor de auditoría

El visor de auditoría, audit-viewer es una interfaz gráfica desarrollada para facilitar la la visualización de eventos. La aplicación básicamente ejecuta comandos de shell y da formato a los logs de auditoría.

Al ejecutar el comando audit-viewer, la ventana principal aparece con todos los eventos de auditoría registrados.

Puede abrir múltiples pestañas seleccionando del menú principal Ventana, Nueva Lista.

Para aplicar filtros de búsqueda, haga clic sobre la lista desplegable Filro.

En la pestaña Filtro puede agregar los filtros de búsqueda para los registros de auditoría.



En la pestaña General puede establecer un nombre diferente a la lista y ordenar los resultados por hora o un campo diferente, de manera ascendente o descendente.

En la pestaña Columnas puede establecer la lista de columnas que serán mostradas en el informe.



En la pestaña Filtrar por Fecha, puede establecer un rango de fecha y hora para la búsqueda en los registros de auditoría.

En la pestaña Expresión puede escribir el filtro de búsqueda utilizando los comandos de ausearch.



Almacenamiento remoto de los registros de auditoria

Si la seguridad del sistema ha sido comprometida, es posible que los registros de auditoría sean desactivados o eliminados. Por este motivo, es importante almacenar los registros de auditoría en un servidor remoto. Aún cuando el atacante remueva los registros o desactive la auditoría, los eventos ya habrán sido transferidos al sistema remoto.

El paquete audisp-plugins debe ser instalado en el cliente y los parámetros para remote_server y port deben ser establecidos en el archivo de configuración /etc/audisp/audisp-remote.conf.

En el servidor, el cual almacenará los registros, el parámetro tcp_listen_port debe ser establecido con el mismo valor que en los clientes.

Debido a que el demonio auditd está protegido por SELinux, semanage debe además tener el puerto listado en su base de datos. Si el servidor y el cliente han sido configurados para usar un puerto diferente a 60, por ejemplo 2000, ejecute el siguiente comando para configurar SELinux:

# semanage port -a -t audit_port_t -p tcp 2000


6AIDE

AIDE

Introducción

AIDE (Advanced intrusion detection environment) es un programa de detección de intrusos. Más específicamente un verificador de integridad de archivos.

AIDE construye una base de datos con información acerca de los archivos y directorios indicados en su configuración. La base de datos de AIDE almacena varios atributos del archivo, incluyendo permisos, número de inodo, usuario, grupo, tamaño, marcas de tiempo, etc. AIDE además almacena el checksum de cada archivo utilizando una combinación de los siguientes algoritmos: sha1, sha256, sha512, md5, rmd160, tiger. Adicionalmente, los atributos extendidos como ACL, xattr y SELinux pueden ser utilizados si son habilitados al momento de la compilación del software.

Típicamente, un administrador de sistemas creara una base de datos AIDE en un nuevo sistema antes de conectarlo a la red. La primera base de datos AIDE es una foto del sistema en su estado normal y el punto de inicio a partir del cual todos los cambios del sistema son medidos.

La base de datos debería contener principalmente los binarios del sistema, bibliotecas y archivos de configuración. Podría desear excluir directorios que cambian constantemente, como /var, /tmp y /home. Por otra parte, un atacante podría dejar archivos en estos directorios debido a que muchas personas lo excluyen de la base de datos IDS. Es necesario analizar el equilibrio entre seguridad y facilidad de administración.

Instalación de AIDE

AIDE es distribuido como paquete en el medio de instalación de Red Hat/CentOS. Para instalarlo, simplemente utilice el comando rpm o el comando yum:

# rpm -ivh aide-*Preparing... ########################################### [100%] 1:aide ########################################### [100%]

El paquete instalará un archivo de configuración de ejemplo, /etc/aide.conf, el cual deberá personalizar.

Configuración de AIDE

El archivo aide.conf contiene la configuración que AIDE usa para inicializar o verificar la base de datos.

El archivo de configuración es sensible a mayúsculas y minúsculas. Existen tres tipos de líneas en el archivo de configuración:


AIDE

● Líneas macro: Definen variables dentro del archivo de configuración

● Líneas de configuración: Utilizadas para establecer parámetros de configuración.

● Líneas de selección: Indican que archivos deben ser agregados a la base de datos

Líneas macro

Las líneas macro definen variables utilizando la siguiente sintaxis:

@@define VARIABLE valor

Para eliminar la definición de la variable, utilice:

@@undefine VARIABLE valor

Puede definir líneas de configuración dependiendo de la existencia de otras variables, con la siguientes sintaxis:

@@ifdef VARIABLE | @@ifndef VARIABLE@@else@@endif

Las líneas entre @@ifdef y @@endif son utilizadas si VARIABLE es definida. La declaración @@ifndev indica que VARIABLE no debe estar definida.

@@ifhost <hostname> | @@ifnhost <hostname>

Estas declaraciones verifican si el nombre de hsot es igual al que AIDE se está ejecutando.

Para utilizar el valor de una variable, indiquela utilizando la siguiente sintaxis:

@@{VARIABLE}

Líneas de configuración

Estas líneas tienen el formato parametro=valor. Los parámetros pueden utilizar URLs para indicar de dónde se obtendrá la entrada o la salida. Los URLs pueden ser los siguientes:

● stdout● stderr● stdin


AIDE

● file::/archivoLos parámetros mas comunes son:

● Parámetro database: El URL de donde la base de datos es leída.

● Parámetro database_out: El URL de donde la base de datos es escrita.

● Parámetro database_new: El URL de donde la otra base de datos es leída cuando se utiliza la opción --compare.

● Parámetro verbose: El nivel de mensajes a ser desplegados en la salida.

● Parámetro report_url: El URL donde reporte es escrito.

● Parámetro gzip_dbout: Si la base de datos es compresa o no.

● Parámetro acl_no_symlink_follow: Establece si se verifican ACLs para enlaces simbólicos.

● Parámetro warn_dead_symlinks: Advertir acerca de enlaces simbólicos muertos.

● Parámetro report_attributes: Lista de parámetros que siempre serán mostrados al final del reporte.

● Parámetro config_version: El valor es mostrado en el reporte para propósitos informativos.

El archivo de configuración por defecto define las siguientes macro y parámetros:

@@define DBDIR /var/lib/aide@@define LOGDIR /var/log/aide

database=file:@@{DBDIR}/aide.db.gzdatabase_out=file:@@{DBDIR}/aide.db.new.gz

gzip_dbout=yesverbose=5

report_url=file:@@{LOGDIR}/aide.logreport_url=stdout

Lineas de selección

Las líneas de selección indican cuáles atributos serán verificados de cada archivo o directorio especificado. Los atributos a ser verificados son indicados a través de


AIDE

definiciones de grupo. Los grupos por defecto son:

#p: permissions#i: inode:#n: number of links#u: user#g: group#s: size#b: block count#m: mtime#a: atime#c: ctime#acl: Access Control Lists#selinux SELinux security context#xattrs: Extended file attributes#S: check for growing size#md5: md5 checksum#sha1: sha1 checksum#sha256: sha256 checksum#sha512: sha512 checksum#rmd160: rmd160 checksum#tiger: tiger checksum

#haval: haval checksum (MHASH only)#gost: gost checksum (MHASH only)#crc32: crc32 checksum (MHASH only)#whirlpool: whirlpool checksum (MHASH only)

#R: p+i+n+u+g+s+m+c+acl+selinux+xattrs+md5#L: p+i+n+u+g+acl+selinux+xattrs#E: Empty group#>: Growing logfile p+u+g+i+n+S+acl+selinux+xattrs

Es posible crear definiciones de grupo personalizadas, por ejemplo:

DIR = p+i+n+u+g+acl+xattrs

El grupo DIR verifica permisos, inodo, número de enlaces, usuario, grupo, ACLs y atributos extendidos.

NORMAL = R+rmd160+sha256

El grupo NORMAL incluye todas las verificaciones realizadas por el grupo R (p+i+n+u+g+s+m+c+acl+selinux+xattrs+md5) además de checksum rmd160 y sha256.

PERMS = p+i+u+g+acl

El grupo PERMS verifica los permisos, inodo, usuario, grupo y ACLs.


AIDE

LOG = >

El grupo LOG indica que es un archivo que únicamente debería crecer en tamaño.

AIDE soporta tres tipos de líneas de selección, regular, negativa e igual. Las líneas que comienzan con / son líneas regulares. Por ejemplo la siguiente regla:

/etc R

Indica que el directorio /etc y todos su contenido, será incluido en la base de datos, almacenando los atributos indicados por el grupo R.

Las líneas que comienzan con ! Indican que se debe ignorar ese archivo o directorio, por ejemplo la siguiente regla:

!/dev

Indica que el directorio /dev sea ignorado.

Las líneas que comienzan con = indican que el directorio indicado debe ser agragado, pero no los subdirectorios. Por ejemplo la regla:

=/tmp DIR

Indica que los atributros del grupo DIR serán aplicados al directorio /tmp, pero no a sus subdirectorios.

Algunas reglas establecidas en el archivo de configuración por defecto son las siguientes:

# Next decide what directories/files you want in the database.

/boot NORMAL/bin NORMAL/sbin NORMAL/lib NORMAL/opt NORMAL/usr NORMAL/root NORMAL# These are too volatile!/usr/src!/usr/tmp

# Check only permissions, inode, user and group for /etc, but# cover some important files closely./etc PERMS!/etc/mtab# Ignore backup files!/etc/.*~


AIDE

/etc/exports NORMAL/etc/fstab NORMAL/etc/passwd NORMAL/etc/group NORMAL/etc/gshadow NORMAL/etc/shadow NORMAL

Utilización de AIDE

Inicialmente, debe crear una base de datos sobre la cual se realizarán las comparaciones futuras. Esto es realizado por medio del comando:

# aide --init

AIDE, version 0.13.1

### AIDE database at /var/lib/aide/aide.db.new.gz initialized.

Este comando crea la base de datos que contienen todos los archivos que ha seleccionado en el archivo de configuración. La base de datos debería ser movida a un dispositivo de sólo lectura. El archivo de configuración no debería mantenerse en el servidor, un atacante podría leer el archivo de configuración y alterarlo, o identificar los directorios que AIDE no analiza.

Ubique la base de datos generada apropiadamente según el archivo de configuración, para utilizar el archivo de configuración por defecto ejecute:

# cd /var/lib/aide/# mv aide.db.new.gz aide.db.gz

Recuerde que esto provocará que la base de datos se mantenga en el disco local pudiendo ser comprometida su integridad.

Para realizar la verificación de la integridad de los archivos, ejecute el comando:

# aide --check

AIDE, version 0.13.1

### All files match AIDE database. Looks okay!

AIDE leerá la base de datos y comparará los archivos que existen en disco. AIDE podría encontrar cambios y dependerá del administrador la acción a tomar ante ellos.

# aide --checkAIDE found differences between database and filesystem!!Start timestamp: 2009-03-20 11:46:24


AIDE

Summary: Total number of files: 102708 Added files: 0 Removed files: 0 Changed files: 1

---------------------------------------------------Changed files:---------------------------------------------------

changed: /etc/shadow

--------------------------------------------------Detailed information about changes:---------------------------------------------------

File: /etc/shadow Mtime : 2008-10-17 21:10:08 , 2009-03-20 11:46:19 Ctime : 2008-10-17 21:10:08 , 2009-03-20 11:46:19 Inode : 134339 , 132521 MD5 : rttbK163hylot4JSx6oKIg== , RN9e+ykQ2oOaS9va323kSw== RMD160 : DpamzSbXGM8fjkev2SEyt+8V/tQ= , 8wbMNHESsgcEWQwPIQtrf5T2V1g= SHA256 : CZ6h6GLUAjjvguUVavWHWMDpS+ODQEQJ , AAj4QTBi90B9AywuGsXi1J4waDW/WQe7

Puede visualizar el reporte posteriormente consultando el archivo /var/log/aide/aide.log:

# more /var/log/aide/aide.log

Para actualizar cambios en el archivo de configuración o la base de datos, ejecute el comando:

# aide --update

Esto generará una nueva base de datos que debe ser transferida al medio de sólo lectura.

Puede además utilizar el comando aide --compare para verificar los cambios que existieron entre una base de datos y otra.


7GnuPG

GnuPG

Introducción

GnuPG es una herramienta de seguridad en comunicaciones electrónicas. Este capítulo es una guía rápida que cubre las funciones básicas de GnuPG. Estas funciones incluyen generar un par de claves, intercambiar y comprobar la autenticidad de claves, cifrar y descifrar documentos, y firmar documentos y verificar firmas digitales.

GnuPG utiliza criptografía de clave pública para que los usuarios puedan comunicarse de un modo seguro. En un sistema de claves públicas cada usuario posee un par de claves, compuesto por una clave privada y una clave pública. Cada usuario debe mantener su clave privada secreta; no debe ser revelada nunca. La clave pública se puede entregar a cualquier persona con la que el usuario desee comunicarse. GnuPG implementa un esquema algo más sofisticado en el que un usuario tiene un par de claves primario, y ninguno o más de un par de claves adicionales subordinadas. Los pares de claves primarios y subordinados se encuentran agrupados para facilitar la gestión de claves, y el grupo puede ser considerado como un sólo par de claves.

Las llaves se pueden usar de dos maneras diferentes: para proporcionar confidencialidad al mensaje y para probar la autenticidad del originador de un mensaje. En el primer caso, el emisor usa la llave pública del receptor para encriptar un mensaje, de manera que el mensaje continúe siendo confidencial hasta que sea decodificado por el receptor con la llave privada. En el segundo caso, el emisor encripta un mensaje usando la llave privada, una llave a la cual sólo tiene acceso el emisor.


GnuPG

La llave pública del receptor asegura la confidencialidad; la llave privada del emisor verifica la identidad del emisor.

Generar un nuevo par de claves

Para generar un par de claves, debe asegurarse de tener instalado el paquete pinentry.

# yum install pinentry

Además deberá asegurarse de que su usuario es el propietario del tty en el cual se encuentra trabajando:

# ls -la $(tty)

Si no es el propietario del tty, probablemente ha realizado su al usuario, deberá salir de esa sesión e iniciar una nueva desde una terminal virtual o realizando ssh usuario@localhost.

Para generar un par de claves, utilice el comando gpg con la opción --gen-key.

$ gpg --gen-keygpg (GnuPG) 2.0.14; Copyright (C) 2009 Free Software Foundation, Inc.This is free software: you are free to change and redistribute it.There is NO WARRANTY, to the extent permitted by law.

Por favor seleccione tipo de clave deseado: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sólo firmar) (4) RSA (sólo firmar)Su elección:

GnuPG es capaz de crear varios tipos diferentes de pares de claves, pero debe existir una clave primaria capaz de generar firmas. Por lo tanto, existen cuatro opciones.

La opción 1 genera dos pares de claves. Un par de claves RSA que es el par de claves primario que se usará sólo para firmar. Un par de claves subordinadas RSA que se usará para el cifrado.

La opción 1 genera dos pares de claves. Un par de claves DSA que es el par de claves primario que se usará sólo para firmar. Un par de claves subordinadas Elgamal que se usará para el cifrado.

La opción 3 sólo genera un par de claves DSA que puede utilizarse únicamente para


GnuPG

firmar.

La opción 4 sólo genera un par de claves RSA que puede utilizarse únicamente para firmar.

La mayoría de los usuarios tienen suficiente con la opción por defecto (1).

Luego es necesario seleccionar un tamaño para la clave.

las claves RSA pueden tener entre 1024 y 4096 bits de longitud.¿De qué tamaño quiere la clave? (2048)

Cuanto más larga sea la clave, más segura será contra ataques de fuerza bruta” e intentos de descifrado. Sin embargo, el cifrado y descifrado de mensajes tiene mejor rendimiento a medida que se incrementa el tamaño de la clave. Una vez seleccionado, el tamaño de una clave no se puede cambiar nunca.

Para terminar, hay que escoger un fecha de caducidad. Si se escogió anteriormente la opción 1, la fecha de caducidad se usará para ambos pares de claves.

Por favor, especifique el período de validez de la clave. 0 = la clave nunca caduca <n> = la clave caduca en n días <n>w = la clave caduca en n semanas <n>m = la clave caduca en n meses <n>y = la clave caduca en n años¿Validez de la clave (0)?La clave nunca caduca¿Es correcto? (s/n) s

Para la mayoría de los usuarios, una clave sin fecha de caducidad es la adecuada. Sin embargo, si se escoge con fecha de caducidad, el tiempo para ésta debe ser escogido con cuidado, ya que, aunque es posible cambiar la fecha de caducidad posteriormente a la generación de la clave, puede ser difícil comunicar un cambio a aquellos usuarios que posean esta clave pública.

Además de los parámetros de la clave, el usuario debe dar un identificador. El identificador de usuario se usa para asociar la clave que se está creando con una usuario real.

GnuPG debe construir un ID de usuario para identificar su clave.

Nombre y apellidos: Juan PerezDirección de correo electrónico: [email protected]:Ha seleccionado este ID de usuario: "Juan Perez <[email protected]>"

¿Cambia (N)ombre, (C)omentario, (D)irección o (V)ale/(S)alir? V


GnuPG

Sólo se creará un identificador de usuario al generar una clave, pero es posible crear identificadores adicionales si se desea usar la clave en dos o más contextos, por ejemplo, si se usa por una parte en la oficina como empleado y por otra parte en casa como activista político. Hay que tener cuidado al crear un identificador de usuario, ya que después éste no puede ser editado para introducir cambios.

GnuPG necesita una frase clave con el fin de proteger las claves privadas, primarias y secundarias, que posea el usuario.

┌───────────────────────────────────────────────────────────┐ │ Introduzca frase contraseña │ │ │ │ │ │ Frase contraseña ________________________________________ │ │ │ │ <OK> <Cancel> │ └───────────────────────────────────────────────────────────┘

No hay límite para la longitud de una contraseña, y ésta debe ser escogida con sumo cuidado. Desde un punto de vista de seguridad, la contraseña que desbloquea la clave privada es uno de los puntos más débiles en GnuPG (y en otros sistemas de cifrado de clave pública), ya que es la única protección que tiene el usuario si alguien se apoderara de su clave privada. Para una contraseña lo ideal es que no se usen palabras de un diccionario, y que se mezclen mayúsculas y minúsculas, dígitos, y otros caracteres.

Reicibirá un mensaje indicando que deberá realizar actividad con el equipo para generar entropía:

Es necesario generar muchos bytes aleatorios. Es una buena idea realizaralguna otra tarea (trabajar en otra ventana/consola, mover el ratón, usarla red y los discos) durante la generación de números primos. Esto da algenerador de números aleatorios mayor oportunidad de recoger suficienteentropía.

En este momento, puede presionar aleatoriamente las teclas de su teclado.

Generar un certificado de revocación

Después de haber generado un par de claves, el usuario debe, de forma inmediata, generar un certificado de revocación para la clave pública primaria, mediante el uso de la opción --gen-revoke. Si el usuario olvidara la contraseña, o si su clave privada estuviera en peligro o extraviada, este certificado de revocación podría ser hecho público para notificar a otros usuarios que la clave pública no debe ser usada nunca más. Una clave pública revocada puede ser usada para verificar firmas hechas por el usuario en el pasado, pero no puede ser usada para cifrar datos. Esto tampoco afecta a la capacidad de descifrar mensajes que hayan sido cifrados con la


GnuPG

clave antes de su revocación, siempre y cuando el usuario todavía tenga acceso a la clave privada.

$ gpg --output jperez_gpg_revoke.gpg --gen-revoke [email protected]

sec 2048R/4A67F73D 2012-05-04 Juan Perez <[email protected]>

¿Crear un certificado de revocación para esta clave? (s/N) sPor favor elija una razón para la revocación: 0 = No se dio ninguna razón 1 = La clave ha sido comprometida 2 = La clave ha sido reemplazada. 3 = La clave ya no está en uso Q = Cancelar(Probablemente quería seleccionar 1 aquí)¿Su decisión? 3Introduzca una descripción opcional; acábela con una línea vacía:>Razón para la revocación: La clave ya no está en uso(No se dió descripción)¿Es correcto? (s/N) s

Necesita una frase contraseña para desbloquear la clave secretadel usuario: "Juan Perez <[email protected]>"clave RSA de 2048 bits, ID 4A67F73D, creada el 2012-05-04

Certificado de revocación creado.

Por favor consérvelo en un medio que pueda esconder; si alguien consigueacceso a este certificado puede usarlo para inutilizar su clave.Es inteligente imprimir este certificado y guardarlo en otro lugar, porsi acaso su medio resulta imposible de leer. Pero precaución: ¡el sistemade impresión de su máquina podría almacenar los datos y hacerlos accesiblesa otras personas!

Intercambiar claves

Para poder comunicarse con otros, el usuario debe intercambiar las claves públicas. Para obtener una lista de las claves en el fichero (anillo) de claves públicas, se puede usar la opción de la línea de órdenes -list-keys.

$ gpg -list-keys

Exportar una clave pública

Para poder enviar una clave pública a un interlocutor, antes hay que exportarla. Para ello se usará la opción de la línea de órdenes --export. Es necesario un argumento adicional para poder identificar la clave pública que se va a exportar.


GnuPG

Como en la opción anterior --gen-revoke, hay que usar el identificador de clave o cualquier parte del identificador de usuario para identificar la clave que se desea exportar.

Por defecto, la clave se exporta en formato binario, y esto puede no ser conveniente cuando se envía la clave por correo electrónico o se publica en una página web. Por tanto, GnuPG ofrece una opción de la línea de órdenes --armor que fuerza que la salida de la orden sea generada en formato armadura-ASCII, parecido a los documentos codificados con uuencode. Por regla general, cualquier salida de una orden de GnuPG, v.g.. claves, documentos cifrados y firmas, pueden ir en formato armadura-ASCII añadiendo a la orden la opción -armor.

$ gpg --output jperez_pub.gpg --armor --export [email protected] -–sign-key

Importar una clave pública

Se puede añadir una clave pública al anillo de claves públicas mediante la opción --import.

$ gpg --import plopez.gpg

Una vez que la clave haya sido importada, es necesario validarla. GnuPG usa un potente y flexible modelo de confianza que no requiere que el usuario dé validez personalmente a cada clave que importe. Sin embargo, algunas claves pueden necesitar que el usuario les dé validez de forma personal. Una clave se valida verificando la huella digital de la clave, y firmando dicha clave para certificar su validez. La huella digital se puede ver con la opción de la línea de órdenes --fingerprint, pero para certificar la clave hay que editarla.

$ gpg --fingerprint [email protected]

La huella digital de una clave se verifica con el propietario de la clave. Esto puede hacerse en persona o por teléfono, o por medio de otras maneras, siempre y cuando el usuario pueda garantizar que la persona con la que se está comunicando sea el auténtico propietario de la clave. Si la huella digital que se obtiene por medio del propietario es la misma que la que se obtiene de la clave, entonces se puede estar seguro de que se está en posesión de una copia correcta de la clave.

Después de comprobar la huella digital ya se puede firmar la clave con el fin de validarla. Debido a que la verificación es un punto débil en criptografía de clave pública, es aconsejable ser cuidadoso en extremo y siempre comprobar la huella digital de una clave con la que nos dé el propietario antes de firmar dicha clave.

$ gpg --sign-key [email protected]

Una vez firmada, el usuario puede comprobar la clave para obtener un listado de las firmas que lleva con la opción --check-sigs. Cada identificador de usuario tendrá una o más autofirmas, así como una firma por cada usuario que haya validado la


GnuPG

clave en cuestión.

$ gpg --check-sigs

Cifrar y descifrar documentos

Cada clave pública y privada tiene un papel específico en el cifrado y descifrado de documentos. Se puede pensar en una clave pública como en una caja fuerte de seguridad. Cuando un remitente cifra un documento usando una clave pública, ese documento se pone en la caja fuerte, la caja se cierra, y el bloqueo de la combinación de ésta se gira varias veces. La parte correspondiente a la clave privada, esto es, el destinatario, es la combinación que puede volver a abrir la caja y retirar el documento. Dicho de otro modo, sólo la persona que posee la clave privada puede recuperar un documento cifrado usando la clave pública asociada al cifrado.

Con este modelo mental se ha mostrado el procedimiento de cifrar y descifrar documentos de un modo muy simple. Si el usuario quisiera cifrar un mensaje para Javier, lo haría usando la clave pública de Javier, y él lo descifraría con su propia clave privada. Si Javier quisiera enviar un mensaje al usuario, lo haría con la clave pública del usuario, y éste lo descifraría con su propia clave privada.

Para cifrar un documento se usa la opción -encrypt (-e). El usuario debe tener las claves públicas de los pretendidos destinatarios. El programa espera recibir como entrada el nombre del documento que se desea cifrar o, si éste se omite, una entrada típica. El resultado cifrado se coloca en la salida típica o donde se haya especificado mediante la opción -output (-o). El documento se comprime como medida adicional de seguridad, aparte de cifrarlo. La opción -recipient (-r) se usa una vez para cada destinatario, y lleva un argumento extra que especifica la clave pública con la que será cifrado el documento. El documento cifrado sólo puede ser descifrado por alguien con una clave privada que complemente uno de las claves públicas de los destinatarios. El usuario, en este caso el remitente, no podrá descifrar un documento cifrado por sí mismo a menos que haya incluido su propia clave pública en la lista de destinatarios.

$ gpg -e -o mensaje_privado.gpg -r [email protected] mensaje_privado.txt

Para descifrar un mensaje se usa la opción --decrypt (-d). Para ello es necesario poseer la clave privada para la que el mensaje ha sido cifrado. De igual modo que en el proceso de cifrado, el documento a descifrar es la entrada, y el resultado descifrado la salida.

$ gpg -o mensaje_privado.txt -d mensaje_privado.gpg

Firmar y verificar firmas

Una firma digital certifica un documento y le añade una marca de tiempo. Si


GnuPG

posteriormente el documento fuera modificado en cualquier modo, el intento de verificar la firma fallaría. La utilidad de una firma digital es la misma que la de una firma escrita a mano, sólo que la digital tiene una resistencia a la falsificación. Por ejemplo, la distribución del código fuente de GnuPG viene firmada con el fin de que los usuarios puedan verificar que no ha habido ninguna manipulación o modificación al código fuente desde que fue archivado. Para la creación y verificación de firmas, se utiliza el par público y privado de claves en una operación que es diferente a la de cifrado y descifrado. Se genera una firma con la clave privada del firmante. La firma se verifica por medio de la clave pública correspondiente.

La opción de línea de órdenes --sign (-s) se usa para generar una firma digital. El documento que se desea firmar es la entrada, y la salida es el documento firmado.

$ gpg -o mensaje_firmado.sig --sign mensaje.txt

El documento se comprime antes de ser firmado, y la salida es en formato binario.

Con un documento con firma digital el usuario puede llevar a cabo dos acciones: comprobar sólo la firma o comprobar la firma y recuperar el documento original al mismo tiempo. Para comprobar la firma se usa la opción -verify. Para verificar la firma y extraer el documento se usa la opción -decrypt. El documento con la firma es la entrada, y el documento original recuperado es la salida.

$ gpg --output mensaje.txt --decrypt mensaje_firmado.sig

Documentos con firmas ASCII

Las firmas digitales suelen usarse a menudo para firmar mensajes de correo electrónicos o en los grupos de noticias. En estas situaciones no se debe comprimir el documento al firmarlo, ya que para aquellos que no dispongan de un sistema para procesarlo sería ininteligible.

$ gpg -o mensaje_firmado.txt --clearsign mensaje.txt

Firmas acompañantes

Un documento firmado tiene una utilidad limitada. Los otros usuarios deben recuperar la versión original del documento de la versión firmada, y aun en el caso de los documento firmados en ASCII, el documento firmado debe ser editado para poder recuperar el original. Por tanto, existe un tercer método para firmar un documento, que genera una firma acompañante. Para generar una firma acompañante se usa la opción -detach-sig.

$ gpg -o firma_mensaje.sig --detach-sig mensaje.txt

Tanto el documento como la firma acompañante son necesarios para poder verificar la firma. La opción -verify se usará para comprobar la firma.


GnuPG

$ gpg -verify firma_mensaje.sig mensaje.txt

Incorporación de gpg al cliente de correo electrónico

Entre los clientes de correo electrónico más populares se encuentran Mozilla Thunderbird y Evolution. Es posible utilizar gpg desde estas aplicaciones para firmar y encriptar mensajes de correo electrónico.

Incorporando gpg a Mozilla Thunderbird

Enigmail es una extensión del cliente Mozilla Thunderbird el cual permite a los usuarios acceder a las características de autenticación y encriptación proporcionadas por GnuPG. Enignail puede ser obtenido de:

http://enigmail.mozdev.org/

Con Enigmail es posible:

● Encriptar/desencriptar/firmar/autenticar mensajes de correo

● Selección automática de la clave del recipiente

● Interfaz de administración de claves

Una vez descargada la extensión de Thunderbird, se instalada desde el desde el gestor de extensiones de Thunderbird : Herramientas/Extensiones/Instalar. Al reiniciar Thunderbird, aparecerá una nueva pestaña en la barra de herramientas (openPGP). La extensión puede ser traducida instalando el paquete de lenguaje y puede ser obtenido de:

http://enigmail.mozdev.org/langpack.html

La instalación se realiza también desde el gestor de extensiones de Thunderbird.

Se debe realizar la configuración inicial de Enigmail indicando la ruta al programa gpg seleccionando OpenGPG/Preferencias, completando el cuadro de texto “Ruta al ejecutable...”


GnuPG

Opcionalmente, si aún no ha creado un par de claves puede hacerlo desde el menú OpenGPG/Administración de claves.

Finalmente se debe activar el servicio, en el menú Editar/Configuración de las cuentas.../Seguridad OpenGPG y marcar la casilla de verificación Activar el soporte OpenPGP (Enigmail) para esta identidad.


GnuPG

Una vez activado Enigmail, puede componer mensajes, firmarlos y encriptarlos al ser enviados.


GnuPG

Incorporando gpg a Evolution

Configurar Evolution para usar GPG es simple, en el menú de Evolution, seleccione Editar/Preferencias/Cuentas de correo. Seleccione su cuenta y haga clic en el botón Editar y seleccione la pestaña Seguridad.


GnuPG

Introduzca el ID de su clave gpg, el ID puede ser obtenido ejecutando el comando gpg –list-keys. Si desea firmar digitalmente todos los mensajes salientes, marque la primera casilla.

La selección de la tercera casilla de verificación encripta la copia del mensaje en la carpeta Enviados. Esto es útil si su casilla de correos no es tan segura como debería ser.

La cuarta casilla de verificación debería permanecer desmarcada debido a que se contradice con el propósito de firmar claves públicas. Claro, si confía en cada clave que ingresa al anillo gpg, puede seleccionar esta opción y no molestarse en firmar ninguna clave.

Seleccione Aceptar para utilizar GPG.

Para enviar un mensaje firmado y encriptado, en la ventana de composición del mensaje, seleccione Seguridad/Firmar con GPG y Seguridad/Encriptar con GPG.


8Recuperación ante desastres

Recuperación ante desastres

Introducción

Cuando se habla de seguridad informática lo primero en lo que se suele pensar es en firewalls, exploits, parches… Esta claro que la seguridad informática cubre todos esos campos pero también se centra en otros aspectos como son las copias de seguridad y los planes de recuperación ante desastres.

Cualquier organización que dependa de sistemas informáticos para sus operaciones diarias debería tener preparado un plan que le permita volver a poner su sistema informático en marcha en el menor tiempo posible en caso de destrucción total. Es un plan completamente distinto al de disponibilidad (el tiempo que un sistema informático esta disponible) o al de continuidad (recuperación de una parte muy concreta del sistema). Los planes de recuperación ante desastres no pretenden mantener el sistema funcionando al 100%, 24 horas al día, 7 días a la semana, si no que intentan especificar el reemplazo del sistema si hubiera que crearlo de nuevo partiendo de cero.

Existen al menos 5 puntos a tener en cuenta en el plan de recuperación ante desastres:

1. Mantener diagramas actualizados de la configuración física y lógica del sistema informático.

2. Mantener listados actualizados de todos los dispositivos que conforman el sistema, su localización y su función.

3. Mantener una copia de todo el software que podamos necesitar para reinstalar el sistema.

4. Implementar sistemas RAID para evitar la perdida información y aumentar la disponibilidad de los sistemas que almacenan dicha información.

5. Hacer copias de seguridad con frecuencia de toda la información y almacenarla en lugar seguro y a ser posible en otro lugar físico al que se encuentra el sistema.

La herramienta de reporte del sistema cfg2html

Obtener información completa y detallada del hardware y software de un servidor Linux podría ser un proceso que lleva mucho tiempo. Sin embargo, existe la herramienta cfg2html la cual obtiene una multitud de datos y genera una página html con toda la información recolectada. La herramienta cfg2html puede ser obtenida de:

http://www.cfg2html.com/



Instalación y configuración de cfg2html

Una vez descargado el paquete de instalación, ejecute el comando rpm para instalarlo:

# rpm -Uvh cfg2html-linux-<version>.rpmEdite el archivo /etc/cfg2html/systeminfo y configure las variables:

Host: mercurio.linux.com.pyDescripcion: Servidor de base de datos de producciónCompañia: Linux ParaguayUbicacion: Sala de servidores, sector 3Contacto: Sistemas ([email protected])Base de datos: OracleURL: http://www.linux.com.py

Puede indicar archivos adicionales que deben incluirse en el reporte editando el archivo /etc/cfg2html/files, por ejemplo, para incluir en el reporte los archivo /etc/sysconfig/clock, /etc/ldap.conf, /etc/openldap/ldap.conf y /etc/pam.d/system-auth agregue la siguiente línea:

FILES="/etc/sysconfig/clock /etc/ldap.conf /etc/ldap/ldap.conf"

Ejecución de cfg2html

Para colectar información del sistema, simplemente debe indicar al comando el directorio donde depositar el archivo con la información del sistema, por ejemplo:

# mkdir /root/systeminfo# cfg2html -o /root/systeminfo

El programa creará un archivo HTML y un archivo TXT con la configuración del sistema llamado nombre-host.html y nombre-host.txt respectivamente.

Mondo Rescue

Mondo Rescue respalda el sistema a CD, cinta, NFS o archivos ISO. Mondo utiliza afio como el motor de copia de respaldo. En el evento de una pérdida de datos catastrófica, puede restaurar todo el sistema inclusive si los discos están totalmente en blanco.

Mondo no es un programa de respaldo para todos los días. No es un reemplazo de star, tar, afio, cpio, etc. Mondo está diseñado para hacer posible recuperar el sistema desde la nada.

Mondo Rescue puede ser obtenido de:



http://www.mondorescue.org

Mondo Rescue requiere de:

● afio: La herramienta de empaquetado de archivos

● gzip: El compresor utilizado por Mondo Rescue

● mkisofs: La herramienta para crear imagenes ISO

● mindi-busybox: Todos los comandos requeridos por mindi

● mindi: El constructor de la mini-distribución del proyecto

● mondo: La herramienta de recuperación de desastres

Mindi

Mindi Linux crea un conjunto de imágenes de discos de inicio/raíz que permite realizar un mantenimiento básico del sistema. La principal virtud de los discos de inicio Mindi es el hecho que contiene el kernel, los módulos, herramientas y bibliotecas del propio sistema.

Mindi se asegura que Mondo tenga todas las herramientas que necesita al momento de arranque.

Instalación de Mondo

Una vez descargado los paquetes mindi, mondo y sus dependencias, ejecute el siguiente comando:

# rpm -Uvh *.rpm

Respaldando datos con Mondo

Antes de iniciar la copia de seguridad, debe modificar el archivo /usr/sbin/mindi y configurar el tamaño máximo del disco RAM, de lo contrario tendrá problemas durante el inicio del CD creado. Para ello, edite el archivo /usr/sbin/mindi y agregue a las opciones de arranque indicadas en ADDITIONAL_BOOT_PARAMS:

ramdisk_blocksize=1024

Para iniciar la copia de seguridad del sistema, ejecute como root el siguiente comando:

# /usr/sbin/mondoarchive



Seleccione una opción de la lista de medios de respaldo soportados. Si desea realizar una copia de seguridad o restaurar a través de la red utilice NFS. Si desea realizar una copia de respaldo o restaurar desde una partición local o si desea almacenar imágenes ISO en un directorio local para grabarlos posteriormente, seleccione “hard disk”. Si seleccione CD/DVD+-R[W] o tape en general el hardware será detectado y configurado automáticamente.

Seleccione el grado de compresión que desea. Si su dispositivo de cinta realiza compresión por hardware, seleccione None. Seleccione Maximum si tiene una CPU muy rápida, Average debería ser apropiado para la mayoría de las situaciones.



Si desea respaldar todo el equipo, utilice la opción por defecto /. De lo contrario, especifique un conjunto de directorios a respaldar separados por un espacio.

Si desea excluir ciertos directorios, especifique la lista de directorios a ser excluidos separados por un espacio.



El programa solicita confirmación de si el kernel es estándar, los usuarios de Red Hat debe seleccionar “yes” debido a que el proveedor produce kernels confiables.

Si esta seguro de continuar, seleccione “yes” para iniciar la copia de seguridad en la ventana de confirmación.



Mondo llama a Mindo, que genera imágenes de discos iniciables e imágenes de discos auxiliares basados en su distribución y sistema de archivos existente.

Finalmente, Mondo inicia la copia de seguridad de los datos. Este proceso puede llevar mucho tiempo dependiendo de la cantidad de información a respaldar, la velocidad de la CPU y la cantidad de memoria.

Una vez finalizada la copia de seguridad, se solicitará que se creen los discos de arranque. Los discos de arranque no son necesarios si realiza copia de seguridad a CD/DVD, pero son necesarios si respalda a cinta o NFS.

Restaurando datos con Mondo

Si por algún motivo no puede iniciar desde el CD/DVD generado, el primer CD/DVD de backup contiene un conjunto de imágenes de disquete que le proporciona la misma funcionalidad que el CD.

Es posible seleccionar los siguientes modo de restauración:

● Interactive – Restauración Interactiva, permite restaurar paso a paso el sistema o un subconjunto de archivos.

● Nuke – Destruye los distos del disco y restaura todo el sistema, de forma automática y desatendida.

● Expert – Modo experto, inicia un shell.

Una de las cosas lindas de Mondo es que permite borrar el sistema actual y restaurarlo bajo una configuración de disco diferente. Puede restaurar de no RAID a RAID, modificar el tamaño de los sistemas de archivos, migrar de sistema de archivos, etc.

Para diagnóstico y solución de problemas, visite las páginas de documentación mondo rescue:

● http://trac.mondorescue.org/wiki/FAQ

● http://www.mondorescue.org/docs.shtml

● http://sourceforge.net/mailarchive/forum.php?forum_name=mondo-devel


9Security Enhanced Linux

Security Enhanced Linux

Introducción

Security-Enhanced Linux o SELinux, es una arquitectura de seguridad integrada en el kernel 2.6.x usando los módulos de seguridad linux (o linux security modules, LSM). Este es un proyecto de la Agencia de Seguridad Nacional (NSA) de los Estados Unidos y de la comunidad SELinux. La integración de SELinux en Red Hat Enterprise Linux fue un esfuerzo conjunto entre al NSA y Red Hat.

SELinux proporciona un sistema flexible de control de acceso obligatorio (mandatory access control, MAC) incorporado en el kernel. Bajo el Linux estándar se utiliza el control de acceso a discreción (discretionary access control, DAC), en el que un proceso o aplicación ejecutándose como un usuario (UID o SUID) tiene los permisos y de ese usuario en los objetos, archivos, sockets y otros procesos. Al ejecutar un kernel SELinux MAC se protege al sistema de aplicaciones maliciosas o dañadas que pueden perjudicar o destruir el sistema. SELinux define el acceso y los derechos de transición de cada usuario, aplicación, proceso y archivo en el sistema. SELinux gobierna la interacción de estos sujetos y objectos usando una política de seguridad que especifica cuán estricta o indulgente una instalación de Red Hat Enterprise Linux dada debería de ser.

Cuando un sujeto, tal como una aplicación, intenta acceder a un objeto tal como a un archivo, el servidor de aplicación de políticas verifica un caché de vector de acceso (AVC), donde se registran los permisos de objeto y del sujeto. Si no se puede tomar una decisión basado en los datos en el AVC, la petición continua al servidor de seguridad, el cual busca el contexto de seguridad de la aplicación y del archivo en una matriz. Los permisos son entonces otorgados o negados, con un mensaje de avc: denied detallado en /var/log/messages. Los sujetos y objetos reciben su contexto de seguridad a partir de la política instalada, que también proporciona información para llenar la matriz de seguridad del servidor. Esta arquitectura es conocida como Flask Security Architecture.



Además de ejecutarse en un modo impositivo, SELinux puede ejecutarse en un modo permisivo, donde el AVC es verificado y se registran los rechazos, pero SELinux no hace cumplir esta política.

En una máquina no SELinux, cada proceso que se ejecuta como root puede acceder al archivo /etc/shadow. Esto quiere decir que cualquier problema de seguridad con un binario que tiene SETUID root o demonio de red que se ejecuta como root puede ser catastrófico. SELinux permite restringir a los demonios y permitir el acceso solamente a los archivos que necesitan, por ejemplo, BIND solamente puede leer sus archivos de configuración y proporcionar servicios en el puerto 53, pero no puede acceder al /etc/shadow, /home, /root o cualquier otro recurso significante ni proporcionar servicios en otro puerto de red. De tal forma que en un sistema SELinux, si BIND fue explotado, lo peor que puede realizar es enviar paquetes DNS falsos, esto es mucho mejor que un control remoto como root.

La implementación de SELinux utiliza control de acceso basado en rol (role-based access control – RBAC), el cual proporciona control basado en roles y Aplicación de Tipo (Type enforcement – TE). TE utiliza la matriz para manejar el control de acceso, aplicando las reglas de las políticas basados en los tipos de los procesos y objetos.



Contextos de seguridad

Todo el control de acceso del sistema operativo está basado en un atributo de control de acceso asociado con los objetos y sujetos. En SELinux, el atributo de control de acceso es llamado contexto de seguridad o security context. Todos los objetos (dispositivo, archivos, sockets) y sujetos (procesos) tienen un único contexto de seguridad asociado a ellos. Un contexto de seguridad se compone de tres elementos, un usuario (user), rol (role) e identificadores de tipo (type identifiers). El formato normal para especificar o mostrar un contexto de seguridad es el siguiente:

user:role:type:level (usuario:rol:tipo:nivel)El valor de cada elemento está definido en el lenguaje de política de SELinux.

En SELinux, el identificador de tipo (type) es la parte primaria del contexto de seguridad que determina el acceso.

El nivel es un atributo de Multi-Level Security. Multi-Level Security no es utilizado por la política targeted.

Por razones históricas, el tipo de un proceso es normalmente denominado dominio. En general, considere dominio, tipo de dominio, tipo de sujeto y tipo de proceso sinónimos.

Examinando los contextos de seguridad

SELinux modifica los comandos del sistema agregando la opción -Z para mostrar el contexto de seguridad para objetos y sujetos. Por ejemplo:

# ls -Z

Muestra el contexto de seguridad de objetos del sistema de archivos y el comando:

# ps -Z

Muestra el contexto de seguridad de los procesos.

Otro comando útil es id, el cual muestra el contexto de seguridad de su shell, esto es, el usuario actual, el papel y el tipo. Por ejemplo:

# id -Zuser_u:system_r:unconfined_t

Modelo de seguridad basado en dominios

En un modelo de seguridad basado en dominios, cada proceso se ejecuta en un dominio de seguridad, y cada recurso (archivo, directorio, socket, etc) tiene un tipo



asociado a él. Existen una serie de reglas que listan las acciones que cada dominio puede realizar sobre cada tipo. Una ventaja del modelo de dominios es que la política puede ser analizada por medio de herramientas de análisis de políticas SELinux para determinar que flujo de información es posible.

Control de acceso TE

En SELinux, todo acceso debe ser explícitamente otorgado. La forma en la que el acceso es permitido, es otorgando a un tipo de sujeto (dominio) acceso a un tipo de objeto usando una regla allow. Una regla allow tiene cuatro elementos:

● Tipo(s) origen: Normalmente el tipo de dominio de un proceso

● Tipo(s) destino: El tipo de un objeto siendo accedido por el proceso

● Clase(s) de Objeto: La clase de objeto a la que el acceso especificado es permitido

● Permiso(s): El tipo de acceso que es permitido al tipo origen hacia el tipo destino para la clase de objeto indicada.

Por ejemplo, considere la siguiente regla:

allow unconfined_t bin_t : file { read execute getattr };

El ejemplo muestra la sintaxis básica de una relgla allow TE. Esta regla tiene dos identificadores de tipo: el tipo origen (sujeto o dominio) unconfined_t; y el tipo destino (objeto) bin_t. El identificador file es el nombre de una clase de objeto definida en la política, en este caso representando un archivo cualquiera. Los permisos encontrados entre las llaves son un conjunto de permisos válidos para una instancia de la clase de objeto. La traducción de esta regla sería como sigue:

Un proceso cuyo tipo de dominio es unconfined_t puede leer, ejecutar y obtener atributos de un archivo cuyo tipo es bin_t.

Asumiendo que unconfined_t es el tipo de dominio de un proceso común no privilegiado como el shell y bin_t es el tipo asociado con archivos ejecutables que los usuarios ejecutan con privilegios normales, como /bin/vi, la regla puede estar en la política para permitir a los usuarios ejecutar el comando vi.

Ejemplo de TE

Para explorar un poco mas las reglas TE, utilizaremos el ejemplo del programa passwd. En Linux, el programa passwd debe leer y modificar el archivo /etc/shadow donde se almacenan las contraseñas. Este comando implementa su propia seguridad interna que permite a los usuarios cambiar su propia contraseña y a



root permite cambiar cualquier contraseña. En Linux, el archivo /etc/shadow tiene permiso de lectura solamente para el usuario root, los usuarios pueden cambiar sus contraseñas debido a que el programa tiene el bit SETUID activado, de tal forma que cuando se ejecuta por cualquier usuario, se ejecuta bajo el usuario root (el propietario del programa passwd).

Esto significa que cualquier programa que se ejecuta como root tiene la posibilidad de modificar el archivo shadow. Lo que permite TE es asegurar que solamente el programa passwd (o programas confiables similares) puedan acceder al archivo shadow, sin importar que usuario ejecuta el programa.

Observe el contexto de seguridad del archivo /etc/shadow:

# ls -laZ /etc/shadow-r-------- root root system_u:object_r:shadow_t /etc/shadow

El contexto de seguridad del archivo /etc/shadow indica que está asociado al tipo shadow_t. Por ahora puede ignorar los elementos usuarios y rol.

Igualmente, examinando un proceso ejecutando el programa passwd bajo la política SELinux (strict):

# ps -aZ |grep passwduser_u:user_r:passwd_t 2305 pts/1 00:00:00 passwd

Como podrá observar en el resultado del comando, el programa passwd se ejecuta en el tipo de dominio passwd_t.

Examine la siguiente regla allow:

allow passwd_t shadow_t : file { ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename };

El propósito de la regla es permitir al tipo de dominio del programa passwd (passwd_t) el acceso necesario al tipo del archivo shadow (shadow_t) para mover y crear un nuevo archivo shadow.

Transición de dominios

Si todo lo que se debiera hacer es proporcionar acceso de sujetos (procesos) a objetos tales como archivos, escribir una política TE sería simple. Sin embargo, se debe considerar una forma de ejecutar los programas con el tipo de dominio correcto. Por ejemplo, no es deseable que programas que no se confían accedan el archivo shadow o de alguna manera ejecutarse dentro del tipo de dominio passwd_t. Este problema conlleva a las transiciones de dominios.

Por ejemplo, considere el ejemplo anterior del programa passwd y el archivo



shadow. En un sistema típico un usuario, por ejemplo jperez, inicia sesión y obtiene un shell, por ejemplo bash. Bajo la política estricta de SELinux (strict) el shell del usuario se ejecutará bajo el dominio user_t. Como jperez puede ejecutar otros programas desde el shell, el tipo de dominio de cualquier nuevo proceso creado por el usuario mantendrán el tipo user_t a menos que se tome una acción. Si esto es así, cómo jperez cambia su contraseña?

No se desea que el dominio no confiable user_t del usuario jperez tenga la posibilidad de leer y escribir al archivo shadow directamente debido a que esto permitiría a cualquier programa ver y cambiar el contenido del archivo. Como se discutió previamente, se desea que solamente el archivo passwd tenga acceso sobre el archivo shadow. Entonces, la pregunta es cómo proporcionar una forma segura y discreta de transicionar desde el shell del usuario jperez el cual se ejecuta en el dominio user_t a un proceso ejecutando el programa passwd con el tipo de dominio passwd_t?.

Como previamente se mostró, la regla allow aseguraría que el proceso passwd de tipo de dominio passwd_t pueda acceder el archivo shadow del tipo (shadow_t). Ahora es necesario encontrar una forma de conseguir la transición de dominio.

Examine el contexto de seguridad del programa passwd:

# ls -Z /usr/bin/passwd-rwsr-xr-x root root system_u:object_r:passwd_exec_t /usr/bin/passwd

El programa /usr/bin/passwd pertenece al tipo passwd_exec_t.

Para lograr la transición de dominio, se necesitan reglas TE adicionales.

allow user_t passwd_exec_t : file { getattr execute };allow passwd_t passwd_exec_t : file entrypoint;allow unconfined_t passwd_t : process transition;

La primera regla permite al shell de jperez (user_t) ejecute el programa passwd que pertenece al tipo de dominio passwd_exec_t.

La segunda regla proporciona un punto de entrada (entrypoint) al dominio passwd_t. El permiso entrypoint define qué archivos ejecutables (programas) pueden entrar en un dominio. Para una transición de dominio, el nuevo dominio al cual se entra (en este caso passwd_t) debe tener una regla de acceso entrypoint que permita al archivo ejecutable transicionar al nuevo dominio.

En este caso, asumiendo que solamente en el archivo passwd está etiquetado con passwd_exec_t, y que solamente el tipo passwd_t tiene un punto de acceso (entrypoint) para passwd_exec_t, tenemos una situación en la cual solamente el programa passwd puede ejecutarse en el dominio passwd_t.



En la última regla, la clase de objeto es process, significando que la clase de objeto representa procesos. Esta regla permite el acceso transition. Este permiso es necesario para permitir a un tipo de dominio de un proceso cambiar el contexto de seguridad. El tipo original (user_t) debe tener el permiso de transición al nuevo tipo (passwd_t) para que se permita la transición de dominio.

Cuando las tres reglas son permitidas por la política TE, una transición de dominio puede ocurrir.

Ahora, el problema es cómo jperez indica que desea realizar una transición de dominio. Las reglas anteriores permiten la transición de dominio, pero no lo requieren. En general, no se desea que los usuarios realicen la transición de dominio explícitamente. Se necesita una forma para que la transición de dominio ocurra por defecto.

Transición de dominio por defecto

Para permitir que la transición de dominios ocurra por defecto, necesitamos una nueva regla, la regla type_transition. Esta regla permite indicar en la política SELinux transiciones por defecto que deberían ser intentadas si una transición explícita no se ha solicitado. Una regla de transición podría ser:

type_transition user_t passwd_exec_t : process passwd_t;

Esta regla provoca que se intente una transición de dominio por defecto, indicando que cuando un archivo ejecutable del tipo passwd_exec_t es ejecutado por un proceso en el tipo de dominio user_t, se intente una transición por defecto al dominio passwd_t. Esta regla intenta una transición por defecto pero no la permite.

La función de los roles

SELinux proporciona una forma de control de acceso basado en roles (RBAC). Los roles limitan los tipos a los cuales un proceso puede transicionar basándose en el identificador de rol del contexto de seguridad de un proceso. De esta forma, una política puede tener un rol que permita transicionar a un conjunto de tipos de dominios, definiendo así los límites del rol.

Aún cuando las reglas TE permitan que el programa passwd se ejecute por el tipo de dominio user_t e ingrese al nuevo dominio passwd_t, al rol de jperez debe asociarse al nuevo dominio para que la transición ocurra. Una regla de rol sería como la siguiente:

role user_r type passwd_t;Esta declaración role define el rol user_t y asocia el tipo passwd_t al rol. Esta asociación indica que el tipo passwd_t puede coexistir en el contexto de seguridad



con el rol user_r. Sin este rol, el nuevo contexto user_u:user_r:passwd_t no podría ser creado.

Una política puede definir roles aún más restringidos para usuarios específicos. Por ejemplo, imagine una política que crea un rol llamado restricted_user_r, idéntico a user_r excepto que no está asociado con el tipo passwd_t. Si el rol de jperez es restricted_user_r en lugar de user_r, jperez no estaría autorizado a ejecutar el programa passwd aún cuando las reglas TE permitan a su tipo de dominio el acceso.

El rol por defecto al cual pertenece un usuario está establecido en el archivo /etc/selinux/<politica>/contexts/default_contexts.

Contexto de seguridad del sistema de archivos

SELinux almacena el contexto de seguridad en atributos extendidos (xattrs). Xattrs son almacenados como una propiedad nombre-valor asociado con los archivos. SELinux utiliza el atributo security.selinux.

Un sistema de archivos podría necesitar ser re-etiquetado. Esto normalmente ocurre cuando se etiqueta un sistema de archivos SELinux por primera vez, o cuando se cambia entre distintos tipos de políticas.

El mejor método para etiquetar un sistema de archivos es dejando al proceso init realizarlo durante el inicio. Para ello, debe crear el archivo /.autorelabel:

# touch /.autorelabel# reboot

Permitiendo que el etiquetado se realice durante el arranque, se asegura que las aplicaciones tienen las etiquetas adecuadas cuando son iniciadas, y que además son iniciadas en el orden correcto.

Es posible re-etiquetar un sistema de archivos usando el comando fixfiles, o re-etiquetarlo basándose en la base de datos RPM:

# fixfiles relabel# fixfiles -R <nombre_paquete> restore

Existe un tercer método que es la ejecución del comando make relabel.

Copiar o mover archivos

En operaciones de sistema de archivos, el contexto de seguridad debe ser considerado en términos de la etiqueta de un archivo, el proceso que lo accede y los directorios en los que la operación se realiza. Debido a esto, copiar o mover un



archivo podría tener resultados inesperados.

A menos que indique lo contrario, cp sigue el comportamiento por defecto cuando crea un nuevo archivo, basándose en el dominio del proceso creador y el tipo del directorio destino. A menos que exista una regla específica para establecer la etiqueta, el archivo hereda el tipo del directorio destino. La opción -Z user:role:type permite especificar una etiqueta para el nuevo archivo.

Por ejemplo, la creación de archivos en el HOME del usuario resulta de la siguiente forma:

# cd $HOME# touch archivo1 archivo2# ls -Z archivo1 archivo2-rw-r--r-- root root user_u:object_r:user_home_t archivo1-rw-r--r-- root root user_u:object_r:user_home_t archivo2

A los archivos creados en los directorios HOME se establece el tipo user_home_t por defecto.

La copia de un archivo a otro directorio crea un archivo en la nueva ubicación con el nuevo tipo basado en el proceso que lo crea y el directorio destino:

# cp $HOME/archivo1 /tmp# ls -Z /tmp/archivo1-rw-r--r-- root root user_u:object_r:user_tmp_t /tmp/archivo1

Si se desea indicar un tipo específico para el objeto durante la copia utilice la opción -Z del comando cp:

# cp -Z user_u:object_r:user_home_t $HOME/archivo1 /tmp# ls -lZ /tmp/archivo1-rw-r--r-- root root user_u:object_r:user_home_t /tmp/archivo1

Al mover archivos con el comando mv, el archivo mantiene el contexto de seguridad. Esto podría provocar inconvenientes, por ejemplo, si mueve archivos de tipo user_home_t al directorio /var/www/html, httpd no podrá servir el archivo hasta que re-etiquete el archivo. Es posible re-etiquetar un archivo con el comando chcon.

Re-etiquetar un archivo o directorio

Utilice el comando chcon cuando tiene un archivo que no es del tipo de desea. Debe conocer el nuevo tipo:

# ls -Z /var/www/html/welcome.html-rw-r--r-- root root user_u:object_r:user_home_t welcome.html

En el ejemplo anterior, la etiqueta de un archivo que debe ser servidor por httpd no es la apropiada, para cambiar la etiqueta ejecute el comando:



# chcon -t httpd_sys_content_t /var/www/html/welcome.html

Puede utilizar la opción -R para cambiar el contexto de forma recursiva.

Utilice el comando restorecon cuando desea restaurar los archivos al contexto por defecto definido en la política. Por ejemplo, para restaurar el contexto de todos los archivos del directorio /var/www/html ejecute el siguiente comando:

# restorecon -R /var/www/html

Haciendo los cambios de contexto de seguridad permanente

La modificación del contexto de seguridad de los archivos es persistente entre reinicios del sistema a menos que el sistema de archivos sea re-etiquetado. Para hacer que el contexto de seguridad de los archivos no cambien, debe establecer el contexto de seguridad por defecto de los archivos agregando la especificación de archivo, tipo y contexto de seguridad SELinux al archivo:

/etc/selinux/<politica>/contexts/files/file_contexts.local

No cree o modifique este archivo manualmente, utilice la herramienta semanage. Para establecer que todos los archivos que existen en el directorio /web/html sean etiquetados con httpd_sys_content_t ejecute el siguiente comando:# semanage fcontext -a -t httpd_sys_content_t '/web/html(/.*)?'

La opción -a indica que se desea agregar una definición de contexto especificado con -t para los archivos indicados con la expresión regular.

Para verificar los contextos definidos, utilice el comando con semanage con la opción -l.# semanage fcontext -l

Política SELinux Targeted

La política SELinux es altamente configurable. Bajo la política targeted, cada sujeto y objeto se ejecuta en el dominio unconfined_t excepto ciertos demonios específicos. Los objetos en el sistema que se encuentran en el dominio unconfined_t no tienen restricciones SELinux y utilizan el control de acceso discrecional de Linux normal (DAC). Esta política es lo suficientemente flexible para utilizarse en una infraestructura empresarial. Los demonios que son parte de la



política targeted se ejecutan en su propio dominio y están restrictos en cada operación que el demonio puede hacer en el sistema. De esta forma, demonios que son explotados están limitando en el daño que podrían provocar.

La política opuesta a la targeted es la política stritct. Esta política no se distribuye con Red Hat/CentOS Enterprise Linux pero puede ser descargada. En la política strict, cada sujeto y objeto se encuentra en un dominio de seguridad específico, con todas las interacciones y transiciones individualmente considerada en las reglas de la política. Este es un entorno mucho mas complejo.

Esta sección se enfoca en la administración de un sistema que utiliza la política targeted.

Administración de SELinux

El uso de la política targeted hace las tareas de administración fáciles para el administrador, por ejemplo, no es necesario considerar agregar, editar o borrar usuarios en SELinux, ni debe considerar los roles.

Verificación del estado de SELinux

El comando sestatus proporciona una visión del estado de SELinux. El comando muestra el estado, el punto de montaje del sistema de archivos selinuxfs, el modo de operación actual, el nombre de la política y la versión.

# sestatusSELinux status: enabledSELinuxfs mount: /selinuxCurrent mode: permissiveMode from config file: enforcingPolicy version: 21Policy from config file: targeted

Modificando el modo de operación de SELinux

Es posible habilitar y deshabilitar SELinux durante la ejecución del sistema o durante el arranque usando la línea de comandos o la interfaz GUI. SELinux puede operar en modo permissive o enforcing, o puede esta deshabilitado. En modo permissive, SELinux registra lo que debería hacer pero no deniega ninguna operación. En modo enforcing, SELinux deniega la operación.

Para cambiar el modo de operación con el sistema en ejecución ejecute el comando setenforce:

setenforce [0|1]

La opción 0 establece el modo permissive, la opción 1 establece el modo enforcing.



Para visualizar el estado actual puede utilizar el comando getenforce o sestatus.

Es posible desactivar el modo enforcing para un servicio en particular en lugar de todo el sistema, por ejemplo, si tiene problemas con el demonio named, puede deshabilitar el modo enforcing para ese demonio solamente utilizando los Dominios Permisivos.

Booleans

Los booleans permiten que parte de la política de SELinux sea cambiada en línea, sin necesidad de conocer el lenguaje de la política de SELinux. Esto permite cambios simples sin tener que compilar o recargar la política de SELinux.

Para listar los booleans y una explicación de lo que son, ejecute el siguiente comando:

# semanage boolean -l

El comando getsebool -a lista todos los booleans y su estado actual:

# getsebool -a

Si especifica un boolean en particular obtendrá el valor del mismo, o puede indicar una lista separada por espacios:

# getsebool allow_console_login allow_daemons_dump_core

Para cambiar el valor de un boolean, utilice el comando setsebool:

# setsebool httpd_can_network_connect_db on

Este cambio se aplicará hasta que se reinicie el equipo. Para que el cambio sea permanente, utilice la opción -P del comando setsebool:

# setsebool -P httpd_can_network_connect_db on

Dominios permisivos

Cuando SELinux se ejecuta en modo permisivo, SELinux no deniega el acceso, pero eventos serán registrados para todas aquellas acciones que deberían haber sido denegadas si se encontrara en modo enforcing. En Red Hat Enterprise/CentOS 4 y 5, los booleans <nombre_dominio>_disable_trans estaban disponibles para evitar que una aplicación transicione a un dominio confinado, y por tanto, se ejecutaba en un dominio no confinado, tal como initrc_t. Sin embargo, esto ocasionaba algunos problemas con las etiquetas de archivos y comunicación entre dominios confinados.



Para resolver estos problemas, Red Hat Enterprise/CentOS 6 introduce el concepto de dominios permisivos. Los dominios permisivos permiten a un administrador configurar a un único proceso (dominio) ejecutarse de manera permisiva, en lugar de dejar a todo el sistema en modo permisivo o con SELinux desactivado.

Para hacer un dominio permisivo, ejecute el comando:

# semanage permissive -a <dominio>

Para visualizar una lista de los dominios en modo permisivo, ejecute el comando:

# semodule -l | grep permissive

Si desea que un dominio ya no se ejecute en modo permisivo, ejecute el comando:

# semanage permissive -d <dominio>

Si desea conocer los nombres de los dominios posibles, ejecute el comando:

# seinfo -adaemon -x

Habilitar o deshabilitar SELinux

Desde la línea de comandos, puede editar el archivo /etc/sysconfig/selinux. El archivo de configuración es muy explicativo. Cambiando el valor de SELINUX o SELINUXTYPE modifica el estado de SELInux y el nombre de la política el siguiente reinicio del sistema.

# This file controls the state of SELinux on the system.# SELINUX= can take one of these three values:# enforcing - SELinux security policy is enforced.# permissive - SELinux prints warnings instead of enforcing.# disabled - SELinux is fully disabled.SELINUX=enforcing# SELINUXTYPE= type of policy in use. Possible values are:# targeted - Only targeted network daemons are protected.# strict - Full SELinux protection.SELINUXTYPE=targeted

Cuando habilita SELinux o realiza un cambio en la polítca, debe realizar un re-etiquetado del sistema de archivos. La modificación requiere el reinicio del sistema.

Realizando copias de seguridad de atributos extendidos

La utilidad tar en versiones anteriores a Red Hat Enterprise 5, no soporta el archivado y restauración de atributos extendidos. En lugar de tar, puede usar la utilizad star, con las opciones -xattr -H=exustar, por ejemplo:

# star -xattr -H=exustar -c -f archivos_web.star /var/www/html



Para restaurar, simplemente utilice la opción xattr:

# star -xattr -x -f archivos_web.star

Red Hat Enterprise 5 proporciona nuevas opciones que permiten el archivado de atributos extendidos con el comando tar. Actualmente, tar tiene las siguientes tres opciones:

● --selinux – Archiva los atributos SELinux de archivos y directorios.

● --acls – Archiva los atributos ACL de archivos y directorios

● --xattrs – Archiva todos los atributos extendidos de archivos y directorios. Esto incluye SELinux, ACLs y cualquier otro xattrs.

Por defecto, tar no archiva los xattrs, asi que estas opciones son necesarias para mantener buenas copias de seguridad.

Entendiendo un mensaje avc: denied

Cuando SELinux deniega una operación, un mensaje es registrado en los registros del sistema /var/log/messages y /var/log/audit/audit.log. El siguiente ejemplo muestra una denegación generado cuando el demonio httpd intenta acceder a un archivo que no tiene la etiqueta correcta:

Feb 23 02:42:00 localhost kernel: audit(1172209320.397:78): avc: denied { getattr } for pid=2631 comm="httpd" name="welcome.html" dev=dm-0 ino=1275217 scontext=root:system_r:httpd_t:s0 tcontext=system_u:object_r:user_home_t:s0 tclass=fileFeb 23 02:42:00 localhost kernel: audit(1172209320.409:79): avc: denied { getattr } for pid=2631 comm="httpd" name="welcome.html" dev=dm-0 ino=1275217 scontext=root:system_r:httpd_t:s0 tcontext=system_u:object_r:user_home_t:s0 tclass=file

El mensaje se compone de los siguientes campos:

● Fecha: Feb 23 02:42:00● Nombre de host: localhost● Mensaje de auditoría del kernel: audit(1172209320.409:79)● Operación denegada: avc: denied● Operación realizada: { getattr }● ID del proceso: pid=2631● Aplicación: comm="httpd"



● Archivo al cual intentó acceder la aplicación: name="welcome.html"● Dispositivo que contiene el archivo: dev=dm-0● Número de inodo del archivo: ino=1275217● Contexto de seguridad del origen (sujeto):

scontext=root:system_r:httpd_t:s0● Contexto de seguridad del destino (objeto):

tcontext=system_u:object_r:user_home_t:s0● Clase de objeto: tclass=file

Setroubleshoot

El paquete setrobleshoot instala una herramienta que monitorea el archivo de auditoría y si encuentra mensajes AVC y ejecuta una búsqueda en una base de datos para intentar encontrar una explicación de por qué SELinux ha evitado el acceso y una forma de solucionar el problema.

En la línea de comandos, los mensajes serán registrados en el archivo /var/log/messages y para obtener información detallada, puede ejecutar el comando sealert como se indica en el mensaje registrado.

Apr 3 03:06:02 mercurio setroubleshoot: SELinux is preventing the httpd from using potentially mislabeled files (/var/www/html/index.html). For complete SELinux messages. run sealert -l 0e0ac7dd-6d83-4a12-87b5-f109e66e0474

Realizando personalizaciones menores a una política existente

Puede resolver denegaciones SELinux usando nuevas reglas de política para permitir ciertos comportamientos. Las ramificaciones de seguridad son imposibles de predecir. En el peor de los casos, la seguridad quedaría controlada por el control de acceso discrecional.

El programa audit2allow, proporcionado por el paquete rpm policycoreutils, permite agregar reglas personalizadas menores a una política existente. Es importante destacar que aunque audit2allow genera una regla, no implica que sea una buena regla o que sea segura, debe verificar la regla para mayor seguridad.

Utilizando audit2allow Red Hat/CentOS Enterprise 5 o superior

Si tiene mensajes AVC puede utilizar audit2allow para generar una archivo TE listo para ser cargado como un módulo de política. El comando requiere del paquete



checkpolicy, asegúrese que el paquete esta instalado.

Los mensajes AVC pueden ser vistos en el resultado del comando sealert -l si el servicio setroubleshoot está activo.

# mkdir -p /root/selinux/local_rules# cd /root/selinux/local_rules/

Copie el mensaje avc: denied mostrado en el archivo de registro a un archivo temporal, por ejemplo, /tmp/avc.msg y ejecute:

# audit2allow -M local < /tmp/avc.msg

El comando generará dos archivos, local.te y local.pp.

El archivo local.te consta de tres partes. La llamada module introduce declaraciones que permiten al módulo funcionar, incluyendo la declaración del módulo y el requerimiento de roles, clases y permisos. Asegúrese que el nombre declarado aquí concuerda con el nombre del archivo (en este caso local.te).

El bloque require lista los símbolos que este módulo utiliza y deben ser declarados en otros módulos.

El resto del archivo es la política. Si ha modificado manualmente el archivo local.te luego de su verificación, debe volver a compilar el módulo, para ello, ejecute el comando:

# checkmodule -M -m -o local.mod local.te# semodule_package -o local.pp -m local.mod

Instale el módulo ejecutando el siguiente comando:

# semodule -i local.pp

El cambio es permanente y se mantendrá al reiniciar el sistema.

Los módulos son identificados por un nombre único. Esto significa que si inserta otro módulo local.pp, reemplazará el actual. Por tanto debería mantener este archivo local.te y agregar a él las reglas que necesita para otras personalizaciones.

Para listar los módulos SELinux cargados, ejecute el comando:

# semodule -l

Para descargar un módulo ejecute semodule -r <nombre_modulo>, por ejemplo:

# semodule -r local

Podría utilizar el comando ausearch -m avc para listar los mensajes todos los



mensajes avc y combinarlo con el comando audit2allow, por ejemplo:

# ausearch -m avc | audit2allow -M local

El comando ausearch permite especificar rangos de tiempo con las opciones -ts y -te.

SELinux y los servicios de red

La configuración por defecto de SELinux puede impedir que ciertos servicios no funcionen como se espera o se está acostumbrado.

En muchas ocasiones, es necesario habilitar explícitamente una funcionalidad sobre un servicio dado utilizando system-config-securitylevel, system-config-selinux o setsebool.

NIS y SELinux

NIS está protegido por la política targeted. Por defecto, esta política no permite conexiones NIS. Para utilizar NIS, debe configurar el valor allow_ypbind de SELinux a 1 con el siguiente comando:

# setsebool allow_ypbind 1

Para verificar la configuración, ejecute el comando:

# getsebool allow_ypbind

Otros valores para NIS incluyen los siguientes:

● yppasswdd_disable_trans: Deshabilita SELinux para yppasswd si se configura a 1.

● ypxfr_disable_trans: Deshabilita SELinux para ypxfr si se configura a 1.

● ypbind_disable_trans: Deshabilita SELinux para ypbind si se configura a 1.

● Los valores booleans de SELinux que afecta a NIS son descritos en la página man ypbind_selinux.

NFS y SELinux

NFS está protegido por la política targeted. Por defecto, esta política permite conexiones NFS al servidor estableciendo los valores SELinux nfs_export_all_ro y nfs_export_all_rw a 1.

Si desea exportar directorios home a través de NFS usando SELinux, debe



establecer use_nfs_home_dirs a 1 en cada cliente utilizando el servidor NFS, para ello, ejecute el siguiente comando como root:

# setsebool -P use_nfs_home_dirs 1


# getsebool use_nfs_home_dirs

Los valores booleans de SELinux que afecta a NIS son descritos en la página man nfs_selinux.

Samba y SELinux

Samba está protegido por la política targeted. Si SELinux está configurado en modo enforcing, los archivos compartidos vía samba deben estar etiquetados con el contexto de seguridad correcto. Luego de configurar SAMBA para compartir un directorio, ejecute el siguiente comando para cambiar el contexto de seguridad de los archivos en el directorio compartido:

# chcon -R -t samba_share_t <directorio>

Si el directorio está dentro de un directorio HOME, posiblemente deba establecer el contexto de seguridad samba_share_t a todo el directorio home.

Cuidado: Si el sistema de archivos es re-etiquetado por SELinux, los cambios en el contexto de seguridad serán sobreescritos. Para realizar los cambios permanentes incluso luego de un re-etiquetado, consulte la sección Haciendo los cambios de contexto de seguridad permanente.

Ejecute el siguiente comando para permitir directorios home o subdirectorios de estos ser compartidos:

# setsebool -P samba_enable_home_dirs 1


# getsebool samba_enable_home_dirs

Si se comparte datos por más de un protocolo, por ejmplo FTP y Samba, el contexto de seguridad de los archivos debe ser establecido a public_content_t o public_content_rw_t.

Para utilizar recursos Samba como directorios home, debe establecer use_samba_home_dirs a 1 en cada sistema cliente que desea montar los directorios home.

Los valores booleans de SELinux que afecta a Samba son descritos en la página



man samba_selinux.

Apache y SELinux

Apache está protegido por la política targeted. Todos los archivos accedidos a través del servidor web deben estar etiquetados con el contexto de seguridad apropiado.

La política targeted permite la ejecución de scripts CGI y la lectura de directorios HOME al servidor Apache, sin embargo, para la lectura de directorios home, debe establecer el contexto de seguridad de los archivos a httpd_sys_content_t con el comando chcon. Otras funciones de Apache, tales como ejecutarse como servidor FTP no se permiten por seguridad. SELinux debe ser configurado explícitamente a 1 para permitir estas características adicionales.

Una lista de los contextos de seguridad y sus usos, así como los distintos valores booleans de SELinux están descritos en la página de man httpd_selinux.

FTP y SELinux

FTP está protegido por la política targeted. Si el servidor FTP está configurado para permitir acceso anónimo, los archivos deben estar etiquetados con el contexto de seguridad public_content_t en el directorio /var/ftp:

# chcon -R -t public_content_t /var/ftp

Si está configurando un directorio para uploads, debe establecer el contexto de seguridad a public_content_rw_t, por ejemplo:

# chcon -R -t public_content_rw_t /var/ftp/upload

Para permitir subir archivos al directorio upload, debe habilitar allow_ftp_anon_write utilizando el comando setsebool:# setsebool -P allow_ftpd_anon_write 1


# getsebool allow_ftpd_anon_write

Para permitir el acceso a directorios HOME ejecute:

# setsebool -P ftp_home_dir 1

Los valores booleans de SELinux que afecta a FTP son descritos en la página man ftpd_selinux.


10Seguridad del sistema de archivos

Seguridad del sistema de archivos

Opciones de montado de sistema de archivos

Muchos ataques de seguridad que son utilizadas contra los equipos, dependen de que puedan ejecutarse comandos en el directorio /tmp. Si este directorio es una partición separada, puede incrementar la protección marcándolo como no ejecutable. Cuando monta una partición, existen muchas opciones que pueden ser utilizadas, las más interesantes desde el punto de vista de seguridad son:

● nosuid – No permite la ejecución de programas con el bit SUID

● noexec – No permite programas ejecutables

● nodev – No permite la creación de dispositivos

Montando un sistema de archivos con estas opciones aumenta la protección, pero no detiene la ejecución de archivos. El linker y loader de Linux permitirá que binarios se ejecuten.

Por ejemplo, si se monta el sistema de archivos /tmp con la opción noexec:

# mount -o remount,noexec /tmp

Y se copia un ejecutable a este directorio:

# cp -p /bin/ls /tmp

Si probamos la ejecución del archivo debería fallar:

# /tmp/lsbash: /tmp/ls: Permission denied

Sin embargo, es posible ejecutarlo utilizando la loader de Linux:

# /lib/ld-linux.so.2 /tmp/ls

Entonces, cuál es el punto de usar la opción noexec? Esta opción permitirá evitar ataques simples que dependen de la ejecución de scripts en el directorio /tmp. Si el atacante obtiene acceso a un shell podría ejecutar el programa, pero una herramienta automatizada será detenida.

Para montar el sistema de archivos /tmp con la opción nosuid, edite el archivo /etc/fstab y modifique las opciones para el sistema de archivos:

LABEL=/tmp /tmp ext3 defaults,noexec,nosuid,nodev 0 0

Para que los cambios tomen efecto inmediatamente, ejecute el comando:

# mount -o remount /tmp



El directorio /var/tmp debería ser además reemplazado por un enlace simbólico al directorio /tmp:

# rm -fr /var/tmp# ln -s /tmp /var/tmp

Un problema que podría presentarse al agregar la opción noexec al directorio /tmp es que el servicio logrotate no podrá rotar los logs correctamente. Para solucionar esto, edite el archivo /etc/cron.daily/logrotate para utilizar otro directorio temporal:

#!/bin/sh

if [ ! -e "/logrotate_tmp" ]; thenmkdir /logrotate_tmp

fiexport TMPDIR=/logrotate_tmp

Nunca debe haber una excusa para que los usuarios ejecuten programas SUID/SGID desde sus directorios home. El directorio /var tampoco debe permitir la ejecución de programas. Modifique el archivo /etc/fstab como sigue:

LABEL=/home /home ext3 defaults,nosuid,nodev 0 0LABEL=/var /var ext3 defaults,noexec,nosuid,nodev 0 0

Permisos por defecto de los archivos

Cuando se crea un archivo o directorio, éste se crea con ciertos permisos por defecto. Los permisos por defecto están dados por la configuración del umask.

El comando umask permite definir qué permisos tendrán por defecto los archivos y directorios son creados.

El comando umask sin parámetros nos devuelve dicho valor :

$ umask022

Los permisos se calculan en base al umask de la siguiente manera:

Para nuevos archivos ejecutables (Programas compilados):

777 Permisos predeterminados

- 022 Se resta el valor de umask755 Permisos permitidos



Esto significa que los permisos con los que el archivo será creado serán 755 (rwxr-x-r-x).

Para nuevos archivos de texto o archivos regulares no ejecutables:

666 Permisos predeterminados

- 022 Se resta el valor de umask644 Permisos permitidos

En el caso anterior, 666-022 = 644 , es decir , cualquier fichero que creemos con un editor ó con otros comandos serán creados con permisos 644 (rw-r--r--) .

Para cambiar la máscara , usamos el comando umask con la nueva máscara que le deseamos dar :

$ umask 077

En cuyo caso , todos los ficheros a partir del ése momento , y hasta que finalice la sesión, serán creados con sin permisos para el grupo y los otros.

Para configurar el umask por defecto para todos los usuarios, edite el archivo /etc/bashrc:# By default, we want this to get set.# Even for non-interactive, non-login shells.if [ $UID -gt 99 ] && [ "`id -gn`" = "`id -un`" ]; then

umask 007else

umask 027fi

Grupos de usuario privado

Red Hat Linux utiliza un esquema de Grupo de Usuario Privado (User Private Group - UPG), lo que hace más fácil de manejar los grupos.

Se crea un UPG siempre que se añade un nuevo usuario al sistema. Un UPG tiene el mismo nombre que el usuario para el cual se crea y ese usuario es el único miembro de ese UPG.

Los UPGs hacen que sea más seguro configurar los privilegios por defecto para un nuevo archivo o directorio lo que permite a ambos, tanto el usuario como al grupo de ese usuario hacer modificaciones al archivo o directorio.

El parámetro que determina qué permisos son aplicados a un nuevo archivo o directorio es llamado un umask y es configurado en el archivo /etc/bashrc.



Tradicionalmente, en sistemas Linux el umask es configurado a 022, lo que sólo permite al usuario que crea el archivo o directorio realizar modificaciones. Bajo este esquema, todos los demás usuarios incluyendo miembros del grupo del creador no tienen derecho a realizar ninguna modificación. Sin embargo, bajo el esquema UPG, esta "protección de grupo" no es necesaria puesto que cada usuario tiene su propio grupo privado.

Directorios de grupos

Muchas organizaciones de IT (del inglés Information Technologies) prefieren crear un grupo para cada proyecto importante y luego asignar personas al grupo si estos necesitan acceso a los archivos de ese proyecto. Usando este esquema tradicional, el manejo de archivos ha sido difícil pues cuando alguien crea un archivo, este es asociado con el grupo primario al cual pertenece. Cuando una persona individual trabaja en múltiples proyectos, se hace difícil asociar los archivos correctos con el grupo correcto. Usando el esquema UPG, sin embargo, los grupos son automáticamente asignados a archivos creados dentro de un directorio con el bit SGID configurado, lo que hace muy simple el manejo de proyectos de grupos que comparten un directorio común.

Digamos, por ejemplo, que un grupo de personas trabajan con archivos en el directorio /datos/contabilidad/. Algunas personas son de confianza como para modificar el directorio, pero ciertamente no todos. Entonces primero cree un grupo contab, como se muestra en el siguiente comando:

# /usr/sbin/groupadd contab

Para poder asociar los contenidos del directorio con el grupo contab, escriba:

# chown -R root.contab /datos/contabilidad/

Ahora es posible añadir los usuarios adecuados al grupo con el comando gpasswd:

# /usr/bin/gpasswd -a <nombre_usuario> contab

Permita a los usuarios crear archivos dentro del directorio y configure el bit SGID, el cual asigna que todo lo que se cree en el directorio el mismo grupo del directorio padre (contab). Use el comando siguiente:

# chmod 2775 /datos/contabilidad

En este punto, puesto que cada usuario tiene por defecto su umask en 002, todos los miembros del grupo contab pueden crear y modificar archivos en el directorio /datos/contabilidad/ sin que el administrador tenga que cambiar los permisos de los archivos cada vez que un usuario escriba nuevos archivos.



Archivos SUID y SGID

Los archivos SUID y SGID de su sistema son potenciales riesgos de seguridad y deberían ser controlados. Como estos programas garantizan privilegios especiales al usuario que los ejecuta, es necesario estar seguro que no hay instalados programas inseguros. Un truco favorito de los crackers es explotar programas con el bit SUID, y entonces dejar un programa SUID como puerta trasera para entrar la próxima vez, incluso aunque el agujero original ya esté tapado.

Encuentre todos los programas SUID/SGID de su sistema y mantener la pista de lo que son, para que esté prevenido de cualquier cambio que podría indicar un potencial intruso. Use el siguiente comando para localizar todos los programas SUID/SGID en su sistema:

# find / -type f $ -perm -04000 -o -perm -02000 $

Incluso podría crear una base de datos de programas SUID con

# find / -type f $ -perm -04000 -o -perm -02000 $ > /root/programas_suid

y posteriormente verificar si ha aparecido alguno nuevo con el siguiente script:

#!/bin/bashDB=/root/programas_suid for ARCHIVO in `find / -type f $ -perm -04000 -o -perm -02000 $`do if ! grep $ARCHIVO $BD then echo "$ARCHIVO es un nuevo fichero con SUID" fidoneecho "Actualiza la base de datos si es necesario"

Directorios Sticky

El permiso Sticky en directorio provoca que los archivos contenidos dentro de ese directorio puedan ser borrados únicamente por el usuario propietario y por el usuario root.

Debe establecer el permiso Sticky en cualquier directorio que tenga el permiso de escritura para todos.

Permisos de escritura global

Los ficheros con permiso de escritura global, particularmente los del sistema, pueden ser un agujero de seguridad si un cracker obtiene acceso a su sistema y los modifica. Además, los directorios con permiso de escritura global son peligrosos, ya



que permiten a un cracker añadir y borrar los ficheros que quiera. Para localizar los ficheros con permiso de escritura global, use el siguiente comando:

# find / ! -type l -perm -2 -fstype ext3 -ls

y esté seguro de saber por qué tienen esos permisos de escritura global. En el curso normal de una operación algunos ficheros tendrán permisos de escritura global, incluidos algunos de /dev y enlaces simbólicos.

Archivos huérfanos

Los archivos sin propietario también pueden ser un indicio de que un intruso ha accedido a su sistema. Puede localizar los archivos de su sistema que no tienen propietario o que no pertenecen a un grupo con el comando:

# find / $ -nouser -o -nogroup $ -ls

Puede establecer un nuevo propietario para esos archivos con el comando:

# find / $ -nouser -o -nogroup $ -exec chown root:root {} \;

Archivos peligrosos

Los archivos .rhosts y .netrc ubicado en el HOME de los usuarios almacenan usuarios y contraseñas y pueden representar un riesgo de seguridad. Para evitar que estos archivos puedan ser creados utilice la siguiente técnica:

Cree un directorio con el nombre .rhosts y .netrc en el HOME de los usuarios:

# mkdir ~/.rhosts ~/.netrc

Cree un archivo vacío dentro del directorio:

# touch ~/.rhosts/lock ~/.netrc/lock

Establezca como propietario root y remueva todos los permisos permisos apropiados para los directorios:

# chown -R root.root ~/.rhosts ~/.netrc# chmod -R 0000 ~/.rhosts ~/.netrc

De esta forma, como el directorio no se encuentra vacío, el usuario no podrá borrarlo de su HOME, como no tiene los permisos apropiados, no podrá borrarlo de forma recursiva, tampoco podrá crear archivos con el mismo nombre.

Archivos extraños

Debe tener cuidado de archivos extraños que pudieran estar instalados en su



sistema de archivos. Tome por ejemplo la salida del siguiente comando ls:

# ls tmp/

#El directorio aparentemente se encuentra vacío, si utilizamos la opción -a para listar los archivos ocultos se obtiene el siguiente resultado:# ls -a tmp/ . ..#

Nuevamente, solo aparecen los directorio “.” y “..”. Sin embargo, si sed ejecuta el comando ls -la se obtiene:

# $ ls -la tmp/total 8-rw-r--r-- 1 root root 93560 feb 25 09:35drwxr-xr-x 2 root root 1024 feb 25 09:35 .drwx------ 28 root root 4096 feb 25 09:35 ..#

Es posible notar la presencia de un archivo cuyo nombre contiene caracteres no imprimibles, en este caso, el nombre del archivo está compuesto únicamente de espacios en blanco. Otro ejemplo podría ser un archivo cuyo nombre esté compuesto solamente por puntos, para engañar a la vista, como el siguiente:

# ls -la tmp/total 101drwxr-xr-x 2 root root 1024 feb 25 09:45 .drwx------ 28 root root 4096 feb 25 09:35 ..drwxr-xr-x 1 root root 93560 feb 25 09:45 ...

Para encontrar archivos extraños como este en el sistema de archivos ejecute el comando find de la siguiente forma:

# find /usr/share/terminfo/ ! -name "*[a-zA-Z0-9]*" ! -name ".*[a-zA-Z0-9]*" \ ! -name "." -ls

El comando buscará archivos cuyo nombre contenga únicamente caracteres especiales.

El comando chattr

Este es un comando muy interesante, ya que permite, entre otras cosas, hacer que un archivo no sea modificable ni siquiera por root en tanto tenga una bandera habilitada, lo que puede ayudarnos a mejorar la seguridad de un equipo o servidor. chattr viene por defecto en la mayoría de las distribuciones de Linux y trabaja en sistemas de archivos Ext2 y Ext3.



La sintaxis básica del comando es la siguiente:

chattr [ -RV ] [ -v version ] [ modo ] archivos

Las opciones son:

Opción Descripción-R Cambia atributos de forma recursiva.-V Muestra mayor información.

Los atributos o modo son puede otorgarse o quitarse anteponiendo el signo + o -, algunos atributos son:

Modo Descripcióna Solo puede abrirse para agregar datos (append).i El archivo es inmutable, no puede borrarse o moverse, no

puede crearse enlaces simbólicos y ningún dato puede ser escrito en el archivo.

s Los bloques de disco que ocupaba el archivo son rellenados con ceros cuando el archivo es borrado.

Para establecer los atributos a un archivo ejecute:

# chattr +a /var/log/messages

Para verificar los atributos de un archivo utilice el comando lsattr:

# lsattr /var/log/messages

Listas de acceso con ACL

En algunos casos, el sistema de permisos de GNU/Linux puede resultar insuficiente para nuestras necesidades. El sistema de ACL's (listas de acceso) extiende las posibilidades de el clásico sistema pudiendo añadir permisos de acceso a archivos a varios usuarios o grupos específicos, en lugar de uno sólo.

Para poder utilizar ACLs, es necesario que el sistema de archivos se monte con la opción -o acl. Para ello, edite el archivo /etc/fstab y agregue acl a la lista de opciones de montado y luego ejecute:

# mount -o acl,remount <punto_de_montaje>

Para hacer que los cambios surjan efecto inmediatamente.



Modificando las listas de acceso

El comando getfacl nos permite ver las listas de acceso de un archivo. Por ejemplo, para ver los atributos del archivo script.bash:

# getfacl script.bash# file: script.bash# owner: root# group: rootuser::rwxgroup::---other::---

Si listamos los permisos del archivo1.txt con el comando ls obtenemos:

# ls -la script.bash-rwx------ 1 root root 0 Feb 23 10:23 script.bash

Como se puede ver, la lista de acceso a archivo1.txt marca los mismos permisos que el comando ls -l, ya que no se ha establecido ningún permiso especial. Suponga que ahora se desea que el solamente usuario jperez, miembro del grupo operadores, pueda también ejecutar el archivo, pero no ningún otro miembro del grupo operadores.

Para lograr esto, que no es posible a través de permisos estándar de Linux, ejecute el comando setfacl con la opción -m:

# setfacl -m user:jperez:r-x script.bash# getfacl script.bash# file: script.bash# owner: root# group: rootuser::rwxuser:jperez:r-xgroup::---mask::r-xother::---

El resultado del comando getfacl muestra que ahora el usuario jperez tiene permisos para leer y ejecutar el archivo script.bash.

Si desea eliminar los permisos para el usuario jperez, utilice la opción -x del comando setfacl:

# setfacl -x jperez script.bash# getfacl script.bash# file: script.bash# owner: root# group: root



user::rwxgroup::---mask::---other::---

ACLs por defecto

Las ACLs por defecto nos permiten indicar cuál es la lista de control de acceso que se desea aplicar automáticamente a los nuevos ficheros y directorios que se creen dentro de un directorio dado. Se dice en estos casos que los permisos se heredan desde el directorio padre.

La sintaxis del comando setfacl es similar con la diferencia de que debe especificar además la opción -d:

# setfacl -d -m user:jperez:r-x /soporte

Cualquier archivo creado dentro del directorio /soporte permitirá la lectura y escritura para el usuario jperez.

Deshaciendo los cambios de las listas de acceso

Si desea quitar los atributos extendidos de un archivo utilice la opción -b que deja los permisos por defecto:

# setfacl -b script.bash# getfacl script.bash# file: script.bash# owner: root# group: rootuser::rwxgroup::---other::---

Copias de seguridad de archivos con ACLs

Los ACLs se almacenan en atributos extendidos del archivo. Para información acerca de cómo respaldar los atributos extendidos, consulte la página 136, Realizando copias de seguridad de atributos extendidos.

Borrado de datos del disco de forma segura

Normalmente los problemas vienen cuando perdemos datos y queremos recuperarlos, rara vez se nos presentará la ocasión en la que queramos eliminar completamente los datos del disco duro. Sin embargo, si se prentende vender el equipo, decomisionarlo, donarlo o devolverlo, lo más probable es que contenga



información sensible que debería borrar definitivamente.

Si el archivo se elimina con /bin/rm, sus contenidos permanecen en disco, hasta que sean sobreescritos por otros archivos.

El sistema de archivos ext3 acera los bloques punteros en el inodo, mientras que ext2 solamente los marca como no utilizados en el mapa de bloques y marca el inodo como borrado, dejando los bloques de punteros en disco. Esto hace que en ext2 sea mucho mas fácil recuperar datos borrados con herramientas tales como e2undel y Midnight Commander.

El comando shred permite borrar de forma segura un archivo o toda una partición o volúmen.

Para borrar un archivo con el comando shred utilice:

# shred -vz <archivo>

Este comando realizará una destrucción total de la información contenida en los bloques de disco que ocupaba el archivo, posteriormente puede borrar el archivo con el comando rm. La opción -v mostrará el progreso y la opción -z indica que finalmente rellene con ceros.

También puede borrar toda una partición o volumen con el comando shred, esto demorará mucho tiempo dependiendo del tamaño, por ejemplo, para borrar toda un disco ejecute:

# shred -n 5 -vz /dev/sdb

Para borrar una volumen lógico ejecute:

# shred -n 5 -vz /dev/datosvg/lvdatos

La opción -n indica que se realicen 5 iteraciones sobre la unidad.

Implementación de cuotas de disco

El almacenamiento en disco se puede restringir mediante la implementación de cuotas de disco y de esta manera el administrador es notificado antes de que un usuario consuma mucho espacio en disco o que una partición se llene.

Las cuotas se pueden configurar para usuarios individuales o para grupos. Este tipo de flexibilidad hace posible darle a cada usuario una pequeña porción del disco para que maneje sus archivos personales, mientras que se le permite tener más espacio para manejar los proyectos en los que estén trabajando o cuotas más grandes (asumiendo que a los proyectos se les da sus propios grupos).

Además, se puede configurar las cuotas no sólo para que controlen el número de



bloques de disco pero también el número de inodos. Debido a que los inodos son usados para contener información relacionada a los archivos, esto permite controlar el número de archivos que pueden ser creados.

El RPM quota debe estar instalado para implementar las cuotas de disco.

Configuración de cuotas de disco

Como usuario root, use el editor de texto de su preferencia, añada las opciones usrquota y/o grpquota al sistema de archivos que requiere cuotas:

LABEL=/home /home ext3 defaults,usrquota,grpquota 1 2

En este ejemplo, el sistema de archivos /home tiene cuotas de usuario y grupo ambas activadas.

Volver a montar un sistema de archivos

Después de agregar las opciones userquota y grpquota, vuelva a montar cada sistema de archivos cuyas entradas fstab hayan sido modificadas. Si el sistema de archivo no está siendo usado por ningún proceso, use el comando mount -o remount para volver a montar el sistema de archivos. Si el sistema de archivos está siendo usado actualmente, el método más fácil para volver a montar el sistema de archivos es reiniciando el sistema.

Creación de archivos de cuotas

Después de volver a montar cada sistema de archivos con cuotas, el sistema puede funcionar con cuotas de disco. Sin embargo, el sistema de archivos mismo no está listo para soportar cuotas. El próximo paso es ejecutar el comando quotacheck.

El comando quotacheck examina los sistemas de archivos con cuotas activadas y construye una tabla del uso del disco por sistema de archivo. La tabla es luego usada para actualizar la copia del uso del disco del sistema operativo. Además, los archivos de cuotas de disco del sistema de archivos, son actualizados.

Para crear los archivos de cuotas (aquota.user y aquota.group) en el sistema de archivos, use la opción -c del comando quotacheck. Por ejemplo, si las cuotas del usuario y grupos están activadas para la partición /home, cree los archivos en el directorio /home:

# quotacheck -acug

La opción -a significa que todos los sistemas de archivos no NFS montados en /etc/mtab son chequeados para ver si las cuotas están activadas. La opción -c especifica que los archivos de cuota deberían ser creados para cada sistema de



archivos con cuotas activadas, la opción -u especifica que se debe verificar por cuotas de usuario, y la opción -g indica verificar por cuotas de grupo.

Si no se especifican ninguna de las opciones -u ni -g, sólo se creará el archivo de cuota de usuario. Si únicamente se especifica la opción -g, sólo se creará el archivo de cuota de grupo.

Después de creados los archivos, ejecute el comando siguiente para generar la tabla del uso actual del disco duro por el sistema de archivos con cuotas activadas:

# quotacheck -avugM

Las opciones usadas son como se muestra a continuación:

Opción Descripcióna Verifica todos los sistemas de archivos montados localmente

con cuotas activadas.v Muestra detalles informativos a medida que la verificación de

cuotas se ejecuta.u Verifica la información de cuota de disco.g Verifica la información de cuota de disco del grupo.M Evita que se inente montar el sistema de archivos como sólo

lectura para la verificación de quotas

Después que quotacheck ha finalizado, los archivos de cuotas correspondiente a las cuotas activas (usuario y/o grupos) son poblados con datos para cada sistema de archivos con cuotas activadas, tal como /home.

Finalmente, para activar las quotas en el sistema de archivos ejecute:

# quotaon -a

Asignación de cuotas por usuario

El último paso es asignar las cuotas de disco con el comando edquota.

Para configurar la cuota por usuario, como usuario root en el intérprete shell, ejecute el comando:

edquota <usuario>

Ejecute este paso para cada usuario para el cual desea implementar una cuota. Por ejemplo, si una cuota es activada en /etc/fstab para la partición /home y se ejecuta el comando edquota jperez, se mostrará lo siguiente en el editor configurado como predeterminado en su sistema:



Disk quotas for user jperez (uid 501): Filesystem blocks soft hard inodes soft hard /dev/mapper/rootvg-lvhome 440436 0 0 37418 0 0

La primera columna es el nombre del sistema de archivos que tiene una cuota activada. La segunda columna muestra cuántos bloques está usando el usuario actualmente. Las próximas dos columnas son usadas para colocar límites de bloques duros y suaves para el usuario del sistema de archivos. La columna inodes muestra cuántos inodos está usando el usuario actualmente. Las últimas dos columnas son usadas para colocar los límites duros y suaves para los inodos del usuario en el sistema de archivos.

Un límite duro (hard) es la cantidad máxima absoluta de espacio en disco que un usuario o grupo puede usar. Una vez que se alcance el límite, no se puede usar más espacio.

El límite suave (soft) define la cantidad máxima de espacio en disco que puede ser usado. Sin embargo, a diferencia del límite duro, el límite suave puede ser excedido durante cierto tiempo. Este tiempo es conocido como período de gracia. El período de gracia puede ser expresado en segundos, minutos, horas, días, semanas o meses.

Si cualquiera de los valores está especificado a 0, ese límite no está configurado.

En el editor de texto, cambie los límites deseados. Por ejemplo:

Disk quotas for user jperez (uid 501):Filesystem blocks soft hard inodes soft hard/dev/mapper/rootvg-lvhome 440436 500000 550000 37418 0 0

Para verificar que la cuota para el usuario ha sido configurada, use el comando:

# quota jperez

Es posible además copiar los valores de quota de un usuario a otro, utilizando la opción -p. La opción -p toma como prototipo el usuario origen y aplica las mismas restricciones de quota al usuario destino. Por ejemplo, el comando:

# edquota -p jperez plopez

Aplicará la misma configuración de quota del usuario jperez al usuario plopez. De esta forma sería posible definir un usuario prototipo y definir los valores de quota para éste, luego, aplicar esta configuración a múltiples usuarios. Por ejemplo, para aplicar la misma configuración de quota para todos los usuarios del sistema con UID mayor a 500 utilizando la configuración de quota del usuario qproto como prototipo ejecute:

# edquota -p qproto $(getent passwd | awk -F ":" '$3 > 500 { print $1 }')



Asignación de cuotas por grupo

Las cuotas también pueden ser asignadas por grupos. Por ejemplo, para configurar una cuota de grupo para el grupo devel, use el comando (el grupo debe existir antes de configurar la cuota):

edquota -g devel

Establecimiento del periodo de gracia por defecto

Para establecer el periodo de gracia por defecto para el cual los límites de cuota dura serán impuestos, use el comando:

# edquota -tGrace period before enforcing soft limits for users:Time units may be: days, hours, minutes, or seconds Filesystem Block grace period Inode grace period /dev/mapper/rootvg-lvhome 7days 7days

Cambie el período de gracia del bloque o inodo, guarde los cambios del archivo y salga del editor.

Informe de cuotas de disco

Para crear un informe del uso del disco debe usar la utilidad repquota. Por ejemplo utilice:

# repquota -a# repquota /home

Aún cuando el informe es fácil de leer, es importante resaltar algunos puntos. La marca -- mostrada luego de cada usuario es una forma rápida de determinar si los límites del bloque o inodo han sido excedidos. Si el límite suave es excedido aparecerá un símbolo + en lugar del correspondiente -; el primer - representa el límite del bloque, y el segundo el límite del inodo.

La columna grace está normalmente en blanco. Si se ha excedido el límite suave, la columna contiene una especificación de tiempo igual al tiempo restante en el período de gracia. Si el período de gracia ha expirado, aparecerá none en su lugar.

Mantenimiento de la precisión de las cuotas

Cada vez que el sistema de archivos se desmonta de forma inadecuada (debido a una falla del sistema, por ejemplo), es necesario ejecutar quotacheck. Sin embargo, quotacheck puede ser ejecutado de forma regular, aún cuando el sistema no haya fallado. Mediante la ejecución regular de este comando se ayuda a mantener la exactitud de las cuotas.



La forma más fácil de ejecutar esto periódicamente es usando cron. Como root, puede bien sea usar el comando crontab -e para planificar un quotacheck periódicamente, o colocar un script que ejecute quotacheck en alguno de los directorios siguientes (usando el intervalo que más le convenga):

● /etc/cron.hourly● /etc/cron.daily● /etc/cron.weekly● /etc/cron.monthly

Las estadísticas de cuotas más exactas pueden se obtenidas cuando el sistema de archivos analizado no está en uso activo. Por tanto, la tarea cron debería ser planificada cuando se esté usando lo menos posible el sistema de archivos. Si esta hora varía para diferentes sistemas de archivos con cuotas, ejecute quotacheck para cada sistema de archivos en las diferentes horas mediante múltiples tareas cron.

Activación y desactivación de cuotas

Es posible desactivar cuotas sin tener que colocarlas a 0. Para desactivar todos los usuarios y grupos, use el comando siguiente:

# quotaoff -vaug

Si ninguna de las opciones -u o -g son especificadas, solamente se desactivarán las cuotas de usuarios. Si únicamente se especifica -g, sólo se desactivarán las cuotas de grupo.

Para activar las cuotas nuevamente, use el comando quotaon con las mismas opciones.

Por ejemplo, para activar las cuotas de usuarios y grupos para todos los sistemas de archivos:

# quotaon -vaug

Para activar cuotas para un sistema de archivos específico, tal como /home:

# quotaon -vug /home

Si no se especifican ninguna de las opciones -u ni tampoco -g, sólo se activarán las cuotas de usuarios. Si sólo se escribe la opción -g, únicamente las cuotas de grupo serán activadas.


11Técnicas para mantener la seguridad del sistema

Técnicas para mantener la seguridad del sistema

El shell restringido

El shell restringido es diseño para imponer a un usuario un entorno en el cual si posibilidad de moverse o escribir a archivos se encuentra severamente limitado. Puede hacer un shell restringido configurando el shell del usuario con el nombre rbash.

Si el shell bash es invocado con el nombre rbash o con la opción -r, bash se ejecutará en modo restringido. Los límites impuestos por el shell restricto evitan que el usuario pueda realizar lo siguiente:

● Cambiar de directorio con cd● Establecer o anular los valores de SHELL o de PATH

● Especificar nombres de órdenes que contengan /

● Especificar un nombre de fichero que contenga al menos una / como un argumento de la orden interna . (source)

● Importar definiciones de funciones desde el entorno del shell en el arranque

● Analizar el valor de SHELLOPTS desde el entorno del shell en el arranque

● Redirigir la salida usando los operadores de redirección >, <, >& y >>

● Utilizar la orden interna exec para reemplazar el shell por otro programa

● Añadir o eliminar órdenes incorporadas con las opciones -f o -d de la orden interna enable.

● Dar la opción -p a la orden interna command.

● Desactivar el modo restringido con set +r o set +o restricted.

Estas restricciones entran en vigor después de que se lean los ficheros de arranque que hubiera. Esto significa que el entorno total del usuario está configurado en el archivo .bash_profile. Debido a que no puede sobreescribir este archivo, permite al administrador configurar el entorno del usuario según sus requerimientos.

Dos métodos comunes para configurar entornos restrictos es establecer un directorio de comandos seguros, por ejemplo $HOME/bin, y que este sea el único directorio en el PATH del usuario. También es posible configurar un menú de comandos del cual el usuario no puede escapar a un shell.



Configuración de un shell restringido bash

Para establecer un shell restringido a un usuario basado en un directorio de comandos seguro utilice el siguiente procedimiento.

Cree un enlace simbólico para el shell bash con el nombre rbash:

# ln -s /bin/bash /bin/rbash

Asigne el shell rbash al usuario:

# adduser -s /bin/bash jperez

Si el usuario ya existe, modifique el shell de la cuenta:

# usermod -s /bin/rbash jperez

Cree un directorio seguro donde ubicará todos los comandos que el usuario tiene permitido ejecutar:

# mkdir /home/jperez/bin# chown root.root /home/jperez/bin

Cree enlaces simbólicos en este directorio a los comandos que el usuario tiene permitido ejecutar:

# cd /home/jperez/bin# ln -s /bin/ls# ln -s /bin/cat

En este caso, el usuario solo tiene permitido la ejecución de los comandos ls y cat.

Edite el bash_profile del usuario y establezca el PATH para que incluya únicamente el directorio seguro:

# vi .bash_profilePATH=$HOME/bin

Al iniciar sesión, el usuario únicamente podrá realizar el comando ls y el comando cat, no podrá especificar otro comando especificando la ruta completa y tampoco podrá cambiarse de directorio de trabajo. Las redirecciones están prohibidas por tanto no podrá reemplazar ningún archivo.

Administración de los registros de eventos

La gestión correcta de los registros de eventos es crítica para mantener la seguridad del sistema. Toda actividad desarrollada en el sistema es registrada y debe ser controlada.



En esta sección se proporcionan algunas recomendaciones para gestionar los registros de eventos del sistema.

Servidor de registro de eventos

El demonio syslog puede configurarse para ir enviando los mensajes de la consola a un equipo central donde se deben almacenar durante un periodo razonable de tiempo, de forma que se puedan comprobar los intentos de conexión no autorizados y las caídas que se producen en estos equipos. Este monitoreo es muchas veces muy sencilla de establecer y la recepción y almacenamiento de los registros no requiere mucha carga del procesador.

Esto permite además establecer una separación entre la administración del sistema y la auditoria de seguridad, de tal forma a que los registros de eventos no puedan ser manipulados y los auditores de seguridad no necesiten acceso a cada servidor para obtener el registro de eventos.

Configuración del servidor central syslog

La configuración por defecto de syslogd rechaza mensajes desde sistemas remotos.

Para configurar un sistema Red Hat/CentOS para que acepte mensajes log desde otros sistemas un la red, edite el archivo /etc/sysconfig/syslog. Agregue la opción -r a SYSLOGD_OPTIONS:

SYSLOGD_OPTIONS="-m 0 -r"

Reinicie el servicio syslogd para aplicar los cambios:

# /sbin/service syslog restart

Configuración de syslog para el envío a un sistema remoto

Debe configurar los demás sistemas de la red para que envíen los mensajes de registros de eventos al servidor syslog remoto.

En el fichero de configuración /etc/syslog.conf se le indica dónde (archivo, consola, o host remoto) ha de escribir cada uno de los eventos en función de la importancia. La hoja de manual syslog.conf explica la sintaxis.

La opción más segura consiste en registrar todos los eventos en el servidor central, de tal forma que un atacante no pueda modificar los registros de su actividad. Para esto, configure una línea en el archivo /etc/syslog.conf como sigue:

*.* @servidor_syslog.linux.com.py



Anteponiendo el símbolo @ al destino de los registros de eventos se indica al demonio syslogd que los mensajes deben ser enviados a un host remoto. Luego de modificar el archivo de configuración, debe recargar el servicio syslogd:

# service syslogd reload

Logwatch

Desafortunadamente hay demasiada información en los diferentes archivos de registro para que el administrador lo pueda asimilar, por lo que se puede recurrir a Logwatch. Logwatch (http://www.logwatch.org/), según lo describen sus autores, "procesa los archivos de registro para un determinado periodo de tiempo y crea un informe analizando las áreas que especifiques, con tanto detalle como se requiera."

Logwatch está instalado por defecto en las distribuciones más comunes y normalmente generará por defecto informes diarios enviándolos al correo electrónico del usuario root. Dado que estos informes son normalmente muy cortos deberían ser leídos cada día. Resaltarán, dependiendo de la configuración, información del tipo intentos de inicio de sesión inválidos, conexiones de red a varios demonios como SSHD, posibles escaneos de puertos, etc.

El archivo de configuración de logwatch por defecto de Logwatch es /usr/share/logwatch/default.conf/logwatch.conf. Las opciones de este archivo de configuración pueden ser personalizadas por medio del archivo /etc/logwatch/conf/logwatch.conf. El archivo de configuración por defecto se encuentra bien documentado.

La herramienta swatch

La herramienta swatch está desarrollada en PERL y permite monitorear logs y actuar en consecuencia de algún patrón detectado.

La herramienta swatch no se instala por defecto y generalmente no se incluye en la distribución Red Hat/CentOS. Debe descargar la aplicación, ya sea desde la pagina web o via yum.

Puede ejecutar cualquier cantidad de instancias swatch, pero cada instancia puede monitorear solo un archivo de registro.

La configuración de swatch es bastante simple. Una declaración típica de algo a ser monitoreado inicia con la palabra clave watchfor. La palabra clave watchfor toma una expresión regular perl que debe concordar en el archivo de registro para ejecutar la acción que desea. Por ejemplo, el archivo de configuración /etc/swatch/swatchrc puede contener lo siguiente:

watchfor /Failed password/



Si swatch detecta una concordancia en el archivo de registro, ejecuta una acción configurable. Algunas de las acciones que puede efectuar las siguientes acciones:

Acción Descripciónecho [modes] Indica que la línea que concuerda debe ser mostrada en la

salida estándar. El modo puede ser normal, bold, inverse o algún color (red, green, magenta, etc).

bell [N] Indica que la línea que concuerda debe ser mostrada en la salida estándar y que sonará la campana del sistema N veces.

exec comando Ejecuta el comando o script indicado. Los campos de la línea que concuerda se almacenan en variables siendo $0 toda la línea, $1 el primer campo, etc.

mail Envía un correo a direcciones especificadas.

El archivo de configuración /etc/swatch/swatchrc completo sería:

watchfor /Failed password/ echo magenta bell 3 mail addressses=root\@linux.com.py,subject="Intento de inicio de sesion invalido"

Puede tener múltiples reglas en el archivo de configuración siempre y cuando se esté monitoreando el mismo archivo de registro, por ejemplo:

watchfor /Failed password/ echo magenta bell 3 mail addressses=seguridad\@linux.com.py,subject=”Intento de inicio de sesion invalido”watchfor /session opened for user root/ echo magenta bell 3 mail addressses=seguridad\@linux.com.py,subject="Inicio de sesion interactivo con usuario root"

Una vez creado el archivo de configuración puede ejecutar swatch en primero o segundo plano. Para ejecutar swatch en primer plano utilice el siguiente comando:

# swatch --config-file /etc/swatch/swatchrc --tail-file /var/log/secure

Para utilizar swatch en segundo plano utilice la opción –daemon:

# swatch --config-file /etc/swatch/swatchrc --tail-file /var/log/secure –daemon



Archivo de registro de sesiones de usuarios

Además de los archivos de registro generados por el demonio syslog, existen otros archivos que permiten detectar actividades relacionadas a usuarios que suceden en el sistema.

El archivo utmp, wtmp y btmp

El archivo /var/log/wtmp es un archivo binario (no se puede leer su contenido directamente con cat o similares) que almacena información relativa a cada conexión y desconexión al sistema. Puede visualizar ver su contenido con el comando last.

El comando las muestra una lista de los usuarios que iniciaron sesión. Puede iniciar como argumento el nombre de usuario para ver los inicios de sesión de un usuario específico, por ejemplo:

# last <usuario>

Los registros guardados en este archivo (y también en el fichero utmp) tienen el formato de la estructura utmp, que contiene información como el nombre de usuario, la línea por la que accede (tty), el lugar desde donde lo hace y la hora de acceso.

El comando who también utiliza este archivo para mostrar la lista de usuario conectados al sistema.

Este archivo también mantiene información acerca de los apagados y reinicios del sistema, puede visualizar la fecha del apagado o reinicio del sistema con los comandos:

# last shutdown# last reboot

El comando lastb es similar al comando last con la excepción que muestra únicamente los intentos de conexión fallidos y esta información la obtiene del archivo /var/log/btmp.

El archivo lastlog

El archivo /var/log/lastlog contiene información acerca del último inicio de sesión exitoso de un usuario. El contenido del archivo está en formato binario y puede ser visualizado con el comando lastlog, por ejemplo:

# lastlog -u <usuario>

El archivo faillog

El archivo /var/log/faillog contiene información acerca de los intentos de inicio



de sesión fallidos. El contenido del archivo está en formato binario y puede ser visualizado con el comando faillog, por ejemplo:

# faillog -u <usuario>

Para que el archivo registre los intentos de inicio de sesión fallidos, debe configurar el módulo pam_tally.

Configuración del acceso de consola

Cuando los usuarios normales (que no son root) se conectan a un ordenador localmente, se les dan dos tipos de permisos:

● Pueden ejecutar ciertos programas que de otra manera no serían capaces de ejecutar.

● Pueden acceder a ciertos ficheros (generalmente ficheros de dispositivos especiales usados para acceder a diskettes, CD-ROMS, etc) a los que, de lo contrario, no les sería posible acceder.

Ya que existen múltiples consolas en un solo ordenador y múltiples usuarios pueden conectarse al ordenador localmente al mismo tiempo, uno de los usuarios tiene que "ganar" la carrera para acceder a los ficheros. El primer usuario que se conecte a la consola posee esos ficheros. Una vez que el primer usuario se desconecta, el siguiente usuario que se conecte tendrá esos archivos.

Por el contrario, a cada usuario que se conecte a la consola se le permitirá ejecutar programas que realicen tareas restringidas normalmente al usuario root. Si se está ejecutando X, estas acciones pueden incluirse como menú de items en la interfaz gráfica de usuario. Los programas accesibles a consolas incluyen halt y reboot.

Deshabilitar el apagado a través de Ctrl-Alt-Supr

Por defecto, /etc/inittab especifica que su sistema está configurado para apagarse y rearrancar el sistema como respuesta a la combinación de teclas usadas en la consola Ctrl-Alt-Supr. Si quiere deshabilitar esta función, deberá comentar la siguiente línea en /etc/inittab:

ca::ctrlaltdel:/sbin/shutdown -t3 -r now

Otra alternativa, es la de conceder a ciertos usuarios no que no son root, el derecho a apagar el sistema desde la consola mediante Ctrl-Alt-Supr. Puede restringir este privilegio a ciertos usuarios, siguiendo los siguientes pasos:

1. Añada una opción -a a la línea /etc/inittab mostrada anteriormente, de manera que quede así:



ca::ctrlaltdel:/sbin/shutdown -a -t3 -r now2. El indicador -a le pide a shutdown que busque el fichero

/etc/shutdown.allow, que creará en el siguiente paso.

3. Cree un fichero llamado shutdown.allow en /etc. El fichero shutdown.allow debería listar los nombres de usuario de cualquier usuario al que se le permita apagar el sistema usando Ctrl-Alt-Supr. El formato del fichero /etc/shutdown.allow es una lista de nombres de usuarios, uno por línea, como sigue a continuación:

jperez hlopezmgimenez

De acuerdo con este ejemplo de fichero shutdown.allow, jperez, hlopez y mgimenez están autorizados a apagar el sistema desde la consola usando Ctrl-Alt-Supr. Cuando se usa esa combinación de claves, el shutdown -a comprueba que cualquiera de los usuarios en /etc/shutdown.allow (o root) están conectados a una consola virtual. Si es uno de ellos, el apagado del sistema continuará; de lo contrario, aparecerá un mensaje de error escrito en la consola del sistema.

Deshabilitar el acceso desde la consola a programas

Para deshabilitar el acceso de usuario a programas de consola, debería ejecutar el siguiente comando como root:

# rm -f /etc/security/console.apps/*

En entornos donde la consola se encuentra asegurada ( BIOS y tienen contraseña, Ctrl-Alt-Suprimir está deshabilitado, los interruptores de encendido y reinicio están desactivados, etc.), puede que no desee permitir a ningún usuario que ejecute en la consola poweroff, halt, y reboot, que son accesibles desde la consola por defecto.

Para desactivar estas habilidades, hay que ejecutar los siguientes comandos como root:

# rm -f /etc/security/console.apps/poweroff# rm -f /etc/security/console.apps/halt# rm -f /etc/security/console.apps/reboot

Deshabilitar el apagado del sistema desde GDM

Para evitar que usuarios no root apaguen el sistema desde la consola GDM, edite el archivo /etc/X11/gdm/gdm.conf en Red Hat/CentOS 4 o el archivo



/etc/gdm/custom.conf en Red Hat/CentOS 5 y modifique en la sección [greeter] estableciendo:

SystemMenu=false

Herramientas de integridad de archivos

Las herramientas md5sum y sha1sum son utilitarios que calcula el checksum de un archivo. Para propósitos de solución de problemas, pude asumir que cada archivo tiene un checksum único.

Debido a el checksum de un archivo cambiará si cualquier parte del archivo es modificado, puede usar estos utilitarios para verificar que un archivo no ha cambiado. Puede utilizarlo para verificar si dos archivos son exactamente iguales.

Puede además generar una base de datos con el checksum de los archivos y utilizarla posteriormente para comparar los archivos, por ejemplo, para generar una base de datos con los archivos y sus correspondientes checksums del directorio actual ejecute:

# md5sum * > md5sum.db

Para verificar si el checksum ha variado (indicando que el archivo fue modificado) ejecute:

# md5sum -c md5sum.db

Cifrado de información en disco

En estos días, los datos son móviles. Cada día, información sensible d ella corporación deja la compañía en un disco flash o en una laptop. Que sucede si la información es robada o perdida?. La información robada o perdida de un dispositivo puede ser mucho mas valiosa que el dispositivo en sí.

La encriptación de dispositivos es una forma de reducir los riesgos de datos móviles.

El Device Mapper y DM-Crypt

Iniciando con la versión 2.6, el kernel de linux proporciona la interfaz Device Mapper. Esta interfaz permite la creación de capas de dispositivos de bloques virtuales por encima de dispositivos de bloques reales. Estos dispositivos son utilizados para funciones como RAID, LVM y encriptación. El módulo DM-Crypt para el Device Mapper proporciona acceso a funciones de criptografía.



Linux Unified Key Setup (LUKS)

LUKS proporciona un formato en disco estándar para particiones encriptadas que facilita la compatibilidad entre distribuciones, permite múltiples usuarios/contraseñas, revocación de contraseñas y otras características de seguridad.

Encriptación de un disco

A continuación se describirá el procedimiento requerido para encriptar un disco, ya sea fijo o removible como un disco USB.

Para discos removibles se recomienda que utilice un sistema de archivos sin journal como ext2.

El procedimiento es destructivo. Por tanto, si desea encriptar los discos del sistema operativo, la mejor opción es realizarla durante el proceso de instalación marcando la casilla de verificación Sistema de cifrado en la ventana de particionamiento del disco.

Posteriormente, deberá ingresar la contraseña de encriptación:



Luego podrá continuar la instalación normalmente.

Para configurar un dispositivo encriptado desde la línea de comandos, inicialmente debe determinar el nombre de dispositivo para su disco, esto puede hacerlo con el comando dmesg o con el comando fdisk -l para listar los discos detectados por el sistema.

Suponiendo que el disco USB es el dispositivo /dev/sdc, debe crear una partición en el dispositivo:

# fdisk -cu /dev/sdc

Command (m for help): nCommand action e extended p primary partition (1-4)pPartition number (1-4): 1First cylinder (1-1019, default 1):Using default value 1Last cylinder or +size or +sizeM or +sizeK (1-1019, default 1019):Using default value 1019

Command (m for help): p

Disk /dev/sdc: 258 MB, 258998272 bytes8 heads, 62 sectors/track, 1019 cylindersUnits = cylinders of 496 * 512 = 253952 bytes

Device Boot Start End Blocks Id System/dev/sdc1 1 1019 252681 83 Linux

Command (m for help): wThe partition table has been altered!



Calling ioctl() to re-read partition table.Syncing disks.

Una vez creada la partición, LUKS debe crear inicialmente una estructura de datos en la partición física que será utilizada. El siguiente comando instala una cabecera LUKS en el dispositivo /dev/sdc1:

# cryptsetup luksFormat /dev/sdc1

WARNING!========This will overwrite data on /dev/sdc1 irrevocably.

Are you sure? (Type uppercase yes): YESEnter LUKS passphrase: [Introduzca una frase de paso]Verify passphrase: [Confirme la frase de paso]Command successful.

Una vez que la cabecera LUKS existe, un dispositivo dm-crypt puede ser creado para la partición encriptada.

# cryptsetup luksOpen /dev/sdc1 cryptodiskEnter LUKS passphrase:key slot 0 unlocked.Command successful.

El comando creará el dispositivo /dev/mapper/cryptodisk, puede verificarlo con el comando ls:

# ls -la /dev/mapper/cryptodiskbrw-rw---- 1 root disk 253, 4 feb 27 22:19 /dev/mapper/cryptodisk

Debe crear el sistema de archivos sobre el dispositivo cryptodisk utilizando el comando mkfs:

# mkfs -t ext4 /dev/mapper/cryptodisk# tune2fs -m 0 -i 0 -c 0 /dev/mapper/cryptodisk

Una vez creado el sistema de archivos la partición puede ser montada.

# mount /dev/mapper/cryptodisk /mnt/cryptodisk

Al terminar de usar el dispositivo debe desmontar y cerrar para eliminar el dispositivo de bloques encriptado antes de extraerlo:

# umount /mnt/cryptodisk# cryptosetup luksClose cryptodisk

Cada vez que desea volver a utilizar el disco, debe ejecutar el comando



cryptosetup luksOpen como se describió anteriormente para crear el dispositivo de bloques encriptado.

Existe un problema que impide que GNOME monte un disco USB encriptado (reportado en buzilla ID 209590). Para solucionar el problema, edite el archivo /etc/udev/rules.d/50-udev.rules y comente la siguiente línea:

# KERNEL=="dm-[0-9]*", ACTION=="add", OPTIONS+="ignore_device"

Montado de un disco encriptado durante el inicio del sistema

Para montar discos encriptados durante el inicio del sistema, puede configurar el archivo /etc/crypttab. Este archivo describe los volúmenes encriptados que deben ser configurados durante el inicio del sistema.

El formato del archivo es el siguiente:

<nombre> <dispositivo> <ruta_archivo_contraseña> <opciones>

Los campos del archivo son:

● <nombre> - El nombre del dispositvo de bloques resultante. El dispositivo puede ser accedido a través de /dev/mapper/<nombre>

● <dispositivo> - La ruta al dispositivo de bloques, por ejemplo /dev/sdc1. Se recomienda utilizar el UUID del dispositivo, por ejemplo UUID=76ea1945-0e6f-4a6a-a8ef-96e8c6da19d6. El UUID puede obtenerlo con el comando blk_id.

● <ruta_archivo_contraseña> - La ruta a un archivo que contiene la contraseña de encriptación. Si no se especifica uno, la contraseña será solicitada durante el inicio del sistema.

● <opciones> - Lista de opciones separadas por coma. Para ver todas las opciones disponibles, ejecute el comando man cypttab. De las opciones disponibles, las siguientes requieren especial mención:

○ swap – El dispositivo encriptado será utilizado como dispositivo swap y será formateado como swap luego de haber configurado el dispositivo encriptado. Puede indicar /dev/urandom como archivo de contraseña.

○ tmp – El dispositivo encriptado será preparado para ser utilizado como una partición tmp. Será formateado como ext2 y se establecerá permisos 1777.

Luego de configurar el archivo /etc/crypttab, además deberá configurar el archivo /etc/fstab. Por ejemplo:



# cat /etc/crypttabcryptoHome UUID=76ea1945-0e6f-4a6a-a8ef-96e8c6da19d6

# cat /etc/fstab/dev/mapper/cryptoHome /home ext3 defaults 1 2

Si desea que el sistema de archivos se monte automáticamente sin que tenga que especificar la frase de paso, deberá agregar un archivo de clave al dispositivo y especificar la ruta al archivo que contiene la clave en el archivo /etc/crypttab. Esto implica un riesgo de seguridad y el archivo debería ser almacenado en un sistema de archivos también encriptado. La ventaja de esto es que si almacena todas las claves en un sistema de archivos encriptado, durante el inicio solo deberá indicar una única frase de paso, que servirá para abrir el sistema de archivos que conotiene los demás archivos de clave.

Para agregar un archivo de clave ejecute los siguientes comandos:

# echo "frase de paso" > /root/cryptoHome.key# chown root /root/cryptoHome.key# chmod 600 /root/cryptoHome.key# cryptsetup luksAddKey /dev/sdc1 /root/cryptoHome.key

Cuando se solicite, introduzca la frase de paso actual. Luego, edite el archivo /etc/crypttab e indique la ruta al archivo:

# cat /etc/crypttabcryptoHome UUID=76ea1945-0e6f-4a6a-a8ef-96e8c6da19d6 /root/cryptoHome.key

The Center for Internet Security – CIS Benchmark

El Centro para Seguridad de Internet (CIS) es una organización sin fines de lucro que proporciona herramientas de benchmark (puntos de referencia), software, scripts, datos, información, recomendaciones/ sugerencias y otros servicios y materiales en su sitio web como un servicio publico a los usuarios de Internet. Las recomendaciones contenidas en los productos son resultado de un proceso de construcción consensuado que involucra la colaboración de muchos expertos en seguridad y son genéricos. El uso apropiado de las recomendaciones requieren un análisis y adaptación a los requerimientos específicos de la empresa, preferentemente, deben ser aplicados inicialmente en entornos de prueba.

El sitio web de CIS es:

http://cisecurity.org

Las herramientas de benchmark son distribuidas sin cargo. Las herramientas de



benchmark son:

● Valores, controles y reglas técnicas recomendadas para proteger el sistema operativo, aplicaciones de software y dispositivos de red

● Unicos, debido a que las recomendaciones son definidas por medio de un consenso entre cientos de profesionales de seguridad alrededor del mundo

● Descargadas aproximadamente un millon de veces por año

● Distribuidas gratuitamente en formato PDF

● Utilizado en miles en empresas como la base para las políticas de configuración de seguridad y estándares de facto contra los cuales compararse

Las herramientas de benchmark pueden ser descargadas del sitio web de CIS para distintos sistemas operativos, aplicaciones, dispositivos de red y móviles.

De la sección benchmark para Linux, podrá descargar los documentos con las recomendaciones que deben ser aplicadas a los sistemas.


Registro de cambios

Versión Fecha Sección Cambios Realizado por2.6 03-17-2011 Introducción a la seguridad

computacionalModificado el tamaño de particiones.

Agregada selección de selección de paquetes.

Iván Ferreira

2.7 20-04-2012 PAM Actualización de la sección a la versión 6

Iván Ferreira

2.8 03-05-2012 GPG Actualización de la sección a la versión 6

Iván Ferreira

2.9 23-05-2012 SELinux Actualización de la sección a la versión 6

Iván Ferreira

2.9 23-05-2012 LUKS Actualización de la sección a la versión 6

Iván Ferreira

Documents

LE301 Seguridad 1 - Seguridad Local v2-10