解决sfewfesfs病毒感染后严重丢包,附删除方法。

前两天一服务器一联网就丢包,断断续续,流量监控到流量跑的非常高,怀疑是攻击但关闭80口后问题依旧,开始着手是否服务器中了病毒果然不出所料

netstat -nltp

发现有三个可疑链接文件名如下

sfewfesfs

sshdd14XXXXXXXX(一串随机数字)

sshhdd14XXXXXXXX(一串随机数字)

查看文件进程PID路径

ps -axu | grep -i sfewfesfs

ps -axu | grep -i sshdd14*

ps -axu | grep -i sshhdd14*

发现sfewfesfs和nhgbhhj在/etc下

首先解除删除权限chattr -i /etc/sfewfesfs*

rm -rf /etc/sfewfesfs*

看到名为nhgbhhj等的可疑文件一并删除

rm -rf /etc/nhgbhhj

rm -rf /etc/nhgbhhj*

删除计划任务,防止病毒再次生成

rm -rf /var/spool/cron/root

rm -rf /var/spool/cron/root.1

用ls -al /etc看到.SSH2(还有可能是.SSHH2)隐藏文件,删除

rm -rf /etc/.SSH2

rm -rf /etc/.SSHH2

用ls -al /tmp看到.sshdd14XXXXXXXX(一串随机数字)或.sshhdd14XXXXXXXX(一串随机数字)隐藏文件,删除

rm -rf /tmp/.sshdd14*

rm -rf /tmp/.sshhdd14*

重启服务器后,一切恢复正常。

时间: 2024-07-31 13:16:47

解决sfewfesfs病毒感染后严重丢包,附删除方法。的相关文章

客户端本地到服务器丢包的检查方法

如果用户本地到服务器出现ping丢包或直接无法连接的时候,可以通过如下步骤进行排查分析:   客户端本地到服务器丢包的检查方法 1. ping服务器IP地址或域名,查看丢包情况:     ping 140.205.140.234 -n 100  说明: -n 后面的数字表示要进行的ping测试次数: 主要关注如下下图所示所统计的丢包率和平均超时时间: 2. 使用MTR工具跟踪下到服务器的链路情况: Windows下,使用所示的WinMTR工具进行跟踪测试: 用法:打开软件后,在[hosts]框中

ping丢包故障处理方法

1. Ping丢包故障定位思路故障分析Ping丢包是指Ping报文在网络中传输,由于各种原因(如线路过长.网络拥塞等)而产生部分Ping报文丢弃的现象.在使用Ping命令,出现Ping丢包的现象时,第一步需要确定Ping丢包的网络位置,其次是确定Ping丢包的故障原因,然后依据定位的故障原因再进行解决.确认Ping丢包的网络位置时一般采用逐段Ping的方法,可以将Ping丢包故障最终确定在直连网段之间. 确认Ping丢包的故障原因一般采用流量统计的方法,通过流量统计可以知道丢弃报文的具体位置.判

Ping丢包故障案例

一.Ping丢包故障 1.Ping丢包故障现象 二.故障猜想可能存在以下问题 1.物理环境故障:2.网络环路:三.故障定位1.物理环境故障:登录交换机dis int g1/0/1查看端口下面不存在CRC报文,排除物理环境故障.2.网络环路(1)通过display interface brief | include up命令,查看所有UP接口下的流量,存在环路的接口上InUti和OutUti两个计数会逐步增加,甚至到接近100%,远远超过业务流量. ??? 第一次查询: ??? <SwitchA>

[转]nf_conntrack: table full, dropping packet 连接跟踪表已满,开始丢包 的解决办法

nf_conntrack: table full, dropping packet  连接跟踪表已满,开始丢包 的解决办法 中午业务说机器不能登录,我通过USM管理界面登录单板的时候发现机器没有僵死,然后一看日志,g一下子就明白了 tail -2000 /var/log/messages Apr 10 12:48:35 bj-push-pushserver83 kernel: [95129.138804] __ratelimit: 16523 callbacks suppressed (“连接跟

AR8033 1000M模式下ping包丢包率过大分析与解决

1 现象 近期对一款基于QCA方案.有线Phy为AR8033.WiFi双频且支持iEEE802.11AC的WLAN产品进行了深度验证,发现有线口同部分PC机直连时,WiFi终端ping 该PC机时总是丢包,有时高达20%:但通过交换机再接PC机时,又不会丢包.一直以为是偶现,所以未引起重视,反正跑流性能与稳定性都没有任何影响.后来新购了一批千兆有线口的便携机进行配套验证时,发现每台都是如此,ping包丢得一塌涂地.在WLAN设备和PC机上分别开启抓包工具,可以看到设备已发包,但PC机未收到报文:

Linux UDP严重丢包问题的解决

测试系统在Linux上的性能发现丢包率极为严重,发210000条数据,丢包达110000之巨,丢包率超过50%.同等情形下Windows上测试,仅丢几条数据.形势严峻,必须解决.考虑可能是因为协议栈Buffer太低所致,于是先看看默认情况: sysctl -a |grep net.core 发现 net.core.rmem_max = 131071 net.core.rmem_default = 112640 修改吧,变大一点,变成10M,然后reboot(应该重启某个服务即可) 然后查网卡收包

Linux服务器丢包故障的解决思路及引申的TCP/IP协议栈理论

我们使用Linux作为服务器操作系统时,为了达到高并发处理能力,充分利用机器性能,经常会进行一些内核参数的调整优化,但不合理的调整常常也会引起意想不到的其他问题,本文就一次Linux服务器丢包故障的处理过程,结合Linux内核参数说明和TCP/IP协议栈相关的理论,介绍一些常见的丢包故障定位方法和解决思路. 问题现象 本次故障的反馈现象是:从办公网访问公网服务器不稳定,服务器某些端口访问经常超时,但Ping测试显示客户端与服务器的链路始终是稳定低延迟的. 通过在服务器端抓包,发现还有几个特点:

UDP丢包和无序 问题的解决方法

最近在做一个项目,在这之前,做了个验证程序. 发现客户端连续发来1000个1024字节的包,服务器端出现了丢包现象. 纠其原因,是服务端在还未完全处理掉数据,客户端已经数据发送完毕且关闭了. 我用过sleep(10),暂时解决这个问题,但是这不是根本解决办法,如果数据量大而多,网络情况不太好的话,还是有可能丢失. 你试着用阻塞模式吧... select...我开始的时候好像也遇到过..不过改为阻塞模式后就没这个问题了... 采用回包机制,每个发包必须收到回包后再发下一个 UDP丢包是正常现象,因

修改网卡缓存,解决Linux 网卡丢包严重问题

修改网卡缓存,解决Linux 网卡丢包严重问题 Linux 网卡丢包严重 生产中有一台linux设备并发比较大,droped包比较多,尤其是在跑游戏数据包的时候,存在严重的丢包现象,怀疑网卡性能不足,在更换设备前想能不有通过软件方法解决,通过网上一些资料显示,出现这种现象,也有可能是网卡buffer size 太小的原因,遂尝试更改buffer 大小解决,下面的设备运行了64天,丢包超过20多亿 找了一些国外的文章,可以通过ethtool来修改网卡的buffer size ,首先要网卡支持,我的