Introducción a Gentoo HardenedEsta guía está orientada a cualquier usuario que esté inseguro de las cosas que ofrece el proyecto Gentoo Hardened, de cómo usarlas juntas y cuáles son sus respectivos roles en el proyecto. El principio básico de seguridad que enfatizamos es el de capas de seguridad. Las capas son fundamentales en asegurar que no se vea comprometida la máquina de un usuario, y si lo está, minimizar los daños hechos. Mediante la combinación de una serie de tecnologías diferentes, no obstante, relacionadas a seguridad, hacemos que un atacante tenga que saltar pasos adicionales antes de que pueda ocurrir un incidente de compromiso. Por esta razón siempre recomendamos que decida cuáles son sus necesidades específicas y combine esas soluciones para proteger su sistema. Intentaremos explicar las opciones y cómo usarlas juntas en este documento. Gentoo Hardened no es un producto o solución por si mismo, es meramente un proyecto formado por un grupo de desarrolladores que trabajan con un mismo objetivo: seguridad muy proactiva. Los subproyectos contenidos en Gentoo Hardened no están relacionados salvo por el hecho de que están alojados dentro del mismo proyecto. Puede pensar que esto es parecido a KDE o GNOME en el sentido de que ambos son partes del proyecto de escritorio, y que los dos tienen un objetivo común pero no están relacionados del todo uno con el otro.
En el corazón del proyecto se encuentra PaX. PaX es un parche para el núcleo que le permite protegerse contra desbordamientos de búfer y del heap y ataques similares. PaX es su primera línea de defensa. A causa del software malamente escrito siempre se está en riesgo de compromiso por la posibilidad de que ocurran desbordamientos de búfer y del heap. Estas dos vulnerabilidades son el resultado de límites no chequeados de la entrada que un usuario realiza en las aplicaciones. Cuando un atacante tiene la capacidad de generar una entrada en una aplicación tal que se inserte en la memoria pero sin ser chequeada, existe la posibilidad de un desbordamiento. Los lenguajes de programación de bajo nivel como C y C++ no protegen automáticamente de saturaciones (overruns) y el resultado final es que cuando el búfer se satura da la posibilidad de que el código ejecutable adyacente pueda ser sobreescrito con la entrada que viene del usuario. Esto normalmente provocaría que la aplicación se caiga en el caso que la entrada del usuario no sea entendida por la máquina y generalmente se manifiesta como un fallo de página (page fault) porque los caracteres que saturan el búfer en el área ejecutable serán tratados como direcciones que probablemente nunca existirían. Este es el resultado más benigno de una saturación. Sin embargo, si el atacante sabe de una saturación tendrá la oportunidad de añadir shellcode a la entrada y en vez de causar que la aplicación se caiga, esta en cambio ejecutará las instrucciones dadas. Esto sucede debido a que el shellcode se trata de cómo se almacenan las instrucciones en memoria para ser ejecutadas por el procesador. En términos básicos, el shellcode consiste de 'códigos de operación' (opcodes) que se traducen a rutinas en ensamblador. Los atacantes conocen estos códigos muy bien y pueden crear shellcode que les permita hacer lo que deseen, tal como ejecutar un shell root y asociarlo a un puerto. Cuando esto pasa, el usuario ni siquiera se dará cuenta de aquello porque la aplicación no se cae sino que empieza ejecutando el código arbitrario de los atacantes permitiéndoles hacer lo que se les plazca. PaX mitiga este problema colocando de forma aleatoria cada función y búfer de una aplicación en memoria. Esto es lo que se denomina ASLR (siglas en inglés de Address Space Layout Randomization, Aleatorización de Distribución del Espacio de Memoria) y es la base de PaX. Al tener offsets aleatorios para las funciones y búferes, el atacante es incapaz de generar una entrada maliciosa que garantice que el shellcode será ejecutado (y lo hace muy difícil puesto que la aplicación probablemente se caerá y se reiniciará con nuevos offsets aleatorios). ASLR es mucho más útil cuando se usa en conjunto con código PIE (Position Independent Executable, Ejecutable Independiente de la Posición) pero también funciona con el código ejecutable estándar, con un sobrecosto (overhead). PaX también ofrece a los segmentos ejecutables la capacidad de ser ejecutables y no modificables, de igual manera a que los segmentos modificables puedan ser modificables y no ejecutables. Esto es denominado pageexec. En procesadores de la arquitectura x86 no hay forma de hacer esto a nivel de hardware ya que los diseñadores de x86 juntaron las banderas de memoria para leer y ejecutar y así ahorrar espacio. Debido a que una página puede ser escrita o leída y ejecutada, no es útil ajustar los búferes como no ejecutables porque no podrían seguir siendo leídos. Así que en x86 PaX emula este comportamiento a nivel de software, el cual introduce un sobrecosto pero es muy útil para la seguridad. Por motivos de claridad, mientras que PIE y SSP generalmente son agrupados en la misma discusión porque ambos son parte del toolchain de Hardened, ciertamente son tecnologías diferentes con propósitos distintos. PIE por si mismo no provee seguridad adicional pero cuando se combina con PaX en el núcleo sí provee una herramienta poderosa contra los desbordamientos. SSP está implementado íntegramente en el espacio del usuario (userland) y protege contra ataques de quebrar la pila (stack smashing attacks) sin la ayuda del núcleo. Al estar implementados separadamente y hacen cosas distintas, ciertamente son dos capas diferentes de protección, por ejemplo, uno ataque denominado ret2libc puede esquivar a PaX pero sería bloqueado por SSP. Hemos avanzado a grandes pasos para proveer una forma fácil de construir la totalidad de las herramientas del espacio del usuario con código PIE para aprovecharse de ASLR con muy poco sobrecosto. Adicionalmente a PIE, nuestro toolchain Hardened también ofrece SSP (Stack Smashing Protection, Protección contra el Quiebre de la Pila) mediante la ubicación de un área externa de los búferes y colocando una marca especial aleatoria y criptográfica. Esto permite a SSP chequear si es que la marca fue sobreescrita luego de cualquier escritura al búfer y le permite terminar abruptamente la aplicación en caso de haber sido sobreescrita dicha marca. El toolchain de Hardened da a los usuarios un espacio PIE/SSP de la forma más fácil posible. Las fases (stages) marcadas con 'pie-ssp' son fases estándares construidas con PIE y SSP, no incluyen controles de acceso SELinux/RSBAC/grsecurity. Aunque PaX es la primera capa de protección, quizás incluso la segunda o tercera si tiene cortafuegos y/o detectores de intrusión en la red, también se recomienda que use control de acceso para dar seguridad adicional a su sistema. Es muy importante que note que el control de acceso como su última capa de protección. El control de acceso es muy útil para evitar el paso a los atacantes que ya ingresaron a su sistema, o a usuarios locales. Actualmente Gentoo Hardened soporta 3 soluciones de control de acceso: SELinux, grsecurity y RSBAC. SELinux requiere de cambios en el espacio del usuario lo que significa que construimos fases (stages) especiales para SELinux y que no deben ser confundidas con las fases pie-ssp. Sin embargo, ya que es recomendado el uso de fases pie-ssp con SELinux, también se ofrecen fases selinux-pie-ssp. Si desea usar grsecurity no tiene de qué preocuparse acerca de las fases ya que no requiere de cambios en el espacio del usuario. Simplemente use las fases pie-ssp y una vez que esté listo para construir el núcleo, use uno que tenga activado grsecurity tal como las fuentes de hardened-sources. Una vez que su sistema esté andando puede usar el modo de aprendizaje de grsecurity para construir las ACLs (Lista de Control de Acceso) para su sistema. Similar a grsecurity, RSBAC no requiere de cambio alguno en el espacio del usuario pero puede ser instalado luego de configurar una instalación normal de Gentoo. RSBAC es soportado por el núcleo rsbac-sources. Una vez que su sistema está corriendo puede elegir los distintos modelos de control de acceso ofrecidos por RSBAC pues todos son módulos. La documentación de Gentoo RSBAC lista los varios modelos ofrecidos y provee más información acerca de cada uno de ellos. Hasta ahora hemos hablado acerca de las dos capas que ofrecemos, tenemos intenciones de ofrecer más y lo haremos en el futuro. Ejemplo de capas adicionales son detección/prevención de intrusión, que estarán ubicadas primero, incluso antes de PaX. Discos y memoria de intercambio cifrados ofrecen protección contra las violaciones de seguridad "física". Auditar le permitiría ver y reaccionar a los riesgos antes de que se conviertan en un compromiso. El tráfico de red cifrado y autenticación fuerte también son capas que son muy bien soportadas en las instalaciones de Linux y probablemente no nos concentraremos en aquello.
|
|