Здравствуйте, Stanislaw K, Вы писали: SK>а напомни, пожалуйста, что мы в этой ветке обсуждаем?
Обсуждаем разумность применения несекьюрных протоколов администрирования и управления для железок, "потому что они и так стоят за NAT".
Точнее, цепочка рассуждений была следующая: железки нельзя втыкать в интернет без NAT -> поэтому NAT всегда есть -> поэтому можно не париться о размерности адресов, т.к. большинство адресов будут приватными.
Я подвергаю сомнению первый шаг этой цепочки — собственно, нужда в NAT с т.з. безопасности продиктована исключительно дегенеративными инженерными решениями.
Тому самому SMB, адвокатом которого вы выступаете, в тыщу раз удобнее просто воткнуть устройство "в интернет", отсканировать QR код на его коробке и настроить всё через панель управления на смартфоне. Чем городить NAT, настраивать порт форвардинг, VPN, и прочую неинтересную парикмахерской ерунду.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Разумность 16 байтных IP-адресов - ведь глупость сделали
Здравствуйте, netch80, Вы писали: N>>Потом проскочила одна реплика "любая схема с фиксированной длиной лучше схемы с переменной". N>Я её, пожалуй, тут приведу...
Скрытый текст
N>
N>Subject: re: IPng ADs Wish to Gauge Consensus on Address Length Requirements
N>To: SIPP Mailing list <sipp@sunroof2.eng.sun.com>,
N> big-Internet@munnari.oz.au
N>Date: Thu, 7 Jul 1994 15:35:29 -0500 (EST)
N>Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
N>From: "Daniel L. McDonald" <danmcd@sundance.itd.nrl.navy.mil>
N>Cc: mankin@cmf.nrl.navy.mil, sob@hsdndev.harvard.edu,
N> "Daniel L. McDonald" <danmcd@sundance.itd.nrl.navy.mil>
N>Message-Id: <9407072035.aa15952@sundance.itd.nrl.navy.mil>
>> Hi, TUBA, SIPP, CATNIP, BIG-INTERNET, and IETF:
N>Hi from SIPP, IETF, and BIG-INTERNET.
>> At this time it would appear to us that there is considerable consensus
>> that a fixed length, topologically structured, hierarchical
N>Yes, you said the magic words, "FIXED LENGTH." I have espoused the virtues
N>of fixed length addresses before. My biggest beef with variable length
N>addresses is the issue of maintaining additional state or taking additional
N>time to parse an address whose length I don't know at the start. Granted,
N>flow ID's and optimizing for certain common ("fast path") cases may help
N>this, but flow ID's still require tables with flow ID's for keys, and
N>today's common case may be tomorrow's exception. Authentication and
N>encryption also present problems similar to flow ID's with key lookup. I
N>don't want to rewrite my (statically configured) OS kernel in 4 years when
N>today's common cases no longer exist. (Although, admittedly, current trends
N>in OS research may render this argument obsolete.)
N>Parsing addresses is a problem all along the path (both network hops, and
N>within each system) an IPng datagram takes. Both routers and end-systems
N>have to parse addresses, at least to the point of finding a fast path. Our
N>implementation experience has shown us that variable length addresses adds a
N>whole new layer of complexity to things such as:
N>Yes, you said the magic words, "FIXED LENGTH." I have espoused the virtues
N>of fixed length addresses before. My biggest beef with variable length
N>addresses is the issue of maintaining additional state or taking additional
N>time to parse an address whose length I don't know at the start. Granted,
N>flow ID's and optimizing for certain common ("fast path") cases may help
N>this, but flow ID's still require tables with flow ID's for keys, and
N>today's common case may be tomorrow's exception. Authentication and
N>encryption also present problems similar to flow ID's with key lookup. I
N>don't want to rewrite my (statically configured) OS kernel in 4 years when
N>today's common cases no longer exist. (Although, admittedly, current trends
N>in OS research may render this argument obsolete.)
N>Parsing addresses is a problem all along the path (both network hops, and
N>within each system) an IPng datagram takes. Both routers and end-systems
N>have to parse addresses, at least to the point of finding a fast path. Our
N>implementation experience has shown us that variable length addresses adds a
N>whole new layer of complexity to things such as:
N>Since it is still fixed length it has none of the nightmares of
N>variable-length addresses.
>> longer than 16 byte fixed length address now.
N>I would like to see why we NEED any address space above 16-bytes. Does
N>anyone have any solid arguments as to why 16 bytes is not enough? I've seen
N>ones for 8, but not 16.
N>Also, let's consider alignment issues if picking a size above 16 bytes. 20
N>blows 8-byte alignment, 24 does not. (But of course, if 128-bit machines
N>happen, 24-byte addresses will be annoying on 128-bit machines.)
N>But hey, at least it's fixed length.
>> only 16 byte length addresses now but ability
>> to lengthen the address later.
N>This will add confusion to implementations, and smacks of variable-length.
N>Experience with OSI implementations shows that many do not handle NSAP's
N>greater than 20 bytes.
N>Absolutely not a good idea.
>> At this point the consensus among the IPng directorate
>> and on several of the mailing lists seems fairly clear
>> (a 16 byte length address is good for those things).
N>Yes, but IMHO, no MORE than 16 bytes.
>> This is a good time to bring forward your remaining views
>> about the requirements for address length for IPng.
N>My position can be best summarized as:
N> The SMALLEST possible fixed-length address. And that length
N> better have a good justification for why it cannot be smaller.
N>--
N>Dan McDonald | Mail: {danmcd,mcdonald}@itd.nrl.navy.mil --------------+
N>Computer Scientist | WWW: http://wintermute.itd.nrl.navy.mil/danmcd.html |
N>Naval Research Lab | Phone: (202) 404-7122 #include <disclaimer.h> |
N>Washington, DC | "Rise from the ashes, A blaze of everyday glory" — Rush +
N>Вот так, военный рявкнул — все взяли под козырёк.
Да ладно! Это какой-то финальный отрывок обсуждения.
I would like to see why we NEED any address space above 16-bytes. Does anyone have any solid arguments as to why 16 bytes is not enough? I've seen ones for 8, but not 16.
То есть 8 байтов мало почему-то мало и были какие-то аргументы. При этом кто-то хотел больше 16-и
А из этого
At this point the consensus among the IPng directorate and on several of the mailing lists seems fairly clear (a 16 byte length address is good for those things).
следует, что о 16 байтах уже договорились ранее и обсуждали нужно ли рассмотреть вопрос о переменной длине за пределы 16 байт.
И каждый день — без права на ошибку...
Re[14]: Разумность 16 байтных IP-адресов - ведь глупость сделали
Здравствуйте, Sinclair, Вы писали:
N>>Невозможно заставить людей не думать в терминах защищённого периметра и ослабленных мер контроля внутри него. 99% в ванную или в постель для секса не потащат заряженный и взведённый пистолет. А кто потащит — или уже Джеймс Бонд с готовой репутацией (и тогда можно быть уверенным, что он не выстрелит, когда не надо), или на него будут слишком активно коситься. N>>И к системам внутри это тоже относится. Передаваемое по PCI или USB обычно не шифруется и не подписывается, эти меры применяются уже снаружи от них. Точно так же поставить внутренние серверы с доступом только через VPN и расслабиться, допуская общие для всех ресурсы видимыми без паролей — нормальная идея. S>Но в USB и в PCI нет задачи "спроектировать сетевой протокол, одинаково пригодный и для подключения 10-сантиметровым шнурком и для связи через континент".
А кто говорил о такой задаче для провиженинга железяк?
Не было такого. Это кто-то потом применил средство не по адресу.
А в самом SIP меры для этого есть — SIPS был заложен изначально, SRTP — очень вскоре.
N>>Метод границ-периметров — работает, и достаточно хорошо работает. Проблемы возникают там, где этот периметр нарушается или незаметно для ответственных за его контроль, или они это игнорируют. S>В целом — да. На практике выясняется, что "решения", которые выглядят рабочими, работают только в каких-то узких тепличных условиях. И сэкономленные на спичках деньги с лихвой перекрываются зарплатами компетентных людей, которые строят и поддерживают эти защищённые периметры. А иногда — с ещё большей лихвой, когда происходит security breach.
И это проблема качества анализа при проектировании и при изменении требований, а не конкретных решений.
А то так можно договориться, что двигатель автомобиля должен быть готов постоянно работать без масла с открытой крышкой, а человек — с открытым мозгом.
N>>И расскажи, что ты видишь плохого в root access, если он достигается по явной заявке владельца (оформленной, например, в виде тычков в меню в особом режиме загрузки). S>Я вижу прекрасную возможность всадить трояна через социальную инженерию. S>Недавно вот был случай — в магазине лежало вполне себе легальное приложение, детская игрулина. Сколько-то месяцев развивало пользовательскую базу. Семилетки играли и фанатели. S>Потом в приложении появился магазин с инструкциями, как выпросить у родителей телефон, запустить на нём Сбербанк Онлайн, получить шестизначный код, и отправить его в аппликуху, "чтобы разблокировать новые скины". S>А завтра я выкачу приложение для взрослых, которое даст выиграть в казино 600к, но для их вывода нужно будет провести "набор тычков в особом режиме загрузки" и загрузить новую прошивку.
Ну то есть заведомо считаем всех пользователей слишком глупыми, а великий Apple их постоянно 24/7/365 защищает от самострела в ногу.
А как ты защитишь, если в магазине Apple будет такое же приложение? Только не надо говорить, что оно не пройдёт. Можно нагуглить сотни примеров, как их проверяльщики не видели диверсий.
А на самом деле решать надо не на этом уровне, а так, чтобы root access был в принципе не нужен. Сейчас-то он используется, в основном, для обхода бессмысленных вендорских ограничений (включая сам гугл).
S>Но это не тот сценарий, про который я рассказываю — я говорю о root access, который получил не пользователь, а злоумышленник. Потому что где-то один дегенерат решил, что "зачем секьюрить меню настроек гаражного замка — оно всё равно будет доступно только во внутренней сети", а другой дегенерат решил, что сервис "управление гаражными воротами через интернет" можно выгодно продать домашним пользователям. S>Сочетание этих двух дегенеративных решений приводит к тому, что вашими гаражными воротами начинает управлять совершенно посторонний вам человек, в противоправных целях.
И снова могу только заметить, что нормальной системе такой root access не нужен.
А как злоумышленник мог его получить? По принципу "я злой мексиканский вирус, сотрите сами всё важное на своём компе"?
N>>Да. А после этого принципиальная постановка вопроса в духе "мы можем заложиться на защиту сети?" в какой-то момент пропускается, скорее всего, на уровне интеграторов, которые просто не замечают проблемы (или игнорируют её). И снова, кто отвечает за то, что входная дверь в квартиру оказалась дизайна двери туалета? Почему (обычно) строители так не ляпают? S>В первую очередь — инженеры. Это наша работа — понимать, что с чем связано. А не полагаться на то, что каждый гражданин Земли — сам себе security инженер.
Но и не надо ставить искусственные барьеры.
N>>Считалось, что https — шибко дорого, как раз до letsencrypt. И вполне обоснованно считалось. А в 2000-х — так вообще. Мало того, ещё и сложно: пока докажешь какому-нибудь Verizon, что ты — это ты, семь потов сойдёт — и то если получится, потому что каждый второй человек на той стороне скажет "да я имел этих таёжных варваров, я нихрена не понимаю в душе что у них там происходит" и зарежектит. S>Подождите. Вы подменяете понятия. SSL != PKI. Мы же говорим об инженерной стоимости. А не о том, насколько велика была жадность Verizon.
А толку с той "инженерной" стоимости, если потом всё равно упираемся в сложность именно для людей и организаций получить нужное?
S>В 1997 году любой желающий мог сам себе сделать letsencrypt. И все так и делали — внутренние сетки отродясь пользовались local CA, и никто не жаловался на то, что эти ключи какие-то особенно дорогие.
Жаловался. Это было сложно и путано. Осиливали единицы из желающих.
Ну и, наконец, это было просто не нужно.
N>>Ну и про железячный их уровень я уже сказал. Они и тот H.323 или SIP еле-еле успевали провернуть. S>Ну, в 1997 году — может быть. Как такая бредятина смогла дожить до 2007 — вот вопрос. А сейчас 2024, и мы на полном серьёзе обсуждаем идею "давайте делать небезопасные протоколы и ендпоинты в надежде на то, что их защищщят при помощи периметра".
Да. Потому что с какого-то момента меры, требуемые для безопасности в варианте открытости всем ветрам, становятся бессмысленно дорогими.
N>>А теперь скажи мне, как сделать простой и удобный (и межвендорски универсальный) раздатчик https сертификатов для локалки, раз уж ты предлагаешь, чтобы даже поход на местный файловый сервер шифровать. И чтобы все браузеры автоматом подтягивали всё нужное. S>Во первых, какие ещё браузеры? Мы же вроде про IoT и технические протоколы взаимодействия.
OK, клиенты в виде железок. Им тоже влить нештатный сертификат не всегда просто.
Иногда — совсем непросто.
S>И даже если мы вернулись к разговору о браузерах, то я считаю идиотским решение S>1. Поставить локальную Jira без https, "потому что мы экономим на сертификатах и IP адресах" S>2. Вывести людей на удалёнку S>3. Тратить деньги и усилия на поддержание VPN, который отваливается раз в иногда, и без которого не получается зайти в локальную жиру снаружи
S>Как по мне, так деньги, потраченные на эти еженедельные "ой, у меня отпал и основной и резервный VPN сервер, что мне делать", было бы лучше один раз потратить на десяток публичных IP-адресов и сертификатов.
Есть большая разница. Ошибки администрирования на VPN сделать сложнее и ловить проще, чем ошибки администрирования на JIRA. Где-то на порядок, если не больше. Потому что JIRA.
Поэтому доступ только из-под VPN всё равно нужен.
А если так, то доп. защита на самой JIRA может быть и излишней.
The God is real, unless declared integer.
Re[7]: Разумность 16 байтных IP-адресов - ведь глупость сделали
Здравствуйте, B0FEE664, Вы писали:
BFE>То есть 8 байтов мало почему-то мало и были какие-то аргументы. При этом кто-то хотел больше 16-и
Я это писал рядом. Аргументы "8 мало, надо 16" были "нужны две части адреса, одна globally unique, вторая locally unique".
Но находить точный текст в архивах SIPP (который ещё есть) и IPng (которого уже, похоже, нет) мне уже облом.
BFE>А из этого BFE>
BFE>At this point the consensus among the IPng directorate and on several of the mailing lists seems fairly clear (a 16 byte length address is good for those things).
BFE>следует, что о 16 байтах уже договорились ранее и обсуждали нужно ли рассмотреть вопрос о переменной длине за пределы 16 байт.
Нет. Потому что письмо "а теперь оставляем пропозал на 16 байт" было позже.
И опять же тут надо смотреть полную переписку. Я привёл два самых главных.
The God is real, unless declared integer.
Re[17]: Разумность 16 байтных IP-адресов - ведь глупость сде
Здравствуйте, ·, Вы писали:
·>Здравствуйте, netch80, Вы писали:
N>>>>Ну тогда познакомься: вот аж целых трое из в общем-то уважаемой организации IETF и аналогично уважаемых домашних организаций. TLDR: для отдельных взаимодействий запрашивается временный IP в дополнение к основному, генерируется случайно так, чтобы не совпал с выдаваемыми автоматом (то есть не соответствовал EUI-64 из MAC адреса). Живёт этот IP до закрытия последнего использующего его сокета (или аналога). N>>·>Что-то не вижу в этом rfc твою интерпретацию. Читаем "Problem Statement": "Anytime a fixed identifier is used in multiple contexts, it becomes possible to correlate seemingly unrelated activity using this identifier". Т.е. это не для обеспечения секретной передачи, а для сокрытия корреляций в сетевой активности. N>>На каком потолке ты вынашел про "секретную передачу" и что это "моя интерпретация"? ·>Выделил болдом выше. нет, эти трое не предлагают, как ты заявляешь, обеспечивать некую безопасность в этом rfq.
Ещё раз задаю вопрос: где у меня про "секретную передачу" и что это "моя интерпретация"?
N>>·>Как я понял, по сути это как бы способ для замены NAT+DHCP, но только позволяет делать stateless реализацию на клиенте без какого участия роутера, делает ненужным и NAT, и DHCP. N>>Во-первых, NAT ни при чём. ·>Временная часть адреса — это эквивалент внутренним, невидимым ipv4 адресам за натом.
А апельсин — эквивалент паровоза.
·> В ipv6 адреса целиком выставляются наружу и видны целиком всему миру. Поэтому их и предгалают рандомизировать, обеспечивая ту же невидимость.
N>>Во-вторых, заменой DHCP здесь служит SLAAC в целом. Только первичный адрес конструируется из MAC на основании префикса из router advertisement, который явно запрошен (если тот не успел случайно себя анонсировать именно в этот момент), а такие вот вторичные захватываются на основании описанного рандома и уже известного префикса. ·>Ну да. А суть этого rfq — замена DHCP+NAT таким образом, чтобы сохранять непрозрачность сетевой активности.
Что такое rfq?
И снова, NAT у них не участвует вообще как концепция.
N>>·>Для секретности есть IPSec, который поддерживается в ipv6 нативно, а не как нашлёпка в ipv4. N>>1) Хватит ретранслировать бредовые сказочки образца 2000 года, это тогда почему-то некоторые утюги вещали то, что ты говоришь. IPSec в IPv4 и IPv6 отличается только деталями формата пакета, в остальном они идентичны. N>>2) IPSec требует настройки на уровне всего хоста (граничного раутера) и работает хост-хост или сеть-сеть. Догадываешься, почему это так мало используется сейчас? ·>Я не об этом. А о том как обеспечивать безопасность на уровне IP.
А я о том, используется ли вообще безопасность на уровне всего IP (всех его взаимодействий хотя бы с конкретным другим IP). И нет, обычно это не делается (VPN не считаем, хотя transport mode IPSec это тоже VPN — VPN не сводится к такому IPSec).
N>>>>При этом никакого scope для того, чтобы через этот временный IP нельзя было достичь тех ресурсов, которые сидят на основном IP и ожидают поступающих соединений (или аналогов), не предполагается. N>>·>Читаем вместе: "Temporary addresses are typically employed for initiating outgoing sessions". Причём тут "ожидают поступающих соединений"?? Читай 2й параграф секции 2.2 про incoming. N>>(mode=Snape) Обычно рекомендуется не просто прочитать буквы написанного, а ещё и подумать над ним: N>>1) Появление нового адреса на интерфейсе означает, что автоматически все слушающие сервисы, которые прибиндились на звезду, будут принимать и на этот адрес тоже. ·>Причём тут прибиндившееся сервисы??! Речь идёт о "initiating outgoing sessions"!
При том, что они с хорошей вероятностью присутствуют на таком хосте.
Я ж говорю, включайте думалку.
N>>И ни один существующий на сейчас стек не предполагает защиты от этого, и проблема в принципе не озвучена. ·>А она вообще есть? И причём тут этот rfq?
Да, проблема есть.
Повторяю вопрос, что такое rfq?
N>>2) Typically это не must и даже не should (согласно RFC2119). Это вообще, как они говорят, informational часть. А если посмотреть на практику, возьмём тот же SIP. Пусть мы создали такой IP и создаём звонок с него. В сигнализации будет участвовать этот IP? Если нет, то мы раскрыли основной. Если да, то мы уже должны принимать входящий поток на него. ·>Не понял. А на ipv4 за Натом кто куда будет соединяться?
IPv4 не влияет.
NAT — влияет, трансляцию во многих случаях надо открывать явно.
The God is real, unless declared integer.
Re[18]: Разумность 16 байтных IP-адресов - ведь глупость сде
Здравствуйте, Sinclair, Вы писали:
N>>Apple головного мозга (АГМ) в полный рост. При любой перепродаже устройства — ходи к производителю за ключами. S>Это всё ещё лучше, чем получить угон аккаунта. "Ходить к производителю" — ну, вот всякий раз, как я сдаю свой старый iPhone в трейд-ин, я "хожу к производителю за ключами". Неудобств, простите, на копейку. Безопасности — на $1200.
Потому что как одиночный конечный пользователь вы вписываетесь в созданную Apple структуру поддержки — и потому, что Apple жива как корпорация и не мутировала до неузнаваемости, вы живёте в мире, где можете сдать аппарат в trade-in (а не сидите в середине ничего возле Гиндукуша) и вы не попали под случайный серп запрета акаунта. Это называется "повезло". А теперь можете почитать истории, как кому-то отключили акаунт за ХЗ какие подозрения и все его аппараты превратились в тыквы.
А в мире толпы вендоров новой на тогда технологии VoIP надеяться на такое везение, что условный Grandstream продержится надцать лет и у него техподдержка будет исполнять такую поддержку хотя бы для стран 1-го мира... нет, нормальный (в смысле психики) бизнесмен на такое не рассчитывает.
Apple ведь раскрутилась вначале именно на фанатах и только набрав какой-никакой авторитет у них стала набирать бизнес-пользователей на бизнес-функции.
N>>Я ещё как-то понимаю, если серверную сторону будут проверять по умолчанию (и предоставлен какой-то стандартный лёгкий путь вшить сертификат локального сервера). Но клиента... ??? S>А в чём проблема? N>>А ещё, вот только что вспомнил, эти телефоны в массе умели получать начальный конфиг по TFTP. Это тоже ты предлагаешь сделать через SSL в облако? S>Именно. Потому что вот этот начальный конфиг собственно и содержит SIP креды, которые тривиально угоняются, если устройство торчит в публичный интернет, а не в локальную сетку, заботливо изолированную NAT-ом от внешнего мира.
Я не понял. Тут TFTP самим принципом не позволяет это сделать за пределами одного локального сегмента.
N>>Только изготовителю устройства, за то, что поддерживает своё хранилище ключей по каждому устройству. Этак баксов 20 в год, минимум (иначе не окупится) на каждое устройство. S>Нифига себе у вас запросы.
Это не у меня, это у них. И по состоянию на (условно) 2000-й год.
S> Двадцать баксов в год стоит хранение гигабайтных объёмов, с безлимитной отдачей их по запросу. Это, естественно, в розницу, то есть с большой прибылью. Если задача — не в том, чтобы содрать с клиента четыре шкуры, то безопасность стоит дешевле, чем её отсутствие.
N>>И расширенную проверку запросов, для чего держать детективное агентство. S>Какое агенство? Какую проверку? Ерунду пишете ведь.
С последним согласен, много видел таких.
Но я опять же думаю, что причины такого чисто рыночные. Устройство с жёсткой защитой "из коробки" просто не покупали бы столь охотно.
После ≈2010 уже появилась возможность более качественно управлять этим.
Я вижу такое, кстати, даже по WiFi раутерам. До какого-то момента нормой было что всем можно зайти на admin:admin или аналог (и только галочка доступа снаружи была снята). Сейчас норма — после ресета настроек чтобы был слабопредсказуемый пароль, записанный на бумажке на нижней стороне устройства (которая обычно на столе или стене). Сложно ли до такого додуматься было изначально? Я уверен, что нет, такие предложения поступали ещё при разработке первых устройств. Почему не делали? Это проблема именно административно-психологическая и UX, проявленная в потребностях рынка, а не техническая.
The God is real, unless declared integer.
Re[18]: Разумность 16 байтных IP-адресов - ведь глупость сде
Здравствуйте, netch80, Вы писали:
N>·>Выделил болдом выше. нет, эти трое не предлагают, как ты заявляешь, обеспечивать некую безопасность в этом rfq. N>Ещё раз задаю вопрос: где у меня про "секретную передачу" и что это "моя интерпретация"?
Цитирую ещё раз:
SK>Я не встречал человека, который бы думал что может скрыть публичный адрес в публичной сети и тем самым обеспечить некую безопасность.
Ну тогда познакомься: вот аж целых трое из в общем-то уважаемой организации IETF
Эти трое в этом RFC не предлагают "обеспечить некую безопасность". Предлагают они совсем другое. Безопасность обеспечивают другие RFC, относящиеся к IPSec, например.
N>>>Во-вторых, заменой DHCP здесь служит SLAAC в целом. Только первичный адрес конструируется из MAC на основании префикса из router advertisement, который явно запрошен (если тот не успел случайно себя анонсировать именно в этот момент), а такие вот вторичные захватываются на основании описанного рандома и уже известного префикса. N>·>Ну да. А суть этого rfq — замена DHCP+NAT таким образом, чтобы сохранять непрозрачность сетевой активности. N>Что такое rfq?
Опечатка, должно быть RFC.
N>И снова, NAT у них не участвует вообще как концепция.
Угу, потому что в ipv6 он не нужен.
N>·>Я не об этом. А о том как обеспечивать безопасность на уровне IP. N>А я о том, используется ли вообще безопасность на уровне всего IP (всех его взаимодействий хотя бы с конкретным другим IP). И нет, обычно это не делается (VPN не считаем, хотя transport mode IPSec это тоже VPN — VPN не сводится к такому IPSec).
И причём тут "эти трое"?
N>>>(mode=Snape) Обычно рекомендуется не просто прочитать буквы написанного, а ещё и подумать над ним: N>>>1) Появление нового адреса на интерфейсе означает, что автоматически все слушающие сервисы, которые прибиндились на звезду, будут принимать и на этот адрес тоже. N>·>Причём тут прибиндившееся сервисы??! Речь идёт о "initiating outgoing sessions"! N>При том, что они с хорошей вероятностью присутствуют на таком хосте.
С какого бодуна? Обычный клиентский комп или мобильник, например, с браузерами и сетевыми аппами — куда более лучшая вероятность. Входящие соединения обычно для серваков.
Ещё раз повторюсь и процитирую RFC: "Addresses generated using SLAAC contain an embedded interface identifier, which may remain stable over time. Anytime a fixed identifier is used in multiple contexts, it becomes possible to correlate seemingly unrelated activity using this identifier.". С какого хрена на таком хосте будут "слушающие сервисы", да ещё и с хорошей вероятностью?
N>>>И ни один существующий на сейчас стек не предполагает защиты от этого, и проблема в принципе не озвучена. N>·>А она вообще есть? И причём тут этот rfq? N>Да, проблема есть. N>Повторяю вопрос, что такое rfq?
Да это у меня на работе сплошные rfq, вот пальцы на автомате пишут. RFC, конечно же.
N>·>Не понял. А на ipv4 за Натом кто куда будет соединяться? N>IPv4 не влияет. N>NAT — влияет, трансляцию во многих случаях надо открывать явно.
В ipv6 — не надо. В этом и цимес.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re: Разумность 16 байтных IP-адресов - ведь глупость сделали
Здравствуйте, Shmj, Вы писали: S>И кажется что все это понимают, но как-то не охота сказать это слово — идиоты — по отношению к столько уважаемым людям.
может через 10 лет и ipv6 не хватит если каждый бот станет порождать тысячи и миллионы вирт. контейнеров,
и онлайн устройств будет явно больше триллиона, это не такая уж и большая цифра — столько рисинок в 40 кубах риса
-
Re[15]: Разумность 16 байтных IP-адресов - ведь глупость сделали
Здравствуйте, netch80, Вы писали:
N>Потому что как одиночный конечный пользователь вы вписываетесь в созданную Apple структуру поддержки
Всё наоборот. Это потому, что Apple создавала структуру для меня, а не для того, чтобы потешить инженерную лень.
N> — и потому, что Apple жива как корпорация и не мутировала до неузнаваемости, вы живёте в мире, где можете сдать аппарат в trade-in (а не сидите в середине ничего возле Гиндукуша)
Если вы сидите в середине ничего возле Гиндукуша, то возможность продать соседнему пользователю устройство, которое не живёт без подключения к интернету, вас скорее всего не очень интересует.
N>и вы не попали под случайный серп запрета акаунта. Это называется "повезло". А теперь можете почитать истории, как кому-то отключили акаунт за ХЗ какие подозрения и все его аппараты превратились в тыквы.
Я в такие истории даже верю, но чисто статистически их гораздо меньше, чем историй о людях, у которых "потерял телефон в торговом центре, а пока дозвонился в банк кто-то успел напокупать этим телефоном на полсотни тысяч".
N>А в мире толпы вендоров новой на тогда технологии VoIP надеяться на такое везение, что условный Grandstream продержится надцать лет и у него техподдержка будет исполнять такую поддержку хотя бы для стран 1-го мира... нет, нормальный (в смысле психики) бизнесмен на такое не рассчитывает.
У нормального бизнеса срок амортизации мелкой бытовой техники вроде телефонов — три года. Какой смысл рассуждать о многолетней устойчивости условного Grandstream, если мы планируем через три года устройство просто выкинуть? Какой смысл рассуждать о сложностях получения у вендора ключей для продажи устройства на сторону, если мы собираемся это устройство тупо списать? К моменту, когда мы решим его заменить, у него остаточная стоимость — $0.
N>Apple ведь раскрутилась вначале именно на фанатах и только набрав какой-никакой авторитет у них стала набирать бизнес-пользователей на бизнес-функции.
Apple раскрутилась на том, что Джобс бил инженеров палкой, не давая им выпустить посредственный продукт.
Это уже потом оказалось, что можно реализовать и бизнес-потребности — в частности, применять корпоративные политики безопасности и прочие ништяки.
N>Я не понял. Тут TFTP самим принципом не позволяет это сделать за пределами одного локального сегмента.
Это каким таким принципом? Он же поверх UDP — бери любой адрес и поехали. И брали и ехали.
N>Это не у меня, это у них. И по состоянию на (условно) 2000-й год.
Опять вы смешиваете маркетинг и инженерную себестоимость. Не стоил килобайт данных 20 долларов в год. Даже в 2000.
N>С последним согласен, много видел таких. N>Но я опять же думаю, что причины такого чисто рыночные. Устройство с жёсткой защитой "из коробки" просто не покупали бы столь охотно.
Неа. В первую очередь, причины — инженерные. Если бы инженеры (хорошо, продукт-менеджеры) задумывались о таких сценариях использования, то маркетинг бы сумел найти способ продавать такие устройства.
Но по факту о них стали задумываться только после того, как маркетинг пришёл обратно с жалобами пользователей. Я же все эти вещи не выдумываю — я в своё время (лет 10-15 тому) плотно работал с ребятками, которые продавали VoIP решения. И вот они-то мне и рассказывали все эти истории, а я им не верил — потому что это же бред с технической точки зрения! Ни один идиот не станет такого делать! Оказалось, что нет, всё — суровая правда. N>После ≈2010 уже появилась возможность более качественно управлять этим.
Ну вот видите. А сейчас — 2024, так что можно уже делать secure by default. А не наоборот.
N>Я вижу такое, кстати, даже по WiFi раутерам. До какого-то момента нормой было что всем можно зайти на admin:admin или аналог (и только галочка доступа снаружи была снята). Сейчас норма — после ресета настроек чтобы был слабопредсказуемый пароль, записанный на бумажке на нижней стороне устройства (которая обычно на столе или стене). Сложно ли до такого додуматься было изначально? Я уверен, что нет, такие предложения поступали ещё при разработке первых устройств. Почему не делали? Это проблема именно административно-психологическая и UX, проявленная в потребностях рынка, а не техническая.
Да нет же! Это решение было принято вовсе не после опроса участников рынка "как вы хотите настраивать устройство — чтобы у всех роутеров был одинаковый пароль, или чтобы у вашего был уникальный на бумажке".
Просто попросили инженеров спроектировать. Ну, а тем и в голову не приходит, что так нельзя. "Ну, у нас же одинаковая прошивка ставится во все устройства, значит и пароль будет у всех одинаковый". Всё, решение принято , поехали.
Кстати, у моего домашнего роутера всё именно так
То есть вот уникальный ключ доступа к WiFi они догадались сделать.
Вместе с инфраструктурой по заводской индивидуализации настройки, да ещё и приклеивания бумажки с этим ключом (вот это, кстати, и есть основной источник затрат — потому что технически прошивка заливается в устройство на одном заводе, коробка отливается на другом, бумажка печатается на третьем, а склеивается всё вместе — на четвёртом).
А вот то же самое для админского пароля — увы. В индустрии наблюдается острый дефицит Джобсов.
Кстати, Microsoft несколько лет тому таки продавила вендоров лаптопов печатать серийный номер устройства (который зашит в BIOS) на внешней стороне коробки.
Что позволяет сделать Over The Air Provisioning. Примерно таким способом, как я вам описал — железка при подключении к сети лезет за конфигурацией на предопределённый хост. А там уже владелец железяки, который заранее получил список серийников едущей к нему партии, заботливо приготовил нужный набор настроек — включая identity пользователя, который будет с этим лаптопом работать, и набор софта для предустановки.
Потому что у бизнеса ровно такие потребности — и, в первую очередь, у малого бизнеса, который не может себе позволить содержать выделенных админов для всех этих задач.
То есть 25 лет назад отсутствие таких практик понять можно — ну, не доросло человечество тогда до таких идей. Вон, и ремни-то в автомобилях не сразу появились. Но теперь мы всё это знаем, так что нет никакого смысла проектировать плохо сразу из коробки и ждать обратной связи от пользователей, "моей умной лампой кто-то мигает" или "мне одногруппники на спине умной джинсовки заменили фото группы TXT на член".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[22]: Разумность 16 байтных IP-адресов - ведь глупость сде
Здравствуйте, Sinclair, Вы писали:
SK>>а напомни, пожалуйста, что мы в этой ветке обсуждаем? S>Обсуждаем разумность применения несекьюрных протоколов администрирования и управления для железок, "потому что они и так стоят за NAT".
Не похоже от слова вообще, ну да ладно.
S>Точнее, цепочка рассуждений была следующая: железки нельзя втыкать в интернет без NAT -> поэтому NAT всегда есть -> поэтому можно не париться о размерности адресов, т.к. большинство адресов будут приватными. S>Я подвергаю сомнению первый шаг этой цепочки — собственно, нужда в NAT с т.з. безопасности продиктована исключительно дегенеративными инженерными решениями.
Собственно, NAT не является каким бы то ни было препятствием. Плохим мальчикам известно как минимум 3 техники проникновения за NAT. Его единственное оправдание существования — дефицит IPv4 адресов и административная сложность их получения (вся вот эта бумажная волокита с выделением, регистрацией, оплатой).
При этом на прикладном уровне NAT-костыль создает проблемы (с той-же телефонией видеосвязью и др) на преодоление которых приходится тратить огромные ресурсы.
S>Тому самому SMB, адвокатом которого вы выступаете, в тыщу раз удобнее просто воткнуть устройство "в интернет", отсканировать QR код на его коробке и настроить всё через панель управления на смартфоне. Чем городить NAT, настраивать порт форвардинг, VPN, и прочую неинтересную парикмахерской ерунду.
В целом итоговый вывод верный, (хотя в деталях всё и "наоборот").
Все проблемы от жадности и глупости
Re[2]: Разумность 16 байтных IP-адресов - ведь глупость сделали
Здравствуйте, trop, Вы писали:
T>может через 10 лет и ipv6 не хватит если каждый бот станет порождать тысячи и миллионы вирт. контейнеров, T>и онлайн устройств будет явно больше триллиона, это не такая уж и большая цифра — столько рисинок в 40 кубах риса
Даже если триллион человек будут иметь 16 млн. девайсов каждый — то IP-адресов публичных все-равно хватит. А внутренних адресов, которые не светятся, можно иметь еще больше.
Re[19]: Разумность 16 байтных IP-адресов - ведь глупость сде
Здравствуйте, ·, Вы писали:
·>Здравствуйте, netch80, Вы писали:
N>>·>Выделил болдом выше. нет, эти трое не предлагают, как ты заявляешь, обеспечивать некую безопасность в этом rfq. N>>Ещё раз задаю вопрос: где у меня про "секретную передачу" и что это "моя интерпретация"? ·>Цитирую ещё раз: ·>
SK>Я не встречал человека, который бы думал что может скрыть публичный адрес в публичной сети и тем самым обеспечить некую безопасность.
·>Ну тогда познакомься: вот аж целых трое из в общем-то уважаемой организации IETF
·>Эти трое в этом RFC не предлагают "обеспечить некую безопасность". Предлагают они совсем другое. Безопасность обеспечивают другие RFC, относящиеся к IPSec, например.
1. Отсутствие видимой со стороны корреляции нужно как раз для безопасности. Иначе оно вообще ни для чего не нужно.
2. Я так и не получил ответ на свой вопрос в его точных терминах. Что ж, тут кроме "слив засчитан" сказать нечего.
N>>И снова, NAT у них не участвует вообще как концепция. ·>Угу, потому что в ipv6 он не нужен.
Абсолютно необоснованное утверждение. Зачем нужен NAT при IPv6, я неоднократно тут упоминал.
N>>·>Я не об этом. А о том как обеспечивать безопасность на уровне IP. N>>А я о том, используется ли вообще безопасность на уровне всего IP (всех его взаимодействий хотя бы с конкретным другим IP). И нет, обычно это не делается (VPN не считаем, хотя transport mode IPSec это тоже VPN — VPN не сводится к такому IPSec). ·>И причём тут "эти трое"?
Я не знаю, это вы зачем-то начали вести в сторону IPSec (причём неверно по утверждениям).
N>>>>(mode=Snape) Обычно рекомендуется не просто прочитать буквы написанного, а ещё и подумать над ним: N>>>>1) Появление нового адреса на интерфейсе означает, что автоматически все слушающие сервисы, которые прибиндились на звезду, будут принимать и на этот адрес тоже. N>>·>Причём тут прибиндившееся сервисы??! Речь идёт о "initiating outgoing sessions"! N>>При том, что они с хорошей вероятностью присутствуют на таком хосте. ·>С какого бодуна? Обычный клиентский комп или мобильник, например, с браузерами и сетевыми аппами — куда более лучшая вероятность. Входящие соединения обычно для серваков. ·>Ещё раз повторюсь и процитирую RFC: "Addresses generated using SLAAC contain an embedded interface identifier, which may remain stable over time. Anytime a fixed identifier is used in multiple contexts, it becomes possible to correlate seemingly unrelated activity using this identifier.". С какого хрена на таком хосте будут "слушающие сервисы", да ещё и с хорошей вероятностью?
А вы не ограничивайтесь мобилками. Типовой виндовый десктоп-лаптоп, особенно в корпоративной локалке, имеет несколько таких сервисов. А дальше принтеры, файловые серверы и тому подобное.
И вот тут начинается то, что доказывает рядом Sinclair — что минимальные защиты во внутренней сети (а иначе неудобно) вместе с дырками в защите (а этот RFC фактически способствует таким дыркам) приводят к открытости всему миру.
N>>>>И ни один существующий на сейчас стек не предполагает защиты от этого, и проблема в принципе не озвучена. N>>·>А она вообще есть? И причём тут этот rfq? N>>Да, проблема есть. N>>Повторяю вопрос, что такое rfq? ·>Да это у меня на работе сплошные rfq, вот пальцы на автомате пишут. RFC, конечно же.
По сути: при том, что предположение о временности такого адреса способствует его использованию для более сложных по поведению сервисов (начиная с VoIP), а это приводит к меньшей защите файрволлом.
N>>·>Не понял. А на ipv4 за Натом кто куда будет соединяться? N>>IPv4 не влияет. N>>NAT — влияет, трансляцию во многих случаях надо открывать явно. ·>В ipv6 — не надо. В этом и цимес.
И снова откровенная ложь. Светить внутреннее устройство сети соглашается не каждый даже с IPv6, а все сказочки типа "вам не нужен NAT, потому что вам достаточно адресов" разбиваются о нормальный уровень паранойи.
The God is real, unless declared integer.
Re[16]: Разумность 16 байтных IP-адресов - ведь глупость сделали
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, netch80, Вы писали: N>>А кто говорил о такой задаче для провиженинга железяк? S>"Такой" — какой?
Делать его через публичный интернет.
У того поколения такая задача не ставилась.
Настройка типа логин/пароль передавалась отдельными путями, вплоть до стартовых пакетов в киосках. Это что было в реальной практике у наших клиентов.
N>>Не было такого. Это кто-то потом применил средство не по адресу. S>Это всё — последствия парадигмы "у нас есть внутренняя сеть, которую настраивают и эксплуатируют дорогостоящие админы". N>>А в самом SIP меры для этого есть — SIPS был заложен изначально, SRTP — очень вскоре. S>Это потому, что сам SIP проектировался для экстранета. SIP-устройству не нужен уютный NAT для того, чтобы работать.
N>>А то так можно договориться, что двигатель автомобиля должен быть готов постоянно работать без масла с открытой крышкой, а человек — с открытым мозгом. S>Если окажется, что это инженерно осуществимо — то да. Вон электромобили работают без коробки передач, и никто не жужжит.
Аналогия некорректна. Отсутствие узла как раз обеспечивает невозможность вмешательства в него
N>>Ну то есть заведомо считаем всех пользователей слишком глупыми, а великий Apple их постоянно 24/7/365 защищает от самострела в ногу. S>Совершенно верно. И делает это крайне успешно.
Ну вот такие подходы не были применимы в обсуждаемые времена.
N>>А как ты защитишь, если в магазине Apple будет такое же приложение? Только не надо говорить, что оно не пройдёт. Можно нагуглить сотни примеров, как их проверяльщики не видели диверсий. S>Странные вопросы вы задаёте. В магазине Apple приложение не сможет попросить человека дать ему root access, потому что пользователь не сможет дать ему root access. S>Не получится сформировать левую прошивку, которая будет тырить данные из банковских приложений. Не получится уговорить пользователя сделать даунгрейд на старую версию прошивки, где была уязвимость.
Зато запросто получится поставить то, в чём все уровни контроля пропустили воровскую активность. А вы куда-то в сторону уводите разговор.
N>>А на самом деле решать надо не на этом уровне, а так, чтобы root access был в принципе не нужен. Сейчас-то он используется, в основном, для обхода бессмысленных вендорских ограничений (включая сам гугл). S>Ну вот у Apple root access не нужен. Я его больше 10 лет эксплуатирую, а root access мне был нужен только тогда, когда устройства продавались заблокированными на оператора.
Anecdotal evidence.
N>>И снова могу только заметить, что нормальной системе такой root access не нужен. N>>А как злоумышленник мог его получить? По принципу "я злой мексиканский вирус, сотрите сами всё важное на своём компе"? S>Нет, очень просто он мог получить — зайдя на публичный адрес железки с кредами admin/password. Ведь её проектировал дегенерат, который думал, что железка торчит в интранет, "а в интранете случайных людей нет".
Это уже обсуждали. Вопрос не в проектировщиках — по крайней мере не на тот момент.
N>>Но и не надо ставить искусственные барьеры. S>Что такое "искусственные барьеры"? Запрет работы без SSL?
Это, например, когда пароль должен включать в себя большие буквы, маленькие буквы, цифры, знаки препинания, семя папоротника, кровь девственницы, завязку, кульминацию и неожиданный финал.
N>>А толку с той "инженерной" стоимости, если потом всё равно упираемся в сложность именно для людей и организаций получить нужное? S>Нет никакой сложности.
См. ниже.
N>>Жаловался. Это было сложно и путано. Осиливали единицы из желающих. S>Ну, в 1997 — да. А в 2000 уже была Active Directory, и контроллеры доменов прекрасно раздавали сертификаты.
Ага. Мы в 2014 как-то угорали с письма юзера "я тут перешёл с Windows 2000 на XP, и у меня проблема с вашей вебмордой".
А рядом ещё один сидел на системе образца ≈2001 года где-то до 2016. На обновиться у него не хватало... не денег — это как раз не было настолько большой проблемой — а людей поддержать процесс перехода, потому что как минимум в биллинге изменилось чуть более, чем всё. (Его перевели, но, кажется, в 4 прыжка через набор ключевых версий.)
Думать, что все хотя бы слышали в 2000 про AD, уже смешно. Что могли на неё перейти — тем более.
N>>Да. Потому что с какого-то момента меры, требуемые для безопасности в варианте открытости всем ветрам, становятся бессмысленно дорогими. S>С какого-то момента при движении в прошлое?
Прошлое ни при чём. При усложнении самих мер.
N>>OK, клиенты в виде железок. Им тоже влить нештатный сертификат не всегда просто. N>>Иногда — совсем непросто. S>А зачем ответ вырезали?
О чём речь?
Если про AD и прочее, то на те времена это было нереальным.
N>>Есть большая разница. Ошибки администрирования на VPN сделать сложнее и ловить проще, чем ошибки администрирования на JIRA. Где-то на порядок, если не больше. Потому что JIRA. S>JIRA администрировать всё равно надо. Наличие VPN увеличивает стоимость эксплуатации, а не уменьшает.
Уменьшает. Потому что есть одна достаточно простая и понятная составляющая, на поддержку/сопровождение/защиту которой и тратятся людские и материальные ресурсы.
А если все админы начнут ещё и тратить время на разборки, что JIRA защищается одним образом, Gitlab вторым, AD третьим (и не надо сказок, что его можно открывать всем ветрам), файловый сервер четвёртым, и так далее — то их работа увеличится в разы.
А VPN, кроме прочего, помогает и против DoS всех видов, а не только взломов и неавторизованных чтений — тем, что у тебя просто нет доступа к ресурсу.
Именно поэтому даже при защите внутренних ресурсов (которая неизбежна, если есть разделение доступа между группами пользователей, типа, программистам нельзя читать sales) всё равно добавляется VPN для доступа в принципе. Иногда — несколько VPN, но однотипных.
N>>Поэтому доступ только из-под VPN всё равно нужен. N>>А если так, то доп. защита на самой JIRA может быть и излишней. S>
Никаких смайлов. Чистые реалии даже у достаточно крупных контор. Одна из последних, на которые работали, имела десятки миллионов пользователей.
Они при этом могут использовать универсальную авторизацию для всего (JIRA, файловые свалки, Jenkins/etc., и прочие) через Azure или Okta (или ещё десяток аналогов), но всё равно масса ресурсов доступна только через VPN.
И это правильно.
The God is real, unless declared integer.
Re[20]: Разумность 16 байтных IP-адресов - ведь глупость сде
Здравствуйте, Sinclair, Вы писали:
N>>Потому что как одиночный конечный пользователь вы вписываетесь в созданную Apple структуру поддержки S>Всё наоборот. Это потому, что Apple создавала структуру для меня, а не для того, чтобы потешить инженерную лень.
Apple создала структуру ради своей прибыли. А её решила обеспечить ориентацией на выравнивание требований пользователей по линейке имени Джобса.
Если ты согласился подровняться под неё — это говорит о тебе.
N>> — и потому, что Apple жива как корпорация и не мутировала до неузнаваемости, вы живёте в мире, где можете сдать аппарат в trade-in (а не сидите в середине ничего возле Гиндукуша) S>Если вы сидите в середине ничего возле Гиндукуша, то возможность продать соседнему пользователю устройство, которое не живёт без подключения к интернету, вас скорее всего не очень интересует.
Интернет через спутник есть везде. А вот ближайший СЦ Apple может быть и в другой стране.
N>>и вы не попали под случайный серп запрета акаунта. Это называется "повезло". А теперь можете почитать истории, как кому-то отключили акаунт за ХЗ какие подозрения и все его аппараты превратились в тыквы. S>Я в такие истории даже верю, но чисто статистически их гораздо меньше, чем историй о людях, у которых "потерял телефон в торговом центре, а пока дозвонился в банк кто-то успел напокупать этим телефоном на полсотни тысяч".
А пока добежал до СЦ — напокупали на миллион. При чём тут вообще тогда защита уровня root или не root?
N>>А в мире толпы вендоров новой на тогда технологии VoIP надеяться на такое везение, что условный Grandstream продержится надцать лет и у него техподдержка будет исполнять такую поддержку хотя бы для стран 1-го мира... нет, нормальный (в смысле психики) бизнесмен на такое не рассчитывает. S>У нормального бизнеса срок амортизации мелкой бытовой техники вроде телефонов — три года. Какой смысл рассуждать о многолетней устойчивости условного Grandstream, если мы планируем через три года устройство просто выкинуть? S> Какой смысл рассуждать о сложностях получения у вендора ключей для продажи устройства на сторону, если мы собираемся это устройство тупо списать? К моменту, когда мы решим его заменить, у него остаточная стоимость — $0.
Три года — это вы по какой стране судите?
IP телефоны даже в условиях США спокойно жили и по 10 лет. А у индийских клиентов жило и по 15, если повезёт (плесенью изнутри не покроется). Могло быть при этом 20 раз перепродано — всё равно в статистике маячили древние модели.
Да, увы, это значит, что юзеры будут требовать поддержки давно устаревшего. Факт, с этим и жили. Отменять нельзя, клиенты слишком обидятся.
Есть фичи, которым с 2001-го года не убираем поддержку (хотя половина из них проявляется в новых изделиях — потому что код переносится). Вот простой пример. Синтаксис SIP допускает знак '*' в userpart в URL, но не '#' (должно быть "%23" взамен). Несимметрично, да. При этом даже Cisco до ~2015 регулярно выпускала софт, который не просто генерировал это '#', а странно работал если передавать "%23". Так и держим опцию "для этих получателей генерировать '#' в открытом виде".
А проблема вроде непонимания правильного CI для тегов (ещё одна диверсия стандарта SIP) вылазила последние лет 10 и на совсем вроде бы новых железяках. Может, они купили древний код, не знаю. Этот пример чуть вбок, но показывает, что "выкинуть через три года" не работает ни к какой части.
N>>Apple ведь раскрутилась вначале именно на фанатах и только набрав какой-никакой авторитет у них стала набирать бизнес-пользователей на бизнес-функции. S>Apple раскрутилась на том, что Джобс бил инженеров палкой, не давая им выпустить посредственный продукт.
Нет.
N>>Я не понял. Тут TFTP самим принципом не позволяет это сделать за пределами одного локального сегмента. S>Это каким таким принципом? Он же поверх UDP — бери любой адрес и поехали. И брали и ехали.
Его не используют без DHCP. Используют тогда уже полноценный FTP, или HTTP.
OK, недостаточно уточнил — не "буквой закона", а типовым принципом использования.
Реально эти железяки именно что получали по DHCP опции "конфигуриться отсюда" и только тогда ходили по TFTP за конфигом (или аналогично если прошивку обновлять).
N>>Это не у меня, это у них. И по состоянию на (условно) 2000-й год. S>Опять вы смешиваете маркетинг и инженерную себестоимость. Не стоил килобайт данных 20 долларов в год. Даже в 2000.
Не я смешиваю, а они. Я констатирую факт.
N>>С последним согласен, много видел таких. N>>Но я опять же думаю, что причины такого чисто рыночные. Устройство с жёсткой защитой "из коробки" просто не покупали бы столь охотно. S>Неа. В первую очередь, причины — инженерные. Если бы инженеры (хорошо, продукт-менеджеры) задумывались о таких сценариях использования, то маркетинг бы сумел найти способ продавать такие устройства.
Тут согласен. Но история IT показывает, что продукт-менеджеры, или бизнес-аналитики, или кто там вместо них будет — промахиваются всегда. Реальную информацию они могут получить только от фидбэка. А фидбэк в плане секьюрити им получить и осознать ещё сложнее.
Тех, кто параноик в душе, слишком мало.
Но всё ещё хуже. Инженеры тоже... мнэээ... лажают. За то, как спроектирован SIP, я регулярно хотел взять автомат и перестрелять всех. Сделать разумно было тривиально, только чуть-чуть подумать. Часть я описал тут, за вторую (где сессия) и дальше пока не брался, там не меньше кошмаров.
S>Но по факту о них стали задумываться только после того, как маркетинг пришёл обратно с жалобами пользователей.
Именно!
S> Я же все эти вещи не выдумываю — я в своё время (лет 10-15 тому) плотно работал с ребятками, которые продавали VoIP решения. И вот они-то мне и рассказывали все эти истории, а я им не верил — потому что это же бред с технической точки зрения! Ни один идиот не станет такого делать! Оказалось, что нет, всё — суровая правда. N>>После ≈2010 уже появилась возможность более качественно управлять этим. S>Ну вот видите. А сейчас — 2024, так что можно уже делать secure by default. А не наоборот.
В 2024 я таки да жду от всех секьюрных решений.
Что, возвращаясь к предыдущей теме, не означает необходимость открытия внутренних сетей всем ветрам. Потому что даже если будут верно проектировать в принципе, CVE никто не отменял.
N>>Я вижу такое, кстати, даже по WiFi раутерам. До какого-то момента нормой было что всем можно зайти на admin:admin или аналог (и только галочка доступа снаружи была снята). Сейчас норма — после ресета настроек чтобы был слабопредсказуемый пароль, записанный на бумажке на нижней стороне устройства (которая обычно на столе или стене). Сложно ли до такого додуматься было изначально? Я уверен, что нет, такие предложения поступали ещё при разработке первых устройств. Почему не делали? Это проблема именно административно-психологическая и UX, проявленная в потребностях рынка, а не техническая. S>Да нет же! Это решение было принято вовсе не после опроса участников рынка "как вы хотите настраивать устройство — чтобы у всех роутеров был одинаковый пароль, или чтобы у вашего был уникальный на бумажке".
Почему вы думаете, что не по опросам участников рынка?
S>Просто попросили инженеров спроектировать. Ну, а тем и в голову не приходит, что так нельзя. "Ну, у нас же одинаковая прошивка ставится во все устройства, значит и пароль будет у всех одинаковый". Всё, решение принято , поехали.
Или у вас какие-то особо дуболомные инженеры-проектировщики, или одно из двух. Потому что сколь-нибудь нормальные знают, что пароли это как раз то, что у всех должно различаться.
А вот на уровне отдела эксплуатации сети на 100500 устройств — таки один на всех.
И это не голые слова. В одном из недавних проектов я как раз с таким имел дело. Там не SIP, другое, но тоже есть M центральных железяк и N (N≫M) юзерских, но жёстко руководимых из центра (клиент имеет право только втыкать-вытыкать шнурки). С завода приходят железяки с заводским паролем. Отдел эксплуатации ставит в сеть и меняет на один пароль и один SSH ключ на всех. Вариант персонального пароля на каждый не рассматривается.
При этом управление идёт через физически отдельный интерфейс, сидящий, разумеется, в своей IP сети. Ибо нефиг.
S>То есть 25 лет назад отсутствие таких практик понять можно — ну, не доросло человечество тогда до таких идей. Вон, и ремни-то в автомобилях не сразу появились. Но теперь мы всё это знаем, так что нет никакого смысла проектировать плохо сразу из коробки и ждать обратной связи от пользователей, "моей умной лампой кто-то мигает" или "мне одногруппники на спине умной джинсовки заменили фото группы TXT на член".
С принципом согласен. И всё равно, повторюсь, это не причина после того выставлять все устройста голым задом в интернет, сколь бы этот зад ни казался бронированным.
The God is real, unless declared integer.
Re[23]: Разумность 16 байтных IP-адресов - ведь глупость сде
Здравствуйте, Stanislaw K, Вы писали:
SK>Собственно, NAT не является каким бы то ни было препятствием. Плохим мальчикам известно как минимум 3 техники проникновения за NAT.
При отсутствии доступа сквозь раутер этих техник нет. Не считаем случай всяких встречных трансляций, при правильной организации это не проникновение.
А отсутствие NAT при отсутствии качественного файрволла превращает сеть в полностью открытую.
SK> Его единственное оправдание существования — дефицит IPv4 адресов и административная сложность их получения (вся вот эта бумажная волокита с выделением, регистрацией, оплатой).
Его главное оправдание на сейчас это сокрытие данных о внутренней сети.
SK>При этом на прикладном уровне NAT-костыль создает проблемы (с той-же телефонией видеосвязью и др) на преодоление которых приходится тратить огромные ресурсы.
Протоколы, с которыми тут проблема, постепенно уходят — не в последнюю очередь из-за этих проблем. Какая доля видеосвязи в последнее время приходится на SIP, а какая — на Zoom, Google Meet, Microsoft Teams, и ещё 100500 аналогов, которых не назвал?
S>>Тому самому SMB, адвокатом которого вы выступаете, в тыщу раз удобнее просто воткнуть устройство "в интернет", отсканировать QR код на его коробке и настроить всё через панель управления на смартфоне. Чем городить NAT, настраивать порт форвардинг, VPN, и прочую неинтересную парикмахерской ерунду.
Такому SMB вообще незачем что-то строить, у него нет причин пропускать что-то внутрь сети не в пределах исходящего соединения.
The God is real, unless declared integer.
Re[20]: Разумность 16 байтных IP-адресов - ведь глупость сде
Здравствуйте, netch80, Вы писали:
N>·>Цитирую ещё раз: N>·>
SK>Я не встречал человека, который бы думал что может скрыть публичный адрес в публичной сети и тем самым обеспечить некую безопасность.
N>·>Ну тогда познакомься: вот аж целых трое из в общем-то уважаемой организации IETF
N>·>
N>·>Эти трое в этом RFC не предлагают "обеспечить некую безопасность". Предлагают они совсем другое. Безопасность обеспечивают другие RFC, относящиеся к IPSec, например. N>1. Отсутствие видимой со стороны корреляции нужно как раз для безопасности. Иначе оно вообще ни для чего не нужно.
Нет, это для приватности. Закрыться полотенцем на пляже когда передеваешься — это приватность. Но полотенце никакую безопасность не обеспечивает.
N>2. Я так и не получил ответ на свой вопрос в его точных терминах. Что ж, тут кроме "слив засчитан" сказать нечего.
Ты просто в терминах путаешься.
N>>>И снова, NAT у них не участвует вообще как концепция. N>·>Угу, потому что в ipv6 он не нужен. N>Абсолютно необоснованное утверждение. Зачем нужен NAT при IPv6, я неоднократно тут упоминал.
NAT64 в смысле? Ну да, нужен, конечно. Но есть нюанс.
N>>>А я о том, используется ли вообще безопасность на уровне всего IP (всех его взаимодействий хотя бы с конкретным другим IP). И нет, обычно это не делается (VPN не считаем, хотя transport mode IPSec это тоже VPN — VPN не сводится к такому IPSec). N>·>И причём тут "эти трое"? N>Я не знаю, это вы зачем-то начали вести в сторону IPSec (причём неверно по утверждениям).
Об этих троих ты заговорил первым, меня ещё в дискуссии не было. Так в чём смысл твоего "тогда познакомься: вот аж целых трое из в общем-то уважаемой организации IETF"?
N>·>С какого бодуна? Обычный клиентский комп или мобильник, например, с браузерами и сетевыми аппами — куда более лучшая вероятность. Входящие соединения обычно для серваков. N>·>Ещё раз повторюсь и процитирую RFC: "Addresses generated using SLAAC contain an embedded interface identifier, which may remain stable over time. Anytime a fixed identifier is used in multiple contexts, it becomes possible to correlate seemingly unrelated activity using this identifier.". С какого хрена на таком хосте будут "слушающие сервисы", да ещё и с хорошей вероятностью? N>А вы не ограничивайтесь мобилками. Типовой виндовый десктоп-лаптоп, особенно в корпоративной локалке, имеет несколько таких сервисов. А дальше принтеры, файловые серверы и тому подобное.
И? Чем поможет NAT?
N>И вот тут начинается то, что доказывает рядом Sinclair — что минимальные защиты во внутренней сети (а иначе неудобно) вместе с дырками в защите (а этот RFC фактически способствует таким дыркам) приводят к открытости всему миру.
Нет, не приводят.
N>По сути: при том, что предположение о временности такого адреса способствует его использованию для более сложных по поведению сервисов (начиная с VoIP), а это приводит к меньшей защите файрволлом.
Не понял. Т.е. ты хочешь сказать, что если кто-то по не знанию и не пониманию сделает какие-то глупые предположения, то они могут получить плохую защиту? Эээ.. ну очевидно, ясен пень. И? Причём тут ipv6?
N>·>В ipv6 — не надо. В этом и цимес. N>И снова откровенная ложь. Светить внутреннее устройство сети соглашается не каждый даже с IPv6, а все сказочки типа "вам не нужен NAT, потому что вам достаточно адресов" разбиваются о нормальный уровень паранойи.
Так вот RFC как раз про то, как не светить внутреннее устройство сети, реализуя ту же хрень, что делает NAT+DHCP, но технически проще. Прочитай и разберись, в конце концов.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[3]: Разумность 16 байтных IP-адресов - ведь глупость сделали
Здравствуйте, m2l, Вы писали:
m2l>Вообще случайная генерация 64 бит — это уже доработки и костыли, когда выяснили насколько же кривое поделие вышло. m2l>Ты просто обоснуй необходимость в каждом пакете через всё сеть слать 64 + 64 бита случайных данных. Условно говоря 1-2% всего трафика — никому не нужный мусор, просто из-за изумительно квалификации авторов IPv6.
Сразу видно что ты не занимался распределёнными сетевыми решениями. Случайные данные нужны для возможности реализации stateless протоколов, что даёт бОльшую масштабируемость, надёжность и производительность. Вот тут, например rfc8981 упомянут был.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[24]: Разумность 16 байтных IP-адресов - ведь глупость сде
Здравствуйте, netch80, Вы писали:
SK>>Собственно, NAT не является каким бы то ни было препятствием. Плохим мальчикам известно как минимум 3 техники проникновения за NAT.
N>При отсутствии доступа сквозь раутер этих техник нет.
В том-то и дело что есть.
N>А отсутствие NAT при отсутствии качественного файрволла превращает сеть в полностью открытую.
Его присутствие ни на что не влияет.
SK>> Его единственное оправдание существования — дефицит IPv4 адресов и административная сложность их получения (вся вот эта бумажная волокита с выделением, регистрацией, оплатой).
N>Его главное оправдание на сейчас это сокрытие данных о внутренней сети.
Не имеет значения. Единственное условие — плохим мальчикам нужно знать что за этим IP расположено нечто (интересное или за что платят интересные деньги), что эта внутренняя сеть существует.
Какие либо дополнительные сведения просто немного сократят вторую фазу "рукопожатия".
SK>>При этом на прикладном уровне NAT-костыль создает проблемы (с той-же телефонией видеосвязью и др) на преодоление которых приходится тратить огромные ресурсы.
N>Протоколы, с которыми тут проблема, постепенно уходят — не в последнюю очередь из-за этих проблем.
Как только NAT сократится, они быстро вернутся.
N>Какая доля видеосвязи в последнее время приходится на SIP, а какая — на Zoom, Google Meet, Microsoft Teams, и ещё 100500 аналогов, которых не назвал?
Последние и живы только благодаря тому что с NAT не работает P2P, приходится гонять весь трафик через сервера. При этом у них собственные фундаментальные проблемы с интерконнектом.
Все проблемы от жадности и глупости
Re[21]: Разумность 16 байтных IP-адресов - ведь глупость сде
можно вопрос?
что важнее, защита трафика или защита от подмены айпи? например объект а общается с б, а пакеты у а подменяются на ип адрес какого нибудь левого с
.
