Выпуск дистрибутивов Альт Сервер, Альт Рабочая станция и Альт Образование версии 8.2

Хрень какая то. Лицензии да ну нах.

Вы хотите сказать, что несвободные дистрибутивы — нах?

Какая разница, если Вы не юридическое лицо?

Американцам не понять.

Нахрен такое разделение? В чём отличие?

Какая разница...?

Вот, да. Это самое товарищ и спросил.

что я должен ставить

Альт Образование

я презираю копирастов и от слова «лицензия» у меня активизируется рвотный рефлекс

я презираю копирастов и от слова «лицензия» у меня активизируется рвотный рефлекс

О_о

Но почему?! Где связь?

Почему у вас слово «лицензия» ассоциируется с копирастами? Ведь копирасты куда чаще вовсе не прибегают к лицензиям? Тогда как свободное творчество без них, напротив, немыслимо.

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

а что будет если выяснится что у кого то есть диплом юриста а он пользуется без лицензии

А-а... Милостивый государь шутить изволит... Ну-ну.

Надоело про лицензии, давай дальше про системы инициализации?

Что-то я обалдел слегка, увидев

tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      1/init

tcp        0      0 0.0.0.0:11211           0.0.0.0:*               LISTEN      427/memcached

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

… 427/memcached …

Причём тут системд?

… 0 0.0.0.0:111 …

Это rpcbind.

Нет, я понимаю, что там надо смотреть, когда настраиваешь, но подставы из коробки...

Ели на сервере

Chain INPUT (policy ACCEPT)
target     prot opt in     out     source               destination         
ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0 

А в CentOS по дефолту и с firewalld, и с iptables открыт только ssh. Так что мимо.

Причём тут системд?

Тут CentOS при чём, а не systemd.

Это rpcbind.

По порту - да. Но почему у него PID 1 ?

А в CentOS по дефолту и с firewalld, и с iptables открыт только ssh. Так что мимо.

Нормально так. Потенциально уязвимый сервис по дефолту слушает всё, а виноват не CentOS? Да там даже в явном виде не предусмотрено его на localhost вешать, только через $OPTIONS в /etc/sysconfig/memcached, при чём там даже намёка нет на то, что это не плохо бы сделать.

И сравни с /etc/sysconfig/memcached в ALT:

# Parameters for memcached daemon.
# See memcached(1) for more details.

RUNAS=memcached
LISTEN="127.0.0.1"
EXTRAOPTIONS=""

Причём, самое смешное, что сценариев использования memcached не локально крайне мало.

Тут CentOS при чём, а не systemd.

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

По порту - да. Но почему у него PID 1 ?

Потому. Параноикам даже на багтрекере ответили уже.

Нормально так

Ай как страшно, при закрытом-то порте.

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

Ну я думал, что посмотреть в unit-файл и в /etc/sysconfig/memcached и увидеть, что там даже задела нет для того, чтобы вешать демона на заданный интерфейс.

Ай как страшно, при закрытом-то порте.

Демоны висят кишками наружу, а он тут рассказывает, что они стекляшечкой прикрыты. Нет там никакого firewalld. Это образ для OpenVZ. Официальный, кстати, с openvz.org.

Параноикам даже на багтрекере ответили уже.

Интересно почитать только с точки зрения ещё посмеяться.

посмотреть в unit-файл и увидеть, что там даже задела нет для того, чтобы вешать демона на заданный интерфейс.

У защитников альта принято не уметь в ПО которым они пользуются?

OPTIONS="-l 127.0.0.1,::1"

Демоны висят кишками наружу, а он тут рассказывает, что они стекляшечкой прикрыты.

Кто тебе виноват, что ты сервера не настраиваешь? И жду прохладных историй о том, как ты подключаешься на закрытые firewall порты.

Это образ для OpenVZ. Официальный, кстати

Не вижу ссылок на него в списке на сайте проекта. Опять обкурился?

Это образ … с openvz.org.

Криво образ собирают openvz, а виноват центос, ага.

Совсем задела нет, ага.

Именно так. Про OPTIONS я тебе сам написал, заметь. Но это - нет задела. А параметр не то, что важен, а вовсе должен быть по-умолчанию.

Криво образ собирают openvz, а виноват центос, ага.

Криво в CentOS собирают пакеты (хотя, вероятно, недостаточно дорабатывают - боюсь, оно так и в Федоре, и в RH): memcached - это epic fail. И, судя по всему, Гитхабу досталось на днях именно из-за этого. Это раз. А два - разве не апологеты CentOS образы туда предоставляют?

Но это - нет задела. А параметр не то, что важен, а вовсе должен быть по-умолчанию.

Кому должен? Что тебе ещё в /etc/sysconfig вынести? Или я где-то пропустил твой на рассказ о том, как на закрытые iptables порты подключаешься?

Криво в CentOS собирают пакеты: memcached - это epic fail.

Опять свои фантазии за действительность выдаешь? Демон работает корректно? Работает. Из коробки до демона достучаться нельзя? Нельзя. А то, что какой-то идиот файервол выключает на публично доступном сервере — он ССЗБ.

А два - разве не апологеты CentOS образы туда предоставляют?

Опять сам нафантазировал, сам же и поверил? Я тебе страницу со ссылками на официальные образы скинул.

Гитхабу досталось на днях именно из-за этого.

Пруфф на отчёт, что это «CentOS only» проблема и на жалобы, что CentOS из коробки подвержен этой проблеме (плачь идиотов, которые сами открыли порт, не в счёт). Или ты так, для крассного словца гитхаб приплёл?

А то, что какой-то идиот файервол выключает на публично доступном сервере — он ССЗБ.

Идиоты - это те, кто считают, что сервер должен быть защищён файрволом, и этого достаточно. Нормальные же люди знают, что на сервере сервисы, к которым не нужен доступ снаружи, должны висеть либо на lo, либо, вовсе, использовать unix socket.

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

Пруфф на отчёт, что это «CentOS only» проблема

Потому, что я посмотрел, в Ubuntu тоже на 127.0.0.1 по-умолчанию. И, надеюсь, что это не они сами, а так в Debian сделано. Значит остаётся у нас кто? Правильно.

Я тебе страницу со ссылками на официальные образы скинул.

Ну ладно. Значит, делаем вывод: из репозитория CentOS фиг что своё соберёшь просто так - можно нарваться. Так и запишем.

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

... и которые, по каким-то причинам, таки требуется держать не на lo. Добавил очевидное, на всякий случай.

Нормальные же люди знают

что бывает необходимо разное поведение и после установки пакета его настраивают. А ты ноешь, что дефолт тебе не подходит.

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

Т. е. и для того, чтобы к тому же memcached не смогли извне подключиться. Или мы таки увидим твой рассказ о неспособности netfilter закрыть доступ к порту?

я посмотрел, в Ubuntu тоже на 127.0.0.1 по-умолчанию.

В Fedora тоже уже исправили дефолт. Сравним дату выхода центоси и бубунточки? Или из-за того, что memcached облажались, нужно забить на совместимость в рамках релиза?

И, надеюсь, что так в Debian сделано.

Надейся, ага. Ты в своём репертуаре, где-то что-то увидел, где-то что-то додумал, где-то совсем придумал. Прежде чем доказывать, что 2×2=5, учебник математики открой, что ли.

Значит остаётся у нас кто?

Дебиан, центос и многие другие, кто не в твоей фантазии живёт.

Ну ладно. Значит, делаем вывод

что AS опять чушь несёт

Так и запишем

Таки что-то тебе мешает держать их на lo? Винду, простите, тоже с настройками по-умолчанию в корпоративной среде используешь?

А ты ноешь, что дефолт тебе не подходит.

Дефолт должен быть безопасен по-умолчанию. Уже перестань выворачиваться. Настраиваться должно из безопасного в опасное, а никак не наоборот.

Т. е. и для того, чтобы к тому же memcached не смогли извне подключиться.

Читай внимательно. Я специально для тебя написал: "... и которые, по каким-то причинам, таки требуется держать не на lo"

Таки что-то тебе мешает держать их на lo?

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

Винду, простите, тоже с настройками по-умолчанию в корпоративной среде используешь?

А CentOS стремится быть похожей на Windows в плане кишков наружу!? Здорово... А я нет, никогда вообще не занимался Windows в корпоративной среде, как и не использовал у себя.

Прежде чем доказывать, что 2×2=5, учебник математики открой, что ли.

Вообще-то я объясняю про 2x2=4.

Ты в своём репертуаре, где-то что-то увидел, где-то что-то додумал

У меня опыта чуток больше, очевидно, чем у тебя, и это позволяет экстраполировать. Хорошо, идём на https://packages.debian.org/stretch/memcached и смотрим там memcached_1.4.33-1.debian.tar.xz. И-и-и... Раз:

[Service]
ExecStart=/usr/share/memcached/scripts/systemd-memcached-wrapper /etc/memcached.conf

# Specify which IP address to listen on. The default is to listen on all IP addresses
# This parameter is one of the only security measures that memcached has, so make sure
# it's listening on a firewalled interface.
-l 127.0.0.1

Дебиан, центос и многие другие, кто не в твоей фантазии живёт.

Увы, Debian и производные выпадают. Пока остаются только федорины производные. Я, правда, Arch не смотрел, SuSe и кто там ещё в лидерах? Сам посмотришь?

В Fedora тоже уже исправили дефолт.

Не заметил за кучей текста. Ну вот видишь, я-то прав.

Сравним дату выхода центоси и бубунточки?

Сравним, когда это было сделано в ALT?

нужно забить на совместимость в рамках релиза?

Совместимость с чем? Это ты клёво придумываешь...

Совместимость с чем? Это ты клёво придумываешь...

Не «с чем», а «чего». Ты мог установить CentOS7 как в 2014 году, так и в 2017. Выполнить на них одни и те же действия, сделать yum upgrade, и получить две идентичные системы.

Сравним, когда это было сделано в ALT?

У Альта, простите, сколько срок поддержки заявлен? Или ты говоришь, что Админы альта привыкли, что в рамках релиза их автоматизация может сломаться, т. к. мейтейнеры решили параметры по умолчанию изменить?

Дефолт должен быть безопасен по-умолчанию. Уже перестань выворачиваться.

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

Ещё раз повторяю: это должно быть по-умолчанию.

Ещё раз повторяю: кому должно? Продемонстрируй эксплуатацию уязывимоти.

Прикинь, я угадал.

Кто-то выше кукарекал о необходимости вынесения этого в отдельную переменную в /etc/sysconfig/memcached. Или ты на ходу переобулся и вариант «вписать в конфиг» — гут? А если вписать в конфиг - гут, то чего ты вообще хочешь? Чтобы дефолт сломал системы тем, у кого демон в изолированной сети сидит и вполне намеренно слушает eth0? Жди CentOS8 — поменяют, возможно. Но ты так и не показал, чем небезопасен дефолт именно в CentOS.

BTW, в апстриме до сих пор (1.5.6)

-l, --listen=<addr>
Listen on <addr>; default to INADDR_ANY. <addr> may be specified as host:port.

Админы альта привыкли, что в рамках релиза их автоматизация может сломаться

Ты хотел сказать, что поддержка уязвимостей может сломаться? Да. :-)

У Альта, простите, сколько срок поддержки заявлен?

И при чём тут срок поддержки, если это было так уже в 2011 ?

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

Её уже продемонстрировали без меня. Я ссылку давал.

Кто-то выше кукарекал о необходимости вынесения этого в отдельную переменную в /etc/sysconfig/memcached.

Кукаретик тут ты. Ещё и читать не умеешь.

Я писал про то, что мантейнер даже не подумал намекнуть пользователю, что можно (и нужно) выбрать, где висеть. А первично - оно уже должно быть так, а как это сделано - не принципиально. Если сделано.

Ещё раз повторяю: кому должно?

Вот ему должно:
https://bugzilla.redhat.com/show_bug.cgi?id=1549752
И вот ему должно:
https://bugzilla.redhat.com/show_bug.cgi?id=1550066
И вот народ тексты писать начал:
https://bugzilla.redhat.com/show_bug.cgi?id=1550654

И вот ему должно:
https://bugzilla.redhat.com/show_bug.cgi?id=1182542
Но ему сделали уже.

Нормальный юзер бы давно отправил багрепорт в апстрим, а не шёл необоснованно ругать дистрибутив.

Нормальный юзер из исходников не собирает, а за конфиг в дистрибутиве отвечает мантейнер в дистрибутиве. Но ты не туда посмотрел. Посмотри в конфиг в апстриме, в самом верху. Строчка где-то пятая. Оно закомментировано, но, хотябы, написано.

Ты хотел сказать, что поддержка уязвимостей может сломаться?

Где уязвимость, продемонстрируй?

Её уже продемонстрировали без меня. Я ссылку давал.

Покажи по той ссылке RHEL или CentOS. Либо покажи как воспроизвести атаку, условие одно: на хосте чистая CentOS, где ты своими шаловливыми руками ещё netfilter не сказал пропускать весь трафик на 11211. Или таки 4.2?

Я писал про то, что мантейнер даже не подумал намекнуть пользователю, что можно (и нужно) выбрать, где висеть.

Мейтейнер запретил пользователю документацию прочитать? Вот это поворот.

А первично - оно уже должно быть так, а как это сделано - не принципиально. Если сделано.

В 8 релизе, скорее всего будет. Чисто «ради порядка». В рамках одного релиза дефолт менять нельзя. По твоей же ссылке описано почему. И опять: либо демонстрируй эксплуатацию уязвимости на дефолтной CentOS, либо чистое 4.2 с твоей стороны.

Вот ему должно: И вот ему должно: И вот народ тексты писать начал:…

То, что у них клиент находится на одном хосте с сервером не значит, что у других нет клиентов за пределами локалхоста. Ломать автоматизацию крупным проектам ради мамкиных админов, которые не могут один конфиг подправить? Вы у себя в Альте, может так и делаете… потому-то его ни видно, ни слышно.

Нормальный юзер из исходников не собирает

Т.е. дятел, увидевший ошибку в дефолте апстрима и срущий в багтрекеры дистрибутивов «сделайте не как у них», вместо одного репорта в апстрим (а оттуда изменения придут в дистрибутивы) — нормальный юзер. Я надеюсь, ты понимаешь, что «юзер» в данном случае — админ, а не «юзер из бухгалтерии»?

Но ты не туда посмотрел. Посмотри в конфиг в апстриме, в самом верху. Строчка где-то пятая. Оно закомментировано, но, хотябы, написано.

Документацию у тебя отобрали, что ли? То, что ты вспышку просрал, не вина дистрибутива. Инструкцию хотя бы бегло прочитать надо было.

Потому, что я посмотрел, в Ubuntu тоже на 127.0.0.1 по-умолчанию.

Вот из-за мейтейнеров, молча меняющие поведение софта и пострадали юзвери, которые выхлоп ss -n не смотрят. Если бы в манах для дебилов писали «Установи пакет и скажи демону слушать только lo», а не «установи пакет», то и проблемы бы, может и не случилось.

Зато теперь есть хороший маркер. Кто пострадал — доки не читает.

Покажи по той ссылке RHEL или CentOS.

По той ссылке memcached. И в RHEL/CentOS состояние пакета, отвечающее этой проблеме. Кстати было, уже несколько дней, как сам memcached обновили, закрыв UPD по-умолчанию и нарушив, в твоём представлении «Выполнить на них одни и те же действия, сделать yum upgrade, и получить две идентичные системы».

где ты своими шаловливыми руками ещё netfilter не сказал пропускать весь трафик на 11211

Ещё раз объясни, зачем это фильтровать, если можно совсем не вешать наружу?

Мейтейнер запретил пользователю документацию прочитать?

Мантейнер собрал пакет на отъе... Впрочем, в отличие от тебя, мантенер-то это понял (см. 1182542), так что про него - это для красного словца, так сказать. Но вот кто в CentOS пакеты пересобирает про это не подумал. Ну или оставил на откуп RHEL, а там то же не подумали.

что у других нет клиентов за пределами локалхоста.

Это - редкая конфигурация для memcached.

Ломать автоматизацию крупным проектам ради мамкиных админов

В CentOS уже обновили memcached на версию с закрытым по-умолчанию UDP. Ради мамкиных админов, не иначе.

Т.е. дятел, увидевший ошибку в дефолте апстрима и срущий в багтрекеры дистрибутивов «сделайте не как у них», вместо одного репорта в апстрим (а оттуда изменения придут в дистрибутивы) — нормальный юзер.

Это ты дятел, потому, что в дистрибутивах способы конфигурирования различаются. Где-то это /etc/sysconfig/memcashed, где-то /etc/memcached.conf, где-то ещё что-то. Апстрим за всеми следить должен?

И ты - дважды дятел: в апстримовском memcached.conf это есть. Я уже тебе писал. Правда закомментирвано, но с рекомендациями.

То, что ты вспышку просрал, не вина дистрибутива.

Это не я проспал: я RHEL/CentOS не использую. А вот их пользователи проспали. Теперь багрепорты строчат. То, что у нашего клента CentOS оказался в VPS - так его за руку никто не тянул и обслуживать его VPS никто не должен, кроме него. Это я по доброте душевной смотреть полез, вместо того, чтобы его просто отключить.

И в RHEL/CentOS состояние пакета, отвечающее этой проблеме

Так продемонстрируй эксплуатацию, хватит шланговать.

Ещё раз объясни, зачем это фильтровать, если можно совсем не вешать наружу?

Это к тебе вопрос, почему ты не вписал -l 127.0.0.1, если тебе не надо в локалку.

Впрочем, в отличие от тебя, мантенер-то это понял

Я где-то говорил, что не надо ставить -l 127.0.0.1? Я говорю, что для эксплуатации уязвимости CentOS нужно особым образом сконфигурировать. Из коробки - никак.

Это - редкая конфигурация для memcached.

И что? В 2014 году решили, что лучше сделать как апстриме. В CentOS 8, возможно, решат сделать -l localhost. Каким образом наличие\отсутствие одно из этих решений открывает порт для входящих подключений?

Апстрим за всеми следить должен?

Да нет, птичка тут ты… Апстрим изменит дефолт, а мейтейнеры дистрибутивов пакета пересоберут пакеты с новым дефолтом хоть в /etc/sysconfig, хоть в /etc/memcached.conf

Правда закомментирвано, но с рекомендациями.

Птица говорун отличается умом и сообразительностью, умом и сообразительностью… оно в документации есть. Если ты — дятел, который дальше /etc/${app}.conf не читает, это только твои проблемы.

Это не я проспал: я RHEL/CentOS не использую. А вот их пользователи проспали.

Ты документацию не читаешь, или твой клиент… суть одна и та же: тот, кто сервер настраивал сервер, документацию не читает и работает «наотвали».

Но от темы не уходи: выше ты кукарекнул о том, что из дефолтная конфигурация CentOS подвержена уязвимости, в отличии от Альта и бубунты. Либо демонстрируй эксплуатацию уязвимости в дефолтной конфигурации, либо признавай 4.2 с твоей стороны. Отсылки на крикунов, которые сами порт выставили наружу, не в счёт.

В CentOS уже обновили memcached на версию с закрытым по-умолчанию UDP.

Единственное, можешь вернуть в конфиг memcached udp порт.

Так продемонстрируй эксплуатацию, хватит шланговать.

Ещё раз: она продемонстрирована. Не притягивай сюда за уши iptables.

Апстрим изменит дефолт, а мейтейнеры дистрибутивов пакета пересоберут пакеты с новым дефолтом хоть в /etc/sysconfig, хоть в /etc/memcached.conf

Нда... Я даже не знаю, как тебе донести... Дефолт где? В бинарнике? Или в конфиге? Ты понимаешь, что конфиги у всех раз-ны-е. И строка параметров для запуска, прикинь, формируется у всех по-разному. Так что вот, расшифруй, что, в твоём понимании, «Апстрим изменит дефолт».

выше ты кукарекнул о том, что из дефолтная конфигурация CentOS подвержена уязвимости

Дефолтная конфигурация пакета в CentOS. Ты суть не меняй давай. А ещё меня шлангом называешь. :-)

Единственное, можешь вернуть в конфиг memcached udp порт.

Чем это отличается от перевесить на lo? «Чуть-чуть беременна»?

Ещё раз: она продемонстрирована. Не притягивай сюда за уши iptables.

Ещё раз: эксплуатация бага memcached при закрытом файерволом 11211 как-то отличается от эксплуатации бага при -l 127.0.0.1 ? Если нет, тебе чего надо? Если да — демонстрируй.

Так что вот, расшифруй, что, в твоём понимании, «Апстрим изменит дефолт».

Если говорить конкретно о memcached, имхо с очередным мажорным релизом стоит сделать при отсутствии -l в параметрах запуска привязку только к lo. А в минорном релизе можно в memcached.conf апстрима указать -l. И подобные изменения дистрибутивы должны делать вслед за апстримом, а не плодить зоопарк.

Дефолтная конфигурация пакета в CentOS.

А ты собрался этот пакет в Gentoo устанавливать? Я тебе и говорю: эта бага в memcached даже при том, что по дефолту он цепляется к eth0, неюзабельна в CentOS, ибо порт закрыт. Поэтому нефиг кукарекать о том, что гитхаб из-за центоса пострадал. А верность решения биндить демона на сетевые интерфейсы обсуждать нужно с апстримом.

Чем это отличается от перевесить на lo? «Чуть-чуть беременна»?

Я это к тому, чтобы ты не шлангонул «дык они уже отвязали»: привяжи обратно, и продемонстрируй.

И подобные изменения дистрибутивы должны делать вслед за апстримом, а не плодить зоопарк.

Ты понимаешь, что зоопарк уже есть, и CentOS, например, как и ALT, не используют memcached.conf вообще? И /etc/sysconfig/memcached на его основе тоже не генерится автоматом. memcached.conf в Debian используется. Вот там можно говорить про изменение в апстриме. В Слаквари, очевидно, тоже.

А ты собрался этот пакет в Gentoo устанавливать?

А минимальный образ CentOS для виртуалок - это уже Gentoo? Или это не CentOS? (внимание, засада. ;-) )

А верность решения биндить демона на сетевые интерфейсы обсуждать нужно с апстримом.

При неиспользовании апстримовского конфига - нет. Только с мантейнером пакета в дистрибутиве. Вот если вести речь по умолчание без конфига вовсе, тогда да, с апстримом.

Я это к тому, чтобы ты не шлангонул «дык они уже отвязали»: привяжи обратно, и продемонстрируй.

Ну ты шланг... То нельзя менять привязку к интерфейсу в конфиге, а как закрыли порт, что, по сути, практически то же самое, так на тестирование уязвимости перевести пытаешься? Ну уж нет. Давай решим, почему нельзя было давно перевесить на lo, если сейчас закрыли udp. Определись с разницей.

А про эксплуатацию я тебе уже не раз ответил.

не используют memcached.conf вообще? И /etc/sysconfig/memcached на его основе тоже не генерится автоматом. memcached.conf в Debian используется.

На то мейтейнеру голова и дана, чтобы он сообразил, что -l localhost из конфига в /etc/sysconfig/memcached перенести надо.

А минимальный образ CentOS для виртуалок

Ты опять про свой openvz? Иди и тряси своих криворучек, что ACCEPT по дефолту врубили при сборке образа.

Ну ты шланг... То нельзя менять привязку к интерфейсу в конфиге…

Дык это ты выше попытался съехать:

В CentOS уже обновили memcached на версию с закрытым по-умолчанию UDP.

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

Но т.к. и в пакете

cat /etc/sysconfig/memcached

PORT="11211"
USER="memcached"
MAXCONN="1024"
CACHESIZE="64"
OPTIONS=""

micdrop.png

На то мейтейнеру голова и дана, чтобы он сообразил, что -l localhost из конфига в /etc/sysconfig/memcached перенести надо.

Мантейнеру голова, вообще-то, дана чуть больше, чем для этого. А продвинутые мантейнеры ещё и код патчат. Под особенности дистрибутива, если это для апстрима не годится по какой-то причине.

Ты опять про свой openvz?

Например да.

Иди и тряси своих криворучек, что ACCEPT по дефолту врубили при сборке образа.

Он не мои и не криворучки: там только ssh порт слушает по-умолчанию. А клиент накатил Битрикс-преинсталл (или как его там), поставил Битрикс и успокоился.

Вот и говорю, если уже закрыт по умолчанию — открой обратно. Остальное дефолт оставь.

Ты несколько сообщений назад возмущался предложением перевесить на lo, а теперь забыл что-то, как в пакете поменяли. Понял, что не сильно прав, что ли?

и демонстрируй эксплуатацию уязвимости.

Вот заладил...

то считаю возможным засчитать тебе слив.

Просто аргументов у тебя нет никаких после последних изменений в пакете. Они тебя подставили. :-)

Мантейнеру голова, вообще-то, дана чуть больше, чем для этого

Одно исключает второе?

А клиент накатил Битрикс-преинсталл (или как его там), поставил Битрикс и успокоился.

Сторонний образ развернул, неумеючи накатил проприетарное г-но, а претензии, конечно, к дистрибутиву.

Ты несколько сообщений назад возмущался предложением перевесить на lo, а теперь забыл что-то, как в пакете поменяли.

В CentOS забиндили memcached на lo? Не поделишься ссылкой на этот уникальный пакет? Или опять фантазируешь?

Вот заладил...

Так если ты кукарекнул «в центос дыра», а когда с тебя пруфф просят, ты как слизь сквозь пальцы просочиться пытаешься.

а теперь забыл что-то, как в пакете поменяли.

Про то, что бинарник иначе себя ведёт — да, проглядел, но дефолтный конфиг кто-то тронул?

а претензии, конечно, к дистрибутиву.

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

В CentOS забиндили memcached на lo?

Ты совсем мух не ловишь? Поясни, в чём ты видишь принципиальную разницу между «забиндить на lo» и «отключить udp»? В обоих случаях меняется доступность приложения снаружи, просто чуть-чуть в разной степени. Жаль, что я про «отключить udp» изначально не начал - сейчас бы совсем смешно было.

Так если ты кукарекнул «в центос дыра»

А мы пакет memcached не CentOS-овский обсуждаем разве ??

да, проглядел, но дефолтный конфиг кто-то тронул?

А какая разница, если поведение однотипно (хоть и не одинаково) поменялось?

небезобасно сконфигурированный пакет.

А если руту пароль поставить 123, то любой пакет будет небезопасен. Проблема не в пакете, а в дебилах настраивающих netfliter пропускать всё и не читающих документацию.

А мы пакет memcached не CentOS-овский обсуждаем разве ??

Так ты продемонстрируй уже, как на дефолтной центос эксплуатировать эту уязвимость. Вот возьми centos-minimal, установи туда memcached, включи обратно UDP (чтобы откатить к состоянию, когда светило UDP портом наружу) и покажи. Либо ты тут просто кудахчешь, чтобы подлизать базальту (типа у других плохо, а у базальта хорошо)?

в чём ты видишь принципиальную разницу между «забиндить на lo» и «отключить udp»?

Тем, что memcached не только в udp умеет.

А какая разница, если поведение однотипно (хоть и не одинаково) поменялось?

«слушать только tcp на всех интерфейсах» и «слушать всё только на lo». Офигеть однотипно.

А если руту пароль поставить 123, то любой пакет будет небезопасен.

В ALT root-а вовсе по ssh не пускают по-умолчанию. Ни при каких условиях. ;-) Надо обычного пользователя заводить. Так что, в худшем случае, ещё и логин угадывать придётся.

Либо ты тут просто кудахчешь, чтобы подлизать базальту (типа у других плохо, а у базальта хорошо)?

Это ты (не только, правда) начал, что веер пальцев у CentOS лучше растопырен. А тут на тебе.

«слушать только tcp на всех интерфейсах» и «слушать всё только на lo». Офигеть однотипно.

И в том, и в другом случае меняется поведение для других приложений. В этом и однотипность. «Чуть-чуть беременна», как я уже писАл.

В ALT root-а вовсе по ssh не пускают по-умолчанию

То вопит о remote code execution, то пыжится «у нас по ссш рута не пускают». Какой-то ты непоследовательный. Ты, кстати, слова свои подтвердишь, или продолжишь впустую кудахтать? Продемонстрируй RCE в memcached на дефолтной CentOS.

Это ты начал, что веер пальцев у CentOS лучше растопырен. А тут на тебе.

На тебе что? Неэксплуатируемая в CentOS без специальной настройки файервола уязвимость memcached?

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

И в том, и в другом случае меняется поведение для других приложений.

Ты предлагаешь дыры не закрывать? Ты осознанно прикидываешься, или правда настолько туп? Суть и есть в том, что тем, кто udp не использует, системы не сломали.

То вопит о remote code execution

Что? 8-()

то пыжится «у нас по ссш рута не пускают»

Про пароль рута ты начал. Я за язык не тянул.

Продемонстрируй RCE в memcached на дефолтной CentOS

Отмотай обратно и дай ссылку на сообщение, где я писал про remote code execution.

Неэксплуатируемая в CentOS без специальной настройки файервола уязвимость memcached?

Не мешай мух с котлетами.

Но, коль ты затронул, да: и центос, и дебиан, и зюзя — все они качеством выше базальтовых поделок.

Мы второй день обсуждаем качество отдельно взятого пакета, которое вовсе не в пользу CentOS. Так что вопрос ещё, где поделка.

Ты предлагаешь дыры не закрывать?

Вообще-то, это ты предлагаешь: Выпуск дистрибутивов Альт Сервер, Альт Рабочая станция и Альт Образование версии 8.2 (комментарий)
Но как только на совместимость таки забили и отключили UDP, а я тебе на это указал, ты, почему-то, решил написать, что это я предлагаю дыры не закрывать. Ты красавец просто. :-)

Ты осознанно прикидываешься, или правда настолько туп?

Нет слов... Но ты мастер передёргивания, да.

Что? 8-()

CVE перепутал.

Отмотай обратно и дай ссылку на сообщение, где я писал про remote code execution.

Продемонстрируй DDoS через memcached на дефолтной CentOS
fixed

Про пароль рута ты начал. Я за язык не тянул.

Т.е. руту можно простой пароль ставить, если по ssh его логин запрещён?

Не мешай мух с котлетами.

Т.е. ты признаёшь, что проблема не у дистрибутива, а у дебилов выключающих firewall. Ну наконец-то.

Мы второй день обсуждаем качество отдельно взятого пакета

Мы можем хоть тысячу и один день обсуждать, что зарплата выросла вдвое. Только мы сделаем неправильные выводы, если при этом не вспомним, что за это время цены выросли более чем в два раза.

Пакет для дистрибутива собран? Мейтейнер знает, что в CentOS firewall включен из коробки. На кой ему менять дефолтные параметры, если на безопасность системы оно не повлияет? Пользователь сам решит на какой/какие интерфейсы ему вешать демона.

Вообще-то, это ты предлагаешь…
Но ты мастер передёргивания, да.

Значит правда не понимаешь… бида. Разжёвываю: у пользователя простыня на sh, которой он может просто пакеты на локалхост установить, а может и целую ферму развернуть. Мы не знаем, что там у него. На этапе установки этого memcached он может сказать echo -e "PORT=\nUSER=\nOPTIONS=" > /etc/sysconfig/memcached, а может sed -i 's/""/"-l 10.8.0.1"/' /etc/sysconfig/memcached, а может ничего не делать, ибо у тебя в документации он прочитал, что по-умолчанию демон будет слушать нужный ему 172.16.2.59, который у него всегда находится в безопасном окружении. И как он к демону подключается ты тоже не знаешь. Может по udp, может по tcp, а может через unix socket. А может не простыня и не на sh.
Находят в memcached опасный баг, решение которому только одно — отключить поддержку udp.

Если ты примешь патч приравнивающий отсутсвтие -U 11211 к -U 0, ты сломаешь сервис только тем, у кого он изначально «сломан». Если ты вместе с этим\вместо этого пропишешь "-l 127.0.0.1", ты сломаешь сервис даже тем, кого баг не затронул, а этого делать нельзя. Поэтому в рамках релиза либо программно отключаем то, что починить нельзя, либо в документацию добавляем «посоны _вот_это_ отключить нужно, ибо разрабы страшный баг ещё не пофиксили».

Но возвращаясь к твоему изначальному визгу: таким образом настроенный memcached.centos.rpm никаким образом не влияет на безопасность, ибо тот, кто использует дефолт, получит висящий на закрытом firewalld udp/11211 демон, а остальные либо намеренно отключат эту привязку, либо намеренно её включат и откроют порт в firewall.

И нормальный пользователь, пользуясь твоими словами, не спорил бы тут со мной третий день, а пошёл и оформил багрепорт в openvz по поводу отсутствия firewall в образе.

Т.е. ты признаёшь, что проблема не у дистрибутива, а у дебилов выключающих firewall. Ну наконец-то.

Нет, проблема у тех, кто опасные сервисы заранее, на всякий случай, кишками наружу вешает, а не тогда, когда это реально требуется. Интересно, кстати, а всякие SQL тоже так же?

Мейтейнер знает, что в CentOS firewall включен из коробки.

Есть много вариантов его выключения. Просто ошибка в конфигурировании, например. При такой массовости тут вопрос не «будет ли», а «когда это случится». А «подарок» уже терпеливо ждёт.

Значит правда не понимаешь… бида.

Это у тебя бида.

Если ты вместе с этим\вместо этого пропишешь "-l 127.0.0.1", ты сломаешь сервис даже тем, кого баг не затронул,

Это сломает сервис только тем, кто
а) вовсе не лазил в настройки memcached;
б) при этом, использует его не на локалхосте.

То есть, людей с первым и вторым твоими случаями это не затронет, так как %config(noreplace) же наверняка, да?

Но ты не уловил основной лейтмотив:

Почему в ALT это сделали 7 (!) лет назад, а в RH/CentOS додумались совсем недавно. Так, что попало в RHEL7 ?

И нормальный пользователь, пользуясь твоими словами, не спорил бы тут со мной третий день, а пошёл и оформил багрепорт в openvz по поводу отсутствия firewall в образе.

Это верно, но спорит тут с тобой не пользователь CentOS. И у меня нет в планах её где-либо ставить (выбор клиента - это его личные крокодилы).

Нет, проблема у тех,…

у кого после установки пакета демон себя ведёт так, как в документации проекта описано?

Есть много вариантов его выключения. Просто ошибка в конфигурировании, например.…

Так pourquoi ты долбоящеров к серверам подпускаешь?) И какая ещё причина может быть?

Это сломает сервис только тем, кто вовсе не лазил в настройки memcached при этом, использует его не на локалхосте.

Так и с какого перепугу ты им сервис ломать будешь, если их баг не задевает?

То есть, людей с первым и вторым твоими случаями это не затронет, так как %config(noreplace) же наверняка, да?

Как это не затронет? Им из-за твоего самодурства придётся автоматизацию развёртывания серверов перенастраивать, а им на баг udp плевать, ибо они udp не используют, а вот tcp используют.

Почему в ALT это сделали 7 (!) лет назад, а в RH/CentOS додумались совсем недавно.

До чего додумались-то? Не путай дефолтный конфиг и патч на бинарник. Ты продемонстрируй как ты подключишься к udp/11211, если он iptables закрыт. Или ты так, покукарекать «наш дифолт лучше»? Не лучше. Нормальный админ, когда разворачивать систему будет, в конфиг заглянет и внесёт нужные изменения, или убедится, что они уже есть.
А дефолт такой потому что RHEL либо решили заранее не идти в разрез с документацией memcached, где написано «по дефолту на всех интерфейсах», либо в приоритете ЦА которой к memcached доступ по сети нужен; а базальт либо срать хотел на документацию, либо в приоритете маленькие сервера с локальным php-memcached. Вопрос лишь того, кому вызвать sed, ибо уровень безопасности оно не снижает.

Это верно, но спорит тут с тобой не пользователь CentOS

И наружу торчит udp/11211 не у пользователя centos, а у пользователя кривой сборки на основе centos. И, как ты выше уже сказал, раз вызвался ему помочь, то пошёл бы и настрочил репорт автору этого образа в openvz. Если бы memcached в этом образе из коробки был (а может и есть, кстати…) и был настроен на прослушивание udp/1121@eth0 автором этого образа, ты бы тоже тут кукарекал, что CentOS плохой? А какая разница, что именно не так настроил тот, кто образ делал, если явная проблема возникла из-за его действий?

Почему в ALT это сделали 7 (!) лет назад, а в RH/CentOS додумались совсем недавно.

До чего додумались-то?

До того, что не надо сервисы голым задом в сеть выставлять по умолчанию, в надежде на файрвол и прочее. В ALT, на самом деле, додумались раньше, это memcached не так давно появился. А тот же MySQL, сколько помню, со skip-networking по-умолчанию всегда был и т.п. Всё слушают только совсем уж очевидные штуки, а-ля ssh, всякие web и т.п.

Им из-за твоего самодурства придётся автоматизацию развёртывания серверов перенастраивать

Это проблема, высосанная из пальца. Единственное, что, действительно, плохо, это смена конфигов в рабочей системе, если эти конфиги не правили.

а базальт либо срать хотел на документацию, либо в приоритете маленькие сервера с локальным php-memcached

Это ты на Debian так наехал до кучи, да? И на RedHat (ты же сам нашёл, что в Федоре поменяли уже, значит и до RHEL доползёт когда-нибудь)? :-)

и был настроен на прослушивание udp/1121@eth0 автором этого образа, ты бы тоже тут кукарекал, что CentOS плохой?

Я проверил конфиг по-умолчанию. Ты забыл? А я писал.

До того, что не надо сервисы голым задом в сеть выставлять по умолчанию, в надежде на файрвол и прочее.

Я и говорю, что ЦА — LAMP-админы. У RHEL ЦА заметно шире.

Это проблема, высосанная из пальца.

Воспроизводимость высосана из пальца?) Только если для мамкиных админов. За пределами локалхоста гарантия, что в случае чп сервис быстро развернётся, важна.

Я проверил конфиг по-умолчанию. Ты забыл? А я писал.

Ты проверил систему развёрнутую из ZVEPb Edition. Если ты выключаешь firewall, ты _должен_ убедиться, чтобы ничего лишнего не торчало наружу. Если он включен, тебе _следует_ убедиться, но даже если и пропустишь какой из них, firewall позволит сохранить систему в безопасности. Но в любом случае, адекватный человек не будет выключать firewall на сервере доступном извне.

Это ты на Debian так наехал до кучи, да?

Дебиан — коммьюнити проект, они демонов даже запускают и в автозагрузку во время установки. И подстилки подкладывают, лишь бы дебилушка себе в ногу не выстрелил и не убежал в коммерческие дистрибутивы с поддержкой. В Enterprise подразумевается, что обслуживанием занимаются квалифицированные люди.

в Федоре поменяли уже, значит и до RHEL доползёт когда-нибудь

Федора тоже community project, хоть и спонсируемый Red Hat. И таки да, после таких залётов со стороны memcached, вряд ли кто-то в здравом уме в ≥2018 будет memcached и по tcp (не говоря уже про udp) использовать. К выходу CentOS 8 соберут статистику и если сеть окажется совсем ненужной, сделают -l localhost, но ванговать не буду.

За пределами локалхоста гарантия, что в случае чп сервис быстро развернётся, важна.

Ты делаешь мне смешно, рассказывая, что конфиги, при развороте сервиса, правятся sed-ом от дефолта, а не кладутся готовые целиком.

Ты проверил систему развёрнутую из ZVEPb Edition

Нет, я посмотрел rpm-ку.

В Enterprise подразумевается, что обслуживанием занимаются квалифицированные люди.

О, энтерпрайз... Ога. :-) Ну вот он тебе, этот энтерпрайз. Увидели. (Опять ржу - энтерпрайз, sed-ом рисующий конфиги...)

К выходу CentOS 8 соберут статистику и если сеть окажется совсем ненужной, сделают -l localhost, но ванговать не буду.

Через сколько лет после ALT? Десять уже будет?

Ты проверил систему развёрнутую из ZVEPb Edition.

Ну так вот. Резюмируем.

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

В CentOS (и, очевидно, RHEL) безопасность обеспечивается на уровне дистрибутива, и шаг влево/вправо приравнивается к побегу и карается, практически, расстрелом. С одним ssh и без файрвола (зачем он, если интерфейс слушает только ssh?) какой-нибудь чайник может доустановить произвольный пакет и, без донастроек, получить спецэффекты.

Беда в том, получается, что CentOS/RHEL не ориентирована на массового пользователя, но, тем не менее, такие, как ты, пропагандируют массовое использование этого Ынтырпрайза.

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

Ты гарантируешь, что у всех пользователей так? Если нет, учитывать и это должен. Или на часть подписок можно забить? Или ты будешь за свой счёт учить всех абонентов «как правильно»?

Нет, я посмотрел rpm-ку.

Для этой rpm система готовая с firewall включеным. А ты привык, что в целевой системе бардак, вот и кудахчешь.

Через сколько лет после ALT? Десять уже будет?

Когда не останется пользователей, которым нужен memcached по сети. Ты выдаёшь отсутствие серьёзных клиентов у базальта (или ориентирование на мамкиных админов серверов с вордпрессом) за достижение. Хотя на деле тут факап мемкэшд после которого и крупные проекты вынуждены перестраивать подход. И в зависимости от этих перетрубаций и будет принят дефолт для RHEL8: -U0 -l any или -l localhost, или ещё что.

Ну так вот. Резюмируем.

В ALT не обеспечивают безопасность на уровне ОС. И если один из мейтейнеров выставит порт наружу, то пользователей легко смогут поиметь.

В CentOS (и, очевидно, RHEL) безопасность обеспечивается на уровне дистрибутива, и даже если обнаружится дыра в софте, мейтейнер которого принял решение, что нет необходимости ужесточать настройки сильнее дефолта, пользователи останутся в безопасности, т. к. даже в минимальной поставке из коробки безопасно настроены firewall и SELinux

Беда в том, получается, что некоторые не умеют определить причинно-следственные связи и ноют, если где-то не попало под их привычки. И ладно бы они просто ныли, так они ещё кукарекают, что подход «не думай, тыкай тяп-ляп и готово» — нормальный подход.

ftfy