Уязвимость в реализации NFS-сервера FreeBSD и OpenBSD

Ну, значит не туда заглядывали.

Последнее они исправляли что-то в клиенте, а тут вылезло в сервере.

всё что имеет доступ в интернет имеет кастыли и уязвимости

Не всё имеет костыли, но да, уязвимость всегда найдётся, потому что человеческий фактор никто не отменял.

мы живём в крайне интересное время, когда хомячок даже и не задумывается о предустановленных python 3.11/perl в linux дистрибутивах

Причём здесь Python и Perl?

Я и не утверждал что SMB лучше NFS, я утверждаю что оно другое (подход, реализация). И проблемы у Samba совсем в другом обычно. ☺

В идеале NFS используется с amd, который кеширует и синхронизирует файлы + завязана на какую-нибудь распределённую систему авторизации. Имеет сильно меньше оверхеда, чем SMB, сравнимо с ftp. В любом случае, настраивать её нужно долго, аккуратно и только если она нужна (а не файлики шарить), ну и сильно внутри локальной сети.

Ладно, раз не хочешь подробностей, то и отвечу без подробностей: в большинстве случаев желателен какой-то управляемый движок для этого.

В большинстве случаев это решается файловой шарой. Потому что работает.

В идеале NFS используется с amd, который кеширует и синхронизирует файлы

amd закопали ещё в 13.0.

Даже без этой дырки, NFS не безопасна, она быстра и хорошо совместима на unix системах, защита лежит сугубо на тебе, это твоя задача vpn пробрасывать и шифровать, авторизация кербос есть, но это не про защиту.

NFS не безопасна

Так в NFS вродь как давно уже завезли шифрование и авторизацию через Kerberos 5. Судя по всему, у тебя познания о NFS 10-ти летней давности.

А что теперь кеширует и синхронизирует? А, нашёл, почти то же самое.

Да, для меня тоже было внезапно: настроил amd в 12.2, заглянул в ман, а там “deprecated, use automountd(8) instead”, пришлось изучать и перенастраивать. В любом случае amd было глючным, так что не могу сказать что произошло что-то плохое.

Ну, даже с глючным amd было лучше, чем без него.

У amd шары могли отваливаться и больше не приваливаться, потому что маунтпоинт уже занят. А у autofs проблема в заморозке процессов, которые пытаются достучаться до отвалившейся шары. Последнее, вполне вероятно, случается потому что оно требует некоторого тюнинга, но с приходом NFSv4 нужда в этих демонах отпала полность, я считаю. Как только NFSv4 переподнимается (даже если это был ребут сервера, а клиенты предварительно не были отмонтированы), клиенты сразу подхватывают. Достаточно прописать в fstab и забыть. С NFSv3 это, разумеется, не прокатит, и без autofs уже не обойтись.

загуглил, про кербос я знаю настраивал, про шифрование читаю:

Unfortunately, NFS wasn’t designed for security. Fact is, the protocol doesn’t have any. If you give an NFS file server a valid handle for a file, the server lets you play with it to your heart’s content. Go ahead, scribble away: the server doesn’t even have the ability to log the network address of the workstation that does the damage.

перевод

К сожалению, NFS не был разработан для обеспечения безопасности. Дело в том, что в протоколе ее нет.

Кербос позволяет сказать что на этом ip сидит вот этот редиска-пользователь и не более, шифрованием он не занимается. Шифрование не добавили видимо потому, что это UDP протокол не потоковый. Все инструкции по использованию говорят, либо доверенная сеть, либо используй vpn. Может я ошибаюсь (хочу ошибиться) но в свежем 2016г. RFC 7862 шифрования не нашёл 😥.

ты прав, я не прав есть опция для шифрования трафика

krb5p Use Kerberos for authentication, integrity checking and encrypt all traffic between the client and server. This is the most secure, but also incurs the most load.

что это UDP протокол

Начиная с NFSv4 работает по TCP. Смотри RFC 7530.

но в свежем 2016г. RFC 7862 шифрования не нашёл

Пункт 4.9.1.2:

Servers SHOULD reject COPY_NOTIFY requests that do not use RPCSEC_GSS with privacy, thus ensuring that the cnr_stateid in the COPY_NOTIFY reply is encrypted.

Коменты далее я не читал, # - решетка == решето

Не так. Если мы сравниваем высокоуровневые(+/-) языки.

Т.е. в твоей вселенной C, C++, Go, Prolog и Lisp читаются одинаково легко вне зависимости от того, что на них написано / равноценны во всех отношениях?

Давно нашлась. При прочих равных, если не заставлять пользователя ЯП городить boilerplate и закатывать Солнце руками, возможности сделать логическую ошибку сокращаются. Факт.

Это всё хорошо, но я почти уверен, что, в отличие от ssh и даже дырявого openssl, nfs-шифрование почти никто всерьёз не тестировал. И дело даже не только в шифровании, а в том что там костыль на костыле, работающий по принципу «работает и ладно».

Если нужно шифрование, проще пустить NFS через wg.

nfs-шифрование почти никто всерьёз не тестировал.

NFS шифрование это лишь слой на основе Ketberos, который стабильный и проверен временем. Используется, к примеру, в MS AD начиная с Windows 2000 Server и особых нареканий не вызывает. Какого еще тестирования тебе не хватает?

а в том что там костыль на костыле

Где ж там костыль, если авторизацию и шифрование сначала планомерно разработали в виде RFC и лишь потом реализовали в рамках нового протокола NFSv4? Если бы его прикрутили к NFSv3 – я бы согласился.

NFS шифрование это лишь слой на основе Ketberos, который стабильный и проверен временем. Используется, к примеру, в MS AD начиная с Windows 2000 Server и особых нареканий не вызывает. Какого еще тестирования тебе не хватает?

Тестирования кода этого слоя в линуксовом ядре не хватает.

Тоже мне проблема. Виновата сишка, авторы все умственные силы потратили на слежку за указателями да освобождением памяти, вот на логику их уже и не хватило. А писали бы на лиспе, всё бы хорошо было с самого начала.

Тестирования кода этого слоя в линуксовом ядре не хватает.

С чего такие выводы? Суровый энтерпрайз вродь как давно для себя протестировал и юзает в проде. Фича вродь не вчера появилась.

вродь

Вот именно. Я ни разу в жизни не видел чтобы кто-то это использовал. Обычно чуваки просто делают отдельные vlan’ы и фильтруют по IP.

Какого еще тестирования тебе не хватает?

Тестирования итогового продукта, а не спецификаций которыми его обложили. У меня такое впечатление, что ты из тех, кто проведённую работу оценивает по бюрократическим бумажкам, написанным в ходе её выполнения. Это плохой подход.

MS AD начиная с Windows 2000 Server и особых нареканий не вызывает

Нашёл на кого равняться. Я ни один виндузятный протокол без ssh-туннеля в инет не пущу.

сначала планомерно разработали в виде RFC

Опять бумажки. Вот tcp/ip разработали в виде rfc, это не мешает тому что в ядре уязвимости в его драйвере находили. Уязвимости, разумеется, в rfc специфицированы не были, это самодеятельная добавка от реализаторов.

Где ж там костыль,

Костыли там в том что это мешанина из ядерных модулей, пачки мутных демонов и странных правил взаимодействия узлов между собой.

Давно нашлась. При прочих равных, если не заставлять пользователя ЯП городить boilerplate и закатывать Солнце руками, возможности сделать логическую ошибку сокращаются. Факт.

Тогда надо не пайтон, а лисп.

Обычно чуваки просто делают отдельные vlan’ы и фильтруют по IP.

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

На безопасности не экономят!

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

Дело не в некоторых, дело в том, что я NFS видел всего в двух видах: free for all и через фильтрацию по IP тем или иным способом. Шифрования я не видел ни разу.

Я ни один виндузятный протокол без ssh-туннеля в инет не пущу.

Ты не путай протокол шифрования от того, что шифруют. Ломают, в подавляющем большинстве, сам сервис а не шифрованный протокол по которому он коммуницирует.

Костыли там в том что это мешанина из ядерных модулей, пачки мутных демонов и странных правил взаимодействия узлов между собой.

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

Шифрования я не видел ни разу.

Потому, что не сталкивался с ворклодом для которого NFS с шифрованием будет актуален.

П.С: годков 8-10 назад, в одной американском компании, с тысячами серваков под виндой и линуксом, заменили CIFS и iSCSI на шифрованный NFS и были счастливы, так как скорость доступа к стореджам существенно улучшилась и уменьшились задержки на чтениях мелких блоков. Юзался CIFS потому, что приходилось тащить кучу легаси.

заменили iscsi на nfs и уменьшились задержки

Прости, но не верю.

Ты не путай протокол шифрования от того, что шифруют. Ломают, в подавляющем большинстве, сам сервис а не шифрованный протокол по которому он коммуницирует.

У меня нет желания разбираться где там протокол шифрования, а где протокол приложения, и какие индусы там что из этого реализовывали. Всё виндузятное - в ssh-туннель, поскольку доверия никакого.

Так причем здесь шифрование NFS? Тут проблема в архитектурном легаси NFS которое тащится десятилетиями.

Я не знаю причём тут шифрование, это ты его зачем-то приплёл. Вот мой исходный коммент: Уязвимость в реализации NFS-сервера FreeBSD и OpenBSD (комментарий) там именно про общую костыльность. Впрочем шифрование, внедрённое в кучу костылей, доверия тоже не вызывает.

Если по религиозным убеждениям это тебя не устраивает – не юзай.

Это не религиозные убеждения а вполне практические: если прога насквозь легаси с костылями - в ней велика вероятность дыр. Ни и да, не юзаю.

На моей памяти, NFS всегда был большой дырой — что в GNU/Linux, что в SUN Solaris. Не припомню, где бы были гарантированно безопасные реализации.