Forum Linux.noyau serveur kimsufi inaccessible pendant quelques minutes ...

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
2
22
mai
2016

Salut les amis,
j'arrive pas à diagnostiquer un truc zarb : j'ai un kimsufi et parfois il n'est pas accessible en ssh / https pendant … 10 à 20 minutes.

Un mtr/traceroute/ping fonctionne sans pb.

Mais si je ssh, le tcpdump m'indique bien que les paquets partent, mais aucune réponse.

Côté serveur le firewall est stoppé.

J'ai cherché du côté de l'ipv6 qui est actif sur ce serveur, mais je ne sais pas trop quoi chercher en fait. (dmesg a attiré mon attention avec plein de messages "ip_set: protocol 6") mais pffff même en supprimant l'ipv6 j'ai le pb.

Ça m'arrive plus souvent avec mon téléphone (android) quand je suis connecté via le wifi chez moi ou au boulot … si ça coince, je stoppe le wifi et ça passe par la 3G, je réactive le wifi ça déconne, je repasse en 3G ça marche !

Et si je suis sur le serveur en ssh en même temps depuis mon pc je ne sais pas quoi chercher pour trouver l'origine du pb. C'est super énervant.

Je m'en rends compte parce-que j'ai un owncloud / agenda / mail sur ce serveur donc il est "monitoré" en quasi temps réel par mon téléphone :o)

Ça vous donne une idée ? Vous avez une piste ?

Merci d'avance,
Éric

  • # Fail2ban?

    Posté par  (site web personnel, Mastodon) . Évalué à 10.

    Salut,

    T'as pas de logiciel pour bannir des IPs malveillantes, du type fail2ban, sur ton serveur?

    Quand je le paramétrais au début, j'étais un peu trop strict sur certaines règles, de sorte que j'auto-bannissais mon IP sur certains types de requête. Cela pourrait expliquer pourquoi ça marche en 3G mais pas en wifi (les 2 connexions ayant une IP publique différente).
    Surtout si ton téléphone fait des requêtes très régulières (pour sync owncloud, agenda, mail…) et que tu as mis des règles pour contrer des DOS, il se pourrait que tu t'auto-bannisses.

    Bon par contre, je bannissais des IPs sur requêtes http par erreur, mais jamais SSH (car là ma règle est super stricte, mais comme j'utilise une clé SSH, je fais jamais "d'erreur").

    As-tu ce type de logiciel sur ton serveur? Si oui, tu devrais regarder de ce côté là, cela pourrait expliquer le problème de requêtes sans réponse. Tu dois trouver un bon compromis pour les règles fail2ban (ou logiciel similaire) entre trop de laxisme et trop strict.

    Je te conseille aussi de regarder les logs pour y trouver des schémas de requêtes évidemment malveillantes tentées sur ton serveur de même que tes propres requêtes évidemment acceptables. Tu pourrais ainsi déduire des patterns qui seront plus fiables et permettront d'arrêter plus de requêtes malveillantes tout en protégeant les accès normaux.

    Si par contre, c'est pas le problème, là je vois pas. :-)

    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

    • [^] # Re: Fail2ban?

      Posté par  . Évalué à 1.

      Merci pour la piste mais non, j'ai effectivement des fail2ban et autres choses du genre mais rien dans les logs, rien dans iptables, rien de rien, je vais continuer à chercher et ptet qu'un jour j'aurais l'explication :-)

      En fait j'aurais eu un coup de bol qu'une autre personne sur linuxfr me dise "ha moi aussi ça me fait ça avec un kimsufi" … peut-être que c'est du filtrage L7 chez ovh (vu que le ping/traceroute fonctionne bien pendant ce temps), en fait c'est toute l'impression que ça me donne mais on accuse toujours les autres et avant de les emmerder avec ça je voulais voir si vous aviez des idées …

      eric.linuxfr@sud-ouest.org

      • [^] # Re: Fail2ban?

        Posté par  . Évalué à 2.

        peut-être que c'est du filtrage L7 chez ovh (vu que le ping/traceroute fonctionne bien pendant ce temps), en fait c'est toute l'impression que ça me donne

        il est possible en effet que tu tombes dans leur systeme anti-DDOS si tes synchros de cloud sont trop frequentes

        tu pourrais essayer en augmentant le delai entre les synchros, voire en desactivant completement la synchro automatique pour ne synchroniser qu'à la main.

        tu verras alors vite si c'est ca qui enclenche l'antiDDOS.

        • [^] # Re: Fail2ban?

          Posté par  . Évalué à 1.

          Hello NeoX, ça progresse, j'ai un tcpdump qui donne ça:

          13:34:48.199847 IP chezmoi.52413 > serveur_kimsufi.https: Flags [S], seq 1930877214, win 14600, options [mss 1460,sackOK,TS val 47366809 ecr 0,nop,wscale 6], length 0
          13:34:48.199887 IP serveur_kimsufi.https > chezmoi.52413: Flags [S.], seq 2960920737, ack 1930877215, win 28960, options [mss 1460,sackOK,TS val 155095627 ecr 47366809,nop,wscale 7], length 0
          13:34:48.233323 IP chezmoi.52413 > serveur_kimsufi.https: Flags [.], ack 1, win 229, options [nop,nop,TS val 47366818 ecr 155095627], length 0
          13:34:48.234156 IP chezmoi.52413 > serveur_kimsufi.https: Flags [P.], seq 1:518, ack 1, win 229, options [nop,nop,TS val 47366818 ecr 155095627], length 517
          13:34:48.234196 IP serveur_kimsufi.https > chezmoi.52413: Flags [.], ack 518, win 235, options [nop,nop,TS val 155095635 ecr 47366818], length 0
          13:34:48.234969 IP serveur_kimsufi.https > chezmoi.52413: Flags [P.], seq 1:138, ack 518, win 235, options [nop,nop,TS val 155095635 ecr 47366818], length 137
          13:34:48.268590 IP chezmoi.52413 > serveur_kimsufi.https: Flags [.], ack 138, win 245, options [nop,nop,TS val 47366827 ecr 155095635], length 0
          13:34:48.269093 IP chezmoi.52413 > serveur_kimsufi.https: Flags [P.], seq 518:569, ack 138, win 245, options [nop,nop,TS val 47366827 ecr 155095635], length 51
          13:34:48.271992 IP chezmoi.52413 > serveur_kimsufi.https: Flags [P.], seq 569:2209, ack 138, win 245, options [nop,nop,TS val 47366827 ecr 155095635], length 1640
          13:34:48.272016 IP serveur_kimsufi.https > chezmoi.52413: Flags [.], ack 2209, win 261, options [nop,nop,TS val 155095645 ecr 47366827], length 0
          13:34:48.307082 IP serveur_kimsufi.https > chezmoi.52413: Flags [P.], seq 138:932, ack 2209, win 261, options [nop,nop,TS val 155095653 ecr 47366827], length 794
          13:34:48.380328 IP chezmoi.52413 > serveur_kimsufi.https: Flags [.], ack 932, win 270, options [nop,nop,TS val 47366855 ecr 155095653], length 0
          13:34:49.809429 IP serveur_kimsufi.https > 193.50.102.131.51194: Flags [F.], seq 18580, ack 792, win 245, length 0
          13:34:49.863651 IP serveur_kimsufi.https > 193.50.102.131.51194: Flags [.], ack 823, win 245, length 0
          13:34:53.312265 IP serveur_kimsufi.https > chezmoi.52413: Flags [F.], seq 932, ack 2209, win 261, options [nop,nop,TS val 155096905 ecr 47366855], length 0
          13:34:53.341454 IP chezmoi.52413 > serveur_kimsufi.https: Flags [P.], seq 2209:2240, ack 932, win 270, options [nop,nop,TS val 47368095 ecr 155095653], length 31
          13:34:53.341953 IP chezmoi.52413 > serveur_kimsufi.https: Flags [F.], seq 2240, ack 932, win 270, options [nop,nop,TS val 47368095 ecr 155095653], length 0
          13:34:53.341979 IP serveur_kimsufi.https > chezmoi.52413: Flags [.], ack 2241, win 261, options [nop,nop,TS val 155096912 ecr 47368095], length 0
          13:34:53.345215 IP chezmoi.52413 > serveur_kimsufi.https: Flags [.], ack 933, win 270, options [nop,nop,TS val 47368096 ecr 155096905], length 0
          13:34:59.881955 IP serveur_kimsufi.https > 193.50.102.131.51194: Flags [.], ack 823, win 245, length 0
          13:35:00.646415 IP chezmoi.49201 > serveur_kimsufi.https: Flags [S], seq 2358183730, win 29200, options [mss 1460,sackOK,TS val 28768 ecr 0,nop,wscale 7], length 0
          13:35:03.629235 IP chezmoi.62889 > serveur_kimsufi.https: Flags [S], seq 804453984, win 29200, options [mss 1460,sackOK,TS val 29513 ecr 0,nop,wscale 7], length 0
          13:35:04.549683 IP chezmoi.63471 > serveur_kimsufi.https: Flags [S], seq 1241973132, win 29200, options [mss 1460,sackOK,TS val 29744 ecr 0,nop,wscale 7], length 0
          13:35:04.625256 IP chezmoi.62889 > serveur_kimsufi.https: Flags [S], seq 804453984, win 29200, options [mss 1460,sackOK,TS val 29763 ecr 0,nop,wscale 7], length 0
          13:35:04.805408 IP chezmoi.49893 > serveur_kimsufi.https: Flags [S], seq 3898300547, win 29200, options [mss 1460,sackOK,TS val 29808 ecr 0,nop,wscale 7], length 0
          13:35:06.629307 IP chezmoi.62889 > serveur_kimsufi.https: Flags [S], seq 804453984, win 29200, options [mss 1460,sackOK,TS val 30264 ecr 0,nop,wscale 7], length 0
          13:35:09.900887 IP serveur_kimsufi.https > 193.50.102.131.51194: Flags [R], seq 290896853, win 0, length 0
          13:35:10.636678 IP chezmoi.62889 > serveur_kimsufi.https: Flags [S], seq 804453984, win 29200, options [mss 1460,sackOK,TS val 31266 ecr 0,nop,wscale 7], length 0
          

          Et un tail -f sur mon fichier apache *.log (erreur ou access) ne donne RIEN, c'est zarb, je reçois des paquets sur le port 443 mais apache semble ne rien voir arriver …

          Ça vous fait penser à un truc ?

          Je continue de creuser !

          eric.linuxfr@sud-ouest.org

          • [^] # Re: Fail2ban?

            Posté par  . Évalué à 2.

            Et un tail -f sur mon fichier apache *.log (erreur ou access) ne donne RIEN, c'est zarb, je reçois des paquets sur le port 443 mais apache semble ne rien voir arriver …
            Ça vous fait penser à un truc ?

            oui, à un firewall qui drop juste apres avoir recu le paquet sur la carte reseau
            => iptables-save sur la machine te montrera s'il y a des regles de blocages.

            fail2ban peut etre reglé pour bloquer selon des erreurs dans les logs, ou un trop grand nombre de connexion…
            et il modifie les regles de firewall pour bloquer "l'attaquant".

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.