Messages récents

Pages: 1 2 [3] 4 5 6 7 8 ... 10
21
O THD + Orange (54 / 57) / Besoin de conseils.
« Dernier message par griselidi le Aujourd'hui à 13:48:10 »
Y a pas d'adsl dans le coin ?
C'est pas la faute de O THD si personne veut utiliser son infra.
Meme sur sa fibre. Après faut aussi voir que les gros opérateurs veulent pas voir un concurent de plus sortir.
22
Logiciels Logiciels / Attaques DDoS contre Threema - 14 août 2026
« Dernier message par lgom le Aujourd'hui à 13:43:26 »
Attaques DDoS contre Threema

Si vous utilisez régulièrement Threema, vous avez peut-être remarqué que le service était temporairement indisponible ou seulement partiellement accessible mardi soir et mercredi matin. Cela était dû à une série d'attaques DDoS. Ci-dessous, nous expliquons ce qui s'est passé et présentons les mesures que nous avons prises.

Qu'est-ce qu'une attaque DDoS ?

Lors d'une attaque par « Déni de Service » (DoS - Denial of Service), un attaquant envoie un nombre disproportionné de requêtes ou de paquets de données à un service en ligne afin de surcharger son infrastructure et de le rendre temporairement inaccessible aux utilisateurs.

Si l'attaque provient simultanément de sources multiples (et potentiellement changeantes), on parle d'attaque par « Déni de Service Distribué » (DDoS). Cela rend la défense nettement plus difficile, car il n'est pas possible de simplement bloquer une source unique.

Une attaque DoS vise uniquement la disponibilité d'un service en ligne, et non sa sécurité. Même si une attaque DoS réussit, les attaquants n'obtiennent aucun accès aux systèmes ni aux données.

Pour parler simplement, cela revient à une compétition de ressources entre l'attaquant et le fournisseur de services : l'attaquant tente de générer plus de trafic que l'infrastructure du fournisseur ne peut en traiter ou que ses mécanismes de protection ne peuvent en filtrer (c'est-à-dire intercepter). Dans le même temps, le fournisseur de services analyse l'attaque, ajuste ses mesures défensives et s'efforce de bloquer le trafic illégitime sans perturber les requêtes légitimes.

Comme les attaquants sophistiqués changent constamment de méthodes, de sources et de schémas d'attaque au cours de l'assaut, un jeu du chat et de la souris s'engage, où chaque partie réagit continuellement à la dernière action de l'autre.

Même avec une protection DDoS efficace, les interruptions temporaires ne peuvent pas toujours être entièrement évitées lors d'attaques impliquant de grands volumes de trafic et des schémas d'attaque qui évoluent rapidement. C'est d'autant plus vrai lorsqu'un attaquant dispose de ressources techniques et financières considérables, comme cela peut être le cas d'acteurs étatiques.

Les récentes attaques DDoS contre Threema
Comme la plupart des services en ligne, Threema fait l'objet d'attaques DDoS récurrentes. Dans la grande majorité des cas cependant, les utilisateurs de Threema ne remarquent (presque) rien car nos mécanismes de défense sont efficaces ou parce que nous nous adaptons si rapidement aux nouveaux schémas d'attaque que la perturbation de service qui en résulte est au pire très brève et généralement peu étendue (par exemple, seuls certains services individuels sont temporairement indisponibles ou le site web met plus de temps à charger).

Cette semaine toutefois, une série d'attaques DDoS de grande ampleur a ciblé Threema et notre partenaire d'hébergement (colocation), Nine. Il n'est pas tout à fait clair si Threema était la cible principale ou si les attaques visaient plusieurs cibles. Dans tous les cas, elles se sont poursuivies sur une longue période et leurs schémas ont été continuellement adaptés, ce qui a rendu la défense particulièrement difficile.

En raison de ces attaques, Threema a été indisponible le mardi entre 19h30 et 23h30 HAEC (CEST). La page fournissant des informations sur l'état actuel du système n'a initialement pas été mise à jour en raison d'un problème technique indépendant de l'attaque. Nous l'avons donc temporairement mise hors ligne jusqu'à ce que le problème soit résolu.

Le mercredi matin, les attaques se sont poursuivies et le jeu du chat et de la souris décrit ci-dessus a suivi son cours. Par conséquent, des interruptions de service brèves et intermittentes se sont produites tout au long de la matinée de mercredi. À 12h23, le fonctionnement normal avait été rétabli, et tous les services sont pleinement opérationnels depuis lors.

Mesures prises
Les interruptions de service ont été communiquées étape par étape sur nos réseaux sociaux, sur la base des informations disponibles à ce moment-là. Les clients professionnels utilisant Threema Work ont été informés par e-mail le mercredi matin de l'instabilité du service, et les chargés de compte ont fourni des informations sur la situation actuelle en réponse aux demandes.

Étant donné que les organisations utilisant Threema OnPrem s'appuient sur leur propre infrastructure, elles n'ont pas été affectées par cette vague d'attaques et ont pu utiliser leurs instances Threema OnPrem comme d'habitude à tout moment, sans aucune interruption.

Pour compléter nos mécanismes de défense existants, nous mettons en œuvre une protection DDoS spécialisée en tant que mesure supplémentaire. Celle-ci filtre le trafic d'attaque en amont, réduisant ainsi la charge sur notre propre infrastructure. Une fois les derniers tests de stabilité terminés – ce qui devrait être le cas dans les prochaines heures –, le mécanisme sera activé dans l'environnement de production.

Nous allons également enrichir la page de statut dans les prochains jours. La mise à jour inclura un historique des incidents ainsi qu'un flux RSS auquel les utilisateurs intéressés et les administrateurs de Threema Work pourront s'abonner afin de recevoir les mises à jour du système via un canal indépendant.

Nous nous excusons pour le désagrément occasionné et vous remercions de votre compréhension.


Source : Blog officiel Threema: https://threema.com/en/blog/outage-august-2026

Date de publication : 14 août 2026

Titre original : DDoS Attacks on Threema


threema, l'appli de messagerie qui va se faire connaitre à cause d'un DDOS ^^

à part qu'ils sont officiellement utilisés par certains corps militaires suisses, je dois admettre que je connais personne qui a cette appli, elle partage les mêmes inconvénients que l'écrasante majorité concurrentielle : propriétaire, chapelle fermée (non interopérable), dispo que sur mobile...
mieux ! elle est europ... enfin suisse ! et pour couronner le tout : elle est payante.
J'en ai entendu parler en 2024, jme disais qu'elle détrônerait avec difficultés le "olvid" imposé par le gouvernement, aux mêmes inconvénients.. même pas, les deux restent très marginaux.. et vu le marché, c'est pas si perturbant ;)
23
Logiciels Logiciels / Attaques DDoS contre Threema - 14 août 2026
« Dernier message par alf084 le Aujourd'hui à 13:42:26 »
L'article est intéressant, on y apprend entre autres que Threema a ses serveurs en colocation chez Nine : https://nine.ch/en/
24
Juste une idée comme ça, mais je me demande si c'est possible qu'OVH rejette certains paquets TCP avec une TTL "suspecte" ? Pour ces entrés que mtr te montre après 2a01:cb1d:6aa:b400:c2d7:aaff:fec0:f839, j'imagine qu'il est plus probable que les paquets soient en fait rejetés avant qu'ils n'atteignent 2a01:cb1d:6aa:b400:c2d7:aaff:fec0:f839.
25
Logiciels Logiciels / Attaques DDoS contre Threema - 14 août 2026
« Dernier message par alf084 le Aujourd'hui à 13:29:02 »
Attaques DDoS contre Threema

Si vous utilisez régulièrement Threema, vous avez peut-être remarqué que le service était temporairement indisponible ou seulement partiellement accessible mardi soir et mercredi matin. Cela était dû à une série d'attaques DDoS. Ci-dessous, nous expliquons ce qui s'est passé et présentons les mesures que nous avons prises.

Qu'est-ce qu'une attaque DDoS ?

Lors d'une attaque par « Déni de Service » (DoS - Denial of Service), un attaquant envoie un nombre disproportionné de requêtes ou de paquets de données à un service en ligne afin de surcharger son infrastructure et de le rendre temporairement inaccessible aux utilisateurs.

Si l'attaque provient simultanément de sources multiples (et potentiellement changeantes), on parle d'attaque par « Déni de Service Distribué » (DDoS). Cela rend la défense nettement plus difficile, car il n'est pas possible de simplement bloquer une source unique.

Une attaque DoS vise uniquement la disponibilité d'un service en ligne, et non sa sécurité. Même si une attaque DoS réussit, les attaquants n'obtiennent aucun accès aux systèmes ni aux données.

Pour parler simplement, cela revient à une compétition de ressources entre l'attaquant et le fournisseur de services : l'attaquant tente de générer plus de trafic que l'infrastructure du fournisseur ne peut en traiter ou que ses mécanismes de protection ne peuvent en filtrer (c'est-à-dire intercepter). Dans le même temps, le fournisseur de services analyse l'attaque, ajuste ses mesures défensives et s'efforce de bloquer le trafic illégitime sans perturber les requêtes légitimes.

Comme les attaquants sophistiqués changent constamment de méthodes, de sources et de schémas d'attaque au cours de l'assaut, un jeu du chat et de la souris s'engage, où chaque partie réagit continuellement à la dernière action de l'autre.

Même avec une protection DDoS efficace, les interruptions temporaires ne peuvent pas toujours être entièrement évitées lors d'attaques impliquant de grands volumes de trafic et des schémas d'attaque qui évoluent rapidement. C'est d'autant plus vrai lorsqu'un attaquant dispose de ressources techniques et financières considérables, comme cela peut être le cas d'acteurs étatiques.

Les récentes attaques DDoS contre Threema
Comme la plupart des services en ligne, Threema fait l'objet d'attaques DDoS récurrentes. Dans la grande majorité des cas cependant, les utilisateurs de Threema ne remarquent (presque) rien car nos mécanismes de défense sont efficaces ou parce que nous nous adaptons si rapidement aux nouveaux schémas d'attaque que la perturbation de service qui en résulte est au pire très brève et généralement peu étendue (par exemple, seuls certains services individuels sont temporairement indisponibles ou le site web met plus de temps à charger).

Cette semaine toutefois, une série d'attaques DDoS de grande ampleur a ciblé Threema et notre partenaire d'hébergement (colocation), Nine. Il n'est pas tout à fait clair si Threema était la cible principale ou si les attaques visaient plusieurs cibles. Dans tous les cas, elles se sont poursuivies sur une longue période et leurs schémas ont été continuellement adaptés, ce qui a rendu la défense particulièrement difficile.

En raison de ces attaques, Threema a été indisponible le mardi entre 19h30 et 23h30 HAEC (CEST). La page fournissant des informations sur l'état actuel du système n'a initialement pas été mise à jour en raison d'un problème technique indépendant de l'attaque. Nous l'avons donc temporairement mise hors ligne jusqu'à ce que le problème soit résolu.

Le mercredi matin, les attaques se sont poursuivies et le jeu du chat et de la souris décrit ci-dessus a suivi son cours. Par conséquent, des interruptions de service brèves et intermittentes se sont produites tout au long de la matinée de mercredi. À 12h23, le fonctionnement normal avait été rétabli, et tous les services sont pleinement opérationnels depuis lors.

Mesures prises
Les interruptions de service ont été communiquées étape par étape sur nos réseaux sociaux, sur la base des informations disponibles à ce moment-là. Les clients professionnels utilisant Threema Work ont été informés par e-mail le mercredi matin de l'instabilité du service, et les chargés de compte ont fourni des informations sur la situation actuelle en réponse aux demandes.

Étant donné que les organisations utilisant Threema OnPrem s'appuient sur leur propre infrastructure, elles n'ont pas été affectées par cette vague d'attaques et ont pu utiliser leurs instances Threema OnPrem comme d'habitude à tout moment, sans aucune interruption.

Pour compléter nos mécanismes de défense existants, nous mettons en œuvre une protection DDoS spécialisée en tant que mesure supplémentaire. Celle-ci filtre le trafic d'attaque en amont, réduisant ainsi la charge sur notre propre infrastructure. Une fois les derniers tests de stabilité terminés – ce qui devrait être le cas dans les prochaines heures –, le mécanisme sera activé dans l'environnement de production.

Nous allons également enrichir la page de statut dans les prochains jours. La mise à jour inclura un historique des incidents ainsi qu'un flux RSS auquel les utilisateurs intéressés et les administrateurs de Threema Work pourront s'abonner afin de recevoir les mises à jour du système via un canal indépendant.

Nous nous excusons pour le désagrément occasionné et vous remercions de votre compréhension.


Source : Blog officiel Threema: https://threema.com/en/blog/outage-august-2026

Date de publication : 14 août 2026

Titre original : DDoS Attacks on Threema
26
Que ce soit depuis chez moi ou depuis un VPS chez Hetzner, je ne vois rien d'anormal :

$ mtr 2a01:cb1d:6aa:b400::1 -6 -c 3 -brwz -T -P 443
Start: 2026-08-14T13:06:17+0200
HOST: meshify                                                              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS3215        livebox.home (XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX)   0.0%     3    0.9   1.1   0.9   1.2   0.2
  2. AS???         ???                                                     100.0     3    0.0   0.0   0.0   0.0   0.0
  3. AS???         ???                                                     100.0     3    0.0   0.0   0.0   0.0   0.0
  4. AS3215        2a01:cb1d:6aa:b400:c2d7:aaff:fec0:f839                   0.0%     3   12.8  12.9  12.8  13.1   0.2
  5. AS???         ???                                                     100.0     3    0.0   0.0   0.0   0.0   0.0

$ mtr 2a01:cb1d:6aa:b400::1 -6 -c 3 -brwz -T -P 443
Start: 2026-08-14T13:05:33+0200
HOST: bb1                                                                            Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    fe80::1                                                                 0.0%     3    3.3   3.5   3.3   3.8   0.2
  2. AS24940  11837.your-cloud.host (2a01:4f8:0:e0c0::2655)                           0.0%     3    0.7   1.4   0.7   2.7   1.1
  3. AS???    ???                                                                    100.0     3    0.0   0.0   0.0   0.0   0.0
  4. AS24940  spine7-rdev2.cloud1.nbg1.hetzner.com (2a01:4f8:cfff:1::f000:195)        0.0%     3    1.2   1.9   1.2   3.2   1.1
        spine7-rdev1.cloud1.nbg1.hetzner.com (2a01:4f8:cfff:1::f000:191)     
     AS24940  spine7-rdev1.cloud1.nbg1.hetzner.com (2a01:4f8:cfff:1::f000:191)
  5. AS24940  core-spine-rdev1.cloud1.nbg1.hetzner.com (2a01:4f8:cfff:1::f000:f069)   0.0%     3    0.8   1.0   0.8   1.3   0.3
        core-spine-rdev1.cloud1.nbg1.hetzner.com (2a01:4f8:cfff:1::f000:f061)
     AS24940  core-spine-rdev1.cloud1.nbg1.hetzner.com (2a01:4f8:cfff:1::f000:f061)
        core-spine-rdev2.cloud1.nbg1.hetzner.com (2a01:4f8:cfff:1::f000:f06d)
     AS24940  core-spine-rdev2.cloud1.nbg1.hetzner.com (2a01:4f8:cfff:1::f000:f06d)
  6. AS24940  core11.nbg1.hetzner.com (2a01:4f8:0:3::2a1)                             0.0%     3    0.8   1.0   0.7   1.4   0.3
        core12.nbg1.hetzner.com (2a01:4f8:0:3::2e1)                           
     AS24940  core12.nbg1.hetzner.com (2a01:4f8:0:3::2e1)
  7. AS24940  juniper5.dc2.nbg1.hetzner.com (2a01:4f8:0:3::22a)                       0.0%     3    0.8   3.2   0.8   7.9   4.1
        juniper5.dc2.nbg1.hetzner.com (2a01:4f8:0:3::22e)                     
     AS24940  juniper5.dc2.nbg1.hetzner.com (2a01:4f8:0:3::22e)
  8. AS1299   nug-b2-link.ip.twelve99.net (2001:2035:0:1e9f::1)                       0.0%     3    0.8   1.0   0.8   1.3   0.2
  9. AS1299   ffm-bb1-link.ip.twelve99.net (2001:2034:a:199::)                        0.0%     3   24.4  24.7  24.4  25.0   0.3
 10. AS1299   ffm-b5-link.ip.twelve99.net (2001:2034:a:171::1)                        0.0%     3    4.3   4.5   4.3   5.0   0.4
        ffm-b5-link.ip.twelve99.net (2001:2034:a:71::1)                       
     AS1299   ffm-b5-link.ip.twelve99.net (2001:2034:a:71::1)
 11. AS1299   orange-ic-325004.ip.twelve99-cust.net (2001:2035:0:13d9::2)             0.0%     3    5.1 687.6   4.8 2053. 1182.5
 12. AS???    ???                                                                    100.0     3    0.0   0.0   0.0   0.0   0.0
27
Si le problème de lag dans le jeu se fait ressemtir chez Sosh et Free, le problème ne vient certainement pas du NRO. as-tu des pertes de paquets quand tu fais le test vers le serveur de jeu ?
Non, je n'ai pas de pertes de paquet à l'arrivé quand je fait un test vers un serveur de jeu.

Bah deja on s'en fout c est vers 1.1.1.1 qui est même pas unique. Et pas vers la plateforme de jeux utilisée et qui serait problématique.

Y a jamais eu de route unique. Ni à l'allée ni au retour. Ni symétrique. Tout ça c'est un fonctionnement normal.

Si j'ai fait un test vers 1.1.1.1 c'est pour montrer qu'il y a un problème de réseau avec ma connexion car a l'arrivé il y a des pertes de paquet.

Une autre capture d'un test fait vers un serveur du jeu. J'ai mis les deux "hops 4" (twelve99 et level3) par lequel transite alternativement ma connexion vers le serveur du jeu. Là on voit très clairement la corrélation entre ces 2 routes sur la destination final. Quand ça passe par twelve99 sur la destination final j'ai 20ms de ping, quand twelve99 est rouge ou quand ça passe par level3 la destination final est de 12ms de ping. Maintenant si l'on compare ça a mes graph réseau que fourni le jeu on voit qu'il y a une correspondance entre le fait que tout au long d'une partie je passe de 4 barres 5 barres 4 barres ect à twelve99 level3 twelve99 ect. d'où mes lags h24 non?
28
Free Actus Free / mensualisation non stoppée
« Dernier message par vivien le Aujourd'hui à 12:29:48 »
+1 privilégier la portabilité qui permet une résiliation rapide (après dans ton cas avec une longue coupure, ce n'est pas simple, les personnes que je connais ont gardées leur abonnement, mais en demandant à être remboursé à cause de la coupure, normalement l'opérateur ne pose pas de pb, même si la coupure dure plusieurs mois).

Si ta résiliation n'a pas été prise en compte, comment as-tu fait pour récupérer le bon de retour mis à disposition dans l'Espace Abonné Freebox, pour renvoyer les équipements ?

Quand tu résilies, tu as le choix de résilier à la fin du mois ou dans 10 jours calendaire. Ensuite, tu as encore une facture avec les frais de résiliation.

Tu as regardé ce qui t'est facturé sur ta facture ?
29
reseau IPv6 / Baromètre IPv6 Arcep 2026
« Dernier message par simon le Aujourd'hui à 11:56:13 »
Vous savez sur vos firewall d'entreprise typique (fortinet, etc) si le NPTv6 est implémenté ? Adresser le LAN en ULA et faire du NPTv6 sur les préfixes des multiples liens WAN est quand même déjà une très bonne solution.
Oui, je n'utilise pas fortinet moi-même mais travaille avec des boîtes qui le font. Ca fait assez longtemps que forti sait faire du dual-WAN avec IPv6, même du load-balancing. Et là en effet ils font du NAT.

Citer
Certains d'entre vous on déjà déployé du v6 sur un LAN d'entreprise avec multi WAN ? C'est vrai que chez nous on se pose aussi la question.
Déjà fait, oui.
Pour les "petits" sites où il faut 2 liens pour redondance et qui se connectent à un site "principal" (type hub and spoke) c'est simple: les sessions VPN IPSec/wireguard/que sais-je peuvent transporter l'IPv6 sans souci. Les préfixes sur le LAN ne sont pas issus d'une allocation de l'ISP des deux liens (dont l'un peut être GP, d'ailleurs), mais d'une allocation plus large qui est portée par le site principal.
On peut changer un lien, voire même les deux, sans aucun impact sur le réseau interne.

Pour les sites autonomes ou ceux où l'on veut que le traffic sorte directement sur internet, le NAT66 fonctionne en effet pas mal.
J'ai fait des esais où j'adressais les VLAN internes avec le préfixe de l'un des deux opérateurs (fixe) et où je faisais du NPTv6 uniquement pour le traffic failover. Ca marche très bien et même mieux qu'avec ULA+dual stack (car dans ce cas les stations préfèrent IPv4), mais je ne connais pas de matériel qui fasse ca out of the box.

Personnellement, j'ai plusieurs VLAN d'accès v6-only avec DNS64/NAT64 et ca ne pose pas de souci.
Là où je me casse les dents, c'est les réseaux industriels où les constructeurs mettent "IPv6" sur la datasheet pour satisfaire les acheteurs (ou un mandat de l'administration américaine), mais qui ne le supportent soit pas, soit seulement en complément d'IPV4, donc inutile.


Ca, c'est pour la technique. Après, il y a les soucis des sysadmins... mais d'expérience, si tu prends une personne jeune et motivée par le réseau, tu n'as pas de souci à la former à IPv6. Par contre, les jeunes tout juste sortis de l'école te disent toujours "IPvQUOI? On a juste eu une slide dessus, c'est pour le futur" en 2026, tristesse.
30
Perso je n'ai rien compris.

Salut, messieurs.

@lgom : Oui il y'a tous les milliardaires et ex patron, PDG IT, business et pleins d'autres ; Et, il y a vous/nous les ingés ; c'est mieux que twitter pour ce genre de problèmes.

# pour la route jusqu'à Paris (Hostinger)
@acut3, @Symbol moi non plus ; je ne comprend pas comment "De OVH (Canada, Montreal) à Hostinger (France, Paris) je transit via MY LIVEBOX Orange_FR à la montagne dans ma maison de  Valdeblore pour repartir votre OVH  pour arriver à hostinger !!"

# ---

Plus sérieusement, il faut aller sur mon serveur canada et vérifier "le traceroute TCP sur port 443" jusqu'à chez moi "gate-fr (France, Valdeblore).

MTR :-: INFOS :-: SRV.🇨🇦.◕‿◕.ST : https://srv.xn--e77hd.xn--hwgz2tba.st/infos/my-traceroute/mtr-tcp_443.html

Sur cette page ci-dessus ; il faut cliquer sur le menu :

    ⛔🔜 root@srv-ca (Canada, Montreal, OVH)~ #

Dans le sous-menu ; il faut cliquer sur le menu :

        mtr to "gate-fr (France, Valdeblore, Orange_FR)"

        mtr to "hst-fr (France, Paris, Hostinger)"

ou de chez vous ; cette "route" je l'ai déjà.

# pour la route jusqu'à chez moi
Actuellement, dernier refresh - j'arrive à 30 Hop sur l'IPv6 mais ne voit pas ma "gateway" ET SURTOUT je part d'OVH arrivé au saut 17 .. je retourne à OVH (2607:5300:60:93ff:ff:ff:ff:f(f-d-e)) saut 25 je retourne à OVH (2607:5300:60:93ff:ff:ff:ff:f(f-d-e)) ; çà tourne en boucle.. et sans voir ; une de mes IPv6 d'Orange_FR sur AS3215 en IPv6.

# Ajout 12h40
C'est vraiment côté protocole Web ; les routes via ICMP me semblent correctes : https://SRV.CA.xn--hwgz2tba.st/infos/my-traceroute/mtr-traceroute.html - https://SRV.FR.xn--hwgz2tba.st/infos/my-traceroute/mtr-traceroute.html

# ----

Pour infos selon le protocole de communication les chemins peuvent différencier à travers le monde ; "Tracer le chemin sur le protocole HTTPS" permet d'identifier un possible attaquant ou homme du milieu qui espionnerait les requêtes et rendus Web ; en plus de vérifier la disponibilité du service sur le port en question et la couche IPv4 et/ou IPv6.

# ----

Comme vous disiez ; j'ai rien compris !
Pages: 1 2 [3] 4 5 6 7 8 ... 10