I would like but i’m not able to sync my nodes anymore.
Ğ1 is down.
If I restart my GVA node via docker, it’s start responding but in few minutes stop responding (without nothing suspicious in the logs).
I just saw now that my Duniter v1 node (g1.brussels.ovh) had issues last night, and so did all others linked in Ginspecte.
Between 04/08/2025 22:10:45 (UTC) and 05/08/2025 00:39:37 (UTC).
So I guess there is nothing I could do to prevent that in the future ? (in my node configuration or …)
Edit: I just saw this post mentionning it might have been a DOS attack:
No.
(.astro) pi@libra:~/.zen/tmp$ août 05 22:14:23 libra.copylaradio.com python[384441]: 2025-08-05 22:14:23,165 - INFO - Rate limiter cleanup: removed 1 IPs, 0 active IPs
On peut implémenter un “Rate Limiter” dans le serveur (celui de UPlanet est limité à 12 requêtes API par minutes), ou bien configurer fail2ban pour détecter l’intrus et bloquer son IP
Tu peux mais c’est inutile.
1 requête toutes les 2 minutes suffit.
Un autoVPN bypass ça sans problème.
Pour Duniter v1, il faudrait une règle de 2 ou 3 requêtes toutes les 15mn.
Pour Duniter v2, 1 requête toutes les 3 secondes… Moins facile de jouer sur le “rate limiter”
En tout cas c’est intéressant de se pencher la dessus…
Avec une surcouche de sécurité déployée avec Duniter, je pense qu’on peut améliorer la résistance de l’essaim aux attaques.
Pour le VPN (qui change d’IP tout le temps), il faudrait une “grey/black list” des IP qui transitionnent trop que l’essaim se partage pour ajuster ensemble leur fail2ban (DEFCON4)… Ensuite pouvoir passer en DEFCON3 pour activer un VLAN (Wireguard) entre les noeuds duniter pour qu’ils continuent à se causer pendant la saturation. Ensuite si ça chauffe trop… On pourrait activer le DEFCON2 qui consiste à scruter les ports des attaquants pour y découvrir des failles puis DEFCON1 retourner l’attaque aux assaillants… de Blue à Red Team…
Qui veux qu’on essaye de blinder un peu mieux nos Duniter ?
- Blue Team
- Red Team
0
voters
We should ask @kalimheros (here) and @Frederic_Renault to fix it. Should be ok.
But not sure anybody care.
I care! Tons of people care!
Everyone who has a little bit of vision and a heart (everyone that matters) cares!
Great stuff is being co-created here thanks to the work of each and everyone.
And you guys are doing an absolutely awesome work!
Just keep having faith in the coming weeks and months.
Great things are coming for you and everyone, I can feel it…
You’ll see! 
A new Duniter Node v1.9 GVA is born today ! Juste for @vjrj and his Ginkgo 
Thanks indeed @joss.rendall 
For some reason the /gva endpoint doesn’t work in your node. Is maybe a proxy issue? See:
https://g1.guenoel.fr/gva
https://duniter-v1.comunes.net/gva
vs:
@vjrj Works better ??
@vjrj are you expecting ssl/tls working on port 443 only ?
my node is running gva on port 44444 but is reported down in ginkgo (44444 port is not displayed in the info panel)
Thanks
Thanks, it will work in the next release.
Anyway, there is an issue with your cert, accessing, for instance:
https://g1v1.taeksheald.fr:44444/network/peers
Gives net::ERR_CERT_AUTHORITY_INVALID.
This is a typical error from 1.9 nodes. From time to time, the GVA part gets out-of-sync, and we need to reset the node again 
.
It’s just says my certificate is not delivered by a known authority but it is autosigned