FreeBSD: Opensmtpd en relay localhost

Bonjour à tous,

Aujourd'hui un petit billet rapide sur la mise en place d'Opensmtpd servant de relay pour l'envoi de mail vers root et configuré uniquement pour accepter les connexions depuis le localhost.

En premier lieu, il faut procéder à son installation:

pkg install opensmtpd

Il faut ensuite modifier le fichier /etc/rc.conf afin de désactiver Sendmail (qui sert par défaut à l'envoi des mails interne) puis d'activer opensmtpd:

# Disable Sendmail MTA
sendmail_enable="NO"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"

smtpd_enable="YES"

Nous pouvons maintenant passer à sa configuration qui, dans notre cas va être très simple. Le fichier de configuration se trouve ic /usr/local/etc/mail/smtpd.conf.

# This is the smtpd server system-wide configuration file.
# See smtpd.conf(5) for more information.

# To accept external mail, replace with: listen on all
listen on 127.0.0.1
listen on ::1

# If you edit the file, you have to run "smtpctl update table aliases"
table aliases db:/usr/local/etc/mail/aliases.db
table secrets db:/usr/local/etc/mail/secrets.db

accept from local for domain votredomain.fr relay via tls+auth://label@votreserveur.votredomain.fr auth 

il est nécessaire de spécifier le compte depuis lequel le mail sera envoyé et depuis lequel l'authentification au niveau du serveur de mail sera effectuée. Pour cela il faut créer le fichier /usr/local/etc/mail/secrets:

label email@votredomain.fr:password

Il est possible d'utiliser le fichier d'aliases se trouvant dans /etc/aliases mais j'ai préféré ne pas y toucher et en faire une copie à coté du fichier de configuration d'opensmtpd:

cp /etc/aliases /usr/local/etc/aliases

Il reste à l'éditer afin de changer l'adresse mail associé à root.
Une fois ces modifications faites, il faut générer/regénérer les fichiers db, pour cela rien de plus simple:

/usr/local/libexec/opensmtpd/makemap secrets
/usr/local/libexec/opensmtpd/makemap aliases

Le service doit être maintenant démarré afin d'être opérationnel:

service smtpd start

Le relay de vos mails locaux est désormais opérationnel!

Si vous souhaitez voir la file d'attente du relay:

smtpctl show queue

Si vous souhaitez supprimer un message rien de plus simple. En premier lieu, il faut afficher la queue (comme vu précédemment) puis utiliser la commande suivante:

smtpctl remove idmessage

Il suffit de remplacer idmessage par l'identifiant du mail à supprimer.

Have a nice day.

FreeBSD: routage avec des vtnet

Bonjour à tous,

Un petit billet portant sur la mise en place d'une machine virtuelle sous FreeBSD avec des cartes en VIRTIO (sous proxmox 4) qui servira de routeur (et de firewall).
Au départ j'utilisais des cartes en e1000 mais le type VIRTIO est censé être plus performant.

Un souci simple mais très handicapant s'est présenté: les paquets arrivent bien sûr les interfaces mais n'en repartent jamais.
Cependant, un tcpdump voyait bien les paquets arriver, montrait bien leur départ mais la commande (un ping par exemple) tombait en timeout.

Le fautif: le checksum offload hardware. Ce mécanisme sert à décharge le checksum des entêtes au niveau de la carte réseau (si elle possède cette capacité).

Pour le désactiver rien de plus simple:

ifconfig vtnet0 -rxcsum -txcsum

Le voici désactivé pour l'IPv4.
Si vous faites de l'IPv6, la commande n'est pas plus compliquée:

ifconfig vtnet0 -rxcsum6 -txcsum6

Et le ping est fonctionnel.
Ce souci était présent sur tout ce qui passait par ce routeur, que ce soit du simple icmp ou de l'http/https.

Cependant attention! au prochain reboot, la modification n'est plus effective. Pour que cela soit persistent, il faut rajouter ce qui suit dans votre /etc/rc.conf :

ifconfig_vtnet0="inet bla netmask bla -rxcsum -txcsum"
ifconfig_vtnet0_ipv6="inet6 bla prefixlen 64 -rxcsum6 -txcsum6"

La modification sera valable tout le temps maintenant.

Have a nice day.

Boris

FreeBSD: poudriere ou comment gérer ses paquets

Edit 23/03/16: maj de l'article pour le vhost et la déclaration du nouveau répo.

Bonjour à vous,

Aujourd'hui, un long billet qui va porter sur un logiciel FreeBSD: Poudriere.

Pour débuter, une petite explication : Poudriere est un logiciel permettant d'automatiser et de maintenir un serveur de packages privé. Il permet de compiler automatiquement une série de packages avec des options de compilation ainsi qu'un environnement prédéfini.
Privé au sens qu'il n'est pas dans la liste des dépôts publics de FreeBSD, mais si vous suivez ce billet, il le sera de tous ceux qui connaissent l'URL.

Par exemple, si vous avez besoin d'une version de php/perl fixe pour un environnement donné, il vous suffit de le fixer dans les fichiers de configuration dédié à cet arbre de ports. Ce qui permettra de ne pas changer d'environnement lors des prochains updates.

Prérequis

Afin de pouvoir utiliser Poudriere dans les meilleures conditions, ZFS est nécessaire.

Pour activer ZFS, il suffit de faire:

echo 'zfs_enable="YES"' >> /etc/rc.conf

Son utilisation permet d’accélérer la création de jails et le traitement des fichiers des différents ports.

Installation

L'installation de Poudriere est tout ce qu'il y a de plus classique :

pkg update
pkg install poudriere

Maintenant, il faut créer le dossier qui sera le point de montage du zpool ZFS:

mkdir /Poudriere
zpool create -m /poudriere poudriere /dev/vtbd1

Vous pouvez changer le dossier sans soucis. Cependant, il faudra adapter le reste du billet à ce changement.

Nous allons maintenant passer à la configuration de base de Poudriere.
Cela se passe dans le fichier /usr/local/etc/poudriere.conf :

ZPOOL=poudriere
ZROOTFS=/poudriere
FREEBSD_HOST=ftp://ftp.freebsd.org
RESOLV_CONF=/etc/resolv.conf
BASEFS=/usr/local/poudriere
USE_TMPFS=yes
ALLOW_MAKE_JOBS=yes

Petite explication des options ci-dessus:

  • ZPOOL : le nom de votre pool ZFS
  • ZROOTFS : la racine de votre pool (ou le point de montage)
  • FREEBSD_HOST : l’hôte à partir duquel télécharger les ports et la distribution. A adapter suivant votre pays afin d'avoir de meilleures performances.
  • RESOLV_CONF : le fichier de configuration du client DNS utilisé par poudrière.
  • BASEFS : le répertoire où poudrière va mettre ses jails et ports
  • USE_TMPFS : demander à Poudriere d’utiliser un TMPFS pour la compilation, il est possible de le désactiver en commentant la ligne si vous êtes limité en ram.
  • ALLOW_MAKE_JOBS=yes : permet de compiler un port avec plusieurs cpu/coeurs.

Ports et jail

Nous allons maintenant créer un arbre de ports par défault:

poudriere ports -c -p default

Options:

  • -c : indique la création de l'arbre de ports
  • -p : définie le nom de l'arbre de ports créé

Le nom peut être changé (ici default) au moment de la création.
/!\ Attention! Une fois créé il n'est plus possible de le changer.

Nous passons maintenant à la création de notre première jail:

poudriere jail -c -j "F102" -v "10.2-RELEASE" -a amd64

Options:

  • -c : indique la création de la jail
  • -j : définie le nom de la jail
  • -v : définie la version de FreeBSD voulue
  • -a : définie l'architecture voulue

Dans ce cas précis, je crée une jail pour la version 10.2 de FreeBSD avec comme architecture AMD64.

Fichiers make

Les fichiers de configuration pour la compilation (make.conf) sont stockés dans un dossier en particulier.
Il faut vérifier si ce dossier est bien présent, sinon il faut le créer:

mkdir /usr/local/etc/poudriere.d

Il est ensuite possible de passer des paramètres (ou knobs) à toutes les jails de Poudriere par le biais du fichier make.conf:

echo "WITH_PKGNG=yes" > /usr/local/etc/poudriere.d/make.conf
echo "WITHOUT_X11=yes" >> /usr/local/etc/poudriere.d/make.conf

Avec ces paramètres dans ce fichier en particulier, TOUTES les compilations seront faites avec le support de PKG pour l'installation des packets et sans le support X11.

Il est possible d'ajouter ces options uniquement pour une jail en particulier, il faudra pour cela ajouter ces options dans le fichier dédié à la jail. Par exemple dans le fichier F102-make.conf au lieu de make.conf.

Afin de gérer les logiciels à compiler, on peut soit préciser les logiciels à la main lors du lancement de la compilation ou les mettres dans un fichier. J'ai choisis la deuxième méthode, voici par exemple le contenu du fichier /usr/local/etc/Poudriere.d/F102-ports :

editors/nano
www/nginx

Une fois ce fichier renseigné, il faut choisir les options de compilation. La commande suivante est l'équivalent d'un make config-recursive:

poudriere options -f /usr/local/etc/poudriere.d/F102-ports -j F102 -p default

Compilation

Il ne reste plus qu'à lancer la compilation des logiciels que nous avons choisis:

poudriere bulk -f /usr/local/etc/poudriere.d/F102-ports -j F102 -p default

Options

  • -f : spécifie un fichier avec une liste de paquets à compiler
  • -p : spécifie le nom de l'arbre de ports à utiliser

Une fois la compilation terminée, il est possible de vérifier le contenu de l'arbre de ports:

ls -al /usr/local/poudriere/data/packages/F102-default

Le dossier peut être différence suivant le paramètre que vous avez fixé dans le fichier de configuration.

Update

Une fois ces premières étapes réalisées, la maintenance et l'update de notre arbre de ports, de notre jail et donc par association de la compilation qui va avec ce fait de la manière suivante.

En premier lieu, il faut mettre à jour notre arbre de ports:

poudriere ports -u -p default

Options:

  • -u : indique que nous voulons mettre à jour notre ports.
  • -p : spécifie le nom de l'arbre de ports à mettre à jour.
poudriere bulk -f /usr/local/etc/poudriere.d/F102-ports -j F102 -p default

Une fois la compilation terminée, vous aurez un rapport sur les paquets compilés. Deux formes de rapport: dans le shell directement avec le nombre de packages compilés, les échecs et les warning. Il y a également une page HTML regroupant ces informations.

Mise à disposition des paquets

Une fois les paquets compilés, il faut les mettre à disposition par le biais d'un serveur HTTP afin qu'ils soient accessibles par les serveurs.

Pour cela deux solutions:

  • Soit vous exposez directement le dossier /use/local/poudriere/data/packages/F102-default (chemin qui peut changer en fonction de ce que vous avez renseigné dans le fichier de configuration de Poudriere).
  • Soit vous faites une synchronisation de ce dossier sur un autre serveur qui lui mettre à disposition par HTTP les paquets.

De mon côté j'ai choisis la deuxième solution avec comme serveur HTTP Nginx.

Il faut mettre en place une réplication des packages entre l'arborescence de Poudriere et le serveur HTTP. Pour cela, rien de plus simple: rsync.

rsync -az /use/local/poudriere/data/packages/ serveur_ip_ou_nom:/chemin/vers/cible

Options:

  • -az : a pour le mode archivage qui permet de conserver les droits/permissions et de copier de façon récursive. z pour compresser les données avant l'envoie.

Cette commande utilise automatiquement SSH, il n'est plus nécessaire de le préciser.

Il est possible de rajouter un v (donc -avz) pour avoir un mode verbose, utile pour la première synchro.

Reste maintenant à configurer la partie HTTP. Pour cela, je créé un fichier de vhost dédié:

server {
    listen       80;
    listen       [::]:80;
    server_name  repo.securmail.fr;

    access_log  /var/log/repo/access.log;
    error_log   /var/log/repo/error.log;

    location / {
        root   /var/www/repo/;
        index  index.html index.htm;
        autoindex on;
    }
}

Attention! C'est du HTTP uniquement car je n'ai pas réussi à faire fonctionner pkg avec un repo en HTTPS et certificat autosigné.

Plusieurs choses sont importantes:

  • les logs: il faut faire attention que le dossier existe bien, sinon vous pouvez le changer sans soucis.
  • root: il s'agit du dossier où vont se trouver les packages, à adapter en fonction de la où vous les avez synchronisés.
  • autoindex: il est obligatoire d'avoir cet option d'activé, cela permet de lister automatiquement le contenu du dossier.

Il vous suffit d'effectuer un reload de Nginx et normalement votre repository privé sera opérationnel!

Afin de maintenir cette infrastructure en bon état de marche, il est possible de réaliser un script qui effectue les étapes d'update, de compilation et de synchronisation appelé depuis une tâche cron. Cela permettra d'avoir une arborescence toujours à jour.

Ce script sera aussi accessible pour un lancement à la main si vous souhaitez rajouter un logiciel qui n'est pas présent au sein du repository et que vous souhaitez l'ajouter sans délais.

Ajouter son repository

Maintenant que notre repository est accessible, il faut l'ajouter sur nos différents serveurs FreeBSD. Pour cela il faut créer le fichier suivant /usr/local/etc/pkg/repos/local.conf.
Il faut vérifier si le dossier /usr/local/etc/pkg/repos/ existe sinon, il faut le créer:

mkdir -p /usr/local/etc/pkg/repos/

Nous allons maintenant remplir le fichier local.conf

nano /usr/local/etc/pkg/repos/local.conf

Avec comme contenu:

myrepo: {
    url: "pkg+http://repo.yourdomain.fr/F102-default",
    mirror_type: "srv",
    signature_type: "none",
    fingerprints: "/usr/share/keys/pkg",
    enabled: yes
}

Suivant comment vous avez nommé votre repository, il faudra changer F102-default par ce que vous avez choisis.
Il est possible de changer le nom de notre repository en changeant myrepo par ce que vous souhaitez.

Une fois ce fichier complété, il suffit de faire:

pkg update
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
Updating myrepo repository catalogue...
Fetching meta.txz: 100%    264 B   0.3kB/s    00:01    
Fetching packagesite.txz: 100%    3 KiB   3.1kB/s    00:01    
Processing entries: 100%
myrepo repository update completed. 8 packages processed.
pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
Updating myrepo repository catalogue...
myrepo repository is up-to-date.
All repositories are up-to-date.
Updating database digests format: 100%
New version of pkg detected; it needs to be installed first.
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
    pkg: 1.6.3 -> 1.6.4 [myrepo]

Comme vous le constatez, notre repository est bien accessible et prit en compte.

A partir de ce point, il ne vous reste plus qu'à ajouter les logiciels dont vous avez besoin à votre repository.

Have a nice day.

PS: un grand merci à Solène Rapenne pour son aide et ses conseils :)

Perc H200: passage en firmware IT

Bonjour à vous,

Aujourd'hui, un billet portant sur le changement du firmware d'une carte Perc H200 de la version IR (raid) à la version IT (JBOD).

!!! Je ne peux être tenu responsable des conséquences qui pourrait survenir sur votre matériel.

En premier lieu, nous allons avoir besoin d'une clé USB bootable avec MS-DOS/FreeDOS dessus.
Pour cela, la technique la plus simple est d'utiliser Rufus:
http://rufus.akeo.ie/

Il suffit de télécharger l'exécutable, puis de le lancer. L'affichage est explicite, il n'y a pas besoin de screenshot.

Une fois la clé USB prête, il faut télécharger et copier dessus ces fichiers:
http://www.mediafire.com/download/29q484590086wvh/LSI-9211-8i.zip
Avec cette archive, vous avez tous les fichiers nécessaires pour effectuer le changement de firmware. Elle contient différentes versions du programme servant à flasher, des firwmares en version différentes et pour plusieurs cartes.
Il suffit d'extraire et de copier son contenu sur la clé.

Merci à Mattr pour le dossier très complet!
Son site: https://techmattr.wordpress.com

Il faut maintenant booter sur la clé.
Si vous avez une carte-mère avec un bios UEFI, il faut choisir dans le menu de boot la clé USB en faisant bien attention qu'elle porte le tag UEFI. Si vous avez un bios standard, pas de soucis vous pouvez booter sur la clé normalement.

Si vous êtes dans le cas d'un bios UEFI, vous devez arriver dans le shell UEFI. À ce moment là, vous saisissez la commande:

map -b

Cette commande vous liste tous les disques accessibles.
Votre clé USB est facilement repérable: elle devrait être la seule tagguée USB.
Une fois son numéro trouvé, il vous suffit de faire cela:

hd44e0b:

(Où hd44e0b est votre numéro de clé)

Cette opération va vous sélectionner votre clé et vous permettre d'utiliser les fichiers qui sont présents dessus.

La suite est commune aux deux modes (seule l'extension de l'utilitaire change, .efi dans le cas d'un bios UEFI et .exe pour un bios normal).

sas2flash -listall
sas2flash -c 0 -list

Noté bien la ligne SAS ADDRESS.

On efface les informations du constructeur:

megarec -writesbr 0 sbrempty.bi
megarec -cleanflash 0

!!! Il faut obligatoirement flasher en premier le firmware 6GBPSAS, pour ensuite pouvoir flasher le firmware LSI.

!!! Attention de bien utiliser la version sas2flash et pas la version sas2flash-p17 qui ne permet pas de passer d'un firmware IR à un IT

sas2flash.efi -o -f 6GBPSAS.FW
sas2flash.efi -o -sasadd 500xxxxxxxxxxxxx

Un reboot est maintenant nécessaire.

Si la ligne SASADDRESS a été perdue ou mal nôtée, il est possible de mettre une adresse générique: 500605B000000001.
Le plus important étant la première partie (500605B) qui correspond au début des adresses des contrôleurs LSI.

Une fois le reboot effectué, il faut revenir dans le shell UEFI (comme à la première étape du billet), et saisir la commande suivante:

sas2flash.efi -o -f 2118it.bin

Cette commande permet de flasher le firmware IT sur la carte.
Un reset de la carte est effectué à la fin du flash.
Si cette partie échoue, il suffit de redémmarer et de revenir dans le shell UEFI afin de pouvoir accéder aux nouvelles informations de notre carte.
Pour cela, il faut saisir ces commandes:

sas2flash -listall
sas2flash -c 0 -list

Nous pouvons constater que les informations de la carte ont bien changé et que le modèle de firmware est différent.
Si le modèle de contrôleur apparait comme cela: SAS2008(??), il faut utiliser la dernière version de sas2flash:

sas2flash-p17 -c 0 -list

Et tout apparaîtra comme il faut.

Have a nice day.

DNSSEC avec Bind9

Bonjour à tous,

Aujourd'hui, un billet sur la mise en place de DNSSEC avec Bind sous Debian/
DNSSEC permet de chiffrer les données envoyées, pas uniquement un canal entre serveurs DNS, cela permet d'éviter des attaques du style MiM si un serveur DNS intermédiaire est corrompu.

En premier lieu, il est nécessaire d’éditer /etc/bind/named.conf.options pour activer la prise en compte de DNSSEC. Il faut ajouter:

dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;

La première ligne active tout simplement le support de DNSSEC pour Bind.
La seconde indique que le résolveur doit en premier lieu essayer d'utiliser DNSSEC.
Enfin la dernière est une option permettant de faciliter l'adoption de DNSSEC en facilitant sa configuration sur les serveurs récursifs. Attention cependant, si vous utilisez une version de Bind trop ancienne, elle ne sera pas compatible avec DNSSEC.

Une fois cet ajout fait, il faut générer les couples de clés, si vous utilisez des dossiers par zone (comme moi), il faut vous situer dedans pour la génération:

cd /etc/bind/boris-tassou.fr/
dnssec-keygen -a NSEC3RSASHA1 -b 4096 -n ZONE boris-tassou.fr
dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 8192 -n ZONE boris-tassou.fr

ATTENTION! au choix de l’algorithme de chiffrement, en fonction du provider certains ne sont pas supportés.

Nous allons maintenant renommer les clés générées afin de mieux s’y retrouver et de mieux les gérer. Le meilleur moyen est de le faire au faire et à mesure (cela évite des confusions):

mv Kboris-tassou...+0..key Kboris-tassou.fr.zsk.key
mv Kboris-tassou...+0..key Kboris-tassou.fr.zsk.private
mv Kboris-tassou...+0..key Kboris-tassou.fr.ksk.key
mv Kboris-tassou...+0..key Kboris-tassou.fr.ksk.private

Une fois la génération des couples (étapes qui peut-être très longue suivant la machine), il faut ajouter deux lignes dans le fichier de zone afin d'avoir la prise en compte des clés générées au préalable:

$INCLUDE Kboris-tassou.fr.zsk.key
$INCLUDE Kboris-tassou.fr.ksk.key

Une fois cette étape faite, il faut signer le fichier afin de pouvoir l’utiliser (étape à refaire à chaque modification du fichier de zone):

dnssec-signzone -e20160101 -t -g -A -3 $(head -c 1000 /dev/random | sha1sum | cut -b 1-16) -N INCREMENT -k Kboris-tassou.fr.ksk.key -o boris-tassou.fr -t db.boris-tassou.fr Kboris-tassou.fr.zsk.key

La partie entre parenthèses permet de générer une chaîne de 16 caractères nécessaires pour la signature du fichier.

L’option -e permet d’ajouter une date d’expiration des clés, chose obligatoire sinon la durée est fixée automatiquement à 30 jours.
L’option -t permet d’avoir des informations à la fin de la signature.
L’option -g permet de générer les enregistrements DS (Delegation Signer).

Dans le fichier /etc/bind/named.conf.local il faut modifier la ligne file pour pointer vers le fichier signé (extension .signed).

Une fois cela fait, un reload est obligatoire:

service bind9 reload

Il est possible de contrôler si le dnssec est bien actif (opération à faire depuis le serveur DNS pour ne pas avoir à attendre la propagation):

dig DNSKEY borits-tassou.fr. @localhost +multiline

Cela doit renvoyer un résultat dig classique mais avec les key affichées complètement.

La dernière étape est d’activer le dnssec au niveau de votre registar (étape longue +24H possible).

Il faut également ajouter la clé de la zone chez le provider, pour cela il faut la récupérer:

tail -n 1 Kboris-tassou.fr.ksk.key

Cela renvoie une résultat de ce style:

domain.tld. IN DNSKEY 257 3 8 AwEAAbulFobmhae+iYuGQJ7h0RZcVOZE/FL2IcDo6P2cAD0HZaUFPl0k[.........]ba5IEC9gnok=

Ce retour va vous fournir les informations nécessaires pour la configuration de DNSSEC auprès du registar. Il y a 3 informations importantes:

  • 257 : le numéro du flag utilisé
  • 8 : numéro de l'algorithme utilisé
  • AwEAAbulFo[...] : la clé

Ces éléments la sont obligatoires pour activer le DNSSEC auprès du registar.

Il est possible d'utiliser un gestionnaire pour gérer DNSSEC comme OpenDNSSEC qui permet l'automatisation du renouvellement des clés, la resignature du fichier de zone lors de modifications, etc. Cela permet d'éviter certaines erreurs de manipulation.

Have a nice day.