首先，那位大佬有.[xueyuanjie@onionmail.org].AIR的勒索病毒的解密方法吗。虽然这次应该用不到了，但是有备无患嘛，最近网络安全事故也是频发，虽然这次最终感染客户应用不是很复杂，在一点狗运的帮助下能找回部分数据，但是如果该问题发生在一些企业核心应用上（这次被感染的算是半个核心业务，被骂半天），将是灾难级别的事故。
按时间节点来看下具体的情况吧
首先是最早的时间点，25年8月10日，服务器多了一个叫做Administrat0rd的异常用户，由于该服务器仅跑一个泛* 的应用，所有该服务器无异常并未有人排查，也未购买云上安全服务，该账号不确定是否与本次勒索病毒有关，但是还是都建议服务器安装安全防护软件以及在能做到的情况下天天巡检。
然后就是今天上午，勒索信条创建。数据全部被加密，sql数据全部无法使用。
详细日志文件被加密，更详细的流程路径就没有了。
不过看到此，哪怕出现了这些问题，还是给出以下建议：
安全建议：
1、不建议支付赎金，因为大多数赎金支付了也无法获得解密；
2、若数据很关键，建议寻求第三方专业解密公司做数据恢复；若数据不关键，则建议择机重装系统；
3、修改所有管理端口的账号和密码，并配置强口令。建议使用 安全组策略 限制访问，并禁止将管理端口和管理后台开放到互联网，仅开放必要的业务端口。
4、数据恢复完毕后，立即对 ECS 配置定期快照策略，同时做好异地数据备份工作。
5、设置所有OS系统口令（包括管理员和普通用户）、数据库账号口令、应用（WEB）系统管理账号口令为强口令，密码12位以上；
6、禁止不必要的端口直接暴露在公网，设置防火墙规则或配置安全组策略来禁止端口开放情况；非公共开放的业务端口（如数据库），建议设置只允许特定的IP进行连接；
7、严格控制各服务的系统权限，各服务进程请不要以管理员权限运行；各应用(如WEB)同数据库交互的账号同样不要使用管理员权限的账号；
原安全配置
原基本无安全配置， 除网络安全组有一定调整外，无额外防护，服务器内某绒杀毒软件不确定是攻击者关闭还是我们关闭。接近裸奔状态，并无定时备份。
安全组如下，已经尽可能关闭访问端口。
登录上客户的账号看了一下之后，整个人都是麻的。所以再次强烈建议，一定要做好安全和备份服务，无论云上云下，只要服务器能接触到公网，都无法保证100%的安全，攻防对抗是人与人的竞争，现在我们无法做到完全防护，只能通过一些安全防护软件等提高攻击者的投入成本，这样能避免大多数的问题。当然被社工（社会工程学）了当我没说过。其实现在很多大厂对社工其实也是有一定的防护。
最终处理方案
先说结论，该问题最终没有得到妥善的处理，现目前没有技术能够对加密文件直接解密。以丢失部分数据结尾。
另外一定不要支付赎金，不要去赌别人的仁慈，甚至说句不好听的，你不付款还有价值，付款之后就什么价值就没有了。
然后就提一下说我的那一点狗运，
我发现在本月15号给客户扩容硬盘的时候为了数据安全，扩容前提前做了一份快照，将快照回滚到一台临时服务器之后，发现里面有截止到15号的部分sql数据。赶紧拉通软件厂商去翻之前的数据，稳定住了客户的心态。
结尾
本次事件导致我们被客户骂了一上午，9点50分客户首次联系说系统不可用，
接到客户需求之后联系软件厂商
10点5分左右接到软件厂商电话，说是中病毒了，登录到服务器中确定为中勒索病毒，开始寻找解决方案。
10.40对15号数据完成回滚，让软件厂商开始找数据。
中午12点，所有抢救方案失效，后续再看有无其它方案。着重让软件厂商开始找数据。开始问题溯源。
其实从时间节点来看，我们响应速度已经很快了，但是亡羊补牢，为时晚矣。目前的勒索病毒全网均无太好解决方案，专业的解密公司收费非常贵。前车之鉴，后车之师。希望能给到后来者一定的提醒，希望大家能够清楚的认识到，无论服务器放在云端还是本地，安全都要自己负责。
多备份总是好的，安全这种事最终到头都是人和人的对抗有些时候除了天天备份确实没办法。
希望大家多多交流。有云的需求和架构上的问题也可以联系我。
