![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.](https://image.slidesharecdn.com/cursoavanzadoseguridadlogs-1231840470283831-3/85/Curso-Avanzado-Seguridad-Logs-27-320.jpg)
Curso Avanzado Seguridad Logs
- 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