Beneficios de seguridad al cargar módulos estáticamente en el servidor Apache

La carga estática hace la diferencia en la seguridad solo en situaciones en las que personas malintencionadas pueden alterar los archivos que se cargan dinámicamente, en cuyo momento es justo decir que tiene problemas más grandes a mano.

Si realmente queremos hablar de seguridad en relación con los módulos estáticos de Apache, podríamos argumentar lo siguiente: los módulos no estáticos facilitan los paquetes de terceros. En, digamos, un sistema Linux, usted tendría un paquete "principal" de Apache, y podría tener un módulo proporcionado por otro paquete. Por ejemplo, en un servidor Ubuntu reciente, puede tener el paquete apache2-bin , que proporciona Apache en sí, y libapache2-mod-php5 , que proporciona el soporte de PHP como un módulo no estático. El soporte de PHP puede estar en otro paquete precisamente porque es un módulo no estático.

Si se encuentra un problema de seguridad en el módulo PHP, ese paquete se puede arreglar (con un paquete nuevo y parcheado) de inmediato, sin tener que reemplazar el paquete principal de Apache de ninguna manera. Por lo tanto, es de esperar que el proceso de reparación sea más rápido: menos personas involucradas, paquetes fijos más pequeños para descargar ... En ese sentido, se puede considerar que los módulos no estáticos mejoran la seguridad, pero eso es muy indirecto. Lo que mejora la seguridad aquí es la capacidad de dividir el código base en varios paquetes que se pueden actualizar por separado, y los módulos no estáticos admiten ese modelo.

Tenga en cuenta que los módulos estáticos aún podrían administrarse como paquetes independientes, pero esto requeriría que el administrador de paquetes recompile (o al menos vuelva a vincular) el binario de Apache cada vez que se actualice un módulo estático. La compilación tras la actualización es una estrategia viable (eso es lo que hacen los sistemas * BSD como FreeBSD con sus "puertos") pero, como norma, las distribuciones de Linux han elegido la ruta de los "paquetes binarios".

Creo que hay dos riesgos principales de seguridad con el enlace dinámico:

1. Reemplazo del módulo: alguien podría reemplazar un módulo que está cargando con su propia versión. Eso tal vez registra los identificadores de sesión y sus claves de sesión correspondientes.
2. Carga previa: alguien se da cuenta de que hay un directorio en la ruta de búsqueda de la biblioteca que se comprueba antes de cargar el módulo actual. El atacante coloca su propia versión del módulo en ese directorio, y su módulo se encuentra y se carga antes de que el módulo original tenga la oportunidad de ser encontrado.

Sin embargo, estos dos ataques probablemente requerirán acceso de raíz para realizar. El primero se puede mitigar fácilmente realizando algún tipo de verificación de integridad en los módulos mismos. Un programa como TripWire le dirá si un archivo / módulo se ha modificado de alguna manera. En segundo lugar, podría restringir las rutas de su biblioteca a los directorios de raíz y mantener el número de rutas verificadas al mínimo.

Si alguien ya tiene acceso de root a su servidor, lo más probable es que tenga problemas más grandes.