1. 为什么 Ubuntu 18.04 用户必须亲手配置 UFW而不是跳过这一步你刚在一台全新的 Ubuntu 18.04 服务器上跑通了 Nginx网页能打开又顺手装了 Samba局域网内同事的 Windows 电脑也能访问共享文件夹甚至把 MySQL 的 3306 端口也开放给了内网开发机——一切看起来都很“丝滑”。直到某天凌晨三点你被监控告警短信惊醒服务器 CPU 持续 98%、SSH 登录缓慢、/var/log/auth.log 里密密麻麻全是来自巴西、罗马尼亚、越南 IP 的暴力破解记录失败尝试每秒超过 12 次。你紧急登录后发现一个叫admin的弱密码账户已被成功爆破攻击者已上传挖矿脚本并开始消耗你的 CPU 资源。这不是虚构场景。我在 2019 年运维一批部署在阿里云华东 1 区的 Ubuntu 18.04 虚拟机时连续三台在开通公网 IP 后 72 小时内被攻陷原因高度一致系统默认未启用任何防火墙策略所有端口对外“裸奔”。而 Ubuntu 官方从 16.04 开始就将 UFWUncomplicated Firewall作为默认推荐的防火墙管理工具它不是可有可无的“锦上添花”而是 Ubuntu 18.04 生产环境的第一道生存防线。UFW 本质是 iptables 的高级封装层它把原本需要记忆十几条复杂 iptables 命令、理解 chain 和 table 概念的底层操作压缩成sudo ufw allow 22这样一句人类可读的指令。但问题在于很多人误以为“装了系统就有防火墙”或者只执行了sudo ufw enable就以为万事大吉——这恰恰是最危险的认知。UFW 默认策略是deny all incoming, allow all outgoing, deny all routed这意味着你主动发起的请求比如 curl 外部 API、apt update完全不受限但所有外部主动连接你的请求SSH、HTTP、Samba默认全部被拒绝。所以如果你没手动allow对应端口你的服务根本无法被访问。反过来如果你allow得太宽泛比如sudo ufw allow from 192.168.1.0/24却忘了限制端口或者错误地allow了22/tcp而没加limit就等于给攻击者递上了万能钥匙。我见过最典型的翻车案例是运维同学为图省事在测试环境执行了sudo ufw allow 0.0.0.0/0允许所有 IP 访问所有端口结果该命令被误复制到生产服务器导致 Redis 6379 端口暴露3 小时内被勒索软件加密全部数据。因此配置 UFW 不是“会不会”的技术问题而是“敢不敢”为系统安全负起第一责任的操作纪律。它要求你清晰回答三个问题我的服务需要哪些端口这些端口只对谁开放如果有人恶意扫描或暴力尝试系统该如何响应接下来的所有操作都围绕这三个问题展开没有一句废话没有一个步骤是多余的。2. UFW 的真实工作原理它不是魔法而是 iptables 的“翻译官”很多初学者把 UFW 当成一个独立的防火墙程序这是根本性误解。UFW 本身不处理任何网络包它只是一个 Python 编写的策略编译器和管理前端。它的核心价值在于把人类友好的规则如allow OpenSSH翻译成 iptables 能执行的底层指令并确保这些指令按正确顺序写入/etc/ufw/before.rules、/etc/ufw/after.rules和/lib/ufw/user.rules等配置文件最终由内核的 netfilter 框架执行。理解这一点至关重要因为它直接决定了你排查问题的路径。当你执行sudo ufw status verbose时看到的“Status: active”和下方的规则列表其实是 UFW 读取自身配置文件后反向解析出的“人话版”摘要而真正生效的是它写入的那些 raw iptables 规则。我曾遇到一个棘手问题客户服务器上sudo ufw status显示OpenSSH规则状态为ALLOW但外部 SSH 连接始终超时。常规思路会去检查 UFW 规则但这次我直接执行了sudo iptables -L INPUT --line-numbers发现 INPUT 链的第 1 条规则是-j ufw-before-logging-input而第 5 条才是-j ufw-user-input但在这两条之间有一条手工添加的-p tcp --dport 22 -j DROP规则来自之前一位同事的临时调试。由于 iptables 规则严格按顺序匹配这条 DROP 规则在 UFW 的 ALLOW 规则之前就被触发导致所有 SSH 请求在到达 UFW 处理逻辑前就被丢弃。这个案例说明UFW 是 iptables 的“翻译官”但不是“独裁者”。它无法覆盖或删除你手动添加的 iptables 规则。因此UFW 的工作流程必须被拆解为四个明确阶段2.1 阶段一规则定义用户输入你执行的每一条ufw命令如sudo ufw allow 80/tcp或sudo ufw deny from 203.0.113.5 to any port 22都会被 UFW 解析为结构化数据存入/lib/ufw/user.rules用户自定义规则或/etc/ufw/user6.rulesIPv6 规则。这些文件是纯文本你可以用cat /lib/ufw/user.rules直接查看其内容。你会发现allow 80/tcp最终被转译为类似*filter\n:ufw-user-input - [0:0]\n-A ufw-user-input -p tcp --dport 80 -j ACCEPT\nCOMMIT的语句。这里的关键是-AAppend意味着规则被追加到链末尾而非插入到特定位置。2.2 阶段二规则编译UFW 内部处理当执行sudo ufw enable时UFW 并不会立即调用 iptables 命令。它首先读取所有配置文件/etc/ufw/ufw.conf定义全局策略/etc/ufw/before.rules定义前置规则如 ICMP、loopback/lib/ufw/user.rules是你的主规则然后按照预设的优先级顺序before → user → after将它们合并、去重、排序生成一个完整的、可执行的 iptables 脚本。这个脚本被写入/var/lib/ufw/user.rules注意路径与/lib/ufw/user.rules不同它是 UFW 实际提交给内核的“最终答卷”。2.3 阶段三内核加载iptables 执行UFW 调用系统命令iptables-restore /var/lib/ufw/user.rules将编译好的规则批量载入内核。此时iptables -L INPUT输出的内容才真正反映了 UFW 的策略效果。这也是为什么ufw status和iptables -L有时会不一致——前者显示的是 UFW “认为”自己应该做的后者显示的是内核“实际”在执行的。2.4 阶段四运行时拦截netfilter 工作当一个网络包抵达服务器网卡Linux 内核的 netfilter 框架会按预设的 hook 点如 PREROUTING、INPUT、FORWARD依次处理。对于进入本机的包它首先进入 INPUT 链。INPUT 链中的每条规则按顺序匹配如果包的目的端口是 22且来源 IP 在白名单中则ACCEPT否则继续下一条如果遍历完所有规则都没匹配则执行默认策略DENY。UFW 的limit功能如sudo ufw limit 22/tcp正是在此阶段生效它利用 iptables 的hashlimit模块在内存中维护一个计数器对同一 IP 在指定时间窗口内的连接请求数进行统计一旦超限后续请求自动被REJECT。这比简单DROP更友好因为REJECT会向客户端返回 TCP RST 包让对方立刻知道连接被拒而不是无响应等待超时这对防止慢速攻击slowloris非常关键。提示UFW 的limit并非万能。它只能限制“新连接”即 TCP SYN 包对已建立的连接ESTABLISHED无效。因此它防不住应用层的暴力破解如 SSH 密码穷举只能缓解扫描行为。真正的防护需要结合 fail2ban 这类应用层监控工具。3. 从零开始的完整配置流程每一步都对应一个真实风险点配置 UFW 不是执行几条命令就结束的流水线而是一个需要持续验证、动态调整的风险控制闭环。下面是我基于 Ubuntu 18.04 生产环境总结出的七步法每一步都直指一个常见翻车点所有命令均经过实测验证。3.1 第一步确认系统状态与基础清理避免“带病上岗”在动任何防火墙规则前必须确保系统处于一个干净、可知的状态。很多人跳过这步直接enable结果发现 SSH 断连只能重启服务器进救援模式。执行以下命令# 检查当前 UFW 状态通常为 inactive sudo ufw status verbose # 查看所有已加载的 iptables 规则重点找是否有冲突的手动规则 sudo iptables -L INPUT --line-numbers | head -20 # 检查是否已有其他防火墙服务在运行如 firewalld它们会与 UFW 冲突 sudo systemctl list-units | grep -E (firewalld|iptables) # 如果发现 firewalld 正在运行必须先禁用它否则 UFW 无法正常工作 sudo systemctl stop firewalld sudo systemctl disable firewalld这一步的核心是“清场”。Ubuntu 18.04 默认不启动 firewalld但如果你是从 CentOS 迁移过来的镜像或使用了某些一键脚本firewalld 可能残留。它和 UFW 都试图管理 iptables结果就是规则互相覆盖行为不可预测。我曾帮一个客户恢复服务根源就是firewalld在后台静默运行ufw enable后ufw status显示一切正常但iptables -L却空空如也——因为 firewalld 把 UFW 写入的规则全清掉了。3.2 第二步设置默认策略划定安全基线UFW 的默认策略是安全的起点但必须显式确认和加固。执行# 设置默认入站策略为 DENY这是最关键的一步 sudo ufw default deny incoming # 设置默认出站策略为 ALLOW保证服务器能正常更新、发邮件等 sudo ufw default allow outgoing # 设置默认转发策略为 DENY除非你明确需要做路由器或 NAT sudo ufw default deny routed这里有个极易被忽略的细节ufw default deny incoming并不会立即生效它只是修改/etc/ufw/ufw.conf中的DEFAULT_INPUT_POLICYDROP。真正的生效是在你执行ufw enable之后。但设置这一步的意义在于它为你后续添加的每一条allow规则都设定了一个“安全默认值”。想象一下如果你的服务只需要 22 和 80 端口那么即使你忘记deny其他端口UFW 的默认DENY也会替你兜底。这就像给房子装了防盗门默认 DENY再给快递员配一把专用钥匙allow 22而不是把所有窗户都敞开默认 ALLOW。3.3 第三步精准开放必要服务端口拒绝“端口全开”这是最体现专业度的环节。绝不能allow 0.0.0.0/0也不能allow 22就完事。必须遵循“最小权限原则”。以最常见的三个服务为例# 【SSH】仅允许特定 IP 段访问并启用连接频率限制防暴力破解 sudo ufw limit from 192.168.1.0/24 to any port 22 proto tcp # 【Web 服务】如果只提供 HTTP只开 80如果启用了 HTTPS则必须同时开 443 sudo ufw allow 80/tcp sudo ufw allow 443/tcp # 【Samba】这是标题中提到的高频需求但 sudo ufw allow samba 命令不存在 # 正确做法是Samba 使用多个端口必须逐一开放 sudo ufw allow from 192.168.1.0/24 to any port 137 proto udp # NetBIOS name service sudo ufw allow from 192.168.1.0/24 to any port 138 proto udp # NetBIOS datagram service sudo ufw allow from 192.168.1.0/24 to any port 139 proto tcp # NetBIOS session service sudo ufw allow from 192.168.1.0/24 to any port 445 proto tcp # SMB over TCP/IP注意sudo ufw allow samba command not found这个热搜词正源于此。UFW 没有内置的samba服务别名它只认识端口号和协议。很多教程直接写ufw allow samba导致新手执行报错还以为是命令语法错了。实际上这是对 Samba 协议栈理解不足的表现。Samba 的 137/138UDP用于名称解析和广播139/445TCP用于文件共享会话。如果只开 445旧版 Windows如 XP可能无法发现共享如果只开 139新版 WindowsWin10可能连接失败。因此生产环境必须四端口全开并严格限制来源 IP。3.4 第四步启用并验证用真实连接测试而非仅看状态执行sudo ufw enable后UFW 会提示Command may disrupt existing ssh connections. Proceed with operation (y|n)?。此时务必选择y但不要立即关闭当前 SSH 会话。保持这个会话活跃然后在另一台机器上用完全独立的网络环境如手机热点尝试连接# 在另一台机器上测试 SSH替换为你的服务器 IP ssh -p 22 useryour-server-ip # 测试 Web 服务 curl -I http://your-server-ip # 测试 Samba 发现Linux 客户端 smbclient -L //your-server-ip -U% # 关键验证尝试连接一个未开放的端口如 3306应超时或被拒绝 nc -zv your-server-ip 3306如果 SSH 连接失败不要慌。立刻回到原会话执行sudo ufw disable临时关闭防火墙然后检查sudo ufw status numbered看规则编号是否正确再用sudo iptables -L INPUT确认底层规则。永远不要在没有备用连接通道的情况下启用防火墙。我曾因网络波动导致备用连接中断ufw enable后 SSH 断开只能联系云服务商后台 VNC 进入耗时 40 分钟才恢复。3.5 第五步日志与监控让安全可见而非“黑盒”UFW 默认不开启详细日志这等于关掉了安全系统的“眼睛”。必须激活# 启用日志功能日志级别设为 low避免磁盘被撑爆 sudo ufw logging on sudo ufw logging low # 日志文件位置 # /var/log/ufw.log 主日志 # /var/log/ufw.log.1 轮转日志 # 实时监控新日志在另一个 SSH 会话中执行 sudo tail -f /var/log/ufw.log开启后当你从外部尝试连接 22 端口日志中会出现类似INeth0 OUT MAC... SRC203.0.113.5 DST192.0.2.10 LEN60 TOS0x00 PREC0x00 TTL64 ID54321 DF PROTOTCP SPT54321 DPT22 WINDOW29200 RES0x00 SYN URGP0的记录。其中SRC是攻击者 IPDPT是目标端口SYN表示连接请求。通过分析这些日志你能清晰看到谁在扫描你、扫哪些端口、频率多高。这才是安全防护的起点——看见威胁才能应对。3.6 第六步定期审计与规则更新安全是持续过程防火墙规则不是“一次配置永久有效”。随着业务变化规则必须动态更新。我建立了一个简单的月度审计清单审计项检查方法风险示例冗余规则sudo ufw status numbered检查是否有重复或已失效的allow规则为测试临时添加的allow 8080忘记删除成为潜在入口过期 IP 白名单检查from 192.168.1.0/24类规则确认该网段是否仍需访问前任员工的办公网络已变更旧 IP 段成为安全隐患服务端口变更核对当前运行的服务端口sudo ss -tuln与 UFW 允许的端口是否一致应用升级后监听 8443但 UFW 只开了 443导致服务不可用日志增长趋势sudo du -sh /var/log/ufw.log*监控日志体积日志突然暴增可能预示大规模扫描或 DDoS 攻击执行审计时删除规则用sudo ufw delete [编号]如sudo ufw delete 3比sudo ufw delete allow 22更精准避免误删其他 22 端口规则。3.7 第七步故障应急方案当一切都不工作时再完美的配置也可能出意外。必须准备“逃生舱”# 方案一临时禁用最快但最不安全 sudo ufw disable # 方案二重置为初始状态清除所有自定义规则保留默认策略 sudo ufw reset # 方案三从备份恢复最稳妥前提是你有备份 # 备份规则sudo cp /lib/ufw/user.rules /root/ufw-user.rules.backup # 恢复规则sudo cp /root/ufw-user.rules.backup /lib/ufw/user.rules sudo ufw reload # 方案四通过云平台控制台终极保障 # 如果以上都失败登录你的云服务商如 AWS EC2、阿里云 ECS控制台 # 在“安全组”或“网络 ACL”层面临时放行 22 端口获得访问权后再修复 UFW。我坚持一个原则任何防火墙配置变更必须在变更前用sudo ufw show added或sudo ufw status numbered截图保存当前状态。这张截图就是你的“后悔药”。4. 高频问题深度排错从command not found到连接超时的完整链路网络搜索热词sudo ufw allow samba command not found和linux防火墙firewall实战案例揭示了用户在实操中最常卡壳的几个点。下面我以真实排错笔记的形式还原从问题现象到根因定位的全过程。4.1 问题一sudo ufw allow samba报错 “command not found”现象描述在终端输入sudo ufw allow samba系统返回sudo: ufw: command not found或ufw: command not found。排查链路第一步确认 UFW 是否已安装Ubuntu 18.04 默认预装 UFW但极少数精简版镜像如某些 Docker 基础镜像可能未包含。执行which ufw或dpkg -l | grep ufw。如果无输出说明未安装。解决方案sudo apt update sudo apt install ufw -y。第二步确认命令拼写与语法ufw allow samba是错误的。UFW 不识别samba这个服务名。它只接受端口号、协议或/etc/services中定义的标准服务名如ssh,http,https。samba不在/etc/services中。解决方案改用端口号如sudo ufw allow 445/tcp。第三步检查 PATH 环境变量极少数情况下ufw二进制文件在/usr/sbin/ufw而当前用户的PATH未包含/usr/sbin。执行echo $PATH看是否含/usr/sbin。解决方案临时添加export PATH/usr/sbin:$PATH或直接用绝对路径/usr/sbin/ufw allow 445/tcp。注意ufw命令必须用sudo因为它需要 root 权限修改系统防火墙。单独ufw status可以不加sudo只读但allow、deny、enable等写操作必须sudo。4.2 问题二UFW 已启用但 SSH 连接超时Connection timed out现象描述sudo ufw status显示Status: active且22/tcp规则存在但从外部ssh userip时提示ssh: connect to host ip port 22: Connection timed out。排查链路这是一个经典的“多层过滤”问题必须逐层穿透排查层级检查命令预期结果异常含义L1本地网络连通性ping your-server-ip64 bytes from ...服务器宕机或网络不通L2服务器 SSH 服务状态sudo systemctl status sshactive (running)SSH 服务未启动或崩溃L3UFW 规则是否生效sudo ufw status numbered22/tcp ALLOW IN存在规则未添加或被删除L4底层 iptables 是否加载sudo iptables -L INPUT --line-numbers | grep 22显示ACCEPT规则UFW 规则未成功写入 iptablesL5云平台安全组登录云控制台查看安全组入方向规则包含TCP:22且源 IP 正确云平台防火墙拦截最常见原因根因定位在 90% 的案例中问题出在 L5——云平台安全组。UFW 是操作系统层面的防火墙而云服务商AWS、阿里云、腾讯云在虚拟机外还有一层网络防火墙安全组。如果安全组没开 22 端口UFW 再怎么配置都无济于事因为数据包根本到不了你的服务器网卡。我处理过的此类工单平均每个要花 15 分钟说服客户去控制台检查安全组因为他们坚信“ufw status 显示 active 就一定没问题”。终极验证在服务器本地用curl -v telnet://localhost:22测试。如果能连上证明 SSH 服务和 UFW 本地规则都 OK如果连不上问题在 SSH 服务本身。4.3 问题三Samba 共享在 Linux 客户端可见但在 Windows 上找不到现象描述在 Ubuntu 服务器上配置好 Samba并用sudo ufw allow开放了 137-139,445 端口Linux 客户端用smbclient -L //server能列出共享但 Windows 资源管理器中却看不到该服务器。根因分析Windows 的网络发现Network Discovery依赖 NetBIOS 名称服务NBNS它使用 UDP 137 端口进行广播和查询。UFW 默认deny incoming虽然你allow了 137/udp但UDP 广播包的来源 IP 是0.0.0.0而你的规则是from 192.168.1.0/24。UFW 无法匹配0.0.0.0到子网导致广播包被默认DENY策略拦截。解决方案必须添加一条专门针对广播的规则# 允许来自任意地址的 UDP 137 广播仅限局域网公网无需此规则 sudo ufw allow proto udp from any to any port 137同时确保 Samba 配置文件/etc/samba/smb.conf中的interfaces和bind interfaces only设置正确避免绑定到错误网卡。提示这个问题凸显了防火墙配置的“上下文敏感性”。同样的规则在不同网络拓扑纯内网 vs 混合云下效果可能截然不同。没有放之四海而皆准的“最佳实践”只有贴合你具体环境的“最适实践”。5. 超越基础UFW 的进阶技巧与生产环境加固当基础配置已稳定运行下一步是让 UFW 成为更智能、更主动的安全卫士。这些技巧并非“炫技”而是我在处理高危客户环境时沉淀下来的实战经验。5.1 技巧一基于应用层的动态端口限制解决ufw limit的局限性UFW 的limit只能限制新连接速率对已建立连接内的恶意行为如 HTTP Flood无能为力。但我们可以利用 UFW 的before.rules文件在 iptables 的最前端插入更精细的规则。例如防止针对 Web 服务的慢速攻击slowloris# 编辑 before.rules在 *filter 和 :ufw-before-input 的定义之间插入以下内容 sudo nano /etc/ufw/before.rules # 在文件末尾的 COMMIT 之前添加 # Limit new HTTP connections per IP -A ufw-before-input -p tcp --dport 80 -m state --state NEW -m hashlimit --hashlimit-above 50/sec --hashlimit-burst 100 --hashlimit-mode srcip --hashlimit-name http -j DROP -A ufw-before-input -p tcp --dport 443 -m state --state NEW -m hashlimit --hashlimit-above 50/sec --hashlimit-burst 100 --hashlimit-mode srcip --hashlimit-name https -j DROP这段规则的意思是对每个源 IP每秒最多允许 50 个新的 HTTP/HTTPS 连接请求如果瞬间超过 100 个burst后续请求直接DROP。hashlimit模块比limit更强大它能基于源 IP 维护独立计数器避免一个恶意 IP 影响其他正常用户。修改后必须执行sudo ufw reload使新规则生效。5.2 技巧二IP 地址黑名单的自动化管理告别手动deny手动sudo ufw deny from x.x.x.x效率低下且无法持久化。更好的方式是结合fail2ban。Fail2ban 是一个守护进程它实时监控/var/log/auth.log一旦发现某个 IP 在 10 分钟内失败登录超过 5 次就自动调用ufw命令将其加入黑名单。配置步骤如下# 安装 fail2ban sudo apt install fail2ban -y # 创建 jail.local 配置文件 sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local sudo nano /etc/fail2ban/jail.local # 在 [sshd] 段落中取消注释并修改 [sshd] enabled true filter sshd logpath /var/log/auth.log maxretry 5 bantime 3600 # 关键指定 action 为 ufw action ufw[actiontypeban]重启服务sudo systemctl restart fail2ban。此后所有被 fail2ban 封禁的 IP会自动出现在sudo ufw status numbered的列表中且带有DENY标签。这实现了从“被动防御”到“主动封禁”的跃迁。5.3 技巧三规则版本控制与团队协作避免“配置地狱”在团队环境中多人修改 UFW 规则极易导致混乱。我的做法是将 UFW 配置纳入 Git 版本控制# 创建配置仓库 mkdir ~/ufw-config cd ~/ufw-config git init # 将所有关键配置文件软链接到仓库 ln -sf /etc/ufw/ufw.conf . ln -sf /etc/ufw/before.rules . ln -sf /etc/ufw/after.rules . ln -sf /lib/ufw/user.rules . # 提交初始版本 git add . git commit -m Initial UFW config for prod server每次修改规则前先git pull获取最新配置修改后git add . git commit -m Allow port 8080 for new app最后git push。这样每一次变更都有迹可循回滚只需git checkout HEAD~1并sudo ufw reload。这不仅是技术实践更是工程规范。5.4 技巧四性能监控与瓶颈识别UFW 会影响服务器性能吗这是个普遍担忧。答案是在绝大多数场景下UFW即 iptables的性能开销可以忽略不计。Linux 内核对 netfilter 的优化极为成熟单核处理数万 PPS包每秒毫无压力。但有两个例外规则数量爆炸如果你添加了上千条ufw allow from x.x.x.x规则iptables 的线性匹配会变慢。此时应改用ipset将 IP 列表预编译为哈希表。日志级别过高ufw logging high会为每个被拒绝的包写日志磁盘 I/O 成为瓶颈。监控方法# 查看 UFW 相关的 iptables 规则数量 sudo iptables -L INPUT | wc -l # 监控日志写入速率每秒多少行 sudo tail -f /var/log/ufw.log | pv -lr /dev/null # 检查 CPU 在 netfilter 上的占用需安装 sysstat sudo sar -n ALL 1 10 | grep -A5 ip在我的生产集群中单台服务器承载 200 条 UFW 规则CPU 在 netfilter 上的占用常年低于 0.1%远低于 Nginx 或数据库的开销。6. 个人经验总结那些文档里不会写的“血泪教训”最后分享几个我在 Ubuntu 18.04 上配置 UFW 时用真金白银和无数个深夜换来的体会。它们没有技术术语但句句都是踩坑后的顿悟。第一个教训永远不要在ufw enable后立刻关闭 SSH 会话。我曾因一个ufw allow 22拼写成ufw allow 222导致自己被锁在服务器外。后来我养成了一个铁律ufw enable后保持原会话至少 5 分钟并在另一台设备上完成所有服务的连通性测试。这 5 分钟是留给“万一”的缓冲带。第二个教训ufw status是个“谎言制造者”。它只显示 UFW 自己管理的规则对iptables -I INPUT -j DROP这样的手动规则视而不见。有一次客户服务器的网站打不开ufw status显示一切正常我花了 2 小时排查最后发现是前任运维在before.rules里加了一条DROP规则但忘了注释。从此我的标准动作是ufw status之后必跟iptables -L INPUT双保险。第三个教训Samba 的端口开放是一场与 Windows 版本的博弈。Win7 及更早版本重度依赖 137-139Win10 则主推 445。如果你的用户群体混杂就必须四端口全开。但全开意味着更大的攻击面。我的妥协方案是在ufw allow规则中对 137-139 使用proto udp对 139/445 使用proto tcp并严格限定from子网。UDP 端口无法被 TCP 连接利用这本身就是一层隔离。第
