linux 被黑, 某个进程不断发起http请求, 怎么查找

Question

我在一台 测试linux 上部署了一个 3proxy 开放代理,最近突然变慢,
查看日志

1496802724.583  PROXY.8989 00522 - 219.82.139.89:51665 219.82.139.89:12345 43719 0 0 GET_http://219.82.139.89:12345/squid-internal-periodic/store_digest_HTTP/1.1
1496802724.887  PROXY.8989 00522 - 219.82.139.89:48103 219.82.139.89:12345 45533 0 0 GET_http://219.82.139.89:12345/squid-internal-periodic/store_digest_HTTP/1.1
1496802724.926  PROXY.8989 00000 - 0.0.0.0:0 0.0.0.0:0 0 0 0 Warning:_too_many_connected_clients_(100/100)
1496802725.198  PROXY.8989 00522 - 219.82.139.89:48107 219.82.139.89:12345 55196 0 0 GET_http://219.82.139.89:12345/squid-internal-dynamic/netdb_HTTP/1.1
1496802725.523  PROXY.8989 00522 - 219.82.139.89:50957 219.82.139.89:12345 53560 0 0 GET_http://219.82.139.89:12345/squid-internal-dynamic/netdb_HTTP/1.1

我判断是本机上某个程序不断请求本地的代理 219.82.139.89:12345 导致资源耗尽

一些说明
我不知到为什么会请求
http://219.82.139.89:12345/squid-internal-dynamic
我也没有安装squid

top 也没找到可疑进程

 PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                                        
 6245 root      20   0   14852   9224      0 S   4.0  0.1 102:27.15 3proxy                                                                                                                                         
  549 root     -51   0       0      0      0 S   2.3  0.0 237:37.93 irq/28-iwlwifi                                                                                                                                 
18361 redis     20   0   41876   8640   2600 S   0.3  0.1  90:43.13 redis-server                                                                                                                                   
20800 root      20   0   43676   3796   3020 R   0.3  0.0   0:00.04 top                                                                                                                                            
    1 root      20   0  119720   5932   4068 S   0.0  0.1   0:58.58 systemd                                                                                                                                        
    2 root      20   0       0      0      0 S   0.0  0.0   0:00.85 kthreadd                                                                                                                                       
    3 root      20   0       0      0      0 S   0.0  0.0   0:03.05 ksoftirqd/0                                                                                                                                    
    5 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:0H                                                                                                                                   
    7 root      20   0       0      0      0 S   0.0  0.0  88:05.96 rcu_sched                                                                                                                                      
    8 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcu_bh                                                                                                                                         
    9 root      rt   0       0      0      0 S   0.0  0.0   0:00.37 migration/0                                                                                                                                    
   10 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 lru-add-drain

有什么方法可以解决这个问题?

Answer 1

查看网络通信情况,找到发起请求的端口,根据端口号找对应的进程.

---

举个例子:

我本地有一个web服务器监听的端口是8888, 但本地还有一个进程不断地访问它, 访问的地址是127.0.0.1:8888/test,但我不知道是哪个进程访问的. 但我只知道发起请求的端口号,这个端口是临时的,它存在的时间不足够我去找到这个端口号对应的进程id. 为什么不能延长这个时间呢?
于是我就针对127.0.0.1:8888/test写了一个处理方法,例如:
def test():
    time.sleep(60)
    return 'test'
加入这个方法后每次再去请求这个地址, 连接总能够保持60s(除非那个进程特意设定了很短的超时时间,但你没在问题中指明,我假设它特意这么做).
好了问题解决了:
sudo lsof -nP -iTCP:59450
找到了那个发起请求的进程名称和对应id.
wget    57464 Ruocheng    3u  IPv4 0xac7f662005e863e1      0t0  TCP 127.0.0.1:59450->127.0.0.1:20050 (ESTABLISHED)

Answer 2

最终找到了问题所在,是某个http通过代理请求代理,导致了http循环,并没有入侵.感谢@waltr的热情回答.多做入侵检测