Partage
  • Partager sur Facebook
  • Partager sur Twitter

Attaques DDoS

    20 septembre 2018 à 21:51:37

    Bonjour la communauté,

    Je viens vers vous pour avoir un peu d'aide. Sur mon serveur, (debian 8.0) je dispose d'iptables et de fail2ban. J'ai fais un serveur Soldier of fortune 2 et je souhaite savoir si il est possible de protéger les ports 20100 et 20200 contre le "ddos".

    Je dois pouvoir créer un jail avec les règles qui conviennent pour Soldier of fortune 2, mais je sais pas comment faire.

    Je vois que ça se passe dans le fichier /etc/fail2ban/filter.d mais comment en créer un spécialement pour Soldier of fortune 2? en gros un regex...

    Mon VPS est visiblement la cible d'attaques DDoS. Je vous ai joint un extrait du log des connexions réseau enregistrés au moment de l'alerte du monitoring :

    ipv4 2 udp 17 15 src=*** dst=*** sport=56478 dport=20200 src=*** dst=*** sport=20200 dport=56478 mark=0 secmark=0 use=2 ipv4 2 udp 17 8 src=*** dst=*** sport=704 dport=20200 src=*** dst=*** sport=20200 dport=704 mark=0 secmark=0 use=2 ipv4 2 udp 17 2 src=*** dst=*** sport=52391 dport=20100 src=*** dst=*** sport=20100 dport=52391 mark=0 secmark=0 use=2 ipv4 2 udp 17 161 src=*** dst=*** sport=3874 dport=20100 src=*** dst=*** sport=20100 dport=3874 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 163 src=*** dst=*** sport=11034 dport=20100 src=*** dst=*** sport=20100 dport=11034 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 131 src=*** dst=*** sport=1945 dport=20200 src=*** dst=*** sport=20200 dport=1945 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 116 src=*** dst=*** sport=24497 dport=20100 src=*** dst=*** sport=20100 dport=24497 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 166 src=*** dst=*** sport=9123 dport=20200 src=*** dst=*** sport=20200 dport=9123 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 102 src=*** dst=*** sport=41565 dport=20200 src=*** dst=*** sport=20200 dport=41565 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 16 src=*** dst=*** sport=44553 dport=20100 src=*** dst=*** sport=20100 dport=44553 mark=0 secmark=0 use=2 ipv4 2 udp 17 158 src=*** dst=*** sport=59201 dport=20200 src=*** dst=*** sport=20200 dport=59201 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 152 src=*** dst=*** sport=21580 dport=20200 src=*** dst=*** sport=20200 dport=21580 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 140 src=*** dst=*** sport=5655 dport=20200 src=*** dst=*** sport=20200 dport=5655 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 137 src=*** dst=*** sport=51850 dport=20200 src=*** dst=*** sport=20200 dport=51850 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 109 src=*** dst=*** sport=45084 dport=20200 src=*** dst=*** sport=20200 dport=45084 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 8 src=*** dst=*** sport=60393 dport=20100 src=*** dst=*** sport=20100 dport=60393 mark=0 secmark=0 use=2 ipv4 2 udp 17 154 src=*** dst=*** sport=42142 dport=20200 src=*** dst=*** sport=20200 dport=42142 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 1 src=*** dst=*** sport=62137 dport=20200 src=*** dst=*** sport=20200 dport=62137 mark=0 secmark=0 use=2 ipv4 2 udp 17 154 src=*** dst=*** sport=48358 dport=20100 src=*** dst=*** sport=20100 dport=48358 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 138 src=*** dst=*** sport=47836 dport=20100 src=*** dst=*** sport=20100 dport=47836 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 7 src=*** dst=*** sport=595 dport=20200 src=*** dst=*** sport=20200 dport=595 mark=0 secmark=0 use=2 ipv4 2 udp 17 14 src=*** dst=*** sport=37325 dport=20100 src=*** dst=*** sport=20100 dport=37325 mark=0 secmark=0 use=2 ipv4 2 udp 17 162 src=*** dst=*** sport=94 dport=20200 src=*** dst=*** sport=20200 dport=94 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 132 src=*** dst=*** sport=42942 dport=20200 src=*** dst=*** sport=20200 dport=42942 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 146 src=*** dst=*** sport=31422 dport=20200 src=*** dst=*** sport=20200 dport=31422 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 144 src=*** dst=*** sport=44403 dport=20200 src=*** dst=*** sport=20200 dport=44403 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 9 src=*** dst=*** sport=44933 dport=20100 src=*** dst=*** sport=20100 dport=44933 mark=0 secmark=0 use=2 ipv4 2 udp 17 168 src=*** dst=*** sport=55878 dport=20100 src=*** dst=*** sport=20100 dport=55878 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 6 src=*** dst=*** sport=36087 dport=20100 src=*** dst=*** sport=20100 dport=36087 mark=0 secmark=0 use=2 ipv4 2 udp 17 133 src=*** dst=*** sport=8598 dport=20100 src=*** dst=*** sport=20100 dport=8598 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 113 src=*** dst=*** sport=53716 dport=20200 src=*** dst=*** sport=20200 dport=53716 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 129 src=*** dst=*** sport=53762 dport=20100 src=*** dst=*** sport=20100 dport=53762 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 145 src=*** dst=*** sport=17030 dport=20200 src=*** dst=*** sport=20200 dport=17030 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 124 src=*** dst=*** sport=9629 dport=20200 src=*** dst=*** sport=20200 dport=9629 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 148 src=*** dst=*** sport=45690 dport=20200 src=*** dst=*** sport=20200 dport=45690 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 148 src=*** dst=*** sport=3232 dport=20200 src=*** dst=*** sport=20200 dport=3232 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 115 src=*** dst=*** sport=50913 dport=20100 src=*** dst=*** sport=20100 dport=50913 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 11 src=*** dst=*** sport=8842 dport=20200 src=*** dst=*** sport=20200 dport=8842 mark=0 secmark=0 use=2 ipv4 2 udp 17 5 src=*** dst=*** sport=49009 dport=20200 src=*** dst=*** sport=20200 dport=49009 mark=0 secmark=0 use=2 ipv4 2 udp 17 154 src=*** dst=*** sport=8215 dport=20200 src=*** dst=*** sport=20200 dport=8215 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 143 src=*** dst=*** sport=1955 dport=20200 src=*** dst=*** sport=20200 dport=1955 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 146 src=*** dst=*** sport=61595 dport=20200 src=*** dst=*** sport=20200 dport=61595 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 160 src=*** dst=*** sport=25683 dport=20100 src=*** dst=*** sport=20100 dport=25683 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 162 src=*** dst=*** sport=33768 dport=20100 src=*** dst=*** sport=20100 dport=33768 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 136 src=*** dst=*** sport=3627 dport=20200 src=*** dst=*** sport=20200 dport=3627 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 132 src=*** dst=*** sport=41174 dport=20100 src=*** dst=*** sport=20100 dport=41174 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 udp 17 133 src=*** dst=*** sport=4585 dport=20100 src=*** dst=*** sport=20100 dport=4585 [ASSURED] mark=0 secmark=0 use=2

    -
    Edité par Benzouye 22 septembre 2018 à 15:23:23

    • Partager sur Facebook
    • Partager sur Twitter
      21 septembre 2018 à 18:07:32

      Bonjour,

      Dans un premier temps, je vais te demander d'anonymiser tes données. La présence d'adresses IP dans ton message n'est pas conseillée...

      Ensuite, il serait plus judicieux d'enregistrer pendant un court moment le trafic lors d'une attaque avec un logiciel comme Wireshark (disponible en cli pour les serveurs) pour traiter l'information (le fichier ne doit pas être partagé publiquement dans la mesure du possible pour éviter de fournir des données non anonymes).

      En gros, deux méthodes sont à suivre pour deux cas différents :

      • Si l'attaque provient d'une unique adresse IP, il suffit de configurer un outils pour détecter et traiter l'attaque (cf. ton moteur de recherche favori)
      • Si l'attaque provient de plusieurs adresses IP, il faut mettre en place des outils beaucoup plus conséquents (cf. ton moteur de recherche favori).

      Enfin, tu peux définir des règles spécifiques grâce au fichier .pcap de Wireshark en analysant le trafic légitime.

      -
      Edité par myrage21 21 septembre 2018 à 18:09:12

      • Partager sur Facebook
      • Partager sur Twitter
        26 septembre 2018 à 2:05:53

        Bonsoir,

        Je loue un VPS-4 - avec protection anti-DDoS: Minimal Shield chez pulseheberg, il y a un monitoring et quand une attaque survient le service est éteint par mesure de sécurité afin d'éviter que ce comportement anormal puisse avoir une incidence sur les données du service ou sur le reste de l'infrastructure.

        Le système de monitoring a remonté le comportement suivant : Trop de connexions simultanée (conntrack)
        Ce dernier n'ayant pas été suspendu, il m'invite à prendre les mesures nécessaires puis à re-démarrer le service via le panel de gestion.

        j'ai installer et configurer No More DDOS et j'ai suivi ce tuto

        https://www.abyssproject.net/2014/08/installer-configurer-no-more-ddos/

        J'ai aussi configuré UFW il était installé mais pas activé, iptables et fail2ban également.

        je voulais même interdire certain pays de ce connecter au serveur, après une recherche sur Google de l'adresse IP ça viendrait du pays Swede, j'ai bannis l'adresse IP avec iptables.

        ça n’arrêtent toujours pas ces connexions simultanée, j'ai l'impression que le monitoring bloc les attaques avant  le pare-feu installé sur le serveur, et sur les logs il n'y a rien d'anormal.

        le log que j'ai mis dans le premier post est un extrait du log des connexions réseau enregistrés au moment de l'alerte du monitoring.

        Je suis à cours d'idée, je me demande même si on peut stopper ce genre d'attaque.

        • Partager sur Facebook
        • Partager sur Twitter

        Attaques DDoS

        × Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
        × Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
        • Editeur
        • Markdown