🚲 Tanguy Ortolo a écrit 12224 commentaires

À ta place, plutôt qu'IRC, j'utiliserais XMPP. L'intérêt, c'est que c'est conçu pour être fédéré, ce qui laisse une chance aux petits serveurs. Avec IRC, qui a été pensé pour un réseau unique comme Usenet, mais qui contrairement à ce dernier, a explosé, les réseaux sont disjoints, les gros survivent et les petits n'ont aucune chance.

Bof, il reste encore plein de personnages. Même dans Toy Story 1, il en reste encore qui n'ont pas été utilisés.

Bah, le webmail étant une solution de secours pour quand on n'a pas de vrai client de messagerie sous la main  …

À ta place, j'éviterai d'utiliser une base de données : ça apporte de la complexité sans grand avantage, sauf besoins très, très spécifiques et bien identifiés.

Que c'est largement plus que nécessaire. 100 utilisateurs, ce n'est rien du tout et ça pourrait tourner sur bien moins que ça.

Mon Dieu, l'argument débile… Dépendance sur le DNS : genre ce n'est pas déjà largement le cas… Cas où les ports différents du 80 et du 443 sont bloqués : il suffit de recommander l'usage de ces deux ports…

Non. Une répartition de charge est possible de cette façon, quoique manquant sérieusement de souplesse, en revanche cela ne permet absolument pas de fournir une redondance.

S'ils ne l'ont pas fait, c'est encore plus décevant que je ne pouvais l'imaginer.

Sauf si je loupe vraiment qqchose

Tu dois vraiment louper quelque chose. Si je cherche à charger une page http://example.com/sarass , je demande les enregistrements DNS _http._tcp.example.com. Si j'obtiens cette réponse :

_http._tcp.example.com. SRV 10 70 80 toto.example.com.
_http._tcp.example.com. SRV 10 30 80 titi.example.com.
_http._tcp.example.com. SRV 20 70 80 tata.example.com.

Je vais pouvoir :

1. essayer de me connecter sur l'un des serveurs de priorité 10, au hasard selon leurs poids respectifs, donc :
   1. tirer un nombre aléatoire entre 0 inclus et 100 exclus ;
   2. s'il est inférieur ou égal à 70, me connecter au serveur toto.example.com. sur le port TCP 80 ;
   3. s'il est strictement supérieur à 70, me connecter au serveur titi.example.com. sur le port TCP 80 ;
2. se cette première tentative échoue, essayer de me connecter sur le serveur de priorité 20.

On a donc là deux choses :

1. de la répartition de charge, puisque, de façon aléatoire pondérée, les clients vont se connecter sur un serveur ou l'autre : aujourd'hui, pour faire la même chose on met plein d'enregistrements DNS A et AAAA, en pondérant à coup de répétitions… ;
2. de la redondance, puisque, si la tentative de connexion à un serveur de haute priorité a échoué, on essaie les priorités plus basses : aujourd'hui, pour faire la même chose on met des dispositifs dédiés qui constituent aux-mêmes des SPOF, qu'on double éventuellement mais la connexion à Internet reste toujours un SPOF, qu'on ne peut éventuellement contourner qu'en faisant du routage BGP, ce qui n'est vraiment pas à la portée de tout le monde.

Moi, ce qui m'agace surtout avec HTTP2, c'est qu'ils ont laissé tomber l'idée d'utiliser des enregistrements SRV pour fournir une redondance et une répartition de charge simple. HTTP reste trop fossilisé pour évoluer vraiment, en somme.

Vraiment lointaine alors, parce qu'à ce compte-là, on peut aussi considérer ça comme une variante éloignée des nems, tant qu'à faire.

Ça a l'air bon, mais je trouve qu'il manque quelques précisions.

Pour réaliser les momboloni, il faut:

• de minces lamelles de porc.

Des lamelles de quoi de porc ? Du lard ?

1. faire chauffer l'huile dans une poêle.
2. étaler les lamelles de porc.

Vu la suite, il doit s'agir de les étaler sur un plan de travail, pas de les faire cuire tout de suite, tu confirmes ?

1. mettre la charcuterie sur les lamelles.

Empiler des tranches de jambon de porc sur d'autres tranches de porc en somme.

1. saupoudrer de parmesans.
2. rouler les lamelles et les maintenir avec un ou deux cure dents.
3. faire cuire à la poêle quelques minutes en les tournant régulièrement.

Faire cuire avec les cure-dents ? En mettant ces rouleaux avec le cure-dent à l'horizontale du coup, c'est ça ?

Avec les deb, les dépendances sont des paquets donc si tu dépend de java-truc et que sur une autre distrib, le même contenu est appelé truc-java, ben c'est foutu, tu dois modifier/forker ton paquet,, alors qu'en RPM, tu dis juste que tu as besoin de /usr/bin/java est c'est bouclé. Et en plus, pour les bibliothèques rpm passe un coup de ldd pour en déduire ce dont tu as besoin, donc t'as même pas à les lister à la main.

Alors, ça peut se faire avec le format de paquet Debian. C'est du niveau gourou, mais ça peut se faire : il faut pour ça générer le fichier debian/control plutôt que de le fournir directement, en utilisant apt-file search pour trouver les paquets fournissant tel fichier. Ça implique de build-dépendre de apt-file, c'est tordu, pas franchement élégant, mais ça doit pouvoir se faire.

Et je rejoints Zenitram, 2 formats pour faire le même job (parce que fondamentalement, je ne vois pas de raison autre qu'historique à avoir 2 espèces de tar+dépendances, et c'est pénible.

Archive, dépendances et scripts d'installation et de désinstallation. Vous pouvez blâmer RedHat, parce que ce sont eux qui ont fait un nouveau format au lieu d'utiliser celui de Debian qui existait déjà quelques années.

Et en plus, pour les bibliothèques rpm passe un coup de ldd pour en déduire ce dont tu as besoin, donc t'as même pas à les lister à la main.

Alors, info exclusive : debhelper, l'outil le plus utilisé pour les règles de constructions de paquets Debian, fait la même chose.

Depuis localhost, évidemment, mais pas depuis le reste du monde, donc non, ta configuration n'est pas vulnérable.

Ce que tu avais modifié ta configuration pour retirer la restriction noquery, la rendant ainsi vulnérable.

C'est inutile, le fichier de configuration par défaut n'est pas vulnérable à cela.

Oui, la derniere version de NTP sous debian est a reconfigurer.

Pas forcément. La configuration par défaut sous Debian n'est pas vulnérable à cette attaque (ou plutôt, ne permet pas de servir de rebond pour cette attaque, comme vous l'aurez compris). En revanche, les configurations modifiées, où la restriction noquery a été enlevée, sont vulnérables.

Sauf qu'encore une fois, systemd et journald n'ont pas et n'ont jamais eu de vocation à l'universalité.

Surtout que, systemd n'a jamais eu de vocation à prendre en charge quoi que ce soit d'autre que Linux.

Donc on a :

• ASCII et UTF-8 : pris en charge partout ;
• format binaire de journald : pris en charge sur Linux, sans vocation à l'universalité.

Parce que la, la personne qui se plaint est la même qui dirait il y a 10 ans que le log est en UTF-8 (un nouveau format binaire) et que son logiciel dans son mode rescue ne lit que Latin-1 (un autre format binaire), et qu'on aurait dû rester en Latin-1 à cause de ça. Avec ce genre d'argument, on n'avance jamais. Bref, conneries.

Non, ça c'est des conneries. Les logs, c'est essentiellement de l'ASCII, les caractères hors de l'ASCII y sont largement minoritaire. Avec un logiciel qui interprète tout comme du latin-1, c'est à la rigueur moche, mais pas du tout inutilisable.

Pour combien de temps ? Je me méfie des promesses de Lennart Poettering, du genre « non non, ne vous inquiétez pas, udev est maintenu dans le dépôt de systemd mais il n'en dépendra jamais ».

Concernant les raisons, j'ai du mal à croire qu'une organisation "s'amuserait" à lancer du 500GBit/s juste comme ça, pour voir.

Ça tombe bien, personne ne fait ça. Il s'agit d'attaques par amplification, où l'attaquant envoie des paquets spécialement conçus à un débit relativement faible, et où le serveur utilisé comme rebond répond avec des paquets beaucoup plus gros et donc à un débit plus élevé en destination de la cible de l'attaque.

Et au sujet des sources de DDOS avec spoof, je suis curieux de savoir pourquoi les fabricants de routeurs/FW n'aggrègent pas les logs en big data pour retrouver ce genre d'infos. Une machine zombie dans son réseau qui va taper des NTP avec une @IP source différente de celle de son réseau d'origine ça devrait se tracker facilement.

Effectivement, le fournisseur d'accès de l'attaquant pourrait détecter son attaque, à supposer que ça l'intéresse et il ait le droit et la capacité de procéder à ce genre de vérification sur le trafic. Mais comme la cible de l'attaque n'a aucun moyen de savoir d'où provient l'attaque, elle ne pourra pas demander à ce FAI.

Je pense que l'argument était que le texte était un format standard, tout comme la compression gzip, tandis que le format de journald n'avait rien d'un standard.