Habrá un cronjob que ejecuta logrotate diariamente como root, puedes verificar la configuración en /etc/logrotate.conf y /etc/logrotate.d/* . Si realiza algún cambio, debe ejecutar /usr/sbin/logrotate -dv /etc/logrotate.conf para asegurarse de que no haya errores en la nueva configuración.
Además de auth.log , también debe rotar y mantener wtmp y btmp (el segundo rastrea los intentos fallidos de inicio de sesión), la mayoría de los sistemas mantendrán solo una rotación de ellos.
La configuración normal es que /var/log/ no se puede escribir en palabras, los archivos de registro que están dentro tampoco se pueden escribir en todo el mundo y, a veces, no se pueden leer en todo el mundo (este último para archivos como auth.log que puede contienen accidentalmente contraseñas ingresó en los campos de nombre de usuario, CWE-532 ).
Debería verificar que los permisos de archivo sean los esperados, es tarea de logrotate crear nuevos archivos de registro y establecer el propietario / permisos correctos (consulte la directiva create ). Sin embargo, el valor predeterminado es aplicar los permisos y la propiedad del archivo actual: si el propietario / los permisos se cambian una vez, estos se mantendrán en cada nueva instancia de ese archivo de registro (por lo que un error anterior puede volver a atormentarlo). / p>
Aunque un usuario normal no puede escribir o modificar directamente esos archivos, un usuario local probablemente puede agregarlos indirectamente a través de syslog:
logger -p auth.info -it sshd \
"Accepted password for root from host.badguys.com port 31337 ssh2"
(La situación es peor si acepta mensajes de syslog a través de UDP a través de la red, pero esto no suele estar habilitado de forma predeterminada en ninguna configuración sana).
Este es un ejemplo de CWE-117 , y muestra uno de una serie de problemas con syslog.
Se debe usar un método diferente para sobrescribir o eliminar datos en realidad si un atacante (o un usuario no confiable) adquiere un inicio de sesión, por ejemplo. escalada de privilegios, o uso creativo de los programas setuid / setgid.
Pero, hay una oportunidad para los ataques de tipo de denegación de servicio aquí. Si no tiene algún tipo de limitación de velocidad o bloqueo en sshd , un atacante puede inundar sus registros con el registro de conexión (y si se interrumpe, puede cubrir sus huellas con entradas falsificadas). Si logrotate está usando una rotación basada en el tamaño (no predeterminada) puede ser posible que gire las entradas reveladoras de la existencia, sin privilegios adicionales. Si utiliza la rotación basada en el tiempo, es posible que él pueda llenar de forma trivial el sistema de archivos en el que está iniciando sesión y evitar que se registren más eventos.
Para resumir:
- si los permisos del archivo de registro son incorrectos, sí, un atacante podría eliminar las entradas del archivo de registro.
(Si un atacante puede aprovechar otra escalada de privilegios locales, puede hacerlo de todas formas, por supuesto, pero entonces tiene un problema mayor)
- debe comprobar que los permisos del archivo de registro sean satisfactorios, por ejemplo. no se puede escribir en el mundo, y posiblemente no se puede leer en todo el mundo; la mayoría de las configuraciones no codifican los permisos paranoicos en el
logrotate.conf
- syslog estándar tiene una serie de problemas, que incluyen autenticidad, integridad y limitación de velocidad
- considere usar
/etc/hosts.allow para agregar a la lista blanca sus bloques de IP remotos para el acceso sshd, si es posible, es una medida de mitigación razonable
- debe usar algún tipo de bloqueo dinámico (en un Pi puede ver Micro Fail2Ban )
Una de las mejores maneras de limitar lo que un atacante puede hacer a sus archivos de registro es registrarlos en un sistema diferente a través de una red segura. Otras soluciones posibles incluyen archivos de solo aplicación implementados por el sistema operativo (consulte esto en Unix & Linux.SE ), esto es a prueba de manipulaciones .
También puede leer sobre mejoras en el registro * nix en El blog del mantenedor rsyslog. Una de las características que se analizan allí es linked-timestamping , que es a prueba de falsificaciones .