Hola Quincy @ossia
Hagamos una pausa rápida y analicemos esto desde una perspectiva profesional de ciberseguridad, sin especulaciones ni intentos de “agarrarse a pajas”.
El concepto clave en todas las tareas de ciberseguridad es la “conciencia situacional”; en este caso, se denomina “conciencia situacional cibernética” (CSA).
Para saber “qué está sucediendo” de manera definitiva, debes desarrollar el mejor conocimiento situacional posible, sin especulaciones ni suposiciones. Solo los hechos.
¿Cómo se hace esto?
Bueno, muy brevemente:
Bueno, muy brevemente:
Lo hacemos fusionando información de todos nuestros sensores. Para las aplicaciones basadas en la web, esto normalmente proviene de los archivos de registro y los datos de sesión. No creo (por lo que recuerdo) que Discourse mantenga información de sesión en la base de datos PG (la última vez que revisé no había una tabla de sesiones como en algunas aplicaciones web LAMP), pero eso no es un obstáculo en absoluto.
Tienes casi todo lo necesario en los archivos de registro de nginx tanto para tu proxy inverso fuera del contenedor (recuerdo haber leído en este tema que estabas usando nginx como proxy) como la misma información de registro dentro del contenedor. En ambos casos, el archivo de registro se encuentra aquí, en la configuración estándar OOTB:
Aquí hay un ejemplo en una de nuestras configuraciones (fuera del contenedor) para el proxy inverso:
# cd /var/log/nginx
# ls -l
total 779964
-rw-r----- 1 www-data adm 0 Jun 17 06:25 access.log
-rw-r----- 1 www-data adm 660766201 Jun 25 18:26 access.log.1
-rw-r----- 1 www-data adm 107367317 Jun 17 03:18 access.log.2.gz
-rw-r----- 1 www-data adm 21890638 May 21 03:08 access.log.3.gz
-rw-r----- 1 www-data adm 7414232 May 5 07:26 access.log.4.gz
-rw-r----- 1 www-data adm 63289 Apr 18 09:12 access.log.5.gz
-rw-r----- 1 www-data adm 0 Jun 17 06:25 error.log
-rw-r----- 1 www-data adm 904864 Jun 25 18:19 error.log.1
-rw-r----- 1 www-data adm 96255 Jun 17 03:17 error.log.2.gz
-rw-r----- 1 www-data adm 79065 May 21 02:58 error.log.3.gz
-rw-r----- 1 www-data adm 70799 May 5 06:54 error.log.4.gz
-rw-r----- 1 www-data adm 1977 Apr 18 05:49 error.log.5.gz
Aquí está la misma información básica de registro dentro del contenedor de Discourse:
# cd /var/discourse/
# ./launcher enter socket
# cd /var/log/nginx
# ls -l
total 215440
-rw-r--r-- 1 www-data www-data 87002396 Jun 25 18:28 access.log
-rw-r--r-- 1 www-data www-data 101014650 Jun 25 08:02 access.log.1
-rw-r--r-- 1 www-data www-data 8217731 Jun 24 08:02 access.log.2.gz
-rw-r--r-- 1 www-data www-data 6972317 Jun 23 07:53 access.log.3.gz
-rw-r--r-- 1 www-data www-data 3136381 Jun 22 07:50 access.log.4.gz
-rw-r--r-- 1 www-data www-data 2661418 Jun 21 07:45 access.log.5.gz
-rw-r--r-- 1 www-data www-data 5098097 Jun 20 07:38 access.log.6.gz
-rw-r--r-- 1 www-data www-data 6461672 Jun 19 07:40 access.log.7.gz
-rw-r--r-- 1 www-data www-data 0 Jun 25 08:02 error.log
-rw-r--r-- 1 www-data www-data 0 Jun 24 08:02 error.log.1
-rw-r--r-- 1 www-data www-data 20 Jun 23 07:53 error.log.2.gz
-rw-r--r-- 1 www-data www-data 254 Jun 23 02:36 error.log.3.gz
-rw-r--r-- 1 www-data www-data 20 Jun 21 07:45 error.log.4.gz
-rw-r--r-- 1 www-data www-data 20 Jun 20 07:38 error.log.5.gz
-rw-r--r-- 1 www-data www-data 20 Jun 19 07:40 error.log.6.gz
-rw-r--r-- 1 www-data www-data 274 Jun 18 15:40 error.log.7.gz
Nota: Esa información “dentro del contenedor” también está disponible desde fuera del contenedor en el volumen compartido.
Por lo tanto (y para mantener esta respuesta breve), @ossia, casi todo lo que necesitas para obtener conocimiento situacional de lo que está sucediendo está en estos robustos archivos de registro. No es necesaria ninguna especulación. Los datos están todos ahí.
Incluso hay más datos excelentes disponibles en el registro de Rails, por ejemplo. En una de nuestras configuraciones, este es el registro de producción de Rails:
tail -f /var/discourse/shared/socket/log/rails/production.log
El registro de Rails también tiene mucha información de registro de usuarios, por ejemplo:
Started GET "/embed/comments?topic_id=378686" for 73.63.114.60 at 2020-06-25 18:36:15 +0000
Started GET "/embed/comments?topic_id=378686" for 195.184.106.202 at 2020-06-25 18:36:16 +0000
Started GET "/embed/comments?topic_id=378686" for 17.150.212.174 at 2020-06-25 18:36:16 +0000
Started GET "/embed/comments?topic_id=378686" for 76.235.99.73 at 2020-06-25 18:36:18 +0000
Started GET "/embed/comments?topic_id=378686" for 124.253.211.42 at 2020-06-25 18:36:19 +0000
Started GET "/embed/comments?topic_id=378686" for 103.96.30.11 at 2020-06-25 18:36:21 +0000
Started GET "/embed/comments?topic_id=378686" for 72.191.206.59 at 2020-06-25 18:36:22 +0000
Started GET "/embed/comments?topic_id=378686" for 68.252.68.76 at 2020-06-25 18:36:23 +0000
Started GET "/embed/comments?topic_id=378686" for 69.17.252.83 at 2020-06-25 18:36:23 +0000
Started GET "/embed/comments?topic_id=378686" for 98.109.33.230 at 2020-06-25 18:36:24 +0000
Nota: Aquí (arriba, como ejemplo) vemos las direcciones IP de los clientes que extraen el código incrustado de Discourse desde otro servidor.
La tarea en cuestión....
Volviendo a la tarea en cuestión, el “truco” es superar la especulación y las suposiciones, y realizar la divertida (1) filtración/limpieza de datos, (2) fusión de datos y (3) análisis de tus datos de sensores (archivos de registro) para crear (4) la conciencia situacional (SA) de lo que está sucediendo en tu sitio.
Para aplicaciones LAMP más antiguas, tengo código personalizado que escribí hace años, el cual escribe toda esta información en una tabla de base de datos y realiza el análisis en tiempo real, contando los “accesos” por dirección IP (como un ejemplo), donde puedo ver rápidamente qué, quién y desde dónde está accediendo al sitio, ya que se requiere cierto código para realizar este tipo de limpieza, filtrado y fusión de datos. (Útil durante ataques DDOS y actividad de bots maliciosos, por ejemplo).
Eso no es un problema para ti, @ossia, porque eres freeCodeCamp.org, por lo que tienes tanto el conocimiento para encontrar excelentes herramientas de análisis de archivos de registro (hay muchas en el ciberuniverso) y/o crear tu propio código personalizado para realizar el análisis de manera rápida y sencilla según el escenario que desees comprender (tu tema y problema).
Escribí mi código personalizado para una antigua aplicación LAMP heredada en unas pocas horas hace muchos años, y no soy un genio de la programación en absoluto, aunque a veces me llaman una “leyenda” en el campo de la ciberseguridad, LOL 
Para resumir....
Bueno, para resumir…
Tienes todos los datos necesarios para crear un conocimiento situacional profundo de “qué está pasando” en tu sitio, y puedes crear esa SA limpiando, filtrando, fusionando y realizando un análisis básico de los datos de tus archivos de registro. Existen herramientas que pueden ayudar, pero siempre encuentro más fácil escribir algo de código personalizado basado en el objetivo del análisis (análisis dependiente), YMMV. Pero puedes hacerlo fácilmente porque eres freeCodeCamp.org y tienes muchas habilidades técnicas.
Te recomiendo que te alejes de intentar obtener SA a partir de Google Analytics y otras aplicaciones de terceros basadas en JS. Nada es mejor que tus propios archivos de registro web (y datos de sesión de la base de datos si los tienes) y no tienes que preocuparte por “qué puede o no estar bloqueado”, etc. Tus archivos de registro del servidor web contienen los datos necesarios para obtener la CSA que necesitas (y también pueden personalizarse cuando sea necesario).
En parte de mi código de CSA, en realidad intercepto la información de sesión y la información de registro de las solicitudes HTTP que no registran nginx, apache2 y otros servidores web (para información adicional); pero aún no he escrito este tipo de código para Discourse, ya que no soy tan “fácil como el pastel” en el desarrollo de plugins de Discourse (como los gurús del equipo de meta Discourse aquí) como lo soy con aplicaciones LAMP, ya que solo comencé con Discourse hace unos meses y aún no he escrito ningún código personalizado de CSA para Discourse (y tratando de programar menos este año, para ser honesto).
La CSA se basa en la fusión de datos de sensores y, a partir de la CSA, surge el conocimiento necesario para comprender qué acciones debes tomar para remediar cualquier problema de ciberseguridad.
¡Mucha suerte en tu búsqueda y espero que esto te ayude a descansar más :slight_smile!
¡Saludos!
Referencia original (histórica) de CSA:
Referencia original (histórica) de CSA:
https://www.researchgate.net/publication/220420389_Intrusion_Detection_Systems_and_Multisensor_Data_Fusion
(Solo referencia para personas interesadas en los orígenes y la tecnología central de la CSA)
