Auteur Sujet: Question iptables pour loguer les clients qui ont +30 connexion TCP simmultanées  (Lu 7758 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
Depuis quelques heures, j'ai régulièrement ce type de message sur le forum :


Je ne sais pas si c'est votre cas, mais je pense que c'est lié a la règles iptables suivante :
/sbin/iptables  -A INPUT -p tcp --syn -m connlimit --connlimit-above 30 -j REJECT
Le but est de limites une même IPv4 à 30 connexions TCP simultanées (la règles ne fonctionnais pas, je l'ai réparé aujourd'hui)

En ce moment je déactivé la règle.

La première étape pour la réactiver serait d'avoir des logs, mais des logs avec une limite pas trop élevée, afin de garantir de ne pas se retrouver avec des gros fichier, vu que j'ai mis le fichier de log dans le ramdisque :

J'ai un script qui est appelé au démarrage où je mets mes règles iptables :

nano /root/qos-iptables.sh
#!/bin/dash
# Limiter le nombre de sessions tcp par client (un client = une IPv4 ou un /64 en IPv6)
/sbin/iptables  -A INPUT -p tcp --syn -m connlimit --connlimit-above 30 -m limit --limit 60/min -j LOG --log-prefix="drop-c-"
/sbin/iptables  -A INPUT -p tcp --syn -m connlimit --connlimit-above 30 -j REJECT
/sbin/ip6tables -A INPUT -p tcp --syn -m connlimit --connlimit-above 30 --connlimit-mask 64 -m limit --limit 60/min -j LOG --log-prefix="drop-c-"
/sbin/ip6tables -A INPUT -p tcp --syn -m connlimit --connlimit-above 30 --connlimit-mask 64 -j REJECT

Pour lancer mon script au démarrage, je fais :
chmod +x /root/qos-iptables.sh
echo "# Application de la QoS au reboot" > /etc/cron.d/qos-iptables
echo "@reboot         root    /root/qos-iptables.sh" >> /etc/cron.d/qos-iptables


Je me demande si la bonne méthode est bien celle là avec :
- une ligne pour loger les connexions TCP au-delà des 30 simultanées autorisées pour une même IP avec une limitation à 40 lignes de log par minute
- une ligne identique qui rejette tous les paquets SYN des au-delà des 30 connexions TCP simultanées autorisées pour une même IP
Je double le tout pour IPv6 en considérant un /64 comme une seule entité.

Est-il possible de mettre deux fois l'argument -m dans une même ligne, comme j'ai fait ?

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
Il y a quelques mois, j'avais cette erreur très souvent, c'est pour ça que j'avais ouvert le topic connexion ethernet instable accusant ma carte réseau. Après avoir résolu le problème des résolutions DNS (qui était bien la partie la plus pénible), il restait toujours cette fameuse connexion échouée. Mais ça ne le faisait pas que sur le forum mais sur d'autres sites également.

Vu que tu l'observes aussi et au vu des règles iptables, difficile de dire si le problème est du côté serveur, client ou un mélange des 2.

Contre toute attente, depuis quelques semaines, je ne l'ai plus croisée ou alors j'arrive à l'éviter d'une manière ou d'une autre. Serait-ce aussi lié au kernel ? Tu a passé le serveur du forum en 4.18 ? De mon côté je suis toujours en 4.15

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
De mon coté la règle n'est resté que quelques heures actives.

Le serveur LaFibre.info est encore avec Ubuntu 16.04, donc Kernel 4.15.

Par contre j'ai la règle sur de nombreux serveurs Ubuntu 18.04 sans rencontrer de problèmes, mais je fais peut être moins de connexions vers ces autres serveurs.

D'où mon envie de monitorer la chose...

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
De mon coté la règle n'est resté que quelques heures actives.

Le jour de sa mise en place ou tu l'as re-désactivée après ta réparation du 24 ?

Enfin, dans un cas comme dans l'autre ça revient au même, et vu que le kernel n'a pas changé, difficile de dire si c'est lié.

En tout cas, je suis bien content de ne plus l'avoir. Ça devenait relou à force...

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
En fait j'avais fait une erreur de débutant quand j'ai mis les régles il y a deux ans : j'ai mis iptables sans spécifier le chemin (il faut mettre /sbin/iptables ).
Cela ne fonctionnait donc pas.

Sur d'autres serveurs, on voit bien l'effet, l'activation a été fait à l'endroit où j'ai mis la barre rouge : (ci-dessous le serveur de mis à jour Ubuntu)


Pour le serveur lafibre.info c'est l'unique changement donc je suis persuadé que le pb rencontré est lié à al règle, d'où le besoin de + monitorer la chose.

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
J'ai mis en place les logs comme décrit, cela fonctionne bien.

Pour consulter les logs : journalctl -k | grep drop-c-

Voici ce que cela donne (j'ai juste remplacé le dernier octet de l'adresse IP par x) :

avril 07 17:28:51 ubuntu kernel: drop-c-IN=enp2s0f0 OUT= MAC=3c:fd:fe:1a:1d:e0:84:26:2b:c6:6f:18:08:00 SRC=81.50.121.xx DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=15945 DF PROTO=TCP SPT=33263 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 17:28:51 ubuntu kernel: drop-c-IN=enp2s0f0 OUT= MAC=3c:fd:fe:1a:1d:e0:84:26:2b:c6:6f:18:08:00 SRC=81.50.121.xx DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=12818 DF PROTO=TCP SPT=33274 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 17:39:57 ubuntu kernel: drop-c-IN=enp2s0f0 OUT= MAC=3c:fd:fe:1a:1d:e0:84:26:2b:c6:6f:18:08:00 SRC=193.49.116.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=30786 DF PROTO=TCP SPT=57506 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 17:48:27 ubuntu kernel: drop-c-IN=enp2s0f0 OUT= MAC=3c:fd:fe:1a:1d:e0:84:26:2b:c6:6f:18:08:00 SRC=37.71.114.xx DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=57578 DF PROTO=TCP SPT=42584 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 17:51:06 ubuntu kernel: drop-c-IN=enp2s0f0 OUT= MAC=3c:fd:fe:1a:1d:e0:84:26:2b:c6:6f:18:08:00 SRC=92.134.126.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=24377 DF PROTO=TCP SPT=36510 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 18:00:35 ubuntu kernel: drop-c-IN=enp2s0f0 OUT= MAC=3c:fd:fe:1a:1d:e0:84:26:2b:c6:6f:18:08:00 SRC=154.245.36.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=47 ID=55231 DF PROTO=TCP SPT=55514 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 18:00:36 ubuntu kernel: drop-c-IN=enp2s0f0 OUT= MAC=3c:fd:fe:1a:1d:e0:84:26:2b:c6:6f:18:08:00 SRC=154.245.36.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=47 ID=55232 DF PROTO=TCP SPT=55514 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 18:00:38 ubuntu kernel: drop-c-IN=enp2s0f0 OUT= MAC=3c:fd:fe:1a:1d:e0:84:26:2b:c6:6f:18:08:00 SRC=154.245.36.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=47 ID=55233 DF PROTO=TCP SPT=55514 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 18:00:42 ubuntu kernel: drop-c-IN=enp2s0f0 OUT= MAC=3c:fd:fe:1a:1d:e0:84:26:2b:c6:6f:18:08:00 SRC=154.245.36.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=47 ID=55234 DF PROTO=TCP SPT=55514 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 18:00:50 ubuntu kernel: drop-c-IN=enp2s0f0 OUT= MAC=3c:fd:fe:1a:1d:e0:84:26:2b:c6:6f:18:08:00 SRC=154.245.36.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=47 ID=55235 DF PROTO=TCP SPT=55514 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 18:01:49 ubuntu kernel: drop-c-IN=enp2s0f0 OUT= MAC=3c:fd:fe:1a:1d:e0:84:26:2b:c6:6f:18:08:00 SRC=91.219.68.xx DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=46 ID=27223 DF PROTO=TCP SPT=4591 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0

Sur le serveur Ubuntu, je vais augmenter la limite de 30 connexions simultanées par IP à 100 connexions simultanées, car elle est régulièrement dépassé et j'ai un doute sur le fait que tout illégitime.

J'attends un peu avant de le remettre en place sur lafibre.info

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
Autre chose étonnant, dans ces log, tous issues de la même IPv4, dans une durée restreinte, les flag ne sont pas systématiquement les mêmes : SYN URGP=0  vs CWR ECE SYN URGP=0  :

avril 07 17:05:03 37.165.139.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=37308 DF PROTO=TCP SPT=6791 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 17:05:03 37.165.139.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=19863 DF PROTO=TCP SPT=6789 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 17:05:11 37.165.139.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=56975 DF PROTO=TCP SPT=6828 DPT=80 WINDOW=29200 RES=0x00 CWR ECE SYN URGP=0
avril 07 17:05:11 37.165.139.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=51091 DF PROTO=TCP SPT=6827 DPT=80 WINDOW=29200 RES=0x00 CWR ECE SYN URGP=0
avril 07 17:05:11 37.165.139.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=26079 DF PROTO=TCP SPT=6829 DPT=80 WINDOW=29200 RES=0x00 CWR ECE SYN URGP=0
avril 07 17:05:12 37.165.139.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=61186 DF PROTO=TCP SPT=6830 DPT=80 WINDOW=29200 RES=0x00 CWR ECE SYN URGP=0
avril 07 17:05:12 37.165.139.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=46213 DF PROTO=TCP SPT=6831 DPT=80 WINDOW=29200 RES=0x00 CWR ECE SYN URGP=0
avril 07 17:05:13 37.165.139.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=55950 DF PROTO=TCP SPT=6823 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 17:05:15 37.165.139.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=55951 DF PROTO=TCP SPT=6823 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 17:05:17 37.165.139.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=60136 DF PROTO=TCP SPT=6640 DPT=80 WINDOW=29200 RES=0x00 CWR ECE SYN URGP=0
avril 07 17:05:18 37.165.139.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=45660 DF PROTO=TCP SPT=6815 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 17:05:19 37.165.139.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=42899 DF PROTO=TCP SPT=6846 DPT=80 WINDOW=29200 RES=0x00 CWR ECE SYN URGP=0
avril 07 17:05:21 37.165.139.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=2988 DF PROTO=TCP SPT=6850 DPT=80 WINDOW=29200 RES=0x00 CWR ECE SYN URGP=0
avril 07 17:05:22 37.165.139.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=42901 DF PROTO=TCP SPT=6846 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 17:05:24 37.165.139.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=61564 DF PROTO=TCP SPT=6868 DPT=80 WINDOW=29200 RES=0x00 CWR ECE SYN URGP=0
avril 07 17:05:26 37.165.139.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=55751 DF PROTO=TCP SPT=6874 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 17:05:26 37.165.139.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=8691 DF PROTO=TCP SPT=6867 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 17:05:28 37.165.139.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=37503 DF PROTO=TCP SPT=6851 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 17:05:30 37.165.139.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=25932 DF PROTO=TCP SPT=6534 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 17:05:31 37.165.139.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=26640 DF PROTO=TCP SPT=6872 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 17:05:32 37.165.139.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=22001 DF PROTO=TCP SPT=6645 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 17:05:34 37.165.139.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=22302 DF PROTO=TCP SPT=6617 DPT=80 WINDOW=29200 RES=0x00 CWR ECE SYN URGP=0
(note j'ai troqué ce qu'il y a entre l'heure et l'IP source)

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
Vraiment intéressant ces logs, je m’aperçois que toutes les IP qui dépassent 30 connexions simultanées sur le serveur de mise à jour Ubuntu sont des usages légitimes : ce sont des IP chez Completel ou Renater (Universite Rene Descartes par exemple) avec des centaines de serveurs derrière.

J'ai regardé dans les IP qui dépassent 30 connexions simultanées: aucune n'a réalisés de requêtes "HTTP 408 (Request Time-out)" dont je parlait dans le sujet Si vous voyez des codes HTTP 408 (Request Time-out) dans vos log Apache2, vous vous posez peut-être la question de ce que c'est...

J'ai donc augmenté la limite de 30 à 400 connexions simultanées.

Commandes pour vérifier que tout est bien en place :

IPv4 : iptables -L
# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
LOG        tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN #conn src/32 > 400 limit: avg 1/sec burst 5 LOG level warning prefix "drop-c-"
REJECT     tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN #conn src/32 > 400 reject-with icmp-port-unreachable

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination       
 

IPv6 : ip6tables -L
# ip6tables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
LOG        tcp      anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN #conn src/64 > 400 limit: avg 1/sec burst 5 LOG level warning prefix "drop-c-"
REJECT     tcp      anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN #conn src/64 > 400 reject-with icmp6-port-unreachable

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
Chez moi c'est revenu hier mais que deux fois. Y'a une condition particulière pour atteindre les 30 connexions ? Car je n'avais que 2 pages du forum ouvertes à ce moment là.

Quand ça se produit, il semble que je n'ai aucun paquet envoyé. Enfin, vu que je n'ai pu le voir qu'une seule fois (et c'était il y a un bon moment déjà) c'était peut-être aussi une mauvaise config de wireshark en filtrant les paquets... je ne m'en rappelle plus très bien.

Y'a moyen de monitorer quelque chose côté client ?

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
Sur le forum je n'ai pas encore remis de limite, c'est donc complètement autre chose.

Je pense mettre 50 connexions simultanés et non pas 30.

Je ferais signe quand cela sera mis en place et avec les logs, je ne risque pas de laisser une condition trop faible.

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
Ah ok.

L'autre fois, j'ai pensé que ça pouvait venir de la version de firefox. J'ai passé quelques heures sous debian sid avec la version ESR (60.6) et j'ai eu droit à l'erreur. Mais vu que ça me l'a refait 2 jours plus tard avec la 66 sur ubuntu, j'ai dit non c'est pas ça...

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
5 IPv4 se sont fait flashées cette nuit en dépassant 400 connexions TCP ouvertes et ce sont tous des usages tordus comme une Ubuntu 11.04 qui fait pleins de requêtes brutalement - pas top d'avoir toujours des serveurs avec Ubuntu 11.04, qui n'est plus pris en charge depuis 2012.

Pour certains, j'ai ce type de log dans Apache : (là impossible de savoir si c'est un Ubuntu qui fait ces requêtes)
193.191.241.x 52164 80 [07/Apr/2019:23:43:51 +0200] "\x16\x03\x01" 400 0 "-" "-"
193.191.241.x 55236 80 [07/Apr/2019:23:45:18 +0200] "\x16\x03\x01" 400 0 "-" "-"
193.191.241.x 10762 80 [07/Apr/2019:23:45:25 +0200] "\x16\x03\x01" 400 0 "-" "-"
193.191.241.x 46058 80 [07/Apr/2019:23:46:05 +0200] "\x16\x03\x01" 400 0 "-" "-"
193.191.241.x 14984 80 [07/Apr/2019:23:47:12 +0200] "\x16\x03\x01" 400 0 "-" "-"
193.191.241.x 33594 80 [07/Apr/2019:23:47:48 +0200] "\x16\x03\x01" 400 0 "-" "-"
193.191.241.x 4626 80 [07/Apr/2019:23:47:52 +0200] "\x16\x03\x01" 400 0 "-" "-"
193.191.241.x 15960 80 [07/Apr/2019:23:48:05 +0200] "\x16\x03\x01" 400 0 "-" "-"
193.191.241.x 15686 80 [07/Apr/2019:23:48:11 +0200] "\x16\x03\x01" 400 0 "-" "-"
193.191.241.x 25780 80 [07/Apr/2019:23:48:15 +0200] "\x16\x03\x01" 400 0 "-" "-"
193.191.241.x 60806 80 [07/Apr/2019:23:48:20 +0200] "\x16\x03\x01" 400 0 "-" "-"
193.191.241.x : IP source
60806 : port TCP source
80 : port TCP destination
"\x16\x03\x01" c'est la requête qui est normalement du type "GET /page.html HTTP/1.1"
400 c'est le code "400 Bad Request" : La syntaxe de la requête est erronée.
Le 0 qui suit c'est la taille : 0 octet échangé
"-" "-" c'est le referer et le user-agent qui ne sont bien sur pas renseigné

Bref, je suis satisfait de mon réglage.