linux運維 - 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的熱情回答.多做入侵檢測