服务器默认端口为何容易被扫描？建站如何用防火墙和密钥加固

服务器默认端口容易被扫描，根本原因不是端口号本身存在漏洞，而是标准端口具有明确的服务指向：22 通常对应 SSH，80 和 443 对应 Web 服务，3306 常见于数据库。自动化扫描器可以批量探测公网地址的这些端口，再根据响应特征识别服务版本并尝试弱口令、已知漏洞或配置错误。只要服务器拥有公网地址、服务正在监听，且入站策略允许访问，就可能被发现。

建站加固应优先采用“减少暴露面、限制来源、密钥认证、最小权限、及时补丁、持续审计”的组合方式。单纯把 SSH 从 22 改到其他端口，只能减少低质量扫描和日志噪声，不能替代防火墙与强认证。下面以 Ubuntu/Debian、OpenSSH 和 UFW 为例，按照先检查、再配置、每步验证、最后回滚的顺序操作。

默认端口为什么容易被扫描

扫描器关注的是服务入口，而不是端口数字

公网扫描通常会批量探测常见端口，也可能进行全端口扫描。端口处于 open 状态时，说明有程序接受连接；如果服务返回协议版本、加密协商信息或错误提示，扫描器还可以进一步判断服务类型。

端口状态通常可以这样理解：

“端口开放”不等于“服务器已经被入侵”，但它意味着攻击者有了继续识别和尝试的入口。相反，“端口改成高位端口”也不等于安全，因为有针对全端口范围的扫描。

端口加固的判断条件

一个端口是否应该保留，至少要同时回答三个问题：

1. 该服务是否是建站所必需的？
2. 是否必须从公网访问，还是只需要本机或内网访问？
3. 访问者是否可以被限制到固定管理地址、业务网段或指定用户？

常见的收敛目标如下：

操作前的准备与基线检查

以下操作针对 Linux 服务器。开始前应准备一个可用的云控制台、串口或救援入口，避免防火墙或 SSH 配置错误后完全失去远程访问能力。

同时准备以下条件：

• 当前账号具有 sudo 权限；
• 保留当前 SSH 会话，并准备第二个终端用于测试；
• 知道管理人员的公网出口 IP 或网段；
• 已确认网站需要的端口，不能只凭默认值操作；
• 已备份 SSH 配置，并记录当前防火墙规则；
• 防火墙调整前确认云平台安全组或上游边界策略不会产生冲突。

先检查系统、SSH 服务和监听端口：

id
sudo -v
sudo ss -lntup
sudo ufw status verbose
sudo systemctl is-active ssh

Ubuntu/Debian 通常使用 ssh 服务名。如果 systemctl is-active ssh 返回服务不存在，应先核验实际服务名，不要直接猜测：

systemctl list-unit-files | grep -E 'ssh|sshd'

重点观察 ss -lntup 的监听地址：

• 127.0.0.1:端口 或 [::1]:端口：通常只接受本机连接；
• 0.0.0.0:端口 或 [::]:端口：可能接受所有 IPv4 或 IPv6 地址的连接；
• 监听地址不是公网可达的充分条件，仍需结合主机防火墙、云安全组和外部测试判断。

先备份 SSH 主配置并记录 UFW 状态。以下命令不会修改服务配置：

sudo cp -a /etc/ssh/sshd_config "/etc/ssh/sshd_config.bak.$(date +%F-%H%M%S)"
sudo ufw status numbered | sudo tee "/root/ufw-before-$(date +%F-%H%M%S).txt"

第一步：先减少不必要的监听服务

防火墙可以限制网络访问，但如果服务本身不再使用，停止服务并删除开机启动更容易维护。先从 ss 输出中确认进程，再结合业务判断，不能根据端口号直接关闭未知服务。

例如发现某个 Web 建站并不需要本机数据库对外监听，应让数据库只绑定本机地址或内网地址，并在防火墙中拒绝公网访问。配置服务监听地址前，应先查看对应服务的实际配置文件和运行方式。

每次调整后重新检查：

sudo ss -lntup
sudo systemctl --failed

成功标准是：只剩网站访问和确有必要的管理入口，数据库、缓存、调试接口等不再直接暴露到公网。若关闭服务导致网站异常，应先恢复服务，再根据进程、日志和业务依赖重新判断，而不是连续关闭多个端口。

第二步：使用密钥登录并收紧 SSH 认证

创建非 root 管理账号

如果目前只能使用 root 登录，先创建一个日常管理账号，并赋予必要的 sudo 权限：

sudo adduser adminops
sudo usermod -aG sudo adminops

adminops 只是示例名称，应替换为实际管理账号。应用运行账号、部署账号和系统管理员账号应尽量分开，网站进程不应使用 root 身份运行，也不应让普通应用账号拥有 sudo 权限。

在管理终端生成密钥

在自己的管理电脑上执行，而不是在服务器上执行：

ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519_a5

建议为私钥设置口令。私钥只保存在管理终端，不要上传到网站目录、代码仓库或服务器公共目录。

首次复制公钥时，可以使用当前可用的密码登录：

ssh-copy-id -i ~/.ssh/id_ed25519_a5.pub adminops@SERVER_IP

将 SERVER_IP 替换为服务器地址。复制完成后，必须打开第二个终端验证密钥登录：

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_a5 adminops@SERVER_IP

验证成功后，可以在服务器上检查权限：

sudo ls -ld /home/adminops /home/adminops/.ssh
sudo ls -l /home/adminops/.ssh/authorized_keys

如果出现权限错误，可在确认路径和账号无误后修正：

sudo install -d -m 700 -o adminops -g adminops /home/adminops/.ssh
sudo chown adminops:adminops /home/adminops/.ssh/authorized_keys
sudo chmod 600 /home/adminops/.ssh/authorized_keys

关闭密码登录和 root 远程登录

确认新会话可以使用密钥登录后，再创建 SSH 加固配置。Ubuntu/Debian 的 OpenSSH 通常支持配置目录：

sudo tee /etc/ssh/sshd_config.d/99-hardening.conf > /dev/null <<'EOF'
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
EOF

如果服务器还需要其他管理员登录，不要直接加入 AllowUsers adminops，否则可能把其他合法账号一并阻断。需要限制账号时，应列出全部必要账号，例如：

AllowUsers adminops deployops

先检查配置语法，再重新加载服务：

sudo sshd -t
sudo systemctl reload ssh

sshd -t 没有输出且退出码为 0，通常表示语法检查通过。随后使用第二个终端再次验证：

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_a5 adminops@SERVER_IP

确认密钥登录仍然正常后，再检查实际生效参数：

sudo sshd -T | grep -E '(pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|permitrootlogin)'

预期结果应接近：

pubkeyauthentication yes
passwordauthentication no
kbdinteractiveauthentication no
permitrootlogin no

如果密钥登录失败，不要关闭当前已登录会话。常见原因包括公钥复制到了错误用户、.ssh 权限过宽、私钥没有被客户端使用，或 AllowUsers 漏掉了账号。客户端可临时使用详细模式定位：

ssh -vv -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_a5 adminops@SERVER_IP

输出中只应关注认证流程，不要把包含敏感路径、账号或密钥信息的完整日志公开发布。

第三步：配置主机防火墙

以下以 UFW 为例。已经使用 firewalld、nftables 或云平台安全组的服务器，不要为了照抄命令而同时启用多套规则，应先确定当前实际生效的防火墙层。

先允许必要访问，再收紧默认策略

如果管理来源固定，例如办公出口地址为 203.0.113.10，可以只允许该地址访问 SSH。这个地址属于文档示例网段，不能直接当作真实管理地址使用。

在确认网站端口和 SSH 端口后执行：

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
sudo ufw status verbose

防火墙调整的影响范围是所有入站连接。若网站还依赖其他端口，应先加入对应的、范围尽量小的规则；不要一开始就执行全量拒绝，再靠猜测恢复业务。

如果管理人员的公网地址经常变化，固定来源规则可能导致自己无法登录。此时可以暂时使用：

sudo ufw limit 22/tcp

limit 只能降低短时间重复连接的影响，不能代替密钥认证和来源限制。管理入口最好仍通过固定出口、管理网段或专用跳板入口访问。

验证当前规则：

sudo ufw status numbered
sudo ss -lntup

如果云平台还配置了外层安全组，必须同时检查两层策略：外层允许而主机拒绝时，外部表现为不可达；主机允许而外层拒绝时，外部同样无法连接。最终应以授权的外部网络测试结果为准。

是否需要修改 SSH 端口

将 SSH 从 22 改为 22222 等非标准端口，可以减少针对 22 端口的低质量扫描，但不能阻止有针对性的端口探测。只有在密钥认证、防火墙和补丁已经完成后，才适合把它作为降低噪声的补充措施。

修改前先查找所有现有 Port 配置：

sudo grep -RinE '^[[:space:]]*Port[[:space:]]+' /etc/ssh/sshd_config /etc/ssh/sshd_config.d 2>/dev/null

OpenSSH 可能同时读取主配置和配置目录。如果简单地在新文件中追加一个 Port 22222，可能造成 22 和 22222 同时监听。因此应明确决定是否保留旧端口，并保证最终配置符合预期。

操作顺序应为：

1. 先在 UFW 和云平台安全组中放行新端口；
2. 修改 SSH 配置中的有效 Port，例如改为 22222；
3. 执行 sudo sshd -t 检查语法；
4. 使用 sudo systemctl reload ssh 重新加载；
5. 在第二个终端测试新端口；
6. 外部验证成功后，再删除旧端口的防火墙放行规则。

示例测试命令如下：

ssh -p 22222 -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_a5 adminops@SERVER_IP

确认新端口可用后，才考虑删除旧端口规则：

sudo ufw delete allow 22/tcp
sudo ufw status numbered

如果旧规则原本带有来源限制，删除时应按照 ufw status numbered 显示的实际规则操作，不要凭记忆输入。

第四步：补丁与最小权限同步落实

端口和认证只能降低入口风险，不能修复 SSH、Web 服务或系统内核自身的漏洞。Ubuntu/Debian 可以在维护窗口执行：

sudo apt update
sudo apt upgrade

升级可能重启服务，也可能要求重启系统。完成后检查失败服务和当前内核：

sudo systemctl --failed
uname -r
sudo journalctl -p warning..alert -b --no-pager

如果升级涉及内核或关键系统库，应安排维护时间重启，并在重启前确认：

• 新 SSH 账号和密钥已经验证；
• 网站文件、配置和数据库有可恢复备份；
• 云控制台或救援入口可用；
• 回滚需要的旧配置仍然保留。

最小权限还包括以下边界：

• 日常管理使用普通账号加 sudo，不直接使用 root 工作；
• 网站运行账号不加入 sudo 组；
• 数据库只监听本机或必要的内网地址；
• 不使用的调试接口、临时管理面板和测试服务应停止；
• 部署密钥、管理员密钥和应用程序密钥分开管理。

第五步：从外部验证暴露面与日志

本机的 ss 只能说明进程是否监听，不能证明互联网用户能否访问。应从授权的外部网络执行有限端口测试，例如在另一台管理主机上使用 Nmap：

nmap -Pn -p 22,80,443,22222 SERVER_IP

不要扫描不属于自己的地址或未获授权的网络。结果判断如下：

• 80/tcp open、443/tcp open：网站端口按预期开放；
• SSH 只有新端口为 open：旧端口应已收敛；
• 管理端口显示 filtered：可能被防火墙拦截，需要确认是否误伤合法管理来源；
• 未使用端口仍为 open：回到 ss -lntup 查找监听进程和对应规则；
• 显示 closed：主机可达但没有服务监听，通常比意外开放更符合预期。

还应检查 SSH 和防火墙日志：

sudo journalctl -u ssh --since "24 hours ago" --no-pager
sudo journalctl -k --since "24 hours ago" --no-pager | grep -i ufw
sudo last -a | head -n 20

如果启用了 UFW 日志，可以在确认日志量可接受后设置中等级别：

sudo ufw logging medium

日志审计重点不是追求零扫描，而是识别异常趋势：

• 是否存在大量 Failed password 或 Invalid user；
• 是否有不熟悉的成功登录来源；
• 是否在修改端口后仍有旧端口连接尝试；
• 是否出现防火墙规则频繁变化；
• 是否有与维护时间不符的服务重启或账号变更。

发现异常成功登录时，应立即保留日志、检查登录账号和进程，再通过控制台或已验证的管理会话轮换密钥，而不是直接删除日志或重启服务器。

常见失败处理

启用防火墙后无法连接

保留的 SSH 会话可能仍然可用。先在当前会话检查：

sudo ufw status numbered
sudo ss -lntup

如果没有可用会话，通过云控制台进入系统，确认：

• SSH 实际监听端口；
• 管理来源 IP 是否变化；
• UFW 是否放行正确端口；
• 云安全组是否同时允许该端口；
• IPv6 是否存在另一套暴露面。

紧急恢复时，可以在控制台临时放行管理地址，而不是长期关闭防火墙：

sudo ufw allow from 203.0.113.10 to any port 22222 proto tcp

sshd -t 检查失败

不要 reload 一个语法错误的配置。先查看具体错误行：

sudo sshd -t

如果刚创建的加固文件导致错误，可以先将其移出配置目录。以下命令只适用于确认该文件由本次操作创建且需要回滚的情况：

sudo mv /etc/ssh/sshd_config.d/99-hardening.conf \
  /etc/ssh/sshd_config.d/99-hardening.conf.disabled
sudo sshd -t
sudo systemctl reload ssh

密钥有效但仍提示认证失败

按由低风险到高风险的顺序检查：

1. 客户端是否使用了正确的私钥；
2. 登录用户名是否正确；
3. authorized_keys 是否属于目标用户；
4. .ssh 和 authorized_keys 权限是否过宽；
5. AllowUsers 是否遗漏账号；
6. sshd -T 中的认证参数是否与预期一致；
7. 查看 journalctl -u ssh 获取服务端拒绝原因。

不要为了快速恢复而长期重新启用 root 密码登录。如果必须临时恢复，应限制来源、完成测试后立即恢复密钥策略。

验收与回滚检查项

完成加固后，可按以下清单验收：

• [ ] ss -lntup 中只存在业务需要的监听服务；
• [ ] 网站所需的 80/443 访问正常；
• [ ] SSH 可使用密钥登录；
• [ ] root 远程登录已关闭；
• [ ] 密码和交互式认证已按计划关闭；
• [ ] 管理端口只对必要来源开放，或至少启用了连接限制；
• [ ] 数据库和内部服务未暴露到公网；
• [ ] 从授权外部网络完成端口验证；
• [ ] SSH、防火墙和系统日志可以正常查询；
• [ ] 系统补丁已更新，失败服务列表为空或已确认；
• [ ] 配置备份、网站备份和控制台入口均可用。

需要回滚时，优先使用控制台或仍保持的 SSH 会话，按照以下顺序处理：

1. 将最近新增的 SSH 配置文件移出配置目录，或恢复修改前的备份；
2. 执行 sudo sshd -t，确认语法正常后再 reload；
3. 临时恢复原 SSH 端口的受限防火墙规则；
4. 从已保存的 UFW 规则记录核对并修正入站策略；
5. 验证管理登录和网站访问；
6. 记录失败原因，修正配置后再分阶段重新加固。

这样处理后，端口变更只是防护的一层，真正承担安全作用的是可控的暴露面、密钥认证、最小权限、及时补丁和持续审计。