Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 117
Если у кого-то вдруг временно простаивает железо, с радостью приму приглашение воспользоваться им в благих целях веб-аналитики.
Доступы к сожалению не дам но могу закачать код и запустить у себя
Отличный идея! :)
Какой именно сервер нужен? Канал, hdd, memory?
Какой именно сервер нужен? Канал, hdd, memory?
Надо сказать это довольно неплохой показатель, можно было ожидать % больше. Количество «админов», которые всё настраивают исключительно по говнотуториалам, после чего пишут свой собственный — ИМХО повыше будет.
Не стоит забывать, что большинство < зачеркнуто >ГС< /зачеркнуто > сайтов вообще не используют memcached. 39 000 все таки не маленькая цифра если речь идет об ip адресах, а не доменах. Летом я вообще пальцем в небо тыкал и 11211 оказался открытым на IT ресурсе habrahabr.ru/post/190260/
Печально, что я вижу в списке по прежнему знакомые мне ресурсы.
Печально, что я вижу в списке по прежнему знакомые мне ресурсы.
Доверить мемкэшу такие вещи, как данные из БД, и не закрыть к нему извне доступ, пожалуй, эпичнее, чем выкатить на продакшн папку .svn
Можно даже что-то интересней получить из memcached.
Всем этим сайтам я отправил уведомления о том, что они стали героями статьи. На Ростелекоме доступ закрыли прямо когда я подключился и делал запросы, похвальная скорость работы админов.
Что обычно хранится на «публичных» memcached серверах?
Очень часто это куски вёрстки, либо html целых страниц, массивы чисел, мелкие тексты. Иногда ключами выступают sql-запросы, так что видна ещё и структура базы.
А как вы узнали наборы ключей, по которым надо делать запросы? В memcache же отсутствует возможность получения списка ключей.
Да ну? habrahabr.ru/post/190260/
Хм, похоже это можно только в этой реализации клиента. Например, через клиент это сделать не получится — code.google.com/p/memcached/wiki/NewCommands
Идея понятна, спасибо.
Идея понятна, спасибо.
Помнится, в отладочных целях пытался с помощью 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
Я не умею готовить awk :(
Да у вас и без этого там жести хватает :) Зачем цикл, например? К чему такие избыточные 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
А почему они в мемекшд не запретят по умолчанию такую конфигурацию? Зачем быть insecure by default
— How do I authenticate?В мемкеше не предусмотрено авторизации впринципе. Очевидно, для повышения производительности
— You don't!
Это unix-way.
Тогда, видимо, и остальные сервера авторизации не должны иметь?
Которые не имеют сущности «пользователь» не должны.
Если из них убрать сущность «пользователь», то её там и не будет. А в memcached можно её добавить, никто не мешает.
Не нужна она кэшеру, а СУБД, например, нужна.
Расскажите зачем она СУБД? Думаю, в большинстве случаев (если иметь ввиду сайты), авторизация используется просто как экран, никакого разделения по пользователем там нет. SQLite без неё вполне обходятся.
В большинстве случаев есть как минимум два пользователя — рут и пользователь БД сайта, с правами только на неё.
В большинстве случаев сайту хватает одного пользователя и одной БД.
Угу, но нужен ещё пользователь-администратор как минимум для самой СУБД. И это если не считать, что большинство сайтов находятся на шаредхостинге и работают с одной СУБД десятки, если не сотни и тысячи сайтов.
Видите как легко вы пришли к пониманию, зачем в мемкешеде могут понадобятся пользователи.
Мемкешед другой сценарий использования обычно имеет — один или несколько серверов обслуживают один хайлоад сайт.
Это же не БД. Нет разных уровней доступа. Не нужно делить ресурсы. Не нужны там пользователи.
Во-первых, это БД. Всё, что имеет данные и позволяет производить с ними операции — БД. Но это просто чтобы развеять ваше заблуждение.
Во-вторых, можете прочитать диалог выше. Увидите, что если что-то используется как нечто без авторизации, то это только потому что авторизации там нет.
В-третьих, SSH не БД, а авторизацию имеет. Из чего следует вывод: чтобы иметь авторизацию не надо быть БД.
Во-вторых, можете прочитать диалог выше. Увидите, что если что-то используется как нечто без авторизации, то это только потому что авторизации там нет.
В-третьих, SSH не БД, а авторизацию имеет. Из чего следует вывод: чтобы иметь авторизацию не надо быть БД.
Не в этом смысле. Авторизация внутри нужна, когда возможны разные уровни доступа. Тут их нет. А просто контроль доступа легко реализуется другими средствами.
Но 127.0.0.1-то поставить по умолчанию можно же было?
А what вы предлагаете делать? Аuthenticate там нет, не listen на внешнем address? У многих более чем один server, admin any way будет на внешний address его configure.
Какую такую? Слушать порт на всех интерфейсах? Что предлагаете взамен?
В тех дистрах линукса, что я видел, memcached из коробки слушал только 127.0.0.1 и не был доступен из внешних сетей.
До кучи можно попробовать поискать сервера с MongoDB, которые по дефолту так же смотрят наружу.
Из чуть более 3.5 млн. сайтов зоны .ru, которые ответили моему скрипту по http, 39 тысяч имеют запущенный и открытый всему миру сервер memcached на стандартном порту 11211. Это количество настолько чудовищно,
Порядка 1%? Честно говоря, не тянет на чудовищно.
Кстати, не могли бы выложить свой скрипт. Интересно, откуда берёте «перечень сайтов»?
Можно еще проверить монгодб и германа
Автор, Вы сделали хорошее дело, что обнаружили уязвимость и написали о ней статью, привлекая внимание общественности.
Но, по имеющимся у меня данным, Вы не написали админам ресурсов. Ай-ай-ай вообще-то!
p.s.
да, имею отношение, да, оперативно закрыли.
Но, по имеющимся у меня данным, Вы не написали админам ресурсов. Ай-ай-ай вообще-то!
p.s.
да, имею отношение, да, оперативно закрыли.
не написал и в нашем случае. И положил болт на ЛС с просьбой на время скрыть название сайта, раз проблемой уже занимаются (что непросто для не-IT компаний ночью, в неурочное время).
Каждому хочется 15 минут славы, в общем.
Каждому хочется 15 минут славы, в общем.
Насчёт «положил болт» — ваше сообщение, отправленное после полуночи, я прочитал только сейчас.
Разумеется, я отправил уведомления всем сайтам, которые упомянуты в статье. Да, я не написал письмо напрямую админам, потому что их имейлов нет в свободном доступе. Я писал через официальную почту или форму поддержки. Давайте в личке разбираться, почему на вашем сайте ещё и баг-репорты не доходят куда надо.
Ошибаетесь.
Правильный путь:
"Выпуск этой статьи был задержан ожиданием пока opera.com закроет уязвимость на всех своих серверах."
"абсолютно все, кто мог пострадать, получили предупреждения об уязвимости с точной датой обнародования заранее."
(с) Были получены исходники 3300 глобальных интернет-проектов
Неправильный путь:
Я Д'Артаньян, и это ваши проблемы «почему на вашем сайте ещё и баг-репорты не доходят куда надо».
Да будьте же ответственны, в конце-концов, раз призываете к ответственности и профессионализму!
Правильный путь:
"Выпуск этой статьи был задержан ожиданием пока opera.com закроет уязвимость на всех своих серверах."
"абсолютно все, кто мог пострадать, получили предупреждения об уязвимости с точной датой обнародования заранее."
(с) Были получены исходники 3300 глобальных интернет-проектов
Неправильный путь:
Я Д'Артаньян, и это ваши проблемы «почему на вашем сайте ещё и баг-репорты не доходят куда надо».
Да будьте же ответственны, в конце-концов, раз призываете к ответственности и профессионализму!
А должен был?
Меня честно говоря удивляет, почему по-умолчанию дистрибутивы не закрывают все кроме 80 порта на нелокальных сетевых интерфейсах. Кто знает, тот легко исправит если что нужно, а кто не знает, тому и не надо в 99% случаев держать что-то еще открытым.
кто не знает, тому и не надо в 99% случаев держать что-то еще открытым.
Весьма спорно. Как закрывать, кстати, полностью дропать все входящие пакеты? Или только запросы на установление соединения? И почему для 80-го исключение? :)
>Как закрывать, кстати, полностью дропать все входящие пакеты? Или только запросы на установление соединения?
Да как хотите. Новичкам пофиг.
>почему для 80-го исключение?
Потому что 99% серверов которые поддерживают люди со слабой подготовкой это HTTP сервера.
Да как хотите. Новичкам пофиг.
>почему для 80-го исключение?
Потому что 99% серверов которые поддерживают люди со слабой подготовкой это HTTP сервера.
А с чего вы поставили знак равенства между сервер и дистрибутив? Плюс нужен как минимум ssh. Ещё обычно smtp/pop3, ftp и т. д.
>сервер и дистрибутив
Потому что из дистрибутива идет дефолтная конфигурация, которую, как известно, никто не меняет. (См эту статью про 64M кэша у мемкеша)
>Плюс нужен как минимум ssh. Ещё обычно smtp/pop3, ftp
Ssh понятно. Еще 443 для https. В принципе можно smtp/pop3 хотя почтовые сервера нужны гораздо реже (много-много реже) + если их настраивают скорее всего квалификации на открытие портов хватит. Так что не обижусь если закроют.
Потому что из дистрибутива идет дефолтная конфигурация, которую, как известно, никто не меняет. (См эту статью про 64M кэша у мемкеша)
>Плюс нужен как минимум ssh. Ещё обычно smtp/pop3, ftp
Ssh понятно. Еще 443 для https. В принципе можно smtp/pop3 хотя почтовые сервера нужны гораздо реже (много-много реже) + если их настраивают скорее всего квалификации на открытие портов хватит. Так что не обижусь если закроют.
RHEL/CentOS так и делают примерно. Только вот нафига 80? Только 22 и все.
Ну а насчет
Ну а насчет
на нелокальных сетевых интерфейсахкак дистрибутив должен узнать, какие интерфейсы у него нелокальные, спрашивать при установке? Особенно если интерфейс всего один (98% случаев на всяких VPS/VDS и даже дедиках).
>Только вот нафига 80? Только 22 и все.
Миллионы леммингов будут засорять интернет вопросами почему у них сервер недоступен. Все-таки большинству нужна именно эта функциональность, которая за супер редким исключением безопасна (а в тех когда опасна админ скорее всего хотя бы школу закончил и понимает что делает).
>как дистрибутив должен узнать, какие интерфейсы у него нелокальные
Например так: ru.wikipedia.org/wiki/Частный_IP-адрес
Миллионы леммингов будут засорять интернет вопросами почему у них сервер недоступен. Все-таки большинству нужна именно эта функциональность, которая за супер редким исключением безопасна (а в тех когда опасна админ скорее всего хотя бы школу закончил и понимает что делает).
>как дистрибутив должен узнать, какие интерфейсы у него нелокальные
Например так: ru.wikipedia.org/wiki/Частный_IP-адрес
Кто определяет, что нужно большинству и на каких основаниях? И схера ли если на интерфейсе айпишник из rfc1918 должно сразу означать, что выше не настроен статический NAT с публичного адреса? Теперь дистрибутив должен при установке еще и сделать запрос на внешний сервер чтобы это выяснить, да?
В общем, предлагаю перестать мыслить узколобо и немного расширить взгляд.
В общем, предлагаю перестать мыслить узколобо и немного расширить взгляд.
>В общем, предлагаю перестать мыслить узколобо и немного расширить взгляд.
Да можно придумаьт миллион исключений. Я говорю о том, что в 90% случаев это ведет только к проблемам с безопасностью, а в остальных нисколько не затрудняет конфигурацию сервера.
Да можно придумаьт миллион исключений. Я говорю о том, что в 90% случаев это ведет только к проблемам с безопасностью, а в остальных нисколько не затрудняет конфигурацию сервера.
78.4% данных в статистических отчетах берутся из головы (с)
>78.4% данных в статистических отчетах берутся из головы (с)
Я правильно понимаю, что на вашем сервере открыты все порты? Или все-таки whitelist? Тогда кому вообще нужно иметь открытыми все по умолчанию?
Я правильно понимаю, что на вашем сервере открыты все порты? Или все-таки whitelist? Тогда кому вообще нужно иметь открытыми все по умолчанию?
О каком сервере идет речь?
>О каком сервере идет речь?
О любом. Лично у меня, ни на каком.
О любом. Лично у меня, ни на каком.
У меня нет никаких серверов.
Но на тех нескольких сотнях, к которым я имею какое-либо отношение, открыты совершенно разные порты, причем на большинстве они вообще не совпадают друг с другом. И 80 среди них практически отсутствует, наверно 3-5% всего.
Но на тех нескольких сотнях, к которым я имею какое-либо отношение, открыты совершенно разные порты, причем на большинстве они вообще не совпадают друг с другом. И 80 среди них практически отсутствует, наверно 3-5% всего.
>И 80 среди них практически отсутствует, наверно 3-5% всего.
И прекрасно. Это значит скорее всего а) На 80 порту там ничего и не висит и проблем с безопаснотью нет (т.к. чтобы вешаться на 80 порт надо быть администратором или форвардить, что опять же означает что закрыть порт человеку минуты) б) Квалификация администраторов подразумевает что закрыть порт для них вообще не задача. Таким образом никто не проигрывает. Хоть сколько-то приличным администратом не стоит проблема закрыть порт, у гигантской массы леменгов меньше проблем с безопасностью.
И прекрасно. Это значит скорее всего а) На 80 порту там ничего и не висит и проблем с безопаснотью нет (т.к. чтобы вешаться на 80 порт надо быть администратором или форвардить, что опять же означает что закрыть порт человеку минуты) б) Квалификация администраторов подразумевает что закрыть порт для них вообще не задача. Таким образом никто не проигрывает. Хоть сколько-то приличным администратом не стоит проблема закрыть порт, у гигантской массы леменгов меньше проблем с безопасностью.
Более того, открою маленький секрет. Для того, чтобы НЕ предоставлять миру доступ к тому или иному порту на том или ином интерфейсе, фаервол совсем не нужен. Сюрприз, правда?
Я правильно понимаю, что на вашем сервере открыты все порты? Или все-таки whitelist? Тогда кому вообще нужно иметь открытыми все по умолчанию?
Что значит «открыты»? Специальной блокировки портов на уровне файерволла нет, есть демоны, которые слушают порты, которые им нужны, а для них вайтлист айпишников, с которых разрешен доступ. Плюс пару серверов глядящих непосредственно в мир.
Что у нас неправильно?
>Что у нас неправильно?
А теперь расскажите мне, как закрытие всех портов замедлит ваш процесс конфигурацию? Учитывая что вы выставляете вайтлист айпишников. А держать все открытые порты не проблема сама по себе, а просто защита от самого себя же что не забудешь сконфигурировать в будущем. Таким образом, запрета всех портов никак не помешает вам, но поможет новичкам которые об этом вообще не думают.
А теперь расскажите мне, как закрытие всех портов замедлит ваш процесс конфигурацию? Учитывая что вы выставляете вайтлист айпишников. А держать все открытые порты не проблема сама по себе, а просто защита от самого себя же что не забудешь сконфигурировать в будущем. Таким образом, запрета всех портов никак не помешает вам, но поможет новичкам которые об этом вообще не думают.
А теперь расскажите мне, как закрытие всех портов замедлит ваш процесс конфигурацию?
Их надо закрывать, вести список открытых/закрытых
Таким образом, запрета всех портов никак не помешает вам, но поможет новичкам которые об этом вообще не думают.
Скорее доставит кучу проблем и кучу сообщений «ПАМАГИТЕ НИЧО НИРАБОТАЕТ» на тематических и не очень ресурсах.
>Скорее доставит кучу проблем и кучу сообщений «ПАМАГИТЕ НИЧО НИРАБОТАЕТ» на тематических и не очень ресурсах.
Мало кому нужно что-то кроме 80 наружу. Все-таки большинство — это всякие мелкие односерверные сайты на дешевых виртуалках. А тем таки кому надо, есть надежда, что задумаются, найдут на форумах информацию в которой будет предлагаться открыть не всем наружу, а только заданным.
Мало кому нужно что-то кроме 80 наружу. Все-таки большинство — это всякие мелкие односерверные сайты на дешевых виртуалках. А тем таки кому надо, есть надежда, что задумаются, найдут на форумах информацию в которой будет предлагаться открыть не всем наружу, а только заданным.
>Кто определяет, что нужно большинству и на каких основаниях?
Статистика.
Статистика.
У меня есть eth0, eth1, eth2, eth3, tun0 и tun1. Какие из них не являются локальными?
И да, что делать с портами 22, 443, 81, 8080, 8081? Первые два нужны очевидно для чего, на трех последних иногда тоже сайты поднимаются.
И да, что делать с портами 22, 443, 81, 8080, 8081? Первые два нужны очевидно для чего, на трех последних иногда тоже сайты поднимаются.
UPD: на тот случай, ежели кто-нибудь считает ответ слишком очевидным, чтобы даже произносить его.
Отгадка
Внешние интерфейсы — eth0 и tun1.
Неужели ответ в RFC1918? :)
Нету там ответа, в этом RFC
tun1 находится в серой подсети, но он — внешний.
Ок, тогда с другой стороны подойдём. Если вы админ в сети, то в первую очередь (в т.ч. используя RFC1918 и другие подручные средства) должны разобраться, какие сетевые интерфейсы у вас локальные, а какие — нет.
Потом определить, какое ПО должно работать на открытых в мир портах.
Потом соответственно всё настроить.
К вашему сведению, интерфейсы можно легко переименовать.
Потом определить, какое ПО должно работать на открытых в мир портах.
Потом соответственно всё настроить.
К вашему сведению, интерфейсы можно легко переименовать.
Согласен. Но здесь рассматривался вариант настроек по умолчанию на тот случай, когда админ ничего не понимает в сетевой безопасности — а значит, классифицировать интерфейсы надо без его участия. Я утверждаю, это невозможно.
PS Переименовать tun1 в eth4 довольно затруднительно…
PS Переименовать tun1 в eth4 довольно затруднительно…
ИМХО, админа, не разбирающегося где у него какой интерфейс, и близко допускать к настройкам ПО нельзя!
Тогда с чем вы спорите? Напомню, ветка началась вот с этого:
Меня честно говоря удивляет, почему по-умолчанию дистрибутивы не закрывают все кроме 80 порта на нелокальных сетевых интерфейсах. Кто знает, тот легко исправит если что нужно, а кто не знает, тому и не надо в 99% случаев держать что-то еще открытым.
Для полноты статьи не хватает туториала для горе-админов «как определить, что memcached открыт, и как с этим жить»).
Статья понравилась
Каким образом вы получили список сайтов зоны .ru? :)
доступен на сайте рег.ру
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
1% всех сайтов рунета держит свой memcached открытым для мира. Немного статистики