Curso Avanzado Seguridad Logs

  • 565 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
No Downloads

Views

Total Views
565
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
48
Comments
0
Likes
1

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.