Des Headers. En veux-tu ? En voilà !

J’ai commencé à me pencher sur HAProxy et à faire quelques tests, ce qui m’a conduit à m’intéresser aux entêtes de sécurité qu’un serveur Web peut renvoyer. Dans la même veine que SSL Labs, j’ai découvert securityheaders.io qui permet de faire rapidement le point sur les entêtes des réponses http d’un serveur pour une url donnée.

De mon côté, je me suis donc assuré de la présence des entêtes suivantes:

  • Referrer-Policy
  • Strict-Transport-Security
  • X-Content-Type-Options
  • X-Frame-Options
  • X-XSS-Protection

Configurées de la manière suivante :

http-response set-header Strict-Transport-Security "max-age=63072000;"
http-response set-header X-Content-Type-Options nosniff
http-response set-header Referrer-Policy no-referrer-when-downgrade
http-response set-header X-Frame-Options SAMEORIGIN
http-response set-header X-XSS-Protection 1;mode=block

Par ailleurs, j’en profite pour m’assurer que les informations concernant le serveur répondant à la requête ne soient pas renvoyées :

http-response del-header Server

Du coup, j’obtiens un petit A, étant donné que je n’ai pour l’instant pas intégré l’entête « Content-Security-Policy ».

Source: Securing haproxy and nginx via HTTP Headers.

Du côté du LAN

Après un long week-end de compétition au championnat de France de roller indoor, j’ai profité de la semaine de récupération qui suivait pour commencer à réorganiser mon réseau interne. Une idée que j’avais en tête depuis un moment déjà.

Au niveau de l’existant, je partais donc d’un réseau composé d’un modem-routeur OVH, d’un routeur personnel et de périphériques clients, parmi lesquelles serveur, NAS, téléphone ou encore PC. Mon objectif principal était d’arriver à me passer du matériel du FAI, afin d’exploiter mon routeur au maximum de ses capacités. Il faut préciser que le modem-routeur fournit par OVH, un technicolor TG788v2, n’est pas fantastique. Il fonctionne bien, mais l’interface n’est pas des plus intuitives, l’assignation d’IP fixe côté DHCP est une plaie et je me retrouvais avec un double NAT pas des plus pratiques.

En remplacement du routeur, j’ai donc fait l’acquisition d’un petit modem compatible avec les caractéristiques de ma ligne OVH, à savoir un DM200 de chez Netgear. J’ai configuré ce dernier en mode bridge, pour confier la gestion du réseau à mon routeur. En parallèle, j’ai migré le-dit routeur (un R7000) vers le firmware alternatif AdvancedTomato pour bénéficier de nombreuses nouvelles possibilités de configuration. Il aura fallu quelques heures pour trouver une première configuration satisfaisante, notamment du côté de la redirection de ports qui ne voulait pas fonctionner à cause d’un paramètre particulier de la configuration WAN.

Par la suite, j’ai cherché à configurer le serveur OpenVPN disponible avec Tomato. Après plusieurs essais, j’ai enfin réussi à me connecter au VPN depuis mon téléphone et à écouter avec satisfaction un fichier de musique en provenance de mon NAS. Les fichiers Flac ont malheureusement du mal à passer, la faute au peu de débit montant des connexions internet traditionnelles. Cela permettra au moins d’éviter l’explosion de la consommation de données du forfait mobile. Restait encore le problème de la ligne téléphonique. Après ajout d’un petit boîtier Cisco nommé SPA112 et connexion d’un téléphone sur l’un de ses ports RJ11, le problème était résolu.

Tous ces changements m’ont obligé de ressortir un switch inutilisé pour disposer de plus de ports, pouvoir connecter un Raspberry Pi, et commencer la suite des opérations à savoir : étudier les possibilités offertes par Ansible et par LXC dans leur domaine respectif. Le WakeOnLan figure lui aussi en bonne position sur la liste des choses à tester pour une éventuelle intégration dans l’architecture globale du réseau.

En bref, de nombreuses idées, de nombreuses pistes à explorer et une structure de réseau à valider par l’usage quotidien des prochaines semaines !

Outlook et l’affichage des pièces jointes…

Si comme moi vous en avez assez qu’Outlook vous place les pièces jointes en plein milieu du corps de vos mails professionnels, il convient de modifier le format du message pour retrouver les pièces jointes au niveau de l’entête du mail.

Pour cela, il suffit de se rendre dans le menu « Fichier » puis « Options ». Dans l’entrée « Courrier », partie « Composition des messages », modifier le paramètre « Composer les messages dans ce format: » et choisir « HTML » (ou « texte brut » si vous préférez).

Dernière chose à savoir, si vous répondez à un mail au format « RTF » (texte enrichi), votre mail de réponse sera au même format, malgré le réglage effectué ci-dessus. Il faut alors modifier explicitement le format du mail de réponse du côté de l’onglet « Format du texte » et choisir un format autre que « texte enrichi ».

HTTPS par défaut

Comme évoqué le mois dernier, j’ai effectué aujourd’hui quelques changements de configuration du côté d’Apache. L’intégralité du flux HTTP est désormais redirigé vers HTTPS à l’aide d’un simple :

Redirect permanent / https://www.unicoda.com/

J’ai effectué un test de requête avec Postman en essayant de récupérer l’une des images du site en HTTP et en précisant de ne pas suivre automatiquement les redirections. J’obtiens alors le message suivant:

 <h1>Moved Permanently</h1>
 <p>The document has moved 
   <a href="https://www.unicoda.com/wp-content/uploads/2012/09/cropped-022232111.jpg">here</a>.
 </p>

, ce qui est positif.

Le changement devrait donc être transparent, les navigateurs modernes et les moteurs de recherche étant capable de gérer automatiquement la redirection, comme l’explique clairement la documentation Mozilla.

[i3] Gestion du volume au clavier

Mon clavier actuel dispose d’une molette permettant de régler le volume. Après plusieurs essais infructueux visant à faire varier le volume via la molette dans i3, j’ai repris dernièrement le problème du début, pour enfin arriver à une configuration fonctionnelle.

Je me suis donc replongé dans la documentation d’i3 qui indique d’utiliser xev pour capturer les informations sur les touches que l’on souhaite configurer. Installation donc avec pacman sous Arch Linux : pacman -S xorg-xev. Il est ensuite possible de démarrer le programme via la commande xev. Si je fais bouger la molette vers le bas, j’obtiens les événements suivants dans xev:

MappingNotify event, serial 33, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

KeyPress event, serial 33, synthetic NO, window 0x2a00001,
    root 0x2a4, subw 0x0, time 14668027, (482,-109), root:(486,1198),
    state 0x10, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0x2a00001,
    root 0x2a4, subw 0x0, time 14668030, (482,-109), root:(486,1198),
    state 0x10, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Tout ceci n’est pas très lisible ici, mais nous pouvons tout de même isoler les informations intéressantes en particulier keycode 122 et XF86AudioLowerVolume. Pour ma part, je choisis d’utiliser le keysysm XF86AudioLowerVolume, et utiliserai donc bindsym, pour utiliser le keycode, on utilisera bindcode (non testé). En résumé, pour diminuer le volume XF86AudioLowerVolume, pour l’augmenter XF86AudioRaiseVolume et pour couper le son XF86AudioMute.

Il faut maintenant s’intéresser à la commande à effectuer dans les différents cas. Pour le contrôle du volume, je décide de passer par pactl, abréviation de PulseAudio Control. La commande est de la forme :

pactl set-sink-volume SINK VOLUME

Le paramètre SINK correspond à la sortie sonore que l’on souhaite contrôler. Pour être en mesure de déterminer son numéro, j’utilise la commande pactl list. Parmi les informations renvoyées, il faut chercher les lignes suivantes Carte #0, Carte #1, … Dans mon cas, la carte 0 indique « HDMI Audio Controller », il s’agit donc de la sortie sonore du port HDMI de mon ordinateur. Pour la carte 1, c’est déjà mieux puisqu’il est affiché « Audio interne ». Pour des informations plus concises, on utilise pactl list sinks short et on sélectionne la carte portant la mention RUNNING.

Petit test rapide, casque sur les oreilles, fond musical, j’exécute la commande suivante dans mon terminal : pactl set-sink-volume 1 -5%. Bingo ! Le volume diminue. J’en profite tout de suite pour tester la commande permettant de couper le son : pactl set-sink-mute 1 toggle. Cela fonctionne. J’ouvre donc le fichier de configuration d’i3 pour y ajouter les lignes suivantes :

bindsym XF86AudioLowerVolume exec pactl set-sink-volume 1 -5%
bindsym XF86AudioRaiseVolume exec pactl set-sink-volume 1 +5%
bindsym XF86AudioMute exec pactl set-sink-mute 1 toggle

Rechargement de la configuration.

Trois lignes de configuration qui me permettent désormais de contrôler le volume directement au niveau de mon clavier, sans avoir à le modifier dans l’application diffusant le flux audio. Pour simplifier la mise en place d’une telle configuration, on essayera de toujours procéder en trois étapes. En premier lieu, validation de la commande que l’on souhaite appeler, puis test de la prise en compte de la touche sur une commande fonctionnelle connue, et enfin réunion des étapes précédentes pour configuration finale. L’essentiel étant surtout de ne pas se hâter (« Ne soyez pas si hâtif, maître Meriadoc ! ») pour éviter de se retrouver, après configuration, sans effet visible ou audible et, de ne pas pouvoir alors, isoler immédiatement la source du problème.