но пока он не заменяет старый код а добавляется к нему - добавляются и его уязвимости. Если раньше можно было атаковать только код в стеке IPv4, то теперь можно атаковать и его, и код в стеке IPv6 - следовательно поверхность атаки увеличилась.
Это какая-то очень эзотерическая логика. Чем меньше кода, тем больше его защищённость, серьёзно? Ну ок, давайте повыкидываем обработку эксепшнов, канареек из стэка выбросим, санитайзеры всякие, zerofill-аллокации, сборщики мусора, вот это всё. Сразу защищённее станет, ага.
Но по факту - он таки более уязвим (хоть в данном контексте это и не важно). Просто потому, что он более новый и он менее активно используется - а в таких условиях в коде всегда больше ошибок, если сравнивать с аналогичным но более старым и проверенным. И в этом легко убедиться: поиск "linux ipv4" по CVE выдаёт 4 результата за 2023 год, а аналогичный для ipv6 выдаёт 11.
А почему только за 2023 год? Я вот сделал поиск по всей базе, и для "linux ipv4" нашлось 84 результата, а для "linux ipv6" -- 88 результатов. Огромная разница, ага. Причём подавляющее большинство их вообще никак не относилось к разнице между реализациями протокола IP этих версий.
Кстати, по "linux netware" за всё время нашлось аж 5 уязвимостей. По вашей логике, его код, получается, в 16 раз более защищён, чем IP.
Все эти "для безопасности/приватности" фичи реализованы, но по умолчанию все они выключены.
Вы в этом видите большую проблему? Добавить\поменять один небольшой скриптик в установщике дистра?
Как думаете, какой процент устройств в домашних локалках будет их использовать
А вы как думаете, какой процент устройств в домашних локалках будет линуксом? :)
Потому как я лично видел RFC 8981 на виндах включённый и работающий под SLAAC по умолчанию ёщё, емнип, на Windows 7.
и скажется ли это хоть как-то на общей ситуации с безопасностью? (Вопрос риторический.)
Никак. Проникновения, для которых требуется находить конкретную жертву по ёё IP, выловленному на скомпрометированном ресурсе, занимают доли процента на фоне всяких фишингов. С тех пор, как нетбиос перестал торчать в инет, я даже не припомню ни одной атаки такого класса.
В IPv6 просто гораздо меньше сценариев, которые требуют человеко-читать IP адрес.
которые к тому же будут привязаны к оператору (поменяли оператора - поменялись все адреса в локалке)
RFC 6275 вам в помощь.
, то с IPv6 так не получится.
Это почему вдруг? Прекрасно раздаётся статика хоть по slaac хоть по dhcp6.
Попробуйте представить, что нужно сделать SOHO админу, что бы перевести все на IPv6
Переводил всё на IPv6, вернее на дуалстэк в одной конторе. Ничего более сложного чем поднятие пары демонов на пограничном роутере и некоторых локальных заморочек с pac-скриптом.
Адрес - информация не секретная. Он виден на каждом ресурсе, к которому обратился
В IPv6 -- секретная.
Интерфейс, кроме основного адреса может нахватать сколько угодно дополнительных-временных, с которых и будет ходить на все нужные ресурсы и не принимать коннекты на них. А принимать только на основном, который не светится нигде, кроме явно указанных мест.
IPv4 так не сумеет, если только вы не купите по паре белых айпи каждой рабочей станции :)
Нет, не увеличивает. Вы не сможете, как с IPv4, просканировать /64 за вменяемое время, если там сидит RFC 4941, а оно там сидит везде по дефолту уже давно.
А я ещё застал времена, когда vk.com был доступен по IPv6.
Простейший пример - протокол FTP, активный режим. Там приложение говорит: мой адрес такой-то, подключайся.
Так FTP в активном режиме сквозь NAT не заработает и в IPv4, так что приходится городить костыли с вмешательством в контрольное соединение или принудительно всех заставлять работать в пассивном режиме.
Хотя, вообще, FTP в 2024 году это уже позор позорный, при наличии всяческих SFTP, rsync и прочего.
Из книжки в книжку и из статьи в статью эту хрень бездумно переписывают :(
Виртуальная память позволяет системе исполнять код приложений, используя больший объем памяти, чем физически доступно. Это достигается путем сброса неиспользуемых блоков памяти приложений на диск
А если диска нет (тонкий клиент, например), или свопинг вообще отключен, то что тогда с виртуальной памятью происходит? Она ведь как-то всё равно продолжает работать?
А философия Линукс в случае заключается в том, что всегда следует стремиться сделать данные человеко-читаемыми. И отступать от этого только если обстоятельства не позволяют (например производительность).
Вот эти линукс-философы на ранней стадии развития Интернета понапридумывали человеко-читаемых протоколов, все эти HTTP/SMTP/POP3/IMAP/IRC/Telnet/SIP/XMPP и, прости г-ди, FTP, кое-где даже нарушая разделение сетевой модели на уровни. Плюс извращения вроде того, что кошерный SMTP обязательно должен влезать в 7-битный ASCII, так что извольте сексоваться с MIME туда-сюда.
А сейчас не могу не заметить явную тенденцию, что всё, что приходит им на смену -- сплошная бинарщина. Не отдельные изолированные случаи нехватки производительности, а просто везде. http/3,grpc,mtproto,ssh и всё в этом же духе.
Как, глядя на данные, мне нужно понять, что их надо представлять в машино (компиляторо) нечитаемом виде?
Очень просто. Вы же знаете, кто эти данные будет читать, исходя из ТЗ и архитектуры проекта? Ну вот в таком виде и представляйте.
Тем более, я конкретные примеры привёл.
статья про код.
Статья -- да. А конкретно эта ветка -- про особенности текстового представления десятичных дробей и смежные проблемы. Ваш экскурс в компиляторы вообще не уместен.
Это какая-то очень эзотерическая логика. Чем меньше кода, тем больше его защищённость, серьёзно? Ну ок, давайте повыкидываем обработку эксепшнов, канареек из стэка выбросим, санитайзеры всякие, zerofill-аллокации, сборщики мусора, вот это всё. Сразу защищённее станет, ага.
А почему только за 2023 год? Я вот сделал поиск по всей базе, и для "linux ipv4" нашлось 84 результата, а для "linux ipv6" -- 88 результатов. Огромная разница, ага. Причём подавляющее большинство их вообще никак не относилось к разнице между реализациями протокола IP этих версий.
Кстати, по "linux netware" за всё время нашлось аж 5 уязвимостей. По вашей логике, его код, получается, в 16 раз более защищён, чем IP.
Очень странную вы метрику выбрали.
Вы в этом видите большую проблему? Добавить\поменять один небольшой скриптик в установщике дистра?
А вы как думаете, какой процент устройств в домашних локалках будет линуксом? :)
Потому как я лично видел RFC 8981 на виндах включённый и работающий под SLAAC по умолчанию ёщё, емнип, на Windows 7.
Никак. Проникновения, для которых требуется находить конкретную жертву по ёё IP, выловленному на скомпрометированном ресурсе, занимают доли процента на фоне всяких фишингов. С тех пор, как нетбиос перестал торчать в инет, я даже не припомню ни одной атаки такого класса.
Это слишком громко сказано -- "военные изобрели".
Максимум -- профинансировали разработку технологии, на развитии которой он потом был построен (не ими).
В IPv6 просто гораздо меньше сценариев, которые требуют человеко-читать IP адрес.
RFC 6275 вам в помощь.
Это почему вдруг? Прекрасно раздаётся статика хоть по slaac хоть по dhcp6.
Переводил всё на IPv6, вернее на дуалстэк в одной конторе. Ничего более сложного чем поднятие пары демонов на пограничном роутере и некоторых локальных заморочек с pac-скриптом.
В IPv6 -- секретная.
Интерфейс, кроме основного адреса может нахватать сколько угодно дополнительных-временных, с которых и будет ходить на все нужные ресурсы и не принимать коннекты на них. А принимать только на основном, который не светится нигде, кроме явно указанных мест.
IPv4 так не сумеет, если только вы не купите по паре белых айпи каждой рабочей станции :)
С чего вы взяли, что код, реализующий IPv6 как то более уязвим, чем код, реализующий IPv4 ?
Нет, не увеличивает. Вы не сможете, как с IPv4, просканировать /64 за вменяемое время, если там сидит RFC 4941, а оно там сидит везде по дефолту уже давно.
Не сложность, а лень админов. Ничего принципиально сложного в v6 нет.
Вот так и про UTF говорили. Мол значительно сложнее считать длину, зачем это нужно, всё ж и так работает...
А я ещё застал времена, когда vk.com был доступен по IPv6.
Так FTP в активном режиме сквозь NAT не заработает и в IPv4, так что приходится городить костыли с вмешательством в контрольное соединение или принудительно всех заставлять работать в пассивном режиме.
Хотя, вообще, FTP в 2024 году это уже позор позорный, при наличии всяческих SFTP, rsync и прочего.
А вы можете эту сложность выразить в каких-нибудь измеримых значениях?
Из книжки в книжку и из статьи в статью эту хрень бездумно переписывают :(
А если диска нет (тонкий клиент, например), или свопинг вообще отключен, то что тогда с виртуальной памятью происходит? Она ведь как-то всё равно продолжает работать?
Хорошим тоном в статьях считается расшифровывать аббревиатуры там, где они встречаются впервые в тексте.
Баадера-Майнхоф?
Вы не доверяете подсчётам, а предпочитаете верить. Но требуете всё же почему-то не амулет на удачу, а близкую к 100% вероятность.
Так не смотрите новости, делов-то. Если в этом проблема.
А то ведь шанс быть сбитым машиной на улице на порядки выше, но вас это от выхода из дому не останавливает же.
Не только в Боингах. Вообще вся авиация использует футовые эшелоны (кроме некоторых стран Средней Азии)
https://en.wikipedia.org/wiki/Flight_level
Ага, чемоданы денег заносят разработчикам, чтобы они, не дай бох, не изобретали новые текстовые форматы обмена данными.
Вот эти линукс-философы на ранней стадии развития Интернета понапридумывали человеко-читаемых протоколов, все эти HTTP/SMTP/POP3/IMAP/IRC/Telnet/SIP/XMPP и, прости г-ди, FTP, кое-где даже нарушая разделение сетевой модели на уровни. Плюс извращения вроде того, что кошерный SMTP обязательно должен влезать в 7-битный ASCII, так что извольте сексоваться с MIME туда-сюда.
А сейчас не могу не заметить явную тенденцию, что всё, что приходит им на смену -- сплошная бинарщина. Не отдельные изолированные случаи нехватки производительности, а просто везде. http/3,grpc,mtproto,ssh и всё в этом же духе.
Не спроста это жжж.
Вам от этого легче станет?
Ну окей, я был неправ по поводу того, что "нет там такого".
Остальное всё в силе.
Очень просто. Вы же знаете, кто эти данные будет читать, исходя из ТЗ и архитектуры проекта? Ну вот в таком виде и представляйте.
Тем более, я конкретные примеры привёл.
Статья -- да. А конкретно эта ветка -- про особенности текстового представления десятичных дробей и смежные проблемы. Ваш экскурс в компиляторы вообще не уместен.
Попытался представить себе условный нетфликс, который стримит фильмы в текстовом потоке...
Эти принципы, как и любые другие, имеют свою область применимости. И не следует возводить их в абсолют.