Successfully reported this slideshow.
Curso Avanzado de  Administradores Seguridad en sistemas GNU/Linux: Logs y análisis forense Antonio Durán Terrés
Ficheros de log <ul><li>Logs del sistema repartidos por varios ficheros </li></ul><ul><li>La mayoría en /var/log/ </li></u...
logs de autenticación <ul><li>auth.log </li></ul><ul><ul><li>Información relacionada con la autenticación </li></ul></ul><...
logs de autenticación <ul><li>Comando last </li></ul><ul><ul><li>muestra la información de los ficheros utmp y wtmp </li><...
logs de navegación <ul><li>/var/log/apache </li></ul><ul><ul><li>Accesos al servidor web local </li></ul></ul><ul><ul><li>...
otros logs <ul><li>/var/log/messages </li></ul><ul><ul><li>información varia del sistema del sistema y de algunos demonios...
otros logs <ul><li>/var/log/dmesg </li></ul><ul><ul><li>mensajes de arranque </li></ul></ul><ul><li>/var/log/kern.log </li...
otros logs <ul><li>/var/log/samba </li></ul><ul><ul><li>logs de SAMBA, muestra las conexiones realizadas a los recursos lo...
otros logs <ul><li>/var/log/XFree86.0.log </li></ul><ul><ul><li>logs del servidor gráfico, para saber la razón cuando éste...
Análisis forense <ul><li>La primera norma a seguir si creemos estar sufriendo o haber sufrido una incursión u otro ataque ...
Durante un ataque <ul><li>Si se trata de un ataque externo a la red local, lo primero es desconectar el cable de conexión ...
Durante un ataque <ul><li>Hay que bloquear la cuenta que el atacante usaba </li></ul><ul><li>A continuación debemos matar ...
Durante un ataque <ul><li>Si detectamos a un usuario local durante un ataque, lo primero que debemos hacer es comprobar qu...
Análisis forense <ul><li>Si pensamos que un usuario local ha intentado comprometer la seguridad o ha realizado cualquier o...
Análisis forense <ul><li>Ejemplo: publicación de material indebido en el portal interno del centro por parte de un alumno ...
Análisis forense <ul><li>Ejemplo: publicación de material indebido en el portal interno del centro por parte de un alumno ...
Análisis forense <ul><li>Ejemplo: publicación de material indebido en el portal interno del centro por parte de un alumno ...
Después de un ataque <ul><li>Cerrar el agujero </li></ul><ul><ul><li>Si sabes por donde ha entrado el usuario, desconecta ...
Después de un ataque <ul><li>Comprobando el daño </li></ul><ul><ul><li>Mantener copia de seguridad de todos los datos y fi...
Después de un ataque <ul><li>Copias de seguridad </li></ul><ul><ul><li>Hacer copias de seguridad regularmente ayuda con la...
Después de un ataque <ul><li>tripwire </li></ul><ul><ul><li>Herramienta de seguridad y integridad de los datos útil para m...
Después de un ataque <ul><li>tripwire </li></ul><ul><ul><li>El fichero de configuración especifica las opciones para el pr...
Después de un ataque <ul><li>tripwire </li></ul><ul><ul><li>Comprobación de la BD: </li></ul></ul><ul><ul><ul><li>tripwire...
Después de un ataque <ul><li>tripwire </li></ul><ul><ul><li>Comprobación de la BD: </li></ul></ul><ul><ul><ul><li>tripwire...
Después de un ataque <ul><li>tripwire </li></ul><ul><ul><li>Comprobación de la BD: </li></ul></ul><ul><ul><ul><li>Se muest...
Después de un ataque <ul><li>tripwire </li></ul><ul><ul><li>Actualización de la BD </li></ul></ul><ul><ul><ul><li># tripwi...
Después de un ataque <ul><li>tripwire </li></ul><ul><ul><li>Actualización de la BD </li></ul></ul><ul><ul><ul><li>Se abre ...
Después de un ataque <ul><li>tripwire </li></ul><ul><ul><li>Actualización de la política </li></ul></ul><ul><ul><ul><li># ...
Después de un ataque <ul><li>Identificar al atacante </li></ul><ul><ul><li>Debido a que a la Intranet no se puede, al meno...
 
Upcoming SlideShare
Loading in …5
×

Curso Avanzado Seguridad Logs

2,721 views

Published on

  • Be the first to comment

  • Be the first to like this

Curso Avanzado Seguridad Logs

  1. 1. Curso Avanzado de Administradores Seguridad en sistemas GNU/Linux: Logs y análisis forense Antonio Durán Terrés
  2. 2. Ficheros de log <ul><li>Logs del sistema repartidos por varios ficheros </li></ul><ul><li>La mayoría en /var/log/ </li></ul><ul><li>Muy útiles a la hora de resolver problemas de funcionamiento o cuestiones relacionadas con la seguridad </li></ul>
  3. 3. logs de autenticación <ul><li>auth.log </li></ul><ul><ul><li>Información relacionada con la autenticación </li></ul></ul><ul><ul><ul><li>inicios y finales de sesión, cambios de usuario por su, entradas por ssh... </li></ul></ul></ul><ul><li>utmp </li></ul><ul><ul><li>usuarios que están en el sistema actualmente </li></ul></ul><ul><li>wtmp </li></ul><ul><ul><li>registra todos los inicios y finales de sesión </li></ul></ul><ul><ul><li>no refleja el uso de su </li></ul></ul>
  4. 4. logs de autenticación <ul><li>Comando last </li></ul><ul><ul><li>muestra la información de los ficheros utmp y wtmp </li></ul></ul><ul><ul><li>Fecha, hora y lugar desde el que se realizó la conexión </li></ul></ul><ul><li>Fichero de log de LDAP </li></ul><ul><ul><li>mejor no hacer logging, para mejorar la velocidad </li></ul></ul><ul><ul><li>sólo útil para resolver problemas LDAP </li></ul></ul><ul><ul><li>no válido para ver autenticaciones </li></ul></ul><ul><ul><ul><li>muchas más entradas no referidas a la autenticación, sino a otros usos de LDAP como directorio </li></ul></ul></ul>
  5. 5. logs de navegación <ul><li>/var/log/apache </li></ul><ul><ul><li>Accesos al servidor web local </li></ul></ul><ul><ul><li>útil para localizar accesos indebidos a partes privadas de la web </li></ul></ul><ul><li>/var/log/squid </li></ul><ul><ul><li>acces.log: accesos a través de Squid </li></ul></ul><ul><ul><li>cache.log: log general de Squid </li></ul></ul><ul><ul><li>store.log: información sobre la caché </li></ul></ul>
  6. 6. otros logs <ul><li>/var/log/messages </li></ul><ul><ul><li>información varia del sistema del sistema y de algunos demonios sin fichero propio </li></ul></ul><ul><li>/var/log/daemon </li></ul><ul><ul><li>información de demonios que no tienen ficheros propios </li></ul></ul><ul><ul><ul><li>dnsmasq </li></ul></ul></ul><ul><li>/var/log/debug </li></ul><ul><ul><li>mensajes de debug del kernel </li></ul></ul>
  7. 7. otros logs <ul><li>/var/log/dmesg </li></ul><ul><ul><li>mensajes de arranque </li></ul></ul><ul><li>/var/log/kern.log </li></ul><ul><ul><li>mensajes generales del kernel </li></ul></ul><ul><li>/var/log/lastlog </li></ul><ul><ul><li>último login de cada usuario. Comando lastlog </li></ul></ul><ul><li>/var/log/mysql/ </li></ul><ul><ul><li>logs del servidor mysql </li></ul></ul>
  8. 8. otros logs <ul><li>/var/log/samba </li></ul><ul><ul><li>logs de SAMBA, muestra las conexiones realizadas a los recursos locales </li></ul></ul><ul><li>/var/log/syslog </li></ul><ul><ul><li>log general para los servicios que no eligen otro fichero para escribir </li></ul></ul><ul><li>/var/log/user.log </li></ul><ul><ul><li>Mensajes relacionados con las sesiones gráficas de usuario </li></ul></ul>
  9. 9. otros logs <ul><li>/var/log/XFree86.0.log </li></ul><ul><ul><li>logs del servidor gráfico, para saber la razón cuando éste no arranque </li></ul></ul>
  10. 10. Análisis forense <ul><li>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. </li></ul><ul><li>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. </li></ul>
  11. 11. Durante un ataque <ul><li>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. </li></ul><ul><li>Si no es posible hacerlo, lo mejor es denegar todo el tráfico desde la dirección del atacante: </li></ul><ul><ul><li>problema por no tener punto único de control -> si el ataque es sobre muchos clientes sería difícil pararlo a tiempo </li></ul></ul>
  12. 12. Durante un ataque <ul><li>Hay que bloquear la cuenta que el atacante usaba </li></ul><ul><li>A continuación debemos matar todos los procesos del usuario atacante y desconectarlos del sistema </li></ul><ul><li>Observar durante un rato para ver si el atacante vuelve a intentarlo, quizá desde otra dirección o con otros objetivos </li></ul>
  13. 13. Durante un ataque <ul><li>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. </li></ul><ul><ul><li>En los I.E.S., acercarte a donde sea a mirar </li></ul></ul><ul><ul><li>En los C.P.R., llamar por teléfono y pedir que comprueben quien está sentado en el puesto </li></ul></ul>
  14. 14. Análisis forense <ul><li>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 </li></ul><ul><ul><li>Comprobar que el puesto desde donde se han realizado es el que usa normalmente el usuario </li></ul></ul><ul><ul><li>Comprobar con los horarios y los profesores quien se sentaba en el puesto durante los actos </li></ul></ul>
  15. 15. Análisis forense <ul><li>Ejemplo: publicación de material indebido en el portal interno del centro por parte de un alumno </li></ul><ul><ul><li>Comprobamos, mediante el log de Apache, a que hora y desde que puesto se realizaron los comentarios </li></ul></ul><ul><ul><li>Comprobamos quien estaba conectado a esa hora en ese puesto, en el auth.log del cliente </li></ul></ul><ul><ul><li>El aula no coincide con la del usuario que estaba conectado, por lo que pensamos que puede haber un uso fraudulento de cuentas </li></ul></ul>
  16. 16. Análisis forense <ul><li>Ejemplo: publicación de material indebido en el portal interno del centro por parte de un alumno </li></ul><ul><ul><li>Comprobamos en el horario que profesor tenía clase en ese aula a esa hora </li></ul></ul><ul><ul><li>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 </li></ul></ul>
  17. 17. Análisis forense <ul><li>Ejemplo: publicación de material indebido en el portal interno del centro por parte de un alumno </li></ul><ul><ul><li>Si no hubiésemos obtenido la información gracias a los alumnos </li></ul></ul><ul><ul><ul><li>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 </li></ul></ul></ul><ul><ul><ul><li>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. </li></ul></ul></ul>
  18. 18. Después de un ataque <ul><li>Cerrar el agujero </li></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>Si no, comprueba todos los ficheros de logs buscando actividad cercana al momento del ataque, que pueda indicar cómo consiguió entrar el intruso </li></ul></ul>
  19. 19. Después de un ataque <ul><li>Comprobando el daño </li></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>Después de un ataque que obtiene privilegios de root -> reinstalar y recuperar los datos de los backups </li></ul></ul><ul><ul><li>Comprobar cuando comenzó el ataque, por si los backups pudiesen estar dañados </li></ul></ul>
  20. 20. Después de un ataque <ul><li>Copias de seguridad </li></ul><ul><ul><li>Hacer copias de seguridad regularmente ayuda con la seguridad, para restaurar los datos que pudiesen haber sido comprometidos </li></ul></ul><ul><ul><li>Comprobar varios backups antes de restaurar los datos, por si llevan modificados mucho tiempo </li></ul></ul><ul><ul><li>Mantener las copias de seguridad en un sitio seguro y separado del servidor </li></ul></ul>
  21. 21. Después de un ataque <ul><li>tripwire </li></ul><ul><ul><li>Herramienta de seguridad y integridad de los datos útil para monitorizar y alertar sobre determinados cambios en ficheros. </li></ul></ul><ul><ul><li>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. </li></ul></ul>
  22. 22. Después de un ataque <ul><li>tripwire </li></ul><ul><ul><li>El fichero de configuración especifica las opciones para el programa (directorios a revisar, nivel de alertas, etc ...) </li></ul></ul><ul><ul><li>El fichero de polica (POLICY) especifica que ficheros se van a controlar. </li></ul></ul><ul><ul><li>Inicialización de la BD: </li></ul></ul><ul><ul><ul><li>tripwire -m i -v </li></ul></ul></ul><ul><ul><ul><li>Se genera la base de datos </li></ul></ul></ul>
  23. 23. Después de un ataque <ul><li>tripwire </li></ul><ul><ul><li>Comprobación de la BD: </li></ul></ul><ul><ul><ul><li>tripwire -m c </li></ul></ul></ul><ul><ul><ul><li>Se va comprobando la integridad de todos los ficheros presentes en la BD </li></ul></ul></ul><ul><ul><ul><li>Se muestra por pantalla el informe y se guarda en el lugar indicado en el fichero de configuración </li></ul></ul></ul><ul><ul><ul><li>Para ver el informe almacenado: </li></ul></ul></ul><ul><ul><ul><ul><li># twprint -m r -r /var/lib/tripwire/report/ddprog.elbrocense.ex-20060519-124320.twr |less </li></ul></ul></ul></ul>
  24. 24. Después de un ataque <ul><li>tripwire </li></ul><ul><ul><li>Comprobación de la BD: </li></ul></ul><ul><ul><ul><li>tripwire -m c </li></ul></ul></ul><ul><ul><ul><li>Se va comprobando la integridad de todos los ficheros presentes en la BD </li></ul></ul></ul><ul><ul><ul><li>Se muestra por pantalla el informe y se guarda en el lugar indicado en el fichero de configuración </li></ul></ul></ul><ul><ul><ul><li>Para ver el informe almacenado: </li></ul></ul></ul><ul><ul><ul><ul><li># twprint -m r -r /var/lib/tripwire/report/ddprog.elbrocense.ex-20060519-124320.twr |less </li></ul></ul></ul></ul>
  25. 25. Después de un ataque <ul><li>tripwire </li></ul><ul><ul><li>Comprobación de la BD: </li></ul></ul><ul><ul><ul><li>Se muestra primero un resumen indicando los ficheros que han sido eliminados, modificados o añadidos desde que se creó la base de datos. </li></ul></ul></ul><ul><ul><ul><li>Posteriormente detalla cada uno de los problemas encontrados, para que podamos comprobarlos. </li></ul></ul></ul><ul><ul><ul><li>Cada vez que toquemos algo de lo que revisa tripwire, deberíamos actualizar la BD. </li></ul></ul></ul>
  26. 26. Después de un ataque <ul><li>tripwire </li></ul><ul><ul><li>Actualización de la BD </li></ul></ul><ul><ul><ul><li># tripwire -m u -r /var/lib/tripwire/report/ddprog.elbrocense.ex-20060519-124320.twr </li></ul></ul></ul><ul><ul><ul><li>Este modo permite reconciliar las diferencias entre la base de datos y el sistema actual. </li></ul></ul></ul><ul><ul><ul><li>El estado actual se obtiene del informe que le indiquemos </li></ul></ul></ul>
  27. 27. Después de un ataque <ul><li>tripwire </li></ul><ul><ul><li>Actualización de la BD </li></ul></ul><ul><ul><ul><li>Se abre el editor que tengamos configurado </li></ul></ul></ul><ul><ul><ul><li>Al lado de cada cambio en la BD aparece una marca [x] para indicar si queremos que el cambio se aplique o no. </li></ul></ul></ul><ul><ul><ul><li>Dejarlo marcado indica que queremos realizar el cambio. </li></ul></ul></ul>
  28. 28. Después de un ataque <ul><li>tripwire </li></ul><ul><ul><li>Actualización de la política </li></ul></ul><ul><ul><ul><li># tripwire -m p twpol2.txt </li></ul></ul></ul><ul><ul><ul><li>Modifica la política con el nuevo fichero de política indicado </li></ul></ul></ul><ul><ul><ul><li>Se obtiene un nuevo fichero binario de política a partir del fichero de texto </li></ul></ul></ul><ul><ul><ul><li>Se actualiza la BD conforme a la nueva política </li></ul></ul></ul>
  29. 29. Después de un ataque <ul><li>Identificar al atacante </li></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>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 </li></ul></ul>

×