Siempre pensé que el mayor beneficio de los registros es confirmar que su máquina ha sido pirateada. Sin embargo, veo piratas informáticos que se jactan de los servidores de "rooting" en todo Internet. ¿Qué impide que un pirata informático con acceso de raíz elimine los registros para cubrir sus huellas?
¿Por qué es posible que el usuario root elimine los registros?
Porque necesitas poder administrar el servidor.
¿Qué impide que un pirata informático con acceso de raíz elimine los registros para cubrir sus huellas?
Con respecto al registro local, solo su propia estupidez. Con respecto al registro externo, su conjunto de habilidades y el suyo.
Hay muchas, muchas formas diferentes de "iniciar sesión". De hecho, podría tener el registro de la máquina enraizado en un dispositivo oculto separado que no se puede sobrescribir fácilmente, como un registrador de frambuesa pi / arduino, del cual tengo algunos.
En Linux, se supone que la raíz es capaz de hacer casi todo. En Windows, se aplica el mismo concepto; Si tiene acceso de root a una máquina, podrá hacer casi todo lo que quiera en esa máquina, lo que incluye eliminar registros.
También puede registrar todas las conexiones a una determinada máquina, especialmente si se supone que no se debe "acceder" en primer lugar.
¿Cómo descubriría lo que está pasando y cómo lo evitaría?
Esta es una manera de encontrar todos los cambios en los últimos 120 minutos:
find / -mmin -120 -printf '%p\t%a\n'
Bien, ¿eh? Gotcha, hacker! Mwahahaha ... pero puedes cambiar estos atributos si sabes lo que estás haciendo, así:
touch -d "24 hours ago" <file>
Peor aún, automatizándolo:
find / -print | while read file; do
touch -d "$(date -r "$file") - 24 hours" "$file"
done
Pero espera, Mark Hulkalo! Si todos los archivos se editaron por última vez hace 24 horas, ¡eso demuestra claramente que tenemos un haxor! Es cierto, pero también puede aplicar $RANDOM donde exista 24. Aquí hay un ejemplo de un número de 1-24: $((RANDOM % 10) + 1) . Ahora no parece tan fácil de descubrir, ¿verdad?
Pero, ¿qué pasa si todos los archivos se ven así, especialmente los archivos que no se deben cambiar? Limite el alcance a un directorio determinado, como /root . Hay muchas formas de enmascarar tu presencia localmente.
A menos que el atacante olvide limpiar ~/.bash_history , estarás volando a ciegas. Realmente, si el único "registro" que tiene es ~/.bash_history , entonces está en problemas si su atacante es al menos moderadamente inteligente. Eso se puede borrar en cada cuenta de usuario con una facilidad asombrosa, siempre y cuando tengas los permisos adecuados.
Es mucho más fácil registrar entradas en un lugar donde no se detectará o modificará fácilmente, como un dispositivo externo. Si bien es posible usar el análisis forense para recuperar las huellas de su atacante, es muy, muy fácil de eludir si sabe lo que está haciendo. Es por esto que el registro externo es una solución mucho mejor.
Y esa es la historia de por qué el registro externo es generalmente la respuesta ... tenga en cuenta que también hay formas de evitar el registro externo. Nada es 100% seguro; solo puedes hacerlo más difícil para tu atacante, no imposible.
¿Por qué es posible que el usuario root elimine los registros?
Debido a que alguien debe poder realizar cambios en el sistema, es decir, rotar los archivos de registro, eliminar los archivos de registro, etc. En la raíz de UNIX es tradicionalmente este usuario totalmente privilegiado. En realidad, no hay mucha diferencia entre modificar un registro y reemplazar un binario para omitir el registro, y la raíz puede hacer ambas cosas de manera predeterminada.
¿Qué impide que un pirata informático con acceso de raíz elimine los registros para cubrir sus huellas?
La configuración estándar por lo general no detiene al atacante en absoluto. Una forma obvia de mejorar esto es el registro en un servidor de registro remoto que está lo suficientemente protegido como para que el atacante no tenga acceso (en el caso más simple: no es posible iniciar sesión de forma remota).
Aparte de FreeBSD, OpenBSD y probablemente otros tienen la idea de archivos inmutables o de solo anexos. Con chflags puede marcar los archivos de registro de esta manera y solo los anexos son posibles y El archivo no puede ser eliminado. Si combina esta función con securelevel, podrá obtener archivos de registro que solo se pueden cambiar (eliminar, rotar) en modo de usuario único.
Y podría utilizar mecanismos de seguridad alternativos o alternativos como SELinux para asegurarse de que el usuario root "normal" no pueda cambiar los archivos.
Si el servidor ha tenido el usuario root comprometido, ese usuario puede eliminar cualquier archivo (incluidos los registros) en los sistemas. Pero, en la mayoría de las empresas, los registros no se almacenan localmente.
Si los registros se almacenan localmente y se eliminan, para determinar el alcance de la infracción, se puede realizar un análisis forense para recuperar los archivos.
Sin embargo, la mayoría de los servidores web empresariales y los entornos corporativos utilizan algún tipo de gestión de registros, que puede ir desde herramientas estándar como Syslog y SNMP, y software de gestión de registros patentado como Splunk.
Cuando se usan esos sistemas, el atacante tendría que comprometer el sistema de administración de registros y cualquier copia de seguridad del mismo para eliminar los registros y cubrir sus pistas.
Tan seguro, uno puede como root eliminar archivos; pero esta no es una forma segura de cubrir las huellas de uno.
Debido a que los dispositivos WORM (escribir una vez, leer muchos) aún son poco comunes. En los sistemas donde la seguridad y el análisis forense son muy importantes, estos dispositivos se utilizan para grabar registros en tiempo real, pero no puede ser eliminado de, incluso por root. Para poder implementar esto de manera segura, tiene que ser una limitación de hardware. Con menos seguridad, podría exponer una API a un servicio de software que solo tiene operaciones para escribir nuevos archivos y leer los antiguos. Si el servidor también tiene un dispositivo de hardware o hipervisor que registra básicamente cada cambio en el sistema, sería muy difícil ocultar sus pistas.
Debido a que ALGUIEN tiene que ser capaz de administrar archivos de registro, y si no es root, ¿quién? ¿Realmente desearía un sistema en el que si, por ejemplo, un archivo de registro crece y ocupa el 90% de su espacio en el disco, no hay absolutamente ninguna forma de eliminarlo?
Claro, este es un agujero de seguridad. En el mismo sentido que un sistema que permite a cualquier usuario hacer cualquier cosa, crea un agujero de seguridad. La mayoría de las cerraduras de las puertas están diseñadas para que solo alguien que esté dentro de la casa pueda sacar la cerradura de la puerta. Pero esto significa que cualquier persona que pueda entrar en su casa, como un huésped o un plomero, podría reemplazar su cerradura de la puerta con una para la cual solo él tiene la llave. ¿Es este un agujero de seguridad? Por supuesto. Pero ¿cuál es la alternativa? ¿Hacer que nadie pueda reemplazar la cerradura? ¿Qué pasa si se rompe el bloqueo?
En la vida real, no es un simple / o: "sistemas inseguros" donde cualquiera puede ingresar y hacer cualquier cosa, en lugar de "sistemas seguros" donde estamos 100% seguros de que solo los usuarios autorizados pueden hacer cosas autorizadas. Hay un rango de "seguridad". A menudo, cuanto más seguro se hace un sistema, más inconveniente se vuelve para los usuarios autorizados hacer su trabajo. En algún punto, la seguridad es tan estricta que el sistema es virtualmente inutilizable.
He dicho esto en los comentarios, pero parece que merece una respuesta completa.
Si está utilizando SELinux, puede configurarlo de tal manera que la raíz no pueda eliminar los archivos de registro. SELinux usa el Control de acceso obligatorio (control basado en roles) para determinar qué roles pueden leer / escribir / ejecutar cada archivo, encima de el control de acceso discrecional de Linux que establece qué Cada usuario / grupo / todos pueden hacer con un archivo: los permisos típicos de rwxrwxrwx.
Parece que hay confusión sobre cómo se podría usar SELinux para lograr esto, pero es bastante sencillo. Un posible punto de confusión es la idea de un usuario de Linux y un rol de SELinux . Nada cambia hasta donde llegan los usuarios de Linux. SELinux solo agrega a lo que Linux ya tiene. Así que configurarías tus usuarios como de costumbre. root también sería lo mismo que siempre.
Entonces necesitas introducir roles de SELinux. A los usuarios de Linux se les pueden asignar muchos roles de SELinux, y los roles de un usuario determinan lo que puede hacer en el sistema. Ahora, la política predeterminada de SELinux - 'dirigida' creo que es lo que se llama - tiene un usuario no limitado , que es análogo a un superusuario. De forma predeterminada, la raíz se asigna como no limitada, por lo que la raíz puede hacer cualquier cosa como lo haría sin SELinux. Me imagino que la mayoría de las personas no modifican la política predeterminada o los roles predeterminados en SELinux, por lo que da la impresión de que la raíz puede hacer lo que quiera.
Sin embargo, esto no es necesario . Si quitas el rol SELinux de la raíz, entonces no puede hacer nada (ni siquiera podrías iniciar sesión). Sin embargo, antes de hacer esto, desearía configurar un usuario con el rol de administrar SELinux. Tanto las políticas "dirigidas" como las "mls" vienen con roles de administración integrados, pero me olvido de lo que se llama exactamente. Por lo general, se lo otorgará a uno de los administradores de su sistema para que puedan modificar la política de SELinux, las funciones, etc., si es necesario.
Su pregunta llega a todo el punto de SELinux y su sistema de acceso obligatorio. La gente se dio cuenta de que obtener root da demasiado a los hackers. Pueden arruinar tu ssh, tu httpd y cualquier otra cosa que quieran. Pero con SELinux puede restringir o eliminar el acceso a la raíz, por lo que incluso si alguien inicia sesión en la raíz no puede simplemente destruir su sistema. Nota: esto se aplica a más que solo archivos de registro. Esto se aplica a todo en el sistema. Obtener root se vuelve sin sentido muy rápidamente si configura SELinux correctamente.
Y para ser claros, algún usuario en algún punto debe poder eliminar los archivos de registro. El objetivo de esto no es hacer que la eliminación de los archivos de registro sea imposible, el objetivo es hacer que sea imposible que root elimine cualquiera / todos los archivos de registro. Si alguien / algo en el sistema puede hacer un archivo de registro, entonces también puede eliminar ese archivo de registro, a menos que esté usando algún tipo de memoria de una sola escritura como otros he mencionado.
Entonces, la pregunta cambia un poco: un pirata informático compromete su servicio web y luego puede eliminar los registros asociados con él, ¿verdad? Y eso es lo que realmente nos importa, porque ese es el registro que rastreará sus acciones. Si aún pueden modificar eso, ¿cuál es el punto de todo este acto de circo? Bueno, la respuesta es que podría ser capaz de eliminar / alterar los archivos de registro, dependiendo del contexto en el que se estén ejecutando una vez que hayan explotado el sistema, y si ese contexto tiene permiso para modificar el Archivos de registro relevantes. Pero eso es un agujero de conejo en sí mismo y esta respuesta es lo suficientemente larga como está. Sin embargo, SELinux grabará las llamadas al sistema de todos modos, y el pirata informático que comprometió su servicio web no podrá modificar los registros de SELinux (son dos contextos / roles separados en el sistema), por lo que al menos tendrá eso.
De forma predeterminada, nada impide que un atacante elimine los registros para cubrir sus pistas; sin embargo, si un atacante elimina los registros, será obvio que algo sucedió. Algo más inteligente desde el punto de vista de un atacante es modificar los registros para eliminar simplemente sus pistas.
Por otra parte, puede implementar algunas medidas para proteger los registros, por ejemplo, enviarlos en tiempo real a un servidor externo.
Lea otras preguntas en las etiquetas linux