服务器遭遇 HTTPS 构造攻击，被恶心坏了。

[tool2d]

最近服务器日志老是 SSL 报警，我好奇抓了一下 tcpdump 包，一看好家伙，完全是针对源代码漏洞的恶意构造攻击。

这种攻击和普通 php 网页漏洞还不一样，是针对 OPENSSL 底层精心构造过的攻击。一般很少人会去动底层代码，一不小心就中招了，真是防不胜防。

给一个截图，里面有 ClientHello 构造证据。我就没见过一个正常 ClientHello ，内容全部是 01 组成的数据。

[salmon5]

没碰到过，有什么影响吗？另外我看服务器是 114.114.114.114 ，有点诡异。

[tool2d]

@salmon5 为了发帖图，我把自己的 ip 模糊化处理了，替换成了 114 。对于攻击者 IP 没变，tcpdump 抓包关键内容也没变。

我个人觉得这种攻击影响很恶劣，是针对某一个 ssl 版本的漏洞，根本不好防范。

也不太好写规则去屏蔽，现阶段只能识别恶意 IP 。

[kilasuelika]

升级 ssl 如何

[ZE3kr]

直接套 cdn 就可以避免这种了吧，这种防御交给 cdn 厂商去做

[Pastsong]

已知漏洞升级 ssl 就好，一般也不会有人拿 0day 漏洞出来干你的网站吧

[lupus721]

这个 ssl hello 能干啥呢？ dos 消耗资源么？

[tool2d]

@lupus721 这 client hello 应该是一个注入的前置探针，如果服务器返回预期结果，接下来就会发送一些破坏代码。轻则服务挂掉，重则变肉鸡。

这个 ip 经常会 post 一些看不太懂的二进制数据，到我服务器上，还好上传权限都卡死死的。

[ranaanna]

好奇查了一下貌似这个 ip 是一个 tor 出口节点，所以... ... ...

[OleJienNor]

服务器前面套一层 nginx 反向代理，如果本来就用的话就更好了，然后使用 nginx 的流量镜像功能转发流量看下具体的请求内容。然后在反向代理层的 nginx 上加 waf 插件，根据特征自己写防护规则，同时根据业务需求禁止非必要访问 IP 地址段。现在有不少开源的软件 waf ，能满足折腾的想法，同时，花销较少。如果嫌麻烦，看看 CDN 和云 WAF 产品。

[lupus721]

@tool2d 注入的前置探针？我孤陋寡闻了，没太理解啥意思，望指教。

还会有后面，服务其返回了预期结果（如果请求方数据报文有问题，ssl 相关应该是直接抛弃啊），如果确实攻击者掌握了一些 0day ，比如心血那种，那确实会出现后面你说的情况，不过好像也没听到 ssl 最近有爆洞啊。

就算拒绝服务栈溢出到命令执行还有不少的路要走，暂时为止没有听说哪个 ssl 的漏洞可以直接打到命令执行这个层面的，也望一起指教。

最后 post ，随便 po 呗，业务系统上做好校验、过滤。不符合的全丢就是了，当然，要是有上传接口确实需要格外注意。

[tool2d]

@lupus721 我有些服务器的 centos 内核版本很老很老，有业务在跑，也没人去升级，就很慌。

这 ip 并不是只发一个 ssl 包，是前后发了一堆二进制数据到 443 （都是非法的），连 wireshark 都报警(Unencrypted protocol detected over encrypted port, could indicate a dangerous misconfiguration)。

能看懂的我不怕，见招拆招。对这种看不懂的，就有点慌。

[lupus721]

@tool2d 内核版本老，那就单独升级 openssl 组件也可以的，要达到你上面你预估的 443 直接命令执行，还是很难的，相对而言担心 nginx 都会多过 openssl ，我刚才又详细确认了下，openssl 历史上都没找到命令执行（个别给的 possibly execute arbitrary code ）没有看到过外界有过先例。

“Unencrypted protocol detected over encrypted port, could indicate a dangerous misconfiguration” 这个本身只是一个预估，发现了疑似明文的在本该加密的端口通讯，多关注服务器本身的日志，报警之类的更靠谱。

不是说 openssl 不会出问题，只是需要足够的证据，就现有的情况，提前排查后面 web 容器，应用，中间件等的风险更有价值。

[qiaorenzhi]

这种不用担心，服务器 22 端口关掉，然后 https 协议强制 TLSv2 以上，对系统基本没啥影响。
实在不放心，升级下 openssl 就行。