А я разве где-то утверждал, что нужно всё принимать на веру? Мой оппонент занимается безосновательным переходом на личности, вы это поддерживаете или что-то другое?
Ну относительно такой вещи как здоровье недоверие должно быть «из общих соображений» ко всем
Сколько угодно, но в какой-то момент всё равно придется остановиться. К сожалению, подавляющее число людей не смогут проверить корректность медицинского исследования, даже если найдут его полный текст. Поэтому они вынуждены доверять тем, кто может это сделать — ВОЗ, FDA, CDC и т.д. Авторитеты всегда будут, просто у разных людей разные.
Кроме того, все комментаторы прицепились только к личности Малышевой почему-то, а не к конкретному утверждению, хотя автор исходного комментария привёл и другой источник. И поэтому я совершенно не понимаю, откуда столько минусов.
Малышева это же вообще диагноз
Давайте не будем опускаться до такого уровня дискуссии. Приведите, пожалуйста, конкретные примеры, где Малышева давала бы заведомо неверную или некорректную информацию?
Меня в первую очередь интересуют конкретные претензии, а не «переобувается в полёте». К тому же не всегда переобувание — это плохо. Медицина не стоит на месте, иногда появляются новые данные. Поэтому можно всё же пример переобувания? Я Малышеву не смотрю, но из того что видел, иногда были вопросы по форме, но не по содержанию.
Иначе в интерфейсе для рекламодателей должно было бы присутствовать поле для указания соли. А его там нет!
А для чего нужно было бы знать Яндексу соль, с которой телефоны хэшируются на другой стороне? Как раз если бы там было поле для ввода соли, это было бы подозрительно.
Очевидно, что самый быстрый и простой вариант — использование радужных таблиц
Неправда. Если телефоны несолёные (хотя как мы выяснили выше, это совершенно необязательно так), то самый быстрый вариант — предпосчитать и хранить несколько миллиардов и даже триллионов хэшей md5 от всех потенциально возможных номеров телефонов. А если используется соль (неизвестного формата и длины), то и радужные таблицы не сильно помогут.
А вообще, в статье домыслы на домыслах и домыслами погоняют: «разумно предположить», «веры нет никакой», «скажем прямо» и остальное, ну куда это годится. Хотел почитать про «слежку от яндекса», а оказалось, там всего лишь выкатили недотестированный релиз. Ну это что получается, шпион все собираемые данные ещё и на устройстве жертвы сохраняет? Для бэкапа что ли, чтоб не потерять, или чтобы его обнаружили побыстрее?
Не факты, а одни лишь предположения, местами ещё и необоснованные выводы, ну на троечку с минусом, я бы сказал.
Так смысл ограничения срока действия сертификатов ведь именно в том, чтобы ключ сменить. Для защиты от подбора ключа всякими спецслужбами вероятного противника. Если ключ оставить тем же самым, можно сразу сертификаты с бесконечным сроком действия выпускать.
вводить пароль от диска при каждом зауске сервера — не самое интересное занятие
Если задача именно в этом — автоматическая разблокировка зашифрованного диска при запуске системы — то ещё проще использовать TPM2. В ubuntu 20.04 это делается примерно так (только надо ещё соответствующие пакеты поставить, минимально необходимый список не подскажу, но достаточный примерно такой: clevis clevis-luks clevis-tpm2 clevis-initramfs clevis-systemd):
+secure boot, +автоподписывание собираемых DKMS модулей, и вот уже более-менее защищенная система получилась (если её не включать, конечно). Отчуждаемый носитель по определению надежнее, но тут уже вопрос рисков, от которых защищаемся.
Суть-то в чем: маскарадинг становится не нужен. Тот NAT, который порты пробрасывает, никуда не девается, он по-прежнему работает точно так же как и раньше, это ж тупо замена одних байтиков в пакете на другие.
если внешние адреса появляются на устройствах и виртуальных машинах, то они попадают в zeroconf/avahi и SMB, скажем, тот же `ssh -6 user@host.local' может случайно использовать внешний адрес
Честно скажу, тут я не особо в курсе, как эти штуки работают под капотом, но сначала попробовал бы решить именно эту проблему — попадание «белых» адресов в zeroconf/avahi. По моей идее, в локалке они должны ходить друг к другу только по ULA адресам. Если всё внутри работает по ULA, остальных проблем с доступом между хостами и тормозами не должно быть.
Почему «либо», всё равно ж нужен какой ни какой межсетевой экран, а проброс с помощью NAT/прокси/МЭ это надёжно.
Имелось в виду, что для доступа к fileserver.local:443 снаружи можно пойти двумя путями: поднять на нём отдельный DynDNS клиент с отдельной записью fileserver.blablabla, либо пробрасывать в него порт с router.local. FW при этом никуда не девается, просто разные правила при этом нужно добавлять.
DHCPv6-PD это ж для конфигурации внутренних сетей
Ну да, но всегда найдется кто-то, кто захочет сделать всё по-своему.
Я честно попытался понять, что вы хотите до меня донести, и не смог.
>Вы очевидно не в курсе работы NAT
Допустим, просвещайте
>Те из них, что «симметричные», откликаются на входящие на конкретный внешний адрес только для установленного для него ремотного
И много вы знаете квартир, в которых работает симметричный NAT?
>даже если NAT конусовый, кто будет _с_ внутренних критичных портов стуаться наружу
Эту часть я вообще не понял, кто, зачем, куда стучится, какую проблему мы решаем — ничего непонятно.
>Это всё ручные действия.
Ну и что? Чем это плохо, если речь о домашних пользоателях и одном-двух сервисах, которые хочется открыть наружу?
>STUN, TURN.
Круто: сделаем себе NAT, огребём проблем и будем их героически решать
>PCP
Требуется поддержка со стороны софта, насколько я понимаю.
Предлагаю сделать проще: опишите ещё раз, пожалуйста, сценарий, в котором возникает проблема, саму эту проблему, как именно её решает маскарадинг (или какой там вид NAT считается «полноценным») и почему её нельзя решить без него в IPv6. Наверняка такие сценарии действительно существуют, только вот сомневаюсь, что они относятся к домашним сетям.
Тут есть некая путаница. Тот NAT, о котором вы говорите, это DNAT — destination NAT, и он работает очень просто: сравниваются IP и порт в пакете с указанными в правилах, если есть совпадение — DST IP в пакете меняется на нужный, и он отправляется получателю, плюс в обратную сторону то же самое.
Тот NAT, который в IPv6 становится не нужен — это маскарадинг, когда все хосты во внутренней сети использут ТОЛЬКО приватные адреса, и выходят в интернет через единый шлюз, используя единственный выданный провайдером внешний адрес на всех. Маскарадинг — это достаточно хитрый костыль, и у него есть свои ограничения и недостатки, при этом он на самом деле решает лишь одну-единственную насущную проблему, остро выраженную именно в IPv4: нехватку публично доступных адресов.
>Я ответил: тем, что скрывает внутреннюю структуру всей сети
Ну, допустим
>и тем самым значительно усложняет атаки извне
Это каким же образом? Теперь у атакующего есть один IP адрес, на котором висят несколько открытых портов. Перебор портов на одном адресе — гораздо более простая задача, чем поиск откликающихся на SYN адресов в /64 подсети.
>То есть вы выступаете за вариант 3, но при этом говорите про «никакой»
Окей, пусть будет вариант 3, видимо я не смог его распарсить. На самом деле тут во многих случаях никакого анализа пакетов не требуется, если правильно настроить сервер (например, у FTP и торрентов можно ограничить диапазон используемых портов и в FW открыть их все сразу), но допустим. Так всё же, чем тут NAT-то вам может помочь? Наоборот, он как раз всё усложняет, как вы собираетесь NAT-ить тот же FTP? С NAT-ом вам нужно помимо FW ещё правильно форвардинг порта настроить.
Никакое. FW может фильтровать все прилетающие из интернета пакеты, кроме «DST IP такой-то, порт такой-то» и established,related. Такой вариант почему-то не рассмотрен.
В той ветке, кстати, так и не был получен ответ на вопрос, чем тут может помочь NAT.
>если Интернет именно в этот момент не доступен, то дачная/домашняя сеть будет тормозить
Почему? Как от этого поможет «полноценный NAT»?
>выдают новый префикс — тормоза
Опять же, почему?
Для внутренней сети можно использовать адреса ULA, они будут более-менее статические и работать будут всегда, тормозить ничего не будет. Для выхода в интернет каждое устройство будет использовать tempaddr, а в качестве постоянного глобального адреса (на случай необходимости организации доступа извне без форвардинга) — адрес из выданной провайдером через DHCPv6-PD подсети. Этот адрес будет изменяться только при смене провайдера, так что для устройств, недоступных извне, смена провайдера будет прозрачна, а для остальных хватит того же DynDNS либо проброса портов.
Но что мешает «скрыть структуру сети» без использования маскарадинга? Опять же, скрыть от кого/чего? MITM на стороне провайдера что ли, который следит за всем проходящим трафиком? И почему защитные меры «не работают»? Предлагаю для начала определиться, от какого сценария вы пытаетесь защищаться.
Эти проблемы ведь никак не решаются NAT-ом? Я не говорю, что файрволл — панацея, но NAT не поможет всё равно — значит, NAT не нужен. Сам по себе NAT, который широко используется в домашних v4 сетях на сегодня, накладывает дополнительные ограничения, от которых с переходом на v6 можно отказаться, не вижу причин этого не делать.
Ну, или я что-то не так понял.
Кроме случая когда корень зашифрован, ага.
И вас с первым апреля :) За стрелку часов на видео отдельный плюсик
Кроме того, все комментаторы прицепились только к личности Малышевой почему-то, а не к конкретному утверждению, хотя автор исходного комментария привёл и другой источник. И поэтому я совершенно не понимаю, откуда столько минусов.
Давайте не будем опускаться до такого уровня дискуссии. Приведите, пожалуйста, конкретные примеры, где Малышева давала бы заведомо неверную или некорректную информацию?
А для чего нужно было бы знать Яндексу соль, с которой телефоны хэшируются на другой стороне? Как раз если бы там было поле для ввода соли, это было бы подозрительно.
Неправда. Если телефоны несолёные (хотя как мы выяснили выше, это совершенно необязательно так), то самый быстрый вариант — предпосчитать и хранить несколько миллиардов и даже триллионов хэшей md5 от всех потенциально возможных номеров телефонов. А если используется соль (неизвестного формата и длины), то и радужные таблицы не сильно помогут.
А вообще, в статье домыслы на домыслах и домыслами погоняют: «разумно предположить», «веры нет никакой», «скажем прямо» и остальное, ну куда это годится. Хотел почитать про «слежку от яндекса», а оказалось, там всего лишь выкатили недотестированный релиз. Ну это что получается, шпион все собираемые данные ещё и на устройстве жертвы сохраняет? Для бэкапа что ли, чтоб не потерять, или чтобы его обнаружили побыстрее?
Не факты, а одни лишь предположения, местами ещё и необоснованные выводы, ну на троечку с минусом, я бы сказал.
Если задача именно в этом — автоматическая разблокировка зашифрованного диска при запуске системы — то ещё проще использовать TPM2. В ubuntu 20.04 это делается примерно так (только надо ещё соответствующие пакеты поставить, минимально необходимый список не подскажу, но достаточный примерно такой: clevis clevis-luks clevis-tpm2 clevis-initramfs clevis-systemd):
+secure boot, +автоподписывание собираемых DKMS модулей, и вот уже более-менее защищенная система получилась (если её не включать, конечно). Отчуждаемый носитель по определению надежнее, но тут уже вопрос рисков, от которых защищаемся.
Честно скажу, тут я не особо в курсе, как эти штуки работают под капотом, но сначала попробовал бы решить именно эту проблему — попадание «белых» адресов в zeroconf/avahi. По моей идее, в локалке они должны ходить друг к другу только по ULA адресам. Если всё внутри работает по ULA, остальных проблем с доступом между хостами и тормозами не должно быть.
Имелось в виду, что для доступа к fileserver.local:443 снаружи можно пойти двумя путями: поднять на нём отдельный DynDNS клиент с отдельной записью fileserver.blablabla, либо пробрасывать в него порт с router.local. FW при этом никуда не девается, просто разные правила при этом нужно добавлять.
Ну да, но всегда найдется кто-то, кто захочет сделать всё по-своему.
>Вы очевидно не в курсе работы NAT
Допустим, просвещайте
>Те из них, что «симметричные», откликаются на входящие на конкретный внешний адрес только для установленного для него ремотного
И много вы знаете квартир, в которых работает симметричный NAT?
>даже если NAT конусовый, кто будет _с_ внутренних критичных портов стуаться наружу
Эту часть я вообще не понял, кто, зачем, куда стучится, какую проблему мы решаем — ничего непонятно.
>Это всё ручные действия.
Ну и что? Чем это плохо, если речь о домашних пользоателях и одном-двух сервисах, которые хочется открыть наружу?
>STUN, TURN.
Круто: сделаем себе NAT, огребём проблем и будем их героически решать
>PCP
Требуется поддержка со стороны софта, насколько я понимаю.
Предлагаю сделать проще: опишите ещё раз, пожалуйста, сценарий, в котором возникает проблема, саму эту проблему, как именно её решает маскарадинг (или какой там вид NAT считается «полноценным») и почему её нельзя решить без него в IPv6. Наверняка такие сценарии действительно существуют, только вот сомневаюсь, что они относятся к домашним сетям.
Тот NAT, который в IPv6 становится не нужен — это маскарадинг, когда все хосты во внутренней сети использут ТОЛЬКО приватные адреса, и выходят в интернет через единый шлюз, используя единственный выданный провайдером внешний адрес на всех. Маскарадинг — это достаточно хитрый костыль, и у него есть свои ограничения и недостатки, при этом он на самом деле решает лишь одну-единственную насущную проблему, остро выраженную именно в IPv4: нехватку публично доступных адресов.
Ну, допустим
>и тем самым значительно усложняет атаки извне
Это каким же образом? Теперь у атакующего есть один IP адрес, на котором висят несколько открытых портов. Перебор портов на одном адресе — гораздо более простая задача, чем поиск откликающихся на SYN адресов в /64 подсети.
>То есть вы выступаете за вариант 3, но при этом говорите про «никакой»
Окей, пусть будет вариант 3, видимо я не смог его распарсить. На самом деле тут во многих случаях никакого анализа пакетов не требуется, если правильно настроить сервер (например, у FTP и торрентов можно ограничить диапазон используемых портов и в FW открыть их все сразу), но допустим. Так всё же, чем тут NAT-то вам может помочь? Наоборот, он как раз всё усложняет, как вы собираетесь NAT-ить тот же FTP? С NAT-ом вам нужно помимо FW ещё правильно форвардинг порта настроить.
В той ветке, кстати, так и не был получен ответ на вопрос, чем тут может помочь NAT.
Почему? Как от этого поможет «полноценный NAT»?
>выдают новый префикс — тормоза
Опять же, почему?
Для внутренней сети можно использовать адреса ULA, они будут более-менее статические и работать будут всегда, тормозить ничего не будет. Для выхода в интернет каждое устройство будет использовать tempaddr, а в качестве постоянного глобального адреса (на случай необходимости организации доступа извне без форвардинга) — адрес из выданной провайдером через DHCPv6-PD подсети. Этот адрес будет изменяться только при смене провайдера, так что для устройств, недоступных извне, смена провайдера будет прозрачна, а для остальных хватит того же DynDNS либо проброса портов.
Ну, или я что-то не так понял.