Il y a aussi le RFC 8567, "Customer Management DNS Resource Records", que j'aime beaucoup :
The ubiquity of residential broadband Internet service affords myriad
benefits to consumers, but also poses a daunting challenge for
Internet Service Providers—how to best manage sensitive customer
identifiers and billing details, while ensuring the resilience and
security of CPE devices on their network?
This document introduces four new RRs to assist in the management of customer data by ISPs.
2.1. The PASSWORD Resource Record
2.2. The CREDITCARD Resource Record
2.3. The SSN Resource Record
2.4. The SSNPTR Resource Record
Voila de quoi simplifier la gestion des comptes utilisateurs, toutes les données seront disponible via DNS !
Pour rappel, le "Social Security Number"(SSN) est une information privée aux États-Unis, on ne le communique pas a tous vents.
La première ligne pour déclarer la zone est incomplète, voici ce à quoi elle devrait ressembler :
example.net. IN SOA server.example.net. hostmaster.server.example.net. ( Dans l'ordre les informations sont:
le nom de domaine
la classe Internet (IN)
le type d'enregistrement (SOA - Start of Authority)
le nom complet du serveur de nom principal (avec un point terminal)
l'adresse e-mail du gestionnaire de zone (hostmaster)
Oui, le dernier champ est bien une adresse e-mail, le premier point est converti en arobase par convention.
Je ne saurais aussi que trop recommander l'outil named-checkzone pour vérifier la syntaxe des fichiers de zone.
Enfin, le TLD .lan n'est pas adéquat pour un réseau personnel. Il existe une définition officielle dans le RFC 8375 pour utiliser home.arpa.
Il y a au moins deux solutions propres possibles :
maintenir un fichier /etc/hosts et le tenir à jour (via rsync ou autre outil similaire). Cela peut fonctionner pour des besoins simples (peu de machines, pas d'enregistrement DNS "évolué").
maintenir un serveur DNS interne, faisant autorité pour le réseau interne. Il faudra un accès VPN ou quelque chose de similaire pour permettre à des personnes sur un autre réseau d'utiliser ce résolveur.
Bonne nouvelle, les choses vont mieux pour Patrick et pour le projet Slackware !
Pat a posté un message de remerciement avec un résumé de la situation dans le fichier ChangeLog. Eric "AlienBob" Hameleers à également publié un article de blog à ce sujet, ainsi que les possibles changements techniques à venir dans la distribution.
Il n'y a pas encore de solution pérenne pour assurer le financement de Slackware, Pat étudie plusieurs solutions, reste à espérer qu'une ou plusieurs d'entre elles seront rapidement en place.
Pat n'est effectivement pas très vocal sur ce qu'il fait en dehors des commentaires occasionnels dans le changelog et quelques posts ça et là sur le forum de linuxquestions.org.
Il a effectivement été malade à partir de 2004 et cela avait bousculé le projet Slackware.
Bonne nouvelle, en attendant une solution plus pérenne à laquelle il réfléchit, Pat a posté un lien PayPal pour recevoir des donations.
La liste des produits sur la boutique a été réduite au fil du temps (plus de décapsuleurs ou autre gadgets). Et sachant que la production de CD/DVD ne coûte pas grand chose, il me semble que son bénéfice devrait être plus élevé que 15%.
Le lien pour faire des dons à été retiré, c'est d'ailleurs la même question qui a lancé la discussion sur linuxquestions.org. Pat a demandé à ce qu'il soit retiré vu qu'il ne reçoit rien de l'argent qui est envoyé.
Slackware est effectivement une distribution un peu ardue pour commencer, mais l'un des avantages est que l'on apprend beaucoup sur ce qui se passe habituellement en coulisse.
Changer les paramètres linguistiques est un peu déconcertant, car il n'y a pas de gestion unifiée entre les paramètres console (défini lors de l'installation) et les paramètres de l'environnement graphique (KDE probablement, qui est le choix par défaut).
Il existe une page de documentation sur le wiki à ce sujet :
Et le résolveur récursif connaît l'IP de chaque "serveur faisant autorité pour la racine" ?
Grâce au fichier root.hints qui liste les adresses de tous les serveurs de la racine. Ce fichier est normalement fourni avec le logiciel serveur DNS (BIND ou Unbound).
Il y a effectivement des changements au niveau des serveurs racine de temps à autre, et il faut maintenir ce fichier à jour depuis le serveur de l'IANA (cron peut faire ça automatiquement).
tu ne vas avoir quasiment aucun cache sur les sites que tu visites rarement
Les choses sont un peu plus complexes que cela.
Pour chaque enregistrement DNS, le gérant de la zone décide de la durée de validité d'icelui. C'est le TTL ("Time To Live"). Un serveur DNS cache gardera l'enregistrement en mémoire aussi longtemps que le TTL le permet.
Bien qu'il existe des RFC spécifiant quelles valeurs sont normalement admises pour un TTL, une des tendances actuelles est de configurer des temps très court pour les sites importants (ce qui permet d'améliorer les bascules de service, la gestion de charge et ce genre de choses). Le bénéfice pour de tels sites sera difficile dans tous les cas.
Un bon serveur DNS cache doit avoir de la mémoire disponible (évidemment) et aussi un bon uptime. Avoir un DNS cache personnel demande une machine qui n'est pas redémarrée ou éteinte sans raison, le service doit rester actif aussi longtemps que possible, sinon les bénéfices du cache ne seront pas évidents.
J'ai un serveur Unbound au boulot qui ne sert que pour des besoins d'infrastructure (équipement réseau, serveurs, …) et le gain est non négligeable si j'en crois les logs de la semaine passée :
Jan 08 04:40:25 unbound[26393:0] info: server stats for thread 0: 39588 queries, 23095 answers from cache, 16493 recursions, 0 prefetch
Probablement ; je n'ai pas encore testé ça. Je suis parti sur une solution un peu plus "solide" en prévoyant d'ajouter une horloge (DS3231 de son petit nom) à mon Pi. La commande est passée, reste à tester quand la livraison sera effectuée.
ok, comme je ne savais pas quoi faire cet après midi, j'ai mis ça en place sur mon raspberry pi3
(…) Le pi3 ne fait pas grand chose à l'heure actuelle à par servir domoticz et désormais unbound (activité ram et proc ok)
J'imagine que le Pi3 est comme ses prédécesseurs dépourvu d'horloge matérielle, je préviens donc à l'avance : Unbound demande une horloge à l'heure afin d'effectuer les validations DNSSec. Ce qui généralement ne pose pas de souci quand le Pi est synchronisé avec NTP.
Seulement voilà : au démarrage du système, NTP à besoin de résoudre un nom d'hôte avec DNS, qui demande lui-même d'être à l'heure… Je suggère fortement de vérifier comment les choses réagissent après un redémarrage, voire un arrêt complet.
Il faudrait peut être que je teste avec le pi3 en réseau filaire ?
Ça permettrait au moins d'avoir une connection réseau consistante.
J'abonde dans le même sens pour ce qui est de la diffusion des fichiers sources (archive contenant le code plus les differents fichiers tel que README, INSTALL, …).
Un point qui est aussi appréciable est d'avoir un moyen de vérifier l'intégrité des fichiers : à minima donner les sommes de contrôle MD5/SHA1/SHA2 sur le site web, et dans l'idéal proposer un fichier de signature cryptographique (.asc). Cela demande évidemment un peu plus de travail initial (créer et diffuser la clé GPG, ajouter une étape de signature après avoir crée l'archive de fichiers sources) mais c'est appréciable de pouvoir vérifier que rien n'ait été modifié, surtout si ton logiciel se retrouve diffusé en différent endroits.
Il existe plusieurs façons de gérer cela, mais il faut bien sûr passer par un script.
Point important à retenir : créer un utilisateur sous Samba requiert de créer un compte système en premier lieu (ou d'avoir un annuaire LDAP pour l'authentification, mais autant commencer simplement).
Pour la création des comptes Samba les choses sont un peu plus simple, voici un squelette de script :
# lecture du fichier 'liste'
/bin/cat liste |
# lecture ligne a ligne
while
read prenom nom identifiant mdp
do
echo -e "$mdp\n$mdp\n" | /usr/bin/smbpasswd -s -a $identifiant
done
Cela implique que les valeurs soient lues dans un certain ordre, qui ne correspond pas à celui utilisé dans l'article de blog, mais cela ne devrait pas poser de souci à adapter.
OK, je me disais que s'il m'arrivait un accident il ne faudrait pas que le mot de passe root soit définitivement perdu, mais donc en fait ce serait pas grave, puisqu'on s'en sert jamais.
Il peut y avoir des situations où un administrateur ou un responsable de l'organisation ait besoin du mot de passe root (rare mais possible).
Comme pour d'autres informations sensibles, ce que j'ai pu faire là où je travaille est de garder une copie du mot de passe root dans une enveloppe scellée dans un coffre (sachant que très peu de personnes ont accès au coffre en question).
Ce qui fait qu'en cas de problème majeur (y compris décès de l'administrateur) l'organisation à un moyen de gérer le serveur ou tout autre équipement sensible (commutateur, pare-feu, routeur, …). J'essaye aussi de laisser quelques instructions de base pour les cas de coupure électrique (que redémarrer dans quel ordre, …). Il est aussi recommandé de tester les choses "à froid" (comme pour les exercices d'évacuation incendie).
C'est le type de "plan B" qu'il peut être bon de préparer pour toute organisation qui dépend de l'informatique pour ses activités régulières. De manière plus formelle, c'est inclus dans le "Plan de reprise d'activité" (PRA).
Évidemment, le temps de rédigé un journal sur le même sujet (et avec un mauvais numéro de version dans le titre qui plus est) je n'ai pas pris le temps de vérifier qu'une dépêche était déjà présente… Mieux vaut trop que pas assez ; merci Yvan !
Je me suis un peu frotté à l'intégration de Samba 4 avec Active Directory, et cela fonctionne, avec quelques bugs ça et là (peut-être dus à Samba, mais le réseau Windows n'était pas configuré dans les règles de l'art non plus…). L'une des choses ennuyeuses et qu'il ne faut pas mettre de règles de filtrage iptables trop restrictives (ou à minima être sûr de bien logger ce qui se passe pour pouvoir comprendre ce qui se passe).
Accessoirement, pour un public anglo-saxon, "ADSL" ne signifiera pas grand chose : les offres commerciales mentionnent uniquement "DSL". Et la grande majorité des connections se fait par câble (ou fibre optique - "FIOS" aux États-Unis - pour les plus chanceux).
Explications de Patrick Volkerding, mainteneur de la distribution :
The proof of concept exploit does not work on any version of Slackware unless that patch (glibc-2.10-dns-no-gethostbyname4.diff.gz) is removed and glibc is recompiled. The patch came from openSUSE long ago, and was also used by Debian at one time, but we seem to be the only ones who still apply it. I've had two requests in email to remove the patch since glibc had supposedly fixed the issue that prompted it, but left it in place anyway. Maybe luck, maybe slack.
Clamscan ne connaît pas ce virus, avast ne l'a pas détecté. Je me demande maintenant quoi faire ? A qui communiquer ces informations ? Si vous avez des idées je suis preneur.
Il y a un formulaire en ligne pour signaler de nouveaux fichiers suspicieux :
Il faudrait sûrement envoyer le fichier exécutable ; envoyer le fichier attaché original pourrait aussi être utile.
Sinon pour le reste (récupération de fichiers depuis un serveur web infecté, …) je n'ai pas de référence exacte en tête, mais ça ne me semble pas être très nouveau…
Merci pour ce compte rendu et pour les liens. Même si ce n'est pas le genre d'opération qu'un administrateur réseau doit avoir à gérer souvent, c'est toujours bon de savoir ce que font les autres.
Une question : d'où vient la commande check-soa ? À ma connaissance ce n'est pas un outil proposé par BIND ou Unbound. Est-ce un script personnel ou un outil tiers ?
[^] # Re: RFC 8565: Hypertext Jeopardy Protocol (HTJP/1.0)
Posté par Ellendhel (site web personnel) . En réponse au journal Liste de poissons d'avril 2019. Évalué à 2.
Il y a aussi le RFC 8567, "Customer Management DNS Resource Records", que j'aime beaucoup :
Voila de quoi simplifier la gestion des comptes utilisateurs, toutes les données seront disponible via DNS !
Pour rappel, le "Social Security Number"(SSN) est une information privée aux États-Unis, on ne le communique pas a tous vents.
# Quelques remarques
Posté par Ellendhel (site web personnel) . En réponse au message fichier de configuration bind9. Évalué à 3.
La première ligne pour déclarer la zone est incomplète, voici ce à quoi elle devrait ressembler :
example.net. IN SOA server.example.net. hostmaster.server.example.net. (
Oui, le dernier champ est bien une adresse e-mail, le premier point est converti en arobase par convention.
Je ne saurais aussi que trop recommander l'outil named-checkzone pour vérifier la syntaxe des fichiers de zone.
Enfin, le TLD .lan n'est pas adéquat pour un réseau personnel. Il existe une définition officielle dans le RFC 8375 pour utiliser home.arpa.
[^] # Re: Pas normal de résoudre des IP locales publiquement
Posté par Ellendhel (site web personnel) . En réponse au message Résolution DNS et serveurs publics qui ne donnent pas de réponses quand la réponse est une ip locale. Évalué à 4.
Il y a au moins deux solutions propres possibles :
maintenir un fichier /etc/hosts et le tenir à jour (via rsync ou autre outil similaire). Cela peut fonctionner pour des besoins simples (peu de machines, pas d'enregistrement DNS "évolué").
maintenir un serveur DNS interne, faisant autorité pour le réseau interne. Il faudra un accès VPN ou quelque chose de similaire pour permettre à des personnes sur un autre réseau d'utiliser ce résolveur.
Il existe beaucoup de documentation sur ce sujet, en voici une parmi d'autres : https://calomel.org/dns_bind.html
# Mise à jour
Posté par Ellendhel (site web personnel) . En réponse au journal Slackware est financièrement mal en point. Évalué à 4.
Bonne nouvelle, les choses vont mieux pour Patrick et pour le projet Slackware !
Pat a posté un message de remerciement avec un résumé de la situation dans le fichier ChangeLog. Eric "AlienBob" Hameleers à également publié un article de blog à ce sujet, ainsi que les possibles changements techniques à venir dans la distribution.
Il n'y a pas encore de solution pérenne pour assurer le financement de Slackware, Pat étudie plusieurs solutions, reste à espérer qu'une ou plusieurs d'entre elles seront rapidement en place.
[^] # Re: Crowfunding ?
Posté par Ellendhel (site web personnel) . En réponse au journal Slackware est financièrement mal en point. Évalué à 7.
Pat n'est effectivement pas très vocal sur ce qu'il fait en dehors des commentaires occasionnels dans le changelog et quelques posts ça et là sur le forum de linuxquestions.org.
Il a effectivement été malade à partir de 2004 et cela avait bousculé le projet Slackware.
Bonne nouvelle, en attendant une solution plus pérenne à laquelle il réfléchit, Pat a posté un lien PayPal pour recevoir des donations.
[^] # Re: Confusion
Posté par Ellendhel (site web personnel) . En réponse au journal Slackware est financièrement mal en point. Évalué à 4.
Oui, la différence est grande, pas faible.
La liste des produits sur la boutique a été réduite au fil du temps (plus de décapsuleurs ou autre gadgets). Et sachant que la production de CD/DVD ne coûte pas grand chose, il me semble que son bénéfice devrait être plus élevé que 15%.
[^] # Re: Dons
Posté par Ellendhel (site web personnel) . En réponse au journal Slackware est financièrement mal en point. Évalué à 9.
Le lien pour faire des dons à été retiré, c'est d'ailleurs la même question qui a lancé la discussion sur linuxquestions.org. Pat a demandé à ce qu'il soit retiré vu qu'il ne reçoit rien de l'argent qui est envoyé.
[^] # Re: Slackware?
Posté par Ellendhel (site web personnel) . En réponse au message comment changer la disposition du clavier ?. Évalué à 3.
Slackware est effectivement une distribution un peu ardue pour commencer, mais l'un des avantages est que l'on apprend beaucoup sur ce qui se passe habituellement en coulisse.
Changer les paramètres linguistiques est un peu déconcertant, car il n'y a pas de gestion unifiée entre les paramètres console (défini lors de l'installation) et les paramètres de l'environnement graphique (KDE probablement, qui est le choix par défaut).
Il existe une page de documentation sur le wiki à ce sujet :
https://docs.slackware.com/fr:slackware:localization
Cela fait aussi parti des questions fréquentes dont les réponses sont disponibles ici (sûrement un peu daté) :
https://www.ellendhel.net/article.php?ref=2012+09+22-0
# ABMX
Posté par Ellendhel (site web personnel) . En réponse au message Cherche serveur rackable 1U ou plus pour rack de 45cm de profondeur. Évalué à 2.
ABMX propose des serveurs 1U de petit format, à voir si tu y trouves ton bonheur :
https://www.abmx.com/1u-server
[^] # Re: apt-get install unbound
Posté par Ellendhel (site web personnel) . En réponse au sondage Quel résolveur DNS utilisez-vous ?. Évalué à 5.
Grâce au fichier root.hints qui liste les adresses de tous les serveurs de la racine. Ce fichier est normalement fourni avec le logiciel serveur DNS (BIND ou Unbound).
Il y a effectivement des changements au niveau des serveurs racine de temps à autre, et il faut maintenir ce fichier à jour depuis le serveur de l'IANA (cron peut faire ça automatiquement).
[^] # Re: Avantage des autres DNS ?
Posté par Ellendhel (site web personnel) . En réponse au sondage Quel résolveur DNS utilisez-vous ?. Évalué à 7.
Les choses sont un peu plus complexes que cela.
Bien qu'il existe des RFC spécifiant quelles valeurs sont normalement admises pour un TTL, une des tendances actuelles est de configurer des temps très court pour les sites importants (ce qui permet d'améliorer les bascules de service, la gestion de charge et ce genre de choses). Le bénéfice pour de tels sites sera difficile dans tous les cas.
J'ai un serveur Unbound au boulot qui ne sert que pour des besoins d'infrastructure (équipement réseau, serveurs, …) et le gain est non négligeable si j'en crois les logs de la semaine passée :
Jan 08 04:40:25 unbound[26393:0] info: server stats for thread 0: 39588 queries, 23095 answers from cache, 16493 recursions, 0 prefetch
[^] # Re: Un résolveur à la maison
Posté par Ellendhel (site web personnel) . En réponse au journal DNS anonyme. Évalué à 2.
Probablement ; je n'ai pas encore testé ça. Je suis parti sur une solution un peu plus "solide" en prévoyant d'ajouter une horloge (DS3231 de son petit nom) à mon Pi. La commande est passée, reste à tester quand la livraison sera effectuée.
[^] # Re: Un résolveur à la maison
Posté par Ellendhel (site web personnel) . En réponse au journal DNS anonyme. Évalué à 8.
J'imagine que le Pi3 est comme ses prédécesseurs dépourvu d'horloge matérielle, je préviens donc à l'avance : Unbound demande une horloge à l'heure afin d'effectuer les validations DNSSec. Ce qui généralement ne pose pas de souci quand le Pi est synchronisé avec NTP.
Seulement voilà : au démarrage du système, NTP à besoin de résoudre un nom d'hôte avec DNS, qui demande lui-même d'être à l'heure… Je suggère fortement de vérifier comment les choses réagissent après un redémarrage, voire un arrêt complet.
Ça permettrait au moins d'avoir une connection réseau consistante.
# Sources signées
Posté par Ellendhel (site web personnel) . En réponse au journal Comment distribuer un logiciel pour GNU/Linux ?. Évalué à 4.
J'abonde dans le même sens pour ce qui est de la diffusion des fichiers sources (archive contenant le code plus les differents fichiers tel que README, INSTALL, …).
Un point qui est aussi appréciable est d'avoir un moyen de vérifier l'intégrité des fichiers : à minima donner les sommes de contrôle MD5/SHA1/SHA2 sur le site web, et dans l'idéal proposer un fichier de signature cryptographique (.asc). Cela demande évidemment un peu plus de travail initial (créer et diffuser la clé GPG, ajouter une étape de signature après avoir crée l'archive de fichiers sources) mais c'est appréciable de pouvoir vérifier que rien n'ait été modifié, surtout si ton logiciel se retrouve diffusé en différent endroits.
# Script
Posté par Ellendhel (site web personnel) . En réponse au message Création simultanée et en lot d'utilisateurs et utilisateurs samba. . Évalué à 3.
Il existe plusieurs façons de gérer cela, mais il faut bien sûr passer par un script.
Point important à retenir : créer un utilisateur sous Samba requiert de créer un compte système en premier lieu (ou d'avoir un annuaire LDAP pour l'authentification, mais autant commencer simplement).
Voici quelques pistes pour ce qui est de la création des comptes système : https://www.ellendhel.net/article.php?ref=2016+06+20-0
Pour la création des comptes Samba les choses sont un peu plus simple, voici un squelette de script :
Cela implique que les valeurs soient lues dans un certain ordre, qui ne correspond pas à celui utilisé dans l'article de blog, mais cela ne devrait pas poser de souci à adapter.
[^] # Re: non
Posté par Ellendhel (site web personnel) . En réponse au message bonnes pratiques pour le mot de passe root. Évalué à 2.
Exactement.
Sudo: You're Doing it Wrong vidéo d'une présentation par Michael W Lucas sur cet outil (en anglais).
Fortement recommandé.
[^] # Re: non
Posté par Ellendhel (site web personnel) . En réponse au message bonnes pratiques pour le mot de passe root. Évalué à 4.
Il peut y avoir des situations où un administrateur ou un responsable de l'organisation ait besoin du mot de passe root (rare mais possible).
Comme pour d'autres informations sensibles, ce que j'ai pu faire là où je travaille est de garder une copie du mot de passe root dans une enveloppe scellée dans un coffre (sachant que très peu de personnes ont accès au coffre en question).
Ce qui fait qu'en cas de problème majeur (y compris décès de l'administrateur) l'organisation à un moyen de gérer le serveur ou tout autre équipement sensible (commutateur, pare-feu, routeur, …). J'essaye aussi de laisser quelques instructions de base pour les cas de coupure électrique (que redémarrer dans quel ordre, …). Il est aussi recommandé de tester les choses "à froid" (comme pour les exercices d'évacuation incendie).
C'est le type de "plan B" qu'il peut être bon de préparer pour toute organisation qui dépend de l'informatique pour ses activités régulières. De manière plus formelle, c'est inclus dans le "Plan de reprise d'activité" (PRA).
[^] # Re: Damned, trop lent
Posté par Ellendhel (site web personnel) . En réponse à la dépêche Slackware 14.2. Évalué à 2.
De rien, merci pour la correction !
# Damned, trop lent
Posté par Ellendhel (site web personnel) . En réponse à la dépêche Slackware 14.2. Évalué à 5. Dernière modification le 02 juillet 2016 à 15:22.
Évidemment, le temps de rédigé un journal sur le même sujet (et avec un mauvais numéro de version dans le titre qui plus est) je n'ai pas pris le temps de vérifier qu'une dépêche était déjà présente… Mieux vaut trop que pas assez ; merci Yvan !
# Intégration Active Directory et BIND
Posté par Ellendhel (site web personnel) . En réponse au message Serveur DNS bind9 avec Active Directory Microsoft. Évalué à 5.
DHCP je ne suis pas certain (probablement, mais je n'ai pas testé).
DNS, BIND en particulier, oui et il y a de la documentation pour cela, mais ce n'est pas très récent :
http://www.ibiblio.org/gferg/ldp/BIND+AD-HOWTO/
L'un des points les plus importants est de comprendre l'utilisation des enregistrements SRV que Active Directory utilise beaucoup.
Voici un autre courte documentation à ce sujet :
http://www.linuxquestions.org/linux/answers/Networking/Configure_BIND_DNS_to_Answer_Active_Directory_Queries
Je me suis un peu frotté à l'intégration de Samba 4 avec Active Directory, et cela fonctionne, avec quelques bugs ça et là (peut-être dus à Samba, mais le réseau Windows n'était pas configuré dans les règles de l'art non plus…). L'une des choses ennuyeuses et qu'il ne faut pas mettre de règles de filtrage iptables trop restrictives (ou à minima être sûr de bien logger ce qui se passe pour pouvoir comprendre ce qui se passe).
# Référence ?
Posté par Ellendhel (site web personnel) . En réponse au message [recrutement] CDI administrateur système et réseau sur Rennes. Évalué à 4.
Je pensais que Mortal Kombat était la référence pour autoriser ou rejeter des candidats.
[^] # Re: Des fôtes
Posté par Ellendhel (site web personnel) . En réponse au journal Internet Packet Life : avec parole. Évalué à 6.
Accessoirement, pour un public anglo-saxon, "ADSL" ne signifiera pas grand chose : les offres commerciales mentionnent uniquement "DSL". Et la grande majorité des connections se fait par câble (ou fibre optique - "FIOS" aux États-Unis - pour les plus chanceux).
# Slackware non vulnérable
Posté par Ellendhel (site web personnel) . En réponse au journal Faille de sécurité dans la GNU libc avec les requêtes DNS. Évalué à 8.
Curieusement, Slackware ne semble pas être vulnérable au problème, du fait d'un patch spécifique appliqué aux sources de glibc :
discussion et détails sur le forum LinuxQuestions.
Explications de Patrick Volkerding, mainteneur de la distribution :
# Signaler les fichiers suspects
Posté par Ellendhel (site web personnel) . En réponse au journal Analyse de l'origine d'un virus. Évalué à 10.
Il y a un formulaire en ligne pour signaler de nouveaux fichiers suspicieux :
http://www.clamav.net/reports/malware
Il faudrait sûrement envoyer le fichier exécutable ; envoyer le fichier attaché original pourrait aussi être utile.
Sinon pour le reste (récupération de fichiers depuis un serveur web infecté, …) je n'ai pas de référence exacte en tête, mais ça ne me semble pas être très nouveau…
# check-soa ?
Posté par Ellendhel (site web personnel) . En réponse au journal dDoS contre les serveurs DNS. Évalué à 3.
Merci pour ce compte rendu et pour les liens. Même si ce n'est pas le genre d'opération qu'un administrateur réseau doit avoir à gérer souvent, c'est toujours bon de savoir ce que font les autres.
Une question : d'où vient la commande check-soa ? À ma connaissance ce n'est pas un outil proposé par BIND ou Unbound. Est-ce un script personnel ou un outil tiers ?