记录一次服务器被CC攻击后的处理过程

2022年10月19日，晚上10点半，突然收到许多用户的反馈说小程序打不开了，打开一看果然，小程序一直处于转圈圈状态。

看了一下时间，10点32分，内心一句MMP：本来打算早睡，一看这架势，熬夜跑不了。

安抚用户

除了小程序之外，服务器上面还跑了很多其他的服务，虽然用户量不大，但是找起来也是要命。

首先告知发出反馈的用户 事件的原因，以及一个保证，并表示问题不大。

解决问题

因为自己并没有收到腾讯云的安全监控提醒，所以起初想到的是某个程序内存泄漏，把资源跑满了。

事实证明是我错了，有量但是不大的网络攻击占满了带宽，导致服务器无法接受新的请求。

1.安全组关闭所有开放端口

理想状态下，关闭安全组之后，服务器状态恢复正常，然后连接服务器，查看一下请求日志，看是攻击的是哪些服务，然后进行针对性的处理，最后睡个好觉。

事不随人愿，服务器已经彻底崩溃了，通过在线SSH已经无法连接，然后通过VNC访问，发现服务器已经崩溃，进入了一堆英文的错误界面。

VNC

VNC 登录是腾讯云为用户提供的一种通过 Web 浏览器远程连接实例的方式。在没有安装或者无法使用远程登录客户端，以及通过其他方式均无法登录的情况下，用户可以通过 VNC 登录连接到实例，观察实例状态，并进行基本的管理操作。

于是乎，只好发送重启命令，跳进入另一个坑。

2.重启服务器

万万没想到，一个重启把整个腾讯云服务器操作页面卡住了（服务器处于Rebooting状态，页面不能进行操作）。

等待了10分钟（刚好抽空进行记录），终于能操作了，满心欢喜连接SSH，卡住，我也愣住。

连接VNC，a starting job xxx 等待130s，飘红，大概意思是在等待一个叫 /dev/vdd的磁盘，继续等待。

超过130s还没好，自动进入了紧急模式（emergency mode），进入紧急模式后能操作Bash命令了。

按照提示进行登录，输入密码，进入了熟悉的命令行界面。

查看两个挂载盘，发现没有叫vdd的，才明白在上一次更换挂载盘的时候，忘记修改自动加载硬盘的参数了。

打开我的葵花宝典：记录自己服务器重启之后，需要重启的服务

默默地修改好，重启了几个重要的服务，一看时间已经半个小时没了...

3.日志分析

分析了所有站点的日志，找到了请求异常的站点，于是乎，先把这个域名解析到127.0.0.1，准备尝试进入生产模式。

发现CC的IP基本都是国外的，修改DNS解析线路类型为境内，从源头防起。

4.放通端口

将安全组配置进行了恢复，观察了一会，已经没有了异常。

大吉大利，攻击的人没有继续纠缠。

CC还在，只是量小了，等DNS解析生效应该更少，安心睡觉。

5.后顾之忧

过往的经验表明，这一次过去了，不代表不会再来一次，通过内网将小程序的服务端关联到了另一台服务器。

如果这台挂了，可以关闭外网的访问，然后将域名解析到另一台服务器，再通过内网反向代理，作为应急之举，应该还是足够的。

6.DNS

全节点DNS更新不知猴年马月，还是有不少请求来自被攻击的这个服务（已经解析127.0.0.1，并且DNS线路为境内）的境外的流量漏进来；

# 国务院去报道
return 301 https://https://www.gov.cn/;

7.安全组

指定子网IP段进行拦截，范围大了容易误杀，不过也没法了。

• 源IP填写为118.124.8.0/24 表示118.124.8.*
• 源IP填写为118.124.0.0/16 表示118.124.*.*

8.预防

逐步将所有服务调整为反向代理，应用服务器深藏局域网，只通过反向代理服务器作为出入口。

事后

收到了邮件，竟然是勒索。

事件