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).
Un article de sensibilisation aux arnaques (“scam”) par courriel, en se servant de chantage concernant un (improbable) accès à votre compte et ordinateur et ainsi à vos données personnelles, contenant des "vidéos compromettantes".
Comme l’article l’explique correctement, ces arnaques ne sont pas ciblées, et ainsi ne peuvent pas être véridiques car n'étant pas ciblé ils n’ont donc aucune des données qu’ils prétendent avoir sur vous.
Et comme pour chaque chantage, il ne faut absolument pas payer ; sans plagier entièrement l’article, ils expliquent que rien n’empêchent ces maîtres chanteurs de revenir, car il n’y aura aucun moyen de vérifier qu’ils ne garderont pas une copie de vos données et qu’ils supprimeront leurs virus (qui je rappelle n'existent pas), et ainsi augmenter leurs enchères.
En conclusion, ayez une solution antivirus à jour (même les gratuites bien connues sont efficaces), ainsi qu’un système à jour principalement sur les mises à jour de sécurité.
Et concernant les chantages, il existe des aides pour bien vous informer (c’est dans l’article aussi).
Merci aux auteurs de cet article pour avoir créer une liste de ces arnaques et la maintenir à jour tout en étant très pédagogique sur le recul à prendre face à de tels courriels (et ils sont nombreux).
EDIT : je copie depuis cet articles des liens vers des pages de journaux français, parlant d'un français présumé coupable arrêté une fois son retour en avion en France :
Même avec un client officiel, des vulnérabilités demeurent suite à l’abandon du support pour ce jeu, permettant ainsi à des personnes malveillantes d’exploiter des failles qui ne seront jamais réparées, même si le client est toujours distribué par l’éditeur.
La suppression des noms de domaines malveillants n’est qu’une répit de quelques instants, tout au mieux.
Petite piqure de rappel.
En clair : ce qu’on appelle "le cloud", ce sont juste des machines qui appartiennent à d’autres ; et si c’est gratuit, alors vous êtes le produit.
Source directe des CGU (Conditions Générales d’Utilisation) en français : https://policies.google.com/terms?hl=fr
Vu sur FRnOG.
Les monnaies basées sur le “Proof of Work” (PoW) sont une catastrophe du point de vue écologique.
Et cette plaie qu’est le Bitcoin va être traînée pendant de longues décennies, jusqu’en 2140[1] d’après les estimations (oui oui, plus de 120 ans), avec une augmentation de la consommation énergétique que cela entraîne pour être le premier à récolter la maigre récompense.
1: https://bitcoin.stackexchange.com/questions/10486/when-will-the-last-bitcoin-be-mined
EDIT 2017-11-10: voir aussi https://digiconomist.net/bitcoin-energy-consumption
Très intéressant comme produit, à voir ça de plus près.
Utiliser le service spamd, qui utilise la méthode de la liste grise pour déterminer le courriel légitime du courriel indésirable, car nu serveur légitime tentera de renvoyer le courriel, alors qu’un spammeur utilisant une machine vulnérable ne le fera pas.
Recommandations à suivre !
Note à mon moi du futur : à lire plus en détails.
Piqûre de rappel, avec aussi l’article source bien connu : http://sackheads.org/~bnaylor/spew/away_msgs.html
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
Un brouillon concernant TLSv1.3.
D'ailleurs, pour pouvoir profiter de Forward-Secrety, il suffit de retirer le chiffrement RSA pour l'échange de clefs symétriques, avec "!kRSA", comme ceci (liste fonctionnant avec OpenSSL en version 1.0.2f actuellement) :
HIGH:!kRSA:!DHE:!DH:!SSLv3:!SSLv2:!RC4:!aNULL:!eNULL:!EXPORT:!3DES:!DES:!SHA1:!MD5
Pour retirer le chiffrement AES128, il suffit de rajouter ":!AES128" à la liste, mais les navigateurs actuels ne fonctionnent pas sans.
À 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”
Haha, tiens, je ne connaissez pas. Un indicateur clair si le discours est sincère ou parodique.
En français : https://fr.wikipedia.org/wiki/Loi_de_Poe
Voir aussi http://blog.cryptographyengineering.com/2015/05/attack-of-week-logjam.html
Un site qui regroupe une liste de configurations concernant le chiffrement (SSL/TLS) pour différents services.
Voici un document au format PDF pour aider à la mise en place et configuration du système DNSSEC avec le logiciel BIND9.
Copie : https://thican.net/~thican/bind_dnssec-guide.pdf
Voir aussi le manuel de référence d'administration de BIND9 (version 9.10.2) : ftp://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/Bv9ARM.pdf
(copie : https://thican.net/~thican/bind_Bv9ARM.pdf)
Ce petit billet me sert principalement de garde-mémoire, je ne vais donc pas détailler ce qu'est le champ TLSA et son but ; ceci est détaillé dans la RFC6698 “The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA” (https://tools.ietf.org/html/rfc6698)
Principalement, ce qui nous intéresse, c’est de fournir soit l’empreinte de la clef, soit l’empreinte du certificat ; c’est ce que définit le champ "Selector" (section 2.1.2).
Remarque : j’ai considéré par défaut que nous sommes dans le cas d’un "DANE-EE: Domain Issued Certificate", valeur "3" du champ "Certificate Usage" (section 2.1.1).
Si vous souhaitez uniquement donner l’empreinte de votre clef (valeur "1" dans le "Selector Field"), utilisez les valeurs "3 1 1" et "3 1 2" respectivement pour les hashs SHA256 et SHA512 ;
Ensuite, vous pouvez au choix déterminer les hashs (SHA256 et SHA512) à partir de la clef privée (n’oubliez pas l’option -pubout, voir openssl pkey(1))
openssl pkey -outform DER -pubout -in "/path/to/private.key" | openssl dgst -sha256
openssl pkey -outform DER -pubout -in "/path/to/private.key" | openssl dgst -sha512
OU, en alternative, déterminer les hashs (SHA256 et SHA512) à partir d'un certificat (c’est ainsi de cette façon qu’un tiers peut vérifier)
openssl x509 -noout -pubkey -in "/path/to/certificat_file.pem" | openssl pkey -outform DER -pubin | openssl dgst -sha256
openssl x509 -noout -pubkey -in "/path/to/certificat_file.pem" | openssl pkey -outform DER -pubin | openssl dgst -sha512
Par contre, si vous souhaitez fournir l’empreinte complète du certificat, utilisez les valeurs "3 0 1" et "3 0 2" respectivement, et exécutez :
openssl x509 -noout -fingerprint -in "/path/to/certificat_file.pem" -sha256
openssl x509 -noout -fingerprint -in "/path/to/certificat_file.pem" -sha512
Ensuite, créer une entrée DNS dans votre zone, en suivant la sémantique suivante :
<port>.<protocole>.<nomdedomaine> IN TLSA <X Y Z> <hash>
Par exemple, pour avoir le hash du certificat pour le service HTTPS, donc le protocole TCP qui répond au port 443, sur la machine foo.example.com, le résultat est "_443._tcp.foo.example.com." (ne pas oublier le dernier point à la fin).
Et pour les valeurs <X Y Z> :
X → https://tools.ietf.org/html/rfc6698#section-2.1.1 : la valeur "3" indique que ce sont des informations avec le certificat le plus proche.
Y → https://tools.ietf.org/html/rfc6698#section-2.1.2 : exporter la clef est plus simple, de ce que j’ai compris.
Z → https://tools.ietf.org/html/rfc6698#section-2.1.3 : "1" pour le hash SHA256, "2" pour le hash SHA512.
Concernant le hash, n'oubliez pas de supprimer les doubles-points (par exemple : echo $hash | tr -d ':')
Sources :
Autre outil (mais en anglais) concernant les noms de domaine, en particulier pour la mise en place du DNSSEC.
Très pratique pour détecter les erreurs.
Un outil du site web de l'AFNIC (registar français pour les TLD en .fr) pour analyser les erreurs possibles contenu dans une zone. Très pratique, car il permet aussi de vérifier les plages de temps de l'entrée SOA.
Pour info concernant le SOA, voici les règles de l'AFNIC :
Voilà, je me suis lancé dans l'aventure NXT, et pour aider les nouveaux, je suis prêt (dans la limite du raisonnable) à envoyer 1 NXT, actuellement de la valeur de la "taxe" (fee), pour vous permettre de faire une transaction sortante et ainsi valider votre clef publique.
Pour cela, envoyez-moi simplement un courriel, avec votre "account ID" de la forme NXT-????-????-????-?????, ainsi que votre clef publique (car tant que le compte n'a rien envoyé, il n'existe pas sur le réseau et l'identifiant "NXT-..." ne sera pas trouvé).
Pour plus d'infos, en attendant que je détaille de mon côté, commencez par le wiki officiel https://wiki.nxtcrypto.org/
Wouah... ça c'est du "business model" qui sent mauvais l'arnaque ; créer l'offre et la demande.
Et ils osent appeler ça des gTLD ? Pouah !
29,49€ HT/an, pour une entrée dans une base de données, punaise, il y a vraiment des escrocs...
Certes, ce n'est pas très "neutre" comme façon de faire, mais vu que ça fait plusieurs années que je reçois différents tentatives d'attaques sur mes serveurs, autant agir préventivement.
Voici les différents ranges que j'ai bannis :
1.160.0.0/12
36.224.0.0/12
111.240.0.0/12
114.24.0.0/14
114.32.0.0/12
118.160.0.0/13
118.168.0.0/14
220.128.0.0/12
Juste pour infos, un /14 correspond à 262 144 adresses possibles (4256256), un /13 à 524 288 (comme /14 2), et un /12 ... à 1 048 576 adresses ! (/13 2 aussi, ou /14 * 4).
En total, je suis à plus de six millions d'entrées (6 291 456).
Avant, c'était fail2ban qui bannissait une par une, là, c'est déjà fait.
Oui, arrêtez vos sarcasmes, et dites le franchement : Non, c'est vraiment une idée stupide.
Petite correction de l'article, d'après ce que j'ai trouvé comme infos, non, l'application ne permet pas d'envoyer "no Yo". Du coup, le côté binaire de l'application est caduque, c'est un simple système unaire https://fr.wikipedia.org/wiki/Système_unaire
Là où je suis stupéfait par cette application, ce n'est pas l'idée en lui-même du « message binaire », mais bien le fait de devoir s'inscrire, qu'il faut faire parti de ce « réseau », et d'être dépendant d'un seul prestataire, pour que fonctionne ce service.
J'ai l'impression que les gens, dès lorsqu'ils utilisent un service lié à internet, désactivent leur cerveau, et du coup ne réfléchissent plus. Auriez-vous accepté, de manger uniquement des aliments d'une unique marque, parce que vous avez des assiettes et des couverts de la même marque ? Pareil pour vos voitures, est-ce que vous auriez accepté d'être interdit de rouler sur telle route, car vous n'avez pas les bonnes marques de pneu, moteur, carburant ?
Bref, il suffit des idées stupides ! Et comme je suis aimable, je vous offre une bonne idée, et elle est toute simple : utilisez votre cerveau !
Un bon article sur le rapport de la "neutralité des plateformes" du Conseil National du Numérique (CNNum).
Voir aussi le résumé sur Numérama : http://www.numerama.com/magazine/29690-la-neutralite-des-plateformes-qu-est-ce-que-c-est.html
Enfin vers un internet décentralisé, et moins sous le contrôle d'un pays qui veut imposer sa vision des choses au monde entier. :-)
Suite d'articles en anglais au sujet du fonctionnement autour de l'email, ou "courriel", les difficultés rencontrées pour satisfaire son implémentation, etc.
Knot, une alternative dans le monde des serveurs DNS, comme BIND.
Rapide et performant.
Prévisible, et pathétique.
TL;DR
(Via Schneier https://www.schneier.com/blog/archives/2013/12/bitcoin_explana.html)
Un article très intéressant au sujet du P2P à la manière d'eMule.
(voir aussi http://www.numerama.com/magazine/1625-le-p2p-de-2005-l-annee-decisive.html)
En voilà une bonne initiative.
De mon avis, le chiffrement n'est pas une solution à long terme ; elle conforte dans un faux sentiment de sécurité et de vie privée, et surtout n'empêchera pas la copie des données brutes.
Là où un changement serait efficace, ce serait aussi de mieux décentraliser les données et de permettre un transport des données avec le chemin le plus court en nombre de routeurs et aussi en distance, donc, d'éviter les autoroutes à données, en augmentant le maillage.
Lien direct : http://www.bortzmeyer.org/ietf-securite-espionnage-bis.html
Billet de blog mettant en lumière quelques contradictions entre le mode "physique" et le monde numérique, ce dernier appelé Cyberespace.
Dommage, je n'y crois plus...
Encore une idée stupide : comment faire disparaitre des données, alors que dans l'informatique, les machines ne sont que des copieuses d'octets ?
Il faut absolument arrêter de vouloir recréer le fonctionnement du monde réel dans le monde virtuel, ça n'aboutit qu'à des échecs.
Et puis, vu comment le monde n'est pas foutu de respecter un standard pour afficher l'heure simplement (alors que la RFC 3339 existe depuis un bon bout de temps), je sens que ça va finir en échecs cuisants.
Un article un peu vieux de Rue89 (octobre 2012) au sujet de la fragmentation des offres d'accès à Internet...
Il ne faut pas que cela arrive !
Un guide sur la configuration de zones DNS assez simple d'accès, pour débuter ou même pour revoir quelques bases.
détails de la fonctionnalité RNDC, liée à BIND.
Oh yeah, un tuto complet pour installer son service Firefox Sync Server personnel.
Cool :-) (arf, Python 2.6, pô cool)
Wow …
…
…
…
Bullshits overflow.
Avertissement, cet article n'est pas destiné à ceux qui ont un cerveau et quelques connaissances en réseau ; des dégâts irrémédiables aux neurons sont possibles.
RFC qui concerne les courriels, avec des échanges chiffrés.
Et malgré tout cela, les gens, ils ne veulent pas comprendre…
Privacy Extensions pour IPv6
echo 'net.ipv6.conf.all.use_tempaddr = 2' >> /etc/sysctl.conf
EDIT: en fait, le "all" ne semble pas fonctionner, du coup, il vaut mieux mettre plusieurs lignes, avec le nom des interfaces réseaux.
Voir RFC 4941 : https://tools.ietf.org/html/rfc4941
Ha ben la voilà, la RFC qu'il faut mettre en place pour améliorer les réseaux, vu la lenteur de déployement de la fibre optique en France ; et pourtant, cette RFC date de 1990 !
Pas de problèmes de collision, avec un espace en 3D contrairement à un espace en 1D.
En anglais https://tools.ietf.org/html/rfc1149
et les mises à jour de cette RFC, https://tools.ietf.org/html/rfc2549 (de 1999, pour la QoS) et https://tools.ietf.org/html/rfc6214 (de 2011, pour l'IPv6)
Guide de programmation sur les sockets, pour le language C, semble très complet.
La NSA, l'agende de sécurité américaine, a un accès direct et sans restriction aux bases de données des grands groupes du web et de l'internet, comme Google, Facebook, Yahoo, Apple, etc.
Quittez donc ces services une bonne fois pour toutes !