端口开放被人连接：到底谁在连你

一台机器只要挂到公网上，就一定会有人来敲门。不是会不会的问题，是什么时候的问题。所以端口开放被人连接这件事，本身属于公网的日常噪音，多数时候是被扫描，不是被入侵。麻烦的地方在于，你从面板上看到一条条外网连进来的记录，根本分不清对面是扫描器、是爬虫、还是真有人在试你的密码。分不清就会瞎封，封完发现业务挂了，再回头一条条放行，白折腾一晚上。

扫描和登录，完全是两码事

扫描的行为很浅，三次握手建立完就走，或者发一个畸形包等回应，目的只是确认这个端口通不通。22 端口暴露在公网上，一天被敲几十上百次都不稀奇，属于常态。真登录就不一样了，握手之后有协议交互，SSH 会走密钥交换，MySQL 会走认证握手。所以看日志别只看“有连接”，要看“有没有走完认证”。/var/log/secure（Debian 系是 /var/log/auth.log）里那种 Failed password 刷屏的，才是真在试密码；而 connection closed by remote host 之后什么也没有的，大概率只是路过扫了一下。

端口开放被人连接之后，先看清是谁在连

别急着上防火墙，先看现场。ss -tunp 比 netstat 快，能看到 ESTABLISHED 状态和对应进程；想按老习惯来就 netstat -anp | grep ESTABLISHED。重点看 Foreign Address 那一列，以及它对应的进程名。如果连上来的是 sshd、mysqld 这种带认证的服务，说明对方已经走到认证环节了；如果压根没有进程对应，那可能是 TIME_WAIT 的残留连接，看着吓人其实没人在说话。再配 who、last、lastb 三个命令看登录历史，lastb 专门记失败登录。IP 归属地可以查，但别当判据——代理和云主机遍地都是，境外 IP 不等于坏人，国内 IP 也不等于自己人。

连上来的，差不多一半是你自己人

这个坑我踩过。盯着一串陌生 IP 在连 443，紧张半天准备拉黑，最后发现是 CDN 回源节点。类似的情况还有：云厂商的健康检查探针、你自己装的监控 agent、定时备份脚本、搜索引擎爬虫、各种 uptime 检测服务。判断方法笨但有效：把可疑 IP 反查一遍 PTR 记录，看它连的是哪个端口，连上来之后做了什么动作。云厂商的探针一般有固定网段，官方文档里能查到，具体以服务商页面说明为准。反查这一步别省，省了就是自己打自己。

真正要命的是监听地址写成了 0.0.0.0

很多这类事故的根子不在防火墙，在服务配置。Redis 默认 bind 127.0.0.1，有人图省事改成 0.0.0.0；MySQL 的 bind-address 同理；Elasticsearch 的 9200、Docker 的 2375、Memcached 的 11211，这几个本身认证弱甚至干脆没有认证，一旦监听在全网卡上，等于门开着还贴了张纸条告诉别人进。ss -lntp 看一眼 LISTEN 那一列，凡是 0.0.0.0: 或者 *: 开头的，逐个问自己一句“这个真的需要对外吗”。改配置文件比堆防火墙规则更彻底，而且不会在下次换机器时忘掉。

三层关卡，别只开一层就放心

云上的机器其实有三层可以拦：安全组管网络层，系统防火墙（firewalld、ufw 或者 iptables）管主机层，服务自身的账号认证管应用层。常见的误区是“我配了安全组就没事了”。安全组管的是外部进来，管不了机器内部的横向移动；系统防火墙管主机，但如果服务监听 0.0.0.0 而规则写漏了一条，照样漏；认证层最容易被弱口令一击穿透。这三层里任意两层到位，风险就降下来一大截；三层全用默认值，那只能靠运气。

换端口不等于安全，只是少点噪音

把 22 改成 22222 这种做法，能挡掉一大批无差别扫描，日志会清爽很多，但这是降噪，不是防护。真正的措施是禁掉密码登录、只留密钥、普通账号走 sudo 提权，再上个 fail2ban 之类按失败次数自动封禁的工具。fail2ban 的阈值别设太狠，见过设得过于激进，自己 VPN 一掉线把自己也关在门外的。改完记得先开一个新终端验证能登上，再关旧会话，这条是老规矩了。

拿不准就抓包，别靠猜

怀疑某个端口有外网流量，直接抓：tcpdump -i eth0 -nn port 6379，跑几分钟看看有没有非内网来源。只看新连接的话加过滤条件 tcp[tcpflags] & tcp-syn != 0。抓到之后看包的大小和频率，扫描通常是高频小包、目的端口一大串轮着来；正常业务是有来有回、有载荷的。抓包别开着不管，磁盘容易被写满，加个 -c 限制包数，看完就停。

一套能照着走的排查顺序

第一，ss -lntp 列出所有监听，把 0.0.0.0 的全标出来；第二，ss -tunp 看当前已建立的连接和对应进程；第三，翻 auth.log 或 secure 里的失败登录记录；第四，把可疑 IP 反查一遍，对照自家已知的探针、CDN 回源和监控；第五，确认多余的端口后，先改服务监听地址，再补安全组规则，最后重启服务验证；第六，改完盯一两天日志，确认没有回退也没把正常业务误伤。顺序别倒，先动防火墙再改配置，很容易改到一半自己进不去。

端口开放被人连接不可怕，可怕的是不知道连上来的是谁，也不知道自己究竟开了什么。每周花十分钟扫一眼监听列表和失败登录，比出事之后再救火划算得多。要一个标准的话就这句：对外只留必须的，对内全部收窄，认证能强就别图省事。