Introducing Shame as a Service!

No, we're not talking about Software as a Service; we're talking about "Shame as a Service". In the technology-driven world, where SaaS platforms solve complex business problems, we've innovated a new kind of service aimed squarely at solving a critical internet problem, the lack of IPv6 adoption.

Un article intéressant qui expliquent qu’une solution purement technologique concernant le contrôle parental n’est pas la solution.
Pour information, ils savent de quoi ils parlent car ils sont justement « experts de justice en (sécurité) informatique » (source : leur site professionnel esplori.pro), dans des affaires cybercriminelles liées à la pédocriminalité.

Note (Français/French) : cet article est une aide mémoire sur l’utilisation de nftables nft, toutefois par habitude je l’ai rédigé en anglais, je m’en suis rendu compte un peu tard, juste avant publication pour quelque chose qui allait être en privé.

Note: this article is just a reminder how to use some nftables instructions.

Use option --handle/-a for displaying handles, which are required for deleting or for insertion for examples.

Create chain, named banned for example, but don’t use hook and priority:

nft create chain inet filter banned

Before it can be inserted, look for the handle to insert before, for example in the main chain INPUT from the table filter from the inet (IPv4 + IPv6) family:

nft --handle list chain inet filter INPUT

Note: it is possible to look through the whole table with this command nft --handle list table inet filter, but then all its chains are also displayed.

Add a jump statement to this newly created chain with the handle previously acquired from above command (replace "${HANDLE}"):
Notes:

• this command adds a comment, it is only to display with list actions;
• the double quotes are required for multiple worded comment, so when invoking nft, use single quotes or escape characters.

nft insert rule inet filter INPUT handle "${HANDLE}" jump banned comment '"lookup on the banned list"'

Now there is a jump statement to this newly chain, however the later is empty after creation.
Here how to add an IP address, either IPv4 or IPv6, or even a range, in this list, with a drop action:
Note: so see a number of packets, the counter statement is added

nft add rule inet filter banned ip saddr "${IP_ADDR_OR_RANGE}" counter drop

Same than previously, here how to display banned IP addresses, with their dedicated counters:

nft --handle list chain inet filter banned

It is also possible to allow an IP address, just replace the drop action by accept; however, because computation is done once a rule is matching, it is almost always better to insert a rule, nft insert rule […] instead of nft add rule […], so it appears at the top of the target chain:

nft insert rule inet filter banned ip saddr "${IP_TO_ALLOW}" counter accept

Via Sebsauvage https://sebsauvage.net/links/?ivD4dg

« Astuce :
Les numéros débutant par :

• 01 99 00
• 02 61 91
• 03 53 01
• 04 65 71
• 05 36 49
• 06 39 98

sont prévus pour les fictions audiovisuelles et ne peuvent pas être attribués, affichés comme numéros appelants ou appelés. »

Quelques rappels sur le fonctionnement des redirections de ports avec SSH à l’aide d’images.

En français, avec quelques explications et l’introduction de la « redirection de port locale et « dynamique » au niveau applicatif » (-D [bind_address:]port, voir ssh(1)), ou plus simplement un « proxy SOCKS » : https://blog.hugopoi.net/2021/01/01/ssh-port-forwarding-par-lexemple/

J’en profite pour rajouter quelques infos, je vous conseille de jeter un œil sur l’option GatewayPorts dans sshd_config(5), car par défaut (version 8.4 actuellement) cette option est sur no, et donc force les redirections en locale uniquement (ce qui est plutôt une bonne chose).
Ainsi, pour laisser le choix aux clients ssh, il suffit de renseigner la valeur clientspecified dans votre configuration (mais attention aux conséquences).

Article très détaillé et très bien expliqué sur la mise en place d'un service DoT et DoH (respectivement DNS over TLS et DNS over HTTPS) et sur son fonctionnement, avec en prime des outils pour vérifications, analyse, suivi de l'état du système.
Merci encore à Bortzmeyer.

Vu sur FRnOG.

(Article en anglais)

Et voilà, une seule erreur, et c’est la catastrophe pour tout le monde ! Pourquoi ? parce que c’est le genre de risques qu’il y a avec tous ces services super centralisés.
Aujourd’hui, la flemme de décrire la faille (j’écris surtout pour garder les liens), mais en gros, ça s’appelle "CloudBleed", car ça a le même soucis que HeartBleed, c’est une zone mémoire prise aléatoirement.

En français, sur NextINpact : https://www.nextinpact.com/news/103421-cloudbleed-importante-fuite-donnees-chez-cloudflare-changez-vos-mots-passe.htm
En français, sur LinuxFR : https://linuxfr.org/users/pied/journaux/ho-la-belle-prise-chez-cloudflare
En anglais : https://bugs.chromium.org/p/project-zero/issues/detail?id=1139

Très intéressant comme produit, à voir ça de plus près.

Hé ben, on n’est pas dans la mélasse …
Encore plus de Google, partout, tout le temps.

“Don’t be evil”™

Recommandations à suivre !

Note à mon moi du futur : à lire plus en détails.

Un nouveau coup dure pour l’anonymat.
Toutefois, je comprends le conseil de l’ANSSI, mais ce n’est pas une solution acceptable.

Pour infos, la liste des nœuds de sortie est disponible ici :
https://check.torproject.org/exit-addresses

Seraient les dernières heures de Bitcoin ?

Le problème avec la fin du Réseau Téléphonique Commuté (RTC), ce sont les personnes qui ne sont pas technophiles, comme les personnes âgées, qui ne pourront plus téléphoner sans devoir débourser encore une fois pour changer leur équipement, ni les problèmes qu'il existe en cas de coupure de courant, comme pour les services d'urgence comme l'indique l'article.

Encore une fois, cela va créer plus de problèmes que ça n'en résout, uniquement au nom de la sacro-sainte finance.

Oh … Aïe, quoi. Ça a l'air plus que sérieux …

C'est étrange, ça rappelle énormément la faille GHOST, en janvier 2015, soit un an : https://links.thican.net/?Y8L6Ag

Plus de liens :

• en français sur le site Web Developpez.com : http://www.developpez.com/actu/96101/Une-autre-faille-critique-de-securite-a-ete-decouverte-dans-glibc-et-rend-les-machines-sous-Linux-vulnerables-a-l-execution-d-un-code-a-distance/
• https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html
• en français sur Linuxfr.org https://linuxfr.org/users/bortzmeyer/journaux/faille-de-securite-dans-la-gnu-libc-avec-les-requetes-dns

À première vue, effectivement, ça semble être une décision regrettable (dans ce que je vais expliquer, ne prenons en compte que les adresses IPv4).
L’une parce que des clients vont être lésés de ne pas avoir de plage complète de ports, et l’autre parce « [qu’]avec environ 11 millions d’adresses IP[v4] pour 6 millions de clients », il y a mathématiquement beaucoup de la place restante. Or, c’est voir le problème par le bout de la lorgnette.

Déjà, commençons par le vif du sujet, le partage de ports : il est de faits que la grande majorité des clients n’utilisent absolument pas de ports ouverts dans leur CPE (les « box ») pour héberger des services chez eux. Du coup, passer de 64ki ports, soient 65 536 ports (1 ki = 1024 unités) pour n’avoir que le quart, soient 16 384, n’empêchent absolument pas de pouvoir naviguer tranquillement sur Facebook, Twitter, Tinder, NetFlix, et d’autres services superflus comme les jeux vidéo, bref, « l’Internet » pour cette majorité de gens. Ces 16 milles ports sont bien plus que suffisant même pour plusieurs utilisateurs derrière la même connexion. De plus, rien n’empêche (si j’ai bien compris) d’ouvrir tout de même quelques ports parmi vos 16ki ports disponibles, pour avoir des services derrière votre CPE grâce au NAPT.

Concernant le nombre théorique d’adresses encore libres, c’est ne pas prendre en compte que les équipements chez Free, comme les routeurs de “backbone” ainsi que les DSLAM, ne peuvent pas prendre une adresse IP parmi les adresses théoriquement disponible : il y a un découpage à respecter, sans parler des adresses qui ne peuvent pas être assignées car elles ont un rôle particulier. Par conséquent, des tas d’adresses IP sont ainsi figées, et redéfinir ces découpages n’est pas chose aisée, surtout que ça voudrait dire que des clients actuels perdraient leur adresse actuellement assignée.

Mais au final, il y a des solutions : si vous faites parti des très rares à 1) avoir besoin d’ouvrir des ports, et 2) dans une plage spécifique (comme c’est le cas pour un service Web qui utilise par défaut les ports 80 et 443, ou pour héberger vos courriels avec les ports 25 et 465), Free a tout de même penser à vous, en fournissant des « adresse IP fixe ». Pour l’instant, pas d’infos sur les modalités d’acquisitions, le prix, etc., mais cette option règle complètement le problème.

De plus, c’est ignorer le fait que ce problème ne concerne qu’IPv4, qui tend à être remplacé par IPv6 ! Sans faire un cours sur IPv6, ce dernier crée des adresses sur 128 bits (dont 64 réservés pour la partie réseau), là où IPv4 ne fonctionne « que » sur 32 bits, ce qui permet d’avoir une quantité immense d’adresses supplémentaires (pas un facteur 4, mais plus !).
Ainsi, chaque client pourra avoir au minimum un /64 pour chaque connexion, ce qui ne permettra plus de problème de partage. Encore une preuve de la très proche pénurie d’adresses en IPv4, et qu’il est temps de fonctionner entièrement en IPv6.

Pour conclure, ce problème n’en est pas un. Le problème de base reste être la pénurie d’adresses en IPv4, et que le déploiement en IPv6 doit être obligatoire. Free est conscient d’un réel soucis et est juste pragmatique vis-à-vis de ses clients.
Certes, d’autres problèmes subsistent (comme les pings en ICMP, ou globalement les protocoles au dessus de la couche IP qui fonctionnent sans port), mais encore une fois, ces cas particuliers car rares ne devraient pas être les fonctionnements par défaut.

Il existe un préfixe en IPv6, qui permet d'écrire des adresses IPv4, pour ainsi faire de la traduction d'un réseau uniquement en IPv6, vers l'internet en IPv4 (oui, il faut donc une machine qui sont reliée en IPv4 pour faire la traduction, principe appelé NAT64).

C’est dans la section 2.1 qu’est définit le préfixe :
“The value of this IPv6 prefix is: 64:ff9b::/96”

Une nouvelle faille dans les systèmes Unix a été détectée.
cette faille, nommée GHOST, se situe dans la bibliothèque glibc - un composant essentiel aux systèmes GNU/Linux - à cause d'un appel de la fonction oboslète gethostname() (dont son nom), qui permet de faire un dépassement de tampon (buffer overflow).

Cette faille est en principe moins touchée pour les version supérieur ou égale à la version 2.18, mais il est conseillé de mettre à jour, pour corriger pleinement cette faille (c.f le communiqué sur la liste FRsAG).

Voir aussi :
http://www.frsag.org/pipermail/frsag/2015-January/005722.html (français)
https://www.nextinpact.com/news/92886-ghost-nouvelle-faille-critique-qui-fait-trembler-linux.htm (français)
https://community.qualys.com/blogs/laws-of-vulnerabilities/2015/01/27/the-ghost-vulnerability (anglais)

Note : dans la section 4 de cette page, il y a un code à compiler soit même :

• copiez simplement la commande qui contient la ligne "cat > GHOST.c << EOF" et finit par "EOF",
• faites "gcc -o GHOST GHOST.c" puis "./GHOST",
• regardez le résultat, pour savoir si vous êtes vulnérable à cette faille ou non.