Win10 NFS 客户端是 SAMBA 杀手吗?

Win10 NFS 客户端是 SAMBA 杀手吗?

由于微软最近撤回了对 Windows 7 的支持,我们终于让最后一批顽固的 Windows 7 用户升级到了 Windows 10,因此现在整个企业要么使用 Ubuntu 18.04,要么使用 Windows 10。

因为 Windows 10 有一个 NFS 客户端,所以现在的问题是是否要放弃 SAMBA 而采用 NFS。

具体来说,既然我们所有的 Windows 客户端都支持 NFS,那么还有理由保留 SAMBA 吗?

答案1

SMB 3.xx 比“通用” TCP 连接具有更好的调整性能,并且具有 Microsoft 未在“其”(实际上是许可的)NFS 客户端中实现的 RDMA 和多通道支持等功能。

答案2

服务器消息块 (SMB) 是 Samba 软件使用的协议,如果部署时足够安全,可能会更容易。网络文件系统 (NFS) 被戏称为“无文件安全性”。这是个玩笑名称,但“无文件级安全性”可能是一个具有准确含义的名称。换句话说,NFS 安全性基于共享分区,而不是单个文件,因此 NFS 协议不强制执行文件级权限。

据我所知,NFS 服务器可以关注文件并拒绝无效请求。但是,并非所有 NFS 软件都会这样做。该协议倾向于让客户端请求驱动器上的数据块,而服务器可以通过从磁盘读取该块来满足该请求,而不必关注该块属于哪个文件。

即使您发现 NFS 实现是安全的,如何防止将来发生更改而导致 NFS 实现/部署安全性降低的可能性?如果您有安全方面的顾虑,那么回答这样的问题可能非常有价值。

使用 SMB,人们可以共享目录而不是分区。这可以帮助您确信您只共享您想要的目录,而不是位于驱动器层次结构不同部分的其他目录。

编辑:又来了一位新挑战者。对此答案的评论声称这是偏离目标的。因此,我寻找了一些有助于支持这一观点的历史悠久的文献。我很容易就找到了支持我答案中主张的材料:

首先,“Secure Networks Inc.”于 1997 年 3 月 7 日发布了一份“安全公告”,标题为“4.4BSD NFS 文件句柄”. (该超链接来自 OpenBSD 网站:SecList.org BugTraq 邮件列表存档(1997 年):4.4BSD NFS 文件句柄显示与旧邮件列表相同的内容,但添加了标题。 PacketStormSecurity:SNI BSD 文件句柄咨询也显示同一篇文档。

本文讨论了 NFS 提供数据的基于块的性质(这可能是我理解这个特定漏洞的来源)。

该文件已由多个组织托管。以下是另一份报告,似乎与该文件毫无关系:“为什么 NFS 很烂”,作者是“SUSE/Novell Inc.”的“Olaf Kirch”[电子邮件保护]说:

“NFS 并不关心您导出的是 reiser、ext3 还是 XFS,是 CD 还是 DVD。这直接导致 NFS 需要一种相当通用的机制来识别文件系统上的对象。” ... “只有服务器需要了解文件句柄的内部格式。” ... “Linux 引入了目录缓存的概念,又称 dcache。dcache 中的条目称为 dentry” ... “VFS 层中的几乎所有函数都期望 dentry 作为参数,而不是(或除了)它们过去使用的 inode 对象。” “这让 NFS 服务器变得有趣,因为 inode 信息不再足以创建 VFS 层愿意操作的东西” ... “攻击者可以拦截具有有效凭据的数据包,并篡改 NFS 请求以执行他们自己的恶意命令。”

至于我对这个绰号的看法, https://news.ycombinator.com/item?id=10967064备份:

1987 年,Sun 的工程师们普遍认为 NFS 代表“无文件安全”

第一个屏幕显示了几个不同的漏洞,包括根据客户端计算机报告的主机名信任某人。

Google 图书:引用自《Ubuntu Linux 实用指南》的材料笔记:

默认的 NFS 安全性是边缘的甚至不存在的(一个常见的笑话是 NFS 代表无文件安全性或噩梦文件系统),因此不应允许您网络之外的不信任的机器进行此类访问。

eTutorials.org 上的 NFS 配置部分笔记:

如果您通过 Internet 安装文件系统,则传输的文件可能会随时受到干扰甚至被篡改(有些人开玩笑说 NFS 是“无文件安全性”的缩写)。

相关内容