Avant de ne serait-ce toucher à la machine, il serait bon d'avoir une idée, même si elle n'est pas définitive, concernant certains points :

• les utilisateurs système : il faut absolument cloisonner les services/tâches. Chaque tâche doit être effectuée sous un utilisateur système différent et, inversement, chaque utilisateur système ne doit être prévu que pour remplir une unique tâche. Ca peut paraître très restrictif mais ça permet de limiter les interactions, d'attribuer des droits appropriés, de définir lesquels peuvent être utilisés ou non pour une authentification, etc
• penser le partitionnement du disque : il serait judicieux de séparer les partitions pour les raisons suivantes :
  • user des options nosuid (/var + /home) et noexec (/var) où elles ont un sens
  • affecter une taille adaptée à chacune, /var étant sans doute la plus gourmande (à cause des logs notamment mais pas seulement)

La première chose à faire est de générer des paires de clés SSH pour chacun des utilisateurs système qui doit accéder à la machine (à commencer par root).

ssh-keygen -t rsa -C "un commentaire pour reconnaître la clé (ça peut être utile)"

Copier la clé pour l'utilisateur root distant via ssh-copy-id :

ssh-copy-id -i <chemin de la clé publique - fichier id_rsa.pub par défaut> root@<adresse IP ou nom de votre serveur>

Répéter ces étapes pour chacun des utilisateurs système du serveur dédié après avoir créé leurs comptes :

# Se connecter à votre serveur en root
ssh root@<adresse IP ou nom de votre serveur>
# Créer vos différents utilisateurs
adduser

A présent, il est urgent de limiter l'accès à SSH uniquement à ceux qui présentent une clé et non un mot de passe car ce ne serait qu'une question de temps avant qu'un tiers ne gagne cet accès (attaques de type brute-force). Pour ce faire, éditer le fichier /etc/ssh/sshd_config pour commenter ou supprimer toute ligne PasswordAuthentication yes non commentée et ajouter une ligne ChallengeResponseAuthentication no puis faire recharger sa configuration à ssh par : service sshd reload.

Note, dans le cas où l'option aurait été loupée lors du adduser ou pour le faire par la suite :

• désactiver tout login pour un compte donné :

  pw lock <login> && pw usermod <login> -s /usr/sbin/nologin

• pour désactiver l'authentification par mot de passe (elle restera possible par clé SSH) : pw usermod <login> -h -

Avec PF, on peut maintenant mettre en place quelques règles préliminaires :

• autoriser les requêtes DNS sortantes, avec leurs réponses
• autoriser le trafic SSH entrant et leurs réponses
• autoriser les requêtes FTP + HTTP sortantes, avec leurs réponses
• bloquer tout le reste
• spécificité OVH : au moins autoriser le ping depuis la machine du même réseau dont l'IP se termine par 250 sinon votre serveur va être rebooté toutes les 5 minutes ?
• facultatif : NTP sortant, avec ses réponses ?

Créer ou éditer /etc/pf.conf tel que :

# nom de l'interface réseau
ext_if = "em0"

# les adresses des serveurs DNS consultés pour la résolution
table <dns> const { 1.2.3.4 5.6.7.8 }
# réservation d'une table pour y ajouter les indésirables
# pour ajouter une adresse : pfctl -t blacklist -T add <liste d'adresses>
table <blacklist> persist

# les paquets sont bloqués sans notification à l'émetteur
set block-policy drop
# ce qui circule sur la boucle locale ne subit pas de filtrage
set skip on lo0

# politique par défaut : tout bloquer en le consignant
block log all

# blocage des indésirables
block quick from <blacklist>

# autoriser le SSH entrant (restreindre les adresses si possible)
pass in log on $ext_if proto tcp from any to $ext_if port ssh
# spécificité OVH : accepter les requêtes de ping (remplacer les X par le réseau de votre serveur) (et ses réponses - "keep state" est implicite)
pass in on $ext_if proto icmp from X.X.X.250 to $ext_if icmp-type echoreq code 0
# autoriser le DNS sortant (et ses réponses)
pass out on $ext_if proto { tcp udp } from $ext_if to <dns> port domain
# autoriser les requêtes HTTP sortantes et leurs retours
pass out proto tcp to any port { http https } # user root
# TODO : FTP

Pour rendre PF opérationnel, vu qu'il n'est pas intégré au noyau par défaut, il faut d'abord charger les modules correspondant (vous pourrez compiler votre noyau plus tard) :

# On charge les modules à la main, de suite
kldload pf
kldload pflog
# Pour ne pas avoir à le faire quand la machine (re)démarre
echo '# Packet Filter' >> /boot/loader.conf
echo 'pf_load="YES"' >> /boot/loader.conf
echo 'pflog_load="YES"' >> /boot/loader.conf

Avant de charger ses règles, toujours les vérifier par la commande :

service pf check

Enfin, charger ses règles car jusqu'ici, nous ne filtrons rien encore :

# Démarrage manuel, pour cette fois
service pf start
# Pour que ce soit automatiques aux prochains démarrages
echo '# Packet Filter' >> /etc/rc.conf
echo 'pf_load="YES"' >> /etc/rc.conf
echo 'pflog_load="YES"' >> /etc/rc.conf

Si des paquets sont déjà installés, les supprimer. Certains sont carrément inutiles et d'autres sont obsolètes et/ou peuvent créer des conflits. Il est possible d'en sauvegarder la liste, au cas où :

pkg_info > ~/packages.txt

Puis tous les supprimer :

pkg_delete -f \*

Installer ensuite les ports :

portsnap fetch extract

Puis, tant qu'à faire, commencer par basculer sur pkgng, le futur remplaçant des utilitaires pkg_* :

cd /usr/ports/ports-mgmt/pkg
make config
make config-recursive
make install clean
pkg2ng
echo "WITH_PKGNG=yes" >> /etc/make.conf

Dans le même temps, (ré)installer screen, ça peut toujours être utile, pour ne pas perdre ce qui est en cours :

cd /usr/ports/sysutils/screen
make config-recursive
make install clean

• mettre à jour votre système (méthode binaire ou source) et/ou compiler un noyau personnalisé
• tuner votre système (/etc/sysctl.conf)
• installer les différents logiciels pour mettre à disposition les services désirés via les ports. Prendre le temps de les tester et configurer correctement avant de les rendre accessible
• configurer la rotation des journaux (/etc/newsyslog.conf)
• mettre en place différents moyens de sauvegarde
• etc

Par les logiciels portés :

cd /usr/ports/mail/opensmtpd
make install clean

Créer le fichier de configuration d'opensmtpd, /usr/local/etc/mail/smtpd.conf, tel que :

listen on lo0

table aliases db:/usr/local/etc/mail/aliases.db

accept from local for local alias <aliases> deliver to mbox
accept from local for any relay

Faire reconnaître les alias à opensmtpd sinon cron, notamment, va vainement tenter d'envoyer les rapports d'exécution de ses tâches :

ln -s /etc/mail/aliases /usr/local/etc/mail/aliases
newaliases

A présent, désactiver sendmail, si ce n'est pas déjà fait au profit d'opensmtpd :

echo 'smtpd_enable="YES"' >> /etc/rc.conf
# et
echo 'sendmail_enable="NONE"' >> /etc/rc.conf
# ou
echo 'sendmail_enable="NO"' >> /etc/rc.conf
echo 'sendmail_submit_enable="NO"' >> /etc/rc.conf
echo 'sendmail_outbound_enable="NO"' >> /etc/rc.conf
echo 'sendmail_msp_queue_enable="NO"' >> /etc/rc.conf

Démarrer manuellement opensmtpd pour cette fois :

service smtpd start

Ajouter une règle au pare-feu (/etc/pf.conf) qui, normalement, correspond à :

# autoriser SMTP(S) sortant (et ses réponses)
pass out on $ext_if proto tcp from $ext_if to any port { smtp smtps }

Puis charger votre nouvelle configuration :

service pf reload

Enfin, tester le bon fonctionnement de l'envoi de mails par :

echo "This will go into the body of the mail." | mail -s "Hello world" <votre adresse email>

Si tout se passe bien, vous devriez recevoir un mail qui sera certainement reconnu comme un spam (pour le moment)

Il s'agit là d'ajouter une entrée DNS de type TXT avec un nom d'hôte vide à votre domaine permettant d'indiquer quelles machines sont ou non autorisées à envoyer des mails sous le nom de votre domaine.

Par exemple, avec la valeur v=spf1 mx ~all, seules les machines figurant en entrée de type MX peuvent envoyer des mails sous le nom de votre domaine.

Note : le prestataire qui a en charge la gestion de votre domaine vous propose éventuellement une interface pour facilement réaliser cette tâche (OVH, par exemple, vous propose directement d'ajouter une entrée de type SPF).

Installons tout d'abord dkimproxy :

cd /usr/ports/mail/dkimproxy
make install clean

Puis configurons-le pour chiffrer les mails sortants (uniquement) au travers du fichier /usr/local/etc/dkimproxy_out.conf de sorte à ce qu'il ressemble à ceci :

listen    127.0.0.1:10027
relay     127.0.0.1:10028

domain    mondomaine.fr
signature dkim(c=relaxed)
signature domainkeys(c=nofws)
keyfile   /usr/local/etc/dkimproxy.private.key
selector  selector1
min_servers 1
min_spare_servers 1

Générer les clés publique & privée par ses commandes :

cd /usr/local/etc/
openssl genrsa -out dkimproxy.private.key 1024
openssl rsa -in dkimproxy.private.key -out dkimproxy.public.key -pubout -outform PEM
chmod 0600 *.key
chown dkimproxy *.key

Démarrer le service dkimproxy_out :

# Démarrage manuel de suite
service dkimproxy_out start
# Pour qu'il soit démarré tout seul aux (re)démarrages
echo 'dkimproxy_out_enable="YES"' >> /etc/rc.conf

Ajouter un nouveau champ TXT nommé "selector1._domainkey" pour votre domaine de telle sorte à obtenir :

g=*; k=rsa; p=<clé publique, le contenu du fichier /usr/local/etc/dkimproxy.public.key>;

Enfin, il est nécessaire d'apporter quelques modifications à la configuration de opensmtpd (fichier /usr/local/etc/mail/smtpd.conf) :

• après la ligne listen on lo0, ajouter : listen on lo0 port 10028 tag DKIM pour la réception des mails après chiffrage
• remplacer la ligne accept from local for any relay par :

  accept tagged DKIM for any relay # cette règle doit être avant, sinon boucle infinie
  accept from local for any relay via smtp://127.0.0.1:10027

La première envoie réellement les mails après chiffrage quand la seconde les fait d'abord transiter par dkimproxy pour qu'ils deviennent chiffrés.

Recharger sa configuration pour qu'elle entre en vigueur dès maintenant : service smtpd reload

A présent (et après avoir attendu un certain laps de temps par rapport à la propagation des DNS), si l'on retente d'envoyer un mail, il ne devrait alors plus figurer parmi les spams.

TODO

• Lire un message en queue :

  smtpctl show message <identifiant du message (voir sortie de smtpctl show queue)>

• Vider la queue :

  smtpctl show queue | cut -f 1 -d'|' | xargs -n1 smtpctl remove

Pas de panique, chez OVH, tant que le problème n'est pas physique, il est normalement possible de récupérer un système. Via l'interface client, suivre ces étapes :

• prochain démarrage sur le réseau : services > netboot > sélectionner rescue-pro
• redémarrage hardware : services > rebooter
• accéder à la machine via les paramètres qui vous sont envoyés par mail et tenter de corriger le problème :

  fsck -y -t ufs /dev/<slice correspondant à la racine de votre système>
  mount -t ufs /dev/<slice correspondant à la racine de votre système> /mnt
  chroot /mnt /bin/tcsh
  
  # rectifier l'erreur
  
  exit # quitter le chroot
  umount /mnt

• prochain démarrage sur disque dur et non plus réseau (dans votre interface client) : services > netboot > sélectionner hd
• redémarrage software (reboot ou shutdown -r now) en ssh

Avant toute chose, nous devons générer nos certificat/clés (à ne faire qu'une fois)

openssl req -x509 -nodes -days 100000 -newkey rsa:2048 -keyout dump.private.key -out dump.public.key -subj '/'
chmod 0600 *.key

A réaliser sur votre propre machine (ici, nous supposerons que les deux clés sont situées dans nos répertoires personnels).

La commande pour chiffrer est :

openssl smime -encrypt -binary -aes256 -in <fichier entrée> -out <fichier sortie> -outform DER ~/dump.public.key

La commande pour déchiffrer, quant à elle, est :

openssl smime -decrypt -binary -in <fichier entrée> -inform DER -out <fichier sortie> -inkey ~/dump.private.key

Ajouter une option -passin à la ligne de commande si la clé privée est protégée par une phrase secrète.

Sur votre serveur :

• uploader la clé publique (fichier dump.public.key) sur votre serveur
• créer ou modifier le fichier ~/.netrc de votre utilisateur système pour les sauvegardes tel que :

machine ftp.foo.bar
login votre_login
password votre_mot_de_passe
 
macdef uploaddump
cd /pub/backups/
bin
put $1
quit
# laissez impérativement une ligne vide en fin de ce fichier

Assurez-vous que ce fichier ne soit lisible que de vous seul (chmod 0600 ~/.netrc). La partie machine permet d'indiquer vos identifiants par rapport à un serveur sans que vous ayez à le faire au moment d'utiliser la commande ftp. La partie macdef définit une macro, un ensemble d'instructions regroupé sous un nom (uploaddump ici). Vous pouvez passer des paramètres à vos macros au moment de leur appel et les référencer de la même manière qu'un script shell (variable $X où 9 >= X >= 1). Pour exécuter une macro, via un shell type (ba)sh, il suffit simplement de procéder de la façon suivante : echo '$ uploaddump nom_fichier' | ftp ftp.foo.bar, qui ici aurait pour but d'uploader nom_fichier sur le serveur ftp.foo.bar en mode binaire dans le répertoire /pub/backups/.

Regroupons à présent tous les éléments pour en faire un script (qui peut être exécuté via cron) :

#!/bin/sh

FILENAME="`date '+%Y%m%d%H'`.sql"
SAFE_FILENAME="${FILENAME}.enc"

# Sauvegarde de notre base de données
mysqldump ... > $FILENAME

# Chiffre le fichier
openssl smime -encrypt -binary -aes256 -in $FILENAME -out $SAFE_FILENAME -outform DER ~/dump.public.key

# Upload du fichier chiffré
echo "\$ uploaddump ${SAFE_FILENAME}" | ftp ftp.foo.bar

Attention : je donne cette solution pour des circonstances précises, ceux qui n'ont pas véritablement le choix parce qu'il y a bien plus simple et sûr en passant par des protocoles comme scp par exemple.

IPv6 est parfaitement fonctionnel. Pour en garder une trace, voici mes propres "observations" concernant IPv6 :

• la passerelle par défaut, bien que mise en place pour être statique via /etc/rc.conf semble expirer environ 30 minutes après le boot. Il est facile de la remettre en place par la commande route add -inet6 default ...
• par rapport au pare-feu, il faut au moins laisser passer les packets ICMP de type neighbor solicitation (icmp6-type neighbrsol) et advertisement (icmp6-type neighbradv) dans la mesure où ça remplace le protocole ARP donc sans cela, les paquets ne sauraient être routés jusqu'à votre machine
• PF a quelques "spécificités :
  • modulate state est incompatible avec IPv6
  • scrub, comme mentionné dans man 5 pf.conf, a pour effet de bloquer les paquets IPv6

Dans la mesure où la passerelle par défaut est connue, il n'est pas nécessaire de compter sur une autoconfiguration de celle-ci via les router advertisement/solicitation (commande rtsol pour émettre un paquet ICMP router solicitation afin qu'un routeur réponde par un router advertisement en retour).