¿Registro de comandos de Linux?

El historial de Bash no te ayudará contra un atacante semicompetente en el caso habitual.

Hay una alternativa: el subsistema de auditoría. Instale auditd y configúrelo, de modo que registre, por ejemplo, ejecuciones de programas y otras cosas que configure. Básicamente, registra las llamadas al sistema que se realizan de acuerdo con los filtros que ha creado.

Ahora, si realmente desea depender del historial de bash, puede hacerlo más seguro: las versiones recientes de bash pueden iniciar sesión en syslog en lugar de en un archivo de usuario local. Luego, syslog se puede redirigir a un servidor de syslog remoto si es importante para usted.

no servirá de nada si permites ejecutar comandos que no sean de shell desde el shell. Por ejemplo, puede omitir bash ejecutando perl (o algún otro lenguaje de scripting) y llamar a los comandos desde allí: evitará el registro de bash.

Un atacante que realmente quisiera ocultar sus pistas simplemente editaría el archivo de historial a mano.

Puede hacer que sea más difícil para un usuario no root ocultar los comandos que ya ha escrito en bash. Pero esto solo requiere que el atacante sea moderadamente competente.

• Si hace que la variable HISTFILE sea de solo lectura, bash guardará los últimos comandos $HISTFILESIZE en ese archivo cuando salga. También puede hacer que HISTFILESIZE (y HISTSIZE ) sea de solo lectura y establecerlos en un valor alto. Sin embargo, esto es muy fácil de vencer, por ejemplo, utilizando el history incorporado para sanear el historial antes de salir. Y dado que bash escribe las entradas del historial cuando sale y no después de cada comando, simplemente salga de bash con kill -9 $$ y no se guardará ningún historial. Se le puede indicar a Zsh que guarde el historial después de cada comando, pero no de ninguna manera que el atacante no pueda deshacer trivialmente.
• En Linux, puede hacer que el archivo histórico se agregue solo con chattr +a ~user/.bash_history . Solo la raíz puede eliminar el atributo de solo agregado de un archivo. Como se vio anteriormente, esto solo significa que si el atacante comete un error , no podrá borrar sus huellas.

Incluso si lograste tener todos los comandos de un shell en particular registrados, esto no sería útil para la seguridad. El atacante podría simplemente emitir comandos desde otra aplicación, de una manera que no levantaría ninguna bandera roja y sería plausiblemente denegable. ( zsh , fish : ok, entonces él prefiere esa shell. emacs , vi : así que editó un archivo de texto. ssh : probablemente solo quería conectarse a otra máquina. ~/bin/foo : es solo un guión inocente, pero ¿quién sabe lo que era hace dos horas?)

Linux (como la mayoría de las unidades unicas) tiene un sistema simple de auditoría de comandos llamado contabilidad de procesos que generalmente está habilitado de forma predeterminada: el El nombre del ejecutable, la hora y el usuario en ejecución para cada comando ejecutado se almacenan en /var/log/account (la ubicación exacta puede variar entre las distribuciones). Puede ver ese archivo de registro con lastcomm . Esto puede ayudarlo en su actual esfuerzo forense, pero puede ser derrotado por un atacante moderadamente competente (por ejemplo, al vincular cada ejecutable con /var/tmp/$name/ls ), todo lo que puede saber de manera confiable es que hubo actividad de ese usuario en un cierto tiempo.

Hay paquetes de auditoría más completos, en particular el subsistema de auditoría que john sugerido . Busque auditctl para encontrar algunos ejemplos de cómo configurarlo. Por lo general, esto no está activado de manera predeterminada, ya que viene con un impacto de rendimiento (no sé qué tan malo es esto en la práctica).

Otra herramienta simple que está (al menos parcialmente) predeterminada es el tiempo de archivo. Si el tiempo de espera de un archivo es anterior a la intrusión, el atacante no lo modificó. Si tiene habilitados los tiempos de acceso a los archivos (esto solía ser el caso de forma predeterminada, pero ahora con frecuencia está deshabilitado para el rendimiento; verifique las opciones de montaje *atime ),.

Todo eso asume que el atacante no ganó la raíz, de lo contrario todas las apuestas están desactivadas. Tenga en cuenta que la atacante incluso puede haber dejado huellas deliberadamente que hacen que parezca que no aumentó su acceso al limpiar inteligentemente solo las huellas más comprometidas. Si le preocupa algo, vuelva a instalar el sistema desde copias de seguridad limpias (así como a otros sistemas a los que el atacante pueda haber llegado después de la interrupción inicial).

Establezca todos los shells de los usuarios en shell restringido de bash . En /etc/passwd , establezca el shell en /bin/rbash (debería ser un enlace sim / bin / bash), o /bin/bash -r

El shell restringido de Bash evita que los usuarios cambien las opciones de shell como el historial de comandos.

Además, para complementar las ideas enumeradas anteriormente, instalaría y configuraría el reloj de registro para que se ejecute diariamente (o con mayor frecuencia) a través de cron y le envíe los resultados por correo electrónico con fines de auditoría.

Instalación y configuración:

Linux basado en Debian escribe el siguiente comando-

apt-get install logwatch

Linux basado en Redhat escribe el siguiente comando-

yum install logwatch

Para personalizar logwatch, vaya a / usr / share / doc / logwatch - * / directory y lea el archivo HOWTO-Customize-LogWatch

Editar archivo logwatch.conf:

vi /etc/logwatch/conf/logwatch.conf

O

vi /usr/share/logwatch/default.conf/logwatch.conf

Lea la página del manual de logwatch para obtener más información.