Ruptures de service http

Support Debian
#1

Bonjour,
Je constate des ruptures de service https sur un serveur Debian 9. A ces moments je remarque ce genre de logs:

an 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
Jan 25 20:37:08 vm3215 snmpd[88043]: Connection from UDP: [85.31.193.78]:44145->[ip.de.mon.serveur]:161
...

3300 connexions de ce genre dans la journée par cette IP russe.

Quelqu’un peut me dire de quoi il s’agit ?

#2

une tentative de compromission.
Il ne faut jamais permettre SNMP sur une IP publique.
Il faut que tu modifie ta configuration SNMP pour ne plus être sur l’ip publique. Configurer ton Firewall pour bloquer ce genre de tentatives.

1 J'aime
#3

Une rapide recherche sur le web et notamment une recherche dans la base whois indique que l’IP 85.31.193.78 est gérée par Jaguar Network SAS, un opérateur de réseau historiquement basé à Marseille et qui semble appartenir actuellement au groupe Iliad (Free, Online/Scaleway etc).

Si snmpd enregistre une ligne de log à chaque paquet UDP reçu, je ne suis pas surpris que cela surcharge une VM avec peu de ressources processeur.

Et, effectivement, un service SNMP ne devrait pas être exposé sur Internet. En plus du risque de piratage, le serveur peut être utilisé dans le cadre d’un DoS via son utilisation de UDP.

–
AnonymousCoward

#4

Effectivement, c’est une IP de l’hébergeur Jaguar. SNMP ne semble exposé que sur des IP de chez eux.

Par contre les logs peuvent suffir à surcharger la VM ?
Chaque ligne de log indique « Connection from UDP », ça ne veut pas dire qu’on log à chaque paquet j’espère, mais à chaque conexion, non ?

D’après ce que je vois, on a l’option de logs SNMP par défaut:

ps aux | grep snmpd
root      82541  0.0  0.0  15452   968 pts/0    S+   10:02   0:00 grep --color snmpd
Debian-+  88043  0.0  0.1  61080  6228 ?        Ss    2020  79:45 /usr/sbin/snmpd -Lsd -Lf /dev/null -u Debian-snmp -g Debian-snmp -I -smux mteTrigger mteTriggerConf -f
#5

Relis les réponses de @Zargos et @AnonymousCoward . Il semble que tu aies un démon snmpd en écoute sur une IP publique !
Retour de :

sudo ss -unlp
#6 
$ sudo ss -unlp
State       Recv-Q Send-Q      Local Address:Port                     Peer Address:Port              
UNCONN      0      0                       *:59212                               *:*                   users:(("rsyslogd",pid=25238,fd=47))
UNCONN      0      0                       *:111                                 *:*                   users:(("rpcbind",pid=663,fd=6))
UNCONN      0      0             192.168.1.3:123                                 *:*                   users:(("ntpd",pid=1203,fd=20))
UNCONN      0      0            85.31.203.69:123                                 *:*                   users:(("ntpd",pid=1203,fd=19))
UNCONN      0      0               127.0.0.1:123                                 *:*                   users:(("ntpd",pid=1203,fd=18))
UNCONN      0      0                       *:123                                 *:*                   users:(("ntpd",pid=1203,fd=17))
UNCONN      0      0                       *:161                                 *:*                   users:(("snmpd",pid=88043,fd=7))
UNCONN      0      0                       *:41470                               *:*                   users:(("rpc.statd",pid=67599,fd=8))
UNCONN      0      0               127.0.0.1:783                                 *:*                   users:(("rpc.statd",pid=67599,fd=5))
UNCONN      0      0                       *:839                                 *:*                   users:(("rpcbind",pid=663,fd=7))
UNCONN      0      0                       *:52187                               *:*                  
UNCONN      0      0                       *:60922                               *:*                   users:(("rsyslogd",pid=25238,fd=7))
UNCONN      0      0                      :::57436                              :::*                  
UNCONN      0      0                      :::111                                :::*                   users:(("rpcbind",pid=663,fd=9))
UNCONN      0      0      fe80::250:56ff:feb9:51a7%eth1:123                                :::*                   users:(("ntpd",pid=1203,fd=26))
UNCONN      0      0      fe80::250:56ff:feb9:f51f%eth0:123                                :::*                   users:(("ntpd",pid=1203,fd=25))
UNCONN      0      0                     ::1:123                                :::*                   users:(("ntpd",pid=1203,fd=21))
UNCONN      0      0                      :::123                                :::*                   users:(("ntpd",pid=1203,fd=16))
UNCONN      0      0                      :::839                                :::*                   users:(("rpcbind",pid=663,fd=10))
UNCONN      0      0                      :::57121                              :::*                   users:(("rpc.statd",pid=67599,fd=10))

Voilà la conf /etc/snmp/snmpd.conf:

syscontact "noc@as30781.net"
com2sec    local    127.0.0.1/32     Ef4Twyff
com2sec    local    85.31.192.0/26   Ef4Twyff
com2sec    local    85.31.193.0/26   Ef4Twyff
com2sec    local    85.31.193.64/26  Ef4Twyff
com2sec    local    10.0.192.0/26    Ef4Twyff
com2sec    local    10.0.193.0/26    Ef4Twyff
com2sec    local    10.0.193.64/26   Ef4Twyff
group MyROGroup v1         local
group MyROGroup v2c        local
group MyROGroup usm        local
view all    included  .1                               80
access MyROGroup ""      any       noauth    exact  all    none   none

extend check_md_raid /opt/admin/bin/check_md_raid.sh
#7

A supprimer. Et mettre dans le ficheir de configuration:

agentaddress tcp:<ip interne>:161
#8

Avant de supprimer il faudrait savoir d’où vient cette configuration SNMP et pourquoi elle a été mise en place.
Après tout ces entrées dans les logs sont peut-être légitimes et dues à un outil de monitoring mis en place par l’hébergeur as30781.net / Jaguar Networks

#9

Oui. C’est une config mise en place par Jaguar.

Les logs peuvent ils réellement pénaliser le serveur à ce point ?

On voit ici à une heure d’une rupture de service que 42 conexions snmp ont été établies dans la seconde:

kmc@vm3215:~$ grep 20:33:06 syslog-20210126 
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
Jan 25 20:33:06 vm3215 snmpd[88043]: Connection from UDP: [85.31.192.48]:42312->[85.31.203.69]:161
kmc@vm3215:~$ grep 20:33:06 syslog-20210126 |wc
     42     378    4158

Mais il y a de telles conexions toute la journée et la rupture de service n’apparait que certains jours, 3 à 4 fois à heures irrégulières. Ce serait donc le cumul de ces conexions avec d’autres process ?
D’autre part je ne scrute les serveurs qu’une fois par heure et ne peux donc être précis sur le temps et la durée des indisponibilités.
Y-aurait-il un moyen de détecter l’origine des ruptures de service de façon certaine sans trop ajouter à la charge du serveur ?

#10

Simple petit commentaire en passant: je te conseille de faire un

nmap

sur ton serveur je tremble à l’idée de savoir ce que ca pourrait révéler.

A mon avis tu as des ports ouverts qui seraient loin de devoir l’être…jdcjdr

1 J'aime
#11

Pas besoin d’utiliser nmap, le retour de la commande ss est déjà assez parlant…
Maintenant il faut savoir si ces services sont légitimes (serveur NTP) ou on vocation a tourner sur un serveur directement relié à l’Internet (serveur NFS et serveur SNMP).

Pour le SNMP il faut voir avec ton hébergeur mais cela ne me semble franchement pas propre comme configuration. Et il n’est pas non plus normal d’avoir autant de connexions de diverses machines dans leurs plages d’IP.

#12

Bah c’est une façon de voir mais ok.

Alors dans ce cas j’aime bien

netstat -nputw | grep ESTABLISHED

ps: normalement sur ta config des traps tu dois avoir des acl limitant le champ des écoutes

#13 
sudo netstat -nputw | grep ESTABLISHED
tcp        0     36 ip.de.la.vm:22         m.o.n.ip:41018      ESTABLISHED 99742/sshd: kmc [pr 
tcp        0     52 ip.de.la.vm:22         27.70.134.169:60774     ESTABLISHED 106153/sshd: unknow 
tcp        0      0 192.168.1.3:824         192.168.1.253:2049      ESTABLISHED

Donc en dehors de moi 2 connexions établies.

Mais que signifie 106153/sshd: unknow ? On peut se connecter SSH en tant que unknown ?!

et 192.168.1.253:2049 ESTABLISHED - ?

#14

Tu as une machine dont l’Ip est 27.70.134.169 qui tente de se connecter en SSH à ton serveur. L’utilisateur est « unknown » parce qu’il ne s’est pas encore identifié.

C’est sur un réseau local 192.168.1.0/24. Au vu du port utilisé, probablement une conexion de ta machine vers un partage NFS.

#15

Bah des tentatives de connexion ssh, il y en a sans arrêt. Et encore, sur ce serveur il y en a peu. Actuellement 138 IP bannies par fail2ban pour tentative SSH et 14 en recidive . J’ai d’autres serveurs où ça monte à 3000 en recidive…

On dirait que je ne vais pas réussir à expliquer les ruptures de service sur ce serveur.

#16

La configuration de ton serveur est étrange avec des services qui n’y ont peut-être pas leur place, une configuration de snmpd douteuse et une connectivité à plusieurs réseaux.

Maintenant, ce que tu appelles des ruptures http, c’est peut-être simplement une surcharge du serveur web, ou une mauvaise configuration qui ne lui permet pas de supporter le charge. Cela tu peux le voir avec tes outils de monitoring : nombre de requêtes HTTP, nombre de processus Apache ou Nginx, etc.

#17

C’est un numéro de PID

#18

Tout ça est le fait de l’hébergeur. Je suppose qu’il sait ce qu’il fait et je n’ai rien de ferme et définitif à objecter.

Je n’ai pas eu non plus de confirmation que la fréquence des logs snmp était en cause.

Il ne me reste donc qu’à analyser le serveur WEB si je comprends bien.