Enviado por juanonlab el Lun, 06/07/2020 - 16:24
Kibana informes

En la entrada anterior traté la instalación de Elasticsearch en una máquina Linux Ubuntu. Ahora que ya se encuentra instalado el motor Elasticsearch junto filebeat y kibana voy a proceder a explicar de manera sencilla como sacar provecho de estas herramientas.

Elasticsearch es un motor muy versátil que puede usarse para gran cantidad de proyectos. En mi caso voy a aprovecharlo para realizar un monitoreo básico de mi servidor web. Cómo he comentado en otras ocasiones se requieren de unos mínimos conocimientos de seguridad para mantener tu servidor a salvo de intrusos. El lema que se podría utilizar es: "no se lo pongas fácil".

La aplicación filebeat va a enviar los logs del sistema linux y los logs de mis servidores web (Nginx y Apache) al motor Elasticsearch. Una vez guardada la información vamos a poder interpretar y/o analizar los datos mediante informes en Kibana.

Accediendo a los Dashboards de Kibana

Cómo no quiero realizar una entrada muy larga en la siguiente captura se muestran los dos informes que he utilizado para hacer un análisis rápido de mi servidor. No voy a explicar todo el proceso de modificación de dashboard porque quedaría una entrada demasiado larga.

Desde Kibana y basándome en dashboards ya creados he realizado 2 informes personalizados. Los dashboards se componen de diferentes visualizaciones. Cada visualización analiza los datos de manera distinta mostrando una gráfica, un lista de llamadas, información geográfica etc.

Dashboards personalizados

Mediante el criterio de búsqueda "jl" se obtienen mis dashboards:

  • Accesos por SSH: me permite investigar el tipo de intentos de conexión que realizan personas/máquinas desde distintos países. 
  • Tráfico Nginx: me permite analizar todas las llamadas que se realizan a partir de mi servidor Nginx. Este blog corre sobre Apache y tengo el servidor Nginx como proxy inverso y contiene también contenido estático. Nginx es el punto de entrada de todo el tráfico web que llega al servidor.

Voy a dar una descripción rápida de cada dashboard para que se pueda comprobar lo fácil que resulta realizar un análisis ligero de tu servidor utilizando estas tecnologías.

 

Accesos por SSH Dashboard

Este informe personalizado me permite identificar si ha habido accesos no autorizados y si estoy recibiendo algún tipo de llamada persistente desde algún país o IP concreta. Sobre todo la utilizo para investigar que nadie ha entrado a mi servidor. Te permite revisar además la fecha de acceso y que comandos sudo se han lanzado durante los días de filtrado. En la captura siguiente se muestra información de 20 días hacia atrás.

Se puede filtrar no sólo por fecha si no por un rango concreto o incluso por horas.

Accesos SSH

SSH login attempts

Es una gráfica que te indica el número de intentos de acceso. Está agrupada por 12 horas. Como mínimo hay unas 1800 peticiones de acceso cada 12 horas lo que me parece increíble. Hay algún pico de más de 2000 accesos. Por ello es muy importante utilizar contraseñas fuertes para que no puedan entrar a nuestro sistema. Antes de instalar la herramienta de Elasticsearch no era consciente del número de intentos de acceso por SSH que se producían. Mi proveedor dispone de un sistema que banea la IP si se realizan muchas peticiones seguidas para dar más seguridad a mi servidor. 

No disponer de algún sistema de control de ataques DoS o control de acceso es muy peligroso. En este caso mi proveedor se encarga de todos estos asuntos.

Login Attempts

Successful SSH logins

Es una de las gráficas más importantes. Suelo recordar cuando entro a mi servidor para realizar alguna tarea de mantenimiento. Si en alguna de las fechas que marca el gráfico yo no recuerdo haber entrado quizás deba analizar si alguien ha entrado a mi servidor. Aunque no lo vamos a ver normalmente cuando entran en tu servidor una de las primeras acciones que se realiza es la de añadir/cambiar usuarios y grupos luego hay que revisar esa gráfica también.

En esta gráfica se observa que no he entrado mucho en mi servidor en los días filtrados.

Success Login SSH

SSH users of failed login attempts

Se muestra también una nube de usuarios utilizados para el intento de acceso. Como se puede comprobar el usuario root es el más habitual para realizar el ataque ya que si entras como root al sistema tienes control total. Como curiosidad se ha intentado acceder a través del usuario ec2-user que es un usuario propio de AWS. Supongo que serán bots que utilizan usuarios y contraseñas comunes para comprobar si pueden entrar a las máquinas de la manera más sencilla.

SSH Cloud User

SSH failed login attempts source locations

Es sorprendente el número de intentos de accesos que se han producido hacia mi servidor durante 20 días. Si se observa bien la imagen, desde Asia, hay un punto naranja y otro granate indicando que se han realizado un gran número de intentos de accesos consecutivos. Os puedo asegurar que ¡yo no me he movido de España!

SSH Locations

SSH login attempts

Finalmente se dispone de una visualización que permite ver en detalle la IP del intento de conexión. En la captura se muestran intentos de conexiones desde Bangladesh, India y China. Estos dos últimos países como se pudo comprobar en la gráfica geográfica intentaban entrar a mi sistema multitud de veces. Desde esta visualización se puede hacer filtrado simple por país por ejemplo.

SSH Login User Info

Tráfico Nginx Dashboard

Este informe me permite ver de manera rápida el número de visitas via web que está recibiendo mi servidor. Como comenté anteriormente algunas aplicaciones se encuentran en un servidor Apache virtual por un puerto concreto pero la puerta de entrada siempre será por mi servidor Nginx. Dispongo de contenido web en Nginx y también en Apache (Nginx actúa en ese caso como proxy inverso). En la captura siguiente se puede ver una serie de visualizaciones: por zona geográfica, por uso de sistemas operativos y una linea temporal de sitios más visitados. No se ve en la captura el de número de visitas por páginas globales pero lo explicaré después.

Tráfico nginx

Uso de filtros

Un asunto que no he mencionado es el uso de filtros. ¿Por qué uso filtros? Porque hay ciertos accesos web que no quiero que aparezcan en mis informes. Por ejemplo, el acceso directo de kibana (al que yo solo tengo acceso). También accesos a páginas de Drupal que no quiero que aparezcan en las estadísticas. En la siguiente captura se puede ver los filtros que he creado:

Filtros

Los filtros los he escrito de manera manual. Hay una documentación en Elasticsearch para realizar el filtrado de la información que quieres obtener. Dejo un enlace sobre el uso de filtros en Elasticsearch.

Por ejemplo, si no quiero nada relacionado con kibana el filtro sería:

Custom Filter

Todo lo que lleve la palabra kibana en adelante queda excluido del informe. Para ello se le añade NOT y que cumpla así con el comportamiento deseado.

 

Access Map

Este informe muestra el número de accesos por país. Siendo una página escrita en español deberían haber bastante visitas de España y América del Sur pero se observa mucho tráfico de la región de Asia.

Por pais

Sistemas operativos

En esta visualización se muestran las visitas organizadas por sistemas operativos utilizados. La plataforma Windows y en particular Windows 10 es la más utilizada.

Sistemas operativos

Accesos nginx (linea temporal)

Quizás una de las visualizaciones más interesantes. Esta me permite analizar algún comportamiento anómalo de las visitas de mi blog o a otras aplicaciones. Me he fijado en 4 páginas para que veáis un ejemplo de análisis ligero que he hecho:

1- Intento de acceso a la página phpmyadmin

2- Intento de acceso a la página phpmyadmin con más atributos

3- Intentos de escribir comentarios

4- Acceso a la dirección raíz de mi web

Los números 1,2 y 3 son intentos de accesos a mi sistema mediante la web. Digamos que son ataques ligeros probablemente realizados por bots. Los intentos del tipo 1 y 2 quieren acceder a través de la página phpmyadmin. Entiendo que un bot meterá las contraseñas más habituales. ¡Pero yo no tengo instalado phpmyadmin!. El número 3 son bots que intentan insertar comentarios en las entradas que tengo en mi blog. Ahora dispongo de herramientas como recaptcha para evitar este spam aunque no lo evito al 100%. 

El número 4 sirve de ejemplo para que se vea el número de accesos a mi dirección raíz.

Analisis

En la siguiente captura se muestran los ataques para intentar acceder a la página phpmyadmin (que recordemos no existe). En ese pico se señala que ha habido 100 llamadas en una hora. Si se observan los otros dos picos se puede ver que también son de 100 llamadas lo que indica cierta automatización en el proceso.

Análisis pico phpmyadmin

En la siguiente captura se muestra como se ha realizado una acción parecida pero el bot, en esta ocasión, ha añadido por parámetro el usuario y la contraseña.

Análisis pico phpmyadmin con login password

Como se puede observar de una manera rápida se pueden buscar picos de llamadas raros en los últimos días de visitas a mi servidor. Elasticsearch posee herramientas muy avanzadas para automatizar este tipo de análisis pero no he profundizado en este aspecto.

Accesos Nginx Top N

La última visualización da un resultado numérico de visitas en un rango de tiempo seleccionado. Me permite ver (quitando los intentos de accesos de bots y usando los filtros) que páginas tienen interés para el público. En muchas ocasiones un incremento de ciertas visitas tiene relación con una mejora en el posicionamiento otorgado por el buscador Google.

Top N búsquedas

Elasticsearch es mucho más de lo que he mostrado. La intención de esta entrada es que se puedan ver las posibilidades de este motor de búsqueda y todas las aplicaciones que la rodean.

En mi caso con filebeat puedo tener un control ligero sobre el tráfico que llega a mi servidor. Dejo un enlace con los dashboards y las visualizaciones que he creado:

En su página web se dispone de mucha información para poder trabajar con Elasticsearch.

Añadir nuevo comentario

This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.