🚲 Tanguy Ortolo a écrit 12091 commentaires

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.

How can I fix my server, router or other device? You should upgrade tp NTP-4.2.7p26 or later.

Mauvaise idée. NTP 4.2.7 est une version de développement. En particulier, pour ceux qui attendent que cette version soit publiée dans Debian, oubliez cette idée : ça n'arrivera pas.

You can add disable monitor to your ntp.conf and restart your NTP process if on an earlier version.

Voilà, ça c'est la vraie solution avec la version stable de NTP. Malheureusement, ça désactive plus que seulement ce qui serait nécessaire, mais bon…

Diantre, le retour de pBpG, et quel retour ! Chapeau bas, c'était très bien exécuté !

Sans indication du codage, il y a tout de même une heuristique extrêmement simple pour utiliser un fichier texte, surtout un log :

1. c'est de l'ASCII (pour un log, c'est généralement le cas), ou au pire, c'est une extension de l'ASCII, les octets sortant de l'ASCII étant trop peu nombreux pour poser un problème si on doit les ignorer ;
2. si décidément, ce n'est pas de l'ASCII, c'est de l'UTF-8 ;
3. si ça contient des séquences qui sont invalides pour de l'UTF-8, c'est une extension mono-octets de l'ASCII, probablement du latin-9 dans un contexte francophone.

Effet : Artistic / Polygonize

Voilà un filtre amusant, qui essaye de transformer votre image en un ensemble de polygones de couleurs constantes, qui suivent plus ou moins les contours. Peut-être intéressant pour les créateurs de vitraux d'églises !

On trouve surtout des vitraux dans les églises, mais pas seulement : la mairie de Paris a quelques vitraux sur les métiers par exemple. En revanche, je doute que cette effet soit sérieusement utile aux créateurs de vitraux, dans la mesure où les vitraux classiques ne sont pas spécialement composés de polygones.

Pour ceux que la technique utilisée pour monter des vitraux intéresse, il y a dans le musée des monuments français, à la Cité de l'architecture à Chaillot, Paris, une excellente explication à ce sujet, avec des illustrations et des pièces qui permettent de très bien comprendre. Oui, c'est carrément hors sujet, mais c'était une occasion de parler ce musée que je trouve remarquable et que je vous recommande vivement, si vous avez quelques heures à perdre à Paris.

J'ai entendu un autre son de cloche, un jour. Quelqu'un qui s'était retrouvé avec journald, et qui avait besoin des logs de son serveur de courrier. Avec la commande appropriée, il lui a fallu trois heures pour récupérer quelques centaines de lignes.

Comment les programmes packagés (plus précisément, les services déclarés dans /etc) vont-ils faire être compatibles avec plusieurs systèmes d'init?

En fournissant plusieurs scripts ou descriptions, un par format de système d'init.

Sachant qu'être compatible avec SysV RC, c'est être, de façon minimale, compatible avec à peu près tous les systèmes de lancement de services puisque les systèmes de lancement de services en questions sont compatibles avec les scripts SysV !

Avec journald, ça doit être le cas oui, mais est-ce que ça affecte tous les logs, je ne sais.

Mon avis personnel : je n'aime pas systemd, qui bien qu'étant basé sur de très bonnes idées est à mon avis développé et promu de façon désagréable, avec ce qui m'apparaît comme une volonté hégémonique sournoise. Mais comme je le mentionne, il ne s'agit là que du choix d'init par défaut, et j'espère donc pouvoir continuer à utiliser l'init et les services SysV.