这篇文章描述了一个SSH暴力破解的应急场景，以及对应的分析和排查方法。最后提出了一些处理措施，如限制管理IP地址、加强口令安全审计、更改SSH默认端口和部署入侵检测设备等。
应急场景
网站管理员登录服务器进行巡检时，发现端口连接里存在两条可疑的连接记录
netstat -anplt | grep 22(显示22号端口有两条连接再
SYN_RECV状态）SSH协议的连接建立过程
- 协议握手：
- 客户端和服务器通过TCP连接建立通信。在握手过程中，它们会协商使用的SSH协议版本、加密算法、消息认证码（MAC）算法等参数。
- 密钥交换：
- 客户端和服务器通过密钥交换算法（如Diffie-Hellman）协商一个共享密钥。这个密钥将用于整个会话的加密和解密。由于密钥交换算法的特性，即使中间人监听了通信过程，也无法获取到共享密钥。
- 服务器认证：
- 在这一步，服务器会向客户端提供它的公钥。客户端需要验证服务器公钥的有效性。这通常通过在客户端预先存储服务器公钥的指纹（fingerprint）来实现。如果客户端没有预存服务器公钥的指纹，可能会提示用户验证。如果验证成功，客户端会生成一个随机数（通常称为会话密钥），用服务器的公钥加密，并发送给服务器。服务器使用自己的私钥解密，获取会话密钥。
- 用户认证：客户端需要向服务器证明自己的身份。有以下几种常见的认证方法：
- 密码认证：客户端发送加密后的用户密码给服务器，服务器验证密码是否正确。
- 公钥认证：客户端使用自己的私钥对一个特定的数据进行签名（数字签名），并将签名和公钥发送给服务器。服务器使用客户端的公钥验证签名，如果验证成功，则认为客户端具有相应私钥的所有权，从而完成认证。
- 会话建立：
- 完成以上步骤后，客户端和服务器之间的SSH连接建立成功。接下来，双方可以通过加密通道进行安全的数据传输和远程命令执行。
分析
- TCP 初始化连接三次握手：C发
SYN包，然后S返回SYN/ACK包，C再发ACK包，连接正式建立。但是这里有点出入，当请求者C收到SYS/ACK包后，就开始建立连接了，而被请求者第三次握手结束后才建立连接。
- 客户端 TCP 状态迁移：
CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED
- 服务器 TCP 状态迁移：
CLOSED->LISTEN->SYN_RECV->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED
- 当客户端开始连接时，服务器还处于
LISTENING，客户端发一个SYN包后，服务端接收到了客户端的SYN并且发送了ACK时，服务器处于SYN_RECV状态，然后并没有再次收到客户端的ACK进入ESTABLISHED状态，一直停留在SYN_RECV状态。
在这里，SSH（22）端口，两条外网 IP 的
SYN_RECV 状态连接，直觉告诉了管理员，这里一定有什么异常。排查：
- 除 root 之外，是否还有其它特权用户 (uid 为 0)（
/etc/passwd）
- 可以远程登录的帐号信息（
/etc/shadow）
- 统计了下
/var/log/secure日志，发现大约有 126254 次登录失败的记录，确认服务器遭受暴力破解
- 输出登录爆破的第一行和最后一行，确认爆破时间范围（用
head -1和tail -1）
- 进一步定位有哪些 IP 在爆破？
- 爆破用户名字典都有哪些？
- 管理员最近登录情况（登录成功的日期、用户名、IP）
处理措施：
- 禁止向公网开放管理端口，若必须开放应限定管理 IP 地址并加强口令安全审计（口令长度不低于 8 位，由数字、大小写字母、特殊字符等至少两种以上组合构成）。
- 更改服务器 ssh 默认端口。
- 部署入侵检测设备，增强安全防护。