确定从哪里“sh”运行在使用PF或NETSTAT的apache www-data用户下

我正在使用受损的Ubuntu 8.04 Plesk 9.5.4服务器。 似乎服务器上的脚本不断地对互联网上的随机IP进​​行反向查找。

我第一次发现它在使用top ,然后注意到这个持续闪烁: sh -c host -W 1 '198.204.241.10'

我写了一个脚本来每隔1秒询问一次ps ,看看脚本发生的频率:

 #!/bin/bash while : do ps -ef | egrep -i "sh -c host" sleep 1 done 

结果是这个脚本经常运行,每隔几秒钟:

 www-data 17762 8332 1 10:07 ? 00:00:00 sh -c host -W 1 '59.58.139.134' www-data 17772 8332 1 10:07 ? 00:00:00 sh -c host -W 1 '59.58.139.134' www-data 17879 17869 0 10:07 ? 00:00:00 sh -c host -W 1 '198.204.241.10' www-data 17879 17869 1 10:07 ? 00:00:00 sh -c host -W 1 '198.204.241.10' www-data 17879 17869 0 10:07 ? 00:00:00 sh -c host -W 1 '198.204.241.10' root 18031 17756 0 10:07 pts/2 00:00:00 egrep -i sh -c host www-data 18078 16704 0 10:07 ? 00:00:00 sh -c host -W 1 '59.58.139.134' www-data 18125 17996 0 10:07 ? 00:00:00 sh -c host -W 1 '91.124.51.65' root 18131 17756 0 10:07 pts/2 00:00:00 egrep -i sh -c host www-data 18137 17869 0 10:07 ? 00:00:00 sh -c host -W 1 '198.204.241.10' www-data 18137 17869 1 10:07 ? 00:00:00 sh -c host -W 1 '198.204.241.10' 

我的理论是,如果我能看到谁在启动sh进程或者启动它的forms,我可以进一步隔离问题。

有人可以请指导我使用netstatps来识别sh正在运行?

我可能会得到很多关于操作系统已经过时的build议,所以请记住这个服务器运行传统软件的一些非常具体的原因。 我的问题针对的是先进的Linux系统pipe理员,他们对安全性有深入的了解,并使用netstatps来实现它的底层。

更新26十月14:01 SAST

grep -lr 'sh -c host'留下的留言中留下的命令grep -lr 'sh -c host'帮助我快速find运行该脚本的相应网站。 事实certificate,服务器没有受到威胁 。 反过来说,SMF 1.1.2 |提供的位置上有一个论坛 SMF©2006-2007,简单机器有限责任公司 ,每次有人访问董事会做反向查找。

这也certificate论坛没有维护和严重的垃圾邮件,为什么我们最初认为这是妥协的是因为许多反向查找指向外国知名的垃圾邮件。 善良只知道一个网站如何执行这个命令,但是暂时我要把这个问题视为无害的。

关于我收到的有关“从备份中恢复”的一揽子答复,我来到了ServerFault,以帮助找出问题,并在最初的请求中明确指出了这一点。 有时从备份恢复是不切实际的,甚至是不可能的。 找出问题或find妥协,以防将来可能出现。

虽然看起来你已经找出了这个问题的原因,但用pstree和几个参数来转储过程表会有帮助。

将循环中的ps命令replace为:
pstree -apu www-data >> getyousomespam.txt

你只想运行这个约30秒,因为它会产生的文字墙。 这将显示www-data所拥有的所有进程,它们的祖先进程,沿途的所有uid转换( -u ),可search的命令行参数( -a )和PID( -p )。

很显然,如果你被攻陷了,那么这个信息就会完全不起作用,但是如果你还没有(这里似乎就是这种情况),那么这将提供你正在寻找的文件……或者至less是一个好的开始。

编辑:
pstree并不关心始发terminal,但是如果你能把事物分离成持久的祖先过程,那么使用PID就可以很容易地从那里完成工作。

停止。 你这样做是错误的。 您的服务器已损坏,您需要断开连接并从已知的备份中恢复。 另请参见如何处理受感染的服务器?