Comments 117
Если у кого-то вдруг временно простаивает железо, с радостью приму приглашение воспользоваться им в благих целях веб-аналитики.

Доступы к сожалению не дам но могу закачать код и запустить у себя
Это намек на запятые. Вот, я вам немного отсыплю — ,,,,,,,,,,,,,,,,,,,
UFO landed and left these words here
К товарищам минусующим. Мне не жалко одной из своих виртуалок для такого дела. Или у кого-то вызвало сомнение правдивость моих слов?
Надо сказать это довольно неплохой показатель, можно было ожидать % больше. Количество «админов», которые всё настраивают исключительно по говнотуториалам, после чего пишут свой собственный — ИМХО повыше будет.
Не стоит забывать, что большинство < зачеркнуто >ГС< /зачеркнуто > сайтов вообще не используют memcached. 39 000 все таки не маленькая цифра если речь идет об ip адресах, а не доменах. Летом я вообще пальцем в небо тыкал и 11211 оказался открытым на IT ресурсе habrahabr.ru/post/190260/
Печально, что я вижу в списке по прежнему знакомые мне ресурсы.
Выкатить-то не грех (разве что я бы DVCS использовал — Git, например); грех не закрыть её.
Всем этим сайтам я отправил уведомления о том, что они стали героями статьи. На Ростелекоме доступ закрыли прямо когда я подключился и делал запросы, похвальная скорость работы админов.

Что обычно хранится на «публичных» memcached серверах?

Очень часто это куски вёрстки, либо html целых страниц, массивы чисел, мелкие тексты. Иногда ключами выступают sql-запросы, так что видна ещё и структура базы.


А как вы узнали наборы ключей, по которым надо делать запросы? В memcache же отсутствует возможность получения списка ключей.
Помнится, в отладочных целях пытался с помощью PHP получить все пары ключ-значение — безрезультатно. Может быть, конкретная реализация memcached не позволила.
У мемкешеда есть текстовой протокол, зашёл на сокет, получай прямо командой что хочешь.
Я когда-то писал «однострочник» для получения ключей и значений:

echo 'stats items' | nc localhost 11211 | while read line; do echo $line | grep -Po 'STAT items:\d+' | grep -Po '\d+'; done | sort -u | xargs -L1 -i echo 'stats cachedump {} 100' | nc localhost 11211 | grep 'ITEM' | sed 's/ITEM \([^ ]\+\) .*/\1/' | xargs -L1 -i echo 'get {}' | nc localhost 11211

Вроде бы работает.
Сколько лишнего… а чего не так?
nc localhost 11211 <<<"stats items" | awk -F: '/STAT items:[0-9]+/{if (!a[$2]++) print $2}' | xargs -I{} echo 'stats cachedump {} 100' | nc localhost 11211 | awk '/ITEM/{print $2}' | xargs -n1 echo get | nc localhost 11211
Да у вас и без этого там жести хватает :) Зачем цикл, например? К чему такие избыточные xargs? Используется Perl-regexp в grep (а он далеко не везде есть) ради «\d» и так далее :)
Не беда:
nc localhost 11211 <<<"stats items" | sed -n '/STAT/{s/[^:]*:\([^:]*\).*/stats cachedump \1 100/;p}' | sort -u | nc localhost 11211 | sed -n '/ITEM/{s/[^ ]* \([^ ]*\) .*/get \1/;p}' | nc localhost 11211
Вы меня ставите в невыносимые условия:
nc localhost 11211 <<<"stats items" | grep -Po '(?<=STAT items:)\d+' | sort -u | xargs -I. echo stats cachedump . 100 | nc localhost 11211 | grep -oP '(?<=ITEM )\S*' | xargs -n1 echo get | nc localhost 11211
Горшочек, не вари :)

Кстати, этот вариант мне наиболее близок (понятен). Хм, почему я так не сделал?

Ваше Command Line Fu намного сильнее моего. Ушел тренироваться.
А почему они в мемекшд не запретят по умолчанию такую конфигурацию? Зачем быть insecure by default
— How do I authenticate?
— You don't!
В мемкеше не предусмотрено авторизации впринципе. Очевидно, для повышения производительности
Тогда, видимо, и остальные сервера авторизации не должны иметь?
Если из них убрать сущность «пользователь», то её там и не будет. А в memcached можно её добавить, никто не мешает.
Расскажите зачем она СУБД? Думаю, в большинстве случаев (если иметь ввиду сайты), авторизация используется просто как экран, никакого разделения по пользователем там нет. SQLite без неё вполне обходятся.
В большинстве случаев есть как минимум два пользователя — рут и пользователь БД сайта, с правами только на неё.
В большинстве случаев сайту хватает одного пользователя и одной БД.
Угу, но нужен ещё пользователь-администратор как минимум для самой СУБД. И это если не считать, что большинство сайтов находятся на шаредхостинге и работают с одной СУБД десятки, если не сотни и тысячи сайтов.
Видите как легко вы пришли к пониманию, зачем в мемкешеде могут понадобятся пользователи.
Мемкешед другой сценарий использования обычно имеет — один или несколько серверов обслуживают один хайлоад сайт.
Догадайтесь почему Мемкешед обслуживает только один сайт.
Это же не БД. Нет разных уровней доступа. Не нужно делить ресурсы. Не нужны там пользователи.
Во-первых, это БД. Всё, что имеет данные и позволяет производить с ними операции — БД. Но это просто чтобы развеять ваше заблуждение.
Во-вторых, можете прочитать диалог выше. Увидите, что если что-то используется как нечто без авторизации, то это только потому что авторизации там нет.
В-третьих, SSH не БД, а авторизацию имеет. Из чего следует вывод: чтобы иметь авторизацию не надо быть БД.
Не в этом смысле. Авторизация внутри нужна, когда возможны разные уровни доступа. Тут их нет. А просто контроль доступа легко реализуется другими средствами.
А what вы предлагаете делать? Аuthenticate там нет, не listen на внешнем address? У многих более чем один server, admin any way будет на внешний address его configure.
UFO landed and left these words here
Принимать соединения, на этом порту, только с определенных адресов?
Какую такую? Слушать порт на всех интерфейсах? Что предлагаете взамен?
В тех дистрах линукса, что я видел, memcached из коробки слушал только 127.0.0.1 и не был доступен из внешних сетей.
До кучи можно попробовать поискать сервера с MongoDB, которые по дефолту так же смотрят наружу.
Из чуть более 3.5 млн. сайтов зоны .ru, которые ответили моему скрипту по http, 39 тысяч имеют запущенный и открытый всему миру сервер memcached на стандартном порту 11211. Это количество настолько чудовищно,


Порядка 1%? Честно говоря, не тянет на чудовищно.
Можно предположить, что на 90% сайтов memcached вообще не используется.
Кстати, не могли бы выложить свой скрипт. Интересно, откуда берёте «перечень сайтов»?
Автор, Вы сделали хорошее дело, что обнаружили уязвимость и написали о ней статью, привлекая внимание общественности.

Но, по имеющимся у меня данным, Вы не написали админам ресурсов. Ай-ай-ай вообще-то!

p.s.
да, имею отношение, да, оперативно закрыли.
не написал и в нашем случае. И положил болт на ЛС с просьбой на время скрыть название сайта, раз проблемой уже занимаются (что непросто для не-IT компаний ночью, в неурочное время).

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

Правильный путь:
"Выпуск этой статьи был задержан ожиданием пока opera.com закроет уязвимость на всех своих серверах."
"абсолютно все, кто мог пострадать, получили предупреждения об уязвимости с точной датой обнародования заранее."
(с) Были получены исходники 3300 глобальных интернет-проектов

Неправильный путь:
Я Д'Артаньян, и это ваши проблемы «почему на вашем сайте ещё и баг-репорты не доходят куда надо».

Да будьте же ответственны, в конце-концов, раз призываете к ответственности и профессионализму!
Меня честно говоря удивляет, почему по-умолчанию дистрибутивы не закрывают все кроме 80 порта на нелокальных сетевых интерфейсах. Кто знает, тот легко исправит если что нужно, а кто не знает, тому и не надо в 99% случаев держать что-то еще открытым.
кто не знает, тому и не надо в 99% случаев держать что-то еще открытым.

Весьма спорно. Как закрывать, кстати, полностью дропать все входящие пакеты? Или только запросы на установление соединения? И почему для 80-го исключение? :)
>Как закрывать, кстати, полностью дропать все входящие пакеты? Или только запросы на установление соединения?

Да как хотите. Новичкам пофиг.

>почему для 80-го исключение?

Потому что 99% серверов которые поддерживают люди со слабой подготовкой это HTTP сервера.
А с чего вы поставили знак равенства между сервер и дистрибутив? Плюс нужен как минимум ssh. Ещё обычно smtp/pop3, ftp и т. д.
>сервер и дистрибутив

Потому что из дистрибутива идет дефолтная конфигурация, которую, как известно, никто не меняет. (См эту статью про 64M кэша у мемкеша)

>Плюс нужен как минимум ssh. Ещё обычно smtp/pop3, ftp

Ssh понятно. Еще 443 для https. В принципе можно smtp/pop3 хотя почтовые сервера нужны гораздо реже (много-много реже) + если их настраивают скорее всего квалификации на открытие портов хватит. Так что не обижусь если закроют.
443 тоже не нужен по дефолту. Кто сумел сгенерить сертификат, то и порт откроет.
UFO landed and left these words here
RHEL/CentOS так и делают примерно. Только вот нафига 80? Только 22 и все.
Ну а насчет
на нелокальных сетевых интерфейсах
как дистрибутив должен узнать, какие интерфейсы у него нелокальные, спрашивать при установке? Особенно если интерфейс всего один (98% случаев на всяких VPS/VDS и даже дедиках).
>Только вот нафига 80? Только 22 и все.

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

>как дистрибутив должен узнать, какие интерфейсы у него нелокальные

Например так: ru.wikipedia.org/wiki/Частный_IP-адрес
Кто определяет, что нужно большинству и на каких основаниях? И схера ли если на интерфейсе айпишник из rfc1918 должно сразу означать, что выше не настроен статический NAT с публичного адреса? Теперь дистрибутив должен при установке еще и сделать запрос на внешний сервер чтобы это выяснить, да?
В общем, предлагаю перестать мыслить узколобо и немного расширить взгляд.
>В общем, предлагаю перестать мыслить узколобо и немного расширить взгляд.

Да можно придумаьт миллион исключений. Я говорю о том, что в 90% случаев это ведет только к проблемам с безопасностью, а в остальных нисколько не затрудняет конфигурацию сервера.
>78.4% данных в статистических отчетах берутся из головы (с)

Я правильно понимаю, что на вашем сервере открыты все порты? Или все-таки whitelist? Тогда кому вообще нужно иметь открытыми все по умолчанию?
>О каком сервере идет речь?

О любом. Лично у меня, ни на каком.
У меня нет никаких серверов.
Но на тех нескольких сотнях, к которым я имею какое-либо отношение, открыты совершенно разные порты, причем на большинстве они вообще не совпадают друг с другом. И 80 среди них практически отсутствует, наверно 3-5% всего.
>И 80 среди них практически отсутствует, наверно 3-5% всего.

И прекрасно. Это значит скорее всего а) На 80 порту там ничего и не висит и проблем с безопаснотью нет (т.к. чтобы вешаться на 80 порт надо быть администратором или форвардить, что опять же означает что закрыть порт человеку минуты) б) Квалификация администраторов подразумевает что закрыть порт для них вообще не задача. Таким образом никто не проигрывает. Хоть сколько-то приличным администратом не стоит проблема закрыть порт, у гигантской массы леменгов меньше проблем с безопасностью.
Созданиеслишком стерильных условий и иллюзии защищенности для толпы леммингов не решит проблему с безопасностью, а только усугубит ситуацию. Потому как харденинг сервера и сервиса состоит из закрытия портов лишь на 2-3 процента.
Более того, открою маленький секрет. Для того, чтобы НЕ предоставлять миру доступ к тому или иному порту на том или ином интерфейсе, фаервол совсем не нужен. Сюрприз, правда?
>Сюрприз, правда?

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

Не спасут, но станет лучше.
Я правильно понимаю, что на вашем сервере открыты все порты? Или все-таки whitelist? Тогда кому вообще нужно иметь открытыми все по умолчанию?

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

Что у нас неправильно?
>Что у нас неправильно?

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

Их надо закрывать, вести список открытых/закрытых
Таким образом, запрета всех портов никак не помешает вам, но поможет новичкам которые об этом вообще не думают.

Скорее доставит кучу проблем и кучу сообщений «ПАМАГИТЕ НИЧО НИРАБОТАЕТ» на тематических и не очень ресурсах.
>Скорее доставит кучу проблем и кучу сообщений «ПАМАГИТЕ НИЧО НИРАБОТАЕТ» на тематических и не очень ресурсах.

Мало кому нужно что-то кроме 80 наружу. Все-таки большинство — это всякие мелкие односерверные сайты на дешевых виртуалках. А тем таки кому надо, есть надежда, что задумаются, найдут на форумах информацию в которой будет предлагаться открыть не всем наружу, а только заданным.
У меня на домашнем сервере наружу торчит не меньше 20 портов. В основном диапазоны >40 000. Все относительно.
>Кто определяет, что нужно большинству и на каких основаниях?

Статистика.
Плюсую комментарий, но.
100% пользователь перестали кликать на кнопку «Пуск», после того как мы скрыли с экрана кнопку «Пуск»… кнопка не нужна! Статистика. Упрямая штука!
У меня есть eth0, eth1, eth2, eth3, tun0 и tun1. Какие из них не являются локальными?

И да, что делать с портами 22, 443, 81, 8080, 8081? Первые два нужны очевидно для чего, на трех последних иногда тоже сайты поднимаются.
UPD: на тот случай, ежели кто-нибудь считает ответ слишком очевидным, чтобы даже произносить его.

Отгадка
Внешние интерфейсы — eth0 и tun1.
Нету там ответа, в этом RFC
tun1 находится в серой подсети, но он — внешний.
Ок, тогда с другой стороны подойдём. Если вы админ в сети, то в первую очередь (в т.ч. используя RFC1918 и другие подручные средства) должны разобраться, какие сетевые интерфейсы у вас локальные, а какие — нет.
Потом определить, какое ПО должно работать на открытых в мир портах.
Потом соответственно всё настроить.

К вашему сведению, интерфейсы можно легко переименовать.
Согласен. Но здесь рассматривался вариант настроек по умолчанию на тот случай, когда админ ничего не понимает в сетевой безопасности — а значит, классифицировать интерфейсы надо без его участия. Я утверждаю, это невозможно.

PS Переименовать tun1 в eth4 довольно затруднительно…
ИМХО, админа, не разбирающегося где у него какой интерфейс, и близко допускать к настройкам ПО нельзя!
Тогда с чем вы спорите? Напомню, ветка началась вот с этого:
Меня честно говоря удивляет, почему по-умолчанию дистрибутивы не закрывают все кроме 80 порта на нелокальных сетевых интерфейсах. Кто знает, тот легко исправит если что нужно, а кто не знает, тому и не надо в 99% случаев держать что-то еще открытым.
UFO landed and left these words here
UFO landed and left these words here
Ну, вот у меня стоит 64 МБ, не используется даже наполовину. Мог бы сменить на 32, только зачем эта экономия на спичках?
UFO landed and left these words here
А чем плох подход «сейчас пик 32, поставим в два раза больше на всякий пожарный… Ой, не надо ставить — уже стоит».
UFO landed and left these words here
Для полноты статьи не хватает туториала для горе-админов «как определить, что memcached открыт, и как с этим жить»).
UFO landed and left these words here
Спасибо! Не знаете, доступны ли актуальные списки для других (не национальных) доменов?

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

Only those users with full accounts are able to leave comments. Log in, please.