Fonctionnement et maintenance de Linux - Linux est piraté et un certain processus continue de faire des requêtes http. Comment le trouver ?

Question

J'ai déployé un proxy ouvert 3proxy sur un Linux de test, et il est soudainement devenu lent récemment,
Vérifiez le journal

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

Je juge qu'un programme sur cette machine continue de demander le proxy local 219.82.139.89:12345, provoquant un épuisement des ressources

Quelques instructions
Je ne sais pas pourquoi je demande
http://219.82.139.89:12345/squid-internal-dynamic
Je n'ai pas non plus installé Squid

top n'a également trouvé aucun processus suspect

 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

Y a-t-il un moyen de résoudre ce problème ?

Answer 1

Vérifiez la situation de la communication réseau, recherchez le port qui a initié la demande et trouvez le processus correspondant en fonction du numéro de port.

---

Par exemple :

我本地有一个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

J'ai finalement trouvé le problème. Il s'agissait d'un certain proxy de requête HTTP via un proxy, qui a provoqué une boucle HTTP. Il n'y a eu aucune intrusion Merci @waltr pour votre réponse enthousiaste.