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

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

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

Из-за ограничений доступа к 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, а буквально понимая эксплойты сможете собственноручно провести пинтест.

Я всё ещё занимаюсь мазохизмом с visual studio и wine

Мазохизм зашёл очень далеко

Я сегодня буквально

Минутка юмора: существует способ "воскресить" старые проекты на базе .NET Framework 4.0 (ASP.NET 2.0) — буквально заставить велосипед шагать. Однако мигрировать на новые технологии всё равно необходимо, а отвергать такие предложения — лишь доказывать свою профнепригодность и становиться генератором технического долга

Существует дилемма обслуживания. С каждым месяцем поддержка программного обеспечения, написанного много лет назад, усложняется. И дело не только в том, что современные разработчики не будут целеустремлённо копаться в старом коде (который часто не следует принципам SOLID, из-за чего даже попытка "поправить чуть-чуть" превращается в сущий ужас), но и в том, что изучать особенности этого стека приходится по "наскальным надписям" — старым форумам 20–25-летней давности, которые дотянули до наших дней..

Официальные разработчики даже встают стеной и говорят: "Извините, оно морально устарело. Будьте любезны, ознакомьтесь с новыми технологиями". Но увы, есть те, кто по сей день называет технологии 10–15-летней давности (уже ставшими де-факто стандартами индустрии) "модными"

Исследователи Cyera сообщают, что все версии OpenSSH, выпущенные за последние 15 лет, подвержены уязвимости, приводящей к получению полного доступа к корневой оболочке, а атаки невозможно обнаружить с помощью анализа логов.

Уязвимость отслеживается как CVE-2026-35414 (CVSS 8.1) и описывается как некорректная обработка параметра authorized_keys principals в определенных сценариях, связанных с центрами сертификации (CA), использующими символы запятой.

По данным Cyera, из-за этой ошибки запятая в имени основного сертификата SSH приводит к обходу контроля доступа OpenSSH, позволяя пользователям аутентифицироваться как root на уязвимом сервере, при условии наличия у них действительного сертификата от доверенного центра сертификации.

Уязвимость заключается в ошибке повторного использования кода, из-за которой простая запятая в основном сертификате была случайно интерпретирована парсером как разделитель списка, в результате чего учетная запись с низкими привилегиями превратилась в корневые учетные данные.

Сервер считает аутентификацию легитимной, а это значит, что данная атака не регистрирует сбой аутентификации в журналах, что делает обнаружение на основе журналов крайне ненадежным.

Как поясняет Cyera, CVE-2026-35414 затрагивает список субъектов, который включает имена пользователей, под которыми владелец сертификата может проходить аутентификацию, и субъекты authorized_keys, содержащие ключи, используемые серверами для подтверждения доверия к сертификатам.

Проблема заключается в том, что функция, обрабатывающая согласование списков шифров и ключей для обмена, сравнивает разделенные запятыми списки шифров во время обмена ключами, разделяет их по запятой и включает аутентификацию, если хотя бы один из фрагментов совпадает со значением субъекта.

Так что если сертификат содержит имя principaldeploy, root, OpenSSH разделяет запятую и предоставляет полный доступ с правами root.

Вторая функция, которая также проверяет авторизацию, рассматривает тот же субъект как единую строку и запрещает доступ. Однако, если строка совпадает, последующие параметры приводят к тому, что проверка субъекта полностью пропускается.

По данным Cyera, успешная эксплуатация уязвимости может предоставить злоумышленнику корневой доступ ко всем серверам организации, если на них запущен уязвимый протокол.

CVE-2026-35414 была устранена в начале апреля в версии OpenSSH 10.3, в связи с чем рекомендуется провести аудит сред и как можно скорее обновиться до исправленной версии.

вспоминаю kaurcev.space и возникает чувство ностальгии.

1 мая могло бы исполниться 3 года с момента запуска