[ИНИЦИАТИВА]: Покупаем статьи. Ищем авторов. Зарабатывай вместе c XSS

Перейти к новому Отслеживать
BrainKios сказал(а):
Ваша статья не прошла модерацию.​
По пунктам:
  1. Статья не соответствует ключевому критерию оценки - в ней отсутствует практика.​
  2. Отсутствие оформления ("сырой" текст - черновик).​
  3. Повторяющиеся фразы (например, описания White/Black Page дублируются в конце), типичные для AI/рерайта конструкции (простые списки, общие советы).​
  4. Грамматические, пунктуационные и логические ошибки.​
 
кекич сказал(а):
Ваша статья не прошла модерацию.​

По пунктам:
  1. Признаки рерайта. Список примеров тематик (от "NARAKA: BLADEPOINT, Apex Legends, GTA 5 - читы" до крипто-ботов вроде "PancakeSwap Sniping Bot") точно совпадает с контентом из "Roku Team Docs" (страница о тематиках софта/игр для "залива"). Инструкции по "вязу" и заливу типичны для публикаций прошлых лет.​
  2. Техническая глубина - минимальна.
  3. Текст полон ошибок. Это скорее пост-черновик, чем статья для других пользователей.​
 
1763721095581.png

Анонсирую новую статью. Сегодня постараюсь залить.
 
onTAKE сказал(а):
:cool:прям методичка
скрин с черновика сделан. Там всё много интереснее
 
Snow сказал(а):
Посмотреть вложение 111320
Анонсирую новую статью. Сегодня постараюсь залить.
статья готова, начинаю заливать. Для самых нетерпеливых прикреплю пдф - ну не умею я вашими маркдаунами пользоваться ... LaTeX forever
 

Вложения

  • brt_art.pdf
    960 КБ · Просмотры: 46
narow71 сказал(а):
/threads/144469/
Ваша статья не прошла модерацию.

По пунктам:
  1. Компиляция из материалов прошлых лет без новизны. Фрагменты (фразы, структура, списки) повторяются в ресурсах по базовым практикам Docker. Отсутствие упоминания актуальных CVE указывает на копирование старого контента без обновлений.​
  2. Нет личного опыта, реальных кейсов или воспроизводимого кода/эксплойтов, что делает практический аспект статьи поверхностным.​
 
evdo сказал(а):
Ваша статья не прошла модерацию.

По пунктам:
  1. Компиляция из материалов прошлых лет без новизны. Фрагменты (фразы, структура, списки) повторяются в ресурсах по базовым практикам Docker. Отсутствие упоминания актуальных CVE указывает на копирование старого контента без обновлений.​
  2. Нет личного опыта, реальных кейсов или воспроизводимого кода/эксплойтов, что делает практический аспект статьи поверхностным.​
Хочу задать вам несколько вопросов:

<Компиляция из материалов прошлых лет без новизны. Фрагменты (фразы, структура, списки) повторяются в ресурсах по базовым практикам Docker>

Можете прислать мне хотя бы один такой ресурс, где проводится такой детальный анализ безопасности Docker? Не понимаю, про какие материалы прошлых лет вы говорите. Информация в статье актуальна по сей день.

<Отсутствие упоминания актуальных CVE указывает на копирование старого контента без обновлений.>

Я привел эти CVE в качестве примера. Разумеется, я не буду указывать их все. Смысл какой? (символы накрутить?) Этих уязвимостей было достаточно, чтобы читатель понял мысль, которую я хотел до него донести.

<Нет личного опыта, реальных кейсов или воспроизводимого кода/эксплойтов, что делает практический аспект статьи поверхностным>

Практика в моей статье есть? Есть. Хоть и поверхностная, но она ЕСТЬ. Я не не написал голую теорию, заметьте.

И все же. Все условия админа были соблюдены.
 
narow71 сказал(а):
Хочу задать вам несколько вопросов:

<Компиляция из материалов прошлых лет без новизны. Фрагменты (фразы, структура, списки) повторяются в ресурсах по базовым практикам Docker>

Можете прислать мне хотя бы один такой ресурс, где проводится такой детальный анализ безопасности Docker? Не понимаю, про какие материалы прошлых лет вы говорите. Информация в статье актуальна по сей день.

<Отсутствие упоминания актуальных CVE указывает на копирование старого контента без обновлений.>

Я привел эти CVE в качестве примера. Разумеется, я не буду указывать их все. Смысл какой? (символы накрутить?) Этих уязвимостей было достаточно, чтобы читатель понял мысль, которую я хотел до него донести.

<Нет личного опыта, реальных кейсов или воспроизводимого кода/эксплойтов, что делает практический аспект статьи поверхностным>

Практика в моей статье есть? Есть. Хоть и поверхностная, но она ЕСТЬ. Я не не написал голую теорию, заметьте.

И все же. Все условия админа были соблюдены.
Спасибо за ваш отклик и вопросы.

По пунктам:
1. Я приведу ресурсы как на русском, так и на английском языке, чтобы вы могли самостоятельно сравнить структуру, фразы и содержание. Эти источники демонстрируют, что ваша статья в значительной степени повторяет стандартные материалы без добавления новой информации.
Актуальность сохраняется для базовых механизмов, но не для угроз (см. ниже про CVE).

Примеры источников на русском языке:​
  • "Проблемы безопасности Docker" (Habr.com, 2017) – https://habr.com/ru/companies/slurm/articles/339126/. Статья имеет почти идентичную структуру — разделы по механизмам (namespaces для изоляции, cgroups для ресурсов, capabilities для привилегий, AppArmor/Seccomp для фильтрации syscalls), векторам атак (breakout, DoS через ресурсы, уязвимости в образах, daemon-атаки) и рекомендациям (drop capabilities с --cap-drop, user namespaces, сканирование образов). Фразы вроде "root в контейнере имеет меньше привилегий" или "Seccomp как фильтр syscalls" повторяются дословно или близко. Ваш вывод о "минимальных привилегиях" эхом отзывается здесь, где обсуждается то же (whitelist capabilities). Это классика, и ваша статья не углубляет тему дальше.​
  • "Программные механизмы изоляции контейнеров DOCKER" (ОКБ САПР, 2021) – https://www.okbsapr.ru/library/publications/programmnye-mekhanizmy-izolyatsii-konteynerov-docker/. Детальный разбор namespaces, cgroups, Seccomp и AppArmor как в вашей части I. Список механизмов (изоляция процессов, сетей, ресурсов) и объяснения (например, "cgroups ограничивают CPU, память, I/O") совпадают, включая историю kernel-версий.​
  • "Безопасность в Docker: от правильной настройки хоста до демона" (Selectel.ru, 2024) - https://selectel.ru/blog/docker-security-1/. Точный аналог: настройка хоста, демон, уязвимости API (curl для проверки), ограничения ресурсов (cgroups). Фразы про "минимальные привилегии" и команды вроде docker run с флагами --security-opt совпадают.
  • "Исчерпывающее пособие по безопасной сборке Docker-образов" (Selectel.ru, 2024) – https://selectel.ru/blog/docker-security-2/. Фокус на образах, сканировании уязвимостей, подписях (Notary), что перекликается с вашим разделом о Docker Hub и рекомендациях.
  • "Методы обеспечения безопасности контейнеров Docker" (Habr.com, 2022) – https://habr.com/ru/companies/first/articles/706764/. Подробный разбор методов (non-root пользователи, namespaces, Seccomp), векторов атак (ошибки конфигурации, --privileged) и рекомендаций. Структура близка: теория механизмов + практика команд, как в вашей Части I–III.

Примеры источников на английском языке:​
  • "Docker Engine security" (Docker Docs: постоянно обновляется, базовая версия с 2017) – https://docs.docker.com/engine/security/. Официальный гайд Docker повторяет вашу структуру: области безопасности (kernel namespaces, cgroups, capabilities, AppArmor), векторы (daemon attack surface, breakout risks) и практики (run non-root, drop capabilities с --cap-add/--cap-drop, Content Trust для образов). Фразы вроде "namespaces provide basic isolation" или "cgroups prevent DoS" — прямые аналогии. Раздел о "root внутри контейнера слабее" взят отсюда (capabilities whitelist по умолчанию). Это базовый материал, который не эволюционировал в вашей статье.
  • "Docker Security Cheat Sheet" (OWASP Cheat Sheet, обновлено 2024) — https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html. Список лучших практик (non-root users, --icc=false для сетевой изоляции, cap-drop, сканирование образов) и векторов атак (daemon exposure, privileged mode) идентичен вашему Часть III. Рекомендации по API (TLS, firewall) и DockerHub (trusted images) — те же. Это «cheat sheet», а не глубокий анализ, но ваша статья следует ему шаг в шаг, без добавления опыта.

Ваша статья — хороший синтез, но без новизны она выглядит как рерайт, а не уникальный контент.

2. Вы правы, не нужно перечислять все CVE для "накрутки символов".
Однако в "глубоком погружении" читатели ожидают обзора свежих угроз.
Без этого статья выглядит как копия контента трехлетней давности, а не анализ по состоянию на ноябрь 2025.

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

Критерий "теория+практика (опыт, случаи)" требует глубины: не просто перечисление, а анализ с примерами из жизни, кодом/скриптами для теста.
Ваша статья соответствует минимуму, но не уровню, за который платит форум.

Ознакомьтесь с примерами:
– "Обзор способов защиты контейнеров Docker" (Habr.com, ноябрь 2024) — https://habr.com/ru/companies/selectel/articles/854850/. Реальные кейсы с кодом YAML для политик.
– "Безопасность в Docker" (Selectel.ru, 2024) — https://selectel.ru/blog/docker-security-1/. Детальные скрипты для сканирования образов с Trivy, примеры работы с user namespaces, личные советы от автора (опыт миграции).

Несмотря на критику, ваша статья — хорошее начало.
Если обновите и переработаете материал, буду рад пересмотреть.​
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Сугубо в качестве инициативы: Предлагаю авторам статей присвоить отдельный статус, например после 3 принятых статей присваивать статус типа: " Автор статей" и реализовать техническую возможность для авторов статей редактировать собственные статьи в течение периода "до момента их формального утверждения админом на оплату". Затем, после утверждения - возможность редактирования убирать.
 
sysbot сказал(а):
Сугубо в качестве инициативы: Предлагаю авторам статей присвоить отдельный статус, например после 3 принятых статей присваивать статус типа: " Автор статей" и реализовать техническую возможность для авторов статей редактировать собственные статьи в течение периода "до момента их формального утверждения админом на оплату". Затем, после утверждения - возможность редактирования убирать.
поддерживаю.
 
admin


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх