Ellendhel a écrit 938 commentaires

Ça y ressemble beaucoup.

Unbound-control utilise un certificat auto-généré lors de l'installation (du moins lors d'un installation à partir des sources, avec un paquet je ne sais pas comment cela est mis en place).

Les fichiers devraient se trouver dans le répertoire /etc/unbound/ et avoir les permissions suivantes :

root@serveur:~# ls -lh /etc/unbound/
total 76K
-rw-r--r-- 1 root    root    3.1K Jun 19 09:38 root.hints
-rw-r--r-- 1 unbound unbound  759 Oct 27 11:04 root.key
-rw-r--r-- 1 root    root     24K Jun 22 16:10 unbound.conf
-rw-r--r-- 1 root    root     25K Jun 19 09:35 unbound.conf.original
-rw-r----- 1 root    root    1.3K Jun 19 09:35 unbound_control.key
-rw-r----- 1 root    root     802 Jun 19 09:35 unbound_control.pem
-rw-r----- 1 root    root    1.3K Jun 19 09:35 unbound_server.key
-rw-r----- 1 root    root     790 Jun 19 09:35 unbound_server.pem

Il est important que les permissions soient bien placées, sinon Unbound ne fonctionnera pas.

Un peu de documentation sur Unbound si cela peut aider (entre autre si les certificats n'on pas été générés).

Et pour aider à résoudre le problème, que donne les réponses pour les deux commandes suivantes :

unbound-control status

et

dig +multi +dnssec SOA .

Il y a bien un point ("racine") à la fin de la seconde commande.

Non, il n'y a pas besoin d'ajouter de directive foward-zone, bien au contraire !

Utiliser ces deux adresses IPv4 (celles des résolveurs OpenDNS soit dit en passant) donnerait un résultat opposé à celui recherché (les serveurs seraient utilisés pour toute les requêtes, au lieu de passer par le mécanisme de résolution DNS). À partir du moment où les fichiers root.hints et root.key sont correctement définis, les bases sont en place.

Au niveau du pare-feu, les règles de filtrages ne doivent pas être restrictives, iptables doit retourner un résultat de ce type :

# iptables -L OUTPUT -n -v | grep dpt:53
  950 69340 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53

Les accès en sortie (output) doivent être autorisés vers n'importe quelle addresse IP (pour joindre n'importe quel server, la racine pour commencer) en UDP et TCP (TCP est utilisé pour DNSSEC). Et évidemment les accès pour les réponses doit être ouvert (state RELATED,ESTABLISHED ou à défaut des règles explicites).

J'utilise des bornes d'accès HP MSM430 et par défaut le réglage des radios 1 et 2 autorise 255 clients (ce que j'ai diminué plus ou moins arbitrairement à 64).

Quelques points à noter : c'est du matériel de gamme "professionnel" et le prix s'en ressent (environ $500 pièce). HP vend ces bornes avec l'idée que l'on achète un contrôleur (ce qui est sûrement appréciable, mais pas indispensable). L'interface web est claire et permet de gérer beaucoup de choses (l'interface SSH est par contre assez limitée).

Il faut obligatoirement un commutateur capable de fournir du courant pour la borne (PoE) ou utiliser un "Power Injector". Sur d'anciennes version du firmware les certificats de sécurités ne gèrent que SSLv3 ; cela à été réglé avec des mises à jour (le certificat par défaut est en TLSv1 sur les bornes récentes).

En ce qui concerne la couverture WiFi à proprement parler, j'ai des dizaines d'étudiants qui utilisent le réseau quotidiennement et très peu de problèmes.

Je ne connais pas aussi bien les produits équivalents des concurrents (Cisco Aironet, …) mais il est probable que tu puisses trouver quelque chose de similaire.

Un bon point de départ est la lecture du site web nommé "Formation Debian GNU/Linux" :

http://formation-debian.via.ecp.fr/

Il y a probablement des points qui ne sont plus tout à fait à jour mais cela devrait couvrir le plus important, hormis pour ce qui est spécifique au Raspberry Pi,

L'administration système est un domaine vaste, et il est toujours bon de savoir à l'avance "que faire et comment" plutôt que d'apprendre suite à une commande mal saisie ou un câble mal branché… (même si l'apprentissage par l'erreur fonctionne bien, ce n'est pas une raison pour multiplier les erreurs :-).

Plusieurs liens ont déjà été postés, et j'aimerais ajouter deux livres comme source de référence.

Le premier n'est pas un livre technique, mais plutôt sur la pratique du métier. Il est dense (1056 pages), en anglais, mais il aborde énormément de choses et est illustré par des exemples. Fortement recommandé.

The Practice of System and Network Administration, 2nd Edition
Thomas A. Limoncelli, Christina J. Hogan & Strata R. Chalup
ISBN 978-0321492661

http://everythingsysadmin.com/books.html

Le second est technique, certainement un peu trop vieux, et orienté "Linux et Unices" (il inclue des "vieux" systèmes UNIX tel que AIX ou HP-UX) et décrit comment gérer tel ou tel besoin (ajouter des utilisateurs, configurer un serveur DHCP, …). Il existe en anglais, peut-être est-il possible de trouver une vieille version française. Et c'est aussi un pavé (1178 pages). Il n'est pas aussi important que le premier, mais si tu as l'opportunité de le trouver d'occasion ou de le consulter dans une bibliothèque (probablement en bibliothèque universitaire), cela vaut la peine d'y jeter un œil.

Essential System Administration, 3rd Edition
Æleen Frisch
ISBN 978-0-596-00343-2

http://shop.oreilly.com/product/9780596003432.do

Bonne lecture !

Il existe également un add-on pour Mozilla Firefox nommé CCK2 qui permet de personnaliser et verrouiller une installation de Mozilla Firefox qui doit pouvoir faire un travail similaire.

https://addons.mozilla.org/en-US/firefox/addon/cck2wizard/?src=kaply.com

Comme probablement d'autre personnes j'ai eu un peu de mal a avoir une définition claire de ce que peut représenter le terme DevOps ; plusieurs personnes ou organisations y vont de leur point de vue.

Suite à une recommandation de Tom Limoncelli (auteur, entre autre, de Admin'sys - Gérer son temps…) j'ai lu le roman "The Phoenix Project" à ce sujet.

Oui, c'est un roman, pas un guide technique, le protagoniste principal se retrouve propulsé responsable informatique et doit gérer une situation de crise sans trop savoir comment s'y prendre et c'est dans ce contexte qu'il découvre et décide de changer les méthodes et les outils utilisés. Le côté "fiction ¹" rend les choses faciles à lire (pour qui lit l'anglais) et l'histoire est assez prenante. L'inconvénient est que l'on se retrouve sans "fiche pratique" et qu'il est plus difficile d'utiliser le livre comme référence par la suite.

Et on voit bien que la méthode DevOps ne concerne pas seulement les outils techniques (virtualisation/containers, tests, gestion de configuration, …) mais aussi la communication entre les membres d'un même équipe et avec le reste de l'organisation.

Je n'ai pas appliqué de méthode DevOps à proprement parler là où je travaille (la structure n'est pas suffisamment importante) mais il y a un certain nombre d'idées que j'ai essayé de mettre en place et certaines ont vraiment apporté des améliorations.

1) si vous avez un peu d'expérience dans le domaine, vous reconnaîtrez certaines situations comme très réalistes

(…) malus pour les emails non signés dans les notations de spam

En théorie on peut déjà s'appuyer sur DKIM pour cela : un certain nombre d'en-têtes de courrier peuvent être signés au niveau du serveur (après configuration par l'administrateur, rien à faire pour les utilisateurs) et le serveur du destinataire peut vérifier la signature (ou noter son absence) et décider d'un filtrage spécifique ou non. Je ne connais pas de statistiques à ce sujet, si c'est beaucoup utilisé ou non, mais c'est possible.

Comme toute restriction sur des logiciels, ce n'est pas une bonne nouvelle, surtout si cela est clairement influencé par la communauté du renseignement.

D'un autre côté, comme le montre l'exemple cité par l'EFF, il y existe des entreprises qui se soucient plus de remplir leur tiroir-caisse que de sécurité informatique et ce n'est pas le genre de comportement qui améliore les choses.

Je ne vois pas de solution simple ou facile, et encore moins à mettre en pratique… La recherche de failles, leur communication et les correctifs devraient rester libre autant que possible, et un système de récompense (bounty) pourrait être défini. Par contre la vente commerciale de 0-day ne devrait pas avoir lieu (même si je ne suis pas naïf, cela n'empêchera pas un marché noir, y compris avec des acteurs gouvernementaux). Et au-delà de la réglementation se pose la problème de mise en application application (par Interpol, des services de douanes, une simple émission de licence, … ?).

Un autre article sur la création d'une clé et de sous-clés, avec des choix personnels sur certains points (tels que l'expiration), est disponible sur le blog de S. Bortzmeyer.

Soit la réunion se déroulera au bar, qui est accessible à tous.

Ce qui peut engendrer certains problèmes pour une keysigning party…

Ce qui est défini et géré par l'Arrangement de Wassenaar (on peut aussi consulter le site officiel). Ce sont ces règles qui limitent officiellement l’importation et l'exportation de moyens cryptographiques.

Et si ton serveur DHCP a deux interfaces réseau distinctes, il est aussi possible de modifier le script de démarrage pour que le daemon ne s'attache qu'à une des interfaces et ignore l'autre.

D'après la page de manuel (qui n'est pas très explicite) :

dhcpd (...) [ if0 [ ...ifN ] ]


The names of the network interfaces on which dhcpd should listen for broadcasts may be specified on the command line.

Vais voir avec les règles "iptables".

Pour information, il existe un autre outil qui travaille au niveau Ethernet : ebtables (que je n'ai jamais utilisé cela dit). iptables est aussi une bonne solution.

Site officiel d'ebtables

Existe-t-il un moyen de configurer mon serveur DHCP pour qu'il réponde uniquement à certaines machines (adresse MAC par exemple) (…) ?

Oui, on peut créer un bloc de configuration par client, en spécifiant l'adresse MAC. Extrait de la page de manuel de ISC dhcpd :

host haagen {
              hardware ethernet 08:00:2b:4c:59:23;
              fixed-address 239.252.197.9;
              filename "/tftpboot/haagen.boot";
            }

Cela permet d'attribuer une adresse IPv4 (et d'autres options au besoin) pour un client particulier.

Par contre je ne suis pas certain que le serveur ne réponde "rien" aux clients non autorisés.

La question d'utiliser du chiffrement n'est pas simplement une question de connaissance ; non seulement il faut savoir comment les choses fonctionnent (et fonctionnent correctement, sans faire d'erreur) mais de plus il faut l'appliquer de manière consistante. Chiffrer ou signer ses messages ne devrait pas être une action ponctuelle, mais devrait être appliqué systématiquement, tout le temps.

Et il ne faut pas se leurrer : quelque chose de compliqué et qui requiert un effort constant n'est pas très vendeur. D'autant plus que pour beaucoup de personnes, un ordinateur est censé effectuer les besognes compliquées et répétitives à leur place ; donc demander de faire des efforts supplémentaires en utilisant un ordinateur est presque contradictoire.

Je reste d'accord : les pratiques autour du chiffrement sont claires et définies, mais les outils ne sont "pas à la hauteur". Je sais que des projets existent pour améliorer cela, mais il reste du chemin à faire…

Par contre je n'ai rien compris au script, (désolé)

Aucun souci, les scripts shells ne sont pas toujours limpides ; voici quelques détails :

• de la ligne commençant par "TMPFILE" jusqu'à celle finissant par "$OUTFILE", c'est la création d'un fichier temporaire qui contient le message de test. Cela évite d'utiliser un fichier texte externe pour le corps du message.

• la ligne débutant par "env MAILRC" est celle qui effectue l'envoi du mail. Un certain nombre d'options sont définies en premier lieu (serveur SMTP utilisé, utilisateur et mot de passe, adresse et identité de l'expéditeur puis la commande mailx (mail est généralement un alias pour cette commande) est lancée en définissant le sujet, l'adresse de destination et le corps du message (le fichier temporaire crée précédemment) est envoyé en entrée. Si tu as besoin de plus de détails, le mieux est de consulter la documentation (man mailx).

• enfin, les lignes suivantes sont là pour afficher un message de réussite ou d'échec selon le résultat de la commande mailx, et comme des codes couleurs (vert/OK, rouge/FAIL) sont utilisés, le code est indigeste à lire. Et le fichier temporaire est supprimé au final.

Ce script peut être utilisé depuis un compte utilisateur standard (non root), il faut bien renseigner les options pour l'identité de l'expéditeur (smtp-auth-user, smtp-auth-password, from).

Et pour rappel, il peut être bon de vérifier et mettre à jour le fichier /etc/aliases sur la machine.

Si un message envoyé via la commande mail est signé correctement par OpenDKIM alors la configuration du serveur n'est pas en cause, et la source est probablement "du côté de la liaison extérieure".

Voici un petit script shell que j'utilise pour effectuer des tests avec la commande mail et différentes options (bien indiquer le nom d'utilisateur et le mot de passe pour les options correspondantes [ oui le mot de passe est en clair, attention à ne pas laisser le script traîner n'importe où ] ) :

#!/bin/bash

# test email script

# Options for a SMTPS server:
# - smtp-auth-user=<username>
# - smtp-auth-password=<password>
# - smtp-auth=login
# - smtp-use-starttls=1
# - ssl-verify=ignore (not necessary if the certificate is known by the system)

# create a temporary file for the message
TMPFILE=$(mktemp /tmp/test-mail.XXXXXX)
OUTFILE=$TMPFILE
(
cat << EOF
Hi,

This is a test e-mail.  Please do not respond.

Sincerely.
--
Me
EOF
) > $OUTFILE

env MAILRC=/dev/null smtp=smtp://smtps.example.net smtp-auth-user=username smtp-auth-password=password smtp-auth=login smtp-use-starttls=1 from="user@example.net (Me)" mailx -n -s "Test Message" recipient@example.com < $TMPFILE

if [ $? -eq 0 ]
then
    printf "\n Sending e-mail to: recipient@example.com\t[ "'\e[1;32m'"\033[1mOK\033[0m"" ]\n"
else
    printf "\n Sending e-mail to: recipient@example.com\t[ "'\e[1;31m'"\033[1mFAIL\033[0m"" ]\n"
fi

rm $TMPFILE

# EoF

Après, pour la connexion avec MS Outlook, je ne peux malheureusement pas apporter beaucoup d'aide.

Pour le fichier aliases, il faudrait vérifier que le domaine listé est bien celui qui doit être signé (par de confusion entre .fr et .com). Également, régénérer le fichier aliases (avec la commande newaliases) pour que les changements soit pris en compte (ce qui est signalé dans les logs avec la ligne "warning: database /etc/aliases.db is older than source file /etc/aliases").

Je n'ai pas vu d'erreur particulière dans la configuration, mais il y a un détail qui me fait réagir dans les logs:

Feb 11 13:23:07 enfer opendkim[12825]: BC73B2241099: external host mon.domaine.fr attempted to send as domaine.com

OpenDKIM ne signera pas les messages pour un autre domaine que celui pour lequel il est configuré, et il semble que ton message est envoyé depuis un domaine différent. Je n'ai pas regardé ce point dans la documentation, mais il est peut-être possible de paramétrer la signature pour une liste de domaines ; c'est à vérifier.

Les fichiers journaux se trouvent dans /var/log

Pour trouver quel fichiers sont utilisés par Postfix ou OpenDKIM, tu peux utiliser la commande suivante :

grep -i --color postfix /var/log/*

Et selon les résultats tu peux consulter les fichiers indiqués avec la commande view (qui lance l'éditeur vi en mode lecture seule, ce qui évite de modifier les fichiers par accident) ou tout autre commande utilisable pour afficher le contenu d'un fichier texte (cat, more, …) :

view /var/log/mail

Une commande utile pour effectuer des tests est d'utiliser la commande tail en mode "flux" :

tail -f /var/log/mail

De cette manière l'affichage du fichier se fait en continu (les nouveaux messages apparaissent au fur et à mesure). Utiliser la combinaison Ctrl + C pour l'arrêter.

Je pars du principe que les enregistrements DNS pour la vérification de signature sont en place (dans tous les cas, ce n'est pas cela qui influe sur le mécanisme de signature proprement dit).

Quelle configuration est en place pour Postfix ? Voici quelques conseils basés sur mon propre serveur (Slackware 14.0).

Les choses fonctionnent en ayant ajouté les lignes suivantes dans le fichier main.cf :

smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = $smtpd_milters
milter_default_action = accept
milter_protocol = 2

Le daemon OpenDKIM fonctionne en local, et les paramètres suivants ont été définis dans le fichier opendkim.conf (en gardant les paramètres par défaut par ailleurs) :

Selector                smtps
KeyFile                 /usr/local/etc/smtps.private
Mode                    s
Socket                  inet:8891@localhost
PidFile                 /var/run/opendkim.pid
Domain                  example.net

L'un des points important ici est d'avoir le Mode s qui définit la signature des messages (l'autre mode, v, peut être utilisé indépendamment ou en combinaison pour vérifier les messages entrants).

Au final, y a t-il des messages d'erreurs dans les fichiers journaux ? OpenDKIM envoie probablement ses messages dans le même fichier que Postfix.

Sur la page de la Wikipédia anglophone à propos de Pretty Good Privacy.

Zimmermann (qui n'est pas impliqué dans l'histoire du télégramme) s'est basé un moyen "courant" aux États-Unis : la liberté d'expression, telle que protégée par un amendement de la constitution américaine.

En cherchant un peu je suis tombé sur Mailvelope qui pourrait être une solution.

Cet outil repose sur la bibliothèque Javascript OpenPGP.js, tu peux regarder de ce côté pour voir si d'autres solutions te conviendrait mieux.

Avertissement : je n'ai ni utilisé, ni testé les outils en question, je me base uniquement sur ce qui est décrit sur les sites web.

Ou Slackware. Très bien ça, Slackware.

Et ça devrait permettre de rester à l'abri de systemd pendant encore un petit moment je pense.