Hacker News Digest

Автор разместил свой личный сайт в сети Tor как скрытый сервис, доступный по .onion-адресу, который генерируется из открытого ключа и не требует DNS, сертификатов или раскрытия IP-адреса. Трафик шифруется end-to-end через сеть Tor, обеспечивая анонимность как пользователей, так и самого сервера — никакая сторона не может связать личность посетителя с его действиями или локацию хостинга.

Для настройки скрытого сервиса автор отредактировал файл /etc/tor/torrc, указав директорию для ключей и перенаправление порта 80 на локальный веб-сервер (127.0.0.1:8080). После перезагрузки Tor сгенерировал уникальный .onion-адрес, который был использован в конфигурации nginx для обслуживания статического сайта без TLS, поскольку шифрование обеспечивается Tor. Чтобы избежать перенаправления на clearnet-домен, сайт собирается дважды: один раз для обычного веба, второй — с базовым URL, равным .onion-адресом, используя Hugo с флагом --baseURL. Этот процесс автоматизирован в пайплайне деплоя через GitHub Actions, который синхронно обновляет обе версии сайта. Оба варианта — clearnet и Tor — поддерживаются в актуальном состоянии без ручного вмешательства. Сайт доступен в сети Tor по адресу dhevt6e4rtgbtr3jh53xrpwmgtilkah6nyjujocsspssrsexc7omxhid.onion.

Размещение сайта в Tor реально, но требует ряда оптимизаций. Чтобы снизить нагрузку на соединения и компенсировать низкую пропускную способность, рекомендуется минимизировать HTTP-запросы, использовать серверный рендеринг, CSS-анимации и встраивать мелкие ресурсы через base64. Для ускорения загрузки можно внедрить HTTP/2 и HTTPS-сертификат. Технические рекомендации: — Добавить заголовок Onion-Location на clearnet-версию для автоматического предложения .onion-адреса в Tor Browser. — Привязывать HiddenServicePort к Unix-сокету или нестандартному локальному IP (не 127.0.0.1), чтобы упростить развертывание нескольких сайтов и избежать случайного доступа. — Обязательно резервировать приватный ключ сервиса, иначе при его потере придется менять адрес. — Не совмещать роль скрытого сервиса с ролью exit-ноды из соображений безопасности. Безопасность и доступность: — Против DDoS в Tor часто применяют двойные капчи. — Для защиты от фронтинга следует использовать уникальные заголовки и отдельные домены. — После перезапуска сервиса возможны задержки в доступности; рекомендуется использовать мосты (obfs4, snowflake) и fallback-механизмы. — v3-адреса длинные, а высокая латентность сети делает предпочтительным использование статического контента. Особенности и альтернативы: — Отсутствие DNS, сертификатов и публичного IP усложняет, но не исключает возможность деанонимизации сервиса государственными агентствами. — В качестве альтернатив с иными компромиссами по скорости и анонимности можно рассмотреть I2P и Yggdrasil.

Go позволяет использовать путь импорта как адрес для загрузки кода, что упрощает распространение библиотек без централизованного репозитория. Однако привязка импорта к конкретному хостингу вроде GitHub создаёт жёсткую зависимость: при миграции на GitLab или другой сервис приходится менять все импорты в коде, что становится непрактичным и дорогостоящим. Автор приводит пример компании, которая вынуждена была одновременно платить за три хостинга, потому что изменение путей импорта требовало слишком много усилий.

Решение — использовать собственный домен (например, go.iain.rocks) для пространства имён Go. На этом домене настраивается веб-сервер, который при запросе с параметром ?go-get=1 отдаёт HTML-файл с мета-тегами go-import и go-source, указывающими на реальный репозиторий. Для обычных посетителей настроен редирект на GitHub. Таким образом, импорт вида go.iain.rocks/boneclone остаётся неизменным независимо от того, где фактически расположен код. Автор предоставляет готовые конфиги Nginx и HTML-файл для быстрого старта и рекомендует этот подход всем командам, использующих Go в продакшене.

Привязка импортов к GitHub — уязвимость, но кастомные домены лишь переносят риск на управление доменами, не решая фундаментальной проблемы надёжности именования в распределённых системах. jerf: любая система именования — человеческое построение, может сломаться; замена GitHub на другой домен не решает проблему, а смещает точку отказа. thih9: коммерческим командам следует использовать кастомные домены для внутренних пакетов независимо от языка, так как даже ссылки в комментариях ломаются при миграции. p4bl0: кастомный домен может быть уничтожен регистратором (как VeriSign), поэтому стратегия не менее рискованна. SenHeng: GitHub надёжнее кастомного домена, так как у открытых разработчиков выше шанс перестать платить за домен, чем GitHub исчезнет. st3fan: при выходе компании из бизнеса её домен может быть перехвачен третьей стороной, что приведёт к захвату зависимостей — уже происходило в других экосистемах. rot256: Go смешивает 'что' и 'где' — фундаментальный недостаток, усугублённый отсутствием изначальной поддержки версионирования и блокировки зависимостей. gumby: следует использовать URN вместо URL для импортов, чтобы отделить идентификатор от места хранения и поддерживать несколько резолверов с подписями. nirui: GitHub-URL — достоверный идентификатор, кастомный домен — нет; система привыкла к GitHub как к стандарту, поэтому домен лучше использовать для брендинга, а не идентификации. deanc: если автор пакета умрёт или домен истечёт — зависимости станут недоступными без восстановления. hk1337: даже при отказе от GitHub пакеты будут ссылаться на GitLab, Codeberg или локальные серверы — проблема не исчезает, только смещается. pidgeon_lover: модель динамической загрузки зависимостей вредна, как stub-установщики; через десятилетия такие импорты могут быть скомпрометированы. okanat: единственный надёжный барьер в Go — сетевой; домен с DNS — минимально необходимый уровень абстракции для безопасного разделения. shieldagent: после переименования организации replace в go.mod покрыл прямые зависимости, но транзитивные импорты старого пути сломали сборку. lewo: следует использовать Software Heritage как резервный архив для исходного кода — Nix и Guix уже реализуют подобный механизм, хотя Go mod не поддерживает SHA-проверку. imhoguy: предлагается использовать IPNS (IPFS) или распределённый реестр вместо доменов, чтобы избежать централизованных точек отказа при идентификации пакетов.

Архив представляет собой единственное собрание публичных PoC‑эксплойтов и обзоров уязвимостей, которые на момент публикации ещё не получили официального CVE. Автор разместил их в открытом доступе, призывая сообщество самостоятельно сообщать о найденных уязвимостях и забирать кредит за присвоенный номер, если он будет выдан. При этом он подчёркивает, что такие материалы предназначены лишь для привлечения людей в область кибербезопасности, а не для реального злоупотребления. Он также шутит, что можно «взять лулз», сообщая о уязвимостях и получая CVE, но настоятельно просит не злоупотреблять этим ресурсом.

Автор заявляет, что такие материалы следует использовать только в образовательных и исследовательских целях, а не для создания атак или распространения вредоносного кода. Он считает, что открытый набор PoC‑ов — самый эффективный способ заинтересовать начинающих специалистов, заставить их практиковаться с реальными примерами и ускорить развитие компетенций в области уязвимостей. При этом он подчёркивает, что злоупотребление архивом может привести к блокировке доступа к ресурсам, потере репутации и юридическим последствиям. Таким образом, репозиторий служит не столько как хранилище эксплойтов, сколько как стимул для ответственного исследования, способствующий формированию более безопасного программного обеспечения.

• Большинство упомянутых уязвимостей – лишь типичные баги или уже исправленные CVE, а термин «0‑day» здесь сильно размыт.
• Некоторые находки действительно интересные (например, уязвимости в c‑ares, nginx, PHP), но их эксплуатация часто требует предварительных условий.
• Большая часть репозитория содержит PoC‑ы, сгенерированные LLM, и их публичное распространение служит скорее образовательной цели, чем реальной угрозой.
• Автор предупреждает о недобросовестном использовании материалов и подчёркивает, что многие «эксплойты» – лишь учебные примеры, а не готовые атаки.

Один большой сервер вместо оркестра микросервисов

Современный сервер Azure с двумя AMD EPYC 3-го поколения даёт:

• 128 физических ядер / 256 потоков
• до 8 ТБ ОЗУ, 200 ГБ/с пропускная способность
• 128 линий PCIe 4.0 → 30 NVMe + 100 Гбит/с сеть
• 4 TFLOPS — в 2000 г. хватило бы для первой строчки Top500

Что он умеет

• 800 Гбит/с видео (Netflix)
• 1 млн IOPS в NoSQL, 70 k IOPS в PostgreSQL
• 500 k RPS nginx, компиляция ядра Linux за 20 с, кодирование 4K-видео 75 fps

Сколько стоит

• Аренда:
  – OVH: 128 ядер, 512 ГБ ОЗУ, 50 Гбит/с — $1 318/мес.
  – Hetzner: 32 ядра, 128 ГБ — €140/мес.
  – AWS m6a.metal: 96 ядер, 768 ГБ — $6 055/мес.
• Покупка: ~$40 000 за аналогичную конфигурацию у Dell.

Вывод
Для большинства задач один такой сервер перекрывает потребности всей компании. Распределённые системы нужны редко; чаще достаточно «одного большого сервера» и простого деплоя.

• «Облачный налог» заставляет инженеров выбирать только дорогие облачные решения, хотя за $200/мес. у Hetzner можно взять 48 ядер и 128 ГБ ОЗУ, тогда как AWS даёт лишь 4 vCPU и 16 ГБ.
• Многие участники подтверждают: при стабильной нагрузке гибрид «colo + VPS» или одна большая машина дешевле и проще, чем микросервисы и K8s.
• Ключевые риски: единая точка отказа, необходимость админов и железных рук; зато нет «meta-слоёв» Docker-proxy-nginx и можно выжимать максимум из железа.
• Часть команд тратит годы на «cloud-native» пайплайны и закрывается, не успев выйти на рынок; проще начать с PaaS/Hetzner и переезжать, когда счёт действительно больно.
• Для критичных задач достаточно двух физических серверов (active/backup) и CDN; 99,9 % доступности хватает большинству бизнесов, которым на деле не нужен 100 % uptime.

ghrc.io — опечатка к ghcr.io — маскируется под реестр контейнеров, но крадёт GitHub-токены.

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

• Обычные пути (/, /404) возвращают стандартную страницу nginx.
• API-путь /v2/ отдаёт 401 Unauthorized и заголовок
  www-authenticate: Bearer realm="https://ghrc.io/token".
  Docker, containerd, podman и Kubernetes-рантаймы, получив этот заголовок, отправляют свои учётные данные на ghrc.io/token.

Когда утекут токены

• docker login ghrc.io
• GitHub Action docker/login-action с registry: ghrc.io
• Секрет Kubernetes для ghrc.io

Простой docker pull ghrc.io/… без логина не передаёт токенов.

Что делать

Если вы когда-либо логинились на ghrc.io:

1. Смените пароль GitHub.
2. Отзовите все PAT и OAuth-токены.

• Пользователи обсуждают, что домен-ошибка ghrc.io (вместо правильного ghcr.io) уже зарегистрирован и может использоваться для атак.
• Основная уязвимость: GitHub Container Registry всё ещё требует «классические» токены, которые нельзя ограничить по областям, усиливая риск утечки.
• Многие открытые проекты уже ошибочно используют ghrc.io в конфигах CI/CD, что делает атаку массовой.
• Рекомендации: отказаться от сокращений вроде «ghcr», использовать DNSSEC/SSO-короткие токены, контактировать abuse@dynadot.com для блокировки злоумышленного домена.

Debian 13 «trixie» вышел 9 августа 2025 года после 2 лет разработки.
Поддержка — 5 лет (Security + LTS).

Десктопы: GNOME 48, KDE Plasma 6.3, LXDE 13, LXQt 2.1, Xfce 4.20.
Пакетов: 69 830 (+14 100 новых, –8 840 устаревших, 44 326 обновлённых).
Размер: 403 ГБ, 1,46 млрд строк кода.
Ядро: 6.12 LTS; первый релиз с официальной поддержкой riscv64.
Архитектуры: amd64, arm64, armel, armhf, ppc64el, riscv64, s390x.
i386 больше не поддерживается; armel последний релиз.

Ключевые обновления: Apache 2.4.64, Bash 5.2.37, BIND 9.20, GCC 14.2, LibreOffice 25.2, MariaDB 11.8, Nginx 1.26, OpenJDK 21, PHP 8.4, PostgreSQL 17, Python 3.13, Rust 1.85, systemd 257 и др.

Облако: образы для EC2, Azure, OpenStack, PlainVM, NoCloud с cloud-init и оптимизированным загрузчиком.
Live-образы: amd64/arm64, GNOME/KDE и др.; установка через Calamares или стандартный установщик.

• Debian 13 «Trixie» вышла: 63 % пакетов обновлены, поддержка 7 архитектур, включая RISC-V.
• i386 теперь только как «amd32»-совместимый, официального ядра/инсталлятора нет.
• Появился новый формат APT-репозиториев debian.sources, старый sources.list пока работает.
• 95 % пакетов достигают bit-for-bit воспроизводимости на amd64/arm64/riscv64.
• /tmp теперь tmpfs по умолчанию (до 50 % ОЗУ), но можно вернуть старое поведение.
• Пользователи хвалят стабильность, скорость обновления «stable→stable» и отсутствие snap.

OpenFreeMap выдержал 100 000 запросов/с

Внезапно сервис получил 3 млрд запросов за сутки и 215 ТБ трафика.
Пиковая нагрузка — 100 000 rps.
Стоимость такого трафика у конкурентов превысила бы $6 млн/мес.

Единственный замеченный сбой — nginx жаловался на «слишком много открытых файлов», но 96 % запросов успешно обслужены (200 OK), лишь 3,6 % вернули 206 Partial Content.
Система продолжала работать, Cloudflare кешировал даже «пустые» тайлы.

Причина всплеска — новый коллаборативный сайт рисования wplace.live, построенный на OpenFreeMap и ставший вирусным.

• На фоне внезапного хайпа wplace.live (2 млн пользователей, 3 млрд запросов) бесплатный OpenFreeMap получил «объятие смерти» ~1 000 rps, что выявило узкое место в лимите открытых файлов nginx.
• Автор OFM защитил решение ограничить по Referrer и отказаться от IP-рейт-лимита, чтобы не блочить обычных пользователей.
• Часть комментаторов считает, что бесплатный сервис не обязан выдерживать такую нагрузку; другие спорят, кто виноват — отсутствие лимитов или неожиданный виральный проект.
• Обсуждаются альтернативы: Cloudflare-only хостинг, PMTiles-файлы, self-host, но все сходятся, что 96 % доступности при таком наплыве — уже успех.