Вадим

Решение, которое позволит поднять стоимость реверса Вашего приложения до неприличного значения:
1. Обфусцируем код через https://github.com/dashingsoft/pyarmor .
2. Перегоняем п1. через https://github.com/Nuitka/Nuitka в сишный код.
3. Компилим п2. в машинный код.
4. Запускаем п3. exe-шник на клиенте.

Получаем:
1. Увеличение производительности.
2. Exe-шник из машинного кода.

Ну для начала что значит "атака"? Какую угрозу ты ожидаешь? Потому что ответы будут ОЧЕНЬ разные в зависимости от этого.

IP бота можно будет попробовать узнать, если ты знаешь, что бот проходит по ссылкам, которые ты можешь ему отправить. Тогда, скинув боту ссылку на свой сайт, можно будет посмотреть, какие адреса заходили в этот момент.
Если бот такого не делает, то скорее всего никак.

Зафлудить бота запросами? С одного аккаунта не получится, а с многих - недёшево. Кому ты нужен за такие деньги?

Потыкать команды бота на пример SQL-инъекции? Если бот вообще использует БД, достаточно использовать стандартные средства подстановки параметров в запросы, а не колхозить SQL чере зформатирование строк.

Угнать бота? Не пости его токен никуда. Если хранишь исходный код в какой-то системе хранения версий - храни токен в отдельном файле и добавь его в исключения. Если есть подозрение, что токен уже уплыл - меняй его у BotFather. А угон акка разработчика - это другая песня уже.

Короче, ответь хотя бы для себя на вопросы:
1. чего конкретно боишься?
2. кому конкретно ты нужен?

1.Использование одного образа для разных сервисов: В вашем файле docker-compose.yml все три сервиса (app, webserver и db) используют один и тот же образ cubinez85/docker_compose/web:latest. Это неправильно, так как каждый из этих сервисов должен иметь свой образ, настроенный для конкретной задачи.

2.Конфигурация NGINX: Если ваш NGINX не настроен правильно, он не сможет перенаправлять запросы на PHP контейнер. Вам нужно удостовериться, что конфигурация NGINX правильно перенаправляет запросы на fastcgi_pass адрес вашего PHP контейнера.

3.Настройка PHP-FPM: Убедитесь, что PHP-FPM в вашем app контейнере настроен для прослушивания соединений (обычно это делается с помощью listen = 9000 в файле www.conf).

Измените docker-compose.yml:

version: '3.7'
services:
    app:
        build: ${PWD}/fpm/
        image: cubinez85/docker_compose/app:latest
        container_name: app
        volumes:
            - ${PWD}/code:/data
        networks:
            - app-network

    webserver:
        build: ${PWD}/nginx/
        image: cubinez85/docker_compose/nginx:latest
        container_name: webserver
        volumes:
            - ${PWD}/code:/data
        ports:
            - "80:80"
            - "443:443"
        networks:
            - app-network

    db:
        image: mysql:latest
        container_name: db
        ports:
            - "3306:3306"
        environment:
            MYSQL_DATABASE: ${MYSQL_DATABASE}
            MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
        volumes:
            - ${PWD}/dbdata:/var/lib/mysql
        networks:
            - app-network

networks:
    app-network:
        driver: bridge

Убедитесь что в nginx.conf есть что-то вроде:

location ~ \.php$ {
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    fastcgi_pass app:9000;
    ...
}

Здесь app:9000 указывает на ваш PHP контейнер и порт 9000, который слушает PHP-FPM.

В данном случае это оправдано.
Кали по сути дебиан, только знающие люди собрали для вас нужные инструменты, ну и это отраслевой стандарт.

Есть два варианта:
1. Экранировать обратным слешем проблемные символы (кавычки и обратный слеш):

multiline = '''
report_number=$(head -n 1 "/root/cron_job_enumerator.txt" | tr -d \'\\n\')
'''
print(multiline)

2. использовать префикс строк r, который не дает обрабатывать содержимое строки, заставляет воспринимать ее как есть (тогда отдельные символы экранировать не надо):

multiline = r'''
report_number=$(head -n 1 "/root/cron_job_enumerator.txt" | tr -d '\n')
'''
print(multiline)

Добавь заголовки запроса, в качестве реферера поставь тот же URL.
Как это сделать, читай в доках requests.

Поздравляю с Майнером, система однозначно была скомпрометирована, вот гайд по устранению этого майнера: https://habr.com/ru/articles/582830/
А вообще лучше снести систему и накатить все по новой, скорее всего вы не заметили но базу вашу почистили создали там таблицу read me с просьбой пополнить криптокошелек и тогда восстановят данные, если это продовый сервер то мониторьте каналы ТГ по сливам на наличие ваших данных в сливах.
Удачи вам, и закрытых портов для ваших сервисов)

Смотри. Уже прошло время когда все пилили монолиты на микросервисы. Щас пошло переосмысление.
Объективно есть 2 причины пилить. Первое - организационная. Команда по какой-то причине не хочет
или не может поддерживать приложение. Или там что-то с бизнесом. Слияние. Поглощение. Передача
проекта другой команде в поддержку. Тогда берут и ставят задачу раздела отвественностей.
Конвей про это писал еще.

И второе - это баланс нагрузки и децентрализация. Про failover тут еще даже речи нет. Это
тяжелая тема и распилить монолит так чтобы его части были отказоустойчивы очень трудно. Более
того в случае синхронных взаимодействий между частями микросервисов может быть даже падение
перформанса. Да. Теоретики которые там пишут восторженные отзывы - совершенно игнорируют
накладные на RPC. И не упоминают что в монолите цена RPC была равна нулю. Иногда RPC заменяют
на MQ - но это новая архитектура и это надо полностью переделывать бизнес.

И что делать с базой данных? Это тот еще вопрос. Я почти готов спорить что вы базу пилить не будете.
И что в результате будет? Иммитация микро-сервисов? Где слабая связность?

Тоесть если у вас нет таких кричащих ситуаций что оргазниация требует или нужно баланс
нагрузки как-то разнести - то тебе вообще-вообще нет смысла ходить ни в какие микросервисы.

Но имеет смысл сделать модуляризацию монолита. Например что там...

application
- sales
- hiring
- userprofiles

Тоже очень полезно для управления сложностью. И пускай себе будет монолит зато будет сильный
контроль за изменениями.

В крон на 00:00 добавляете запуск

/usr/bin/sleep $((`/usr/bin/od -An -N2 -t u2 /dev/random` % 3600)) && ваша_задача

Директория app находится на два уровня выше директории php в которой размещён Dockerfile - поменяй путь в директиве COPY
И WORKDIR /app создаёт директорию и делает её текущей, так что должно быть COPY ../../app .

PS
Никогда не используй Alpine образы ни для чего - этот дистрибутив оптимизирован для встраевыемых устройств с единицами мегабайт оперативной памяти и процессором с одним ядром, там вместо libc использован суррогат musl с неэффективным на б̀ольших объёмах памяти аллокатором, к тому же она не так сильно распростронена, как libc, что увеличивает вероятность столкнуться с чем нибудь вроде segmentation fault. К тому же часть пакетов в собранном виде отсутствует из-за чего во время установки происходит их сборка, что занимает значительное время, да и образ в итоге получается очень большим (компилятор то никто не умеет настраивать)

Используй debian-slim и PHP устанавливай из Sury репозитория - установка произойдёт очень быстро, а итоговый образ будет компактным (если, конечно, не забывать стирать списки пакетов и кеши на том же слое, где они были созданы)

PPS

# Remove Cache
RUN rm -rf /var/cache/apk/*

Удалять что либо на следующем слое бесполезно - там Copy on Write файловай система и всё что было на предыдущем слое создано там и останется