服务端口监听地址绑定是安全第一道闸门，必须禁用0.0.0.0默认监听，数据库/缓存/ssh等一律绑定内网或回环ip（如192.168.10.5或127.0.0.1），web服务按需指定公网ip，改配后须重启服务并用ss -tlnp验证生效，再配合防火墙、访问控制、非root运行等措施形成纵深防御。
服务端口监听地址绑定不是“开了就能用”的配置，而是安全防线的第一道闸门。绑错地址，等于把数据库、缓存、管理后台直接推到公网扫描器面前；绑对了，哪怕不改密码、不设防火墙，也能拦下90%以上的无差别攻击。
只绑必需的IP，拒绝0.0.0.0裸奔
默认监听 0.0.0.0 是多数服务的“懒人模式”，意味着所有网卡、所有IP都接受连接——包括你根本没打算开放的公网IP。这不是便利，是风险敞口。
- 数据库（MySQL/PostgreSQL/Redis）一律绑定内网IP，例如
bind-address = 192.168.10.5或listen_addresses = '192.168.10.5' - Web服务若仅供内网访问，就写死
listen 192.168.10.5:80，别留listen 80这种通配写法 - 确需公网访问的服务（如Nginx前端），也应明确指定公网IP，而非
0.0.0.0，方便后续配合防火墙做精准控制
SSH管理面必须收缩监听范围
SSH是服务器命脉，但也是攻击者最常盯上的入口。不限制监听地址，等于在每张网卡上都开了一扇没锁的门。
- 编辑
/etc/ssh/sshd_config，添加或修改ListenAddress行，例如：ListenAddress 192.168.10.5（内网运维IP）ListenAddress 127.0.0.1（仅本地跳板机登录） - 多网卡环境可写多行，支持IPv4和IPv6混配，但禁止出现
ListenAddress 0.0.0.0 - 改完务必执行
sshd -t校验语法，再systemctl restart sshd，并用ss -tlnp | grep :22确认只监听目标地址
验证监听是否真正生效
配置写了≠生效了。很多加固失败，是因为改了配置却没重启服务，或重启后被旧进程残留干扰。
- 用
ss -tlnp查监听列表，重点过滤非127.0.0.1的行，确认端口绑定的是你指定的IP，不是*:端口 - 从不同网络发起测试：用内网机器连内网IP，用公网机器尝试连公网IP，用另一台内网机器尝试连错误IP——该通的通，该拒的拒
- 云服务器用户额外检查安全组/NACL规则，确保放行的是“指定IP+端口”，而非整个子网或0.0.0.0/0
配套动作不能少：绑定只是起点
单靠绑定IP无法构成完整防护，必须和其它措施联动才有效。
- 数据库加访问控制：MySQL用
GRANT ... ON *.* TO 'user'@'192.168.10.%'，限制来源IP段 - Redis禁用高危命令：
rename-command FLUSHALL ""、rename-command KEYS "" - 所有服务启用非root用户运行，避免进程提权后直接接管系统
- 日志集中采集+fail2ban联动，对异常连接自动封禁源IP
