Curso Avanzado Seguridad Logs

  • 2,343 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
2,343
On Slideshare
0
From Embeds
0
Number of Embeds
5

Actions

Shares
Downloads
87
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Curso Avanzado de Administradores Seguridad en sistemas GNU/Linux: Logs y análisis forense Antonio Durán Terrés
  • 2. Ficheros de log
    • Logs del sistema repartidos por varios ficheros
    • La mayoría en /var/log/
    • Muy útiles a la hora de resolver problemas de funcionamiento o cuestiones relacionadas con la seguridad
  • 3. logs de autenticación
    • auth.log
      • Información relacionada con la autenticación
        • inicios y finales de sesión, cambios de usuario por su, entradas por ssh...
    • utmp
      • usuarios que están en el sistema actualmente
    • wtmp
      • registra todos los inicios y finales de sesión
      • no refleja el uso de su
  • 4. logs de autenticación
    • Comando last
      • muestra la información de los ficheros utmp y wtmp
      • Fecha, hora y lugar desde el que se realizó la conexión
    • Fichero de log de LDAP
      • mejor no hacer logging, para mejorar la velocidad
      • sólo útil para resolver problemas LDAP
      • no válido para ver autenticaciones
        • muchas más entradas no referidas a la autenticación, sino a otros usos de LDAP como directorio
  • 5. logs de navegación
    • /var/log/apache
      • Accesos al servidor web local
      • útil para localizar accesos indebidos a partes privadas de la web
    • /var/log/squid
      • acces.log: accesos a través de Squid
      • cache.log: log general de Squid
      • store.log: información sobre la caché
  • 6. otros logs
    • /var/log/messages
      • información varia del sistema del sistema y de algunos demonios sin fichero propio
    • /var/log/daemon
      • información de demonios que no tienen ficheros propios
        • dnsmasq
    • /var/log/debug
      • mensajes de debug del kernel
  • 7. otros logs
    • /var/log/dmesg
      • mensajes de arranque
    • /var/log/kern.log
      • mensajes generales del kernel
    • /var/log/lastlog
      • último login de cada usuario. Comando lastlog
    • /var/log/mysql/
      • logs del servidor mysql
  • 8. otros logs
    • /var/log/samba
      • logs de SAMBA, muestra las conexiones realizadas a los recursos locales
    • /var/log/syslog
      • log general para los servicios que no eligen otro fichero para escribir
    • /var/log/user.log
      • Mensajes relacionados con las sesiones gráficas de usuario
  • 9. otros logs
    • /var/log/XFree86.0.log
      • logs del servidor gráfico, para saber la razón cuando éste no arranque
  • 10. Análisis forense
    • La primera norma a seguir si creemos estar sufriendo o haber sufrido una incursión u otro ataque es mantener la calma. De otro modo nuestras acciones podrían causar más daño que las del supuesto atacante.
    • Será necesario estar seguro de que se ha producido un ataque, comprobando que los daños producidos no han podido ocurrir por otra causa más común.
  • 11. Durante un ataque
    • Si se trata de un ataque externo a la red local, lo primero es desconectar el cable de conexión del router, para evitar que hagan más daño, y puede que piensen que es un problema de red en lugar de una detección.
    • Si no es posible hacerlo, lo mejor es denegar todo el tráfico desde la dirección del atacante:
      • problema por no tener punto único de control -> si el ataque es sobre muchos clientes sería difícil pararlo a tiempo
  • 12. Durante un ataque
    • Hay que bloquear la cuenta que el atacante usaba
    • A continuación debemos matar todos los procesos del usuario atacante y desconectarlos del sistema
    • Observar durante un rato para ver si el atacante vuelve a intentarlo, quizá desde otra dirección o con otros objetivos
  • 13. Durante un ataque
    • Si detectamos a un usuario local durante un ataque, lo primero que debemos hacer es comprobar que realmente el usuario es el titular de la cuenta.
      • En los I.E.S., acercarte a donde sea a mirar
      • En los C.P.R., llamar por teléfono y pedir que comprueben quien está sentado en el puesto
  • 14. Análisis forense
    • Si pensamos que un usuario local ha intentado comprometer la seguridad o ha realizado cualquier otro acto contrario a las normas, lo primero es comprobar que efectivamente el titular de la misma es el que ha realizado estas acciones
      • Comprobar que el puesto desde donde se han realizado es el que usa normalmente el usuario
      • Comprobar con los horarios y los profesores quien se sentaba en el puesto durante los actos
  • 15. Análisis forense
    • Ejemplo: publicación de material indebido en el portal interno del centro por parte de un alumno
      • Comprobamos, mediante el log de Apache, a que hora y desde que puesto se realizaron los comentarios
      • Comprobamos quien estaba conectado a esa hora en ese puesto, en el auth.log del cliente
      • El aula no coincide con la del usuario que estaba conectado, por lo que pensamos que puede haber un uso fraudulento de cuentas
  • 16. Análisis forense
    • Ejemplo: publicación de material indebido en el portal interno del centro por parte de un alumno
      • Comprobamos en el horario que profesor tenía clase en ese aula a esa hora
      • Un poco de ingeniería social en clase por parte de jefatura de estudios reveló qué alumnos exactamente se sentaban en el puesto en cuestión a la hora indicada
  • 17. Análisis forense
    • Ejemplo: publicación de material indebido en el portal interno del centro por parte de un alumno
      • Si no hubiésemos obtenido la información gracias a los alumnos
        • Comprobaríamos en el puesto los logins anteriores y posteriores, por si los usuarios entraron con sus propias cuentas en la misma hora de clase
        • En caso contrario, habríamos comprobado todos los auth.log de los ordenadores de alumnos, preguntándoles a éstos con quien se sentaron. La pareja que no hiciera login es la responsable.
  • 18. Después de un ataque
    • Cerrar el agujero
      • Si sabes por donde ha entrado el usuario, desconecta ese servicio, y comprueba que la versión que estás usando no tiene fallos de seguridad conocidos
      • Si no, comprueba todos los ficheros de logs buscando actividad cercana al momento del ataque, que pueda indicar cómo consiguió entrar el intruso
  • 19. Después de un ataque
    • Comprobando el daño
      • Mantener copia de seguridad de todos los datos y ficheros de configuración para poder realizar una nueva instalación rápida si fuese necesario
      • Después de un ataque que obtiene privilegios de root -> reinstalar y recuperar los datos de los backups
      • Comprobar cuando comenzó el ataque, por si los backups pudiesen estar dañados
  • 20. Después de un ataque
    • Copias de seguridad
      • Hacer copias de seguridad regularmente ayuda con la seguridad, para restaurar los datos que pudiesen haber sido comprometidos
      • Comprobar varios backups antes de restaurar los datos, por si llevan modificados mucho tiempo
      • Mantener las copias de seguridad en un sitio seguro y separado del servidor
  • 21. Después de un ataque
    • tripwire
      • Herramienta de seguridad y integridad de los datos útil para monitorizar y alertar sobre determinados cambios en ficheros.
      • En primer lugar se inicializa la base de datos, creando una visión de los datos actuales. Al hacer posteriormente las comprobaciones de integridad, se tomarán estos datos como referencia.
  • 22. Después de un ataque
    • tripwire
      • El fichero de configuración especifica las opciones para el programa (directorios a revisar, nivel de alertas, etc ...)
      • El fichero de polica (POLICY) especifica que ficheros se van a controlar.
      • Inicialización de la BD:
        • tripwire -m i -v
        • Se genera la base de datos
  • 23. Después de un ataque
    • tripwire
      • Comprobación de la BD:
        • tripwire -m c
        • Se va comprobando la integridad de todos los ficheros presentes en la BD
        • Se muestra por pantalla el informe y se guarda en el lugar indicado en el fichero de configuración
        • Para ver el informe almacenado:
          • # twprint -m r -r /var/lib/tripwire/report/ddprog.elbrocense.ex-20060519-124320.twr |less
  • 24. Después de un ataque
    • tripwire
      • Comprobación de la BD:
        • tripwire -m c
        • Se va comprobando la integridad de todos los ficheros presentes en la BD
        • Se muestra por pantalla el informe y se guarda en el lugar indicado en el fichero de configuración
        • Para ver el informe almacenado:
          • # twprint -m r -r /var/lib/tripwire/report/ddprog.elbrocense.ex-20060519-124320.twr |less
  • 25. Después de un ataque
    • tripwire
      • Comprobación de la BD:
        • Se muestra primero un resumen indicando los ficheros que han sido eliminados, modificados o añadidos desde que se creó la base de datos.
        • Posteriormente detalla cada uno de los problemas encontrados, para que podamos comprobarlos.
        • Cada vez que toquemos algo de lo que revisa tripwire, deberíamos actualizar la BD.
  • 26. Después de un ataque
    • tripwire
      • Actualización de la BD
        • # tripwire -m u -r /var/lib/tripwire/report/ddprog.elbrocense.ex-20060519-124320.twr
        • Este modo permite reconciliar las diferencias entre la base de datos y el sistema actual.
        • El estado actual se obtiene del informe que le indiquemos
  • 27. Después de un ataque
    • tripwire
      • Actualización de la BD
        • Se abre el editor que tengamos configurado
        • Al lado de cada cambio en la BD aparece una marca [x] para indicar si queremos que el cambio se aplique o no.
        • Dejarlo marcado indica que queremos realizar el cambio.
  • 28. Después de un ataque
    • tripwire
      • Actualización de la política
        • # tripwire -m p twpol2.txt
        • Modifica la política con el nuevo fichero de política indicado
        • Se obtiene un nuevo fichero binario de política a partir del fichero de texto
        • Se actualiza la BD conforme a la nueva política
  • 29. Después de un ataque
    • Identificar al atacante
      • Debido a que a la Intranet no se puede, al menos en teoría, acceder desde fuera, cualquier ataque procederá de algún centro de la RTE
      • Lo ideal sería tener el listado de direcciones IP por centros para poder informar inmediatamente a los responsables de los mismos de que se está produciendo un ataque desde sus instalaciones
  • 30.