服务器与大带宽专家 · 持牌IDC/CDN/ISP服务商
简米科技官网JIANMI TECH
资讯 2026-10-21 简米科技 4,376 字 10 分钟阅读

服务器被攻击时如何安全传输文件?被攻击服务器文件怎么安全传输

导读服务器被攻击时,最稳妥的顺序是:先断外网、再开加密隧道、用SSH系工具把数据搬出来,搬完立刻收口,绝不给攻击者留第二道门, 很多人遇到攻击第一反应是“赶紧把文件拖到本地”,这个动作恰恰最容易把后门也一起拖回家,下面按判断、传输、防护三个阶段拆开讲,拿文件之前,先判断这台服务器还能不能信攻击可分成两种:操作系统层……

服务器被攻击时,最稳妥的顺序是:先断外网、再开加密隧道、用SSH系工具把数据搬出来,搬完立刻收口,绝不给攻击者留第二道门。 很多人遇到攻击第一反应是“赶紧把文件拖到本地”,这个动作恰恰最容易把后门也一起拖回家,下面按判断、传输、防护三个阶段拆开讲。

拿文件之前,先判断这台服务器还能不能信

攻击可分成两种:操作系统层面被渗透,或者数据盘被加密勒索,前者更隐蔽,shell命令可能都被人换过了,服务器被攻击怎么办”这个问题的真正起点,是判断这台机器还有多少可信度。

行业共识认为:一台被root权限入侵过的服务器,除非你能完整审计系统,否则它就不再是干净环境,计算机安全领域有个说法被攻破的主机,所有二进制程序都要当作不可信。

第一件事:断外网,但别断自己

先拔网线或者把安全组入方向规则清空,这是最直接的手段,简米云、酷番云、华为云的控制台都可以直接在网页操作,断开后业务会短暂中断,但数据安全优先,这时候你自己仍需要一个入口去拿数据,所以保留一个运维专用的公网IP白名单,只允许你当前IP访问22端口。

查后门:越隐蔽的越要先看

  • 检查 /root/.ssh/authorized_keys,凡是你不认识的一行公钥,直接删掉。
  • 检查 /etc/ssh/sshd_config 是否被加了奇怪的 Include 或 PermitRootLogin 配置。
  • 用 systemctl list-units --type=service --state=running 看有没有陌生服务名。
  • 查看定时任务 crontab -l 和 /etc/cron.d/ 下的新增文件。

这一步不能省,攻击者往往在你眼皮底下留了恢复通道,你以为传完文件就没事了,人家回头又把数据加密一遍。

传数据前,先用新密钥重连

不要再使用服务器上原有的SSH密钥对,因为你不知道它有没有被复制,在你本机生成一对新的密钥:

ssh-keygen -t ed25519 -C "recovery-$(date +%Y%m%d)"
ssh-copy-id -i ~/.ssh/recovery.pub root@服务器IP

然后把服务器的 sshd_config 改成只允许公钥登录,密码登录关掉,这一步做完再开始传文件,比上来就传要安全得多。

被攻击后怎么把数据拿出来:三种实操路径

明确了“能信”这个前提,下一步才谈得上“传输”,整个过程优先级从高到低是:数据完整性 > 传输速度 > 文件数量,宁可用慢一点的加密通道,也不能为了省时间开一个裸奔端口。

单个大文件:用 tar 打包,走 scp

先把要拿的目录打包压缩,减少传输次数和暴露面:

tar czvf /tmp/web_backup_$(date +%Y%m%d).tar.gz /var/www/html
scp -O -i ~/.ssh/recovery.key /tmp/web_backup_$(date +%Y%m%d).tar.gz you@本地IP:/home/you/backup/

这里 -O 参数是为了禁用scp的SFTP协议回退,能避免某些入侵环境里SFTP组件被替换的问题,传输完成后马上在本地计算哈希:

sha256sum web_backup_$(date +%Y%m%d).tar.gz

同时去服务器上再算一遍,两边一致说明文件没有被篡改或注入。

成百上千个小文件:rsync 断点续传

小文件多了用 scp 容易中断,rsync 是更靠谱的选择,它支持增量同步,哪怕传到一半断了,重新执行一次会接着传:

rsync -avz --progress --partial --bwlimit=5000 -e "ssh -i ~/.ssh/recovery.key" /var/www/html/ you@本地IP:/home/you/backup/www/

--bwlimit=5000 是把带宽限制在每秒5MB左右,防止占满业务带宽引发其他问题。--partial 保证半截文件不删除,下次续传。

业内专家提醒过:rsync 传完以后不要马上信任本地副本,重点检查文件名包含shell、crypto、xmrig这类敏感词的文件,多半是恶意脚本。

数据库:用官方工具导出,再走 SFTP

数据库文件不能直接拷贝物理文件,除非你完全停掉数据库服务,否则数据文件处于一致性风险,更稳妥的方式是用官方逻辑导出:

mysqldump -u root -p --single-transaction --routines --triggers > db_backup.sql
gzip db_backup.sql
sftp -i ~/.ssh/recovery.key you@本地IP

进入 SFTP 后用 put db_backup.sql.gz 传回本地,PostgreSQL 对应的是 pg_dump,命令结构类似。

这一步需要注意:导出动作会占用数据库连接和磁盘读写,如果这台机器已经被勒索病毒扫过一遍,磁盘空间可能已经很紧张,先看一眼 df -h 再动手。

业务还没恢复,又必须对外收文件怎么办

现实里有个更尴尬的场景:服务器被攻击了,但业务还要继续接收用户上传的文件,这个时候怎么安全接收?有人说“先把FTP开起来顶两天”,千万别这么干,FTP是明文协议,用户名密码直接裸奔在网络上,等于把登录口令送给下一个攻击者。

临时SFTP收件目录:只开22,其他全关

在服务器上新建一个独立目录,用 SFTP 代替FTP,它走的还是 SSH 协议,加密是现成的,给这个目录建一个权限受限的系统用户:

useradd -d /srv/incoming -s /bin/bash temp_receiver
chmod 750 /srv/incoming

安全组里只放行你自己的 IP 访问22端口,其他全部拒绝,如果用户上传需求来自多个不固定IP,那就用 Match User 限制这个用户只能从特定地址段登录。

落地后立刻校验哈希,并自动移到隔离区

写一个简单的 inotifywait 脚本监控上传目录,文件到达后自动计算哈希并把原文件移动到另一个只读目录:

inotifywait -m /srv/incoming -e close_write |
while read path action file; do
    sha256sum "$path/$file" >> /var/log/upload_checksum.log
    mv "$path/$file" /srv/quarantine/
done

这样就算上传的文件藏了恶意内容,也碰不到相邻文件,目录监控脚本要放在系统服务里跑,别用 nohup,否则shell一断监控也没了。

云服务器被攻击恢复要几步:从传输到重启的完整清单

“云服务器被攻击恢复”看起来是个大工程,但落到操作层面其实就是可验证的几步,按顺序执行,比东一榔头西一棒子更稳。

第1步:快照优先

进云控制台,先打一份快照,这个动作要放在所有操作之前,现在简米云、酷番云都支持后台快照,哪怕你已经断开外网也能操作,快照的目的是保留现场,后续做取证分析时不会破坏原始数据。

第2步:数据盘单独挂载

如果系统盘已经被污染得很严重,把数据盘卸载,挂载到一台新开的干净实例上,这是最干净的路子不再需要SSH隧道,数据盘通过内网挂载到新机器,然后在新环境里打包下载,这种方式能避免旧系统上的后门干扰整个下载过程。

第3步:传输、校验、重启三步闭环

  • 文件传到本地后先做哈希校验,再执行杀毒扫描。
  • 新实例上重新部署业务,使用“服务器被攻击怎么防护”的常见手段:防火墙默认拒绝、SSH只保留公钥登录、安装入侵检测工具。
  • 旧实例在确认数据完整后再销毁,不要急着删,留一个快照至少一周。

第4步:查日志,搞清楚怎么进来的

登录云控制台查看安全组操作日志和系统登录记录,重点关注攻击前一周的22端口登录情况,根据大量应急响应案例,弱口令和未打补丁的Web服务是走漏得最多的两个入口,这次恢复只能解决当下,不解决根因,下次还会再来。

传输中翻车最多的几种做法

有些操作是“看起来方便,实际全给攻击者送助攻”的,遇到一次就够你恢复好几天:

  • 用FTP传数据,用户名密码明文走网线,全程等于广播。
  • 为了传文件把端口开成0.0.0,本意是方便自己,实际是方便全网扫描器。
  • 把服务器上所有文件一股脑打包下载,连攻击者留下的后门脚本也当作“重要资料”备份回家。
  • 在已经被入侵的机器上用老密码做一遍全局改密,改完等于没改。
  • 拿服务器当跳板去访问公司内网其他机器,导致内网横向漂移。

这些坑只要踩一个,前面做的事情就白费了一半。

服务器被攻击后怎么安全传输文件?三个高频疑点一次说清

被攻击后直接打开Xshell传文件,算不算安全?

Xshell的SFTP功能底层是SSH加密协议,加密本身没问题,不安全的点在于这台服务器上可能有别人也在监听攻击者拿到root权限后,可以在你的SSH会话里装一个插件,记录你敲过的每一个命令,包括密码,所以在重装系统或者彻底清除后门之前,任何交互式会话都有被录屏的风险,更稳妥的做法是用密钥认证+文件直传,少在服务器上敲敏感命令。

攻击者还在线,我传文件的过程中会不会被拦截?

不会,SSH传输是加密的,监听网络流量的第三方看不懂内容,真正需要担心的是文件在服务器上被提前动了手脚比如入侵者给某个配置文件里塞了Webshell,你把它备份走了,等于把后门请回家,所以传输前的哈希校验和传完后的样本筛查才是关键动作。

传输速度太慢,数据量太大,能不能先用磁盘镜像方式拷出来?

可以,但代价是时间,你在云平台上做快照导出,或者用dd命令把整个数据盘镜像拉回本地,安全性和完整性都比文件级别传输高,而且能保留删除文件痕迹用于取证,缺点是镜像文件体积远大于实际数据,动辄几个T,本地硬盘和带宽得撑得住,多数云厂商的“快照回滚”功能就是干这个用的,直接在新实例上挂载旧数据盘,比下载到本地再上传省时间。

文件传输只是应急响应的中间环节,不是终点,数据到本地、系统重做完、后门清除掉,这才算把“服务器被攻击时如何安全传输文件”这一程走完,整个过程记住三句话:断开再用、加密通道、落地校验。

分享本文
本文为 简米科技官网 原创,已由运维技术专家审核。转载请注明来源:原文链接
售前咨询 服务热线 售后 邮箱