Привет, Квинси @ossia
Давайте на секунцу отступим назад и посмотрим на это с профессиональной точки зрения кибербезопасности, без спекуляций и попыток «хвататься за соломинку».
Ключевое понятие во всех задачах кибербезопасности — это «осведомлённость о ситуации» (situational awareness), поэтому в данном случае речь идёт о «киберосведомлённости о ситуации» (CSA — Cyber Situational Awareness).
Чтобы точно знать, «что происходит», необходимо сформировать максимально полную картину ситуации, опираясь только на факты, без догадок и предположений.
Как это сделать?
Ну, очень кратко:
Ну, очень кратко:
Мы делаем это, объединяя информацию со всех наших датчиков. Для веб-приложений эта информация обычно поступает из файлов логов и данных сессий. Насколько я помню (без проверки), Discourse не хранит информацию о сессиях в базе данных PostgreSQL (в последний раз, когда я проверял, там не было таблицы сессий, как в некоторых LAMP-приложениях), но это совсем не критично.
У вас есть почти всё необходимое в файлах логов nginx как для обратного прокси-сервера вне контейнера (я помню, что в этой теме вы упоминали использование nginx в качестве прокси), так и для аналогичной информации внутри самого контейнера. В обоих случаях при стандартной настройке «из коробки» (OOTB) файлы логов находятся здесь:
Вот пример в одной из наших настроек (вне контейнера) для обратного прокси:
# 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
Вот та же базовая информация о логировании внутри контейнера 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
Примечание: Эта информация «внутри контейнера» также доступна извне контейнера на общем томе.
Следовательно (и чтобы не затягивать ответ), @ossia, почти всё необходимое для формирования осведомлённости о том, что происходит, содержится в этих надёжных файлах логов. Никаких спекуляций не требуется. Все данные уже там.
Ещё больше ценной информации доступно, например, в логах Rails. Вот пример лога production на одной из наших систем:
tail -f /var/discourse/shared/socket/log/rails/production.log
В логах Rails также содержится много полезной информации о действиях пользователей, например:
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
Примечание: Здесь (выше, в качестве примера) мы видим IP-адреса клиентов, запрашивающих встроенный код Discourse с другого сервера.
Задача, стоящая перед нами....
Вернёмся к текущей задаче. «Секрет» заключается в том, чтобы отбросить спекуляции и догадки, и заняться увлекательным процессом: (1) фильтрацией и очисткой данных, (2) объединением данных и (3) анализом информации с ваших датчиков (файлов логов), чтобы сформировать (4) осведомлённость о ситуации (SA — Situational Awareness) о том, что происходит на вашем сайте.
Для старых LAMP-приложений у меня есть собственный код, написанный много лет назад, который записывает всю эту информацию в таблицу базы данных и выполняет анализ в реальном времени, подсчитывая «хиты» по IP-адресам (в качестве одного из примеров). Это позволяет мне быстро видеть, что, кто и откуда атакует сайт, поскольку для такой очистки, фильтрации и объединения данных требуется написание кода. (Это полезно, например, при DDoS-атаках и активности вредоносных ботов).
Для вас, @ossia, это не проблема, так как вы являетесь freeCodeCamp.org, а значит, у вас есть как знания для поиска отличных инструментов анализа логов (их множество в киберпространстве), так и возможность написать собственный код для быстрого и простого анализа в зависимости от сценария, который вы хотите изучить (ваша тема и проблема).
Я написал свой собственный код для старого устаревшего LAMP-приложения за несколько часов много лет назад, и я отнюдь не гений программирования, как бы ни называли меня многие в сфере кибербезопасности «легендой», LOL 
Подводя итог....
Ну, подводя итог…
У вас есть все данные, необходимые для формирования глубокой осведомлённости о том, «что происходит» на вашем сайте. Вы можете создать эту SA, очистив, отфильтровав, объединив и проанализировав данные ваших файлов логов. Существуют инструменты, которые могут помочь, но я всегда считаю проще написать собственный код, исходя из целей анализа (зависимый анализ). Ваше мнение может отличаться (YMMV), но вы легко сможете это сделать, так как вы являетесь freeCodeCamp.org и обладаете множеством технических навыков.
Я рекомендую вам отказаться от попыток получить SA с помощью Google Analytics и других сторонних приложений на базе JavaScript. Ничто не лучше собственных файлов веб-логов (и данных сессий из БД, если они у вас есть), и вам не нужно беспокоиться о том, «что может или не может быть заблокировано» и т.д. Файлы логов вашего веб-сервера содержат данные, необходимые для получения требуемой CSA (и их также можно при необходимости настроить).
В некоторых из моих кодов CSA я фактически перехватываю информацию о сессиях и данные логирования из HTTP-запросов, которые не логируются nginx, apache2 и другими веб-серверами (для получения дополнительной информации); однако я ещё не писал такого кода для Discourse, так как я не настолько «прост, как пирог» в разработке плагинов для Discourse (как гуру команды meta Discourse здесь), как это было с LAMP-приложениями. Я начал работать с Discourse всего несколько месяцев назад и пока не написал никакого собственного кода CSA для него (и, честно говоря, в этом году стараюсь писать меньше кода).
CSA основана на объединении данных с датчиков, и именно из CSA проистекает знание, необходимое для понимания того, какие действия нужно предпринять для устранения любой проблемы кибербезопасности.
Всего наилучшего в ваших поисках, и надеюсь, это поможет вам спать спокойнее
Удачи!
Оригинальная (историческая) ссылка на CSA:
Оригинальная (историческая) ссылка на CSA:
https://www.researchgate.net/publication/220420389_Intrusion_Detection_Systems_and_Multisensor_Data_Fusion
(Ссылка только для тех, кто интересуется истоками и базовыми технологиями CSA)
панели инструментов