如果你管理过TrueNAS尤其是一台承载着公司文件共享服务的TrueNAS那么迟早会面对这样一个灵魂拷问“这个文件到底是谁删的”“昨天下午谁动过这个目录”“销售部那批合同被人打开过没有”。在没有审计日志之前这种排查基本靠猜靠翻聊天记录靠“你动过吗”“我没有啊”的拉锯战。而配置了Samba的Full_Audit VFS模块之后每一个打开文件、创建目录、删除条目、重命名的操作都会老老实实被记录下来。这篇文章就基于我最近在一台TrueNAS Scale实例上做的Full_Audit审计日志配置把完整的操作思路、配置细节、验证方法以及那些文档里不会告诉你的坑一次性讲清楚。这篇文章适合谁适合正在使用TrueNAS Core或Scale做文件共享的运维人员、企业IT管理员也适合那些被“文件丢失但查无可查”问题折磨过的朋友。我这里讲的是实测过的完整流程不是照着官方文档念一遍。配置本身不难难的是理解每个参数到底干了什么以及日志出来之后怎么用。1. 为什么选择Full_Audit它解决了什么问题1.1 Samba审计的几种实现方式Samba本身要记录文件操作其实有不止一条路可走。我在最初研究这个需求的时候先大概梳理过几种方案第一是直接用Linux系统层面的auditd来监控文件访问这个方案的好处是不管你用Samba、NFS还是本地访问都能记录缺点是日志量巨大而且auditd的规则写起来也麻烦和SMB协议层的用户映射对不上号第二是在Samba里开log level把日志级别调高这个方案确实能记录一些访问信息但日志混杂了大量协议协商、连接建立的信息实际检索效率很低第三就是使用VFS模块也就是本篇要讲的full_audit它工作在Samba内部的文件系统调用层能够把某个共享下的操作精确记录下来。选择全审计方案的关键在于它捕获的信息带有完整的SMB用户上下文。也就是说日志里能直接看到是哪个域用户或者本地用户通过SMB协议做了什么操作而不是只看到一个系统层面的uid。这对于企业排查“谁动了我的文件”这个问题价值是完全不同的。另外Full_Audit对的性能影响相对可控。它的工作方式是在文件系统调用前和调用后各做一次检查如果你只记录失败操作对性能影响几乎可以忽略。即使像我这样把读写删除等关键操作全记录下来在一般中小企业的并发规模下也完全够用。我之前看过Samba官方文档和一些性能测试帖子Full_Audit带来的开销通常在个位数百分比范围内远比全局抓包分析要轻量得多。1.2 这套方案能记录到什么程度这里需要把Full_Audit的能力边界说清楚免得大家期待值不对。它能够记录的Samba操作包括但不限于打开文件open、创建文件create_file、目录创建mkdir、删除unlink、目录删除rmdir、重命名rename、读read、写write、关闭close、获取属性getattr、设置属性setattr等等。基本覆盖了SMB协议下最常见的文件操作类型。需要注意的是Full_Audit记录的是Samba进程通过VFS层发起的操作而不是底层块设备或者文件系统层面的操作。换句话说如果你是SSH到服务器上直接改文件Full_Audit是管不到的因为那条路径根本不经过Samba。搞清楚这个边界后续排查的时候就不会被误导。还有一点Full_Audit并不像数据库binlog或者文件系统快照那样具备记录文件内容变化的能力。它能告诉你“某用户在某个时间删掉了某个文件”但不能帮你把删除的内容捞回来。所以审计日志是安全体系的辅助手段不能替代备份策略。这一点我觉得再怎么强调都不为过我看到不少人在配置审计日志之后反而把备份给松懈了这完全走偏了。2. 配置前的准备环境确认与模块检查2.1 版本差异和路径差异我的生产环境跑的是TrueNAS Scale基于Debian的那条产品线所以很多操作在Web界面和底层文件系统路径上和老的TrueNAS Core基于FreeBSD会有差异。Core的Samba配置管理方式和Scale也有不少区别尤其是在共享配置的存储位置、辅助参数的写入方式上。如果你用的是TrueNAS Core那么Samba的配置文件一般位于/etc/smb4.conf实际上很多版本是运行时生成的修改方式也大多依赖WebUI的辅助参数Auxiliary Parameters功能。而Scale这边的配置文件在/etc/samba/smb.conf同样是系统生成的直接修改会在重启服务后被覆盖。因此正确的姿势永远是在TrueNAS Web界面的共享配置里添加辅助参数或者通过System Settings里的Advanced配置来加而不是动手去改配置文件。在动手之前我强烈建议先确认一下当前Samba的版本。方法是进入TrueNAS的Shell执行samba --version。不同版本的SambaVFS模块的编译情况和参数支持会有细微差异比如老版本对某些full_audit参数的支持就不完整。我见过有人在旧版本Samba上配置了新参数名结果模块直接加载失败。另外通过smbd -b可以查看编译时支持的模块路径方便后面确认full_audit模块到底有没有装。2.2 确认full_audit模块可用TrueNAS系统里Samba的VFS模块通常已经预编译好但我还是建议实际操作前先确认一下。在Shell中执行find / -name *full_audit* 2/dev/null正常情况下能看到类似/usr/lib/x86_64-linux-gnu/samba/vfs/full_audit.so这样的文件。确认了这个文件存在才能说明当前Samba二进制确实支持full_audit功能的动态加载。如果找不到可能是系统自带的Samba没有包含这个模块那就得考虑换源、换版本或者改用其它方案不过在TrueNAS上这种情况很少见。另外要确认一项容易被忽略的内容日志写入的位置和权限。Full_Audit如果配置为写入文件那么Samba进程通常以root或者sambashare用户运行需要有目标日志文件的写权限。如果配置为写入syslog则需要系统syslog服务正常工作。我这次选用的是直接写入文件的方式这样便于集中收集和后续接入日志平台。如果你有现成的ELK或者Loki这类日志系统直接写到syslog再由rsyslog转发到远端也是更规范的做法。3. Full_Audit核心配置实战我采用的配置方案3.1 通过Web界面添加辅助参数第一步是在TrueNAS Web界面里找到需要审计的SMB共享。打开“共享”菜单进入“Windows共享(SMB)”列表点击对应共享右侧的编辑按钮。在编辑界面里找到“高级选项”展开项其中有一个“辅助参数”文本框这里就是填custom配置的地方。需要说明的是不同TrueNAS版本的界面文字略有不同但大致位置都在这附近。你如果找不到直接在系统Shell里看生成的/etc/samba/smb.conf也能确定当前生效的配置内容。我在辅助参数里填的核心配置如下vfs objects full_audit full_audit:prefix %u|%I|%m full_audit:success mkdir rmdir unlink rename open close full_audit:failure all full_audit:facility local5 full_audit:priority notice full_audit:logfile /var/log/samba/audit.log逐行解释一下这些参数的实际含义。vfs objects指定了这个共享要加载的VFS模块列表这里只加载了full_audit。如果已经有其它vfs模块可以参考官方文档的顺序规则一般是全审计要放在栈的指定位置但绝大多数场景下单独使用它没有问题。full_audit:prefix定义的是日志前缀格式。%u是SMB用户名%I是客户端IP地址%m是客户端NetBIOS机器名如果不提供则可能为空这些变量拼接起来就能快速定位来源。full_audit:success列出的是要记录成功操作的操作类型。我这里选了创建目录、删除目录、删除文件、重命名、打开和关闭文件。需要说明的是open和close的记录量会非常之大几乎任何文件访问都涉及生产环境里如果磁盘比较敏感可以先不开这两个只保留mkdir、rmdir、unlink、rename这类高风险操作。full_audit:failure all表示失败操作全记录这样权限不足、文件不存在、路径错误之类的异常行为不会漏掉。full_audit:facility和full_audit:priority是syslog的facility和priority配置如果你选择写syslog就靠它们来区分日志来源。我这里是直接写文件所以facility的设置影响不大但保留它有个好处——以后想切syslog转远端时不用再改Samba配置。full_audit:logfile指定日志写入文件的绝对路径。这个路径要确保Samba进程有权限写我使用的路径是/var/log/samba/audit.log。配置填好之后保存Samba服务通常会自动重载。为了保险起见我建议在Shell里重启一下服务systemctl restart smbd # 或者通过service smbd restart3.2 关于配置文件顺序和参数作用域的补充这里补充一个我在测试中发现的细节如果共享配置里已经存在vfs objects参数而你新填的辅助参数又给了新的vfs objects后者可能会覆盖前者导致原先的VFS模块失效。实际情况取决于Samba配置的合并方式不同版本有所差异所以我在填之前先查看了当前生效的配置testparm -v --parameter-namevfs objects 2/dev/null | grep -A 2 共享名如果原有配置里有模块比如recycle回收站模块那就要把full_audit追加在后面类似vfs objects recycle full_audit。我这次使用的共享是新建的没有额外模块所以直接填了full_audit。另外要注意通过Web界面填的辅助参数是全局生效还是仅对某个共享生效取决于填写的页面。在共享编辑界面的辅助参数是针对该共享的在“系统设置-高级-辅助参数”里填的则是全局的。如果你希望所有共享都进行审计填全局也行如果你只想对一个敏感目录审计就在对应的共享下配置。这个作用域问题一定要搞清楚不然会出现“明明配了却不生效”或者“没配的共享也有日志”的情况。4. 日志验证与数据解读4.1 真实操作后的日志长什么样配置完成之后我立刻在一台Windows客户端上对这个共享做了一系列测试操作包括新建文件夹、重命名文件、删除文件、尝试打开一个没有权限的文件等。然后回到TrueNAS的Shell里查看日志文件tail -n 50 /var/log/samba/audit.log日志的格式大致是2025/01/15 14:23:01.882417, 0[ 1234]: administrator|192.168.1.100|PC01|mkdir|/share/docs/新文件夹|ok 2025/01/15 14:23:12.332019, 0[ 1234]: administrator|192.168.1.100|PC01|rename|/share/docs/新文件夹|/share/docs/改名后|ok 2025/01/15 14:23:20.993421, 0[ 1234]: administrator|192.168.1.100|PC01|unlink|/share/docs/待删除.txt|ok 2025/01/15 14:23:35.204192, 0[ 1234]: administrator|192.168.1.100|PC01|open|/share/docs/机密方案.docx|denied字段从左到右依次是时间戳、进程ID、用户名、客户端IP、机器名、操作类型、文件路径、操作结果ok/denied/error。这样一个日志就形成了一个完整的事件线索再也不用对着用户说“我再查查”了。这里要注意一个细节如果你在full_audit:success里加入了open和close那么日志增长的速度会非常可观。比如用户只是用办公软件打开编辑一个文档并保存可能就会产生若干条open/close记录。这些记录不是问题但会给日志收集和存储带来压力。我当时做验证的时候还用了一个很方便的命令来统计某个时间段内某个用户的操作频次grep 2025/01/15 14:2 /var/log/samba/audit.log | grep administrator | wc -l做这种粗粒度统计对了解共享目录的真实使用烈度比较有帮助。如果某个部门的操作量远超预期就需要考虑是不是有程序在后台反复读写文件或者是不是有人在跑脚本同步数据。这些在日志里都会露出痕迹。4.2 日志里出现的“成功”和“失败”如何理解Full_Audit的success和failure参数是分开定义的也就是说某个操作可能既被记录为成功调用返回正常又被记录为失败权限检查未通过等。在实际日志里我们会看到同一操作类型出现两条记录一条ok一条denied。就拿删除文件来说客户端可能先尝试删除一个文件但因为ACL权限不足失败了这条操作会出现在failure日志里随后客户端调整权限或换用户后删除成功这条则会记录在success日志里。两条都记录才能完整还原全过程。不少人在初看日志时会疑惑“为什么我明明没有做过这个操作日志里却有denied记录”这往往是客户端的一些后台行为导致的。比如Windows资源管理器在打开文件夹时会去读取缩略图、读取文件属性杀毒软件会扫描新文件办公软件会自动创建临时文件再改名。这些行为都会触发Samba的文件操作也都会被记录。所以遇到莫名奇妙的denied日志先别急着认定有人攻击很多情况下只是正常的客户端行为。5. 日志轮转与留存策略审计日志也要过日子5.1 日志太大会发生什么如果审计日志只写不轮转很快会遇到几个问题。最直接的是磁盘空间被慢慢吃光其次是单一日志文件过大后排查时用文本编辑器打开会卡顿grep检索也会变慢还有一点某些老版本Samba在打开日志文件时如果遇到文件过大甚至可能会有IO性能问题。所以给审计日志配置logrotate是必须做的一项收尾工作。TrueNAS Scale本身是基于Debian的所以系统里自带logrotate机制。但系统默认的logrotate配置不会为/var/log/samba/audit.log做处理需要自己添加配置。我这里建了一个新的logrotate配置文件/etc/logrotate.d/samba-audit内容是/var/log/samba/audit.log { daily rotate 180 compress delaycompress missingok notifempty create 0640 root root postrotate if [ -d /run/samba ]; then smbcontrol smbd close-share audit /dev/null 21 || true fi endscript }简单说明下几个关键参数daily表示每天轮转一次rotate 180表示保留180份日志文件配合daily就是大约180天compress启动gzip压缩delaycompress表示延迟一天压缩方便最近一天的日志直接查询create指定新建日志文件的权限和属主这里设为root可读写组可读因为Samba进程通常以root运行读这个日志的运维用户需要加入root组或调整权限postrotate脚本的作用是通知Samba重新打开日志文件避免它一直往已rename的旧文件里写日志。5.2 是否需要把日志转发到远端如果你管理的TrueNAS不止一台或者公司有集中的日志平台建议把审计日志通过rsyslog转发出去。Samba会把full_audit的日志内容以syslog消息的形式交给本机的syslog服务然后你可以在/etc/rsyslog.d/下添加一条简单的转发规则local5.notice 192.168.1.50:514加上这条之后本机日志会同时写入本地文件和远端日志服务器。这种做法可以在TrueNAS本身出现故障、磁盘损坏甚至被入侵的情况下保证审计数据仍然在远端有备份。真的遇到安全事件时这条链路可能成为唯一的取证来源。不过有一个细节要提醒远程syslog传输默认是明文UDP重要的审计日志在网络上传输时建议用TLS封装或者走独立的内部管理网段。虽然多数环境下内部网络威胁面不大但审计日志本身就是为了安全和合规传明文总觉得有点讽刺。我在生产里是把管理网段单独划出来的审计日志转发只允许走这个网段风险会小很多。6. 常见问题排查与避坑实录6.1 日志文件始终不生成怎么办我最初在测试时配置填好之后发现/var/log/samba/audit.log这个文件完全没有被创建。当时的第一反应是权限问题但排查后发现真正的问题是没有触发任何经过full_audit的操作。因为这台共享当时挂载在了一个几乎没人访问的测试目录上所以没有操作就没有日志输出。这听起来像是废话但确实是最常见的原因之一。排除这个原因之后如果还是没有日志第二步我会看Samba是否真的加载了这个VFS模块。可以用以下命令检查testparm -v 2/dev/null | grep -A 30 \[docs\]在共享配置段里如果能看到vfs objects full_audit说明配置生效了。如果看不到多半是辅助参数被覆盖或者没有保存成功要回Web界面重新确认。还有一种情况日志路径的父目录不存在。比如你在配置里写的是/var/log/samba/audit.log但系统里/var/log/samba目录不存在那么Samba启动时会尝试创建但可能因为父目录权限或者SELinux策略失败。TrueNAS Scale上虽然没有SELinux用的是AppArmor但权限问题还是需要排查。最直接的办法mkdir -p /var/log/samba touch /var/log/samba/audit.log chmod 640 /var/log/samba/audit.log chown root:root /var/log/samba/audit.log手动把目录和文件准备好再重启smbd可以省去很多权限相关的折腾。6.2 日志里有记录但没有操作详情怎么办这个问题比较隐蔽。有时候日志能输出但内容只有一行操作类型和结果缺少用户名、IP等前缀信息。这通常是因为full_audit:prefix参数没有生效或者配置里写错了变量名。Samba对变量名拼写比较敏感比如%I是客户端IP%u是用户名%U是连接的UID对应的用户名大小写不同含义完全不同。如果拼写错误Samba会把它当作普通字符串输出而不是替换成实际值。检查的时候可以用testparm看解析后的配置也可以直接查看Samba运行时日志/var/log/samba/log.smbd里是否记录了模块加载错误。我之前遇到过一次是在参数里把%I误写成了%i结果IP地址字段始终不存在。这种小错误很隐蔽不对比日志根本发现不了。6.3 日志量太大如何优化记录策略在配置完成后的一周左右我发现一台面向全公司的共享服务器一天产生的full_audit日志竟然超过了500MB。排在前面的操作类型是open和close——几乎等于记录了所有用户的每一次文件打开和关闭。这个量级对于单独的日志文件来说已经不小了虽然没到爆炸的程度但对于日志检索和留存是个负担。优化措施很简单把full_audit:success里的open close去掉只保留mkdir rmdir unlink rename write等关键写操作。读操作虽然也有价值但在用户量大的环境中属于低信号高噪音对排查安全问题的帮助有限。如果你确实想追踪某段时间的读操作可以通过tcpdump抓包做定向分析而不是长期开启全量审计。此外还可以在Samba配置里按共享拆分日志文件对不同的共享设置不同的full_audit:logfile这样日志之间相互隔离单个文件大小可控后续检索也更方便。代价是需要在每个共享里重复配置一遍参数好在这些参数本身很简单多写几遍也不算什么负担。6.4 重启Samba服务后配置丢失这是一个非常让人抓狂的问题明明配置好了测试也通过了结果TrueNAS系统升级或者手动重启Samba后配置“消失”了。其实配置并没有消失而是你上次直接修改了生成的/etc/samba/smb.conf没有通过Web界面。TrueNAS在服务重启或系统设置变更时会重新生成这个配置文件把所有手工改动覆盖掉。这是TrueNAS的一个设计原则把配置入口收敛到WebUI/API层避免底层文件漂移。所以正确做法从头到尾都是在Web界面的共享辅助参数里填写full_audit配置。如果你有自动化配置的需求可以通过TrueNAS的API来更新共享配置也尽量不要直接改配置文件。我在实验时有一次图省事直接改了smb.conf结果重启后果然被恢复白白浪费了一个下午排查“为什么配置不见了”。6.5 一个容易被忽略的性能细节最后说一个和性能相关的小细节。Full_Audit模块默认记录所有配置为success的操作而每次记录都涉及格式化字符串、打开日志文件、写入、关闭如果每条都独立打开的话。虽然Samba内部对日志文件句柄做了缓存但在极高并发下日志IO确实可能成为瓶颈。我的建议是如果共享服务的并发量很大比如数百人同时在线把日志写入到独立的磁盘上至少不要和Samba的数据目录在同一个物理盘上。否则读写日志的IO会和数据读写的IO相互争抢导致共享服务的吞吐下降。在我自己的环境里数据是在一组HDD上日志目录在SSD上分流之后明显稳了很多。如果你没有独立SSD也可以把日志写到tmpfs内存文件系统但要注意重启后日志会丢失需要配合及时转发到远端才能兼顾性能和持久性。7. 从审计日志到权限治理的一点经验配置完成full_audit之后日志慢慢积累我逐渐发现了一些之前完全没注意到的事情。比如某个离职很久的账号每隔几天就会有一条访问共享目录的denied记录排查发现是某台服务器上残留的计划任务还在用旧账号尝试连接又比如某个文件夹被大量rename和unlink追查发现是有人在跑一个不规范的同步脚本把整个目录当成了临时中转站。这些行为如果没有审计日志靠用户主动上报是永远发现不了的。这让我意识到full_audit真正的价值并不仅仅是出了问题之后追责而是把平时“看不见”的文件访问行为浮出水面。基于这些数据可以对权限策略做进一步收紧。我自己就根据日志调整了好几处共享目录的ACL把那些“偶尔读一下”的外部人员账号的读权限也收回了结果两个月下来没有收到任何抱怨说明那些权限本来就没人在用。如果你所在的企业有等保或者ISO 27001这方面的合规需求一份完整的文件访问审计记录也是检查组非常看重的东西。与其到检查前手忙脚乱地去补不如平时就把full_audit开着让所有文件操作都有据可查。180天留存配合远端转发应付大多数检查项都够用了。