TG在线咨询服务器暴露在公网后，弱口令、未修补的软件漏洞和不必要的开放端口都可能增加入侵风险。做好服务器安全加固常见设置，不需要一次部署复杂平台；先收紧入口，再控制权限、保持更新并确认能够追踪和恢复。
以下步骤适用于常见 Linux 服务器。不同发行版的服务名称和命令可能略有差异，远程操作前应保留当前管理会话，并确认有控制台或其他恢复方式。
一、先收紧登录入口
1. 使用密钥登录并限制特权账号
为管理员配置 SSH密钥登录，确认密钥可用后，再考虑关闭密码认证。编辑 /etc/ssh/sshd_config，检查 PermitRootLogin 和 PasswordAuthentication 配置；一般可将前者设为 no，并在验证密钥登录成功后将后者设为 no。先用 sshd -t 检查配置，再按系统服务名称重载 SSH 服务，并用新终端测试登录。不要在尚未验证前关闭当前会话，以免配置错误导致无法远程管理。
二、减少已知漏洞和暴露面
2. 建立稳定的系统更新流程
及时安装安全更新，尤其关注操作系统、SSH 服务、Web 服务及实际运行的软件组件。Debian、Ubuntu 常用 apt 更新工具，Fedora、RHEL 系发行版常用 dnf；具体命令和重启要求以系统版本为准。可安排固定维护窗口，更新前确认备份可用，更新后检查服务状态和应用日志。需要重启的内核更新应安排在业务允许的时间执行。
3. 用防火墙限制网络入口
按服务清单开放端口，只允许确实需要的来源访问管理服务。使用 UFW 时，先添加 SSH 允许规则，再启用防火墙；使用 firewalld 的系统则先确认对应区域和规则。网站服务器通常只需开放实际提供服务的端口，数据库管理端口不应因方便而直接对所有公网地址开放。规则调整后，从外部网络检查预期服务是否可达，同时确认管理入口没有被误封。
三、控制账号权限与异常尝试
4. 执行最小权限原则
日常运行服务尽量使用独立的普通账号，不让应用进程长期以 root 身份运行。检查文件和目录的所有者、读写权限，以及 sudo 授权范围；只给维护人员完成工作所需的权限。逐项核对正在运行的服务，停用确认不需要的服务和监听端口。权限收紧后要验证应用能否正常读写所需文件，避免用全员可写权限掩盖配置问题。
5. 降低密码猜测和重复登录风险
优先采用密钥认证，并为不同管理人员分配独立账号，便于撤销单个账号权限。对仍需密码登录的服务，可使用 fail2ban 等工具根据日志对重复失败的来源临时封禁；封禁阈值应结合正常登录失败情况设置，避免误伤共享出口地址。启用前检查日志路径、服务名称和白名单，之后观察封禁记录并保留人工解封方法。
四、确保事件可追查、可恢复
6. 检查日志与备份是否真正可用
确认系统认证日志、服务日志和防火墙记录持续写入，并限制普通用户修改日志的权限。日志保留周期要结合磁盘容量和审计需要设定；配置轮转，避免日志占满磁盘。重要配置和业务数据应定期备份到与服务器分离的位置，并限制备份访问权限。备份完成不等于能够恢复，需在隔离环境中抽查恢复过程，并记录恢复所需的账号、步骤和依赖。
实施顺序与复核
- 盘点账号、服务和当前开放端口，保存现有配置。
- 先验证密钥登录和恢复通道，再调整 SSH 与防火墙。
- 更新系统，收紧服务账号权限，并配置失败登录防护。
- 检查日志是否持续生成，按计划测试备份恢复。
- 每次变更后复核登录、业务访问和监听端口，记录变更时间及回退办法。
这六项服务器安全加固常见设置能够覆盖不少基础风险，但不能替代应用自身的安全检查。根据实际服务定期复核账号、端口、更新状态和恢复能力，才能让加固措施持续有效。
常见问题
关闭 SSH 密码登录后忘记私钥怎么办？
应在切换前准备可用的第二把密钥或云平台、机房提供的控制台恢复方式。无法确认恢复路径时，不要直接关闭密码认证。
服务器只用于内部网络，也需要防火墙吗？
需要。内部网络并不等于所有来源都可信，防火墙可限制可访问的网段和端口，减少误配置或其他设备受影响时的暴露面。
安装 fail2ban 就能防止所有入侵吗？
不能。它主要针对日志中可识别的重复失败尝试，不能替代密钥认证、系统更新、权限控制和漏洞修复。