La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux (usage serveur) => Discussion démarrée par: vivien le 24 mars 2019 à 16:06:19
-
Depuis quelques heures, j'ai régulièrement ce type de message sur le forum :
(https://lafibre.info/testdebit/ubuntu/201903_iptables_reject.png)
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 ?
-
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 (https://lafibre.info/tutoriels-linux/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
-
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...
-
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...
-
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)
(https://lafibre.info/images/stats/201903_ubuntu_apache_processes.png)
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.
-
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
-
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)
-
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... (https://lafibre.info/attaques/408-request-time-out/)
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
-
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 ?
-
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.
-
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...
-
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.
-
0x16 0x03 0x01 c'est un début d'un handshake TLS 1.0 (cf http://blog.fourthbit.com/2014/12/23/traffic-analysis-of-an-ssl-slash-tls-session).
Du coup en capturant le reste des données tu peux peut-être récupérer plus d'informations, mais pour récupérer la requête il faudrait que le serveur réponde au handshake.
Quelqu'un aurait configuré https://ubuntu.lafibre.info:80, un passage en https (par exemple via un script) d'une url qui spécifiait inutilement le port ?
-
Du https sur le port 80, bien vu.
Pourquoi ouvrir plus de 400 connexions simultanées aussi ?
Bref, il y a toujours des cas tordus sur près de 900 000 machines qui font leur mise à jour quotidiennement.
-
Peut-être plusieurs machines avec la même configuration sur un réseau d'entreprise (si la recherche de mise à jour se fait à heure fixe).
Mais étant donné qu'Apache doit rapidement terminer la connexion, c'est étonnant d'arriver à 400 connexions simultanées, sauf si le parc de machines est assez grand.
-
La recherche ne se fait pas à heure fixe, heureusement pour les serveurs ! (les veilles versions avaient une plage d 40 minutes de random pour les mises à jour tôt le matin mais ce n'est plus le cas avec les versions récentes)
Quand je limitait à 30 connexions simultanées, là j'ai vu des IP avec des grands parcs, il y a du trafic toute la journée (et on voit aux fichiers demandés qu'il y a différentes versions déployés)
-
J'ai réactivé hier de 7h à 22h les règles iptables pour limiter le nombre de connexion à 50 ouvertes simultanèment.
J'ai été moi même bloqué par cette limite alors que je surfait sur le forum, avec un seul PC (Ubuntu 19.04) et un seul navigateur (Firefox 66.0.3 64bits).
Voici son implèmentation :
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 50 -m limit --limit 2/min -j LOG --log-prefix="drop-c-"
/sbin/iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 50 -j REJECT
/sbin/ip6tables -A INPUT -p tcp --syn -m connlimit --connlimit-above 50 --connlimit-mask 64 -m limit --limit 2/min -j LOG --log-prefix="drop-c-"
/sbin/ip6tables -A INPUT -p tcp --syn -m connlimit --connlimit-above 50 --connlimit-mask 64 -j REJECT
Le manuel https://www.chedong.com/phpMan.php/man/iptables-extensions/8
explique pourtant :
connlimit
Allows you to restrict the number of parallel connections to a server per client IP
address (or client address block).
--connlimit-above n
Match if the number of existing connections is above n.
Examples:
# allow 2 telnet connections per client host
iptables -A INPUT -p tcp --syn --dport 23 -m connlimit --connlimit-above 2 -j
REJECT
J'ai récupéré les stats Apache que j'ai filtré sur mon IP pour voir ce que je faisais avant le blocage et compter les connexions (connexion 1 = la connexion ouverte juste avant le blocage), pour voir ou remonte les 50 connexions qui sont censées être ouvertes : Pour avoir 50 connexions ouverte, il faut toutes celles ouvertes la dernière demi-heure soient restées ouvertes !
Je n'ai fait que consulter ou éditer des messages dans une seule fenêtre et j'ai une connexion 100 Mb/s donc le chargement est rapide, bref pour moi c'est incompréhensible.
(https://lafibre.info/images/stats/201904_--connlimit-above_drop1.png)
Ce qui est sur fond blanc, ce sont les log Apache2
Ce qui est sur fond jaune, ce sont les stats iptables obtenues par la ligne journalctl -k | grep drop-c-
-
Un second exemple dans la soirée, là il faut cumuler 45 minutes de surf pour voir les 50 connexions sur mon forum.
Il est pourtant évident que les premières connexions ont été rapidement fermées.
(https://lafibre.info/images/stats/201904_--connlimit-above_drop2.png)
Voici le fichier LibreOffice Calc, lisible avec Excel : 201904_--connlimit-above_drop.ods (https://lafibre.info/images/stats/201904_--connlimit-above_drop.ods)
Je suis sur de ne pas avoir d'autres connexions sur le serveur, donc je ne comprends pas ce blocage.
-
Tes règles m'interpellent : tu cibles toutes les connexions, sans distinction de leur état.
Tu as tenté de spécifier seulement les "ESTABLISHED" ?
-
Je ne comprend pas bien pourquoi il fait gerer ca avec iptable.
nginx et php-fpm et je limite dans la conf nginx exactement à ce que je veux pour la vm...
-
donc les regles iptables fonctionnent bien c'est jusqu'il y a trop de connexions non fermées au bout d'un moment ? le souci est du coté d'apache donc ?
qu'indique l’état des connexions restantes ouvertes ? (avec "ss -iep" par exemple)