Cómo ajustar los permisos de Linux para máxima seguridad

¡Has hecho una pregunta MUY multidimensional allí!

Para empezar, existe todo un mundo de permisos POSIX: permisos de lectura / escritura / ejecución para usuarios, grupos, mundo y todo eso. Las respuestas de Daniel Toshkov y Jesse Pollard hablan a ese reino.

Jesse menciona SE Linux : lo que introduce son controles de acceso específicos de recursos. Hay ACL de POSIX , hay grupos C (grupos de control) y hay espacios de nombres .

Todos son muy hábiles y cada una de las cosas en negrita arriba es un tema que podría explorar fácilmente durante un día o más.

Consíguelos mal, y obtienes errores extraños. Por ejemplo, un inicio falla “permiso denegado” debido a que una aplicación ha leído solo su propio archivo de inicio y no ninguno de los otros archivos que están en el mismo directorio que ese archivo de inicio. Entonces “incluye” estaban fallando. Eso sucedió al menos una vez. Lo sé porque lo encontré y lo arreglé modificando las reglas para que funcione.

Contar con las reglas predeterminadas de SE Linux que vienen con varias aplicaciones es una estrategia. Examinar lo que son y revisarlos es otro, que personalmente considero mejor que el primero. Mejor aún estaría haciendo algunos experimentos usted mismo, agregando nuevas reglas para cerrar cualquier exposición “deslumbrante” que pueda notar.

No es un camino fácil, por ejemplo, le sucederá cosas como esta: SELinux está impidiendo que / usr / sbin / sshd acceda a ‘name_bind’ en tcp_socket.

Si entiendo la respuesta de Miroslav correctamente, se espera que los administradores de usuarios finales estén encantados de ejecutar:

# semanage port -a -t ssh_port_t -p tcp NNNNN

Toda esa genialidad de C-Group / Namespace / SE-Linux se puede envolver y usar con algunas herramientas geniales de Docker. Las implementaciones de servicios basados ​​en contenedores Docker realmente pueden brillar si desea construir cosas que sean seguras.

Reuní lo anterior para dar una perspectiva rápida de lo que estoy hablando aquí. De lo que esto habla es de proporcionar servicios a través de contenedores, donde cada contenedor ejecuta su propia copia distinta de un servicio dado con sus propios “mini-linux”, archivos de configuración, puntos de montaje, etc.

Por lo general, el microservicio es un servicio web, un servicio de base de datos o un punto final de API u ocasionalmente algún otro servidor basado en sockets como ssh (pero esto se desaconseja, excepto por diversión y exploración; no desea dejar ssh accidentalmente para imágenes de producción)

Ninguno de los procesos de microservicio se ve. Si / cuando miran alrededor de su propio entorno, esos procesos no verían mucho en absoluto. Una versión muy escasa y apenas disponible de Linux. Solo lo suficiente para seguir corriendo.

Todos piensan que son los únicos que escuchan en su puerto de servicio. Eso es porque en sus mundos, dentro de distintos contenedores Docker, lo son.

Cada instancia de Docker que ejecutes obtiene como versión del mundo una pila como la anterior. Tendrá un contenedor grabable en la parte superior de una pila de superposiciones.

Si bien el contenedor de escritura de la instancia se puede usar para cosas, no es una buena práctica usarlo para datos de producción. docker diff es mucho más útil para depurar problemas REALES si no hay muchos datos extraños en el contenedor.

Por ejemplo, con el servicio “Apache” de la imagen anterior ejecutándose en el puerto 80, puede iniciar sesión en /var/log/apache.log y simplemente escribir en ese contenedor, o Apache puede configurarse para enviar sus registros fuera del servidor a través de un punto final del servicio de agregación de registros. El uso del punto final de agregación le permite utilizar mejor los datos de registro.

Terminaré todo esto y lo llamaré ” construir buenas infraestructuras de contenedores “. Otra forma de ajustar los permisos de Linux para la máxima seguridad.

Buena lectura: SELinux revela errores en otro código.

Otra buena lectura: 20 consejos para reforzar la seguridad del servidor Linux

Depende de lo que usted llama “máxima seguridad”, ya que eso depende de su política de seguridad.

Para empezar son los permisos básicos, lectura (r), escritura (w), ejecución (x) / acceso. leer otorga la capacidad de leer un archivo, escribir otorga la capacidad de actualizar un archivo, ejecutar se aplica a archivos binarios y scripts de shell (aunque los scripts de shell también requieren acceso de lectura). Cuando se trata de un directorio, el indicador de ejecución se usa para significar “acceso a un archivo dentro del directorio”, y se aplican los derechos de acceso en el archivo mismo. Para leer un directorio todavía se requiere acceso de lectura, por lo que frecuentemente ve directorios con permiso “rx”. Esto permite al usuario leer el directorio y ver los nombres de los archivos a los que se hace referencia allí. Sin el acceso de lectura, el usuario debe conocer el nombre del archivo, ya que no puede mirar para ver qué nombres están presentes. (El uso principal para esto fue con FTP anónimo: permite que usuarios específicos recuperen archivos si se les dio el nombre del archivo con anticipación; todos los demás tenían que adivinar el nombre).

La base son los permisos de usuario, grupo y mundo.

Algunos archivos que solo el usuario debe tener (cachés, contraseñas web, credenciales …) por lo que estos archivos solo permitirían el acceso del usuario y a nadie más.

Entonces depende de si el usuario está compartiendo archivos con otros usuarios en un grupo designado o en diferentes grupos.

Luego hay archivos a los que cualquier usuario puede acceder.

El valor predeterminado USUAL es que el propietario tiene todos los derechos sobre sus propios archivos, PUEDE tener acceso de lectura o, a veces, de lectura / escritura a los archivos compartidos en un grupo, y generalmente tiene acceso de lectura a cualquier archivo que otorgue acceso mundial. Dado que los archivos de los usuarios normalmente comienzan con su propio directorio, propiedad de ellos, con sus controles de acceso de grupo predeterminados, el permiso en este directorio sería rwx (usuario), —- (grupo), —- (mundo). Ahora la mayoría de los lugares asumen que el usuario trabajará dentro de un proyecto, por lo que el grupo tiende a ser rx (lectura y acceso, ya que este es un directorio). USUALMENTE no tiene acceso A MENOS QUE el usuario elija cambiarlo. A veces esto viola la política del sitio. Algunos sistemas (Fedora es uno) crean un grupo único para cada usuario cada vez que se crea un usuario; este nombre de grupo predeterminado es el mismo que el nombre de inicio de sesión de los usuarios. Esto funciona ya que permite que el grupo refleje los permisos de los usuarios, sin compartirlos accidentalmente, pero generalmente está configurado en rx. El usuario PUEDE tener múltiples grupos autorizados por el archivo / etc / groups. El nombre del grupo está asociado con una lista de usuarios en ese grupo, por lo tanto, estos usuarios tendrán permisos de acceso grupal según lo establecido por el usuario (que aún puede negar el acceso).

Luego están las listas de control de acceso (ACL) que permiten al usuario especificar exactamente qué usuario o qué grupo puede tener acceso (y cuáles son esos derechos).

ALGUNOS sistemas incluyen controles de acceso obligatorios que el usuario no puede anular. Estos son establecidos por el administrador para hacer cumplir un modelo de seguridad dado, y se pueden usar para dividir a los usuarios entre sí, como separar los departamentos de recursos humanos de contabilidad de los departamentos de desarrollo. Esto evita que los usuarios utilicen los permisos de acceso “mundiales” por exceder las políticas de seguridad del sitio. También puede particionar a los usuarios de los archivos del sistema para ayudar a frenar y mitigar los errores de seguridad en el sistema. SELinux configura los controles de acceso obligatorios más detallados. RH los utiliza de manera predeterminada, y Fedora los incluye, utilizando variaciones que dependen del uso previsto del sistema, y ​​la estación de trabajo tiende a ser más flexible que un servidor, por ejemplo. SELinux se puede utilizar para establecer un modelo de seguridad multinivel en modo compartimentado completo para requisitos de alta seguridad. Sin embargo, en la práctica, no se usa tanto, ya que hace que el sistema sea un poco incómodo de manejar (cambiar los errores es MUCHO más difícil).

SELinux también admite la definición de roles de seguridad (controles de acceso basados ​​en rollos), e incluso se puede utilizar para eliminar la identificación de inicio de sesión raíz de ser un inicio de sesión viable. Esto elimina cualquier inicio de sesión raíz “todo poderoso”. Significa que la configuración debe hacerse con cuidado y garantizar que todos los privilegios habituales de root se distribuyan a uno o más “administradores”, de modo que incluso si requiere que dos de ellos lleven a cabo una acción, la acción realmente puede realizarse . Es bastante fácil pasar por alto algo …

Permisos del sistema de archivos – Wikipedia

Guía del usuario y administrador de SELinux (también verifique la versión adecuada; si está centrada en HR, consulte con la documentación de HR).

Capítulo 20. Listas de control de acceso

Lo primero es asegurarse de que su kernel de Linux admita la máxima seguridad.

Debe aplicar parches para GRSecurity y RBACS, preferiblemente también ACL POSIX si aún no están incluidos, y necesita los parches de estabilidad. También verifique que no haya parches de grupo de control que le faltan.

Necesita compilar el núcleo con estos y SELinux con MLS, junto con nilfs. Ah, también desea usar L4Linux, ya que necesita que funcione sobre SEL4. Si no puede probar FLASK, al menos puede garantizar que las funciones principales del núcleo sean correctas y no expongan la información de manera perjudicial.

Necesitas un corrector de host. SARA está desactualizado pero debe haber algo que pueda usar. Además, desea las pruebas EAL5 + junto con cualquier prueba más reciente (post-EAL).

También desea una segunda computadora (una virtual) que pueda hacer pruebas de penetración. Hay algunos probadores libres como en cerveza y también un par de probadores libres como en libertad.

Primero, coloque su directorio de registro en una partición que use NILFS. Está versionado, por lo que los ataques que intentan cambiar los registros para borrar la evidencia simplemente darán lugar a que veas tanto los ataques como los intentos de borrar.

A continuación, ejecuta los verificadores de host. Estos le mostrarán qué permisos están configurados correcta o incorrectamente. Desea que los permisos de archivo estándar de Unix sean correctos y seguros. Desea que los detectores de alteración de archivos (como Tripwire) se ejecuten regularmente, ya que detectarán el malware mejor que el software antivirus.

Tercero, menos privilegios. Usando contenedores (cárceles raíz en algunos casos) y grupos de control, asegúrese de que ninguna aplicación tenga acceso directo a ningún recurso (incluidos archivos y directorios) que no necesite. Debería ver un sistema mínimo específico para él y nada más.

Cuarto, instale las reglas MLS básicas de SELinux. MLS es seguridad de múltiples capas. Significa que puede hacer todo tipo de control detallado de todo. En su mayoría, desea usar esto para evitar que las aplicaciones eludan las restricciones y bloquear operaciones que son demasiado específicas para otros métodos. También desea limitar todas las cuentas de usuario para que todo lo que no necesite sea efectivamente invisible. De esa manera, el software hostil en una cuenta de usuario no puede hacer mucho.

En este punto, ejecute sus escáneres de seguridad externos para ver si hay errores de configuración de la aplicación o errores en componentes como el firewall. Si es necesario, corríjalos antes de verificar que los pasos 2–4 todavía estén bien.

Quinto, obtenga el problema del Dr. Dobbs que habla sobre la eliminación de root como usuario. No quieres o necesitas una cuenta de superusuario. Simplemente debilita la seguridad.

Sexto, deshabilitar las comunicaciones inseguras. SSH2 sobre cualquier cosa y casi todo lo demás sobre IPSEC2 están bien. Obviamente no puede ejecutar el protocolo IPSEC2 se ejecuta sobre IPSEC2. Es posible que no pueda ejecutar túneles IPSEC2 a su proveedor de DNS. DNSSEC está bien, pero es fácil de atacar por DoS, por lo que es mejor si nadie sabe lo que se está comunicando si es posible. SSL / TLS debe considerarse inseguro.

Séptimo, si es una opción, use OpenBIOS o Coreboot ya que muchas implementaciones estándar de firmware del sistema no son seguras.

Finalmente, usando sus notas de todo lo que cualquier software necesita, determine lo que queda. Tacha la lista de todo lo que tú, como administrador o usuario, quieras. Cualquier cosa que quede en la lista es mala juju. Use las capacidades para deshabilitarlo.

Si ha hecho esto bien, el sistema será utilizable. Altamente especializado, casi imposible de usar fuera de esas especialidades, pero debe ser increíblemente rápido dentro de esos parámetros ya que cada programa se encuentra en un entorno muy optimizado. También será muy seguro. Utilice el probador POSIX y cualquier probador de aplicaciones (las pruebas ACID para bases de datos, por ejemplo) para garantizar que las funciones que desea estén disponibles para los usuarios que las desean y no para otros usuarios.

Si hay un error de configuración, las pruebas no funcionarán. De hecho, la mayoría de las cosas no funcionarán. Los errores en las pruebas, y en qué usuario se equivocan, le indicarán qué debe ajustarse.

Esta es la máxima seguridad. Casi nadie necesita el máximo, pero esto te lo dará.

En la práctica, solo necesitará un subconjunto de esto, dependiendo de las necesidades y paranoias.

Los permisos predeterminados en Linux son 0022 (755 para directorios; 644 para archivos).

NSA RHEL recomienda una máscara de 0077 para máxima seguridad, lo que hace que cada archivo nuevo creado por un determinado usuario, no sea legible para otros usuarios que no sean el propietario.

Cuando usa una umask de 0077, solo el usuario tiene permisos de lectura, escritura y ejecución. El usuario definitivamente podrá abrir (‘ejecutar’) directorios.

Umask no sería apropiado si intenta controlar lo que otros usuarios pueden ver entre sí. Sin embargo, si tiene y trabaja con numerosos archivos que son sensibles hasta el punto de que pedir permiso para acceder a ellos es menos molesto / arriesgado que simplemente dejar que las personas vean lo que quieran, una buena máscara de 0077 sería una buena idea.

Personalmente configuré un umask de 0077 en todas mis instalaciones. Pero tenga en cuenta que esto es solo una cosa de las muchas. Y es tan importante como usar sudo, por ejemplo.

Leer más: umask – Wikipedia