Пожалуй один из тех постов на хабре, который заслуживает внимания, отчасти.

Информация хоть и довольно обычная, я б сказал "базированная", но как таковых проблем не решает.
Просто пункт — детализация, а к итогу сверка всего и решение: "пора менять компанию".

А вот кстати сам пост

Из-за ограничений доступа к api.telegram.org с территории РФ некоторые боты могут перестать работать. Если ваш проект столкнулся с этой проблемой, можно использовать простой реверс-прокси на Node.js, который перенаправляет запросы к Telegram API.

Как это работает

· Если у вас нет сервера за границей, можно воспользоваться бесплатным хостингом render.com.
· Скопируйте репозиторий, разверните приложение — получите URL, который затем подставляете вместо официального API в вашу библиотеку (Telegraf, aiogram и аналоги).

Особенности прокси

· Прозрачная передача запросов с подменой заголовков и корректной обработкой TLS.
· В консоль выводятся логи: какой запрос отправлен ([PROXYING]) и какой ответ получен от Telegram ([TG_RESPONSE]).
· При сбое соединения с Telegram возвращается ответ Proxy Error, сам прокси продолжает работу.

Ссылка на репозиторий
Код и инструкция по развёртыванию:
https://github.com/kaurcev/kadev-moment-telegram-not-work

Но отмечу, если уж взялись за render, то там надо его пинговать каждые 10 минут в идеале, так как сервера на бесплатном тарифе засыпают

сегодня нашлось время чтобы обеспечить настройки сервера.

сегодня выстроил архитектуру (докер контейнеры в изоляции, проброс портов на локалхост сервера и вывод через nginx на портах 80 и 443.

там же настроил базовые механизмы безопасности, ограничения по количеству запросов в секунду (429 ответ если будете брутфорсить), ограничил доступ к информации разворачиваемой инфраструктуры (кроме nginx вы ничего не узнаете)..

ещё настроил fail2ban который будет мониторить частые ошибки 429 и 403, после чего будет отправлять пользователей в бан на 2 часа на уровне itables

а вот про ssh я ничего не скажу

Вообще сейчас посмотрим на артефакты и уже после пойдем в QEMU где можно будет побаловаться.

Но напомню, вы, как разработчик, отвечаете за системную безопасность и выбор стека критически важен при разработке программного обеспечения.

Этот инструмент морально устарел и данный момент (и не один год, не пару лет) не поддерживается. Это значит то что специфичные действия способны вызвать не просто падение ПО, но и склонность к утечкам и т.д.

И да, все равно пишу для просвещения, ASLR (рандомизация адресного пространства) или DEP (предотвращение выполнения данных) там были реализованы иначе, а то вовсе слабее.

Старый стек просто не умеет использовать современные фишки безопасности ОС

И даже если вы идеально спроектируете ПО (по всем канонам), оно все равно не будет соответствовать безопасности, не просто по меркам с какой-нибудь очередного cve.org, nvd.nist.gov или www.cvedetails.com, а буквально понимая эксплойты сможете собственноручно провести пинтест.